Claude Codeに何を読ませ、何を書かせるかを決める権限設計は、AIツールを業務に入れる際の最初のガバナンス判断です。アクセス範囲の決定をライセンス配布の後回しにすると、開発者ごとに異なる権限状態が生まれ、監査ログから操作主体を特定できなくなります。この記事では、リポジトリ権限とアクセス範囲の設計を、開発生産性とガバナンスの両立を前提に3層に分けて組む手順を示します。
Claude Code 権限設計を3層に分ける理由
Claude Codeのリポジトリアクセスは、次の3層で設計します。第1層はアクセス範囲、第2層は読み書き分離、第3層はシークレット除外です。この順序で設計する理由は、判断の粒度が異なるためです。
第1層のアクセス範囲は、リポジトリ単位で「このAIに触れさせてよいコードベースはどこまでか」を決定します。複数リポジトリを読めるよう設定すると、AIは横断的にコードを参照して回答を生成します。その結果、意図しないリポジトリの情報が別リポジトリの回答に混入するため、アクセス範囲は最小限に絞ります。
第2層の読み書き分離は、読み取り専用(read-only)と書き込み可(read-write)の2段階で権限を分けます。読み取り専用の場合、Claude Codeはコードベースを参照して回答は生成しますが、ファイルへの変更は提案のみに留まります。書き込み可の場合、ファイルへの直接編集とコミットが可能になります。どの段階で書き込み権限を与えるかは、後述の承認ゲート設計と連動します。
第3層のシークレット除外は、認証情報・APIキー・接続文字列をAIの読み取り範囲から外す設計です。この層は技術的な構成(環境変数・秘密管理サービスへの分離)と、アクセス制御(シークレットファイルへの権限剥奪)の両方で実現します。シークレット除外は別の回で詳述するため、この記事では第1層と第2層の設計手順を示します。
第1層 アクセス範囲の決定 リポジトリ単位で切る
アクセス範囲は、Claude Codeに読ませるリポジトリの集合を、業務の責任境界に沿って区切ることで決定します。責任境界とは、「このコードベースの変更を承認する主体が誰か」で引ける線です。承認主体が異なるリポジトリを同じアクセス範囲に含めると、AIが生成した変更案の妥当性を、承認権限を持たない人が判断することになります。
具体的には、次の2つの基準でリポジトリを分けます。第1の基準は機密性レベルです。社外秘・部門限定・全社公開といった情報区分が異なるリポジトリを、同一のアクセス範囲に含めません。Claude Codeは参照したすべてのコードを材料に回答を生成するため、機密性の高いリポジトリと低いリポジトリを混在させると、高い方の情報が低い方の回答に混入します。
第2の基準は変更承認フローの違いです。例えば本番環境に直結するリポジトリと、検証環境専用のリポジトリでは、コミット前のレビュー要件が異なります。要件の異なるリポジトリを同じ権限で扱うと、検証用のコードが本番リポジトリへ流れ込む経路が生まれます。
これらの基準に沿って、次のようにアクセス範囲を区切ります。まず全リポジトリをリストアップし、それぞれに機密性ラベル(社外秘・部門限定・全社公開)を付与します。次に承認フロー(変更前レビュー必須・事後チェックのみ・承認不要)を記録します。機密性と承認フローの組み合わせが同一のリポジトリ群を1つの範囲として括り、範囲ごとに識別名(例: core-backend-confidential、frontend-public-sandbox)を付けます。この識別名が、後の権限付与とログ記録の単位になります。
第2層 読み書き分離の設計 段階的に権限を広げる
読み書き分離は、読み取り専用(read-only)と書き込み可(read-write)の2段階で権限を分け、利用者の習熟度と業務影響の大きさに応じて段階的に移行させる設計です。この設計の目的は、AIが生成したコードの品質を人が検証できる期間を確保することです。
読み取り専用権限では、Claude Codeはコードベースを参照して提案を生成しますが、ファイルへの直接書き込みはできません。生成された変更案は、利用者が内容を確認した上で、手動でコピー&ペーストするか、別途コミット操作を行う必要があります。この手順を挟むことで、AIの提案が意図しない副作用を持つかどうかを、コミット前に検証できます。
書き込み可権限では、Claude Codeがファイルを直接編集し、コミットまで実行できます。この権限を与える前に、次の2つの条件を満たすことを確認します。第1の条件は、利用者がAIの提案内容を読み、意図と一致しているかを判断できる技術水準を持つことです。第2の条件は、誤ったコミットが発生した場合に、それを検出して巻き戻す手順が整備されていることです。
段階的な移行は、次の手順で進めます。まず全利用者に読み取り専用権限を付与し、2週間以上の試用期間を設けます。この期間中に、AIが生成した提案の妥当性を人が判断した記録(レビューコメント・却下事例)を収集します。次に、試用期間中に誤った提案を正しく見分けた実績を持つ利用者に対して、書き込み可権限への昇格を個別に承認します。昇格の判断材料は、提案の採否を記録したログと、それに対する上長またはコードレビュー担当者の評価です。
権限の付与単位 個人か役割か
Claude Codeの権限は、個人アカウント単位で付与するのではなく、役割(ロール)単位で付与します。役割単位で付与する理由は、人事異動や組織変更が発生した際に、権限の再設定が不要になるためです。個人アカウントに直接権限を付けると、異動のたびにアクセス範囲と読み書き権限を見直す必要があり、その間に不要な権限が残存するリスクが生まれます。
役割は、次の3軸で定義します。第1の軸は業務上の責任範囲です。例えばバックエンド開発担当・フロントエンド開発担当・インフラ担当といった区分です。第2の軸は機密性の取り扱い権限です。社外秘情報を扱える役割と、全社公開情報のみを扱う役割を分けます。第3の軸は承認権限の有無です。他者のコミットを承認できる役割と、自分のコミットのみを行える役割を区別します。
これらの軸を組み合わせて、役割の定義表を作成します。例えば「バックエンド開発担当・社外秘扱い可・承認権限あり」という役割には、core-backend-confidentialリポジトリへの書き込み可権限を付与します。「フロントエンド開発担当・全社公開のみ・承認権限なし」という役割には、frontend-public-sandboxリポジトリへの読み取り専用権限を付与します。役割ごとの権限表を作成したら、個人アカウントを役割に割り当てます。この割り当ては人事システムまたは組織図と連動させ、定期的に同期します。
権限設計を監査ログと連動させる方法
権限設計は、監査ログの記録単位と連動させることで、後から「誰が何を読ませたか」を追跡可能にします。監査ログに記録すべき項目は、利用者ID・アクセスした範囲(リポジトリ識別名)・権限レベル(読み取り専用/書き込み可)・操作日時・生成されたコミットID(書き込み可の場合)の5つです。
これらを記録するには、Claude Codeのアクセスをバージョン管理システム(GitHub・GitLab等)のAPIを経由させ、API呼び出しログを保存する構成にします。APIログには、呼び出し元のアカウント・対象リポジトリ・実行された操作(read/write)が含まれます。このログを定期的に取得し、利用者IDと役割の対応表と突き合わせることで、役割を超えたアクセスが発生していないかを検証できます。
ログの保存期間は、組織の監査要件に従います。一般的には1年以上の保存が推奨されますが、金融・医療など規制の厳しい業界では、より長期の保存が求められることがあります。ログの形式は、JSON Lines形式で1行1イベントとして記録すると、後の集計と分析が容易になります。
権限設計を組織変更に耐える形で作る
組織変更が発生した際に、権限設計を全面的に作り直す事態を避けるには、役割定義を業務の責任境界に沿って作り、組織図の部署名に直接紐付けない設計にします。部署名は組織変更のたびに変わりますが、業務の責任境界(バックエンドの変更を承認する主体・フロントエンドの変更を承認する主体)は、部署が統廃合されても本質的には変わりません。
具体的には、役割定義表に「所属部署」列を設けず、「承認責任を持つ範囲」列を設けます。例えば「core-backend-confidentialリポジトリの変更を承認できる」という責任範囲を役割の定義に含め、その役割に誰を割り当てるかを、組織図とは独立に管理します。組織変更が発生した場合は、役割への人の割り当てを更新するだけで済み、役割そのものの定義は変更しません。
この設計を実現するには、役割定義表と人事データを疎結合にします。人事システムから取得するのは個人IDと現在の承認権限の有無のみとし、役割への割り当ては別の管理台帳で行います。管理台帳は、個人ID・役割名・割り当て開始日・割り当て終了日(未定の場合は空欄)の4列で構成します。この台帳を権限付与の唯一の正本とし、バージョン管理システムのアクセス制御設定は、台帳から自動生成します。
統制装置の置き場所は前提に依存する
権限設計の前提となるのは、ライセンスの配布範囲と、利用者が直接触れるインターフェースです。前提が変われば、統制装置の置き場所も変わります。Copilotの有償ライセンスが一部にしか配布されていない前提では、広く使われるエージェントをCopilot Studioへ昇格させ、環境分離・コネクタDLP・環境別クレジット割当・公開承認フローという統制装置を必ず通過させる設計が成立していました。しかし有償ライセンスが対象組織のほぼ全員に配布された結果、全社展開の主経路は「Copilot Studioへ昇格」ではなく「Agent Builderのままギャラリーへ掲載」へ転換しました。Agent Builderは環境の概念を持たず、コネクタDLPの対象外です。そのため、Copilot Studio環境側に置いた統制装置の上を、全社展開の主経路が通らなくなりました。
具体的には、開発から本番への段階検証、コネクタDLPによる出口統制、環境別クレジット割当と上限到達時の自動停止、公開承認フロー、この4つが主経路に対して効かなくなりました。全社公開のゲートはギャラリー掲載に置き換わりましたが、その審査主体と基準は未定義であり、ガバナンス上の空白として残りました。統制の思想(入口は止めず出口で締めるガードレール型)は変えず、装置の置き場所を「環境」から「人(セキュリティグループ)とデータ(権限・ラベル)」へ再配置する方針で組み替えました。統制設計はライセンスの配布範囲という前提に依存しています。前提が変われば、統制の思想ではなく装置の置き場所を組み替えます。
監査設計は権限の承認可否で決まる
監査ログの取得をPurview前提で設計したが、監査ロールの付与が社内承認されなかった事例があります。メール等まで閲覧範囲が及ぶことが理由です。監査目的の大半はエージェント管理基盤へ載せ替えましたが、「誰が誰に共有したか」の操作記録だけは代替手段がなく、残存リスクとして記録しました。監査設計は「技術的に取得できるか」ではなく「その権限が社内で承認されるか」で決まります。
権限設計を組む際には、監査に必要なログを取得する権限が、組織内で承認される見込みがあるかを先に確認します。承認されない場合は、代替手段(API呼び出しログ・外部監査基盤へのイベント転送)で実現可能な範囲を特定し、実現できない部分は残存リスクとして記録します。
削除基準は稼働頻度で決めない
90日間未使用のエージェントを一律で削除する基準を設けたが撤回した事例があります。半年に1回など低頻度で稼働するエージェントが存在するため、未使用期間による一律削除は成立しませんでした。権限設計においても、同様に「最終アクセスから◯日経過したら権限を剥奪」という自動ルールは、低頻度の正当な利用を誤って停止させるリスクがあります。
権限の見直しは、未使用期間ではなく、役割の割り当て状態(人事異動・退職)を基準に行います。役割から人が外れた時点で、その人に紐づく権限を自動的に剥奪する仕組みを整えます。最終アクセス日時は参考情報として記録しますが、削除や剥奪の判断材料には使いません。
実務で回す手順書の作り方
権限設計を決定した後、実務で回すには手順書が必要です。手順書は、検証、決定、手順書の順序で作ります。検証、決定、手順書の順序を崩すと手戻りが発生します。決定を急がせる前に、検証結果を材料として先に出します。
検証段階では、次の3つを確認します。第1に、役割定義表に基づいて権限を付与した場合、バージョン管理システムのAPI呼び出しログに必要な項目(利用者ID・リポジトリ名・操作種別)が記録されるかを実際に試します。第2に、役割への人の割り当てを変更した場合、権限の反映にかかる時間(即時反映か、同期バッチの実行タイミングか)を計測します。第3に、書き込み可権限を持つ利用者が誤ったコミットを行った場合に、それを検出して巻き戻す手順が、実際に機能するかをテスト環境で確認します。
検証結果を材料に、次の事項を決定します。役割定義表の確定版(役割名・アクセス範囲・権限レベル)、役割への人の割り当て基準(承認責任の有無・機密性の取り扱い権限)、権限の昇格条件(読み取り専用から書き込み可への移行要件)、監査ログの保存期間と形式、組織変更時の割り当て更新頻度(週次・月次)の5つです。
決定事項を元に、次の手順書を作成します。新規利用者への権限付与手順(役割の判定・割り当て申請・承認・反映)、権限の昇格手順(試用期間の記録・評価・承認)、組織変更時の割り当て更新手順(人事データの取得・役割の再割り当て・反映確認)、監査ログの取得と保存手順(APIログの取得スクリプト・保存先・集計方法)、誤ったコミットの検出と巻き戻し手順(検出ルール・通知先・巻き戻しコマンド)の5つです。手順書には、実行者の役割名・前提条件・実行コマンドまたは操作画面・期待される結果・エラー時の対処を必ず記載します。