「Chromeに追加」をクリックしても、拡張機能はインストールされず、小さなグレーのダイアログが表示されます。「この拡張機能は組織の管理者によってブロックされています」。それ以上の説明はなく、次に押すべきボタンも見当たりません。ただブロックされているだけです。
このメッセージには具体的な意味があり、「永遠にダメ」という意味ではありません。実際に何が起きているのか、あなたが申請したときにIT部門には何が見えているのか、そしてブロックされた拡張機能を承認済みへと動かす実際の方法を解説します。
ブロックの正体
Chrome自体は、どの拡張機能が安全かについて独自の判断を持っていません。管理対象デバイス——会社のChrome EnterpriseやGoogle Workspace管理コンソールに登録されたデバイス——では、すべての拡張機能の権限はChrome自身ではなく、IT部門が設定したポリシーによって管理されています。
具体的なポリシーは、ほぼ必ずデフォルト拒否リストの一種です。*(すべてブロック)を指定したExtensionInstallBlocklistと、例外的に許可する拡張機能を列挙したExtensionInstallAllowlistの組み合わせです。新しい環境ではこれを1つのExtensionSettingsポリシーにまとめていますが、ロジックは同じです——明示的に名前を挙げられていない限り、何も許可されません。あなたの拡張機能がそのリストになければ、Chromeは権限の確認画面すら出さずにブロックします。だからこそ、インストールのプロンプトなしに、あのダイアログが即座に表示されるのです。
つまり、このブロックはあなたの拡張機能そのものが問題視されているわけではありません。まだレビューされていないものをすべて一括して引っかける、包括的なデフォルト設定であり、そこには仕事で使ってまったく問題のない拡張機能も含まれています。
申請フローの実際の仕組み
組織側でリクエストのワークフローが有効になっていれば——まさにこの状況に対処する標準的な方法なので、たいていの管理対象Chrome環境では有効になっています——管理対象プロファイルでサインインした状態のChrome ウェブストアには、「Chromeに追加」の代わりにリクエストボタンが表示されます。
クリックしても何もインストールされません。リクエストはGoogle 管理コンソールに送られ、権限を持つ管理者がそれを承認・却下、あるいは組織全体(またはあなただけ)に自動インストールできます。管理者が対応すると、Chromeの通知が届きます——フォローアップのメールは必須ではありませんが、リクエストがキューに滞留することもあるため、多くの人は念のため送っています。
管理者がそのリクエストを開くと、拡張機能が宣言している権限、ホストアクセスの範囲、そして——現在のほとんどのWorkspace/Chrome Enterprise環境では——自動リスクスコアが表示されます。このスコアリングを行っているのがSpin.AIの拡張機能リスク評価ツールで、以前この役割を担っていたCRXcavatorがサービスを終了した後、Googleが管理コンソールに直接統合したものです。権限の範囲、コードの挙動、評判に関するシグナルを横断的にスコア化し、リスクスコアが高いだけで、管理者がそれ以上深追いせずに却下するには十分な材料になることも珍しくありません。
承認されやすいリクエストの条件
ここは推測するしかないブラックボックスではありません。拡張機能を本当の意味で安全にする要素は、そのまま承認を得やすくする要素でもあります。
- 説明のつく、狭い権限セット。
bookmarksとstorageだけを求める拡張機能は、判断が容易です。そこに<all_urls>、tabs、history、cookiesまで加わると、管理者は自分が使わないかもしれない機能のために、はるかに大きな影響範囲を正当化しなければならなくなります。 - 説明のつかないホストアクセスがないこと。 拡張機能がリモートサーバーと通信する場合、誠実なリクエストはその理由——同期、ライセンス認証、特定の連携機能など——を説明します。「とにかく信用してください」ではすみません。
- 単一の、明言された目的。 関係のない機能を詰め込んだ拡張機能(広告ブロックやタイピング速度の計測までこなすブックマーク管理ツールなど)は、1つのことだけをする拡張機能に比べて承認が難しくなります。
- 管理者が文書に残せる理由。 「時間の節約になる」というのは本当ですが、漠然としています。「これまで使っていた、同じく未レビューだった3つの別々のツールを1つに置き換える」であれば、誰かに聞かれたときに管理者が上に説明できるリクエストになります。
自分でリクエストを送る側なら、組織のフローでノートを添えられる場合は、実際に必要な理由を書いておきましょう。管理者は推測せずに済むほど、承認を早く出せます。
IT部門にNoと言われたら、それがNoです
これははっきり言っておく価値があります。管理者がリクエストを却下したら、そのデバイスに関してはそこで終わりです。管理対象拡張機能のポリシーを無効化する方法、サイドロードで回避する方法、「バイパス」ツールを探すことはグレーゾーンではありません——雇用主が所有するハードウェア上で、雇用主が意図的に設置したセキュリティ制御を覆す行為です。しかも、それを手助けすると謳うガイドの多くは、実際には解決策どころかマルウェアのリスクそのものです。この記事ではそうした方法をいっさい取り上げませんし、あなたもそれを教えてくれるサイトを探すべきではありません。
そのツールが本当に役立つのに、会社が承認してくれない場合、誠実な選択肢は次の2つです。個人用のChromeプロファイルで使う(多くの人はすでに仕事用とは別のプロファイルを持っています)、または管理対象マシンを必要としない作業については個人のデバイスで使う。これは回避策ではなく、実際の制約です。IT部門の判断が変わるまでは、業務時間外専用のツールになる場合もあるということです。
個人としてリクエストする側ではなく、チーム環境向けに拡張機能を構築・評価する立場であれば、セキュリティ担当者が広く承認する前に何を確認したいのかをまとめた姉妹記事を書いています。IT・セキュリティチーム向けSecond Bookmark Barでは、権限テーブル、デバイスから出ていくデータとそのタイミング、そして個人開発のツールとエンタープライズベンダー製品との正直なギャップを解説しています。