Skip to main content
公開日: 2026 年 9 月 30 日
この記事は 2026 年 9 月時点の情報です。
実はAdminaは、従業員マスターとなるSaaSを設定しなくても使い始められます。「部署で契約しているSaaSのアカウント管理を任されているけれど、従業員マスターの連携はこれから」というケースもあるでしょう。そんな部署の管理者の方に向けて書きました。 AdminaのSaaS管理機能では、Google WorkspaceやMicrosoft Entra IDなどの「従業員マスター(全社アカウントの大元データ)」を繋いで全社導入するのが一般的な形です。その一方で、従業員マスターSaaSは連携せず、部署のディレクトリ台帳(Google スプレッドシート)を大元データにして部署単位で運用する形も選べます。管理する範囲は自部署の従業員とSaaSだけに絞れます。 以前の記事では、アカウントを管理したいSaaSのうち、直接連携できないものをスプレッドシートで取り込む方法を紹介しました。この記事でスプレッドシートにするのは、従業員マスターのほうです。部署のディレクトリ台帳スプレッドシートを、Adminaのディレクトリに反映します。基本は、台帳をCSVにしてAdminaにアップロードするだけです。反映を自動化したい方向けに、GAS(Google Apps Script)とAdmina APIのサンプルコードも載せています。
以前の記事とこの記事の違いを並べた図。以前の記事は、SaaSアカウントをスプレッドシートで取り込む。ディレクトリはGoogle WorkspaceやEntra IDなどの従業員マスターと連携したままで、未対応SaaSのアカウントだけをスプレッドシート連携で取り込む。この記事は、従業員マスターをスプレッドシートにする。従業員マスターは繋がず、部署のディレクトリ台帳スプレッドシートをCSVまたはAPIでディレクトリに反映する。SaaSアカウントはOAuthやAPIなどの通常のSaaS連携で取り込む。どちらもAdminaで名寄せ・退職検知・棚卸しを行う

以前の記事とこの記事でスプレッドシートを使う場所の違い

従業員マスターSaaSを繋がない構成が向いている場面

SaaS管理ツールでは、従業員マスターを連携するのが基本です。 Google WorkspaceやMicrosoft Entra IDを従業員マスターとして繋ぐと、管理対象外の全社員アカウントまでディレクトリに入ってきます。管理対象外のアカウントは入れずに、自部署の従業員だけをディレクトリに入れたい場合は、従業員マスターを繋がない構成が向いています。 なお、グループ会社ごとにGoogle Workspaceなどのテナントが分かれていて、1つのSaaSを従業員マスターに決められない場合にも、同じ構成が使えます。

全体構成:スプレッドシート台帳を従業員マスター代わりにするデータ動線

構成はシンプルです。Adminaの設定 > 組織 > 従業員マスター設定はあえて設定せず、現場で管理しているディレクトリ台帳スプレッドシートを大元データとして、Adminaのディレクトリ(従業員台帳)に反映します。従業員マスターを設定しない場合にCSVでディレクトリ台帳を作ることは、初期設定のヘルプページでも案内しています。
従業員マスターSaaSを繋がない場合の全体構成図。ディレクトリ側では、部署のディレクトリ台帳スプレッドシートから、パターンA(CSVインポート、画面から手動)またはパターンB(GAS × Admina API、毎日自動)でAdminaのディレクトリへ反映する。SaaSアカウント側では、直接連携できるSaaSをOAuth・API・IDとパスワードでAdminaのSaaS管理に取り込む。Adminaはメールアドレスで名寄せし、退職アカウントを検知する

従業員マスターSaaSを繋がない場合の全体構成

台帳を大元にしても、退職検知の仕組みはそのまま担保できます。メールアドレスが一致していればAdminaディレクトリ上の同じ従業員に名寄せされるため、台帳側でステータスを「退職」に更新してAdminaに反映すれば、各SaaSに残っているアカウントをアラート種別「退職アカウント」として検知できます。

パターンA(基本):ディレクトリ台帳CSVインポートによる反映

基本の方法です。Adminaの標準機能だけで完結し、大まかな流れは3ステップです。
  1. ディレクトリ > インポートからテンプレートCSVをダウンロードする(既存データをエクスポートして修正する形でもOK)
  2. 台帳スプレッドシートの内容をテンプレートの項目に合わせて成形し、CSVとして書き出す
  3. ディレクトリ > インポートからCSVを取り込む
画面ごとの詳しい手順や登録できる項目の仕様は、ディレクトリ台帳CSVのインポート手順にまとまっています。 運用中の作業は、人の出入りがあったときに台帳をCSVで書き出してアップロードするだけです。更新頻度が多くない場合は、この方法でも十分に回るでしょう。更新頻度が高くアップロードも自動にしたい場合は、次のパターンBを参考にしてください。

パターンB(応用):GAS×Admina APIで自動反映するサンプルコード

ここからは、反映を自動化したい方向けの応用です。 Adminaには公開APIが用意されており、ディレクトリの従業員情報(Identity)をAPI経由で取得・作成・更新できます。これを使ってGAS(Google Apps Script)で「台帳スプレッドシートを読み取り、Adminaディレクトリへ反映する」処理を書けば、CSVの書き出しと手動アップロードが不要になります。

事前準備

  • Adminaの設定画面からAPIキーを作成します(手順はIT Management APIの認証ガイド)
  • 組織ID(Admina管理画面のURLに含まれる数値)を控えておきます
  • 台帳のメールアドレスのドメインが、設定 > 組織 > ドメインに登録されているか確認します。組織を作成したときのプライマリドメイン以外を使う場合は、追加が必要です。登録がないと外部IDとして扱われ、正社員など社内IDでしか選べない雇用形態では作成がエラーになります

使うエンドポイントは3つだけ

APIリファレンス: Identity一覧取得 / Identity作成 / Identity更新

処理フロー(upsert方式)

GASスクリプトの処理フロー図。毎日1回、①ディレクトリ台帳スプレッドシートを読み込み、②Identity一覧APIで取得したAdminaの従業員とメールアドレスで照合する。③台帳にいてAdminaにいない人はPOSTで新規作成し、両方にいて差分がある人はPUTで更新する。④台帳にいないのにAdminaで就業中の人は警告のみ出し、退職にはしない。差分がない人には何もしない

GASスクリプトの処理フロー

実装のポイント:ステータスのマッピング

この連携の肝は、台帳の「ステータス」列をAdminaのステータス(employeeStatus)に変換する部分です。台帳に最終勤務日を入れておけば、その翌日の0時台にスクリプトが退職としてAdminaに反映します。最終勤務日は、Adminaの契約終了日(contractEndAt)に入ります。ステータス列を手で書き換えなくても、各SaaSに残ったアカウントは退職アカウントアラートで検知できます。
スクリプトが書き換えるのはAdmina側だけで、台帳は変更しません。最終勤務日を過ぎても、台帳のステータス列は「就業中」のまま残ります。台帳の上でも退職した人が分かるようにしたい場合は、ステータスを「退職」に変えてください。変えても変えなくても、Adminaに反映される結果は同じです。スクリプトが台帳のステータスを書き換えないのは、退職日ではなく最終勤務日を基準にアカウントを消すなど、組織によって運用が違うためです。ご自身の組織の運用に合わせて、スクリプトを書き換えてください。
以下はサンプルコードです。台帳の列構成(A列: メールアドレス、B列: 姓、C列: 名、D列: ステータス、E列: 雇用形態、F列: 部署、G列: 最終勤務日)に合わせて、冒頭の COL 定義とシート名を変えて使ってください。コードは台帳スプレッドシートの「拡張機能 > Apps Script」に貼り付けます。台帳をこれから作る場合は、setupRosterSheet を1回実行すると、この列構成のシートを用意できます。ステータスと雇用形態の列はプルダウンになるので、表記ゆれを防げます。本番の台帳で使う前に、少人数の台帳で動きを確かめてください。
Googleスプレッドシートのディレクトリ台帳の画面。1行目にメールアドレス・姓・名・ステータス・雇用形態・部署・最終勤務日の列が並び、画面下のタブは「従業員一覧」。2行目以降に従業員の行がある。ステータス列と雇用形態列はプルダウンで選ぶ形式になっている。メニューバーの右端に Admina メニューが表示されている

setupRosterSheet で用意した台帳の例。ステータスと雇用形態の列はプルダウンで、メニューに「Admina」が加わる

運用・セキュリティのポイント

権限の分け方の図。ディレクトリ台帳スプレッドシートの中に、従業員一覧シートと、台帳に紐づく同期スクリプトがある。同期スクリプトはAPIキーをスクリプトプロパティに保存し、メニューの今すぐ反映と毎日1回のトリガーで実行され、Admina APIでAdminaのディレクトリに反映する。台帳の編集者は全員スクリプトとAPIキーを見られるので、編集権限はAPIキーを見られてもいい人だけに渡す。Adminaにログインするのは部署の管理者だけ

台帳の編集者と部署の管理者の権限の分け方

  • APIキーはGASのスクリプトプロパティに保存し、コードやシートに直書きしないでください
  • 台帳の編集者は、APIキーを見られてもいい人だけにしてください。台帳に紐づくスクリプトとスクリプトプロパティは、台帳を編集できる人全員が見られます。台帳を見るだけの人は、閲覧権限で共有します
  • 外部の委託先など、APIキーを見せたくない人も台帳を編集する場合は、スクリプトを台帳とは別のスタンドアロンのApps Scriptプロジェクトに作って分けてください。コードの SpreadsheetApp.getActiveSpreadsheet() を SpreadsheetApp.openById("台帳のID") に変えれば動きます。その場合メニューは出ないので、反映は毎日のトリガーか、部署の管理者による手動実行になります
  • 時間主導型トリガーで毎日実行しておけば、日々の作業は「台帳シートを更新するだけ」になります
  • すぐに反映したいとき(入社当日や退職当日など)は、台帳のメニューの Admina > 今すぐ反映 から同期できます。結果の件数とエラーは画面に出ます。何度実行しても、差分がある人だけを反映します。初めて実行する人は、Googleの承認画面でスクリプトの実行を許可してください
  • 退職した人の行は削除せず、ステータスを「退職」にするか最終勤務日を入れてください。行を削除しても、Admina側では就業中のまま残ります(スクリプトは警告を出します)。この警告は、台帳にいない社内IDで就業中の人全員が対象です。部署の管理者など、台帳の対象外の人が組織にいる場合は、その人も台帳に行を足しておくと、毎回の警告が出なくなります
  • Adminaのアカウントは、部署の管理者だけが持てば足ります。台帳の編集者はAdminaにログインしなくても、台帳の更新と反映ができます

2パターンの使い分け

パターンAから始めて、アップロードの手間も省きたくなったらパターンBを試してみてください。

まとめ:部署単位で始めるAdminaのSaaS管理スモールスタート

Adminaは、従業員マスターを連携しなくても始められます。現場のスプレッドシート台帳を大元にして、自部署の従業員とSaaSだけを管理する形でも運用できます。 いま使っている台帳スプレッドシートは、作り直さなくて大丈夫です。そのままAdminaに反映すれば、退職検知や棚卸しの対象にできます。基本はCSVインポートで始められます。アップロードの手間も省きたくなったら、サンプルコードで反映を自動化できます。まずは自部署の台帳スプレッドシートを繋ぐところから始めてみてください。

Admina の資料を請求する(資料 3 点セット)

最終更新日 2026年9月30日