PSIRTは Product Security Incident Response Team の略で、「ピーサート」と読みます。FIRST（Forum of Incident Response and Security Teams）の公式文書は、こう定義しています。

ここで大事なのは「組織が開発・販売する」という部分です。自社が世に出したものが対象——だから、出していない会社には要りません。逆に言えば、出しているなら業種を問わず該当します。

整理は筆者によるものです。「有償か無償か」「主力事業かどうか」は関係ありません。利用者がいる限り、脆弱性が出れば連絡する相手がいます。

PSIRTは「独立した特殊部隊」ではありません

名前の響きから、専門家を集めた別動隊を想像しがちです。FIRSTはそれを明確に否定しています。

第1章 おわり — 次は第2章

この違いは、FIRST自身の経緯がいちばん雄弁です。

1つの文書で書こうとしたら、書けなかった——それくらい別物だということです。違いの核心も明記されています。

当サイトで扱ってきた3つの体制を並べると、こうなります。

整理は筆者によるものです。詳しくは SOCとは？ と CSIRTとは？ をご覧ください。

4行目の時間軸が、実務ではいちばん効きます。CSIRTの仕事は「今起きている事故を止める」ことなので、時間との勝負です。PSIRTの仕事は、報告を受けて、再現して、修正版を作って、テストして、利用者に配って、公表を調整する——数週間から数か月かかります。同じ人が兼任すると、火事のたびに製品対応が止まります。

第2章 おわり — 次は第3章

FIRSTのフレームワークは「サービスエリア → サービス → 機能 → サブ機能」という4階層で書かれています。いちばん上の6つが、PSIRTの仕事の全体像です。

FIRST『PSIRT Services Framework Version 1.1 日本語版』のサービスエリア構成より。日本語版はSoftware ISAC（一般社団法人コンピュータソフトウェア協会）とJPCERT/CCが翻訳し、KONICA MINOLTA PSIRT・Mitsubishi Electric PSIRT・Panasonic PSIRTがレビューしています。

この6つを見て、「うちには無理だ」と思わないでください。フレームワークは「ガイドであり、さまざまな組織モデル、機能、サービス、達成すべき成果を提示している」もので、「チームは自由に独自のモデルを実装し、ステークホルダ固有のニーズを満たす機能を構築できる」と明記されています。

そして注目すべきは1番と5番です。技術的な作業（2〜4番）ではなく、「誰に伝えるか」と「いつ公表するか」がフレームワークの両端を占めています。これは、CSIRTの記事で見た「技術力よりコミュニケーション能力」という話と同じ構図です。

第3章 おわり — 次は第4章

CSIRTの記事で、JPCERT/CCが「CSIRTに『規格』はないのです」と書いていることを紹介しました。PSIRTでも、FIRSTがまったく同じことを言っています。

同 PSIRTの組織構造 より。分散モデルの課題として挙げられている「PSIRTに報告を行わない可能性がある」は、実務でよく見られる問題です。

分散モデルのPSIRTが担う役割として挙げられているものが、PSIRTの本質をよく表しています。

同 分散モデル より抜粋。「自分で直す」役割が1つも入っていないことに注目してください。

第4章 おわり — 次は第5章

日本では、脆弱性の発見者がいきなり製品開発者に連絡するとは限りません。公的な取扱制度があります。

IPA『情報セキュリティ早期警戒パートナーシップガイドライン』のページおよびIPA四半期報告より。

制度が動いている規模は、四半期ごとに公表されています。2026年第2四半期（4〜6月）時点の数字です。

IPA『ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期］』より。累計は2026年第1四半期に2万件を超えました。

この表から読み取れることが2つあります。

「取扱い中」は、IPA・JPCERT/CCが内容確認中のもの、または製品開発者が調査・対応中のものを指します。

そしてもう1つ、PSIRTを持つ側にとって重い数字があります。

第5章 おわり — 次は第6章

脆弱性が見つかった。調整機関が製品開発者に連絡しようとした。ところが、連絡が取れない。

このとき、制度は止まりません。制度は前に進みます。IPAの四半期報告が、その手順を明記しています。

段階を分けて読むと、こうなります。

同資料の記述を段階に整理したものです。公表判定委員会は「法律、サイバーセキュリティ、当該ソフトウェア製品分野の専門的な知識や経験を有する専門家、かつ、当該案件と利害関係のない者」で構成されるとされています。

実際にどれくらい起きているのか。数字が公表されています。

同資料 1-3 および 2-1-5 より。一覧はJVNのサイトで誰でも閲覧できます（jvn.jp/reply/）。当四半期の新規公表が0件だったことは、制度が落ち着いてきていることを示しますが、198件が現在も「連絡が取れない状態」で公表され続けているという事実は変わりません。

窓口が無いと起きる、もう1つのこと

制度の外でも問題が起きます。発見者が、報告する先を見つけられないときの行動です。

整理は筆者によるものです。2行目を防ぐことが、窓口を置く最大の理由です。

第6章 おわり — 次は第7章

第3章の6つのサービスエリアを全部やろうとすると、動き出せません。順番があります。いちばん外側——外から来た報告が届く道——から作ります。

順序は筆者によるものです。5について、IPAの報告書は「JPCERT/CCは、ソフトウェア製品の脆弱性関連情報を『製品開発者リスト』に基づき、一般公表日の調整等を行います。迅速な調整が進められるよう、『製品開発者リスト』に登録してください」と案内しています。

1〜2は今日できます。費用もかかりません。そして、この2つだけで第6章の4段階に入るリスクの大部分が消えます。

売る側の責任は、制度の側でも重くなっています

この分野は、いま動いています。2026年7月31日に決定された『重要インフラのサイバーセキュリティ対策のための統一基準』（2026年10月1日施行）は、システムベンダー、セキュリティベンダー、プラットフォームベンダー、クラウド事業者を「サイバー空間関連事業者」として位置づけ、責任ある行動を求めています。

また『重要インフラのサイバーセキュリティに係る行動計画』は「セキュリティ・バイ・デザイン」の推進を掲げ、「サイバーセキュリティを業務、製品・サービス等のシステムの企画・設計段階から確保する『セキュリティ・バイ・デザイン』の実装が必須となっている」としています。

これは第1章で見たFIRSTの考え方——PSIRTはSDLに統合されるもの——と、まったく同じ方向です。製品を出す側は、出したあとだけでなく、作る前から問われるようになっています。ソフトウェアの中身を管理する仕組みは SBOM、優先度の付け方は CVSS と KEVカタログ にまとめています。

第7章 おわり — 次は第8章

第8章 おわり — 最後にFAQ