AI駆動開発のセキュリティ対策｜機密情報を守るために弊社が実施していること

生成AIを活用した開発では、従来よりも速いスピードで調査、設計、実装、テストを進められるようになりました。

一方で、AIを開発工程に取り入れる以上、私たちは「便利だから使う」だけでは不十分だと考えています。

特に重要なのが、お客様からお預かりする情報、認証情報、個人情報、非公開のソースコードなどを、どのように守りながらAIを活用するかという点です。

テイルウインドでは、AI駆動開発を進める際に、単一のルールや担当者の注意力だけに頼らず、複数の仕組みを組み合わせた情報保護を行っています。

この記事では、具体的な内部設定やセキュリティ上公開すべきでない情報は伏せながら、私たちがどのような考え方でAI駆動開発のセキュリティを設計しているのかをご紹介します。

「AIに入力しない」だけでは十分ではない

生成AIのセキュリティ対策というと、

「個人情報を入力しない」
「パスワードを貼り付けない」
「機密情報をプロンプトに書かない」

といったルールがまず思い浮かびます。

もちろん、これらは非常に重要です。

ただし実際の開発現場では、人が意図的に入力しなくても、AI開発ツールがファイルを読み取ったり、検索結果やコマンドの出力から情報を取得したりする可能性があります。

そのため私たちは、単なる注意喚起ではなく、

「そもそもAIが機密情報へアクセスしにくい構造にする」

ことを重視しています。

1. AIが触れてよい情報と、触れてはいけない情報を分ける

AI駆動開発では、AIエージェントがソースコードやファイルを読みながら作業するケースがあります。

そこで、環境設定、認証情報、秘密鍵、本番データなど、AIが参照する必要のない情報については、あらかじめアクセスを制限しています。

仮にAIがそのファイルを読もうとしても、仕組み側で止める考え方です。

また、アクセスが拒否された場合に「何とか別の方法で読み取る」のではなく、

• ダミー値を使う
• データの構造だけ確認する
• 変数名だけを確認する
• 必要な情報だけ人が判断して伝える

といった代替手段へ切り替えます。

AIを便利に使うことよりも、機密情報へ触れないことを優先する運用です。

2. ソースコードに秘密情報を混入させない

AIが安全でも、作成したコードや設定ファイルにパスワード、APIキー、認証トークンなどが含まれてしまえば意味がありません。

そこで、ソースコードを登録する前と、共有リポジトリへ反映した後の双方で、秘密情報が含まれていないか自動検査しています。

ポイントは、検査を一度だけにしていないことです。

開発者のPC上では、できるだけ早い段階で問題を発見します。

さらに共有環境側でも再度確認することで、ローカル側の設定ミスや検査の迂回があった場合にも検知できるようにしています。

つまり、

「登録前に止める仕組み」と「登録後にも必ず確認する仕組み」

を分けています。

AI駆動開発では変更量が多くなりやすいため、人間がすべての差分から秘密情報を目視で探す方法には限界があります。

こうした確認こそ、自動化との相性が良い領域だと考えています。

3. 情報を置く場所そのものを分ける

もう一つ重要なのが、情報を一か所に集めすぎないことです。

私たちの開発では、ソースコードを扱う場所と、

• 契約に関する情報
• お客様との打ち合わせ内容
• 分析資料
• 本番環境の実測値
• 社内管理情報

などを扱う場所を分離しています。

開発用のリポジトリには、開発に必要な情報だけを置きます。

「AIに読ませないよう気を付ける」のではなく、そもそもAIが作業する場所へ不要な機密情報を置かないという考え方です。

これは、人が誤って情報をコピーするリスクの軽減にもつながります。

4. 情報の持ち出し先も制限する

セキュリティでは、「何を読むか」だけでなく「どこへ出せるか」も重要です。

そのため、開発データやソースコードを送信してよい共有先をあらかじめ管理し、想定外の場所へ送信されないようにする仕組みも取り入れています。

AI開発では、複数の作業環境や自動化ツールを組み合わせることがあります。

だからこそ、担当者が毎回送信先を目視確認するだけではなく、許可された経路だけを使うという考え方を採用しています。

5. AIだけではなく、完成するシステム自体も検査する

AI駆動開発におけるセキュリティというと、AIへの情報流出だけが注目されがちです。

しかし本来重要なのは、完成するシステムそのものが安全であることです。

そのため私たちは、

• ログへの機密情報出力
• 認証情報の扱い
• 権限管理
• ファイルへの直接アクセス
• 不要な外部送信
• 入力値の検証
• レート制限
• 不正なファイルアップロード
• CSVなどを経由した攻撃
• 依存ライブラリの既知脆弱性

なども継続的に確認しています。

AIが高速にコードを書くほど、「動くかどうか」だけを評価していると問題を見落としやすくなります。

そのため、機能テストとは別に、セキュリティ上変更してはいけない箇所を監視する検査も組み込んでいます。

6. 「テストが通った＝安全」とは考えない

私たちが特に重視している考え方の一つです。

通常のテストは、

「ログインできるか」
「登録できるか」
「CSVを出力できるか」

といった機能確認には非常に有効です。

一方で、

「ログに余計な情報が出ていないか」
「セキュリティ設定が弱くなっていないか」
「認可チェックが削除されていないか」

といった問題は、システム自体が正常に動いてしまうため、通常のテストでは検知できない場合があります。

そこで、機能テストとは別にセキュリティ設定やコード構造を監視する仕組みを用意しています。

AIによる修正で意図せず安全性が後退する、いわゆるセキュリティの退行を防ぐためです。

7. 問題が見つからないことより、「検査できていること」を重視する

セキュリティ検査で怖いのは、

「問題がありませんでした」

ではなく、

「実は検査自体が動いていなかった」

という状態です。

そのため、私たちは検査ツールが正常に動かなかった場合にも、原則として異常として扱う考え方を採用しています。

問題がないから成功なのか。

それとも確認できていないだけなのか。

この2つを区別することは非常に重要です。

セキュリティの世界では、このように異常時には安全側へ倒す設計を「Fail Close」と呼びます。

私たちのAI駆動開発でも、この考え方をできるだけ取り入れています。

8. 自動化だけに任せず、人が判断する領域も残す

一方で、すべてをAIや自動検査だけで判断できるとは考えていません。

例えば、

• 本番データを確認する必要がある場合
• 認証方式を変更する場合
• 外部サービスへ新たに情報を送る場合
• セキュリティ設定の例外を設ける場合
• 既存仕様との互換性と安全性が衝突する場合

などは、人による判断が必要です。

特にお客様との契約やNDAに関係する内容については、AIエージェントが独断で判断しないようにしています。

自動化すべき領域と、人が責任を持って判断すべき領域を分けること。

これもAI駆動開発では重要な設計の一つだと考えています。

AIを使うから管理が緩くなるのではなく、AIを使うから管理を強くする

生成AIによって、開発のスピードは今後さらに速くなっていくと考えています。

しかし、開発速度が2倍、3倍になれば、変更されるコード量も、扱う情報量も増えていきます。

だからこそ、人間の注意力だけに頼った管理では追いつかなくなります。

私たちはAI駆動開発を、

「AIに自由に開発させる方法」ではなく、「AIが安全な範囲で高速に開発できる仕組みを作ること」

だと捉えています。

そのため、

• AIがアクセスできる情報を制限する
• 機密情報の混入を自動検知する
• 情報を置く場所を分離する
• 許可されていない場所への送信を防ぐ
• CIで継続的に検査する
• システム自体のセキュリティをテストする
• 通常テストでは見つからない問題も監視する
• 自動化で判断できない部分は人が確認する

といった複数の対策を組み合わせています。

どれか一つの仕組みだけで完全に守れるとは考えていません。

一つの対策を抜けても、次の仕組みで止める。

そうした多層防御を前提に開発環境を設計しています。

安心してAI駆動開発を任せていただくために

AIを活用することで、これまでより短期間で試作や開発を進められる場面は確実に増えています。

一方で、企業システムの開発ではスピードだけでは不十分です。

お客様のデータや業務情報を扱う以上、

「どのAIを使っているか」以上に、「どのようなルールと仕組みの中でAIを使っているか」

が重要だと私たちは考えています。

テイルウインドでは、AI駆動開発のスピードを活かしながらも、情報管理・セキュリティ・品質管理を開発プロセスそのものに組み込むことで、安全性と開発速度の両立を目指しています。