ハーネスエンジニアリングとは？AIの性能を引き出す制御設計
ハーネスエンジニアリングとは何か
ハーネスエンジニアリングとは、AIエージェントの動作を制御・制約する設計手法です。2026年2月にOpenAIが公式ブログで使い始めた言葉で、その後Anthropic、LangChain、Martin Fowlerなど業界の主要プレイヤーがそれぞれの解釈を発表しています。
LangChainは「Agent = Model + Harness（エージェント = モデル + ハーネス）」と定義しました。つまり、ハーネスとはモデル以外のすべて——プロンプト、ツール設定、実行ロジック、品質チェックの仕組みを指します。
なぜ今この概念が注目されているのか。それはAIモデルの性能が十分に高くなった今、ボトルネックはモデルの外側にあると多くの実務者が気づき始めたからです。
レースカーに学ぶ「制限が性能を上げる」原理
ハーネスエンジニアリングの本質を一言で言えば、「制限することで本質的な価値を高めること」です。
レースカーを想像してください。どれだけ強大なエンジンを積んでいても、それだけではレースに勝てません。エンジンのパワーを路面に伝える車体（シャシー）、コーナーで制御するサスペンション、そしてドライバーの意図を反映するステアリングが必要です。
エンジンの出力をあえて制限する場面すらあります。しかしその結果、ゴールへは確実に近づき、全体としてのパフォーマンスは向上する。これがハーネスエンジニアリングの考え方です。
AIエージェントも同じです。Claude OpusやGPT-5クラスのモデルは、膨大な知識と推論能力を持っています。しかし「何でもできる」状態のまま業務に投入すると、余計なことをしたり、品質にムラが出たり、セキュリティ上の問題を見落としたりします。適切に制限し、制御し、監視することで初めて、モデルの持つ本来の力が業務成果に変わるのです。
各社が語るハーネスエンジニアリング——5つの視点
興味深いのは、この概念に対して各社がまったく異なるアプローチを取っていることです。
OpenAI——「人間が舵を取り、エージェントが実行する」
OpenAIのエンジニアRyan Lopopolo氏は、5ヶ月間エンジニアが手動でコードを1行も書かず、Codexエージェントだけで約100万行のアプリを構築した事例を公式ブログで発表しました。核心は「Humans steer. Agents execute.（人間が舵を取り、エージェントが実行する）」という原則です。
エンジニアの役割は「コードを書くこと」から「エージェントが成果を出せる環境を設計すること」に変わったと述べています。
Anthropic——コンテキスト管理と品質の分離
Claude Codeの開発元であるAnthropicは、ハーネス設計に関する記事でGenerator-Evaluator構造を提唱しています。作業するエージェントと評価するエージェントを分離する考え方です。
背景には「エージェントは自分の仕事を評価すると、常にポジティブに偏る」という発見があります。人間でも自分の仕事を客観的に評価するのは難しいですが、AIも同じです。だからこそ、作業と評価を分離する設計が重要になります。
また、「Context anxiety（コンテキスト不安）」という概念も指摘しています。コンテキストウィンドウの上限が近づくと、AIが作業を早期に切り上げてしまう傾向があるという問題です。
LangChain——ハーネスだけで性能13.7%向上の実証
LangChainはベンチマークによる定量的な実証を行いました。同じモデル（GPT-5.2 Codex）を使い、ハーネスの設計だけを変更した結果、タスク達成率が52.8%から66.5%に向上（+13.7ポイント）しました。
モデルを変えずに性能が13.7%上がる。これはハーネスエンジニアリングの価値を数字で証明した重要なデータです。
Martin Fowler——ガイドとセンサーの2軸
ソフトウェア設計の権威であるMartin Fowlerのサイトでは、Birgitta Bockeler氏がハーネスを2軸で整理しています。
- ガイド（フィードフォワード制御）: エージェントが動く前に、正しい方向へ誘導する仕組み
- センサー（フィードバック制御）: エージェントが動いた後に、結果を検知して修正する仕組み
「良いハーネスは人間の入力を完全に排除するのではなく、人間の判断が最も重要な場所に集中させるべきだ」という指摘は、実務で非常に共感できる視点です。
全員が一致している4つのポイント
解釈は異なりますが、全員が同意している点もあります。
- モデルの外側の設計が成果を左右する
- 制約は「お願い」ではなく「強制」すべき
- フィードバックループが不可欠
- プロンプトエンジニアリングは不要にならない（ハーネスの一部として残る）
実務で実践しているハーネスの3層構造
私はClaude Codeを2025年10月から業務の中心に据えて使い込んでいます。コーディングだけでなく、記事執筆、提案書作成、調査、ナレッジ整備まで、ほぼすべての業務をClaude Code経由で行っています。
その中で実感しているのは、Claude Code自体が賢くなっているというよりも、ハーネスが整備されてきたことで、セッションごとの出力品質が確実に向上しているということです。
私が実践しているハーネスは、大きく3つの層に分かれます。
第1層：ガイドライン（CLAUDE.md・ルールファイル）
CLAUDE.mdとルールファイルは、Fowlerの分類でいう「ガイド（フィードフォワード制御）」にあたります。エージェントが動く前に、方向性を定める仕組みです。
ただし、ここで重要なのは「書きすぎない」こと。CLAUDE.mdへの記載量が一定以上増えると、コンテキスト量の増加により逆に作業精度が下がるという報告があります。
これはまさにハーネスエンジニアリングの本質——「制限が性能を上げる」——を体現しています。ガイドラインを増やせば精度が上がるわけではなく、必要最小限に絞ることで最大の効果が出ます。
第2層：Skills・コマンドによる行動の型化
Skillsは「繰り返し行う業務の手順書」です。SEO記事の執筆、画像生成、MicroCMSへの投稿といった一連のワークフローを、再現可能な形でスキルとして定義しています。
スキルの価値は、エージェントに「何をすべきか」だけでなく「どの順番で、どの基準で」を明示できること。コンテキストに頼らず、毎回同じ品質で作業が完了します。
第3層：Hooksによる強制的な品質監視
Hooksは、Fowlerの分類でいう「センサー（フィードバック制御）」です。エージェントが作業した後に、強制的にチェックをかける仕組みです。
AIが間違えやすい部分には共通点があります。記事執筆時の表記ルール違反、クライアント情報の混入、Webサイト制作時のSEO設定やインデックス設定の漏れ。こうした「毎回同じパターンで起きるミス」に対して、Hooksで第三者的な品質管理をAIに任せたことで、品質が大幅に改善しました。
Anthropicが提唱するGenerator-Evaluator構造を、Hooksという機能で実装しているとも言えます。作業するAIと、それを監視するAIを分離することで、自己評価バイアスの問題を解消しています。
ハーネスエンジニアリングが解決する「コンテキスト問題」
AIエージェントを実務で使い込むと必ずぶつかるのが、コンテキスト量の増加による品質低下です。
業務が複雑になればなるほど、エージェントに渡す情報は増えます。しかしAnthropicが指摘するように、コンテキストが膨れるほどAIの注意力は散漫になり、「Context anxiety」が発生します。
ハーネスエンジニアリングは、この問題に対する方法論の一つです。「何を見るか」「何を守るか」をハーネスで絞ることで、コンテキストが多くなっても品質を維持できる。すべてをAIに丸投げするのではなく、AIが集中すべきポイントを制御する。これがハーネスの役割です。
LangChainのベンチマーク結果（ハーネスのみで+13.7%）は、この考えを裏付けています。モデルの能力は同じでも、「何に集中させるか」の設計次第で成果は大きく変わるのです。
明日から始めるハーネスエンジニアリング3ステップ
ハーネスエンジニアリングは理論だけでなく、今日から実践できる具体的な手法です。
ステップ1：CLAUDE.md / AGENTS.mdを書く
まずは最小限のガイドラインから始めます。プロジェクトの目的、守るべきルール、ファイル構成を500文字程度で記述するだけで効果を実感できます。書きすぎないことが重要です。
ステップ2：品質ゲートを自動化する
リンター、型チェック、テストをHooksで強制実行させます。「お願い」ではなく「通らなければ先に進めない」仕組みにすること。各社が一致して「制約は強制すべき」と述べている理由がここにあります。
ステップ3：フィードバックループを回す
ハーネスは一度作って終わりではありません。エラーパターンを検出したら制約を追加し、不要な制約は削除する。この反復がハーネスを進化させます。
私自身、知見蓄積のルールを「learnings/に月単位で蓄積→月末に棚卸し→重要なものは正式ルールに昇格」というサイクルで運用しています。日々の業務から得た気づきが、翌月のハーネスを改善する。この積み重ねが、セッションごとの出力品質向上として実感できています。
まとめ：モデルの性能競争から、ハーネスの設計競争へ
ハーネスエンジニアリングは、AIの「使い方」を設計する技術です。
OpenAI、Anthropic、LangChain、Martin Fowler——それぞれ視点は異なりますが、全員が指し示す方向は同じです。モデルの能力が十分に高い今、差がつくのはモデルの外側の設計である、と。
レースで勝つのは、最もパワフルなエンジンを積んだチームではありません。エンジンの力を最も効率よくゴールに変換できるチームです。AIの活用も同じ段階に入りました。
「AIを導入したけれど期待通りの成果が出ない」——そう感じている方は、モデルの選定や機能の追加ではなく、ハーネスの設計を見直すことから始めてみてください。制限が、あなたのAIの性能を引き出します。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。