図解

はじめに

「AI活用の仕組みを整えました」という資料を読むと、たいてい道具の一覧が出てきます。

このコマンドを入れた。この MCP を繋いだ。このルールファイルを置いた。

そこで終わっていることが、かなりあります。

足りないのは2つです。出てきたものが正しいかを誰が判定するのか。そして、どこで人間に返すのか。

この2つが入っていない整理は、仕組みではありません。

ハーネスではなく、ただのプロンプト集。

この記事では、AIに仕事を任せるための足場——ハーネス——が何でできているかを、5つの要素で整理します。そして、自分の手元がどちらなのかを判定できる形にします。

この記事で扱うこと

ハーネスの5要素
欠けると何が起きるか
工程ごとに足場を分ける理由
あえてLLMを使わない場所
ハーネスが本当に解いている問題

🧰 ハーネスの5要素

AIに仕事を任せるとき、話題になるのはいつもプロンプトの書き方です。

でも品質を決めているのは、その外側にあります。

要素	中身
足場一式	AIが一人で回れるようにするもの
使える道具	MCP・コマンド
触らせない境界	権限設定
検証器	出力が正しいかを機械が判定する
停止条件	どこで人間に渡すか

この図の下2つ、検証器と停止条件があるかどうかが、ハーネスかどうかの分かれ目です。

上3つは揃えやすい部分です。道具を繋ぎ、権限を絞る。作業として分かりやすく、やった実感もあります。

下2つは地味です。何も新しいことができるようにはなりません。できることを減らす方向の作業だからです。

だから飛ばされます。そして飛ばした結果が、道具の一覧で終わっている資料になります。

部品を集めることが目的ではなく、足場として組み上がっているかどうかが本体。

スキルもコマンドも、この足場の部品にすぎません。

🕳 検証器と停止条件が欠けると

何が起きるか、具体的に見ます。

**検証器が無い場合。**AIが出したものを、人間が全部読むことになります。最初はできます。10件目あたりから雑になります。そして通ってはいけないものが通ります。

**停止条件が無い場合。**どこまで進んでいいのかが決まっていないので、AIは進めるところまで進みます。気づいたときには、戻すのが高くつく場所まで来ています。

この図の2本の道が、それぞれ欠けたときの行き先です。どちらも「動いてはいる」状態で壊れます。

エラーが出ないのが厄介なところです。仕組みが無いことに、誰も気づきません。

判定のしかたは単純です。いま使っている仕組みについて、この2つに答えてみてください。

**出力が正しいかを、機械が判定していますか。**人が目で見ているなら、それは検証器ではありません
どこで止まって人間に渡るか、決まっていますか。「おかしかったら止める」は決まっていません

両方に答えられなければ、手元にあるのはプロンプト集です。

🔁 工程ごとに足場を分ける

もう1つ、構造の話があります。ハーネスは1本ではありません。

覚えることは3語だけです。フェーズ分割・ハーネス・検証器。

開発を工程に分ける。工程ごとに、AIが一人で回れる足場を作る。その足場に、出力が正しいかを機械が判定する仕組みを組み込む。

この図の足元にある3つの区切りが、AIの仕事が必ず止まる場所です。止まる場所を先に決めるのが、ハーネス設計です。

なぜ工程ごとに分けるのか。まとめて1本のほうが楽に見えます。

理由は1つです。正解の判定の仕方が、工程ごとに違うから。

要件定義の「正解」は、チケットの粒度を人間が見るしかありません。実装の「正解」は、テストが通るかどうかで機械が判定できます。

フェーズの切れ目とは、「正解の判定方法が変わる場所」のこと。

工程表の都合で区切るのではありません。判定方法が切り替わる場所で区切ります。

3本の中身を1枚にすると、こうなります。

	要件定義	実装	レビュー
流れ	文字起こし → 議事録に構造化 → チケット起票	チケット起点 → GitHub＋コマンド → PR作成	機械的検証 → LLM-as-a-judge → 人間がマージ
肝	非構造な会話を機械が扱える形に落とす入口	渡す粒度	型チェック・リント・テスト
検証器／停止条件	チケットの粒度と抜け漏れを人間が見る	テストが通るか	観点固定の評価マトリクスを人間が見る

3本とも、終端に**「誰が正解を決めるか」**が書いてあります。

📐 レビューが辛いとき、直すのはレビューではない

実装のハーネスで、いちばん効くところの話をします。

気をつけているのは、コードの書かせ方ではありません。渡す粒度です。

1つのPRでレビューできる大きさを超えないように、チケット側で制御します。

この図の左側が、多くの人が手を入れる場所です。右側が、実際に効く場所です。

レビューが辛くなってきたとき、私たちはつい、レビューのやり方を工夫しようとします。チェックリストを増やす。観点を絞る。時間を区切る。

順番が逆です。

レビューの負担は、レビューの工夫ではなく、渡す側の粒度で決まる。

AIに書かせると、1回で大量に出せます。**出せる量が増えたぶん、渡す側で絞る必要が出てきました。**ここを絞らずにレビューを工夫しても、追いつきません。

検証器はシンプルです。**テストが通るか。**通らなければ、そもそもレビューの席に着かせません。

🚫 あえてLLMを使わない場所

レビューのハーネスは二段構えです。ここに、この記事で一番はっきりした判断があります。

まず、型チェック・リント・テストという機械的な検証を通します。

判定が確定的にできるところは、あえてLLMを使わない。

この図の左側が、機械に任せる領域です。ここにモデルを置くと、揺らぎが入ります。

型チェックの結果に「たぶん合っています」は要りません。白黒が確定的につく場所にLLMを置くのは、コストの無駄というだけでなく、判定の揺らぎを持ち込む改悪です。

機械的検証を通ったものだけを、別コンテキストで立てたレビュー用のエージェントに渡します。自分の答案を自分で採点させないためです。

そして自由に感想を書かせません。観点を固定した評価マトリクスを出させます。自由記述にすると毎回ブレて、そのうち誰も読まなくなります。

最後に、そのマトリクスを人間が見てマージします。

AIの判定は一次で、マージの責任は承認した人間にある。

この置き方だけは崩しません。

🎯 ハーネスが本当に解いている問題

一段引いた話をします。なぜ、足場を作る必要があるのか。

速くするため、ではありません。

プロンプトが上手い人が上手くやる。それは仕組みではなく、個人技です。

個人技は、その人が休んだ日に止まり、その人が辞めた日に消える。

この図の右側が、ハーネスが作ろうとしている状態です。誰がやっても同じ品質が出る。

5要素に検証器と停止条件が入っているのは、このためです。この2つを欠いた整理が個人技のままなのも、同じ理由です。

判定する仕組みが無ければ、判定できる人に依存します。止まる場所が決まっていなければ、止めどきが分かる人に依存します。

ハーネスが守っているのは、速さではなく再現性です。

🌿 いつから足場が要るのか

最後に、線引きの話をします。常に足場が要るわけではありません。

ハーネスという言葉が付く前の状態を、野生状態と呼びます。みんなAIを使っているが、各自バラバラ。Aさんは成果を出し、Bさんは安定しない。

ただし、野生が常に劣るわけではありません。

何を作るか決まっていない探索段階では、型を作る手間のほうが高くつきます。野生のほうが速い。

方法論が効き始めるのは、「人が増えた時」と「同じことを繰り返す時」。

この図の交点が、切り替えどきです。人が増える前でも、繰り返しが始まる前でもありません。

この線引きを持っておくと、「まず型から入るべきですか」と聞かれたときに「探索フェーズなら型は後でいいと思います」と返せます。

方法論の押し売りに見えなくなる、大事な一言です。

📝 まとめ

3つに絞ります。

1つ目。ハーネスは5要素。 足場一式・使える道具・触らせない境界・検証器・停止条件。下2つが無ければ、ハーネスではなくプロンプト集です。

2つ目。工程ごとに分けるのは、正解の判定方法が違うから。 工程表の都合ではありません。判定方法が切り替わる場所で区切ります。

3つ目。守っているのは再現性。 速さではありません。個人技は、その人が休んだ日に止まります。

明日いちばん先に試すことを1つ挙げるなら、これをおすすめします。

いま使っているAIの仕組みについて、「出力が正しいかを機械が判定しているか」と「どこで人間に返るか」の2つに答えてみてください。

答えられなければ、**それはプロンプト集です。**悪いことではありません。探索の段階なら、それで足ります。

ただし人が増えるか、同じことを繰り返し始めたら、そこが切り替えどきです。

📚 参考

あわせて読む

Harness design for long-running application development — Anthropic、2026年3月24日
Effective harnesses for long-running agents — Anthropic、2025年11月26日
Graph Engineering とは — Loop Engineering の次に来た「エージェントの配線図」 — @y-morimatsu

💡 この記事について
本記事は2026年9月18日時点の整理です。

**この記事の内容は、筆者の所属する日本AIセンターの社内教材をもとにしています。**特定の顧客やプロジェクトの情報は含みません。

引用の形で示した言い切り（「ハーネスではなく、ただのプロンプト集」など）は、その教材の文言です。外部の出典があるものではありません。

「ハーネスエンジニアリング」は、まだ用語として固まりきっていません。**同じ言葉が別の意味で使われていることがあります。**この記事での定義は上の5要素です。

エンジニアがAIを活用して次のレベルへ。上流はさらに上へ、下流は上流へ。
そのために何をするかを書いていきます。