一般社団法人ディペンダビリティ技術推進協会

OSD部会 各部会紹介

技術活用部会の活動

2021年6月21日
技術活用部会中川 雅通

活動ミッション
協会が保有する技術の産業・社会への活用

活動
OSDが活用できる・必要とされると考える分野に対して、具体的な提案活動
ギャップ分析、OSD視点からの追加案

適用分野
条件

• 開発だけでなく、継続的な信頼性確保の取組みが必要な分野• 複数のステークフォルダーが存在して、合意形成、説明責任が重要になると思われる分野
取組み分野• つながる世界のセキュリティ（IPA）• 医療情報ガイドライン（経産省）• 機械学習品質マネジメントガイドライン 取組み中
2021/6/21

1.つながる世界の開発指針
IPA（情報処理推進機構）が発行
IoTの進展にともない、様々なモノがつながって新たな価値を創出していく『つながる世界』ならではの機器やシステムに関わる企業が安全安心に関して最低限考慮すべき事項を記載

2021/6/21

つながる世界の１７の指針
大項目

4.1 つながる世界
方の安全安心に企
針業として取り組む指針
指針１

安全安心の基本方針を策定する

指針2

安全安心のための体制・人材を見直す

指針3

内部不正やミスに備える

指針4

守るべきものを特定する

4.2 つながる世界 指針5分のリスクを認識す析指針6る

4.3 守るべきもの
設を守る設計を考計える

運 4.5 関係者と一緒つながりで波及するリスクを想定する

指針7

物理的なリスクを認識する

指針8

個々でも全体でも守れる設計をする

指針9

つながる相手に迷惑をかけない設計をする

指針10

安全安心を実現する設計の整合性をとる

指針11

不特定の相手とつなげられても安全安心を確保できる設計をする

指針12

安全安心を実現する設計の検証・評価を行う

4.4 市場に出た後 指針13
保も守る設計を考え守
指針14
る2017/6/6

つながることによるリスクを想定する自身がどのような状態かを把握し、記録する機能を設ける
時間が経っても安全安心を維持する機能を設ける

指針15

出荷後もIoT リスクを把握し、情報発信する

指針16

出荷後の関係事業者に守ってもらいたいことを伝える

２つの文書の項目毎に比較つながる世界の17の開発指針
方針：
方針：
4.1 安全安心に企 4.1
業として取り組む

方針：
分析:
分析:
分析:
分析:
設計:
設計:
4.1
4.2 リスクを認識 4.2
4.2
4.2
4.3 守るべきもの 4.3するを守る設計を考える
123456789
安全安心の基本 安全安心のため 内部不正やミスに 守るべきものを特 つながることによ つながりで波及す 物理的なリスクを 個々でも全体でも つながる相手に方針を策定する の体制・人材を見 備える
定するるリスクを想定す るリスクを想定す 認識する守れる設計をす 迷惑をかけない
直す
る
る
る
設計をする

設計:
設計:
保守:
保守:
運用:
運用:
運用:
4.3
4.3
4.4 市場に出た後 4.4
4.5 関係者と一緒 4.5
4.5
も守る設計を考えに守るる
1011121314151617
安全安心を実現 不特定の相手と 安全安心を実現 自身がどのような 時間が経っても安 出荷後もIoTリス 出荷後の関係事 つながることによする設計の整合 つなげられても安 する設計の検証・ 状態かを把握し、 全安心を維持す クを把握し、情報 業者に守ってもら るリスクを一般利性をとる
全安心を確保で 評価を行う
記録する機能を る機能を設ける 発信する
いたいことを伝え 用者に知ってもらきる設計をする
設けるるう①経営者は、つな ①つながる世界 ①つながる世界 ①つながる世界 ①クローズドな①セキュリティ上 ①盗まれたり紛 ①外部インタ①IoTコンポーネ ①安全安心を実 ①IoTコンポーネ ①つながる機器 ①自身の状態や ①経年で増大す ①欠陥や脆弱①導入、運用、保 ①不用意なつながる世界の安全 における安全安 の安全安心を脅 の安全安心の観 ネットワーク向け の脅威や機器の 失した機器の不 フェース経由／内 ントの異常を検知 現するための設 ントがつながる相 やシステムは、他機器との通信 るリスクや変化す 性、事故やインシ 守、廃棄で守って ぎ方や不正な使安心の基本方針 心上の問題を統 かす内部不正の 点で、守るべき本 の機器やシステ 故障の影響が、 正操作や管理者 包／物理的接触 できる設計を検討 計を見える化す 手やつながる状 IoTならではのリス 状況を把握して記 る使い方・利用環 デントの最新情報 もらいたいことを い方をすると、自を企業として策定 合的に検討でき 潜在可能性を認 来機能や情報な ムであってもIoTコ 他の機器とつな のいない場所で によるリスクに対 する。
る。
況に応じてつなぎ クも考慮して安全 録する機能を検 境に対し、アップ を常に収集・分析 直接それらの業 分だけでなく、他し、社内に周知す る体制や環境を 識し、対策を検討 どを特定する。
ンポーネントとし がることにより波 の物理的な攻撃 して個々のIoTコ ②異常を検知し ②安全安心を実 方を判断できる設 安心の設計の検 討する。
デートなどで安全 する。
務に関わっている 人に被害を与えるとともに、継続 整える。
する。
②つなげるため て使われる前提 及するリスクを想 に対するリスクを ンポーネントで対 たときの適切な振 現するための設 計を検討する。 証・評価を行う。 ②記録を不正に 安心を維持する ②必要に応じて 担当者や外部の たり、環境に悪影的に実現状況を ②そのための人 ②関係者のミスを の機能(IoT機能） でリスクを想定す 定する。
想定する。
策を検討する。 る舞いを検討す 計の相互の影響 ②危険なつなぎ消去・改ざんされ 機能を検討する。 社内や関係事業 事業者に伝える。 響を与えたりする把握し、見直して 材（開発担当者や 防ぐとともに、ミス についても、本来 る。
②特に、安全安 ②中古や廃棄さ ②個々のIoTコン る。
を確認する。
方をしにくい設計ないようにする機者、情報提供サイリスクがあることいく。
保守担当者など） あっても安全安心 機能や情報の安 ②つながる相手 心対策のレベル れた機器の情報 ポーネントで対応や危険なつなぎ能を検討する。
トなどへリスクのを一般利用者にを確保・育成す を守る対策を検 全安心のためが偽物だったり、 が低い機器やシ などの読み出しや しきれない場合方に気づくような情報を発信し共伝える。
る。
討する。に、守るべきもの 乗っ取られるリス ステムがつながる ソフトウェアの書 は、それらを含む設計を検討す有する。
②安全安心を維として特定する。 クを想定する。と、影響が波及す き換え・再販売な 上位のIoTコンる。
持していくために③保守時のリス るリスクが高まる どのリスクを想定 ポーネントで対策
一般利用者にク、保守用ツール ことを想定する。 する。
を検討する。
守ってもらいたいの悪用によるリスことを伝える。
クも想定する。

大項目
Ｎｏ
指針

ポイント

本指針が関係す 人材の確保・育成 合意形成においる項目は多い。し は合意につなげ ては、本指針はかし、「理解」や る理解の醸成に ほぼ無関係とい「合意」について 寄与する。しかえる
各列コメント→ の明確な記述は し、明確な合意形 個々の指針毎のない。
成や他ステークホ 合意も必要であルダの合意の記 る。
述はない。
62853のア
ウトカムa) ステー
クホルダ
間でシステム等に関する共通理解と明示的合意が確立している

IEC62853の１つのviewにおける
outcome
注: 4つのview毎に表が作られている
1. 合意形成2. 変化対応
3. 障害対応
4. 説明責任

具体的説明

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

設計:
4.3

設計の見える化 合意形成においが合意形成の一 ては、本指針は助になることは確 ほぼ無関係といかだが、まだ不足 える個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

本指針が関係す 本指針が関係す 本指針が関係する項目は多い。し る項目は多い。し る項目は多いしかし、「理解」や かし、「理解」や かし、「理解」や「合意」について 「合意」について 「合意」についての明確な記述は の明確な記述は の明確な記述はない。
ない。
ない。

各行コメント↓「システム等」とはシステム、システムの目的、目標、環境、性能、ライフサイクルおよびそれらの変化を言う

各資料はステー 明示的に合意す 社内に周知
クホルダー毎に るような記述は (明示的な合意ま利用できるよう ないでは無い）
準備し理解/合意レベルがわかるようにしておく人材（開発担当者や保守担当者など）を確保・育成(社内のステークホルダのみへの理解対応。
明示的な合意までは無い）

1)システムのステークホルダが同定されている

ステークホル
ダー記入欄がありその全体リストも出るようにしておく

いくつかのス
社内に周知
テークホルダが出てくるが、網羅されている保障はない人材（開発担当者や保守担当者など

２）記述の枠組みが確立しており、全てのステークホルダーによって理解されている文書関連図ががありその図とステークホルデーとの関係がわかるようにしておく

指針1～17が記述の枠踏みといえるか？
記述の枠組みについての理解か？ だとするとこの列は該当なしとなる

３）システム等についての各ステークホルダによる共通理解が得られている

ステークホル
ステークホルダ 社内に周知人材（開発担当者
ダーのドメイン を網羅している 通知だけでは「理 や保守担当者なにあった言葉で かは？
解」には届かない ど）を確保・育成
記述され記録さか？
育成をしているのれていることで「理解」には十分と考えられる設計を見える化
設計の相互の影響を確認
見える化すること
で、開発者のみならず、経営層、発注元、外注先などに対するセーフティやセキュリティの設計品質の説
明及び合意にも活用することが可能である

社内や関係事業 出荷後の関係事 一般利用者に者、情報提供サイ 業者に伝える
知ってもらうトなど(明示的な合意ま (明示的な合意まリスクの情報を発 では無いが、教育 では無い）
信し共有や訓練が含まれる）

社内や関係事業 出荷後の関係事 一般利用者
者、情報提供サイ 業者
トなど

開発者のみならず、経営層、発注元、外注先など見える化することで、開発者のみならず、経営層、発注元、外注先などに対するセーフティやセキュリティの設計品質の説
明及び合意にも活用することが可能である

社内や関係事業 出荷後の関係事 一般利用者
者、情報提供サイ 業者
伝えるだけなのでトなどへ発信し共 伝えるだけなので 理解が得られる
有する
理解が得られる かは保証なし
かは保証なし明示的に合意と 明示的に合議と記録は記述され 記録は記述されていない→各社・ ていない→各社・各組織の活動に 各組織の活動に依存する
依存する

明示的に合意と記述されていない→各社・各組織の活動に依存する

明示的に合議と 明示的に合議と 明示的に合議と記録は記述され 記録は記述され 記録は記述されていない→各社・ ていない→各社・ ていない→各社・各組織の活動に 各組織の活動に 各組織の活動に依存する
依存する
依存する

６）合意文書の解釈のステークホル
ダーによる差異は少ない

合意に利用した どうすれば「差 「周知」でどこまで 人材（開発担当者
文書名を記述し 異が少ない」と できるかが鍵→ や保守担当者な即座に取り出せ いえるのかが難 各社・各組織の活 ど）に限定されるる環境としてお しい
動に依存するが、育成している
くので差異は縮小できるはず

開発者のみならず、経営層、発注元、外注先などに限定されているが、見える化によりある程度差異はすくなく解釈できる？

情報を発信し共有→共有の具体的な方法に依存する

７）以上のアウトカムが公正で全てのステークホルダにマインドフルなやり方で達成されている

ステークホル「マインドフ「周知」でどこまで 「育成」のやり方
ダー毎の理解/合 ル」のレベルは できるかが鍵→ に依存する
意状況が即座に 各組織のやり方 各社・各組織の活見られる環境と に依存するし、 動に依存するしておく
どこまでできているかの確認も難しいことは確か。

マインドフルかど
うかは組織のやり方に依存する共有の具体的な 伝えるだけなの 伝えるだけなの方法に依存する で、マインドフル で、マインドフルかどうかは伝え方 かどうかは伝え方に依存するに依存する

４）合意が得られない場合の調停プロセスが定められている
５）３）の理解に基づいてシステムに関する明示的合議が得られ、記録されている。

合意形成プロセ ここまでの記述
スを用意し各ス はみあたらない
テークホダーに説明し理解されていること
各関連文書にス
明示的に合意とテークホルデー 記録は記述されの理解/合意レベ ていない
ルの記録をするマッピング結果の各outcome毎のコメント

マッピング結果の各指針毎のコメント

直接それらの業 伝えるだけなので務に関わっている 解釈の差異がすく担当者や外部の ないとはいえない
事業者に伝える→伝え方に依存する

つながる世界の開発指針の1項目とIEC62853のoutcomeの1項目毎のマッピング結果
黒字: 62853のoutcomeの記述に対応する開発指針の記述部分
赤字: コメント
×印: 無関係、対応せず
グレー : 列もしくは行全てが×印

合意形成との比較

方針：
方針：
4.1 安全安心に企 4.1
業として取り組む

方針：
4.1

分析:
4.2 リスクを認識
する

分析:
4.2

分析:
4.2

分析:
4.2

設計:
設計:
4.3 守るべきもの 4.3を守る設計を考える
12
3456789
安全安心の基本 安全安心のため 内部不正やミスに 守るべきものを特 つながることによ つながりで波及す 物理的なリスクを 個々でも全体でも つながる相手に方針を策定する の体制・人材を見 備える
定するるリスクを想定す るリスクを想定す 認識する守れる設計をす 迷惑をかけない直す
る
るる設計をする

設計:
4.3

10
安全安心を実現する設計の整合性をとる①経営者は、つな ①つながる世界 ①つながる世界 ①つながる世界 ①クローズドな①セキュリティ上 ①盗まれたり紛 ①外部インタ①IoTコンポーネ ①安全安心を実がる世界の安全 における安全安 の安全安心を脅 の安全安心の観 ネットワーク向け の脅威や機器の 失した機器の不 フェース経由／内 ントの異常を検知 現するための設安心の基本方針 心上の問題を統 かす内部不正の 点で、守るべき本 の機器やシステ 故障の影響が、 正操作や管理者 包／物理的接触 できる設計を検討 計を見える化すを企業として策定 合的に検討でき 潜在可能性を認 来機能や情報な ムであってもIoTコ 他の機器とつな のいない場所で によるリスクに対 する。
る。
し、社内に周知す る体制や環境を 識し、対策を検討 どを特定する。
ンポーネントとし がることにより波 の物理的な攻撃 して個々のIoTコ ②異常を検知し ②安全安心を実るとともに、継続 整える。
する。
②つなげるため て使われる前提 及するリスクを想 に対するリスクを ンポーネントで対 たときの適切な振 現するための設的に実現状況を ②そのための人 ②関係者のミスを の機能(IoT機能） でリスクを想定す 定する。
想定する。
策を検討する。 る舞いを検討す 計の相互の影響把握し、見直して 材（開発担当者や 防ぐとともに、ミス についても、本来 る。
②特に、安全安 ②中古や廃棄さ ②個々のIoTコン る。
を確認する。
いく。
保守担当者など） あっても安全安心 機能や情報の安 ②つながる相手 心対策のレベル れた機器の情報 ポーネントで対応を確保・育成す を守る対策を検 全安心のためが偽物だったり、 が低い機器やシ などの読み出しや しきれない場合る。
討する。に、守るべきもの 乗っ取られるリス ステムがつながる ソフトウェアの書 は、それらを含むとして特定する。 クを想定する。と、影響が波及す き換え・再販売な 上位のIoTコン③保守時のリス るリスクが高まる どのリスクを想定 ポーネントで対策
ク、保守用ツール ことを想定する。 する。
を検討する。の悪用によるリスクも想定する。
本指針が関係す 人材の確保・育成 合意形成においる項目は多い。し は合意につなげ ては、本指針はかし、「理解」や る理解の醸成に ほぼ無関係とい「合意」について 寄与する。しかえるの明確な記述は し、明確な合意形 個々の指針毎のない。
成や他ステークホ 合意も必要であルダの合意の記 る。
述はない。

理解や合意が必要だが明確な記述はない

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成アウトカムに直接つながる指針ではない。
しかし、各指針の合意は必要と考える。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

設計:
4.3

保守:
保守:
運用:
運用:
運用:
4.4 市場に出た後 4.4
4.5 関係者と一緒 4.54.5も守る設計を考えに守るる
11121314151617
不特定の相手と 安全安心を実現 自身がどのような 時間が経っても安 出荷後もIoTリス 出荷後の関係事 つながることによ
つなげられても安 する設計の検証・ 状態かを把握し、 全安心を維持す クを把握し、情報 業者に守ってもら るリスクを一般利
全安心を確保で 評価を行う
記録する機能を る機能を設ける 発信する
いたいことを伝え 用者に知ってもらきる設計をする
設けるるう①IoTコンポーネ ①つながる機器 ①自身の状態や ①経年で増大す ①欠陥や脆弱①導入、運用、保 ①不用意なつなントがつながる相 やシステムは、他機器との通信 るリスクや変化す 性、事故やインシ 守、廃棄で守って ぎ方や不正な使手やつながる状 IoTならではのリス 状況を把握して記 る使い方・利用環 デントの最新情報 もらいたいことを い方をすると、自況に応じてつなぎ クも考慮して安全 録する機能を検 境に対し、アップ を常に収集・分析 直接それらの業 分だけでなく、他方を判断できる設 安心の設計の検 討する。
デートなどで安全 する。
務に関わっている 人に被害を与え計を検討する。 証・評価を行う。 ②記録を不正に 安心を維持する ②必要に応じて 担当者や外部の たり、環境に悪影②危険なつなぎ消去・改ざんされ 機能を検討する。 社内や関係事業 事業者に伝える。 響を与えたりする方をしにくい設計ないようにする機者、情報提供サイリスクがあることや危険なつなぎ能を検討する。
トなどへリスクのを一般利用者に方に気づくような情報を発信し共伝える。
設計を検討す有する。
②安全安心を維る。
持していくために一般利用者に守ってもらいたいことを伝える。

設計の見える化 合意形成においが合意形成の一 ては、本指針は助になることは確 ほぼ無関係といかだが、まだ不足 える個々の指針毎の合意も必要である。

設計:
4.3

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

合意形成においては、本指針はほぼ無関係といえる個々の指針毎の合意も必要である。

本指針が関係す 本指針が関係す 本指針が関係する項目は多い。し る項目は多い。し る項目は多いしかし、「理解」や かし、「理解」や かし、「理解」や「合意」について 「合意」について 「合意」についての明確な記述は の明確な記述は の明確な記述はない。
ない。
ない。

合意形成アウトカムに直接つながる指針ではない。
しかし、各指針の合意は必要と考える。

設計の見える化
は、理解を助け合意形成の一助になる

アウトカムに関連する項目が多い
理解や合意が必要だが明確な記述はない

OSDの視点からの提言の例
 設計：守るべきものを守る設計を考える
指針12の「安全安心を実現する設計の検証・評価を行う」は、OSDでの「障害対応の遂行」につながる。

OSDでは「起きた障害の実態に即して設計時の仮定を見直す」、「なされた対応処理を評価する」ために、設計時だけでなく運用時にも検証・評価を行うことも要求している。

 運用：関係者と一緒に守る
指針15、16では、リスクや守ってもらいたいことの関係者への周知が重視されている。
OSDの合意形成の観点からは、さらに、何にどこまで対応するか等について関係者との「明示的合意」を双方向のコミュニケーションで確立することも要求している。

また、障害対応に対する、関係者、一般利用者へ、「実施した障害対応が、正しい対応であったか」の説明責任遂行も要求している。更に、合意をなぜ守らないといけないのか、守らないとどうなるかについて、普段から説明をして納得を得ることも要求している。
2021/6/21

IPA SEC Journalへ寄稿得られた知見をIPA発行の雑誌で公開
IPAの SEC journal 第53号。
IEC 62853と「つながる世界の開発指針」 Open
Systems Dependabilityの観点からの考察

https://www.ipa.go.jp/files/000068597.pdf

2021/6/21

2. 医療情報ガイドライン
 「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」へOSDの考え方を取り入れたいと経産省和泉審議官おりお声がけいただく。
 医療情報に関するシステムは、患者、医療機関、システム開発事業者、システム運用事業者など専門知識の異なる多くのステークホルダーが関係するシステム。
 ガイドライン案をOSDの観点から検討し、主に合意形成、説明責任の観点から追加、修正案を提案。
 ２０２０年８月のガイドラインへOSDの観点が取り込まれる。
https://www.meti.go.jp/press/2020/08/20200821002/20200821002.html
2021/6/21

医療情報システム等のライフサイクル
共通理解や、合意の維持などのOSDの観点

2021/6/21

3. 機械学習品質マネジメントガイドライン
 産総研の「機械学習品質マネジメントガイドライン 第一版」
https://www.cpsec.aist.go.jp/achievements/aiqm/（以下AIQMガイドライン）を、OSDの観点から検討中
 ガイドラインの主眼は、従来のソフト開発と異なる機械学習の品質の確保についてである。例えば、データへの依存性、繰り返しによる要件の獲得の仕方、運用での学習などである。
 OSDの観点からは、機械学習の不確実性、運用時での学習が開発行為となる点、モニタリングの重要性などへの言及など、関連する内容も数多くあると考える。

AIQMの中でOSDに関連しそうな記載
 1.3.2 継続的なリスクアセスメント
機械学習を利用するシステムにおいては、いわゆる「バグ」「初期不良」への対応として必要な修正だけでなく、当初から運用開始後の状況変化への対応を想定し、開発・運用を一体化した継続的ライフサイクルプロセスを導入することが必要となる場合が多い。

 1.5.1 リスク回避性
一般に機械学習システムにおいて、「どんなときにでも必ず安全な動作をする」といったような厳密な性質の保証は本質的に馴染まず、機械学習要素単体だけではシステム全体に必要の利用時品質を達成できないことも考えられる。

 1.6.4 外部環境の複雑性への対応限界
路上や公共空間などの開放環境でいわゆるサイバーフィジカルシステムの一部として組み込まれる形態も多くあり、全ての環境条件において期待通りの判断を行う事は、極限的な状況も含めると不可能である。この問題は本質的には、機械学習に依らず、開放環境で動作する装置やソフトウェア全般に共通する問題であり、従来の信頼性工学関係の規格においても、例えば IEC 629986などがこの問題に多かれ少なかれ対応しようとしていると考えられる。
2021/6/21

2021年度 技術活用部会活動
一緒に議論、検討していただけるメンバーを大募集中です。
OSDを理解するには、具体的な事例で考えるのは大変役に立ちます。
masamichi.nakagawa@deos.or.jp までご連絡ください。
実施日・時間奇数月のDEOS運営会議終了後（通常、17～19時）①IEC62853の開発文書とのマッピングWorking Group
目的: 展開・普及へつながるアウトプットを生み出す
参加: 情報収集ではなく、作業する会員メンバ限定

内容※会員の方で、参加希望の方は随時連絡ください
2021年度、まずはAI品質保証に関する適用を中心に議論予定②上記①の活動成果報告（年数回）
参加者① 作業に参加して頂ける会員メンバ② 会員メンバは誰でも参加可能

開催場所

WEB会議形式 (状況に応じて運営会議の実施会場）