STAMPとは何か？
STAMPとは、従来の解析的な還元や信頼性理論ではなく、システム理論に基づく新たな事故モデルのこと。従来の事故モデルでは、事故は故障イベントの連鎖によって起こると考えられてきた。しかしながら、近年システムの複雑さが増し、ハードウェアのように「故障」することのないソフトウェアが多く用いられ、事故発生の仕組みが変わった。STAMPは、システムを構成するコンポーネント間の相互作用に着目してシステム全体の流れを表す事故モデルとなる。このため STAMP では、事故は単純なコンポーネント故障のみを原因とせず、コンポーネントの振る舞いやコンポーネント間の相互干渉が、システムの安全制約（コンポーネントの振る舞いに関わる物理的、人、又は社会に関わる制約）を違反した場合に起こると考える。

出典：STAMP手法に関する調査報告書（IPA/SEC）

CPS社会の実現に立ちはだかる4つの課題

──IoT（Internet of Things）の普及に伴い、CPSに対する関心も高まっています。両者の違いは何でしょうか。

松本氏：CPSはIoTが実現して、初めて注目されるものです。私は、両者は別物だと考えています。IoTは、ネットを介してあらゆるモノがつながる「ユビキタスネットワークの実現形」で、いわば「土管」です。

　一方、CPSは、IoTと近年のハイコンピューティングパワーが結びつくことによって可能になったシステムです。これまでは実現できなかった膨大な量のデジタルデータの収集／分析や、人工知能（AI）による高度な解析結果が、実世界へフィードバックできることで生まれた「実世界とサイバー空間との相互連関」です。サイバー空間での情報処理結果によって、実世界の動きを制御するのがCPSです。


──サイバー空間と実世界が相互連携する世界では、既存のセキュリティや安全性に対する考え方が大きく異なりますね。

松本氏：システムの安全設計の観点から見れば、今までのサーバ中心の考えでは通用しなくなります。これまではサーバに格納されているデータを守るか、サーバ上で稼働するアプリを正確に動かすために信頼性を向上させていました。しかし、CPSのように、さまざまなシステムが複雑に連携する社会では、「1台のサーバのお守りをしていればよい」というわけにはいきません。言ってみれば、サーバ／システム間の境界線がなくなっている。安全性の考え方については、大きな転換期を迎えていると言えるでしょう。

──CPS社会の実現において、想定される課題は何でしょうか。

松本氏：CPSを利用するにあたり、解決すべき課題は大きく分けて4つあります。

　1つ目は、相互接続する相手先の信頼性と安全性の確認の難しさです。CPSはさまざまな製品が相互接続する世界です。そのような状況では、接続する製品／サービスの安全性や信頼性を確認することは難しい。信頼性のレベルが低い相手と接続すると、サービス全体の信頼性レベルが低下してしまいます。

　2つ目は、障害の影響範囲が以前とは比較にならないほど拡大していることです。現在は、サーバ1台の故障が、他のサービスにも影響を及ぼし、連鎖的にダウンすることも珍しくありません。こうした危険性は、今後も高まってくるでしょう。

　3つ目は開発プロセスを根底から見直す必要があることです。今までの開発プロセスは、コンポーネント単位で品質を向上させ、最終的に試験をする「V字モデル」でした。しかし、今後は相手との相互連携を考慮した試験をしなければなりません。ただし、連携先との試験のバリエーションを考えれば、すべてを試験することは、事実上不可能になります。

　4つ目はデータの信憑性はだれが保証するのかといった課題です。信頼性の高いセンサーやアプリが収集したデータであっても、取得したデータが本当に正しいのか。たとえば、モーターの回転数を取得しなければならないのに、モーターの稼働時間を取得してしまったらどうでしょうか。それが回転数データとして処理されたら、甚大な被害が発生します。

　さらに、データ・プライバシーも考慮しなければなりません。複雑に接続されている環境では、自分の予期しないところにデータが流れてしまう可能性があります。そうなれば、データの回収はできません。

──現在、各国が行っている標準化は、こうした課題の解決になるのでしょうか。

松本氏：残念ながら、ドイツのインダストリー4.0やアメリカのIIC（Industrial Internet Consortium）は、インタオペラビリティ（相互接続性）の部分しか考えていません。「安全性の度合いがどこまで可視化されているのか」「接続する機器／システムがどれだけセーフティ設計されているか」という取り決めはしていないのです。

　唯一、挙げるとしたら、2015年9月に米国のNIST（National Institute of Standards and Technology／国立標準技術研究所）が公開した「CPSフレームワーク」です。その中には「Trustworthiness／信用性」という規定が記載されています。

　そこではTrustworthinessとして、「安全性、信頼性（reliability）、セキュリティの確保を包含したガイドラインを定めるべきだ」とも書いてあります。ただし、ここでも具体的な中身は、まだ決まっていません。

機能単位で考える「STAMP」の可能性

──CPSでは障害の影響範囲が拡大するとのことですが、どのように障害原因を特定するのでしょうか。

松本氏：CPSでは障害の影響範囲想定し、原因を特定することは難しいのですが、SECでは米国マサチューセッツ工科大学（MIT）が開発した「STAMP（Systems Theoretic Accident Model and Processes／システム理論に基づく事故モデル）」というリスク分析手法に注目しています。これは、ハードウェアやソフトウェアなどを区別せずに、システムを構成する複数の分野を包括して開発する「システムズエンジニアリング」の考え方に基づき、安全性の高い設計をしようという発想です。

　これまでの障害原因診断は、イベント連鎖で考えていました。つまり、障害が起こった時点を起点にして原因を連鎖的に遡って追及し、根本的な原因となっているコンポーネントを特定する方法です。しかし、システムが密に相互連携している環境では、この方法は十分ではありません。

　一方、STAMPは「機能単位で考える」という考え方です。モノ（機器／部品）単位の原因究明ではなく、接続する先の要素も含め、機能単位で検証（原因究明）をします。機能を実現するコトンローラ間のインタラクションがどのように連携しているのかをモデル化した「コントロールストラクチャ」というモデルを基に考えるのです。

　具体的には、コントロールストラクチャ上でコントローラ間のインタラクションである「コントロールアクション」が適切なタイミングで正しく伝達されているのかを全体で整理し、ハザード（障害）に至るケースがないかを検証します。「システム全体を体系的に捉えて可視化する」という発想です。この考え方は分かりやすいので、日本で広めたいと考えています。

　ただし、STAMPで難しいのは、「考える機能単位の切り出し」の見極めです。機能を抽象化しすぎると包含される部分が多くなりすぎて分からなくなり、細かすぎると1つの部品になってしまう。STAMPのポイントは、「どこまでを抽象化し、コントロールストラクチャを書くか」です。SECでは　この部分を日本のシステム向けにテンプレート化したいと考えています。

──STAMPを用いた開発は行われているのでしょうか。

松本氏：日本でSTAMPを用いて設計されたということで有名なのは、宇宙航空研究開発機構（JAXA）の無人宇宙ステーション補給機「こうのとり」です。また、自動車メーカーもSTAMPに関心を持っています。積極的に公表はしていませんが、複数の大手自動車メーカーは、すでに一部でSTAMPを導入していると聞いています。

　実際にSECでもSTAMPを用いて試験的に安全性設計をしたことがあります。複数チームにわかれて模擬的に鉄道の踏切制御の仕組みを設計したのですが、全チームがまったく異なるコントロールストラクチャを書きました。どの視点でハザード分析をするかによって、機能の切り出し方が違いますからそうなるのですね。

　この検討ではSTAMPの提唱者であるナンシー・レブソン教授からもコメントを頂いたのですが、ナンシー教授のコントロールストラクチャも異なっていました。曰く、「STAMPに正解はなく、それぞれが正しい」ということです。

【次ページ】「安全レベルを可視化する」重要性