図解
はじめに
「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を活用して次のレベルへ。上流はさらに上へ、下流は上流へ。
そのために何をするかを書いていきます。