記事

新人メンバーにClaude Codeを安全に使ってもらうオンボーディング

Claude Codeをチームに迎える新人メンバー向けの5日間オンボーディング設計。導入手順・最初の課題・やってはいけないこと・レビュー方法を、コピペで使える依頼文テンプレートとともに整理します。

Claude Codeを新人にいきなり「自由に使っていいよ」と渡すと、.envを読ませる・git push --forceを承認する・依存を勝手に増やすといった事故が起きがちです。一方で「使うな」と禁止すると生産性の差が開いていきます。本記事では、新人メンバーが5日間で安全に独り立ちするためのオンボーディング手順を整理します。チーム導入そのもののルール作りは「チームでClaude Codeを導入するときに最初に決めるルール」で扱っています。

結論：5日間で「読む→計画→実装→PR→レビュー対応」まで通す

新人オンボーディングは、AI機能の高度な使い方を全部教えるのではなく、安全な最小ループを1周回すことを目標にします。

日	目標	アウトプット
1日目	環境構築・認証・動作確認	`claude doctor`がパスする
2日目	プロジェクトを「読ませる」	コードベースの要約を出させる
3日目	Plan Modeで小タスクを計画	計画レビューを通す
4日目	実装・テスト・コミット	1つのPRを出す
5日目	レビュー対応・振り返り	PRがマージされる

期間は目安です。経験者なら3日、慎重派なら2週間でも構いません。重要なのは順序です。

1日目：環境構築と動作確認

やること

OS要件確認（macOS 13以上 / Windows 10 1809以上 / Ubuntu 20.04以上 / Debian 10以上 / Alpine 3.19以上）
インストール（macOSはHomebrew、WindowsはWinGet＋Git for Windows、WSLはネイティブインストーラー）
認証（チームの選択：Pro/Max個人アカウント・Claude for Teams・Console APIキー・クラウドプロバイダーのいずれか）
動作確認：

claude doctor

claude --version

リポジトリをクローンして.claude/settings.jsonが読み込まれることを確認

やってはいけないこと

npm install -g @anthropic-ai/claude-codeをsudoで実行する（権限エラーの温床）
個人のANTHROPIC_API_KEYを環境変数に置く（チームの認証ソースと干渉）
bypassPermissionsを試しに有効化する

詳しい手順はOS別に「macOSでClaude Codeをインストールする手順と初期設定」と「WindowsでClaude Codeを使う方法：WSL導入から動作確認まで」で扱っています。

2日目：プロジェクトを「読ませる」

新人がコードに手を入れる前に、まずコードを読ませて要約させるステップを必ず入れます。AIに先に書かせる前に、AIの理解度をこちらが確認できるためです。

最初の依頼文テンプレート

依頼：このリポジトリの構成を要約してください。

## 観点
- どんなアプリか（1〜2文）
- 主要なディレクトリと役割
- ビルド・テスト・デプロイのコマンド
- 触ってはいけないファイル/ディレクトリ（@CLAUDE.md参照）

## 出力
- Markdown形式で200〜400字程度
- 推測した内容はその旨を明記

## 制約
- ファイルを編集しない
- 外部ネットワークにアクセスしない

新人はこの出力を読み、認識ずれを質問するメンターに渡します。AIの理解とメンターの想定が食い違うところが、CLAUDE.mdの不足箇所です。

`CLAUDE.md`の写経も同日にやる

CLAUDE.mdを新人自身が音読・要約して、不明点をメンターに質問するレビュー時間を取ります。書かれている禁止事項を新人自身の言葉で言い換えられるまで進めれば、3日目以降の依頼文の質が上がります。

3日目：Plan Modeで小タスクを計画

最初に実装させるタスクは、次の条件を満たすものを選びます。

1〜2ファイルで完結する
既存テストが通っている部分
30分〜2時間で終わる
失敗してもロールバックが容易（型変更・大規模リファクタは避ける）

新人はいきなり「実装してください」と書きがちです。Plan Modeで計画フェーズだけ走らせる練習をします。

claude --permission-mode plan

依頼文の最小テンプレ：

依頼：`/api/health`エンドポイントにレスポンスヘッダ`X-Build-Version`を追加する計画を立ててください。

## 制約
- まだ実装はしない（計画だけ）
- 既存のエンドポイントの返り値は変えない
- 追加するヘッダ値はビルド時環境変数 BUILD_VERSION から取る
- テストも追加する

## 出力
- 変更するファイル一覧
- 変更内容の要約
- テストの追加方針
- 想定リスク

メンターは計画を一緒にレビューします。レビュー観点は「Claude Codeに『計画してから実装』させるプロンプト例」で扱っている5項目（スコープ・依存追加・テスト・後方互換・秘密情報）です。

4日目：実装・テスト・コミット

計画が承認されたら、/permission-mode defaultに戻して実装に入ります。新人にはdiff確認の習慣を最優先で身に付けてもらいます。

git diff

git diff --stat

4日目に必ず教える3つの操作

Esc Escで直前のチェックポイントに戻る
/clearで別タスクに移る前にコンテキストを切る
git restore <file>で個別ファイルを戻す

最初の機能追加の通し手順は「Claude Codeで最初の小さな機能追加をする手順」を参照してください。

コミット時の3チェック

git diffを自分の目で読んだか
npm test npm run lint npx tsc --noEmitがすべて通るか
コミットメッセージにCo-Authored-By: Claudeを含めたか

5日目：PR・レビュー対応

PRは新人自身がgh pr createで出します。PR本文には次を必ず書きます。

やったこと（1〜3行）
AI生成行数の目安
動作確認方法（コマンドまたは手順）
レビュアーに見てほしい観点

レビューが返ってきたら、「全部AIに直させる」のではなく、内容を読み解いて自分の言葉で対応方針を返す練習をします。これを習慣化しないと、レビュアーが疲弊して指摘の質が落ちます。

やってはいけないことリスト（オンボーディング期間中）

以下は2週間程度の「養成期間」中は禁止にすることを推奨します。

bypassPermissionsの使用
acceptEditsモードの常用
git push --forceの承認
依存追加（npm install <new-pkg>／pip install等）の承認
本番DB・本番URLへの接続
自分以外のメンバーのブランチへのpush
サブエージェントの自作（消費トークン管理がまだ難しい）
MCPサーバーの追加（セキュリティ評価が難しい）

これらは「絶対だめ」ではなく、メンターと一緒なら可、独力では不可、という線引きにします。

メンター側の準備物

オンボーディングを受ける側だけでなく、メンター側も次を用意します。

準備物	中身
環境構築チェックリスト	OS別の手順を1ページにまとめる
`CLAUDE.md`の読み合わせ用ドキュメント	各セクションの背景・なぜそう書いてあるか
最初のタスク3件のリスト	難易度1〜3で用意。1件目は1ファイルで完結
PRレビューチェックリスト	AI生成コード固有の観点（過剰抽象化・無駄な防御コード）
1on1の時間	1週目は毎日15分、2週目は隔日30分が目安

オンボーディング完了の判定基準

「独り立ちした」と見なすための最小基準を決めておきます。

Plan Modeで計画を出し、レビューに耐える内容にできる
git diffを自分の目で読み、過剰変更を指摘できる
.claude/settings.jsonの権限ルールの意図を説明できる
PRレビューで返ってきた指摘に、自分の言葉で返答できる
失敗ログを依頼文に貼り直して、再依頼の依頼文を書ける

これらが揃ったら、メンターからの「全PR確認」を「依存追加・マイグレーション・本番系PRのみ確認」に切り替えていきます。

よくある失敗パターン

症状	原因	対処
1日目に挫折する	OS要件未満／Gitfor Windows未導入	環境構築チェックリストの事前送付
計画レビューで時間が溶ける	タスクが大きすぎる	1〜2ファイル・30分以内の課題に絞る
全部承認して進める	`default`モードの意図を理解していない	「ファイル編集は毎回承認」のデモを見せる
PRがレビュー不能サイズ	計画段階でスコープ過大	Plan Modeの計画レビューを必須化
依存追加で本番が落ちる	依存追加を独力で承認	期間中は依存追加の承認をメンター経由に

チェックリスト

1日目：環境構築・動作確認が完了
2日目：プロジェクト要約をメンターレビュー
3日目：Plan Modeで小タスク計画作成・レビュー
4日目：実装・テスト・diff確認・コミット
5日目：PR提出・レビュー対応・マージ
期間中の禁止事項リストを新人に共有した
メンターが1on1の時間を確保した
完了判定の5項目を満たした

次に読むおすすめ記事：

「チームでClaude Codeを導入するときに最初に決めるルール」：オンボーディングの前提となるチームルール
「Claude Codeで最初の小さな機能追加をする手順」：4日目に通す実装フロー
「Claude Codeに『計画してから実装』させるプロンプト例」：3日目のPlan Mode計画レビュー観点

管理人

編集者 / オーナー