用語集

コアエンティティ

エージェント: アイデンティティ、ロール、スキル、アダプターを持つ AI ワーカーです。ちょうど 1 つのワークスペースに属します。システムにおける主要なアクターです。

アダプター: エージェントのターンを実行するランナーです。2 つが同梱されます: Control Center（組み込み） — モデルプロバイダーと対話するインプロセスのハーネス — と、claude -p 経由の Claude Code です。Cursor、Codex、Anthropic、OpenAI、その他は、別個の CLI ではなく、組み込みアダプター上のプロバイダーです。アダプターとモデルを管理を参照してください。

ワークスペース: 最上位の分離テナントです。エージェント、リポジトリ、スペース、チケット、メモリ、パイプラインをまとめます。分離は慣習ではなく構造的です: 各ワークスペースは独自の SQLite ファイル（<dataDir>/<workspaceId>/workspace.db）を持つため、ワークスペースをまたぐ読み取りはコンパイルできません。アプリ内のすべてのルートには /workspaces/:workspaceId が前置されます — ルートマップを参照してください。

フォージ: コードホスト — GitHub、GitLab、Bitbucket Cloud です。フォージは各リポジトリのプロパティで、登録時に origin リモートから読み取られ、そのリポジトリの API アダプターと資格情報を選びます。1 つのワークスペースが 3 つすべてのリポジトリを保持できます。集約するサーフェス（受信トレイ、PR キュー）は、存在するすべてのフォージにファンアウトして結果をマージし、障害を分離するため、到達できないフォージが他を空にすることはありません。フォージはサポート内容が異なります — コードホストを接続のケイパビリティ表を参照してください。

リポジトリ: 1 つのワークスペース内に登録された Git リポジトリです。ワークスペース単位 — 同じチェックアウトを 2 つのワークスペースに登録すると、2 つの id を持つ 2 つの独立した行になります。ワークスペースをまたぐリポジトリの同一性はファイルシステムのパスで決まり、id では決まりません。登録には、origin リモートがサポート対象のフォージを指す git ワークツリーが必要です。各リポジトリはそのフォージ（github / gitlab / bitbucket）を持ち、それが使用する API アダプターと資格情報を選びます。

分離リポジトリ: 登録済みリポジトリのワークスペース単位のワークツリーです。そのネイティブが同梱されている場所では rift によるコピーオンライト、Windows では git worktree です。スペースごとにプロビジョニングされ、そのスペースのすべての会話が 1 つのチェックアウトを共有するため、エージェントがソースを書き換えることはありません。

スペース: 人間とエージェントの参加者、永続化された Mode、プロビジョニング状態、そして SpaceKind（topic / agentPeer / system / pr / slack）を持つ、ワークスペース単位のコラボレーションコンテナです。SpaceKind は、どのようにセクション分けされ、ミュートされ、バッジが付き、ガベージコレクションされるかを決めます。会話が共有する分離ワークツリーを所有します（rift によるコピーオンライト、Windows では git worktree）。

会話: スペース内の 1 つのメッセージストリームで、独自の id、履歴、エージェント実行コンテキストを持ちます。スペース内の会話は対等なフラットな存在で、primary や「main」のストリームはありません。それぞれがエディタータブとして開き、スペースの未読状態はそれらすべてを集約します。

スレッド: anchorMessageId が設定された会話です: 同じスペース内の兄弟会話の 1 つのメッセージにアンカーされ、そのアンカーメッセージをシードとする新しいエージェントコンテキストを持ちます。深さは 1 レベルで、スレッドがスレッドにアンカーされることはありません。

チケット: 作業単位のアグリゲートです。ベンダー中立で、既定では local、Linear、GitHub Issues、Jira Cloud、ClickUp 向けの同期アダプターを持ちますが、アプリ内で同期接続を作成するサーフェスはありません。階層、リンク、委任をサポートします。エージェントへの割り当ては所有権を記録するだけで何もディスパッチしません。例外はチームへの割り当てです（TeamRoutingService がリーダーをディスパッチします）。

パイプライン: ステップ（エージェントのディスパッチ、スクリプト、条件分岐）を連鎖させる DAG ベースのワークフローです。テンプレートで定義され、実行として実行されます。

値オブジェクト

AgentRole: 列挙されたロール（CEO、coder、reviewer、QA、designer、security、devops、PM、general）です。ペルソナ、メモリへのアクセス、階層を決めます。

AgentSkills: ディスパッチ時に関連するコンテキストをプロンプトへ注入する、大文字小文字を区別しないスキル識別子の集合です。

スキルのソース: スキルカタログとしてワークスペースごとに登録された GitHub リポジトリです。構造上信頼されません: リポジトリのメタデータは表示専用であり、すべてのインストールは、内容がディスクやプロンプトに到達する前にフェイルクローズのスキャンゲートを通過します。スキルのインストールと管理を参照してください。

skills-lock.json: インストール済みスキルのワークスペース単位のマニフェストです: 各スキルについて、そのソースリポジトリ、リポジトリ内パス、ピン留めされたコミット、およびロールアップされたコンテンツハッシュを持ちます。インストール、更新、アンインストールがこれを最新に保ち、verify_skills がディスクと照合します。

エージェント実行ゲートウェイ: エージェントのサンドボックス内にアクションポリシーを適用する、cc_server 上のループバックエンドポイントです。エージェントによる GitHub へのすべてのプッシュはここに回され、リモートへプッシュのルールと照合され、エージェントが決して持たない書き込みトークンで転送されます。Claude Code の Bash コマンドは同じエンドポイント上のフックを通じて確認されます。サンドボックスとセキュリティを参照してください。

Mode: chat、plan、review、orchestrate のいずれかです。スペース単位で保存されるため、1 つのエージェントがスペースごとに異なるモードになり、スペース内のすべての会話がそれを共有します。システムプロンプト、サンドボックスの書き込みルール、MCP ツールの許可リストをゲートします。コンポーザーが提供するのは chat、plan、orchestrate だけで、chat のラベルは「Agent」です。

SandboxBackend: microvm（囲まれた VM — カーネル境界を持つ唯一のバックエンドで、対話型ターミナルに適用されます）、native（macOS では Seatbelt、Linux と WSL2 では bubblewrap）、または none です。起動時に一度プローブされます。native は利用可能な場合にエージェントのディスパッチに適用され、Claude Code CLI とハーネスの bash ツールをラップします。Windows にはネイティブバックエンドがなく、Linux には bwrap と socat が必要なため、そこでの実行はラップされません。--sandbox off は意図的にオプトアウトします。

リグ: エージェントがリアルタイムで操作する使い捨てのマシンです — 囲まれたブラウザまたは Linux デスクトップ、ホストが管理する Android エミュレータまたは iOS シミュレータ、あるいは囲まれたターミナルです。独自のフル解像度レーンでライブに表示され、テイクオーバーはサーバー側で強制されます。会話にスコープされるため、人間のタブとエージェントの browser_use / computer_use / mobile_use / ios_use 呼び出しが 1 つの既定のマシンを対象にします。リグとエンクロージャーを参照してください。

エンクロージャー: VM ベースのリグが持つより強力な境界です — カーネル境界、使い捨てのオーバーレイディスク、既定で拒否するネットワークゲート、資格情報ブローカーです。Android と iOS のリグは使い捨てですが、ホストが管理するネットワークを使うため、この境界を主張しません。どのリグを操作する場合も enclosureControl ガードレールクラスを使います。

RunCost: 1 回のエージェント実行のトークン／コスト集計（入力トークン、出力トークン、セント単位の推定コスト）です。

WakeReason: エージェントがディスパッチされた理由です。6 つの値があります: ユーザーメッセージ、チケットの割り当て、失敗後のリカバリ再ディスパッチ、子チケットの完了、スケジュールされたフォローアップのハートビート、パイプラインステップです。

ポート

SandboxPort: サンドボックスのライフサイクル（プローブ、起動、イベント、exec、破棄）を管理します。

CredentialBrokerPort: サンドボックス起動用のスコープ付き資格情報を発行し — エージェントの環境には読み取り専用、書き込みはサーバー側のプッシュ経路のみ — 破棄時に失効させます。

GitRepoInspectorPort: ローカルの Git リポジトリパスからメタデータ（owner、repo、branch）を抽出します。

EmbeddingPort: セマンティック検索用の単位ノルムのテキスト埋め込みベクトルを生成します。

NotificationPort: カテゴリ／ルートのゲートを尊重してネイティブのデスクトップ通知を表示します。

TicketProviderPort: チケッティングバックエンドへのベンダー非依存の境界です（create、get、list、update、transition、assign）。

PipelineEnginePort: テンプレートからパイプライン実行を開始し、呼び出し元を具体的なエンジンから切り離します。

ドメインサービス

AgentDispatchService: エージェント実行を起動します: 分離リポジトリをプロビジョニングし、プロンプトを組み立て、実行ログを作成し、ライブのイベントストリームを返します。

TicketWorkflowService: 楽観的並行性の変更チョークポイントとワークスペース分離の強制を備えた、純粋なドメインのチケットライフサイクルエンジンです。これが強制する遷移グラフはエージェントと自動化だけを縛り、ユーザー主導の UI 変更は force: true を渡して迂回します。エージェントの担当者向けのチケットディスパッチャーは存在しません — ディスパッチを担うのは AgentDispatchService であり、チケットをエージェントに割り当てても実行は始まりません。例外はチケットをチームに割り当てる場合です（TeamRoutingService がリーダーをディスパッチします）。

PipelineEngine: 実行の実行をオーケストレートします: 実行を開始し、ステップをスケジュールし、状態を永続化し、ルーター／ジョイン／continue-on-fail を処理し、再起動後に進行中の実行を再開します。

PipelineTriggerDispatcher: ドメインイベントをサブスクライブし、有効なトリガーに対して一致するパイプライン実行を自動開始します。

MemoryAccessPolicy: ドメインに対するエージェントロールのメモリ権限を解決して強制します。

HarnessCostCalculator: models.dev カタログから、組み込みハーネスのトークン使用量を RunCost として価格計算します。ディスパッチはその集計を実行ログに永続化します。

BudgetEnforcementService: エージェントごとの月間支出と、ディスパッチ前のブロック（checkInvocationBlock）を計算します。このブロックを参照するのはリカバリのリコンサイラー（OrphanRunReaper、StrandedTicketReconciler）だけで、通常のユーザーやエージェントのディスパッチは決して参照しません。

BudgetGovernanceService: 各実行後にエージェントごとの月間支出を評価します — ソフトしきい値は警告インシデントを記録し、使い切るとハードインシデントを記録してエージェントのライフサイクルを paused に切り替えます。

イベント

DomainEventBus: フィーチャーをまたぐ通信用の、インプロセスのブロードキャスト型パブリッシュ／サブスクライブバスです。イベントは型付きで、サブスクライバーは on<T>() ストリームを消費します。

DomainEvent: 基底インターフェースです。すべてのイベントは occurredAt を持ちます。主要なカテゴリ: workspace/agent、PR/review、messaging、ticketing、pipeline、meetings/calendar、identity、rigs、observability。

ミーティングとカレンダー

ミーティング: ローカルに録音され文字起こしされたミーティングセッションです。マイクとシステム音声を取り込み、選択可能な ASR モデル（既定では Parakeet TDT v3。Parakeet TDT v2、Whisper large-v3-turbo、Whisper base.en が代替です）でオンデバイスで文字起こしし、話者をダイアライズして、ノート、アクションアイテム、決定事項に要約します。選択した ASR モデルは起動時に強制インストールされ、録音操作は 1 回の再起動後に有効になります。ワークスペース単位で、マシン上にとどまります。

MeetingSegment: 文字起こしされた 1 つの音声ウィンドウで、話者タグ（me/them）、ダイアライゼーションラベル、ミリ秒単位のオフセットを持ちます。

MeetingActionItem / MeetingDecision: 要約パイプラインが抽出し、個別の行として保存する構造化された出力です。アクションアイテムはチケットにリンクできます。

CalendarEvent: ワークスペースと接続済みアカウントにスコープされた、同期された Google Calendar のエントリです。ミーティングとは異なります: イベントは予定された約束であり、ミーティングは録音されたセッションです。MeetingCalendarLink を通じて 1 対 1 でリンクされます。

CalendarAccount: ワークスペースとメールアドレスごとの、接続された Google アカウントです。OAuth リフレッシュトークンは <dataDir>/secrets.json に google_* キーとしてサーバー側で保存され、クライアントに到達することはありません。デバイスコードフローはサーバー上で完了します。authExpiredAt フラグが再接続バナーを駆動します。

アーキテクチャ用語

クリーンアーキテクチャ: 依存関係のルール: Presentation → Application/Providers → Domain ← Infrastructure。Domain にはインフラストラクチャのインポートが一切ありません。

ポートとアダプター: ドメインが抽象インターフェース（ポート）を定義し、インフラストラクチャが具体的な実装（アダプター）を提供します。コンポジションルートがそれらをバインドします。

共有カーネル: 3 つ以上のフィーチャーで共有される core/domain/ のエンティティ、値オブジェクト、ポート、サービスです。

フィーチャー優先: コードは技術レイヤーではなくビジネスドメイン（agents、pipelines、messaging）ごとに構成されます。

マルチプレイヤー、アイデンティティ、ベロシティ

プリンシパル: 人間とエージェントを単一のアクター抽象として統合する sealed な値です — UserPrincipal(userId) または AgentPrincipal(agentId)。すべてのメッセージ、チケット、レビュー、プラン、実行ログはプリンシパルを通じて帰属します。

ユーザー: 人間のアイデンティティで、global.db に保存されるためワークスペースをまたいでグローバルです。ワークスペースを作成したプリンシパルがそのオーナーになり、Workspace.ownerUserId に、同じ操作でオーナーロールのメンバーシップ行とともに記録されます。その他は招待または SSO で参加します。

WorkspaceMember / WorkspaceRole: ユーザーをロール（owner / admin / member / viewer / guest）でワークスペースに束縛するメンバーシップ行です。アクセスの境界となるのは、ペアリングキーではなくメンバーシップです。 リポジトリ単位の許可が、メンバーシップによってフォージを上回る権限が得られないようにします。

ParticipantPresence: プリンシパルの一時的な気配です（ステータス、ローカス、カーソル、タイピング、エージェントのライブステータスと実行中コスト）。決して永続化されず、サーバーハブ方式で、ファンアウト前にリポジトリの許可でフィルタリングされます。

フォローモード: アバターをクリックすると、あなたが操作するまでそのビューポートに追従し、その後デタッチします。人間にもエージェントにも機能します（「エージェントの作業を眺める」）。

自律度ダイヤル: スペースごと、エージェントごとの制御で、propose-only / act-with-approval / act-freely のいずれかです。アクションガードレールストア上の名前付きプロファイルとして実装されています。

ActionClass: 13 個のエフェクトクラスからなる閉じた集合です（fileDelete、gitPush、prCreate、networkEgress、processSpawn、enclosureControl、…）。すべての変更ツールが自分のクラスを宣言し、ガードレールエンジンがスコープごとに allow / prompt / deny を解決します（space > agent > workspace > mode preset > built-in default）。

WriteLedger / 冪等キー: すべての変更は、クライアント生成の冪等キー（UUIDv7、論理アクション単位）を運びます。ワークスペース単位の台帳がハンドラー実行前に重複を排除し、再生はバイト単位で同一の元の結果を返します。これにより、再接続とマルチクライアントが構造的に安全になります。

要対応の受信トレイ: 厳格なルールを持つ横断的なキューです — 何か（エージェント、マージ、同期）を ブロック しているか、明示的にオペレーターを要求している場合にのみ、項目が現れます。

Plan Studio: インタラクティブなプランニングサーフェスです — ステップごとのコスト、時間、リスクと部分承認を備えた、編集可能な型付き DAG のプランです。

レビューコンピュート: サーバー側の PR レビューコンピュート（グラフから導かれたコホート、型付き図、ビジュアル差分、API 契約差分、複数軸のゲート）で、review_studio.* 経由で提供され、レビュータブに組み込まれます。

レビュースペース: PR の唯一の基盤スペース（モード review、種類 pr）で、冪等に作成され、ReviewSpaceAssociation によって PR にリンクされます。すべてのレビュアーがそこに指摘を登録し、それが比較可能性を生みます。その分離ワークツリーには、ヘッド時点の PR がチェックアウトされています。

レビューノード: AI レビューの指摘の構造化された単位です: 種別（bug、suggestion、recommendation、question、ticket）、優先度 P0〜P3、カテゴリ／重大度／工数のトリアージ三点、ファイルと行のアンカー、任意の修正案、確信度スコアです。add_review_node で登録され、判定は散文ではなくノードから算出されます。

コンセンサス準備完了: ピアのレビュアーが指摘を確認したときにだけ到達するレビューノードのステータスです — エージェントが自分の指摘を確認することはできません。レビュータブの GitHubに公開 ボタンは残っているすべてのオープンな指摘を送信し（selection: all_open）、MCP ツール publish_review_to_github は今もピアが確認した指摘のみを既定とします。

レビューレベル: どのレビュアーがファンアウトするか（エンジニアのみ、+qa+architect、+security+perf）と、しきい値未満の指摘をどこに表示するかを定めるワークスペースポリシー（light、balanced、thorough）です。指摘を削除することは決してありません。

レビュー軸: レビューごとの 5 つのスコアリングレーンの 1 つです: correctness、security、testGap はレビュアーの指摘から導かれ、visual と apiContract は決定論的です。ゲート対象の軸は判定に組み込まれ、それをより厳しくすることしかできません — partial または unavailable のゲートは、判定を通過させるのではなく引き留めます。

レビュー判定: ship、hold、block のいずれかです。確信度 ≥ 0.7 の P0 の指摘は block にします。それ以外の P0 または P1 は hold にします。それ以外は ship です。ゲート対象の失敗した軸は block を強制し、指摘による多数決で覆すことはできません。

フリートと評価

cc_worker: ヘッドレスの純粋な Dart のフリート実行者バイナリです。cc_server とペアリングし、ホストのケイパビリティを宣言し、リースされたジョブを取得して実行し、プロセスイベントをストリームで返します。永続状態を一切持ちません — 権威あるサーバーが 1 つ、愚直な手足が N 個です。

JobSpec: 実行可能なものすべて（エージェント実行、パイプラインステップ、コードインデックス、ゴールデンレンダー、ベンチマーク、評価バッチ）の型付き仕様です。

評価スイート: ワークスペース単位の評価定義です（プロンプト、対象のエージェントとモード、グレーダー）。ワークスペースの作成時に 5 つのスターターがシードされ、オブザーバビリティ → 品質に一覧表示されます。

デプロイメントとクライアント

シンクライアントアーキテクチャ: どのクライアントもデータベースを開きません。ヘッドレスの cc_server プロセスがデータを所有し、WebSocket RPC 経由で提供します。すべてのクライアント（デスクトップ、Web、スマートフォン）は、その 1 つの RPC 接続上のレンダラーです。

cc_server: ヘッドレスサーバーバイナリです（純粋な Dart、Flutter エンジンなし）。Drift/SQLite データベースを所有し、WebSocket 経由で repo-RPC を提供し、バックグラウンドサービス（パイプライン、MCP、リコンサイラー）を実行します。

ServerConnectionMode: デスクトップがサーバーに到達する方法です — local（このマシンで cc_server を起動する。既定）または remote（別の場所のサーバーに接続する）。Web クライアントは常に remote です。

RemoteRpcClient: すべてのシンクライアントがサーバーと通信するために使う、トランスポート非依存の JSON-RPC クライアントです — WSS、ループバック、またはブローカー経由のリレーを介します。

コール単位のワークスペーススコープ: サーバーはステートレスです — セッション単位のワークスペース束縛は存在しないため、1 つのサーバー上の複数のクライアントが「現在のワークスペース」を共有することはありません。ワークスペーススコープのすべての repo/call と sub/subscribe は、引数に workspace_id を含まなければなりません。欠落した id、または未登録の id は、データベースを開く前に拒否されます。アクセスはその後、セッションではなく、ワークスペースのメンバーシップとロールによってゲートされます。

cc_remote: スマートフォン用のシンクライアントです — ブローカー経由のリレーを介してフリートをリモートコントロールする、既定で拒否のツールポリシーを持つ Flutter Web の PWA です。

cc_signaling_server: 招待でゲートされたルームをホストする、ステートレスな WebSocket リレーブローカーです — エンドツーエンドで密封されたフレームだけを転送し、アプリのデータを一切保持せず、ペアリング PSK を見ることもない愚直なリレーです。

関連項目

• ルートマップ
• アーキテクチャ
• ワークスペース
• ドメインイベント