「もっと賢いモデルを使えば、エージェントは安定するはずだ」——現場でよく聞く期待ですが、長時間の実務タスクでは、これがしばしば裏切られます。エンタープライズ向けAIエージェント・インテグレーターであるhomulaが日々の実装で直面するのも、モデルの賢さではなく 「文脈（コンテキスト）の設計」 が信頼性を左右する、という現実です。2026年7月、この論点を業界の主要プレイヤーが明確に言語化しました。
いま「コンテキストエンジニアリング」が主戦場になった
2026年7月22日、LangChainは Sydney Runkle 氏と Harrison Chase 氏による「Agent Architecture（エージェント・アーキテクチャ）」を公開しました（LangChain Blog）。Chase 氏はかねてより 「信頼できる長時間（long-horizon）エージェントへの近道は、基盤モデルを改善し続けることだけではなく、その周囲のインフラとフィードバックループを使いこなすことにある」 と論じてきました。この考えは、いまや 「コンテキストエンジニアリング（context engineering）こそが新しい堀（moat）だ」 という言い回しで業界に定着しつつあります（Sequoia Capital）。
エージェントの中身は、実はシンプルなループです。LLMを呼ぶ → 次の行動を決める → ツールを実行する → 繰り返す。何が「賢い」エージェントを作るかは、このループの 周り——計画、記憶、サブエージェント、そしてどのトークンをコンテキストに入れるか——の作り込みにあります。
プロンプトエンジニアリングとの違い：プロンプトエンジニアリングは「最初の指示文」を磨く技術です。コンテキストエンジニアリングは、最初のシステムプロンプトから最後の要約まで、タスク実行中に流れる全トークンのライフサイクルを設計・運用する技術です。ワンショットの生成では差が出にくく、何十ステップも続く長時間タスクで初めて差が出ます。
なぜ長時間タスクで壊れるのか——「コンテキストの劣化」
長時間エージェントが途中で崩れる主因は、モデルの能力不足よりも コンテキストウィンドウの汚染 です。ステップが進むほど、過去のツール出力・中間結果・失敗の痕跡がウィンドウに溜まり、肝心の情報が埋もれていきます。
AI検索・データベースを手がける Chroma の「Context Rot（コンテキストの腐敗）」研究は、入力トークンが増えるほど、関連情報がすべて含まれていてもモデルの精度が下がる ことを主要モデル横断で示したと報告されています。劣化幅は条件により大きく、無視できない水準に達するケースもあるとされます。つまり「入れれば入れるほど賢くなる」わけではなく、入れすぎは害になる。これが長時間エージェント設計の出発点です。
4つの戦略：Write / Select / Compress / Isolate
LangChain は、エージェントのコンテキスト運用の定石を Write・Select・Compress・Isolate の4つ に整理しています（Context Engineering for Agents, LangChain）。実務では、この4つを組み合わせて「ウィンドウに何を残し、何を外に出すか」を設計します。
| 戦略 | 何をするか | 具体例 |
|---|---|---|
| Write（書き出す） | 文脈をウィンドウの外に保存する | スクラッチパッド／永続ファイルシステムに中間結果を退避（大きなツール出力をディスクに置く） |
| Select（選び取る） | 必要な文脈だけを引き込む | 50個のツールを全部積まず、そのステップで関連する5〜8個だけを検索して渡す（ツールへのRAG） |
| Compress（圧縮する） | 必要なトークンだけを残す | 会話の要約、ツール出力の圧縮、状態スキーマに要約フィールドを持たせる |
| Isolate（分離する） | 文脈を分割する | 探索・解析・要約などのサブタスクを、クリーンなウィンドウを持つ別エージェントに委譲 |
とくに Select は、homula がAgensで日々向き合う論点そのものです。企業のエージェントは数十〜数百のツールに接続しますが、それを丸ごとコンテキストに積むと精度もコストも悪化します。「いま必要なツールだけを選んで渡す」——ここが実装の勝敗を分けます。
「圧縮」と「分離」が長時間タスクを救う
とくに効くのが Compress（圧縮＝コンパクション） と Isolate（分離＝サブエージェント） です。
- コンパクション：ウィンドウが満杯になってから慌てて要約する「後手」の圧縮は、すでに劣化したトークンを抱えたまま処理を続けることになりがちです。逆に、無差別に定期要約すると、進行中のサブゴールの途中で文脈を刈り取ってしまう。「いつ・何を残して圧縮するか」 の設計が肝心です。Anthropic は自社評価で、コンテキスト編集だけで一定の性能向上が得られ、メモリ機能と組み合わせるとさらに伸びること、長いWeb検索タスクではトークン消費を大幅に削減しつつ、本来なら文脈枯渇で失敗する処理を完走できたと報告しています。
- サブエージェントによる分離：重いサブタスクを、それぞれ独立したクリーンなウィンドウを持つサブエージェントに切り出し、結果は千〜数千トークンの凝縮サマリーだけを親に返す。Anthropic のマルチエージェント研究システムは、この分離設計により単一エージェント構成を大きく上回る成績を出したと報告されています。
実務の勘所は「コンテキストは有限の予算」と捉えることです。エージェントの種類ごとにトークン予算を割り当て、Write で外に逃がし、Select で必要分だけ引き込み、Compress で削り、Isolate で分ける。モデルを乗り換える前に、この4レバーを回し切れているかを先に問うべきです。
homulaの観点：信頼性は「文脈の設計」から作る
homula は n8n / Dify / LangGraph を活用してエンタープライズのAIエージェントを実装しています。LangGraph は、まさにこのコンテキストエンジニアリング——永続ファイルへの書き出し（Write）、状態スキーマによる圧縮（Compress）、サブグラフによる分離（Isolate）——を組み込みで設計できる基盤です。私たちが「モデル選定より、その周りの設計」と言い続けてきた理由が、ここにあります。
- Select を実装で解く：Agens は、MCPを活用して 200以上のツールと構築ゼロで接続 します。接続の広さは価値であると同時に、「毎回どのツールをコンテキストに渡すか」という Select の課題を生みます。ツールの取捨と接続を基盤側で扱えることが、長時間エージェントの精度とコストを左右します。
- 分離を安全に回す統制：サブエージェントに権限を委ねるほど、「どのエージェントが、誰の承認で、どこまで触れるか」の設計が重要になります。Agens Control は承認フロー・DLP・RBAC・5年分の監査ログ を提供し、Isolate 戦略を統制の効いた形で運用可能にします。
- 設計知見を自社に残す：どのツールを選び、どこで圧縮し、どうサブエージェントを切るか——この コンテキストの設計知見こそが、再現性のある競争力（オペレーション学習） です。homula は戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化を一気通貫で支援し、この知見を自社に残すことを重視します。定型業務では処理時間 93%削減 といった成果も出ています。
なお、「モデルよりハーネス（実行の枠組み）」という近い論点は 「どのモデルか」から「どのハーネスか」へ でも扱っています。本稿の「コンテキストエンジニアリング」は、そのハーネスの中で トークンの流れをどう設計するか に踏み込んだものと捉えてください。
まとめ
2026年年央、業界の合意は明確になりました。長時間エージェントの信頼性は、より賢いモデルを待つことではなく、その周りのコンテキストを設計すること から生まれる——コンテキストエンジニアリングです。
Write でウィンドウの外に逃がし、Select で必要分だけ引き込み、Compress で削り、Isolate で分ける。この4つを回し切ることが、PoCでは動いたのに本番で崩れるエージェントと、何十ステップも安定して走り切るエージェントを分けます。日本企業がとるべき初手は、モデルの乗り換えではなく、自社の業務に合わせた文脈設計を、統制の効いた基盤の上で作り込むこと です。
「PoCでは動いたのに本番で不安定」——その多くはモデルではなく文脈設計の問題です。homula が、ツール選定から圧縮・分離の設計、統制、内製化までを伴走します。