MCPとAI Agentについての考察

0. はじめに

昨今AI Agentサービスの導入、リリースが多く行われております。

私自身、AI Agentへの理解がまだ粗い部分があると感じていたため、改めて現時点の理解・疑問・その上での意見を言語化しました。もともとのメモを基に、AIの支援を得てブログ公開用の文章として整えています。

また私は、何かに取り組む際には「それは何を解決するのか」「解決したい背景は何か」「認識している課題は本質を捉えているか」を常に自分に問いかけながら考えるようにしています。こうした観点から見たとき、AI関連のサービスがどのように見えるのかを共有したいと思い、本稿を作成しました。

※一部解像度低いところがあるので、そのあたり誤った情報があれば随時修正かけます。

1. MCPとは何か

MCP（Model Context Protocol）は、AIモデルに外部ツールやAPIを呼び出す能力を与えるプロトコルです。

基本的な流れ： ユーザー → AI → MCP → 外部API（Notion,Fgima等）→ データ返却

本質的には、AIにMCP経由で実行可能な関数を公開し、チャットの指示に基づいて何を実行するかを判断させている仕組みです。

MCPでできること・できないこと

MCPでできることは、APIを叩く口を用意する、データを取得する、ツールを公開する、といったことです。

一方でできないことは、何を叩くべきか判断する、データを解釈する、課題を解決する、といったことです。

MCPは「配管」であって「蛇口」ではない、という表現がしっくりくるかもしれません。

2. 現状のMCP構成の限界

受動的な構造の課題

現状の構成は以下のような流れになっています。

ユーザー指示 → AI判断 → ツール実行 → 結果返却 → 終了

この構造には以下のような課題があります：

• ユーザーが指示しない限り何も起きない
• 単発のリクエスト/レスポンスで完結してしまう
• 会話ごとにコンテキストがリセットされる

自律エージェントとの違い

巷で語られる「自律的なAI Agent」に必要な要素と比較すると、現状のMCPには大きな差があります。

目標設定について、現状のMCPではユーザーが毎回指示する必要がありますが、自律エージェントは自分で目標を持ち続けます。

計画立案について、現状のMCPは単発のツール呼び出しですが、自律エージェントは複数ステップの分解・計画を行います。

実行ループについて、現状のMCPはリクエスト/レスポンスで終わりますが、自律エージェントは継続的に動くプロセスを持ちます。

状態記憶について、現状のMCPは会話ごとにリセットされますが、自律エージェントは永続的なメモリを持ちます。

自己評価について、現状のMCPにはありませんが、自律エージェントは結果を見て次を決定します。

トリガーについて、現状のMCPはユーザー入力のみですが、自律エージェントは時間・イベント・条件ベースで動きます。

3. 「自律エージェント」の実態

現在のAI Agentの状況

巷で言われる「AI Agent」について整理してみると。

• AutoGPT / BabyAGI：ループで自己プロンプトしている仕組みで、実用性は限定的
• Devin / Cursor Agent：コーディングタスクに特化した限定的な自動化

「何でもこなす自律AI」というのは、現時点ではマーケティング的な表現に近いのではないでしょうか。

実際のところ

• 狭い領域で
• 人間の監視下で
• 限定的なタスクを自動化

これが現状の限界だと考えられます。

4. 素人には使いにくい問題

暗黙のユーザー像

現状のシステムが想定しているのは、こういった指示ができる人です。

「customer_id 1234567890 の過去30日のキャンペーン別CPAをGAQLで取得して、CVRが低いものを特定して」

これが言える人は、もはや素人ではありません。

ユーザーとシステムのギャップ

素人が「広告がうまくいってない気がする」と言っても、現状のシステムは「何を取得するか自分で決めてください」と返します。

「売上を増やしたい」と言っても、「具体的なIDとクエリを指定してください」と言われます。

「CPAって何？」という質問には、用語を知っている前提で話が進みます。

「で、どうすればいい？」と聞いても、データは返すけど判断はご自身で、という対応になります。

5. 「なんでもできる」の落とし穴

汎用性の罠

「なんでもできます！」という謳い文句は、実質的には何もできないのと同じになりがちです。

「なんでもできます」
→ ユーザー：「で、何すればいいの？」
→ 結果：何も起きない

ツールがあってもドメイン知識がなければ使えない

現状は「データ取得できる」「コンテンツ生成できる」「分析できる」という状態ですが、実際に必要なのは「何を取得すべきか知っている」「何を作るべきか知っている」「何を見るべきか知っている」ということです。

よくある会話の流れ

素人：「広告のレポート作って」
AI：「どの指標を含めますか？期間は？誰向けですか？」
素人：「わからない...普通のやつ」
AI：「では一般的なものを...」
→ 結局役に立たない

6. 本当に価値があるものとは

汎用ツール vs 特化ソリューション

汎用ツールが「MCPでGA4取得できます」と言うのに対し、特化ソリューションは「毎週月曜に売上レポートが届きます」と言います。

汎用ツールが「GAQLで何でも聞けます」と言うのに対し、特化ソリューションは「CPAが20%上がったら通知します」と言います。

汎用ツールが「AIがコンテンツ作れます」と言うのに対し、特化ソリューションは「過去広告を学習して新案を3つ提案」と言います。

狭く、深く、具体的にしないと、価値が出にくいのではないでしょうか。

素人が使えるシステムに必要なレイヤー

1. 意図理解：「調子どう？」→ CPA, ROAS, CVRを見ればいいと判断
2. 自動コンテキスト補完：このユーザーのアカウントは○○、業種は△△と把握
3. データ取得：← 現状ここだけが実現されている
4. 分析・インサイト生成：「キャンペーンAのCPAが30%悪化。原因は○○」
5. アクション提案：「入札を10%下げますか？」→ ワンクリック実行

7. ChatベースのAIの得意・不得意

ChatGPTがうまくいっている領域

• 知りたいことを知る
• 壁打ち相手としての提案
• 一人で思考を拡張させる

これらは「考えを整理したい」「情報が欲しい」といった比較的明確な課題であり、ユーザーが自分で問いを立てられる領域です。

うまくいきにくい領域

マーケティングなど専門領域では、ChatベースでのAI活用には高度な専門知識が必要になりがちです。

SaaSとChatの違い

ユーザーが問いを立てる必要について、Chatでは自分で問いを立てる必要がありますが、SaaSではアプリが問いを立ててくれます。

自由度について、Chatは高すぎて迷いがちですが、SaaSでは導線が設計されています。

状態について、Chatは毎回ゼロからですが、SaaSでは状態が保持されます。

結果の評価について、Chatでは良し悪しがわかりにくいですが、SaaSではベンチマークが組み込まれています。

SaaSは「課題を知らなくても解決に導く設計」ができますが、Chatは「課題を知っている人向け」という違いがあるように思います。

8. 課題発見の本質的な困難さ

ChatベースのAIで課題発見が難しい理由

• 言語化の壁：ユーザーは課題を言葉にできないことが多い
• 文脈の欠如：AIはユーザーの状況を十分に把握できない
• 探索的対話の限界：何を聞けばいいかわからない

本来必要なプロセス

1. 専門家との対話 → 課題を言語化する支援
2. 状況の可視化 → データから課題を発見
3. 比較対象の提示 → 「普通」との差分を見せる
4. 仮説の提示 → 「これが課題では？」と問いかける

Chatは「言語化された課題」に対応するツールであり、「言語化できない課題」には別のアプローチが必要ではないでしょうか。

9. 必要になるもの

AI専用のUIUX設計

従来のSaaS UIでは不十分な理由があります。

従来のSaaS UIは固定的な画面遷移、決まったワークフロー、ユーザーが操作を選ぶ形式でした。AI時代に必要なUIは、動的に変化する画面、ユーザーの状況に応じた導線、AIが次のアクションを提案する形式です。

AI専用UIUX設計に必要な要素：

• プロアクティブな提案（ユーザーが聞く前に「これ見て」と示す）
• コンテキストアウェアな表示（状況に応じてUIが変化）
• 段階的な課題発見（いきなり答えではなく、気づきを促す）
• 自然言語とGUIのハイブリッド
• 状態の可視化（今どこにいて、何が起きているか常に見える）

高度なシステム設計

必要なアーキテクチャ：

1. 永続的なコンテキスト管理：ユーザーの状況、過去の行動、目標を保持
2. マルチステップオーケストレーション：複数のツール呼び出しを計画・実行・評価
3. イベントドリブンな実行：ユーザー入力だけでなく、条件トリガーで動く
4. フィードバックループ：結果を評価し、次のアクションを調整
5. ドメイン知識の組み込み：「何を見るべきか」「何が異常か」を知っている

現状と理想のギャップ

現状は「Chat入力 → API呼び出し → 結果表示」という流れで、ステートレス、受動的、汎用、テキストベースです。

必要なのは「状況把握 → 課題発見 → 提案 → 実行 → 評価」という流れで、ステートフル、能動的、ドメイン特化、マルチモーダルなものです。

10. ビジネスインパクトと参入障壁

開発できれば大きなインパクト

もし「素人が課題を意識せず解決できるAIプロダクト」が作れたら：

• 専門家不要で成果が出る → 市場が拡大
• 人件費の大幅削減 → 導入企業のROIが向上
• 24時間稼働 → 機会損失の削減
• スケーラブル → コスト効率が高い

中小企業にとっての難しさ

この領域に中小企業が対応するのは容易ではありません。

AI専用UIUX設計の知見については、経験者が少ないという課題があります。高度なシステムアーキテクチャについては、設計できるエンジニアの採用が難しいです。ドメイン知識の深い組み込みについては、専門家の確保・維持が困難です。大量の実験と改善には資金的余裕が必要で、LLMのコストも開発段階での負担が大きいです。

中小企業に残された選択肢

1. 待つ：AI企業がプラットフォームを整備するのを待ち、その上でアプリケーションを作る
2. 超特化する：極めてニッチな領域に絞り、ドメイン知識で勝負する（ただしスケールは限定的）
3. 部品として使う：MCPを「便利ツール」として社内利用し、製品化は見送る

11. ドメイン知識の組み込み：最も難しい課題

なぜ最も難しいのか

AI専用UIUX設計の方法論は存在かもしれません（筆者AIのUIUX領域は調査できていないため割愛します）。

システムアーキテクチャも難しいですが、エンジニアで解決可能です。しかしドメイン知識の組み込みは、誰がどうやって行うのかが明確ではありません。

ドメイン知識は「人の頭の中」にしかないことが多いのです。

ドメイン知識の性質

• 暗黙知が多い：言語化されていない、「なんとなくこうする」
• 経験に依存：教科書にない判断基準が大量にある
• 文脈依存：状況によって正解が変わる
• 例外だらけ：ルール化できない判断が多い
• 常に変化：市場・技術・法規制で変わり続ける

組み込みの難しさ

専門家を見つける段階では、本当の専門家は少なく、いても忙しい・高い・協力を得にくいという課題があります。

知識を引き出す段階では、専門家自身が言語化できないことが多く、「なぜそう判断した？」と聞いても「うーん、経験かな」という答えが返ってきます。

構造化する段階では、プロンプトにするか、ナレッジベースにするか、ファインチューニングするか、どれも一長一短です。

検証する段階では、正しいか誰が判断するのか、エッジケースは無限にあるという問題があります。

維持する段階では、ドメイン知識は変化するため、誰が更新し、どう検知するかという課題があります。

根本的なジレンマ

• ドメイン知識を持つ人 ≠ AIを作れる人
• AIを作れる人 ≠ ドメイン知識を持つ人
• 両方を持つ人 = ほぼ存在しない
• 両方を持つチーム = 組成が極めて困難

12. まとめ

MCPの現在地

MCPは「部品」であって「製品」ではありません。部品箱を開けて見せている状態であり、組み立てて特定の課題を解決するプロダクトにしないと、ユーザーには届きにくいでしょう。

AI Agentの現在地

「自律的に何でもこなすAI」は、現時点では存在しないと言えます。現状は「AIにAPIを叩かせる便利なインターフェース」であり、狭く、深く、具体的な課題に特化して初めて価値が出てきます。

ドメイン知識について

ドメイン知識の組み込みは、技術的問題というより「人の問題」です。知識を持つ人を見つけ、引き出し、構造化し、検証し、維持する——この全プロセスに「人」が必要です。

AIで人を置き換えようとしたら、AIのために大量の人が必要になる——そんな逆説的な状況があります。

最後に

「ChatにMCPをつなげば課題解決できる」というのは、少し楽観的すぎる見方かもしれません。

本当に課題を解決するには

• AI専用のUIUX設計
• 高度なシステムアーキテクチャ
• ドメイン知識の深い組み込み

これらを一から設計する必要があります。

MCPは「部品」、Chatは「インターフェースの一つ」に過ぎません。製品として成立させるには、その上に膨大な設計と実装が必要です。

「なんでもできる」ではなく、「誰の、どんな課題を、どう解決するか」を定義しない限り、MCPもAI Agentも「技術デモ」の域を出ない——そう考えています。