はじめに

ClaudeがMCP(Model Context Protocol)を発表してから、約半年が経過しましたが、web上の文書情報からだとイマイチ、ピンと来ていない方も多くいらっしゃるのではないかと思います（私はそうでした）。今回は、MCPを実際に使って、手元のClaude Desktopとslackおよびgithubとを接続し、人からお願いされたプログラムの修正作業を優秀な部下ならぬAIに依頼してみました。

MCPサーバーとは？

私は、インターネットを介してつながっている数々のサービスに対してAIが指示を出せるようにするために、AIとサービスとを仲介するサーバーと理解しています。例えばwebアプリケーションで指示の受付をwebAPIとして用意しているのであれば、AIデスクトップアプリからMCPサーバーを介してwebAPIをたたくことが可能になります。MCPサーバーとAIデスクトップアプリ（web上のサービスも同様と思われます）とが通信をする際の決め事がMCPです。
今回はせっかくなので、仕事をする上で必要な複数のツールを跨いで、以下のような仕事を完結させることができるのか、検証してみようと思います。

slackでチームメンバーから仕事を依頼される。
依頼された内容を理解する。今回はとあるプログラムのコードの修正依頼です。
依頼された内容を実施する。＝github上でコードの修正作業を行う。
依頼通りのものができているか、slackで依頼者に投げ返す。

　これを実現するため、私の手元のwindowsマシンに以下のような構築をしました。

上記の構築手順

ここからは技術的な内容ですので、結果だけに興味がある方は、次のセクションまで読み飛ばしてください。

AIデスクトップアプリの準備

今回はClaudeデスクトップを使用します。公式サイトからデスクトップアプリをダウンロード、インストールします。

MCPサーバーの準備

MCPサーバーとしての機能を果たすNode.jsの準備をします。（以下手順はほぼこちらの和訳です。MacやLinuxマシンで構築される方などは参考になるかと思います）
Powershellを開いて、以下のコマンドでNode.jsをローカルマシンにインストールします。

winget install OpenJS.NodeJS.LTS

インストールが完了したら、Powershellを再起動します。
今ログインしているユーザーがNodeを実行できるよう設定します。

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

インストールがうまく行っていることを確認します。
（このコマンドでバージョンが表示されない場合は、なんらかの不具合があります。）

node --version

バージョンが表示されればOKです。

webAPI側の準備

各webAPIにアクセスするための認証情報を取得します。

github

slack側の準備

今回は、自分の環境に参加できるslack botという架空のアカウントのようなものを作成して、そのアカウントにslack内の情報を参照、追加できる権限を与え、そのbotを介して情報を取得する構成にします。

slack appsの管理ページへアクセス
右上のCreate New Appをクリックし、From scratchを選択
作成したら、左メニューのOAuth & Permissionへ
スクロールして、Bot Token ScopesでBotに与える権限を設定します。

今回はこのように設定しました。
設定が完了したら同画面のOAuth Tokensからワークスペースへのインストールを行い、Bot User OAuth Tokenをコピーします。
別途slackの場合はチームIDが必要です。web版slackにアクセスすると、URLに記載されていますので、そこから取得するのが良さそうです。
例：https://app.slack.com/client/{ここがチームID}/XXXXXX

Claude Desktopの設定

取得したトークンをAIエージェントに設定していきます。

Claude Desktopを起動する。
左上のハンバーガーメニューのマークをクリックする。
ファイルから設定をクリック
左側のタブから開発者をクリック
構成を編集をクリック
エクスプローラーが立ち上がるので、開かれたページにあるclaude_desktop_config.jsonを編集する

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-slack"
      ],
      "env": {
        "SLACK_BOT_TOKEN": "ここにslackのトークン",
        "SLACK_TEAM_ID": "ここにslackのチームID"
      }
    },
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ここにgithubのトークン"
      }
    }
  }
}

設定した内容としては

Claude Desktopを起動したら、slackとgithubのMCPサーバーを起動する
webAPIへのアクセス時に必要な認証情報を設定する

になります。設定が完了したら、Claude Desktopを再起動します。
うまく設定ができていると、プロンプトの入力欄下にハンマーのマークで使用できるMCPツールを確認できるようになります。
これで、構築が完了しました。

検証結果

まずは、同僚に仕事を依頼してもらいます。
この仕事をClaudeに依頼します。プロンプトは「slackのお問合せチャンネルで駒形さんからお願いされている件、やっておいて。プルリク作るところまでで、マージはしなくていいから。完成したら駒形さんにこれで有ってるか、確認してもらうように依頼しておいて。」（よくよく考えるとこれだと品質確認を私がしないフローなので、無責任な仕事の仕方にはなってしまってますが）
結果はこちらです

なぜか英語になってしまっています。作業手順を確認してみます。
1. まずslackにそのような依頼があったかどうかの確認をしに行く
2. 確認されたら依頼内容を解釈し、何をすべきかを決める
3. 依頼された内容を自分が遂行可能確認する。また遂行に必要な情報をweb上から収集する。
4. 実行にうつる。少々の失敗（ここではブランチを作ろうとしたものの、同名のブランチがすでにあり、一度処理に失敗する）があっても回避方法を考え、やり直しをしてくれる。
5. 作業が完了する。できあがったものがこちら
- 作成されたプルリクエストの変更内容
- slackでの確認依頼
  
  なぜかマージの依頼をしてしまっていますね。これは私の指示が悪かったとも言えます。
  またメンションにも失敗しているようです。

感想、気になった点、追加情報など

今回は依頼した内容が完結かつ具体的なものであったので、想定通りのものを実際に作り上げてくれました。細かな点でミスや、ハルシネーションと取れなくもないような勝手な意思決定も見られましたが、この辺りは調整や今後のLLMの更なる発展でいかようにでも改善されていくでしょう。
方々で叫ばれている通り、AIの指示のもと人間が機械的に行っている作業が不要となることがこの技術の最大の利点のように思います。MCPを使用できるものは何もwebAPIに限りません。より実務に近い所では、自分のPCのファイルシステムとつなげ、ローカルネットワークのプリンターとつなげることで「あの書類印刷しといて」の指示でプリンターが動き出すようになるはずです。

利用者目線でMCPサーバーのすごい所は何か？
- 従来の技術でもできたのではないか？
  今回AIデスクトップアプリからMCPサーバーを介してwebAPIへリクエストをかけましたが、MCPサーバーを介することの利点は何でしょうか。どうも仲介させなくともできなくはないが、使用するAPIの仕様を熟知した専門家が間に入る方が、AIを使う側の手間が少なく速度も速い、ということのようです。いちいち各サービスの仕様を調べて、AIに教え込むのは面倒なので辞書の役割を果たすサーバーを用意して、そのサーバーをどんなAIでも使えるようにしておこうよという話のように感じています。現状ではどのMCPサーバーとつなげるかは人間が設定する必要があります。MCPサーバーがweb上に乱立するようになれば、取捨選択が面倒になりそうです。（と思ったらこんな構想がすでにあるようです）
- ローカルマシン上にMCPサーバーを立てなければならない理由はなにか
  名前のわりに、手元に環境を立てなくてはいけない理由は何か、気になりました。私は現状、以下の理解をしています。
  - つなげたい先がローカルネットワークにある可能性がある。
    例えば自分のPCのファイルシステムやオフィスに設置したIoTデバイスなどとの通信は、ローカルネットワーク内で閉じて行うことができるので、安全性を気にせず使用できます。
  - 費用・管理問題
    単純に立ち上げるサーバーの維持費やメンテナンスの責任を誰が持つのか、という問題があります。
  - 認証情報の漏洩
    第三者が立ち上げたリモートMCPサーバーとつなげてしまうと、それはそのまま認証情報をそのサーバーを運営する人へ漏洩したことになってしまいます。従って、もし例えばslack公式が管理するMCPサーバーを立ち上げた場合、そこへつなげることにはセキュリティ上のリスクはなさそうです。もしくは、自社内で管理するリモートMCPサーバーを設置するのも同様でしょう。CloudFlareやAzureなど、大手IaaSはすでにリモートMCPサーバーを容易に構築するサービスを提供し始めています。
    このリモートMCPサーバーの認証に関する問題については、SSEという技術で解決するよう鋭意開発が進んでいるようです。

おわりに

業務で発生した記録や、業務実施のノウハウはITシステムによって支援されてきましたが、MCPの不況に伴い、その記録を使用した次の動き方の検討や、その業務の実行も支援されるようになりました。生成AIはすでにほとんどの人類を凌駕する知性を持っていますから、これは支援ではなく代替と言い切ってしまってよいかもしれません。人が発揮できる価値は意思決定のその結果に対する責任がほとんどな世の中になりそうです。これは物理的な要求をなされない仕事内容について、人手不足を感じている会社にとってはまたとない機会だと思います。

株式会社LOKIARでは、こうした業務の効率化を実現するための食品物流に特化したコンサルティング、システム開発業務を承っております。ぜひお気軽にお問合せくださいませ。物流について相談する

また、弊社では開発にご助力いただける方を募集しています。
まずはカジュアルに情報交換させて頂ければと思いますので、
ぜひこちらからお問い合わせください。