# 配信は AI エージェントに任せる。エージェンシーの新しい組織と回し方

_2026-08-19 · 配信を AI エージェントが担い、戦略と承認を人が持つとき、エージェンシーは役割、週次の流れ、クライアントのワークスペース、API キーをどう組み直すべきかを解説します。_

配信に AI エージェントを使うエージェンシーは、ストラテジスト、エディター、クライアント担当という3つの人の役割と、エージェントを運用する技術責任者1名を軸に組織を組み直すべきです。承認済みのアイデアから、多数のアカウントでの予約投稿までの制作ラインはエージェントが担います。方向性、品質、クライアントとの関係は人が持ちます。そして週次の流れは、エージェントが出したものがすべて、公開前に必ず人の目を通るように設計します。

多くのエージェンシーは、既存の体制にエージェントを後付けして「なぜ何も良くならないのか」と首をかしげます。従来の体制は、足りないのは「手」だという前提で作られていました。手が安くなれば、足りなくなるのは判断力とレビューの時間です。体制はそこを中心に設計し直す必要があります。

## 制作がボトルネックでなくなると、何が変わるのか

従来の SNS エージェンシーでは、アカウント担当者が週の大半を制作に費やします。バリエーションを書き、アップロードし、予約し、リンクを集め、レポートを作る。その人の処理量が、エージェンシーが抱えられるアカウント数の上限になっていました。

配信プラットフォームにつないだエージェントがあれば、50アカウントにまたがる1つのキャンペーンの制作も、1回の指示で走らせる作業になります。制約は上流の「そのアイデアは良いのか、承認されているか」と、下流の「結果を誰かが読んだか」に移ります。この2点に人を置かなければ、エージェンシーは平凡な投稿をより速く量産するだけです。

## エージェンシーに必要な役割は

| 役割 | 責任範囲 | 主な仕事 | やらないこと |
|---|---|---|---|
| ストラテジスト | クライアントごとの月間テーマ、オファー、オーディエンス | 企画、結果の読み込み、クライアントとの戦略ミーティング | アカウント別キャプションの執筆 |
| エディター | エージェントの出力品質 | 下書きのレビュー、エージェントのルールの改善 | 手作業での予約 |
| クライアント担当 | 関係性と承認 | 承認リンクの送付、フィードバック対応 | 制作 |
| エージェント運用担当 | キー、スキル、プロンプト、監査 | クライアント横断でのエージェント設定の保守 | コンテンツの判断 |

小さなエージェンシーなら、1人が2つの役割を兼ねても構いません。大事なのは、どの責任にも担当者の名前がついていることです。エージェント運用担当はほとんどのチームにとって新しい役割で、抜け落ちがちです。プロンプトが少しずつずれていき、どのキーがどこに公開できるのか誰も把握していない、という状態はここから生まれます。

## クライアントのアカウントはどう構成すべきか

構成次第で、エージェントがうっかり触れてしまう範囲が決まります。

1. **クライアントごとに1つのワークスペース。** 各クライアントのアカウントは、それぞれ専用のワークスペースに置きます。クライアント A の作業をしているエージェントの一覧に、クライアント B のチャンネルが並ぶことはありません。
2. **クライアントの組織図に合わせたグループ。** 地域、ブランド、言語、フランチャイズの階層などです。エージェントは `group_ids` を指定して投稿先を決め、ストラテジストはスプレッドシートなしで「北エリアの全店舗」といった単位で考えられます。
3. **接続はクライアント自身が行う。** クライアントは接続リンクから自分の SNS アカウント（Facebook、Instagram、YouTube、X、LinkedIn、TikTok）を接続するので、パスワードがエージェンシーを経由することはありません。流れの全体は[クライアント向け接続リンク](/en/blog/client-connect-links)をご覧ください。
4. **キーは仕事に合わせて権限を絞る。** 下書きを作るエージェントには `read` と `write` を。`publish` を持たせるのは予約を行うステップだけです。すべての呼び出しはエージェントダッシュボードの監査ログに記録されます。詳しくは[API キー、スコープ、監査](/en/blog/api-keys-scopes-and-audit)の記事で解説しています。

1つのエージェントで多数のクライアントを運用するなら、この分離はさらに重要です。作業が他のクライアントに混ざらないためのプロンプトとキーの設計は、[1つのエージェントで多数のクライアントを回す](/en/blog/one-agent-many-clients)ガイドにまとめています。

## 週次の流れはどうなるか

10から数百アカウントを運用するエージェンシーで機能する流れを紹介します。曜日はあくまで例で、大事なのは順番です。

1. **月曜：企画。** ストラテジストがクライアントごとに1ページのブリーフを書きます。テーマ、オファー、素材、対象グループ、投稿日、そして法務的な注意が必要な表現です。
2. **月曜午後：エージェント実行。** エージェント運用担当が実行を開始します。エージェントはメディアをアップロードし、アカウント別のキャプションを書き、下書きを作成します。
3. **火曜：編集レビュー。** エディターが下書きの束をすべて読みます。問題はエージェントのルール側で直してから実行し直すので、同じ問題が翌週また出てくることはありません。
4. **火曜午後：クライアント承認。** クライアント担当が承認依頼を送ります。クライアントはログインせずに承認できます。
5. **水曜：予約。** 承認された投稿を、アカウント間で配信タイミングをずらして予約します。
6. **金曜：結果の確認。** エージェントがアカウント別・投稿別のクリック数を取得して短いサマリーを書き、ストラテジストが翌週に何を変えるかを決めます。

ステップ1のブリーフこそ、この仕組み全体でいちばん重要な成果物です。曖昧なブリーフからは、曖昧な投稿が大量に生まれます。

## 月曜のエージェント実行は具体的にどうなるか

エージェント運用担当は通常、毎週同じ内容になるよう実行手順をスキルにまとめておきます。ルールは別の場所にあるので、毎週の指示は短くて済みます。

```text
Run the weekly distribution routine for workspace "Northwind Bakeries"
using brief 2026-W38 (attached).
Groups: "City stores", "Mall kiosks".
Formats: REEL for the video, FEED for the two photos.
Draft only. When done, request approval for all drafts and return the links.
```

この指示の裏で呼ばれるツールは次のとおりです。

```text
whoami                    check scopes: expect read, write
list_workspaces           select "Northwind Bakeries"
list_groups               resolve "City stores", "Mall kiosks"
list_channels             fetch account names for localization
upload_media_from_url     once per asset, with width, height, duration_ms for the Reel
create_post               per asset: caption, group_ids, media_ids, format,
                          per_channel[...], first_comment, cta_url,
                          campaign "w38-autumn-menu", label "agent-draft"
request_approval          per post, returns a link for the client
```

`campaign` と `label` のフィールドは単なる整理用に見えますが、誰も手作業で投稿にタグ付けせずに金曜のレポートを作れるのは、これがあるからです。このルーティン自体を再利用できるスキルにまとめたい場合は、[週次配信ルーティン](/en/blog/skill-weekly-distribution-routine)をご覧ください。

## 料金はどう設定すべきか

投稿コストが下がれば、投稿単位の課金はあまり意味をなさなくなります。このモデルに移行したエージェンシーの多くは、運用アカウント数に応じて料金を設定し、戦略とレポーティングをリテイナー契約の中核に据えています。プラットフォーム側では、Shager は接続アカウント数で料金が決まり、すべてのプランに API アクセス、MCP、ユーザー数無制限が含まれます。エージェントやレビュアーを増やしてもシート料金は増えません。現在のプランは[料金ページ](/en/pricing)に掲載しています。

## よくある失敗パターンは

1つ目は、「エージェントはもう十分優秀だから」と編集レビューを省くことです。ずれは少しずつ進みます。週に一度読んでいれば、早い段階で気づけます。

2つ目は、メンバー全員が自分のプロンプトを使うのを放置することです。同じクライアントについて2人が同じエージェントに別々の指示を出すと、ブランドのトーンは崩れていきます。スキルはクライアントごとに1つにし、変更するときは意図を持って行いましょう。

3つ目は、金曜の数字を誰も読まないことです。アカウント別の結果を誰も活かさなければ、エージェンシーが生み出しているのは成果ではなく、ただの量です。

## よくある質問

### エディター1人で週に何アカウント分レビューできますか？

投稿の長さ、バリエーションの数、エージェントのルールがどこまで練られているかによります。最初のうちはまだルールを直している段階なので、レビューに時間がかかります。最初の1か月はクライアントごとのレビュー時間を記録し、自社のデータをもとにキャパシティを決めてください。

### エージェントがキャプションを書いていることを、クライアントに伝えるべきですか？

伝えることをおすすめします。エージェントが下書きを作り、担当エディターがレビューしてから承認依頼が届く、という流れを説明しましょう。多くのクライアントが気にしているのは品質と責任の所在で、このモデルはその両方に応えられます。

### 運用するのに開発者は必要ですか？

必要ありません。エージェント運用担当に求められるのは、API キーの扱いとスキルファイルの編集に慣れていることで、ソフトウェア開発ではありません。MCP の接続は設定作業であり、コードを書く必要はありません。

まずは中規模のクライアントを1社選び、ワークスペースとグループを設定して、ほかは何も変えずに月曜から金曜までの流れを2週間回してみるのがおすすめです。

---
Source: https://shager.ai/ja/blog/agency-operating-model-with-agents