AI コーディングエージェントは「チャット AI」とは別物
AI コーディングエージェントは質問に答えるだけの AI ではありません。ソースコード、設定ファイル、ターミナル、CI/CD、パッケージ管理、ブラウザ操作 まで含めて、開発行為そのものに入り込んできます。便利な一方で、取り扱う対象がそのまま会社の設計資産・秘密情報・本番システムです。
この違いを理解しないまま導入すると、社内では「便利な開発支援ツールを入れただけ」の認識でも、実際には 未信頼の repo / 顧客データ / 社内認証情報 / 外部通信を同居させた実行基盤 を作っていることになります。ここに統制の空白が生まれます。
最初に誤解されやすい 3 つの錯覚
- 「承認ボタンがあるから安全」 ── エージェントが自動承認モード（YOLO mode）で起動するケースがある。デフォルト設定の確認なしでは意味がない
- 「履歴が残るから追跡できる」 ── ローカル端末のログだけでは社内 SOC に転送されない。クラウド SaaS 側のログ保持期間も契約条件次第
- 「社内 PC で動くから外部通信していない」 ── ほとんどのエージェントは推論を外部 API で実施。社内 PC で動いていても通信先は外部
「どのデータにアクセスできるのか」「どこへ通信できるのか」「誰が設定を変えられるのか」── この 3 つを決めて初めて運用の入口に立てます。
企業が最初に決めるべき 7 項目
| # | 項目 | 決めること | 曖昧だと起きること |
|---|---|---|---|
| 1 | データ区分 | 入力してよいコード・顧客情報・設計資料の線引き | 機密情報がクラウド側へ流れる |
| 2 | 未信頼 repo の扱い | 外部 repo・OSS フォークをどの環境で開くか | repo 由来の設定ファイル・スクリプトで事故が起きる |
| 3 | 秘密情報の置き方 | API キー・PAT・SSH 鍵の発行方法と寿命 | 常駐キーが漏えいすると被害が広がる |
| 4 | 実行権限 | 読み取り・編集・コマンド実行・外部通信の範囲 | 作業主体が強すぎて誤動作の影響が大きくなる |
| 5 | レビュー手順 | 何を人が見るか・どこまで自動で流してよいか | 生成物がそのまま本番へ入る |
| 6 | 監査と記録 | 誰が何を実行し、どこへ接続したかの残し方 | 事故後に追跡できない |
| 7 | インシデント対応 | 漏えい時の初動・報告先・鍵のローテーション手順 | 事故対応が属人化する |
① データ区分 ── どこまでが「投入してよい」か
すべての社内データを「公開」「内部限定」「機密」「極秘」の 4 段階に分け、エージェントに投入可能なクラスを明示します。とくに 顧客提供のソースコード（NDA 対象）・未公開特許の発明開示資料・人事評価データ・M&A 関連文書 は基本投入禁止クラス。投入可否の判断を開発者個人に委ねず、リポジトリ単位で許可リスト方式にするのが運用しやすいです。
② 未信頼 repo の扱い ── OSS フォーク・他社受領コードをどう開くか
GitHub から clone しただけの repo を、エージェントが「ファイル読み込み + ターミナル実行可」モードで開くと、リポジトリ内の .cursorrules や CLAUDE.md・postinstall スクリプト経由でプロンプトインジェクション・任意コード実行のリスクがあります。対策は 未信頼 repo はコンテナ（Dev Container / Codespace / 専用 VM）でのみ開く ことを義務化。ローカル直接 clone を禁止します。
③ 秘密情報の置き方 ── 長寿命キーを使わない
「禁止」と書くだけでは回りません。長寿命キー（GitHub PAT / DB password / AWS Access Key）を社員 PC に常駐させない ことが核です。必要な場合は短命トークン（1Password CLI / AWS SSO / GitHub App installation token）を都度発行。リポジトリには絶対に .env をコミットしない。シークレットスキャナー（GitHub Secret Scanning / TruffleHog）を CI に組み込んで防壁にします。
④ 実行権限 ── YOLO モードを禁止
多くのエージェントは「自動承認モード（全コマンド許可）」を持っています。Claude Code の --dangerously-skip-permissions、Cursor の YOLO mode、Aider の --auto-commit 等。これらは 本番接続のあるリポジトリでは原則禁止。開発作業ごとに「読み取り専用」「ファイル編集まで」「コマンド実行まで」「外部通信まで」を段階的に許可する設計が必要です。
⑤ レビュー手順 ── 自動マージ禁止が原則
エージェントが作成した PR を「テスト通過 → 自動マージ」する運用は、本番影響のあるリポジトリでは原則禁止。人間レビュー必須とし、変更ライン数の閾値（例: 200 行以上は必ず 2 名レビュー）・影響範囲ラベル（DB マイグレーション・認証・課金）に応じたエスカレーションを設計します。
⑥ 監査と記録 ── ローカルログだけでは不十分
エージェントの操作ログを 社内 SIEM（Splunk / Datadog / Sentinel）に常時転送 します。「誰が、いつ、どの repo に、どのコマンドを実行し、どこへ通信したか」を追跡可能に。クラウド SaaS 側の admin audit log（Cursor for Business / GitHub Copilot Enterprise audit）と組み合わせることで監査要件を満たせます。
⑦ インシデント対応 ── 鍵漏えい時の初動手順
エージェント経由でキーが流出したと疑われた場合の 初動 30 分 を文書化。① 該当キーの即時失効（IdP / Vault / Secrets Manager 上で revoke） → ② 影響範囲調査（過去 7 日分のアクセスログ確認） → ③ 関係者通知 → ④ 報告書作成、までを CSIRT 手順書に組み込みます。
最低限そろえたい社内標準（チェックリスト）
- ☐ 未信頼 repo は隔離環境（Dev Container / Codespace / 専用 VM）でのみ開く
- ☐ 全面許可モード（YOLO / dangerous-skip-permissions）を標準設定にしない
- ☐ 本番資格情報を開発用エージェントの環境に置かない
- ☐ レビューなしの自動マージを禁止する（main ブランチへのマージは 2 名承認）
- ☐ 部門ごとに許可されたユースケースを定義する（営業 OK / 法務 NG 等）
- ☐ シークレットスキャナーを CI に組み込む
- ☐ エージェント操作ログを社内 SIEM に転送し 1 年以上保持する
- ☐ 月次でアクセスログをサンプリングレビューする運用を整える
主要 AI コーディングエージェントの設定値マッピング
主要なエージェントが、上述の 7 項目をどう実装しているかをマップしておきます。導入前のセキュリティ評価チェックリストとしてご活用ください。
| ツール | 提供形態 | セキュリティ機能 | 監査ログ | 備考 |
|---|---|---|---|---|
| Claude Code | CLI（Anthropic） | 権限プロンプト・hooks による独自ガード | セッションログ（要 export 設定） | --dangerously-skip-permissions の利用ポリシー必須 |
| Cursor | IDE（Cursor for Business） | SSO・Privacy Mode・組織管理画面 | Admin Audit Log（Enterprise） | Privacy Mode 強制が組織設定可能 |
| GitHub Copilot Workspace | SaaS（GitHub Enterprise） | SSO・SAML・content exclusion | GitHub Audit Log に統合 | 既存 GitHub Enterprise 統制が流用可 |
| Aider | OSS CLI | --auto-commit を切る等の自己設定 | 標準提供なし（手動設定必要） | 自社 LLM と組み合わせ可能 |
| Devin | SaaS（Cognition Labs） | サンドボックス環境 | セッション動画記録 | クラウド完全実行型 |
| Cline / Roo Code | IDE 拡張 | 承認モード設定 | VS Code 拡張ログ | ローカル LLM 接続可 |
大企業で推奨される 3 層運用モデル
大企業では、全社一律に同じ設定で使うより、情報区分に応じて運用モデルを分ける 方が現実的です。社外公開前提の軽い開発支援と、顧客案件や基幹システム開発を同じ基盤で扱うのは無理があります。
| 層 | 対象業務 | 推奨基盤 | 制約 |
|---|---|---|---|
| 標準業務層 | 社内ツール開発・自動化スクリプト・社内ドキュメント整備 | Cursor / Claude Code（クラウド SaaS） | Privacy Mode 強制・機密ラベル付きデータ投入禁止 |
| 機密業務層 | 顧客案件開発・特許関連コード・受領 NDA 案件 | 同上（クラウド）+ 隔離環境・短命認証 | Dev Container 必須・1 日単位トークン・自動マージ禁止 |
| 高機密業務層 | 金融・公共・防衛系・未公開 M&A 関連開発 | ローカル LLM（Llama 3.3 70B 等）+ オンプレ実行基盤 | 外部通信完全遮断・エアギャップ・全操作 SIEM 記録 |
この分離があると、セキュリティ部門は「一律禁止」に頼らずに済み、現場は業務特性に合った AI 活用ができます。逆にこの仕分けがないと、利便性を優先した部門が勝手に広い権限で使い始め、あとから統制が追いつかなくなります。
よくある事故パターン 5 件と再発防止策
| 事故パターン | 原因 | 再発防止策 |
|---|---|---|
| API キーの公開リポジトリへの混入 | .env ファイルをコミット / エージェントが認証情報をハードコード | pre-commit hook + シークレットスキャナー + 短命トークン化 |
| 未信頼 repo 経由のプロンプトインジェクション | 悪意のある CLAUDE.md / .cursorrules が repo に同梱 | 未信頼 repo は隔離環境必須・ルールファイル監査 |
| 本番 DB への破壊的操作 | 自動承認モードで rm / DELETE 文を実行 | 本番接続環境では人間承認必須・読み取り専用接続強制 |
| 顧客 NDA データの外部送信 | 機密ラベル付き repo でクラウド AI を起動 | repo メタデータでエージェント起動制御・Privacy Mode 強制 |
| ライセンス違反コードの混入 | エージェントが GPL コードを丸ごとコピー | OSS ライセンスチェッカー（FOSSA / Snyk）を CI に組込み |
導入を急がないための進め方（5 ステップ）
AI コーディングエージェントは、まず小さく試し、その結果を見て広げるのが基本です。とくに大企業では、技術検証より先に 利用ルールと責任分界を先に決めた方が、結果的に導入が速くなります。「使いたい人だけ使ってください」では運用が回らないからです。
- 対象部門とユースケースを絞る ── 例：DX 推進部の社内ツール開発 1 案件、10 名以下から開始
- 入力禁止情報と権限設定を決める ── データ区分・YOLO モード禁止・短命認証を社内規程に追記
- 隔離環境と監査ログを整える ── Dev Container 標準化・SIEM 連携・1 ヶ月のドライラン
- 数チームで検証し、事故パターンを先に洗い出す ── 想定漏えい・想定誤操作シナリオを実際に発生させて初動訓練
- 必要に応じてローカル LLM やオンプレミスへ切り替える ── 高機密業務はクラウド一択にしない判断
導入判断で迷う企業ほど、クラウド一択で考えない方が安全 です。社内ルール設計と一緒に、ローカル LLM やオンプレミスの選択肢まで含めて比較することで、あとから大きなやり直しを避けやすくなります。
よくある質問（FAQ）
Q. GitHub Copilot Enterprise を契約していれば、これだけの設計は不要では？
A. Copilot Enterprise は「学習に使わない」「監査ログがある」までは標準提供しますが、未信頼 repo の隔離・本番認証情報の分離・YOLO モード制御は 組織側で別途設計が必要 です。Enterprise 契約 = 安全運用ではありません。
Q. 自動承認モード（YOLO mode）を完全禁止すべきですか？
A. 環境による分離が現実的です。① 個人検証用 sandbox では許可、② 社内 repo 接続環境では制限付き、③ 本番接続環境では完全禁止、の 3 段階で運用するのが定石。「全部禁止」は開発者の離反を招きます。
Q. 小規模スタートアップでもここまで必要ですか？
A. 7 項目すべてではなくても、③ 秘密情報・④ 実行権限・⑤ レビュー手順 の 3 つは最低限。とくに本番 DB に接続する開発環境では必須です。シードフェーズで疎かにすると、シリーズ A 以降のデューデリで指摘されます。
Q. ローカル LLM に切り替えれば、この設計はいらない？
A. いいえ。外部通信が遮断されても、未信頼 repo 経由のプロンプトインジェクション・実行権限の暴走・人間レビュー不足による品質事故は同じく発生します。ローカル LLM はデータ持ち出しリスクを下げますが、運用統制は別途必要です。
まとめ
AI コーディングエージェントの導入で本当に難しいのは、モデルの精度ではなく、誰にどこまでの実行権限を渡すか です。大企業では、権限設計の甘さが、そのまま監査不備や情報漏えいリスクになります。
だからこそ、導入の最初に社内ルールと責任分界を決める必要があります。データ区分・未信頼 repo の扱い・秘密情報の置き方・実行権限・レビュー手順・監査記録・インシデント対応の 7 項目を、各部門の現状に合わせて文書化するのが第一歩です。高機密業務まで見据えるなら、ローカル LLM やオンプレミス生成 AI を前提にした設計も早い段階から比較対象に入れるべきでしょう。
はてなベースでは、社内 AI ガバナンス策定・データ区分設計・SIEM 連携・運用ハンドブック作成までを伴走支援しています。「クラウド型を入れたいが、社内ルールが追いついていない」という段階でも、無料相談からスタートいただけます。
関連 LP・関連記事
- AI ガバナンス整備支援 ── 社内 AI ルール策定・運用ハンドブック作成の伴走支援
- Claude エンタープライズ法人導入支援 ── SSO・監査ログ・部署別ガバナンスを含む全社導入
- 大企業こそローカル LLM とオンプレミス生成 AI を検討すべき理由 ── 関連記事
- Claude Code の脆弱性から考える、クラウド型生成 AI を業務で使うときの注意点 ── 関連記事