# AI エージェントのための配信プラットフォームの選び方：12の基準

_2026-10-07 · AI エージェントが動かせる SNS 配信プラットフォームを選ぶ12の基準。MCP と API、スコープ付きキー、監査、アカウント別のバリエーション、料金。_

AI エージェントのための配信プラットフォームを選ぶときは、エージェントがそれを通して仕事を最初から最後までこなせるかを試してください。人が画面をクリックして回らなくても接続できるか、正しいアカウントを見つけられるか、アカウントごとに変化をつけた投稿を作れるか、承認を待てるか、安全に予約できるか、アカウント別に結果を読めるか。そのうえで、それを取り巻く管理の仕組みを確認します。キーのスコープ、監査ログ、各ネットワークの公式 API、そして自動化に不利にならない料金体系です。人向けに設計され、あとから API が追加されたプラットフォームは、たいていこのうちの2〜3点でつまずきます。エージェントのプロジェクトが止まるのは、まさにその穴です。

以下の12の基準は、自社のものも含め、どのプラットフォームを評価するときにも私たちが使うものです。アクセス、管理、配信の品質、ビジネスとの適合の4つに分かれ、最後に午後半日で実施できる短い実地テストを紹介します。

## 「API がある」だけでは判断できなくなったのはなぜか

ほとんどの SNS ツールは、何年も前から API を提供しています。そうした API は、たいてい連携機能を作る開発者向けに作られていました。ドキュメントを読み、コードを書き、認証を処理し、フィールドを対応づける。エージェントの動き方は違います。実行時にオペレーションを発見し、説明を読んで何を呼ぶかを決め、対処に使える構造化されたエラーを必要とします。エージェントを前提に作られたプラットフォームは、[Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro) のような標準を通じてオペレーションをツールとして公開し、わかりやすく説明し、キーごとにできることを制限します。MCP が初めてなら、まずは[マーケター向けの解説](/en/blog/mcp-explained-for-marketers)からどうぞ。

## アクセス：エージェントはプラットフォームにすんなりたどり着けるか

### 1. リモート MCP サーバー

エージェントは、ローカルにインストールせず URL で接続できるべきです。トランスポートを確認しましょう。MCP の仕様は、リモートサーバー向けに [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports) を定義しています。あわせて、認証の仕組みと、それによってどのクライアントが使える、あるいは使えないのかも確認します。

### 2. OpenAPI の記述を備えた、文書化された REST API

すべての作業がアシスタントの中で行われるわけではありません。定期実行のジョブや社内ツールは、API を直接呼び出します。OpenAPI の記述、たとえば [Shager の OpenAPI 3.1 ファイル](https://app.shager.ai/api/v1/openapi.json)があれば、開発者やコード生成ツールも MCP のツールと同じオペレーションを使えます。レスポンスとエラーの形式が一貫しているかも見てください。エージェントは HTML のエラーページより、`{ "error": { "code", "message" } }` からのほうがはるかにうまく立ち直れます。

### 3. エージェントの自己登録と、人による引き継ぎ

エージェントが自分でトライアル用のワークスペースを作り、所有権を引き継ぐためのリンクを人に渡せるか。これができれば、評価でいちばん時間のかかるステップがなくなります。安全装置として、人が引き継ぐまでサンドボックスには制限がかかっている必要があります。Shager の[エージェント向け登録手順](/auth.md)はこの仕組みです。引き継がれていないサンドボックスでは下書きは作れますが、予約、公開、承認依頼の送信、接続リンクの作成はできません。

## 管理：エージェントの行動を制限し、把握できるか

### 4. スコープ付きのキー

読み取り、書き込み、公開の権限が分かれていることは、エージェントが運用する配信でいちばん重要な管理機能です。これがなければ、プロンプトと公開投稿の間にあるのは、モデルの解釈だけになります。

### 5. エージェントの呼び出しの監査ログ

エージェントが行ったすべての呼び出しについて、どのキーで、いつ行われたかを確認できる必要があります。ログがプロダクト内でチームに見えるのか、サポートに問い合わせないと見られないのかを確認しましょう。

### 6. 下書きと承認の状態が正式な機能として扱われているか

エージェントが下書きを作り、承認を依頼し、状態を確認し、そのあとで初めて予約する。これらがすべてツールを通じてできるべきです。クライアントの承認にクライアント側のアカウント作成が必要なら、承認は滞ると思っておきましょう。チェックポイントを下書きと予約の間に置くべき理由は、[エージェントの投稿を人が承認する](/en/blog/human-approval-for-agent-posts)の記事で説明しています。

## 配信の品質：規模が大きくなっても、安全で効果的な出力になるか

### 7. 1回の呼び出しで、アカウントごとのバリエーション

1回の投稿リクエストの中で、アカウントごとに違うキャプション、最初のコメント、フォーマットを指定できる方法があるかを確認します。それがなければ、エージェントはすべてのアカウントに同じキャプションを送るか、アカウントごとに1回ずつ呼び出すかのどちらかになり、後者は遅いうえに管理も大変です。

### 8. 配信タイミングの分散と送信前の検証

多数のアカウントに同じ秒で送信するのは、プラットフォームが監視しているパターンです。アカウント間で配信の間隔を空け、その幅を設定できるか。そして、送信前に各投稿を投稿先ネットワークのルールに照らして検証するかを確認しましょう。

### 9. 各ネットワークの公式 API のみ

プラットフォームがどうやって公開しているのか、率直に聞いてください。ブラウザーの自動操作やログイン情報の共有は、ネットワークの規約上、クライアントのアカウントを危険にさらします。これは「はい」か「いいえ」で答えられる質問で、答えは書面でもらうべきです。

### 10. アカウント別の貢献分析

エージェンシー向けのプラットフォームなら、アカウントごとに計測リンクを生成し、アカウント別・投稿別のクリック数を API で返すべきです。そうすれば、エージェントが週次の振り返りを作れます。

## ビジネスとの適合：エージェンシーの収支に合うか

### 11. パスワードなしのクライアントオンボーディング

クライアントがアカウントを作らず、ログイン情報も共有せずに、リンクから自分のアカウントを接続できるべきです。また、人が許可したあとは、エージェントが API でそのリンクを作れるべきです。

### 12. 自動化に課税しない料金体系

API と MCP のアクセスがすべてのプランに含まれているのか、上位プラン限定なのか。レビュアーが1人増えるごとにシート料金がかかるのか。アカウント数に応じて料金がどう増えるのか。これらを確認しましょう。エージェンシーはアカウント数で成長するので、シート単位の課金より、ユーザー数無制限のアカウント単位の課金のほうが合うのが普通です。すべてのプランに API、MCP、ユーザー数無制限が含まれる Shager のプランは、[料金ページ](/en/pricing)に掲載しています。

## 候補をどう採点するか

シンプルなシートを使います。各基準を0、1、2で採点し、自社にとって必須の基準には印を付けます。

| 基準 | 必須か | プラットフォーム A | プラットフォーム B | プラットフォーム C |
|---|---|---|---|---|
| 1. リモート MCP サーバー | はい |  |  |  |
| 2. OpenAPI 付きの REST API |  |  |  |  |
| 3. 自己登録と引き継ぎ |  |  |  |  |
| 4. スコープ付きのキー | はい |  |  |  |
| 5. 監査ログ | はい |  |  |  |
| 6. 下書きと承認の状態 |  |  |  |  |
| 7. アカウント別のバリエーション |  |  |  |  |
| 8. 分散配信と検証 |  |  |  |  |
| 9. 公式 API のみ | はい |  |  |  |
| 10. アカウント別の貢献分析 |  |  |  |  |
| 11. クライアント向け接続リンク |  |  |  |  |
| 12. 料金の適合 |  |  |  |  |

どの項目が必須かは、ビジネスによって異なります。ここで印を付けた4つは、クライアントの仕事で私たちが妥協しない項目です。

## どんな実地テストをすべきか

ドキュメントからわかるのは、プラットフォームが何を意図しているかです。エージェントが実際に何をできるかは、テストしないとわかりません。各候補に、同じアシスタントで同じタスクを与えましょう。

1. **接続する。** アシスタントに MCP サーバーを追加します。かかった時間を計ります。
2. **発見させる。** 「このプラットフォームで何ができる？」と聞きます。よいサーバーなら、ツールの説明をもとにアシスタントが正確に答えられます。
3. **作らせる。** 3つのアカウントそれぞれに違うキャプション、リンク付きの最初のコメント、縦型の動画を付けた下書きを作るよう、エージェントに頼みます。
4. **壊してみる。** リールには合わないサイズの動画を渡します。エージェントが説明して直せるほど、エラーがわかりやすいかを見ます。
5. **止めてみる。** 公開権限のないキーで、エージェントに予約を頼みます。きちんと拒否されるはずです。
6. **承認させる。** クライアント役の同僚に承認依頼を送ります。その人にアカウントが必要だったかを記録します。
7. **読ませる。** 過去の期間について、アカウント別のクリック数を求めます。
8. **監査する。** エージェントがたった今行ったことすべての記録を探します。

Shager の場合、ステップ1〜8は `whoami`、`list_workspaces`、`list_channels`、`upload_media_from_url`、`per_channel` を使った `create_post`、`request_approval`、`schedule_post`、`get_analytics` に対応し、監査ログはエージェントダッシュボードにあります。

## よくある質問

### 各ネットワークの API の上に、自前の配信レイヤーを作るべきでしょうか？

作ることはできますし、実際に作っている大きなチームもあります。各ネットワークのアプリ審査、トークン管理、フォーマットの検証、レート制限、継続的な API の変更にかかるコストを、それらをすでに扱っているプラットフォームと比べて検討してください。ほとんどのエージェンシーにとって、自前で作るコストを正当化するのは難しいでしょう。

### 評価にはどのくらいの期間をかけるべきですか？

上の実地テストは、プラットフォーム1つにつき午後半日で終わります。そのあと、契約を決める前に、クライアント1社分の本物の下書きで2週間試してみてください。

### プラットフォームは、最初からすべてのネットワークに対応している必要がありますか？

必要なのは、クライアントが今使っているネットワークに対応していて、残りについても信頼できる計画があることです。Shager は現在、Facebook ページ、Instagram のプロアカウント、YouTube チャンネル、X アカウント、LinkedIn の個人プロフィールに公開できます。TikTok にも対応していますが、TikTok がアプリを承認するまでは、投稿先は非公開アカウントに限られ、投稿も非公開として公開されます。

Shager が候補に入っているなら、エージェントがサンドボックスを登録して自分でテストを始められます。[エージェント向けの入口](/en/agents)には、クライアントごとのセットアップ手順があります。

---
Source: https://shager.ai/ja/blog/choosing-a-distribution-platform-for-agents