AIに仕様を詰めさせ、CIまで面倒を見させる開発フロー ——「grill × babysit-pr」実践ガイド
AIに仕様を詰めさせ、CIまで面倒を見させる開発フロー ——「grill × babysit-pr」実践ガイド
Claude Codeの
/grillで仕様を詰め、実装・多層AIレビュー・CI対応までを自動化する開発フローを解説。babysit-prの8段階ワークフローと、人間が残すべき判断ポイントまで実例つきで紹介します。
はじめに：AIでコードは書けるようになった。では、なぜ楽にならないのか
GitHub CopilotやClaude Codeが普及し、「コードを書く」作業そのものはかつてと比べて格段に速くなりました。しかし、多くの開発者が「思ったより楽にならない」という感覚を抱えているのではないでしょうか。
実際の開発現場では、AI活用によってスループットが上がった結果、別のボトルネックが浮き彫りになっています。
ボトルネック①：仕様の曖昧さがAIの迷走に直結する
「なんとなくこういうもの」という仕様でAIに実装を依頼すると、一見動くが要件を満たしていないコードが生成されます。手戻りが発生し、結果として「自分で書いたほうが早かった」という状況に陥りがちです。
ボトルネック②：生成コードのレビュー負荷が人間に集中する
AIが高速に生成したコードは、人間が同じ速度でレビューできるわけではありません。AIのスループットに人間のレビュー能力が追いつかず、レビュー待ちが慢性化します。
ボトルネック③：CI失敗→修正→プッシュの往復で集中が途切れる
CIが落ちるたびにPRに戻り、ログを確認し、修正してプッシュする。この往復作業が、本来集中すべき設計思考を分断します。
本記事では、これら3つのボトルネックを構造的に解決するフローを紹介します。具体的には、/grillで仕様を固め→Claude Codeで実装→Copilot＋Codexで多層レビュー→babysit-prがCI成功まで自律対応する、という一連のパイプラインです。人間の仕事は「ドメイン判断」と「設計レビュー」に集約され、ルーティン作業の大半をAIが担います。
ステップ1：/grill によるAIリファインメントで仕様を固める
grillとは何か——実装前に仕様を詰めるインタビューエージェント
/grill（別名grill-me）は、TypeScriptエバンジェリストのMatt Pocockが作成したClaude Codeスキルです。Xで15万を超えるインプレッションを記録し、2026年現在、日本のエンジニアコミュニティにも急速に普及しています。
一言で表すと、**「実装前に仕様を徹底的に詰めるインタビューエージェント」**です。Claude Codeのプランモードで実行し、AIが人間に質問を重ねながら設計の決断ツリーを一つずつ解決していきます。
grillの実行フロー（Jiraチケットを例に）
実際の現場では、以下のような流れで進みます。
- 自動抽出：JiraチケットからAIが目的・背景・現状を読み取る
- 先行コード調査：画面設計・GraphQL・権限・フィーチャーフラグ・既存テスト・類似実装をコードベースから自律的に調査
- 質問の絞り込み：コードを読んだだけでは答えられない論点のみを人間に提示する
- 合意事項の文書化：ディスカッションの結果を構造化されたドキュメントとして残す
ポイントは「質問を絞り込む」という設計です。AIが「とりあえず全部聞く」のではなく、コードリーディングで自己解決できる問いは自分で処理し、本当に人間の判断が必要な論点だけを提示する構造になっています。
成果物として残す5項目
grillのセッション後には、以下の5項目が文書として残ります。
- 共通認識：チームが前提として共有すべき文脈
- 仕様：実装すべき機能の詳細
- 受入条件：何をもって完了とするか
- QA観点：テストで確認すべき観点
- 未決事項：実装前に解決が必要な残課題
この「未決事項」の扱いが重要です。空欄のまま実装に進めないことがgrillを効かせるコツの一つです。
導入効果：レビューで「驚くことがほぼない」状態
このステップを踏むことで、実装後のレビュー時に「なぜこういう設計にしたのか」という認識の差が生まれにくくなります。詳細な実装イメージがチーム全体で事前に共有されるため、レビューで「驚くことがほぼない」状態が実現します。体感として「2〜3人のシニア開発者が並走している」ような感覚に近いと言われます。
なお、推論能力の高いモデル（Fable 5等）を選ぶことで、このステップの品質が大きく向上します。
ステップ2：Claude Codeでの実装フロー
grill済みチケットを「そのままプロンプト」として投入する
grillによって仕様・実装方針・受入条件が明文化された状態では、それをほぼそのままClaude Codeへのプロンプトとして投入できます。プロンプト設計に費やす時間がほぼゼロになるのは、実装速度の向上よりも大きな恩恵かもしれません。
AIが迷走しにくい構造的な理由もここにあります。「何を作るか」が明確であれば、モデルが設計上の誤った前提を立てにくくなります。結果として手戻りが減り、生成されたコードの品質が安定します。
実装フェーズで人間がやること・やらないこと
| やること | やらないこと |
|---|---|
| 方針のズレの検知 | 行単位の目視コードチェック |
| 設計上の重要な判断 | 命名規則の指摘 |
| ドメイン知識の補完 | CIが落ちた原因の手動調査 |
行単位のチェックや規約の確認は、後段の多層AIレビューとCI層に委ねます。この役割分担の明確化が、このフローの核心です。
ステップ3：多層AIレビュー体制を「スイスチーズモデル」で組む
単一AIレビューの限界と多層化という発想
「AIにレビューさせる」という取り組み自体は珍しくなくなりましたが、単一モデルに任せた場合、そのモデル固有の弱点がそのままレビューの死角になります。
ここで有効なのがスイスチーズモデルの発想です。チーズに空いている穴の位置が各スライスで異なるように、複数のAIを重ねることで、一つのモデルが見落とした欠陥を別のモデルが補足できます。
GitHub Copilot：規範チェック係
Copilotはコーディングルールやチームのベストプラクティスとのブレを発見するのに向いています。役割を「規範チェック係」と位置づけ、.instructions.mdやREVIEW.mdにチェック観点を明示することで、チームのスタイルガイドに沿ったレビューを安定して実施できます。
設定例（REVIEW.md抜粋）：
- TypeScriptの型は明示的に宣言すること
- async関数のエラーはtry-catchではなくResult型で処理すること
- コンポーネントはsrc/components/配下に配置すること
OpenAI Codex：自由探索レビュー
Codexに対しては、あえて明確な指示を与えず、自由にコードを探索させます。これにより、事前に想定していなかった構造的バグや境界条件の問題を発見しやすくなります。「規則を知っているが探索が苦手」なCopilotと、「制約なく探索できる」Codexの組み合わせが相互補完的に機能します。
厚いCI層が「品質の機械的な床」を担保する
多層AIレビューだけでは「AIが見逃した問題」が残るリスクがあります。そこで重要になるのが、CI層の厚さです。
- ユニットテスト・インテグレーションテスト
- リンター（ESLint等）
- 型チェック（TypeScript）
- ビジュアルリグレッションテスト（VRT）
- E2Eテスト（Playwright等）
これだけのCI層を積んで初めて、「AI生成コードの人間目視確認が不要」な構造が成立します。逆に言えば、CIが薄い状態でAIレビューを導入しても、品質の保証にはなりません。
ステップ4：babysit-pr でCI成功まで自律対応させる
babysit-prとは——PRを「見守らせる」Claude Codeスキル
/babysit-prは、その名の通りPRを「見守る（babysit）」スキルです。
/babysit-pr [PR番号またはURL]
PR番号を省略した場合は、現在のブランチから自動的にPRを検出します。CI失敗の往復から人間を解放し、次の作業やフォーカスタイムに集中できる環境を作ることが目的です。
8段階ワークフローの中身
babysit-prは以下の8段階で自律的に動作します。
| ステージ | 内容 |
|---|---|
| ① PR識別 | 対象PRの特定と基本情報の取得 |
| ② ステータス確認 | CI・レビュー状況・マージ可能性を並行チェック |
| ③ 問題分類 | CI失敗＞レビューコメント＞マージ競合の優先順で整理 |
| ④ CI失敗修正 | テスト・リント・ビルド・型エラー別に対応→コミット→プッシュ |
| ⑤ レビューコメント対応 | 指摘内容に応じてコードを修正 |
| ⑥ マージ競合解消 | リベースによる競合の自動解消 |
| ⑦ 検証・報告 | 修正内容を確認し、状況をレポート |
| ⑧ ループ or 完了 | 問題が残れば最大5回まで反復、解決すれば完了 |
CI失敗→レビューコメント→マージ競合という優先順位の設計が重要です。CI失敗を先に解決しないとレビューが始まらないことが多いため、この順序でタスクを処理します。
暴走させないための3つの安全機構
自律的に動くエージェントに対して、適切なガードレールの設計は不可欠です。babysit-prには以下の安全機構が組み込まれています。
安全機構①：[babysit-pr]マーカーによる無限ループ防止
自動コミットのメッセージに[babysit-pr]というプレフィックスを付けることで、自身が作ったコミットを誤って再処理するループを防止します。
安全機構②：ローカル再現不可な失敗は人間に委譲
同じCI失敗がローカルで再現できない状態が3回続いた場合、自動的に人間に判断を委ねます。「解決できない問題を無限に試みる」という非生産的な状況を回避する設計です。
安全機構③：自動マージは実行しない
これが最も重要な設計判断です。babysit-prはCI成功とレビュー承認の条件が揃った状態に持っていくところまでが責務であり、最終的なマージは人間が行います。完全自動化の誘惑に抗った設計が、このツールの信頼性を支えています。
定期ポーリングで運用する：/loop 5m /babysit-pr
複数のPRを並行して監視したい場合は、loopコマンドとの組み合わせが有効です。
/loop 5m /babysit-pr
5分間隔でPR状態を監視し、問題があれば自律的に対応します。また、Codex向けのスタンドアロンプラグイン版（novotnyllc/babysit-pr）も登場しており、Claude Codeを使わない環境でも同様のワークフローを実現できます。
人間が関与すべき4つの判断ポイント
このフロー全体を通じて、人間が必ず関与すべき判断ポイントが4つあります。
1. リファインメント時の要件判断
grillの質問スレッドへの回答が、このフロー全体の品質を決定します。AIがコードを読んでも判断できない問い——「この機能の優先度は？」「ここはパフォーマンスよりも保守性を取るべきか？」——に対する回答が、後段のすべての工程に影響します。
2. プランニング時の優先度・キャパシティ決定
何を、いつ、どの順番で作るかの判断は人間が担います。AIは与えられたチケットを実装することには長けていますが、ビジネス文脈を踏まえた優先度付けはまだ人間の領域です。
3. 最終的なコードオーナーレビュー
AIによる多層レビューを経たコードでも、最終的なコードオーナーとしての確認は人間が行います。ただし、このレビューの焦点は「設計・仕様の妥当性」に絞られます。命名規則や型定義の細部はAIに任せ、「この設計判断はビジネス要件と整合しているか」という視点に集中できます。
4. ドメイン理解と新規課題の発掘
AIは既存の課題を解決するのは得意ですが、「そもそもこのユーザーは何に困っているのか」というドメイン理解や、「次に解くべき問題は何か」という課題発掘は人間の仕事です。このフローが成熟するほど、エンジニアの時間がこの「上流」の思考に集約されていきます。
エンジニアの役割は「トークン保持者」へ
このフローが定着すると、エンジニアの役割は質的に変化します。ルーティン実装・CI対応・レビューコメント返信はAIが担い、人間は仕様合意・設計判断・ドメイン理解に時間を集約します。業務の強度は上がる一方で、「AIが判断できない問い」を扱う、より高次の仕事に集中できる環境が生まれます。
導入ステップ：明日から試すなら何から始めるか
スモールスタートの推奨順序
一度にすべてを導入しようとすると、どこで問題が起きているか分からなくなります。以下の順序で段階的に導入することをベストプラクティスとして推奨します。
Step 1：まず/grillだけを1チケットに適用してみる
babysit-prやCI整備の前に、まずgrillを一つのチケットで試してください。「質問の絞り込み」と「合意事項の文書化」だけでも、実装品質が変わることを体験できます。
Step 2：CopilotのREVIEW.mdにレビュー観点を言語化する
「Copilotにレビューさせる」だけでは効果が薄いです。チームの規約・スタイル・よくある指摘事項をREVIEW.mdに書き出すプロセス自体が、チームの暗黙知を明示知化する機会になります。
Step 3：CIを厚くしてからbabysit-prを導入する
この順序が重要です。CIが信頼できない状態でbabysit-prを動かすと、「間違った修正を自動的に積み重ねる」という最悪のパターンに陥ります。
よくある失敗パターン
失敗①：grillを飛ばして実装させる
「時間がないから」という理由でgrillをスキップすると、仕様の曖昧さがそのまま実装に反映されます。後からの手戻りを考えると、grillに使う20〜30分は必ず回収できます。
失敗②：CIが薄いままbabysit-prを回す
CIが「形だけ」の状態でbabysit-prを導入すると、CIを通過した誤った実装が自動的にプッシュされ続けます。babysit-prの効果を最大化するには、CIが「本当にバグを検出できる」状態であることが前提条件です。
まとめ：AIに任せる範囲を「構造」で決める
本記事で紹介したフローを振り返ります。
/grill で仕様を固める
↓
Claude Code で実装
↓
Copilot（規範チェック）＋ Codex（自由探索）で多層レビュー
↓
babysit-pr がCI成功まで自律対応
↓
人間が設計・仕様・ドメイン判断のみ実施
このフローの本質は、AIの精度への期待ではなく、安全機構の設計にあります。grill-meのインタビュー構造、スイスチーズモデルによる多層レビュー、babysit-prの3つの安全機構——これらはすべて「AIが自律的に動ける範囲」を構造的に定義するための装置です。
AIに仕様を詰めさせ、CIまで面倒を見させる。その結果として、人間は「AIに任せるべき問い」と「人間が考えるべき問い」を明確に分けることができます。段階的に理解を深めながら、まずは/grillの一チケット適用から試してみてください。
参考リンク
関連記事
Claude Codeのセッション消滅問題を解決！claude-memで過去の作業を永続化する完全ガイド
Claude Codeのセッション消滅問題をclaude-memで解決する方法を解説。自動キャプチャ・永続ストレージ・コンテキスト注入の3機能で、セッションをまたいだ作業継続を15分で実現します。
