AIエージェントの本番運用前に確認したい5項目｜評価・権限・コストの設計

2026年秋の公式発表から考える運用設計

GitHubが10月1日に公開した9月分の更新情報では、定期タスクの自動実行や、レビュー指摘・失敗したチェックへの対応を進めるagent mergeがプレビュー機能として紹介されています。9月22日には、Copilotアプリの実行過程をOpenTelemetryで監視する機能も発表されました。

これらは製品個別の発表ですが、実装を任せる範囲が広がるほど、実行後の検証と追跡が必要になると考えられます。以下は公式情報を踏まえた設計例です。当社の導入実績や実測結果を示すものではありません。

1. 「何をもって完了か」をシステムの状態で決める

たとえば「問い合わせを処理する」という指示だけでは、返信文の作成、送信、顧客台帳の更新のどこまで任せるかが曖昧です。最初は「問い合わせ内容と社内FAQを参照し、根拠付きの返信案をチケットに保存する」までに絞ると、確認すべき成果物が明確になります。

Anthropicの2026年1月9日の評価解説は、エージェントの発言と実際に残った結果を区別しています。業務でも「保存しました」という応答だけで成功にせず、対象チケットに返信案が存在するか、参照したFAQが正しいかを確認する設計が必要です。

• 入力条件：問い合わせID、利用できる資料、資料の更新日を指定する。
• 完了条件：正しいチケットに、必要項目を満たす返信案が1件保存される。
• 停止条件：本人確認や契約情報が不足する場合は、担当者へ引き継ぐ。
• 対象外：返信案の作成だけを任せる段階では、送信や返金処理は実行させない。

2. 正常時と例外時を同じ評価セットで試す

評価は、回答が自然かどうかに加え、業務の条件を守ったかを調べます。よくある質問、FAQに答えがない質問、矛盾する資料、権限不足、外部APIのタイムアウトなど、実際に起こり得る状況を用意しましょう。個人情報は匿名化し、更新や送信はテスト環境で確認します。

採点項目は「正しい回答」と「誤った操作をしないこと」を分けます。問い合わせへの回答率だけを高めると、根拠のない回答まで成功に数えるおそれがあります。引き継ぐべきケースで正しく停止した割合も確認します。

同じ条件でも結果が変わるため、代表ケースは複数回実行し、各回の成功・失敗を残します。モデルや指示文、検索設定を変更したら、同じケースで変更前後を比較します。採点基準自体が曖昧なら、まず担当者同士で合否の判断をそろえるところから始めます。

3. ツール権限を業務単位に絞る

MCPはAIと外部ツールを接続するための共通仕様です。2026年7月28日の仕様公開では、認可サーバーの識別子検証など、認可に関する強化が説明されています。接続基盤を更新するときは、利用するクライアントとサーバーの対応版を確認してください。

業務側でも、読み取り、下書き保存、外部送信を別の操作として設計します。問い合わせ対応用の認証情報には、必要なチケットへのアクセスだけを与えます。「送信しないで」と指示するだけでなく、ツールやAPI側でも実行できない状態にします。

将来、送信まで自動化する場合は、宛先、対象データ、送信数などの許容範囲を定義します。範囲外の依頼は停止させ、顧客の文章や検索結果に書かれた指示によって権限が広がらないかも試します。これらはアプリ側で確認すべき業務ルールです。

4. 実行ログから原因を追えるようにする

GitHubの9月22日の発表では、OpenTelemetryを使ってモデルへの要求やツール利用を追跡できると説明されています。プロンプトと応答の本文は標準では収集対象に含まれません。監視のために、必ず全文を保存する必要があるわけではありません。

自社の仕組みでは、1回の処理に実行IDを付け、問い合わせID、モデルと設定の版、使ったツール、所要時間、結果、引き継ぎ理由を関連付けます。これにより、資料が古かったのか、検索で見つからなかったのか、保存APIが失敗したのかを切り分けやすくなります。

ログにはAPIキーを含めず、顧客情報は必要な範囲に限定します。閲覧権限と保存期間を決め、検証に使う記録にも同じ扱いを適用します。

5. 費用の上限と再実行時の動きを決める

GitHubの9月2日の技術記事は、ツール出力を短くしても、情報不足による再取得が増えるとタスク全体の費用が高くなる場合を報告しています。これは同社の評価条件における結果ですが、1回の呼び出しだけで費用を判断しないという観点は実務でも使えます。

確認したいのは、成功1件あたりの総費用と完了までの時間です。失敗や再試行の費用も含め、集計期間の総費用を成功件数で割って確認します。成功件数がゼロなら値を出さず、失敗として扱います。人が修正する時間は別に記録すると、業務全体の負担を判断できます。

タイムアウトは、処理が実行されなかった証拠にはなりません。保存APIの応答だけが失われた場合、単純な再試行で下書きが重複する可能性があります。問い合わせIDと処理の種類などから重複を判定するキーを作り、再実行前に保存済みかを確かめます。

• 上限：1件あたりの処理時間、ツール呼び出し数、費用に上限を置く。
• 再試行：一時的な障害に限定し、回数を制限する。権限不足は繰り返さない。
• 復旧：途中までの状態を記録し、未完了の工程から再開できるようにする。
• 停止：連続失敗や重複を検知したときの通知先と、実行を止める担当者を決める。

最初の運用レビューで見る指標

小さく始めるなら、返信案の作成までを対象にし、業務担当者が成果物を確認できる形で試します。次の指標を週次など一定の間隔で確認し、原因が多いところから資料、ツール、指示文を改善します。数値目標は業務の影響と現状の処理水準に合わせて決めます。

• 品質：条件を満たした完了件数、誤った回答、担当者による修正時間。
• 制御：権限外の操作を拒否できたか、必要なケースで引き継げたか。
• 効率：成功1件あたりの総費用、完了時間、再試行回数。
• 運用：重複登録や処理漏れ、復旧にかかった時間。