ブラウザの「ブラックボックス」を解剖する：独自のDevToolsパネルで開発体験を劇的に変える技術
こんにちは。日々の開発で「ブラウザのコンソールに流れる膨大なログ」を眺めて、ため息をついたことはありませんか？
ReactやVue、あるいは自作のステート管理ライブラリを使っているとき、DOMの階層を追いかけたり、複雑なオブジェクトの変更を追跡したりする作業は、まさに暗闇で針を探すようなものです。
実は、ChromeやEdgeの「DevTools」は単なる既製品のツールではありません。あなたのWebアプリの内部構造に直接アクセスし、好きなUIでデータを可視化できる「拡張可能なプラットフォーム」なのです。今回は、あなたのアプリ専用の「専用デバッガ・パネル」を構築し、開発の質を一段上のレベルへ引き上げる手法を伝授します。
—
1. なぜ「専用パネル」を作るのか？
標準の「コンソール」や「要素パネル」は汎用的なツールです。しかし、あなたのアプリには「ユーザーにしか見えないビジネスロジックのステート」や「独自プロトコルの通信データ」があるはずです。
これらをDevToolsのパネルとして組み込むと、以下のような魔法が起こります。
- コンテキストの分離: アプリ側の画面を汚さず、デバッグ情報を専用タブに隔離できる。
- ライブ・インターフェース: 単にログを出すだけでなく、パネル上のボタンからアプリのステートを直接書き換える（タイムトラベルデバッグのような）操作が可能になる。
- チームの知見の資産化: チームメンバーがデバッグのために読むべき「正しい情報の見方」をUIとして定義できる。
—
2. 最小構成のアーキテクチャ
ブラウザ拡張機能でDevToolsパネルを作るには、3つの登場人物が必要です。
1. manifest.json: 拡張機能の玄関口。
2. devtools.js: パネルを生成する司令塔。
3. panel.html / panel.js: あなたが自由に設計できる「専用デバッガ」のUI。
ステップ1: manifest.json の設定
まず、拡張機能の定義を行います。ここで重要なのは `devtools_page` プロパティです。
{
“manifest_version”: 3,
“name”: “My Custom Debugger”,
“version”: “1.0”,
“devtools_page”: “devtools.html” // DevTools起動時に裏側で走るHTML
}
ステップ2: devtools.html と devtools.js
`devtools.html` は実体を持たず、スクリプトを読み込むためだけの箱です。
// devtools.js
// chrome.devtools.panels.create(タイトル, アイコン, パネルのHTML, コールバック)
chrome.devtools.panels.create(
“MyApp Debugger”,
null, // アイコンパス
“panel.html”, // ここにデバッグ用のUIを表示する
(panel) => {
console.log(“パネルが作成されました”);
}
);
—
3. 現場で震えるほど役立つ「通信の仕組み」
ここが最も重要なポイントです。DevToolsパネルは、Webアプリの実行コンテキスト（windowオブジェクト等）とは直接繋がっていません。
通信には `chrome.runtime.sendMessage` を介した「バックグラウンド・スクリプト」を仲介させる必要があります。以下の図をイメージしてください。
- [Webアプリ] <-> [Content Script] <-> [Background Script] <-> [DevToolsパネル]
このパイプラインを構築することで、Webアプリ上の `AppState` をリアルタイムにDevToolsパネルへ転送できます。
HelloWorld的な動作確認：パネルにデータを送る
Webアプリからパネルへ「Hello!」と送る最小実装です。
1. Content Script (Webアプリ側に挿入):
// アプリ内の状態が変わるたびに送信
window.postMessage({ type: “APP_STATE_UPDATE”, data: { count: 1 } }, “”);
2. DevToolsパネル側 (panel.js):
// パネルが開かれたときに、アプリからのメッセージを監視する
chrome.runtime.onMessage.addListener((message) => {
if (message.type === “APP_STATE_UPDATE”) {
document.body.innerText = `現在のカウント: ${message.data.count}`;
}
});
—
4. アーキテクトからのアドバイス：どうスケールさせるか
最初は「カウントを表示するだけ」で十分です。しかし、実務では以下の3点を意識してください。
1. データのシリアライズ: `postMessage` で送れるデータは構造化クローンアルゴリズムでコピー可能なものに限られます。複雑なクラスインスタンスを送る際は、JSON化するか、必要なプロパティのみを抽出する設計にしましょう。
2. パフォーマンスへの配慮: デバッグ情報が数ミリ秒おきに大量に飛んでくると、開発ツール自体が重くなります。バッファリングや間引き（Throttling）のロジックを必ず挟んでください。
3. セキュリティ: 拡張機能はブラウザの深い階層にアクセスできるため、信頼できないスクリプトを読み込まないよう、Manifest V3の厳格なポリシーを守りましょう。
最後に：なぜ今、これをやるのか
ツールを作ることは、自分の開発スタイルを定義することです。「既存のログを見る」から「ツールを使って解釈する」へ。この視点の転換こそが、一歩先行くエンジニアへの登竜門です。
まずはシンプルなテキストを表示するパネルから始めてみてください。あなたのアプリの内部が見えたとき、これまで悩んでいたバグが「ただの数値のズレ」として視覚的に捉えられるはずです。
さあ、あなたのWebアプリに「眼」を授ける作業を始めましょう。何か躓いたら、いつでも相談してくださいね。応援しています。