自動化が境界を明らかにする：サービング化するETLからエージェントの環境トラフィックまで

Spark 4.2がベクトル検索を飲み込む、ETLエンジンの領域が変わる場所

Apache Spark 4.2がリリースされた。目玉はネイティブなベクトル検索だ。vector distance、similarity functions、vector normalization、vector aggregation、そしてNEAREST BYというSQL演算子。top-K類似度検索をSparkのSQLエンジン内で完結できる仕組みになった。

これまでRAGパイプラインを組むとき、Sparkで前処理したデータをPineconeやWeaviateに同期させる、という構成をよく見てきた。同期がずれる。データ量が増えると転送も重い。Spark 4.2のNEAREST BYが実用レベルの性能を出せれば、この往復が減る。ETLエンジンがそのまま検索エンジンを兼ねる形だ。

ただし、どこまで速いかは分からない。専用ベクトルDBが持つHNSWなどのインデックス最適化と

（HNSW: Hierarchical Navigable Small World。高次元ベクトルをグラフ構造で近似的に高速検索するアルゴリズム）、Sparkのオプティマイザがどこまで戦えるか。大規模なコーパスで億単位のベクトルを扱う場合は、まだ別システムが必要かもしれない。

Governed metric viewsも地味に効く機能だ。ビジネス指標の定義を一元化し、集計セマンティクスを保持する。BIチームとMLチームで「売上」の定義が食い違ってモデルが狂う、という事故を防げる。指標を一度定義すれば、人間のクエリでもAIの推論でも同じ結果を返す。これは実務で地味に嬉しい。

Python周りも進んだ。Arrow C Data InterfaceとPyCapsule protocolで, Spark DataFrameをPolarsやDuckDBにコピーなしで渡せる。Arrow最適化UDFがデフォルトになったのも大きい。PySparkの遅さに悩んできた人間にはありがたい。

Auto CDCも見逃せない。Spark Declarative Pipelinesで変更データキャプチャがファーストクラスになり、マージロジックを手書きしなくて済む。CHANGES SQL句で差分を取れる。ストリーミングとバッチの境界がさらに薄くなった。

ネイティブのGEOMETRY/GEOGRAPHY型とST_*関数も入った。位置データを扱うチームが別の空間拡張に依存する理由が減る。

全体を見て、Sparkが「データを準備して渡す」層から「データを準備して直接提供する」層にシフトしている。ETLだけじゃなく、サービング層の一部になりつつある。うちのチームもSparkでETLして別システムに渡す構成が多いので、どこを減らせるか考えたい。

GPUノードが勝手に直る世界で気をつけるべきこと

AWSがEKS Node Monitoring Agentをオープンソースにした。4月のことだ。このエージェントは、ノードのハードウェア障害を検知してKubernetesのNodeConditionを書き込み、Karpenterがノードを自動置換するきっかけを作る。EKS Auto Modeでは、この自動修復がデフォルトで動く。アドオンなし、コントローラー設定なし、修復ポリシー記述なし。

なぜこれが重要か。数千クラスターでKubernetesを運用していると、「稀な」ハードウェア障害が毎日どこかで起きるからだ。GPUがPCIeバスから脱落する。コンテナランタイムがスタックする。ネットワークインターフェースが消える。深夜3時に障害が起きれば、オペレーターが起きるまでワークロードは劣化したまま。この対人依存をなくすのが自己修復の目的だ。

運用から得られた6つの教訓が興味深い。特に刺さったのが3つ。

Reason codesはAPI契約として扱え。下流の修復コントローラーやダッシュボードは、文字列マッチでreason codesに反応する。追加は機能だが、名前変更や重大度変更は破壊的変更だ。APIバージョニングと同じ頭で計画すべきという指摘。Kubernetesのエコシステムでは、NodeConditionのreasonを勝手に変えるコントローラーがいると即座に事故る。この原則は汎用的に使える。

AbsentとUnknownは別物だ。監視していない状態と、監視しているが判断できない状態は、下流の自動化にとって意味が違う。無効なモニターがUnknownを書き込むと、どこかのコントローラーがそれに基づいて動いてしまう。監視していないなら何も出力しない。シンプルだが、実装で間違えやすい箇所だろう。

テレメトリの解釈は、経験値ではなく仕様に対してテストせよ。これが一番痛い。DCGMのビットフィールドで非ゼロを故障とみなしていたら

（DCGM: NVIDIA Data Center GPU Manager。GPUのヘルスチェックやテレメトリを管理するツール）、ドライバ更新で正常値がゼロから仕様定義の非ゼロマスクに変わり、全GPUノードが一斉に異常判定された。安全装置が働いて修復は走らなかったが、教訓は明確だ。ハードウェアのテレメトリはbooleanではない。パックドエナムやビットフィールドを扱うなら、テストフィクスチャはベンダーのドキュメントから作る。過去のハードウェアがたまたま返していた値に依存してはいけない。

検出と診断を分けるべきという指標も実務に直結する。検出は自動化に供給する。高速で、継続的で、データ量は最小。診断は人間に供給する。オンデマンドで、詳細で、重い。混ぜると両方が劣化する。私の現場でも、アラートの閾値議論と事後分析のログ要件が混ざって議論が迷走することがある。目的を明確に分ける設計は、Kubernetesに限らず監視全般で有効だ。

所有権の境界を越えるなという教訓も見逃せない。kubeletがワークロード駆動の条件を所有し、ノードヘルスエージェントがハードウェア障害を所有する。境界を越えると、修復システムがkubeletの退去システムと戦う。どちらかが間違った判断をする。Kubernetesでは各コントローラーの責務境界を明確にしないと、意図しない競合が起きる。この原則は自己修復に限らず、オペレーター設計全般で意識すべきだろう。

EKS Auto Modeを使えば、ノード修復の設定は不要になる。ただし、自動化が進むほど、検出の正確さが直結する。誤検知が修復をトリガーすれば、ワークロードの不要な退去が起きる。Reason codesの安定性やテレメトリの仕様ベースのテストは、自己修復の信頼性を支える基盤だ。

AlphaEvolveが一般提供開始：評価関数を自分で書けるなら強い、書けないならただのAPI

GoogleがAlphaEvolveをGemini Enterprise Agent Platformで一般提供した。DeepMindの研究プロジェクトが、Google Cloud顧客なら自分のコードに対して実行できる製品になった。

仕組みはこうだ。ベースラインアルゴリズムを与えると、Geminiモデルが変異候補を生成する。ユーザー定義の評価関数でスコアリングし、収束するまで繰り返す。最終的に最適化された人間が読めるコードを出力する。

ここで重要なのがデプロイメントモデル。評価関数はユーザー側のインフラで動く。ラップトップでもプライベートクラスタでもスーパーコンピュータでも構わない。AlphaEvolveのAPIは候補プログラムを生成するだけ。スコアリングはローカルで行い、結果を送り返す。コードを外に出せない企業にとって、この分離は意味がある。

成果の数字は派手だ。KlarnaはML training throughputを2倍にした。3週間で約6,000の候補プログラムを探索しつつ、金融規制が求めるbit-exact再現性を維持している。JetBrainsはIDE code completionのレイテンシを15〜20%改善。FM Logisticはすでに最適化済みの倉庫ピッキングルートからさらに10.4%削った。Kinaxisはforecasting accuracyを22%向上させつつruntimeを90%削減。Oak Ridge National LaboratoryはFrontier（exascale system）で科学計算ワークロード向けのGPU kernel最適化を行っている。Google内部では次世代TPUのシリコン設計最適化、SpannerのLSM-tree compactionでのwrite amplification 20%削減、storage footprint 9%削減をすでに達成済みだ。

JetBrainsの証言が一番腑に落ちた。「エンジニアはベンチマークとレビューとリリース決定を所有し続ける。小さくなるのは探索空間だ」。

ただし効く範囲は限られている。Hacker Newsでの議論が的確に指摘していた。「私には絶対効かない」という反応と「数ヶ月分の仕事が1時間で終わった」という反応の両方があって、どちらも正しい。境界線は明確だ。測定可能で自動化可能な評価関数がある問題には効く。明確なベンチマーク、スコアリング指標、検証可能な正確性チェックがあるコードは最適化できる。人間の判断に依存するコードは最適化できない。Googleの顧客リストがそれを反映している。forecasting pipelines（WMAPE）、warehouse routing（距離）、GPU kernels（スループット）、chip layouts（面積と電力）。すべてに最適化すべき数字がある。

大多数のプロダクションコードはどうか。ビジネスロジックに曖昧な成功基準がついている。そういう領域でAlphaEvolveがどうなるか、まだ分からない。

発表に含まれていないことにも注意が必要だ。パフォーマンス数値はすべてベンダー提供か顧客証言で、独立したベンチマークがない。価格も非公開。ある実践者が指摘していた通り、成果はLLMと進化的アルゴリズムがうまく働くように設計された環境の結果だ。その環境設計こそが本当の仕事になる。チームは自分が気にするすべてのプロパティを捕捉するスコアリングハーネスを構築しなければならない。進化的探索は評価者が測定し損ねたものを何でも搾取するからだ。テストが捉えられない微妙に間違った高速コードを生成する、ということが起こりうる。

自分がKubernetesマニフェストやTerraformコードを最適化したいとしたら、評価関数をどう書くか。デプロイ時間か、リソース使用量か、可用性か。その設計にこそ数週間かかるかもしれない。

WebflowがSOCなしで504時間を取り戻した内製AIの実験

WebflowのセキュリティチームにはSOCがない。アナリストがシフト制でモニターを監視する仕組みではなく、少数のセキュリティエンジニアが検知の作成からインシデント対応、システム改善まで全ライフサイクルを担当している。当然、すべてを調査することはできない。優先順位の取捨選択が日常だった。そこにAIを1年かけてプロダクションに組み込んだ。パイロットでもデモでもない。結果として、1四半期で504時間の工数削減を出した。

きっかけは検知数の急増だ。ある四半期で検知が200%増えた。手動で毎回ゼロからコンテキストを集め、複数プラットフォームを行き来してログを確認する従来のトリアージが限界に達した。ここでAIに前作業を任せる設計に切り替えた。エンジニアがアラートを見る時点で、チケットには関連する履歴信号や初期の重大度評価がすでに揃っている。誤検知と高信頼度で判断できるものは自動クローズまで回す。この判断基準は数ヶ月のチューニングと検証の上に構築されており、環境変化に合わせて定期的に見直しているという。

興味深いのは、LLMを調査のパートナーとして使っている点だ。プレイブックがそのまま当てはまらない曖昧なインシデントで、ログの要約、過去の類似事例の提示、次のステップの提案、初期タイムラインの作成をLLMに担わせる。人間がすべての重要な意思決定点に残ることは設計原則として明記されている。AIが提示し、エンジニアが検証して行動する。この境界が曖昧になれば、監査不可能で事後説明の困難なリスクが生まれると彼らは書いている。

ベンダーのAI製品を買い集めて同じ断片化を繰り返すのではなく、内製で統合的に構築したという選択がこの記事の根にある。コンテキストの把握しやすさと制御のしやすさは、自社のワークフローに密接に合わせたシステムだからこそ得られる利点だろう。ただし、どの程度の初期投資と維持コストがかかったのか、内製できるチームの技術水準はどこに必要なのか、そのあたりは記事からは読み取れない。504時間の節約は大きいが、その裏でチューニングや検証にどれだけの時間が積み上がっているのか気になるところだ。

エージェントが環境リクエストをトラフィックに変えた

プラットフォームエンジニアリングは勝利を収めた。90%の組織が内部プラットフォームを少なくとも1つ採用し、ゴールデンパスは正統な手法として定着した。かつて数日かかっていた環境リクエストは数時間で処理されるようになった。だが、そこに最も要求の厳しい顧客が現れた。開発者ではない。コーディングエージェントだ。

エージェントは自分の作業を検証するため、環境を要求する。APIを呼ぶように。バースト的に、同時に、数分の寿命で、数秒の期待値で。100人の開発者組織で、各エンジニアが1日に数回のエージェントセッションを監督すると、昼前には数百の環境リクエストが発生する。各リクエストは現実的な依存関係を必要とし、検証が終われば不要になる。これはチケットキューではない。トラフィックだ。

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

問題は量だけではない。形も変わった。人間の環境需要は日中に偏り、交渉可能で、朝の遅延に耐えられる。エージェントは再試行し、ファンアウトし、タイトなループで反復する。この需要の形にはすでに名前がある。トラフィックだ。

従来の2つのモデルはどちらも破綻する。複製モデルは各リクエストにスタックの完全なコピーを渡す。40サービスのシステムでデータベースとキューを含めると、コピー1つあたり1時間数ドルかかり、構築に数十分を要する。同時実行で乗算すれば、モデルは崩壊する。ウォームプールの事前プロビジョニングも救わない。エージェントの需要はバースト的であり、ピークに合わせたプールは谷でアイドルになり、谷に合わせたプールはピークでキューを作る。共有モデルも失敗する。1つのステージング環境にテナントを順次受け入れると、待機時間が爆発する。Littleの法則が1961年から示している通りだ。

（リトルの法則：システム内の平均滞在数は、「到着率 × 平均処理時間」で決まるという待ち行列理論の基本原則）隔離の失敗も致命的で、1つの壊れた変更が背後の全テナントの環境を汚染する。

私が注目するのは、記事が「環境をプロビジョニングからサーブへ」という転換を指している点だ。環境をサービングシステムとして捉える。レイテンシ、同時実行、リクエストあたりの限界コスト、共有インフラ上の安全なマルチテナンシー。これはプラットフォームチームがすでに計算リソースで使っている精神モデルそのものである。おそらく、これからのプラットフォームエンジニアリングの核心は、環境を静的なインフラではなく、スピードと効率でサーブするシステムをどう構築するかにかかっている。

まとめ

Sparkがベクトル検索を飲み込んでサービング層に近づき、コーディングエージェントが環境をトラフィックとして扱う。システムを構成する要素が、静的なプロビジョニングから動的なフローへとシフトしている。データを準備して渡すのではなく、直接提供する。環境を構築して待つではなく、リクエストに応じてサーブする。この振る舞いの変化は、プラットフォームの責務を根本から変えつつある。

動的なシステムを動かすには、境界を明示的に引く必要がある。WebflowはAIに前作業を任せつつ、重要な意思決定点に人間を残す境界を設けた。AlphaEvolveは、評価関数という明確な成功基準を書ける領域にしか効かない。EKSの自己修復でも、検出と診断を分け、所有権の境界を越えないことが事故を防ぐ前提になっている。自動化が進むほど、どこを機械に委ね、どこで人間が検証するかの線が問われる。

その線を引く仕事は、決して楽ではない。テレメトリの解釈を仕様に対してテストし、進化的探索が評価者の盲点を搾取しないようにスコアリングハーネスを設計する。誤検知が修復をトリガーすれば、ワークロードが不要に退去される。境界の設計を間違えれば、自動化は信頼を失うか、最適化すべきでないものを最適化する。

自動化やAIは境界の外側を広げるが、境界そのものを消し去るわけではない。システムが動的になるほど、何を自動化の対象とし、何を人間の制御下に置くか。その線を明文化し、テストし、守る作業が、これからのエンジニアリングの核心になるはずだ。

参照記事

記録日: 2026-07-20