GWSカスタム属性をGASで人事連携する設計ガイド

Google Workspace（以下 GWS）のカスタム属性（Custom User Attributes）は、Context-Aware Access（CAA）の条件式や動的グループの絞り込みに直結する。この記事では、GAS（Google Apps Script）と Admin SDK Directory API を使った人事連携の設計判断の軸を整理する。

この記事を読んだほうが良い人

• GWS / Cloud Identity のカスタム属性を入退社・異動のたびに手作業で更新している
• 更新漏れが CAA ポリシーや動的グループに影響していないか確かめたい
• SCIM 連携の導入を検討しているが、100 名規模で費用対効果があるか判断できていない
• GAS と Admin SDK Directory API を使った軽量な同期設計を検討している

カスタム属性の乖離が引き起こす2つのリスク

カスタム属性は「登録して終わり」のデータではなく、組織のアクセス制御に直結する動的な情報だ。主に 2 つの領域で問題を引き起こす。

CAA の条件式への影響

CAA は Cloud Identity Premium / Workspace Enterprise Standard・Plus・Essentials Plus / Education Standard・Plus / Frontline Standard・Plus で利用できるアクセス制御機能だ。Workspace Business 各プランは対象外のため、導入前にエディションを確認すること。Advanced mode では CEL（Common Expression Language）式を使って条件を定義でき、カスタム属性を参照した条件式を構成できる。カスタム属性を参照する具体的な CEL 構文は、CAA Advanced mode の公式仕様（Google Workspace 管理者ヘルプの「コンテキストアウェアアクセスの高度なモードの例」）を事前に確認すること。

たとえば「雇用区分が業務委託のユーザーは社外から特定アプリにアクセス不可」のような制御を、カスタム属性の値で実現できる。退職や契約終了後もその属性が更新されないままだと、意図しないアクセスが継続するリスクがある。

動的グループのフィルタリングへの影響

GWS の動的グループ（Dynamic Groups）は、ユーザー属性に基づいてメンバーシップを自動更新する機能だ。部門コードや役職フラグをカスタム属性で管理している場合、異動後に属性が古い値のままだと、本来入るべきでないグループに残り続ける。共有ドライブや Google Chat スペースへのアクセスが想定外に継続することがある。

どちらのリスクも「属性が実態と乖離している期間」が長いほど影響が大きくなる。手動更新は漏れとタイムラグが避けられないため、自動同期の設計が有効になる。

GAS vs SCIM：GWSユーザー属性と人事システムの同期設計をどう選ぶか

カスタム属性を人事マスタと同期する主な方法は SCIM 連携経由 と GAS + Directory API の 2 方式だ。

SCIM 連携が向いている状況

SCIM（System for Cross-domain Identity Management）は、Okta や Microsoft Entra ID などの IdP（Identity Provider）を介してユーザープロビジョニングを自動化する標準プロトコルだ。次のような状況に向いている。

• 組織に IdP がすでに導入されており、HR システムからの属性フィードを受け取れる
• 標準属性（氏名・メール・部署・役職）のプロビジョニングが主目的
• 複数の SaaS にまたがる一元プロビジョニングが必要

ただし、GWS のカスタムスキーマ（独自定義したフィールド）への書き込みは標準 SCIM スペック外になる。対応 IdP ではカスタム属性マッピングを設定できるが、その構成は別途必要になる。SmartHR 等の HR SaaS も SCIM をサポートしているが、GWS へ直接ではなく IdP を経由する構成が一般的だ。

GAS が向いている状況

GAS は次のような状況で現実的な選択肢になる。

• HR マスタがスプレッドシートや API 対応の軽量 SaaS（SmartHR 等）で管理されている
• IdP を新規導入するコストを避けたい、または既存 IdP がない
• 100 名規模で、カスタム属性の同期が自動化の主目的
• 既存の IT 構成を変えずに最小限の実装で始めたい

GAS は GWS アカウント内で動作し、スプレッドシートとの連携が容易だ。時間トリガを使った定期実行も設定でき、Admin SDK Directory API を直接呼び出せるためカスタムスキーマの書き込みに向いている。

判断フロー

状況	推奨方式
IdP 導入済み・複数 SaaS プロビジョニングが必要	SCIM + IdP
HR マスタがスプレッドシート or 軽量 SaaS	GAS + Directory API
カスタム属性の更新のみが目的	GAS + Directory API
標準属性は SCIM、カスタム属性だけ追加で自動化したい	SCIM × GAS ハイブリッド

SCIM と GAS は排他関係ではない。標準属性のプロビジョニングを SCIM に任せつつ、カスタム属性の同期だけ GAS で補完するハイブリッド構成も実用的な設計だ。

Directory API カスタムスキーマ操作のポイント

GAS で Admin SDK Directory API を使ってカスタム属性を操作する際の、設計上の重要ポイントを整理する。

スキーマの事前定義が必要

カスタム属性を使うには、まずスキーマ（フィールド名・型の定義）を先に作成しておく必要がある。スキーマの作成は Admin SDK Directory API の Schemas.insert メソッドまたは GAM などのクライアントを通じて行う（公式リファレンスより）。

スキーマ名とフィールド名は作成後に変更できない。フィールドの型（STRING / INTEGER / BOOLEAN など）も後から変更不可だ。命名規則と型の設計は実装前に確定させておくことが重要になる。

属性値の書き込み構造

属性値の更新は、Admin SDK Directory API の Users.patch メソッドで customSchemas プロパティを指定することで実行できる。スキーマ名を親キーとし、その配下にフィールド名と値を配置するネスト構造になっている（公式リファレンスより）。GAS では Advanced Service として Admin SDK Directory サービスを有効化してから呼び出す。

読み出し時は projection パラメータに custom または full を指定しないと、カスタム属性が返ってこない点も注意だ。デフォルトの basic では含まれない。

制約として把握しておくべき数値

公式リファレンスによると、アカウント全体でのスキーマ数は最大 100、フィールド数も最大 100 という制限がある。100 名規模の組織ではほぼ問題にならないが、増設する前提で設計する場合は念頭に置いておく。文字列フィールドの値は単一値で最大 500 文字。センシティブな個人情報（政府 ID 番号・カード情報・医療情報等）の格納は公式で明示的に禁止されている。

属性更新漏れを検知するパターン

GAS による自動化を導入しても、次のような要因で更新が抜ける場合がある。

• スクリプトの実行エラー（API クォータ超過・認証切れ）
• HR マスタへの入力漏れ（フィールドが空欄のまま）
• スキーマ名・フィールド名の表記揺れによるミスマッチ

これに対処するため、以下の 3 パターンを組み合わせて使う。

パターン1：HR マスタと Directory API の定期突合

HR マスタの期待値と Directory API から取得した実際の属性値を定期的に比較し、不一致があれば Slack や Gmail で通知するスクリプトを用意する。更新スクリプトとは独立して動かすことで、「更新したつもりが反映されていなかった」という状況の見落としを防ぐ。

パターン2：実行ログの記録と監視

GAS のエラーログをスプレッドシートや Cloud Logging に書き出す運用に乗せる。Apps Script の実行一覧からエラーは確認できるが、通知設定まで組み込んでおくほうが確実だ。スクリプトの停止や認証切れを早期に発見できる。

パターン3：CAA アクセス監査との照合

GWS の管理コンソールにある「監査と調査」セクションには、CAA の評価結果に関連するアクセスイベントのログが残る。期待していない拒否や許可が増えた場合は、CAA 条件の設定だけでなくカスタム属性の更新漏れを疑う手がかりになる。

設計前に確認しておくべき4点

実装を始める前に次の点を確認しておくと、後からの修正コストを下げられる。

• 同期対象フィールドを絞る: CAA や動的グループで実際に参照しているフィールドだけを自動化の対象にする。全属性を同期しようとするとスコープが広がり、HR マスタの品質問題の影響を受けやすくなる
• フィールド型と HR データの形式を合わせる: 日付型・Boolean の扱いは HR システムとの形式差異が出やすい。事前に突き合わせる
• 実行アカウントの権限: GAS を動かすサービスアカウントまたは管理者アカウントに、Directory API への適切な権限（ユーザー管理権限以上）が付与されているか確認する
• API クォータの把握: Admin SDK Directory API の 1 日あたり呼び出し上限を確認し、ユーザー数とトリガ頻度の積が上限に収まるか試算する

まとめ

カスタム属性の自動化は「更新スクリプトを作る」だけでは不十分だ。同期の正確性を継続的に保証する仕組み、つまり突合チェックと実行ログ監視がセットになって初めて運用に耐える。

どの属性を自動化すべきかは、CAA ポリシーや動的グループで実際に参照しているフィールドを棚卸しすることで優先度が見えてくる。100 名規模であれば GAS + Directory API の組み合わせが、IdP 新規導入のコストを抑えながら属性の鮮度を保つ現実的な出発点になる。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。