AIコーディングエージェントを安全に導入するための社内ルール設計
企業が最初に決めるべき7項目
目次
- なぜ「便利な開発ツール」では済まないのか
- ルールがないと起きる事故シナリオ5選
- 企業が最初に決めるべき7項目（詳細解説）
- 大企業で実際に採用されている3層運用モデル
- 「明日から始められること」チェックリスト
- まとめ
1 なぜ「便利な開発ツール」では済まないのか
まず、AIコーディングエージェントが従来のツールとどう違うのかを整理します。
| 機能 | 従来のコード補完 （例：旧Copilot） |
AIコーディングエージェント （例：Claude Code、Devin） |
|---|---|---|
| コードの提案 | ○ カーソル位置で候補を表示 | ○ 提案だけでなく自動で書く |
| ファイルの読み書き | × 表示中のファイルのみ | ○ プロジェクト全体を読み書き |
| コマンド実行 | × | ○ ターミナルでコマンドを実行 |
| 外部サービスとの通信 | × | ○ API呼び出し、Git操作、デプロイ |
| 設定ファイルの読み込み | 限定的 | ○ .envやAPIキーを含むすべてのファイル |
つまり、こういうことです
AIコーディングエージェントに開発環境を渡すことは、「新入社員にオフィスの鍵、金庫の暗証番号、全取引先の連絡先を渡して自由に仕事してもらう」ことに近い行為です。能力は高いかもしれませんが、ルールなしでは何が起きるかわかりません。
2 ルールがないと起きる事故シナリオ5選
「うちのエンジニアはちゃんとしているから大丈夫」——そう思う方にこそ読んでいただきたい、実際に起こりうるシナリオです。
シナリオ①：顧客データがAIの学習サーバーへ
エンジニアがバグ修正のため、顧客データを含むログファイルをプロジェクトに置いたまま、AIエージェントに「このバグを直して」と指示。AIはログファイルも含めてプロジェクト全体を読み込み、顧客の個人情報がクラウドのAIサーバーに送信されてしまいました。
損害：個人情報保護法に基づく報告義務、顧客への通知、監督官庁への報告。対応コスト数千万円。
シナリオ②：AWSの請求が月500万円に
開発環境に本番用のAWSアクセスキーが.envファイルに保存されていました。AIエージェントの脆弱性を突かれ、アクセスキーが外部に漏えい。攻撃者がこのキーを使って暗号通貨マイニング用のサーバーを大量起動し、翌月のAWS請求が500万円に。
損害：不正利用分のクラウド費用、セキュリティ調査費用、全キーのローテーション作業。
シナリオ③：退職者のOSSリポジトリから社内侵入
エンジニアが退職者が公開していたOSSリポジトリをクローンし、AIエージェントで解析しようとしました。このリポジトリには、AIエージェントの設定を書き換える悪意ある設定ファイルが仕込まれており、社内のGitHub認証トークンが外部に送信されてしまいました。
損害：社内リポジトリ全体への不正アクセスリスク、全社的なトークン無効化と再発行。
シナリオ④：AIが生成したコードがそのまま本番へ
AIエージェントが生成したコードを、レビューなしで自動マージする設定にしていた結果、SQLインジェクション脆弱性を含むコードが本番環境にデプロイされてしまいました。攻撃者にデータベースの内容を抜き取られました。
損害：顧客データの流出、サービス停止、信頼回復に数年。
シナリオ⑤：競合に自社のアルゴリズムが漏れる
データサイエンティストが、自社開発の独自アルゴリズムをAIエージェントに渡して最適化を依頼。クラウド型AIの利用規約では「入力データを学習に使用しない」とあったが、サーバーログにはデータが残っており、サーバー侵害時に競合に渡るリスクがありました。
損害：数年かけて開発した競争優位の喪失。金額換算は困難だが、事業インパクトは甚大。
3 企業が最初に決めるべき7項目（詳細解説）
項目① データ区分 ― 何をAIに入れてよいか
✗ ルールなし：「各自の判断で」
○ ルールあり：「データを3段階に分類し、段階ごとに入力可否を明示」
社内データを以下の3段階に分類します：
- Green（入力OK） ― 公開情報、社内周知文、一般的なコードスニペット
- Yellow（条件付き） ― 社内限定の設計文書、テストデータ（匿名化済み）
- Red（入力禁止） ― 顧客データ、本番認証情報、未公開の事業計画、特許出願前の技術情報
この分類を部門ごとに作成し、新しいAIツール導入時に必ず適用します。
項目② 未信頼リポジトリの扱い ― 知らないフォルダを開くリスク
✗ ルールなし：「GitHubからcloneして自由に解析」
○ ルールあり：「外部リポジトリは隔離環境（サンドボックス）でのみ開く」
2026年のClaude Code脆弱性では、リポジトリ内の設定ファイルによって安全確認をバイパスできる問題がありました。外部リポジトリには悪意ある設定が含まれている可能性があります。
具体的な対策：
- 外部リポジトリはDockerコンテナやVM内でのみ開く
- ネットワークアクセスを制限した環境で解析する
- 社内リポジトリと外部リポジトリを同じ環境で同時に開かない
項目③ 秘密情報の管理 ― APIキーを「そのへんに置かない」
✗ ルールなし：「.envファイルにAWSキーを書いて開発」
○ ルールあり：「長期間有効なキーは禁止。短命トークンをシークレットマネージャーから都度取得」
AIエージェントはプロジェクト内のすべてのファイルを読めます。.envファイルやconfig.jsonに書かれたAPIキーも例外ではありません。
具体的な対策：
- AWS Secrets Manager、HashiCorp Vault、1Passwordなどのシークレットマネージャーを使用
- キーの有効期間を最大24時間に設定
- 本番環境のキーを開発環境に置くことを禁止
- キーの利用ログを監査システムに連携
項目④ 実行権限 ― AIにどこまでやらせるか
✗ ルールなし：「全権限で自由に使わせる」
○ ルールあり：「業務に必要な最小限の権限のみ付与」
AIエージェントには「読む」「書く」「実行する」「通信する」の4つの権限があります。すべてをONにするのではなく、業務に応じて制限します。
| 業務内容 | 推奨権限 |
|---|---|
| コードレビュー | 読み取りのみ（書き込み・実行は不可） |
| バグ修正 | 読み書き可、コマンド実行は承認制 |
| テスト自動化 | 読み書き・実行可、外部通信は制限 |
| デプロイ補助 | すべて可、ただし人の承認を必須とする |
項目⑤ レビュー手順 ― AIの成果物を誰がチェックするか
✗ ルールなし：「AIが作ったコードを自動マージ」
○ ルールあり：「AIの成果物は必ず人がレビューしてからマージ」
AIが生成したコードには、セキュリティ脆弱性やライセンス違反のコードが含まれる可能性があります。
具体的な対策：
- AIが作成したPull Requestには「AI-generated」ラベルを自動付与
- AIが作成したコードは通常のコードレビューに加え、セキュリティチェックを必須化
- 本番環境に直接デプロイすることを禁止（ステージング環境を必ず経由）
項目⑥ 監査と記録 ― 「何が起きたか」を追跡できるようにする
✗ ルールなし：「ログは取っていない」
○ ルールあり：「全操作ログを記録し、90日以上保持」
事故が起きたとき、「誰が・いつ・何をAIに指示し・AIが何を実行し・どこに通信したか」を追跡できなければ、原因究明も再発防止もできません。
記録すべき項目：
- ユーザーの指示内容（プロンプト）
- AIが読み込んだファイルの一覧
- AIが実行したコマンドとその結果
- 外部への通信先と送信データの概要
- 生成されたコードやファイルの変更内容
項目⑦ インシデント対応 ― 事故が起きたときの初動
✗ ルールなし：「事故が起きたらその場で考える」
○ ルールあり：「対応手順書を事前に作成し、四半期ごとに訓練」
AIエージェント経由の情報漏えいが発生した場合の初動手順を事前に決めておきます。
初動チェックリスト例：
- 該当AIエージェントの利用を即時停止
- 漏えいした可能性のあるAPIキー・トークンを全て無効化
- 影響範囲の特定（どのデータが・どこに送信されたか）
- 情報セキュリティ責任者への報告（発覚から1時間以内）
- 必要に応じて顧客・監督官庁への報告準備
- 原因究明と再発防止策の策定
4 大企業で実際に採用されている3層運用モデル
大企業では、「全社一律のルール」よりも、業務の機密度に応じた3層の運用モデルが現実的です。
| 層 | 対象業務 | AI環境 | 主なルール |
|---|---|---|---|
| 第1層：一般業務 | 社内文書作成、公開情報のリサーチ、コードスニペットの生成 | クラウドAI（ChatGPT、Claude等） | Green データのみ入力可、利用ログを記録 |
| 第2層：機密業務 | 顧客案件の開発、社内システムの保守、テストデータの処理 | 閉域クラウドまたは社内AI基盤 | 隔離環境で利用、短命トークン、レビュー必須 |
| 第3層：高機密業務 | 基幹システム開発、個人情報処理、未公開技術の研究 | オンプレミスAI / ローカルLLM | 外部通信禁止、監査ログ完全記録、承認制 |
3層モデルのメリット
「AI利用を全面禁止」する必要がなくなります。一般業務ではクラウドAIの利便性を享受しつつ、機密業務では安全な環境で活用できます。「禁止」から「適切な使い分け」への転換が可能になります。
5 「明日から始められること」チェックリスト
すべてを一度に整備する必要はありません。まず以下の項目から始めてください。
今週中にできること（コストゼロ）
- □ 社内で誰がどのAIコーディングエージェントを使っているか把握する
- □ 本番環境のAPIキーが開発環境の.envファイルに置かれていないか確認する
- □ AIエージェントの自動マージが有効になっていないか確認する
今月中にできること
- □ 社内データの3段階分類（Green/Yellow/Red）を作成する
- □ 「AIエージェントに入れてはいけないデータ」の一覧を全エンジニアに周知する
- □ 外部リポジトリを開く際の隔離環境ルールを定める
四半期以内にできること
- □ 7項目すべてのルールを文書化する
- □ インシデント対応手順を策定し、机上訓練を実施する
- □ 高機密業務向けにローカルLLM/オンプレミスAIの導入を検討開始する
6 まとめ
AIコーディングエージェントは、正しく使えば開発生産性を劇的に向上させます。しかし、ルールなしの導入は「鍵をかけずにオフィスを開放する」のと同じです。
本記事で紹介した7項目は、技術的に難しいものではありません。必要なのは、「AIに何をさせてよいか」を組織として明確に決めることです。
- データ区分を明確にし、入力禁止の範囲を定める
- 外部リポジトリは隔離環境で開く
- APIキーは短命トークンに切り替える
- AIの権限は最小限に設定する
- AIの成果物は必ず人がレビューする
- すべての操作ログを記録する
- 事故対応の手順を事前に準備する
これらを整備すれば、AIの力を安全に業務に取り込むことができます。
はてなベースでは、AIコーディングエージェントの社内ルール策定から、
セキュリティ設計、オンプレミスAI基盤の構築まで一貫して支援しています。
「自社に合ったAI導入の進め方を相談したい」という方は、お気軽にお問い合わせください。
