APIは「サービスやシステムが外部から機能を利用するための窓口」で、MCPは「AIアプリが外部のツールやデータを扱うための共通プロトコル」となります。

まぁ、なんだかよく区別のつかないAPIとMCP、MCPはAPIの代わりになるものではなく、MCPサーバーの内部でAPIを呼び出す構成もありますが、データベースやファイル、コマンドラインツール、独自の処理などを直接扱うこともできます。

APIとMCPは同じ場所を取り合う技術ではなく、役割が違うんです。

APIは「サービスの窓口」、MCPは「AIと外部機能をつなぐ共通プロトコル」

APIは、ソフトウェア同士が機能やデータをやり取りするための仕組みで、天気予報サービスなら天気情報を取得するAPI、カレンダーなら予定を取得・登録するAPI、決済サービスなら決済処理を行うAPIなどがあります。

それぞれのサービスが、URL、リクエスト方法、データ形式、認証方法などを定めている一方、MCP（Model Context Protocol）は、AIアプリケーションと外部のデータやツールを接続するためのオープンなプロトコルです。

Anthropicが2024年11月25日に発表した後、MCPはオープンな標準として広がり、2025年12月にはAnthropicがMCPをLinux Foundation傘下のAgentic AI Foundationへ寄贈し、現在は特定のAIサービスだけの仕組みではなく、複数のAI開発環境で利用される共通プロトコルとして位置づけられています。

イメージすると、次のような関係。

ユーザー
↓
AIアプリ
↓ MCP
MCPサーバー
↓
API・データベース・ファイル・CLIなど
↓
外部サービスやデータ

ここで重要なのは、MCPサーバーの下にあるものがAPIとは限らないことで、MCPサーバーが社内データベースを直接検索したり、パソコン上のファイルを読み取ったり、コマンドラインツールを実行したりする構成なども考えられます。

そのため、「MCPはAPIを置き換えるもの」というものではなく、AIアプリと外部の機能・データを共通の方法で接続するための層と考えるほうが分かりやすくなります。

APIとMCPの違いを具体例で比べる

たとえば、社内の予定表サービスをAIに操作させるケースを考えてみましょう。

APIだけで作る場合

開発者は予定表サービスのAPI仕様を確認し、予定の取得や登録を行うプログラムを作ります。

さらにAIにその機能を使わせるには、AIアプリ側で「どの機能を呼べるのか」「どんな引数を渡すのか」「結果をどう受け取るのか」といった処理を組み込む必要があります。

別のAIアプリで同じサービスを利用する場合には、そのAIアプリ側でも対応が必要になることがあります。

MCPを使う場合

予定表サービスに接続するMCPサーバーを用意します。

MCPに対応したAIアプリは、そのMCPサーバーが公開するツールやリソースなどを、MCPという共通のプロトコルを通じて扱えます。

MCPサーバーの内部では、予定表サービスのAPIを呼び出しても構いません。

この場合の構造は、

AIアプリ → MCP → MCPサーバー → 予定表API → 予定表サービス

となります。

ただし、MCPサーバーが必ずAPIを経由するわけでもなく、

AIアプリ → MCP → MCPサーバー → データベース

という構成も可能となっています。

つまり、MCPとAPIは「どちらを使うか」という単純な二択ではなく、APIはサービスやシステムの機能を外部から利用するためのインターフェースで、MCPはAIアプリが外部のツールやデータを扱うための共通プロトコル。

この違いを押さえると、両者の関係が分かりやすくなります。

MCPは「個別の接続方法」を共通化する

MCPのメリットを理解するには、AIアプリや外部サービスが増えた場合を考えると分かりやすくなります。

AIアプリごとに、それぞれの外部サービスへ個別の接続方法を用意すると、サービスが増えるたびに対応する範囲も広がります。

たとえば、AIアプリが複数あり、接続したいサービスも複数ある場合、それぞれの組み合わせに合わせて異なる接続処理を作る必要が出てきますが、MCPを使えば、AIアプリ側はMCPに対応し、サービス側はMCPサーバーを用意することで、共通のプロトコルを使って接続できます。

そのため、MCPのメリットは、AIと外部サービスの組み合わせが増えても、毎回ゼロから接続方法を設計する必要を減らせることであり、これがMCPが「USB-C」にたとえられる理由の一つでもあります。

機器ごとに異なる専用の接続方法を用意するのではなく、共通の方式に対応することで接続しやすくするという考え方なのですが、MCPに対応したからといって、すべてのAIアプリとサービスが何の設定もなく自動的につながるわけでもありません。

認証、権限、対応する仕様、サービス固有の処理などは、別途考える必要があります。

MCPの基本的な仕組み

MCPでは、AIアプリ側とMCPサーバー側がプロトコルを介して通信します。

一般的な構成では、AIアプリケーションがホストとなり、その中のMCPクライアントがMCPサーバーと通信します。

MCPサーバーは、AIアプリに外部のツールやデータを提供します。

代表的なものが次の3つ。

• Tools（ツール）：AIが実行できる操作
• Resources（リソース）：AIやアプリケーションが参照できるデータ
• Prompts（プロンプト）：あらかじめ用意された指示やテンプレート

たとえば、

• ツール：予定を登録する、ファイルを検索する
• リソース：文書、データベースの情報、ファイルの内容
• プロンプト：特定の作業で使う指示テンプレート

といったもので、通常のAPIでも似た機能を作ることはできますが、違いは、MCPではAIアプリとサーバーの間で、こうした機能を公開・利用するための共通の方式が定められていること。

そのため、MCPに対応したAIアプリは、個々のサービスごとにまったく異なる方式を学習するのではなく、共通のプロトコルを通じツールやリソースを扱えます。

なお、MCPにはこの3種類だけでなく、認証や拡張機能など、さまざまな仕組みがあります。

MCPの通信方法も共通化されている

MCPでは、メッセージの形式としてJSON-RPCが使われます。

通信方法には、ローカルでMCPサーバーを起動する場合のstdioや、リモートのサーバーと通信するためのStreamable HTTPがあります。

ここでも重要なのは、MCPが「APIそのもの」ではなく、AIアプリとMCPサーバーの間でやり取りするためのプロトコルだという点です。

また、MCPの仕様は更新されています。

2026年7月28日に公開された仕様では、従来のプロトコルレベルのセッションやinitializeによるハンドシェイクが廃止され、ステートレスなプロトコルコアへ変更されました。必要に応じてserver/discoverを使ってサーバーの能力を確認できます。

そのため、MCPについて調べるときは、どの仕様バージョンを前提にした説明なのかを確認する必要があります。

どちらを意識すればよいのか

立場によって、見るべきところは変わります。

AIアプリを使う側

MCPに対応したAIアプリなら、対応するMCPサーバーを接続することで、外部のツールやデータを利用できる場合があり、この場合、利用者が外部サービスのAPI仕様を細かく理解する必要はありません。

ただし、MCPサーバーにどのような権限を与えるのかは確認が必要。

自社サービスをAIから使えるようにしたい開発者

すでにAPIを提供しているなら、そのAPIを残したままMCPサーバーを追加する構成が考えられます。

たとえば、

既存API → MCPサーバー → AIアプリ

という形で、APIはAI以外のシステムからも利用できるため、APIとMCPを両方用意することで、それぞれの利用目的に対応できます。

AI以外のシステム同士をつなぐ場合

AIが介在しない通常のシステム連携なら、APIを直接利用する方法が一般的です。

たとえば、

販売管理システム → API → 会計システム

のように、処理の内容があらかじめ決まっている連携であれば、MCPを使う必要はありません。

MCPは特に、AIが状況に応じて外部のツールやデータを選択して利用するような処理で意味を持ちます。

MCPで注意したいセキュリティ

MCPは単なる「データの読み取り規格」ではありません。

ツールを通じ、AIが外部システムに対して操作を実行できる場合がありますので、、MCPサーバーを追加するときは、

• 何にアクセスできるのか
• 何を実行できるのか
• どの権限を持っているのか

を確認する必要があります。

特に注意したいのが、外部から取得した文章などに悪意のある指示を混ぜるプロンプトインジェクションで、AIがメールやWebページ、カレンダーなどの内容を読み取り、その中に書かれた指示を誤って実行してしまう可能性があります。

また、MCPのツールには、読み取り専用か、破壊的な操作を行う可能性があるかといった情報を示す仕組みがありますが、それだけで安全性が保証されるわけではありません。

そのため、MCPを導入するときは、許可するツールを限定する、必要以上の権限を与えない、認証を設定する、実行ログを確認できるようにするなどの対策が重要になります。

出どころの分からないMCPサーバーを、機能だけを見て接続するのも避けたほうが安全。

APIとMCPは「どちらか」ではない

APIとMCPの違いを一言で整理すると、次のようになります。

	API	MCP
主な役割	システムの機能やデータを外部から利用する	AIアプリと外部のツール・データを共通方式で接続する
主な利用者	アプリケーション、システム、開発者	AIアプリ、AIエージェント
接続先	サービス、システム、データベースなど	MCPサーバー
共通化するもの	サービスごとに異なる	AIとMCPサーバー間の通信・機能公開の方式
下にあるもの	データベースやサービスなど	API、データベース、ファイル、CLIなど
AI専用か	いいえ	AIとの連携を主な目的とする

だから、MCPが普及したからAPIが不要になるという話でもなく、むしろ、APIがサービスやシステムの機能を外部に公開し、MCPがその機能やデータをAIから扱うための共通の接続方法を提供するという関係で考えると分かりやすくなると思います。

AIが外部のサービスやデータを扱う場面が増えるほど、「AIに何をさせられるか」だけでなく、「AIと外部の機能をどのようにつなぐか」も重要になり、MCPは、その接続方法を共通化するための仕組みとなっています。

GoogleのAI OverviewやChatGPT検索が当たり前になってきている今、「検索順位は落ちていないのにPVだけ減っていく」という声が増えてきているようですね。

実際、AI概要が出るクエリではオーガニックCTRが大きく下がったというデータもありますし、情報系ブログほど影響を受けやすい状況となっているようです。

ですので、今後多くのブロガーが目指していくのは「ブログだけで独立」するのではなく、生活費の一部をほんの少しだけ支えることのできる月3〜5万円クラスの収益を求めることが現実になっていくような気がします。

AI検索の台頭で何が変わったのか

かつては、検索ボリュームのあるキーワードで上位表示できれば、それだけで安定したアクセスと収益が見込めたのですが、今は、ユーザーが検索窓にキーワードを入れても、最初に目にするのはGoogle AI Overviewの要約や、AIがまとめた「答え」であり、要点だけを知りたい人は、その画面を眺めるだけで満足ですし、個別のブログ記事までたどり着かないことが増えてきています。

また、ChatGPTやPerplexityのように、最初から検索エンジンではなくAIに質問する人も多くなってきており、こうした行動の変化が「順位は落ちていないのにクリックされない＝ゼロクリック検索が増える」という現象を生み出し、特に「◯◯とは」「◯◯のやり方」といった、定義や手順だけを知りたいような検索においては、AIだけで完結しやすくなっています。

要点だけに絞った回答が出てくる上、そこから気になったことは、さらにAIに尋ねるということができますからね。

月3〜5万円ブロガーが直面しているリスク

副業としてブログを運営し、月に3〜5万円を稼いでいる層は、時間も予算も限られているうえ、大きな問題になってくるのは「PVが減ると、そのまま売上も減る」構造に依存しているということ。

たとえば、検索流入がメインで、収益源もほぼアフィリエイトと広告のみというパターンなどでは、AI検索の影響で情報系記事のPVがじわじわと削られていくことによって、収益も連動して下がっていきますし、生活費の一部を任せている人ほど、この変化はプレッシャーになっていきます。

とはいえ、すぐに高額なツールを導入したり、すべての記事を構造化データ対応にしたりするのは現実的ではありませんし、そこを改善したからといってAI検索の流れに歯止めがかかるわけでもありません。

大切なのは、「今ある記事と読者」を活かしながら、落ち込みを緩やかにし、指名で読まれる経路を少しずつ増やしていくことが重要になってきます。

押さえたい「生活防衛」の具体的な一歩

最初の一歩として有効なのは、すでに読まれている記事の中身を、AI検索時代向けに少しだけ作り替えることで、新しい技術用語を覚える前に「AIにも人にも読み取りやすい記事」に近づけるイメージでリライトしていくことが第一歩となるでしょう。

たとえば、よく読まれている解説記事の冒頭に、質問への一言回答を置いておき、そのあとに詳しい理由や手順を続けるだけでも、AIにとっては要点を拾いやすくなります。

また、見出しを「◯◯とは？」「◯◯のメリット・デメリット」のように、質問と答えがセットで伝わる形に整えることで、回答抽出との相性もよくなります。

さらに、その記事の中で、自分なりの具体的な体験や、小さな失敗談を一つだけでも加えておくと、AIだけでは書きづらい「人間の声」としての価値が高まりますし、情報としての役割と「この人の視点で読む意味」の両方を意識することで、AIに要約されても読みに来てもらえる確率が少しずつ上がっていきます。

「指名して読まれる経路」を少しずつ増やす

さらに考えるべきなのは「検索でたまたま来る人」だけに依存しないことで、AI Overview経由であなたのブログ名やサイト名が目に入ったとき、「あ、この前も見た名前だ」と感じてもらえる機会を増やしておくと、その後の指名検索や直接訪問につながります。

そのためには、ブログの中で名前やサイトコンセプトを丁寧に伝えることに加え、Xやニュースレター、RSSなど、読者が「続きを受け取れる場所」を一つ用意しておくことが役立つはず。

大げさな仕組みでなくても、更新情報と一言コメントを流すだけで、「AIで概要を知ったあと、詳しく知りたいときに戻ってこられる場所」として機能しますし、月3〜5万円の規模なら、読者一人ひとりとの接点を濃くする方が、PV数を追いかけるよりも安定につながりやすくなります。

ブログを続ける意味

AI検索の影響で、従来型のSEOだけに頼るブログ運営は厳しくなってきているのは確実です。

しかし、読者が「誰の経験や視点を信じたいか」で情報源を選ぶ流れは、むしろ強くなってきていますし、AIが集めた情報だけでは不安になったとき、人は具体的な失敗談や生活の話が混ざった文章を求めるようになります。

月3〜5万円のブログ収入は、家計の中では決して小さくない額ですし、そのラインを守るためには、「検索結果の数字」だけでなく、「誰がどんな気持ちで読んでいるか」をもう一度見つめ直すことが欠かせないでしょう。

AI検索時代のブログ運営は、アクセス数の競争から一歩下がり、少ないけれど濃い読者との関係を積み重ねていく、より地道なフェーズに入ってきており、ファンを作るということが重要になってきます。

そこで得られる信頼や一次情報は、将来の別の収益源にもつながる資産になっていくはずですよ。

設定変更もテーマ作成も、頼めばAIがやってくれる。

そんな触れ込みのLinuxディストロを実際にセットアップしてみると、真っ先につまずくのはAIエージェントの認証画面。

Ruby on Rails作者のDHH氏が手がける「Omarchy」の最新版、Omarchy 4.0（Omarchy Quattro）が、AIエージェント統合を軸にした開発者向けOSとして動き始めた。

---

AIを「第一級市民」にしたOS構成

Omarchy（オマーキー）は、Arch Linux を土台にした Linux ディストリビューションで、画面を自動で整列させる「Hyprland」と、高速なカスタマイズシェル「Quick Shell」を最初から組み合わせているのが特徴となっています。

• Arch Linux ベース：最新パッケージが使える軽量・高カスタマイズな基盤
• Hyprland 搭載：ウィンドウを自動でタイル状に並べるモダンな環境
• Quick Shell 同梱：素早く設定・拡張できるシェルフレームワーク

WindowsやMacに代わる、使いやすく美しいOSを志向していて、インストール後すぐに使い始められる構成を目指しています。

Omarchy の新版で特に注目されているのが、AI エージェントの統合です。

何がすごいのか

• 複数の AI エージェントに対応：Claude、Codex、Copilot、Gemini、Grok など
• 「スキルファイル」を読み込ませて操作：Hyprland の操作方法やショートカットの説明、設定変更、アプリのインストール、テーマの切り替え、Quick Shell プラグインの生成などを AI が担当
• トラブル時の自動解析：アプリやツールがクラッシュしたとき、AI がログを解析して原因と修正方法を提示

従来であれば、カスタマイズは「自分で調べて、自分で設定する」ことが当たり前だったのですが、Omarchy の目指すのは「こういうテーマを作って」と頼むだけで、OS 側（AI エージェント）が設定や生成をしてくれるようになり、つまりは「指示するだけで環境が変わる」という、より直感的なLinux体験を設計している点が新版の大きな特徴とも言えます。

セットアップで露出した段差

ZDNETによれば、「AI が何でもやってくれる」という構想と、現実のセットアップの間には、かなりギャップがあるようです。

公式マニュアルでは「AI コーディングエージェントを第一級市民として扱うが、最優先にはしない」と明記され、主要なエージェントのCLIは遅延ロードのランチャーとして組み込まれています。

実際に、Geminiエージェントをセットアップしようとすると、ブラウザの認証画面がオーバーレイの裏に隠れる問題があって、Googleアカウントでのログインでは認証できず、結局API トークンを作成する回り道が必要だったようです。

また、Omarchyの操作はSuperキー中心のショートカットとタイル型ウィンドウが前提で、マウス中心の一般的な UI とは勝手が異なるようですね。

ローカルAI については、GUIのLM Studio、CLIのOllama が利用でき、デフォルトのOmarchyAIエージェントと並行実行できるようですから、ある意味、大きな縛りはなさそう。

とはいえ「AI が何でもやってくれる」という理想の一方で、そのAI自体をセットアップする段階でつまずくというのも、まだまだこれから発展していく余地はありそう。

「AIに任せる」ことの評価軸はどこに？

Omarchyが投げかけているのは、「AIが何でもやってくれるか」ではなく、「AIとOSの間にある段差を、どこまで吸収できているか」というものであり、設定やテーマ作成をAIに任せられるという構想自体は魅力的とはいえ、その前にあるエージェントの認証やUIの噛み合わせが整っていなければ、体験全体としての快適さにはつながりにくいですね。

とはいえ、AIコーディングエージェントやローカルLLM環境がOSレベルで一通り揃っていることには十分価値があり、多少のつまずきは、Linuxらしいクセの範囲と捉えられれば、大きな問題ではなさそうですが、WindowsやMacに代わるという一般普及が目標ということであれば、さらなる改善は必要。

とはいえ、現時点の体験は初期バージョン特有の粗さを含んでいる可能性が高いですし、アップデートを重ねた先でどこまで改善されていくのかは楽しみではありますね。

途中で頓挫しないことを願うばかり。

OpenAIは8月10日に広告ポリシーを更新し、13日には新たな最高売上責任者の就任を発表、表面的には無料サービスへの広告導入となるのですが、会話AIでは利用者が予算や条件を伝えた「決める直前」に広告を出せる点で、従来の検索広告とは競争軸が異なってきそう。

ChatGPT広告と新CRO就任が同時に動いた理由

OpenAIによれば、ChatGPTはすでに週10億人超、200万社超が利用しているのだそうで、この規模の利用基盤に対し、8月に入り広告ポリシーの更新と売上責任者の新設がほぼ同時に発表されたことは、広告事業を one of many機能ではなく、収益の柱として本格的に位置づけ始めたことようですね。

すでに、アメリカのFree・Go利用者を対象にChatGPT広告をテストしているようで、広告は回答とは分離し「Sponsored」と表示する方針となっているようです。

広告主には会話内容やチャット履歴、メモリ、個人情報を渡さず、表示回数やクリックなど集計データのみが提供されるようで、無料サービスを広告で支えるという、動画やSNSでもおなじみの仕組みと同じような体制に。

検索広告の起点が「キーワード」から「意思決定直前」へ

構造的に異なるのは、ChatGPTでは利用者が「東京で3泊、子連れ、予算15万円」「MacBookとWindows PCで迷っている」といった具体的な条件を会話の中で伝えることで、それによりOpenAIは、利用者が選択肢を調べ、比較し、決定する場面を広告価値の中心に据えているのだとか。

従来の検索広告は「ノートPC おすすめ」のような短いキーワードで検索されており、表示されたものに対して利用者自身が複数サイトを回って比較検討する必要がありました。

しかし、会話AIでは、比較そのものをAI側に任せられることから、広告が接触するタイミングは、検索の入口から意思決定の直前へと移り始めています。

この流れはOpenAIだけのものではなく、GoogleはAI Modeが月間10億人超に達したとし、会話型検索の中で商品やサービスを提示する新しい広告形式を開発しているようですよ。

なぜ今なのか、計算資源9.5倍という背景

この動きの背景には、AIサービスを支える運営コストの急拡大がああるようで、OpenAIによれば、同社が利用できる計算資源は2023年の0.2GWから2025年には約1.9GWへ、9.5倍に増えていて同期間に年間経常収益も、20億ドルから200億ドル超へ拡大しているとはいえ、より多くの計算資源を確保するため、OpenAIでは、サブスクリプション、API、コマース、広告を組み合わせる方針を示しています

広告導入は単なる収益源の追加ではなく、無料利用者を維持しながら巨大な計算コストを賄うための事業構造の一部と見る方が実態に近いようですね。

広告主・メディア・利用者に生まれる利害のねじれ

この変化は関係者に異なる影響を及ぼし、広告主やEC事業者にとっては、検索キーワードでは捉えにくかった具体的な購買意図に接触できる機会が広がる一方、AIが比較を代行すればするほど、利用者がブランド公式サイトに訪れる前に候補から外されてしまう可能性もあり、素直に喜べない部分もあるようです。

さらに最も立場が厳しくなり得るのは、比較サイトやレビューメディアであり「おすすめ10選」といった記事が担ってきた役割をAI自身が果たすようになれば、比較系コンテンツへの検索流入は減っていくでしょうし、皮肉なのは、こうしたメディアの情報がAIの回答を支える材料として使われながら、自サイトへの訪問者は失われるという構図が生じかねないこと。

一般利用者にとっては、比較の手間が減るという利便性があるとはいえ、AIの回答と広告表示の境界を意識することが必要になってきます。

たとえば「3万円以内で仕事用イヤホンを選んで」と聞き、AIが提示した候補の直後にスポンサー商品が表示された場合、どこまでがAIの評価でどこからが広告なのかを利用者自身が見極める場面が増えていくことになるでしょう。

この変化は定着するのか、判断材料は何か

会話型広告が社会に定着する要因としては、AIが検索・比較・商品選択に使われる割合が増えるほど、意思決定直前の利用者に接触できる広告枠に経済的価値が生まれることが挙げられます。

OpenAIだけでなくGoogleも同じ市場を作り始めていることを考えると、この動きが一過性の実験だけではなく、今後の新たな広告枠としてのニーズが高まっていくことは間違いないでしょう。

一方で、広告表示によって回答への信頼が低下し、利用者が有料プランや別サービスへと移動するようになると、広告主にとっての魅力は薄れてしまいますし、健康や金融などの利用者の警戒感が強い領域ではその反発が大きくなり得ることから、OpenAIは、現在もこうした分野への広告表示を強く制限しているようです。

今後を見極めるうえで有効な指標としては、広告対象国や対象プランの拡大が挙げられ、アメリカ以外の国へ急速に広がるようになれば、事業化が進んでいることにもなるでしょうし、限定テストが長期化するようであれば慎重姿勢が続いていると考えていいでしょう。

また、この流れで登場してきそうなのは、広告主自身が出稿できるセルフサービス化やCPC入札、コンバージョン計測の拡大であり、OpenAIはすでにAds Managerの整備を進めているようで、この機能がどこまで拡張されるかは、広告市場としての成熟度を測る手がかりになりそう。

さらに、AI内で決済や予約まで完結する機能が広がるかどうかも、今後の広告のあり方の流れを左右してきそう。

「答える場所」から「決める場所」への移行をどう見るか？

今回の広告導入は、単なる無料サービスの収益化策ではなく、検索・比較・購入という別々に行われてきた行動が一つのAI画面に統合されていく過程の一部と捉えられます。

高額な買い物では、AIが示す候補だけで判断せず、メーカー公式情報や第三者のレビューを別途確認することが引き続き有効ではありますし、ブログやECを運営する側にとっては、検索順位だけを重視する発想から、AIが理解し比較しやすい形で一次情報を公開する発想への転換が、今後の課題として浮かび上がってきます。