AIが構築したコードは本当に安全か？ ビルダーのためのFAQ

オンボーディングの通話ではほぼ毎回、この質問の何らかのバリエーションを受けます。たいてい慎重な言い方で、聞く側は半ば「そんなに心配しなくていい」と言われることを期待しているような口ぶりです。しかし、その心配を打ち消すべきではありません。セキュリティは、コードを書いたのが人間であれモデルであれ、適度な警戒心が正しく機能する数少ない領域の一つです。以下は、私が実際に受ける質問に、できる限り率直に答えたものです。

AIが書いたコードは、人間が書いたコードより安全性が低いのか？

平均的に見て、そして何もチェックしなければ——そうです、多少は。数年前のスタンフォード大学の研究（Perryらによるもので、この問題を扱った最初の本格的な調査としてよく引用されます）では、AIコーディングアシスタントを使った開発者は、対照群よりも安全性の低いコードを書き、しかも——ここがより心配すべき点ですが——自分のコードを実際よりも安全だと評価していました。品質は下がったのに、自信は上がったのです。Veracodeの最近のGenAIコードセキュリティスキャンも、これをおおよその数値で示しています。テストしたAI生成コードサンプルのうち、およそ10件中4件が、入力チェックの欠落や弱いデフォルト設定といったありふれた欠陥を少なくとも1つ含んでいたとのことです。だからといって、AIが書いたコードが本質的に破綻しているわけではありません。レビューされていないAI生成コードは、レビューされていない人間のコードと同じリスクを抱えているということであり、実際の危険は「レビューされていない」という部分にこそ潜んでいます。速く書き、決してチェックされないモデルは、金曜午後に若手エンジニアが犯すのと同じミスを——ただしより速く、より多く——出荷してしまうのです。

自分のAPIキーやシークレットはどうなるのか？

これは実際に私が夜も眠れなくなる問題です。なぜなら、露見するまで見えないタイプのミスだからです。その失敗は劇的なものではありません——映画のハッカーのようにサーバーが侵害されるわけではないのです。それは、チャットに貼り付けられたキーが生成ファイルにそのまま反映され、コミットされ、6か月後に誰かが好奇心からシークレットスキャナーをかけたときに、リポジトリの中で平文のまま静かに座っているのが発見される、というものです。このプラットフォームでは、シークレットが生成されたソースコードに含まれることは一切ありません——実行時に暗号化されたストアからテナントごとにスコープされて注入され、ビルドエージェントには名前で参照するよう指示されており、値そのものを扱うことはありません。しかし、他の場所で構築している場合や、どんなツールであれチャットウィンドウに認証情報を直接貼り付けている場合は、プロバイダーが明示的に否定していない限り、そのテキストはどこかのトレーニング関連ログの一部になったと想定してください。チャット欄に一度でも入力したものは、テストが終わったその日のうちに、念のためすべてローテーションしてください。

プロンプト経由で自分のサイトがハッキングされる、たとえばプロンプトインジェクション攻撃を受けることはあるのか？

ここでは2つの異なる話が混同されがちですが、その区別は重要です。ビルダーに対するプロンプトインジェクション——アプリを構築しているAIを騙して、依頼していないことをさせる——は実在する、研究されているリスクです。だからこそビルドエージェントは無制限のシェルアクセスではなくスコープされたツール権限で動作し、ファイルシステムやデプロイパイプラインに触れる操作はすべて、後から監査できる明示的なアクションログを通ります。一方、出荷済みアプリに対するプロンプトインジェクションは別の問題で、アプリ自体が実行時にLLMを組み込んでいる場合——サポートチャットボットやAI検索機能など——にのみ関係します。もしそうであれば、ユーザーが入力できるあらゆるテキストを、そのモデルにとっての信頼できない入力として扱ってください。SQLクエリに対する信頼できない入力として扱うのと同じことです。ルール自体は昔からあるもので、新しいのはどのシステムがその文字列を解釈するかという部分だけです。

ビルダーは出荷前に自分自身のコードの脆弱性をチェックしているのか？

自動チェックは、単調で発生頻度の高い問題——ハードコードされたシークレット、明らかに必要な認証がエンドポイントに欠けている、パラメータではなく文字列連結で組み立てられたSQL、既知のCVEを持つ依存関係——を確実に検出します。しかし、うまく検出できないのがビジネスロジックの欠陥です。個々のコード行はすべて問題がないのに、誰も一緒にチェックしようと思わなかった2つの機能の「隙間」に脆弱性が潜んでいるようなケースです。無限に重ねがけできる割引コードと紹介ボーナスの組み合わせ。あるメールアドレスがシステムに存在するかどうかを漏らしてしまうパスワードリセットフロー。これらを見つけるには、コードが何をするかだけでなく、アプリが何のためにあるかを理解している人間が必要であり、AIであれ何であれ、スキャナーがそれを確実に見つけられるようにはまだなっていません。自動レビューは床であって、天井ではないのです。

インストールされるサードパーティのパッケージについてはどうか——サプライチェーンリスクにならないのか？

はい、そして正直なところ、これはAIが書いたコード自体よりも現実的に大きなリスクです。ほとんどのアプリは行数ベースで80〜95%が依存関係であり、ビルダーが書くコードはnpmやPyPI、あるいはそのスタックが使うエコシステムの上に載る薄い層に過ぎません。悪意のある、あるいは乗っ取られたパッケージは、その周りのつなぎコードを誰が、あるいは何が書いたかに関係なく、あなたを危険にさらす可能性があります——実際にどう展開するかについてはevent-streamやcolors.jsの事件を参照してください。対策は地味ですが効果的です。最新版を追いかけるのではなくバージョンを固定すること、先週公開されたばかりのものより実際のメンテナンス実績があるパッケージを優先すること、そして依存関係の監査（`npm audit`、`pip-audit`、あるいはあなたのスタックに合ったもの）を、ローンチ前の一度きりの作業ではなく継続的な習慣として実施することです。

侵害が発生した場合、誰が責任を負うのか？

法的には、ほぼ常にあなたです——それがあなたのアプリで、あなたの顧客のデータであれば。「AIが書いたから」と責任がどこかに移ると考える人は多いですが、驚かれることが多い点です。それは移りません。建築業者を雇っても建築基準法違反の責任が所有者から移らないのと同じです。プラットフォームは自らが管理するインフラ——シークレットの保存方法、テナントデータの隔離方法、ホスティング層自体がパッチ済みかどうか——について責任を負います。しかし、あなたが指定したアプリケーションロジック、あなたが収集を選んだデータ、あなたがユーザーに提示した利用規約は、あなたのものです。決済情報や医療情報、GDPRやCCPAの対象となるものなど、何か機密性の高いものを扱っている場合は、「AIが構築したから」という理由で何か追加の法的保護があると想定せず、実際に利用しているプラットフォームのデータ処理契約書を読んでください。そのようなものはありません。

ある創業者が半分冗談で「少なくとも自分は夜中2時に疲れないから」という理由で、自分自身のコードよりもAIのコードを信頼していると言ったことがあります。そうかもしれません。しかし、疲れた人間はたいてい自分が疲れていることを自覚しています。AIは自分がミスを犯したことに気づきません。コードが完璧であろうと穴だらけであろうと、まったく同じ自信に満ちた口調で「完成した」と告げてくるのです。自信は、どちらの発信元であっても、セキュリティのシグナルにはなりません。

ローンチ前に本格的なセキュリティ監査にお金を払うべきか？

決済を扱っている場合、規制当局がPIIと呼ぶようなものを保存している場合、あるいはどのみちSOC 2レポートを求めてくるビジネス顧客向けに構築している場合——答えはイエスです。コストを理由に諦めないでください。小規模アプリを対象とした集中的な監査は、規模にもよりますが数百ドルから数千ドル程度で、侵害通知の対応コストに比べれば安いものです。趣味のプロジェクトや社内ツール、実際のユーザーデータがリスクにさらされないものを構築している場合は、有料監査は過剰です。代わりに無料・低コストの層を実施してください——依存関係のスキャン、すべての認証境界の手動チェック（URLを変えるだけでユーザーAがユーザーBのデータを見られないか）、そしてお金やパスワードに触れる部分については別の人間の目でもう一度確認すること。

人々が犯す最も一般的なセキュリティのミスは何で、それはいつ起こるのか？

ローンチ時ではなく、その3か月後——アプリが動いていて、もう誰も見ていない頃です。それは、構築した本人が自分自身としてログインしてしかテストしなかったせいで、無防備なまま放置された管理者用ルートだったりします。本番環境で完全なスタックトレースを返してしまうデバッグ用エンドポイントだったり。「テスト用だから」という理由でデフォルトパスワードのまま、一度もローテーションされなかったデータベースだったりします。どれも珍しいものではありません。急いでいた一度だけドアマットの下に予備の鍵を置き、それがそこにあることを忘れてしまう——セキュリティにおけるそれと同じことです。解決策はより良いツールではなく、5分の習慣です。月に一度、誇らしげなビルダーの目でアプリを見る前に、5分間だけ攻撃者の目で見てみてください。