ここまでの11本は「考え方」でした。この記事は、それを実案件で1本のループに配線した一例です。
これが正解の形ではありません。案件・チーム・顧客が違えば正解の形も違う——ただ「つなげるとこう回る」という実物が1つあると、自分の案件での組み方を考えやすいはずです。
人間が出るのは3つの定点だけ
このループの設計原則はひとつ：人間の確認ポイントを事前に決めておく。ここでは ①計画承認 ②途中の動作確認 ③最終確認 の3定点に絞り、それ以外はエスカレーション基準に当たったときだけ人間が呼ばれます。
どこで人が見るかが決まっていないと、全部見る（＝AI導入の意味がない）か、全部見ない（＝事故る）の二択になります。3定点は「全部見ない」を安全にするための設計です。
各記事がループのどこで効いているか
| ループの箇所 | 使っている考え方 |
|---|---|
| issue起票〜計画立案 | 受け入れ条件とスコープ外の明文化を計画書の冒頭に置く。技術の詰めはAIが行い、仕様・リスクの判断点は選択肢つきで①に前倒しして集める（10） |
| 実装 | メインは段取り、実作業はサブエージェントに委譲。完了条件には必ずテストを含める（5） |
| 自動レビュー→対応のループ | 多重レビュー。フレッシュなコンテキストの別AI（別モデルも可）が受け入れ条件と案件の地雷リストを観点にレビューし、人間（③）の前に品質を上げる |
| エスカレーション | 秘密情報・本番設定・仕様分岐などの停止条件を明文化して渡してある（10）。AIは自分で「これは上げるべき」と選別して止まる |
| ループ全体の足回り | AIはコードの地図を最初に読んで動く。タスク管理ツールとはMCP連携済みで、issueの読み取り・状態更新・報告をAIが自分で行う。フロー自体をスキル化してあるので、誰が起動しても同じ手順で回る |
| ループの外側 | 週次で改善の定例。うまく回らなかった箇所を巻き取らずに地図・スキル・エスカレーション基準の修正に落とす。地図の鮮度維持は自動ジョブ化 |
支える自動化基盤
考え方だけでは回りません。土台として最低限これを敷いています：
- CI（テスト自動実行）——「テストを通さずに完了扱いしない」を機械で強制する
- ブランチ保護とマージ規約——③の最終確認とマージを人間しかできない操作として実装する（3定点の「実装」）
- タスク管理ツールのステータス運用——AIが進められる状態と「人の番」の状態を分け、いまボールがどちらにあるかをツールを見ればわかるようにする
- スケジュールジョブ——地図の鮮度維持など、定例改善のうち判断が要らないものを自動化する
導入するときの順番
一気に全部は作りません。小さく始めて育てるのはループ自体も同じです。
- 地図と受け入れ条件から——道具がなくても今日から効く（3・7）
- エスカレーション基準を明文化——「任せる不安」がここでほぼ潰れる（10）
- レビューを多重化——人間レビューの負荷が下がり、並列化の余地が生まれる（9）
- 自動化基盤（CI・ブランチ保護・MCP連携）——ループを機械で支える
- フローをスキル化して固定——ここまで来ると、上の図が「毎回説明しなくても回る標準」になる
この構成は社内の実案件でリファレンス実装として実証を進めているものです。数字・事例は育ち次第、ここに足していきます。
お知らせ
この記事は、イデアライブ社内の「AI駆動開発の考え方」ドキュメント（全12本）をシリーズとして公開しているものです。