Agent Fit Checker（AIエージェント導入適性診断）
質問に回答すると、Agent導入の適合度（GO/CAUTION/STOP）、推奨タイプ（RAG/Tool/Browser/Workflow）、次にやるべきタスクを返します。記事AIエージェント導入チェックリスト（事故防止・完全版）に基づく診断です。
決めたい想定所要時間: 約10分カテゴリ: AI活用
このツールで決まること:AIエージェント導入をGO / CAUTION / STOP のどれにするかを決められる
判断を前提→仮説→撤退線→1枚資料まで一気通貫で回したい方は
First byte Method で回す →質問
回答済: 0/52
対象業務は明確ですか？（例：問い合わせ返信の一次案 / 月次レポート生成）
ID: O_1
対象は社内業務ですか？（顧客向けの直接出力ではない）
顧客向け直接出力はリスクが上がるため、最初は社内が安全です。
ID: O_2
API連携できる対象ですか？（ブラウザ操作しか手段がない、ではない）
ID: O_3
本番データに書き込みが必要ですか？（更新/送信/削除など）
Yesなら承認・ログ・ロールバックが必須になります。
ID: O_4
目的が1文で定義されていますか？（何のために導入するか）
ID: A_1
成功条件（どうなったら成功か）が定義されていますか？
ID: A_2
対象範囲（スコープ）が固定されていますか？（最初は1業務/1工程）
ID: A_3
入力と出力の仕様が決まっていますか？（何を受け取り、何を返すか）
ID: A_4
例外が出た時の挙動が決まっていますか？（止める/質問する/エスカレ）
ID: A_5
『やらないこと』が明文化されていますか？（禁止行為/禁止領域）
ID: A_6
成果KPIが定義されていますか？（速度/品質/コストなど）
ID: A_7
安全ガードレール（監視指標/停止条件）が定義されていますか？
例：誤送信率、例外率、苦情率、不適切出力率など
ID: A_8
改善の意思決定ルール（何を見て次を決めるか）が決まっていますか？
ID: A_9
プロンプト/方針が属人化せず運用できる見通しがありますか？
ID: A_10
参照すべき情報源（ドキュメント/DB/規約）が棚卸しされていますか？
ID: B_1
情報源にオーナー/更新日/有効期限が付いていますか？
ID: B_2
古い情報（deprecated）を廃止扱いにできる運用がありますか？
ID: B_3
矛盾が出た時の優先順位ルールがありますか？（正本優先など）
ID: B_4
出力に引用（参照箇所）を付けられますか？
ID: B_5
参照できない場合に『不明』を許容するルールがありますか？
ID: B_6
正本（SSOT）が明確ですか？（方針/辞書/契約/FAQなど）
ID: B_7
正本の更新フロー（誰が/いつ/どうレビュー）が決まっていますか？
ID: B_8
評価用の代表ケース（10〜30件）が用意できますか？
ID: B_9
出力フォーマットを固定できますか？（テンプレ/JSON）
ID: B_10
禁止表現（断定/誇大/法務/医療等）のルールがありますか？
ID: B_11
外部情報（Web検索）を使う場合のルールがありますか？（一次ソース優先など）
ID: B_12
個人情報/機密を含む情報源にアクセスしますか？
Yesの場合は法務・権限・ログが揃うまで実行系を封印推奨。
ID: B_13
ナレッジが頻繁に変わりますか？（週次以上で更新）
ID: B_14
失敗した場合に金銭的損害が起こり得ますか？
ID: C_1
失敗した場合に信用毀損（炎上/クレーム）が起こり得ますか？
ID: C_2
法務/契約/個人情報のリスクがありますか？
ID: C_3
ロールバック（戻し方）が用意できますか？
ID: C_4
dry-run（提案のみで実行しない）で開始できますか？
ID: C_5
緊急停止（Kill Switch）を用意できますか？
ID: C_6
インシデント対応手順（停止→連絡→復旧→再発防止）が用意できますか？
ID: C_7
最小権限（read/write/delete/sendの分離）ができますか？
ID: D_1
人間承認を挟む設計にできますか？（commit前にレビュー）
ID: D_2
監査ログ（誰が/いつ/何を/根拠）を残せますか？
ID: D_3
本番/検証環境を分離できますか？（dev/stg/prod）
ID: D_4
出力が外部公開/顧客送信される前に検閲できますか？
ID: D_5
エージェントの変更はレビューを通しますか？（変更管理）
ID: D_6
リリースチェックリスト運用ができますか？
ID: D_7
プロンプト/辞書/方針の正本をコード化できますか？
ID: D_8
外部APIキーや秘密情報を安全に扱う設計がありますか？
ID: D_9
監視とアラート（異常検知）を運用できますか？
ID: E_1
週次の改善レビュー（数字→原因→次の一手）を回せますか？
ID: E_2
評価データセット（代表ケース）で回帰テストできますか？
ID: E_3
例外ログを蓄積し、ルールを更新できますか？
ID: E_4
運用担当（オーナー）が明確ですか？
ID: E_5
運用ドキュメント（手順/FAQ/復旧）が用意できますか？
ID: E_6
導入初期は『実行を封印（dry-run）』する合意がありますか？
ID: E_7
社内説明（なぜこの枠組みが必要か）を用意できますか？
ID: E_8
Tip
- まずは STOP が出る条件（gating）を潰すと、設計の質が一気に上がります。
- Coverage が低い状態で GO が出ても、実務では "見落とし" が増えます（最低でも60%を目安）。
- 本番運用では、回答ログを保存して「前提が変わったら再評価」できるようにしてください。
このツールについて
前提：AIエージェントは「ミスる前提」で設計する。正本・承認・監査ログ・停止・ロールバックが揃っていない状態で実行系を出すと、事故が止められず説明できず再発防止できない形になる。
使い方：STOP 理由（gating）を先に潰すと設計の質が上がる。Coverage は最低60%を目安に。結果の推奨タイプと次タスクを実務の優先順位に使う。
解釈の注意：GO が出ても「前提が変わったら再評価」が必要。診断はスナップショットであり、組織の変化や新リスクで STOP に戻ることがある。
この判断のあと、次に整理する判断
1 つの判断は、次の判断の前提になります。次の判断軸を、関連ツールで言語化してください。
よくある質問
GO 判定が出れば、すぐに本番投入していいですか？
回答: いいえ。GO はスナップショット判定です。前提（権限・正本・ログ・停止手段）が変わったら必ず再評価してください。最初はドライラン → 影響範囲を絞った試行 → 段階拡大が原則です。
STOP が出ても押し切ってリリースする方法はありますか？
回答: 推奨しません。STOP は『事故が起きたとき止められない／説明できない／再発防止できない』状態を意味します。STOP の理由（gating）を 1 件ずつ潰すのが最短です。
Coverage が低いまま GO になりました。問題ないですか？
回答: 見落としリスクが高い状態です。最低 60% を目安にしてください。Coverage が低いまま GO すると、前提条件の認識ズレで運用後に事故が起きる典型パターンになります。
※ 上記は判断補助のための一般的な解説です。重要な意思決定は専門家への相談を推奨します。