MCP サーバーとCLIの違い：権限と用途で選ぶ実践ガイド

MCP サーバーとCLI、どちらを選ぶべきですか？

リポジトリ内で作業する開発者なら、まずCLIから始めます。 CLI（コマンドラインインターフェース）は、コマンドで操作するプログラムです。エージェントに承認済みのコマンド実行環境があり、そのツールで作業を完結できるなら、連携を追加しても成果は変わらず、保守の負担だけが増えることがあります。

複数のユーザーに提供するホスト型アシスタントには、強い権限を共有するシェルより、権限範囲を限定したMCPサービスが適しています。 Model Context Protocolは、AIアプリケーションがツールを見つけて呼び出すための標準です。リモートサーバーでユーザーごとの認可を受け付け、アシスタントに必要な操作を公開できます。ただし、その権限を実際に強制する仕組みは別途必要です。

エンジニアリングチームで共有するなら、役割に応じて併用します。 リポジトリの作業はコマンド実行環境に残し、共有の業務操作は呼び出し元の本人確認と権限確認を行うサービス経由にします。

判断軸は、実行環境へのアクセス、認証情報の所有者、対応する操作、モデルに渡す情報量です。プロトコル名は、その後に考えるものです。

本比較の根拠となる開発元のドキュメントは、2026年11月11日に確認しました。記載内容は文書化されたワークフローとアーキテクチャ上の判断であり、ベンチマークや実機検証の結果ではありません。

CLIとMCPは、それぞれどうモデルにつながるのですか？

MCPはエージェントにツールの説明を渡し、CLIは実行するコマンドを渡します。 どちらもモデル単体で操作を実行できるようにするものではありません。モデルが提案した呼び出しを周囲のアプリケーションが受け取り、制御を適用して実行し、結果を返します。

MCPでは、クライアントがサーバーに利用可能なツールを問い合わせます。各ツールには名前、目的、受け付ける項目を定義した入力スキーマがあります。アプリケーションがその定義をモデルに提示すると、モデルはツールを選んで構造化された引数を渡します。MCPのツール仕様はツールの検出と呼び出しを定義していますが、ユーザーとのやり取りの形はアプリケーションに委ねています。

CLIでは、エージェントがコマンド実行ツールを介してインストール済みのプログラムを起動します。一般的なコマンドはすでに知っている場合もありますが、--helpで実際に入っているツールの構文を確認できます。返り値はテキスト、構造化されたJSON、ファイルパスなどです。CLIの出力が非構造化テキストとは限りません。

たとえば「自分が作成した未完了のプルリクエストを一覧にする」という依頼は、引数付きのGitHubツール呼び出しにも、gh pr listコマンドにもできます。どちらも、利用するアカウントに対象のプルリクエストを読む権限が必要です。インターフェースを変えてもアクセス権は増えません。

プロトコルのより広い役割については、MCPとは何かを参照してください。

コンテキスト消費：単純なローカル作業ではCLIが有利です

CLIなら不要なツールの詳細をモデルのコンテキストに入れずに済みますが、コンテキスト消費そのものがなくなるわけではありません。 コンテキストとは、モデルが次の行動を決める際に受け取る情報です。ホストがツールの説明やパラメータのスキーマを含めれば、ヘルプやコマンド出力と同じようにトークンを消費します。

そのため、幅広いツールを持つMCPサーバーでは、実作業に入る前に大量のコンテキストを使うことがあります。ただし重要なのは、ホストがいつツール一覧を読み込むかです。すべてのアプリケーションが、利用可能な全定義を毎回のモデルリクエストに含めるとは限りません。ツール数を絞ったり、必要に応じて検出したりすれば、比較結果も変わります。

CLIでは、最初はコマンド実行ツールの定義だけを渡し、個別ツールのヘルプを必要なときに読み込めます。モデルに返す前にデータを絞ることもできます。プルリクエストの全項目を返して大半を無視させるより、タイトルとURLだけを取得するほうが適切です。

一方、CLIが巨大なログを出力したり、スキルが長いマニュアルを読み込んだりすれば、その利点は失われます。逆に、簡潔な答えを返すMCPツールなら、シェルで何度も調べるより効率的な場合があります。定義、ヘルプ、出力、再試行、そして結果の正しさまで、作業全体で測る必要があります。コマンド文字列が短いだけでは判断できません。

この項目の結論：出力を絞れる日常的なローカル作業にはCLIです。 MCPも、ツールの種類と結果を小さく保てば十分に競争力があります。どちらが何倍のトークンを使うか、一律に言える根拠はありません。

認証と権限：サービスが境界を強制できるならMCPが有利です

エージェントがJSONとコマンド文字列のどちらを送るかより、ユーザーごとの認可が重要です。 OAuthは、ユーザーがパスワードを渡さずにクライアントへ権限を委譲するログインの仕組みです。リモートMCPの構成では、そのユーザーの識別情報に基づいて、アクセスできるアカウント、レコード、操作を判断できます。

複数の顧客組織を支援するサポートアシスタントを考えてみてください。全アカウントを読めるエンジニアの認証情報を渡すのではなく、ログイン中の顧客のレコードだけを取得すべきです。適切に権限範囲を限定したリモートMCPサービスと、管理者権限を共有するシェルの比較なら、サービスを選びます。この2つの実装のうち、MCP側しか許容できない場面です。

もちろん、安全な構成はそれだけではありません。APIに直接連携しても同じ境界を強制できます。また、MCPを加えるだけで境界ができるわけでもありません。MCPの認可仕様では認可は任意とされ、HTTPでの認可フローを定義する一方、環境から認証情報を受け取るローカルSTDIOサーバーと区別しています。

CLIでも、ブラウザログインや権限範囲を限定した認証情報を利用できます。リスクを決めるのは、そのプロセスがアクセスできる認証情報、ファイル、ネットワーク接続先、ほかの実行ファイルです。認証情報を狭く限定したサンドボックス内のコマンド実行環境と、開発者のマシンへの無制限のアクセスは、別の構成として考える必要があります。

この項目の結論：複数ユーザーから権限の委譲を受けるなら、範囲を限定したリモートMCPです。 どちらの経路でも、アカウントと対象オブジェクトの認可をコードで強制し、モデルに見える出力に認証情報を含めず、各操作を誰が認可したかを記録します。

GitHub CLIとGitHub MCP：リポジトリ作業か、サービスへの共有アクセスか？

GitHub CLIはghコマンドで使うクライアントで、チェックアウト済みのリポジトリで動くコーディングエージェントには素直な選択です。 自分が作成した未完了のプルリクエストの要約を作るとします。認証後、リポジトリ内で次のコマンドを実行できます。フラグはいずれも公式に文書化されています。

gh pr list --author "@me" --json number,title,url

このコマンドは、要約に必要な項目だけを要求します。CLIは--jqにも対応しており、モデルに渡す前にJSONを絞れます。具体的に使えるコンテキスト節約策ですが、ここでトークン数のベンチマークを主張しているわけではありません。

CLIの制約を決めるのは、それを動かす実行環境です。手元のPCで動くコマンドが、すべての従業員や顧客に適したインターフェースとは限りません。GitHub CLIのログインマニュアルによると、ブラウザログインでは通常、システムの認証情報ストアにトークンを保存し、それが使えない場合はプレーンテキストにフォールバックします。「ローカルだから隔離されている」と考えず、実際の認証情報の扱いを確認します。

GitHub公式のツールサーバーであるGitHub MCP Serverは、MCP経由でリポジトリ操作を必要とするアシスタントに適しています。 同じ要約を作る場合は、関連するプルリクエストのツールを公開し、対象ユーザーの認可を使って、そのユーザーの未完了リクエストを取得させます。GitHubはリモートサーバーをホストしており、ローカルで動かす選択肢も提供しています。

GitHubは、ツールセットや個別ツールの選択に加え、書き込みツールを除外する読み取り専用モードを文書化しています。リモートのOAuth対応も、ホストアプリケーションが適切なGitHub AppまたはOAuth Appを設定することが前提です。通信方式が対応しているだけでは、認証の問題は解決しません。

この組み合わせの結論： 開発者向けの要約やリポジトリ内のスクリプトにはghを使います。必要な認証フローにクライアントが対応している共有アシスタントにはMCPが適しています。どちらもリポジトリの権限設定に代わるものではありません。MCPのツール数を絞れば、分かりやすさとコンテキスト効率の両方を改善できます。

Playwright CLIとMCP：コーディング作業か、探索的なブラウザ操作か？

Microsoftが提供するブラウザ操作用のコマンドインターフェース、Playwright CLIは、Webの変更を確認するコーディングエージェントの基本の選択肢です。 開発元は、コマンドなら大量のスキーマやページ情報をコンテキストに読み込まずに済むことから、コーディングエージェントにはCLIとスキルの併用を推奨しています。これは開発元の設計指針であり、本記事で速度を計測した結果ではありません。

開発者がフォームを確認するなら、ページを開き、必要な要素を調べ、操作して、結果を確認する流れになります。操作のたびにページの全情報を読み直す必要はありません。

playwright-cli install：まずは開発元のコマンドで始めます

文書化されているインストール方法と、ページを読み取るだけの確認手順は次のとおりです。

npm install -g @playwright/cli@latest
playwright-cli --help
playwright-cli open https://playwright.dev
playwright-cli snapshot
playwright-cli close

このコマンド群は公開ページを調べるもので、テストスイートではありません。取得したスナップショットで対象を特定してから、自分のアプリケーションに対する操作を追加します。

Playwright CLIのスキル：作業手順を追加します

CLIのインストール後に使う、文書化されたスキル用コマンドはこちらです。

playwright-cli install --skills

注意したいのは、実行可能な環境、適切なブラウザセッション、成功条件を定める指示を自分で用意する必要があることです。スキルは手順を支援しますが、実際の顧客取引が認可されているかどうかを判断するものではありません。

MicrosoftのブラウザツールサーバーであるPlaywright MCPは、探索を繰り返す中で、ページを構造的に調べることがMCPクライアントに役立つ場合に適しています。 ページ要素を構造化して記述したアクセシビリティスナップショットを使い、ブラウザ操作を支援します。

制約は2つあります。まず、ブラウザ状態の保持はMCPだけの機能ではありません。Playwright CLIも、同じセッション内の呼び出し間でCookieとストレージを保持し、ブラウザの再起動をまたぐ永続プロファイルも提供しています。また、MCPのリポジトリは、サーバー自体はセキュリティ境界ではないと明記しています。オリジン制御についても、その境界を提供するものではなく、リダイレクトにも影響しないと注意しています。

この組み合わせの結論： コーディングの流れの中で行う日常的な確認にはCLIとスキルを使い、ブラウザツールを介した操作がクライアントと作業に役立つならMCPを選びます。セッション状態を保持したいという理由だけで切り替える必要はありません。MCPを使う方法は、Playwright MCPの設定とブラウザテストのガイドで詳しく説明しています。

Stripe CLIとStripe MCP：Webhook開発か、アカウント操作か？

StripeのターミナルツールであるStripe CLIは、決済連携の開発とデバッグに適しています。 代表的な作業は、Stripeで何かが起きたときに送信される通知、Webhookイベントを、ローカルで動くアプリケーションで受信することです。CLIでは、イベントを受信・転送するstripe listenと、サンプルイベントを生成するstripe triggerが文書化されています。

この作業はサンドボックス内で行います。イベントのトリガーはAPIオブジェクトを作成し、追加のイベントを発生させることがあります。サンプルのペイロードを表示するだけではありません。また、CLIはAPI操作やリクエストログの確認にも対応しており、Webhookの転送以外にも役立ちます。

認証についても、「CLIならAPIキーをコピーする」と単純には言えません。Stripeは、ユーザーごとのブラウザログイン、利用可能な場合のローカルでの安全な認証情報の保存、セッションの更新、アクセスの取り消しを文書化しています。開発者には適した構成になり得ます。ただし、ホスト型アシスタントでCLIを選ぶなら、ユーザーごとに実行環境と認証情報を分離する方法が必要です。

エージェント向けのサービスインターフェースであるStripe MCPは、ローカルのコマンド実行環境を持たない対応アシスタントから、アカウントを操作する場合に適しています。 たとえば、権限を持つ担当者が、必要なStripe APIデータを検索して読み取るようアシスタントに依頼できます。サーバーは操作ごとのツール定義を要求する代わりに、API検索、パラメータの確認、読み取り、書き込みのツールを提供します。

Stripeは、ユーザーに代わってアクセスするためのOAuthと、独立してアクセスするためのエージェントAPIキーに対応しています。汎用のstripe_api_writeツールは、多くの操作をカバーできます。Stripe側で人による確認が必要かどうかは操作によって異なり、クライアント自身のツール承認設定とは別です。したがって、ツールのカテゴリを承認することと、そのツールで実行可能なすべての業務操作を承認することは同じではありません。

この組み合わせの結論： ローカルでのWebhook開発にはCLI、アシスタント内で権限の委譲を受けて行うアカウント作業にはMCPです。コマンドやツールの数ではなく、必要な操作を比較します。アカウントデータを読むMCP接続は、開発中に使うローカルのWebhookリスナーの代わりにはなりません。

MCPとスキルの違い：手順は別のレイヤーです

スキルは作業の進め方を伝え、MCPとCLIは操作する手段を提供します。 Agent Skills形式では、SKILL.mdファイルに名前、説明、作業の指示を記述し、必要に応じてスクリプトや参照ファイルを添えます。エージェントはまずメタデータを見つけ、必要になったときに詳しい指示を読み込みます。

MCP、CLI、スキルを比較するなら、CLIとスキルの組み合わせが有用なことがよくあります。CLIが操作を実行し、スキルは使うコマンド、選ぶ環境、確認する証拠、終了条件を指定します。スキルはMCPツールを使うエージェントにも同じように指示できます。

プルリクエストの要約なら、未完了のものだけを対象とし、必要な項目を絞り、報告中のコメント投稿を禁止する、といった内容をスキルに書けます。ただし、実際のアクセス境界は認証情報と実行環境で強制しなければなりません。文章の指示は適切な行動を助けますが、権限を取り除くものではありません。

この項目の結論：繰り返し使う手順にはスキルです。 どちらのインターフェースも補完でき、読み込めばスキル自体もコンテキストを使います。

MCP・API・CLIの比較：サービスのロジックを一元化します

業務ルールをサービス側に置き、ユーザーに必要なインターフェースを公開します。 APIはアプリケーションをプログラムから操作するための窓口です。Stripeの各インターフェースが示すように、CLIからもMCPサーバーからも呼び出せます。

両方を保守するなら、認可や検証を共通化し、「誰がこのレコードを変更できるか」を別々に実装しないようにします。プロトコルのレイヤーを追加する価値がある場面は、MCPとAPIの比較で説明しています。

任意のシェル文字列を受け付けるラッパーは、移行の十分な理由になりません。既存のコマンド実行環境をMCP経由で呼び出せるようにはなりますが、実行環境の権限はそのままです。有用なアダプターは、範囲を限定した操作を公開し、入力を検証し、エージェントに必要な証拠だけを返します。

選択早見表：導入環境に合わせて選びます

権限を広げずに作業を完結できる、最小限のインターフェースを選びます。 以下は出発点となる構成であり、ずっと同じ方式に固定するためのものではありません。

MCPからCLIへ、またはCLIからMCPへ移行するには

ツール一式ではなく、ワークフロー単位で移行します。 負担が大きいのは、ツール名をコマンドに置き換えることより、権限、出力、失敗時の処理を維持することです。

CLIへの移行では、インストール、認証情報、コマンド実行環境、出力の絞り込み、再現可能な手順を整えます。MCPへの移行では、サーバーを選択または運用し、クライアントの認証を設定し、公開ツールの範囲を定め、そのインターフェースでのエラー処理を用意します。ブラウザを使うワークフローでは、セッションとプロファイルを誰が所有するかも明確に決める必要があります。

正常に動いているCLIのワークフローを、プロトコル対応を加えるためだけに切り替える必要はありません。コマンドのほうが短く見えるからといって、シェルを使わない人に提供しているリモートMCP連携を取り除くべきでもありません。

エージェントのワークフローの選び方や権限範囲の定め方に関する実践ガイドは、ニュースレターでもお届けしています。

よくある質問