AIコスト按分やクラウド可観測性ツールについて調べたことがあれば、「eBPF」という言葉を目にしたことがあるはずです。セキュリティプラットフォーム、ネットワークツール、パフォーマンスモニターに登場し、近年はAIコスト按分の文脈でも存在感を増しています。では、eBPFとは実際のところ何を指し、なぜAI支出の計測において重要なのでしょうか。
eBPFとは
eBPFは「extended Berkeley Packet Filter」の略です。名称はその起源(ネットワークパケットのフィルタリング手段として誕生した経緯)を色濃く残していますが、技術としてははるかに広い領域へと進化しました。カーネルのソースコードを変更したり、カーネルモジュールを追加でインストールしたりすることなく、小さくサンドボックス化されたプログラムをLinuxカーネル内で直接実行できる仕組みです。
実務的に言えば、eBPFはソフトウェアがマシン上の出来事を最も低いレイヤーで観測することを可能にします。あらゆるシステムコール、ネットワークパケット、プロセス、GPUのやり取りを、発生した瞬間に捉えるのです。しかも安全に、です。eBPFプログラムは検証済みのサンドボックス環境で動作するため、カーネルをクラッシュさせたり、セキュリティホールを生じさせたりすることはありません。ローダーや検証アーキテクチャの技術的な詳細については、eBPF.ioの入門ドキュメントが最も網羅的な公開資料です。
eBPFセンサーは、この機能を活用するソフトウェアそのものを指します。カーネルイベントにアタッチする軽量なプログラムで、観測したデータを別の場所で動作するコレクターや分析レイヤーへストリーミングします。OS自体に埋め込まれ、アプリケーション層のツールでは決して見えない挙動を監視するセンサーだとイメージすると分かりやすいでしょう。
eBPFセンサーとカーネルモジュール・エージェントの違い
eBPFが登場する以前、この種の可視性を得る手段はおおむね2つに限られていました。カスタムカーネルモジュールを書くか、アプリケーション層にフックする重量級のエージェントを走らせるかです。
カーネルモジュールはeBPFセンサーと同じものをすべて見ることができますが、相応のリスクを伴います。カーネルモジュールのバグはマシン全体をクラッシュさせかねません。モジュールはカーネルメモリに対して完全かつ無制限のアクセス権を持って動作するからです。加えて、カーネルのバージョンごとにビルドし直してテストする必要があり、多くのチームが引き受けたがらない継続的な保守負担が発生します。
アプリケーション層のエージェントはこのリスクを回避できますが、その代償として盲点を抱えます。アプリケーション内部にインストールされたエージェントは、そのアプリケーションが公開する情報しか見えません。共有GPUドライバー、カーネルネットワークソケット、あるいは存在を知らされていないプロセスを通過するトラフィックを捉えることはできないのです。
eBPFセンサーはその中間に位置し、両者の良いところを併せ持ちます。カーネル内で動作するためカーネルモジュールと同じくすべてを観測できますが、あらゆるeBPFプログラムは実行を許可される前にカーネルのベリファイアを通過するので、システムをクラッシュさせたり、触ってはならないメモリを読んだりすることはありません。「リスクを抑えながら完全な可視性を得られる」というこの組み合わせこそが、最新の可観測性、セキュリティ、そして今やコスト按分ツールにおいてeBPFが標準的な選択肢となった理由です。
カーネルレベルでの観測がなぜ重要なのか
多くの監視・按分ツールはアプリケーション層で動作します。そして、何らかの計装、たとえばリソースのタグ、API呼び出しをラップするSDK、エンジニアが忘れずに追加したログ行に依存しています。計測対象が静的で明確に定義されているなら、これで十分機能します。
しかし、AIインフラは静的でも明確でもありません。従来のFinOpsの実践がまさに限界を迎えるのがこの領域です。詳しくはFinOpsがAIワークロードにどう適応するか(そしてしないか)を参照してください。共有GPUクラスターは複数のプロダクトに同時にサービスを提供します。マネージドモデルAPIのアカウントには、何十ものチームからリクエストが飛んできます。LLMゲートウェイは、エージェント、パイプライン、人間のユーザーからのトラフィックを1本の外向きストリームに集約し、その過程で呼び出し元の識別情報を落としてしまうことも珍しくありません。こうした活動にはタグが付いておらず、自社で制御するSDKも経由しません。
eBPFセンサーはそれらを一切必要としません。OS内部で動作するため、実際の消費、つまりプロセス、コンテナ、Pod、GPUサイクル、トークンをそのまま直接見ています。アプリケーションに報告を求める必要はなく、システムそのものを観測するのです。
よくあるシナリオを考えてみましょう。あるエンジニアリングチームが、複数プロバイダー間のレート制限とフェイルオーバーを管理するために、モデルトラフィックをすべて1つのLLMゲートウェイに集約したとします。ゲートウェイから見ると、すべてのリクエストは同じに映ります。APIキーは1つ、外向きストリームも1本です。モデルプロバイダーからの請求書にも、同様に平坦化された姿が反映されます。請求書だけを見ても、その1ドルが顧客向け機能によるものなのか、社内自動化によるものなのか、暴走したテストスクリプトによるものなのかを見分ける術はありません。eBPFセンサーは、トラフィックが実際にマシンを離れる地点、つまりゲートウェイが集約する前にそれを観測し、各リクエストを発行元のプロセスに紐付けることで、この問題を解決します。
eBPFセンサーの動作をステップごとに
- アタッチ。 センサーは、システムコール、ネットワーク活動、GPUスケジューリングなど、観測対象に応じて特定のカーネルイベントにアタッチします。
- キャプチャ。 イベントが発生すると、センサーはプロセスID、リソース使用量、タイミングといった関連するデータポイントを取得します。
- 検証。 これらに先立ち、LinuxカーネルのeBPFベリファイアがプログラムを検査し、安全に実行できることを確認します。この点が、はるかに大きなリスクを伴う従来のカーネルモジュールとの決定的な違いです。
- ストリーミング。 センサーは観測結果をカーネル外部の収集レイヤーへストリーミングし、そこでプロバイダーの請求データなど他のデータと結合できます。
- マッピング。 結合されたデータは、どのエージェント、どの機能、どの顧客に起因するのかを示すワークロードにマッピングされます。
この一連のプロセスは、コード変更もマニフェスト編集も一切の計装も必要とせず、継続的かつリアルタイムに実行されます。
eBPFセンサーとAIコスト按分
ここでeBPFは、Tokenomics、すなわち各トークンのコストと価値を理解する分野と直接結び付いてきます。AIワークロードは動きが速く予測不能なため、計装ベースの按分では到底追いつけません。エージェントは一晩で1,000のサブエージェントを生み出し得ます。エンジニアリングチームが新しい呼び出しパターンをSDKでラップし終える頃には、請求書はすでに届いているのです。
eBPFセンサーはこの問題を根本から回避します。OS内部から計測するため、あらゆるプロキシ、あらゆる抽象化、あらゆる所有権境界の手前で、発生した瞬間のすべてのトークン、すべてのモデルリクエスト、すべてのGPUサイクルを捉えます。そのデータはAnthropic、OpenAI、Google Gemini、AWS Bedrockなどのプロバイダー請求データと結合でき、キャッシュされたトークン、推論トークン、入力トークン、出力トークンを自動的に分解できます。
その結果、タグ・SDK・コード変更に依存しない按分が、数か月ではなく数分で実現します。この粒度は、AIのROIを正確に測定するための土台でもあります。機能の実際のコストが分からなければ、どんなROI計算も推測の上に成り立つほかありません。
よくある質問
eBPFセンサーは本番環境で安全に動作しますか? はい。あらゆるeBPFプログラムは、ロードが許可される前にカーネル組み込みのベリファイアを通過します。ベリファイアは、プログラムが必ず終了すること、境界外のメモリを読まないこと、カーネルをクラッシュさせたり不安定にしたりしないことをチェックします。これは、無制限のアクセス権を持ち安全チェックの仕組みもない従来のカーネルモジュールとは、根本的に異なるリスクプロファイルです。
eBPFセンサーの導入にはコード変更や計装が必要ですか? いいえ。むしろそこが最大の利点です。eBPFセンサーはカーネルレベルで活動を観測するため、状況を把握するのにタグもSDKもコード変更も要りません。アプリケーションがどの言語で、どのように書かれているかに関わらず、同じように動作します。
eBPFセンサーのデプロイにはどれくらい時間がかかりますか? デプロイは通常、数週間ではなく数分単位で完了します。計装のステップも、マニフェスト変更も、アプリケーションコードの修正も不要なため、センサーはインストール後ほぼ即座にトラフィックの観測を開始できます。Attribute™ by DoiTでは、ほとんどのお客様が当日中に按分データを確認しています。
eBPFセンサーは共有GPUやLLMゲートウェイの内側まで見えますか? はい。まさにこの点こそが、タグやSDKベースのアプローチと異なるところです。センサーはOSレベルで、ゲートウェイ、プロキシ、共有リソースを通過する前のトラフィックを観測するため、活動が下流で集約されたり匿名化されたりしても、発生元のプロセスまで遡って追跡できます。
eBPFはネットワークとセキュリティ用途にしか使えないのですか? いいえ。eBPFはネットワーク技術として始まりましたが(名称は「extended Berkeley Packet Filter」の略です)、その後、可観測性、セキュリティ、そしてコスト按分へと領域を広げています。アプリケーションの自己報告に頼らず、システムの活動を直接観測することで恩恵を得られるユースケースは、いずれもeBPFベースのアプローチの候補になります。
eBPFセンサーとeBPFプログラムの違いは何ですか? eBPFプログラムはカーネル内で動作するコードの基本単位で、特定のフックポイントにアタッチされた小さな検証済みロジックを指します。eBPFセンサーはその上に構築されたより広範なシステムで、生のカーネル観測データを利用可能なデータに変える収集・マッピングロジックまでを含みます。
これがAttribute™ by DoiTの基盤です。カーネルレベルのAIコスト按分が、お客様の環境でどう見えるかをぜひご確認ください。