GitHubトレンドで急上昇中の「rocketplaneIO」は、Kubernetesの障害をAIが検知・原因特定・修復まで自動化するセルフホスト型SREツールだ。eBPFによるゼロインストルメンテーションと社内LLM完結という設計思想が、金融・医療の運用現場を揺さぶっている。SRE市場18,000検索の背景にある「人が張り付く運用」の常識は、いま構造ごと崩れ始めた。
何が起きたか
olemeyer/rocketplaneIOが129スターを獲得し、GitHubトレンドで急上昇している。特徴は3点だ。第一に、Kubernetes環境の障害をAIが自動検知し、根本原因を特定して修復まで完了させる「自己修復SRE」であること。第二に、アプリ側にトレース用のコードを埋め込む必要がない、eBPFベースのゼロインストルメンテーション観測性を採用していること。第三に、セルフホスト構成で社内LLMと接続すれば完結し、外部にログを一切送出せずに運用できることだ。この「エアギャップ対応」が、規制産業の運用チームを強く引き寄せている。従来、AI運用ツールはSaaS前提のためログ持ち出しがネックとなり、金融・医療・防衛系では導入自体が不可能だった。その最後の壁を、OSSが崩しにきている。
なぜこのニュースが重要か
SREという職能は、Googleが2003年に定義して以来、「人間の当直エンジニアが24時間張り付き、SLO違反を検知して手作業で復旧する」ことを前提に設計されてきた。オンコール手当、夜間シフト、外注MSP契約——これらすべてが「人間が最終判断者である」という前提の上に積み上がった経済圏だ。rocketplaneIOが示すのは、この前提そのものの解体である。
技術的に見れば、AIがKubernetesの障害対応をこなす下地はすでに揃っていた。kubectlのAPIは構造化されており、Prometheusメトリクスは機械可読、ログはJSON化が進んでいる。LLMにとってこれほど扱いやすいドメインは他にない。決定的に足りなかったのは「観測データを取得する摩擦」と「機密データを外に出す抵抗」の二つで、それをeBPFとセルフホストが同時に解いた。SRE検索ボリューム18,000という数字は、依然として「人がやる仕事」の求人・学習需要を反映しているが、この構造は今後2年で反転する。運用外注ビジネスの単価下落は、すでに始まったと見るべきだ。
技術的な深掘り
コードと仕様書から本質を読むと、rocketplaneIOの肝はeBPFの採用にある。eBPFはLinuxカーネル内で安全にプログラムを動かせる仕組みで、アプリケーションのソースコードに一切手を入れずにシステムコール、ネットワークパケット、プロセス挙動を観測できる。従来のOpenTelemetry方式が「アプリを計装する」思想だったのに対し、eBPFは「カーネルから見下ろす」思想だ。この違いは運用現場で決定的な意味を持つ。レガシーなJavaバッチ、ベンダー製バイナリ、Goで書かれたサイドカー——計装できないワークロードが混在するのが本番環境の現実であり、eBPFはそこを一撃で貫通する。
さらに、社内LLMで完結できる設計は、モデルサイズの選択自由度を運用者に返す。Llama 3系70Bクラスをオンプレで回せば、GPT-4級の障害推論が外部通信ゼロで動く。推定だが、GPU 2枚（H100相当）の初期投資でオンコールエンジニア1人分の年間コストを下回る損益分岐に達する。エアギャップ環境という「AI導入が最も遅れる」とされてきた領域が、逆に「AI導入が最も進む」領域へ反転する可能性が高い。
経営者として次に取るべき動き
第一に、自社の運用外注契約を棚卸しし、24時間監視・一次切り分けに支払っているコストを可視化せよ。この費目は今後2年で50%以上の下落圧力を受ける。長期契約の巻き直し交渉が有効だ。
第二に、社内LLM基盤への投資判断を前倒しせよ。rocketplaneIOのようなOSSツールは社内LLMがなければ真価を発揮しない。逆に基盤があれば、SRE以外にもインシデント対応、コードレビュー、セキュリティ監査へ横展開できる。GPU調達のリードタイムを考えれば、意思決定は今四半期中が望ましい。
第三に、SREチームの評価軸を「対応速度」から「AIへの権限委譲設計」へ切り替えよ。何を自動修復させ、何を人間の承認に残すか——このガードレール設計こそが、これからのSRE職の中核業務になる。手を動かす人材ではなく、判断基準を設計できる人材を残す組織再編に着手すべきだ。