Harnessエンジニアリングで変わるAIエージェント構築の最前線

内部リンクを追加した修正版を出力します。本文の関連箇所にサイト内リンク2本を自然に組み込みます。

「モデルは優秀なのに、エージェントが使えない」——その原因

Stack Overflow が2025年に実施した調査によれば、開発者の84%がすでにAIツールを使用中、または導入を予定している（Endor Labs）。しかし現場では「プロトタイプは動くが、本番に出すと壊れる」という声が絶えない。コンテキストの忘却、無限ループ、非決定論的な出力、そしてセキュリティの穴——これらはモデル性能の問題ではなく、エージェントを囲むシステム設計の問題だ。

METR が2025年に発表した研究では、熟練した開発者がAIツールを使うと、むしろタスク完了が19%遅延するケースが確認されている（Endor Labs）。ツールを導入しても、それを支える構造が整っていなければ生産性は上がらない。この問題意識を工学的に整理したのが、2026年初頭に定式化された「Harnessエンジニアリング」という概念である。

公式の定式は簡潔だ。Agent = Model + Harness（faros.ai）。モデルは方程式の一変数に過ぎない。もう一方の変数——ツール、メモリ、ガードレール、検証、オブザーバビリティからなる「ハーネス」——を設計する工学的規律こそが、AIエージェントを本番環境で機能させる鍵になる。これはLLMそのものの改良ではなく、機械学習システムを実運用に耐えうる構造へ落とし込むエンジニアリングの問題だ。

関連記事AIエージェントの料金体系はどうなっている？ ／ AIエージェントはどれを選べばいい？

Harnessエンジニアリングが定式化された背景

AI工学の成熟段階を faros.ai は次のように整理している。

• 第1フェーズ（2022–2023年）：プロンプトエンジニアリング
• 第2フェーズ（2024–2025年）：コンテキストエンジニアリング
• 第3フェーズ（2026年）：ハーネスエンジニアリング

プロンプトを磨き、コンテキストを整えるだけでは解決できない問題群——実行の信頼性、セキュリティ、観測可能性——が顕在化したことで、より上位の抽象レイヤーが必要になった。HashiCorp共同創設者のMitchell Hashimotoが2026年2月初頭にこの概念をブログで提唱し、OpenAIのRyan Lopoloが同年2月11日に正式定義として発表したことで、業界内での議論が加速した（Augment Code）。

「Harnessエンジニアリング」という用語自体は新しいが、その実践はHaystackなど既存フレームワークで先行していた（deepset Blog、2026年5月）。名前がついたことで、設計のパターン言語が共有されるようになった。マルチモーダルAIの普及によってエージェントが扱う入出力の多様性が増したことも、マルチモーダルモデルの構造的理解とともに、ハーネス設計の重要性を押し上げる背景になっている。

5層ハーネスの構成と、Claude Codeを例にした実装

faros.ai が整理した5層構造を、実際のエージェント構築に照らして見ていく。

① ツールオーケストレーション

エージェントが呼び出すツール群（検索、コード実行、外部API等）を管理する層。ツールの定義・選択・呼び出し順序を制御する。設計が甘いと、ツールの誤呼び出しや連鎖エラーが本番障害に直結する。

② 検証ループ

エージェントの出力が期待するスキーマや制約を満たすかを検証し、満たさなければ再試行させる仕組み。これを持たないエージェントは、一度出力が壊れると無限ループか不正データの伝播を引き起こす。

③ コンテキスト＆メモリ

長いタスクで状態を維持する仕組み。セッションをまたいだ記憶（長期メモリ）と、現在の作業文脈の管理（短期メモリ）を分けて設計する必要がある。コンテキストの忘却はエージェント障害の最頻原因の一つだ（deepset Blog）。

④ ガードレール

入力と出力の両方にフィルタを置き、有害・不正・ポリシー違反のコンテンツや操作を遮断する。Apiiro が2025年9月に分析したデータによれば、AI生成コードは2025年6月時点で月1万件を超えるセキュリティ問題を新規に導入しているとされる（Augment Code）。ガードレールはセキュリティの防御ラインとして機能する。

⑤ オブザーバビリティ

エージェントの実行ログ、トレース、メトリクスを収集・可視化する層。何が起きたかを再現できなければ、障害の原因究明も改善もできない。本番運用では「見える化」が設計の前提になる。

これら5層を、Claude Code向けに実装する場合、X上のビルダーコミュニティが共有しているフレームワークが参考になる。CLAUDE.md（メモリファイル）、スキル、ガードレール、サブエージェント、プラグインという5要素がそれぞれ上記5層に対応する構成だ（x.com）。CLAUDE.md がコンテキスト管理を担い、スキルがツールの定義を担い、サブエージェントが検証ループの実装を支える。

主要フレームワークの比較

Harnessエンジニアリングを実践するうえで参照されるオープンソースフレームワークを整理する。

フレームワーク	主な用途	特徴	適合する設計層
Letta	自己改善型エージェント	長期メモリと自己修正ループを統合	③コンテキスト＆メモリ、②検証ループ
CrewAI	マルチエージェントチーム	役割分担と協調を宣言的に定義	①ツールオーケストレーション
Haystack	RAG・パイプライン構築	コンポーネント単位の組み合わせ設計	①③の実践的先行実装（deepset Blog）

注：LettaとCrewAIについては、現時点でXのポスト経由の言及が主であり、独立した一次情報源による詳細仕様の確認が十分にとれていない。導入検討の際は各プロジェクトの公式ドキュメントで最新の仕様を確認することを推奨する。

Harnessエンジニアリングが解決できること、解決できないこと

設計上の限界を正直に述べておく。

ハーネスが有効に機能するのは、エージェントに課すタスクが明確に定義でき、検証の基準を事前に設計できる場合だ。ゴールが曖昧なタスク、ドメイン知識が希薄な領域、あるいは「正解が存在しない」創造的作業では、ガードレールや検証ループの設計そのものが困難になる。

また、ハーネスを適切に設計するには相応のエンジニアリングコストがかかる。5層すべてを初期から整えることは現実的でない場合も多く、まずオブザーバビリティとガードレールを先行させ、観測データをもとにメモリと検証の設計を改善するという段階的アプローチが実務上は合理的だ（Arize AI、2026年8月）。

さらに、ハーネスはモデルの判断誤りを構造的に減らす仕組みだが、誤りをゼロにはしない。特に法的判断、医療、金融など高リスク領域での自律的な意思決定には、人間のレビューを設計に組み込む必要がある。

明日から始める具体的な一歩

エージェント構築の出発点として最も即効性が高いのは、オブザーバビリティの先行実装だ。現在動かしているエージェントがあれば、まず全実行のログと入出力を記録する仕組みを入れる。何が起きているかが見えなければ、他の4層の設計改善は目測になる。

次にガードレールの最小設計。禁止する出力パターン（機密情報の漏洩、想定外のシステム操作など）を列挙し、出力フィルタとして実装する。Apiiroのデータが示すように、AI生成コードのセキュリティリスクは規模が大きくなるほど急増する（Augment Code）。初期から組み込む方がコストは低い。

CLAUDE.mdのようなメモリファイルの活用は、長期タスクで効果が出やすい。エージェントが「忘れる」場面を特定し、その状態を外部ファイルに書き出す設計を加えるだけで、コンテキスト管理の精度は大きく改善しうる。

AIエージェントの信頼性は、モデルの選択より設計の質で決まる。Harnessエンジニアリングが示すのは、その設計を工学的に体系化するための共通言語だ。

---

参考文献

• Faros　https://www.faros.ai/blog/harness-engineering
• Endor Labs　https://www.endorlabs.com/learn/harness-engineering-how-to-make-ai-coding-agents-reliable-and-secure
• Augment Code　https://www.augmentcode.com/guides/harness-engineering-ai-coding-agents
• deepset Blog　https://www.deepset.ai/blog/harness-engineering
• Arize AI　https://arize.com/resources/harness-engineering/
• x.com　https://x.com/i/trending/2117603924928758218