AIコーディングツールを試したいが、社内でどこまで許可してよいのか決められない。個人利用の延長で入れると、機密コード、秘密情報、未検証パッケージ、危険な自動実行が一気に混ざります。逆に全部禁止すると、現場は個人契約や私物端末に逃げます。
この記事は、その中間を作るためのものです。AIコーディングツールの社内ガイドラインを、何から書けばよいか分からない人向けに、最小構成のテンプレと判断基準を整理します。組織導入全体の考え方は AI の組織利用ガイド、個別リスクは バイブコーディングの脆弱性チェックリスト、サプライチェーン面は パッケージハルシネーション攻撃の解説、外部ツール接続は MCP エンタープライズ運用ガイド を前提知識として参照してください。
先に結論: ガイドラインで決めるべきは5項目だけ
社内ガイドラインが失敗する理由は、最初から長すぎることです。私なら、初版では次の5項目に絞ります。
- 何を入力してよいか
- AIにどこまで操作させてよいか
- どの変更を人間レビュー必須にするか
- どのログを残すか
- 例外を誰が承認するか
この5つが曖昧なまま「AI活用を推進する」とだけ書くと、現場では運用が割れます。あるチームは下書き専用、あるチームは npm install や本番反映まで自動化、という状態になりやすいからです。
なぜ一般的な生成AIルールだけでは足りないのか
一般的な生成AI利用規程は、「個人情報を入れない」「最終判断は人間が行う」で止まりがちです。AIコーディングではそれでは足りません。コードと開発環境には、文章生成より強い権限が絡むからです。
NIST の SP 800-218A は、生成AIや dual-use foundation models を扱うソフトウェア開発で、データ管理、モデル評価、変更管理、サプライチェーン管理を SSDF の延長で扱う必要があると整理しています。OWASP の LLM Top 10 でも、プロンプトインジェクション、機密情報漏洩、サプライチェーン、過剰権限が主要リスクに入っています。
実務で見るべき論点は、文章生成ツールより明確です。
- リポジトリや
.envをどこまで読ませるか - シェル実行や依存関係追加を自動化してよいか
- MCP や外部APIにどの権限でつなぐか
- 生成コードの責任を誰が負うか
つまり、AIコーディングツールの社内ガイドラインは、利用規程と開発統制の中間に置くべき文書です。
私が最初に分ける3つの利用レベル
導入初期は、全員に同じ権限を配らない方が安全です。私なら次の3段階で始めます。
レベル1. 提案専用
- 要件整理
- テスト観点の列挙
- コメントやドキュメントの下書き
- コード修正案の提案
このレベルでは、コードベースの読み取りは許可しても、書き込み、シェル、依存関係追加は許可しません。まずは「思考補助」として使わせる段階です。
レベル2. 限定編集
- ワークツリー内のファイル編集
- ローカルのビルドやテスト
- read-only な外部参照
ここでは、レビュー前提で編集を許可します。ただし npm install、pip install、デプロイ、Secrets 参照、MCP 経由の書き込みは止めます。多くの開発チームは、最初はここまでで十分です。
レベル3. 承認付き実行
- 依存関係追加
- マイグレーション生成
- MCP 経由の外部操作
- CI Auto-Fix や bot 実行
ここは申請制にします。便利ですが、事故のコストも上がるからです。特に依存関係追加と外部書き込みは、監査ログとロールバックの前提がないなら開けない方がよいです。
ガイドライン本文に必ず入れるべき7章
以下が、初版でも削らない方がよい章です。
1. 対象ツール
許可する製品名、プラン、ワークスペースを明記します。個人契約の野良利用を黙認するより、まず「会社が管理する環境は何か」を固定した方がよいです。
Anthropic の Team / Enterprise 向け Claude Code では、組織ポリシーで利用機能を制御できます。OpenAI 側も Codex でタスクごとの隔離環境や操作ログを前提に設計しています。ここを使わず、個人契約に任せる理由は薄いです。
2. 入力データ区分
最低でも次の3区分にします。
- 公開可
- 社内限定
- 機密・個人情報・認証情報
そして、区分ごとに「どのツールまで可か」を書きます。私なら初版は次のようにします。
- 公開可: 許可
- 社内限定: 管理ワークスペースのみ可
- 機密・個人情報・認証情報: 原則禁止
ここで重要なのは、「秘密情報を貼らない」だけではなく、ツールが自動で読むファイルも対象に含めることです。
3. 許可操作
ガイドラインでは、自然言語の曖昧表現より操作単位で書く方が運用できます。
- 読み取り: 可
- ファイル編集: 条件付き可
- ローカルテスト: 条件付き可
- 依存関係追加: 承認制
- 外部送信: 原則禁止
- 本番変更: 禁止
Claude Code や Codex のようなエージェント系ツールでは、「チャット利用」ではなく「エージェントに何を実行させてよいか」で切るべきです。
4. 人間レビュー境界
私はここを最重要に見ます。次は AI 出力をそのまま通さないと明文化します。
- 本番反映
- 権限変更
- 認証、課金、個人情報に触る変更
- 新規依存関係の追加
- 外部送信文面の確定
「最終責任は人間」では弱すぎます。どの種類の差分に、どのレビューを必須にするかまで書かないと意味がありません。
5. 依存関係とサプライチェーン
AIコーディング導入で最も見落とされやすい章です。slopsquatting や typo 系パッケージ混入を防ぐため、次を最低限入れます。
- AI提案の新規パッケージはレジストリ確認必須
- ロックファイル差分をレビュー対象に含める
- private registry / allowlist を優先
- SBOM 生成と脆弱性スキャンをCIに入れる
この論点は パッケージハルシネーション攻撃の解説 で詳しく整理しました。
6. 外部接続と MCP
MCP やブラウザ自動化、GitHub、SaaS 操作を許可するなら、接続先と権限主体を分けます。
- 人間の代理で使う OAuth
- bot / service account
- read-only
- write 可能
MCP は便利ですが、ガイドライン上は「AIツール拡張」ではなく「外部システム接続」として扱う方が安全です。詳しい設計論点は MCP エンタープライズ運用ガイド に分けています。
7. 監査・例外・停止手順
最後に、次を短く書きます。
- 利用ログの保存期間
- インシデント時の報告先
- 例外申請の承認者
- 緊急停止の方法
OpenAI の Enterprise 向け Compliance API や Anthropic の Enterprise 機能は、まさにこの監査要件に効きます。ログが取れないなら、権限を開けすぎない方がよいです。
そのまま使える初版テンプレ
以下は、私なら最初に配る最小構成です。法務文書ではなく、現場が迷わない運用文書として書いています。
# AIコーディングツール利用ガイドライン
## 1. 目的
本ガイドラインは、AIコーディングツールを用いた開発生産性向上と、機密情報保護・品質確保・監査可能性の両立を目的とする。
## 2. 対象ツール
- 会社が承認したワークスペース上の AI コーディングツールのみ利用可
- 個人契約ツールでの社内コード投入は禁止
## 3. 入力ルール
- 公開情報: 入力可
- 社内限定情報: 承認済みワークスペースでのみ入力可
- 個人情報、認証情報、秘密鍵、顧客機密: 入力禁止
## 4. 許可操作
- コード読解、要約、レビュー観点列挙: 可
- ファイル編集、ローカルテスト: チーム設定に従い可
- 依存関係追加、マイグレーション、外部送信、デプロイ: 承認制または禁止
## 5. レビュー必須項目
- 本番反映を含む変更
- 認証、課金、権限、個人情報を扱う変更
- 新規パッケージ追加
- 自動生成されたSQL、シェル、IaC
## 6. MCP / 外部連携
- 未承認サーバーの追加禁止
- write 権限を持つ接続は管理者承認必須
- bot 用資格情報と個人資格情報を分離する
## 7. 監査
- 利用ログと実行ログを保存する
- インシデント発生時は即日で管理者へ報告する
- 管理者は必要に応じて利用停止できる迷ったときの判断基準
細かい例外は必ず出ます。そこで私は、現場向けには次の4問だけ配ります。
- この入力は、外部SaaSに入れてよい情報か
- この操作は、人間がレビューせずに実行して事故らないか
- この差分は、ロールバックと監査ができるか
- この接続は、退職・異動時に中央で止められるか
1つでも曖昧なら、権限を上げない方がよいです。AI利用ルールは、技術的には「できる」ことを全部許可する文書ではありません。事故時に説明できる範囲だけを先に許可する文書です。
実務では30日でここまで決めれば十分
大企業向けの完璧なポリシーを初日から作る必要はありません。私なら30日で次の順に進めます。
- 会社が管理するツールとワークスペースを固定する
- レベル1〜2の利用者を分ける
- 入力禁止データとレビュー必須差分を明文化する
- 依存関係追加と MCP 書き込みを申請制にする
- ログ保存と停止窓口を決める
この順なら、現場を止めずに最低限の統制を先に入れられます。
まとめ
AIコーディングツールの社内ガイドラインで本当に必要なのは、きれいな標語ではありません。入力境界、実行境界、レビュー境界、監査境界です。
最初から何十ページも作るより、まずは
- 対象ツール
- 入力データ区分
- 許可操作
- レビュー必須項目
- 依存関係追加
- MCP 接続
- 監査と停止
この7章を一枚で回せる状態にした方が強いです。そこから実績に応じて広げればよいです。
AIコーディング導入は、全面解放か全面禁止かの二択ではありません。説明できる範囲だけを先に許可し、ログが取れる形で広げる。これが一番壊れにくい進め方です。