Dynamic Workflow Agent監視Harness：安全な業務Agentを量産する方法

要旨

Dynamic Workflow AgentはMARIA OSの業務実行層である。GoalをWorkflow Graphへ変換し、AgentやToolへtaskを振り分け、例外へ対応し、Evidenceを残し、承認を要求し、次回WorkflowをMemoryから改善する。重要なのは、これは単なるPlannerではないという点である。Dynamic Workflow AgentはSelf-Evolving Company OS内で稼働する、監視可能な製造単位である。

本稿では、Dynamic Workflow Agent設計を量産モデルへ落とし込む。5つの中核Agent、量産時に必要な監視ツール、品質・製造管理Harness、Loop Guard、Agent Blueprint、量産手順、品質管理・製造管理への適用を定義する。目的はAgentを増やすことではない。観測でき、制約でき、一時停止でき、修復でき、監査でき、退役でき、改善できるAgentを増やすことである。

1. Dynamic Workflowが必要な理由

多くの企業Workflowは固定的なprocess diagramとして書かれる。顧客依頼がqueueへ入り、taskが決められたstepを進み、例外がticketになり、人間operatorが判断する。この方式は安定しているが、現実の業務変化には弱い。採用面接は候補者返信に依存する。Sales quoteはmargin riskに依存する。請求処理は発注書や検収記録に依存する。製造品質問題はlot、machine、operator、supplier、inspection stateに依存する。

Dynamic Workflow Agentはこの前提を変える。固定手順を実行するだけでなく、目的を解釈し、制約をcompileし、Workflow Graphを生成または修正し、各NodeとGateにHarnessを割り当て、権限不足時に停止し、学習すべきことをMemoryへ残す。Workflowは静的diagramではなく、統治されたruntime objectになる。

MARIA OSでこれが重要なのは、Agentic Companyをprompt chainだけで運営できないからである。すべてのWorkflowは、なぜ存在するのか、誰が責任を持つのか、どのEvidenceが必要か、どのToolを使えるか、どこで止まるか、どう復旧するか、何をMemoryへ戻すかを知らなければならない。Dynamic Workflow Agentは、business intent、runtime execution、harness control、organizational learningが交差するcoordination layerである。

2. 5つの中核Agent

量産モデルは5つのAgentから始める。Intent and Constraint Compiler Agentは、自然言語Goal、業務event、authority rule、過去failureをGoal Object、Constraint Object、Risk Class、Required Harness List、Human Approval Boundaryへ変換する。曖昧な目的を、Harnessが検査可能なruntime materialへ変える場所である。

Workflow Topology Planner Agentは、制約をWorkflow Graphへ変換する。Node、Edge、Gate、Retry Policy、Timeout Policy、Parallel Execution Plan、Responsibility Map、Rollback Pathを定義する。出力は手順listではない。Harnessが観測できるgraphである。

Harness Binding Agentは、各Node、Edge、GateへStatic、Pre-Execution、Runtime、Post-Execution、Cross-Cutting、Meta Harnessを割り当てる。新しいNodeにHarness Bindingがない場合、そのWorkflowは実行すべきではない。このAgentがDynamic Workflow LayerとHarness Runtimeを接続する。

Runtime Repair Orchestrator Agentは、Harness failureを受け取り、retry、pause、reroute、patch request、operator notification、human escalationを選ぶ。技術原因と業務影響を分離する。たとえばSalesforce API failureが起きても、顧客emailまで止める必要はない場合がある。CRM syncをqueueへ退避し、低riskな顧客連絡は継続できる。

Workflow Learning and Policy Refactor Agentは、完了run、失敗、patch、review comment、KPI変化、類似incident memoryをLearning Recordへ変換する。Template update、Harness rule update、Agent assignment update、Preventive Controlを提案する。ここでWorkflow運用が会社の再利用可能な知識になる。

3. Agent間Protocol

Dynamic Workflow Agentは自由文messageではなくEnvelopeで通信する。最小fieldはworkflowRunId、mariaCoordinate、sourceAgent、targetAgent、eventType、riskClass、authorityBoundary、evidenceRefs、payload、requestedOutput、deadlineである。Envelopeにより、各Agent actionは帰属可能で、scopeがあり、監査可能になる。

{
  "workflowRunId": "wf_run_001",
  "mariaCoordinate": "G1.U2.P3.Z1.A5",
  "sourceAgent": "Runtime Repair Orchestrator Agent",
  "targetAgent": "Workflow Topology Planner Agent",
  "eventType": "HARNESS_FAILURE_DETECTED",
  "riskClass": "Medium",
  "authorityBoundary": "human_review_required",
  "evidenceRefs": ["ev_invoice_001", "ev_log_991"],
  "payload": {},
  "requestedOutput": "Workflow Patch",
  "deadline": "PT10M"
}

このProtocolは量産要件である。数百のAgentが作られると、ad hocな自然言語traceだけでは運用をdebugできない。安定したidentifier、coordinate、evidence reference、risk class、ownership boundaryが必要になる。また、Workflowが遅延し、loopし、過剰costを使い、Gateを迂回した時に、監視toolが因果関係を復元するためにも必要である。

4. 量産時のMonitoring Tool群

第一の監視toolはAgent Factory Monitorである。量産されたAgentがAgent Blueprint、MARIA coordinate、owner、reviewer、risk envelope、tool permission、harness coverage、memory scope、version、lineage、duplicate capability reviewを持つかを見る。出力はAgent Registry Health、Coverage Gap、Authority Drift Report、Duplicate Agent Report、Retirement Candidateである。

第二のtoolはQuality Observatoryである。Success Rate、Human Acceptance Rate、Evidence Completeness、Unsupported Claim、Regression Rate、Rework Rate、CustomerまたはOperator Feedbackを監視する。出力はQuality Score、Quality Drift Alert、Required Test Addition、Prompt Revision Proposal、Workflow Revision Proposalである。

第三のtoolはSettlement Ledger Monitorである。精算は外部請求だけではない。社内配賦、部門別利用料、Agent別原価、顧客別cost、budget burn、invoice status、reimbursement state、duplicate charge prevention、cost anomalyを含む。業務上は完了しても、精算できないWorkflowは完了していない。

第四のtoolはAgent Operations Monitorである。Heartbeat、Queue Depth、Running、Waiting、Failed、Paused、Tool Error Rate、Retry Count、Latency、Escalation Rate、Permission Denial、Memory Read/Write Errorを監視する。Stuck Agent Alert、Tool Failure Alert、Auto Pause Request、Human Escalation Requestを出せる。

第五のtoolはHarness Loop Controllerである。Loop Depth、Repair Attempt Count、Same Failure Fingerprint Count、Cooldown、Remediation Lock、Harness Trigger Source、Human Approval Stateを制御する。これはSelf-Healing Systemと制御不能なrepair loopを分ける装置である。Continue、Stop、Quarantine、Escalate、Advisory-onlyを決める。

5. 品質および製造管理ハーネス

Production systemには、実行後の品質確認だけでは足りない。Agent実行前、実行中、実行後を検査する製造管理Harnessが必要である。MARIA OSではこれをStatic HarnessとRuntime Harnessに分ける。

Agent Blueprint Static Harnessは、Agent名、MARIA coordinate、role、responsibility boundary、input、output、tool permission、memory scope、risk envelope、required harness、owner、reviewerを検査する。Ownerがない、risk envelopeがない、tool permissionが広すぎる、required harnessが未割当、memory scopeが無制限、high-risk権限にHuman Approval Gateがない場合はfailする。

Workflow Contract Static Harnessは、Workflow Graph、Node Responsibility、Retry Policy、Timeout Policy、Approval Gate、Rollback Path、Evidence Requirement、Harness Binding Planを検査する。Retry上限がない、停止条件がない、承認Gateを迂回するEdgeがある、Rollback Pathがない、Post-Execution Harnessが未設定の場合はfailする。

Quality Static Harnessは、品質基準、Evidence基準、Evaluation Rubric、Golden Dataset、Regression Test、Human Review条件を検査する。品質基準が数値化されていない、Evidenceなしで判断確定できる、回帰testがない、Human Reviewしきい値がない場合はfailする。

Settlement Static Harnessは、Cost Center、Budget、Billing Owner、Charge Unit、Cost Cap、Settlement Period、Invoice Rule、Duplicate Charge Guardを検査する。Cost Centerがない、Budget上限がない、精算単位が不明、二重請求防止keyがない、High Cost Toolに承認Gateがない場合はfailする。

Agent Observability Static Harnessは、Heartbeat、Log Schema、Trace ID、Metrics、Alert Rule、Quarantine Rule、Manual Overrideを検査する。Heartbeatがない、workflowRunIdやmariaCoordinateがlogにない、alertしきい値がない、quarantine ruleがない場合はfailする。

Loop Guard Static Harnessは、maxLoopDepth、maxRepairAttempts、cooldownWindow、idempotencyKey、failureFingerprint、remediationLock、escalationThreshold、loopOwnerを検査する。Loop上限がない、同一failure再処理抑制がない、修正lockがない、Harness自身の出力で同じHarnessを即時再起動できる、人間escalation条件がない場合はfailする。

6. ランタイムハーネス

Quality Runtime Harnessは、Node完了時、Workflow完了時、Human Review後、顧客feedback後に走る。Output Quality Score、Evidence Completeness、Policy Compliance、Unsupported Claim、Rework Required、Human Overrideを検査する。Low Riskでは再生成または補足Evidence要求、Medium RiskではWorkflow一時停止とHuman Review要求、High Riskでは確定処理禁止とEscalationを行う。

Settlement Runtime Harnessは、Tool実行前、高cost API実行前、Workflow完了時、請求締め処理前に走る。Cost Cap、Budget Burn Rate、Duplicate Charge Key、Invoice State、Payment/Reimbursement State、Customer Contract Ruleを検査する。予算超過前に警告し、二重請求疑いをblockし、高額実行をApproval Gateへ送り、精算未完了Workflowをclose禁止にする。

Agent Health Runtime Harnessは、Agent起動時、heartbeatごと、tool実行後、queue滞留時、retry発生時に走る。Heartbeat Missing、Queue Depth、Tool Error Rate、Retry Count、Latency、Permission Denial、Memory Errorを検査する。Agent一時停止、queue隔離、tool権限一時停止、Runtime Repair Orchestrator通知、Human Escalationを行う。

Workflow SLA Runtime Harnessは、Node開始時、Node終了時、SLA期限前、承認待ち滞留時に走る。Expected Duration、Blocking Node、Approval Waiting Time、Retry Saturation、Downstream Impactを検査する。迂回Workflow提案、期限前Escalation、SLA違反予測、Workflow Topology Plannerへの再計画要求を行う。

Loop Guard Runtime Harnessは、Harness Event発生時、Repair Plan作成時、Fix実行前、Verify失敗時、Learn実行前に走る。loopDepth、repairAttemptCount、sameFingerprintCount、cooldownUntil、remediationLock、causedByHarnessRunId、lastHumanDecisionを検査する。Actionはcontinue、cooldown、stop、quarantine、human escalation、meta-harness advisoryである。

7. 品質管理と製造管理

MARIA OSの品質管理はoutput scoringだけではない。Blueprint品質、実行品質、review品質、memory品質までのchain全体である。Workflow Agentが流暢なartifactを作っても、Evidenceを飛ばし、budgetを超え、approval policyを破り、再利用可能なlearning traceを残さないなら、そのAgentは不良品である。

Quality Observatoryはmulti-axis scorecardを公開するべきである。Output Quality Scoreはartifactがrubricを満たすかを見る。Evidence Completenessはclaim、金額、decision、approvalがsourceに結びつくかを見る。Human Acceptance Rateはreviewerが大きなreworkなしに受け入れるかを見る。Regression Rateは変更が過去の安定episodeを悪化させたかを見る。Rework Rateは運用上の無駄を測る。Unsupported Claim Rateはhallucinationや根拠のない推論を測る。

製造管理は別の視点を加える。Agent Blueprint Yieldは生成AgentがStatic Harnessを初回でpassする比率である。Harness Binding CoverageはWorkflow Nodeに必要Harnessが割り当てられているかを見る。Authority Drift RateはAgentがenvelope外の権限を要求する頻度を見る。Duplicate Capability Rateはfactoryが再利用可能capabilityではなく重複Agentを作っていないかを見る。Retirement Candidate Rateはmerge、disable、replaceすべきAgent数を見る。

ここがAgent作成とAgent製造の違いである。作成は1つのAgentが動くかを問う。製造は、多数のAgentを安定した品質、traceability、cost control、retirement path、safety envelope付きで作り続けられるかを問う。

8. 無限Loop防止

Self-healingは新しいfailure modeを作る。repair loop自体が問題になる可能性である。MARIA OSはfailureFingerprint、cooldownWindow、repairAttemptCount、sameFingerprintLimit、remediationLock、causedByHarnessRunId、人間escalation thresholdでこれを防ぐ。

基本ruleは保守的でよい。Harness Eventは必ずfailureFingerprintを持つ。同一workflowRunId、同一failureFingerprint、同一eventTypeはcooldownWindow内で再処理しない。Fix失敗が3回続いたら自律修正を停止する。同じ原因でVerifyが2回失敗したら人間へescalateする。Meta-HarnessはHarness変更を提案できるが、高risk Harness定義を直接編集しない。Learn/Preventはpolicy変更を提案できるが、高risk policyを自動適用しない。

Loop Controlは官僚的な機能ではない。自律修復を許可しながら、repair loopに無制限のauthorityを与えないためのstability marginである。

9. エージェントのブループリント

量産にはBlueprintが必要である。BlueprintはAgentの製造仕様であり、identity、coordinate、owner、reviewer、purpose、risk envelope、tool permission、memory scope、required static harness、required runtime harness、loop guard、approval gateを定義する。

{
  "agentId": "dwa_invoice_repair_001",
  "agentType": "HarnessLoopDynamicWorkflowAgent",
  "mariaCoordinate": "G1.U2.P3.Z1.A5",
  "owner": "Finance Operations",
  "reviewer": "Risk Control",
  "purpose": "Invoice workflow repair and rerouting",
  "riskEnvelope": "Medium",
  "toolPermissions": ["read:invoice", "read:purchase_order", "write:workflow_patch"],
  "memoryScope": "finance.workflow.incidents",
  "requiredStaticHarness": [
    "Agent Blueprint Static Harness",
    "Workflow Contract Static Harness",
    "Settlement Static Harness",
    "Loop Guard Static Harness"
  ],
  "requiredRuntimeHarness": [
    "Quality Runtime Harness",
    "Settlement Runtime Harness",
    "Agent Health Runtime Harness",
    "Loop Guard Runtime Harness"
  ],
  "loopGuard": {
    "maxLoopDepth": 5,
    "maxRepairAttempts": 3,
    "sameFingerprintLimit": 2,
    "cooldownWindowMinutes": 30
  },
  "approvalGate": {
    "mediumRisk": "review_required",
    "highRisk": "proposal_only"
  }
}

Blueprintにより、MARIA OSはAgentが実行される前に比較できる。Agent versionがtool permissionを追加し、memory scopeを変え、loop guardを弱め、reviewerを消し、required harness bindingを外した場合、その変更はruntime前に見える。

10. 量産方法

第一段階はBlueprint標準化である。すべてのAgentに必須fieldを定義し、owner、reviewer、coordinate、risk envelope、tool permission、memory scope、static harness、runtime harness、loop guard、approval gateがないAgentをrejectする。

第二段階はHarness Template Packagingである。Agent familyごとに再利用可能なHarness Packを持たせる。Finance Agentにはsettlement、duplicate charge、evidence、approval harnessを付ける。Hiring Agentにはcandidate privacy、evaluation fairness、scheduling SLA、human approval harnessを付ける。Sales Agentにはquote evidence、margin、CRM sync、customer-visible output harnessを付ける。Manufacturing Agentにはlot traceability、inspection evidence、supplier quality、machine-state、nonconformance harnessを付ける。

第三段階はmonitored factory intakeである。新しいWorkflow Agent要求が来たら、Agent Factory Monitorが既存Agentと比較し、duplicate capabilityを確認し、coordinateを割り当て、Blueprintを適用し、Static Harnessを走らせ、approval-ready agent packageまたはrejection reportを出す。

第四段階はcontrolled runtime rolloutである。新Agentはobserve-onlyまたはdraft modeから始める。Episodeを収集し、recommendationを作り、high-risk actionを実行せずにHarnessを走らせる。Quality、Settlement、Health、Loop metricsが安定したら、Low Risk executionへenvelopeを広げる。Medium/High Risk actionはreviewの背後に残す。

第五段階はmemory-backed improvementである。成功episodeはtemplateになる。失敗episodeはprevention ruleになる。却下patchはreviewer rationale memoryになる。繰り返されるcoverage gapは新しいHarness Templateになる。退役Agentは次回factory checkのnegative exampleになる。

11. 品質・製造管理での例

製造業務では、Dynamic Workflow Agentはnonconformance handling、supplier corrective action、inspection routing、production stop decision、engineering change requestを調整できる。Workflow Graphにはlot identification、machine status retrieval、operator report review、inspection evidence collection、root-cause hypothesis、disposition proposal、approval gate、supplier notification、preventive-action trackingが含まれる。

必要Harnessは具体的である。Lot Traceability Harnessはlot、serial、supplier、production line identityを検証する。Inspection Evidence Harnessはmeasurement record、photo、sampling plan、acceptance criteriaを検証する。Quality Runtime HarnessはdispositionがEvidenceに支えられているかを見る。Settlement Runtime Harnessはscrap cost、rework cost、supplier chargeback、customer credit exposureを追跡する。Approval Gate Harnessはauthorityがないshipment release、supplier debit、production restartをblockする。

Monitoring Toolにより、このprocessはscaleする。Quality Observatoryはdefect recurrence、false closure、rework rate、evidence completeness、human acceptanceを追跡する。Agent Operations Monitorはstuck investigationやtool failureを検知する。Settlement Ledger Monitorはrework costがfinancial trailの外へ消えることを防ぐ。Harness Loop Controllerは同じnonconformance signatureが戻り続ける時、自動再計画を停止する。

これによりMARIA OSは品質管理をdocument routingからgoverned runtimeへ変える。systemはcorrective action reportを作るだけではない。Workflowを観測し、authorityを制約し、Evidenceをbindし、costを制御し、loopを防ぎ、どのpreventive controlを標準化すべきかを学習する。

12. KPIモデル

Workflow KPIは業務完了率、平均処理時間、Agent利用率、Escalation率、業務自動化率である。Quality KPIは品質score、Evidence完備率、Human Acceptance Rate、Rework率、Unsupported Claim率、品質Drift検知数である。Settlement KPIはWorkflow別Cost、Agent別Cost、Budget Burn Rate、精算完了率、二重請求block数、Cost Anomaly検知数である。

Agent Monitoring KPIはHeartbeat欠損率、Queue滞留時間、Tool Error Rate、Retry Count、Quarantine数、権限拒否率である。Harness KPIは修復成功率、平均復旧時間、誤分類率、再発率、Coverage率、PR採択率である。Loop Guard KPIはLoop停止率、平均Loop Depth、sameFingerprint再発率、Cooldown発火数、Human Escalation率、無限Loop防止成功数である。

重要なのは、単一metricを支配的にしないことである。Escalation率が下がってもapproval bypassが増えるなら悪い。Workflowが速くなってもsettlementが未完了なら悪い。Automation率が上がってもreworkが増えるなら悪い。Costが下がってもEvidence品質が落ちるなら悪い。MARIA OSは業務自律性をspeed contestではなく、制約付き最適化問題として扱う。

13. 最終的なアーキテクチャ

Dynamic Workflow AgentはHuman OperatorとHarness Runtimeの間に位置する。Human OperatorはGoalを表明し、high-risk actionを承認し、例外をreviewする。Dynamic Workflow AgentはGoalをcompileし、Graphを計画し、Harnessをbindし、taskをrouteし、repairを扱い、learning recordを書く。Agent RuntimeはToolとSub-Agentを実行する。Harness Runtimeは観測し、blockし、repairし、verifyし、escalateする。Memory and Learningは再利用可能patternを保存する。

統合flowは、Workflow Node実行、Runtime Harness観測、Quality/Settlement/Health Event生成、Loop Guard判定、Risk Envelope分類、retryまたはrerouteまたはpause、必要時のPatch Planner request、Scoped Harness、Cross-Cutting Harness、必要時のHuman Approval、deployまたはWorkflow resume、Memory update、Preventive rule proposalである。

これにより企業は継続的に改善するOperating Systemになる。Agentが業務を実行する。Harnessが業務を監視する。Fixerが業務を修復する。Memoryが業務を記憶する。Monitoring ToolがAgentを生産するfactoryを制御する。これがMARIA OSにおけるAgent実行からSelf-Evolving Company OSへの道である。

結論は

Dynamic Workflow Agentは製造規律なしに量産してはいけない。すべてのAgentにはBlueprintが必要である。すべてのWorkflowにはHarness Binding Planが必要である。すべての実行にはQuality、Settlement、Health、Loop Telemetryが必要である。すべてのrepairにはEnvelope、Rollback Path、Evidenceが必要である。すべての再発failureはMemoryになるべきである。すべての未割当HarnessはCoverage Gapになるべきである。

実務上の順序は明快である。Blueprintを標準化する。Harness Templateをpackage化する。Factory Intakeを監視する。Agentを制約付きEnvelopeでrolloutする。Memoryで反復作業をより良いdefaultへ変換する。これによりMARIA OSは、業務Agentを増やしながら業務riskを増やさない量産方式を実現できる。