カタログは100以上のサービスをカバーしますが、社内ツールや地域限定SaaSなど、カタログに載っていないツールはどのチームにもあります。カスタムコネクタはそのギャップを埋めます。
資格情報(APIキーまたはOAuth資格情報)を登録し、Zeroにそのサービスの呼び出し方を伝えます。あとはZeroが標準コネクタとまったく同じように扱います。同じ監査ログ、同じブローカードアクセスプロキシ、同じセンシティブアクションのゲートです。
2つのタイプ
サービスに合わせて選びましょう。
- APIキー — ヘッダーに静的トークンで認証するあらゆるサービスに対応します。最もシンプルで早い方法です。キーを貼り付け、コネクタに名前を付け、Zeroにベース URL を指定するだけ。社内APIや多くのSaaSツールはこの方式です。
- OAuth 2.0 — OAuthでユーザーごとにトークンを発行するサービス向けです。クライアントIDとシークレットを提供し、Zeroが要求できるスコープを設定すると、必要に応じてZeroがユーザーごとにOAuthフローを実行します。
どちらにするか迷ったら、対象サービスのAPIドキュメントを確認してください。「APIキー」や「個人アクセストークン」とあればタイプ1、「OAuth」や「クライアント資格情報」とあればタイプ2にあたることが多いです。
APIキー型コネクタを設定する
- ワークスペースでコネクタページを開きます。
- カスタムコネクタを追加 → APIキーをクリックします。
- 以下を入力します。
- 名前。 Zeroがプロンプトで認識できる名称にします。例:
internal-billing-api、acme-crm。 - ベースURL。 APIのルートです。例:
https://api.internal.acme.com。 - 認証ヘッダー。 通常は
Authorization: Bearer YOUR_TOKENまたはX-API-Key: YOUR_TOKEN。サービスの仕様に合わせてください。 - APIキー。 資格情報を貼り付けます。暗号化保存され、保存後は再表示されません。
- 許可パス(任意)。 Zeroを特定エンドポイントに限定します。例:
/v1/invoices/*。影響範囲を狭められます。
- 名前。 Zeroがプロンプトで認識できる名称にします。例:
- 保存してから接続テストをクリックします。Zeroがベース URL に
GET /を投げて結果を返します(パスは指定可能)。
OAuth 2.0コネクタを設定する
少し手間が増えますが、ユーザーごとの認可が必要なサービスでは有用です。
- 対象サービスにOAuthアプリケーションを登録します。クライアントIDとクライアントシークレットを取得します。リダイレクトURIは、カスタムコネクタ追加フォームでVM0が表示するものに設定します。
- VM0でカスタムコネクタを追加 → OAuth 2.0を選びます。
- 以下を入力します。
- 前述と同じく名前とベースURL
- 対象サービスのOAuthドキュメントから取得したAuthorization URLとToken URL
- クライアントIDとクライアントシークレット
- スコープ。 Zeroが要求できるスコープのリスト。ワークフローに必要な最小限にとどめます。
- 保存します。このコネクタを必要とする最初のセッションで、ユーザーごとのOAuthフローが走ります。
カスタムコネクタの使い方をZeroに教える
方法は2つ。あなたのワークフローに合うほうを選んでください。
インラインで説明する。 Zeroに依頼するときに、そのまま書き添えます。
「
internal-billing-apiコネクタで請求書#4422を取得して。そのPDFをops@acme.comにメール送信して。」
Zeroはコネクタの仕様を読み込み、呼び出すべきエンドポイントを判断します。これは、コネクタにOpenAPI形式のメタデータが付属している(多くのサービスでは自動検出、必要に応じて手動提供)ためです。
コネクタ名を参照するスキルを書く。 スキル本文に手順を記述します。説明文がリクエストに合致するとZeroが自動でスキルを読み込みます。繰り返し使うワークフローでは、毎回インラインで説明するよりこちらのほうがすっきりします。
pull-invoiceという名前のスキル。説明は「internal-billing-apiから請求書を取得し、PDFをメール送信する」。一度書いておけば、誰かが請求書を依頼するたびにZeroが呼び出します。
OpenAPI仕様とインラインスキーマ
Zeroは、利用可能なエンドポイント、メソッド、パラメータを把握しているとカスタムコネクタを最もうまく扱えます。情報の渡し方は3通りです。
- 自動検出。 サービスが
/openapi.jsonまたは/swagger.jsonを公開していれば、ZeroにそのURLを指定するだけです。 - 仕様のアップロード。 OpenAPI 3形式のYAML/JSONを貼り付けるかアップロードします。Zeroはこれを解析し、呼び出し作成時にツールチップ的なメタデータを提示します。
- インライン記述。 仕様のない社内ツール向けに、コネクタ本文に短いMarkdownの説明(エンドポイント、メソッド、サンプルペイロードなど)を書きます。粗い方法ですが機能します。
仕様がなくてもZeroは動きますが、パラメータの形状を多めに推測することになります。よく使うカスタムコネクタについては仕様を用意しておくと、すぐに元が取れます。
ワークスペース間での共有
カスタムコネクタはデフォルトでワークスペース単位です。同じ組織の2チームが、同じ社内API向けに別々のカスタムコネクタを保有することもできます。組織で1つの正準なセットアップを持ちたい場合は次のようにします。
- エンタープライズ組織レベルコネクタ。 エンタープライズプランで利用可能。組織レベルで一度設定すれば、傘下のすべてのワークスペースで表示されます。全員が使う社内API向けに推奨されます。
- コネクタパッケージ。 大規模組織では、社内プラットフォームチームがカスタムコネクタをバージョン管理されたパッケージとして公開できます。各ワークスペースはインストールし、更新を自動的に受け取れます。
セキュリティとレート制限
- 資格情報。 ワークスペース単位の鍵で暗号化保存。保存後は再表示されず、再入力のみ可能です。
- 呼び出しごとの監査。 カスタムコネクタ経由のすべてのリクエストは、メソッド、URL、ステータスコード、所要時間とともにセッションログに記録されます。
- レート制限。 対象サービス側で適用されます。Zeroは429レスポンスを指数バックオフで処理し、ワークスペース設定の上限まで再試行します。
- 許可リスト化されたパス。 任意設定で、特定URLパターンへの限定が可能です。鍵が必要以上の権限を持つ場合の影響範囲を抑えます。
- デフォルトは読み取り専用。 新規カスタムコネクタは読み取り専用としてマークされます。書き込みアクセスの付与はワークスペースごとに明示設定が必要です。
よくある落とし穴
- 広すぎるAPIキー。 サービスが対応していれば、個人の管理者キーを使い回すよりZero専用のスコープ付きキーを発行しましょう。ローテーションや監査がしやすくなります。
- スキーマの不足。 OpenAPI仕様もインラインの説明もないと、Zeroはパラメータ形状を推測します。単純なケースなら問題ありませんが、ネストしたオブジェクトでは破綻します。可能であれば仕様を渡しましょう。
- 未テストのベースURL。 設定後は必ず接続テストをクリックします。401や404はクリティカルなセッション中ではなくこの段階で出るほうがずっとよいものです。
- ローテーションの忘れ。 鍵は四半期ごとにローテーションするカレンダーリマインダーを設定しましょう。VM0側のローテーションはワンクリック。時間を取るのは対象サービス側のローテーションです。