結城美雪佐藤のメタC、想像以上に厄介だ。仕組みを全部把握しないと動けない。
📖 用語まとめ表
難しい略語ばかりですが、物語を読みながら少しずつイメージしていきましょう。一気に覚えなくて大丈夫です!
| 用語(略語) | 読み方 | 一言説明 | 身近な例え |
|---|---|---|---|
| CSIRT | シーサート | インシデント対応の専門チーム | 学校の「緊急連絡対応チーム」 |
| SOC | ソック | 24時間ログを監視する組織 | マンションの「防犯カメラ監視室」 |
| JPCERT/CC | ジェーピーサート・シーシー | 日本の公的なセキュリティ情報センター | 全国の学校に危険情報を知らせる文科省みたいなもの |
| IPA | アイピーエー | 脆弱性情報や対策を公表する国の機関 | 国の「危険箇所マップ」を作るところ |
| J-CSIP | ジェーシップ | 企業間でサイバー攻撃情報を共有する仕組み | 近所の防犯グループで「最近この手口の泥棒が出た」と共有し合う仕組み |
| CVE | シーブイイー | 脆弱性に付けられる世界共通のID番号 | 薬の「添付文書番号」みたいなもの。同じ番号で世界中が同じ脆弱性を指せる |
| CVSS | シーブイエスエス | 脆弱性の深刻さを0〜10点で評価するスコア | 地震の「震度」。数値が大きいほど危険 |
| NVD | エヌブイディー | CVEをもとに脆弱性情報を集めた米国のデータベース | 世界中の危険薬物を登録したデータベース |
| CWE | シーダブリューイー | 脆弱性の「種類」を分類した共通リスト | 病気の「病名分類表」。CVEが個別の患者番号なら、CWEは病名のカテゴリ |
| JVN | ジェーブイエヌ | 日本語で脆弱性情報を提供するポータルサイト | IPAとJPCERT/CCが共同で作った「日本版NVD」 |
| EPSS | イーピーエスエス | 脆弱性が実際に悪用される確率を予測するスコア | CVSSが「震度」なら、EPSSは「その地域で地震が起きる確率予報」 |
| J-CRAT | ジェークラット | 標的型サイバー攻撃を受けた組織を支援するIPA傘下のチーム | 被災した自治体に専門家チームが駆けつける「災害派遣チーム」 |
| ISAC | アイサック | 業種ごとに脅威情報を共有する組織 | 同じ業界の「防犯情報シェアグループ」 |
| STIX | スティックス | サイバー脅威情報を記述するための標準フォーマット | 「不審者の特徴」を統一書式で書いたマニュアル |
| TAXII | タクシー | STIXで書いた脅威情報をやり取りするプロトコル | 統一書式で書いたマニュアルを「宅配便で送る仕組み」 |
🔍 結城の偵察



佐藤さえいなければ、もっと楽だったのに。
深夜0時を過ぎても、結城の画面は暗くならなかった。
ノートPCに映し出されているのは、メタCのセキュリティ体制に関する公開情報の数々だ。ISMS認証の取得発表、佐藤のセキュリティカンファレンス登壇記録、IPAへのインシデント報告実績——。
「……思ったより、ちゃんとしてる」
結城は小さく舌打ちした。
セキュリティの素人相手に仕掛けるなら、それなりのやり方がある。だがメタCには、インシデント対応の専門組織・CSIRTが整備されている。しかも責任者の佐藤は、前職の大手企業でも実績を積んだ本物のプロだ。
「慎也を孤立させるつもりだったのに……里見だけじゃなく、佐藤まで壁になるの」
結城の指が、キーボードの上で一瞬止まった。
孤立させれば、戻ってくる——そう思っていた。里見との関係を壊し、メタCでの居場所を失わせれば、慎也は誰かを必要とする。そのとき傍にいるのが自分なら、また繋がれる。それが結城の描いていた未来だった。
「慎也は優しいから。ひとりになったら、絶対に私を頼ってくれるはずだった」
だが現実は違う。里見というセキュリティエンジニアの恋人が慎也を守り、佐藤というプロが組織全体で守っている。ひとりにしようとするほど、慎也の周りの防衛網は固くなっていく気がした。
画面の隅に、慎也のSNSアカウントが映る。里見との穏やかなやりとり。笑っている。楽しそうだ。


結城は涙目になりながら・・・。
「私だけは、何も持っていなくても慎也のそばにいられる。それが、私にしかできないことなのに」
「調べれば調べるほど、どこかに隙が見える。組織が大きくなるほど、連携の穴も増えるものだから」
結城はIPAの公開する脆弱性情報のページを開いた。CVSSスコアが高い未対処の項目を、メタCの技術スタックと照らし合わせながら、静かに、しかし確実に、次の手を探し始める。
💬 慎也と里見の会話①



佐藤さんって普段何してるんだろうって思って。
メタC社内のラウンジで、慎也は恋人の隣に座りながらそう切り出した。
「さっき廊下で佐藤さんとすれ違ったんだけど、なんか画面にびっしり英数字が並んでて、すごい真剣な顔してた」
「ああ、あれはたぶんSIEMのダッシュボードかな。ログを監視してるんだよ」
「シーム……? ログって、アクセスの記録みたいな?」
「そうそう。ざっくり言うと、誰がどこから何をしたかを全部記録して、怪しい動きがあればアラートが出る仕組み。佐藤さんはそれを常に見てる」
「えっ、それって24時間ずっと?」
里見は少し笑った。
「さすがに一人じゃないよ。でも、佐藤さんが動いてる組織には、それを可能にする仕組みがある。今日ちょうどそっちの話、教えようと思ってたんだ」
「タイミングよすぎでしょ」
「偶然じゃなくて、慎也が気にしてくれるの待ってたんだよ」
そう言って、里見は軽やかにメモアプリを開いた。
📘 里見の解説「CSIRTからSTIX/TAXIIまで」



組織でセキュリティを守る仕組みを一緒に見ていこう。
CSIRT(シーサート)



まずセキュリティ事故対応の専門チームの話から。
「CSIRT、Computer Security Incident Response Team。直訳すると『コンピューターセキュリティの事故に対応するチーム』だね」
「佐藤さんのチームがまさにそれ?」
「そう。メタCのCSIRTは佐藤さんを含む3名体制。セキュリティ事故が起きたとき——不正アクセスでもマルウェア感染でも——即座に動いて、被害を最小限に抑える役割を担ってる」
「警察みたいなもの?」
「近いね。でも警察は事後対応が中心だけど、CSIRTは予防から対応・再発防止まで全部やる。火が出る前に消防署が点検もしてる、みたいなイメージかな」
SOC(ソック)



SOCってCSIRTと何が違うの?
「次はSOC。Security Operation Center、セキュリティ運用センターって言うんだけど、CSIRTと混同しやすい」
「確かに、どっちも似た感じがする」
「SOCは常時監視が仕事。ログやトラフィックを24時間チェックして、異常を発見したらCSIRTに知らせる『観測所』だよ。対してCSIRTは知らせを受けて動く『緊急部隊』」
「じゃあ、SOCが目で見て、CSIRTが動く感じ?」
「まさに。マンションで言うと、SOCが防犯カメラの監視室で、CSIRTが実際に現場に駆けつけるセキュリティスタッフ」
JPCERT/CC・IPA・J-CRAT



組織の外にも、頼れる情報源があるんだよ。
「ここからは、メタCの外の話。日本には、セキュリティ情報を集めて発信してくれる公的な機関がある」
「どんなところ?」
「JPCERT/CC——Japan Computer Emergency Response Team Coordination Centerって言って、サイバー攻撃の情報収集・分析・注意喚起を行う非営利の組織。あと、IPAはInformation-technology Promotion Agency、情報処理推進機構のこと。国の機関で、脆弱性情報の公開や、ソフトウェアの危険性を教えてくれる」
「つまり、攻撃の情報を全国に知らせてくれる?」
「そう。メタCのCSIRTも、JPCERT/CCやIPAからの情報を日々チェックして、自分たちの組織に関係があればすぐ対策を取る。佐藤さんがよく参照してるのもそのあたりだよ」
「さらに、IPAにはJ-CRAT——サイバーレスキュー隊もある。Cyber Rescue and Advice Team against targeted attackの略で、標的型攻撃を受けた組織に専門家チームが直接出向いて支援してくれる」
「駆けつけてくれるの?」
「そう。被害を受けた組織が自力で対処できないとき、いわば災害派遣みたいな形でプロが来てくれる。企業や地方自治体が申請できる制度だよ」
J-CSIP(ジェーシップ)



企業同士でも情報共有するの?
「J-CSIP(サイバー情報共有イニシアティブ)はIPAが運営していて、サイバー攻撃を受けた企業が情報を匿名で共有する仕組み。Initiative for Cyber Security Information sharing Partnership of Japanの略ね」
「自分がやられた攻撃の情報を他社に教えるってこと?」
「そう。悪いことじゃなくて、同じ手口で他の会社もやられる前に防ぎましょう、っていう連携。近所の防犯グループで『最近この手口の詐欺が多いから気をつけて』って共有するのと同じ発想だよ」
CVE・CVSS・NVD



脆弱性には世界共通のIDとスコアがついてるんだよ。
「ソフトウェアには『脆弱性』——つまりセキュリティ上の弱点が日々見つかるんだけど、それを世界中で同じように管理するための仕組みがある」
「CVEって聞いたことある気がする」
「CVEはCommon Vulnerabilities and Exposures、共通脆弱性識別子。発見された脆弱性ひとつひとつに『CVE-2024-12345』みたいなIDが付く。これがあれば、世界中のどのエンジニアも同じ脆弱性を指して話せる」
「薬の管理番号みたいなもの?」
「いい例えだね。CVEは公式サイト(cve.org)で検索できるから、気になる脆弱性はここで調べるのが一番正確。で、その脆弱性がどれくらい危険かを数値化したのがCVSS——Common Vulnerability Scoring System。0〜10点のスコアで、地震の震度みたいに危険度が一目でわかる。NVDはそのCVSSスコアを含む脆弱性情報のデータベースで、米国NISTが運用してる」
「スコアが高い脆弱性は、早めに対処しないといけない?」
「その通り。だからCSIRTはNVDを常にチェックして、自分たちの使っているソフトに危険なスコアの脆弱性が出たらすぐ動く、という流れになってる。せっかくだから最近の実例を見てみよう」
里見はノートPCの画面を慎也に向けた。
「2025年12月、ReactのServer Componentsっていうウェブ開発の仕組みに重大な脆弱性が発見された。CVE-2025-55182——通称『React2Shell』。
CVSSスコアは10.0満点。これが出た瞬間、世界中のCSIRTが一斉に動いた」
「10点って……最高危険度?」
「そう。認証なし・特別な権限なし・HTTP要求1回で、サーバーを乗っ取れるという内容だった。慎也、フロントエンドでReactを使ってるよね?」
「……使ってる。Next.jsも」
「だから他人事じゃない。さらに同月12日、同じコードに別の脆弱性も見つかった。CVE-2025-55184——こっちはCVSSスコア7.5で、悪意ある特殊なリクエストを送るとサーバーが無限ループに陥ってサービス停止になる攻撃ができる」
「パッチを当てればよかった、ということ?」
「そこが難しいところで、CVE-2025-55182の最初のパッチでは55184を完全に防げなかった。後からCVE-2025-67779という追加修正が出て、さらに対応が必要になった。CVEに番号が付いていることで『次のパッチはどの脆弱性に対応したか』が明確になるから、対応が遅れている部分を追いかけやすい」
慎也は思わず自分のPCを見た。
「今使ってるReactのバージョン、確認しないと……」
「そういう反応が正解だよ」と里見は微笑んだ。「CVSSスコアを見ればどの脆弱性を優先するか判断できる。9.0以上なら最優先、7.0以上なら数日以内、というように運用しているCSIRTが多い」
CWE・JVN・EPSS
あと、CVEと一緒に覚えてほしいのがCWE——Common Weakness Enumeration。CVEが『この脆弱性はCVE-2024-12345』って個別に番号を付けるのに対して、CWEは『バッファオーバーフロー』とか『SQLインジェクション』とか、脆弱性の種類を分類したリストなんだ。病気で言うと、CVEが患者カルテの番号で、CWEが病名の分類表」
「じゃあCVEを調べると、CWEも一緒に書いてある感じ?」
「そう。NVDのエントリーにはCVSSスコアとCWE IDが両方載ってることが多い。どんな種類の弱点か分かると、根本的な対策も立てやすくなる」
「あとJVNも覚えておいて。Japan Vulnerability Notes——IPAとJPCERT/CCが共同で運営している日本語の脆弱性情報ポータル。NVDは英語だけど、JVNは日本語で読めるし、国内製品の脆弱性情報も載ってる。実務ではjvn.jpを最初に見るエンジニアも多い」
「そして、CVSSだけじゃ判断しきれない場面に使うのがEPSS——Exploit Prediction Scoring System。CVSSが『この脆弱性はどれだけ危険か』の深刻度なのに対して、EPSSは『この脆弱性が実際に攻撃に使われる確率』を0〜1で予測するスコアなんだ」
「確率? CVSSだけじゃダメなの?」
「CVSSスコアが高くても、実際の攻撃ツールがなければすぐには悪用されにくい。逆にCVSSが中程度でも、攻撃コードが出回っていれば危険度は跳ね上がる。EPSSを組み合わせると、本当に今すぐ対処すべき脆弱性が絞り込みやすくなる」
ISAC・STIX・TAXII



ISACって、企業同士の情報共有グループ?
「ISACはInformation Sharing and Analysis Center。業種ごとに作られた脅威情報の共有組織で、金融業界のFS-ISACとか、航空業界のA-ISACとかがある。メタCが属するIT・通信系にも対応するISACがある」
「J-CSIPと似てる?」
「J-CSIPはIPAが運営する国内の仕組みで、ISACは業界単位でのグローバルな枠組みだね。ただ共有する、という発想は同じ。そして、共有する情報を書くための標準フォーマットがSTIX——Structured Threat Information eXpression。攻撃者の特徴や手口を統一書式で記録できる」
「その情報を送るための仕組みが……」
「TAXIIだね、Trusted Automated eXchange of Indicator Information。STIXで書いた脅威情報をリアルタイムに組織間でやり取りするプロトコル。STIXが『書式』で、TAXIIが『配送システム』というイメージ」
「じゃあ、JPCERT→ISAC→各企業のCSIRT、みたいな情報の流れがある?」
「そう。たとえばアメリカのCISA——国土安全保障省傘下のセキュリティ機関——はAIS(Automated Indicator Sharing)っていう仕組みを運営していて、TAXIIサーバーを使って参加機関に脅威情報を自動配信してる」
「あ、さっきNVDのAPIでJSONが返ってきてたじゃないですか。あれがSTIXフォーマットってこと?」
里見は少し首を振った。
「そこ、混同しやすいんだけど——NVDのJSONとSTIXは別物だよ」
「え、違うの?」
「NVDのAPIが返すのはNVD独自のフォーマット。こういう構造ね」
{
"vulnerabilities": [
{
"cve": {
"id": "CVE-2025-55182",
"descriptions": [{ "lang": "en", "value": "..." }],
"metrics": {
"cvssMetricV31": [{ "cvssData": { "baseScore": 10.0 } }]
}
}
}
]
}
「vulnerabilities とか cvssMetricV31 とか、NVDが独自に決めたキー名で構成されてる。CVSSスコアを調べたいときはNVDが便利だけど、これはあくまでNVDの検索APIの形式」
「じゃあSTIXは?」
「STIXは組織間で脅威情報を共有するための標準言語。同じCVE-2025-55182をSTIX形式で書くとこうなる」
{
"type": "vulnerability",
"spec_version": "2.1",
"name": "CVE-2025-55182",
"external_references": [
{ "source_name": "cve", "external_id": "CVE-2025-55182" }
]
}
「type: "vulnerability" というSTIX標準のオブジェクト型が使われてて、CVE IDは external_references の中に入る。見た目は似てるJSONでも、キー名も構造も全然違う」
「なるほど……同じJSONでも用途が違うのか」
「そう。NVDは『脆弱性情報を検索・参照するDB』、STIXは『組織間で脅威情報をやり取りする共通言語』。実務では、NVDから取得した情報をMISPやOpenCTIみたいなプラットフォームがSTIXに変換して、TAXIIで配信する、という流れが多い」
「つまり、NVD → 変換 → STIX → TAXII → 各CSIRTへ、という流れ?」
「まさに。で、そのSTIXの中に攻撃の指標情報——IOC(Indicator of Compromise)——が含まれる場合もある。React2Shellで言うと、攻撃に使われるURLパターンをSTIXのindicatorオブジェクトで書いてTAXII配信するとこういう形になる(STIX 2.1 仕様)」
{
"type": "indicator",
"spec_version": "2.1",
"name": "CVE-2025-55182 React RCE",
"pattern": "[url:value = '/ssr/manifest.json']",
"pattern_type": "stix",
"pattern_version": "2.1",
"valid_from": "2025-12-03T00:00:00Z",
"labels": ["malicious-activity"]
}
「これを受け取ったSOCは、監視ルールに自動で追加できる。人手なし、リアルタイムで」
「人が手動でメールを共有するより、全然速い……」
「そこがポイント。STIXとTAXIIがあれば、世界中のCSIRTが脅威情報を自動交換できる。React2Shellは公表から数時間以内に世界中のアラートルールに組み込まれた。NVDとSTIX、それぞれの役割が噛み合って、初めて機能する仕組みなんだよ」
里見は目を細めて頷いた。
「セキュリティって個人が頑張るだけじゃなくて、組織同士が繋がって守る仕組みが支えてるんだよね」
⚡ 攻撃の影



NVDに出てる新着CVEと、うちの構成が気になる。
その夜、佐藤のモニターにアラートが入った。
メタCが利用しているオープンソースのライブラリに、CVSSスコア8.1の脆弱性が報告されたという通知だった。情報源はJPCERT/CCの速報。NVDにもすでにエントリーが上がっている。
「タイミングが少し早い……」
佐藤は眉を寄せた。脆弱性情報が公開されると、攻撃者はすぐにそれを悪用しようとする。パッチが出る前の短い空白期間を突くのが常套手段だ。
佐藤はすぐにSOCへ連絡を入れ、該当ライブラリを使っているサービスへのアクセスログを重点監視するよう指示した。同時にISACの情報共有チャネルを確認すると、同業他社でも同じライブラリへの不審なアクセスが確認されていた。



偶然じゃない。誰かが公開情報をもとに動いている。
「SOCとCSIRTの連携を強化します。里見さん、一時的にパッチ適用の優先度を最上位に変更してください」
🛡️ チームの対応



脆弱性が出たら、情報→判断→対処の流れで動く。
翌朝、里見から慎也にメッセージが届いた。
「昨夜ちょっとバタついてたんだ。パッチ対応、急ぎで進めた。もう落ち着いたよ」
詳しく聞くと、NVDに登録されたばかりの脆弱性情報を、佐藤がJPCERT/CCの速報で即座にキャッチ。ISACの情報共有でも同じ脆弱性が複数社で標的になっていることが確認され、SOCがログ監視を強化する中でCSIRTが緊急パッチ適用を判断・実施したという流れだった。
「攻撃が本格化する前に対処できた、ってこと?」
「そう。CVSSスコアが8.1だったから、すぐ動けた。あのスコアがなかったら優先度の判断が遅れてたかもしれない」



情報→判断→対処。その流れを支える仕組みが全部繋がってた。
慎也は今日里見から聞いた話を思い返した。JPCERT/CCがあり、CVEで脆弱性が識別され、CVSSで危険度が判断できる。ISACが情報を共有し、SOCが監視し、CSIRTが動く。点だと思っていた用語が、ひとつの防衛ラインとして繋がった。
「佐藤さんのチームって、本当にすごいんだな」
「当たり前だよ。でも慎也が仕組みを理解してくれてるだけで、私は嬉しい」
💬 慎也と里見の会話②



組織で守るって、一人のヒーローじゃなくて連携なんだよね。
帰り道、ふたりは並んで歩いていた。
「今日の話、正直最初は略語が多すぎてついていけるか不安だったんだ。CSIRT、SOC、JPCERT/CC……全部バラバラに見えてた」
「今は?」
「なんか、繋がってる気がした。外から情報が来て、中で監視して、事故が起きたら対応チームが動く。そういう流れ全体がセキュリティなんだって」
里見はすこし嬉しそうに笑った。
「そう、まさに。一人の天才がいれば守れる、じゃないんだよ。バラバラに動いてる組織が情報を共有して、連携するから守れる。STIXとTAXIIみたいな共通言語が必要なのも、そのためだし」
「佐藤さんが『個人でできることには限界がある、組織で守るんです』って言ってた意味が、今日初めてわかった気がする」
「その言葉、もう何度も言ってるよね、あの人」
「聞くのと理解するのは違うんだよな、ってちょっと反省した」
里見が慎也の肩にそっともたれた。
「わかってくれるなら、十分だよ。ゆっくり覚えていこう」
夕暮れの帰り道、ふたりの足音が重なった。
😤 結城の悔しがり



情報が全部繋がってる……予想以上に厄介だ。
CVSSスコア8.1の脆弱性が公開されてから、メタCがパッチを当てるまでにかかった時間は——12時間以下だった。
結城はその事実を確認して、キーボードを叩く手を止めた。
「……JPCERT/CCの速報をリアルタイムで拾って、即日対処……」
公開された脆弱性情報を利用して、パッチ適用前の隙を突こうとしていた。だが佐藤のチームの動きが速すぎた。NVDでスコアを確認した結城が動く前に、すでに対応が完了していた。
「ISACの情報共有まで使ってる。他社の被害情報が即座に届く仕組みがある、ということか」
STIXとTAXII——脅威情報の書式と配送。慎也たちが守られているのは、彼ら個人の力だけじゃない。世界規模の情報網が、メタCを包んでいる。
「……焦って動くより、もっと深いところに手を入れる必要がある」
結城はノートに何かを書きつけた。その横で、慎也のSNSに新しい投稿が上がる。里見と並んだ夕暮れの写真だった。
幸せそうな笑顔。
「……まだ、終わってない」





コメント