生成AIの進化により、サイバー攻撃の速度と規模はかつてないほど拡大している。2026年4月には、生成AIが東京大学の入試問題で合格者最高点を上回る成績を収めたことが報じられた。この能力は攻撃側も同様に活用でき、脆弱性の発見から攻撃の実行までをAIが担えば、攻撃を100%防ぐことは困難になる。重要ITシステムの設計は「守る」だけでは不十分で、守れなかった場合の被害をどこまで小さくできるかという発想が必要だ。その答えはITアーキテクチャにあると、筆者は考える。ヒントは自然界の生態系にある。
攻撃の速度に「守り」が追いつかない
東京大学の入試に関する報道では、論述問題のようにAIが不得意とする分野も明らかになった。いずれにしても、適用分野によってはAI化は速く進むだろう。では、AIを活用したITシステムへの攻撃についてはどうか。最近、連日不正アクセスによる情報窃取が報道されている。個々の事案にAIが使われたかどうかは多くの場合明らかになっていないが、AIを攻撃に使った事例は既に報告されている。中国の国家支援型の攻撃者がAnthropicの「Claude Code」を悪用し、偵察や脆弱性の発見、認証情報の窃取といった攻撃工程の80～90%をAIに自動的に実行させたサイバー攻撃活動はその一例だ。
現状でも、脆弱性が見つかってから攻撃に使える状態になるまでの時間は、中央値で24時間を大きく下回るという。筆者がかつて攻撃を実際に受けた複数のケースでは、同一の攻撃が複数発生しており、最短で2時間程度から始まった事象を確認している。脆弱性を突くプログラムの開発をAIが担うことは、既に技術的に可能になっている。Anthropicは2026年4月、未公開のAIモデル「Claude Mythos Preview」が主要なOSとWebブラウザで数十件の深刻な脆弱性を見つけ、その多くで攻撃コードを人の指示なしに作成したと公表した。同社は当時、危険性を理由にこのモデルを一般公開しなかった。こうした能力が攻撃側に渡れば、AIが脆弱性の状況を監視しつつ、見つけた脆弱性を突くプログラムを迅速に開発するところまでが、極めて短期間に実現することになる。
さらに現状でも、事前に攻撃先を特定して準備しておき、プログラムの開発後は速やかにそのプログラムを組み込んで攻撃を開始する仕組みが存在する。そのため、脆弱性の監視、攻撃プログラムの開発、攻撃先の特定、攻撃の実行という一連の活動をAIが自動的に実施し、多方面に攻撃することが可能になると考えられる。実際、侵入後の偵察から認証情報の収集、別システムへの移動、恐喝までをAIエージェントが連続して実行した事例も、2026年7月に報告されている。
守りと被害最小化の両輪で臨む
これに対応するには、2つの方向の備えが必要だ。一つは守りの強化、もう一つは守れなかったときの影響を小さくすることだ。まず守りの強化はどうすべきか。対応が必要なITシステムについて、どのソフトウェア部品で構成されているかを示すSBOM（ソフトウェア部品表）を常に管理する。その上で、脆弱性が検知されたソフトウェア部品を利用しているITシステムには素早くパッチを当てる、あるいはそのITシステムを外部のネットワークから切り離すといった脆弱性対応の手順と仕組みを構築する必要がある。パッチが用意される前の脆弱性をAIが見つける能力は、前述の通り既に現実のものだ。Anthropicは、この能力を防御側で先に生かすため、AWS、Microsoft、Googleなどと「Project Glasswing」を立ち上げた。こうした脅威については、各国が協力して対応方法を検討することが急務だと考えられる。
もう一つは、守れなかったときの影響を小さくすることだ。マイクロサービス（MS）を活用し、データをサービス単位に分散して持つことで、攻撃された場合の被害を最小化できる。例えば、顧客名だけの流出であれば、被害は限定的だ。住所だけの流出も同様だ。顧客名と住所を別々のサービスが持っていれば、一方のサービスが攻撃されても、顧客名と住所が紐付いた形では流出しない。データをサービス単位に分断して持てば、攻撃された場合の影響範囲を最小化できるのだ。サービス機能の分断が進めば、トラブル時の影響範囲も最小化でき、個別に対応できるため復旧も早い。
攻撃を100%防ぐことが難しい以上、トラブル発生時の影響範囲の最小化と対応力の向上を同時に目指す必要がある。守りだけでなく、守れなかったことも想定した対策を講じるべきなのだ。従って、重要ITシステムのMSアーキテクチャ化は避けて通れない。
「外部との電文のやりとり」を状態の変化で整理する手法とは
本題に話を戻す。まず状態遷移図を取り上げる。状態遷移図とは、システムが取り得る「状態」と、ある出来事（電文の受信など）をきっかけに別の状態にどう遷移するかを図にしたものだ。電文とは、システム同士がネットワークを通じてやりとりする、決まった形式のデータのまとまりのことだ。現在のAPIにおけるリクエストやレスポンスに近い。通信制御の設計では、相手と電文をやりとりするたびに接続や処理の状態がどう変わるかを整理するために使われてきた。
これまでのモノリス（一枚岩）のITシステムでは、外部の接続先とリアルタイムでデータをやりとりする方法を表現する有効な手段として、状態遷移図が利用されてきた。モノリスのITシステムでやりとりされるデータはトランザクションデータであり、同一のネットワークで接続先とさまざまなトランザクションを交換している。トランザクションの処理方式は大きく制御系とアプリケーション系の2つに分かれ、それぞれが状態遷移図で表現されてきた。制御系に該当するのは、ネットワークの接続を開始するための「開局電文」のやりとりや、接続を終了させる「閉局電文」のやりとりだ。それらの電文に挟まれる形で、トランザクションの種類ごとに、データのやりとりに伴う状態の移り変わりを表現したものが状態遷移図だ。
東京証券取引所と証券会社の売買データのやりとりを例に考える
東京証券取引所（東証）と証券会社の間で株式の売買データをやりとりする例でイメージを共有しよう。取引時間は決まっているので、取引時間の前に開局電文を相互にやりとりし、データ受信の準備ができていることを互いに確認する。取引時間の終了時も同様に、閉局電文を相互にやりとりして確認する。
アプリケーション系のトランザクションでは、例えば特定の株式の買い注文のデータを証券会社から東証に送信する。東証はデータの妥当性を確認し、買い注文のデータを受け取ったことを示す電文を証券会社に送信する。不適切なデータの場合は、エラーの電文を証券会社に送信し、該当データの処理を受け付けない。受け付けた買い注文が約定した場合、東証は約定した事項と約定価格、約定番号などの電文を該当する証券会社に送信する。
このように、トランザクションデータの種類ごとに、電文のやりとりと状態の移り変わりを整理する手法として、状態遷移図は有用だ（実際にはかなり複雑だが……）。すべてのトランザクションデータの種類について状態遷移図を定義することが求められる。
マイクロサービス化では「API単位」に状態遷移図を定義し直す
ところがMS化の場合は、一つのネットワーク接続というよりは、多くのネットワークで外部の接続機器とAPIによって結ばれることになる。そのため、制御方式もあらかじめ両者で確立しておく必要がある。両者間のAPIをすべて明確にした上で、制御方式についてはAPIの接続方式を標準化する。その上で、API単位に、アプリケーション別の状態遷移を定義することになる。
先ほどの例で言えば、買い注文のAPIと約定のAPIが別になる場合も当然あり得る。そのため、かなりの数のAPIを定義する必要がある。同一機能のAPIでも、例えば株式の銘柄単位にAPIが分離されることも想定される。接続方式に関しては、APIを念頭に置いた状態遷移図を作成する必要があり、その標準化が重要だと筆者は考える。
銘柄単位にAPIを分離するのは、決済の時期や株式分割、増資・無償増資、売買の停止といったように、銘柄ごとに異なる状況に対応するためだ。特定の銘柄でトラブルが発生しやすい場合でも、APIを分離しておけば他の銘柄に影響を与えずに済み、トラブル発生時の影響範囲を最小化できる。
APIによる機能分断で復旧を速められる理由
ネットワークのハードウェアのトラブルも避けて通れない。現状では、複数の種類のトランザクションデータが同一のネットワークで接続されているため、トラブル発生時の外部との影響範囲が大きくなる。APIで機能を分断すれば、ネットワークも物理的に分断でき、結果的に影響範囲が限定される。
さらに、API単位にソフトウェアやネットワークのトラブル対応を独立して実施できるようになり、トラブルからの復旧時間も大幅に改善される。つまり複数のAPIで接続することにより、ネットワークの並列接続を可能にするわけだ。現状の直列接続と比べて信頼性を飛躍的に高めるとともに、障害発生時の影響範囲の縮小を実現できる。今後ネットワークの接続が拡大する中で、耐障害性の観点から極めて重要な方式になると考えられる。API化は単にMS化への対応というだけではなく、今後ますます広がるネットワーク化の中で、トラブルの影響範囲の最小化とトラブル対応の迅速化に大きく貢献する。さらに、前述したように外部からの攻撃によるトラブルへの対応力の強化にもつながるのだ。
「見えざる手」が早熟を生むエコシステムへ
同一機能のサービスを複数活用することで、アプリケーションレベルの冗長構成を実現する道も開けると考えられる。ハードウェアを二重化するだけでなく、同じ機能を提供するサービスを複数用意しておき、一つが止まっても別のサービスで業務を続けられるようにする構成だ。
特に重要ITシステムの場合、アプリケーションレベルの冗長構成を実現することは今後一層重要になる。検討課題は当然いくつかあるが、機能を小さく分離独立させたアーキテクチャにすることは、代替機能を複数提供する状況を実現するための必須条件だと筆者は考える。
同一の機能を持つ複数のサービスが、それぞれ独自の個性を持ちつつ互いに競争しながら進歩し、共存していくことが、エコシステム全体としての機能を高める。その結果、エコシステムとしての信頼性と安全性が高まり、コストの最適化も進む。そうした自発的で健全な競争をしながら新陳代謝を促し、系として発展するのが真のエコシステムなのではないかと筆者は思っている。
冒頭で、ヒントは自然界の生態系にあると述べた。自然界では、同じ機能と異なる機能を持つたくさんの生物（動物、植物、菌類、細菌など）が、雨や風といった自然現象や、山、田、海といった地形も含めた環境を構成している。それらは厳しい生存競争を行いながら、互いに依存しつつ調和している。ITシステムも、こうした自然界そのものに少しずつ近づくように進化していくと筆者は感じている。つまり、MSアーキテクチャが進むことで、独立したITサービスが競争しながら共存し、エコシステムを形成する。そして全体の調和を達成しつつ、状況変化にも対応する。誰かが中央で統治するのではなく、アダム・スミスのいう「見えざる手」に導かれるように、個々の競争と共存から全体の早熟が生まれる。こうした姿こそが、われわれが目指すべきITシステムのアーキテクチャなのではないかと筆者は思っている。
データ分析の時代、DFDが再び役立つと考える理由
最後に、データフローダイアグラム（DFD）を取り上げる。DFDは、業務の中でデータがどこから入り、どのように加工され、どこに蓄積・出力されるかという「データの流れ」を図にする手法だ。そもそもDFDは、筆者がSE人生を始めた頃に一世を風靡していた「構造化分析手法」の核となる、業務要件の表現方法だ。構造化分析手法は、業務をデータの流れと処理に分解して仕様を記述する方法論で、1970年代後半に体系化され、1980年代にかけて普及した。
当時は、いわゆるリアルタイム処理（当時はオンライン処理と呼んでいた）が出始めた頃だった。ホストコンピュータの障害時に、待機している別のホストコンピュータに自動的に切り替わる処理（いわゆるテークオーバー）をサポートしているコンピュータメーカーもまだ少なかった。従って、データベースの更新（当時は磁気テープに記録したファイルの更新が中心で、そのファイルをマスターファイルと呼んでいた）はバッチ処理が主体だった。実際、利益計算など特定の日に一斉に行う処理がどうしてもあるため、バッチでデータベースを更新する処理は現在でも残っている。バッチでマスターファイルを更新する時代において、DFDは要件を表現する極めて有効な手段だった。そのため当時、構造化分析手法は、トム・デマルコ氏やエドワード・ヨードン氏といった著名人とともに主要な方法論になった。ヨードン氏は後にオブジェクト指向に傾倒し、ピーター・コード氏との共著でオブジェクト指向分析（OOA）を提唱した。筆者もその著書を手にしている。
ただ、ITシステムが24時間365日稼働し続ける必要性はますます高まり、バッチ処理でデータベースを更新する比率は確実に低下している。そういう意味では、バッチ処理を前提にした業務要件の表現方式の重要性は低くなっている。筆者も、データベースの更新は今後リアルタイムの方式で実施すべきだと考える。ただ、DFDは、トランザクションデータがどのように変換・分離・廃生されるかを表現するには有効だ。つまり、DFDはトランザクションデータの振る舞いを可視化する手法なのだ。そういう意味では、SoI（Systems of Insight：蓄積したデータを分析して洞察を得るためのシステム）などのデータ分析基盤に提供するデータの整理と可視化には、大いに役立つと考えられる。
というのも、データ分析の対象はリアルタイムのデータだけではない。日ごと・月ごと・年ごとのトレンドも分析する必要があるからだ。短期的な視点と中長期的な視点、ミクロの視点と俯瞰（ちょうかん）する視点など、さまざまな角度からの分析が必要だからだ。その意味でも、DFDは今後も業務要件を表現する有力な手法であり続けると筆者は考える。
既存システムの現状分析にもDFDは欠かせない
DFDは既存のITシステムの現状分析において重要な手法だ。状態遷移図や画面遷移図といった他の手法も、現状分析をする上では、復元すべき情報を明らかにするための情報整理方法になる。
標準化とAI活用の前提になるものは？
これまで述べてきた手法には、共通することがある。これらの情報は、紙で整理して表現するのが非常に難しいということだ。DFDや業務フローはその典型だ。維持管理に頼っては、紙では極めて煩雑になる。標準化を進める上でもツール化と設計情報のデータ化、すなわちリポジトリ化は必須だ。リポジトリとは設計情報を一元に蓄積し、工程や担当者をまたいで参照・更新できるデータベースのことだ。リポジトリ化することで、AIを活用して異なる工程の設計情報の一部を自動生成することも可能になる。
工程をまたぐ設計の完全自動化、「できないし、やるべきでもない」理由
ただし、工程間の設計情報は、密に結び付けることなく、緩やかに連絡させる必要がある。各工程間でリアルタイムに矛盾をなくし続けるよりも、定期的に矛盾を洗い出し、その都度確認するのが妥当だと筆者は考える。設計工程は進むごとに段階的に詳細化され、詳細化によって前工程の矛盾も発見されるからだ。
矛盾点の洗い出しが一段落した時点で、前工程の設計情報に反映すべきかを判断すればよい。その矛盾点が工程による捉え方の差によるものであれば、容認してよい可能性があると筆者は思う。ある工程ですべてを見通せるのは神のみであり、人間にはできない。各工程で、その工程に見合った粒度まで情報を段階的に詳細化していくことが重要だ。
工程が違えば扱う情報も違うのだから、完全自動化は決してできないし、やるべきでもない。AIを活用しながら生産性と品質を上げる活動は、終わりのない改善なのだ。
