What Customers Are Doing With AI and Honeycomb

O11yConでは、業界各社のエンジニアリングチームに話を聞きましたが、その数字は本格的に驚くべきものになり始めています。MixpanelのDevOpsエンジニアEddie Bracho氏は、同社のエンジニアリングチームがAI導入前と比べて50%も多くのPRを生成していると語りました（失礼）。

そんな速度はワクワクする一方で、コードを書かないスタックのあらゆる部分にプレッシャーをかけています。以下は、顧客から聞いているその影響についてです。

コード量が新たな強制力に

Eddie氏は率直にこう述べました。Mixpanelがすでに投資してきた可観測性インフラのおかげで、新しいコード量を吸収できているというのです。「エンジニアの人数は変わっていません。ただ、書くコードの量が増えただけです。Honeycombに頼れるのは本当に助かっています」

可観測性はもはや「あったら良いもの」ではありません。デプロイ頻度が50%も跳ね上がれば、新たな変更が期待通りに動作しているか、あるいは誤動作しているかを素早く判断できる必要があります。フィードバックループが追いつかなければ、それがボトルネックになります。

Gem（採用テックプラットフォーム）のエンジニアリングマネージャーYi-an Lai氏は、次のように的確に表現しました。「コードをリリースするのはエンジニアの仕事のごく一部です。コードレビューや、複雑に相互接続されたシステムの設計も行いますし、オンコールローテーションに参加して顧客報告の問題をトリアージ・解決するのも大きな役割です。コードのリリースは速くなっても、製品をサポートする速度と効率も同時に高めることが重要です」

AIはループの左側を助けます。右側、つまりコードが世に出た後に何をしているかを理解する部分は、まだ改善が必要です。

Honeycomb MCPサーバー

私たちが話を聞いたいくつかのチームは、AIコーディングエージェントにHoneycomb MCP serverを接続しており、そのユースケースは興味深いものです。

Gemでは、Yi-an氏のチームがオンコールローテーション中のエンジニアを支援するAI支援ツールを構築しました。「静的なコードだけで推論するのではなく、具体的な証拠を集めたり、トレースを深く掘り下げてパフォーマンスボトルネックを明らかにしたりできます」

Mixpanelはインシデントトリアージボットの構築を進めています。目標は、ページャーが鳴った瞬間に自動でエージェントセッションを開き、Honeycombのデータに加えてGCPログやKubernetesの情報を取り込み、人間がノートPCを開く前にできるだけ多くのコンテキストを提示することです。Eddie氏は「どうすればエンジニアにできるだけ多くのコンテキストを提示できるか」と表現しました。Honeycomb MCP serverはその中核コンポーネントです。

StarSling（自己改善型CIループにより高速・低コストなGitHub Actionsを構築）は、この道を最も進んでいます。共同創業者のDaniel Worku氏は興味深いアプローチを説明しました。まずHoneycomb MCP serverから始め、それをサブエージェントとプロンプトでラップするHoneycomb skillを重ね、その上に自社アーキテクチャの具体的なコンテキストを持ったカスタムskillを構築するというものです。「インシデントが発生したら、そのskillを実行するだけです。『何が起きている？』と聞くと、通常はバックエンドから賢明な回答が得られます」

生のMCPアクセスから、コンテキスト豊かな独自skillへの進化は、今後さらに多くのチームで見られるようになると予想しています。

BubbleのためのBubbleUp

BubbleのShogo Wada氏から聞いた話は注目に値します。Bubbleはノーコードプラットフォームで、独自の課題を抱えています。AIは同社の独自言語を理解しないため、エージェントの計装が難しくなります。しかし、バックエンドシステムに関しては、Honeycombは組織的に有用なツールになっています。

「Honeycomb以前は、ログとメトリクスを使っていました。ダッシュボードのパターンを見て結論を出せるエンジニアはわずかで、そのためには組織に何年も在籍する必要がありました。Honeycombを使えば、誰でも相関関係を見て結論を導き、そこから行動に移せます」

特にBubbleUpは、こうした会話でよく取り上げられます。高カーディナリティデータからシグナルを見つけるには、深い組織的知識が必要でした。その知識が誰でも使えるツールにエンコードされれば、長年勤続した2人に依存する必要がなくなります。

リアクティブからプロアクティブへ

ほとんどのチームは、現在のAI支援可観測性ワークフローがまだリアクティブであることを正直に認めています。GemのYi-an氏はこう述べました。「大部分はリアクティブですが、チームは現在フロントエンドの可観測性スタックの刷新を進めています。OpenTelemetryを採用しており、この移行によりまず標準化し、その後リアクティブからプロアクティブなモニタリングへ移行することを期待しています」

私たちが繰り返し目にする流れはこれです。適切に計装し、OpenTelemetryで標準化し、顧客が気づく前にAIが問題を検知できるほどデータを充実させる。現在、ほとんどのチームはアラート発報後に素早く対応するためにAIを使っています。さらに進んだチームは、アラートが発報される必要すら生じない段階でAIが問題を捉えることを目指しています。

ただし、その基盤となるインフラがまず必要です。テレメトリーが不完全・不整合だったり、相互に連携しない3つのツールに分断されていたりすれば、エージェントにシステムを推論させることはできません。

実際に必要なもの

豊かで高カーディナリティなテレメトリーが、すべてを支える基盤です。可観測性の有用性は、その背後にあるデータの質に依存します。

良いニュースは、これを上手く進めているチームが特別なインフラを運用しているわけではないことです。OpenTelemetry、十分なコンテキストが付与された分散トレース、そしてサーバーの健全性だけでなく顧客体験を測定するSLO。その上に構築されるAIツールはますます利用しやすくなっていますが、その基盤となるデータ品質には意図的な投資が依然として必要です。

AIコーディングエージェントがすでに50%も多くのコードをリリースしているなら、その投資はもう待ったなしでしょう。