「社内の数人が見るだけの画面なので、簡単に作れますよね」と相談を受けて、見積りを出すと驚かれることがあります。画面自体は数日でも、ログイン、パスワード再発行、権限の付け外し、退職者の削除まで含めると、工数の相当部分が認証に持っていかれるからです。
しかも厄介なのは、完成した後です。誰かが辞めるたびに、担当者はそのツールを思い出してアカウントを消しに行かなければなりません。忘れられたアカウントは、たいてい何年も残ります。
すでに Google Workspace を全社で使っているなら、この部分は作らずに済ませられます。
「認証機能を持たないアプリ」という選択肢
考え方は単純で、アプリの手前に認証の関所を置き、通過した人だけをアプリに届けます。アプリ側にはログイン画面もパスワード保管も存在しません。
Google Cloud であれば、Identity-Aware Proxy（IAP）が Cloud Run に直接統合できるようになり、ロードバランサや固定 IP、SSL 証明書を用意しなくても社内限定公開ができます。アクセスを許可する対象に自社の Google Workspace ドメインやグループを指定すれば、在籍している社員だけが入れる状態になります。
この構成で消えるのは、実装だけではありません。
- パスワードの保管・ハッシュ化・再発行フローが存在しない（漏れる対象がない）
- 二要素認証は Workspace 側の設定がそのまま効く
- 退職手続きで Workspace のアカウントを止めれば、全ツールから同時に締め出される
- 「誰がこのツールに入れるのか」の答えが、Google グループの一覧に集約される
最後の点が、運用ではいちばん効きます。ツールごとにユーザー表が散らばっている状態と、グループを見れば分かる状態とでは、棚卸しにかかる時間が桁で違います。SaaS のログイン管理を Google Workspace の ID 基盤に一元化するのと同じ発想を、自社で作るツールにも適用する形です。
詰まるのは、人ではないアクセス
実装で必ず引っかかるのがここです。関所を置いた瞬間、人以外からのアクセスが全部落ちます。
具体的には、次のようなものが動かなくなります。
- CI から叩いていたデプロイ後の疎通確認
- 監視サービスからのヘルスチェック
- 別の社内システムからの API 呼び出し
- 最近はこれが増えました — AI エージェントに操作させたい API
「ブラウザで開けるのに curl だと弾かれる」という症状で持ち込まれる相談は、ほぼこの構図です。関所は Google アカウントでのログインを求めるので、対話的にログインできない相手は通れません。
通し方は、相手が何かで決まります。
| アクセス元 | 通し方 |
|---|---|
| 社員（ブラウザ） | Workspace アカウントでログイン。グループで許可範囲を管理 |
| CI・監視・他システム | 専用のサービスアカウントを発行し、ID トークンを付けて呼ぶ |
| AI エージェント | 人と同じ権限を借りず、専用の識別子を割り当てて範囲を絞る |
押さえておきたいのは、機械用の口を「認証なしの抜け道」にしないことです。 「CI からは通したいので、この URL だけ認証を外す」という対処をした結果、その URL が社外から叩ける状態になっていた例は珍しくありません。機械には機械の身元を持たせて、通す。原則はこれだけです。
サービスアカウントの鍵ファイルを CI に置く方式も動きますが、鍵は流出したら終わりで、ローテーションも忘れられます。 GitHub Actions からのデプロイであれば、Workload Identity Federation で長期の鍵を持たずに認証する構成にしておくほうが、後の運用が楽です。
監査ログの見え方も変わる
セキュリティ担当がいる会社では、ここが評価されます。アプリごとにログイン履歴を持っている状態では、「先月このツールに誰が入ったか」を調べるのに、ツールの数だけ調査先が増えます。
関所方式では、アクセスの記録が Google Cloud 側に集約されます。どのアカウントが、いつ、どのアプリに入ったか。これが同じ形式で残るため、棚卸しの手順が1つにまとまります。「調べられる状態にしておく」ことは、平時には価値が見えませんが、何かが起きた日に効きます。
自社で作った小さなツールほど、この部分が省略されがちです。ログイン履歴を持たないツールは、後から「誰が見ていたのか」を答えられません。
寄せられないケースを先に切り分ける
この構成が向かない相手もあります。設計に入る前に確認しておくと、途中でやり直しになりません。
社外の人が使う場合です。取引先や顧客に見せるツールでは、相手が Google アカウントを持っているとは限りません。ゲストとして招く方法もありますが、相手企業のポリシー次第で使えないこともあります。ここは素直に別の認証を用意する判断になります。
モバイルアプリや外部サービスからの常時連携が主目的の場合も、関所方式は相性が良くありません。ブラウザ前提の仕組みなので、無理に寄せると回避策だらけになります。
逆に言えば、「社内の人だけが、ブラウザから見る」ツールであれば、ほぼ寄せられます。 社内ダッシュボード、集計結果の共有ページ、管理用の簡易画面。この種のツールは、社内に想像以上の数が眠っています。
発注する側が確認する一行
外部に開発を頼む場合、仕様書に次の一行を入れておくだけで、見積りも設計も変わります。
認証は Google Workspace のアカウントに寄せ、アプリ側にログイン機能を実装しない。CI・監視・エージェントからのアクセスは、専用のサービスアカウントを用いる。
検収では、退職者を想定した確認を1つ足してください。 「Workspace 側でアカウントを停止したら、このツールに入れなくなること」を実際に確かめる。ここが通っていれば、アカウント管理が二重化していないことの証明になります。ソーシャルログインを実装してもらう場合の検収で見る点も併せて確認しておくと安全です。
次にやること
社内で使っている自作ツールを1つ選び、そのツール専用のパスワードを持っている人が何人いるかを数えてください。 3人以上いれば、寄せる価値があります。退職者のアカウントが残っていれば、優先度はさらに上がります。
社内ツールの認証設計、Google Workspace を軸にした権限の集約、CI や AI エージェントからの機械アクセスの通し方については、グリームハブの開発・AI・自動化のご相談で承っています。既存ツールの構成によって取れる手が変わるため、個別にご相談ください。お問い合わせからどうぞ。
