IEC 62304 実践ガイドブック概説(4)－サプライヤにこそ必要なIEC 62304－

本題にはいる前に，DeNA が運営するインターネットサイト WELQ（ウェルク）がちまたで話題になっていることを取り上げようと思う。

WELQは，サイトで化粧品や健康食品について，効果・効能が保証されているかのような記事を掲載していた。

WELQは，インターネット上の他のサイトに書かれた記事を引用していた上に追加・修正まで加えてしまっていたのだそうだ。医師が書いた元の記事に，シロウトのライターが文章を書き加えて，その医師の名前のままで記事を出していたりしたらしい。テレビで記事を引用された医師が「自分が書いていないことが書き加えられて引用されている」と怒っていた。

人によっては，大量の記事の追加・修正は，人間のライターではなく，AIソフトウェアにやらせていたのではないかと疑う人もいる。

【Yahoo! Newsから引用　「ＤｅＮＡ「ウェルク」都が聴取…誇大広告の疑い」】

ＩＴ大手ディー・エヌ・エー（ＤｅＮＡ）が運営し、記事が不正確だったなどとして公開中止とされたインターネットサイト「ＷＥＬＱ（ウェルク）」について、東京都が医薬品医療機器法（旧薬事法）違反（誇大記述・広告）の疑いがあるとして、調査を始めたことがわかった。 

　５日に同社の担当者から聴取した。 

　都が問題視しているのは、同サイトで、特定の化粧品や健康食品について、効能や効果が保証されているかのような記事が掲載され、商品の購入ページに移動できる仕組みになっていた点。都は誇大な広告とみなせる記事が多く、記事の作成経緯などを調べる必要があると判断した。

【引用終わり】

WELQで問題問題視されているのは，大量の記事の引用で構成されていたというモラルの問題よりも，化粧品や健康食品について，効果や効能が保証されているかのような記事を書いたことが，医薬品医療機器法（旧薬事法）に抵触する可能性があるという点だ。

医薬品医療機器法（旧薬事法）では健康や医療について届け出をせず効果・効能を触れ回ると法律違反になる。医薬品医療機器法は，一見，薬事申請をする人達が守らなければならない法律のように思われるかもしれないが，実はそうではなく，薬事申請をしない製品の広告にも縛りをかけていることを一般の企業は知っておく必要がある。

医薬品は医療機器の製造業者は，医薬品医療機器法が広告規制をしていることを良く知っているので，薬事申請していない効果，効能について吹聴するようなことはしない。

医薬品医療機器法（旧薬事法）の広告規制を知らずに，たまに間違いを侵すのは，医薬品医療機器法（旧薬事法）に接する機会がない一般の企業だったりする。

このことは，薬事申請をしていないヘルスアプリついても同じことが言える。薬事申請をしていないヘルスアプリが，「○○を診断できる」とか「○○の疑いを発見できる」とか「○○の改善に効果がある」といった宣伝をすると医薬品医療機器法違反になる可能性がある。○○に病名を入れるとアウトになる可能性が高い。例えば○○に睡眠時無呼吸症候群と入れるとアウトの可能性が高く，病気とはいえないいびきとするとセーフの可能性が高い。解析アルゴリズムが同じであっても，病気を診断できるとか，病気の改善に効果があることを，薬事申請していない製品が広告することを医薬品医療機器法は禁じている。

医師の資格を持った先生に監修してもらったとしてもダメだ。ヘルスアプリとしての効果・効能をはっきりうたいたいのならば，医療機器プログラムとして薬事申請するしかない。その際，「診断できる」というならば，既存の承認製品との同等性を主張するか，独自の臨床評価が必要になる。

人の健康に関連する商品の広告は，病気や健康に不安を持つ人にとって本当ならすがりたい情報になる。だから，その効果・効能に根拠の裏付けがないと国民に不利益をもたらすので国は規制をするのだ。

だから医療機器に搭載されるソフトウェアやそのものが医療機器となるソフトウェア製品に対しても，その安全性を示すための根拠を求める。そのライフサイクルプロセスに関する要求が IEC 62304 だ。

医療機器の製造業者の多くはソフトウェアの一部または全部を外部の協力会社（=サプライヤ）に開発委託しているだろう。

つきあいの長いサプライヤならば，そのソフトウェアが現場でどんな使われ方をしているのか知っているかもしれない。しかし，サプライヤのソフトウェアエンジニアには医療現場をよく知らない者もいるだろう。

だから，医療機器のソフトウェアは，使われる場面を知っている者がバリデーションしなければならない。

ちなみに，2016年10月に IEC 82304-1 ヘルスソフトウェア－第1部：製品安全に関する一般要求事項 という規格が国際規格として公開された。（アイイーシーハチニイサンゼロヨンダッシュワンと呼ぶ）

IEC 82304-1 のプロセスは左図にようになっていて，ソフトウェアライフサイクルプロセスについては IEC 62304 を抱え込むようになっている。

IEC 82304-1 のスコープであるヘルスソフトウェアは

HEALTH SOFTWARE
software intended to be used specifically for managing, maintaining or improving health of individual persons, or the delivery of care.

（参考訳）個人の健康を管理，維持若しくは改善するために又は医療を提供するために使用することを意図するソフトウェア。

となっていて，非常に範囲が広い。汎用ITプラットフォーム上で動作するソフトウェアという条件が付いているが，規制対象の医療機器ソフトウェアだけでなく，規制対象外のヘルスアプリも対象となる。

IEC 82304-1 の附属書A には下記のようなソフトウェアが In Scope の例として示されている。

In Scope の例（規制対象と規制対象外含む）

• 健康用途のソフトウェア製品
• 特別なセンサや検出器を使わない機器で動作するモバイルアプリ
• 検査情報ソフトウェア
• 放射線科情報ソフトウェア
• フィットネスセンターの個人用ソフトウェア
• 受胎調節ソフトウェア
• コンピュータ支援診断ソフトウェア
• 医療画像解析ソフトウェア
• 個人の診断，治療及び健康管理を目的とする臨床診断支援ソフトウェア
• 電子カルテシステムを含む，電子健康記録システム
• 病院情報システム

規制対象外のヘルスソフトウェアが IEC 82304-1 に適合しなければいけない縛りはないが，それも世の中が IEC 82304-1 をどのように認知するかによっては，ヘルスアプリメーカにとって強い努力目標となるかもしれない。

なお，単独の医療機器ソフトウェアは，いずれ，この IEC 82304-1 への適合を証明することが要求されるようになる。IEC 82304-1 はソフトウェアライフサイクルプロセスについて IEC 62304 を引用しているので，ここでも IEC 62304 要求を実施する必要がある。

IEC 82304-1 では IEC 62304 には含まれていないバリデーションの詳細な要求が書かれている。

さて，サプライヤは医療機器製造業者からソフトウェア開発の一部のプロセスを委託されているだけだから，IEC 62304 の要求内容を知らなくてもいいのかといえばそうではない。

バリデーションは医療機器製造業者がやらないといけないとしても，IEC 62304 の多くのプロセスがサプライヤに委託されているのならば，サプライヤも IEC 62304 の要求内容を理解していなければ，最終的に規制当局に規格要求を満たしていることが説明できない。

EUでは，MDD（医療機器指令）がMDR（医療機器規制）に格上げされつつある。MDRになると，NB（Notified Body）と呼ばれる第三者認証機関は，非通知審査（Unannounced Audits）を実施することになっている。

非通知審査の対象は医療機器製造業者だけでなく，ソフトウェアのサプライヤも対象になる可能性がある。

ようするに抜き打ちで医療機器製造業者のソフトウェアサプライヤが監査される可能性があるのだ。最初のうちは，ソフトウェアを審査できる人もそうはいないだろうが，審査サイドの規格教育が進んでくれば，あちこちでソフトウェアサプライヤが審査されるようになるかもしれない。

医療機器ソフトウェアをはじめて薬事申請しようと考えている新規参入企業も同じだ。IEC 82304-1 の要求内容を理解しておく必要もあるし，IEC 62304 は自分達はもちろん，サプライヤにも教育しておかないといつ来るかわからない審査や査察に耐えられない。

P.S.

今，Amazon で IEC 62304 実践ガイドブックの なか見！検索 で，ガイドブックの付録のかなりの部分が見られるようになっている（自分だけか？） FDAやCFDAの医療機器ソフトウェアに対する規制要件の内容を見ることができる。

IoTというバズワードに踊らされている方々へ

IoTとは、「ありとあらゆるモノがインターネットに接続する世界」 らしい。ネットワークはすでに整備・構築されているので，センシングしたデータや入力した情報をつなげることで新たなサービスを提供するという発想だろう。

ちなみに，そのサービスにはクラウドかどうかは別にして情報を集約するデータサーバーが不可欠だ。だとすると，サーバーのメインテナンスやサービスソフトウェアのアップデートの管理費用がかかる。

IoT のビジネスの例として，BtoB で人的負荷の軽減によりコストダウンを計ることができると言う。でも，それってすでにかなりの分野でやっていることではないだろうか。

例えば，自動販売機の中のジュースや缶コーヒーがなくなると販売の機会損失となるので，サービス員が品物が切れていないかとうか見回ることになる。でも，その見回り作業はすでに，PHSやG3のモジュールに置き換わっている。IoTというキーワードが出てくる前から実現していたサービスだ。

また，消費者がお金を払うシーンではポイントカードがトリガーになって情報は集約され分析されている。これも，IoT 以前に確立していたサービスだ。

いまさら，BtoB の IoT で儲かりビジネスがざくざくあるようには思えない。BtoB の IoT は所詮マイナスをゼロに近づける取り組みであり，ビジネスの拡大には劇的に貢献するようには思えない。

そして次に考えるのがBtoBではなく，BtoC のIoTで儲かるサービスがあるのではないかということだ。

この分野で誰しもがこれは儲かるのではと考えるのが「健康に関する IoTサービス」ではないかと思う。

「健康に関する IoTサービス」に関連して，つい最近，気になるお知らせが来た。

2016.10.04　ウェルネスリンクサービスの終了について　

自分はオムロンの体重体組成計と血圧計でウェルネスリンクサービスを使っているので，このお知らせを見て「おいおい，それが売りで買ったのにサービス終わっちゃうのかよ」とギョッとした。

このお知らせの内容は分かりにくいのだが，どうも，オムロンは OMRON connect　をやめるのではなく， アプリを提供しているドコモヘルスケア（株式会社NTTドコモ　66％, オムロン ヘルスケア株式会社　34％）は，ダイエット用のアプリなどとっちらかっている複数のサービスをわたしムーヴとカラダのキモチに集約しようとしているようだ。

察するに，docomo と2者で運営してきたドコモヘルスケアのサービスは収益があまり上がらないので，アプリを統廃合して赤字にならないようにメインテナンス費用を圧縮しようとしているのではないだろうか。

一方で，オムロンのサイトに 11月1日から OMRON connect　サービスが拡大するといニュースが上記のニュースとは別に掲載されている。こっちには Apple の Healthcare にも対応と書かれている。

docomo と オムロンの Exclusiveな関係では，サービスを黒字化することが難しくなってきたので，健康データの二次利用を希望する会社に開放して活路を見いだそうとしているのではないか。

実は，消費者がヘルスアプリやウェルネス機器に払うお金はそんなに多くないのではないか。ウェルネスとかヘルスケアと聞くと誰もがそのためなら金を出すという印象があるようだが，実際にはそうではないと思う。

病気の人は病院に行く。病院では健康保険によるバックアップがあるものの多大な経費になやまされていて経営に皆苦労している。

だからこそ，治療効果が高い，または，入院期間が短縮できる投資は積極的に行う。逆に言えば効果が見えない，入院期間の短縮に貢献するのかしないのか確証がないものには積極的には投資しない。

大事なのは「効果があるのかないのか」だ。患者からすれば，そこに自分の命がかかっているし，病院からすれば経営の継続がかかっている。そういったもにには金を払う。

だから，治療効果の明白な機器やサービス，医薬品は売れる。そこが曖昧な製品，サービスは売れない。

病院の中でさえ，そうなのに，一般消費者が効果が明確でない健康サービスにお金を払うだろうか。

医薬品医療機器法（旧薬事法）は広告規制があるので，医療機器として申請をしていない製品やサービスが診断・治療に対する効果効能を広告すると法律違反になる。プラズマクラスター付きの加湿器が風邪の予防に効果があると広告して売ったら違反だ。ウイルスを殺す効果を悪戯に強調するのも，かなり黒に近いグレーだ。

シャープのこのページを見て欲しい。消費者がイメージするウイルス防止といった印象とはかなり違うトーンの説明と感じると思う。これが医薬品医療機器法の広告規制を考慮した表現である。

だから，薬事申請していない製品やサービスが診断・治療に関する効果効能を広告することができない。そうなると，消費者への訴求が弱い表現となる。

BtoC の IoT サービスを成功させるには，規模の大きい情報サービスの準備と，サーバー保守費用を捻出するための，サービスに対する対価を回収するしくみが必要だ。

IoT 機器は1回売ったら利益はそれだけなので，問題は IoT を使ったサービスでペイするかどうかがポイントになる。

自分は，多くの消費者は IoT サービスに直接は金を払わないと思っている。インターネットの利用者は情報はタダで手に入るという感覚が染みついてしまったからだ。

よっぽどのことがないと，インターネット利用の消費者は情報やサービスには金を払わない。そう考えると，一般消費者から直接お金を回収するのではなく，広告を表示することで，公告主からお金を回収している Google や Facebook は上手いと思う。

情報サービスは裏方であり，結局は物が売れることで儲かるしくみにつなげることができないと利益につながらないのではないかと思う。

BtoC領域ではつながることによって得られる情報はタダという認識がある以上，IoT絡みの新規サービスの立ち上げにはリスクが伴う。

IoT の機器を売って，また，IoT絡みのサービスで儲けようと考えている方達，他のバズワードが辿った運命と同じように IoT のブームもあと何年かかもしれない。

少なくとも，ありとあらゆるモノがインターネットに接続することが大事なのではなくて，つなげて提供するサービスやそのサービスを利用する物販が，サービスを維持する費用を上回る価値を生み出せるのかどうかなんだと思う。

IoTの場合，単純な物販とは違って，サービスを提供するための初期投資が大きく，いったんはじめてしまうと簡単にはやめられない（物の販売のように在庫無くなったら終わりとはならない）だけに，リスクが大きいビジネスだと思う。

IoT というバズワードに踊らされて火傷しないように。

IEC 62304 実践ガイドブック概説(3)－これだけでも価値ある「付録」－

IEC62304実践ガイドブックには7つの付録が付いている。これらの付録は海外に医療機器を輸出する組織にとっては価値のある情報である。

この付録だけのためにガイドブックを買ってもいいのではないかとさえ思う。

付録の1～4までは米国FDAが発行する医療機器ソフトウェア向けのガイダンスの邦訳，付録5が中国CFDAのガイダンスの邦訳，付録6と付録7がIEC 62304に関連した比較表である。FDAガイダンスは原文（英語）はFDAのWEBサイトで無償で閲覧できる。

IEC 62304 実践ガイドブック 付録一覧

No.	原文タイトル	参考和訳タイトル	発行日
付録1	General Principles of Software Validation; Final Guidance for Industry and FDA Staff	ソフトウェアバリデーションの一般原則	2002年1月11日
付録2	Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices	医療機器における既製（OTS）ソフトウェアの使用に関するガイダンス	1999年9月9日
付録3	Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices	医療機器に含まれるソフトウェアのための市販前申請の内容に関するガイダンス	2005年5月11日
付録4	Cybersecurity for Networked  Medical Devices Containing Off the-Shelf (OTS) Software	市販(OTS)ソフトウェアを含むネットワーク接続医療機器のサイバーセキュリティ	2005年1月14日
付録5	医疗器械软件注册技术审查指导原则	医療機器ソフトウェア申請技術審査指導原則	2015年8月5日
付録6	IEC 62304:2006の Amd1:2015 における追加・修正部分一覧表
付録7	IEC 62304/米国FDA/CFDAソフトウェア要求比較表（目安とするための参考資料)

FDA が発行するガイダンスは下記 Point 10.5 で紹介されているように，「適用される法的要件及び規制要件を満たすものであれば，代替的アプローチを用いて構わない」と説明されているが，FDAの監査官はこれらのガイダンスについて教育を受けているので，ガイダンス通りでなければ当然照会（質問）が来る。ガイダンスの要求内容と提出書類にギャップがある時には「あなたはガイダンスを読んでいるのですか？」と突っ込まれることもある。「アメリカに医療機器を輸出したいのなら，ガイダンス読んでいるのは当然だろ」ということだ。

IEC 62304 実践ガイドブック 「Point 10.5　　FDAガイダンスの拘束力」より引用

FDAのガイダンスのほとんどに下記のような但し書きが書かれています。これは，ガイダンスの書かれた要求が絶対条件ではなく，代替的アプローチがあればそれを用いても構わないということを言っています。 

本ガイダンスは食品医薬品局（FDA）のこのテーマに関する現在の考えを表すものである。これは何人に対してもいかなる権利を生じるもしくは付与するものではなく，またFDAまたは国民を拘束するために機能するものではない。適用される法的要件および規制要件を満たすものであれば，代替的アプローチを用いて構わない。代替的アプローチについて協議したい場合は，本ガイダンスの施行を担当するFDAスタッフに連絡されたい。 

だから，上記のように書かれていても，FDA が発行するガイダンスは従っていないと許認可が遅れるので，実質的には規制要件だと考えておいた方がよい。

そう考えると 米国に医療機器を輸出するのならば 付録3 の「医療機器に含まれるソフトウェアのための市販前申請の内容に関するガイダンス」を隅々までよく読んで，このガイダンスの通りに必要な書類を準備しておく必要がある。

一方，付録5 は 中国の規制当局であるCFDA が発行する「医療機器ソフトウェア申請技術審査指導原則」の参考和訳で，構成は付録3の米国FDAの市販前申請ガイダンスとよく似ている。

CFDAは，米国FDAの医療機器ソフトウェアの市販前申請の方法を下敷きにしており，米国のやり方に中国独自の条件を追加している。どちらのガイダンスもその通りにドキュメントが準備できていなければ，何回も照会されて審査が長引いてしまう。

付録3 と 付録5 は米国と中国の医療機器ソフトウェアの市販前申請に対する要件なので，特に重要な情報と言える。

ちなみに，医療機器の輸出を考えている企業の頭痛の種は，各国の規制当局が課す医療機器ソフトウェアに対する要件がそれぞれ微妙に違うという点だ。

IEC 62304 が国際規格だから，これに従っていればいいのかと言えば，そうはいかない。米国FDAも中国CFDAも，要求が少しずつ異なっている。

中国では2012年04月28日にCMDE（医療機器技術審査センター）が医療機器ソフトウェア登録基本要求を策定し，この中でソフトウェアのバージョンを変更したら，申請もやり直しというルールを作り，世界中から批判を浴びた。そこで，2015年8月5日に，CFDA（国家食品薬品監督管理局）が医療機器ソフトウェア登録技術審査指導原則を発行して，このルールを変更した。変更に際しては中国独自の判断基準を設けている。

なお，米国FDA は IEC 62304 を認知規格としているものの，実際すべての監査官，査察官が IEC 62304 を熟知しているかといえばそうではない。FDAガイダンスの方を重点的に教育されている。

当然だが，米国にとっては，米国の規制当局が発行するガイダンスの方が国際規格よりも優先なのだ。

だから，各国に医療機器を輸出する企業は，国際規格と各国のガイダンス要求の差異を認識した上で，それらの最大公約数のドキュメントを用意して各国の規制に合わせて提出書類をアレンジしなければならない。

そのとき，ガイドブックに付いている 付録7 の IEC 62304/FDA/CFDA 要求の比較表が役に立つ。

また，IEC 62304 は 2006年の初版と 2015年の 追補1 版が現存する。2006年の初版で組織内の手順を構築してきた場合，追補版で何が変わったのかその差分を認知した上で，手順の変更検討する。ちなみに IEC 62304 Amd1 は IEC 62304:2006 からの移行に関して期限のようなことは一切書いていない。現時点は，各国とも移行期限を通知していないので，いつまでに移行しなければいけないのか明確な締め切りは今のところない。

ただし，EUや日本が採用している医療機器に基本要件では下記のように「最新の技術に基づく開発ライフサイクルに従い・・・」　とあるので，いずれは IEC 62304 Amd1 の方をベースにした手順にすることが必要になると思われる。

12.1a.   For devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into the account the principles of development lifecycle, risk management, validation and verification

このとき役立つのは 付録6の「IEC 62304:2006の Amd1:2015 における追加・修正部分一覧表」だ。

付録6 は追加・修正部分だけでなく，Amd1 の目次全部が掲載されているので，これ自体をIEC 62304 Amd1 の要求が網羅されているかどうかのチェックシートとすることもできる。（Excel版は，JEITA ヘルスケアインダストリ事業委員会/医療用ソフトウェア専門委員会に参加すると入手できる）

ちなみに，付録1 のソフトウェアバリデーションの一般原則 はガイドブック上で30ページの大作となっており，これを原文で読むのはなかなか大変な量の文章だ。このガイダンスは 2002年に最後の改訂がされており，FDA のソフトウェアバリデーションに対する考え方が書かれている。

ガイダンスが対象としているのは，製品に搭載するソフトウェアだけでなく，医療機器を製造したり，検査する際に使うソフトウェアのバリデーションも含まれている。この考え方は ISO 13485:2016(医療機器－品質マネジメントシステム－規制目的のための要求事項)にも新たに取り入れられた。

US FDA は世界に先駆けて医療ソフトウェアに関するガイダンスを発行し，運用の実績を根拠に，ガイダンスの要求内容を国際規格に反映させてグローバルスタンダードにするという戦略を着実に実行している。

IEC 62304 実践ガイドブック概説(2)－ガイドブックの目次と読み方－

IEC 62304 医療機器ソフトウェア－ソフトウェアライフサイクルプロセス は，IEC（International Electrotechnical Commission：国際電気標準会議）から発行されている国際規格で 初版が2006年に 追補版である Amendment 1 が2015年に出ている。

英語/フランス語版はIEC のWEBサイトで，IEC 62304:2006 を JIS化した JIS T 2304：2012年 はJSA WEBストアで購入できる。ちなみに，JISの番号がなぜ 62304 ではなく，2304なのかと言うと，その当時 JIS の番号は4桁が基準で特例以外は4桁にさせられていたからである。今では5桁が使える。

IEC 62304:2006 は IECのWEBストアで290スイスフ,ラン（IECの本部がスイスにあるのでスイスフラン，290スイスフランは約3万円）　IEC 62304:2006 Amd1:2015 は158スイスフラン（Amd1は修正点のみ記述，158スイスフランは 約1万6千円）で買うことができる。

JIS T 2304:2012 は JSA WEB ストアで 4320円で購入できる。 JIS T 2304 の追補1 は現在 JIS 化が進められており，来年には発行されると思われる。

国際規格を規制への適合目的で使用する場合は，必ず規格の原文を入手しておく必要がある。また，JIS版があるからといって JIS だけを買うのではなく，必ず IECやISOの規格も買うことを推奨する。

その理由は，JIS版の日本語では曖昧な点，もしくはよく分からない所については IECやISOの英語の原文を読むとはっきりすることがあるからだ。

例えば，英語では shall と should では，shall の方が「しなければならない」という強制力があるが，日本語にするとどちらも「する」になっていることがある。

IEC 62304 実践ガイドブックを規制への適合目的に使うのであれば，必ず 規格の原文を横においていつでも規格の文言がどうなっているのかを確かめられるようにしておくことを強く推奨する。

IEC規格をJIS化する場合、正確に伝わるように日本語を選ぶのだが、意訳したりむやみに注釈を追加したりはできず、できる限り原文に近い日本語にするため、どうしても意味がストレートに伝わらないことがある。そういった意味が通りにくい部分の解釈を国際規格を検討してきたエキスパートたちの言葉で伝えるという目的もこのガイドブックにはある。

IEC 62304 実践ガイドブックの読み方

IEC 62304 実践ガイドブックは 基本的には IEC 62304:2006 と IEC 62304 Amd1:2015 の規格要求事項の解釈や解説を目的としているが，規格解釈以外の情報も含まれているので想定される読者別に IEC 62304 実践ガイドブックのお勧めの読み方（斜め読みの仕方など）を紹介する。

【IEC 62304 や JIS T 2304 をすでに読み込んでいて，規格適合に取り組んでいる方】

IEC 62304 実践ガイドブックは 第3章～第9章が IEC 62304と同じ章構成になるようにしている。したがって，規格原文で分からないところがあったら，その章と同じ章のガイドブックの箇所を読めば，規格が要求している内容の理解が進む。また，ガイドブック側には Point という囲み記事が各所にあるのでそれも参考になると思う。

Point 囲み記事の例

Point 5.7.1　Fail（失敗）が1つもないソフトウェアシステム試験結果 　ソフトウェアシステムの規模が大きく，複雑になればなるほど，ソフトウェアシステム試験の内容も増大します。そうなるとテストを実施した時点で，試験のテストケースの内容や合否判定基準自体に誤りがみつかることもあります。 　また，ソフトウェアを変更すればするほどテストケースも変わる可能性が高いため，ソフトウェアの完成度が高まらないとテストケースもなかなか固まらないという側面もあります。そのため，ソフトウェア結合試験やソフトウェアシステム試験の仕様書を確定させずに，プレ試験をくり返し，すべての試験項目に合格することが確認できた時点で，試験の仕様書を承認し，その仕様書をもとに実施した試験結果を登録するということもあるようです。この場合，ソフトウェアシステム試験の結果にFail（失敗）が1つもなく，すべての試験に合格していることが試験結果となります。 　このようなFail（失敗）が1つもない試験結果は，欧米の監査官，査察官には奇異に映り，本当にテストをしたのかどうかの疑いの目で見られることもあります。 そういったことが起こらないようにするためには，試験の仕様書はある程度，上流から下流に向けて段階ごとに確定させていきます。テストケースは，要求仕様をつくったときに同時に作成してしまう癖を付けておくとよいでしょう。そして，テスト自体は繰り返し実施し，テストで発見された異常は検証の報告書でレポートするようにします。（Point 5.6 参照） 　設計の上流においても下流においても，設計とテストを常にペアで考えていると，合否判定基準を意識するようになり，設計上のもれや抜けを早期に発見することにもつながります。アジャイルソフトウェア開発でテストファーストが推奨されているのも，テストケースの早期作成が検証の効率化のみならず，ソフトウェア設計にプラスの影響を与えると考えられるからです。

次に，第10章の各国の医療機器ソフトウェア規制を読み，第1章のIEC 62304が策定された背景と今後の見通し と 第2章のリスクベースアプローチを読むとよい。

【国内薬事申請担当または，各国規制担当の方】

まず，第1章のIEC 62304が策定された背景と今後の見通し と 第10章の各国の医療機器ソフトウェア規制 を読み，次に第2章のリスクベースアプローチ を読んで，ソフトウェア起因の事故の再発防止が目的で規格が作られていることを理解し，米国や中国に医療機器を輸出しているまたは，これから輸出するならば，付録のFDAやCFDAのソフトウェアの関するガイダンスの邦訳を読む。

【医療機器ソフトウェアのサプライヤ】

医療機器ソフトウェアのサプライヤは，医療機器製造業者からソフトウェア開発を委託され，ソフトウェアを供給するソフトウェアハウスだ。よって，医療機器性業者がIEC 62304 を規制目的で採用しているならば，規格の内容を理解している必要がある。よって，規格原文とガイドブックの第3章～第9章に目を通し，自分達が委託されているソフトウェアの開発プロセスの要求部分を詳細に読むとよい。

また，それらの規格要求がどのような背景で作られていったのかと知るために，第1章，第2章を読む。また，第10章の各国規制の章を読めば，医療機器性業者がどんな規制を受けているのかが分かる。

【医療機器ソフトウェアの業務ドメインへの新規参入者】

規制が求められる医療機器や医療機器ソフトウェア，また，規制対象外のヘルスソフトウェアの開発者製造業者で，将来規制対象の医療機器や医療機器ソフトウェアを開発したいと考えている方は，第1章で規格制定の概要と 第2章のリスクベースアプローチ と 第10章の各国規制についてまず読み，次に第3章～第9章の規格要求の解説を読むとよい。

【医療機器ドメイン外でソフトウェア規制について興味がある方】

医療機器ドメイン外でソフトウェア規制について興味がある方には，是非 第1章の IEC 62304が策定された背景と今後の見通し と 第2章のリスクベースアプローチを読んで欲しい。

第2章の リスクベースアプローチは 1980年代の発生したソフトウェア起因の医療機器の事故から米国FDAが医療機器ソフトウェア規制の乗りだし，さらにその後も発生し続けているソフトウェア起因のインシデントやアクシデントは，どうしたら防ぐことができるのかという再発防止のために，IEC 62304 が作られたという背景を知って欲しい。

一言で医療機器といっても多種多様であるため，一つの対策，一つの方法論では安全を確保することはできないということが，医療機器業界では共通認識となっている。この多様性の中で培ってきた安全を実現するためのリスクベースアプローチは今後，ITイノベーションが進み限られた機能から多様な機能へ変異するさまざまな業界において，利用者から安全が求められるシーンがあるなら必ずや参考になると思う。

第2章のリスクベースアプローチを理解した上で，第3章～第9章の IEC 62304 の要求を読み進むと，なぜ，そのような要求になっているのかが分かると思う。

※IEC 62304 と機能安全と同じだと勘違いしている人には，第2章と第10章をよく読んで欲しいと思う。

目次	概要
第1章　IEC 62304が策定された背景と今後の見通し	IEC 62304 が策定された背景や，Amd1 の変更点，関連する規格 IEC 80001シリーズや IEC 82304-1 の規格を紹介している。
第2章　リスクベースアプローチ	放射線治療器 Therac-25 の事故でソフトウェアの何が影響したのか，また事故から学ぶ教訓とはなにか。安全（セーフティ）の概念とは何か，米国のヘルスITに対するリスクベースアプローチの考え方を紹介。 ※本章の記事は，現MIT教授ナンシー・レブソンらが1980年代に書いた論文（An Investigation of the Therac-25 Accidents）を元にソフトウェア設計の観点で再分析した。
第3章　IEC　62304で使われる用語の解説	第3章～第9章までは IEC 62304 Amd1 の章立てに対応しており，IEC 62304 の規格の横に本書を置いて，規格要求の意味を知るためのリファレンスとして使用する。 ところどころに Point の囲み記事を配置し，より突っ込んだ解釈・解説をしている。
第4章　IEC　62304の一般要求事項
第5章　ソフトウェア開発プロセス
5.1　ソフトウェア開発計画 5.2　ソフトウェア要求事項分析 5.3　ソフトウェアアーキテクチャの設計 5.4　ソフトウェア詳細設計 5.5　ソフトウェアユニットの実装 5.6　ソフトウェア結合及び結合試験 5.7　ソフトウェアシステム試験 5.8　システムレベルで使用するためのソフトウェアリリース
第6章　ソフトウェア保守プロセス
第7章　ソフトウェアリスクマネジメントプロセス
第8章　ソフトウェア構成管理プロセス
第9章　ソフトウェア問題解決プロセス
第10章　医療機器のソフトウェア規制	医療機器ソフトウェアの各国規制について説明
10.1　医療機器の各国規制について 10.2　IMDRFが定義するSaMD 10.3　IMDRF参加各国のIEC 62304：2006に対する考え方 10.4　医療機器ソフトウェアの各国規制の状況 10.5　医用電気機器安全通則から参照されるIEC 62304 10.6　米国FDAの医療機器ソフトウェア規制 10.7　EUの医療機器ソフトウェア規制 10.8　中国の医療機器ソフトウェア規制 10.9　日本の医療機器ソフトウェア規制	各国の医療機器規制当局が集結する IMDRF の動きと現在までに IMDRF が発行するドキュメントを紹介。米国，EU，中国，日本の医療機器ソフトウェアの規制状況について解説している。医用電気機器安全通則と IEC 62304 の関係についても説明。
付　　　録
1　ソフトウェアバリデーションの一般原則（製造業者およびFDAスタッフのための最終ガイダンス） 2　医療機器における既製（OTS）ソフトウェアの使用に関する企業，FDA 審査官および適合性のためのガイダンス 3　医療機器に含まれるソフトウェアのための市販前申請の内容に関する ガイダンス 4　市販（OTS）ソフトウェアを含むネットワーク接続医療機器のサイバー セキュリティ	米国FDAが発行するソフトウェア系のガイダンス4種の参考和訳を掲載。原文は公開されているものの，邦訳は貴重。
5　 医療機器ソフトウェア登録技術審査指導原則	中国CFDAが2015年に発行した医療機器ソフトウェア登録技術審査指導原則の邦訳版を掲載。本内容は中国にソフトウェアが搭載されている医療機器を輸出する際には申請の要件となるため，必読の内容となる。
6　 IEC　62304：2006のAmd　1：2015における追加・修正部分一覧表 7　 IEC　62304／米国FDA／CFDAソフトウェア要求比較表（目安とするための比較表）	IEC 62304 Amd1 の要求と FDAが発行するソフトウェア系ガイダンス，中国CFDAの要求の違いを比較表で示した。また，IEC 62304:2006 と IEC 62304 Amd1:2015 でどこが変わったのかも付録6の表で確認することができる。

IEC 62304 実践ガイドブック概説(1)－ガイドブックを編纂した背景－

IEC 62304 実践ガイドブックの概要

IEC 62304 （医療機器ソフトウェア－ソフトウェアライフサイクルプロセス－）の実践ガイドブックがJEITA ヘルスケアインダストリ事業委員会/医療用ソフトウェア専門委員会 編纂で2016年9月28日予定で出版される。（現在はAmazonで予約受付中）

このガイドブックが編纂された背景を紹介する。下記の 本の内容紹介が簡潔で分かりやすいので引用する。

【Amazon 内容紹介より】

2017年11月より実質的な規制要件となるIEC 62304（JIS T 2304）の現場レベルでの解釈、および各国の医療機器ソフトウェア規制要求をまとめたガイドブック！
日本国内において、2017年11月より、IEC 62304（医療機器ソフトウェア ‐ ソフトウェアライフサイクルプロセス）への適合が医療機器ソフトウェアの実質的な規制要件となります（医療機器の基本要件基準 第12条2。現在は経過措置期間中）。しかし、IEC 62304のJIS版であるJIS T 2304を読んだだけでは、要求の背景や意味がわからず、具体的にどのような対応をとればよいのか不明な部分も多くあります。
本書は、JEITAヘルスケアインダストリ事業委員会／医療用ソフトウェア専門委員会の活動成果の集大成であり、IEC 62304（JIS T 2304）の策定に携わったエキスパートらが直接、本規格の要点と対応のコツをわかりやすく解説した実践書です。
規格本文と付属書からだけでは読み取りにくい事柄や、欧米のソフトウェア開発と異なる文化をもつ日本の医療機器ソフトウェア開発において、本規格を適合させるためのヒントと各国の医療機器ソフトウェア規制の内容を紹介しており、今後、規制対象の医療機器ソフトウェアの開発に携わるソフトウェア技術者にとって必修の内容をコンパクトにまとめています。

◇本書によってIEC 62304の求める要件について的確な理解が得ることで、スムーズに適合を示すことが可能になります。
◇日本、EU、中国、米国の医療機器ソフトウェア規制要件とそれらの違いがわかります。
◇医療機器ソフトウェアが規制されるようになった背景と今後の国際規格の見通しがわかります。
◇医療機器ソフトウェア業界へ新規参入する企業や医療機器製造業者へソフトウェアを供給するサプライヤにとって最適なガイドとなります。

医療機器ソフトウェアの規制要件について

医療機器ソフトウェアは世界各国で法規制の対象となるソフトウェアだ。規制の対象になっている理由は2つある。一つは診断・治療・予防に対する有効性を担保する必要があることと，二つ目は医療機器としての安全性を担保する必要があり，国は国民のために医療機器の安全性や有効性が保たれていることを確認し監督しなければならないからだ。

安全性や有効性の確認や監督といった堅い責務とソフトウェアという柔らかい対象物は相性がいいとは言えない。ハードウェアについては安全性や信頼性の試験で担保できるものでも，ソフトウェアの場合は（簡単に変更できてしまい，かつ問題が分かりにくいという意味で）ふわふわしているため，こうすれば大丈夫という決めてがない。だから，プロセス規格によって間接的に安全性や信頼性を担保しようとする。

ソフトウェアは柔らかく締め付けがしにくいが，それでもいろいろな製品の中で中心的な役割を果たしつつあり，業務ドメインによっては，国民の安全のために規制をしなければいけないところまで来ている。

ちなみに，自動車業界において話題になっている機能安全規格 ISO 26262 は，現在，どの国においても法規制に使われてはいない。国際規格もたくさんあるが，規制目的で使用されているかどうかの切り分けはとても重要だ。規制目的に使われるには，それなりの背景や理由がある。規格の利用者はその背景や理由を理解しておく必要がある。

さて，ここまで，IEC 62304 が医療機器ドメインにおいて，規制に使われているかのような書き方をしたが，上記の本の内容説明にあるように正確には「実質的な規制要件」になるというのが正しい。

一体それはどういうことか説明するとこのようになる。

まず，医療機器は日本では薬事法で規制をされていた。薬事法では対象が有体物だったので，無体物であるソフトウェアは規制の対象ではなかった。（医療機器に組み込まれたソフトウェアは以前から規制の対象だったが，現在，汎用プラットフォームに搭載するソフトウェア単体も医療機器と見なすのが一般的になりつつある）

そこで，日本も米国やEUに習って，薬事法が2014年11月25日に医薬品医療機器法（正式名称：医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律，略して薬機法と呼ばれることもある）に変わり，ソフトウェアが法律の中では「プログラム」と称されて医療機器として規制の対象になることになった。

医薬品医療機器法には，旧薬事法時代から　第四十一条第三項 が設けられており，「厚生労働大臣は必要な基準を設けることができる。」となっている。

厚生労働大臣が設ける必要な基準というのが，厚生労働省告示のようなものであり，2014年11月5日に 厚生労働省告示 403号 （医療機器の基本要件）が発行され，次の 2の条件が追加された

第十二条プログラムを用いた医療機器（医療機器プログラム又はこれを記録した記録媒体たる医療機器を含む。以下同じ。）は、その使用目的に照らし、システムの再現性、信頼性及び性能が確保されるよう設計されていなければならない。また、システムに一つでも故障が発生した場合、当該故障から生じる可能性がある危険性を、合理的に実行可能な限り除去又は低減できるよう、適切な手段が講じられていなければならない。

２ プログラムを用いた医療機器については、最新の技術に基づく開発のライフサイクル、リスクマネジメント並びに当該医療機器を適切に動作させるための確認及び検証の方法を考慮し、その品質及び性能についての検証が実施されていなければならない。

この条文の内容は GHTF（現在はIMDRFで各国の医療機器規制当局の連合体）が定めたもので，EUも同様に医療機器の基本要件として採用している。

IEC 62304 実践ガイドブック 10章 「医療機器のソフトウェア規制」より引用

　医療機器の基本要件(Essential Principles of Safety and Performance of Medical Devices Study Group 1 Final Document GHTF/SG1/N68:2012)を策定したのはGHTFです。GHTF は日本，米国，EU，カナダ，オーストラリアといった各国・地域の規制当局及び産業界の代表者が参加して国際的な医療機器規制の整合化と収束を促進するために1992年に創設されました。その後，GHTFは解散し，その役割は2011年に創設された IMDRF（International Medical Device Regulators Forum, 国際医療機器規制当局フォーラム）に引き継がれています。
　現在，IMDRFはGHTFの参加国に新興国も加わり，オーストラリア，ブラジル，カナダ，中国，欧州連合（EU），日本，ロシア，アメリカがマネジメントコミッティを組織し，図10.1にあるようにワーキンググループで活動を行っています。

さて，この厚労省告示 403号の 第12条 2 に書かれている「プログラムを用いた医療機器については，最新の技術に基づく開発のライフサイクルを考慮し，その品質及び性能についての検証が実施されていなければならない」という条件は，すべての医療機器に対して求められている規制要件であるから，要件が満たされていなければ罰せられる。（法律に付随する厚労省の告示の条件であるため）

そして，医療機器ソフトウェアにおける「最新の技術に基づく開発のライフサイクル」に対して，2016年9月現在，存在する国際規格は IEC 62304 しかないため，IEC 62304 が実質的な規制要件になるのだ。

ただし，厚労省告示 403号の 第12条 2 は，IEC 62304 に適合せよ とは言っていない。だから，最新の技術に基づく開発のライフサイクルを採用して，品質及び性能について検証が実施されていると主張すれば，他のライフサイクルプロセスを採用することは可能だ。

しかし，医療機器製造業者の 99.9 % は　IEC 62304 を使って，厚労省告示 403号 第12条 2 に適合していることを示す。医療機器の基本要件への適合を審査する審査機関も IEC 62304 が使われる事になれているため，他のライフサイクルプロセスで要件を満たすのかどうか判断するには相当な時間がかかるだろう。

だから，ほとんど全ての医療機器製造業者が IEC 62304 への適合を示すし，その方が医療機器の薬事申請がスムーズに進む。

こういった背景により，IEC 62304 は実質的な規制要件となっているのである。

なお，2014年11月25日に医薬品医療機器法ができたとき，告示403号 第12条 2 は3年間の経過措置が設けられた。

その理由は開発ライフサイクルの基準を実践するのは，それなりの時間がかかるので IEC 62304 が示すライフサイクルプロセス基準を満たせるようになるための猶予期間が3年設けられたのだ。

だから，3年後の 2017年11月25日からは，医療機器製造業者にとって IEC 62304 への適合が実質的に必須になる。

IEC 62304 は初版が 2006年に制定されており，EUに医療機器を出荷している製造業者は 2006年頃から IEC 62304 の対応を始めているので，焦る必要もないのだが，国内で規制対象の医療機器プログラムを製造している製造業者や，国内の医療機器製造業者にソフトウェアを供給しているサプライヤにとっては，2017年11月25日から日本においても，IEC 62304 が実質的な規制要件になるということはよく理解しておく必要がある。

各国規制当局の IEC 62304 の使用に関する考え方

ちなみに，IMDRF は IMDRF/MC/N35:2015 文書として，IEC 62304 の使用に関する声明を IMDRF 参加各国の規制当局の言葉で下記のように示している。

これにより 各国規制当局の IEC 62304 の扱いに関する考え方が分かる。日本は IEC 62304 を参照していないと書いているが，それは2015年時点のことで，2017年11月25日以降は，経過措置が切れるので，ヨーロッパと同じような考え方になると予想される。

IMDRF/MC/N35:2015 IEC 62304の使用に関する声明

 Statement regarding Use of IEC 62304:2006 “Medical device software – Software life cycle processes”

国・地域	規制当局	説明原文	参考和訳
Australia オーストラリア	Therapeutic Goods Administration (TGA) 保険省薬品・医薬品行政局	All medical devices are required to meet Australian Essential Principles (EPs). IEC 62304 - Software lifecycle process (or equivalent or better) and IEC 62366 - Usability engineering (or equivalent or better) are referenced in the supporting data form and compliance with these standards is used as evidence of compliance with the EPs.	すべての医療機器は，オーストラリア基本原則に適合することが要求されます。IEC62304--ソフトウェアライフサイクルプロセス(または，同等かそれ以上)とIEC62366—ユーザビリティエンジニアリング(または，同等かそれ以上)は申請書フォームで参照され，そして，これらの規格への適合は基本原則への適合の証拠として使用されます。
Brazil ブラジル	National Health Surveillance Agency (ANVISA) ブラジル国家衛生監督庁	All medical devices must meet requirements of safety and effectiveness. IES 62304/2006 may be employed in technical reports (technical dossiers). It is currently not mandatory to be certified on that standard.	すべての医療機器は安全性と有効性の要求を満たさなければなりません。IEC 62304:2006は技術報告書(技術的な関係書類)で使われるかもしれません。現在，この規格の認証は義務ではありません。 ※2016年8月より，IEC 62304:2006への適合が求められるようになる。
Canada カナダ	Health Canada (HC) カナダ保健省	In Canada, conformance to specific standards is not mandatory. However, evidence of conformity to recognized standards can be submitted to demonstrate that specific requirements of the Medical Devices Regulations have been met. HC publishes a list of recognized standards, and the level of evidence expected is “equivalent or better” to these recognized standards. IEC 62304:2006 is currently a recognized standard, and represents an accepted approach to the software development process for medical devices.	カナダでは，特定の規格への適合は義務ではありません。しかしながら，認知規格への適合の証明は医療機器規制の要求を満たしていることを示すために提出することができます。カナダ保健省は認知規格のリストを公開しており，期待される証拠のレベルはこれらの認知規格に対して「同等か，それ以上」です。 IEC 62304:2006 は現在，認知規格の一つであり，医療機器のソフトウェア開発プロセスとして受け入れられているアプローチです。
China 中国	China Food and Drug Administration (CFDA) 中国食品医薬品局	The IEC 62304:2006 had been translated into China industry standard: YY/T 0664-2008 equally and implement from 2009.6.1, it isn’t mandatory standard，and just is recommended standard.	IEC 62304:2006は中国産業標準YY/T0664-2008に翻訳されており，2009年6月1日より実行しています。 この規格は強制規格ではなく推奨規格です。
Europe ヨーロッパ	European Commission (EC)	The corresponding European standard EN 62304:2006 is a European harmonized standard, which provides presumption of conformity with legal requirements on development lifecycle for software which are incorporated in medical devices and software which are medical devices in themselves. The use of this standard (to the extent specified in its Annex ZZ) provides one solution for compliance with the relevant legal requirements. Compliance with the legal requirements can however be ensured also by other means.	対応する欧州規格 EN 62304:2006は，医療機器に組み込まれるソフトウェア及び医療機器としてのソフトウェアが，開発ライフサイクルの法的要求事項に適合しているかを判断するための欧州整合規格です。 関連する法的要求への適合の一つの解決策を提供します。しかしながら，他の手段でも法的要求への適合を示すことができます。
Japan 日本	Ministry of Health, Labor and Welfare (MHLW) 厚生労働省 Pharmaceuticals and Medical Devices Agency (PMDA) 独立行政法人 医薬品医療機器総合機構	IEC 62304:2006 is not referred to so far, but, for example, it may be used for rational explanation through a pre-market application process to satisfy the EPs that align with those defined in GHTF/SG1/N68:2012 Essential Principles of Safety and Performance of Medical Devices.	IEC 62304:2006 は今のところ参照されていません。しかし，市販前申請においてGHTF/SG1/N68:2012医療機器の安全性と有効性の基本要件で定義されている基本要件への適合証明への根拠の説明に使用されるかもしれません。 ※訳注　2017年11月25日以降は実質的に要件となる。

IEC 62304 実践ガイドブックを編纂した理由

「はじめに」より引用

IEC 62304（医療機器ソフトウェア－ソフトウェアライフサイクルプロセス）はEUではすでに，日本では2017年11月より医療機器ソフトウェアに対して実質的な規制要件となります。 

このように，IEC 62304は各国の医療機器ソフトウェアの規制要件として採用されつつあり，対象となる仕向地で医療機器を販売するためには，医療機器ソフトウェアがIEC 62304に適合していることを証明することが求められます。

適合証明の方法として第三者認証機関で試験を受ける場合もあります。IEC 62304は医療機器ソフトウェアの開発や保守についての「プロセス規格」であることから，電気的安全性試験のように，誰が試験を実施しても同じ結果にはならず，規格に対する知識レベルや経験が不十分なために判定結果や見解が変わったり，試験結果に詳細な説明を付け加える必要があったりします。医療機器ソフトウェア開発者にとって規格適合が目的になってしまうと，規格要求事項は形式化，形骸化してしまい，「高品質で安全な医療機器ソフトウェアを継続して製造するための開発プロセスとその要求事項を示す」というIEC 62304の本来の目的から乖離してしまう危険性があります。

また，IEC 62304はJIS T 2304として邦訳版を入手することも可能ですが，規格を読んだだけでは，規格策定にかかわった各国のエキスパートらの議論の過程や意図が読者に十分に伝わらないこともあります。

そこで，IEC 62304や関連する国際規格の策定にかかわったISOやIECの国際エキスパートが中心となり，また，IEC 62304の実戦経験が豊富な一般社団法人 電子情報技術産業協会（JEITA）のヘルスケアインダストリ事業委員会 / 医療用ソフトウェア専門委員会の有志の監修のもと本ガイドブックを作ることにしました。本ガイドブックのコンセプトはIEC 62304の趣旨と要求内容を正確に読者に理解してもらい，IEC 62304の本来の目的である「高品質で安全な医療機器ソフトウェアを継続して製造する開発プロセス」が実践できるようになることです。 

本書の読者には，医療機器の製造業者（薬事担当，ソフトウェア開発担当），医療機器の製造販売業者（薬事担当，QA担当），ソフトウェア開発受託業者や，医療機器ならびにヘルスケア業界への新規参入を目指している方々，さらには未来の医療機器ソフトウェア技術者を育成するアカデミアの方々を想定しています。 

執筆者一同，本ガイドブックが高品質で安全な医療機器ソフトウェア開発の一助となることを願っています。

2016年8月　執筆者一同

今後，このブログサイトでも，少しずつ，本ガイドブックの内容を解説してきたいと思う。

テスラ社死亡事故で考える Intended Use （意図する使用）

GHS（ヘルスソフトウェア推進協議会）のリスクマネジメントトレーニング講座で，Intended Use（意図する使用）が決まっていないとリスク分析はできないと教えている。

Intended Use を決める・定義するということは，製造業者が提供する製品やサービスにおいて，誰が，何を，どのように使うことを意図しているのかを明確にすることである。

日本人の技術者は特にこれが苦手だと感じる。

その理由は，多くの日本の製造業者がすでに市場にある自社製品やライバル会社の製品の機能や性能を模倣・継承して，それらに付加価値として追加することで「売れる」製品を作ることができてしまうからではないかと考えている。

だから，日本の技術者は自分が開発に携わった製品の新たに付け足した機能や性能のことはスラスラと答えることができるのに，その製品の Intended Use （意図する使用）は何かと聞いてもバシッと答えが返ってこない。

こちらが聞いているのは，付け足した付加機能のディテールではなく，基本機能や基本性能を誰のために，何のために作ったのかを答えた欲しいのだが，そういった基本機能・基本性能は，すでに前の機種で実現してしまっていて，再利用するだけなので，付け足し機能しか担当していない技術者の頭の中に残らないのだろう。

しかし，製品やサービスの基本機能や基本性能が故障したり不具合を起こしたりすると，とたんに大問題となる。だから，市場で不具合が発覚してリコールになったりしたときにはじめてそれが製品にとって重大な機能だったのだと気が付いたりする。

GHSのセミナーでは，Intended Use を説明するのにMobile MIM という iPad iPhone のアプリケーションソフトウェアを例示している。

このアプリケーションソフトウェアは，医療機器である画像診断装置のデータをクラウド上に格納し，その画像を iPad や iPhone で閲覧するソフトウェアだ。iPhone を持っている方は，アプリをダウンロードしてサンプル画像を無料で見ることができるので試してみるとよい。

このアプリは，2008年に 米国FDAに医療機器としての申請をしており，3年間に渡るFDAの交渉を経て，医療機器と認められている。

この経緯はアプリのようこその Mobile MIMのストーリーに書いてあるので，読んで見ると面白い。

そして，ユーザーガイドの配下に左記の使用目的が書いてある。

日本語では使用目的となっているが英語モードで表示させると Intended Use だ。

Intended Use には，「何の目的のソフトウェアであるか」「アプリが扱う医療画像は何から得たものか」がまず書かれている。

そして次が大事なのだが，このアプリは医療行為に関わることとして「放射線治療のプランを承認することに使用できる」と書いてある。

そしてさらに重要なのは，このアプリが医療機器である画像ワークステーションに取った代わるように設計していないことと，画像ワークステーションへのアクセスができないときにのみ使用すべきと明示している。

そういった場合であってもマンモグラフィには使用できないと明確に書いている。

ようするに Intended Use を定義した上で，でできることと，できないことをはっきりと書いているのだ。

このような書きぶりは，海外の医療機器では珍しくない。海外の医療機器ではIntended Useの中で，できることと出来ないことがはっきりと書かれている。

米国で特にそういう書きぶりになるのは，できることと出来ないことを明確にしておかないと，その製品で事故が起こったときに，製造業者側の責任分解点が曖昧になるからである。

なお，訴訟対策という意味以外でも，冒頭に書いたように Intended Use が明確になっていないとリスク分析ができない。

Mobile MIM に関して言えば，「放射線治療のプランを承認する」目的での使用は意図しているので，その目的に際して，間違った判定にならないようにリスク分析を行い対策しておく責務が製造業者側に生まれる。

おそらくそのためであろう。このアプリは自然光が強い場所では使えないように，医療用途で使用する場合には，少しだけコントラストを変えたエリアをランダムに表示させて，そこをポイントできないと先に進めないようなくふうがされている。

これは，微妙な輝度の違いを読み取れないような環境でアプリを使うと誤診につながるので，それを回避するためのリスクコントロール手段である。想像するにFDAと何回も Intended Use と想定されるリスクについて議論した末に設定したリスクコントロール手段だと思われる。

そして，何を意図しているのかと同様に「何を意図していないのか」ことも明確に示した。これによって「製造業者が意図していないこと」をユーザーが行った場合は，誤使用となる。医療機器ドメインでは「合理的に予見可能な誤使用」は製造業者の責任でリスクコントロールをする義務があるが，Intended Use で明確に出来ないこと，意図していないことを明示している場合に，ユーザーがそれをやってしまった場合は，よっぽどのことが無い限り，製造業者の意図に反した誤った使い方となる。

日本人がこのような Intended Use を見ると，販売に悪影響がでるのではないかと思うかもしれない。しかし，組織が取扱説明書等で出来ないと書いているのに，セールスの担当者が「公式にはできないと書いてありますが，実際には多くのお客さんがこんな使い方をしていますよ」などとユーザーに耳打ちしていれば，FDAは取扱説明書上に明記された Intended Use と 医療機器の使用の実態との乖離を許さない。

さて，2016年6月30日に米テスラモーターズの「自動運転モード」作動中に初の死亡事故が起きた。（日経記事）

死亡した運転手は自動運転中にポータブルDVDプレーヤーでハリーポッターのDVDを鑑賞していた可能性があるらしい。（ロイター記事）

この記事の中で，下記のように書かれている。

事故車となったセダン「モデルＳ」の２０１５年モデルの運転手が道路を見ていたのかどうかという疑問は、テスラにとって重大な意味がある。同社は、オートパイロットの安全性に関して連邦当局から予備調査を受けている。 　

オートパイロット搭載車は運転しなくても、車線内を走行し、スピードを維持できる。同社は１日に声明を出し、「オートパイロットは路上での最先端のドライバー支援システムだ。ただ、これにより、テスラ車が自律走行車になったり、運転車が責任を放棄できたりするわけではない」との見解を示した。 　

この，「オートパイロットは路上での最先端のドライバー支援システムだ。ただ、これにより、テスラ車が自律走行車になったり、運転車が責任を放棄できたりするわけではない」というテスラモーターズの主張に思い切り突っ込みを入れたい。

テスラモーターズは オートパイロット機能による自動運転を Intended Use として意図しているのか，意図していないのかを明確にしておらず，曖昧なままにして，状況によって都合良く解釈していないかと。

ようするに，ユーザーがオートパイロットに任せきった運転をすることを想定もしくは，黙認しながら，公式には自律走行は許していないとする，2つの顔を使い分けていないかということだ。

こういうことをすると，有効なリスク分析できない。製造業者として意図していることと意図していないことが明確になっていないから，運転手がオートパイロットに運転を任せきってしまうことが，正常使用なのか，明確な誤使用なのか，それとも合理的に予見可能な誤使用なのかがはっきりしない。

自律走行を意図していないのなら，まず，「オートパイロット」で運転手が運転を任せてしまうことは禁忌・禁止として，明確に，常に意識できるようにラベリング（みえるところに表示する）必要があり，かつ，そうしてでも運転を任せきってしまうことは合理的に予見可能な誤使用としてありうると考えて，リスクコントロール手段を講じることが必要だ。

例えば，運転手の視線が前方を向いていなければ警告音を鳴らすといったリスクコントロールだ。

こういったリリスクコントロール手段にはコストがかかるから，やるやらないの判断するためには，組織として承認された Intended Use が必要になる。そこがはっきりしないと，開発の過程で組織の都合のよい解釈が成されて，リスクが残ったまま，製品が市場で使われることになる。

今一度，自動車メーカーに問いたいのは自動車メーカーは「運転手から運転を解放するため」に自動車に自動運転機能を装備しようとしているのではないのかということだ。目標は高く掲げ，社会への貢献を高らかに謳い，「やっちゃえ」と言ってユーザに期待させておきながら，事故が起きると責任は回避するという態度はいただけない。

医療機器の場合，単純化すると，製造業者が「診断」「治療」「予防」を標榜すると医療機器として規制されることになる。支援するとか，補助するとかで，誤魔化すのではなく，左記のようにビシッと線を引くことが Intended Use を定義することになる。

自動運転機能を自動車に装備する目的は「運転からの開放」なのに，事故が起こったときだけ「自動運転はあくまでも運転の補助だ」と言っていないか。上の図の例だと線が右にいったり左にいったりしていないかということだ。

「運転からの開放」か「あくまでも運転の補助かなのか」の使用目的の違いによって，リスク分析の結果や必要なリスクコントロールが変わってくる。

だからこそ，大事なのは「その機能があるかないかではなく，製造業者がどんな意図でその機能を製品に搭載したのかという意図の問題」だ。それが Intended Use を特定することだ。

そして，その機能を意図して搭載すると決めたのなら，その使用目的を想定したリスク分析を行い，リスクが受容できるまでリスクコントロール手段を講じなければいけない。

Mibile MIM の例では「放射線治療プランの承認に使用することを意図する」と決めたから，放射線治療プランを誤って承認するリスク（例えば実際には病巣があるのにないと判断して治療が遅れ病状が悪化するなど）が抽出され，リスクコントロール手段を取ることができたのだ。

Intended Use を曖昧にしていると「コントラストが確認できない状況でアプリを使わせてはいけない」というリスク分析が出てこないかったかもしれないし，コストがかかるからといわれ採用できなかったかもしれない。

自動運転に関しては，何のためにその機能を搭載するのかの Intended Use を定義しないまま，自動車業界は世の中のムードや早く実現しろというプレッシャーに押されて開発を進めていないだろうか。

一番危ないのは，サプライヤーが「その機能作れって言われたので作りました」というスタンスで部品として自動運転の機能を自動車メーカーに提供するというケースだ。

「ASIL-D として自動運転機能を仕上げましたので安心してどうぞご使用ください」というスタンスだと，Intended Use をベースにしたリスク分析やリスクコントロール手段に結び付かない。ようするに自動運転が「運転からの開放」なのか，「運転の一部肩代わり」なのか曖昧なままでは，リスク分析の結果とリスクコントロール手段が変わり，受容できないリスクが残留するいうことだ。

また，事故が起こってからリスクコントロール手段を考え直すということを繰り返していくと，付け足したリスクコントロール手段が新たなリスクを生む可能性がある。

医療機器業界は，そういった経験を繰り返した結果，機能安全(Functional Safety)とは異なる，リスクベースアプローチ（Risk Based Approach)を中心した基準を確立してきた。

自動車業界は今後，自動車運転を未来に向かって推し進めようとするならば，自動運転の Intended Use を明確に定義すべきだ。

運転支援だなどと曖昧にごまかして，事故が起こらないうちは，さんざんメリットとして宣伝に使い，いざ事故が起こったら使用者の誤使用にして責任を逃れるやり方は許されない。

これまで自動車は走る・止まる・曲がるの基本性能と付加価値となる機能の間に独立性があったが，時代が変わって，付加価値の機能と基本機能・基本性能が絡み合うようになってきたのだと思う。

医療機器の世界では，ひとつに特定しきれないさまざまな機能をもった機器があり，その使い方に絡む事故もたくさん起こっていたので，事故の再発防止のためにも Intended Use の定義とリスクマネジメントの重要性が叫ばれてきた。

自動車業界もITとの融合が本格的になってきて，Intended Use を明確にしなければ，有効なリスク分析ができず，これまでにはなかった複雑な要因の事故が多発する世界に足を踏み入れてきたのではないだろうか。

P.S.

テスラ社の事故に関して「これは運転支援システムであるから，ドライバーが運転を機械任せにしてしまったことが間違い」という識者の見解を散見するが，こういう考え方をしていると未来に発生するであろうオートパイロットの事故は減らない。オートパイロットを導入することで交通事故が減少するというメリットと天秤にかけるという考え方はあるが，それを正当化したいのなら社会的なコンセンサスを得たうえで，利用者にもリスクを理解させ，オートパイロットの使用における禁忌・禁止事項を守らせることが必要だと思う。

リアルタイムOSから出発して組込みソフトエンジニアを極める【改装版】

2006年3月に出版した著書『組込みソフトエンジニアを極める』は，最初の日経BP社版が再版されず絶版となったため，エスビーアイアクセス版を2011年9月に出版した。

その後，この版が在庫切れとなり，オンデマンド印刷で少しずつ刷ろうということになったが，結局あまりコストが下がらないということで，改装版で再版することになった。

------

最初に出版してから10年経ちましたが，組込みソフトウェア開発の環境は劇的には変わっていないなあと感じています。ソフトウェアを作っているのは人間なのでそう簡単には変われないのでしょう。

表紙が少し明るい色になりました。Amazon での取り扱いも始まったので，是非ご利用ください。

三菱自動車の燃費不正問題に思うこと（プレッシャーの悪影響）

三菱自動車の燃費偽装問題では、不正なデータの操作が行われた軽乗用車４車種の実際の燃費が、カタログなどに記していた公表値と大幅に異なる可能性が出ていて、5～10%ぐらいの乖離があり、大幅に異なる場合には型式指定の取消しがあるかもしれないとのことである。

ｅＫワゴンの当初の燃費目標は2011年2月の時点で26.4km/リットルだったが、スズキが2012年9月に28.8km/リットルのワゴンＲを発売すると、三菱自動車内の目標は29km/リットルに引き上げられ、ダイハツ工業が2012年の12月に売り出した「ムーヴ」の燃費が29km/リットルになるという情報が伝わると、目標は29.2km に引き上げられた。

もしも、燃費目標と根拠となるメカニズムがセットで語られていなかったのだとしたら「手段を選ばず目標を達成せよ」と命じたのと同じだと思う。直接不正を指示してはいなくても、結果的にはそうせざるを得ない所に追い込んだことになる。

三菱の軽自動車もアイドリングストップの機能は搭載していたようだが、ライバル会社はそれ以上のこと（スズキのエネチャージなど）をしているのに、新たな技術開発なくして燃費性能が上がるわけがない。

売り上げが上がらないから売れるような物を作れとか、燃費性能が負けているからそれ以上の物を作れとか、およそ技術で立脚している会社の目標とは思えないようなことを言うトップマネジメントがいるんだと思った。そんなことなら技術的背景がまったなくても言えるでしょ。

こちらの時事通信の記事によると社長は「基本的な数字を操作しているとは夢にも思わなかった。性善説に立っていた」と言い，担当部長は「何としても燃費目標を達成しろ。やり方はお前らで考えろ」と言ったそうだ。繰り返すが，技術で飯を食っている会社のマネジメント層が発する言葉とは信じられない。技術的根拠に重きを置かず，その会社のコア技術，コアコンピタンスとなる技術が何かについて知らない，知りたいと思わないなら技術に立脚した会社とは言えないと思う。

安全分析で著名なMITのナンシー・レブソン教授が、スペースシャトルコロンビアの事故をモデル化した図がこの図だ。（出典はこちら）

これで注目して欲しいのは、左側の予算カットや性能に対するプレッシャーがミッション成功に対してマイナスの影響を与えているということだ。

三菱自動車の不正の件は安全への影響はなかったようだが、ユーザーの信頼を失う結果となった。技術者が伸び伸びと開発に専念できない環境、プレッシャーだけが強く、モチベーションやインセンティブがない環境が最終的には組織に損害を与えるというモデルはあると思う。

そのベースが人間の論理的でない部分から成るので、証明するのが難しいが、事故分析の分野では事故当事者にかかっていたプレッシャーを考慮に入れる例は多くある。

『ダイハツ・ムーヴ　“燃費チキンレース”はもうしない！』という記事もあるから、ダイハツは燃費競争がいずれ破綻することが分かっていたようだ。

この記事で注目すべきは、「もうこれ以上の燃費性能を顧客は望んでいない」というところだ。顧客は望んでいないが、ライバル会社に負けるから燃費の目標数値を上げるというところが間違いの元であり、誰のために商売しているのかを見失った時に問題は起こるということを思い知らされた。

今回のケースは顧客のためではなく自分達のために安易に燃費目標をつり上げ、結局は燃費を偽って顧客の利益に背反することをやってしまった。仮に軽自動車の競争で後塵を拝していたのだとしても、顧客のことをないがしろにする企業に明日はないと思う。多くの社員がそうではなかったとしても、ボードメンバーに顧客を気遣う気持ち（Awareness）よりも利益が先に立つ人がいると危ない。

また､三菱自動車の燃費不正の問題は、経営層が技術に立脚しないプレッシャーを社員にかけることのリスクが明白になった例であり、どの企業にもありうる教訓にしないといけないと思った。

スキル・キャリア細分化 vs 問題解決能力・ドメイン熱中力

世の中、ソフトウェアエンジニアのスキルやキャリアを細分化しようという動きが盛んなようだ。ソフトウェアの規模が大規模・複雑化している昨今、分業しなければやっていけない、一人の技術者が何でも知っているという時代ではないのは分かる。

ただ、おびただしい数のスキル項目やコンピテンシー項目を見せられると強い違和感を感じるのは自分だけだろうか。

一覧となったスキルやコンピテンシーを組織として網羅しながらレベルを上げていくと、どんな開発も成功するのだろうかという疑問が湧く。ソフトウェアエンジニアを人間として見ていないように見えるのだ。コンピュータのAIに必要な知識を学習させているような感覚を覚える。コンピュータ vs 人間の将棋対決が象徴しているように、現実社会でAIと人間が対決してもしようがないように思う。それぞれ得意な分野で役割分担した方がよっぽど生産的だ。だから、ネットの情報やネットで調べた専門家を使って解決できる問題は、スキルやコンピテンシーリストから外してもいいのではないだろうか。今どき「知っていること」は重要ではなく、「問題を解決する意欲を持って、どこで情報を収集してどう組み立てて進めればいいか」が分かってできることが重要なのではないか。

タイトルに書いた「スキル・キャリア細分化 vs 問題解決能力・ドメイン熱中力」の意味は、たとえ、スキルやキャリアがほとんど無かったとしても、問題解決能力とドメインへの熱中力（Enthusiasm)が高ければ、必要なスキルはスポンジが水を吸い込むように身についてきて、それが自信につながりキャリアも形成されるのではないかという意味だ。

現実には、プロジェクトメンバー全員が問題解決能力が高いという状況はあり得ないので、いろいろな人の組合せでプロジェクトを進めていかなければならない。ただ、そのとき人は人として捉えなければならず、人をコンピュータのAIのように扱ってはいけないと思う。

現代のソフトウェアエンジニアリングは大きな曲がり角に来ていると思う。エンジニアリングを学問として昇華させようと考える人々は、すべてのドメインに共通に利用できる普遍的な理論を構築しようとする。しかし、ソフトウェアを作っているのは人間であり、人間は千差万別でコンピュータとは違って普遍的な思考や行動をしない。

だから、ソフトウェアの研究者の中でも、G.M. ワインバーグやトム・デマルコのように、人を人と捉えて語る人達もいる。

一方で、ソフトウェア工学の研究者は特定のドメインで醸成されてきた手法・方法論をそのドメインの特徴として捉える研究も少ないと感じる。（なぜか NASA だけは特別扱いのようだが）

ハードウェアの世界では業界に密着した研究（例えば東京大学の藤本隆宏先生の自動車業界の研究）などがあるのに、ソフトウェアの世界では、ドメインに特化した研究はあまり見かけない。

タイトルに書いた「スキル・キャリア細分化 vs 問題解決能力・ドメイン熱中力」のように、多様化している世界の中で、ドメインを意識しない抽象化を目指すのではなく、ドメインに特化した問題解決を目指す必要があるように考える。当然、nが減るから対象者・読者は減ってしまうが、全員に通じるような理論・方法論は今の世の中あり得ないと思うのだ。

もっと、「問題解決能力の高さ」とか「このドメインが好きでこの仕事をしてるんだ」といった所を高く評価するしくみはできないのかねと言いたい。（『問題解決能力（Problem Solving Skills)：自ら考え行動する力』も参照されたし）

人間はコンピュータではないので、一律にもののように扱ってはいけない。デバッグ工学研究所の松尾谷さんが説くように、プロジェクトメンバー全体のモチベーションを高めることに注力を注いだ方が効率よくより良い結果に結び付くのではないかと思う。

その仕事が好きで、プロ意識を高く持って、寝食を忘れて没頭するようなエンジニアは、必要な知識がどこにあるのかを探し、スキルが必要であれば熟練者に弟子入りしてスキルを習得する。自分が熱中できる分野での足らない知識やスキルなら、それを学べることはこの上なく楽しいと感じる。何に役立つのかも知らさせていない講義をスキルマップの星取り表に従って機械的に受けるのとは、学習効率がまるで違う。

人間には人間の得意な創造性や問題解決の能力を求め、知識や解決方法の検索や提案はネットやAIがやってくれる時代はすぐそこまで来ているような気がする。

スキルやコンピテンシーは一般化できないドメインに特化したものに集中させた方がよい時代になってきていると感じる。そうなるとドメインに特化する必要があって、研究者も現場に密着しないと成果につながらない。だから、そういう研究ってほとんど見当たらないんだろうなと思う。でも、現場の問題をソフトウェアエンジニアリングで解決する事ほど研究者のモチベーションを高めると思う。それを一般化しようしようとするのではなく、どのドメインに特化した要素がないかどうかを考えた方がよい。

サイバーセキュリティって誰のためにやっているの？

最近、自分の業務ドメインにてサイバーセキュリティの問題に取り組んでいる。

数年前まではまったくのシロウトだったが、エキスパートの方達と活動していく中でそこそこ詳しくなったと思う。

そして常に考えているのは「これは一体誰のためにやっているのか？」という疑問だ。

なぜ、そんなことを考えているのかというと、サイバーセキュリティの分野ではその道で飯を食っている人達がいて、彼らは「こんなことも知らないのか」とか「こんなこともやっていないのか」とか「こんなことされるんですよ」などと、目に見えない脅威に対して恐怖を煽ってくれる。

幸いにも現実に悪意を持ったハッカーによって患者さんの健康被害に至ったという事例はまだ聞いたことがない。

上記の図は、そういった状況の中で機器の製造業者がどのようなプレッシャーにされされているのかを表したものだ。

1. 専門的な知識が必要。
2. 世の中で話題になっている。
3. 規制またはそれに近い要件となっている

この3つが揃うと、これで金儲けできると考える者・組織がどこからともなく表れ、「アドバイスしまっせ」と近寄ってくる。知識が十分でない製造業者はいいかもとなる。レクチャーする方は正義の味方の顔をしているのだが、なんだか釈然としない。

そこで、「これは一体誰のためにやっているのか？」と考えるのだ。もちろん、エンドユーザーである患者さんが健康被害に至るようなことがあってはならないので、リスクを分析し対策を打つことが必要であるということは分かる。

しかし、これまでやっていなかったことに取り組む訳だから、そこには必ずコストがかかる。そのコストは最終的に誰が負担するのか。それは、回り回ってエンドユーザーの負担になる。

だからこそ、余計なこと、やってもあまり意味のないことはやりたくない。

そこで、今、セキュリティとセーフティをどのように切り分けるのかの考え方をまとめようとしている。

ところが、セキュリティの専門家という人達はセーフティとセキュリティの切り分けができない。特にセーフティサイドの概念や経験がほとんどないので、インフォメーションセキュリティリスクがどのような危害に至るのかメカニズムを説明することができない。一方で、どんな脆弱性があるのかセキュリティで有効とされる対策はどんなことがあるのかを列挙してくる。

セキュリティでビジネスする者にとっては、対策はより多く採用されればされるほど儲かる。しかし、製造業者に取っては、対策は最小限であればあるほど、コストを上げなくて済む。

機能安全の話も同じだと思うが、自分には、職業的セキュリティの専門家と悪意を持ったハッカーがダブって見えてくる。

今一度、サイバーセキュリティに携わっている人達に聞きたい。「これは一体誰のためにやっているのか？」と。

方法論が先行して目的を見失うこと無きよう、気をつけましょう。