OAuthを「人がいない朝」に動かす難しさ

1. リード

人が操作している昼なら通るのに、人がいない朝の自動実行では急に難しくなる処理がある。OAuth はその代表だった。画面を見ながら認証するときは、迷う場所が見える。だが 06:30 の無人実行では、迷った瞬間に止まる。止まった理由が認証なのか、データ欠損なのか、実行条件なのかも切り分けにくい。

RC 検証週で確認できた事実は、劇的な成功談ではない。Metricool OAuth は通常起動中の非対話 refresh で partial / 7 / 7 の成功実績があり、認証方式そのものを変える判断は取らなかった。一方で、朝の自動実行という文脈では、認証が一度通っただけでは安心できないことも見えた。今回のテーマは、その「通る」と「毎朝通る」の差だ。

2. 背景

Vol.12 と Vol.13 で書いたように、RC 検証週の論点は Connector 単体の成否だけではなかった。手で動くか、launchd が起動するか、Mac が最後まで起きているか。そこに加えて、認証まわりにも「対話のある時間」と「人がいない時間」の差があった。

Season 1 の早い段階でも、同じサービス名でも対話用と定期実行用では体験が違う、と何度も感じていた。Cursor の中では通るのに、ターミナルからの定期実行では別の前提が要る。OAuth は特にその差が見えやすい。対話中はブラウザも説明もあるが、無人実行にはそれがない。

この時点で正式 v1.0.0 は未リリースだ。だからこの記事でも、「認証問題は解決した」とは書かない。書けるのは、Current Context にある範囲、つまり 通常起動中の非対話 refresh で partial / 7 / 7 成功実績があり、認証方式は変えない方針までだ。

3. 今回のテーマ

テーマは、OAuth を「一度通した」ことと、「人がいない朝にも通る」と言えることは別だったという話だ。

ログインや初回認証は目立つ。だから、そこを越えると安心しやすい。だが運営では、その後の地味な継続の方が重い。日次の読取りで必要なのは、派手な初回成功ではなく、無人の時刻に説明なしで refresh が回り続けることだった。

4. 実際の出来事

Current Context では、Metricool OAuth について二つの事実が並んでいる。一つは、通常起動中の非対話 refresh で partial / 7 / 7 の成功実績があること。もう一つは、認証方式を変えない方針であることだ。ここで重要なのは、「partial」を失敗扱いしなかったことだと思う。

Metricool は一部指標が null になりうるため、Current Context では partial を仕様として許容している。つまり、認証が回ったかどうかと、すべての値が完全に埋まるかどうかは別に見ていた。ここを混同すると、認証問題なのか、データ仕様なのか、運用条件なのかが一気に曖昧になる。

RC 検証週では、こうした切り分けが特に大事だった。なぜなら朝の自動実行では、問題が一つずつ現れてくれないからだ。launchd、睡眠、ネットワーク、認証、指標欠損が、同じ「今日は朝の結果が弱い」という見え方をする。だからこそ、Metricool OAuth については「非対話 refresh は実績あり」「partial は仕様として許容」「認証方式は変えない」と線を引いていた。

この線引きは、非エンジニアにとってかなり大きかった。認証と聞くと、すぐ「方式を変えた方がいいのでは」と考えたくなる。だが RC 検証週では、新機能追加も認証方式変更も避ける方針だった。朝の無人実行で摩擦が出ても、まず見るべきは大きな作り直しではなく、今の方式で確認できている事実をどこまで言い切れるかだった。

もう一つ大事だったのは、成功実績の書き方だ。partial / 7 / 7 は、万能感のある数字ではない。むしろ「一部は null を含みうる」という前提込みの成功だ。だが前提込みで書けるなら、それは十分に価値がある。運営では、完璧に見せることより、どの条件で通ったかを残すことの方が次の朝に効く。

ここで支えになったのは、Current Context にすでに「Metricool は未提供指標がある場合 partial を仕様として許容する」と書かれていたことだった。つまり、その朝に見えている欠け方が、認証破綻なのか、仕様上起こりうる欠けなのかを切り分ける前提が、先に文章として置かれていた。文章で境界が置かれているだけで、朝の見え方はかなり変わる。少なくとも「全部取れていないから OAuth が壊れた」と短絡せずに済む。

しかもこの整理は、認証を軽く見るためではない。逆だと思う。認証を本当に大事な論点として扱うなら、何でもかんでも認証のせいにしない方がいい。認証の失敗、指標提供側の仕様、無人運用の条件不足を分けて見ないと、次に直すべき点もぼやける。RC 検証週で残したかったのは、解決済みという安心感ではなく、次の朝に同じ揺れが出ても観測し直せる整理だった。

5. 考えたこと

OAuth の難しさは、技術そのものより「人がそばにいない」ことにあるのかもしれない。人がいれば、ブラウザを開く、確認する、やり直す、といった逃げ道がある。人がいない朝には、その逃げ道がない。だから朝の運用では、認証は派手な初回設定ではなく、継続条件の一つとして扱う必要があった。

ここで学んだのは、認証を深刻にしすぎないことでもある。深刻にしすぎると、少し摩擦が出るたびに方式変更へ走りたくなる。だが RC 検証週の役割は、大きく変えることではなく、現状の境界を正確に言うことだった。今の方式でどこまで確認できたか。どこから先はまだ言えないか。その区切りが、朝の安心を少しずつ増やしていく。

非エンジニアの立場では、「通る」と言われたものが、なぜ別の時間帯でまた疑わしくなるのかが最初は分かりにくかった。だが今は、対話中の成功と、無人運用の成功は別の品質だと受け止めている。前者は機能の確認で、後者は運用条件の確認だ。条件が違えば、同じ OAuth でも別の難しさになる。

この受け止め方は、Human Approval の考え方とも少し似ている。押せることと、押してよいことを分ける。動くことと、任せてよいことを分ける。OAuth でも同じで、refresh が一度成功したことと、そのまま朝の運用に任せてよいことは同じではなかった。だからこそ RC 検証週では、派手な改善案より先に、どの条件なら任せてよいのかを言葉で細かく区切る必要があった。

言い換えると、ここで扱っていたのは認証のテクニックより運営判断だったと思う。方式変更を急がない、partial を仕様として許容する、通常起動中の refresh 実績だけをまず事実として残す。この順番を守ることで、朝の不安を「全部壊れているかもしれない」から「どの層を見ればいいか分かる」へ少し動かせた。非エンジニアが AI と運営 OS を続けるには、この違いがかなり大きかった。

6. 学び

• OAuth は「一度通った」だけでは無人運用の安心にならない
• 非対話 refresh の成功と、指標の完全性は分けて見る必要がある
• Metricool の partial は失敗ではなく、仕様として許容する境界が要る
• 認証で摩擦が出ても、すぐ方式変更へ飛ばず確認済み事実を整理する方が強い
• 人がいない朝では、認証も継続運用の条件として扱う必要がある

7. 次回メモ

この流れで続けるなら、Step50 で ChatGPT / Cursor / GitHub / Human Approval の役割を固定した理由につながる。ただし正式 v1.0.0 は未リリースのため、安定運用の完成談としては書かない。