TL;DR

既存のサイトブロッカーは全て固定リスト方式で、「事前にブロック先を決める」というアプローチ自体に限界がある
セッション中に初アクセスしたサイトでその場で Block / Allow を選ぶ動的ブロッカーを作った
競合調査した結果、このアプローチのChrome拡張は既存に存在しなかった（2026年4月時点）
Chrome Web Store公開済み・GitHub公開済み・超軽量13KB

👉 Dynamic Site Blocker - Chrome Web Store
👉 GitHub

1. 課題：作業中の脱線は構造的な問題

作業中にブラウザで脱線して、気づいたら10〜20分経っていた――エンジニアなら一度は経験があると思う。AIツールの応答待ちのようなちょっとした空白時間がきっかけになることも多い。

これは意志力の問題じゃない。環境の問題だ。

カリフォルニア大学アーバイン校のGloria Mark教授の研究によれば、1つの画面に集中できる平均時間は2004年に150秒だったのが、2024年には47秒まで縮んでいる（Mark, 2023）。デジタル環境そのものが集中を削る構造になっている。さらに、一度タスクが中断されると元の作業に戻るまで平均23分15秒かかるというデータもある（Mark et al., CHI 2008）。

「脱線しないようにする」のは非現実的で、脱線しにくい環境を作る方が合理的だ。で、サイトブロッカーを試してみた。

2. 既存ブロッカーの根本的ジレンマ

既存のブロッカーは全て固定リスト方式だ。事前に「このサイトをブロックする」とリストを作っておく。このアプローチには構造的なジレンマがある。

❌ 厳しくすると仕事に支障が出る
仕事でYouTubeの技術解説動画を見ることもありえなくはない。Twitterで技術トレンドを追う場面もある。「YouTube = 悪」ではない。タスクによって必要なサイトが変わるのに、固定リストはそれに対応できない。

❌ 緩くすると意味がない
じゃあ本当に不要なサイトだけブロックすればいいかというと、脱線先は予測不能だ。Hacker Newsから飛んだ先のブログ記事で時間が溶けることもある。ブロックリストに入ってないサイトには無力。

❌ タスクごとにプリセットを用意するのは現実的じゃない
プリセット管理自体が仕事になる。本末転倒。

問題は「事前にリストを決める」というアプローチそのものにあった。

3. 解決策：Dynamic Site Blocker

事前に決めるのが無理なら、その場で決めればいい。

Dynamic Site Blockerの仕組みはシンプルだ。

1. セッションを開始する
拡張アイコンから「Start Session」を押す。

2. 初アクセスのサイトで判断を求められる
セッション中に初めてアクセスしたドメインで、「Block / Allow」のオーバーレイが表示される。「このサイト、今の作業に必要？」と聞かれるだけ。

3. ブロックしたサイトにはアクセスできなくなる
ブロックを選んだドメインは、セッション中はカスタムブロック画面にリダイレクトされる。ブロック画面にはランダムなユーモアメッセージが出る（全14種）。何回アクセスを試みたかのカウンターもつけた。

4. セッション終了で全リセット
「End Session」を押すと、ブロック/許可のリストが全てクリアされる。次のセッションではまたゼロからスタート。

固定リスト方式:     事前にリスト作成 → ブロック → リスト管理が仕事に
Dynamic方式:       セッション開始 → その場で判断 → セッション終了でリセット

間違えてブロックしてしまっても、ポップアップからUnblockできる。逆に、許可したけどやっぱりブロックしたくなったらBlockに変更もできる。双方向に変更可能にした。

競合調査の結果

作る前にChrome Web Storeで既存のブロッカーを一通り調べた。いずれも固定リスト方式、タイマー方式、スケジュール方式のいずれかだった。

「セッション中に初アクセス時にその場で判断する」インタラクティブな動的ブロッカーは、既存のChrome拡張に存在しなかった。（2026年4月時点）

4. 副次的な発見：メタ認知トレーニングになる

使い始めて気づいたことがある。

毎回「このサイト、今必要？」と聞かれることで、無意識の脱線が意識的な判断に変わる。

Dynamic Site Blockerを入れると、サイトに到達した瞬間に「Block / Allow」を突きつけられる。ここで一瞬、**「今このサイトに用事あるっけ？」**と考えることになる。

この1秒の問いかけが効く。答えが「ない」なら、Blockを押すまでもなく自分でタブを閉じることもある。ブロッカーに止められたんじゃなくて、自分で気づいて止めた。

これは単なるサイトブロッカーじゃない。セルフアウェアネスツールだ。

最終的には、この拡張が不要になるのが理想。無意識の脱線を意識的にコントロールする癖がつけば、ブロッカーなしでも集中できるようになるはず。

5. 技術的なポイント

超軽量（13KB）で作った。使った技術要素を軽く紹介する。

Manifest V3

Chrome拡張は2024年以降Manifest V3が必須。Service Workerベースで、バックグラウンドの常駐が不要になる代わりに、状態管理に工夫が必要になった。

declarativeNetRequest（redirect方式）

ブロックには chrome.declarativeNetRequest のsession rulesを使っている。ブラウザ側でネイティブに処理されるので、JavaScriptの実行コストがゼロ。ブロック対象ドメインへのリクエストをカスタムブロックページにリダイレクトする仕組み。

// セッションルールでドメインをブロック（イメージ）
chrome.declarativeNetRequest.updateSessionRules({
  addRules: [{
    id: ruleId,
    priority: 1,
    action: {
      type: "redirect",
      redirect: { extensionPath: "/blocked.html" }
    },
    condition: {
      urlFilter: `||${domain}`,
      resourceTypes: ["main_frame"]
    }
  }]
});

session rulesはブラウザ終了で自動的にクリアされるので、セッション管理と相性がいい。

chrome.storage.session

セッション中の状態（ブロック済み/許可済みドメインのリスト、セッション開始フラグ）は chrome.storage.session で管理。Service Workerが再起動してもセッションが維持される。

Block / Allow オーバーレイ

初アクセスドメインの検知には chrome.webNavigation.onCompleted と chrome.tabs.onActivated を組み合わせている。検知後、chrome.scripting.executeScript でオーバーレイを注入する。

おわりに

課題の定義が正しければ、ソリューションはシンプルでいい。

「事前にリストを作る」のが問題なら、「その場で決める」ようにする。200行程度のコードで、既存のどのブロッカーも解決できなかった問題が解決できた。

この課題は日本固有じゃないと思ったので、UIやブロック画面のメッセージは全て英語にしてある。

エンジニアなら、自分が抱える課題を自分で解決する力がある。作ったものがたった13KBでも、課題の定義さえ正しければそれで十分機能する。

👉 Dynamic Site Blocker - Chrome Web Store
👉 GitHub - atsushikaneko/dynamic-site-blocker

使ってみて感想やフィードバックがあればぜひコメントで。

参考文献

Mark, G. (2023). Attention Span: A Groundbreaking Way to Restore Balance, Happiness and Productivity. Hanover Square Press.
Mark, G., Gudith, D., & Klocke, U. (2008). "The Cost of Interrupted Work: More Speed and Stress." Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '08), pp.107-110.