「Vibe で書いた」「Spec 駆動にした」「Context を整えた」「Harness を組んだ」——同じ「AI駆動」でも、指しているものが会話ごとにずれます。ある人はプロンプトのコツを、ある人は権限と評価を、ある人は CI で回る自律ループを指します。用語が近いほど、議論は噛み合わなくなります。
本記事は、いま現場で見かける AI駆動開発のパターンを地図として並べるものです。効果の保証やランキングではありません。INTERESTIC でも役割分割や worktree など一部は使っていますが、個別テクニックの深掘りより どの層の話かを揃えることを優先します。製品 UI 名は変わりうるので概念として読んでください。コード例は説明用で、本番コピペ保証はしません。
目次
- AI駆動開発とは何か（定義のズレ）
- なぜ今パターンが増えたか — Prompt → Context → Harness → Loop → Graph
- AI駆動開発をズバリ一言で
- まずはここから — パターン地図の読み方
- パターン① Chat / Vibe 駆動
- パターン② Spec / Plan 駆動（Spec-Driven Development）
- パターン③ Context Engineering（コンテキストエンジニアリング）
- パターン④ Harness Engineering（ハーネスエンジニアリング）
- パターン⑤ Role / Subagent 駆動
- パターン⑥ Isolation / Worktree 並列
- パターン⑦ Loop Engineering
- パターン⑧ Graph Engineering
- パターン⑨ Review / CI / 自律 PR 駆動
- 選び方と比較表・アンチパターン
- 現在地・これから・まとめ
AI駆動開発とは何か（定義のズレ）
「AI駆動開発」という言葉は、次のどれを指しても成立してしまいます。
| 話し手が指しているもの | 典型フレーズ | 実際の論点 |
|---|---|---|
| プロンプトの書き方 | 「こう頼めばうまくいく」 | 一文の指示品質 |
| IDE 上のエージェント | 「Cursor で全部書かせた」 | 編集・探索・ツール呼び出し |
| 仕様先行 | 「まず Spec を固めた」 | 合意と検証可能な受け入れ条件 |
| 自動化パイプライン | 「エージェントが PR まで出す」 | 権限・評価・ゲート |
| 組織プロセス | 「AI を前提にスプリントを組んだ」 | レビュー負荷と責任分界 |
ズレの本体は、「AI がコードを書く」こと自体ではなく、どこまでをシステムとして設計しているかです。チャット一発のデモと、権限・テスト・承認が組み込まれた運用を同じラベルで語ると、設計判断が崩れます。
本記事での作業定義は次です。
人間の意図を、モデル・ツール・リポジトリ・評価の組み合わせに渡し、ソフトウェア変更を反復的に生み出す開発のやり方。
「毎回ゼロから会話する」やり方も、「仕様とハーネスを資産化する」やり方も含まれます。優劣の宣言ではなく、どの部品を固定し、どこを毎回決めるかの差として見ます。
なぜ今パターンが増えたか — Prompt → Context → Harness → Loop → Graph
パターンが増えた背景は、モデルが賢くなった一点ではありません。一度に渡せる情報量・呼び出せるツール・長時間エージェント・並列実行が増え、「何を固定資産にするか」の設計空間が広がったからです。
ざっくりした進化の軸は次の入れ子です。内側を十分にしないまま外側だけ借りると、コストが増えやすい、という読み方をします。
Prompt ⊂ Context（渡す情報）
⊂ Harness（動かす枠・権限・評価）
⊂ Loop（枠を反復起動）
⊂ Graph（複数ループとゲートの接続）
| 層 | 何を固定するか | 失敗したときの見え方 |
|---|---|---|
| Prompt | その場の言い回し | 「言い方を変えれば直る」感覚 |
| Context | 渡す材料の質と範囲 | 正しい指示でも前提が足りない／多すぎる |
| Harness | 権限・ツール・成功条件 | 勝手に壊す／止まらない／測れない |
| Loop | 反復の打ち切りと再試行方針 | 同じ失敗を回し続ける |
| Graph | 複数役・複数ゲートの接続 | 局所は通るが全体が迷子 |
最初は Prompt、次に Rules や関連ファイルの渡し方（Context）、ツール編集が当たり前になると権限と評価（Harness）、CI や夜間バッチで反復（Loop）、複数役と承認の接続（Graph）へ広がります。流行名が出るたびに「前が古い」と捨てる必要はありません。
AI駆動開発をズバリ一言で
モデルに「書かせる」ことではなく、意図・文脈・権限・評価を設計して変更を反復可能にすること。
噛み砕くと、「上手い一文」より先に 何を知っている状態で動かすか（Context）、どこまで触ってよいか（Harness）、**いつ終わりか（Loop / Graph）**を決める、という話です。Chat / Vibe も地図の一角で、否定対象ではありません。探索には向く。再現と監査が要る仕事では上位の層が必要になりやすい、という程度の差です。
まずはここから — パターン地図の読み方
以降の 9 パターンは排他的な流派ではなく、重ねて使う前提のレンズです。
読み方は3つだけです。
- 縦の層（Prompt → … → Graph）で「いま議論している深さ」を揃える
- 横のパターンは、同じ深さでも切り口が違う（Role は評価軸、Isolation はディスクなど）
- 近縁記事との分担: 役割の中身は 役割分割の記事、worktree の運用詳細は git worktree の記事 に寄せ、本記事は地図に留める
いわゆる Compound Engineering（小さな改善を積み、エージェントやプロセスを強くする考え方）は独立パターンではなく、Context / Harness / Loop を横断する運用姿勢です。比較の節で短く触れます。
| いまの状態 | 先に足すもの | まだ急がないもの |
|---|---|---|
| チャットでその場しのぎ | Spec の最小受け入れ条件 | Graph 全体 |
| 指示は良いがぶれる | Context（Rules / 関連ファイル） | 夜間フル自律 |
| 触りすぎ・測れない | Harness（権限と評価） | 複雑なマルチエージェント |
| 並列でファイルが混線 | Isolation（worktree） | 役割の大量増設 |
パターン① Chat / Vibe 駆動
定義: 短い指示と対話のノリで、探索しながらコードや文章を生成する。厳密な事前仕様より、感覚とフィードバックの速さを優先する。
いわゆる vibe coding に近い位置です。「動くものを早く見る」には強い一方、成功条件が頭の中だけだと再現とレビューが難しくなります。
# 説明用: Vibe 寄りの依頼（探索向き）
この画面の余白をいい感じに。ついでにダークでも見やすく。
| Pros | Cons |
|---|---|
| 立ち上がりが速い／探索向き | 受け入れ条件が残らない |
| 学習コストが低い | 雰囲気差分・共有／監査の弱さ |
向くのは試作やスパイク。向かないのは課金・権限など誤りコストが高い変更。Vibe を否定せず、成果を Spec やテストへ書き戻す出口を決めると次へ繋げやすいです。
パターン② Spec / Plan 駆動（Spec-Driven Development）
定義: 実装前（または実装と並行して）に、振る舞い・境界・受け入れ条件を文章やチェックリストとして固定し、それに沿ってエージェントと人間が進める。
Plan モードや「章立てゲート」「GO まで実装しない」運用も、広い意味でこの族です。重要なのはツール名より、検証可能な Done の定義があることです。
# 説明用: 最小 Spec の骨子
目的: ログイン済みユーザーが API キーを1つ発行できる。
受け入れ条件:
- POST /api/keys が 201。secret はレスポンスに1回だけ
- 一覧は prefix のみ（secret はハッシュ保存）
- 未ログインは 401 / 既存削除フローを壊さない
非ゴール: レート制限 UI、チーム共有キーは今はやらない
| Pros | Cons |
|---|---|
| レビュー観点が先に立つ | 過剰な文書化で探索が死ぬ |
| 合意装置になる／寄り道を減らせる | 悪い・曖昧な Spec は速い失敗を量産する |
実務では 探索（Vibe）→ 固定（Spec）→ 実装の往復が多いです。長い仕様書が必須、という意味ではありません。
パターン③ Context Engineering（コンテキストエンジニアリング）
定義: モデルに渡す材料（リポジトリ規約、関連コード、差分、禁止事項、用語集）の範囲と品質を設計し、毎回の「思い出し」コストと混線を減らす。
Prompt が「言い方」なら、Context は「その言い方が乗っかる土台」です。Rules、プロジェクト文書、関連ファイルの選択、長文チャットの分割もここに入ります。
| Pros | Cons |
|---|---|
| 同じ指示でも再現性が上がりやすい | 渡しすぎでノイズになる |
| 暗黙知を資産化／混線を減らせる | メンテしない Rules は害になる |
# 説明用: Context の置き場（概念）
- リポジトリ共通: 表記・禁止・コミット方針
- 仕事単位: 今回の受け入れ条件と非ゴール
- その場: 触ってよいパス、参照すべき既存実装
Context を厚くするほど、Harness なしでは「よく知ったうえで大きく壊す」リスクも上がります。次の層とセットで考えるのが安全です。
パターン④ Harness Engineering（ハーネスエンジニアリング）
定義: エージェントが動く枠——権限、ツール、作業ディレクトリ、成功／失敗の評価、打ち切り条件——を設計し、勝手な破壊と測れない成功を防ぐ。
Harness は「プロンプトを上手くする」層ではなく、実行時の安全帯と採点表です。読み取り専用、特定ディレクトリのみ編集可、テスト通過を Done にする、危険コマンドを拒否する、などが具体例です。
# 説明用: ハーネスのチェック項目（概念・本番設定ではない）
agent:
allowed_paths: ["app/Http", "tests/Feature"]
deny: ["force push", "本番シークレット読取"]
done_when:
- "phpunit --filter ApiKeyTest が成功"
- "git diff が受け入れ条件のパスに閉じる"
stop_when:
- "同一エラーが3回"
- "人間の明示確認が必要な操作"
| Pros | Cons |
|---|---|
| 被害半径を限定できる／Loop・CI の土台 | 枠が厳しすぎると進まない |
| 「完了」が機械に寄りやすい | 評価設計コスト／枠だけ先に作りがち |
Harness は1回の走行の枠、Loop はその枠を何周するかです。枠が無い Loop は、失敗を高速再生します。
パターン⑤ Role / Subagent 駆動
定義: 成功条件の違う仕事を、名前付きの役割（frontend / writer / reviewer など）に分け、評価軸の衝突とコンテキスト混線を減らす。
ここでは深掘りしません。INTERESTIC では既に、役割（role / subagent）を分けるメリット として整理しています。地図上の位置づけは次です。
Role は Context の「どの評価軸で読むか」を固定し、Harness に渡す仕事単位をきれいにするパターン。
Spec で Done を書き、Role で誰がそれを見るか分け、Harness で実行制約を掛ける、という三段がよく効きます。役の増やしすぎは「どれを使うか」問題を起こす点だけ、注意に留めます。
パターン⑥ Isolation / Worktree 並列
定義: 複数エージェント／複数チャットの並行を、会話分割だけでなく作業ディレクトリ（例: git worktree）で隔離し、HEAD と未追跡ファイルの混線を防ぐ。
Role が会話の純度なら、Isolation はディスクの純度です。手順・Pros/Cons・巻き戻しは git worktree で AI マルチタスクを隔離する に譲り、地図上の要点だけ示します。
| 分けたもの | 防げる混線 | 防げない混線 |
|---|---|---|
| チャット / Role | 評価軸・用語 | 同一 tree 上のファイル衝突 |
| worktree | HEAD / untracked の踏み合い | 悪い Spec・弱い Harness |
並列を増やす前に Isolation が無いと、Loop や Graph の失敗解析が「どのディレクトリの話か」から始まります。
パターン⑦ Loop Engineering
定義: 同じ Harness（または同じ評価）のもとで、失敗→観察→修正→再実行を意図的に回し、打ち切り条件と学習（何を次に渡すか）を設計する。
テスト失敗をエージェントに戻す、レビュー指摘を再実行する、夜間に同じジョブを回す、などが典型です。「何度も呼ぶ」こと自体より、何が変われば次周が意味を持つかがポイントです。
| Pros | Cons |
|---|---|
| 小さな欠陥を自動で縮めやすい | 同じ誤りを予算まで燃やす |
| 人間の待ちを減らしやすい | ログ無しだと監査不能／「回っている感」と進捗の混同 |
// 説明用: ループの骨格（本番実装ではない）
async function agentLoop(task: Task, harness: Harness) {
for (let i = 0; i < harness.maxTurns; i++) {
const result = await runAgent(task, harness)
const eval_ = await harness.evaluate(result)
if (eval_.ok) return result
if (eval_.needsHuman) throw new NeedsHumanError(eval_)
task = task.withObservation(eval_.summary) // 次周の Context
}
throw new BudgetExceededError()
}
パターン⑧ Graph Engineering
定義: 複数の Loop（や Role）を、分岐・合流・ゲート（承認・CI・人手）で繋ぎ、仕事全体の流れを実行グラフとして設計する。
ここでいう Graph はエージェント実行のグラフです。次とは別物なので切り分けます。
| 用語 | 指すもの | 本記事での扱い |
|---|---|---|
| Graph Engineering（実行グラフ） | 複数エージェント走行とゲートの接続 | この章の対象 |
| Knowledge Graph | 実体・関係の知識表現 | 別領域（ここでは深掘りしない） |
| GraphRAG | 検索拡張にグラフ構造を使う手法 | Context 寄りの別手段。実行 Graph とは階層が違う |
| Pros | Cons |
|---|---|
| 品質ゲートを構造に埋め込める | 設計・運用コストが高い |
| 役割・隔離と相性が良い／道筋が残る | 局所最適が全体を遅らせる／複雑化しやすい |
Graph は「すごいエージェント」の上位互換ではありません。単一 Loop で足りる仕事に Graph を載せると、待ちとオーケストレーションだけが増えます。まず単一 Harness の Loop を安定させ、再現した分岐だけを辺として切り出す方が失敗しにくい、というのが実務寄りの見立てです（効果の保証ではありません）。
パターン⑨ Review / CI / 自律 PR 駆動
定義: エージェントの出力を、人間レビュー・自動テスト・リンタ・セキュリティチェック・（必要なら）自動 PR 作成まで含めて「出荷可能な変更」に乗せる。
Graph の終点に置かれやすい一方、単独でも始められます。「書いて終わり」にせず、差分が既存の品質ゲートを通るかを Done に含める発想です。
# 説明用: 自律 PR の Done（概念）
1. 専用ブランチで変更
2. テスト / lint が緑
3. PR 本文に受け入れ条件のチェックリスト
4. 秘密情報スキャンが通る
5. 人間が Approve するまで merge しない（方針はチーム次第）
| Pros | Cons |
|---|---|
| 出荷直前の品質を揃えやすい | CI が遅いと Loop が高くつく |
| 責任分界を明示／既存 DevOps を再利用 | 自動 PR 洪水でレビュー枯渇／「緑なら正しい」とは限らない |
自律度を上げるほど、Harness（権限）と Review（人のゲート）の設計が重要になります。完全無人を目指す必要はなく、どこで人が見るかを先に決める方が安全です。
選び方と比較表・アンチパターン
数値ベンチは置かず、向きの差だけを示します。
| パターン | 主に固定するもの | 向く状況 | 足りないとき起きやすいこと |
|---|---|---|---|
| Chat / Vibe | その場の対話 | 探索・試作 | 再現不能な差分 |
| Spec / Plan | Done の定義 | 合意が要る変更 | 曖昧 Spec の高速実装 |
| Context | 渡す材料 | ぶれ・前提不足 | ノイズ過多 / 古い前提 |
| Harness | 権限と評価 | 破壊・測れなさ | 枠なしの暴走 |
| Role | 評価軸 | 混線・品質の喧嘩 | 役の乱立 |
| Isolation | 作業ディレクトリ | 並列マルチタスク | ファイル混線 |
| Loop | 反復と打ち切り | 自動修正の余地 | 無限の同じ失敗 |
| Graph | 複数走行の接続 | ゲート付きパイプライン | 過剰オーケストレーション |
| Review / CI | 出荷ゲート | 継続的な出荷 | レビュー枯渇 / 緑信仰 |
重ね方の目安（厳密な手順ではない）です。
アンチパターン表
| アンチパターン | 何が起きるか | 戻し方のヒント |
|---|---|---|
| 用語のすり替え | Vibe の話が突然 Graph の話になる | 層（Prompt…Graph）を先に確認する |
| Spec なし自律 | 速いがレビュー不能 | 受け入れ条件を3行でも書く |
| Context 盛りすぎ | モデルが古い方針に引っ張られる | 「今回の差分と禁止」に削る |
| Harness なき Loop | 失敗を高速再生 | 評価と打ち切りを先に決める |
| Role の増殖 | 起動に迷う | 5系統前後に戻す（近縁記事参照） |
| 会話だけ並列 | ディスクで衝突 | worktree 等で Isolation |
| Graph 先勝ち | 運用コストだけ増える | 単一 Loop が安定してから辺を足す |
| 緑なら完了 | 仕様ずれを CI が見逃す | Spec 照合を Review に残す |
| Compound の儀式化 | 改善チケットだけが増える | 計測できる痛みに紐づける |
Compound Engineering を短く位置づけるなら、「Pattern を増やすこと」ではなく、Context / Harness / 評価を資産として複利にする姿勢です。地図のどのマスを厚くするかの選択とセットでないと、チェックリスト消化になりやすいです。
現在地・これから・まとめ
現在地
2026年時点の見立てでは、入口は Chat / Vibe と Context（Rules）のあいだに寄ることが多い、と考えています（統計調査ではなく、会話や公開事例から得た印象です）。Spec や Role を部分導入し、破壊が怖い領域だけ Harness と CI を足す段階が現実的です。フルな Graph はデモでは目立ちますが、レビュー負荷と権限が追いつかないと遅くなりやすいです。INTERESTIC の役割分割や worktree も、「地図の特定マスを厚くした」例であり、全マス完了ではありません。
これから
増えやすい論点の見立てです（予測であり約束ではありません）。
- 評価つき Harness（テスト・ポリシー・差分範囲）が標準に近づく
- 単一 Loop の安定が先で、Graph は必要な枝だけ残る
- 人のゲート再設計（全件／サンプリング／高リスクのみ）が組織論点になる
- Knowledge Graph / GraphRAG は Context 強化として並行し、実行 Graph と用語が整理される
画面名は変わっても、「意図・文脈・権限・評価・反復・接続」の層は残りやすい、というのが本記事の賭けです。
まとめ
- 「AI駆動」は定義がずれやすい。まず どの層かを揃える
- 軸は
Prompt ⊂ Context ⊂ Harness ⊂ Loop ⊂ Graph - 9パターンは排他ではなくレンズ。Role / Isolation は近縁記事で深掘り済み
- Graph Engineering は実行グラフ。Knowledge Graph / GraphRAG とは別
- 効果は断定せず、比較とアンチパターンで地図を使う
明日からの一行: 次の AI 依頼の前に、「これは Vibe / Spec / Context / Harness のどれを厚くする話か」と一言ラベルを貼る。
正本・関連
この記事の正本（INTERESTIC ブログ）: