Claude Code の Projects に、Projects の記事を書かせてみた——初日の実録
Projects で Projects の記事を書く
Claude Code の Projects が作り直され、2026年9月17日からベータとして使えるようになりました1。ゴールを渡すと、コーディネーターが仕事を切り分けて複数のスレッドに配り、各スレッドがクラウド上の Claude Code セッションとして並行に作業する、という仕組みです。
使い始めた初日に、手元で一番確かめやすい題材を選びました。この Projects という機能そのものを紹介する記事を、Projects に下書きさせることです。依頼してから下書きの PR が上がるまでの経過は、プロジェクトチャットとスレッドに秒単位の時刻つきで残ります。体感ではなく、その記録から何が起きたかを追えます。
先に結論を書きます。依頼の受け付けは速く、質問への返答は7秒、新しいスレッドの立ち上げは8秒でした。立ち上がったスレッドは、ブログリポジトリに置いてある執筆ルールを自分で読み、既存の記事パイプラインに沿って作業を進めました。一方で、トークン消費量やスレッドごとのコストのような内部の数値は、スレッドの中からは取れません。この記事の数字は、外から見える時刻とリポジトリの履歴、手元で実行したコマンドの出力に限っています。
新しい Projects の構造
公式の発表によると、新しい Projects は「作業をするスレッド」と「それを指揮するコーディネーター」の二層でできています1。
| 要素 | 役割 |
|---|---|
| プロジェクトチャット | 依頼を書き込む場所。全体の進捗もここで追える |
| コーディネーター | 依頼を受けて切り分け、新しいスレッドを始めるか既存のスレッドに回すかを決める |
| スレッド | 1本ずつが独立した Claude Code のクラウドセッション。自分のブランチとリポジトリの複製を持つ |
| 共有メモリ | 各スレッドが書き込み、読み出す。作業の好みや連絡の頻度もここに学習される |
| ライブラリ | 追加したファイルと、Claude が作った成果物を置く |
スレッドどうしが同じコードを触った場合は、普通の PR と同じくマージコンフリクトとして表に出る、と説明されています1。並列化のための特別な仕組みを持ち込むのではなく、ブランチと PR という既存の道具で衝突を処理する設計です。
提供範囲には制約があります。ベータの対象はクラウドセッションを使う Pro と Max の一部ユーザーで、Team と Enterprise は後回しです。スレッドは今のところクラウドでしか動かず、手元のマシンでの実行は近いうちのリリースで予定されています12。また、スレッドは1本ずつが完全な Claude Code セッションとして数えられるので、並列に走らせるほど利用枠の消費は速くなります2。
実測1 依頼からスレッド起動までの時刻
プロジェクトを作ってから、この記事の下書き PR が上がるまでの記録を並べます。時刻はプロジェクトチャットとスレッドに残ったメッセージのタイムスタンプ（UTC）です。
| 時刻（UTC） | 出来事 | 直前からの経過 |
|---|---|---|
| 12:36:03 | プロジェクト作成。コーディネーターの最初の挨拶が届く | — |
| 12:37:47 | 「リポジトリを足せば実測に基づいた記事は書けるか」と質問する | 1分44秒 |
| 12:37:54 | コーディネーターが「書けます」と返答。取れない数値の注意も添える | 7秒 |
| 12:38:27 | 「この Projects 機能自体について書いてみたい」と依頼する | 33秒 |
| 12:38:35 | チャットに着手の一言が出て、同時にスレッドが立ち上がる | 8秒 |
| 12:38:56 | スレッドに進捗チェックリストが出る | 21秒 |
| 12:40:02 | スレッドが記事の切り口を選択式で確認してくる | 1分6秒 |
| 12:43:18 | 下書きの PR（draft）が上がる | 3分16秒 |
依頼してから下書きの PR が上がるまで、合計で4分51秒でした。この時点の下書きには、著者の所感を書く場所と hero 画像がまだ空いています。
記事の依頼から下書き PR まで4分51秒
2026-10-13 12:38:27（UTC）の依頼を0秒とした経過
ここで目を引いたのは、コーディネーターの最初の返答の中身です。リポジトリから取れるものとして、コミット履歴、PR、差分、Co-Authored-By の行、スレッドのやり取りそのものを挙げていました。そのうえで「トークン消費量や所要時間のような内部の数値は取れないので、そこは推定と明記する形になる」と先に断っていました。何ができるかだけでなく、どこまでしか測れないかを最初に言われたので、この記事の範囲もそこで決まりました。
もう一つは、依頼が曖昧だったときの振る舞いです。「書いてみたいな」という依頼には、どういう切り口で書くかが含まれていません。スレッドはそこで止まらず、「初日の実録」「数日使ってから」「機能解説中心」の三択をカードで出し、推奨の「初日の実録」で作業を続けました。返事を待つあいだも下書きは進んでいて、選び直せば後から方針を変えられる、という進め方です。
実測2 スレッドの中で起きたこと
スレッドの作業記録から、外から見えにくい部分を拾います。
まず、プロジェクトに登録していた3つのリポジトリ（このブログ本体、Claude Code のスキル配布用、チェンジログサイト）は、スレッドのコンテナにすべて複製されていました。3つとも同じ作業ブランチ名が割り当てられていて、スレッド1本が複数リポジトリをまたいで1つの単位として動く作りです。
次に、各リポジトリの CLAUDE.md がスレッドの指示として読み込まれていました。このブログのリポジトリには、記事を書くときの手順と公開前のチェックを文章にまとめたスキルを置いてあります。スレッドは書き始める前にそれを読み、その手順に沿って作業を進めました。Projects 専用の設定を足したわけではなく、普段の Claude Code 向けに書いておいたルールがそのまま効いた、というのが実際のところです。
最後に、リポジトリを足すと何が数秒で測れるかの例です。スレッドの中で3リポジトリの履歴を数えると、次のようになりました。
| リポジトリ | 最初のコミット | 総コミット | Co-Authored-By: Claude を含むコミット | 割合 |
|---|---|---|---|---|
| ブログ本体 | 2025-02-11 | 732 | 246 | 34% |
| スキル配布用 | 2025-12-06 | 952 | 551 | 58% |
| チェンジログサイト | 2026-06-06 | 155 | 34 | 22% |
この数字は Claude が関わった変更の下限です。Co-Authored-By の行を付けない運用だった時期や、手で直したコミットは数えていません。それでも、3つのリポジトリを横断した集計を、ローカルにクローンし直すことなく1つのスレッドで出せるのは、リポジトリを Project に足しておく利点だと感じました。
割合そのものは、ふだんの使い方からすると「まあそんなもの」という感覚で、意外さはありませんでした。
実測3 クラウドのスレッドから手元の Mac に作業を渡す
途中で、記事のトップ画像を作る段になりました。このブログの画像は、手元のマシンにログインしてある Codex CLI の画像生成で作る決まりにしています。スレッドはクラウドで動いているので、そのままでは手が届きません。
そこで、スレッドに「手元の Mac か Windows を操作して、Codex CLI から生成して」と頼みました。スレッドは画像のプロンプトをリポジトリに書いて push し、Mac 上で Claude Code のセッションを1本起動する許可を求めてきました。Remote Control という仕組みで、許可するとそのフォルダで Claude Code が動き、結果はスレッドに戻ってきます。
| 時刻（UTC） | 出来事 | 直前からの経過 |
|---|---|---|
| 12:48:53 | 「手元の機体で Codex CLI から画像を生成して」と頼む | — |
| 12:50:14 | スレッドが Mac での作業の許可を求めるカードを出す | 1分21秒 |
| 12:50:31 | 許可する | 17秒 |
| 12:50:37 | Mac 上のセッションがスレッドにつながる | 6秒 |
Mac 側のセッションは、ブログの画像生成スクリプトから Codex CLI（0.162.1）を呼び、1回目で使える画像を作りました。生成にかかったのは壁時計で125秒、Codex が使ったトークンは34,372です。そのまま画像を記事に配置して PR のブランチに push し、クラウドのスレッドがそれを取り込んで続きを書いています。この記事のトップ画像が、そのときの成果物です。
画像の依頼からコミットまで7分51秒、生成そのものは2分5秒
2026-10-13 12:48:53（UTC）の依頼を0秒とした経過
Codex 本体の処理は124.8秒で、PNG を WebP に変換すると約2MBが約170KBになりました。
公式の説明では、スレッドそのものは今のところクラウドでしか動きません1。今回もスレッドはクラウドに残ったままで、手元でしかできない一工程だけを Mac のセッションに渡しています。それでも使う側から見ると、同じスレッドの中でクラウドの作業と手元の作業を行き来しているように感じられました。今日いちばん良かったのは、この継ぎ目のなさです。
測れないものと、まだ試していないもの
公平のために、初日の記録で分からなかったことも書いておきます。
- トークン消費量とコスト。公式には Project ごとの利用量が表示されるとありますが1、スレッドの中からその値は読めません。この記事のどの工程が高くついたかは、推定もしていません
- 並列の効き目。今回動いたスレッドはこの1本だけで、コーディネーターが仕事を複数のスレッドに分けて同時に走らせる場面はまだ見ていません。スレッドどうしの衝突がマージコンフリクトとして出てくる挙動も未確認です
- 共有メモリの効き目。プロジェクトが初日なので、前のスレッドの学びが次のスレッドに引き継がれるかどうかは、これから分かることです
使ってみて分かった向き不向き
一つ目は、リポジトリにルールを書き込んである作業ほど Projects に向いている、という見立てです。今回スレッドが迷わず動けたのは、記事の置き場も公開前のチェックも、すでにリポジトリの中に文章として書いてあったからでした。逆に、ルールが頭の中にしかない作業は、スレッドが毎回推測で埋めることになるはずです。実感としてはそう思っていますが、裏づけになる比較はまだ持っていません。
もう一つは、チャットで投げた一言がそのまま作業単位になる手軽さです。依頼を書いて8秒後にはスレッドが立ち、以後はスレッドの進捗チェックリストを見に行けば足ります。複数の依頼を投げっぱなしにできるかどうかは、スレッドが複数走ったときにあらためて測ります。
これまでは、ローカルの Claude Code と Web のセッションを使い分け、どちらからも見える共通のタスク管理として GitHub の Issue を使っていました。Projects では、依頼を書いたチャットとスレッドが、そのまま作業の記録として残ります。Issue の役割をどこまで置き換えられるかは、まだ分かりません。
初日に分かったことと、次に測ること
新しい Projects は、コーディネーターがチャットで依頼を受け、ブランチを持ったスレッドに配る、という分業でできています。初日の記録では、受け付けは数秒で、スレッドはリポジトリに置いた既存のルールを読んでそれに従いました。手元の Mac でしかできない画像生成も、同じスレッドから渡して戻してもらえました。測れたのは時刻とリポジトリの履歴、手元のコマンドの出力までで、トークンやコスト、並列の効き目はまだ分かっていません。
この記事の下書き自体が、その過程の成果物です。並列で複数のスレッドを走らせたときの記録が取れたら、続きとして書くつもりです。
参考文献
Footnotes
Projects redesigned: from folder to conversation - Anthropic による新しい Projects の発表（2026年9月17日）。構造、共有メモリ、提供範囲 ↩ ↩2 ↩3 ↩4 ↩5 ↩6
Claude Code Projects: parallel sessions - ベータ公開を報じた記事（2026年9月18日）。スレッドごとの利用枠消費とローカル実行の予定 ↩ ↩2