# BPF in the agentic era > [!abstract] 概要 > LWN の Daroc Alden は、2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit における Alexei Starovoitov の発表と議論を報告する。中心テーマは、LLM とコーディングエージェントが前提となる開発環境で、BPF の安全性を維持しながら、記述・検証・デバッグのフィードバックループを短くする方法である。記事は確定済みのカーネル機能一覧ではなく、Starovoitov が示した提案と会場の懸念を記録した報告である。 ## 記事情報 - 媒体: [[LWN.net]] - 著者: [[Daroc Alden]] - 公開日: 2026-06-03 - 会議: 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit - 発表者: [[Alexei Starovoitov]] - 関連する議論参加者: [[Daniel Borkmann]]、José Marchesi、Amery Hung、Cupertino Miranda、[[Steven Rostedt]] - URL: https://lwn.net/Articles/1075067/ ## 問題設定: エージェント向けのフィードバックループ コーディングエージェントは、コードを書き、エラーを観測し、修正して再実行する短い反復で能力を発揮する。大規模なリファクタリングのような機械的作業では、この反復が特に有効である。一方、BPF では、正しくテストするために仮想マシンを起動しなければならない場合があり、検証器のエラーも原因を隠す大量のダンプになりやすい。記事は、この遅く不親切なフィードバックが、LLM による BPF コード生成を難しくする要因だと報告する。 ## verifier の安全境界と開発者支援の分離 BPF はカーネルをクラッシュさせないことを安全性の中核とするため、verifier は廃止できず、信頼できないユーザ空間からカーネルを守るためにカーネル内で動く必要がある。したがって、verifier を単純にユーザ空間へ移すことは解決策にならない。 記事が報告する提案は、verifier の役割を二つに分けて考えることである。プログラマの単純な誤りを発見する役割は Rust コンパイラなどのユーザ空間ツールへ寄せ、安全境界としての検証はカーネル内に残す。unsafe コードやインラインアセンブリに依存しない、通常の Rust 製 BPF プログラムについては、Rust コンパイラを通過したプログラムが verifier でも通過する状態を目標とする。 この目標が達成されれば、開発者は単純な誤りを仮想マシンやカーネルへ投入する前に知ることができる。なお、記事中の「数か月で verifier と格闘しなくなる」という発言は将来予測であり、実装完了の報告ではない。 ## エラー報告の改善 現在の verifier エラーは「register is not init」のような内部状態中心の説明になり、何が起き、どう直せばよいかが分かりにくい。提案されている方向は Rust の診断表示を参考にし、失敗箇所だけでなく、原因と修正方法を含むメッセージへ変えることである。残る verifier エラーをほぼなくし、避けられないエラーにも実用的な説明を付けることが目標とされる。 verifier を user-mode Linux 上で実行する案も、信頼境界を移すためではなく、検証エラーを早く受け取るための開発用経路として議論された。実カーネルがユーザ空間を信頼する必要はなく、開発時のエミュレーションと本番の安全境界を分ける発想である。 ## verifier の表現力を広げる候補 Starovoitov は、エージェントだけでなく人間にも有用な verifier の制約緩和を列挙した。 - 6 個を超える引数を持つ関数 - 間接関数呼び出し - 構造体の値返し - 128 ビット整数 - より大きな BPF プログラムスタック - より深い呼び出し連鎖 - 100 万命令制限の除去 - BPF プログラムの長いジャンプ - static 関数と global 関数の検証差異の解消 BPF arena の平坦なアドレス空間へデータを移し、arena ごとのグローバルアロケータを使うことが、いくつかの制約を単純化する案として説明された。一方、Rust コンパイラがコードへ混在させる仮想ディスパッチテーブルを BPF が扱えない問題があり、コンパイラ側の出力変更が必要になる可能性もある。 ループ検証では、状態を何度も精密に追跡する代わりに **widening** を使い、ループ変数のより広い値の集合を一度に扱う案が示された。状態の精度は低下するため実行時検査が必要になる場合があるが、固定された最大反復回数を持つループを扱いやすくすることが狙いである。記事は初期結果を良好と報告するが、実用化には追加作業が必要だとしている。 ## ツールとエージェントの接続 [[bpftrace]] と DTrace はトレースポイント設定用の専用言語を使うため、人間には扱いやすい一方、LLM がニッチな構文を扱うには不利だと論じられた。対策として、コーディングエージェント向けに標準ツールの使い方を明示的な例つきで文書化する方向が示される。標準言語の構文を使い、追加機能を備える drgn のようなツールは、この方向と相性がよいとされる。 目標は、エージェントへ「このカーネルの性能問題を見つけて」と指示し、BPF と drgn を使って原因調査まで進めさせることである。ただし、カーネルの関数と型に関する情報を自動検査可能な形式で提供しなければ、対象マシンを危険にさらす可能性がある。例として `vmlinux.rs` のような Rust バインディングが挙げられた。 ## エージェント生成コードとレビュー BPF サブシステムでは、一見すると質が高く見える低品質パッチが増え、保守者の規模には限界があると報告された。Starovoitov は、コミットログを LLM が生成した可能性を考慮してパッチ自体を直接読む状況を述べ、パッチを投稿する人がコードレビューにも参加するよう求めた。 会場では、LLM によるレビューを GCC などにも使う案、LLM のコメント後にレビューする運用、コミットログをパッチ内容から再生成する案などが議論された。一方で、クラウド LLM のトークン費用、ベンダーロックイン、オープンソース開発者が継続して利用できる資金源、新規貢献者の学習機会が懸念として示された。 ## 横断的な位置づけ この議論は、[[eBPF]] の「カーネル内で未信頼コードを検証・実行する」という安全性と、[[エージェント型コーディング]] の「短い反復で環境からフィードバックを得る」という生産性要求の衝突を明示する。解決策は安全境界を弱めることではなく、ユーザ空間コンパイラ、開発用検証環境、実行時検査、診断メッセージ、標準ツールの文書化を組み合わせ、同じ安全性をより速く説明可能な形で提供することにある。 ## 限界・不確実点 - 記事は会議での発表と議論の報告であり、列挙された verifier 改良が Linux に実装済みであることを意味しない。 - `widening` の具体的なアルゴリズム、実行時検査の位置、性能影響は記事では詳述されていない。 - Rust と BPF verifier の互換性目標の適用範囲は、unsafe コード、インラインアセンブリ、ヘルパー利用、カーネル版差異によって変わりうる。 - LWN の記事本文と会場発言が中心であり、スライド自体の図表・実装ロードマップは別ソースで確認する必要がある。 ## 関連 - 概念: [[eBPF]] / [[BPF]] / [[BPF verifier]] / [[エージェント型コーディング]] / [[フィードバックループ]] / [[LLMによるカーネル最適化]] / [[WebAssembly]] / [[オープンソースソフトウェア開発]] - エンティティ: [[Alexei Starovoitov]] / [[Daniel Borkmann]] / [[Daroc Alden]] / [[LWN.net]] / [[bpftrace]] / [[Steven Rostedt]] / [[Linux]] - 関連ソース: スライド版の [[@2026__BPFConf2026__BPF in the Agentic Era (LSFMM 2026)]] ## 出典 - [[.raw/articles/lwn-1075067-2026-08-29.md]]（LWN 記事の取得原稿） - [LWN: BPF in the agentic era](https://lwn.net/Articles/1075067/)（Daroc Alden, 2026-06-03）