AIエージェントが新しいSaaSだ［YouTube］

• 従来のSaaSが業務ツールを販売していたのに対し、エージェントSaaSはチームがもはや手作業で処理しなくてよい業務そのものを販売し、数兆ドル規模の人的資本市場を狙う
• 有望なエージェントは、すでに従業員・エージェンシー・受付担当者・配車担当者に費用が支払われている業務のうち、頻度が高く、完了条件と損失が明確で、既存ソフトウェアにアクセスしながら一定の判断が必要な有償ワークフローから出発する
• 開発前に実際の担当者の事例を10〜20件観察し、トリガー・文脈・ツール・権限・承認・エスカレーション・成功基準を明記したうえで、下書き・承認または分類・調整・限定実行のいずれかによる**最小有用エージェント（MUA）**を作るべき
• 実際の事例50件で評価セットを構成し、ログ・承認・設定・引き継ぎルールを提供することで、顧客は動作とエラーを確認できるようになり、エージェントが仕事をこなしていても、このプロダクトラッパーがSaaSとしての信頼を形成する
• 1つのニッチ市場で同じ問題を抱える顧客2〜3社に、人とAIを組み合わせたパイロットを販売し、繰り返される部分をプロダクト化したうえで、検証済みの結果に応じて利用量・成果ベースの価格へ拡張するアプローチが必要

---

業務ツールから業務遂行プロダクトへ

• 中核となる考え方は「プロダクトこそが業務」ということ
  • 一般的なSaaSはチームが使うためのツールを販売する
  • エージェントSaaSはチームがもはや手作業で処理しなくてよい業務を販売する
• エージェント市場がSaaSより大きくなり得る理由は、ソフトウェア予算を超えて数兆ドル規模の人的資本市場を対象にしているため
• 良いプロダクト提案は、特定の面倒な業務をジュニア社員よりうまく処理し、エージェンシーより速く、人員を追加するより安くこなすという形になる

• レストランの電話対応

  • 夕食時に電話が集中すると、ホストは席案内と繰り返しの質問、予約依頼を同時に処理しきれず、予約や団体利用の問い合わせで売上を逃すことがある
  • Slang AIはレストラン向けAIスーパーホストの事例
    • 着信と顧客からの質問に応答する
    • 予約を管理し、VIPリクエストを伝達する
    • 団体利用の問い合わせや顧客クレームのような優先度の高いトピックをスタッフに通知する
    • レストランが使っている他のシステムと連携する

• ホームサービスの電話対応

  • 配管・HVAC・屋根工事・害虫駆除の業者は、電話を取り逃すと作業予約や追客が漏れ、配車担当者の負担が増えることがある
  • same dayはホームサービス事業者向けに24時間電話とSMSを処理するAI配車担当者・営業エージェント・受付担当者を販売している
    • 電話応答とSMS返信を処理する
    • 作業を予約したり日程を変更したりする
    • 同じ需要からより多くの売上を得られるよう支援する

すでに費用が支払われているワークフローを探す

• エージェントのアイデアは、人々がすでに従業員・エージェンシー・受付担当者・コーディネーター・配車担当者に費用を払っている業務から見つけるべき
• 自動化によってその業務の一部を軽くすれば、人はより創造的な仕事に集中できる

• 良いワークフローの5つの条件

  • 頻度が高いこと
    • 毎日起こる業務でもよいが、毎時間発生する業務のほうがより適している
    • インバウンドの見込み顧客、電話、技術サポートチケット、見積もり依頼、予約、注文、保守依頼が例
  • 完了条件が明確であること
    • 作業予約の完了、チケット分類、返金承認、ベンダー日程の確定、顧客への有用な回答の提供のように、成功かどうかを判定できる必要がある
  • 既存ソフトウェアを使うこと
    • Gmail、Slack、Shopify、HubSpot、Zenes、Stripeのようなシステムで文脈を読み取り、ツールを使える業務が適している
  • 例外は面倒だが学習可能であること
    • 単純すぎる業務は基本的な自動化やZapで処理できる
    • 純粋に人間の判断が必要なら、最初のバージョンは簡単に失敗する
    • 反復的でありながら、AIが役立つ判断を含む領域が適切
  • 買い手が損失を実感していること
    • 不在着信、遅い返信、離脱した見込み顧客、空き予約枠、低付加価値な調整に投入される高コスト人材などが該当する

• アイデアのスコアリング

  • 1つのニッチ市場を選び、人々が不満を持つ業務20件を書き出す
    • 屋根工事業者: 不在着信、金融関連の質問、保険書類、予約リマインダー
    • メディカルスパ: 見込み客の選別、ノーショーの回復、会員プランのアップセル
    • Shopifyブランド: 返品、交換、卸向け見込み顧客へのフォローアップ
  • 各業務は次の5つの基準で評価する
    • どれほど頻繁に発生するか
    • 問題によるコストがどれほど大きいか
    • 完了可否をどれほど簡単に判断できるか
    • どのツールにアクセスする必要があるか
    • 誰がすでに関連予算を持っているか
  • 最初に選ぶべき対象は、給与や外注費がすでに付いている業務である

開発前に実際の業務を観察する

• プロンプトを書いたりコーディングしたりする前に、その業務を行う人を観察してこそ、高品質なエージェントに必要な詳細情報を得られる
• 担当者が処理する10〜20件の事例を直接見るか画面録画し、実行過程を口頭で説明してもらう
  • どの事例が簡単か確認する
  • どの事例が特殊か把握する
  • 意思決定の前に何を確認しているか記録する
  • どこでミスが発生するか見つける
• 以前にその業務を自分でやったことがあっても、最近の実際の事例を改めて観察すると、開発過程で細かな流れを思い出す助けになる

• 業務の細部がプロダクト品質を決める

  • レストランホストの実際の業務は、営業時間の質問に答えることよりはるかに深い
    • キッチンのラストオーダー時刻を把握している必要がある
    • ベビーカーを置きやすいテーブルを見分ける必要がある
    • パティオ営業を停止しているか確認する必要がある
    • VIPをどう扱うか知っている必要がある
    • 特定の問い合わせを別担当へ回すタイミングを判断しなければならない
  • こうした実際の業務の細部がエージェントの品質を決める

• エージェント仕様の7要素

  • 何がエージェントを起動させるのか
  • どんな文脈が必要か
  • どんなツールを使えるか
  • 何を自分で処理できるか
  • どこで承認が必要か
  • いつ人にエスカレーションすべきか
  • 成功とはどんな状態か
  • これらの要素を明確にすることで、人と同等かそれ以上に働きつつ、より一貫した品質を提供できる

最小有用エージェントから始める

• 最初から完全自律の社員を作ろうとすると、デモはもっともらしく見えても実際には機能せず、事業が失敗しかねない
• 初期バージョンは**最小有用エージェント（MUA）**としてスコープを絞るべき

• 4つの初期バージョン

  • 下書き・承認エージェント
    • 文脈を読み取り、返信、見積もり、要約、または次のステップを作成する
    • 人が結果を承認する
    • リスク、創造性、承認プロセスが含まれる業務に適している
  • 分類エージェント
    • 入ってきた業務を分類し、適切な場所へ送る
    • 保守依頼、請求の問題、返金依頼などに適用できる
  • 調整エージェント
    • システムと人の間で業務進行を管理する
    • 空き時間を確認し、通知を送り、不足情報を求める
  • 限定実行エージェント
    • 明確なルールの下で特定の作業を直接実行する
    • 予約、フォローアップ、50ドル未満の返金などが例
  • 最小有用エージェントは、下書き、分類、調整、限定実行の順に自律性の範囲を広げられる

• ワークフローから自律エージェントへ

  • Anthropicのエージェント指針によれば、多くのエージェント問題はまず予測可能なワークフローから始めるべき
  • ワークフローは決められた経路に従うが、エージェントは状況に応じてより動的に判断する
  • 起業家は予測可能な経路から始め、判断が価値を生む部分にだけ自律性を追加すべき
  • 初期プロダクトは1つのワークフローと1つの約束で十分
    • 屋根工事業者の不在着信に応答し、適切な作業を予約する
    • 不動産管理者の保守依頼を分類し、適切なベンダー日程を設定する
    • レストランの予約電話を処理し、人が介入すべきときにスタッフへ通知する
  • 顧客もまた初めてエージェントを買う以上、MicrosoftやSalesforceではない新規事業者にすべての業務を一度に任せようとはしないかもしれない
  • したがって、機能する単一ワークフローで信頼を築く必要がある

信頼を作るプロダクトラッパーと評価体系

• エージェントが業務を遂行するなら、プロダクトラッパーは顧客に信頼とコントロールを提供する
• 単純な自動化とエージェント優先SaaSを分ける機能は次のとおり
  • 作業ログ
  • 承認プロセス
  • 制御設定
  • 人に渡すルール
  • 本番稼働前のテスト
  • エージェントが特定の行動を選んだ理由を確認する機能
• エージェントは電話システム、受信トレイ、Slackチャンネル、CRMの中で動作し得るため、ダッシュボードはシンプルでもよいが、顧客には管制室が必要
  • レストラン電話エージェント: 通話要約、予約結果、失敗した人間への引き継ぎ
  • 不動産保守エージェント: 作成されたチケット、ベンダー連携、入居者への更新通知、オーナー承認

• 実際の事例50件で評価する

  • 自律性を約束する前に評価セットを構成すべき
  • 電話、見込み顧客、保守依頼など実際の業務事例50件を収集する
  • 各事例に正しい答えを付けたうえで、次の項目を確認する
    • 問題を正確に分類したか
    • 必要な不足情報を尋ねたか
    • 正しいポリシーを適用したか
  • プロンプト、モデル、ツール、ワークフローを変えるたびに、同じ評価セットを再実行して改善と後退を確認する
  • 評価は営業プロセスでも信頼資料として活用できる
  • 過去の保守依頼50件のうち42件を正しく転送し、6件を人によるレビュー対象として分類し、2件でミスした、といった形で結果を公開する
  • ミスした事例と修正方法まで示せば、顧客はエージェントの限界と改善過程を確認できる

労働のようにパイロットを売り、SaaSとしてプロダクト化する

• 最も速い出発点は、AIと人が一緒に業務を行うパイロットを販売し、その後に繰り返される部分をプロダクト化すること
• 同じニッチ市場、ワークフロー、問題を持つ顧客3社から始め、結果を販売する
  • 不在着信に応答し、見込み顧客を選別する
  • 保守依頼を分類する
• 初期には導入費とわかりやすい月額サブスクリプションを受け取り、価値を把握した後で利用量または成果ベースの価格を追加する
• 顧客は追加のユーザー席ではなく結果に対して費用を払いたいと思うかもしれないが、最初から成果課金に切り替えず、十分に学んでから適用すべき

• 価格例

  • 導入費1,500ドルとワークフロー1件あたり月額1,000ドル
  • 導入費2,000ドルと検証済み予約1件あたり30ドル
  • 処理チケット500件まで月額3,000ドル
  • 正確な価格を見つけることより、次の情報を学ぶことのほうが重要
    • 顧客は何に価値を感じるか
    • エージェントはどこで失敗するか
    • どの作業に承認が必要か
    • プロダクトを取り除いたとき、顧客が最も惜しむものは何か

• 繰り返しパターンのプロダクト化

  • すべての屋根工事業者が緊急電話スクリプト、サービス地域確認、金融関連の質問、見積もり後のフォローアップを必要とするなら、それを1つのプロダクトにできる
  • すべてのメディカルスパが見込み客スコアリング、相談予約、ノーショー回復、施術後フォローアップを必要とするなら、同じようにプロダクト化できる
  • まず自分で業務を実行しながら共通パターンを見つけてこそ、再利用可能なソフトウェアを作れる

ワークフロー比較コンテンツで顧客を獲得する

• 顧客獲得コンテンツとしては、従来方式とエージェント方式を並べて見せるワークフロー解剖が効果的

• 従来方式

  • 誰も電話に出ず、顧客が競合へ流れる
  • カスタマーサービス担当者が質問し、日程とサービス地域を確認してから予約する
  • メモとリマインダーは残すが、フォローアップを忘れる

• エージェント方式

  • 電話を受け、適切な質問をする
  • サービス地域と緊急度を確認する
  • 予約を作成し、CRMを更新する
  • 確認メッセージを送信する
  • 例外事例を人に引き渡す
  • 管理者は既存プロセスで発生する損失を直接実感しているため、ビタミンではなく鎮痛剤に当たるプロダクトを売るべき
  • 1つのワークフローを選び、インターネット上でその業務とプロダクトが結びつくようにする必要がある
  • チェックリストとベンチマークを作る
  • ワークフロー解剖資料と約50本の事例コンテンツを公開する
  • 従来方式を風刺したりミーム化したりする
  • 反応の良いコンテンツを選んで有料広告を配信する
  • 最初は1つのプラットフォームに集中し、構築期間を通して見込み顧客層も並行して作る必要がある

30日間のエージェント事業実行計画

• 第1週: ニッチ市場と動くバージョンの検証

  • 1日目: 見落とされた業務が金銭的損失につながるニッチ市場を選ぶ
    • ホームサービス、不動産管理、保険代理店が例
  • 2日目: 運用担当者10人にインタビューし、画面共有でワークフローを観察する
    • インタビュー費用を支払ってもよい
    • 通話内容を研究資料として保管する
  • 3日目: 頻度、痛み、ソフトウェアアクセス性、明確な成功指標を備えたワークフローを1つ選ぶ
  • 4日目: トリガー、文脈、ツール、ルール、引き継ぎ、評価を含むエージェント仕様を書く
  • 5日目: Claudeやchatbtを使って文脈をコピー＆ペーストし、結果の下書きを作ってから人が承認するようにする
    • ソフトウェアを作る前に、AIが実際の業務に役立つか検証する
  • 6日目: 下書き・承認または分類機能を中心に、最も小さい有用なバージョンを構築する
  • 7日目: 実際の事例50件で評価セットを作る

• 第2週: 同じニッチ市場でパイロットを販売

  • 同一のニッチ市場とワークフローを対象にパイロット2件を販売する
  • スコープを絞り、同じ問題と結果を反復的に検証する

• 第3週: SaaSの制御機能を追加

  • ログ、承認、設定、分析、人への引き継ぎを含むプロダクトラッパーを追加する
  • AIを使ってそのソフトウェアを構築し、Clawude DesignとFableがツールの例として含まれる

• 第4週: 証拠と配信チャネルを確保

  • ワークフロー解剖コンテンツを公開する
  • パイロット結果をプロダクトの検証資料に変換する
  • 反応の良いコンテンツ形式を見つけ、その戦略に集中する
  • 有料の顧客獲得に費用を投じられるチャネルを把握する
  • 2か月目と3か月目には、顧客生涯価値（LTV）、機能するチャネル、追加投資すべき領域を確認する

繰り返される痛みのある業務をなくす事業

• ソフトウェアの役割は「業務を助けるツール」から「一緒に業務を遂行するシステム」へ移っている
• 機会は、よく理解しているニッチ市場で、一日中繰り返される最も小さく痛みの大きいワークフローを見つけて取り除くことにある
  • 電話応答
  • 作業予約
  • チケット分類
  • システム更新
  • 特殊事例の人へのエスカレーション
• 実行順序は、業務を見つける、担当者を観察する、仕様を書く、手動運用する、最小有用エージェントを構築する、パイロットを販売する、反復部分をプロダクト化する、である
• 人がすでに費用を払っている業務を安定して実行し、制御・評価・引き継ぎ手段まで提供してこそ、顧客が実際に購入するエージェントSaaSになる