| Agent |
目標に基づいて状態を観察し、アクションを選択・実行し、その結果に応じて状態を更新して次のステップを決定するシステム |
| Agentic Workflow |
決定論的なオーケストレーションに、局所的な動的判断を取り入れたワークフロー |
| Bounded Autonomy |
候補アクション、権限、予算、ステートマシン、評価ゲートによって制限された自律性 |
| Context Contract |
モデルのコンテキストに入る情報の種類、出所、権限、ライフサイクル、信頼性に関する取り決め |
| Context Engineering |
タスクの完了に必要な情報、能力、制約を、適切なタイミングと形式でモデルとツールに提供する動的システムを構築すること |
| Context Pack |
1回のモデル呼び出しに実際に渡される型付き入力契約。目標、状態、エビデンス、ツール、予算、省略情報、バージョン情報を含む |
| Evidence |
出所、バージョン、Locator、時刻、権限、および根拠となる Claim に紐づけられた意思決定のエビデンス |
| Source Manifest |
データソースの Owner、分類、ACL、更新、有効時間、削除、パーサー、Schema を登録する契約 |
| RAG |
Retrieval-Augmented Generation。生成時に外部知識を検索し、モデルのコンテキストとして提供する手法 |
| Agentic RAG |
推論の進行に応じて Agent が検索のタイミングと方法を決定し、制限されたループ内でエビデンスを補完する手法 |
| Hybrid Retrieval |
クエリの形状に応じて FTS、Vector、Graph、SQL、API を組み合わせ、複数経路の候補を統合して再ランキングする手法 |
| GraphRAG |
エンティティ、関係、パス、コミュニティ、グラフアルゴリズムを利用してエビデンスを検索・整理する手法。具体的な製品実装は異なる場合がある |
| Knowledge Graph |
ビジネスのエンティティ、関係、ルールを記述し、「何が真実で、何がつながっているか」に答えるグラフ |
| Context Graph |
1回の Agent 実行における Goal、Task、Tool、Evidence、Claim の因果関係を記述するグラフ |
| Handoff |
ある Agent がタスクの制御権と必要な状態を別の Agent に明示的に引き渡すこと |
| Supervisor |
複数の責任単位にまたがるルーティング、委任、集約、制御を担うオーケストレーション上の役割 |
| Central Supervisor |
ドメイン横断の Goal 分解、Team ルーティング、グローバルな依存関係、予算、結果集約を担うコントロールプレーン上の役割 |
| Team Supervisor |
単一ドメイン内で Worker を選択し、サブ予算を割り当て、局所的な結果を検証して、外部に Team Result を返す役割 |
| Delegation Contract |
サブタスクの目標、受け入れ基準、スコープ、ツール、予算、期限、エスカレーション方法に関する取り決め |
| Result Contract |
Agent タスクの状態、結論、エビデンス参照、不足情報、副作用、次のステップの提案に関する取り決め |
| Join Contract |
並列タスクの待機集合、完了しきい値、タイムアウト、競合、遅延結果に関する集約の取り決め |
| Late Result |
タスクのタイムアウトやキャンセル後、または Plan の更新後に到着した結果。記録はするが、現在の状態へ既定で統合してはならない |
| Reconcile |
外部の副作用の状態が不明な場合に、無条件に再試行するのではなく、権威あるシステムへ問い合わせてローカル状態を収束させること |
| Artifact |
Agent またはツールが生成した参照可能な成果物。本番システムでは不変バージョンとコンテンツハッシュを使用することが望ましい |
| AgentOps |
Goal、Plan、Route、Tool、Evidence、Decision、Control を軸に、診断、介入、復旧、継続的な最適化を可能にする本番運用の責任体系 |
| Capstone |
1つの完全なプロジェクトを通じて、問題、アーキテクチャ、実装、セキュリティ、評価、リリース、運用、保守のエビデンスを一貫して完結させる総合的なデリバリー |
| Vertical Slice |
最小限の機能によって、アイデンティティ、計画、委任、ツール、状態、エビデンス、評価、観測などの実際の境界を貫くエンドツーエンドのスライス |
| Evidence Package |
特定の Release Candidate に紐づき、プロダクト、アーキテクチャ、実装、品質、セキュリティ、レジリエンス、運用、トレーサビリティのエビデンスを集約した受け入れ検証パッケージ |
| Traceability Matrix |
Requirement、ADR、Contract、Implementation、Verification、Runtime Evidence、Sign-off を双方向に結び付ける関係 |
| Release Candidate |
ソースコード、契約、Prompt、Model、Tool、Policy、Knowledge、成果物、エビデンスの各バージョンを固定したリリース候補 |
| Clean-room Reproduction |
作者のローカルマシンの状態や口頭説明に依存しない独立環境で、公開手順に従ってシステムとエビデンスを再現する受け入れ検証手法 |
| SBOM |
Software Bill of Materials。リリース成果物に含まれる直接依存および推移的依存、そのバージョン、識別子、ライセンスを記述するソフトウェア部品表 |
| Build Provenance |
成果物が誰によって、どのようなビルドプロセスで、どの入力を使用して生成されたかを記述する検証可能な出所情報 |
| Artifact Attestation |
成果物とその来歴、ビルド、その他の属性についての検証可能な署名付き声明。成果物に脆弱性がないことを意味するものではない |
| Release Gate |
問題、設計、スライス、品質、セキュリティ、運用などの独立したリスクごとに、Pass、Conditional Pass、Fail を判定するリリースゲート |
| System Acceptance |
要件、エビデンス、リスク、独立した再現に基づき、システムをデリバリー可能かどうか正式に判断すること |
| Goal Outcome Event |
目標の結果、安全経路、エビデンスのカバレッジ、レイテンシ、コスト、バージョン、相関参照を記述する構造化された運用イベント |
| Tier 1 Metric |
ユーザーへのコミットメントとシステム全体の健全性を直接表し、運用上の意思決定を変え得る目標レベルの指標 |
| Tier 2 Metric |
Planner、Router、Worker、Tool、Model、State、Security などの責任レイヤー別に Tier 1 の変化を説明する診断指標 |
| Incident Bundle |
インシデントの影響、バージョン、エビデンス、制御アクション、ロールバック、タイムラインを集約した引き継ぎ可能な事実パッケージ |
| A2A |
Agent2Agent Protocol。独立した Agent 間で能力を発見し、メッセージを交換し、タスクを追跡して成果物を引き渡すための相互運用プロトコル |
| AgentCard |
A2A において Agent のアイデンティティ、インターフェース、能力、スキル、セキュリティ方式を記述するディスカバリーオブジェクト |
| Capability Snapshot |
AgentCard または Registry から導出し、ユーザー、テナント、環境、バージョン、リスクでフィルタリングしたうえで Planner に提供する能力のスナップショット |
| Tool Call |
モデルが生成する構造化されたアクション提案。実行前に解析、検証、認可を受ける必要がある |
| Tool Contract |
ツールの名前、用途、入力 Schema、権限、エラー、冪等性、副作用を定めた完全な契約 |
| State |
Agent がステップ間で共有する構造化された実行時データ。タスク、エビデンス、制御、相関情報を含む |
| Checkpoint |
一時停止、再開、リプレイ、障害分析のために、状態グラフのステップ境界で保存する状態スナップショット |
| Idempotency |
同じ業務アクションが繰り返し要求されても、追加の副作用を発生させない、または同じ結果を返す性質 |
| MCP |
Model Context Protocol。AI Host と外部 Server が能力を発見、読み取り、呼び出すための標準プロトコル |
| Golden Dataset |
ガバナンスが確立され、反復実行が可能で、重要なリスクを代表する評価ケース契約の集合。入力、事実、エビデンス、経路の不変条件、許容範囲、出所を含む |
| Golden Entry |
Golden Dataset 内の個別のバージョン付きケース。入力、期待される事実とエビデンス、許可・禁止される振る舞い、実行ポリシー、ガバナンスメタデータを記述する |
| Evaluation Contract |
品質属性、対象集団、計算方法、評価器、スライス、しきい値、ゲート、Owner に関する取り決め |
| Evaluator |
1回または複数回の Agent 実行に対して構造化された測定値や判定を生成するコード、ドメインルール、LLM Judge、人手レビューの仕組み |
| LLM-as-a-Judge |
明確な Rubric に基づいて、言語モデルで自由形式の出力を評価、またはペア比較する測定手法。キャリブレーション、バージョン管理、判断保留、人手レビューが必要となる |
| Judge Calibration |
Judge の判定と独立した人間のラベルを比較し、一致率、Precision、Recall、Kappa、順序の安定性、スライス別の誤差を評価するプロセス |
| Evaluation Slice |
意図、リスク、言語、経路、モデル、ツール、その他の軸で分割した評価サブセット。全体平均では隠れてしまう差異を発見するために使用する |
| Holdout Set |
開発時のチューニングから分離し、リリース検証または定期監査に使用する留保評価セット |
| N-run |
明示したモデルパラメータ、Fixture、キャッシュ、状態リセットの条件下で同じケースを繰り返し実行し、結果の分布を分析する手法 |
| pass@k |
k 回の試行のうち少なくとも1回成功する確率または観測指標。候補生成や検索のシナリオでよく使用される |
| pass^k |
k 回の実行がすべて成功することを表す、本書独自の表記。安定した実行を重視するもので、業界で統一された標準名称ではない |
| Paired Evaluation |
Baseline と Candidate を同じケース、同じ制御条件下で実行し、ケースごとに差分を比較する評価設計 |
| Regression Gate |
ハードゲート、非回帰の許容範囲、性能・コスト予算に基づき、変更を次のリリース段階へ進めてよいか判断する品質戦略 |
| Quality Drift |
目標の成功、忠実性、安全性、意思決定、体験などの品質属性が、時間またはバージョンとともに変化する現象 |
| Data Leakage |
評価ケースまたはその意味的近傍が、学習、Few-shot、RAG、Memory に混入し、汎化能力を示さないまま回帰スコアを過大に高める現象 |
| Trace |
1つのタスクにおける計画、ルーティング、ツール、状態、出力の観測可能な実行軌跡 |
| Control Plane |
ルーティング、計画、ポリシー、予算、承認、状態遷移を担うコントロールプレーン |
| Runtime Control Plane |
本番環境の観測結果を、サーキットブレーク、縮退、キャンセル、レート制限、ロールバック、復旧などの監査可能なアクションへ変換する実行時コントロールプレーン |
| Control Action Contract |
制御アクションの対象、スコープ、理由、承認、想定バージョン、期限、ロールバック、復旧条件に関する取り決め |
| Execution Plane |
Agent、Tool、Worker、Sandbox、モデル呼び出しを実際に実行する責任面 |
| Source of Truth |
ある事実が競合した際に最終的な裁定権を持つ権威ある情報源 |
| Derived Index |
クエリや分析の効率を高めるために権威ある情報源から生成され、バージョンに基づいて再構築できる派生構造 |
| Startup Probe |
アプリケーションが許容時間内に初期化を完了したかを判定するプローブ。成功するまで通常の Liveness Probe と Readiness Probe を実行すべきではない |
| Liveness Probe |
プロセスが、復旧に再起動を必要とする内部障害に陥っているかを判定するプローブ |
| Readiness Probe |
現在のインスタンスが新しいトラフィックを受け入れられるかを判定するプローブ。失敗時は通常、再起動せずトラフィックの送信対象から除外する |
| Synthetic Check |
制御されたテストリクエストを使用して、重要なエンドツーエンドの業務経路を検証する能動的なチェック |
| OpenTelemetry |
Trace、Metric、Log などのテレメトリデータを生成、伝播、収集、エクスポートするためのオープンなオブザーバビリティフレームワーク |
| Baggage |
リクエストとともに伝播する、制御されたキーと値のコンテキスト。下流のネットワークリクエストに入り得るため、機密データを含めてはならない |
| SLO |
Service Level Objective。指定した期間内のユーザーが知覚できるサービス指標に設定する目標 |
| SLI |
Service Level Indicator。ユーザーが知覚できるサービス性能の計算定義であり、対象集団、分子、分母、期間、除外項目を明示する必要がある |
| Error Budget |
1 - SLO で表される許容可能な信頼性の不足分。変更速度と信頼性への投資のバランスを取るために使用する |
| Error Budget Burn Rate |
指定した期間内にエラーバジェットを消費する速度。急速または継続的な信頼性の低下を特定するために使用する |
| RPO |
Recovery Point Objective。障害後に許容できるデータ損失の時間範囲 |
| RTO |
Recovery Time Objective。障害発生から対象サービスの復旧までに許容される最長時間 |
| Circuit Breaker |
下流で障害が続く際に速やかに失敗させ、制御されたプローブによって復旧したかを判定するサーキットブレーカー機構 |
| Bulkhead |
タスク、テナント、ツール、リソースプールごとに並行処理と障害を隔離するバルクヘッド機構 |
| Backpressure |
システムが過負荷の際に、拒否、有界キュー、レート制限、縮退によって上流からの入力を抑制する仕組み |
| Retry Amplification |
物理的な試行の総数と一意な論理操作数の比率。複数レイヤーの再試行が重なることで生じる負荷とコストの増幅を特定するために使用する |
| Cost per Successful Goal |
有効コストの総額を成功した Goal の数で割り、技術的な消費をビジネス成果に結び付けるユニットエコノミクス指標 |
| Wasted Cost |
失敗、破棄、重複、または最終結果に寄与しなかった処理によって発生したモデル、ツール、プラットフォームのコスト |
| Semantic Cache |
意図、エンティティ、権限、バージョン、有効時間に基づき、意味的に同等のリクエストや中間結果を照合するキャッシュ。ヒット時にも分離とエビデンスの制約を再度満たす必要がある |
| Experience Store |
出所、人手レビュー、スコープ、有効期間、プライバシー、バージョン互換性のガバナンスを適用した、再利用可能な運用経験のストア |
| Prompt Release Manifest |
Prompt のバージョン、コードコミット、変数、互換性契約、評価、カナリアリリース、除外リスク、ロールバック、Owner を記録するリリースマニフェスト |
| GameDay |
制御された本番環境に近い環境で障害を注入し、システム、人員、プロセス、アラート、Runbook、復旧能力を総合的に検証する演習 |
| ORR |
Operational Readiness Review。SLO、品質、セキュリティ、復旧、運用、コスト、演習のエビデンスに基づいて Go、Conditional Go、No-Go を判定する本番運用準備レビュー |
| Break-glass |
緊急時に一時的な権限昇格または通常のアクセス手順の迂回を可能にする制御された仕組み。明確なスコープ、承認、TTL、監査が必須となる |
| DLQ |
Dead Letter Queue。再試行上限に達した、または処理できなかったメッセージを、診断と制御されたリプレイまで保持するキュー |
| Prompt Injection |
攻撃者がユーザー入力、検索コンテンツ、ツール結果、その他の経路を通じて、モデルの目標、意思決定、出力に影響を与える攻撃 |
| Indirect Prompt Injection |
ユーザーから直接与えられるのではなく、Web ページ、メール、文書、OCR、ツール結果、Peer Agent のコンテンツに埋め込まれた悪意ある命令 |
| Least Agency |
真に必要な場合にのみ、最小限の機能、権限、自律性を付与する Agent セキュリティ原則 |
| Tool Guard |
モデルの Tool Intent と特権実行器の間に位置し、アイデンティティ、ポリシー、Schema、リスク、承認、結果のゲートを適用するアーキテクチャ上の役割 |
| Policy Enforcement Point |
アクセスまたはアクションのリクエストを捕捉し、Policy Decision を適用する決定論的な制御点 |
| Workload Identity |
サービス、Agent、Worker、Tool Runtime を表すマシンアイデンティティ。エンドユーザーのアイデンティティとは分離される |
| Effective Authority |
ユーザー、Workload、委任、タスク、ツール、リソース、環境、承認それぞれの権限の積集合として決まる実効権限 |
| Bound Approval |
特定のアクション、リソース、パラメータハッシュ、バージョン、Scope、有効期間に紐づけて付与される承認 |
| TOCTOU |
Time of Check to Time of Use。チェックの成功後から実行前までの状態変化により、先の認可が無効になる問題 |
| Confused Deputy |
低権限の主体が高権限のサービスを誘導し、元の主体には許可されていないアクションを、そのサービス自身の権限で実行させる問題 |
| Token Audience |
Access Token の発行対象となるリソースサービス。受信側は、自身が想定されたオーディエンスであることを検証する必要がある |
| DLP |
Data Loss Prevention。機密データの検出、分類、変換、ブロック、外部流出の監視 |
| Security Invariant |
統計的なエラーバジェットによる消費を許さないゼロトレランスのセキュリティ条件。たとえば、未認可の副作用はゼロでなければならない |
| Attack Success Rate |
指定した攻撃セット、バージョン、反復回数の範囲内で、攻撃が禁止された目標を達成した割合 |
| Red Team |
明確なスコープと安全上の制約のもとで攻撃を模擬し、制御、検知、対応、復旧の能力を検証する活動 |
| Fail Closed |
制御または依存先が失敗した際に、保護対象のアクションを既定で拒否し、セキュリティコンポーネントの利用不能によるポリシー回避を防ぐこと |
| Nonce |
メッセージ、承認、委任のリプレイを検出するために1回だけ使用するランダム値または一意値 |
| ADR |
Architecture Decision Record。背景、制約、選択肢、決定、検証方法を記録する文書 |