メドピア開発者ブログ

集合知により医療を再発明しようと邁進しているヘルステックカンパニーのエンジニアブログです。読者に有用な情報発信ができるよう心がけたいので応援のほどよろしくお願いします。

Claude Enterprise全社導入で何を検討し、何をやらなかったか

こんにちは。セキュリティエンジニア兼SREの侘美です。

2026年6月、メドピアではClaude Enterpriseの全社導入を完了しました。正社員・契約社員あわせて約130名にアカウントを配布しています。

今回の導入は、自分（セキュリティ）とコーポレートIT（社内のIT機器・SaaS管理を担当）で協力して設計・構築しました。セキュリティ方針やリスク評価は自分が担当し、SSO・SCIM設計やクライアント管理、コネクタ運用といった実装面の細かい検討・構築はコーポレートITのメンバーが中心になって進めています。

全社導入にあたっては「何を使えるようにするか」と同じくらい「何をやらないか」の判断が多く、この記事ではその検討プロセスを共有します。導入を検討している企業の参考になれば幸いです。

全社導入の背景

PoC期間で見えたこと

メドピアではエンジニアが先行してClaude Codeを業務に活用していました。2026年3月からはビジネスサイドを含む5〜10名の選抜メンバーでPoCを開始し、オペレーション業務を1/3に削減する目標を掲げていました。

PoCを進める中で2つの課題が見えてきました。

1つ目は非エンジニアの利用リスクです。PoCメンバーから「パッケージのインストールを案内されるとよくわからずにYesを押してしまう」という声があがりました。git操作やNode.jsの設定をAIに指示されるまま実行してしまうケースも報告されています。

2つ目はアカウントの格差です。Claude IDを持っている人と持っていない人とで情報格差・業務格差が発生し、事業推進部ではSkills化が進んでオペレーションメンバーへの展開が必要な段階になっていました。

全社員にアカウントを配布しつつ、安全に使える仕組みが必要。これが全社導入の出発点です。

セキュリティ面の状況

導入検討と並行して、AIエージェント周りのセキュリティインシデントが立て続けに報告されていました。

  • Claude Code設定ファイル経由のRCE（CVE-2025-59536）
  • Coworkでの間接プロンプトインジェクションによるファイル流出
  • Desktop ExtensionsのゼロクリックRCE（CVSS 10.0）
  • 野良Skills（ToxicSkills）の36%にプロンプトインジェクション検出

これらのリスクを理解した上で「だから使わない」ではなく「どう使うか」を設計する必要がありました。

導入までのスケジュール

全体で約3ヶ月、以下の流れで進めました。

時期 フェーズ
2026年3月 PoC開始、ガバナンスポリシー策定
4月 セキュリティ方針共有、プロダクト整理、部長会での合意取得
5月前半 管理設計・方針凍結
5月後半 設定構築、SCIM連携、SSO・端末認証設定
6月1日 全社展開完了

設計の基本方針

Tier方式のリスク分類

Claudeのプロダクトを2つのTierに分類しました。

  • Tier 1（Chat等）: ユーザーがデータを明示的に渡す。従来のチャット型AIと同等のリスク
  • Tier 2（Cowork / Code / Chrome等）: AIが許可された範囲で自律的に操作する。固有のリスクあり

この分類が「誰に何を使わせるか」の判断基軸になっています。

「事前制御」主軸

Cowork、Claude in Chrome、Officeエージェント、Claude in Slackは監査ログに対応していません。標準機能では「誰が・いつ・何を入力し・何を取得したか」の追跡がほぼ不可能です。

OpenTelemetryで理論上は追跡可能ですが、コスト・ROIの問題があります。

事後検証に頼れない以上、そもそもリスクが発生しない環境を作る「事前制御」を主軸に据えました。

リスクへの基本姿勢

リスクをゼロにすることは現実的ではなく、これはClaude固有の話ではなくあらゆるITツールに共通です。「リスクがある＝利用禁止」ではなく、状況に応じた柔軟な判断を方針としています。

導入時のルール

職種ごとのプロダクト使い分け

Claudeの主要プロダクトは4つあります。Chat（Web/デスクトップ/モバイル）、Code（CLI/IDE）、Cowork（デスクトップアプリ）、Design（プロトタイプ作成）です。下にいくほど自律性が高く、リスクも増します。

機能 エンジニア 非エンジニア
Chat 利用可 利用可
Cowork 利用可 許可制
Code 利用可 利用不可

DesignはまだResearch Previewのため、ここでは割愛しています。

非エンジニアのClaude Code利用については社内でも議論がありました。結論としては「非エンジニアがCodeを使うのではなく、そのタスクはエンジニアが担当すべき」「Codeを使うなら実質的にエンジニアになるべき」という方針です。セキュリティ面で中堅エンジニア程度の知識がないと危ないというのもあります。

Coworkは想定以上に多機能で、Notion整理やSlack連携、CSV分析といったタスクはCoworkで十分にこなせます。安全にしたCodeと素のCoworkの機能差が小さくなってきている現状では、いったんシンプルな線引きで、無理に仕組みを作らずにプロダクトを使い分ける方が無難だと判断しました。

認証: SSO + 端末認証

Google WorkspaceをIdPとしたSAML認証に加え、Context-Aware Access（CAA）で会社管理端末のみアクセスを許可しています。BYODからのアクセスは排除する設計です。SSO・CAAの設定構築はコーポレートITが担当しました。

検証中に2点ほど問題が見つかりました。

OTPログイン経路がCAAを迂回する問題。メール+OTPでのログインはSAML/CAA経由しないため、端末認証が効きません。「Require SSO for Claude」設定をONにしてSSO以外の認証経路を封鎖しました。検証段階で気づけたのはよかったです。

iOSアプリのSSOログイン失敗。アプリ内WebViewではCAAのデバイスシグナルが渡せず、Googleサポートにも「サードパーティアプリのWebViewはGoogleエンドポイント管理と統合されていない」と言われました。社用iPhoneではChrome経由でアクセスする運用としています。モバイルでClaude使う場面は限定的なので、業務影響は軽微です。

SCIM連携によるアカウント・権限の自動管理

アカウント管理は4つのプロビジョニングモード（Invite only / JIT / SCIM / SCIM + Group Mappings）から最も自動化度が高い「SCIM + Group Mappings」を採用しました。Googleグループへの所属・離脱だけでアカウント発行・削除・権限変更が完結します。

グループ設計とSCIM構築はコーポレートITが中心に進め、7つのGoogleグループで運用しています。

グループ 用途
claude-owner 管理コンソール全権限
claude-admin 管理コンソール（請求除く）
claude-base Claude.aiの基本利用
claude-cowork Cowork追加利用
claude-code Claude Code追加利用
claude-seat-premium Premiumシート
claude-seat-standard Standardシート

シート種別はStandard（$40/月）とPremium（$200/月）の2種類があり、PremiumはClaude CodeやCoworkが利用可能です。誰にどちらを割り当てるかの設計もグループで管理しています。

ポイントはカスタムロールの加算式仕様です。claude-baseに所属するメンバーにclaude-coworkグループを追加すると、base + coworkの権限の和集合が適用されます。「制限のためにグループを作る」というアプローチはこの仕組みでは取れません。ベース＋積み上げ式の設計になります。

運用上の落とし穴がいくつかあります。

  • Group Mappings有効化前に全メンバーをいずれかのロールグループに所属させる必要がある。未所属のメンバーは自動削除されてしまう
  • Owner権限グループが存在しないまま有効化するとロックアウトする
  • シート種別を割り当てないとPremiumに自動振り分けされる。コスト増の罠
  • メールアドレス変更はSCIM上では新規作成＋旧アカウント削除として処理される

地味にハマるポイントなので、導入時は注意してください。

コネクタ（MCP）の管理

利用を許可するコネクタは限定しています。

コネクタ 読取り 書込み 備考
Notion ✅ ✅ 個人情報NG
Slack ✅ ❌ 書込み不可
GitHub ✅ ✅ エンジニア向け
Figma / Datadog / Sentry 調整中 調整中 —

Slackへの書込みを不可としている理由は、後述のClaude in Slack OFFと共通です。端末認証の迂回経路になるのを防いでいます。

コネクタ管理で厄介だったのは、有効化すると組織全体に影響する制約です。「特定部署だけで使う」といった細かい制御ができませんでした。当初は組織全体のon/offしかできないため、コーポレートITが申請フローを整備して統制していました。

その後、Role単位でコネクタを制御できる機能がリリースされたため、今後は許可されたRoleにはある程度の裁量を持たせるルールに変更予定です。こうしたプロダクト側の進化でルールの前提が変わるのは日常的に起きます（「新機能リリースへの対応」で詳しく触れます）。

制限・無効化した機能

Claude in Slack → OFF

OFFにした理由は複合的です。

  • SlackはBYODからアクセス可能なので、Claudeの端末認証を迂回する
  • SlackのガバナンスとClaudeのガバナンスが矛盾する（情報の流通経路が二重になる）
  • Claude Code in SlackでCode起動が可能。非エンジニアCode利用NG方針と衝突する
  • チャット内容がClaudeの監査ログに記録されない

Admin ConsoleでのOFFに加え、コーポレートIT側でSlackのClaudeアプリをRestrictにして二重防御としています。

とはいえ、SlackはメドピアのコミュニケーションHub なので、ここでClaudeが使えない不便さは正直大きいです。セキュリティ上の課題をクリアする方法がないか、継続的に検討しています。

プラグイン・デスクトップ拡張 → 原則不可

プラグイン経由で意図しないコネクタやスキル、MCPが持ち込まれるリスクがあるため、許可リスト方式で管理しています。業務上必要なものはIT宛に申請する運用です。

Claude in Chrome → 許可制

Claudeがブラウザ上で読み取り・クリック・入力・送信を代行する機能です。不許可条件として、要配慮個人情報を含むサービス、誤操作時に不可逆な影響があるもの、代替手段があるものを設定しています。承認フローは部長→SaaS管理者→情シス→セキュリティの4者直列です。Google WorkspaceのChrome拡張管理でインストール自体を制御しています。

Officeエージェント → 保留

M365コネクタの判断と一体で扱う方針です。SharePoint内の要配慮個人情報の実態確認や、顧客契約上の「外国保管禁止」条項の確認が必要で、まだ結論が出ていません。

新機能リリースへの対応

「デフォルトON」問題

Anthropicは新機能をデフォルトONで提供します。管理者の明示的な同意なく機能が有効化される構造です。

実際に起きた事例をいくつか挙げます。

  • Officeエージェントが有効化された状態で提供開始された（2026年5月7日）
  • Claude in Slackが管理者の同意なく有効化されていた（2026年5月13日確認）
  • Claude Security機能が利用上限設定を無視して課金されるバグがあった（5月初旬、5/7修正）

「まずONで配って、利用しないなら個別にOFFしてください」がAnthropicのスタンスです。これは「たまたま起きた個別事象」ではなく構造的な問題なので、今後も継続的に発生することを前提に統制を設計しています。

検討中に前提が変わる

先述のコネクタ管理のように、ルールを設計している最中にプロダクト側の仕様変更で前提が変わることが日常的に起きます。Coworkも当初はResearch Previewでしたが、急速に進化して想定以上の機能を持つようになりました。

完璧なルールを最初に作ろうとするとすぐに陳腐化します。段階的に整備して変化に追従する方針で運用しています。

検討したがやらなかったこと

導入時のルールと同じくらい、「やらない判断」にも時間を使いました。

Managed Settings（managed-settings.json）

Claude Codeには設定ファイルが4階層あり、その最上位がmanaged-settings.jsonです。Jamf等のMDMで配布すればユーザーは変更できず、Hooksの無効化やMCPの制限、危険コマンドのdenyを強制できます。

非エンジニア向けの厳格な設定まで設計していましたが、費用対効果から見送りました。

  • managed-settings.jsonの対象はClaude Code利用者に限られ、全社員のうちの一部。その人数に対して設計・配布・メンテナンスの工数が見合わない
  • エンジニアはMacの管理者権限を持っているため、本人またはAIがmanaged-settings.jsonを削除・改ざんできてしまう
  • 無効化の検知はCrowdStrike FileVantage等で理論上は可能だが、その仕組みの構築自体にもコストがかかる

セキュリティリスクと工数を天秤にかけた結果です。ただし完全に捨てたわけではなく、なるべく工数をかけずにクリティカルな部分を抑制できる設定がないか、検証は継続しています。

Cloudflareでのapi.anthropic.comブロック

非エンジニアのClaude Code利用をネットワーク層で遮断する案も検討しました。managed-settings.jsonで統一的に制御した方がシンプルという判断で不採用に。最終的にはライセンス制御で十分に対応できています。

CrowdStrike FileVantage

.claude/配下やmanaged-settings.jsonのファイル変更をリアルタイム検知する案です。Managed Settingsの無効化検知にも使えます。ただ現状のCrowdStrike契約に含まれておらず、価格調査・動作検証が必要なため保留としています。

パッケージスキャンツール（Socket.dev等）

npm install前にパッケージの安全性を自動チェックするツールです。有効なのは間違いないですが、導入コスト・運用負荷との兼ね合いで保留中です。

代替として、サプライチェーン攻撃対策を全社で水準統一しています。Actionsのhash固定（pinact等）、ロックファイルの厳密な適用、ライブラリアップデートのクールダウンタイム（3〜7日）に加え、Takumi Guard（GMO Flatt Security）をレジストリプロキシとして導入し、npm install時に悪性パッケージをインストール前にブロックする仕組みも取り入れています。

まとめ

Claude全社導入はセキュリティリスクとの戦いというより、リスクを正しく理解した上での設計の連続でした。監査ログに頼れない現状では「事前制御」が軸になりますし、Anthropicの「デフォルトON」方針を前提とした運用設計も必要です。

今回はセキュリティ側からリスク評価と方針を出し、コーポレートITが実装・運用面を細かく詰めていく分担でうまく回りました。プロダクトの進化が速いので完璧なルールは作れませんが、段階的に整備して変化に追従していく方針が現実的だと感じています。

Claudeは新機能が高頻度でリリースされるプロダクトなので、一度作った設計が正解であり続けることはありません。この記事の内容も、数ヶ月後には見直しが必要になっているはずです。導入して終わりではなく、設計を常にアップデートしていく前提で運用することが大事だと思います。

同じようにClaude Enterpriseの導入を検討している方の参考になれば幸いです。

是非読者になってください！

メドピアでは一緒に働く仲間を募集しています。
ご応募をお待ちしております！

■募集ポジションはこちら hrmos.co

■エンジニア紹介ページはこちら engineer.medpeer.co.jp

■メドピア公式YouTube　 www.youtube.com

■メドピア公式note
style.medpeer.co.jp