MCP・ACP・AIスキルの違い：目的から選ぶ接続方法
モデルの接続先、MCPツール、ACPのコーディングエージェント、スキル、定期タスクを具体例で使い分けます。
アシスタントに課題を読ませたい、バグを直させたい、毎週のチェックを繰り返させたい。「連携を追加する」だけでは、どの構成が必要かは分かりません。モデルのエンドポイント、MCP、ACP、スキル、スケジュールは、それぞれ仕事の別の部分を受け持ちます。
まずやりたい動作を決め、何が足りないかを探します。プロトコルを足しても、より良いモデルが手に入るわけでも、アカウントにサインインできるわけでも、パソコンが電源オンのままになるわけでもありません。このガイドは、ReunifiedのMonoや似たアプリで、動く範囲でいちばん小さな構成を選ぶ手助けをします。
1. 足りない能力を見分ける
プラグインを探す前に、この表を使ってください。
| 直近の目的 | 最初に確認するもの |
|---|---|
| 文章の返答に別のモデルを使いたい | モデルのエンドポイント設定 |
| 別のサービスの情報を読み書きしたい | 適切なMCPサーバーや組み込みの連携 |
| コーディングエージェントとリポジトリで作業したい | ACPクライアントとエージェントが一緒に動くか |
| まとまった処理を再利用したい | スキルと、それに必要なもの |
| すでに動く処理を繰り返したい | スケジューラーと、それが動く場所 |
これは出発点で、組み合わせて使うことも多くあります。スキルがMCPを使うことも、コーディングエージェントがツールを呼ぶことも、定期タスクがスキルを実行することもあります。すべての層を入れるのではなく、最初に足りない部分を見つけましょう。
2. 外部サービスの能力にはMCPを使う
Model Context Protocol（MCP）は、AIアプリとサーバーが提供する機能をつなぎます。公式の構成説明では、それをツール、リソース、プロンプトに分けています。サーバーが提供するのは、そのうち一つの場合も複数の場合もあります。
たとえば、プロジェクト管理サービスの未解決の課題を一覧にしたいとします。その検索を提供する接続と、プロジェクトを読む権限のあるアカウントが必要です。課題を検索できるサーバーが、課題を作ったり閉じたりできるとは限りません。
サーバーが実際に何をできるかを確かめ、読み取りだけの小さなリクエストで試します。設定の手順はMCP接続ガイドを見てください。言語モデルを変えても、プロジェクトのアカウントにアクセスできるようにはなりません。
3. コーディングのセッションにはACPを使う
Agent Client Protocol（ACP）は、コーディングエージェントとエディターなどのクライアントがどうやり取りするかを決めています。ACPの紹介で説明されています。エージェントはリポジトリで作業し、クライアントはあなたがエージェントに指示を出す画面です。
「この失敗しているテストを見つけて直して」という作業なら、エージェント、クライアント、それを動かすパソコンが一緒に動くかを確認します。同じプロトコルを使っていても、組み合わせで試されたとは限りません。リポジトリとコマンドには、必要なアクセス権とツールがそろったパソコンが今でも必要です。
スマートフォンは、作業を動かすパソコンでなくても、その作業を操作できます。Mono Codeでは、パソコンがプロジェクトを置き、スマートフォンからACPでClaude Code、Gemini CLI、OpenCodeなどのエージェントを操作します。リモート開発ガイドでは、小さな作業、承認、再接続について説明しています。ACPは常時稼働のクラウドのパソコンを用意するものではなく、エージェント提供元の料金を払うものでもありません。
4. 再利用する処理にはスキルを使う
「スキル」の意味は製品によって違います。Monoのスキルは、モジュール、パラメーター、ほかのサービスとの接続を含められるアドオンです。別の製品では、指示を書いた文書や別形式のパッケージを指すこともあります。ある製品のスキルが別の製品で動くとは考えないでください。
「毎週このメモを同じ形に整える」という作業なら、まずスキルが何を受け取り、何を返すかを確認します。渡したテキストだけを使うこともあれば、モデルを呼んだり、接続を通じて情報を取ってきたりすることもあります。どれも設定が増え、失敗しうる箇所が一つ増えます。
スキルの導入確認ガイドで、スキルに必要なものを確認し、結果を一つ試してください。インストールできても、今日そのデータ元が動いていることや、すべての端末で動くことの証明にはなりません。
5. 動作確認後に予定を追加する
スケジューラーが決めるのは、作業を始めるタイミングです。足りない入力や権限を補ってはくれません。毎週のプロジェクト要約なら、まず手動で正しい項目を取得し、役立つ要約ができることを確認します。そのうえで、必要な時刻にどこで動かすかを決めます。
Monoのタスクは端末上で動き、アプリを閉じている間に逃したタスクは、次にアプリを開いたときに実行されます。そのため、スマートフォンの電源が切れている間に時間どおり動くとは期待しないでください。パソコンでのコマンドが必要なタスクには、そのパソコンも必要です。スケジュールを設定しても、コマンドがスマートフォンに移るわけではありません。
予定した結果が届かないときは、モデルを変える前に、タスクがどこで動くかを確認します。サービスが認可エラーを返すときは、コーディングエージェントを入れ直す前に、そのアカウントの接続を確認します。
6. 自分の構成を五行にまとめる
モデル、外部サービス、再利用する処理、コーディング用のパソコン（あれば）、スケジュール（あれば）の五行を書きます。使わない行は空けておきます。使う部分ごとに、誰が動かすのか、どんな情報を受け取るのか、誰が料金を請求するのかをメモします。
簡単な文章作成ならモデルだけで足りることもあります。リポジトリの修正には、ACPエージェントとパソコンが必要でも、新しいMCP接続は不要かもしれません。サービスの週次まとめには、接続、スキル、動いているスケジューラーが必要になることがあります。
Monoはまだ公開前ですが、ウェイトリストに登録できます。それまでは、この地図を使って、説明でき、試せる構成を計画してから広げていきましょう。
