OPENAI SEARCH INSIGHT

2026.10.15 / OpenAI最新情報

Block、OpenAI Daybreakで脆弱性修正を18分へ短縮

この記事で分かること: BlockがOpenAIのAI技術をどのように脆弱性調査、検知チューニング、修正提案へ組み込み、人間による統制を維持しているのかを知りたい。

OpenAIは2026年10月14日、Square、Cash App、Afterpayを展開するBlockが、OpenAI Daybreakを含むAIシステムをセキュリティ業務に導入した事例を公開した。Blockは脆弱性の発見、検知、対応をAIで支援し、従来は数日から数週間を要した作業の一部を数時間へ圧縮している。

注目すべき数値は、直近のレッドチーム演習で高レベルの脆弱性情報を投入してから自動の修正案が出るまで18分だった点だ。ただしBlockは、AIの出力をそのまま適用する運用ではなく、すべての結果を人間が検証し、必要に応じて担当者が処理を引き継ぐ設計を採っている。

OpenAI公式発表で示されたBlockの取り組み

今回の発表はOpenAIの公式ニュース「How Block is building AI-powered security with OpenAI technology」として公開された。対象企業は北米のエンタープライズ企業であるBlockで、業種は金融・テクノロジー、掲載プロダクトはCodexとされている。

OpenAIによると、Blockのセキュリティチームは「OpenAI Defense Factory」を活用し、脆弱性の発見、検知、対応をAIで扱っている。その中でOpenAI Daybreakを含むAIシステムを用い、セキュリティ担当者が戦略的な業務に集中できるよう、脆弱性修正までの時間を縮めることを狙う。

Blockの最高情報セキュリティ責任者であるJames Nettesheim氏は、AIが「人間の意図から行動までの時間」を圧縮すると説明する。攻撃者の俊敏性が優位とみなされてきた状況に対し、AIツールによって防御側もAI活用の速度に追随できるというのが同氏の見解だ。

検知ルールの検証を7か月分のテレメトリーで再生

公式発表で具体例として挙げられたのが、検知ルールのチューニングだ。Blockでは各調査における生のクエリー証拠を保存しており、提案された検知変更を本番の過去テレメトリーに対して再生できる。

この仕組みにより、7か月分のテレメトリーに対する検知変更の再生を1時間未満で実行できるという。以前は多数の過去ケースを人手で再クエリーする必要があり、時間負荷が大きいため、実務上は十分に実施されないこともあったとOpenAIは説明している。

検知ロジックの変更は、誤検知の増加や検知漏れを引き起こし得る。過去データで変更案を再評価する能力は、生成AIによるルール作成を速くするだけでなく、変更前後の挙動を監査可能な形で比較する基盤として重要になる。

調査とトリアージで公表された定量成果

Blockは自動トリアージによって、トリアージ処理能力が50%向上し、インテリジェンス収集と調査も50%増加したとしている。また、アラートごとに関連要素を深く調査する自律的なハンティング能力も新たに得たという。

公式掲載の結果では、偽陽性のトリアージから担当者へ戻った時間は四半期当たり約600アナリスト時間、AIシステムが完了した調査は四半期当たり約1,100アナリスト時間とされる。これらはBlockの事例であり、他社環境で同水準の効果を保証する数値ではない。

OpenAIの説明では、AIは単一のアラートを個別に処理するだけでなく、複数のログや証拠を横断して関連性を仮説化する。あるエンドポイントの通常のアラートについても、証拠内に付随していた指標をアイデンティティログと結び付け、より大きな問題群を浮上させた事例が紹介されている。

Daybreakを中心にした攻撃経路の分析と修正提案

従来型のスキャンツールは、単一の脆弱性を孤立した所見として通知することが多い。BlockはDaybreakを使い、攻撃パターンを仮説化し、複数の攻撃をつないで侵害に至る一連の経路として捉えることを目指している。

OpenAIは、社内システムに関する少数のヒントを与えたレッドチーム演習で、モデルがSQLインジェクション、権限昇格、足掛かりの確保、認証情報列挙、他システムへのピボットを含む攻撃経路を約2時間で連結したと紹介する。人間のレッドチーム担当者なら通常は数日かかる作業だという。

一方、脆弱性を見つけるだけでは対策として不十分だ。Blockのプロセスでは、問題のコード箇所と所有者を特定し、修正案を作成し、悪用可能性と修正の有効性を確認する。修正案の作成からコード変更の展開までには、人間が関与して誘導・検証することが明記されている。

モデル選択と人間の介入を組み込む設計

Blockは、常に最新モデルを一律に利用するのではなく、仕事ごとに異なるモデルを選ぶ運用へ移行したとしている。セキュリティ用のハーネスはDaybreak上に構築され、タスクを適切なモデルへルーティングする役割を持つ。

このハーネスには、人間がタスクを引き継ぐためのフックと、エージェント同士が互いの作業を検証するための仕組みも含まれる。チームは内部ベンチマークと実運用での性能に対して継続的に評価し、責任ある対応が必要な場合には人間のレビューへ処理を回すとしている。

AIエージェントは技術的に処理できても、組織固有の背景、過去の判断理由、事業上の優先順位まで自動的に把握するわけではない。BlockはAIの判断が実務で検証されるにつれ、より機微なシステムへ適用するリスク水準を段階的に上げる考えを示している。

Agent Memories編集部の考察

日本のセキュリティ組織が評価すべきなのは、「AIで何分短縮できるか」だけではない。Blockの事例が示す実務上の要点は、検知変更の検証用データ、証拠の保存、担当者の介入点、評価指標を、AI導入前から運用設計へ組み込んでいることにある。

特にSOCやプロダクトセキュリティでは、生成AIにアラート要約や修正コードの作成を任せる前に、変更を再生できるログ基盤、修正の承認責任、デプロイ前の検証手順を明文化したい。AIの出力品質だけを測るのではなく、誤った提案が本番へ到達しない統制を評価対象にする必要がある。

また、タスク別のモデル選択は、性能、コスト、レイテンシー、データ取り扱い要件を分離して判断する考え方につながる。脆弱性の優先順位付け、ログの初期分析、検知ルール案、修正案の生成を同じリスク区分として扱わず、承認要件を変えることが現実的だ。

ただし、Blockの時間短縮や処理能力向上は、同社のログ資産、セキュリティハーネス、評価体制を前提とする公式事例である。自社で導入効果を見積もる際は、同様の数値を前提にせず、まず偽陽性トリアージや過去アラートの再評価など、結果を人間が検証しやすい領域から測定するのが妥当だろう。

よくある質問

BlockはAIに脆弱性修正を完全自動で任せているのか

いいえ。OpenAI公式発表では、Blockは人間がすべての結果を検証すると説明している。修正ではコード上の所在と所有者を特定し、修正案、悪用可能性、修正済みであることを確認する過程に人間が関与する。

18分という時間は何を指すのか

直近のレッドチーム演習において、高レベルの脆弱性を提出してから、自動化された修正案が提示されるまでの時間を指す。脆弱性の受付から本番環境への修正適用完了までを一律に18分とする意味ではない。

OpenAI Daybreakは何に使われているのか

公式説明では、Daybreakを含むAIシステムが、脆弱性の発見、検知、対応を支援する。Blockでは攻撃経路の仮説化、複数ログの横断分析、タスクに応じたモデルへのルーティングなどに関連して紹介されている。

日本企業が最初に確認すべき運用条件は何か

ログや証拠の保存範囲、AIへ渡すデータの管理、提案の評価方法、人間が承認・差し戻し・引き継ぎを行う地点を確認すべきだ。加えて、検知ルールと修正コードの双方について、変更後の影響を検証する仕組みが必要になる。

まとめ

OpenAIの公式事例でBlockは、OpenAI Daybreakを含むAIシステムを活用し、検知変更の再生、アラート調査、攻撃経路の分析、修正案の作成を高速化している。公表値には、7か月分のテレメトリー再生が1時間未満、修正案の提示が18分、四半期当たり約1,100時間の調査実行が含まれる。

実務上の核心は、AIによる自動化の範囲を広げながらも、評価、証拠、モデル選択、人間によるレビューを一体で設計している点にある。導入を検討する組織は、速度向上と同時に、変更検証と責任分界をどこまで運用へ落とし込めるかを評価したい。

本カテゴリはMiraigent / Agent Memoriesによる非公式編集記事です。OpenAIとの提携・承認・後援を示すものではありません。