こんにちは、えんせきです。
Claude Codeの記事を読んでいると「便利そうだけど、どう運用に組み込めばいいのか分からない」状態になりがちだったので、 自分なりに GitHub + Claude Code を前提にした開発フロー → GitHub Vibe Flow(仮) を整理して、実際にやってみた。 キモは GitHub Issueの活用と、Claude Code自体に開発の振り返りをさせてSkills等を更新させる こと。
GitHub Vibe Flow(仮)は勝手に名前をつけただけなので、どこかで被っていたらごめんなさい。 (仮)まで含めて名前だから許して。
I'm Boris and I created Claude Code. Lots of people have asked how I use Claude Code, so I wanted to show off my setup a bit.
— Boris Cherny (@bcherny) 2026年1月2日
My setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don't customize it much. There is no one correct way to…
を実現しようと思って始めたので記載しているところ以外は基本これ準拠
つまりなにしたの？
GitHub Issue を起点に、Claude Codeで 計画 → 実装 → PR作成 → レビュー対応 → 振り返り までを一気通貫で回す、
「GitHub Vibe Flow（仮）」という運用を作って、 並列開発でも破綻しないようにしてみた。
GitHub Vibe Flow（仮）とは？
GitHub Vibe Flow（仮）は、Claude CodeとGitHubを開発プロセスの一部として包括的に扱うやり方で、 実際に人と開発するときのプロセスを再現することを狙って作ったもの。
狙いは以下の3つにした。
- 次に何をするかを固定して、認知負荷を下げる
- Issueを並列で進めてもブランチ事故を起こさない
- 最後にレトロスペクティブを行ってAgent自体を成長させる
GitHub Vibe Flow（仮）の準備
CLAUDE.mdを作った
まず CLAUDE.md を作った。ここはClaude Codeの行動原則を書く場所になる。
面倒なので /init で出来上がったものをベースにして、そこから少しずつ調整した。
自分は英語弱者なので、トークン消費よりも認知負荷を下げることを優先して、 コミュニケーションルールとして「日本語でやりとりする」旨を記載した。 あわせて、判断が必要なときは「おすすめを書いてほしい」というルールも入れている。
例としてはこんな感じ。
## Communication Guidelines **日本語でのコミュニケーション:** - ドキュメンテーション（コメント、README等）は日本語で記述してください - チャット上でのコミュニケーションも日本語で行ってください - コード自体（変数名、関数名、型名等）は英語を使用してください **判断を仰ぐ場合の形式:** ユーザーに判断を求める際は、以下の形式で簡潔にまとめてください： === 【判断が必要な事項】 <判断が必要な理由や背景を簡潔に説明> 【判断材料】 - 選択肢A: <メリット・デメリット> - 選択肢B: <メリット・デメリット> - 選択肢C: <メリット・デメリット> 【推奨】選択肢X（理由: <推奨理由>） ===
これを入れたかどうかで、自分の場合は作業スピードがかなり変わった。
.claude ディレクトリを作った
.claude/ には Skills や Sub Agent の定義、運用ルールを置くようにした。
公式の推奨構成に従いつつ、最初からホームディレクトリに置くのではなく、 今回の作業対象リポジトリ内に置いて、実験的にプロセスを回してみた。
ここは「今回うまくいった／失敗した」を設定に還元して Agentの成長を担う場所になるので、常にきれいに保つようにしている。
GitHub MCPを適用した
Issue、PR、レビュー、CIログをClaude Codeから直接扱えるようにした。
プロセスの中でGitHubを頻繁に参照する前提なので、 ここは実質必須だなという感触だった。
.mcp.json に以下を書いている。
トークンが含まれるので .gitignore を忘れないようにした。
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_TOKEN_HERE"
}
}
}
}
Skills（開発の流れを固定するコマンド）
細かいプロンプトはレトロスペクティブでどんどん修正がかかる前提なので、 最初は「このH3の目的を満たすSkillsを作って」と依頼するくらいの粒度で準備した。
/planning
- バックログ整理をする
- Issueを深掘りする
- 粒度や優先度を調整する
曖昧なIssueは、ここで必ず「実装できる形」にしている。
/create-issue
- GitHubにIssueを起票する
- 背景・目的・Done条件を明文化する
ここでは、実際にMCP経由でIssueが作られているかを確認するようにしている。
/start-issue <Issue番号>
- Issue内容を読み込む
- 実装方針を再確認する
git worktreeで環境を分離して実装を始める
並列でClaude Codeを動かす前提なので、worktreeは必須にしている。
git worktree add ../repo-issue-123 -b issue/123
/pr-ready
- 変更内容を要約する
- Sub Agentで事前チェックを行う
- PR本文を生成してPRを作成する
PR前に、定型的に確認できそうな部分と、 自分では気づきにくい部分を一度まとめてチェックさせている。
/review-follow
- PRレビューを確認する
- 修正要否を判断する
- CIログを解析して対応する
CIが重い場合は、ログ解析専用のSub Agentに投げている。 GitHub上で動くClaude botのレビューもあわせて確認し、必要があれば修正している。
/retrospective
これは、無事にマージできた後やPRをCloseした後に実施している。 （最終的に複数のAgentが同じテキスト空間を共用してスクラム開発的なレトロスペクティブをさせたかったけど実体はただのフィードバックなので普通に/feedback とかでも良いかも。
- 今回のセッションを振り返る
- 詰まった点・改善点を抽出する
CLAUDE.mdや.claudeに反映する
ここでやっていることは、いわゆる「反省会」ではなく、 次回以降のClaude Codeの振る舞いを変えるためのフィードバック整理に近い。
たとえば、
- 何度も判断を仰がれた → 判断フォーマットを
CLAUDE.mdに追加する - PR前に同じ指摘を受けた → Sub Agentのチェック項目に入れる
- 指示が曖昧で手戻りした → Skills側の目的定義を修正する
といった形で、 人間側の反省をコードではなく「Agentのルール」に落とすようにしている。
レトロスペクティブをここまでやると、 「Claude Codeを使っている」というより 「Claude Codeを育てながら一緒に開発している」感覚に近くなってきた。
この運用を入れてから、 同じ失敗を繰り返す回数が明らかに減ったので、 GitHub Vibe Flow（仮）の中でも一番効果が高いパートだな と思っている。
Sub Agentsの構成
PR前チェック用（/pr-ready から呼ぶ）
code-simplifier
実装されたコードを読み、不要な複雑さや冗長な処理がないかを確認する。 責務が混ざっている箇所や命名の分かりにくさを指摘し、改善案を提示する。
architecture-reviewer
変更内容が既存のアーキテクチャや設計方針と整合しているかを確認する。 依存関係や責務分離、将来的な拡張性の観点からレビューする。
build-validator
ビルド、テスト、型チェック、lint が正しく通るかを確認する。 失敗している場合は、原因と修正方針を簡潔にまとめる。
app-verifies
アプリケーションの振る舞いが期待通りかを確認する。 主要なユースケースを想定し、E2Eテストや手動確認観点で抜け漏れをチェックする。
security-reviewer
セキュリティ上の問題が入り込んでいないかを確認する。 入力値検証や認可漏れ、情報漏えいにつながる点を重点的に見る。
レビュー対応用（/review-follow から呼ぶ）
pr-handler
Pull Request に対するレビューコメントや CI の実行結果を整理する。 指摘内容や失敗ログを分解し、対応方針を分かりやすくまとめる。
運用の流れまとめ
- /planning でバックログ整理・Issueの洗い出しをする
- /create-issue で実装可能な粒度のIssueを作成する
- /start-issue で環境分離して実装・検証する
- /pr-ready で変更内容をまとめてPull Requestを作成する
- /review-follow でレビュー対応・CI対応を行う
- /retrospective で今回の開発を振り返り、ルールを改善する
必要であれば /planning と会話しながら、Issueを n 並列で回している。
感想
並列数を増やすことはスピードを上げる手段ではあるけど、 それ以上に大切なのは、
- 自分がオーナーとして plan を読むこと
- PRとレビュー結果をちゃんと読むこと
- Claude Codeの成長に資するフィードバックを返すこと
だなという感じだった。 ちなみに、自分の場合は4並列くらいまでしか自然知能が対応できなかった。
Claude Codeは速くしてくれるけど、 責任までは引き取ってくれないので、そこは人間の仕事。
仕事で管理職をやっていて趣味くらいは役割から外れようと思っていたのに、 趣味の開発でも、ついに管理職になる時代が来たっぽい。
ちなみにこれを使って実際に作ったのはLIFEGAME
- Webサイトとして成立させる
- 初期状態固定のLIFEGAMEができるようにする
- クリックしたらセルを編集できる
- デザインを厨二病にする（←もっと細かいこと言った
- 設定値も編集できる
くらいのIssueに分けて実行したけど、ほとんど並列度を上げるまでもなくサクサク出来上がった。
