最近、開発者の界隈で「ハーネスエンジニアリング」という言葉をよく見るようになった。Claude Code や Codex のようなコーディングエージェントを使いこなす人ほど、関心がモデルそのものよりその周りの仕組みに移っている。同じモデルを使っても、成果に大きな差が出る。その差を生んでいるのが、このハーネスの設計。聞き慣れない言葉だけど、中身を分解すると、実は多くの人がすでにやっていることの延長線上にある。何を指していて、なぜ今これが効くのかを整理する。
- ハーネスエンジニアリングとは、「モデル以外の全部」を設計すること
- プロンプト→コンテキスト→ハーネス、関心の移り変わり
- 手綱は2種類、「先回りの誘導」と「事後の検証」
- 一番効く検証は、AIが言い逃れできない「テスト」
- どこまで仕組みで縛れるか、その限界
- まず一枚の指示書と、一本のテストの関所から
ハーネスエンジニアリングとは、「モデル以外の全部」を設計すること
まず言葉から。ハーネス(harness)は、もともと馬具や犬の胴輪を指す。馬がどれだけ力強くても、手綱や鞍がなければ、その力を目的の方向へ使えない。AI エージェントも同じ構図だと考えると、すっと腑に落ちる。
エンジニアの Martin Fowler は、ハーネスを「AI エージェントの中で、モデル以外のすべて」と定義している。システムプロンプト、使えるツール、記憶の持たせ方、出力の検証、複数の処理をつなぐ段取り。モデルという「考える部分」を取り囲む、制御の仕組み全体。あるエンジニアは「LLM は、エージェントシステムの中でいちばん小さな部分にすぎない」とまで言っている。賢い頭脳があっても、それを実用に変えるのは周りの作り込みだ、という見方。
このハーネスは、2 つの層に分かれる。ひとつは、ツールの作り手が用意する組み込みのハーネス。Claude Code 自体に最初から入っているシステムプロンプトやコード検索の仕組みがこれ。もうひとつが、使う側の自分たちが作るユーザーのハーネス。自分のコードベースやチームのやり方に合わせた、独自の指示書や検証の仕組み。ハーネスエンジニアリングというとき、主に意味するのは後者。自分の現場に合わせて、エージェントの手綱を握り直す作業のこと。
プロンプト→コンテキスト→ハーネス、関心の移り変わり
なぜ今これが流行っているのか。少し業界の流れを振り返ると分かりやすい。
最初は「プロンプトエンジニアリング」だった。AI にどう指示を書くか、という話。次に「コンテキストエンジニアリング」が来た。指示だけでなく、AI にどんな情報をどう渡すか、という話。そして今、関心が「ハーネスエンジニアリング」へ移り、さらに「ループエンジニアリング(エージェントを動かす反復の流れ自体を設計する)」という言葉まで出てきている。
正直に言うと、この呼び名の移り変わりには、少しバズワードの乗り換えっぽさもある。半年ごとに名前が変わって、新しい概念のように語られる。ただ、流行り言葉だと切り捨てるのはもったいない。底にあるのは一貫した変化で、「賢いモデルに良い一言を投げる」ことから、「モデルが良い仕事をせざるを得ない環境を作り込む」ことへ、エンジニアの仕事の重心が移っている。モデルが賢くなるほど、一発の指示でどうこうするより、周りの仕組みで成果を底上げするほうが効く。その実感が、この言葉を広めている。
手綱は2種類、「先回りの誘導」と「事後の検証」
では具体的に何を作るのか。Fowler の整理がいちばん分かりやすいので借りる。ハーネスの部品は、大きく 2 種類に分けられる。先回りで誘導するものと、やった後に検証するもの。
ひとつ目が「ガイド」。エージェントが動く前に、進む方向を先回りで示すもの。たとえば、コードベースの作法を書いた指示書(Claude Code なら CLAUDE.md、Codex 系なら AGENTS.md)、設計方針のドキュメント、特定の作業手順をまとめたスキル、型チェッカー。「うちではこう書く」「この部品を使う」を前もって伝えておくことで、的外れな方向に進むのを防ぐ。すでに CLAUDE.md にルールを書いている人は、知らないうちにこのガイドを作っている。
ふたつ目が「センサー」。エージェントが何かを書いた後に、それが正しいかを観測して返すもの。リンター(コードの書き方をチェックする道具)、型チェッカー、テスト、AI によるコードレビュー、本番での監視。間違いを後から捕まえて、人間のレビューに回る前に直させる。前にこのブログで Claude Code のセキュリティプラグインを取り上げたけれど、あれはまさに「書いたコードを別の AI が検証する」センサーの一種だった。
この 2 つを組み合わせて、エージェントが「最初から良いものを出す確率」を上げ、「出した後に自分で気づいて直す」ループを作る。これがハーネスの骨格。
一番効く検証は、AIが言い逃れできない「テスト」
センサーの中でも、何を使うかで信頼度が変わる。ここは押さえておきたい勘所。
検証の最上位とされるのが、決定論的なテスト。決定論的というのは、同じ入力なら必ず同じ結果が出る、という性質のこと。テストが通るか通らないか、リンターが警告を出すか出さないか。この種の白黒はっきりした結果に対して、AI は言い逃れができない。「たぶん大丈夫です」と取り繕えない。だから、機能の正しさを縛りたいなら、まずテストで固めるのが効く。
一方、AI にコードを評価させる「LLM-as-judge(裁判官としての AI)」は、柔軟で便利だけど、ごまかされやすい。数値で割り切れない読みやすさや設計の良し悪しを見るには向くが、それだけに頼ると甘い判定が通ってしまう。だから強いハーネスは、決定論的なチェックと AI の判断を組み合わせる。機械的に測れるものは機械で、測れない部分だけ AI に、という役割分担。
もうひとつ実践的な原則が「Keep quality left(品質を前倒しする)」。検査を、速くて安いものから順に並べて、開発の早い段階に寄せる考え方。コミット前には軽いリンターや型チェック、その後のパイプラインで重い解析、裏では継続的に不要コードや依存関係の監視。重い検査を全部最後にまとめてやると遅くなるので、メリハリをつける。コストと速度で検査を配置するこの発想は、従来の CI/CD のパイプライン設計とよく似ていて、エンジニアには馴染みやすいはず。
どこまで仕組みで縛れるか、その限界
景気のいい話ばかりではない。ハーネスには、はっきりした限界がある。
まず、コードベースによって手綱のかけやすさが違う。型がしっかりした言語、境界が明確な設計、確立されたフレームワーク。こういう「足場」が整っているほど、ハーネスは効く。逆に、型のゆるい言語や、入り組んで境界の曖昧なコードでは、仕組みで縛りにくい。
そして、いちばん本質的な未解決問題が「振る舞いのハーネス」、つまり機能が本当に正しいかを保証する部分。Fowler はこれを「部屋の中の象(誰もが気づいているのに手をつけられていない問題)」と呼んでいる。多くのチームは、AI が生成したテストでこれを担保しようとするが、彼ははっきり書いている。「この方法は AI 生成テストを過度に信頼している。まだ十分ではない」。テストそのものを AI に書かせて、そのテストで AI のコードを検証する。これでは、間違いが二重に通り抜ける余地が残る。前に「バイオ分野の AI エージェントの壁は、賢さより土台のデータだった」という記事を書いたけれど、ここでも似た構図がある。賢いモデルの周りの、地味な仕組みのほうが、成果を決めている。
さらに、ガイドとセンサーが増えるほど、互いに矛盾しはじめる問題もある。「こう書け」という指示と「これはダメ」という検証がぶつかると、エージェントは混乱する。しかも、ハーネスの良し悪しを測る、テストカバレッジのような標準的な指標は、まだ存在しない。
だから Fowler が強調するのは、ここ。「良いハーネスは、人間の関与を完全になくすことを目指すのではなく、人間の input が最も重要な場所へ振り向けることを目指すべきだ」。組織の文脈、倫理的な判断、技術的負債のトレードオフ。こういう、仕組みに encode できない判断は、人間にしかできない。ハーネスは人を追い出す道具ではなく、人の出番を上流の大事な決定に集中させる道具、という位置づけ。
まず一枚の指示書と、一本のテストの関所から
ハーネスエンジニアリングは、目新しい概念のようでいて、エンジニアがずっとやってきた「良い開発環境を整える」ことの、AI 時代版だと受け取っている。指示書を整え、テストで関所を作り、レビューの仕組みを組む。やっていること自体は、地続き。違うのは、その相手が人間のチームから AI エージェントに広がったこと。
前に「AI に任せるほど、効くのは専門性だった」という Anthropic の分析を取り上げた。あの記事の結論は、成果を決めるのは「コードが書けること」より「問題を正確に言葉にできること」だった。ハーネスエンジニアリングは、まさにその「正確に言葉にする」を、一回の指示ではなく仕組みとして常設する営みだと思う。自分の現場の作法を、ガイドとセンサーの形で AI が走る環境に作り込んでおく。そこに、これからのエンジニアの腕の見せどころが移っていく気がしている。
いきなり立派なハーネスを組む必要はない。まず試すなら、自分のプロジェクトに CLAUDE.md を一枚用意して「うちではこう書く」を 5 行書く(ガイド)。そして、エージェントが書いたコードに対して、必ず通すテストやリンターを一本決めておく(センサー)。この最小の往復から始めて、AI の出力がどれくらい安定するかを見る。物足りなければ、矛盾しない範囲で少しずつ足していく。賢いモデルを追いかけるのと同じくらい、その周りの手綱をどう握るか。そこを意識できるかどうかが、同じ道具を使っても差がつく分かれ目になる。
