投稿者 投稿日: カテゴリー ChatGPT
GPT-6 Astraとは、OpenAIが2026年9月に公開した最上位のAIモデルのことです。
2026年9月、OpenAIはGPT-6 Astraの公開にあわせて、既知の脆弱性を実際に動く攻撃コードに変えられるかを測る評価「ExploitBench」で、安全策を外した状態のスコアが100%に達したと開示しました。前世代のGPT-5.6 Solは78.5%でしたから、攻撃側の作業を肩代わりできる水準が一段上がったことになります。ECサイトを運営する側から見ると、この数字は「攻撃者の手間が減る」という警報であると同時に、「自社サイトの弱点探しをAIに手伝わせられる」という道具の話でもあります。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、カート・会員情報・決済連携を抱えるEC事業者が、GPT-6 Astraを防御側の脆弱性チェックに使うための手順を、プロンプト6本とあわせて整理します。
ExploitBench 100%が意味するものと、EC事業者に関係する理由
ExploitBench 100%が意味するのは、公開済みの脆弱性について「穴の場所と修正パッチが分かっている状態」から攻撃コードを組み立てる作業を、GPT-6 Astraがほぼ確実にこなせるということです。ExploitBenchとは、既知の脆弱性と修正前後のプログラム、デバッグ用ツールを渡し、実際に動作する攻撃コードを作れるかを測る評価のことです。InfoWorldによると、より広い攻撃コード開発を測るExploitGymではAstraが42.4%、GPT-5.6 Solが30.3%でした。公開前3か月以内に開示された脆弱性を使ったテストでは、未知の脆弱性（ゼロデイ）を2件見つけて関係ベンダーに開示したとも報じられています。
数字の読み方には注意が要ります。ソフトウェアサプライチェーンのセキュリティ企業Socketの分析では、ExploitBenchはブラウザのJavaScriptエンジンV8の既知脆弱性について、パッチや修正前後のバイナリまで与えたうえで、1件あたり5回の試行のうち成功したものを集計する設計だと指摘されています。つまり「どんなサイトでもゼロから攻略できる」という意味ではありません。OpenAI自身も、直近3か月に開示された新しい脆弱性だけに絞った評価ではAstraが39.0%、Solが11.5%だったと示しています。満点の数字を額面どおりに受け取らず、「既知の穴を突くスピードが上がった」と理解するのが実務的です。
OpenAIはAstraを、同社の安全評価の枠組みであるPreparedness Frameworkでサイバーセキュリティの「Critical」水準を初めて超えたモデルと位置づけました。そのため一般向けのAstraは、攻撃用の概念実証コード（PoC）の生成など高度な攻撃タスクを拒否する設定で提供されています。検証済みの防御側組織向けには「OpenAI Daybreak」というプログラムを用意し、段階的に制限を緩める方針です。EC事業者が使うのは当然この防御側の用途で、攻撃コードを書かせることではありません。
では、なぜEC事業者に関係するのか。理由は、日本のECサイトの多くが既知の脆弱性を抱えたまま運用されているからです。カート、会員登録、問い合わせフォーム、管理画面、決済代行との連携モジュールなど、ECサイトは攻撃の入口が多い構造をしています。WordPressにEC系プラグインを組み合わせた構成や、数年前に構築したまま改修していないパッケージ型のカートでは、ベンダーが修正版を出していても適用されていないケースが珍しくありません。現場で繰り返し見るのは、「パッチは出ているが、適用すると表示が崩れるかもしれないので後回し」という判断が半年以上続いている状態です。
攻撃側のAIが既知の穴を短時間で突けるようになると、この「後回し」のコストが跳ね上がります。日本では日本クレジット協会のクレジットカード・セキュリティガイドラインが6.0版でEC加盟店のシステムとWebサイトの脆弱性対策、不正ログイン対策、EMV 3-Dセキュアの導入を指針に加え、現在は6.1版が最新として掲載されています。カード情報の漏えいが起きれば、個人情報保護法にもとづく個人情報保護委員会への報告と本人への通知が必要になり、決済代行会社からの取引停止や調査費用も発生します。攻撃と防御の両方でAIの性能が上がった今、脆弱性への反応速度そのものが店舗の経営リスクを左右する段階に入ったと判断します。
防御側でGPT-6 Astraに任せられる仕事と任せられない仕事
GPT-6 Astraに任せられるのは「情報を読み解き、優先順位を付け、修正方針を下書きする」仕事です。逆に、本番環境に対する攻撃的なテストや、修正の最終判断は人と専門事業者に残します。この線引きを先に決めておくと、社内で使い始めるときの混乱がほとんどなくなります。
任せやすい仕事の1つ目は、構成の棚卸しです。ECサイトがどのカートシステム、どのプラグイン、どのバージョンで動いているかを一覧にし、サポート終了やセキュリティ告知の有無を整理する作業は、資料さえ渡せばAIが得意とする分野です。2つ目は、脆弱性情報のトリアージです。JVN（日本の脆弱性対策情報ポータル）やベンダーの告知文を読み、自社の構成に影響があるか、どれから直すべきかを判定する作業も、根拠を示させれば精度の高い下書きが出てきます。3つ目は、自社で書いたコードの防御的なレビューです。決済代行への連携処理、会員ログイン、検索フォーム、管理画面のアップロード機能など、入力値の扱いを誤りやすい箇所を重点的に読ませると、人のレビューで見落としがちな点が浮かび上がります。
任せてはいけない仕事もはっきりしています。第一に、他社のサイトや、許可を得ていないシステムへの調査です。日本では不正アクセス禁止法があり、自社のつもりでも委託先が管理するサーバーへ無断で検査をかければ問題になり得ます。第二に、本番環境への直接の負荷試験や攻撃的な検査です。これは検証環境（ステージング）を用意し、契約にもとづいて専門の脆弱性診断事業者に依頼する領域です。第三に、修正の採否を決めることです。AIの指摘には誤検知が混ざるため、最終判断は開発担当者か委託先のエンジニアが行います。
ここで日本の公的な基準と組み合わせると、点検の網羅性が上がります。IPAのECサイト構築・運用セキュリティガイドラインは、中小企業の経営者と実務担当者を対象に、要件1から要件14までの対策要件と、Excel形式の構築時・運用時チェックリストを公開しています。SaaS型のカートを使う場合も対象に含まれているため、Shopifyやfutureshop、makeshopのようなサービスを使う店舗にも当てはまる項目が多いはずです。チェックリストの各項目をAIに読ませ、自社の現状と照らし合わせて「充足・不足・確認不能」に仕分けさせる使い方が、最初の一歩としては最も効果が見えやすいでしょう。
既存のうるチカラ記事でも、Astra公開時の論点はGPT-6 Astra公開とタスク単価57%減の3論点で、隠し命令による乗っ取りリスクはAIエージェントのプロンプトインジェクション対策で整理しています。セキュリティ用途に使う前に、AIそのものが攻撃の対象になり得る点もあわせて押さえておいてください。
ECサイトの脆弱性チェックを内製化する手順とプロンプト6本
内製化の手順は、棚卸し、情報収集、優先順位付け、コードと設定の点検、委託先との連携、有事の備えの6段階で進めます。以下のプロンプト6本は、GPT-6 Astraを想定して作っていますが、ChatGPT、Claude、Geminiのいずれでも使えます。機密情報を扱うため、API利用時のデータ保持設定や、ChatGPT Business・Enterpriseなど業務向けプランの管理設定を確認してから使ってください。
最初は構成の棚卸しです。カート、CMS、プラグイン、外部サービスの一覧を作り、サポート状況とリスクの見立てを出させます。
プロンプト1：ECサイト構成の棚卸しとリスク整理
あなたはECサイトの運用セキュリティに詳しいエンジニアです。
以下は当社ECサイトの構成情報です。防御目的の点検として整理してください。
構成情報：
- カートシステム／CMS：{名称とバージョン}
- 追加プラグイン・アプリ：{名称とバージョンの一覧}
- サーバー・ホスティング：{種類}
- 決済代行・外部連携：{サービス名と連携方式}
- 管理画面のURL公開範囲：{IP制限の有無など}
出力してほしいこと：
1. 構成要素ごとに「サポート状況（継続中／終了／不明）」と、その根拠として確認すべき公式情報の種類
2. 攻撃の入口になりやすい箇所の上位5つと、その理由
3. 情報が足りず判断できない項目の一覧（推測で埋めないこと）
出力は箇条書きではなく、要素ごとの短い段落で書いてください。
次に、届いた脆弱性情報が自社に関係するかを判定します。告知文を貼り付け、影響の有無と対応の緊急度を根拠つきで出させます。
プロンプト2：脆弱性告知の自社影響トリアージ
以下の脆弱性情報が、当社ECサイトに影響するかを判定してください。
脆弱性情報（告知文をそのまま貼り付け）：
{JVNやベンダー告知の本文}
当社の構成：
{プロンプト1で整理した構成情報}
判定ルール：
1. 影響あり／影響なし／判断不能 のいずれかで結論を最初に書く
2. 結論の根拠として、告知文のどの記述と当社構成のどの要素が一致・不一致かを示す
3. 影響ありの場合、緊急度を「72時間以内」「2週間以内」「次回定期更新」の3段階で提案する
4. 緊急度を上げる要因（会員情報・決済に関わる、ログイン不要で悪用可能など）を明記する
5. 判断不能の場合は、追加で確認すべき情報を列挙する
攻撃手順や攻撃コードは出力しないでください。
3本目は、自社で書いたコードの防御的なレビューです。対象は決済連携、ログイン、フォーム、ファイルアップロードなど入力値を扱う処理に絞ると精度が上がります。
プロンプト3：決済・会員まわりの防御的コードレビュー
あなたはWebアプリケーションのセキュアコーディングに詳しいレビュアーです。
以下は当社ECサイトの{機能名：例 決済代行への連携処理}のソースコードです。
防御側のコードレビューとして、修正すべき点を指摘してください。
観点：
1. 入力値の検証とエスケープ（SQLインジェクション、クロスサイトスクリプティング）
2. 認証・セッション管理（ログイン試行回数制限、セッション固定）
3. 決済結果の改ざん対策（金額・注文番号のサーバー側検証）
4. 秘密情報の扱い（APIキーのハードコード、ログへのカード情報出力）
5. エラーメッセージからの情報漏えい
出力形式：
- 指摘ごとに「該当行」「問題の内容」「想定される影響」「修正方針の例」を短い段落で
- 確信度を高・中・低で添える（低は誤検知の可能性がある旨を明記）
- 攻撃の再現手順は書かない
ソースコード：
{コード}
4本目は、管理画面と会員ログインの設定点検です。IPAのチェックリストの該当項目を貼り付け、現状の設定と突き合わせます。
プロンプト4：IPAチェックリストとの突き合わせ
以下は、IPA「ECサイト構築・運用セキュリティガイドライン」付録チェックリストの一部と、当社の現状設定です。
各項目を「充足」「不足」「確認不能」に仕分けてください。
チェックリスト項目：
{該当項目を貼り付け}
当社の現状：
- 管理画面の2要素認証：{有無}
- 管理者アカウント数と共有の有無：{内容}
- 会員ログインの試行回数制限：{内容}
- 管理画面へのアクセス元制限：{内容}
- バックアップの頻度と保管場所：{内容}
出力：
1. 不足項目を優先度順に並べ、それぞれ「誰が」「何を」「いつまでに」の形で対応案を1文で
2. 確認不能項目は、誰に何を聞けば確認できるかを書く
5本目は、制作会社や保守委託先への確認です。自社だけで判断できない項目を、委託先に送る質問文に変換します。
プロンプト5：委託先への確認質問リスト作成
当社ECサイトの保守を委託している{委託先の種類：例 制作会社}に、セキュリティ対応状況を確認したいです。
以下の不足・確認不能項目をもとに、委託先に送る確認メールの本文を作成してください。
項目：
{プロンプト4で出た不足・確認不能項目}
条件：
1. 責任を問う口調ではなく、現状把握のための確認として書く
2. 質問は番号付きで、各質問に「はい／いいえ／未対応」で答えられる形にする
3. 回答期限の提案と、回答が難しい項目は打ち合わせで確認したい旨を添える
4. ですます調、400〜600字
最後は有事への備えです。漏えいが疑われたときに慌てないよう、初動の社内連絡と、外部への報告に必要な情報の整理を事前に下書きしておきます。
プロンプト6：情報漏えい疑い時の初動手順の下書き
当社はEC事業者で、{取扱情報：例 会員情報、配送先、カード決済は決済代行のリンク型}を扱っています。
カード情報や個人情報の漏えいが疑われたときの初動手順書を下書きしてください。
含めること：
1. 発覚から24時間以内にやること（社内連絡の順番、証拠保全、決済代行会社への連絡）
2. 個人情報保護委員会への報告と本人通知が必要かを判断するために集める情報
3. 顧客向け告知文の骨子（事実、原因の調査状況、問い合わせ窓口）
4. 外部の専門事業者（フォレンジック調査会社など）に依頼する判断基準
注意：法的判断が必要な箇所は「弁護士・専門家に確認」と明記し、断定しないこと。
6本を一度に回す必要はありません。プロンプト1と2を月1回の定例作業にし、プロンプト3は改修のたびに、4と5は半年に1回、6は年1回の見直しという頻度が、少人数の店舗でも続けやすい配分です。
失敗しやすい使い方と回避策
最も多い失敗は、AIの「問題なし」を安全の証明として扱ってしまうことです。AIのレビューは見つけた問題を挙げるのは得意ですが、見つからなかったことが安全の根拠にはなりません。直近の支援案件で観測したのは、AIに一度コードを読ませて指摘ゼロだったため、外部の脆弱性診断を取りやめてしまったケースでした。回避策は、AIの点検を「専門診断の前の下ごしらえ」と位置づけ、年1回の外部診断やカート事業者の診断サービスと併用することです。
2つ目の失敗は、ソースコードや設定ファイルをそのまま貼り付けて、APIキーやデータベースのパスワードまでAIに渡してしまうことです。業務向けプランやデータを保持しない設定（OpenAIの対象API顧客向けZero Data Retentionなど）を使っていても、秘密情報を外部サービスに送らないのが原則です。貼り付ける前に、キーやパスワードを「{APIキー}」のような置き換え文字に差し替える手順を、作業ルールとして明文化しておきます。
3つ目は、指摘をすべて同じ重さで扱ってしまい、本当に急ぐべき修正が埋もれることです。AIは確信度の低い指摘も並べるため、20件、30件と指摘が出ると担当者が手を付けられなくなります。プロンプト2とプロンプト3で緊急度と確信度を必ず出させ、「会員情報・決済に関わり、ログインなしで悪用できるもの」から着手するというルールを先に決めておくと、修正の順番で迷わなくなります。
4つ目は、AIへの依頼文が攻撃手順の作成と受け取られ、拒否される、あるいは利用規約に触れるおそれがある書き方をしてしまうことです。一般向けのAstraは攻撃的なタスクを拒否する設定で提供されています。依頼文には「防御側の点検として」「攻撃コードは出力しない」と明記し、対象を自社の資産に限定する一文を入れておくのが安全です。
KPI設計と費用・工数の目安
追うべきKPIは、脆弱性への反応速度と、点検の網羅率の2系統です。反応速度の指標としては、脆弱性告知を把握してから自社への影響を判定するまでの日数と、影響ありと判定してから修正を本番に反映するまでの日数を記録します。店舗運営の現場感覚では、専任担当のいない中小規模のECで前者に1〜2週間かかることが多く、プロンプト2を定例化すると2〜3日に縮められる見込みです（目安であり、構成の複雑さで変わります）。
網羅率の指標としては、IPAチェックリストの充足率、管理画面アカウントの2要素認証適用率、サポート終了ソフトウェアの残存数を追います。2要素認証の適用率は100%を目標にし、例外を認める場合は理由と期限を記録します。サポート終了ソフトウェアは、ゼロにするまでの移行計画を四半期ごとに更新するのが現実的です。
費用は、APIで使う場合と、チャットサービスで使う場合で考え方が変わります。InfoWorldの報道では、GPT-6 AstraのAPI料金は入力100万トークンあたり10米ドル、出力100万トークンあたり50米ドルです。たとえば決済連携まわりのコード一式を入力20万トークン、レビュー結果を出力2万トークンとすると、1回あたり入力2米ドルと出力1米ドルで約3米ドルの計算になります。月2回のレビューとプロンプト1・2の定例作業を合わせても、多くの店舗では月数十米ドルの範囲に収まる見込みです。チャットサービスで使う場合はChatGPTのPlus、Pro、Business、Enterpriseが対象プランとして案内されましたが、プランごとの利用上限や新規受付の状況は変わることがあるため、契約前に公式の最新情報を確認してください。
工数の目安は、初回の棚卸しとIPAチェックリストの突き合わせで合計1〜2日、その後の定例作業は月2〜4時間程度です。外部の脆弱性診断の費用はサイト規模と診断範囲で大きく変わるため一概には言えませんが、AIで事前に棚卸しと既知の問題の修正を済ませておくと、診断の範囲を絞り込みやすくなり、見積もりの比較もしやすくなります。
今後の展望と、EC事業者が押さえておくべき視点
今後は、攻撃側のAI活用が当たり前になる前提で、ECサイトの運用設計を組み直す必要があります。OpenAIは後継のGPT-6.1 Astraについて、欺瞞的な振る舞いへの懸念から公開を見送ったと報じられており、詳細はGPT-6.1 Astra公開中止の3論点で整理しています。フロンティアモデルの提供範囲は今後も安全性評価に応じて揺れ動くと考えられ、特定のモデルに点検体制を依存させない設計が望ましいでしょう。プロンプト6本をChatGPT、Claude、Geminiのいずれでも動く形にしているのはそのためです。
2つ目の視点は、SaaS型カートへの移行判断です。パッケージ型や自社開発のカートは自由度が高い反面、脆弱性への反応速度を自社で担保しなければなりません。攻撃が速くなるほど、セキュリティ更新をサービス側が一括で行うSaaS型の価値は上がります。移行には費用と手間がかかるため、今回の棚卸しで出たサポート終了ソフトウェアの数と修正の滞留日数を、移行判断の材料として経営層に示すのが筋のよい進め方です。
3つ目は、AIエージェントが店舗業務に入り込むことで、守る対象そのものが広がる点です。受注処理や在庫連携をAIエージェントに任せると、エージェントが持つ権限やAPIキーが新しい攻撃の入口になります。脆弱性チェックの対象に、ECサイトの画面やコードだけでなく、AIエージェントに渡している権限の一覧も加えておくべきです。5,000社支援の中で何度も再現したパターンとして、新しい仕組みを入れた直後に権限の棚卸しが抜け落ちることが挙げられます。AIの導入とセキュリティ点検は、同じ会議体で扱うのが安全です。
よくある質問
GPT-6 AstraのExploitBench 100%は、ECサイトがすぐに攻撃されるという意味ですか
いいえ、そういう意味ではありません。ExploitBenchは修正パッチや修正前後のプログラムまで与えたうえで攻撃コードを作れるかを測る評価で、一般向けのAstraは攻撃的なタスクを拒否する設定です。ただし既知の脆弱性を突く速度が上がる方向性は確かなので、パッチの適用を後回しにする運用は見直すべきです。
中小規模のEC事業者でもAIで脆弱性チェックができますか
はい、できます。構成の棚卸しや脆弱性告知の影響判定、IPAチェックリストとの突き合わせは、専門知識が浅くてもプロンプトで進められる作業です。コードのレビューや本番環境の検査は、制作会社や脆弱性診断事業者と分担してください。
ShopifyなどSaaS型カートを使っていても点検は必要ですか
はい、必要です。SaaS型ではサービス本体の更新は事業者側が担いますが、追加アプリの権限、管理画面アカウントの2要素認証、スタッフアカウントの棚卸し、テーマの改修部分は店舗側の責任範囲に残ります。IPAのガイドラインもSaaS型の利用を対象に含めています。
ChatGPT・Claude・Geminiのどれを使えばよいですか
いずれでも構いません。本記事のプロンプトはどのサービスでも動く形で書いています。重要なのはモデルの選択よりも、業務向けプランでのデータ保持設定と、秘密情報を貼り付けない運用ルールを先に整えることです。
AIに自社サイトへ検査をかけさせても違法になりませんか
自社が管理権限を持つ環境を、正当な権限にもとづいて点検する分には一般に問題になりにくいと考えられます。ただしサーバーやシステムを委託先が管理している場合は、事前に委託先の了承と契約上の確認が必要です。他社のサイトに無断で検査をかけることは不正アクセス禁止法に触れるおそれがあるため、判断に迷う場合は弁護士など専門家に確認してください。
カード情報を保持していなければ脆弱性対策は不要ですか
いいえ、不要にはなりません。カード情報を保持しない構成でも、決済画面への遷移を改ざんされて偽の入力画面に誘導される被害や、会員情報・配送先情報の漏えいは起こり得ます。日本クレジット協会のガイドラインでもEC加盟店のWebサイトの脆弱性対策と不正ログイン対策が求められています。
まとめ
GPT-6 AstraがExploitBenchで100%を記録したことは、既知の脆弱性を突く作業がAIによって速くなる時代に入ったことを示しています。EC事業者がとるべき対応は、恐れることではなく、同じAIを防御側の点検に使い、脆弱性への反応速度を上げることです。まずはプロンプト1で自社サイトの構成を棚卸しし、プロンプト2で直近の脆弱性告知を判定するところから始めてください。そのうえでIPAのチェックリストと突き合わせ、自社で判断できない項目は委託先と専門事業者に任せる。この役割分担ができれば、専任のセキュリティ担当がいない店舗でも、点検を定例業務として回せるようになります。
参考文献
- InfoWorld: OpenAI launches GPT-6 Astra, its first model to cross a critical cybersecurity threshold
- Socket: GPT-6 Astra Attempts Supply Chain Attacks Against Open Source Maintainers in Testing
- OpenAI: GPT-6 Astra
- IPA: ECサイト構築・運用セキュリティガイドライン
- 日本クレジット協会: クレジットカード・セキュリティガイドライン関連資料
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
