Claude Teams 完全ガイド｜複数チーム・多部署で Claude を回す非エンジニアの運用設計 2026年4月版

「半年前はマーケ部5人だけでClaude Teamを試していたのですが、気づけば営業・制作・企画・経理・総務まで合わせて30人が使うようになってきました。各部署が勝手にプロジェクトを作り、同じ顧客情報を別々のチャットに貼り付けていて、このまま増やし続けて大丈夫なのか心配です。Workspaceをもう1つ契約すべきか、それとも今の1つのWorkspaceの中で整理するべきか、誰にも相談できないまま放置しています」——30人規模の広告制作会社の経営者、50人の税理士法人のパートナー、80人規模の建築設計事務所のDX担当、病院内のバックオフィス統括担当。2026年4月に入ってから、こうした「1チームから複数チームへ」の相談が目に見えて増えてきました。

結論から書きます。Claude Teams（複数形で検索されるこの言葉）は、プラン名の表記揺れを指すこともありますが、2026年4月時点の実務で最も切実なのは、1つの契約（Workspace）で複数チーム・多部署を回す運用設計の話です。この領域は、Anthropic の公式ドキュメントにも薄くしか書かれておらず、国内の日本語情報もほとんど整理されていません。本記事では、20〜100人の中堅企業で「1部署の成功を全社に広げたい」段階にあるあなたのために、運用の設計図と60日の実行計画を一本にまとめました。

なお、既に「Claude Team プラン自体が何か」から知りたい方は、先に関連記事661（Claude Team とは）を読んでから本記事に戻ってくるのが近道です。本記事は、単一チームでの導入は完了している前提で、そこから先の複数チーム・多部署運用に焦点を絞っています。

注: 本記事の画面操作・料金・機能は2026年4月19日時点の Anthropic 公式情報（claude.com / docs.claude.com / anthropic.com/pricing）を参照した目安です。実運用の前に最新の公式ページを確認してください。

この記事で分かること

  • 「Claude Teams」と「Claude Team」は別物なのか、同じものなのか（呼称の整理）
  • 複数チーム運用の3パターン（1 Workspace内 Projects分離・複数 Workspace契約・親子会社別運用）の選び方
  • Workspaceを分けるべき5つの判断軸（情報境界・管理責任・請求独立性・ガバナンス・監査要件）
  • 1 Workspace複数チームでの Projects 設計と命名規則
  • 多部署展開の60日ロードマップ（20〜100人規模、非エンジニア3人体制を想定）
  • 部署別の利用ガイドライン雛形（営業・制作・企画・経理・総務・人事・法務）
  • 非エンジニアが多部署展開でハマる10の疑問と答え

記事末尾に、本記事の運用設計をそのままチェックリスト化した「Claude はじめての使い方ガイド PDF」を特典として無料配布します。

ここから先は本論です

第1章 「Claude Teams」と「Claude Team」は別物か——呼称の整理

最初にこの疑問を片付けておきます。後の章の理解がかなり楽になります。

公式プラン名は単数形「Claude Team」

2026年4月19日時点で、Anthropic が公式にプラン名として使っているのは単数形の Claude Team（クロード・チーム）です。anthropic.com/pricing にも claude.com/team にも、複数形の Claude Teams という公式プラン名は存在しません。

それでも「Claude Teams」が検索される3つの理由

公式プラン名は単数形なのに、複数形で検索する人が多いのには背景があります。

  1. 表記揺れ: 英語では Microsoft Teams や Google Workspace のように複数形・集合名詞の製品名が多いため、条件反射で Teams と入力する方が一定数います
  2. 複数チーム運用の検索: 1チームの導入は終わっていて、次の段階として複数チーム運用の情報を探している方が、自然に Teams と複数形で検索する
  3. 他社製品との混同: Microsoft Teams・Google Meet・Slack の連携機能を調べるときに、「Claude Teams 連携」のような形で検索する

本記事は、このうち2番目の「複数チーム運用」に焦点を合わせています。1と3の方は、関連記事661と703（Claude と Microsoft Teams 連携）をご覧ください。

用語の整理（以降の章で使います）

以降の章では、次の用語を区別して使います。最初に整理しておきます。

  • プラン: Anthropic との契約形態。Free / Pro / Team / Enterprise の4種類
  • Workspace（ワークスペース）: Team / Enterprise プランで作る、会社やチームの箱。1契約 = 1 Workspace が基本
  • Team（チーム）: Workspace の中で、部署・プロジェクトごとに区切る単位（機能としては Projects に近い概念）
  • Projects（プロジェクト）: 特定の案件・顧客・業務に関連する資料・会話・指示をまとめる機能
  • メンバー: Workspace に招待された個人（社員・外部パートナー）

「Claude Teams」と検索してきたあなたが実際に扱うのは、多くの場合「1つの Workspace の中に、複数の部署・Team・Projects が同居する状態をどう整理するか」という問題です。

第2章 複数チーム運用の3パターン

20〜100人規模の中堅企業が取りうる、複数チーム運用の3パターンを整理します。自社がどれに当てはまるかを、この章で決めてください。

パターン1: 1 Workspace内 Projects分離（推奨・最もシンプル）

1つの Workspace（1つの契約）の中で、部署・業務ごとに Projects を作って情報を分ける方法です。20〜50人規模の中堅企業で最も採用されるパターンです。

採用する会社の特徴:

  • 部署は分かれているが、同じ経営者・同じ管理部門が全社を見ている
  • 扱う情報の機密レベルに極端な差がない（一般業務の範囲）
  • IT管理の担当者が1〜2人で、Workspaceを複数管理するリソースがない
  • 社員全員が同じ会社に所属している（グループ会社を含まない）

メリット: 契約・請求・管理が1本化される。Workspace間の情報移動が不要。メンバーが複数の部署に兼務しても、ログイン先が1つ。

デメリット: 部署間の情報境界を技術ではなくルールで守る必要がある。退職者処理も1箇所でまとめて行う必要がある。

パターン2: 複数 Workspace契約（中堅〜大企業・グループ会社向け）

部署単位または機能単位で、複数の Workspace を別々に契約する方法です。50〜100人規模や、グループ会社・事業部制の会社で採用されます。

採用する会社の特徴:

  • 部署・事業部ごとに独立した予算とIT管理権限がある
  • 扱う情報の機密レベルが部署ごとに大きく異なる（人事・法務と一般業務で隔離したい）
  • 事業部別・子会社別の会計で、請求を分けたい
  • 各部署にITリテラシーの高い担当者がいる

メリット: 情報境界が技術的に保証される。部署ごとに独立した管理責任。請求の独立性。

デメリット: 契約・請求・アカウント管理が複数になる。Workspace間の情報移動はコピー＆ペースト頼み。最低5席×契約数の最低料金が発生する。

パターン3: 親子会社別運用（グループ経営・M&A後）

親会社・子会社で別々の Workspace を契約し、情報境界を厳格に保つ方法です。グループ経営の会社や、M&A で買収した子会社を統合途中の会社が採用します。

採用する会社の特徴:

  • 親子会社間で、法務・契約・知財の情報を絶対に混ぜてはいけない
  • 子会社独自の顧客情報があり、親会社のメンバーが見られては困る
  • 子会社が将来的に独立運営になる可能性がある
  • 上場準備中で、グループ内の情報管理について監査法人から指摘を受けている

メリット: 情報境界が法務的にも明確になる。買収・売却・分社化に強い設計。

デメリット: 契約管理・請求管理が完全に分離される。グループ共通ナレッジを両方の Workspace で二重管理する必要がある。

第3章 Workspaceを分けるべき5つの判断軸

パターン1（1 Workspace）で始めるか、パターン2・3（複数 Workspace）で始めるか。この章で判断軸を提示します。

判断軸1: 情報境界の要件

「この情報は、A部署の人は見てよいが、B部署の人は絶対に見てはいけない」という情報境界が、社内に明確に存在するか。

  • はい（例: 人事の査定資料、法務の訴訟情報、経営企画のM&A資料）→ Workspace分離を検討
  • いいえ（全社員が見て問題ない業務情報が中心）→ 1 Workspaceで Projects 分離で十分

判断軸2: 管理責任の分離

IT管理者・利用統括者を、部署・事業部ごとに別々に置く必要があるか。

  • はい（事業部制の会社、グループ経営）→ Workspace分離で管理権限も分離
  • いいえ（本社IT部門が一元管理）→ 1 Workspaceで十分

判断軸3: 請求の独立性

部署別・事業部別・子会社別の会計で、Claudeの利用料を請求書ごとに分ける必要があるか。

  • はい（事業部別P/L、グループ会計、監査法人の指摘）→ Workspace分離で請求も分離
  • いいえ（本社経費として一括計上で問題ない）→ 1 Workspaceで十分

判断軸4: ガバナンスの層

社内の規定・コンプライアンス要件が、部署ごとに異なるか。

  • はい（金融関係の部署だけ厳格な監査ログが必要、医療系の部署だけPHI対応が必要）→ Workspace分離
  • いいえ（全社共通のガイドラインで運用できる）→ 1 Workspaceで十分

判断軸5: 監査・認証要件

社外の監査・認証（ISO 27001 / ISMS / Pマーク / 上場準備）において、Claudeの利用範囲を部署ごとに分けて説明する必要があるか。

  • はい（上場準備、官公庁案件、金融機関との取引）→ Workspace分離が安全
  • いいえ（一般的な商取引の範囲）→ 1 Workspaceで十分

判断軸の合成ルール

5つの判断軸のうち、3つ以上で「はい」に当てはまる場合は、Workspace分離（パターン2または3）を真剣に検討してください。2つ以下の「はい」なら、1 Workspaceでスタートし、運用しながら必要に応じて分離を検討するのが実務的です。

多くの中堅企業は、1〜2つの「はい」に当てはまる程度です。この場合は、1 Workspace内で Projects 分離と利用ガイドラインでカバーできます。最初から複数 Workspaceにすると、管理コストが運用メリットを上回ることが多いです。

第4章 1 Workspace複数チームの Projects 設計

パターン1（1 Workspace）を選んだあなた向けに、Projects の設計図を具体的に提示します。この章が本記事の設計図の核です。

命名規則の基本形

Projects の名前は、「部署コード＋業務種別＋具体名」の3要素で統一するのがおすすめです。例を示します。

  • SL_提案_A社プロジェクト（営業 Sales の提案業務、A社向け）
  • MK_競合調査_2026Q2（マーケティング Marketing の競合調査、2026年第2四半期）
  • AC_月次決算_2026年4月（経理 Accounting の月次決算、2026年4月分）
  • HR_採用_中途エンジニア2026春（人事 Human Resources の採用、中途エンジニア2026年春募集）
  • LG_契約レビュー_B社NDA（法務 Legal の契約レビュー、B社NDAドキュメント）

部署コードは、英字2文字で統一します（SL / MK / AC / HR / LG / GA総務 / IT / SA管理 など）。これだけで、Projects一覧画面で「自部署のもの」「他部署のもの」が一目で判別できます。

3層構造のナレッジ設計

Projects の中身（Knowledge と Instructions）を、3層構造で整理します。

  • 第1層 全社共通: 会社概要、ブランドガイドライン、社員名簿、経営理念、禁止ワードリスト
  • 第2層 部署共通: 各部署の業務標準、定型テンプレート、過去の成功事例、よくある質問集
  • 第3層 案件別: 特定顧客の情報、特定プロジェクトの議事録、進行中の提案内容

第1層は「全社共通Project」として1つ作り、全員に閲覧権限を与えます。第2層は部署別に1つずつ。第3層は案件ごとに担当者が作る。この3層ルールを徹底すると、同じ情報の重複投入がほぼゼロになります。

情報の縦横ルール

Projects の権限は「縦と横」の2軸で考えると整理しやすくなります。

  • 縦の軸: 全社共通（全員参照可）→ 部署共通（部署メンバーのみ）→ 案件別（担当者のみ）
  • 横の軸: 営業・マーケ・制作・経理・総務・人事・法務・経営企画

縦方向は機密度、横方向は業務領域、と覚えてください。この2軸で整理された Projects は、入社3日目の新人でも迷わずにたどり着けます。

よくある設計ミスと回避策

複数チーム運用で最もよく見る設計ミスを3つ挙げておきます。

  1. 全社共通Projectに何でも入れてしまう: ブランドガイドだけの予定が、気づけば個別の顧客情報まで入り、機密境界が崩壊する。対策: 全社共通には「全員が見て問題ないか」を必ず確認してから投入するルール化
  2. 案件別Projectが量産されて管理不能になる: 100件を超える案件Projectが並ぶと、検索性が極端に落ちる。対策: 月次で「完了した案件Project」をアーカイブに移す運用
  3. 部署コードが未統一: 営業がSales、営業部、SL、営などと混在し、検索で引っかからない。対策: IT担当が最初にコード表を作り、全社員に配布

第5章 多部署展開の60日ロードマップ

ここは実行部分です。1部署での運用が完了した会社が、2〜3ヶ月で全社展開するための時系列プランを示します。

Day 0（起点）

既に1部署（5〜10人）で1ヶ月以上の運用経験があり、利用ガイドラインと基本的なProjectsが整っている状態を起点にします。ここがスタート地点です。

Day 1〜14（第1期・最初の横展開）

やること:

  • 起点部署の成功事例を5つまとめる（プロンプト例、削減時間、具体的な成果）
  • 次に展開する部署を1つだけ選ぶ（営業から制作、経理から総務などの隣接部署が無難）
  • 新部署のキーパーソン2人をピックアップし、起点部署のメンバーとペアを組ませる
  • ペアで2週間、週1回30分のOJT（on the job training：実務の場で教える方式）

この期間のゴール: 新部署のキーパーソン2人が、自部署向けの実務プロンプトを5本作れる状態。

Day 15〜30（第2期・新部署の定着）

やること:

  • 新部署のキーパーソン2人が、同部署のメンバー3〜5人に展開
  • 起点部署と新部署で合同の振り返り会（60分）を1回実施
  • 両部署で使える横断Projectsを1つ作る（例: 顧客共有、社内通達要約）
  • 利用ガイドラインに、両部署の経験を反映した改訂版を出す

この期間のゴール: 2部署で合計15〜20人が日常的にClaudeを使っている状態。

Day 31〜45（第3期・3部署目以降の連鎖展開）

やること:

  • 3部署目・4部署目を同時に立ち上げ（2部署並行で負荷分散）
  • 既存2部署のキーパーソンが、新部署の指南役になる連鎖展開モデル
  • 全社共通Projectsの整備（社員名簿、ブランドガイド、経営理念など）
  • 月次の利用状況レビュー会を定例化（管理者ダッシュボードの数字を共有）

この期間のゴール: 4部署で30〜40人が利用、全社共通Projectsが稼働。

Day 46〜60（第4期・全社標準化と最後の部署の取り込み）

やること:

  • 残る部署（経営企画・総務・法務など）を一気に取り込む
  • 部署別ガイドラインを全部署分そろえる（第6章の雛形を参考に）
  • 全社員向けの「Claude 使い方入門」を30分の動画または対面研修で実施
  • 3ヶ月後の定量評価計画を策定（削減時間・使用回数・満足度の3指標）

この期間のゴール: 全部署で50〜80人が利用、ガイドラインと研修体制が揃う。

Day 61以降（定着と改善の継続）

  • 月次のレビュー会を継続（60分・部署横断）
  • 3ヶ月に1回、プロンプト集の棚卸しと更新
  • 半年後に Enterprise プランへの移行検討（社員50人超・SSO必須などのサインが出たら）

第6章 部署別の利用ガイドライン雛形

多部署展開で最もよく聞かれるのが、「部署ごとにガイドラインを出し分けるべきか、共通1本で済ますべきか」という疑問です。答えは、全社共通の骨格1本＋部署別の追加1〜2行、が運用しやすいバランスです。

全社共通の骨格（A4 1枚）

以下の5項目を、A4 1枚にまとめて全社員に配布します。

  • 入力してよい情報の範囲: 社内資料、一般公開資料、業務メール、議事録
  • 入力してはいけない情報: マイナンバー、個人のクレジットカード番号、顧客の個別財務情報、未公開のM&A情報
  • 出力物の確認ルール: 重要文書は必ず人間が読み返してから社外に出す
  • 問い合わせ窓口: 社内DX担当・情シス
  • 違反時の対応: 初回は注意、2回目は利用停止、3回目は人事評価に影響

部署別の追加ルール例

各部署の業務特性に応じて、共通骨格に1〜2行を追加します。

営業部: 顧客の契約書・見積書の全文投入は、顧客からの事前同意を得てから行うこと。

マーケティング部: 競合他社の非公開資料（漏洩資料・未公表情報）を入力してはならない。公開情報のみを扱う。

制作部: 著作権のある画像・テキストを無断で入力し、改変した出力物を納品物に流用してはならない。

経理部: 個人のマイナンバー、銀行口座、印鑑登録証明書の画像を入力してはならない。

総務部: 就業規則・規程集の改訂前ドラフトをClaudeに入力する場合、人事・法務に事前相談してから行う。

人事部: 個別の社員の査定情報・健康情報を入力してはならない。一般化した事例検討のみ可。

法務部: 進行中の訴訟、未締結の契約書、係属中の審判の情報を入力する場合、個別の明示承認を得る。

経営企画部: M&A、新規事業、組織改編の未公表情報を入力する場合、役員の明示承認を得る。

部署別ガイドラインを作るときの注意

過剰な禁止事項を並べると、現場が萎縮してClaudeを使わなくなります。禁止は「絶対にダメな数個」に絞り、残りは「迷ったら相談」にしておくのが、利用定着とリスク管理のバランスを取る実務のコツです。

第7章 非エンジニアが多部署展開でハマる10の疑問

実際の相談で特に多い、多部署展開の疑問10問をまとめました。

Q1: 1 Workspace内で、他部署のProjectsは見えてしまいますか

A: デフォルトでは、WorkspaceのメンバーはPublic（公開）にしたProjectsを全員見られます。Private（非公開）に設定すれば、招待されたメンバーだけがアクセスできます。部署別Projectsは、基本的にPrivateで作成し、必要な部署メンバーだけを招待する運用が安全です。公開範囲の設定は、Project作成時または後からでも変更可能です。

Q2: メンバーが複数部署に兼務している場合の運用は

A: 1人のメンバーが複数の部署別Projectsに招待される形で問題ありません。個人のアカウントは1つのまま、所属部署の数だけProjectsへのアクセス権を持つ、という状態になります。兼務が解除になった場合は、該当するProjectsから手動で外してください。自動削除機能は2026年4月時点では存在しません。

Q3: 退職者のアカウントはどう処理しますか

A: 管理画面からRemove memberで削除します。削除すると、そのメンバーが作ったProjectsは管理者にオーナー権限が移る設定と、削除される設定があります（Workspaceの設定で選択可）。退職者処理のSOP（業務手順書）を事前に作っておくと、毎回の判断に迷いません。人事部・IT部・業務部署の3部門で合意形成してから本運用に入るのが安全です。

Q4: 部署間でProjectsの情報を共有したい場合は

A: 3つの選択肢があります。

  1. Projectのオーナーが、他部署のメンバーを追加招待する（最もシンプル）
  2. 横断Projectsを新設し、必要な情報をコピー＆ペーストで集める（情報の所有権を明確にしたい場合）
  3. 全社共通Projectsに昇格させる（全員が参照してよい情報と判断した場合）

現場で最もよく使われるのは1番です。2番と3番は、情報のライフサイクル管理をきちんとしたい場合に使います。

Q5: 席数は部署ごとに管理できますか

A: 2026年4月時点の Team プランでは、席数は Workspace 単位の管理で、部署ごとの席数割り当ては公式機能としては用意されていません。社内のルールとして「営業部10席、制作部8席」のような運用を管理者が手動で守る形になります。部署ごとの厳格な席数管理が必須の場合は、パターン2（Workspace分離）を検討してください。

Q6: 管理者（アドミン）は複数人にすべきですか

A: 管理者は2〜3人にすることを強くおすすめします。1人だと、その人が休暇・病欠・退職したときにロックアウトのリスクがあります。典型的な構成は「社長（兼務）＋IT担当＋DX推進担当」の3人体制です。全員が日常的に管理画面を触る必要はありませんが、鍵を3人で共有しておくことで、組織の安全性が一段上がります。

Q7: 料金は部署別に按分できますか

A: 請求書は Workspace 単位で1通出ます。部署別の按分は、請求書を受け取った経理側で、席数比率や利用実績比率に応じて内部振替伝票を切る運用になります。按分ルールは事前に経理と合意しておくと、月次処理が揉めません。按分の厳密性を重視するならパターン2（Workspace分離）が適します。

Q8: 外部パートナー（税理士・社労士・外注先）を招待してよいですか

A: 招待自体は可能ですが、情報管理の観点から慎重な運用が必要です。外部パートナー用に専用Projectsを作り、共有する情報を限定する形が安全です。社内メンバーが全Projectsにアクセスできるのに対し、外部パートナーは特定のProjectsだけ、という権限設計にしてください。NDA（秘密保持契約）の締結は当然の前提です。

Q9: 利用状況を部署別に集計できますか

A: 管理者ダッシュボードでは、メンバー単位の利用概要が見られます。部署別の集計は、メンバー名簿と部署所属を社内で突合する作業が必要です。Googleスプレッドシートで部署別の集計表を作り、月次で管理者がダッシュボードの数字を転記する、という運用が実務的です。API経由での自動集計は、Enterprise プラン相当の機能になります。

Q10: Enterprise プランに切り替えるタイミングは

A: 次のサインが2つ以上出たら、Enterprise 見積もりを取る段階です。

  • 社員50人を超えて Claude を利用
  • SSO（Single Sign-On：社内認証基盤で Claude にログイン）が必須要件になった
  • 監査ログ（誰がいつ何を使ったかの記録）が法令・認証上必要
  • 専任カスタマーサクセス・SLA・MSA（基本契約書）対応が必要

Team プランで1年以上の運用実績を積んだうえで Enterprise に上がると、移行がスムーズです。詳細は関連記事524（Teamプランと Enterpriseプラン どちらを選ぶ）を参照してください。

第8章 今日からの3ステップアクション

本記事の内容を、明日から動けるアクションに落とし込みます。

ステップ1: 今週、自社が3パターンのどれに当たるかを判定

第3章の5つの判断軸に、自社の状況を書き込んでください。

  • 情報境界の要件（はい/いいえ）
  • 管理責任の分離（はい/いいえ）
  • 請求の独立性（はい/いいえ）
  • ガバナンスの層（はい/いいえ）
  • 監査・認証要件（はい/いいえ）

3つ以上「はい」ならパターン2または3（Workspace分離）、2つ以下なら パターン1（1 Workspace）です。判定結果を1枚のメモにまとめ、経営陣と共有してください。

ステップ2: 今月中に、Projects の命名規則と3層ナレッジ構造を確定

第4章で示した部署コード2文字＋業務種別＋具体名のルールを、自社の部署構成に合わせて決めてください。IT担当またはDX推進担当が、A4 1枚のコード表を作成し、全部署の管理職に共有します。コード表の合意が取れたら、既存Projectsの命名を新ルールに揃える棚卸し作業を実施します。

ステップ3: 来月から第5章の60日ロードマップを開始

起点となる部署が既に1ヶ月以上の運用経験を持っているかを確認し、持っているなら翌月からDay 1〜14の第1期を開始します。運用経験がまだなら、まずは関連記事661（Claude Team とは）を参考に、単一部署での1ヶ月運用を先に済ませてください。1部署の成功なしに多部署展開に進むと、失敗事例が社内に伝播して一気に定着が遠のきます。

まとめ

本記事の要点を5行でまとめます。

  • 「Claude Teams」の検索は、プラン名の表記揺れと複数チーム運用の問合せが混在。本記事は後者にフォーカス
  • 複数チーム運用は3パターン。1 Workspace内 Projects 分離（推奨）、複数 Workspace契約、親子会社別運用
  • Workspace分離は5つの判断軸（情報境界・管理責任・請求独立性・ガバナンス・監査）のうち3つ以上はいなら検討
  • 1 Workspace複数チームでは、部署コード2文字の命名規則と3層ナレッジ設計（全社共通・部署共通・案件別）が成功のカギ
  • 多部署展開は60日ロードマップで進める。1部署の成功を起点に、隣接部署→連鎖展開→全社標準化の順

1部署での導入成功は、多部署展開のスタートラインにすぎません。本記事の設計図が、あなたの会社の全社展開の足場になれば幸いです。

🎁 特典 Claude はじめての使い方ガイド PDF

本記事の内容を、明日からデスクに置ける1冊の PDF（A4・8ページ）にまとめて無料配布しています。

  • A4・8ページ、印刷前提レイアウト
  • 複数チーム運用の3パターン判定シート（5つの判断軸のチェックボックス付き）
  • Projects 命名規則テンプレート（部署コード表 A4 1枚）
  • 3層ナレッジ設計のサンプル（全社共通・部署共通・案件別の具体例）
  • 60日ロードマップ チェックリスト（Day単位のタスク一覧）
  • 部署別ガイドライン雛形（7部署分）
  • 多部署展開で10の疑問の回答カード

ダウンロードはこちら: /resources

📚 参考リファレンス

  • Anthropic 公式: claude.com / anthropic.com / docs.claude.com
  • Claude Team プラン情報: claude.com/team
  • 料金ページ: anthropic.com/pricing
  • Trust Center（セキュリティ・プライバシー）: claude.com/trust-center
  • 関連記事: Claude Team とは｜非エンジニアの中小企業が月4,500円×人数で始めるチーム導入完全ガイド 2026年4月版（記事661）
  • 関連記事: Claude Pro Team どっち 選び方｜社員10〜100人の中小企業の社長が5分で決める判断フレーム 2026（記事641）
  • 関連記事: Claude の Team プランと Enterprise プラン、中小企業はどちらを選ぶ？（記事524）
  • 関連記事: Claude Cowork とは｜非エンジニアの最初のガイド（記事503）
  • 関連記事: Claude 料金プラン完全ガイド｜個人・チーム・法人プランの選び方（記事506）
  • 関連記事: Claude に社内情報を入れても大丈夫？（記事512）
  • 関連記事: AI を社内で使うならルールが先｜中小企業の社長が最初に決めるべきガイドライン5項目（記事523）

最終更新: 2026年4月19日 / 公開: 2026年4月19日