AI NEWS

AIニュース

2026.09.21

黒山結音

【2026年9月最新】Claudeの新Projectsとは？AIが仕事の分担・進捗管理まで担う新機能を解説

Claudeの新Projects。仕事の分担・管理もAIへ。一部ユーザー向けベータ版

AIに仕事を頼んだはずなのに、気づけば自分が複数のチャットを行き来している。「調査は終わった？」「この結果を別のチャットへ渡さないと」「結局、どれが最新版？」。そんな経験はありませんか。

Claudeの新しいProjectsは、このAIへの仕事の割り振りと、成果をまとめる手間に踏み込むアップデートです。ひとつの会話で目標を伝えると、Claudeが複数の作業を分担し、進み具合を追いながら結果を取りまとめる仕組みが加わりました。公式発表

たとえば、自社サイトの問い合わせ導線を見直すとき。「画面を直す」「動作を確かめる」「変更内容を説明する」という仕事を、ひとつの目的のもとで進める使い方が考えられます。プログラムを書かない方にとっても、AIにどんな単位で仕事を任せればよいかを考えるうえで注目したい変化です。

今回扱うのは、2026年9月17日に発表された、Claude Codeから始まる新しいProjectsのベータ版です。2026年9月21日の確認時点では一部のPro・Max利用者への段階提供で、すべてのアカウントで使える機能ではありません。公式ヘルプ

この記事は公式発表・技術資料・公式SNSの案内に基づきます。掲載画面は公式紹介資料で、当社による実機操作・実行テストは行っていません。活用例や依頼文は、仕事への取り入れ方の提案です。

1. 新しいProjectsで、何が変わった？

今回の中心は、Claudeが継続的な仕事の「まとめ役」を担い、その下で個別の作業が進む構造です。

Claudeの公式Xは、今回の更新を次のように紹介しています。

“Projects now run from one conversation, starting in Claude Code.”

ひとつの会話からプロジェクトを動かす体験を、まずClaude Codeで提供するという説明です。Claude公式Xの発表

理解のために、仕事を頼む場面へ置き換えてみましょう。あなたが「問い合わせフォームを使いやすくしたい」と伝え、まとめ役のClaudeが必要な作業を整理し、それぞれの担当へ渡します。あなたは全体の会話で優先順位や目的を伝え、細かな確認が必要なときに個々の作業へ入る、という関わり方です。

画面や公式説明に出てくる言葉は、次のように捉えると読みやすくなります。

用語	この記事での捉え方
Project（プロジェクト）	続けて取り組む仕事のまとまり。「自社サイト改善」など
Thread（スレッド）	個別の仕事を進める作業単位。「フォームの修正」など
Repo（リポジトリ）	プログラムや設定ファイルをまとめて管理する場所
Branch（ブランチ）	元のプログラムと分けて変更を進めるための作業先
PR（プルリクエスト）	変更点を確認して、元のプログラムへ取り込むための提案

仕事を切り出す段取りもClaudeへ相談できます。その際は「サイトをよくして」より、「初めて訪れた人が、相談内容を迷わず送れる状態にしたい」と目的を伝えると、確認すべき結果を定めやすくなります。

2. 以前のProjectsやSubagentsとは何が違う？

同じProjectsという名前でも、従来の資料整理と、今回の仕事を調整する体験は分けて理解する必要があります。

従来のProjectsでは、関連する会話や資料、共通の指示をまとめて扱います。また、以前からプロジェクトに関わるmemoryの説明もあり、「今回、初めて何かを覚えられるようになった」という更新ではありません。従来Projectsの管理方法、Claudeのmemoryの説明

違いを大づかみに整理すると、次のようになります。

仕組み	主に整理・調整するもの	使い分けのイメージ
従来のProjects	関連する会話、資料、共通の指示	同じテーマについて相談を重ねる
Subagents	ひとつのセッション内で任せる補助作業	調査などの一部分を別の担当へ渡し、結果を受け取る
新しいProjects	継続的な目標と、複数のクラウド作業	個別作業の進行と結果を、全体の会話で追う

Subagentsは、別の文脈で部分的な仕事を進め、呼び出した側へ結果を返す仕組みです。新しいProjectsは、続いていく目標に対して複数の作業を開始・追跡する位置づけで、単純な名称変更ではありません。並列実行の方式を比較した公式資料

たとえば、「この資料の要点を教えて」という単発の相談なら、普通のチャットで十分な場合があります。一方、「問い合わせ対応を見直し、FAQ案を作り、社内確認を経て改訂する」といった複数段階の仕事では、目標と途中の判断をひとつの場所に置く意味が大きくなります。

3. 誰が使える？まず提供条件を確認しよう

試す前に確かめたいのは、契約プランと、今回のベータ版が自分のアカウントへ提供されているかです。

公式ヘルプでは、CodeのサイドバーにProjectsが現れることが、新しい体験を使える目印とされています。既存のchat・CoworkのProjectsは引き続き利用でき、今回の更新で一斉に置き換わるわけではありません。公式ヘルプ

確認すること	2026年9月21日時点の案内
対象プラン	Pro・Maxの一部アカウントから段階提供
Team・Enterprise	今回の新しいProjectsベータは未提供
主な入口	WebのClaude Code、デスクトップアプリのCodeタブ、iOS・Androidアプリ
無料プラン	既存Projectsの案内と、新ベータの提供条件を分けて確認する
まだ表示されない場合	公式案内のwaitlistを確認する

提供先・入口は新Projectsの公式仕様、段階展開とwaitlistは公式ヘルプで案内されています。

初期対象は、クラウドセッションの利用歴があり、Web・デスクトップで既存のProjectsを持っていない一部のPro・Max利用者です。ただし、今あるProjectsを削除すれば新機能を使える、という保証はありません。利用中の資料や会話を消すことを、試すための手順にはしないでください。公式発表

業務で使っている契約がTeamやEnterpriseなら、この機能だけを理由に個人アカウントへ社内データを移すのは避けたいところです。先に利用できる人が架空の題材で試し、操作感や必要な準備を共有する方法なら、導入の検討を進めやすくなります。

4. 仕事の分担と「人の確認待ち」はどう見える？

全体の方針はメインの会話で伝え、個別作業の詳しい確認は各スレッドで行う、という二段構えで考えると扱いやすくなります。

公式の紹介画面には、Claudeが取りかかれる仕事を提案するカードが並んでいます。最初の目標や資料から、次の作業を相談する入口です。

Claudeが着手できる仕事を提案する公式紹介画面。出典：Claude公式ブログ。2026年9月21日確認。当社の操作画面ではありません。

コードを扱う場合、各スレッドは独立したクラウドセッションと作業用ブランチで動きます。ただし、同じコードを別々に変更すれば、取り込む際に競合が起こることがあります。作業場所が分かれていても、変更内容の整合性まで自動的に保証されるわけではありません。公式発表

たとえば、フォームの見た目を変える作業と、入力項目を変える作業が同じファイルに触れるなら、分担の境界が曖昧です。その場合は「入力項目を先に確定し、それを前提に見た目を整える」など、順序を決めるほうがよいこともあります。

公式デモでは、人の対応を待っている作業や、レビューできる状態の作業も示されています。

公式デモ動画の一場面。「Waiting on you」は利用者の対応待ち、「Ready for review」は確認できる状態を示す表示です。出典：Claude公式Xのデモ。2026年9月21日取得。当社の実行結果ではありません。

この画面から考えたいのは、人がいつ戻ってくるかです。「完成したら知らせて」だけで始めると、途中の判断が止まっていても気づきにくくなります。担当者を決め、確認時に何を見るかを先に書いておくと、待機中の仕事を再開しやすくなります。

5. Memory・Instructions・Libraryは、役割を分けて使う

資料、継続して守るルール、途中で決まったことを分けておくと、後から作業を再開しやすくなります。

新しいProjectsには、スレッド間で使う共有memoryと、追加したファイルや生成物をまとめるLibraryがあります。Project instructionsとして、継続的な指示を設定する仕組みも用意されています。公式発表、新Projectsの公式仕様

実務では、次のような入れ分けをおすすめします。以下は機能の内部実装を説明する表ではなく、情報を整理するための運用例です。

置き場所	入れる内容の例	人が確かめること
Instructions（継続的な指示）	公開前に担当者の確認を受ける、未確認の数字を作らない	今回だけの事情を、恒久ルールとして残していないか
Memory（記憶）	採用した方針、見送った案と理由、次回も必要な判断	古い決定と新しい決定が混ざっていないか
Library（資料・成果物）	入力資料、FAQ案、検証結果、完成した説明文	正本の資料と作業途中のファイルを見分けられるか

たとえば、問い合わせ対応の整備なら、「営業時間は承認済みの会社案内に従う」は継続ルールになります。「今回は営業時間の見直しを対象にしない」は、この仕事で決めた範囲です。営業時間そのものが書かれた会社案内は、根拠となる資料として扱います。

区切りごとに「決定事項と保留事項を分けてまとめて」と頼み、人が確認すると、方針が変わったときに見直す場所も分かりやすくなります。

なお、memoryを、会話の完全保存や、モデルそのものの再学習と同じ意味で捉えるのは適切ではありません。大切な判断は、参照できる資料と一緒に確認する前提で使いましょう。Claudeのmemoryに関する公式説明

6. PCを閉じても動く。ただし、実行場所はクラウド

手元のパソコンから離れても進む仕組みと、手元の環境をそのまま使えることは、別々に確認する必要があります。

Claude Codeのクラウドセッションは、パソコンを閉じたあとも継続できます。今回の新Projectsのスレッドもクラウド実行で、ローカルのセッションを組み込む機能は現時点で未対応です。Claude Code on the web、新Projectsの公式仕様

たとえば、自宅のパソコンにしかないExcelファイルを使ってほしいなら、クラウド側から読める状態を整える必要があります。社内ネットワークからしか入れないシステムも、利用条件や接続方法の確認が先です。

公式資料でも、クラウドは新しい環境として起動し、ローカルの設定やツールをすべて自動で引き継ぐものではないと説明されています。コード、接続先、実行に必要な設定がどこにあるかを切り分けましょう。クラウド環境の公式資料

準備するときは、「AIが賢いか」だけを見ず、次の三点を書き出すと判断しやすくなります。

材料：使ってよい資料は何か。最新版はどこか。
実行場所：クラウドからその資料やシステムへアクセスできるか。
止める条件：情報不足、アクセス不可、想定外の変更が起きたら、誰へ何を報告するか。

最初の題材は、入力資料がそろい、成果物を人が読み比べられる仕事が向いています。接続の問題と文章の品質の問題を一度に解こうとせず、まずはファイルだけで完結する小さな作業から始めると、つまずいた原因を見つけやすくなります。

7. 最初のプロジェクトは「小さな完成形」から始めよう

新機能を試すときは、仕事の大きさよりも、何ができれば終わりかを明確にすることが大切です。

提供対象のアカウントでは、WebのClaude CodeまたはデスクトップのCodeタブで、サイドバーの「Projects」から「New project」を選びます。「Name」は名前、「Goal」は目標、「Context」は使う資料などの情報です。名前は必須で、目標と文脈は任意ですが、任せる仕事を具体化するために記入しておくとよいでしょう。作成方法の公式資料

リポジトリを付けずに、文書やファイルを扱うプロジェクトも作れます。なお、作成直後にClaudeが自動で動いて利用枠を使う場合があるため、試しに作る段階でも対象範囲は絞っておきましょう。新Projectsの公式仕様

実務での準備は、次の順序で進めると整理しやすくなります。

ひとつの仕事を選ぶ：「営業業務を改善」では広いため、「初回面談の準備資料を整える」などに絞る。
完成形を書く：「資料ができた」ではなく、必要な項目と確認者を決める。
材料をそろえる：使う資料と、情報がないときの扱いを伝える。
作業案を確認する：どこを並行して進め、何を先に決めるかを見る。
ひと区切りで振り返る：出力の多さより、人が直した内容と次回に残すルールを確認する。

依頼文①：着手前に、仕事の分け方を相談する

いきなり全作業を始めるより、最初の計画を短く確認したい場合の依頼文です。

このプロジェクトの目的は、初めて問い合わせる人が迷わず使えるFAQ案を作ることです。

材料は、添付した架空の問い合わせ記録とサービス説明です。
まず、必要な作業、作業同士の前後関係、確認が必要な点を提案してください。
まだ本文の作成は始めず、私が作業案を確認してから進めてください。

完成条件は、質問、回答案、根拠に使った資料、未確認事項が対応していることです。
資料にない料金・契約条件・効果は補わないでください。

接続先の権限や利用設定も、任せる範囲に合わせて確認してください。自然文での指示は、権限制御の代わりにはなりません。

8. 仕事でどう使う？具体例と、そのまま使える依頼文

ここでは、コードを扱う仕事と文章を扱う仕事の二つで、任せ方を具体化します。いずれも説明用の想定例であり、当社の導入実績や実機で成功を確認した事例ではありません。

例①：自社サイトの問い合わせ導線を改善する

「ボタンを目立たせたい」という要望の背景には、訪問者が問い合わせ場所を見つけにくい、入力項目の意味が分からない、といった問題があるかもしれません。最初に目的を決め、変更案・実装・検証をつなぐと、見た目だけを変えて終わることを防ぎやすくなります。

この例なら、画面を直す作業、入力内容を確認する作業、変更内容を説明する作業に分けられます。ただし、実装が終わらなければ確かめられない項目は後に回すなど、前後関係も必要です。

今回の新Projectsでリポジトリを扱う場合は、対象への書き込み権限と、Claude GitHub Appのインストールが必要です。PRが作られたら、変更箇所と実行されたテストを確認する工程を設けましょう。クラウドでコードを扱う公式案内

依頼文②：実装と確認を、ひとつの目標にまとめる

目的は、サイトを初めて訪れた人が問い合わせ先を見つけ、必要事項を迷わず入力できる状態にすることです。

対象は接続済みリポジトリの問い合わせページです。
まず現在の導線と入力項目を確認し、変更案を出してください。
案の確認後、実装、必要な動作確認、変更点の説明を適切に分担してください。
同じファイルを変更する作業は、重複と前後関係を整理してください。

料金表示、送信先、外部サービスとの契約は変更しないでください。
本番公開やPRの取り込みは行わず、確認できる状態で止めてください。
最終報告には、変更理由、確認した操作、未検証の操作、残る判断事項を含めてください。

人が見るべきなのは、作業完了の表示に加えて、実際の使い勝手です。入力ミス時の案内が分かるか、スマートフォンで読みやすいか、送信先が正しいかなど、業務の目的に照らして確かめます。

また、フォームを変更しただけで、問い合わせ数が増えたとは判断できません。改善効果を知りたいなら、公開前後の条件や観測期間をそろえて別途測定する必要があります。

例②：問い合わせ記録からFAQと社内マニュアルを作る

プログラムの変更が目的でなくても、同じ資料から複数の成果物を整える仕事は、分担を考えやすい題材です。顧客向けFAQと社内向けマニュアルでは、使う言葉も、必要な詳しさも違います。

たとえば、架空の問い合わせ記録を使い、「質問の分類」「顧客向け回答案」「担当者が確認すべき事項」を別々に整理します。その後、同じ質問への説明が食い違っていないかを横断して確認すると、単に文書を増やす作業から一歩進められます。

依頼文③：同じ材料から、読者の違う文書を整える

添付した架空の問い合わせ記録とサービス説明を使い、FAQ案と社内対応メモを作成してください。

まず質問を分類し、その分類に沿って次の成果物を作ってください。
・顧客向け：短く分かりやすいFAQ案
・社内向け：回答時に確認すべき資料と、判断が必要な条件

仕事を分担する場合は、共通の質問番号を付けて照合できるようにしてください。
不明な条件は推測で埋めず、「担当者確認」として残してください。
最後に、FAQと社内メモで矛盾している箇所がないか確認してください。
公開・外部送信は行わず、確認用の下書きとしてまとめてください。

「文章を二つ作って」だけで頼む場合に比べて、共通の質問番号を指定すると人が照合しやすくなります。AIがどう分担するかと同時に、人がどう確認するかも設計しておくことがポイントです。

依頼文④：レビューを「よさそう」で終わらせない

成果物がそろったあとに、根拠と未確認事項を確認するための依頼文です。

完成した成果物を、最初に決めた完成条件に照らして見直してください。

項目ごとに「満たした」「未達」「確認できない」を分け、根拠となる箇所を示してください。
実行していないテストや、参照できなかった資料を、確認済みとして扱わないでください。
修正が必要な点は、利用者への影響が大きい順に整理してください。
最後に、私が確認・判断する項目だけを短くまとめてください。

この再確認もAIの評価なので、それ自体が正しさの保証にはなりません。自分が読む場所を絞るための補助として使い、重要な判断は元資料や実際の操作結果に戻って確かめます。

9. 並列で動かす前に、利用量と仕事の相性を見よう

同時に進む作業が増えるほど、何を任せるかを絞ることが大切になります。

新Projectsの各スレッドは、それぞれClaude Codeのセッションとして動くため、利用枠を早く消費する場合があります。プロジェクトごとの使用状況や、使うモデル・思考量の設定も確認しましょう。公式発表

また、「同時実行は二つまで」と文章で頼むことは、システムが強制する上限設定とは異なります。自然文の指示を、確実な費用制限として扱わないでください。新Projectsの利用量・実行調整の説明

利用枠の上限で止まったスレッドが、枠のリセット後に再開する場合もあります。試用を終えるときは、一時停止などを使い、継続させる作業を確認しましょう。利用枠と停止・再開の公式説明

最初の使いどころを選ぶために、次の観点が役立ちます。

仕事の状態	新Projectsを試す判断
共通の目標があり、独立して進められる作業がある	分担と取りまとめを試しやすい
同じ資料から、用途の違う成果物を作る	共通の基準を決めると比較・確認しやすい
一文の言い換えや、短い単発の質問	通常のチャットで足りることが多い
前の判断が終わるまで次に進めない	並列化より、順番と確認者を明確にする
資料不足や権限不足が残っている	実行を増やす前に、材料と利用条件を整える

試用時に残したい記録は、作業数だけではありません。人が準備に使った時間、途中で判断した内容、やり直した理由、最終確認の負担を残すと、自社の仕事に合うかを具体的に振り返れます。

10. よくある疑問

最後に、使い始める前に迷いやすい点を、今回のベータ版に対象を絞って整理します。

無料のProjectsと同じものですか？

同じ名前でも、従来のProjectsと今回の新ベータでは案内が異なります。公式ヘルプにある既存版の無料枠や共有機能の説明を、そのまま新ベータへ当てはめないようにしましょう。公式ヘルプ

チームのメンバーと同じプロジェクトを共有できますか？

今回の新ベータは個人所有で、プロジェクトやスレッドを他の利用者へ共有する機能は未対応です。組織で使う際は、成果物を誰が受け取り、確認するかも別途決める必要があります。新Projectsの制限事項

スマートフォンからでも使えますか？

公式にはiOS・Androidアプリも入口として案内されています。ただし、細かな変更点や長い資料のレビューまで小さな画面だけで済ませるかは、仕事に応じて判断しましょう。提供されるかどうかはアカウントの対象条件も確認してください。新Projectsの公式仕様

以前のProjectsにある「RAG」と同じ進化ですか？

RAGは、大量の資料から必要な情報を探して利用するための仕組みです。従来Projectsの資料活用に関する説明であり、今回の「Claudeが複数作業を調整する」という更新とは分けて理解します。ProjectsのRAGに関する公式説明

Claudeがレビューまで行うなら、人の確認は不要ですか？

業務上の判断や公開の責任まで移るわけではありません。特に料金、契約条件、顧客向けの回答、本番環境への変更は、承認済みの資料や実際の動作と照らして確認する運用をおすすめします。

11. まとめ：次に任せるのは、ひとつの仕事と、その完成条件

新しいProjectsを試すなら、普段の仕事から「目的はひとつ、作業は複数」という題材を選んでみてください。

何を分担し、どの資料を使い、何ができれば完了か。現場の人が知っている判断基準を伝えることが、任せ方の出発点です。試した仕事で迷った点も言葉にして残せば、次の依頼や確認の質を上げる材料になります。

Claudeの使い方を基礎から学びたい方は、Claude Academyの学習ガイドもご覧ください。

あなたのAI顧問株式会社の「あなたのAI顧問」は、AI・DX領域のBPO × AI教育を通じて、業務改善の実装と現場の自走を支援するサービスです。業務棚卸しから優先順位付け、契約範囲内の実装、現場教育・移管までをつなぎ、自社で改善を続けられる状態を目指します。

「自社なら、どの仕事からAIへ任せるべきか」を整理したい方は、自社業務の棚卸しについてご相談ください。

主な公式出典

機能・提供条件は更新される可能性があります。この記事の確認日は2026年9月21日です。

WRITERライター紹介

黒山結音

あなたのAI顧問株式会社　代表取締役

「AIは現場で使えなきゃ意味がない」を掲げ、30社以上にAI顧問として導入から定着までサポート。OpenClaw・Claude・ChatGPTなどAIツールを実務でフル活用し、AI駆動経営を実践。本メディアでは、実際の現場で効果が出た事例や、AI初心者がつまずく「最初の一歩」を、専門用語を極力使わずに解説します。

OpenClaw / Claude Code / Codex / Cursor / Manus