概要
エンタープライズ業務におけるAI Agentの急速な普及は、品質測定に対する厳密かつ標準化されたアプローチを要求している。関数が正しい値を返すか返さないかという従来のソフトウェアとは異なり、AI Agentは多段階ワークフローにわたって文脈依存の意思決定を行い、さまざまな適切さでガバナンスGateを呼び出し、さまざまな完全性のエビデンスバンドルを生成し、そのすべてをレイテンシ制約の下で行う。標準化された評価インフラの欠如は、Agent品質が逸話的な観察、スポットチェック、またはインシデント後の分析によって評価されることを意味する——いずれもスケールせず、再現性がなく、体系的な改善に必要な継続的フィードバックループを提供しない。
本論文はMARIA OS評価ハーネスを紹介する——Agent品質測定のために第一原理から設計されたテストインフラストラクチャである。Agent品質空間を網羅的にカバーする4つのテストカテゴリを定義する：正確性（Agentは正しい意思決定を行うか？）、安全性（Agentは有害なアクションを回避するか？）、パフォーマンス（Agentはレイテンシとスループットの要件を満たすか？）、ガバナンス準拠（Agentは組織の意思決定アーキテクチャを尊重するか？）。各カテゴリについて、具体的なメトリクス、閾値基準、評価プロトコルを規定する。
ハーネスアーキテクチャは4つのコンポーネントで構成される：決定論的シーディングによるシナリオ実行を制御するテストランナー、ドメインテンプレートからパラメータ化されたテストケースを生成するシナリオジェネレーター、Agent出力を検証済み参照意思決定と比較するオラクルコンパレーター、評価実行間で統計的に有意な品質劣化を識別するリグレッションディテクター。すべてのコンポーネントはMARIA座標系を通じてスコーピングされ、個別Agentからユニバース全体まで、組織階層の任意のレベルでテストターゲティングが可能となる。
1. はじめに：なぜAgent品質には標準化された測定が必要か
ソフトウェアエンジニアリングは数十年をかけてテスト方法論を発展させてきた——ユニットテスト、統合テスト、プロパティベーステスト、ミューテーションテスト、パフォーマンスベンチマーク——テストされていないコードは信頼できないコードであることを痛い経験から学んだからだ。AI Agentエコシステムはより初期の段階にある：意思決定の重要なワークフローにAgentをデプロイしているが、同等のテストインフラを持っていない。
このギャップは単なるツーリングの問題ではない。概念的な問題である。従来のテストは決定論的な契約を検証する：入力Xが与えられたら、関数はYを返さなければならない。Agent評価は確率的なポリシーを検証しなければならない：コンテキストCが与えられたとき、Agentは受容可能な分布Dの範囲内で意思決定を行い、ガバナンス制約Gを尊重し、品質Qのエビデンスを生成し、レイテンシ上限Lの範囲内でそのすべてを行うべきである。この多次元的な品質空間は、根本的に異なる評価フレームワークを必要とする。
Agentテストと従来のソフトウェアテストを区別する3つの性質がある：
| 次元 | 従来のソフトウェアテスト | Agent品質評価 |
| --- | --- | --- |
| 正確性 | 決定論的：完全な出力一致 | 分布的：受容可能な意思決定範囲 |
| 安全性 | 境界値検証、null チェック | 軌跡にわたる行動制約の検証 |
| パフォーマンス | スループット、レイテンシ（単一操作） | リソース制約下での意思決定品質 |
| 準拠性 | APIコントラクトの遵守 | ガバナンスGate呼び出し、エビデンス生成 |MARIA OS評価ハーネスは、次元ごとの透明性を保持しつつ、単一の複合品質スコアを生成する統一アーキテクチャを通じて、4つの次元すべてに対処する。
2. テストカテゴリ
2.1 正確性
正確性評価は、Agentが検証済みの参照結果と一致する意思決定を行うかどうかを測定する。正確性がバイナリであるユニットテストとは異なり、Agentの正確性はスペクトラム上に存在する。低リスクの経費報告を人間のレビューなしで承認するAgentは、ある組織コンテキストでは正しいかもしれないが、すべての経費にマネージャーの承認が必要な別の組織では正しくないかもしれない。
正確性は意思決定オラクル——テストスイート内の各シナリオに対する正しいアクションを規定する検証済み参照ポリシー——に対して相対的に定義する。オラクルはドメインエキスパートによって構築され、（コンテキスト、アクション）ペアを正確性ラベルにマッピングする意思決定テーブルとしてエンコードされる。
interface DecisionOracle {
scenarioId: string;
context: ScenarioContext;
expectedAction: AgentAction;
acceptableVariants: AgentAction[];
correctnessWeight: number; // importance of this scenario [0, 1]
}
function evaluateCorrectness(
agent: AgentUnderTest,
oracle: DecisionOracle[],
seed: number
): CorrectnessReport {
const prng = createPRNG(seed);
const results = oracle.map((scenario) => {
const agentAction = agent.decide(scenario.context, prng);
const isExactMatch = deepEqual(agentAction, scenario.expectedAction);
const isAcceptable = scenario.acceptableVariants.some(
(v) => deepEqual(agentAction, v)
);
return {
scenarioId: scenario.scenarioId,
correct: isExactMatch || isAcceptable,
exact: isExactMatch,
weight: scenario.correctnessWeight,
};
});
const weightedAccuracy =
results.reduce((sum, r) => sum + (r.correct ? r.weight : 0), 0) /
results.reduce((sum, r) => sum + r.weight, 0);
return { results, weightedAccuracy };
}2.2 安全性
安全性評価は、敵対的または曖昧な入力によって促された場合でも、Agentが有害と分類されるアクションを決して取らないことを検証する。安全性テストシナリオは、正しいアクションが直接実行ではなく、拒否、エスカレーション、またはGate呼び出しである境界条件を探索するよう設計されている。
安全性違反を3つの重大度レベルに分類する：S1（クリティカル）——不可逆的な損害を引き起こす、または法的制約に違反するアクション、S2（シリアス）——ガバナンスGateをバイパスする、または不完全なエビデンスを生成するアクション、S3（マイナー）——最適ではないが安全性不変量に違反しないアクション。ハーネスはS1違反に対してゼロトレランスポリシーを強制する：S1違反を1つでも生成したAgentは、他のすべてのスコアに関係なく安全性評価に失敗する。
2.3 パフォーマンス
パフォーマンス評価は、リソース制約——レイテンシバジェット、同時リクエスト負荷、劣化したインフラ条件——の下でのAgent意思決定品質を測定する。重要な洞察は、Agentのパフォーマンステストは単なる速度の問題ではないということである。それは優雅な劣化についての問題である。負荷時に高速だが誤った回答を返すAgentは、レイテンシバジェット内で品質閾値を満たせないときに正しく人間にエスカレーションするAgentよりも劣る。
interface PerformanceScenario {
concurrentRequests: number;
latencyBudgetMs: number;
infrastructureDegradation: "none" | "partial" | "severe";
expectedBehavior: "normal" | "graceful-degradation" | "escalation";
}
const PERFORMANCE_SCENARIOS: PerformanceScenario[] = [
{ concurrentRequests: 1, latencyBudgetMs: 500, infrastructureDegradation: "none", expectedBehavior: "normal" },
{ concurrentRequests: 50, latencyBudgetMs: 2000, infrastructureDegradation: "none", expectedBehavior: "normal" },
{ concurrentRequests: 200, latencyBudgetMs: 5000, infrastructureDegradation: "partial", expectedBehavior: "graceful-degradation" },
{ concurrentRequests: 500, latencyBudgetMs: 10000, infrastructureDegradation: "severe", expectedBehavior: "escalation" },
];2.4 ガバナンス準拠
ガバナンス準拠評価は、Agentが組織の意思決定アーキテクチャに正しく参加することを検証する。これには以下が含まれる：適切な意思決定ポイントで必要な責任Gateを呼び出すこと、スキーマ仕様を満たすエビデンスバンドルを生成すること、自律権限閾値を超える意思決定に対して承認ワークフローを尊重すること、すべてのアクションを監査可能性のためにMARIA座標でログに記録すること。
ガバナンス準拠はMARIA OS評価ハーネスにおいて最も独自性の高いテストカテゴリである——従来のソフトウェアテストに同等のものはない。セキュリティテストがソフトウェアが悪用されないことを検証するのに対し、ガバナンス準拠テストはAgentが組織のアカウンタビリティ構造に能動的に参加することを検証する。
3. 評価メトリクス
3.1 意思決定精度（DA）
意思決定精度は、評価シナリオセット全体にわたる正しい意思決定の加重割合を測定する。
DA = (\sum_{i=1}^{N} w_i \cdot \mathbb{1}[a_i \in A_i^{\text{correct}}]) / (\sum_{i=1}^{N} w_i)ここでw_iはシナリオiの重要度ウェイト、a_iはAgentのアクション、A_i^{correct}はオラクルによって定義された受容可能なアクションの集合である。指示関数はAgentのアクションが受容可能な集合に含まれるとき1を返す。
3.2 Gate準拠率（GCR）
Gate準拠率は、ガバナンス感度の高い意思決定ポイントのうち、Agentが必要な責任Gateを正しく呼び出した割合を測定する。
GCR = |\{ d \in D_{\text{gated}} : \text{gate}(d) = \text{gate}_{\text{required}}(d) \}| / |D_{\text{gated}}|D_gatedはGate呼び出しを必要とするすべての意思決定ポイントの集合であり、分子はAgentが正しいGateタイプ（人間参加型、承認ワークフロー、エビデンス収集など）を呼び出した意思決定をカウントする。
3.3 エビデンス品質スコア（EQS）
エビデンス品質スコアは、Agentが生成したエビデンスバンドルの完全性、追跡可能性、正確性を評価する。各エビデンスバンドルは3つのサブ次元にわたってスキーマ仕様に対してスコアリングされる：
EQS = \alpha \cdot \text{completeness}(E) + \beta \cdot \text{traceability}(E) + \gamma \cdot \text{correctness}(E)alpha + beta + gamma = 1 である。完全性は必要なフィールドがすべて存在するかを測定する。追跡可能性はエビデンスチェーンがMARIA座標を通じてソースデータまで遡れるかを測定する。正確性はエビデンスの内容が基礎となる意思決定コンテキストを正確に表現しているかを測定する。
3.4 負荷時レイテンシ（LUL）
負荷時レイテンシは、各パフォーマンスシナリオのレイテンシバジェットに対して正規化されたAgentのp95応答時間を測定する。
LUL = 1 - \text{min}(1, p_{95}(\text{latency}) / L_{\text{budget}})LULスコア1.0はAgentのp95レイテンシがゼロであることを意味する（理論的最大値）。スコア0.0はp95レイテンシがバジェットと完全に等しいか超過していることを意味する。負の値はゼロにクランプされる。
4. 複合Agentスコア
4つのメトリクスは、加重幾何平均を用いて単一の複合Agentスコア（CAS）に統合される。幾何平均は、いずれかの次元における壊滅的な失敗が他の次元の優秀さによって隠されないことを保証する。
CAS = DA^{w_1} \cdot GCR^{w_2} \cdot EQS^{w_3} \cdot LUL^{w_4}w_1 + w_2 + w_3 + w_4 = 1 である。MARIA OSにおけるデフォルトのウェイトは w_1 = 0.35（正確性）、w_2 = 0.30（ガバナンス）、w_3 = 0.20（エビデンス）、w_4 = 0.15（パフォーマンス）である。幾何平均は、いずれかの因子がゼロであれば複合スコアもゼロになるという重要な性質を持つ——ガバナンス準拠に完全に失敗したAgentは、意思決定精度に関係なくCASがゼロとなる。
CASのウェイトはエンジニアリングパラメータではなく、組織ポリシーである。ガバナンス準拠を生の精度よりも優先する企業は、w_1に対してw_2を増やすべきである。MARIA OSでは、ウェイト変更はエビデンスによる正当化を伴う意思決定パイプラインを通過することが要求され、評価基準自体がガバナンスされることを保証する。定理（単調応答性）。 複合Agentスコアは、他のすべてのメトリクスを一定に保った場合、いずれか個別のメトリクスの真の改善に対して単調非減少である。
証明。 CAS = DA^{w_1} GCR^{w_2} EQS^{w_3} * LUL^{w_4} とする。DAがDA_0からDA_1に改善され、DA_1 > DA_0 >= 0、他のすべてのメトリクスが一定の場合を考える。CAS_1 / CAS_0 = (DA_1 / DA_0)^{w_1} > 1 となる。DA_1 / DA_0 > 1 かつ w_1 > 0 だからである。したがって CAS_1 > CAS_0。この議論はすべてのメトリクスについて対称的に成立する。QED。
5. ハーネスアーキテクチャ
評価ハーネスは、パイプラインアーキテクチャに配置された4つのコンポーネントで構成される。
5.1 テストランナー
テストランナーは決定論的シーディングによるシナリオ実行を制御し、再現性を保証する。各評価実行は (suite_id, seed, timestamp) の三つ組で識別され、実行トレース全体を一意に決定する。ランナーはシナリオ提示の決定論的な順序を維持しつつ、複数のAgentインスタンスにわたる並列実行をサポートする。
interface EvaluationRun {
suiteId: string;
seed: number;
timestamp: Date;
coordinate: MARIACoordinate; // scope of evaluation
agent: AgentUnderTest;
scenarios: EvaluationScenario[];
config: RunConfig;
}
interface RunConfig {
parallelism: number;
timeoutMs: number;
failFast: boolean; // stop on first S1 safety violation
recordTraces: boolean;
}
async function executeRun(run: EvaluationRun): Promise<RunResult> {
const prng = createPRNG(run.seed);
const scenarios = shuffleWithSeed(run.scenarios, prng);
const results: ScenarioResult[] = [];
for (const batch of chunk(scenarios, run.config.parallelism)) {
const batchResults = await Promise.all(
batch.map((s) => executeScenario(run.agent, s, prng))
);
results.push(...batchResults);
if (run.config.failFast && batchResults.some((r) => r.safetyLevel === "S1")) {
return { status: "failed-safety", results, abortedAt: results.length };
}
}
return { status: "completed", results };
}5.2 シナリオジェネレーター
シナリオジェネレーターはドメインテンプレートからパラメータ化されたテストケースを生成する。各テンプレートは意思決定コンテキストスキーマ、可変パラメータの集合、および各パラメータ組み合わせに対するオラクル検証済みの正しいアクションを定義する。テンプレートはMARIA座標で組織され、特定ドメインに対するターゲットテスト生成を可能にする。
ジェネレーターは3つのモードをサポートする：網羅的（すべてのパラメータ組み合わせ）、ランダム（指定シードによるモンテカルロサンプリング）、敵対的（既知のエッジケースと過去の失敗モードに偏ったパラメータ選択）。
5.3 オラクルコンパレーター
オラクルコンパレーターはAgent出力を検証済み参照意思決定に対して評価する。単純な等価性チェックとは異なり、コンパレーターは部分的正確性をサポートする——Agentの意思決定が部分的に正しい場合を認識する（例：正しいアクションだが不完全なエビデンス、正しいエスカレーションだが誤ったGateレベルへのエスカレーション）。
コンパレーターは各シナリオに対して多次元の正確性ベクトルを生成し、これがセクション3で説明したメトリクス計算に供給される。
5.4 リグレッションディテクター
リグレッションディテクターは評価実行間で統計的に有意な品質劣化を識別する。CASスコアのローリングベースラインを維持し、仮説検定を適用して回帰を検出する。
H_0: \mu_{\text{current}} \geq \mu_{\text{baseline}} \quad \text{vs} \quad H_1: \mu_{\text{current}} < \mu_{\text{baseline}}有意水準 alpha = 0.01 の片側t検定を適用する。H_0が棄却された場合、リグレッションディテクターはMARIA OS意思決定パイプラインを通じてデプロイメントをブロックするアラートを発行する。ディテクターはメトリクスごとの回帰も追跡し、単一次元の劣化により複合スコアが低下した場合のターゲット調査を可能にする。
6. MARIA座標に基づくテストスコーピング
評価ハーネスの最も強力な機能の一つは、MARIA座標系との統合である。テストは組織階層の任意のレベルでスコーピングできる：
// 単一Agentの評価
const agentScope: TestScope = {
coordinate: "G1.U2.P3.Z1.A5",
level: "agent",
inheritParentScenarios: true,
};
// ゾーン内の全Agentを評価
const zoneScope: TestScope = {
coordinate: "G1.U2.P3.Z1.*",
level: "zone",
includeInterAgentScenarios: true,
};
// ユニバース全体を評価
const universeScope: TestScope = {
coordinate: "G1.U2.*.*.*",
level: "universe",
includeCrossZoneScenarios: true,
includeCrossPlanetScenarios: true,
};階層的スコーピングにより、テストスイートは自然に合成される。ゾーンレベルの評価にはそのゾーン内のAgentに対するすべてのAgentレベルシナリオに加え、Agent間協調シナリオが含まれる。ユニバースレベルの評価にはすべてのゾーンレベル評価に加え、ゾーン間インタラクションシナリオが含まれる。この合成可能性により、個別のテストスイートメンテナンスを必要とせずに、組織階層のすべてのレベルで品質が検証される。
7. Agentスコアリングの形式的フレームワーク
評価フレームワークをタプル (S, A, O, M, C) として形式化する：
- S = シナリオ空間、すべての可能な評価コンテキストの集合
- A = アクション空間、すべての可能なAgent応答の集合
- O = オラクル関数、O: S -> P(A)、シナリオを受容可能なアクションの集合にマッピング
- M = メトリクス関数、M = {DA, GCR, EQS, LUL}
- C = 合成関数、C: R^4 -> R、メトリクススコアを複合スコアにマッピング
Agent piはシナリオをアクション上の確率分布にマッピングする確率的ポリシー pi: S -> Delta(A) である。メトリクスmの下でのAgent piの期待品質は：
Q_m(\pi) = \mathbb{E}_{s \sim \mathcal{S}, a \sim \pi(s)}[m(a, O(s))]複合品質は次のようになる：
Q(\pi) = C(Q_{DA}(\pi), Q_{GCR}(\pi), Q_{EQS}(\pi), Q_{LUL}(\pi))定理（分離可能性）。 複合品質 Q(pi) は、メトリクス関数がシナリオコンテキストを条件として条件付き独立である場合に限り、独立したメトリクスごとの評価に分解できる。
この分離可能性の性質は実用的な評価にとって極めて重要である：正確性、安全性、パフォーマンス、ガバナンスのテストを独立に実行し結果を合成できることを意味し、すべてのテストシナリオが4つの次元すべてを同時に評価する必要がなくなる。
8. 継続的評価パイプライン
評価ハーネスは一回限りのツールではない——MARIA OSデプロイメントワークフローに統合された継続的パイプラインとして動作する。
interface ContinuousEvaluationPipeline {
// トリガー条件
triggers: {
onAgentUpdate: boolean; // Agentコード変更時に再評価
onOracleUpdate: boolean; // オラクル更新時に再評価
scheduled: CronExpression; // 定期的な再評価（例：毎日）
onIncident: boolean; // 本番インシデント後に再評価
};
// パイプラインステージ
stages: [
"scenario-generation", // テストシナリオの生成またはリフレッシュ
"agent-execution", // シナリオに対するAgent実行
"oracle-comparison", // 出力のオラクル比較
"metric-calculation", // DA, GCR, EQS, LUL の計算
"regression-detection", // ベースラインとの統計的比較
"report-generation", // 人間可読レポートの生成
"gate-decision", // 合格/不合格/エスカレーション判定
];
// 出力
result: "deploy" | "block" | "escalate-to-human";
}パイプラインは4つのトリガーで自動実行される：Agentコード更新、オラクル仕様更新、スケジュール間隔（デフォルト：毎日）、本番インシデントレポート。各実行は複合スコア、メトリクスごとの内訳、回帰分析、デプロイメント推奨を含む評価レポートを生成する。
Gate判定ステージは特に重要である：評価結果をMARIA OS意思決定パイプラインを通じてガバナンスアクションに変換する。すべての閾値を通過したAgentは自動デプロイメント承認を受ける。S1安全性シナリオに失敗したAgentは自動的にブロックされる。中間的なケース——例えば、許容分散内である可能性のある僅かなGCR回帰——は責任Gateシステムを通じて人間のレビュアーにエスカレーションされる。
9. 従来のソフトウェアテストとの比較
以下の表は、従来のソフトウェアテストとMARIA OS評価ハーネスアプローチの主要な違いを要約する：
| 側面 | 従来のテスト | MARIA OS 評価ハーネス |
| --- | --- | --- |
| 正確性基準 | 完全な出力一致 | オラクル検証済み受容範囲 |
| テスト決定論性 | 完全に決定論的 | シードPRNGによる決定論的 |
| 安全性検証 | ネガティブテスト（不正入力） | 行動軌跡分析 |
| パフォーマンステスト | 負荷テスト（スループット/レイテンシ） | 制約下品質評価 |
| 準拠テスト | N/Aまたは手動監査 | 自動ガバナンスGate検証 |
| テストスコーピング | パッケージ/モジュール階層 | MARIA座標階層 |
| 回帰検出 | Diffベース（合格/不合格） | 統計的仮説検定 |
| 評価出力 | 合格/不合格 | 次元内訳付き複合スコア |
| 継続的統合 | コード変更時 | コード変更+オラクル変更+スケジュール+インシデント時 |
| ガバナンス統合 | なし | 意思決定パイプライン完全統合 |最も根本的な違いは哲学的なものである。従来のテストは「コードが仕様通りに動作するか？」と問う。評価ハーネスは「Agentは組織が支持するであろう意思決定を、組織が承認したプロセスを通じて、組織が監査できるエビデンスとともに行うか？」と問う。
10. シナリオ設計の原則
効果的な評価には適切に設計されたシナリオが必要である。Agent評価におけるシナリオ設計の5つの原則を提案する：
原則1：量より網羅性。 4つのテストカテゴリすべてとすべてのMARIA座標レベルをカバーする500シナリオのテストスイートは、Agentレベルの正確性のみをテストする50,000シナリオのスイートよりも価値がある。シナリオジェネレーターは量的拡大の前に次元的網羅性を優先すべきである。
原則2：敵対的シナリオは必須。 すべてのテストスイートは既知の失敗モードを探索する敵対的シナリオを含まなければならない：曖昧なコンテキスト、矛盾する制約、リソース圧力、カスケードエラー条件。シナリオの少なくとも20%は敵対的であるべきである。
原則3：オラクルメンテナンスはガバナンス。 オラクルは組織の判断を表す。オラクル検証済みの正しいアクションの変更は組織ポリシーの変更であり、エビデンスによる正当化を伴う意思決定パイプラインを通過しなければならない。
原則4：シナリオの来歴。 すべてのシナリオはそのソースまで追跡可能でなければならない——テンプレートから生成されたか、本番インシデントから導出されたか、ドメインエキスパートによって設計されたか。来歴は、Agentが特定のシナリオに失敗した場合の根本原因分析を可能にする。
原則5：時間的妥当性。 シナリオには有効期限がある。組織ポリシーは変化し、ドメイン知識は進化し、受容可能な意思決定範囲はシフトする。ハーネスはシナリオの妥当性ウィンドウを追跡し、陳腐化したシナリオにレビューのフラグを立てる。
11. 実装上の考慮事項
評価ハーネスは本番環境とは分離された隔離環境で実行される。テスト対象のAgentインスタンスは本番トラフィックを受信せず、本番データにアクセスできない。ハーネス環境は本番MARIA OS構成をミラーリングするが、シナリオジェネレーターによって生成された合成データを使用する。この隔離により、評価が本番運用に影響を与えることがなく、評価結果が本番状態によって汚染されることもない。主要な実装の詳細は以下の通りである：
決定論的シーディング。 評価パイプラインにおけるすべてのランダム性のソースは、シードPRNG（mulberry32、MARIA OS Civilization Engineと一貫）によって制御される。これは評価実行が完全に再現可能であることを意味する：同じ (suite_id, seed, timestamp) の三つ組が与えられれば、ハーネスは同一の結果を生成する。
順序保証を伴う並列実行。 バッチ内のシナリオはパフォーマンスのために並列実行されるが、バッチは早期終了動作を可能にするために逐次実行される。決定論的シャッフルにより、位置依存バイアスを回避しつつ、シナリオの順序が実行間で一貫することが保証される。
エビデンス収集。 ハーネスはすべてのシナリオについて完全な実行トレースを記録する。Agent内部状態（利用可能な場合）、意思決定根拠ログ、Gate呼び出し、エビデンスバンドルが含まれる。これらのトレースはメトリクス計算と評価後のデバッグの二つの目的に使用される。
ベースライン管理。 リグレッションディテクターはCASスコアの30日間ローリングベースラインを維持する。ベースラインはAgentが改善するに従い自動的に更新されるが、更新は非対称である：改善はベースラインを引き上げるが、回帰はベースラインを引き下げない。このラチェット機構により、品質は時間の経過とともに改善のみが可能となる。
12. 結論と今後の方向性
MARIA OS評価ハーネスは、Agent品質を不透明で主観的な評価から、透明で再現可能なエンジニアリング測定へと変革する。4つのテストカテゴリ、4つの主要メトリクス、形式的な複合スコアリングフレームワーク、そしてMARIA OSガバナンスインフラと統合された継続的評価パイプラインを定義することで、ハーネスは体系的なAgent品質管理の基盤を提供する。
本論文の主要な貢献は以下の通りである：
1. 正確性、安全性、パフォーマンス、ガバナンス準拠をカバーする、Agent品質評価のための形式的テスト分類体系 2. 数学的定義と測定プロトコルを持つ4つの具体的メトリクス（DA、GCR、EQS、LUL） 3. 単調応答性と分離可能性の性質が証明された複合スコアリングフレームワーク 4. 統計的回帰検出とガバナンス統合を備えた継続的評価アーキテクチャ 5. 個別Agentからユニバース全体までの階層的品質検証を可能にするMARIA座標に基づくテストスコーピング
今後の研究課題には以下が含まれる：マルチAgent協調品質の評価へのハーネス拡張（個別Agent品質だけでなく）、オラクル構築のための転移学習アプローチの開発（新しい評価スイート作成に必要なドメインエキスパートの労力の削減）、そしてCivilization Engineとの統合による競争的マルチ国家シミュレーション環境でのAgent行動評価。
本研究の最も深い洞察は、評価インフラはガバナンスインフラとは別物ではなく、ガバナンスインフラそのものであるということだ。組織が測定するメトリクスの選択、受容のために設定する閾値、評価基準を更新するプロセス——これらすべてが組織の価値観の表現である。MARIA OS評価ハーネスは、これらの選択を明示的に、監査可能に、そしてAgent自体を管理するのと同じ意思決定パイプラインによってガバナンスされるものとする。