コード化されたインテリジェントエージェントにおける高度なコンテキストエンジニアリングの応用 Human Layer の創設者 @dexhorthy は、自身の経験と実際の例に基づいて、プロトタイプから製品レベルのコードへの変換を重視しており、その中心となるのは LLM の「コンテキスト ウィンドウ」、つまりモデルの入力情報の品質と構造の最適化です。 背景：コンテキストエンジニアリングの起源とAIコーディングの進化 Dex氏は「コンテキストエンジニアリング」という用語の起源を遡り、2022年4月に「12 Factor Agents」というマニフェストを発表し、信頼性の高いLLMアプリケーションのための12の原則を探求しました。2024年6月には、この用語はより広く知られるようになりました。彼は今年のAIエンジニアカンファレンスの2つの基調講演を引用しました。1つはショーン・グローブ氏の「The New Code」で、ソフトウェアの未来はコード自体ではなく仕様が中心であると強調しました。もう1つは、10万人の開発者のデータを分析したスタンフォード大学の研究で、AIコーディングはプロトタイピングを加速させる一方で、大規模なエンタープライズ環境やレガシーコード環境では、やり直しや逆効果につながることが多いことが明らかになりました。AI生成コードは、複雑なタスクのやり直し率を最大50%増加させる可能性があるのです。 Dexの見解は、現在のモデルでは複雑なシステム（競合状態やシャットダウン順序を含むGoアプリケーションなど）の人間が書いたコードを完全に置き換えることはできないというものです。したがって、コンテキストエンジニアリングの目標は、既存のモデルから最大限の価値を「引き出す」こと、つまり、入力を慎重に設計することで出力の精度と効率を向上させることです。 主な課題: 従来の AI コーディング方法はなぜ失敗するのか? • 単純なプロンプト: エージェントとの対話を繰り返すだけで (「いいえ、もう一度試してください」など)、コンテキスト ウィンドウが簡単に使い果たされ、モデルが混乱したり、「ノイズ」(無関係な情報) が生成されたりする可能性があります。 • コンテキストボトルネック：LLMは本質的に「純粋関数」であり、出力の品質は入力のみに依存します。コーディングエージェントの反復プロセス（ファイルの検索、プロセスの理解、コードの編集）によってウィンドウがすぐに埋め尽くされ、情報過多、情報欠落、またはエラーが発生します。 • チームの問題点：AIが生成した2万行のコードプルリクエスト（PR）はレビューが難しく、チームの連携が崩れる原因となっています。Dex氏は自身の経験を共有し、トップクラスのAIコーダーと仕事をしていた際に、行単位のレビューを断念せざるを得なくなり、仕様書に頼って「手放す」ことにしたと述べています。 目的: 大規模で複雑なコードベースに適しており、現実世界の問題を解決し、「ガベージ」コードがなく、製品レベルの出力が得られ、トークンの使用率が最大化されます。 主要戦略: 圧縮からワークフローのリファクタリングへ Dexは「あらゆるもののためのコンテキストエンジニアリング」という概念を提唱し、正確性（誤った情報がない）、完全性（欠落情報がない）、サイズ（ノイズの制御）、軌道（方向の維持）という4つの側面を最適化しました。彼は非効率的なツール（単純な/slashcompactコマンドなど）を避け、代わりに以下の高度な手法を採用しました。 1. 意図的な圧縮： 単純な再起動の代わりに、「進捗ファイル」が作成され、主要な概要（ファイルパス、変更の意図、テスト計画など）が記録されます。これは元のコードよりもはるかに短く、後続のプロキシがコンテキストを継承しやすくなります。 • 定型的な思考：有効トークン数 ≈ 総トークン数（約17万） - ノイズトークン数。DexはJeff Huntleyの「ソフトウェアエンジニアとしてのRalph Wigum」の記事を引用し、同じプロンプトをループ処理することで（ランダムに反復処理するのではなく）結果が大幅に改善されることを証明しています。 2. サブエージェントのコンテキスト制御: • メインコンテキストを汚染することなく、「情報ストリームの検出」などのタスクを分離するために使用されます。サブエージェントは構造化された応答（例：ファイル名 + 行番号）を返すため、「伝言ゲーム」を連想させる情報の歪みを回避できます。 課題: 非決定論的システムは混乱しやすいため、親エージェントが子エージェントに指示を出す方法について正確なガイダンスが必要です。 3. 頻繁な意図的な圧縮と3段階のワークフロー： • 調査フェーズ：オープンソースのプロンプトテンプレートを使用して、システムの概要（ファイル、データフロー、問題箇所）を生成します。出力は簡潔で、迅速なエージェントの特定に役立ちます。 • 計画フェーズ: エージェントは、すべての変更（ドキュメント、コードスニペット、検証手順）をリストアップして「実装計画」を作成する必要があります。計画は通常、コードよりも短く、人間がレビューしやすいものになります。 • 実装フェーズ：計画のコーディングに基づき、コンテキスト利用率を40%未満に維持します。各ステップの完了ごとに計画を更新し、新しいウィンドウを再起動します。 • 全体的なサイクル: 調査 → 計画 → 実装 → 人間によるレビュー → 反復。Dex は次のように強調しています。200 行の計画をレビューする方が、2,000 行のコードをレビューするよりもはるかに効果的です。早期にエラーを検出し、チームの「精神的な一致」を維持できるからです。これがコードレビューの核となる価値です。 これらのプロンプトテンプレートはオープンソースで、GitHub で入手できます。Dex 氏も認めています。「これは「魔法」ではありません。注意深く読み、調整する必要があります。」 実践的なケーススタディ：Rust の修正から WASM の統合まで · Rust コードベースの修正：Dex は、YC のもう一人の創設者である Vibhav（BAML の開発者）と協力し、30 万行に及ぶ Rust コードベースのバグを一気に修正しました。このプロセスは 75 分間のポッドキャストでドキュメント化され、最終的に CTO によって PR がひっそりとマージされました。これにより、レガシーシステムにも適用可能であり、手直しは不要であることが証明されました。 • 複雑な問題解決：Boundary社のCEOと協力し、WASMサポートを追加しながら、7時間以内に35,000行のコードを生成・記述しました。これはエンジニアリング作業に換算すると1～2週間に相当します。これにより、本番環境における戦略の実現可能性が検証されました。 意味と将来の展望 Dexの核となる洞察：コードエラーは上流から発生します。不適切な調査は数千行の不適切なコードにつながり、不適切な計画はそれを数百倍に増幅させます。したがって、コードの詳細にこだわるのではなく、仕様とシステムの理解に投資することを優先してください。彼のチーム（3人）は1ヶ月で大量のAPIクレジットを消費しましたが、エンジニアリング時間を大幅に節約しました。インターンは初日に2件、8日目までに10件のプルリクエストを提出しました。Dex自身も2ヶ月間、Markdown以外のファイルを一切開きませんでした。 展望：コーディングエージェントはコモディティ化が進む傾向にありますが、課題はチームの変革（仕様を最優先に考え、頻繁にレビューを実施すること）にあります。Human Layerは、Y Combinator傘下の6人規模のスタートアップ企業から数千人の従業員を抱える大企業への変革を支援しています。 ビデオアドレス:
