AI に本番 DB アクセスを許す。AI に GitHub への直接 push を許す。AI に MCP 経由でブラウザ操作を許す。
便利、ではある。ただし同時に、それは権限委譲です。鍵を一本渡すたびに、鍵がどこに置かれ、誰が監視し、紛失したらどう戻すかという話が、必ず後ろに張り付きます。
ところが「ハーネスエンジニアリング」を語る記事の多くは、鍵を渡す側の話で終わっています。Plugin を足した、Skill を入れた、MCP を繋いだ、AGENTS.md を書いた──そこで満足してしまう。
ハーネスエンジニアリングとは、AI への能力拡張（＝権限委譲）と、それに見合うリスク管理を、セットで設計する実践です。 派手な前者、地味な後者。両方が揃って初めて、ハーネスは形になります。むしろ実務で長く回すほど、後者の比重のほうが大きくなる、というのが筆者の見方です。
以下では、Stage 0 から Stage 7 までを「能力」と「リスク管理」の対で並べていきます。自分の現在地と、次の一手を見つけるための地図として読んでもらえれば十分です。
ハーネスは段階で組み上がる
ハーネスエンジニアリングは、もとから 失敗を見つけるたびに防止策を積み重ねる継続的な工学 として提唱されました。この語を最初に明示した Mitchell Hashimoto は、自身のブログでこう定義しています。
"the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again"
防止策は時間とともに重なり、上に層が積まれていきます。Plugin、ルール、validate、CI Gate──これらは互いに置き換わるものではなく、上に重ねていくもの。ハーネスが単発で完成しない以上、段階で語るほうが事実に近いといえます。
積み方には筋があります。Thoughtworks の Birgitta Böckeler は、coding agent harness を「事前のガイド（feedforward）」と「事後のセンサー（feedback）」の二軸で整理し、両軸が揃って初めて harness は機能する、と書いています。
"Separately, you get either an agent that keeps repeating the same mistakes (feedback-only) or an agent that encodes rules but never finds out whether they worked (feed-forward-only)."
事前に何を渡すか、事後に何を見るか。ハーネスはこの二軸の組み合わせで、渡す能力の大きさに応じて厚みを変える 構造をとります。Anthropic も long-running agent を扱うときの harness について、memory・sub-agent・観測・回復ループといった複数の層を組み合わせる必要があると論じており、扱う対象が大きくなるほど harness は厚くなる、という観察を残しています（Effective harnesses for long-running agents、Stage 7 で再度参照します）。
本記事の Stage モデルは、この 能力と層の対応関係 を、AI に渡す権限の大きさに沿って 8 段階に並べ直したものです。
実務に翻訳すると、ハーネスの仕事は次の四つに分かれます。
- 入力の制御: AI に何を見せ、どのツールを使わせるか
- 進行の制御: どの順序で作業させ、どの状態を保つか
- 出力の検証: どこで評価し、どこで止めるか
- 失敗の取り扱い: 失敗時にどう戻し、人間がどこで介入するか
Plugin を入れた人も、AGENTS.md を書いた人も、validate CLI を整備した人も、sandbox を運用している人も、全員が「ハーネスやってます」と言えてしまう。同じ言葉なのに議論が噛み合わないのは、これが理由です。だから、ハーネスを 段階 で切り分けます。
能力拡張＝権限委譲、だからリスク管理がセットで要る
AI に Plugin / MCP を入れる行為は、AI に 外部システムへの手足 を渡すことです。GitHub への書き込み、DB の読み取り、ブラウザ操作。一つひとつは「人間がこれまでやっていたこと」を AI に肩代わりさせる契約に他なりません。これは技術導入というより、権限委譲 です。
委譲には便利さと同じ重さのリスクが伴います。たとえば本番 DB アクセスを AI に許す場合、現実の運用では次が対で並びます。
- 読み取り専用権限に絞る、あるいは特定スキーマだけに絞る
- 書き込みが必要なら、承認フローを通す
- 壊れても戻せるよう、定期バックアップを取る
- 何をやったかを観測できるよう、操作ログを残す
- 異常を検知したら止められるよう、回復手順を用意する
これらが伴わない状態で本番 DB の鍵を渡すのは、監視カメラもバックアップもない金庫に鍵だけ置く ことに等しい。便利さの分だけ、爆発した時の被害も大きくなります。
「Plugin / MCP / Skill を入れた」だけでハーネスエンジニアリングを語るのが片手落ちなのは、ここに理由があります。何を渡すか と どう守るか は、同じ Stage に同居しているべき対です。本記事の Stage モデルは、その対の関係を骨格に据えます。
制御成熟度の 8 段階：能力拡張 × リスク管理対策
断り書き: 以下の Stage 0〜7 は本記事の整理であり、業界標準分類ではありません。番号や呼称は他の整理と一致しないことがあります。
各 Stage は前の Stage を含み、能力を一段拡張するごとに、それに見合うリスク管理対策を一段追加するという構造です。
| Stage | 特徴 | AI に渡す能力・権限 | それに見合うリスク管理対策 | 主な効果 |
|---|---|---|---|---|
| 0 | 素の AI 利用 | 推論と回答のみ（ツールなし） | 人間が全出力を目視で確認する | 初速が速い |
| 1 | Instruction / Rule 直書き | リポジトリのファイル参照、ローカル CLI | AGENTS.md / CLAUDE.md / rules.md に方針・禁止事項・進め方を文書化 | AI の作業方針を固定できる |
| 2 | Skill / Workflow 定型化 | 反復作業の自律実行 | Skill / Workflow に手順を固定し、毎回同じパスを通させる | 作業の再現性が上がる |
| 3 | Tool / Plugin / MCP 能力拡張 | 外部システム（GitHub / DB / ブラウザ / API）への接続 | 最小権限・読み取り専用・API キーのスコープ制限・監査ログ | AI が実行できる作業範囲が広がる |
| 4 | Spec / Task 構造化 | 仕様駆動の自走（自分で設計判断） | Spec / Scenario / Contract を正解として明示し、AI の判断と突き合わせられるようにする | 要件・設計が整理される |
| 5 | Repo-local Validate | 実装まで一貫した自走 | validate CLI で仕様 ID 接続を機械検査、参照切れ・未消化 todo を落とす | 仕様逸脱を機械的に検知できる |
| 6 | CI Gate / Quality Harness | PR を AI が自分で出す | CI Gate で統合前に止める / mutation testing / レビュー報告で人間レビューを絞る | 統合前ゲートで品質を担保 |
| 7 | Full Agent Harness | 本番系・長時間実行・multi-agent orchestration | sandbox 隔離 / 権限制御 / 定期バックアップ / observability / 回復ループ | AI 実行環境全体を制御できる |
表だけだと骨格しか見えないので、Stage ごとに何をしているか、何が足りていないかを順に見ていきます。
Stage 0：素の AI 利用
ChatGPT や Claude に都度プロンプトで依頼する状態。リポジトリには何もない。
個人の相談・調査・使い捨て作業ならこれで十分です。リスク管理は 人間が全出力を読む ことで担保します。
Stage 1：Instruction / Rule 直書き
AGENTS.md / CLAUDE.md / rules.md に作業方針や制約を書く段階です。「このコマンドを使う」「この API は避ける」「この手順で確認する」を文書化します。
ただし、書いたルールを AI が守ったかどうかは検査できません。Stage 1 のリスク管理は「方針を文書化すること」までで、守ったかの確認はまだ人間頼みです。これが Stage 1 の限界です。
Stage 2：Skill / Workflow 定型化
Instruction を Skill / workflow として束ね、必要なときに呼び出せるようにする段階です。Claude の Skill、Cursor の Rules、独自の workflow ファイル群などが該当します。
Skill 化の効果は次です。
- 作業単位で instructions を切り出せる
- 必要なときだけ呼び出せる（コンテキストを常に圧迫することがなくなる）
- scripts や resources を同梱できる
- チーム内で再利用できる
この意味で、Skill は Instruction を再利用可能なパーツに切り出したもの です。リスク管理の側からは「毎回同じ手順を踏ませる」ことで、AI のブレが目に見えて減ります。ただし、その手順が出した成果物が正しいかどうか、ここまでではまだ何も保証していません。
Stage 3：Tool / Plugin / MCP 能力拡張
GitHub / DB / ブラウザ / 検索 / API / MCP サーバーを使わせる段階です。AI ができることが大きく増えます。
この Stage が他と違うのは、能力拡張とリスク管理を同時に設計しないと、Stage として成立しない ところです。Plugin を一つ入れた瞬間、AI に外部世界への手足が生えます。それに対して最低限、次の対策が並走します。
- 最小権限: AI に渡すトークンや API キーは、必要なスコープだけに絞る
- 読み取り専用: 書き込みが必要ない作業は読み取りだけに制限する
- 監査ログ: AI が外部に対して何をしたかを記録する
- 承認フロー: 影響の大きい操作（マージ、デプロイ、削除）は人間の承認を挟む
この対策群が揃ったときに初めて、Stage 3 を「成立している」と呼べます。Plugin を入れただけの状態は、能力だけ伸ばして守りが置き去りになっている、いわば未完の Stage 3 です。
Stage 4：Spec / Task 構造化
Spec Kit、Kiro、あるいは独自の docs/specs / docs/contracts / docs/tasks 構造で、要件・設計・タスクを構造化する段階です。
「何を作るのか」が整理されることで、AI への指示の解像度が大きく上がります。リスク管理の観点では、仕様という形で正解を明示しておく ことで、AI が出してきた成果物と突き合わせる準備が整います。ただし、突き合わせを機械的にやれるのは次の Stage 5 からです。
Martin Fowler は spec-driven development の現実について、次のような観察を残しています。
"even with sufficient instructions, AI agents would frequently not follow all of them"
十分な指示を書いても、AI が指示通りに動かないことは頻繁に起きる、という指摘です。だからこそ、仕様を「読ませる」だけの Stage 4 で止めず、Stage 5 の機械的検査までつなげる必要があります。
Stage 5：Repo-local Validate
仕様 ID、Scenario、Test list、Contract、Decision Log を置き、ローカルで実行できる validate CLI で検査する段階です。
具体例として、業務ルール / シナリオ / API 契約 / 受入テストに ID を振り、参照関係を機械的に検査します。
BR-ORDER-001: 取引停止中の顧客は注文できない
SC-ORDER-001: 取引停止中の顧客が注文作成 API を呼ぶと 400 を返す
API-ORDER-CREATE: 注文作成 API の契約
TEST-ORDER-001: SC-ORDER-001 を検証する受入テスト
TEST-ORDER-001 -> SC-ORDER-001 -> BR-ORDER-001 -> API-ORDER-CREATE
validate では、たとえば次を検査します。
- 仕様 ID の一意性
- 参照切れ
- Scenario が Business Rule を参照しているか
- Test が Scenario を参照しているか
- Contract 変更時に Scenario / Test が更新されているか
- テストリストの未消化 todo が残っていないか
ここまで来て、ようやく「仕様を守って」「TDD で実装して」という曖昧な指示が 機械的な制約として機能 します。AI に届く最良のフィードバックは、自然言語の説教ではなく CI の赤 です。
そして、この validate がやっていることをよく見ると、特別新しいわけではありません。人間がコードレビュー、QA、TDD で長年やってきた検査 を、AI 向けに機械化したものです。AI 時代だから新しい武器が必要になる、という話ではなく、既存の武器を機械が扱える形に研ぎ直している、という話です。
Stage 6：CI Gate / Quality Harness
Stage 5 の validate を CI に統合し、test / lint / security / mutation / report も含めて、統合前に AI の逸脱を止める段階です。
report は人間のレビュー帯域を守るためにも重要です。AI 時代の差分量に対して、人間が全部読む前提は破綻します。「全部読む」から「リスクの高い場所を見る」に移行するには、変更分類（互換維持・改善・仕様変更）と影響範囲のレポートが要ります。
これも、ソフトウェア開発が何十年も育ててきた CI とコードレビューの文化を、AI が PR を出す時代向けに焼き直したものです。発明はしていません。
Stage 7：Full Agent Harness
sandbox / 権限 / 観測 / 回復 / runtime / multi-agent orchestration を持つ段階です。AI 実行環境全体を制御します。
リスク管理の側から見たとき、ここが最も濃くなります。
- sandbox: AI が壊しても本番には届かない隔離環境
- 権限制御: 誰が何にどこまで触れるかを最小権限で設計
- 定期バックアップ: 何かあったときに戻せる状態を常に保つ
- observability: 何が起きたかを後から追えるよう、ログとメトリクスを集める
- 回復ループ: 異常を検知して、自動または半自動で戻す
この層が必要になるのは、大企業、規制産業、AI 基盤チームに限られます。すべての組織が目指すべきラインではありません。ただし、本番系への直接アクセスを AI に許すなら、ここに並んだ要素はどれも値切れません。値切ると、最初の事故で全部を払うことになります。
時間をまたぐ運用に何が要るかを、Anthropic はこう書いています。
"Every subsequent session asks the model to make incremental progress, then leave structured updates."
各セッションは少しずつ前進し、構造化された更新を残して終わる。次のセッションは、その更新を読んで状態を引き継ぐ。Stage 7 のリスク管理が見ているのは、時間をまたいで状態を保ち、必要な地点まで戻せる という、運用としての連続性です。
自分の現在地を判定する
ここで、地図上で自分がどこにいるかを当てに行きます。判定基準は一つだけ。能力とリスク管理が対になっているか です。
| 状態 | 該当 Stage | リスク管理対策が伴っているか |
|---|---|---|
| ChatGPT / Claude に直接依頼するだけ | Stage 0 | 人間が全出力を読むなら OK |
| AGENTS.md / CLAUDE.md に作業方針を書いた | Stage 1 | 文書として方針はあるが、守ったかは確認できない |
| Skill / workflow 化して呼び分けるようにした | Stage 2 | 手順は固定されたが、出力品質は別 |
| GitHub / MCP / 検索などを使わせている | Stage 3（条件付き） | 最小権限 / 読み取り専用 / 監査ログがあるかを確認する。なければ Stage 1 や 2 のまま能力だけ拡張した状態で、危ない |
| Spec Kit / Kiro / 独自構造で仕様・タスクを置いた | Stage 4 | 仕様は整ったが、満たしたかは別途検査が要る |
| 仕様 ID と参照切れチェックをローカルで走らせている | Stage 5 | validate がリスク管理を担っている |
| 上記を CI で落としている | Stage 6 | 統合前ゲートが効いている |
| sandbox / 権限 / 観測 / 回復まで持っている | Stage 7 | 本番系を任せても回復できる |
勘違いの典型は、能力だけ拡張して、リスク管理が追いついていない状態 を Stage 3 と呼んでしまうことです。Plugin を 5 個入れ、MCP を 3 本繋いでも、最小権限の設計も監査ログも validate も無いなら、それは未完の Stage 3 のままです。
逆方向の話もしておくと、ローカル CLI しか渡していなくても、Stage 5 の validate が動いていれば、品質の意味では遥かに安定します。能力で勝ってもリスク管理で負けることがある、という構図です。
どこを目指すべきか：用途別の推奨ライン
すべての人が Stage 7 を目指す必要はありません。渡す能力の大きさ に応じて、必要なリスク管理の Stage が決まります。
| 用途 | 渡す能力 | 推奨 Stage |
|---|---|---|
| 個人の相談・調査・使い捨て | 推論と回答のみ | Stage 0〜1 |
| 反復作業がある個人開発・小規模チーム | ローカルでの定型作業 | Stage 2 まで |
| 外部ツールや MCP を使う開発（ローカル / GitHub 程度） | 限定的な外部接続 | Stage 3（最小権限と監査ログをセットで） |
| 外部ツールや MCP を使う開発（DB / クラウド / 本番系まで伸ばす） | 強力な外部権限 | 最低 Stage 5（validate ＋ 統合前ゲート） |
| 要件整理が必要な開発（SDD 導入） | 仕様駆動の自走 | Stage 4 を経由して Stage 5 へ |
| 実務プロダクトで AI 出力品質を安定させたい | 自走実装 | 最低 Stage 5（Repo-local Validate） |
| チーム開発・業務システム・継続開発 | AI が PR を出す | Stage 6（CI Gate）まで |
| 大企業・規制産業・AI 基盤 | 本番系・長時間実行 | Stage 7（Full Agent Harness） |
判断の基本ルールは一つです。
AI に渡す能力（権限）が大きくなるほど、それを抑える仕組みも一段強くする。
たとえば、個人開発でも本番 DB アクセスを AI に許した瞬間、AGENTS.md だけでは足りません。最低でも読み取り専用、できれば validate と CI Gate も欲しい。逆に、ローカルでコードを書かせるだけなら Stage 1 や Stage 2 で十分機能します。
なお、個人開発・小規模チームで「Stage 5 のフルセットは重いが、Stage を上げたい」という場合は、極小スタートが取れます。
docs/
rules.md # BR-XXX-NNN: ... を箇条書きで
scenarios.md # SC-XXX-NNN: ... を箇条書きで
tests/
acceptance/ # TEST-XXX-NNN を SC-XXX-NNN で参照
scripts/
validate.sh # grep で参照切れと未消化 todo を検出するだけ
AGENTS.md # 「上流 ID を必ず参照する」を明記
ID 接続と grep ベースの参照切れチェックがあれば、validate CLI フレームワーク無しでも、Stage 5 の最小実装は持てます。
まとめ：ハーネスの本質は「AI の暴走を抑える仕組み」
ここまで Stage 0 から Stage 7 まで歩いてきました。最後に一つだけ、本記事の着地点を置きます。
注目を集めるのは、いつも前者です。MCP、Plugin、新しい Skill、人気 OSS。記事が映え、SNS で拡散され、社内勉強会の題材になる。
一方、長く回したときに事故を起こさないのは後者のほうです。validate、CI Gate、最小権限、監査ログ、定期バックアップ、回復ループ。並べても誰もリツイートしてくれません。
ここで一つ、誤解を解いておきたい点があります。後者は、新しいものではありません。 AI がどれほど進化しても、いまの延長線上にある限り、それは「優秀な人間のような振る舞い」の上位互換止まりだと筆者は考えています。優秀な人間でもミスはします。であれば、人間相手にやってきた、
- ミスを検知する仕組み
- 成果物を機械的にチェックする仕組み
- 仕様を明示し、逸脱を見つける仕組み
- 統合前に止めるゲート
- 異常を検知して戻すループ
これらが、相手が AI に変わっても効きます。むしろ AI がアウトプットの量と速度を引き上げる分、人間相手のとき以上に効く、と言っていいかもしれません。元となるのは、ソフトウェア開発が QA・TDD・コードレビュー・CI / CD・SRE で何十年も磨いてきた知恵です。
この見方は筆者だけのものではありません。冒頭で触れた Böckeler の feedforward × feedback の二軸も、本記事が Stage 0 から 7 まで「能力とリスク管理を対で並べる」と言ってきたことと、別の言葉で同じ位置を指しています。フィードバックだけのハーネスは同じミスを繰り返し、フィードフォワード（事前のガイド）だけのハーネスはそれが効いたかを確かめられない──両輪で初めて harness は形になる、という整理です。
最後に一文だけ。AI に何をさせるかではなく、AI が間違えたときにどこで止め、どう戻すか。 ここを抜きにしては、ハーネスは話せません。
なお筆者は、Stage 5 / 6 の土台を提供する OSS として QFAI を開発しています。SDD・ATDD・TDD・Contract・Delta・Traceability・validate・report・skills を一つの品質ハーネスにまとめ、AI が逸脱したときに機械的に止める仕組みを目指しています。
参考リンク
ハーネスエンジニアリングの参考
- Mitchell Hashimoto「My AI Adoption Journey」（2026-02）— "harness engineering" を最初に明示した個人ブログ。失敗を見つけるたびに防止策を積み上げる継続的工学として定義 — https://mitchellh.com/writing/my-ai-adoption-journey
- Birgitta Böckeler「Harness engineering for coding agent users」（2026-04）— Thoughtworks 発、guides（feedforward）と sensors（feedback）の二軸で coding agent harness を整理した記事 — https://martinfowler.com/articles/harness-engineering.html
- Anthropic「Effective harnesses for long-running agents」（2025-11）— 長時間 agent 運用に必要となる harness の層を論じた一次資料 — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
仕様駆動・品質駆動の参考
- Spec-driven development with AI — https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
- Kiro Docs — https://kiro.dev/docs/specs/
- Kiro Vibe / Spec session — https://kiro.dev/docs/chat/vibe/
- IT Revolution「How to ensure quality when AI does the coding」 — https://itrevolution.com/articles/how-to-ensure-quality-when-ai-does-the-coding/
- Martin Fowler「Spec-driven development tools」 — https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
- Cucumber Gherkin Reference — https://cucumber.io/docs/gherkin/reference/
- ADR — https://adr.github.io/
筆者の OSS