- デバイス登録・組織管理・ライセンス
- セキュリティ・証明書・通信
- TLSインスペクションでは一部のGoogle通信を除外する
- ChromeOSのVerified Accessとは
- ChromeOSでUSBメモリなどの外部ストレージの利用を制限する方法
デバイス登録・組織管理・ライセンス
ZTE
ChromeOSのZTEトークンで登録先OUを指定する方法
ChromeOS端末をゼロタッチ登録（ZTE）する場合、ZTEトークンを生成する際に、端末の登録先となる組織部門（OU）をあらかじめ指定できます。
例えば、新しい端末を「営業デバイス」というOUへ直接登録したい場合は、Google管理コンソールで次の流れで操作します。
［デバイス］→［Chrome］→［デバイス］ を開く
「営業デバイス」OUを選択 →［デバイスの登録］→［トークンの生成］
このOUで生成したZTEトークンを使って端末を登録すると、対象のChromeOS端末は最初から「営業デバイス」OUに配置されます。
そのため、
いったん別のOUへ登録してから、後で端末を移動する必要はありません。
ポイント
ZTEでは、どのOUを選択した状態でトークンを生成するかが重要です。
端末を配置したいOUを先に選択してから、ZTEトークンを生成します。
ChromeOS Flex
Zero-Touch Enrollment（ZTE）非対応
ChromeOSとChromeブラウザの組織管理・登録の違い
Chromeでは、ChromeOSデバイス自体を管理する方法と、Chromeブラウザだけを管理する方法があります。似ていますが、管理対象と登録方法が異なります。
サマリ
ChromeOSはOS単位で管理し、Windows・macOS・LinuxではChromeブラウザ単位で管理する、と整理すると分かりやすいです。
| 利用環境 | 基本的な管理方法 |
|---|---|
| Chromebook / ChromeOS | ChromeOSをEnrollment |
| Windows / macOS / Linux + Chrome | Chrome Enterprise CoreでChromeブラウザを登録 |
ChromeOSデバイスを組織の管理下に置く方法
ChromebookなどのChromeOSデバイスは、Google管理コンソールへデバイス登録（Enrollment）することで組織の管理下に置きます。
一般的な手動登録では、初期セットアップ時にEnterprise Enrollmentを行い、管理者権限を持つGoogleアカウントで認証します。
この通常の手動Enrollmentでは、事前に登録トークンを作成する必要はありません。
一方、大量展開などでZero-Touch Enrollment（ZTE）を利用する場合は、事前にZTE用の登録トークンを生成して利用します。
- 通常の手動Enrollment：登録トークン不要
- Zero-Touch Enrollment：登録トークンを利用
Chromeブラウザを組織の管理下に置く方法
Windows、macOS、Linuxなどで動作するChromeブラウザは、Chrome Enterprise Coreを利用してGoogle管理コンソールから管理できます。
この場合、管理者が登録トークン（Enrollment Token）を作成し、対象端末のChromeブラウザを組織へ登録します。
登録が完了すると、Chromeにはデバイス管理トークン（DM Token）が自動的に発行・保存されます。
それぞれの役割は以下のとおりです。
- 登録トークン：Chromeブラウザを最初に組織へ登録するために使用
- DM Token：登録後、ChromeがGoogleの管理サービスと通信するために使用
DM Tokenを管理者が事前に作成するわけではありません。
ChromeOSを登録した場合、Chromeブラウザの登録も必要か
ChromeOSデバイス自体をEnrollmentしている場合、そのChromeOS上のChromeブラウザをChrome Enterprise Coreの登録トークンで別途登録する必要は基本的にありません。
ChromeOSをEnrollmentすると、Google管理コンソールからChromeOSデバイス全体を管理でき、その中にはChromeブラウザに関する設定も含まれます。
そのため、Chromebookの場合は基本的に、
ChromeOSをEnrollmentする
という管理方法だけで問題ありません。
ChromeOSを登録せず、Chromeブラウザだけ登録することはあるか
構成としては考えられますが、ChromeOS端末では一般的な運用ではありません。
Chromeブラウザだけを登録するメリットがあるのは、
「端末自体は組織管理したくない、または管理できないが、Chromeブラウザだけ会社のポリシー下に置きたい」
といったケースです。
ただし、会社支給のChromebookなどを管理するのであれば、ブラウザだけではなくChromeOS自体をEnrollmentする方が自然です。
・macOS・LinuxではChromeブラウザ単位で管理する、と整理すると分かりやすいです。
GO-BOX
Go-Boxとは
Chromebookを大量に初期設定・登録する際に、人間のキーボード操作を自動化するためのサードパーティ製機器。
何を自動化するか
Chromebookに物理的に接続し、以下のような操作を自動実行する。
- Wi-Fi設定
- 登録画面の操作
- Chrome Enterpriseへのエンロール
- 必要な情報の入力
- 初期化後の再登録
イメージとしては、
人が1台ずつキー入力する代わりに、Go-Boxが自動で入力する
というもの。
ゼロタッチ登録との違い
ゼロタッチ登録
端末購入時に販売店などで事前登録しておき、
電源ON → インターネット接続 → 自動で企業環境へ登録
できる。
→ 物理的な設定作業が少なく、大量展開に向いている。
Go-Box
すでに手元にあるChromebookなどに物理接続して、
初期設定・登録操作そのものを自動化する。
→ 物理接続は必要なので、ゼロタッチほどスケーラブルではない。
使い分け
- 新規大量導入・ゼロタッチ対応販売店から購入
→ ゼロタッチ登録が基本 - ゼロタッチ登録できない既存端末
→ Go-Boxが候補 - 初期化後の端末を多数再登録したい
→ Go-Boxが便利
既存端末でもゼロタッチは使える？
場合によっては可能。
ただし、管理者が手元の端末を自由にゼロタッチ化できるわけではなく、通常は対応販売店側から端末情報をゼロタッチ登録へ追加できることが必要。
したがって、
既存端末 = Go-Box必須ではない。
既存端末でも販売店側でゼロタッチ対応できるなら、ゼロタッチの方が便利。
試験向けの覚え方
ゼロタッチ
= 事前登録して、電源を入れれば自動エンロール
Go-Box
= 手元のChromebookに接続し、人間の初期設定操作を自動化
組織内のすべての新規デバイスは、デフォルトで最上位の組織単位（OU）に登録されます。今後追加されるすべての新規デバイスを、デバイス専用のサブ組織単位に登録したい場合、どうすればよいでしょうか？
具体的には Google 管理コンソールのユーザー／ブラウザ設定 にあります。
［デバイス］→［Chrome］→［設定］→［ユーザーとブラウザ］
→ 対象OUを選択
→ 設定内で 「ChromeOS デバイスをユーザーの組織内に配置する」 を探して有効化します。
この設定は ［デバイスの設定］ではなく［ユーザーとブラウザ］側 です。
Google公式では、この設定を選ぶと、端末登録時に 登録ユーザーが所属するOUへChromeOSデバイスを配置する 動作になります。
利用済みChromebookを企業管理下に登録する場合の注意点
すでに個人利用などでサインイン済みのChromeOSデバイスを、あとから企業の管理対象デバイスとして登録したい場合は、まず端末を初期化（Powerwash）する必要があります。
なぜ初期化が必要なのか
ChromeOSの企業登録は、基本的に初回セットアップ時の登録フローで実施します。
そのため、すでにユーザーがサインインして利用を開始している端末では、そのまま企業登録を行うのではなく、一度端末を初期状態に戻してから登録します。
流れは次のとおりです。
利用済み端末 → Powerwash（初期化）→ 初回セットアップ → 企業登録
バンドルライセンス付き Chromebook の特徴
主なメリット
バンドルライセンス付き Chromebook では、Chrome Education Upgrade / Chrome Enterprise Upgrade 相当の高度な管理・セキュリティ機能を利用できます。
また、ライセンスは端末に紐づいており、対象デバイスのサポート終了まで有効です。別途ライセンス更新を行う必要がない点もメリットです。
ライセンスの考え方
バンドルライセンスは、通常の個別購入ライセンスのように別の端末へ自由に移し替えることはできません。
一方で、端末自体を別の管理ドメインに再登録できる場合はあります。そのため、
- 端末を別ドメインへ再登録する
- ライセンスだけを別端末へ移す
は別の話として考える必要があります。
Google Workspaceのドメイン所有権確認とは
Google Workspaceを利用する際は、登録したドメインを実際に管理していることをGoogleに証明する必要があります。
確認方法
一般的には、DNSにGoogleから指定された値をTXTレコードとして追加します。
例：
google-site-verification=xxxxxxxxxxxx
GoogleがこのTXTレコードを確認できると、ドメインの所有権確認が完了します。
セキュリティ・証明書・通信
Google Cloud Certificate Connector
Google Cloud Certificate Connector は、証明書発行基盤と Google 管理環境を連携させるために、ネットワーク接続された Windows サーバーにインストールして利用します。
たとえば、ADCSで作られたクライアント証明書をChrome OSに配布したいときに利用する。
Chrome OS ウィルス対策ソフト
GoogleはChromeOSについて、読み取り専用OS、Verified Boot、実行ファイルのブロック、サンドボックス、自動更新などを組み合わせることで、第三者製のウイルス対策ソフトを基本的に不要にしている （by google)
読み取り専用OSになると、ウィルス対策OKというのがつながらない。技術的に教えて。
「読み取り専用だからウイルスが絶対入らない」という意味ではありません。正確には、ウイルスがOSの中核部分を書き換えて居座るのをかなり難しくする、という話です。
技術的にはこうです。普通のOSでは、マルウェアが管理者権限を取ると、OSの重要ファイルや起動時に読み込まれる仕組みを書き換えて、再起動後も残り続けることがあります。ところがChromeOSでは、システム領域の多くが読み取り専用として扱われ、ユーザーや通常のプロセスが勝手に書き換えにくい設計です。
さらに重要なのが Verified Boot です。起動時に、OSの中核部分がGoogleの想定した正しい状態かを検証します。もし改ざんされていれば、正常なイメージに戻す方向で動きます。
なので防御の流れは、
書き換えにくい → もし改ざんされても起動時に検知 → 正常な状態へ戻す
という二段構えです。
ただし、これだけで全部の脅威を防ぐわけではありません。ChromeOSはさらに、ブラウザやアプリをサンドボックスで分離し、自動更新で脆弱性を修正します。つまり「読み取り専用OS」は多層防御の一部です。
一言でいうと、ウイルス対策ソフトが“侵入後に探して消す”発想なのに対して、ChromeOSは“そもそもOSを書き換えて定着しにくくする”設計を強く使っている、という違いです。
Chromebookがランサムウェアに強い理由
Chromebookがランサムウェア攻撃を受けにくい主な理由として、次の2つがあります。
1. アプリケーションがサンドボックス内で実行される
ChromeOSでは、アプリケーションやブラウザの処理がサンドボックスと呼ばれる隔離された環境で実行されます。
そのため、仮に1つのアプリやWebページが侵害されても、OS全体や他の領域へ影響が広がりにくい設計になっています。
2. 検証済みブート（Verified Boot）
Chromebookは起動時に、OSが改ざんされていないかを確認します。
異常が検出された場合は、正常な状態への復旧を試みるため、マルウェアがOSへ恒久的に入り込むリスクを下げられます。
ChromeOSはOSのデータを2つ保持している
ChromeOSでは、OSを格納する領域を**2系統（A/B）**持っています。
イメージとしては、
- OS-A：現在使用しているChromeOS
- OS-B：アップデート先として利用するChromeOS
という構成です。
ChromeOSをアップデートするときは、現在使用していない側のOS領域へ新しいバージョンを書き込みます。
例えば、
OS-Aで稼働中 → OS-Bへ新しいChromeOSを書き込む → 再起動 → OS-Bから起動
という流れです。
この仕組みにより、アップデートに問題が発生しても、正常なOS側を利用できるため、アップデート失敗によって端末が起動できなくなるリスクを下げられます。
ChromeOSにもパーティションは存在するが、ユーザーは基本的に意識しない
ChromeOSもWindowsと同じように、物理ストレージの内部は複数の**パーティション（領域）**に分割されています。
例えば、内部には次のような領域があります。
- OS-A用の領域
- OS-B用の領域
- ユーザーデータ用の領域
- 起動・復旧などに利用する領域
ただし、通常のChromeOSユーザーがこれらのパーティションを直接意識することはありません。
Windowsとの違い
Windowsでは、
Cドライブ、Dドライブ
などのドライブをユーザーが確認し、ファイル保存時に保存先として選択することがあります。
一方、ChromeOSではユーザーが普段意識するのは、
- マイファイル
- ダウンロード
- Google ドライブ
などの保存場所です。
その裏側にどのパーティションが存在しているかをユーザーが選択することは基本的にありません。
TLSインスペクションでは一部のGoogle通信を除外する
ChromeOSでTLS（SSL）インスペクションを利用する場合、Googleが指定する一部のホスト名をインスペクション対象から除外する必要があります。
TLSインスペクションでは、プロキシなどがHTTPS通信をいったん復号し、端末にはプロキシが発行した証明書を提示します。そのため、ChromeOS側にはインスペクションで利用するCA証明書を信頼させる設定も必要です。
一方、ChromeOSの更新や認証など、一部のGoogle通信ではTLSインスペクションによる証明書の差し替えを許容せず、通信が正常に動作しない場合があります。
ChromeOSのVerified Accessとは
Verified Accessは、ChromeOS端末が信頼できる管理端末かどうかを外部サービス側で確認する仕組みです。
たとえば、社内システムへアクセスする際に、
ChromeOS端末
↓Verified Access対応のChrome拡張機能
↓
外部サービス（ISV or 自社開発）
↓Google Verified Access API
↓端末が信頼できるか確認
↓アクセス許可 / 拒否
という流れで利用します。
Chrome拡張機能の役割
Chrome拡張機能は、Verified Accessの検証に必要な情報を端末側で取得し、外部サービスへ渡します。
実際には、Googleから受け取ったチャレンジに対してChromeOS端末側で署名し、その結果をバックエンドへ送信します。
ISV製品を使う場合と自社開発する場合
Verified Accessの仕組みは、ISV製品を使う場合でも自社開発する場合でも基本は同じです。
ISV製品を利用する場合
- Chrome拡張機能やバックエンド処理をベンダーが実装
- 利用者は製品を導入して設定する
自社開発する場合
- Chrome拡張機能を自社で開発
- バックエンドからGoogle Verified Access APIを呼び出す処理も実装する
ChromeOSでUSBメモリなどの外部ストレージの利用を制限する方法
設定箇所は以下です。
デバイス → Chrome → 設定 → ユーザーとブラウザ → ハードウェア → 外部ストレージ デバイス
認証・SSO・パスワードレス
ChromeOSログイン時のSAML認証状態をブラウザへ引き継ぐ（デバイスへのログインとサービスへのログインのSSOのイメージ）
ChromeOSでは、SAMLを利用してデバイスへログインした際の認証状態を、ログイン後のChromeブラウザのユーザーセッションへ引き継ぐことができます。
通常、ChromeOSへのログイン時のSAML認証と、ログイン後にChromeからWebサービスへアクセスする際の認証は別のセッションとして扱われます。
そこで、SAML SSO Cookieをユーザーセッションへ転送する設定を有効にします。
これにより、
ChromeOSへSAMLでログイン
→ SAMLの認証Cookieをユーザーセッションへ転送
→ Chromeから同じIdPを利用するWebサービスへアクセス
→ 再認証なしでSSO
という動作が可能になります。
ポイントは、ChromeOSへのSAMLログイン時の認証状態を、ログイン後のブラウザ利用にも引き継ぐための設定ということです。
設定方法
1. ChromeOSでSAML SSOを有効化
Google管理コンソールで、
デバイス → Chrome → 設定 → ユーザーとブラウザ
対象OUを選択し、
セキュリティ → シングル サインオン
で、
「Chrome デバイスで SAML ベースのシングル サインオンを有効にする」
を選択して保存します。
前提として、Google Workspace側でも、Entra IDなどのサードパーティIdPとのSAML SSO設定が完了している必要があります。ChromeOSでは SP起点のSAML SSOのみサポートされています。
2. SAML SSO Cookieをユーザーセッションへ転送
次に、
デバイス → Chrome → 設定 → デバイスの設定
対象OUを選択し、
ログイン設定 → シングル サインオン Cookie の動作
を開いて、
「ログイン中、ユーザー セッションへの SAML SSO Cookie の転送を有効にする」
を選択して保存します
ChromeOSでSSOプロバイダーのログイン画面を最初に表示する設定
ChromeOSでサードパーティのSSOプロバイダーを利用している場合、通常はサインイン時にいったんGoogle側でメールアドレスなどの入力を求められ、その後SSOプロバイダーの画面へリダイレクトされることがあります。
この動作を変更し、管理対象のChromeデバイスで最初からSSOプロバイダーのログイン画面を表示したい場合は、以下の設定を使用します。
シングルサインオン IdP リダイレクト
この設定を有効にすると、ChromeOSのサインイン時にGoogleのアカウント入力画面を経由せず、直接SAML IdPのログイン画面へ誘導できます。
通常の流れ：
ChromeOS → Googleログイン画面 → SSOプロバイダー
IdPリダイレクト有効時：
ChromeOS → SSOプロバイダー
＜設定画面＞
デバイス → Chrome → 設定 → デバイスの設定 → ログイン設定 → シングル サインオン ID プロバイダ（IdP）のリダイレクト
SAMLシングルサインオンの「パスワード同期フロー」とは
ChromeOSには、SAML SSOに関連する設定として「SAML シングル サインオンによるパスワード同期フロー」があります。
名前だけを見ると、IdPとChromeOSの間でパスワードを直接同期する機能のように見えますが、実際には少し意味が異なります。
パスワード同期フローの意味
この設定は、IdP側のパスワード変更などによってオンライン再認証が必要になった場合に、どの画面でIdP認証を要求するかを決める設定です。
つまり、
再認証が必要なときに、ログイン画面だけでIdP認証を出すか、ロック画面でもIdP認証を出すか
を制御します。
設定による違い
設定には主に次の2つがあります。
| 設定 | 挙動 |
|---|---|
| ログイン画面でのみオンライン ログインを強制適用する | 再認証が必要になった場合、ログイン画面でIdP認証を要求する |
| ログイン画面とロック画面でオンライン ログインを強制適用する | 再認証が必要になった場合、ログイン画面に加えてロック画面でもIdP認証を要求する |
重要なのは、常にIdP認証画面が表示されるわけではないという点です。
再認証が必要でない通常時は、ログイン画面やロック画面で毎回IdP認証画面が表示されるわけではありません。
なぜ「パスワード同期フロー」と呼ばれるのか
IdP側でパスワードを変更すると、ChromeOS端末に保存されているローカルパスワードと不一致になることがあります。
その際にIdPでオンライン再認証を行い、新しいパスワードに合わせてChromeOS側のローカルパスワードも更新します。
そのため「パスワード同期フロー」という名称になっています。
ただし、IdPとChromeOSの間でパスワードを常時同期・コピーする仕組みではありません。
設定場所
Google管理コンソールで以下の順に移動します。
［デバイス］→［Chrome］→［設定］→［ユーザーとブラウザ］→［セキュリティ］
［SAML シングル サインオンによるパスワード同期フロー］
ChromeOSでログイン時にインターネット接続を必須にする方法
ChromeOSでサードパーティのIdPを使ったSAML SSOを構成している場合、ログイン時に毎回オンライン認証を要求するよう設定できます。
設定箇所は以下です。
デバイス → Chrome → 設定 → ユーザーとブラウザ → セキュリティ → SAML シングル サインオンによるログインの頻度
この設定でオンラインログインを毎回要求するようにすると、ユーザーはログイン時にSAML IdPへアクセスする必要があります。
そのため、インターネットに接続されていない状態ではChromeOS端末にログインできなくなります。
Chrome Imprivata
IDパスワード入力を省略し、ICカードや生体認証で迅速にChrome OSへの認証・ログインを行うための仕組み。医療現場などで利用される。
Imprivata は Google 製品ではなく、Imprivata社が提供するサードパーティ製品
セットアップ
ユーザーが手動でChromeに入れるというより、管理者がGoogle管理コンソールからImprivata連携を有効化して配布する形
ChromeOSのパスワードレス化に必須？
ChromeOSをパスワードレスで利用する方法はImprivata以外にもあります。
ChromeOSで利用できる生体認証
ChromeOSでは、対応するChromebookで指紋認証を利用できます。
指紋認証は、主に端末のロック解除などに利用されます。ただし、すべてのChromebookが対応しているわけではなく、指紋センサーを搭載した対応端末が必要です。
一方、Windows Helloのような顔認証による端末ログイン・ロック解除については、Googleの現行公式ドキュメントではChromeOSの機能として確認できません。
更新・ライフサイクル・復旧
AUE
AUE は Auto Update Expiration の略です。日本語だと 自動更新の有効期限 です（一般用語というよりは、Google特有の用語）
Chromebook にはモデルごとに、「Google から ChromeOS の自動アップデートを受け取れる期限」が決まっています。その期限が AUE です。
なので、AUE を過ぎると、その端末は原則として新しい ChromeOS の機能更新やセキュリティ更新を受け取れなくなります。
Chromebookのリカバリイメージとは
ChromebookのChromeOSが壊れた場合や、正常に起動しなくなった場合にOSを復旧するためのデータです。
USBメモリなどにリカバリイメージを作成しておき、そのUSBメモリを使ってChromeOSを再インストールできます。
リカバリイメージを使用するケース
主に以下のような場合に利用します。
- ChromeOSが起動しない
- OSが破損している
- 起動を繰り返すなど正常に動作しない
- Powerwash（初期化）では復旧できない
Powerwashがユーザーデータや設定を初期化する処理なのに対し、リカバリはChromeOSそのものを再インストールする、より強力な復旧方法です。
リカバリUSBの作成方法
リカバリUSBを作成するには、**Chromebook Recovery Utility（Chromebook リカバリ ユーティリティ）**を使用します。
基本的な流れは以下です。
- Chrome ウェブストアにアクセスする
- Chromebook Recovery UtilityをChromeに追加する
- Recovery Utilityを起動する
- 復旧対象となるChromebookのモデルを指定する
- USBメモリを接続する
- 対象モデル用のリカバリイメージをUSBメモリに書き込む
Chromebook Recovery Utilityとは
Chromebook Recovery Utilityは、ChromeOSのリカバリメディアを作成するためのChrome拡張機能です。
WindowsやmacOSへ一般的なアプリケーションとしてインストールするものではなく、Chromeに追加して利用するツールという位置付けです。
作成したUSBメモリから対象のChromebookを復旧モードで起動することで、ChromeOSを再インストールできます。
Chromeブラウザ・Chrome OS のリリースチャンネルとは
ChromeブラウザやChromeOSには、安定性や新機能の提供タイミングが異なる複数のリリースチャンネルがあります。
一般的には、本番環境ではStableを利用し、BetaやDevは新機能の事前検証に利用します。
また、ChromeOSには長期安定運用向けのLTS/LTCがあります。
各チャンネルの概要
- LTS（Long-term support）
ChromeOSを長期間、機能変更を抑えて安定運用するためのチャンネル。 - LTC（Long-term support candidate）
次のLTSになるバージョンを事前検証するためのチャンネル。 - Extended Stable
Chromeブラウザの機能更新頻度を抑えて運用するためのチャンネル。 - Stable
通常の本番運用向け。 - Beta
次期Stableの新機能を事前検証するためのチャンネル。 - Dev
Betaよりも早い段階で新機能を検証するためのチャンネル。Betaより不安定。 - Canary
Chromeブラウザの非常に早い開発版。最も新しい機能を試せる一方、不安定。
ChromeブラウザとChromeOSの対応
表の上に行くほど安定運用向け、下に行くほど新機能の早期検証向けです。
| チャンネル | Chromeブラウザ | ChromeOS（管理対象） | 用途 |
|---|---|---|---|
| LTS | × | ○ | 長期安定運用 |
| LTC | × | ○ | 次期LTSの事前検証 |
| Extended Stable | ○ | × | ブラウザの更新頻度を抑える |
| Stable | ○ | ○ | 通常の本番運用 |
| Beta | ○ | ○ | 次期Stableの事前検証 |
| Dev | ○ | ○ | より早い新機能の検証 |
| Canary | ○ | × | Chromeブラウザの超早期テスト |
Chrome Trusted Tester Programとは
Chrome Trusted Tester Programは、ChromeやChromeOSの正式公開前の一部機能を、限定された組織やユーザーが先行して評価するための仕組みです。
リリースチャンネルとの違い
Trusted Tester Programは、Beta・Dev・Canaryのようなリリースチャンネルではありません。
リリースチャンネルがChromeやChromeOS全体の先行バージョンを利用する仕組みであるのに対し、Trusted Tester Programでは、Googleが指定した特定の未公開機能を先行して利用します。
そのため、
リリースチャンネル：製品全体を先行版にする
Trusted Tester Program：特定機能だけを先行して試す
という違いがあります。
どのような機能を試せるのか
対象機能は時期によって異なりますが、たとえば次のような機能が対象になることがあります。
- 新しいAI機能
- 新しいセキュリティ機能
- 新しいChrome管理ポリシー
- デバイス管理機能
- テレメトリやレポート機能
たとえば、正式公開前の新しい管理機能を一部の検証ユーザーだけで試し、自社環境への影響を事前に確認するといった使い方ができます。
他、補足
beta、Dev、Canaryを利用するために、Trusted Tester Programへ参加する必要はありません（Trusted Tester Programは、通常のリリースチャンネルとは別軸で、特定の未公開機能を先行評価するためのプログラムです。）
ブラックアウト ウィンドウとは
ブラックアウト ウィンドウとは、システムの変更やアップデートなどを実施しない期間を指定する考え方です。
ChromeOSに限った用語ではなく、IT運用全般で使われる一般的な表現です。
ChromeOSでは、自動アップデートを適用しない期間を設定する目的で利用されます。
たとえば、繁忙期や決算期など、アップデートによる再起動や不具合の影響を避けたい期間に設定します。
ChromeOSアップデート後に端末を強制再起動する方法
ChromeOSでは、アップデート適用後に一定時間が経過したら、端末を自動的に再起動させることができます。
設定箇所は以下です。
デバイス → Chrome → 設定 → ユーザーとブラウザ → Chrome の更新 → 再起動通知
「再起動通知」で、一定期間が経過したら自動的に再起動する設定を有効にし、再起動までの時間を指定します。
これにより、ユーザーが再起動しなかった場合でも、一定時間後に再起動させ、ChromeOSのアップデートを確実に適用できます。
アップデートとは関係なくChromeOS端末を再起動する方法
管理者は、Google 管理コンソールから特定のChromeOS端末を任意のタイミングで再起動することもできます。
設定箇所は以下です。
デバイス → Chrome → デバイス → 対象端末を選択 → 再起動
これはアップデート後の再起動ポリシーとは異なり、管理者が必要なタイミングで個別のChromeOS端末へ再起動コマンドを送信する機能です。
ChromeOS 113以降の管理対象端末で利用できます。
WindowsやmacOSなどもGoogle 管理コンソールから再起動できるのか
Google 管理コンソールから端末そのものをリモート再起動する機能は、基本的にChromeOS向けです。
Windows、macOS、Linuxについては、Google 管理コンソールでは主にChromeブラウザやChromeプロファイル、各種ポリシーを管理します。ChromeOSと同じように、OS端末そのものを管理コンソールから再起動する機能ではありません。
WindowsやmacOSなどを遠隔で再起動したい場合は、Microsoft IntuneなどのMDMやRMM製品を利用します。
端末機能・運用管理
ChromeOSデバイスへのリモート接続
Google Workspace / Chrome Enterprise の管理者は、Google 管理コンソールから管理対象のChromeOSデバイスへリモート接続できます。
主に、端末のトラブルシューティングやリモートサポートに利用します。
接続方法
管理コンソールで以下の順に開きます。
デバイス → Chrome → デバイス → 対象デバイス → リモート デスクトップ
その後、以下のいずれかのセッションを開始します。
| 種類 | 用途 | 特徴 |
|---|---|---|
| 共有セッション | ユーザーが利用中の端末をサポート | ユーザーと管理者の両方が画面を確認できる |
| 非公開セッション | 無人端末などを管理 | 管理者だけが画面を確認できる |
共有セッション
ユーザーが利用中のChromeOSデバイスに接続する方法です。
基本的にはユーザーの承認を受けて接続し、管理者とユーザーが同じ画面を見ながらトラブルシューティングできます。
非公開セッション
ChromeOS 132以降で利用できる機能です。
ユーザーがログインしていないデバイスに管理者だけで接続でき、端末側のユーザーにはリモート画面は表示されません。
利用するには、管理コンソールで「企業の管理者からのリモート アクセス接続を許可する」設定を有効にします。
ChromeOSのキオスクモード
キオスクモードとは、ChromeOSデバイスを特定用途専用の端末として動作させるモードです。
通常のChromebookではユーザーがログインして複数のアプリや設定を利用できますが、キオスクモードでは指定したアプリやWebアプリを自動起動し、基本的にその用途だけで利用させます。
デジタルサイネージ、受付端末、店舗端末などで利用されます。
設定方法
Google管理コンソールで以下を開きます。
デバイス → Chrome → アプリと拡張機能 → キオスク
キオスクで利用するアプリを追加し、**［自動起動するアプリ］**に指定します。
端末を起動すると、ユーザーが通常のログイン操作を行わずに、指定したアプリが自動的に起動します。
ChromeOSで利用できるアプリの種類
ChromeOSでは、主に次のようなアプリを利用できます。
- Webアプリ / PWA
- Androidアプリ
- Linuxアプリ
Webアプリ・PWA
Chromeブラウザ上で動作するWebアプリを利用できます。
また、PWA（Progressive Web App）に対応したサービスでは、Webアプリを端末にインストールし、通常のアプリのように独立したウィンドウで利用することもできます。
Androidアプリ
対応しているChromebookでは、Google PlayからAndroidアプリをインストールして利用できます。
スマートフォンやタブレット向けのAndroidアプリを、ChromeOS上でアプリとして動作させることができます。
Linuxアプリ
ChromeOSでは「Linux開発環境」を有効にすることで、Linuxアプリを利用できます。
この仕組みは一般に Crostini と呼ばれます。
ChromeOS自体もLinuxカーネルをベースにしていますが、LinuxアプリをChromeOS上でそのまま直接実行しているわけではありません。
イメージとしては、
ChromeOS
→ Linux用の分離された実行環境
→ Linuxアプリ
という構成です。
つまり、
「ChromeOS ＝ LinuxデスクトップOS」
というわけではなく、ChromeOSとは別にLinuxアプリを動かすための環境を用意して、その中でLinuxアプリを実行すると理解すると分かりやすいです。
ChromeOSで利用できるプリンターを管理者が設定する方法
Google 管理コンソールでは、ChromeOSで利用するプリンターを、特定の組織部門やグループに割り当てることができます。
たとえば、財務部門専用のプリンターを財務チームのユーザーだけに利用させる、といった設定が可能です。
設定箇所は以下です。
管理コンソール → デバイス → Chrome → プリンタ → プリンタ
ここで対象の組織部門またはグループを選択し、利用させたいプリンターを追加・許可します。
設定すると、対象ユーザーのChromeOS端末でそのプリンターが利用可能になります。
ChromeOSのドライバーレス印刷
ChromeOSでは、対応プリンターであれば、専用のプリンタードライバーを個別にインストールしなくても印刷できます。
このドライバーレス印刷では、主に次の仕組みが関係します。
- CUPS：ChromeOS側で印刷ジョブを管理する仕組み
- IPP / IPP Everywhere：ChromeOSとプリンターが通信するための仕組み
つまり、
CUPSでChromeOSが印刷を管理し、IPP / IPP Everywhereを使ってプリンターと通信する
という構成です。
なお、古いプリンターや特殊な機能を利用する場合は、PPDファイルなどの追加設定が必要になることがあります。
（補足）Windowsの場合
Windowsでは、従来はプリンターごとにメーカー製のプリンタードライバーをインストールして利用する方式が一般的でした。
一方、現在のWindowsでは、IPP などの標準的な仕組みを利用したドライバーレス印刷も可能です。
ChromeOS端末のリモートログを取得する方法
ChromeOSでは、Google管理コンソールから対象デバイスのログをリモートで取得できます。
事前設定
リモートログを取得するには、あらかじめ管理コンソールで「デバイスのシステムログのアップロード」を有効にしておく必要があります。
設定場所は、以下です。
［デバイス］→［Chrome］→［設定］→［デバイスの設定］→［ユーザーとデバイスのレポート］→［デバイスのシステムログのアップロード］
ログの取得方法
事前設定を有効にしたうえで、管理コンソールから対象のChromeOSデバイスを開き、デバイスの詳細画面で「ログをキャプチャ」を実行します。
コメント