エージェント向け製品設計

もしあなたが私と同じように、X（旧Twitter）の特定のタイムラインを頻繁にチェックしているなら、「ユーザーインターフェースは死んだ」という主張を目にしたことがあるはずです。

「Obsidian で第二の脳を構築する方法」のような投稿と、「Anthropic が某業界を完全に壊滅させた」といった投稿が混在するフィードをスクロールしているうちに、やがて「MCP、API、CLI、あるいはその中間の手段で AI エージェント（AI Agent）に利用できない製品は生き残れない」という意見を目にするようになります。

この傾向は Ramp においてすでに顕著です。過去3ヶ月間で、Claude、ChatGPT、その他の AI エージェントを通じて当社の製品を利用する顧客が増えるにつれ、MCP における週間アクティブユーザー数が10倍に増加しました。（MCP：Model Context Protocol、モデルコンテキストプロトコル。これは AI エージェントが外部ツールやデータにアクセスするための標準的な手段と理解できます。）

先週、Salesforce はこの判断を積極的に受け入れた最初の伝統的なソフトウェア大手の一つとなりました。

出典：https://venturebeat.com/ai/salesforce-launches-headless-360-to-turn-its-entire-platform-into-infrastructure-for-ai-agents

https://www.salesforce.com/ は水曜日、同社27年の歴史において最も過激なアーキテクチャ変革を発表し、「[https://www.salesforce.com/news/stories/salesforce-headless-360-announcement/」を立ち上げました。これはプラットフォーム全体を対象とした大規模な計画で、プラットフォーム内のすべての機能を API、MCP ツール、または CLI コマンドとして公開し、AI エージェントがブラウザを開くことなくシステム全体を操作できるようにするものです。

この発表は、Salesforceがサンフランシスコで開催する年次https://www.salesforce.com/tdx/大会で発表され、100以上の新しいツールやスキルがすぐに開発者に公開されました。また、これは企業ソフトウェアの頭上に懸かる死活問題に正面から応えるものです：AIエージェントがすでに推論、計画、実行を行えるようになった今、企業はグラフィカルインターフェースを備えたCRM（Customer Relationship Management）システムをなお必要とするのか？

Salesforceの答えは「不要」であり、これこそがポイントです。

Salesforceのこの一手は賢明であり、これが容易な決定ではなかったことは想像に難くありません。多くの営業担当者にSalesforceの使用感を尋ねれば、彼らはおそらくSalesforceを使うのが好きではないと答えるでしょう。しかし、Salesforceがこれほどまでに普及している理由の大きな部分は、そのユーザー体験（UX）が十分に慣れ親しんだものであることです。営業責任者は通常、チーム全体を新しい技術に適応させることを望みません；多くの場合、機能の豊かさよりも一貫性の方が重要です。

Benioff氏とそのチームは、この堀（護城河）が侵食されつつあることを認めています。彼らはまた、今後多くの行動がClaude、ChatGPT、そしてユーザーには見えないバックグラウンドのプロセスを通じて行われるという現実を積極的に受け入れ始めています。

私はユーザーインターフェース（UI）が死滅すると考えていません。人間はまだボタンをクリックし、設定を確認し、タスクが完了したことを確認したいと考えています。しかし、パレートの法則（二八法则）は逆転しています：未来における人間とソフトウェアの80%のインタラクションは、AIエージェントを通じて行われることになります。これはあなたが何を構築する必要があるかだけでなく、どのようにそれを構築するかをも変えるでしょう。

新しいインタラクションモード

過去20年間、人々がソフトウェアとインタラクションする主要な方法は以下の通りでした：

ユーザー → インターフェース → データベース

製品を開き、クリックして操作し、タスクを完了させます。インターフェースこそがソフトウェアを体験する方法です。多くの人にとって、インターフェース自体が製品そのものです。

しかし、AIエージェントがより多くの作業を引き受けるにつれて、新しい中間層が登場しました：

ユーザー → ユーザーのAIエージェント（例：Claude）→ データベース

AIエージェントはユーザーに代わって行動します。それは読み取り、書き込み、製品の閲覧を行い、ユーザーが自ら操作する必要がなくなります。突然、インターフェースは消滅します。エージェントは直接基盤システムと対話し始めます。

ただし、このモードも急速に変化しています。ソフトウェア会社は——そしてそうすべきです——独自のAIエージェントと能力を設計しています。したがって、新しいモードはより以下のようになります：

ユーザー → ユーザーのAIエージェント → ソフトウェア独自のAIエージェント → データベース

このモデルでは、ソフトウェア独自のAIエージェントがユーザーのエージェントの複雑さを処理します：ビジネスロジックの実行、ルールの適用、後者が持たないコンテキストの補完。2つの大規模言語モデル（LLM）が協力して、同じ結果に向けて進みます。

AIエージェントに成功する方法を教える

現在、私のブレインストーミング、執筆、アイデア出しの大部分は、大規模言語モデルとの共同作業によって行われています。ドラフトが共有準備ができると、NotionのMCPサーバーを通じてNotionに送信します。私は長年Google Docsの忠実なユーザーでしたが、NotionのMCPが私の習慣を変えました。

Notion MCPの利用者として私が賞賛している点は、AIエージェントに何かを書かせると、それがほぼ毎回完璧に実行されることです。表、箇条書き、斜体、リストなど、考えられるフォーマットはすべて正しく処理されます。

これは偶然ではなく、設計された結果です。

Notion の notion-create-pages ツール説明には、最初から「完全な Markdown 仕様の詳細が必要な場合は、まず MCP リソース notion://docs/enhanced-markdown-spec を取得してください。Markdown 構文を推測したり、幻覚で生成したりしないでください」と明記されています。私がエージェントにページへの書き込みを指示した際、その最初の行動はまさにこの仕様の取得でした。まず仕様を読み、その後で書き込みを開始します。Notion 固有の仮定はすべて明示され、汎用モデルのデフォルト理解に依存することはありません。

旧世界では、こうした仕様は API ドキュメントに記載されていました。Notion に接続する開発者はドキュメントを読み、ルールを理解し、変換層を構築していました。現在では、Notion は AI エージェントが実際に必要とする瞬間に、直接仕様を提供します。

Slack MCP を使用した経験があるなら、逆のケースを経験しているかもしれません。あなたの AI エージェントは標準 Markdown をデフォルトで使用しますが、Slack 独自の特定フォーマットに従いません。その結果、書式修正に費やす時間が、手動でメッセージを作成する時間よりも多くなることがあります：

もちろん、Slack のフォーマットガイドはオンラインで入手可能であり、保存してエージェントに使い方を教えることも可能です。しかし、それは煩雑であり、本来ユーザーが気にすべきことではありません。

あなたが考えるべきは、あなたのエージェントを呼び出す人が、成功するために何を知る必要があるかです。そして、その情報を積極的に提供してください。エージェントに独自で調査させるのではなく、手助けしてあげましょう。

フィードバックループの構築

Ramp で MCP を公開した当初、最大の課題は観測可能性（observability）でした。ツール呼び出しの数は確認できましたが、それらの呼び出しを引き起こしたチャットのコンテキストは見えませんでした。単に呼び出し数を知るだけでは、何が機能し、何が壊れ、ユーザーが実際に何を実現しようとしているのかを教えてくれません。

その後、私たちはいくつかの方法でこの問題を解決しました：

• 各ツール呼び出しに「理由」の記入を要求する。 すべての MCP または CLI ツール呼び出しにおいて、AI エージェントに rationale 引数を含めさせ、リクエストを発行する理由を説明させます。チャット内容は見えませんが、この理由によって意図を再構築できます。理由に含まれるパターンから、ユーザーの本当の目的がわかります。

• フィードバックツールを提供する。 独立したツールを公開しました。AI エージェントが壁にぶつかったり、特定のパターンが機能しないことに気づいたりした場合、このツールを呼び出すことができます。エージェントは、本来達成しようとしていたこと、試した内容、そして行き詰まった箇所を提出します。

• 特定のツールにコンテキストシードを追加する。 単一のツールに対して、後ほど有用となるコンテキストを捕捉するために特別に設計された引数を追加します。この情報はエージェントが取得可能ですが、能動的に収集しない場合、後からでは推測するしかなくなります。

顧客サポートプラットフォームを構築し、ツールを通じて顧客がチケットを取得できるようにしていると想像してください。時間が経つと、理由ログの中で「インシデントレポートを生成中」「インシデント概要のドラフト作成中」「ダウンタイム振り返り関連チケットの収集中」といった類似の表現が繰り返し目立つようになります。

これは新たな製品機能のシグナルです！ 関連するチケットを識別し、重大度を評価し、影響を受けた顧客グループを取得し、強力な制約付きフォーマットで概要をドラフト作成する build-incident-report ツールを作成できます。

このツールが公開された後、以下のようなフィードバックが届き始めるかもしれません。「レポートに3日前のチケットが含まれているが、それらは今回のインシデントには関係ない」「無料プランユーザーのチケットを常に振り返りに含めてしまうが、これらのユーザーはインシデント振り返りには含まれるべきではない」。突然、あなたの AI エージェントが、次に構築すべきことをあなたに教えてくれるようになります。

AI エージェントは間違いなくハルシネーションを起こします。しかし、フィードバックの点において、それらはあなたが製品に送る人間のユーザーの大多数よりも、具体的かつ一貫性のある報告を行う傾向があります。

レポートに無関係なチケットが含まれている場合は、日付範囲のパラメータを追加します。フリープランの顧客を含めるべきでない場合は、顧客セグメントのフィルターを追加します。各フィードバックループは、製品改善のための新たな入力口となります。

文脈のギャップに注意する

あらゆる AI エージェント間のやり取りにおいて、あなたのシステムは呼び出し元エージェントが知らない文脈の一部を保持しており、一方、呼び出し元エージェントもあなたのシステムが知らない文脈の一部を保持しています。これらのやり取りを設計する際、どちらの側がどの情報において優位性を持っているかを明確に判断すべきです。

例えば、Diego が出張に出ました。彼の AI 首席補佐官は、経費管理システムのエージェントから Slack の通知を受け取ります：最近の出張で未処理の精算があるとのことです。現在、2 つの AI エージェントは同じ目標——これらの精算を正しく提出すること——に向かっています。

これら 2 つのエージェントは、それぞれ異なる文脈を持っています。

Diego の AI 首席補佐官が知っていること：

• Diego のカレンダー：どの会議が行われ、いつ、誰と行ったか

• Diego のメール：ホテルやフライトの確認メールの添付ファイル

• Diego の Slack：Kokkari での夕食を、Acme チームを招待した会話スレッドに関連付けることができる

• Diego のレシート：メールの添付ファイルや写真ギャラリーから取得

経費管理システムが知っていること：

• 元の取引データ（例：店舗名、取引時刻）

• 精算提出に関する会社のポリシー

• 会社の総勘定元帳科目（GL accounts）（GL は通常 General Ledger、つまり財務会計における総勘定元帳の分類を指します）

• 会社の過去の費用分類の習慣

従来の API は、この問題をユーザーに戻します：「ここに GL コードの入力が必要な取引があります。このインターフェースを呼び出して 150 個の GL コードオプションを取得し、自分で選択してください。」

適切に設計された AI エージェント間のやり取りは、この処理を逆に行います——GL コードを直接要求するのではなく、文脈を要求します。これは顧客接待費、チーム会議費、それとも個人の旅行支出でしょうか？AI 首席補佐官は、カレンダーエントリや Slack の会話から答えを見つけることができます。その後、経費管理システムは、自身が欠いていた文脈に基づいて、正しい科目を自動的に適用します。

Diego も彼のエージェントも、GL コードが具体的に何であるかを知らなくても構いません。財務チームは正確な分類を得ることができます。双方は各自が知っている情報を貢献し、最終的に Diego——そして彼の会計担当者にとっても——より良い結果を納品します。

エージェントからエージェントへのやり取りを設計する際、文脈のギャップに必ず注意してください。あなたのエージェントがどこで苦手であるかを認めることは完全に許容されます——なぜなら、你们は実際には同じユーザーのためにサービスを提供しているからです。

過去では、インターフェースは Diego と彼の経費システムの間に挟まれていました。現在、インターフェースは彼のエージェントとあなたのエージェントの間に挟まれています。

この変化は、製品チームの仕事の定義を再定義します。過去には、あなたはタスクを迅速に完了し、ミスを避け、自分の作業を見える化したい生身の人間のために製品を設計していました。現在でも、あなたは同じ人をサービスしていますが、その間に仲介者（エージェント）が追加されています。その直感、文脈、および限界は人間とは異なります。

AI エージェントが成功する方法を教えること、フィードバックループを構築すること、文脈のギャップに注意すること——これら 3 つのことの背後にある本質的な問いは同じです：あなたのエージェントを呼び出す側が、仕事を遂行するために本当に必要としているものは何か？あなたはそれらをそのエージェントに提供していますか？

多くの企業はMCPを1つリリースし、「私たちもAIエージェントに対応しています」というチェックボックスにチェックを入れるだけで、次のステップへ進んでしまいます。その利用数は数四半期は増加するかもしれませんが、その後停滞します。時が経つにつれて、顧客は細部まで磨き込まれた製品へと流れていき、おざなりな対応の製品は避けられるようになります。

当初、人間ユーザーのために製品を設計したように、AIエージェントのためにも真摯に製品を設計してください。なぜなら、やがて請求書にサインする相手こそがエージェントであることに気づくことになるからです。