MCPとは。AIが外部サービスを使う共通の窓口と、CLIとの違いを整理

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。「まだ対応していない重要な問い合わせを、一覧から探して、担当者ごとにまとめて。」AIにそう頼むと、AIは社内の問い合わせ管理システムをどうやって調べるのか。今回は、その答えにあたるMCPとCLIという二つの方法を整理します。出典はHiraokuさんの技術記事。2026年7月28日版で変わったことも取り上げます。

この記事は、私が保存したブックマークの一つです。重ねて読んだのは、私のブログの二つの言葉。「確かめることと、変えることは、別の承認として分けておきます」と「つなげば動く、とは限らない」です。

読み方の筋は、次の順。MCPとは何かから始めて、CLIが支持された理由、不満は仕様かアプリ設計か、7月28日版の変更と確認の再要求、仕様が直さないもの、コードでの加工、クラウドでの配置、使い分けの目安とAIに頼む線へ進みます。

Hiraokuさん（hiraoku.dev）の記事『MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更』（2026年11月7日公開）より・第1章で引く部分

そのアプリと外部サービスのつなぎ方を共通化するのが、MCP（Model Context Protocol）です。

つまりMCPは、AIが外部サービスを使う共通の窓口です。AIアプリと外部サービスのつなぎ方を、共通の形にそろえる決まり。

例で見ます。AIに「まだ対応していない重要な問い合わせを一覧から探して、担当者ごとにまとめて」と頼む場面です。

モデルは依頼の意味が分かります。でも、それだけでは社内の問い合わせシステムを検索できません。検索するプログラムを呼んで、結果を受け取る必要があります。

ここでAIモデルと、それを使うアプリを分けます。ChatGPTやClaude Desktopのようなアプリを、この記事では「AIアプリ」と呼びます。

モデルが選んだ操作を呼び出して、結果をモデルに返すのがアプリの役目。

MCPでは、問い合わせサービスが「search_tickets」という操作を公開します。状態や優先度を条件にして、取得件数も指定できます。公開するのはサービス側。取得して呼ぶのはアプリ側です。

MCPの用語では、アプリ全体をホストと呼びます。アプリの中でMCPの通信を担当する部分がクライアント。操作を公開する側がサーバー。

既存のAPI（サービスが外に向けて開けている窓口）を置き換える必要はありません。その手前に共通の窓口を置く仕組みです。

Hiraokuさんが2026年11月7日に公開した記事は、MCPへの批判が出てCLIが支持された時期があり、そこから再評価されるまでの流れを整理しています。

記事の冒頭には、@trq212 さんのXの投稿が置かれています。

Hiraokuさんの紹介では、投稿者は「予想していなかった」としながら、多くの統合でCLIよりMCPのほうがよいと考えるようになった、と述べています。理由は3つ。まず、モデルのツール呼び出し能力です。

次に、ツール定義（使える操作の説明書き）の遅延読み込み（必要になるまで読み込まないこと）。最後に、MCPのステートレス化（過去のやりとりに頼らず、要求ごとに必要な情報を添える作り方）です。

データの組み合わせや絞り込みには、queryのような引数（操作に渡す条件）を用意すればよい、とも書いているそうです。

私はこう受け取りました。窓口が共通になると、アプリごとに専用のつなぎ込みを作る手間が減ると考えます。

Hiraokuさん（hiraoku.dev）の記事『MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更』（2026年11月7日公開）より・第2章で引く部分

CLIが支持されたのは、古い技術への郷愁からではありません。説明を読む量、処理の自由度、既存資産の再利用が、エージェントの仕事に実用的だったからです。

MCPへの期待は、一度サービスを対応させれば互換性のあるアプリから使えることでした。ところが、ツールが増えると問題が目立った。

問い合わせを検索したいだけなのに、大量のツール定義（使える操作の説明書き）をモデルへ渡してしまいます。作成や更新、添付や利用者管理の操作まで。

検索結果にも不要な項目が返り、コンテキスト（AIが一度に読める作業用のメモ帳のようなもの）が埋まっていきます。一方、コーディングエージェントは、既存のCLIやコード実行環境で同じ仕事を進められました。

Mario Zechnerさんは2025年11月の記事で、少数のCLIとコードで処理するほうがよい、という考えを示しています。

Peter SteinbergerさんもLex Fridmanさんとの対談で、出力をjq（データから必要な項目だけを取り出すコマンド）で絞る利点を話している。Hiraokuさんの紹介です。

CLIの例を見ます。未対応の問い合わせを取り、jqで優先度の高いものだけを選ぶ。IDと件名と担当者だけに絞ります。最後の出力だけをモデルに返すなら、途中の大きなデータはコンテキストに入らない。

詳しい使い方は「–help」で必要なときに読めます。

とはいえHiraokuさんは、正確に使うには説明が要る、CLIなら読む量が増えない、というわけではない、とも書いています。利点は、説明を必要な時点まで後回しにしやすいこと。

市場全体でMCPが減ったことを示すものでもない、と断っています。

AI氣道『Tailscaleのセキュリティ確認方法｜初心者が設定を変えずに調べる5項目』より

「確かめることと、変えることは、別の承認として分けておきます。」

読むだけの確認を、変える操作と分けて承認する考えを、私は『Tailscaleのセキュリティ確認方法｜初心者が設定を変えずに調べる5項目』で書いています。

2026年10月28日、私はAIに頼んで、自分のMacに入っているTailscaleを確かめました。設定は一つも変えず、読むだけです。確かめられたのはMac1台だけ。

CLIで読むだけの操作をAIに渡す向きと同じだと読みました。私なりの言い方は、こう。読むだけの操作と変える操作を分けると、AIに任せる範囲が決めやすいと考えます。

Hiraokuさん（hiraoku.dev）の記事『MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更』（2026年11月7日公開）より・第3章で引く部分

まず、全ツール定義を一括で提示する実装では、使わない機能の説明までコンテキストに入ります。次に、ツールの結果を毎回そのままモデルへ返す実装では、中間データも大量に入ります。

先に結論です。使わない操作の説明が多いことや、結果が大きすぎることは、MCPで必ず起きる問題ではありません。ホスト（AIアプリ全体のこと）やツールの作り方による部分が大きい、ということです。

Hiraokuさんは、従来のMCPの不満を3つに分けて整理しています。

1つ目は、使わない操作の説明までAIが読むこと。原因は全ツール定義を最初に見せる実装。直す場所は、AIアプリ側のツール選択と遅延読み込みです。

2つ目は、大量の検索結果や中間データが入ること。原因は結果をそのままモデルへ戻す実装。直す場所は、ツールの検索引数（操作に渡す条件）と、実行環境での加工です。

3つ目は、サーバーを増やすと通信管理が複雑になること。

原因は、初期化（やりとりを始める前に、互いの版や使える機能を取り決める手順）で決めた情報や、セッション（やりとりの間つなぎ続ける状態）への依存です。直す場所はプロトコルとサーバーの設計です。

旧仕様には初期化のやり取りがあり、HTTP（ウェブの通信の決まり）でセッションを使う構成もありました。利用者のPCで単純に呼ぶ場合は、意識しにくい。

多数の利用者を複数台のサーバーで処理する側には、通信状態を管理する負担があったんです。

ここが大事です。7月28日版に更新しても、問い合わせ検索で返す件数や項目は、それだけでは変わりません。モデルに渡す量を減らすには、工夫が要る。

検索条件で件数を絞ったり、取得したデータから必要な項目だけを取り出したりします。

一方、今回の仕様変更は、初期化とプロトコル上のセッション管理を不要にします。複数のサーバーへ処理を振り分けやすくなる。通信規約そのものを見直して、状態を管理する負担を減らす整理です。

私の読みです。あなたが「MCPは重い」と聞いたら、それが仕様の話か、アプリやツールの作りの話かを、まず切り分けると整理しやすいかなと思います。

Hiraokuさん（hiraoku.dev）の記事『MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更』（2026年11月7日公開）より・第4章で引く部分

ステートレス化は「何も保存しない」ことではありません。過去の接続や暗黙のセッション情報に依存せず、要求に必要な情報を明示する、という意味です。

Hiraokuさんによると、2026年7月28日版は、直前の2025年11月25日版から通信の基本構造を変えました。機能を足すだけではない。初期化やセッションを取り除き、要求と応答を中心に組み直した版です。

旧仕様では、まず「initialize」でプロトコルの版や対応機能を取り決めました。初期化完了の通知を送ってから操作する流れ。ハンドシェイク（握手。やりとりを始める前の取り決め）にあたります。

HTTPでは、サーバーが「Mcp-Session-Id」（やりとりごとの目印の番号）を任意で発行できた。必ずセッションの保管場所が要ったとは言えない、とHiraokuさんは注意しています。

新版では、この初期化のやり取りがなくなりました。代わりに、各要求が「_meta」（要求に添える付随情報の欄）に、プロトコルの版とクライアントの対応機能を入れます。

HTTPのMcp-Session-Idも撤去されました。

公式の変更履歴も確かめました。書かれていたのは、プロトコル上のセッションとMcp-Session-Idの撤去、ステートレス化、_metaに版と能力を載せること。

効くのは分散です。次の要求を別のサーバーが受け取っても、前のサーバーから初期化の情報を引き継ぐ必要がありません。MCPを普通のHTTPサービスに近い感覚で、複数台に分けやすくなります。

業務上の状態は残ります。買い物かごを作ったら、後の呼び出しに「basket_id」を渡して参照します。かごの中身はデータベースや既存の業務サービスで管理する。保存方法をMCPが決めるわけではありません。

事前にサーバーの対応版や機能を確かめたいときのために、「server/discover」が新しく加わりました。サーバーは実装しなければならない。クライアントが操作の前に必ず呼ぶ必要はありません。

初期化が名前を変えて戻ってきたわけでもない、ということです。

ここは私の見立てです。前もっての約束事が減り、要求ごとに必要な情報を添える形になったと考えます。

Hiraokuさん（hiraoku.dev）の記事『MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更』（2026年11月7日公開）より・第5章で引く部分

ポイントは、担当者が回答する前に、1回目の要求への応答を返せることです。

Hiraokuさんの例です。カスタマーサポートの担当者が、顧客から届いた20件の質問に返信を終えました。あとは、問い合わせ管理システムの20件の記録を「対応中」から「対応済み」へまとめて変えたい場面。

担当者はAIアプリに「この20件を対応済みにして」と頼みます。アプリは記録のIDを指定して、MCPサーバーへ変更を要求する。この例では、サーバーが実行前に確認を求めます。

サーバーはこの時点では記録を更新しません。「この20件を対応済みにしますか」という質問を応答に入れて返す。アプリが質問を担当者に見せる。

「はい」を受け取ったら、同じ20件の変更を回答とともに再要求（同じ依頼に回答を添えて送り直すこと）します。更新されるのは、再要求を受けたあとです。回答や権限を確かめてから更新します。

この方式をMulti Round-Trip Requests、略してMRTRと呼びます。

確認の機能（Elicitation。サーバーがアプリ経由で利用者に質問する機能）にアプリが対応している必要がある。

仕様上は、確認が必要という応答を「input_required」、完了を「complete」で表します。公式の変更履歴にも、MRTRの導入が書かれていることを確かめました。

CLIにも確認はあります。MCPでは、「追加入力が必要」という共通の形をアプリが受け取ります。自分の画面に合った方法で、担当者へ質問を出せる。実行前の回答や権限の確認は、サーバー側で引き続き必要です。

長い処理は、別の仕組みで扱います。大量の記録をCSV（表計算ソフトで開ける、カンマで区切ったデータの形式）に書き出すような処理では、Tasks拡張が受付番号のようなタスクIDを先に返します。

ツール一覧などの結果には、「ttlMs」（再利用してよい時間の目安。ミリ秒）が付きます。300000なら5分です。

AI氣道『Agent Skillsとは。業務手順書の設計8つのコツを風音屋の記事で整理』より

「AIが文面を本人に見せ、本人が承認してから送ります。」

外に出る操作の承認は人が持つ、という向きを、私は『Agent Skillsとは。業務手順書の設計8つのコツを風音屋の記事で整理』で書いています。

確認が必要と返して回答を待つMRTRは、この向きと同じだと読みました。

こう整理しています。あなたの仕事でも、変える操作の前に人が確認する線を、先に決めておくと進めやすいかな。

Hiraokuさん（hiraoku.dev）の記事『MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更』（2026年11月7日公開）より・第6章で引く部分

遅延読み込みや検索引数は、それを利用するアプリやツールが実装します。モデルの能力向上は、MCP仕様を読んでも証明できません。

整理すると、投稿が挙げた変化のうち、7月28日版の仕様が直接変えたのはステートレス化だけです。ほかは、アプリやツールが作り込む部分。

遅延読み込みは、AIアプリが取得したツール定義を保持しておく工夫です。最初から全部を渡さず、「問い合わせを検索する」仕事に必要な定義だけをモデルに見せる。

公式ガイドではProgressive Tool Discoveryと呼ばれています。ツールが少数なら、一括で渡すほうが単純です。

検索引数は、search_ticketsに、状態や優先度で絞る条件と、取得する項目や件数を渡せるようにする設計です。不要な問い合わせや長い本文を、モデルへ送る前に除ける。

投稿の「queryのような引数」はこの設計を指します。queryという共通の言葉がMCPに加わったわけではありません。

投稿の4つの主張のうち、モデルの能力向上は、MCPの仕様を読んでも確かめられない、とHiraokuさんは書いています。新しい仕様へ更新するだけで、すべてのやり取りが変わるとは言えません。

ほかに、Roots（作業に関係するファイルやフォルダを伝える機能）とSampling（AIアプリ側のモデルに文章生成を頼む機能）が非推奨になりました。

Logging（サーバーの記録をMCP経由で送る機能）も同じです。非推奨は、今の仕様には残るものの、新しく採用するのは避ける段階。

新版の方式だけに対応したサーバーは、旧版の初期化を前提にするクライアントを扱えません。一つの窓口で新旧の両方を出す方法もあります。

AI氣道『Claude Codeで会員データベースをつなぐMCPと、使いながら直す修正ボタンを動画の相談から整理する』より

「つなげば動く、とは限らない。受講生の画面で確かめて、初めて詰まりが見えました。」

つなげば動く、とは限らないという詰まりを、私は『Claude Codeで会員データベースをつなぐMCPと、使いながら直す修正ボタンを動画の相談から整理する』で書いています。

AIに頼んでUTAGEのMCPで講座のレッスンに動画を入れたとき、video_id（動画の番号だけを入れる欄）だけだと受講生の画面で1本中0本でした。

video_url（動画の完全なURLを入れる欄）に完全なURLを入れると、1本中1本が立ち上がりました。測ったのもAIです。

私の読みです。仕様が直す所と直さない所を分けて読み、更新したあとも使う人の画面で確かめる向きだと考えます。

Hiraokuさん（hiraoku.dev）の記事『MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更』（2026年11月7日公開）より・第7章で引く部分

すべての結果をモデルへ返して一件ずつ処理させる代わりに、ホストの実行環境でツールを呼び、コードで突き合わせる構成を取れます。

例で見ます。問い合わせの担当者の所属部署を、別のサービスから取って突き合わせたい場面です。モデルは、突き合わせの処理をするコードを作ります。ツールを呼ぶのも、そのコードを動かすのも、実行環境の側。

問い合わせの検索、所属部署の取得、結合（二つのデータを同じ項目でつなぐこと）、集計を進めます。最後に、担当者別の件数など必要な結果だけをモデルへ返します。

これはCLIのパイプ（コマンドの出力を次のコマンドへ渡す仕組み）と同じ考え方です。途中の大きなデータを、モデルのコンテキストに通さずに済みます。CLIの例で見たjqの絞り込みと、狙いは同じ。

Anthropicは2025年11月4日に、この設計を紹介しています。7月28日版で初めて可能になったものではありません。ただし、楽になるだけの話でもない。

コードを動かす実行環境の隔離（ほかの処理と切り離して動かすこと）と、各呼び出しの認可（誰にどこまで許すかの確認）は必要です。

データを組み合わせる自由度がほしい場面でも、必ずCLIを選ぶ必要はない、ということです。

Hiraokuさん（hiraoku.dev）の記事『MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更』（2026年11月7日公開）より・第8章で引く部分

リモートMCPでは、ツールの実装や依存関係をサーバー側で管理し、エージェントはHTTPで接続します。

Hiraokuさんの整理では、手元のPCのエージェントは、入れてあるCLIと、設定ファイルや作業フォルダを使えます。

ビルド（プログラムを動かせる形に組み上げる作業）やファイル加工のような手元の仕事は、この環境で完結しやすい。許可された認証情報があれば、コマンドを実行するだけで仕事を始められます。

CLIの手軽さは、この準備済みの環境に支えられています。

タスクごとに起動する短命なコンテナ（実行環境を一式まとめた入れ物）でエージェントを動かすなら、必要なCLIと依存関係（動かすのに必要な部品）をそこへ用意します。

使うサービスが増えるほど、CLIの版や設定の管理も増える。事前にイメージ（環境をあらかじめ作り込んだ雛形）へ組み込む方法はあります。CLIが不利で不可能という話ではない。

リモートMCPなら、ツールの実装と依存関係をサーバー側で管理し、エージェントはHTTPで接続します。各エージェントにサービス専用の実行プログラムを配る負担を減らせる。

認証や認可（誰にどこまで許すかの確認）が不要になるわけではありません。CLIでも、資格情報（ログインに使う鍵のようなもの）を外部の管理基盤から受け取れます。

7月28日版のステートレス化で、サーバー側は、どのサーバーで要求を処理するかをセッションに縛られず決めやすくなりました。それでも、エージェントが再起動しても作業が自動で戻るわけではありません。

作業履歴の保存は、エージェント側で考える。

GitHubは2026年10月28日、検証済みのMCPサーバーを「コネクター」（外部サービスへの接続設定をまとめたもの）として使えるパブリックプレビューを発表しました。Hiraokuさんの紹介です。

7月28日版への対応を示す発表ではありません。

Hiraokuさん（hiraoku.dev）の記事『MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更』（2026年11月7日公開）より・第9章で引く部分

手元のビルドやファイル加工には既存のCLI、複数のAIアプリから使う業務サービスの接続にはリモートMCP、という使い分けが一つの目安です。

ただし、すべてのコマンドをMCPへ置き換える必要はありません。CLIを捨てる話でもなく、MCPだけにする話でもない、ということです。既存のCLIをMCPサーバーの内部から呼ぶ構成もとれます。

人間とシェル（コマンドを打つ画面のこと）にはCLI、外部のAIアプリにはMCPを出す、という分け方です。

選ぶ目安は、使う場所です。手元のビルドやファイル加工には、今あるCLIで足ります。複数のAIアプリから使う業務サービスの接続なら、リモートMCPが合います。

迷うときは、手元で動かしたい仕事か、複数の環境から使う仕事かを先に分けます。接続先の対応状況も確かめたうえで、MCPを有力な候補として評価する。決めるのは、そこからです。

ここからは私の読みです。あなたが使っているAI連携を、書き出す。

手元で完結するもの（ファイルの加工や、プログラムを動かせる形に組み上げるビルドなど）と、複数の人や環境から使うもの（問い合わせ管理や会員データなど）に分ける。

この仕分けをAIに手伝ってもらうなら、「確認だけ、整理だけ。変更や送信はしない」と書いて頼みます。読み取りだけに絞る、ということです。

AI氣道『ChatGPT Dotsに任せる前に決めたい、承認の線と仕事の持ち主』より

「AIにどこで承認を求めさせるか、その線は動かす前に文章にしておく。」

承認を求める線を、動かす前に文章にしておく考えを、私は『ChatGPT Dotsに任せる前に決めたい、承認の線と仕事の持ち主』で書いています。

クラウドで複数の環境から使うときの、権限と承認の線の話にも、この向きは通じると読みました。

MCPは、AIが外部サービスを使う共通の窓口。AIアプリが外部サービスの操作を共通の形で取得して呼ぶ決まりです。CLIは、文字でコマンドを打ってプログラムを動かす方法。Hiraokuさんは、CLIが支持された理由を二つに整理しています。必要な説明だけ読めること。結果を絞ってからAIへ返せること。そこに、人間も同じコマンドで再現できることが加わります。

2026年7月28日版で変わったのは、初期化とプロトコル上のセッションの撤去、確認が要る操作の再要求、ttlMsによる再利用の目安などです。変わっていないのは、必要なツール定義だけ見せる工夫と、結果の加工。ここはアプリとツールの側の仕事です。

そこで、あなたの仕事のAI連携を二つに分けてみます。手元で完結するものと、複数の人や環境から使うものです。分けたら、それぞれに何を使うかを1行で書く。これが、この記事の読み終わりの形かなと思います。

元の記事と公式の変更履歴は、リンク先で全文を読めます。細かい仕様は、使うAIアプリとサーバーの対応状況とあわせて、手元で確かめて進めてください。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！