対象読者： エンジニア全般、臨床工学技士、医療情報担当者、病院のIT管理に関わる方
読了時間： 約20分
この記事のポイント（3行要約）
- 認証情報が1つ破られたとき、影響がどこまで広がるかは「アカウント設計」で決まる
- 病院ネットワークは「更新できない機器が繋がったまま動き続ける」という特殊な制約を持ち、そこにセキュリティ設計の本質が凝縮されている
- 守り方の考え方は、Ethernet / TCP/IP の階層構造と「疎結合」という同じ発想で説明できる
⚠️ 大事な前置き
この記事は、筆者の現時点での個人的な学習メモをまとめたものであり、法的助言でも、特定製品・構成の推奨でもありません。
実際に院内システムやネットワークの設計・変更を行う場合は、必ず医療情報システム安全管理責任者、医療機器安全管理責任者、システムベンダー、および必要に応じて所管行政機関と相談したうえで判断してください。
筆者は、この記事の内容を実際の業務で使われたことに起因するいかなる損害についても責任を負いません。
はじめに
生成AI、クラウドサービス、SNS、GitHub、SaaS。
現在の仕事では、ひとつのアカウントだけを利用して業務が完結することはほとんどありません。Google、Microsoft、GitHub、クラウドサービス、開発環境、SNSなど、複数のサービスが連携しながら日々の仕事を支えています。
便利である一方で、ひとつの認証情報に問題が起きたとき、その影響がどこまで広がるのかを理解しておくことも重要だと改めて感じました。
きっかけは、筆者自身のSNSアカウントが不正アクセスを受けたことです（この件はX上で公表済みです）。詳細な経緯はここでは扱いませんが、対応の過程で気づいたことがありました。
自分は「守り方」を知っているつもりで、「壊れたときの構造」を知らなかった、ということです。
セッション一覧を開いたとき、そこに並んだ端末が正常なのか異常なのか、即座に判断する基準を自分が持っていませんでした。パスワードを変えれば安全になると漠然と思っていて、セッションと連携アプリが別枠で残ることを実感として理解していませんでした。
この記事では、その学び直しとして整理した内容をまとめます。あわせて、臨床工学技士として11年間見てきた病院ネットワークという「特殊な環境」の話も書きます。
一般のIT環境と病院の環境は、一見まったく別物です。しかし整理していくと、根っこにある考え方は驚くほど似ていました。
🔰 第1部：まず理解したい5つの基本
セキュリティは「専門家だけの仕事」ではない
以前は、セキュリティというとSOC、CSIRT、ネットワークエンジニア、セキュリティエンジニアといった専門職が扱う領域という印象がありました。
しかし生成AIやクラウドを日常的に使う現在では、一般のエンジニアにも一定の知識が必要です。
重要なのは「攻撃方法を詳しく知ること」よりも、「自分のアカウント、端末、認証情報、データをどう守るか」 を理解することだと考えています。
1. パスワードはサービスごとに分ける
最も基本的でありながら、非常に重要です。
仮にサービスAから認証情報が漏洩した場合でも、サービスB・C・Dですべて別のパスワードを使用していれば、被害の連鎖を抑えられます。
攻撃者の視点で考えると分かりやすい。 攻撃者はまず、どこかで漏れた「メールアドレス＋パスワード」の組み合わせを大量に入手します。そして、それを片っ端から他のサービスに試します。これをクレデンシャルスタッフィング（credential stuffing＝漏洩した認証情報を使い回して他サービスへ侵入を試みる攻撃）と呼びます。
パスワードを使い回していなければ、この攻撃は1サービスで止まります。使い回していれば、1つの漏洩が全滅につながります。
人間が何十個も覚えることは現実的ではないので、パスワードマネージャーを利用する方が合理的です。
⚠️ 補足：自分で考えた「規則的なパスワード」（サービス名を末尾に足す等）は、パターンが見抜かれた時点で全滅します。生成器に任せるほうが安全です。
2. 多要素認証を「追加機能」ではなく標準にする
パスワードだけに依存した認証には限界があります。
そこで重要なのが、認証アプリ、パスキー、セキュリティキー、2要素認証です。
ここで押さえておきたいのは、多要素認証にも強度の差があるということです。
🔴 SMSによる2要素認証
一定の効果はありますが、SIMスワップ（携帯電話会社を騙して他人のSIMを再発行させる攻撃）や、SS7という電話網のプロトコルを悪用した傍受のリスクが指摘されています。「ないよりはるかに良いが、最善ではない」という位置づけです。
🟡 認証アプリ（TOTP）
TOTP（Time-based One-Time Password＝時刻をもとに30秒ごとに変わる6桁の使い捨てパスワード）を使う方式です。SMSより強固ですが、偽サイトに誘導されて本人が入力してしまうと突破されます。攻撃者がリアルタイムで本物のサイトに転送すれば通ってしまうためです。
🟢 パスキー / セキュリティキー（FIDO2 / WebAuthn）
こちらはフィッシングに対して原理的に強い方式です。
理由は、認証時に「どのドメインからのリクエストか」が暗号的に検証されるためです。偽サイト（例：x-login.example.com）から要求されても、本物の x.com 用に登録された鍵は反応しません。人間が騙されても、ブラウザと認証器が騙されない構造になっています。
可能な限りパスキーへ移行していく方針が合理的だと考えています。
3. 「ログインできるか」ではなく「誰がログインしているか」を見る
アカウントの安全性を確認するとき、「自分がログインできるから大丈夫」だけでは不十分です。
確認すべきなのは以下です。
- 現在のログインセッション
- 過去にログインした端末とIPアドレス
- 接続されているアプリ（OAuth連携）
- APIトークン
- SSH Key
- 登録されている復旧手段（メール・電話番号）
ここで実感として学んだことがあります。パスワードを変更しても、既存のセッションは自動的には切れません。
これはWebの仕組みを考えれば当然です。ログイン後に発行されるセッショントークン（またはCookie）は、パスワードとは別の資格情報として動いています。パスワードは「入口の鍵」で、セッションは「入った後に渡される館内パス」のようなものです。鍵を交換しても、既に配られた館内パスは回収しない限り有効なままです。
同様に、OAuth連携で発行されたアクセストークンやリフレッシュトークンも、パスワード変更とは独立して生き続けます。
したがって、侵害が疑われる場合の手順は次の3点セットになります。
- パスワード変更
- 全セッションの強制ログアウト
- 連携アプリ・APIトークンの取り消し
2と3を忘れると、パスワードだけ変えて「対応完了」と思い込む状態になります。
4. ブラウザも重要なセキュリティ境界
Chromeなどのブラウザには、パスワード、Cookie、セッション、拡張機能、OAuth認証状態、クラウドサービスへのログイン状態など、多くの重要情報が集まります。
特に注意したいのが拡張機能の権限です。
拡張機能をインストールするとき、「すべてのサイトのデータの読み取りと変更」という許可を求められることがあります。これは文字通り、あなたが見ているすべてのページの中身を読み、書き換えられるという意味です。
ログイン済みの管理画面も、Webメールも、社内システムも含まれます。パスワードマネージャーが入力した瞬間の値も、DOM上にあれば読める可能性があります。
対策としては以下が基本になります。
- 不要な拡張機能を減らす
- インストール前に要求される権限を確認する
- 出所不明のユーザースクリプトを実行しない
- セーフブラウジングを有効にする
- OS・ブラウザを更新する
「便利だから追加する」だけでなく、「この拡張機能にどこまでアクセスを許可しているのか」 を考える習慣を持ちたいと思います。
5. 復旧手段まで含めてセキュリティ
セキュリティというと「侵入されないこと」に注目しがちですが、リスクを完全にゼロにすることはできません。
そのため「何か起きたときにどう復旧するか」まで準備しておく必要があります。
実際に対応して分かった、事前に用意しておくべきもの
① 復旧用の連絡先が「生きている」こと
多くのサービスは、登録メールアドレスを起点に本人確認を行います。逆に言えば、そのメールアドレスを失うと復旧の起点そのものを失います。だからこそ、メール側のアカウントは最優先で守る必要があります。
② 所有権を証明できる材料
これは事前にはあまり意識していなかった点です。
有料プランを契約している場合、決済履歴は強力な所有権証明になります。決済プラットフォームから届いた領収書メールは、正当な契約者しか持っていません。アカウントを奪われても、支払い記録はメールボックスに残ります。
サポートに問い合わせる際、この種の「攻撃者には提示できない情報」を用意できるかどうかで、審査の通りやすさが変わります。
③ バックアップコードの保管場所
多要素認証を有効にすると発行されるバックアップコードは、スクリーンショットだけに頼らず、パスワードマネージャーなど別系統にも保管しておく必要があります。端末を失った瞬間に両方消えては意味がありません。
④ 重要アカウントの一覧
「どこに何のアカウントがあるか」を把握していないと、侵害時に何を確認すべきか分かりません。棚卸しは平時にしかできません。
これはBCP（Business Continuity Plan＝事業継続計画）の考え方に近いと感じました。そして医療の世界では、このBCPの発想がはるかに徹底しています。
🔧 第2部：病院ネットワークという特殊な世界
ここからは、臨床工学技士として現場で見てきた病院のネットワーク環境について書きます。
一般のIT環境とは前提条件が大きく異なります。そして、その違いを理解すると、セキュリティ設計における「制約の中での最適化」 という考え方が見えてきます。
🔰 前提知識：TCP/IPの階層をおさらいする
先に、最低限の用語を整理します。すでにご存じの方は読み飛ばしてください。
ネットワークは「階層」で考えます。郵便に例えると理解しやすくなります。
レイヤ1：物理層（ケーブル・電気信号）
LANケーブルや光ファイバそのもの。郵便で言えば「道路」です。
レイヤ2：データリンク層（Ethernet）
同じネットワーク内での配送を担当します。ここで使われるのがMACアドレス（機器ごとに割り振られた固有の識別番号。製造時に決まる）です。
郵便で言えば「同じマンション内の部屋番号」に相当します。マンション内の配達は部屋番号だけで完結します。
このレイヤで動くのがスイッチ（LANケーブルを束ねる機器）です。スイッチはMACアドレスを見て、正しいポートにだけデータを流します。
レイヤ3：ネットワーク層（IP）
異なるネットワーク同士をつなぐ層です。ここで使われるのがIPアドレスです。
郵便で言えば「住所」です。別の街に届けるには住所が必要です。この配送を担当するのがルータです。
レイヤ4：トランスポート層（TCP / UDP）
届いたデータを「どのアプリケーションに渡すか」を決める層です。ここで使われるのがポート番号（アプリケーションごとの窓口番号。Webなら443番など）です。
郵便で言えば「部屋の中の誰宛か」です。
レイヤ7：アプリケーション層
HTTP、DICOM、HL7など、実際のやりとりの中身です。
🔧 病院ネットワークが特殊である4つの理由
理由1：更新できない機器が、繋がったまま動き続ける
これが最大の制約です。
医療機器は、薬機法上の承認・認証を受けた製品です。組み込まれているソフトウェアやOSを勝手に更新すると、承認された仕様と異なる状態になる可能性があります。そのため、メーカーが検証・提供した手順以外での更新は原則としてできません。
結果として、サポートが終了した古いOSを搭載した機器が、院内で稼働し続けるという状況が生まれます。これは現場の怠慢ではなく、制度と安全性の要請から来る構造的な制約です。
さらに、医療機器は稼働を止められません。人工呼吸器、血液浄化装置、生体情報モニタは、患者さんが使用している間は電源を落とせません。「メンテナンスのため深夜に再起動します」が通用しない世界です。
一般のIT環境の常識である「速やかにパッチを当てる」が、そのままでは適用できません。
理由2：機器同士が独自のプロトコルで会話している
病院内では、一般的なWebプロトコル以外の通信が多く流れています。
- DICOM（Digital Imaging and Communications in Medicine＝医用画像の保存・通信に関する標準規格）：CT・MRI・超音波などの画像を、撮影装置からPACS（画像保管通信システム）へ送るときに使われます
- HL7（Health Level Seven＝医療情報交換のための標準規格）：電子カルテと部門システムの間で、患者情報やオーダー情報をやりとりします
これらは医療分野に特化した規格であり、一般的なセキュリティ製品が中身を正しく解釈できるとは限りません。汎用のファイアウォールやIDS（侵入検知システム）が、DICOM通信の異常を検知できるかどうかは製品次第です。
理由3：リモートメンテナンス回線という「必要な穴」
医療機器やシステムには、メーカーによる遠隔保守が設定されている場合があります。故障時に迅速に対応するため、これは臨床上きわめて有用です。
一方で、この回線は外部から院内に入る経路でもあります。
国内外で報告されている医療機関へのランサムウェア被害では、VPN機器の脆弱性やリモート保守経路が侵入口となった事例が公表されています。「必要だから開けている穴」が、そのまま攻撃面になるという構図です。
理由4：ネットワークが「部門ごと」に育ってきた歴史
多くの病院では、電子カルテシステム、放射線部門システム（RIS/PACS）、検査部門システム、透析支援システム、手術部門システムなどが、それぞれ別の時期に、別のベンダーによって導入されています。
その結果、ネットワークの全体像を一人が把握していないという状況が起こりやすくなります。どの機器がどのセグメントに繋がっていて、どこと通信しているのか。これを図面として正確に持っている施設ばかりではありません。
🎯 では、どう守るのか —— 分離という考え方
物理分離と論理分離
病院ネットワークの設計で基本になるのが「分離」です。
物理分離は、文字通り別のケーブル・別のスイッチで、まったく繋がっていないネットワークを作る方法です。最も確実ですが、コストがかかり、運用の柔軟性が下がります。
論理分離は、同じ物理配線を使いながら、論理的に別ネットワークとして扱う方法です。ここで使われるのがVLAN（Virtual LAN＝1台のスイッチを仮想的に複数のスイッチとして分割する技術）です。
VLANは、Ethernetフレームに「VLAN ID」というタグを付けることで実現されます（IEEE 802.1Qという規格）。同じスイッチに繋がっていても、VLANが違えばレイヤ2では直接通信できません。
例えるなら、同じマンションの中に、行き来できない別々の区画を作るようなものです。
なぜ分離が効くのか
分離の本質は、「1つ破られても、そこから先に進めない」構造を作ることです。
マルウェアの多くは、侵入後に同じネットワーク内の他の機器を探索します。これをラテラルムーブメント（lateral movement＝横方向への感染拡大）と呼びます。
ネットワークが平坦（フラット）だと、1台が感染した時点で全機器が探索範囲に入ります。分離されていれば、探索は同じセグメント内で止まります。
これは、船の隔壁（水密区画）と同じ発想です。船底に穴が開いても、区画で仕切られていれば船全体は沈まない。
境界防御からゼロトラストへ
ここで重要な変化があります。
厚生労働省の「医療情報システムの安全管理に関するガイドライン」第6.0版では、従来の「インターネットと院内ネットワークを分離すれば安全」という境界防御型の発想だけでは、USB経由のマルウェア侵入や内部不正といった巧妙化する攻撃に対応するのが難しいという整理がなされています。内部ネットワークであっても無条件に信頼せず、利用者や操作内容ごとにアクセスを管理する姿勢が示されており、これは一般に「ゼロトラスト」と呼ばれる考え方と重なる部分があります。
ゼロトラスト（Zero Trust＝「内部だから安全」という前提を置かず、すべてのアクセスを検証する考え方）は、クラウド時代のIT業界で広まった概念ですが、医療分野のガイドラインにも同じ方向性が現れています。
「院内LANだから安全」という前提が崩れつつある、ということです。
バックアップの考え方
同ガイドラインでは、サイバー攻撃対策としてバックアップをネットワークから論理的・物理的に切り離して保管すること、少なくとも3世代を確保することが示されています。重要なファイルは、追記可能な記録媒体と追記不能設定の媒体を組み合わせるなど、複数の方式で確保することが重要とされています。
ここで押さえておきたいのは、「ネットワークから切り離す」 という点です。
ランサムウェアは、感染端末から到達できる範囲のファイルを暗号化します。ネットワーク越しに常時アクセスできるバックアップは、一緒に暗号化されます。「バックアップを取っていたのに復旧できなかった」という事態は、ここから生じます。
オフラインバックアップ（テープ、切り離した外付けディスク、イミュータブルストレージ）が必要になるのは、この理由です。
🎯 医療機器とITネットワークをつなぐ国際規格
医療機器をネットワークに接続することのリスクについては、国際規格が存在します。
IEC 80001-1（Application of risk management for IT-networks incorporating medical devices）は、医療機器を組み込んだITネットワークにおけるリスクマネジメントの適用について規定した規格です。
この規格の考え方で重要なのは、「安全性」「有効性」「データとシステムのセキュリティ」を同時に扱うという点です。
一般のIT分野では、セキュリティの目標として機密性・完全性・可用性（CIA）が挙げられます。医療機器ネットワークでは、これに患者安全という軸が加わります。
セキュリティ対策のために通信を止めた結果、生体情報モニタのアラームが届かなくなれば、それは患者安全を損なう対策です。「守ること」と「動かし続けること」のバランスを、リスクとして評価する必要があります。
また、医療機器ソフトウェアのサイバーセキュリティについては、IEC 81001-5-1（国内ではJIS T 81001-5-1）が、JIS T 2304（医療機器ソフトウェアのライフサイクルプロセス規格）を前提に、製品ライフサイクルを通じて実施すべきセキュリティ活動を規定しています。
これらは主に製造販売業者側の規格ですが、医療機関側も「そういう枠組みで作られた製品を運用している」と理解しておく価値があると筆者は考えています。
🎯 第3部：病院インフラと一般ITに共通する構造
ここまで書いてきて、改めて気づいたことがあります。
病院ネットワークの設計思想と、個人のアカウントセキュリティの考え方は、同じ構造をしています。
| 病院ネットワーク | 個人・開発環境 |
|---|---|
| VLANによるセグメント分離 | サービスごとに異なるパスワード |
| 部門間のアクセス制御 | 最小権限のAPIトークン |
| ラテラルムーブメントの阻止 | 1つ漏れても他に入れない構造 |
| オフラインバックアップ | 復旧手段の分散保管 |
| ゼロトラスト（内部も検証） | セッション・連携アプリの定期確認 |
| 更新できない機器の隔離 | レガシー環境の分離運用 |
どちらも、根底にあるのは 「ゼロリスクを目指すのではなく、被害を限定する」 という発想です。
これはソフトウェア設計の疎結合（loose coupling＝各部品の依存関係を小さく保つ設計）に似ています。
認証情報も、ネットワークも、できるだけ依存関係を小さくしておく。1つが壊れても、それが全体に波及しない。この構造を作ることが、対策リストを増やすことよりも効果的だと考えています。
AIエンジニアとして特に気を付けたい認証情報
AI・Web開発では、一般的なアカウントに加えて以下を扱います。
- GitHub Personal Access Token
- SSH Key
-
.envファイル - 各種API Key（OpenAI、Anthropic等）
- Cloudflare / Vercel / AWS / GCP / Azure の認証情報
- Docker Hub の認証情報
- CI/CD の Secrets
これらは単なる「パスワード」以上の権限を持つ場合があります。APIトークンは、多要素認証を迂回します。 トークンを持っている者は、それ自体が認証済みの存在として扱われるためです。
したがって、以下の基本を徹底する必要があります。
- Gitにシークレットをコミットしない — 削除しても履歴には残ります
- 必要最小限の権限にする — read権限で足りるならwriteを付けない
- 使用期限を設定する — 無期限トークンを作らない
- 定期的にローテーションする
- 不要になったKeyは削除する
侵害が疑われたときのローテーション順序
ここも実際に整理して分かったことですが、順番が重要です。
- 先に新しいトークンを発行し、動作を確認する
- 次に古いトークンを失効させる
- その後で、必要ならgit履歴の書き換えを行う
順番を逆にすると、作業中に古いトークンが有効なまま残ります。また、履歴の書き換えを先にやってしまうと、何が漏れていたのかという証拠を自分で消してしまうことになります。
インシデント対応では「調査」と「修復」を分けるのが原則です。医療で言えば、原因究明のための検体を捨ててから治療を始めるようなことは避ける、という発想に近いと思います。
✅ 今夜できる、確実な一歩
長く書きましたが、全部を一度にやる必要はありません。優先度の高いものから1つずつで十分です。
今夜やるなら、これ1つ
メールアカウント（Google / Microsoft等）にパスキーを設定する。
理由は、メールが他のすべてのアカウントの復旧起点だからです。ここが最も守るべき一点で、パスキーは最も強い手段です。5分で終わります。
今週やるなら
- メールの転送設定とフィルタを確認する（侵入時に仕込まれる典型的な「裏口」です）
- 主要サービスのセッション一覧を開き、知らない端末をログアウトする
- 連携アプリ（OAuth） を棚卸しし、使っていないものを取り消す
- ブラウザ拡張機能の権限を確認し、不要なものを削除する
- パスワードマネージャーの使い回しチェックを実行する
病院・組織で考えるなら
- 院内ネットワークの構成図が最新か確認する
- バックアップがネットワークから切り離されているか確認する
- リモートメンテナンス回線の一覧と、その認証方式を把握する
- サポート終了OSを搭載した機器の所在と隔離状況を確認する
いずれも、実施にあたっては医療情報システム安全管理責任者・医療機器安全管理責任者およびベンダーとの調整が必要です。
今後、自分が学びたい分野
対策方法だけでなく、仕組みそのものを理解したいと考えています。
- 認証と認可（AuthN / AuthZ）
- OAuth 2.0 / OpenID Connect
- Passkey / WebAuthn / FIDO2
- Cookie / Session の設計
- TLS / HTTPS / 証明書の検証
- DNS とその汚染手法
- CSP / XSS / CSRF
- SQL Injection
- Secrets Management
- IAM / Zero Trust
- Software Supply Chain / SBOM
- Incident Response
- Backup / Recovery
特にAIエンジニアとして、生成AIにコードを書いてもらうだけではなく、
- 「このコードは安全なのか」
- 「このAPI Keyの管理方法は適切なのか」
- 「この権限は本当に必要なのか」
まで考えられるようになることが重要だと感じています。
まとめ
セキュリティは、一度設定して終わるものではありません。
新しいサービスを使い、新しいAIツールを使い、新しいクラウドを使うたびに、自分の攻撃面も少しずつ広がります。
そして今回、病院ネットワークと個人のアカウント管理を並べて整理してみて、共通する原則が見えました。
- 1つ漏れても、他には入れない
- 1台壊れても、復旧できる
- 1つのKeyが漏れても、権限が限定されている
- 不審なアクセスを、早く発見できる
- すぐにセッションを無効化できる
病院という、更新できない機器を止められないまま守り続けなければならない環境は、制約が厳しいからこそ「分離」と「限定」の設計が徹底されてきた分野です。その考え方は、クラウドやAIを使う一般の開発環境にもそのまま応用できます。
便利さと同時に、守り方も学ぶ。
生成AIについて学ぶのと同じように、セキュリティについても継続的に学び、実際の開発や業務改善へ活かしていきます。
⚠️ 最後にもう一度
この記事は筆者の現時点での個人的見解であり、法的助言ではありません。また、特定の製品・構成を推奨するものでもありません。
院内ネットワークやシステムの設計・変更は、患者安全に直結します。実施にあたっては必ず、医療情報システム安全管理責任者、医療機器安全管理責任者、システムベンダー、および必要に応じて所管行政機関と相談したうえで判断してください。
本記事に誤りを見つけられた場合は、ご指摘いただけると助かります。
出典・参考資料
| 資料 | URL |
|---|---|
| 医療情報システムの安全管理に関するガイドライン 第6.0版（厚生労働省） | https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html |
| 医療機器プログラム（SaMD）の審査ポイント／IEC 81001-5-1解説（PMDA） | https://www.pmda.go.jp/files/000250907.pdf |
| JAHIS 医療情報システムの患者安全に関するリスクマネジメントガイド＜解説編＞Ver.2.0 | https://www.jahis.jp/standard/detail/id=746 |
| 医療法（e-Gov法令検索） | https://elaws.e-gov.go.jp/document?lawid=323AC0000000205 |
| 薬機法（e-Gov法令検索） | https://elaws.e-gov.go.jp/document?lawid=335AC0000000145 |
| 個人情報保護法（e-Gov法令検索） | https://elaws.e-gov.go.jp/document?lawid=415AC0000000057 |
※ IEC 80001-1:2010 "Application of risk management for IT-networks incorporating medical devices"、IEC 81001-5-1:2021、JIS T 2304:2017 については、規格本文は有償頒布のため、本記事では上記の公的解説資料に基づいて記述しています。
著者プロフィール
臨床工学技士 × AIエンジニア / 11年間、病院の医療機器の現場に立ち続けてきました。
いまはAIエンジニアとしても活動しながら、酪農学園大学の研究生として論文博士の取得を目指しています。研究テーマの主軸は遺伝子医療の未来。そのうえで、医療現場と地続きにある病院のIT・サイバーセキュリティ・医療AI導入についても、現場で起きている課題と一次情報を突き合わせながら調べ続けています。
質問・誤りの指摘・「うちの病院ではこうしている」という事例の共有、いつでも歓迎します。
- X：@endoh_taichi
- Qiita：@TaichiEndoh