2026年9月29日更新：公式ドキュメントの変更に合わせて2か所を直しました。①手元の環境が要るタスクだけ、そのスレッドを自分の PC で動かす「ローカルで作業」が加わり、「手元の環境が要るならプロジェクトは選べない」は正しくなくなりました。②リポジトリの .claude/settings.json で有効にしたプラグインは、スレッドには読み込まれないと公式ドキュメントが説明しています（プロジェクト設定の Plugins で足す）。表を直しました。実際にサイトを丸ごと作らせた記録はプロジェクト機能を使ってみたにまとめています。
目次
2026年9月17日、Anthropic が Claude Code のプロジェクトを作り直したと発表しました。名前そのものは前からあります。claude.ai のチャットで「会話と資料をまとめておく入れ物」として使われてきた、あのプロジェクトです。新しいプロジェクトは、同じ名前のまま中身が別物になりました。公式ブログの副題がそのまま答えになっていて、「フォルダから会話へ（from folder to conversation）」と書かれています。
何が変わったのかを一言でいえば、仕事を配る係が、あなたからClaudeに移ったということです。あなたは会話に用件を放り込むだけで、Claude がそれを「スレッド」に切り分け、スレッドはクラウドで並列に走り、終わるとプルリクエストを置いて報告してきます。パソコンを閉じても止まりません。
ただし、飛びつく前に確かめることが3つあります。使えるアカウントがまだ限られていること、GitHub が事実上の必須条件であること、そしてトークンの減り方が単発のセッションとは比べものにならないことです。この記事では、Claude Code の公式ドキュメントと公式ブログに書かれている条件を一次情報から拾い直し、「自分は使えるのか」「使ったら何が起きるのか」を順に整理します。
先に結論——プロジェクトの3つの顔
出典: Claude Code 公式ドキュメント「Let Claude coordinate ongoing work with Projects」
配る係がClaudeになる
会話1本＋スレッド多数
用件を書くと、Claude が必要な数だけスレッドを立てて追跡する
閉じても続く
スレッド＝クラウド
自分の端末ではなくクラウドで走る。スマホから様子を見て指示できる。
代わりに払うもの
GitHub必須・枠は共通
github.com のみ。利用枠は他のセッションと同じ財布から減る。
1. フォルダではなく、1本の会話になった
新しいプロジェクトは、2つの部品でできています。コーディネーター役のClaudeがいる「プロジェクトの会話」と、その会話が立ち上げる「スレッド」です。
会話のほうは、ずっと続く1本のセッションです。あなたが送ったものを読んで、答えて済むことはその場で答え、仕事になるものはスレッドに切り出します。スレッドの中身を逐一見ているわけではなく、スレッドが報告してきた結果だけを見ています。
スレッドは実働部隊です。1つ1つが独立したクラウドセッションで、自分だけのコンテキストウィンドウを持ち、自分のブランチで作業し、必要ならプルリクエストを開き、終わると会話に報告します。公式ドキュメントでは、スレッドの状態が Overview という一覧に次のように並ぶと説明されています。
Overview に並ぶ6つの状態
Ready for review
PRが開いていて、あなたのレビュー待ち
Waiting on you
返事・承認が要る、または失敗した
Working
まだ動いている
Landing
PRが承認済み、またはマージ待ち行列
Idle
終わって、何も待っていない
Resolved
片付いたもの。1週間動きがなければ自動でここに入る。
ここで大事なのは、並列に動くこと自体は新しくないという点です。Claude Code にはもともと、サブエージェント・agent view・エージェントチーム・動的ワークフローという並列の手段がありました。プロジェクトが加えたのは並列ではなく、「振り分けと追跡を人間がやらなくてよくなること」と「端末を閉じても消えないこと」の2つです。公式ドキュメントも「並列に動かせること自体がプロジェクトの目的ではない」と明記しています。
2. 同じ名前の「旧プロジェクト」とは別物
ややこしいのは、claude.ai のチャット側にも「プロジェクト」があることです。こちらは会話とファイルをまとめる入れ物で、スレッドもコーディネーターもありません。名前が同じなので混同しやすいのですが、公式ドキュメントでは別の機能として扱われています。
| 比較 | 旧プロジェクト（チャット・Cowork） | 新しいプロジェクト（Claude Code） |
|---|---|---|
| 正体 | 会話と参照ファイルのフォルダ | コーディネーターとの会話1本＋スレッド群 |
| 仕事をするのは | あなたが開いた会話 | Claude が立てたスレッド（クラウドセッション） |
| 端末を閉じたら | 止まる | 走り続ける |
| 成果物 | 会話の中の回答 | ブランチ・プルリクエスト・Library タブのファイル |
| 今後 | 当面そのまま動く | ロールアウトの拡大に合わせて旧プロジェクトを順次アップグレード |
💡 三つめの同名機能：ターミナルの Claude Code にある claude project コマンドは、作業ディレクトリのローカル状態を管理するためのもので、この記事のプロジェクトとは名前が同じだけの別物です。公式ドキュメントにもわざわざ「無関係（unrelated）」と注記されています。
3. 使える条件——自分に来ているかの見分け方
2026年9月19日時点では公開ベータで、段階的に配られています。条件がかなり具体的に書かれているので、そのまま引用に近い形で並べます。
配布条件のチェックリスト
✅ プラン
Pro と Max のみ。Team・Enterprise はまだ対象外。
✅ 先に届く人
クラウドセッションを使ったことがあり、かつチャットやCoworkに既存のプロジェクトを持っていないアカウントから
✅ 見る場所
claude.ai/code のサイドバー、またはデスクトップアプリの Code タブ。モバイルアプリからも使える。
❌ 使えない場所
ターミナルのCLI。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry 経由も対象外。
ここで見落としやすいのが2番目です。チャット側に古いプロジェクトをたくさん作り込んでいる人ほど、新しいプロジェクトは後回しになります。公式ブログには、既存プロジェクトは当面そのまま動き、ロールアウトが広がるのに合わせてアップグレードすると書かれています。つまり「使い込んでいる人が先」ではなく、まっさらな人から順に配られているということです。
サイドバーに出ていなければ、まだ自分の番ではありません。その場合は ウェイトリスト に登録できます。探す場所を間違えないことも地味に大事で、出るのは Code 側（claude.ai/code またはデスクトップアプリの Code タブ）のサイドバーです。チャット側のサイドバーをいくら探しても、そこにあるのは旧プロジェクトです。
4. GitHubが要る。ここで脱落する人がいる
ここが実務上いちばん効く制約です。スレッドが扱えるコードは github.com にあるものだけで、しかも Claude GitHub App がそのリポジトリにインストールされている必要があります。公式ドキュメントは、条件を次のように書いています。
- コードが github.com にあること。GitHub Enterprise Server・GitLab・Bitbucket は不可。
- 連携した GitHub アカウントに、そのリポジトリへのプッシュ権限があること。
- Claude GitHub App がそのリポジトリに入っていること。
/web-setupで入れたトークンは他のクラウドセッションには効くが、プロジェクトのスレッドには足りない。 - 組織のリポジトリでは、インストールを完了できるのは組織のオーナーだけ（オーナーでなければ承認待ちになる）。
つまり、自前の git サーバやレンタルサーバのベアリポジトリで運用している個人開発者は、そのままでは対象外です。社内 VPN の先にある API、手元のデータベース、端末のエミュレータ、SSH でつなぐ本番サーバも同様で、スレッドはあなたの端末の外側にいるので触れません。
ただし、2026年9月下旬の公式ドキュメントでは、手元の環境が要るタスクだけ、そのスレッドを自分の PC で動かす「ローカルで作業」（Work locally）が加わっています。中身は Remote Control で、Claude Code v2.1.280 以降が要り、PC が起きている間しか動きません。デスクトップアプリで使う場合は、設定の「このコンピューターをスマートフォンや claude.ai から使用できます」をオンにします。このとき遠隔から作業を始められる対象は、それまでに Claude Code で開いたフォルダの一覧（利用履歴から自動で集まる）なので、使う間だけオンにするのが安全です。
⚠️ 迂回路はあるが、プロジェクト向けではない：通常のクラウドセッションなら、CCR_FORCE_BUNDLE=1 を設定することで GitHub 以外のリポジトリをローカルバンドルとして送り込めます。ただし公式ドキュメントに明記されているとおり、そのリモートへ結果をプッシュし返すことはできません。プロジェクトのスレッドは GitHub App を前提にしているので、この抜け道は「読ませる」用途に限られます。
では GitHub を使っていない人に一切出番がないかというと、そうでもありません。プロジェクトはリポジトリなしでも作れます。契約書のフォルダやサポート問い合わせのエクスポートをアップロードして、「この中で多い統合ミスを10個挙げて」のような仕事をスレッドに投げ、成果物を Library タブで受け取る、という使い方が公式に想定されています。アップロードしたファイルはスレッドから /mnt/project-files 以下で読めます。
コードの仕事で、ほとんどのタスクに手元の環境が要るなら、選ぶべきはagent view でローカルセッションを並べる方法のほうです。こちらは自分の端末で動くので、VPN もローカル DB も SSH も使えます。手元が要るのが一部のタスクだけなら、プロジェクトの「ローカルで作業」でそのスレッドだけを手元に回せます。
5. スレッドが最初から持っているもの
スレッドは毎回まっさらから始まるわけではなく、プロジェクトが与えた前提を持って起動します。持ち物は4種類です。
- プロジェクトのリポジトリとファイル——登録したリポジトリは、そのタスクが触らなくても毎回クローンされる。
- プロジェクト指示——全スレッドに渡る共通の指示書。上限は16,000文字。
- プロジェクトメモリ——Claude 自身が書き足していく記憶。索引の
MEMORY.mdを起動時に読み、必要になったら個別ファイルを開く。 - クラウド環境——ネットワークの許可範囲、環境変数、APIの資格情報、事前インストールされるツール。
この「持ち物」で最も事故になりやすいのが、リポジトリの設定ファイルの扱いが、リポジトリ1個のときと複数のときで変わる点です。公式ドキュメントの表を整理すると、こうなります。
| リポジトリ側にあるもの | リポジトリ1個のプロジェクト | リポジトリ複数のプロジェクト |
|---|---|---|
CLAUDE.md | 起動時に読まれる | 全リポジトリぶん読まれる |
.claude/ のスキル・エージェント・コマンド | 読まれる | 全リポジトリぶん読まれる |
プラグイン（.claude/settings.json で有効化） | 読まれない（プロジェクト設定の Plugins で足す） | 読まれない（プロジェクト設定の Plugins で足す） |
権限ルール・フック・env | 適用される | どのリポジトリのものも適用されない |
理由は単純で、権限・フック・環境変数はスレッドが起動したディレクトリの .claude/settings.json からしか読まれないからです。リポジトリが複数あるとスレッドはクローン群の1つ上の階層で起動するので、どのリポジトリの設定も読まれる場所にありません。リポジトリを1つ足しただけでフックが静かに効かなくなるわけで、これは知らないと気づけません。複数リポジトリのプロジェクトでは、共通ルールはプロジェクト指示に、環境変数はクラウド環境に置く、というのが公式の案内です。
MCP まわりも整理しておくと、スレッドが使える MCP サーバはclaude.ai アカウント側のコネクタです。端末にだけ入れた MCP サーバは届きません。そしてプロジェクトの会話自体にはコネクタがありません。コネクタが要る仕事は、会話で聞くのではなくスレッドに投げる必要があります。
6. トークンはどれだけ増えるのか
ここが導入前にいちばん気になるところです。公式ドキュメントの書きぶりは率直で、プロジェクトは単一のセッションより速く利用枠を使い、とくに Pro では動かした日に上限へ早く届くと思っておくこと、と名指しで警告されています。増える理由は積み上げです。
トークンが増える5つの経路
出典: Claude Code 公式ドキュメント（Projects / Costs）
① スレッド＝フルのセッション
それぞれが独立したコンテキストを持つ。5本走れば5本ぶん。
② 会話そのものも消費する
報告を読み、次を決めるぶんのトークンが別途かかる
③ 既定が Opus の high
新規プロジェクトはスレッドが Opus・高努力、会話が Opus・低努力で始まる
④ PRの見張りで起きる
CIが落ちる・レビューが付くたびに、寝ていたスレッドが起きて動く
⑤ 放置後の読み直し
キャッシュの寿命（Pro・Maxで1時間）を過ぎたスレッドに追撃すると、会話を頭から読み直す
④ は特に注意が要ります。プロジェクトのスレッドは、プルリクエストを開くと自動修正（auto-fix）を既定でオンにして見張ります。他のクラウドセッションで自動修正を切っていても、プロジェクトのスレッドは別扱いです。CI の失敗を直し、レビューコメントに対応し、通ったら報告してくれる一方で、放っておくとそのぶん利用枠を食べ続けます。止めたいときは、そのスレッドに「このPRの監視をやめて」と伝えます。
では、どのくらい増えるのか。プロジェクト自体の倍率は公表されていませんが、同じ「1タスクを複数セッションに割る」仕組みであるエージェントチームについては、公式ドキュメントが「計画モードで動かすと標準セッションの約7倍」という数字を出しています。並列化は速度を買う仕組みであって、節約する仕組みではない——この一点は共通です。
歯止めの効き方も知っておく価値があります。
- 同時に走るスレッド数に上限はありません。「2本までにして」と伝えられますが、公式ドキュメントはこれを「強制される設定ではなく、Claude が守ろうとする指示」と明記しています。強制的な上限は1日200スレッド（全プロジェクト合計）だけです。
- 利用枠に達したスレッドは自分で待ち、枠が回復すると自動で再開します。放っておくと、次の枠を勝手に使い始めます（止めるならスレッドで Stop、またはプロジェクトを一時停止）。例外はルーチンが起動したスレッドで、こちらは待たずにエラーで止まります。
- クラウドの仮想マシンそのものに別料金はかかりません。増えるのはトークンだけです。
- アイドル中のプロジェクト（走っているスレッドも、見張り中のPRも、新しいメッセージも無い状態）は利用枠を使いません。
💡 減らし方（公式の推奨）
- プロジェクト設定 > General で、スレッドのモデルと努力レベルを下げる
- 古いスレッドを叩き起こすより、新しいスレッドを立てるほうが安いことがある（読み直しが発生しないため）
- 会話で「同時に走らせる本数を減らして」「小さい質問はスレッドを立てずにここで答えて」と伝える
- 使い道は プロジェクト設定 > Usage でスレッド別・モデル別に見られる
7. 5つある並列手段の使い分け
Claude Code には、いま並列に仕事をさせる方法が5つあります。プロジェクトはそのうちの1つで、「誰が配るか」と「どこで走るか」が他と違います。公式ドキュメントの比較を、選ぶ基準で並べ直すとこうなります。
| 方法 | 配るのは | 走る場所 | 向いている場面 |
|---|---|---|---|
| サブエージェント | 会話中のClaude | 手元 | 脇道の調査でメインの会話を汚したくないとき |
| agent view | あなた | 手元 | 独立した作業を投げておいて、必要なときだけ介入したいとき |
| エージェントチーム | リーダー役のClaude | 手元 | 1つの仕事を分担させたいとき（実験的機能・既定は無効） |
| 動的ワークフロー | スクリプト | 手元 | 大規模な監査・移行など、結果の相互検証が要るとき |
| プロジェクト | Claude | クラウド | 数日〜数週間続く仕事、端末を閉じても進めたいとき |
この表で自分の状況に線を引くなら、判断はだいたい2つの問いで決まります。手元の環境（ローカルDB・VPN・SSH）が要るか？ ほとんどのタスクで要るなら agent view、一部だけならプロジェクトの「ローカルで作業」でそのスレッドだけ手元に回します。その仕事は今日で終わるか？ 終わるならクラウドに引っ越す意味が薄く、agent view で十分です。サブエージェントとエージェントチームの違いについては別記事で詳しく比較しています。
8. 最初のバッチを投げる前にやること
公式ドキュメントが「最初のバッチの前に」として挙げている手順は4つで、いずれもあとから直すと高くつくものです。
- プロジェクト指示を書く——どのブランチから切るか、終わったと判断する前に何を実行するか、何をする前に自分の承認が要るか。公式の例では「必要なものに届かないときは、何が足りないかを最初のメッセージで言って止まれ。代用も、モックも、推測もするな」と書かれています。
- 本物の仕事を1つだけ投げて、開いて読む——報告の仕方とブランチ上の実物を確認する。
- モデルと努力レベルを見直す——既定の Opus・high のままだと最も速く枠が減ります。
- 「始める前に提案して」「同時に走らせるのは数本まで」と伝えておく——数本が期待どおりに返ってきてから外す。
もう1つ、地味ですが効く注意があります。スレッドのサンドボックスはターン間で一時停止し、次に再開します。再開できなかった場合はクローンからやり直しになるため、コミットしていない変更は失われることがあります。長い作業では「途中でコミットしてプッシュしておいて」と指示しておくのが公式の推奨です。
⚠️ 自動修正とコメント連動の自動化は相性が悪い：自動修正が有効なスレッドは、レビューコメントのスレッドにあなたの GitHub アカウントで返信することがあります（Claude Code が書いたことは明記されます）。Atlantis や Terraform Cloud、issue_comment をきっかけに動く GitHub Actions を使っているリポジトリでは、コメントが本番の操作を起動しうるため、公式ドキュメントも自動修正を切ることを勧めています。
まとめ
新しいプロジェクトは、「並列で動かせるようになった機能」ではなく、「並列で動かす面倒を人間から引き取った機能」です。配る・追う・同じ前提を毎回説明し直す、という手間が消えます。ずっと続く仕事を持っていて、それが github.com の上にあり、Pro か Max に入っているなら、噛み合う可能性は高いといえます。
逆に、ほとんどが手元の環境で進む仕事、自前の git サーバ、今日で終わる単発の作業には向きません。そして共通して言えるのは、並列は速度を買う代わりにトークンを払うということです。既定が Opus の high で、同時本数に強制上限が無く、PR を見張るスレッドが勝手に起きる——この3つを知らずに1日回すと、利用枠の減り方に驚くことになります。最初に設定を下げ、本数を絞り、1本の往復で手応えを確かめてから広げるのが、いちばん安全な入り方です。
プロジェクトで得た調査結果を、読み返せる提案書や手順書にまとめたいなら、Claude Docsの使い方も参考になります。仕事を継続して進めるプロジェクトと、文書を作って編集するDocsは、目的に合わせて使い分けましょう。
FAQ
Q. チャット側にある既存のプロジェクトはどうなりますか？
A. 当面はこれまでどおり動きます。公式ブログには、Pro と Max の既存プロジェクトはそのまま使え、ロールアウトがチャットと Cowork に広がるのに合わせてアップグレードすると書かれています。ただし新しいプロジェクトの配布は、既存プロジェクトを持っていないアカウントから始まっているため、作り込んでいる人ほど順番は後になります。
Q. ターミナルの Claude Code から使えますか？
A. 使えません。使えるのは claude.ai/code、デスクトップアプリの Code タブ、モバイルアプリの3つです。Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry 経由も対象外です。なお CLI の claude project コマンドは名前が同じだけの別機能です。
Q. GitHub を使っていません。どうすればいいですか？
A. コードを動かす用途では、選択肢は3つです。リポジトリを github.com に置いて Claude GitHub App を入れるか、手元で動くagent view を使うか、プロジェクトの「ローカルで作業」でスレッドを手元のフォルダで動かすかです（手元のスレッドは PC が起きている間だけ動き、Remote Control の設定が要ります）。なお、リポジトリを持たないプロジェクトなら GitHub なしで作れます。資料をアップロードして調べ物や文書作成をさせ、成果物を Library タブで受け取る使い方です。
Q. Pro プランでも現実的に使えますか？
A. 使えますが、設定を下げてから使うべきです。公式ドキュメント自身が、とくに Pro ではプロジェクトを動かした日に上限へ早く届くと思っておくこと、と警告しています。新規プロジェクトの既定はスレッドが Opus の high なので、まずそこを落とし、同時に走らせる本数を絞り、プロジェクト設定の Usage で実際の消費を見ながら広げるのが現実的です。
