「IT・セキュリティ企業だから安全」は成立しない：GMOの事例から考える企業統治とシステム設計

Posted at 2026-11-03

すべてのエンジニア(だけに留まらない)多くの企業に該当する「事故防止・トラブル対応時の報告フロー」が結論です。

2026年11月3日時点の公開資料と、技術者としての読み方に基づく考察です。GMOグループやGMOサイバーセキュリティ byイエラエの実績は認めつつ、「個別の技術力」と「グループ全体の統制」は分けて考えています。事故原因や個人の責任は、公開されていない内部記録を推測して断定していません。

はじめに

「GMOは日本のインターネットを作ったとまで言えるのか？」
「インターネットセキュリティといえばGMO、という印象はあるのか？」
この二つのXでの問いから話は始まった。
問いへの結論を先に書く。

GMOを「日本のインターネットを作った企業」と呼ぶのは言い過ぎだ。ただ、「日本のインターネットを大衆化・商業化した主要企業の一つ」なら、十分に言える。

もう一つ。グループ内にセキュリティで成果を出している会社があることと、「グループ全体が安全である」ことは同じではない。
この差を追っていくと、セキュリティの要は製品や技術そのものより、報告・意思決定・裁量・責任・是正をつなぐ「企業の設計」にある、という話になる。

1. GMOは本当に「日本のインターネットを作った」のか

1-1. 技術的な創成と、商用サービスの普及は別物

日本のインターネットの技術的な起源を辿ると、GMOより前の取り組みに行き着く。

時期	主な出来事	役割
1984年	JUNET開始。東京大学・東京工業大学・慶應義塾大学の研究ネットワーク	日本のネットワーク研究と文化の原点
1988年	WIDEプロジェクト開始。村井純氏らが参加	TCP/IPを用いた広域ネットワーク技術の研究・実証
1992年	IIJ設立。同時期に商用ISPが登場	商用接続サービス・インターネット運用の先駆け
1995年	GMOの前身「interQ ORIGINAL」開始	接続手続きの簡素化と利用の裾野拡大

出典：JPNICの沿革、JPドメインに関する主な出来事、GMOの旧会社沿革。

つまり、日本のインターネットの技術的な創成期にGMOが中心だった、という歴史ではない。

1-2. では、GMOは何をしたのか

① インターネット接続のハードルを下げた（1995年）

「interQ ORIGINAL」は、事前の会員契約なしで使える接続サービスを展開した。当時、手続きの面倒さを減らした意味は大きい。GMOの沿革では1995年12月開始とされている。

② ドメイン登録を大衆化した（1999年～）

前身企業が1999年にICANN認定レジストラとなり、ドメイン登録を始めた。個人や中小企業が独自ドメインを持つときの価格・手続きの敷居を下げた。

③ Webサイト運営の敷居を下げた

ドメイン、ホスティング、サーバー、認証、セキュリティをグループとして広く提供し、専門インフラ技術者がいなくてもサイトを公開しやすい環境の普及を後押しした。ただし、傘下企業が買収前に積み上げた成果を、最初からGMO本体の独自成果とみなすのは適切ではない。

新しいインターネット技術を発明した、というより、既存の技術を安く・簡単に商用サービスとして使えるようにした。ここに事業としての功績がある。

1-3. 先駆者との比較

企業・組織	特に大きな貢献	役割の整理
JUNET・WIDE・村井純氏ら	ネットワーク技術・研究基盤	日本のネットワークの創成
IIJなど初期のISP	商用接続・ネットワーク運用	商用インフラの先駆者
NTT系	回線・アクセス網の整備	物理的な普及基盤
GMO	接続・ドメイン・ホスティングの簡便化、価格競争	商業化・利用促進
Yahoo! JAPANなど	検索・ポータル・一般利用者向けサービス	利用文化の普及

※筆者による役割分類であり、企業の客観的な順位ではない。

「GMOがなければ日本のインターネットは存在しなかった」には根拠が薄い。一方、「GMOがなければ、ドメイン取得やWebサイト開設の普及速度や価格競争は違っていたかもしれない」なら、筋は通る。

発明家というより、インターネットを誰もが使える商材に変えた事業家集団。この言い方・表現が一番しっくりくると考える。

2. 「インターネットセキュリティといえばGMO」というキャッチコピーは妥当か

2-1. 技術的実績はある。が、ブランドの主張とは別

「インターネットセキュリティといえばGMO」には、かなり違和感がある。

ただし、グループ内にセキュリティ分野の実績があるのも事実だ。

分野	関係事業・実績	評価上の留意点
SSL/TLS証明書	GMOグローバルサイン（GlobalSign）	証明書市場の実績と、セキュリティ市場全体の順位は別
脆弱性診断・ペネトレーションテスト	GMOサイバーセキュリティ byイエラエ	高度な攻撃者視点の技術を持つ
電子署名・認証	GMOサイン、GlobalSign	認証サービスの提供実績がある
SOC・EDR・継続監視	関連ソリューションの展開	業界全体での優位性は比較データが必要
グループ全体の安全管理	2026年の不正アクセス事案	技術的な事業実績とは別に統制を見るべき

GlobalSignはグループ入り前から事業があり、イエラエも2022年にグループ入りした。買収で得た専門性と、GMO本体が歴史的に育てた専門性は混ぜて考えない方がよいと考えている。

「ネットのセキュリティもGMO」というプロジェクトの公表は2025年2月6日。包括的なブランド訴求としては比較的新しい。従来の市場イメージとずれていても、それ自体は不自然ではないように見受けられる。

出典：GMO「ネットのセキュリティもGMO」発表、同プロジェクトの紹介。

2-2. イエラエの技術成果はどこまで裏付けできるか

公正に見れば、イエラエには一流と言ってよい技術成果がある。しかもCTF優勝だけではない。

実績	内容	注意点
171件	2021～2024年に報告した未知の脆弱性（同社公表）	CVEの報告日・件数に基づく同社集計
3連覇	DEF CON Cloud Village CTF、2023～2025年	DEF CON全体のCTF総合順位ではなく部門別大会
世界2位	Automotive CTF 2024 グローバル決勝	当該大会の成績
8万米ドル超	Linuxカーネル脆弱性の報告に対するGoogle kernelCTF報奨金	特定の研究成果に対する報奨金

出典：GMOの171件報告、GMOのCTF実績、Cloud Village CTFの3連覇解説、Linux脆弱性発見の発表。

2021～2024年の新規脆弱性報告件数

合計171件。同社発表の数値であり、CVE件数だけでは深刻度・発見難易度・再現性・競合との優劣までは分からない。

Linuxカーネルに19年近く潜伏した脆弱性

2026年、イエラエの研究者がCVE-2026-43456の詳細を公表した。

項目	公表内容
対象	Linuxカーネル
問題の原因	2007年に導入されたコードに由来するtype confusion
影響	条件を満たす環境での権限昇格
PoCの成功率	研究者の検証では99%以上、1秒以内
報奨金	Google kernelCTFで8万米ドル超
留意点	攻撃条件に`CAP_NET_ADMIN`が関係。すべてのLinux環境で無条件に権限昇格できるわけではない

出典：ScanNetSecurityの研究者解説、GMOの発表。

競技成績より実務的な説得力がある。実際のソフトウェアの安全性向上に結びつく成果だからだ。

2-3. それでも「グループ全体が一流」とは言えないのではないか

評価対象	筆者の評価
高度な脆弱性探索能力	一流と言える成果がある
CTF競技能力	世界トップクラスの競技実績がある
脆弱性研究の成果	明確で検証可能な成果がある
顧客向け診断サービスの品質	比較可能な公開データが不足
SOC・継続的な防御運用	一流と認定する根拠が不足
GMOグループ全体のセキュリティ統制	別に評価する必要がある。今回の問題は看過できない

見るべきは、検出漏れ率、診断の再現性、是正支援の実効性、検知・対応時間、比較可能な競合データなどだ。

「イエラエには高度な脆弱性探索の専門家がいる」は言える。しかし「ネットのセキュリティといえばGMO」というグループ全体の主張までは、それだけでは正当化できない。

3. 不正アクセス事案が示す、技術力と組織統制の分離

2026年11月2日の会見では、GMOインターネットが提供する「お名前.com デスクトップクラウド」への不正アクセスについて、顧客情報の流出と資産被害が説明された。グループ会社のイエラエによる事前の指摘を運営に生かせなかったことも認められた。

報道によれば、2024年4月24日にイエラエがシステムの課題・改善点を指摘。その後の対応は十分でなく、同一環境への追跡診断も実施されなかったという。経営トップまで報告が届かず、エスカレーション基準が存在しなかったことも会見で説明された。

出典：ITmedia NEWS（11月2日）、ITmedia NEWS（11月3日）、＠ITによる会見詳報。

※公開された事実関係を整理するための概念図。個々の侵入経路や因果関係を独自に確定したものではない。

開発・品質保証の視点から見ると、ここは痛い。

脆弱性診断は実施した
専門家は問題を検出した
運営側は問題を認識していた
しかし、抜本的な是正は完了しなかった
結果として、顧客に実害が出た

脆弱性を見つける能力と、見つかった脆弱性をリスクとしてとらえ、確実に直す組織能力は、まったく別だ。

検出プロセスが動いていても、リスク管理のクローズドループが閉じていなければ、防御は完結しないと筆者は考える。

なお、個別の管理職や役員がどの時点で何を判断したかを断定するには、当時の意思決定記録・権限分担・リスク受容記録が必要になると考えている。

4. 「これを導入したから安全」とは言えない

ここからはGMOに限らない、企業セキュリティの話をしたい。

セキュリティは完成品ではなく、継続的な制御活動だと筆者は考える。

脆弱性は次々見つかる。構成変更、新しい攻撃技術、人的ミス、依存関係、外部サービスで、昨日成り立っていた前提は今日変わる。

暗号アルゴリズムやアクセス制御の一部には、前提とモデルを限定した数学的・形式的保証を与えられる場合（≒数理的制御）もある。ただ、企業システム全体には人・外部サービス・変更・未知の脆弱性が入る。数理的な保証がある部分と、組織全体の絶対安全性は同じではない。

セキュリティ製品の導入は対策の開始であって、完了ではない。

4-1. 対外公表にもトレードオフがある

脆弱性修正の公表やパッチ公開から、攻撃者が差分を解析し、未修正環境への攻撃方法を類推できる場合がある。「公表すれば終わり」でも「隠せば安全」でもないと筆者は考える。

選択肢	利点	残るリスク
早期公表	利用者が防御・更新を始められる	攻撃者にも手掛かりを与える可能性
公表を遅らせる	修正準備・調整の時間を確保できる場合がある	利用者が危険を知らず運用する可能性
パッチ配布	適用環境の既知リスクを軽減できる	未適用環境や副作用が残る

ゼロリスクの選択肢がないからこそ、専門家の技術評価、経営者の受容判断、利用者への説明、継続的な再評価をつなぐ必要があると筆者は認識している。

5. 世界標準も「技術」だけでなく「統治」を見ている

NIST Cybersecurity Framework（CSF）2.0は、2024年の改訂でGovern（統治）を明示し、6機能の体系になった。

※統治の役割を強調した概念図で、NIST原図の完全な再現ではない。6機能は本来、相互に関連し並行・継続的に取り組むもの。

出典：NIST CSF 2.0 FAQ。

日本でも、IPAが参照するJUASの「企業IT動向調査報告書2022」に、経営層の関与に関する数字がある。

回答区分	割合
重要性は認識しているが、主にIT部門などに任せ、経営会議で議論されない	50.9%
経営課題として認識し、重大な対策等を経営会議で審議・決定する	38.6%
重要性を認識しておらず、ほとんど会話がない	10.4%

出典：IPA「情報セキュリティ白書2023」第2章、図2-4-5（JUAS調査、n=1,123）。端数処理により合計は100%と一致しない。調査時点の結果であり、日本企業の2026年最新割合ではない。

重要性は分かっていても、経営の意思決定につながっていないケースがある。これだけで「日本だけが特別に悪い」とは言えないと考えている。同じ条件の国際比較が必要だと。

日本固有というより世界共通のガバナンス問題で、日本企業の組織文化によって深刻化しやすい可能性がある、くらいに見ておくのが妥当だろうと筆者は考察する。

6. 真の問題は「報連相不足」だけではない

重視したいのはここだ。

役割	よくある問題	本来必要な仕組み
技術担当者	報告した時点で仕事が完了	再現性、影響範囲、是正確認
管理職	予算・納期を優先して先送り	対応期限と未対応理由の記録
CISO	責任はあっても停止権限が弱い	独立した報告経路と緊急権限
経営層	詳細を知らないまま承認	重大リスクの明示的な受容判断
監査部門	手順書や記録の有無を確認するだけ	実際に問題が解決されたかを検証

最悪なのは、「報告した」「検討した」「承認した」という形式上の手続きだけが終わり、リスクそのものは残り続ける状態だ。

報連相があることと、問題が解決することは違う。

現場に改善責任を押し付けながら、予算・人員・稼働停止・リリース延期の裁量を与えない組織は、構造的に問題を解けない。

これはサイバーセキュリティに限らない。品質保証、製品事故、労働安全、法令遵守でも同じ構造が出る。

技術者がリスクを評価し、権限を持つ者が根拠と責任を伴って決め、その判断を継続的に見直す。この循環が要る。

6-1. KPIは「事故ゼロ」だけでよいのか

セキュリティの成熟度を「攻撃を何件防いだか」だけで測るのは無理があると考えている。

むしろ見たいのは次のような指標だ。

重大リスクの発見から責任者への到達時間
リスク評価から是正方針決定までの時間
是正期限を超過した重大リスクの件数と滞留期間
リスク受容を誰が、何を根拠に、いつまで認めたか
是正後の再検証と再発防止策の実施率

事故件数がゼロでも重大リスクが放置されている企業は健全とは言えない。逆に、問題報告が多い組織は、発見・報告の文化が機能している可能性もある。

セキュリティの真価は、「問題がないことではなく、問題を見つけたときに組織がどう動くか」に出る。

これは事故やトラブルへの対応と全く同じ基準と筆者は考える。

7. これはシステム設計と同じ構造だ

ここまで見ると、セキュリティガバナンスは、システム設計における責務分離・例外処理・状態管理・フィードバック制御と同じ型をしている。

企業組織を一つのシステムとして捉えると、こう対応づけられる。

システム設計	企業のセキュリティ統治
要件定義	許容するリスクと守る資産の定義
アーキテクチャ設計	組織構造・権限・責任の設計
インターフェース設計	報告・承認・エスカレーション
例外処理	インシデント対応・緊急判断
状態管理	脆弱性の発見・対応・保留・完了
タイムアウト制御	是正期限・期限超過時の強制通知
ログ・監査証跡	誰が、いつ、何を根拠に判断したか
回帰テスト	是正確認・再発防止の検証

決定的な共通点がある。

「正常系が動作すること」と「システムが健全であること」は違う。

ソフトウェアなら、例外を握りつぶしたり、エラーをログに残すだけで復旧処理がなかったりすれば、設計不良と判断される。

ところが組織になると、同じ構造の問題が「担当者の判断」「報連相不足」「意識改革」で片付けられがちだ。

たとえば、重大な脆弱性の報告が30日間放置されたら、組織として何が発火するのか。誰にエスカレーションされ、誰が停止権限を持ち、どの条件でリスク受容が失効するのか。

これらが定義されていなければ、組織というシステムの異常系設計が欠けている。

企業には人間の裁量が必要だから、すべてをプログラムのように決定論的には制御できない。だからこそ、裁量を認める範囲と、その判断を検証する仕組みの両方を設計する必要がある。

7-1. 状態遷移として書く

脆弱性管理は「見つけた／直した」の二値では足りない。

重要なのは、「リスク受容」を永久の免罪符にしないことだ。期限や前提が変わったら、再評価へ戻す。

責任者へ情報が届かない場合、権限者が対策実行を認めない場合、是正完了を誰も検証していない場合、それぞれに例外経路が要る。

手順書を増やす話ではない。組織の業務プロセスを、障害を検出して回復できるアーキテクチャとして設計する話だ。

8. 結論――セキュリティ企業かどうかではなく「問題に向き合える企業か」

整理すると、こうなる。

GMOには、日本のインターネットの商業化と普及に寄与した実績がある。技術的な創成そのものを独占したわけではない。
イエラエには、CTF、未知の脆弱性報告、Linuxカーネル研究など、高度な技術成果がある。正当に評価すべきだ。
専門家を抱えることと、グループ全体がリスクを確実に制御できることは別問題だ。
セキュリティは製品導入で完成しない。未知の脆弱性、パッチ差分、構成変更、人的・組織的判断でリスクは変わり続ける。
重要なのは「知っていたか」だけではなく、「誰に届き、誰が決め、いつまでに直し、誰が検証したか」だ。
それは、ソフトウェアに異常系・状態管理・監査・回帰テストを入れるのと同じ構造だ。

「日本企業の報連相不足」と片づけるだけでは浅い。根にあるのは、悪い情報が上がることを歓迎し、権限と責任を一致させ、不都合な判断にも経営が責任を負う仕組みがあるかどうかだ。

企業のガバナンスとは、人間が動かす業務プロセスに対するアーキテクチャ設計だ、と言ってもよい。

技術の設計不良には厳しいのに、組織の設計不良には曖昧な説明で済ませがちだ。そこに矛盾がある。

「セキュリティ企業だから安全」ではない。「IT企業だから安全」でもない。セキュリティ企業かどうかは、免罪符にも保証にもならない。

セキュリティの真価は、問題が起きないという看板ではなく、問題を見つけたときに、責任ある判断と是正が途切れず実行される組織かどうかにある。

主な参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up