本記事は2026年6月に最新情報へ更新した（Dynamic Workflows・Claude Routines・Fable 5/1Mトークン等を追記し、運用実績を169万メッセージに更新）。
Claude Codeの新機能が毎週出る。Dynamic Workflows、Claude Routines、Fable 5、アーティファクト共有——リリースノートを追うだけで1日が終わる。
だが、169万メッセージをClaude Codeで回してきたPMとして断言する。機能を知っているだけでは、成果は出ない。
私はPM1人+AI社員の体制で5つの商用プロジェクトを同時進行している。その現場で見えた事実は明確だ。同じClaude Codeを使っていても、運用設計の有無で生産性は数倍変わる。指示の解像度と出力の品質は比例する——これはAIに丸投げして品質崩壊を経験したからこそ言える。
本記事では、Claude Codeの全機能をPM視点で整理し、「何ができるか」ではなく「PMがどう運用に組み込むか」を解説する。リリースノートに振り回される消耗から抜け出すための地図だ。
Claude Code 2026年6月——全機能マップ
まず全体像を把握する。2026年6月時点のClaude Codeは、単なるAIコーディングツールではない。プロジェクト運用の基盤だ。
| カテゴリ | 機能 | PMにとっての意味 |
|---|---|---|
| プロジェクト設計 | CLAUDE.md | プロジェクトの「憲法」。全エージェントの行動指針 |
| 安全策 | Hooks | main直接push禁止、セッション終了時の未コミット警告 |
| 標準化 | Custom Slash Commands / Skills | チーム共通の作業手順を属人化せずに共有 |
| 並列実行 | Agent Teams | 複数Issueの並行開発をWorker単位で分離 |
| 動的編成 | Dynamic Workflows | Claude自身が手順を動的生成し、最大1,000サブエージェントを並列実行 |
| 定期自動実行 | Claude Routines | スケジュール起動で定型タスクを自走（cron的） |
| 外部連携 | MCP Integration | 業務システム・ドキュメントとAIの接続 |
| モデル選択 | Fable 5 / Opus 4.8（1Mトークン） | タスクに応じたモデル使い分け。大規模コンテキストの一括把握 |
| 音声入力 | Voice Mode | push-to-talkで音声指示（一般提供） |
| コード品質 | Code Review | 専門エージェントによるPR自動レビュー |
| 定期監視 | /loop | 指定間隔での自動タスク実行 |
| イベント連携 | Channels | 外部イベントをセッションにプッシュ |
| 安全な試行 | Checkpoint / Rewind | 変更前の自動保存、Esc×2で即座に巻き戻し |
| 思考制御 | Effort Controls | タスク複雑度に応じた処理レベル制御 |
月額$200（約3万円）のMAXプランで、Code Review（Teams/Enterprise専用）を除くほぼ全機能にアクセスできる。従来の開発体制なら月105〜310万円が必要だったコストだ。
ただし、機能の数が成果を保証するわけではない。この半年でも機能は次々に増えたが、増えた機能の大半は私の運用を変えていない。変わったのは、運用設計に組み込めた数個の機能だけだ。
PMが成果を出す「運用設計」の実践
ここからは、私が実際に使い込んで成果を出した機能の運用設計を解説する。机上の空論ではなく、商用プロジェクトで検証済みの手法だ。
CLAUDE.md——プロジェクトの「憲法」を書く
CLAUDE.mdは、プロジェクトルートに置く設定ファイルだ。ここに書いた内容が、Claude Codeの全セッションに読み込まれる。
PMとしての運用設計ポイント:
CLAUDE.mdを「機能説明」で終わらせてはいけない。PMが書くべきは運用ルールだ。
# NG: 機能説明
「TypeScriptを使っています」
# OK: 運用ルール
「TypeScript strictモード。any型は禁止。
APIレスポンスは必ずApiResponse<T>型を使用。
テストカバレッジ80%未満のPRはマージ禁止」
私のCLAUDE.mdには、技術スタック、セキュリティ規約（tenantIdフィルタ必須、PII暗号化必須、ソフトデリートのみ）、テスト規約、Agent Teamsの運用ルールまで定義している。これは「AIへの指示書」ではなく「プロジェクトの憲法」だ。人間の新メンバーが入ったときにも同じ資料を渡せる。
特に効果が大きかったのはセキュリティ規約の明文化だ。「全DBクエリにtenantIdフィルタ必須」「PIIはencryptPII()で暗号化」「hard delete禁止」——これをCLAUDE.mdに書いておくだけで、AIが書くコードにもセキュリティ基準が自動的に反映される。
ただし、CLAUDE.mdには「肥大化の罠」がある。
公式ドキュメントによれば、CLAUDE.mdは200行以下が推奨だ。40,000文字を超えるとClaude Codeが警告を出す。Claude Codeの組み込みシステムプロンプトには既に約50の指示が含まれており、フロンティアLLMが確実に従える指示数は合計150〜200個が限界とされる。つまり、CLAUDE.mdで使える「指示枠」は100〜150個程度しかない。
肥大化したCLAUDE.mdは、Claudeに指示を無視させる原因になる。 皮肉なことに、丁寧に書けば書くほど遵守率が下がる。
公式が推奨するセルフチェックはシンプルだ。「この行を削除したら、Claudeが間違えるか？」——そうでなければ削除する。
CLAUDE.mdが200行を超えたら、.claude/rules/ にトピック別ファイルとして分割すべきだ。たとえば rules/security.md、rules/testing.md、rules/code-style.md のように分ける。パス固有ルール（frontmatterの paths フィールド）を使えば、特定のファイルタイプを編集するときだけ該当ルールを読み込ませることもできる。
正直に言えば、私自身のCLAUDE.mdも現時点で推奨の3倍以上ある。これは改善すべき課題だ。
Hooks——「壊してはいけないもの」を自動で守る
Hooksは、ツール実行時に自動でシェルスクリプトを走らせる仕組みだ。PMにとって、これはガードレールだ。
私が設定しているHooks:
| Hook | タイミング | 効果 |
|---|---|---|
protect-main.sh | git commit/push前 | mainブランチへの直接commit/pushを自動ブロック |
session-verify.sh | セッション終了時 | 未コミット変更がある場合に警告 |
先日、クライアントのプロジェクトで旧版コードファイルを使ってデグレードが発生するインシデントがあった。Git未使用の環境で、担当者がローカルの旧ファイルを最新と思い込んで使用した結果だ。
Hooksを導入していれば、少なくともmainへの直接pushは防げた。人間のチェックリストだけでは漏れる。自動化できる安全策は自動化すべきだ。
Custom Slash Commands——「属人化しない仕組み」を作る
Custom Slash Commandsは、.claude/commands/ にMarkdownファイルを置くだけで独自のコマンドを定義できる機能だ。
開発プロジェクトで運用する場合、開発パイプラインをそのままコマンドに落とし込むのが最も効果的だ。
| コマンド | 用途 |
|---|---|
/spec | 仕様確認・要件定義・QA突合 |
/dev | Issue作成・実装・Git操作 |
/review | PRレビュー・ファクトチェック・マージ |
/docs | ドキュメント更新・設計書管理 |
/test | テスト実行・E2Eデバッグ |
/audit | セキュリティ監査・デプロイ前チェック |
/deploy | デプロイ・リリースノート生成 |
この7つのコマンドを組み合わせれば、開発のあらゆるフローがカバーできる。
バグ修正: /spec → /dev → /test → /review
仕様突合: /spec → /docs
デプロイ: /audit → /deploy
PMとしての運用設計ポイント:
公式ドキュメントでは1スキル=1目的、スキルあたり500行以下、全スキルのdescription総量がコンテキストの2%以内が推奨されている。スキルの数に明確な上限はないが、1つのスキルに複数の目的を詰め込みすぎると、Claudeの判断精度が下がる。
コマンドに品質基準を埋め込むことが核心だ。実例を2つ挙げる。
/review コマンドには100点満点の評価基準を埋め込んでいる。コード品質（30点）、設計（25点）、セキュリティ（25点）、ドキュメント（20点）の4軸でスコアリングし、85点以上でマージ可、69点以下はマージ拒否。さらに「tenantIdフィルタ漏れは即D評価」のような過去の教訓も組み込んである。
/audit コマンドにはデプロイ前の6項目チェックを定義している。typecheck、lint、テスト実行、セキュリティ簡易チェック、環境変数チェック、DBマイグレーション状態——これを手動で毎回やると漏れる。コマンドに埋め込めば、/audit pre-deploy の一言で全項目が走る。
誰が実行しても——AIエージェントが実行しても——同じ品質基準が適用される。 これがナレッジの属人化を防ぐ仕組みだ。
Agent Teams——複数Issueを安全に並行開発する
Agent Teamsは、複数のAIエージェントを同時に走らせる機能だ。PMにとっての最大の価値は複数Issueの並行開発だ。
たとえば、5つのGitHub Issueが承認済みで、3つは独立、2つは同じファイルを触る。人間なら「1つずつ片付ける」か「ブランチを切って並行する」。Agent Teamsなら、ファイル競合を設計した上で、複数Workerに分割して同時実行できる。
並行開発の設計フロー:
1. /dev parallel #12 #13 #14 #15 #16 ← 対象Issueを指定
2. ファイル競合マップを作成 ← 各IssueがどのファイルをDiffするか可視化
3. Worker分割 ← 同一ファイルを触るIssueは同じWorkerに
4. Wave設計 ← 競合なしのWorkerを先にマージ
5. Agent × N 並行起動 ← 各Worker = 1ブランチ = 1PR
6. マージ → 次のWave
PMとして重要な設計判断が3つある:
- ファイル競合マップ: 同じファイルを触るIssueは必ず同じWorkerに入れる。
schema.prismaのようなDB定義は単独Workerか最終Waveに配置する - Workerの分離: 各Workerは
isolation: worktreeで起動する。独立したgit worktreeで作業するため、互いのコードを汚染しない。1 Worker = 1ブランチ = 1 PR - Wave順序: 変更が少ないPRから先にマージする。マージ後に次のWaveで共通ファイル（i18n、ルーター定義等）を整理する
誤コミット・混信への対応も設計しておく。 間違ったブランチにコミットした場合は即座に作業を停止し、git revert で取り消す（--force は禁止）。判断に迷う場合は必ず人間に確認する。
これは、人間のチームマネジメントとまったく同じ原則だ。役割を明確に分離し、競合を設計段階で排除する。
MCP——AIの「手足」を業務システムに伸ばす
MCPは、Claude Codeを外部システムに接続するオープンプロトコルだ。
私はセミナーで、MCPサーバーを使ったドキュメント管理の自動化をデモした。「部品の調達先を変更する」という一言の指示から、4部署・16箇所のドキュメントへの影響分析とレポート生成までが自動で流れた。従来2〜3時間の作業が約1分に短縮された。
PMにとってのMCPの価値:
MCPの本質は「AIに手足を与える」ことだ。ドキュメント検索、データベース参照、APIコール——AIが外部の情報源にアクセスできるようになることで、PMの「確認作業」が劇的に減る。
ただし、MCPは万能ではない。セキュリティ設計（どのデータにアクセスさせるか）と権限管理（書き込みを許可するか）は、PM側で慎重に設計する必要がある。
2026年6月の新機能——PMはどう向き合うか
3月から6月までの3ヶ月で、Claude Codeの機能はさらに増えた。ここで大事なのは、全部を追わないことだ。新機能は「使えるか」ではなく「自分の運用課題を解決するか」で取捨選択する。
新機能が出るたびに全部試す。週末にリリースノートを読み込み、平日に片っ端から触る。でも月末に振り返ると、運用に残った機能は1つもない。
まず、3月時点で「展望」として挙げた機能のその後を一言で整理する。
- Voice Mode: 一般提供に。私はPCに座るのは1日2〜3時間で残りはスマホなので、音声指示は要件定義やIssue起こしの摩擦を確実に減らした。価値は「タイピング不要」ではなく思考からアウトプットまでの摩擦を減らすことにある
- /loop: デプロイ後の死活監視やAgent Teamsの進捗確認など、PMが手動でやっていた「確認」の自動化に定着した
- Channels: Slack・GitHub Webhook・CI/CDのイベントをセッションに流し込む連携。能動的に動くAIの土台だが、実運用の安定性はまだ見極め中
次に、新しく本格運用に入った／注目している機能を順に見ていく。Code Reviewは個人PMにとって判断が分かれるので、最初に詳しく扱う。
Code Review——GitHub上のマネージドサービスと自作スキルの違い
まず前提を明確にする。Claude Code ReviewはCLI機能ではない。 GitHub PR上で動くマネージドサービスであり、Teams/Enterpriseプラン専用だ。MAXプラン（個人向け$200/月）では使えない。
仕組みはこうだ。GitHub Appをインストールし、対象リポジトリを選ぶ。PR作成時・push毎・@claude review コメントのいずれかでレビューが走る。複数の専門エージェントがAnthropicインフラ上で並列に差分を分析し、信頼度スコア80以上の指摘だけをPRにインラインコメントとして投稿する。1回あたり$15〜25で、プラン使用量とは別課金だ。
公式が示す実績データ:
| 指標 | 導入前 | 導入後 |
|---|---|---|
| 実質的レビューコメントが付くPR | 16% | 54% |
| 大規模PR（1,000行超）の検出率 | — | 84%（平均7.5件の指摘） |
| 誤検出率 | — | 1%未満 |
| 平均レビュー時間 | 数時間〜数日 | 約20分 |
では、個人PMはどうするか？
私はMAXプランで運用しているため、公式Code Reviewは使えない。代わりにCustom Commandsで /review スキルを自作し、100点満点の採点基準でPRレビューを回している。
| 観点 | 公式 Code Review | 自作 /review スキル |
|---|---|---|
| 対象プラン | Teams/Enterprise | 全プラン（MAXでもOK） |
| 実行場所 | GitHub PR上（Anthropicインフラ） | Claude Codeセッション内（ローカル） |
| トリガー | PR作成/push/コメント | /review #PR番号 で手動実行 |
| カスタマイズ | REVIEW.mdで指示追加 | コマンド内に自由に定義 |
| 評価基準 | バグ・セキュリティ中心 | プロジェクト固有の採点（100点満点） |
| 過去の教訓 | gitヒストリーから自動学習 | コマンドに明示的に埋め込む |
| コスト | $15〜25/回（別課金） | セッション内のトークン消費のみ |
| 判定 | 指摘のみ（承認/拒否なし） | スコアでマージ可否を判定 |
深夜2時に1人でコードレビュー中、Claude Codeにセキュリティチェックを依頼したら、3時間見落としていたセキュリティホールを5分で発見された——この体験がきっかけで /review スキルを作った。公式Code Reviewが使えなくても、Custom Commandsで同等のレビュー体制は構築できる。
Teams/Enterpriseプランなら両方使うのがベストだ。 自作 /review でプロジェクト固有の品質ゲート（tenantId漏れ即D評価、横展開チェック等）を担保し、公式Code Reviewでロジックエラーやリグレッションを補完する。CLAUDE.mdに書いた規約は公式Code Reviewにも反映されるため、運用設計の投資が二重に効く。
Dynamic Workflows——「体制設計」をAIに任せる
Dynamic Workflowsは、Claudeが自分でオーケストレーションスクリプトを動的生成し、最大1,000のサブエージェントを並列実行できる機能だ。Agent Teamsが「人間が分割した複数Issueを並行処理する」のに対し、Dynamic Workflowsは分割の仕方そのものをAIが設計する点が違う。
PM視点のポイント: これはPMの「体制設計」と同じ構造だ。コードベース全体の横断調査、数十ファイルにまたがる一括リファクタ、大量の候補から有望案を絞り込む探索——こうした「広く並列に当てる」タスクで効く。
ただし、サブエージェントを1,000個動かせることは、1,000個動かすべきという意味ではない。並列数は成果ではなくコストだ。 私の運用では、まず「この作業は本当に並列に分解できるか」を判断し、分解できるものだけをWorkflowに載せる。判断の主体はあくまで人間に残す——任せる範囲は広がるが、判断は残るという原則は、ここでも変わらない。
Claude Routines——「確認」を定期実行で自走させる
Claude Routinesは、スケジュールを設定してタスクを定期的に自動実行する機能だ。/loop がセッション内の軽量ループなら、Routinesはセッションをまたいで走り続ける常駐タスクにあたる。
PM視点のポイント: 私はこれを「朝のブリーフィング」「停滞案件の洗い出し」「定期レポートの下書き生成」に組み込んでいる。PMの仕事には「毎朝・毎週、同じ確認を繰り返す」定型業務が必ずある。そこをRoutinesに渡すと、人間は判断が必要な例外だけを見ればよくなる。
注意点は、定期実行は「動いていること自体を忘れる」ことだ。出力先と失敗時の通知を必ず設計し、誤った前提のまま走り続けないようにする。
Fable 5 / 1Mトークン——モデルを「使い分ける」
2026年6月、新モデル Fable 5 がClaude Code内で選択できるようになった。さらにOpus 4.8では1Mトークン（日本語でおよそ50〜80万字）のコンテキストを扱える。
PM視点のポイント: モデルが増えると「どれが最強か」を探したくなるが、それは消耗の入り口だ。PMが設計すべきは使い分けのルールである。私の運用はシンプルだ——大規模な設計判断や横断調査は1Mコンテキストのモデルに任せ、定型処理や軽い修正は軽量モデルに回す。プロジェクト全体を一度に読み込ませて整合性を確認できるのは、1Mコンテキストの実務的な威力だ。
重要なのは、モデルが賢くなるほど「何を任せ、何を自分で判断するか」を決める仕事が重くなることだ。 スペック競争を眺めるより、自分の運用に合うモデルの当て方を決める方が、はるかに成果に直結する。
機能を追うな、運用を設計せよ——3つの原則
ここまで読んで気づいたかもしれないが、成果を出している機能はすべて運用設計が先にある。機能を知った「後」に使い方を考えるのではなく、運用課題が「先」にあり、機能はそれを解決する手段だ。
原則1: CLAUDE.mdから始める
新しい機能を試す前に、まずCLAUDE.mdを書く。プロジェクトのルール、品質基準、ファイル構造を明文化する。これが全機能の土台になる。CLAUDE.mdなしにAgent Teamsを動かしても、バラバラの品質のコードが量産されるだけだ。
原則2: 安全策を先に自動化する
Hooksで「やってはいけないこと」を自動で防ぐ。mainブランチへの直接pushブロック、未コミット変更の警告——人間のチェックリストより自動化の方が確実だ。
原則3: 品質基準をコマンドに埋め込む
Custom Commandsに品質基準を組み込めば、誰が（AIが）実行しても一定の品質が担保される。属人化を防ぎ、スケーラブルな体制を作れる。
まとめ——今日から始める最初の一歩
Claude Codeは強力なツールだ。だが、ツールの性能ではなく、PMの「指示力」と「運用設計」が成果を決める。 これは169万メッセージを回してきた実感だ。
今日から始めるなら、この順序だ:
- CLAUDE.mdを書く — プロジェクトの技術スタック、コーディング規約、品質基準を定義する
- Hooksを設定する — mainブランチ保護を最低限入れる
- Custom Commandを1つ作る — 自分が一番繰り返している作業をコマンド化する
新機能を追いかけるのは、この3つが揃ってからでいい。
PMBOK-AIフレームワークの核心は「AIは優秀なツールだが、判断の主体にはなれない」ことだ。Claude Codeも例外ではない。機能の使い方を覚えるのではなく、プロジェクト全体の中でAIをどう位置づけるか——それを設計するのがPMの仕事だ。