新しいPCを配るたびに管理コンソールを開き、Chrome の登録トークンを探してコピーし、セットアップ手順書に貼る。委託先との契約が終わったのに、その組織部門の登録トークンが有効なまま残っている。部署の異動があるたびに、登録済みのブラウザを1台ずつ別の組織部門へ移している。Chrome Enterprise Core で社内の Chrome を管理していると、こうした手作業が少しずつ積み上がります。
この登録トークンの発行・無効化と、登録済みブラウザの一覧・組織部門の移動が、Chrome Management API に加わりました。2026年10月に API 定義（Discovery 文書）に現れ、11月11日の時点では API リファレンスと開発者ガイドにも載っています。同じ操作は、これまでも Admin SDK の Directory API（v1.1beta1）のエンドポイントで行えました。今回の追加は、それを Chrome Management API の形で書き直したものと読めます。新しく自動化を組む場合も、既存のスクリプトを持っている場合も、両者の違いを押さえておくと判断しやすくなります。
この記事は、2026年10月13日に Discovery 文書を確認して書き、2026年11月11日に Chrome Management API のリファレンス、開発者ガイド、コードサンプルの原文で照合し直したものです。従来の API は Google の Chrome Enterprise ヘルプで確かめました。編集部は API を実際に呼び出していません（検証用の管理者権限・認証情報を用意していないため）。リファレンスとガイドにプレビュー版などの表示はありませんが、リリースノートや告知は見つからず、提供開始の日付は確認できていません。
リファレンスに載った2つのリソース
顧客（customers）の下に、登録トークンの enrollmentTokens と、登録済みブラウザの chromeBrowsers があります。URL はどちらも https://chromemanagement.googleapis.com/v1/customers/{customer}/ から始まります。
| 操作 | HTTP | リファレンスの説明（要約） | 押さえる点 |
|---|---|---|---|
enrollmentTokens.create | POST .../enrollmentTokens | ブラウザの登録トークンを作る | 同じ組織部門に有効なトークンがあると失敗 |
enrollmentTokens.get / list | GET | トークンを1件・一覧で取得 | 状態・組織部門で絞り込み。1回100件まで |
enrollmentTokens.revoke | POST .../enrollmentTokens/{id}:revoke | トークンを無効にする | 無効にした人と日時が残る |
chromeBrowsers.get / list | GET | 登録済みのブラウザ（端末）を取得 | 22の項目とグループで絞り込み。1回100件まで |
chromeBrowsers.patch | PATCH | 管理者のメモ（注記）を更新 | 利用者・場所・資産番号・メモの4項目 |
chromeBrowsers.move | POST .../chromeBrowsers:move | 別の組織部門へ移す | 1回600台まで。1台でも失敗すると全台移らない |
chromeBrowsers.delete | DELETE | 収集したデータを削除 | 登録の解除になるかは書かれていない |
Discovery 文書には、2026年10月8日付の版（revision 20261008）で2つのリソースが現れました。Google の Node.js 用クライアントにある9月30日付の定義にはありません。その後の版で、ブラウザ一覧の既定の並び順が変わり（revision 20261020）、絞り込みの項目に virtual_device_id が加わり（revision 20261101）、各メソッドに必要なスコープが載りました（revision 20261104）。10月中に定義を読んで書いたスクリプトは、この3点を見直してください。
必要なスコープと管理者権限
開発者ガイドの「Chrome Management Chrome Browsers API」「Chrome Management Enrollment Tokens API」に、メソッドごとの OAuth スコープと管理者権限の表があります。
| 対象 | 読み取り（get・list） | 書き込み（create・revoke・patch・move・delete） |
|---|---|---|
| 登録トークン | chrome.management.enrollmenttokens.readonly または chrome.management.enrollmenttokens | chrome.management.enrollmenttokens |
| ブラウザ | chrome.management.browsers.readonly または chrome.management.browsers | chrome.management.browsers |
スコープはいずれも https://www.googleapis.com/auth/ に続く名前です。管理者権限は、どちらの API も管理コンソールの「Services > Chrome Management > Settings > Managed Browsers」です。読み取りだけなら、その下の「Read」でも足ります。ガイドには「Note: administrator roles can be assigned directly to a Service Account.」とあり、サービスアカウントに管理者ロールを直接割り当てる使い方もできます。一覧の書き出しだけを自動化するなら、.readonly のスコープと「Read」の権限に絞れます。
なお、API の初期設定のガイド（Initial Setup）で OAuth 同意画面に入れるスコープの例は Reports・App Details・Telemetry の3つだけで、今回の2つの API のスコープは載っていません。
従来の API（Directory API v1.1beta1）との違い
Chrome Enterprise ヘルプの「Use the Chrome Enterprise Core API」と「Use the Chrome Browser Enrollment Token API」には、https://www.googleapis.com/admin/directory/v1.1beta1/customer/{my_customer|customerId}/... のエンドポイントで、ブラウザの一覧・取得・注記の更新・削除・組織部門の移動（moveChromeBrowsersToOu）と、登録トークンの一覧・作成・無効化を行う方法が載っています。この版の Discovery 文書は公開されておらず（要求すると404）、Admin SDK の定義（directory_v1）にも Chrome ブラウザや登録トークンのリソースはありません。
ヘルプと新しいリファレンスを比べると、次の違いがあります。
| 項目 | 従来（v1.1beta1、ヘルプの説明） | 新しい API（Chrome Management API） |
|---|---|---|
| トークンの組織部門 | 組織部門のパス（作成時は org_unit_path） | 組織部門のID（orgUnitId）。一覧の絞り込みはパスでもIDでもよい |
| 移動先の指定 | 組織部門のパス、または id: を付けたID | 組織部門のID（destinationOrgUnitId） |
| 移すブラウザの指定 | 端末のID（resource_ids） | resourceIds。コードサンプルでは customers/{customer}/chromeBrowsers/{browserPermanentId} の形 |
| 移動の上限 | 1回600台 | 1回600台。1台でも失敗すると全台移らない |
| トークンの期限 | expire_time・ttl で指定できる | 期限を指定する項目がない |
| スコープ | ブラウザは admin.directory.device.chromebrowsers（読み取りは .readonly） | 上の表のとおり、ブラウザとトークンで別のスコープ |
| 顧客の指定 | my_customer が使える | コードサンプルでは my_customer が使える |
従来の API について、廃止や移行の案内はヘルプに見当たりませんでした。動いているスクリプトをすぐ書き換える理由は、今のところ公式資料からは読み取れません。
登録トークンは「組織部門ごとに有効なものは1つ」
作成するときの指定
作成時に指定できるのは次の3つです。
- 組織部門
orgUnitId: 省略すると最上位の組織部門のトークンになります（「If not set, the token is created for the root organization unit.」）。指定するのはパス（/営業部のような表記）ではなく、組織部門のIDです - 種類
tokenType: 現時点の選択肢は Chrome ブラウザ用（ENROLLMENT_TOKEN_TYPE_CHROME_BROWSER）だけで、省略してもこれになります - ID
enrollmentTokenId: 任意のクエリパラメーターです。1〜63文字の英数字と._-で、顧客の中で重ならない値を付けられます。省略すると自動で採番されます
注意したいのは、リファレンスの作成の説明にある一文です。
Creation fails if there is already an active token for this customer under the same org unit.
同じ組織部門に有効なトークンがあると、新しいトークンは作れません。 Chrome Enterprise ヘルプにも「For each organizational unit, there can only be one active enrollment token.」とあります。「PCを配るたびに新しいトークンを作る」という組み立ては、2回目で失敗します。発行のスクリプトは、先に list で状態が有効（ACTIVE）のトークンを探し、あればそれを使う、入れ替えたいなら revoke してから create する、という順にします。
状態と、残る記録
トークンの状態（state）は、有効（ACTIVE）、期限切れ（EXPIRED）、無効（REVOKED）の3つです。作成した人のID（creatorId）と作成日時、無効にした人のID（revokerId）と無効にした日時（revokeTime）が記録されます。誰がいつ発行し、いつ止めたかを API から取り出せます。
一方で、有効期限を指定する項目は、リファレンスのトークンの項目にありません。 期限切れという状態はあるものの、何をもって期限切れになるのかは、リファレンスにもガイドにも書かれていません。従来の API では作成時に期限（expire_time・ttl）を指定できましたが、新しい API にはその項目がありません。期限に頼らず、不要になった組織部門のトークンは revoke で止める運用にしておくのが確実です。なお、ヘルプによると、トークンを無効にしても、そのトークンで登録済みのブラウザは登録されたまま残ります（「Devices that you already enrolled with the revoked token remain active and enrolled.」）。
list は、状態（token_state）、組織部門のパス（org_unit_path）・ID（org_unit_id）、種類（device_type）で絞り込め、条件は AND でつなげます。ガイドのコードサンプルには token_state=ACTIVE AND org_unit_path=/Marketing のような例があります。
トークンの値の扱い
トークンの値（token）は、端末に保存され、登録のリクエストで端末を識別させる値と説明されています。その組織部門にブラウザを登録できる値として扱い、手順書やチャットに平文で貼らず、配布ツールの秘密情報として渡すのが安全です。
ブラウザの一覧を絞り込み、600台まで一度に移す
一覧の絞り込みと並べ替え
chromeBrowsers.list は、マシン名、OS、バージョン、最後に使った人、最終の利用日時、組織部門、管理者の注記など22の項目と、Cloud Identity のグループ（in_group("groups/{groupId}")）で絞り込めます。条件は AND でつなぎます。項目名を付けずに文字列だけを書くと、索引のある文字列の項目すべてから探します。
日時の項目は =・<=・>= が使え、RFC 3339 形式の値をダブルクォートで囲んで指定します。たとえば「最終の利用日時（last_activity_time）が3か月以上前」のブラウザを抜き出せば、使われなくなったPCの候補になります。ワイルドカード * はマシン名・資産番号・バージョンだけで使えます。
並び順を指定しないと、ブラウザのID（browser_permanent_id）の昇順で返ります。新しい順に見たいときは、orderBy に last_activity_time desc のように desc を付けます。1回に返るのは最大100件で、続きは pageToken で取ります。
返る項目には、シリアル番号、マシン名、OS、Chrome ごとのバージョン・チャネル、最近使った人のほか、同じ端末IDを複数の端末が使っている可能性を示す deviceIdCollision があります。PCのイメージを複製して配っている場合は確認しておくとよいでしょう。
管理者の注記の更新
patch で書き換えられるのは、利用者（annotatedUser）、場所（annotatedLocation）、資産番号（annotatedAssetId）、メモ（annotatedNotes）の4つです。ほかは「Output only」です。書き換える項目は updateMask で指定します。資産台帳と資産番号をそろえておくと、台帳の番号で検索できます。
移動は「全部移るか、1台も移らないか」
chromeBrowsers.move は、移動先の組織部門のID（destinationOrgUnitId）と、移すブラウザの一覧（resourceIds）を受け取ります。上限は1回600台です（「A maximum of 600 browsers may be moved per request.」）。リファレンスの説明には次のようにあります。
If there is an error while moving any of the browsers, none of the browsers will be moved.
1台でもエラーになると、1台も移りません。 中途半端な状態は残りませんが、失敗した束は対象を確認して送り直します。成功したときの応答の本体は空で、失敗したときにどのブラウザが原因かが返るかは、リファレンスには書かれていません。
公式資料を踏まえた自動化の組み立て方
公式資料からは分からないこと
実装の前に、テスト用の組織部門で確かめたい点です。
deleteが何を消すか。 リファレンスの説明は「Deletes the data collected from a Chrome browser profile.」です。ヘルプによると、管理コンソールでブラウザを削除すると登録が解除され、端末のクラウドポリシーが外れます。API のdeleteが同じ動きをするかは書かれていません。台帳から外す目的で安易に呼ばないようにしますresourceIdsに入れる値。 リファレンスは「List of resource IDs」とだけ書いています。ガイドのコードサンプルはcustomers/{customer}/chromeBrowsers/{browserPermanentId}の形で、ブラウザのIDだけを渡せるかは書かれていません- トークンが期限切れになる条件
my_customerの扱い。 コードサンプルは「ID of the customer or literal my_customer」としていますが、リファレンスの各メソッドの説明はcustomers/{customer}の形だけです- 提供開始の日付と対象のエディション。 Chrome Management API のリリースノートのページは見つからず、Google Workspace の更新情報のブログにも告知は見当たりませんでした
ブラウザの管理画面で拡張機能を段階的に絞る進め方はChrome Enterprise Coreで拡張機能を管理する、更新を強制してバージョンをそろえる方法はChromeの緊急更新を全社に行き渡らせるで整理しています。同じ Chrome Management API で拡張機能や SaaS の利用状況を棚卸しする方法は、Chrome拡張機能のリスク評価をAPIで取得とChrome Management APIでシャドーAIを棚卸しにまとめています。
編集部の提案する手順
ここまでの資料を踏まえた、編集部の提案です。
- 組織部門の設計を先に決める。 トークンもブラウザの移動も、組織部門のIDで指定します。部署や委託先ごとの分け方は組織部門(OU)で部署ごとに分けるを参考にしてください。IDは Directory API の組織部門（
orgunits）のorgUnitIdで確認できます - 権限を用途で分ける。 棚卸しだけの仕組みには
.readonlyのスコープと「Managed Browsers」の「Read」の権限を、トークンの発行や移動をする仕組みには書き込みのスコープと権限を与えます - トークンは「探してから作る」。
listで組織部門とACTIVEを条件に探し、なければcreate。入れ替えるときはrevokeのあとにcreate - 委託先・期間限定の組織部門は、終わったら
revoke。 期限の項目に頼らない - 月に一度、一覧を書き出す。 最終の利用日時、バージョン、
deviceIdCollisionを見て、使われていないPCや複製されたPCの候補を確認する - 移動は600台以下に分け、テスト用の組織部門で先に試す。 一括で失敗する性質と、
resourceIdsに入れる値の形を確かめてから本番の異動に使う
POST https://chromemanagement.googleapis.com/v1/customers/my_customer/chromeBrowsers:move
Authorization: Bearer （chrome.management.browsers のスコープを持つアクセストークン）
Content-Type: application/json
{
"destinationOrgUnitId": "（移動先の組織部門のID）",
"resourceIds": [
"customers/my_customer/chromeBrowsers/（ブラウザのID）",
"customers/my_customer/chromeBrowsers/（ブラウザのID）"
]
}上の形は、開発者ガイドのコードサンプルに合わせて項目を並べたもので、編集部は送信していません。
確認した範囲
2026年10月13日に、Chrome Management API の Discovery 文書（revision 20261008）と、googleapis/google-api-nodejs-client の discovery/chromemanagement-v1.json（revision 20260930）を比べました（資料調査）。2026年11月11日に、Chrome Management API のリファレンス（customers.enrollmentTokens・customers.chromeBrowsers の各メソッド）、開発者ガイド（Chrome Browsers API・Enrollment Tokens API・それぞれのコードサンプル・Initial Setup）、Discovery 文書（revision 20261109）、従来の API を説明する Chrome Enterprise ヘルプ3本を開いて照合しました。API の呼び出し、管理コンソールでの表示、端末への登録は試していません。提供開始の日付、対象のエディション、料金の条件は確認できていません。
Chrome ブラウザの管理や Google Workspace の運用の自動化は、IT・Google Workspace 無料相談からお問い合わせください。
参考資料
- Chrome Management API — REST Resource: customers.enrollmentTokens
- Chrome Management API — REST Resource: customers.chromeBrowsers
- Chrome Management API — Method: customers.chromeBrowsers.move
- Chrome Management API — Chrome Management Chrome Browsers API（ガイド）
- Chrome Management API — Chrome Management Enrollment Tokens API（ガイド）
- Chrome Management API — Code Samples for the Chrome Management Chrome Browsers API
- Chrome Management API — Code Samples for the Chrome Management Enrollment Tokens API
- Chrome Management API — Discovery 文書
- Chrome Enterprise ヘルプ — Use the Chrome Enterprise Core API（従来の API）
- Chrome Enterprise ヘルプ — Use the Chrome Browser Enrollment Token API（従来の API）
- Chrome Enterprise ヘルプ — Enroll cloud-managed Chrome browsers
