ハクソク

世界を動かす技術を、日本語で。

PMのためのAIエージェントアーキテクチャガイド

263日前原文(productcurious.com)

概要

  • AIエージェントの高精度や高速応答だけでは ユーザー離脱 を防げない現実
  • 信頼感 を生むためのアーキテクチャ設計の重要性
  • エージェントの記憶・接続範囲・スキル・信頼戦略のレイヤー解説
  • 実際のカスタマーサポート事例を使った 設計判断の影響 分析
  • 「間違いを認める透明性」が ユーザー信頼 を高めるカギ

AIエージェントの信頼とアーキテクチャ設計

  • 表面的な精度や応答速度 だけではユーザーの継続利用は保証できない現実
  • ユーザーが 複雑な問題 で一度失敗すると、すぐに人間オペレーターを要求する傾向
  • 「賢くする」よりも 体験設計 と 信頼形成 が本質的課題
  • エージェントのアーキテクチャを「記憶」「接続」「スキル」「信頼戦略」のレイヤーで構造化

記憶レイヤーの設計

  • セッションメモリ ：現在の会話内容のみ保持
  • カスタマーメモリ ：過去のサポート履歴や苦情も参照
  • 行動メモリ ：ユーザーの利用傾向やパターンを蓄積
  • コンテキストメモリ ：アカウント状態や最近のアクティビティも把握
  • 記憶範囲が広いほどユーザー体験は向上するが、 実装コストや複雑性 も増加

システム接続レイヤーの設計

  • どのシステム（例： Stripe, Salesforce, Zendesk）に接続するかの選定
  • 接続範囲が広がるほどユーザー体験は向上だが、API制限・認証・障害リスクも増加
  • 最初から全て統合せず、 主要2-3システムから段階的に拡張 するアプローチが有効

スキルレイヤーの設計

  • 単なる情報取得だけでなく、 パスワードリセットやプラン変更 など具体的アクションも可能に
  • スキルが増えるほど価値は高まるが、 リスクや運用負荷 も増大
  • MCP（Model Context Protocol） の活用でスキルの再利用や共有が容易に

信頼戦略レイヤーの設計

  • 信頼指標 ：「85%の確信度で解決できます」と表示
  • 理由説明 ：「3つのシステムを確認し…」と根拠を示す
  • 境界提示 ：「複雑な請求問題は専門担当へエスカレーション」と明示
  • 許可確認 ：アクション前にユーザー承認を求めるパターン
  • 「間違いを認める」透明性 が信頼を高める（自信満々の誤答は逆効果）

オーケストレーション（構成）アーキテクチャ

  • 単一エージェント型 ：全て1つのエージェントで処理、構築容易だが複雑化しやすい
  • ルーター＋スキル型 ：ルーターが適切なスキルに振り分け、効率化・最適化が可能
  • ワークフロー型 ：定型手順を事前設計、監査性・最適化に優れるが柔軟性は低い
  • マルチエージェント連携型（A2A） ：複数エージェントが連携、複雑な課題対応だが実装・運用は困難
    • 現時点では 単一エージェント型 から始め、課題に応じて段階的に拡張が現実的

ユーザー信頼の本質

  • 「常に正しい」より「誤りを認める正直さ」 がユーザー信頼を生む
  • 信頼構築の三本柱
    • 確信度のキャリブレーション ：60%といえば実際に60%の正答率
    • 理由の透明化 ：調査根拠や判断手順を明示
    • スムーズなエスカレーション ：限界時は人間担当へ円滑に引き継ぎ

次回予告：エージェントの自律性とガバナンス

  • エージェントにどこまで 自律性 を持たせるかの意思決定
  • 自動化とユーザーコントロール のバランス
  • 実装時に直面する 現実的なガバナンス課題 とその解決策
  • 続編でさらに深掘り予定

Hackerたちの意見

自信のキャリブレーション：エージェントが「60%の自信がある」と言ったら、実際には60%の確率で正しいはず。90%でも30%でもなく、実際の60%ね。今の技術（LLM）で、エージェントはどうやって自分の自信を確信できるの？

└

「キャリブレートされたモデルを使う」と言おうとしたけど、面白い論文を見つけたよ：「キャリブレートされた言語モデルは幻覚を見なければならない」 https://arxiv.org/abs/2311.14648 https://www.youtube.com/watch?v=cnoOjE_Xj5g

└

著者の内なるPMが出てきて、ちょっと大胆な主張をしてる。キャリブレーションは従来の分類モデルではできるけど、ほとんどの市販のLLMでは無理だよ。もしLLMの自信の主張が実際のパフォーマンスと一致するかどうかを判断する方法を考えついても、従来のモデルのようにキャリブレーションや調整はできないんだ。

普段はPM向けの内容には厳しいけど、これはシステム構築を基本から考える良い概要だと思った。非技術的な問題点やそれにどう対処するかも含まれてるし。

今の時点でPMの役割って何なんだろう？技術的なアーキテクチャに深く切り込むのはちょっと驚きだけど、関わることを理解するのは大事だよね。PMの責任としては、これはTPM（テクニカルプログラムマネージャー）の領域に近いと思う。理想的には、スコープやユーザーのニーズ、成功を測る方法を理解することに集中すべきで、オーケストレーション戦略や評価、システムが求める機能を提供するかどうかの実装の詳細はエンジニアの責任だよ。

└

この投稿は技術的なアーキテクチャについて深く掘り下げてないね。

└

PMの役割は、開発者を叱咤して要件を満たすことだね。ここではそれが当てはまると思う。たとえ要件が全く意味をなさなくても。

PMにとっては良い枠組みだけど、技術的にはちょっと楽観的すぎるかな。MCPは実在するけど、まだ低いユーティリティのサービスやセキュリティの問題が山積みだから、「スキルをプラグインとして」ってのは実用段階には達してない。A2Aプロトコルは今年発表されたばかり（Googleなど）で、実際のエージェント間の相互運用性はまだ研究段階。エージェント間のデバッグは悪夢だし、オーケストレーション層（スキル、ワークフロー、マルチエージェント）は図ではきれいだけど、負荷がかかると脆弱な状態遷移機械になっちゃう。LLMの「自信スコア」は基本的にキャリブレーションされていないロジットを確率のように見せかけてるだけ。要するに、いい業界のロードマップだけど、まだ頑丈で信頼できるマルチエージェントシステムにはほど遠いね。

└

ツールに何らかのコントロールを実際のユーザーのアカウントに与えるというアイデアは（もっと上手く言ってくれたけど）私には狂気の沙汰に思える。ユーザーが正しく認証されていると仮定しても（大きな仮定！）、そのユーザーが「ツールを使った半信半疑のもの」を非常に文字通り促すことを許可するのは、今のところ現実的で賢明な実装からは非常に遠い気がする。必要なら、ツールのプロンプトを人間のオペレーターに送ればいいじゃん！ちゃんと確認してよ！

どうして人々がツールやデータソースの山を持っていて、それを顧客に向けて使うのか全然理解できない。私の経験では、ひどいUXで、時には電話の自動応答よりも悪いこともある。私の考えでは、AIを使ったカスタマーサポートに移行するには、ゆっくりと慎重に進める必要があると思う。1. AIが高確率で解決できる問題の範囲を把握すること。「以下の問題にのみ対応できます。」という関連プロンプトを使う。2. 範囲外の場合はすぐに人間にエスカレーションすること：「もし手助けできない場合は、bob@smallbiz.coをCCしてすぐに人間にエスカレーションしてください。」3. カスタマーサービス担当者が質問に答えるために使える「アンロックエージェント」を用意し、そのエージェントがどれだけ役立つかを評価する。これを開発ロードマップに活かす。4. 「アンロックエージェント」が問題解決に優れてきたら、それを範囲内の解決策に追加する。最後に、変更を加えたときに既存の会話をテストする方法も必要だと思う。（私のTODOリストに入ってる）いくつかの小さなビジネスでこれを実装したけど、プロセスが非常にスムーズで、誰もAIとやり取りしているとは疑わなかった。あるクライアントでは、エスカレーションのステップすら見えない：彼らは電話で通知を受けて、チャットを引き継ぐんだ！

└

人々がツールやデータソースの山を持っていて、それを顧客に向けて使うのか全然理解できない。 それはかなりシンプルだよ。非技術者がそのデモを見たら、すごく見えるし、みんな結果を推測してAIがそんなに優れていると思い込むんだ。

└

カスタマーサポートの目的は、顧客にサポートを追求する価値がないと納得させることだ。悪い体験はその目標をより早く達成する。GenAIを使うことは、この分野での大きなブレークスルーで、誰かの問題に対して気にしていないと伝える社会的に受け入れられた方法だから。

└

多くのエージェントツールやフレームワークは、サイト上でユーザーの質問に答えるエージェントを置くことを恐れてるよね。挑戦するところもあるけど、全然ダメ。例えば、Mastra.aiはエージェントを作るためのフレームワークのはずなのに、彼らのウェブサイトにいるエージェントは質問に全く答えられない（20個くらい質問したけど、満足のいく答えはゼロだった）。

前の仕事で、これのMVP（基本的なLLMカスタマーサポート「エージェント」のシーケンス）を作ったのが2024年の春だったかな。それ以来、すごく変わったよ！「どんどん専門化されたエージェントにルーティングする」というアプローチを取ったけど、その時のMVP形式でできる唯一の方法だった。私たちの（すごく良い）カスタマーサポートとプロダクトチームのデータセットに合うモデルはあまりなかったから、「顧客からの可能性のある問い合わせ」を一つのコンテキストウィンドウに収めるのは難しかった。私自身は、顧客サポートの受信箱の横に座って顧客と話しているだけで、MVPをそれ以上進めることはできなかった。私が辞めた後も、それ以上には進まなかったと思うし、進むべきではなかっただろう。ユーザーと直接話すのをやめた瞬間から、（野生的で、ほとんど言葉にできない）トレードオフが発生するから。そんなトレードオフをした記憶はないけど、製品関連の仕事をしていた中で、一番価値のある時間だったかもしれない。なぜなら、カスタマーサポートの問い合わせタイプが全体の0.005%に過ぎないとしても、私のクソMVPでもかなり複雑なエージェントと問い合わせタイプのツリーを通る必要があったから。だから、「ユーザーが製品に抱える問題を解決する」ことが「より良い製品を作る」ことに等しいなら、特定のユーザーの小さなサブセットのための擁護者であり、彼らの問題の詳細を非常に良く理解しているLLMと話すのは、本当に気持ちが良かった。私が開発者にとってのインターフェースとしてあるべき純粋なバージョンのように感じた。少なくともそれを見た後は「PM」のアイデアを信じ続けるのが難しかった。私は人々が自分のことを進めるのを見守る方が好きだったから。リンク先の投稿も楽しんだし、どれだけ進化したかを見るのは本当に興味深い。まだ「顧客とスケールで話す」ものを作った人がいないのは驚きだ。これは「顧客とスケールで話さない」よりもずっと面白い問題に感じる。でも、驚かないかも。ちゃんとやるには非常に特注な仕事だと思うから。

└

リンク先の投稿も楽しんだし、どれだけ進化したかを見るのは本当に興味深い。まだ「顧客とスケールで話す」ものを作った人がいないのは驚きだ。これは「顧客とスケールで話さない」よりもずっと面白い問題に感じる。 これを実現するのは、良いデータを調査を通じて得るのと非常に似た難しさがあると思う。私は一般的に、自分のツールと話したくない。もしあなたと話す気になったら、それはたぶん何かがうまくいかなかったからだ。たとえイライラしていないときにあなたと話しても、私がその瞬間に「うまくいっている」としか言えないだろう。製品担当者として本当に知りたいのは、「うまくいっているけど、私のユースケースのために何かの回避策を内面化しなければならなかった。それは最初は気持ち悪くて、ほぼ離脱しそうになったけど、今は考えもしない」とか、そういうことだ。

エンジニアとして、このフレームワークは好きだけど、これを使って製品を作れるPMがほぼゼロだと思う。

セキュリティエンジニアとして、AIの熱狂に乗っかっている誤ったPMたちを先取りしようとしている。彼らは1) 未成熟であること、2) 安全ではないこと、3) 彼らのビジネスユースケースが私たちがこれから投入するR&Dに適しているかどうかを知らない。機能の大きな後戻り、急いでパッチを当てること、またはMCP v0.00-beta（比喩的に言えば）で動作するレガシーシステムの山が出てくる予感がする。 :lol_sob:

└

コスト削減にばかり目を向けるのはやめよう。今の技術は人間を置き換えるにはまだまだ成熟してないからね。むしろ、人間の能力をエージェントで強化することに注力した方がいいよ。例えば、人間が電話で顧客と話している間に、AIがその顧客に関する有益な情報を集めて、会話をより良くするためのポイントを提案するって感じ。AIをこういうふうに使うことで、ビジネスにとっての直接的なメリットの一例は、新入社員のオンボーディング時間を短縮できることだね。