Googleがコンテキストウィンドウを消した

ミリオントークンのコンテキストウィンドウは、大規模言語モデルのための裏技として期待されていました。ベンダーは、128K、200K、さらには1Mトークンのプロンプトを宣伝するために競い合い、単純な容量の増加が信頼性の高いコーディング補助ツール、自律エージェント、完全に検索可能な知識ベースを解放するかのように扱いました。しかし現実は、それほど映画的ではありません。より多くのトークンは、しばしば単に遅く、高価で、なおかつ混乱したモデルを意味するだけでした。

Googleの最新の研究では、コンテキストエンジニアリングの限界が明らかにされています。同社は「問題に対してトークンを増やすことは時間を稼ぐが、コスト、レイテンシ、信頼性のカーブの形状は変わらない」と主張しています。1Mトークンのウィンドウを使えば、複雑さに一時的に対抗できるものの、実際の作業負荷（RAG結果、マルチエージェントログ、ツール出力、ユーザー履歴など）はすぐに追いついてきます。

3つの硬直的な制約が「プロンプトを詰め込むだけ」という戦略を押しつぶし続けています。第一はコストと遅延のスパイラルです：追加の100Kトークンごとに推論時間とクラウド料金が上昇し、実際のアプリではしばしば2～3倍になります。第二は「中間での喪失」で、これは過負荷のプロンプトに埋もれた重要な指示をモデルが無視するという文書化された現象です。第三は物理の問題です：ツールやエージェントを数時間または数日間にわたってチェーンすることを始めると、百万トークンのウィンドウもオーバーフローしてしまいます。

Googleの答えは「2Mトークン」ではなく、アーキテクチャの転換です。文脈を巨大な可変チャットログとして扱うのではなく、同社はそれをより豊かで状態を持つシステムに対するコンパイルされたビューとして位置づけています。生データ—セッション、記憶、アーティファクト—はソースコードとして機能し、プロセッサのパイプラインが各モデルコールに対して最小限のタスク固有の作業コンテキストをコンパイルします。

その変化は、コンテキストを単純なバッファ問題からシステム設計問題に変えます。Googleのエージェント開発キット（ADK）は、作業コンテキスト、セッション、メモリ、アーティファクトの4層スタックにこれを組み込んでおり、それぞれが明確な責任とライフサイクルを持っています。コンテキストは「ウィンドウに収まるもの」から、コード、ポリシー、および範囲の明示的な産物になります。

この記事では、そのフレームワークが実際にどのように機能するかを詳しく説明します。Googleエージェント開発キット（ADK）を使用して、コンテキストアーキテクチャ、さまざまなコンテキストオブジェクトと権限、そしてなぜ百万トークン時代がすでに終わったのかを示す実際のドキュメントリサーチエージェントについて分解していきます。

より大きなコンテキストウィンドウは全知を約束するが、実際には高い価格に驚かされることが多い。追加の100,000トークンごとに実際のコストと時間が加算され、生産チームはその両方を実感する。Google自身のコンテキストエンジニアリングブログでは、コスト/レイテンシスパイラルについて説明している。1回の呼び出しごとに増えるトークン数が、何千もの同時ユーザーによって掛け算されることで、「素晴らしいデモ」が「予算超過」に一気に変わる。

レイテンシも同様に過酷にスケールします。その百万トークンのプロンプトは、デコーディングが遅くなり、ツールチェーンが長くなり、ユーザー体験が「アシスタント」から「チケッティングシステム」へと変わってしまいます。マルチエージェントの設定では、各エージェントの呼び出しがさらに多くのモデル呼び出しに広がるため、一つの肥大化したコンテキストが全体のパイプラインに感染します。

次にLost in the Middleが登場します。LLMは巨大なプロンプト全体に均等に注目するわけではなく、しばしば始まりと終わりに偏りがちで、中央部分を静かに無視します。Googleのブログとその後の研究は、重要な事実が長いシーケンスの中央に埋もれているとき、モデルが技術的には「すべてを見ている」場合でも、正確性が低下することを示しています。

生産エージェントのプロンプトを想像してみてください。上部には新しいユーザーの質問、下部には最近のツールエラーと再試行の指示があります。その中央には実際のポリシー制約や重要なシステム指示が挟まれています。モデルは喜んで周辺を最適化し、実際に重要なものを超えて幻覚的にアプローチします。

実際の作業負荷はこれをさらに悪化させます。1回のターンには以下が含まれる可能性があります： - 20〜50のRAGパッセージ - 5〜10のツール呼び出しログ - 数十件の以前のチャットメッセージ

それらすべてを「1Mトークン対応」モデルに詰め込んでも、コンテキストウィンドウは豊富なインタラクションの数回で詰まってしまいます。実際、Googleエージェント開発キット（ADK）のデモでも、すべてを無防備にプロンプトにストリーミングすると、どれほど速くアーティファクト、メモリ、セッション状態が膨張するかが示されています。

物理的限界は仕事を完遂します。コンテキストの長さは計算能力とメモリに対して超線形ではなく、128Kから1Mトークンに移行するだけでも、異常なインフラが必要です。さらに高い数値に達すると、単に巧妙なプロンプト設計だけでなく、GPUのRAM、帯域幅、トレーニングの安定性との闘いになります。

これは単なる実験室の好奇心ではありません。これは、生産チームが歴史を静かに抑制し、RAG結果を短縮し、積極的に要約する理由です。文脈が未加工の流れから集約されたビューに変わらない限り、大規模なエージェントは自らのデータに埋もれ続けるでしょう。

Googleの新しいコンテキストコンパイラのアイデアは、コンテキストウィンドウの古いメンタルモデルを引き裂きます。それは、底なしのチャットログではなく、変化可能なストリームバッファではなく、セッション、記憶、そして単一のプロンプトの外に存在するアーティファクトからなるはるかに豊かな状態に対するコンパイルされたビューになります。各モデルコールは、全体の藁山ではなく、慎重に構築されたスライスのみを参照します。

コンパイラエンジニアのように考え、プロンプトの調整者ではありません。生のインタラクションデータはソースコードとなり、一連のプロセッサがコンパイラとして機能します。そして、Geminiに送信される最終的なプロンプトは最適化された実行可能ファイルです。Googleのブログ「生産のための効率的なコンテキスト対応マルチエージェントフレームワークの設計」では、これは生産規模のエージェントにとっての厳格な要件であり、単なる良い抽象概念ではないと明言されています。

このモデルの下では、開発者の仕事は「このプロンプトをどう言い表すか？」から「コンテキストを構築するためのパイプラインをどう設計するか？」に移ります。セッションがどのように構造化されたイベントを保存し、記憶が長期的な知識をどのようにエンコードし、PDFやCSVなどのアーティファクトがどのようにIDで参照されるかを設計します。メガプロンプトを手動でキュレーションすることをやめ、フロー、プロセッサー、スコープを定義し始めます。

Googleエージェント開発キット（ADK）は、これをそのAPIに組み込んでいます。異なるコンテキスト層—作業コンテキスト、セッション、メモリ、アーティファクト—を公開し、`app`、`user`、`temp`のような明示的なプロセッサーと状態プレフィックスを通じてそれらを接続することを強制します。このストレージとプレゼンテーションの分離により、5,000トークン未満のスリムでターゲットを絞ったプロンプトを出しながら、何千ものイベントをログに記録することが可能になります。

力はデフォルトでのスコープから生まれます。すべてのモデル呼び出しは、そのタスクに必要な最小限のコンテキストのみを受け取り、コンパイラパイプラインによってタイムリーに組み立てられます。エージェントがより多くの情報を必要とする場合は、すべてを「念のため」に事前にロードするのではなく、ツールを呼び出してアーティファクトを取得したりメモリをクエリしたりします。

この組み合わせたコンテキストアプローチは、3つの痛点を同時に解決します。トークン数が減少するため、コストとレイテンシもそれに伴い低下します。「中間での損失」は縮小し、中間がほぼ消えるため、無関係な履歴が作業コンテキストに入ることはありません。物理的なコンテキスト制限は硬い上限ではなく、コードで制御できる最適化予算となります。

コンテキストエンジニアリングは、情報が存在する場所とモデルがそれをどう見るかとの間に明確な区切りを設けることから始まります。Googleのエージェント開発キット（ADK）は、これをその第一原則に組み込んでいます：ストレージとプレゼンテーションを分離する。これは抽象的に聞こえるかもしれませんが、進化できるシステムと、その自らのトランスクリプトの下で崩壊するシステムとの差異です。

ADKはセッションと作業コンテキストの間に明確な線を引きます。セッションは持続的で権威のある台帳として機能します。すべてのユーザーメッセージ、ツール呼び出し、ツール結果、システムイベントがここに構造化された状態として記録されます。作業コンテキストは、単一のLLM呼び出しのために作られた使い捨てのスナップショットで、呼び出し後には破棄されます。

セッションはあなたのデータベースと考え、ワーキングコンテキストはSQLクエリの結果と考えてください。各クエリに合わせてデータベースを変更することはなく、クエリを変更します。ここでも同じ考え方です：完全な追加専用のセッションを保持し、タスクやモデル、レイテンシ予算に応じてそこから異なるワーキングコンテキストを作成します。

その分離は、あなたの製品が変わる瞬間に重要になります。Gemini 3 Proをより小さいモデルに交換したいですか？それとも、冗長なチャットスタイルのプロンプトから端的なツール実行プロンプトに切り替えたいですか？ワーキングコンテキストを構築するプロセッサを更新すればよく、セッションスキーマや過去のデータは変更しません。過去のやり取りはそのまま保持され、モデルに対するフレーミングを根本的に変えたとしても、影響を受けません。

Googleエージェント開発キット（ADK）のドキュメントでは、明確なコンテキストオブジェクトと状態プレフィックスを使用してこれを公式化しています。セッションに基づく状態は `app` や `user` といった耐久性のあるプレフィックスの下に存在し、一時的で呼び出し専用のデータは `temp` の下に存在します。作業コンテキストのみがこれらの名前空間を横断して読み取り、現在の呼び出しのための最小限のビューをまとめます。

実践的な影響はマルチエージェントシステムで迅速に現れます。一つのエージェントは、最後の3つのユーザーの発言とツールの要約だけを持つ作業コンテキストを見るかもしれません。別のエージェントは、200件のメッセージからなるセッションの要約とRAGヒットを受け取るかもしれません。どちらも同じ基盤となる記録から派生していますが、各コールは実際に必要なトークンのみに対してのみ料金を支払います。

コンテキストウィンドウは文字列の結合によって増加していました：ユーザーメッセージ、エージェントの応答、ツール出力、請求が爆発するまで繰り返します。Googleエージェント開発キット（ADK）はそれを取り除き、明示的変換に置き換えます：生の状態を機能するプロンプトにコンパイルするための名前付きの順序付けられたパイプラインです。コンテキストはテキストの塊ではなく、ビルドアーティファクトになります。

`prompt = history + docs + tools`の代わりに、`summarize_session`、`select_relevant_artifacts`、`inject_instructions`、`budget_tokens`のようなプロセッサを定義します。各ステップには名前、契約、パイプライン内の位置があります。すべてのステージをログに記録し、実行間の出力を比較し、システムの他の部分に触れずにプロセッサを交換することができます。

GoogleのコンテキストブログとADKドキュメントでは、これをセッション、メモリ、アーティファクト、作業コンテキストの4層の状態を変換するフローとして説明しています。例えば、ドキュメントリサーチエージェントは以下を行うことができます： - メモリから以前の決定を取得する - アーティファクトから候補のPDFをランキングする - 引用を2,000トークンの要約に圧縮する - Gemini 3 Proのための最小限のプロンプトを生成する

プロセッサーが明示的であるため、チームはそれらをユニットテストできます。`select_relevant_artifacts` が5つ以上のドキュメントを取得することは決してないと主張したり、`summarize_session` が1,000トークン未満に収まることを確認したりできます。デバッグは「なぜモデルがハルシネートしたのか？」から「どのプロセッサーが間違ったデータを注入したのか？」に変わります。

デフォルトでスコープ設定は、混乱のもう一方の側面、すなわち「誰が何を見るか」に対処します。すべてのツール呼び出しにマルチエージェントの完全なトランスクリプトを投げ込むのではなく、ADKはタイプ化されたコンテキストオブジェクトを介して最小限の役割特有のコンテキストをルーティングします。ツール、コールバック、および指示提供者は、それぞれ制限されたビューを受け取ります。

ツールの機能は、セッション状態を読み書きできるToolContextを受け取ります。これにより、アーティファクトを保存またはロードし、メモリを検索することができます。コールバックハンドラは、状態とアーティファクトを持つCallbackContextを受け取り、メモリ検索がないため、サイドチャネルの混乱を防ぎます。インストラクションプロバイダーは、読み取り専用のコンテキストを扱うため、システムプロンプトを生成する際に密かに状態を変更することができません。

スコープ付きコンテキストは、マルチエージェントシステムをAIアセンブリラインに変えます。一つのステージはアーティファクトを読み取り、構造化された要約を生成します。別のステージは、より狭いスコープでその要約をユーザー向けの文章に変換します。そして、第三のステージは結果をメモリに記録します。どのエージェントも50,000トークンの全履歴を持ち運ぶことはありません。

Explicit TransformationsとScoped by Defaultは、一緒になって負荷下でも予測可能なコンテキストフローを生み出します。どのプロセッサが実行され、どの状態に触れ、どれだけのトークンを出力するかを正確に把握できます。その規律こそが、ミリオン・トークンモデルを必須ではなく任意にする要因です。

Googleエージェント開発キット（ADK）のコンテキスト対応エージェントは、コンテキストを副作用ではなく製品として扱う四層スタック上で動作します。各層は異なる質問に答えます：モデルが今見ているもの、実際に起こったこと、持続すべきこと、そして重い資産がどこにあるかです。

最上部には作業コンテキストがあります。これはADKがコンパイルして単一のモデル呼び出しのためにGeminiに送る、厳密で一時的なペイロードです：選択されたメッセージ、ツールの出力、メモリからのスニペット、およびいくつかのアーティファクトの参照が含まれています。ADKは呼び出しの後すぐにこれを破棄するため、作業コンテキスト内の情報はそれ自体では権威あるものではありません。

その下にあるのがセッションであり、インタラクションの長期にわたる公式ログです。すべてのユーザーメッセージ、モデルの応答、ツールの呼び出し、ツールの結果が、平面的なトランスクリプトではなく、構造化されたイベントオブジェクトとしてここに記録されます。ADKが作業コンテキストを再構築する際には、このセッションのタイムラインを照会し、現在のタスクのためにイベントをフィルタリング、要約、または再スレッドするプロセッサーを適用します。

長期的な知識は記憶に移行します。記憶はユーザーの好み（トーン、言語、通知習慣）、永続的な事実（企業方針、製品仕様）、および単一のチャットを超えて存続すべき濃縮された決定を保持します。ADKは、エージェントが10,000トークンの履歴を再生するのではなく、重要な3〜10件のみを引き出せるように、記憶検索APIを通じてこれを表面化させます。

アーティファクトは「プロンプト内の巨大なファイル」問題を解決します。アーティファクトは、大きなバイナリまたはテキストオブジェクト—PDF、CSV、画像、音声ファイル—で、一度保存され、安定した名前やIDで参照され、プロンプトに貼り付けられることはありません。ツールはアーティファクトを読み書きし、作業コンテキストは必要に応じて軽量の参照と抽出されたチャンクのみを含みます。

これらの4つの層が一緒になって、モノリスではなくコンテキストパイプラインを形成しています。例えば、ドキュメントリサーチエージェントは、セッションを読み取って最新のユーザ質問を見つけたり、以前の決定を探すためにメモリを検索したり、IDによってPDFアーティファクトを読み込んだり、関連する数段落と引用文だけを使って作業コンテキストを構築したりすることができます。コストとレイテンシは、そのコンパイルされたスライスに応じてスケールし、生のコーパスには依存しません。

Googleのガイダンスでは、チームはこれらのレイヤーを第一級のデザインサーフェスとして扱うことを推奨しています。ADKコンテキストドキュメントでは、作業コンテキスト、セッション、メモリ、アーティファクトが具体的なタイプ、権限、プロセッサーにどのようにマップされるかが明示されており、マルチエージェントシステムがワークロードの増加に伴っても迅速で安価、かつ基盤を持つ状態を維持できるようになっています。

ステートはAIに持続的な感覚を持たせ、金魚のような短期記憶にならないようにします。そして、Googleエージェント開発キット（ADK）は、そのコンテキストAPIに巧妙なプレフィックスシステムを直接組み込んでいます。エージェントに一つの不明瞭な「メモリ」の塊を渡すのではなく、ADKはステートをtemp:、user:、およびapp:の名前空間に分け、実際のソフトウェアがどのように動作するかにきれいに対応させています。

temp: 最初は temp:、スクラッチパッド。`temp:` の下に書いたものは、一度の呼び出しのためだけに存在し、その後消えます。あるツールが解析したCSVを `temp:parsed_doc` に保存し、別のツールが200ミリ秒後にそれを読み取ることができます。そして、エージェントが応答を返した後、ADKはそれを消去します—中間的なゴミで長期的な履歴を汚染するリスクはありません。

レベルを上げると、user: はエージェントの実際の人物の記憶となります。 `user:reading_level`、`user:last_projects`、または `user:blocked_sources` のようなキーは、ADKをバックストアに接続している限り、セッションを超えて持続します。デモに組み込まれたリサーチアシスタントは、ユーザーが先週既に要約した論文を記憶し、再取得や再説明を避けることができます。

最上部にはapp:があり、全体のデプロイメントに対するグローバルな状態があります。機能フラグ（`app:enable_vision`）、システム全体のレート制限、共有された埋め込みインデックスの参照がここにあります。すべてのエージェントインスタンスとすべてのユーザーはこれらの値を読み取ることができるため、設定を一度変更すれば、数百の同時セッションでの動作の変化を観察できます。

これらの3つのプレフィックスを組み合わせることで、カスタムフレームワークを作成することなく、具体的な状態階層を得ることができます。以下のようになります： - temp: ツール間のターンごとの接続用 - user: ユーザー識別ごとのメモリ用 - app: ユーザー間の設定用

その階層はADKのデザイン原則を直接エンコードしています。ストレージとプレゼンテーションを分離する：状態は`temp:`、`user:`、または`app:`の下にあり、作業コンテキストはこれらのキーのコンパイルされたスライスです。明示的な変換：ツールとプロセッサは特定のプレフィックスを読み書きし、大きなプロンプトを変異させることはありません。デフォルトでスコープが限定される：`temp:`はターンを超えて漏れ出すことはなく、`user:`は誤ってグローバルにならず、`app:`は静かにユーザー特有の挙動に変わることはありません。

Googleエージェント開発キット（ADK）は、すべてのコンテキスト理論を実際のリサーチボットに変えます。Yeyu Labのデモは、完全なPDFをプロンプトに投げ込むことなく、ファイルを検索、オープン、および分析できるドキュメントアシスタントを構築しました。その代わりに、各Gemini 1.5またはGemini 2.0の呼び出しに対して、必要なコンテキストを十分にまとめます。

デザインの中心にはオンデマンド読み込みパターンがあります。`list_documents`ツールは、軽量なメタデータのみを返します：ドキュメントID、タイトル、場合によってはバイトサイズとタイムスタンプ。モデルは、200ページの生テキストではなく、コンパクトなオプションの表を見ています。

ユーザーが「四半期報告を分析する」といった内容を選択すると、エージェントは`analyze_document`を呼び出します。このツールはアーティファクトストレージからファイル全体を取得し、チャンク化や要約を行い、その後、モデルに圧縮された結果を提示します。LLMは元のドキュメントをインラインで受け取ることはなく、要求された処理された部分のみを受け取ります。

ツールは`temp:` 状態を介してコーディネートされ、ペイロードをワイヤー経由でドラッグする必要はありません。`list_documents`は`temp.current_doc_id = "report_q2_2024"`を書き込み、`analyze_document`はその同じキーを読み取って、どのアーティファクトをロードすべきかを正確に知ります。ベース64のブロブも、50,000トークンのJSONがツール間で行き来することもありません。

その `temp:` スコープは単一の呼び出しの間だけ存在し、作業コンテキストを最小限に保ちます。典型的なターンには、ユーザーのリクエスト、短いシステムプロンプト、コンパクトなドキュメントリスト、そして一つの `current_doc_id` 文字列が含まれますが、それでもリッチなマルチステップワークフローのように感じられます。Googleエージェント開発キット（ADK）は基盤を処理し、モデルは推論に集中できるようにします。

長期的な行動は`user:`の状態に依存しています。「私は簡潔な要約が好きです」と誰かが言うと、ツールやコールバックが`user.summary_style = "brief"`と記録します。将来の呼び出し—明日、来週、別のデバイスで—はそのキーを読み取り、自動的に3文の要約を生成することができます。

優先設定はプロンプトを肥大化させることなく積み重ねることができます。以下を追跡することができます： - `user.domain_focus = "金融"` - `user.citation_format = "APA"` - `user.summary_style = "簡潔"`

各呼び出しは、作業コンテキストに関連するサブセットのみをコンパイルします。誰もユーザーが箇条書きを嫌っていることを思い出すためだけに、200ターンのチャットログを再生することはありません。

このエージェントの知能は、効率的なツールの使用から生まれます。モデルは正確なツールコールを発行し、`temp:`と`user:`の状態を行き来し、必要な時だけアーティファクトに触れます。Googleエージェント開発キット（ADK）は、賢く振る舞うために毎回全履歴を再読み込みする必要があるという考えを効果的に否定します。

プロンプトエンジニアリングはかつて巧妙な呪文や脆弱なハックを意味していました。GoogleのコンテキストブログとGoogleエージェント開発キット（ADK）によって提唱されたコンテキストエンジニアリングは、その役割を言語モデルの分散システムアーキテクチャに近いものにアップグレードします。

単一のメガプロンプトにこだわる代わりに、開発者はパイプラインを設計しています：セッション、状態、メモリ、そしてアーティファクトがプロセッサを通じてコンパイルされた作業コンテキストにどのように流れるかです。ADKの4層スタック—作業コンテキスト、セッションログ、長期記憶、外部アーティファクト—は「プロンプトに何があるのか？」を「このビューを生成したシステムは何で、なぜなのか？」に変えます。

その変化はAI開発の明確な成熟を示しています。あなたは以下を定義します： - どのデータがどこに存在するか - どの変換がいつ実行されるか - どのエージェントまたはツールがどの範囲を見るか

結果：行動は魔法のように感じられなくなり、デバッグ可能に感じられるようになる。

信頼性が向上するのは、すべてのコンテキストスライスに明示的なレシピがあるからです。エージェントが幻覚を見た場合、その出力を構成したプロセッサーやプレフィックスを調査します。40,000トークンの塊ではありません。ADKの状態プレフィックス（`app`、`user`、`temp`）やスコープ付きコンテキスト（ツール、コールバック、呼び出し）は、バグを再現し、テストを作成し、失敗モードについて考えるための手段を提供します。

予測可能性は向上します。エージェントはもはや全履歴を一度に取り込むことはありません。彼らはIDでアーティファクトを要求し、制御されたクエリでメモリを検索し、制約された状態セグメントに書き込みます。コストも低下します：コールごとに必要最低限のコンパイル済みコンテキストのみをストリーミングし、何週間分ものログを100万トークンのウィンドウにリプレイする必要がなくなります。

生産をターゲットにするチームにとって、これはマルチエージェントバックエンドの設計図のように見えます。一つのエージェントがオーケストレーションを行い、専門のエージェントがツールや記憶を所有し、ADKのコンテキストフレームワークが各コールに十分な情報を提供することを保証します。Google自身のドキュメント、特に会話のコンテキストに関する紹介: セッション、状態、そしてメモリは、プロンプトのヒントというよりもAPI設計ガイドのように読まれます。

コンテキストエンジニアリングは、Googleエージェント開発キット（ADK）で実装されており、LLMアプリを微調整する呪文ではなく、あなたが設計するシステムに変えます。これは、真剣な規制されたマルチエージェントの展開に必要な前提条件です。

本格的に試す準備はできましたか？まずは、Googleエージェント開発キット（ADK）をインストールし、Gemini APIキーを取得し、Google DevelopersブログのGoogleのコンテキストエンジニアリングの解説を読んでください：生産向けの効率的なコンテキスト対応マルチエージェントフレームワークの設計。この記事では、作業コンテキスト、セッション、メモリ、アーティファクトの4層スタックと、コードに反映させるべき3つの原則が定義されています。

次に、公式の ADKコンテキストドキュメント に直接アクセスしてください：google.github.io/adk-docs/context。`InvocationContext`、`ToolContext`、および `CallbackContext` がセッション、メモリ、アーティファクトへのアクセスをどのように制御するか、また `app:`, `user:`, `temp:` プレフィックスがどのようにスコープ付きの状態を実装するかに焦点を当てます。これらのAPIを単なるヘルパークラスではなく、システムの境界と見なしてください。

次に、GitHubからYeyu Labのデモをダウンロードしてください: context_demo。ドキュメントアシスタントを実行し、アーティファクトがどのように保存され、IDによって参照されるかを確認し、ツールがどのようにプレフィックスを介して状態を読み書きするかを追跡することで、フリーフォームテキストにデータを隠すのではなく、それを行う様子を観察してください。これが、コンテキスト対応のマルチエージェントワークフローの参照実装です。

初めてのプロジェクトとして、既存のRAGアプリをこのパターンに合わせてリファクタリングしてください。「すべてをプロンプトに詰め込む」ロジックを以下のように置き換えます：

• 1構造化されたイベントのセッションログ
• 2PDF、CSV、長文書類のアーティファクトストレージ
• 3同じ事実を再送するのではなく、メモリー検索を使用してください。
• 4ツール間で中間結果を渡すための「temp:」ステート

もはやプロンプトを調整するだけではなく、自然言語で会話する分散システムを設計しています。コンテキストをコンパイルされたビューとして内面化し、状態、アーティファクト、明示的な変換を考慮してアーキテクトを組んでいる開発者が、他の人々がより大きなコンテキストウィンドウを追い続ける中で、本番環境に適したAIを出荷することになります。

コンテキストエンジニアリングとは何ですか？

コンテキストエンジニアリングは、GoogleによるAIエージェントのための新しいアーキテクチャパターンです。これは、コンテキストを単一のテキストストリームとして扱うのではなく、セッション履歴、メモリ、外部ファイルなどのさまざまなデータソースから生成された「コンパイルビュー」として扱い、各特定のモデル呼び出しに最適化されます。

大きなコンテキストウィンドウはAIエージェントにとってなぜ問題なのか？

一見強力な大きなコンテキストウィンドウは、高コストと遅延の悪循環を引き起こします。また、「中間で失われる」問題にも悩まされており、モデルは雑音の海の中から関連情報を見つけるのに苦労し、最終的にはスケーラビリティと信頼性を制限します。

Googleのエージェント開発キット（ADK）は、これらのアイデアをどのように実現していますか？

ADKは、コンテキストエンジニアリングのためのビルトインプリミティブを備えたフレームワークを提供します。それは、永続的なストレージ（セッション、メモリ、アーティファクト）を、一時的な「作業コンテキスト」と分離し、必要な時に必要なものだけを読み込むためにツールと状態管理を使用します。

コンテキストエンジニアリングは、取得強化生成（RAG）を置き換えるのでしょうか？

それはそれを補完し、洗練させます。RAGはデータの取得に関するものであり、コンテキストエンジニアリングは、その取得されたデータ（およびその他のすべてのコンテキスト）がどのように構造化され、管理され、モデルに提示されるかに関するものです。これにより、RAGスタイルのワークフローに対して、より堅牢でスケーラブルなシステムが提供されます。