広告運用のインフラを自社で持つということ
広告運用のデータを確認するために、毎回管理画面にログインしてレポートを手動でダウンロードする。多くの運用者がこの作業を当たり前だと思っている。だが、この「当たり前」のコストは積もると膨大だ。
自社でAPIツールを持てば、「先週の指名検索の数字を見せて」とAIに一言伝えるだけでデータが返ってくる。意思決定のスピードが根本的に変わる。Yahoo!広告をClaude Codeから操作するためのMCPサーバーを自作したのは、そうした運用基盤を自社に持つためだった。
しかし、自社ツールには「壊れていることに気づかない」という致命的なリスクがある。管理画面ならデータが表示されなければすぐにわかるが、APIツールの場合、エラーが返っていてもそれに気づくのは実際にデータを取りに行ったときだけだ。ある日、日常的な確認作業でYahoo!広告の指名検索データを取ろうとしたところ、3つのAPI全てが400 Bad Requestを返した。全滅だった。
原因の特定：APIの仕様変更という落とし穴
最初に認証を疑ったが、トークンは生きていた。問題はもっと根深いところにあった。MCPサーバー経由ではHTTPステータスコードしか見えないため、直接APIを叩いてレスポンスボディを確認したところ、accountIdがnullだというエラーが返ってきた。値は確かに送っている。にもかかわらずnull扱いになる。
この現象には重要な教訓がある。Yahoo!広告APIは、認識できないフィールド名を受け取ると、そのフィールドの値をnullとして扱う。つまり「値がnullだ」というエラーメッセージの本当の意味は、「そのフィールド名をAPIが知らない」ということだった。
フィールド名の不一致——APIバージョン更新の地雷
調査の結果、問題はAPIバージョンv18でのフィールド名変更だった。たとえばAccountService/getはaccountId（単数）ではなくaccountIds（複数形・配列）を期待するようになっていた。たった一文字の違いで全く動かなくなる。
さらにレポート関連のフィールド名も軒並み変更されていた。公式リファレンスと照合した結果、修正が必要だったフィールドは以下の通りだ。
dateRangeType→reportDateRangeTypedownloadFormat→reportDownloadFormatIMPRESSIONS→IMPSCONVERSION_RATE→CONV_RATECOST_PER_CONVERSION→COST_PER_CONV
1つ直すと次のフィールドでエラーが出る。APIの仕様書をその都度確認しながら、モグラ叩きのように1つずつ潰していった。
設計の欠陥——ツールが「動いているふり」をしていた
フィールド名の問題よりも深刻だったのは、レポート取得のフロー自体が不完全だったことだ。Yahoo!広告のレポート取得はレポート定義の作成、完了の待機、CSVダウンロードという3ステップで構成されるが、元のコードはステップ1だけ実行して、ジョブ作成の確認JSONをそのまま返していた。つまり、実際のレポートデータは一度も取得できていなかった。
これが「壊れていることに気づかない」問題の核心だ。ツールは一見動いているように見える。エラーも出ない。しかし返ってくるのはレポートデータではなくジョブ作成のレスポンスにすぎない。この状態が何ヶ月も続いていた可能性がある。
フィールド名の修正に加えて、レポート定義の作成からポーリング、CSVダウンロードまでの一連のフローを再実装した。以下はその中核部分だ。
async def _create_and_download_report(self, operand):
report_id = val["reportDefinition"]["reportJobId"]
# 完了を待つ（最大60秒、2秒間隔でポーリング）
for _ in range(30):
await asyncio.sleep(2)
if status == "COMPLETED":
break
# CSVダウンロード
resp = await client.post(
f"{BASE_URL}/ReportDefinitionService/download",
json={"accountId": account_id, "reportJobId": report_id},
)
return resp.text修正後に見えたデータ
全部直した後、改めて指名検索の状況を確認した。
2/25 — 表示：98 / クリック：17 / CTR：17.4% / 費用：¥2,620 / IS：100%
2/26 — 表示：106 / クリック：21 / CTR：19.8% / 費用：¥4,162 / IS：99.1%
2/27 — 表示：100 / クリック：28 / CTR：28.0% / 費用：¥3,621 / IS：98.0%
2/28 — 表示：90 / クリック：18 / CTR：20.0% / 費用：¥2,185 / IS：100%
3/1 — 表示：92 / クリック：12 / CTR：13.0% / 費用：¥1,322 / IS：100%
3/2 — 表示：178 / クリック：50 / CTR：28.1% / 費用：¥5,292 / IS：100%
3/3 — 表示：108 / クリック：20 / CTR：18.5% / 費用：¥3,382 / IS：100%
インプレッションシェア99.6%。指名検索はほぼ完全にカバーできている。キーワード別で見ると自社ブランド名の完全一致が品質インデックス10でCTR 34.2%。ブランドワードとしては健全な数字である。
この「データが見える」という当たり前のことが、ツールの不具合で3ヶ月近くできていなかった可能性がある。もしこの期間にインプレッションシェアが低下していたら、競合にブランドワードを取られていたかもしれない。データが見えないということは、問題に気づけないということであり、気づけない問題は対処できない。自社ツールの信頼性は、広告運用の成果に直結している。
技術の問題ではなく、運用設計の問題
今回の障害は一見すると技術的なデバッグの話に見える。しかし本質は、自社ツールの保守運用をどう設計するかという問題だ。
APIは必ずバージョンアップする。フィールド名が変わり、仕様が変わり、昨日まで動いていたコードが今日動かなくなる。これは避けられない現実であり、「一度作ったら終わり」という前提でツールを構築すると、いつか必ずデータが見えなくなる時がくる。
重要なのは、壊れたことそのものではなく、壊れていることに3ヶ月間気づけなかった運用体制のほうだ。定期的な疎通確認の自動化、APIバージョン更新の監視、エラー時のアラート通知——こうした「メンテナンスの仕組み」を最初から設計に組み込んでおくべきだった。
なぜそれでも自社ツールを持つべきか
こうしたメンテナンスコストがあるにもかかわらず、自社でAPIツールを持つ価値は大きい。管理画面にログインしてレポートをダウンロードする手動作業は、1回あたり数分でも年間では膨大な時間になる。さらに、AIと連携した運用基盤があれば「先週のCTRが低下したキャンペーンを特定して」「予算消化ペースが遅いキャンペーンの入札を調整して」といった高次の判断を自動化できる。このレベルの運用効率は、管理画面の手動操作では到達できない。
ただし、その基盤を構築し、維持し、APIの仕様変更に追従し続けるには、技術と広告運用の両方の知見が必要になる。両方を社内に持てる組織は多くない。
まとめ
広告運用の競争力は、運用者のスキルだけでなく、その運用者がどんなインフラの上で仕事をしているかにも左右される。AIと連携した自社ツール基盤は、意思決定のスピードと精度を根本的に変える。しかし、そのインフラは作って終わりではなく、継続的なメンテナンスが必要だ。
広告運用のインフラを自社で構築・維持するには、技術と運用の両方の知見が求められる。自走が難しければ、パートナーと組むのが現実的だ。「ツールを作る」だけでなく「ツールを動かし続ける」体制まで含めて、運用基盤の設計を考えてほしい。
