Assurance Case 36

Assurance Caseは欧米における、原子力発電所など高安全システムの安全性規格認証の際、提出が必

須になりつつあるSafety Caseを、ディペンダビリティやセキュリティなど他の属性も含めて一般化し た概念である。Safety caseの定義の一つを示す [1]。

‘A structured argument, supported by a body of evidence that provides a compelling, comprehensible and valid case that a system is safe for a given application in a given environment’

（システムが与えられた適用と環境において安全であることについて、説得力があり、理解しやすく、

妥当な根拠一式を提供する証拠を元にした構造化された議論）

Caseとは法廷用語である。Longman英語辞書では、以下のように定義されている。

‘All the reasons that one side in a legal argument can give against the other side.’

（裁判における各論点について、一方が他方に対して与えることができる全ての根拠）

ここでは、「根拠一式」と訳した。

Assuranceは、「確信を持てる、させる」という日本語が最も近い。O-DA [13]におけるAssuredness

は、「確信」と訳されうる。確信を持ってもらう対象が明記されていないが、狭義には規格認証者、広 義には利用者、開発者、さらには社会を含むステークホルダ全体が対象となる。意訳すると、Assurance Caseは

「システムがディペンダブルであるとステークホルダに確信を持ってもらうための議論および ドキュメント」

となる。

Safety Caseの背景には、欧米の安全性規格認証において、特に1970年代以降の深刻な事故への反省

から生じた、Prescriptive (処方箋的)なアプローチ中心の規格認証から、Goal-Based（ゴール指向）なア プローチを合わせた規格認証への大きな流れがある。深刻な事故の例として、1988年に死者167名を出 したPiper Alpha北海油田事故、35名の死者を出したClapham Junction鉄道事故がある。"Safety Case"

という言葉は、Cullen卿らによるPiper Alpha事故調査報告書などにより、広まったと考えられる[2]。

Prescriptiveな規格認証では、規格認証者が設定したチェック項目を満たすか否かで認証を行う。

Goal-Basedな規格認証では、安全性など、システムが満たすべき性質が与えられ、システム開発者や運

用者自らが、それが満たされていることの議論を、FTA解析結果などを証拠として自ら構築し、規格認 証者に提示する。

BloomfieldとBishopは、Prescriptiveな規格認証の欠点として以下をあげている[3]。

 システム開発者や運用者は定められた項目を充足するのみで、法的責任を満たすことができる。

定められた項目が安全性に不十分であったと後に判明しても、責任は規制側のみにある。

 Prescriptiveに定められた項目は、過去の経験に基づくものであり、技術的発展に伴い、不十分に

なる、さらには不必要なリスクを伴う可能性がある。

 Prescriptiveに定められた項目は、新しい安全技術の導入を阻む。

 Prescriptiveに定められた項目は、国際市場への展開、他分野との統合を阻む。

 Prescriptiveに定められた項目を満たすために、不必要なコストがかかることがある。

一方、Goal-Basedな規格認証では、システムの安全性を満たすための手法はシステム開発者、運用者 側に委ねられており、自由に安全技術を導入できるなど、ベストエフォートでシステムの安全性達成が できる利点があるとBloomfieldとBishopは主張している。Safety Caseに対する強い批判もある。

Levesonは、「多くのSafety Caseの研究は、個人的な意見を述べているか、記述例を示しているのみ

で、本当に効果的であるかどうかは示していない」と述べている[4]。

Safety Caseの構造の例として図4-1を示す。

図4-1: Safety Caseの構造の例

Safety Caseを要求項目としている規格の例としては、EUの航空管制システムに関する規格である

EUROCONTROL [5]、イギリスの鉄道の規格であるRail Yellow Book [6]、イギリス国防省規格である MoD Defense Standard 00-56 [7]がある。アメリカでは、医療器機分野において要求項目になるなどし ている。自動車の機能安全規格であるISO 26262は、Safety Caseが要求項目になっている。

Safety Caseは、多くの場合自然言語で記述される（企業の秘密情報を含むことから、公開されること

は少ない。例としてVirginia大学のSafety Case Repositoryがある[9]）。Safety Caseの記述、読解、

コミュニケーションを助けるために、グラフィカルな表記法が提案されている。代表的な表記法として、

York大のTim KellyらによるGSN (Goal Structuring Notation) [10]、Adelard社のRobin Bloomfield らによるCAE (Claim, Argument, Evidence) がある[11]。D-Caseの表記法はGSNをベースにしている

（後述する）。図4-2はCAEの例である。

図4-2: CAEの例

CAEは主に、Claim, Argument, Evidenceという３種類のノードがある。Claimはシステムが満たす べき主張である。ArgumentはClaimを支える議論を表す。EvidenceはClaimを最終的に支えるもの である。図4-3にGSNの例を示す。

図4-3: GSNの例

Goalは示すべき命題である。ContextはGoalを議論する前提、文脈である。Strategyは、ゴールを 詳細化し、サブゴールに分割する方法を説明する。Evidenceはゴールが達成されていることを示す最終 的な根拠である。Undevelopedは、Goalが達成されていることを示す十分な議論、Evidenceがその時 点でないことを示す。

CAEのClaimはGSNにおけるGoal、 CAEのEvidenceはGSNにおけるEvidence (Solution)、CAE のArgumentはGSNにおけるModuleとStrategyを合わせたような意味を持つ。本質的には、GSNと CAEは同じ表記法であり、GSNとCAEを統合したメタモデルSACM (Structured Assurance Case Metamodel) がOMGにおいて規格化されている[12]。注意すべきは、Safety CaseはGSNやCAEだけ で書かれた部分だけでなく、多くの他のドキュメントやモデル、説明文と合わせて構成されることであ る。GSNやCAEの記述編集支援ツールは、多くの他のドキュメントやモデル記述支援ツールとつなが る必要がある。

4.2.2 D-Case の定義と導入の経緯

D-Caseは従来のAssurance CaseをDEOSでのオープンシステムへの対応を基に拡張した手法とツー

ルである。オープンシステムのライフサイクルは、DEOSプロセスにあらわされるように、開発、運用、

障害対応など、あらゆるフェーズが同時に行われる。これまでのディペンダビリティの研究では、Laprie らの論文にあるように、開発フェーズと運用フェーズが明確に分かれて議論されてきた[14]。D-Caseは、

まず開発時、運用時の情報、さらに障害対応を同時に議論するために、従来のAssurance Caseの表記法 であるGSN (Goal Structuring Notation) に、開発時の情報に加えて、運用時のモニタリングおよび障 害対処の情報を明示するために、証拠（エビデンス）の概念を拡張したノードを追加した（後述する、

モニタノードとアクションノード）。さらにオープンシステムにおけるシステム間の関係を表すノード

（外部拡張ノード）を加えた。

D-Caseの定義は以下である。

 開発、運用、保守、廃棄などのシステムライフサイクルを通じて、システムのディペンダビリテ ィをステークホルダが合意し、社会に説明責任を果たすための手法とツール。主としてAssurance Caseを記述するための手法とツールを提供する。ドキュメント自体もD-Caseと呼ぶ。

D-Caseの導入の経緯を述べる。木下チームは2009年2、3月に、イギリスにディペンダビリティ研

究の調査旅行に、木下、武山、松野で赴いた[8]。GSN (Goal Structuring Notation) の提案者であるYork

大学のTim Kellyらと出会い、Assurance Caseを紹介された。若手を中心としたDEOSコアチームで

は、開発したOS要素技術の細分化、高度化により、それらのディペンダビリティの企業への説明に困 難があった。松野、髙村がAssurance Caseをコアチームに紹介したところ、システムのディペンダビリ ティ説明に有用であることが認識された。横手をリーダーとしたDEOSフレームワークチームでは、シ ステムのディペンダビリティ情報をシステム内に格納する仕組みを検討していた。エビデンスを元にし

たAssurance Caseの構造はディペンダビリティ情報のデータ構造として有望であると議論した。開発と

運用が境目なく行われるこれからのシステムは、ディペンダビリティ情報を開発と運用に共通的に用い る必要があるとDEOSで議論した。フレームワークチームとコアチームは、DEOSにおけるAssurance Caseとして、D-Caseという名前をつけた。2009年9月DEOS中間成果報告会において遠隔監視デモ システムのD-Caseを展示した。パネルディスカッション参加企業から、企業間で共通して用いることが できる、ディペンダビリティのための標準的なドキュメント形式として、D-Caseに期待すると言われた。

2010年1月より、東大と富士ゼロックス共同で、研究促進のためにD-Case Editorの開発が始まった。

2010年4月より、松野をリーダーとして、武山、中澤、髙村、高井、伊東、上野、田口、湯浅、松田ら で構成されるD-Caseチームの研究活動が本格的に始まった。以後、名大山本グループ、産総研加賀美チ ーム、筑波大佐藤チーム、東大石川チーム、DEOSセンター、D-Script (EBI) チーム、D-ADDチーム などと協力しながら現在に至っている。オープンシステムディペンダビリティのために重要である合意 形成と説明責任はD-Case、D-Scriptをベースに研究が行われてきた。

D-Caseについては次節において詳細を述べる。現在のSafety Caseは、システム供給者、第3者コン

サルティグ会社、システム利用者(国防省など)の間のコミュニケーションなどに使われるが、主には認証 のために使われてきた。規模が拡大し、ネットワーク化したこれからの情報システムは開発・運用を通 し、多くのステークホルダが合意し、システムと連携して、ディペンダビリティを達成する必要がある。

DEOS で開発している他のツールやランタイムシステムなどとの連携のための基礎研究と開発に加えて、

以下の3点が実用化のために重要であると考えた。

 企業にとってわかりやすい入門書や講習の開発

Safety Caseはこれまで高い安全性が求められるシステムに対して、高度な専門知識を持つコンサ

ルタントなどによって書かれてきた。そのため、セーフティケースのガイドブックなどは、安全性 分析など高い専門知識を前提とされたものがあるだけであった。これからのシステムのディペンダ ビリティは、一般企業が多く参加しなくては達成できない。そのためには、わかりやすい入門書や 講習が必要であると考えた。

 企業にとって使いやすい、ニーズに即したツールの開発

Safety Caseが普及し始めてまだ日が浅いこともあってか、ツールはイギリスAdelard社のASCE

ツール などいくつかあるだけである。またASCEツールなどは、主に認証ドキュメントを作成す るためのツールであり、他の開発ツールとの連携が容易ではなく、企業のニーズに即したツールに はまだなってない。企業が使いやすい、ニーズに即したツールが必要であると考えた。

 記述、応用例の充実

Safety Caseの問題の一つは、企業の重要な情報を含むことから、なかなか実際の例が表に出てこ

ない点がある。しかしそれでは一般の、特に日本企業の方に具体的なイメージを持っていただくこ とは困難である。わかりやすく、具体的な記述例や応用例が必要であると考えた。

従来のAssurance Caseにおける研究課題と、D-Caseでの新たな研究課題の領域の図4-4に示す。

Assurance Caseは従来高安全が要求される大規模システムの認証Assurance Caseは新しい分野であり、

図4-4の従来のAssurance Caseの部分に示した多くの課題は未解決である。図4-4はすでに研究が行わ

れていた研究課題に加え、オープンシステムのディペンダビリティの達成のために特に必要であると考