相次ぐ情報漏洩｜サイバー攻撃の穴は、直しても戻る。AIは攻撃の道具か、守りの味方か

「AIでアプリは作れても、セキュリティは守れないでしょう」

私のようにAIでシステムを作っていると言うと、とくにエンジニアの方から、こう言われることがあります。

最近は、「AIの普及で、システムの弱点の発見が急増した」というニュースも出ています。AIが、まるで悪者のように扱われることも増えました。

たしかに、半分はその通りだと思います。AIに「作って」と頼むだけでは、「動くもの」はできても、「攻撃に耐えるもの」になるとは限りません。そして、攻撃する側がAIを使うことも、現実に起きています。

でも、残りの半分は違います。AIは、攻撃する側の道具であると同時に、守る側の強い味方にもなります。 作るだけでなく、「自分が作ったものの穴を探して、ふさぐ」ところまで、やってくれます。

しかも先日、AIに再点検をさせたところ、私が「ふさいだはずの穴」が、いつの間にか復活しているのが見つかりました。しかも、その背景には、AIが、頼んでいない所まで変えてしまうという、バイブコーディングの落とし穴がありました。この記事では、その顛末まで含めて、全部書きます。

サイバー攻撃(インターネットなどを通じた攻撃の全般)、なかでもサーバー(情報やサービスを預かるコンピューター)を狙うサーバー攻撃が怖い、という経営者の方、情報システム部門の方に向けて、最近の漏洩事案のこと、そして私がやらせた脆弱性(ぜいじゃくせい。システムの弱点、守りの穴のことです)チェックの内容を、失敗も含めてお伝えします。

最近、サーバー攻撃への警戒がとても強くなっています

脆弱性は、1日に130件以上、世界のどこかで見つかっています

アメリカのMITRE社が管理している、CVE(共通脆弱性識別子。世界共通の「弱点の管理番号」のようなものです)という仕組みがあります。

報道によると、このCVEの2025年の登録数は、約4万8千件でした。前の年(2024年)は約4万件です。単純に割ると、1日あたり130件以上、新しい弱点が見つかっている計算になります。2021年と比べると、約2.4倍です。

増えた理由には、AIが関わっているようです

報道では、この急増の背景に、AIの普及があると伝えられています。

脆弱性の情報を共有している国際組織FIRSTが、2026年6月に公表した予測の見直しでも、AIの活用が広がったことが、発見数の増加に関わっているとされています。2026年の予測は、約6万6千件に引き上げられました。

ここで大切なのは、FIRSTが「件数が増えたことは、ソフトウェアの品質が下がったことを、必ずしも意味しない」と述べている点です。これまで見つかっていなかった弱点が、AIの力で掘り起こされている、という側面があるのです。つまり、AIは「弱点を増やしている」のではなく、「隠れていた弱点を、見つけやすくしている」ともいえます。

政府も、企業に対策を呼びかけています

2026年10月9日には、内閣官房の国家サイバー統括室が、企業に対して対策の徹底を求めたと報じられています。報道によれば、更新プログラムの適用、多要素認証(パスワードに加えて、もう1つ別の確認を行う仕組み)、ログの監視、取引先を含めた管理などが挙げられており、「経営課題として取り組むように」という趣旨でした。

なぜ、サーバー攻撃への対処は、こんなに難しいのか

ITに詳しくない方からすると、「ちゃんとしたセキュリティソフトを入れておけば大丈夫なのでは？」と思われるかもしれません。ここでは、たとえ話で説明します。

理由① 守る側は「全部」、攻める側は「1か所」でいい

家を想像してください。ドアが2つ、窓が10枚あるとします。

泥棒は、鍵のかかっていない窓を、1枚見つければ入れます。一方、住人は、12か所すべてに鍵をかけ続けなければなりません。

システムも同じです。守る側は、すべての入口を守る必要があります。攻撃者は、たった1つの穴が見つかれば、それで十分です。この不公平さが、対処の難しさの根っこにあります。

理由② 新しい「合鍵の作り方」が、毎日見つかる

先ほどの、1日130件以上という数字を思い出してください。

昨日まで安全だった鍵が、今日、「実は、こうすれば開く」と発見されることがあります。昨日きちんと守っていた人でも、今日は穴が開いているかもしれないのです。守りは、一度作って終わりではありません。

理由③ 受付が「社員です」の一言で通してしまう

オフィスビルの受付で、社員証を見せなくても、「社員です」と口で言っただけで通してくれる受付があったら、どうでしょうか。

システムの世界では、こういうことが、実際に起こります。「この通信は、社内の画面から来たものだ」という自己申告を信用してしまう作りです。自己申告は、攻撃者が簡単にウソをつけます。この穴は、私のシステムでも見つかりました。 詳しくは、後ほどお話しします。

理由④ 増築するたびに、新しい窓ができる

システムは、作って終わりではありません。機能を追加するたびに、建物を増築するように、新しい入口が増えます。

増築のたびに、「ここに窓を付けたけど、鍵は付けたかな？」を確認しなければなりません。 忙しい現場では、この確認が、つい後回しになります。

理由⑤ 古い設計図で改装すると、直した鍵が元に戻る

もうひとつ、現場でよく起きるのが、これです。

窓の鍵を直したあと、別の担当者が、直す前の古い設計図を使って、改装工事をしてしまう。すると、せっかく直した鍵が、元の壊れた状態に戻ってしまいます。誰も悪気はないので、気づかれません。

これが、まさに私のシステムで起きたことです。後ほど詳しく書きます。

理由⑥ 攻撃は「見えない」し、見つけても「量」が多い

泥棒は、昼間に堂々と入ってはきません。攻撃は、多くの場合、静かに行われます。

しかも、システムが毎日吐き出す記録(ログ)は、膨大な量です。その中から「怪しい動き」を探すのは、毎日何万枚もの防犯カメラの映像から、不審者を見つけるようなものです。そもそも、防犯カメラを付けていなければ、何が起きたのかさえ、後から分かりません。

理由⑦ 取引先の裏口から入られる

自社の玄関に、どれだけ頑丈な鍵をつけても、取引先や外部サービスの裏口が開いていれば、そこから入られます。自社だけ頑張っても、守り切れない。これが、サーバー攻撃のやっかいなところです。

最近の漏洩事案では、どんな手口が使われたのか

「実際には、どんな攻撃で漏れたのか」。経営者の方も、情報システム部門の方も、いちばん気になるところだと思います。そこで、最近の事案について、調べられる範囲で調べました。会社名は伏せます。

事案① カーシェアリングサービス：約660万アカウント

2026年9月下旬に不正アクセスが確認された、カーシェアリングサービスの事案です。報道によると、約660万アカウント分の情報が漏れ、そのうち約160万アカウント分には、運転免許証などの本人確認書類の画像が含まれていました。

そして、この会社は、退会した後も7年間、本人確認書類の画像を保管していたと報じられています。被害が大きくなった一因として、長期保管が指摘されました。会社は、今後は画像を保有しない方針に改め、保有している画像を10月末までにすべて削除するとしています。

肝心の攻撃の手口は、私が確認できた範囲では、公式発表にも報道にも、公表されていませんでした。外部の専門機関による調査(フォレンジックといいます)が、続いている段階です。

事案② 外食チェーンの会員アプリ：約1,079万件

2026年10月に公表された、外食チェーンの公式アプリの会員管理システムの事案です。アプリの登録者約1,081万件のうち、約1,079万件が漏れたとされています。漏れたのは、会員番号、氏名、メールアドレス、電話番号の4項目で、ログイン用のパスワードや生年月日、クレジットカード情報などは対象外だと説明されています。

こちらも、公式発表は「第三者による不正アクセス」とするにとどまり、手口や侵入経路は、私が確認した時点では公表されていませんでした。登録者のほぼ全員が対象になっている点について、解説記事の中には、「会員の情報を一括で取り出せる作りになっていなかったか」といった点検の観点を挙げるものがありますが、これは一般論であり、この事案で実際に何が起きたのかは、確認できていません。

この2つで、手口が分からないのは、むしろ普通です

手口の詳細は、調査が終わってから、あるいは、公表の方針が決まってから出てくることが多く、事件の直後には分からないことがほとんどです。ですので、ここでは推測で「こうだったに違いない」とは書きません。

手口が公表されている事案も、あります

同じ時期に報じられた事案には、手口がある程度分かっているものもあります。

• ランサムウェア(データを勝手に暗号化して使えなくし、元に戻すことと引き換えに身代金を要求する攻撃)を受けた、ある企業グループの事案

• 従業員のアカウントが乗っ取られ、約9千通のなりすましメールが送られた、ある報道機関の事案

• 業務を委託していた会社のサーバーに侵入され、委託元の顧客情報が漏れた可能性がある、ある金融機関の事案

特に最後の例は、先ほどの「取引先の裏口から入られる」という話そのものです。

手口が分からなくても、守りの基本は変わりません

一般に、こうした事案で問題になりやすいのは、次のようなことです。

• ログインの突破(盗まれたIDとパスワードの使い回し、アカウントの乗っ取り)

• アプリの設計の穴(認証の確認が抜けている、一度に大量のデータを取り出せてしまう)

• 取引先・委託先経由での侵入

• 不要なデータの長期保管(被害を大きくします)

どれも、手口が公表される前から分かっている、「守りの基本」です。後ほど、私が自作のシステムで、これらの点にどう向き合ったかを書きます。

AIは、悪者ではありません。守る側にも、使えます

「AIで弱点が増えた」の、もうひとつの見方

先ほどのニュースの見出しは、AIが悪者のように読めます。でも、同じ事実には、反対の見方もあります。

AIが弱点を見つけやすいなら、守る側が先にAIで見つければ、攻撃される前にふさげます。

実際に、Firefoxというブラウザを作っているMozillaは、開発中にAIエージェント(自分で考えて作業を進めるAI)を使い、バグを271件見つけて修正した、とFIRSTの報告で紹介されています。

また、Googleも、2026年4月に公式ブログで、「汎用的なAIでも、脆弱性の発見に極めて高い能力を発揮することは実証されている」と述べ、守る側にも、AIの活用が必要だと提言しています。攻撃する側は、すでにAIを使い始めているからです。

私がやってきたことは、まさにこれです

私は、AIにシステムを作らせるだけでなく、AIに、そのシステムの穴を探させて、直させてきました。次の章から、その中身を書きます。

「AIで作ったシステムは危ない」という声は、半分当たっています

AIは「頼まれたこと」を作るのが得意

私は、AIには「頼まれたものを、頼まれた通りに作る」得意さがある、と感じています。「ログイン機能を作って」と言えば、ログインはできるものを作ってくれます。ただ、「そのログインは、攻撃されても破られないか」までは、頼まない限り、考えてくれないことがあります。

私自身も、失敗したことがあります

以前、別のアプリを作ったとき、AIの外部サービスを使うための「鍵」(APIキー)を、画面側のファイルに、そのまま書き込んでしまったことがあります。限定公開だから大丈夫だろう、と、動くことを優先してしまったのです。

でも、画面側のファイルは、見る気になれば、ブラウザの開発者ツールで誰でも中身を見られます。限定公開でも、URLを知っている人には、鍵が丸見えになります。

この失敗のあと、「鍵は、画面側には絶対に書かない。サーバー側の安全な場所に置く」というルールを作りました。

だからこそ、「AIにチェックさせる」ことが大事

AIが穴を作ることがあるなら、AIに、その穴を探させて、直させればいいのです。作る人と、点検する人を分ける。人間の世界で当たり前にやっていることを、AIとの開発でもやる、ということです。

「クラウドなら安全」は、幻想です

「オンプレは危ない、クラウドは安全」という思い込み

「自社でサーバーを持つ(オンプレミス)より、AWSのようなクラウドのほうが、脆弱性が見つかりにくく、安全だ」。そう考えている方は、多いのではないでしょうか。クラウドは「できあがっているもの」で、ちゃんとした会社が守ってくれているはずだ、という解釈です。

これは、半分は正しく、半分は幻想です。

クラウド事業者が守るのは「土台」まで

たとえ話で説明します。クラウドは、マンションを借りるようなものです。

建物の構造、共用部分の警備、玄関のオートロックの仕組みは、マンションの管理会社が守ってくれます。でも、自分の部屋の鍵をかけるかどうか、誰に合鍵を渡すか、部屋に何を置くかは、借りた人の責任です。

これは「責任共有モデル」と呼ばれる考え方で、AWSも公式に説明しています。AWSが責任を持つのは、クラウドを動かす土台(施設、ハードウェア、ネットワーク、仮想化の部分など)です。一方、利用者側は、自分の設定やデータ(暗号化の選択を含む)を管理する責任があり、使うサービスによっては、OSの更新やファイアウォールの設定も、利用者の仕事になります。責任の範囲は、使うサービスによって変わります。

「見つかりにくい」のではなく、「見えていない」だけかもしれません

オンプレミスでは、自分で何もかも管理しているので、弱点が見つかりやすい。クラウドでは見つかりにくい。そう感じる方もいるかもしれません。

でも私は、クラウドで弱点が見つからないのは、弱点がないからではなく、点検していないから、見えていないだけのことも多いと考えています。設定の穴は、誰かが探さない限り、見つからないまま残ります。

私のシステムの実例

私のコールセンターシステムは、サーバーを自分で持たない構成(サーバーレス)で、OSの更新など土台の管理はAWSに任せています。それでも、今回見つかった穴は、AWSの側にあったのではありません。私が作った(AIが書いた)プログラムの中の、認証の省略が原因でした。

AWSは、正しく動いていました。穴は、その上に載せた、自分のプログラムの中にあったのです。

クラウドは「できあがったもの」ではなく、「素材」です

クラウドを使えば、土台の守りは、プロに任せられます。これは、大きなメリットです。

しかし、その上に載せる設定、プログラム、データを守るのは、自分の仕事です。オンプレミスでも、クラウドでも、自分で作った部分の点検は必要です。

今回、点検の対象にしたもの

自作の、AI電話対応コールセンターシステムです

私は、AIが電話に出て、お客様の本人確認や案内を行う、コールセンターシステムを個人で作っています。AWS(アマゾンのクラウドサービス)の上で動かし、サーバーを自分で持たない構成(サーバーレス)にしています。

システムは、大きく3つの部分でできています。

• 電話に自動で応答するAI

• 電話オペレーターが使う画面

• 管理者・スーパーバイザーが使う管理画面(ダッシュボード)

扱うのは、個人情報です

このシステムは、お客様の名前、電話番号、住所、そして支払いの状況といった、漏れたら困る情報を扱います。通話の録音データもあります。なお、現在は一般には公開しておらず、テスト運用の段階です。

だからこそ、「動けばOK」では済ませられません。以下が、AIと一緒に行ったチェックと対策です。

実際にやった、脆弱性チェックと対策

対策① 管理画面の入口を、まず「HTTPS+Basic認証」で固めた

最初に取り組んだのは、管理画面の入口です。

CloudFront(世界中に素早くデータを届けるサービス)を前に置いて、通信を暗号化するHTTPSにしました。そのうえで、Basic認証(ブラウザに標準で備わっている認証の仕組み)を組み合わせた、**「HTTPS+Basic認証」**の構成にしています。通信を暗号化したうえで、管理画面を開く前に確認が入る、という形です。

つまり、管理画面にたどり着く前に、まず1つ目の関門を作ったのです。

対策② 「社員です」の一言で通れる穴をふさいだ(Origin偽装対策)

これが、今回の記事の中心になる点検です。

当時の仕組みでは、管理画面からの通信かどうかを、通信に付いている「送信元(Origin)」という情報を見て判断し、管理画面からだと判断した場合は、ログインの確認を省略していました。

先ほどの受付の例えでいう、社員証を見せなくても、「社員です」と言えば通れる状態です。この送信元の情報は、専用のソフトを使えば、誰でも偽装できます。偽装されると、ログインしていない人が、管理者の機能を呼べてしまいます。

6月、点検の結果これが見つかり、修正しました。「送信元がどこであっても、必ず本人確認の証明書(セッショントークン)を持っていること」を、すべての通信の条件にしたのです。送信元の自己申告は、一切信用しない、という方針です。

……そのはずでした。この話には、続きがあります。後ほど、「ふさいだはずの穴が復活していた」の章で書きます。

対策③ 管理画面の中にも、ログインを付けた(二段階の関門)

「HTTPS+Basic認証」だけでは、入口の確認を1回通れば、画面の中は誰でも操作できてしまいます。

そこで、管理画面の中にも、もう1枚、ログイン画面を作りました。入口の「HTTPS+Basic認証」と、画面の中のログインで、関門が二重になっています。

対策④ 権限を3段階に分けた

全員が、何でもできる状態は危険です。そこで、利用者の権限を3つに分けました。

• 一般の電話オペレーター

• スーパーバイザー機能が使える人

• 管理者だけが使える機能

管理画面のログインは、スーパーバイザーか管理者の権限がある人だけが通れるようにしています。「必要な人に、必要な分だけ」の権限、というのが基本の考え方です。

対策⑤ 画面を隠すだけでなく、サーバー側でも確認する

ここは、IT素人の方に、とくに知ってほしい点です。

画面上で「管理者用のボタンを隠す」だけでは、守ったことになりません。なぜなら、画面は利用者の手元で動いており、隠したボタンを、裏から直接呼び出すことができるからです。

そのため、管理画面を開き直したときなどは、サーバー側で「この証明書は本物か」「管理者の権限があるか」を、毎回、確認する作りにしています。

対策⑥ ブラウザの「他サイトへの通信を許すかどうか」のルール(CORS)を整えた

ブラウザには、安全のための決まりがあります。同一オリジンポリシーといって、あるサイトの画面から、別のサイトのサーバーへ勝手に通信させない、というルールです。マンションで、隣の部屋の人が、勝手に入ってこられないのと同じです。

ところが、私のシステムは、画面を配信する場所と、データを扱うサーバーが、別の場所にあります。そのため、画面からサーバーへ通信するには、サーバー側で「この通信は許可します」と、はっきり伝える必要があります。管理人が、訪問者に許可証を出すようなものです。この許可の仕組みを、CORS(コーズ。別のサイトからの通信を、どこまで許すかを決める仕組み)といいます。

そこで、サーバー側に、次の設定を入れています。

• 通信の前の「確認」(プリフライトといいます)に、きちんと返事をする

• 許可する通信の種類(取得、登録、更新、削除)を、明示する

• 画面から送ってよい情報(本人確認の証明書など)を、必要なものだけ明示する

録音の再生のときには、ブラウザが録音を直接取りにいくとCORSで弾かれる問題が起きました。そこで、サーバーを経由して録音を渡す方式に変えて、解消しています。

なお、CORSは「許可証」を出す仕組みです。許可証があっても、部屋に入るには、本人確認の証明書(鍵)が必要です。CORSだけで守りきるのではなく、ほかの対策と組み合わせて守る、というのが基本です。

対策⑦ パスワードは、そのまま保存しない

電話オペレーターのパスワードは、そのままの形では保存していません。

PBKDF2(ピービーケーディーエフツー。パスワードを何十万回もかき混ぜて、元に戻せない形に変える方式)で、かき混ぜた結果だけを保存しています。かき混ぜる回数は、31万回です。さらに、パスワードごとに違う「ランダムな塩」を混ぜるので、同じパスワードでも、保存される結果はバラバラになります。

また、電話オペレーターの一覧を画面に返すときは、パスワードの情報は含めないようにしています。

対策⑧ 秘密の鍵は、画面側に置かない

先ほどお話しした失敗を踏まえて、AIの外部サービスを使うための鍵や、通知の連携先などは、画面側ではなく、サーバー側の「環境変数」(プログラムに外から渡す設定値で、画面からは見えません)に置いています。

画面側のファイルには、鍵を一切書きません。これは、プロジェクト共通の絶対ルールにしました。

対策⑨ 通話の録音は、暗号化して、直接は触らせない

通話の録音データは、暗号化して保管しています。しかも、録音ファイルを保管している場所に、外から直接アクセスすることはできません。

録音を聞くときは、いったんサーバー側のプログラムを経由して、権限を確認した上で再生する形にしています。

Slackなどで録音を共有するためのリンクは、偽造できない署名付きで、有効期限は24時間です。期限が切れたリンクは、使えなくなります。チャットに添付ファイルをアップロードするときの一時的なURLは、さらに短く、5分で切れます。

対策⑩ 電話の相手を、3つの情報で照合する

これは、攻撃対策というより、「情報の出しすぎ」を防ぐ仕組みです。

AIが電話で支払い状況などをお伝えする前に、お名前、電話番号、住所の3つを照合します。照合に2回失敗した場合は、AIが勝手に話を進めず、人間の電話オペレーターに転送します。

AIが「うっかり、他人に個人情報を話してしまう」リスクを、設計の段階で減らしておく、という考え方です。

対策⑪ データを、溜め込まない

AIとの会話の履歴は、24時間で自動的に消える設定にしています。

持っていないデータは、漏れません。 先ほどの事案①のように、退会後も長く保管していたデータが、被害を大きくすることがあります。漏洩の被害を小さくするには、そもそも不要なデータを持ち続けない、というのが効果的です。

対策⑫ 「触ってはいけない場所」を決めて、変更前に必ずバックアップ

最後は、仕組みではなく、運用のルールです。

ログインに関わる部分は、一切変更しない、と決めました。ログイン周りを何気なく触って、守りが壊れる事故を防ぐためです。変更が必要なときは、必ず理由と範囲を明確にして、提案してもらい、私が承認してから実行します。

また、作業の前には必ずバックアップを取ります。電話の流れを定義したファイルだけでも、バックアップが20本以上たまっています。

AWSの操作では、日常の作業は権限を絞った専用のユーザーで行い、最上位の管理者アカウント(ルートアカウント)は、本当に必要なときだけ使って、作業が終わったらすぐにログアウトする、というルールにしています。

本題：ふさいだはずの穴が、復活していた

再点検で、AIが見つけた

対策がひと通り済んだあとも、定期的にAIに再点検をさせています。今回、本番で動いているプログラムそのものを読ませて、「攻撃者の目線で、穴を探して」と頼みました。

すると、AIから、こういう報告が出てきました。

「6月に廃止したはずの、送信元(Origin)による認証の省略が、本番のプログラムに残っています」

ふさいだはずの、あの穴です。

本当に通れるのか、その場で試した

AIは、推測だけで終わらせません。本番に対して、実際にこういうテストをしました。

• 本人確認の証明書を付けずに、保護された機能を呼ぶ → 拒否される(正常)

• 証明書は付けず、送信元だけを「管理画面から来た」と偽装して呼ぶ → 通ってしまった

テストに使ったのは、状態を確認するだけの、影響の小さい機能です。それでも、ログインしていない人が、送信元を偽装するだけで、保護された機能の呼び出しを通せることが、確認できました。

なぜ、復活したのか

私は、「なぜ戻ったのか」を、記録から調べさせました。ここからは、ファイルの記録から推測できる範囲です。当時のAIとのやり取りは残っていないため、確実とまでは言えません。

分かったことは、次のとおりです。

• 6月22日のバックアップには、修正済みのプログラムが残っていました

• ところが、6月24日の時点で作業していたファイルは、更新日時が6月18日でした。6月22日の修正版よりも古いものです

• この古いファイルには、修正前の認証の省略が入っていました

• 6月24日には、管理画面のログインを作り直す作業をしていて、その成果が本番に反映されています

つまり、修正した内容が、作業用のファイルに引き継がれないまま、古いファイルを元に作業が進み、本番に反映された時に、修正が上書きで消えた、という流れだったと推測しています。

AIが、わざと穴を作り直したわけではありません。たとえ話でいう、直す前の古い設計図で改装工事をして、直した鍵が元に戻った状態です。

しかも、ファイルが「作業フォルダ」「バックアップ」「本番」の3か所に分かれていて、どれが正しいのか、分からなくなっていました。今回の再点検でも、手元のファイルが、本番より古かったのです。もし手元のファイルを元に直していたら、また別の修正を消してしまうところでした。

AIは、頼んでいないところまで、変えてしまうことがある

今回の件は、AIとの開発における、大事な教訓でもあります。

6月24日に私が頼んだのは、「管理画面にログインを付けること」でした。ところが、そのとき本番に反映されたプログラムには、頼んでいない「認証の省略の復活」が含まれていました。 誰も承認していない変更が、認証という、いちばん大事な部分に、入り込んでいたのです。

原因は、古いファイルを元にしたことだと推測しています。AIに悪意があるわけではありません。ただ、AIは、頼まれた作業を終わらせることに集中するあまり、その作業がほかの場所に何を及ぼすかを、人間ほど慎重に確かめないことがあります。作業に必要だと判断すれば、頼んでいない場所にも、手を入れます。

実は、別のツールを作ったときにも、似たことがありました。サービスの停止方法を質問しただけなのに、頼んでいない切り替えボタンを、次々と追加されました。また、管理画面のログイン方式を、こちらの許可なく、別の方式に書き換えられていたこともあります。(どちらも、元に戻してもらいました。)

さらに、このコールセンターでは、「ログイン周りは、承認なしに変更しない」というルールを、6月18日に作っていました。それでも、反映の過程で、認証にかかわる内容が、承認のないまま入れ替わってしまいました。ルールを文書に書いておくだけでは、防ぎきれなかったのです。

これは、AIを責める話ではありません。バイブコーディングで開発する人が、必ず知っておくべき性質です。AIに任せるほど、「何が変わったか」を人間が確かめる仕組みが、必要になります。

修正の手順

修正は、次の順番で進めました。もちろん、「提案、承認、実行」の順番は守ってあります。

1. まず、本番の今の状態をバックアップする(本番のプログラム、管理画面、API Gatewayの設定)

2. 本番のプログラムを取得して、それを元に直す(手元の古いファイルは使わない)

3. 管理画面側を直す。証明書を付けずに通信していた約45箇所を、すべて自動で証明書を付ける共通の仕組みでまとめて対応する

4. プログラム側で、送信元による認証の省略を、削除する

5. 管理画面を先に反映し、そのあとプログラムを反映する

プログラムだけを先に直すと、管理画面の一部が使えなくなります。順番にも意味があるのです。

直ったことを、確かめた

反映したあとは、同じテストをもう一度行いました。

• 送信元を偽装して呼ぶ → 拒否される

• 偽の証明書で呼ぶ → 拒否される

• ログイン画面用の機能、通信の事前確認(CORS)、録音共有リンクの不正な署名 → 想定どおりに動く

さらに、本番を修正前のバックアップと比べて、意図した箇所以外を触っていないことも確認しました。プログラムの変更は、認証を省略していた数行だけ。設定は変わらず、管理画面は追加のみで、削除された行はゼロでした。

「データが消えた」と焦った話

実は、反映の直後に、ひやっとしたことがありました。管理画面を開いたら、情報が全部消えて、空っぽの画面になったのです。

結論から言うと、データは1件も消えていませんでした。顧客も、通話の履歴も、そのまま残っていました。

原因は、ブラウザが、修正前の古い管理画面を使い続けていたことでした。古い画面は、新しいサーバーのルールを知らず、証明書を付けずに通信してしまい、拒否された結果、何も表示されなかったのです。強制再読み込みをすると、元通りに戻りました。

この件を受けて、管理画面のファイルに、「毎回、最新版か確認する」という設定を足しました。反映した直後に、画面が空っぽになっても、慌てずに、まず古い画面が残っていないかを疑う。 これも、いい勉強になりました。

防犯カメラを付けた:アクセスログの設定

これまでは、後から調べる手段がなかった

今回の再点検で、もうひとつ分かったことがあります。APIのアクセスログが、設定されていなかったのです。

つまり、穴が開いていた間に、実際に悪用された形跡があったかどうかを、後から調べる手段がありませんでした。防犯カメラが付いていないのと、同じです。

その場で設定した

そこで、アクセスログを取る設定を、その日のうちに入れました。

• 記録するのは、時刻、通信の種類、通信先の機能名、結果、送信元のIPアドレスなどです

• 電話番号や、本人確認の証明書は、記録しません(ログから個人情報が漏れないようにするためです)

• 保存期間は、90日にしました。無期限にすると、溜まり続けるからです

費用は、ほぼゼロでした

ログの保存にかかる費用は、気になるところです。そこで、自分のアカウントの実際の数字を調べました。

• 直近30日間のログの取り込み量は、全部で約45MBでした

• 無料枠は、月5GBです。1%以下に収まっています

アクセスログを足しても、今のテスト運用の規模なら、無料枠の範囲に収まる見込みです。コストを抑えた設計にするのは、個人開発では特に大切です。

「後から見る」方法も、用意した

ログは、取っただけでは役に立ちません。見る方法も用意しました。直近のアクセスを集計して、結果コード別の件数、認証エラーの多い送信元、存在しない機能への通信(スキャンの疑い)を、一覧で出す簡単なスクリプトです。AIに「ログを確認して」と頼むだけでも、調べてくれます。

バイブコーディングで脆弱性チェックをやらせる、コツ

ここまでの対策は、AIと一緒に、一つひとつ進めたものです。やり方のコツを、まとめます。

コツ① 「攻撃者の目線で、穴を探して」と頼む

「安全に作って」と頼むより、「この仕組みを攻撃する人の立場になって、破れそうな所を挙げて」と頼むほうが、具体的な指摘が出てきます。

コツ② 推測で終わらせず、「実際に試して」確認させる

「穴がありそうです」と言うだけでなく、実際に偽装した通信を送って、通るかどうかを試させます。今回も、これで確実に分かりました。

コツ③ 「提案、承認、実行」の順番を守らせる

AIは優秀ですが、頼んでいないことまで、先走って直そうとすることがあります。まず提案させて、人間が承認してから、実行させる。 この順番を守ることが、安全のためにも大切です。

コツ④ 直す前に、必ずバックアップを取る

どんなに小さな修正でも、本番を触る前には、元に戻せる状態にしておきます。今回も、バックアップがあったから、安心して直せました。

コツ⑤ 直したら、元の状態と比べて、「余計なところを触っていないか」を確かめる

直した結果を、修正前のバックアップと比べます。意図した箇所だけが変わっているかを確認するだけで、「直したつもりで別の場所を壊す」事故を、かなり防げます。

コツ⑥ 「元にしたファイルが最新か」を、必ず疑う

今回の復活の原因は、古いファイルを元にしたことでした。修正する前に、本番の今の状態を取得して、手元のファイルと比べる。 これを、手順に入れておく必要があります。今回の手順を、今後の標準にします。

コツ⑦ 直したら、ルールとして記録する

直しっぱなしにしないで、「なぜ直したか」「今後やってはいけないこと」を、記録に残します。AIは、前の作業の記憶を持ち越さないことがあるので、ルールを文書にしておくと、次の作業でも守らせやすくなります。

コツ⑧ 一度ふさいだ穴が、復活しないか、繰り返し見直す

先ほどの「増築のたびに窓ができる」「古い設計図で鍵が戻る」という話を思い出してください。点検は、1回やって終わりではなく、定期的に、繰り返し行うものです。

コツ⑨ ルールを書くだけでなく、「仕組み」で確かめる

「承認なしに触らない」というルールを書いても、AIは作業の流れの中で、頼んでいない所を変えてしまうことがあります。そこで、反映のたびに、偽装した通信が拒否されることを自動で確かめるテストを実行する運用にしました。ルールを守ってもらうだけでなく、守られているかを、機械的に検査するということです。

エンジニアの方の疑問に、正直にお答えします

「AIに任せて、本当に大丈夫なのか」

大丈夫、とは言い切れません。AIが見落とすこともあります。最終的な判断と責任は、人間にあります。 本格的なシステムでは、専門家による診断(ペネトレーションテスト。実際に攻撃を試みて、穴を探す検査)も併用したほうが安心です。

「それなら、AIを使う意味はあるのか」

あります。今回、ふさいだはずの穴が復活していたことを見つけたのは、AIによる再点検でした。私は、そこに穴があることに、気づいていませんでした。

また、私のような個人でも、これだけの点検と対策を、短い期間で実施できました。今まで「専門家に頼む予算がないから、何もしない」だった場所に、最低限の守りを入れられる。 これが、AIで点検することの、いちばん大きな価値だと思います。

「AIで作ったものは、点検できない」のではありません。「点検を頼まなければ、点検されない」だけです。

経営者・情報システム部門の方へ

まず、確認してほしい4つのこと

サーバー攻撃への備えとして、まず次の4つを、自社のシステムで確認してみてください。

• 入口は固めていますか(通信の暗号化、多要素認証、管理画面の二重の関門)

• 権限は、必要な人に必要な分だけになっていますか

• クラウドを使っているから安全、と思い込んでいませんか(自分で作った設定やプログラムの点検は、クラウドでも必要です)

• 持ち続けなくていいデータを、持ち続けていませんか

もうひとつ、確認してほしいこと

そして、次の2つも確認してみてください。

• 「ふさいだはずの穴」が、復活していないか、定期的に確かめていますか

• 何かあったとき、後から調べられるよう、ログを取っていますか

「作った人」と「点検する人」を分ける

人間であれ、AIであれ、自分が作ったものの穴は、自分では見つけにくいものです。作る役と、点検する役を分ける。AIを使えば、この「点検役」を、手軽に増やすことができます。

完璧な守りはありません

最後に、大切なことをお伝えします。サーバー攻撃に対して、「これで絶対に安全」という状態はありません。 私のシステムも、完璧ではありません。実際、「ふさいだはずの穴」が復活していました。

だからこそ、点検を続けること、そして、見つかった穴を、すばやくふさぎ続けることが重要です。AIは、そのための心強い相棒になります。

なお、この記事は私個人のシステムでの一例であり、セキュリティを保証するものではありません。実際に導入される際は、ご自身の環境に合わせて、専門家にもご相談ください。

まとめ

• 脆弱性は、1日に130件以上のペースで見つかっており、攻撃への対処は「守る側が全部、攻める側は1か所」という不利な戦いである

• 最近の漏洩事案では、お名前の出た2件とも、手口は(確認した時点では)公表されていない。ただ、ログインの突破、設計の穴、委託先経由、不要データの長期保管という「守りの基本」は共通して問われる

• 「クラウドは、できあがっていて安全」は幻想。クラウド事業者が守るのは土台まで。設定、プログラム、データの守りは、利用者自身の仕事(責任共有モデル)

• AIは、攻撃する側の道具にもなるが、守る側の強い味方にもなる。弱点を先に見つけて、先にふさげる

• 私は、自作のコールセンターシステムで、入口の二重化、送信元の偽装対策、権限の3段階化、他サイトからの通信の許可設定(CORS)、パスワードの保管方法、録音データの保護、データの自動削除など、多くの点検と対策を行った

• 再点検で、ふさいだはずの穴が復活していることを、AIが見つけた。原因は、古いファイルを元にした作業で、修正が上書きされたこと(と推測している)

• AIは、頼んでいないところまで変えてしまうことがある。ルールを書くだけでは防ぎきれないので、「何が変わったか」を確かめる仕組み(自動テスト、差分の確認)が必要

• 直すときは、バックアップ、本番の最新版を元に修正、反映前後のテスト、修正前との比較、の順で進める

• アクセスログを取る設定を入れた。費用は、今の規模ならほぼ無料の見込み

• 点検は1回で終わりではなく、繰り返し行う

AIが攻撃に使われる時代だからこそ、守る側も、AIを使うべきです。バイブコーディングは、「作る」ためだけのものではありません。「守る」ためにも、使えます。

【この記事が興味深かった方は、以下記事もおすすめです】

＜おすすめ記事①＞
そのパスワード、チャットに残っていませんか。「読んだら消える」秘密の玉手箱を作った話はこちら。

＜おすすめ記事②＞
興味本位で「見に行く」のが、なぜ危ないのか。GMOの情報流出の件で考えたい方はこちら。

＜おすすめ記事③＞
今回、点検した、自作のAIコールセンターを作り始めた話はこちら。

#サーバー攻撃 #脆弱性 #セキュリティ対策 #情報システム部門 #経営者 #バイブコーディング #AWS #コールセンター #個人開発 #munchie