自己書き換えAgentシステム — Tool・Command・Workflowを自律的に進化させるアーキテクチャ

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

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

しかし、ツール生成は能力問題の一軸にしか対処しない。本番環境で時間が経過すると何が起こるかを考えよう。 | 問題 | ツール生成の対応 | 実際に必要なこと | |---|---|---| | APIエンドポイントのURL変更 | 新URLで新ツールを生成 | 既存ツールのエンドポイント設定を修正 | | データ量増加でツールが3倍遅くなる | 最適化された代替を生成、元を放置 | ツールのアルゴリズムをスケール対応に修正 | | ワークフローのステップが不要になる | そのまま残し、バイパスツールを追加 | ワークフロー定義からステップを削除 | | 決定ルールが偽陽性を生成 | ポストフィルターツールを生成 | 決定ルールの閾値やロジックを修正 | | 下流システムのコマンド構文変更 | 新コマンドラッパーを生成 | 既存のコマンドテンプレートを修正 |

パターンは明白だ。ツール生成は精錬なき蓄積を生む。エージェントのツールレジストリは単調に増加し、ほぼ重複するツール、孤立したラッパー、回避策レイヤーで満たされる。これはエージェント版の技術的負債であり、人間のソフトウェアシステムにおける技術的負債と同様に複利で増大する。新しいツールを追加するたびにツール選択のレイテンシが増し、最適でないツールを選択する確率が高まり、誰のエージェントも解決する責任を持たない保守負担が生まれる。

自己修正はこの問題に対するアーキテクチャ的回答である。ツールAを置き換えるためにツールBを生成するのではなく、エージェントはツールAをインプレースで修正する。そのアイデンティティ、既存ワークフローにおける位置、統合ポイントを保持しながら、実装を現在の要件に合わせて変更する。

2. 修正対象：Tool・Command・Workflow・Decision Rule

自己修正は4つの異なるアーティファクトカテゴリにわたって動作する。それぞれ異なる修正セマンティクスとリスクプロファイルを持つ。

// SMASにおける4つの修正可能アーティファクトカテゴリ
type ModifiableArtifact =
  | ToolDefinition       // 型付きI/Oを持つ実行可能関数
  | CommandTemplate       // 外部システム向けパラメータ化コマンド文字列
  | WorkflowDefinition    // 条件分岐を持つステップのDAG
  | DecisionRule          // エージェント動作をゲートする述語関数

interface ModificationScope {
  artifact: ModifiableArtifact
  modifiableFields: string[]      // 変更可能なフィールド
  frozenFields: string[]          // 変更不可能なフィールド（安全不変条件）
  requiredApproval: GateLevel     // auto | agent-review | human-approval
  rollbackWindow: number          // 修正が恒久化するまでの秒数
}

Toolは最も頻繁に修正されるアーティファクトである。ツールの実装、パラメータデフォルト、リトライロジック、タイムアウト値、エラーハンドリングはすべて修正可能だ。型シグネチャ（入力型と出力型）はデフォルトで凍結される。ツールのインターフェースを変更すると、それに依存するすべてのワークフローが壊れるためだ。インターフェース変更には明示的なワークフローレベルの修正も必要となる。 Commandは、エージェントが外部システム（API・データベース・シェルコマンド）と対話するために使用するパラメータ化テンプレートである。コマンドの修正には通常、エンドポイントURL・認証方法・パラメータマッピング・シリアライゼーション形式が含まれる。コマンドのセマンティック意図（何をするか）は凍結され、どのようにするかだけが修正可能だ。 Workflowはステップの有向非巡回グラフである。ワークフローの修正には、ステップの追加・削除・並べ替え、条件分岐述語の変更、並列性設定の修正、タイムアウトおよびリトライポリシーの調整が含まれる。ワークフローのエントリポイントと最終出力型は凍結される。 Decision Ruleは分岐点でエージェントの動作を決定する述語関数である。修正には閾値調整・特徴量追加・ロジック再構成が含まれる。ルールの決定ドメイン（どの質問に答えるか）は凍結され、どのように答えるかだけが修正可能だ。

3. 修正トリガー：自己修正が起動する条件

自己修正は連続的ではない。現在の運用状態が最適でないことを示す特定のトリガーに応じて起動する。3つのトリガーカテゴリを識別する。

パフォーマンス劣化。 エージェントはすべてのツール・コマンド・ワークフローの実行メトリクスを監視する。メトリクスが劣化閾値を超えた場合（レイテンシが2倍以上増加、エラー率が5%超過、成功率が過去のp95を下回る）、修正パイプラインがトリガーされる。これは反応的修正である。何かが壊れたか遅くなり、エージェントは適応しなければならない。

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

効率最適化。 すべてが動作している場合でも、エージェントは運用を継続的にプロファイリングし、最適化の機会を特定する。常に同じ値を返すワークフローステップを定数に置き換えられる。3つの逐次APIコールを並列化できる。決定ルールが12個の特徴量を評価しているが4個で同じ精度が出る。最適化トリガーは、期待される改善が最小閾値（デフォルト：レイテンシ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・ネットワーク）を超えないこと

段階4：適用。 検証済み提案がアトミックに適用される。現在のアーティファクトバージョンがスナップショットされ（不変の履歴記録を作成）、修正が適用され、新バージョンが単調増加するバージョン番号でアーティファクトレジストリに登録される。適用はトランザクショナルであり、どのステップが失敗しても修正全体がロールバックされる。

段階5：確認。 適用後、修正されたアーティファクトは確認ウィンドウに入る（デフォルト：ツールは1時間、ワークフローは24時間、決定ルールは72時間）。このウィンドウ中、システムは修正されたアーティファクトの動作を期待される改善メトリクスに対して監視する。期待に沿わない場合や予期しない副作用が生じた場合、自動ロールバックがトリガーされる。確認は最終的な安全ネットであり、本番負荷パターンでのみ発現する問題をキャッチする。

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

SMASのすべてのアーティファクトは完全なバージョン履歴を持つ。これはオプションではなく、アーキテクチャの構造的要件である。バージョン履歴は3つの機能を果たす：監査（誰が何を、いつ、なぜ変更したか）、ロールバック（任意の以前のバージョンへの復帰）、学習（修正パターンの分析による将来の提案改善）。

バージョン履歴は追記のみのログを形成する。バージョンは削除も変異もされない。これにより、エージェントが自身に対して行ったすべての修正の完全な改ざん検知可能な記録が作成される。MARIA OSでは、このログはdecision_transitionsテーブルにself_modification遷移タイプとして格納され、エージェントの自己修正を他のすべての意思決定に使用される同じ監査インフラストラクチャに統合する。

ロールバックは常に利用可能だ。任意のアーティファクトを任意の以前のバージョンに戻すことができる。ロールバック自体が修正であり、同じパイプラインを通過し（対象コンテンツは以前に検証済みのため検証は簡略化される）、独自の監査記録を生成する。痕跡を残さずにアーティファクトを修正する方法は存在しない。

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. 修正下の安定性：Lyapunov解析

自己修正システムの中心的な懸念は安定性である。繰り返しの自己修正が、振動や発散ではなく、良好に機能する状態に収束することを保証できるか？ これにLyapunov安定性解析で対処する。

最適な運用からの距離を測定するLyapunov関数$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

これが厳密Lyapunov減少条件である。$V$がゼロ（完全な運用）で下に有界であることと合わせると、収束が保証される。数列$V(M(0)), V(M(1)), V(M(2)), \ldots$は単調減少かつ下に有界であり、したがって単調収束定理により収束する。

Lyapunov条件は修正パイプラインの段階3（検証）で強制される。すべての提案はサンドボックステストを通じて、修正されたアーティファクトの損失が現在のアーティファクトの損失より厳密に低いことを実証しなければならない。検証が厳密な減少を確認できない場合、提案は却下される。これにより、数学的な安定性保証が実用的なエンジニアリング制約に変換される。

実際には、測定ノイズに対応するために厳密減少条件を緩和し、$V(M(t+1)) < V(M(t)) - \epsilon$（$\epsilon > 0$は最小改善閾値）を要求する。これにより、厳密な不等式は満たすが意味のある改善をもたらさない些細な修正を防ぐ。

8. 有界自己修正：修正フロンティア

すべてが修正可能であるべきではない。修正フロンティアは、エージェントが修正できるものとできないものの境界である。この境界はアーキテクチャによって定義され、エージェントの選択によるものではない。エージェントは自身の修正フロンティアを拡張できない。

修正フロンティア自体は凍結されている。エージェントは自己修正を統治するルールを修正できない。これがSMASの根本的な安全不変条件である。エージェントが自身の修正制約を修正できれば、いかなる安全保証も成立しない。エージェントは自身の安全チェックを除去し、無制限の自己修正に入る可能性がある。フロンティアは人間のアーキテクトによって設定され、MARIA OSの標準的な責任ゲートプロセス（人間の承認付き）を通じてのみ変更できる。

Metaラベルの凍結カテゴリが最も重要である。これには以下が含まれる：(1) 修正フロンティア定義自体、(2) 安全制約述語$\phi_{\text{safety}}$、(3) 監査ログシステム、(4) どの修正が人間の承認を必要とするかを決定するゲートレベル割当、(5) Lyapunov関数$V$とその減少閾値$\epsilon$。これらが有界自己修正を可能にするアーキテクチャ不変条件である。

9. 自己修正の停止問題

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

制約1：有限修正空間。 修正部分空間$\mathcal{S}$は有限次元である。アーティファクトは有限サイズを持ち、パラメータは有界範囲を持ち、修正可能なフィールドの集合は固定されているためだ。これは$\mathcal{M}$がコンパクトであることを意味する。

制約2：厳密Lyapunov減少。 すべての修正は$V$を少なくとも$\epsilon$減少させなければならない。$V$はゼロで下に有界であり修正ごとに少なくとも$\epsilon$減少するため、修正の最大回数は有界である。

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

最大$N_{\text{max}}$回の修正後、それ以上の修正はLyapunov減少条件を満たすことができず、システムは停止する（安定状態に到達する）。

制約3：クールダウン期間。 各アーティファクトには修正間の最小時間（トリガー条件$\text{stable}(a, w)$の安定性ウィンドウ）がある。修正が利用可能であっても、レート制限される。これにより、ほぼ同等の構成間の高速振動を防ぐ。

停止保証は構成的である。システムが実行する自己修正の総数の上限を計算できる。V(M(0)) ~ 100、epsilon = 0.1の典型的なMARIA OSデプロイメントでは、修正の最大回数は1,000回である。実際には、システムは初期適応期間中に50〜200回の修正後に安定化し、その後は外部変化に応じた修正のみが発生する定常状態に入る。

この結果には深い含意がある。自己修正エージェントは永久機関ではない。運用状態が局所最適である固定点に収束し、環境が変化するまでそこに留まる。自己修正は適応メカニズムであり、永続的なプロセスではない。

10. 証拠アーキテクチャ：不変の修正記録

すべての自己修正は、MARIA OS証拠システムに不変に格納される構造化された証拠バンドルを生成する。証拠バンドルは修正をそのトリガー・正当化・検証結果・デプロイ後の確認に結びつける。

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

  // トリガーチェーン
  trigger: {
    type: "degradation" | "new-requirement" | "optimization"
    evidence: MetricTrace[] | RequirementSpec[] | OptimizationAnalysis
    detectedAt: string
  }

  // 修正内容
  diff: {
    before: string              // 完全なアーティファクトソース（修正前）
    after: string               // 完全なアーティファクトソース（修正後）
    hunks: DiffHunk[]           // 行レベルの差分ハンク
    summary: string             // 自然言語による要約
  }

  // 検証記録
  validation: {
    typeCheck: { passed: boolean; details: string }
    sandboxResults: TestResult[]
    regressionResults: TestResult[]
    safetyCheck: { passed: boolean; constraintsEvaluated: string[] }
    lyapunovDecrease: { before: number; after: number; delta: number }
  }

  // デプロイ後確認
  verification: {
    windowStart: string
    windowEnd: string
    status: "pending" | "verified" | "rolled-back"
    productionMetrics: MetricSnapshot
    anomalies: AnomalyReport[]
  }
}

証拠アーキテクチャにより、自己修正がブラックボックスになることは決してない。あらゆるステークホルダー（人間またはエージェント）が、修正をそのトリガーから正当化を経て結果まで追跡できる。これは組織的信頼に不可欠である。エージェントが自身のツールを修正する場合、組織はその理由を理解し、修正が安全であったことを検証し、必要に応じて元に戻せなければならない。

11. MARIA OS実装：自己修正に対する責任ゲート

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

ゲートレベルは修正パイプラインによってアーティファクトタイプ・差分のスコープ・影響を受ける依存アーティファクトの数に基づいて自動的に決定される。エージェントはゲートレベルの割当をオーバーライドできない。これは修正フロンティアにおける凍結フィールドである。

12. 結論

自己書き換えAgentシステムはエージェントアーキテクチャ進化の次の段階を表す。ツール生成はエージェントに能力を拡張する力を与えた。自己修正はそれらの能力を洗練する力を与える。変化する環境に応じて運用コードを適応・最適化・進化させる能力だ。核心的な洞察は、自己修正は有界でなければならないということである。凍結された修正フロンティアによって制約され、Lyapunov解析によって安定化され、エネルギー議論によって停止が保証され、責任ゲートによって統治される。無制限の自己修正は危険である。有界の自己修正はガバナンス機能である。それはエージェントを運用実態に整合させつつ、完全な監査可能性を維持する。MARIA OSにおいて、自己修正はガバナンスモデルの例外ではない。エージェント自身のコードに適用されたガバナンスモデルそのものである。