公開わずか2日で122スターを集めたrocketplaneIOは、Kubernetes向けの自己ホスト型AI SREだ。eBPFによる計装ゼロの可観測性と、障害原因を自動特定・修復するCopilotを組み合わせる。オンプレで完結し、利用するLLMも選べる。金融・医療といったデータ持ち出し不可の領域が真っ先に反応した意味を、SREの構造変化として読み解く。

何が起きたか

GitHubに公開されたolemeyer/rocketplaneIOが、公開2日で122スターに到達した。位置付けは「Self-hosted AI SRE for Kubernetes」。中身は大きく2層に分かれる。第一層はeBPFベースの可観測性レイヤーで、アプリケーション側にエージェントやSDKを埋め込むことなく、カーネル層からシステムコール、ネットワーク、プロセス情報を収集する。第二層はCopilotと呼ばれる修復エージェントで、収集したテレメトリを基に障害の原因を推定し、修正操作を実行する。

特筆すべきは自己ホスト前提の設計だ。バックエンドのLLMも自分で選択でき、テレメトリを外部SaaSに送出する必要がない。夜間のオンコール対応、いわゆる「叩き起こされる当番業務」を肩代わりする用途として、金融・医療など機密性の高いワークロードから注目が集まっている。

なぜこのニュースが重要か

SREという職種は、月間検索1.8万を稼ぐ定着したキーワードでありながら、実務は「アラート受電と原因調査と暫定対応」の連鎖に押しつぶされている。ここにAIが入る余地は前から議論されていたが、実装のボトルネックは常に2つあった。ひとつはテレメトリ収集のために全アプリにOpenTelemetry SDKや各種Exporterを仕込む「計装コスト」。もうひとつは、LLMにログやスタックトレースを渡すことによる「情報漏えいリスク」。

rocketplaneIOはこの2つを同時に潰しにいっている。eBPFはLinuxカーネル4.x以降で成熟した仕組みで、アプリコードを1行も変えずにネットワーク・ファイルI/O・システムコールを観測できる。つまり計装コストがほぼゼロになる。加えて自己ホスト+モデル選択自由なので、テレメトリはクラスタ外に出ない。この2点の組み合わせが、これまでDatadogやNew Relic系のSaaSに払っていた「観測+分析」の外部依存を切る現実的な手段になる。SREの労働問題ではなく、SREのアーキテクチャ問題として捉え直す契機だ。

技術的な深掘り

コードと仕様書から本質を読む立場で見ると、この設計の勘所は「eBPF×LLM×Kubernetes API」という3点セットにある。eBPFは高頻度な低レベルイベントを出すが、そのままではLLMのコンテキスト窓に入らない。したがって前段で必ずイベントの集約・要約・相関付けが必要になる。ここの実装品質が、Copilotの「原因特定精度」を決定する。単なるログ全文投入では、コスト面でもレイテンシ面でも夜間対応に耐えない。

さらに修復フェーズでは、Kubernetes APIに対する変更操作をどこまでLLMに委ねるかが焦点になる。Deploymentのロールバック、リソース上限の一時引き上げ、Podの再起動あたりは半自動化しやすいが、Namespace横断のネットワークポリシー変更や永続ボリューム操作までCopilotに握らせるのはリスクが跳ね上がる。RBACによる操作範囲の絞り込みと、変更前のドライラン・監査ログが実装されているかは、採用可否を分ける論点だ。122スターという初速は熱量の証明だが、production readyかどうかは別問題で、まずはステージングクラスタでの挙動観察が前提になる。

経営者として次に取るべき動き

第一に、現在のオンコール体制のコストを可視化することだ。夜間対応の平均発生回数、対応時間、対応者の翌日稼働ロスを数値化すれば、AI SRE導入の投資回収ラインが明確になる。SREを外部委託している場合、月額数十万〜数百万の削減余地が生じる。

第二に、監視SaaSの契約更新前に自己ホスト型AI SREのPoCを走らせること。DatadogやNew Relicの年間契約は数千万規模になりやすい。eBPFベースの計装ゼロ観測で代替可能な範囲を切り分ければ、SaaS費用の一部を確実に圧縮できる。

第三に、Copilotに与える権限設計を情報システム部門ではなくセキュリティ部門主導で設計させること。Kubernetes APIに対する自動変更は、下手をすると全社サービスを止めうる。RBACスコープ、承認フロー、ロールバック手順を先に決めてから接続する。この順序を間違えると、AI SREはリスクを増幅する装置に変わる。