AIで誰でも攻撃できる時代 ── やられる前に、自分のサイトを自分で検査する

上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。

AIで誰でも攻撃できる時代 ── やられる前に、自分のサイトを自分で検査する

この記事は、連載「自分のサービスは自分で守る ── AI 時代の自衛セキュリティ」の第 1 回です。自分でできる検査は自分で、難しいときは EarthLink Network が検査を代行し、直せない弱点は私たちが修正します。

連載の目次

AIで誰でも攻撃できる時代 ── やられる前に、自分のサイトを自分で検査する（この記事）
攻撃する側が持っているツール ── AI が自分で攻撃を進めるとは（予定）
検査を始める前に ── 本番を壊さず、自分のものだけを調べる（予定）
外から攻めて検査する① ── 準備と、最初の実行まで（予定）
外から攻めて検査する② ── 攻撃ツールと正規ツールで、見つかるものは違う（予定）
自分の書いたコードを検査する ── 静的解析（予定）
使っている部品の弱点を検査する ── 依存ライブラリ（予定）
インフラの設定の穴を検査する（予定）
検査の結果を 1 か所に集めて、どれから直すかを決める（予定）
見つかった弱点の直し方 ── 3 つの道（予定）
自分で直せないときは ── 保守契約という選択（予定）
毎日自動で検査し続ける ── 作る時代から、守り続ける時代へ（予定）

結論

この連載の主張は一つです。攻撃ツールは、もう誰でも無料で手に入ります。攻撃する側はとっくに持っていて、現に使っています。だから、やられてから気づくのではなく、自分のサービスを自分で先に検査して、弱いところを見つけて直す。これがいちばん確実な守り方です。第 1 回のこの記事では、なぜ今それが必要なのかと、連載全体で何をやるのかを説明します。

セキュリティは、もう「狙われるほど目立っている会社の問題」ではありません。目立っていなくても、機械的に片っ端から試される時代になりました。この前提が、この連載の出発点です。

この連載の全 12 回

先に、連載で何をやるのかをお見せします。

第 1 回（この記事）：なぜ今これをやるのか。その考え方と、連載全体の流れ。
第 2 回：攻撃する側が、今どんなツールを持っているのか。AI が自分で攻撃を進めるとは、どういうことか。入手の方法ではなく、どこまでできる相手なのかを知ります。
第 3 回：検査を始める前に決めておくこと。本番を壊さないように、本番とは別に用意した同じ作りの環境で試すこと。そして、自分のもの以外は調べないこと。
第 4 回：外から攻めて検査します。準備と、最初の検査を実行するところまで。
第 5 回：外から攻める検査の結果。攻撃する側が使うツールと、正規の検査ツールとで、見つかるものがどう違うかを比べます。
第 6 回：自分の書いたコードを、動かさずに読んで検査します（静的解析）。
第 7 回：使っている部品（ライブラリ）に、知られた弱点が残っていないかを検査します。見つかる件数が多くなりやすいのが、ここです。
第 8 回：サーバやクラウドの設定に、穴がないかを検査します。
第 9 回：ばらばらに出てきた検査の結果を 1 か所に集め、つながっている取引先や部品の危なさも含めて、どれから直すかを決めます。
第 10 回：見つかった弱点の直し方。3 つの道があります。
第 11 回：自分では直せないときに、保守の契約で直してもらうという選択。
第 12 回：検査を毎日自動で回し続ける。作る時代から、守り続ける時代へ。

検査の対象は、私たちが運営している自社サービス promptflow です。

2026 年 10 月、世界中で情報流出の公表が続いた

2026 年 10 月は、情報流出の公表が世界中で止まりませんでした。アメリカでは、Oracle のヘルスケア部門（旧 Cerner）で 2025 年に起きた流出の被害が約 2,000 万人に増えたことや、心臓モニターの iRhythm で約 820 万人分の情報が盗まれていたことが、相次いで明らかになりました。英国の通販 ASOS は顧客情報の流出を、教育系の Frontline Education は学校職員の情報の流出を公表しました。日本でも、ヤマト運輸が 531 万件の個人情報漏洩を公表し、ある集計では 1 か月で 40 件を超える発表がありました。世界全体では、セキュリティ会社 Bitdefender の集計によると、直前の 9 月の 1 か月だけで 790 の組織が、ランサムウェアの被害者として犯人側に名前を出されました。前の年の同じ月より 3 割多い数です。

数字を並べると他人事に見えますが、私が引っかかったのは、被害に遭った会社の顔ぶれでした。運送会社、通販、病院系、学校の事務。どこにでもある普通の会社ばかりで、特別に狙われる理由があったようには見えません。

狙われたのは、特別な会社ではない

報道を読んでいて、もう一つ気づいたことがあります。入られた経路が、特別なものではないのです。取引先のサーバ、API（ほかのシステムやアプリがデータを取りに来るための、決まった入口）や管理画面の設定ミス、ソフトの古い不具合、使い回されて漏れたパスワード。並べてみると、どれも多くの会社がそのまま持っている、ごく普通の経路です。

一つだけ、具体的に書いておきます。使い回されたパスワードというのは、こういうことです。どこか別のサービスで、利用者のメールアドレスとパスワードの組が、まとめて漏れたとします。攻撃する側は、その組を、まったく関係のない何百ものサイトに片っ端から入力してみます。同じパスワードを使い回していた人のところだけ、すっと通ってしまう。あなたのサイトそのものが破られたのではなく、利用者が別の場所で漏らしたものが、あなたのサイトでたまたま通ってしまう。これも、人ではなく機械が、休みなく自動でやります。だから「うちのパスワード管理はしっかりしている」と思っていても、利用者側の事情で入られることがあるのです。

さらに今の攻撃には、昔と違う性質があります。人がやる攻撃は、狙いを定めてから動きました。「あの会社のあの情報が欲しい」という動機が先にあって、時間をかけて一社に取り組んだのです。しかし自動化された攻撃は、順番が逆です。インターネット全体を機械的に片っ端から調べていき、たまたま穴があったところを後から拾います。あなたのサービスが有名かどうか、規模が大きいかどうかは関係ありません。公開されていて、たまたま穴があれば、それで十分なのです。だから「うちのような小さなところを、わざわざ狙う人はいない」という安心は、自動化された相手には通用しません。狙われているのではなく、全部まとめて調べられている、と考えたほうが実態に近いと思います。

攻撃は、もう特別な技術が要らない

ここが、今までといちばん違う点です。少し前まで、攻撃にはそれなりの技術が要りました。どこを調べるか、次に何を試すか、人が自分の頭で考える必要があったのです。

家の鍵でたとえてみます。昔ながらのシリンダー錠、つまり鍵を挿して回すよくあるタイプは、細い金具を挿して手の感覚でピンを一つずつ合わせる職人技でこじ開けられました。だから「誰でも」はできませんでした。できる人が限られていたこと自体が、ある意味で守りになっていたのです。ところが、鍵に被せてボタンを押すだけで回ってしまう装置が出回ると、話が変わります。職人技も、経験も要らない。だから、表面に小さなくぼみが並んだ複製されにくい鍵、いわゆるディンプルキーへの置き換えが進みました。簡単に通用する万能の合鍵が出てしまった以上、それに耐える鍵へ替えるしかなかったからです。

セキュリティの世界で、いままさに同じことが起きています。

AI が攻撃の段取りを引き受ける

2025 年の夏ごろから、攻撃の段取りそのものを AI が肩代わりするツールが、無料で配られ始めました。

一例が、中国の会社が出した Villager というツールです。人が「このサイトを調べて」と指示するだけで、どこを調べ、何を試し、次に何をするかを、AI が自分で決めながら進めます。これが、プログラムの部品を誰でも取ってこられる公開の場所に無料で置かれ、公表までのおよそ 2 か月で約 1 万回ダウンロードされました。中身は第 2 回でくわしく説明します。

Villager だけではありません。同じように AI が自分で攻撃を進めるツールは、プログラムを公開して共有する場所で、いくつも複製されて並んでいます。どれくらい広がっているのか。あるツールにはおよそ 7,700、別のものには 4,700、さらに別のものには 2,900 という複製（コピーして自分用に持つこと）が付いています。一つが話題になれば、似たものがすぐに何百と広がる。これが、無料で配られているソフトの現実です。止めようと思って止められるものではありません。

その中には、「あなたのアプリの弱点を見つけて直すため」とうたう、本来は守る側のための正規のツールもあります。この連載では、その両方を自分のサービスに使います。攻撃する側が実際に使っているやり方で確かめないと、本当に入られるところは分からないからです。そのうえで、正規のツールとでは見つかるものがどう違うかも、自分のサービスで比べてお見せします。

ここで言いたいのは、良い悪いの話ではありません。技術の敷居が、ほぼゼロまで下がった、という事実です。短い指示を一つ入れれば、誰でも——極端に言えば子供でも——攻撃を進められてしまう。腕の有無が守りになっていた時代は、もう終わりかけています。

小さい会社ほど、確かめていない

皮肉なことに、こうした自動化された攻撃にいちばん無防備なのは、小さい会社です。大きな会社には、セキュリティの専門担当者がいて、自分たちで定期的に試しています。外部の専門会社に頼む予算もあります。ところが、個人事業主や数人の会社には、その人手も予算もありません。結果として、いちばん確かめていないところが、いちばん無差別に試される、という状態が生まれています。確かめていないから、弱点があることにも気づけない。気づけないから、漏れて初めて知る。この順番が、いちばん怖いところです。

私がワンクリックで動くツールにこだわるのは、ここに理由があります。専門の担当者を雇えなくても、ツールが段取りをやってくれるなら、小さい会社でも一度は自分で試せます。難しい専門知識が要るうちは、「大事なのは分かっているけれど、うちには無理」で止まってしまう。誰でも一度は実行できる形になって初めて、確かめるという行動が現実になります。攻撃の敷居が下がったのと同じ理屈で、確かめる敷居も下がりました。悪いことばかりではない、と私は思っています。

情報を隠しても、守る側が損をするだけ

こう書くと、必ず返ってくる反論があります。「そんなツールの名前を記事に出すな。攻撃する側に手がかりを与えることになる」。もっともらしく聞こえます。でも私は、この考え方そのものが逆だと思っています。

まず、攻撃する側は、こういう真っ当な記事からツールを知るわけではありません。彼らはとっくに、別のところから手に入れています。手に入れているから、現に攻撃しているのです。2026 年 10 月の流出の山が、その証拠です。公表された被害は、情報を隠していたから防げた、というものではありません。情報を隠して止められる相手ではないのです。

では、情報を隠して誰が困るのか。困るのは、自分で探す手段を持たない人——つまり守る側だけです。攻撃する側は何が来るかを知っていて、守る側だけが知らない。守る人が、自分が何から守られていないのかを知らない。これがいちばん危ない状態です。

実際、守る側はこの公開された情報で助かっています。あるツールがどんな弱点を突くのかが公になれば、同じ弱点を持つソフトの作り手が、急いで直せます。使っている人も、設定を見直せます。情報が回るからこそ、守りが間に合う。隠していたら、誰も直せないまま、攻撃する側だけが黙って使い続けるだけです。

鍵の世界でも同じでした。鍵の仕組みを秘密にしても、鍵そのものが弱ければ破られます。強い鍵は、仕組みが公開されていても破られないから強いのです。ソフトのセキュリティも同じで、隠して守るのではなく、知られても耐えるように作る。だから私は、ツールの名前も、それが何をするかも、自分のサービスを検査した結果も、この連載では隠さずに書きます。

まず、自分のサービスを自分で検査する

やることは単純です。攻撃する側が使っているのと同じツールを、まず自分のサービスに対して自分で使い、弱いところを先に見つけて直す。たとえるなら、簡単に通用する万能の合鍵が売られているなら、まず自分の家の鍵でそれが通用するか試してみる。通用してしまったら、強い鍵へ替える。それだけのことです。

検査の対象を自社サービスの promptflow に限るのには、理由があります。自分のものなら、どこまで試すかを自分たちで決められ、試す環境から利用者や外のサービスに影響が出ないように止めておくこともできます。そして、自分のものの弱点は、他の誰でもなく自分がいちばん直せる立場にいる。試して、弱いところを見つけて、直す。この一連を、自分の資産に対してやって見せるのが、いちばん正直で、いちばん役に立つと考えました。

promptflow は、私たちが作って運営している、AI とのやり取りを扱う自社のサービスです。利用者がログインして使い、外とは API でもつながっています。ログインの入口があり、データを預かり、外部とつながっている。つまり、今回の流出で入口になったのと同じ要素を、ひととおり持っています。だからこそ、検査の題材にちょうどいいと考えました。自分たちのサービスで弱いところが見つかれば、それは、読んでいるあなたのサービスでも同じところが弱いかもしれない、ということです。自分のサービスで試す手順をそのままお見せするので、あなたは自分のサービスで同じことを確かめられます。

「安全かどうか」は、試してから人が判断する

もう少しだけ、私がこの連載を大事に思う理由を書かせてください。

私はもともと、これからの人間の仕事は判断に専念することだと考えています。雑用や、決まりきった作業は、できるだけ AI に任せたい。そのうえで、「このメールを送っていいか」「この設定で公開していいか」「この料金でいいか」は、最後に人が判断する。叩き台は AI が作り、人は判断だけをする。そういう形を、自分の会社で実際にやろうとしています。

「自分のサービスは安全か」も、まったく同じ種類の判断です。そして判断には、実際に試した事実が要ります。試さずに「たぶん大丈夫」と言うのは、判断ではなく願望です。願望で会社を守ることはできません。

少し前まで、攻撃する側だけが有利でした。攻撃は自動化されているのに、守る側は手作業で一つずつ確かめるしかなかったからです。でも今は、同じ自動化を守る側も使えます。攻撃する側がワンクリックで試せるなら、こちらも同じワンクリックで試せる。有利さの差が、少しだけこちらに戻ってきました。使わない手はありません。

連載で実際にやること

第 4 回からは、promptflow を実際に検査していきます。イメージがわかないと不安だと思うので、何をするのかを、具体的な操作ではなく考え方だけ先に書いておきます。

検査は、大きく分けて二つの方向から行います。

外から攻めて確かめる：攻撃する側と同じように、外からサービスを試します。ログインの画面、API の入口、管理画面、公開しているつもりのないファイル。そうした入口を数え上げ、通していい相手だけを通すかを確かめ、見つかった弱点が本当に外から届くのかまで確かめます。理屈の上で危ないのと、実際に外から触れてしまうのとは、別だからです。
中を読んで確かめる：自分のサービスなら、中身も見られます。自分の書いたコード、使っている部品（ライブラリ）、サーバやクラウドの設定。この三つを、動かさずに読んで、知られた弱点や設定の穴が残っていないかを確かめます。

自分のサービスだけを守っても、つながっている取引先や、ほかの会社と一緒に使っている仕組みが破られれば、そこから入られます。今回の流出でも、入口の一つは取引先のサーバでした。だから、自分のサービスがどこにつながっていて、どの部品や外のサービスに頼っているのかも洗い出し、その危なさも結果に含めます。相手のサイトを検査するのではありません。つながりと、知られている弱点の情報を集めるということです。

外からだけ、中からだけでは、見落としが出ます。両方の結果を 1 か所に集めて、どれから直すかを決め、直す。自分で直せないものは、直せる人に頼む。ここまでで、ひとまわりです。

AI のツールは、こうした検査を、人が一つずつ指示しなくても自分でつないで進めてくれます。高い AI や専門家がいなくても、安い AI で数をこなせば、かなりのところまで調べられます。攻撃する側がやっているのも、まさにそういうやり方です。だから初めての人でも、全体を一度は通して実行しやすくなっています。細かいやり方は第 4 回から、promptflow の画面を見せながら順に説明します。

もう一つ、先に言っておきたいことがあります。検査は、一度やって終わり、ではありません。サービスは直し続けるものですし、新しい弱点も次々に見つかります。攻撃する側が自動で何度も試してくるなら、守る側も、自動で試し直し続ける。部品の弱点は毎日のように新しく見つかるので、部品やコードの検査は毎日自動で回すのがいちばん確実です。外から攻める検査は、毎日ではなく、本番とは別の環境で回します。連載の最後には、その仕組みまでお見せします。

自分のサービスが、壊れてしまわないか

ここで心配になるのが、「自分のサービスに攻撃のツールを使って、壊れてしまわないか」という点だと思います。正直に言うと、やり方しだいでは、サービスに負担がかかることはあります。ですから第 3 回では、本番のサービスには使わず、本番とは別に用意した同じ作りの環境か、ソースコードのコピーに対して試すやり方と、攻撃をかけすぎないための線引きを説明します。試す場所と、かける量さえ守れば、怖がりすぎる必要はありません。むしろ、何も確かめないまま本番を動かし続けているほうが、よほど危ない。

他人のサイトには、絶対に使わないでください

最後に、一つだけ注意です。この連載で紹介するツールや考え方は、自分が持っているサービスを検査するためのものです。他人のサイトや、自分が権利を持っていないシステムに対して使うことは、絶対にしないでください。法律に触れますし、この連載の目的とも正反対です。検査していいのは、あくまで自分のものだけです。

この記事の情報の出どころ

この記事に書いた攻撃ツールの説明は、報道や公開されている情報に基づくものです。自分のサービスで実際に試した結果は、第 4 回以降で画面のまま出します。弱点が見つかったところも、見つからなかったところも、弱点ではないのに弱点として出てきたものも、そのまま書きます。

次回

次回は、攻撃する側が持っているツールの中身に入ります。AI が自分で攻撃を進めるとは、具体的にどういう段取りなのか。守る側として、何を前提に考えればいいのか。くり返しますが、入手の方法は書きません。何ができる相手なのかを知ったうえで、落ち着いて自分のサービスを確かめられるように書きます。

この連載では、攻撃ツールが誰でも無料で手に入る時代に、自分のサービスを自分で検査し、弱いところを先に見つけて直す手順を、順に示します。検査の対象は自社サービスに限り、他人のサイトを攻撃する手順は扱いません。自分で検査するのが難しい方は、EarthLink Network が検査を代行します。弱点は見つかったが自分では直せない、という方は、私たちが修正まで引き受けます。お気軽にご相談ください。役に立ったと感じたら、ぜひ「いいね」と記事の購読をお願いいたします。

自社プロダクトは https://www.eln.ne.jp/products にまとめています。

筆者について

上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。

また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。

EarthLink Network は、会社の全業務を AI で回すために、必要になったものを自社で作っています。いま作っているプロダクトの一覧と概要は、こちらにまとめています。

→ EarthLink Network が自社でつくっている18のプロダクト

会社と各プロダクトの詳細は、公式サイト www.eln.ne.jp をご覧ください。