昨日の午後、私たちのチームのエンジニアがSaaStrのステージでAnthropicが社内GTMスタックを紹介するのを見て、スライドのスクリーンショットを撮り、Zeroにたった一つの質問を投げかけました。このうち、私たちが欠けているのはどれ？ それから6時間19分後、Snowflakeはすべてのお客様向けに本番環境で稼働していました。これは私たちが一年間で出荷した180番目あたりの連携機能で、次の一つを書くのがエンジニアではない、ということが、ますます当たり前になってきています。これを可能にしているフレームワーク、そしてその上に乗っている社内スキルを紹介します。
エージェントプラットフォームについて、誰も話さないこと
LLMは瓶の中の脳です。それ自身では、データウェアハウスについての詩を書くことはできますが、実際に開くことはできません。チャットボットをエージェントに変えるもの、つまりチームが本当にお金を払っているものは、エージェントがすでに使っているツールに手を伸ばし、その中で実際に仕事をすることができるかどうかです。
私たちはこの「手の届く範囲」を コネクタレイヤー と呼んでいます。Zeroを一年間作り続けてきた経験から、エージェント製品においてこれが最も重要なインフラだと確信しています。だから自分たちで作りました。さらに重要なのは、その周りに、チームの誰もがコネクタを書けるワークフローを構築したことです。
なぜMCPではないのか。なぜZapierではないのか。
早い段階で両方とも提案されました。それぞれは、それぞれの目的には素晴らしいものです。でも、私たちが必要としていたものではありませんでした。
MCP はプロトコルであり、製品ではありません。自社サービスをどんなLLMからも到達可能にしたいツール作者にとっては素晴らしいものです。しかし、今日デプロイされているMCPサーバーは、モデルにツールのリストを渡し、安全に呼び出してくれることを信頼してしまっています。組織ごとのクレデンシャル保管庫もなく、どのエンドポイントを叩いていいかのファイアウォールもなく、呼び出しを承認した人間まで遡れる監査ログもありません。あるエージェントがお客様の本番Stripeに触れ、別のエージェントがCEOのGmailでメールを書く可能性のある製品にとって、「モデルを信頼する」はセキュリティモデルとは呼べません。
Zapier系の連携プラットフォーム は、別の問題を解いています。決定論的なトリガーから決定論的なアクションへの配線です。エージェントはそのようには動きません。エージェントは思考の途中で、次のステップはSnowflakeに問い合わせて、それからLinearのチケットを書くことだと判断します。クレデンシャル、スコープ付きのHTTPクライアント、監査証跡が、事前に用意されたレシピとしてではなく、まさにその瞬間に必要なのです。
そこで私たちは地味なものを作りました。各エントリが認証メタデータを持つ連携機能のレジストリ、どのシークレットがサンドボックスに注入されるかを示す環境マッピング、許可されたホストのファイアウォール、OAuthやトークンの細かな違いを扱う小さなハンドラ。それがインフラです。
しかし、ストーリーの面白いところはインフラではありません。面白いのは、その上で何が起きたかです。
全員をコネクタ作者にしたスキル
新しいSaaSがバックログに登場するのは、平均して一日2回くらい。お客様からのリクエスト、チームメイトがZeroにできないことに気づいたケース、見込み客のスタックに私たちがまだ知らないツールが含まれているBDの会話など、出どころはさまざまです。
これら全部をエンジニアのキューに通していたら、週に一つしか出荷できないでしょう。私たちは一日一つ出荷しています。
その理由は、私たちが コネクタ作成スキル と呼ぶ社内ツールです。これは私たちがお客様にも出荷しているのと同じ形のZeroスキルですが、私たち自身のコードベースに向けて使っています。チームの誰かが「Notionコネクタを追加したい」と言うと、Zeroが手順を案内します。
- ユーザーシナリオから始める。 ユーザーはこのツールで実際に何を しよう としているのか？「データベースを問い合わせる」「ページを作る」「ワークスペース全体を検索する」など。スキルは、ファイルを一つ触る前に、具体的なユーザーストーリーを書くよう求めます。コネクタの目的は、エージェントの能力を可能にすることであり、APIを網羅的にラップすることではありません。
- 認証方式を見極める。 OAuth、APIトークン、または両方。スキルはそれぞれの方式が何を意味するかを知っています。OAuthなら、同意UIとリダイレクトの配線。APIトークンなら、組織ごとのシークレット注入と、ユーザーがトークンを取得する場所。作者はツールに合った方式を選びます。あとはそこから自然に決まります。
- エンドポイントをシナリオにマッピングする。 「REST API全体をラップする」のではありません。ユーザーストーリーを満たす、ほんの一握りのエンドポイントだけです。3つの厳選されたエンドポイントを持つコネクタは、エージェントが触りもしない40のエンドポイントを持つコネクタに勝ります。
- 12個のファイルをスキャフォールドする。 レジストリエントリ、ハンドラ、ファイアウォールパターン、プラットフォームアイコン、環境マッピングの配線、Zeroにコネクタの 使い方 を教えるエージェント側スキル。スキャフォールドはスキルが書き、意図は作者が書きます。
- 2つのPRを開く。 一つはコネクタフレームワーク、もう一つはスキルライブラリへ。両方ともエンジニアがレビューしますが、レビューは正しさのためであって、作者にフレームワークを教えるためではありません。
かつて組織知識を必要としたもの（どの認証方式、どのエンドポイント、どのリポジトリの どの12ファイル、ファイアウォールパターンが動的サブドメインとどう組み合わさるか）は、今やスキル自身が担っています。作者はユーザー共感を持ち込みます。スキルはスキャフォールディングを持ち込みます。
こうして、デザイナーや、BDのリードや、PMがコネクタを出荷することになります。彼らはユーザーが何を望んでいるかを知っています。残りはスキルが知っています。
ケーススタディ：昨日のSnowflake
昨日、AnthropicがSaaStrのステージで自社のGTMスタックを紹介しました。記録のシステムとしてSalesforce、エンリッチメントにClay、ルーティングにLeanData、通話にGong、チケットにJira、サポートにIntercom（Fin）、契約にIronclad、データウェアハウスにSnowflake。[トークへのリンク]
私たちのエンジニアの一人がそのスライドのスクリーンショットを撮り、Zeroに一つの質問とともに投げ込みました。「このうち、コネクタが欠けているのはどれ？」
そのあと起きたことの実際のタイムラインです。すべてPDT。
16:59。 スクリーンショットが到着。Zeroはコネクタカタログと照合：10個のうち7個はすでに存在（Salesforce、Gong、Jira、Intercom、Ironclad、Gmail、Slack）。3つが欠けている（Clay、LeanData、Snowflake） で、データウェアハウスはGTMスタックの土台だから、Snowflakeが最も価値が高いとフラグ付け。17:00に返信が届く。
17:01。 フォローアップ：「このうちAPIトークン型のコネクタにできるのはどれ？」 Zeroは認証ドキュメントを引っ張る：ClayはパーソナルAPIキーを持ち、Snowflakeは最近Programmatic Access Tokensを出した、LeanDataはOAuthのみでSalesforceに紐づいている。 17:02の結論：まずSnowflake（価値が最も高く、認証が最もきれい）、次にClay。
17:04。 エンジニアが「ゴー」と言う。コネクタ作成スキルが引き継ぐ。17:07までにClayをスコープから外し（公開されている表面はテーブルごとのWebhookだけで、本物のコネクタを作る対象がない）、Snowflakeの形を確定：SNOWFLAKE_PATシークレット ＋ SNOWFLAKE_ACCOUNT変数、Snowflake REST APIとSQL API v2に対するBearer認証、Zendeskを参考にした動的サブドメインのファイアウォールパターン。
17:35。 同じ分のうちに、両方のPRがオープン：
vm0-skills#176：エージェント側スキル。Snowflake SQLの書き方、結果の整形、一時的なエラーでのリトライ。vm0#13356：コネクタ本体。レジストリエントリ、PATハンドラ、ファイアウォールジェネレータ、プラットフォームアイコン、環境マッピングの配線。
18:22。 スキルPRマージ。
18:42。 コネクタPRマージ。
18:52。 リリースPRが自動オープン。
23:18。 web@v12.369.0とリリーストレインの残りが本番デプロイ。Snowflakeはすべての組織で稼働。
6時間19分 、「Anthropicのスタックのスクリーンショット」から「Zeroがあなたのウェアハウスにクエリを投げられる」まで。エンジニア一人。一つの会話。「コネクタチーム」への引き継ぎはゼロ。
このスループットは、エンジニアが速いからではありません。コネクタ作成スキルが、かつて組織知識を必要としていた部分を引き受けた からです：どの認証方式を選ぶか、どのエンドポイントがユーザーシナリオにマッピングされるか、どの12のファイルがどの2つのリポジトリに着地する必要があるか、ファイアウォールパターンが動的サブドメインとどう組み合わさるか。作者は 意図 を書きました。スキルが スキャフォールディング を書きました。本番が残りをやりました。
これが、フレームワークが私たちにもたらすものです。スピードだけではなく（スピードも本物ですが）、誰が仕事を引き受けられるか、です。Snowflakeの作者はたまたまエンジニアでした。エンジニアである必要はなかった。
なぜAPIトークンがファーストクラスシチズンなのか
脚注として引き出す価値のある話。意図的な設計判断で、人を驚かせるからです。
ほとんどのエージェントプラットフォームは、OAuthを唯一の正しい認証として扱い、APIトークンはレガシーツールのフォールバックとして扱います。私たちは逆をやっています。APIトークンは、私たちのコネクタモデルにおけるファーストクラスシチズンで、同じ同意UI、同じ組織ごとの保管、同じ監査証跡、同じファイアウォール強制が適用されます。
理由は2つあります。
一つは APIトークン認証はTime-to-First-Useが短い ということです。Snowflakeが最近Programmatic Access Tokensを出したのは、まさにこの理由のためです：長寿命でスコープ可能で取り消し可能なクレデンシャルで、OAuthのダンスを必要としません。PATを持ったユーザーは、Zero上で1分以内に生産的になれます。OAuthフローは、きれいなものでも、より時間がかかり、ユーザーに多くを要求します。
もう一つは OAuthが常に使えるわけではない ということです。一部のエンタープライズツールはOAuthを単に提供していないか、エンタープライズSKUの後ろにゲートされたOAuthしか提供していません。APIトークンを（フォールバックではなく）対等な存在として扱うことで、こうしたツールを「近日対応予定」の墓場に置き去りにせず、きちんとサポートできます。
昨日出荷されたSnowflakeコネクタはAPIトークンです。お客様のメールスレッドを扱うGmailコネクタはOAuthです。どちらも同じフレームワーク、同じスキル、同じレビューを通ります。作者はツールに合った方式を選び、フレームワークがどちらでも安価に作れるようにしてくれます。
180個ほどの連携機能が本当に解き放つもの
数字そのものはポイントではありません。ポイントは、この密度になると、エージェントは呼び出すツールであることをやめ、住み込む環境になり始める ということです。
ZeroがCRM と データウェアハウス と サポート受信箱 と デザインツール と リポジトリ、すべてのコネクタを持っていると、単一連携のエージェントにはできないことができます。Snowflakeのクエリを引っ張り、オープンなLinearチケットと突き合わせ、カスタマーサクセスチームがいるSlackチャネルに要約を投稿できます。Gongの通話を読み、見込み客が尋ねた機能を見つけ、ロードマップにあるかを確認し、フォローアップメールを書く、すべて一手で。
新しいコネクタは線形に価値を加えるのではありません。組み合わせとして価値を加えます。180番目のコネクタは1番目よりも価値があります。なぜなら、それより前の179とコンポーズするからです。
それがフレームワークの賭けです。そしてスキルの賭けは、コンパウンドのスピードは、チームの何人が積み上げに参加してよいかにかかっている ということです。
次は何か
私たちは、コネクタ作成スキルをお客様にも開くことに取り組んでいます。あなたがチームでZeroを動かしていて、連携が必要な社内ツール（請求システム、ウェアハウス、自社の管理パネル）があるなら、昨日Snowflakeを出荷したのと同じワークフローが、あなたが自分の連携を出荷するためのワークフローになります。同じスキャフォールディング、同じ認証モデル、同じファイアウォール、同じ監査証跡。違うのは作者だけ。
興味があれば、お話しさせてください。
