動くConnectorと、毎日動く仕組みは別だった

1. リード

Connector は動いていた。少なくとも、そう思っていた。GA4 も GSC も Clarity も Metricool も、必要なときに走らせれば結果は返る。SQLite にも溜まる。Dashboard でも見える。だが RC 検証週に入ってから、その「動く」は朝の安心に直結していないと分かった。手で動かせることと、毎朝勝手に動くことは別物だった。

この差は、コードを書けるかどうかより痛かった。運営 OS が欲しかった理由は、朝の確認を短くするためだ。毎日 06:30 に同じ仕事が終わっている前提で、昨日との差だけ見たい。その前提がなければ、Dashboard があっても、結局は「今日は本当に更新されたのか」を人が疑うことになる。

2. 背景

Vol.09 で v1.0.0-rc1 に到達し、Vol.10 で「ここで終わらない」と書いた。終わらない理由は単純で、RC は完成ではなく検証の入口だったからだ。Connector は 10 件までそろい、SQLite に履歴を残し、Dashboard 8 画面も確認した。見た目には、かなり形になっていた。

だからこそ、次の1週間は「足さない」期間にした。新機能を入れず、朝に開き、昨日との違いを見る。Operational Validation Week とは、派手な改善より、地味な前提が本当に成立しているかを確かめる時間だった。

この時点で正式 v1.0.0 は未リリースだ。完成したことを書く週ではなく、完成と言ってよいかを見張る週だった。その見張りの最初の論点が、Daily Connector Automation だった。

Vol.11 では Day 7 の一時 No-Go を書いた。今回の Vol.12 は、その少し手前で何が見えていたかの話だ。No-Go という判断だけを切り出すと、厳しく止めたように見える。だが実際には、その前に「どこが欠けているのか」を言葉にし直す作業があった。Step49.1 の価値は、まさにその言い直しにある。

3. 今回のテーマ

テーマは、動くConnectorと、毎日動く仕組みは別だったという当たり前の発見だ。

今振り返ると当たり前に見える。だが当時は、手動実行が通ること、SQLite に結果が残ること、Dashboard で見えることに意識が寄っていた。ひとつひとつが正しくても、朝 06:30 に自動で流れる経路がなければ、運営 OS の価値は半分になる。

Connector を作る話と、Connector を毎日走らせる話は、似ているようで責務が違う。前者は取得・変換・保存の品質、後者は時間・起動条件・継続性の品質だ。Step49.1 で見えたのは、その境界だった。

4. 実際の出来事

RC 検証週で見たかったのは、「朝に開けば昨日との差がもう並んでいる」状態だった。ところが、レビュー期間中の確認で、日次Connectorが想定どおり回っていないことに気づいた。ここで最初に疑いたくなるのは Connector 本体だ。GA4 が壊れたのか、GSC の取得が失敗したのか、SQLite への保存が落ちたのか。だが Step49.1 の記録で分かった原因は、もっと地味だった。自動実行そのものが未設置だった。

つまり、Connector は壊れていなかった。壊れていたのは、「毎朝動くはず」という前提の方だった。手動で走るものを積み上げてきた結果、私はどこかで「ここまで来れば毎朝も動くだろう」と考えていたのだと思う。だが実際には、スケジューラを置き、起動条件を決め、失敗時にどこを見るかを決めて、初めて毎日の仕組みになる。

この発見を受けて、Step49.1 では Daily Connector Automation として launchd を導入する方向に整理された。重要だったのは、「新しい機能を足した」というより、運営 OS の定義を言い直したことだ。運営 OS は、便利なスクリプト集ではない。朝に何もしなくても、必要な読取りが所定の時刻に終わっている仕組みでなければいけない。

ここで少し怖かったのは、見た目には進んで見えていたことだ。Dashboard がある。Connector もある。SQLite もある。だから「ほぼ完成」に見えてしまう。だが毎日動く仕組みが空白なら、その完成は説明できない。説明できない完成は、Version を上げる根拠にならない。

Step49.1 の時点で大事だったのは、原因を Connector 故障にしなかったことでもある。もし「一部の取得が不安定だった」で済ませていたら、直す対象がぼやける。実際には、取得ロジックより先に、運用の時間軸を担う部品がなかった。問題の種類が違うと分かったことで、次に整えるべきものも明確になった。

ただし、この段階で「もう解決した」とは書けない。Current Context にあるとおり、その後も無人実行の確認論点は残った。だからこの記事で言えるのは、Step49.1 で「どこが抜けていたか」が見え、Daily Connector Automation を明示的な作業として切り出した、という事実までだ。

見方を変えると、ここで初めて「運営の失敗」と「Connector の失敗」が分かれたとも言える。部品の異常なのか、部品を走らせる条件設計の異常なのか。この違いが見えないままだと、改善しても朝の不安は消えない。見えたことで、次の確認項目が機能単体ではなく、朝の流れ全体へ向くようになった。

5. 考えたこと

非エンジニアの立場から見ると、ここで学んだのは「動作確認」の意味が思っていたより狭かったことだ。ボタンを押して期待どおりの結果が返る。それは動作確認として十分に見える。だが運営では、時間が条件に入る。朝に勝手に終わっているか。翌日も続くか。人がいないときも同じか。その条件が入った瞬間に、確認対象はスクリプト単体から仕組み全体へ変わる。

この差を見落とすと、AI と一緒の開発は簡単に楽観へ滑る。個々の部品はどんどん整うからだ。Connector も、SQLite も、Dashboard も、レビューも、それぞれ前進している。前進しているものが多いほど、全体も前進している気がしてしまう。だが全体の品質は、部品の総和ではなく、部品のつなぎ目で決まることが多い。

Daily Connector Automation の話は、派手な新機能の話ではない。それでも Season 1 の流れに置く価値があるのは、ここで「運営 OS の完成条件」が一段厳しくなったからだと思う。手で回せる、では足りない。毎日回る、まで言えて初めて、朝の不安を減らす道具になる。

Human Approval の思想とも少し似ている。書き込みを自動化しないのは、境界が要るからだった。同じように、日次読取りを「毎日動く仕組み」として明示するのも、境界をはっきりさせる作業だ。どこまでが Connector の責務で、どこからが運用の責務か。境界が曖昧なままだと、失敗したときに原因も責任もぼやける。

この境界が見えたことで、私は「便利なものが増えた」ではなく「朝の前提をどこまで外部化できたか」で見るようになった。非エンジニアにとっては、ここがかなり大きい。コードの正しさを全部評価できなくても、朝の確認が前提どおり始まっているかは評価できる。評価できるものが増えると、運営者としての責任も現実的になる。

もう一つ、Step49.1 はレビューの価値を逆向きに見せた出来事でもあった。レビューは「間違いを見つける」だけでなく、「何を完成条件に含めるか」を変える。Connector が動くことだけで満足していたら、この話は記事にもならなかった。運用検証週があったから、毎日動くことを別の要件として扱えた。

6. 学び

• 手動実行で動くことと、毎朝自動で動くことは別の品質である
• Connector の品質とスケジューラの品質を混同すると、原因切り分けが遅くなる
• RC 検証週は、追加実装より前提の抜けを見つける場として機能する
• 見た目がそろっていても、時間軸の仕組みが空白なら完成とは言えない
• 非エンジニアの運用品質は、部品単体より「続く条件」をどこまで定義できるかに出る
• レビューは、機能の是非だけでなく完成条件そのものを変える

7. 次回メモ

この続きで書くなら、launchd を入れたあとも無人運用には論点が残った、という話につながる。ただし正式 v1.0.0 は未リリースのため、どの記事でも完成形としては書かない。

---

シリーズ情報

項目	内容
Season	1
Vol	12
現在の開発 Version	1.0.0-rc1
GitHub	https://github.com/boraemon2000/kagoshimaniax-os/tree/main/docs/qiita

次回メモ

次候補「launchd を入れたあとも朝は簡単ではなかった」
ただし正式 v1.0.0 未リリースのため、無人実行の最終成功を完成形としては書かない。