この記事について
刷新された Claude Projects を、GitHub を日常的に使う開発者向けに解説します。コーディネーターとスレッドの仕組み、ブランチと PR の扱い、プロジェクトメモリと指示、Remote Control によるローカル実行、使用量の節約、ベータ中の制限までまとめました。「そもそも何が変わったのか」という導入は、姉妹記事の初心者編にあります。情報は2026年10月12日時点、Anthropic 公式ドキュメントにもとづきます。
なお、筆者のアカウントはまだ Projects のベータの対象になっていません。この記事は実際に動かして確かめたものではなく、公式ドキュメントと公式記事を読んで整理したものです。
並行作業をしたいだけなら、クラウドセッションを複数立てればいい。では、わざわざ「プロジェクト」にする意味はどこにあるのか。
答えは、調整役を自分でやらなくて済むことです。
複数セッションを手で回すと、どれに何をやらせるかを決め、毎回同じ前提を貼り直し、どれが終わってどれが詰まっているかを見に行く。この調整を、全部自分で抱えることになります。プロジェクトでは、そこを Claude が引き受けます。投げるのは仕事、決めるのは方針だけ。要点はこれに尽きます。
以下、仕組みと勘所を順に見ていきます。
前提（2026年10月時点）
Projects は Pro・Max のパブリックベータです。クラウドセッション利用者かつ、claude.ai チャットや Cowork に既存プロジェクトがないアカウントから順次ロールアウト中。Team・Enterprise と無料プランは未対応です。使える場所は claude.ai/code、デスクトップアプリの Code タブ、iOS・Android アプリ。ターミナル CLI、VS Code・JetBrains 拡張、Bedrock・Vertex・Foundry 経由は対象外です。
全体像：コーディネーター＋スレッド
プロジェクトの実体は、「クラウド上の Claude Code セッションを、Claude 自身がオーケストレーションする仕組み」です。Slack から使う Claude Tag と同じアーキテクチャで、プロジェクトごとに1体のコーディネーターがメモリを管理し、作業用のスレッド（＝サブのセッション）を起動します。
構成要素は次のとおりです。
- プロジェクト会話：コーディネーター役の Claude。送られた依頼を何のスレッドにするか判断し、全スレッドを把握する。各スレッドの「報告」は見るが、途中の全ステップは見ない
- スレッド：実働役。独立したコンテキストウィンドウを持つ別セッション。クラウドスレッドは専用ブランチで作業し、必要に応じて PR を開く
- Overview：Threads（状態別一覧）／Library（追加ファイル＋成果物）／Pull requests／Routines（定期実行）の各タブ
各クラウドスレッドが起動時に受け取るのは、プロジェクトの指示とメモリ、プロジェクトの各リポジトリの CLAUDE.md とスキル、claude.ai アカウントのコネクタ、ネットワークや環境変数を定めるクラウド環境です。手元のマシンの Claude Code 設定は引き継がれません。ここは最初に押さえておきます。
スレッドをどう動かすか
スレッドとブランチ、PRの扱い
クラウドスレッドがコードを変更するとき、指示がなければ既定の動きはこうです。
- ブランチ：デフォルトブランチから新しいブランチを切って作業
- PR：頼めば開く。バグ修正など具体的な変更では自分から開くこともある
- PRを開いた後：auto-fix を有効にして自分の PR を監視。CI が落ちれば修正を push し、レビューコメントに対応し、通ったらスレッドで報告する
複数スレッドが同じコードを触れば、通常どおりマージコンフリクトとして解消が必要になります。スレッドのカードには「Resolve conflicts」「Fix CI」「Address comments」「Merge it」などのボタンが出て、その指示をスレッドに送れます。PR を開くタイミング（「頼んだときだけ」など）や、どのブランチから切るかは、タスクかプロジェクト指示で指定します。
承認はスレッドの中で
ここは見落としやすい点です。スレッドは、モデルが対応していれば auto モードで動くので、多くのツール呼び出しは確認なしで進みます。ただし承認が必要なとき、そのプロンプトはスレッドの中に出ます。プロジェクト会話で「進めて」と言っても、そのスレッドには届きません。承認は該当スレッドを開いて答えます。
特定のコマンドを全スレッドで無確認にしたい、あるいは禁止したいときは、リポジトリの .claude/settings.json に権限ルールを書きます。ただし後述のとおり、クラウドスレッドがこれを読むのは単一リポジトリ構成のときだけです。複数リポジトリ構成では、どのリポジトリの権限ルールもクラウドスレッドには効かず、auto モードと各スレッド内での承認に頼ります。
コーディネーターへの指示でふるまいを変える
スレッドの動かし方は、会話での一言で調整できます。公式が例として挙げているのは、こういった指示です。
- 「提案だけして、GOを出すまで開始しない」／「確認不要、いま始めて」
- 「同時に動かすのは2本まで」／「同じ領域の追加依頼は既存スレッドを使い回して」
- 「更新は短めに」／「完了か詰まったときだけ投稿して」
- 「このタスクは小さいモデルで」
- 「プランを見せるまで PR は開かないで」
こうした好みは Claude が自分でプロジェクトメモリに保存し、以後のスレッドで守ろうとします。ただし強制設定ではなく「守ろうとする指示」です。本数制限なども、ここで伝えたぶんはあくまで好みで、強制上限ではありません。必ず全スレッドに効かせたいことは、プロジェクト指示に明文化します。
文脈をまたいで運ぶ：メモリ・指示・環境
標準コンテキスト：メモリと指示
スレッドをまたいで文脈を運ぶ仕掛けが3つあります。
| 種類 | 運ぶもの | 設定場所 |
|---|---|---|
| プロジェクトメモリ | 要件・決定・ハマりどころ。ファイルで保持。索引は MEMORY.md | 会話や任意のスレッドで「覚えて／忘れて」。閲覧・編集は Project settings > Memory |
| プロジェクト指示 | 新スレッドが毎回最初に受け取るブリーフ（上限16,000文字） | Project settings > Memory > Project instructions |
| リポジトリ・ファイル・環境 | クローンするリポジトリ、/mnt/project-files 下で読めるファイル、クラウド環境 | Project settings > Environment、Library タブ |
各クラウドスレッドは起動時に索引 MEMORY.md を読み、必要に応じて他のファイルを開きます。注意したいのは置き分けです。プロジェクトメモリは、手元の Claude Code が持つ auto memory や、リポジトリの CLAUDE.md とは別物です。リポジトリ固有のルール（ビルドコマンドなど）はそのリポジトリの CLAUDE.md に、プロジェクト全体の前提はプロジェクトメモリに書きます。
プロジェクト指示の雛形として、公式はこんな例を挙げています。
| 1 2 3 4 5 6 7 8 | このプロジェクトは payments-api の p95 レイテンシを 200ms 未満に保つ： プロファイリング、クエリ・キャッシュ改善、それに伴う依存更新。 - main からブランチを切り、スレッドごとに draft PR を1つ開く。 - 完了とする前に `make test` と `make lint` を実行し、要約行を最終メッセージに貼る。 - 必要なもの（リポジトリ・シークレット・API・コネクタ）に届かないときは、 何が足りないかを最初のメッセージで明言して止まる。代替・モック・推測はしない。 - merge / force-push / CI設定の変更は、スレッド内で私に確認せず行わない。 |
リポジトリ構成：単一と複数で挙動が変わる
ここは見落としやすい差です。各クラウドスレッドはプロジェクトの全リポジトリをクローンし、すべての CLAUDE.md とスキルを読み込みます。ただし権限ルール・フック・env は、スレッドが起動するディレクトリの .claude/settings.json からしか読みません。
- 単一リポジトリ：そのリポジトリ内で起動するため、
CLAUDE.md・スキルに加え、権限ルール・フック・envも効く（クラウドが無視する一部のenvキーを除く） - 複数リポジトリ：クローンの上の階層で起動するため、どのリポジトリの権限ルール・フック・
envも効かない。各リポジトリのCLAUDE.mdとスキルは読み込まれる
複数リポジトリ構成では、恒久ルールはプロジェクト指示へ、環境変数はクラウド環境へ寄せるのが安全です。プロジェクトに入れていないリポジトリも、タスクが必要とすればスレッドが自分で追加できますが、その場合クローンは作業の途中で行われるため、起動時点ではそのリポジトリの CLAUDE.md やスキルは読み込まれていません。
スキル・プラグイン・コネクタの持ち込み
クラウドスレッドには、手元のマシンにしか入っていないスキル・MCP サーバー・プラグイン・ツールはありません。持ち込み方は次のとおりです。
- スキル・サブエージェント・コマンド：プロジェクトに追加したリポジトリにコミットする（例
.claude/skills/<name>/SKILL.md）。全スレッドが各リポジトリの.claude/を読み込む。claude.ai アカウントで有効化したスキルも読まれる - プラグイン：Project settings > Plugins で追加する。リポジトリの
.claude/settings.json宣言はクラウドスレッドでは読まれない - MCP サーバー（コネクタ）：claude.ai アカウントのコネクタから供給される。プロジェクト会話自体にはコネクタがないので、コネクタが要る作業はスレッドに回す。単一リポジトリ構成なら、そのリポジトリの
.mcp.jsonも読まれる - CLI ツール・パッケージ：クラウド環境のセットアップスクリプトでインストールする
自分のPCで動かす（ローカル実行）
ここが、9月の発表直後から変わった重要点です。発表当初は「ローカル対応は近日中」とされていましたが、現在はローカル実行に対応しています。ローカル DB、実機エミュレータ、VPN 内の API など、自分のマシンにしかないものが必要なタスクは、そのスレッドだけ自分の PC で動かせます。プロジェクトの他のスレッドはクラウドで動いたままです。
仕組みは Remote Control 経由です。クラウドスレッドとの違いを整理します。
- そのマシンのファイル・ツール・MCP サーバー・Claude Code 設定（フックや権限ルール含む）を使う
- プロジェクト指示は引き継ぐが、メモリファイルはロードされない
- そのPCが起きていて Remote Control がオンの間だけ動く（クラウドと違い、閉じると止まる）
接続は、要 Claude Code v2.1.280 以降。デスクトップアプリの「設定 > Claude Code」で「この端末をスマホと claude.ai から使う」をオンにしてフォルダを登録するか、ターミナルで対象フォルダにて claude remote-control を起動しておきます。gitリポジトリなら --spawn worktree で各スレッドに専用 worktree を割り当てられます。
| 1 2 3 4 5 | # 対象フォルダで起動したままにしておく claude remote-control # gitリポジトリで、スレッドごとに専用worktreeを割り当てる claude remote-control --spawn worktree |
あとは、プロジェクト会話で + メニューの「Work locally」を選ぶと、そのスレッドがマシン上のフォルダで動きます。カードの「Allow Claude to work in a folder on your device」でフォルダを選び、「Allow once」で許可します。1つのフォルダで2本同時に動かすと互いの変更を上書きしうるので、gitリポジトリなら「Worktree」をオンにして分けます。
なお、アカウントで「Require trusted devices（信頼済み端末を必須にする）」をオンにしていると、プロジェクトはローカル実行できません。
GitHubの前提条件
コードを扱うなら、次が必要です。
- コードが github.com にある（GitHub Enterprise Server・GitLab・Bitbucket は不可）
- 連携した GitHub アカウントにプッシュ権限がある
- 対象リポジトリに Claude GitHub App がインストールされている（組織リポジトリは組織オーナーの承認が必要。SAML SSO 必須の組織では再認証も必要）
注意点として、ターミナルで /web-setup により GitHub 連携したトークンは、他のクラウドセッションには効きますが、プロジェクトのクラウドスレッドには足りません。スレッドは Claude GitHub App を必要とします。リポジトリアクセス系のエラーは、たいていこの App の未インストール・サスペンド・アカウント未リンクのいずれかです。
使用量とコスト
料金は別建てではなく、既存プランの枠を消費します。そして単一セッションより速く枠を使います。とくに Pro では、プロジェクトを回した日は上限に早く届くと見ておくべきです。消費源は3つです。
- 走っているスレッド：1本が完全なセッション。同時に何本も動く。本数の指定は好みで、強制上限は全プロジェクト合計で1日200スレッド
- 会話そのもの：コーディネーターが報告を読み、次を判断するためにトークンを使う
- PRを監視中のスレッド：CI 失敗やレビューコメントで待機中のスレッドが起き、再び枠を使う
何も動いていないプロジェクト（実行中スレッドなし・監視PRなし・新規メッセージなし）は、放置しても枠を使いません。アーカイブ済みも同様です。節約の勘所はこうです。
- 新規プロジェクトの既定（Opus・高思考強度）を、スレッド／会話／両方で下げる
- 同時実行数を抑える（会話で「同時2本まで」と伝える）
- 新しい用事は新しいスレッドで始める。放置して長くなった古いスレッドに続きを頼むと、会話全体を読み直して割高になる（キャッシュ保持は Pro・Max で1時間）
- 使用量は Project settings > Usage でスレッド別・モデル別に確認する
上限に達したスレッドは停止せず待機し、リセット後に自動で続きを進めます。プラン上限を超えて使えるのは、利用クレジットを有効にしている場合だけです。ただし routine から起動したスレッドは待機せず、上限エラーで止まります（リセット後に自分でメッセージを送って再開）。
知っておきたい制限（ベータ中）
- プロジェクトは1ユーザー専用。共有不可で、スレッドのトランスクリプトに共有オプションはない。組織レベルの管理機能もベータ中はなし
- 自分でマシン上に立てたローカルセッションは、プロジェクトに追加できない。プロジェクトがマシンに届くのは Remote Control でスレッドを動かすときだけ
- スレッドは起動元のプロジェクトに属し、別プロジェクトへ移動・複製はできない。「Move to project」はクラウドセッションをプロジェクトに取り込む一方向のみ。プロジェクト同士の統合も不可
- クラウドスレッドのサンドボックスはターン間で一時停止し、続きで再開する。再開に失敗すると未コミットの変更が失われうるので、長いタスクでは途中コミット・pushを指示する
近い機能との違い
- クラウドセッション：各スレッドの実体。違いは「誰が起動・追跡するか」。プロジェクトでは Claude が代わりにやる。自分で立てたクラウドセッションは「Continue as project」「Move to project」でプロジェクト化・合流できる
- サブエージェント：1つのセッション内で side タスクを別コンテキストで走らせ、要約を返す。プロジェクトのスレッドは“丸ごとのセッション”で会話に報告する点が違う（スレッドが内部でサブエージェントを使うのはあり）
- Claude Tag：チームの Slack でみんなが使う（Team・Enterprise）。プロジェクトは自分専用（Pro・Max）
- Routines：プロジェクト内で定期実行を頼むと、そのプロジェクトのスレッドとして動く routine が作られ、Routines タブに出る
つまずいたときの見方
- スレッドが止まって見える：途中ステップは会話に出ないので、たいていは作業中。新規スレッドは環境構築のぶん最初の反応が遅い。スレッドを開いてトランスクリプトを見る
- 複数スレッドが勝手に仮定して進む／詰まる：原因はたいてい共通のセットアップ不足。会話で「全スレッドについて、何を頼まれ、何を仮定し、何に届かず、何を待っているか一覧して」と聞き、プロジェクト指示か環境を一度直してから、1本試して残りを流し直す
- 「Claude hasn’t responded」バナー：Project settings > General の「Restart」で会話を再接続（スレッドは影響なし）
- 「Claude ran out of context on this turn」：そのスレッドがコンテキストを使い切った。続く旨の表示があれば新セッションで継続、なければ残り作業を新スレッドで
公式ドキュメントはベータ中も更新が続いています。ここに書いたのは、2026年10月12日時点の公式情報の整理です。筆者のアカウントにロールアウトが届いたら、WordPress プラグイン開発で実際に試した結果を、この記事に追記する予定です。
関連と参考（一次情報）
Rapls Works のその他の記事
- Rapls AI Chatbot ガイド｜WordPress AIチャットボットの導入から運用まで ── WordPress に AI チャットボットを設置できるプラグイン。
- Rapls PDF Image Creator｜WordPress PDFサムネイル生成プラグイン ── PDF をアップロードすると、自動でサムネイル画像を生成するプラグイン。
コメント