抽象化の裏で制御点が問い直される

Airflow代替の2強が合流した先にあるもの

PrefectがDagsterを買収する。まだ正式なクロージングは通っていないが、事実上決まった話だ。Dagsterのチーム約40人がPrefect側に移り、DagsterとDagster+は既存の名称・価格・ロードマップを維持するという。

7年ほど前、この2つは同じ土俵で争っていた。どちらもApache Airflowの代替を狙ったPython製オーケストレーター。PrefectはPython開発者にとってのプロダクション運用を簡素化し、Dagsterはパイプラインが何を生み出すかに注目した。タスクの実行順序ではなく、成果物の定義と追跡。哲学の違いはあったが、ターゲットは同じだった。

それがAIエージェントの文脈で合流する。Prefect創業者のJeremiah Lowinの説明によれば、Dagsterはゴール設定を、Prefectは即興的な実行を、FastMCPはエージェントが触れる範囲の制御を担う。3つの役割を1つにまとめるのがこの買収の狙いだ。

FastMCPの存在が大きい。Anthropicが2024年末に公開したModel Context Protocol（MCP）

（LLMが外部ツールやデータソースと標準化された方法でやり取りするためのオープン規格）に対応するフレームワークで、プレーンなPython関数を書くだけでMCPサーバーを構築できる。MCPと同月にリリースされ、後にAnthropic公式のPython SDKとして採用された。エージェントと外部システムをつなぐ層で、Prefectはすでに強い足場を持っている。

懸念されるのはDagster側の体制だ。Nick Schrockは創業者からCTOへ、そして今回の買収に伴いプロジェクトと会社を離れると明言した。「戦略的アドバイザーとして残る」という公式発表とは少し温度差がある。Pete Huntとともにアドバイザーを務める予定だが、現場の意思決定からは遠のくことになるだろう。

Dagsterを使っているチームはどうなるか。当面は名称も価格も変わらないとされている。ただ、2つのオープンソースコミュニティが1つの会社に集まるわけで、リソース配分や優先度の付け方はいずれ揺れる。DagsterのComponentsやCompassといった直近の機能追加が、Prefectのエージェント戦略の中でどこまで育つのか。そこはまだ見えない。

データパイプラインのオーケストレーターという枠で見れば、競争が減って選択肢が減ったと映るかもしれない。しかしLowinが言う「近代オーケストレーションの重心の移動」が本気なら、これは別の話だ。エージェントの実行を制御する層で、誰が標準を握るか。MCPの普及速度を考えると、FastMCPを公式SDKに持つPrefectの立ち位置は悪くない。

Kubeflow運用でkubectlに戻らなくて済むUIができた

Kubernetes上でAI/MLワークロードを動かすなら、Kubeflowは避けて通れない選択肢の一つになっている。分散トレーニングもハイパーパラメータチューニングもパイプラインも、全部CRDとして定義される。

（CRD: Custom Resource Definition。KubernetesのAPIを拡張して独自のオブジェクトを定義する仕組み）Kubernetes-nativeな作りのおかげで、運用者にとっては他のワークロードと同じプリミティブで扱えるはずだ。しかし現実はそう甘くない。Kubeflowが同梱しているML専用ダッシュボードは、Kubernetesのレイヤーを隠してしまう。Notebookが動かない、トレーニングジョブが失敗した、という場面で結局kubectlに頼ることになる。ImagePullBackOffなのかOOMKilledなのか、PVCの待ちなのか。Podレベルで起きていることを知るには、クラスタの真理に触れるしかない。

この溝を埋めるプラグインがHeadlampに追加された。Kubernetes SIG UIがメンテナンスするHeadlampは、Apache 2.0ライセンスの拡張可能なKubernetes Web UIだ。デスクトップアプリでもインクラスタでも動く。そのプラグインシステムを利用して、KubeflowのカスタムリソースをHeadlamp内で直接可視化する。

具体的に何が見えるか。Notebookの詳細画面では、Podのconditionsとreason/message、CPU・メモリ・GPUのrequests/limits、volume mountsの背後にあるPVCやConfigMapやSecret、環境変数の参照元、サイドカー、node tolerationsが一覧できる。普段ならkubectl describeを何度も叩いて拾う情報を一画面で確認できる。Katibのビューではチューニングアルゴリズム、探索空間、各Trialのステータス、最適Trialのメトリクス値とパラメータ、早期停止の設定と実際に停止したTrial数が追える。Pipelinesのビューは特徴的だ。Kubeflow PipelinesのAPIサービスやバックエンドDBを叩かず、Kubernetes APIから直接読む。パイプラインサービスが落ちていてもステートを確認できるのは、インシデント対応中には助けになるはずだ。PipelineVersionの最新と前バージョンのYAML diffを横並べで比較できるのも地味に嬉しい。

もう一つ面白いのがMap機能。Notebook、Profile、PodDefault、Experiment、Pipeline、SparkApplication、TrainJobをグラフノードとして描画し、ownerReferencesに基づいてエッジを引く。リソース間の依存関係が視覚的に追える。プラグインはクラスタ上のKubeflow APIグループを自動検出し、インストール済みのコンポーネントに対応するセクションだけを表示する。不要な画面で埋め尽くされる心配はない。

ここで注目したいのは、このプラグインが示すパターンの方だ。ドメイン特化のワークフローをCRDで表現するプラットフォームはKubeflowに限らない。そうしたプラットフォームのダッシュボードは、ドメインの関心事に集中するあまりKubernetesの状態を隠しがちだ。運用者は「すでに働いている場所」で「クラスタレベルの真理」を見たい。Headlampのプラグインは、その二つを同じ画面で満たす実装例になっている。他のCRD-heavyなプラットフォームでも同じアプローチが取れるはずだ。

試す敷居は低い。READMEに軽量なCRD-onlyの評価パスが用意されており、サンプルリソースだけのクラスタでも動かせる。既存のモジュラー構成のKubeflow環境にもそのまま追加可能だ。Artifact Hubではheadlamp_kubeflow 0.2.0-alphaが公開されている。まだアルファ版なので本番投入は早いが、MLワークロードのトラブルシューティングでkubectlと往復する日々に疲れているなら、一度触れてみる価値はある。

Kubernetes DashboardからHeadlampへの移行で認証と運用が変わる

Kubernetes Dashboardがアーカイブされ、Headlampが後継に位置づけられた。Kubernetes SIG UIが推すこの移行、単なるUIの差し替えじゃ済まない。認証モデルと日常的な操作が結構変わる。

一番の差は「どこで動くか」「誰の権限で動くか」だ。Dashboardはインクラスタで動き、ServiceAccountのトークンで認証する。つまりクラスタ内にUIを置き、そこにトークンを貼り付けてログインする。一方Headlampは、デスクトップで動かせばkubeconfigをそのまま使う。kubectlと同じ権限でUIを操作できる。インクラスタで動かす場合も、ServiceAccountベースになるが、SSOやOIDCと組み合わせられる。

この違いが何を変えるか。まずログインの手間が減る。トークンをコピペする運用から解放される。次にマルチクラスターが標準になる。Dashboardはクラスタごとに1つ立てるのが普通だった。Headlampはkubeconfigにある複数のコンテキストを横断的に見せる。dev、staging、prodを行き来する作業が楽になるだろう。

リソースの作成方法も変わる。Dashboardはフォーム入力だった。HeadlampはYAMLをapplyする方向に倒れている。個人的にはこちらの方が好みだ。フォームでポチポチ作ったリソースはGit管理しづらいし、再現性もない。YAMLならCI/CDに乗せられる。

移行の進め方として、並行稼働が推奨されている。Headlampを入れて試し、チームが慣れたらDashboardを消す。急いで切り替える必要はない。ただし、既存のServiceAccountやRBACのクリーンアップは忘れがちなので、移行後のタスクリストに入れておきたい。

デスクトップ版とインクラスタ版のどちらを選ぶか。プラットフォームチームが管理する共有URLが欲しければインクラスタ。各開発者がローカルで手軽に見るならデスクトップ。両方もありえる。まずはデスクトップ版で検証し、チーム全体の需要が確認できた段階でインクラスタ版への移行を検討するのが現実的なルートだろう。

懸念点もある。Headlampのプラグインエコシステムがどこまで成熟しているか。Dashboardのフォームでリソースを作っていた人は、YAMLを書くことに抵抗があるかもしれない。移行そのものより、ここをどうサポートするかが課題になりそうだ。

データ所有権の実務的ハードルが見えてきた

ベルリンで開かれたLocal First Conf 2026のパネル「Data Ownership Beyond Local-First」が、local-first運動の本来の動機だったデータ所有権を実務の観点から解剖した。登壇者はScuttlebuttのZenna Fiscella、BlueskyのPaul Frazee、Ink & SwitchのBoris Mann、SupramundaneのRobin Berjon、Eileen Wagner。モデレーターは2019年のlocal-first論文で示されたデータ所有権の枠組みを起点に据えた。

Fiscellaは、データ所有権の議論がメタデータ露出やデバイス侵害への対策にシフトしていると指摘した。暗号化してローカルに置いても、メタデータで通信先や頻度が漏れるなら所有権は絵に描いた餅だ。Frazeeは「形式的な権利だけでは不十分」と断を下した。GDPRのデータアクセス要求がいい例で、ユーザーはデータを受け取れても機械可読でない形式では使いようがない。

ここで面白いのは、分散の理想とスケールの現実がぶつかった部分だ。FrazeeはAT Protocolがピアツーピア構成からサーバー構成へ移行した経緯を説明した。Twitter規模の運用、つまり2億4000万のデイリーアクティブユーザーを支えるにはP2Pでは厳しかった。ただしBlueskyの目標は、会社自体より長く生き残るエコシステムを育てることだと言う。理想を手放したというより、到達手段として中央集権的な足場を使う判断と読める。

相互運用性の欠如も繰り返し指摘された。Berjonは同期標準と独立運営インフラの必要性を訴え、Frazeeはプロトコル間のブリッジこそが足りないレイヤーだと述べた。Fiscellaは別の角度から、コミュニティごとに異なるアイデンティティシステムやガバナンスモデルが必要だと主張した。単一のトラストモデルに全員を押し込むのは、中央集権と同じ過ちを繰り返すだけだろう。

実装の優先順位を巡るクロージングで、各人のスタンスがくっきり出た。Berjonはコミュニティや市民レベルでのデータガバナンス共有ツールを求めた。FiscellaはメッシュネットワークとOSレベルの統合を強調。Mannの発言が一番実務に刺さった。アイデンティティや暗号をゼロから作り直すのをやめ、既存のビルディングブロックを共有すべきだ。そして連絡先、カレンダー、メールといった実際のユーザーデータドメインに向き合えと。JMAPという標準も名前が挙がった。

（JMAP: JSON Meta Application Protocol。メールやカレンダーなどの通信を効率化するモダンな標準プロトコル）

自分がマイクロサービスを書いている立場で見ると、この「ゼロから作り直すのをやめろ」という指摘は耳が痛い。認証も暗号も、チームごとに独自実装しがちだ。local-firstの文脈に限らず、共通部品として何を残し何を捨てるか。そこが次の論点になるはずだ。

NSAレッドチーム出身者が指摘する、SOCがやめるべきこと

7月23日、The New Stackがバーチャルイベントを開く。登壇者はSumo LogicのSecurity Strategy VP、Chas Clawson。NSAレッドチームで攻撃側を務め、商務省のESOC SIEMソリューションを設計した経験を持つ人物だ。彼が語るのは、SOCが「やめるべきこと」。

やめるべきなのは、もっとデータを集めようとすること。

ここ数年、セキュリティチームは可視性を広げてきた。エンドポイント、クラウドサービス、アイデンティティ、テレメトリ。見えるものを増やし続けた結果、どうなったか。データ不足は解消された。だが今度は、そのデータに埋もれることになった。アラート疲れ（alert fatigue）は、セキュリティ運用の定番の課題だ。しかし本質は量ではない。文脈（context）なのだとClawsonは指摘する。

個別のアラートは全体像を語らない。不審なログイン、奇妙なプロセス、予期しないネットワーク接続。それぞれ単独なら無害に見える。だが、ある1人のユーザーやデバイス周辺にそれらが集まると、違う光景が浮かぶ。だから今、検知の単位を変えるチームが出てきている。個別のイベントで発火させるのではなく、ユーザー、デバイス、サービスアカウント、ワークロードを中心に据える。アナリストが自ら数十のバラバラなアラートから組み立てるのではなく、継続的な状況像として提示する。この発想の転換は、マイクロサービスの監視で分散トレーシングが必須になった流れと似ている。個別のスパンではなく、トレース全体を見る。セキュリティも同じ方向へ動いている。

もちろん、文脈を集めればそれで終わりではない。誰かが意味を理解しなければならない。ここでAIが実用的な役割を担い始める。アナリストの代替ではなく、ログを読むのに疲れないチームメンバーとして。検知ルールのチューニング、調査結果の要約、プレイブック構築、複数データソースにまたがる証拠の相関、人間が優先的に見るべきシグナルの提示。AIにこうした作業を任せる方向性は、私が普段見ているCI/CDの自動化とも近い。ただし前提がある。正しいデータ戦略がなければ、AIも機能しない。

すべてのログを同等に扱うべきではない。すぐに検索できるデータ、アナリストが見る前にエンリッチメントすべきデータ、コンプライアンス用にアーカイブしつつ調査時には取り出せるデータ。何をどこに置き、どれくらい保持するか。何を集めるかと同じくらい重要な判断になる。ログを全部放り込んでおけばいい、という時代は終わったのだと読める。

Clawsonの経歴が面白い。攻撃側の視点と、大規模SOC構築の視点を両方持っている。レッドチームの感覚で「どこが見えていないか」を知りつつ、エンタープライズ側で「どう見えるようにするか」を設計した人物が語るデータ戦略。7月23日のイベント内容は、おそらく実務に即した話になるだろう。ログを全部取るのは簡単だ。何に注目すべきか、有効なSOCと過負荷なSOCを分けるものは何か。そこが論点だ。

まとめ

ドメイン特化のダッシュボードやデータパイプラインのオーケストレーターは、便利さと引き換えに下層の真理を隠してきた。しかし運用現場では結局kubectlに戻り、SOCではデータに埋もれる。抽象化やデータ収集を「もっと」やる時代は終わったと見ていい。

だからこそ、制御点と文脈の再定義が始まっている。KubeflowプラグインやHeadlampは、ドメインの関心事とクラスタの真理を同じ画面で満たそうとしている。PrefectとDagsterの合流は、エージェントの実行制御という新しい制御点をMCPで握ろうとする動きだ。SOCでも、個別のアラートからユーザーやデバイスを中心とした状況像へ検知の単位を変える。どこで制御し、何を単位として見るか。そこが問い直されている。

理想や機能のゼロベース構築から、既存のブロックの組み合わせへという流れも見える。データ所有権の議論で「ゼロから作り直すのをやめろ」という指摘があった。PrefectがFastMCPという公式SDKを足場にするのも、SOCがデータ戦略の前提でAIを動かすのも同じだ。自分たちが制御するレイヤーと、既存のものに乗るレイヤーを明確に分ける。実務的な判断だけが、抽象化の泥沼から抜け出す足場になるはずだ。

参照記事

記録日: 2026-07-14