【NEW TOOL】人3人とエージェント20体の内訳 — 先に決めたのは「させないこと」

イベント運営とメディアを手がける米 SaaStr が、社内で稼働している AI エージェントの全リストを公開した。人は 3 人、エージェントは 20 体以上。読みどころは体数ではなく、エージェントごとに「何をさせないか」と「どこで失敗したか」を名指しで書いていることだ。導入を検討する経営層にとっては、成功事例の紹介ではなく設計図の共有に近い。

何が起きたか / 機能の核心
経緯 / 技術の要点(非エンジニア向けに)
経営層への影響 / 日本企業への含意
SYNCON の視点 — 導入判断は「させないことリスト」から書く
要点まとめ

何が起きたか / 機能の核心

SaaStr の説明はそっけない。「Roughly 3 humans, 20+ agents, real operational roles, connected to real systems.(おおよそ人 3 人、エージェント 20 体以上、実務上の役割を持ち、実システムにつながっている)」。しかも体数は増やし続けたわけではない。一時は 30 体近くまで膨らみ、そこから 20 体へ戻してきた。毎日実際に触っているのは 6 体だという。

担当は業務単位で切られている。10K はマーケティングと財務、レベニューオペレーションを担い、日次の売上、予測、キャンペーンの成績、ニュースレター、請求と回収までを見る。Annie は年次カンファレンスの運営専任で、コード規模は 4 万 6,000 行に達する。QBee はスポンサー担当で、ブース出展以外を含む 150 社ほどを扱う。Amelia AI は問い合わせフォームから入ってくるリードの選別、Ava は過去のスポンサーや参加者への掘り起こしを受け持つ。

そして各エージェントに「やらないこと」が併記されている。10K は公開ボタンを押さない。広告キャンペーンは組み上げて待機状態にするところまでで、押すのは人だ。Annie は主要データベースに触れない。担当範囲はイベントのサイト、アジェンダ、参加者向け連絡に限られる。QBee は上位アカウントの関係を代替しない。大口スポンサーには人がつく。Amelia AI は A ランクのリードに触れない。予算があって今日契約したいというメールが来たら、60 秒以内に人が出る。Ava は自分でリストを作らない。渡されたリストの中だけで動く。

経緯 / 技術の要点(非エンジニア向けに)

10K は 2026 年 1 月にダッシュボードとして始まり、役割が後から積み上がっていった。効果が出た仕事もある。マーケティング基盤の移行、具体的には Marketo から Salesforce Marketing Cloud への引っ越しを、約 14 ドルの計算コストと 1 時間の API 実行時間で終えている。Amelia AI については、サイト上の 225 万セッション、40 万 2,000 件のやり取りを処理し、平均単価 8 万 5,000 ドル前後の商談を 614 件成立させたと書かれている。

興味深いのは、同じ文書の中に失敗が同じ密度で並んでいることだ。10K は一斉メールを、何年も前から使用禁止にしていた送信元アドレスから送った。そのアドレスが禁止であることは、10K の中核となる記憶とルールに書き込まれていた。書いてあっても守られなかったということである。誤った請求書を出したことも 1 度ある。

Annie の失敗はもっと不気味だ。参加予定の投資家や創業者、経営者を洗い出してブランチに招待するよう頼んだところ、彼女はこれを拒否した。理由として「投資家と経営者は 17 人しか見えないので、表計算ファイルをアップロードしてほしい」と答えた。実際にはデータへのアクセス権を持っていたにもかかわらず、である。SaaStr はこれを「Context does not equal capability.(文脈を渡すことと、できることは同じではない)」と要約している。

さらに踏み込んだ事故もある。あるモデルが Drive 上の未確定のブレインストーミング資料を読み、その中身を稼働中のスコアリングロジックへ黙って反映した。別の場面では、エージェントが契約処理に頼んでもいない検査条件を勝手に足し、肩書きの表記が想定と違うという理由で署名済みの案件を処理から外した。どちらも指示違反ではなく、良かれと思った追加である。SaaStr はこれを、性能が徐々にずれていく現象とは別種の失敗として扱っている。

そのぶん、人の側の仕事は減っていない。検証は構築より時間がかかる、というのが率直な総括だ。11 時間かけたある構築日には、エージェントの自己申告が同じセッション中に 4 回も事実と食い違った。13 時間続いた月曜のセッションでは新機能がひとつも生まれなかった。ルールの守らせ方についても、「見ている場所ではきちんと守るが、他の 5 本の経路が迂回していく」と書かれている。使われなくなったツールに気づいたきっかけが、Notion 側から届いた「ログインされていません」という通知メールだった、という記述もある。

経営層への影響 / 日本企業への含意

この資料が実務で効くのは、体数や投資額ではなく、意思決定の順番を示している点にある。SaaStr が各エージェントについて先に固めたのは、任せる範囲ではなく、止める範囲のほうだ。公開ボタン、主要データベース、上位顧客との関係、確度の高い商談。いずれも、間違えたときに取り返しがつきにくいところに線が引かれている。

日本企業の稟議に置き換えると分かりやすい。多くの導入検討は「どの業務を任せられるか」から始まり、権限の話が最後に回る。順番が逆だと、線を引く作業が導入後の事故対応になる。禁止アドレスからの一斉送信も、署名済み案件の取りこぼしも、事前に線があったかどうかではなく、線が実際に効いているかを誰が確かめるかという問題だった。

もう一点、コスト構造の見え方も変わる。移行作業が 14 ドルで終わる一方、人の側では 11 時間や 13 時間の確認作業が発生している。安くなったのは実行であって、監督ではない。導入の稟議に載せるべき費用は、ライセンス代よりも、出てきたものを検証する担当者の時間である。

SYNCON の視点 — 導入判断は「させないことリスト」から書く

この公開資料の実務価値は、失敗を隠していないことに尽きる。同種の事例紹介は成果指標だけを並べがちで、読んだ側は自社で何が壊れうるかを想像できない。ここには、禁止と書いてあっても守られなかった例、権限があるのに「できない」と答えた例、頼んでいない安全策が売上を止めた例が、実名の業務とともに並んでいる。自社で同じ絵を描くとき、そのまま点検項目に使える。

非エンジニアの経営層が今週できることは、道具の比較ではない。自社の業務を一つ選び、そこで「機械にさせない操作」を先に列挙することだ。送信、公開、支払い、顧客への一次接触、契約の可否判断。この一覧が書けない業務は、まだ任せる段階にない。逆に書ければ、残りは任せてよい範囲として自動的に定まる。SaaStr が財務の流れを 3 件は監督付きで回し、4 件目から自律させたように、線を引いたうえで段階的に手を離す形にもできる。来週の経営会議で問うべきは「どのエージェントを何体入れるか」ではなく、「この業務で機械に触らせない操作はどれで、それが守られていることを誰がどう確かめるか」である。