用語集

このハンドブック全体で繰り返し使われる用語を一箇所にまとめました。各項目の「詳細」は、その用語を最初に詳しく説明した章にリンクしています。

中核概念 チーム構成要素 ワークスペース構造 ツール・プラットフォーム

中核概念

ハーネスエンジニアリング Harness Engineering
モデルがどのツール・ルール・検証装置を通じて働くかを設計すること。プロンプトエンジニアリング(何を伝えるか)→コンテキストエンジニアリング(何を知らせるか)に続く第三段階にあたる。 詳細: 第2章 §1
サブエージェント Subagent
メインセッションとは独立したコンテキストウィンドウを持ち、狭い範囲のタスクを処理したのち要約だけを返す補助エージェント。「スペシャリスト」という概念を実際のツールで実装する仕組みである。 詳細: 第2章 §3b
ハンドオフ Handoff
エージェント間で作業を引き継ぐ行為、またはその地点。ハンドオフ契約(Handoff Contract)は、やり取りする情報の形式を構造化したもので、目的・範囲・前段階の成果物を明示することで、次のエージェントが聞き返すことなくすぐに作業を開始できるようにする。 詳細: 第2章 §3
動的チーム編成 Dynamic Team Composition
オーケストレーターがリクエストのたびに、実際にどのサブエージェントを何回、どの順序で投入するかをその都度判断すること。定義されたチーム名簿は固定であっても、実際の投入構成はタスクごとに変化する。 詳細: 第2章 §4b · 実習: 第4章 D-2
オーケストレーションパターン Orchestration Pattern
Anthropicが整理した5つの代表的パターン。プロンプトチェイニング(段階的な逐次処理)、ルーティング(リクエストを分類し適切なエージェント/モデルへ振り分け)、並列化(ファンアウトによる独立タスクの同時実行、または投票による同一タスクの反復実行と多数決)、オーケストレーター・ワーカー(サブタスクを事前に固定せず動的に分解)、評価者・最適化(下書きを独立に検証してからのみ反映する「検証してから適用」方式)がある。これらは一つのワークフローの中で自由に組み合わせて使うことができる。 詳細: 第2章 §4
コンテキストウィンドウ / コンテキスト過負荷 Context Window / Context Overload
AIモデルが一度に処理できるトークン(テキスト)の上限をコンテキストウィンドウと呼ぶ。この上限の中に、役割定義・過去の会話・作業指示・成果物のすべてを収めなければならず、内容が増えるにつれて前半の情報が薄れていく現象をコンテキスト過負荷と呼ぶ。マルチエージェントチームは、これを役割ごとに分散して解決することを主な動機の一つとしている。 詳細: 第1章 §マルチエージェント:専門家チームの原理
フロントマター Frontmatter
エージェント定義ファイル(agents/*.md)の先頭にYAML形式で記述するメタデータブロック。エージェント名・役割・許可されたツール(tools)・モデルティア(tier)などを機械的にパースできるよう定義する。extendsフィールドによって他のエージェントファイルを継承することもできる。 詳細: 第8章 §1 デプロイとSSOT
スキャフォールディング Scaffolding
bun scripts/new-project.tsによって、variantテンプレートの全体構成(エージェント・スキル・コマンド・ガバナンスパイプライン)を独立したgitリポジトリとして複製する作業。「プロジェクトをゼロから作るのではなく、あらかじめ設計された骨組みの上から始める」という意味を持つ。 詳細: 第6章 §2
ガードレール Guardrails
許可モデル・フック・監査など、エージェントの行動境界を強制する安全装置。 詳細: 第3章 §1
フック Hook
エージェントが特定のツールを呼び出す前後に自動実行されるスクリプト。例: PostToolUseフックによるファイル修正後の自動監査(audit)チェック。Claude Code(CLI)では.claude/hooks/に定義されたフックが発火するが、Claude Desktop Appでは動作しないため、ツールごとの挙動の違いに注意する必要がある。 詳細: 第3章 §監査ログと可観測性
かんばん / WIP制限 Kanban / WIP Limit
同時に進行中の作業(Work In Progress)の数を制限する並列性の制御方法。ファンアウトによってエージェントを複数同時に投入する際、WIP制限を設定しておくことで、同時実行数が多くなりすぎることによるリソース競合やコンテキスト欠落を防ぐことができる。 詳細: 第2章 §オーケストレーションパターン
サービスチケットモデル Service Ticket Model
AIを「リクエストを受けたら処理してくれるサービス」としてのみ利用する運用方式。既存のIT組織のチケットシステムに似ている。ユーザーが一つひとつリクエストの形で指示する必要があり、エージェントチームの自律性が制限される。本ハンドブックが提案する「開発ツール+variantモデル」と対比される考え方である。 詳細: 第7章 · 企業内運用戦略の比較
ライフサイクル / 状態 Lifecycle / State
ライフサイクルとは、エージェント・スキル・スクリプトが経る一連の段階全体(例: Create→Verify→Operate→Improve→Deprecate)を指す。状態とは、ある時点でその構成要素がライフサイクルのどの段階にあるかを示すスナップショットである。YAMLフロントマターのstatusフィールド(draft、active、deprecated、retired)が状態の値を保持する。ライフサイクルは「路線図」、状態は「今どの駅に列車がいるか」を示す表示板に例えられる。 詳細: 第8章 §2 · 状態とライフサイクルの区別

マルチエージェントチーム構成要素

オーケストレーター Orchestrator
全体の作業を段階に分け、スペシャリストを呼び出し、ユーザー確認が必要な地点で止まる役割。しばしば「PMエージェント」と呼ばれる。
スペシャリスト Specialist
設計・実装・テスト・セキュリティレビューのように、狭く明確な責任を持つエージェント。入力と出力が明確に定義されている。
モデルティア Model Tier
エージェントの役割ごとに割り当てるモデルのコスト等級(high/medium/low)。判断の重い役割にはhigh、定型的な反復作業にはlowを割り当て、コストと品質のバランスを取る。agents/*.mdフロントマターのtierフィールドで指定し、実際のモデル名はmodel: inheritによってプラットフォームが変換する。 詳細: 第5章 §3。L0→L1→L2の「3層(3-tier)」とは別の概念なので混同に注意。

ai-workspace-standards 構造

SSOT Single Source of Truth
ある情報の原本がただ一箇所にのみ存在するという原則。例: CONSTITUTION.mdはワークスペース全体のルールのSSOTであり、context.mdは個々のプロジェクトの設定文書である。 詳細: 第5章 §4
L0 / L1 / L2 / L3
ワークスペースルート(L0、唯一の原本)→共通テンプレートスナップショット(L1、templates/common/)→variantテンプレート(L2、templates/co-*/)→稼働中のプロジェクト作業ディレクトリ(L3、Projects/*/、new-project.tsによってL2 variantからスキャフォールディングされる — 外部クローンではなく同じワークスペースリポジトリ内にある)へと続く4層構造。流れは常に上から下へのみ進み、L1→L2はvariant作成時点で一度だけ行われる「フォーク」であり、L2→L3はプロジェクト作成時の一回限りのスキャフォールディングである。 詳細: 第8章 §1 デプロイとSSOT
フォークモデル Fork Model
L1からL2が分岐したのちは、自動的な逆同期を行わず独立して進化していく方式。正式テンプレートへ昇格させるには、l3-to-variant-pipeline.tsを人が明示的に実行する必要がある。
variant
templates/配下にある、特定のドメイン向けに完結したマルチエージェントチーム構成(PM・専門エージェント・ガバナンスパイプラインの一式)。co-develop、co-design、co-workなどが例である。 詳細: 第5章 §3
Phase A / Phase B
新規variantを作成する際の2段階。Phase AはProjects/配下で独立したプロトタイプとして自由に実験する段階、Phase Bはpromote-variantによって正式なtemplates/variantへ昇格させる段階である。 詳細: 第11章 · 新規variant作成
ボイラープレート Boilerplate
プロジェクトごとに最初から書き直す必要のあるPM役割定義・ガバナンスパイプライン・コマンド/スキル配線をあらかじめ揃えておいた出発点。ai-workspace-standardsが提供するものの本質である。
コンテナ連携 Container Integration
ai-workspace-standardsの高度化の方向性の一つ。スキャフォールディングされたプロジェクトが、Docker/Kubernetes環境でOpen WebUIのようなサービスと連携し、個人単位でサポートされるべきだという要求。現時点ではローカルのAIコーディングツールと直接連携する方式のみがサポートされている。 詳細: 第8章 §5 高度化ロードマップ
メモリ統合 Memory Consolidation
ai-workspace-standardsの高度化の方向性の一つ。個々のプロジェクトごとに散在するmemory/YYYY-MM-DD.mdファイルをワークスペースレベルで統合・整理し、全体的な傾向を把握できるようにする機能。 詳細: 第8章 §5 高度化ロードマップ

ツール・プラットフォーム

AGENTS.md
30以上のAIコーディングツールが共通して読み込むオープンスタンダードファイル。ビルド・テストコマンドやコードスタイルなど、ツールに依存しない規則を定義する。本リポジトリでは、これに加えて「エージェントロースター」の役割も兼ねている。 詳細: 第2章 §ツールを横断するハーネス、AGENTS.md
teammateMode
Agent Teams(実験的機能)の並列実行モード。Claude Desktop Appはin-processのみをサポートし、Claude Code(CLI)はtmux分割ペインモードも追加でサポートする。 詳細: 共通参考 §1
Agent Manager
Antigravity(Desktop)で複数のワークスペースを一画面で統括する上位インターフェース。ワークスペースごとにエージェントを一つずつ割り当てることを原則とする。
/goal / /agent / /agents
Antigravity CLI(agy)で動的サブエージェントオーケストレーションを呼び出すスラッシュコマンド。/goalは目標を最後まで実行し、/agentはバックグラウンドでの長時間タスクを委任し、/agentsはこれまでに生成されたサブエージェントの状態一覧を確認する。この能力自体はagyだけのものではない — Claude Code/Appは同じ動的オーケストレーションをAgent(Task)ツールと自然言語のリクエストによって、Antigravity(Desktop)はAgent ManagerのGUIによって実行する。この3つのコマンドは、その動作をCLI画面上で呼ぶ際の名称にすぎない。 詳細: 共通参考 §2