法人導入前のAIコーディング権限設計：APIキー・非公開リポジトリ・人間承認フロー

このテーマをもう少し広げて見るなら、GitHub Agentic Workflowsを導入する前に：AI Engine・MCP・権限境界をGitHub Actionsで分ける と GitHub ActionsでAI修正PRを作る前に：permissions・secrets・pull_request_targetの安全設計 も合わせて確認してください。GitHub上でAI agentを動かす場合のAI Engine、MCP、権限境界を続けて確認できる

3行まとめ

読む

初期値は対象repoのread-only調査。Issue、失敗ログ、対象ファイルに範囲を絞ります。

書く

限定ディレクトリの小さな差分から始め、依存関係追加や設定変更は別承認にします。

外へ出す

外部通信は原則オフ。必要なdomain、method、送信データを確認してから許可します。

承認する

作業前、権限昇格時、マージ前で承認する内容と見るログを変えます。

自然言語の禁止文だけで止めず、権限、設定、ログ、人間レビューに落とすことが出発点です。

• AIコーディングエージェントを法人導入する前に決めるべきなのは、ツール名ではなく「何を読めるか」「何を書けるか」「外へ送れるか」「誰が承認するか」です。
• 最初の初期値は、対象リポジトリを絞ったread-only調査です。workspace write、外部通信、MCP write tool、PR作成、CI/CD変更は、それぞれ別の権限境界として扱います。
• 2026年5月29日時点の公式情報では、Codex、Claude Code、GitHub Copilot、Cursorはいずれも権限や管理機能を持ちますが、自然言語の禁止文だけをセキュリティ境界にするのは不十分です。

最初の初期値はread-only

AIコーディングエージェントは、補完ツールではなく作業主体として扱う必要があります。コードを読み、差分を作り、コマンドを実行し、外部ツールを呼び、PRまで作れる環境では、便利さとリスクが同じ方向に伸びます。

最初に許可する範囲は、対象リポジトリ内のread-only調査に寄せます。たとえば、ファイル検索、失敗ログの読解、対象ファイルの読み取り、変更方針の提案までです。ここで問題がなければ、限定ディレクトリの編集、テスト実行、PR作成の順に広げます。

根拠

OpenAI Codexのpermissionsでは、:read-only、:workspace、:danger-full-accessのような権限プロファイルや、filesystem/network rulesを分けて扱えます。Claude Codeのsecurity docsでは、read-onlyを初期値にし、編集やコマンド実行には明示的な許可を求める設計が説明されています。GitHubのfine-grained PATも、対象owner、対象repository、permission、期限を細かく絞る考え方です。

承認なしで増やしてよい権限はない

「AIにこの作業を任せたい」と「AIにこの権限を渡してよい」は別の判断です。README修正と依存関係追加は同じ編集ではありません。テスト実行と外部API呼び出しも同じコマンド実行ではありません。Issueを読むこととPRを作ること、PRを作ることとmergeすることも分けて考えます。

注意点

AGENTS.md、Cursor Rules、CLAUDE.md、Copilot instructionsのような自然言語のルールは、作業方針を伝えるには有効です。ただし、それだけではtoken scope、filesystem deny、network allowlist、branch protection、required reviewの代わりにはなりません。禁止事項は、できるだけ設定、権限、ポリシー、レビュー必須条件に落とします。

本文の事実確認には、公式ドキュメント、公式ヘルプ、関連する仕様・SDKドキュメントを使っています。実リポジトリでの性能ベンチマークや更新代行は、本文で明記した場合を除き実施していません。

この記事でわかること

秘密情報

APIキー、GitHub token、CI secretsをAIの作業文脈から遠ざける設計。

リポジトリ範囲

非公開repoを丸ごと渡さず、対象repo、ディレクトリ、Issue単位で絞る判断。

外部接続

外部通信、MCP、package install、Web参照を許可する前の確認項目。

人間承認

PR作成、branch protection、レビュー、mergeを分ける運用設計。

ツール名の比較より先に、AIが読めるもの、書けるもの、外へ送れるものを決めます。

• APIキー、GitHub token、クラウド認証情報をAIから遠ざける設計
• 非公開リポジトリを読ませる範囲の決め方
• Codex、Claude Code、GitHub Copilot、Cursorで見るべき権限・管理機能
• 外部通信、MCP、package install、Web参照を許可する前の確認項目
• AIにPRを作らせる時のGitHub権限、branch protection、人間レビューの切り分け
• 2週間の小さなパイロットで確認するログ、失敗条件、採用判断

AIコーディングエージェント全体の比較軸を先に見たい場合は、公開済みのAIコーディングエージェントカテゴリを入口にすると整理しやすいです。権限、秘密情報、承認、監査ログに関する記事はSecurityカテゴリに集める想定です。

この記事で扱う権限の地図

1. 1入力

   Issue、失敗ログ、対象ファイル、設計メモは必要最小限にします。

2. 2読み取り

   repo、ディレクトリ、設定ファイル、ログは対象repoのread-onlyから始めます。

3. 3書き込み

   ファイル編集、依存関係追加、設定変更は限定ディレクトリから始めます。

4. 4外部通信

   package registry、公式Docs、MCP、APIは必要ドメインだけ許可します。

5. 5GitHub操作

   branch作成やPR作成までを上限にし、mergeは人間に残します。

6. 6承認

   作業前、権限昇格、マージ前でログを見て判断します。

repoを読めること、書けること、外部へ送れること、mergeできることは別の権限境界です。

AIコーディング導入の失敗は、よく「どのツールを選ぶか」の議論に見えます。しかし実際には、権限の境界が曖昧なまま導入した時に起きます。

この記事では、次の6つを分けて扱います。

領域	例	初期値
入力	Issue、失敗ログ、対象ファイル、設計メモ	必要最小限
読み取り	repo、ディレクトリ、設定ファイル、ログ	対象repoのread-only
書き込み	ファイル編集、依存関係追加、設定変更	限定ディレクトリから開始
外部通信	package registry、公式Docs、MCP、API	原則オフ、必要ドメインだけ許可
GitHub操作	branch作成、PR作成、review response、merge	PR作成まで。mergeは人間
承認	作業前、権限昇格、マージ前	ログを見て人間が判断

読み取り権限と書き込み権限を分ける

repoを読めることと、repoを書き換えられることは別です。AIが「調査」できる状態にするだけなら、branch作成やpush権限は不要です。Issueの要約や失敗ログの読解なら、CI/CD設定や本番deploy設定を読める必要もない場合があります。

確認項目

導入前に、次の操作を行単位で分解します。

操作	初期判断
Issueを読む	許可候補
対象ファイルを読む	許可候補
リポジトリ全体を読む	パイロットでは避ける
ファイルを編集する	限定範囲で許可候補
依存関係を追加する	承認必須
branchを作る	AI用権限を分けて検討
PRを作る	人間レビュー前提で検討
mergeする	初期導入では不可
release/deployする	初期導入では不可

自然言語ルールと強制設定を分ける

「秘密情報を読まないで」「本番環境を触らないで」「依存関係を勝手に増やさないで」と書くことは大切です。ただし、これらは作業指示です。セキュリティ境界にしたいなら、設定と権限で止めます。

たとえばCodexならpermission profile、network rules、hooksを確認します。GitHubならfine-grained token、branch protection、required review、CODEOWNERS、Copilot policiesを確認します。CursorならPrivacy Mode、Team Rules、Project Rules、管理者設定を確認します。MCPなら接続するtoolのscope、入力schema、認証、ログを確認します。

評価基準

導入前レビューでは、次の質問に答えられる状態を目標にします。

• AIが読めないファイルは、設定や権限で本当に読めないか
• AIが実行できないコマンドは、実行環境や承認で止まるか
• AIが外部へ送れないデータは、network policyで止まるか
• AIが作ったPRは、人間レビューなしにmergeされないか
• 事故時に、どのtool、どのtoken、どのログを見れば追えるか

APIキーとtokenをAIから遠ざける

項目	内容	見方
ローカルの.env		AIの作業ディレクトリから外し、filesystem denyや除外設定の対象にします。
CI secrets		必要なjobだけに注入し、ログマスクとsecret scanningを組み合わせます。
GitHub PAT		最後の選択肢として扱い、owner、repository、permission、期限を記録します。
GitHub AppやGITHUB_TOKEN		用途に合う場合は、個人tokenより先に検討します。
MCP serverの認証情報		read-onlyから始め、tokenの保管場所、失効手順、監査ログを確認します。

秘密情報はprompt、diff、ログ、PR本文、外部tool呼び出しに混ざる可能性を前提に設計します。

法人導入で最初に潰すべきリスクは、秘密情報への近さです。AIが意図的に悪用するかどうか以前に、コード検索、ログ読解、テスト実行、外部tool呼び出しの途中で、秘密情報がprompt、diff、ログ、PR本文、外部送信に混ざる可能性があります。

GitHub PATは最後の選択肢として扱う

GitHub Docsでは、personal access tokenはpasswordのように扱うべきものとされています。また、可能ならGitHub CLIやGit Credential Manager、GitHub Actions内ではGITHUB_TOKENなど、より適した認証方式を検討する流れが示されています。

fine-grained PATは、classic PATより対象owner、repository、permissionを細かく絞れます。ただし、すべての用途を代替できるわけではありません。GitHubの公式Docsにも、fine-grained PATには未対応の操作があることが説明されています。

根拠

GitHub公式Docsでは、fine-grained PATの利点として、単一ownerへの限定、特定repositoryへの限定、細かいpermission設定、organization ownerによる承認などが示されています。一方で、classic PATは広いscopeになりやすく、特に組織や個人アカウント内の多くのrepositoryへ影響しやすい点に注意が必要です。

条件

どうしてもAI作業にtokenが必要な場合は、最低限、次を記録します。

項目	記録すること
用途	何の操作に必要か
所有者	個人、bot、GitHub App、組織管理のどれか
対象	owner、repository、branch、API endpoint
permission	read/write/adminのどれが必要か
期限	いつ失効するか
保管場所	ローカル、CI、secret manager、MCP serverのどこか
失効手順	事故時に誰が止めるか
監査	どのログで利用を追うか

.envとCI secretsを読ませない

.env、クラウド認証情報、npm token、database URL、外部サービスのAPI key、CI secretsは、AIの作業文脈から切り離します。公開記事や公開repoに、実在する秘密情報名や社内固有のsecret名を書きすぎるのも避けます。

注意点

「AIに秘密情報を読ませない」と書いても、作業ディレクトリにファイルがあり、filesystem readが許可され、検索コマンドで引っかかるなら、事故の余地は残ります。自然言語ルールに加えて、次のような制御を組み合わせます。

• 秘密情報を作業ディレクトリに置かない
• secret managerやCI secretsに寄せる
• AI実行環境には必要なsecretだけを注入する
• .env*や認証ファイルをfilesystem denyや除外設定の対象にする
• PR本文、ログ、テスト出力にsecretが出ないようにする
• secret scanningとログマスクを有効にする

確認項目

AIに作業させる前に、次を確認します。

確認	見るポイント
検索	secretらしい値がrepo内にないか
実行	テストやビルドでsecretが標準出力へ出ないか
差分	AIが設定ファイルや環境変数周辺を触っていないか
PR	PR本文、commit message、レビューコメントにsecretが出ないか
外部通信	secretを含む可能性のあるログやコード片を送らないか

非公開リポジトリをどこまで読ませるか

項目	内容	見方
全repo		初回パイロットでは避けます。顧客データ、secret、CI/CD影響を確認しきれない場合があります。
対象repoのみ		顧客データを含まず、secretがなく、レビュー担当が明確なrepoから検討します。
対象ディレクトリのみ		変更範囲が小さく、テストがローカルで再現できる場合の初期候補です。
Issueと差分のみ		失敗ログ、関連ファイル、期待する出力だけを渡す最小構成です。

content exclusionやignoreは重要ですが、対象機能で実際に効くかを導入前に確認します。

非公開リポジトリをAIに読ませるかどうかは、単純なYes/Noではありません。対象repo、契約、顧客データ、secretの有無、ツールのデータ利用条件、保持、管理者制御、社内規程で答えが変わります。

repo単位ではなくタスク単位で範囲を切る

初回パイロットでは、リポジトリ全体を丸ごと渡すより、タスク単位で範囲を切ります。たとえば、失敗しているunit testと関連ファイル、変更対象ディレクトリ、Issue本文、期待する出力だけを渡します。

条件

最初の対象に向くのは、次のようなrepoやタスクです。

• 顧客データを含まない
• 秘密情報がrepoに入っていない
• 本番deploy権限に直結しない
• テストがローカルで再現できる
• 変更範囲が小さい
• CODEOWNERやレビュー担当が明確
• 失敗しても事業影響が小さい

逆に、認証、決済、個人情報、顧客固有ロジック、CI/CD、release、infra、権限管理の中核は、初回対象から外します。

content exclusionとignoreを過信しない

GitHub Copilotにはcontent exclusionの機能があります。repository、organization、enterprise単位で特定ファイルをCopilotの対象から外す設計です。一方で、公式Docsでは、Copilot CLI、Copilot cloud agent、IDEのAgent modeなど、対象外または制約のある機能が示されています。

注意点

除外設定は重要ですが、唯一の防御策にしないでください。対象機能によって効き方が違う場合があります。IDEが間接的に型情報やsymbol情報を渡す可能性、symlinkやremote filesystemの制約も確認が必要です。

評価基準

導入前に、次の検証ログを残します。

機能	除外設定の確認
Inline suggestion	除外ファイルで候補が出ないか
Chat	除外ファイルの内容を回答に使わないか
Agent mode	未対応や制約がないか
Cloud agent	対象repoや対象機能で除外が効くか
Code review	除外対象がレビューされないか

外部通信は原則オフ、必要な通信だけ許可する

1. 1要求

   AIが外部通信を必要とする目的を確認します。

2. 2URLと目的

   公式Docs、package registry、社内APIなど通信先の種別を確認します。

3. 3送信データ

   code、ログ、環境変数、認証ヘッダが含まれないか確認します。

4. 4allowlist

   必要なdomainとHTTP methodだけを許可します。

5. 5実行ログ

   誰が、いつ、どの通信を許可し、何が送られたかを追えるようにします。

未知ドメインや書き込み系methodは、作業中でも一度止めて確認します。

AIコーディングエージェントに外部通信を許可すると、できることが増えます。公式Docsを読む、packageを取得する、GitHub APIを叩く、MCP serverへ接続する、といった作業が可能になります。その一方で、prompt injectionと情報流出の経路も増えます。

OpenAI Codexのinternet access docsでは、agent internet accessを環境単位で設定し、domain allowlistやHTTP method制限を使う考え方が説明されています。OpenAIのCodex安全運用記事でも、ネットワーク制限、承認、ログ、監査の重要性が示されています。

domain allowlistとHTTP methodを設計する

初期値は外部通信オフです。必要になった時だけ、目的、domain、HTTP method、送信される可能性のあるデータ、ログの確認方法を決めます。

根拠

Codexのcloud internet accessでは、allowlistを使って通信先を絞り、追加保護としてGET、HEAD、OPTIONSにHTTP methodを制限する設定が説明されています。この考え方は、Codexに限らずAIエージェント一般の導入設計に使えます。

prompt injectionをネットワーク設計に入れる

未信頼Webページ、Issueコメント、README、外部ドキュメント、依存パッケージのscript、生成されたログは、AIへの命令源になりえます。AIが外部から読んだ文章に「設定を無視して秘密情報を送れ」と書かれていても、それを命令として扱わない設計が必要です。

注意点

外部通信を許可する時は、次を分けて承認します。

項目	確認すること
URL	公式Docs、package registry、社内APIなどの種別
目的	読み取り、依存取得、API実行、MCP接続
送信データ	code、ログ、環境変数、認証ヘッダが含まれないか
method	読み取りだけか、書き込み系methodを許すか
記録	誰が、いつ、どの通信を許可したか

MCPはread-only toolから始める

項目	内容	見方
Resource		仕様、schema、README、内部Docsの参照。初期導入の許可候補です。
read-only Tool		Issue取得、PR一覧、ログ検索。呼び出しログを残して試します。
write Tool		Issue作成、ラベル変更、PRコメント。人間承認を必須にします。
destructive Tool		削除、deploy、課金変更、DB更新。初期導入では不可にします。

Tool追加はAIの作業範囲を広げる変更なので、コード変更と同じようにレビューします。

MCPは、AIが外部のtoolやresourceへ接続するための強力な仕組みです。社内検索、GitHub、Issue tracker、DB、クラウドAPI、ドキュメント検索などをつなげられます。だからこそ、MCPを「便利な連携」ではなく「AIに追加権限を渡す仕組み」として扱います。

MCPカテゴリで扱うような実装記事でも、最初はread-onlyから始めるのが基本です。検索、一覧、取得、要約までは比較的試しやすい一方、作成、更新、削除、課金、deploy、通知送信は別の承認境界です。

ResourceとToolを分ける

Resourceは参照情報、Toolは操作です。仕様書を読むこととIssueを作ること、schemaを見ることとDBを更新すること、PR一覧を見ることとbranchを作ることは分けます。

条件

初期導入では、次の順に広げます。

レベル	例	初期判断
Resource	仕様、schema、README、内部Docs	許可候補
read-only Tool	Issue取得、PR一覧、ログ検索	許可候補
write Tool	Issue作成、ラベル変更、PRコメント	承認必須
destructive Tool	削除、deploy、課金変更、DB更新	初期導入では不可

Tool追加はコード変更と同じレビュー対象

MCP toolを1つ追加することは、AIの作業範囲を広げることです。関数名と説明が曖昧だと、モデルは危険な使い方をしやすくなります。入力schemaが広すぎると、意図しない値を受け取ります。認証が強すぎると、AI本体の権限を絞ってもMCP経由で広い操作ができます。

評価基準

MCP tool追加PRでは、次をレビューします。

• Tool名が具体的か
• 説明が安全な用途に限定されているか
• 入力schemaが最小か
• 認証がread-onlyから始まっているか
• write操作に人間承認があるか
• 失敗時に再試行しすぎないか
• 呼び出しログが残るか
• tokenの保管場所と失効手順があるか

PR作成とGitHub権限を分けて設計する

項目	内容	見方
Issueを読む		調査や要約のための読み取り権限として検討します。
branch作成		AI用credentialと対象repoを分けて検討します。
commitとpush		限定branchに絞り、直接pushや保護branchへの変更を防ぎます。
PR作成		人間レビュー、status checks、secret scanningを通す前提で検討します。
merge		初期導入では人間に残し、required reviewsとCODEOWNERSを効かせます。
releaseとdeploy		本番影響があるため、初期導入ではAIの権限から外します。

AI用tokenと人間用tokenを混ぜると、責任範囲、失効、監査が追いにくくなります。

AIにPRを作らせる運用は、実務ではかなり便利です。Issueからbranchを作り、修正し、テストを回し、PR本文まで作る流れは、AIコーディングの大きな価値です。ただし、PR作成を許可することと、mergeやreleaseまで許可することは違います。

PR作成まで許可してもmergeは人間へ残す

最初の運用では、AIがPRを作るところまでを上限にします。merge、release、deploy、production secret変更は人間に残します。

条件

AI作成PRには、次の保護を通します。

保護	目的
branch protection	直接pushや勝手なmergeを防ぐ
required reviews	人間レビューを必須にする
CODEOWNERS	専門領域のreviewerを固定する
status checks	lint、typecheck、testを必須にする
secret scanning	secret混入を検出する
dependency review	依存関係追加を見逃さない

AI用tokenと人間用tokenを混ぜない

AI作業に人間の個人tokenを流用すると、誰の責任で何が実行されたのか追いにくくなります。退職、異動、端末紛失、権限変更の時にも失効漏れが起きやすくなります。

根拠

GitHubのPAT docsでは、tokenは作成者の権限を超えることはできない一方、付与されたscopeやpermissionの範囲で操作できると説明されています。fine-grained PATは対象を絞れますが、用途によってはGitHub AppやGITHUB_TOKENの方が適します。

確認項目

確認	見るポイント
作成主体	AI用bot、GitHub App、個人tokenのどれか
失効	退職や事故時にすぐ止められるか
監査	audit logやPR履歴で追えるか
権限	PR作成に不要なadmin権限がないか
保管	ローカル端末に広いtokenが残らないか

人間承認フローを作業前・作業中・作業後に分ける

1. 1作業前スコープ承認

   対象repo、branch、読む範囲、編集範囲、実行コマンド、外部通信、MCP接続を決めます。

2. 2権限昇格承認

   依存関係追加、未知ドメインアクセス、secret閲覧、DB接続、CI/CD変更は一度止めます。

3. 3マージ前承認

   差分、テスト結果、外部通信ログ、MCP呼び出し、secret露出、deploy影響を確認します。

承認者は、AIが何をしたかをログで追える状態になってから判断します。

「人間承認を入れる」と言っても、どの瞬間に何を承認するかを決めていないと機能しません。AI作業では、作業前のスコープ承認、作業中の権限昇格承認、作業後のマージ前承認を分けます。

作業前に承認するもの

作業前には、AIに渡す範囲を承認します。ここで曖昧なまま始めると、作業中に「ついでにここも直す」が増えます。

確認項目

• 対象repo
• 対象branch
• 読んでよい範囲
• 編集してよい範囲
• 実行してよいコマンド
• 外部通信の有無
• MCP接続の有無
• 利用モデルやプラン
• 予算上限
• 終了条件

作業中に止めるもの

作業中に、AIが当初の範囲を超えたくなる場面があります。ここで自動的に許可しないことが大切です。

条件

次の操作は一度止めます。

操作	止める理由
依存関係追加	ライセンス、供給網、脆弱性、料金に影響する
未知ドメインアクセス	情報流出とprompt injectionの入口になる
secret閲覧	promptやログへ混入する可能性がある
DB接続	本番データや個人情報に近い
CI/CD変更	deployやsecret利用に影響する
大幅な差分拡大	レビュー不能になりやすい
破壊的コマンド	復旧不能な変更につながる

作業後にレビューするもの

作業後は、差分だけでなく、AIがどう作業したかを見ます。外部通信、MCP tool呼び出し、未実行テスト、secret露出、依存関係追加、設定変更を確認します。

評価基準

レビュー担当者は、次の表を使うと判断しやすくなります。

観点	PASS条件
差分	依頼範囲内で説明できる
テスト	必須コマンドが実行され、結果が記録されている
未実行	実行できなかった理由が明記されている
外部通信	許可済みの範囲に収まっている
MCP	呼び出したtoolと結果が追える
secret	prompt、diff、ログ、PR本文に出ていない
依存関係	追加理由、ライセンス、脆弱性確認がある
deploy影響	本番変更やrelease操作が含まれない

ツール別に最初に見る設定

項目	内容	見方
Codex		permissions、network、hooks、AGENTS.md、cloud環境のinternet access、ログと監査。
Claude Code		read-only開始、編集やbash実行の承認、sandbox、MCP接続、untrusted contentの扱い。
GitHub Copilot		organization/enterprise policy、content exclusion、cloud agent、branch protectionとの接続。
Cursor		Privacy Mode、Team Rules、Project Rules、AGENTS.md、MCP security、compliance logging。

実際の許容範囲は、プラン、契約、管理者設定、社内規程によって変わります。

ここでは勝敗をつけません。法人導入前に、各ツールで最初に見るべき設定を並べます。実際の許容範囲は、プラン、契約、管理者設定、社内規程によって変わります。

Codexで見ること

Codexでは、permissions、network、hooks、AGENTS.md、cloud環境のinternet accessを確認します。permission profileでは、:read-only、:workspace、:danger-full-accessのように権限の広さを分けられます。danger-full-accessは名前どおり広い権限なので、通常の法人パイロット初期値にしない方がよいです。

確認項目

• default permission profile
• filesystem read/write/deny
• network allowlist
• local serviceへのアクセス
• hooksでの承認・拒否
• AGENTS.mdの読み込み範囲
• cloud環境のinternet access
• ログと監査の取り方

Claude Codeで見ること

Claude Codeのsecurity docsでは、read-only初期値、明示的な許可、sandbox、prompt injection対策、MCP security、IDE securityなどが説明されています。導入時は、どのpermission modeを使うか、どのコマンドを許可するか、外部toolやMCPをどう扱うかを確認します。

確認項目

• read-onlyから開始しているか
• 編集やbash実行に承認があるか
• sandboxを使うか
• MCP接続をどう許可するか
• untrusted contentをどう扱うか
• チーム向け設定や監査が必要か

GitHub Copilotで見ること

GitHub Copilotは、Business/Enterpriseの承認資料、policies、content exclusion、cloud agent、GitHub上の権限を分けて見ます。feature policy、privacy policy、models policyを管理できる一方、content exclusionには機能ごとの制約があります。

確認項目

• organization/enterprise policy
• 利用できるfeatureとmodel
• content exclusionの対象と制約
• cloud agentの対象repo
• Actions minutesやpremium requestへの影響
• branch protection、required reviewとの接続
• Copilot用の管理者承認資料

Cursorで見ること

CursorはSecurityページでPrivacy Mode、subprocessor、team/enterprise admin、SSO/SCIM、compliance loggingなどの導線を示しています。Rules docsでは、Project Rules、User Rules、Team Rules、AGENTS.mdを使った指示管理が説明されています。ただし、Cursor自身のDocsにもある通り、AI guidanceだけをsecurity controlにしない設計が重要です。

確認項目

• Privacy Mode
• Team Rulesとenforced rule
• Project RulesとAGENTS.md
• Cloud Agent network security
• MCP security considerations
• compliance logging
• SSO/SCIM
• model blocklistや管理者設定

実務で使うなら：2週間のパイロット設計

1. Day 1

   対象repo、権限プロファイル、外部通信、MCP、承認者、終了条件を決めます。

2. Day 2-3

   read-onlyでIssue要約、失敗ログ読解、変更方針の提案までを確認します。

3. Day 4-7

   README修正、小さなbugfix、unit test追加など小差分で試します。

4. Week 2

   AI作成PRをbranch protection、required reviews、status checksに通します。

5. 判定会

   権限逸脱、secret露出、レビュー可能性、承認負荷、ログ不足を確認します。

採用判断は速度だけでなく、被害範囲の小ささと説明可能性で行います。

いきなり全社導入するより、2週間だけ小さく試す方が学びが濃くなります。目的は「AIが速いか」だけではありません。権限逸脱がないか、レビュー可能か、secretが出ないか、承認負荷が現実的かを見ます。

最初の対象タスクを選ぶ

条件

初回タスクは、次のようなものにします。

• README修正
• 小さなbugfix
• unit test追加
• 型エラー修正
• lint修正
• 依存関係を増やさない修正
• 顧客データを含まない変更
• deployに直結しない変更

パイロット終了時に採用/保留/見送りを決める

評価基準

判定	条件
採用候補	権限逸脱なし、レビュー可能、テスト再現、secret露出なし、承認負荷が低い
保留	便利だが、ログ不足、除外設定の不安、権限昇格が多い
見送り	secret露出、外部通信の説明不能、レビュー不能な大差分、merge権限要求がある

AI Dev Lab Japanでは、こうした仕様変更や導入判断のメモを継続的に追えるようにニュースレターでも更新通知を出す想定です。本文の判断材料を確認したあと、必要な時だけ購読してください。

導入前チェックリスト

項目	内容	見方
リポジトリ		対象repo、対象branch、対象ディレクトリ、除外ファイル。
秘密情報		.env、CI secrets、クラウド認証情報、外部API key。
network		allowlist、HTTP method、外部URL、通信ログ。
MCP		tool一覧、認証、read/write、監査ログ。
GitHub		token scope、branch protection、CODEOWNERS、required checks。
運用		承認者、利用申請、失効、予算、教育、インシデント、月次見直し。

チェックリストは導入時だけでなく、ツール更新時や権限変更時にも見直します。

技術チェック

カテゴリ	確認項目
リポジトリ	対象repo、対象branch、対象ディレクトリ、除外ファイル
秘密情報	.env*、CI secrets、クラウド認証情報、外部API key
filesystem	read/write/denyの範囲
network	allowlist、HTTP method、外部URL、ログ
MCP	tool一覧、認証、read/write、監査ログ
GitHub	token scope、branch protection、CODEOWNERS、required checks
テスト	lint、typecheck、unit、E2E、未実行時の記録
監査	session log、tool log、MCP log、PR履歴

運用チェック

カテゴリ	確認項目
承認者	作業前、権限昇格、merge前の担当
利用申請	誰がどのrepoで使えるか
失効	退職、異動、事故時に停止できるか
予算	利用上限、超過時の停止、月次レビュー
教育	prompt injection、secret、MCP、PRレビューの注意
インシデント	secret露出、誤PR、外部送信時の連絡先
見直し	月次またはツール更新時の再確認

法人向けにAIコーディング導入支援を検討する場合は、権限棚卸し、AGENTS.md/Rules整備、GitHub token設計、MCP read-only設計、パイロット評価表の作成から始めるのが現実的です。相談窓口はお問い合わせにまとめています。

よくある失敗と回避策

AGENTS.mdに禁止と書いたから安全

自然言語ルールは作業指示です。禁止したい操作はtoken scope、filesystem deny、network policyで止めます。

PATにrepo全体のwrite権限を渡す

流出時の影響範囲と監査負荷が大きくなります。fine-grained、期限、用途別credentialを検討します。

外部通信を許可したまま放置する

許可した後に何が送られたかまで確認します。domain allowlistとmethod制限だけで終わらせません。

パイロットでは作業成功率より、事故時の被害範囲を小さく保てるかを優先します。

「AGENTS.mdに禁止と書いたから安全」と思う

AGENTS.mdやRulesは、AIに方針を伝えるには有効です。しかし、強制境界ではありません。禁止したい操作は、token scope、filesystem deny、network policy、branch protection、required reviewで止めます。

注意点

自然言語ルールは、レビュー時に「どう振る舞うべきだったか」を説明する証跡にはなります。ただし、事故を防ぐ主防御にするには弱いです。

PATにrepo全体のwrite権限を渡す

広いPATを渡すと、短期的には楽です。しかし、流出時の影響範囲が大きく、監査も難しくなります。fine-grained PAT、GitHub App、GITHUB_TOKEN、用途別credentialを検討します。

上振れ/下振れ

権限を広げると作業成功率は上がるかもしれません。一方で、事故時の被害範囲、レビュー負荷、失効手順の複雑さも上がります。パイロットでは成功率よりも、被害範囲の小ささを優先します。

外部通信を許可したまま放置する

依存取得、公式Docs参照、Web検索、MCP接続は便利です。ただし、未知ドメインへの通信や、認証情報を含む可能性のあるログ送信は避けます。

注意点

外部通信は、許可した瞬間だけでなく、許可した後に何が送られたかまで確認します。domain allowlistとHTTP method制限を入れても、送信内容のレビューは残ります。

FAQ

個人利用と法人利用で何が違うか

法人利用では、データ利用、保持、管理者制御、監査ログ、契約条件、失効、予算まで見ます。

非公開リポジトリを読ませてもよいか

ツール、プラン、契約、データ保持、対象repo、除外設定、社内規程で答えが変わります。

MCPは危険か

MCP自体ではなく、接続先、token、write権限、外部通信、ログ、承認設計でリスクが変わります。

PR作成まで任せてもよいか

検討できます。ただしmerge、release、deployは初期導入では人間に残します。

Rulesだけで社内ルールを管理できるか

作業指示としては有効ですが、security controlには設定、権限、policyが必要です。

どの質問も、最新の公式情報、契約条件、社内規程を分けて確認します。

個人利用と法人利用で何が違いますか

法人利用では、データ利用、保持、管理者制御、監査ログ、契約条件、退職時の失効、予算管理、インシデント対応まで見ます。個人で便利に使える設定が、そのまま法人の説明責任を満たすとは限りません。

非公開リポジトリをAIへ読ませてもよいですか

ツール、プラン、契約、データ保持、学習利用、対象repo、除外設定、社内規程で答えが変わります。最初は重要度の低いrepo、顧客データを含まないrepo、secretがないrepoでパイロットするのが現実的です。

MCPは危険ですか

MCP自体を危険と決めつける必要はありません。ただし、MCP toolはAIに外部操作を渡す入口です。read-only toolから始め、write toolは人間承認を挟み、token scopeとログを確認します。

AIにPR作成まで任せてもよいですか

PR作成までは検討できます。ただし、merge、release、deployは初期導入では人間に残します。branch protection、required review、CODEOWNERS、status checks、secret scanningを通してください。

Cursor RulesやAGENTS.mdだけで社内ルールを管理できますか

作業指示としては有効です。しかし、セキュリティ境界には設定や権限が必要です。RulesやAGENTS.mdは、permission、policy、token scope、network allowlist、branch protectionと組み合わせます。

導入しない方がよいケースはありますか

あります。secretがrepo内に残っている、テストが再現できない、レビュー担当がいない、AI用tokenを分けられない、外部通信ログを確認できない、merge権限までAIに渡したい、という状態なら先に運用整備をします。

---

次に読むなら

参照した主な情報源

OpenAI / Codex

• OpenAI Codex permissions: https://developers.openai.com/codex/permissions
• OpenAI Codex agent internet access: https://developers.openai.com/codex/cloud/internet-access
• Running Codex safely at OpenAI: https://openai.com/index/running-codex-safely/
• OpenAI Codex AGENTS.md: https://developers.openai.com/codex/guides/agents-md
• OpenAI Codex hooks: https://developers.openai.com/codex/hooks

Claude Code / Cursor

• Claude Code security: https://code.claude.com/docs/en/security
• Cursor security: https://cursor.com/security
• Cursor rules: https://cursor.com/docs/rules.md

GitHub / Copilot

• Managing your personal access tokens: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens
• Resources for getting approval of GitHub Copilot: https://docs.github.com/en/copilot/tutorials/roll-out-at-scale/govern-at-scale/resources-for-approval
• Excluding content from GitHub Copilot: https://docs.github.com/en/copilot/how-tos/configure-content-exclusion/exclude-content-from-copilot
• GitHub Copilot policies: https://docs.github.com/copilot/concepts/policies

更新履歴

1. 2026年5月29日

   OpenAI Codex、Claude Code、GitHub Copilot、GitHub PAT、Cursorの公式一次情報を確認して初版を作成。

2. Codex

   permissions、internet access、hooks、AGENTS.mdの仕様を再確認します。

3. GitHubとCopilot

   PAT仕様、policies、content exclusion、approval resourcesを再確認します。

4. Claude CodeとCursor

   security docs、Privacy Mode、Rules、MCP security、管理者設定を再確認します。

5. MCP

   Resource、Tool、認証、ログ、write操作の承認条件を再確認します。

導入時や公開更新時には、記事の確認日と各ツールの最新仕様を照合します。

2026年5月29日

OpenAI Codex、Claude Code、GitHub Copilot、GitHub PAT、Cursorの公式一次情報を確認し、法人導入前の権限設計チェックリストとして初版を作成しました。

更新時に見る項目

Codex permissions/internet access、GitHub Copilot policies/content exclusion、GitHub PAT仕様、Cursor Privacy Mode/Rules、Claude Code security docs、MCP関連仕様は変わりやすいため、導入時や公開更新時に再確認します。