Nioh 仁王開発の門番に、品質の知を。
AIが書いたコードを、
世に出す前に見極める。
AIはコードもテストも量産します。けれど、その正しさを見極める役目は、まだ人に残っています。buboのQA方法論を、要件定義から運用までのMCPツール「Nioh（仁王／読み：におう）」にしました。AIに仕事を奪われるのではなく、AIの番人になる。動かすのは、お手元のLLM。鍵もあなたのものを使います。buboはサーバーを提供するだけです。
無料ベータ・面談制・正式版は有料提供予定（ベータ枠は限定）
なぜいま、QAに「AIの番人」が必要なのか
2026年のQAの現場で起きているのは、仕事がなくなることではありません。AIが書いたコードやテストを、世に出してよいか見極める作業を、人が延々と引き受ける事態です。通っているのに欠陥を見逃すテスト、抜けたままの要件、気づかないうちに壊れる互換性。buboがめざすのは「つくり手が、はじめから良いものを、当たり前につくる」世界です。品質は後から検査して足すものではなく、つくるその瞬間から織り込めるはずです。Niohは、その考えを道具にしたものです。AIの生成物をひとつずつ見極め、世に出す前に止められます。とりわけAIでコードを書く開発者に効き、品質を見るQA・テストの現場でも、そのまま力を発揮します。
開発工程に沿って、上流から運用まで
要件定義から設計、実装・コードレビュー、テスト、リリース・運用まで。各工程に効く道具をそろえています。まずは全体像から。
実装に入る前に、要件の見落としを洗い出す
バグの多くは、コードを書く前の要件で仕込まれます。仕様の見落とし・あいまいさ・対象者の抜けを、実装に入る前に洗い出します。下流で何倍にも膨らむ手戻りを、入口で断つための道具です。
設計のうちに、抜けとテスト観点を固める
影響範囲や異常系の抜けは、設計の段階なら安く直せます。必要なテスト観点・優先度・要件とテストのつながりを設計時に固め、テストしにくい構造も先回りで見つけます。
そのテスト、何を確かめるべきかが決まる前に、書き始めていませんか。
テスト設計AItest-design
設計段階で必要なテスト観点・技法と、テストしにくい箇所を先回りで示します。
そのテスト、何をもって「合格」とするかが曖昧なまま動いていませんか。
テストオラクル導出test-oracle-deriver
仕様から期待結果・合否判定基準・許容範囲を導き出します。
限られた工数を、本当に効くテストに割けていますか。
リスクベース優先度づけrisk-based-test-prioritizer
リスクの大きさでテストの優先度を算出し、工数配分をティアで示します。
テストのない要件や、宙ぶらりんのテストが紛れ込んでいませんか。
トレーサビリティ点検traceability
要件・設計・テストの対応を数え上げ、つながりの切れ目を見つけます。
AIが書いた変更を、世に出す前に見極める
AIは速く書きますが、要件どおりか・既存を壊していないかは別の話です。変更・要件・テストの突き合わせ、想定外の入力で壊れる箇所、公開APIの互換性まで、実装のその場で押さえます。
AIが書いた変更、本当に要件どおりで、既存を壊していないと言い切れますか。
AI変更検証AIai-change-verify
AIの変更が要件どおり・抜けなく・既存を壊さず実装できているかを見極めます。
ファイルや接続の閉じ忘れが、本番でじわじわ効いてきていませんか。
資源リーク検出resource-leak-lint
ファイル・接続・ロック等の解放漏れを検出し、資源枯渇を防ぎます。
外部から来た文字列を、ガードなしでLLMに渡していませんか。
プロンプトインジェクション検査prompt-injection-lint
未信頼の入力が無防備にプロンプトへ連結される箇所を検出します。
AIが返すJSON、たまに形が崩れて後続が落ちていませんか。
LLM出力契約チェックllm-output-contract
LLMの構造化出力が、宣言したスキーマどおりか出力前に検証します。
AI製品の出力やログに、見せてはいけないものが混ざっていませんか。
AI出力 漏えい検査llm-leak-scan
出力・ログ・説明文から、社外秘や個人情報の漏れを公開前に検査します。
通っているのに欠陥を見逃すテストを、見抜く
テストは数があれば安心、ではありません。通っているのに欠陥を見逃すテストや、壊れやすく不安定なテストを見抜き、テストそのものの効き目を確かめます。
出した後の不具合を、学びに変える
本番は、出してからが本番です。出た不具合を根本原因まで掘り下げ、再発防止と、どこにテストを足すべきかまで返します。世に出したソフトウェアを支え続けるための道具です。
ただのAIに聞くのと、何が違うのか
汎用のAIは「聞けば何か答える」もの。Niohは「何を・どう確かめるかを知っている」道具です。buboが開発とQAの現場で積み上げてきた方法論を、その中に閉じ込めています。
確かめるべき観点を、ツールが持っている
何を確かめるべきかというQAの観点を、ツール側が持っています。要件はUSDM、テスト設計は境界値やデシジョンテーブルといった技法にもとづき、抜けなく同じ目線で見ます。プロンプトの上手・下手に結果が左右されません。
決定的で、再現する
多くのツールは静的解析で答えを出すため、同じ入力なら同じ結果が返ります。LLMにありがちな「毎回ぶれる」「もっともらしい誤り（ハルシネーション）」を避け、AIに送るのは必要な場面だけにしています。
合否で返せる＝ゲートにできる
指摘・スコア・合否といった構造化された形で返るので、CIに組み込んで自動で止められます。会話AIの文章では、機械的に止めることはできません。
実際の入力と、返ってきた出力
同じ要件を、汎用AIと spec-validation にそのまま渡した、実際のやりとりです（要約ではありません）。要件には、測れないもの・手段が先行したものが混じっています。
## 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-validation は全要件×観点を漏れなく機械的に点検し（網羅を保証・同じ入力なら毎回同じ）、USDM方法論（対象者／手段の目的化／価値の深さ・広さ・状態）に沿って構造化・記入例つきで返す点です。上のリスクは、この決定的な網羅と合否での出力で抑えられます。
使い方は、2通り
開発の最中に、お使いのAIクライアント（Claude・Cursorなど）から呼び出し、その場でレビューや指摘を受け取ります。要件・設計のレビューや、テスト観点の洗い出しに向いています。
合否を返すツールは、GitHub ActionsなどのCIに組み込み、基準を満たさない変更を自動で止める「品質ゲート」にできます。互換性チェックや、AIが書いた変更の検証などに向いています。
これらは、bubo自身が日々の開発で使っている道具です。要件レビューやテスト観点の洗い出しに、私たち自身が開発ループへ組み込んで使っています。品質を後から足すのではなく、つくるその場で織り込む。Niohは、その手を開発のいちばん近くに置きます。
社外秘のコードを、どう守るか
buboは入力を保存しません
ツールに渡したコード・仕様・データを、buboのサーバーは保存しません。bubo自身が学習に使うこともなく、処理はその場限りです。
AIに送るか・どこへ送るかは、あなたが握ります
LLMはお手元の鍵で、あなたが選んだプロバイダを呼びます。学習に使うかどうかといったデータの規約も、あなたとプロバイダの契約のもとにあります。なお、LLMキーを使うツールは現時点でClaude・Geminiに対応しており、他プロバイダは順次対応予定です。
AIに送らず動くツールも多くあります
多くのツールは決定的な静的解析だけで完結し、LLMに渡すのは必要な場面に限られます。AIに送る範囲を、あなた自身で絞り込めます。
どう申し込み、どうつなぐのか
1. 面談を予約する
予約フォームから面談をお申し込みください。現在のQAの困りごとと、試したいツールをお聞かせいただきます。
2. 面談で適用先を一緒に決める
そろえたツールのうち、貴社の工程で効く順番をご一緒に見立てます。設定方法・つなぎ方は、この面談でお渡しします。
3. お手元のLLMで動かす
お手元のLLMの鍵（ご自身の鍵をそのまま使うこの方式を、BYOKと呼びます）を設定し、buboのMCPサーバーへ接続。普段お使いのAIクライアントから、そのままQA方法論を呼び出せます。
ベータの条件
- buboの利用料は無料です（LLMを使うツールは、ご自身が契約するLLMのAPI利用料が別途かかります。静的解析だけのツールはかかりません）。
- 面談制です。予約フォームからお申し込みのうえ、面談を経てご利用いただけます。
- 枠には限りがあります。お早めにご相談ください。
- 正式版は有料サブスクリプションでの提供を予定しています。正式版公開時にベータは終了します。
- ベータ期間中にいただいたご意見は、正式版の改善に活用させていただきます。
よくあるご質問
本当に無料ですか。あとから請求されませんか。
ベータ期間中、buboの利用料は無料です。ただしLLMを使うツールは、ご自身の鍵（BYOK）で選んだプロバイダを呼ぶため、そのLLM APIの利用料が利用者側に別途かかります（静的解析だけで完結するツールはかかりません）。buboからあとで請求することはありません。正式版は有料サブスクリプションでの提供を予定していますが、ベータがそのまま課金に切り替わることはなく、正式版公開時にベータは終了します。
入力したコードやデータは安全ですか。
渡したコード・仕様・データを、buboのサーバーは保存しません。bubo自身が学習に使うこともありません。またLLMはお手元の鍵で、あなたが選んだプロバイダを呼ぶため、学習に使うかどうかといったデータの規約は、あなたとプロバイダの契約のもとにあります。データの流れは面談で具体的にご説明します。
どのツールがAIにデータを送りますか。
ツールは大きく3種類です。（1）静的解析や集計だけで完結し外部LLMを一切呼ばないもの（テスト有効性・堅牢性・資源リーク・API互換性・トレーサビリティ など）、（2）静的解析を主に、必要に応じてLLMを併用できるもの、（3）要件レビュー・テスト設計・AI変更検証など、判断や生成にLLMを使うもの。AIに送る範囲は利用者ご自身で絞り込めます。どのツールが外部LLMに送り・送らないか、通信経路とあわせた資料は、セキュリティ審査向けに面談でお渡しします。
正式版の価格はいくらですか。
正式版は有料サブスクリプションを予定していますが、価格は現在準備中です。決まり次第お知らせします。ベータにお申し込みいただいた方には、正式版のご案内を優先的にお送りします。
ツールがたくさんありますが、どれから始めればよいですか。
面談で貴社の工程をうかがい、効く順番をご一緒に見立てます。多くの場合、上流（要件レビュー）か、AI生成物の検証から始めると効果を実感しやすいです。まずは1〜2ツールからで構いません。
途中でやめたり、ベータが終了したらどうなりますか。
いつでもご利用を停止いただけます。違約金などはありません。ベータは正式版公開時に終了しますが、その際は事前にご案内し、正式版への移行をご希望の方にはご相談に応じます。
どんな環境で使えますか。
MCP（Model Context Protocol）に対応したAIクライアントからご利用いただけます。お手元のLLMキーを設定して接続する形です。具体的な対応環境と設定手順は面談でお渡しします。