公開日: 2025 年 10 月 22 日
Chrome では、JavaScript ソースのライブ編集機能が非推奨になりました。Chrome 142 で試験運用版フラグの背後に移動し、Chrome 145（2026 年 2 月）で完全に削除する予定です。ソースファイルに関連する他の強力な機能（ローカル オーバーライド、ワークスペース、スニペットなど）は削除されず、引き続き完全にサポートされます。
Chrome DevTools チームは、デベロッパーに強力で信頼性の高いツールを提供するために常に取り組んでいます。この取り組みの一環として、もはや役割を果たしていない機能を廃止する必要がある場合があります。この決定は、この機能の維持費が不釣り合いに高いこと、使用率が低いこと、優れた最新の代替機能が存在することに基づいて慎重に検討された結果です。ワークフローの変更は混乱を招く可能性があるため、この投稿ではその理由を明確に説明します。
ライブ編集とは何ですか？
ライブ編集を使用すると、実行時にスクリプト ファイルのコンテンツをその場で置き換えることができます。これは、スクリプトがブレークポイントで一時停止している場合でも機能しました。[ソース] パネルで JavaScript コードを変更し、ファイルを保存（Command+S / Ctrl+S）して変更を適用できます。デバッガは、実行時にすでに定義されている関数をパッチ適用します。変更された関数がコールスタックにある場合、その関数も再起動されます。
この目標は、ページを完全に再読み込みすることなく、小さな変更をテストする方法を提供することでした。ページを完全に再読み込みすると、アプリケーションの状態がクリアされます。この点で、その目的は、最新の開発スタックで Hot Module Replacement（HMR）が実現するものと似ていました。
削除する理由
ライブ編集のユーザー エクスペリエンスは常に課題でした。関連するショートカット（Command+S / Ctrl+S）は通常、ファイルの保存に関連付けられていますが、副作用は伴いません。失敗した場合、フィードバックが不明確になることがあります。DevTools に「LiveEdit failed: Functions that are on the stack (currently being executed) can not be edited」のような警告メッセージが表示されることがありますが、見落とされる可能性があります。そのため、デベロッパーは変更が適用されたかどうかを確信できません。
ライブ編集がソースファイルに関連する他の DevTools 機能とやり取りすると、さらに悪化します。たとえば、DevTools スニペットのコンテンツをライブ編集すると、DevTools がスニペット ソースの ID を参照する際に混乱し、新しいバージョンが読み取り専用ファイルとして表示されることがあります。ワークスペース機能が有効になっている場合、DevTools はファイル システム内のソースの変更を監視し、これらの変更をライブページにシームレスに適用します。この動作は、ユーザーの環境やツールチェーンの設定によっては、想定内である場合もあれば、想定外である場合もあります。
ライブ編集が解決しようとしていた元の問題（アプリケーションの状態を失うことなく変更を行う）は、現在ではホット モジュール置換（HMR）によってより効果的に解決されています。HMR は、React、Angular、Vue などの最新のウェブ開発フレームワークの標準機能です。これは、ユーザー空間でより高いレベルの抽象化で同じ効果を実現します。DevTools でのライブ編集が干渉し、予期しない誤った動作が発生する可能性があります。
これらの問題は、ユーザー エクスペリエンスの低下につながります。また、使用状況の統計情報からも、この機能がほとんどのデベロッパーのワークフローのコア部分になっていないことが確認されています。この機能を利用しているユーザー数は非常に少なく、減少傾向にあります。
高いメンテナンス費用と技術的な複雑さ
ライブページでコードを置き換えることは、妥当なセマンティクスを定義するだけでなく、実装の面でも簡単ではありません。これは、V8 JavaScript エンジンと Chrome DevTools に大きなエンジニアリング コストを課し、V8 の多くの部分で慎重な検討を必要とします。ライブ編集は、注意深く行わないと、再現が難しくデバッグが困難なクラッシュにつながる可能性があります。たとえば、関数の新しいバージョンに、以前のバージョンとは異なる数の正規表現、オブジェクト、関数リテラルが含まれている場合、これらのリテラルを追跡するデータ構造を慎重に調整する必要があります。
このメンテナンスの負担により、新しい JavaScript 機能の実装が遅れ、より広く使用されている DevTools 機能の改善からリソースが奪われます。
この複雑さにより、次のようなサポートされていないシナリオも多く発生しました。
- コールスタックにあるが最上位のフレームではない関数を編集する。
- 非同期関数またはジェネレータの編集。
- ES モジュールの最上位コードを編集する。
代替
前述のとおり、ホット モジュール置換（HMR）はより一般的な代替手段であり、いくつかの重要な点でライブ編集よりも優れています。
- ライブ編集では、ライブページの古いバージョンのソースコード レベルで、その一部が置き換えられます。一方、HMR は Web フレームワークが意図した抽象化レベルで古いバージョンを置き換えるため、ライブ アップデート中にコンポーネントとアプリケーションの状態を正しく移行できる可能性が高くなります。
- HMR は作成したソースコードで動作します。エディタで元のファイル（TypeScript、JSX など）を編集すると、ビルドツールがブラウザでの更新を処理します。一方、ライブ編集はデプロイされたソースファイルにのみ影響します。多くの場合、これはツールチェーンによって生成されたビルド出力です。
- 堅牢で、統合も優れています。HMR は最新の開発ツールチェーンのコア部分であり、更新が成功または失敗した場合に明確なフィードバックを提供することで、信頼性の高いエクスペリエンスを実現します。
ライブ編集の削除は、Chrome DevTools の他の 2 つの強力な機能には影響しません。
- ローカル オーバーライドを使用すると、ネットワーク リクエストをインターセプトして、代わりにローカル ファイルを提供できます。ソースコードにアクセスできない本番環境のサイトで変更をプロトタイピングする場合に最適です。変更はページの再読み込み後も保持されます。
- ワークスペースでは、[ソース] パネルとローカル プロジェクト ファイルの双方向バインディングを作成することで、DevTools がより強力なエディタになります。DevTools で変更を保存すると、ファイル システムに直接保存されます。これにより、開発サーバーの HMR またはライブリロード プロセスがトリガーされる可能性があります。
まとめ
ライブ編集は、メンテナンス コストが高く、使用率が低いため、持続可能ではありません。そのため、この機能を削除します。最新のウェブ開発エコシステムでは、ホット モジュール置換というはるかに優れたソリューションが提供されています。
この機能を廃止することで、Chrome DevTools のより影響力の大きい部分にエンジニアリングの取り組みを集中させることができます。削除のタイムラインは次のとおりです。
- 近い将来: Chrome 142 でこの機能が試験運用版に移行し、Chrome フラグ（chrome://flags/#devtools-live-edit）として利用できるようになります。
- Chrome 145（2026 年 2 月）: この機能と対応する Chrome フラグが完全に削除されます。
この変更に関するご意見をお待ちしております。フィードバックの問題にコメントを追加します。