Claude Codeは柔軟性を増していますが、現在できることと、構想として示されている方向は同じではありません。開発者はClaude Modsを使ってコーディングエージェントの作業フローの一部を変更でき、Artifactsは複数のClaudeインスタンスがアクセスするプロジェクトの状態を永続的に保持できます。さらに広い構想では、インターフェース、モデルの推論、コードの実行を切り離し、複数のエージェントがローカルとクラウドにまたがって協働できるようにします。この変化はチームがソフトウェア開発を調整する方法を変える可能性がありますが、それはコードとデータへのアクセスを適切に区切れることが前提です。
開発者がいま変えられること
Claude Codeには、エージェントがコードを書く前に開発者が方向づける手段がすでにあります。Ask User Questionツールを使えば、データスキーマや実装方法の選択といった曖昧な要件を確認できます。CLAUDE.mdファイルには、セッションをまたいで使うプロジェクトの指示を保存できます。ただし、出発点として役立つのは長い制約のリストではありません。古いモデルが繰り返した誤りを正すために書いたルールが、もうその誤りをしない新しいモデルを縛ってしまうことがあるためです。新しいプロジェクトでは空のファイルから始め、同じ失敗が繰り返し起きたときに指示を加えればよいでしょう。
Claude Modsは、こうした制御を書面の指示の外にまで広げます。従来のフックは、イベントが起きたときに外部スクリプトを起動するものでした。これに対してModsはClaude CodeのTypeScriptプロセスの内部で動作するため、拡張機能はエージェントのイベントに反応し、範囲を限ったセッション情報を参照し、構造化された出力を扱い、ターミナル画面の一部を変更できます。拡張の仕組みは、コマンド、プロンプト、エージェント、ツール、出力、設定、構成など、多くのフックポイントに及びます。
たとえば独自のModで、エージェントが変更を実装する間に置いた前提を記録し、最後にまとめて示すことができます。タスクの完了後に理解度チェックを実行するModも考えられます。この仕組みでは、小さな作業を任された別のエージェントの分岐であるサブエージェントが、作業が完了条件を満たしているかを確認し、開発者向けのクイズ問題を返します。これらは開発者が作れる拡張の例であり、すべてのClaude Codeセッションが既定で実行する手順ではありません。
▲ コーディング作業フロー内の別レビュー
分岐したサブエージェントは、親セッションのプロンプトキャッシュ、つまりモデルがすでに読み込んだ入力の処理結果を再利用できます。これにより補助的なチェックのコストを抑えつつ、その評価内容をメインの会話から切り離せます。この分離は、コーディングのやり取りのたびに長い監督的な対話を挟まずにレビューや説明を得たい場合に重要です。とはいえ、自動化を増やせば必ず良くなると考えるのではなく、追加したスキルやModが実際に結果を改善するかを検証するのが妥当です。
ほかにも、専用の作業モードを選ぶセレクターや、Claudeのモデルを選び分けるルーターといったModが考えられます。自動ルーティングが既定になっていないのは、作業を始める前にタスクの難しさを判断することがまだ確実ではないためです。複雑な依頼を処理しきれないモデルに送れば、時間の節約どころか無駄になりかねません。カスタマイズは強力ですが、シンプルな既定の作業フローなら生じない選択肢も生み出します。
ターミナルのセッションから共有ワークスペースへ
現在、開発者はClaude Codeをローカルで実行することも、リモートやクラウドでの実行を選ぶこともできます。Claude TagはSlackのようなチームの共有スペースにエージェントを持ち込み、参加者は共通のプロジェクトの文脈をもとに作業できます。Claude Projectsは個人に焦点を当てた作業から始まり、共有環境へと広がることを想定しています。
Artifactsは、これとは異なる種類の協働の場を提供します。Artifactは一時的な結果を表示するだけでなく、永続的なデータベースに支えられた対話型のインターフェースを提供できます。構造化された情報をClaudeに送り返すこともできます。エージェントを外部のツールやデータにつなぐ仕組みであるMCP（Model Context Protocol）の連携を通じて、別々のClaudeインスタンスが同じArtifactのデータを読み取り、更新できます。セッションをまたいでタスクを保持するプロジェクトボードは、その活用例の一つです。
より野心的な方向性は、その共有インターフェースをプロジェクトの中心に置くことです。専門のエージェントが並行して動く間、人はそこで作業を確認し、コメントを残し、タスクを割り当てられます。提案されているアーキテクチャでは、インターフェースとそのデータは、クラウドで動くモデルの推論とは別に置かれます。実行も別に行われ、作業を担う隔離された環境であるクラウドのサンドボックスか、接続されたローカルマシンのどちらかで動きます。見慣れたターミナルのセッションは、システム全体の入れ物ではなく、作業方法の選択肢の一つになります。
これは設計の方向性であり、すべての要素がすでに一つのシームレスな製品として動いているという意味ではありません。複数のエージェントを調整し、共有のプロジェクト情報を継続的に生成すれば、トークン（モデルが処理するテキストの単位）の使用量と遅延が増えることもあります。人による方向づけも依然として重要です。アーキテクチャやデザイン、タスクに必要なレビューの量について、明示されていない好みをエージェントが確実に推測することはできません。
▲ アクセス境界を分けた共有プロジェクト状態
協働には境界が必要
共有エージェントによって、開発者がプロジェクトの詳細を手作業で伝える必要は減る可能性があります。たとえば専用のチームチャンネルでは、法務やコンプライアンスの担当者が、エージェントが参照できるプロジェクトの文脈を使ってコードの変更について質問できます。障害対応では、複数の対応者が共有のログやランブックをもとに作業できます。どちらの作業フローが適切かは、エージェントに何を見せ、何を許可するかによって決まります。
チームのエージェントには、独自のアイデンティティと明確な権限が必要です。人によっては、同じプロジェクトに異なるMCPサーバー、ドキュメント、ローカルの認証情報を接続することがあります。分離がなければ、ある領域で参照できる情報が別の領域に漏れるおそれがあります。信頼できない内容が共有チャンネルに入ってくることは、プロンプトインジェクションのリスクにもなります。データとして与えられたテキストが、より広い権限を持つエージェントの行動をそらそうとする可能性があるからです。防御の原則は、外部からの入力を特権的なエージェントの操作から切り離し、各エージェントのアクセスをタスクに必要な範囲に限ることです。
実行にも独自の安全策が必要です。サンドボックス、範囲を限った認証情報、承認や監視の層によって、自律的に動くエージェントが変更できる範囲を制限できます。こうした制御は、作業が短時間で人が見守るローカルでの実行から、複数の環境でツールを使う長時間稼働のエージェントへ移るほど重要になります。共有インターフェースだけでは、アイデンティティ、認可、データの可視性の問題は解決しません。
いま取り組むべきこと
当面の機会は、自律的なエージェントチームへの全面的な移行ではなく、選択的なカスタマイズにあります。コーディングのタスクは、目標とアーキテクチャ上の未知の点を明確にするところから始め、CLAUDE.mdのルールは繰り返し起きた問題に結びつけたうえで、モデルを変えた後に見直しましょう。Modでレビューや前提の記録といった補助的な作業を加えるなら、それが作業フローを実際に改善しているかを評価します。
共有プロジェクトでは、ツールやチャンネルを接続する前に、どの人とどのエージェントがどのデータソースにアクセスできるかを整理します。信頼できない入力は特権的な操作から切り離し、コードの実行には範囲を限った権限を使います。Claude Modsと永続的なArtifactsは、開発が柔軟で協働的なワークスペースへ向かう可能性を示しています。その方向性をチームがどこまで責任を持って活用できるかは、権限の設計と、人による意図的な方向づけにかかっています。