四時間ごとに静かに死ぬ接続
「動くか?」ではなく「失敗したら私はどう気づくか?」
StackTubeのノートは五つの経路で配達される。メール、Googleドライブ、Dropbox、Kindle、Obsidian。ユーザーがどこで読みたいかによって選んで接続する。この五つの経路を一つずつ作るたびに「接続済み」という緑の表示を出し、私はその緑色を信じていた。
EP.14で私は白紙で出てくる電子書籍と格闘した。あのとき学んだのは「ビルド成功が結果正常を意味しない」ということだった。今回の事件はその教訓の次の章だ。あのときは失敗が即座に目の前にあった——本を開けば白紙だったから。今回は失敗が目の前になかった。時間が経ってから現れた。
ローンチ前の点検で、この連携コード全体をAIに検査させた。結果リストの一行目がこうだった。
「Dropbox接続は約4時間後からすべてのアップロードが失敗します。そしてその失敗はどこにも報告されません。」
内容はこうだ。Dropboxに接続すると鍵を受け取る。ところがこの鍵は4時間ものだ。4時間が過ぎると新しい鍵に替えなければならないのに、替える코드がなかった。接続直後はすべて正常だ。テストも通る。ユーザーも満足する。そして4時間後、鍵が期限切れになり、その後のすべての配達が失敗する。
ここまでなら平凡なバグだ。本当の問題はその次の文だった。失敗が報告されない。配達が失敗してもシステムはエラーを上げず、静かに次の仕事に移るようになっていた。ユーザー画面の表示は依然として「接続済み」。緑色だった。
想像してみた。あるユーザーがDropboxを接続し、最初のいくつかのノートがちゃんと届くのを確認し、安心して忘れる。その日の午後からノートは届かない。一週間後にフォルダを開いたユーザーは何をするだろう。問い合わせを送るだろうか? おそらく違う。ほとんどは「何かおかしいな」と思って静かに去る。システムも静かで、ユーザーも静かだ。私だけが知らない。
「私だけが知らない。」この状態がこの事件の核心だった。バグ自体——4時間ものの鍵を更新しないこと——はありふれた失敗だ。怖いのはそのバグが私に見えないことだった。ユーザーは去り、画面は緑色で、私はサービスがうまく回っていると信じる。失敗が静かに起きている間、私は成功していると錯覚する。
同じ検査で、似た部類の問題がいくつか出てきた。シングルクォートの入った英語タイトル——たとえばDon'tで始まる動画——がドライブ検索を壊して、同じノートが重複アップロードされていたバグ。ノートを削除すると保管庫に移す機能が、探すファイル名と実際のファイル名が違って、何も移さずに「完了」と答えていたバグ。すべて同じ家族だ。失敗したのに、失敗したと言わないものたち。
修正は三日もかからなかった。鍵の更新コードを入れ、失敗したら一度やり直させ、沈黙していた場所ごとに通知をつけた。今は配達が失敗すると私のSlackに警告が来る。失敗がもう静かではなくなった。
この事件以降、私の点検の質問が一つ増えた。以前は「この機能が動くか?」だけを聞いた。今はもう一つ聞く。「この機能が失敗したら、私はそれをどう気づくのか?」
この二つ目の質問が一つ目より重要だということを、私はこの事件で学んだ。一つ目の質問は今この瞬間だけを見る。「今動く」という確認だ。しかしシステムは時間の中で生きる。今動くものが四時間後にも動く保証はない。二つ目の質問に答えのない機能は、動いているのではなく、まだ失敗する時が来ていないだけだ。
コードを読めない私にとって、これは特に切実な問題だ。開発者ならコードを見て「ここにトークン更新がないな」と気づけるかもしれない。私はできない。私が失敗を知りうる唯一の道は、失敗が自ら私に信号を送ってくるようにすることだけだ。だから私のような人間にとって、感知装置——通知、ログ、モニタリング——は開発者よりむしろ必須だ。私はコードを見られないから、コードが私に話しかけるようにしなければならない。
4時間ものの鍵はどこにでもある。今緑色のものの中に、まだ期限切れになっていないだけのものが何個あるだろう。それをすべて知ることはできない。ただ今は、それらが死ぬとき静かに死なないようにしておこうと思う。
🔧 このエピソードの技術用語解説
アクセストークン / リフレッシュトークン（Access / Refresh Token） 外部サービスにアクセスするときに使う鍵。アクセストークンは寿命が短く（Dropboxは4時間）、期限切れになるとリフレッシュトークンで新しい鍵を発行してもらう必要がある。今回の事件はその「再発行コード」がなかったこと。
401（Unauthorized） 「鍵が有効でない」という応答コード。この応答を受けたときに再発行を試みるか、静かに見過ごすかが、今回のエピソードの分かれ道だった。
オブザーバビリティ（Observability） システムが今どんな状態かを外から知れる度合い。ログ、通知、モニタリングがその道具だ。「失敗したらどう気づくのか?」という質問がこれだ。このエピソードの中心概念。
アラート / モニタリング（Alerting / Monitoring） 失敗や異常が発生したときに自動で信号を送る装置。配達が失敗するとSlackに警告が来るようにしたのがその例。コードを読めない運用者にとっては「コードが私に話しかける」唯一の通路だ。
リトライ（Retry） 作業が失敗したときに自動で再試行すること。一時的な失敗（ネットワーク切れなど）はリトライだけで解決する場合が多い。