毎朝6時半に、秘書が自動で動き始めます。前日のノートを読んで、助言を作って、保存します。その一連の記録（ログ）を、ある朝なんとなく開きました。一行目に、こう出ていました。
「ノートの取り込みに失敗しました（未pushのローカル変更・コンフリクトの可能性）」
いちばん最初の工程で止まっていたわけです。つまり、その日の秘書には材料が一つも入っていなかったのです。
処理そのものは、そのあとも最後まで走っています。止まったのは取り込みだけで、残りの工程は、古いままのノートを読んで、いつも通りに終わっていました。エラーで全体が落ちてくれれば、まだ気づきようがあったと思います。静かに、それらしい結果を出し続けるほうが厄介でした。
取り込みが止まる理由
Obsidianのノートは、パソコンからもスマートフォンからも書きます。だから、どちらからでも同じ保管庫を触れるように、クラウド経由で同期しています。毎朝の処理は、まずその保管庫から最新のノートを取り込むところから始まります。
この取り込みには、一つ条件を付けてありました。手元に保存されていない変更が残っているときは、上書きせずに素直に失敗します。機械に既存のノートを勝手に書き換えさせない、という原則からです。9,623ノートの塊なので、ここで手を抜くと取り返しがつきません。
設定としては、いまも間違っていないと思っています。問題は、その「保存されていない変更」の中身のほうでした。
残っていたのは、秘書が書いたファイルだった
調べてみると、未保存のまま溜まっていたのは、秘書自身が書き出した「AIからの提案」というフォルダでした。
秘書は毎週、そこにファイルを追加します。そして、誰もそれを保存（コミット）しません。自分は見に行かないし、保存する手順も組んでいません。ファイルだけが静かに増えていきます。増えた分は「手元に保存されていない変更」として扱われるので、ある時点から、翌朝の取り込みが必ず止まります。
そもそも、なぜ提案をノートの保管庫の中に置いたのか。理由ははっきりしていて、そこなら外出先でもスマートフォンから読めるからです。専用の画面を作らなくても、いつも使っているノートアプリの中に置いておけば、そのうち目に入るだろう、と考えました。実際には目に入りませんでした。
出力をノートの保管庫の中に書く設計が、その保管庫からの入力を止めていました。
前回の話と、つながっていた
第7回で、秘書には出口が7つあるのに、本人に届いたのは1つだけだった、と書きました。今回入口を詰まらせたのは、その届かなかった6つのうちの1つです。
見る面がないから、読まれません。読まれないから、保存もされません。溜まったまま、システムの入口を塞いでいました。読まれない出力は、放っておかれるだけでは済みませんでした。
もう一つ、材料の側も止まっていた
同じ時期に、もう一つ分かったことがあります。デイリーノートそのものが、3日間書かれていませんでした。
秘書の助言は、前日のノートを読むところから作られます。ノートが無ければ、作れるものがありません。仮に取り込みが正常でも、その3日については、やはり動けなかったわけです。
仕組みのほうが「毎日ノートが書かれる」という前提に寄りかかりすぎていました。実際には、書かない日があるのが普通です。忙しい日もあれば、書く気にならない日もあります。書かない日を異常として扱わない形に組み直す必要があります。
出口を、保管庫の外に出す
対処の方針は決めました。秘書が書き出すものを、ノートの保管庫の中に置くのをやめます。
保管庫は入力専用に戻します。読むだけの場所にして、こちらからは書き込みません。出すものは別の場所に一箇所へ集めて、そこを作業台が読みに行きます。入ってくる道と出ていく道を分けて、それぞれ一本道にすれば、詰まる場所も減ります。第7回で唯一ループが閉じた出口が、たまたまその形をしていた、というのも後押しになりました。
—
この件でいちばん効いたのは、不具合そのものより、気づくまでに何日もかかったという部分でした。
自分しか使わないシステムなので、壊れても誰にも迷惑がかかりません。誰も怒らないし、報告も上がってきません。だから、たまたまログを開くまで分かりません。人に使ってもらう道具だったら、こんなに長く放っておかれることはなかったと思います。
自分の出したものが一周して、自分の入口に戻ってきて、自分の首を絞めていたのです。個人用のシステムを作るというのは、そういう閉じた輪の中に立つことなのだな、というのが、今回いちばん残った感覚でした。
コメント