責務を小さくできる
「この画面で、この操作だけを支援する」と決められます。巨大な業務システム全体をAIに理解させるより、実装の対象を狭くできます。
01 · WHY AN EXTENSION
今の業務を変えずに、
小さな改善を追加する。
Chrome Extensionなら、既存のWebサービスを作り替えることなく、その画面に小さな機能を追加できます。
そして現在は、AIを使うことで、こうした小さなソフトウェアを以前より作りやすくなっています。
- 01 小さく作る。
- 02 人が確認する。
- 03 ブラウザで使う。
この3つの順番が、このページで説明する考え方のすべてです。順番を入れ替えると、別の話になります。
02 · 人とWebサービスのあいだ
Chrome Extensionは、人とWebサービスのあいだに入る。
Webサービスは、そのサービスの都合で作られています。あなたの職場にだけ必要な一手間を、サービス側に足してもらうことは、ふつうはできません。
Chrome拡張は、その画面を作り替えるのではなく、あなたのブラウザの中に置かれます。表示されているページの上に、確認や整形のための小さな機能を重ねる形になります。
人
書く、貼り付ける、添付する、送信する。判断するのはここ。
ブラウザ（拡張が動く場所）
拡張が入るのはここ。表示中のページの上に、機能を重ねる。
Webサービス
そのまま。改修も、設定変更も、移行も必要としない。
拡張が動くのは、あなたのブラウザの中です。サービス側に手を入れているわけではありません。
そのかわり、できることはブラウザの中に限られます。サービス側のデータそのものを書き換える、基幹の処理を置き換える、といった要件には向きません。
03 · AI × EXTENSION
AIで作る“小さなソフトウェア”と、Chrome Extensionは相性がいい。
AIによって、ソフトウェアを書くコストは大きく下がりつつあります。
しかし、「何でもできる大きなシステム」をAIに丸ごと作らせることが最適とは限りません。任せる範囲が広いほど、あとで確認しなければならない範囲も広がります。
むしろ、次のような条件がそろった小さなソフトウェアのほうが、AI開発との相性がよい。
- 目的が一つであること
- 対象になる画面が明確であること
- 入力と出力が小さいこと
- 必要な権限が明確であること
- 動作を人間が確認できること
Chrome Extensionは、この条件を作りやすい形です。1つの画面で、1つの操作を助ける。それだけを実装すれば、道具として成り立ちます。
これは「AIを使えば誰でも簡単に拡張を作れる」という話ではありません。書く量が減るぶん、何を作るか・公開してよいかを判断する仕事が残ります。相性がよいのは、その判断の対象を小さく保てるからです。
04 · DEVELOPMENT LOOP
AIで生成し、人が確認してから使う。
実際の流れは一本道ではなく、短いループになります。そしてこのループには、自動化しない段が一つあります。
AI が引き受ける
業務上の小さな困りごと
「この画面で、毎回これを確認している」。一文で書けるところまで絞る。
AI Agent / AI Coding
一度に全部ではなく、機能を分けて小さく実装させる。
小さなChrome Extension
1つの目的、1つの画面。この時点では、まだ動くだけのもの。
権限・コード・動作を確認する（人／仕組み）
生成されたものが、そのまま使われる図にはしません。ここを通ってから先へ進みます。
- manifestの権限
- 外部通信の有無
- 保存先
- 実機での挙動
人が使う
Chromeで利用
いつものブラウザの、いつもの画面で使う。手順は基本的に変えない。
フィードバック
使って初めて分かる違和感。多くは、コードを読んでも出てこない。
改善
直す範囲が小さいので、直すかどうかの判断も軽い。
改善したら、また困りごとの定義に戻る。ここが一周する速さが、この作り方の利点です。
この図で大事なのは、書いていないことのほうです。「AIが全部を自動で、安全に作る」とは書いていません。生成と利用のあいだには、人が見る段があります。
なぜ、この形がAI開発と噛み合うのか
ブラウザが実行環境になる
ブラウザの中で完結する機能なら、別途大きなサーバー基盤を用意しなくても実現できます。すべての要件がそうなるわけではありません。
権限が見える
Chrome拡張はmanifestで必要な権限を宣言します。AIが書いたコードに対して「何にアクセスするのか」を確認する、一つの境界として使えます。
動きを確認しやすい
入力、クリック、コピー、送信。対象になる操作が比較的はっきりしているので、実際のブラウザで自分で触って確かめられます。
小さく改善できる
一度で巨大なものを完成させるのではなく、作る→使う→困る→直す、という短い周期を回せます。
05 · 大きな変更を伴わない
大きなシステム変更を必要としない。
業務システムの入れ替えは、費用も期間も、関係する人の数も大きくなります。「この画面で毎回これを確認している」という程度の困りごとのために、その規模の変更を選ぶのは現実的ではありません。
拡張は、既存の画面をそのまま残したまま、その上に足す形になります。使う人の手順も、基本的には今のままです。
- サービス側の改修を伴わずに始められる場面がある
- 今の画面と操作を残したまま試せる
- 合わなければ、外して元に戻せる
これは「何でも拡張で済む」という意味ではありません。ブラウザの外で起きる処理や、サービス側のデータの整合性に関わる要件は、拡張の担当範囲の外です。
AI × CHROME EXTENSION × ENTERPRISE
3つを重ねると、続けられる形になる。
それぞれ単体でも成り立ちますが、この順に重ねたときに、「作って終わり」ではない進め方になります。
LAYER 01
AI
小さな機能を、短いサイクルで作る。仕様を分けて実装させ、人が確認する。
LAYER 02
Chrome Extension
既存のWeb業務に、機能を追加する。サービスを作り替えずに、画面の上へ届ける。
LAYER 03
Enterprise Management
必要な対象へ、許可・配布・制御する。誰に配るかと、何を許可するかを管理者が決める。
この3層を組み合わせると、「既存システムを全面的に作り直さず、小さな業務改善を継続的に追加する」という進め方になります。
06 · 個人・チーム・企業
個人で始めて、チームで使い、企業で管理できる。
業務の多くがブラウザの中で起きているなら、改善したい一手間もブラウザの中にあります。だから、個人が試した形を、そのままチームへ、必要なら組織へ広げやすい。使う単位が変わっても、道具の形は変わりません。
個人
自分のブラウザに入れて、自分の作業を軽くする。決めるのは自分だけなので、その日から試せます。
チーム
同じ画面を毎日見ている数人で使う。効果も副作用も短期間で分かるので、続けるかどうかを早く判断できます。
企業
対象を決めて配布し、ポリシーで管理する。判断の材料になるのは、要求する権限と、実際の動作の説明です。
07 · CHROME ENTERPRISE
企業では、管理者が許可・配布・制御できる。
Chrome拡張は「各自が勝手に入れるもの」とは限りません。Googleの管理コンソール（Chrome Enterprise Core）から、組織のChromeに対してポリシーを配れます。拡張を業務で使うかどうかの議論は、この前提の上で行えます。
- 全体の方針を選ぶ。すべて許可してブロックリストで止める、すべてブロックして許可リストだけ入れる、許可リストに加えて利用者からの申請を受け付ける、といった方針を管理コンソールで選べます。
- 個別に指定する。ExtensionInstallAllowlist / ExtensionInstallBlocklist / ExtensionInstallForcelist / ExtensionSettings といったポリシーで、拡張ごとの扱いを決められます。
- 権限で判断する。拡張が要求する権限を条件に許可・不許可を決めたり、特定のサイトでの動作を止めたりできます。
- 申請を受け付ける。利用者からの拡張機能リクエストを、管理者が許可・ブロック・自動インストールで処理できます。
- 組織内に配る。Google Workspace のドメインに限定して公開する方法があります（組織向けのChromeウェブストア）。
どこまでできるかは、契約しているエディションと管理設定によって変わります。導入の判断は、自社の管理者とGoogleの公式ドキュメントで確認してください。以下はGoogleのページです。
アプリと拡張機能を許可またはブロックするsupport.google.com
拡張機能のリクエストを受け付けるワークフローsupport.google.com
Chrome Enterprise ポリシー一覧chromeenterprise.google
組織向けの公開方法（Enterprise publishing options）developer.chrome.com
08 · この考え方で作っている
Legacy Toolsも、この形で作っています。
このサイトで公開しているのは、8本のChrome拡張です。どれも「送る前に確認する」「貼る前に置き換える」といった、一つの場面のための道具で、汎用の業務システムではありません。
作り方も、このページに書いたとおりです。困りごとを一文にしてから、AIに機能を分けて実装させ、自分のChromeに読み込んで使い、権限と通信と保存先を人が確認してから公開しています。
8本を公開してみて分かったのは、AIに任せられる部分と、人が決めるしかない部分が、はっきり分かれることでした。作る速さより、何を作るか・公開してよいかを決めるほうに時間がかかります。
09 · 権限とローカル処理
「拡張だから安全」ではない。だから、確認する。
Chrome拡張は、ページの中身を読む権限も、入力内容に触れる権限も要求できます。形式が拡張であること自体は、安全性の保証にはなりません。ここを曖昧にしたまま業務で使う話を進めることはできません。
そのかわり、確認できるようにはなっています。必要な権限はmanifestに宣言され、インストール時に表示されます。何にアクセスするのかを、入れる前に読めます。
- どのサイトで動くのか
- 何を、どこに保存するのか
- 外部に送信しているのか
- 更新のたびに、要求する権限が増えていないか
Legacy Toolsの8本については、処理をブラウザの中で完結させ、入力内容を外部に送らない設計にしています。製品ごとの権限と処理の範囲は、技術的透明性のページに一覧で置いています。
10 · 既存の統制との関係
DLPやログ監査の代わりにはならない。
企業には、すでに情報の取り扱いに関する仕組みがあります。DLP、ログ、監査、アクセス制御。拡張は、その置き換えではありません。
位置が違います。多くの統制は、データが経路を通るときや、通ったあとに働きます。拡張が入れるのは、その手前です。人が送信ボタンを押す、その直前。
だから、並べて使うことになります。手前で気づける回数が増えても、後段の統制は必要です。逆に、後段の統制があっても、送るかどうかの判断は人が行っています。
そして、拡張そのものも統制の対象です。どの拡張を許可し、誰に配るかは、07に書いたとおり管理者が決められます。「野良の拡張が増える」という懸念と、「拡張で業務を改善する」という話は、同じポリシーの上で両立します。
11 · はじめの一つ
まず、一つの業務から始める。
全社導入の計画から始めなくて構いません。1つの画面、1つの操作、1つのチーム。この規模なら、合わなかったときに戻せます。
-
1
困りごとを一文にする
どの画面で、何をしているときに、何を確認しているのか。この一文が曖昧なままだと、作るものも曖昧になります。
-
2
すでにあるもので足りるか見る
同じことをする拡張が、すでに公開されていることもあります。その場合は、作るより、権限と動作を確認して選ぶほうが早い。
-
3
小さく作って、自分で使う
1つの画面、1つの操作。動くところまで作ったら、実際のブラウザで自分が使ってみます。コードを読むだけでは出てこない違和感があります。
-
4
確認してから、広げる
権限と動作を確認してから、チームへ。組織で使うなら、そこで配布とポリシーの話になります。順番が逆になると、あとから戻すのが難しくなります。
このページで言えるのは、ここまでです。「AIなら簡単に作れる」でも「拡張なら安全」でもありません。Chrome Extensionは責務と実行範囲を小さく設計しやすく、だからAIに実装させて人が確認するという作り方と噛み合う。主張しているのは、その一点です。