AIを悪用した攻撃への備え｜委託先に確認したい管理画面・APIの公開範囲

2026年10月、JPCERT/CCとNICTが、国内で相次ぐ不正アクセスについて注意喚起を出しました。その中で、攻撃者がAIを用いて脆弱性の探索や攻撃を試みていたことも報告されています。

Webシステムやアプリの開発・運用を外部に任せている企業では、発注側の担当者が自分で点検するわけにはいきません。委託元として確かめておきたいのは、管理画面やAPIを「誰に使わせるつもりか」と「実際にどこから届くか」、技術担当が行った点検の対象と対象外、確認日、根拠、そしてまだ残っている事項です。

この記事は、その確認を技術担当や委託先へ依頼する情シス・発注側の担当者に向けたものです。攻撃の再現方法や診断の手順は扱いません。また、ここで扱うのは攻撃者によるAIの悪用で、委託先が業務で生成AIを使うときの入力情報の管理とは別の話です。

不正アクセスや情報漏えいが疑われる状況であれば、この記事の確認や回答の回収を待たず、すぐに技術・セキュリティ担当へ連絡してください。

公的機関が報告しているのは「AIを使った探索や攻撃の試行が確認された」という事実です。相次ぐ漏えいがすべてAIによるものだ、という説明ではありません。

• 10月8日公開・10月23日更新：JPCERT/CCは確認された攻撃手法を類型ごとに示し、23日の更新で、AIを用いたペネトレーションテスト基盤を悪用した攻撃の試行を加えました（JPCERT/CC注意喚起 JPCERT-AT-2026-0030）。この試行では、主にインターネットに公開されたWebアプリケーションが標的とされていたことが確認されています。一方で注意喚起は、従業員向けの管理システムやBIツールなど、不特定多数の利用を想定していないシステムが被害に遭う例もあるとして、点検を呼びかけています。すべての事案で同じ手法が使われたとは示していません
• 10月13日：NICTは、公開されているAndroidアプリを解析して裏側のサーバーを狙う攻撃（A2B）に注意を促しました（NICT CYNEX 注意喚起）。アプリ自体に問題がなくても、サーバー側の認証・認可や入力値の検証に不備があれば被害につながるおそれがあり、AIの活用で解析や脆弱性探索が進めやすくなり、攻撃がより多くのシステムに及ぶ可能性にも注意を促しています
• 10月15日（日本語版）：JPCERT/CCは公式ブログで、攻撃者がAIを利用して既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことを、攻撃元サーバーの調査で確認したと説明しています（JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」）。AIの利用割合や、攻撃全体に対する効果は示されていません

委託元としては、外から届く管理画面やAPIが技術担当の点検対象に入っているかを確かめる理由になります。技術的な対策の詳細は、一次資料と技術担当に委ねてください。

「公開されていますか」と一言で聞くと、聞く側と答える側で指す内容がずれます。次の4つに分けて聞くと、回答の食い違いに気づきやすくなります。

先に言葉をそろえておきます。管理画面は、システムの設定変更やデータの管理を行うための画面で、社員や委託先の運用担当が使うものです。APIは、アプリとサーバー、あるいはシステム同士がデータをやり取りする窓口です。外部のAIサービスのAPIに限らず、自社のスマホアプリや取引先システムとの連携のために用意したものも含みます。

1. 想定する利用者：誰に使わせるつもりで作ったか（一般の顧客、社員、委託先の運用担当、連携先のシステムなど）
2. 到達できる範囲：インターネットのどこからでも届くのか、社内ネットワークや特定の接続元からだけか
3. 認証：利用者が誰かを確かめる仕組み
4. 認可：確かめた利用者に、どのデータ・どの操作を許すか

この4つは別々の状態です。インターネットから届くAPIが、それだけで問題になるわけではありません。公開を前提に設計されたAPIも多くあります。反対に、ログイン画面がある、接続元を制限している、URLを公表していない、といった条件のどれか一つだけで安全とは判断できません。JPCERT/CCのブログは、アプリ内の工夫に頼らず、サーバー側で利用者と操作権限を確かめるよう呼びかけています。

到達範囲や設定の実態を確かめる作業は、承認された範囲で技術担当が行います。委託元の担当者が、承認や技術的な準備なしに外部からアクセスを試すことは避けてください。

確認は、対象システムを一つに絞ってから始めます。次の6項目を、回答と根拠の組み合わせで聞きます。選定から契約終了までの委託先管理の全体の流れは、情報セキュリティ委託先管理とは？必要性から実務の進め方までで説明しています。ここでは管理画面・APIの公開範囲と点検状況に絞ります。

確認対象	回答で確かめること	根拠、または未確認のときの次の行動
1. 対象システム	対象の環境（本番・検証など）と、管理画面・APIの一覧を誰が把握しているか	一覧や構成資料の保管先と更新日。一覧がなければ作成の担当と期限を決める
2. 意図と実態	想定する利用者を明確にし、実際に到達できる範囲が、業務上必要とする公開範囲に合っているか	技術担当が確かめた日・対象環境・到達範囲の確認結果。「設定済み」の申告だけなら、確認した範囲と結果の概要も聞く
3. 認証と認可	利用者の確認と、許可するデータ・操作の確認を、それぞれ点検したか	点検の実施者、方法の概要、対象。手順そのものは求めない
4. 点検の範囲	管理画面だけかAPIも含むか、本番・検証・旧版のどれか、ログインの前後どこまでか	点検報告の概要（対象・実施日・対象外）
5. 侵害の確認	ログなどで不審なアクセスを確認したか、いつ・どの範囲か	確認の日付と範囲。「見つからなかった」と「侵害がない」は分けて残す
6. 残る事項	未確認・契約の対象外・対応中を区別しているか	対応の担当、次の行動、完了予定日（未定なら予定を決める期限）、再確認の方法

この表は編集部が作成した設計例です。公的機関が定めた必須項目でも、安全性を判定する票でもありません。すべての委託先に全項目の資料提出を求めるものではなく、対象システムに合わせて項目を選んでください。

表の外で補っておきたい点が3つあります。

まず、4と5は別の作業です。脆弱性の点検は弱点を探す作業で、侵害の確認はすでに入り込まれていないかを調べる作業です。片方を実施したことは、もう片方の実施を意味しません。JPCERT/CCの注意喚起も、示された送信元からのアクセスの有無を確認するよう呼びかけています。

次に、質問票に集めない情報があります。パスワード、APIキー、秘密鍵、脆弱性の詳細そのもの、機微な構成情報は書かせないでください。必要なのは報告の概要、対象を特定するID、資料の保管先です。共有の範囲が決まっていない段階では、生の資料の提出も求めません。

最後に、一般的な運用の目安として、IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」には、通信を許可する範囲の把握、クラウドなどサービス提供元との責任範囲の把握、定期的な脆弱性診断や監査が含まれています。2019年に更新された一般的な資料で、今回の攻撃に合わせた基準ではありません。

回答にどこまで証跡を求めるかは、セキュリティチェックは自己申告だけでいい？証跡や追加確認をどこまで求めるかで詳しく扱っています。

「点検済み」という回答は、委託先が点検を実施したと説明している状態です。報告の概要などで、実施日と対象・対象外を確かめ、今回確認したい範囲と一致しているかを見ます。

たとえば、次のような場面です（編集上の架空例で、特定の企業やツールの画面ではありません）。会員向けWebサービスの運用を委託している企業が、委託先から「9月に脆弱性診断を実施済み」という回答を受け取りました。報告の概要を見ると、対象は本番環境の管理画面だけで、スマホアプリが使うAPIと、ログイン後の権限の確認は対象外でした。

この時点の記録は、次のように短く残せば足ります。

項目	内容
確認できたことと根拠	本番の管理画面を9月に診断（報告概要の対象・実施日の欄）
未確認	アプリ向けAPI、ログイン後の権限、検証環境
次の担当	委託先の技術責任者が点検範囲の追加案を出し、委託元の情シスが判断する
期限	社内で定めた追加案の提示期限を記入

この例で、診断が不十分だったと決めつける必要はありません。当初の目的に合った範囲だった可能性もあります。残しておくのは、未確認の範囲を誰がいつまでに決めるかです。記録は適否や安全性を判定するためのものではありません。

IPAは、委託先への調査結果に応じて追加質問や証跡の提出を依頼し、懸念がある場合は経営者へ報告して組織としての方針を検討する実践例を紹介しています（IPA「プラクティス9-1 サイバーセキュリティリスクのある委託先の特定と対策状況の確認」）。法令上の義務ではなく、進め方の一例です。

点検を行うのは技術担当や委託先の技術者です。委託元が担うのは、回答と点検の対象・根拠を対応付け、残った事項の行き先を決めることです。対象が少なければ、Excelとメールでも十分に回せます。委託先やシステムが増え、誰が未回答か、どの回答を差し戻したかを追いにくくなってきたら、仕組みを見直す時期です。

マモリスは、繰り返し発生するチェックシート業務（作成・依頼・回収・確認・差し戻し・証跡保管）を扱うサービスです。脆弱性の検出、公開されている管理画面やAPIの発見、攻撃の検知や防御、侵害の判定は行いません。扱えるのは、ここまでの確認を依頼し、回答と根拠を確かめて記録する部分です。

• 設問をマモリス上で作成する（選択式、テキスト、ファイル添付、URLなどの形式）
• 回答者はログイン不要で回答でき、回答状況の一覧で未回答を把握できる。期限前のリマインドメールの自動送信や一括催促も使える
• 回答を確認し、不足があればコメントを残して差し戻す。回答・確認・差し戻しの履歴を残せる

複数の委託先への依頼・回収の進め方は、チェックシートの回収管理｜依頼前の準備から確認完了まで、管理表の記入例で詳しく説明しています。

最初は、連絡先が分かっている委託先1社と対象システム1つを選び、「外部から届く管理画面・APIの範囲」「点検の実施日と対象外」「未確認の事項と次の担当」の3問ほどで、依頼から回答確認まで試すと進め方を決めやすくなります。試す場合は、マモリスの無料登録から始められます。

Q1. インターネットに公開されたAPIがあると危険ですか。

公開していること自体は問題ではありません。確かめたいのは、実際に到達できる範囲が業務上必要とする公開範囲に合っているか、想定する利用者に応じた認証・認可の設計と実装が点検されているか、そのAPIが点検の対象に入っているかです。

Q2. ログインしないと使えない管理画面なら安心ですか。

ログインは利用者を確かめる仕組みの一部です。ログイン後にどのデータ・操作を許すか（認可）は別に点検が必要です。また、JPCERT/CCは業務上不要な管理機能がインターネットに公開されていれば公開を停止するよう呼びかけています。外部から届く必要があるかも、あわせて確認してください。

Q3. 委託先の「診断済み」という報告があれば十分ですか。

報告の対象・実施日・対象外が、今回確かめたい範囲と一致しているかを見てください。一致していれば回答の根拠になります。脆弱性の点検と侵害の確認は別の作業なので、侵害の有無を確かめたかは別に聞きます。

Q4. マモリスで脆弱性や不正アクセスを検出できますか。

できません。マモリスで扱えるのは、技術担当や委託先へ確認を依頼し、回答と根拠を確かめて記録する運用です。点検や調査は技術担当や委託先の技術者が行います。

• JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（JPCERT-AT-2026-0030、2026年10月8日公開、10月23日更新）
• JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」（日本語版 2026年10月15日）
• NICT CYNEX「相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」（2026年10月13日）
• IPA「安全なウェブサイトの運用管理に向けての20ヶ条」（最終更新 2019年3月6日）
• IPA「プラクティス9-1 サイバーセキュリティリスクのある委託先の特定と対策状況の確認」（2026年4月28日）