AI コーディングツールを業務に取り入れる流れは、もはや止まりません。一方で、導入を検討する組織で最後まで残る懸念がセキュリティです。「AI が書いたコードは安全なのか」「社内のソースや顧客データを外部のモデルに渡して大丈夫なのか」「うっかり危険なコマンドが実行されないか」。こうした不安は、特に金融・医療・建設・製造といったデータの機密性が高い業界ほど強く、導入の最大の障壁になります。

本記事は、AI 駆動開発のクリエイティブスタジオである FIXIT が複数のクライアントワークと社内開発で運用してきた経験から、AI 駆動開発に固有のセキュリティリスクと、それを現場で抑え込むための具体策を整理したものです。抽象的な心構えではなく、生成コードの脆弱性パターン・シークレット管理・権限設計・スキャン自動化・組織ガバナンスという順で、実装と運用に落ちる形で扱います。AI 駆動開発そのものの全体像は AI 駆動開発とは？従来開発との違い・進め方 を併せてご覧ください。

結論 — AI 駆動開発で増えるのは「リスクの量」であって「種類」ではない

先に結論を述べます。AI 駆動開発で本質的に新しい脆弱性が生まれるわけではありません。SQL インジェクションも認可漏れもシークレットのハードコードも、人間が手で書いてきた時代から存在する古典的な問題です。変わるのは、それらが生み出される速度と量です。

AI は人間より速くコードを書きます。レビューと検査の体制が追いつかないまま生成量だけが増えると、従来なら 1 件だった見落としが 10 件になる。これが AI 駆動開発のセキュリティリスクの正体です。つまり対策の方向は明確で、「生成量に見合うだけの自動検査とレビューの網を、生成より先に張る」ことに尽きます。

整理すると、AI 駆動開発で注意すべきリスクは大きく次の 4 つに分かれます。

リスク領域具体的な事象主な対策の方向
生成コードの脆弱性認可漏れ・インジェクション・古い暗号方式の再生産静的解析・セキュリティレビューの必須化
シークレット漏洩API キーや認証情報のハードコード・外部送信シークレットスキャン・入力データの線引き
過剰な権限実行エージェントによる削除・外部送信コマンドの暴走権限設定・hooks による事前ブロック
ガバナンス不在個人ごとに設定がバラバラで監査できないポリシーと標準設定の組織配布

以降で、それぞれを深掘りします。

生成コードに混入しやすい脆弱性のパターン

AI が生成するコードには、いくつか繰り返し現れる弱点があります。事前にパターンを知っておくと、レビューの目が利きます。

認可・権限チェックの抜け

最も多いのが認可の欠落です。AI に「ユーザーの注文一覧を返す API を作って」と頼むと、機能としては動くコードが返ってきます。ただし「リクエストしたユーザーが、その注文の所有者かどうか」を確認するチェックは、明示的に指示しないと抜けがちです。結果として、ID を差し替えれば他人のデータが見えてしまう、いわゆる IDOR（安全でない直接オブジェクト参照）が紛れ込みます。

AI は「動くコード」を最短で書くため、認証は実装しても認可までは踏み込まないことがある、と前提に置いてレビューします。所有者チェックや権限スコープの検証が入っているかを、データを返す API では必ず確認しましょう。

入力検証とインジェクション

文字列連結でクエリを組み立てる、ユーザー入力をそのままコマンドやテンプレートに流す、といった実装も依然として出てきます。学習データに古い書き方が大量に含まれているためです。プレースホルダを使ったパラメータ化や、入力のバリデーションを設計の前提として CLAUDE.md やルールファイルに明記しておくと、生成段階から品質が上がります。

古い暗号・ライブラリの再生産

AI は学習時点までの知識で書くため、すでに非推奨になったハッシュ方式や、既知の脆弱性を抱えた古いバージョンのライブラリを提案することがあります。依存関係の脆弱性チェックを CI に組み込み、提案された実装を鵜呑みにしない運用が要ります。

「それっぽく動く」セキュリティ実装

最も危ういのが、一見正しく見えるが実は穴のあるセキュリティ実装です。たとえば、署名検証をしているように見えて比較がタイミング攻撃に弱い、トークンの有効期限を検証していない、といったケース。動作テストは通るため、機能テストだけでは検出できません。セキュリティに関わる箇所こそ人間のレビューを厚くするのが鉄則です。生成コードを安全にマージするためのレビュー設計は AI 生成コードのレビュー設計 で詳しく扱っています。

シークレット・機密データを AI に渡さない設計

次に、入力側のリスクです。コードを書かせる過程で、機密情報がモデルに渡ってしまう経路を断つ設計を考えます。

渡してよい情報と渡さない情報の線引き

最初にやるべきは、ポリシーとしての線引きです。本番の API キー・データベース認証情報・個人情報・顧客の生データは、原則としてモデルに渡しません。代わりに、ダミー値やマスキング済みのサンプルで作業します。スキーマや構造を伝えたい場合も、実データではなく型定義やサンプルレコードで十分なことがほとんどです。

この線引きを 1 枚のドキュメントにまとめ、チーム全員に配布します。「判断を個人に委ねない」ことが事故を防ぎます。

.env や認証情報をコンテキストに含めない

.env、credentials.json、秘密鍵といったファイルは、AI ツールのコンテキストに自動で取り込まれないよう除外設定を入れます。多くのツールは無視するファイルパターンを設定でき、.gitignore と同様の仕組みで参照対象から外せます。リポジトリ単位でこの設定をコミットしておけば、新しく参加したメンバーの環境でも自動的に保護が効きます。

学習利用とデータ保持の契約確認

ツール選定の段階で、入力データが学習に使われるか、どこにどれだけ保持されるかを必ず確認します。法人向けプランの多くは学習に使わない条件を提供していますが、プランの種別で扱いが変わるため、契約条件を読み込むことが前提です。情報セキュリティ部門の承認を取る際は、「何が外部に送信され、何が送信されないか」「保持期間と保存リージョン」を明記した資料を用意すると話が早く進みます。

Claude Code / Cursor の権限・許可設定と hooks による防御

エージェント型のツールはコマンドを実行できるため、実行系の制御が安全運用の中心になります。Claude Code を例に、防御の二段構えを説明します。

権限・許可設定で操作を分類する

Claude Code には、ツールが実行する操作を「自動許可・確認・拒否」に振り分ける権限設定があります。読み取りや安全なテスト実行は自動許可にしてテンポを保ちつつ、ファイル削除・外部へのネットワーク送信・認証情報に触れる操作は確認または拒否に倒します。

ここで重要なのは、この設定をリポジトリにコミットしてチーム共通にすることです。個人ごとに設定がバラバラだと、誰かの緩い環境が組織全体の穴になります。権限設定の具体的な書き方は別記事でも触れていますが、まずは「危険な操作を明示的に止める」ことを最優先にしてください。

hooks で実行前にチェックを挟む

権限設定だけでは表現しきれない、組織固有のルールを機械的に強制したいときは hooks が有効です。hooks は、ツールがコマンドを実行する直前や、ファイルを編集した直後など、特定のタイミングに独自のスクリプトを差し込む仕組みです。

たとえば、コマンド実行前に内容を検査して rm -rf や本番環境への接続を含むものを止める、編集後にシークレットスキャンを自動で走らせて検出時に警告する、といった防御を自動化できます。実装パターンは Claude Code の hooks 実践 5 パターン にまとめているので、自社のガードレールを組む際の出発点にしてください。

権限設定が「何を許すか」の静的な宣言だとすれば、hooks は「実行の瞬間に動的に判断する」防御です。両者を組み合わせることで、想定外のコマンドが本番に届くのを多層で防げます。

脆弱性スキャンとセキュリティレビューの自動化

生成量が増える前提に立つと、人手のレビューだけでは破綻します。検査の自動化を、AI 生成かどうかにかかわらず全コードへ一律にかけるのが基本方針です。

CI に組み込むべき検査は、おおむね次の通りです。

  • シークレットスキャン: コミットやプッシュの段階で、ハードコードされた API キー・トークン・秘密鍵を検出する。検出時はマージをブロックする必須ゲートにする。
  • 静的アプリケーションセキュリティテスト（SAST）: ソースを解析し、インジェクションや認可漏れの疑いを機械的に洗い出す。
  • 依存関係スキャン: 利用ライブラリに既知の脆弱性がないかをチェックし、古いバージョンの混入を防ぐ。
  • テストの必須化: セキュリティに関わる挙動はテストで担保する。テストを先に書く進め方は AI とも相性がよく、品質の土台になります。

これらをパスしないとマージできない状態を作っておけば、AI が大量にコードを生成しても、危険なものは入口で止まります。さらに一歩進めるなら、プルリクエストのレビュー自体に AI を並走させ、人間のレビュアーが見落としやすい箇所を補完させる運用も有効です。AI の生成と AI の検査を組み合わせると、人手だけのときより検出網はむしろ広がります。セキュリティ挙動をテストで担保する具体的な設計は AIテスト自動化の実践 — 生成 AI でテストを書く設計と注意点 にまとめています。

ポイントは、検査を「AI が書いたコードだけ」に限定しないことです。出所で扱いを変えると運用が複雑になり、抜けが生まれます。すべてのコードを同じゲートに通すほうがシンプルで堅牢です。

組織導入時のガバナンス・ポリシー設計

個々の技術対策を支えるのが、組織としてのガバナンスです。とはいえ、最初からすべてを網羅した規程を作ろうとすると、いつまでも運用が始まりません。まずは最小セットを回し、育てていくのが現実的です。

優先して整備すべきは次の 3 点です。

第一に、データ取り扱いポリシー。「外部に送ってよい情報・送ってはいけない情報」を 1 枚で定義し、全員に配布します。これがすべての判断の基準になります。

第二に、権限設定と hooks の標準セット。リポジトリ共通の設定として配り、個人環境のばらつきをなくします。新規プロジェクトはこの標準を雛形として開始する運用にすると、自然に保護が効きます。

第三に、必須レビューゲート。シークレットスキャンと脆弱性スキャン、そしてセキュリティに関わる変更への人間レビューを、マージの必須条件にします。

加えて、AI ツールの利用は監査可能にしておきます。誰がどのプランでどのリポジトリに使っているかを把握できる状態を保ち、インシデントやヒヤリハットが起きたらポリシーを更新する。この「小さく始めて、事例を起点に育てる」サイクルが、デジタル後発の業界でも無理なく定着します。Claude Code を組織へ広げる全体ロードマップは Claude Code を実務に導入する完全ガイド (2026 年版) で段階別に整理しています。

FIXIT のセキュリティ運用とツール導入支援

FIXIT は AI 駆動開発のクリエイティブスタジオとして、自社のクライアントワークでここまで述べた防御を標準運用しています。権限設定と hooks のテンプレートをプロジェクト共通で配り、シークレットスキャンと脆弱性スキャンを CI の必須ゲートに据え、セキュリティに関わる変更には人間のレビューを必ず通す。AI で速度を上げながら、検査とレビューの網を先に張ることで、品質とスピードを両立させています。

ツール導入を検討する組織に対しては、データ取り扱いポリシーの整備から、情報セキュリティ部門の承認に必要な資料づくり、権限・hooks の標準セット設計、CI への検査組み込みまでを伴走支援しています。「セキュリティが不安で踏み出せない」という状態を、具体的なガードレールと運用ルールに落とすのが私たちの役割です。

まとめ

AI 駆動開発で本当に増えるのは、脆弱性の種類ではなく、生み出される速度と量です。だからこそ対策の核心は、生成より先に検査とレビューの網を張ること。生成コードの脆弱性パターンを知り、機密データを渡さない線引きを定め、権限設定と hooks で危険な実行を止め、スキャンを CI の必須ゲートにする。これらを組織のポリシーとして配布し、事例を起点に育てていけば、AI 駆動開発はむしろ安全側に倒せます。セキュリティ対策を含めたテスト・型・CI・ガードレールの多層防御は AI 駆動開発の品質保証 — テストとガードレールの全体像 で体系化しています。

セキュアな形で AI コーディングツールを業務へ組み込みたい組織は、AI 開発ツール導入支援 からお気軽にご相談ください。ポリシー設計から CI ゲートの構築まで、現場で機能する形でご一緒します。