原文：Designing for Agents
著者：Teddy Riker
📌 はじめに：この記事は何を伝えるのか？
「UIは死んだ」――そんな言葉がSNSを飛び交っています。
しかし、RampのProduct HeadであるTeddy Rikerはこう言います。
UIは死んでいない。でも、ソフトウェア交互の"8割"はAIエージェント経由になる。
- Ramp社では過去3カ月で、MCP（Model Context Protocol）上の週間アクティブユーザーが10倍に成長した
- SalesforceはプラットフォームのあらゆるUIをAPI/MCP/CLIで操作できる「Headless 360」を発表し、「ブラウザを開かずにCRM全操作」を可能にした
- AIエージェントが台頭する今こそ、エージェントのために設計するという新発想が必要である
🔄 ソフトウェア交互アーキテクチャの進化
旧来のモデル（過去20年間）
ユーザー → UI（インターフェース） → データベース
ユーザーが画面をクリックし、フォームを入力し、ボタンを押す。
このモデルでは「UIがプロダクトそのもの」でした。
中間期モデル（現在進行中）
ユーザー → ユーザーのAIエージェント（例：Claude） → データベース
AIエージェントがユーザーの代わりに操作する。
UIが消え、エージェントが直接バックエンドと対話する。
次世代モデル（これからの標準）
ユーザー → ユーザーのAIエージェント → ソフトウェア側AIエージェント → データベース
2つのLLMが協調して1つの結果を導く。
| 担当 | 役割 |
|---|---|
| ユーザーのAIエージェント | ユーザーのカレンダー・メール・チャット履歴・受領書など「個人コンテキスト」を持つ |
| ソフトウェアのAIエージェント | ビジネスルール・歴史データ・ドメイン知識・ポリシーなど「システムコンテキスト」を持つ |
💡 ポイント：問題をユーザーに投げ返すのではなく、2つのエージェントが互いの知識を補完し合って解決する。
🧩 原則1：エージェントに「成功の定義」を教える
Notion MCP が優れている理由
Riker氏はNotionのMCPを使って記事を書く際、フォーマットのミスがほぼゼロだと言います。
表・箇条書き・イタリック・リスト——どれも一発で正確に出力される。
その理由は設計にあります。
Notionのnotion-create-pagesツールの説明文にはこう書かれています：
完全なMarkdown仕様が必要な場合は、必ずMCPリソース
notion://docs/enhanced-markdown-spec を先に取得すること。
Markdown構文を推測・幻覚しないこと。
エージェントはページを書く前にまず仕様書を読む。
Notion固有の前提はすべて明示され、汎用モデルの"デフォルト解釈"には頼らない。
Slack MCPが失敗している理由
対照的に、Slack MCPでは：
- AIエージェントが標準Markdownを前提に動作する
- しかしSlackは独自のフォーマットルールを持つ
- 結果：送信されたメッセージのフォーマットは崩れ、ユーザーが手動で修正する羽目になる
自分で書くより時間がかかるという本末転倒な状況が生まれる。
🎯 設計の教訓
| ❌ やってはいけないこと | ✅ やるべきこと |
|---|---|
| 仕様をドキュメントに書いて「あとで読む」 | エージェントが必要なタイミングで仕様を直接渡す |
| 呼び出し元が常識で判断できると思い込む | 必要な情報を能動的に提供する |
| 汎用モデルのデフォルトに依存する | ツール固有のルールを明示する |
💡 核心原則：「呼び出し元のエージェントが成功するために何を知る必要があるか？」を考え、それを能動的に提供せよ。
🔁 原則2：フィードバックループを構築する
RampにおけるMCPリリース後の課題
RampがMCPをリリースした直後、最大の壁は**可観測性（Observability）**でした。
- ツール呼び出し数は見えた
- しかし「なぜそのツールを呼んだのか」というチャットの文脈は見えなかった
- 数字だけでは「何が機能していて、何が壊れているか」がわからない
Rampが実装した3つのフィードバック機構
① 全ツール呼び出しに「rationale（理由）」パラメータを必須化
// MCPツール呼び出しの例（概念）
{
"tool": "ramp_get_transactions",
"rationale": "出張費の精算を完了するために、未提出の取引一覧を取得しています",
"date_range": "2026-04-20_to_2026-04-27"
}
- チャットの内容は見えなくても、rationaleがユーザーの意図を再構成してくれる
- 同じパターンのrationaleが大量に出現すれば、それはユーザーの本当のニーズ
② 独立した「フィードバックツール」の提供
エージェントが行き詰まったり、パターンが機能しないと判断したとき、専用のフィードバックツールを呼び出す。
送信内容：
- やろうとしていたこと
- 試みたこと
- どこで詰まったか
これはユーザー意図のアクティブなシグナルになる。
③ ツール固有のシードパラメータ
各ツールに固有のパラメータを設け、後続分析に必要だがエージェント自身は推論できないコンテキストを捕捉する。
📊 フィードバックループが生み出すプロダクトロードマップ
具体例：カスタマーサポートプラットフォーム
rationaleログを蓄積して分析すると、同様の表現が頻出：
「インシデントレポートを生成中」
「障害のサマリーを起草中」
「ダウンタイムの事後検討に関連するチケットを収集中」
➡️ これは新機能のシグナル！
そこでbuild-incident-reportツールを作成。すると今度はこんなフィードバックが来る：
「このイベントとは無関係な3日前のチケットが含まれている」
「フリープランのユーザーのチケットが事後検討に入っているが、本来入るべきではない」
これを受けて：
- 日付範囲パラメータを追加
- 顧客セグメントのフィルタを追加
💡 AIエージェントが、あなたのAIエージェントに「何を作るべきか」を教えてくれる。
🤖 AI vs 人間のフィードバック品質
| フィードバック種別 | 具体性 | 一貫性 |
|---|---|---|
| 人間のユーザー | 「なんか使いにくい」「ちょっとわかりづらい」 | 低い（感情・主観が混じる） |
| AIエージェント | 「date_rangeパラメータが今回のイベントとは無関係な3日前のチケットを含んでいる」 | 高い（構造的・具体的） |
AIエージェントは「感覚」ではなく「事実」でフィードバックする。だからこそより行動可能（actionable）。
🧠 原則3：コンテキストのギャップを意識する
Diego の出張精算シナリオ
Diego が出張から戻った。彼のAIチーフ・オブ・スタッフが、費用管理システムのAIエージェントからSlackで通知を受け取った：
「未完了の出張費精算があります。」
2つのAIエージェントが同じゴールに向かって動き出す。
各エージェントが持つコンテキスト
Diego のAIチーフ・オブ・スタッフが知っていること
- 📅 Diegoのカレンダー：どの会議がいつ誰と行われたか
- 📧 メール：ホテルや航空券の確認書がある
- 💬 Slack：Kokkariでの夕食がAcmeチームを招待したスレッドと関連していることがわかる
- 🧾 領収書：メール添付や写真アルバムから取得できる
費用管理システムのAIエージェントが知っていること
- 💳 原始取引データ：加盟店名・取引日時
- 📋 会社の経費精算ポリシー
- 📒 GLアカウント（総勘定元帳科目）（General Ledger）
- 🔄 過去の費用分類パターン
旧来の API 設計 vs 良いエージェント設計
❌ 従来のAPIが問うこと：
「この取引にはGLコードが必要です。
以下のエンドポイントで150個の選択肢から1つを選んでください。」
✅ 良いエージェント設計が問うこと：
「これはクライアントとの食事ですか？チーム内の食事ですか？それとも個人の出張費ですか？」
費用管理エージェントがコンテキストを尋ねると、DiegoのAIはカレンダーやSlackスレッドから自動で答えを引き出す。
費用管理システムは不足していたコンテキストに基づいて正しい勘定科目を自動で適用する。
結果：
- Diego と彼のエージェントはGLコードを知らなくてよい
- 経理チームは正確な分類を得られる
- 両者が自分の得意な部分を担当し、最良の結果を出す
🗺️ コンテキストギャップへの対処法
【設計する際に自問すること】
あなたのエージェントは何を知っているか？
↓
呼び出し元のエージェントは何を知っているか？
↓
どちらが何の情報において優位か？
↓
互いの不得意を補い合う設計になっているか？
💡 あなたのエージェントが苦手なことを認めることは完全に正しい。
なぜなら、両者は同じユーザーにサービスを提供しているのだから。
📐 3原則のまとめ
| 原則 | 要点 | アンチパターン |
|---|---|---|
| ① エージェントに成功を教える | 仕様・ルールを能動的に提供し、推測させない | 「ドキュメントを読めばわかる」と放置する |
| ② フィードバックループを作る | rationale・フィードバックツール・シードパラメータで意図を可視化する | ツール呼び出し数だけ見て満足する |
| ③ コンテキストギャップを意識する | 両エージェントが互いの不足を補い合う設計にする | GLコードのように複雑さをそのままユーザーに押し付ける |
🏁 おわりに：エージェントに支払われる時代
「かつて人間のためにインターフェースを設計したのと同じ真剣さで、
AIエージェントのためにインターフェースを設計してください。
なぜなら、あなたの製品に最終的に支払いをするのは、
エージェントかもしれないのだから。」— Teddy Riker
多くの会社はMCPを公開し、「AIエージェント対応済み ✅」と記して前に進みます。
数四半期は利用量が増えるでしょう。でも、やがて停滞します。
時間が経つにつれ、顧客は細部まで丁寧に設計されたプロダクトに流れていきます。
UIは死んでいません。しかしプロダクトチームの仕事の定義は変わりつつあります。
| 旧来の仕事 | 新たな仕事 |
|---|---|
| 素早くタスクを完了したい人間のために設計 | AIエージェントが正しく動くためのコンテキストとルールを設計 |
| エラーを起こさないUIを作る | エージェントがエラーを起こさないツール定義を作る |
| ユーザーの行動ログを分析する | エージェントのrationaleログとフィードバックを分析する |