セキュリティ

早期警戒パートナーシップとは?2026年版の届出・公表の流れと開発会社の対応

早期警戒パートナーシップとは?2026年版の届出・公表の流れと開発会社の対応

情報セキュリティ早期警戒パートナーシップは、ソフトウェア製品やウェブサイトの脆弱性を見つけた人の届出をIPAが受け付け、JPCERT/CCが製品開発者と調整したうえでJVNに公表する、2004年から続く官民の枠組みです。2026年10月1日にはガイドラインの第14版が公開され、一定の脆弱性情報を内閣府へ通知する手順と、情報通信研究機構(NICT)との連携が加わりました。この記事では、ガイドライン本文をもとに届出から公表までの流れと日数の目安、第14版での変更点を整理し、通知を受ける側になる製品開発者・ウェブサイト運営者・受託開発会社がどこまで備えればよいかを判断できるようにまとめます。

まとめ:早期警戒パートナーシップの仕組みと2026年10月改訂で変わった点

早期警戒パートナーシップは、脆弱性の情報を「直す人が直し終えるまで外に漏らさず、直したら利用者に届ける」ための取り決めです。窓口はIPAで、ソフトウェア製品の調整はJPCERT/CCが担います。法律上の義務ではなく、経済産業省告示を踏まえた推奨の枠組みです。

日数の目安は2つあります。ソフトウェア製品はJPCERT/CCが製品開発者に最初に連絡を試みた日から45日後の公表、ウェブアプリケーションはIPAからの通知から3か月以内の修正報告です。

第14版の要点は、悪用が確認された脆弱性などをIPAが内閣府へ速やかに通知し、サイバー対処能力強化法に基づいて基幹インフラ事業者や製品開発者へ情報が届く経路ができたことにあります。受託開発会社のうち、パッケージや配布型のソフトを持つ会社は窓口の登録を急ぐべきです。1社専用のシステムだけを作る会社は、窓口の登録より保守契約の通知条項を先に整えれば足ります。

情報セキュリティ早期警戒パートナーシップの定義と告示・7署名機関の関係

制度の正式名称は「情報セキュリティ早期警戒パートナーシップ」で、運用の中身はIPAが公開するガイドラインに書かれています。根拠と担い手を先に押さえます。

経済産業省告示の取扱規程を根拠に2004年7月から続く脆弱性情報の流通の枠組み

IPAのガイドライン公開ページは、この制度を経済産業省告示「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」を踏まえ、脆弱性関連情報を適切に流通させて被害を抑えるための枠組みと説明しています。告示は2004年制定の旧「取扱基準」を置き換える形で2017年に定められ、平成29年経済産業省告示第19号として2024年6月18日に最終改正されました。

IPAは2004年7月から届出の受付を続けており、ガイドラインも2004年7月8日の第1版から改訂を重ねています。2024年6月18日の第13版を経て、2026年10月1日に第14版が発行されました。ここでいう脆弱性には、ソフトウェアの欠陥だけでなく、個人情報が適切なアクセス制御なしに置かれているといった運用上の不備も含まれます。脆弱性そのものの種類や識別の仕組みは脆弱性の種類とCVE・CVSSの仕組みで扱っています。

受付機関IPAと調整機関JPCERT/CC、2026年版で加わったNICTの役割分担

ガイドラインには7つの組織が名を連ねています。2026年版の表紙に載るのは、IPA、JPCERT/CC、電子情報技術産業協会(JEITA)、ソフトウェア協会(SAJ)、情報サービス産業協会(JISA)、日本ネットワークセキュリティ協会(JNSA)、そして今回加わったNICTです。

組織 ガイドライン上の役割 主な相手
IPA 受付機関・公表判定委員会の組織 発見者・ウェブサイト運営者
JPCERT/CC 調整機関・公表日の決定 製品開発者・海外の調整機関
NICT 発見者として助言する際に連携 製品開発者・JPCERT/CC
業界団体4者 署名機関として会員へ周知 製品開発者・SI事業者

実務で連絡を受けるのはIPAかJPCERT/CCのどちらかです。両者の組織としての違いや、インシデント報告の窓口との使い分けはJPCERT/CCの役割とIPAとの違いにまとめました。

法的義務ではない推奨の枠組みと2026年9月末で届出累計20,553件の運用実績

ガイドラインは関係者に「推奨する行為」をまとめた文書で、届出も対応も罰則で強制されるものではありません。それでも件数は積み上がっています。2026年10月22日に公開された2026年第3四半期の届出状況によると、7〜9月の届出はソフトウェア製品179件、ウェブサイト61件の計240件で、受付開始からの累計は20,553件に達しました。

同じ期間にJVNで公表されたソフトウェア製品の脆弱性は79件、修正が完了したウェブサイトは19件です。届出の多くは研究者や一般の利用者によるもので、製品開発者やウェブサイト運営者は、ある日突然「通知を受ける側」になります。

ソフトウェア製品とウェブアプリケーションで分かれる届出から公表までの流れ

ガイドラインの適用範囲は、日本国内で使われているソフトウェア製品と、日本国内から実質的にアクセスされるウェブサイトのウェブアプリケーションで、影響が不特定または多数に及ぶおそれのあるものです。区別が難しいときは、修正が事業者側だけで済むならウェブアプリケーション、利用者側の対応が要るならソフトウェア製品として扱います。

ソフトウェア製品はJPCERT/CC経由で調整し起算日から45日後を目安にJVN公表

ガイドライン2026年版のⅣ章は、ソフトウェア製品の流れを次の順に定めています。

  1. 発見者がIPAに脆弱性関連情報を届け出る(24時間受付、処理は原則営業日)
  2. IPAが受理条件を確かめ、JPCERT/CCへ通知する
  3. JPCERT/CCが関係する製品開発者を特定して連絡する
  4. 製品開発者が脆弱性を検証し、結果をJPCERT/CCへ報告する
  5. JPCERT/CCと製品開発者が公表日を調整し、製品開発者は公表日までに対策方法を作る
  6. IPAとJPCERT/CCがJVNで脆弱性情報と各社の対応状況を公表する

公表日は、JPCERT/CCが製品開発者への連絡を最初に試みた日(起算日)から45日後が目安です。対策の作成に要する期間、海外の調整機関との調整、情報流出のリスク、悪用のリスクの4点を考えて前後します。製品開発者が利用者全員に連絡できると確認できる場合は、JPCERT/CCと調整して公表前に利用者へ知らせることもできます。

ウェブアプリケーションはIPAが運営者へ通知し3か月以内を目処に修正を報告

ウェブアプリケーションの流れは短く、JPCERT/CCは入りません。IPAが届出を受理するとウェブサイト運営者へ直接通知し、運営者が内容を検証して修正します。検証結果と修正した旨のIPAへの連絡は、通知から3か月以内が目処です。

ソフトウェア製品と違い、ウェブアプリケーションの流れには脆弱性情報をJVNで一般に公表する段階がありません。運営者にも積極的に公表する必要はないとされ、修正の報告で取扱いは区切りを迎えます。なお、深刻度がCVSSv3基本値で4.0〜6.9、影響範囲が中で、利用者の操作を待つ受動型の攻撃に限られる場合は、影響が小さいとしてIPAが処理を取りやめることがあります。深刻度の数値の読み方はCVSSv3の計算式とスコアの目安の解説にまとめました。

6か月以上連絡が取れない製品開発者を扱う公表判定委員会と連絡不能案件

製品開発者と連絡がつかない場合にも手順があります。JPCERT/CCがメール・郵便・電話・FAXを試しても応答がなければ「連絡不能開発者」として名前を公表し、6か月以上連絡が取れない、または公表で合意できない案件は「調整不能」としてIPAへ回ります。

IPAは利害関係のない有識者や法律・セキュリティの専門家で公表判定委員会を組織し、製品開発者の意見を聞いたうえで公表の可否を決めます。公表されるのは、調整不能であること、脆弱性の存在が認められること、IPAが公表しなければ知りようのない利用者がいること、公表が適当でない事情がないこと、の4条件をすべて満たすときです。連絡不能開発者として公表された累計は、2026年9月末時点で251件でした。

2026年10月1日公開の第14版で追加された内閣府への通知とNICT連携の中身

第14版の改訂案は、情報システム等の脆弱性情報の取扱いに関する研究会の報告として2026年9月14日に公開されました。変更の中心は新設の付録7です。

付録7が内閣府へ通知する脆弱性は悪用の確認と深刻度・影響範囲の2基準

付録7は、内閣府へ通知する脆弱性を2種類に絞っています。1つは悪用が確認された、または悪用が疑われる脆弱性です。もう1つは一定の深刻度があり、悪用されたときの影響範囲が大きいもので、深刻度はCVSSなどの業界標準の指標で、影響範囲は製品の利用者数や基幹インフラ事業者での利用状況を勘案して評価します。

見落とせないのは、IPAが届出を受理しなかった場合や処理を取りやめた場合でも、この2基準に当たれば内閣府へ通知する点です。また、内閣府への通知の有無や内閣府での対応状況は、発見者が問い合わせても答えられない場合があると明記されました。

内閣府から製品開発者と基幹インフラ事業者へ情報が届くサイバー対処能力強化法の経路

通知を受けた内閣府は、サイバー対処能力強化法に基づいて情報を配ります。付録7が挙げる経路は次のとおりです。

  • 第42条第1項:内閣府やIPAなどの受託法人から製品開発者への情報提供
  • 第38条第1項:関係する国の行政機関への提供。所管省庁は第42条第2項で製品開発者に措置を要請でき、第40条第1項で基幹インフラ事業者に情報を提供できる
  • 第41条:重要電子計算機の利用者への提供
  • 第45条第1項:協議会の構成員への提供

これらの提供は、JVNでの一般公表より前に行われることがあります。受け取った行政機関や事業者は、公表日まで第三者に漏らさないよう管理するとされています。基幹インフラ事業者が負う届出・報告の義務そのものはサイバー対処能力強化法の届出・報告義務と委託先への影響で解説しました。

JPCERT/CCへの直接報告もIPAへ共有される第14版の変更とNICTの位置づけ

第14版はⅣ章4の11)で、JPCERT/CCがIPAを経由せずに発見者から受け取った脆弱性関連情報と発見者の情報を、速やかにIPAへ通知すると定めました。研究会の改訂案の説明では、IPAを経由して内閣府へ通知するための追加とされています。受付の窓口がどちらでも、内閣府への通知の判断はIPAに集まる形です。

NICTは、情報通信研究機構法第14条第1項第7号ロに基づき、自ら見つけた脆弱性について製品開発者に助言や情報提供を行う立場にあります。その際はあらかじめJPCERT/CCへ連絡し、製品開発者の負担が重ならないよう両者で連携すると書かれました。製品開発者から見れば、NICTから連絡が来ても窓口はJPCERT/CCとの調整に集約されるということです。

通知を受ける側の製品開発者・ウェブサイト運営者・システム構築事業者の対応

ガイドラインは発見者向けの手続きとして読まれがちですが、ページ数の多くは通知を受けた側の振る舞いに割かれています。立場ごとに分けて見ます。

製品開発者はJPCERT/CC製品開発者リストへ窓口を登録し45日の公表日を調整

製品開発者に推奨されている最初の行為は、JPCERT/CCとの連絡窓口を設けて事前に届けることです。この窓口がJPCERT/CC製品開発者リストに登録され、名称の掲載を承諾するかどうかも選べます。発見者からの直接の届出を受け付けたい場合は、リストに受付窓口を載せるよう申し出られます。

連絡を受けたあとは、影響を調べて検証結果を報告し、45日の目安を踏まえて公表日を相談します。悪用の事実をつかんだらJPCERT/CCに伝え、公表後は対策方法を利用者に周知します。望ましい公表の手順は別冊の「ソフトウエア製品開発者による脆弱性対策情報の公表マニュアル」が示しており、体制づくりから読むならIPAの製品開発者向けガイドが入口です。

ウェブサイト運営者は委託していても委託元が対応主体になる点と秘密保持契約

付録1は、ウェブサイトの管理を外部の事業者に委託していても、委託元がウェブサイト運営者だと明記しています。IPAからの通知は発注企業に届き、3か月の目処で検証と修正を進めるのも発注企業の責任です。

構築や保守を請けた会社は、発注企業から修正を頼まれる立場になります。ガイドラインは、運営者が修正を依頼する外部機関や管理の委託先には、秘密保持契約を結んだうえで情報を渡すよう推奨しています。修正の過程で原因が汎用のソフトウェア製品にあると分かった場合、その情報も公表まで第三者に出してはいけません。OSSの脆弱性が公表されたあとの社内体制は、署名団体のJISAとJEITAがまとめた「SI事業者における脆弱性関連情報取扱に関する体制と手順整備のためのガイダンス」が扱っています。

脆弱性が原因で個人情報が漏えいした場合にウェブサイト運営者が公表する6項目

ウェブアプリケーションの脆弱性は原則として公表不要ですが、例外があります。その脆弱性が原因で個人情報が漏えいした、または漏えいした可能性がある場合、二次被害を防ぐため次の項目を含めて公表するよう求めています。

  • 個人情報漏えいの概要
  • 漏えいしたと推察される期間
  • 漏えいしたと推察される件数
  • 漏えいしたと推察される個人情報の種類(属性など)
  • 漏えいの原因
  • 問合せ先

この6項目は、個人情報保護法の漏えい報告とは別の、ガイドライン上の推奨です。法令上の報告義務がかかるかどうかは、件数や情報の種類から別途判断する必要があります。

発見者が届け出る前に確認すべき不正アクセス禁止法の線引きと情報非開示依頼

自社のエンジニアが取引先のサイトや使っている製品で脆弱性に気づくことはよくあります。届け出る前に、付録3の法的な論点を確かめておく必要があります。

正規ログイン中の通信観察は抵触しないと推察され番号の総当たりは危うい境界

付録3は、アクセス制御を回避してシステムに入れば不正アクセス禁止法に触れ、サーバーの性能を落とせば業務妨害罪に問われうると述べたうえで、抵触しないと推察される例を3つ挙げています。正規にログインして通常どおり使った際の通信を観察しただけで脆弱性を推定できた場合、入力欄にHTMLタグを含む文字列を入れたらそのまま表示された場合、URL中のページ番号を別の数字に変えて閲覧したら偶然見えてはいけない結果が出た場合です。

最後の例には但し書きがあります。多数の数字列を積極的に変えて試す行為は、制限を免れる目的とみなされる可能性があります。気づいた時点で手を止め、再現手順と画面キャプチャを残して届け出るのが安全です。

受理されても発見者の法的責任は免責されないという注記と1年後の非開示依頼の扱い

IPAは脆弱性関連情報の入手方法に関知せず、届出を受理しても入手手段が合法だと判断したわけではありません。受理によって発見者の法的責任が免責されるわけでもない、とガイドラインは明記しています。

発見者には、正当な理由なく第三者へ開示しないよう「情報非開示依頼」がかかります。ソフトウェア製品の場合、起算日から1年以上たった届出については、発見者がIPAに依頼の取り下げを求めることが可能です。届出はIPAの脆弱性関連情報の届出受付から行い、製品名やURL、確認した環境と手順、製品開発者への氏名通知の可否などを記載します。

受託開発会社が早期警戒パートナーシップに備える範囲と過剰な準備をしない線引き

制度は推奨の枠組みですが、通知は予告なく届きます。受託開発会社の場合、自社が「製品開発者」に当たるかどうかで準備の量が大きく変わります。

パッケージや配布型ソフトを持つ会社は窓口登録と45日で修正を出す手順を今整える

自社名義のパッケージ、複数の顧客に配るプラグインやライブラリ、ソフトウェアを組み込んだ機器を出している会社は、ガイドライン上の製品開発者です。OSSとして公開しているものも含まれます。この場合は、JPCERT/CCへの窓口登録と、通知から45日を目安に検証・修正・公表まで進める社内手順を、通知が来る前に決めておくべきです。

第14版で、悪用が疑われる脆弱性は内閣府経由で基幹インフラ事業者や所管省庁にも届くようになりました。基幹インフラで使われている製品なら、所管省庁から措置を要請される可能性もあります。出荷前の段階で外部の目による検査を済ませておくなら、脆弱性診断・セキュリティ診断をリリース工程に組み込む方法があります。

1社専用のスクラッチ開発だけなら窓口登録より保守契約の通知条項を先に整える

1社のためだけに作る業務システムは汎用性のある製品ではなく、社内でしか使わないものは「不特定または多数」への影響という適用範囲からも外れます。この場合、JPCERT/CCへの窓口登録は過剰です。手間をかけるべきは別の場所にあります。

公開ウェブサイトを請けているなら、IPAからの通知は発注企業に届きます。保守契約に「通知を受けたら何日以内に委託先へ共有するか」「3か月の目処に間に合う修正の段取り」「秘密保持の範囲」の3点を書いておけば、通知が来てから揉めずに済みます。納品物に組み込んだOSSの脆弱性がJVNで公表されたときに追えるよう、部品の一覧を残しておくことも有効で、その作り方はソフトウェアサプライチェーンセキュリティの実装判断で扱いました。

早期警戒パートナーシップについて開発・運用担当者から寄せられやすいよくある質問

脆弱性を見つけた側と通知を受けた側の両方から出やすい質問を5つ選び、2026年10月22日時点のガイドライン第14版と公表資料に沿って答えます。

早期警戒パートナーシップへの届出は義務ですか?

義務ではありません。ガイドラインは経済産業省告示を踏まえて関係者に推奨する行為をまとめたもので、届出をしなくても罰則はありません。ただ、複数の製品開発者に影響しうる脆弱性は、連絡が行き渡らない開発者が出ないようIPAへ届け出ることが望まれると書かれています。製品開発者が直接の届出を受け付けている場合は、開発者へ直接知らせることもできます。

脆弱性の届出先はIPAとJPCERT/CCのどちらですか?

届出先はIPAです。IPAが受付機関、JPCERT/CCが調整機関という分担で、ソフトウェア製品の届出はIPAからJPCERT/CCへ回され、JPCERT/CCが製品開発者と調整します。ウェブサイトの脆弱性はIPAが運営者へ直接通知します。2026年版からは、JPCERT/CCに直接報告された脆弱性もIPAへ共有されることになりました。

届出から公表までどのくらいかかりますか?

ソフトウェア製品は、JPCERT/CCが製品開発者に最初に連絡を試みた日から45日後が公表日の目安です。対策の準備や海外の調整機関との調整に時間がかかれば延び、悪用のリスクが高ければ考慮されます。ウェブサイトの脆弱性にはJVNでの一般公表の段階がなく、運営者が通知から3か月以内を目処に修正してIPAへ報告する流れです。

自社サイトの脆弱性をIPAから通知されたらどうすればよいですか?

まず通知内容を検証し、脆弱性が実在するかと影響の大きさを確かめます。存在すれば修正し、検証結果と修正した旨を通知から3か月以内を目処にIPAへ連絡します。サイトの管理を外部に委託していても対応主体は委託元です。委託先へは秘密保持契約を結んだうえで情報を渡し、修正が終わるまで第三者に漏らさないよう管理してください。

2026年版ガイドラインで何が変わりましたか?

2026年10月1日公開の第14版では、悪用が確認・疑われる脆弱性や、深刻度が高く影響範囲の大きい脆弱性をIPAが内閣府へ通知する付録7が新設されました。サイバー対処能力強化法の施行に合わせた変更です。あわせて、NICTが7番目の署名機関に加わり、JPCERT/CCに直接報告された脆弱性をIPAへ共有する規定も追加されています。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.07.21 テックブログ Apache Tomcatの脆弱性一覧【2026年10月】最新版11.0.27・10.1.61・9.0.123とCVE-2026-59083ほかの影響確認・対応手順
  2. 2026.10.21 テックブログ NEC委託先の不正アクセスとは|顧客システム暗号化・情報漏えいの経緯と委託元が点検する正規アカウント
  3. 2026.10.21 テックブログ ふるさとチョイス不正アクセスで445万件流出:対象確認・パスワード変更と再開時期
  4. 2026.10.22 テックブログ Tomcatバージョン一覧とサポート期限【2026年10月】9.0系は2027年3月末で終了・9.1系と11.0系への移行判断
  5. 2024.07.05 コラム XAMPPの脆弱性とは?危険性とCVE-2024-4577への対策をわかりやすく解説【2026年10月】

RELATED POSTS 関連記事

目次