コンテキストウィンドウは巨大化している
「エージェント」という言葉が、あらゆるものに対して使われている。
ツールを呼び出す関数はエージェント。メモリを持つチャットボットはエージェント。ループを持つスクリプトもエージェント。
この誤解が、質の低いエンジニアリングを招く。チームは単純なタスクを過剰に設計（オーバーエンジニアリング）し、複雑なタスクの設計を疎かにしてしまう。たった一つの優れたプロンプトで済むワークフローに対して、エージェントのオーケストレーションに何週間も費やしているチームをよく見かける。
私が考える「真のエージェント」の定義は以下の通りだ。
エージェントには目的がある。単に指示に従うだけではない。次に何をすべきかを自ら決定する。失敗に対処する。そして、いつ止まるべきかを知っている。
以下のベンチマークを活用してほしい：
- 人間がすべてのステップをガイドしなければならないなら、それはチャットインターフェースである。
- ツールの呼び出しに失敗してもシステムが復旧できるなら、それはエージェントへと近づいている。
- システムが目標をタスクに分解し、それらを委任できるなら、それは真のエージェントである。
成功しているエージェントの多くは、用途が限定的（narrow）だ。一つの仕事を完璧にこなす。カスタマーサポートのトリアージや、ドキュメントの抽出などだ。それらは汎用的な推論エンジンではない。
成功しているチームは、次の3つのことに集中している：
- ツール設計：インターフェースはどれほど洗練されているか？
- 失敗への対処：ツールが何も返さなかった場合、どうなるか？
- オブザーバビリティ（観測性）：エージェントがなぜその決定を下したのか、追跡できるか？
失敗するチームは、単にモデルを新しいものに置き換えて、より良い結果を期待するだけだ。彼らはシステム設計を無視している。
LangChainやCrewAIのようなフレームワークは毎月のように変わる。フレームワークそのものよりも、パターンの方が重要だ。
次のパターンを活用すべきだ：
- 計画してから実行する：推論ステップと実行ステップを分離する。
- 検索と推論を分離する：コンテキストを取得することと、それを使用することは別の仕事である。
- 明示的な引き継ぎ：あるエージェントが別のエージェントに仕事を渡す際は、構造化されたログを使用する。
フレームワークは単なる足場に過ぎない。アーキテクチャこそが建物そのものである。
RAGは標準的だが、チャンキング（chunking）がうまくいっていないことが多い。ドキュメントの分割が不適切だと、モデルはコンテキストを見失う。これがハルシネーション（幻覚）につながる。
RAGの結果が役に立たない場合は、チャンキングとメタデータをチェックしてほしい。問題がモデルにあることは稀だ。
モデルは進化するだろう。コンテキストウィンドウは拡大し、トークンコストは低下するだろう。
しかし、それらのどれもが真のエンジニアリングの課題を解決するわけではない。見ていない時でも正しく動作するシステムを構築しなければならない。
ガバナンス、オブザーバビリティ、そして信頼性の高いツール利用に注力せよ。最高のエンジニアは、モデルの研究者ではない。信頼できるAIを構築するシステムデザイナーである。
コンテキストウィンドウは巨大化している。それがすべてを変える理由。
コンテキストウィンドウのサイズは、ここ数年で爆発的に拡大しています。かつては数千トークンが限界でしたが、今では数十万、あるいは数百万トークンを扱えるモデルが登場しています。
これは単なる「より多くの情報を一度に読み込めるようになった」という進化ではありません。これは、AIとの対話、アプリケーションの設計、そして私たちがAIを利用する方法そのものを根本から変えるパラダイムシフトです。
コンテキストウィンドウの進化
少し前まで、コンテキストウィンドウのサイズはLLMの最も重要な制約の一つでした。
- GPT-3: 2,048トークン
- GPT-4: 32,768トークン
- Claude 2: 100,000トークン
- Gemini 1.5 Pro: 1,000,000+ トークン
この進化のスピードは驚異的です。
RAGの役割の変化
これまで、コンテキストウィンドウの制限に対処するための標準的な手法は RAG (Retrieval-Augmented Generation) でした。
RAGの仕組みはこうです：
- 膨大なデータセットから、質問に関連する小さな断片（チャンク）を検索する。
- その断片をコンテキストウィンドウに詰め込む。
- LLMにその情報に基づいて回答させる。
RAGは非常に効果的でしたが、いくつかの問題を抱えていました。検索プロセスにおいて、文脈の重要な部分を見落としたり、断片化された情報によって全体像が失われたりすることがあります。
しかし、コンテキストウィンドウが巨大化すると、RAGの必要性が変わってきます。
「検索」から「推論」へ
コンテキストウィンドウが十分に大きくなれば、私たちは「断片を検索する」必要がなくなります。代わりに、**「データセット全体をコンテキストに投入し、その上で推論させる」**ことが可能になります。
これが何を意味するのか？
- 完全な文脈の理解: 検索による情報の欠落がなくなり、ドキュメント全体の構造やニュアンスをモデルが直接理解できるようになります。
- 複雑な推論: 「この1,000ページの契約書の中で、矛盾している箇所はどこか？」といった、断片的な検索では不可能な質問が可能になります。
- ゼロショットの知識注入: 膨大なマニュアルやコードベース全体を一度に読み込ませることで、モデルを微調整（Fine-tuning）することなく、高度にカスタマイズされた挙動を実現できます。
「干し草の中の針（Needle in a Haystack）」テスト
ロングコンテキストモデルの性能を測る指標として、「干し草の中の針（Needle in a Haystack）」テストがよく使われます。これは、膨大なテキスト（干し草）の中に、たった一つの無関係な事実（針）を隠し、モデルがそれを正確に見つけ出せるかをテストするものです。
以前のモデルは、コンテキストが長くなると情報の「中だるみ（Lost in the Middle）」現象が発生し、最初と最後の方の情報は覚えていても、真ん中の方にある情報を忘れてしまう傾向がありました。しかし、最新のモデルはこの問題を克服しつつあります。
課題：計算コストと複雑さ
もちろん、すべてがバラ色というわけではありません。コンテキストウィンドウを拡大するには、大きな技術的障壁があります。
最も大きな問題は、標準的な Transformer アーキテクチャにおける Attention（アテンション）メカニズム の計算量です。アテンションの計算量は、入力トークン数 $n$ に対して $O(n^2)$、つまり二次関数的に増加します。
トークン数が2倍になれば、計算量は4倍になり、メモリ使用量も劇的に増加します。これが、モデルを巨大化させる際の最大のボトルネックです。
これを解決するために、以下のような技術が開発されています：
- FlashAttention: メモリへのアクセスを最適化し、アテンションの計算を高速化する。
- Sparse Attention: すべてのトークン間ではなく、重要なトークン間のみに注意を向ける。
- Linear Attention: 計算量を $O(n^2)$ から $O(n)$ に抑える試み。
結論
コンテキストウィンドウの拡大は、AIの活用方法を「検索ベース」から「推論ベース」へとシフトさせています。
RAGは死ぬことはありません。検索は依然として、数テラバイトに及ぶような、コンテキストウィンドウに収まりきらない超大規模なデータセットを扱うには不可欠です。しかし、RAGは「情報の断片を渡す手段」から、「コンテキストを補完する高度なツール」へと進化していくでしょう。
私たちは今、AIが「断片的な知識」を扱う時代から、「膨大な知識の全体像」を理解する時代への転換点に立っています。