2026年6〜9月のHomelab活動を振り返る
サービスを揃える → 危険な穴を塞ぐ → 個人データを横断して使う → 自律運用を作り込む → 実際に役立つ薄い運用へ絞る。
2026年6月初め〜9月9日のGit履歴・会話・当時の監査記録を照合した振り返り。Irisの分析を会話で確認し、「よいまとめなのでノートに残しておこう」と保存した。評価はIrisの解釈として残し、本人の原則や新しい実行承認へ読み替えない。全サービスの最新状態を再監査した記録ではない。
時期ごとの変化
6月 — 保存先から、使えて守れる環境へ
Immich・Paperless・Navidrome・LANraragiなどを土台に、resticからB2への外部バックアップ、Homepageの状態表示、ObsidianのNAS同期を整備した。RSSはMiniflux＋iris-newsへ。月末にはwger・Jeluも試した。
「NASに置く」だけでなく、外から使う・失っても戻せるようにする方向へ進んだ。ただし、バックアップの稼働確認は全面的な復元保証ではなかった。
7月初め — 具体的な危険を減らす
7月6〜8日の横断監査で、NASの秘密ファイルの緩い権限、Discordの利用者制限を無効化する設定、Hermes状態のバックアップ不足を発見・修正した。WebUIはloopback＋Tailscale HTTPSへ限定。コンテナ異常通知と監視自身のheartbeatも追加した。
新機能より、漏えい・無断操作・気づかない停止を減らした。この時期の対処は費用対効果が高かった。
7月中旬 — NASとser7の役割を分ける
Paperless検索・Immich日次参照などの限定MCP、サービスマップ、GatusからHermesへの監視連携を整備。7月16日にKarakeep・MinifluxをNASからser7へ移設した。
NASはデータ・配信、ser7は処理・制御という分担が明確になった。代わりに、ser7停止時の影響とホスト間依存は増えた。
7月後半〜8月初め — 用途を広げ、合わないものを退役させる
Grimmory・Szurubooru・openGym・Wallos・Healthchecksなど、蔵書・画像・運動・支出・定期ジョブへ対象が広がった。一方、Materialiousは導入後に削除し、Supervisorは7月30日に運用退役、Glanceも退役記録がある。
生活に結びつく用途を増やしながら、試したものを残し続けない判断もあった。ただし、導入と習慣としての有用性は別。全サービスの利用効果までは確認していない。
8月 — 自分のデータで使えるようにする整備
蔵書の中心をGrimmory／LANraragiへ整理し、日本語書誌・表紙・シリーズ・物理本・ファイル配置・取り込み権限・バックアップを段階的に整備した。Jeluの退役も反映した。
旧Calibreや散在ファイル、旧形式、BookWalker取得物のページ品質など、アプリを起動しただけでは解消しない問題が表に出た。「何を導入するか」から「中にある本を本当に読める・移せる状態にする」へ比重が移った。
並行して、自律継続、Kanbanの引継ぎ・再試行・承認・通知・再起動時の整合性を集中的に修正した。仕事を進める仕組み自体を修理する仕事が大きくなった。
8月30日にはHermesの重要状態を選別した復旧バンドルを整備し、B2からの隔離復元まで確認した。ただし、セッションや作業成果物すべてを含む保存経路ではない。
9月初め — 全体の一般化から、代表経路の実用成功へ
日常運用を常時Kanban中心から外す方向へ転換した。代表サービスのCLI、実容量警告の人間・Iris双方での消費、Radicaleの隔離復元、関係図の自然更新を確認した。
NAS Compose定義をdotfilesへ収容し、限定的な変更・復帰手順も整備した。ただし、定義の収容と全サービスの更新・データ移行の安全性は別。
「全体を賢く管理する」から「一つの現実の経路を最後まで通す」へ戻った。この方向は、環境を意識せずに使いたいという目的に近い。
よかった判断
- 外部バックアップを早く作り、後から復元の実証へ進んだ。 コピーの数より、何が戻せるかを具体化した。Radicaleの成功はDBサービス全体へ一般化しない。
- データの正本をAIやダッシュボードへ移さなかった。 各アプリのDB・ファイルとNix／Composeに正本を残し、Irisを検索・観測・操作の入口にした。AIやクライアントを替える余地が残る。
- 日本語書誌の弱さを乗り換えだけで解決しようとしなかった。 本棚・リーダーと書誌取得を分け、撤退用エクスポートを計画した。ただし計画と常時実証済みの持ち出し経路は別。
- 作った仕組みを退役させた。 MaterialiousやSupervisor、日常運用でのKanbanを、作ったこと自体を理由に維持しなかった。
遠回りだったところ
実用成功より先に、自律化の基盤を広げすぎた
Supervisor、Living Loop、Kanban継続、Outcome、承認・通知・再試行。それぞれに理由はあったが、引継ぎ先が増えるほど、重複実行・古い状態・途中成果の完了扱いを防ぐ実装が必要になった。
進捗確認を減らすための仕組みが、別の監督対象になった。排他・承認・復旧の安全策は必要だったが、その周囲の一般化は早すぎた、というのがIrisの評価。
保存・整理・退役の完了が混ざった
一覧化、分類、コピー、閲覧確認、書誌・進捗の引継ぎ、旧領域の退役は別工程。途中の成果が全体完了に見える場面があった。
旧Calibreの調査では、無関係なGrimmory物理本の移行実績を一度参照してしまった。旧ディレクトリが残ることも未救出の証拠ではない。分類時点の件数と後の内容照合件数を混ぜず、元の対象と実行記録を結びつける必要がある。これはIris側の証拠のつなぎ方と報告の問題だった。
品質確認が大量処理の後ろに回った
BookWalkerでは、取得数やCBZ生成に加え、ページの欠落・重複・描画品質・実reader表示まで確認する必要が出た。集める能力が育った分、修復・保管・再取り込みの負債も増えた。
代表的な難しい本で品質と取り込みまで通してから量を増やすほうが、総作業量を減らせる。
9月9日時点で残っていた境界
ここは当時の振り返りであり、現在のタスク一覧ではない。後続作業で解消されても、この記録を再開指示にしない。
- 重要サービスごとの復元保証。 Paperlessは9月8日の記録では復元準備段階。DBの復元と文書ファイルとの整合は別。
- 容量と旧データの退役。 9月8日昼はNAS約90%、空き約835GB。その後の削減を含む現在値は振り返りでは再測定していない。必要な内容・状態をどこへ残したかで退役を判断する。一律の容量ゲートで必要作業を止める方針にはしない。
- 蔵書の品質修復と最終取り込み。 BookWalkerの再取得物完成とGrimmory置換完了は別。全冊の最新完了は今回再認定していない。旧Calibre全体の救出・退役完了も認定していない。
- 通知。 Gatusの対象不一致は9月8日に恒久修正済みだが、全対象の実通知到達は別。heartbeatは9月9日朝の実行側が旧方式で、修正候補と本番を分けて扱う。
- 自律運用の省力化。 timer稼働と、催促なしで実異常が調査・対処・検証・報告まで閉じることは別。必要な対象での継続実績はまだ評価が要る。
- 定義収容後の保守。 モノレポへの収容は、全サービスの更新・再作成・データ移行の保証ではない。古い図や計画と現行記録のずれも残る。
次の成果を何で測るか
この期間は何も進まなかったのではない。使えるサービス、データ保全、安全境界という土台は前進した。一方、「環境を意識しなくても維持・改善される」という便益は、その土台に比べて遅れている。
Irisからの提案として、サービス数や完了カード数ではなく、次の三つで見る。
- 使いたいデータへ、以前より少ない手間で到達できるか。
- 壊れたとき、何をどこまで戻せるか説明できるか。
- 進捗を聞かなくても、必要な判断か検証済み成果が届くか。
読めない本、取り込み未反映、重要DBの復元未検証、通知経路の欠落は、日常利用・保全を妨げる残件として優先する。全件の書誌統一、旧データの全面照合、全サービスへの監視展開、汎用的な自律化は、具体的な必要が出るまで広げない。
7月初めの危険対処と9月の代表ケース優先への転換はよかった。8月の自律化基盤は学びが残ったが、作り込みすぎた。さらに仕組みを足すより、既にあるものから実用上の便益を取り切る段階、と捉える。