モード

モードとは

モードはスペースのプロパティであり、スペース行の 1 つのカラムとして保存されます。スペース内のすべての会話がこれを共有し、スレッドも同じです。スレッドはほかの会話と同様に、そのスペースのモードを継承します。したがって同じエージェントが、同時に異なるスペースで異なるモードになることができ、スペースのモードを切り替えると、エージェントに触れることなく次のターンから動作が変わります。

モードはちょうど 4 つあります: chat、review、plan、orchestrate です。enum 自体はポリシーを持ちません。モードが保証するすべては、ケイパビリティプロファイルで一度だけ宣言され、すべての強制レイヤーがそこから投影します:

ツールサーフェス — そのモードでそもそもどのツールが存在するか。最大承認ティア、許可リスト、拒否リスト、拒否されるエフェクトクラスの集合として表現されます。
必須の出力動詞 — 何かを届けたことになるために、実行が呼び出さなければならないもの。
拒否されるエフェクトクラス — アクションガードが即座に拒否するもの。
ワークツリーの態勢 — ワークツリーへの書き込みが許されるかどうか。これは、変更を加えるツールをサーフェスから取り除くことで強制され、そのおかげでどのホストでも守られます。ホストに OS サンドボックスがある場合、同じ態勢がファイルシステムの書き込みルールも定めます（読み取り専用モードはワークツリーを読み取り専用でマウントします）が、それは保証の 2 つ目のコピーであり、実際に効いているものではありません。
システムプロンプトブロック — 実際にマテリアライズされたツール一覧から導出される_生成された_ケイパビリティの前書きと、手書きのガイダンス。

すべての強制レイヤーがその 1 つのプロファイルから投影するため、ツールサーフェス、ガード、ワークツリーの態勢、プロンプトが食い違うことはありません。

4 つのモード

チャット — 「Agent」として表示されます

デフォルトであり、追加の制約がない唯一のモードです。実行ティアまでの完全なツールサーフェス、書き込み可能なワークツリー、拒否されるエフェクトクラスなし、完了契約なしです。実装、バグ修正、コードベースに関する質問、その場限りのあらゆる作業に使います。

ラベルに注意してください。コンポーザーではこのモードは「Chat」ではなく **「Agent」**として表示されます。

プラン — 読み取り専用、成果物は 1 つ

プランモードはワークツリーを読み取り専用にし、書き込みツールをサーフェスから完全に取り除きます。そのため制約は指示によるものではなく構造的です。エージェントは読み、検索し、調査して、ちょうど 1 つだけを届けます。型付きの依存関係グラフを運ぶ submit_plan 呼び出しです。グラフは、ゴールと、キー・タイトル・説明を持つノード、および各ノードが依存するノードキーからなります。

プランは会話内にコンパクトな行として表示され、その横のタブで Plan Studio を開きます。これを承認すると、グラフがオーケストレーションにコンパイルされ、生成された作業が実行され、作成元のスペースがエージェントモードに戻ります。

プランモードの実行が submit_plan を一度も呼ばずに終わると、ループはまず、その呼び出しが成功するまでプランは存在しないというナッジを注入します。このナッジは、「ここにプランは不要です」という正直な終了を明示的に許可します。プランモードはスペースの設定であり、その中で尋ねた単なる質問が偽りのプランを強制すべきではないからです。

別のもう 1 つの出口があります: exit_plan_mode です。これは出力動詞ではなく、厳格な承認ゲートです。submit_plan の代わりにこれを呼ぶエージェントは何も届けていません。最初の呼び出しは永続的な plan_exit 承認を開いて pending を返し、スペースは読み取り専用のままです。繰り返しの呼び出しは 2 つ目のゲートを開かず、pending のままです。承認が与えられて初めて、次の呼び出しがスペースをチャットに切り替えます。拒否された場合、エージェントは修正プランの新しいリクエストを開けます。

自分でプランモードを抜けるには、コンポーザーのドロップダウン（または Shift+Tab）を切り替えます。exit_plan_mode の決定は MCP ツール decide_approval で行います。受信トレイの「エージェント承認」の行は別物です。実行中のエージェントからのターンごとの確認プロンプトです。

レビュー — 読み取り専用、契約なし

レビューモードは PR レビュー用です。ワークツリーを読み取り専用にし、ツールサーフェスを実行ティア未満に制限し、レビュー・チケッティング・コミュニケーション用ツールの厳選された許可リストを適用します。プルリクエストのために開かれたスペースは、自動的にレビューモードで作成されます。

エージェントの出力は、構造化された所見、つまりレビューノードであり、レビューが確定したときには判定です。ノードは、種類（bug、suggestion、recommendation、question、または ticket）、P0（リリースをブロック）から P3（あると望ましい）までの優先度、自己評価による確信度、任意のアンカー（ファイルと行範囲。リポジトリ全体のメモには付きません）、そしてライフサイクルステータスを持ちます。ステータスは、作成者ではないピアが確認した時点で open から consensusReady に移ります。優先度または確信度が欠けているか範囲外の所見は、判定を汚す前に読み取り境界で破棄されます。

判定は Ship、Hold、Block のいずれかで、そこに畳み込まれる軸ごとの結果によって_より_厳しくされることしかありません。ゲート対象の軸が失敗すれば block が強制され、ゲート対象の軸が実行できなければ少なくとも hold が強制されます。証拠の不在がゲートをグリーンにすることは決してありません。

プランやオーケストレーションと違い、レビューには完了契約がありません。所見は add_review_node で蓄積され、finalize_review で公開されますが、どちらも正当に一度も呼ばれないことがあります。レビューモードで動くパイプラインエージェントは、代わりにチケットを完了するためにそこにいるのかもしれません。

オーケストレーション — 読み取り専用、チームを提案

オーケストレーションモードは、1 つのゴールをチーム全体のプランに変えます。プランモードと同様に読み取り専用で、ファイルに書き込めません。調査用サーフェスに加えて、propose_orchestration という単一の特権的な動詞を持ち、これが構造化された提案を出力します。役割、サブチケットのツリー、統合ステップ、予算です。プロンプトはサーフェス上のツールだけを列挙するため、モデルは呼び出せない採用やチケット作業を語ることにターンを費やしません。

提案は、あなたが承認するまで何も実行されません。承認すると、決定論的なマテリアライザーがエージェントを採用し、チケットとプロジェクトを作成し、生成されたパイプラインを実行します。承認はオペレーター専用です。そのための MCP ツールは存在しないため、エージェントは提案できても自分のプランを承認することはできません。エージェントが開始した再提案は 2 分間のクールダウンでレート制限されるため、連続する再プランは拒否され、まとめるよう指示されます。詳しくはオーケストレーションを参照してください。

知っておく価値のある 2 つのルール

モード自身の出力動詞が拒否されることは決してありません。 submit_plan と propose_orchestration はツールサーフェスに固定され、ツールフィルター、承認ゲート、アクションガードのいずれも通過済みとして事前承認されます。そのため、スペースごとの自律性ダイヤルがモードの成果物を黙らせることはできません。ハーネスの ask_user も同じ理由で固定されています。これこそが実行がオペレーターに到達する方法であるため、これをゲートすると、何かを尋ねる必要のある実行がデッドロックします。読み取りティアなので、すべての読み取り専用モードがこれを保持し、承認ラッパーからも除外されています。承認者が接続されていない状態でプロンプトの前にプロンプトを置くとフェイルクローズし、エージェントは尋ねるという行為自体を拒否されることになります。

読み取り専用モードはネットワークアクセスやシークレットを拒否しません。 レビュー、プラン、オーケストレーションが拒否するエフェクトクラスは、世界を変えるものです。ファイル削除、ワークツリー外への書き込み、コミット、プッシュ、PR の作成と公開、ベンダー同期の書き込み、パッケージのインストール、プロセスの起動、ワークスペースの変更、エンクロージャー制御です。ネットワークの送信とシークレットへのアクセスは意図的にデフォルトのままです。調査こそが読み取り専用モードの目的そのものだからです。

モードの選択と変更

コンポーザーのモードドロップダウンには 3 つの選択肢があります。Agent（チャット）、Plan、Orchestrate です。review はユーザーが選択できません。PR レビューのスペースが作成されるときにシステムが設定し、パイプラインステップも設定します。

スペースを開くパイプラインノードは、extras['mode'] キー（chat、review、または plan）でそのルームのモードを固定できます。このキーは完全一致です。ほかの綴り（orchestrate を含む）は黙って無視され、ルームにはボディのデフォルト（create-space ボディでは review）が適用されます。エージェントステップは、自分が作成していないルームに参加し、その権限を変更しません。

解決自体は単純です。ディスパッチャーはスペースの mode カラムを読み取ります。スペースのないディスパッチ（ワンショット、CLI 呼び出し、または別のワークスペースのスペース ID。これは単にこのワークスペースのデータベースファイルに存在しないだけです）は chat に解決されます。モードの変更は次のターンから有効になります。

保証が実際に効くのはどこか

モードのツールサーフェスは組み込みハーネスが構築し、強制します。単に拒否するのではなくツールを見えなくすること、実行前にすべての呼び出しをゲートすること、完了契約を観測することができる唯一のトランスポートです。

Claude Code トランスポートでは、チャット以外のモードは --permission-mode plan として渡されます。Claude はそれを慣習として尊重しますが、自身の読み取り・書き込み・編集ツールは見えないところで実行され、シェルコマンドはコマンドラインを読むフックでしか確認されません。そのトランスポートにとってモードはガイダンスであり、Control Center の境界ではありません。詳しくはエージェントモデルを参照してください。

許可リストは書き込みティア以上のツールを制約します。組み込みハーネスの読み取りティアは、どのリストにも載っていないツールにも依然として到達します。Claude Code では、許可リストが省略したツールは、サーバーがそれを持っているかどうかに関係なく拒否されます。