Claude Projects新ベータの使い方｜複数スレッドの分担と確認【2026年10月更新】

2026年9月17日、AnthropicはClaude Projectsの刷新を発表しました。新しいProjectsでは、一つの会話で依頼した仕事をClaudeが複数のスレッドに分け、進行をまとめます。初期提供はClaude Codeの一部Pro・Maxユーザー向けベータです。公式発表

従来のProjectsも引き続き利用できます。本記事は2026年10月20日に再確認した新ベータの情報を扱い、業務の進め方やプロンプトはMakeAIの提案として掲載しています。利用対象のアカウントで実行を検証した記事ではありません。

新しいProjectsは何を管理するのか

仕事を受ける中央の会話と、個々の作業を進めるスレッドで構成されます。スレッドはプロジェクトの資料、指示、メモリを引き継ぎ、追加した資料や成果物はLibraryに集まります。既存のProjectsから新ベータへの移行は段階的です。公式ヘルプ

たとえば、Webサイトの改善で「表示の不具合を調べる」「フォームの動作を確認する」「修正後のテストを行う」といった関連作業が続く場合、個別の会話へ同じ背景を説明する負担を減らせる可能性があります。

ただし、複数の作業が並行して終わることと、全体が完成することは同じではありません。共通の画面やファイルを変更した場合は、最後に組み合わせた状態を確認する必要があります。

利用対象と実行場所を先に確認する

新ベータはClaude Codeの一部Pro・Maxユーザーから提供が始まり、現在は一部の既存Projectsの移行も進められています。Pro・Maxでも未提供の場合があり、Team・Enterpriseは初期対象ではありません。提供条件

通常のスレッドはクラウドで動くため、手元のパソコンだけにある設定やツールをそのまま使うわけではありません。現在は必要なスレッドをRemote Control経由で手元へ移す方法も案内されています。コードを扱う場合はリポジトリへの接続などが必要です。詳細はClaude CodeのProjectsドキュメントで確認できます。

仕事を渡す前に、完了の条件を決める

MakeAIでは、初めに小さな改善を一つ選び、対象と完成条件を明確にする方法を提案します。以下は架空のWebサイト改善の例です。

項目	記入例
目的	問い合わせフォームで起きる入力エラーを減らす
対象	問い合わせページと、その入力確認処理
完成条件	指定した入力例が正しく通り、エラー例には適切な案内が出る
人が確認すること	画面の文言、送信先、個人情報の扱い、本番への反映

「使いやすくする」だけでは、改善範囲が広がりやすくなります。何を直し、何をもって完了とするのかを先に書くと、作業の抜けや過剰な変更を見つけやすくなります。

Projectsへ依頼するプロンプト例

このプロジェクトでは、問い合わせフォームの入力エラー表示を改善します。
添付の不具合記録と、接続したリポジトリを確認してください。

まず、調査・修正・テストに分けた作業案を出してください。
複数の作業が同じファイルに触れる場合は、担当範囲と統合する順番を整理してください。

完了条件：
・不具合記録の各入力例について、修正前後の結果が分かる
・変更したファイルと変更理由が分かる
・実行したテストと、実行できなかった確認が分かる

今回はレビュー用の変更案までを作成してください。
本番公開、顧客への連絡、契約や権限の変更は担当者が行います。
判断に必要な情報が足りなければ、その作業を止めて質問してください。

この指示例のポイントは、「作業を分けてよい」と「すべてを任せる」を区別することです。人の判断が必要な箇所を決めたうえで、調査や修正を進めます。

並行作業の結果を確認する順番

公式ドキュメントでは、Overviewで進行状況や利用者の対応待ちを確認し、個別スレッドへ入って作業を調整できます。コードのスレッドはそれぞれ独立した作業環境を使うため、変更をまとめる際の確認も必要です。構成と作業の流れ

レビューするときは、まず未完了と対応待ちを確認し、その後に完成したものを見ます。完成した資料やコードだけを読んでいると、前提となる調査が止まっていることを見落としかねません。

次に、成果物を最初の完成条件と照らし合わせます。見た目の整った報告があっても、指定したテストが実施されていなければ、その分は未確認として扱います。

利用量と向いている仕事

複数スレッドを同時に動かすと、契約プランの利用枠を速く消費します。利用量の説明

最初は、作業の数を増やすより、一つの改善を最後まで確認してみてください。MakeAIとしては、関連する依頼が繰り返し発生する仕事、共通の資料やルールを何度も使う仕事で試すと、使いどころを判断しやすいと考えます。

モデルの特徴とProjectsという作業機能は別の話です。モデル選びについてはClaude Fable 5.1の解説を参照してください。

仕事を分ける前に、依存関係を書き出す

Projectsで複数のスレッドを使うときは、数を増やすことより、同時に進めてよい仕事を区別することが大切です。問い合わせフォームを改善する仮の例なら、入力エラーの再現調査と、表示文言の読み直しは別々に始められます。一方、送信処理の仕様が決まる前に、同じ仕様を前提とするテストを書き進めると、後で修正が必要になる場合があります。

まず、各作業の入力と成果物を一行で書きます。「再現調査は不具合記録を受け取り、再現条件を返す」「修正は再現条件を受け取り、変更案を返す」「確認は変更案を受け取り、結果を返す」という形です。何を受け取るまで待つのかが分かれば、並行できる範囲も見えます。これはMakeAIの進行方法の提案で、特定の設定を選ぶと競合がなくなるという説明ではありません。

作業	先に必要なもの	完了時に返すもの
不具合の調査	入力例、発生環境、期待する動作	再現した条件と未再現の条件
画面文言の案	対象画面と利用者の目的	文言の変更案と理由
コードの修正	確定した仕様と再現条件	変更差分、テスト結果、残る問題
統合後の確認	採用する変更がそろった状態	一連の操作結果と未確認事項

同じファイルを触る仕事の扱い

入力チェックとエラー表示が同じファイルにあるなら、二つのスレッドが別々に変更すると競合する可能性があります。担当を分ける場合は、どの関数や領域を担当するか、どちらの変更を先に取り込むかを明示します。変更箇所が密接に関係するなら、一つのスレッドへまとめ、もう一方は読取とレビューを担当させるほうが確認しやすい場合もあります。

競合を解消したことと、不具合が直ったことも別です。両方の変更がファイルに残っていても、組み合わせると動作が変わることがあります。最終的には、利用者が入力して送信結果を受け取るまでの流れを確認します。個々のスレッドが「テスト成功」と報告しただけで、全体が完成したと判断しません。

プロジェクトに残す指示と、今回だけの依頼を分ける

継続する仕事では、全スレッドが守る条件と、一回の依頼だけに必要な条件があります。対象のリポジトリ、成果物を返す形式、検証結果の書き方は共通の指示にできます。一方、今回だけ直すエラーメッセージや調査対象の入力例は、個別の依頼へ置きます。すべてを共通指示へ追加すると、別の仕事にも不要な制約が残ります。

共通の作業方針：
目的は問い合わせフォームの不具合を解消することです。
変更ごとに、元の問題、変更理由、確認結果を残してください。
実行していないテストを成功と記載しないでください。
他の作業が変更した箇所を、理由なく元に戻さないでください。
同じファイルを変更する必要が出たら、担当と統合順を整理してください。
判断が必要な点は、選択肢と影響が分かる形で知らせてください。
今回の依頼：添付した入力例Aで起きるエラーを再現し、修正案を作る。
完了条件：入力例Aが通り、関連する既存の例B・Cの動作が保たれる。

共通指示を更新したら、進行中の仕事にどう影響するかも確認します。新しい指示があるからといって、既に作られた成果物が自動で修正済みになるとは判断できません。影響する作業を挙げ、必要な再確認を依頼してください。前提の変更を記録すれば、古い方針で作られた成果物を誤って採用することを防ぎやすくなります。

Overviewから、止まっている理由を確認する

進捗を見るときは、完成したスレッドの数だけを数えず、残る仕事が何に依存しているかを見ます。待ち状態には、資料不足、利用者の判断待ち、実行環境の問題、利用上限などがあります。必要な対応が違うため、「止まっている」とだけ捉えず、メッセージの内容を読んで分けます。

資料不足なら必要なファイルを特定し、判断待ちなら採用する案を決めます。環境の問題なら、テストに必要なツールや接続先が使えるかを確認します。利用上限なら、追加の作業を増やす前に利用状況を確認します。原因が不明なまま同じ指示を繰り返すと、同じ場所で止まる作業を増やしかねません。

プロジェクトの現在の状況を整理してください。
完了したもの：成果物と確認結果。
進行中のもの：次に出る結果と、必要な入力。
止まっているもの：止まった理由と、再開に必要な判断。
重複しているもの：同じ目的やファイルを扱う作業。
全体の完成条件に対して残っているもの。
完了していない確認を、完了した作業数に含めないでください。

ローカル環境が必要になった場合

2026年10月20日確認の公式ドキュメントでは、通常のスレッドはクラウドで実行し、手元の環境が必要なスレッドはRemote Controlを通じて自分のコンピューターで実行する方法も案内されています。クラウドで動く仕事と、コンピューターが起動している必要がある仕事を分けて確認してください。Projectsの実行場所の説明

この違いは、社内だけのデータベースや手元のアプリに依存する作業で重要です。必要な環境がどこにあるかを特定し、接続できない部分を未確認として残します。環境を変えたら同じテストが実行できるかも確かめます。クラウドで成功した処理が、社内の設定でも同じように動くとは限りません。

完了報告に、統合後の確認を含める

最後の報告は、作業の一覧ではなく、最初の完成条件への回答にします。フォームの例なら、正常入力、必須項目不足、文字数超過、送信エラーの各条件でどうなったかを並べます。画面の文言を変えただけなら、送信先まで確認したとは書きません。実行できなかった確認には、理由と次に必要な環境を付けます。

継続するプロジェクトでは、一回の改善を終えた時点で、次の仕事に必要な決定だけを残します。今回のエラーへの対処をすべて恒久ルールにする必要はありません。今後も守る仕様、使うべき資料、再発時に見る箇所を短くまとめると、次の依頼で同じ確認を繰り返しにくくなります。

Projectsが向いているかは、成果物の量だけでなく、依頼の重複、確認の待ち時間、統合時の修正量で判断します。一つの短い質問で済む仕事まで分割する必要はありません。関連する作業が続き、共通の前提を何度も説明する仕事から試すと、管理の負担が減ったかを確認しやすくなります。

文書中心の仕事でも、成果物の統合役を決める

コードを扱わない仕事でも、分担した結果を一つにまとめる確認が必要です。たとえば営業資料、問い合わせ集計、顧客向け説明文を別スレッドへ依頼した場合、商品名や価格の前提が一致しているかを見ます。それぞれの文章が自然でも、同じサービスについて違う条件を書いているなら、全体としては使えません。

入力資料の正本を一つに指定し、各成果物へ根拠と更新日を残します。統合する担当には、成果物を並べるだけでなく、共通の数字、名称、対象者、未確定事項を照合する役割を渡します。違いが見つかった場合は、作成時点が違うのか、資料が違うのか、解釈が違うのかを分けて確認してください。

各スレッドの文書をまとめる前に、共通条件を照合してください。
商品名、対象顧客、価格、開始日、提供範囲を比較します。
違う箇所は、文書名、根拠資料、対象の文章を並べてください。
確認できた差だけを修正し、判断が必要な差は残してください。
統合後の文書に、未確定の条件が確定情報として混ざっていないか確認します。

作業を細かく分けすぎて、統合の確認に多くの時間がかかる場合は分担を減らします。同じ前提を何度も照合する仕事なら、文章作成と検収だけを分ける構成も考えられます。スレッドの数を評価するのではなく、全体が完成するまでの手間と、確認漏れが減ったかで調整してください。