多くの連携ページはロゴの数を競います。実際に稼働しているものを数え、その違いをお見せします。
「200のインテグレーションに対応」は、ほぼ何でも意味しえますし、たいていそうです。Tajoはこの主張を、厳密で検証可能な定義を持つ段階に分けます。カタログに載っているだけのもの、管理されたランタイムに登録済みのもの、同期にデータを読み込めるもの、同期や送信の書き込み先になれるものです。以下の数字はプラットフォームの現在の正直な状態です。数字が変われば、このページも変わります。
| 階層 | 現在 | 実際の意味 |
|---|---|---|
| 書き込み先 Brevo、Shopify、HubSpot、Salesforce、Pipedrive、Zoho CRM。 | 6 | 同期や送信の書き込み先として使われる、実際の書き込みアクションを持つコネクタです。すべての書き込みはランタイムのゲートを通ります。入力に紐づく一度限りの承認と予算上限です。 |
| 同期に読み込める レコードを同期に読み込める登録済みインテグレーション。 | 47 | 同期のソースです。Webhookの作成、チャットへの返信、読み取りだけを行うPOSTエンドポイントといったアクションを持つものもありますが、それらは書き込みとして数えません。 |
| 登録済み 実運用ランタイムに登録されているインテグレーション。 | 55 | 認証済みで、ガバナンスの下で動いています。登録だけではレコードは動きません。それぞれに何ができるかは、上の2つの段階が示します。 |
| 発見用コーパス ベンダーが公開しているAPI仕様に含まれる操作で、エージェントはここからドラフトを作成します。 | 27 ベンダー / 5,937 オペレーション | 接続ではなく、下書きのための素材です。お使いのスタックにこれらのベンダーのいずれかが含まれている場合、エージェントはエンドポイントを推測するのではなく、実際にドキュメント化された API オペレーションを参照して下書きを作成します。 |
| カタログ掲載 連携カタログに掲載されているエントリーです。 | 200 | ロードマップの全体像であり、識別・スコープ定義済みのシステム群です。カタログに掲載されているだけでは、データは一切動きません。その点を誤解させるようなことはしません。 |
階層は、最も実証されているものから最も広範なものへと並んでいます。すべての連携は、どの階層であっても同じガバナンスのもとで実行されます。ダイジェストに紐づく承認、フェイルクローズ方式の同意ルール、予算上限、改ざん検知可能な監査ログです。詳しくは 仕組みのページ で、全体のライフサイクルをご確認ください。
段階が上がるごとに、基準は厳密に高くなります。システムを一覧に載せるのは簡単です。管理されたランタイムに登録するには作業が要ります。そのレコードを同期に読み込むにはさらに作業が要り、書き込み先として書き込むには最も多くの作業が要ります。この段階表は、その作業がどこまで進んでいるかを正確に示します。
コネクタを数えるのは、同期や送信の書き込み先として使われる実際の書き込みアクションを持つ場合だけです。Webhookの作成、チャットでの返信、読み取りだけを行うPOSTエンドポイントの呼び出しは数えません。そのため、条件を満たすのは55件中6件です。現時点で「認定」のラベルが付いたインテグレーションはありません。
優先順位を決めるのは、アーリーアクセスパートナーです。お使いのスタックでコーパス内のベンダーの接続が必要な場合や、接続済みの連携を書き込み対応にする必要がある場合、それはまさに Tajo のエージェントとチームが存在する理由である、フォワード・デプロイド型の作業そのものです。
その代わりとなるのは、業界でよくあるやり方だからです。古くなったカタログの1件と、実戦で鍛えられた連携先が、プロジェクトがその違いに左右される瞬間まで見分けがつかない、ロゴの壁です。Tajo の前提はすべて検証可能性にあります。確認できる承認、実行内容を証明する実行ログ、こっそり編集できない監査証跡です。数字を水増しした準備状況ページは、そうした製品の入り口としては不自然です。このページは、そうしていません。
次に何を登録し、書き込みに対応させるかは、早期アクセスパートナーが決めます。接続が必要なシステムを教えてください。一緒に実現に向けて構築します。