多くの連携ページはロゴの数を競います。実際に稼働しているものを数え、その違いをお見せします。
「199件の連携に対応」という表現は、ほぼ何を意味していてもおかしくありません。実際、たいていはそうです。Tajo はこの主張を、厳密で検証可能な定義に基づいた階層に分けています。単にカタログに掲載されているだけのもの、ガバナンスの効いたランタイムに接続されているもの、安全に書き込みができるもの、そしてエンドツーエンドで認定済みのもの、という区分です。以下の数字は、プラットフォームの現在の、偽りのない状態を示しています。数字が変われば、このページも変わります。
| 階層 | 現在 | 実際の意味 |
|---|---|---|
| 認定済み連携先 Brevo（型付き連携先7件）。HubSpot は、次に控える2つ目の連携先です。 | 1 (+1 in progress) | ガバナンスの効いたライフサイクル全体が、型付き書き込み先、承認ゲート、アテステーション（実行証明）、監査に至るまでエンドツーエンドで実証されています。今日から本番環境に対して公開し、実行できる連携です。 |
| 書き込み対応 書き込みアクションを1つ以上備えたランタイム連携です。 | ~19 | ランタイムのゲートを通じて書き込みを実行できます。1回限りで入力内容に紐づく承認や予算上限も含まれますが、すべての連携先で認定済みラベルを獲得しているわけではまだありません。 |
| ランタイム接続済み 本番のランタイムに接続されている連携です。 | 53 | 認証済みで、ガバナンスのもとで実行されています。多くは読み取り中心で、発見・サンプリング・下書き作成に適しています。書き込みは、ゲートを通過し次第、順次追加されます。 |
| 発見用コーパス エージェントが下書きの参照元とする、ドキュメント化された API オペレーションです。 | 27 ベンダー / 10,345 オペレーション | 接続ではなく、下書きのための素材です。お使いのスタックにこれらのベンダーのいずれかが含まれている場合、エージェントはエンドポイントを推測するのではなく、実際にドキュメント化された API オペレーションを参照して下書きを作成します。 |
| カタログ掲載 連携カタログに掲載されているエントリーです。 | 199 | ロードマップの全体像であり、識別・スコープ定義済みのシステム群です。カタログに掲載されているだけでは、データは一切動きません。その点を誤解させるようなことはしません。 |
階層は、最も実証されているものから最も広範なものへと並んでいます。すべての連携は、どの階層であっても同じガバナンスのもとで実行されます。ダイジェストに紐づく承認、フェイルクローズ方式の同意ルール、予算上限、改ざん検知可能な監査ログです。詳しくは 仕組みのページ で、全体のライフサイクルをご確認ください。
各階層は、厳密により高いハードルになっています。システムを一覧に載せることは簡単です。ガバナンスの効いたランタイムに接続するには手間がかかります。安全な書き込みを実証するには、さらに手間がかかります。そして、すべての連携先をエンドツーエンドで認定することが、最も手間のかかる作業です。この段階構造は、その作業が今どこまで進んでいるかを正確に示しています。
認定済みの連携先とは、すべての型付き連携先が、下書き、検証、ダイジェストに紐づく承認、証明付き実行、監査という全ライフサイクルを経て検証済みであることを意味します。カタログ全体にラベルを一律に貼るのではなく、1つの連携先ずつ、きちんと認定していきます。
優先順位を決めるのは、アーリーアクセスパートナーです。お使いのスタックでコーパス内のベンダーの接続が必要な場合や、接続済みの連携を書き込み対応にする必要がある場合、それはまさに Tajo のエージェントとチームが存在する理由である、フォワード・デプロイド型の作業そのものです。
その代わりとなるのは、業界でよくあるやり方だからです。古くなったカタログの1件と、実戦で鍛えられた連携先が、プロジェクトがその違いに左右される瞬間まで見分けがつかない、ロゴの壁です。Tajo の前提はすべて検証可能性にあります。確認できる承認、実行内容を証明する実行ログ、こっそり編集できない監査証跡です。数字を水増しした準備状況ページは、そうした製品の入り口としては不自然です。このページは、そうしていません。
次に接続・認定する対象を決めるのは、アーリーアクセスパートナーです。接続が必要なシステムをお知らせいただければ、一緒に実現に向けて構築を進めます。