Claude Codeをチーム導入する前に作る「リスク台帳」の中身

金曜の夕方、同僚が「Claude Codeめっちゃ便利だから、来週からみんなで使おう」と言い出しました。

僕は嫌な予感がしました。彼が個人で使っていたときは、自分のブランチを自分でレビューして自分でマージしていた。事故っても被害は本人だけ。でもチームで使うとなると話が変わります。誰の許可で、どこまで触らせて、誰が変更を確認するのか。これが決まっていないまま6人で使い始めたら、本番DBを消す変更がいつの間にかマージされていた、なんてことが普通に起きます。

実際、別のチームでこれをやりました。3人がそれぞれ自分流の設定でClaude Codeを動かし、ひとりが「いい感じに整理して」と頼んだら、共有の設定ファイルが書き換わって、月曜の朝にデプロイが全部こけました。原因の特定に半日。誰も悪気はなかった。ただ「チームで任せるときのルール」がなかっただけです。

そこで作ったのが、この記事で紹介するリスク台帳です。台帳といっても表が一枚あるだけ。でもこれがあるかないかで、Claude Codeのチーム導入が「楽になった」で終わるか「事故処理で消耗する」で終わるかが変わります。

この記事の要点

• チーム導入の事故は、モデルの賢さではなく「誰が・どこまで・誰の確認で」が決まっていないことで起きる。
• リスク台帳は、危ない領域ごとに「担当・検証方法・次に進む条件」を1行で書いた表のこと。最初は3行で十分。
• 権限（どのファイルを触らせるか）、CI（変更が壊れていない証拠）、公開（本番反映の確認）の3つを最初に固める。
• Claude Codeに任せるのは「下書きと検証の実行」まで。削除・本番DB・課金・force pushは必ず人が承認する。
• コピペで動く台帳テンプレートと、危険な操作を弾く設定例を載せた。まず1ファイルだけで試すのがコツ。

リスク台帳って、結局なに？

リスク台帳は、Claude Codeにチームで仕事を任せるときの「事故りやすい場所」を一覧にした表です。

各行はたった3つの列で済みます。どこが危ないか、それが安全だと言える証拠は何か、誰がその確認をするか。これだけ。難しい管理ツールはいりません。最初はスプレッドシート1枚、なんならコードの中の配列で十分です。

なぜ表にするかというと、「なんとなく気をつける」が一番危ないからです。人は忙しいと必ず確認を飛ばします。表にして「この行が埋まるまでマージしない」と決めておけば、忙しい金曜の夕方でも事故が止まります。冒頭のデプロイ事故も、共有設定ファイルを「触ってはいけない領域」として1行書いておくだけで防げました。

最初に固める3つの危険ポイント

チーム導入でこける場所は、だいたい次の3つに集約されます。逆に言うと、ここさえ台帳に書いておけば、初日の大事故はほぼ防げます。

1. 権限（どのファイルを触らせるか）

一番多い事故が「触らせすぎ」です。「リポジトリを整理して」と頼むと、Claude Codeは設定ファイルもCIの定義も平気で書き換えます。だから、編集していい場所と絶対に触らせない場所を先に決めて文字で残します。

僕の基準はシンプルです。記事や下書き、テストコードは触ってOK。.github/、本番の環境変数、デプロイ設定、データベースのマイグレーションは「人が確認するまで止める」。この線引きを各自の好みに任せると、人によってルールがバラバラになって、結局一番ゆるい人の設定が事故を起こします。チームで1つに揃えるのが肝心です。

2. CI（壊れていない証拠を出させる）

Claude Codeが「直しました」と言っても、それは感想です。証拠ではありません。だから、変更が壊れていない証拠を出すコマンドを台帳に書いておきます。ビルドが通る、テストが緑になる、型エラーがない。このどれかを「成功報告の前に必ず実行する」と決めます。

ここで大事なのは、検証コマンドを速くしておくこと。フルテストに10分かかると誰も回さなくなります。変更したファイルに関係するテストだけを30秒で回せるようにしておくと、確認が習慣になります。

3. 公開（本番に出る変更を必ず見る）

ブログの収益ページでもAPIでも、外に出る変更は「本物のURLで見たか」を残します。ビルドが通ったことと、実際にユーザーが見るページが正しいことは別問題です。本番のURLを開いてスクリーンショットを1枚残す。これを完了の条件にします。

公開URLが200を返しても、中身が別ページなら未公開と同じです。日本語ページなのに英語の本文が混ざっていたら、それも未完成です。当たり前に見えて、急いでいる日ほどここを飛ばします。

AIに任せる範囲と、人が決める範囲

線引きで迷ったら、この表をそのまま使ってください。「戻せるかどうか」が判断軸です。

操作	Claude Codeに任せる	人が承認してから実行
下書きの作成・修正	◯
テスト・ビルドの実行	◯
変更内容の説明（差分の要約）	◯
ファイルの削除		◯
本番データベースへの書き込み		◯
課金が発生する操作		◯
force push・履歴の書き換え		◯
デプロイ・本番公開		◯

ルールはひとつ。戻すのが大変な操作は、最初は全部「人に聞く」にする。安全だと分かった操作だけ、あとから自動に格上げします。最初からゆるくして事故るより、きつくして少しずつ緩めるほうが、結果的に速いです。

コピペで使えるリスク台帳テンプレート

まずは依頼の前に、Claude Codeへ渡す指示文をテンプレ化します。これを毎回貼るだけで、勝手な拡大を防げます。

作業前に次を守ってください。
- 編集してよいのは src/content/ と tests/ の中だけ。
- .github/、本番環境変数、デプロイ設定、DBマイグレーションは触らない。触る必要があれば、編集せずに理由を報告する。
- 変更後は必ず `npm run check` を実行し、結果を報告する。
- 削除・本番DB・課金・force pushが必要になったら、実行せず確認を求める。
編集前に、上の制約を自分の言葉で言い直してから作業を始めてください。

そして台帳そのもの。最初は3行で十分です。自分のチームの危険ポイントに置き換えてください。

// チーム導入リスク台帳: 危険ポイントごとに「担当・証拠・次に進む条件」を1行で書く
type RolloutRisk = {
  area: string;       // 危ない領域
  risk: string;       // 何が起きうるか
  owner: string;      // 確認する担当
  proof: string;      // 安全だと言える証拠
  nextGate: string;   // 次に進んでよい条件
};

const rolloutRisks: RolloutRisk[] = [
  {
    area: "権限",
    risk: "Claude Codeが共有設定まで書き換える",
    owner: "リード",
    proof: "編集可・編集禁止の一覧が文書化されている",
    nextGate: "まず1ファイルだけで試す",
  },
  {
    area: "CI",
    risk: "検証コマンドが遅い、または存在しない",
    owner: "開発担当",
    proof: "ビルドが緑、または関係テストだけ緑",
    nextGate: "PRテンプレートに検証手順を入れる",
  },
  {
    area: "公開",
    risk: "本番に出る変更を実物で確認していない",
    owner: "運用担当",
    proof: "公開URLのスクリーンショット",
    nextGate: "戻し手順をメモに残す",
  },
];

console.table(rolloutRisks);

nodeで動くように保存して実行すれば、表が出力されます。派手ではありませんが、価値は「作業を始める前に危険ポイントを言葉にできる」ことです。各行が埋まるまでマージしない、というルールにすれば、台帳が事故の門番になります。

こんなチームで効く（3つの実例）

近い状況があれば、台帳を作り直さず名前だけ置き換えて使ってください。

1. 2人の小さなチーム 共有コードを触る前に、編集してよい場所・触ってはいけない場所・人の承認が必要な操作を3人で読み合わせて1枚にします。これだけで「片方が知らないうちに設定を壊す」事故が消えます。小さいチームほど「言わなくても分かるだろう」で事故るので、最初に文字にする価値が大きいです。

2. レビューを通すチーム リードは、Claude Codeが作った変更がレビューに回る前に「検証コマンドを実行した結果」と「変更点の要約」を必須にします。これがないPRは見ない、と決める。レビュアーが差分を読んで、検証を再実行して、戻し方を説明できる状態まで持っていくのが目標です。

3. 収益ページを持つチーム ブログや商品ページなど、お金に直結するページの変更は、完了扱いにする前に公開URLのスクリーンショットを残します。「ビルド通った」で終わらせず、ユーザーが実際に見る画面を確認する。タイトル・本文・画像・導線が想定どおりかを目で見ます。

よくある失敗と、その直し方

正直に書くと、この台帳も最初はうまく回りませんでした。やらかしを3つ共有します。

各自が独自ルールを作った 最初、設定を個人任せにしたら、人によって編集可能な範囲がバラバラになりました。一番ゆるい設定の人が事故を起こします。直し方は単純で、編集可・禁止の一覧をチームで1つに統一して、リポジトリに置きました。

CIの失敗を後回しにした 「あとでまとめて直す」が口癖になると、最初のチーム導入が「Claude Code入れたら壊れる」という悪い印象で終わります。検証コマンドが落ちたら、その場で止めて、緑になるまでドラフト扱いにするルールにしました。

担当を曖昧にしたまま難しい判断を避けた 「誰が承認するか」を決めずにいると、一番難しい本番反映の判断が宙に浮きます。台帳のowner列を必ず埋める。空欄のまま進めない。これだけで、判断が止まらなくなりました。

作業が広がり始めたと感じたら、依頼文全体を書き直すのではなく、触れる範囲を狭める・検証を先に出す・確認の担当を1人決めるの順で締めます。失敗をチーム内に共有として残すのも大事です。成功例だけ見ていると、自分が危ない状態に入っていることに気づけません。

よくある質問

Q. 小さなチームでも台帳は必要ですか？ 2人でも必要です。むしろ少人数ほど「言わなくても分かる」と思い込んで事故ります。最初は3行のテンプレートで十分なので、5分で作って共有してください。

Q. Claude Codeの権限設定だけで足りませんか？ 権限設定は「触らせない仕組み」で、台帳は「誰が何で確認するか」の運用ルールです。両方いります。設定で技術的に止め、台帳で人の確認を回す。詳しくは権限設定ガイドを見てください。

Q. 検証コマンドは何を選べばいいですか？ そのチームで「壊れていない」と言える最短のコマンドです。型チェック、関係テストだけの実行、ビルドのどれか。フルテストで10分かかるなら誰も回さないので、まず30秒で終わるものを1つ決めます。

Q. エンジニアじゃないメンバーがいても回りますか？ 回ります。台帳は表を読んで埋めるだけなので、コードが読めなくても運用できます。非エンジニア向けの始め方は非エンジニア向けの使い方が参考になります。

Q. プロジェクト固有のルールはどこに書けばいいですか？ リポジトリのCLAUDE.mdに書くと、Claude Codeが毎回読んでくれます。編集禁止の領域や検証コマンドをここに集約すると台帳と一致させやすいです。書き方はCLAUDE.mdの書き方にまとめています。Anthropic公式のClaude Code documentationも一次情報として確認してください。

実際に試した結果

冒頭のデプロイ事故のあと、僕は「Claude Codeを信じるか」で悩むのをやめました。代わりに見るのは、台帳のどの行が埋まっていないか、です。

実際に3行の台帳を導入して、共有設定ファイルを「触ってはいけない領域」として明文化したら、設定を壊すマージはゼロになりました。検証コマンドを「成功報告の前に必須」にしたら、レビューで初めて壊れに気づくことがなくなり、差し戻しが目に見えて減りました。公開ページにスクリーンショットの確認を入れてからは、「ビルドは通ったのに別ページが出ていた」という見落としも止まりました。

確かめたのはこの3点だけです。賢いエージェントを探すより、転んでも戻せる運用を先に作る。遠回りに見えて、チーム導入ではこれが一番速い、というのが今の実感です。

会社でClaude Codeの導入を本格的に進めたい、運用ルールを一緒に設計したい、という段階なら、研修・相談で具体的な手順まで一緒に組み立てられます。まずは自分のチームの危険ポイントを3行、書き出すところから始めてください。