「うちには盗まれて困るものなんてありません。ただの小さなサイトですから」。この言葉はたいてい本心から出たものですが、代償は数か月後に現れます。ある日、外部サービスの請求額がいつもの何倍にもなっていたり、全顧客のデータが誰かに閲覧された痕跡があり、それがいつ起きたのかもわからなかったりします。攻撃者はあなたのサイトが盗む価値があるかどうかを先に判断したりしません。プログラムで自動的にスキャンし、鍵が開いていればそのまま入ってきます。狙われているのではなく、もともと鍵が開いていただけなのです。以下の 3 つは、私たちが AI で作られた製品を引き継ぐときに最初に確認することです。
AI は速く書けるが、侵入される心配まではしてくれない
AI ツールの目的は「求められた機能を作ること」であり、「入ってはいけない人を防ぐこと」ではありません。
- 会員システムが欲しいと言えば、会員システムを作ってくれます。しかし「他人のデータを見られないようにしてほしい」と言わなければ、それを自分で追加することはありません。
- 人間のエンジニアが機能を書くとき、頭の中には「悪意のある人ならどう使うか」というリストがあります。それが経験です。
- AI はそのリストを、こちらが明示的に求めたときにしか動かしません。しかもそのリストの存在自体を、あなたは知らないのです。
だからこそ、AI で作られた製品は機能面がほぼ完璧である一方、防御面はほぼ空っぽになりがちです。これはVibe Coding と本当のシステムアーキテクチャの差という記事と同じ話です。作れることと、攻撃に耐えられることは、まったく別の能力です。
まず崩すべき 5 つの「思い込み」
本当に危険なのは技術的な詳細ではなく、一見もっともらしく聞こえるこの 5 つの思い込みです。
| 思い込み | 実際は | 何が起きるか |
| 画面に表示されなければ、権限もない | バックエンドで本人確認が再度行われていない | URL を少し書き換えるだけで他人の注文が見える |
| コードに鍵を書いても誰にも見えない | コードがリポジトリに入った時点で公開されたのと同じ | 請求額が急増する、あるいはサービスが停止される |
| フォームには普通の文字しか入力されない | 特別に細工された文字列を貼り付ける人がいる | データベースを丸ごと読み取られる、または削除される |
| うちのような小さなサイトは誰も狙わない | 攻撃はプログラムがネット全体を自動でスキャンしている | 鍵が開いていれば入られる。誰であるかは関係ない |
| 公開時に確認したから、ずっと安全 | 基盤となるパッケージの脆弱性は次々と見つかる | 古い脆弱性が放置されたままで、誰も気づかない |
3 つの地雷:権限、鍵、入力検証
- 権限。画面上はログイン者に応じて表示するボタンを変えていても、実際にデータを処理する部分で「この人にこの操作を行う資格があるか」を再確認していません。これはオフィスの正面玄関には入館証チェックがあるのに、各部屋のドアには鍵がかかっていないようなものです。正面玄関を通った人は、どこへでも自由に入れてしまいます。
- 鍵。鍵はプログラムと外部サービスをつなぐ通行証です。それを手に入れた人は誰でも、あなたの名義でお金を使うことができます。最も手早い作り方は鍵をコードに直接書くことですが、そのコードがアップロードされた瞬間、その文字列は誰でも見られる状態になります。
- 入力検証。プログラムが「これは妥当な入力か」を先に確認せずにデータベースに渡したり画面に表示したりすると、その文字列はデータではなく命令として実行されてしまいます。お客様が備考欄に「レジを開けろ」と書いたら、厨房が本当にそのとおりにしてしまうようなものです。
共通する根本原因は、プログラムが「これはデータ」と「これは命令」を区別していないこと、そして「画面に表示されない」と「実際に取得できない」を区別していないことです。
5 分でできる 3 問セルフチェック
技術知識は不要です。テスト環境を用意するか、作った人に立ち会ってもらってください。
- 権限:一般顧客のアカウントでログインし、URL 内の番号を別の数字に書き換える、または管理画面の URL を直接入力してみます。見えてはいけないものが見えたら、失格です。
- 鍵:コードを開いて key、secret、password、token を検索します。乱数のような長い文字列が見つかったら失格です。ついでにリポジトリが公開設定になっていないかも確認してください。
- 入力検証:どれかのフォーム欄にシングルクォートと山括弧を含む文字を貼り付けて送信します。画面のレイアウトが崩れたり、英語のエラー文が表示されたりしたら失格です。
3 問すべて合格しても安全とは限りませんが、最低限の鍵は閉まっているということです。2 問以上失格なら、まだ実際の顧客には公開しないでください。これはデモができることと公開できることは違うという記事のチェックリストのうち、セキュリティ部分を詳しく展開したものです。
補う順番
3 つの地雷は同時に処理せず、この順番で対応してください。
- まず鍵を交換する。リポジトリに入ったことのある鍵はすべて漏洩済みとみなします。新しいものを発行し、古いものを無効化し、新しい鍵はコードの外に移します。最も速く終わり、かつ「すでにお金が漏れている可能性がある」唯一の項目です。
- 次に権限を補う。「資格があるかどうか」のチェックを、画面上だけでなくデータを処理するすべての箇所に追加します。機能ごとに確認する必要がありますが、効果は最も大きいです。
- 最後に入力検証を補う。すべてのフォーム、外部データを受け取るすべての入り口にチェックとフィルタリングを追加します。多くの開発フレームワークには既存の仕組みがあるので、すべての入り口で実際に使われているか確認することが重要です。
補い終えた後も、セキュリティ更新は継続する必要があります。基盤となるパッケージの脆弱性は次々と見つかり続けるからです。
Nerdtechnic(恩梯科技)がこの 3 つの扉をどう見ているか
- 引き継ぎの最初の段階で鍵の交換と権限の補強を行い、何か起きてから対応することはありません。
- セキュリティ更新は四半期に 1 回以上、緊急時は別途対応し、手が空いたときだけ行うものではありません。
- 不具合を報告いただいたら 2 営業日以内に評価結果を返答し、サーバーやサービスに問題が起きたら 1 営業日以内に対応します。
セキュリティは一度で終わるプロジェクトではなく、毎月誰かが継続して見ているべきことです。
AI で作られた製品で閉めるべき扉を閉めることは、私たちが Helper CTO として引き継いだ最初の段階で必ず対応することです。会社の技術責任者のような存在でありながら御社の社員ではなく、引き継ぎ・保守・改善はすべて同じチームが担当します。最初の一歩は 60 分のシステム健診です。コードを見せていただくだけでよく、本番環境のアカウント情報は不要です。3~5 営業日以内に、3 つの地雷それぞれの状態を明記した 1 ページのレポートをお渡しします。3 問セルフチェックをやってみて、あまり良くない結果だった方は、まずはこちらからどうぞ:Helper CTO:システム保守プラン。