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サーバーを構築して使用する例を紹介します。

1. はじめに

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

前回の記事ではMCPサーバーの概要と導入時の注意点について書きましたが、 今回はVS CodeやClaudeCodeから実際にMCPサーバーを使用して外部サービスと連携する方法を実践形式で解説します。

MCPサーバーには現在、大きく分けて3つの提供形態があります。

・公式MCPサーバー：Anthropic社など、サービス提供会社が提供,公開しているMCPサーバー
・SaaS型MCPサーバー：Zapier社等が提供するクラウドサービス
・OSS MCPサーバー：GitHub等で公開されているオープンソースのコードを自分で構築・ホスティングする

これら3つの方法を実際に試してみて、それぞれの特徴と使い方を比較していきます。

本記事は第1部としてGitHub公式のMCPサーバーを使用した例を紹介します。
また本記事は主にVS CodeやClaude Codeの使用経験があるエンジニアの方を対象としています。

2. 公式GitHub MCPサーバーを使ってみよう

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

[準備フェーズ]
①GitHubでPersonal Access Tokenを作成
②VS CodeにMCPサーバ情報を設定
③作業対象のサンプルプロジェクトを作成

[実行フェーズ]
・GitHub Copilot Agentを使用してIssue情報を取得し、対応作業を実行して完了後にPRを出す。

2-1. 準備フェーズ

①Personal Access Tokenの作成
まずはGitHubでPersonal Access Token(PAT)を作成します。
今回は「Fine-grained personal access tokens」を使用しています。

GitHub MCPサーバーを使用するにあたり、PATに以下の権限を付与します。

・Repository permissions
  └ Contents: Read and write
  └ Issues: Read and write
  └ Pull requests: Read and write
  └ Metadata: Read-only

②MCPサーバーの接続情報ファイルをVS Codeに設定
VS Codeのワークスペースに.vscode/mcp.jsonファイルを作成し、以下の内容を記述します。

これでGitHub CopilotからGitHub MCPサーバを使用する準備は完了です。とても簡単ですね！

③作業対象のサンプルプロジェクトを作成
実際に操作する対象のサンプルプロジェクトを作成します。
今回は以下のような簡単なWEBページを(GitHub Copilotが)作成しました。

・GitHubリポジトリ: index.htmlのみ作成

・作成したWEBページ: ユニバース不動産 トップページ

2-2. 実行フェーズ

実行フェーズでは以下の操作を行っていきます。

　① GitHubにIssueを登録
　② VS CodeのGitHub Copilot AgentでIssue情報を取得
　③ Issueの対応作業を実行し、PRを作成する
　④ PRの確認

①GitHubにIssueを登録

GitHubに行わせたい作業のIssueを登録します。
ここではデザインを青から赤に変更し、TOP画面のメッセージを変更する内容のIssueを登録しました。

② VS CodeのGitHub Copilot AgentでIssue情報を取得

それではGitHub Copilot Agentを起動し、MCPサーバー経由でIssue情報を取得させてみます。

正しくIssue情報が取得できました。出力からMCPサーバーを経由していることがわかります。

③ Issueの対応作業を実行し、PRを作成する

それでは実際にIssueの対応作業を実行させ、完了後にPRを作成させてみます。

出力されたメッセージは以下の通りです。

以上の出力からGitHub Copilot AgentがIssueの内容を理解し、対応作業を実行してPRを作成したことがわかります。

またGitHub Copilot Agentの処理途中に何度か操作確認のメッセージが表示されました。
データの読み取りには確認がありませんが、追加/変更系の処理、またターミナルの実行時には確認が入る仕様となっている様です。

④ PRの確認

最後にGitHub上でPRが作成されていることを確認します。

PRと修正後の画面を確認すると、Issueで指定した内容が正しく反映されているようです。

ただし画面のスクリーンショットは正しく作成・アップロードできませんでした。
今回はチャットの途中で画像URLの入力を求められましたが、別のケースではPR内に存在しないURLを指定することもあり、このあたりはまだ正確さに欠けるようです。
これはGitHub Copilot Agentの現時点での制限事項と思われます。

3. まとめ

以上、GitHub CopilotのMCPサーバーを経由してIssue情報を取得し、作業を実行してPRを作成する例を紹介しました。

実は今回の内容に関しては、MCPサーバーを使用しなくてもGitHub CLIやgitコマンドで実現可能です。
実際MCPサーバーが利用できない場合、GitHub Copilot Agentは自動で処理方法を切り替えて動作します。

しかし、それでもMCPサーバーを使用することで以下のようなメリットがあります。

・統一されたインターフェースで複数のサービスと連携できる
・手元にGitHub CLIなどのツールをインストールする必要がない
・認証情報を一元管理できる
・今後のアップデートにより、MCPサーバーでしか実現できない機能が追加される可能性がある

特に複数の外部サービスを統合して利用する場合、MCPサーバーの真価が発揮されると考えられます。

今回はGitHub MCPサーバーを使って、MCPサーバーの基本的な使い方とGitHub Copilot Agentでどのように活用されるかを紹介しました。
次回はSaaS型MCPサーバーのZapier MCPを使用した例を紹介します。

1. はじめに

山根さん「小川くん、MCPって知ってる？」
ボク「あー、アレですよね。最近よく聞くアレ、AIの、あのー・・・アレです。」
山根さん「じゃあ調べてブログ書いてね。」
ボク「はい。」

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

昨今目覚ましい進展を見せているAIに合わせ、「MCP」なるものを随所で目にする機会が増えました。
ボクも普段は目にするばかりで強く調べたりはしていなかったのですが、最近業務でMCPについて関わることになりました。 その中で調査したこと、実際に利用していった中で分かったこと、何となく認識していたもので誤解していたこと等をブログをご覧の皆さまと共有できればと思います。

本記事は入門説明＋実体験レポート の2部構成で進めていきます。
また今回の記事は主にMCPの導入を考えている非エンジニア、ならびにMCPの海に漕ぎだそうとしているエンジニアの方を対象としています。

2. MCPとは(一般論)

ここまでの説明だと少し抽象的ですが、次にMCPに関する記事や図を見ると、多くの人がこの規格をどのようにイメージしているのかが分かります。 以下の図は、MCPの仕組みを説明する際に、多くの記事で引用されている図の一例です。

このイラストはとてもわかり易いですね。

ふんふんなるほど、MCPというのはAIを異なる複数のサービスと連携できる様にするハブ的なものなのかな。
で、MCPサーバーは名前通りだとそのMCPが動いているサーバーなのかなと。




...でも「Protocol」って言っているのになんでUSBハブになるの？
何かおかしい気がする...と思いながらも、他の記事を見てみても大体以下の様な図が出てきます。

これらの説明から、とりあえず「MCPを使えばAIと各システムを繋ぐことができるんだな」と、 そしてそれはきっと「MCPサーバーを立てれば実現できるんだね」と。

当初はその様にかなりざっくりと理解していたのですが、実際に触ってみたら概ねその通りではありましたが、認識が色々と違っていました。
こちら周囲に聞いてみた所、結構な人が同じ誤った認識をしていました

3. 実際に触ってわかったこと: よくある誤解

4. MCPを導入する前に知っておくべきこと

ここまでしてMCP/MCPサーバーを導入するメリットって何かあるのでしょうか。

ChatGPTは登場当初、学習済みの情報から返答を作成していましたが、 現在では質問によってWeb上を検索し、そこで得た情報から回答を作成することができる様になっています。

その様にAIを閉じた状態から外へ出られる状態にすることでできることの可能性は大きく広がりますが、 しかしその一方で、デメリットや注意点をしっかりと認識した上で使わないと大変なことになりえます。

ここでAIにMCPを導入することで実現できること、そして起こりうる問題の可能性について考えてみます。

4-1. 実現できること

・今まで：新しく社員が入社した際、社内システムのアカウントを個別で登録する
　→ AIと各システムのAPIとMCPでつなげることで「新しくアカウント作って」とAIに依頼を投げるだけで作成させる。

・今まで：毎月の売上レポートを管理画面からデータを出力してまとめる
　→ AIに「◯月の売上レポート作って」と依頼することで売上管理システムにアクセスしてデータを取得してレポートを作成させる。

・今まで：EC サイトの売上が急に下がった際、どのページが原因か毎回調査していた
　→ MCP でアクセスログ・CVR・検索ワード API を取得し、
　　　「カートページのエラー率が前週比 40% 上昇しています」
　　　「検索ワード '在庫' が急増しており、欠品が原因の可能性があります」
　　といった "傾向分析＋原因推定"をAIが実施。

・今まで：セキュリティ確認を人手でやっていた
　→ MCP で勤怠・入退室ログ・監視カメラ（サマリデータ）にアクセスし、
　　　「通常勤務しないはずの深夜帯に A さんの入室が連続しています」
　　　「直前に退勤しているため、カードの貸し出しの可能性があります」
　　など異常なパターンを AI が発見。

このように、従来は担当者が個別に対応していたルーチンワークから、ログデータを横断的に分析して原因を推測するような高度な判断まで、AIがMCPを介して調査・分析を行い、その結果を提示できるようになります。

4-2. リスクと注意点

・AIの不確実性による問題
　与えた指示に対して指示者が想定していた動作を必ず行うかどうかは実行してから出ないと分からない。
　DBやシステムへの登録,更新,削除などの権限を与えていた場合、指示を出していなくても実行される可能性がある。

・AI使用料金問題
　MCP通信では、AIに渡す情報量（トークン数）が増えるため、通常より課金が高くなります。
　最近ではトークンを減らすテクニックがAnthropic社から提供されましたが、まだこの仕様が標準では
　ない為、個別に努力する必要があります。
　(参考資料:Anthropic公式のMCPサーバー設計術！98.7%のトークン削減を実現)

ボクはこの不確実性にやや危険を感じています。

例としてボクは普段Amazon Echoを家で使用しているのですが、 「朝9時にアラーム」と告げると翌朝9時にアラームがセットされます。
しかし1度だけ何故か翌々日の朝9時にセットされたことがありました。 原因は未だ不明ですが、以降はセットした後に必ずセットされた日時の表示を見る様にしています。

その他にも例えば「新入社員情報を登録して」と伝えても、AIが無関係な情報を削除することも起こり得ます。
データ取得系のAPIであれば問題ありませんが、登録/更新系のAPIの操作権限をどこまで渡すものか？
AIによる間違った対応が起こった時はどう対応すべきか、などは考慮して使用する必要がある様に思います。

5. まとめ

◯MCPとは
・AIが外部と連携する為の通信仕様のこと。
・実体はない。

◯MCPサーバーとは
・AIと外部サービス(主にAPI)を連携させる為の中継サーバーのこと。
・基本的に1サービス毎に1サーバー必要になる。

◯ MCPクライアントとは
・AI（エージェント）が外部機能を利用する際に、MCPサーバーとの通信を担当するコンポーネント。
・Claude Code などのツールに内蔵されていることが多い。
・AIの指示を受けて、MCPサーバーにリクエストを送る仲介役。

◯ MCP導入のメリット
・作業の自動化：アカウント登録やレポート生成など、人が行う業務をAI経由で一括処理できる。
・拡張性の高さ：同じプロトコル上で新しいツールやサービスを簡単に追加できる。

◯ MCP導入時の注意点
・AIの不確実性：誤ったAPI呼び出しでデータ破壊のリスクがある。
・コスト増加：MCP通信に必要なトークン量が多く、課金額が跳ね上がる可能性。
・セキュリティリスク：第三者製MCPサーバ利用時にはコードレビューが必須。

次回は「実際にMCPを使ってみた」という記事を投稿する予定です。それではまた！

6. おまけ：現状と今後の展望についての極めて個人的な考察

MCPは2024年11月にClaudeを開発したAnthropic社が提唱したAIとサービスを連携させるための標準ルールで、今もどんどんMCPサービスを提供している会社が増えてはいますが、MCPに関してボクはまだ発展途上感が否めません。

特に現在の主な用途はエンジニア向けなのか、ローカル上でMCPサーバーを動作させて同じくローカルのVsCodeやClaudeCodeから接続して使用する様な例ばかりを多く見ます。

MCP対応しているワークフローツールの「Dify」を見てみますと、あえてそうしているのか、こちらMCPに対応はしているものの「これMCPの使い方として正しい？」と疑問に思う機能となっています。

また各種WEBサービスと連携する為のOSSのMCPサーバーを公開しているサイトがありますが、こちらで公開されていたMCPサーバーを利用してみた所、起動はしますがMCPサーバーとのリクエスト/レスポンスの構造が違っていて、正しく連携できなかった事がありました。

これは元のアプリが間違った作りをしたままリリースしているのか、または途中でMCPの仕様が変わってしまい動かなくなったのか。

こうした規格は今後もアップデートしていくのでしょうが、過渡期の現在それがどれほどの頻度で発生するのか、開発としては悩ましい所です。

7. 参考資料: 公開されているMCPサーバ

◯Zapier MCP (https://zapier.com/mcp)
　・有料
　・約8000のWebAppに接続できるMCPサーバーを提供するSaaS

◯CData MCP(https://jp.cdata.com/solutions/mcp/)
　・2025年末まで無料
　・APIキーを取得して使用する
　・Windows Installerが配布されている
　・機能制限版のコードはGithubで公開されている
　　https://github.com/CDataSoftware/cdata-jdbc-mcp-server
　・主にローカル環境のClaude Code等から接続して使用を目的としていると思われる

◯AI Base (https://mcp.aibase.com/ja/explore)
　・OSSで公開されている個人開発のMCPサーバーをリストアップしているサイト
　・各画面からGithubへの遷移リンクがある
　・そのままではろくに使えないものも存在する
　・セキュリティ面は自分でコードを見て安全か確認する必要がある

◯AI Base (https://mcp.aibase.com/ja/explore)
　・OSSで公開されている個人開発のMCPサーバーをリストアップしているサイト
　・各画面からGithubへの遷移リンクがある
　・そのままではろくに使えないものも存在する
　・セキュリティ面は自分でコードを見て安全か確認する必要がある

◯MCP Hub (https://hub.docker.com/mcp/explore)
　・docker社が管理するMCPサーバーのDockerイメージ配布サイト
　・主にサービス提供企業が作成した公式Imageが配布されている

◯Github MCP Registry (https://github.com/mcp)
　・企業が開発した自社サービスのMCPサーバーがリストアップされている