免責事項：このアプローチは個人プロジェクトでのみ使用しており、仕事ではまだ試していません。チームで上手くいくかは分かりませんが、私個人には効果的です。

これは2025年12月8日時点のワークフローです。今後変わる可能性があります。

ツールとモデル

ツールキットはかなりシンプルで、主に3つだけです：

1. Claude Code + Claude Sonnet 4.5
2. Codex + GPT-5.1/5.2（推論高、要約自動）
3. Antigravity

よく使うMCP：

1. Github
2. Jira/Azure Devops
3. Sequential thinking
4. Chrome devtools
5. Context7

コンテキスト管理

compactはタスクの重要なコンテキストを失わせると感じるので、常にコンテキストウィンドウの少なくとも30%を確保するようにしています。残りのコンテキストが30%を下回ったら、Claude Code（またはCodex）に現在の進捗をMarkdownファイルにまとめてもらい、新しいセッションを開始します。

私のワークフロー

ワークフローを紹介する前に、GPT 5.1/5.2とClaude Sonnet 4.5の違いについて学んだことを共有します。

1. GPT 5.1/5.2は推論に優れている — 行き詰まった難しい問題に特に有効です。例えば、明確な原因がない問題をデバッグする際、GPTはよく解決策を見つけます。
2. GPT 5.1/5.2は受動的 — コードベースを積極的に探索せず、回答も簡潔で分かりにくいことがあります。
3. Codexはローカルコマンドが苦手 — サンドボックス環境で動いているようで、gitのような汎用コマンドは問題ありませんが、リポジトリ固有のツール（gradlew、terraformなど）では問題が発生しがちです。Claude Codeはこの点で優れています。
4. Claude Code Sonnet 4.5は徹底的 — コードベースを積極的に探索し、詳細で分かりやすい説明を提供します。ツールやコマンドの実行も上手です。欠点は、過剰なエッジケース処理やコメントで過度に設計しがちなことです。

簡単な比較：

私のワークフローは通常こうなります：

0. プロジェクトセットアップ — デフォルトのinitコマンドでプロジェクト用のclaude.mdファイルを作成します。（テンプレートを共有しています。）重要な内容：カスタムコマンド（./gradlew ktlintFormat detekt、pre-commit run --all-files、uv sync、taskfile/makefileのコマンドなど）と、エージェントが各ディレクトリの役割を理解できるようにコードベース構造を含めます。
1. 要件理解 — Jira/Azure DevOpsのMCPでチケット説明を取得し、Claude Codeにビジネス要件の理解を手伝ってもらい、すべてをmarkdownファイルにまとめます。
2. ソリューション探索 — Claude Codeにコードベースを探索させ、ソリューションを考えてもらいます。常に少なくとも3つの異なるアプローチと、それぞれの長所・短所・トレードオフをmarkdownに記録するよう求めます。このステップではウェブ検索も使うことがあります。シンプルなプロンプトを使っています。
3. 評価と決定 — 新しいCodexセッションを開いてソリューションを評価し、最終アプローチを選択（または統合）します。
4. 実装計画 — Claude Codeに戻り、最終ソリューションに基づいた詳細な実装計画を生成します。プロンプトはこちら。
5. コード作成 — 実装計画に従ってCodexにコードを書いてもらいます。このプロンプトで実行をガイドします。
6. テストと仕上げ — Claude Codeでテストとlintをすべてパスするまで実行します。Chrome DevTools MCPをテストとデバッグに使うこともあります。
7. コミットとプッシュ — この部分はまだ手動です — コミットメッセージを書いてGitHubにプッシュします。
8. （オプション）最終仕上げ — 必要に応じて、Antigravityでエンドツーエンドテスト（Chrome統合内蔵）とドキュメント作成を行います。

ビジュアルワークフロー

ワークフローの視覚的表現：

flowchart TD
    Start([新しいチケット開始]) --> Step0["0. プロジェクトセットアップ<br/>(カスタムコマンドとコードベース構造を含むclaude.mdを作成)"]
    Step0 --> Step1["1. 要件理解<br/>(Claude Code + Jira/Azure DevOps MCP)<br/>📝 出力：要件markdown"]
    Step1 --> Step2["2. ソリューション探索<br/>(Claude Code + ウェブ検索)<br/>📝 出力：3つ以上のアプローチと長所/短所/トレードオフ"]
    Step2 --> Step3["3. 評価と決定<br/>(新しいCodexセッション)<br/>📝 出力：最終アプローチ選択"]
    Step3 --> Step4["4. 実装計画<br/>(Claude Code)<br/>📝 出力：詳細な実装計画"]
    Step4 --> Step5["5. コード作成<br/>(実装計画に従ってCodex)"]
    Step5 --> Step6["6. テストと仕上げ<br/>(Claude Code + Chrome DevTools MCP)<br/>テストとlintをすべてパスするまで実行"]
    Step6 --> Step7["7. コミットとプッシュ<br/>(手動)<br/>コミットメッセージを書いてGitHubにプッシュ"]
    Step7 --> Step8{"最終仕上げ<br/>が必要？"}
    Step8 -->|はい| Step8a["8. 最終仕上げ<br/>(Antigravity)<br/>E2Eテストとドキュメント"]
    Step8 -->|いいえ| End([完了])
    Step8a --> End

    style Step0 fill:#e1f5ff
    style Step1 fill:#fff3e0
    style Step2 fill:#fff3e0
    style Step3 fill:#e8f5e9
    style Step4 fill:#fff3e0
    style Step5 fill:#e8f5e9
    style Step6 fill:#fff3e0
    style Step7 fill:#fce4ec
    style Step8a fill:#f3e5f5

並列作業パターン

実際には、3つのgit worktreeを使って3つのチケットを同時に作業しています：

graph LR
    subgraph "開発者（ボトルネック）"
        Dev[あなた]
    end

    subgraph "Worktree 1"
        T1["チケットA: OAuth2ログイン追加<br/>ステップ5: コード作成中"]
    end

    subgraph "Worktree 2"
        T2["チケットB: DBクエリ最適化<br/>ステップ2: ソリューション探索中"]
    end

    subgraph "Worktree 3"
        T3["チケットC: ダッシュボードUI再設計<br/>ステップ6: テスト中"]
    end

    Dev -.コンテキストスイッチ.-> T1
    Dev -.コンテキストスイッチ.-> T2
    Dev -.コンテキストスイッチ.-> T3

    style Dev fill:#ffd54f
    style T1 fill:#c5e1a5
    style T2 fill:#90caf9
    style T3 fill:#ef9a9a

よくある質問

1. スラッシュコマンド、サブエージェント、スキルは使いますか？

lintとテスト用のスラッシュコマンドは設定しています。カスタムスキルはまだ探索していません。サブエージェントは試しましたが期待通りではありませんでした。理由は以下で説明します。

2. これを自動化ワークフローにしようとしましたか？

はい、LangChainで試しました。問題は、コーディング時に各ステップを慎重にレビューする必要があることです。自動化ワークフローは人間の介入が多すぎて、目的を達成できません。これがサブエージェントを使わない理由でもあります — 出力を十分に監視できないのです。

Claude Codeインスタンスで別のClaude Codeを呼び出したり調整したりすることも試しました。しかし実際には期待通りの結果は得られませんでした。主に3つの問題があります：

• 人間がループに入ることは依然として必須です。

  人間はAIの推論と出力を注意深く追い、何か問題があればすぐに中断して修正入力を提供する必要があります。そうしないと、プロセスは簡単に間違った方向に進みます。Claudeは過度に同意的な傾向もあり、明示的にプロンプトしても「おっしゃる通りです」のような反応をし、十分に強い批判的フィードバックを提供しません。

• 長時間実行エージェントはメモリとコンテキスト管理に苦労します。

  最近この記事を見つけました：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents。有望なアイデアがありますが、まだ実践していないので、これは未解決の問題です。

• 開発ワークフローは時間とともに進化します。

  タスクが進むにつれて、開発プロセス自体がよく変わります。これにより、すべてを事前に固定ワークフローにロックすることが難しくなります。現在のモデルは、プロジェクトの特定の状態に基づいて最も適切な次の開発ステップを確実に決定するほど賢くありません。

3. spec-kitやBMADはどうですか？

それらも試しました。かなり厳格なウォーターフォール式ワークフロー（constitution→specify→clarify→plan→analyse→tasks→check→implement）に従います。各ステップが独自のmarkdownファイルを生成し、時々互いに矛盾します。主な問題は、実装中に問題を見つけてアプローチを変更する必要がある場合、フロー全体を再開しなければならないことです。また、エンジニアとして、何かにどうアプローチするかの直感を持っていることが多いので、そのオーバーヘッドは不要に感じます。

4. 時間がかかりそうですね。本当に速くなりますか？

良い質問です。最初は約20%の速度向上しか見られませんでした。しかし気づいたのは：本当の力は1つのタスクを速くすることではなく、複数のタスクを並行して行うことです。今は通常3つのgit worktreeを開いて、3つの異なるチケットを同時に作業しています。（3つが私の限界です — それ以上だとコンテキストスイッチとコードレビューについていけません。私がボトルネックになります。）

結果として全体で約2倍速くなりました。（3つのチケットを作業しているのになぜ3倍ではないのか？各チケットでレビューとデバッグにより多くの時間を費やす必要があるからです。自分で書いていないコードは通常レビューに時間がかかります。他の人が書いたPRを慎重にレビューする必要があるのと同じです。）