なぜ「育てる」か
サーバーは、組み上げて公開して、バックアップを仕掛けたら終わり——ではない。サーバーは、生き物のように手入れして育てるものだ。 ディスクは少しずつ埋まり、ソフトには日々セキュリティ修正が出て、ログには小さな異常が溜まっていく。放っておけば、ある日突然止まる。手入れを続ければ、何年でも健やかに動く。
ここで身構えないでほしい。「サーバーを持つと毎日面倒を見なければならないのでは」という不安は、よく聞く。だが、それは違う。この章が目指すのは、週に15分の定例で回る設計だ。 毎日張り付く必要はない。むしろ、張り付かなくても回るように仕組みを作っておく——それが「育てる」ということだ。
第5章でファイアウォールを張り、第10章でバックアップを自動にした。あの自動化の積み重ねが、ここで効いてくる。日々の守りは仕組みに任せ、人間は週に一度、短く見守るだけでいい。この章では、その見守りの最小セット、保守のリズム、壊れたときの型、そして次の一手を順に整える。
第一節 見守りの最小セット
週次の定例コマンド
サーバーの健康を見るのに、特別な監視ソフトは要らない。まずは素朴なコマンドの組で十分だ。週に一度、次を順に打って、出力を眺める。
df -h # ディスクの空き（埋まりすぎていないか）
free -h # メモリの空き
journalctl -p err --since -7d # 直近一週間のエラーログ
systemctl --failed # 失敗しているサービスはないか
sudo tail -n 30 /var/log/auth.log # 不審なログイン試行の様子
sudo fail2ban-client status sshd # fail2ban が弾いた数（第5章で入れていれば）
systemctl is-active postgresql # データベースが生きているか（第7章で入れていれば）
これを毎週手で打つのは面倒だ。だから一つのシェルスクリプトにまとめる。
#!/bin/bash
# ~/weekly-check.sh — 週次の健康診断
echo "===== disk =====" ; df -h
echo "===== memory =====" ; free -h
echo "===== errors (7d) =====" ; journalctl -p err --since -7d --no-pager
echo "===== failed units =====" ; systemctl --failed --no-pager
echo "===== fail2ban =====" ; sudo fail2ban-client status sshd 2>/dev/null
echo "===== database =====" ; systemctl is-active postgresql 2>/dev/null
chmod +x ~/weekly-check.sh
./weekly-check.sh
出力をまるごとClaudeに渡す
ここがAI時代の運用の肝だ。スクリプトの出力をただ眺めても、初心者には「何が正常で何が異常か」が分からない。だから、出力をまるごとClaudeに貼って、「先週と比べて気になる点はあるか?」と聞く。
人間が一行ずつ意味を判定する必要はない。Claudeに「ディスクは大丈夫か」「このエラーは放置していいか」「このログイン試行は気にすべきか」を判断させ、人間はその助言を吟味して動く。これが、第3章から続く「環境を伝える作法」の、運用フェーズでの最終形だ。サーバーの状態がすべてテキストで取れるという、第1章で書いた性質が、ここで最大限に効く。
その先：軽い監視ツール
週次の手動チェックに慣れて、もう一歩進みたくなったら、軽い監視ツールを入れるとよい。たとえば Uptime Kuma は、サービスが落ちたら通知してくれる軽い監視ツールだ。「自分が見ていない間にサービスが止まった」を、人間が気付くより先に教えてくれる。ただし焦らなくていい。まずは手動の週次チェックで「自分のサーバーの平常時の顔」を覚えるのが先だ。
Claudeに聞いてみよう①：weekly-check.sh を自分の構成向けに書かせる
私のDebianサーバーの構成は次のとおりです： 〔my-server.md を貼る。動かしているサービス、ファイアウォール（第5章）、fail2ban の有無、データベース（第7章）など〕
週に一度実行して「サーバーの健康診断」をするシェルスクリプト
weekly-check.shを、私の構成に合わせて書いてください。 ディスク・メモリ・エラーログ・失敗サービス・不正アクセスの兆候・各サービスの稼働状況を、見出しを付けて順に出力する形で。 各チェックが「何を見ているか」「どういう出力なら異常を疑うべきか」も一行ずつ添えてください。
自分の構成を渡せば、自分のサービス名に合わせたチェックが並ぶ。出てきたスクリプトは git に置いておく（第10章で決めた設定管理の作法のとおり）。
第二節 保守のリズム
日々は自動、月次は手動
セキュリティ修正は待ってくれない。だから、日々のセキュリティ更新は unattended-upgrades（第5章で設定した）に任せる。これが毎晩、重要な修正を黙って当ててくれる。日々の保守は、すでに自動化されている。
人間がやるのは月次の手当てだ。月に一度、次を実行する。
sudo apt update
sudo apt full-upgrade
full-upgrade は、新しい依存関係が必要になったパッケージも含めて、きちんと最新に揃える。更新が終わったら、再起動が要るかを確認する。
# 再起動が必要かの確認
[ -f /var/run/reboot-required ] && echo "再起動が必要" || echo "再起動は不要"
# どのサービスが古いライブラリを掴んだまま動いているか
sudo needrestart
カーネルが更新されたときは再起動が要る。第1章で書いたとおり、サーバーの再起動は「その間すべてのサービスが止まる」重みを持つ。だから、影響の小さい時間帯を選んで、計画的に再起動する。
Debian安定版の世界観
ここで、Debianという土台の性格を一段深く理解しておきたい。Debianの安定版（あなたが入れた trixie）は、約2年ごとにメジャーリリースが出る。その間は、機能を大きく変えず、セキュリティ修正とバグ修正だけを当て続ける（これがポイントリリース）。だから日々の full-upgrade で、いきなり世界が変わることはまずない。「安定して、予測可能で、退屈」——これがサーバー向けDebianの最大の美点だ。
数年に一度、次のメジャーリリースへ上げる日が来る。これは日々の更新とは別物で、心構えが要る作業だ。本編第17章「アップデートとメンテナンス」でデスクトップ向けに書いた作法——更新前にバックアップ、リリースノートを読む、一気にやらず段階を踏む——が、サーバーでもそのまま効く。そしてサーバーには第10章のバックアップと復元演習があるから、メジャーアップグレードに踏み切る不安はずっと小さい。最悪でも、バックアップから戻せる。
Claudeに聞いてみよう②：定例チェックの出力で健康診断
私のDebianサーバーで
weekly-check.shを実行しました。出力は次のとおりです：〔weekly-check.sh の出力をまるごと貼る〕この出力を健康診断してください。 (1) すぐ対応すべき問題 (2) 今すぐではないが近いうちに対応した方がよいこと (3) 正常で問題ないこと に分けて。 対応が必要なものには、具体的なコマンドと、実行前に確認すべき点を添えてください。 先週の出力〔あれば前回分を貼る〕と比べて、変化があれば指摘してください。
毎週これをやると、Claudeが「先週より2%ディスクが増えている」「先週は無かったエラーが出ている」といった変化を拾ってくれる。人間一人では気付きにくい、緩やかな悪化の兆候が見えるようになる。
第三節 壊れたときの型
デスクトップ編の作法は、サーバーでもそのまま効く
サーバーも、いつかは壊れる。あるいは、設定をいじって動かなくなる。そのとき頼りになるのは、本編第18章「問題が起きた時の対処」で身につけた作法だ。焦って再インストールしない。症状を切り分ける。ログを取る。Claudeに渡す。 この型は、デスクトップでもサーバーでも変わらない。
ただし、一つだけ決定的な違いがある。サーバーには画面がない。 デスクトップなら、最悪その場の画面を見て操作できた。サーバーは普段リモートから入っているから、SSHが死ぬと「入る手段そのもの」を失う。
SSHが死んだときの退路
だから、SSHで入れなくなったときの退路を、あらかじめ知っておく。
- 自宅の物理サーバーなら：モニターとキーボードを直接つなぐ。普段は画面がなくても、いざというときは物理コンソールがある。
- VPSなら：契約しているVPS事業者の管理画面に、ほぼ必ずWebコンソール（ブラウザから直接サーバーの画面を叩く機能）がある。SSHが死んでもこれで入れる。さらにレスキューモード（別のOSで起動してディスクを修復する機能）も用意されていることが多い。
この退路の存在を知っているかどうかで、「SSHが死んだ」ときの落ち着き方がまるで違う。今のうちに、自分の環境ではどの退路が使えるかを確かめておくといい。
最悪でも「作り直せばいい」
そして、ここで第10章が効いてくる。どうしても直らないとき、サーバーには「作り直す」という最終手段がある。 OSは最小インストールからやり直せる。設定は git から戻せる。データは restic から戻せる。第10章で再構築演習までやっていれば、これは机上の話ではなく、一度通った道だ。
「最悪でも作り直せばいい」という確信が、運用の余裕を生む。 一つ一つのトラブルに過剰に怯えなくなる。怯えがなくなると、かえって冷静に切り分けられる。これは技術というより、心の持ちようの話だ。そしてその余裕の土台は、第10章のバックアップと復元演習が支えている。
Claudeに聞いてみよう③：サーバー版トラブル時のテンプレ
私のDebianサーバーで次のトラブルが起きています：〔症状〕
サーバーの構成：〔my-server.md を貼る〕 今アクセスできる手段：〔SSHは生きている / SSHが死んだのでVPSのWebコンソールから / 物理コンソール など〕 これまで試したこと：〔箇条書き〕
次に試すべき手順を、リスクの低い順に3つ。各手順の確認方法と、失敗時の次の一手も。 サービスを止めずに直せる方法があれば優先してください。最終手段として第10章のバックアップから作り直す場合の判断基準も添えてください。
第四節 次の一手
ここまでで、あなたは一台のサーバーを運用できている。組み立て、公開し、守り、見守り、保守する——一通りの作法が手に入った。では、ここから先、どう育てるか。方向は大きく三つある。
一. 載せるものを増やす
今のサーバーに、新しいサービスを足していく。写真サーバーの次はメモ同期、その次は家計簿、その次は——と、自前化したいものを一つずつ増やす。第6章のサービスの作法、第7章のデータベース、第8章のFastAPIの型があれば、新しいサービスを足すのは難しくない。
そして最も面白いのは、自分で作ったアプリを載せることだ。本編第15章「Claudeとの開発」で、Claudeと一緒に小さなアプリを作る話をした。そこで作ったアプリを、このサーバーに載せて、いつでもどこからでも使えるようにする。「Claudeと作って、自分のサーバーで動かす」——これは、個人が持てる最も完結した循環だ。
二. 二台目を持つ
一台を回せるようになったら、二台目という選択がある。役割を分ける（一台はファイル、一台は公開Webサービス）、あるいは互いをバックアップ先にする（第10章の3-2-1ルールの「別の場所」を、二台目で満たす）。二台目は、一台目で学んだことの応用だから、最初の一台ほどは苦労しない。
三. 構成をコード化する
これが最も本質的な「次の一手」だ。今あなたがやっているセットアップ手順——どのパッケージを入れ、どう設定し、どのサービスを動かすか——を、頭の中やバラバラのメモから、一つのスクリプトとドキュメントにまとめ、git に置く。
なぜこれが本質的か。手順がテキストになっていれば、Claudeと一緒に何度でも再現できるからだ。 新しいサーバーを立てるとき、スクリプトを流せば同じ環境ができる。手順を変えたくなったら、Claudeに相談して書き換える。第10章の再構築演習で見つけた「抜けていた手順」を、ここに埋めていく。サーバーが「自分の頭の中にしかない属人的なもの」から、「テキストで再現できる資産」に変わる。これは、本編第12章の設定管理を、サーバー全体に押し広げることに他ならない。
Claudeに聞いてみよう④：次の一手を相談する
私はDebianサーバーを一台、運用できるようになりました。現状は次のとおりです： 〔my-server.md を貼る。動かしているもの、使っている時間、かけられる予算など〕
ここから先の「次の一手」を相談したいです。私の目的は〔例：家族のデータを全部自前で持ちたい / 勉強として技術を深めたい / 自作アプリを公開したい〕、サーバーに割ける時間は週〔〇〕時間、追加で使える予算は月〔〇〕円くらいです。 (1) 載せるものを増やす (2) 二台目を持つ (3) 構成をコード化する のうち、私の状況だとどれから手を付けるのが良いか、理由とともに提案してください。選んだ方向の最初の一歩も具体的に。
結び——自分のインフラを持つということ
デスクトップ編との対
本編（デスクトップ編）は、「自分の机を取り戻す」話だった。毎日向き合うPCを、広告も監視もない、自分で中身を見られる機械にする話。
このサーバー編は、「自分のインフラを持つ」話だった。あなたが触っていない間も働き続ける裏方を、自分の手の中に持つ。データを自分の機械に置き、サービスを自分で動かし、それを長く育てる。机の次は、机の向こうの土台までも、自分の側に取り戻したことになる。
かつて専任の管理者が要った仕事が
少し前まで、サーバーを一台立てて運用することは、専任のシステム管理者の仕事だった。分厚いマニュアルを読み、エラーメッセージを辞書のように引き、設定ファイルの文法を暗記する——その入口の高さが、個人を遠ざけていた。
Claudeが、その入口を崩した。 エラーを貼れば意味が返る。やりたいことを伝えれば設定例が返る。週次のチェック出力を貼れば健康診断が返る。かつて専任の管理者が要った仕事が、Claudeを横に置いた個人の手に届くようになった。あなたは今、その証拠を一台のサーバーとして手元に持っている。
あなたの問いの立て方とともに、サーバーは育つ
最後に、本編の結章（第23章「次世代への継承」）と同じことを、サーバーの言葉で書いておく。
Claudeは進化し続ける。数年後には、もっと強いClaudeが出ているだろう。だが、「自分の状況をテキストにして渡し、返った答えを吟味して、自分で判断する」という基本は変わらない。 あなたのサーバーは、性能の良いハードや高価なソフトでではなく、あなたの問いの立て方とともに育っていく。 何を載せるか、何を守るか、どこで止めるか——それを決めるのは、最後まであなただ。
このサーバー編の役割は、ここで終わる。あなたの手元には、動いているサーバーと、自動で取られるバックアップと、週次の健康診断スクリプトと、そして何より、「自分のインフラは自分で育てられる」という確信が残っている。
あとは、あなたの時間だ。サーバーを、ゆっくり育てていってほしい。
まとめ
この章でやったこと：
- サーバーは「作って終わり」ではなく「育てる」ものであり、週に15分の定例で回る設計を目指すと定めた
- 見守りの最小セット（
weekly-check.sh）を作り、出力をまるごとClaudeに渡して健康診断する運用を身につけた - 保守のリズム（日々は unattended-upgrades に自動、月次は手動の
full-upgradeと再起動判断）と、Debian安定版の世界観を確認した - 壊れたときの型（本編第18章の作法、SSHが死んだときの退路、最悪は作り直す）を整えた
- 次の一手（載せるものを増やす／二台目／構成のコード化）の三方向を、自分の目的・時間・予算でClaudeと相談した
手元に残ったもの：
weekly-check.sh（週次の健康診断スクリプト、git 管理）- 月次保守と、メジャーアップグレードへの心構え
- SSHが死んだときの退路の知識
- 「次の一手」の方向づけ
- そして——自分のインフラを、自分で育てられるという確信
シリーズ全体はClaudeと一緒に学ぶDebian サーバー編 一覧から辿れる。本編（デスクトップ編）は全章一覧へ。コメント・議論は Facebook グループへ：AISeed — 生物多様性・食料・AIと暮らし