自己変更エージェント システム: 独自のツール、コマンド、ワークフローを書き換えるエージェントのアーキテクチャ

1. ツールの作成を超えて: 自己修正の必要性

ツール作成パラダイムは、2024 年以降、エージェント アーキテクチャを支配しています。エージェントはタスクを受け取り、適合する既存のツールがないと判断し、自然言語記述から新しいツールを生成し、サンドボックスで検証して、ツール レジストリに追加します。このパラダイムは、エージェントの機能拡張に関する最初の問題を解決しました。エージェントは、呼び出すすべての関数を人間の開発者が作成する必要がなくなりました。

しかし、ツールの作成では、機能の問題の 1 つの軸にのみ対処します。実稼働環境で時間の経過とともに何が起こるかを考えてみましょう。 |問題 |ツール作成の応答 |実際のニーズ | |---|---|---| | API エンドポイントの URL が変更される |新しい URL で新しいツールを作成します |既存のツールのエンドポイント構成を変更する | |データ量が増加するとツールの実行が 3 倍遅くなる |最適化された置換を作成し、オリジナルを孤立させます。スケールを処理するためにツールのアルゴリズムを変更する | |ワークフローステップが不要になる |そのままにして、バイパス ツールを追加します。ワークフロー定義からステップを削除します。 |決定ルールにより誤検知が発生する |ポストフィルターツールを作成する |決定ルールのしきい値またはロジックを変更する | |ダウンストリーム システムでのコマンド構文の変更 |新しいコマンド ラッパーを作成する |既存のコマンド テンプレートを変更する |

パターンは明らかです。ツールの作成は洗練されずに蓄積を生み出します。エージェントのツール レジストリは単調に増加し、ほぼ重複したツール、孤立したラッパー、および回避策レイヤーで満たされます。これはエージェントの技術的負債に相当し、人間のソフトウェア システムにおける技術的負債と同様に、さらに複雑化します。新しいツールごとに、ツールの選択に待ち時間が加わり、最適ではないツールが選択される可能性が高まり、エージェントが解決する責任を負わないメンテナンスの負担が生じます。

自己変更はアーキテクチャ上の応答です。エージェントは、ツール A を置き換えるためにツール B を作成するのではなく、ツール A を適切に変更します。そのアイデンティティ、既存のワークフロー内での位置、および統合ポイントを維持しながら、現在の要件に合わせて実装を変更します。

2. 変更される内容: ツール、コマンド、ワークフロー、意思決定ルール

自己変更は 4 つの異なるアーティファクト カテゴリにわたって機能し、それぞれに異なる変更セマンティクスとリスク プロファイルがあります。

// The four modifiable artifact categories in SMAS
type ModifiableArtifact =
  | ToolDefinition       // Executable functions with typed I/O
  | CommandTemplate       // Parameterized command strings for external systems
  | WorkflowDefinition    // DAGs of steps with conditional branching
  | DecisionRule          // Predicate functions that gate agent behavior

interface ModificationScope {
  artifact: ModifiableArtifact
  modifiableFields: string[]      // What CAN be changed
  frozenFields: string[]          // What CANNOT be changed (safety invariants)
  requiredApproval: GateLevel     // auto | agent-review | human-approval
  rollbackWindow: number          // Seconds before modification becomes permanent
}

ツールは最も一般的に変更されるアーティファクトです。ツールの実装、パラメータのデフォルト、再試行ロジック、タイムアウト値、エラー処理はすべて変更できます。ツールのインターフェイスを変更すると、それに依存するすべてのワークフローが中断されるため、その型シグネチャ (入力型と出力型) はデフォルトで固定されています。インターフェイスの変更には、ワークフロー レベルの明示的な変更も必要です。 コマンドは、エージェントが外部システム (API、データベース、シェル コマンド) と対話するために使用するパラメーター化されたテンプレートです。コマンドの変更には通常、エンドポイント URL、認証方法、パラメータ マッピング、シリアル化形式が含まれます。コマンドのセマンティックな意図 (何を行うか) は固定されています。変更できるのはその方法のみです。 ワークフローは、ステップの有向非循環グラフです。ワークフローの変更には、ステップの追加、削除、または並べ替えが含まれます。条件分岐述語を変更する。並列処理設定を変更する。タイムアウトと再試行ポリシーを調整します。ワークフローのエントリ ポイントと端末の出力タイプは固定されます。 意思決定ルール は、分岐点でのエージェントの動作を決定する述語関数です。変更には、しきい値の調整、機能の追加、ロジックの再構築が含まれます。ルールの決定領域 (どのような質問に答えるか) は固定されています。応答方法のみが変更可能です。

3. 変更のトリガー: 自己変更がアクティブになったとき

自己修正は継続的ではありません。現在の動作状態が最適ではないことを示す特定のトリガーに応答してアクティブになります。次の 3 つのトリガー カテゴリを特定します。

パフォーマンスの低下。 エージェントは、すべてのツール、コマンド、およびワークフローの実行メトリックを監視します。メトリクスが劣化しきい値を超えると、つまりレイテンシーが 2 倍以上増加し、エラー率が 5% を超え、成功率が過去の p95 を下回った場合、変更パイプラインがトリガーされます。これは事後的な変更です。何かが壊れたり速度が低下したりしたため、エージェントはそれに適応する必要があります。

新しい要件。 運用環境は、既存のアーティファクトでは対応できない形で変化します。新しいデータ形式が API 応答に表示されます。規制上の制約により、必須フィールドがレポートに追加されます。ダウンストリーム システムはエンドポイントを廃止します。エージェントは、実行の失敗または明示的な構成更新を通じて要件のギャップを検出し、ギャップを埋めるための変更をトリガーします。

効率の最適化。 すべてが機能している場合でも、エージェントは継続的に業務のプロファイリングを行い、最適化の機会を特定します。ワークフローには、常に同じ値を返し、定数に置き換えることができるステップがあります。ツールは、並列化できる 3 つの連続した API 呼び出しを実行します。決定ルールは、4 つの特徴が同じ精度を生成する場合、12 の特徴を評価します。最適化トリガーは、変更のチャーンを防ぐために、期待される改善が最小しきい値 (デフォルト: 10% の遅延削減または 5% のリソース削減) を超えた場合にのみアクティブになります。

T_{\text{trigger}}(a) = \begin{cases} 1 & \text{if } \Delta_{\text{perf}}(a) > \theta_{\text{degrade}} \\ 1 & \text{if } \exists r \in R_{\text{new}} : \neg\text{satisfies}(a, r) \\ 1 & \text{if } \Delta_{\text{opt}}(a) > \theta_{\text{opt}} \land \text{stable}(a, w) \\ 0 & \text{otherwise} \end{cases}

ここで、$a$ はアーティファクト、$\Delta_{\text{perf}}$ はパフォーマンスの低下を測定し、$R_{\text{new}}$ は新しい要件のセット、$\Delta_{\text{opt}}$ は最適化の可能性を測定し、$\text{stable}(a, w)$ はアーティファクトが少なくとも $w$ 時間単位安定していることを確認します (最近変更されたアーティファクトの変更を防止します)。

4. 変更パイプライン: 検出、提案、検証、適用、検証

すべての自己変更は 5 段階のパイプラインを通過します。どのステージもスキップすることはできず、各ステージで不変のレコードが生成されます。

ステージ 1: 検出。 監視サブシステムは変更トリガーを識別し、ターゲット アーティファクト、トリガー タイプ、サポート証拠 (メトリック トレース、エラー ログ、要件仕様)、および優先度スコアを含む ModificationRequest を生成します。検出は完全に自動化されており、変更リクエストの作成に人間やエージェントの承認は必要ありません。

ステージ 2: 提案。 変更エンジンはリクエストを分析し、1 つ以上の ModificationProposal オブジェクトを生成します。各提案には、差分 (アーティファクトへの正確な変更)、影響分析 (変更されたアーティファクトに依存する他のアーティファクトと、それらがどのように影響を受けるか)、リスク スコア、および推定される改善メトリクスが含まれています。このエンジンは、テンプレート ベースのパッチ適用 (URL 変更などの既知の変更パターンの場合) と LLM ベースのコード生成 (新規の変更の場合) を組み合わせて使用​​して提案を生成します。

ステージ 3: 検証。 各提案は検証バッテリーを通過します。 - 型チェック: 変更されたアーティファクトは静的型分析に合格する必要があります - サンドボックス実行: 変更されたアーティファクトは、その履歴の入力/出力から派生したテスト スイートに対して実行されます。 - 回帰テスト: 破損を検出するために、すべての依存アーティファクトが修正されたバージョンで実行されます。 - 安全制約チェック: 変更は、凍結されたフィールドに違反したり、変更のフロンティアを越えたりしてはなりません - リソース境界チェック: 変更されたアーティファクトはリソース制限 (メモリ、CPU、ネットワーク) を超えてはなりません

interface ModificationProposal {
  id: string
  targetArtifact: ArtifactReference
  trigger: ModificationTrigger
  diff: ArtifactDiff           // Before/after with line-level granularity
  impactAnalysis: {
    directDependents: ArtifactReference[]
    transitiveDependents: ArtifactReference[]
    breakingChanges: BreakingChange[]
    riskScore: number          // 0.0 - 1.0
  }
  validation: {
    typeCheck: ValidationResult
    sandboxExecution: ValidationResult
    regressionTests: ValidationResult
    safetyConstraints: ValidationResult
    resourceBounds: ValidationResult
  }
  expectedImprovement: MetricDelta
  requiredApproval: GateLevel
}

ステージ 4: 適用。 検証された提案はアトミックに適用されます。現在のアーティファクト バージョンのスナップショットが作成され (不変の履歴レコードが作成され)、変更が適用され、新しいバージョンが単調増加するバージョン番号でアーティファクト レジストリに登録されます。アプリケーションはトランザクションです。いずれかのステップが失敗すると、変更全体がロールバックされます。複数のアーティファクトに同時に影響を与えるワークフロー変更の場合、分散トランザクション プロトコルによりオール オアナッシングのセマンティクスが保証されます。

ステージ 5: 検証。 適用後、変更されたアーティファクトは検証ウィンドウに入ります (デフォルト: ツールの場合は 1 時間、ワークフローの場合は 24 時間、意思決定ルールの場合は 72 時間)。このウィンドウの間、システムは、変更されたアーティファクトの動作を、期待される改善メトリクスと比較して監視します。アーティファクトが期待を満たさない場合、または予期しない副作用が発生した場合、自動ロールバックがトリガーされます。検証は最後のセーフティ ネットです。本番環境の負荷パターンでのみ現れるため、サンドボックス テストで見逃された問題を検出します。

5. エージェント コードのバージョン管理: 不変の監査証跡とロールバック

SMAS のすべてのアーティファクトには完全なバージョン履歴があります。これはオプションではなく、アーキテクチャの構造上の要件です。バージョン履歴には、監査 (誰が、いつ、なぜ変更したのか)、ロールバック (前のバージョンに戻す)、学習 (将来の提案を改善するための変更パターンの分析) という 3 つの機能があります。

interface ArtifactVersion {
  versionId: string               // Monotonically increasing
  artifactId: string
  content: string                 // Full artifact source
  contentHash: string             // SHA-256 of content
  previousVersionId: string | null
  modification: {
    triggerId: string             // Link to ModificationRequest
    proposalId: string            // Link to ModificationProposal
    diff: ArtifactDiff            // What changed
    justification: string         // Why it changed (natural language)
    causalChain: string[]         // Evidence chain from trigger to proposal
  }
  metadata: {
    createdAt: string
    createdBy: AgentCoordinate    // MARIA coordinate of modifying agent
    approvedBy: AgentCoordinate | "auto"
    verificationStatus: "pending" | "verified" | "rolled-back"
    performanceBaseline: MetricSnapshot
    performanceActual: MetricSnapshot | null
  }
}

バージョン履歴は追加専用のログを形成します。バージョンが削除されたり、変更されたりすることはありません。これにより、エージェントがこれまでに行ったすべての変更について、改ざんが明らかな完全な記録が作成されます。 MARIA OS では、このログは「self_modification」遷移タイプを持つ「decion_transitions」テーブルに保存され、エージェントの自己変更を他のすべての決定に使用されるのと同じ監査インフラストラクチャに統合します。

ロールバックはいつでも利用できます。コンテンツがターゲットの履歴バージョンと一致する新しいバージョンを作成することで、アーティファクトを以前のバージョンに戻すことができます。これは、ロールバック自体が変更であることを意味します。ロールバックは同じパイプラインを通過し (ターゲット コンテンツは以前に検証されているため、検証が省略されます)、独自の監査レコードを生成します。痕跡を残さずにアーティファクトを変更する方法はありません。

6. 数学モデル: 修正演算子

エージェントの動作状態空間上のオペレーターとしての自己変更を形式化します。 $M(t) \in \mathcal{M}$ が、時刻 $t$ におけるエージェントの完全な動作状態を表すものとします。ここで、$\mathcal{M}$ は、すべての有効なエージェント構成の空間です。状態 $M(t)$ は、エージェントのツール レジストリ、コマンド テンプレート、ワークフロー定義、および決定ルールで構成されます。

M(t+1) = M(t) + \delta M(t)

ここで、 $\delta M(t): \mathcal{M} \rightarrow \mathcal{M}$ は、時刻 $t$ における 修飾演算子 です。演算子 $\delta M$ は任意ではありません。これは、フリーズされたフィールドと安全性が重要な不変式を除外する 修正部分空間 $\mathcal{S} \subset \mathcal{M}$ に制限されます。

\delta M(t) \in \mathcal{S} \quad \text{where} \quad \mathcal{S} = \{ \delta \in \mathcal{M} : \pi_{\text{frozen}}(\delta) = 0 \land \phi_{\text{safety}}(M(t) + \delta) = \text{true} \}

ここで、$\pi_{\text{frozen}}$ は固定された次元への投影 (ゼロでなければなりません - 変更は許可されません)、$\phi_{\text{safety}}$ は変更後に保持する必要がある安全述語です。変更演算子は、トリガー信号と現在の状態から導出されます。

\delta M(t) = \underset{\delta \in \mathcal{S}}{\arg\min} \; L(M(t) + \delta) + \lambda \|\delta\|^2

ここで、$L$ は運用上の準最適性を測定する損失関数、$\lambda \|\delta\|^2$ は大きな変更にペナルティを与える正則化項です (最小限の変更を優先します)。この処方により、薬剤がトリガーに対処するために必要な最小限の変更を確実に行い、意図しない副作用のリスクが軽減されます。

7. 修正下の安定性: リアプノフ解析

自己修正システムの主な関心事は安定性です。繰り返される自己修正が、振動したり発散したりするのではなく、適切に機能する状態に収束することを保証できますか?私たちはリアプノフ安定性解析を通じてこれに対処します。

最適な操作からの距離を測定する リアプノフ関数 $V: \mathcal{M} \rightarrow \mathbb{R}_{\geq 0}$ を定義します。

V(M) = \sum_{a \in \text{artifacts}(M)} w_a \cdot \ell_a(M)

ここで、$\ell_a(M)$ は構成 $M$ におけるアーティファクト $a$ の損失 (準最適性) であり、$w_a$ はその重要度の重みです。システムが自己修正下で安定するためには、すべての修正で $V$ が厳密に減少することが必要です。

V(M(t+1)) < V(M(t)) \quad \forall t \text{ where } \delta M(t) \neq 0

これは 厳密なリアプノフ減少条件です。 $V$ がゼロ以下に制限されているという事実 (完全操作) と組み合わせると、収束が保証されます。シーケンス $V(M(0)), V(M(1)), V(M(2)), \ldots$ は単調減少し、以下に制限されているため、単調収束定理によって収束します。

The Lyapunov condition is enforced at Stage 3 (Validate) of the modification pipeline. Every proposal must demonstrate — through sandbox testing — that the modified artifact's loss is strictly lower than the current artifact's loss. If the validation cannot confirm strict decrease, the proposal is rejected. This transforms a mathematical stability guarantee into a practical engineering constraint.

実際には、$V(M(t+1)) < V(M(t)) - \epsilon$ ($\epsilon > 0$ が最小改善しきい値) を要求することで、測定ノイズを考慮して厳密な減少条件を緩和します。これにより、厳密な不等式を通過しても意味のある改善が得られないような些細な変更をシステムが行うことを防ぎます。

8. 境界のある自己修正: 修正のフロンティア

すべてが変更可能である必要はありません。 変更フロンティア は、エージェントが変更できるものとできないものの境界です。この境界は、エージェントの選択によってではなく、アーキテクチャ的に定義されます。エージェントは独自の変更領域を拡張できません。

The modification frontier itself is frozen. An agent cannot modify the rules that govern self-modification. This is the fundamental safety invariant of SMAS. If an agent could modify its own modification constraints, no safety guarantee would hold — the agent could remove its own safety checks and enter unbounded self-modification. The frontier is set by human architects and can only be changed through the standard MARIA OS responsibility gate process with human approval.

メタ というラベルが付いた凍結されたカテゴリが最も重要です。これには、(1) 変更フロンティアの定義自体、(2) 安全性制約の述語 $\phi_{\text{safety}}$、(3) 監査ログ システム、(4) どの変更に人間の承認が必要かを決定するゲート レベルの割り当て、(5) リアプノフ関数 $V$ とその減少しきい値 $\epsilon$ が含まれます。これらは、制限された自己変更を可能にするアーキテクチャ上の不変条件です。

9. 自己修正の停止問題

自己修正エージェントは、安定状態に到達することなく自身を継続的に修正する無限修正ループに陥る可能性がありますか?これは自己修正の停止問題であり、一般的な停止問題とは異なり、SMASでは3つの構造的制約により決定可能です。

制約 1: 有限の変更空間。 加工部分空間 $\mathcal{S}$ は有限次元です。これは、アーティファクトのサイズが有限で、パラメータの範囲が有限であり、変更可能なフィールドのセットが固定されているためです。これは、$\mathcal{M}$ がコンパクトであることを意味します。

制約 2: 厳密なリアプノフ減少。 すべての変更では、$V$ を少なくとも $\epsilon$ 減少させる必要があります。 $V$ は 0 未満で制限され、変更ごとに少なくとも $\epsilon$ ずつ減少するため、変更の最大数には制限があります。

N_{\text{max}} = \left\lfloor \frac{V(M(0))}{\epsilon} \right\rfloor

最大 $N_{\text{max}}$ の変更の後、それ以上の変更はリアプノフ減少条件を満たすことができず、システムは停止します (安定状態に達します)。

制約 3: クールダウン期間 各アーティファクトには、変更間の最小時間 (トリガー条件 $\text{stable}(a, w)$ からの安定性ウィンドウ) があります。変更が利用可能な場合でも、レートは制限されています。これにより、ほぼ同等の構成間での急激な発振が防止されます。

The halting guarantee is constructive: we can compute an upper bound on the total number of self-modifications the system will ever perform. For a typical MARIA OS deployment with V(M(0)) ~ 100 and epsilon = 0.1, the maximum number of modifications is 1,000. In practice, systems stabilize after 50-200 modifications during the initial adaptation period, then enter a steady state where modifications occur only in response to external changes.

この結果は、自己修正エージェントは永久機関ではないという重大な意味を持っています。これらは、動作状態が局所的に最適になる固定点に収束し、環境が変化するまでそこに留まります。自己修正は適応メカニズムであり、永続的なプロセスではありません。

10. 証拠のアーキテクチャ: 不変の変更記録

すべての自己変更により、構造化された証拠バンドルが生成され、MARIA OS 証拠システムに不変に保存されます。証拠バンドルは、変更をそのトリガー、その正当性、検証結果、および展開後の検証に関連付けます。

interface ModificationEvidence {
  // Identity
  modificationId: string
  artifactId: string
  fromVersion: string
  toVersion: string
  timestamp: string
  agentCoordinate: string       // G1.U1.P9.Z3.A1

  // Trigger chain
  trigger: {
    type: "degradation" | "new-requirement" | "optimization"
    evidence: MetricTrace[] | RequirementSpec[] | OptimizationAnalysis
    detectedAt: string
  }

  // Modification content
  diff: {
    before: string              // Full artifact source (pre-modification)
    after: string               // Full artifact source (post-modification)
    hunks: DiffHunk[]           // Line-level diff hunks
    summary: string             // Natural language summary
  }

  // Validation record
  validation: {
    typeCheck: { passed: boolean; details: string }
    sandboxResults: TestResult[]
    regressionResults: TestResult[]
    safetyCheck: { passed: boolean; constraintsEvaluated: string[] }
    lyapunovDecrease: { before: number; after: number; delta: number }
  }

  // Post-deployment verification
  verification: {
    windowStart: string
    windowEnd: string
    status: "pending" | "verified" | "rolled-back"
    productionMetrics: MetricSnapshot
    anomalies: AnomalyReport[]
  }

  // Approval chain
  approval: {
    gateLevel: "auto" | "agent-review" | "human-approval"
    approvedBy: string
    approvedAt: string
    justification: string
  }
}

エビデンス アーキテクチャにより、自己変更が決してブラック ボックスにならないことが保証されます。人間でもエージェントでも、あらゆる利害関係者が変更をトリガーから正当化、結果に至るまで追跡できます。これは組織の信頼にとって不可欠です。エージェントが独自のツールを変更した場合、組織はその理由を理解し、その変更が安全であることを確認し、必要に応じて変更を元に戻すことができなければなりません。

11. MARIA OS の実装: 自己変更に対する責任ゲート

MARIA OS では、自己変更が既存の責任ゲート フレームワークに統合されています。変更タイプが異なれば、リスク プロファイルに基づいて異なるゲート レベルが必要になります。

ゲート レベルは、アーティファクト タイプ、差分の範囲、影響を受ける依存アーティファクトの数に基づいて、変更パイプラインによって自動的に決定されます。エージェントはゲート レベルの割り当てを上書きできません。これは変更のフロンティアで凍結されたフィールドです。

// MARIA OS self-modification responsibility gate integration
async function executeModificationPipeline(
  request: ModificationRequest
): Promise<ModificationResult> {
  // Stage 1: Detect (already completed — request exists)
  const evidence = await collectTriggerEvidence(request)

  // Stage 2: Propose
  const proposals = await generateProposals(request, evidence)

  // Stage 3: Validate
  const validated = await validateProposals(proposals)
  const best = selectBestProposal(validated)

  // Stage 4: Gate check (MARIA OS responsibility gate)
  if (best.requiredApproval !== "auto") {
    const approval = await requestApproval({
      type: "self-modification",
      artifact: best.targetArtifact,
      diff: best.diff,
      riskScore: best.impactAnalysis.riskScore,
      coordinate: request.agentCoordinate,
      gateLevel: best.requiredApproval,
    })
    if (!approval.granted) return { status: "rejected", reason: approval.reason }
  }

  // Stage 5: Apply (atomic, with snapshot)
  const version = await applyModification(best)

  // Stage 6: Verify (async, monitored)
  scheduleVerificationWindow(version, best.targetArtifact)

  return { status: "applied", versionId: version.id }
}

MARIA OS 責任ゲートとの統合は、自己変更がプラットフォームのすべてのガバナンス機能 (座標ベースのエージェントの識別、証拠に裏付けられた意思決定証跡、エスカレーションを伴う承認ワークフロー、不変の監査ログ) を継承することを意味します。自己変更は特別なケースではなく、システム内の他の決定と同様、同じガバナンスの枠組みに従う決定です。

12. 結論

自己変更エージェント システムは、エージェント アーキテクチャの進化の次の段階を表します。ツールの作成により、エージェントは自分の能力を拡張できるようになりました。自己変更により、エージェントはこれらの機能を洗練し、環境の変化に応じて運用コードを適応、最適化、進化させることができます。重要な洞察は、自己修正には限界がある必要があるということです。つまり、凍結された修正フロンティアによって制約され、リアプノフ分析によって安定化され、エネルギー議論によって停止が保証され、責任ゲートによって管理されます。際限のない自己修正は危険です。制限された自己変更はガバナンス機能であり、完全な監査可能性を維持しながら、エージェントを運用の現実に合わせた状態に保ちます。 MARIA OS では、自己変更はガバナンス モデルの例外ではありません。これは、エージェント自身のコードに適用されるガバナンス モデルです。