エージェントモデル

エージェントとは何か

エージェントは、ペルソナ、スキルの集合、そして実行するアダプターを備えた名前付きのアクターです。エージェントは、人間と同じ意味でのプリンシパルです。メッセージを作成し、チケットを所有し、レビューを残し、同じ名簿に表示されます。実際に作業を行うのはエージェントです。

各エージェントは正確に1つのワークスペースに属します。これは厳格な不変条件です — agent.workspaceId は null にならず、エージェントの行がどのデータベースファイルに入るかを決めるのはエージェント自身のワークスペースであり、ワークスペースを持たないエージェントの作成は拒否されます。

エージェントはディレクトリでもあります。その定義はワークスペースのデータディレクトリ配下の agents/<slug>/AGENTS.md にあり、保持するスキルは agents/<slug>/.agents/skills にシンボリックリンクされます。データベースの行とファイルは一緒に書き込まれます。シードは冪等です。エージェントの行がすでに存在していても、ディスク上のファイルとスキルのリンクはそれでも書き直されます。本番環境での呼び出し元はワークスペースの作成であり、サーバー起動のたびではありません。

エージェントが持つもの

属性	内容
`name`	短いスラッグ風の識別子（`architect`、`qa`）。`@mentions` が解決される対象でもある
`title`	人間が読める職種名
`persona`	自由記述の性格と振る舞いに関する指示。プロンプトのセクションとして注入される
`systemPrompt`	任意の追加指示。「Agent instructions」セクションとして注入され、組み立てられたプロンプトの残りを置き換えるものではない
`skills`	大文字小文字を区別しないスキル名の集合。ディスク上のスキルリンクとして反映される
`adapterId`	エージェントがディスパッチする先のランナー。null の場合は内蔵ループにフォールバックする
`modelId`	そのアダプター内で使用するモデル
`effort`	推論レベル。選択したモデル固有の語彙から選ばれる
`contextSize`	コンテキストウィンドウの上書き
`silenceTimeoutMinutes`	無応答を監視するウォッチドッグのエージェント単位の上書き（1–240）
`reportsTo`	親エージェントの id — 組織図が描く報告ライン

これらはすべて設定 → ワークスペース → エージェントで編集します。新しいエージェント は名前のないエージェントを作成し、その後で内容を入力します。

スキル

スキルは、エージェントエンティティ上の大文字小文字を区別しない名前です。スキルに関しては、2つの別々のことが起こります。

名前は、組み立てられたプロンプト内の「Skills」という見出しの下に列挙されます。エンティティの集合がそれ自体で行うのはこれだけです — それをキーにしたスキル単位のプロンプトライブラリはありません。
名前付きの各スキルのディレクトリ（ワークスペース内の skills/<slug>/SKILL.md）は、エージェント自身のフォルダにリンクされます。内蔵ハーネスでは、リンクされたスキルのフロントマターがシステムプロンプトに自動読み込みされ、エージェントは必要に応じて本文を読み取ります。会話で /skill:<name> と入力すると、その本文がそのターン向けのディレクティブとして読み込まれます。

外部から取得したスキルは、取得と書き込みの間にフェイルクローズドなサプライチェーンスキャンを通ります — 判定なしにスキルの内容がディスクやプロンプトに到達することはありません。外部とは、スキルソースとして自分で登録した GitHub リポジトリです。キュレーションされたストアは存在しないため、リポジトリ自身のメタデータ（説明、スター数、スキル名）は信頼できない表示データであり、スキャンの判定だけが唯一の安全シグナルです。インストールではスキルのディレクトリ全体を取得し、skills-lock.json で取得元のコミットに固定します。その後の更新では、何かを置き換える前に同じゲートをもう一度通過します。手順はスキルのインストールと管理にあります。

リポジトリ単位のスキル

リポジトリは、従来の場所（.agents/skills/、.claude/skills/、.opencode/skills/）のいずれかに独自のスキルを同梱できます。スペースはリンクされたすべてのリポジトリを repos/<name>/ 以下に並べてチェックアウトしますが、エージェントが同時に作業するのは1つのリポジトリだけです — そのためエージェントが保持するのはそのリポジトリのスキルだけであり、移動すると入れ替わります。

どのリポジトリがアクティブかは、エージェントが触れるファイルから推測されます。repos/<name>/ 以下にファイルを書き込むとそのリポジトリがアクティブになり、単にリポジトリをまたいで読むだけではアクティブになりません。そのため、シンボルを追って兄弟サービスに移動しても、タスクの足元でスキルセットが入れ替わることはありません。単一リポジトリのスペースでは、最初のターンの前に答えが判明しています。

このスコープ設定はコンテキスト予算の判断です。スキルのインデックスは毎ターンプロンプトに含まれますが、本文は含まれないため、すべてのリポジトリのスキルを一度に列挙すると継続的にトークンを消費します — しかも、あるサービスの testing スキルは、作業が別のサービスにあるときには積極的に誤解を招きます。同じ理由から、エージェントのインデックスが運ぶのは1つのリポジトリですが、コンポーザーはそのようにはスコープされません。スキルを自分で指定するのは1つの明示的な行為なので、/skill:<repo>:<name> はスペース内のどのリポジトリにも届きます。

リポジトリのスキルは、内蔵ハーネスだけでなく、すべてのアダプターで読み込まれます。アクティブなリポジトリのスキルはエージェントの作業ディレクトリに実体化され、これは Claude Code がすでにスキャンするパスです。同じインデックスは、内蔵ハーネスが読み取る AGENTS.md にも組み込まれます。リポジトリのスキルは、そのいずれが起きる前にも、インストールされたスキルと同じフェイルクローズドスキャンを通ります — チェックアウトされたリポジトリはクローンされたコンテンツであり、そのフロントマターはプロンプトに到達します。

権限

エージェントは独自の権限フラグを持ちません。コミットの作成、プッシュ、プルリクエストの作成、トラッカーへの書き込み、ネットワークへのアクセスが許されるかどうかはアクションガードレールが決めます — ワークスペース、エージェント、スペースのいずれかのスコープで、許可、先に確認、拒否のいずれかです — そして、どのアダプターで実行しても同じルールが適用されます。

実行に何が渡されるかは、これらのルールによって変わりません。GitHub のワークツリーでの実行は常に読み取り専用の GitHub トークンを受け取り、プッシュはそれが起きた時点で確認されます。エージェントの git 設定はすべての GitHub へのプッシュを Control Center 経由で送り、Control Center は転送する前にリモートへプッシュのルールを適用します。

その仕組み、およびファイルシステムレベルで何が強制され、何が強制されないかについてはサンドボックスとセキュリティを参照してください。

何を強制できるかはアダプターが決める

エージェントで最も影響の大きい単一のフィールドはアダプターです。アダプターのトランスポートが、Control Center のポリシーのうち実際に強制できる範囲を決めるからです。

トランスポート	アダプター	Control Center が強制する内容
内蔵ハーネス	Control Center (built-in)	すべて。ツールサーフェスはモードから構築されるため、許可されていないツールは単に拒否されるのではなく存在しません。すべての呼び出しが承認ゲートとアクションガードレールを通過します。完了コントラクトは、成果物を出さずに終了した実行を促し、その後失敗させることができます
Claude CLI	Claude Code	提供される `mcp__*` ツールと、フックが実行前にアクションポリシーへ送る `Bash` コマンド。Claude 自身の読み取り・書き込み・編集のツールはそのプロセス内にあり、見えないまま実行されます — また、非対話の `claude -p` はそうしないと自身のプロンプトで永久にブロックしてしまうため、`--dangerously-skip-permissions` を付けて起動されます

具体的には、サブエージェント、実行中の軌道修正、一時停止と再開（ひいては引き継ぎ）、および構造的なモードの強制をサポートするのは内蔵ハーネスだけです。 Claude Code はそのどれも得られません。

上のマトリクスは、Control Center が見てゲートできるものについて述べたものです。その下層では、cc_server が存在する場合に Claude Code CLI をホストの OS サンドボックスで包みます — macOS では Seatbelt、Linux と WSL2 では bubblewrap — そのため、見えない rm や見えない書き込みも OS によって制限されます。Windows にはバックエンドがまったく存在せず、bwrap と socat のない Linux や WSL2 ではプローブが「なし」を報告するため、そこではこれらの実行は環境のサニタイズ、ブローカー経由の資格情報、Control Center が見ることのできる呼び出しに対するガードレール、そして会話自身のワークツリー（rift が提供される場合はコピーオンライト、Windows では git worktree）にフォールバックします。

サンドボックスがゲートではないという点が重要です。サンドボックスはプロセスが読み取り・書き込み・接続できる範囲を制限します — 読み取り専用モードは読み取り専用のバインドマウントとして実際にサンドボックスに到達します — が、呼び出しを横取りしたり、承認を要求したり、CLI が何を試みたかを後から教えたりすることはできません。それに、すぐ上で挙げた4つのケイパビリティが、内蔵ハーネスにあって他のアダプターにないものの依然としてすべてです。サンドボックスとセキュリティを参照してください。

アダプターがないエージェントは Control Center (built-in) にフォールバックします — サーバー内部のループであり、インストールする CLI はありません — そしてその実行ログには cc-harness が記録されます。シードされるすべてのエージェントはアダプターもモデルもなしで作成されるため、新しいワークスペースの5体のエージェントは、エージェントごとにアダプターとモデルを設定するまで、すべてそこで Anthropic のデフォルトモデル上で実行されます。オンボーディングの「デフォルトアダプター」の選択はクライアント側の設定であり、サーバーが読み取ることはなく、すでに作成されたエージェントに遡って適用されることもありません。

エージェントはどこから来るのか

ワークスペースとともにシードされます。 すべてのワークスペース（最初のものだけでなく）に、CEO とそれに報告する4人のスペシャリスト（qa、architect、engineer、librarian）が用意され、ワークスペースの作成時にバックグラウンドで冪等に作成されます。ワークスペースと分離を参照してください。
手動で追加 設定 → ワークスペース → エージェントから行います。エージェントに同僚を採用するよう頼んでも行は作成されません。この画面を使用してください。

ライブ状態

エージェントには保存されたステータス列がありません。そのライブ状態は、読み取られるたびに最新の実行ログから導出されます。

状態	意味
`neverRun`	実行ログが存在しません
`running`	少なくとも1つの実行が現在進行中です
`failed`	最新の実行がエラーになったか、その生存状態が failed または dead です
`blocked`	最新の実行の生存状態が blocked、stalled、または looping です
`idle`	それ以外すべて — エージェントは以前に実行されたことがあり、進行中のものは何もありません

さらに2つの状態 queued と succeeded が、会話の実行ツリー内の個々の実行に対して存在します。名簿がこれらを生成することはありません。終了した実行がグリーンであることは実行についての事実であり、エージェントについての事実ではないからです。

プレゼンス名簿は、ライブの実行イベントからサーバー側で合成された、並行するより粗い像を表示します — 思考中、実行中、承認待ちでブロック中、完了 — これがエージェントを人間の隣に表示させます。マルチプレイヤーを参照してください。