障害対応中にAIエージェント（自律的にタスクを遂行するAIアシスタント）へ調査を任せている運用チームに向けた内容です。特に本番環境のインシデント対応でAIエージェントの支援を受けているSRE・インフラ担当者は、目を通しておいて損はありません。
AIエージェントは会話の途中経過こそ覚えていても、組織固有の運用ルールは自動では蓄積しません。デプロイ基準、ランブック（障害対応の手順書）、重要度ティアの定義、命名規則の変更履歴。これらは毎回誰かが貼り付け直さない限り、エージェントの手元には存在しないままです。
何が起きるか：セッションごとに知識がリセットされる
オンコール担当者がAIエージェントに障害調査を依頼する場面を想像してください。エージェントは最初の質問に対して、もっともらしい回答を返します。
ところがその回答は、2年前に廃止された命名規則に基づいていたり、既に無効化された旧デプロイ手順を前提にしていたりします。担当者は毎回それを訂正しますが、翌日の別セッションではまた同じ訂正から始まります。
これは単発の不便さでは済みません。AIエージェントの活用が組織に広がるほど、同じ知識の手作業での再構築が組織全体で繰り返されます。導入がうまくいくほど、この「手作業の税金」が積み上がるという逆説が起きます。
影響範囲は個人の生産性だけではありません。障害対応中に誤った前提でエージェントが調査を進めると、根本原因の特定が遅れます。最悪の場合、既に無効な手順に基づいた誤った復旧アクションを提案し、二次障害を招く可能性もあります。
なぜ起きるか：組織知の置き場所がそもそもバラバラ
原因を段階的に分解していきます。
第一に、組織の運用知識はGit、社内ポータル、Confluence、チケット管理システム、Slack、そして個々人の頭の中に散らばっています。人間のエンジニアなら新規参加時に一度学習コストを払えば、あとは雑談や経験で知識を更新できます。エージェントにはその「廊下での立ち話」に相当する手段がありません。
第二に、エージェントが記憶や指示（インストラクション）を保持できても、それは「何を言われたか」の記録にすぎません。「どの基準が正式なものか」「どの例外がまだ有効か」「半年前に覆された決定は何か」といった、情報の信頼性の判断はまた別の問題です。
第三に、この問題への対処が個々のリポジトリ任せになっています。CLAUDE.mdやAGENTS.mdのようなAI向けルールファイルを各チームが独自に作成する動きは、裏を返せば「本来は共通基盤で提供すべき機能を、各チームが個別に手組みしている」状態です。ビルドスクリプトやデプロイツール、監視設定の整備で過去に起きたパターンと同じ構図です。
第四に、検索の品質にばらつきがあります。優秀なエンジニアは良質なコンテキストを集めて良い結果を得ますが、それ以外の人は検索結果の上位に出てくる、3年前の古いWikiページを参照してしまうことがあります。エージェントも同じ罠にはまります。
自分のプロジェクトが該当するか確認する
以下の観点で、自組織のAIエージェント運用が「手作業の税金」を払い続けていないか確認できます。
- リポジトリ内に
AGENTS.mdやCLAUDE.md、あるいは類似のAI向けルールファイルが存在するか。find . -name "*AGENTS*.md" -o -name "*CLAUDE*.md"のようなコマンドで横断的に確認できます - ランブックや障害対応手順書の最終更新日を確認し、AIエージェントに渡している内容と実際の運用手順が一致しているか照合します
- インシデント対応のログやチャット履歴を遡り、「エージェントの初回回答を訂正した」ケースが何回あったか数えてみます。訂正の頻度が高いほど、コンテキスト供給の仕組み化が急務です
- 複数チームでそれぞれ独自にAI向けルールファイルを作っていないか、社内の複数リポジトリを横断して確認します。重複があれば、共通基盤化の余地があります
- サービスの依存関係図、重要度ティア定義、デプロイ承認フローなどが、単一の信頼できる情報源（Single Source of Truth）に集約されているか確認します
該当項目が多いほど、AIエージェントの活用が広がった際に「手作業の税金」が急増するリスクが高いと判断できます。
対策の手順
対策は「エージェントが賢く質問する」方向ではなく、「組織側がコンテキストを供給可能な形に整える」方向で進めます。
まず、散在する運用知識の棚卸しから始めます。ランブック、デプロイ基準、重要度ティア定義、命名規則の変更履歴を一覧化し、更新日時と最新版の所在を明確にします。
次に、各チームが個別に作っているAGENTS.md相当のファイルを、共通フォーマットに統合できないか検討します。共通基盤チーム（プラットフォームチーム）がある組織であれば、このタイミングでコンテキスト供給を正式な提供機能として位置づける判断ができます。
続いて、情報の「信頼性」に階層をつけます。すべての情報を同列に扱うのではなく、「現在有効な標準」「過去の決定で既に覆されたもの」「例外的に今も有効なもの」をタグ付けし、検索結果の優先順位に反映させます。単純な全文検索やベクトル検索（意味的な類似度で文書を探す仕組み）だけでは、この信頼性の区別がつきません。
さらに、障害対応の現場では、インシデント発生時にエージェントへ渡すコンテキストのテンプレート化を進めます。サービスの依存関係、直近のデプロイ履歴、既知のフレーキーテスト（不安定で失敗しやすいテスト）といった情報を、毎回手作業で集めるのではなく、事前に整備した情報源から自動で引き渡せる形にしておきます。
最後に、運用コストの観点も無視できません。コンテキストを整備・維持する作業自体に工数がかかるため、どの情報を優先的に構造化するかは、実際の障害対応やオンコール対応での訂正頻度が高い項目から着手するのが現実的です。
まとめ
AIエージェントを本番運用やインシデント対応に組み込む際、コンテキストの手作業収集は個人の努力では解決しません。
- 障害対応中のエージェントへの訂正頻度を記録し、どの知識が繰り返し欠落しているか把握する
- リポジトリ内のAI向けルールファイルを棚卸しし、重複や陳腐化がないか確認する
- 運用知識の信頼性に階層をつけ、古い情報が検索上位に出続ける状態を解消する
- コンテキスト供給を個人の努力ではなく、共通基盤側の提供機能として位置づける
まずは自組織のインシデント対応ログを1件分見直し、エージェントへの訂正がどこで発生したかを洗い出すところから着手できます。