チームで回すAI駆動開発ループ — interview-dev-loop と Loop Engineering¶

作成日: 2026-06-26 出典 / きっかけ: ウンス（株式会社エクスプラザ）「個人のプロンプト術をやめて、チームで回るAI駆動開発ループを作った話」 https://zenn.dev/explaza/articles/d0aeb08fcd1888 関連: 社内mcp共通基盤_認証認可ログ_整理 / note記事_技術負債をネットワーク指標で監視する

0. 要点（3行）¶

個人のプロンプト技巧をやめ、エージェントが不足情報を「質問」して埋める反復ループをチーム資産にする話。良いプロンプトを人間が書くのではなく、エージェントに調査→質問→計画→実装→レビュー対応を回させ、人間は「回答・承認・動作確認」だけに縮める。
肝は3つ: ①Material Ambiguity（実装方向が変わりうる曖昧さ）だけを質問対象に定義 ②現実的な選択肢を最大3つに絞る ③調査/計画エージェントと実装エージェントを分離（捨てた案を実装側に持ち込ませない）。
成果: レビュー指摘がコード1,000行あたり −72〜77%（変更量は約4.6倍に増えても）。本質は「どう指示するか」より「何を作るべきか」を事前に詰めることがPR品質を上げる、という転換。

1. 背景にある概念 — Loop Engineering（Addy Osmani, 2026-06）¶

この記事の土台は Loop Engineering。Addy Osmani が2026年6月に同名エッセイで命名し、Peter Steinberger・Anthropic の Boris Cherny の議論を基盤にしている（出典は本ノート末尾）。

定義: 「自分（プロンプトを打つ人間）を、エージェントにプロンプトを打つ“システム”で置き換える」。一言で言うと prompt を書く人 → loop を設計する人 へのレバレッジ移動。
anatomy（構成要素・Osmani）: automations（自動起動）/ worktrees（並行隔離）/ skills / connectors / sub-agents / external state（会話外の状態）。
核心の緊張: 検証は依然として人間の責任。「無人で走るループ = 無人で間違え続けるループ」。だから maker（作る）と verifier（検証する）sub-agent を分離して「done」を意味のある主張にする。さらに、ループが速くコードを吐くほど「自分が読んでいないコード」が増える＝comprehension debt（理解負債）が貯まる。

関連: ハーネスエンジニアリング（足場の5要素）と対になる概念。harness = 1回の作業を確実にする足場、loop = それを自動で何度も回す制御系。本記事はその loop をチーム運用に落とした実例。

2. As-is（改善前）の課題¶

チーム内でAIの使い方が統一されず、品質と速度にばらつき。
人間がループ進行の係になっている。プロンプト初手も、PR後のレビュー対応の修正指示も、毎回人間。
エージェントは1往復するたびに停止し、人間の指示待ち。自律性が低い。

3. 実装 — interview-dev-loop の5フェーズ¶

公開リポジトリ unsu0707/interview-dev-loop（Claude Code / Codex 両対応）として配布。

[調査] コード・ドキュメント・テスト・過去計画を読む
   ↓
[質問] Material Ambiguity（実装方向が変わる曖昧さ）を抽出して人間に問う
   ↓
[計画] 人間が承認する形で実装方針を確定
   ↓
[実装] 別エージェント（サブ）に正確な指示を渡して実装
   ↓
[レビュー対応] 修正を自動ループ

人間の役割は ①質問への回答 ②計画承認 ③動作確認 の3点だけに縮小される。

なぜ「インタビュー」重視か¶

最初から完璧なプロンプトを人間が書くのではなく、エージェントが不足情報を自動抽出して質問する。タスク特性に応じて調査・質問内容が変わる。

例: 外部連携 Provider 追加時に「実装スコープ」「UI表示方法」「セキュリティ境界」を事前に質問させる。

4. 作りながら直した3つの工夫（ここが本質）¶

工夫	内容	効果
質問対象の定義	「質問してよい曖昧さ」を Material Ambiguity（実装方向・検証方法・ロールアウト・データ処理・権限・ユーザー視点の動作が変わりうる不確実性）に限定	質問の質と安定性が向上。瑣末な質問が消える
選択肢設計	「明らかに選ばれない選択肢」を禁止。実装方向が実際に変わる現実的な選択肢のみ・最大3つ。推奨案表記はOK（ただし他も実現可能なこと）	不要な質問が減り、意思決定が高速化
実装エージェントの分離	調査・計画担当（メイン）と実装担当（サブ）を分ける。メインの「捨てた案・不採用の前提」をサブに引き継がせない	サブは「採用方針・変更対象・完了条件・必要テスト」に集中できる

この「作る側と判断/検証する側を分ける」は Loop Engineering の maker/verifier 分離そのもの。自分の baby-ehon の harness×loop 設計（spec-author が契約を起草 → maker は契約に触れず実装）と同じ発想。

5. 定量成果¶

導入前後2ヶ月・他メンバー対象・優先度別の重み付けで集計。

指標	Before	After	変化
レビュー指摘スコア / 1,000変更行	2.096	0.581	−72.3%
P1+P2 コメント数 / 1,000変更行	1.347	0.305	−77.4%
変更行数	—	—	約4.6倍に増加

変更量が増えても、実装量あたりのレビュー指摘が大幅減。
著者は「効果はこのSkill単独とは限定できない（チーム全体のAI習熟も寄与）」と明示（誠実な留保）。

6. チームへの効果・文化変化¶

プロンプト作成時間が減る（短い指示で、足りない部分は自動質問）。
個人の工夫がプロジェクト資産化（Skill・ドキュメント改善が PR で全員に共有）。
メンバーの声: 手戻り減・並行作業可・仕様検討に時間を割けるようになった。
気づき: AIとの対話が 「指示→実行」から「協議→実行」 へ。「何を作るべきか」の議論が重視される文化に。

7. 現在のフロー（PR後ろまで拡張）¶

interview-dev-loop（実装）
   → E2E動作確認（人間）
   → PR作成
   → codex-review-loop（指摘対応の自動化）
   → E2E動作確認（人間）
   → Merge Ready

これから: チケット作成段階の自動インタビュー / 定期バグ検出・小改善の自動化 / Notion・Slack・GitHub の定期監視と自動指示。

8. まとめ — いつ・どう使うか¶

状況	推奨アプローチ
AIの使い方が人によりバラつく	質問・計画フェーズを仕組み化してチームの共通ループにする
良いプロンプトを書くのが属人的	プロンプトを磨くより、不足情報をエージェントに質問させる設計に倒す
質問が多すぎ/瑣末	Material Ambiguity に質問対象を限定、選択肢は現実的3つまで
実装エージェントが脱線する	調査/計画と実装を別エージェントに分離し、採用方針だけ渡す
PR レビュー指摘が多い	「どう作るか」より「何を作るべきか」を事前に詰めることに投資する

一言で: プロンプト術の個人化から、開発ループの団体化へ。最適化対象を「人間のプロンプト技術」から「チームの反復システム」に移す。

参考リンク¶

ウンス（エクスプラザ）「個人のプロンプト術をやめて、チームで回るAI駆動開発ループを作った話」 https://zenn.dev/explaza/articles/d0aeb08fcd1888
interview-dev-loop（GitHub） https://github.com/unsu0707/interview-dev-loop
Addy Osmani「Loop Engineering」（概念の出典） https://addyosmani.com/blog/loop-engineering/
Loop Engineering（O'Reilly Radar） https://www.oreilly.com/radar/loop-engineering/
cobusgreyling/loop-engineering（実践パターン集） https://github.com/cobusgreyling/loop-engineering

作成: 2026-06-26 ／最終更新: 2026-06-26