GitHubは2026年10月13日、シークレットスキャン向けの新しい「コンテキスト認識型シークレット分類器」を発表しました。従来のLLMベースのパイプラインを置き換えるもので、リポジトリオーナー加重のアラート受け入れ率が11.5%向上、ポストプッシュスキャンの実行時間中央値が86%削減、サービングコストが98%以上削減されたとしています。
室谷代表取締役GitHubのシークレットスキャンに新しい分類器が入ったという発表なんですよね。数字が派手で、まずそこに目が行きます。
テキトー教師DotAI 認定講師そうなんですよ。単に「速くなりました」という話じゃなくて、精度とノイズとコストを同時に動かしているのがポイントで。
そこを分解して見ていきたいですね。
そこを分解して見ていきたいですね。
GitHubのシークレットスキャン新分類器とは?何が発表されたか
新分類器の発表内容:測定軸ごとの成果
オンラインA/B実験
- リポジトリオーナー加重のアラート受け入れ率が11.5%向上
- アラートの質の改善を示す指標
- 大量アラートを一括処理する顧客の影響を抑えるためオーナー単位で重み付け
ポストプッシュスキャン
- 実行時間中央値が86%削減
- スキャンの速度に関する改善
- オフライン評価で精度13%向上・再現率19%向上
室谷代表取締役まず定義から整理すると、GitHubのシークレットスキャン用の新しいコンテキスト認識型シークレット分類器は、GitHubが2026年10月13日に発表した、リポジトリに誤ってコミットされた認証情報の検出精度を上げるための分類モデルで、従来のLLMベースのパイプラインを置き換えるものなんですよね。
テキトー教師DotAI 認定講師はい。発表によると、リポジトリオーナー加重のアラート受け入れ率が11.5%向上、ポストプッシュスキャンの実行時間中央値が86%削減、サービングコストが98%以上削減。
この3つが公式に示された主要な成果です。
この3つが公式に示された主要な成果です。
室谷代表取締役ここで大事なのは、発表元がGitHubだという点です。Xでも告知されていますが、主語はあくまでGitHub。
そして「何を測った数字なのか」がそれぞれ違うんですよ。
そして「何を測った数字なのか」がそれぞれ違うんですよ。
テキトー教師DotAI 認定講師そこは講座でもよく言うんですけど、数字の意味を揃えて読まないと誤解するんですよね。受け入れ率はアラートの質、実行時間はスキャンの速度、コストはサービングの効率。
別々の軸の改善を3つ並べている。
別々の軸の改善を3つ並べている。
室谷代表取締役しかも「オーナー加重」というのがミソで。大量にアラートを一括処理する顧客の影響を抑えるために、リポジトリオーナー単位で重み付けした受け入れ率なんですよね。
単純平均だと歪むから、そこを補正している。
単純平均だと歪むから、そこを補正している。
テキトー教師DotAI 認定講師ええ。つまり「多くの開発者が実際にアラートを妥当だと判断した割合が上がった」という読み方をすべき数字であって、検出数が増えたという話とは別なんです。
室谷代表取締役あとオフライン評価の数字も出ていて、同じ公開トラフィック上で精度13%向上・再現率19%向上。これはポストプッシュスキャンでの評価です。
オンラインのA/B実験では受け入れ率11.5%向上。オフラインとオンラインで別々に検証しているのが丁寧ですよね。
オンラインのA/B実験では受け入れ率11.5%向上。オフラインとオンラインで別々に検証しているのが丁寧ですよね。
コンテキスト認識型分類器で何が変わったのか——精度11.5%向上・スキャン時間86%削減・コスト98%削減
まとめ
コンテキスト認識型分類器で変わったこと
- リポジトリオーナー加重のアラート受け入れ率: 11.5%向上(誤検知の削減を示す)
- ポストプッシュスキャンの実行時間中央値: 86%削減
- サービングコスト: 98%以上削減(コンパクトモデルとリモートLLM呼び出しの比較)
- オフライン評価(同一公開トラフィック): 精度13%向上・再現率19%向上
- 速度とコストの改善により、ジェネリックシークレット検出をプッシュプロテクションに拡張することが現実的になった
- プッシュプロテクションはレイテンシ制約が厳しく、LLMベースでは難しかったため小型モデルを持ち込んだのが設計判断
テキトー教師DotAI 認定講師では「何が変わったのか」を整理しましょう。発表で示された変化は、大きく3つです。
室谷代表取締役整理するとこうです。
- リポジトリオーナー加重のアラート受け入れ率: 11.5%向上(誤検知の削減を示す)
- ポストプッシュスキャンの実行時間中央値: 86%削減
- サービングコスト: 98%以上削減(コンパクトモデルとリモートLLM呼び出しの比較)
- オフライン評価(同一公開トラフィック): 精度13%向上・再現率19%向上
テキトー教師DotAI 認定講師このうち開発者体験に直結するのが受け入れ率です。アラートが「本物だ」と受け入れられる割合が上がるということは、それだけノイズが減ったということなんですよ。
室谷代表取締役MYUUUでもコードを書くメンバーがいるので分かるんですが、セキュリティアラートって多すぎると誰も見なくなるんですよね・・・。受け入れ率が上がるのは、地味だけど一番効く改善なんですよ。
テキトー教師DotAI 認定講師そして86%の時間削減と98%のコスト削減が効いてくる。発表では、この効率化によって「ジェネリックシークレット検出をプッシュプロテクションに拡張することが現実的になった」と説明されています。
つまり速度とコストの改善は、単なる節約ではなく機能拡張の前提条件だったわけです。
つまり速度とコストの改善は、単なる節約ではなく機能拡張の前提条件だったわけです。
室谷代表取締役ここ、見落とされがちなんですけど、すごく本質的なんですよね。速くて安くなったから、これまで事後検出しかできなかったものを、プッシュ前のブロックに広げられる。
順番が大事なんです。
順番が大事なんです。
テキトー教師DotAI 認定講師しかもプッシュプロテクションは、開発者が変更をプッシュする前に結果を返す必要があります。レイテンシの制約が厳しい場所で、LLMベースのパイプラインでは難しかった。
そこに小型モデルを持ち込んだのが今回の設計判断です。
そこに小型モデルを持ち込んだのが今回の設計判断です。
なぜジェネリックシークレットの検出は難しいのか——誤検知とのトレードオフ
構造化シークレットとジェネリックシークレットの検出難易度
構造化された認証情報
- 特徴的なプレフィックスを持つ
- 長さや文字の種類が決まっている
- チェックサムを持つことが多い
- 構文が機密でない文字列と重なりにくい
ジェネリックシークレット
- 特定プロバイダに紐づかないパスワードや接続文字列
- 特徴的なプレフィックスやチェックサムがない
- 構文がビルドID・チェックサム・アセットハッシュ・サンプル値と重なる
- 文脈が決め手になる
室谷代表取締役そもそも、なぜこんなに工夫が必要なのか。ここが記事の肝なんですよね。
テキトー教師DotAI 認定講師発表では「シークレットスキャンは、開発者が検出結果を信頼できてこそ機能する」と説明されています。検出が少なすぎれば本物の認証情報がリポジトリに残る。
アラートが多すぎれば、開発者はシークレットでない文字列の調査に時間を使う。このバランスが難しいと。
アラートが多すぎれば、開発者はシークレットでない文字列の調査に時間を使う。このバランスが難しいと。
室谷代表取締役特に難しいのがジェネリックシークレットなんですよ。特定のプロバイダに紐づかないパスワードや接続文字列のことですよね。
構造化された認証情報は、特徴的なプレフィックスや長さ、文字の種類、チェックサムを持っていることが多い。でもジェネリックはそうじゃない。
構造化された認証情報は、特徴的なプレフィックスや長さ、文字の種類、チェックサムを持っていることが多い。でもジェネリックはそうじゃない。
テキトー教師DotAI 認定講師発表では、ジェネリックシークレットの構文がビルドID、チェックサム、アセットハッシュ、サンプル値といった機密でない文字列と重なると指摘されています。だから「文脈が決め手になる」と。
室谷代表取締役具体例が分かりやすいんですよね。本物らしい例として「本番データベースURLの隣に代入されたパスワード」、無害な似た例として「テストフィクスチャの中の同じ形の値」。
デプロイ設定の接続文字列と、セットアップガイドのlocalhost接続文字列。高エントロピーな値がAPI認証情報に紐づいているか、単なるチェックサムか。
デプロイ設定の接続文字列と、セットアップガイドのlocalhost接続文字列。高エントロピーな値がAPI認証情報に紐づいているか、単なるチェックサムか。
テキトー教師DotAI 認定講師これが「ハードネガティブ」と呼ばれるものですね。認証情報のパターンには一致するけれど、使える認証情報ではない文字列。
ドキュメントのプレースホルダ、テストのトイ例、レダクト済みの値、機密でないID、生成されたフィクスチャなどです。
ドキュメントのプレースホルダ、テストのトイ例、レダクト済みの値、機密でないID、生成されたフィクスチャなどです。
室谷代表取締役ここでルールベースの限界が出るんですよね。例外ルールを足せばいくつかは抑えられるけど、その例外が本物のシークレットを隠してしまうリスクがある。
発表でも「各例外は本物のシークレットを隠すリスクを伴う」と書かれています。
発表でも「各例外は本物のシークレットを隠すリスクを伴う」と書かれています。
テキトー教師DotAI 認定講師だから学習ベースの分類器にした、と。ファイルパス、シークレットの種類、変数名、周辺のコードやテキストといった信号を使えるからです。
受講生さんが「正規表現だけで何とかしようとする」相談をよく持ってくるんですけど、まさにこの壁なんですよね。
受講生さんが「正規表現だけで何とかしようとする」相談をよく持ってくるんですけど、まさにこの壁なんですよね。
2段階パイプラインの仕組み——正規表現とModernBERT分類器の役割分担
室谷代表取締役ここが技術的に一番面白いところです。新しいスキャナは2段階なんですよね。
テキトー教師DotAI 認定講師はい。第1段階が候補生成。
正規表現フィルタが高い再現率でシークレット候補を拾います。速くて決定的で、認証情報らしいパターンの広いファミリーを漏らさず捕まえるために最適化された段階です。
正規表現フィルタが高い再現率でシークレット候補を拾います。速くて決定的で、認証情報らしいパターンの広いファミリーを漏らさず捕まえるために最適化された段階です。
室谷代表取締役第2段階がコンテキスト認識型の分類。微調整されたModernBERT分類器が、候補とその周辺コンテキストを評価する。
プレースホルダ値、サンプル、ドキュメントの断片、生成コンテンツ、機密でない識別子といった誤検知のシグナルを認識するように訓練されている。
プレースホルダ値、サンプル、ドキュメントの断片、生成コンテンツ、機密でない識別子といった誤検知のシグナルを認識するように訓練されている。
テキトー教師DotAI 認定講師重要な設計判断として、発表では「モデルは決定的なスキャンを置き換えるのではなく補完する」と明言されています。正規表現は候補文字列を速く見つけるのに適したツールとして残り、機械学習は「シークレットに見える」と「本物のシークレットである可能性が高い」を区別する部分で使う。
室谷代表取締役役割分担がはっきりしているんですよね。正規表現が広く網を張って、分類器が丁寧に選別する。
発表の図でも「Broad first, careful second」と表現されています。
発表の図でも「Broad first, careful second」と表現されています。
テキトー教師DotAI 認定講師処理の流れを整理するとこうです。
- スキャン:リポジトリの内容、コミット、プルリクエストなど対象サーフェスを走査
- 候補生成:正規表現パターンがトークン、キー、認証情報らしい文字列を特定
- 分類:微調整されたModernBERTが候補とコンテキストを評価し、本物のシークレットである確率を算出
- アラートまたは抑制:信頼度の高い検出だけを先に進め、誤検知の可能性が高いものはフィルタ
室谷代表取締役モデルの入力も決まっていて、候補の値、ファイルパス、シークレットの種類、そして周辺コンテキストを一定量含むんですよね。出力は分類スコアで、スキャナが候補を先に進めるかどうかを決める。
テキトー教師DotAI 認定講師なぜModernBERTなのかも説明されています。コンパクトで効率的、コードに隣接するテキストの分類に適している。
短い候補ウィンドウに対して高スループット・低レイテンシで較正された判断を下す必要があるから、汎用LLMよりも微調整されたエンコーダ分類器のほうがサービング形態として適している、と。
短い候補ウィンドウに対して高スループット・低レイテンシで較正された判断を下す必要があるから、汎用LLMよりも微調整されたエンコーダ分類器のほうがサービング形態として適している、と。
室谷代表取締役しかも自然言語の出力を生成しないから、LLMのレイテンシと計算オーバーヘッドがない。コンテキスト理解はLLMに匹敵するものを、生成なしで得るという発想なんですよね。
テキトー教師DotAI 認定講師学習データも3つのソースを組み合わせています。GitHubリポジトリ由来のプロダクト事例と人間による検証、高再現率の正規表現候補と人間注釈・弱ラベル、そしてドキュメントのシークレットやテストフィクスチャ、公開鍵、チェックサム、構造的な類似物、ニアミスペアといった疎で難しいケースを狙った合成例です。
室谷代表取締役合成データは決定的な検証とモデルベースの品質レビューを通してから使う。そしてデータ分割の前に、同じリポジトリや候補値、事例を共有する行をグループ化して、ニアデュプリケートが訓練と評価の両方に出ないようにしている。
地味だけど、これがないと評価が甘くなるんですよね。
地味だけど、これがないと評価が甘くなるんですよね。
テキトー教師DotAI 認定講師閾値はオフライン評価で選び、本番に近いトラフィックで挙動を検証してから広くロールアウトする。訓練済みモデルはONNX形式にエクスポートし、8bit量子化で高速推論を実現しています。
室谷代表取締役「モデルのサイズは有用性と同じではない」という発表の締めの言葉がいいんですよ。タスクが狭く、決定境界が測定可能で、サービング効率が重要なら、小さい微調整済み分類器が正解になり得る。
これ、AI導入を考える経営者にそのまま刺さる話ですよね。
これ、AI導入を考える経営者にそのまま刺さる話ですよね。
GitHubシークレットスキャンの使い方・設定——無料で使える範囲とSecret Protectionの提供条件
室谷代表取締役ここからは実務の話です。読者が一番知りたいのは「自分のリポジトリで使えるのか」ですよね。
テキトー教師DotAI 認定講師公式ドキュメントで提供範囲が明確にされています。まず公開リポジトリでは、シークレットスキャンは無料で自動実行されます。
室谷代表取締役組織所有のプライベートリポジトリと内部リポジトリは、GitHub TeamまたはGitHub Enterprise CloudでGitHub Secret Protectionを有効にすると利用できる。ユーザー所有のリポジトリは、Enterprise Managed Usersを使うGitHub Enterprise Cloudで利用可能。
GitHub Enterprise Serverでは、エンタープライズがGitHub Secret Protectionを有効にしている場合に利用できる、という整理なんですよね。
GitHub Enterprise Serverでは、エンタープライズがGitHub Secret Protectionを有効にしている場合に利用できる、という整理なんですよね。
テキトー教師DotAI 認定講師整理するとこうです。
- 公開リポジトリ:シークレットスキャンが無料で自動実行
- 組織所有のプライベート/内部リポジトリ:GitHub TeamまたはGitHub Enterprise CloudでGitHub Secret Protectionを有効化
- ユーザー所有リポジトリ:Enterprise Managed Usersを使うGitHub Enterprise Cloudで利用可能
- GitHub Enterprise Server:エンタープライズがGitHub Secret Protectionを有効にしている場合に利用可能
室谷代表取締役つまり「publicなら無料、privateはSecret Protectionが必要」という基本構造は変わっていないんですよね。今回の分類器の改善は、この提供範囲の中で効いてくる話です。
テキトー教師DotAI 認定講師検出対象も公式ドキュメントで3カテゴリに分けられています。ジェネリック(正規表現ベース)、AI検出(AIモデルベース)、プロバイダ(正規表現ベース)です。
室谷代表取締役ジェネリックの例としてはRSA秘密鍵やデータベース接続文字列。プロバイダはAWS、Azure、Stripeなど特定サービスに紐づくもの。
AI検出はCopilotを使ってパスワードなどの非構造化シークレットを検出するもので、現状パターンは「password」のみなんですよね。
AI検出はCopilotを使ってパスワードなどの非構造化シークレットを検出するもので、現状パターンは「password」のみなんですよね。
テキトー教師DotAI 認定講師ここは誤解されやすいので丁寧に言うと、AI検出パターンはプッシュプロテクションと有効性チェックに対応していません。またジェネリックパターンは有効性チェック非対応です。
対応状況はカテゴリごとに違うので、公式の表で確認するのが確実です。
対応状況はカテゴリごとに違うので、公式の表で確認するのが確実です。
室谷代表取締役プロバイダパターンは531個もサポートされていて、パートナー通知やプッシュプロテクション、有効性チェック、メタデータチェック、Base64対応など、パターンごとに対応可否が違うんですよ。自社で使っているサービスのトークンが対応しているかは、一度確認しておいたほうがいいですよね。
テキトー教師DotAI 認定講師アラートは3種類あります。ユーザーアラートはリポジトリのSecurity and qualityタブに報告されるもの。
プッシュプロテクションアラートは、コントリビューターがプッシュプロテクションをバイパスしたときに報告されるもの。パートナーアラートは、シークレットスキャンのパートナープログラムに参加するシークレットプロバイダへ直接報告され、リポジトリのタブには表示されません。
プッシュプロテクションアラートは、コントリビューターがプッシュプロテクションをバイパスしたときに報告されるもの。パートナーアラートは、シークレットスキャンのパートナープログラムに参加するシークレットプロバイダへ直接報告され、リポジトリのタブには表示されません。
室谷代表取締役アラートへの対処は、無効化・ローテーション・履歴からの削除が基本なんですけど、今回の発表はそこに踏み込んだ話ではないので、詳細は公式ドキュメントに譲るのが正確です。
プッシュプロテクションとポストプッシュスキャンの違いと運用のポイント
テキトー教師DotAI 認定講師最後に運用の話です。シークレットスキャンは2つの時点で動きます。
プッシュプロテクションとポストプッシュスキャンです。
プッシュプロテクションとポストプッシュスキャンです。
室谷代表取締役プッシュプロテクションは、プッシュが受け入れられる前に変更をスキャンして、シークレットがリポジトリに入るのを防ぐ。開発者がその場で対処できる機会を提供するんですよね。
ポストプッシュスキャンは、コミット後に継続的にリポジトリの内容をスキャンして、潜在的なシークレットが検出されたらアラートを作る。
ポストプッシュスキャンは、コミット後に継続的にリポジトリの内容をスキャンして、潜在的なシークレットが検出されたらアラートを作る。
テキトー教師DotAI 認定講師今回の発表の面白さは、86%の時間削減によってジェネリックシークレット検出をプッシュプロテクションに拡張することが現実的になった、という点です。従来はコミット後の検出が中心だったものが、プッシュ前のブロックにも広がる可能性が出てきた。
室谷代表取締役プッシュプロテクションの設定は、リポジトリ、組織、エンタープライズの各レベルで有効化できるんですよね。ただしリポジトリ向けはGitHub Secret Protectionが必要で、デフォルトでは無効。
リポジトリ管理者、組織オーナー、セキュリティマネージャー、エンタープライズオーナーが有効化できる。
リポジトリ管理者、組織オーナー、セキュリティマネージャー、エンタープライズオーナーが有効化できる。
テキトー教師DotAI 認定講師一方でユーザー向けのプッシュプロテクションはGitHub.com限定で、デフォルト有効。公開リポジトリへのシークレットのプッシュを止めますが、リポジトリレベルでも有効にしていない限り、バイパス時にアラートは生成されません。
室谷代表取締役ここは運用で勘違いしやすいところですよね。ユーザー向けはデフォルトで守ってくれるけど、アラートが残るかどうかは別の話。
組織として記録を残したいなら、リポジトリレベルの設定も見ておく必要がある。
組織として記録を残したいなら、リポジトリレベルの設定も見ておく必要がある。
テキトー教師DotAI 認定講師バイパスの扱いも決まっています。リポジトリ向けのプッシュプロテクションでは、デフォルトで書き込みアクセスを持つ誰もがバイパス理由を指定してバイパスできます。
バイパスされると、リポジトリ、組織、エンタープライズのSecurity and qualityタブにアラートが作られ、バイパスイベントが監査ログに追加されます。
バイパスされると、リポジトリ、組織、エンタープライズのSecurity and qualityタブにアラートが作られ、バイパスイベントが監査ログに追加されます。
室谷代表取締役ブロックされる対象も広いんですよね。コマンドラインからのプッシュ、GitHub UIでのコミット、GitHubへのファイルアップロード、REST APIへのリクエスト、GitHub MCPサーバーとのやり取り(公開リポジトリのみ)。
開発経路が増えるほど、入口での防御が効いてくる。
開発経路が増えるほど、入口での防御が効いてくる。
テキトー教師DotAI 認定講師発表では、今後の方向性として2つが示されています。1つは継続的改善のフライホイール。
本番のフィードバックループから新しい偽陰性と偽陽性を特定し、実世界のシグナルを高品質な訓練・評価データに変えていく。もう1つは新しいモデルアーキテクチャの探索で、シークレットの検出と抽出を1ステップで行い、精度とスケールを保ちながらパイプラインの複雑さを減らすアプローチを検討していると。
本番のフィードバックループから新しい偽陰性と偽陽性を特定し、実世界のシグナルを高品質な訓練・評価データに変えていく。もう1つは新しいモデルアーキテクチャの探索で、シークレットの検出と抽出を1ステップで行い、精度とスケールを保ちながらパイプラインの複雑さを減らすアプローチを検討していると。
室谷代表取締役この「検出と抽出を1ステップで」というのは、要するにパイプラインを短くする方向なんですよね。今回2段階に整理したものを、さらに畳んでいけるかという挑戦で。
今後のアップデートが楽しみです。
今後のアップデートが楽しみです。
よくある質問
室谷代表取締役ここまでの話を踏まえて、よく聞かれる点を整理しておきますね。
テキトー教師DotAI 認定講師まず「GitHubのシークレットスキャンとは何か」。これはリポジトリ内に誤ってコミットされた認証情報(APIキー、パスワード、秘密鍵など)を検出する機能です。
発表では、プッシュプロテクションがプッシュ前、ポストプッシュスキャンがコミット後の2つの時点で動くと説明されています。
発表では、プッシュプロテクションがプッシュ前、ポストプッシュスキャンがコミット後の2つの時点で動くと説明されています。
室谷代表取締役「無料で使えるのか」という点。公開リポジトリでは無料で自動実行されます。
組織所有のプライベート/内部リポジトリはGitHub Secret Protection(GitHub TeamまたはGitHub Enterprise Cloud)が必要です。
組織所有のプライベート/内部リポジトリはGitHub Secret Protection(GitHub TeamまたはGitHub Enterprise Cloud)が必要です。
テキトー教師DotAI 認定講師「誤検知はどう減ったのか」。コンテキスト認識型分類器がファイルパス、変数名、周辺コードを読んで、プレースホルダやテストフィクスチャ、チェックサムをフィルタします。
その結果、リポジトリオーナー加重の受け入れ率が11.5%向上しました。
その結果、リポジトリオーナー加重の受け入れ率が11.5%向上しました。
室谷代表取締役「どれくらい速くなったのか」。ポストプッシュスキャンの実行時間中央値が86%削減、サービングコストが98%以上削減です。
オフライン評価では精度13%向上・再現率19%向上という数字も示されています。
オフライン評価では精度13%向上・再現率19%向上という数字も示されています。
テキトー教師DotAI 認定講師「どんなシークレットパターンに対応しているのか」。ジェネリック、AI検出、プロバイダの3カテゴリで、プロバイダパターンは531個がサポートされています。
パターンごとにプッシュプロテクションや有効性チェックの対応状況が異なるので、公式ドキュメントの表で確認してください。
パターンごとにプッシュプロテクションや有効性チェックの対応状況が異なるので、公式ドキュメントの表で確認してください。
室谷代表取締役「プッシュプロテクションはデフォルトで有効なのか」。リポジトリ向けはデフォルト無効で、GitHub Secret Protectionが必要です。
ユーザー向けはGitHub.com限定でデフォルト有効ですが、リポジトリレベルでも有効にしない限りバイパス時のアラートは生成されません。
ユーザー向けはGitHub.com限定でデフォルト有効ですが、リポジトリレベルでも有効にしない限りバイパス時のアラートは生成されません。
テキトー教師DotAI 認定講師最後に「今回の発表で料金体系は変わったのか」。発表と公式ドキュメントで示されているのは提供範囲の条件であり、新しい料金が示されたわけではありません。
料金の詳細は現時点では明らかにされていませんので、公式の見積もりページで確認するのが確実です。
料金の詳細は現時点では明らかにされていませんので、公式の見積もりページで確認するのが確実です。
室谷代表取締役総じて、地味だけど開発者体験に直結する改善なんですよね。アラートを信頼できるから見るようになる、速いからプッシュ前に止められる、安いからカバレッジを広げられる。
この3つが揃ったのが今回の発表の価値だと思います。
この3つが揃ったのが今回の発表の価値だと思います。
