コンテンツにスキップ

複数プロジェクトの兼任

1体のミニオンを複数のプロジェクトにPMまたはEngineerとしてアサインできます。このガイドでは、複数プロジェクト兼任時のトレードオフと推奨プラクティスを解説します。

すべてのプロジェクトが同じリソースを必要とするわけではありません。プロジェクトの「重量」を把握することで、1体のミニオンで兼任可能かどうかを判断できます。

重量特徴
重量級ローカルDB(Supabase, PostgreSQL)、Dockerコンテナ、プロジェクト固有のMCPサーバー設定、複数ポート使用Supabase付きフルスタックアプリ、マイクロサービス構成
軽量級静的ファイル中心、ローカルサービス不要、最小限のツーリングランディングページ、ドキュメントサイト、シンプルなスクリプト
パターンリスク推奨
軽量級 + 軽量級最小1体のミニオンで問題なく兼任可能
重量級 + 軽量級作業ディレクトリの分離で対応可能
重量級 + 重量級ミニオンを分けるべき

ミニオンの長期記憶は単一のSQLiteデータベースに保存されています。スコーピングなしでは、プロジェクトAで学んだこと(コーディング規約、アーキテクチャ判断)がプロジェクトBの作業中にノイズとして影響する可能性があります。

対策: メモリエントリは project_id によるスコーピングをサポートしています。プロジェクト固有の知識にはプロジェクトIDがタグ付けされ、汎用的なノウハウ(ユーザーの好み、一般的な技術知見)はスコープなしのまま保持されます。project_id付きでクエリすると、そのプロジェクト固有のメモリと汎用メモリの両方が返されます。

Terminal window
# プロジェクトスコープでメモリ検索
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=キーワード"

.mcp.json はミニオン全体で共有されます。2つの重量級プロジェクトが異なるMCPサーバー設定(例: 異なるSupabase接続文字列)を必要とする場合、後からデプロイされた設定で上書きされます。

対策: 重量級 + 軽量級の組み合わせでは、軽量プロジェクトがプロジェクト固有のMCPサーバーを必要としないため問題になりにくいです。重量級 + 重量級の場合はミニオンを分けてください。

3. 環境変数・シークレットの衝突

Section titled “3. 環境変数・シークレットの衝突”

ミニオンのシークレットは process.env にフラットにロードされます。プロジェクトAとBが SUPABASE_URLDATABASE_URL を異なる値で必要とする場合、値が競合します。

対策: プロジェクトごとに異なる変数名を使用する(例: PROJECT_A_SUPABASE_URL)か、シークレット名が重複するプロジェクトには別々のミニオンをアサインしてください。

重量級プロジェクトはローカルサービスを起動することが多いです(Supabaseのポート54321、開発サーバー、Dockerコンテナなど)。2つの重量級プロジェクトが同じデフォルトポートを取り合います。

対策: ミニオンを分けてください。ポートの再設定は壊れやすく、エラーの原因になりがちです。

スキルは ~/.claude/skills/<name>/ にグローバルに格納されます。2つのプロジェクトが同名のスキル(例: deploy, test)を異なる内容で定義すると、後からデプロイされた方で上書きされます。

対策: プロジェクト接頭辞付きのスキル名を使用してください(例: projectA-deploy, projectB-deploy)。

重量級プロジェクトがそれぞれDockerコンテナを起動すると、一般的にスペックが控えめなVPS(Lightsail)上でメモリとCPUを圧迫します。

対策: リソース使用量を監視してください。VPSが逼迫している場合は、プロジェクトを別々のミニオンに分割してください。

プロジェクトごとに異なる作業ディレクトリを使用してください:

~/projects/
project-a/ # 重量級フルスタックアプリ
project-b/ # 軽量級静的サイト

メモリにプロジェクトスコープをタグ付けする

Section titled “メモリにプロジェクトスコープをタグ付けする”

プロジェクト固有の学び(技術スタック、規約、アーキテクチャ判断)を保存する際は project_id を含めてください。ユーザーの好みや一般的なノウハウは汎用(project_id なし)として保持します。

メモリの種類スコープ
ユーザーの好み汎用「レビューコメントは日本語で記述」
一般的な技術知見汎用「日本語検索にはFTS5 trigramトークナイザを使用」
プロジェクトのアーキテクチャプロジェクト固有「プロジェクトAはNext.js 16 + Supabase構成」
プロジェクトの規約プロジェクト固有「プロジェクトAはESLint strictモード必須」

追加のLightsail VPSのコストは、プロジェクト間の情報汚染によるデバッグ時間と比べれば低コストです。2つのプロジェクトが両方とも重量級であれば、それぞれに専用のミニオンを割り当ててください。