ブログやSNSのデータを自動取得し、最終的にはAIで横断分析する「全媒体データ分析基盤」を作っています。
前回はPythonからWordPress、GA4、Google Search Console、Bing、YouTubeへ接続するところまで進みました。
結果だけ見れば「5媒体のAPI連携に成功した」となります。しかし実際には、かなりの時間を認証と権限の問題に使いました。
特に分かりにくかったのが、Google OAuth、Google Cloudの設定、Search Console API、YouTubeのチャンネル権限、Bing Webmaster APIです。
今回は完成した仕組みではなく、実際にどこで詰まり、どう切り分けたのかを記録します。
この記事で分かること
- API連携で「認証」と「権限」が別である理由
- Google系APIで確認するポイント
- YouTubeで正しいチャンネルを取得できなかった原因
- Bing APIでGoogleとは別の対応が必要だったこと
- Codexを使ったAPI開発で人間が確認すべきこと
「APIがある＝簡単に取得できる」ではなかった
当初は、
APIへ接続 → JSONなどを取得 → SQLiteへ保存
という流れを想像していました。
しかし、その前に「誰がAPIへアクセスしているのか」「その人は対象データを見る権限を持っているのか」を確認する必要があります。
ここを理解していないと、データが取得できないたびにPythonコードを疑ってしまいます。
実際には、コードではなく認証・権限・API設定・アカウント構造に原因があることが何度もありました。
Google OAuth｜認証できてもデータを見られるとは限らない
Google系APIで最初に整理する必要があったのがOAuthです。
重要だったのは、
認証に成功したことと、対象データへの権限があることは別
という点でした。
OAuthではAPIごとにアクセス範囲を示す「スコープ」が設定されます。例えばGoogle Analyticsにも読み取り用スコープが用意されています。 (Google for Developers)
しかし、正しいスコープで認証できても、そのGoogleアカウントが対象のGA4プロパティやSearch Consoleプロパティへアクセスできなければ、必要なデータは取得できません。
そのため問題が起きたら、「OAuthが成功したか」だけではなく、どのアカウントで認証し、何への権限を持っているのかまで確認する必要がありました。
Google Cloud側の設定も確認する必要がある
Google APIではGoogle Cloud側の設定も関係します。
どのプロジェクトを使っているのか。
どのAPIを利用するのか。
どのOAuthクライアントを使っているのか。
Python側ではどの認証情報を読み込んでいるのか。
こうした関係が増えると、「APIを設定したはずなのに動かない」という状態が起こります。
特に厄介なのは、問題が起きると新しい認証情報やプロジェクトを作りたくなることです。
今回の開発では、むやみに作り直すよりも、現在どの設定を使っているのかを一つずつ確認する方が原因を見つけやすいと感じました。
Search Console｜管理画面を見られることとAPI利用は別
Search Consoleでも一度詰まりました。
ブラウザでは普通に検索パフォーマンスを確認できるため、最初は「同じGoogleアカウントならAPIからも取得できるだろう」と考えていました。
しかし、管理画面へアクセスできることと、プログラムからAPIを利用することは同じではありません。
API側の設定や認証、対象プロパティへのアクセス権をそれぞれ確認する必要があります。
APIでエラーが出た場合、
「コードがおかしいのか」
「認証なのか」
「権限なのか」
「対象プロパティなのか」
と原因を分けて考えることが重要でした。
YouTube｜エラーが出ないのに間違っていた
今回、特に印象に残ったのがYouTubeです。
API接続自体は成功し、データも返ってきました。
ところが取得されたのは、分析したかったチャンネルではなく、認証したGoogleアカウントに関連する別のチャンネルでした。
これは単純なエラーより厄介です。
プログラム上は成功しているため、「接続できた」と判断できてしまいます。
ここで初めて、
レスポンスが返った＝成功ではない
と実感しました。
取得されたチャンネルIDや名称などを確認し、「本当に目的のデータなのか」までテストする必要があります。
YouTubeのChannel Permissionsにも注意が必要だった
YouTubeにはBrand AccountやYouTube StudioのChannel Permissionsなど、複数の管理方法があります。
ここで重要な仕様があります。
YouTube公式ヘルプでは、Channel Permissionsで招待されたユーザーはYouTubeやYouTube Studio上でチャンネルを管理できる一方、YouTube API経由では管理できないと案内されています。 (Google ヘルプ)
つまり、
ブラウザ上でチャンネルを操作できる
＝
その権限でAPIから同じチャンネルを扱える
とは限りません。
今回のような問題はPythonコードだけを変更しても解決できない可能性があります。
「プログラミングの問題だと思っていたら、実際にはアカウントと権限の問題だった」という代表的な例でした。
Bing API｜Googleとは別物として考える
Google系の接続を経験すると、Bingも似た流れで進められそうに感じます。
しかしBing Webmaster APIはMicrosoft側の仕組みなので、当然ながら認証方法やAPI仕様も異なります。
Microsoftの公式ドキュメントでは、Bing Webmaster APIでOAuth 2.0を利用する場合、Bing Webmaster側でクライアントを登録し、認証情報を取得してアクセストークンを利用する流れが案内されています。 (Microsoft Learn)
Googleで覚えた具体的な操作方法をそのまま使うのではなく、サービスごとの公式仕様を確認する必要がありました。
データ保存についても、Google Search ConsoleとBingの検索データを無理に同一視せず、それぞれの観測値として残す設計にしています。
APIエラーを「層」で切り分けるようになった
今回の経験から、問題が起きたときは原因を一つずつ分けて確認するようになりました。
Pythonコード → APIリクエスト → 認証 → スコープ → 権限 → API設定 → 対象ID → レスポンス内容 → 保存結果
という順番です。
以前は「動かないからコードを修正する」と考えがちでした。
しかしYouTubeのように、コードもAPIも正常なのに対象が違うことがあります。
そのため、最後には必ず期待したデータが取得できているかを人間が確認します。
Codexがいても正解の確認は人間に残る
今回の開発ではCodexを使い、エラー確認やコード修正、テストをかなり効率化できました。
一方でYouTubeの問題では、
API接続成功。
レスポンス取得成功。
データ保存成功。
まで進んでも、目的のチャンネルではありませんでした。
AIはコードを修正できますが、その結果が自分の目的に合っているかは別の問題です。
「このデータは本当に分析したかった対象なのか」を確認する工程は、人間側にも残ります。
まとめ
今回のAPI連携で一番苦労したのは、Pythonの文法ではありませんでした。
GoogleではOAuth、スコープ、Google Cloud、対象サービスの権限が関係します。YouTubeではさらにチャンネルとアカウントの関係が加わります。BingではGoogleとは異なる認証やAPI仕様を理解する必要がありました。
そして最も重要だったのは、
「エラーが消えたら成功」ではない
ということです。
APIから何か返ってきても、それが目的のアカウント・サイト・チャンネルのデータでなければ意味がありません。
欲しかった正しいデータを、正しい権限と対象から取得し、正しい場所へ保存できて初めて成功と判断する。
今回の失敗を経験したことで、今後PinterestやInstagram、TikTokなど新しい媒体を追加するときにも使えるAPI接続の確認基準ができました。
