セルフホストから自作へ

以前はサーバーにいろいろ入れていた。ファイル同期、写真のバックアップ、パスワード管理、RSS リーダー。どれもネットで OSS を探し、ドキュメントを読み、Docker Compose を書き、リバースプロキシを設定した。入れ終わった瞬間は達成感があった。サーバーにサービスが一列に並び、どれにも Web 画面がついて、何でもできそうに見えた。

そのうち気づいた。本当に使う機能はごく一部だった。写真のバックアップなら自動アップロードと日付順の閲覧しか使わないのに、そのシステムは顔認識も機械学習も地図も共有リンクも抱えていて、アップデートのたびにデータベースの移行を慎重に確認しなければならなかった。困ったときが一番つらかった。ログは大量に出るし、コードは自分のものではないから、issue を掘るしかない。誰かが直してくれるのを待つか、設定をいじって運を試すか。

転機はコーディングエージェントだった。最初は小さなスクリプトを書かせるだけだったが、ある日気づいた。自分しか必要としない機能なら、既存のプロジェクトを探す必要はない。欲しいものをはっきり伝えて、書いてもらえばいい。

今の私のサーバーは別の景色だ。AI との対話のセッション管理、記事に意見を書き込むページ、日本語の単語を覚えるゲーム、読書の進みを記録するページ。どれも自作で、共通点は私のやりたいことだけをやることだ。変えたくなったらそのまま言う。直ったら終わり。問題が起きても、コードは全部自分の手元にあり、ログは自分の指示で打たせたものだから、読んでいて他人のものという感覚がない。

自分で書いたものが成熟したプロジェクト並みに安定しているのかと聞かれるかもしれない。私の経験では、個人で使うサービスはもともと複雑ではない。機能を自分用に切り詰めれば、バグの入り込む余地はむしろ減る。成熟したプロジェクトの安定性は何千もの使い方のために用意されたもので、私の使い方は一つだけ。保守の気持ちも違う。他人のプロジェクトの保守は借金の返済みたいなものだが、自分のコードの保守は自分の持ち物の世話だ。

最近の例を一つ。自作のクライアントがサーバーに接続するとき、アドレスのプロトコルを書き間違えて、起動するなり落ちた。ログには明確な例外が残っていて、その行を突き止め、一語直して修復した。コードはエージェントが書いたもので、私は一行ずつ読んではいない。それでもログも構造も命名も私の流儀で育っているから、調査するのは自分の家で物を探すのに似ている。

セルフホストから自作までの間にいたのはコーディングエージェントだ。「一つ書く」コストを「一つデプロイする」以下まで下げた。コードを書く方がドキュメントを読むより速くなったとき、答えは変わった。

この記事も、技術記事の大半を削除したときに決めた方向の延長だ。すぐ古くなる技術の細部より、設計のトレードオフと選び方の考え方を書く。