『AISI ヘルスケア領域における AI セーフティ評価観点ガイド』付録 完全読解 ── 10観点を「誰が答えるか」で仕分け、医療機関向けに読み替える
【10観点フル質問票 + SKILL.md 全文つき】
2026年6月に、私は AISI (AI セーフティ・インスティテュート) の「ヘルスケア領域における AI セーフティ評価観点ガイド」を紹介しました。
そのとき、実践ガイドはいつ出ますかという問いに、年内に出る予定です、本稿は暫定の運用版として読んでください、と答えています。
https://note.com/nice_wren7963/n/n395da7ba1584
その宿題が、2026年8月5日に返ってきました。
この記事は、note に公開した記事の完全版です。
note 版では紙幅の都合で削った、10 観点それぞれの質問文、ベンダーからもらうべき証拠の種類、契約に書く条項の案、そして私が実際に動かしたときの生の結果を、すべて載せます。note 版は読み替えの手順までをまとめた短い版です。同僚に概要を渡すときの共有用としてお使いください。
https://note.com/nice_wren7963/n/nf9aed68f6c12
読み進める前に、言葉を 6 つだけ整理させてください。
AISI は AI セーフティ・インスティテュートの略で、IPA (情報処理推進機構) の下に置かれた国の機関です。
提供者は AI サービスを作って売る側で、ベンダーと言い換えても構いません。
導入者はそれを買って使う側で、病院やクリニックがこちらにあたります。
Non-SaMD は薬機法の医療機器にあたらないソフトウェアです。
10 の評価観点は AI の安全性を確かめる 10 個の切り口、5 つのフェーズは AI サービスが作られてから使われるまでの 5 段階です。
Agent Skills は、AI に「この資料をこう使いなさい」と教えておく仕組みで、SKILL.md という決まった名前のファイルを置いて使います。
第１章：6月に「まだです」と書いたものが届きました
8月5日に追加されたのは 2 つです。
ひとつは英語版のガイド本体と概要版、もうひとつが付録「プロンプトとスキルによる AI セーフティ評価の実践例」です。
公表は Ubie 株式会社が、日本デジタルヘルス・アライアンスの委員長として行いました。
付録は 3 段構えです。
1 段目は、そのままコピーして使えるプロンプトが 4 本です。
各評価観点のリスクとチェック項目の整理、開発フェーズ別チェックリストの生成、リスクアセスメントの支援、ステークホルダー別のアクション整理、という 4 種類が用意されています。
ガイドの第 3 章と第 4 章は Markdown 形式でも配られていて、これを ChatGPT や Claude に読み込ませたうえで、4 本のどれかを投げます。
2 段目は、AI サービスのプロジェクト機能に資料と指示をあらかじめ登録しておく方法です。
カスタム指示のテンプレートが 1 本まるごと載っています。
ユースケースを確認し、観点別の整理、フェーズ別のアクション、リスクアセスメントの概要、次の一手、という順で出力させる設計です。
3 段目が Agent Skills です。
国の機関の文書が SKILL.md というファイル名と置き場所のフォルダ名まで指定し、Claude Code なら .claude/skills/、OpenAI Codex と Gemini なら .agents/skills/ と表にしています。
付録には SKILL.md の記述例が全文載っています。
公的な日本語文書がここまで具体的に AI エージェントの使い方を書いた例を、私は他に知りません。
ミニまとめ
追加されたのはプロンプト 4 本、プロジェクト機能の設定例、Agent Skills の 3 段構えです。
英語版も同時に出ました。
第２章：このガイドは「作る人」向けに書かれています
ここで、多くの医療者がつまずきます。
ガイドの概要版 3 ページ目に、対象者がはっきり書かれています。
AI 提供者、つまり学習済みの生成 AI モデルを API 経由などで利用してプロダクトやサービスの開発を行う事業者です。
想定読者として並んでいるのも、経営層、プロダクトマネージャー、エンジニア、法務です。
対象となるプロダクトも、Non-SaMD で、テキストを生成する AI に絞られています。
病院はこの文書の宛先ではありません。
配られたプロンプトを見ると、それがもっとはっきりします。
どのプロンプトにも「プロダクト概要」を書く欄があり、そこに入れるのは、自分たちが作っているサービスの種別、対象ユーザー、主な機能、扱うデータ、使っている大規模言語モデルです。
買う側の病院は、このどれも自分では書けません。
ベンダーに聞かないと分からないからです。
5 つのフェーズも同じ構造です。
設計、モデル選定、実装の 3 段階は、提供者の社内で起きることです。
病院は立ち会えません。
検証と、導入して運用する段階になって、ようやく病院が当事者になります。
ここを「病院が自分で点検する」と考えると、必ず手が止まります。
これはガイドの欠陥ではありません。
宛先が違うだけです。
ミニまとめ
ガイドの宛先は作る側です。
5 つのフェーズのうち最初の 3 つは、病院が立ち会えない場所で起きます。
第３章：使う側の道具に変える
では病院には関係ないのかというと、そうではありません。
読み替えれば使えます。
読み替えの中身は一行です。
自分で埋める表として読むのをやめて、ベンダーに埋めさせる表として読む。
それだけです。
プロンプトの「プロダクト概要」欄を、空欄のままベンダーに送って、記入して返してくださいと頼む。
これだけで、ふだんは出てこない情報が出てきます。
どの大規模言語モデルを使っているのか、患者が入力したデータはどこに保存されるのか、学習に使われるのか。
商談の場では流されがちな話が、書面で残ります。
6月の記事で、私は小さなクリニックの読者に向けて一行だけ書いていました。
完全な点検は要りません、自院で開発するのでなければ、ベンダーを選ぶときのチェック項目として使うのが現実的です、と。
あのときは手段がありませんでした。
8月5日にプロンプトが配られたことで、その一行が実行できるようになりました。
ここで大事な線引きをしておきます。
この読み替えは、ガイドが想定した使い方ではありません。
禁じられてもいませんが、公式の手順でもありません。
病院がこれをやったからといって、ガイドを守ったことにはなりませんし、法律上の義務を果たしたことにもなりません。
あくまで、ベンダーに説明を求めるための道具です。
この線引きを曖昧にすると、2 つの事故が起きます。
ひとつは、AISI に沿ったから安全だ、という誤解です。
もうひとつは、提供者が負うべき責任を病院が肩代わりしてしまうことです。
どちらも、後から効いてきます。
ミニまとめ
自分が埋める表ではなく、ベンダーに埋めさせる表として読み替えます。
ただしこれは公式の使い方ではなく、義務を果たしたことにもなりません。
第４章：10の観点は、誰が答えるべきものか
読み替えを実際にやると、次の壁が来ます。
10 の観点を全部ベンダーに聞いても、答えが返ってこないものがあるのです。
学習データの中身は企業秘密ですし、攻撃への強さを病院が試すことはできません。
そこで、10 の観点を「誰が答えるべきか」で 3 つに仕分けします。
ベンダーが証明すべきもの、病院が自分で担保するもの、契約書に書いて両者で決めるものです。
この表を作ると、病院がやるべきことが急に減ります。
10 個のうち、病院が自分で担保するのは、使い方のルールと、人が最後に確認する運用と、入力するデータの管理です。
残りは「聞く」か「契約に書く」に落ちます。
参考までに、ガイド本体が示している 10 観点と 5 フェーズの組み合わせ表も載せておきます。
作る側がどこまで細かく点検するのかが分かると、ベンダーへの質問の解像度も上がります。
10 観点そのものの一覧も引いておきます。
ミニまとめ
10 の観点を、聞くもの、自分でやるもの、契約に書くもの、の 3 つに仕分けします。
病院が自分でやるのは 3 つ程度です。
第５章：10観点の質問票
ここからが配布物です。
10 の観点それぞれについて、そのまま口に出せる質問文と、証拠として何をもらうか、答えが不十分だったときにどうするかを並べます。
印刷して商談に持ち込める分量にしてあります。
観点 1、有害な情報を出さないこと。
質問文はこうです。
患者さんが自傷や過量服薬について書き込んだとき、このサービスはどう応答しますか。
危険な内容をはじく仕組みはありますか。
その仕組みを、どうやって検証しましたか。
もらう証拠は、危険な入力に対する応答の設計書と、検証した件数と結果です。
答えが不十分なときは、その用途では使わないという条件をつけて導入するか、見送ります。
観点 2、嘘や誤りを防ぐこと。
質問文はこうです。
このサービスが参照している情報源は何ですか。
添付文書や診療ガイドラインを参照していますか。
その情報源はどのくらいの頻度で更新されますか。
回答に出典は表示されますか。
事実と違う出力が出た割合を測っていますか。
もらう証拠は、参照している情報源の一覧と更新の頻度、そして誤りの発生率の実測値です。
実測値が出てこない場合、まだ測っていない可能性が高いので、そこを確認します。
観点 3、個人情報を守ること。
質問文はこうです。
患者さんが入力した内容は、御社および御社が使っている AI の提供元で、モデルの学習に使われますか。
それは初期設定でそうなっていますか、それとも申請すれば止められますか。
保存場所はどこの国ですか。
保持期間と、削除を求める手続きを教えてください。
データ処理に関する契約は結べますか。
再委託先の一覧を出せますか。
もらう証拠は、利用規約の該当箇所、データ処理契約の雛形、再委託先の一覧です。
ここは最も重要なので、口頭の説明で終わらせないでください。
観点 4、セキュリティを確保すること。
質問文はこうです。
脆弱性が見つかったとき、どのくらいの期間で修正しますか。
第三者による診断を受けていますか。
事故が起きたとき、当院には何時間以内に連絡が来ますか。
もらう証拠は、脆弱性対応の方針、第三者診断の報告書の要約、事故時の連絡体制です。
観点 5、想定外の使われ方を防ぐこと。
質問文はこうです。
このサービスは薬機法の医療機器にあたらない、という判断の根拠を文書でいただけますか。
あわせて、御社が「これはさせない」と決めている機能を教えてください。
これは、最も重要な質問だと考えています。
問診を要約するだけのサービスは、通常は事務の支援として医療機器にあたらないと説明されます。
ところが、要約のなかに緊急度や疑われる病名の示唆が入った瞬間に、それは実質的なトリアージになります。
緊急度も判定できますので優先順位づけに使えます、という説明と、これは医療機器ではありません、という説明が同時に出てきたら、その 2 つは両立しません。
もらう証拠は、医療機器該当性の判断根拠を書いた文書と、してはいけないと定義した機能の一覧です。
観点 6、公平性と包摂性。
質問文はこうです。
どういう患者層で検証しましたか。
高齢の方、認知症の方、視覚や聴覚に障害のある方、日本語を母語としない方は、使えますか。
使えない場合、代わりの手段は用意されていますか。
もらう証拠は、検証したときの患者層の内訳と、対象外とする患者層の明示です。
自院の患者層と大きく違う場合、その差を埋める話をします。
観点 7、説明できること。
質問文はこうです。
この出力がなぜそうなったのかを、患者さんに説明できる形で示せますか。
カルテにはどう記録されますか。
もらう証拠は、根拠を示す機能の説明と、カルテへの記録の仕様です。
観点 8、安定して動くこと。
質問文はこうです。
中で使っているモデルを更新するとき、当院に事前に知らせますか。
更新によって挙動が変わった場合、どう検知しますか。
当院が版を固定したいと言った場合、それは可能ですか。
もらう証拠は、変更管理の方針と、事前通知の取り決めです。
ここは契約に書ける項目です。
観点 9、データの質。
質問文はこうです。
学習や参照に使っているデータの出所を教えてください。
医療の専門家がその内容を確認していますか。
もらう証拠は、データの出所と、専門家によるレビューの有無です。
企業秘密で答えられないと言われることも多いので、その場合は契約で担保する方向に切り替えます。
観点 10、検証できること。
質問文はこうです。
導入前に当院で試す期間をもらえますか。
そのとき何をどう測ればよいか、御社の推奨はありますか。
運用が始まったあと、記録の開示を求めることはできますか。
もらう証拠は、受け入れ試験の手順案と、記録開示の可否です。
10 個すべてを毎回聞く必要はありません。
絞り方を続けて書きます。
忙しい人のための最小版
外来の合間にできる分量ではない、と感じた方へ。
最小版を置きます。
まず、3 つだけ聞きます。
個人情報の扱い (観点 3)、想定外の使われ方への対策 (観点 5)、データの質 (観点 9) です。
この 3 つは、事故が起きたときに最も重い結果になりやすく、しかも病院側の運用に直結します。
そして、もうひとつだけ足すなら、患者さんが入力した元の文章が残るかどうかを聞いてください。
要約だけがカルテに渡り、元の文章が消える設計だと、あとで何が起きたのかを誰も検証できなくなります。
この 4 問に、書面で、固有名詞と数字を伴う答えが返ってくるかどうか。
それだけでも、判断材料としてはかなりの部分が埋まります。
返答が口頭だけ、あるいは持ち帰りますで終わるなら、その時点でひとつの情報です。
紙に印刷して商談の場に持ち込んでも構いません。
この手順に AI は必要ありません。
ミニまとめ
個人情報、想定外の使われ方、データの質、元文章の保全。
この 4 つを書面で聞きます。
第６章：ベンダーの答えを聞き分ける
質問を送ると、答えが返ってきます。
ここからが本番です。
安全性には十分配慮しております、という文章は、答えになっていません。
業界標準に準拠しています、も同じです。
準拠している対象の名前と版数が書かれていなければ、確かめようがないからです。
私が使っている見分け方は 3 つです。
ひとつめは、固有名詞と数字があるかどうかです。
どのモデルを使い、どの規格の第何版に対応し、何件で検証したのか。
ここが書けるベンダーは、社内で実際に検討しています。
ふたつめは、実現の方法まで書いてあるかどうかです。
誤った情報を出さないようにしています、では足りません。
どういう仕組みでそうしているのかが要ります。
みっつめは、できないことを自分から言っているかどうかです。
この患者層では精度が落ちます、この使い方は想定していません、と書いてくるベンダーは、むしろ信用できます。
すべてに丸がつく回答書のほうが危険です。
信号で整理すると、こうなります。
赤にあたるのは、医療機器にあたるかどうかの説明が曖昧なまま、緊急度の判定もできると宣伝している場合です。
利用規約で学習への利用が許されている場合も赤です。
画面の設計上、人が最後に確認する場面が消えている場合も赤です。
黄にあたるのは、証拠が口頭だけの場合、検証結果の開示を断られた場合、海外での処理について説明が足りない場合です。
緑にあたるのは、観点ごとに書面で回答があり、記録の方針が示され、院内での使い方のルール案まで一緒に出てくる場合です。
参考までに、ガイドが示している製品の内部構造も載せておきます。
AI の安全性は、モデルだけで守るものではなく、入力、モデル、出力、参照データ、画面、セキュリティという層で守るものだ、という図です。
ベンダーに「どの層で何をしていますか」と聞くときの下敷きになります。
ミニまとめ
固有名詞と数字、実現方法、できないことの明示。
この 3 つで答えの質が判別できます。
第７章：契約に落とす3つの条項と、AISI 以外に確認すべきこと
質問への答えが口頭で終わる項目は、契約に落とします。
優先順位の高い 3 つを挙げます。
ひとつめは、学習への利用の禁止と、記録の扱いです。
患者さんが入力した内容をモデルの学習に使わないこと、記録をどこにどれだけ保存するか、契約が終わったときにどう消すかを書きます。
ふたつめは、事故が起きたときの通知の期限です。
何時間以内に、誰に、どういう手段で知らせるかを決めます。
期限のない通知義務は、実質的に機能しません。
みっつめは、変更前の通知と、再テストの権利です。
中で使っているモデルが変わると、挙動も変わります。
事前に知らせてもらい、必要なら受け入れ試験をやり直せることを書いておきます。
ここまでが AISI のガイドを起点にした話です。
ただし、これだけでは足りません。
AISI は、既存の制度を置き換えるものではないからです。
導入の前に確認する順番を書いておきます。
最初に、そのサービスの使用目的が、診断や治療の決定を代わりに行うものになっていないかを見ます。
ここが薬機法の医療機器にあたるかどうかの入口です。
次に、医療機器にあたらないという判断の根拠が文書としてあるかを確認します。
そのうえで、要配慮個人情報を扱う委託の契約があるかを見ます。
病歴は要配慮個人情報です。
さらに、厚生労働省の医療情報システムの安全管理に関するガイドラインに照らして、クラウドを使う場合の確認が済んでいるかを見ます。
ここまで済んでから、AISI の 10 観点の質問票を送ります。
最後に、してはいけない使い方と、人が最後に判断することを、院内の規程に書きます。
順番が大事です。
AISI の質問票から始めると、より重い法的な論点を見落とします。
なお、8月5日には英語版も公開されました。
海外のベンダーや多国籍のクラウド事業者と話すとき、同じ物差しを英語で渡せるようになった、という意味があります。
海外本社に回して回答をもらう、という使い方ができます。
ミニまとめ
契約に書くのは、学習利用の禁止、事故時の通知期限、変更前の通知と再テスト権です。
AISI の前に、薬機法と個人情報保護法と安全管理ガイドラインを確認します。
第８章：実際に走らせてみました
AISI が配ったものを、私自身の環境で動かしました。
結果を正直に書きます。
試したのは 2 通りです。
ひとつは、第 3 章と第 4 章のファイルを AI に読ませたうえで相談する、というやり方です。
もうひとつは、AISI が例示した SKILL.md を指定どおりのフォルダに置き、同じ相談をする、というやり方です。
相談文はどちらも同じにしました。
当院は200床の地域中核病院です、外来の問診を補助する AI サービスの導入をベンダーから提案されています、私は臨床医でエンジニアではありません、情報システム部門は1名だけです、このサービスを導入してよいか判断するために何を確認すべきか教えてください、という内容です。
結果を先に書くと、ファイルを直接読ませたほうが、はっきり良い答えが返ってきました。
ファイルを読ませたほうは、こちらが何も言っていないのに、冒頭でこう返してきました。
この 2 つの章は AI を開発する事業者向けに書かれています、あなたの立場は導入者なので、そのままチェックリストを埋めようとすると、自分では答えられない項目ばかりになって手が止まります、と。
この記事で私がここまで書いてきたことを、AI が自分で言い当てたわけです。
そのうえで、ベンダーに証拠を出させるもの、院内でしか担保できないもの、契約に落とすもの、の 3 つに整理して返してきました。
さらに、ベンダーに会う前に院内で決めておくこととして、このサービスに何をさせないか、要約を誰がいつ確認するか、止める権限を誰が持つか、患者への説明と同意をどう取るか、の 4 つを挙げてきました。
質の高さの理由は、参照の仕方にありました。
ガイドの章番号や表番号を引いた記述が 11 か所あり、10 の観点への言及が 13 回ありました。
ガイドに収録されている実際の事故事例も引用していました。
一方、SKILL.md を置いたほうは、10 の観点にも 5 つのフェーズにも一度も触れませんでした。
回答の内容自体は悪くなく、医療機器該当性、患者データの学習利用、電子カルテとの接続費用という 3 点を先に潰すべきだという指摘は的確でした。
ただし、AISI のガイドを参照した形跡が数えて 0 件です。
つまり、スキルが働いていません。
原因は確かめました。
AISI が書いた SKILL.md には、どんなときに発動するかの条件として、ヘルスケア、AI 安全性、セーフティ評価、といった言葉が並んでいます。
ところが私が投げた相談文は、AI サービスの導入を提案されています、何を確認すべきでしょうか、という、医療者が実際に使う言い回しでした。
ここに、発動条件の言葉が 1 つも入っていません。
そこで、同じ内容を「ヘルスケア AI のセーフティ評価をお願いします」と言い換えて、もう一度投げました。
今度は動きました。
10 の観点のうち重点となる 4 つを特定し、SKILL.md が指示しているとおりのリスク登録簿を、危険度の高い順に番号をつけて出してきました。
要約が胸痛や黒色便や自殺念慮を静かに落とす危険、医師が要約だけを読んで元の文章を確認しなくなる危険、要約がトリアージに転用される危険。
どれも、この製品を検討するなら最初に見るべき論点です。
つまり、このスキルは壊れているのではありません。
ガイドの言葉で話しかけたときだけ動きます。
医療者が自然に使う言い回しでは動きません。
置いてあるのに使われない、という状態になります。
これは、スキルという仕組みの一般的な性質でもあります。
発動条件に書いた言葉と、利用者が実際に打つ言葉がずれていると、そのスキルは存在しないのと同じになります。
医療者向けに配るなら、発動条件は医療者の言い回しで書く必要があります。
この記事の後半で、その書き換え案を置きます。
もうひとつ見つかったことがあります。
AISI の SKILL.md は、リスク登録簿のテンプレートとチェックリストのテンプレートという 2 つのファイルを参照するように書かれています。
ところが、この 2 つは配布物に含まれていません。
参照先が存在しないので、AI はそこを自分で埋めることになります。
AISI が意図した形式とは違うものが出てくる可能性があります。
これらは欠陥というより、公開されたばかりの実践例が抱えている初期の課題だと思います。
ただ、読者が同じことをやって同じところで止まるのは避けたいので、記録として書いておきます。
限界も書いておきます。
この実験は私自身の環境で 1 回ずつ行ったものです。
まっさらな環境ではありませんし、相談文も 1 種類だけです。
他の環境や他の聞き方では違う結果になる可能性があります。
一般化できる強さの結果ではありません。
ミニまとめ
ファイルを直接読ませたほうが良い結果でした。
スキルは発動しませんでした。
原因は発動条件の言葉と、実際の言い回しのずれです。
第９章：医療機関向けに書き換えた SKILL.md
院内に技術者がいる場合に向けて、AISI の例を書き換えたものを置きます。
変更点は 3 つです。
発動条件を医療者の言い回しに合わせたこと、立場を導入者に固定したこと、参照先のテンプレートを外したことです。
---
name: healthcare-ai-vendor-review
description: 医療機関が AI サービスの導入を検討するときに、ベンダーへ確認すべき事項を整理する。AISI ヘルスケア AI セーフティ評価観点ガイドの 10 観点にもとづき、ベンダーに聞く質問、院内で担保すること、契約に書くことに仕分ける。「AI サービスの導入」「ベンダーから提案」「導入してよいか」「問診 AI」「音声カルテ」「患者向けチャット」「何を確認すべき」「稟議」「選定」などで発動する。
---
# 医療機関向け AI ベンダー審査スキル
## 立場の固定
利用者は AI を開発する事業者ではなく、AI サービスを導入する医療機関である。
利用者に開発内容を尋ねない。開発側の情報は「ベンダーに聞く項目」として出力する。
## 参照ファイル
- chapter3.md: AI セーフティ評価の 10 観点
- chapter4.md: プロダクト開発 5 フェーズの評価実践
## 対応手順
### Step 1: 状況の確認
次を確認する。不足があれば先に尋ねる。
- サービスの種類 (問診補助 / 音声カルテ / 患者向けチャット / その他)
- 施設の規模と、情報システム担当者の人数
- 患者の情報が入力されるか
- 導入の段階 (情報収集 / 商談中 / 契約直前 / 導入済み)
### Step 2: chapter3.md を参照し、10 観点を 3 つに仕分ける
各観点について次の 3 列で出力する。
- ベンダーに証明させること (そのまま送れる質問文で書く)
- 院内で担保すること
- 契約に書くこと
### Step 3: 優先順位をつける
事故時の影響が大きい観点から並べる。時間がない場合に絞る 3 観点を明示する。
### Step 4: 商談で使える形にする
質問文は口に出せる文にする。箇条書きの単語で終わらせない。
各質問に「良い回答」と「不十分な回答」の例を添える。
## 注意事項
- 出力はガイドにもとづく下書きであり、院内の正式なリスク評価の代わりにはならない。
- 薬機法上の医療機器該当性、個人情報保護法への対応、医療情報システムの安全管理に
関するガイドラインへの適合は、必ず専門家に確認するよう明記する。
- 患者個人の情報を入力しないよう、冒頭で注意する。
- ガイドに書かれていない見解を述べる場合は、その旨を明示する。置き場所は、AISI の表に従います。
Claude Code なら .claude/skills/healthcare-ai-vendor-review/、OpenAI Codex と Gemini なら .agents/skills/healthcare-ai-vendor-review/ です。
同じフォルダに chapter3.md と chapter4.md を置きます。
ただし、ここまで読んで分かるとおり、この作業は病院の情報システム担当者でも手間がかかります。
前の章の結果からすると、ファイルを直接読ませるやり方で十分です。
スキルにする価値が出るのは、同じ作業を何度も繰り返す場合だけです。
ミニまとめ
発動条件を医療者の言い回しに変え、立場を導入者に固定し、無いテンプレートへの参照を外しました。
ただし、繰り返さないならスキルにする必要はありません。
第１０章：やってはいけないこと
してはいけないことを 4 つ挙げます。
ここが、この記事でいちばん伝えたい部分かもしれません。
患者さんの情報を、外部の AI サービスに入れないでください。
ベンダーの製品情報を確認するのに、患者データは要りません。
院内で AI の利用が禁止されている場合は、質問票を紙で作れば足ります。
AI が出したチェックリストを、そのまま院内規程にしないでください。
あれは下書きです。
AISI 自身が、法律に関わる最終判断は専門家に確認するように、と書いています。
AISI のガイドを確認したから安全だ、とも書かないでください。
このガイドに法的な拘束力はありません。
薬機法の医療機器にあたるかどうか、個人情報保護法をどう満たすか、医療情報システムの安全管理ガイドラインに合っているか。
これらは別に確認が要ります。
逆に、拘束力がないから無視してよい、とも言えません。
事故が起きたあとで、確認できたはずのことを確認していなかった、と問われる場面はあります。
今後の見通しとしては、罰則つきの義務になるより先に、大きな病院や公的な事業の調達で「AISI のガイドを参照した評価を実施しましたか」と聞かれるようになる、という順序が現実的だと考えています。
断定はできません。
ただ、今のうちに質問票の形にしておくと、将来の様式にそのまま載せ替えられます。
ミニまとめ
患者データを入れない。
AI の出力を規程にしない。
AISI だけで安全とも、無視してよいとも言わない。
FAQ
Q1. AISI の資料を自分で読めば済む話ではありませんか。
その通りです。
プロンプト 4 本も SKILL.md の例も、AISI のサイトから無料で読めます。
この記事が足しているのは、それを買う側の立場に読み替える手順と、実際に動かしたときにどこで止まるかの記録です。
読み替えの手順は公式には書かれていません。
Q2. 6月の記事とどこが違いますか。
6月の記事は、AISI のガイドを他の 9 本のガイドラインと並べて、どれを先に読むべきかを整理したものでした。
今回は、8月5日に追加された実践例だけを扱い、病院がベンダーに質問するための道具に読み替えます。
6月の記事を読んでいない方でも、この記事だけで完結します。
Q3. 院内で ChatGPT が使えなくても、この手順は使えますか。
使えます。
この記事の中心は、10 の観点を「誰が答えるべきか」で仕分けした表と、10 観点の質問票です。
どちらも紙で足ります。
AI を使うのは、質問票を自院の状況に合わせて手早く作り直したいときだけです。
Q4. ベンダーが質問に答えてくれない場合はどうしますか。
答えられない理由を聞いてください。
企業秘密だから答えられない、という項目は実際にあります。
その場合は、契約書に書けるかどうかに切り替えます。
学習に使わない、事故が起きたら何時間以内に知らせる、版を変えるときは事前に通知する。
この 3 つが契約に書ければ、口頭の説明よりずっと確実です。
Q5. 英語版が出たことに意味はありますか。
海外のベンダーや多国籍のクラウド事業者と話すときに、同じ物差しを英語で渡せます。
日本語版だけだと、海外本社に回した時点で議論が止まります。
国際的な調達を考えている施設には効きます。
【まとめ】
2026年8月5日に AISI が追加した実践例は、ガイドを「読むもの」から「使うもの」に変えました。
ただし、その使い手として想定されているのは、AI サービスを作る事業者です。
病院やクリニックは宛先ではありません。
それでも、読み替えれば使えます。
自分で埋める表としてではなく、ベンダーに埋めさせる表として読む。
10 の観点を、聞くもの、自分でやるもの、契約に書くもの、の 3 つに仕分ける。
この 2 つの操作で、提供者向けの文書が、導入する側の質問票になります。
実際に動かしてみると、公式が例示したスキルの置き方より、ファイルを直接読ませる素朴なやり方のほうが良い結果を返しました。
参照先のテンプレートが配布されていないなど、公開直後らしい荒さも残っています。
このガイドを確認したからといって、安全が保証されるわけではありません。
法的な義務が生まれるわけでもありません。
それでも、何を聞けばよいか分からないまま商談に臨むよりは、ずっとましです。
聞くべきことが決まっていれば、答えの質でベンダーを見分けられます。
最後に、立場を明らかにしておきます。
私は医療 AI のガバナンスと監査を事業とする会社を経営しています。
この記事の内容は、その事業と無関係ではありません。
そのうえで、この記事に書いた手順はすべて、無料で公開されている資料だけで実行できるように書きました。
この記事の付録について
10 観点の質問票、ベンダー回答の記録用紙、契約に書く 3 条項の案、そして医療機関向けに書き換えた SKILL.md を、コピーして使える形にまとめています。
院内の稟議や、ベンダーとの商談にそのまま持ち込める粒度で作りました。
Cursorvers では、臨床知をそのまま資産に変えるための実践的な環境を公開しています。
評論ではなく実践として医療の未来に関わりたい方は、メンバーシップもご検討ください。
本記事で綴った「AIに臨床の魂を宿す」という想いは、単なる考えの提案にとどまりません。具体的な「臨床現場への実装」へと段階を移しました。
記事を読むだけでなく、実際に手を動かすための環境も公開しています。安全なガバナンスの下で、臨床知を形式知・資産へと変えていくための実践的環境（Cursorvers Library）です。
その理念に共鳴し、評論家ではなく「実践者」として医療の未来を作りたい方は、是非メンバーシップ（無料・有料）への加入をご検討ください。
（もし不具合があれば、お問い合わせフォームからご連絡ください。）
▼ Cursorvers Program Roadmap
参考資料
・AISI ヘルスケア領域における AI セーフティ評価観点ガイドの公開 (Publication of the Guide to Evaluation Perspectives on AI Safety in the Healthcare Sector — Japan AISI): https://aisi.go.jp/output/output_information/260402/
・同 ガイド本体 第1.0版 (PDF): https://aisi.go.jp/assets/pdf/20260402_healthcare_ai_safety_eval_v1.0_ja.pdf
・同 概要版 第1.0版 (PDF): https://aisi.go.jp/assets/pdf/20260402_healthcare_ai_safety_eval_summary_v1.0_ja.pdf
・同 付録 プロンプトとスキルによる AI セーフティ評価の実践例 (PDF): https://aisi.go.jp/assets/pdf/20260402_healthcare_ai_safety_eval_example_v1.0_ja.pdf
・同 付録 実践例 (Markdown): https://aisi.go.jp/assets/file/20260402_healthcare_ai_safety_eval_example_v1.0_ja.md
・同 第3章 AI セーフティ評価の10観点 (Markdown): https://aisi.go.jp/assets/file/20260402_healthcare_ai_safety_eval3_v1.0_ja.md
・同 第4章 AI プロダクト開発における AI セーフティ評価の実践 (Markdown): https://aisi.go.jp/assets/file/20260402_healthcare_ai_safety_eval4_v1.0_ja.md
・同 英語版 ガイド本体: https://aisi.go.jp/assets/pdf/20260402_healthcare_ai_safety_eval_v1.0_en.pdf
・同 英語版 概要版: https://aisi.go.jp/assets/pdf/20260402_healthcare_ai_safety_eval_summary_v1.0_en.pdf
・IPA プレス発表 AISI、ヘルスケア領域における AI セーフティ評価観点ガイドを策定: https://www.ipa.go.jp/pressrelease/2026/press20260403.html
・JaDHA ニュース ヘルスケア領域における AI セーフティ評価ガイドを策定: https://jadha.jp/news/news20260403.html
・Ubie プレスリリース 英語版およびプロンプト実践例を公開 (2026-08-05): https://prtimes.jp/main/html/rd/p/000000222.000048083.html
・拙稿 AISI ヘルスケア AI 評価観点 v1.0 と既存 9 ガイドラインの差分マップ (2026-06-04): https://note.com/nice_wren7963/n/n395da7ba1584
・厚生労働省 医療情報システムの安全管理に関するガイドライン: https://www.mhlw.go.jp/
・PMDA プログラム医療機器の該当性に関する情報: https://www.pmda.go.jp/
・個人情報保護委員会 医療関連分野ガイダンス: https://www.ppc.go.jp/
本来は開発者向けに書かれたガイドラインを、「ベンダーに回答を求めるチェックリスト」として読み替える発想にすごく納得しました。医療機関の現場で自力で評価しようとすると手が止まってしまいますが、質問票として落とし込み、何を聞くべきかを明確にする手順は非常に実践的で参考になります。