Anthropic公式PDF日本語要約｜Claude Code社内10チーム活用

最終更新：2026年9月

結論：「How Anthropic teams use Claude Code」は、Anthropic が自社10チームへのインタビューをまとめた全23ページ・英語のPDFで、Anthropic のCDN（www-cdn.anthropic.com）に直接置かれており、登録もフォーム入力もなしで読めます。

この記事の要点：

• 中身は「10チーム × 使い方 × 成果 × コツ」の定型フォーマット。データ基盤・製品開発（Claude Code チーム自身）・セキュリティ・推論・データサイエンス／ML・APIナレッジ・グロースマーケティング・プロダクトデザイン・RL・法務が、各2ページずつ整理されています。
• 数字は控えめだが具体的。インフラ調査が10〜15分から約5分に、機械学習の調査時間が約8割減、JavaScriptをほぼ書けないチームが5,000行のTypeScriptアプリを完成、広告クリエイティブを最大100パターン自動生成、広告コピー作成が2時間から15分に短縮、という値がPDF本文に記載されています。
• 最大の読みどころは「非技術者3チームが載っている」こと。法務・グロースマーケティング・プロダクトデザインの3部門が、エンジニアではない立場での使い方として登場します。日本企業がこのPDFを真似るなら、ここが入口です。

対象読者：Claude Code を全社に広げるか迷っている経営者・情報システム責任者・AI推進担当者。
読了後にできること：自部門の「APIがある反復作業」を1つ選び、PDFの財務チームと同じ「プレーンテキストの手順書」を書かせるところまで進められます。

判断の分かれ目は「エンジニアの道具か、部門の道具か」に尽きる

Claude Code の社内展開で結果がいちばん変わる分岐は、料金プランでもモデル選定でもありません。開発部門への支給品として配るのか、部門ごとの業務道具として配るのかという一点です。前者は稟議が通りやすい代わりに効果がエンジニアの生産性に閉じ、後者は効果が横に広がる代わりに権限設計と初期セットアップの伴走が要ります。

このPDFが他の資料と違うのは、その両方が同じ文書に並んで書かれている点です。製品開発チームやRLチームのページは完全にエンジニアの話。一方で法務チームのページには、弁護士が1時間でアクセシビリティ用アプリを作った話が出てきます。同じツールなのに読む人によって別の文書に見える。だから「うちはどちらで入るべきか」を決める材料として読むのが正しい使い方です。

法人向けのAI研修や導入支援の場でも、質問はこの分岐に集中します。「エンジニアがいない部署に配って意味があるのか」「セキュリティ部門をどう納得させるのか」。このPDFは前者に非技術者3チームの実例で、後者にセキュリティチーム自身の使い方とMCPサーバーの運用方針で答えを持っています。

以下、10チームの要約、共通していた4つの型、「2025年6月の資料をそのまま2026年に真似ると外す部分」まで整理します。数字はPDF本文の値だけを使い、公式ドキュメントで裏取りしたものは確認日を添えました。

まず「どのファイルを読むのか」を確定させる

同名・類似の資料が複数あるので、ここは正確に押さえてください。

• URL：https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf
• ページ数：23ページ（1が表紙と序文、2が目次、3〜22が本文）
• 言語：英語のみ／サイズ：約6.2MB
• 更新状況：2026年9月14日に確認した時点で、HTTPレスポンスの Last-Modified は 2025年6月4日。約1年3か月更新されていません

検索すると note・Zenn・LinkedIn の要約が上位に混ざりますが、それらは二次情報です。数字や文言を引用するなら必ずCDN直リンクの本体を開いてください。本文は1チーム2ページの固定型で、①チーム紹介 ②Main Claude Code use cases ③Team impact（ここに数字が出る） ④Top tips の順に並びます。「使い方 → 成果 → コツ」が10回繰り返されるだけなので、通読せず自部門に近いチームの2ページだけ読めば足ります。

10チームの要約表｜該当ページ・主な使い方・成果

PDFの「Main Claude Code use cases」と「Team impact」から核だけを抜いた表です。ページ番号はPDF内のノンブルです。

10チームのうち3チーム（グロースマーケティング・プロダクトデザイン・法務）は「コードを書く仕事ではない人」の章です。Claude Code を開発ツールだと思って読むと、この6ページを飛ばしてしまいます。日本企業にとって転用価値がいちばん高いのは、まさにこの6ページです。

なお表に出てくる「サブエージェント」「並行インスタンス」は、現在のClaude Codeでは機能として整理されています。並列実行の現行仕様はClaude Code Agent Teamsの使い方｜並列実行【2026】でまとめています。

非技術者3チームの読みどころ

グロースマーケティング：「APIがある反復作業」から入っている

最初の対象が「文章を上手に書かせる」ではなく「APIが叩ける反復作業」だった点が肝です。Top tips の1番目も「APIのある反復作業を特定せよ」。もう1つ効くのが「複雑なワークフローは専門サブエージェントに分割せよ」で、見出しと説明文を専任に分けた理由として「デバッグしやすくなり、複雑な要件下での出力品質が上がる」と書かれています。文字数制限のある日本語の広告や商品説明にそのまま持ち込めます。

プロダクトデザイン：セットアップだけはエンジニアに手伝わせている

Top tips の1番目が「エンジニアにきちんとセットアップを手伝ってもらえ」である点が見落とされやすい。リポジトリの初期設定と権限周りは非開発者には難しい、と正直に書かれています。アカウントを配って終わりにすると定着しないという展開設計上の根拠が公式資料側にあるわけです。2番目も具体的で、メモリファイルに「自分はデザイナーでコード経験が少ない。詳しい説明と、小さく刻んだ変更が必要」と書いておくと応答の質が変わるとあります。

法務：Claude.ai で設計して Claude Code で作る

明記されているのは「Claude.ai で構想を練り切ってから、Claude Code に実装用の手順プロンプトを渡す」2段構え。しかも「一気に出力せず、1ステップずつゆっくり」と指示します。非エンジニアが大量のコードを一度に受け取っても判断できないからです。法務領域の活用は法務のClaude Code活用30選｜契約レビュー・社内規程で別途整理しています。

エンジニア7チームに共通したのは「任せる範囲の線引き」

残る7チームは書きぶりが違うのにどこまで自律で走らせ、どこから人が監視するかに収束します。とくに対照的な3チームを並べます。

• 製品開発チームは「タスク分類の勘を育てよ」と明示。非同期（放流）で回るのは周辺機能とプロトタイプ、同期（監視）が必要なのはコアのビジネスロジックと重要な修正、と線を引いています。
• データサイエンスチームは同じことを「スロットマシン」と表現。可視化アプリは「relatively low context（比較的コンテキストが浅い）」でモノレポ全体の理解を要しないから丸投げできる。だから5,000行のTypeScriptが成立する。
• RLエンジニアリングチームは限界を率直に書きます。小〜中規模のPRなら短時間で作れるが一発で通るのは約3回に1回。だから「まず一発を試し、ダメなら協働に切り替える」運用にしている。

3つは矛盾していません。コンテキストが浅く失敗のコストが低い領域は放流、深く絡み合って失敗が高くつく領域は監視という同じ基準を、部署ごとの語彙で言い換えているだけです。全社ルールに書くべきは、この基準そのものです。

10チームを貫く4つの型

複数チームが独立に同じことを言っている箇所が4つあります。規模や業種に関係なく移植できる部分です。

型1：人に聞く前に、まずClaude Codeに聞く

APIナレッジチームはあらゆるタスクの「first stop」として使い、どのファイルを見るべきか尋ねてから作業を始めます。推論チームはGitHubを手で検索せず「どのファイルがこの機能を呼ぶか」を尋ねる。データ基盤チームは新入社員に「まずClaude Codeでコードベースを案内させろ」と伝える。製品開発チームはSlackの返信を待つ代わりに直接聞く。4チームが同じ行動をしています。しかも効果は速度だけではなく、APIナレッジチームは「不慣れな領域に踏み込む自信がついた」、推論チームは「テスト網羅を考える精神的負荷が下がった」と書いています。

型2：CLAUDE.md を「案内役の文書」として育てる

PDFの表記は「Claude.md」ですが、これは現在の公式ドキュメントで CLAUDE.md と大文字統一されているファイルを指します（公式ドキュメント「How Claude remembers your project」・2026年9月14日確認）。

データ基盤チームの Top tips 1番目は「詳細な Claude.md を書け」。文書化するほど性能が上がり、既存パターンがある定型作業で特に効くとあります。RLチームは同じファイルでツール呼び出しの失敗を防ぎ、実例として「run ではなく pytest を実行しろ／不要な cd をするな、正しいパスを使え」が載っています。つまりこのファイルはルールブックであり、同時に自分の前提を宣言する場所です。データ基盤チームはさらに、セッション終わりに作業要約と改善案を出させ、その内容でファイル自体を磨き込む継続改善ループを回しています。

型3：きれいな git 状態から始めて、チェックポイントを刻む

製品開発チームは「クリーンなgit状態から始め、チェックポイントを定期的にコミットすることを強調している」と書きます。RLチームはこれを「try and rollback」と名付け、Top tips に「チェックポイント重視のワークフローを使え」と明記。データサイエンスチームは「状態を保存してから30分走らせ、ダメなら作り直す。直そうとするより作り直したほうが成功率が高い」と書いています。

この記述は非エンジニア部門の展開ルールに翻訳できます。git でなくとも、作業前にファイルのコピーを取る、共有ドライブの版管理を有効にしておく、といった形で「戻せる状態を先に作る」原則だけ移せば足ります。

型4：スクリーンショットと計画をそのまま渡す

データ基盤チームはKubernetes障害の切り分けでダッシュボードのスクリーンショットをそのまま投入し、Google CloudのUIをメニュー単位で案内されました。プロダクトデザインチームはモックアップ画像から動くプロトタイプを作り、Command+Vでの貼り付けを Top tips に挙げる。法務チームは「文章で説明せずスクリーンショットで見せて反復する」と書いています。

計画側も同じで、法務チームとグロースマーケティングチームは両方ともClaude.ai で構想を作り込み、実装用の手順プロンプトにまとめさせて Claude Code に渡す手順を採っています。画面と計画は、非エンジニアがいちばん自然に用意できる入力です。この型が非技術者3チームに集中しているのは偶然ではありません。

日本企業がこのPDFを真似るなら、この順番で

PDFの Top tips を、日本企業の組織構造に合う順に並べ替えたものです。

1. 非エンジニア部門の「APIがある反復作業」を棚卸しする。広告管理画面、MA、会計、勤怠、CRM。同じ操作を月に何十回も繰り返しているものを挙げます。開発部門から始めないのは、効果が横に広がる証拠がPDF側にあるからです。
2. 手順書をプレーンテキストで書かせる。PDFでは、コード経験のないメンバーが「このダッシュボードに問い合わせて情報を取り、これらのクエリを実行し、Excel出力を作る」という粒度でステップを書き、読み込ませるだけで一連の処理が実行された。必要な入力（対象日付など）は向こうから聞いてくるとあります。最初の成果物はプログラムではなく手順書です。
3. 初回セットアップだけエンジニアが伴走する枠を取る。ここを個人の努力に任せると、配っただけで終わります。
4. 機微なデータはCLIではなくMCPサーバー経由にする。データ基盤チームの Top tips 2番目が、そのまま稟議に使える記述です。BigQuery CLI を直接触らせるのではなくMCPサーバーを経由させる。理由は「Claude Code が何にアクセスできるかをより良く制御できる」「ログが必要なデータやプライバシー上の懸念があるデータで特に重要」。「AIにDBを触らせるのか」という問いに公式資料が「境界を挟め」と答えているのは強い材料です。稟議と承認フローの実装はClaude Code法人導入｜Team比較・稟議テンプレ・FAQ【2026】にテンプレートとしてまとめています。
5. 使い方を見せ合う会を開く。データ基盤チームの Top tips 3番目。互いに実演した結果、自分では発見できなかった使い方が広がったとあります。ツールの定着は機能説明会ではなく同僚の画面で決まります。

【要注意】このPDFをそのまま真似ると外す3点

一次情報としての価値は高いものの、2025年6月に作られた文書です。そのまま社内資料に転記すると事実がずれる箇所があります。

注意1：ファイル名は CLAUDE.md（全大文字）

❌ PDFの表記どおり「Claude.md を作りましょう」と社内手順書に書く
⭕ CLAUDE.md と書く

なぜ重要か：現在の公式ドキュメントは CLAUDE.md で統一され、置き場所も ./CLAUDE.md または ./.claude/CLAUDE.md、個人用は ~/.claude/CLAUDE.md、共有しないものは CLAUDE.local.md と整理されています。200行以内を目安にすること、大きくなったら .claude/rules/ に分割する仕組みも明記されており、PDFの時点にはなかった整理です。

注意2：「auto-accept モード」は今の正式名ではない

❌ 「shift+tab で auto-accept モードに入る」とだけ書く
⭕ 「Shift+Tab で権限モードを切り替える。ファイル編集を自動承認するのは acceptEdits モード」と書く

なぜ重要か：現在の権限モードは default（CLI表示はManual）／acceptEdits／plan／auto／dontAsk／bypassPermissions に整理され、Shift+Tabで巡回します。さらにPro・Max・Teamプランでは auto モードが既定の開始モードで、別のモデル（分類器）が人の代わりに操作を審査します（公式ドキュメント「Choose a permission mode」・2026年9月14日確認）。PDFの「auto-accept」で社内ルールを書くと現行の auto モードと混同します。別物です。

注意3：「一発で通る」前提で工数を見積もらない

❌ 「Vimモードは約70%がClaudeの自律作業」を根拠に開発工数を7割減で見積もる
⭕ 同じ資料のRLチームが「一発で通るのは約3回に1回」と書いていることも前提に置く

なぜ重要か：このPDFは成功例だけの資料ではありません。RLチームは「コメントを変な場所に付ける」「コード構成が疑わしいことがある」と書き、データサイエンスチームは「モデルは既定でより複雑な解に傾くので、止めて『もっと単純に』と言う必要がある」と書いています。成果の数字と限界は同じ文書内に併記されています。片方だけ引用すると期待値がずれます。

PDFの内容を社内展開に落とすプロンプト5つ

そのままコピーして使えます。角括弧の部分を自社の情報に置き換えてください。いずれも末尾に事故防止の一行を入れてあります。

プロンプト1：部門の「APIがある反復作業」を棚卸しする

以下の部門の業務のうち、「同じ操作の繰り返し」かつ「使っているツールにAPIがある」ものを洗い出してください。

部門：[例：マーケティング部・4名]
使っているツール：[例：Google広告、Meta広告、HubSpot、Figma]
月間の主な作業：[箇条書きで5〜10個]

出力形式：
1. 作業名
2. 月あたりの実施回数と1回の所要時間（不明なら「要計測」）
3. 使用ツールにAPIがあるか（公式ドキュメントで確認できればURLも）
4. 自動化の優先度（高/中/低）とその理由

不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

プロンプト2：業務担当者が書いた手順書を実行可能な形に整える

以下は私が自分の言葉で書いた業務手順です。
プログラムに書き換える前に、手順として曖昧な箇所を洗い出してください。

【私の手順書】
[例：月初に広告管理画面から前月の実績CSVを落とす → 部門別に集計する → 前月比を計算する → 報告用シートに貼る]

やってほしいこと：
1. 各ステップで「あなたが私に確認すべき情報」を列挙する
2. 判断が人に必要なステップと、機械的に決まるステップを分ける
3. 実行手順を1ステップずつに分解して番号を振り直す

一気に実装しないでください。まず手順の確認だけを返してください。

プロンプト3：CLAUDE.md の初版を作る

このリポジトリを読んで、CLAUDE.md の初版を作ってください。

含めてほしい内容：
- ビルド・テスト・lint の実行コマンド（実際に存在するものだけ）
- ディレクトリ構成のうち、外から見て分かりにくい部分
- このプロジェクト固有の命名規則・コーディング規約
- 触ってはいけないファイル／変更前に確認が必要なファイル

条件：
- 200行以内に収める
- コードを読めば分かることは書かない
- 推測で書いた行には行末に「(要確認)」と付ける

読み取れなかった項目は、推測で埋めずに「不明」と書いてください。

プロンプト4：スクリーンショット起点で原因を切り分ける

添付したスクリーンショットは [システム名／画面名] のものです。
[起きている症状] という状態になっています。

やってほしいこと：
1. この画面から読み取れる事実だけを箇条書きにする（推測は分けて書く）
2. 考えられる原因を、確認コストが低い順に並べる
3. 1つ目の原因を確認する手順を、どこをクリックするかまで書く

画面から読み取れないことは推測せず、「この画像では確認できない」と書いてください。
破壊的な操作が含まれる場合は、実行前に必ず警告してください。

プロンプト5：機微データの取り扱い境界を設計する

以下のデータをAIコーディングツールから扱う場合の、アクセス境界を設計してください。

対象データ：[例：顧客マスタ（氏名・メール・契約金額）、勤怠データ]
現在のアクセス方法：[例：データウェアハウスにCLIで直接接続]
社内の制約：[例：個人情報へのアクセスは監査ログ必須、部門外からの参照は禁止]

出力してほしいもの：
1. 直接接続させる場合のリスク（具体的な事故シナリオで）
2. 中間層（MCPサーバー等）を挟む構成と、そこで制御できること
3. 監査ログに何を残すべきか／この設計で「防げないこと」

公式ドキュメントで確認できない仕様は「要確認」と明記してください。
規程の解釈が必要な部分は、法務確認が必要であることを明示してください。

よくある質問

PDFに出てくる「サブエージェント」は Agent Teams 機能のことですか？

いいえ、別物です。PDFのグロースマーケティングチームが使う「2つの専門サブエージェント」は、現在のClaude Codeでいうサブエージェントに相当します。一方Agent Teamsは複数のClaude Codeセッションをチームとして協調させる別の仕組みで、公式ドキュメントに「実験的機能であり、既定で無効」と明記されています。有効化には環境変数または settings.json で CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を 1 にします。

公式ドキュメントは推奨規模をまず3〜5人のteammate、1人あたり5〜6タスクとし、トークン消費は単一セッションより大幅に増えると明記。セッション再開（/resume）でteammateが復元されない、teammateが自分のteammateを作れない、といった制限も列挙されています。定型作業ならサブエージェントか単一セッションのほうが費用対効果が高い、という書き方です（2026年9月14日確認）。

「Teamプラン」と Agent Teams は関係ありますか？

関係ありません。Agent Teams は機能名、Team は契約プラン名です。公式の料金ページでは Team は「2〜150人のチーム向け」とされ、標準シートが年払いで1席あたり月20ドル（月払いは25ドル）、Premiumシートが年払いで1席あたり月100ドル（月払いは125ドル）。Team には Claude Code と Claude Cowork が含まれると記載されています（2026年9月14日確認）。

つまりTeamプランを契約しても Agent Teams が自動で使えるわけではありません。逆に個人のProプランでも環境変数を設定すれば動きます。プラン側の比較はClaude Code Teamプラン｜料金・最低2名から【2026年9月】にまとめています。

このPDFの日本語版はありますか？

2026年9月14日時点で、このPDF（23ページ）の日本語版は公式に確認できていません。ダウンロードできるのは英語版のみです。

ただし同名のブログ記事には日本語ページが存在します。claude.com/ja/blog/how-anthropic-teams-use-claude-codeで「AnthropicチームによるClaude Codeの活用方法」として公開されています。ただしブログ記事はPDFより大幅に短く、10チーム分の「Team impact」「Top tips」は入っていません。詳細が必要なら英語のPDFを読む必要があります。

参考・出典

• How Anthropic teams use Claude Code（PDF・全23ページ・英語） — Anthropic（参照日: 2026-09-14 / HTTP Last-Modified: 2025-06-04）
• How Anthropic teams use Claude Code（ブログ記事・英語） — Anthropic（2025年7月24日公開 / 参照日: 2026-09-14）
• AnthropicチームによるClaude Codeの活用方法（日本語ページ） — Anthropic（参照日: 2026-09-14）
• Agent Teams 公式ドキュメント — Anthropic（参照日: 2026-09-14）
• CLAUDE.md（メモリ）公式ドキュメント — Anthropic（参照日: 2026-09-14）
• 権限モード 公式ドキュメント — Anthropic（参照日: 2026-09-14）
• Claude 料金ページ — Anthropic（参照日: 2026-09-14）

結論

「How Anthropic teams use Claude Code」は、Claude Code を開発部門の道具から会社の道具に変えるための一次資料です。23ページのうち非技術者3チームの6ページが日本企業にとっていちばん転用価値が高く、10チームが独立に同じことを4つ言っています。まず聞く／CLAUDE.md を育てる／戻せる状態から始める／画面と計画を渡す。この4つを社内ルールに落とせば、実務的な価値はほぼ回収できます。

同時に、2025年6月の資料であることも忘れないでください。考え方は生きていますが、モード名もファイル名も変わっています。「思想はPDF、設定は公式ドキュメント」が読み方の結論です。

今日から始める3つのアクション

1. 今日：PDF本体を開き、自部門に近いチームの2ページだけ読む（管理部門なら21〜22ページ、マーケティングなら15〜16ページ、情報システムなら3〜4ページ、開発部門の管理者なら5〜6ページ）。
2. 今週中：プロンプト1で自部門の「APIがある反復作業」を棚卸しする。候補が1つでも出たら、プロンプト2で手順書を整える。
3. 今月中：機微データを扱うなら、プロンプト5でアクセス境界の案を作って情報システム部門と擦り合わせる。あわせて初回セットアップの伴走枠を展開計画に書き込む。

あわせて読みたい：

• Claude Code法人導入｜Team比較・稟議テンプレ・FAQ【2026】 — 稟議とセキュリティ要件の詰め方
• Claude Code Agent Teamsの使い方｜並列実行【2026】 — PDFの「サブエージェント」の現行仕様側
• Claude Code Teamプラン｜料金・最低2名から【2026年9月】 — 契約プランとしてのTeamの選び方

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計50,000部突破）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。