09-06. ケース 6: 個人 Web サービスの保守 — 本リポジトリを生きた教材として
シチュエーション
個人で運営する Web サービスがある(複数の小さいアプリ群)。 週末に少しずつ保守 したいが、久々に触ると:
- プロジェクト構造を思い出すのに 30 分
- 依存パッケージのアップデートで予期せぬ破壊
- バグ修正のために本番ログを掘り起こす苦労
- 「軽微な追加機能」のはずが半日仕事に
Before (Claude Code を使わない場合)
- 前回触ってから 3 か月、コードの記憶が薄れている
- 各アプリで使ってる技術スタック・デプロイ手順が違う
- バックアップ取り忘れて事故 → 復旧で土曜が消える
After (Claude Code を使う場合)
各アプリに CLAUDE.md が整備されている前提で:
$ cd /path/to/your-services
$ claude
> claude-academy-japanese に新機能 X を追加したい。まず影響範囲を調べて。
→ Claude が CLAUDE.md を読んで現状把握 → 影響ファイルを列挙 → 順次変更 → デプロイ手順を そのまま 実行(CLAUDE.md に書いてある)。
メタ実例: 本リポジトリ ★digitaocean_claudecode
このリポジトリ自体が Claude Code で運用されている 実例。 本セクションでは、本リポジトリの CLAUDE.md と、これまでに行われた 5 つの開発エピソードを 生きた教材 として解剖する:
エピソード 1: 「Nginx の sites-enabled は symlink ではなく独立ファイル」
- 過去に何度も踏んだ罠を CLAUDE.md の Critical Rules に明記
- 結果: 同じ罠に二度と踏まない
- 教訓: 過去の失敗を CLAUDE.md に文章化する だけで、AI も人間も助かる
エピソード 2: 共有 venv と専用 venv のジレンマ
- 4 アプリが共有 venv (
/var/www/venv) を使用 - 1 つだけ最新 SDK が必要になった (Extended Thinking 用)
- → 専用 venv に切替、CLAUDE.md に「他アプリも使うので削除厳禁」と明記
- 教訓: 依存の局所化 はトラブルの局所化に繋がる
エピソード 3: レート制限の追加
- 勉強会参加者が増えた → API コストが心配に
- Claude に相談 → SQLite テーブル + デコレータ的な helper で実装
- 1 セッション(数時間)で完成
- 教訓: 小さい改善を週末に積む ことができるのが個人 Web サービスの強み
エピソード 4: レスポンシブナビの修正
- ナビバーが日本語で縦割れ(エラー画像で報告)
- Claude が
whitespace-nowrap不足を即座に特定 - ハンバーガーメニュー追加 + ブレイクポイント再設計
- 教訓: エラー画像を Claude に見せる だけで原因特定が早い
エピソード 5: ドキュメント更新
- アプリの仕様変更後、
backup/app_CLAUDE/<app>_CLAUDE.mdを更新 - Claude に「最新の仕様で書き直して」と依頼 → 更新完了
- 教訓: ドキュメントは Claude に頼める仕事(人間が偏執的にやらなくていい)
必要な道具立て
| 機能 | 何のために |
|---|---|
| 各アプリの CLAUDE.md | 本リポジトリのものをテンプレに |
| 親リポの CLAUDE.md | アプリ間の共通ルール、SSH 接続情報 |
| Skill: deploy-checklist | デプロイ前後の確認手順を強制 |
| Hook: PreToolUse (Bash) | rm -rf / DROP TABLE を必ずブロック |
| バックアップスクリプト | 定期的に取得 |
Skill .claude/skills/deploy-checklist/SKILL.md (例)
---
name: deploy-checklist
description: 本番サーバーへデプロイする / systemd restart する時に使う
---
# デプロイ チェックリスト
## デプロイ前
- [ ] 変更を git diff で最終確認
- [ ] テストが通ることを確認
- [ ] `local_temp/` でローカル確認
- [ ] バックアップ取得 (該当する場合)
## デプロイ
- [ ] SCP でファイル配置
- [ ] `chown -R www-data:www-data`
- [ ] `systemctl restart <service>`
## デプロイ後 (必須)
- [ ] `systemctl is-active <service>` が "active"
- [ ] `journalctl -u <service> -n 50` でエラーなし
- [ ] curl でエンドポイントが 200 を返すこと
- [ ] ブラウザで実際に動作確認
ワークフロー (週末 1 時間で 1 改善)
土曜朝、1 時間だけ作業:
[10 分] git pull → CLAUDE.md を読み返す → やりたいこと宣言
> 今日は X アプリに「ユーザー登録時のメール確認機能」を追加したい
[20 分] Claude が影響範囲調査 → 設計提案 → 一緒に検討
[20 分] 実装(Hook で自動テスト)
[10 分] デプロイ(deploy-checklist Skill 発火)
注意点・限界
- 本番 DB を直接触らない: 必ずバックアップ → ステージングで試す → 本番、の順
- 無料 SSL の更新忘れ: certbot の renew は cron で自動化、Claude に聞いて設定
- CLAUDE.md が更新されないと AI が古い情報で動く: 機能追加時に CLAUDE.md も同 PR で更新する習慣
- 個人運用の限界: 本気の SLA が必要なら自前運用やめてクラウドサービスへ
応用
- 複数人で運用するチーム小サービス: CLAUDE.md は 共有ナレッジ として PR レビュー対象に
- OSS への貢献: 本ケースの逆 — OSS リポに
CLAUDE.mdを contribute する PR を出す動きも増えている - 退職時の引き継ぎ: CLAUDE.md があれば後任が即戦力に
このケース後にできるようになること
- 個人 Web サービスを "週末 1 時間" で継続成長 させられる
- 過去の失敗を 資産化(CLAUDE.md の Critical Rules)
- 「個人開発の限界」がコード量ではなく 保守性 にあると気づく
- 本リポジトリのワークフロー(
local_temp/で編集 → SCP → systemctl restart → ログ確認)を 自分のサービスに移植 できる
章のまとめ (第9章のクロージング)
| ケース | 学んだこと |
|---|---|
| s1 リポジトリキャッチアップ | 新規参加プロジェクトを 1〜2 時間で把握 |
| s2 リファクタ自動化 | 機械的反復作業を半自動化 + テスト駆動 |
| s3 PR レビュー | チーム業務に AI を組み込む |
| s4 個人ナレッジベース | 蓄積を AI 横断検索可能に |
| s5 データ分析 | 探索的分析の高速化 |
| s6 Web サービス保守 | 全機能の総合運用 + 過去の失敗を資産化 |
第9章を通じて、Claude Code は 手段 であり、目的は 読者の業務効率化と価値創出 であることを体感した。
道具立ては段階的に: 1. 最初は CLAUDE.md だけ で始める 2. 課題が明確になったら Skill / Hook を足す 3. 特化型ワークフロー が必要になったら Agent SDK で独自エージェント
→ 「自分専用の AI 相棒」が育っていく。
関連
- 本リポジトリ
CLAUDE.md(これ自体が教材) - 09-04 個人ナレッジベース —
~/notes/の運用と本ケースの「複数 CLAUDE.md」運用は思想的に同根 - 08-04 Hooks — デプロイ事故防止の Hook