Claude Code 法人導入の相談で、私が最も多く聞く言葉があります。
「入れてはみたんですが、誰がどこまで触っていいのか決まっていなくて」。

インストールは済んでいます。
ライセンスも通っています。
それでも止まっている。
決まっていないのは手順ではなく、その前の7つでした。

法人のClaude Code導入は「インストールできた」では終わらない

個人利用の延長で始めると、権限と運用が曖昧なまま広がる

個人で使っていて便利だったから会社にも入れる、という順路はごく自然です。
そして、この順路がいちばん危ない。

個人利用では、扱うデータも権限も自分の判断ひとつで済みます。
会社に入れると、その判断が「誰の判断だったのか」を後から説明できなくなります。
顧客の個人情報を渡してよかったのか。
外部へ送信するコマンドを実行してよかったのか。
削除は誰の承認で走ったのか。

導入担当者が最初にぶつかるのはここです。
技術的に動かないのではなく、動かしてよいかが決まっていない。

Re-railが使っている7工程の全体像

私がセットアップ支援で使っている順序は次の7つです。

1. 導入目的と対象業務を1〜2件に絞る
2. 扱ってよいデータと、入力してはいけない情報を分類する
3. 読み取り・編集・外部送信・削除・公開の権限を分ける
4. 端末、アカウント、対象フォルダ、バージョン、拡張機能を揃える
5. CLAUDE.mdへ会社固有の用語、禁止事項、成果物形式、確認工程を書く
6. 入力・処理・出力・例外・人の確認を含む完了判定テストを行う
7. 利用開始後に、止まった場面、手作業へ戻った場面、問い合わせを記録して改善する

順序には理由があります。
目的が絞れていないとデータ分類ができず、データ分類ができていないと権限を決められません。
そして権限が決まっていないと、完了判定テストの合格条件が書けない。
後ろの工程は、前の工程の答えを材料にしています。

にもかかわらず、実際の導入は環境構築から始まることが多い。
インストールとライセンス手配は手を動かせば進むので、着手感があるからだと思います。
目的の絞り込みは会議を開かないと決まらず、データ分類は情報管理規程を読み直さないと書けない。
つまり、順序が逆になるのは怠慢ではなく、進みやすいところから進んでいるだけです。
その代償がどこで請求されるのかは、工程6の完了判定まで来ると一気に見えてきます。

この記事の完了条件：現場担当者が再現できること

完了の基準は「インストールできた」ではありません。
現場の担当者が同じ手順で同じ結果を再現でき、問題が起きたときに人へ戻せることまでを含みます。

導入担当者が動かせる状態は、まだ通過点です。
その人が休んだ日に業務が止まるなら、導入は終わっていません。

Anthropicの公式Enterprise管理者ガイドも、技術セットアップ／チェンジマネジメントと立ち上げ／イネーブルメントと研修／定着のスケールという4フェーズ構成を取っています（claude.com/resources/tutorials/claude-enterprise-administrator-guide、2026年8月4日確認）。
技術作業のあとに、わざわざ3フェーズ分の定着作業を置いている。
公式が想定している完了地点も、インストールの先にあります。

なお、各社のセキュリティ要件は異なります。
この記事だけで導入可否を判断せず、自社の情報管理規程と公式ドキュメントで最終確認する前提で読んでください。

最初の1週間の進め方（対象業務を1件に絞った場合）

会議体をどれだけ確保できるかで前後しますが、1件に絞った場合の目安として次の配分で組んでいます。

• 1日目：対象業務を1件決め、成果物の形（見出し構成まで）を業務担当者と紙に書く
• 2日目：入力してよい情報／要承認／入力禁止の3分類を、自社の情報管理規程と突き合わせて確定する
• 3日目：5種類の権限の可否と、一次承認者と代理を人名で決める
• 4日目：環境一覧（対象フォルダ・バージョン・拡張機能・アカウントとプラン）を1枚にまとめ、マネージド設定とpermissions、必要なフックを入れる
• 5日目：CLAUDE.mdを5要素で書き、導入担当者が通しで一度動かす
• 6〜7日目：現場担当者が手順書だけで完了判定テストの5観点を実施し、出た質問を手順書へ反映する

この配分どおりに進まないこと自体は問題ではありません。
どこで止まったかが、そのまま「自社で決まっていない項目」の一覧になります。

【工程1・2】導入目的を1〜2業務に絞り、扱ってよいデータを分類する

対象業務を1〜2件に絞る理由

「業務効率化のために導入します」。
稟議書ではこれで通ります。
現場では、これでは何も始まりません。

目的が「業務効率化」のままだと、完了判定が作れないからです。
何ができたら成功なのかが言えない。

成果物の形が言える単位まで落とします。
「議事録の音声書き起こしから、社内フォーマットの議事メモの下書きを作る」。
「既存の請求処理コードに、境界値のテストを書き足す」。
このくらいまで絞ると、出力を見た瞬間に合否が判定できます。

絞る対象は1〜2件で足りる、というより1〜2件にすべきです。
5件並べると、データ分類も権限もその5件分の和集合になります。
範囲が広がった分だけ、決めるべきことが増えて止まります。

入力してよい情報と入力してはいけない情報を先に書き出す

データ分類でつまずくのは、「機密かどうか」で分けようとするときです。
社内のほとんどの情報は、程度の差はあれ機密です。
それでは線が引けません。

分ける基準は「Claude Codeに入力してよいか」の一点にします。
顧客の個人情報、認証情報、契約書の原本は、入力禁止として明文化する。
判断が分かれるものは、承認者を決めて例外扱いにする。

この表は一般例です。
実際の分類は自社の情報管理規程に合わせて作り直してください。

入力したデータがどこに残るかを確認する

保持の扱いはプランで違います。
公式のデータ利用ページは、消費者向け（Free/Pro/Max）について、改善利用を許可した場合5年、許可しない場合30日の保持と整理しています。
商用（Team/Enterprise/API）は別扱いです（code.claude.com/docs/en/data-usage、2026年8月4日確認）。

ゼロデータ保持（ZDR）は、Enterpriseに自動で付く機能ではありません。
条件を満たすアカウントへ提供される申請制の仕組みで、アカウントチームが適格性を確認したうえで組織単位で有効化します。
同一アカウント配下に新しく作った組織へは自動適用されません。
部署ごとに組織を分けている場合、ここは必ず確認が必要になります。

見落としやすいのはローカル側です。
公式ドキュメントは、セッション記録が既定で一定期間ローカルに保存され、cleanupPeriodDays で変更できると記載しています。
サーバー側の保持設定を詰めても、端末に記録が残っていれば、端末の管理が情報管理の対象に入ります。

【工程3】権限を読み取り・編集・外部送信・削除・公開の5つに分ける

5種類の権限を分けて考える

権限を「使える／使えない」の2択で考えると、たいてい「使える」に倒れます。
使えないと導入した意味がないからです。

そこで、5つに分けます。
読み取りはファイルやデータを読むこと、編集はファイルを書き換えること、外部送信は社外のサービスへデータを送ること、削除はファイルやデータを消すこと、公開は社外から見える場所へ出すことです。

読み取りと編集は、対象フォルダを絞れば既定で許可してよい場面が多くあります。
一方、外部送信と公開は承認者を人に固定します。
この2つは、間違えたときに社内で取り返せません。

• 読み取り：対象フォルダ内は既定で許可。範囲は設定で固定し、範囲外は導入担当者が判断する
• 編集：対象フォルダ内は既定で許可。変更履歴で追跡し、共有フォルダの書き換えは業務責任者が承認する
• 外部送信：既定で禁止。業務責任者の個別承認とし、送信先と内容を記録する
• 削除：実行前に確認を挟み、実行者本人が対象を確認する。復元手段がない対象は禁止
• 公開：既定で禁止。業務責任者と、広報または法務の承認を必須にする。例外を作らない運用が無難

もっとも、この5分割が唯一の正解だとは思っていません。
承認の回し方が重い会社では、削除を業務のなかで一律禁止にして、消す作業だけ人の手に残したほうが早く回り始めることもあります。
分け方より、「どの操作を誰の名前で承認したか」が後から言えるかどうかが本題です。

マネージド設定は開発者のローカル設定より優先される

権限を決めたら、どこに書くかが問題になります。
各自の端末で設定してもらうと、設定した人としない人が混ざります。

公式のadmin-setupページは、組織ポリシーをマネージド設定によって適用し、これがローカルの開発者設定より優先されると明記しています。
配布経路はClaude管理コンソール、MDM、ディスク上のファイルの3つです（code.claude.com/docs/en/admin-setup、2026年8月4日確認）。

マネージド設定で制御できるのは、Claudeが到達できるツール・コマンド・サーバー・ネットワーク宛先です。
ツール権限、ファイルアクセス制限、MCPサーバー構成を全ユーザーへ適用できます。
なお本記事で permissions と書いているのは、Claude Codeの設定ファイル内で、どのツールやコマンドを許可・確認・禁止にするかを列挙する仕組みを指します。
MCPサーバーとは、Claude Codeが外部のツールやデータへつなぐための接続先の仕組みです。
ここを開けたままにすると、想定していない外部サービスへ手が届きます。

設定の層は複数あり、優先順位の説明は公式ドキュメント内でも複数ページにまたがります。
細かい上下関係は、設計時に公式の該当ページで確認してください。

誰が承認するかを決めておく

承認者は役職ではなく人で決めます。
「部門長が承認」と書くと、部門長が不在の日に止まります。
一次承認者と、その代理を名前で決めておく。

もうひとつ、退職者のアカウント棚卸しを手順化しておきます。
SSO・SCIM・席の割り当てはClaude Codeの設定ではなく、Claudeアカウント側で設定します（前掲admin-setup）。
SCIMは、人事側のアカウント情報とサービス側のアカウントを自動で同期する仕組みです。
これを前提にしておくと、退職処理の中でClaude Codeの席も回収されます。

【工程4】端末・アカウント・プラン・バージョンを揃える

個人プランの混在を先に解消する

導入前の洗い出しで、私がいちばん高い頻度で見つけるのがこれです。
個人プラン（Pro/Max）のまま業務で使っている人がいる。

悪意はありません。
先に自分で試していた人ほど、そうなっています。
そして、この混在は「契約の問題」として発覚しないところが厄介です。
先に出るのは、同じ指示なのに人によって出力が違う、参照できるファイルが違う、といった症状のほうで、原因の切り分けを始めてから「そもそも別プランで動かしていた」と分かります。
前述のとおり消費者向けプランは改善利用を許可した場合5年の保持と整理されており、業務データを入れる前提の話ではありません。

導入計画を書く前に、誰がどのアカウントで使っているかを一覧にしてください。
ここを飛ばすと、商用プランを契約したあとも個人プランのまま使い続ける人が残ります。

TeamとEnterpriseの違いは席と管理機能

プランの選択は、席数と必要な管理機能で決まります。
2026年8月4日の確認時点では、Enterpriseは1席あたり月20ドル＋API料率の従量課金、年額請求、最低20席と案内されていました。
Teamの全機能に加えてSCIM・監査ログ・カスタム保持・ロールベースアクセスが付き、Teamは最大150席で超える場合はEnterpriseへ移行します（claude.com/pricing および公式ヘルプ、同日確認）。
同時点で、Chat-only席とStandard／Premium席は新規契約では提供終了し、既存契約も次回更新時に単一のEnterprise席モデルへ移行すると案内されています。
Teamの最低席数と、Team各席でのClaude Code利用可否は、契約前にclaude.com/pricingと公式ヘルプで要確認です。

価格は税別で、Anthropicの裁量で変更されうると公式に注記されています。
ここに挙げた金額と席数も、あくまで確認日時点のスナップショットとして読んでください。
社内資料には具体値を固定で書かず、確認日と公式URL、そして見積での再確認をセットにしておくのが安全です。

対象フォルダとバージョン、拡張機能を揃える

環境が揃っていないと、同じ指示で違う結果が出ます。
そして「誰かの環境だけ動く」状態になります。

揃えるのは4つです。
対象フォルダ、Claude Codeのバージョン、使う拡張機能、そしてアカウントとプラン。
完了判定テストの前提として、この一覧を1枚にまとめておきます。

テストで不合格が出たとき、原因が手順なのか環境なのかを切り分けるために使います。
この1枚がないと、切り分けの前に環境の聞き取りから始めることになります。

【工程5】CLAUDE.mdに用語・禁止事項・成果物形式を書く

CLAUDE.mdは設定ではなく文脈として読まれる

ここが、法人導入でいちばん誤解されている箇所です。

CLAUDE.mdは、Claude Codeが会話の開始時に読み込むファイルです。
社内ルールを書いておけば、毎回説明しなくても踏まえてくれる。
ここまでは合っています。

公式のmemoryページは、セッションをまたいで知識を運ぶ仕組みは2つだと説明しています。
人が書くCLAUDE.mdと、Claude自身が書くauto memoryです。
そのうえで、Claudeはこれを文脈として扱い、強制される設定としては扱わないと明記しています（code.claude.com/docs/en/memory、2026年8月4日確認）。

つまり、CLAUDE.mdに「顧客名を書かない」と記載しても、それは強制ではありません。
参照される情報のひとつです。

公式は、行動を確実にブロックしたい場合はPreToolUseフックを使うよう案内しています。
PreToolUseフックは、Claude Codeがツールを実行する直前に割り込んで、実行を止められる仕組みです。
「CLAUDE.mdに禁止と書けば守る」という理解は、ここで崩れます。

私が読んだ範囲では、日本語の解説記事はCLAUDE.mdを設定ファイルとして紹介する傾向が強く、私自身も最初はそう読んでいました。
権限設計をCLAUDE.mdだけで済ませていたら、いつか外れます。

書くべき5要素

では何を書くか。
私は5つに絞っています。

• 社内用語の言い換え：社内でしか通じない略称や、一般語と意味が違う語
• 入力禁止情報：データ分類で決めたもの
• 成果物のフォーマット：出力の形。ここが決まると合否判定が速くなる
• 人が確認する工程：どこで人に戻すか
• 参照してよい社内ドキュメントの場所：探しに行ってよい範囲

これ以上増やすと、書いたルールが守られているかを誰も追えなくなります。

全社共通のルールは、マネージドポリシーのCLAUDE.mdに置きます。
マネージドポリシーのCLAUDE.mdは除外設定ができず、組織全体の指示が個々の設定に関わらず常に適用されます（前掲memoryページ）。
部署ごとの補足は、各プロジェクトのCLAUDE.mdへ。

auto memoryについても方針を決めておきます。
既定で有効で、/memory のトグル（autoMemoryEnabled）で切り替えます。
Claude自身が書いた内容が蓄積されるので、社内固有の情報が自動的に溜まっていく前提になります。
ここを有効のまま運用するのか、業務データを扱う対象フォルダでは切るのか。
判断は業務の性質によりますが、決めないまま使い始めるという選択肢だけはありません。

【工程6】完了判定テストで再現できることを確認する

入力・処理・出力・例外・人の確認の5点を見る

完了判定は5点で見ます。

1. 想定した入力が渡せるか
2. 同じ手順で同じ処理が走るか
3. 出力が決めた成果物形式になっているか
4. 想定外の入力で止まるか
5. 人が確認する工程が飛ばされないか

1から3までは、たいてい通ります。
落ちるのは4と5です。
想定外の入力で止まらず、それらしい出力を返してしまう。
人の確認を挟むはずの工程を、そのまま通過してしまう。

観点ごとの確認方法と合格の目安は次のとおりです。

• 入力：手順書どおりに想定入力を渡す。追加説明なしで処理が始まれば合格。始まらなければ手順書へ前提の記載を追加する
• 処理：同じ入力で2回実行する。2回とも同じ工程を通れば合格。ずれたら手順の記述を具体化する
• 出力：成果物形式と突き合わせる。形式が一致していれば合格。違えばCLAUDE.mdの成果物形式を修正する
• 例外：入力禁止情報を渡し、削除を伴う操作も試す。止まって人へ戻れば合格。通ってしまえばpermissionsとフックを見直す
• 人の確認：確認工程を飛ばせるか試す。飛ばせなければ合格。飛ばせたら承認の実装場所を変える

冒頭で触れた「順序を逆にした代償」が請求されるのは、この表の右側です。
目的が絞れていなければ出力の合格条件が書けず、データ分類がなければ例外テストに渡す入力が用意できません。
環境構築から始めた導入が完了を宣言できないのは、テストが難しいからではなく、テストに書く合格条件の材料が手元にないからです。

テストは導入担当者ではなく現場担当者が実施する

テストを導入担当者が実施すると、「担当者の環境なら動く」で終わります。
本人は手順を全部知っているので、書かれていない前提を無意識に補います。

現場担当者が手順書だけを見て再現できたときに完了とします。
このとき、導入担当者は横で見ていて構いませんが、口を出さない。
質問が出たら、それは手順書に足りない箇所です。

私の経験では、ここで手順書が必ず1〜2箇所書き足されます。
多いのは「どのフォルダを開いた状態から始めるのか」と「途中で確認を求められたときに何と答えるのか」の2点で、どちらも導入担当者にとっては説明する必要のない前提です。
書き足すべき点が見つかるのが正常で、一度も質問が出ないほうを疑ったほうがいい。

例外テストには、入力禁止情報を渡そうとしたケースと、外部送信・削除が絡むケースを必ず含めます。
このとき、CLAUDE.mdに禁止と書いただけの状態と、PreToolUseフックまで設定した状態を分けて実行してください。
前者で通ってしまう場合、CLAUDE.mdの記載を強制力と取り違えていた箇所がそこに出ます。
見るのは、止まるかどうかだけではありません。
止まったあと、誰に相談すればよいかが担当者に分かるかどうかです。

テスト結果は、実施日・実施者・使った手順書のバージョン・結果を1行で記録します。

【工程7】利用開始後に止まった場面を記録して改善する

記録するのは事象だけにする

利用が始まると、記録は放っておくと感想になります。
「けっこう便利です」「思ったより使えないですね」。
これでは何を直せばいいのか分かりません。

記録するのは3つに絞ります。
Claudeが止まった場面、人が手作業へ戻した場面、担当者からの問い合わせです。

いずれも事象です。
評価ではありません。
「出力の形式が違ったので手で直した」と書いてあれば、直す場所はCLAUDE.mdの成果物形式だと分かります。
「禁止情報を貼ったのに処理が続いた」なら、直すのはpermissionsとフックの層です。
症状から直す層が一意に決まる粒度まで、書き方を落としておきます。

利用状況はOpenTelemetryで数値として取れる

手書きの記録だけに頼らなくてもよい部分があります。

Claude CodeはOpenTelemetryで利用状況・コスト・ツール活動を書き出せます。
CLAUDE_CODE_ENABLE_TELEMETRY=1 などの環境変数で設定し、管理者はマネージド設定ファイルで全ユーザーのOTel設定を一元管理できます（code.claude.com/docs/en/monitoring-usage、2026年8月4日確認）。

OpenTelemetryは、システムの動作記録を収集して外部の監視ツールへ送るための標準的な仕組みです。
これを入れておくと、「使われているのか」を体感ではなく数値で答えられます。
導入の説明責任が求められる場面では、この経路があるかどうかで話が変わります。

監査要件がある場合の保持の考え方

コンプライアンスAPI経由のデータは独自の保持モデルに従い、アクティビティフィードとリモートセッションのトランスクリプトは6年保持されます。
claude.ai由来のチャット・ファイル・プロジェクトの内容は、組織の保持ポリシーに従います（code.claude.com/docs/en/data-usage、2026年8月4日確認）。
ただし保持年数や適用範囲は契約形態とプランで変わりうるため、監査要件がある場合は自社の契約条件と合わせて確認してください。

改善は月1回で足ります。
記録が3件以上たまった項目だけを取り上げ、CLAUDE.mdか手順書か権限設定のどれで直すかを決めて反映します。
毎週見直すと、記録が2〜3件のうちに直してしまい、たまたま起きたことに合わせた設定が増えていきます。

完成したCLAUDE.mdの実例

5要素をすべて含めた例

先に挙げた5要素を1ファイルに書いた例を置きます。
架空の一般例です。

# プロジェクト固有の指示

## 対象業務
週次の営業会議の音声書き起こしから、社内フォーマットの議事メモ下書きを作る。
（各社で必ず書き換える箇所。ここが埋まらないと完了判定テストが作れない）

## 社内用語
- 「週次」: 毎週月曜の営業会議を指す。それ以外の定例は「定例」と書き分ける
- 「案件」: 受注前の見込みを指す。受注後は「プロジェクト」と呼ぶ
- 「一次」: 一次承認者のこと。人名は書かず役割で記載する

## 入力禁止情報
以下は入力しない。
- 顧客の氏名、会社名、連絡先などの個人情報および取引先を特定できる情報
- APIキー、パスワード、アクセストークン
- 契約書原本、単価や取引条件が記載された文書

※この節は文脈として参照されるだけで、強制力はない。
※実際のブロックは permissions と PreToolUse フックで実装している。
※禁止情報を含む入力に気付いた場合は、処理を続けず作業者へ確認を戻すこと。

## 成果物フォーマット
議事メモは以下の見出し構成で出力する。
1. 日付と出席者（役割名のみ。人名は書かない）
2. 決まったこと（箇条書き。1項目1行）
3. 決まらなかったこと（箇条書き。次回の判断者を併記）
4. 次回までの宿題（担当の役割名と期限）

書き起こしに存在しない内容を補わない。
聞き取れていない箇所は「（不明）」と書いて残す。

## 人が確認する工程
- 出力後、作業者が3の「決まらなかったこと」を必ず目視で確認する
- 社外へ共有する場合は、一次の承認を得るまでファイルを共有フォルダへ置かない
- 上記2工程は省略しない。急ぎの依頼があっても省略しない

## 参照してよい社内ドキュメント
- 議事メモの過去分（本プロジェクトの docs/minutes/ 配下）
- 社内フォーマット定義（docs/format/ 配下）
上記以外のフォルダは読み取らない。

この例をそのまま使わない方がよい部分

書き換えが必要なのは2箇所です。

対象業務の名称と、成果物フォーマット。
ここを自社のものに置き換えないと、完了判定テストの合格条件が作れません。
出力を見ても、それが正しいのか判断できないからです。

もう1点。
入力禁止情報の節には、強制力がない旨のコメントを入れてあります。
これは自分に向けた注記です。
ここに書いたから安心、という運用に戻らないための歯止めとして残しています。

よくあるご質問

まとめ：先に決めるのは手順ではなく完了の定義

7項目を並べましたが、最初に手を付けるのは3つです。

目的の絞り込み、データ分類、権限。
この3つが決まると、環境とCLAUDE.mdは自動的に絞れます。
対象業務が1件なら、揃える環境も1件分。
入力禁止情報が決まっていれば、CLAUDE.mdに書く禁止事項もそのまま決まります。

逆に、この3つを飛ばして環境構築から始めると、あとで全部やり直しになります。
私が見てきた止まっている導入は、ほぼこの順序を逆にしていました。
そして繰り返しになりますが、逆にしてしまう理由は理解できるものです。
進みやすいところから進んだ結果なので、責める話ではなく、順序だけ入れ替えれば済みます。

本記事の内容は、2026年8月4日時点の公式ドキュメントとRe-railのセットアップ実務にもとづきます。
プラン名・席モデル・管理機能は2026年中にも変わりうる領域で、実際にChat-only席とStandard／Premium席は新規契約では提供終了しています。
社内資料には確認日と公式URLを併記し、更新時に見直す前提で書いてください。
各社のセキュリティ要件は異なりますから、導入可否の最終判断は自社の情報管理規程と公式ドキュメントで行ってください。

どこで止まっているかが分からない場合もあります。
そのときは、対象業務を1件だけ選んで、完了判定テストの5観点を書き出してみてください。
書けない観点が、いま決まっていない項目です。

もし途中の切り分けで手が足りないようであれば、Re-railでもセットアップの支援を行っています。
まずは自社で7項目を紙に書き出すところから始めていただくのが、いちばん早い進み方だと思います。

自社に合う導入設計を、相談から。

対象部署・育成人数・業界固有の業務を伺い、法人受講とAI導入の進め方を整理します。

法人受講を相談する無料体験会を確認する