Embedded Software Manufactory

AIとベテランの組み合わせが、ソフトウェア開発を変える

2026-04-08T21:46:00.001+09:00

2025年6月に個人事業主として独立し、2026年1月に初めて確定申告（青色申告）を提出した。

組織を離れてつくづく感じるのは、サラリーマン時代には見えていなかったものが、独立するとよく見えてくるということだ。

会社はエンジニアの給料の「倍」を払っている

個人事業主になると、社会保険料を全額自分で払うことになる。健康保険、年金、それに消費税の申告まで。組織にいたときはほとんど意識していなかったが、これが想像以上に重い負担だ。

一般に、会社は社員に支払う給料の倍近くをさまざまなかたちで負担しているといわれる。月給50万円のエンジニアがいれば、会社の実質的な人件費は100万円前後になる計算だ。健康保険・厚生年金の会社負担分、交通費、福利厚生、オフィスコスト……それらをすべて合算すれば、社員一人を雇うコストがいかに大きいかがわかる。

ソフトウェア開発プロジェクトにエンジニアが10人いれば、それだけで月1,000万円が飛んでいく。1年続ければ1億2,000万円だ。

サラリーマンエンジニアはこの現実をほとんど知らない。自分の給与明細しか見えていないからだ。しかし経営者や独立した事業主の目線で見れば、人件費はプロジェクトコストの大部分を占める最大の変動費である。この非対称な認識が、後述する「なぜ組織はAI活用に遅れるのか」という問題の根っこにある。

ソフトハウスの利益構造はなぜ脆いのか

製造業と比較するとわかりやすい。

製造業は、設計・開発の投資を一度やり切ってしまえば、あとは設計図通りに量産するだけで利益が積み上がる。売れれば売れるほど一製品あたりのコストは下がり、利益率は上がっていく。もちろん、商品に魅力がなければ売れないし、営業も必要だ。しかし「仕組みが動いていれば利益が出る」という構造が製造業には存在する。

ところがソフトハウスは根本的に違う。利益を生み出す源泉はエンジニアそのものであり、エンジニアが手を動かさない限り、何も生まれない。受注が増えれば人を増やすしかなく、人が増えればコミュニケーションコストが増え、むしろ効率が落ちる。製造業のように「黙っていても利益が出る仕組み」が、ソフトハウスには存在しない。

メーカーはこれまで、製品を売ることで得た利益の一部を、新製品の開発費としてソフトハウスに支払うかたちで産業を回してきた。そのほとんどが人件費だ。ソフトハウスにとっても、エンジニアの稼働率こそが売上の源泉であり、人を増やすことが成長の唯一の手段だった。

この構造は長らく変わらなかった。しかしAIの登場によって、その前提が崩れ始めている。

大規模プロジェクトを、今やり直したら

前職では、大規模なクラウドサービスの開発を数年間にわたってPMとしてマネジメントした経験がある。プロジェクトの規模は相当なものであり、外注費の大半がソフトハウスへの人件費だった。

プロジェクトが大きくなるほど、打合せ・仕様確認・修正依頼のラウンドトリップが増える。関わるエンジニアやステークホルダが増えれば増えるほど、コミュニケーションコストが膨らみ、開発効率はどんどん落ちていった。これはソフトウェア開発の構造的な問題であり、当時はそれ以外の選択肢がなかった。

そのプロジェクトを、今のAIを使ってやり直せたなら——開発費は10分の1以下、期間は半分以下にできたと確信している。

これは感覚的な数字ではない。PMとして全工程を見てきたからこそ言える数字だ。もちろん、プロジェクトの規模や性質、ドメインの複雑さによって結果は大きく異なる。しかし少なくとも、コミュニケーションコストが支配的だった開発においては、この肌感覚には根拠がある。

実際、最近、個人事業として、データベース・バックエンド・フロントエンドを連携するWebサービスをClaudeを使って開発した。開発期間は約3週間、Claudeに使った費用は約300ドルだ。想定していた機能はほぼすべて実装できた。

このサービスを外部の開発会社に委託した場合の見積もりをAIに試算させると、「エンジニア1名体制で3〜5ヶ月、費用は約500万円」という答えが返ってきた。コミュニケーションコスト——打合せ・仕様確認・修正依頼のラウンドトリップ——が大きな時間的オーバーヘッドになるからだ。これが外注の現実だ。

ちなみに、WEBシステムのモックアップを作るのに、エンジニア数人で一ヶ月かかっていたものが、今ではAIに何を作りたいかをきちんと説明できれば1時間もかからずに出来上がる。これを実際に体験したとき、「この変化に対応できない組織は10年後に競争に負ける」と直感した。

AIを使いこなすのは「誰でも」ではない

ただし、誤解してほしくない点がある。

AIにコードを書かせるだけなら、確かに誰でもできる。しかしそれだけでは、システムはじわじわとデグレードしていく。修正指示を闇雲に出し続けると、AIは整合性を失い、コードは壊れていく。どれだけ優秀なAIであっても、的確な指示がなければデグレードは避けられない。

AIを使いこなすには、ソフトウェアエンジニアリングの基礎と、プロジェクト成功の経験が必要だ。要求仕様の定義、各種設計書の作成とアップデート、テスト計画、構成管理、チェンジコントロール——これらを的確に指示できなければ、AIは力を発揮しない。それどころか、指示の仕方次第でシステムを壊す存在になる。

デグレードを防ぐためには、設計書を作成し、常にアップデートしておき、AIに指示を出す前に「まずこれを読め、そのうえで進めろ」と釘を刺す必要がある。成功したソフトウェア開発のアプローチや、過去の失敗から得た教訓をAIにあらかじめ伝えておくことが、品質を守る唯一の方法だ。

つまり、人間のソフトウェアプロジェクトにおける成功と失敗の経験を持っていない人間には、AIへの的確な指示は出せない。AIは道具であり、使い手の経験値がそのまま出力品質に直結する。

逆に言えば、それがきちんとできていれば、開発効率は圧倒的に上がり、品質の高い設計ができる。AIは経験ある人間の思考を増幅させる道具として、これ以上ないポテンシャルを持っている。

ここで言う「経験」とは、単に年数ではない。ソフトウェア工学という、過去数十年にわたるエンジニアたちの叡智の結集を、どれだけ自分のものにしているかだ。

要求分析、アーキテクチャ設計、品質保証、リスク管理——これらはソフトウェア工学が長い試行錯誤の末に体系化してきた知識だ。AIはその膨大な知識を学習データとして取り込んでいる。しかし、AIが持つ知識を引き出し、正しい方向に使うためには、人間側がその体系を理解していなければならない。ソフトウェア工学を知らない人間がAIに指示を出しても、AIの能力の表面しか使えない。

筆者自身、30年以上にわたって組織の外のコミュニティで一流のエンジニアたちと交流を続けてきた。そこで培ったのは、特定の技術や言語の知識ではなく、「ソフトウェア開発とはどうあるべきか」という考え方の軸だ。その軸があるからこそ、AIへの指示が的確になる。AIは膨大なソフトウェア工学の知識を取り込んでいる。それを引き出せるかどうかは、指示する人間の側にかかっている。

AIと付き合う上での「失敗談」

AIを使った開発は順調なことばかりではない。実際に経験した落とし穴を一つ紹介しておく。

AIのコンテキストウィンドウ（一回のチャットで扱える情報量）は年々拡大しており、最新モデルでは数十万トークン規模になっている。しかし、開発が長期化するにつれて、膨大なやり取りの中から何が重要かをAIが適切に判断し続けることには、現時点では限界がある。不必要な情報が混在すると、肝心の指示への集中が乱れ、整合性の取れないコードを生成したり、すでに決まっていたはずの仕様を無視した実装をしてきたりする。

これを防ぐには、新しいチャットを適切なタイミングで始めることが重要だ。そのためには、これまでやってきたことのエッセンスを仕様書や作業ログとして記録しておき、新しいチャットの冒頭でそれを読み込ませるという習慣が必要になる。

これはソフトウェア開発における構成管理やドキュメント管理の重要性と、本質的に同じ話だ。人間のチームでも、引き継ぎ資料がなければ新しいメンバーはゼロから学び直すことになる。AIも同じだ。記録を残す習慣がないエンジニアは、AIを使っても同じ失敗を繰り返すことになる。

AIを過信してはいけない

AIの可能性を語ってきたが、同時にリスクについても触れておかなければならない。

AIはもっともらしい嘘をつく。これは比喩ではなく、LLM（大規模言語モデル）の構造的な特性だ。ハルシネーションと呼ばれるこの現象では、AIが存在しない関数を平然と使ったコードを生成したり、古いバージョンのAPIを正しいものとして提示したり、文脈を取り違えたまま実装を進めたりする。そしてその出力は、表面上は非常に「それらしく」見える。

経験のないエンジニアがAIのアウトプットをそのまま信じてしまうのは、この「それらしさ」に騙されるからだ。AIの出力を鵜呑みにせず、自分の経験と知識でクリティカルに検証できる能力が、AI使いには不可欠だ。

AIはあくまで道具であり、最終的な判断と責任は人間にある。この原則を忘れたとき、AIは強力な助っ人から危険な存在に変わる。

最強の組み合わせは「経験者×AI」である

では、誰がAIを使いこなせるのか。

それは、製品開発や事業開発の成功体験と失敗体験を持つ経験者だ。顧客ニーズを把握し、事業計画を立て、開発プロジェクト全体を俯瞰できる人間が1人と、AIおよびAIを扱えるエンジニアが1人いれば、かつての大人数チームを凌駕する開発が可能になる。その2役を1人が兼ねられれば、さらに強い。

ここで注目したいのが、リタイアしたベテランの価値が急上昇するだろうという点だ。

特定ドメインでの製品開発・事業開発を長年経験してきた人材は、もはやソースコードを書く必要がない。AIやAI使いのエンジニアに対して的確な指示を出せればいい。かつては「現役を退いた」とみなされていた経験者が、AI時代の最重要リソースになりうる。経験と知識こそが、AIを正しい方向に導く羅針盤だからだ。

そういった人材をうまく確保し、組織内のAI使いエンジニアをプロジェクトに参加させて経験を積ませることができる組織が、次の競争を生き残る。

AIにできないこと

ここまでAIの可能性を語ってきたが、AIにできないことも明確にしておきたい。

AIは、コードを書き、設計を考え、文書を作ることはできる。しかし、人と人をつなぎ、組織をまたいで合意を形成し、実行可能な提案を引き出すことは、AIには代替できない。

定年退職前の5年間、筆者が心血を注いだのはまさにそこだった。開発部門と品質部門、事業部門と技術部門、社内と社外——それぞれの立場と論理を持つ人間の間に入り、横串を刺して、「それぞれが納得でき、かつ実現可能な提案」を形にする仕事だ。これは、どれだけAIが賢くなっても、人間にしかできない。

AIは「答え」を出すことが得意だ。しかし組織の中での意思決定は、正しい答えを出すことよりも、関係者を動かすことのほうがはるかに難しい。その現場の政治、感情、組織の力学を読みながら動ける人間が、AI時代にもっとも価値を持つ人材の一つだと思っている。

ベテランの価値は、知識やスキルだけではない。人と組織を動かしてきた経験そのものが、AIには持てない固有の資産なのだ。

ゼロから新人を育てている場合ではない

日本ではいまだに新卒一括採用が主流だ。プログラミング経験ゼロの新人を数年かけてOJTで育て、一人前になるまで何年、場合によっては何十年もかかる。

一方、過去のソフトウェア開発の叡智を集積したAIエキスパートを、月数万円のサブスクで使える時代が来ている。

この非対称性は致命的だ。

スキルゼロの新人を何年もかけて育成しているコストと時間を、AIとベテランの組み合わせに投資した競合他社が先行すれば、価格でも開発スピードでも太刀打ちできなくなる。

ただし、AI使いとなるエンジニアもまた育成が必要だという点は忘れてはならない。AIの特性を把握したうえで、AIのアウトプットに対して的確に修正指示を出せるスキルは、一朝一夕では身につかない。

そのための育成方法として、筆者が有効だと考えるのはPBL（Project Based Learning）だ。無茶だと思っても、実際の製品やサービス開発を新人エンジニア複数人とAIの組み合わせでやりきらせる。途中でベテランが定期的にレビューを入れ、方向を修正する。教科書で学ぶのではなく、実際のプロジェクトで成功と失敗を経験させることで初めて、AIへの的確な指示が出せるエンジニアが育つ。

試行錯誤しながらもゴールを目指す自立したエンジニアでなければ、良いAI使いにはなれない。残念ながら、日本の教育環境はこの点で不利だ。知識詰め込みの画一教育では、創造性や自立した思考は育ちにくい。学校でそれができないのならば、企業側で育てるしかない。そのコストと時間を惜しむ組織は、AI時代の競争から脱落していくだろう。

エンジニア自身が損をしないために

このブログで一貫して言いたいのは、エンジニアがやり甲斐のある仕事をし、高いスキルを持って正当に評価される世界を目指してほしいということだ。

AI時代において、その実現を阻む最大のリスクは「AIに使われるエンジニア」になってしまうことだ。AIが出してくるアウトプットを検証もせずに右から左に流すだけの存在になれば、エンジニアとしての価値は急速に失われる。

逆に、AIを使いこなし、ソフトウェア工学の知識をAIへの指示に変換し、プロジェクト全体を俯瞰できるエンジニアの価値は、AI時代にこそ上がる。単純な実装作業はAIに任せ、自分はより高度な判断と設計に集中できるからだ。

AIを道具として使いこなすエンジニアになるか、AIに代替される存在になるか——その分岐点は、ソフトウェア工学の基礎を学び、実プロジェクトで経験を積む努力を続けるかどうかにかかっている。

AI時代は、スキルの高いエンジニアにとってむしろ追い風だ。問題は、その追い風に乗れる準備ができているかどうかだ。

ソフトウェア開発のサイクルが変わる

AIの活用が進むと、開発サイクルそのものが変わる。

これまで1つの機能を追加・修正・検証・バリデーションするまでに半年かかっていたものが、AIを活用することで1ヶ月程度に短縮できる感覚がある。ソフトウェアのアップデートサイクルが年1回から四半期に1回になれば、それだけで競合他社との明確な差別化になる。営業が顧客にアピールできる材料も増える。

開発費の削減よりも、むしろこの開発スピードへのインパクトのほうが、競争優位に与える影響は大きいかもしれない。製品開発には多くの人間が関わるため、コミュニケーションコストが劇的に減るわけではない。しかし、ソフトウェア開発の部分だけでも大幅に短縮できれば、製品全体の競争力は根本から変わる。

経営層が気づくかどうかが、生死を分ける

技術の話をしているようで、これは本質的には経営の話だ。

AI時代に対応できない組織は、10年後には競争に敗れ始める。問題は技術でも予算でもなく、経営層がこの変化に気づき、組織再編に踏み出せるかどうかだ。

少数精鋭＋AI＋ベテランの知見という組み合わせに再編できた組織が生き残り、旧来の大人数・長期育成モデルから抜けられなかった組織が淘汰される——そういう時代が、静かに、しかし確実に始まっている。

組織は永遠にベテランエンジニアをキープし続けることはできない。だからこそ、今この瞬間に、経験者の知見とAIを組み合わせる仕組みを作り始めた組織が、次の10年を制するのだと思う。

RaspberryPi5を使ったリアル波形描画(3) Googleカレンダーを表示してみる

2026-02-26T10:15:00.003+09:00

10.1インチ Raspberry Pi用 IPS タッチモニターとRaspberry Pi5 を購入したのは、リアル波形描画を Qt で作成し直すことだけでなく、仕事机の脇において Googleカレンダーを表示させる目的もあった。

仕事用に34インチのLCDディスプレイを使っているので、GoogleカレンダーはLCDディスプレイのどこかに表示させておけばいいのだが、大抵、いろいろなファイルを広げているので、カレンダーを見るにはいちいち再表示させないといけない。

そのため、机の脇に10インチのディスプレイでGoogleカレンダーが常時表示されている状態にしたかった。そういう商品も売っているようだが、ラズパイで自分用にカスタマイズしたものが欲しかった。

そこで、今回、Raspberry Pi5で10インチのモニターに google カレンダーを表示させるアプリを作ってみた。

Googleカレンダーを表示させた様子（完成系）

作ってみたといっても、自分では一行もコードを書いていない。最近、流行りのコード生成に優れているといわれている Anthropic 社の Claude を使った。

ChatGPTでもできたかもしれないが、この動画を見て Claudeの実力が見てみたくなった。

プロジェクトの概要

本プロジェクトでは、Raspberry Pi 5 上にGoogleカレンダーとGoogle Tasksを表示するウォールダッシュボードを構築した。ダッシュボードはGoogleカレンダーのUIに近いデザインで、月間カレンダービューにイベントをリアルタイム表示する。

システム構成

項目	内容
ハードウェア	Raspberry Pi 5
OS	Raspberry Pi OS (Debian 12, Linux 6.12.62)
リモートアクセス	RealVNC Viewer (Windows PC から接続)
バックエンド	Python 3.13 + FastAPI + Uvicorn
フロントエンド	HTML/CSS/JavaScript (シングルページ)
認証	Google OAuth2 (デスクトップアプリ)
API	Google Calendar API + Google Tasks API

大まかな仕組みとしては、Google OAuth で仕事用の Googleアカウントを認証し、バックエンドのソフトウェアで Googleカレンダー情報を取得する。取得した情報を html でカレンダーとして表示する。これが可能なのは、Google が Google Calendar API と Google Tasks API を提供しているからだ。

最近のアプリは、このようにクラウドサービスが提供するAPIとエンドポイント側のPCや組み込み機器が連携して価値を生み出すものが多い。これまでスタンドアロンで動いていた組み込み機器もネット接続して、このようなクラウド上のAPIと連携して新しい価値を提供するサービスが増えてきている。そううった傾向もあり、サイバーセキュリティも重要度が増している。

ChatGPTで医療機器ソフトウェア規制にこたえるチャットボットを作ったときは、壁打ちしながら約１週間かかった。

MSC Chat（医療機器ソフトウェアQ&A）

Claude での Googleカレンダーアプリ作成は約５時間。Claude がすごいと思ったのは、問題が起こったときのリカバリーの良さだ。今回のサービスでは、ラズパイにPython のインストールが必要で、Python 3.13 のインストール作業の過程でつまずいた。Python 3.13 と pydantic==2.7.1 の互換性問題が発生した。

pydantic：**Pydantic（パイダンティック）**は、Pythonで「データの型チェック」と「データ検証」を簡単・安全に行うためのライブラリです。特に、API開発（FastAPIなど）や設定ファイル、JSONデータの扱いで広く使われています。「Pythonの型ヒントを使って、データの正しさを自動で検証・変換してくれるライブラリ」

pydantic-core のビルドにRustコンパイラが必要なためインストールに失敗した。pydantic==2.11.0 にバージョンを変更することで解決した。

パッケージ	バージョン	用途
FastAPI	0.111.0	WebAPIフレームワーク
Uvicorn	0.29.0	ASGIサーバー
pydantic	2.11.0	データバリデーション
google-auth	2.29.0	Google認証
google-auth-oauthlib	1.2.0	OAuth2フロー
google-api-python-client	2.127.0	Google API クライアント

こういう互換性の問題は、スクラッチで作っているときに発生すると原因がわからず、暗い気持ちになりストレスが溜まる。ヒントをインターネット検索で探すのだが、解決した経験を誰かがアップしてくれていればラッキーで、そこにたどり着くまでにはそれなりの時間がかかる。

しかし、Claude は問題の状況をスクリーンショットで伝えると一発で原因を分析し、代替え手段を提示してくる。こんな感じで Claudeと壁打ちしながら、試行錯誤を繰り返していって、Googleカレンダーをラズパイで表示することができた。

完成した機能

機能	詳細
Googleカレンダー表示	月間カレンダービューでイベントをリアルタイム表示
カレンダー色分け	カレンダーごとの色でイベントを色分け表示
今日のハイライト	今日のセルを水色背景で強調表示
日時表示	右上に現在日時をリアルタイム表示
自動更新	5分ごとに自動リフレッシュ
Pi起動時自動起動	電源投入後に自動でダッシュボードが表示される
全画面キオスクモード	ブラウザのUI非表示で純粋なダッシュボード表示

ちなみに、ChatGPTは Pro の契約をしており、ChatBotを一週間かけて作ったときは、追加料金はかからなかったが、Claude はインプット、アウトプット量に対して、えげつないほどの従量課金になっており、結局 Googleカレンダーアプリ作成に6481円かかった。
使用料は毎日リセットされるので、一日の使用量まで達したら、翌日続きを行うようにすれば、月額使用料の中で完結できたのだが、一日で仕上げたいとなると、追加請求される。

前述の動画でも解説されているが、ChatGPTはオールラウンドプレイヤーで Claudeはビジネス用途の実績主義に特化しているとのこと。確かに判断が的確で試行錯誤が少ないが、効率がよいぶん、費用の請求もえげつない。

AIを使ったコード生成の感想

多くの識者が語っているように、今後ソフトウェアのコーディングは劇的に変わっていくことを実感した。経験の少ないソフトウェアエンジニアを一から教育する投資がもったいないというか、そこに疑問を持たずに続けていく企業はいずれ滅びてしまうのではないかという感覚がある。

現実に米国ではすでにソフトウェアエンジニアのリストラが始まっていると聞く。AIに置き換えられた分の人件費をカットする判断を経営層が下ししている。日本では簡単に社員をクビにはできないが、ソフトウェアエンジニアの採用が徐々に減っていく予感さえある。

何を作りたいか、何を提供すれば顧客に価値をもたらすことができるかさえ想定できれば、AIがアプリを作ってくれるところまで来ている。仮に作ったサービスが期待通りの実績を上げられなくても、ユーザーの使用状況のデータなどを収集してAIに分析させることで、どう改変すればよいのかも教えてくれる。

もちろんそのための費用もかかるが圧倒的に人件費より安い。

今後、生身のエンジニアに求めらるのは、コーディング力ではなく、価値創造の企画力や、人間同士のコミュニケーション能力ではないだろうか。それと、AIが出してきたアウトプットの是非を判断できる経験。

今回、Raspberry Pi 5 Google カレンダーダッシュボードプロジェクトが完成したところで、Claude に詳細なレポートを作ってもらった。

これをしっかり読み込むことで、AIが何を考え試行錯誤したのかがよく分かった。昔ならベテランの先輩に年単位で教えてもらっていたことが、数日で学習できる。

今後の技術者教育は、自分で企画してAIに作ってもらい、その開発過程をAIに説明してもらうことで、自分の経験として取り込むという教育が有効な感じがした。

どっちにしても、従来と同じようなソフトウェアエンジニアの採用や教育を行っていると、グローバルな競争に負けていく予感がしている。

便利だけど、生身のソフトウェアエンジニアには受難の時代になってきたかもしれない。

RaspberryPi5を使ったリアル波形描画(2) Linux を使ってみる

2026-01-20T10:32:00.000+09:00

RaspberryPiの OS は Linux である。RaspberryPi でアプリ制作をするにあたっては、Linux でコマンドを打つシーンが多くなる。コマンドを打ちやすくするために、VNC Viewer をセッティングする。

【VNC とは】

VNC（Virtual Network Computing）は、離れた場所にあるパソコンの画面を手元の端末に表示し、キーボードやマウス操作をそのまま遠隔のパソコンに送るためのリモートデスクトップソフト。

Real VNC Viewer（RealVNC Viewer）は、RealVNC 社が提供しているリモートデスクトップ用のビューアソフトで、離れた場所にある PC やサーバーの画面を表示して操作できるツールで、無償で使える。Home（無料）ライセンスでは、個人用途向けに台数制限付き（例：最大 5 台まで）でリモート接続が可能。

現在、RaspberryPi5 は Wi-Fi に繋がっているので、デスクトップPCに VNC Viewer をインストールして、RaspberryPi5 の画面を PC上に表示させる。こうすると、デスクトップPCのキーボードやマウスを使って、RaspberryPi5 をリモートで操作することができる。

(1) PCに「VNC Viewer」をインストールして起動。（こちらの note記事を参照）

これがRaspberryPi5のスクリーンをVPNでディスクトップPCに表示させた様子だ。下側に出ているのはタッチスクリーンのキーボード。RaspberryPi5にキーボードが接続されていないときにタッチスクリーンを使ってキーボード入力できる、親切な設計だ。ただ、VNCでは使わないので、左上のラズベリーメニュー→ Preferences→Control Centre→Display→On-screen Keyboard を Disabled にしておく

コマンドプロンプト画面は、左上のアイコンをクリックすると表示される。最初はかなり小さい画面になっているので、Edit → Style でフォントの大きさや画面サイズを変更した。

【RaspberryPiに登録されているユーザを確認する】

まず最初に、RaspberryPi5 に登録されているユーザーを確認しておく。

コマンドは　cat /etc/passwd。結果は次のようになった。

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin

　：

colord:x:107:111:colord colour management daemon:/var/lib/colord:/usr/sbin/nologin
hplip:x:108:7:HPLIP system user:/run/hplip:/bin/false
vnc:x:985:985:vnc:/nonexistent:/usr/sbin/nologin
xxsakai:x:1000:1000::/home/xxsakai:/bin/bash

前半はすべて Linux のシステムが使うユーザーで最初から設定されているものだ。vnc はVNCを使うために追加されたユーザーで、xxsakai は Linux のインストールイメージを作ったときに設定したユーザー（自分自身）である。

これで、システム以外のユーザーは自分だけだということがわかった。

ちなみに、root ユーザーはすべての権限を持った特権ユーザーで、昔は、root ユーザーのパスワードを設定して、root ユーザーになることができたが、Raspberry Pi 5（Raspberry Pi OS）では root ユーザーのパスワードは「最初から設定されていいない」。

なぜ root のパスワードがないのかといえば、Raspberry Pi OS（Debian系）は、root での直接ログインを禁止し、通常ユーザーでログインして、必要なときだけ sudo で管理者権限を使うという設計になっているからである。

Linux のイメージを作ったときに、ユーザーを設定するので、そのユーザーは sudo を使えるようになっている。コマンドラインで確かめてみる。

sudo グループに入っており、sudo コマンドが使えることが確認できた。

【Linux のアップデートについて】

Linux をアップデートするには、次のコマンドを実行する。

sudo apt update

sudo apt upgrade

update：最新情報を取りに行く（変更なし）

upgrade：実際に更新する（変更あり）

update はリポジトリから最新のパッケージ一覧を取得する。update は何も書き換えない。upgrade コマンドで、最新のパッケージをインストールすることになる。

では、upgrade はどれくらいの頻度でやるべきか。推奨は、月1回程度で、何かの作業が終わった後がよい。避けるべきなのは、作業の途中や動作の確認中だ。

Linux は Windows Update のように定期的にパッチを当てるような仕組みがないので、脆弱性が発見されたときなど、手動で upgradeする必要があるが、upgrade することで、今動いていた機能が動かなくなるリスクもまったくないとは言えないので、頻繁にやることはない。

RaspberryPi5 を設置した直後に upgrage を行ったが、かなりの量の更新があった。アップグレードは節目節目、月イチ程度で行った方がよいだろう。

【Linux でよく使うコマンド】

📌 ファイル・ディレクトリ操作（最重要）

コマンド	説明
`ls`	ファイル一覧表示
`ls -l`	詳細表示
`ls -a`	隠しファイル含め表示
`pwd`	今いるディレクトリ
`cd`	ディレクトリ移動
`mkdir`	フォルダ作成
`rmdir`	空フォルダ削除
`cp`	コピー
`mv`	移動・名前変更
`rm`	削除（注意）
`rm -r`	フォルダ削除（注意）
`file`	ファイル種別確認

📌 ファイル内容の確認・編集

コマンド	説明
`cat`	内容を全部表示
`less`	ページ送りで表示
`head`	先頭表示
`tail`	末尾表示
`tail -f`	追記をリアルタイム表示
`nano`	簡易エディタ
`vi` / `vim`	高機能エディタ
`wc`	行数・文字数カウント

📌 検索・抽出（慣れると超便利）

コマンド	説明
`grep`	文字列検索
`find`	ファイル検索
`locate`	高速検索（事前DB）
`awk`	列処理
`sed`	文字置換
`sort`	並び替え
`uniq`	重複除去

📌 システム・状態確認

コマンド	説明
`top`	プロセス監視
`htop`	見やすい top
`ps`	プロセス表示
`df -h`	ディスク空き
`du -h`	使用量
`free -h`	メモリ
`uptime`	稼働時間
`uname -a`	カーネル情報
`lsblk`	ストレージ構成

📌 ネットワーク

コマンド	説明
`ip a`	IPアドレス
`ip r`	ルーティング
`ping`	通信確認
`ss -lntup`	ポート確認
`curl`	HTTP取得
`wget`	ファイル取得
`nmcli`	NetworkManager操作

📌 ユーザー・権限

コマンド	説明
`whoami`	自分
`id`	UID/GID
`groups`	所属グループ
`sudo`	管理者権限
`passwd`	パスワード変更
`su`	ユーザー切替
`chmod`	権限変更
`chown`	所有者変更

📌 パッケージ管理（Debian系）

コマンド	説明
`apt update`	更新情報取得
`apt upgrade`	更新
`apt install`	インストール
`apt remove`	削除
`apt autoremove`	不要削除
`apt search`	検索
`apt show`	詳細

📌 圧縮・展開

コマンド	説明
`tar`	アーカイブ
`gzip` / `gunzip`	gzip圧縮
`zip` / `unzip`	zip
`xz`	高圧縮

📌 便利・覚えておくと楽

コマンド	説明
`history`	実行履歴
`clear`	画面消去
`alias`	別名
`watch`	定期実行
`time`	実行時間
`which`	実体確認
`man`	マニュアル

今回は、これくらいにしておく。

RaspberryPi5を使ったリアル波形描画(1) イントロダクション

2026-01-13T10:59:00.006+09:00

2018年にRaspberryPi3を使ったリアル波形描画の記事を10回に渡って書いた。7年半たって、RaspberryPiも進化し、ソフトウェアのプラットフォームとして使っていた Qt もバージョンが上がっている。

そこで、今回よりあらためてRaspberryPi5をベースにして、心電図モニタを想定したシステムを構築しつつ、どのようなソフトウェアアーキテクチャを医療機器に採用するとよいかについて解説していきたい。

RaspberryPi とは

Raspberry Pi（ラズベリーパイ）は、クレジットカードサイズの小型コンピュータで、低価格ながら本格的なPCと同等の機能を備えています。Linux（Raspberry Pi OS）が動作し、キーボードやモニタを接続すれば、Web閲覧、プログラミング、サーバ構築など幅広い用途に利用できます。最大の特徴は、基板上に備えられたGPIOピンを使って、LEDやセンサー、モーターなどのハードウェアを直接制御できる点です。これにより、ソフトウェアと電子工作を組み合わせたIoTや制御システムの試作が容易に行えます。省電力で常時稼働にも向いており、自宅サーバや実験用マシンとしても人気です。学習用途から実務のプロトタイプまで幅広く活用できる点が、Raspberry Piの大きな魅力です。

RaspberryPiを使う理由は、ボードコンピュータとして汎用性が高く、安価で、LANや HDMI、USB、SDカード、Wi-Fiが標準装備されており、入手も容易なので壊れてすぐに交換が可能なのがよいからだ。ラズパイは教育やホビー、カスタマイズできるシステムとして広く普及していて、コンピュータプログラミングの入門機としても適している。

7年前にはRaspberry Pi 3 Model B+ をプラットフォームに使った。今ではRaspberryPiも、ずいぶんラインナップが増えた。

RaspberryPi が特によいのは、デフォルトで Wi-Fi を搭載しているところだ。Wi-Fi を搭載するには、各国の無線規制をクリアする必要がある。日本では技適（技術基準適合認定）を受ける必要があり、20～50万円の費用がかかる。各国で同様の認定が必要なため、世界中でWi-Fiを使えるようにするのは、かなり大変なことだ。RaspberryPi はそういった汎用インタフェースを世界中で同じ仕様で使えるようにしているところがすごい。

Raspberry Pi Foundation（ラズベリーパイ財団）は「未来のエンジニアを育てるために、世界一身近なコンピュータを作った教育団体」で、エンジニア教育への貢献は非常に大きいと思う。

Raspberry Piシリーズ性能比較（主要モデル）

モデル	CPU	メモリ	特徴・性能感
Raspberry Pi Zero 2 W	Quad-core ARM Cortex-A53（1.0GHz）	512MB	超小型・超低消費電力。軽量な制御・IoT向け
Raspberry Pi 3 Model B+	Quad-core Cortex-A53（1.4GHz）	1GB	入門用。Linux学習や簡易サーバ向け
Raspberry Pi 4 Model B	Quad-core Cortex-A72（1.5GHz）	2/4/8GB	実用性が大幅向上。デスクトップ用途も可
Raspberry Pi 5	Quad-core Cortex-A76（2.4GHz）	4/8GB	処理性能が飛躍的に向上。小型PC並み

RaspberryPi 5 は1万7千円とちょっと高めだったが、Raspberry Pi 3 Model B+ に比べてどのくらい性能が上がったのかも体感してみたかったので、RaspberryPi 5を購入することにした。

リアルタイム波形描画を行うには、LCDディスプレイが必要なので10インチのLCDディスプレイにRaspberryPiを背負わせることができるキットを選定した。これにRaspberryPi5とSDカードを合わせて購入した。

購入製品のリスト

RaspberryPiは、電源アダプタや HDMIケーブルなどは同梱されていないので、必要な電源アダプタなどの周辺機器がセットになったLCDキットなどはいろいろ販売されている。タッチパネル付きのLCDや電源がセットになっていたのでXBONFIRE のLCDキットを選んだ。

最初の組み立て

RaspberryPiは、前職で新人技術者教育に使っていたことがあって、汎用性は高いもののSDカードとの相性が悪いと立ち上がらないこともよくあり、「一発では動かない」というイメージがあった。そして、案の定、一発ではうまく動かなかった。

まず、RaspberryPiを起動させるためには、SDカードにLinuxのイメージを書き込む必要がある。このようなセットアップ手順はいろいろなサイトで紹介されているので、今回はこちらのnoteの記事を参考にさせてもらった。

「Raspberry Pi Imager」をRaspberryPi財団のサイトからダウンロードして、自分の Window PCにインストールして、Linuxの起動イメージをSDカードに書き込む。起動ディスクだから、コピペでは動かないので、専用のアプリでイメージを書き込む必要がある。RaspberryPiに挿入するSDカードはmicroSDだが、SDカードアダプタがついていたので、アダプタ経由でPCに刺してOSのイメージを書き込んだ。Raspberry Pi Imager では初期の設定を編集することができて、次のような項目を設定することができる。

ホスト名
ユーザ名
パスワード
Wi-FiのSSIDとパスワード、Wi-Fiの使う国（JP)
タイムゾーン(Asiia/Tokyo)
キーボード設定(JP）

これらをRaspberryPi本体で設定しようとすると、キーボードやディスプレイが必要になるので、この段階で設定できるようになっているのはとても親切だ。

そして、SSH（Secure Shell、ネットワーク越しに、別のコンピュータを安全に操作するための通信プロトコル）の設定（今回はパスワード認証）を行う。

RaspberryPiを立ち上げた後に Wi-Fi経由で自分のPCからSSHで通信する必要があるので、これをやっておく必要がある。

SDカードにイメージを書き込み、RaspberryPi本体にmicroSDカードを差し込んで、電源(USB TypeCから給電する）を入れると、RaspberryPiが立ち上がる。

今回LCDのキットがあるので、LCDキットの基盤にRaspberryPi5をセットして、電源を投入したのだが、LCDディスプレイには「No Input Image」が一瞬表示されて画面が消えてしまう。

「ああ、やっぱり一発では動かなかったか」と落胆しつつ、LCDキットの取説の一番後ろに書いてあったユーザサポートにメールしてみる。12時間以内に返信するとあった。

状況の説明と写真を送ったところ、ていねいな返信がきていろいろアドバイスを教えてくれた。困った時にはAIがヒントをくれるが、生身の人間のサポートがあると安心できる。

RaspberryPiをネジ止めする4箇所のネジ穴があるのだが、ネジ受けの頭に薄い茶色のフィルムが貼られていてそれを剥がせという指示があった。実際、RaspberryPiの基盤をネジ止めしようとしたらネジがうまく入らなかったのでネジ止めできなかったのだが、そういう理由だったようだ。老眼になると細かいところがよく見えないのでフィルムがあることに気が付かなかった。

このLCDキットは、USB-TypeCコネクタとHDMIコネクタに変換アダプタを接続して、LCDキットの基盤のコネクタに刺すような構造になっている。基板側のコネクタがロックのない２列のコネクタでよく見ないと一列ズレて刺してしまう。どうも、最初にうまくいかなかったのは一列がズレてコネクタが刺さっていたからのようだ。RaspberryPiの取り付け位置もフィルムのせいでピタッと合っていなかったこともズレの原因だった。

茶色のフィルムを剥がして、慎重にコネクタの位置を確認しながら接続し、電源を投入したところ、RaspberryPiの初期画面が表示された。

その後、Wi-Fiの接続ができず、タッチパネルを使って、RaspberryPiのWi-Fiをオンにしたり、Wi-FiのSSIDやパスワードを再設定したりし、sshの設定をやり直したりした。

chatGPTに現状の症状を伝えながら、一つずつ問題をクリアすることで、PCからRaspberryPiにWi-Fi経由で接続することができた。

最初の段階ですんなり行かなかったが、焦らずに少しずつすすめていこうと思う。

会計ソフトとの７ヶ月間に渡る格闘

2026-01-06T10:19:00.001+09:00

2025年3月に定年退職して、2ヶ月の準備期間を経て、6月に個人事業主として起業した。

青色申告して60万円の控除を得るために、会計ソフトの freee会計を契約して日々の入出金を記録して、先日2025年の会計を無事閉じることができた。

ここに至るまで、複式簿記の知識がゼロだったので、いろいろとわからないことがあり、非常に苦労した。何が大変だったのかをここに書き留めておきたいと思う。

■会計の期間と起業日について

会計の期間は1月1日から12月31日の一年間が基本だ。しかし、起業日が6月1日だったので、1月から5月までの期間は起業前となる。このシチュエーションは起業の最初の年だけなので、そのような設定を freee会計上ですることができない。

起業前の開業にかかった費用は、開業費として経費計上できることは知っていたので、起業前に準備したPCなどの費用は集計して、領収書も全部取っておいた。

銀行口座とクレジットカードは、個人の口座と事業の口座を分けたかったので、素早く作れるfreee ライフカードと楽天銀行で、個人事業主としてのクレジットカードと銀行口座を作った。

開業費として買うものは freeeライフカードで購入して、楽天銀行の口座から引き落とされるようにした。楽天銀行には、元入金として事業資金を振り込んでおいた。

freee会計では、登録した銀行口座やクレジットカードから、API経由でデータを取り込んでくれて、その情報をもとにして複式簿記の取引を記録できる。

当然、freeeライフカードと楽天銀行は登録したので、データがfreee会計に取り込まれる。1月から5月の間に開業費として使ったカード情報も取り込まれてしまうのだが、起業前なので無視としていた。

ところが、この間に使ったクレジットカードの費用は、freee会計上、銀行引き落としとしての振替を登録しない限り、永遠に残ってしまう。これはとても気持ちが悪い。

後からわかったのは、1月から5月までに freeeライフカードで使った費用は、「開業費」として登録しておけばよかったのだ。結局、年が明けてから、1月から5月にfreeeライフカードで購入したものは無視ではなく、開業費として登録して、freee ライフカードの登録残高はゼロ円にすることができた。

開業費としてリストしてあったもののうちfreeeライフカードで購入したものの金額は削除した。

■クレジットカードと銀行口座について

クレジットカードでサブスクリプションの支払いなどをすると、クレジットカードと利用履歴は数日遅れて登録され、一ヶ月くらいおくれて銀行口座からまとめて引き落とされる。

これはfreee会計上、非常に面倒くさい。クレジットカードの利用情報を一旦取引として登録し、未決済状態にしておいて、銀行口座から引き落とされたときに振替処理をして決済する。

タイムラグがあるのと、銀行の引き落としは一ヶ月のクレジット利用をまとめられてしまうので、記入漏れがあると会計上でズレが生じてしまう。ズレがあると、なんとも気持ちが悪い。

また、三井住友カードが個人事業主向けにビジネスオーナーズという、屋号付きの口座を作れることがわかった。三井住友カードではVポイントがつくので、クレジットカードはこちらに切り替えることにした。

また、三井住友銀行も個人事業主用に屋号付きの口座を作れることがわかったので口座を作った。

また、デビッドカードを使えば、銀行口座から即引き落とされて、すぐに取引登録できるので、ほとんどすべての購入をデビットカードにすることにした。これで取引と決済のタイムラグをなくすことができる。

ちなみに、デビットカードが使えないケースが稀にあって、その場合はしようがないので三井住友カードを使うようにして、三井住友カードの決済を三井住友銀行の口座から引き落とすようにした。

楽天銀行は口座を作るのは簡単だったが、月末月初にAPIが集中するためか、手動同期ができなくなるのと、PCでログインしようとすると、毎回、生年月日とメールアドレスに送られてくるコードを入力しなければならず、使い勝手が悪いので使うのをやめた。

Microsoft Office Businessをデビットカードで契約しようとしたら、どうしてもうまく行かず、Microsoftに問い合わせたところ、まず、セキュリティ強化のため、デビットカードの設定をNGにしていると言われ、解除してもらったのに、うかくいかず、銀行口座開設時に設定した屋号を正確に入力することでやっと設定ができた。

■開業費の減価償却

開業前に使った費用は、好きなときに減価償却できるルールらしいが、freee会計では何年かの均等割でしか償却ができなかった。

■日帰り出張時の昼食代

日帰り出張時の昼食代は経費にできるものと思っていたが、ChatGPTに聞いてみたところ、経費にはできないとのことだった。宿泊を伴う出張時の食事代は経費にできるらしい。

■家事按分

インターネット代など、プライベートと事業で共用する費用は、ちゃんと根拠を説明すれば、家事按分としてある一定の割合を事業経費にできる。

■請求と振り込み

毎月の事業契約では、月末に役務が終了して、翌月請求し、翌月末に振り込みされるというパターンがある。この場合、仕事をしてから、対価が振り込まれるまで最長二ヶ月かかる。この感覚がなかなかなれなかった。また、12月の業務については、1月に請求書を発行するのだが、会計としては、12月末時点で売掛金として登録する必要があることがわかった。役務が発生したときを基準にする必要があるのだそうだ。

■AmazonBusiness

AmazonBusiness口座をfreee会計に登録すると、何を購入したのかが詳細に登録されるので便利だ。AmazonBusinessの引き落としも、デビットカードにしておけば、タイムラグも少ない。ただ、AmazonBusinessは荷物が届いた時点で情報が登録されるため、デビッドカードでの引き落としの方が先に登録されることがある。AmazonBusinessで取引登録して、デビットカードの銀行口座で振替しないといけないので、一つ手間が増えるが、何を買ったのかの情報が詳細なので、AmazonBusiness口座は利用している。

■個人事業主借り、個人事業主貸し

プライベート資金を事業用に使った場合は、個人事業主借り、事業の資金をプライベート側に回す場合は個人事業主貸しになる。出張時にPASMOを使ったときなどは個人事業主借りとして取引登録する。

■セミナー講師実施時の交通費

リアルセミナーで講師をしたとき、交通費が実費精算だった。事前に交通費を調べて往復分を講師料と一緒に請求書で請求した。この取引登録が難しかった。

講師費用は消費税ありで、売掛金からの売上高になり、交通費は消費税なしで未収入金からの雑収入とした。ここに行き着くまで　ChatGPTと何回もやり取りしたやっと腹落ちした。

■インボイス制度、消費税

以前は1000万円未満の個人事業主は消費税込みで受け取った費用に対して、消費税を納付する必要がなかったが、インボイス制度が始まって、消費税を納付しなければならなくなったようだ。そのためインボイス登録番号を取って、簡易課税の事業者として登録した。

■感想

freee会計を使ってみて、いろいろ勉強した。freeeや会計士の人のYouTubeの動画でも勉強したし、一番教えてもらったのは　ChatGPTだった。ただ、ChatGPTはもっともよいアドバイスをしてくれるとは限らないので、一旦言われた通りにやってみて、後から修正することも多々あった。複式簿記の仕組みがやっと理解できてきたので、2026年はあまり迷うことなく、取引を登録できると思う。

IEC 62304 実践ロードマップ ― 基礎理解から開発プロセス構築・運用まで ― （情報機構セミナーのお知らせ）

2025-09-06T08:20:00.002+09:00

このたび、情報機構主催のセミナーにて、IEC 62304 に関する講演を行うことになりました。

開催日: 2025年12月（詳細は情報機構の案内ページをご覧ください）
会場: 東京・大井町
時間: 10:30〜16:30
テーマ: IEC 62304 実践ロードマップ ― 基礎理解から開発プロセス構築・運用まで ―

セミナー概要

IEC 62304 は、医療機器ソフトウェア開発における国際的な基本規格であり、ソフトウェアライフサイクルプロセスを体系的に定義しています。
しかし実際には、

規格条文をどのように開発現場に落とし込むか？
他の規制要求（FDA、IMDRF、日本PMDAなど）との整合をどう取るか？
中小規模の開発組織でどのように運用すればよいか？

といった課題に直面している企業が少なくありません。

今回のセミナーでは、単なる規格解説にとどまらず、実際の現場支援で培った具体的なアプローチを交えながら、以下のポイントを詳しく解説します。

主な内容

IEC 62304 の基本構造と条文の理解
開発プロセスを構築・運用するための実践的な手順
リスクマネジメント（ISO 14971）との関係
市販ソフトウェア（SOUP）の扱い方
海外規制（FDA、IMDRF ガイダンス等）との関連付け
実際の現場で起きやすい「つまずき」とその解決策

特に今回は、リアル会場開催となるため、オンライン動画では伝えきれない、現場ならではの生々しいエピソードや実体験もご紹介する予定です。

参加のご案内

セミナーの詳細・お申込みは、情報機構の公式ページからご確認ください。

現場で規格対応に悩まれている方にとって、必ず役立つ実践的なヒントをお持ち帰りいただける内容になっています。
東京・大井町の会場で、皆さまとお会いできるのを楽しみにしています。

自動車業界と医療機器業界のリスクマネジメントの違い

2025-07-14T14:20:00.003+09:00

医療機器ソフトウェアの国際規格を検討する国内委員会に長年参加していて、機能安全規格である IEC 61508（機能安全）を医療機器業界にも採用せよという圧力が度々かかり、その都度、医療機器業界側がその要求を跳ね返してきた歴史を聞いてきた。

なぜ、そのような圧力がかかるのか。

その理由のひとつは、IEC 61508（機能安全 Functional Safety）の認証ビジネスの市場は 2023年に55億ドル規模となっており、その中で自動車分野が最も高い 10%で成長していて、この認証ビジネスの市場に医療機器も含めようという思惑があるからだ。

図2024〜2032 年の機能安全認証ビジネスの年平均成長率（CAGR）予測。全体市場は年 7.5 % で拡大する一方、ISO 26262 への適合需要が牽引する自動車セグメントは年 9.9 % と最速で成長すると見込まれる（出典：Allied Market Research、Global Market Insights）

そこで今回、AIの分析も交えながら、機能安全を採用している自動車業界と医療機器業界のリスクマネジメントの違いを掘り下げてみたいと思う。

A. 筆者が考える自動車業界と医療機器業界のリスクマネジメントの違い

自分は自動車業界でのソフトウェア開発経験はないのだが、ずっと、IEC 61508（機能安全）や ISO 26262（自動車の機能安全規格）についてアンテナを張ってきた。

そして、出した結論がこうだ。

自動車はサプライヤーが提供する部品を、完成品メーカーであるOEMがアセンブリして自動車に仕上げる。OEMはサプライヤーに対して、ISO 26262 への適合を条件にすることで、自動車の安全性を高めたい。安全が規格によって担保された部品を組み合わせることでシステムの安全を確保するという、フォールトアボイダンスの考え方を採用している。

一方、医療機器は、医療機器の種別によって、基本性能や基礎安全がまったく異なる。例えば、人工呼吸器と画像診断装置では、基本性能も基礎安全も異なり、安全対策も代わってくる。そのため、医療機器の安全を担保するためには、医療機器メーカーが主導してリスクマネジメントを行い、ソフトウェアを含む各部品に不具合があるとい前提でフェールセーフやフォールトトレランスの安全設計を行う必要がある。

自動車業界のボトムアップのリスクマネジメントのアプローチに対して、医療機器業界はトップダウンのリスクマネジメントであるというのが、自分の考えであった。

参考：　日経ものづくり 2010年8月号の特集記事『ソフトが揺さぶる製品安全』

また、自動車の基本性能は、「走る・止まる・曲がる」であり、医療機器と違って、その点は自動車というカテゴリーでは変わらないので、リスクマネジメントの方向性はどの自動車でも変わらず、OEMがサプライヤーに求める機能安全は保険のようなもので、基礎安全の確保の本質ではないと思っていた。その証拠に、医療機器業界では、規制当局が ISO 14971や IEC 62304 を規制要件としているの対して、自動車業界では ISO 26262 は規制要件にはなっていない。これは、ISO 26262 がストレートに自動車の安全に必要不可欠という要件ではないという認識だからだと考える。

そういう状況なのに、機能安全の認証ビジネスは、2023年に55億ドル規模となっており、機能安全の認証機関やコンサルティングファームは、機能安全への適合の必要性をさかんにアピールし、またサプライヤーも自分達の担当製品が ISO 26262 の認証を取ったことをニュースリリースする。

個人的にはその風潮は機能安全の認証ビジネスを増長させるだけであって、認証取得にかけたコストの全てが自動車の安全にストレートには寄与していないと感じていた。

だから、認証機関やコンサルテーションファームが IEC 61508 と ISO 26262 と IEC 62304 をひとくくりにして、各製品のサプライヤーはこれらの認証を取得しなければならないと主張するたびに、IEC 62304 は、医療機器製造業者にもとめられる規格であり、医療機器のソフトウェアを委託開発しているソフトハウスに対してIEC 62304の認証は要求していないということを説明し訂正を求めてきた。

国際安全規格の体系（ISO/IEC Guide51型）　参照：「安全設計の基本概念」向殿政男監修, 日本規格協会, 2007年

その効果があったせいか、ここ数年このような間違った主張をするインターネット上での記事は見かけなくなったように思う。

そもそも、機能安全（Functional Safety）ってなんだ？とずっと疑問に思っていた。「機能」と「安全」をくっ付けたことに強い違和感を感じていた。ISO 14971 の安全の概念は、医療機器がもたらすすべての危害を分析し、対策して残留リスクを受容可能にすることがゴールなのだが、機能安全のゴールは、安全関連機能が要求(SIL/ASIL）を満たし、故障しても安全状態になることとなっている。どちらも、安全を目指しているものの、本質が違うように思えてならないのだ。

医療機器はトップダウンでリスクマネジメントの本質を追究していて、自動車の機能安全はボトムアップで安全な部品を集めればシステムも安全になるという、フォールトアボイダンスの概念であり、それは、リスクマネジメントの正しい考え方ではないと感じてしまう。

下記に AIが分析した IEC 61508（機能安全）と ISO 14971（医療機器リスクマネジメント）の違いを示す。

B. IEC 61508 と ISO 14971の違い──“同じリスクマネジメント”では語れない理由（AIの分析）

医療機器の開発者や品質担当者にとって、IEC 61508（機能安全の基本規格）と ISO 14971（医療機器リスクマネジメントの国際規格）は、どちらも「リスクを下げるための規格」として耳にする機会が多いと思います。しかし両者は守ろうとしている対象も、リスク低減の方法論も、本質的に異なるため、単純に置き換えたり“どちらが上位”と序列化したりはできません。以下にその違いを整理してみます。

1. スタート地点が違う

IEC 61508 は、電気／電子／プログラマブル電子（E/E/PE）システムが「故障しても人を傷つけない」ように設計する機能安全の総本山です。自動車、化学プラント、鉄道など各産業がここから派生規格（ISO 26262 など）を作ってきました。
ISO 14971 は、医療機器がもたらすあらゆる危害――電気的誤動作だけでなく、化学的暴露、使用ミス、サイバー攻撃など――を対象にした包括的なリスクマネジメントのフレームワークです。

2. “リスク”という言葉の意味が違う

IEC 61508 ではリスクを定量的指標（PFH, PFDavg）にブレークダウンし、あらかじめ目標値（SIL）を設定して達成可否を判断します。言わば「○○ Fit/Hour 以下にしなさい」という数値契約が核心。
ISO 14971 ではリスクを発生確率と危害の重大度の組み合わせで見積もり、残留リスクが「受容可能か／ベネフィットが上回るか」を経営レベルで判断します。こちらは医療上の価値と危害を秤にかける思考法です。

3. リスク低減の優先順位が違う

IEC 61508 は「故障を避ける → 故障を検出する → 安全状態に導く」という機能（機械的アクション）でリスクを下げる道筋を示します。冗長化や診断回路が主役です。
ISO 14971 はまず「本質安全設計（危険源そのものを除去）」を最優先とし、次に防護機構、最後に取扱説明書やトレーニングでカバーするという階層防御を採ります。医療現場では「ユーザー教育」も正式なリスクコントロール手段と見なされます。

4. ライフサイクルの捉え方が違う

IEC 61508 は開発～運用～廃棄までを “安全ライフサイクル” として工程管理しますが、フォーカスは安全関連システムの信頼性確保にあります。市販後のフィードバックよりも、設計段階の定量検証が重い。
ISO 14971 は市販後監視（PMS）を含めた“ファイル”の更新サイクルを重視し、臨床データや苦情情報を継続的にリスク評価へ反映するよう求めます。市販前のリスクマネジメントも要求していますが、製品が市場に出てからが本番、という発想です。

5. コンプライアンスの位置づけが違う

IEC 61508 は法律で直接義務づけられていない国が多く、「契約条件」「業界慣習」「第三者認証」で守られていることがほとんどです。
ISO 14971 は EU MDR、FDA QSR、薬機法など各国規制と密接にリンクしており、実務的には**“ほぼ必須”**。適合しなければ市販許可が降りない場合もあります。

C. 自動車は「走る・止まる・曲がる」だけではない。

AIから、こう指摘されたのでその論拠を示しておく。

1．「走る・止まる・曲がる」はクルマの“運動三本柱”

自動車の運動性能を語るとき、昔から業界や大学の講義、技術系メディアで必ず登場する切り口が「走る（推進）・止まる（制動）・曲がる（操舵）」の三つです。NSK の技術ストーリーや自動車教室の記事でも、この三要素を“車両運動の基本”と明言しています。行政サイドも同じ捉え方で、国土交通省は ADAS を説明するときに「走る・曲がる・止まるの基本操作を支援する制御」と表現します。したがって運動面に限定すれば、この三つをもって「自動車の基本性能」と呼ぶのは妥当だと言えます。

2．“総合性能”を語るには三要素だけでは足りない

ただし、現代の自動車は走行ダイナミクスだけで評価されるわけではありません。事故後の乗員保護や衝突回避といった安全性能、省エネ・排出ガス規制に絡む環境／経済性、静粛性や HMI（ヒューマンマシンインタフェース）、コネクテッド機能といった快適・情報性能、さらに耐久・整備性や OTA 更新まで含めた信頼性・保全性――多面的な“商品力”が求められています。ISO 26262 をはじめ最新の車両規格は、こうした横串領域（セキュリティ、サービス性、サステナビリティなど）まで要求を広げています。

要するに「走る・止まる・曲がる」は土台であっても、それだけで車づくりの全体像を語り切ることはできません。

3．機能安全の視点で見る三要素

ISO 26262 の HARA（ハザード分析とリスクアセスメント）では、走る・止まる・曲がるに関わる機能は最も高い ASIL、しばしば ASIL D に分類されます。理由は簡単で、この三要素が失われるとクルマは即座に軌跡を制御できなくなり、乗員・歩行者ともに致命的なリスクが生じるからです。

半導体ベンダ（Tier-2）はロックステップ CPU や ECC などで「走る」機能をフォールトトレランス化。
ブレーキ ECU のサプライヤ（Tier-1）は冗長回路やフェイルセーフ機構で「止まる」機能を守る。
OEM はシステム統合層で最小リスク操舵（Minimum Risk Manoeuvre）を実装し、「曲がる」機能の残留リスクを受け持つ。

このようにサプライチェーン全体で三要素を多重に支え、単一点故障で人命に直結しないよう作り込む構造ができています。

4．実務での活かし方──“三要素＋α”で考える

まずは三要素を押さえるクルマを動かす基礎指標として「走る・止まる・曲がる」は不変のものさしです。
しかし評価軸を広げる今日の車両企画・審査・規制対応では、安全・環境・快適・デジタルなど“＋α”を加えた多面的評価が欠かせません。
機能安全では最高リスク源三要素は最も高い ASIL を与えられるため、OEM から半導体まで冗長化・診断カバレッジを分担して確保するのが実務のセオリーです。

D. 機能安全を深掘りしてみる

ちなみに、冒頭の自分の機能安全に対する考え方について、AIに聞いてみたところ「ステレオタイプであり、そんなに単純化できるものではない」と怒られた。

特に、自動車の機能安全はフォールトアボイダンスで、フェールセーフやフォールトトレランスではないという考えについては、次のように反論された。また、サプライチェーンと認証ビジネスの関係についてもAIに聞いてみた。

1. サプライチェーンと「認証ビジネス」の関係を物語る４つの事実

まず押さえておきたいのは、ISO 26262 への適合が法律で強制されているわけではないという点です。道路運送車両法や FMVSS など各国の保安基準には直接組み込まれておらず、「業界が自主的に使うベストプラクティス」という立ち位置にとどまっています。

ただし OEM（完成車メーカー）は車両全体の安全責任を負うため、部品やソフトを供給する Tier 1、さらにその下位サプライヤーに対して「ISO 26262 に従った開発プロセスを示せ」と契約で要求します。“客先要求”という形でチェーンの下流まで波及するのが実態です。

ここで大きな役割を果たすのが TÜV、exida、SGS といった第三者機関の認証サービスです。ISO 26262 自体は自己宣言でも構わないのですが、入札競争力や訴訟リスク低減を狙って「外部のお墨付き」を取る企業が増えており、認証は半ばマーケティング・ツールとして使われています。

結果として「機能安全」市場は 2023 年時点で約 55 億ドル、しかも自動車分野が年 10 ％前後で伸びていると報告されています。――つまり、多数のサプライヤーが存在する構造と認証ビジネスの相互作用が ISO 26262 普及を後押ししているのは事実ですが、本質は“安全責任を証明可能に分担する”仕組みづくりにあります。認証はあくまでその手段にすぎません。

2. 規制当局が ISO 26262 を“強制しない”３つの理由

第一に、パフォーマンス・ベース規制という考え方があります。国連 WP.29（たとえば UN R157／ALKS）は「審査官は ISO 26262 の知識を持つべき」とは示しても、規格そのものへの義務的準拠は求めません。NHTSA や EU GSR II も同じく、「一定距離で自動緊急ブレーキが止まるか」といった結果を試験で示し、方法までは縛らないスタイルです。

第二に、民事責任との二重構造が機能しています。重大な欠陥があれば OEM は巨額リコールや PL 訴訟に直面するため、規格適合は「合理的注意を払った」ことを示す防御材料になります。強制されなくても自主的に従うインセンティブが働くわけです.

第三に、技術進化への追随性を確保したいという事情があります。ハード法規で特定の手順を固定すると、規格改版のたびに法改正が必要になりイノベーションを阻害しかねません。そこで当局は「成果を示せば手段は問わない」という枠組みを選びました。

要するに、「安全に直結しないから強制しない」のではなく、成果主義と民事責任を組み合わせて柔軟性と技術革新を両立させる――それが各国規制当局の基本スタンスです。

3. ISO 26262 の安全哲学は Fault Avoidance だけではない

誤解されがちですが、ISO 26262 が求める安全設計は三層構造です。

Fault Avoidance（系統的故障の未然防止）コーディング規約や静的解析、レビューといった開発プロセスで設計ミスを作り込まないことを徹底します。これはパート 2 とパート 6が詳述しています。
Fault Detection と Fail-Safe／Fail-Silent（故障後の安全停止）故障を完全にゼロにはできません。そこで高い診断被覆率で異常を検出し、規定時間内に安全状態へ遷移させる仕組みを要求しています。ブレーキ ECU なら「電圧異常を検知したら油圧を保持して停止」といった具合です。
Fault Tolerance／Fail-Operational（故障後も機能を維持）自動運転のように「止まること」自体が危険なケースでは、冗長系へ切り替えて走り続ける設計が必要になります。第2版ではこの Fail-Operational コンセプトが補強されました。

このように ISO 26262 は「故障を避ける」「故障を見つける」「故障に耐える／安全に止める」という総合戦略をライフサイクル全体に埋め込んでいます。Fault Avoidance だけに特化した規格ではありません。

まとめ

普及ドライバー：OEM が契約でサプライヤーに要求し、第三者認証が市場競争力になる。
規制の立ち位置：法的強制ではなく、成果義務と PL 法が実効性を担保。
安全哲学：Fault Avoidance、Fail-Safe、Fault Tolerance を一体化した多層防御。

ISO 26262 を語るときは、「誰がどの層の安全責任を担い、どう証明するのか」という視点で見ると、サプライチェーンと規制の力学がクリアに見えてきます。

E. 医療機器は IEC 61508を義務にしていない

医療機器が IEC 61508を義務にしていないことを AI にまとめてもらった。

医療機器が IEC 61508 を「義務化しない」と決めてきた経緯──公式文書を手がかりに読み解く

「医療機器にも IEC 61508 を強制すべきだ」という声は過去に何度も上がりましたが、結局いまも“適用除外”のままです。なぜそうなったのかは、議事録を追わなくても一次資料の本文にはっきり書かれています。ポイントになる４つの証拠を時系列で追ってみましょう。

1. 61508 自身が “医療機器は対象外” と宣言している

最新の第２版（2010）Part 1〈Scope〉には「IEC 60601 シリーズに適合する医療機器には適用しない」という一節が残っています。汎用機能安全規格側が自ら線引きをしているわけです。iTeh Standards

2. 医療ソフト専用規格 62304 が「参考にするが要求しない」と明記

IEC 62304 第２版 CDV の Annex C.9 は、

61508-3 の手法は参考情報として使ってよいが、要求事項としては採用しない── と断言し、SIL ではなく “Software Process Rigor Level＋ISO 14971” を採用する理由を説明しています。MLFP Content

3. 学協会ガイドでも「医療だけ例外」と総括

IET の 2020 Medical EMC Guide は、

61508 をベースにした機能安全規格は数多いが、医療規格だけは ISO 14971 が基盤と繰り返し指摘しています。機能安全の専門家が書いたハンドブックでも同じトーンです。Interference Technology

4. 直近の専門家コメント（2025）も同じ見解

LinkedIn で公開された機能安全選定ガイド（2025/7）は、

医療製品（IEC 60601 系）は IEC 61508 の例外で、現時点で明確にカバー外とまとめています。業界側の認識がいまも変わっていないことが分かります。LinkedIn

どう読み取るか

IEC 61508 側の注記は初版（1998）から一貫して削られていない。産業プロセス系 TC 65 と医療系 TC 62 が早期に合意した線引きが、条文という形で固定化されたと考えられます。
TC 62/SC 62A が 62304・60601 系列を策定し、自前のリスクマネジメント（ISO 14971）を採用。SIL を持ち込まず、医療の「ベネフィット vs. リスク」思考を優先しました。
学協会や業界解説も「医療は 61508 例外」と繰り返し明記。これは単なる意見ではなく、IEC 本体の Scope 注記と Annex が一次根拠になっているため、業界全体がそれを追認してきた結果です。

結論

医療機器への IEC 61508 強制を業界が拒んできたことを示す一次エビデンスは、

医療機器における安全規格の枠組みは、機能安全＝61508 系とリスクマネジメント＝ISO 14971 系を明確に分離して進化してきた──これが公式文書から読み取れる歴史的事実です。

F. 最後に

AIの力を借りて、自動車業界と医療機器業界のリスクマネジメントの考え方の違いについて深掘りすることができた。

下記の図は、日科技連主催のソフトウェア品質シンポジウム2010（SQiPシンポジウム2010）で広島市立大学の大場充先生が、ソフトウェア品質論の歴史を解説した内容を図にしたものである。（解説記事はこちら）

広島市立大学大場充教授講演「民主主義原理に基づくソフトウェア品質論入門」を参考に作成

「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論で、1960年代に主流であったゼロディフェクト運動がそれに象徴する。しかし、その後、ソフトウェアの不具合をゼロにすることは不可能という考え方が常識になり、ソフトウェアの開発プロセスの中でソフトウェアの品質を高める考え方に変わりつつある。また、日本では古くから製品の価値や顧客満足度を重視する「当たり前品質」や「魅力的品質」の考え方があった。

医療機器のソフトウェアライフサイクルプロセス規格 IEC 62304 は、プロセスアプローチであるとともに、ISO 14971のリスクマネジメントを要求するリスクベースアプローチを組み合わせた規格である。

その視点で、自動車の機能安全規格を眺めたときに、機能安全規格はサプライヤーにゼロディフェクトを要求しているのであって、OEMが主体的に自動車のリスクマネジメントを追究していないのではないかと感じてしまう。

今回 AI の助言もあって、そう簡単なロジックでは片付けられないと指摘されたわけだが、自動車に搭載されるソフトウェアの規模が増大する現状において、サイバーセキュリティも含めてソフトウェア起因のどんな障害が発生するのか予想も付かず、自動車の中でECU同士が通信し合う巨大なネットワークシステムが構築されている現状を考えると、医療機器業界が長年やってきたように、完成車メーカーであるOEMが主体となって、今後ソフトウェア起因のどんなリスクが存在しうるかをリスク分析した上で、トップダウンでリスクコントロール手段を設計する必要があるのではないかと感じる。

G. 参考

15分で分かる ISO 14971（17分）

ISO 14971 規格解説動画（47分）

FDA公開「AI 搭載医療機器リスト」最新アップデートを読み解く

2025-07-11T07:02:00.003+09:00

FDA公開「AI 搭載医療機器リスト」最新アップデートを読み解く― 2025年7月版 ―

1️⃣ はじめに｜なぜ “いま” このリストなのか

米FDAの 「Artificial Intelligence-Enabled Medical Devices List」 は、AIを組み込んだ医療機器（SaMD／医療機器ソフトウェアを含む）の承認・認可済み製品を一括把握できる公的データベース です。開発企業・臨床現場・投資家が同じテーブルで議論できる “共通言語” を提供するという点で、極めて重要なリソースになっています。U.S. Food and Drug Administration

2️⃣ 2025年5月30日更新：リストはついに1,000件超え

最新エントリー日時：2025年5月30日付の複数機器（Aidoc BriefCase-Triage ほか）が追加。U.S. Food and Drug Administration
件数の急増：2024年8月時点で903件だった登録数が、2025年6月には1,000件を突破。わずか10ヵ月で+100件以上と、成長曲線はなお加速中です。ラップスSTAT

ポイント
放射線科系が依然トップシェアですが、心血管・眼科・生殖医療や病理分野などへも裾野が拡大。いまや「AI = 画像診断専用」という常識は過去のものになりつつあります。

3️⃣ FDAが強調する “AI 搭載医療機器リストの使い方”

リストの機能	実務への応用ヒント
CSV/Excel 形式でダウンロード可	市場分析や競合調査に活用。社内BIツールへ取り込み、デバイス種別・企業国籍・審査ルート（510(k)／De Novo／PMA）別トレンドを可視化すると示唆が得やすい。U.S. Food and Drug Administration
各機器の決定概要へ直リンク	“何が評価され、どこまで詳細を開示しているか” を逆算し、自社の PCCP（事前定義変更計画）設計や営業資料のエビデンス強化に利用。
AI関連用語ベースの抽出	公開サマリーに AIモデル構造／学習データ概要／バージョン管理などを明示すると、FDAが次回更新でタグ付けしやすくなる → 透明性＝PR効果に直結。

4️⃣ “Foundation Model” 時代への布石

FDAは今後、LLM（大規模言語モデル）やマルチモーダルAIを搭載した医療機器を明示的にタグ付け する方針をページ内で表明しています。つまり、“生成AI” を活用するSaMDの開発者は 早期から透明性とバイアス管理 を示すことが、リスト収載⇒市場信頼性確保への近道になります。U.S. Food and Drug Administration

5️⃣ スタートアップ／投資家向けアクションプラン

競合マッピング：ダウンロードしたデータを◆製品領域×リスク分類◆でピボット。ホワイトスペースを特定。
審査ルート分析：同程度リスクの先行事例を抽出し、510(k) なのか De Novo なのかを確認。早期上市戦略の指針に。
資金調達資料での活用：FDA公開情報で裏付けされた TAM（Total Addressable Market）試算を提示し、説得力向上。
PCCP設計の先行研究：リスト中で公開概要に “predetermined change control plan” を示す製品を探し、ドキュメント構成をベンチマーク。

6️⃣ AI医療機器で先行している米FDAのAI医療機器ガイダンスの内容を確認しましょう。

“規制を制する者が、AI医療機器市場を制す”

Medical Software Consulting では、AI医療機器向けのFDAガイダンス 2点の解説動画（AI医療機器ライフサイクルガイダンス、AI医療機器 PCCPガイダンス）を公式 YouTubeチャネルにて公開しています。世界に先駆け、急成長している AI医療機器に米FDAがどのような要求をしているのかが分かります。

Medical Software Consulting 解説動画一覧

🔗 参考リンク（URL付き）

FDA｜Artificial Intelligence-Enabled Medical Devices（公式ページ）
https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-enabled-medical-devices U.S. Food and Drug Administration
FDA｜Good Machine Learning Practice for Medical Device Development: Guiding Principles
https://www.fda.gov/medical-devices/software-medical-device-samd/good-machine-learning-practice-medical-device-development-guiding-principles U.S. Food and Drug Administration
FDA｜Marketing Submission Recommendations for a Predetermined Change Control Plan for AI-Enabled Device Software Functions
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial-intelligence U.S. Food and Drug Administration
RAPS｜Study: Data lacking for AI-enabled medical devices cleared by FDA（903件分析, 2025年4月）
https://www.raps.org/news-and-articles/news-articles/2025/4/study-data-lacking-for-ai-enabled-medical-devices ラップス
STAT News｜As AI device market grows, FDA’s accounting goes silent（2025年6月20日）
https://www.statnews.com/2025/06/20/fda-ai-reporting-goes-silent-more-medical-devices-hit-market/

FDAサイバーセキュリティガイダンス2025年6月改訂版解説

2025-07-05T09:48:00.002+09:00

速報 FDAサイバーセキュリティガイダンス2025年6月改訂版

医療機器サイバーセキュリティ：品質システムの考慮事項と市販前申請の内容

概要

FDAは2025年6月、医療機器サイバーセキュリティガイダンス「Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions」の改訂版を発行しました。2023年版（最終化ガイダンス）からの主な変更点として、AI/ML搭載デバイス向け要件の拡充、SBOMの詳細化、サプライチェーンリスク管理の強化などが挙げられます。

主な変更点

✅AI/ML搭載デバイス向け要件を拡充

AI/MLを活用する医療機器ソフトウェアにおけるサイバーリスクへの対応について、AIモデルや学習データ管理の脆弱性も含めたリスク評価が必須となりました。脅威モデリングでもAI特有の攻撃シナリオ（例：モデル逆流攻撃）を考慮することが明記されています。

✅SBOMにAIモデル情報の追加を義務化

SBOM（ソフトウェア部品表）に、デバイスに搭載するAIモデルや外部AIライブラリの以下の情報を含めるよう更新されました：

バージョン
トレーニングデータ概要
ベンダー情報

✅ソフトウェア・サプライチェーンリスク管理の詳細化

サプライチェーンリスク管理を強化し、第三者ソフトウェアやクラウドサービスの脆弱性対応計画を脆弱性管理計画に組み込むことが必須化されました。

✅脆弱性開示・対応スケジュールの具体化

脆弱性発見から公表、パッチ提供までのタイムライン目安（例：重大度Criticalなら60日以内）を設定するよう推奨され、管理計画に明記することが求められるようになりました。

✅多拠点連携を想定したマルチペイシェントハーム評価

複数施設に配備される機器を想定し、同時多発的に複数患者へ影響を及ぼすリスクへの設計対応を明記するよう更新されました。

✅規格参照の更新

FDAが推奨するセキュリティ関連規格リストに以下が追加されました：

IEC 81001-5-1:2024（医療機器ソフトウェアのセキュリティライフサイクル規格最新改訂版）
ANSI/AAMI SW96（SBOM標準化仕様）

✅人材・体制強化を推奨

設計・リスク管理に携わる組織に対して、サイバーセキュリティ専任者配置やトレーニング実施をガイダンス上で推奨されました。

まとめ

2023年版ガイダンスから2年を経て、AI/MLの台頭とサプライチェーン脅威の深刻化を反映した内容に進化しました。医療機器メーカーは、AI・クラウドを活用したソフトウェアの脆弱性管理を含め、開発初期から詳細な文書化・体制整備を徹底する必要があります。

Medical Software Consulting では Youtube公式チャネルにて、2023年版のガイダンスの解説動画は下記にて解説していますので、今回の改定内容と合わせてご覧下さい。

✅FDA 医療機器サイバーセキュリティガイダンス(2023年版）解説（10分）

なお、本ガイダンスでも AI/ML を考慮した内容が追加されています。FDAの医療機器AI系ガイダンスについても解説動画をご覧下さい。

✅FDA AI医療機器ライフサイクルガイダンス（12分）

✅FDA PCCPガイダンス（AI医療機器向け変更計画の戦略的活用）（11分）

参照情報

医療機器ソフトウェアのリファクタリング

2025-07-04T15:54:00.001+09:00

『医療機器ソフトウェアのリファクタリング』という動画を作った。

この動画を作成するにあたっては、第8回組込みシステム開発技術展（ESEC）　2005年6月29日～7月1日専門セミナーで『高信頼性を確保するソフトウェア開発手法と実践』という講演をしたときのスライドを使った。

20年前に作ったスライドだが、このときのスライドが今でも使えるということは、ソフトウェア開発の世界はそんなに進化していないのかもしれない。

この動画を作ったきっかけは、医療機器ソフトウェア（SaMD）を新規に開発しようとするスタートアップ企業は、まず、フィージビリティスタディとしてソフトウェアを作ってしまい、いざ、薬機法申請するために規制要件である IEC 62304（医療機器ソフトウェアーソフトウェアライフサイクルプロセス）に適合しようとするという話しを聞いたからである。

IEC 62304 は、リスクベースアプローチなので、そのものが不具合を起こしたときに患者危害に至るようなソフトウェアモジュールはリスクレベルが高い（ソフトウェア安全クラスC）とし、もっとも厳しいアクティビティ、タスクを課す。

だから、ソフトウェアのアーキテクチャを設計する際に、リスクが高いモジュールとリスクが低いモジュールを分離しておかないといけない。リスクが高いモジュールとは、多くの場合、診断や治療を担うソフトウェアモジュールのこととなる。診断や治療を担うソフトウェアが期待通りに働かないと、誤診したり、意図しない出力を患者に与えたりするからだ。

また、例えば、意図しない出力を出していないかどうかを判定するリスクコントロール手段としてのソフトウェアや、セルフチェック機能が誤動作して、医療機器の機能が使えなくなるような場合のソフトウェアもソフトウェア安全クラスはBやCとなる。

だから、医療機器ソフトウェアを開発するときは、フィージビリティスタディ（要素技術開発やコンセプト開発）のフェーズでも、リスクの高いモジュールは、リスクの低いモジュールと分離して、高凝集、疎結合にしておかないといけないのだが、医療機器できるかどうか、臨床的に効果が見込めるかどうか分からない段階では、まず、どんなものでもいいから、動くソフトウェアが欲しくて、医療機器ソフトウェアの開発経験が無い、IEC 62304 の規格要求も知らないソフトウェアハウスに、とりあえずソフトウェアを作ってもらってしまう。

実際、臨床効果が見込めなければ、資金調達も難しいだろうし、最初から完璧な規格適合ができるようなリソースも用意できない状況では、取りあえず動くソフトウェアを作るというアプローチを取るのも仕方がないだろう。

しかし、臨床的にも「これはいける」となって、資金も調達できる見込みが立ったときに、CEOはソフトウェアを作り直すという決断はしないだろう。おそらく、動いているんだから、試作レベルで作ったソフトウェアをそのまま製品にしろ、テストでバグが見つかったら修正すればよいと考えるはずだ。

でも、そんな考えでは、IEC 62304 の規格には適合できないし、そもそも、市場に出したときに患者危害に至るような障害が発生する危険性が高まる。本当に障害が発生すれば、リコールになって膨大な回収費用を被ることになる。1回も痛い目にあっていない経営者には、その痛みは分からないかもしれない。

リコールのコストもさることながら、患者危害に至れば、国民の安全を守ることはできないから、各国の規制当局は医療機器ソフトウェアの市販前申請の際に、キチンと規格に適合しているかどうかをチェックする。

ソフトウェアは中身が見えないから、チェックするレビューワーの技量にもよってしまうが、まともにアーキテクチャ図が描けていないような場合は、米国FDAなら、まず、申請は通らない。

じゃあ、どうすればよいかを解説したのが今回の動画になる。

ソフトウェアの詳細な技法のことを説明してもピンとこないと思ったので、紙芝居風にしてイメージを掴んでもらうことにした。

ざっとこんな感じだ。

一度作ってしまったソフトウェアシステムのイメージ

診断・治療を実現している機能を切り出し、結合度を弱めます

コア資産を高凝集・疎結合にします

まず、コア資産のバグを摘出します

残りのシステムをドメインに分割します

ドメインごとにバグを摘出し、不具合を抑制します

コア資産を分離し、ドメイン分割することができました。

実際にはそんなに簡単にはいかないのだが、まあ、イメージを掴んでもらうということならこんなもんだろう。

実際、米国FDAは、2023年に「医療機器ソフトウェア機能の市販前申請の内容」というガイダンスを出して、医療機器ソフトウェアを、医療機器のソフトウェア全体ではなく、医療機器ソフトウェア機能（MDF=Medical Software Function）として審査するように方針を変更した。

これは、今や医療機器は単独で動くのではなく、データをネットワーク経由で他のシステムに送信したり、クラウドに送ってAI解析したりすることが当たり前になって、どのソフトウェア機能が何のハードウェアや他のソフトウェアとつながって、診断、治療、予防を担っているのかを把握した上で審査しなければならなくなってきたからである。

そのため、医療機器ソフトウェア内部の機能が、ネットワーク接続した医療機器周辺のデバイスやインターネット接続してクラウド内で動いているAI機能などとどのような通信をしているのか、それぞれのソフトウェア機能の要求仕様は何なのかをシステム&ソフトウェアアーキテクチャ図で示すことを要求している。

下記布図は、FDAの医療機器ソフトウェア機能の市販前申請の内容ガイダンスの附属書に掲載されている 3つの仮想の医療機器のシステム&ソフトウェアアーキテクチャ図を UMLツール EnterpriseArchitectでトレースしなおした図だ。

Figure1: Hand-Held Diagnostic Device

Figere2: Implantable Therapeutic Device with Patenet-and Provider-Facing Applications

Figure3: Cloud-based Device Algorithm for Analyzing Previously Captured Medical Images

これらの図の表記法は FDAのオリジナルだが、UMLツール EnterpriseArchitectでこの表記法で描けるような設定ファイルが用意されている。（設定ファイルが欲しいかたは info@medical-sc.com までご連絡ください）

この表記法の特徴は、凡例にあるように、各モジュールの線種、色、枠線で、ソフトウェアモジュール、ハードウェアモジュール、OTS、その他の機能、通信の方向などが分かるようになっている。実は、FDAはこのガイダンスのドラフトガイダンスでは、やや違った表記法を採用していて、ガイダンスをファイナライズしたときに、少し簡略化したようだ。

FDAがこのシステム＆ソフトウェアアーキテクチャ図で知りたいことは次の3点だということが、この図をトレースして分かった。

ハードウェアモジュール、ソフトウェアモジュール、OTS（市販ソフトウェア）、その他のモジュール（医療機器の基本機能ではないモジュール）の種別と、それらのモジュール間のインタフェースの方向性が知りたい。
各モジュールには、要求仕様があるはずなので、それぞれのモジュールに要求仕様のIDを付与してトレースできるようにする。
当該医療機器本体だけでなく、ネットワーク接続できる周辺機器やクラウドサービスを明示させる。

そういった意味では、UMLの表記法とは異なるが医療機器ソフトウェアを機能レベルでリスクがあるかないかを俯瞰するための表記法としてはシンプルで合理的だと感じる。

各モジュールに要求仕様のIDを書かせているところが味噌で、そのIDを辿ることでそのモジュールが診断、治療を提供しているのか、また、リスクコントロール手段となっているのかを判断できるし、仮にそうだったとしたら、そこに関連した検証記録やバリデーションの記録、IEC 62304 で求められているアクティビティやタスクが実行されているかどうかを追うことができる。

よって、フィージビリティスタディのフェーズで取りあえず試行錯誤で作ってしまったソフトウェアを FDAに申請しようとしても、このようなアーキテクチャ図を描くことができず、門前払いを食らうことになる。

そのため、取りあえず作ってしまった分割されていないソフトウェアの固まりは、医療機器としてのリスクレベルを踏まえてリファクタリングしないといけないのだ。

そんな動画を作っていたら、たまたま、Software Design 2025年8月号の特集記事が『第1特集　そのリファクタリング、今やるか？見送るか？適切なタイミングとビジネス面の価値』だった。こちらは IT業界のリファクタリングの話しらしい。

医療機器業界の方には、是非、医療機器ソフトウェアのリファクタリングの動画を見ていただきたい。（18分）

FDA 医療機器ソフトウェア市販前申請ガイダンスの解説動画を作りました

2025-06-18T19:08:00.000+09:00

米FDA 医療機器ソフトウェア市販前申請ガイダンスの解説動画を作りました。アメリカでソフトウェア搭載の医療機器、または、そのものが医療機器となるソフトウェア（SaMD）を上市しようとしたら、このガイダンスの要求に沿って作成したドキュメントを提出しなければなりません。

日本国内やEU、一般海外は医療機器ソフトウェアに関しては、IEC 62304 さえできていれば、どうにかなりますが、FDAの審査はレベルが違います。ものすごく厳しくて、ガイダンスをちゃんと読み込んで、ちゃんとガイダンスの意図を理解した上でドキュメントを提出しないと、申請は通りません。

ガイダンス通りに作っていないと、照会がいくつもやってきて、答えられずに180日経過してしまうと、その申請は却下されてしまいます。180日長いと思うかもしれませんが、臨床試験や実験をしないと答えられないような内容だと、時間はどんどん過ぎていきます。

米国FDAへの申請を考えている方は、まず、この約30分の動画を観て、どれくらい厳しいのかを感じてみてください。FDAはAIの医療機器のこともしっかり考えていて、市販後の機械学習のことも市販前申請に審査します。

トランプ政権がFDAの職員も大量にクビにして、一部再雇用されたりして、今は混乱しているかもしれませんが、そのことでFDAの審査が甘くなるとはとても思えません。

医療機器以外のドメインの方も、医療機器ソフトウェア規制がどんなものか、この動画で様子を観てください。

紹介動画（ショート）

解説動画本編

15分でわかる IEC 62304 の動画を作りました

2025-06-15T18:56:00.005+09:00

15分で分かる医療機器ソフトウェア規制シリーズとして、IEC 62304（JIS T 2304）医療機器ソフトウェアライフサイクルプロセスの解説動画を作ってみました。

長い動画は不評という記事をみて、自分で作った1時間ちかい解説動画をAIにお願いして 15分くらいのシナリオにしてもらい、ナレーションの台本も作ってもらって、AI音声で早口で音声を会わせました。結局20分になってしまいましたが。

AIの出力を修正したり編集したりするのに一日かかりましたが、自分でイチから作ったら、一週間はゆうにかかるところを一日でできたので、相当なスピードアップです。

AIは、「分かりません」とは言わないので、「そこは言い切らないで欲しい」というところも自信もって言い切ってくるので、ファクトチェック、レビューは必須です。

ファクトチェックは必要としても、ものすごく優秀な部下がいる感じで、頼もしい限りです。

Medical Software Consulting を起業しました

2025-05-30T20:25:00.002+09:00

6月1日付けで、Medical Software Consulting を起業し、ポータルサイトを開設しました。医療機器ソフトウェアの規制対応支援がメインでドメインに特化したコンサルティングを行う予定です。特に見てもらいたいのは、起業に合わせて作った youtube の動画チャネルです。

医療機器ソフトウェアの規格適合に必要な国際規格の1時間弱の解説動画がメインで、音声を VoicePeakという AIソフトで作りました。原稿を書くのは大変でしたが、国際規格の内容は3年に一回修正されるので、変更点を差し替えるのもAI音声の方が楽だし、VoicePeak は本当になめらかに喋ります。（規格名称の発音だけがイマイチですが。）

それと、解説動画を紹介するショート動画も、AIを使って身振り手振り付きでアバターが喋っています。

解説動画は無料ですが、Google Classroom を使った教育マネジメント（動画視聴管理、チャット、質疑応答、修了テスト、力量評価）を有料にしています。テストはベースを ChatGPT に作ってもらいました。

今回、ChatGPT 含め、AIを駆使することでかなりのことが、低価格で実現できて、時代の変化を感じます。

AIでかなりのことが省力化できるので、人間は人間と人間の関係性の部分に注力を注ぐべきなんだろうと思います。ただ、AIはあたかもホントのこのようように間違ったことを自信ありげに言ったりもするので、正しいか間違っているかを判断する素養が人間側に必要です。 AIを使いこなすには、対象となる課題を一度は一通り経験していることが必要と感じています。一度やったことがあって、失敗もしたことがあるからこそ、AIのサジェスチョンを有効に利用できます。生成AIの出力はそのままでは商品にならない、または、何回か修正を繰り返さなければ、満足できる形にならないこともあります。でも、自分で全部やるよりははるかに楽です。今度、もの作りにおいては、経験の浅い技術者に対象ドメインのもの作りを企画から製造まで、一通りやりきるような PBL（Project Based Learning）をやらせることが重要になってくるでしょう。その経験の上で、AIを使うようになると、もの作りの効率化が進むと思います。もの作りの経験なしに AI に頼っても、正しいサジェスチョンかどうかを判断できないので、顧客価値を高めるためのもの作りを達成するのは難しいと思います。世の中にすでに存在するものを模倣してアレンジすることはできるのですが、新しい価値を生み出す開発は人間がコントロールしないとダメだと思います。

ポータルサイト

youtube チャネル（規格解説動画）

「組込みソフトエンジニアを極める」がB5版のオンデマンド出版になります。

2023-11-03T23:17:00.004+09:00

「リアルタイムOSから出発して組込みソフトウェアエンジニアを極める」ですが、印刷製本コストが値上がりで、今までの形式（普通の印刷）や価格では重版はできなくなり、オンデマンド出版で判型がB5になります。価格もちょっとだけ上がって税込み2200円になります。

大きさは一回り大きくなって、やや薄くなり開きやすくなったと思います。

日経BPでの初版が2006年で、その後、エスアイビー・アクセスでの初版が2011年、改訂版が2016年、オンデマンド版が2023年となります。

2006年の初版から 17年経ちもう少しで一万部ですが、まだまだ使える内容です。実際、組込みソフトウェアもネットワークにつながることが普通になって、規模も増大する一方です。とはいうもののソフトウェアプロダクトラインをちゃんと実践している企業ってまだ少ないですもんね。

この本の原稿書いていたときは、セキュリティのことなんか一ミリも考えていませんでしたが、今原稿書くなら、セキュリティについてもガッツリ解説しないとダメなんだろうなって思いますね。

そういう意味では、セキュリティについてもクリアできないと、組込みソフトエンジニアを極めたことにならないんだな。これから社会に出て行くエンジニアって、学習しなければいけないことがどんどん増えていくみたい。でも、そこをAIがサポートして補っていくんだろう。

となると、ソースコード書くところよりも、もっと上流の設計の考え方とか、ビジネスと技術をどう融合させるかといったところのが技術者の大事な役割になると思うので、まだまだこの本が役に立つ時代は続きます。この本は、技術だけでなく、ビジネスや組込みソフトウェア開発そのものにエンジニアがどう向き合うかについても書いたつもりです。

Amazon の原稿判型の在庫がなくなり次第、B5版のオンデマンド版に変わる予定です。

FDAの医療機器ソフトウェア機能の市販前申請ガイダンスが18年ぶりに改訂された

2023-06-28T15:48:00.005+09:00

FDA 米食品医薬品局が、医療機器を市販前申請する際の「デバイスソフトウェア機能の市販前申請の内容」（Content of Premarket Submissions for Device Software Functions）のガイダンスを 2023年6月14日に発行した。

このガイダンスは、米国で医療機器を販売する際に、ソフトウェアが含まれている場合は、このガイダンスに従って必要なドキュメントを FDA に提出しなさいという内容だ。

この文書は、2005年5月に発行された「医療機器に含まれるソフトウェアの市販前提出の内容に関するガイダンス」に代わるもので、内容はだいぶ変わっている。

とはいうものの 2021年11月にドラフトが公開されていたので、こんな感じで変わるということはアナウンスされていた。（FDAのガイダンスはドラフト→ Final というプロセスを踏むが、ドラフト段階でもできているかどうか聞かれる）

一番の変更点は、2005年までのガイダンスでは、タイトルが「Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices」（医療機器に含まれるソフトウェアのための市販前ガイダンスの内容）だったのが、「Content of Premarket Submissions for Device Software Functions」（デバイスソフトウェア機能の市販前申請の内容）になった点だ。

これは何を意味しているかというと、2005年のガイダンスでは、「医療機器に含まれるソフトウェアに関するいろいろな説明をせよ」だったのが、2023年のガイダンスでは、医療機器に含まれるではなく、医療機器ソフトウェアの機能がターゲットになったという点が異なる。

同じように見えるかもしれないが、2005年のガイダンスでは、医療機器に含まれるソフトウェアが審査の対象だった。2023年のガイダンスでは、医療機器に含まれるソフトウェアだけでなく、医療機器が提供する機能として、医療機器が連携するクラウド上のソフトウェアや、スマホやタブレットのブラウザやアプリケーションなども含めて「医療機器単体でできることだけでなく、ネットワークを含めたトータルのシステムでできること、しようとしていること」を説明することが求められるようになった。

以前は、ソフトウェアに障害が発生したときの患者への影響に応じて Level of Concern が Minor, Moderate, Major の3段階に設定され、それぞれのレベルに応じて提出するドキュメントが分かれていたが、今回は、基本ドキュメントと拡張ドキュメントの2段階になった。

拡張ドキュメントになる条件は以下になる。

医療機器のソフトウェア機能に関連する障害や欠陥が、患者、デバイスの使用者、または使用環境の他の人々に対して死亡または重大な負傷の恐れを伴う危険な状況を引き起こす可能性がある場合

下記に各ドキュメントレベルに応じて、求められる内容を示す。

Software Documentation Elements ソフトウェアドキュメント要素	Basic Documentation Level 基本ドキュメントレベル	Enhanced Documentation Level 拡張ドキュメントレベル
Documentation Level Evaluation ドキュメントレベル評価	A statement indicating the Documentation Level and a description of the rationale for that level. ドキュメンテーションレベルを示す声明と、そのレベルの根拠の説明。
Software Description ソフトウェア説明	Software description, including overview of significant software features, functions, analyses, inputs, outputs, and hardware platforms. ソフトウェアの説明、重要なソフトウェアの特徴、機能、分析、入力、出力、およびハードウェアプラットフォームの概要を含める。
Risk Management File リスクマネジメントファイル	Risk management plan, risk assessment demonstrating that risks have been appropriately mitigated, and risk management report. リスクマネジメント計画、リスクが適切に軽減されていることを示すリスクアセスメント、およびリスクマネジメント報告書。
Software Requirements Specification(SRS) ソフトウェア要求仕様書(SRS)	SRS documentation, describing the needs or expectations for a system or software, presented in an organized format, at the software system level or subsystem level, as appropriate, and with sufficient information to understand the traceability of the information with respect to the other software documentation elements (e.g., risk management file, software design specification, system and software architecture design chart, software testing). SRS（Software Requirements Specification）文書は、システムまたはソフトウェアのニーズや期待事項を組織的な形式で記述し、ソフトウェアシステムレベルまたはサブシステムレベルに応じて、他のソフトウェア文書要素との情報のトレース性を理解するための十分な情報を提供する（例：リスクマネジメントファイル、ソフトウェア設計仕様、システムおよびソフトウェアアーキテクチャ設計図、ソフトウェアテスト結果など）。
System and Software Architecture Design システム及びソフトウェアアーキテクチャ設計	Detailed diagrams of the modules, layers, and interfaces that comprise the device, their relationships, the data inputs/outputs and flow of data, and how users or external products (including information technology (IT) infrastructure and peripherals) interact with the system and software. デバイスを構成するモジュール、レイヤー、およびインターフェースの詳細な図解、それらの関係性、データの入力/出力とデータのフロー、およびユーザーや外部製品（情報技術（IT）インフラストラクチャや周辺機器を含む）がシステムとソフトウェアとのやり取りをする方法についての図解。
Software Design Specification (SDS) ソフトウェア設計仕様(SDS)	FDA is not recommending the SDS as part of the premarket submission. Sponsor should document this information on the design via the DHF for the device. During premarket review, FDA may request additional information, if needed, to evaluate the safety and effectiveness of the device. FDAは、市販前申請の一環としてSDS（Software Development Standards）の提出を基本ドキュメントレベルでは推奨していない。製造業者は、医療機器の設計に関するこの情報をデバイス履歴ファイル（DHF）に文書化する必要がある。市販前審査中、FDAは、必要に応じて、医療機器の安全性と有効性を評価するために追加の情報を要求することがある。	SDS documentation, including sufficient information that would allow FDA to understand the technical design details of how the software functions, how the software design completely and correctly implements all the requirements of the SRS, and how the software design traces to the SRS in terms of intended use, functionality, safety, and effectiveness. SDS（Software Development Standards）文書には、FDAがソフトウェアの機能の技術的な設計詳細、ソフトウェア設計がSRSのすべての要件を完全かつ正しく実装している方法、およびソフトウェア設計が意図された使用目的、機能、安全性、有効性に関してSRSとのトレース性を理解するために十分な情報が含まれる。
Software Development, Configuration Management, and Maintenance Practices ソフトウェア開発、構成管理(コンフィグレーションマネジメント)及び保守	A summary of the life cycle development plan and a summary of configuration management and maintenance activities; ライフサイクル開発計画の概要と、構成管理および保守活動の概要の要約。 OR 又は A Declaration of Conformity36to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable. FDAが認識しているIEC 62304のバージョンに対する適合性宣言（Declaration of Conformity）：該当する場合には5.1.1-5.1.3、5.1.6-5.1.9の細分箇条、箇条6（ソフトウェア保守プロセス）、および箇条8（ソフトウェア構成管理プロセス）などが含まれる。	A summary of the life cycle development plan and a summary of configuration management and maintenance activities; ライフサイクル開発計画の概要と、構成管理および保守活動の概要の要約。 OR 又は A Declaration of Conformity36to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable. FDAが認識しているIEC 62304のバージョンに対する適合性宣言（Declaration of Conformity）：該当する場合には5.1.1-5.1.3、5.1.6-5.1.9の細分箇条、箇条6（ソフトウェア保守プロセス）、および箇条8（ソフトウェア構成管理プロセス）などが含まれる。
Software Testing as Part of Verification and Validation 検証(ベリフィケーション)および妥当性確認(バリデーション)の一部としてのソフトウェアテスト	A summary description of the testing activities at the unit, integration and system levels; ユニット、統合、およびシステムレベルでのテスト活動の概要説明 AND 及び System level test protocol including expected results, observed results, pass/fail determination, and system level test report. システムレベルのテスト手順書（テストプロトコル）を含み、期待される結果、観測された結果、合格/不合格の判定、およびシステムレベルのテストレポートを含む。	Basic Documentation Level, PLUS 基本ドキュメントレベルに加えて unit and integration level test protocols including expected results, observed results, pass/fail determination, and unit and integration level test reports. ユニットおよび統合レベルのテスト手順書（テストプロトコル）を含み、期待される結果、観測された結果、合格/不合格の判定、およびユニットおよび統合レベルのテストレポートを含む。
Software Version History ソフトウェアバージョン履歴	A history of tested software versions including the date, version number, and a brief description of all changes relative to the previously tested software version. 以前にテストされたソフトウェアバージョンの履歴を含み、日付、バージョン番号、以前にテストされたソフトウェアバージョンとの関連でのすべての変更の簡単な説明が含まれる。
Unresolved Software Anomalies 未解決のソフトウェア異常	List of remaining unresolved software anomalies with an evaluation of the impact of each unresolved software anomaly on the device’s safety and effectiveness. 未解決のソフトウェアの異常のリストと、各未解決のソフトウェアの異常がデバイスの安全性と有効性に与える影響の評価。

特に注目して欲しいのは、System and Software Architecture Design（システム及びソフトウェアアーキテクチャ設計）の部分で、「デバイスを構成するモジュール、レイヤー、およびインターフェースの詳細な図解、それらの関係性、データの入力/出力とデータのフロー、およびユーザーや外部製品（情報技術（IT）インフラストラクチャや周辺機器を含む）がシステムとソフトウェアとのやり取りをする方法についての図解。」の提出を求められることになった。

今回のガイダンスには Appendix B にこのシステム及びソフトウェアアーキテクチャ設計図の例が3つ示されている。

1. ハンドヘルド診断デバイス

2. 患者と医療提供者向けのアプリケーションを備えた埋め込み式治療デバイス

3. 取得された医療画像を解析するためのクラウドベースのデバイスアルゴリズムのシステムおよびソフトウェアアーキテクチャ

これらのダイアグラムはハードウェア、ソフトウェアを含むシステム全体の静的なアーキテクチャ図で、この図は一般的なURLの表記ではなく FDAの独自の表記法である。

凡例を付けていれば、この様式とまったく同じでなくてもよいようだが、このFDAが示す表記法で医療機器申請をすれば審査が早く進むのだろう。

特徴的なのは、ハードウェアモジュール、ソフトウェアモジュール、OTS（市販されている既製のソフトウェア製品）を区別しており、それらの関係性をインタフェースの矢印線で示しているところだ。

2の「患者と医療提供者向けのアプリケーションを備えた埋め込み式治療デバイス」のアーキテクチャ図を見ると分かるのは、埋め込み式の治療デバイスが物理的な医療機器なのだが、実際には、リーダー/プログラマと通信したり、リーダー/プログラムを通して、クラウドにデータを送ったり、モバイル端末でデータを見たりするような使い方をする（＝意図する使用としている）ことである。

ようするに、現代の医療機器は、医療機器単体で使用することは少なくなってきていて、ネットワークに接続して、クラウドで機械学習したり、モバイル端末で医療機器の情報を閲覧したりすることが当たり前になってきているということだ。そのため、患者リスクは医療機器の中だけに留まらず、医療機器から外に出た情報がどのように使われるのかも含めて、リスクマネジメントしないといけなくなってきている。

だからこそ、FDAのガイダンスのタイトルが「医療機器に含まれるソフトウェアのための市販前ガイダンスの内容」から「デバイスソフトウェア機能の市販前申請の内容」に変わったのだ。

規制当局としてチェックしなければいけないのは医療機器に含まれるソフトウェアだけではなくなったので、医療機器のソフトウェア機能として、ネットワークを含めた接続機器や機能全体を審査しないといけなくなったのである。

それにともない、医療機器が出力する情報は仕様を公開するので自由に使ってくださいという考え方はNGとなっている。相互運用性（Interoperability）を医療機器製造業者が定義した上で、その安全性や有効性の妥当性を確認する必要があるということになる。

そうなると、医療機器からどんな情報が出たり入ったりしていて、どんな機器やシステムと接続しているのか、それらの機器・システムには市販のソフトウェアが使われてるのかどうかを見る必要が出てくる。だからこそ、システム及びソフトウェアアーキテクチャ設計図が必要となった。

また、システム全体の機能として安全性や有効性を確認するためには、それぞれの機能モジュールの要求仕様を確認した上で、それらの要求仕様が検証され、バリデーションされているかのトレースを取る必要がある。

そのため、システム及びソフトウェアアーキテクチャ設計図の各モジュールには、要求仕様の番号が記載されている。（例 SWReq X.Y) また、ところどころで機能モジュールの Intended Use（意図する使用）がノートで説明されている。例えば、1のハンドヘルド診断デバイスでは、解析エンジンのノートに下記のノートが付けられている。

Analysis engine consists of software algorithms for analyzing signals acquired from patient （解析エンジンは患者から取得した信号を解析するためのソフトウェアアルゴリズムで構成されています）

システム及びソフトウェアアーキテクチャ設計図が、SRS（ソフトウェア要求仕様）でも提示を求められているのは、各モジュールの要求仕様を確認したり、トレースを取ったりしたいからである。

医療機器ソフトウェアの安全性や有効性を確認するために、規制当局がシステムアーキテクチャまで踏み込んで審査する時代になった。

システムエンジニアやソフトウェアエンジニアは、ソフトウェアを作る以前に、さまざまなモデリングができなければいけなくなってきている。今回は、システム及びソフトウェアアーキテクチャ設計図だが、サイバーセキュリティでは脅威モデリングとしてデータフローダイアグラムを信頼境界も含めて描くことが求められてる。

現代のソフトウェアエンジニアは当たり前にモデリングができることが求められるようになった。

今回の FDA が要求するシステム及びソフトウェアアーキテクチャ設計図は、UML モデリングツール EnterpriseArchitect で描くことができる。

↓アドインの説明

System and Software Architecture Diagramの作成

EA 16.1 にこのアドインを取り込んで描いた図を示す。

すり合わせ的に作ってきたソフトウェアシステムは、こんなに綺麗に機能=モジュールになっていないかもしれないが、AIなど多様な機能を取り入れたシステムを実現するには、機能分割されたモジュールを組み合わせた設計にしていく必要がある。

すり合わせ一本でここまでソフトウェアを開発してきた技術者には、モデリングできるように今回のようなシステムアーキテクチャを描く練習するとともに、是非「リアルタイムOSから出発して組込みソフトエンジニアを極める」を読んで、どうやって時間分割のハードルを越えて、さらに機能分割のハードルを越えるのかを学んで欲しい。

医療機器のサイバーセキュリティ規制強化へ

2023-04-10T10:53:00.001+09:00

2023年3月31日付けで、厚労省から医療機器のサイバーセキュリティ規制強化に関するいくつかの通知が発出された。

どんな通知なのかを説明したいと思う。

「医療機器の基本要件基準第12条第３項の適用について」の医療機器の基本要件基準とは何か

PMDAに詳しい説明資料があるのでこれを参照して欲しい。

簡単にいうと、薬機法（法律）で医療機器は認証基準への適合が必要となっていて、基本要件基準第41条にて、厚生労働大臣は必要な基準を設けることができるとある。医療機器の基本要件基準は厚労省からの告示によって示されている。

医療機器の基本要件基準の第12条は、「プログラムを用いた医療機器の対する配慮」で、今回第12条の 3項にサイバーセキュリティ要求が追加された。

実は第12条2項は 2017年5月に追加されたJIS T 2304(医療機器ソフトウェア―ソフトウェアライフサイクルプロセス)への適合を求めた追加だった。

第12条3項は、2023年3月9日に追加の告示が発出されている。今回出た通知は、第12条3項の施行に関する通知となる。

医療機器の基本要件基準第12条第３項

３．プログラムを用いた医療機器のうち、他の機器及びネットワーク等と接続して使用する医療機器又は外部から不正アクセス及び攻撃アクセス等が想定される医療機器については、当該医療機器における動作環境及びネットワークの使用環境等を踏まえて適切な要件を特定し、当該医療機器の機能の支障が生じる又は安全性の懸念が生じるサイバーセキュリティに係る危険性を特定及び評価するとともに、当該危険性が低減する管理が行われていなければならない。また、当該医療機器は、当該医療機器のライフサイクルの全てにおいて、サイバーセキュリティを確保するための計画に基づいて設計及び製造されていなければならない。

これが追加された第12条3項の内容になる。この3項の説明が冒頭の3/31付けの通知1 に書かれている。その内容を紹介する。

趣旨

基本要件基準は、医療機器が具備すべき品質、有効性及び安全性に係る基本的な要件を規定したものであり、医療機器に対しリスクマネジメントの適用によってリスクを許容可能な範囲まで低減することが要求されている。
サイバーセキュリティ対策については、「医療機器におけるサイバーセキュリティの確保について」（平成27年４月28日付け薬食機参発0428第１号及び薬食安発0428第１号）、「医療機器のサイバーセキュリティの確保に関するガイダンスについて」（平成30年７月24日付け薬生機審発0724第１号及び薬生安発0724第１号）等において必要な対応を行うよう求めてきたところであるが、今般、令和２年３月に国際医療機器規制当局フォーラム（IMDRF）において、「医療機器サイバーセキュリティの原則及び実践に関するガイダンス」が取りまとめられたことに伴い、IMDRF N47文書（Essential Principles of Safety and Performance of Medical Devices and IVD Medical Devices）及びN60文書（Principles and Practices for Medical Device Cybersecurity）を踏まえ、プログラムを用いた医療機器に対しサイバーセキュリティを確保するための設計及び製造、ライフサイクル活動として、①製品の全ライフサイクルにわたって医療機器サイバーセキュリティを確保する計画を備えること、②サイバーリスクを低減する設計及び製造を行うこと、③適切な動作環境に必要となるハードウェア、ネットワーク及びITセキュリティ対策の最低限の要件を設定すること、の３つの観点を基本要件基準に盛り込むこととし、基本要件基準第12条に第３項を追加する改正を行ったものである。

要約すると、

IMDRF N47文書、N60文書をベースにしている。

製品の全ライフサイクルにわたって医療機器サイバーセキュリティを確保する計画を備えること
サイバーリスクを低減する設計及び製造を行うこと
適切な動作環境に必要となるハードウェア、ネットワーク及びITセキュリティ対策の最低限の要件を設定すること

の3つの観点を基本要件基準に盛り込んだということになる。

IMDRF は各国の規制当局の集まりで、ここで決まったことを各国の医療機器規制当局が自国の規制に適用することになっている。

IMDRFの成果として有名なのが、MDSAP（医療機器単一審査プログラム）で、各国とも ISO 13485 （ISO 9001 の医療機器版）を医療機器製造販売業者に求めているが、国によって微妙に異なる部分を各国統一部分＋差分という形にして、1回審査をパスすれば、それぞれの国で審査し直さなくてもよいというプログラムを作った。これによって、米国の非常に厳しい査察を定期的に受ける必要がなくなった。（全体としては米国の審査基準に近づいたので米国以外の審査としてはハードルが上がったと言える）

IMDRF はN60文書として医療機器の対するサイバーセキュリティのガイダンスを発行していて、冒頭の2の文書が、IMDRF N60文書の日本適用版という位置づけになっている。

冒頭１の施行通知の解説を続ける。

(1) 「プログラムを用いた医療機器のうち、他の機器及びネットワーク等と接続して使用する医療機器」とは、他の機器（医療機器、IoT機器、周辺機器、外部記録媒体（USB、SD、HDD、CD、DVD等）、電子カルテ、PC（外部からの持ち込みPC含む））、ネットワーク（院内システム、院外システム、グローバル）等に接続して電磁的情報のやり取りをする医療機器である。

ここは対象となる医療機器の説明をしてる。

・他の機器にネットワーク等に接続して電磁的情報をやり取りする医療機器が対象。

（２）「外部からの不正アクセス及び攻撃アクセス等」は、脆弱性を攻撃対象とする等の設計者が通常使用において想定していない手法等を用いた悪意を持った不正アクセスや、意図的に過剰な負荷を与えたる攻撃（DoS攻撃(Denial Service Atttack)、DDoS攻撃(Distributed Denial of Service Attack)等）、マルウェア（悪意のあるソフトウェア）の感染を意図する攻撃によるアクセス等を想定している。昨今のサイバー攻撃についてはその攻撃形式が多様化・高度化しており、今後はこれらの攻撃手法の他にも対応することも必要となり得る。

ここは、外部からの不正アクセス及び攻撃アクセスの説明。

（３）「動作環境及びネットワークの使用環境等を踏まえて適切な要件を特定し」とは、医療機関、在宅、救急、植込み型機器等の動作環境並びに接続するネットワーク種別やオペレーティングシステム及び各種ライブラリ等のプラットフォームといった使用環境を特定し、その使用環境に適した運用体制等を含めた医療機器の意図する使用に適切な要件を設定することである。

使用環境の特定について説明と、医療機器の意図する使用と使用環境の要件を設定すること。

（４）「当該医療機器の機能に支障が生じる又は安全性の懸念が生じるサイバーセキュリティに係る危険性を特定及び評価するとともに、当該危険性が低減する管理」とは、他のリスクと同様に、サイバーセキュリティに係るリスクに対しても、適切にリスクマネジメントを行い、例えば、JIS T 81001-5-1に示されている通り、サイバーセキュリティの脆弱性を特定し、その悪用によって生じる脅威や悪影響に伴うリスクを評価し、適切にリスクをコントロールすることである。

サイバーセキュリティのリスクを評価する。悪用によって生じる脅威や悪影響に伴うリスクを評価し、リスクをコントロールする。

（５）「ライフサイクルの全てにおいて、サイバーセキュリティを確保するための計画に基づいて設計及び製造」とは、全ライフサイクルにわたってサイバーセキュリティを確保するため、設計・製造工程における取組だけでなく、医療機関との連携、脆弱性対策（市販後のアップデート等を含む）に係る計画等も踏まえ、それが達成できるように、また、問題点や脆弱性が見つかった場合に対応できるように設計・製造を行うことである。

設計・製造工程における取り組みだけでなく、脆弱性対策、医療機関への報告、連携を計画し、達成する。

JIS T 81001-5-1 とは IEC 81001-5-1 の JIS版で、「ヘルスソフトウェア及びヘルスITシステムの安全，有効性及びセキュリティ－第５－１部」というタイトルの規格だ。

IEC 81001-5-1は、IEC 62443-4-1 の要求事項を IEC 62304 のプロセスに当てはめた形の規格であり、すでに産業用の制御システムのセキュリティ規格として存在していた IEC 62443-4-1 を医療機器のライフサイクルプロセスに置き換えた規格だ。

実は、この規格をJIS化するにあたっては、通常は2～3年かかる作業を約1年という短い期間で実現している。これは、厚労省が医療機器の基本要件基準のサイバーセキュリティ要求の適合と示すために、この規格を使おうと考えていたからだ。

冒頭１の通知では、「例えば、JIS T 81001-5-1に示されている・・・」というように、JIS T 81001-5-1 以外の規格を使ってもいいよというニュアンスで説明しているが、実際のところは「JIS化したんだから、JIS T 81001-5-1 に適合しろよ」といった本音がにじみでている。

IEC 81001-5-1 のような国際規格を日本が世界に先駆けて医療機器規制に使うというのは非常に珍しいことで、これまではEUが規制に取り入れてから、日本も追随するというパターンだった。

サイバーセキュリティに関しては日本の特に医療分野、医療機器分野では対応が遅れているとされていたため、今回は厚労省が世界に先駆けて、医療機器への規制を強化したといえる。

冒頭の通知３は、医療機関向けのサイバーセキュリティに関するガイダンスになる。

サイバーセキュリティは、医療機器製造業者だけでも医療機関だけでも達成することはできない、両者と規制当局は医療情報システムの提供者などが協力してはじめて達成できる。

よって、各者の情報開示や、レガシーシステムに対する補完的対策などが重要になってくるため、医療機器製造者向けのガイダンスと医療機関向けのガイダンスの両方が発出されている。

また、現行のシステムが医療機関においてどのようなネットワークにつながっているのか、また、どのようなセキュリティ対策（＝信頼境界があるのか）、どのような脅威が想定されるのかを分析すること（＝脅威分析）が必要であり、医療機器製造販売業者は、今度、脅威分析図、システム構成図を医療機関に示すことが必須になってくる。

このとき使うのが脅威モデリング（データフローダイアグラムを使うのが一般的）だ。

今後、このブログの中で脅威モデリングの説明をしていきたいと考えている。

プログラム医療機器を開発しようとしてる方は、まず3月31日付けで発出された3つの通知をよく読んで内容を理解することをお勧めする。

久しぶりの投稿

2023-01-01T15:58:00.002+09:00

1年3ヶ月ぶりの投稿。ふと、Facebook で友人が近況を書き込んでいるのをみて、「あ、そういえばブログ更新してなかった」て気が付いた。

このブログを始めたきっかけは、自分の本を出版して読者との交流しながら情報発信したいと思っていたからだった。あと、組織内で思ったこと、感じたことをブログに書くことである意味ストレス解消していたのかもしれない。また、書くことで自分の考えを整理して伝えるスキルを高めたいという思いもあった。

20年以上、組込みソフトウェアの開発をしてきたが、技術者への支援の仕事を経て、今は、組込み機器からの情報をクラウドに上げて、ユーザにサービスを提供するソフトウェアの開発をマネジメントしている。在宅勤務が増えて仕事の取り組み方も変わって、仕事をしているときとしないときの、ON/OFFがはっきりするようになって、OFFのときは仕事の事を考えなくなった。

若い時は会社にいても家に帰ってきても抱えてる課題をどう解決しようかと考えていたが、今はスキルが高まってきたせいか、ONのときに課題解決の道筋が見えるようになってきたので、OFFのときは仕事のことはあまり考えないようになった。こういった状況の変化で、ブログの更新が滞っていたのかもしれない。

環境が変化したとはいえ、今になってもいろいろを思うところはある。ソフトウェアは複数のエンジニアが関わって作っていくものだし、事業も関係する人々とコミュニケーション取りながら進めて行くので、その中で何かしら感情がぶつかったりすることはある。そういうことがあると、ブログに自分の考えを書きたくなってくる。

最近思うのは、組織ってやっぱり蛸壺的になるもんだということだ。組織が大きくなるほど、エンドユーザとの接点がなくなり、自分のやっていることがユーザのためというよりは、組織のため、さらに自部門のため、さらに自分の利益のためになる。最近、他部門の技術者が「その機能、入れるのか入れないのかだけ、言ってください」という発言をしたので、「そうじゃないだろう、ユーザにとって必要かどうかを考えるんだろう」とたしなめたことがあった。上から言われたことだけやる仕事って面白くないようなって思う。自分が作ったものをユーザが喜んでくれることを糧に仕事ができれば、技術を吸収するスピードだって速くなる。

自分がそういう考えで35年以上働いてきて感じるのは、組織の中にいても自分は個人商店だという認識を持っていたのはよかったなということだ。

入社したてのころはスキルがなくて、とても独立してやっていくことはできなかったので、早く一人前になりたいと貪欲に技術を吸収しようと思っていた。ある程度、外の世界の人達と渡り合えるようになってからは、いつでも独立するぞという気持ちでいたつもりだ。

ただ、組織と自分のポリシーにオーバラップがある内は、多少イヤなことがあっても我慢しようと思った。実力さえ身につけることができれば、組織が方向性が自分の生き方と異なると思ったら、迷わずに外に出ようと考えることができた。個人商店として何とかやっていきそうという自信が付いてなければ、組織にかじり付くしかなかったけれど、いつでも個人商店としてやっていけるとなれば、組織に対してもそれ相当の発言ができる。

そして、組織の事業を支えるようなプロジェクトに関わるようになれば、顧客満足を高めることの実感を得ることができるようになる。

自分はエンドユーザにどのような価値が提供できるのかから始まり、それを実現するための技術は何か、その技術を習得するためにどうしたからいいかという順番で物事を考えるようにしている。

いろいろな技術者と話しをしていると、そういう思考ではなくて、このファンクションをどうやったら実現できるかから話しをはじめる人がいることに気が付く。

「組込みソフトエンジニアを極める」の著書では、技術的なこととともに、エンドユーザに提供する価値を実現する技術を身につけることの大切さを書いたつもりだ。

そういった思考をする訓練をしてきたことによって、さまざまな課題にぶつかったときに、組織内のセクショナリズムなど、エンドユーザ価値に関係がない、また逆行するような事柄は実にくだらないと考えることができるようになった。

35年以上ソフトウェアエンジニアとして働いてきて思うのは、やっぱりソフトウェアは人が作ってるので、人=技術者のことをよく理解しないと何事もうまくいかないということだ。

「組込みソフトエンジニアを極める」や「リコールを起こさないソフトウェアのつくり方」で、欧米と日本の技術者の考え方の違いについてしつこいくらい書いたのは、そこを理解しなければ開発はうまくいかないと直感していたし、実際、欧米で培われたプロセスアプローチはそのまま適用したのでは日本ではうまくいかないと実感したからだ。

ソフトウェアの面白さって、人と密接に関係しているところかもしれないと、今更ながら感じる。

2021年11月1日にヘルスソフトウェア向けリスクマネジメント・トレーニング講座（オンライン）を開催します

2021-09-10T07:12:00.000+09:00

GHS 一般社団法人ヘルスソフトウェア推進協議会は、2021年11月1日にヘルスソフトウェア向けリスクマネジメント・トレーニング講座（オンライン）を開催します。

本リスクマネジメント・トレーニング講座は、GHS 開発ガイドラインの Level-1 の要求を実践するために必要な知識、技術を習得するための講座です。一般社団法人ヘルスソフトウェア推進協議会(GHS)は、これまで、9回に渡りトレーニング講座を開催し、のべ200名以上の参加者がヘルスソフトウェアのリスクマネジメントに関するスキルを修了しています。

本講座は、分かり易い資料、少人数に分かれたグループワーク・グループディスカッション、経験豊富な講師やモデレータによる丁寧な指導が特長の参加者の満足度が高いセミナです。

リスクマネジメント・トレーニング講座（オンラインセミナ）プログラム

10:00～10:05 開講挨拶（トレーニング講座開講の挨拶とスケジュール確認，連絡）

10:05～10:15 テスト　受講者事前知識調査

10:15～11:00 講義1 安全（セーフティ）の考え方

11:00～11:10 アイスブレイク（Zoomのブレイクアウトルームを使ってみる）

11:10～12:00 演習1 Intended Use（意図する使用）の定義と安全面とセキュリティの特質を明確化

12:00～12:45 昼食休憩

12:45～16:25 ※途中休憩あり

演習2　演習1 Intended Use（意図する使用）の発表

演習3　仮想ヘルスソフトウェアアプリのリスク分析演習

演習4　リスク分析結果発表（各グループ）とディスカッション

解説　　分析例の解説

16:25～16:40 GHS リスクマネジメント様式集（3種）と記入例とヘルスソフトウェアのサイバーセキュリティ要求について

16:40～16:50 質疑応答

16:50～17:00 アンケート記入・提出

詳しくは、こちらをご覧下さい。

演習では仮想のヘルスソフトウェア（健康アプリ）を題材にして、危害にいたる可能性のある一連の事象、危険状態、具体的な危害をリストアップし、それらが発生する確率（可能性）と重大度を分析して対策を考えます。

個人ワークの結果を持ち寄り、他社の参加者とグループディスカッションを行うことにより、自分では気が付かなかった視点があることに気付き、演習を経験することで、持ち帰って自社製品でもリスク分析できるようになることを目指します。

※コンサルティング関係の方の参加はお断りしています。

IEC 62304 準拠と謳っている RTOS が医療機器規制当局から注意喚起を受ける

2021-08-31T09:07:00.004+09:00

富士ソフトが扱う blackberry QNX リアルタイムOS に脆弱性が見つかり、米国FDA, 日本の厚労省が医療機関や医療機器製造業者に対して注意喚起を行っている。

厚労省通知　2021年8月23日『医療機器のオペレーティングシステムに係る脆弱性への対応について(注意喚起)』

本件については下記の記事の解説が分かり易い。

【ZD Net Japan 『米政府機関、ブラックベリー製品の脆弱性で注意喚起』より引用】

米サイバーセキュリティ・インフラセキュリティ庁（CISA）は、BlackBerryの製品に存在する「BadAlloc」の脆弱性に関するセキュリティアラートを発表した。BadAllocは、2021年の初めにMicrosoftの研究者が発表した脆弱性だ。
　また米国時間8月17日、BlackBerryは同社の「QNX Real Time Operating System（RTOS）」がBadAllocの脆弱性の影響を受ける可能性がある問題についてのアドバイザリーを発表した。QNX RTOSは医療機器や自動車、工場などで使用されており、国際宇宙ステーションでも使われている。同社は最近、QNX RTOSがおよそ2億台の自動車で使われていると明らかにしたばかりだ。
　CISAは、QNX RTOSは一部のIoT機器やOT/ICSシステムで使用されており、これらのシステムを保護するための対策が急務だと付け加えた。BlackBerryは影響を受ける製品の完全なリストを公開している。
　CISAのアラートでは、「リモートの攻撃者にCVE-2021-22156を悪用されると、対象デバイスがサービス妨害状態に陥ったり、任意のコードが実行されたりする可能性がある。BlackBerryのQNX RTOSは幅広い製品で使用されており、この製品が侵害されると、悪意を持った攻撃者に極めて重要度が高いシステムの制御を奪われる可能性があり、国家的に重要な機能のリスクが高まる」と述べている。
　「CISAは、現時点ではこの脆弱性が積極的に悪用されている事例を把握していない。CISAは、重要インフラ企業や、影響を受けるQNXベースのシステムを開発、保守、サポート、使用しているその他の組織に対して、影響を受ける製品にできる限り早くパッチを適用することを強く推奨する」
　CISAによれば、一部のRTOSのソフトウェアをアップデートするには、機器を取り外すか、敷地外の施設に持ち込んで、メモリーを物理的に交換する必要があるという。
　BlackBerryのアドバイザリーには、同社がこの脆弱性を修正するためにリリースした多数のアップデートの情報が掲載されている。Microsoftは4月に、BadAllocは25件のCVEにまたがる問題であり、消費者向け製品から医療用IoTや産業用IoTまでさまざま分野に影響を与える可能性があると述べている。
　米国の政治専門ニュースメディアであるPoliticoは8月17日、4月にBadAllocの脆弱性に関する情報が開示されて以降、BlackBerryと米国の政府関係者との間で交わされてきた舞台裏での議論について報じた。
　記事では、BlackBerryは同社の製品がBadAllocの影響を受けることを否定し、米政府がこの問題に関してアラートを公表することに抵抗したとされている。
　また、CISAの担当者が、QNXシステムに関するセキュリティアラートについて、影響を受ける業界や国防総省などと事前に連携を取っていたことや、外国の政府関係者にもこの脆弱性について説明する予定であることも報じられている。
　BlackBerryは6月に、QNXはAptiv、BMW、Bosch、Ford、GM、本田技研工業、Mercedes-Benz、トヨタ自動車、Volkswagenが製造する多数の自動車に採用されていると発表している。

【引用終わり】

サイバーセキュリティに関する脆弱性は市販後に見つかることがあり、それ自体はあってもまったく不思議ではないので、この脆弱性が見つかったからといって QNXの品質が悪いとは思わない。

どの製品にもありうるので、ここは粛々とパッチを当てたり、QNXの外側の環境で緩和策を取ることが重要と考える。

今回の記事で取り上げたのは、blackberry QNX について、日本の販売元の富士ソフトが QNXは IEC 62304（医療機器ソフトウェア - ソフトウェアライフサイクルプロセス）のソフトウェア安全性クラスC に準拠証明書付きで出荷されると宣伝しており、これが IEC 62304 のリスクベースアプローチの考え方から逸脱していて、単に商品を売るために規格を利用しているに過ぎないことを示したかったからだ。

【QNX OS for Medical 概要・特長】より引用

医療機器の複雑さが日増しに増加する昨今、規制の監視が益々厳しくなって来ています。根源が知られており事前認証されたコンポーネントを選択することで、認証プロセスが相当楽になります。QNX OS for Medical（医療用QNX OS）は、独立サードパーティにより「医療機器ソフトウェア - ソフトウェアライフサイクルプロセス」の標準規格であるIEC 62304準拠であると評価されています。この製品はARMとx86プロセッサーでサポートされています。
医療用QNX® OSは、医療機器メーカー用のQNXソフトウェアシステムズソリューションの主要素です。これは、市場投入前の認証業務に必要な時間と手間を低減することで医療関係のお客様が厳しい規制要件を満たすお手伝いをするためにデザインされています。医療用QNX OSは、QNXの標準オペレーティングシステムにより100% API互換で、お客様が最大限にソフトウェアを再使用し、それぞれ異なる認証要件を持つ複数製品用の共通プラットフォームを構築できるようになります。この製品は独立サードパーティ評価によるIEC 62304クラスC準拠証明書付きで出荷されます。

【引用おわり】

このブログサイトでも幾度となく、IEC 62304 が自動車ドメイン等で幅をきかせている機能安全規格ではなく、医療機器のインシデントに対して、医療機器のソフトウェア開発プロセスをリスクベースアプローチでの再発防止を目的として策定されたものであることを説明してきた。

機能安全規格では、製品に使用している部品の開発プロセスが機能安全規格が定めるプロセスどおりに作られているかどうかを認証することを推奨しているが、IEC 62304 はあくまでも医療機器の開発プロセスをリスクベースアプローチで開発することを求めていて、部品単位での規格適合など求めていない。

※機能安全という名前が良くない。安全（Safety）は機能（Function)ではない。機能的安全というのもおかしい。安全機能は手段でしかなく、本質を示していない。機能安全という言葉自体が安全の本質を目指していないと感じる。

そもそも、製品全体の構成要素の信頼性を高めることで安全性を確保しようとする設計は個別最適の発想（フォールト・アボイダンス）であり、ソフトウェアの規模が増大し、複雑化した現代では、まったくもって古い考え方である。1960年代の主流だった発想だ。

今では、左図の緑枠にあるように、製品の安全は「フェールセーフ」「フォールトトレランス」「エラー・プルーフ」といった、個々の構成要素に故障がバグがあっても安全側に倒れるようにしたり、冗長性を持たせたり、操作者は必ずミスをするという前提で設計するといった全体最適の発想を行うことが求められている。これが IEC 62304 で求められているリスクベースアプローチ（患者危害に至る危険状態が起こる要因を分析して、重大な危害が起こらないような対策を行う手法）だ。

だから、RTOSのような汎用部品が何の機器に組み込まれて、どのような機能や性能を実現するために使われるかが分からない状態で、安全性を評価することはできない。

例えば、列車で事故が発生したら速やかに列車を止めることが求められるが、飛行機で事故が発生したら、近くの空港まで飛行機を飛ばし続けなければらならない。同じ移動手段でも前者は止める、後者は動き続けることが求められる。

使用目的（意図する使用 = Intended Use）が定まらないと、リスク分析ができないと教えている。なぜなら、同じ材質、同じ形状をしていても何に使うのかによって、危険状態に至る可能性や発生する危害は変わるからである。

この図にあるように、細い木の棒は、アイスキャンディの棒かもしれないが、医師が口の中を診る際の舌圧子かもしれない。

後者の場合は、医療機器となり滅菌や一つ一つの包装が求められる。

同じ材質、同じ形状でも、意図する使用（Intended Use）によっては、リスクが変わるのだ。

よって、汎用製品であるリアルタイムOS について、規格の認証が取れているから安全性が高いと主張しているのは、間違っているし、意味がない。

下記の誤った記事を見て欲しい。IEC 62304 を機能安全規格と同じように扱っている。さらに、IEC 62304 のソフトウェア安全クラスは、機器の意図する使用によってリスク分析を行いその評価によってクラスが変わるはずなのに、なにに使われるのか分からない段階で、ソフトウェア安全クラスC であると言っている。一番高いクラスにしておけばいいでしょという考えならば、それはリスクベースアプローチの本質をまったく理解していないことになる。ようするに、IEC 62304 の規格趣旨が理解できていない証拠である。

【MONOist 組込み開発ニュース『工業、自動車、医療機器の機能安全認証を取得した最新版RTOSを提供開始』】より引用

BlackBerryは2020年11月9日、機能安全認証を取得したリアルタイムOSの最新版「QNX OS for Safety 2.2」の提供を開始した。自動車や組み込みソフトウェア開発などにおいて、認証取得作業を軽減し、迅速なシステム開発を可能とする。
最新版のQNX OS for Safety 2.2は、「QNX Neutrino RTOS」をベースとする。第三者認証機関のテュフラインランドから、「IEC 61508 SIL3」（工業）、「ISO 26262 ASIL D」（自動車）、「IEC 62304 Class C」（医療機器）の機能安全認証を取得している。
　さらに、「ISO 26262」「IEC 61508 TCL3/T3」の要件に準拠したC/C++ツールチェーンも採用している。これにより、QNXの機能安全性製品に安全認証取得済みのC++ランタイムライブラリが含まれることとなった。
　同社は、最新版のQNX OSを利用することで、開発期間を短縮しながら安全性や信頼性の高いシステムを開発し、開発費用の削減が可能になるとしている。

【引用おわり】

一方で、富士ソフトは、IEC 62304 を医療機器のソフトウェア開発に適用する際に、支援を行うサービスも行っており、そのサービスを紹介したページでは、IEC 62304 の趣旨を正しく理解しているように見える。【対象ページ】

なぜ、このような矛盾が生じるのか。理由は簡単だ。QNX が IEC 62304 に準拠したと宣伝に使っている部門と、IEC 62304 をコンサルテーションしますといっている部門が異なっており、前者は IEC 62304 の中身を読んでおらず（または読んでいても理解しておらず）規格適合したと表明すれば、他のRTOSと差別化ができ、規格の趣旨をよく理解できていないユーザから購入してもらえると考えているからだ。

そして、規格の内容や趣旨を熟知している第三者認証機関が機能安全ではない IEC 62304 を汎用ソフトウェア製品に対して適合証明してしまうのか、これも商売になるからだ。（規格適合を証明するには相当な費用がかかる）

規格を熟知した認証機関が誤った使い方をしていることを知っていながら、規格適合証明を出しているのだから、こっちの方が罪が重いと思う。

このブログで必要に問題のあるソフトウェア製品について批判する記事を書くのは、これらの認証がエンドユーザの安全を目指して実施されているのではなく、単に商品を売りたいために認証を取っていると思うからだ。

ここで冒頭の blackberry QNX リアルタイムOS に脆弱性が見つかり、米国FDA, 日本の厚労省が医療機関や医療機器製造業者に対して注意喚起を行っているという件に話しを戻す。

blackberry QNX リアルタイムOS は　第三者認証機関のテュフラインランドから、「IEC
61508 SIL3」（工業）、「ISO 26262 ASIL D」（自動車）、「IEC 62304 Class C」（医療機器）の機能安全認証を取得している（IEC 62304は機能安全規格ではないので、この記述は誤り）と、富士ソフトはWEBサイトで、規格の認証を取得していて、他の製品より安全ですよと主張している。

揚げ足を取るつもりはないが、今回の脆弱性の発見で脆弱性を突かれるとリアルタイムOSを使っている製品が悪用され、患者危害に至る可能性があるためパッチを当てる必要があることが分かった。

QNX は「信頼性が高いとされていた」ため、医療機器にも多く使用されていたので、米国や日本の規制当局が冒頭の注意喚起を出したわけだ。

QNXは自動車にも多く使われているようなので、自動車業界でも対応が求められているだろう。

ただ、QNXが対象システムのどこに、何に使われているのかによって、リスクの大きさは異なる。だから、製品ごとにリスク分析を行うことが重要なのであって、部品の製品開発のプロセスが規格に適合していることを主張するのはおかしいし、医療機器の場合、規格趣旨から特に間違っている。

この図を再掲するが、個別最適で安全設計をする時代ではないのだ。全体最適の発想で、意図する使用を明確にして、その上でリスクを分析し、危害の重大度を考慮し、重大な危害に至るケースを優先して、対策を立てていることが、患者や利用者の被害を効率てきに低減することにつながる。

このリスクベースアプローチの考え方を理解せずに、規格適合を主張し、商品を売ろうとする者は、場合によっては、エンドユーザのリスクを高めてしまっている可能性さえある。

汎用ソフトウェア部品を利用する開発者は、ソフトウェア部品の開発プロセスの認証を気にするのではなく、そのソフトウェアがどのような検証を行ったのか、テストの網羅性やテストケースの設計はどうだったのかを精査するべきだ。

規格ビジネスの悪は、規格が求める内容を理解しないユーザにお墨付きをちらつかせて商品を売ろうとする側面を増長させる点にある。

単純な商品販売における競争のための手段ならまあ、無駄ではないし、それもありかと思うが、そこにユーザの健康や安全がかかっているとすれば、それは間違いだと言わなければかえって危ないと思っている。

セキュリティ上の脆弱性は市販後に見つかったら、粛々を対応することでよい。

だた、これを期に、汎用ソフトウェア製品の規格適合証明が製品の安全性で担保するのは間違いであるということを再認識して欲しい。

医療機器プログラムの該当性のガイドラインが改訂され、非医療機器の範囲が広がった？（間違い）

2021-07-07T09:05:00.006+09:00

医療機器プログラムの該当性のガイドラインは 2021年3月31日に発行されたもので2014年に発行されたものから置き換わりました。（厚労省のページ）

GHS（ヘルスソフトウェア推進協議会）にて、第３回ヘルスソフトウェアのリスク分析入門セミナー（オンライン）を 2021年8月23日に実施します。

このオンラインセミナーの「ヘルスソフトウェアー規制と規制対象外の境界の考え方」にて、今回改訂されたプログラム医療機器該当性のガイドラインについても解説します。

ヘルスソフトウェアのリスク分析入門オンラインセミナープログラム

13:00～13:10 開講挨拶（スケジュール確認，連絡）
13:10～13:30 GHS と GHS 開発ガイドラインの紹介
13:30～14:00 ヘルスソフトウェア－規制と規制対象外の境界の考え方
14:00～14:15 休憩
14:15～15:00 ヘルスソフトウェアの周辺に存在するリスク（健康リスク）
15:00～16:00 リスク分析の考え方とリスク分析演習（仮想ヘルスソフトウェアを想定して）
16:00～16:15 質疑応答
16:15～16:30 アンケート記入・提出

厚労省のページ（医療機器プログラムについて）では、対象のソフトウェアが医療機器に該当するかしないかを判定した事例も随時 Excel 表にて提示されています。

また、厚労省は医療機器プログラムの早期実現推進を目的として、医療機器プログラムに関する相談を「医療機器プログラム総合相談」として一元的に受け付ける窓口をPMDAに設置しました。

SaMD一元的相談窓口（医療機器プログラム総合相談）

一方で、これまで医療機器の該当性の相談を都道府県の担当窓口にて受けてきましたが、今後、プログラムの医療機器該当性の相談については、厚生労働省医薬・生活衛生局監視指導・麻薬対策課にて一元的に行うこととなったようです。

なお、医療機器に該当しないプログラムの広告相談につきましては、引き続き、都道府県にご相談とのことです。

医療機器プログラムの該当性のガイドラインが改定されたことで、非医療機器の範囲が拡大されたとミスリードして、下記のようなことを書いているサイトがありますが、これは間違いです。（厚労省確認ずみ）

厚労省が今年3月31日より施行したプログラム医療機器のガイドラインによると、このような健康管理のためのプログラムは非医療機器としてリリースが可能とのこと。

つまり非医療機器部分が拡大されたわけで、このガイドラインを活用すれば、非医療機器＝薬事法の外でいろいろな仕掛を行うことが可能となります。

米国もそうですが、医療機器と非医療機器の境界にあるヘルスソフトウェア、ヘルスアプリはどんどんリリースされてきており、各国の規制当局もそのソフトウェアが医療費の削減に貢献されるのであれば歓迎したいというスタンスで、厚労省も効果・効能があって、医療機器にするなら支援しますよといっています。

一方で、医療機器と非医療機器の違いや、健康被害に至るようなリスクがあるのかないのかといったリスクマネジメントについて、よく分からないままソフトウェアをリリースし、商品を売りたいがために、効果・効能的なことを謳ってしまって、広告規制に引っかかるといったケースも増えてくると思います。

GHSのリスク分析入門セミナーでは、規制と規制対象外の違いや、どんなリスクが想定されるのか、また、リスク分析とはどのようにやるのかについて解説します。

セミナーの詳細については、GHSのこちらのページからご確認ください。

人工呼吸器は不足したからといって簡単に作れるもんじゃない

2021-03-23T14:42:00.003+09:00

『他業種の医療機器製造業参入について（人工呼吸器そんなに簡単に作れるの？）』の記事をおよそ1年前に書いた。

時は流れて最近、人工呼吸器の使い方を病院の臨床工学士の皆さんに説明する場に立ち会う機会があった。

自分は人工呼吸器はあまり詳しくないので、初めて聞く内容ばかりだったが、かなり専門性のある内容であることは分かった。

例えば、マスクが外れたことを検知したときにアラームを鳴らして、いったん酸素の供給を止めるが、マスクを付け直したことを検知したら自動的に再稼働するとか、使用前点検の記録を各病院のルーティーンに合わせてカスタマイズできるとか。

そういった専門的で臨床使用する場合の仕様が人工呼吸には必要なんだということが分かったので、『他業種の医療機器製造業参入について（人工呼吸器そんなに簡単に作れるの？）』の記事を書いた頃の、「人工呼吸器不足しているので作ってみました」的な記事はいったい何だったのかと思った次第だ。

たぶん、臨床の現場では、それは役に立たない代物であり、実際には睡眠時無呼吸症候群の治療用のCPAPの代用品にできるかどうかくらいだったのだろうと思う。

医療機器ってそんなに簡単に参入できるもんじゃないよなということを再認識したとともの、医療機器を作るなら医療の現場をじっくり見て臨床的に何が行われているのかをちゃんと見ないとダメだと思った。

組込みソフト開発とクラウドソフト開発の違い

2020-07-07T08:57:00.000+09:00

30年近く組込みソフトウェア開発に携わってきたが、ここに来てクラウドソフトウェアサービスの開発に関わっている。

そこでだいぶ様子が違うことが分かってきた。今回はその違いについて書いてみたい。

IoT機器（組込みソフトウェア機器）を無線/有線ネットワークでクラウドに接続し、クラウドアプリケーションソフトウェアでサービスを提供するというスタイルが増えつつある。

かつて、組込みソフトウェアは出荷時のソフトウェア品質を担保するためウォーターフォール的な開発プロセスが取られてきたが、ソフトウェアの規模が増大するにつれて、組込みソフトウェアでも一部または全体にアジャイル的なプロセスが適用されるようになった。

一方で、クラウドアプケーションソフトウェアの開発はどうだろう。クラウドアプリケーションソフトウェアの開発は DevOps だと言われる。

DevOps については、『DevOpsとは何か？そのツールと組織文化、アジャイルとの違い』の解説がわかりやすい。

DevOpsとは「開発チーム（Development）と運用チーム（Operations）がお互いに協調し合うことで（図1参照）、開発・運用するソフトウェア／システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」という概念である。

【引用おわり】

ようするに、開発しながら運用も行うという、組込みソフトウェアを長年やってきたエンジニアとしては、ちょっと衝撃的な開発スタイルだ。

これが実現可能となっているのは、クラウドサービス提供各社（Microsoft Azure や Amazon AWS等）のクラウドアプリケーションが、クラウド上での各種サービスアプリケーションの組み合わせで、目的を果たせるようになっているところにある。

最終的なUI部分の作り込みは必要だが、IoT機器との接続や、アーカイブ、二次処理、データからのトリガー、セキュリティ確保等々、すでにあるサービスの組み合わせでかなりことができる。

これらのサービスの組み合わせの開発もクラウド上で行うので、クラウドアプリの開発にはPCとインターネットがあれば、それだけでできてしまう。

ただ、クラウドアプリの開発には、各社がクラウドサービスで提供するサービス群を使いこなすためのノウハウ（多くはWEBに情報があるが、使いこなすには経験が必要）をもったエンジニアが必要であり、この主の知識・スキルはかつての組込みソフトエンジニアが持っている知識・スキルとは異なると感じている。

ちなみに、Microsoft は今後のもうけの種をIoT や PC に搭載する Windows OSの販売から、クラウドサービス(Azure）の使用料に大きく舵を切っている。今や、Microsoft Office も Microsoft 365 でクラウドサービスになりつつある。

Microsoft は IoTのOSは Windows にこだわっておらず、Linux でもよいと考えている。だから、最新のWindows 10には WSL（Windows Subsystem for Linux）を追加できるし、Linux から Azure への接続もまったく問題にしていない。

実際やってみてわかるのは、IoTからクラウドへの接続費用とクラウドサービスの使用料はそれなりにかかる。クラウドへの接続のセキュリティレベルを高くしようとすると、それだけ接続料は上がるし、クラウドサービスは使用するサービスの組み合わせでどんどん料金が上がっていく。

エンドユーザは、さまざまなクラウドサービスが無償で提供されている気分になっているが、実際にはかなりのコストがかかっていて、商品の代金やサブスクリプション費用にそのコストが上乗せされている。

商品の価格にクラウドサービスのコストを転嫁すると、商品を売り続けないとダメなので、各企業ともサブスクリプションでエンドユーザからお金をもらいたい。そのためには、Eコマースのサービスを導入する必要があり、その投資も馬鹿にならない。

また、一度、クラウドサービスをエンドユーザに提供し始めると、そう簡単にはやめられなくなる。クラウド業者をスイッチするこは理論的には可能だが、各種提供されるクラウドサービスのインタフェースがまったく同じではないので、実質的には難しい。

よって、クラウドサービス提供業者はクラウドサービスの利用企業を囲い込むことができる。クラウドサービスの提供にはかなりの費用がかかると思うが、それに見合った利益も確保できるので、おいしい商売だと感じる。

さて、DevOps の話にもどると、クラウドサービスでエンドユーザにどんな価値が提供できるのかは、実際やってみないとわからない部分が多い。

また、クラウドへアクセスする部分のUIは比較的簡単に変更可能であるため、ユーザの要望に応じて、運用しながら変更していくこともできる。

そこが、組込みソフトウェアの開発との大きな違いだと感じる。組込みソフトウェアの場合、ネット経由でシステムソフトウェアのアップデートがやりやすくなったとはいえ、リリース時のソフトウェア品質の担保は必須であり、変更にもかなり気を遣うし、検証や妥当性確認の工数も必要だ。

一方でクラウドアプリケーションの場合は、すでに完成されたサービスを組み合わせるため、個々のサービスの信頼性は確保されており、データの流れを変えていくようなイメージで変更ができる。

同じことを組込みソフトウェアで実現することも、ソフトウェアアーキテクチャ次第で可能ではあるが、最初のシステムアーキテクチャの構築が難しい。クラウドアプリケーションの場合は、すでにシステムアーキテクチャが用意されている状態で利用を始めるので、最初の苦労はない。

ちなみに、クラウドアプリケーションで提供される個々のサービスの完成度が高いからといって、試行錯誤的な開発をしていたのでは、エンドユーザの対する品質は担保できない。

アジャイルを単純な試行錯誤的な開発開発スタイルだと思っているエンジニアはさすがに少数になったと思うが、ひょっとして今でもそれなりの数いるのではないかと疑っている。

そういう方には、『アジャイル開発のプロジェクトマネジメントと品質マネジメント: 58のQ&Aで学ぶ』を読むことをお勧めする。

日立製作所でアジャイル開発の品質保証を実践してきた筆者らが、本当の意味での品質を担保したプロのアジャイル開発とは何かについてレクチャーしてくれている。

自分もまだ全部腹に落ちておらず勉強中だが、クラウドアプリケーション開発において実践しないといけないと思っている。

IoT（組込み）ソフトエンジニアとクラウドソフトエンジニア、この二種類のソフトウェアエンジニアが協力しないと、今どきのクラウドサービスが成り立たない。

この二種類のエンジニアは似て非なる者だと思うので、これらの開発をうまくコーディネイトできる人材が成功の鍵となるのではと思っている。

ソフトウェアとハードウェアのつなぎについても、両方の知識や経験をもった技術者（＝組込みソフトエンジニア）の存在が重要だったが、IoT とクラウドについても両方の知識・スキルを持ったエンジニアがシステムの全体を俯瞰しながら、適宜最適となるようにソフトウェア開発プロセスを選択的に適用していく必要があるし、二つの文化の違いを理解した上で、それらを上手にマネジメントする必要がある。

明らかに10年前、20年前とは、ソフトウェアの開発スタイルが変わりつつある。クラウドサービスに関しては、クラウドアプリを開発できるエンジニアをどれだけ増やせるかがクラウドサービス提供者の売り上げアップの鍵となるため、クラウドサービスの技術を学ぶための教育コンテンツが驚くほど豊富にWEB上に存在する。それもすべて無償だ。

かつて組込みソフトエンジニアのための教育教材がないということで、SESSAMEが作られたのだが、クラウドエンジニアの教材は豊富に提供されている。このソフトウェアエンジニアのトレーニングという部分での進化もすさまじい。

ただ、勉強することが山ほどあって、分業しないとやってられないという現実はある。だからこそコーディネータの役割は重要だと感じる。

DevOpsを成功させるには、エンドユーザの対する価値と時代による価値の変化を敏感に感じ取るセンスも必要だし、価値をビジネスに結びつけるための戦略を考え、その戦略を実現するための技術が何であるかがわかるようでないとうまくいかない。

組込むソフトウェアとクラウドソフトウェア、新しい時代のソフトウェアエンジニア像について、今後も考えていきたい。

IoT（組込み系）のソフトウェア技術の e-Learning コンテンツが新型コロナウイルス感染症緊急対策で助成金を利用できます（東京都）

2020-05-15T15:25:00.002+09:00

SESSAMEがリリースした組込みソフトの e-Learning コンテンツについて、東京都が用意した新型コロナウイルス感染症緊急対策で、費用の4/5（上限32万円）の助成申請ができます。

東京都に事業所がある資本金3億円以下、従業員300人以下の企業であれば、新型コロナウイルス感染症緊急対策の中小企業人材オンラインスキルアップ支援助成金を使い、e-Learning 費用の4/5(上限32万円）の助成を申請することができます。

SESSAMEの e-Learning WEBコンテンツは月額3000円で見放題なので、およそ100名のエンジニアに下記のコンテンツを一か月間約6万円の費用で受講させることができます。

現在リリースされているタイトル

o.	カテゴリ	講義タイトル	リリース時期	詳細
WB-01	初級	プログラミング/テストの基礎	2020年04月
WB-02	初級	構造化分析・設計の基礎	2020年04月
WM-01	中級	組込みシステム開発における知的財産権	2020年04月
WM-02		構成管理（理論編/実践編）	2020年04月
WM-03		リアルタイムシステム設計（理論編/実践編）プラットフォーム選定の観点（RTOS編）	2020年04月
WM-04		テスト・レビュー・インスペクション	2020年04月

申請期間は第6回の最後が 9月21日なので、申請する企業はお早めに。

------------- SESSAME の e-Learning コンテンツについて ----------

組込みソフトウェア管理者・技術者育成研究会（SESSAMEは) これまで CD-ROM で提供してきた SESSAME e-Learning Series のコンテンツを WEBコンテンツに移行しています。（すべてのコンテンツの移行が完了するまで、CD-ROMでの販売も継続します。）　

今回、初級コンテンツ2講座と中級コンテンツ 5講座を WEBコンテンツ化しました。これまで CD-ROM 1コンテンツ 5000円で、さらに、多人数で視聴する場合は上映権を設定していましたが、WEBコンテンツではひとりのユーザがすべてのリリースコンテンツを１ヶ月3000円+税で視聴できるようになります。

これにより、短期集中的に組込みソフトウェアを学習したい方、長期に渡り学習したい方の両方にニーズに対応できるようになります。

この機会に是非 SESSAME e-Learning Series (WEBコンテンツ版）をご利用ください。

SESSAME WEBサイト

SESSAME e-Learning Series (WEB版）

『ソフトウェア系国際規格の認証の現状について』の記事に対するコメントと回答

2020-04-21T13:45:00.000+09:00

2019-10-20に投稿した『ソフトウェア系国際規格の認証の現状について』の記事に対して2020-02-10にコメントをもらっていて、確認＆承認を忘れており、昨日気が付いて承認をしました。2ヶ月以上放置してしまい申し訳ありません。

改めて、コメントの内容をここで紹介し、回答も書きたいと思います。

ーーーーコメントーーーー

匿名さんのコメント...
いつも有益な記事をありがとうございます。
汎用ソフトウェアが医療ソフトウェア規格の認証を受けることは意味が無いということは、ソフトウェアを含む医療機器開発には、汎用OSはもちろん、コンパイラが提供するライブラリも使用できないということですね？
リアルいタイムOSはもちろん、Linuxのような巨大なOS相当も、意図する使用を考慮してフルスクラッチが必要であるということですね？もしくは、LinuxクラスのOSは使用してはいけないということですね？
C言語ならいざ知らず、C++やJava 等の言語のメカニズムに相当する部位も汎用ソフトウェアと言えますから、それも使えないということですね？

ーーーーコメントに対する回答ーーーー

さて、「汎用ソフトウェアが医療ソフトウェア規格の認証を受けることは意味が無いということは、ソフトウェアを含む医療機器開発には、汎用OSはもちろん、コンパイラが提供するライブラリも使用できないということですね？」のご質問に回答します。

汎用ソフトウェア(OTS: Off The Shelf Software）は OTS として検証・評価を行います。IEC 62304 はリスクベースアプローチを採っているため、何に使うのかが定まっていない状態で、リスクベースアプローチのプロセス規格を適用することは意味がないと言っているのであり、医療機器にOTSを使用できないとは一言も言っていません。

米 FDA は医療機器に使用するOTSに対するガイダンスを発行しており、このガイダンスでは「そのOTSを医療機器に使用したときの懸念レベルを定めて、ハザード分析すること」を医療機器の製造業者に求めています。また、OTSの検証・評価も必要です。これもリスクベースアプローチです。

これについても勘違いしているOTSベンダーが多いのですが、OTSベンダーができるのはOTSの検証(=Verification）の部分であり、OTSが医療機器に使われたときの懸念レベルの推定やハザード分析は、医療機器製造業者が行います。正確には、その OTSを何に使うのか知っている医療機器製造業者しか、懸念レベルの推定やハザード分析はできないということです。

もちろん、Windows や Linux を医療機器に使用することもできますが、それらOTSを医療機器に使用したときのリスクの分析（OTSに障害が起きたときの患者への危害の重大さや発生確率の分析と評価）がもとめらます。

記事の中でも説明したつもりですが、機能安全のアプローチである認証が取れたOTSを使用することを求めるという考え方と、意図する使用（=Intended Use）を明確にした上で、リスクベースアプローチでOTSを使用するという考え方は、元のコンセプトが異なるということです。

リスクベースアプローチの考え方であっても、OTSが使えないということはありません。OTSがどんな用途の医療機器に使用するのかを分析した上で、必要な検証、評価を求めています。

また、コンパイラは医療機器に組み込まれるソフトウェアではないものの、製品の品質に影響を与えるQMSソフトウェアであることから、そのリスクレベルに応じてバリデーションを求められます。(ISO 13495:2016 より）

さらに、近年の医療機器規制の中のサイバーセキュリティ要求により、汎用ソフトウェアの脆弱性の監視とパッチ対応は医療機器製造業者に対する義務となりつつあります。

いずれにせよ、汎用OSやコンパイラが医療機器に使えないということは一切ありません。

他業種の医療機器製造業参入について（人工呼吸器そんなに簡単に作れるの？）

2020-04-18T07:18:00.004+09:00

新型コロナウイルスの蔓延で人工呼吸器が足らなくなるかもしれないというニュースが駆け巡っている。

それを受けて、自動車やその他の産業から、急遽医療機器の製造を支援したり、医療機器そのものを作りますといった発表も散見される。『ホンダが新型コロナ軽症者の搬送車両を開発、陰圧状態の後部座席で飛沫感染防ぐ』の記事中で、トヨタ自動車の豊田章男社長は、次のように述べている。

人工呼吸器の生産に対しては「人命に直結するモノづくりは簡単ではない」（自工会会長の豊田章男氏）とし、直接生産は行わない姿勢だ。

それはその通りなのだが、なぜ「人命に直結するモノづくりは簡単ではない」について解説したいと思う。

医療機器は規制が厳しいので、実際にどのような規制要件があるのかを書いてみる。非常時なんだから、一次的に規制は緩和してもいいのではないかという意見もあると思うが、まずは、現状どんな規制があるのかを書く。

法規制

日本では薬機法（旧：薬事法。正式名称：医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律）がある。医療機器としての要件や、医療機器製造業や販売業に関する規定が含まれている。

電気を使用する医療機器では IEC 60601-1 医用電気機器―第１部：基礎安全及び基本性能に関する一般要求事項の規格に適合しなければならない。

この規格は各種個別規格や副通則もあるので、医療機器の種別によって適合しなければならない規格は複数存在する。

※医療機器には基本要件基準が定められており、IEC 60601-1 は基本要件基準への適合を示すための規格の一つ。

ソフトウェアの要件としては IEC 62304(JIS T 2304）もある。さらに、医療機器を製造するには ISO 13485（ISO 9001 の医療機器版）の認定も必要だ。

どれ一つとってもハードルは高く、そのハードルの高さが、異業種からの医療機器業界への新規参入を阻んでいる。

なぜ、そんなに規制が厳しいのか？

薬機法には公告規制もある。要するに虚偽・誇大広告は法律で禁じられている。

第六十六条　何人も、医薬品、医薬部外品、化粧品、医療機器又は再生医療等製品の名称、製造方法、効能、効果又は性能に関して、明示的であると暗示的であるとを問わず、虚偽又は誇大な記事を広告し、記述し、又は流布してはならない。

効果効能が明確でないのに、「癌が治る」とか「症状が軽減する」などと公告すると、一般市民が惑わされ害があるので規制されている。病気や健康は人々にとって強い関心事であるため、虚偽又は誇大な記事を規制しないとだまされる人が増えて社会が混乱する。

医療機器についても同じで、効能、効果、性能が臨床的に立証されていない機器は売れないし宣伝もできない。

規制がないと、製造業者が表明している機器の機能や性能が実際には十分でなかったり、リスクコントロールがないため事故が起こったりしてしまう。一般的な機器ならユーザがメーカにクレームを言えば済むかもしれないが、医療現場では取り返しがつかないような事態になるかもしれない。だから、医療機器は規制されている。

ベネフィット・リスク分析

多くの薬には副作用がある。副作用があるけれども、効果効能を優先させるために服用が必要な場合もある。例えば、抗がん治療には副作用があるが、延命するためには治療はしなければならない。

医療機器も同様で、リスクはあるがベネフィットが上回るため、ある条件下では使用すべきということが多々ある。

生命維持装置や治療器には大抵リスクがあるので、どんなリスクがあり、それらのリスクを低減してリスクが受容できている状態にしておく必要がある。

そのときに、リスクはあるがベネフィットが上回るので条件付きで使用させるというケースも出てくる。

左図の上部は顕在的な価値、例えばカタログスペックに出てくるような目に見える価値で、下の部分は、表にはでてこないけれど安心や安全を担保する価値になる。当たり前品質とも言える。

医療機器は、この潜在的価値の部分が脆弱だと、人の死に直結してしまう可能性がある。生命維持装置や治療器が期待通りに動かなければ、患者が死亡したり重傷を負ったりするかもしれない。

よって、この潜在的価値の部分を担保するために、さまざまな規制があると言えるし、規制当局は取り締まりをすることで、国民の安全を確保している。

緊急時にそんなこと言ってられない

世の中平温ならいざ知らず、今は、「もたもたしていたら、死者がどんどん増えてしまうではないか」という緊急事態かもしれない。

だから、米FDA（食品医薬品局）は、COVID-19 に関連して、規制を緩和するガイダンスを次々に出してる。例えば、これやこれ。こちらのサイトでCOVID-19をキーワードに検索すると27件ものガイダンスがヒットする。

米国は、FDAにかなりの権限があり、規制に対する裁量権が認められているので、ガイダンスによって規制を緩和することができるようだ。

モバイルアプリに関しても、左図にあるように米国では、医療機器かもしれないが、FDAが執行裁量権を使って取りあえず規制しないというカテゴリーがあるが、日本では、法体系が違うためそのような曖昧なことはできない。

1か0（医療機器か、そうでないか）を判定しないといけない。

よって、現実的には、日本では薬機法を改訂しないかぎり、従来の規制を一次的に緩和することは難しい。

特に、現実問題、医療機器の製造業・販売業の業の認定がない企業に、一次的ではあっても医療機器を製造したり、販売させることはできないだろう。

米国も同じだが、審査の工程を簡素化したり、短縮したりすることはできるようだ。

現実的には何が問題になるのか

法規制のことはいったん横においておいて、実際にこの緊急時に異業種の企業が人工呼吸器を作ることにどんな問題があるのだろうか。

コロナ最前線で戦う医療現場にTeslaが約束の｢人工呼吸器｣を送ったという記事があった。

ところが、この機器は、睡眠時無呼吸症候群の治療機機器であるCPAPの機器だったようだ。価格は800ドルで、侵襲型の人工呼吸器（約5万ドル）とは異なる。

機能としては、CPAPも人工呼吸器も酸素を送り込むので似ているが、意図する使用/意図する目的（Intended Use）が異なる。

臨床的に目的が異なるものを緊急で転用するならその違いを理解している人が機器を扱わないと事故が起こる危険があるし、人間は必ずミスをする（ヒューマンエラーはなくならない）ので、臨時の使い方を多くの人がするようになると気をつけないといけないことを怠って事故が起こる確率も徐々に上がっていくだろう。

それも含めて緊急事態だからベネフィット・リスクを考えて、臨時的な使い方を許容するという選択肢もあるかもしれない。

どちらを優先させるべきか悩ましいが、前提として臨床的に有効性のない機器を投入することは間違いだと言えるし、患者が死や重傷に至るようなリスクに対してリスクコントロールがされており、リスクが受容できているという確認（＝バリデーション）は必ず必要だ。

特に、医療機器の開発にあたっては、臨床的な知識や医療現場での機器の使われ方、治療や診断の実際について、開発者が十分に理解していることが重要だ。

今、集中治療学会は、新型コロナウイルス感染症（COVID-19）の対応に関連して、人工呼吸教育ビデオや、新型コロナウイルス肺炎患者に使用する人工呼吸器等の取り扱いについて（Ver.2.0）などの情報を公開している。

これを見るだけでも人工呼吸器は取り扱いに注意が必要で、十分なメインテナンスが必要な機器であることがわかる。

「人工呼吸器の部品を3Dプリンタで作りました」などのニュースを見ると、作った部品は滅菌できるのかとか、つなぎ目から空気の漏れは起こらないのか、薬液耐性は大丈夫かとかといった疑問が沸く。

人工呼吸器を本気で作ろうと考えている設計者は、まずは、臨床的な知識、治療の実際について理解してから、自分達が持っている技術がどの部分に活かせるのかを考える必要があると思う。

総合的な感想

現在の医療機器規制は過去の事故の再発防止策などが積み重なって今に至っている。ただし、改めてそれらができていないと安全ではないのか、逆にそれらができていれば安全なのかという疑問がないわけではない。

例えば、IEC 62304 はプロセス規格なので、この規格への適合と機器の安全は一体一ではない。機器としてのリスクを分析しており、リスクが受容できていることの確認はしている。でも、この規格の一つ一つの要求について、本当に必要か？という要求もないわけではない。

再発防止策の積み重ねは40年以上続いているのでハードルはどんどん高くなっており、医療機器ドメインへの新規参入はかなり難しくなっている。

でもハードルを下げれば、事故は増えるだろう。だからこそ、リスクの高い機器についてはハードルを上げざるを得ず、リスクの低い機器やヘルスソフトウェアのハードルは下げて上げるのが現実的であり、米FDAはそういうアプローチを採っている。

では、人工呼吸器はどうか。生命維持装置なのでリスクが高い機器であることは間違いない。人工呼吸器が足らない状況にみんなが協力して打開しようとすることはとても良いことだが、よかれと思った取った行動が逆の結果を招くかもしれないのが、医療機器の怖さでもある。

意図通りに動作すれば社会に貢献でき、高い満足感も得られるが、その裏側には大きな責任（＝リスク回避の責任）もあるということだ。

この危機的な状況にあっても、安易に実験的な機器を現場に投入するよりは、現存する機器の増産の可能性を探ることが現実的なような気がする。

日本の自動車業界が医療機器製造業者に製造に関する支援を表明しているのはそういう理屈なのだろう。