1. はじめに

山根さん「小川くん、Difyディフィって知ってる？」
ボク「海賊王になるやつですかね」
山根さん「じゃあ調べてブログ書いてね。」
ボク「はい。」

そんなやり取りがあったとか無かったとか

ブログをご覧の皆さまこんにちは。エンジニアの小川です。

今回はAIツール「Dify」について、入門編として基本的な使い方を解説します。

2. Difyとは

Dify公式サイト
https://www.dify.ai/

まとめるとDifyはAIアプリケーションを簡単に作成できるプラットフォームです。
GUIで操作できるため、プログラミングの知識がなくてもAIツールを作成できます。

ええそうです。ごくごく簡単なものであれば。

実際はコードを書かないといけない場面が多々ありますし、そもそもやりたいことのワークフローの設計自体が難しいケースもあります。

つまりは謳われている程には「プログラミング知識がなくても良い」ことはなく、あった方が断然良いかと思われます。まぁ「ノーコード」を名乗るサービスの多くは大体そんな感じかと思いますが。

一方で経験がある方からすると、DifyはLLMを使ったアプリケーションをとても手軽に作成できる便利なツールと言えます。

そこで本記事では、Difyの基本的な使い方と、LLMやMCPサーバーとの連携方法について、2部構成で紹介します。

・はじめてのDify - エージェント&ワークフロー実践: 第1部 入門編
・はじめてのDify - エージェント&ワークフロー実践: 第2部 応用編

本記事は主に

　・初級〜中級エンジニアの方
　・Difyを初めて使う方
　・DifyでLLMを使ったアプリケーションを作成したい方
　・DifyとMCPサーバーの連携に興味がある方

を対象としています。

3. Difyの基本操作

3-1. Difyの種類

Difyには大きく分けて2つの提供形態があります。

・Dify Cloud：Dify社が提供するクラウドサービス
・Dify Self-Hosted：Difyのオープンソースコードを自分で構築・ホスティングする

今回はCloud版を使用します。Self-Hosted版はGitHubでコードが公開されていますので、興味がある方はそちらも試してみてください。実際に使ってみましたが、Docker経験者であればとても簡単に構築できるかと思います。

またEnterprise版もありますが、こちらは大規模組織向けの有料プランとなっており、今回は割愛します。

3-2. アカウント作成

まずはDifyのアカウントを作成します。
特に難しい点はありません。

Dify公式サイト（https://www.dify.ai/）にアクセスし、画面右上の「Get Started」ボタンをクリックします。

GitHubアカウント、Googleアカウント、またはメールアドレスで登録/ログインできます。

ログイン後、Difyのダッシュボード画面が表示されます。

3-3. シンプルなワークフローを作ってみる

それでは実際にワークフローを作成してみましょう。
画面内のメニューにある「最初から作成」リンクを押下します。

作成内容の選択画面が表示されます。
ここでは「ワークフロー」を選択し、アプリ名とアプリ説明を入力して「作成する」ボタンを押下します。

現在(2025/11/26)の最新バージョン(v1.10.0)では、開始ノードを選択する機能が追加されていました。
今回は「ユーザー入力」を選択します。

開始ノードが作成され、ワークフロー編集画面が表示されます。

次にワークフローのキャンバス上で右クリックし、表示されるメニューから「ブロックを追加」を選択します。
次に「HTTPリクエスト」を選択します。

次にワークフローのキャンバス上で右クリックし、表示されるメニューから「ブロックを追加」を選択します。
次に「HTTPリクエスト」を選択すると、マウスにHTTPリクエストブロックが追従しますので、それをキャンバス内に配置します。

この中に通信したい先を設定していきます。
今回は例として「livedoor 天気予報API(https://weather.tsukumijima.net/)」を使用しましょう。

API欄でメソッドを「GET」に設定し、URL欄にはAPIのエンドポイントを入力します。
次にこのAPIでは「city」というクエリパラメータが必要となりますが、折角なのでこちらは実行時にユーザが入力できる様にしていきます。

まず「ユーザー入力」ブロックを選択し、「入力フィールド」横の「＋」ボタンを押下します。

押下すると入力フィールドが追加されますので、以下に設定します。

　・フィールドタイプ: 短文
　・変数名：input_city
　・ラベル名: input_city
　・最大長: 48(デフォルト)
　・初期値: 130010(東京)
　・必須: チェック有り

入力できたら次は入力ブロックとHTTPリクエストブロックを接続します。
ユーザー入力ブロックにマウスオーバーすると、右側に小さな丸が表示されますので、それをドラッグしてHTTPリクエストブロックに接続します。
これでユーザが入力した値をHTTPリクエストブロックで使用できる様になります。

次にHTTPリクエストブロックを選択し、「パラメータ」フィールドに以下を設定します。
入力欄で「/」を最初に入力すると、変数を指定できる様になります。

　・キー: city (文字列を入力)
　・値: input_city (変数から設定)

これでユーザが入力した都市IDがHTTPリクエストのクエリパラメータとして設定されます。

最後に結果を出力するための「出力」ブロックを追加します。
先程と同様にキャンバス上で右クリックし、表示されるメニューから「ブロックを追加」から「出力」を選択して配置します。
配置したら先程と同様にHTTPリクエストブロックと出力を接続します。
接続したら、出力ブロックを選択し、「出力内容」フィールドに以下を設定します。

　・result: {{HTTPリクエスト.body}}

これでHTTPリクエストのレスポンスボディが出力される様になります。

それでは最後に「テスト実行」ボタンを押下して動作確認をしてみましょう。 入力欄は初期値か、または
全国の地点定義表から都市IDを参照して入力してください。

実行すると実行結果が表示されます。
正常に動作していれば指定した都市の天気予報データがJSON形式で表示されます。

以上でシンプルなワークフローの作成と実行が完了です。

4. Dify実践: LLMとの連携

ワークフローの基本操作が理解できたところで、次はDifyのコア機能と言えるLLMとの連携を試してみましょう。

4-1. 初期設定(LLM設定)

まずは使用するLLMの設定を行います。

ヘッダーのアカウントメニューから「設定」を選択します。

次に設定メニューから「モデルプロバイダー」を選択します。
すると使用できるLLMを提供するサービス一覧が表示されます。

今回は「Gemini」を使用しますので、「Gemini」カードにマウスオーバーし、「インストール」ボタンを押下します。

ここで注意してほしいのが、インストールしたモデルプロバイダーはアンインストールできません(謎仕様)。
その為無駄にインストールしない様に注意してください。「消させろー！」ってなります(なりました)。

インストールが完了したら、次にAPIキーを設定します。
「Gemini」カードの「セットアップ」ボタンを押下し、表示されたモーダル内にGeminiのAPIキーを入力します。
APIキーが正しければ使用できるモデル一覧が表示される様になります。
※GeminiのAPIキーの取得方法については本記事では割愛します。公式ドキュメント等を参照してください。

インストール完了時の表示

Geminiセットアップ画面

セットアップ完了時のGeminiサービス内モデル一覧

以上でLLMを使う準備ができました！

4-2. ワークフローでLLMを使ってみる

それでは実際にLLMを使ったワークフローを作成してみましょう。
先程作成したワークフロー編集画面に戻り、キャンバス上で右クリックし、表示されるメニューから「ブロックを追加」を選択します。
次に「LLM」を選択してLLMブロックをワークフロー内に配置します。

配置したら先程と同様にLLMブロックを編集します。
「AIモデル」欄に先程セットアップしたGeminiモデルを選択します。
今回は一定量まで無料枠で使用できる「Gemini 2.5 Flash」を選択します。

また今回やりたいこととして、現在のワークフローでは1次細分区定義表内の都市IDを入力させていますが、ここからいちいちIDを調べるのは面倒です。
そこでLLMに都市名から都市IDを調べてもらい、そのIDを使用して天気予報APIに問い合わせる様にしてみましょう。

SYSTEMプロンプト欄には以下を設定します。

https://weather.tsukumijima.net/primary_area.xml に定義されている、入力された地名に一番近い1次細分区域の都市IDを取得してください

実行すると実行結果が表示されます。
正常に動作していれば指定した都市名に対応する都市IDが表示されますが、余計なテキストが大量に含まれてしまっていますね。

この結果を天気予報のAPIにそのまま渡してもエラーになってしまいます。
そこでLLMブロックのSYSTEMプロンプトを以下の様に修正してみましょう。
「出力形式を明示的に指定する」ことで、LLMの出力をコントロールします。

https://weather.tsukumijima.net/primary_area.xml に定義されている、入力された地名に一番近い一次細分区域の都市IDを取得してください。
出力は都市IDのみとし、他のテキストは一切含めないでください。

しっかりIDのみが取得できていますね！
あとはLLMブロックの出力をHTTPリクエストブロックのパラメータに設定すれば、都市名から天気予報を取得できるワークフローが完成します。

完成したワークフロー

最終実行結果

ばっちり東京の天気情報が取得できましたね！
以上でLLMを使ったワークフローの作成と実行が完了です！

5. まとめ

本記事ではDifyの基本的な使い方と、LLMとの連携方法について紹介しました。

Difyはノーコード/ローコードでAIアプリケーションを作成できる便利なツールですが、ご覧の通りある程度のプログラミング知識が必要となるかと思います。
更に複雑なことをやろうとすると、通常のブロックだけでは実現できず、コードブロックを使用してJavaScriptやPythonで処理を書く必要が出てきます。

また今回は触れていませんでしたが、今回のワークフローの場合、LLMが返す都市IDが不正確な場合があり、その場合は天気予報APIからエラーが返ってしまいます。
こういったケースに対応するには、エラーハンドリングやリトライ処理を実装するなどの工夫が必要となってきます。AIによる不確実性を考慮した設計が求められる点は、他のLLM連携ツールと同様です。
ちなみに今回は数回の試行の内、1回謎のIDを出力していました。

しかしプログラムを理解している人が、複数サービスのAPIを組み合わせてAIアプリケーションを手軽に作成するツールとしては非常に有用であるとは感じます。
以前も「Yahoo Pipes」の様な複数のAPIを組み合わせることができるマッシュアップサービスが数多くありましたが、そのAI対応版でしょうか。
※残念ながらYahoo Pipesは2015年にサービス終了しました。当時は「マッシュアップ」という言葉と共に流行ったんですけど一緒に廃れましたね。

また冒頭に出てきましたが、少し前までスケジュールトリガ機能がありませんでしたが、現在では実装された模様ですので、より多様なユースケースに対応できる様になっているかと思います。
今後もDifyの機能追加や改善が進むことが期待されますので、興味がある方は是非試してみてください。

次回は「DifyとMCPサーバーの連携」について紹介します。

1. はじめに

ブログをご覧の皆さまこんにちは。エンジニアの小川です。

前回の記事ではZapier社が提供するSaaS型のMCPサーバーのVS Codeでの使用方法をご紹介しました。
本記事ではOSSとして公開されているMCPサーバを使用するケースをご紹介します。

以前の記事で紹介しましたが、OSSのMCPサーバーは以下で公開されています。

AI Base : https://mcp.aibase.com/ja/explore

(※他にもあるかもしれませんが、今のところここしか見つけられていません)

今回はこちらで公開されているGoogle スプレッドシート連携のMCPサーバーを使用してみます。

2. OSS MCPサーバーを使ってみよう

この項では以下の流れを行っていきます。

[準備フェーズ]
①OSS MCPサーバーをGitHubからダウンロード
②OSS MCPサーバーを構築
③VS CodeにMCPサーバー情報を設定

[実行フェーズ]
①Agentを実行しよう
②実行ログを見て、通信の動きを確認しよう

2-1. 準備フェーズ

①OSS MCPサーバーをGitHubからダウンロード

まずは使用したいMCPサーバーをGitHubからダウンロードします。今回はこちらを使用したいと思います。

Googlesheet MCP

画面右上にあるGitHubアイコンをクリックするとGitHubリポジトリに移動しますので、ローカルにプロジェクトをダウンロードします。

ちなみにこちらが良い物かどうかはこの時点では分かりません。この時点でできることは、評価とDL数、それと説明文内に使いたい機能がありそうなのを選ぶしかできません。
できればDocker上で動作するものを選ぶと比較的楽ですが、対応しているものはあまり多くないようです。ただDockerFile/compose.yamlが入っていても動かないものもあります。落とし穴ばかりですね...。


今回紹介しているMCPサーバーは、このブログ用に構築してみた3番目に試した物になります。先に試した2つはREADMEが滅茶苦茶で止めました。(※ファイル構成/起動方法がREADMEの内容と全く違うという...。)
ちなみにこちらのプロジェクトも元のままではVS Codeで動きませんでしたので、少し手を加えています。READMEにはCursorの説明が記載されていてるので、もしかしたらCursorならそのまま動くのかもしれません。

また念の為、使用前にはコードをチェックしておきましょう。悪意のあるコードが混入している可能性もゼロではありません。

良かった

②OSS MCPサーバーを構築

それではプロジェクトに添付のマニュアルに従ってMCPサーバーを構築していきます。
Pythonの実行環境は整っている前提で進めます。

1. 使用するPythonライブラリをインストールします。

2. Google Cloud Platformでプロジェクトとサービスアカウントを作成し、「APIとサービス」からGoogle スプレッドシートAPIの権限設定を行った後、「IAMと管理」からcredentials.jsonをダウンロードします。

GCPの詳細説明は割愛していますが、ここが一番大変かも。

3. credentials.jsonをプロジェクトのルートに配置します。

4. Googleスプレッドシートを開き、共有設定でサービスアカウントのメールアドレスを追加します。

5. 以下のコマンドを実行してMCPサーバーをインストール

ここまでで一旦MCPサーバーの構築は完了です。
早速ドキュメントに記載していない手順もありましたが、恐らくこれで良い・・・ハズです。

③VS CodeにMCPサーバー情報を設定

前々回の記事で作成した .vscode/mcp.jsonファイルに記載します。記載の内容はREADMEに書いてある通りです。

今までと書き方が変わっていますね。今まではHTTPで接続していましたが、今回は直接Pythonのコマンドで実行する形になっています。
これでVS CodeからMCPサーバーに接続できるようになります。なっているはずです...!

④動きませんでした。そしてその対策。

結論がタイトルになってしまいましたが、残念ながら動きませんでした。ほんとこんなのばっかり

ここでログに出ているエラーをGitHub Copilotと相談しながら行った対応を以下に記載します。
このMCPサーバーは使う予定がない方はスキップしてください。

1.vscode/mcp.jsonを修正します

2.main.pyを修正します

3. 起動はREADMEの起動コマンドでなく、IDEのMCPサーバー起動ボタン、またはAgentが実行時に自動で起動して使用します

以上でMCPサーバーの修正が完了です。
これでVS CodeからMCPサーバーに接続できるようになります。

ちなみにこの修正はあくまで私の環境で動かすためのものであり、他の環境で動作する保証はありません。もしかしたらCursor環境では動くのかもしれません。

そういうの止めて欲しいですけど...。

2-2. 実行フェーズ

①Agentを実行しよう

それでは実際にAgentを実行してみましょう。
まずは試験的に、Googleスプレッドシートにデータを追加する依頼を実行します。

実行した所、どのスプレッドシートにデータを追加するかの指示が不足している旨のエラーが発生しました。
そこで対象のスプレッドシートのURLを渡して再度実行します。

登録に成功しました！

ログを見ると途中思っていたより手間取っていますが、無事にMCPサーバーを使用してGoogleスプレッドシートにデータを追加することができました。

実際にスプレッドシートを確認してみます。

登録されているのを確認できました！次はシート内のデータを読み込んでみます

正しく読み込みが確認できましたね！

それでは次は少し複雑なことをやらしてみましょう。
こちらのサイトで配布されている日次セールス レポート フォームを使用して、対象のデータを取得させてみます

全体読み込みはOK

細かな内容の指定もOK

レポートの表の内容も正しく認識できていますね！

以上でMCPサーバーを使用したGoogleスプレッドシートの読み書きができることが確認できました。

ただ途中で発生した問題として、実は何度かAgent内の学習データを消してスクリーンショット撮影用にと最初からやり直しをしていたのですが、

　・スプレッドシートへの書き込みに失敗する様になってしまい、何度も繰り返した結果、「送信するパラメータが分かりません」とAgentが途中で処理を諦めた。
　・書き込んだデータの前後に変な記号が入っていた。

等と、同じ命令文でも挙動が安定しませんでした。
これらはもしかしたらMCPサーバー側の問題かもしれませんし、Agent側の問題かもしれません。
このあたりやはりAIによる不確実性が否めず、信用性の面で課題がありそうです。

②実行ログを見て、通信の動きを確認しよう

最後に実行時のログを見てみましょう。
元のプロジェクトではログの出力が全く行われていなかったため、main.pyにログ出力のコードを追加してみます。
以下が実行時のログになります。

「シートのデータを読み込んでください」：初回実行時のログ

連続して2回目実行時のログ

VS Codeの「New Chat」を押下し、チャット欄を初期の状態にして再度データ読み込みを実行

ログを見ると、MCPサーバーがどのように動いているかが分かります。
1回目の実行時にはMCPサーバーが起動し、

・ListPromptsRequest
・ListToolsRequest

を行ってMCPサーバー内のpromptやツールの一覧を取得し、

・CallToolRequest

でツールの呼び出しを行っていることが分かります。

2回目の実行時にはList情報を保持している為か、CallToolRequestのみが処理されており、その後get_sheet_contentを実行してシート情報を取得しています。
3回目、今度はチャット履歴を消して再度実行した際には、CallToolRequestのみが処理されていますが、その後はlist_spreadsheetsでスプレッドシート一覧を取得しようとしています。list_spreadsheetsは1回目と同じ挙動です。

ここから分かることは、AgentとMCPサーバーは状態を保持しますが、チャット履歴を消すと一部消えるデータと消えないデータがあることが分かります。

・MCPツールListやPrompt List - 消えていない
・取得対象のスプレッドシートID - 消えている

これはVS Code内のチャット別に保持しているデータ、LLMとの会話セッションで保持しているデータによるものかと思われます。
またこれらはMCPクライアント(Agent)の設計によるものかと思われますので、詳細に探るのは難しいです。また使用するMCPクライアントによって挙動が変わる可能性があります。

3. まとめ

以上、OSSのMCPサーバーを使用してGoogleスプレッドシートにデータを読み書きする方法をご紹介しました。

OSSのMCPサーバーはSaaS型のMCPサーバーと比べて、
・使いたいサービス別にMCPサーバーが必要になる。
・自分でサーバーを構築する必要がある。
・動作が不安定な場合/そもそも動かないケースがあり、信頼性に乏しい。
・開発言語がC#/Go/Java/TypeScript(JavaScript)/Python/Rustなど多岐に渡る為、環境構築の為には各言語別の知識が求められる。

といったデメリットがありますが、

・自分でサーバーを構築するため、セキュリティ面で安心できる。
・自分でサーバーを構築するため、カスタマイズが可能。 (とはいえ今回の様な強制カスタマイズ必須はメリットではないけれど)

といったメリットもあります。

どちらを使用するかは、使用する用途や環境によって異なりますが、
セキュリティ面で不安がある場合や、外にデータを極力出したくない場合(基本外部のLLMサービス使っておいて何をという話ですけど)には
カスタマイズが必要な場合はOSSのMCPサーバーを使用する、または参考に自作するというのはありかと思います。
3つのパターンの比較を表にすると以下になります。

4. MCPサーバーのそれは極めて個人的な考察

MCPサーバーの導入方法3部作、いかがでしたでしょうか？

正直な所、現時点でのOSSのMCPサーバーはあまりお勧めできません。
今回の流れを見て頂いた通り、ドキュメントは滅茶苦茶、動かそうとしてもコードに手を加えなければいけない等、ヒッジョーに扱いづらいです。ダウンロードするプロジェクトが次から次へとこんな感じで、何度PCの前で雄叫びをあげたか分かりません。こんなハズじゃなかった。歴史がボクに問いかける。

趣味や個人利用の範囲であればよいですが、そのままの使用は業務利用には向かないかと思います。あくまでソースの参考程度に留めておくのが良いかと思います。

ただしこれが今後apache foundationのような大きな組織,コミュニティがベースのMCPサーバーをOSSとして公開し、継続的にメンテナンスされるようになれば話は変わってくるかと思いますので今後に期待したい所です。

しかし今回3種のMCPサーバーをガッツリと触ってみて思ったのは、MCP自体は非常に面白い技術であり、LLMと外部サービスを繋ぐ上で非常に有用であるとは感じました。
例えば今後開発するシステム内に、APIだけでなくMCP機能も合わせて組み込むことで、LLMを使用した柔軟な操作が可能になる等、応用範囲は広いかと思います。

今後もっと使いやすくなり、エンジニアぐらいしか使わないVS Code等のIDE以外からも簡単に使用できるようになれば、一般利用がもっと進むと思います。

最後までお読みいただきありがとうございました。

1. はじめに

ブログをご覧の皆さまこんにちは。エンジニアの小川です。

前回の記事ではGitHubが提供する公式のMCPサーバーを使用したMCPサーバーのVS Codeでの使用方法をご紹介しました。

本記事ではZapier社が提供するSaaS型のMCPサーバを使用するケースをご紹介します。

Zapier MCPサーバーは、GitHub MCPとは異なり「コード不要」で外部サービスのAPIを扱えるのが最大の特徴です。利用者はトークン等の接続情報を設定するだけでMCPサーバーとして扱える点が大きなメリットです。

本記事は主にVS Code、またGitHub Copilot、Claude Code等のAIエージェントの使用経験があるエンジニアの方を対象としています。

2. Zapier MCPサーバーを使ってみよう

この項では以下の流れを行っていきます。

[準備フェーズ]
①Zapierでアカウント作成
②ZapierでMCPサーバーを構築
③VS CodeにMCPサーバー情報を設定

[実行フェーズ]
①Agentを実行しよう
②Zapierの実行履歴(History)を確認しよう

2-1. 準備フェーズ

①Zapierでアカウント作成

まずはZapierのアカウントを作成します。https://zapier.com/mcpにアクセスしてSign upからアカウント作成画面に遷移しますので、サイト内の記載の通りに作成します。

アカウントが作成できたら早速ログインします。
ここで注意していただきたいのが、ヘッダーのLoginボタンからログインを行うと別のサービス画面に遷移しますので、https://zapier.com/mcpのTOP画面の「Start Building」からログインしてください。いやほんと謎仕様...。

「Start Building」から入った場合のMCPサーバー画面

ヘッダーからログインした場合のZapierのメインサービス画面
ちなみにこの画面からはMCP画面に遷移できないので、入ってしまったらやり直し。

②ZapierでMCPサーバーを構築

まずは画面内にある「+ NEW MCP Server」ボタンを押下します

モーダルが表示されるので、「MCP Client」のセレクトボックスで、MCPサーバーに接続するクライアントツールを選択し、Nameには適当な識別名を付けます。

サイドバーに追加されたMCPサーバーを選択すると、現在のMCPサーバーの設定情報が表示されますので、こちらで「+ Add tool」ボタンを押下します。

追加できるWebサービス一覧が表示されます。先頭には恐らくよく使われるサービスが表示されておりますので、一覧に無い場合は検索ボックスから検索します。
今回は「Slack」を選択します。

Slackで使用できるTool(API)一覧画面が表示されます。この中から使いたいSlackの機能を選択します。

Toolの選択が完了すると、サービスへの接続設定が求められます。今回はSlackを選択している為、Slackへの接続設定を行うボタンが表示されます。

今回は合わせてGoogle Calendarも追加しました。

③VS CodeにMCPサーバー情報を設定

最後にVS Codeとの接続設定を行います。
接続設定はヘッダにある「Connect」リンクを押下します。すると選択したMCP Clientへの接続設定と、接続用に発行されたURLが一部隠された状態で表示されます。

「Server URL」の右にある「Copy URL」ボタンを押下すると、クリップボードにMCPサーバーのURLがコピーされます。

そして今度は取得したサーバーのURLを、前回の記事で作成した .vscode/mcp.jsonファイルに記載します。記載の内容は以下です。

以上でMCPサーバーへの接続が完了です！今回もとても簡単でしたね！

2-2. 実行フェーズ

①Agentを実行しよう

それでは早速使ってみましょう！今回GitHub Copilot Agentが連携している対象は「Slack」と「Google Calendar」の２つのサービスと連携できているハズ！です！

今回テスト用に、Slackに「#notify」チャンネルを作成し、Googleカレンダーには「お茶を買いに行く」という日程を追加しました。

さて、それではCopilot Agentにお茶を買いに行く日付を調べさせて、分かったらSlackの#notifyチャンネルに通知させる動作確認を実用性はさておき行ってみたいと思います。

途中でSlackにメッセージを投稿して良いのか？という確認が入りますのでOKします。

完了したみたいですので、Slackチャンネルを見てみます。

問題なく投稿できていますね！

以上、とても簡単に Google Calendarから検索→Slack通知という、複数のサービスと連携した動作が実現できました！

②Zapierの実行履歴(History)を確認しよう

最後にZapier側で実際にMCPサーバーがどのように動作したかを確認してみます。
Zapier MCPサーバーの画面に戻り、ヘッダーの「History」リンクを押下します。

History画面ではMCPサーバーが受け取ったリクエストが一覧で表示されています。
ここで先程のSlack通知の際に送信されたリクエストを選択してみます。

アコーディオンを展開すると、MCPサーバーが受け取ったリクエストの詳細情報が確認できます。
ここではMCPサーバーが受け取った指示内容や、Slackに投稿するために解決したパラメータ情報、最終的な出力結果などを確認することができます。
これにより、MCPサーバーがどのように動作したかを把握できます。

3. まとめ

以上、SaaS提供MCPサーバーであるZapier MCPサーバーを使って複数のサービスと連携した動作がとても簡単に実現できることを紹介しました。

前回の公式GitHub MCPサーバーと比べ、今回のSaaS型 MCPサーバーは

・アプリやアプリ内のToolsの追加が画面上で簡単に行える。
・どういうToolが使えるかが一覧で把握できる。
・外部サービスの認証設定も画面上で簡単に行える。

といったメリットがあることがわかりました。
また今回紹介はしておりませんが、WebhookやカスタムAPIを使用して独自のサービスと連携することも可能です。

一方でZapier MCPサーバーでは

・日本のサービスはあまり対応していない。
・社内システムなどの外部に公開されていないAPIとは連携できない。
・使用の都度コストがかかる（無料プランもありますが、利用制限が厳しい）。

といった点にも注意が必要です。

次回はOSS MCPサーバーを構築して使用する例を紹介します。