サービス知識ベースワールドモデル · 自己修復

あらゆるサービス連携を、
ハードコードではなく発見する。

SKBは外部サービスの権威あるレジストリです — 認証設定、APIケイパビリティ、その両方に対する意味検索を、必要に応じて新しいサービスを学習する自律型発見エンジンが支えます。設計原則は無制限のサービス規模。何も事前設定されておらず、すべてが利用可能です。

ドキュメントを読む
課題

あらゆる連携プラットフォームは、いずれ保守負担になります。

プロバイダーごとに異なるOAuthの流儀、実際のAPIから乖離しないケイパビリティスキーマ、エージェントが関数名を暗記するのではなく必要なものを言葉で伝えられる意味マッチング、そして誰もコネクタを事前に作っていないサービスのための発見パイプラインが必要です。これを手作業で構築すれば、新しいサービス一つひとつが独立したスプリントになります。SKBはこの問題全体を一つのサービスとして引き受けます。何も事前設定されておらず、無制限のサービス規模は成長目標ではなく設計原則です。

サービスレジストリ

プラットフォームが把握しているすべての外部サービスに関する権威ある記録 — 認証設定、ケイパビリティスキーマ、その両方への意味検索を一箇所に集約します。

意味ベースのケイパビリティ検索

エージェントが「チームチャットに投稿する」のように必要なものを自然言語で説明すると、SKBは正確な関数名ではなくスコアとドメインに基づいて一致するケイパビリティを返します。

自律的な発見

SKBがまだ見たことのないサービスをリクエストしても失敗しません — 発見エンジンがプロバイダーの公開ドキュメントを読み、その場で学習します。

2段階抽出

ケイパビリティと認証要件はそれぞれ独立した2回のパスで抽出されるため、プロバイダーのドキュメントを部分的にしか読めなかった場合でも、中途半端なケイパビリティが生まれることはありません。

認証優先の解決

ケイパビリティの詳細を抽出する前に認証が解決されます — 認証方法がわかるまで、そのサービスの他の部分は一切使用できません。

検証キュー

自動発見されたサービスは、本番でエージェントが呼び出せるようになる前に管理者レビューのキューに入ります — 発見は自律的でも、信頼は自動ではありません。

ドメインタグ

ケイパビリティはドメイン単位でタグ付けされるため、プレイブックは「Notionを検索」ではなく「ドキュメントストアを検索」を参照します。プロバイダーを入れ替えてもプレイブックは動き続けます。

一度学習すれば、ずっと使える

新しく発見されたサービスはレジストリに書き込まれ、再発見の必要は二度とありません — カタログは増え続けるだけで、設計上の優先事項は速さではなく信頼性です。

発見の仕組み

未知のサービスが、人の手を介さずに登録済みケイパビリティになるまで。

発見ループ

01

問い合わせエージェントが、あるサービスへの到達方法をSKBが知っているかを尋ねます。

02

未検出 → 発見知らない場合、リクエストを失敗させる代わりに発見エンジンが起動します。

03

識別対象サービスとその連携面が公開ドキュメントから識別されます。

04

2段階抽出ケイパビリティと認証要件がそれぞれ独立した2回のパスで抽出されます。

05

認証優先ケイパビリティの詳細より先に認証が解決されます — それがなければ他の何も機能しないからです。

06

登録新しく学習したサービスがレジストリに書き込まれます。

07

永続的な学習一度学習すれば再発見の必要はありません — 速さより信頼性が設計上の優先事項です。

APIサーフェス

参照・検索・登録 — 3つの動詞で成り立つ全表面。

GET/api/services既知のサービス一覧を取得(ページネーション、ドメインでの絞り込み対応)
GET/api/services/:id_or_slugサービス詳細 — 認証設定、ケイパビリティスキーマ、発見ステータス
POST/api/capabilities/search意味検索:意図を渡すと、スコア順のケイパビリティ候補が返る
POST/api/services/lookupサービス名で検索 — SKBがまだ確認していないサービスの場合、自動的に発見(ディスカバリー)がトリガーされる
GET/api/services/:id_or_slug/capabilities特定サービスに登録されたケイパビリティ一覧を取得
POST/api/admin/services/:id/verify管理者用:発見されたサービスを本番で信頼する前に承認
GET/api/categoriesプロバイダー変更に強いプレイブックのためのサービスカテゴリ一覧を取得
保証事項

白紙の状態でも信頼できるように設計されています。

無制限のサービス規模何も事前設定されていません — カタログはロードマップではなく発見によって成長します。

認証が最初に解決される認証要件が抽出・検証されるまで、いかなるケイパビリティも使用できません。

信頼される前に人による検証自動発見されたサービスは、本番でエージェントが呼び出せるようになる前に管理者レビューのキューに入ります。

ツール名ではなくドメインタグプレイブックは「Notionを検索」ではなく「ドキュメントストアを検索」に紐付くため、プロバイダーを変更してもプレイブックが壊れることはありません。

一度学習すればずっと利用可能登録済みサービスは再発見の必要がありません — レジストリは増え続けるだけです。

テナント分離各組織の接続済みサービスと認証情報はその組織の範囲内にとどまり、テナント間で共有されることは決してありません。

実践例

発見・マッチング・分離が実際にどう動くか。

未知のサービス

エージェントがSKBが一度も索引化したことのないCRM連携を要求します。発見エンジンがベンダーの公開APIドキュメントを読み、認証とケイパビリティを抽出して検証キューに登録します — エンジニアの手は一切介在しません。

意味マッチング

「チームチャットに第3四半期の数字を投稿して」は、teams.post_message(0.87)よりslack.send_message(0.93)に一致します — エージェントはSlackの関数名を知る必要が一切ありませんでした。

プロバイダー変更

「ドキュメントストアを検索」を基準に作られたプレイブックは、組織がNotionからConfluenceに切り替えても変更なしで動き続けます — 要となるのはツール名ではなくドメインタグです。

認証優先ゲート

発見エンジンがサービスのケイパビリティは見つけたものの、OAuthフローを解決できません。認証が確認されるまでそのサービスは未登録のままとなり、中途半端に動くことはありません。

MCPと並んで

特定の社内ツール用MCPサーバーが、SKB自身のコネクタと並んで存在します — SKBはコミュニティがすでに提供しているものの上に、意味レイヤーとドメインタグを追加します。

結果を求めるだけでいい。サービスを見つけるのはSKBの仕事です。

無制限のサービス規模を、必要なときに発見。何も事前設定されておらず、すべてが利用可能です。