役員も知らなかった連携アプリ150件。承認制は情シスが一人で決めない

ある会社（約90名）で Google Workspace の点検をしていて、社員が許可した連携アプリを書き出した。150 件あった。その中に、名前が「無題のプロジェクト」の Apps Script が 7 件あった。1 件はメール全体、2 件はドライブ全体に触れる。

一番簡単なのは、正体の分からないものを全部止めることだ。だが、すぐには止めなかった。止めた日にどこかの業務の自動処理が止まっても、止めた側の情シスからは、どこが止まったのか見えないからだ。

代わりに、一覧を「埋めれば判断になる表」にした。そして、承認制へ切り替える段取りを社内の情報セキュリティ委員会に出した。進め方は了承された。細かいところは毎週の定例で詰める。出してみて分かったのは、役員やセキュリティ委員会のメンバーでも、連携アプリまわりは把握していなかったことだ。この記事は、止める前、切り替える前の記録だ。

筋は 1 つ。止める前に、誰が困るかを確かめ、誰が決めるかを分ける。

▼150 件は、利用者の数ではなく「触れるデータの範囲」で分けた

承認制にするのは、管理コンソールの「セキュリティ」→「アクセスとデータ管理」→「API の制御」→「サードパーティ製アプリのアクセスを管理」にある「未設定のサードパーティ製アプリ」の設定だ。Google のヘルプの設定ページでは、既定は「許可する」だ。この会社でも 150 件がつながっていた。社員が自分の判断で、外部のアプリにメールやドライブを渡せる状態だった（今の設定値そのものは、画面でまだ確かめていない）。今回の承認制は、業務で使うアプリを先に許可リストに入れ、それ以外は「Google でログイン」の基本情報だけに絞る形にする。設定の作り方と通知の実装は、前に書いた記事に任せる。

書き出しは ID 単位で 150 件、名前で数えると 124 種類だった。同じ名前のアプリが、別の ID で複数あるからだ。件数を人に報告するときは、数え方を添えた方がいい。

アプリ名や利用者数で並べても、判断はできない。見るのは「会社のどのデータに触れるか（スコープ）」だ。そう分けると、1 件ずつ確かめるのは A の 35 件で済む。全体の 4 分の 1 弱だ。

区分	件数	扱い
A. メール・ドライブ全体・管理情報に触れる	35	1 件ずつ用途を確かめ、業務のものだけ許可リストへ
B. カレンダー・スプレッドシートなど一部	21	業務なら許可。社内の Apps Script は持ち主を確かめる
C. サインインだけ（データに触れない）	89	当面そのまま。終了したサービス・個人向けは外す候補
Google 製・OS 標準	5	この制御の対象外

分けてみて、判断の軸が 3 つはっきりした。

• ▶ 人数が多い＝安全、ではない。数十人が使う Notion のドライブ連携は「ドライブ全体の読み取り」を持っていた。業務で使っているので止めない。ただ、ドライブ全体が読めることは、承認する側に共有しておく
• ▶ 1 人だけのアプリほど危ないことがある。利用者 1 名で、メールの転送設定の変更まで含む、ほぼ全部の権限を持つ正体不明のアプリがあった。人数で並べると、一覧の一番下に沈む
• ▶ C は後回しでいい。データには触れない。ただし、会社のアカウントで外部サービスに登録している状態なので、退職時の棚卸しの対象にはなる

▼作成者の分からない Apps Script 7 件は、止める前に「誰が困るか」を確かめる

7 件の名前は、どれも「無題のプロジェクト」。内訳はメール全体が 1 件、ドライブ全体が 2 件、スプレッドシート全体が 4 件。許可した人は、それぞれ 1 名だ。

一覧には、あえて人数しか載せなかった。許可した人は、管理側でトークンを引けば分かる。だが、誰が何のために作ったのかは、どこにも書いていない。管理コンソールから Apps Script の作成者をたどる方法も、Google のヘルプには見当たらなかった。

同じ一覧には、名前の付いた社内の Apps Script も並んでいた。問い合わせのメールをスプレッドシートに取り込むもの、契約の期限を知らせるもの、などだ。この会社では、Apps Script が業務を回している。だから無題の 7 件も「ゴミ」とは決めつけられない。

• ▶ 許可した人が 1 名だけの無題のスクリプトは、本人が作った可能性が高い。止める前に本人に聞くのが一番早い
• ▶ 誰に聞くかも、情シスが一人で決めない。資料には、利用者は自分が管理画面で調べて本人に直接聞く、名前は出さない、と書いた。そのうえで、開発部門の場で聞いてよいかも委員会に尋ねた。委員会では「会社と個人の Google アカウントを切り替えて使う人が多い。個人のつもりで会社のアカウントにつないだものもありうる」という声が出た。結果、誰が何をつないでいるかを見る人は絞り、本人への確認は自分だけでやることになった

作れる人に依存した社内ツールの話は、AI で社内ツールが乱立しはじめた会社の記事でも書いた。無題のスクリプトは、その行き着く先の 1 つだ。

▼一覧は「埋めれば判断になる表」にした

棚卸しの一覧は、読ませるためではなく、埋めてもらうために作る。列の作り方で、受け取った側の作業が「判断」になるか「感想」で終わるかが決まる。

シートは 4 枚にした。説明、先に確認（優先して確かめたい 12 行）、全件、集計だ。「全件」の列は、優先、区分、アプリ、人数、触れる範囲、見立て・案、確認結果、判断、クライアント ID、スコープ（原文）の 10 列だ。「先に確認」のシートには「確認先」と「確認結果」の列を置いた。止めたら誰が困るかを埋める欄だ。列ごとに、置いた理由がある。

列の作り方	理由
「判断」はプルダウンで 3 択（許可／外す／確認中）	「確認中」があれば、分からないものを無理に決めなくていい。空欄より、次に誰が動くかが見える
最初から「案」を書いておく	白紙で「どうしますか」と聞くと止まる。情シスの見立てを書き、違えば直してもらう
クライアント ID の列を入れておく	「許可」と決まった行が、そのまま管理コンソールの許可リスト登録の作業表になる
許可した人の名前は載せない（人数だけ）	目的はアプリの判断で、誰がつないだかの犯人探しではない。一覧は多くの人の目に触れる

▼承認制は、影響の出ない準備と、影響の出る切り替えを分ける

承認制への切り替えは、設定 1 つで済む。だが、許可リストに登録漏れがあれば、その日に業務アプリが使えなくなる。だから順番を分けた。社員に影響しない準備を先に全部済ませる。影響の出る作業は、了承と本人の確認を取ってからやる。切り替えは、情シスの部門で試してから全社に広げる。

承認制にすると、社員から見て何が変わるか

• ▶ 許可リストのアプリは、今までどおり使える
• ▶ 許可リストにないアプリは、「Google でログイン」（サインインだけ）なら使える。メール・ドライブ・カレンダーに触れるものは使えない
• ▶ 使いたいアプリは、Google の画面から申請できる。申請は管理コンソールの「審査待ちのアプリ」に入る

進め方

段階	内容	社員への影響	いつやるか
決める	方針・承認する人・判断基準を委員会で決める	なし	最初
準備	先に確認したいアプリの正体を確かめる／業務アプリを許可リストへ／申請の通知を作って試す	なし	了承を待たずに進めてよい（2 週間ほど）
外す	不要と分かった接続を外す	外す接続の持ち主だけ。個別に連絡	了承の後、本人に確かめてから
周知	何が変わるか、申請のしかた、問い合わせ先	お知らせのみ	切り替えの 1 週間以上前
切り替え	情シスの部門だけで試す → 全社へ	許可リスト外でメール・ドライブを使っていた人は、申請が要る	了承の後
運用	申請への対応、月 1 回の見直し、退職時の確認	申請した人は承認まで待つ	切り替えの後
強い制限	Gmail・ドライブを、許可リストのアプリだけに絞る	許可リストにない既存の接続が切れる。やるなら改めて周知	切り替えから 1 か月後に、委員会で改めて判断

この表の判断の軸は 4 つだ。

• ▶ 準備は了承を待たない。正体を確かめる、許可リストに入れる、通知を試す。どれも社員から見て何も変わらない。待つ理由がない。設定そのものを変えるのは、了承の後だ。外すのも準備に混ぜない。外せば、その接続の持ち主には影響が出る
• ▶ 強い制限を、最初の切り替えに混ぜない。Google のヘルプには、Gmail やドライブを「制限付き」にすると、信頼していないアプリのトークンが取り消される、とある。最初の切り替えより影響が大きい。最初の 1 か月の申請の出方を見てから決める
• ▶ 切り替えの週に、別の設定変更を重ねない。同じ時期に、別のアクセス制限の展開も予定している。資料には、その展開とは週を分けると書いた。何かが使えなくなったとき、原因を 1 つに絞れるようにするためだ
• ▶ 情シスの部門で試してから広げる。許可リストの登録漏れは、情シス自身が先に踏む

周知を出すのは情シスではなく、社員が普段お知らせを受け取る人（役員や、社員の問い合わせの窓口の人）にする案にした。文案は情シスが書く。同じ内容でも、知らない人から来たお知らせは読まれない。

Google の仕様で詰まるところ

• ▶ 申請は「審査待ち」に溜まるだけ。Google のヘルプには、申請を管理者に知らせる仕組みの記載がない。管理コンソールのアクティビティ ルール（旧レポートルール）で拾えるかは、まだ試していない。届く前提では切り替えない。だから通知の仕組みを準備の段で作り、アクティビティ ルールで拾えるかも、そこで一緒に試す。作り方は前の記事のとおりだ
• ▶ 承認は、申請した本人ではなく組織部門の全員に効く。部門の分け方が粗いと、1 人に許可したものが部門の全員に許可される。Microsoft 365 で「管理者が同意するとテナント全員に効く」のと同じ構造だ（ChatGPT の M365 連携を絞った記事）
• ▶ 設定の反映に最長 24 時間ほどかかる。切り替えの日は、「まだ使える人」と「もう使えない人」が混ざる。問い合わせの窓口は、その前提で構える
• ▶ 「Google でログインだけ許可」に変えたとき、許可済みの未登録アプリの接続がすぐ切れるかは、ヘルプに書いていない。未検証だ。情シスの部門で試すときに確かめる

▼情シスが一人で決めないこと

承認制を情シスが一人で決めると、社員から見れば「情シスが勝手に止めた」になる。情シスが決めていいものと、決めてはいけないものを先に分けた。決めてはいけないものは、委員会に渡した。

承認の判断基準：情シスが決めるもの・決めないもの

区分	例	誰が決めるか
承認する	業務で使う、提供元がはっきりしている、触れる範囲が用途に見合う	情シス
承認しない	個人の用途、終了したサービス、提供元が分からない	情シスが判断し、申請者に理由を返す
相談して決める	メール・ドライブ全体に触れるもの、AI ツール、顧客のデータを扱うもの	情報セキュリティの責任者に相談。AI ツールは会社の AI 利用のルールに沿う

• ▶ 一番使う基準は「触れる範囲が用途に見合うか」。カレンダーを見たいだけのアプリがドライブ全体を求めていたら、承認しない
• ▶ 回答の目安は 2〜3 営業日と書いた。外部の情シスとして、即時の対応は約束できない。約束できないことは、最初から書いておく
• ▶ AI ツールは情シスの判断から外した。この会社では、新しい AI を使うときは届け出が要る。連携アプリの承認も、それに合わせる
• ▶ 申請を AI に分析させる部品は、今回は入れない。前の記事では Claude に申請の中身を読ませた。今回は通知だけで始め、AI に読ませるかは届け出のルールに沿って別に決める

委員会に出した 6 つ

1. 進め方：準備 → 周知 → 切り替え、強い制限は 1 か月後に判断、でよいか
2. 承認する人：一次判断は情シス、相談先は責任者でよいか。承認は部門の全員に効くので、誰が承認するかは軽くない
3. 切り替えの時期：繁忙期と重なる部署がないか
4. AI ツールの扱い：サインインだけの利用も、データに触れる連携もある。AI の届け出のルールとどう合わせるか
5. 確認先：正体の分からないアプリを、誰に聞けばよいか
6. 通知の仕組みの持ち主：下に書く

通知の仕組みを、自分の持ち物にしない

一覧には、自分が点検のために動かしたスクリプトも載っていた。名前を付けていたから、自分のだと分かった。表には「点検後に削除する」と書いた。

自分がいなくなれば、これも「誰のか分からないスクリプト」の 1 つになる。通知の仕組みを自分の持ち物にすれば、冒頭の 7 件と同じものを、自分で作ることになる。自分の管理者アカウントで動かせば、契約が切れた日に止まる。

だから、動かすアカウント（情シス用のアカウントなど）、置き場所（共有ドライブ）、通知先のチャンネルを、会社の持ち物として決めてもらうことにした。動かすアカウントの権限は、レポートを見るだけに絞るつもりだ。

▼委員会の結果と、経営側が知らないという穴

委員会では、提案した進め方で進めることになった。承認する人、切り替えの時期、通知の仕組みの持ち主など細かいところは、毎週の定例で責任者と詰める。本人が気づかないまま使っている接続をどう扱うかは、課題として残った。

委員会に出して一番感じたのは、冒頭に書いたことだ。役員やセキュリティ委員会のメンバーでも、連携アプリまわりは把握していなかった。経営側が知らないこと自体が、けっこう大きな穴だ。

連携アプリは、社員が自分の判断でつなぐ。既定のままなら、誰の承認も通らない。管理コンソールを開かない限り、誰の目にも入らない。だから情シスの仕事は、一人で止めることでも、一人で許すことでもない。一覧と判断の材料を、決める立場の人の前に出すことだ。承認制は、そのための入口だ。

▼まだ分からないことと、次にやること

まだ分からないこと	次にやること
・今の「未設定のサードパーティ製アプリ」の設定値（画面ではまだ確かめていない） ・強い制限（Gmail・ドライブを「制限付き」）が今のプランで使えるか。ヘルプに記載がない ・「Google でログインだけ許可」に変えたとき、既存の接続がどうなるか ・申請をアクティビティ ルールで管理者に通知できるか ・7 件の作り手と用途	・7 件を含む「先に確認したいアプリ」を本人に確かめる ・業務アプリを許可リストに登録する ・通知の仕組みを会社のアカウントで作り、試す ・届け出のない AI ツールの接続を一覧から洗い出す ・周知 → 情シスの部門で試す → 全社に広げる

切り替えの結果は、この記事に追記する。

▼まとめ

• ▶ 連携アプリは、利用者の数ではなく、触れるデータの範囲で分ける。1 件ずつ見るのは全体の 4 分の 1 弱
• ▶ 作成者の分からない Apps Script は、誰が困るかを本人に確かめてから外す
• ▶ 一覧は「判断」の列を 3 択にし、案とクライアント ID を最初から入れる
• ▶ 影響の出ない準備を先に済ませ、外すのは確かめてから、切り替えは情シスの部門で試してから。強い制限は混ぜない
• ▶ 進め方・承認する人・時期・仕組みの持ち主は、情シスが一人で決めない。一覧を経営側の前に出すこと自体に意味がある