クラウド環境で複数のチームがサービスを開発・運用していると、どのエンドポイントが認証なしでアクセスできる状態になっているのかを把握し続けるのは容易ではありません。設定ファイル上は保護されているように見えても、実際のネットワークやクラウドアセットの適用状態によって意図しない公開が発生することがあります。
2026年10月19日、カナダのShopifyはエンジニアリングブログにて、自社開発の公開範囲検査ツール「Overexposed（Shopify Engineering）」の仕組みを公表しました。同社が初期の検査方式で直面した限界と、稼働資産を起点としたアプローチへの移行、さらにAIコーディングエージェントを活用した開発においてテストの不備をどう見つけ出したのかは、既存システムの保守やセキュリティ改善を進める上で多くの示唆を含んでいます。
なぜ設定ファイルの確認だけでは公開範囲を見誤るのか
Shopifyが最初に試みたアプローチは、インフラリポジトリ内のKubernetes設定ファイルを読み込み、認証設定のない公開ホスト名を持つIngressを抽出した上で、実際のリクエストを送って確認するというものでした。一見すると実通信も伴っており堅実に見えますが、この初期方式には3つの大きな課題が生じました。
第一に、一部のチームがプロキシ認証設定を直接指定していた場合、スキャナーがその設定を認識できず、本来保護されているアプリケーションを「公開中」と判定してしまう誤検知（False alarms）が発生しました。第二に、クラスタがIngressを受け入れる際に設定を変更するAdmission Controllerの影響です。Admission Controllerはすべてのクラスタで均一に動いているわけではないため、リポジトリ上の記述が正しくてもクラスタ上で効力を発揮していない場合があり、見逃し（Misses）の原因となりました。そして第三に、他のリポジトリや社内プラットフォームツールから作成されたIngressがスキャナーの視野から外れるという死角（Blind spots）です。
リポジトリに保存されたコードは「開発者が意図した設定」を示しているにすぎず、「クラスタ上で実際に強制されている設定」とは乖離することがあります。設定の正しさだけでなく、稼働している実態を直接確認しなければ、公開範囲の正確な判定は行えません。
稼働中の資産から調べる――Cloud Asset Inventoryと匿名アクセスの照合
そこでShopifyは、リポジトリを読む方針を改め、Google Cloudの「Cloud Asset Inventory」から稼働中の資産情報を取得する方式へ切り替えました。このインベントリには、Admission Controllerの処理を経てGKE（Google Kubernetes Engine）に受け入れられたIngressや、Cloud Runサービス、ロードバランサーの情報が含まれています。この切り替えによって、初期のスキャナーが認識していなかったプロジェクト内のCloud Runサービスも検知対象へ追加できるようになりました。
資産一覧を把握した後は、外部の第三者と同じ視点で匿名HTTPリクエストを送信して応答を調べます。検査時はまずHEADリクエストを送り、拒否された場合のみGETを試みる設計です。リダイレクトは自動で追跡せず、転送ごとに接続先を検証しながら最大3回まで追跡し、アイデンティティプロバイダへのリダイレクトや認証チャレンジを伴う401応答であれば保護されていると判断します。一方、Cloud Runの前面にロードバランサーやGoogleのフロントエンドが介在する場合、アプリケーション起動前の404応答は認証の有無を証明しないなど、ステータスコードの意味が構成によって異なる点にも配慮されています。
Overexposedでは、観測された応答を6種類の判定（exposed、expected、protected、not found、unreachable、inconclusive）に分類します。事前の承認リスト（allowlist）の扱いも重要です。ホストとパスが完全一致する承認済みのエンドポイントであっても検査を省略せず、毎回のスキャンで実際にプローブを送信します。匿名アクセスが成功し、承認済みのホストとパスに一致した場合は「expected」と記録されますが、もし認証を要求するようになったり消失したりした場合は、承認リストの更新が必要な候補としてフラグが立てられます。
また、得られた証拠が不完全または矛盾している場合は、安易に安全とみなして「保護されている」と決めつけるのではなく、あえて「inconclusive（判断保留）」として調査対象に残す運用を採用しています。判定理由を残す際も、レスポンス本文や認証情報は含めず、機密情報を保護しながら後から判定理由を追跡できる設計です。さらに、スキャナー自身が悪用されて内部ネットワークへ不正通信を行う事態（SSRF）を防ぐため、DNS解決後のIPアドレス検証などの対策を説明した上で、それだけでは不十分であり、内部サービスやクラウドのメタデータ接続先へのネットワークアクセスも制限する必要があると述べています。
「通るが意図を検証していないテスト」をどう防ぐか
Overexposedの開発プロセスにおいて、ShopifyはAIコーディングエージェントを活用して実装を進め、すべてのプルリクエストに対してAIによるコードレビューを実施しました。これにより迅速に開発を進められたとする一方で、新たなリスクも浮き彫りになりました。それは、「テスト自体はパスするが、本来検査すべき意図を検証できていない」という事態です。
具体例として挙げられているのが、SQLパラメーターの存在を検査するテストです。そのテストはパラメーターが存在することを確認していましたが、背後のクエリが実際にそのパラメーターを使っているかどうかまでは検査していませんでした。テストコード自体は正常終了するため、人間のレビューや通常の自動テスト実行だけでは見落とされやすい欠陥です。
この隙間を埋めるため、Shopifyは防御処理に対する「ミューテーションテスト（mutation testing）」を導入しました。あえて実装した修正コードを外し、その状態でテストを実行します。もし修正を外したにもかかわらずテストが合格してしまうなら、そのテストは機能の正しさを検証できていないと判断できます。さらに、判定種別ごとに既知の期待結果を持つ「canary target」を用意し、判定ルールの変更によって誤判定が生じた場合はテストが失敗する仕組みを構築しました。ルール変更前には過去の保存済みスキャン結果に対して新ルールを再実行し、判定がどう変化するかを比較検証する手法も採られています。
AIにテストを書かせたり改修を行わせたりする現場では、「変更前に失敗すること」をどう定義するかが成否の分かれ目となります。たとえばVercelがv0の画面遷移高速化について解説した記事「Making Navigations Instant in v0（Next.js Blog）」では、エージェントが遅い画面遷移に対してまず失敗するテストを書き、それをパスさせる修正を繰り返すループを回した事例が紹介されています。Next.jsのinstant()ヘルパーを用い、期待する表示がネットワーク待ちで遮られた場合に確実にテストが失敗する条件を整えた設計です。Shopifyのように「修正を外してテストが失敗するかを確かめる手法」と、Vercelのように「変更前に失敗するテストを先に用意する手法」は、いずれもAIが生成したコードやテストが形骸化していないかを機械的に検証する有効なアプローチといえます。
国内の業務システム保守へ応用するための考え方
こうした実践は、国内の企業が自社システムや取引先向けツールを保守・改善する際にも参考になります。たとえば、取引先向けの商品案内（一般公開）と社内向けの受注管理（社員専用）を同一のクラウド基盤上で運用している卸売企業を想定してみましょう。
リポジトリ内の設定ファイルだけで公開状況を判断していると、ステージング環境の設定漏れや、インフラの個別変更による意図しない外部公開を見落とす恐れがあります。まずは実際のクラウドアセット一覧からインターネットに面したサービスを抽出し、どのURLが誰に公開されるべきかを整理することが第一歩となります。
その上で、外部からのアクセス観測を自動化するスクリプトや検査処理を作成する場合、AIツールにコードを書かせるアプローチを試すことも選択肢の一つです。ただし、生成された検査コードやテストが「認証ヘッダーの形式だけを確認して実際のアクセス制御を見ていない」といった形骸化した状態に陥らないよう注意が必要です。認証を意図的に外した検証用エンドポイントを用意してスキャナーが検知できるか試す、あるいは検査コードの防御ロジックを一時的に無効化してテストが正しく失敗するか確認するといった検証手順を組み込むことで、定義した期待結果や意図的に用意した不備を検出できるかを確かめることができます。
業務システムの公開範囲整理とAI活用のご相談について
社内ツールやWebシステムの改修において、稼働中の資産と公開ルールの照合、そしてAIを使った効率的な改修プロセスの導入には、業務実態に合わせた設計が欠かせません。
株式会社デノフでは、コーポレートサイトやECサイト、社内業務システムの設計・開発から公開後の運用保守までを一貫して支援しています。詳しくはデノフのサービス案内に記載している通り、要件整理から現場への定着まで一つの窓口で対応しており、AIを活用した業務改善やツール選定のご相談も承っています。
自社のWebシステムで公開範囲の確認対象をどう整理すべきか迷っている場合や、AIを用いた保守・開発フローに確実なテスト手順を組み込みたいとお考えの際は、お気軽にデノフへの相談窓口までお問い合わせください。現在のシステム構成や運用状況を伺いながら、無理のない進め方を具体化します。
