メインコンテンツへスキップ メインコンテンツにスキップ
MCPの使いどきを考える 後編 : MCPの使い所見定めていきまっしょいという話
MCP

MCPの使いどきを考える 後編 : MCPの使い所見定めていきまっしょいという話

目次

前編のまとめ

前回の記事では、PlaywrightのMCPサーバであるplaywright-mcpを使ってみたときの気づきについて書きました。

その中でのまとめとして以下のことを述べていました。

  1. playwright-mcpは「スクリプティングが面倒なときか、スクリプティングの知見がないとき」に便利っぽい
  2. MCP・CLI・APIベースのスクリプティングなど、アプリケーションへのアクセス手段は多分使い分けるものっぽい
  3. その使い分けは利用者の能力・用途・アプリ側のインターフェースの実装や複雑さなどの要素によって、適切な選択がケースバイケースで変わるっぽい

今回は3番目のポイントに注目し、どのような要素でインターフェース選択が決まるのかを掘り下げていきます。

インターフェース選択を決める要素

アプリケーションへの主なアクセス方法には従来GUI、CLI、APIがありました。

ここにLLMを利用してアプリケーションにアクセスする、MCPという新しい方法が登場したわけです。さて、どう使い分けていけばいいだろうか？ というのが今回のテーマになります。

自分の現在地点では、アプリケーションへアクセスするインターフェースを選ぶ際の主要因として以下の3つの要素があるんじゃないかという仮説を持っています。

  1. ユーザースキルと知識レベル
  2. タスクの頻度と複雑さ
  3. アプリケーション自体の設計・特性

順に見ていこうと思います。

1. ユーザースキルと知識レベル

まず、使う人のスキルや知識によって最適なインターフェースは大きく変わるでしょう。例えば、以下のようなことが言えそうです。

  • プログラミング初心者: GUIが最も直感的に使える。MCPは自然言語で指示できるため次に使いやすい。CLIやAPIは学習コストも含めて難易度が高い
  • スクリプティングには慣れているが、そのアプリケーションのCLI/APIに詳しくない人: MCPを使うことで、CLI、APIなどの仕様を覚える手間を省ける
  • ベテラン開発者: APIやCLIを直接使う方が細かい制御ができて効率的なことが多い

Playwrightを例に取ると、普段プログラミングをしないQAエンジニアがテスト自動化を行うなら、Playwrightを使ってコードを書くよりplaywright-mcpを使った方が断然効率的でしょう。

対してSETでバリバリPlaywright触ったことありますという人であれば、MCPを使わなくてもスクリプティングした方がいいかもしれません（当初自分はこっち寄りの視点しか持ち合わせていませんでした）。

その中間、プログラミングはできるけどPlaywrightは知らない、という人であれば、MCPから触って要領をつかみ、必要ならコーディングエージェントを使ってスクリプティングするというアプローチを取るのがベストな気がします。

このように、対象となるアプリケーションへの理解度や、素地となるプログラミングスキルによって、何を使うべきかが変わってきそうです。

2. タスクの頻度と複雑さ

また、そのタスクをどれだけの頻度で実行するか、そのタスクの複雑さはどれくらいかも重要な要素でしょう。

  • 一回きりの簡単なタスク: GUIで手作業が速い
  • 一回きりだが複雑なタスク: MCPが自然言語で複雑なロジックを表現できて便利
  • 繰り返し行う定型タスク: APIやCLIを使ったスクリプト化が最適
  • 頻度は低いが複雑で重要なタスク: 再現性を考えるとスクリプト化すべきだが、MCPで半自動化も選択肢

前回の例で言えば、JSTQBのシラバスの最新版だけを一度取得するという、「一回きりだが少し複雑」なタスクにはMCPが最適でした。

対して、仮にE2Eのリグレッションテストを書くという場合であれば、出力が安定しない可能性のあるLLMベースのMCPを毎回呼び出すよりもスクリプトを書いた方が妥当なことが多そうです。

微妙なラインなのは「頻度は低いが複雑で重要なタスク」、思い当たるのは監査とかの類のタスクですが、これは恐らく理想論ではスクリプト化すべきなものの、実装コストが高すぎてMCPで妥協するとか、そういった判断も必要になりそうな気がしています。

3. アプリケーション自体の設計・特性

最後に、アプリケーション自体の特性もインターフェース選択に影響するはずです。

  • 優れたCLI/APIがある場合: 直接CLI/APIを使うのが効率的
  • CLI/APIはあるが複雑・ドキュメント不足だったり、そもそもCLIやAPIがない・限定的な場合: MCPを使うと翻訳レイヤーとして機能する可能性がある

例えばGitHubはCLIが優秀で、大抵のことはCLIで実現できます。別にMCPを使わなくてもよいと思うことは多いです。

他方で、JiraやConfluence、Notionに関してはMCPを使いたくなります。

恐らく、バックログ管理アプリやドキュメンテーションアプリの類は、そのアプリでユーザーが本当にやりたいことと、CLIやAPIが提供する機能に乖離が生まれやすいのかもしれません。このプロジェクトの要約してくれ、なんてコマンドは基本的に作りようがないですからね。

この問題は暫定的にMCPで、将来的にはアプリのエージェント化によって解決されるのかな、とも考えています。

4. その他の副次的な要素

自分が検討した上記の3要素に加えて、以下の要素もインターフェース選択に影響するかもしれない、とClaudeくんが教えてくれました。

  • セキュリティと権限の要件
    • 高度なセキュリティ・認可が必要な場合はCLIやAPI経由のアクセスの方が細かい制御が可能
    • MCPは現状セキュリティがガバガバ
  • パフォーマンスとリソース・コスト効率
    • 大量データの処理ではAPIを利用するのが効率的
    • MCPはLLM処理のオーバーヘッドがある上、APIコールすれば実費も発生しうる
  • 既存ワークフローとの統合性
    • CI/CDパイプラインに組み込むならAPIやCLIが適合しやすい
    • 単発実行ならMCPの方が楽なことも多い
  • ドキュメントとコミュニティサポート
    • ドキュメントが充実したAPIは直接使いやすい
    • ドキュメントが不足している場合はMCPが逆に有利

まとめ：MCPの適材適所を考えて使いこなす

  1. playwright-mcpは「スクリプティングが面倒なときか、スクリプティングの知見がないとき」に便利っぽい
  2. MCP・CLI・APIベースのスクリプティングなど、アプリケーションへのアクセス手段は多分使い分けるものっぽい
  3. その使い分けは利用者の能力・用途・アプリ側のインターフェースの実装や複雑さなどの要素によって、適切な選択がケースバイケースで変わるっぽい

後編では3「アプリケーションのインターフェースの使い分けは大きく3つの要素（ユーザースキル、タスクの目的、アプリの設計）で決まる」という仮説を展開しました。

ここで自分の気付きの2「アプリケーションへのアクセス手段は多分使い分けるものっぽい」に立ち戻るのですが（文章構成完全に間違えた）、一番重要なのはアプリへの複数のインターフェースを適切に組み合わせて利用することなんだと思います。

MCPは便利ですが万能ではないです。それぞれのインターフェースの特徴を理解し、使い所を見定めましょうということですね。

しかし今回の仮説が提示するところは、MCPの使い所は利用する人のスキルや目的、使うアプリによってケースバイケースに異なるということを意味しています。

一概に「誰にとってもこれが常に正解だ」とは言い切ることはできない、これが重要な示唆です。

突き詰めると、結局のところ「自分自身の能力や目的に照らし合わせて適切な手段を選ぼう」という、言われてみれば当たり前のところに帰着するのかもしれません。

しかしAIが実装はほとんどやってくれる時代において、ITエンジニアにはこうした本質的な意思決定や問題解決力が求められてくるのかもしれませんね。

と、うまくまとめた感じを出して、今回はこの辺で逃げようと思います。ではまた。

ブログ一覧に戻る