エージェントが前提になる実務で、環境・知識・判断の設計前提が揺らぐ

WebflowがSOCなしでセキュリティをスケールさせた内製AIの実際

Webflowのセキュリティチームが、1年かけてAIを検知・対応ワークフローに組み込んだ。SOCなし。

（SOC: Security Operations Center。セキュリティ監視と対応を行う専門組織）アナリストのシフト制なし。セキュリティエンジニアの小チームが検知ルールの作成からインシデント対応まで全工程を担う。そこにAIを持ち込んだ結果、1四半期で504時間を節約した。

この話の面白さは、AIの使いどころにある。彼らはベンダー製品を買い足していない。既存のSOCツールの断片化されたスタックにAIバッジを貼り直すのではなく、内製で組み上げた。コンテキストの統合度と制御権を手放さずに済む。この判断は実務的に筋が良い。外部製品のAI連携は、自社のインフラコンテキストをどこまで吸えるかが常にボトルになる。

具体的な変化は二段階で起きている。一段目はトリアージの前処理。従来はアラートのチケットを開き、コンテキストを引き、資産の所有者を確認し、関連ログを相関させる。難しくはないが時間がかかる。ある四半期に検知数が200%増えたとき、この手作業モデルが限界を迎えた。そこでAIに前処理を任せた。エンジニアがアラートを見る時点で、チケットには関連コンテキスト・履歴シグナル・初期重要度判定が揃っている。さらに、誤検知と高信頼で判定されたパターンは自動クローズする。この判断基準は数ヶ月のチューニングと検証の上に構築されており、環境変化に合わせて定期的に見直しているという。

二段目は、複雑な調査における認知負荷の軽減。プレイブックが当てはまらない曖昧なインシデントで、LLMにログの要約・過去事例の提示・次ステップの提案・初期タイムラインの作成をさせる。人間がすべての重要な判断を行う前提は崩さない。AIが提示し、エンジニアが検証・決定・実行する。この境界が曖昧になれば、監査不能で事後説明も困難なリスクを生むと彼らは明言している。信頼は段階的に稼ぐものだとし、新規の検知ロジックを監視なしで走らせるのと同じ考え方だ。

ポストインシデントでのAI活用についても触れられていた。振り返りの自動化やナレッジベースの構築など、インシデント後の文脈整理こそAIが最も価値を発揮する領域の一つだろう。

この事例で気になるのは、自動クローズの判断基準をどう管理するかだ。環境が変われば誤検知の判定基準もずれる。定期レビューをしているとあるが、そのレビュー自体をどうスケールさせるか。AIに任せる部分が増えるほど、人間のレビューがボトルネックになる可能性はある。

それでも、SOCの人的スケールに頼らない構え方は現実的だ。セキュリティエンジニアの採用は常に厳しい。アラートの前処理をAIに肩代わりさせ、人間の認知リソースを判断そのものに集中させる。この分工は、マイクロサービスの運用でCIパイプラインに定型作業を任せるのと同じ発想だ。

エージェントが環境要求をトラフィックに変えたとき、プラットフォームはどう動くか

プラットフォームエンジニアリングは勝利を収めた。90%の組織が内部プラットフォームを少なくとも1つ採用し、ゴールデンパスは正統な手法として定着した。かつて数日かかっていた環境リクエストが数時間で処理されるようになった。自分たちが設定した基準で言えば、それは勝利だ。

そこに、プラットフォームがこれまで遭遇した中で最も要求の厳しい顧客が現れた。開発者ではない。コーディングエージェントだ。

エージェントは自分の作業を検証するために環境を要求する。その様子は、クライアントがAPIを呼ぶのに近い。バースト的に、並行して、寿命は分単位、応答は秒単位で期待される。100人の開発者がいる組織で、各エンジニアが1日に数回のエージェントセッションを監督すると、昼前には数百の環境リクエストが発生する。各リクエストはリアルな依存関係を必要とし、検証が終わった瞬間に死骸になる。これはチケットキューではない。トラフィックだ。

需要は推測ではない。GitHubのOctoverseは、月4,320万のプルリクエストがマージされ、前年比23%増であると報告している。Copilotのコーディングエージェントだけで、最初の5ヶ月で100万以上のプルリクエストを開いた。それらの変更はすべて、マージ前にリアルな環境で実行される必要がある。Stack Overflowの2025年調査では、プロの開発者の半数がすでに毎日AIツールを使用している。環境の需要はもはや人数に追従しない。人数×エージェント数×イテレーション数に追従する。

従来の2つのモデルはどちらも破綻する。フルコピーを毎回渡す複製モデルは、40サービスのシステムでデータベースとキュー付きならコピー1つあたり数ドル/時間、組み立てに数十分かかる。並行数を掛けると、コストはエージェントの活動に比例して増大する。エージェントは秒で反復するが、環境到着を数十分待てない。ウォームプールの事前プロビジョニングも無駄を移動するだけだ。エージェントの需要はバースト的で、ピークに合わせたプールは谷で遊休し、谷に合わせたプールはピークでキューを作る。

一方、1つのステージング環境にテナントを順次入れる共有モデルも機能しない。Littleの法則が1961年からこの失敗モードを記述している。

（リトルの法則：システム内の平均滞在数は、平均到着率に平均処理時間を掛けたものに等しいという待ち行列理論の基本原則）到着率が環境の吸収率に近づくと、待ち時間は緩やかに劣化するのではなく爆発する。エージェントは到着数を5〜10倍にするが、完了率は固定されたままだ。分離も失敗する。1つの壊れた変更が背後の全テナントの環境を汚染する。チームはバッチ化で対応し、変更を大きなデプロイに積み上げる。すると障害の爆発半径が広がり、占有時間が延びる。キューがまさにキューを悪化させる行動を教え込む。

私がマイクロサービスを書いていて感じるのは、この「環境のサービング化」が一番の論点だ。Kubernetesで名前空間を分けて環境を作る手法は今でも有効だが、エージェントの速度には追いつかない。Terraformで環境をプロビジョニングするパイプラインは、分単位の寿命には遅すぎる。プロビジョニングからサービングへの転換は、CI/CDパイプラインそのものの設計を変える必要がある。環境を静的なリソースではなく、レイテンシ・並行性・リクエストあたりの限界コスト・マルチテナントでの安全性で評価されるサービングシステムとして扱う。具体的にどう実装するかは、まだ各社が模索している段階だろう。Signadotのようなツールがこの領域で名前を挙げられているが、

（Signadotは、リクエストルーティングを用いて仮想的な環境を瞬時に作成する「環境の仮想化」を提供するツール）エコシステム全体の解は固まっていない。私の実務でも、テスト環境の枯渇はすでに起きている。エージェントが当たり前になるなら、環境の提供方法を抜本的に考え直す時期に来ている。

Pinecone Nexusが描く「エージェントのための知識層」とRAGの限界

（RAG: Retrieval-Augmented Generation。外部知識を検索してLLMのコンテキストに注入し、回答精度を高める手法）

PineconeがNexusというナレッジエンジンを一般提供した。エンタープライズの散在するデータを構造化レイヤーに変換し、AIエージェントが直接クエリできるようにするものだ。Pineconeの主張は明確で、LLMは世界知識に強く、ベクトルDBは埋もれた情報を掘り出すのが得意だが、企業が本当に依存しているのはビジネスコンテキストである。契約書、Wiki、HR文書、会議メモ、サポートチケット、財務記録に散らばる知識だ。

ここで指摘されている問題は、エージェントを実際に動かしている人なら痛いほど分かる。タスクのたびに検索を繰り返すのは非効率で、トークンコストも跳ね上がる。回答が遅くなり、不完全にもなりやすい。Nexusはこの検索ループの外側に知識を構造化する段階を置く。一度のキュレーションで済ませ、クエリごとのトークン消費を前置きに追い出す設計だ。

数値は興味深い。法務ドメインでNexusは全タスクを完了したのに対し、コーディングエージェントは6%、RAGシステムは66%だった。RAGが苦戦したのは「教義の統合、複数事例の横断推論、多数ソースの統合が必要な質問」だという。まさにRAGの苦手な領域。エンタープライズデータ管理でも精度90%に対しRAGは65%。キュレーションコストはドキュメント1件あたり$0.0038。トークン消費は約9〜15倍の削減らしい。

アーキテクチャはワークスペース、コンテキスト、マニフェストの3層構造。マニフェストでデータの取り込みと変換を定義する。ここが重要で、専門家がクエリ実行前にドメイン知識をブループリントとして組み込む。エージェントがコーパスの構造を推測するのではなく、専門家の理解を継承する形だ。データソースはローカルファイル、Box、Microsoft OneLakeに対応。Google Drive、Slack、GitHub、Notion、Confluence、S3は近日対応とされている。クエリ言語としてKnowQLを提供し、プレイグラウンドも用意されている。BYOCデプロイメントオプションもある。

気になるのは、この構造化の事前コストだ。マニフェストを書き、コンテキストを設計し、専門家の知識をブループリントに落とし込む。RAGの手軽さと比べると、明らかに初期投資が重い。ただ、エージェントの完了率が6%から100%に跳ね上がるなら、投資に見合う場面はある。法務や財務のように正確性が命の領域か。頻繁に構造が変わるドメインでは、マニフェストのメンテナンスが負担になるかもしれない。LlamaIndexやCogniteといった類似ソリューションとの差分も、実務で選ぶなら押さえておきたいところだ。

Grok 4.5の「Opusと同じコードを4分の1のトークンで」という売り文をRustの実務タスクで検証したら、小さい仕事では逆転した

xAIがGrok 4.5を7月8日にリリースした。学習データにCursorのセッションログを混ぜている。売りは2つ。Claude Opus 4.8と同じコードを書くこと。そして出力トークンを約4.2分の1で済ませること。価格もGrokが入力100万トークン2ドル・出力6ドルに対し、Opusは5ドル・25ドル。半額以下だ。Anthropicのシェアを狙い撃ちにしていると読める。

筆者がfdというRust製のファイル検索ツールで3つの実務タスクを回した。CursorのAgentモードで同一プロンプトを与え、モデルだけを変える。テストはバグ修正・リファクタ・機能追加の3本。

1つ目のバグ修正でxAIの主張が揺らぐ。--no-ignore-vcsフラグのバグ(issue #907、2021年の実修正の直前コミットを使用)を両モデルに直させた。結果のコードはバイト単位で同一。差分は1行削除だけ。70テストも通る。しかしトークン数はOpusが174.1K、Grokが210.2K。Grokのほうが2万トークン多く消費し、時間も46秒対30秒で遅い。小さいタスクではOpusが勝った。

2つ目のリファクタで状況が変わる。construct_config関数を新モジュールに切り出すタスク。コード品質は再び同等。264テストが両方で通る。差分サイズも6行以内の差。しかしトークン消費がGrok 197.1K対Opus 953.7K。4.8倍の開きだ。コストもGrok 0.27ドル対Opus 1.67ドル。1つ目のテストでOpusが速くて安かったから、この逆転は驚きだと筆者は書いている。

3つ目の機能追加(--countフラグの実装)の結果は元記事が途切れていて分からない。ただ傾向は見える。タスクが大きくなるほどGrokのトークン効率の良さが効いてくる。小さなバグ修正ならOpusの少ないコンテキストで足りる。複数ファイルをまたぐリファクタになると、Opusが冗長な出力を大量に吐いているように見える。

開発者のワークフローでどこが論点か。CursorやCopilotでコーディングしている身からすると、トークン単価は直接月額に響く。1日何回Agentモードを回すかによるが、リファクタ1回で1.67ドルと0.27ドルの差は月次で無視できない。ただしコストだけ見て乗り換えるのは早い。SWE-Bench ProではOpusがまだ勝っている。複雑なバグ修正の精度でGrokがどこまで食い込めるか、ベンチマークの「as good, for far less」がどの範囲まで成り立つか。そこが実務での判断の分かれ目になる。

Dolt 2.0、バージョン管理データベースの実用性が一段上がった

DoltHubがDolt 2.0をリリースした。Gitのようなバージョン管理を組み込んだMySQL互換データベースのメジャーアップデートだ。目玉は自動ガベージコレクションとアーカイブ圧縮のデフォルト有効化。

Doltはcopy-on-writeで動く。コミットされていない中間状態がすべてディスクに残る仕組みで、特にインポート時はゴミが溜まりやすい。1.xでは手動でGCを走らせる必要があった。2.0からは自動で整理される。地味だが運用負荷は確実に減る。

新しいディスクフォーマット「archives」も追加された。辞書圧縮で重複を排除し、ストレージフットプリントを30-50%削減するという。バージョン管理の性質上、履歴分のデータを抱え込むのは避けられない。圧縮がデフォルトで効くのは、長期運用でのディスク枯渇懸念をかなり緩和するはずだ。

パフォーマンスの向上も大きい。以前はMySQL比で読み取り10倍遅、書き込み20倍遅かった。それが読み取り5%速、書き込み13%速まで追いついたと主張している。sysbenchでの計測とのことだが、ベンチマークの条件次第な面はある。それでもバージョン管理のオーバーヘッドが実用上問題にならないレベルに達したという主張は、評価に値する。

ベクトルインデックスのバージョン管理もベータで入った。MariaDBのVector型を使う。読み取りパスにまだギャップがあり、ベータ外れは先になりそうだ。ただベクトルデータをバージョン管理できるデータベースは他にない。RAG運用でモデル更新時のベクトル再計算をどう扱うか悩んでいるチームには、検討の余地があるかもしれない。

データのバージョン管理はLakeFSやNessieなども別アプローチで狙っている領域だ。DoltはMySQL互換のクエリインターフェースを提供する点で差別化されている。PostgreSQL互換のDoltgreSQLも同じストレージエンジンを使うが、まだベータ。こっちがGAになれば採用の敷居はさらに下がる。

データベースにブランチ・マージを持ち込む発想自体は珍しくなくなってきている。本番データで安全に実験し、変更をロールバックできるというメリットは理解できる。ただ実際のワークフローに組み込むには、周辺ツールやCI/CDの対応も考える必要がある。マイグレーション運用でDoltのブランチをどう扱うか、まだ手探りの部分がありそうだ。

まとめ

4つの話題に共通するのは、AIエージェントが実務に入り込んだことで、周辺のインフラやツールの設計前提が揺らいでいる点だ。エージェントは人間より速く、並行的に、小さな単位でリソースを消費する。環境プロビジョニングは静的なリクエストからトラフィックに変わり、知識の供給は検索の都度組み立てから事前の構造化へと移り、セキュリティの分工も人間の認知リソースを判断に集中させる形に再編されている。

この変化に対し、既存の仕組みはどこも追いついていない。Kubernetesの名前空間による環境分けやTerraformのプロビジョニングパイプラインは、分単位の寿命を持つエージェントの要求には遅すぎる。RAGの検索ループはトークンコストと精度の両面で限界を露呈している。モデルの選択にしても、小さいタスクと大きいタスクで最適解が逆転する。いずれも「エージェントの特性に合わせて土台を作り直す」方向に動いている。

ただし、事前投資のコストは無視できない。Pineconeのマニフェスト設計、Doltのブランチを組み込んだマイグレーション運用、Webflowの自動クローズ基準の管理。構造化や自動化を進めるほど、人間のレビューや設計がボトルネックになる矛盾を抱えている。エージェントに任せる部分が増えれば、その境界の管理を人間がどうスケールさせるかという問題に置き換わる。

エージェントが当たり前になるなら、環境の提供方法、知識の構造化、モデルの使い分けを抜本的に考え直す時期に来ている。解はまだ固まっていない。各現場で手探りが続くが、その手探りこそが今の技術動向の核心だ。

参照記事

記録日: 2026-07-19