AIエージェントのコンテキスト管理とは？
AIエージェントのコンテキスト管理とは、既存のアクセス権の範囲内で、エージェントが仕事に使う情報を選び、整理し、更新することです。チームにとって、その情報はコード、共有受信箱、チームのチャネル、そして意思決定の記録に存在します。いずれも、正確さを保ち、必要な人が参照できる状態にしておく必要があります。
共通理解は、コンテキストの共有から始まります。対話を通じて深まり、具体的な成果物によって行動に結びつき、定期的なメンテナンスによって役立ち続けます。
まずは一つのワークフローから始めます。信頼できる情報源を特定し、現在のタスクに必要な情報だけを取り出して、根拠へのリンクを含む要約を作ります。決定事項と提案は区別します。リリース、顧客からの新情報、アクセス権の変更で内容が古くなったら、要約を更新します。
1. AIエージェントが参照する共有コンテキストを把握する
どのチームにも、知識や意思決定の記録が複数の場所に分散して存在します。エージェントを導入する最初の一歩は、その記録がどこにあるかを把握することです。
エージェントのコンテキストウィンドウには、現在のタスクで利用できる情報が入ります。AIエージェントのメモリは、後で取り出すための情報を保持します。共有コンテキストは、チームが使うさまざまなツールにまたがる知識です。有用なコンテキスト管理の仕組みは、タスクごとに関連する情報を選び、元の情報源へのリンクを残します。
こうした情報の選択と維持は、コンテキストエンジニアリングとも呼ばれます。Anthropicのコンテキストエンジニアリングガイドでは、必要なときに情報を取得し、古い内容を要約して、エージェントが扱うコンテキストを絞り込む方法を説明しています。チームでは、今の意思決定にどの根拠が役立つかが判断の軸になります。
プロダクトチームにとって、コードは重要なコンテキストの情報源です。デプロイやリリースの記録と組み合わせることで、製品が現在どのように動作するかを確認できます。共有受信箱には、顧客の質問、直面している問題、達成したいことという別の視点があります。チームのチャネルには、議論、制約、約束、意思決定の理由が残されています。
それぞれの情報源が答える問いは異なります。コードは実装を説明し、デプロイの情報はそれが顧客に届いているかを示します。顧客との会話は実際の利用体験を明らかにし、社内の議論は特定の方針を選んだ理由を理解する手がかりになります。
エージェントには、各情報源に何があり、どの問いに答えられ、誰が管理し、どの程度新しいかを示す一覧が必要です。この一覧が、有用な協働のための初期コンテキストになります。
情報源同士の食い違いも認識する必要があります。チャネルのメッセージではリリース予定が説明されていても、デプロイの記録では未実施かもしれません。ドキュメントが古い製品バージョンを説明している場合もあります。こうした違いを見えるようにすることで、チームは正確な状況認識から仕事を始められます。
図1。コード、顧客との会話、チームの議論は、それぞれ異なる視点を提供します。エージェントは各人の既存のアクセス権の範囲内で根拠を結びつけ、チームが使える成果物を作成します。
2. AIエージェントのアクセス権を情報源側で管理する
共有コンテキストにもアクセスの境界があります。チームメンバーの責任はそれぞれ異なり、参照できる情報もその責任に応じている必要があります。
権限は、コンテキストを保存し、取得するシステムが管理するものです。誰が情報にアクセスできるかは、組織のID管理システム、情報源となるアプリケーション、メモリの保存先が決めるべきです。エージェントはその境界の中で動作し、個人のアクセス権を独自に判断しません。
Okouのチームで共有できるエージェントも、この分離に基づいています。チームで指示やワークフローを共有しながら、各人が自分の接続済みアカウントを通じて実行できます。
この区別は、コンテキストを別の形式に変換するときに重要です。閲覧が制限された会話から作る要約にも、適切な制限を引き継ぐ必要があります。情報をメモリに保存したり、図などの成果物に組み込んだりする場合も、元のアクセス要件を維持しなければなりません。
個人のコンテキストにも、明確な範囲が必要です。私的なメモ、好み、会話は、権限のある手続きを通じて意図的に共有されない限り、その本人にひもづけておくべきです。
つまり、チームは同じ目標を共有していても、メンバーが参照できる情報は異なる場合があります。エージェントの役割は、各人が利用できるコンテキストを使って貢献できるよう支援することです。必要な根拠にアクセスできない場合は、理解のどの部分が未確認なのかを明示する必要があります。
3. AIエージェントで共通理解を育てる
適切な情報源にアクセスできるようになれば、エージェントは、それらが仕事とどう関係するのかを人々が理解する手助けをできます。
人の注意力とワーキングメモリには限界があります。追っている会話が違えば、同じ状況に対する解釈も異なります。開発チームは実装上の制約を理解し、サポートは繰り返される顧客の問題を把握し、プロダクトチームは過去の意思決定で何を優先したかを覚えています。
エージェントは、これらの視点を結びつけ、その意味を説明できます。
たとえば、顧客が製品に同僚を招待する際に困っているとします。共有受信箱には問題の説明があり、コードとリリースの記録からは現在の招待機能の動作を確認できます。チームのチャネルには、招待対象を制限するルールの理由が残っているかもしれません。
エージェントはこれらの根拠をまとめ、顧客が何に直面し、製品がどう動作し、どの意思決定がその動作につながったかを一貫した説明にできます。そのうえで、相手に合った説明を用意できます。
開発チームには再現手順と問題のある動作の根拠が必要です。サポートには正確な説明と、確認済みの回避策があればその内容が必要です。プロダクトチームには顧客への影響と選択肢の理解が必要です。どの説明も、同じ基礎的な事実に根ざしていなければなりません。
会話をまたいで経緯を保ち、依存関係を明らかにし、参加者自身も気づいていない前提を見つけることは、仕事の調整の大きな部分を占めます。
Slackで議論している場合、同じスレッドで動作するエージェントなら、依頼、根拠、その後の対応を参加者が参照できる状態に保てます。
エージェントは、観察した事実、解釈、意思決定を区別する必要があります。似た顧客の訴えから傾向が見えても、原因は引き続き調査が必要かもしれません。有望な解決案でも、効果はまだ不明な場合があります。その区別を明確にすることが、次の行動を選ぶ助けになります。
4. 人が目標と関係づくりに集中できるようにする
コンテキストの収集や説明をエージェントがより多く担うことで、人は方向性、判断、人との関係に注意を向けやすくなります。
何を大切な成果とするかを決めるのは人です。競合する優先事項を比較し、約束をし、同僚や顧客との信頼を築きます。また、記録されていない事情も理解しています。たとえば、慎重な対応が必要な顧客との関係、非公式の合意、まだうまく言葉になっていない懸念などです。
エージェントは、その判断の準備を支援できます。話し合いの前に関連する経緯をまとめ、未解決の問いを洗い出し、選択肢ごとの影響を説明できます。仕事が進む中では、約束に影響する変更や依存関係を知らせることもできます。
提示する情報量は、会話の目的に合わせるべきです。顧客との通話では、問題と既存の約束を簡潔に把握できれば十分な場合があります。技術レビューでは、実装の詳細と再現の根拠が必要でしょう。経営層との議論では、事業への影響と判断が必要な事項が中心になります。
よいコンテキスト管理は、お互いを理解するための負担を減らします。十分な背景知識を共有した状態で会話に入り、重要なことを話すために時間を使えるようにするのです。
5. 意思決定と引き継ぎを見える形にする
具体的な成果物があると、チームはそれを見ながら確認し、議論し、修正できます。
形式は、解決したいコミュニケーション上の問題に合わせます。ワークフロー図は不明確な依存関係を明らかにできます。注釈付きの画面は、顧客がどこでつまずくかを示せます。比較表は選択肢ごとの影響を整理し、タイムラインは、あるチームの約束が別のチームの仕事にどう影響するかを示します。
招待機能の問題なら、注釈付きのカスタマージャーニーで、現在の手順、分かりにくい箇所、顧客から得た根拠、変更案を示せます。現在の動作、提案する動作、未解決の問いは、明確に区別して表示します。
同じ成果物を複数の話し合いに活用できます。サポートは顧客体験を正しく表しているかを確認し、開発チームは製品の動作を検証し、プロダクトチームは変更案が根本的な問題に対応しているかを判断できます。
意思決定のための資料には、結論に至った理由も残すべきです。有用な比較には、検討した選択肢、重要だった制約、各案の前提、最終的な選択の理由が含まれます。
引き継ぎにも同じ明確さが役立ちます。次の担当者が、何が完了し、何が検証され、何が未解決で、関連資料がどこにあり、次にどの行動を求められているかを把握できるようにします。
エージェントは、仕事の変化に合わせて、これらの成果物と元の根拠の整合性を保つことができます。
6. AIエージェントのメモリとコンテキストを保守する
情報の状態や新しさが不明確になると、コンテキストの価値は下がります。
製品は進化し、優先順位は変わり、意思決定は見直されます。根本的な問題が解決した後も、一時的な回避策が使われ続けることがあります。提案が、いつの間にか承認済みの決定として扱われることもあります。正確だった要約も、状況が変わると誤解を招くようになります。
有用なコンテキストの仕組みは、事実、前提、提案、決定、過去の記録を区別します。それぞれに必要な保守は異なります。事実は状況が変われば更新し、前提は検証し、提案には状態を明示します。決定には、その理由と後から行われた変更を残す必要があります。
定期的な保守では、重複をまとめ、矛盾を指摘し、利用中の要約を更新し、現在の仕事の指針ではなくなった資料をアーカイブします。過去の根拠は参照可能な状態を保ち、置き換えられた指針は明確に示します。
重要な出来事に応じた更新も必要です。リリースによって製品の案内が古くなったり、目標の変更によって必要な情報が変わったり、新たな決定が以前の計画に取って代わったりします。情報源のアクセス権が変わった場合は、そこから派生したコンテキストの保存方法や取得方法にも反映する必要があります。
チームメンバーは、エージェントの理解を簡単に修正できるべきです。古い記述を指摘したり、信頼すべき情報源を示したり、ある議論は決定には至らなかったと伝えたりできるようにします。そうした修正は、適切な個人または共有の範囲内で、その後の仕事に反映される必要があります。
図2。目標を設定するのは人です。エージェントはコンテキストを見つけ、結びつけ、説明し、仕事の変化に合わせて更新します。情報源へのリンクと意思決定の履歴は残ります。
7. 小さく始め、AIによるチーム協働の改善を測る
実際の導入は、ひとつのプロジェクトと、繰り返し発生するひとつのコミュニケーションの問題から始められます。
具体的な出発点として、AIワークフローの事例を見て、入力が明確で、チームが成果を確認できるものを選ぶとよいでしょう。
サポートから開発への引き継ぎは、よい例です。関連する受信箱、リポジトリ、リリース情報、議論のチャネルを特定し、具体的な成果物を定義します。たとえば、顧客の根拠、検証済みの製品動作、未解決の問い、注釈付きのワークフローを含む問題整理資料です。
最初に評価するのは、エージェントが状況を正しく表しているかどうかです。関連する根拠を取得できているか。現在の動作と予定されている変更を区別しているか。不確実性を保っているか。各参加者が、他の人に何が必要かを理解できるかを確認します。
そのうえで、協働が改善したかを評価できます。背景の説明を繰り返すことが減ったか。引き継ぎ後の確認の往復が少なくなったか。途中から参加した人が、意思決定の理由を理解できるか。古い前提が顧客への約束に影響する前に見つかるかを見ます。
こうしたやり取りからのフィードバックを、情報源の一覧、コンテキストの組み立て方、エージェントが作る成果物の改善につなげます。土台が信頼できるようになれば、担当範囲を広げられます。
価値が表れるのは日々の仕事です。エンジニアは調査を始める前に顧客への影響を理解でき、サポートは製品を正確に説明でき、新しい参加者は決定に至った理由をたどれます。必要なコンテキストを持って仕事に臨めることで、人は目標を選び、約束を交わし、チームが成果を出すための関係を築くことに、より多くの注意を向けられます。
よくある質問
AIエージェントのコンテキストとメモリはどう違いますか？
コンテキストは、モデルが現在の応答や行動に使える情報です。メモリは、必要に応じてセッションをまたぎ、後で使うために情報を保存します。保存された決定事項は、取り出された時点で現在のコンテキストに入ります。どちらにも、情報源への参照、明確な利用範囲、情報が古くなっていないかの確認が必要です。
AIエージェントのコンテキスト管理とRAGはどう違いますか？
検索拡張生成（RAG）は、情報を検索・取得し、それを根拠としてモデルに回答させる手法です。コンテキスト管理は、指示、会話履歴、ツールの結果、取得した情報をタスクごとに選ぶ、より広いプロセスを指します。アクセス制御の範囲内で、鮮度や保存期間も管理します。RAGはその一部として使えます。
AIエージェントのコンテキストウィンドウがいっぱいになると、どうなりますか？
システムによって、リクエストが失敗したり、古い内容が削除されたり、会話が要約に圧縮されたりします。目標、確認済みの決定事項、未解決の疑問、情報源へのリンクを簡潔な作業記録に残してください。詳細な根拠は必要に応じて再取得し、要約から重要な制約が抜けていないか確認します。
全員のアクセス権を共有せずに、AIエージェント同士でコンテキストを共有できますか？
できます。ただし、情報源のアプリ、認証・認可システム、保存先がアクセス権を適用する必要があります。指示の共有によって、他の人の接続済みアカウントへのアクセス権が得られるわけではありません。要約や引き継ぎにも元の情報の制限を維持し、取得時や共有時にシステムがアクセス権を再確認します。
AIエージェントの引き継ぎには何を含めるべきですか？
タスクの目標、現在の状況、確認済みの事実、情報源へのリンク、決定事項とその理由、未解決の疑問、次の行動と担当者を含めます。仮定や提案は明示してください。顧客の問題であれば、本番環境で確認された挙動と、計画中または未デプロイの修正を区別します。
AIエージェントのコンテキストは、どのくらいの頻度で更新すべきですか？
関連するリリース、顧客からの新情報、意思決定、アクセス権の変更があったら、使用中のコンテキストを更新します。影響の大きい行動の前には、変わり得る事実を再確認してください。情報源の変化の速さに合わせて見直しの頻度を決め、古い指針には更新済みであることを示し、過去の根拠は権限のある人が参照できる状態に保ちます。
コンテキスト管理によってチームの協働が改善したか、どう測りますか？
繰り返し発生するワークフローを一つ選び、導入前の状態を記録します。同種のタスクで、背景を調べ直す時間、引き継ぎごとの確認の往復、事実の訂正回数を比較してください。適切な情報源の参照、アクセス権の遵守、不確実性の明示も確認します。作業が速くなることに価値があるのは、結果の正確さが保たれる場合です。
