SlackのAIに話しかけるだけで、Passworkのデータ連携を 構築・実行・監視・調査 できる ── これを実現しているのが「Passwork MCP」です。本稿は、その裏側を技術的に解説します。MCP（Model Context Protocol）とは何か、なぜClaude TagからPassworkを制御できるのか、Passwork MCPが Tools / Resources として何を実装しているのかまでを、実際のSlack使用例とともに掘り下げます。

まず、登場人物と接続関係を整理します。Slackで「あの連携、いま動かして」と打つと、内部では次の3層が連携して動いています。

ポイントは、Claude TagとPassworkは「MCP」という共通の言語で会話している ことです。Claude TagはPassworkの内部実装を一切知りません。知っているのは、MCPで公開された「ツールの一覧」と「その呼び出し方」だけ。逆にPassworkも、相手がClaude Tagであることに依存しません。MCPに準拠したクライアントなら、何が来ても同じように応答します。
　
この 疎結合 こそが、本稿で読み解く設計の出発点です。順に分解していきます。

MCP（Model Context Protocol） は、Anthropicが提唱したオープンな標準プロトコルです。ひとことで言えば、「LLMアプリケーションが、外部のツールやデータに接続するための共通規格」 です。よく 「AIにとってのUSB-C」 と例えられます。
　
従来、LLMに外部機能をつなぐには、アプリごと・モデルごとに独自の連携を書く必要がありました。M個のAIアプリと、N個のツールがあれば、M × N 通りの実装が必要になる。MCPは、この組み合わせ爆発を M + N に畳む規格です。ツール提供側は MCPサーバ を一つ作れば、MCP対応のどのAIからも使われる。

3つの役割：Host / Client / Server

MCPは、次の3者で構成されます。

3つのプリミティブ：Tools / Resources / Prompts

MCPサーバが公開できる能力は、大きく3種類に分かれます。この区別が、後半の設計理解の鍵になります。

MCPは「賢いAI」を作る技術ではありません。AIと外部システムの”つなぎ方”を標準化する ものです。だからこそ、Passworkは一度MCPサーバを実装すれば、Claude Tagでも、デスクトップのClaudeでも、他のMCP対応クライアントでも、同じように制御できる ようになります。

Claude Tag は、Slackに常駐するAIです。技術的に言えば、Claude Tagは MCPホスト（かつクライアント） として振る舞います。つまり、外部のMCPサーバに接続し、そのツールを呼べる側です。
　
Passworkは、エージェントごとに固有の リモートMCPエンドポイント（URL） を払い出します。Claude Tag側にそのURLを登録すると、Claude Tagは接続時に tools/list を投げ、Passworkが「いま使えるツールの一覧」を返します。以降、ユーザーがSlackで自然言語を打つたびに、Claude Tagは どのツールを・どんな引数で呼ぶべきか を判断し、tools/call を発行します。

# ① Claude Tag が接続時に使えるツールを問い合わせる
→ tools/list
← { tools: [ "list_flows", "execute_flow", "plan_flow",
           "compile_flow", "list_job_runs", ... ] }

# ② ユーザー：「あの売上連携、いま動かして」
#    Claude Tag が意図を解釈し、ツールを呼ぶ
→ tools/call { name: "execute_flow", arguments: { flow_id: "123" } }
← { status: "queued", job_run_id: "28283022179" }

ここまでの仕組みが、実際のSlack会話でどう動くか。プレスリリースで紹介した5つの使用例を、裏で呼ばれるMCPツール とともに見ていきます。
　

• ①既存フローの実行を開始

登録済みのデータ連携を、その場で起動。管理画面を開く必要はありません。
　
「あの連携、いま動かして」

• ②実行履歴の期間指定確認

期間を指定して、実行履歴・成否・処理件数を会話で確認。問題の早期発見と原因追跡がスレッド上で完結します。
　
「この1週間でフローの実行にエラーや遅延はあった？」

• ③新規フローの構築

意図を伝えるだけで、AIが要件を整理し、サーバが検証済みの決定論連携へコンパイルします（第05章の流れ）。
　
「受注したSalesforceの商談をBoardの商談に連携したい」

• ④コネクタの管理

接続設定の更新、権限の変更、利用状況の確認までSlackから。どの連携がどのコネクタを使っているかの逆引きも会話で行えます。
　
「このコネクタ、いまどのフローで使われてる？」

• ⑤認証情報を使った、各種サービスのデータ調査

既存の接続情報をそのまま使い、調査クエリを即実行。連携を組む前に、対象データの中身を会話で確かめられます。ナレッジResourceを参照して項目名を解決します。
　
「Boardを元にして、今年新規に取引が始まった会社の一覧は？」

注目してほしいのは、ユーザーは一度もツール名を口にしていない ことです。「Boardを元にして、今年新規に取引が始まった会社」という業務の言葉を、Claude Tagがツール呼び出しの連鎖に翻訳し、Passworkがナレッジを足場に「新規に取引が始まった」を実際の項目・条件へ セマンティックに解釈 する。これが、MCPサーバ側のナレッジとセマンティック解釈が効く場面です。

「会話でデータ連携を動かせる」と聞くと、安全性が気になります。Passwork MCPは、技術的に2つの観点で担保しています。
　

① 決定論：AIを”実行時”に呼ばない

AIが決定するのはどのフローを実行するかであって、実行される実体はPassworkの決定論的なフローです。実行される処理自体にはAI推論を挟みません。これにより、
　

• 同じフローは 何度実行しても同じ結果（再現性）
• 実行ごとの API課金・レイテンシが乗らない（コスト安定）
• 実行履歴を後から監査できる（説明可能性）

　
「毎回AIに丸投げ」だと失われるこれらの性質が、入口と出口を分けることで保たれます。
　

② 権限統制：許可されたコネクタとtoolsのみが実行される

許可された コネクタ／tools のみ が実行させる権限制御を行います。仮にクライアントから tools/call が来ても、実行の手前でfail-close（許可が無ければ拒否）で評価して、処理を終了させます。
　
権限は 「クライアントを信用しない」前提 で組みます。クライアント側の絞り込みは利便性（不要なツールを見せない）であり、安全性の最終担保は サーバ側 に置く。MCPは疎結合ゆえ、どんなクライアントが繋いでくるか分からない ── だからこそ、サーバが自分で守る必要があります。

ここまでを一枚に畳むと、Passwork MCPの正体は 「業務の言葉」と「検証済みの決定論連携」をつなぐ翻訳層 です。

「会話でデータ連携を動かす」という体験の裏には、こうした地味で堅い設計があります。派手なのは表側のSlackですが、価値を生んでいるのは “AIの揺らぎを決定論に変換する境界をどこに引くか” という設計判断のほうです。Praztoは、この境界設計とその運用を、お客様の業務に合わせて伴走しています。