アプリの削除

モノレポからアプリを安全に非推奨化・削除する方法。

アプリを削除するタイミング

以下のような場合にアプリを削除します：

• 別のアプリに置き換えられた場合（例：database-viewer → database-accessor）
• 使われなくなり、運用停止された場合
• 機能が別のアプリに統合された場合

アプリの削除は複数のステップからなるプロセスです。急ぐと、孤立したサービスや壊れた参照、失われた機能が発生する可能性があります。以下のフェーズを順番に進めてください。

フェーズ1：機能の移行

何かを削除する前に、置き換え先のアプリに削除対象アプリのすべての機能が含まれていることを確認します。

チェックリスト

1. 両方のアプリの機能を比較する（ページ、APIルート、コンポーネント、libファイル）
2. 不足している機能を置き換え先アプリに移植する
3. 置き換え先アプリのドキュメントを更新する（README.md、CLAUDE.md、PLAN.md、ai_docs/）
4. 置き換え先アプリが正常にビルドできることを確認する
5. 移行のPRを作成してマージする

ヒント

• 両方のアプリの _lib/ ディレクトリで移植が必要なユーティリティ関数を確認する
• _components/ ディレクトリでUIコンポーネントを比較する
• app/api/ のAPIルートで、置き換え先に不足しているエンドポイントを確認する
• アクセス制御と認証パターンを確認する — アプリ間で異なる場合がある

フェーズ2：インフラの準備

コードを削除する前に、デプロイ済みのサービスを停止します。これにより、実行中で課金が続く孤立したデプロイメントを防ぎます。

Railwayの停止

1. Railwayダッシュボードを開く
2. アプリのサービスを見つける（ステージングと本番の両方）
3. 各環境からサービスを削除する
4. サービスが実行されていないことを確認する

アプリポータル

アプリがアプリポータル（app_portal_appsテーブル）に登録されている場合：

• アプリを無効に設定する、または
• エントリを完全に削除する

データベーステーブル

アプリが所有する不要になったデータベーステーブルがある場合：

1. shared/database/prisma/schema.prismaからPrismaモデルを削除する
2. shared/schema.mdからドキュメントを削除する
3. 既存のマイグレーションファイルは削除しない — Prismaが履歴管理に必要
4. CIパイプラインがスキーマの差分を検出すると、ドロップマイグレーションを自動生成する

重要: テーブルを削除するスキーマ変更を含むPRでは、CIボットが生成したマイグレーションファイルをブランチにコミットするのを待ってからマージしてください。mainへのマージワークフローは prisma migrate deploy を実行するだけで、マイグレーションを生成しません。マイグレーションファイルなしでマージすると、本番データベースが schema.prisma と同期しなくなります。

# schema.prismaを編集した後、差分を確認
git diff shared/database/prisma/schema.prisma

フェーズ3：コードの削除

アプリとコードベース内のすべての参照を削除します。完全なチェックリストは以下の通りです：

アプリディレクトリ

アプリディレクトリ全体を削除：

rm -rf apps/old-app-name

GitHub Actionsワークフロー

デプロイメントワークフローファイルを削除：

rm .github/workflows/deploy-app-old-app-name-staging.yml
rm .github/workflows/deploy-app-old-app-name-production.yml

ルートpackage.jsonスクリプト

ルートのpackage.jsonからdev、build、startスクリプトを削除：

// これらの行を削除:
"build:old-app-name": "pnpm --filter old-app-name build",
"start:old-app-name": "pnpm --filter old-app-name start",
"dev:old-app-name": "pnpm --filter old-app-name dev",

ドキュメントの参照

リポジトリ全体で削除対象アプリへの参照を検索して更新：

確認が必要な一般的な場所：

ロックファイルの更新

アプリを削除した後、pnpmのロックファイルを更新：

pnpm install

フェーズ4：PRの作成と検証

ビルドチェック

残りのアプリが正常にビルドできることを確認：

# 置き換え先アプリのビルド
pnpm --filter new-app-name build

# 他のアプリが削除されたアプリからインポートしていないか確認
# （Claudeがクロスアプリインポートを検索できます）

PRの作成

すべての削除変更を含むPRを作成：

git checkout main && git pull origin main
git checkout -b feature/remove-old-app-name

# すべての変更をステージング
git add -A
git commit -m "chore: remove deprecated old-app-name app"
git push -u origin feature/remove-old-app-name

# GitHub CLIでPRを作成
gh pr create --title "chore: remove deprecated old-app-name" --body "..."

PRチェックリスト

マージ前に確認：

• Railwayサービスが既に停止済み（ステージング＋本番）
• アプリポータルのエントリが無効化または削除済み
• アプリディレクトリが削除済み
• ワークフローファイルが削除済み
• ルートpackage.jsonスクリプトが削除済み
• Prismaスキーマモデルが削除済み（該当する場合）
• CI生成のドロップマイグレーションがブランチにコミット済み（スキーマ変更がある場合）
• shared/schema.mdが更新済み
• ドキュメントの参照が更新済み
• pnpm installを実行してロックファイルを更新済み
• 置き換え先アプリが正常にビルドできる
• 削除されたアプリからのクロスアプリインポートがない

実際の例

database-viewerアプリは、機能がdatabase-accessorに統合された後、このモノレポから削除されました。

経緯：

1. 移行PR（#516） — database-viewerからdatabase-accessorに動的テーブルカテゴリ分類を移植、統計カウンターUIを追加、すべてのドキュメントを更新
2. Railway停止 — Railwayダッシュボードからステージングと本番の両サービスを削除
3. 削除PR（#517） — 61ファイル（約6,800行）を削除：アプリディレクトリ全体、2つのワークフローファイル、ルートスクリプト、不要な計画、インストラクターガイドとテンプレートの参照を更新
4. 結果 — クロスアプリの破損ゼロ、database-accessorはすべての機能を備えてビルド・実行可能

クイズ

次のステップ

• モノレポの構造について学ぶ
• 削除PRの作成のためにブランチとPRのワークフローを確認する