Google Workspaceに含まれたGAS (Google Apps Script)は何を変えるか
森田さんの記事が投げかけている本質
森田嶺さんは、Google Apps Script (GAS )について「情報セキュリティの観点でどのような問題があったのか」を書き残す、とXで投稿しています。
この記事の重要性は、Google Apps Scriptの便利さを紹介している点ではありません。むしろ、これまで企業がGoogle Apps Scriptを警戒してきた理由を、かなり実務寄りに言語化している点にあります。
https://note.com/yoshidumi_times/n/n22120174519f?sub_rt=share_pw
Google Apps Scriptは便利です。
ただし、医療機関で語るなら「便利な自動化ツールです」で終わらせない方がいい。
何ができて、何が危なくて、どこから管理対象になるのか。
そこまで見ないと、現場では使える文章になりません。
Google Apps Scriptとは何か
Google Apps Scriptは、Google Workspace (GWS) 上の作業を自動化するための仕組みです。Googleフォーム、スプレッドシート、Gmail、Googleドライブ、Googleカレンダーなどをつなぎ、手作業で行っていた通知、転記、集計、確認、ファイル作成を自動化できます。
たとえば、
Googleフォームに回答が入ったら、その内容をスプレッドシートに整理する。
未入力の項目があれば担当者にメールを送る。
毎週月曜の朝に集計結果を管理者へ通知する。
特定の条件を満たした行だけ別シートに移す。
会議前に資料提出状況を一覧にする。
こうした処理を、Google Workspaceの中で動かせるのがGoogle Apps Scriptです。
医療機関でいえば、いきなり診断や治療判断に使うものではありません。むしろ、診療の周辺にある事務作業、確認作業、委員会運営、教育管理、点検表、提出物管理に向いています。電子カルテ本体を触る前に、院内の紙、表、メール、フォーム、通知の渋滞をほどく道具として見ると分かりやすいです。
具体的に何に使えるのか
院内研修なら、
Googleフォームで受講後アンケートを集める
スプレッドシートで未回答者を抽出する
期限前に自動でリマインドする
医療安全研修、感染対策研修、個人情報保護研修のように、毎年必ず確認が必要なものと相性がいい。手作業で名簿を見比べる時間を減らせます。
委員会運営なら、各部署から提出される資料の有無を自動で一覧化し、未提出部署に通知できます。
会議前日の時点で、提出済み、未提出、差し戻し中を色分けする。
これだけでも、事務局の追いかけ作業はかなり軽くなる。
医療安全ラウンドや感染対策ラウンドなら、
フォームで点検結果を入力する
スプレッドシートに集約する
未確認項目だけを担当者へ返す
前回から改善していない項目を抽出する
ここでは患者個人情報を入れずに、部署名、点検項目、対応状況だけで運用できます。
診療所や中小病院なら、備品管理にも使えます。
期限が近い物品
残数が少ない物品
発注済みだが未納の物品
これらをシートで管理し、条件に応じて担当者へ通知する。高価な専用システムを入れる前に、まず現場の抜け漏れを減らせる。
採用や職員対応でも使えます。
応募フォームの回答を整理する
面接日程の候補を担当者へ通知する
入職時チェックリストの未完了項目を出す
職員健診の受診状況を管理する
ただし、健康情報や人事情報を扱う場合は、権限、保存先、閲覧者を厳密に決める必要があります。
このように、Google Apps Scriptの価値は「AIを作れる」ことではありません。現場の小さな確認作業を、Google Workspaceの中で減らせることにあります。
Google Workspaceに含まれると何が変わるのか
今回、Google Apps ScriptがGoogle Workspaceのコアサービスになったことは大きな変化です。GoogleのWorkspace Updatesでは、Apps ScriptがCore Serviceになり、エンタープライズグレードのデータ保護、管理者向け制御、標準技術サポートの対象になると説明されています。
この一文だけを見ると、「それなら医療機関でも安心して使える」と読みたくなるかもしれません。
でも、ここは慎重に読む必要があります。
コアサービス化は、Google Apps Scriptで作られた全スクリプトが自動的に安全になる、という意味ではありません。正確には、Google Apps Scriptを組織の管理対象として扱いやすくなった、という変化です。
これまでGoogle Apps Scriptは、現場が便利に使える一方で、企業や医療機関の管理部門から見ると少し宙に浮いた存在でした。Googleフォームやスプレッドシートは業務基盤として認めているのに、その裏で動くGoogle Apps Scriptは、個人が作った小さな自動化として増えていく。ここにねじれがありました。
コアサービス化によって、このねじれが少し解消されます。
Google Apps Scriptを「個人の工夫」ではなく、Google Workspace上の正式な業務基盤の一部として議論しやすくなる。管理者制御、データ保護、標準サポートの対象に入ることは、医療機関の稟議ではかなり大きいです。
ただし、期待すべきなのは「Google Apps Scriptなら何でも許可できる」ではありません。期待すべきなのは、Google Apps Scriptを禁止か野放しかの二択から外し、管理された院内自動化として位置づけられることです。
過去投稿で書いた「順番」の話
ここは私も過去、言及してきました。
「患者情報をAIに渡せない。」
この一文で止まる医療機関は多い。
紹介状の下書きを外部AIに読ませるのは難しい。患者を識別できる情報を含むシートを外部サービスに送るのも慎重に扱う必要があります。
しかし、Googleフォームで受けた内容をスプレッドシートへ整え、未入力だけ担当者へ通知し、確認欄を残すことはできます。つまり、患者情報を外部AIに投げる前に、院内の転記、確認、通知を減らせる余地がある。
同じ投稿では、見るべき順番についても書きました。要点は、モデル名ではなく運用表です。どの権限で動き、どのログが残り、どの時点で人へ戻るか。ここが先にあるから、Google Apps Scriptは単なる便利ツールではなく、院内の改善基盤になります。
医療機関では「小さな自動化」も管理対象になる
厚労省の「医療情報システムの安全管理に関するガイドライン第6.0版」は、医療情報システムについて、医療機関側の管理責任、説明責任、委託先管理、責任分界、定期的な見直しを求めています。経営管理編では、医療機関等が「医療情報システムを適正に管理する責任」を負うという考え方が示されています。
この視点に立つと、Google Apps Scriptは単なる個人の便利ツールでは済みません。
患者情報や医療安全に関わる情報へ触れるなら、それは小さくても医療情報システムの一部です。フォームで入力された内容をシートに集めるだけでも、そこに患者を識別できる情報が入るなら扱いは変わる。通知先を間違えた時、外部に送信した時、担当者が異動して止められなくなった時、医療機関として説明できる設計が必要になります。
ここで大切なのは、Google Apps Scriptを禁止することではありません。
むしろ逆です。医療機関は、Google Apps Scriptのような軽量な自動化を正しく使えるようになるべきです。診療所や中小病院では、巨大なシステム改修を待っている間にも、日々の転記、確認、通知、集計が積み上がっていく。こうした周辺業務を減らせる可能性は大きい。だからこそ、最初から「便利だから使う」ではなく、「管理できる範囲で使う」に変える必要があります。
一番危ないのは外部送信が見えないこと
Google Apps Scriptの強力な機能の一つに、外部API、つまり別サービスとの接続口へリクエストを送れることがあります。
Google公式ドキュメントでも、Apps ScriptはUrlFetchを使って外部のWeb APIとやり取りできると説明されています。
これは業務自動化では非常に便利です。
チャットツールへ通知する
外部の予約管理システムへ送る
生成AIへ文章を渡して要約させる
技術的には簡単にできます。
しかし医療機関では、この「簡単にできる」がリスクになります。
スプレッドシートに患者名、相談内容、紹介元、検査予定、職員の健康情報が含まれていた場合、それを外部サービスへ送るかどうかは、現場担当者の判断だけでは決められません。送信先の契約、保存期間、学習利用の有無、削除手順、アクセスログ、委託関係、責任分界を確認する必要があります。
ここを曖昧にしたまま、Google Apps Scriptから生成AIのAPIへ投げる。これが一番危ない。Google Apps Scriptがコアサービスになったことは、外部送信先の安全性まで保証するものではありません。Google Workspace内で管理しやすくなったとしても、外へ出す判断は医療機関側に残ります。
見るべきものは画面ではなく運用表
医療機関でGoogle Apps Scriptを使うとき、完成画面だけを見てはいけません。
画面が動くか
通知が届くか
集計が速いか
そこだけ見ると、便利なものはたいてい通ってしまいます。
先に見るべきなのは運用表です。
誰が所有者か
誰が管理者か
どのデータを読むのか
どのOAuthスコープ、つまりどの権限を要求しているのか
外部送信はあるのか
どのトリガーで自動実行されるのか
エラー時に誰へ通知されるのか
担当者の異動時に誰が引き継ぐのか
不要になったら誰が止めるのか
Apps ScriptのOAuthスコープについては、Google公式ドキュメントでも、スクリプトがGoogleサービスへアクセスする権限として整理されています。制限付きスコープや機密性の高いスコープは、医療機関では特に注意して見るべきです。
この一枚がないGoogle Apps Scriptは、本番運用に入れない方がいい。
逆に、この一枚が作れる施設なら、Google Apps Scriptはかなり現実的な改善基盤になります。医療安全委員会や情報システム部門が見るべきなのは、コードの美しさよりも、責任と停止条件が書かれているかです。
AIガバナンスにも同じ構図がある
私は以前、AI導入についてこう書きました。
「製品に最初から組み込まれた既定値」
AIの価値観や安全設計は、使う側から見えにくい。
知らないうちに、ベンダーの既定値に現場判断が引きずられる。
この問題は、Google Apps Scriptにも近いものがあります。
Google Apps Scriptそのものは便利です。
Google Workspaceの中で動くことも追い風です。
しかし、実際にどの権限を持たせ、どこまで自動実行し、どの外部サービスへ送るかは、院内の設計で決まります。
ツールの既定値に任せるのではなく、医療機関側が自分たちの業務に合わせて、許可する範囲と止める条件を決める必要があります。
AI導入でもGoogle Apps Script運用でも、同じ問いに戻ります。
誰が許可し、誰が責任を持ち、後から確認できるようにするのか。
ここを言葉にしておくことが、導入の前提になります。
今後、Google WorkspaceとGoogle Apps Scriptに期待したいこと
今後期待したいのは、医療機関がGoogle Apps Scriptを院内の軽量業務システムとして扱える状態です。
管理コンソールから組織内のGoogle Apps Scriptを一覧化できる。
どのスクリプトが、どのユーザーの権限で、どのGoogleサービスにアクセスし、どのトリガーで動いているかを確認できる。
OAuthスコープ、つまりアクセス権限を管理者が見て、高リスクな権限には承認を挟める。
外部API送信がある場合は、送信先を記録し、必要なら止められる。
Google Workspaceの管理者向けドキュメントでは、アプリのアクセス制御として、
信頼できる
限定
特定のGoogleデータ
ブロック中
といったアクセス設定を扱えることが示されています。
こうした考え方がGoogle Apps Scriptの院内運用にもより深く接続されると、医療機関にとって使いやすくなります。
森田さんの記事でも、このあたりへの期待が書かれています。特に医療機関では、DLP（情報の持ち出しを防ぐ仕組み）やアクセス制御と連動し、患者情報や機密情報を含むシートから外部送信しようとした時に警告またはブロックできると、実務上かなり意味があります。
ここまで進むと、Google Apps Scriptは「野良スクリプト」ではなくなります。院内の小さな改善を、安全管理の枠内で動かす基盤になる。
AI導入の前にGoogle Apps Scriptを棚卸しする
医療機関のAI導入では、よく「患者情報をAIに渡せない」という話になります。これは正しい懸念です。ただ、その前に見るべきものがあります。院内のGoogle Workspace上で、すでに誰が、どの情報を、どの権限で、自動処理しているのか。ここが見えていない状態で、生成AIだけを安全に使うのは難しい。
私は別の投稿では、AI導入についてこう書きました。
「失敗タスクの在庫表を持っている施設」
この考え方は、Google Apps Scriptにもそのまま使えます。
院内にある自動化を一覧化し、どこで失敗しやすいかを残す。
通知漏れ、権限不足、外部送信、担当者不在、エラー時の見落とし。
こうした失敗パターンを在庫として持っている施設は、次の改善が速い。
Google Apps Scriptは、AI導入前の組織能力を測る良い入口になります。
院内にあるGoogle Apps Scriptを一覧化する。
所有者、対象データ、権限、外部送信、トリガー、通知先、停止手順を書く。
空欄があるものは本番運用にしない。
患者情報に触れるものは個別審査へ回す。
外部API送信があるものは、契約と送信内容を確認する。
これは地味です。でも、この地味な棚卸しができる組織は、AI導入でも強い。なぜなら、AI導入で本当に問われるのはモデル名ではなく、データ、権限、ログ、責任、人間の確認点だからです。
「外来が止まる」を防ぐために
私は以前、医療AIガバナンスについてこう書きました。
「AIを入れたら外来が止まった」を防ぐ。
これは大げさな話ではありません。
医療機関では、便利な仕組みほど業務の奥に入り込みます。
最初は委員会資料の提出管理だったものが、やがて毎月の報告、部署間の確認、外部委託先とのやり取りに広がる。
止まった時に誰も仕組みを知らないと、現場はその日から困ります。
Google Apps Scriptも同じです。
軽いからこそ入りやすい。入りやすいからこそ、管理されないまま深く入る。だから本番利用の前に、止め方と戻し方を決める必要があります。
Google Apps Scriptは「AI以前」の改善基盤になる
医療機関にとって、Google Apps Scriptの価値は「非エンジニアでもコードが書ける」ことだけではありません。
もっと大きいのは、AIを使う前の業務改善を、院内の管理下で進められることです。
たとえば、
Googleフォームで受けた院内研修の回答をスプレッドシートに整える
未提出者を自動で抽出する
担当者に通知する
確認済みフラグを残す
月末に委員会資料へ転記する
ここには患者情報を外部AIへ渡す工程を入れなくていい。それでも、紙、電話、手作業の追いかけは減らせます。
この層を改善できるだけで、医療機関の負担はかなり変わる。現場は、いきなりAI診断支援に飛ばなくていい。まずは、転記、通知、確認、集計を減らす。そこにGoogle Apps Scriptの現実解があります。
結論 ー 最初に作るのはスクリプトではなく一覧表
Google Apps Scriptのコアサービス化は、医療機関にとって追い風です。
ただし、それは「自由に使ってよい」という追い風ではありません。管理して使う準備が整いやすくなったという追い風です。
最初に作るべきものは、新しいスクリプトではありません。
院内にあるGoogle Apps Scriptの一覧表です。
誰の権限で動き、どのデータに触れ、どこへ送信し、どのログが残り、どの時点で人へ戻るのか。
その表を作る。
ここから始める施設は、Google Apps Scriptを単なる便利ツールで終わらせない。AI導入の前に、院内の小さな自動化を管理できる組織になる。医療機関のAI導入は、モデル選びより前に、こういう地味な一枚で決まります。
さらに詳しく学びたい方には、noteで「情シスがいないクリニックで安全にAIを試す手順」や「そのまま使えるプロンプト例」をまとめていきます。
本記事で綴った「AIに臨床の魂を宿す」という想いは、単なる考えの提案にとどまりません。具体的な「臨床現場への実装」へと段階を移しました。 記事を読むだけでなく、実際に手を動かすための環境も公開しています。安全なガバナンスの下で、臨床知を形式知・資産へと変えていくための実践的環境（Cursorvers Library）です。 その理念に共鳴し、評論家ではなく「実践者」として医療の未来を作りたい方は、是非メンバーシップ（無料・有料）への加入をご検討ください。 （もし不具合があれば、お問い合わせフォームからご連絡ください。）
▼ Cursorvers Program Roadmap
「医療✕AI」に関するビジネス発信はSubstackから行っております。是非ご登録お願いします。