毎朝9時に、私が何もしなくてもブログの下書きができあがっている——そんな仕組みを作って、しばらく本当にうれしかったんです。ところが今、その仕組みは47日間止まったままです。しかも、これまで効いていた復旧の手順が、とうとう効かなくなりました。今日はその話を、うまくいかなかったまま書いてみます。結論から言うと、私は同じ回避策を6回打っていて、そのあいだ一度も「なぜ毎回同じ症状が出るのか」を疑っていませんでした。
毎朝、勝手に下書きができる仕組みを作っていました
まず、何が動いていたのかを簡単に説明させてください。私はブログの記事づくりを、かなりの部分まで自動化しています。仕組みとしてはこんな流れです。パソコンが決まった時刻に自動でプログラムを起動し、まず「次に書くテーマ」をスプレッドシートに聞きに行きます。テーマを受け取ったら、それをもとにAIが記事の下書きを作り、WordPressに下書きとして投稿し、最後にスプレッドシートへ「この行は書き終わった」と記録して終わります。
このテーマの受け渡しに使っているのが、Google Apps Script(グーグル・アップス・スクリプト。以下GAS)で作ったWebアプリです。GASはGoogleのサービス上で動く小さなプログラムで、スプレッドシートを操作したり、外から呼び出せるURLを1本用意したりできます。私はこのURLに「次のテーマちょうだい」とお願いすると、テーマの情報が返ってくる、という窓口を作っていました。仕組みの全体像はブログ更新をまるごと自動化してみた話に書いたとおりです。
大事なのは、この窓口が全工程の一番最初にあるということです。ここが返事をしてくれないと、記事生成もWordPress投稿もシート更新も、その先が丸ごと動きません。入口の1本のURLに、毎朝すべてがぶら下がっている状態でした。
7月24日、その窓口が急に返事をしなくなりました
最初の異変は7月24日の夜でした。いつもならテーマの情報が返ってくるはずのURLから、Googleの「アクセスが拒否されました」というページが返ってきたんです。エラーの種類はHTTP 403(よんまるさん)。ざっくり言うと「あなたにはここを見る権限がありません」という意味の返事です。
おかしいのは、私はその日、何も変えていなかったことでした。プログラムも設定もそのままです。設定ファイルには「誰でもアクセスしてよい」と書いてありますし、その設定を自分で書き換えた覚えもありません。それなのに、昨日まで通っていた窓口が、ある日を境に急に扉を閉じてしまった。
ここで一つだけ、後から思えば大事だった手がかりがあります。それは、返ってきたのが「私のプログラムが出したエラー」ではなく「Googleが出した汎用のページ」だったことです。つまり、私のプログラムは動く前の段階で弾かれていた。合鍵が間違っていたのではなく、そもそも建物の入口で止められていた、という状態でした。
「新しいデプロイを作れば直る」という必殺技を覚えてしまいました
調べていくうちに、ある対処法にたどり着きました。GASのWebアプリは「デプロイ」という単位で公開されます。デプロイとは、書いたプログラムを外から使える形で世に出す操作のことで、公開するたびに新しいURLが割り当てられます。そこで私は、新しくデプロイを作り直し、設定ファイルの中のURLを新しいものに差し替えてみたんです。
すると、動きました。8月5日のことです。あっけないくらい簡単に復旧して、私はほっとしました。そしてこのとき、心の中に「403が出たら新しいデプロイを作ればいい」という必殺技が生まれてしまいました。今にして思えば、この瞬間がいちばん危なかったのだと思います。
なぜ危なかったかというと、直ったことで「原因を調べる理由」がなくなってしまったからです。困っているときは調べますが、直ってしまえば、その日はもう次の作業に移ります。復旧できた経験そのものが、原因究明のきっかけを奪っていました。
一晩ももたなかった日
8月20日、また同じ403が出ました。私はもう慌てませんでした。手順は分かっているので、新しいデプロイを作り、URLを差し替えます。ところが翌8月21日の朝、また止まっていたんです。前日に作ったばかりのデプロイでも403でした。
このときはさすがに引っかかりました。念のため、それまでに作ったデプロイを全部リストアップして、片っ端からアクセスしてみたんです。結果は、テスト用の特別なもの以外はすべて403。つまり、扉が1枚閉まっているのではなく、扉という扉が全部閉まっていたことになります。
ここまで来て「デプロイを作り直しても意味がないのでは」と、うっすら気づいてはいました。ただ、そのときの私は、その気づきを「今日直すべき問題」としては扱いませんでした。とりあえず新しいデプロイを作ってみて、動けばその日は良し。動かなければ、その日は記事の自動生成を諦める。そんなふうに毎日をやり過ごしていました。
とうとう打つ手がなくなった日
8月24日、25日、27日、29日。記録を見返すと、私はほぼ隔日でこの窓口を叩きに行っています。9月1日にもデプロイを作りました。そして9月8日、これまでで何度目かのデプロイを新しく作って、いつもの手順でアクセスして——今度は、直りませんでした。
必殺技が効かなくなった瞬間でした。ここでようやく、私は腰を据えて原因を考え始めます。ずいぶん遅い話です。7月24日の初発から数えて、このとき既に46日が経っていました。
そして今日、9月9日にもう一度確認したら、やはり403のままでした。47日間、毎朝の自動化は止まったままです。
原因は、たぶん「便利にしようとして足した機能」でした
現時点でいちばん有力だと考えている原因を書きます。まだ完全には裏が取れていないので、断定ではなく見立てとして読んでください。
私はこの数か月のあいだに、テーマ管理をしているのと同じGASのプロジェクトへ、別の機能をどんどん足していました。アクセス解析のGA4のデータを取ってくる部分、検索の状況が分かるSearch Consoleのデータを取ってくる部分、それらを毎日記録していく部分。どれも便利で、実際に役立っています。
ところが、こうした機能を足すと「スコープ」というものが増えます。スコープとは、そのプログラムが何にアクセスしてよいかの許可範囲のことです。アクセス解析を読むなら「アクセス解析を読んでよい」という許可が要ります。そして厄介なことに、追加した許可は、プログラムの持ち主がブラウザで「はい、許可します」というボタンを押すまで有効になりません。
私のWebアプリは「持ち主の権限で動く」設定になっていました。ということは、持ち主の許可が宙ぶらりんのあいだは、外から匿名でお願いしても通してもらえない。テーマを取ってくるだけの、アクセス解析とは何の関係もない窓口が、同じプロジェクトに同居していたせいで巻き添えを食っていた、という話です。
この構図に気づいたとき、正直かなり気が抜けました。私は自分で自分の首を絞めていたわけです。しかも「便利にしよう」と思ってやったことで。
コマンドでは押せないボタンがある
では新しいデプロイでなぜ直らなかったのか。ここが今回いちばん学びになった部分です。
私はGASの更新を、パソコンのコマンドから操作するclasp(クラスプ)という道具でやっています。コードを送るのも、公開するのも、コマンド一行で済むので便利です。ただ、この道具でできないことが一つありました。それが「ブラウザに表示される許可ボタンを押すこと」です。
許可の画面は、人がブラウザで見て、自分の意思でボタンを押すことを前提に作られています。コマンドからその画面を出すことはできません。つまり、どれだけ新しいデプロイを作っても、その手前にある「人が押すべきボタン」が押されていない限り、扉は開かないわけです。
私はclaudeとGASの相性について書いた回でも、自動化の相性の良さを書きました。実際、書く・直す・動かすはほとんど自動化できます。それでも最後に、人がブラウザに戻ってボタンを押す作業だけが残る。自動化の最後の一歩は、いつも認証のところで人間に返ってきます。
同じ回避策を3回打ったら、手を止めることにしました
今回のことで、運用のルールを一つ決めました。同じ回避策を3回打ったら、その時点で原因究明に切り替える、というルールです。
私は6回打っていました。しかも1回目から6回目まで、毎回きちんと「今日のトラブル」として真面目に対処していたつもりです。困ったことに、真面目に対処していたからこそ気づけませんでした。毎回ちゃんと直っていたので、疑う理由がなかったんです。
- 同じ症状に同じ手を3回打ったら、それは治療ではなく延命——直ったことは、原因が解決したことを意味しません
- 「今日直った」を記録するだけでなく、前回いつ同じことが起きたかを一緒に書く——横に並べないと周期は見えません
- 機能を足したら、許可の再確認が要るかもしれないと疑う——足した機能と、止まった機能が別物でも関係していることがあります
3つ目は特に盲点でした。壊れたのはテーマ取得の窓口で、足したのはアクセス解析の機能です。私の頭の中では、この二つはまったく別の話でした。同じプロジェクトに入っている、というだけの理由でつながっていたんです。
よくある質問
Q. GASのWebアプリが403になったら、まず何を確認すればいいですか?
A. 返ってきたものが「自分のプログラムのエラー」なのか「Googleの汎用エラーページ」なのかを最初に見分けてください。後者ならプログラムが動く前に弾かれているので、コードを直しても解決しません。合鍵の問題ではなく、扉の問題です。
Q. 新しいデプロイを作れば直る、と聞きましたが違うのですか?
A. 直ることもありますが、それは一時しのぎかもしれません。私は6回この手を打って、最後は効かなくなりました。同じ手が2回目、3回目と必要になっている時点で、別の原因を疑ったほうが早いです。
Q. スコープを足すと、なぜ関係ない機能まで止まるのですか?
A. 許可は、機能ごとではなくプロジェクト単位でまとめて扱われるためです。持ち主の権限で動く設定にしていると、許可が宙ぶらりんのあいだは、そのプロジェクトの窓口ぜんぶが影響を受けることがあります。
Q. コマンドから全部自動化できないのですか?
A. 許可の画面だけは人がブラウザで押す前提の作りなので、コマンドからは出せません。自動化を組むときは「ここだけは人が対応する」という工程がある前提で、失敗したら通知が来るようにしておくのが現実的だと思います。
まとめ:直せてしまうことが、原因を隠すことがあります
47日止まったままの自動化について書いてきました。まだ直っていません。この記事も、いつもと違って手作業で書いています。
この一件でいちばん怖いと思ったのは、私が毎回サボっていたわけではない、ということです。むしろ毎回きちんと対処して、きちんと復旧させていました。それでも根本原因には近づけなかった。直せてしまう回避策を持っていると、人はその先を調べなくなるんですね。
もし自作の自動化を運用している方がいたら、「同じ手を3回打ったら手を止める」だけでも決めておくと、私のように47日を溶かさずに済むかもしれません。非エンジニアが配信ツールを自作した話のときも思いましたが、作るところより、動かし続けるところのほうが、実はずっと難しいです。
この同じ出来事を、私の作業を横で見ているAI「トキワ」の視点からも書いてもらいました。同じ47日間を、まったく違う角度から見ています。私が気づけなかった理由を、トキワは数字で説明してきました。あわせて読むと、たぶん少し面白いです。→ 私は107件のメモを数えました｜AIが見つけた「6回打たれていた同じ回避策」（トキワの観測日記）
このブログでは、AIと一緒に何かを作ってうまくいったこと、うまくいかなかったことを、そのまま書いています。よかったらX(旧Twitter)やInstagramのフォローで、ゆるっとのぞいてもらえたら嬉しいです。「うちの自動化もこれで止まった」という話があれば、こっそり教えてください。
コメント