ローカル環境の整理整頓はエンジニアの永遠の課題です。「このスクリプトはこっちのフォルダに入れたほうが綺麗だな」と、ついファイルを移動したくなる衝動に駆られます。
しかし、その何気ないファイル移動が、Google CloudのOAuth認証基盤と連携した自動化プログラムを完全に沈黙させる引き金になってしまいました。
今回は、ファイル整理の魔力によってOAuthクライアントIDが無効化された（ように見えた）トラブルの顛末と、そこから得た教訓をシェアします。
1. 起きたこと：整理整頓のあとの突然のエラー
ある日、ディレクトリ構造を美しく整理しようと、Google APIを叩く自動化スクリプト一式を別のフォルダ階層へとごっそり移動させました。
「よし、これでスッキリした」と意気込んでプログラムを再実行したところ、コンソールに突如として見慣れないエラーが吐き出されました。
発生したエラー
invalid_client redirect_uri_mismatch
慌てて Google Cloud Console の認証情報ページを確認しに行ったところ、なんと設定していた OAuth 2.0 クライアントID が無効化（または想定外のステータス）になっていたのです。
2. 原因：クライアントIDのスコープと構成ファイルの乖離
なぜファイルの置き場所を変えただけでクライアントIDに影響が出るのでしょうか。正確には「クライアントIDそのものがファイルパスによって自動生成・変更されるわけではない」のですが、以下の要因が複合的に絡み合っていました。
① 相対パスによる設定ファイル読み込みの崩れ
プログラムが認証情報を取得するためのJSONファイル（credentials.json など）のパスを、相対パス（./config/... など）でハードコーディングしていました。
そのため、移動先からファイルを見失い、空のパラメータや不正なパラメータでAPI認証エンドポイントにリクエストを投げてしまっていました。
② リダイレクトURI（コールバックURL）の不一致
ローカルサーバーを立ち上げてOAuthの認可コードを受け取るタイプのスクリプト（デスクトップアプリ型やローカルスクリプト）の場合、起動時のカレントディレクトリやポートバインド、あるいは設定ファイル内のリダイレクト先パスが変わり、Google側で登録している許可済みリダイレクトURIと完全一致しなくなりました。
③ 誤ったプロジェクト参照やクレデンシャルの混同
複数の自動化スクリプトを管理している中で、フォルダ移動に伴って別プロジェクトの古い設定ファイルを読み込んでしまい、Google Cloud側で削除・無効化したはずの古いクライアントIDを呼び出してしまっていました。
3. 得られた教訓
今回のトラブルを通じて、以下の教訓を強く胸に刻みました。
-
スクリプトの置き場所は「インフラ」の一部である
コードだからといって、デスクトップの整理感覚でホイホイとディレクトリを移動させてはいけません。特にAPI連携を前提とした自動化スクリプトは、ファイルパスそのものが依存関係のアンカーになっています。 -
パスは必ず絶対パスまたは環境変数（
.env）で管理する
コード内での相対パス依存を排除し、環境変数やプロジェクトルートを基準とした絶対パス解決を徹底するべきでした。 -
Google Cloud側の認証情報は変更にシビア
リダイレクトURIや承認済みドメインの整合性が崩れると、セキュリティ保護のために意図せず通信が弾かれます。
4. まとめ
「ちょっとファイルを整理しただけ」という油断が、自動化システム全体の停止を招きます。
コードの配置換えを行うときは、単なるファイルの移動だけでなく、**「設定ファイルのパス解決」と「APIコンソール側のリダイレクトURIの整合性」**が維持されているかをセットで確認する習慣をつけましょう。
同じ罠にハマるエンジニアが一人でも減ることを願っています。