CMSを削除してビルド時間を1/3に短縮した話
Article by: Eli Lennox（了読時間：11分） Sentryでは、ものが壊れないことに執念を燃やし、それこそが私たちの存在意義だと考えています。しかしかつて、自社のマーケティングサイトがその信念を揺るがしてしまう時期がありました。 sentry.io 上で皆さんが目にするもの（マーケティングサイト、ブログ、オープンソースのマイクロサイトなど）の多くは、従来のヘッドレスCMSを基盤とした古いGatsbyサイト群で動いていました。理論上は機能していましたが、実際には壊れやすいプラグインの寄せ集め、制限の多いスキーマ、そして肝心な出荷タイミングに限って失敗する外部API依存に振り回されていました。 そこで私たちは、まともなエンジニアリングチームなら当然そうするように、それをすっぱり捨てて、Astro、Markdown、AI駆動の自動化で置き換えました。 問題：「ヘッドレス」という頭痛の種 旧スタックは、不必要に複雑な代物になりつつありました。 ビルドのボトルネック：Gatsbyの統合データレイヤーは便利でしたが、コンテンツが増えるにつれてビルド時間は1回あたり約14分に膨らんでいました。1日平均95回のビルドを行っていたため、毎日約22時間分のビルド時間を消費していました。 CMSのコスト：約2,500ページのコンテンツを1つのCMSインスタンスで管理していました。ページスキーマとコンポーネントスキーマが並立しており、条件付きフィールドが使えなかったため、スキーマの上限に達しないよう条件付きフィールドのプラグインを別途購入する羽目になりました。月額サブスクリプションに加えて年間サブスクリプションのコストも重なり、それでもスケーラビリティは限られたままでした。 外部依存の脆さ：すべてのビルドがGatsbyプラグイン経由で外部のCMSとマーケティングオートメーションシステムのAPIに依存していました。リビルド開始前の最後の1か月で、CMSのGatsbyプラグインが1日に3〜5回失敗し（サポートチケットを提出しても解決策はなし）、マーケティングオートメーションAPIもレート制限で1日に複数回失敗していました（詳しくは後述）。 解決策：Astroと「ただのファイル」の力 フレームワークをAstroに移行しました。モダンなWeb向けに設計されており、デフォルトで高速、そして驚くほど柔軟性が高いことを選定理由としました。 Viteによる高速化：Viteへの移行により、ローカル開発と本番ビルドがようやく2026年らしい速度になりました。ビルド時間は約14分から4分未満に短縮され、1日あたり約15.8時間分のビルド時間を節約できています。 フレームワーク非依存：Astroは目的に最適なツールを使う自由を与えてくれます。コンポーネントにReactが適していればReactを使い、シンプルな静的コンテンツであればHTML/CSSで済みます。 Vercelに重い処理を任せる：画像処理をVercelにオフロードすることで、ビルドプロセスを遅らせることなくアセットを最適化できています。 しかし最大の変化はフレームワークではなく、コンテンツの管理方法でした。ヘッドレスCMSのUIをMarkdownとFrontmatterに置き換えたのです。 AIネイティブなコンテンツ管理（SaaSの肥大化なし） CMSプロバイダーの「AIアドオン」にお金を払う代わりに、Claude Skillsとの直接連携を自前で構築しました。 今ではサイトを更新する際、肥大化したダッシュボードにログインする必要はありません。スキルを使ったワークフローで作業します。 1. ユーザーをガイドしながら、MarkdownファイルとFrontmatterを正確に更新するプロセスを進めます。 2. ライブプレビューを生成します。 3. レビュー用のPull Requestの下書きを作成します。 CMS統合AIを使わず、なぜカスタム構築にしたのか。 依存ゼロ：コンテンツはリポジトリに置かれます。APIの障害がなければビルドの失敗もありません。 スキーマの制限なし：Frontmatterで構造を自分たちで定義します。新しいフィールドやスキーマタイプが必要になれば、追加するだけです。サブスクリプションの制限も、プランの縛りもありません。 「Sentryらしい」やり方：深い技術志向を持つデベロッパーファーストの企業として、コンテンツをコードとして管理することは自然な選択です。バージョン管理され、ピアレビューされ、レンダリングするコンポーネントのすぐそばに置かれます。 実施プロセス マーケティングサイトとブログ合わせて約2,500ページのサイトを移行するのは、大規模なプロジェクトです。チームは2.5人の開発者で、期間は2か月でした。 チームが小さく、サイトの規模が大きかったため、コーディングの多くをClaude Codeに頼りました。開発者たちは計画立案、スコープ定義、要件整理に時間の大半を費やし、コードのレビュー、変更の指示、アウトプットの調整を行いました。 スコープ定義 このプロジェクトでは、次の2つの理由からスコープ定義が比較的容易でした。 これらのWebサイトにはモノレポを使用しているため、ボットがビルド・移行対象の全体像を把握できていた。 […]
【React Native SDK】Expo アプリのデバッグが簡単に
Article by: Aleksandr Pantiukhov Expo アプリからのイベントは、React Native アプリ全体のイベント量の約 75% を占めています。この数値を受けて、Expo アプリのデバッグとパフォーマンスのワークフローを改善するために、Sentry React Native SDK への投資を行うことは自然な判断でした。 このアップデートにより、以下が可能になります。 OTA アップデートのチャンネルやバージョンでイシューをフィルタリングし、特定のアップデートに起因する問題かどうかを即座に絞り込む 緊急リリースに対するアラートを受け取り、ユーザーから報告される前に OTA パイプラインの障害を検知 EAS Build の健全性を Sentry 上で追跡できるため、ビルドログを辿ることなく問題の発生箇所を特定 ナビゲーションパフォーマンス全体を可視化し、プリフェッチのタイミングやアセット読み込みまで含めて確認 自動 OTA 更新コンテキストの付与 Expo Updates を使った OTA 配信では、適切なコンテキストがないと問題の原因が見えづらくなります。どの update channel だったのか、どの runtime version だったのか、埋め込みバンドルだったのか、それともダウンロードされた更新だったのか、といった情報です。 今回のアップデートでは、すべての Sentry イベントに ota_updates コンテキストが自動で付与されます。追加設定は不要です。update ID、channel、runtime version、起動時間、埋め込みアセットの使用有無などが取得できます。これらは Expo プロジェクトで標準で収集されます。 さらに、すべてのイベントには検索可能なタグ（expo.updates.channel、expo.updates.runtime_version、expo.updates.update_id）も付与されるため、特定のチャンネルやアップデートに絞ったフィルタリングを簡単に行えます。 […]
サイトからCookieをなくして2年：私たちはどこにたどり着いたのか
Article by: Matt Henderson 2024年1月、私は sentry.io からすべての広告 Cookie とユーザートラッキングを削除したことについて書きました。当時、その決定から8か月が経っていましたが、何が壊れ、何が予想外だったのかを、まだ検証している最中でした。その記事は大きな反響を呼びました。おそらく、これまで私たちが公開した記事の中でも最も多く読まれたものの一つです。理由は単純で、Web 上でプロダクトを作ったり運営したりしている誰もが、同じ Cookie 廃止の流れを見つめながら、「もし本当に誰かが思い切って全部やめたら、実際どうなるのか？」を気にしていたからだと思います。 それから、もう2年以上が経ちました。私たちは Cookie を戻していません（そもそも戻すつもりもありませんでした）。そして、その結果として、成長予算の使い方はかなり大きく変わりました。最初から壮大な戦略を立てていたわけではありません。ですが、Cookie をなくしたことで、「どこにお金を使うべきか」「その投資に何を期待するのか」を考え直さざるを得なくなったのです。現在、私たちの成長予算のおよそ70%は認知向上に使われています。実際には、たとえば次のような取り組みです。 私たちは Golden State Warriors、Golden State Valkyries、そして Chase Center と複数年契約を結びました。 Syntax.fm は、自社でコーポレートポッドキャストを立ち上げる代わりに、2023年に Sentry の一部となりました。 毎年、ビルボード広告や OOH（屋外広告）にもかなりの予算を使っています。 ポッドキャスト、Reddit、YouTube、サードパーティニュースレター、インフルエンサーは、私たちにとって非常に大きなチャネルです。 この2年間で Open Source Pledge を通じて、オープンソースメンテナーに75万ドルを寄付しました。（それ以前にも継続して支援しています。） コアとなるビジネスモデルや、その他すべての施策も含めると、こうした投資は確実に成果を上げています。新規のアクティブユーザー数は指数関数的に成長しています。 こうしたタイプの投資は、開発者向けに製品を販売している企業としてはかなり珍しいものです。ただ、私たちも最初から大きな施策を打っていたわけではなく、もっと小さなところから始めました。ここまでで、私が学んだことを紹介します。 ソフトウェアの見つけられ方が変わっている もしプロダクトを作っているなら、すでに感じているかもしれません。人々がツールを見つけ、評価する方法は、いま大きく変わりつつあります。 以前は、かなり予測しやすい導線がありました。誰かが Google で問題を検索し、いくつかの検索結果をクリックし、比較記事を読み、トライアルに登録する。コンテンツを書き、広告を出し、SEO を行い、その流れの中で見つけてもらえれば、プロダクトは成長できました。 ですが、その流れは以前ほど信頼できるものではなくなっています。Google からのリファラルトラフィックは減少し、ゼロクリック検索は増加しています。Semrush の 2025年のデータによると、現在では Google 検索のおよそ60%が、どの […]
【Flask × React】実装するチェックアウトフローの監視とデバッグ
Article by: Will McMullen チェックアウトフローが壊れると、顧客は「最先端」のJSメタフレームワークが廃れるよりも早く離れていきます。幸い、Sentry を使えば、顧客のチェックアウトのようなクリティカルパスにオブザーバビリティを設定するのは簡単です。ここでは、私たちがどのようにインスツルメントし、監視し、大きな問題を最小限の労力で修正したのかを順を追って紹介します。 チェックアウトフローのインスツルメント まず、ユーザーがチェックアウトプロセスとどのようにやり取りしているかを正確に追跡したいと考えました。Sentry の Distributed Tracing を使って監視ダッシュボードを設定するのは簡単でした。フロントエンドとバックエンドのアプリケーション（今回の場合は app.py と App.tsx のトップレベルファイル）でトレーシングを有効化し、/api/ エンドポイントを tracePropagationTargets に追加して Distributed Tracing をセットアップするだけで完了です。 これで、Flask と React の両方にわたって、パフォーマンスメトリクス、エラー、トレーシングデータを取得できるようになりました。 ユーザージャーニーの監視 Sentry にデータが集まるようになると、eコマースストアフロントで最も重要な要素であるチェックアウトフローを監視するためのダッシュボードを立ち上げるのは非常に簡単でした。 ここに到達するために、私たちはいくつかの主要な属性で Span データ を拡張しました。これらは Sentry で Span Metrics として可視化・監視できます。誰かが Cart.jsx コンポーネントを使うたびに、Sentry SDK でのインスツルメンテーションによって「カートに追加されたアイテム数」をそのアクティブな Span に付与し、その数を追跡できるようにしました。 実際のところ、次のような形になります。 まず、Sentry.startSpan() でスパンを作成し、次に checkoutspan.setAttribute を使って items_at_checkout を属性として追加します。ここにデバッグやパターン分析のために顧客データなど他の有用な情報を付与することも簡単にできますが、ここではシンプルに留めることにしました。 […]
ダウンタイムの一般的な原因とウェブサイト監視のメリット
Article by: Lewis D. 本ブログの内容 どの Sentry 機能が使用されているのか ウェブサイト監視による過負荷の検出 アップタイム監視による不良デプロイの検知 アップタイム監視による依存関係問題の検知 なぜアップタイム監視だけではセキュリティ脆弱性を検知できないのか ユーザーに指摘される前にダウンタイムのアラートを受け取る ダウンタイムは、最も都合の悪い瞬間に発生します。例えば、「クイックデプロイ」の直後や、思い切って5分間離れた時などです。トラフィックの急増によってエンドポイントの一つが集中的にダウンし、他のエンドポイントもダウンしてしまうかもしれません。あるいは、自信を持って本番環境に直送した「小さな変更」が原因かもしれません。 どちらの場合も、ユーザーはサイトにアクセスできず、現在は本番環境でライブデバッグを行っています。 この記事では、基本的なウェブサイト監視によって、ステータスページの更新、Slack の通知、ツイートなどの前に、より早く問題を発見できる方法を解説します。シンプルな Node.js Express アプリを用いて、監視によってパターンやボトルネックが明らかになり、ひょっとするとコーヒーを飲み終える時間を稼ぐことができる方法をご紹介します。 本題に入る前に少し余談ですが、物事をシンプルにし、完全に理論的な話にならないようにするために、基本的な Node.js Express アプリを立ち上げ、完全なエンタープライズ監視スタックにすることなく、実用的な監視機能だけに接続しました。 私が設定した内容は次のとおりです。 Sentry トレーシングなので、何かが壊れたときにアラートが届きます。 ソース マップは Sentry Wizard 経由でアップロードされます。縮小されたスタック トレースは最悪だからです。 アプリを軽量ホスティングサービスに投入 Sentry にアップタイム監視アラートを作成しました。これは、パブリックエンドポイントにpingを送信し、応答が停止した場合にアラートを出します。トレーシングとは別に動作するため、アプリがエラーを投げていなくても、全く応答していない状態を検知します。 どの Sentry 機能が使用されているのか この記事で紹介する Sentry のすべての機能とその役割を簡単にまとめたマップを以下に示します。 特徴 監視対象 以下に使用されている箇所 アップタイム監視 パブリックURLまたはエンドポイントにアクセスできるかどうか エンドポイントによってサイト全体がクラッシュしたときに、最初のアラートが出され、その後、別の分離されたエンドポイントルートに対してアラートが出されます。 エラー監視 処理されない例外とログに記録されたエラー 不適切なデプロイ後に発生した パッケージ欠如によるスタックトレース […]
アプリケーションのパフォーマンスを関数呼び出しレベルまでデバッグ ― 継続的プロファイリングとUIプロファイリングの導入
Article by: Will McMullen 本番環境で何かの動作が遅くなった場合、古い習慣に陥りやすいものです。ログをいくつか追加し、メトリクスを送信し、ローカルで問題の再現を試みます。意欲があれば perf や py-spy に手を伸ばすかもしれません。トレースは役立ちますが、特にスタックの深い部分では、「なぜ遅いのか」を説明するには不十分なことがあります。 つまり、開発者がアプリケーションの挙動を、直感に頼って推測せざるを得ない場面が生じます。たとえば、プロパティドリルによってレンダリングが肥大化していたり、状態変更によって不要な再レンダリングが発生していたり、あるいはサードパーティ製のライブラリが静かに 500 個のイベントリスナーを起動していたりするかもしれません。 こうしたときにこそ、プロファイリングが役に立ちます。プロファイリングは症状を指摘するだけでなく、CPUを消費している関数呼び出しやファイル、行番号を正確に表示します。 本日、私たちは Continuous プロファイリング と UI プロファイリング の2つの強力なプロファイラーをリリースします。実行時の動作を関数レベルで可視化し、ボトルネックを迅速に特定して解決するための機能を提供します。 バックエンドのボトルネックを特定して解決する Continuous プロファイリング 開発マシンでは問題なく動作していました。ステージングテストも問題なし。しかし、本番環境で実際の負荷がかかると、その重要な API エンドポイントが突然遅くなったり、バックグラウンドワーカーが予期せず大量のメモリを消費したりすることがあります。ログは正常に見え、トレースによってサービスがアクセスされたことも確認できているのに、内部のボトルネックが特定できない…。そのようなとき、開発者は再現が困難な問題や、隠れた非効率性を推測するしかありません。 継続的プロファイリングは、このような状況において、バックエンドの実行状況を常時可視化を提供します。長時間実行されるワークロード、リアルタイム API、「ローカルでは問題なかった」と片付けられがちなコードパスの解析に最適です。 特に、以下のような場合に役立ちます。 CPU ホットスポット：あるエンドポイントが突然 CPU 使用率が3倍に急増し、原因が分からない場合、プロファイリングは機能レベルのボトルネックを直接特定できます。 バッチジョブ：何時間も静かに実行される（時にはクラウド請求を倍増させる）あの夜間処理。いまでは、それが どこで時間を費やしているのかを正確に確認できる ようになりました。 ML パイプライン：あるモデルパイプラインで発生していたレイテンシのスパイクを、プロファイリング を使ってわずか 10 分ほどで、10 秒短縮しました。調べてみると、パイプラインの一部が「想定以上の処理」をしていたのです。詳細はこちらをご覧ください。 アナリティクス：あなたの「インサイトエンジン」が、実際には数百万行を回すだけのループにすぎないこともあります。プロファイリングは、ログやメトリクスでは見えない非効率を、プロダクション環境に影響が出る前に発見する手助けをします。 バックエンドサービスのパフォーマンスは、ブラックボックスのままである必要はありません。Continuous プロファイリング を使えば、インフラコストの最適化、API レスポンスの遅延削減、スループットの向上が可能になり、Slack が通知であふれる前に非効率を簡単に見つけられます。 現在、Node.jsとPythonを標準でサポートしています。 […]
Vercel マーケットプレイスに新カテゴリー追加・Sentry 対応開始
Article by: Cody De Arkland 来年にかけて、これまでの10年間よりも多くの人々がアプリケーションを構築・出荷するようになるでしょう。あらゆる経験レベルの開発者によって「ローンチ」されるアプリケーションが増えるにつれ、「何が壊れたのか」「なぜ壊れたのか」、そしてそれを修正するための明確な道筋を理解することが、ますます重要になります。 こうした背景から、Sentry は Vercel の新たな Observability Marketplace カテゴリーにおいて、最初のプラットフォームとしてローンチされました。 Sentry は、ソフトウェアを構築するすべての人が、メトリックの行をたどってデバッグを強いられたり、特別なダッシュボードビューを手作業で作成して問題の原因を探ったりすることなく、安心してソフトウェアを出荷できるようにしたいと考えています。 Sentry を開発が生まれる現場へ ソフトウェアの開発速度が加速する中で、コードが壊れることは避けられません。そこで、Vercel を通じて Sentry を簡単に利用できるようにすることで、開発者は壊れたコードを迅速に修正するための最短ルートを手に入れることができます。 私たちは、開発者が最も利用するエコシステムへの継続的な投資を通じて、最良の開発者体験を提供することに注力しています。これにより、開発チームはソフトウェアの出荷において最も重要な部分に集中できるようになります。 この開発者体験の大部分は、Next.js のような主要なプラットフォームにおいて、可能な限り摩擦のない体験を提供できているかどうかにかかっています。 開発者は、1 行のコマンドを実行するだけで Next.js 上で Sentry を導入できます。これにより、クライアント・サーバー・エッジにわたる設定が自動的に行われ、コードのソースマップが生成され、エラー境界も実装されます。 Next.js アプリケーションでは、初回の設定コマンドを実行するだけで、エラーモニタリング、リプレイ、トレーシングが自動的に構成されるようになっています。これにより、アプリケーションの遅延や複雑なハイドレーションエラー、RSCに関する問題まで、あらゆる不具合を開発チームが迅速にデバッグできるようになります。 しかし、これで終わりではありません！ 現在、Next.js に特化した新しいインサイトダッシュボードの開発に取り組んでいます。これは、Next.js を利用する開発者に対し、フレームワーク特有の視点からの環境モニタリング機能を提供することを目的としています。 フレームワーク固有のインサイトページは、特定のフレームワークに投資した開発者に、監視プラットフォームから最も価値を得ている情報に密接に一致するインサイトを提供するように設計されています。 私たちは、従来型の監視ツールについて、非常に多くの冗談を言ってきました。というのも、それらはしばしばユーザーを複雑なダッシュボードに縛りつけ、過剰に複雑なデータの解釈を強いるからです。そのため、一見すると Next.js 専用のダッシュボードは、かえって過去に戻るように感じられるかもしれません。 ですが、ぜひ私たちの意図を聞いてください。開発者や運用チームが、Sentry の各機能からより多くのコンテキストを得られることに、私たちは強い関心を持っています。 Next.js アプリケーションは、フロントエンドとバックエンド、RSC、SSRといった技術のユニークな組み合わせを特徴としています。これらの特性に最適化されたビューを構築することで、開発者や運用チームがアプリケーション全体の状況をより深く理解し、適切な判断を下すための助けとなります。 Vercel マーケットプレイスでの Sentry Native 統合 本日（April 8, […]
【PHP】パフォーマンスを改善する方法
Article by: Richard C. 本ブログの内容 前提条件 プロファイリングとは？ SPX を使った PHP プロファイリング トレーシングとは？ OpenTelemetry を使った PHP のトレーシング フロントエンドを含む分散トレーシング オンラインサービスを使ったプロファイリングとトレーシング クリーンアップ PHP のパフォーマンスを改善するヒント 次のステップ PHP アプリは一見シンプルに見えますが、何かが遅くなり始めると状況は一変します。ページの読み込みに数秒余計にかかったり、原因がはっきりしないままサーバーコストが増加していたりしませんか？そんなときに役立つのがパフォーマンスモニタリングです。 このガイドでは、PHP アプリケーションのパフォーマンスを監視・改善する方法を解説します。プロファイリングやトレーシングを使ってコードのボトルネックを特定し、アプリを最適化する方法を学びましょう。Docker を使っている場合でも、すでにローカルに PHP をインストールしている場合でも、例に沿って進めることができます。 このガイドの内容は PHP 8 に対応しており、将来的な変更の程度によってはそれ以上のバージョンにも適用可能です。 前提条件 本ガイドに含まれるすべてのコード例は、Docker を使って任意のホスト OS 上で実行できます。Docker をお持ちでない場合は、こちらからダウンロードしてください。 すでに PHP がインストールされている場合、Docker は不要です。 次のセクションでは、プロファイリングとトレーシングを使って処理が遅いコード部分を特定する方法を紹介します。最後には、サイトのパフォーマンスを改善するためのベストプラクティスのチェックリストも掲載しています。 プロファイリングとは？ アプリケーションのプロファイリングとは、パフォーマンスデータを記録し、改善の余地があるコードを特定するために分析することです。パフォーマンス指標には、アプリがユーザーのために機能を実行するのにかかる時間、実行中に使用される CPU、メモリ、ディスク、ネットワーク帯域などが含まれます。これらすべての指標の値が低いほど、ユーザー体験が向上し、サーバーコストの削減にもつながります。 記録された結果を分析することで、意図よりも高い値の指標を特定し、その原因となっているコード行を見つけます。 […]
【Python】エラーと例外処理の実践的なヒント
Article by: Abdul D 本ブログの内容 Python におけるエラーと例外 − その違いとは Python におけるエラー Pythonにおける例外 なぜ Python において例外・エラー処理が重要なのか Sentry は Python アプリのエラー監視にどのように役立つのか Python のコードで、原因か分からないエラーメッセージに遭遇したことはありませんか？ それはあなただけではありません。経験豊富な開発者でさえ例外に直面するため、効果的に対処する方法を理解することが重要です。 基本的な構文エラーはコードエディタやデバッグツールによって早期に検出できますが、より複雑な問題は実行時に発生することが多く、体系的な例外処理のアプローチが求められます。 経験の有無にかかわらず、すべての Python 開発者が例外処理を習得することで恩恵を受けられます。本ガイドでは、エラーと例外の違いを理解し、一般的な例外の種類を確認したうえで、Python アプリケーションにおける適切な対処方法を学びます。 また、Sentry を使ってリアルタイムで例外を監視・追跡する方法についても解説し、アプリケーションのパフォーマンスと安定性に関する詳細なインサイトを得る手段を紹介します。 Sentry トレーシング Python におけるエラーと例外 − その違いとは 完璧なコードを書くことは非現実的な期待であり、すべての開発者はコーディングミスによる予期しない動作に直面するものです。これらの問題は一般的にエラーと例外の2つに分類されます。 エラーはプログラムの実行を完全に妨げる根本的なコーディングミスです。エラーは通常コンパイル時に検出され、修正されるまでコードは実行されません。 例外はエラーの一種であり、プログラムの実行中（ランタイム）に予期しない状況、例えばゼロ除算のような場合に発生します。 result = 10 / 0 # Raises ZeroDivisionError エラーとは異なり、例外はコード内で捕捉して処理することができます。 エラー処理 vs デバッグ […]
JavaScript にも Debug ID が必要
Article by: Abhijeet Prasad 数か月前、Sentry は Debug ID 用の新しい NPM 組織（名前空間）を作成し、その配下に複数のパッケージを公開しました。https://www.npmjs.com/org/debugids これは、JavaScript Debug ID がエコシステム全体で正式に認知されるための大きな一歩です。同時に、Sentry がオープンスタンダードを牽引し、合意形成に取り組む成熟度を示しています。 ———————————————————————————– 💡 要点まとめ Debug ID は JavaScript ファイルとそのソースマップを結びつける決定論的かつグローバルに一意な値です。 Sentry は Debug ID を Sentry 独自の機能にとどまらず、JavaScript エコシステム全体で広く利用される概念にしようとしています。 Debug ID をソースマップ仕様に追加するため、tc39 に公式提案を提出し、ブラウザ API も含めた標準化を推進しています。 誰でもツールやアプリに Debug ID 機能を追加できるよう、各種プラグイン・ツール・ポリフィルを公開済みです。また、バンドラーやソースマップツールへの対応を JavaScript コミュニティと協力して進めています。 詳しく知りたい方は、ぜひ読み進めてください。 Debug ID とは何か 現代のウェブサイト開発者は、JavaScript […]