Claude Code 使い方|Anthropic 社員の playbook 5 拡張 + 3 運用

Claude Code 使い方|Anthropic 社員の playbook 5 拡張 + 3 運用

Claude Code を業務で使ってはいるが、自分の活用はまだ浅いのではないかと感じている方は多いはずです。Anthropic が 2026 年 5 月に公開した社内 playbook には、社員自身が実際に使っている拡張機能と運用パターンが体系化されています。本記事では 2 つの能力軸 + 5 拡張機能 + 3 運用パターンを日本語で整理し、自社チームにそのまま輸入できる粒度でお届けします。

結論powered by Claude

Anthropic が公開した「How Anthropic teams use Claude Code」は、社内エンジニアと非エンジニア職を含めた実利用パターン を体系化した公式 playbook です。コード作業の中核と、調査・設計・運用などコードを越えた使い方の 2 つの能力軸 で全体が整理されており、Claude Code 導入判断の一次資料として扱える内容になっています。

playbook が提示する強化軸は CLAUDE.md・フック・Skills・Plugins・Managed Agents の 5 拡張機能 と、CLAUDE.md 中心のチーム共有・フックによる安全弁・監督モデルの 3 運用パターンです。Anthropic 社員は これらを段階的に積み上げて自分の作業環境を強化 しており、最初から全てを使う必要はないと明言されています。

日本のエンジニアが今日から真似できる入口は 小さく始めて段階的に拡張する ことです。CLAUDE.md に最小ルールを書き、フックを 1 個だけ導入し、Opus による監督モデルを 1 タスクで試すという 3 ステップで、英語 30 ページの playbook を読まずに 本家のベストプラクティスを輸入 できます。

目次 (23)

1. Anthropic 公式 playbook「How Anthropic teams use Claude Code」とは何か

2026 年 5 月 12〜13 日にかけて Anthropic 公式ブログとサイトで公開された「How Anthropic teams use Claude Code」は、Claude Code を日常的に業務で使っている Anthropic 社員自身が、どのように本ツールを活用しているかを体系化したドキュメントです。公式 blog の要約版と 30 ページ超の PDF 全文版の 2 形態で公開され、エンジニアリングチームだけでなくセールス・マーケ・経理・法務など非エンジニア職の利用例も含まれている点が大きな特徴です。Claude Code の導入を検討するチームにとって、公式の一次資料が出てきた意義は非常に大きいと言えます (出典: https://claude.com/blog/how-anthropic-teams-use-claude-code)。

1.1 PDF 全文と blog 要約の使い分け

公式 blog 版は要約で、playbook の核となる「2 能力軸 × 5 拡張 × 3 運用パターン」のフレームワークが提示されています。これに対して PDF 全文版 (https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf) は、各社員の具体的な使い方事例、失敗談、初期セットアップで詰まったポイントが豊富に収録されており、社内勉強会・コンサル提案の素材として高い価値があります。エンジニアリング職以外への展開を考えるなら PDF 全文の参照が必須となり、blog 版だけでは情報量が不足します。

1.2 なぜ Anthropic は社内事例を一般公開したのか

公開意図は 3 つに整理できます。1 つ目は、顧客企業が「Anthropic 社内ですらどう使っているかわからない」状態を解消し、生産性ベンチマークを提示すること。2 つ目は、Claude Code を取り巻く拡張機能とコミュニティプラグインのエコシステム拡大を促進すること。3 つ目は、社外で生まれた優れた使い方を逆輸入する経路を作ることです。Anthropic にとって、社内ドキュメントの一般公開はコスト以上にリターンが大きいと判断された結果と読み取れます。

1.3 想定読者と読みどころ

playbook の主要読者は、Claude Code を導入済みのエンジニアリングチームのリードと、導入是非を検討中の CTO・VPoE 層です。最大の読みどころは「Anthropic 社員ですら最初から完璧にやっていない」「拡張は段階的に積み上げるもの」というメッセージで、これは初期導入チームのプレッシャーを和らげる効果があります。完璧な構成を目指すのではなく「今日 1 個から始める」という姿勢が文書全体に貫かれており、現場の心理障壁を下げる構成になっています。

2. 全社で共通する 2 つの能力軸 - コードを書く / コードを越えた使い方

playbook が冒頭で提示するのが、Claude Code の能力を整理する 2 つの軸です。第 1 軸は「コード作業の中核」で、コードを書く・読む・レビューする・デバッグするという従来の AI コーディング支援イメージに対応します。第 2 軸は「コードを越えた使い方」で、調査・設計レビュー・ドキュメント作成・運用作業・データ集計・他職種との橋渡しなど、エンジニア以外の業務まで含む広い領域です。Anthropic 社内では第 2 軸の利用ボリュームが第 1 軸と同等かそれ以上に達しており、これは多くの読者の使い方の盲点を突く重要な発見です (出典: https://claude.com/blog/how-anthropic-teams-use-claude-code)。

2.1 第 1 軸 - コードを書く・読む・レビューする

第 1 軸はエンジニアの中核業務で、新規実装、既存コードの読解、PR レビュー、デバッグ、リファクタリングが含まれます。playbook では特に「不慣れな言語・フレームワーク・社内コードベース」での威力が強調されており、たとえば長年 Python を書いてきた社員が初めて Rust の社内サービスに触る際に、Claude Code が「読み解きパートナー」として機能した事例が紹介されています。新人オンボーディングの加速にも直接効きます。

2.2 第 2 軸 - 調査・設計・運用・橋渡し

第 2 軸は非コード作業を指します。具体例として、セールスチームが顧客提案資料の下書きを Claude Code で生成、マーケチームがブログ記事の構造案を生成、経理チームが社内ダッシュボードの SQL を生成、法務チームが契約書の差分要約を生成する利用が紹介されています。エンジニアでなくとも CLAUDE.md にチームのコンテキストを書けば、職種別の壁を越えて活用できる点が示されています。

2.3 2 軸の比率が示す本当のメッセージ

Anthropic 社内では第 2 軸の利用が第 1 軸と同等以上に達するという事実は、Claude Code を「コード補完ツール」と捉える視点が狭すぎることを示しています。読者が自社チームに導入する際は、エンジニアだけにアカウントを配るのではなく、業務委託・営業・コーポレート職にも配る方が ROI が高い可能性があります。これは playbook 全体を通じての最大の発見点と言えます。

3. 5 つの拡張機能で社員はどう Claude Code を強化しているか

playbook が「拡張軸」として整理する 5 つの機能を順に解説します。Anthropic 社員はこれらを段階的に重ね、自分専用の作業環境を構築しています。重要なのは「全部を最初から使う必要はない」点で、まず 1 つ導入して効果を測り、次の拡張へ進むのが推奨ルートです。以下の順序は playbook 内の言及頻度順とほぼ一致しており、最初に着手すべき優先度の高い順から並べています (出典: https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf)。

3.1 拡張 1 - CLAUDE.md による文脈注入

CLAUDE.md は、リポジトリやディレクトリごとに「Claude Code がそのコードベースを理解するための前提知識」を書き溜める設定ファイルです。Anthropic 社員はチーム共通の CLAUDE.md にコーディング規約、テストコマンド、デプロイ手順、過去の失敗パターンを書き込み、新しいタスク開始時に Claude Code が即座に文脈を把握できる状態を維持しています。これだけで Claude Code の応答品質が大きく向上し、最も投資対効果の高い初手と評価されています。

3.2 拡張 2 - フックによる前後処理の自動化

フックは、Claude Code の各イベント(ツール実行前後、セッション開始時など)に処理を挿入する機能です。社員は commit 前の lint 強制、本番デプロイ前の確認ダイアログ、特定ファイル編集時の警告通知などをフックで構築し、Claude Code が想定外の動きをするリスクを構造的に下げています。フックは「Claude Code が AI として何をやってよくて何をやってはいけないか」を機械的に縛るガードレールとして機能しています。

3.3 拡張 3 - Skills による反復タスクの再利用

Skills は、特定の業務手順をパッケージ化して Claude Code に呼び出させる仕組みです。たとえば「PR を作る」「リリースノートを生成する」「データを集計する」といった反復作業を Skill として定義しておくと、毎回プロンプトを書き直さずに済みます。Anthropic 社内では各チームが共通 Skills のレジストリを持っており、新メンバーがすぐに本家のベストプラクティスに乗れるようになっています。組織知の蓄積場所として機能している点が特徴です。

3.4 拡張 4 - Plugins による外部機能統合

Plugins は、外部サービスやツールとの統合を Claude Code に提供する拡張で、MCP(Model Context Protocol)サーバーとして実装されることが多い機能です。社員は Slack、Linear、GitHub、社内 DB、社内 API などを Plugin として接続し、Claude Code から直接これらにアクセスできる環境を作っています。結果として「ツールを切り替えずに 1 つの会話で完結する」体験が生まれ、コンテキスト切替コストが大幅に減少しています。

3.5 拡張 5 - Managed Agents による長時間タスクのバックグラウンド実行

Managed Agents は、Claude Code が長時間のタスクをバックグラウンドで実行できる仕組みです。社員はリファクタリング、テストカバレッジ向上、大型データ移行、複数 PR の並列処理などを Managed Agents に任せ、自分は別の作業を進めるという働き方を採用しています。Anthropic 社内では「1 人で複数エージェントを並列に指揮する」スタイルが標準化しつつあり、生産性の天井そのものが上方に押し上げられています。

4. 3 つの運用パターン - CLAUDE.md / フック / 監督モデル

5 つの拡張機能と並んで、playbook が強調するのが「運用パターン」です。これは個別の機能ではなく、複数の機能を組み合わせて「チームとして Claude Code をどう扱うか」の型を示しています。Anthropic 社内で実証された 3 パターンを順に紹介します。いずれも完璧に始める必要はなく、まず最小構成でチームに導入し、運用しながら洗練していくのが標準ルートとして提示されています (出典: https://claude.com/blog/how-anthropic-teams-use-claude-code)。

4.1 パターン A - CLAUDE.md を中心としたチーム共有ルール

最初の運用パターンは、CLAUDE.md にチーム全員が読むべきルールを集約する型です。コーディング規約、テストコマンド、デプロイ手順、レビュー基準、過去の失敗事例を CLAUDE.md に書き込み、レビューを通して全員でメンテナンスします。Anthropic では「CLAUDE.md は team handbook の AI 版」として位置づけられ、新メンバーのオンボーディング資料も兼ねるという二重の役割を担っています。

4.2 パターン B - フックを使った安全弁

2 つ目は、フックを使ってチームの最低限の安全ラインを引く型です。たとえば本番デプロイ前に必ず確認プロンプトを差し込む、特定ファイル(本番設定など)の編集時に警告する、commit 前に lint を強制するなどです。Anthropic 社内では「フックは AI を信用しないための仕組みではなく、AI と人間がペアで安全に走るためのガードレール」と位置づけられており、運用思想として重要な転換点になっています。

4.3 パターン C - 監督モデルの活用

3 つ目は、強力なモデル(Opus)が弱いモデル(Sonnet 等)の出力を監督する階層構造、または人間がエージェントを監督するレビュープロセスです。Anthropic 社内では Opus が複数の Sonnet エージェントを監督する構成が登場しつつあり、コスト効率と品質を両立させる新しい設計パターンとして注目されています。最終的な承認者として人間が介入する役割は維持されており、責任の所在は明確に保たれています。

5. 日本のエンジニアが今日から真似できる 3 つの実践ステップ

ここまでに紹介した内容は Anthropic 社内の事例ですが、日本のエンジニアが現場で真似する際には、時差・言語・既存ツールスタック・組織文化の違いを踏まえた翻訳が必要です。本セクションでは、編集部の経験を踏まえ、playbook を最小コストで自社に持ち込むための 3 ステップを順序付きで提示します。いずれも「今日 1 個から始める」を意識した粒度に落としてあり、初回試行のハードルを下げることを最優先しています。

Step 1: CLAUDE.md に最小ルールを書く

最初のステップは、CLAUDE.md の作成です。ただし、いきなり完璧な内容を書こうとせず、まず以下の最小 3 項目だけ書きます。

  1. 「日本語で書いてよい」一文を最初に明記する
  2. 時刻表記は JST 固定とし、コミットメッセージにも JST を入れる
  3. 主要なテストコマンドと lint コマンドを 2-3 行だけ書く

これだけで Claude Code の応答品質が体感できるレベルで変わります。最初の commit は完成度よりも「とにかく commit する」を優先し、運用しながら少しずつ加筆していくのが現実的な進め方です。

Step 2: フックは 1 個だけで慣らす

2 つ目のステップは、フックを 1 個だけ導入する試みです。最初の 1 個として推奨されるのは、commit メッセージの自動整形フック、または本番デプロイ前の確認フックのいずれかです。両方を一気に入れず、片方だけにすることで、フックが想定外の挙動を起こした場合の切り戻しコストが最小化されます。1 週間運用して効果が確認できたら、次のフックを 1 個追加するという段階的な拡張が安全です。

Step 3: 監督モデルを 1 タスクだけ試す

3 つ目のステップは、Opus による監督モデルを 1 タスクだけ試すことです。最初の試行に推奨されるのは、大規模リファクタリングのレビュー、または複数 PR の差分要約のいずれかです。費用対効果を測定する前提で 1 タスクだけ走らせ、Opus の判断品質と Sonnet ベース実行とのコスト差を比較します。納得できる ROI が確認できれば、定常運用に組み込む判断が可能になります。

出典

参考になったら ♡
Clauder Navi 編集部
@clauder_navi

Anthropic の Claude / Claude Code を中心に、日本のエンジニア向けに最新動向と実務 を毎日発信。 運営方針 は メディアについて をご覧ください。