はじめに
先日、Claude Code活用事例にて登壇させていただき、 「Claude Code くん、君には全てを任せないが ほとんどは任せよう」 というタイトルで5分LTを行いました。持ち時間の都合で触れきれなかった 実践テクニック を、この記事でまとめ直します。
スライドはこちらになりますので、興味あれば覗いてみてください。
この記事で得られること
- ✅ Plan mode ×
plan.md× 【指摘】運用 の具体的なワークフロー（CLAUDE.md の実例付き） - ✅ Claude Code × Codex の マルチAIレビュー体制 の組み方と使い分け
- ✅ 「AIに任せつつ、責任の所在を曖昧にしない」ためのマインドセット
「ほとんどを任せる」の全体像
LTの中でも少し触れましたが、自分は日々の開発業務の中でかなりの時間を Claude Code に費やしています。自分の仕事を全て奪って欲しいという勢いで使っています。というのも、実際自分だけが手を動かすよりも、適切に指示を出して Claude Code を最強の相棒に育てた方が、圧倒的に生産性が上がったという実感/実績があるからです。
Claude Code に任せている作業は、今のところ以下です。
| 領域 | 任せ方 |
|---|---|
| 💭 壁打ち相手 | アイデアの整理、思考の言語化 |
| 🏗️ 設計 | アーキテクチャ・技術選定の検討 |
| 💻 コード作成 | 実装の大部分 |
| 🔍 コードレビュー | Claude Code + Codex を併用したマルチAIエージェント体制 |
| 📝 ドキュメント作成 | 設計書・仕様書 |
| 🚀 PR作成 | コミット分割・PR 文面 |
こうやって書くと、「実際Claude Codeしか仕事してなくない？」と思うかもしれません（書いてて自分自身でも思いました）。
一方、自分自身が担当している のは次の3つだけです。
-
仕様の把握
このタスクが「どういう修正を」「どういう背景から」求められているか、Claude Code に適切な指示を出すための下地を自分で作ります -
修正内容の把握
Claude Code が書いたコードを読み、自分のもの として理解します -
責任を持つ
生成されたコードに対して、障害が起きたときに自分が対応する覚悟を持ちます
この 「任せる / 任せない」の境界 をどう引いているかを、以下で具体的に掘り下げます。
※今後も凄まじいAIエージェントの進化により、全てを任せた方が賢明な判断になるケースも出てくると思います。人間の理解の曖昧さがボトルネックになるパターンもあると思います。なのでこの意見はあくまで「2026年4月時点での自分の運用ルール」として読んでいただければと思います。
全部任せて失敗した話
自分自身最初から上手く運用できていたわけではありません。AIエージェント主体で取り組む「AI駆動開発」に挑戦し始めたのも、Claude Codeがリリースされて社内で利用できるようになってからなので、2025年の夏頃からです。明らかにこれまでのAIエージェントとは違う感動をしたのを覚えています。のちにPlanモードがリリースされ、「計画立ててから進めてくれるから、ある程度自走させても上手くいくんじゃない？」と思い、任せる ことを増やしていきました。(Planモードは Claude Code のプロンプト入力中に Shift+Tab で切り替え可能です。詳細な設定については公式ドキュメントを参照してください。)
Planモードを利用すると、プロンプトに対する計画を立ててくれます。その計画を承認すると、その通りに実装を進めてくれる、という流れです。自作プランニングポーカーアプリの改善を例に、実際のやり取りを載せてみます。
※プランニングポーカーアプリの概要としては、チームでストーリーポイントを見積もるWebアプリです。ルーム作成/参加→Azure DevOps URLで作業項目取得→Fibonacciカードで一斉投票→結果公開・Azure DevOpsへ反映。SSEでリアルタイムに同期する簡易的なアプリです。
❯ このアプリの使いやすさ向上のためにできることって何がある？
planning-pokerアプリの使いやすさ向上について、まず現状を把握する必要があります。
⏺ 3 Explore agents finished
├─ planning-pokerアプリ全体調査 · 61 tool uses · 84.0k tokens
├─ UI/UX関連コード調査 · 64 tool uses · 76.4k tokens
└─ ドキュメントと課題調査 · 31 tool uses · 57.8k tokens
調査結果を踏まえて、このアプリの使いやすさ向上の策を整理します。
現状サマリ
Next.js 15 + React 19 + SSE のリアルタイム投票アプリ。基本機能は
揃っており、直近3月末にUX改善フェーズも実施済み。ただし伸びしろが
大きい領域が複数見つかりました。
改善候補を7カテゴリに整理
A. キーボード操作 / ショートカット（体感インパクト大）
- カード選択を Tab/矢印キー＋Enter で操作可能に（Card.tsx に focus:ring-* 無し）
- 数字キー（0-9）で投票、R で公開/リセット、C でルームコード・URLコピー
- ADOを見ながら片手で投票するのがダルい
B. Azure DevOps URL 入力のダル解消
- 履歴サジェスト（localStorage）
- 複数URL一括ペースト → キュー化してラウンドを回す
C. モバイル / タッチ最適化
- lg: ブレークポイントしかない → md/smでの最適化
- タップターゲット 44px 未満のもの（ParticipantList行、アイコン）を拡大
D. 通知 / フィードバック
（以下 E. 投票体験, F. アクセシビリティ, G. 永続化 と続く…）
実際に与えているプロンプトは「このアプリの使いやすさ向上のためにできることって何がある？」という1文だけなのに、これだけのアウトプットが返ってきます。一方でもっと詳細で長いプロンプトを与えた際は、アウトプットも長くなります。
- Claude Codeの計画がターミナルに 長文で流れてくる
- 全部に目を通せず 流し読み でGOサインを出してしまう
- 期待外れのアウトプットが返ってきて「あれ？」となる
Claude Codeは実装計画を提案してくれているのに、この時の自分は、「任せた」つもりで実は ただ放任していた だけだったことが分かりました。
Claude Codeの精度は十分に高いです。ですが全てが完璧ではないため、提案の内容をしっかり確認して、必要に応じて修正指示を出す ことが重要です。最強の相棒として、お互いを補完し合うために 「確認の仕組み」 を作る必要があります。
ここからが本題の、その「確認の仕組み」です。
深掘り①：Plan mode × plan.md × 【指摘】運用
Claude Code は、実装前に「まず計画を立てて見せて」と指示できる Plan mode を持っています。これは実装を始める前に、Claude Code の提案を確認できるモードです。
ただ、Plan mode をそのまま使うだけでは先述の 流し読み問題 は解決しません。そこで次の3ステップを足しています。
❶ plan.md というファイルに書かせる
まず、計画をターミナル表示ではなく plan.md というファイルに書き出させる ようにしました。実際に自分が ~/.claude/CLAUDE.md に記載している内容はこちらです。
## 計画と実装のルール（必ず守ること）
### 実装前の計画
- コード変更・ファイル編集を伴うタスクでは、実装前に必ず `plan.md` をプロジェクト直下に出力すること
- `plan.md` には以下を含めること:
- **Context**（何をなぜやるのか、背景）
- **変更一覧**（ファイル別・機能別に具体化）
- **検証方法**（どうやって動作確認するか）
### 【指摘】レビュー運用
- `plan.md` 内の `> 【指摘】` は私が書き込んだレビューコメント
- 次のターンで必ず該当箇所を読み返し、計画に反映すること
- 反映後、どこをどう直したか計画書内または返答で明示すること
### 実装開始のサイン
- 私が「GO」「進めて」「OK」等で明示的に承認するまで、実装コードには手をつけないこと
- 単発の質問・小さな修正（typo・1行fix等）は plan.md 不要
この記載によって、Claude Codeが計画を立てる時は必ず plan.md に書いてくれるようになります。これが 確認の仕組みの第一歩 になります。出力先をターミナルからファイルにすることで、
- エディタで開いて読みやすい
- 横断検索や履歴管理ができる
-
指摘事項を
plan.mdに直接書き込める（運用の決め手） - 後で「あのとき何を計画したか」が残る
という地味だけど、確実なメリットが生まれます。
❷ 【指摘】コメントで計画をブラッシュアップ
plan.md の気になる箇所に 【指摘】 というマーカー付きコメントを書き足します。
### 1. ファシリテーター機能の強化
- `lib/room/store.ts`: ファシリテーターが `revealVotes` / `resetVotes` / `setStory` を実行できるように権限チェックを整理
- `components/FacilitatorControls.tsx`: 操作ボタンはファシリテーターのみに表示
> 【指摘】 ファシリテーター権限は撤廃したい。参加者誰でも操作できるように
### 2. 投票タイマー表示
- `hooks/useVotingTimer.ts`: `phase` と `storyId` の変化でタイマー開始/リセット、1秒ごと更新
- `app/room/[roomId]/page.tsx`: ページ下部にタイマー表示
> 【指摘】 タイマーの表示位置はヘッダーに固定してほしい
書き足したら Claude Code に「指摘箇所を見て」と伝えるだけで、次のターンで計画をブラッシュアップしてくれます。この往復をN回繰り返して、自分が納得できる計画 を作っていきます。
❸ GOサインを出してから実装開始
計画書が納得できる形に仕上がったら、最後は自分がGOサインを出します。ここで初めて実装が始まります。
Before : 提案 → 流し読み → 不本意なGO → 期待外れ
After : 提案 → plan.md → 【指摘】で磨く → 納得 → GO → 期待通り
この3ステップは ❶ の CLAUDE.md に書いてあるので、毎回 Claude Code に「plan.md に書いて」「指摘を反映して」と指示する必要はありません。
深掘り②：マルチAIレビュー体制
plan.md で実装前の計画は磨けます。でも、書き終わったコードそのもののレビュー は別の問題です。
Claude Code に「自分で書いたコードをレビューして」と頼むと、どうしても 自己採点 になりがちです。そこで、別のAIエージェントを使うか、新しく Claude Code のセッションを立ち上げて、レビューしてもらうようにしています。今回は特に Codex を併用する運用について紹介します。
なぜ Codex を併用するのか
Claude Code 向けの Codex プラグイン で、同じセッションからシームレスに呼べるようになったからです。以前は別ターミナルで Codex を立ち上げたり、Codex App に貼り付けて依頼し、その結果を Claude Code に戻す、という手間がありました。プラグインを入れれば 同じセッション内でそのまま両方に依頼できる ので、マルチAIエージェント体制の構築コストが一気に下がります。
また個人的には実装の大部分をClaude Codeで、レビューはCodexでという役割分担が相性いいと思っていますが、別のAIエージェントをレビューに使うのも全然アリだと思います。もちろん実装をClaude Code任せないという意見もあるかと思います。
使い分け：/codex:review と /codex:adversarial-review
Claude Code 向けの Codex プラグインには、
-
/codex:review— git 差分に対する通常のコードレビュー -
/codex:adversarial-review— 設計判断やトレードオフを 問い直す挑戦的レビュー
があります。使い分けは以下のように考えています。
| レビュー | 使う場面 | 期待する指摘 |
|---|---|---|
/codex:review |
PR を出す直前、実装が終わった段階 | バグ・抜け漏れ・命名・型の不整合 |
/codex:adversarial-review |
設計が大きめの変更をしたとき | 「そもそもこの設計でいいのか」 |
レビュー以外のコマンド
Codex プラグインにはレビュー以外のコマンドもあります。本編からは逸れるので一覧だけ掲載します。
| コマンド | 役割 |
|---|---|
/codex:setup |
初回セットアップ・認証確認 |
/codex:rescue |
Codex に調査・修正・フォローアップを委任（Claude Code が詰まったときに強力） |
/codex:status |
実行中・完了ジョブの一覧表示 |
/codex:result |
バックグラウンドジョブの最終結果を表示 |
/codex:cancel |
実行中のジョブをキャンセル |
実際のフロー
1. Claude Code で実装（plan.md に基づき）
2. Claude Code 自身のセルフレビュー
3. /codex:review で Codex に別視点レビューを走らせる
4. 大きな設計変更があれば /codex:adversarial-review も追加
5. 両方の指摘を突き合わせて修正
6. PR作成
1人で書いていても、実装者とは別視点のレビューが入ります。これがマルチAIエージェントを活用する最大のメリットです。
深掘り③：責任の所在を曖昧にしない
ここは思想的な話ですが、運用の 底を支える発想 なので触れておきます。
本番環境で障害が起きたケースを考えてみてください。
- ❌ 「Claude Code が書いたコード」 と捉えると
- 誰の責任？ 当事者意識が希薄になります
- コードが他人事になります。チームの会話も「Claude Code がやらかした」と他責化していきます
- 結果、Claude Code に放任するだけ の関係に逆戻りしてしまいます
- ✅ 「自分が Claude Code で書いたコード」 と捉えると
- コードは自分のもの。障害が起きたら自分が対応します
- 自分のアウトプットを最大化するために、Claude Code を最強の相棒として育てます
主語の取り戻し。これをしておかないと、"任せる" の運用はどこかで崩れます。
Plan mode で計画を磨くのも、マルチAIでレビューするのも、技術的な話のようでいて 最終的には「自分が書いたコード」として世に出すために、自分ができる精一杯の工夫 だと思っています。
まとめ
「ほとんどを任せる」は、次の3つの仕組みで成立しています。
- Plan mode × plan.md × 【指摘】運用 — 実装前の計画を磨き切る
- Codex とのマルチAIレビュー — 実装後のコードを別視点でチェック
- 主語を「自分」に取り戻す — 責任の所在を曖昧にしない
Claude Code は最強の相棒です。でも主体は、あくまで 自分。Claude Code に全てを任せるのではなく、自分が書いたコードとして、Plan mode で計画を磨き、マルチAIレビューで品質を高めます。これが、2026年4月時点での自分の「ほとんどを任せる」運用ルールです。
1日単位で状況が移り変わっていくため、この考え方が来週には古くなっている可能性もあります。ですが 「任せる / 任せない」の境界を自分の中で明確に持つこと は、AIエージェントと共に働く上での重要なマインドセットだと思っています。
最後に
ここまで紹介した plan.md + 【指摘】運用 と マルチAIレビュー の他に、弊社各チームで様々な取り組み、最新情報のキャッチアップが行われています。また、それらの取り組みを社内向けに展開するためのイベントの企画・実施もしています。
Claude Code に賭けて開発を進めたいエンジニアを募集しています。興味がある方はぜひ 株式会社デジタルバリュー 採用ページ からご応募ください！
フルリモートなので、全国どこからでも Join お待ちしております！