※この記事は Zennの記事 からの転載です。
私は医療機関で事務職をしています。エンジニアではありません。
AIと一緒に、院内の業務システムを3つ作りました。どれも1週間以内で、専任の開発者としてではなく、ふだんの事務の仕事をしながらです。
| システム | 中身 | 開発期間 | 状態 |
|---|---|---|---|
| 制服の申請 | 以前は Google フォームで集めていた申請を、職員がスマートフォンから申請し、発注数と配布リストまで自動で作る仕組みにした（GAS＋スプレッドシート） | 1週間以内 | 稼働中 |
| 受付の伝票 | 外来の受付機で、対象の患者さんにだけ専用の伝票を自動で印刷する（Windowsの常駐ツール） | 1週間以内 | 試験中 |
| 職員の名札QR | 名札のQRで研修会の出欠を取り、部署ごとの未参加者を集計する（GAS＋API） | 1週間以内 | 試験中 |
どれも、職員や患者さんの個人情報を扱います。そして3つとも、本物のデータを一度もAIに見せていません。
「データを見せない」と聞くと、手間が増えて遅くなりそうに思えます。実際には、業務の合間でも、それぞれ1週間以内に作り切れました。
「AIを使いたいけど、個人情報があるから無理」と思っている人に向けて、そのためにやったことを書きます。
決まり1：本番のデータは、AIの届く場所に置かない
いちばん単純で、いちばん効く決まりです。
- 本番の名簿・患者番号のファイルは、院内のパソコンと共有フォルダだけに置く
- AIが作業するフォルダ、クラウド、AIがつながる場所には置かない
AIに「見せないように気をつける」のではなく、物理的に届かないようにします。気をつけるだけの決まりは、忙しい日に破られます。
決まり2：ダミーの職員は「組み合わせごとに1人」
本物を見せないなら、テストはダミーで行います。ここで工夫したのが、ダミーの作り方です。
制服の支給は、職種・部署・性別・年度で中身が変わります。介護とリハビリは毎年3着、看護は隔年、シューズは部署と性別で選べるものが違う、という具合です。
そこで、テスト用の環境に部門×部署×職種×性別の組み合わせごとに1人ずつダミーの職員を置きました。
イメージはこうです（値はすべて架空です）。
| 職員番号 | 氏名 | 部門 | 部署 | 職種 | 性別 |
|---|---|---|---|---|---|
| 900001 | 試験 太郎 | 看護部 | 病棟A | 看護師 | 男 |
| 900002 | 試験 花子 | 看護部 | 病棟A | 看護師 | 女 |
| 900003 | 試験 次郎 | 看護部 | 病棟A | 介護職 | 男 |
| 900004 | 試験 春子 | リハビリ部 | リハビリ室 | 理学療法士 | 女 |
| 900005 | 試験 三郎 | 事務部 | 総務 | 事務 | 男 |
| … | … | … | … | … | … |
1行が「この組み合わせの人には何が出るべきか」のテストケースになります。支給のルールを変えたら、全員分の申請画面を開いて、出る品目が期待どおりかを見るだけです。
- 実在の名簿を持ち込まなくても、判定ルールを全パターン試せる
- ダミーなので、AIに画面を操作させても、スクリーンショットを撮っても問題ない
担当者向けのマニュアルの画面写真も、このテスト環境でブラウザを自動操作して撮っています。画面を直したら撮り直すだけです。
決まり3：本番だけで起きる不具合は、値を伏せて症状だけ伝える
困るのは、テストでは動くのに本番だけで動かないときです。本番の値を見せたくなります。
ここは決まりとして先に決めておきました。値は伏せて、症状だけをAIに伝える。 たとえば受付の伝票では、
- 何バイト届いたか
- 最後に受け取った時刻
- 区切りの文字（改行など）が16進数で何だったか
を見れば、番号そのものがなくても「届いていない」のか「区切りが合っていない」のかを切り分けられます。そのために、番号を残さず、件数・時刻・エラーの種類だけを出す調査用の画面を最初から作りました。
決まり4：データベースそのものを、読んでも分からない形にする
制服の申請では、もう一歩進めました（現在試験中）。
- 職員の名前は、最初と最後の1文字だけを残した伏せ字で保存し、読み仮名は捨てる（読み仮名が残ると、漢字を伏せても名前が分かるため）
- 業務でフルネームが要る場面のために、名前は暗号化した値でも持つ。鍵はシートとは別の場所と、管理者の頭の中に分ける
シートの中身は、こう見えます（イメージ・値は架空です）。
| 職員番号 | 氏名（伏せ字） | 氏名（管理者用） | 氏名（本人用） |
|---|---|---|---|
| 900001 | 試〇〇郎 |
q3Vx9…（読めない文字列） |
Zp8aK…（読めない文字列） |
| 900002 | 試〇〇子 | L0bt2… |
Hw4nE… |
こうしておくと、たとえAIの接続や共有の設定ミスでシートが読まれても、見えるのは伏せ字と読めない文字列だけです。「見せない」を、運用の注意から仕組みの性質に変えたことになります。
決まり5：設計するAIと、実装するAIを分ける
私は、設計・レビュー・本番への反映を受け持つAIと、コードを書くAIを分けています。依頼は文書で受け渡します。
これが効いた場面がありました。管理画面のパスワードに「5回失敗したらロック」を付けたのですが、レビューを受け持つAIが、
ロックはログイン画面にしか付いていない。管理用の別の処理を直接呼べば、回数無制限に試せる
と指摘しました。GAS の Web アプリは、名前が _ で終わらない関数を画面から誰でも呼べます。ロックを共通の認証処理に移して塞ぎました。
書いた本人（のAI）は、自分の書いたものの穴に気づきにくいものです。人間のチームと同じでした。
決まり6：直す前に、本番そのものを読む
制服の申請は、最初に作った版を見直して作り直しました。そのとき最初にしたのは、手元の記録ではなく、本番そのものを読むことです。
読んでみると、
- 申請データに年度がなく、翌年度に申し直すと前年の記録まで取り消される
- 全データを消す関数が、画面から誰でも呼べる場所に残っている
- ファイルが個人のアカウントの持ち物になっている（退職すると引き継げない）
という問題が見つかりました。さらに、手元の記録には本番に出していない作業が混ざっていました。記録を信じて直していたら、未完成の機能を本番に混ぜるところでした。
やってみて分かったこと
- **「AIに見せない」は、気をつけることではなく、置き場所の問題。**届かない場所に置けば、気をつける必要がない
- ダミーの作り方で、テストの質が決まる。「組み合わせごとに1人」なら、少ない人数で全パターンを試せる
- **値がなくても、不具合は切り分けられる。**そのための調査画面を先に作っておく
- **レビューを分けると、自分では気づけない穴が見つかる。**AI同士でも同じ
まだ書けないこと
3つのうち、稼働しているのは制服の申請だけです。受付の伝票と名札のQRは試験中で、「どれだけ楽になったか」の数字はまだありません。稼働したら、成果を数字で追記します。
それぞれの仕組みの技術的な中身は、別の記事に分けて書いています。
- 桁の少ない番号を、ハッシュではなく HMAC で照合する話（「その患者番号、SHA-256にしても0.4秒で戻せます」）
- 業者の受付システムに手を入れずに、中継を挟んで機能を足す話（「業者のシステムは1行も触れない。それでも機能は足せる」）