第9章 アンチパターン ── よくある失敗と脱出法
アンチパターン1:「とりあえず20個入れる」
症状:「おすすめChrome拡張20選」を見て全部インストールした。2週間後、実際に使っているのは3〜4個。残りはアイコンとして残っているだけ。Chromeの起動が以前より遅くなった。
根本原因:拡張機能は「発見するもの」ではなく「自分のトイルに対して選ぶもの」だ。トイルを定義せずにインストールしても、ワークフローに組み込まれない。
さらに悪い影響:
- 使わない拡張機能の content script がページ読み込みのたびに実行される
<all_urls>権限を持つ拡張機能が複数存在するとセキュリティリスクが増える- コンテキストメニューが肥大化して使いたい機能が埋もれる
脱出法:
現状確認:
chrome://extensions で全拡張機能を確認
「先月使ったか?」を1つずつ問う
NOなら迷わずアンインストール
これから:
「今困っていることを1つ特定する」
→ その解決策として1つだけ入れる
→ 1週間使ってみる
→ 効果があれば定着させ、なければアンインストール
アンチパターン2:「権限を確認せずにインストールする」
症状:便利そうな拡張機能をChromeストアで見つけた。「追加」ボタンを押して、権限ダイアログが出たが「追加」を押した。後から「この拡張機能がデータを収集していた」という報告を見た。
根本原因:Chrome拡張機能は <all_urls> + tabs + storage の組み合わせで、ブラウザ上で行われるほぼすべての操作を把握できる。この権限を悪用したデータ収集の事例は複数報告されている。
過去の事例(実際に起きたもの):
・DataSpii インシデント(2019年)
8つのChrome拡張機能がユーザーの閲覧履歴を収集・販売
「The Great Suspender」(タブ休眠ツール)がマルウェア化(2021年)
人気拡張機能が売却・所有者変更後にスパイウェアに改変
2025年現在も、評価が高い拡張機能が売却されて
悪意あるコードを追加されるケースが続いている。
脱出法:
インストール前のチェックリスト:
□ ユーザー数は1,000人以上か?(少ないものは注意)
□ 最終更新日は最近か?(1年以上前は廃墟リスク)
□ 開発者情報にGitHubや公式Webサイトがあるか?
□ レビューは実際の感想か?(定型文の5つ星は偽レビューのサイン)
□ 要求する権限は用途と一致しているか?
(付箋アプリが "tabs" + "history" を要求→不自然)
□ 拡張機能がオープンソースか?(GitHubでコードを確認できるか)
アンチパターン3:「AIに全部依存して自分で読まなくなる」
症状:SiderやMonicaを入れてからすべてのページをAI要約で済ませている。ある日、AI要約が間違えた情報を返したが気づかずに誤った理解で作業を進めた。
根本原因:AI要約は「ハルシネーション(事実誤認)」を含む場合がある。特に数字・固有名詞・技術仕様は要約の精度が下がる。「読むコストを下げるAI」を「読まない理由にするAI」として使うと、情報の正確性が下がる。
脱出法:
AI要約の適切な使い方:
✅ 「読むかどうか判断するための要約」
→ 要約を見て「読む価値がある」と判断したら全文を読む
→ 要約を見て「関係ない」と判断したらスキップ
✅ 「概要を先に把握して、詳細は選択的に読む」
→ 要約でポイントをつかむ → 重要な箇所だけ全文で確認
❌ 「要約だけで判断する(全文を読まない)」
→ 技術仕様・数字・重要な意思決定には使わない
「AIは読書スピードを上げるもの、読書をなくすものではない」
アンチパターン4:「自動化ツールを本番業務に直結させる」
症状:Bardeenで「LinkedInのリードを自動でCRMに登録してSlackに通知」という自動化を設定した。設定ミスにより意図しないリードが大量登録されCRMのデータが汚染された。
根本原因:ノーコード自動化ツールは「設定が簡単」なぶん「動作確認が不十分なまま本番に適用する」リスクがある。
脱出法:
自動化の段階的検証:
Step 1: サンドボックスで動作確認
→ テスト用のスプレッドシートやCRMアカウントに出力する
→ 期待通りのデータが出力されるか確認
Step 2: 小規模で本番適用
→ 1件 → 10件 → 100件と段階的に拡大
→ 各段階でデータを目視確認
Step 3: ロールバック手段を用意する
→ 「自動登録されたリードに"auto_import"タグを付ける」
→ 問題があれば "auto_import" タグで絞り込んで一括削除できる
自動化ほど「本番前のテスト」が重要。
コードなしで作れる = バグなしで動くではない。
アンチパターン5:「拡張機能が重複している」
症状:翻訳はDeepL・Google翻訳・Sider の3つ。タブ管理はOneTab・Workona・Session Buddy の3つ。それぞれ機能が重複していて、どれを使えばいいか毎回迷う。
根本原因:「試してみる」という正しい行動が、「使い分けが未定義のまま溜まる」という問題を生む。同じカテゴリの拡張機能を複数保持すると、使う際の判断コストが生まれる。
脱出法:
カテゴリごとに「これを使う」を決める:
翻訳 → DeepL だけ(Sider の翻訳機能は使わない)
AI要約 → Sider に統一(Monica はアンインストール)
タブ管理 → OneTab だけ
スニペット → Text Blaze に統一(Magical はアンインストール)
重複している拡張機能がある場合の判断:
「2つの拡張機能で自分が実際に使っているのはどちらか?」
→ 使っていない方をアンインストール
→ 迷うということは、どちらも定着していないサイン
アンチパターン6:「自作拡張のメンテナンスを放置する」
症状:便利な社内拡張機能を作ったが、半年後にGitHubのUIが変わって動かなくなった。作った本人はすでに別のチームに異動。誰も直せない。
根本原因:Chrome拡張機能は「サードパーティサイトのDOM構造」に依存している。GitHubが class="js-issue-title" を変更すれば、それに依存した拡張機能は動かなくなる。
脱出法:
長寿命の拡張機能を作るための設計原則:
1. DOM依存を最小化する
❌ document.querySelector('.js-issue-title')
✅ document.querySelector('[data-testid="issue-title"]')
(テスト用 data 属性はUIリリースより変化が遅い)
✅ ページのURLパターンから情報を取得する(より安定)
2. 拡張機能にバージョンを付ける
manifest.json の "version" を適切に管理
変更履歴をREADMEに残す
3. 動作確認のチェックリストを作る
「この拡張機能のテスト手順」を15分でできる形で残す
→ 誰でも壊れたことを検知・修正できる
4. チームに引き継ぐ
「自分だけが知っている拡張機能」は組織の負債になる
GitHubに置いてオーナーをチームに設定する
アンチパターン7:「セキュリティツールの拡張機能を入れすぎる」
症状:セキュリティのためにVPN拡張・プロキシ拡張・広告ブロック・トラッカーブロック・フィンガープリントブロックを全部入れた。一部のWebアプリが動かなくなった。社内システムへのアクセスが通らなくなった。
根本原因:セキュリティ拡張機能はリクエストのインターセプト・変更を行うため、互いに干渉したり、特定のWebアプリの動作を壊したりする。
脱出法:
シンプルなセキュリティ拡張の構成:
広告・トラッカーブロック → uBlock Origin Lite 1本で十分
VPN → ブラウザ拡張ではなくOSレベルのVPNクライアントを使う
競合している可能性がある場合の診断:
Chrome設定 → 拡張機能 → 全てオフ → 問題が解決するか確認
→ 1つずつ有効にして原因を特定
アンチパターン分類まとめ
| # | アンチパターン | 症状 | 根本原因 |
|---|---|---|---|
| 1 | とりあえず20個入れる | 使わない拡張が溜まる・動作遅延 | トイル定義なしの選択 |
| 2 | 権限を確認しない | データ漏洩リスク | セキュリティ意識の欠如 |
| 3 | AIに全依存 | 誤情報を信じる | AI要約の限界の誤解 |
| 4 | 自動化を本番直結 | データ汚染・意図しない操作 | テストプロセスの欠如 |
| 5 | 同カテゴリの重複 | 使う際の判断コスト | 棚卸し不足 |
| 6 | 自作拡張のメンテ放置 | UI変更後に動かなくなる | 長期運用設計の欠如 |
| 7 | セキュリティ拡張の入れすぎ | Webアプリの動作不全 | 相互干渉の見落とし |