既存コードベースに AI を導入する：ガードレールとレビュー

新規プロジェクトと違い、長年動き続けてきたコードベースにAIコーディングを入れるときは、書ける速度よりも先に「どこまで任せ、どこから人間が止めるか」を決めることが事故防止の核になります。本ガイドは、リスク評価 → 範囲・権限・品質の3層ガードレール → 段階導入 → レビューと運用までを、2026年時点の実際のツール挙動に沿って整理します。

FIG.1　AIの提案は「範囲（見せる）→ 権限（実行）→ 品質（通す）」の3関門を通してから本番へ

大事な前提を一つ。最近のAIコーディングは単なる入力補完にとどまらず、ファイルをまたいで自分で編集・実行・PR作成まで進めるエージェント機能が標準になりました（Cursor のエージェント、GitHub Copilot のagent mode / coding agent、Claude Code など）。任せられる範囲が広がったぶん、ガードレールの設計が品質を直接左右します。

01導入前のリスク評価：機密性 × 影響範囲

同じコードベースでも、ファイルごとにリスクは大きく違います。まず「AIに見せていいか（機密性）」と「壊れたときの被害（影響範囲）」の2軸でざっくり仕分けすると、後のルール設計が楽になります。

FIG.2　まず4象限でラフに仕分け。右上（高機密・高影響）から順にルールを厚くする

AIに見せる前に止めるもの（機密性）	人間レビューを厚くするもの（影響範囲）
API キー・トークン・接続文字列を含む設定（`.env` 等）	本番に直結するコード（決済・認証・課金）
個人情報・顧客データを含むコードやテストデータ	DBマイグレーション（ロールバック計画を必須に）
営業秘密・競合優位の核になるロジック	共有ライブラリ・多数の呼び出し元を持つ基盤コード

逆に、純粋なテストコードや使い捨てユーティリティは影響が局所的なので、ここでAIに慣れるところから始めると安全です。

02第1層・範囲制限：何を「見せない」か

最初の関門は、AIに渡すコンテキストを絞ることです。多くのツールが .gitignore と同じ書式の除外ファイルを持っています（Cursor の .cursorignore、GitHub Copilot の content exclusions など）。

# .cursorignore（プロジェクト直下）
.env
.env.*
secrets/
production-config/
**/credentials.json
node_modules/
dist/

ただし除外ファイルは「ベストエフォート」であり、完全な保証ではない。

ここは2026年時点で特に注意が必要な点です。Cursor は公式に .cursorignore を「best-effort（最善努力）」と位置づけており、状況によっては除外したはずのファイルが渡ってしまう不具合が起こり得ます。GitHub Copilot 側はさらに踏み込んだ制約があり、agent mode や Cloud（クラウド）エージェントは content exclusion ルールを尊重しません（2026年5月時点）。つまり「除外ファイルに書いたから安全」ではなく、本当に見せたくないものはリポジトリの外に出す・別管理にするのが原則です。秘密情報はコードではなくシークレットマネージャや環境変数で管理し、AIの作業対象ディレクトリから物理的に分離します。

03第2層・権限制限：何を「実行させる」か

エージェントが自分でコマンドを走らせたりファイルを消したりできる以上、「読み取り中心」から始めて、危険操作だけ人間承認に寄せるのが基本方針です。ツールごとに用意された権限設定を使います。

FIG.3　権限は3段で設計：安全操作は自動、変更系は要承認、危険操作は最初から拒否

具体的なツール挙動の例（2026年時点）:

Claude Code は権限モードを段階的に選べます。plan（読み取り専用で探索）、default（その都度確認）、acceptEdits（ファイル編集だけ自動承認）、dontAsk（許可リスト外は問答無用で拒否）、bypassPermissions（全許可・信頼できる隔離環境のみ）。実務では allowedTools に安全なコマンドを列挙し、dontAsk と組み合わせると「許可したものだけ自動・あとは全部拒否」の固いエージェントになります。
Cursor は実行を「都度確認」にでき、Background Agent は GitHub 連携と従量課金が前提で、Privacy Mode とは併用できません。チーム/ビジネスプランでは組織全体に Privacy Mode を強制できます。
共通の鉄則: git push・本番デプロイ・削除・送金や外部API課金につながる操作は人間の最終承認に必ず残す。最小権限（必要な範囲だけ与える）を初期値にします。

04第3層・品質ゲート：何を「通す」か

最後の関門は、人やAIが書いたかに関わらず同じ自動チェックを全コードに課すことです。AI由来かどうかで基準を変えないのがポイントです。

Lint / Format

規約違反を機械的に弾く。AIは規約を外しがちなので、ここで揃える。

テスト & カバレッジ維持

既存テストが緑であることを必須に。カバレッジが下がる変更はブロック。

セキュリティ & シークレットスキャン

脆弱性スキャンに加え、鍵の混入をCIと pre-commit（手元） の両方で検出。

人間によるPRレビュー

自動チェックを通った後、人間が意図と実装の整合を確認してからマージ。

シークレット対策は2026年の実データが効きます。GitGuardian の調査では、Copilot を使うリポジトリの鍵漏えい率は約6.4%で、GitHub 平均より約40%高いと報告されました。AIが生成したコードに鍵が紛れ込みやすいということです。GitHub の push protection は既定で多数のトークン種別（39種）を push 時にブロックしますが、それはサーバーに届いてからの防御。鍵を端末から出さないために、手元の pre-commit スキャンを併用するのが堅実です。

05段階的な導入ロードマップ

いきなりエージェントに複数ファイルを任せると、レビューが追いつかず信頼を失います。権限を一段ずつ開けていくのが定着のコツです。

補完のみ

Tab 補完だけ ON。書き方を変えずにAIの当たり外れの感覚をつかむ。

質問・説明だけ

「この関数を説明して」「テスト案を出して」。生成はまだ採用せず、読む側に徹する。

単一ファイルの変更

新規ファイル追加や1関数の書き換えまで。必ずPRに乗せて人間レビュー。

複数ファイル / エージェント

Cursor のエージェントや Claude Code で横断変更。レビューと品質ゲートをさらに厳格に。

06AIが読みやすいプロジェクトにする

ガードレールと同じくらい効くのが文脈整備です。AIは与えられた情報からしか判断できないので、プロジェクトの「地図」を用意するほど提案精度が上がり、的外れな変更が減ります。

AGENTS.md：AIエージェントへの指示書。ビルド・テストコマンド、コード規約、触ってはいけない領域を書く。複数ツールが読む共通フォーマットとして普及しつつあり、Claude Code の CLAUDE.md なども同じ役割。Cursor は .cursor/rules/ 配下に、ファイルのグロブごとにルールを分けて置く方式（必要なルールだけ文脈に読み込まれる）。
README / 各ディレクトリの説明：目的とアーキテクチャ、各モジュールの責務。
型定義・APIドキュメント：TypeScript なら型を厳密に。曖昧さが減るほどAIの誤りも減る。

07レビュー方針：AIコードの「見方」

AI生成コードはもっともらしく動くが意図とずれていることがあります。「動く」を合格ラインにしないのが第一歩です。

意図との整合

要件と実装が合っているか。指示していない範囲まで“ついでに”書き換えていないか。

過剰変更の排除

不要なリファクタや無関係な差分を削る。差分は小さく保つ。

未知のAPI検証

使ったことのないライブラリ・関数は実在と仕様を確認（後述のslopsquatting対策）。

レビュー観点はAI由来でも従来と同じく、① セキュリティ（認証・認可、入力検証）② パフォーマンス（N+1・大量データ）③ エラーハンドリング ④ テストの網羅 ⑤ 命名・規約。なお Copilot の code review 機能は2026年にエージェント型へ刷新され、プロジェクト文脈を集めてから指摘し、修正PR生成まで連携できますが、あくまで人間レビューの補助であり置き換えではありません。

Supply Chain Risk

実在しない依存を「うっかり入れる」のが今いちばん危ない

AIは存在しないパッケージ名を自信たっぷりに提案することがあります（ハルシネーション）。攻撃者はAIが頻繁に挙げる“ありそうな名前”を先回りして悪意あるパッケージとして登録します。これが slopsquatting（スロップスクワッティング）。タイプミスを突く typosquatting と違い、AIの提案パターンそのものを突くのが特徴です。

FIG.4　幻のパッケージ提案 → 攻撃者が同名を登録 → 何も知らずに install してしまう経路

2026年には実害が確認されています。AIが本物の eslint-plugin-unused-imports ではなく unused-imports という幻の名前を提案し、その名前で公開された悪意あるパッケージが2026年初めの時点でも配布され、週あたり数百回ダウンロードされていた、という報告があります。対策は明快です:

install 前に実在と素性を確認（公開元・ダウンロード傾向・リポジトリ）。AIエージェントには許可リスト外のパッケージを勝手に入れさせない。
ロックファイルでバージョン固定＋ハッシュ検証をCI/CDで徹底し、再現可能なビルドにする。
package.json の依存追加は人間承認のステップを必ず挟む。

08よくある事故と処方箋

起きがちな事故	仕組みでの対策
APIキーを含む変更がPRに混入	pre-commit と push protection の二重スキャン＋秘密はリポジトリ外管理
古い依存を勝手にアップグレード	`package.json` 変更を要承認。lock を固定しCIで差分検知
実在しないライブラリを追加	依存追加に許可リストゲート（slopsquatting対策）
テストが壊れたまま commit	CIで必ずブロック。緑でなければマージ不可
“ついで”の大規模リファクタ	1PR=1目的。差分が大きすぎる提案は突き返す

AI生成コードのリスクは精神論ではなく実数で語れる段階に入りました。ある2026年の調査では、主要LLMが生成したコードサンプルのおよそ4件に1件に確認された脆弱性が含まれていたと報告されています。だからこそ「AIが書いたから速い」ではなく「人間と同じゲートを必ず通す」運用が前提になります。

09組織としての運用

ツールと契約形態を統一：Copilot Business / Enterprise は入力データを学習に使わない方針（プロンプト等は一定期間＝28日保持）。Cursor もチーム/ビジネスで Privacy Mode を組織強制できる。プランによって守られ方が違うので、無料/個人プランのまま業務コードを入れない。
監査ログ：エンタープライズ向けにはAIコードの監査ログやSSO/SCIMが用意される。誰が何を生成・マージしたか追えるようにする。
ガイドラインを定期更新：ツールの挙動（除外ファイルの限界、agentの権限）はバージョンで変わる。半年単位で見直す。
インシデント共有：鍵漏えいや幻パッケージの“ヒヤリ”は匿名でも共有し、次のガードレールに反映する。

10まとめ

既存コードベースへのAI導入は、ツールの賢さよりガードレールの設計が成否を分けます。要点は3つ。① 見せないもの（秘密・顧客データ）はリポジトリの外へ出す（除外ファイルは保証ではない）。② 権限は読み取りから始め、危険操作は人間承認に残す。③ 品質ゲートはAI由来かに関わらず全コードに等しく課す。小さく権限を開けながら、依存追加と鍵の取り扱いだけは最後まで人間が握る——これが2026年時点での堅実な進め方です。次は、AIに良いコードを書かせるためのコーディング用プロンプトの書き方へ進みましょう。