"MCP vs CLI" AIエージェントが使うにはどちらが優位か

 こんにちは、横井です。

先日の投稿で「エージェンティックな機能より、エージェントフレンドリーな機能」という話しを書きましたが、Saasプロバイダーは具体的な動きが出ています。

https://corp.freee.co.jp/news/20260302freee_mcp.html

■MCPサーバー「freee-mcp」について
MCP（Model Context Protocol）は、AIアシスタントと外部ツールを接続するためのオープンプロトコルです。「freee-mcp」は、freeeが2018年から提供してきたPublic APIをベースに、会計・人事労務・請求書・工数管理・販売など約270本のAPIを網羅的にMCPツール化し、幅広いfreeeプロダクトに対応します。また、MCPツールに加えて、freee APIをMCP経由でより効果的に操作するためのAgent Skillsも含まれており、AIエージェントが業務文脈を理解した上で正確に操作を実行できます。

https://help.salesforce.com/s/articleView?id=platform.hosted_mcp_servers.htm&type=5

MCP サーバーは、AI アシスタントがデータソースに接続するための標準手段を提供することで、CRM データへのアクセス性とアクション性を高めます。Salesforce Hosted MCP Server を使用すると、組織は AI アシスタントが使用できるツールとして特定の Salesforce API とデータを公開できます。

現時点でシェアを獲得しているSaasは、いくらAIエージェントのコーディング能力が高くなったとしても、その機能の豊富さと複雑さ、なにより可用性やインフラのスケール、運用対応を考えれば、そう簡単にひっくり返るものではありません。

前置きが長くなりましたが、エージェントフレンドリーな機能とはどういうものでしょうか?

平たく言うと、エージェントが使いやすい手段(プロトコル)が提供されている。という事になります。

システムの操作はUI、ユーザーインターフェースを介して行いますが、その名の通りユーザー(人)が操作する為に考えられたインターフェースです。

最近はエージェントの機能として色々なツールを使えるようになったので、UIを操作することが出来ます。いわゆるRPAのようにブラウザ上の画面を人に変わって入力する、表示されたデータを認識する。と言った事も可能です。ただ、それは「できる」というだけで、それがエージェント(AI)にとって操作しやすいか？と言うと別な話になります。

で、システムが提供するエージェントが操作可能なインターフェースは何か？というと、具体的には「Web API」「MCP」「CLI」があります。

現状、本命としてはMCP(Model Context Protocol)があげられます。元々はAnthropic社が考えたエージェントが他のサービスへアクセスするための共通プロトコルですが、他のエージェントも対応してきたため、現在ではディファクトになってきています。

MCPで当初問題視されたのはMCPを使用する設定をするとエージェント起動時から内容が読み込まれ、MCPを使用していない間もコンテキストを圧迫するという事態が発生しました。現在ではアドホックに読み込みがされるようになり、この問題も解消しています。

この状況を見るとやはり本命はMCPだと思われるかもしれませんが、私は少し違う意見です。

私の推しはCLI(Command line interface)です。CLIとはコマンドプロンプトやシェルで実行可能なコマンド(プログラム)の事です。

なぜそんなに推すのかというと、これも実体験になりますが、大量のレガシーコードをエージェント使って解析していて気が付いた事がありました。この時はClaude code(以下CC)だったのですが、CCはbashを駆使します。正確にはbash上でLinuxのコマンド(grep, cat, wc, less, などなど)を駆使してリポジトリ上のコードを解析します。他のエージェントだとRAGやインデックスを構築して使いますが、CCの場合はそういったDB化をせずに直接コマンドを組み合わせて情報抽出をする特性があります。

そして繰り返し繰り返し解析を続けていると、定型的な処理が見えてくるので、今度はCCはPythonでコードを書き始めます。いわゆるバッチ処理化です。バッチ処理化するメリットとしては

(1) 同じ処理を繰り返し実行できる

(2) 同じ処理を繰り返し実行しても同じ結果となる

(3) バッチ処理の実行にはLLMを使用しない

といった点があります。

(1)は一般的にもバッチ処理の特徴ですが、(2)と(3)が生成AIならではの点です。

まず(2)の「同じ処理を繰り返し実行しても同じ結果となる」ですが、一見当たり前の事に思われるかもしれませんが、生成AIは確率論的な推論でアウトプットを生成します。同一のインプット、同一の実行条件でもアウトプットに揺らぎが出ます。繰り返し大量に実行した場合は当然揺らいだ結果が多くなってしまいます。これがバッチ処理であれば何回実行しても同じ結果となるのはプログラムという仕組み上、当然の結果です。

また、(3)に関しては、バッチ処理の実行自体にはLLMが使われますが、それ以降バッチ処理が完了するまではそのプログラムが実行されLLMは全く使われません。当然、LLMに対するトークンも消費されませんから課金もありません。スピードもLLMとのやり取りから比べたら爆速です。

業務システムのコーディングやレガシーマイグレーションでの大量のソースコード解析やドキュメントの出力など、ロングランを必要とする処理では地味に重要なポイントだったりします。

この2つの事から、私はCLIを好んで使っていますし、MCPが提供されているサービスはそれをラップする形でCLIを自分で作成し、利用していたりします。

皆さんも是非、MCPとCLIを使い比べてその善し悪しを実感してみてください。

では。

Saas is deadは本当か?

こんにちは、横井です。

ちょっと前から「Saas is dead(Saasは死んだ)」といった話題がXで飛び交っていますよね。

生成AIの進歩とバイブコーディングによって、必要なアプリケーションは誰でもすぐに作れるようになるから。というのが主張のようですが果たしてそうなのでしょうか？

このブログの読者含め企業の業務システムを作っている人からすれば「そんな簡単な話じゃないよね」というのが率直な感想でしょう。

企業が使う安定的で正確なシステムを提供するために必要なインフラやアプリケーション、その構成を設計、実装して、運用する。そこまで含めて初めてサービスとして成り立ちます。もちろんセキュリティの担保も。成立するための要素を上げ出したらいくらでも出てきます。

まあ、Xなどで賑わしているAI驚きおじさんは個人事業主が多いのでしょう。そんなスケールだったらいけるのかもしれませんが、企業レベルでは乗り越えるハードルはたくさんあります。

ただ、別な観点で考えると「生成AIによって淘汰されるsaasが出てくる」というのはあながち嘘ではないと思います。

chat-gpt の普及から2年、色々な製品やsaasで生成AIを活用した機能を組み込まれましたが、たいていはチャットウインドウで話しかけると処理が動いて結果が出る。といったものが多いですが、大抵「こんなプロンプトを書いているのかな？」と裏側が透けて見えるレベルが多いです。

私はClaude code やcodexといったLLMプロバイダが出しているコーディングエージェントを使うことが多いのですが、これらのエージェントは機能が段違いです。LLMプロバイダは今やAIコーディングが当たり前ですし、利用できるLLM資源も我々と違ってある意味無限ですから、いまだに人間がコーディングしている製品やサービスのAIエージェント機能がチープなのは仕方が無い事です。なので、手コーディングのプロンプトを組み込んだエージェントモドキではいっその事AI機能なんて組み込まない方が良い気がします。

一方、コーディングエージェントを使っていると、様々なツールを使いこなしてくれる事に気がつきます。gitでのリポジトリ管理、gradleやmavenでのビルドやテストの自動化、github のissue管理など、ソフトウエア開発のワークフローをエージェントが自動化してくれています。

最近は既存システムの調査としてエクセルドキュメントを分析していますが、エージェントはエクセルファイルも普通に読み書きできますし、図形描画やエクセル方眼紙などは1度画像として出力して画像解析することで内容を認識する事も出来ます。(画像が粗くて文字が読めない時は追加でエクセルファイルを解析してテキスト文字列を抽出してくれます)。こんな体験をすると、「生成AIを使った機能の実現」もパラダイムの転換が起きてきます。

つまり

・既存の機能にAI機能を追加する

よりも

・AIエージェントが使いやすいインターフェースを提供する機能

の方が、よっぽど役に立つものが出来るのではないでしょうか。

AIが普及した世界では、エージェンティックな製品/サービスではなく、エージェントフレンドリーな製品/サービスを提供しないと生き残れない = エージェントフレンドリーではないSaasは死ぬ。のではないでしょうか。

 

では。

生成AIを使いこなすパラダイムの転換

第6部 — パラダイム転換

旧パラダイム → 新パラダイム

旧パラダイム	新パラダイム
推論量中心	情報設計中心
多く読ませる	必要な情報だけ与える
自由に探索させる	探索を制限する
プロンプト工夫	コミュニケーション設計

これからは、「やり取りの量」ではなく、「やり取りの質」で勝負が決まる 時代だと思っています。

そして、ちょっと皮肉ですが、料金体系の変化が私たちにこの転換を 否応なく 迫ってきている、というのが現状でもあります。

---

まとめ

長くなったので、最後に5行で。

1. AI は会話を覚えていない。だから過去を毎回渡し直している。
2. 過去は積み上がるだけで、整理されない。情報の濃度は薄まっていく。
3. 品質劣化は、人間の修正のやり取りで雪だるま式に加速する。
4. 解決策は、段階を踏みつつ「空回り」を起こさせないこと。
5. AI のアウトプットの質を決めるのは AI じゃなくて、それを使う「私たち」である。

最後まで読んでくださってありがとうございました。AI とのやり取りが、ちょっとでも軽く、楽しくなれば嬉しいです。

---

本記事は、2026年4月に行った社内勉強会の資料『LLM/AIエージェントのパラダイム転換 ― トークン消費時代における実践理論』をブログ向けにリライトしたものです。

横井利和(株式会社イノベーティブ・ソリューションズ)

今日から使える3つの原則

第5部 — 今日から使える3つの原則

よくある誤解と、正しいアプローチ

✗ よくある誤解	✓ 正しいアプローチ
「最強のプロンプトを作れば、一発で正解が出るはず」	段階を踏みつつ、修正の往復を起こさせない
段階を踏む過程そのものを飛ばしている	段階を踏むこと自体が AI への「設計図」
最初の指示が重くなりすぎる	やり取りの "質" を見極める
結局、別の形で品質が落ちる	やり取りを減らすのが正解じゃない

ポイントは、「どんな」やり取りをするかが、すべて ということ。

やり取りには「前進する」ものと「空回りする」ものがある

	前進するやり取り	空回りするやり取り
何の話か	仕事そのものの話	過去の失敗の話
積み重ねた結果	進歩	混乱
品質への影響	良くなる、または変わらない	急激に悪くなる
例	仕様の段階的な詰め、レビューと確定	やり直し指示、感情的な反応、補足の補足

やり取りの 「数」 ではなく、「種類」 で品質が決まる。

3つの設計原理

図9. 3つの設計原理

① 良質なインプット

• 最初に与える情報を厳選する
• 無駄な情報を入れない
• → そもそもノイズを入れない設計

② 健全なコンテキスト

• 良質なインプットだけ履歴に残す
• 修正の往復を起こさせない
• → 「空回り」を作らない

③ 明確なアウトプット

• アウトプットのフォーマットも指示に含める
• 出力項目を規定して、揺らぎを抑える
• → 出力の揺らぎを減らす

これは経験から得た原則ですが、ここまでで見てきた AI の性質とちゃんと整合しているはずです。

前進するやり取りを作るための4つのコツ

最後に、現場で意識しているコツを4つ。

• ✅ 完璧なプロンプト(一発指示出し)は必要ない。会話で十分
• ✅ 指示(ゴール)だけじゃなく、それが必要な状況(文脈)も伝える
• ✅ 指示内容は段階的に詳細化する(良質なインプットを履歴に積む)
• ✅ 苛立ちや「違う、それじゃない」「なぜこうなった?」を AI に投げない

この4つを守れば、やり取りは「前進」したまま、「空回り」に転落しにくくなります。

良い結果を出すのも、悪い結果を出すのも、結局は自分次第

 

第4部 — 品質が悪化する本当の理由

ここまでで分かったこと

履歴が積もる → 大事な情報が薄まる → 品質が落ちる

これは分かりますよね。でも、現場で観測される品質低下って、もっとひどいんですよね。

品質低下は、加速度的 に進む

なぜそうなるのか。

品質劣化は「雪だるま式」に進む

図8. 雪だるま式の品質劣化ループ

実際に起きるのは、こういう加速ループです。

1. 情報を詰め込みすぎる
2. AI の出力品質が落ちる
3. ユーザーが「違う、もっとこう」と指摘
4. 指摘のやり取りも履歴に積もる
5. 次の出力はさらにブレる
6. さらに厳しく指摘する

…で、1 に戻る。

ちなみに、この構造は AI 特有の話じゃなくて、他の分野にも同じものがあります。

• 化学:自己触媒反応
• 制御工学:発振
• 生態系:正のフィードバック

要は、放置すると勝手に大きくなる現象です。

雪だるまの「核」は、修正のやり取り

雪だるまの中心 — 加速のエネルギー源になっているのは、実は 修正・やり直しのやり取り です。

ふつうの指示	やり直し・修正のやり取り
仕事の話	過去の失敗を蒸し返す話
AI が前進する材料になる	AI を混乱させる材料になる
品質に貢献 / 中立	品質を急落させる

過去の失敗の話が混ざるほど、AI は「結局、いま何をすべきか」を見失っていきます。

つまり、品質を決めているのは AI じゃなくて「人間の振る舞い」なのです。

AI の調子が悪くなる原因の半分は、私たちの「付き合い方」にある

しかも、悪循環がきれいにできあがっています。

出力が悪い → 苛立ち・焦り → 過剰な再指示 → さらに出力悪化

ということで、これは AI 側を変える話じゃなくて、私たちの使い方を変える話 です。

私も仕事として実際にコーディングする事は少なくて、指示出しなどマネジメントが殆どですが、感覚的には人に指示してプログラムを作成して貰うのも、生成AIに指示してプログラムを作成するのも、変わらない印象です。結局は「相手を見て何を伝えるか? どう伝えるか?」を考え続けています。

生成AIのコストはトークン消費量に比例するが、精度は比例しない

ここが生成AI の本質的な性質の話です。ネット上では色々なテクニックが転がっていますが、物事には必ず原理原則があります。そしてそれが発生するメカニズムがあります。生成AIに関する原理原則を知っておくと色々な現象がスッと腑に落ちます。

第3部 — 高コストの裏にある仕組み

AI は会話を「覚えていない」

図4. AIは1回ごとに完結している(ステートレス)

身も蓋もない話ですが、現在の AI(LLM)は 会話を覚えていません。

• 入力 → 思考 → 出力で完結
• 内部に記憶を持たない
• 1回の応答ごとに完結する(前後と独立)

「いやでも、ちゃんと前のやり取り覚えてるよね?」と思うかもしれません。あれは、毎回履歴を読み直しているから、覚えているように見えている だけです。

専門用語ではこの性質を「ステートレス(状態を持たない)」と呼びます。これは設計の選択じゃなくて、現在の AI の仕組み上の本質です。

だから、毎回「過去を渡し直す」仕組みになっている

図5. 履歴を毎回渡し直す

AI が記憶を持たないなら、どうやって会話が成り立つのか。答えはシンプルで、過去のやり取りを丸ごと毎回くっつけて渡している んです。

• ターン1:[入力] → LLM → [出力1]
• ターン2:[入力 + 履歴1] → LLM → [出力2]
• ターンN:[入力 + 履歴1 … 履歴N-1] → LLM → [出力N]

これがエージェントの基本動作。なお、これは 記憶の代わり であって、本物の記憶ではない、というのが大事なポイントです。

履歴は減らせない、まとめられない

図6. 履歴は減らせない、まとめられない

生成AI は、過去のやり取りを 自分自身で要約する機能を持っていません。だから履歴は積み上がる一方になります。

• 足していく → 可能(普通にどんどん溜まる)
• 削っていく → 不可(AI が自発的に整理してくれない)
• まとめる → 不可(AI が自発的に圧縮してくれない)

履歴を要約させることはできますが、それは外から指示してやらせるのであって、AI 自身が自然にやってくれるわけではありません。

情報は増えるが、「役に立つ情報」の濃度は薄まる

図7. コンテキストの中身の濃度は薄まる

履歴がどんどん積み上がると、見かけの情報量は増えます。でも、そのうち本当に役に立つ情報の比率(濃度)は下がっていく。

	初期	中期	後期
重要情報の濃度	100%	33%	17%
中身	全部役に立つ	過去の失敗・冗長が増える	大事な情報が埋もれる

役に立つ情報の割合 = 必要な情報 ÷ 全体の情報量、というイメージです。

これが、業界で言う 「コンテキスト汚染」 の正体です。

だから「たくさん考えさせる」ほど賢くなるわけじゃない

これが、現象B(料金と精度のミスマッチ)の正体です。

これまでの常識	実際に観測されたこと
情報を増やすほど賢くなる(右肩上がり)	途中で頭打ち、その後は逆に劣化

「もっと文脈を渡せば、もっと良い答えが返ってくるはず」 — じゃないんですよね。

モデルの進化が、汚染の規模も大きくした

ちょっと皮肉な話です。

• STEP 1 — モデルが進化した:コンテキストウィンドウが大幅に拡大(4K → 32K → 200K → 1M トークン以上)
• STEP 2 — 業界が「もっと詰め込める」に流れた:ドキュメント全体を投入、履歴を全部保持、ツール出力を無制限追加…
• STEP 3 — 結果、汚染も桁違いに拡大:重要情報の絶対量は変わらず、ノイズだけが膨らんでいく

つまり、容量の拡大が 意味密度低下のリスクに直結している。

解決策は、容量を使い切ることじゃなくて、容量の中で 「何を選ぶか(=何を残すか)」。

AIエージェントはあなたのお金をどのように使うのか

論文が示した内容は私とっては「驚きの内容」ではなく、「実体験で感じてきた事の言語化」でした。

例えば、バイブコーディングでプロト開発をするような場合は特に問題なく速攻で出来てしまいますが、業務システムの様に画面やテーブルが数百もある規模のコーディングを前提とした場合、作る機能は様々でも各レイヤーでは同じ様なコーディングを繰り返し繰り返し行う事になりますが、このようなロングラン状態でも同じ結果を出力し続ける事は確率論的な生成AIではかなり難しい事でした。

第2部 — 研究が示した3つの事実

ここからは、論文と現場の観測から見える3つの現象を順番に見ていきます。

現象A:エージェントは「通常のチャットの 1000倍」消費する

図1. トークン消費量の比較

普通のチャット(数往復のやり取り)を基準にすると、エージェント — つまり「AI が自分で考えながら手を動かす」場合 — は、消費量がケタ違いです。だいたい 1000倍規模になります。

しかも、研究で分かったポイントはここ。

AI が出した答え(出力)よりも、AI に渡している情報(入力)の方が、料金の大半を占めている

つまり、課金の主役は「AI が頑張って考えて吐き出した結果」ではなく、「AI に毎回読み込ませている文脈」の方なんです。

現象B:使えば使うほど料金は膨らむ。しかも賢くはならない

図2. 情報量と賢さの関係

直感的には「情報を多く渡す = AI がより賢く答える」と思いますよね。実際はそうなってなかった、というのがこの論文の発見です。

• 料金は青天井(渡せば渡すほど、消費トークンは増える)
• でも、精度は途中で頭打ちになる
• それどころか、その後は逆に 劣化 することがある

「お金を積めば賢くなる」が成立しない、という話です。

現象C:同じ仕事を頼んでも、料金は毎回バラバラ

図3. 同じタスクを6回実行したときの消費量

同じタスクを何回かエージェントに投げて、消費トークンを記録するとどうなるか。最大で 30倍 くらいの差が出ます。

しかも、

• どれだけ消費するかは、やってみるまで分からない
• AI 自身に「どれくらい使う?」と聞いても、正確には答えられない
• しかも見積もりは、たいてい実際より少なく出る

予算管理する側からすると、これは結構しんどい性質です。

3つの事実は、すべて同じ原因から来ている

ここまでの3つ — 「1000倍消費」「料金と精度のミスマッチ」「実行ごとのばらつき」— は、それぞれバラバラの問題に見えます。でも実は、ひとつの構造的な原因 から来ている、というのが次の章の話です。