AI駆動開発の最初のハードルは社内承認― 生成AIガバナンスの全体像を一枚の図にする

Claude CodeやCursorを使った開発のデモは、たいてい成功します。PoCでの生産性向上も数字で示せます。それでも導入が進まない企業には、共通の風景があります。稟議が止まっているのです。

承認する側——情報システム部門、セキュリティ部門、法務、経営管理——の問いは、どの企業でもおおよそ同じです。

• 入力したコードやデータは、どこへ送られるのか
• 誰が・いつ・何をAIにやらせたのか、監査で説明できるのか
• 顧客データを含むリポジトリで使ってよいのか
• 利用料は青天井にならないか
• 顧客Aの案件情報が、顧客Bの作業に混ざらないか

この問いに「利用ガイドラインを整備し、研修を実施します」と回答した稟議は、たいてい差し戻されます。ガイドラインは破れるからです。承認側が見ているのは、破ろうとしても破れない仕組み——技術的に強制できる統制があるかどうかです。

その統制が何を守り、どこに置かれるのか。全体像は一枚の図に収まります。

守る対象を数えると、3つしかありません。

この3つに共通する性質が、設計の前提になります。

AIが情報を悪用するかどうか(技術的な漏洩)よりも、「渡した」という行為そのものが、第三者提供・NDA・委託先監督義務に抵触するかどうかが本質である。

実害が出たかどうかは関係ありません。渡す行為そのものが契約・法律上の問題になり得ます。たとえば、顧客から預かった要件定義書をそのままプロンプトに貼り付ける行為は、一文字も漏洩していなくても、委託契約上の「第三者への再提供」に該当し得ます。だから対策の設計思想は「漏れなければいい」ではなく、「渡していい情報の事前の線引き」と「渡す場合の正当な手続き」の2つに絞られます。

Team / Enterpriseプランでは入力データがデフォルトで学習に使われませんが、それは線引きの前提条件にすぎません。技術設定と契約・法務の整理が揃って、初めて承認の材料になります。

冒頭の承認側の問いは雑多に見えますが、それぞれ守る場所が違います。「管理外で使われないか」は端末とネットワークの話、「学習に使われないか」はサービスとの契約の話、「監査できるか」はログの話。守る場所が同じ対策は、担当部署も手段も同じになります。これを束ねると、生成AIのガバナンスは次の6つの層に整理できます。

この図は、そのままワークシートとして機能します。各層について「自社は何で担保するか」が一行ずつ埋まると、その6行が承認者に見せる統制設計の骨子になります。層1・2・4はClaude / IdPの設定と契約で埋まり(具体的な中身は第5章)、層5は法務との整理で埋まります。

構造上の制約はひとつだけあります。土台の層0が未整備だと、上の5層はすべて迂回できる。私物端末から私用メールアドレスでアクセスされれば、SSOも監査ログも素通しになります。図の表示を「層0が未整備」に切り替えると、その様子がそのまま見えます。Claude側の設定をどれだけ固めても、実効性を決めるのは自社の端末・ネットワーク管理の成熟度です。

層3(入力側DLP)だけは毛色が違い、プランの機能として買うことができず、自社で設計するしかない層です。中身は「AIに見せてよいデータしか、開発環境に存在しない」状態を作ること——本番データは合成データやマスキングで代替し、`.env`やSSH鍵への読み取りアクセスは設定で機械的に塞ぐ。運用ルールに頼らない、最も確実なDLPです。

導入検討でよく出てくるのが、ClaudeのProject機能を「顧客A用」「顧客B用」と分ければ案件別の管理ができる、という設計です。

一見それらしく見えますが、Projectは会話やナレッジを整理するための作業フォルダであり、権限やデータアクセスを強制する統制境界ではありません。誰がどの機能を使えるか、どのデータに触れるか、いくらまで使えるか——統制として管理したいものは、いずれもProjectの単位では強制できません。

TeamのProjectは「作業フォルダ」。統制境界は、EnterpriseのGroupとCustom Roleである。

受託開発やコンサルティングのように案件ごとに統制を変える要件がある場合、対応できるのはEnterpriseです。SSOはTeamでも使えますが、監査ログ、カスタムロール、SCIM、案件別の利用上限といった分離・監査・権限の機能はEnterpriseに集中しています。個人向けプラン(Pro / Max)には組織側の統制手段がほぼなく、案件別統制の議論の土俵に乗りません。

この区別が説明資料に一行あると、「Projectで分ければよいのでは」という手戻りがなくなります。

Enterpriseを前提にすると、統制の配置は次のように描けます。端末から接続先サービスまでの経路上に、統制ポイントが順に並ぶ構図です。

この配置には2つの設計判断が入っています。

ひとつは、強制ルールは開発者が変更できない場所に置くこと。Claude Codeの組織ポリシーは、管理者だけが書き込めるmanaged settingsとして端末に配布され、ユーザーやプロジェクトの設定より常に優先されます。配置場所はmacOSなら`/Library/Application Support/ClaudeCode/managed-settings.json`で、Jamf等のMDMからの配布や管理コンソールからの配信に対応しています——つまり、第3章の層0(MDM)がここでも土台になります。

                {
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(~/.ssh/**)"
    ]
  },
  "deniedMcpServers": [{ "serverName": "filesystem" }]
}
            

権限確認のバイパス禁止、外部送信・秘密情報読み取りの遮断、未検証のMCPサーバー(外部ツール接続)の禁止。「AIが勝手に危険なことをしないか」という承認側の問いへの回答は、この数行に集約されます。案件リポジトリ側の`.claude/settings.json`は開発者が編集できるため、こちらは「統制」ではなく「補助」と位置付けます。破れない層と調整できる層を分けておくと、承認者への説明がそのまま成立します。

もうひとつは、実データの分離はClaudeの外で決まること。コネクタは、接続先のGoogle DriveやGitHubで本人がアクセスできる範囲のデータにしか届きません。つまり案件の分離は、Claude側のGroup・Custom Roleと、接続先サービス側の権限設計がセットになって初めて成立します。

機能の開放範囲には、定石があります。

Admin Consoleで機能をすべてOFFにした状態から始め、業務要件が確認できたものだけを順にONにする。

このホワイトリスト方式には、「なぜこの機能がONなのか」の記録が機能ごとに残るという性質があり、監査にも承認者への説明にもそのまま使えます。反対の「全部ONで始めて、問題が出たら止める」方式は、止めた時点で現場との摩擦が生まれる——後から機能を取り上げられる形になる——ため、定着の面で分が悪い進め方です。

最後に、冒頭の承認側の問いに対する回答を並べ直します。

検討の順序は6層モデルの下から、つまり層0の現状確認からになります。判定は次の5問で足ります。

1. 業務PCのすべてに、MDMで管理プロファイルとクライアント証明書が配布されているか
2. 社内LAN / Wi-Fiは、証明書のない端末を接続の段階で弾くか(802.1X)
3. リモートアクセスは、VPNまたはZTNA経由に限定されているか
4. 社外への通信をCASB / Webフィルタで検査し、未許可のクラウドサービス利用を検知できるか
5. 私用メールアドレスでの生成AIサービス利用を、運用ルールではなく技術的に止められるか

「いいえ」が混ざる場合、先に埋める穴はClaude側ではなくそこにあります。すべて「はい」なら、層1以降はこのコラムの範囲でほぼ設計でき、稟議の段階で統制設計まで示せる状態です。

具体的な設定キーの選定、プラン構成、稟議資料への落とし込みは、自社のインフラ構成と契約条件によって最適解が変わります。Chapter Techでは、ガバナンス設計を含むAI駆動開発の導入・定着支援をエンタープライズ向けサービスとして提供しています。自社の構成でどう組むかは、お問い合わせからご相談ください。

なお、本コラムで扱ったのは組織側の統制です。開発プロジェクト側の統制——QCD基準、生成と検証の分離、トレーサビリティ——はClaude Code プロジェクトパックとしてGitHubで公開しています。

※ プラン別機能・設定キーは2026年7月時点の情報です。仕様は更新されるため、導入時点ではAnthropicの公式ドキュメントが正になります。