Claudeの「Projects」機能が全面的な刷新を遂げました。これまでの単なるドキュメント置き場から、仕事を自律的に割り振る「AIプロジェクトマネージャー」へと劇的な進化を遂げています。
旧来のProjectsは、関連資料をアップロードしてカスタム指示を書くための静的なフォルダに過ぎませんでした。しかしClaude Codeのベータ機能としてローンチされた新生Projectsは、長期間にわたって稼働し続ける「オーケストレーター（統括指揮）対話」へと変貌しました。人間は高レベルな「目標」を伝えるだけでよく、タスクの分解、作業の着手、進捗の追跡、成果物の自己レビューまで、すべてClaudeが自動で差配してくれます。
公式ドキュメントを読み込み、特に押さえておくべき核心的な変更点をまとめました。
核心：オーケストレーター ＋ 並行ワーカースレッド
プロジェクトのメインチャットに開発要件、バグ報告、エラーログ、アイディアを投げ込むと、オーケストレーターが自ら判断します。「即答できるものはその場で返し、重い実装タスクは新規スレッドを立てて切り出し、関連する既存スレッドがあればそこへルーティングする」という挙動です。
各スレッドはそれぞれ独立したコンテキスト、Gitブランチ、リポジトリのワークスペースを持つ、完全なClaude Codeのクラウドセッションです。もし複数のスレッドが同一ファイルを変更した場合は、通常のGitのコンフリクト解消フローに沿って安全にマージ処理が行われます。
すべてのスレッドが共有する「プロジェクトメモリ」
すべての並行スレッドは、同一のプロジェクトメモリを読み書きします。「リリース日が金曜に延期されたことを覚えておいて」「決済サービスを触る前に必ず人間に確認して」といった指示を与えると、以降に立ち上がるすべてのスレッドがその共通認識を持った状態で作業を開始します。また、「どのくらいの頻度で進捗報告すべきか」「どの程度詳細なログを出すか」といった人間の好みのワークスタイルも学習・記憶されます。
最大16,000文字の「プロジェクト共通指示書」
新しく立ち上がる全スレッドに渡されるシステムプロンプトとして、最大16,000文字のプロジェクト指示書を記述できます：
- プロジェクトの最終ゴール
- どのブランチからチェックアウトして作業するか
- 完了前に必ずパスすべきテストスイート
- 権限不足時の挙動
- 人間の事前承認が絶対に必須な破壊的操作の定義
俯瞰できるOverviewダッシュボード
サイドバーには全スレッドの進行状況がリアルタイムに可視化されます：
- 要レビュー（Needs review）
- 人間の返信待ち（Waiting on you）
- 実行中（In progress）
- マージ中（Merging）
- アイドル（Idle）
- 完了（Done）
1時間ほど席を外して戻ってきても、どのPRがレビュー待ちで、どのスレッドがエラーで立ち往生しているかがひと目で把握できます。Libraryタブには、ユーザーが投入した素材やClaudeが自律生成した成果物ファイルが集約されます。
PRの自律監視と修正サイクル
スレッドがGitHub上でPR（プルリクエスト）を作成すると、ClaudeはそのままPRの監視を続けます。CIテストが落ちたら自らコミットを積んでバグを直し、人間からレビューコメントがついたら指摘通りにコードを修正し、すべてのCIチェックがグリーン（通過）になった段階でユーザーに通知を送ってくれます。
ローカル実行とハイブリッド連携
社内イントラネットのAPI、ローカルデータベース、シミュレータへの接続が必要なタスクについては、特定のワーカースレッドだけを開発者のローカルマシン上で直接実行させることができます（他のスレッドはクラウド上で通常通り並行稼働）。※Claude Code v2.1.280以降が必要。
モデルと推論強度の個別設定
統括オーケストレーターと各ワーカースレッドには、それぞれ異なるモデルや推論強度（Reasoning Effort）を割り当てられます。デフォルトはOpusとなっており、設定画面から各スレッドが消費したトークン数を詳細に確認できます。
はじめ方
利用開始はとても簡単です。http://claude.ai/code、デスクトップアプリの「Code」タブ、またはモバイルアプリからアクセスできます。
左サイドバーの「Projects」→「New project」をクリックして名前を入力すれば作成完了です。GitHubリポジトリ、ローカルファイル、Google Driveのフォルダをアタッチできます。既存のクラウドセッションをメニューから「Continue as project」を選んでプロジェクト化することも可能です。※コードを扱う場合は、GitHub上にリポジトリを置き、Claude GitHub Appをインストールしておく必要があります。
実践的なプロンプトのコツ
プロジェクトを作成したら、まずプロジェクト指示書を整え、小さめのタスクを1つ投げて様子見することをお勧めします。どんなブランチ運用をするか、どう報告してくるかを観察し、信頼できるようになってから大規模なタスクを並行投入しましょう。以下の指示フレーズが極めて効果的です：
- 「作業を開始する前に、まず作成予定のスレッド一覧を提示して私の確認を待ってください」
- 「同時に走らせる並行スレッドは最大2本までに制限してください」
- 「完了したとき、または完全にブロックされたときだけ報告してください」
- 「このタスクはコストを抑えるため小型モデルを使ってください」
- 「勝手に修正を始めず、まず問題点の原因だけを整理して報告してください」
期待以上にうまく機能するユースケース
- レガシーAPIの廃止・移行：API側、Webフロントエンド側、モバイルアプリ側で3本のスレッドを同時に立ち上げ、全呼び出し箇所を一括移行。テストを通した上でそれぞれのPRを作成し、最後にどの順番でマージすべきか手順書を提示させる。
- パフォーマンスチューニング：目標レイテンシを設定し、エンドポイントごとにプロファイリング、コード最適化、PR作成を順次自律実行させる。
- エラーログの集約と予防保守：日々発生するバグやエラーログをプロジェクトチャットに随時放り込んでおくと、踏んだ落とし穴が自動的にメモリに蓄積され、以降の実装で同じバグを絶対に踏まなくなる。
- 仕様書からの複数機能の並行実装：PRD（要件定義書）を放り込むだけで、複数のスレッドが各コンポーネントを分担して並行実装する。
- コード以外の非エンジニア業務：大量の契約書や問い合わせチケットをアップロードし、頻出するトラブルや改善要望を体系的に分析させて、そのレポートをLibraryにファイルとして出力させる。
もちろん注意点もあります。最大のリスクは**「トークン消費スピードの凄まじさ」**です。各スレッドが丸ごと1つの独立したセッションとして動くため、並行で何本も走らせるとProプランのクォータが一気に削られます。また、PRを監視しているアイドル状態のスレッドも、CIエラーが起きるたびに再起動してトークンを消費します。万が一、共有メモリに誤った前提知識が書き込まれてしまうと、以降の全スレッドがその間違った前提に引っ張られてしまうため、メモリの内容は定期的に目視確認することをお勧めします。
