検査を始める前に ── 検査の全体像と、本番を壊さない線引き

Last updated at 2026-10-30Posted at 2026-10-24

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

検査を始める前に ── 検査の全体像と、本番を壊さない線引き

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

連載の目次

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

結論

自分のサービスの検査は、1 種類では足りません。外から攻撃する側と同じように試す検査と、中身を調べる検査があり、中身を調べる検査はさらに、自分の書いたコード、使っている部品（ライブラリ）、サーバやクラウドの設定、の三つに分かれます。自分の書いたコードの検査には、鍵やパスワードの書き残しを探すことも含めます。それぞれ見つけるものが違うので、どれか一つだけでは見落としが出ます。出てきた結果を 1 か所に集め、毎日自動で回し、見つかったものを直す。ここまでがひとまわりです。

私たちは自社サービスの promptflow で、このうちコードと部品と秘密の置き忘れの検査を、毎日自動で回しています。使っているのは Trivy・Gitleaks・Semgrep という無料のツールで、2026 年 6 月 26 日から 10 月 23 日までに、決まった時刻の自動実行だけで 115 回実行されました。検査の中身そのものは、ほとんどが無料のツールで揃います。有料で変わるのは、コードを公開していない場合（GitHub などに非公開で置いている場合）に使えるかどうか、使える人数や回数の上限、結果をまとめて管理する画面などです。

そして、検査を始める前に決めておくことが四つあります。

本番には向けない。コピーか、本番とは別の環境に向ける。
かけすぎない。範囲・回数・費用・時間に、機械で止まる上限をかける。
使っているクラウドの、検査に関するルールを先に確かめる。
自分のもの以外は調べない。

手を動かすのは次の第 4 回からなので、この回では検査の全体の様子と、守ることを先に揃えます。

検査の種類と、この連載のどの回で扱うか

検査には、大きく分けて二つのやり方があります。

一つは、動いているサービスに外から実際にリクエスト（サービスへの問い合わせの通信）を送って、弱点を探す検査です。攻撃する側と同じ目線で、入口を一つずつ試します。英語では動的な検査（DAST）と呼ばれます。

もう一つは、サービスを動かさずに、中身を調べる検査です。自分のサービスなら中身が手元にあるので、外からは見えない書き方の間違いや、古い部品まで見つかります。英語では静的な検査と呼ばれ、調べる相手によってさらに分かれます。

この連載で扱う検査を、種類ごとに並べます。ツールの名前は、私たちが実際に使ったものを例として添えています。

検査の種類	何を見つけるか	例として使うツール	扱う回
外から試す検査	動いているサービスの入口の弱点（応答の守りの設定の抜け、ログインの扱いの不備など）	ZAP（無料）、StackHawk（有料・お試しあり）、HexStrike（攻撃する側のツール）	第 4・5 回
自分の書いたコードを調べる検査	危ない書き方、鍵やパスワードの書き残し	Semgrep、Gitleaks（どちらも無料）、AI にコードを読ませる Strix	第 4・6 回
使っている部品の弱点の検査	知られた弱点が残っている古いライブラリ	Trivy（無料）、Dependabot（GitHub に無料で付いている）	第 7 回
インフラの設定の検査	サーバやクラウドの設定の抜け（公開しすぎ、鍵のかけ忘れなど）	Trivy の設定の検査、Checkov や Prowler（どれも無料）	第 8 回
結果を 1 か所に集める	重複をまとめ、重さで並べ、いつ直したかを残す	DefectDojo（無料）	第 9 回
直す・頼む	自分で直す、AI に直させる、直せる人に頼む	―	第 10・11 回
毎日自動で回し続ける	新しく見つかった弱点に、翌朝には気づく	GitHub Actions の定期実行	第 12 回

AI のツールは、この表の中で別の種類として立っているわけではありません。外から試す検査の段取りを AI にさせるもの（HexStrike）もあれば、コードを読む検査を AI にさせるもの（Strix）もあります。どちらのやり方の中にも「AI に段取りさせる型」がある、と考えるのが正確です。第 4 回でこの二つを実際に動かします。

なぜ、1 種類の検査では足りないのか

外から試す検査と、中を調べる検査は、見つけるものが違います。これは考え方の話ではなく、私たちが自分のサービスのコピーで実際に試した結果です。くわしくは第 5 回で並べますが、先に一つだけ言うと、同じログインまわりの処理を相手に、外から試すツールは「応答に付けるべき守りの設定（ヘッダ）が抜けている」ことを見つけ、コードを読むツールは「ログアウトしたのにサーバ側のログインが残る」「記録に書く『誰が』を、確かめていない鍵の中身から読んでいる」といった、外からは見えにくいものを見つけました。重なったものは、ほとんどありませんでした。

中を調べる検査にも、さらに種類があります。自分たちが書いたコードの危ない書き方、使っている部品の知られた弱点、そして鍵やパスワードの置き忘れ。サービスを動かしている土台（インフラ）の構成が手元にあるなら、その構成も同じように動かさずに調べられます。構成をファイルで管理していないサービスなら、いまの構成を設計図の形（Terraform など）に起こし直してから調べる、という手もあります。これは第 8 回で試します。

中を調べる検査には、もう一つ大きな利点があります。サービスを動かさないので、本番にも開発用の環境にも一切触れません。だから、検査に慣れていない人がまず始めるのに、いちばん安全です。

私たちが毎日自動で回している検査

ここからは実物です。promptflow のソースコードは、GitHub のリポジトリ（コードと変更の履歴をまとめて置いておく場所）に、外には公開しない形で置いてあります。そのリポジトリに、毎日 1 回、朝に自動で検査を回す設定が入っています。GitHub Actions という、GitHub に付いている自動実行の仕組みを使っています。

この設定で、毎日三つの検査が回ります。

Trivy：使っている部品の一覧を見て、知られた弱点が残っているものを探します。弱点の一覧は毎日更新されるので、コードを何も変えていなくても、昨日まで無かった弱点が今日見つかることがあります。毎日回す理由はここにあります。
Gitleaks：コードの中に、鍵やパスワードを書き残していないかを探します。
Semgrep：自分たちが書いたコードに、危ない書き方がないかを、決まった型（ルール）に照らして探します。ここではセキュリティ向けの型の集まり（p/security-audit）を使っています。

三つとも、オープンソース（作り方の中身が公開されていて、誰でも無料で使えるソフト）の無料のツールです（Trivy は Apache-2.0、Gitleaks は MIT、Semgrep の本体は LGPL-2.1）。結果は第 9 回で見せる集約の置き場（DefectDojo）に送られ、新しく重い弱点（Critical か High）が見つかったときだけ、チャットに通知が届くようにしてあります。

では、本当に毎日回っているのか。GitHub の実行記録を、コマンドで取り出してみます。

直近の 10 回は、すべて成功です。記録をさかのぼると、最初の実行は 2026 年 6 月 26 日で、10 月 23 日までに決まった時刻の自動実行が 115 回あり、そのうち 114 回が成功、1 回が失敗でした（ほかに、人が手で 1 回起動しています）。1 回の実行は、多くが 1〜2 分で終わります。一覧の中に 1 時間 34 分かかった回がありますが、これも最後まで終わって成功しています。人が毎朝なにかをしているわけではありません。一度設定してしまえば、あとは機械が毎日回します。

部品の更新は、月に 1 回

使っている部品については、もう一つ別の仕組みも動かしています。GitHub に付いている Dependabot です。部品に新しい版が出ると、更新の依頼（プルリクエスト）を自動で作ってくれます。

ここは、正直に書いておきます。私たちの設定では、Dependabot は毎日ではなく、月に 1 回です。

4 種類の部品すべてが、月に 1 回の更新です。実際に Dependabot が作った更新の依頼を取り出すと（一覧の画面は第 7 回でお見せします）、おおむね月の初めにまとめて届いていました。

10 月 1 日には 69 個、9 月 1 日には 58 個の部品の更新が、それぞれ 1 本にまとめて届いています。8 月だけは、まとめた依頼が 1 日・4 日・7 日・11 日と 4 回作られました（前のものを閉じての作り直しが 3 回）。また、10 月 1 日と 9 月 1 日の 2 本は、取り込まずに閉じています。届いた更新をすべて取り込めているわけではない、ということも正直に書いておきます。取り込まずに閉じた理由は、第 10 回で、10 月 1 日の 1 本を例に書きます。毎日の弱点の検査は Trivy が、月に 1 回の新しい版への更新は Dependabot が受け持つ、という分担です。

Dependabot には、弱点が見つかった部品をすぐに知らせる機能（Dependabot alerts）もあり、これも無料です。弱点のある部品を見つけたときに自動で更新の依頼を作る機能（Dependabot security updates）もあります。私たちのリポジトリでは、この記事のために確かめるまで、どちらも有効にしていませんでした（2026-10-23 に GitHub の API（プログラムから問い合わせる窓口）に問い合わせて、どちらも無効の返事でした）。確かめたあと、同じ日の夜に、両方とも有効にしました。有効にしてからは、弱点のある部品が見つかると、月に 1 回の更新の日を待たずに、更新の依頼が届きます（有効にしたその夜にも、いくつか届きました）。毎日の Trivy の結果とどこが重なり、何が変わるかは、第 7 回で部品の検査を扱うときに確かめます。

無料でできること、有料で変わること

ここまでの検査は、すべて無料のツールで回っています。では、有料のツールやプランで何が変わるのか。各社の公式の料金ページを 2026 年 10 月 23 日に確かめて、撮っておきました。料金は変わるので、使う前にはご自分で最新のページを確かめてください。

先に、この連載で名前が出るツールと、よく比べられるツールを、一つの表に並べます。導入難度は、一般的な Web のサービスの開発で、自動で回せるようになるまでの目安です。AI のツールは、前の表では種類として分けませんでしたが、この表では比べやすいように一つの分類にまとめています。

分類	ツール	無料利用	主な検査対象	導入難度
自分の書いたコードを調べる検査（SAST）	Semgrep	◎ オープンソース＋有料	ソースコードの弱点	低
自分の書いたコードを調べる検査（SAST）	SonarQube	○ 無料版＋有料	コードの品質・弱点	中
コードと部品をまとめて調べる検査（SAST・SCA）	Snyk	○ 制限付きで無料	コード・使っている部品・インフラの設定ファイル（IaC）・コンテナ	低
使っている部品の弱点の検査（SCA）	Dependabot	◎	部品の知られた弱点（CVE）・更新の依頼（プルリクエスト）	低
使っている部品の弱点の検査（SCA）	Trivy	◎ オープンソース	部品・コンテナ・設定・鍵やパスワードの書き残し	低
外から試す検査（DAST）	ZAP	◎ オープンソース	Web のサービスや API に実際に試す検査	低〜中
外から試す検査（DAST）	Nuclei	◎ オープンソース	知られた弱点（CVE）・知られた攻撃の型・外から見えてしまっている設定	低
外から試す検査（DAST）	Burp Suite	△ 自動の検査は有料	Web・API・ログインまわりなど	中
外から試す検査（DAST）	Invicti	× 有料	Web・API の弱点の自動の確かめ	中
インフラの設定の検査（設定ファイル・IaC）	cdk-nag	◎ オープンソース	AWS CDK の設定の不備	低
インフラの設定の検査（設定ファイル・IaC）	Checkov	◎ オープンソース	Terraform・CDK・CloudFormation など	低
インフラの設定の検査（クラウドの実際の設定）	Prowler	◎ オープンソース＋有料	AWS の実際の設定・権限（IAM）・公開の範囲	低〜中
AWS 上で動くものの弱点の検査	Amazon Inspector	△ 短いお試しのあとは使った分だけ課金	EC2・Lambda・ECR・コード	低
AI が自分で進める侵入を試す検査	Strix	◎ オープンソース＋有料のクラウド版	URL・コード・AI が自分で進める検査	中
AI が自分で進める侵入を試す検査	PentAGI	◎ オープンソース＋有料版	複数の AI が手分けして侵入を試す	中〜高
AI が自分で進める侵入を試す検査	ARTEX	公式の公開は終了	AI が自分で進める侵入の試み	非推奨

◎ は無料で主な機能が使える、○ は無料版に制限がある、△ はお試しか一部の機能だけ、× は原則として有料、という意味です。オープンソースのツールでも、中で動かす AI の利用料や、動かす環境の費用は別にかかることがあります。

ARTEX は、元の GitHub のリポジトリが無くなりました。その後、元のコードをもとにした非公式のコピーが別の名前で広まっていると、韓国のセキュリティ会社 AhnLab の調査チーム（ASEC）が報告しています。入れる候補からは外すのが妥当です。

ここからは、料金のページの実物を見ていきます。まず、外から試す検査の ZAP です。ずっと無料のオープンソースです。

同じ外から試す検査でも、StackHawk には、ずっと無料で使えるプランはありません。

第 5 回で StackHawk を使った結果を見せますが、それはこの 14 日間の無料お試しの期間内で試したものです。続けて使うなら、1 人あたり月 10 ドルがかかります。

自分の書いたコードの検査では、GitHub の CodeQL が有名です。ただし、無料で使えるのは公開しているリポジトリだけです。

promptflow のリポジトリは非公開なので、CodeQL を使うには、コードを書き込む人 1 人あたり月 30 ドルの追加と、GitHub の Team 以上のプランが要ります。GitHub の API に問い合わせると、「Code Security を有効にしないとコードの検査は使えない」という返事でした。私たちは CodeQL を使っておらず、自分のコードの検査には無料の Semgrep を毎日回しています。

その Semgrep にも、無料の範囲と有料の範囲があります。

Semgrep には二つの無料の使い方があります。ログインせずにコマンドだけで使う版（Community Edition）と、Semgrep のサービスに登録して使う Free Edition です。私たちが毎日の検査で使っているのは前者です。Semgrep の公式の説明では、コマンドだけの版は一つの関数や一つのファイルの中しか調べず、ファイルをまたいだデータの流れは追いません。Free Edition に登録すると、10 人・10 個のリポジトリまでなら、ファイルをまたいで調べる機能も無料で使えます。

ほかのツールも合わせると、無料と有料の違いは、だいたい次の五つにまとまります。

検査の中身は、多くが無料で揃う。 ZAP・Trivy・Gitleaks・Semgrep・Checkov・Prowler・DefectDojo は、どれもオープンソースで、検査そのものは無料で使えます。有料版がある製品で増えるのは、たとえば Prowler なら、予約して回す仕組み、まとめて管理する画面、チャットや課題管理のツールとの連携、サポートです（Prowler の公式の料金ページの説明）。
公開リポジトリなら無料、非公開なら有料、という線引きがある。 GitHub の CodeQL と、鍵の漏れを止める機能がそうです。非公開のリポジトリで使うと、1 人あたり月 30 ドルと月 19 ドルがかかります。ただし Dependabot は、無料プランでも使えます。
無料版は、量で区切られている。 Semgrep の Free Edition は 10 人・10 リポジトリまで、というように、人数・リポジトリの数・回数に上限があります。
調べる深さで差を付ける製品がある。 Semgrep のコマンドだけの版のように、無料版は一つのファイルの中しか見ず、有料版や登録版はファイルをまたいで追う、というものです。
ずっと無料のプランが無い製品もある。 StackHawk は 14 日間のお試しだけです。「無料で使える」と書かれていても、お試しの期間のことなのか、ずっと無料なのかは、料金ページで確かめてください。

同じ違いを、検査の場面ごとに並べると、次のようになります。

比較項目	無料のツール	有料のツール
新しく見つかった弱点（CVE）への追従	公開されている弱点の情報と、検査の型（ルール）の更新で追いつく	独自の情報や、直す順番の付け方が加わることがある
まだ知られていない弱点	コードを調べる検査や、思いがけない入力を大量に送る検査（ファジング）などで見つけられる	より深くデータの流れを追う解析や、独自の型が加わることがある
URL だけでの検査	Nuclei・ZAP でできる	より細かくサイトを巡回したり、ログインの状態を保ったりする製品もある
ログインしたあとの画面の検査	設定すればできる	ログインの状態を保つことや、複数の役割（権限）の切り替えが楽な場合がある
AI が自分で進める侵入を試す検査	Strix・PentAGI でできる	続けて回すこと、結果の管理、直したあとの検査のやり直しなどが充実している
続けて自動で回す	GitHub Actions などで組める	予約・通知・まとめての管理が最初から入っていることが多い
複数のプロジェクトの管理	自分で作るか、別のツールとつなぐ必要が出やすい	まとめて見る画面や、権限の管理が充実している

有料だからといって、新しい弱点を必ず早く見つけるわけではありません。たとえば Nuclei では、公開されている検査の型が、続けて更新されています。Prowler は、有料版も無料版と同じ検査の仕組みで動きます（Prowler の公式の料金ページに「Every edition runs the same open-source engine」とあります）。一方で、SonarQube のデータの流れを追う解析（有料の Team 以上）や、Burp Suite の自動の検査（無料の Community 版には無い）のように、有料版で見つける機能そのものが増える例もあります。

AI のツールについても書いておきます。第 4 回で使う Strix も HexStrike も、ツール本体は無料のオープンソースです（Strix は Apache-2.0、HexStrike は MIT）。かかるのは、中で動かす AI の利用料だけで、自分で選んだ AI の会社に払います。私たちが安い AI（DeepSeek）で動かしたときは、Strix で 1 回 0.45 ドル、HexStrike で 1 回 0.0331 ドルでした。

URL を一つ渡して自動で検査させる使い方では、ツールごとに次のような違いがあります。

ツール	URL 起点で開始	サイト巡回	AI が次の検査を判断	特徴
Nuclei	◎	△ 別の巡回ツールとつなぐ	×	知られた弱点（CVE）を手早く調べる
ZAP	◎	◎	× 標準では決まった型（ルール）が中心	Web のサービスを広く調べる
Burp Suite Professional	◎	◎	△ AI の手助けがある	ログインまわりや、細かい Web の検査
Strix	◎	―	◎	自分で探して、確かめる
PentAGI	―	―	◎	複数の AI が手分けして確かめる

◎ は主な機能、○ は対応している、△ は限られるか別のツールとつなぐ、― は公式の説明に書かれていない、という意味です。どのツールも、URL を渡すだけで、すべてのページやすべてのログインの種類を漏れなく調べられるわけではありません。

最後に、組み合わせの例です。Next.js・TypeScript・AWS CDK・GitHub Actions を中心に作っているサービスなら、次の組み合わせが候補になります。

実行タイミング	使用するツール	目的
コードを変えたとき（プルリクエスト）	Semgrep ＋ Trivy	コードと使っている部品の検査
CDK を変えたとき	cdk-nag ＋ Checkov	反映する前の設定の検査
毎日・弱点の情報（CVE）が更新されたとき	Dependabot ＋ Trivy	新しく見つかった弱点に気づく
ずっと見張る	Amazon Inspector（必要な AWS の資源だけ）	AWS の上で実際に動いているものの検査
毎日・定期	Prowler	AWS の実際の設定と権限の確認
定期・本番とは別の環境	Nuclei ＋ ZAP	外から試す検査
大きな変更のあと・定期	Strix または PentAGI	複数の弱点を組み合わせた侵入を試す検査

外から試す検査や、AI に侵入を試させる検査は、どれも本番ではなく、別の環境に向けて行います。その線引きを、次の節で書きます。

検査の対象は、本番ではなく「別の環境」に

ここからが、始める前の線引きです。いちばん大事なのは、検査を本番のサービスに向けないことです。

外から試す検査は、実際に攻撃と同じリクエストを送ります。本番に向けると、本番のデータを書き換えたり、お客さまに影響が出たりする恐れがあります。それに、公開中のサービスに強い検査を次々とかけると、通信を受けているクラウドの防御の仕組みが「これは攻撃だ」と判断して、送り元を遮断することがあります。自分で自分のサービスへの通信を止めてしまうわけです。ひどいときは、同じネットワークから出ている他のサービスまで巻き添えで遮断されます。守るための検査で自分のサービスを止めてしまっては、検査をする意味がありません。

だから、向ける先は二つのどちらかにします。

本番とは別に用意した、同じ作りの環境。 多くのサービスは、開発中の動作を確かめるための環境（開発環境、dev 環境）を持っています。そこへ向ければ、本番のお客さまにもデータにも影響しません。
ソースコードのコピー。 中を調べる検査なら、コピーを動かす必要すらありません。

ここで、私たち自身が思い違いをしかけたことを書いておきます。「手元のパソコンで起動したサービスなら、本番とは別だから安全だろう」と思いがちですが、そうとは限りません。

promptflow のコードは、データベースの表やファイルの置き場の名前を指定しないで起動すると、すべて本番の名前を使います。手元で起動するための .env.local には、本番の鍵がそのまま入っています。開発用の環境（staging）の値を入れて起動すれば、多くの表は開発用のものに向きます。それでも、ファイルの置き場は、その開発用の環境でも本番と同じものを使っています（どれも 2026-10-24 に、いまのコードと、コードに残した設定の注記で確かめました）。起動のしかたによっては、手元のサービスに外から検査をかけると、検査のリクエストがそのまま本番のデータを読み書きします。「手元だから安全」とは限らなかったのです。検査を始める前に、自分のサービスが手元や開発環境でどこにつながっているのかを、設定ファイルで確かめてください。

そこで私たちは、二つのやり方を選びました。一つは、ソースコードのコピーを作って、コードを読む検査だけをすること（第 4 回の Strix）。もう一つは、外から試す検査のために、ログインまわりの処理だけを写したコピーを、外から入れない閉じた環境で動かすことです（第 4・5 回の HexStrike・ZAP・StackHawk）。

この閉じた環境では、検査される側（target）は外に入口を持たず、同じ仮のネットワークの中にいる攻撃役からしか届きません。外から入ることはできませんが、中から外へ出ていく通信までは止めていません。攻撃役も AI を呼ぶために外へ通信しますが、検査のリクエストを送ってよい先は target だけです。本番のデータベースにも、本物のログインの仕組みにもつながっていません。

ただし、この環境は、本番と同じ作りの開発環境そのものではありません。ログインの相手を簡易版で置き換えているので、その簡易版の甘さが、弱点のように見えてしまうことがありました。これは第 5 回でそのまま見せます。本番と同じ作りの環境で外から試すことは、まだやっていません。

開発用の環境がない小さなサービスでも、心配は要りません。ソースコードのコピーを中から調べるだけなら、動かす必要がないので、本番にも開発環境にも一切触れません。まずはそこから始めれば十分です。

攻撃をかけすぎないための線引き

二つ目の線引きは、量です。検査の相手がコピーでも、範囲・回数・費用・時間に上限をかけておきます。上限は人が気をつけるのではなく、機械が止めるようにします。人は途中で目を離すからです。

私たちが外から試す検査で使った、攻撃する側のツールを動かすスクリプト（ツールに手順を渡して動かす小さなプログラム）には、次の三つを入れました。

向かってよい相手を一つに決める。 AI がほかの宛先を検査しようとしても、スクリプトが断ります。AI は指示を取り違えることがあるので、「相手はここだけ」とお願いするだけでなく、機械で止めます。
費用の上限を決める。 上限は 2 ドルにしました。実際に使ったのは 0.0331 ドルでした。
手数の上限を決める。 AI が考えて次の手を決める回数を、24 回までにしました。

ほかのツールでも同じです。第 4 回の Strix は、コマンドで費用の上限を 1 ドルにして実行し、実際には 0.45 ドルで止まりました。第 4・5 回で使う StackHawk は、設定ファイルで、サイトの中をたどる時間を 5 分まで、検査の時間を 15 分までにしました。範囲を絞ることも、量の上限の一つです。promptflow には外から触れる入口が 231 本ありますが、最初の検査は、そのうちログインまわりの 4 本に絞りました。

クラウドの「検査のルール」を先に確かめる

三つ目の線引きは、クラウドの事業者のルールです。開発用の環境でも、それがクラウドの上にあるなら、検査の通信はクラウドの事業者の設備を通ります。大きなクラウドの事業者は、利用者が自分のサービスに検査をかけてよい範囲を、あらかじめ決めて公開しています。

AWS のルールのページを見てみます。

一覧にあるサービスなら、事前の承認なしに検査できます。ただし、大量のリクエストでサービスを止めるような検査は、自分のサービスに対してでも禁止です。ログインの入口に何千回も送りつけるような検査は、ここに当たります。量に上限をかける理由は、自分のサービスを守るためだけではなく、クラウドのルールを守るためでもあります。

もう一つ、一覧そのものを確かめることも大事です。promptflow は AWS の Amplify というサービスで配信していますが、2026 年 10 月 23 日の時点で、Amplify はこの一覧に名前がありません。一覧にないサービスを検査したいときは、AWS のサポートに相談するように、と書かれています。つまり、私たちが公開中の環境に外から検査をかけるなら、その前に AWS に相談する必要があります。今回、閉じた環境とコードのコピーで検査したのは、この点でも安全でした。

ほかの大手のクラウドの窓口も挙げておきます。手続きは事業者ごとに違います。

AWS：許可された主なサービスへの検査は、事前の申請なしに行えます。大量の通信で止めるような検査は禁止で、その模擬をしたいときは専用の手続きが要ります（AWS の検査のルール）。
Google Cloud（GCP）：自分のプロジェクトへの検査は、Google への事前の連絡は不要です。ただし、利用規約（Acceptable Use Policy）を守り、ほかの利用者に影響を与えない範囲で行います（GCP のセキュリティに関する FAQ）。
Microsoft Azure：事前の承認も通知も不要です。ただし、事業者が定める「検査の実施ルール（Rules of Engagement）」に従う必要があります（Azure の検査のルール）。

これら以外のクラウドやレンタルサーバを使っている場合は、契約している事業者に「自分のサービスにセキュリティの検査をかけてよいか、事前の連絡や申請が要るか」を必ず確かめてください。黙って強い検査をかけると、遮断されるだけでなく、規約に反する行為として扱われることがあります。

自分のもの以外は、調べない

四つ目の線引きは、第 1 回でも書いたことです。検査していいのは、自分のものだけです。他人のサイトや、自分が権利を持っていないシステムに検査をかけるのは、法律に触れます。

気をつけたいのは、自分のサービスが「つないでいる先」です。決済、メールの配信、ログインの仕組みなど、多くのサービスは外の会社の仕組みにつながっています。自分のサービスから呼んでいるからといって、その先は自分のものではありません。外から試すツールを動かすときは、検査のリクエストが、つないでいる先の会社のサーバにまで飛ばないように、向かってよい相手を一つに決めておきます。さきほどのスクリプトで、相手以外のホストを断るようにしたのは、このためでもあります。

では、つないでいる先の危なさは、どう確かめるのか。相手のサイトを検査するのではなく、自分が使っている部品の一覧と、公開されている弱点の情報を突き合わせます。それが第 7 回の部品の検査と、第 9 回の結果の集め方の話です。

どこで区切るか（費用の話）

最後に、範囲と費用の決め方です。入口が 231 本もあるサービスを、全部まとめて一つずつ深く調べようとすれば、費用も時間もかかります。選べる道は三つあります。

費用のかからない、中を調べる検査を、まず隅々まで。 Trivy・Gitleaks・Semgrep のような AI を使わない検査は、費用がかからないので、コード全体を毎日調べられます。私たちが毎日回している検査は、これです。
範囲を絞って、一か所ずつ深く調べる。 入口を用途ごとに区切り、一つのまとまりずつ AI に深く調べさせれば、少ない費用でも深いところまで届きます。ログインまわりの 4 本に絞った Strix の検査は、0.45 ドルでした。
費用をかけて、深いところまで一度に調べる。 入口が多いサービスを丸ごと深く調べるなら、その分の費用をかけます。

小さなチームなら、一つ目から始めて、二つ目へ進むのが現実的だと思います。一度に完璧を目指さず、まず無料の検査で全体を見て、気になるところから順に AI で深く調べる。1 つのまとまりを深く調べた費用は、私たちの場合 0.45 ドルでした。情報が漏れて、お客さまへのおわびやサービスの停止に追い込まれることを思えば、検査にかける費用は、保険として安いほうだと私は思います。むしろ、検査にいくらかけるかを、はっきり予算として決めておくこと自体が、これからの運営には欠かせません。

始める前に確かめること

ここまでを、始める前の確認の一覧にまとめます。第 4 回から先は、この一覧を満たした状態で進めます。

自分のサービスが、手元や開発環境で、どこのデータベースや保存先につながっているかを、設定ファイルで確かめた。
検査の相手を、本番とは別の環境か、ソースコードのコピーに決めた。
外から試すツールが向かってよい相手を一つに決め、それ以外を機械で断るようにした。
費用・回数・時間の上限を、ツールの設定かコマンドで決めた。
使っているクラウドの検査のルールを読み、自分の使っているサービスが一覧にあるかを確かめた。
検査の相手に、自分のもの以外（つないでいる先の会社のサーバなど）が入っていないことを確かめた。

次回

次回の第 4 回から、手を動かします。外から攻めて検査する、の一回目です。攻撃する側と同じクラスの AI の検査ツールを、自分のサービスのコピーに使います。ツールを入れるところから、安い 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 をご覧ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up