コンテンツにスキップ

Claude Code 完全ガイド

Claude Code /team-onboarding 完全ガイド: 新メンバーの立ち上がりを最短化する使い方

対象 / ポイント

対象: Claude Code をチーム導入し始めた Tech Lead、EM、開発基盤担当。新メンバーの立ち上がりを標準化したい人。

ポイント:

  • /team-onboarding は過去30日分のセッション、コマンド、MCP 利用を分析して、共有用の Markdown ガイドを生成する1
  • 生成結果は便利だが正本ではない。恒久ルールは CLAUDE.md、.claude/settings.json、.claude/skills/ に置く234
  • 共有前に個人環境依存の情報を削る。MCP、ローカルパス、権限設定は特にレビュー必須

新しい開発者に Claude Code の使い方を渡すとき、 本当に時間を食うのはインストールより 「このリポジトリでは何を覚えるべきか」の整理です。

2026年4月10日に追加された v2.1.101 の /team-onboarding は、 その属人的な立ち上がり手順を Markdown ガイドに変換するためのコマンドです5。

この記事の問いは、 /team-onboarding をどこまで信頼し、 何を version control に残すべきかです。

/team-onboarding で何が生成されるのか

結論から言うと、/team-onboarding は 「チーム向けのセットアップ文書の下書き」を自動生成する機能です。

公式コマンド一覧では、 Claude Code が過去30日分のセッション、コマンド、 MCP server usage を分析し、 チームメイトが最初のメッセージとして貼り付けられる Markdown ガイドを出力すると説明されています1。

Week 15 の更新説明でも、 「十分に使い込んだプロジェクト」で実行し、 新メンバーに渡して再現させる使い方が推奨されています6。

役割分担図: /team-onboarding と設定資産

つまり価値は、機能紹介そのものではありません。強いメンバーの暗黙知を、再利用可能な文章に圧縮できることです。

まずはこの流れで使う

実務では、最初から全員に配るより、運用が固まっているリポジトリで試すのが安全です。

claude --version
claude
# セッション内で実行
/team-onboarding

古いバージョンではコマンド自体が出ません。 /team-onboarding は v2.1.101 追加なので、 まずバージョン確認が必要です5。

また、公式は built-in command の表示可否が プラン・環境・プラットフォームに依存すると明記しています1。 そのため「自分の環境にない」場合は、 まず更新とログイン状態を疑うのが先です。

ここで次の疑問が出ます。生成された Markdown を、そのままチームの正解として配ってよいのか。答えは基本的に No です。

CLAUDE.md や settings とどう使い分けるか

/team-onboarding は入口として強い一方、恒久的な運用ルールを置く場所ではありません。役割を分けると整理しやすくなります。

手段主な役割共有範囲向いている内容
/team-onboarding直近30日の利用実態を文章化配布用の下書き初回セットアップ、最初に読むべき流れ
CLAUDE.md毎セッションで読む恒久指示リポジトリ共有アーキテクチャ、命名規約、共通ワークフロー2
.claude/settings.jsonチーム共有設定リポジトリ共有permissions、hooks、MCP、project settings37
.claude/skills/手順化した再利用知識リポジトリ共有定型作業、長い手順、チェックリスト4

実務上のコツは単純です。 /team-onboarding で見つかった安定ルールを、 あとから正規の保管場所へ昇格させることです。

公式は CLAUDE.md を 「新しいチームメイトも必要とする文脈」を書く場所と説明しています。 project settings や project skills も source control でチーム共有できます234。

共有前に必ず見るべき3点

ここが一番重要です。 公式は /team-onboarding の生成元として セッション履歴やコマンド履歴を挙げています1。

そのため、出力にはチーム全体の標準ではなく、 ある1人のローカル事情 が混ざります。 これは公式仕様からの自然な推論です。

共有前は次の3点だけは必ず見直してください。

  • ローカル依存: 個人の絶対パス、一時ディレクトリ、私用 alias が残っていないか
  • MCP 依存: その MCP が全員に必要か、project 設定や managed settings に寄せるべきか
  • 権限と安全性: 個人だけが許可した危険な操作を、チーム標準として広げていないか

Claude Code の security と IAM 文書は、 permissions を version control や managed settings で 管理することを勧めています78。

環境差分ごと減らしたいチームなら、 devcontainer まで含めて揃えると onboarding のブレがさらに小さくなります9。

チーム導入ではこう運用すると効く

最も失敗しにくいのは、/team-onboarding を「配布文書ジェネレーター」ではなく暗黙知検出器として使う運用です。

導入フロー図: /team-onboarding の4ステップ

  1. 使い込んだメンバーが成熟したリポジトリで /team-onboarding を実行する
  2. 出力から個人依存のノイズを削り、恒久ルールを CLAUDE.md や .claude/settings.json に移す
  3. 残った Markdown を「初回メッセージ用ガイド」として新メンバーに渡す
  4. 新メンバーが実際につまずいた点を、今度は project files 側へ反映する

この循環が回ると、 オンボーディング資料が単なるドキュメントではなく、 Claude Code を前提にした運用資産に変わります。

まとめ

/team-onboarding の本当の価値は、 説明文を自動生成することより、 チームの暗黙知がどこに散らばっているかを見える化することにあります。

生成された Markdown をそのまま信じるより、 そこから何を CLAUDE.md、settings、skills に 昇格させるべきかを判断できるチームのほうが、 立ち上がりも再現性も速くなります。

関連記事

  1. Commands - Claude Code Docs ↩↩↩↩

  2. How Claude remembers your project - Claude Code Docs ↩↩↩

  3. Claude Code settings - Claude Code Docs ↩↩↩

  4. Extend Claude with skills - Claude Code Docs ↩↩↩

  5. Changelog - Claude Code Docs ↩↩

  6. Week 15 · April 6–10, 2026 - Claude Code Docs ↩

  7. Security - Claude Code Docs ↩↩

  8. Identity and Access Management - Claude Code Docs ↩

  9. Development containers - Claude Code Docs ↩