|
|
🤖 AIプログラミング進化史：プロンプト、コンテキストエンジニアリングからHarnessへ
同等の能力を持つモデルが増えるにつれ、各社製品の体験の差はかえって広がっています。 ある製品が生成したコードはそのままコミットしてリリースできるのに、別の製品が生成したコードは保守が困難です。それはなぜでしょうか？ モデル自体は同じだからです。差は、モデルをどう使うか、どう安定して使うかにあります。 AI業界では、これを Harness Engineering（ハーネス・エンジニアリング / 制御工学） と呼びます。
🧠 Harnessエンジニアリング：Agentを3つの層に分割する
プログラミングAgentを3つの層に分けます：
- Scaffolding（足場） システムが準備したツールを含め、AIがタスクを実行する前のすべての準備作業を担当します。
- Harness（ランタイムオーケストレーション、コア） エージェント全体のコアとなるディスパッチセンター。 AIのコア推論ループを管理・制御し、ツールの呼び出し、コンテキスト管理、実行時の安全制御、およびセッションデータの永続的ストレージを調整します。
- Context Engineering（コンテキストエンジニアリング） 大規模モデルがテキストを処理する最小計算単位であるトークン（token）のリソース割り当てを管理します。 AIの実行プロセスにおいて、どの情報を保持し、どの情報を破棄すべきかを決定します。
安定して動作するAIコードエージェント = 呼び出される1つまたは複数の大規模モデル + 完璧なHarnessシステム。
⏳ Harnessは重要だが、なぜ今になって注目されているのか？
① 第1段階：Prompt Engineering（プロンプトエンジニアリング）
核となる焦点：いかに優れた指示（プロンプト）を書くか。
- 役割設定：AIに明確なアイデンティティと責任の境界を定義する。
- 例の提示：Few-shotを用いて、AIに特定のフォーマットやスタイルに従って生成させる。
- 思考の連鎖（Chain-of-Thought）：指示の中でAIに問題を段階的に分解し、論理的に推論させることで、飛躍的なエラーを減らす。
② 第2段階：Context Engineering（コンテキストエンジニアリング）
単一のプロンプトではもはや不十分であり、モデルのためにコンテキスト環境全体を動的に構築する必要があります。 モデルが意思決定を行うたびに、タスクファイル、会話履歴、ツールのルール、ナレッジベースの項目など、必要なすべての情報を正確に参照できるようにします。
コア理念：モデルに見るべきものを見せ、見るべきでないものを遮断する。
③ 第3段階：Harness Engineering（ハーネス・エンジニアリング）
エージェントが間違いを犯したのを発見するたびに、同じ間違いを繰り返さないよう、時間をかけてエンジニアリング的に解決する。
モデルの能力は十分なのに、言うことを聞かない。どうすればいいのか？ その答えが、Harness Engineeringです。
実際の事例：
| 実験 | 条件 | 結果 |
|---|---|---|
| LangChain | 同じモデルで、Harnessのみを最適化 | Terminal Bench 2.0：52.8 → 66.5 |
| Nate B Jones | 同じモデル、同じプロンプトで、実行環境のみを変更 | コーディングベンチマーク勝率：42% → 78% |
| OpenAI | 空のGitリポジトリから開始し、5ヶ月間完全にAIエージェント主導 | 約100万行のコード、1500件のPRを生成し、人間の介入はゼロ |
Agentは難しくない。難しいのはHarnessだ。
💥 AIのタスクはなぜ頻繁に失敗するのか？
1. 一歩で全てを完了させようとする 1つのウィンドウで全ての機能を完成させようとした結果、コンテキストウィンドウが急速に枯渇し、後半の品質が絶壁のように低下します。
2. 早すぎる勝利宣言 複雑なプロジェクトの開発後半において、AIエージェントがコア機能を完了し目に見える成果を出すと、多くの機能が未実装でコア要件が満たされていなくても、タスクが完了したと直接判断して自発的に終了してしまいます。
3. 早すぎる機能完了のマーク AIエージェントは特定の機能を書き終えると、すぐに完了としてマークします。エンドツーエンドの完全な機能テストを自発的に行うことはなく、実際の環境で本当に使えるかどうかの検証もしません。動くように見えて、実際には至る所に隠れたバグが存在します。
4. コードパターンの機械的なコピー AIは既存のコードパターン（アーキテクチャスタイル、コーディング規約）を機械的に踏襲します。たとえそのパターンが間違っていても、プロジェクト全体で継続的に増幅させます。制約のないAIエージェントは、猛烈なスピードでプロジェクトに大量の技術的負債を蓄積していきます。
🛡️ Harnessの4つのガードレール
🔹 1. コンテキストエンジニアリング
AGENTS.MD ファイルが長く情報が冗長になるほど、Agentのタスク成功率は低くなり、一方で推論コストは高くなります。 AGENTS.MDファイルは厳格に60行以内に抑えるべきです。
コンテキストは希少なリソースであり、過剰な指示は本当に重要なタスクのコードを押し出してしまいます。
🔹 2. アーキテクチャの制約（最も重要）
厳格なレイヤードアーキテクチャを実行します。プロンプトでAgentに「アーキテクチャを遵守してください」と伝えるのではなく、決定論的なLinterと構造化テストを使用して機械的に実行させます。
Linterのエラーメッセージに修正ガイドラインを直接埋め込み、Agentにどう修正すべきかを伝えます。制約は指示よりも効果的です。
🔹 3. フィードバックループ（Feedback Loop）
Harnessにおいて、コードレビューはAgent対Agentの方式になります。 標準化されたクローズドループ（計画と発見 → 構築 → 検証 → 修正）を形成し、これを繰り返すことでコードの品質を継続的に純化します。
🔹 4. エントロピー管理
時間の経過とともに、AIが生成したコードには多くの問題が蓄積されます。ドキュメントの陳腐化、アーキテクチャのドリフト、スタイルの崩れ、デッドコードの堆積などです。 AgentにAgentのためのドキュメントを保守させることで、継続的にエントロピーの増大に対抗し、プロジェクトの腐敗を防ぎます。
🧭 まとめ
AIプログラミングの進化は、本質的に「優れたプロンプトを書く」ことから「優れたシステムを構築する」ことへのパラダイムシフトです。
- Prompt Engineering は「どう伝えるか」を解決します。
- Context Engineering は「どの情報を与えるか」を解決します。
- Harness Engineering は「どう制御するか」を解決します。
これら3つの路線は代替関係ではなく、重ね合わせの漸進関係にあります。各層は前の層の基盤の上に構築されます。本当に安定して高品質なコードを産出できるAIプログラミング製品は、必ずこれら3つのレベルすべてにおいて多大な努力を注いでいます。