モデルの性能より「ハーネスの出来」で差がつく ――AIエージェントを正しく制御する「ハーネスエンジニアリング」とは？

【17-B-9】ハーネスエンジニアリングがもたらす開発プロセスの変化とは？

　2026年7月16日に開催された「Developers Summit 2026 Summer」において、セッション『ハーネスエンジニアリングがもたらす開発プロセスの変化とは？』が行われた。本セッションでは、Asterminds株式会社 共同創業者・CTOの加賀谷諒氏をモデレーターに迎え、株式会社Algomatic リードエンジニアの宮脇峻平氏、株式会社シン・ミキイシジマ 代表取締役のイシジマミキ氏が登壇。AIプロダクト開発や組織ガバナンス、デザインといった多様な視点から、近年話題を集める「ハーネスエンジニアリング」の概念と、それを組織としてどう適用していくべきかについて深い議論が交わされた。

ハーネスエンジニアリングの基本概念と実践事例

　セッションの導入として、加賀谷氏から「ハーネスエンジニアリングとは何か」という概要と定義が共有された。

　「ハーネス（Harness）」という言葉は元々、馬に装着してコントロールする「馬具」に由来する。AIエージェントの文脈においては、政策やモデルを思い通りに制御し、意図した仕事をさせるための仕組み全体を指す言葉として使われている。

　一般に、AIエージェントは「モデル＋ハーネス」という方程式で表現されることが多い。Claude CodeやCodexといったコーディングエージェントを例にとると、核となるモデルの周りに、コード実行やツール呼び出し、検証ループといったモデル以外の周辺システム（＝ハーネス）が組み合わさる。これらが合わさることで、初めて実用的なエージェントとして機能するのだ。

　加賀谷氏は、研究や実践の現場で言われる「そこそこのモデル × 良いハーネス ＞ 最高のモデル × 悪いハーネス」という知見を紹介した。モデル単体の性能向上以上に、制御機構であるハーネスの出来栄えが成果物の品質や自律性を左右するという。

Asterminds株式会社 共同創業者・CTO 加賀谷 諒氏

　また加賀谷氏は、利用者視点での理解を促すべく、ハーネスを大きく2つのレイヤーに整理して提示した。

• エージェントハーネス（内部ハーネス）：Claude CodeやCodexなどのプロダクト自体に最初からビルトインされている実装層。オーケストレーション、ツール実行、メモリ保持、ガードレール、検証ループなどを担う。
• ユーザーハーネス（外部・ガイドハーネス）：利用者が自分たちの開発環境やリポジトリに載せる制約や仕組み。AGENTS.mdやCLAUDE.mdといったルールファイル、Skills、フック（Hooks）、MCP（Model Context Protocol）、テストやlintのコマンド実行環境などが含まれる。

　加賀谷氏は「一般的な開発チームやエンジニアが向き合うのは、後者のユーザーハーネスである」と説明した。さらに、1回のエージェント実行を正しく成功させるための仕組みを「ハーネス（1回の質）」、それを中断させずに自律的に走らせ続ける仕組みを「ループ（継続と自走）」と区別して捉えることが、実践的な整理として有効であると語った。

ハーネスエンジニアリングとループエンジニアリングについて

現場における「外部ハーネス」の実装アプローチ

　続いて、パネリストの2人から実際の開発や支援の現場でどのようなハーネスを組んでいるかが明かされた。

　Algomaticで企業のAX（AI Transformation）推進やガバナンス整備を主導する宮脇氏は、ハーネスを「モデルに何をさせるか」「何をさせないか」というリスクマネジメントの観点から構築していると語る。宮脇氏のアプローチは大きく2つに分かれる。

1. ベースラインの統制：ポリシー・アズ・コード（Policy as Code）の手法を用いて、コーディング規約や組織のAI原則を最低限遵守させる。また、ADR（Architecture Decision Records）などを活用し、設計の不変条件をコンテキストとして与える。
2. リスクベースの統制：特にデータのやり取りにおけるセキュリティリスクを重視する。エージェント間やツール呼び出しの境界でフックを噛ませ、失敗した際の影響度（品質コスト：Cost of Quality）が高い箇所を中心に制御を固める。

　宮脇氏は具体的なトラブル事例として、以前にエージェントがGitへ載せてはいけないシークレット情報をコミットしようとした経験を明かした。そのため同社では、GitのプレコミットフックにGitleaksやOpenAI Privacy Filterを設置し、データの流出を機械的にガードしている。

　一方、デザイン組織のコンサルティングを手がけるイシジマ氏は、デザイナーの視点から独自のハーネス実践を語った。デザインにおいては、セキュリティリスクよりも「生成される意匠の崩れ」を防ぐことが主眼となる。

　イシジマ氏は「フロントエンドの仕組みとして、.mdファイルなどに『まず白黒で作ってください』や『3つのグループに分けて優先順位をつけてください』といった基本的なデザイン原則を記述し、制約をかけている」と説明する。

　しかし、ルールを敷いた際によく起きる問題として「ルールをガチガチにしすぎると身動きが取れなくなる」という点を指摘した。イシジマ氏は、そのルールによって何を防ぎたいのかというリスクの根本を考える重要性を強調した。

　これに対し加賀谷氏は、事前・事後の検証軸と、ガイドライン・センサーの軸によるマトリックスでハーネスを分類する考え方を補足した。「デザイン原則のように事前かつガイドライン的に読ませるものと、コードのlintのように作成後にセンサーとして事後チェックさせるものを組み合わせる。そうすることで、ハーネスの欠けている部分が見えやすくなる」と述べた。