チームブラウザーを評価するための実践チェックリスト

料金ページを開く前に判断を定義する

有用な評価は、ベンダー一覧ではなく業務から始まります。次を書き出してください。

• 承認済みの業務と、それを許可するシステム。
• 人数、保存プロファイル数、同期プロファイル数、同時ブラウザーセッション数。
• 対応するOSとプロセッサアーキテクチャ。
• 必要なブラウザーエンジン、拡張機能、プロキシ、IDプロバイダー、自動化クライアント。
• データ所在地、保存、エクスポート、削除、監査の義務。
• 復旧時間と許容データ損失。
• 担当者と管理者のアクセシビリティ要件。
• 予算、請求期間、サポート範囲、移行条件。
• 製品がチームに許可してはならない禁止業務。

リソースの種類を分けてください。保存プロファイル500件、クラウド同期プロファイル100件、5シート、同時セッション10件のプランは、チームの同時セッション500件を提供するわけではありません。すべての上限を、実際の業務が消費する単位へ変換します。

次に、妥協できないゲートを特定します。一般的なゲート群は次のとおりです。

1. 対応中で最新のブラウザービルド。
2. プロファイルの密かな破損または同時書き込みがない。
3. 取消可能な最小権限アクセスを持つ個人別ID。
4. 通常ログまたは自動化出力に生の秘密情報がない。
5. 利用可能な監査の根拠。
6. テスト済みの復元および移行経路。
7. 適用されるサービス規約に沿った適法で承認済みの利用。

不合格のゲートを数値スコアの平均に入れないでください。洗練されたインターフェースで、未検証のアップデーターや状態を失う復元手順を補うことはできません。

単純な根拠尺度を使う

チェック項目ごとに、結果と、得られた最も強い根拠の両方を記録します。

結果

• 合格： 定義したテスト環境で要件を実証した。
• 懸念： 動作が要件と矛盾する、または重大なトレードオフを生む。
• 未確認： 根拠がない、利用不能、古い、または判断するには曖昧すぎる。
• 対象外： 業務に本当に適用されず、その理由を記録した。

根拠

1. 公開された主張： マーケティングまたは営業資料。
2. 技術文書： バージョン付きの製品、セキュリティ、API、サポート文書。
3. 観察した実演： 自分たちのシナリオを使うベンダーのライブ実演。
4. 管理された試用： チームが使い捨てデータで動作を再現し、バージョンと結果を記録。
5. 独立または契約上の根拠： 要件を対象とする範囲明示の評価、署名済み確約、サポート条件。

どの場合も、数字が大きい根拠が自動的に優れるわけではありません。独立報告がデスクトップブラウザーを除外する一方、管理された試用が直接その動作を確認する場合があります。各成果物の対象範囲、日付、バージョン、限界を記録してください。

1. 製品状態と主張の境界

• □ 必要なすべてのプラットフォームとアーキテクチャ向けに、実際にインストールできるビルドがあるか。
• □ 現在のアプリケーションバージョン、ブラウザーバージョン、リリース日をベンダーが特定できるか。
• □ ベータ、プレビュー、実験的、一般提供の各機能が分けて表示されているか。
• □ 文書と実際の試用で、上限と動作が一致するか。
• □ セキュリティ、可用性、暗号化、性能の主張が、特定の要素と根拠に範囲を限定しているか。
• □ 既知の制限、未対応業務、サポート終了規則が公開されているか。
• □ 見えなくなること、アカウントの維持、第三者サービスへのアクセスをベンダーが保証していないか。

評価日に、インストーラー、バージョン画面、リリースノート、関連文書を取得します。安定した参照先のない営業回答は、検証済み動作ではなく公開された主張のままです。

2. プロファイルの分離と完全性

まず、製品が何をプロファイルと呼ぶか定義します。永続ブラウザーデータディレクトリ、一時ブラウザーコンテキスト、同期アーカイブ、遠隔セッション、設定の集合を指す場合があります。これらは同等ではありません。

Chromiumは、ユーザーデータディレクトリを利用者データの場所として文書化し、独自ディレクトリの選択方法を説明しています。また、二つの実行中インスタンスが一つのディレクトリを共有できない場合があると述べています。上流のユーザーデータディレクトリ文書を出発点にし、その後で製品固有の根拠を求めてください。

• □ 各永続プロファイルに、明確に定義されたストレージとプロセスの境界があるか。
• □ 同じ変更可能なプロファイル状態を二人が開いて書き込むことを製品が防ぐか。
• □ Cookie、ストレージ、キャッシュ、履歴、拡張機能、ダウンロード、権限、設定が文書どおり分離されるか。
• □ 一時セッションと永続プロファイルが区別して表示されるか。
• □ クリーンな起動が意図したプロファイルデータだけを使うか。
• □ 再起動後、製品が保持すると約束する状態だけを正確に保持するか。
• □ 拡張機能の権限とインストール元を管理できるか。
• □ プロファイルのインポートを信頼できない入力として扱い、利用前に検証するか。
• □ 破損または互換性のないプロファイルを、正常コピーを上書きせず隔離できるか。

試用の根拠にはプロファイル間テストを含めます。プロファイルAに無害な目印を設定し、Bに存在しないことを確認し、両方を再起動し、アプリケーション更新後に繰り返します。使い捨てアカウントと合成データを使ってください。

3. ブラウザーの鮮度、サンドボックス、更新

ブラウザーは継続的に保守されるセキュリティ依存要素です。Chromiumの現行チャンネル文書では、Stableに小規模更新が毎週、メジャー更新が4週間ごとに提供されると説明しています。このリリース頻度がベンダーの正確なサービス水準を決めるわけではありませんが、バージョンと更新の根拠がなければ「Chromiumベース」という説明が不完全である理由を示します。

• □ 製品のブラウザービルドを、正確な上流バージョンへ対応づけられるか。
• □ 上流のセキュリティ更新を取り込む目標または履歴が公開されているか。
• □ 上流リリースと緊急修正を誰が監視するか。
• □ アプリケーションとブラウザーの更新が、ダウンロード接続とは独立して署名・認証されるか。
• □ 成果物のダイジェスト、リリース来歴、同等の流通過程を検証できるか。
• □ ロールアウトが段階化され、監視でき、停止できるか。
• □ 現行セキュリティポリシーでは安全でない版へ戻すロールバックを防ぐか。
• □ 対応するアップグレードとダウングレード経路で、プロファイルスキーマ移行をテストしているか。
• □ 通常動作でブラウザーサンドボックスを有効に保つか。
• □ サンドボックス外または高権限プロセスと、その必要性をベンダーが説明できるか。

Chromiumは、サンドボックスを信頼できないコードを制限する境界と説明し、サンドボックス内コードとその管理側の両方に最小権限を適用します。Chromium sandbox designを確認し、その後でベンダーに実際の本番構成を示してもらいます。「Chromiumを使用」という記述だけでは、上流のすべての緩和策が有効なままだと証明できません。

更新の完全性について、The Update Frameworkは、リポジトリと署名鍵の侵害を明示的に扱うため有用な参考です。SLSA provenanceは、成果物がどこで、いつ、どう生成されたかについて、検証可能な情報を定義します。ベンダーがこれらのプロジェクトを必ず使う必要はありませんが、成果物の識別、鍵の侵害、ロールバック、凍結、ビルド来歴を設計でどう扱うか説明すべきです。

4. ID、端末、最小権限

NIST SP 800-53 Rev. 5は、アクセス制御、監査、認証、緊急時対応計画、インシデント対応、サプライチェーンリスクの各管理策を整理しています。フレームワークとの整合を実装の証明とはせず、確認項目の発想に使ってください。

• □ 共有チームログインではなく、全員に個別IDを与えるか。
• □ 管理者などの機密ロールに多要素認証を提供し、強制できるか。
• □ リスクに応じて、より強いフィッシング耐性のある認証を利用できるか。
• □ 必要な場合、製品の認可を迂回せずIDプロバイダーと連携できるか。
• □ 表示、起動、編集、共有、エクスポート、削除、請求、管理を分けられる十分なロール粒度があるか。
• □ 組織、ワークスペース、フォルダー、明示的なプロファイル群へアクセスを限定できるか。
• □ 端末、セッション、利用者、サービス認証情報、招待を速やかに失効できるか。
• □ サービスアカウントに独自ID、期限、スコープ、処理量上限があるか。
• □ 権限変更と認可失敗が監査記録に見えるか。
• □ 共有パスワードを変更せずに、オフボーディングでアクセスを削除できるか。

現行の認証用語と保証指針は、2025年7月31日に確定したNIST SP 800-63B-4を参照してください。Webサイトログイン、デスクトップロック解除、ローカルAPI、クラウドAPI、復旧、サポートアクセスでは異なる仕組みを使う場合があるため、ベンダーの認証主張が製品のどの部分を対象とするか確認します。

5. 機密データと信頼境界

製品をデータフローとして描きます。デスクトップ管理ツール、ブラウザープロセス、ローカルサービス、クラウドコントロールプレーン、同期ストレージ、アップデーター、クラッシュレポーター、サポートツール、第三者連携を記入します。各境界で、何が、なぜ通るか確認してください。

• □ どのプロファイル内容が標準でローカルに留まるか。
• □ 同期を有効にすると、どのメタデータと機密内容をアップロードするか。
• □ どこで暗号化し、どの関係者が復号鍵を取得できるか。
• □ ローカル鍵をどう保護、バックアップ、ローテーション、復旧するか。
• □ 組織管理者、ベンダーサポート、インフラ担当者、自動化クライアントは何を読めるか。
• □ Cookie、パスワード、プロキシ認証情報、二要素認証の機密情報、暗号鍵を通常UI、ログ、テレメトリー、API、エージェント出力から除外するか。
• □ クラッシュレポートと診断を事前確認でき、編集して隠し、同意を考慮し、保存期間を制限できるか。
• □ 生のプロファイルアーカイブや認証情報を求めずにサポートできるか。
• □ インポートする拡張機能、アーカイブ、ブラウザーダウンロード、更新メタデータを信頼できないものとして扱うか。
• □ ローカルコピー、クラウドオブジェクト、バックアップ、ログ、サポート成果物にまたがる削除を定義しているか。

「暗号化」という言葉だけを完全な回答として受け入れないでください。データ区分、場所、暗号化境界、鍵の保持者、復旧経路、平文が存在する場合を記録します。

6. 共同作業と監査可能性

• □ 割り当てと引き継ぎの間も、プロファイル所有者が明確か。
• □ 同時編集を防ぐ、または目に見える形で解決できるか。
• □ 招待、ロール変更、起動、停止、共有、エクスポート、削除、自動化呼び出し、復旧操作を記録するか。
• □ 各イベントが、人間の実行者、委任ワークロード、リソース、時刻、判断、結果を識別するか。
• □ 重要な構成変更について、秘密情報を隠しながら変更前後の値を記録するか。
• □ 時計、タイムゾーン、イベント順序、要求識別子が曖昧でないか。
• □ 監査へのアクセス、エクスポート形式、保存、削除の管理が文書化されているか。
• □ 管理者が、その管理者自身を確認する記録を変更または削除できるか。
• □ チームの監視または調査システムへログをエクスポートできるか。
• □ 監査先が利用不能な場合も、ログ記録を継続、安全にバッファ、または安全側に失敗できるか。

OWASPのログ記録ガイダンスは、認可失敗と高リスク操作を記録し、いつ、どこで、誰が、何を行ったかを捉え、ログアクセスを管理し、技術的秘密情報を避けることを推奨しています。セキュリティページのスクリーンショットだけでなく、実際にエクスポートした製品イベントへこの確認を適用してください。

7. 復旧、中断、移行

復元をテストするまで、バックアップの主張は不完全です。NIST Cybersecurity Framework 2.0には、バックアップの作成、保護、維持、テストと、復元成果物および復元済みシステムの検証に関する成果が含まれます。

• □ プロファイルロックを尊重しながら、一貫したバックアップを作れるか。
• □ ローカル版と同期版を識別し、順序づけられるか。
• □ 現在のコピーを破壊せず、選択した版を復元できるか。
• □ 通常利用を再開する前に、復元データとブラウザーの互換性を検証するか。
• □ ブラウザープロセス強制終了、ネットワーク喪失、ディスク満杯、アップロード中断、アプリケーションクラッシュ後に何が起こるか。
• □ 修復失敗から最終正常版を保護するか。
• □ 唯一の復旧経路を失わず、失効済みまたは紛失端末を削除できるか。
• □ 復旧鍵またはコードを、偶発的紛失と無制限な管理者アクセスの両方から保護するか。
• □ 文書化済み形式でデータをエクスポートし、サービス解約前に検証できるか。
• □ 残る保存範囲を明示した、対応済みの削除およびアカウント終了手順があるか。

ベンダーと変更手順が本番演習を明示的に認めない限り、復旧テストには使い捨ての試用データだけを使います。復旧時間、失った状態、手作業、警告、製品バージョンを記録してください。一つの小さなプロファイルで実演に成功しても、本番規模の性能または完全性を確立しません。

8. 自動化と開発者向け管理

• □ 無制限なファイルシステムまたはプロセスアクセスではなく、バージョン付きドメイン操作を公開するか。
• □ API、CLI、SDK、Playwright、CDP、WebDriver、Webhook、エージェントの機能を別々に文書化しているか。
• □ 正確なブラウザーとクライアントの互換性表があるか。
• □ 認証情報をテナント、プロファイル、操作、対象、期限、処理量、費用で制限できるか。
• □ 破壊的、一括、外部から見える、秘密情報を伴う、費用が発生する操作に、強いポリシーまたは承認を求めるか。
• □ プレビューを実行する正確な要求へ結びつけるか。
• □ 変更コマンドが冪等か、または不明な結果を明示するか。
• □ 長時間操作をキャンセルし、安全に再開できるか。
• □ 実行中のジョブにも失効が反映されるか。
• □ 自動化の判断を、人による操作と同じ監査記録で追跡できるか。
• □ 生のセッション状態を返さず、通常の自動化出力を有用に保てるか。
• □ 秘密情報を漏らさず復旧できるだけ具体的なエラーメッセージか。

拒否経路をテストします。読取専用トークンでプロファイルを起動できてはいけません。プロファイル範囲のトークンは別フォルダーに対して失敗する必要があります。期限切れ認証情報を、より広いアクセスへ密かに更新してはいけません。エージェントが拒否された呼び出しを書き換えて、管理者承認へ変換できてはいけません。

9. 担当者の体験とアクセシビリティ

• □ キーボード利用者がすべてのコントロール、ダイアログ、表、メニュー、プロファイル操作へ移動し、操作し、離れられるか。
• □ ページ移動、エラー、モーダル変更後もフォーカスが見え、論理的な順序になるか。
• □ ラベル、エラー、状態変更、破壊的操作の確認がスクリーンリーダーで機能するか。
• □ ズーム時と文字サイズ拡大時もインターフェースを利用できるか。
• □ 色、動き、時間制限を調整できるか、重要情報に不可欠でないか。
• □ 色だけに依存せず、選択中の組織、プロファイル、プロキシ、環境、リスク状態を区別できるか。
• □ アクセシブルでない密集表を強制せず、一括操作を確認できるか。
• □ ネイティブプラットフォーム動作、通知、ファイル選択、認証情報画面、更新画面が一貫して機能するか。

WCAG 2.2は、キーボード操作、フォーカス順、フォーカス表示、ターゲットサイズ、エラー識別、アクセシブルな認証など、テスト可能なWebコンテンツ基準を提供します。デスクトップ製品はネイティブとWebのインターフェースを含む場合があるため、関連する基準の確認と、対応OSごとの支援技術テストを組み合わせます。

10. 商用および運用上の適合性

• □ シート、保存プロファイル、同期プロファイル、ストレージ、通信量、同時セッション、API処理量、自動化ワーカー、サポート水準の料金を明確に分けているか。
• □ どの上限が強制停止、超過料金、フェアユース条件か。
• □ 管理者の承認なしに請求または容量が変わり得るか。
• □ 対応するプロキシプロトコル、認証方式、拡張機能、ネットワーク環境を文書化しているか。
• □ サポート方針が、ブラウザー更新事象、プロファイル破損、復元失敗、セキュリティ報告、アカウント復旧を対象にするか。
• □ サービス状況、インシデント連絡、エスカレーション経路が実在し監視されているか。
• □ 契約が、データ返却、削除、料金変更、停止、終了を定義しているか。
• □ 安全な移行を証明する根拠を失わずにサービスから離れられるか。

最大同時業務量、想定同期状態、自動化量、サポート要件で費用を計算します。税、年間契約、超過、移行作業を記録してください。各料金ページで最大のプロファイル数だけを比較しないでください。

管理された試用計画

評価用に作ったテストアカウント、合成認証情報、プロファイルを使います。試用を現実的に見せるため、本番Cookieをインポートしないでください。

1. 環境を記録する。 アプリとブラウザーのバージョン、OS、ハードウェア、ネットワーク、プロキシ種別、拡張機能群、アカウントプラン、テスト日を記録する。
2. 二つのロールと複数プロファイルを作る。 管理者、制限された担当者、別フォルダー、担当者がアクセスしてはならないプロファイルを少なくとも一つ含める。
3. 通常業務を実行する。 プロファイルを起動、利用、停止、引き継ぎ、再起動し、期待状態と実際の状態を記録する。
4. 拒否を実行する。 制限されたIDで対象外プロファイル、エクスポート、ロール変更、自動化コマンドを試す。
5. 中断を実行する。 使い捨てデータで、ベンダーが対応する、または安全な方法により、ブラウザー停止または同期手順を中断し、復旧経路を確認する。
6. 復元して比較する。 既知のスナップショットを新しいコピーへ復元し、完全性を確認し、受入完了まで現在のコピーを残す。
7. アクセスを失効する。 利用者、端末、セッション、サービス認証情報を削除し、UIとAPIの両方で拒否を確認し、監査イベントを調べる。
8. 可搬性を確認する。 許可されたデータをエクスポートし、文書化済み形式を調べ、対応している場合は使い捨ての移行先へ再インポートし、省略項目を特定する。
9. アクセシビリティを確認する。 必要な各プラットフォームで、キーボードと関連支援技術を使って中心業務を完了する。
10. 費用と主張を照合する。 観察したリソース利用とサポート応答を、提案書および契約と比較する。

判断記録のテンプレート

要件	優先度	結果	根拠と日付	制限またはリスク	担当者と次の操作
例：担当者がセッション状態をエクスポートできない	ゲート	合格	管理された試用、バージョンX、YYYY-MM-DD	APIのみ。CLIは未テスト	セキュリティ責任者がCLIをテスト

評価の最後に、次の四つを明示的に列挙します。

• 十分な根拠で合格したゲート。
• 名前を明示した責任者と確認日を伴って受容した懸念。
• 未確認のまま残る項目。
• 新しいブラウザーエンジン、IDプロバイダー、アップデーター、料金モデル、プロファイル形式など、再評価を開始する条件。

一般的な警戒項目

次の場合は判断を停止します。

• ブラウザーバージョンを特定できない。
• 通常利用にサンドボックスの無効化が必要。
• 管理者と自動化が一つの恒久的認証情報を共有。
• チームでの引き継ぎに、生のCookieまたはパスワード共有へ依存。
• UIが保護すると主張する秘密情報をAPIがエクスポート可能。
• 監査イベントに実行者がなく、エクスポートできない。
• 「バックアップ」がクラウドコピーの存在だけを意味し、復元実演がない。
• 中断された書き込みまたは同じプロファイルへの同時アクセスをベンダーが説明できない。
• アクセシブルでない重要業務に代替手段がない。
• セキュリティ報告に、通常メールで秘密情報を送る必要がある。
• 製品が検出不能、保証されたアカウントアクセス、プラットフォーム制御の回避を約束する。

「未確認」は非難ではありません。根拠が不足していることを正確に表すものです。ベンダーが根拠を示す、チームが動作をテストする、判断責任者がリスクを受容するまで、見える状態に保ってください。