【要約】Google Ads RSA 日本語文字数制限と事前バリデーション実装 — 全角2カウント問題で全滅した話 [Zenn_Python] | Summary by TechDistill
// Problem
Google Ads API経由でRSAを一括作成する際、日本語の文字数制限（全角2カウント）を考慮せずにリクエストを送信した結果、全件がstring_length_error: TOO_LONGで失敗した。管理画面のリアルタイムカウントに頼れず、APIによるバッチ処理では、事前に仕様に基づいた厳密な検証ロジックを実装しなければ、運用上の致命的なエラーを招く。
// Approach
APIリクエスト送信前に、unicodedata.east_asian_width()を用いて文字の幅（Wide/Fullwidth）を判定し、正確なカウント値を算出するバリデーション関数を実装した。これにより、ヘッドライン（30カウント）や説明文（90カウント）の制限、および本数制限を事前に検証し、エラーがある場合はAPIを呼び出さずに早期リターンする設計とした。
// Result
API呼び出し前のバリデーションレイヤーを導入することで、不要なAPIリクエストを削減し、エラーの原因（どのテキストが何カウント超過しているか）を明示的に特定可能にした。これにより、自動化プロセスにおけるエラーハンドリングの堅牢性が向上し、バッチ処理の安定稼働を実現する設計指針を得た。
Senior Engineer Insight
本件は、外部APIの仕様理解と防御的プログラミングの重要性を再認識させる典型例である。単なるエラーハンドリング（事後処理）ではなく、バリデーション（事前検証）として実装を分離した点は、スケーラビリティと運用コストの観点から極めて正しい。特に、unicodedataを用いた実装は、単純なバイト数や文字数判定では不十分な多言語環境において、実戦的な解である。ただし、API側の仕様変更は常にリスクとなるため、ユニットテストによる境界値検証と、仕様変更を検知するための監視体制をセットで検討すべきである。