AIエージェントに「これやって」と言えばよかった時代がありました。たった2年前の話です。でも今は、エージェントがミスをしたらエージェントではなくシステムを直すことが常識になりました。プロンプト・エンジニアリング → コンテキスト・エンジニアリング → ハーネス・エンジニアリング。4年でパラダイムが3回変わったのです。
これは何？
AWS Korea データサイエンティストのキム・ヨンミン氏がまとめた「AIエージェントパターン4年の記録」が開発者コミュニティで話題です。単なるトレンド整理ではなく、各時代がなぜ失敗したのかを追う剖検レポートに近いものです。
核心はこうです。2022年には「何を言えばいいか？」を考えていました。プロンプトさえうまく書けばAIがやってくれると信じていた。2025年になると「何の情報を入れるか？」に変わりました。プロンプトよりコンテキストウィンドウに何を詰め込むかが重要だと気づいたのです。そして2026年、「どんなシステムを作るか？」になりました。
面白いのはこの転換の起源です。「ハーネス・エンジニアリング」という言葉は、2026年2月にTerraformの生みの親Mitchell Hashimotoが初めて使いました。彼の原則はシンプルでした。「エージェントがミスをするたびに、そのミスが再発しないよう環境を修正せよ。」プロンプトを直すのではなく、エージェントを取り巻くシステム — ルール、ツール、制約、フィードバックループ — を変えることです。
驚くのはその直後に起きたことです。2週間以内にOpenAI、Martin Fowler（ThoughtWorks）、Ethan Mollick（ウォートン教授）がそれぞれ独立して同じ結論を発表しました。事前調整はありませんでした。全員が同じ壁にぶつかっていたから可能になった「同時発見」でした。
核心公式
エージェント = モデル + ハーネス
ハーネスとは「エージェントからモデルを引いた残り全て」です。モデルはエンジン、ハーネスはOS。どんな強力なエンジンもOSなしでは使えません。
何が変わるの？
Chad Fowler（Honeycomb CTO）がこの変化を一言でまとめました。「厳密さは消えない。移動するだけだ。」 XP運動が「設計書の代わりにテストコード」を主張したときも、動的言語がコンパイラなしでデプロイすると言ったときも、従来派は「厳密さが失われる」と批判しました。毎回外れました。厳密さはより高い抽象レイヤーに移動しただけでした。
| 次元 | プロンプトエンジニアリング (2022) | コンテキストエンジニアリング (2025) | ハーネスエンジニアリング (2026) |
|---|---|---|---|
| 核心の問い | 「何を言う？」 | 「何を見せる？」 | 「どんなシステムを作る？」 |
| 例え | メール文章術 | 受信トレイ管理 | メールシステム設計 |
| 失敗原因 | 盲目的プロンプト、非決定論 | コンテキスト汚染、情報過多 | オーケストレーションバグ |
| 核心指標 | 応答品質（主観的） | KV-cacheヒット率 | タスク完了率、コスト/タスク |
| 必要スキル | 言語センス | 情報アーキテクチャ | システム設計＋セキュリティ |
最も重要なポイントはこれです。各時代は前の時代を置き換えるのではなく、包含します。ハーネスエンジニアリングの中にコンテキストエンジニアリングがあり、その中にプロンプトエンジニアリングがあります。「プロンプトエンジニアリングが死んだ」は間違いです。死んだのではなく昇格した — より大きなシステムのサブモジュールになったのです。
実践事例を見るとより明確になります。OpenAIはCodexで100万行のコードベースを手動コード0行で作りました。7人のエンジニアが5か月間コードを一行も書かなかった。代わりにコードが安定して生成される環境を設計しました。Anthropicは3エージェントアーキテクチャで作るエージェント、評価するエージェント、計画するエージェントを分離しました。
核心まとめ：今すぐ始める方法
- AGENTS.mdを「目次」として作る
巨大な指示書の代わりに、100行の地図を作りましょう。エージェントが必要な情報を自分で探しに行けるようにするためです。OpenAIが「地図を渡せ、1000ページのマニュアルではなく」と強調した理由です。 - ミスのたびにハーネスを更新する
エージェントが誤ったコマンドを繰り返すならAGENTS.mdを直し、構造的なミスを繰り返すならリンターやテストを追加してください。Hashimotoの核心原則 — 「エージェントを責めずハーネスを改善せよ」。 - 機械的強制を導入する
文書化だけでは不十分です。カスタムリンター、構造的テストでアーキテクチャルールを強制しましょう。エージェントがリンターを通過するために自分でコードを修正するようにします。 - 「剥がせる」ハーネスを設計する
モデルが進化すると既存のエラー回復ロジックの半分が不要になります。ハーネスは剥がせる（rippable）ように作りましょう。過度なエンジニアリングは次のモデルアップデートの足を引っ張ります。 - エージェントを常に動かす
Hashimotoの目標は「常にエージェントが動いている状態」です。1日の最後の30分にエージェントを動かし、翌朝進捗を確認するパターンから始めてください。
セキュリティ注意：Lethal Trifecta
Simon Willisonが警告する3つが同時に存在するとセキュリティ事故は必然です：(1) 信頼できない外部入力の処理 (2) 機密データへのアクセス (3) 状態変更能力。Metaの「Rule of Two」— エージェントにはこのうち最大2つだけを同時に許可しましょう。
