MCP（Model Context Protocol）でClaudeに外部ツールをつなぐ。
手順そのものは、もう難しくありません。
むしろ悩むのは、その先です。
何につなげば本当に得をするのか。
ここが分からない、という人は多いでしょう。
先日、海外のClaudeユーザーが集まる掲示板で、まさにその質問が投げかけられていました。
日々の作業が実際に楽になったMCPを教えてほしい、という趣旨です。
集まった反応は200件を超えました。
しかも、仕事道具から家電、筋トレアプリまで並びます。
驚くほど雑多な顔ぶれでした。
一番人気はチケット管理とドキュメント
最も多くの支持を集めたのは、JiraとConfluenceの組み合わせでした。
次いでLinear、ServiceNow、Slackが続きます。
要するに、チームの記録が溜まっている場所です。
Slackについては、こんな声がありました。
古いスレッドを掘り起こして要約させるだけでも助かる、と。
地味な用途です。
しかし、探し物にかかる時間はばかになりません。
面白いのは、チケット管理を推した人が同時に不満も述べていた点でした。
チケットの説明文が、AI生成の中身の薄い文章で埋まりはじめる。
それをまたAIが読む。
蛇が自分の尻尾を食べているようなものだ、と表現していました。
ではその人が何をしているのか。
書いた本人に直接聞くのだそうです。
「ここ、本当はどういう意味？」
「Xが期待する挙動で合ってる？」
「Yのケースは考えた？」と。
関係者の顔と事情を知っている人間だからこそできる仕事が、そこに残るわけです。
対策として提案されていた工夫も紹介しておきます。
AIが何かを書き込むとき、冒頭には人間向けの短い要約を置く。
詳細はその下に続ける。
そういうルールをスキルとして定義しておく、という手です。
もうひとつ、実務的な注意もありました。
新しいモデルほど、チケットの本文を「自分への指示」として読み取りやすい。
そして、確認なしに作業を始めてしまう場合があるそうです。
読み取り専用のつもりで接続しているなら、権限設定を先に見直しておくほうがよさそうですね。
Notionを「Claudeの作業場」にする
Notionをつないだ瞬間に手応えを感じた、という報告も目立ちました。
ある人は、こんな体験を挙げています。
移動中にスマホのClaudeで考えごとを延々と吐き出し、そのままメモ化した。
翌日デスクトップで開いたら、望んだ形に整理された状態でNotionに収まっていた。
派手な話ではありません。
ただ、こういう小さな連続性が効くのだ、という感想でした。
さらに踏み込んだ使い方をしている人もいます。
Notionの一角をまるごとClaude用の領域として明け渡す。
そして、構造の管理まで任せてしまう方式です。
具体的には、こんなルールを設けていました。
- 各ページの先頭に短い「読み方の説明」を置き、そのページが全体のどこに位置するかを書く
- 新規ページを作るときも、本文と同時にその説明を書かせる
- 説明を読まずにページを編集させない
- 1ページはおおよそ1万字までに抑える（ブロックが増えるとページ自体が重くなるため）
こうしておくと、Claudeはページを開いた瞬間に文脈と内容を同時に受け取れます。
本人は「チームメイトが増えた感覚に近い」と書いていました。
Notion内のデータベースをSQLで問い合わせられる点も、評価されていました。
自作ツールの分析ダッシュボードを維持するのは、やめてしまったそうです。
代わりに「さっきの修正、ちゃんと効いてる？レコードを見て確認して」と頼む形に切り替えました。
家のことをまるごと任せる
支持の多さで二番手に付けたのは、Home Assistantでした。
朝の一連の流れを組んでいる人の例が、具体的で面白かったので紹介します。
枕元のボタンを押すと、夜通し回していた扇風機の電源が切れる。
日の出前なら照明が朝焼けの色に変わり、日の出後ならブラインドが開く。
寝室のドアを開けると、センサーがタイマーを起動する。
そして5分以内に薬のボトルに付けたボタンを押さなければ、スマホに通知が飛ぶ仕組みです。
これに対して、鋭い突っ込みが入りました。
その内容、AIは要らないのでは、と。
Home Assistantの標準機能だけで組めますよね、というわけです。
返答が誠実でした。
確かに全部その通りだ、と認めています。
Home Assistant自体は何年も前から持っていた。
ただし、設定ファイルをいじって連携を組み、不具合を追いかける。
その面倒さがずっと障壁でした。
プロンプト一言で済むところまで手間が下がって、ようやく重い腰が上がったのだそうです。
そのうえで、AIならではの用途も挙げていました。
サーモスタットの記録と電気代と外気温を突き合わせる。
そして、夜間の冷房設定を変えたら料金がどう動くかを見積もる。
照度センサーの数値からは、夕方の自動化を起動する妥当なしきい値を決める。
睡眠や運動のデータも、まとめて眺める。
データが手元にあっても放置しがちな部分を、質問するだけで拾ってもらえるわけです。
別の人は、システムの健全性チェックを「環境の状態を見て」の一言で走らせていました。
問題には優先順位も付けさせています。
ダッシュボードの作成、センサーの命名整理、公開されている自治体の雨量データを取り込んでの平均値算出。
数日で環境を作り直したそうです。
体づくりに使う人も多い
意外に票が集まったのが、トレーニング記録アプリでした。
HevyやLiftin’といったサービスに接続する。
そして、Claudeをコーチ役に据えるパターンです。
やり方は、おおむね共通していました。
過去のケガや制約をまとめたファイルをプロジェクトに置く。
そこを前提にメニューを組ませる。
あとはアプリ側の記録をMCP経由で読ませ、進み具合を見ながら内容を調整させます。
週の頭に全体を振り返り、半ばに簡単な確認を挟む。
そういう運用にしている人もいました。
高額なパーソナルトレーナーとの契約を解約した、体重が目に見えて落ちた。
そんな報告も並んでいます。
ただし、これは投稿者本人の申告です。
検証されたものではありません。
体調に関わる話ですから、真似する前に専門家の意見を挟むほうが賢明でしょう。
技術的に面白かったのは、公開APIのない食事管理アプリの事例です。
通信を解析して、自前のMCPを作ってしまった人がいました。
Android環境をローカルに用意し、アプリの静的解析とプロキシによる通信観察を組み合わせる。
そうやって必要な呼び出しを特定したとのこと。
数時間の試行錯誤で、MCP化まで持っていったそうです。
開発と運用の現場
このあたりは実務的な報告が多く、参考になります。
監視の分野では、DatadogとGrafanaが繰り返し挙がりました。
障害調査を手作業に戻す気にはもうなれない、という声もあります。
Kubernetesとの組み合わせで、クラスタの調査が楽になったという報告もありました。
Splunkを使っている人の話も具体的です。
複数のインデックスを横断させ、事象を時系列に並べさせる。
セキュリティ調査での使用例でした。
1時間かかる作業が数分で片付く、という評価です。
ブラウザ操作では、Playwrightが人気でした。
ただし、ここで有益な指摘が入ります。
PlaywrightをMCPとして接続すると、コンテキストの消費が激しい。
それよりも、コマンドライン版を道具として使わせるほうがいい、と。
この意見には賛同が集中していました。
ライブラリのドキュメントを都度取りに行くContext7も、評価が高いツールです。
日々の流れがいちばん変わった、と書いた人がいました。
学習時点の古いAPIを提案されなくなる点が効いているようです。
こちらもコンテキストは食います。
だから、関数やクラス単位まで絞って問い合わせる。
返却トークン数に上限を設ける。
そういった対処が紹介されていました。
データベース周りでは、自作のPostgreSQL接続MCPが印象的でした。
用途を絞った構成になっています。
テーブル定義の確認、本番以外での参照系クエリ、インデックスと制約の分析。
この3つだけです。
設計時にも障害調査時にも、ちょうどいいタイミングで呼ばれてくれると評価されていました。
作る系のツールとの相性
Figmaは「とにかく素直に動く」という評価でした。
デザイナーから受け取ったファイルを、そのまま渡す。
そしてサイトに起こしてもらう。
そんな使い方が紹介されています。
驚きの声が大きかったのは、Blenderです。
3Dプリント用のモデルを、口頭の説明だけで作る。
何度か直して、その日の午後には現物が手元にある。
SF的だ、という感想が添えられていました。
ホワイトボードのMiroも、印象的な報告がありました。
「作った計画をそのまま図に起こして」の一言で、成果が返ってきたそうです。
無限のキャンバスと作図の道具一式をAIに渡すと何が起きるか。
そういう話として読むと面白いところでしょう。
このほか、WordPressやWebflowでのサイト構築、Sketchでの素材制作、TouchDesignerでの映像制作なども挙がっていました。
反面、Fusionでは期待外れだったという報告もあります。
自分が熟練している領域では、まだ人間のほうが速い場合がある。
素直な感想だと思います。
数字を見る仕事
Google Analytics 4とBigQueryをつないだ人の報告がありました。
サイト上でユーザーが何をしたか。
それを調べる時間を大幅に削れたそうです。
「今日は売上がなぜ落ちたのか」
「フォームの1段階目に進む人は増えているか」
そういった質問を、そのまま投げる使い方でした。
この人の指摘で光っていたのが、答えられなかったときの挙動です。
データが足りずに回答できない場合、次回は答えられるようにするための計測タグの追加を提案してくる。
つまり、計測が育つほど返ってくる答えも良くなっていくわけです。
広告運用でも、似た報告がありました。
ただし、全面的に任せてはいないと明言しています。
ベストプラクティスをスキルとして積み上げ、レポートも調査も提案も自動で回す。
しかし、配信の設定内容だけは自分の目で確かめるそうです。
理由も書かれていました。
「昨日20ドル使ってコンバージョンがゼロだから、このキーワードを止めよう」。
月単位で見れば明らかにおかしい判断を、たまに出してくるからです。
ほかにも、Search Console、PostHog、ShopifyとXeroの組み合わせによる財務レポートといった事例が並んでいました。
逆に「つながない」という答え
このスレッドで最も参考になったのは、実は反対方向の意見だったかもしれません。
接続を大幅に減らしたことが最大の改善だった。
そう書いた人がいました。
理由は明快です。
接続中のサーバーは、そのツール定義が毎ターンずっとコンテキストに載る。
だから、月に一度しか使わないサーバーが8つあれば、その料金を全メッセージで払い続けることになります。
同じ趣旨の助言は、他にもありました。
使うものだけをその場で有効にして、残りは切っておく。
まずコマンドラインで済まないかを考える。
そしてMCPが、置き換える対象より手間がかかるようなら、それは導入する価値がありません。
さらに徹底した人もいます。
決まりきった作業をGoで書いた道具にまとめ、そちらを呼ばせる方式に移行していました。
会話の記録を見返し、どのツール呼び出しが繰り返されているかを洗い出す。
そして、まとめられるものは1回の呼び出しに畳む。
3か月かけて消費量を落としたという報告でした。
その一方で、ファイルシステムへの接続だけは元が取れる、という声もあります。
毎回コンテキストを貼り付ける手間が消える。
それが日々の作業でいちばん効く、という評価でした。
権限で縛るという発想
セキュリティの観点でも、うなずける投稿がありました。
PostgreSQLをつないでいる人の話です。
ただし、あえて権限を削ったロール経由で接続しています。
書き込みを許すのは、記憶用のスキーマだけ。
それ以外は参照とストアドプロシージャの実行のみです。
Claudeはデータベース全体を読めますし、手続きも呼べます。
しかし、本番テーブルには「書くべきだ」と判断しても書けません。
本人の言葉が的確でした。
影響範囲を、プロンプトの指示ではなく権限で決めた。
その途端、いろいろ問い合わせさせることに気が楽になった、と。
関連する報告もありました。
インターネットで拾った設定をそのまま信用する前に、中身を確認する仕組みを作った人です。
手元にどれだけのMCPが入っているのか把握できなくなる。
ある程度使い込んだ人には、共通の悩みのようですね。
まとめ
スレッド全体を通して見えてきたことがあります。
うまくいっている人ほど、AIに何かを新しくやらせているわけではない、という点です。
すでに自分が持っているデータや道具の上に、Claudeを乗せているだけでした。
Home Assistantの人が正直に語っていた通りです。
多くの作業は、以前から可能でした。
変わったのは、手を付けるまでの心理的な距離です。
設定ファイルと格闘する必要がなくなり、思いついた時点で実行できるようになりました。
そしてもうひとつ。
接続の数を誇るフェーズは、すでに終わっているようです。
何を切るか。
どこまで書き込みを許すか。
コマンドラインで足りないか。
その判断のほうが、実際の使い心地を左右していました。
まずは自分が毎日開いているツールを、1つか2つ選んでみてください。
合わなければ、外せばいいだけの話です。
