【組織のAI活用#240】GASで作ったAIツールを社外に公開する前に。押さえておくべき3つのリスクと、整えるべき社内フロー
こんにちは!寺田です。
現在は、デジタル関連会社のAI推進者などのAI活用者のコミュニティである「AI Digital Community (ADC)」の代表理事や、顧客事業の「×AI化」をサポートするFURIKAKE Partners(株)と組織のAI活用を支援するプロダクトを提供するAI Portalize(株)の代表取締役を務めており、様々な側面から組織のAI活用をサポートしています!
このnoteでは、AI活用について毎週3〜5本ほど記事を書いています。実際に自分で試したことや経験をもとに書いています。
フォローしておいていただくと、新しい記事を受け取りやすくなります!
今回は「GASで作った自作ツールを社外に公開するときのリスク」というテーマで、会社としてどんな体制を作っておくべきかを整理してまとめてみました。
AIを活用してツールを作るなら、まずはGAS(Google Apps Script)で作って社内に展開するのがおすすめです。社内の業務効率化において、AIとGASの相性は抜群だと思います。
AIの進化により、エンジニアでなくても「こんな機能が欲しい」とプロンプトを打ち込むだけで、あっという間に実用的なコードが生成されるようになりました。
そして社内で便利に使っていると、こんな声が上がり始めます。「これ、取引先や社外の人にも使ってもらったら便利じゃない?」
社外に広げる発想自体は、とても有益です
この発想自体は、とても有益なものだと思っています。
社外とのやり取りにまで広げていく考え方は、今後の業務のあり方を確実に前に進めていくものですし、こうした発想によってAI活用はどんどん推進されていくはずです。
ただ、社外で使うとなると、社内で使う場合と比べてセキュリティ上のリスクが大きく増えます。だからこそ、そのあたりはあらかじめ押さえたうえで進めたいところです。
この記事では、GASで作った自作ツールを社外公開する前に知っておきたいリスクと、それをふまえて会社としてどのような体制を作っていけばよいのかを解説します。
AI×GASツールを社外公開する「3つの重大リスク」
AIを使ってサクッと作ったアプリケーションを外部に公開する場合、次のようなリスクが立ちはだかります。
1. 「作成者本人」の権限で動くため、情報漏洩のリスクがある
GASは基本的に「作成者(オーナー)の権限」で実行されます。
もし公開したツールに脆弱性があった場合、悪意のあるユーザーによって、そのツールを作成した従業員がアクセスできる会社のGoogle Workspace内の情報に手が届いてしまう可能性があります。
必ず起こることではありません。ですが、「一従業員が作ったツールが、会社の機密データへの入口になり得る」という構造そのものは知っておく必要があります。
2. 「AI任せのコード」の脆弱性は、体制で対処する
プロのエンジニアがセキュリティを担保して構築したシステムと違い、サクッと作ったGASアプリは脆弱性のチェックが行われていないことがほとんどです。
特に、AIにコードを書かせて中身を完全に理解していない状態(いわゆるバイブコーディング)の場合、意図せず脆弱なライブラリを使用していることがあります。後日その仕組みに脆弱性が発見されても、作った本人が構造を把握していないため、情報をキャッチアップできず、対処もできないという状況に陥りがちです。
大切なのは、作った本人だけに任せないことです。脆弱性の確認と、問題が見つかったときに対処できる構造をあらかじめ用意しておく必要があります。
具体的には、社外に出す前に情報システム部門など社内の専門的な知見を持つ人が内容を確認するフローを設けること、そして公開後も管理権限の設定や作ったものの棚卸しを継続的に行うことです。この体制があってはじめて、「中身を完全には理解していないコード」を安全に運用できます。
3. SLA対象外なので、障害時の「説明責任」が果たせない
GASは本格的なクラウドサービスとは異なり、SLA(サービス品質保証)の対象外です。
万が一システムがダウンした際、確実な復旧手段が担保されておらず、社外のクライアントに対して「なぜ止まったのか」「いつ復旧するのか」という説明責任が果たせなくなります。社外向けのサービスとして、これは致命的だと思います。
事故を防ぐための「社内確認フロー」を作る
AIの恩恵で「誰でも簡単にツールが作れる」ようになったからこそ、「作れること」と「社外へ安全に運用・提供できること」は全く別物であるという認識を強く持つ必要があります。
社外と連携するツールを作りたい場合は、属人的な公開を防ぐために、次のような社内フローや体制を必ず構築してください。
1. 必ず「情報システム部門」の許可を取るフローにする
一担当者や一部署の判断で外部公開するのは避けてください。
そもそも会社として、GASなどの簡易ツールの外部公開を許容しているのか。公開する場合のセキュリティ基準はどうなっているのか。必ず情シスなどの関連部門に確認し、連携を取るルールを設けましょう。
2. 管理体制と権限の「棚卸し」を徹底する
公開を許可する場合でも、次のような管理台帳を作成し、運用する体制が必要です。
明確にツールの「管理者」を立てる
「どこの誰に」「どのアプリを」「どんな権限で」公開しているかを一元管理する
定期的に棚卸しを行い、不要になった権限はすぐに削除する
代替案として、社外とのやり取りはGoogleフォームを使う
お客さまに何かを入力してもらい、その情報をもとに処理をしたい場合は、Googleフォームを使うのがおすすめです。
外部の人が直接触れるのはGoogleフォームだけになるので、GASのWebアプリをそのまま外部公開するリスクを避けられます。
また、フォームの内容についてGASと連携させて裏側で調整することもできます。フォームで受け取ったデータをGASで自動処理する、フォームの選択肢をGAS側で更新しておく、といった使い方であれば、社外の人が触る画面は安全なサービスに任せたまま、やりたい業務効率化を実現できます。
社内で使い倒し、社外に出すときは会社として通す
AIを活用すれば、圧倒的なスピードで業務ツールが生み出せる素晴らしい時代です。ですが、それが「社外」に触れるものになった瞬間、セキュリティや運用のハードルは一気に上がります。
便利なAI×GASツールは、まずは社内限定で使い倒す。もし社外に展開する場合は、しっかりとした社内フローを通し、適切なガバナンスを効かせる。
ぜひ、この一線を会社全体で守りながら、安全で効果的なAI活用を進めていただければなと思います!
読んでいただきありがとうございました!
過去のAI関連記事はこちらです!
ちなみに、組織におけるAIの推進についてまとめた本も出版させていただいております。もしよければご覧ください。
<自己紹介>
直近までは、電通グループに属する約1400人・20社以上の事業会社群で構成されるCARTA HOLDINGSにて、全社横断のAI推進室で組織全体のAI活用推進を担いつつ、法人向けの「生成AI&デジマ人材」研修サービスであるD-Marketing Academyの代表取締役も兼務し、大手企業からスタートアップまで、数百社にわたるAI人材育成を支援してきました。
現在は、デジタル関連会社のAI推進や担当コミュニティである「AI Digital Community (ADC)」の代表理事や、顧客事業の「×AI化」をサポートするFURIKAKE Partners(株)と組織のAI活用を支援するプロダクトを提供するAI Portalize(株)の代表取締役を務めており、様々な側面から組織のAI活用をサポートしています!
<略歴>
2005年 5月 大学在学時にEC事業を開始
2007年 5月 (株)サイバーエージェントに入社し新規事業の立ち上げに携わる
2011年 10月 (株)VOYAGE GROUPにてKDDIとの協業事業を行う(株)Flesselを設立し代表取締役に就任
2015年 11月 ECコンサルティング事業を行う(株)JSコンサルティングの代表取締役へ就任
2018年 4月 東証一部プライム企業Hamee(株)にJSコンサルティングをM&Aし、代表取締役を継続
2019年 5月 Hamee(株)の執行役員に就任し、Hameeグループの新規事業領域を管轄
2021年 2月 D2C支援を行うTHE CHOSEN ONE(株)の顧問に就任
2021年 3月 アパレルD2C事業を行う(株)NAAFYの取締役に就任
2021年 4月 D-Marketing Academy(株)を設立し代表取締役に就任
2023年 1月 (株)CARTA HOLDINGSにD-Marketing AcademyをM&Aし、代表取締役を継続
2025年 3月 CARTA HOLDINGSグループ全体のAI活用促進を行うAI推進室を兼務開始
2026年 1月 生成AIに関しての顧問を行うFURIKAKE Partners(株)を設立し、代表取締役に就任
2026年 1月 組織の生成AIプラットフォームサービスAI Portalize(株)を設立し、代表取締役に就任
2026年 1月 デジタル関連のAI活用企業コミュニティ「AI Digital Community(ADC)」を設立し代表理事に就任
