要旨
AI Agentの時代における本質的な問いは、「モデルはどれほど賢いか」ではなく、「知能はどの位相に入り、どの位相から戻れなくなるか」である。単発応答の品質、ベンチマークスコア、RAGの検索精度、プロンプトの巧拙だけでは、長期稼働するAgent群を説明できない。Agentは目的、記憶、人格、権限、品質、レイテンシ、費用、責任境界を持つ動的システムであり、時間とともに状態空間を移動する。
本稿では、Dynamic Harnessを「Agent runtimeの位相空間を観測し、評価し、軌道修正するRuntime Governance Layer」として定義する。添付草稿で示された「知能を生成する時代から、知能を運営する時代へ」という問題意識を、bonginkan/virtual-talentのProducer AI実装から得た具体的な設計知見と接続する。virtual-talentでは、Producer jobをruntime episodeへ正規化し、failure taxonomy、dynamic scorecard、repair proposal、controlled self-healingへ接続する一連のハーネスが実装されている。これは単なるテストではなく、失敗を次の開発チケット、修復PR、隔離、再実行、人間承認へ変換する運営ループである。
MARIA OSにおける次の研究課題は、この運営ループを企業、Agentic Company、そしてAgentic Societyの位相制御へ拡張することである。つまり、AI組織が「安定運用」「品質劣化」「記憶ドリフト」「権限漏れ」「再試行ループ」「自己改善暴走」のどの吸引領域にいるのかを観測し、壊れる前に軌道を変える。これが、位相レベルのハーネスである。
1. ハーネスはテストから制御へ移行する
ソフトウェア開発におけるハーネスは、もともとテスト対象を囲い、決められた入力、環境、検証条件の中で実行するための枠組みだった。関数に入力を与え、期待値と比較する。UIを開き、クリックし、表示を検証する。APIを叩き、スキーマとステータスコードを確認する。これは重要であり、これからも不要にはならない。
しかしAgent runtimeでは、ハーネスの意味が変わる。Agentは一度の関数呼び出しではない。記憶を読み、ツールを選び、他のAgentへ引き継ぎ、再試行し、失敗を隠し、時にはユーザーに見えない内部判断を行う。つまり、検証対象は「出力」ではなく「軌道」になる。
従来のテストは、ある点での正しさを確認する。一方、Dynamic Harnessは、状態空間の中でシステムがどの方向へ流れているかを観測する。今日の出力が合格でも、retry rateが上がり、identity driftが増え、advisoryの効きが悪化し、human correctionが増えているなら、システムはすでに不安定な位相へ入り始めている。
この見方に立つと、ハーネスは単なる品質ゲートではなく、制御理論、観測可能性、自己修復、運用ガバナンスの交点に置かれる。Agentic CompanyのOSには、こうしたハーネスがカーネルに近い位置で必要になる。
2. virtual-talentから得た実装知見
bonginkan/virtual-talentのProducer AIでは、すでに静的ハーネスと動的ハーネスが重層的に実装されている。公開LPだけを見ると、バーチャルタレント、Studio、Producer、動画生成、商用品質のプロダクトに見える。しかし内部構造としては、多数の品質ハーネス、runtime episode抽出、失敗分類、scorecard、repair proposal、self-healing境界が走っている。
特に重要なのは、Producer jobを単なる成功/失敗として扱わず、runtime episodeとして正規化している点である。episodeには、ユーザー意図、normalized intent、stage、Agent、quality gate、advisory、asset、retry、hold、failure hint、durationが集約される。これにより、品質、UX、Provider、Analyze、Agent責務、開発改善を同じ単位で語れる。
| Dynamic Harness要素 | virtual-talentでの実体 | MARIA OSへの拡張 |
|---|---|---|
| Runtime episode | Producer job eventsを正規化 | 業務判断、会議、監査、営業、開発をepisode化 |
| Failure taxonomy | intent_mismatch、identity_drift、retry_loopなど | 組織判断、責任境界、Memory drift、Goal mutationへ拡張 |
| Owner mapping | producer_planning、studio_ux、provider_runtimeなど | Planet、Zone、Agent、Human Gate、Executive Gateへ拡張 |
| Dynamic scorecard | completion、quality pass、retry、advisory usage | 事業KPI、責任KPI、信頼KPI、文明整合KPIへ拡張 |
| Repair proposal | scopeと検証コマンド付きPR候補 | 自律修復、承認付き修復、組織プロトコル更新へ拡張 |
| Controlled self-healing | quarantine、rerun、draft PR、人間承認 | 高リスク自律性の停止、低リスク修復の自動化へ拡張 |
ここでの設計は、添付草稿がいう「知能運営OS」をかなり具体的にしている。観測点があり、失敗分類があり、修復候補があり、高リスクscopeでは人間承認を要求する。つまり、ハーネスはテスト結果を出すだけでなく、次の行動を生成している。
この「次の行動を生成する」性質が、Dynamic Harnessを従来の評価ハーネスから分ける。評価ハーネスは測る。Dynamic Harnessは、測ったあとに状態を変える。
3. 位相空間としてのAgent Runtime
位相空間とは、システムの状態を表す変数群によって構成される空間である。物理なら位置と速度、生態系なら個体数と資源量、経済なら価格と需要と供給、Agent runtimeなら目的、記憶、信頼、品質、権限、レイテンシ、費用、責任境界が状態変数になる。
MARIA OSでは、Agent runtimeの状態を次のように置く。
G_t: goal coherence M_t: memory integrity I_t: identity continuity Q_t: quality state L_t: latency pressure C_t: cost pressure R_t: responsibility demand A_t: authority boundary $$
ここで重要なのは、個々の変数が独立していないことである。Latency pressureが上がると、Agentはショートカットを選びやすくなる。Memory integrityが下がると、identity continuityも崩れる。Authority boundaryが曖昧になると、responsibility demandが見えなくなる。Cost pressureが上がると、retry policyやprovider selectionが変わり、quality stateが揺れる。
Dynamic Harnessは、この状態ベクトルx_tを直接完全に観測できるわけではない。実際に観測できるのは、ログ、生成物、ユーザー修正、Gate結果、Agent handoff、ツール呼び出し、レイテンシ、失敗メッセージ、承認履歴などの断片である。したがって、ハーネスは観測モデルでもある。
H_t(y_{0:t}) -> u_t $$
y_tは観測データ、Oは観測関数、epsilon_tはノイズである。H_tがDynamic Harnessであり、過去から現在までの観測を受け取り、制御入力u_tを出す。u_tは、rerun、quarantine、repair PR、human approval、policy rewrite、memory pruning、Agent reassignmentなどである。
このモデル化によって、ハーネスは「テストを実行するもの」ではなく「状態推定と制御入力を出すもの」になる。
4. 静的ハーネスの限界
静的ハーネスは必要である。型が通るか、API契約が壊れていないか、UI hookが存在するか、tenant境界があるか、スキーマがドリフトしていないか、品質ゲートが呼ばれているか。これらを確認しないAgentic systemは、そもそも運用に耐えない。
ただし、静的ハーネスは「現在の契約」を見る。Dynamic Harnessが見るのは「契約が時間とともにどのように壊れ始めているか」である。
例えば、ある品質ゲートは通っている。しかしユーザー修正率がじわじわ増えている。動画生成は成功している。しかしprovider retryが増え、平均時間が伸び、失敗時のhold理由が曖昧になっている。Studio UIは表示されている。しかしユーザーは同じ情報不足を何度も言い直している。これらは静的契約違反ではないが、runtimeの位相は悪化している。
静的ハーネスが見るもの:
- 存在するか
- 型が合うか
- 閾値を満たすか
- 契約を破っていないか
- 期待する画面が描画されるか
Dynamic Harnessが見るもの:
- どの品質が悪化しているか
- どの失敗が再発しているか
- どのownerに負荷が集中しているか
- どのadvisoryが改善ではなく劣化を生んでいるか
- どの変更を自動修復してよいか
- どの変更は人間承認なしに動かしてはいけないか
静的ハーネスは境界線であり、Dynamic Harnessは操縦桿である。MARIA OSには両方が必要である。
5. Dynamic Harnessの5レイヤー
virtual-talentの設計をMARIA OSの抽象レイヤーに置き直すと、Dynamic Harnessは少なくとも5層で構成される。
5.1 Runtime Episode Layer
第一層はepisode化である。Agentの実行を、ログの羅列ではなく、分析可能な単位へ正規化する。業務Agentであれば、1つの請求書処理、1つの監査判断、1つの営業提案、1つのコード修正、1つの採用判断がepisodeになる。
episodeには、目的、入力、判断経路、使用した記憶、使用したツール、関与Agent、Gate、証跡、失敗、修正、最終状態を入れる。ここで重要なのは、成功episodeも保存することである。失敗だけを保存すると、改善の比較対象が消える。Dynamic Harnessは「悪い状態」だけでなく「良い状態の軌道」も学習する必要がある。
5.2 Failure Taxonomy Layer
第二層は失敗分類である。分類されない失敗は改善できない。失敗を「なんか悪い」ではなく、intent mismatch、brief under-specified、memory drift、identity drift、tool misuse、latency regression、tenant boundary risk、schema drift、governance bypassのように分類する。
分類にはownerが必要である。ownerのない失敗は、誰の改善対象にもならない。virtual-talentではproducer planning、studio UX、visual quality、video quality、provider runtime、analyze governance、platform contractなどのownerに写像している。MARIA OSでは、これをPlanet、Zone、Agent、Human Gate、Executive Gate、Knowledge Layerへ広げる。
5.3 Dynamic Scorecard Layer
第三層はscorecardである。ただし静的スコアではない。時間軸を持つscorecardである。completion rate、quality pass rate、retry rate、human correction rate、advisory lift、owner別failure count、平均duration、release blockerを追う。
重要なのは、単一スコアにしすぎないことである。複合スコアは経営判断には便利だが、修復には分解可能性が必要である。Dynamic Harnessでは、総合スコアと同時に「どの軸が吸引領域を変えているか」を見る。
5.4 Repair Proposal Layer
第四層は修復提案である。失敗分類とscorecardを、具体的なscope、検証コマンド、PR本文、優先度へ変換する。ここでDynamic Harnessは開発プロセスへ接続される。
重要なのは、大きな抽象タスクを出さないことだ。「品質を改善する」ではなく、「group_relation_weakが増えているため、brief extractionとrelationship gateをこのscopeで修正し、このハーネスで確認する」のように、実装可能な単位へ落とす。
5.5 Controlled Self-Healing Layer
第五層は自己修復の境界である。すべてを自動化してはいけない。むしろDynamic Harnessの価値は、自動化してよいものと、止めるべきものを分けることにある。
低リスクなprovider runtimeの再検証、tenant単位のadvisory quarantine、既知のretry loop抑制は自動化できる可能性がある。一方で、schema、deploy、global insight、core prompt、tenant boundary、権限境界に触れる変更は、人間承認を要求すべきである。自己修復は、自己暴走と紙一重である。したがって、自己修復ハーネスには、必ず停止条件と承認条件が必要になる。
6. Phase-level Harnessとは何か
Phase-level Harnessとは、単一の失敗ではなく、システムが入っている位相を検出し、制御するハーネスである。ここでいう位相とは、「同じ種類の挙動が自己強化される状態領域」を指す。
Agent runtimeには、いくつかの典型的な吸引領域がある。
| 位相 | 症状 | 放置した場合 | ハーネス制御 |
|---|---|---|---|
| Stable production | 品質、速度、修正率が安定 | 通常運用 | 軽量監視 |
| Retry loop | 同じ失敗を繰り返す | コスト増、遅延、UX悪化 | loop suppression、hold、owner routing |
| Identity drift | 人格、顔、文体、役割が揺れる | 信頼低下、再生成増加 | memory pruning、identity gate、reference lock |
| Goal mutation | 元の目的からズレる | 意図しない最適化 | goal consistency check、human gate |
| Governance leak | 権限や責任境界が漏れる | 監査不能、法務リスク | fail closed、approval escalation |
| Latency freeze | 遅延が判断品質を壊す | timeout、雑な回答 | budgeted fallback、degradation policy |
| Advisory poisoning | 学習知見が逆効果になる | じわじわ品質悪化 | ON/OFF評価、quarantine |
これらの位相は、単発のテストでは見えない。retry loopは1回の失敗ではなく、失敗の反復である。identity driftは1枚の画像ではなく、連続生成の中で起きるズレである。Goal mutationは1つの回答ではなく、長期的な目的関数の変形である。Governance leakは1つの権限チェックではなく、責任境界の連鎖的な曖昧化である。
Phase-level Harnessは、こうした状態を早期に検出するために、点ではなく軌跡を扱う。episode列を見て、差分を見て、勾配を見て、再発を見て、ownerの偏りを見る。そして、状態が危険な吸引領域へ入る前に、制御入力を入れる。
7. 動的ハーネスとMAPE-Kループ
Dynamic Harnessは、古典的な自律運用モデルであるMAPE-Kループと近い。Monitor、Analyze、Plan、Execute、Knowledgeの頭文字であり、自己適応システムの基本形として知られている。
MARIA OSで言い換えると、次のようになる。
| MAPE-K | Dynamic Harness | MARIA OSでの意味 |
|---|---|---|
| Monitor | Runtime episode extraction | Agent、Memory、Gate、Evidenceを観測 |
| Analyze | Failure taxonomy、scorecard | 位相、owner、severity、勾配を推定 |
| Plan | Repair proposal | scope、検証、承認条件を生成 |
| Execute | Controlled self-healing | rerun、quarantine、draft PR、human gateを実行 |
| Knowledge | Governance memory | 失敗、修復、効果測定を再利用可能な知識へ保存 |
ただし、Agentic systemではMAPE-Kをそのまま適用できない。なぜなら、制御対象が単なるサーバーやリソースではなく、意味を生成する知能だからである。Agentは「何を目的としているか」を持つ。記憶を持つ。言語を使って人間を説得する。ツールを呼ぶ。したがって、MonitorはCPUやメモリだけでは足りず、Goal、Memory、Identity、Authorityを含める必要がある。
この点で、Dynamic HarnessはAI時代のMAPE-K拡張である。知能を運用するための自己適応ループであり、MARIA OSのRuntime Governance Kernelになる。
8. 位相制御の数理モデル
Dynamic Harnessを研究対象として扱うには、数理的な形式化が必要である。最小モデルは、状態、観測、制御、遷移、コストで構成される。
y_t = O(x_t) + \epsilon_t
u_t = H(y_{0:t}, p_t) $$
x_tはAgent runtimeの真の状態、u_tはハーネスが与える制御入力、w_tは外部環境変動、y_tは観測、p_tはポリシーである。Fはruntimeの遷移関数、Oは観測関数、HはDynamic Harnessである。
制御の目的は、品質を最大化することだけではない。むしろ、危険な位相へ入らないこと、責任境界を破らないこと、学習による改善がadvisory poisoningを起こさないこと、自己修復が自己暴走しないことを同時に満たす必要がある。
subject to: R_t \leq R_{max} A_t \in SafeAuthority P(critical\_failure) < \delta $$
D_qは品質劣化、D_gは目的一貫性のズレ、D_mは記憶ドリフト、D_lはレイテンシ劣化、C(u_t)は制御コストである。R_tは責任需要、A_tは権限境界である。ここで最適化は、単なる品質最大化ではなく、ガバナンス制約付きの安定化問題になる。
このモデルは、制御理論、異常検知、因果推論、プロセスマイニング、強化学習、ランタイム保証の交点にある。特に重要なのは、Agent runtimeでは「行動が正しいか」だけでなく、「行動を正しくするための制御が正当か」を検証しなければならない点である。
9. MARIA OSでの実装青写真
MARIA OSにDynamic Harnessを組み込む場合、最小実装は次の順序になる。
9.1 Episode Store
まず、全ての重要なAgent actionをepisodeとして保存する。Decision Scanner、Workflow Scanner、Audit Universe、Sales Universe、AI Office、CEO OS、Executive Board OSの各runtimeで、共通のepisode schemaを持つ。
episodeはMARIA座標を持つ。例として、G1.U2.P3.Z1.A5のように、どのGlobal、Universe、Planet、Zone、Agentの出来事かを記録する。これは単なる監査ラベルではない。位相空間のどの局所領域で変化が起きているかを示す座標である。
9.2 Failure Taxonomy Registry
次に、失敗分類を共通化する。業務領域ごとに固有の失敗はあるが、上位分類は共通にできる。Goal drift、Memory drift、Authority leak、Evidence gap、Tool misuse、Loop risk、Latency pressure、Human correction overload、Responsibility mismatchなどである。
各failureには、severity、confidence、owner、user visible、suggested action、suggested verificationを持たせる。これにより、失敗はログではなく、運用可能なオブジェクトになる。
9.3 Dynamic Scorecard
次に、時間軸を持つscorecardを作る。短期の状態だけでなく、移動平均、悪化勾配、再発頻度、owner別集中、修復後の改善差分を持つ。
特に重要なのは、修復後の差分である。Dynamic Harnessは修復提案を出すだけでは足りない。その修復が本当に位相を安定側へ戻したかを評価する必要がある。これはA/Bテストやcounterfactual evaluationの領域に近い。
9.4 Repair Proposal Generator
scorecardから、修復候補を生成する。PR候補、docs更新、Gate追加、Memory TTL変更、prompt constraint追加、routing policy変更、Agent retraining、human approval policy変更などである。
ここで重要なのは、提案に必ず検証コマンドを含めることである。検証できない修復提案は、運用上の負債になる。
9.5 Controlled Self-Healing
最後に、低リスク領域だけを自動化する。高リスクscopeでは人間承認を必須にする。MARIA OSでは、この承認も責任Gateとして扱われ、誰が、なぜ、どの証跡で許可したかを残す。
10. Agentic Societyにおけるハーネス
添付草稿の重要な主張は、AGIの本質が単一モデルではなく「継続存在する知能」にあるという点である。この見方は、Agentic Societyの運営に直結する。
Agentが企業、教育、医療、金融、行政、研究、創作、公共サービスに入り込むと、社会は多数のAgent runtimeが相互作用する場になる。ここでは、個別Agentの品質だけでは不十分である。Agent同士の相互作用、制度との接続、人間のインセンティブ、記憶の共有、責任の分配、価値観の更新が問題になる。
Dynamic Harnessは、この社会的runtimeの観測層になる。個別Agentを監視するだけでなく、Agent集団がどの位相に入っているかを監視する。
- 市場Agentが同じシグナルに過剰反応していないか
- 採用Agentが過去の偏りを増幅していないか
- 教育Agentが学習者を快適な領域に閉じ込めていないか
- 医療Agentが説明責任を低レイヤーへ押し流していないか
- 開発Agentがテストを通すためだけの変更を学習していないか
- 経営Agentが短期KPIを文明整合性より優先していないか
これは、倫理の問題であると同時に、観測と制御の問題でもある。価値観は文章で宣言するだけでは実行されない。価値観は、どの状態で止めるか、どの状態で人間へ戻すか、どの状態で学習を隔離するかというruntime policyとして実装される。
11. 研究課題
Dynamic Harnessには、まだ多くの研究課題が残っている。
第一に、観測可能性である。Agentの内部状態は完全には見えない。したがって、ログ、出力、修正、ツール使用、Memory参照、Gate結果から状態を推定する必要がある。これは部分観測マルコフ決定過程に近い問題である。
第二に、因果性である。品質が上がったとして、それはadvisoryの効果なのか、prompt改善の効果なのか、provider変更の効果なのか、偶然なのかを分ける必要がある。Dynamic Harnessには、単なる相関ではなく、修復の因果効果を推定する仕組みが必要になる。
第三に、安定性である。自己修復するシステムは、それ自体が不安定化要因になる。修復提案、自己隔離、再実行、policy rewriteが過剰に走ると、runtimeは制御振動を起こす。したがって、Lyapunov安定性や制御入力の上限、cooldown、承認Gateが必要になる。
第四に、トポロジーである。Agent runtimeの状態空間は高次元であり、単純な平均値では位相変化を捉えられない。Persistent homologyやグラフスペクトル、クラスタ遷移、異常な連結成分の検出は、位相レベルのハーネスにとって有望である。
第五に、社会的正当性である。Dynamic Harnessは自律性を制御するため、誰がハーネスを設計し、誰が閾値を決め、誰が自動修復を許可するのかが問題になる。これは技術設計だけではなく、制度設計である。
12. 結論: 知能を壊さず運営するためのOS
AGI時代の競争軸は、モデルサイズやベンチマークだけでは終わらない。長期稼働するAgent群を、どれだけ壊さず、どれだけ自己修復させ、どれだけ責任境界を維持しながら運営できるかが中核になる。
Dynamic Harnessは、そのためのRuntime Governance Layerである。静的ハーネスが契約を守るなら、Dynamic Harnessは位相を制御する。静的ハーネスがテストを通すなら、Dynamic Harnessは失敗を次の改善へ変換する。静的ハーネスが境界線なら、Dynamic Harnessは操縦桿である。
virtual-talentのProducer AIで見えているepisode、failure taxonomy、dynamic scorecard、repair proposal、controlled self-healingは、MARIA OSにとって重要な実装証拠である。これを企業OSへ、さらにAgentic Society Runtimeへ拡張することで、MARIA OSは単なるAgent管理ツールではなく、知能運営OSになる。
人類は、知能を作る時代から、知能を運営する時代へ移行している。その時代に必要なのは、賢いAgentだけではない。Agentの位相空間を観測し、危険な吸引領域を検出し、責任ある制御入力を入れられるハーネスである。
知能を壊さず運営できるか。その問いへの実装上の答えが、Dynamic Harnessであり、MARIA OSである。