AIエージェント時代のオブザーバビリティ設計｜ログ・権限・実行履歴で安全に運用する方法

2026.06.01AI運用

1. AIエージェント運用は「見える化」が前提になる

AIエージェントは、単に回答を返すチャットボットとは違います。社内文書を検索し、外部ツールを呼び出し、条件によってはチケットを更新し、メールの下書きを作り、ワークフローの次の処理を選びます。人間の代わりに判断と操作をつなぐ存在になるほど、企業にとっては「便利なAI」ではなく「業務システムの一部」として扱う必要があります。

そこで重要になるのが、AIエージェントのオブザーバビリティです。ここでいうオブザーバビリティとは、AIが最終的に何を答えたかだけでなく、誰の依頼で、どの権限で、何を参照し、どのツールを呼び、なぜその判断をしたのかを追える状態を指します。

Microsoftは2026年のAIエージェント活用に関する発信の中で、エージェント利用の拡大に伴い、観測、ガバナンス、セキュリティが新しい運用課題になると整理しています。Deloitteも、AIエージェントの導入が速く進む一方で、ガバナンスやリスク管理の成熟が追いつきにくい点を指摘しています。つまり、AIエージェントは作る段階から、運用中に見えるようにしておく必要があります。

2. 従来のログ設計だけでは足りない理由

一般的なWebシステムでは、リクエスト、レスポンス、エラー、ユーザーID、実行時間などをログに残します。これはAIエージェントにも必要ですが、それだけでは事故や品質劣化の原因を十分に追えません。

AIエージェントでは、同じユーザーが同じ画面から依頼しても、参照した文書、会話履歴、ツールの返り値、モデルの判断によって結果が変わります。さらに、AIの出力は途中の推論やツール選択に依存します。最終回答だけを保存しても、なぜその回答になったのか、どの情報が混ざったのか、どこで誤った判断が入ったのかを後から説明できません。

特に問題になるのは、次のような場面です。

AIが本来見られないはずの情報を回答に含めた
AIが誤ったツールを呼び出して、チケットやCRMを更新した
同じ依頼なのに日によって回答品質が大きく変わった
コストが急増したが、どの業務やプロンプトが原因か分からない
現場から「AIが変な動きをした」と言われても再現できない

こうした状況では、通常のアプリケーションログだけでは足りません。AIエージェントには、入力から出力までの行動履歴を、業務監査と改善の両方に使える形で残す設計が必要です。

3. 観測すべき5つのポイント

AIエージェントを本番運用するなら、観測対象を「回答」だけに閉じないことが大切です。入力、判断、ツール実行、出力、改善ループまでを一つの流れとして捉えます。

AIエージェントでは、入力、判断、ツール実行、出力、改善ループをつなげて観測することが重要です。

1. 入力と権限

まず残すべきなのは、誰が何を依頼したのかです。ユーザーID、所属部署、ロール、利用画面、依頼内容、添付ファイル、会話ID、実行時刻を記録します。RAGやMCP連携では、同じ質問でもユーザー権限によって参照できる情報が変わるため、権限判定の結果もログに含める必要があります。

ここで重要なのは、入力本文をそのまますべて保存すればよいわけではないことです。個人情報や機密情報を含む可能性があるため、保存範囲、マスキング、保持期間を決めておきます。ログ自体が新しい情報漏洩リスクにならないようにするためです。

2. AIの判断条件

AIエージェントがどのモデル、どのプロンプト、どの設定で動いたかも重要です。モデル名、バージョン、システムプロンプトのバージョン、温度などの生成設定、利用したナレッジベース、会話履歴の範囲を残しておけば、品質変化を追いやすくなります。

プロンプトを頻繁に改善する運用では、どのプロンプト版でどの回答が出たのかを追えないと、改善の効果を測れません。AIの挙動はコードだけでなく、プロンプト、検索対象、ツール説明にも左右されるため、これらを設定管理の対象として扱う必要があります。

3. ツール呼び出し履歴

AIエージェントの本番運用で最も重要なのがツール実行ログです。どのツールを、どの引数で呼び、どの結果が返り、その結果をAIがどう使ったのかを残します。読み取り系ツールだけでなく、更新、送信、削除に近い操作では、実行前後の差分も必要です。

たとえばCRMを更新する場合は、更新前の値、更新後の値、更新理由、人間承認の有無、承認者、実行アカウントを追えるようにします。これがないと、あとから顧客情報が変わっていたときに、AIの判断なのか、人間の操作なのか、別システムの同期なのかを切り分けられません。

4. 出力と人間レビュー

AIが最終的に返した回答、作成した下書き、送信した文面、更新した内容も当然残します。ただし、出力ログで重要なのはテキストそのものだけではありません。人間が確認したか、差し戻したか、どの理由で修正したか、ユーザーが役に立ったと評価したかまで見られると、改善につながります。

特に高リスクな業務では、AIの出力を「実行済み結果」ではなく「提案」として扱い、人間承認を挟む設計が現実的です。その場合、承認前の案と承認後の最終内容の差分を残すことで、AIが苦手なパターンを把握できます。

5. コストと品質の変化

AIエージェントは、便利になるほど利用回数が増え、モデルAPI費用や検索基盤のコストも増えます。利用回数、トークン数、ツール呼び出し回数、平均応答時間、失敗率、有人エスカレーション率を継続的に見る必要があります。

コストだけを見ると、AI活用を抑える判断になりがちです。削減時間、問い合わせ削減数、再作業率の低下など、業務効果と一緒に見れば、どのエージェントに投資すべきか、どこを軽量モデルへ切り替えるべきかが判断しやすくなります。

4. オブザーバビリティ基盤の設計ステップ

AIエージェントのオブザーバビリティは、あとからログを足すだけではうまくいきません。PoCの段階から、本番で必要になる情報を小さく取り始めるのが現実的です。

ステップ1: 業務フローを分解する

最初に、AIエージェントが担当する業務を分解します。入力、検索、判断、ツール実行、人間承認、出力、改善の流れを書き出し、各ステップで何を記録すべきかを決めます。

たとえば問い合わせ対応AIなら、質問受付、FAQ検索、回答生成、回答不能時のエスカレーション、ユーザー評価、FAQ更新までが一連の流れです。ここで「最終回答だけ残す」のではなく、検索されたFAQ、回答できなかった理由、エスカレーション先、更新すべきナレッジまで記録対象にします。

ステップ2: ログの粒度をリスクで分ける

すべての操作を同じ粒度で保存すると、ログが膨らみ、確認も難しくなります。読み取り、下書き、更新、送信、削除のように操作レベルを分け、高リスクな操作ほど詳細な証跡を残します。

読み取りだけならユーザー、検索対象、参照文書ID程度で足りることもあります。一方、外部送信やCRM更新では、実行前後の差分、承認者、実行理由、関連する会話IDまで残すべきです。

ステップ3: ログ閲覧権限を設計する

AIのログには、ユーザーの入力、社内文書、顧客情報、業務上の判断が含まれます。つまり、ログは便利な分析データであると同時に、機密データの集合体でもあります。

運用担当者なら全ログを見られる、という設計は危険です。業務部門、情報システム部門、セキュリティ担当、経営層で見える範囲を分け、個人情報や本文はマスキングした集計ビューを用意します。監査目的の詳細ログと、改善目的の集計ログを分けると扱いやすくなります。

ステップ4: 失敗を改善タスクに変える

ログは保存するだけでは意味がありません。回答不能、誤回答、ツール実行失敗、承認差し戻し、コスト急増を定期的に見て、改善タスクへ変換する運用が必要です。

週次で「失敗理由トップ10」を見れば、ナレッジ不足、プロンプト不備、権限設計の問題、UIの分かりにくさが見えてきます。AIエージェントの品質は、モデルを変えるだけでなく、データ、業務フロー、承認条件を直すことで改善します。

5. 運用で見るべき指標とアラート

AIエージェントの運用では、技術指標、業務指標、安全指標を分けて見ると整理しやすくなります。

分類	見るべき指標	判断に使うポイント
技術	応答時間、エラー率、ツール呼び出し失敗率、トークン数	遅延やコスト増の原因を見つける
業務	利用回数、削減時間、有人エスカレーション率、再作業率	AIが業務成果に貢献しているかを見る
品質	ユーザー評価、承認差し戻し率、誤回答報告数	改善すべきプロンプトやデータを特定する
安全	権限拒否回数、危険操作の承認待ち件数、外部送信件数	不適切な利用や設定ミスを早く見つける