Google認証の「見えない壁」。自サーバー運用という自由の代償

前回のVol.9では、n8nでSlack通知を「わずか10分」で開通させたお話をしました。
あまりの拍子抜けに、「これならいける」と手応えを感じた直後に取り組んだのが、今回のテーマである Google系ツールとの連携 です。

結論から言うと、前回のような「快勝」とはいきませんでした。
数時間にわたる試行錯誤。正しいはずの設定を何度確認しても跳ね返される、自サーバー運用ならではの洗礼を受けた記録になります。

開発者の領域「Google Cloud コンソール」での格闘

今回の自動化では、Googleドライブやスプレッドシートとの連携が欠かせません。
そのためにまず避けて通れなかったのが、Google Cloud コンソールという開発者向けの管理画面でした。

Web版（有料版）であれば意識せずに済んだであろう、専門用語が並ぶ深い階層の設定画面。
自サーバー運用という「固定費をかけない選択」をした代償として、この領域での設定作業を引き受けることになりました。

連携の瞬間に突きつけられる「拒絶」

コンソールでの設定を終え、いざn8nからGoogleアカウントへ連携しようとした瞬間。画面に現れたのは、成功の通知ではなく 400エラー でした。

原因を追っていくと、トンネルURLが起動のたびに変わることで登録情報とズレが生じていたり、設定反映にタイムラグがあったりと、「設定は正しいはずなのに動かない」状況が続いていました。

「判断」を求められる場面の積み重なり

ようやくエラーを抜けたと思ったところで、次に表示されたのがこの画面です。

ここで感じたのは恐怖というより、判断を自分で引き受けなければならない負荷でした。
Googleという巨大な仕組みから強い警告文を突きつけられながら、自分の設定が正しいと信じて「続行」を選ぶ。このプロセスの積み重ねが、自サーバー運用における見えない壁なのだと実感しました。

落ち着かない挙動という「実務上のストレス」

速度面については、localhost（開発環境）を併用することである程度カバーしていましたが、それでも挙動の不安定さは残ります。

ターミナル操作のたびに挙動が微妙に違ったり、ログインまでに時間がかかったり。
「昨日は動いたのに、今日は同じ手順で進まない」。
こうした 再現性の低さ が、実務としての効率をじわじわ削っていく感覚がありました。

「ひと手間」を許容するかどうか

数時間の試行錯誤の末、ようやく認証が通った瞬間。
そこにあったのは達成感よりも 安堵 でした。

現状では、起動のたびにURLを登録し直すという「ひと手間」をかければ、固定費なしで運用できます。
ただ、この判断の負荷や挙動の不安定さを、いつまでも人力で吸収し続けるのが最適かどうかは、考える余地がありそうです。

Cloudflare TunnelやDockerといった、より安定した運用方法もあるようなので、次はこの「不便さ」を仕組みで軽減できるかどうか、改善（カイゼン）に挑戦してみたいと思っています。

📎 過去の記事はこちら

この連載が、なぜ始まったのか
Vol.1：40代・製造業エンジニアが、会社の外で「自分の市場価値」を問い直す。AI自動化で『資産』を作るリスキリングの記録。
https://note.com/toto_automake/n/n26f026045328

「まず動かす」までに必要だった、地味な準備
Vol.7：n8nを「まず動かす」までの話。衝撃の前にあった、地味な準備
https://note.com/toto_automake/n/ncf2c1e6e4160

「とりあえず動いた」という、軽い手応えの話
Vol.9：わずか10分で開通。n8nでSlack通知を組んで感じた「拍子抜け」の快感
https://note.com/toto_automake/n/nc7f800dd9f03

📎 次の記事はこちら

認証で止まったあと、運用の形を決め直した話
Vol.11：「満足」から「改善」へ。数分間の沈黙を越えるための決断
https://note.com/toto_automake/n/n4cf0e072d641

📎 リアルタイムの学習ログはこちら

Xでは、
作業中に感じた違和感や、
判断を引き受ける場面での引っかかりを、
メモや簡単な2コマとして残しています。

記事になる前の、
思考の途中経過を置いている場所です。
https://x.com/toto_automake