製品シグナルからプルリクエストへ：PostHog ジョシュア・スナイダー

PostHog が挑む「自己構築型プロダクト」：LLM による自動バグ修正とプルリクエストの未来

PostHog は、製品分析データを基に手動での問題特定プロセスを自動化し、自動的にコード修正を実行する「自己構築型プロダクト」の実現に向けて動き出しています。従来のようにダッシュボードを見てから対応を開始するのではなく、異常を検知した瞬間に AI エージェントが調査・修復を行い、開発者がレビューするだけで済むプルリクエスト（PR）を提出するシステムです。

このアプローチは、エンジニアが日々の退屈なバグ対応から解放され、新機能の開発に集中できる未来のワークフローを示唆しています。PostHog のジョシュア・スナイダー氏は、この完全自動化パイプラインの実装プロセスと、そこから得られた重要な教訓を明かしました。

従来の「遅い」プロセスからの脱却

PostHog はもともと製品分析ツールとしてスタートしましたが、現在はセッション再生やエラー追跡など多様な機能を備えています。しかし、従来の運用フローには大きな課題がありました。

「製品で何かが発生するとシグナルが検知され、ダッシュボードの指標が変化します。その後、エンジニアは数時間後あるいは数日後にログインして状況を確認し、問題が重要だと判断されて初めて対応を開始します。」

このプロセスには数日ものタイムラグがあり、多くの場合、その間にユーザー体験は悪化しています。また、問題が実は重要ではないケースもあり、無駄な作業が発生することも珍しくありません。

PostHog が目指すのは、この「人間がダッシュボードを見て判断する」モデルを廃することです。代わりに、背景でエージェントが常時監視し、何が問題かを特定して自動的に PR を作成します。エンジニアは朝起きて GitHub 上の PR を確認するだけでよく、リスクの低い変更であれば機能フラグ経由で即座にデプロイも可能です。

ノイズの多いデータソースを統合する「意味的マッチング」の壁と突破

この自動化を実現するための最大の難関は、膨大で多様なデータソースからのノイズを処理し、真の問題を特定することでした。PostHog はエラーログ、セッション記録、Slack の通知など、異なる形式のデータを大量に扱います。

初期の実装では、これらのデータを「埋め込み（embedding）」モデルを使ってクラスタリングしようとしました。しかし、このアプローチは構造的な類似性に基づいてしまうため失敗しました。

「市販の埋め込みモデルは、『チェックアウトのエラー』と『オンボーディングに関する Slack メッセージ』を、構造的に似ているという理由だけでまとめてしまいます。しかし、これらは意味的には全く異なる問題です。」

構造的な類似性ではなく、意味的関連性でグループ化するために、PostHog はアプローチを変更しました。

1. クエリ生成の活用: シグナルそのものを埋め込むのではなく、LLM に「このシグナルは何についてか？」と問いかけ、複数の検索クエリを生成させます。
2. 意味的マッチング: 生成されたクエリを埋め込み空間で照合し、異なるソース（エラー、ログ、Slack）から意味的に関連する情報を統合します。

この変更により、ランダムな例外と顧客からの深刻な不具合報告を正しく結びつけることが可能になり、問題の特定精度が劇的に向上しました。

エージェントによる調査と自動修正パイプライン

信号をグループ化し、「レポート」としてまとめた後，PostHog は「研究エージェント」を起動します。このエージェントは Claude Agent SDK を使用し、Modal 上でサンドボックス環境で安全に動作します。

エージェントには以下のツールが用意されており、調査の精度を高めています：

• MCP サーバー: セッション再生やエラーログなど、追加のコンテキストデータを取得可能。
• Git Blame: コード変更履歴を参照し、誰がレビューすべきかを特定。
• 外部ツール連携: Linear や Notion への接続により、問題の優先順位付けや文脈理解を強化。

調査の結果，エージェントは以下のいずれかの判断を下します：

1. 実行不可能: データ不足または人間の判断が必要な場合。この場合はプールに戻り、さらに証拠を集めます。
2. 人間への引き継ぎ: 製品に関する重要な意思決定が必要な場合。朝のインボックスへ通知されます。
3. 自動修正（最良ケース）: エージェントが即座に修正コードを生成し、PR を作成します。

特にエラー追跡のような具体的な事象では，エージェントが即座に修正を実行できるケースが増えています。生成された PR は CI（継続的インテグレーション）のチェックを受け，失敗やコメントがあれば自動的に再実行され，緑色になるまで反復されます。

実装から得た4 つの重要な教訓

このパイプラインを構築する過程で、PostHog チームは数々の試行錯誤を経験しました。その中で得られた重要な教訓は以下の通りです。

1. 本番環境での評価（Evals）が不可欠

ローカルデータや雰囲気チェックだけで評価を完了させるのは危険です。顧客の多様なデータと実際の運用状況を反映した評価データがないと、パイプラインは「闇雲に手を動かす」状態になります。

2. エンベディングモデルの限界を理解する

オフ・ザ・シェルフの埋め込みモデルは構造的類似性に偏りやすいです。データ形式が統一されていない場合や、異なるソースを統合したい場合は、クエリ生成による意味的マッチングなど、慎重な設計が必要です。

3. エージェントに「具体的な問題文」を与える

「『オンボーディングが壊れている』という一般的なレポートを投げつけても、エージェントはただ何かを修正しようと試みるだけです。」

問題の具体性が不足していると、ノイジーで無意味な PR が大量発生します。エージェントには、調査によって得られた具体的なコンテキストと問題文を与えなければなりません。

4. トークンコストへの過度な懸念が実験を遅らせる

初期段階では「トークンは無料ではない」という理由から、エージェントの実行を最終段階まで遅らせようとしていました。しかし、これは大きなミスでした。

「実験段階では、エージェントを実行して類似点を見つけることが重要です。一度実行すれば、その行動パターンに共通点が見えてきます。」

コストを気にしてエージェントを使わないと、パイプラインの改善が遅れます。最初は高価なステップでも、エージェントの実行を通じて得られる知見は、最終的にワンショット LLM コールや軽量モデルへの置き換えなど、コスト削減の道筋を示してくれます。

未来のエンジニアリング：「自己修復型」システムへ

PostHog の目指すゴールは、製品が自分自身で構築されることです。開発者はエキサイティングな新機能の開発に集中し、バグ対応や退屈な実験の実施、価格設定の調整などはすべて AI エージェントに任せる未来です。

「PR を却下したり、デプロイで問題が発生したりした場合でも、その結果を学習して次回の PR でより上手になる。このループを回し続けることで、システムは自律的に進化していきます。」

現在アルファ版として提供されているこの機能は、今後数ヶ月かけて段階的に展開されます。大量のデータを生成するプロダクトを持つ企業にとって、AI エージェントを活用した「自己修復型」ワークフローへの移行は、開発生産性を劇的に向上させる重要な一歩となるでしょう。