Nioh 仁王開発の門番に、品質の知を。
AIが書いたコードを、
世に出す前に見極める。
AIはコードもテストも量産します。けれど、その正しさを見極める役目は、まだ人に残っています。buboのQA方法論を、要件定義から運用までのMCPツール「Nioh（仁王／読み：におう）」にしました。AIに仕事を奪われるのではなく、AIの番人になる。動かすのは、お手元のLLM。鍵もあなたのものを使います。buboはサーバーを提供するだけです。
無料ベータ・面談制・正式版は有料提供予定（ベータ枠は限定）
- 所要時間: 30分
- 進め方: 現場の状況をヒアリングし、最初に効くツールと順番を一緒に決めます
- ご準備は不要です
なぜいま、QAに「AIの番人」が必要なのか
2026年のQAの現場で起きているのは、仕事がなくなることではありません。AIが書いたコードやテストを、世に出してよいか見極める作業を、人が延々と引き受ける事態です。通っているのに欠陥を見逃すテスト、抜けたままの要件、気づかないうちに壊れる互換性。buboがめざすのは「つくり手が、はじめから良いものを、当たり前につくる」世界です。品質は後から検査して足すものではなく、つくるその瞬間から織り込めるはずです。Niohは、その考えを道具にしたものです。AIの生成物をひとつずつ見極め、世に出す前に止められます。とりわけAIでコードを書く開発者に効き、品質を見るQA・テストの現場でも、そのまま力を発揮します。
開発工程に沿って、上流から運用まで
要件定義から設計、実装・コードレビュー、テスト、リリース・運用まで。各工程に効く道具をそろえています。まずは全体像から。
まず試すならこの2本
全工程に入れる必要はありません。まずは1工程・1チームから試せます。
要件レビューAIspec-verification
要件の穴（測れない成功基準・対象者の抜け・手段どまりの記述）を、誰が見ても同じ観点で必ず突きます。自社の要件定義に毎増分適用しているほか、官公庁が公開している実物の要件定義書（400ページ超）を素材にした検証では44件の実指摘を返しました。
前提：USDM形式の要件が対象です。自由記述は usdm-normalize で前段変換できます。
トレーサビリティ点検traceability
要件・設計・テストのID対応を数え上げ、テストの無い要件・宙ぶらりんのテストを割り出します。自社開発のドッグフーディング監査では、テスト未被覆の要件6件・宙ぶらりんのテスト1件を検出し、補完したテストが今もコードとして残っています。決定的なロジックだけで動くため、LLM不要・API費用ゼロで試せます。
前提：要件ID（REQ-）・テストID（TC-）の命名規約に沿った文書が対象です。
実装に入る前に、要件の見落としを洗い出す
バグの多くは、コードを書く前の要件で仕込まれます。仕様の見落とし・あいまいさ・対象者の抜けを、実装に入る前に洗い出します。下流で何倍にも膨らむ手戻りを、入口で断つための道具です。
その要件定義書、つくる前から穴が空いていませんか。
要件レビューAIspec-verification
手段の羅列・対象者の抜け・測れない要求を、実装前に洗い出します。
前提：USDM形式（## REQ-NN + 理由 + 成功基準 + SPEC）。自由記述はusdm-normalizeで前段変換
箇条書きと散文が混ざった要件を、診断にかけられる形に直す手間。
要件フォーマット整形usdm-normalize
自由形式の要件テキストを、USDM形式へ自動で整えます。
前提：特になし（自由形式の要件定義テキストを受け付ける。むしろUSDM前段変換の入口ツール）
受入条件はそろっているのに、対象ユーザーは目的まで到達できていませんか。
受入条件の妥当性レビューspec-validation
抽象的な品質語をペルソナ視点で本質に分解し、受入条件の妥当性を裁定します。
前提：personas/scenes/surfaceは必須。criteria（任意）はspec-verificationが分解した受入条件を渡す想定
設計のうちに、抜けとテスト観点を固める
影響範囲や異常系の抜けは、設計の段階なら安く直せます。必要なテスト観点・優先度・要件とテストのつながりを設計時に固め、テストしにくい構造も先回りで見つけます。
実装に入ってから「この設計、影響範囲を見落としていた」と気づいていませんか。
基本設計レビューAIdesign-review
基本設計書を、コードを書く前にレビューします。
そのテスト、何を確かめるべきかが決まる前に、書き始めていませんか。
テスト設計AItest-design
設計段階で必要なテスト観点・技法と、テストしにくい箇所を先回りで示します。
前提：design_from_specは自然言語の仕様文。技法系4関数は構造化入力（min/max・conditions・factors・states/events）で前提なし
そのテスト設計、レビューは通ったのに実は測れていませんか。
テスト設計の品質評価vvassess
検証×妥当性確認の6セル19要素を、事実ベースで決定的に評価します。
前提：assessに渡すfactsは正規化済み事実スキーマ必須（planの収集プレイブックに沿って呼び出し元が整形）
そのテスト、何をもって「合格」とするかが曖昧なまま動いていませんか。
テストオラクル導出test-oracle-deriver
仕様から期待結果・合否判定基準・許容範囲を導き出します。
限られた工数を、本当に効くテストに割けていますか。
リスクベース優先度づけrisk-based-test-prioritizer
リスクの大きさでテストの優先度を算出し、工数配分をティアで示します。
テストのない要件や、宙ぶらりんのテストが紛れ込んでいませんか。
トレーサビリティ点検traceability
要件・設計・テストの対応を数え上げ、つながりの切れ目を見つけます。
前提：REQ-/TC- 形式のID規約（要件ID=REQ-1等、テストID=TC-1等が明示されていること）
AIが書いた変更を、世に出す前に見極める
AIは速く書きますが、要件どおりか・既存を壊していないかは別の話です。変更・要件・テストの突き合わせ、想定外の入力で壊れる箇所、公開APIの互換性まで、実装のその場で押さえます。
AIが書いた変更、本当に要件どおりで、既存を壊していないと言い切れますか。
AI変更検証AIai-change-verify
AIの変更が要件どおり・抜けなく・既存を壊さず実装できているかを見極めます。
前提：change/requirement/testsの3点セット（requirementはREQ-ID＋受入条件文＋参照シンボル/ファイル名を含めること）
「完了しました」の一言を、そのまま信じて大丈夫ですか。
完了条件チェッカーdone-verifier
完了と申告された変更が、受入条件を本当に満たすか裏取りします。
前提：acceptanceはDoDチェックリスト形式（- [ ]／* ／1. 等のマーカー付き改行区切りリスト、1項目以上）
想定外の入力が来たとき、そのコードは例外で落ちませんか。
堅牢性チェックrobustness-lint
エッジ入力で例外を投げる、ガードのない危険操作を検出します。
前提：Python実装コードのみ対応
ファイルや接続の閉じ忘れが、本番でじわじわ効いてきていませんか。
資源リーク検出resource-leak-lint
ファイル・接続・ロック等の解放漏れを検出し、資源枯渇を防ぎます。
前提：決定的層はPythonのみ対応（python以外はLLM層のみに委譲）
そのAPI変更、使っている既存プログラムを黙って壊していませんか。
API互換性チェックapi-contract
公開API変更時、互換性を壊す変更をリリース前に見つけます。
前提：契約形式は {functions|endpoints|operations:[{name,params,returns}]} または JSON Schema風 {fields|properties,required}。各操作要素にnameキー必須
外部から来た文字列を、ガードなしでLLMに渡していませんか。
プロンプトインジェクション検査prompt-injection-lint
未信頼の入力が無防備にプロンプトへ連結される箇所を検出します。
AIが返すJSON、たまに形が崩れて後続が落ちていませんか。
LLM出力契約チェックllm-output-contract
LLMの構造化出力が、宣言したスキーマどおりか出力前に検証します。
前提：期待スキーマはJSON Schema風部分集合（type/required/properties/items/enumを解する）
AI製品の出力やログに、見せてはいけないものが混ざっていませんか。
AI出力 漏えい検査llm-leak-scan
出力・ログ・説明文から、社外秘や個人情報の漏れを公開前に検査します。
通っているのに欠陥を見逃すテストを、見抜く
テストは数があれば安心、ではありません。通っているのに欠陥を見逃すテストや、壊れやすく不安定なテストを見抜き、テストそのものの効き目を確かめます。
テストは全部通っているのに本番でバグが出る。そのテスト、効いていますか。
テスト有効性スコアtest-effectiveness
通っているのに実バグを捕まえない、弱いテストを検出してスコア化します。
前提：Pythonテストコードのみ対応（pytest/unittest）
そのテストコード、読みにくく壊れやすくなっていませんか。
テストコード品質チェックtest-smell-lint
テストコードの構造的なアンチパターンを検出します。
たまに落ちて、また通る。あの不安定なテストに悩まされていませんか。
不安定テスト検出flake-forecast
テストの非決定性を実行前に検出し、flakyを未然に抑えます。
出した後の不具合を、学びに変える
本番は、出してからが本番です。出た不具合を根本原因まで掘り下げ、再発防止と、どこにテストを足すべきかまで返します。世に出したソフトウェアを支え続けるための道具です。
出た不具合を、その場の修正で終わらせていませんか。
不具合分析AIdefect-analyzer
不具合を分類・集計し、根本原因と再発防止・テスト追加先まで返します。
ただのAIに聞くのと、何が違うのか
汎用のAIは「聞けば何か答える」もの。Niohは「何を・どう確かめるかを知っている」道具です。buboが開発とQAの現場で積み上げてきた方法論を、その中に閉じ込めています。
確かめるべき観点を、ツールが持っている
何を確かめるべきかというQAの観点を、ツール側が持っています。要件はUSDM、テスト設計は境界値やデシジョンテーブルといった技法にもとづき、抜けなく同じ目線で見ます。プロンプトの上手・下手に結果が左右されません。
決定的で、再現する
多くのツールは静的解析で答えを出すため、同じ入力なら同じ結果が返ります。LLMにありがちな「毎回ぶれる」「もっともらしい誤り（ハルシネーション）」を避け、AIに送るのは必要な場面だけにしています。
合否で返せる＝ゲートにできる
指摘・スコア・合否といった構造化された形で返るので、CIに組み込んで自動で止められます。会話AIの文章では、機械的に止めることはできません。
実際の入力と、返ってきた出力
同じ要件を、汎用AIと spec-verification にそのまま渡した、実際のやりとりです（要約ではありません）。要件には、測れないもの・手段が先行したものが混じっています。
## REQ-01 システムは高速に応答すること ## REQ-02 管理者はユーザー情報をCSV形式でエクスポートできる ## REQ-03 ログイン画面にreCAPTCHAを導入する ## REQ-04 画面はわかりやすく、使いやすいこと ## REQ-05 データはできるだけ安全に保管すること
REQ-01「システムは高速に応答すること」— 「高速」の定義がないため合否判定ができません。「主要画面は3秒以内に表示」のように、具体的な数値目標と測定条件(負荷条件・ネットワーク環境等)を明記すべきです。 REQ-02「管理者はユーザー情報をCSV形式でエクスポートできる」— これは要件として比較的具体的ですが、詳細が不足しています。エクスポート対象の項目(全項目か一部か)、文字コード(Shift_JISかUTF-8か)、対象データの範囲(全件か検索結果か)、権限確認の方法などを補足すると実装・テストしやすくなります。 REQ-03「ログイン画面にreCAPTCHAを導入する」— これは要件というより実現手段(How)を直接指定しています。本来の要件は「不正ログイン・ボット攻撃を防止する」であり、reCAPTCHAはその一手段のはずです。手段を先に固定すると他の選択肢(レートリミット、多要素認証など)を検討する余地がなくなるので、目的と手段を分けて書くことをおすすめします。 REQ-04「画面はわかりやすく、使いやすいこと」— REQ-01と同様、「わかりやすい」「使いやすい」が主観的で検証不能です。誰にとって(新規ユーザーか熟練ユーザーか)、どういう基準で判定するか(タスク完了率、初回操作の迷いの少なさ、UIガイドライン準拠など)を明確にする必要があります。 REQ-05「データはできるだけ安全に保管すること」— 「できるだけ」という表現が曖昧で、対策の範囲に上限がありません。対象データの機密度に応じて、暗号化方式(保管時・通信時)、アクセス制御、バックアップ方針など、どこまで対応するかの基準を具体化すべきです。 全体として、REQ-01・04・05は非機能要件が定性的な表現にとどまっており検証可能性が低く、REQ-02は詳細度が不足、REQ-03は目的と手段が混同されています。優先度としては、まず「何を達成したいか(目的)」を明文化し、その上で数値基準や実装手段を整理し直すと、後工程のテスト設計や実装判断がぶれにくくなります。
# 修正リスト - [要確認] 上位価値 @ 文書全体 - 問題: 要求全体が実現しようとする具体的な業務目標や最終アウトカムが定義されていないため、要件の妥当性が判断できません。 - 直し方: システム導入によって達成したい具体的な事業目的や、解決すべき課題を最上位のゴールとして定義してください。 - [要確認] 対象者 @ REQ-01 - 問題: REQ-01「システムは高速に応答すること」: 価値の受け手が明記されていないため、誰にとっての高速応答か不明。 - 直し方: 「利用者が快適に操作できるよう、システムは応答速度を○秒以内とする」のように対象を明記する。 - 展開漏れ @ REQ-01 - 問題: REQ-01 に対応する仕様(SPEC)がありません - 直し方: REQ-01 を実現する仕様を SPEC-01-1 形式で追加してください - 成功基準欠落 @ REQ-01 - 問題: REQ-01 に成功基準がありません - 記入例: 検索ボタン押下後、2秒以内に結果画面を表示する。 - 理由欠落 @ REQ-01 - 問題: REQ-01 に理由(reason)がありません - 記入例: 検索待ち時間を短縮し、ユーザーの操作ストレスを軽減するため。 - [要確認] to-be価値 @ REQ-02 - 問題: REQ-02: エクスポートという手段に焦点が当たり、目的である業務上のメリットやあるべき状態が未定義。 - [要確認] 漏れ:広さ @ REQ-02 - 問題: REQ-02: ユーザーデータの取り扱いやログイン履歴に関する監査証跡の要件が定義されていない。 - 展開漏れ / 成功基準欠落 / 理由欠落 @ REQ-02 - 問題: 仕様(SPEC)・成功基準・理由が未記載。 - [要確認] to-be価値 @ REQ-03 - 問題: REQ-03「reCAPTCHAを導入する」: reCAPTCHA導入という手段が目的化しており、セキュリティ上の期待状態が不明確。 - 直し方: 「ボットによる不正アクセスが確実に排除され、ログインの安全性が確保されている」ことを目的として記述する。 - [要確認] 対象者 @ REQ-03 - 問題: 導入の目的や、誰の利便性・保護のための措置かが不明。 - [要確認] 漏れ:状態 @ REQ-03 - 問題: reCAPTCHAの認証失敗時のエラー処理・通知要件が欠如。 - 展開漏れ / 成功基準欠落 / 理由欠落 @ REQ-03 - 問題: 仕様(SPEC)・成功基準・理由が未記載。 - [要確認] 対象者 @ REQ-04 - 問題: REQ-04「わかりやすく、使いやすいこと」: 誰にとってわかりやすいかが不明。 - 直し方: 「一般ユーザーがマニュアルなしで操作できるよう、画面のUIを改善する」のように対象を限定する。 - 展開漏れ / 成功基準欠落 / 理由欠落 @ REQ-04 - 問題: 仕様(SPEC)・成功基準・理由が未記載。 - 記入例: 主要なメニューへの遷移を3クリック以内で行えること。 - [要確認] 対象者 @ REQ-05 - 問題: REQ-05「できるだけ安全に保管すること」: 誰のどのような利益のために安全保管するのか対象が不明。 - 展開漏れ / 成功基準欠落 / 理由欠落 @ REQ-05 - 問題: 仕様(SPEC)・成功基準・理由が未記載。 - 記入例: 全ての個人情報はAES-256で暗号化し、3年間の保存期間を設定する。
汎用LLMだけに任せるときのリスク
- 再現しない：同じ入力でも結果が毎回変わり、監査や再チェックの基準にできない。
- 網羅の保証がない：見落としても「見落とした」ことに気づけない。確認する項目が増えるほど崩れやすい。
- もっともらしい誤り：実在しない問題や誤った基準を、自信ありげに混ぜることがある（ハルシネーション）。
- 自動で止められない：出力は文章のため、CIの品質ゲートとして機械的にブロックできない。
汎用AIの回答にも妥当な指摘は含まれますが、網羅の保証がなく、実行のたびに変わります。spec-verification は全要件×観点を漏れなく機械的に点検し（網羅を保証・同じ入力なら毎回同じ）、USDM方法論（対象者／手段の目的化／価値の深さ・広さ・状態）に沿って構造化・記入例つきで返す点です。上のリスクは、この決定的な網羅と合否での出力で抑えられます。
使い方は、2通り
開発の最中に、お使いのAIクライアント（Claude・Cursorなど）から呼び出し、その場でレビューや指摘を受け取ります。要件・設計のレビューや、テスト観点の洗い出しに向いています。
合否を返すツールは、GitHub ActionsなどのCIに組み込み、基準を満たさない変更を自動で止める「品質ゲート」にできます。互換性チェックや、AIが書いた変更の検証などに向いています。
これらは、bubo自身が日々の開発で使っている道具です。要件レビューやテスト観点の洗い出しに、私たち自身が開発ループへ組み込んで使っています。品質を後から足すのではなく、つくるその場で織り込む。Niohは、その手を開発のいちばん近くに置きます。
社外秘のコードを、どう守るか
buboは入力を保存しません
ツールに渡したコード・仕様・データを、buboのサーバーは保存しません。bubo自身が学習に使うこともなく、処理はその場限りです。
AIに送るか・どこへ送るかは、あなたが握ります
標準のキーレス接続では、意味を読む処理は普段お使いのAIクライアントの中で実行されます。データの扱いは、お客様とそのプロバイダの既存のご契約のもとにあり、buboがAPIキーやコードをお預かりすることはありません。ご自身の契約するプロバイダを直接指定したい場合は、BYOK（Bring Your Own Key）として任意で設定できます。
AIに送らず動くツールも多くあります
多くのツールは決定的な静的解析だけで完結し、LLMに渡すのは必要な場面に限られます。AIに送る範囲を、あなた自身で絞り込めます。
ワンタイムコードは単回使用・有効期限7日・サーバーに平文保存はしません。発行したトークンは設定ファイルに直書きせず環境変数で参照します。既存のMCP設定がある場合も、壊さず冪等にマージします。
どう申し込み、どうつなぐのか
1. 面談を予約する
予約フォームから面談をお申し込みください。現在のQAの困りごとと、試したいツールをお聞かせいただきます。
2. 面談で適用先を一緒に決める
そろえたツールのうち、貴社の工程で効く順番をご一緒に見立てます。ワンタイムコードと接続コマンドは、面談後にあわせてお渡しします。
3. コード1つ、コマンド1行で接続
お受け取りしたワンタイムコードで、コマンドを1行実行（Windows / mac / Linux 各1行）。有効化・MCP設定（.mcp.json）生成・環境変数設定まで自動で完了します。あとはAIクライアント（Claude Code / Gemini CLI）を再起動するだけで、そのままQA方法論を呼び出せます。APIキーのご用意は不要です。ご自身の契約するLLMを使いたい場合は、BYOK（Bring Your Own Key）として任意で設定いただけます。
ベータの条件
- buboの利用料は無料です。標準のキーレス接続は、普段お使いのAIクライアントのご契約の中で動くため、別途のAPI利用料は発生しません（ご自身が契約するLLMを使いたい場合は、BYOKとして任意で選べます。その場合はそのLLMのAPI利用料が別途かかります）。
- 面談制です。予約フォームからお申し込みのうえ、面談を経てご利用いただけます。
- 枠には限りがあります。お早めにご相談ください。
- 正式版は有料サブスクリプションでの提供を予定しています。正式版公開時にベータは終了します。
- ベータ期間中にいただいたご意見は、正式版の改善に活用させていただきます。
よくあるご質問
本当に無料ですか。あとから請求されませんか。
ベータ期間中、buboの利用料は無料です。標準のキーレス接続は、普段お使いのAIクライアントのご契約の中で動くため、別途のLLM API利用料は発生しません。ご自身の契約するLLMをBYOKで使う場合のみ、そのAPI利用料が利用者側にかかります。buboからあとで請求することはありません。正式版は有料サブスクリプションでの提供を予定していますが、ベータがそのまま課金に切り替わることはなく、正式版公開時にベータは終了します。
入力したコードやデータは安全ですか。
渡したコード・仕様・データを、buboのサーバーは保存しません。bubo自身が学習に使うこともありません。またLLMを使う処理は、標準のキーレス接続では普段お使いのAIクライアントの中で実行されます（BYOKの場合はご自身が指定したプロバイダ）。学習に使うかどうかといったデータの規約は、いずれもお客様とプロバイダのご契約のもとにあります。データの流れは面談で具体的にご説明します。
どのツールがAIにデータを送りますか。
ツールは大きく3種類です。（1）静的解析や集計だけで完結し外部LLMを一切呼ばないもの（テスト有効性・堅牢性・資源リーク・API互換性・トレーサビリティ など）、（2）静的解析を主に、必要に応じてLLMを併用できるもの、（3）要件レビュー・テスト設計・AI変更検証など、判断や生成にLLMを使うもの。AIに送る範囲は利用者ご自身で絞り込めます。どのツールが外部LLMに送り・送らないか、通信経路とあわせた資料は、セキュリティ審査向けに面談でお渡しします。
正式版の価格はいくらですか。
正式版は有料サブスクリプションを予定していますが、価格は現在準備中です。決まり次第お知らせします。ベータにお申し込みいただいた方には、正式版のご案内を優先的にお送りします。
ツールがたくさんありますが、どれから始めればよいですか。
面談で貴社の工程をうかがい、効く順番をご一緒に見立てます。多くの場合、上流（要件レビュー）か、AI生成物の検証から始めると効果を実感しやすいです。まずは1〜2ツールからで構いません。
途中でやめたり、ベータが終了したらどうなりますか。
いつでもご利用を停止いただけます。違約金などはありません。ベータは正式版公開時に終了しますが、その際は事前にご案内し、正式版への移行をご希望の方にはご相談に応じます。
どんな環境で使えますか。
MCP（Model Context Protocol）に対応したAIクライアントからご利用いただけます。APIキーのご用意は不要でそのまま接続できます（ご自身の鍵を使うBYOKも任意で選べます）。具体的な対応環境と設定手順は面談でお渡しします。
lint系ツールで誤検出が続くと、CIが赤くなり続けませんか。
誤検出は report_outcome で「見送った（false_positive）」旨を報告するとallowlistに登録され、以後は suppress 引数で自動的に除外対象になります。サーバー側は入力・検出結果を保存しないステートレス設計のため、allowlistの管理は利用者側の環境で行っていただきます。