2026年6月現在の Claude Code 開発フロー

こんにちは。フィッツプラスでフロントエンドエンジニアをしている梅津です。

2025年後半から Claude Code を使い始めて、少しずつ設定を育ててきました。気がつけば普段の開発フローがだいぶ固まってきたので、2026年6月時点の構成を紹介します。

紹介する内容は以下の通りです。

• 前提: 使っているツール
• 普段の開発フロー
• 開発フローを支える Plugin・Skills・Hook

前提: 使っているツール

開発フローの話に入る前に、普段使っているツールを簡単に紹介しておきます。

Claude Desktop

最近は Claude Desktop をメインの作業環境にしています。ターミナルを開かずに Claude Code を動かせて、複数のセッションを並行して走らせるときもアプリ上で切り替えられるので、ウィンドウを行き来する手間が少ないのが気に入っています。

WezTerm

ターミナルを使うときは WezTerm を開いています。モテるターミナルにカスタマイズしよう（WezTerm）を参考にカスタマイズしました。

タブは画面下部に配置しています。複数の作業ディレクトリを行き来することが多いので、タブの視認性が良いのはありがたいです。

ちなみに背景画像は佐賀県の呼子で撮った写真を使っています。呼子は心のふるさとです。

gtr（git-worktree-runner）

Git worktree の管理には gtr を使っています。git gtr new <ブランチ名> でブランチに対応した worktree を作成できます。設定ファイルのコピーや依存関係のインストールといった後処理もフックとして設定できるので、一度セットアップしておけば worktree 作成後にすぐ作業に入れます。git gtr go <ブランチ名> で既存の worktree に移動できます。ブランチごとに作業ディレクトリが分かれるので、複数の作業を並行して進めやすくなります。

Neovim

簡単なコーディングやコードリーディングは Neovim で済ませることが多いです。ターミナル内でさっと開いて完結できるので、エディタを立ち上げ直す手間がありません。

Zed

深いコードリーディングや、マークダウンのプレビューを見たいときは Zed を使っています。動作が軽く、VSCode より起動も速いので、気軽に開けるのが気に入っています。

普段の開発フロー

普段の開発フローの全体像を紹介します。後述する Plugin・Skills・Hook がどう噛み合っているかのイメージを持ってもらえると思います。

大まかな流れは以下の通りです。

1. worktree を作る — git gtr new <ブランチ名> で作業用の worktree を作成します
2. チケットを Claude に読ませる — Backlog MCP でチケットの内容を取得し、Claude に渡します。「このチケットをやりたい」と伝えるだけで、チケットの内容を読み取って作業に入ってくれます
3. Plan（計画） — Claude Code を Plan モードで動かしているので、いきなり実装に入らず、まず計画ファイルを作って承認を待ちます。このとき計画ファイルには、要件チェックリスト（REQ-1、REQ-2...）やテストケース一覧といった「完了条件」をチェックボックス形式で書いておきます。ここで書いた完了条件が、あとで品質ゲートの検証対象になります
4. 計画レビュー — 必要に応じて /codex-review で計画ファイルの妥当性を Codex にチェックさせます。テストケースの抜け漏れや設計の問題点を指摘してくれます
5. 実装 — 承認した計画に沿って Claude が実装を進めます
6. 自動品質ゲート — 実装が終わると dev-flow-gate（Stop Hook）が自動で発火し、計画ファイルの検証 → コード整理 → Codex レビュー → Draft PR の作成までを順番に通過させます
7. ブラウザ動作確認とセルフレビュー — Draft PR ができたら、フロントの変更があれば /browser-check で Claude にブラウザを操作させ、画面の描画・遷移・操作が壊れていないかを観測してもらいます。開発中の状態を作り込む確認にはモックを使う local モード、デプロイ済みの実機確認や PR への証跡貼り付けには staging モードを使い分けます。Claude が動作確認をしている間に、私は PR のコードをセルフレビューする、という並行作業になります

手動で介入するのは、主にステップ1〜4の計画づくりと、最後のセルフレビューです。チケットの内容を渡して計画を確認したら、実装から Draft PR の作成までは Claude と Hook が連携して進めてくれます。PR ができたら、Claude にブラウザで動作を確認させつつ、私はそのあいだに PR のコードへ目を通す。そんな分担に落ち着いています。もちろん途中で確認や修正を入れることもあります。

Plan モードをデフォルトに設定

この開発フローの起点になっているのが、settings.json の permissions.defaultMode を plan にしている設定です。

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Claude Code には複数のパーミッションモードがあり、plan モードでは Claude がいきなりコードを書き始めるのではなく、まず計画ファイルを作成してユーザーの承認を待ちます。

AI がいきなりコードを書き始めると、こちらの意図とズレた変更をされることがあります。Plan モードにしておけば、実装の前に「何をどう変えるか」を確認して認識を合わせられるので、的外れなコード変更を防げます。superpowers Plugin の writing-plans スキルと組み合わせると計画立ての質がさらに上がりますし、計画ファイルはマークダウンで出力されるので、あとから振り返ることもできます。

そして、計画ファイルに書いた要件チェックリストやテストケースは、ただのメモではありません。後述する dev-flow-gate の Phase 2 が、このチェックリストと実際のコード変更が同期しているかを検証します。計画を「書いて終わり」にせず、実装と歩調を合わせ続けるための仕組みです。

開発フローを支える Plugin・Skills・Hook

ここからは、上で紹介した開発フローの中で使われている Plugin・Skills・Hook を詳しく紹介します。

Plugin

Claude Code には Plugin という仕組みがあり、公式やコミュニティが提供する機能拡張を追加できます。settings.json の enabledPlugins で有効・無効を管理します。

開発フローに関わっている、公式・コミュニティ製の Plugin は以下の3つです。

superpowers

superpowers は Claude Code の振る舞いを大きく変える Plugin です。計画立て、ブレインストーミング、TDD、デバッグなど、さまざまな開発ワークフローのスキルがまとまっています。

特に便利だと感じているのが brainstorming（ブレインストーミング）です。何か実装を始める前に、質問形式で「何を作るのか」「どういう制約があるのか」を対話的に整理してくれます。自分の頭の中にあるぼんやりしたイメージを、質問に答えていくうちに具体化できるのが良いところです。

計画立ての場面では、brainstorming で要件を固めてから writing-plans で計画ファイルに落とし込む、という流れがそのまま開発フローのステップ3につながっています。これらは適切なタイミングで自動的に発動します。たとえば「この機能を作りたい」と伝えると brainstorming が動き出し、計画がまとまると writing-plans に切り替わる、という具合です。

code-simplifier

code-simplifier は、コードの簡素化・リファクタリングを行う Plugin です。後述する dev-flow-gate の Phase 3（Simplify）で /simplify スキルとして呼び出されます。

codex

codex は、OpenAI の Codex エージェントを Claude Code に接続する Plugin です。

この Plugin にはコードレビューのゲート機能が用意されていて、dev-flow-gate の Phase 4 で、この Plugin が提供する reviewer（/codex:review）を呼び出してコードレビューを行っています。

こうしたレビューの仕組みは自作のスクリプトで組むこともできますが、公式が用意してメンテナンスし続けてくれるものに乗っかるほうが、結局は楽で安定します。

自作プラグインをチームで共有する

公式やコミュニティの Plugin だけでなく、自分たちで作った Plugin もチームで共有しています。

社内にマーケットプレイスを用意して、共通で使いたいスキル（コミットや PR 作成など）を Plugin としてまとめて配布する、という取り組みです。もともと個人の ~/.claude に閉じていた設定を、チームの資産として展開していくイメージです。同じ設定をメンバー間で揃えられると、開発フローそのものをチームで揃えていけるのが良いところだと感じています。

カスタム Skills

Claude Code の Skills は、~/.claude/skills/ にマークダウンファイルを置くことで定義できるプロンプトテンプレートです。/スキル名 の形で呼び出せます。

開発フローで使っているスキルを紹介します。

commit は、変更内容を分析して Conventional Commits 形式のコミットメッセージを自動生成します。曖昧なメッセージ（「fix」や「レビュー対応」など）を書かせない仕組みになっていて、タイトルと本文を分けた丁寧なコミットメッセージが出てきます。変更が多い場合は適切な粒度に分割してくれるのも便利です。

pr は、PR の作成と更新を一括で行います。まだ PR がなければ Draft で新規作成し、すでにあれば本文を再生成して更新します。コミット履歴を分析して PR の説明文を組み立ててくれるので、手書きの手間が省けます。

codex-review は、Codex を呼び出してレビューを実行する自作スキルです。今は主に計画ファイルのレビューに使っていて、実装に入る前に /codex-review で計画の実現可能性やテストケースの抜け漏れを Codex にチェックさせます。コードのレビューは codex Plugin に任せているので、こちらは計画のレビューに専念させています。

browser-check — ブラウザで振る舞いを確認する

browser-check は、フロントエンドの変更がユーザーから見える振る舞いを壊していないかをブラウザで確認するスキルです。

実行ツールには playwright-cli を使っています。/browser-check と呼び出すと、変更の影響範囲を観測可能な振る舞いに翻訳し、チェックリストを作って、ブラウザで一つずつ観測していきます。

モードは2つあります。

このスキルで大事にしているのは、実装の詳細ではなく、ユーザーが画面を通じて観測できる事実を確認するという考え方です。

• ❌ 「createNuxtLinkActiveClass が active クラス文字列を返す」
• ✅ 「メニューをクリックすると該当画面に移動し、その項目が強調表示される」

私はもともとテストを書くときも、実装の詳細ではなくユースケースに注目する考え方（Kent C. Dodds の影響を強く受けています）を大事にしてきました。browser-check はそれをブラウザでの動作確認にそのまま持ち込んだ形です。単体テスト（Vitest）が「ロジックの正しさ」を担保するのに対して、browser-check は「画面に出る・遷移する・操作できる」という結合後の振る舞いを担保します。役割が分かれているので、両方あると安心感が違います。

Hook

Claude Code には Hook という機能があります。Claude が特定のアクションをするタイミングに、任意のシェルスクリプトを差し込める仕組みです。対応しているイベントのライフサイクル全体は公式ドキュメントに詳しく載っています。

開発フローで使っているイベントは以下の2つです。

• PreToolUse: ツール実行の前に発火。実行の許可・拒否を制御できる
• Stop: Claude が応答を終えてユーザーに制御を返す瞬間に発火

settings.json の hooks セクションに、イベントごとにスクリプトを登録します。開発フローに関わる部分を抜き出すと、このようになっています。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$HOME/.claude/hooks/skill-guard.sh\"",
            "timeout": 5
          }
        ]
      },
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$HOME/.claude/hooks/terraform-guard.sh\"",
            "timeout": 5
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$HOME/.claude/hooks/dev-flow-gate.sh\"",
            "timeout": 180
          }
        ]
      }
    ]
  }
}

matcher でどのツールに対して発火するかを絞り込めます。たとえば skill-guard と terraform-guard は "Bash" を指定しているので、Bash ツール（コマンド実行）のときだけ動きます。

それぞれのスクリプトの中身を紹介します。

skill-guard — コマンドの直接実行を防ぐ

git commit や gh pr create などのコマンドを Claude が直接実行するのをブロックする Hook です。PreToolUse（Bash）で発火します。

#!/bin/bash
# セッション固有のフラグファイルパスを取得（並行 worktree セッション対応）
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
FLAG_FILE=$("${SCRIPT_DIR}/skill-flag-path.sh")
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# git commit パターンの検出
if echo "$CMD" | grep -qE '^\s*git\s+commit'; then
  if [ -f "$FLAG_FILE" ]; then
    exit 0
  fi
  # deny JSON を出力してブロック
  cat <<'JSON'
{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"git commit を直接実行しないでください。代わりに /commit スキルを使用してください。"}}
JSON
  exit 0
fi

仕組みはシンプルです。/commit や /pr スキルは実行開始時にフラグファイルを作成します。このスクリプトはフラグファイルの有無で「スキル経由かどうか」を判定し、直接実行ならブロックします。worktree を並行して使うことが多いので、フラグファイルのパスはセッションごとに分けています。

なぜこうしているかというと、/commit スキルには Lint・型チェック・テストの実行、変更の適切な粒度への分割、Conventional Commits 形式でのメッセージ生成が組み込まれているためです。直接 git commit されるとこれらをすべてスキップしてしまいます。gh pr 系のコマンドも同じようにガードしていますが、view や diff といった読み取り系は素通しにして、邪魔にならないようにしています。

terraform-guard — インフラ変更にブレーキをかける

terraform apply と terraform destroy をブロックする Hook です。こちらも PreToolUse（Bash）で発火します。terraform init、terraform plan、terraform fmt は許可しています。

インフラ変更は PR レビューを経てから適用する運用にしたいので、Claude が勝手に apply しないようにしているだけのシンプルな Hook です。

dev-flow-gate — 5フェーズの自動品質ゲート

Stop Hook で発火する、一番特徴的な Hook です。Claude が応答を終えようとするたびに実行され、コード変更があれば以下の5つのフェーズを順番に通過させます。前半の2つは計画ファイルの検証、後半の3つはコードの整理・レビュー・PR 作成にあたります。

Phase 1: 計画ファイルのコンプライアンス検証

計画ファイルの名前が規約（yyyyMMdd-機能名）に沿っているか、1つの PR が1つの計画ファイルに対応しているか、といった形式面をチェックします。

Phase 2: TODO 完了・チェックリスト同期検証

ここが計画ファイルと実装をつなぐフェーズです。Plan のステップで計画ファイルに書いておいた完了条件（チェックボックス）と、実際のコード変更が同期しているかを検証します。

具体的には、ベースブランチ時点と現ブランチ時点の計画ファイルを比較して、「このブランチで満たした項目がきちんと - [x] になっているか」「コードは変わっているのにチェックリストが更新されていないか」を自動で検出します。

計画ファイルを書いても、実装を進めるうちにチェックの更新を忘れて、いつのまにか計画と実態がズレていく、ということが起こりがちです。Phase 2 は、それを「書いて終わりの資料」にせず、実装と歩調を合わせ続けるための仕組みです。

Phase 3: Simplify（コード整理）

未コミットのコード変更を検出すると、/simplify スキルを呼び出してコードの簡素化・整理を指示します。

Phase 4: Codex Review（自動レビュー）

Simplify が完了すると、公式 Codex Plugin の reviewer（/codex:review）を呼び出して自動コードレビューを実行します。バグの可能性、セキュリティの問題、ロジックエラーを検出します。問題があれば修正して再試行します。

Phase 5: PR 作成

feature ブランチの場合、Codex レビューが通ったら /commit と /pr スキルを呼び出して、コミットと Draft PR の作成を自動実行します。develop、main、master ブランチではこのフェーズはスキップされます。

各フェーズの状態はハッシュベースで管理していて、同じ変更内容に対して同じフェーズを再実行しない仕組みになっています。また、各フェーズには安全弁（最大リトライ数）があり、何らかの理由で通過できない場合は自動的にスキップされます。

完了時にはサマリーが表示されます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[開発フローゲート] 完了サマリー
  ブランチ: feature/add-user-form
  ディレクトリ: /path/to/project
──────────────────────────────────────────
  Phase 1 (計画ファイル検証): ✅ 完了
  Phase 2 (チェックリスト同期): ✅ 完了
  Phase 3 (Simplify): ✅ 完了
  Phase 4 (Codex Review): ✅ 完了
  Phase 5 (Draft PR作成): ✅ 完了
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

一時的に無効化したいときは /gate off で止められます。

さいごに

いかがだったでしょうか。2026年6月時点の開発フローを一通り紹介しました。

設定を育てるにあたって意識していることは、3つあります。

1つ目は、公式の Plugin やスキルがあればなるべくそれを使うということです。自作のスクリプトやプロンプトで頑張ることもできますが、公式のものは他の人の知見が集まっていますし、アップデートで勝手に改善されていきます。コードレビューを公式 Codex Plugin に任せているのは、まさにこの考えからです。

2つ目は、計画とコードのズレや形骸化を、仕組みで防ぐということです。計画ファイルを書く運用にしても、更新を忘れれば計画と実態はすぐにズレていきます。dev-flow-gate に Phase 1 と Phase 2 を置いているのは、それを人間の注意力に頼らず、自動で検出したかったからです。

3つ目は、Claude が計画から PR 作成まで自律的に走り切れる精度と安定性を底上げするということです。チケットの内容を渡して計画を確認したら、あとは実装・確認・レビュー・コミット・PR 作成まで自動で進むのが理想です。人間が介入するのは方向性の判断だけにして、作業は Claude に任せる。そういう形を目指して、少しずつ調整を重ねています。

ぜひ皆さんも、自分なりの開発フローを育ててみてください。

それでは、また。