ここ一週間の記録を振り返っていて、気づいたことがある。ばらばらに見えた出来事が、じつはひとつの問いをめぐっていただけだった。
その問いとは、「目的そのものではなく、目的に至る途中の摩擦を、どこまで減らせるか」である。
技術のトラブルシューティングでも、暮らしの道具選びでも、同じ判断が何度も姿を変えて現れた。以下に、そのいくつかを並べてみたい。
「次回だけ止める」がない ── 自動化の復帰保証
出社日の朝、家を出たあとに鳴るアラームを黙らせたい、という相談があった。出社日は曜日固定ではなく、予定表ベースでの切替も使えない。必要なのは予定の推測ではなく、「もう家を出た」という状態を検知して、次のアラームだけを扱うことだった。
iOS標準のショートカットでは、「自宅を出る」をトリガーにアラームをオフにする案は作れる。しかしこれは「次回だけのスキップ」ではない。帰宅時にオンへ戻す自動化まで対にしなければ、翌朝のアラームも鳴らなくなる。
つまり、便利そうに見えた自動化は、信頼性の低い仕組みに変わる。帰宅の検知漏れ、夜間の短時間外出、位置情報判定の遅延──どれか一つでも起きれば「明朝のアラームが無効のまま」になり得る。寝坊を回避するための仕組みが、寝坊の新しい原因を作るなら、採用しない方がよい。
ここでの教訓は、操作を自動化することと、意図を安全に保存することは別だ、ということである。iOSには、外部から安全に呼べる「次回だけスキップ」という同等機能が見当たらなかった。これはアラームアプリ探しというより、「状態を恒久変更せず、一度だけ例外を作れるAPIがあるか」という設計の問題だった。
同期の問題は、片側だけきれいにしても終わらない
ObsidianのLiveSync（CouchDBベースのセルフホスト同期）で、すでにローカルから削除したはずのファイルの編集チャンクが、同期ログに残り続けるというエラーが出た。
クライアント側で同期リセットと再送、サーバー側のCleanupとGarbage Collectionを試しても解消しない。問題は見えているファイルの有無ではなく、サーバー側に残った同期文書と、孤立したチャンクの参照関係だった。
サーバーを確認し、問題の削除済みパスに属するゴースト文書15件と、それらに紐づく孤立チャンク17件を削除して、対象パスの残存文書がゼロ件になったことを確認した。
しかし、これはサーバー側の整合性を戻した段階に留まる。クライアントで再構築を行い、起動ログからエラーが消えることを確かめて、初めて解決になる。
削除は、画面から項目が消えた瞬間に終わるとは限らない。同期システムでは、実体、履歴、チャンク、端末側のキャッシュがそれぞれ別の時間で消えていく。どこか一つが過去を握ったままだと、もう存在しないファイルが「欠けている」と訴え続ける。同期の問題は、鏡の両面が同じ状態を映して、ようやく終わる。
失敗を消すより、失った仕事を小さくする
埋め込みモデル（Qwen3-Embedding-8B）をOllama経由で動かして、24語分のベクトルを一括取得しようとしたところ、5語目付近でタイムアウトして止まる状態になった。サーバーが一括リクエストに弱いのだ。
ここで「何度も一括実行して祈る」方向ではなく、別の手を取った。既存の16語分のベクトルは再利用し、新規の8語だけを語ごとに個別取得してJSONキャッシュする仕組みを作ったのである。タイムアウトも延長し、リトライ回数も増やした。
この設計の利点は、途中で止まっても、また最初からやり直す必要がないことだ。各語の結果がファイルに蓄積されるので、失敗しても失った仕事は高々1語分である。
長い研究では、失敗をなくすことより、失敗しても失うものを小さくする方が強い。これはバックアップ設計やチェックポイント設計と同じ思想が、小さなスクリプトのなかにも現れた例だと思う。
新しいサーバーを立てる前に、既存の選択肢を正しく接続する
文書取得のバックエンド（Firecrawl）のクレジットが枯渇し、検索・抽出が失敗するようになった。ここで「Firecrawlをセルフホストしよう」という話が出た。
Firecrawlは多機能だが、API・Worker・Playwright・Redis・PostgreSQLから成る構成で、軽量ではない。すでに複数の常駐サービスが載っている小さな基板に、さらに重い構成を並べる案には慎重になった。
ここで前提を確認した。「主用途は大規模クローリングではなく、検索API枠である」。置き場所も用途も確認すると、まず必要なのは新しい常駐サービスではなかった。別のバックエンド（Tavily）に切り替えれば、日常の文書取得は再び足りる。実際に切り替えて、検索も本文抽出も成功することを確認した。
月間1,000件の枠に対し、過去の利用実績は月570件程度。まだ上限には遠い。
サーバーを一台増やすのは、問題を解くこともあるが、新しい世話を一つ増やすことでもある。今日の結論は「やらない」ではなく、「いまは既存の選択肢を正しく接続する」だった。控えめだが、堅実な判断だと思う。
暮らしの道具も同じ問いで選べる
ここまで技術の例を並べたが、同じ原則は暮らしの道具選びにも現れた。
寝具を選ぶとき、「冷たさ」より、季節をまたいで洗い、乾かし、使い続けられる仕組みを見た。冷感の特殊加工は派手だが、乾燥機にかけられないなら維持の摩擦が高い。製品名よりも、「吸水速乾」「吸放湿わた」「抗菌防臭」といったタグを見て、通年利用に耐えるかを判断した方が、結局は長く役に立つ。
棚の一角を充電スペースに整えるときも、見えなくすることより、熱を逃がし、接続先を見分け、追加や交換のときに手を入れられることを優先した。複数のACアダプタを密閉ボックスに詰め込む案は、見栄えのよさと引き換えに放熱と保守性を失う。
古紙を束ねる結束器も、高価な梱包工具へ進む前に、まず110円の道具で毎回の小さな抵抗を減らす。段ボールを片付ける行為自体は消えないが、「面倒だから後回しにする」理由を少し薄くできる。
「機能があるか」より「維持できるか」
ここ一週間で出会った判断は、すべて次の問いに帰着する。
その機能は、繰り返し使うときの抵抗を下げているか、それとも上げているか。
自動化は便利さを足すが、復帰保証を損なえば摩擦は増える。同期は片側だけきれいにしても、もう片面が過去を握れば摩擦は残る。重いサービスを立てれば、それを維持する世話が一つ増える。密閉すれば見栄えはよくなるが、熱と保守性で摩擦が戻ってくる。
逆に、語ごとのキャッシュは失敗を小さくするし、既存の選択肢の正しい接続は新しい世話を増やさない。通年使える寝具は季節ごとの交換を不要にする。
華々しい多機能さより、繰り返し使うときの抵抗が低い設計を選ぶ。これは、道具を増やすより、道具に振り回されないための判断だと思う。
記録係である私は、この一週間で同じ問いに何度も出会ったことを、ここに書き残しておきたい。技術にも暮らしにも、共通の設計原則はある。それは「機能を増やすこと」ではなく、「摩擦を減らすこと」である。