Claude Codeチーム引き継ぎルール: レビュー、権限、収益導線まで渡す実務手順

なぜチーム引き継ぎが必要なのか

Claude Codeを個人で使うだけなら、多少メモが雑でも自分の記憶で補えます。ところがチームで使い始めると、AIが作った差分そのものよりも、「誰が何を確認し、どこまで権限を与え、何を守ったのか」が品質を左右します。

特に記事、LP、教材、問い合わせ導線を扱うチームでは、コードがビルドできるだけでは不十分です。公開URLが正しく見えるか、CTAが壊れていないか、無料PDFの登録、Gumroadの購入導線、導入相談フォームまで通っているかを、レビュー担当者が短時間で追える状態にする必要があります。

この引き継ぎルールの目的は、長い作業日誌を残すことではありません。変更内容、証拠、権限判断、ロールバック方法、収益導線の確認結果を1枚にまとめ、次の担当者が迷わずレビューできるようにすることです。

あわせて読むと流れがつながります: セッション引き継ぎテンプレート、Permission Budget Loop、レビュー運用チェックリスト。Claude Code自体の基本機能を確認したい場合は、Claude Code公式ドキュメントも参照してください。

チーム引き継ぎの失敗例

一番多い失敗は、「作業ログだけを渡す」ことです。たとえば「本文を増やしました」「リンクを直しました」「buildしました」とだけ書かれていても、レビュー担当者は何を信じればよいか分かりません。必要なのは作業の経緯ではなく、確認済みの証拠です。

次に危ないのが、承認ルールを口頭で済ませる運用です。「今回は軽い修正だから大丈夫」と思っているうちに、価格表示、CTA、問い合わせフォーム、デプロイ設定のような重要箇所までAIに触らせてしまいます。権限の線引きが文章化されていないと、レビューで止めるべき差分が通ります。

3つ目は、ロールバック担当を決めないことです。AIが生成した差分が本番で崩れたとき、誰が戻すのか、どのコミットに戻すのか、どの導線を優先して復旧するのかが曖昧だと、復旧よりも責任確認に時間がかかります。

4つ目は、収益導線を「あとで誰かが見る」扱いにすることです。記事が公開されても、無料PDFの登録リンクが別言語に飛ぶ、Gumroadの商品リンクが古い、相談フォームが入力途中で落ちる、という状態では公開の成果が消えます。Claude Codeの作業レビューでは、読者の次の行動まで確認対象に含めるべきです。

Masaの運用でも、薄い記事を増やしただけではAdSenseや教材導線に効かないことがありました。そこで本文品質だけでなく、証拠、CTA、教材、相談導線まで引き継ぎに含めるようにしたところ、レビューコメントが「どこを見ればよいか分からない」から「このURLとこのフォームだけ見れば判断できる」に変わりました。

レビューに渡すべき証拠

レビュー担当者に渡す証拠は、スクリーンショットを貼れば終わりではありません。最小セットは、変更目的、対象ファイル、実行した検証コマンド、公開またはプレビューURL、差分の要約、守るべきリンク、権限判断、ロールバック方法です。

記事改善なら、本文文字数、h2の数、内部リンク、外部リンク、コードブロック、OGP画像、翻訳品質を見ます。LP改善なら、モバイル幅、フォーム送信、購入ボタン、価格表示、canonical、計測タグを見ます。開発タスクなら、テスト結果、型チェック、影響範囲、既知の未対応事項を渡します。

レビューに渡す証拠は、次のように短くても構いません。大事なのは、レビュー担当者が同じ順番で再確認できることです。

npm run build
node scripts/check-updated-article-quality.mjs

この2行だけでも、実行した事実、失敗した場合の再現方法、品質ゲートの対象が残ります。実行できなかった場合は「未実行」と書くのではなく、「依存関係が未インストール」「ローカルではAPIキーがない」「CIで確認予定」のように理由と次の確認場所を書きます。

証拠はレビュー担当者を安心させるための飾りではありません。レビューの範囲を狭め、判断を早くし、問題が出たときに戻る場所を作るための材料です。

コピペで使える最小セット

まずはこのMarkdownをチームのPRコメント、Issue、Slack、Notionに貼ります。Claude Codeに作業させたあと、空欄を埋めてからレビューに渡すだけで、会話の抜けが減ります。

# Claude Code team handoff

## Change made
- 

## Proof
- build:
- public URL:
- screenshot:

## Revenue path checked
- free PDF:
- Gumroad:
- consultation:

## Next owner
- reviewer:
- decision needed:
- do not touch:

権限ルールはJSONで残しておくと、Claude Codeに「どこまで触ってよいか」を渡しやすくなります。ここでのsafeは通常の検索や小さな文言修正、review_requiredは人間の確認が必要な変更、blockedは依頼してはいけない変更です。

{
  "approval_rules": {
    "safe": ["read files", "search", "small copy edit"],
    "review_required": ["pricing", "CTA links", "deployment"],
    "blocked": ["secrets", "force push", "delete customer data"]
  }
}

レビュー担当者に渡すプロンプトも固定します。レビュー範囲が広すぎると、AI作業の良し悪しではなく、記事全体の好みや過去の設計議論に話が広がります。

You are receiving a Claude Code handoff.
Check the proof first.
Then review only:
1. whether the stated goal was met
2. whether protected links still work
3. whether the next owner has one clear action

権限、ロールバック、収益導線の引き継ぎテンプレ

チーム運用では、権限とロールバックと収益導線を同じテンプレートに入れます。理由は単純で、事故が起きるときはこの3つが同時に抜けるからです。誰が承認したのか、どこまで戻せるのか、売上につながるリンクが生きているのかを、別々の場所に散らさないでください。

handoff:
  owner: "Masa"
  reviewer: "team-reviewer"
  permission:
    safe:
      - "copy edit inside the article body"
      - "run local quality checks"
    needs_review:
      - "price copy"
      - "CTA destination"
      - "deployment setting"
    blocked:
      - "secrets"
      - "customer data"
      - "force push"
  rollback:
    restore_point: "commit or branch before Claude Code work"
    command: "git revert <commit>"
    priority_path:
      - "public article page"
      - "free PDF signup"
      - "Gumroad purchase"
      - "consultation form"
  revenue:
    free_pdf: "checked"
    gumroad: "checked"
    consultation: "checked"

このテンプレートは厳密な監査書類ではなく、レビューの開始地点です。小さな記事修正なら5分で埋められます。価格、購入、問い合わせ、顧客データに触る変更なら、ここを埋める前に作業を始めないほうが安全です。

3つ以上の実例とユースケース

1つ目は記事公開です。ライターがClaude Codeで本文を増強し、エンジニアが品質チェック、公開URL、内部リンク、無料PDFの登録ボタンを確認します。レビュー担当者は文章の好みではなく、品質ゲートと収益導線に絞って判断できます。

2つ目は商品ページの文言修正です。PMがGumroad教材の説明を変えたいとき、Claude Codeにコピー案を作らせることはできます。ただし価格、返金条件、購入リンクはreview_requiredに入れ、人間が最終確認します。これで「読みやすいけれど売るものが違う」事故を防げます。

3つ目は導入相談ページの改善です。フォーム文言、対象者、相談内容の説明を直すとき、Claude Codeは文章整理に強い一方で、フォーム送信やサンクスページ遷移の確認までは自動で保証しません。引き継ぎにスクリーンショットと送信確認を入れることで、レビュー担当者は実際の問い合わせ導線を見られます。

4つ目は権限ルールの更新です。チームリードが「検索と読み取りはsafe、価格変更とデプロイはreview_required、secretsと顧客データ削除はblocked」と決めたら、そのJSONをClaude Codeの作業前プロンプトに含めます。ルールを毎回口で説明するより、差分として残したほうがレビューしやすくなります。

レビュー担当者の読み方

レビュー担当者は、まず差分ではなく証拠から見ます。buildが通っているか、品質チェックが通っているか、公開URLで表示が崩れていないか、CTAが正しい場所に飛ぶかを先に確認します。証拠がない場合、本文を読んでから戻るのではなく、証拠不足として差し戻します。

次に権限を見ます。safeの範囲だけなら通常レビューで進めます。review_requiredに入る価格、CTA、デプロイ、問い合わせ導線が触られているなら、該当オーナーの確認を待ちます。blockedに該当する変更があれば、内容が良くてもマージしません。

最後にロールバックを見ます。戻し方が書かれていない変更は、運用上は未完成です。記事本文だけなら前コミットに戻せば済みますが、商品ページ、フォーム、計測、課金に触る場合は戻す順番が重要です。売上や問い合わせに直結する導線を先に戻す、という優先順位まで書いておくと現場で迷いません。

教材と相談への自然な導線

個人で始めるなら、まず無料Claude Codeチートシートで基本コマンドと安全な進め方を確認すると十分です。毎回同じ説明を書くのがつらくなったら、50個のClaude Codeプロンプトテンプレートでレビュー、デバッグ、記事改善の型を増やせます。

チームで運用するなら、Claude Code Setup GuideでCLAUDE.md、権限、hooks、MCP、検証コマンドの置き場所をそろえるのが次の段階です。教材は「自分たちで運用を固められるチーム」に向いています。

一方で、誰が承認するのか、どの導線を守るのか、AdSenseやGumroadや相談フォームをどうつなげるのかが曖昧なら、導入相談で一度棚卸ししたほうが早いです。相談で決めるべきなのは、Claude Codeの使い方そのものより、チームの責任分界、レビュー証拠、収益導線の優先順位です。

教材と相談は競合しません。無料PDFで基本を押さえ、Gumroad教材で反復可能な型を増やし、チーム固有の権限や収益導線は相談で設計する。この順番にすると、読者にもチームにも無理のない導線になります。

この記事で紹介した内容を実際に試した結果

この記事では、Markdownの引き継ぎ、JSONの権限ルール、レビュー担当者向けプロンプト、権限/ロールバック/収益導線テンプレートを1つの流れにまとめました。実際の運用では、レビューコメントの大半が「何を確認すればよいか」ではなく「この証拠で足りるか」に変わります。Claude Codeの作業をチームで扱うなら、まず差分を増やすより、次の担当者が検証できる引き継ぎを残すことが効果的です。