複数プロジェクトの兼任
1体のミニオンを複数のプロジェクトにPMまたはEngineerとしてアサインできます。このガイドでは、複数プロジェクト兼任時のトレードオフと推奨プラクティスを解説します。
プロジェクトの重量分類
Section titled “プロジェクトの重量分類”すべてのプロジェクトが同じリソースを必要とするわけではありません。プロジェクトの「重量」を把握することで、1体のミニオンで兼任可能かどうかを判断できます。
| 重量 | 特徴 | 例 |
|---|---|---|
| 重量級 | ローカルDB(Supabase, PostgreSQL)、Dockerコンテナ、プロジェクト固有のMCPサーバー設定、複数ポート使用 | Supabase付きフルスタックアプリ、マイクロサービス構成 |
| 軽量級 | 静的ファイル中心、ローカルサービス不要、最小限のツーリング | ランディングページ、ドキュメントサイト、シンプルなスクリプト |
推奨アサインパターン
Section titled “推奨アサインパターン”| パターン | リスク | 推奨 |
|---|---|---|
| 軽量級 + 軽量級 | 最小 | 1体のミニオンで問題なく兼任可能 |
| 重量級 + 軽量級 | 低 | 作業ディレクトリの分離で対応可能 |
| 重量級 + 重量級 | 高 | ミニオンを分けるべき |
起こりうる問題
Section titled “起こりうる問題”1. メモリの混濁
Section titled “1. メモリの混濁”ミニオンの長期記憶は単一のSQLiteデータベースに保存されています。スコーピングなしでは、プロジェクトAで学んだこと(コーディング規約、アーキテクチャ判断)がプロジェクトBの作業中にノイズとして影響する可能性があります。
対策: メモリエントリは project_id によるスコーピングをサポートしています。プロジェクト固有の知識にはプロジェクトIDがタグ付けされ、汎用的なノウハウ(ユーザーの好み、一般的な技術知見)はスコープなしのまま保持されます。project_id付きでクエリすると、そのプロジェクト固有のメモリと汎用メモリの両方が返されます。
# プロジェクトスコープでメモリ検索curl -H "Authorization: Bearer $API_TOKEN" \ "http://localhost:8080/api/memory?search=キーワード&project_id=プロジェクトUUID"
# 汎用メモリ(全プロジェクト横断)curl -H "Authorization: Bearer $API_TOKEN" \ "http://localhost:8080/api/memory?search=キーワード"2. MCP設定の衝突
Section titled “2. MCP設定の衝突”.mcp.json はミニオン全体で共有されます。2つの重量級プロジェクトが異なるMCPサーバー設定(例: 異なるSupabase接続文字列)を必要とする場合、後からデプロイされた設定で上書きされます。
対策: 重量級 + 軽量級の組み合わせでは、軽量プロジェクトがプロジェクト固有のMCPサーバーを必要としないため問題になりにくいです。重量級 + 重量級の場合はミニオンを分けてください。
3. 環境変数・シークレットの衝突
Section titled “3. 環境変数・シークレットの衝突”ミニオンのシークレットは process.env にフラットにロードされます。プロジェクトAとBが SUPABASE_URL や DATABASE_URL を異なる値で必要とする場合、値が競合します。
対策: プロジェクトごとに異なる変数名を使用する(例: PROJECT_A_SUPABASE_URL)か、シークレット名が重複するプロジェクトには別々のミニオンをアサインしてください。
4. ポートの競合
Section titled “4. ポートの競合”重量級プロジェクトはローカルサービスを起動することが多いです(Supabaseのポート54321、開発サーバー、Dockerコンテナなど)。2つの重量級プロジェクトが同じデフォルトポートを取り合います。
対策: ミニオンを分けてください。ポートの再設定は壊れやすく、エラーの原因になりがちです。
5. スキル名の衝突
Section titled “5. スキル名の衝突”スキルは ~/.claude/skills/<name>/ にグローバルに格納されます。2つのプロジェクトが同名のスキル(例: deploy, test)を異なる内容で定義すると、後からデプロイされた方で上書きされます。
対策: プロジェクト接頭辞付きのスキル名を使用してください(例: projectA-deploy, projectB-deploy)。
6. Dockerとリソースの競合
Section titled “6. Dockerとリソースの競合”重量級プロジェクトがそれぞれDockerコンテナを起動すると、一般的にスペックが控えめなVPS(Lightsail)上でメモリとCPUを圧迫します。
対策: リソース使用量を監視してください。VPSが逼迫している場合は、プロジェクトを別々のミニオンに分割してください。
ベストプラクティス
Section titled “ベストプラクティス”作業ディレクトリを分離する
Section titled “作業ディレクトリを分離する”プロジェクトごとに異なる作業ディレクトリを使用してください:
~/projects/ project-a/ # 重量級フルスタックアプリ project-b/ # 軽量級静的サイトメモリにプロジェクトスコープをタグ付けする
Section titled “メモリにプロジェクトスコープをタグ付けする”プロジェクト固有の学び(技術スタック、規約、アーキテクチャ判断)を保存する際は project_id を含めてください。ユーザーの好みや一般的なノウハウは汎用(project_id なし)として保持します。
| メモリの種類 | スコープ | 例 |
|---|---|---|
| ユーザーの好み | 汎用 | 「レビューコメントは日本語で記述」 |
| 一般的な技術知見 | 汎用 | 「日本語検索にはFTS5 trigramトークナイザを使用」 |
| プロジェクトのアーキテクチャ | プロジェクト固有 | 「プロジェクトAはNext.js 16 + Supabase構成」 |
| プロジェクトの規約 | プロジェクト固有 | 「プロジェクトAはESLint strictモード必須」 |
迷ったらミニオンを分ける
Section titled “迷ったらミニオンを分ける”追加のLightsail VPSのコストは、プロジェクト間の情報汚染によるデバッグ時間と比べれば低コストです。2つのプロジェクトが両方とも重量級であれば、それぞれに専用のミニオンを割り当ててください。