「フォルダ」が「コーディネーター」に変わった日
9月17日、AnthropicがClaude Codeの「Projects」機能を全面的に作り直し、ベータ公開した。これまでのProjectsは、いくつかのファイルと一つのチャットを束ねた「フォルダ」のようなものだった。新しいProjectsは、一つの継続的な会話がコーディネーターとして機能し、大きな目標を複数の並列スレッドに分解して実行する仕組みに生まれ変わっている。発表文のタイトルが「フォルダから会話へ」だという点が、この変化の本質を端的に表している。
「コーディネーター」と「ワーカー」という二層構造
技術的な設計として興味深いのが、プロジェクト会話とスレッドという二層のアーキテクチャだ。プロジェクト会話は司令塔の役割を担い、ユーザーの指示を解釈し、簡単な質問にはその場で答えつつ、実作業が必要な部分をスレッドとして立ち上げる。各スレッドは独立したClaude Codeクラウドセッションで、それぞれが専用のブランチとリポジトリのコピーを持つ。スレッドはプルリクエストを開き、テストを実行し、ドキュメントを読み込みながら、コーディネーターに進捗を要約して報告する。コーディネーターはスレッドの全ステップを見ているわけではなく、報告された要約だけを受け取る設計になっている点は、コンテキストの肥大化を防ぐうえで理にかなった判断だ。
実例で見る使い方
発表に添えられた例が分かりやすい。チェックアウト処理のp75レイテンシ(リクエストの75%が応答を得るまでの時間)を下げたい場合、Claudeが各エンドポイントをプロファイリングし、複数の最適化案を並列スレッドで試しながらプルリクエストを開く。あるいは、API・Web・モバイルの複数リポジトリを接続し、「廃止予定のv1エンドポイントを退役させる」という目標を与えれば、Claudeがリポジトリごとにスレッドを作り、呼び出し元の移行、テスト実行、プルリクエストの作成までをこなし、どのプルリクエストから先にマージすべきかまで報告してくれるという。複数リポジトリをまたぐ地味だが手間のかかる移行作業を、まとめて並列化できる点は実務上のインパクトが大きい。
モデルと思考の強さを役割ごとに使い分ける
もう一つ実用的な設計判断が、コーディネーターとワーカースレッドそれぞれに、使用するモデルと思考の強さ(エフォート)を個別に設定できる点だ。状況把握とタスク分解という難易度の高い仕事を担うコーディネーターには最上位モデルと高いエフォートを割り当て、ルーティンなテスト実行や単機能のリファクタリングを担うワーカーには標準モデルと低いエフォートを割り当てる、といった柔軟な資源配分ができる。デフォルトでは各スレッドがOpusを高エフォートで動かす設定になっているとの報道もあり、品質を維持しながらトークン消費を抑えるためのエンジニアリング上の工夫だと言える。
使用量の消費が速くなるという現実的な注意点
見過ごせない実務的な注意点として、並列スレッドはプランの利用上限を通常より速く消費する。1日あたりの新規スレッド数には200件という上限があり、有償の追加クレジットがない場合、プランの上限に達したスレッドはリセットされるまで待機状態になる。ルーティンによって開始されたスレッドは例外で、上限に達するとそのターンでエラー終了し、ユーザーがリセット後に改めてメッセージを送る必要があるという。並列化による生産性向上と引き換えに、利用枠の管理が新たな運用課題として浮上する構図だ。
段階的なロールアウト計画
ベータは現時点で、クラウドセッションを利用しているPro・Maxサブスクライバーの一部に限定されており、チャットやCowork上に既存のプロジェクトを持たないユーザーが対象になっている。今後数週間かけてPro・Maxの対象を広げ、その後Team・EnterprisePlanにも展開していく計画だという。既存のプロジェクトはロールアウトが進むまで従来通り動作し続ける。
エンジニアとして見ておきたいこと
単一のプロンプト応答から、コーディネーターが差配する複数エージェントの協調作業へ——この変化は、AIコーディングツールが「一問一答」から「プロジェクト単位の自律的な進行管理」へと重心を移しつつあることを示している。複数リポジトリをまたぐ移行作業や、パフォーマンスチューニングのような並列探索が有効なタスクにとっては魅力的な選択肢になりそうだ。一方で、利用枠消費の速さや、コーディネーターがスレッドの詳細な過程を把握していないことによる見落としのリスクなど、実運用でどこまで信頼して任せられるかは、ベータの拡大とともに見えてくるだろう。