AI搭載機能を構築して学んだこと

• PostHogが12か月にわたりAI機能 Max AI を開発して得た実践的な経験をもとに、適切な機能選定から実装、改善までの全プロセスを体系化したガイド
• AI機能は、遅い・信頼できない・意味のない問題を解決する場合、かえって製品を悪化させる可能性があり、検証済みのパターン（データ検索/要約、ジェネレーター、ツール利用）を活用すべき
• 実装段階では、アプリのコンテキストと状態管理が中核であり、クエリ計画と条件付きルーティングでAIを正しい方向へ導き、モニタリングとガードレールで失敗に備えること
• 速度最適化のため、モデルのベンチマークを継続的に追跡し、作業に応じて高速モデルと低速モデルを組み合わせ、非同期処理を活用すべき
• 継続的な評価と改善のため、初期段階から eval を追加し、A/Bテストを実施し、AI知識のサイロ化を防いでチーム全体にAIの専門性を分散させるべき

---

何を構築するかを選ぶ

• AIが製品を悪化させうることを認識し、遅すぎる・信頼できない・誰も気にしない問題を解決する誤った機能を作らないようにする

1. AIが得意なパターンを学ぶ

• 検証済みのAIパターンを取り入れ、ユーザーにとって馴染みのあるUXパターンと、AIが実際に得意な機能を組み合わせる
  • 1つ目のパターン: 「文書/データ/PDFと対話する」 - AIは検索と要約に優れており、これを使ってレポートやレコメンドを生成できる（例: Intercom の Fin、Mintlify のドキュメントチャット）
  • 2つ目のパターン: さまざまな種類のジェネレーター - タイトル、コード、ドキュメント、SQL、画像、フィルターなどを生成する（例: Lovable、Bolt.new、Figma、Rippling、Notion）
  • 3つ目のパターン: ツール利用 - AIが明確に定義されたツールを使ってワークフローを自動化・改善する（例: MCP サーバー、Zapier、Atlassian、Asana）
• PostHog の Max AI は複数のパターンを活用している
  • データやドキュメントとの対話
  • SQLインサイトやフィルターの生成
  • アンケート生成や分析インサイトなどのツール利用
  • 今後はセッションレコーディングの自動視聴・分析などへツール利用を拡張予定

2. AIが解決できる問題を特定する

• AIが提供できる価値に焦点を当て、製品全体で作業を見直す
  • 30秒以上かかる明確な単一タスク - 長いフォーム入力、手動データ入力、統合設定、SDK導入など
  • ユーザーが理解していない言語やインターフェースの利用が必要な場合 - 複雑なUI、SQLクエリ、アプリ構築など
  • 20回以上繰り返す作業 - 説明文作成、要約作成、項目生成など
• incident.io の Stephen Whitworth の助言: 「AIができる新しくてすごいこと」よりも、「ユーザーが1日に100回やることをAIでより良くできるか」に集中する
  • 例: ユーザーは自分で書くよりも自動生成されたインシデント要約を強く好み、現在ではインシデント要約の75%がAIで生成されている
• PostHog での適用例
  • AIインストールウィザード: PostHog の導入時間を約10分から90秒へ短縮
  • Max AI の SQL翻訳: 複雑なSQLクエリを自然言語で簡単に書けるようにし、SQLに不慣れなユーザーでもカスタムインサイトを作成可能にする

3. 問題が具体的で価値あるものか検証する

• 具体的で価値ある問題へとスコープを絞る必要がある
• 避けるべき落とし穴
  • 価値のない問題に既存パターンを当てはめること: 初期段階のシンプルな製品に「ドキュメントと対話する」機能は不要で、むしろ核心的なユーザビリティ問題を隠してしまう可能性がある
  • AIで大きすぎる問題を解こうとすること: AIがいきなり10億ドルを稼がせてくれるわけではなく、まずは狭い問題を解決してから拡張する方がよい
• Max の構築時、「売上をどう増やすか？」のような広すぎる質問は効果的でないとすぐに認識した
  • その代わり、PostHog に統合され、ユーザーの PostHog コンテキストを活用できる具体的な機能に集中した
  • 例: Max は利用可能なテーブルを把握しているためより良いSQLを書け、組み込みの利用可能なツールを理解しているためネイティブな可視化で製品に関する質問へ回答できる

アイデアを実装する

• 作ろうとしているものが本当に機能するかを確かめるため、核心要素に集中する

4. アプリのコンテキストと状態が中核

• OpenAI API を呼び出すこと自体は誰にでもできるが、アプリのコンテキストは固有である
• 含められるデータ
  • ユーザーがやろうとしている作業
  • 誰がそれを行っているか
  • アカウントの状態
  • アプリ内の位置
  • アプリのデータスキーマ
• Max が「先週登録数が減少した理由」を質問されたとき、APIが受け取る情報
  • 現在のページ（ダッシュボード、表示中のインサイト、適用済みフィルター、ユーザーロール）
  • データスキーマ（利用可能なイベント、イベントプロパティ、人物プロパティ）
  • アカウント（組織ティア、タイムゾーン、保持期間）
• コード例によるUIコンテキストのフォーマット
  • ダッシュボード情報（名前、表示中のインサイト、適用済みフィルター、日付範囲）
  • インサイト情報（名前、クエリ種別、分析対象イベント、分類）
• ワークフロー内の**「コンテキスト」（状態）処理**も不可欠
  • 会話が進む中でコンテキストが失われないようにする必要があり、特に複数のサブエージェントがいる場合に重要
  • ワークフローのあらゆる部分でコンテキストを保存し、含める
• コンテキスト最適化とモデル選定は、モデルのファインチューニングよりも効果的で有用である

5. クエリ計画と条件付きルーティングでAIを成功へ導く

• AIを無制限に動かすと、あらゆる予想外の挙動を起こすため、成功に向けた誘導が必要
• 複数ステップをオーケストレーションして接続する形で実装する: クエリ計画 → データ取得 → 可視化
• 状態管理以外に必要なこと
  • AIが使えるツールとデータを認識していること
  • 意図された作業に応じて正しいツールとデータを選択できること
  • クエリ実行やフォーマットのようなツールが実際に動作することを確認すること
• PostHog のトップレベルルーターの例
  • インサイト生成が必要か判断
  • ドキュメント検索が必要か判断
  • 請求関連か判断
• 各ルーターノードは、その作業に必要な正しいデータとツールへ接続する独自の条件を持つ
  • AIがタスク完了に必要な構成要素を確実に持てるようにし、成功確率を高める

6. モニタリング、ガードレール、エラー処理で失敗に備える

• 構築した仕組みが失敗を防ぐとはいえ、AIは最終的にガードレールへぶつかるため、ガードレールの提供は必須である

モニタリング

• 問題発生のタイミングを把握するため、最初からモニタリングを実装する
• Max AI チームの Georgiy の助言
  • 本番トレースのモニタリングは必須
  • ドッグフーディング用のモニタリングツールを構築したが、最初からあればよかった
  • 規模が大きくなるほどトレース監視は難しくなるため、オンライン評価が役立つはず（次の優先事項）
  • 100件の会話を見直すのは大変で、1日に1,000件の会話を見直すのは不可能
  • こうした会話には実際のユーザーの質問や困りごとが含まれており、エージェント構築に必要なあらゆるインサイトを与えてくれる

ハルシネーション防止

• AIがハルシネーションできるものはすべてハルシネーションするので、直接設定すべきデータや従うべきルールを明示する
• AIインストールウィザードのルール例
  • APIキーを絶対に捏造しないこと。代わりに .env ファイルに入力済みのAPIキーを常に使う
  • 「// 実際のアプリでは...」のようなプレースホルダーコメントを追加しないこと
  • 既存のビジネスロジックを変更したり、シミュレーションコードを追加したりしないこと
  • 既に使われていない新しいパッケージやライブラリを import しないこと
  • 認証ライブラリ（Clerk、Auth.js など）が使えると仮定しないこと

ユーザー向けガードレール

• 空のテキストボックスを見ると、人は不安になり、何もかも忘れてしまう
• 解決策: AI機能の使い方に関する提案を追加し、正しい方向へ導き、可能な作業を思い出させる

エラー処理

• ワークフローは時々中断するため、リトライとレート制限で上手に処理する
• 上級ユーザー向けに、LLM分析、エラー追跡、機能フラグを設定可能
  • PostHog はその3つすべてを提供している（うれしい偶然）

機能を改善する

• AIモデルは速く、しかも予測不可能に進化するため、AI機能には予想以上に多くの保守と継続的改善が必要になる

7. AI知識のサイロ化を防ぐ

• AI機能の構築は、チーム内の「AI担当者」1人の責任であってはならない
• AIは製品に深く統合されるべきであり、それはユーザーと対話し、その人たちのために何かを作る人々の専門性を必要とする
• 推奨される方法
  • プリミティブを構築し、AI機能を組み合わせ可能にする: チームがプロンプト、ストリーミング、同意、eval、分析を毎回作り直さずに済むようにし、独自で付加価値のあるAI機能に集中できるようにする
  • アプリ全体で一貫したUXパターンを維持する: PostHog ではそれが Max に当たり、何千ものAIウィジェットによる混乱を防ぐ
  • AIの専門家をチームに一時的に配置する: チームがより速くAI機能を構築できるよう支援し、組織全体へAI知識を分散する（Max AI チームが実施）

8. 速度に集中する

• AI機能、特に複雑な機能の大きな課題の1つは遅さである
• ワークフローはしばしばLLMプロバイダーへの複数回の呼び出しを意味し、多くの待ち時間につながる
• アプリやWebサイト上でタスクを完了する代替手段がある場合は特にいら立たしい
• Superhuman の創業者 Rahul Vohra の助言: 「スピードが勝つ」
  • 例: Instant Reply や Auto Summarize
  • Gmail や Outlook にも似た機能はあるが、リクエスト時に返信や要約を生成し、完了まで待つ必要がある
  • Superhuman ではこれを事前計算しているため常に即座に提供でき、この単純な違いがユーザー体験に非常に大きな影響を与える

改善方法

• モデルのベンチマークと新モデルのリリースを把握する: より良く、より速いモデルが出たらテストして利用することで、機能面でも速度面でも最大の改善を得られる（LLM分析を使用）
• タスクに応じて高速モデルと低速モデルを使い分ける
  • タイトル生成、セッション再生フィルター、アンケート要約、インサイト検索には高速モデル（gpt-4.1-mini, gpt-4.1-nano）を使用
  • スキーマ生成、会話処理、コンテキスト管理には低速モデル（gpt-4.1）を使用
• 非同期処理を使う: セッション要約やパターン抽出のような複雑なAIタスクは Temporal ワークフローを通じて非同期に実行され、ユーザー操作をブロックしない。その後 Redis にキャッシュされ、再計算なしでリトライできる

9. 有効性を継続的にモニタリングし評価する

• 新機能が ✨ AI ✨ だからという理由だけで、甘く評価されるべきではない
• 誤ったアイデアは製品を悪化させうるし、モデルの変化はユーザーに気づかれないまま体験へ悪影響を及ぼす可能性がある

有効性の評価方法

• 早い段階で eval を追加する: 小さなゴールデンデータセットや合成データセットでも、通常の開発サイクルと比べて大幅な性能向上をもたらす。規模が大きくても実装は予想より簡単で、今後の機能開発も速くなる
• A/Bテスト: AI機能と通常体験の比較、異なるプロンプト、コンテキスト、ワークフローなどをテストする
• さまざまな顧客タイプでのAI利用率を確認する（例: 無料ユーザー vs エンタープライズ、プロダクト部門 vs 営業部門）
  • プロダクトマネージャーやマーケターが、理想的な顧客プロファイルであるプロダクトエンジニアよりも Max を頻繁に使っていることがわかり、ロードマップを再考するきっかけになった
• ユーザーがAI応答を良い/悪いで評価できるようにする: 悪いと評価された場合は追加詳細を求め、コンテキスト、プロンプト、ワークフロー調整に活用する
• AI利用者と非AI利用者を比較する: 既存のアクティベーションや継続率指標を使って、AIが製品とユーザーライフサイクルのどこに最も適しているか、また良い影響を与えているかを理解する

まとめ

• この9つの教訓は独立したものではなく、相互に作用する
• 最後の方だけをつまみ食いして eval の最適化だけで優れた製品を作れると考えるのは誤り
• 目標はユーザーにとって価値あるものを構築することであり、派手な技術デモではない
• AIだからといって、ユーザーが価値を見出すとは限らない
• 優れた製品づくりで学んだ教訓は今でもそのまま当てはまる
  • ユーザーと話す
  • すばやく出す
  • 実験を回す
  • 反復する