AIエージェントを本番で任せる前の10問｜受入基準・責任分担・採算チェック

AIエージェントが一度うまく動くと、「このまま本番でも任せられるのでは」と考えたくなります。

ただ、デモで動くことと、業務として任せられることは別です。本番では、失敗したときに止められるか、結果を証拠で確認できるか、誰が責任と費用を持つかまで決める必要があります。

この記事では、ユーザー企業のIT企画・調達と、SIerのPM・アーキテクト・品質責任者が、PoCから読み取り専用、限定的な書き換え、本番運用のどこまで進めるかを判断するための10問をまとめます。

結論はシンプルです。AIに任せる前に、「止められる・測れる・責任と費用を分けられる」を確認します。

この10問は、法務・セキュリティ審査や個別契約の代わりではありません。業種、データ、利用国、システムの重要度に合わせて調整してください。NISTなど特定規格への準拠を証明するものでも、すべての案件にそのまま使える万能チェックリストでもありません。

先に決める3つの判定

10問に答える前に、今回の判断を次の3段階へ分けます。

判定	進めてよい状態
本番の書き換えへ進む	完了条件、権限、停止方法、責任分担が決まり、証拠を再現できる
読み取り専用・限定PoCを続ける	評価、データの鮮度、監視、変更管理に弱い点が残る
保留する	採算、継続条件、撤退方法を説明できない

1つの合計点で決めないことが大切です。権限や停止方法が未定なのに、精度や価格の高得点で相殺してはいけません。

コピペ用：AIを任せる前の10問

会議メモ、RFP、受入表へそのまま貼り付けられる形です。最初に記入者・承認者・今回の判断目的を決め、各問には「回答」「確認済み証拠」「未取得の証拠」「適用」「残る条件」まで記録します。分からない項目は空欄や0にせず、「未判定」「未取得」と明示します。

案件名：
対象業務：
記入者：
承認者：
今回の判断目的：
今回判断する段階：PoC / 読み取り専用 / 限定書き換え / 本番
確認日：
次回見直し日：

1. 完了条件と対象外は何か
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

2. AIの説明ではなく、実際の結果をどう評価するか
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

3. データの出典・版・鮮度・欠損をどう確認するか
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

4. AIはどのIDで、どの操作までできるか
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

5. 何を監視し、誰が異常を判断するか
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

6. 失敗時にどう停止・引継ぎ・復旧するか
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

7. ユーザー企業・SIer・AIサービス間の責任をどう分けるか
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

8. モデル・プロンプト・ツール変更後に何を再検証するか
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

9. 人の確認と失敗対応を含む総コストはいくらか
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

10. 継続・拡大・停止をいつ何で決めるか
回答・対象範囲：
担当：
確認済み証拠（ID・版・確認日）：
必要な証拠 / 未取得：
適用：対象 / 対象外 / 未判定
対象外の理由：
判定：可 / 条件付き / 不可 / 未判定
残る条件・次の一手：
対応担当：
期限：

総合判定：本番の書き換えへ進む / 読み取り専用・限定PoCを続ける / 保留
決定者：
次に許可する段階：
開始条件：
再評価日：

以下で、各問の意味と証拠の例を説明します。

1. 完了条件と対象外は何か

AIへ「チケットを処理して」と頼むだけでは、完了の意味が曖昧です。調査、回答案の保存、状態変更、顧客への送信では、必要な権限とリスクが違います。

主な担当：業務責任者
必要な証拠：開始状態、期待する最終状態、成果物、禁止操作を並べた受入表
該当なし：原則なし。どの業務にも完了条件は必要
確認例：「回答案を下書き保存」まで。送信とチケット完了は対象外

ワークフローと自律的なAIエージェントを分け、必要な複雑さだけを選びます。単純な手順で済むなら、最初から高い自律性を持たせる必要はありません。

2. AIの説明ではなく、実際の結果をどう評価するか

「完了しました」という返答だけでは、業務の完了を証明できません。保存先、チケット状態、作成ファイル、テスト結果など、環境に残った結果で確認します。

主な担当：品質責任者・業務責任者
必要な証拠：期待結果と実結果の比較、代表ケース、失敗ケース、再実行結果
該当なし：出力を業務判断・顧客対応・成果物へ一切使わない私的な試用だけ。助言や下書きでも業務に使うなら評価対象
確認例：20件の代表ケースで正答だけでなく、禁止操作が0件かも確認

評価では、正解率だけでなく、安定して成功するか、危険な誤操作をしないかを分けて見ます。モデル自身の自己採点だけに頼りません。会話の助言でも業務判断へ使う場合は、誤答、根拠の欠落、危険な助言を固定ケースで確認します。

3. データの出典・版・鮮度・欠損をどう確認するか

AIが正しい手順で答えても、参照データが古ければ結果は誤ります。「データがない」と「0件」も別です。

主な担当：データ責任者
必要な証拠：出典、取得時刻、版、更新間隔、欠損時の表示
該当なし：外部・社内データを参照しない固定処理
確認例：規程名、版、施行日、引用箇所を回答と一緒に保存

RAGを使う場合は、RAGの精度が上がらない7つの原因も確認すると、検索・生成・権限・鮮度を分けて評価できます。

4. AIはどのIDで、どの操作までできるか

人の管理者アカウントをそのまま渡すと、誰が何をしたか分からなくなります。AI専用のIDと、操作単位の許可が必要です。

主な担当：システム責任者・情報セキュリティ
必要な証拠：ID、権限一覧、許可ツール、対象環境、監査ログ
該当なし：外部システムへ接続しない場合
確認例：読み取りと下書き保存だけ許可。mainへの反映、本番公開、顧客送信は禁止

権限、承認、監査ログの設計はAIエージェントのセキュリティ設計で詳しく整理しています。

5. 何を監視し、誰が異常を判断するか

動作回数だけでは品質を判断できません。失敗、やり直し、人への引継ぎ、処理時間、費用を追います。

主な担当：運用責任者
必要な証拠：監視項目、基準値、通知先、一次対応者、対応期限
該当なし：一度限りのオフライン評価で本番利用しない場合
確認例：失敗率、引継ぎ率、重大な禁止操作、1件当たり費用を日次確認

公開後の監視も評価の一部です。PoC時点の数字だけで、長期運用を保証しません。

6. 失敗時にどう停止・引継ぎ・復旧するか

再試行を増やすと、同じ書き換えや送信を重複させることがあります。停止、再読取、人への引継ぎ、元に戻す方法を先に決めます。

主な担当：運用責任者・システム責任者
必要な証拠：停止手順、再試行上限、重複防止キー、復旧手順、訓練結果
該当なし：外部接続がなく、繰り返し自動実行もしない一度限りの私的試用だけ。読み取り専用でも、実行を繰り返すなら停止・再試行上限・引継ぎは必要
確認例：書き換え後に応答が途切れたら、再送前に対象を再読取する

生成AIのPoCが本番導入で止まる7つの理由では、例外処理や運用設計を含めて本番化条件を確認できます。

7. ユーザー企業・SIer・AIサービス間の責任をどう分けるか

AIサービスの提供者、システムを構築するSIer、業務判断をするユーザー企業では、管理できる範囲が違います。

主な担当：契約責任者・業務責任者
必要な証拠：役割分担表、承認者、障害連絡、データ・知財・損害の契約条項
該当なし：原則なし。社内開発でも部門間の責任分担は必要
確認例：AIサービスは契約で定めた提供範囲、SIerは統合・試験・一次対応、ユーザー企業は期待値と最終業務判断を担当。契約確認前に損害責任まで断定しない

製品比較と契約条件をつなぐには、生成AIベンダーの選び方の質問票も利用できます。

8. モデル・プロンプト・ツール変更後に何を再検証するか

本番開始後も、モデル、指示、参照データ、接続ツールは変わります。初回だけ合格しても、変更後の品質は保証されません。

主な担当：変更管理責任者・品質責任者
必要な証拠：変更履歴、固定評価セット、回帰テスト、段階反映、戻す条件
該当なし：変更しない期間限定の検証
確認例：モデル版を変えたら、成功例だけでなく過去の失敗例も再実行

評価質問は重複を避け、1つの問いで1つの判定をするようにします。まずルールで判定できる項目を検査し、主観評価が必要な箇所だけ人が確認します。

9. 人の確認と失敗対応を含む総コストはいくらか

API料金が安くても、レビュー、例外処理、データ整備、監視が増えれば採算は悪化します。

主な担当：サービス責任者・経理・SIerの案件責任者
必要な証拠：初期費用、固定費、従量費、人の確認時間、失敗対応、保守、移行費
該当なし：原則なし。無償の短期検証でも、人の準備・確認・失敗対応時間は「未取得」または仮定付きで記録
確認例：1件当たりのモデル費用に、レビュー時間と失敗時の再処理費を加える

測り方は生成AIの費用対効果はどう測る？で、価値・利用・品質・総コストの4層に分けています。

10. 継続・拡大・停止をいつ何で決めるか

始める条件だけでなく、続ける条件と止める条件を決めます。評価日を置かなければ、効果が曖昧なまま運用費だけが残りやすくなります。

主な担当：事業責任者
必要な証拠：基準値、目標、最低条件、評価日、撤退・移行手順
該当なし：原則なし。短期PoCでも終了判定は必要
確認例：必要な証拠がそろう最短の評価日を置き、品質、利用、総コストを比較する。90日は本番影響がある案件の一例で、待機義務ではない

社内決裁へ進める場合は、生成AI導入の稟議書テンプレートへ、この10問の未決事項と証拠を引き継げます。

MetaのSecond BrainをSIerへ転用すると何が変わるか

既存の10問は導入前の判断には使えますが、「AIを継続的に改善するとき、誰がどの証拠で変更を受け入れるのか」まで具体化するには、変更管理の観点を補う必要があります。

Metaの公式Engineering Blog「An Organizational Second Brain: Building an AI That Learns From Experts」は、専門家の知識を構造化したファイル、知識と推論手順の分離、変更ごとの評価ゲート、専門家のフィードバックを回帰テストへ戻す改善ループを組み合わせています。ポイントは、AIが自分で賢くなることではありません。変更を最小の差分にし、元の失敗ケースを再生し、他のケースを壊していないことを確認してから、人が承認することです。

これをSIer案件へ転用するなら、次の4点を一体で設計します。

契約・スコープ：学習対象を「モデル」ではなく、承認済みの知識ファイル・手順・評価ケースの更新として定義します。PoC契約には対象業務、参照可能な情報、変更可能な成果物、受入条件を記載し、顧客固有データを無断で次案件へ再利用しません。
責任分界・承認：ユーザー企業の業務責任者は正しい業務判断と例外を承認し、SIerは原因分析、最小差分、回帰結果、監査証跡を提示します。AIサービス提供者の責任と、SIerが構築した知識・手順層の責任を混同しません。
既存運用・切り戻し：変更ごとに元の失敗ケースを再生し、固定した回帰セットを通します。不合格なら前版の知識・手順へ切り戻し、障害時は人の運用へ引き継げる状態を残します。
費用・納期：初期構築費だけでなく、専門家レビュー、評価ケース追加、回帰実行、監査、切り戻し訓練の工数を見積もります。改善頻度を上げるほど評価費用も増えるため、変更1件当たりの総コストとリードタイムを追います。

この設計にすると、問2の「実結果」、問6の「復旧」、問7の「責任」、問8の「変更後の再検証」が一本の変更管理フローになります。記事の10問は導入前チェックだけでなく、変更PRごとの受入テンプレートとして使えます。

そのまま転用できない条件

Metaの事例を、そのまま一般的なSIer案件の成功保証にはできません。Metaと同じ組織規模、専任の専門家・評価基盤、内製権限、文書構造、反復頻度を前提にしないことが重要です。顧客ごとに契約、機密区分、データ持ち出し条件、再委託先、既存の変更審査が異なるため、次の条件がそろわない場合は適用範囲を狭めます。

正解や許容範囲を承認できる業務責任者がいない
過去の失敗ケースを匿名化し、評価用に再利用する契約上の許可がない
知識、手順、モデル、接続ツールのどこが変わったかを版管理できない
回帰テストと人のレビュー費用を保守契約へ含められない
失敗時に前版へ戻す権限と運用手順がない

この場合は、自動改善をうたわず、読み取り専用の助言、固定版の知識、都度の人手承認から始めます。Metaが報告した結果は同社の条件下の実績であり、案件の効果見積もりには自社の代表ケースと実測工数を使います。

読者の判断チェックリスト

[ ] 改善対象を、知識・推論手順・モデル・ツールのどれかに切り分けられる
[ ] 元の失敗を再現するケースと、壊してはいけない回帰ケースがある
[ ] 顧客、SIer、AIサービス提供者の承認・障害対応責任が契約上分かれている
[ ] 変更前後の差分、評価結果、承認者、反映時刻を監査できる
[ ] 不合格時に前版へ切り戻し、人の運用へ引き継げる
[ ] 専門家レビューと回帰実行を含む費用・納期で採算を判断している

1つでも未決なら、全面的な本番適用ではなく、対象業務・権限・件数を限定して証拠を集めます。

4つの確認ゲート

10問を埋めたら、次の順で判断します。

ゲート1：本番の書き換えを止める条件

次のどれかが未決なら、本番の書き換えへ進めません。

問1：完了条件と対象外
問4：IDと操作権限
問6：停止・引継ぎ・復旧
問7：責任分担

まず読み取り専用か、隔離した環境へ戻します。

ゲート2：評価を続ける条件

問2、問3、問5、問8の証拠が弱い場合は、成功と断定せず、限定PoCを続けます。

ゲート3：採算判断を保留する条件

問9と問10が埋まっていなければ、技術的に動いても商用化・全社展開は保留します。

ゲート4：すべて合格しても段階的に広げる

最初は対象業務、利用者、権限、件数を限定します。重大な失敗がないことと、実際の業務価値を確認してから範囲を広げます。

SIer案件の記入例：障害チケットの一次整理

架空の例です。導入実績や事故統計ではありません。

対象業務

監視システムから届く障害チケットを読み、過去の手順書を参照し、原因候補と確認手順を下書きします。

許可すること

チケットと許可済み手順書の読み取り
原因候補と確認手順の下書き
隔離ブランチでの修正案作成
テストの実行
証拠ログの保存

禁止すること

チケットを完了状態へ変更する
顧客へ連絡する
mainへ統合する
本番へ反映する
認証情報や支払い情報を変更する

10問の要約

問い	担当	回答・対象範囲	確認済み証拠	適用	判定	残る条件・担当・期限
1 完了条件	運用PM	原因候補と確認手順の下書きまで。送信・完了操作は禁止	未取得（SAMPLE-A01受入表案）	対象	条件付き	期待出力30件を確定／運用PM／評価開始前
2 実結果	QA	通常20件・境界10件で誤答、根拠、禁止操作を別判定	未取得（SAMPLE-A02評価案）	対象	未判定	基準確定後に実行／QA／試験前
3 データ	手順書責任者	匿名化、固定版、施行日、不明資料の保留を確認	未取得（SAMPLE-A03入力一覧案）	対象	条件付き	匿名化と利用権の証拠／データ担当／試験前
4 権限	基盤担当	読み取りと指定下書き先だけ。顧客送信・main・本番は禁止	未取得（SAMPLE-A04設定案）	対象	条件付き	境界拒否テスト／基盤担当／接続前
5 監視	運用責任者	成功・失敗・不明、再試行、人の確認時間をケース別記録	未取得（SAMPLE-A05台帳案）	対象	未判定	評価ログを取得／運用担当／30件評価時
6 復旧	基盤担当	ケース別上限、停止、結果不明時の再読取、引継ぎを訓練	未取得（SAMPLE-A06訓練案）	対象	条件付き	timeout・重複試験／基盤担当／自動実行前
7 責任	契約担当	A社は期待値と採用、SIerは統合・試験。提供者責任は契約確認後	未取得（SAMPLE-A07分担案）	対象	条件付き	本番責任と障害連絡を合意／契約担当／本番判断前
8 変更	QA	入力・指示・ツール版を固定し、同じ30件で前後比較	未取得（SAMPLE-A08版管理案）	対象	条件付き	固定版とrollback条件／QA／試験前
9 総コスト	案件責任者	架空試算：確認2時間＋準備2時間＝計16,000円、契約配賦は未取得	未取得（SAMPLE-A09試算案）	対象	未判定	実時間と費用上限／事業担当／採算判断前
10 継続判断	事業責任者	30件評価で次段階を判断。重大禁止操作・架空出典時は停止	未取得（SAMPLE-A10判断案）	対象	条件付き	閾値を事前確定／業務担当／評価開始前

この架空例の総合判定は「準備のみ可」です。本番利用は未承認です。決定者はA社運用責任者、次に許可する段階は固定データでのオフライン評価、開始条件は匿名化と30件の期待出力・停止基準の確定です。証拠がそろえば評価を開始し、日数を消化するためだけに待ちません。

この例では、匿名化、30件の期待出力、停止基準を確定してから、固定データでの評価を開始できます。本番展開には、問2・問5の評価・監視証拠、問7の責任合意を含むすべての未決条件を解消する必要があります。固定価格化は、それに加えて問9・問10の実測コストと継続条件がそろってから判断します。

90日で段階的に確かめる

以下は本番へ影響する案件の期間例です。固定データでの机上評価は当日から始められ、各ゲートの証拠がそろえば前倒しで次の判断へ進めます。反対に重大な欠点があれば、日数に関係なく停止します。90日を必須の待機期間にはしません。

1〜2週：オフライン評価

過去のチケットや架空データで、正常例と失敗例を確認します。外部システムへ書き換えません。

3〜4週：読み取り専用の並行運転

人の処理と並べ、結果の一致、見落とし、人への引継ぎを測ります。

5〜8週：隔離環境で限定的に書き換える

AI専用ID、操作単位の権限、承認、監査ログ、停止手順を実機で確認します。

9〜12週：限定した本番で判断する

対象業務と件数を絞り、品質、利用、総コスト、失敗の重大度を基準値と比較します。評価日に継続・修正・停止を決めます。

この10問と既存記事の使い分け

PoC全体の進め方を確認する： PoCが本番導入で止まる7つの理由
データ検索の品質を掘る： RAGの精度が上がらない7つの原因
権限・承認・監査を設計する： AIエージェントのセキュリティ設計
総コストと効果を測る：生成AIのROI・KPIの作り方
製品・契約を比較する：生成AIベンダーの選び方
決裁資料へまとめる：生成AI導入の稟議書テンプレート

この記事は、それらを置き換えるものではありません。案件を次の段階へ進める前に、未決事項と証拠を1枚で確認する入口です。

出典と更新情報

Meta Engineering, An Organizational Second Brain: Building an AI That Learns From Experts, 2026年9月2日公開、2026年9月17日確認
Anthropic, Building effective agents, 2024年12月19日公開、2026年9月6日確認
Anthropic, Demystifying evals for AI agents, 2026年1月9日公開、2026年9月6日確認
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), 2024年7月26日公開・2026年4月8日ページ更新、2026年9月6日確認
Google Developers, Rules of Machine Learning, 2025年8月25日更新、2026年9月6日確認
経済産業省, AIの利用・開発に関する契約チェックリスト, 2025年2月18日公開、2026年9月6日確認
promptfoo, promptfoo repository, MIT License、2026年9月6日確認。評価質問を原子的にする設計と、外部API不要のecho providerによるsmoke testを参照。本記事ではツール自体は導入していません。

版：1.3／更新日：2026年9月17日

10問がすべて「可」になること自体が目的ではありません。未決事項を見つけ、安全な範囲へ戻し、次の判断に必要な証拠をそろえることが目的です。