クライアント向けの週次レポートを、毎週月曜の朝までにエージェントが書き上げる
Shagerのデータからエージェントがまとめる週次レポートの作り方。公開済み・失敗した投稿、アカウント別・投稿別のクリック、CRMのリードとの突き合わせ。
クライアント向けの週次配信レポートは、エージェントに書かせることができます。Shager から取得するのは3つです。その週に公開された投稿とアカウントごとの結果、get_analytics によるアカウント別・投稿別のクリック、そして失敗したものの一覧です。そのうえで、各アカウントを識別する utm_content の値を使って、クリックをクライアントの CRM にあるリードと突き合わせます。読み取り専用のキーで定期実行すれば、月曜の朝にはフォルダにレポートが届いています。
頭を使うべきはコードではありません。クライアントが本当に見る必要があるものは何かを決め、数字が何を測っているのかを正直に示すことです。
週次の配信レポートに何を入れるべきか
4つのセクションで十分です。それ以外は月次の振り返りに回します。
- 配信状況。 何件の投稿が、いくつのアカウントに出たか。どのアカウントで失敗したか。クライアントは何かが抜け落ちるまでこの点をほとんど気にしませんが、いざ抜け落ちると、それしか聞いてこなくなります。
- アカウント別のクリック。 どのページ、支店、チャンネルがサイトへ人を送ったか。予算配分を変えるのはこのセクションです。
- 投稿別のクリック。 すべてのアカウントを通して、どのコンテンツが効いたか。
- アクション。 クライアントがすべきこと。アカウントの再接続、翌週の下書きの承認、足りない素材の送付などです。
入っていないものに注目してください。リーチ、インプレッション、いいねです。Shager が測るのは、自社の計測リンクのクリックを、アカウント別・投稿別に集計したものです。SNS の分析スイートを名乗るつもりはありませんし、レポートでもそう装うべきではありません。
データを取得する呼び出し
クライアントのワークスペースについて、エージェントは次の順で呼び出します。ツール名は実際の MCP ツールで、対応する REST の操作は OpenAPI ドキュメントにあります。
list_workspacesで、クライアントのワークスペースを名前から特定します。statusをPUBLISHEDにしてlist_postsを呼び、続いてPARTIALLY_PUBLISHEDとFAILEDでも呼びます。limitは最大100です。- その週の各投稿について
get_postを呼び、アカウントごとの状態、公開された URL、エラーメッセージを取得します。 - その週をカバーする
fromとtoを指定してget_analyticsを呼びます。 list_channelsを呼び、チャンネル ID を読みやすいアカウント名に対応づけ、接続状態が変わったアカウントを見つけます。
REST での分析の呼び出しは次のとおりです。
curl -s "https://app.shager.ai/api/v1/workspaces/ws_example/analytics?from=2026-09-14T00:00:00%2B03:00&to=2026-09-20T23:59:59%2B03:00" \
-H "Authorization: Bearer $SHAGER_READ_KEY"
この URL には、つまずきやすい点が2つあります。クエリ文字列の中では、オフセットの + を %2B にエンコードしないと、サーバーにスペースとして読まれてしまいます。また、週の区切りはサーバーではなくクライアントのタイムゾーンで計算すべきです。from を省略すると get_analytics はデフォルトで直近30日を返しますが、週次レポートで欲しいのはそれではありません。
クリックはリードではない。だから突き合わせる
Shager は各アカウントに専用の短縮リンクと UTM タグを付け、utm_content でアカウントを識別します。これがあるから突き合わせができます。CRM には、ランディングページのフォームで取得した UTM の値とともにリードが記録されます。エージェントはそれを、同じ utm_content をキーにして、Shager のアカウント別クリック数と照合します。
こうしてできる表が、レポートの中心です。
| アカウント | 投稿数 | クリック（Shager） | リード（CRM） | メモ |
|---|---|---|---|---|
| Aurora 中央店 | 4 | ... | ... | |
| Aurora 北口店 | 4 | ... | ... | 再接続が必要 |
列どうしの差も情報です。クリックが多いのにリードがゼロなら、それは配信ではなく、ランディングページかオファーの問題です。リードの列を信頼できるものにするフォームの項目と CRM のマッピングについては、以前のガイドアカウント単位のリード計測で、エージェント側の話はエージェントのコンテンツからリードを測るで解説しています。
CRM にアクセスできなくても、クリックだけでレポートは成り立ちます。その場合はレポートの冒頭にそう明記してください。クリックを「成果」と表記したレポートは、四半期後にエージェンシーが信頼を失う原因になります。
Claude Code で無人実行する
Claude Code は、ヘッドレスのドキュメントにあるとおり、claude -p で非対話的に実行できます。これで週次レポートを cron のジョブにできます。
まず、レポート用のプロジェクトフォルダを用意し、キーを環境変数から読む .mcp.json を置きます。Claude Code の MCP のドキュメントによると、ヘッダー内で ${VAR} の展開が使えます。
{
"mcpServers": {
"shager": {
"type": "http",
"url": "https://app.shager.ai/api/mcp",
"headers": { "Authorization": "Bearer ${SHAGER_READ_KEY}" }
}
}
}
次に指示を書きます。ロジックを crontab の1行ではなく1つのファイルに収めるため、スキルとして保存します。スキルのドキュメントのとおり、Claude Code はプロジェクトのスキルを .claude/skills/<name>/SKILL.md から読み込みます。
---
name: weekly-report
description: Compile the weekly distribution report for one client workspace from Shager. Use when asked for a weekly client report.
---
The argument is the client workspace name: $ARGUMENTS
1. Resolve the workspace with list_workspaces. Read its timezone.
2. Compute last Monday 00:00 to Sunday 23:59:59 in that timezone, with offsets.
3. Collect posts with list_posts (PUBLISHED, PARTIALLY_PUBLISHED, FAILED) and
keep those published in the window. Call get_post for each.
4. Call get_analytics for the window. Map channel ids to names with list_channels.
5. If crm/<workspace>.csv exists, join leads on utm_content.
6. Write reports/<workspace>/<YYYY-MM-DD>.md with four sections: Delivery,
Clicks by account, Clicks by post, Actions. Use tables. No adjectives about
performance; numbers and one plain sentence per section.
7. Never call any tool that creates, schedules or cancels anything.
そして定期実行するコマンドです。事前に許可するのは、読み取り系のツールとファイルの書き込みだけです。
cd ~/agency-reports && claude -p "/weekly-report Aurora" \
--allowedTools "mcp__shager__list_*,mcp__shager__get_*,mcp__shager__whoami,Write" \
--output-format json > logs/aurora-$(date +%F).json
mcp__<server>__ という接頭辞と末尾のワイルドカードを使った許可ルールの構文は、Claude Code の権限のリファレンスに記載されています。無人実行では、このリストにないものは自動で許可されません。
ここで読み取り専用のキーが重要な理由
スキルはモデルに「書き込むな」と指示します。キーは、それを不可能にします。レポート用に read スコープだけを持つ別のキーをエージェントダッシュボードで作成し、他の用途には使わないでください。万一そのキーが漏れても、最悪の場合に起きるのは、誰かにクリック数を見られることだけです。スコープの全体像は API キー、スコープ、監査で説明しています。
レポート用エージェントの呼び出しはすべて、同じダッシュボードの監査ログにも表示されます。最初の数回の月曜日に、想定どおりの呼び出しだけをしていて、それ以上のことはしていないかを確かめるのに役立ちます。
文章の部分を書かせる
各セクションに1〜2文の説明をエージェントに書かせるのはよいのですが、制約をかけてください。ルールがないと、モデルは4%の変化を「大幅な増加」と書いてしまいます。私の指示は単刀直入です。数字を示し、前週のデータがあれば比較し、データが示していない限り原因には触れないこと。ある支店のページのクリックがゼロだったのが、火曜日に接続が切れたからなら、それはデータが示す原因です。「オーディエンスの飽き」はそうではありません。
よくある質問
エージェントにレポートを直接クライアントへ送らせることはできますか？
メール用のツールを渡せば可能ですが、初日からはおすすめしません。まずはファイルを書かせ、数週間分の出力を確認してから、送付を自動化しましょう。レポートは、クライアントがあなたの仕事を見る窓です。誤った数字が自動で送られれば、節約した時間よりも大きな代償を払うことになります。
get_analytics にリードは含まれますか？
いいえ。返すのは、指定した期間内の Shager の計測リンクのクリックを、アカウント別・投稿別に集計したものです。リードはクライアントの CRM やフォームツールから取得し、utm_content で照合します。レポートでは、この2つのデータソースをはっきり分けて見せるべきです。
レポートはどこまでさかのぼれますか？
get_analytics は送った from と to をそのまま受け付け、from を省略した場合のデフォルトは直近30日です。前月比を出すなら、過去のレポートを正しいデータとして保存しておくのではなく、期間を変えて同じスキルを実行してください。
次のステップ
まだキーを持っていない場合は、エージェント向けページで、キーの作り方やエージェントに自己登録させる方法を確認できます。まずは1社のクライアントで始め、3回分の月曜のレポートを自分で読んでから、残りのクライアントに広げましょう。
