Agentic Fabriq：機能、MCP ゲートウェイ、料金（2026年）

Agentic Fabriq は AI エージェント向けの ID・権限管理プラットフォームです。エージェントとツールの間に入り、各リクエストにユーザー ID を結び付け、アクセス方針を適用し、認証情報を管理して実行履歴を残します。

エージェントフレームワークとは役割が異なります。推論方法やタスクを決めるのではなく、操作を選んだ後に何へアクセスし、何を実行できるかを制御します。

2025年設立で、Y Combinator の2026年冬期バッチに参加しました。本稿は2026年9月時点の仕組み、MCP の位置付け、費用、導入に適した場面を扱います。

どのような問題を解決するのか

顧客記録を読み、Stripe で注文を確認し、Gmail で返信するサポートエージェントを考えてみてください。ツールを呼べるだけでは、次の点が不明です。

• リクエストを送ったエージェントはどれか。
• 誰の代理として動いているか。
• そのユーザーには、対象の操作を行う権限があるか。
• ユーザーの OAuth トークンはどこに保存されるか。
• 再デプロイせずにアクセスを取り消せるか。
• 許可、拒否、承認待ちの呼び出しを確実に追跡できるか。

共有サービスアカウントでは、全ユーザーが同じ権限を持ち、認証情報がアプリの基盤に残り、操作の主体も特定しにくくなります。OAuth ライブラリはログインを支援しますが、エージェント単位の方針や統一監査までは提供しません。

公式ドキュメントによれば、Fabriq はリクエストをエージェントと実行ユーザーの両方に関連付け、最新の方針で組み合わせを検査してからツールへ転送します。

動作の流れ

1. アプリまたはエージェントを登録。 ID と、要求できるツール権限の上限を定義します。
2. 各ユーザーのアカウントを接続。 Gmail、Slack、GitHub などのホスト型 OAuth 同意画面を経て、認証情報を保管庫へ保存します。
3. 短期間有効なユーザー別トークンを発行。 バックエンドは自社アプリのユーザー ID を使い、Fabriq のアプリシークレットはサーバー側に置きます。
4. ゲートウェイ経由で呼び出し。 Python SDK または単一の MCP エンドポイントで、そのユーザーが使えるツールだけを発見・実行します。
5. 検査して記録。 操作を確認し、サーバー側でプロバイダーの認証情報を付与して、許可された呼び出しを転送し、監査証跡へ記録します。

重要なのは5番目の境界です。システムプロンプトは方針への従属を指示できますが、指示自体はセキュリティ制御ではありません。Fabriq はモデルの外側、ツール呼び出しの境界で権限を判定します。

主な機能

エージェントとユーザーの ID

有効な権限は、エージェントに与えた権限と、ユーザーが元から持つ権限の共通部分です。エージェントが返金を許可されていても、利用者に返金権限がなければ拒否されます。

社内共有エージェントでは、組織、チーム、メンバー、個別操作ごとに権限を変えられます。同じデプロイでも、ある社員には読み取り専用、別の社員には限定的な書き込みを認められます。

統制された MCP ゲートウェイ

接続済みツールを、単一の Model Context Protocol エンドポイントから提供します。現在のユーザーに応じて一覧を生成するため、禁止されたツールは選択後に拒否するだけでなく、一覧から隠せます。

連携カタログには Google Workspace、Microsoft 365、メッセージング、開発ツール、CRM、サポート、データ分野が含まれます。OpenAPI サービス、既存の MCP サーバー、保護された Postgres 接続も追加できます。

認証情報の保管と OAuth 仲介

ユーザーが自分のアカウントを認可し、アクセストークンと更新トークンは Fabriq の保管庫に残ります。転送時に認証情報を付与するため、エージェントへ返したり、製品のデータベースに保存したりする必要はありません。更新と取り消しも処理します。

顧客向け製品では、顧客それぞれの Gmail や Slack を接続でき、開発者は各プロバイダーのトークン保管機構を個別に維持せずに済みます。

方針の適用と承認

原則拒否の権限付与を使い、個別操作まで制御できます。毎回方針を読むため、変更は再デプロイなしで次の呼び出しから反映されます。Enterprise では機密性の高い操作を承認フローへ送れます。

監査証跡

実行ユーザー、エージェント、ツール、操作、判定を記録できます。複数のプロバイダーログをつなぎ合わせずに、横断的な履歴を確認できます。

監査ログだけで法令順守が成立するわけではありませんが、事故調査や自社の統制に必要な主体の特定と証拠を得られます。

MCP サーバーなのか

MCP エンドポイントは提供します。ただし、それだけでは主な価値を説明できません。

MCP 対応ランタイムと多数の下流ツールの間に置け、既存の MCP サーバーも同じ ID・方針の境界に収められます。MCP は接続方式であり、製品の中心は統制です。

開発者向けと企業向けの使い方

顧客の代理として動く製品

開発者モデルでは、アプリが Fabriq のアプリ ID とシークレットを保持します。顧客は製品内で外部アカウントを接続し、渡されたユーザー ID ごとに呼び出しが制限されます。顧客自身の Fabriq アカウントは不要です。

メール、予定表、文書、メッセージなどの SaaS に、顧客の認可でアクセスする AI 製品に適します。

社員の代理として動くエージェント

企業モデルでは社員が Fabriq ワークスペースでアカウントを接続します。管理者は共有エージェントの権限、組織の ID プロバイダー連携、集中監査を管理します。

社内アシスタント、サポート・運用エージェント、利用社員のアクセス境界を継承すべきコーディングエージェントに適します。

料金

2026年9月11日時点の開発者向け従量プランです。

有料開発者プランの超過料金は10,000回あたり $2 とされています。下流ツールの実行以外に、認証、ツールアクセス、認証情報の要求も計上される場合があります。タスク全体をモデル化し、公式料金ページで最新条件を確認してください。

導入に適した場面

• 多数のユーザーの代理として動く。
• OAuth を使う業務ツールをユーザーが接続する。
• 共有 API キーや広いサービスアカウント権限を避けたい。
• エージェント、ユーザー、操作別に権限を変える。
• 集中的な主体特定、取り消し、監査が必要。
• 複数ランタイムで同じ統制済み連携を使う。

公開 API のみを呼ぶ試作品や、厳しく限定した単一のアプリ所有資格情報だけを使う場合は不要かもしれません。編成、評価、プロンプト対策、重大な判断の人手確認を置き換えるものでもありません。

導入前の評価項目

ツール呼び出しの重要経路に入るので、ID 基盤として検討します。

1. 接続範囲： 必要な操作と権限範囲を実際に提供しているか。
2. 方針モデル： リソース境界や承認条件を必要な精度で表現できるか。
3. 障害時の動作： ゲートウェイ、ID 基盤、下流サービスが停止したらどうなるか。
4. 認証情報・データ要件： マネージドクラウドで安全性とデータ所在要件を満たすか、カスタムの自社運用が必要か。
5. 費用： ユーザーのタスク全体で何回計上されるか。
6. 可観測性： 事故対応と統制に必要な記録を出力できるか。

まとめ

多人数で使う本番システムでは、エージェントに実際の操作能力を与えつつ、代理する本人を超える権限を渡さないことが課題になります。

Fabriq の価値は、モデルを賢くすることより、生の認証情報やプロンプト頼みの権限検査を避けて実際のツールを使わせる点にあります。ユーザー別 ID、統制された MCP、認証情報の仲介、集中監査が必要なら検討対象です。

A

Agentic Fabriq

管理された MCP ゲートウェイによる AI エージェントの ID と権限制御