Anthropicは9月16日、Claude DocsとClaude Slidesを発表すると同時に、チャットとCoworkを一つのClaude体験へ統合し始めた。両製品ではアシスタントとの会話の中で文書やプレゼンテーションを作れる。まずProとMaxの契約者へ数週間かけて統一機能を提供する。今回の発表は、すでにすべてのアカウントが変更済みだという意味ではない。Anthropicの発表。

報告書を準備するチームにとって、提案されている変化は実務的だ。文書を作った会話と同じ場所に文書を保管できる。アシスタントと別のエディターの間で下書きを移す作業が減るかもしれない。全体の時間を節約できるかは、出力に必要なレビューの量と、既存の承認手順にどれほど合うかによる。

何が利用でき、誰が使えるか

Claude DocsはClaudeアカウントに保存されるリッチテキスト文書である。他の人と編集でき、変更を加えた人やClaudeの名前が記録される。所有者が共有設定に応じて閲覧・編集者を決める。Anthropicによれば、Claudeが文書を操作するのは、サインイン中の人が依頼した場合であり、その人の権限の範囲内に限られる。Claude Docsの文書。

DocsはPro、Max、Team、Enterpriseプランでベータ提供されるが、Enterpriseでは管理者が有効化する必要がある。同じ文書には、顧客管理暗号化キー、データ保持ゼロ、HIPAA対応構成を使う組織は対象外と記される。展開を計画する前に管理者が利用資格を確認すべき理由となる制約だ。

チャットとCoworkの統合には別の提供計画がある。Anthropicによれば、TeamとFreeプランは初期のPro・Max版の後に続き、Enterprise管理者には組織の変更前に少なくとも30日前の通知が届く。Docsが使えることを、企業が新しい体験全体を受け取った証拠と見なしてはならない。提供計画の詳細。

共有ワークスペースはレビューの場所を変える

説明のため、営業提案書を考えてみよう。管理者が承認済みの商品情報を提供し、ライターが提案を下書きし、同僚が約束事項を確認する。アシスタントが共有文書内で作業すれば、レビュアーはテキストを何度もチャットへコピーせずに結果を確認できる。発表されたワークフローで可能な使い方の例であり、BIG CHANGEが実験したものではない。

滑らかな下書きによって、未承認の主張が確定事項のように見える危険がある。このツールを試すチームは、価格、期限、約束を一つずつ情報源までたどれるよう、レビュアーに確認を求めるべきだ。編集権限で分かるのは誰が文書を変更できるかであり、顧客に納期を約束する権限が誰にあるかではない。チームの手順内で責任者を明示する必要がある。

Conceptual workflow from checked source documents to a shared draft with comments, followed by one human hand verifying the draft against another page.
Approved inputs, collaborative drafting and human verification: an illustrative review process, not a tested product workflow. AI-generated illustration · BIG CHANGE.

運用上の制限もある。Anthropicのヘルプページによれば、予定されたタスクはクラウドで実行できる一方、ローカルフォルダー、内蔵ブラウザー、コンピューター操作の機能にはClaude Desktopを起動したままにする必要がある。長い作業は短い質問よりプランの利用枠を多く消費する。閉じたノートPC内のファイルに依存する報告書が無人で完成すると想定すべきではない。Claude統合機能と制限。

ソフトウェア開発にも同じ変化が届く

Docs発表の翌日、Anthropicは選定されたClaude Codeユーザー向けにProjectsの再設計版をベータ公開した。調整役の会話から課題をクラウドセッションに分割し、結果を集められる。各スレッドには独自のブランチとリポジトリコピーがあるが、編集が重なればマージ競合はなお発生し得る。初期提供の対象は限定されている。9月17日のProjects発表。

これらの発表を合わせると、業務ソフトの方向性が見える。アシスタントは、成果物を取り巻く作業をより多く整理するようになる。これは製品変化に対する私たちの解釈であり、企業がすでに文書作成スイートや開発チームを置き換えた証拠ではない。公開発表は、いずれのリリースについても独立に検証された生産性向上を示していない。

適切な試験導入では、担当者が明確な定期社内報告書を一つ扱う。元の入力を保存し、作業全体にかかった時間を記録し、レビュー後の修正件数を数える。完成して承認された出力を既存の手順と比べる。最初の下書きが速くできても、確認と修正を経た後に時間が節約されなければ有用性は限定される。

試験には、プロンプトを書かなかった人への引き継ぎも含めるべきだ。その人は正式なファイルを特定し、未解決のコメントを確認し、必要な形式で結果を出力できるか。最初のデモの後もチーム全員が業務を維持できるかが、重要な導入判断となる。

BIG CHANGEは発表と文書を確認したが、新機能の実地試験は行っていない。運用文書をベータに移す前に、購入者は自分のアカウントでの提供状況と必要なセキュリティ設定を確認すべきだ。