DB承認型開発: AI生成コードを状態遷移として管理する整合性設計

要旨

AI を活用したコード生成は、自律エージェントが自然言語仕様から機能的なソフトウェアを生成し、要件に応じて既存のコードベースを変更し、リポジトリ全体にわたって複数ステップのリファクタリング操作を実行できる段階に達しました。ただし、大規模な言語モデルの確率的な性質により、同じプロンプトを同じコードベースに適用すると、実行ごとに異なるコード出力が生成される可能性があります。この非決定論は、すべての変更が追跡可能である必要があり、すべてのビルドが再現可能である必要があり、すべての展開が監査可能である必要があるエンタープライズ ソフトウェア開発の再現性要件と基本的に両立しません。

このペーパーでは、DB-Approved Development (DBAD) を紹介します。これはコード変更をデータベースに基づいた状態遷移としてモデル化し、再現性、ロールバックの正確性、およびゲート強制承認ワークフローの数学的保証を提供する正式なフレームワークです。コードベースの状態 S_t を時刻 t におけるコンテンツアドレス指定可能なスナップショットとして定義し、各コードの変化を遷移 delta_t として定義します (S_{t+1} = T(S_t, delta_t))。すべてのトランジションは、完全な来歴とともに追加専用データベースに記録されます。トランジションを生成したエージェント、トランジションをトリガーしたプロンプト、使用されたモデル パラメーター、通過した承認ゲート、およびその承認を正当化する証拠バンドルです。

我々は 3 つの核となる定理を証明します。 (1) 再現性 — 初期状態 S_0 と記録された遷移のシーケンス [delta_0, ..., delta_{t-1}] が与えられると、状態 S_t は決定論的に再構築できます。 (2) ロールバックの正確性 — あらゆる遷移 delta_t に対して、逆遷移 delta_t^{-1} が存在し、S_t = T(S_{t+1}, delta_t^{-1}); (3) 競合検出 — 同じ状態 S_t に適用される同時遷移 delta_a と delta_b は、状態空間の重複領域を変更する場合に限り、検出可能な競合を生成します。フレームワークは生成プロセスではなく実際の出力を記録するため、これらの保証は AI コード生成プロセス自体の非決定性に関係なく適用されます。

DBAD を MARIA OS 意思決定パイプラインと統合して、影響度スコアリングの承認ゲートを実装します。各コード変更はコードベースへの影響によって分類され（依存関係分析、テスト カバレッジの相関関係、デプロイメントの爆発半径によって測定されます）、適切なゲート層を経由してルーティングされます。影響の少ない変更（影響スコア < 0.3）は自動承認され、影響が中程度の変更（0.3 <= 影響 < 0.7）はピアレビューされ、影響の大きな変更（影響 >= 0.7）は人間による承認となります。 847 のサービスを備えたエンタープライズ マイクロサービス プラットフォームでの実験結果では、ルーチンの変更に対して 99.7% の再現率、99.97% のロールバック成功率、94.3% の自動承認スループットが実証されており、ゲート評価による追加の平均遅延はわずか 180 ミリ秒です。

核となる貢献は、バージョン管理、コード レビュー、CI/CD パイプラインがすでに存在する個々のメカニズムではなく、AI によって生成されたコード変更の動作について証明可能な保証を提供する単一の数学的フレームワークの下でのそれらの統合です。 AI エージェントが運用コードを変更する場合、組織は、AI 自体の決定論に依存することなく、その変更が再現可能で、元に戻すことができ、承認されていることを証明できます。

1. AI コード生成における再現性の危機

従来のソフトウェア開発は、決定論的な基盤に基づいています。コンパイラは、固定ルールに従ってソース コードを実行可能ファイルに変換します。同じソースと同じコンパイラ バージョンを使用すると、出力は同じになります。 Git のようなバージョン管理システムは、すべての変更をコンテンツでアドレス指定可能な差分として追跡し、あらゆる履歴状態の完全な再構築を可能にします。ビルド システムは、再現可能なアーティファクトを生成する依存関係グラフをエンコードします。ツールチェーン全体は、同じ入力が同じ出力を生成することを前提としています。

AI コード生成は、この前提を根本から破ります。大規模な言語モデルは、トークン シーケンスの確率分布からサンプリングすることによってコードを生成します。同一のプロンプトと同一のモデル重みを使用しても、異なるランダム シードは異なる出力を生成します。温度設定、top-p サンプリング、ビーム検索構成、およびコンテキスト ウィンドウ管理はすべて変動性をもたらします。モデルの動作が決定的となるのは、すべての確率的パラメーターが凍結されている場合のみです。この状態は、運用環境のデプロイメントではほとんど保証されません。

1.1 非決定論の原因

AI コード生成における非決定性は複数の独立したソースから生じており、それぞれのソースには再現性フレームワークによって対処する必要があります。

サンプリング分散。 最も明白な情報源。温度 T > 0 の場合、モデルは、さまざまなトークンの確率がゼロではないソフトマックス分布からサンプリングします。同じプロンプトで 2 回実行すると、ランダム シードが異なり、異なるトークン シーケンスが生成されます。 T = 0 (貪欲なデコード) の場合でも、GPU 操作の数値精度の違いにより、異なるハードウェアでの浮動小数点演算では異なる argmax 結果が生成される可能性があります。

コンテキストの依存性。 LLM はコンテキストに依存します。同じ命令でも、コンテキスト ウィンドウの前に表示される内容に応じて異なるコードが生成されます。コンテキストにわずかに異なるファイル内容が含まれている場合 (別のエージェントによる同時変更により)、生成されるコードが変更されます。これは、モデルへの「入力」が単なるプロンプトではなく、コンテキスト全体であり、実行ごとに異なる方法で組み立てられる可能性があることを意味します。

モデル バージョンのドリフト。 エンタープライズ展開ではホスト型 LLM API がよく使用され、モデル バージョンは予告なく変更される可能性があります。モデル バージョン v1.2.3 では正しく機能したコード生成が、v1.2.4 では微妙に異なるコードを生成する可能性があります。モデルプロバイダーがいつ更新を展開するかを組織は制御できず、動作の違いを予測する変更ログとともに更新が発表されることはほとんどありません。

インフラストラクチャの差異。 モデルの重みと入力が同じであっても、GPU アーキテクチャ (A100 と H100)、CUDA バージョン、バッチ サイズ、KV キャッシュ使用率が異なると、異なる出力が生成される可能性があります。これは、浮動小数点演算が完全に結合的ではなく、並列処理により非決定的なリダクション順序が導入されるためです。

プロンプト テンプレートの進化 実際には、コード生成プロンプト自体が、時間の経過とともに進化するテンプレートとして管理されます。システム命令、コーディング規約、リポジトリ コンテキストを含むプロンプトは、複雑な成果物です。プロンプト テンプレートのコンポーネントを変更すると、生成されたコードが変更されます。テンプレートがコードベースとは別に管理されている場合、これらの変更は従来のバージョン管理では追跡できない可能性があります。

1.2 企業開発への影響

非決定的なコード生成の結果は、企業のコンテキストでは深刻です。

再現不可能性を構築する。 AI エージェントが 2 週間前に関数を生成し、組織が今日まったく同じアーティファクトを再構築する必要がある場合、再生成されたコードは異なる可能性があります。このビルドはソースから再現できなくなり、コンプライアンス、監査、インシデント対応の基本要件に違反します。

監査証跡のギャップ。 規制フレームワーク (SOX、SOC 2、ISO 27001、EU AI 法) では、組織は、導入されたソフトウェアがそのソースまで追跡できることを実証する必要があります。ソースが AI によって生成され、再現できない場合、監査証跡は壊れます。組織は現在のコードを示すことはできますが、それがどのように導出されたのかを証明したり、同じ導出プロセスで同じ結果が得られることを実証したりすることはできません。

デバッグの脆弱性 AI が生成したコードで運用インシデントが発生した場合、デバッグ プロセスでは、コードが何を行うかだけでなく、コードがなぜそのように生成されたのかを理解する必要があります。生成が非決定的である場合、「なぜ」には安定した答えがありません。同じプロンプトが異なるコードを生成した可能性があり、バグはディストリビューションのこの特定のサンプルに固有である可能性があります。

ロールバックの不確実性。 AI によって生成された変更が後退を引き起こした場合、組織は以前の状態に戻す必要があります。しかし、前の状態に AI によって生成されたコードも含まれており、生成プロセスが非決定的である場合、「前の状態」自体は再現できない可能性がある特定のサンプルになります。ロールバックは、逆方向の操作 (元に戻す) ではなく、順方向の操作 (再生成) となり、追加のリスクが生じます。

1.3 基本的な洞察

この論文の重要な洞察は、再現性には決定論的な生成は必要ないということです。確定的な記録が必要です。システムが各 AI コード生成の実際の出力 (それをトリガーしたプロンプトではなく、生成された特定のコード) を記録する場合、AI が 2 回目の実行で同じコードを生成するかどうかに関係なく、記録された遷移を再生することで、任意の時点でのコードベースの状態を再構築できます。

この洞察は、混同されがちな 2 つの懸念を切り離します。(a) AI を決定論的にすること。これは困難で脆弱であり、言語モデルの確率的性質と根本的に矛盾します。 (b) 開発プロセスを再現可能にする。これには、すべての変更が記録され、すべての状態が再構築できることだけが必要です。 DB 承認済み開発では、(a) を必要とせずに (b) に対応します。

2. 正式なステートマシンとしてのコードステート

コードベースをステート マシンとして形式化します。各状態はコードベースの完全なコンテンツ アドレス指定可能なスナップショットを表し、各遷移は完全な来歴を伴うコード変更を表します。

2.1 コードベースの状態定義

定義 1 (コードベースの状態)。 コードベースの状態 S は、ファイル パスからファイルの内容へのマッピングです。

ここで、P はリポジトリ内の有効なファイル パスのセット、C は可能なファイル コンテンツ (バイト シーケンス) のセットです。状態 S は コンテンツアドレス指定可能 です。その ID は、すべての (パス、コンテンツ) ペアを正規の順序で連結した暗号ハッシュによって決定されます。

ここで、H は衝突耐性のあるハッシュ関数 (SHA-256)、パスは辞書順にソートされ、||連結を表します。これはファイル システムのマークル ツリー ルートに相当し、まさに Git がツリー ハッシュを計算する方法です。

定義 2 (状態空間)。 状態空間シグマは、すべての有効なコードベース状態のセットです。

構造上の制約には、ソース ファイルの構文の妥当性、構成ファイルのスキーマの互換性、依存関係の一貫性 (インポートが壊れていないこと) が含まれます。パスからコンテンツへの任意のマッピングのすべてが有効なコードベースの状態を構成するわけではありません。コンパイル、静的解析に合格し、参照整合性を維持できるもののみが有効です。

2.2 遷移の定義

定義 3 (コード遷移)。 コード遷移 (またはデルタ) デルタは、コードベースの状態への変更の構造化された記述です。正式には:

どこ：

• (追加) は、新しく作成されたファイルの (パス、コンテンツ) ペアのセットです。
• D (削除) は、削除されたファイルのパスのセットです。
• M (modifications) は、変更されたファイルの (path, old_content, new_content) トリプルのセットです。

セクション 8 で説明するように、変更の三重構造 (古いコンテンツと新しいコンテンツの両方を記録する) は、可逆性にとって不可欠です。

定義 4 (遷移の出所)。 各遷移には出所レコード Pi が含まれます。

来歴記録には、移行が生成された理由とそれがどのように承認されたかを理解するために必要なすべてが記録されます。 Agent_id は、変更を作成した AI エージェントまたは人間の開発者を識別します。プロンプトは自然言語による指示を記録します。 model_version と model_params は、AI モデルの正確な構成をキャプチャします (温度、top-p、利用可能な場合はランダム シードを含む)。 Gate_id と Approval_id は、移行が通過したガバナンス ゲートと承認ワークフローを参照します。 evidence_bundle には、テスト結果、静的分析レポート、およびその他の裏付けとなる証拠が含まれています。

2.3 遷移関数

定義 5 (遷移関数)。 遷移関数 T は、状態にデルタを適用して新しい状態を生成します。

ここで、Delta はすべての有効な遷移のセットであり、bot は遷移の失敗を表します。遷移関数は次のように定義されます。

遷移デルタ = (A, D, M) は、次の場合にのみ状態 S に適用可能です。

1. A のすべての (p, c) について: p は dom(S) にありません (すでに存在するファイルを追加することはできません) 2. D のすべての p について: p は dom(S) にあります (存在しないファイルは削除できません) 3. M のすべての (p, c_old, c_new) について: p は dom(S) にあり、S(p) = c_old (ファイルは存在し、その現在のコンテンツは予期される古いコンテンツと一致します)

条件 3 は、古い遷移が適用されるのを防ぐ 前提条件チェック です。トランジションが生成されてから別の変更によってファイルが変更されている場合、old_content は一致せず、トランジションは失敗します。これは、オプティミスティック同時実行制御に相当するステート マシンです。

遷移が適用できる場合、結果の状態 S' は次のようになります。

2.4 ステートマシンの形式化

定義 6 (コード開発ステート マシン)。 コード開発ステート マシンはタプルです。

ここで、Sigma は状態空間、Delta は遷移空間、T は遷移関数、S_0 は初期状態 (空のリポジトリまたは初期コミット)、F は一連の受け入れ基準 (CI に合格、デプロイメント ゲートを満たす) です。状態 S が F にある場合、状態 S は 解放可能な状態 であり、すべての許容基準を満たしていることを意味します。

コードベースの履歴は、一連の状態と遷移です。

この形式化は単に表記上の便宜上のものではありません。これにより、オートマトン理論、データベース理論、形式的検証のよく知られた結果を AI コード生成ガバナンスの問題に適用できるようになります。

3. 状態遷移モデリング: S_{t+1} = T(S_t, delta_t)

正式な状態マシンが整ったので、遷移の合成、競合検出、再現性の証明を可能にする代数的特性など、状態遷移モデリングの詳細な仕組みを開発します。

3.1 遷移構成

定義 7 (順次合成)。 2 つの遷移 delta_a および delta_b の順次合成は、次のような遷移 delta_{ab} です。

シーケンシャル合成では、delta_a に続いて delta_b を適用することによる「複合効果」を計算します。これは、承認の目的で、一連の小さな変更を 1 つのアトミックな遷移に圧縮する場合に便利です。

組成は次のように計算されます。 delta_a = (A_a, D_a, M_a) および delta_b = (A_b, D_b, M_b) とします。合成された遷移 delta_{ab} = (A_{ab}, D_{ab}, M_{ab}) は次のとおりです。

• A_{ab} = (A_a \ D_b) 共用体 A_b 共用体 {(p, c_new) : A_a の (p, c) および M_b の (p, c, c_new)}
• D_{ab} = (D_a \ A_b) Union D_b Union {p : (p, c_old, c_new) in M_a and p in D_b}
• M_{ab} = {(p, c_old_a, c_new_b) : M_a の (p, c_old_a, c_new_a) および M_b の (p, c_new_a, c_new_b) ユニオン {(p, c_old, c_new) M_a : p は dom(delta_b) にありません} ユニオン {(p, c_old, c_new) M_b : p にありませんドム(デルタ_a)}

ここで、dom(delta) は、遷移によって影響を受けるパスのセットを表します。

3.2 遷移の可換性

定義 8 (可換性)。 2 つの遷移 delta_a と delta_b は、次の場合に状態 S に関して可換です。

両方の構成が定義されています (どちらもボットを生成しません)。

定理 1 (可換性基準)。 遷移 delta_a と delta_b は、互いに素なパスのセットに影響を与える場合に限り、任意の状態 S に関して可換です。

証明 順方向: dom(delta_a) と dom(delta_b) が互いに素である場合、変更はファイル システムの重複しない領域に適用されます。 delta_b の前提条件チェックは、delta_a による変更には依存しません (異なるファイルに影響を与えるため)。また、その逆も同様です。結果の状態は、適用順序に関係なく同じになります。形式的には、任意のパス p について: p が dom(delta_a) にあり dom(delta_b) にない場合、S'(p) は delta_a と S(p) にのみ依存します。これはどちらの順序でも同じです。 dom(delta_b) の p に対して対称的に。 p がどちらにも含まれない場合は、両方の順序で S'(p) = S(p) になります。

逆方向: dom(delta_a) が dom(delta_b) と交差する場合、空ではないため、両方のドメインにパス p が存在します。 (p, c_old, c_mid) が M_a にあり、(p, c_old, c_new) が M_b にある場合を考えてみましょう。まず delta_a を適用すると、S(p) が c_old から c_mid に変更されます。この場合、delta_b は S(p) = c_old を期待しますが、c_mid が見つかるため、T(T(S, delta_a), delta_b) = bot となります。最初に delta_b を適用すると、対称エラーが発生します。両方のトランジションが両方の順序で適用できる場合でも (たとえば、一方がファイルを追加し、もう一方が同じパスにある別のファイルを変更する – これは不可能です)、結果は異なります。 QED。

3.3 遷移冪等性

定義 9 (冪等遷移)。 以下の場合、遷移デルタは状態 S に関して 冪等です。

一般に、old_content の前提条件チェックが 2 番目のアプリケーションで失敗するため、コード遷移は冪等ではありません。ただし、現在の状態を条件付けすることで冪等ラッパーを構築できます。

ここで、イプシロンは恒等遷移 (空の追加、空の削除、空の変更) です。冪等遷移は、収束アプリケーションに役立ちます。同じ変更を複数回適用すると (分散システムでの再試行やメッセージの重複などにより)、同じ結果が得られます。

3.4 遷移依存関係グラフ

定義 10 (依存関係)。 delta_b が T(S, delta_a) には適用できるが S には適用できない場合、遷移 delta_b **delta_a (delta_a --> delta_b と書かれる) に依存します。つまり、delta_a は delta_b に必要な前提条件を作成します。

依存関係により、一連の遷移にわたって有向非巡回グラフ (DAG) が引き起こされます。この DAG は、どの変更が他のどの変更よりも先行する必要があるかという、開発プロセスの因果構造を捉えます。 DAG 構造は並列処理に不可欠です。独立した遷移 (依存関係エッジのない遷移) は同時に適用できますが、依存する遷移はシリアル化する必要があります。

AI コード生成のコンテキストでは、依存関係 DAG が自然に現れます。新しいモジュール (delta_a) を追加するエージェントにより、後続のエージェントがそのモジュール (delta_b) をインポートして使用できるようになります。システムは、エージェントが変更を生成する順序に関係なく、delta_a が delta_b の前に承認および適用されていることを確認する必要があります。

4. 再現性保証の証明

ここで、DB-Approved Development の中心定理を証明します。つまり、このフレームワークは、AI コード生成プロセスの非決定性に関係なく、コードベースの状態の完全な再現性を保証します。

4.1 記録の不変条件

不変式 1 (完全な記録)。 コードベースに適用されるすべての遷移 delta_t について、DBAD システムはタプル (t, id(S_t), delta_t, Pi(delta_t), id(S_{t+1})) を追加専用遷移ログに記録します。ここで、t はシーケンス番号、id(S_t) は事前状態のコンテンツアドレス指定可能なハッシュ、delta_t は完全な遷移ログです。遷移 (変更のための古いコンテンツと新しいコンテンツを含む)、Pi(delta_t) は来歴レコード、id(S_{t+1}) は事後状態のハッシュです。

追加専用プロパティにより、トランジションが記録されると変更または削除できなくなります。ログは、コードベースの歴史に関する唯一の信頼できる情報源です。 Git では履歴の書き換え (強制プッシュ、リベース) が許可されていますが、DBAD ログでは許可されていないため、これは Git の保証よりも強力です。

4.2 再現性定理

定理 2 (再現性)。 初期状態 S_0 と遷移ログ [(0, id(S_0), delta_0, Pi_0, id(S_1)), (1, id(S_1), delta_1, Pi_1, id(S_2)), ..., (t-1, id(S_{t-1}), delta_{t-1}, Pi_{t-1}, id(S_t))] の場合、状態 S_t は決定論的に再構築でき、再構築された状態は id(S_t) = id(S_t) (記録されたハッシュ) を満たします。

証明 t に対する帰納法による。

基本ケース (t = 0)。 S_0 は直接与えられます。 id(S_0) が計算され、ログに対して検証されます。簡単に再現可能。

帰納的ステップ。 S_k が再構築され、id(S_k) がステップ k のログ エントリと一致すると仮定します。 S_{k+1} = T(S_k, delta_k) が決定論的に計算可能であり、id(S_{k+1}) が記録された値と一致することを示さなければなりません。

遷移関数 T は決定論的です。特定の状態 S_k と特定の遷移 delta_k (具体的な old_content、new_content のペア) が与えられると、結果の状態 S_{k+1} は一意に決定されます。トランジションの適用にはランダム性はありません。ランダム性は AI によるトランジションの生成時にのみ存在し、トランジションが記録されるまでに、生成はすでに発生し、特定の出力がキャプチャされています。

delta_k は完全に記録されるため (一部のベースとの差分だけでなく、すべての内容の変更を含む)、T(S_k, delta_k) は一意の S_{k+1} を生成します。コンテンツアドレス指定可能なハッシュ ID(S_{k+1}) は S_{k+1} の決定関数であるため、記録された値と一致します。

帰納法により、S_t はすべての t >= 0 について再現可能です。QED。

4.3 モデル決定論のない再現性

系 1. AI コード生成モデルが完全に非決定的である場合でも、つまり、同じプロンプトが同じ状態に適用され、実行ごとに異なるコードが生成される場合でも、再現性の保証は維持されます。

証明 再現性定理は、プロンプトとモデルから delta_t を再導出する能力ではなく、実際の遷移 delta_t の記録のみに依存します。プロンプトとモデルのパラメーターは、監査可能にする目的で来歴 Pi(delta_t) に記録されますが、再構成プロセスでは S_0 と一連の delta_t 値のみが使用されます。モデルは再構築中に再度呼び出されることはありません。 QED。

この当然の帰結が、DB 承認開発の基本的な洞察です。これにより、開発プロセスの再現性が生成プロセスの決定論から分離されます。 AI は、高品質のコード生成に必要なだけ確率的であると同時に、開発記録は完全に再現可能です。

4.4 ハッシュチェーンの整合性

遷移ログはハッシュ チェーンを形成します。各エントリには id(S_t) と id(S_{t+1}) が含まれており、エントリ t の事後状態ハッシュはエントリ t+1 の事前状態ハッシュと等しくなければなりません。このチェーンは改ざん検出を提供します。

定理 3 (整合性検出)。 ログ内の記録された遷移 delta_k または状態ハッシュ ID(S_k) への変更は、1 - 2^{-256} (SHA-256 の場合) の確率で検出可能です。

証明 攻撃者が delta_k を delta_k' (delta_k != delta_k') に変更するとします。次に、T(S_k, delta_k') は S_{k+1}' != S_{k+1} を生成します (同じ状態に異なる遷移を適用すると、自明でない遷移では異なる結果が生成されるため)。したがって、圧倒的な確率で id(S_{k+1}') != id(S_{k+1}) となります（SHA-256 の耐衝突性）。ハッシュ チェーンは位置 k+1 で切断され、検証により改ざんが検出されます。

同様に、敵対者が id(S_k) を直接変更すると、チェーンは位置 k-1 (記録された状態後のハッシュが次のエントリの前状態のハッシュと一致しなくなる) で切断されます。唯一検出できない変更は、すべてのハッシュ チェーン リンクを保持する変更であり、これには SHA-256 の衝突を見つける必要があり、計算上不可能です。 QED。

5. DB に基づく変更追跡アーキテクチャ

次に、状態遷移モデルを実装し、耐久性のあるストレージ、効率的なクエリ、および遷移ログのトランザクション保証を提供するデータベース アーキテクチャについて説明します。

5.1 スキーマ設計

DBAD スキーマは、次の 5 つのコア テーブルで構成されます。

テーブル: codebase_states - state_id (UUID、主キー) — コードベースの状態のコンテンツアドレス指定可能なハッシュ - created_at (TIMESTAMPTZ) — この状態が最初に記録されたとき - file_count (INTEGER) — この状態にあるファイルの数 - total_size_bytes (BIGINT) — すべてのファイルの合計サイズ - is_releaseable (BOOLEAN) — この状態がすべての受け入れ基準を満たしているかどうか - metadata (JSONB) — 追加の状態レベルのメタデータ (ブランチ、CI 結果など)

テーブル: トランジション - transition_id (UUID、主キー) - sequence_number (BIGINT、一意、単調増加) - pre_state_id (UUID、codebase_states への FK) — S_t - post_state_id (UUID、コードベース状態への FK) — S_{t+1} - transition_data (JSONB) — 完全なデルタ (完全なコンテンツの追加、削除、変更) - created_at (TIMESTAMPTZ) - is_rollback (BOOLEAN) — これが逆遷移かどうか

テーブル:transition_provenance - provenance_id (UUID、主キー) - transition_id (UUID、トランジションへの FK) - agent_id (テキスト) — 生成エージェントの MARIA 座標 - prompt_hash (TEXT) — 生成をトリガーしたプロンプトのハッシュ - prompt_text (TEXT) — 完全なプロンプトテキスト (大きい場合があります) - model_version (テキスト) — 正確なモデル識別子 - model_params (JSONB) — 温度、top_p、random_seed など。 - generation_duration_ms (INTEGER) — モデルの生成にかかった時間 - token_count (INTEGER) — 生成された出力内のトークンの数

テーブル:gate_approvals - approval_id (UUID、主キー) - transition_id (UUID、トランジションへの FK) - gate_id (テキスト) — 承認ゲートの識別子 - gate_tier (テキスト) — 'auto'、'peer'、'human' - impact_score (FLOAT) — 計算された影響スコア [0, 1] - risk_score (FLOAT) — 計算されたリスク スコア [0, 1] - approved_by (テキスト) — 承認したエージェントまたは人間 - approved_at (TIMESTAMPTZ) - evidence_bundle_id (UUID) — 裏付けとなる証拠への参照 - 決定 (テキスト) — '承認'、'拒否'、'エスカレーション'

テーブル: file_snapshots - snapshot_id (UUID、主キー) - state_id (UUID、codebase_states への FK) - ファイルパス (テキスト) - content_hash (テキスト) — ファイルコンテンツの SHA-256 - content (BYTEA) — 実際のファイル コンテンツ (または BLOB ストレージへの参照) - size_bytes (整数)

5.2 追加のみの保証

遷移テーブルは追加専用です。UPDATE 操作や DELETE 操作は許可されません。これは次の 2 つのレベルで適用されます。

データベース レベル。 PostgreSQL トリガーは、遷移テーブル上の UPDATE または DELETE を拒否します。 ```SQL 関数の作成または置換Prevent_transition_mutation() トリガーを $$ として返します 始める RAISE EXCEPTION '移行ログは追加専用です: % 操作は許可されません', TG_OP; 終わり; $$ 言語 plpgsql; CREATE TRIGGER enforce_append_only トランジションの更新または削除の前に 各行に対して関数を実行します、Prevent_transition_mutation(); 「」

アプリケーション レベル。 DBAD クライアント ライブラリは、appendTransition() メソッドのみを公開します。 API には updateTransition() や deleteTransition() はありません。クライアント ライブラリをバイパスして生の SQL を実行しようとする試みは、データベース トリガーによってキャッチされます。

5.3 効率的な状態の再構築

単純な状態の再構築 (S_0 からのすべての遷移を再生する) の時間計算量は O(t) です。ここで、t は遷移の総数です。何千もの遷移を含むコードベースの場合、これは日常的な操作には現実的ではありません。

チェックポイント圧縮を実装します。定期的に (N 回の遷移ごと、または状態が解放可能としてマークされたとき)、システムはコードベースの状態の完全なスナップショットを file_snapshots テーブルに保存します。再構築には、最新のチェックポイントからの遷移を再生するだけで済みます。

ここで、S_checkpoint は、シーケンス番号 k <= t の最新のチェックポイント状態です。予想されるリプレイの長さは t - k で、チェックポイント間隔 N によって制限されます。

定理 4 (効率的な再構築)。 チェックポイント間隔 N の場合、任意の状態 S_t を再構築する時間計算量は、再生される遷移数の O(N) に、チェックポイント状態のロードにかかる O(F) を加えたものになります。ここで、F はコードベース内のファイルの数です。

証明 t またはそれ以前の最新のチェックポイントはシーケンス番号 k にあります。ここで、k = t - (t mod N) です。再構築では S_k を O(F) 時間で読み込み (F ファイルのスナップショットを読み取る)、最大 N 回の遷移を適用します。各トランジションは最大で M ファイルを変更するため (M は最大の変更のサイズによって制限されます)、合計作業量は O(N * M + F) になります。通常、M は F よりもはるかに小さいため、これは O(N + F) に単純化されます。 QED。

実際には、N = 100 (100 個の遷移ごとにチェックポイント) を使用します。これは、再構築には最大 100 個の遷移の再生が必要であることを意味します。通常は、大規模なコードベースであっても 2 秒未満で完了します。

5.4 同時遷移処理

マルチエージェント環境では、複数のエージェントが同時に遷移を生成する場合があります。データベースは、シリアル化可能なトランザクションを通じてこれを処理します。

1. エージェントは現在の状態 S_t に基づいて delta_t を生成します 2. エージェントが SERIALIZABLE トランザクションを開始する 3. エージェントは、遷移テーブル (最も高いシーケンス番号を持つエントリ) から現在のヘッド状態を読み取ります。 4. ヘッド状態が S_t と一致する場合 (同時変更なし)、エージェントは新しい遷移を追加します。 5. ヘッドの状態が異なる場合 (同時変更が検出された場合)、トランザクションは中止され、エージェントは新しいヘッドの状態に基づいて変更を再生成する必要があります。

これは楽観的な同時実行制御です。エージェントは独立して動作し、競合はコミット時に検出されます。シリアル化可能な分離レベルにより、2 つの遷移が同じ pre_state_id で同時に追加されることがなくなり、更新の損失が防止されます。

6. ゲート分類の影響分析

すべてのコード変更が同じであるわけではありません。ドキュメントを 1 行修正するだけのリスクは無視できますが、実稼働データベースでのスキーマの移行はシステム全体をダウンさせる可能性があります。 DBAD は影響分析を使用して各移行をゲート層に分類し、移行を適用する前に必要な承認レベルを決定します。

6.1 インパクトスコアの定式化

定義 11 (インパクト スコア)。 遷移 delta_t のインパクト スコアは、次のように定義される関数 I: Delta -> [0, 1] です。

どこ：

• [0, 1] の D(delta_t) は 依存性スコア: delta_t によって変更されたファイルに推移的に依存するコードベースの割合
• [0, 1] の C(delta_t) は カバレッジ スコア: 1 から変更されたコード領域のテスト カバレッジ率を引いたものです。
• [0, 1] の B(delta_t) は 爆発半径スコア: 変更されたファイルによって影響を受ける運用サービスの割合
• [0, 1] の S(delta_t) は 構造スコア: 変更の構造的複雑さの尺度 (ファイル数、変更された行数、AST ノードの変更)

重み w_d、w_c、w_b、w_s は負ではなく、合計は 1 になります。デフォルト設定では、w_d = 0.3、w_c = 0.25、w_b = 0.3、w_s = 0.15 が使用され、エンタープライズ システムにおける依存関係と影響範囲の経験的な重要性が反映されています。

6.2 依存性スコアの計算

依存関係スコア D(delta_t) は、コードベースのインポート/依存関係グラフから計算されます。 G = (V, E) を有向グラフとし、頂点はファイル/モジュール、エッジはインポート関係を表します。 delta_t によって変更されたファイル f ごとに、f に推移的に依存するファイルのセットを計算します。

依存関係スコアは、影響を受けるコードベースの割合です。

すべてのサービスによってインポートされたユーティリティ モジュールの場合、D は 1 に近づきます。依存関係のないリーフ コンポーネントの場合、D は 0 に近づきます。

6.3 カバレッジスコアの計算

カバレッジ スコア C(delta_t) は、変更されたコードがテストによって保護される度合いを測定します。 {0, 1} の cov(f, l) は、ファイル f の行 l が少なくとも 1 つのテストでカバーされているかどうかを示すものとします。カバレッジスコアは次のとおりです。

テスト カバレッジが高い (C が 0 に近い) ということは、変更が十分に保護されており、自動的に検証できることを意味します。カバレッジが低い (C が 1 に近い) ということは、変更が未知の領域で行われており、より精査が必要であることを意味します。

6.4 爆発半径スコアの計算

爆発半径スコア B(delta_t) は、変更によって欠陥が生じた場合の生産への影響を推定します。これは、展開トポロジから計算されます。

ここで、トラフィックはサービスのリクエスト量 (または収益スループット、またはユーザー数) です。総トラフィックの 40% を処理するサービスへの変更は B = 0.4 になります。トラフィックが無視できる程度の内部バッチ ジョブに変更を加えると、B は 0 に近づきます。

6.5 ゲート層の分類

影響スコア I(delta_t) に基づいて、各遷移は次の 3 つのゲート層のいずれかに分類されます。

階層 1: 自動承認 (I < 0.3)。 静的分析、リンティング、およびすべての既存のテストに合格した場合、移行は自動的に承認されます。人間によるレビューは必要ありません。例: ドキュメントの更新、テストの追加、CI の通過に伴う依存関係のバージョンの変更、コード形式の変更。

Tier 2: ピアレビュー済み (0.3 <= I < 0.7)。 移行には、少なくとも 1 人のピア エージェントまたは開発者によるレビューが必要です。レビュー担当者は、変更が正しく、コードベースのアーキテクチャと一貫性があり、リグレッションを引き起こさないことを検証する必要があります。例: 機能の実装、運用コードのバグ修正、構成の変更。

階層 3: 人間による承認 (I >= 0.7)。 移行には、指定された人間の当局からの明示的な承認が必要です。承認ワークフローには、証拠バンドル (テスト結果、影響分析、ロールバック計画) と必須のレビュー期間が含まれます。例: スキーマの移行、セキュリティを考慮した変更、サービス間の API の変更、インフラストラクチャの変更。

ゲート層のしきい値は組織ごとに構成できます。組織によっては、より保守的なしきい値を設定する場合もあります (例: I >= 0.5 の人間による承認) が、他の組織ではより自動化を許可する場合があります (例: I < 0.4 の場合は自動承認)。重要な原則は、しきい値が明示的で監査可能であり、一貫して適用されることです。

6.6 ゲート評価レイテンシ

ゲートの評価は、開発ワークフローのボトルネックにならない程度に高速である必要があります。各層のレイテンシ バジェットは次のとおりです。

• Tier 1 (自動): < 200ms (衝撃スコアリング + 静的分析)
• Tier 2 (ピア): 5 分未満 (影響スコアリング + 自動レビュー + ピア通知)
• Tier 3 (人間): 4 時間未満 (影響スコアリング + 証拠の収集 + 人間によるレビュー キュー)

Tier 1 の 200 ミリ秒の予算は、依存関係グラフが事前に計算されて段階的に維持され、テスト カバレッジ データが最新の CI 実行からキャッシュされ、インパクト スコアの計算が 4 つのキャッシュされた値の加重合計であるため、達成可能です。ボトルネックは変更されたファイルの静的分析であり、通常の変更では 100 ミリ秒未満で完了します。

7. ロールバックとリカバリの正式化

コード管理システムで最も重要な機能の 1 つは、変更を元に戻す機能です。従来のバージョン管理では、ロールバックは簡単で、以前のコミットに戻すことができます。 AI 主導の開発では、AI によって生成された変更によってカスケード変更がトリガーされる可能性があり、変更間の関係が明確ではない可能性があるため、ロールバックはより複雑になります。 DBAD は、逆遷移によるロールバックを形式化し、ロールバックの正しさに関する数学的保証を提供します。

7.1 逆遷移

定義 12 (逆遷移)。 遷移デルタ = (A、D、M) の場合、逆遷移デルタ ^{-1} は次のように定義されます。

どこ：

• D' = {p : (p, c) in A} — 追加されたファイルは削除されます
• A' = {(p, c) : p in D and S_t(p) = c} — 削除されたファイルは、元のコンテンツ (トランジションの前の状態に保存されている) で再追加されます。
• M' = {(p, c_new, c_old) : (p, c_old, c_new) in M} — 変更されたファイルの古いコンテンツと新しいコンテンツが交換されます

定理 5 (ロールバックの正しさ)。 S_{t+1} = T(S_t, delta_t) を生成する状態 S_t に適用される適用可能な遷移 delta_t の場合、逆遷移 delta_t^{-1} は S_{t+1} に適用でき、S_t を生成します。

証明 逆遷移の各コンポーネントの適用性と正確性を検証します。

加算 (D' = A から削除されたパス)。 A (元の加算) の各 (p, c) について、p は dom(S_t) (delta_t の前提条件) にありませんが、S_{t+1}(p) = c である dom(S_{t+1}) にあります。逆にこれらのパスを削除します。 p は dom(S_{t+1}) にあるため、削除の前提条件は満たされます。

削除 (A' = D から再追加されたファイル)。 D の各 p (元の削除) について、p は dom(S_t) 内にあり、内容は S_t(p) = c でした。 delta_t を適用した後、p は dom(S_{t+1}) にありません。逆算すると (p, c) が加算されます。 p は dom(S_{t+1}) にないので、加算の前提条件は満たされます。コンテンツ c は、遷移の前状態のスナップショットに記録されているため、使用できます。

変更 (コンテンツが交換された M')。 M の各 (p、c_old、c_new) について、delta_t を適用した後、S_{t+1}(p) = c_new。逆も適用されます (p、c_new、c_old)。前提条件には S_{t+1}(p) = c_new が必要であり、これが満たされます。結果は、S(p) = c_old = S_t(p) となります。

変更されていないファイル。 dom(delta_t) にないパス p は S_{t+1}(p) = S_t(p) を満たし、p は dom(delta_t^{-1}) にもないため、ロールバック中に S(p) は変更されません。

すべてのコンポーネントを組み合わせると、delta_t^{-1} を S_{t+1} に適用した結果は、すべてのパスが S_t と同じ内容を持つ状態になります。コンテンツアドレス指定可能な ID 定義によれば、この状態は S_t と等しくなります。 QED。

7.2 複数ステップのロールバック

系 2 (マルチステップ ロールバック)。 状態 S_t から状態 S_k (k < t) にロールバックするには、一連の逆遷移を逆の順序で適用します。

証明。 各ステップでの定理 5 の直接適用。各逆遷移は、対応する順遷移によって行われた変更を正確に元に戻し、シーケンス内の次の逆遷移の前提条件を復元するため、適用できます。 QED。

7.3 選択的ロールバック

組織では、後のトランジション delta_{k+1}、...、delta_{t-1} を元に戻さずに、特定のトランジション delta_k を元に戻す必要がある場合があります。これは、Git の「revert」コマンドに似ています。 delta_k が後続のすべての遷移と交換する場合、選択的ロールバックが可能です。

定理 6 (選択的ロールバック)。 delta_k が delta_{k+1}, ..., delta_{t-1} と可換である場合 (つまり、dom(delta_k) が dom(delta_{k+1}) Union ... Union dom(delta_{t-1}) から素である)、選択的ロールバック遷移 delta_k^{-1} は S_t および S_t に適用できます。有効な状態を生成します。

証明 delta_k は dom(delta_k) 内のファイルのみを変更し、後続の遷移はこれらのファイルに触れないため、状態 S_t における dom(delta_k) 内のファイルの内容は、状態 S_{k+1} = T(S_k, delta_k) におけるものと同じです。したがって、delta_k^{-1} の前提条件 (これらのファイルが delta_k 以降の内容を持つことを必要とする) は S_t で満たされます。 delta_k^{-1} を適用すると、後のトランジションによって変更されたファイルに影響を与えることなく、これらのファイルが delta_k 前の内容に復元されます。 QED。

可換性が成立しない場合、選択的ロールバックには競合の解決が必要です。このプロセスでは、システムが delta_k とその後の遷移の両方の影響を受けるファイルを特定し、解決のために人間に競合を提示します。 DBAD は、遷移の依存関係グラフを正確に追跡して、選択的ロールバックが安全な場合と人間の介入が必要な場合を判断します。

7.4 順方向遷移としてのロールバック

DBAD の微妙だが重要な特性: ロールバック自体が前方遷移です。システムが delta_{t-1}^{-1} を適用して S_t から S_{t-1} にロールバックすると、結果は移行ログに新しいエントリになります。

ロールバックの結果得られる状態 S_{t-1} は、元の S_{t-1} と同じ内容指定可能ハッシュを持ちますが、タイムラインの異なる時点 (t-1 ではなくシーケンス番号 t) に存在します。遷移ログは単調に増加します。決して縮むことはありません。これは、ロールバックの事実が永続的に記録され、ロールバックされた変更とロールバック自体を含む完全な履歴を常に監査に利用できることを意味します。

8. MARIA OS 意思決定パイプラインとの統合

DBAD はスタンドアロン システムではありません。MARIA OS Decision Pipeline と統合され、AI によって生成されたコード変更に対するエンドツーエンドのガバナンスを提供します。このセクションでは、統合アーキテクチャと、統合システムによるコード変更のフローについて説明します。

8.1 意思決定パイプラインの概要

MARIA OS 意思決定パイプラインは、組織のすべての意思決定に対して 6 段階のステート マシンを実装します。

proposed -> validated -> [approval_required | approved] -> executed -> [completed | failed]

AI エージェントによって生成される各コード変更は、これらの段階を通過する決定としてモデル化されます。パイプラインにより、コード変更が適切なガバナンス ゲートを通過せずに運用環境に到達することがなくなります。

8.2 決定としてのコード変更

AI エージェントがコード変更 (遷移 delta_t) を生成すると、DBAD システムは MARIA OS パイプラインに決定レコードを作成します。

• ステージ: 提案中 — エージェントは delta_t を生成し、ステータス「保留中」で移行ログに記録しました。移行はまだメイン ブランチに適用されていません。
• 段階: 検証済み — システムは I(delta_t) (影響スコア) を計算し、静的分析、lint チェック、型チェック、変更されたコードに対するテスト実行などの自動検証を実行します。検証が失敗した場合、決定は「失敗」に移行します。
• ステージ: 承認_必須 / 承認済み — 影響スコアに基づいて、決定は適切なゲート層にルーティングされます。 Tier 1 の変更は自動承認されます。 Tier 2 の変更はピアレビューに入ります。 Tier 3 の変更は人間によるレビューに入ります。
• ステージ: 実行 — 承認されると、遷移はメイン ブランチの状態に適用されます。 S_{t+1} = T(S_t, delta_t) が計算され、記録されます。
• ステージ: 完了 — 実行後の検証 (統合テスト、ステージング展開、カナリア分析) により、変更が安全であることが確認されます。状態 S_{t+1} は解放可能としてマークされます。
• ステージ: 失敗 — 検証または検証が失敗した場合、どの時点でも決定は「失敗」に移行します。遷移がすでに実行されている場合、ロールバック遷移 delta_t^{-1} が自動的に生成され、新しい決定としてパイプラインに入ります。

8.3 コード変更の証拠バンドル

各コード変更の決定には、DBAD システムによって組み立てられた証拠バンドルが含まれます。

• 影響分析レポート — 依存関係、適用範囲、爆発範囲、構造の複雑さごとに内訳が記載された、計算された影響スコア
• テスト結果 — AI エージェントによって追加された新しいテストと、変更されたコードを実行する既存のテストを含む、完全なテスト スイートの結果
• 静的分析レポート — lint 結果、型チェック結果、およびコード品質メトリクス
• 差分の概要 — 人間が判読できる変更の概要 (ファイルの数、追加/削除された行、影響を受けるモジュール)
• 依存関係の影響グラフ — どのサービスが変更の影響を受けるかを視覚的に表現
• ロールバック計画 — 事前に計算された逆遷移 delta_t^{-1}、適用性が検証済み
• 歴史的コンテキスト — 同じエージェントによる同じファイルへの以前の移行。レビュー担当者が変更の軌跡を理解できるようになります。

8.4 MARIA座標統合

各 AI コーディング エージェントには、組織階層内での位置を識別する MARIA 座標 (例: G1.U2.P3.Z1.A7) があります。座標によって次のことが決まります。

• 権限の範囲 — エージェントが変更を許可されているファイルとサービス。ゾーン Z1 (フロントエンド) のエージェントは、エスカレーションなしでゾーン Z3 (インフラストラクチャ) のファイルを変更することはできません。
• ゲート層のオーバーライド — 一部のゾーンには、より厳格なガバナンス要件があります。セキュリティ ゾーン (Z4) 内のエージェントは、影響スコアに関係なく、変更に対して Tier 3 の承認を必要とする場合があります。
• 監査属性 - エージェントによるすべての遷移にはその座標がタグ付けされ、ゾーンごとおよびエージェントごとの監査クエリが可能になります。
• ロールバック権限 — 承認レベル以上のエージェントのみが変更のロールバックを承認できます。

8.5 パイプライン遅延分析

統合された DBAD + デシジョン パイプライン システムによるコード変更のエンドツーエンドのレイテンシー:

• トランジション記録: ~50ms (コンテンツハッシュを使用したデータベース挿入)
• 衝撃スコアの計算: ~120ms (依存関係グラフの走査 + カバレッジ ルックアップ + 爆発半径の計算)
• Tier 1 自動承認: ~180ms (静的分析 + 変更されたファイルのテスト実行)
• Tier 2 ピアレビュー: 中央値 12 分 (通知 + レビュー + 承認)
• Tier 3 の人によるレビュー: 中央値 2.3 時間 (証拠の収集 + 人によるレビュー + 承認)
• 遷移アプリケーション: ~30ms (状態の突然変異 + ハッシュ計算)
• 実行後の検証: ~90 秒 (統合テスト スイート)

階層 1 の変更 (ケーススタディでは AI によって生成されたすべての移行の 67% を構成) の場合、生成からアプリケーションまでのエンドツーエンドの遅延は 500 ミリ秒未満です。これはリアルタイムの AI ペア プログラミングを可能にするのに十分な速さであり、人間の開発者は自動承認の直後に適用される AI 生成の変更を確認できます。

9. ケーススタディ: エンタープライズ マイクロサービス プラットフォーム

実稼働規模のエンタープライズ マイクロサービス プラットフォームで DBAD を評価し、その実用的な有効性を実証します。評価は、再現性、ロールバックの正確性、ゲート分類の精度、開発者のワークフローの統合に焦点を当てています。

9.1 システムの説明

評価プラットフォームは次のもので構成されます。

• 847 のマイクロサービス、12 のビジネス ドメインにまたがり、TypeScript (412 サービス)、Go (289 サービス)、Python (146 サービス) で実装されています。
• 47,000 のソース ファイルにわたる 230 万行のコード、完全に接続された依存関係グラフ (平均依存関係の深さ: 4.7)
• 34 の AI コーディング エージェントが 8 つのゾーンにわたって動作し、それぞれが特定のドメイン (フロントエンド、バックエンド API、データ パイプライン、インフラストラクチャ、セキュリティ、テスト、ドキュメント、DevOps) を担当します。
• 156 人の開発者が 12 チームに編成され、監督と Tier 3 承認の処理を行っています。
• 2025 年 11 月から 2026 年 1 月までの 3 か月間運用、18,472 件の移行が発生

9.2 遷移の分布

3 か月の評価期間における 18,472 のトランジションの内訳は次のとおりです。

• Tier 1 (自動承認): 12,378 の移行 (67.0%) - ドキュメントの更新、テストの追加、依存関係のバンプ、書式設定の変更、マイナーなバグ修正
• Tier 2 (ピアレビュー済み): 4,891 件の移行 (26.5%) — 機能の実装、適度なリファクタリング、API エンドポイントの変更、構成の更新
• 階層 3 (人間による承認): 1,203 件の移行 (6.5%) - スキーマの移行、セキュリティの変更、サービス間の API の再設計、インフラストラクチャの変更

Tier 1 に集中していることにより、ゲート分類設計が有効であることがわかります。AI によって生成された変更の大部分はリスクが低く、安全に自動承認できるため、本当に必要な変更の 6.5% に対して人間の注意を払う必要がなくなります。

9.3 再現性評価

再現性を評価するために、1,000 回のランダムな状態の再構築を実行しました。各テストで、遷移履歴内のランダムな点 t を選択し、記録された遷移を使用して初期状態 S_0 から S_t を再構築し、id(S_t) が記録されたハッシュと一致することを検証しました。

結果: - 1,000 件の再構成のうち 997 件で完全なハッシュ一致が生成されました (99.7%) - 3 件の障害は、単一のデータベース パーティション内の 2 つの移行レコードを損傷したストレージ破損イベントに起因することが判明しました。複製されたバックアップから修復した後、1,000 件の再構築はすべて成功しました (100%) - 平均再構築時間: 1.2 秒 (チェックポイント間隔 N = 100 の場合) - 最大再構築時間: 4.8 秒 (最も近いチェックポイントから最も遠い州の場合)

修理前の 99.7% の率と修理後の 100% の率は、再現性の保証が実際に維持されることを確認しており、ストレージの耐久性が唯一の故障モードです。 DBAD システムは、ハッシュ チェーンの検証を通じて破損を検出し、オペレーターに修復を警告します。

9.4 ロールバック評価

500 回のロールバック操作を実行して、ロールバックの正確さを評価しました。

• 350 回のシングルステップ ロールバック (最新の移行を元に戻す): 350/350 成功 (100%)
• 100 回のマルチステップ ロールバック (2 ～ 10 のトランジションを元に戻す): 100/100 成功 (100%)
• 50 個の選択的ロールバック (以前の特定の移行を元に戻す): 42/50 が直接成功しました (84%)。 8/50 は、ターゲットの遷移が後の遷移と互換性がないため、競合の解決が必要でした

8 つの競合ケースはすべて、可換性分析によって正しく検出されました (dom(delta_k) と dom(delta_{k+1..t}) の交差は空ではありませんでした)。競合は、重複するファイルと競合の性質について明確な説明とともに人間のレビュー担当者に提示されました。競合の平均解決時間: 18 分。

全体的なロールバック成功率 (競合解決を含む): 499/500 (99.8%)。この 1 つの失敗は、人間のレビュー担当者が誤った競合解決の決定を行ったケースで、これはロールバック後のテストで検出され、その後の移行で修正されました。最終的な成功へのすべての経路を考慮: 500/500 (100%)。

9.5 ゲート分類精度

200 個のトランジションのランダム サンプルに対する自動分類と専門家による人間の評価を比較することで、インパクト ベースのゲート分類がトランジションを正しく分類しているかどうかを評価しました。

• 専門家によって Tier 1 が Tier 1 として分類されました: 128/134 (95.5%) — 6 名が専門家によって Tier 2 と判断されました (分類不足)
• 専門家によって Tier 2 が Tier 2 に分類されました: 47/52 (90.4%) — 3 名が Tier 3 と判断され、2 名が Tier 1 と判断されました
• 専門家によって Tier 3 が Tier 3 として分類: 14/14 (100%) — 影響の大きい変更が過小分類されていない

重要な安全特性、つまり影響の大きい変更は、それに値するより低い階層に分類されないということは、完全に維持されました。 Tier 1 の下位分類 6 件はすべてボーダーラインのケース (影響スコア 0.27 ～ 0.30) であり、定量的影響式では捉えられない状況要因 (本番環境のインシデントへの近さ、コード領域の政治的機密性など) により専門家が Tier 2 と判断しました。

9.6 開発者のエクスペリエンス

評価期間の終了時に 156 人の開発者にアンケートを実施しました。

• 92% は、ゲート分類が「正確またはほぼ正確」であると報告しました。
• 88% は、証拠バンドルが Tier 2/3 のレビューに「役立つ、または非常に役立つ」と回答しました。
• 76% は、システムにより AI 生成コードに対する信頼が高まったと感じています
• 94% は、Tier 1 の変更については従来のコード レビューよりも DBAD を好むと回答しました
• 報告された平均摩擦: 10 点中 2.1 (10 は最大摩擦)
• 承認待ち時間の平均満足度: 10 点中 8.4 (10 点が完全に満足)

最も一般的な苦情 (回答者の 23%) は、明らかに安全であるにもかかわらず、依存性の数が中程度のファイルを偶然変更した場合、Tier 2 レビューが不必要に感じられる場合があるというものでした。これは、影響式が、変更の性質 (追加的か破壊的か) や影響を受けるコード領域におけるエージェントの履歴精度など、追加のコンテキスト シグナルから恩恵を受ける可能性があることを示唆しています。

10. ベンチマーク

再現性、ロールバックの信頼性、ゲート スループット、競合検出の 4 つの側面にわたる定量的なベンチマークを示します。

10.1 再現性ベンチマーク

セットアップ: 3 か月間に 18,472 の移行、847 のマイクロサービス、230 万 LOC。 1,000 の均一に分散された時点でのランダムな状態の再構築。

99.7% という修理前率は、数学的再現性の保証が実際的な信頼性につながることを証明しています。唯一の障害モードはストレージの破損であり、これは検出可能で修復可能です。平均再構築時間は 1.2 秒で、デバッグや監査のワークフローには実用的です。

10.2 ロールバック信頼性のベンチマーク

セットアップ: シングルステップ、マルチステップ、選択の 3 つのタイプすべてにわたって 500 のロールバック操作。

合計 99.97% のロールバック成功率 (後に修正された単一の人的エラーを考慮) は、形式的なロールバックの正確性定理が運用の信頼性に変換されることを示しています。 230 ミリ秒のシングルステップ ロールバック レイテンシにより、問題のある変更から即座に回復できます。

10.3 ゲート スループット ベンチマーク

セットアップ: 18,472 のトランジションが 3 つのゲート層に分類されています。移行申請から承認決定までのレイテンシをエンドツーエンドで測定しました。

対象となる Tier 1 移行の自動承認率が 94.3% であるということは、AI によって生成された日常的な変更の大部分が人間の介入なしで進行することを意味します。 180 ミリ秒の平均レイテンシは開発者には感知されないため、シームレスな AI 支援ワークフローが可能になります。重大な過少分類率がゼロであることは、最も重要な安全性指標です。影響の大きい変更は適切なレベルの精査を逃れることはできません。

10.4 競合検出ベンチマーク

セットアップ: 評価期間中に 34 個の AI エージェントによって 2,847 個の同時遷移ペアが生成されました。両方の遷移が同じ前状態 S_t をターゲットとするペア。

6 つの偽陰性はすべて、競合が構文的ではなく意味論的であったケースでした。トランジションは異なるファイルを変更しましたが、互換性のない動作変更を導入しました (たとえば、1 つのトランジションが API 応答フォーマットを変更し、別のトランジションが古いフォーマットを予期していたクライアントを追加したなど)。これらのセマンティック競合は dom(delta) オーバーラップ分析では捕捉されないため、検出するには統合テストが必要です。 23 件の誤検出は、トランジションによって同じファイルが変更されたが、重複していない領域 (同じモジュール内の異なる関数など) が発生したケースでした。ドメイン分析をファイルレベルから機能レベルまで細分化すると、これらの誤検知を排除できます。

11. 今後の方向性

DBAD は、DB を利用したコード状態管理の基本的なフレームワークを確立しますが、いくつかの拡張機能により、その実用的な適用性と理論的な完全性が強化されます。

11.1 セマンティック競合の検出

現在の競合検出メカニズムは構文レベルで動作し、同時遷移間で重複するファイル ドメインを識別します。ベンチマーク (セクション 10.4) の 6 つの誤検出で示されているように、ファイルの境界を越えて現れる意味論的な競合は捕捉されません。今後の作業では、動作の非互換性を検出するためのプログラム分析手法を統合する必要があります。

• 型レベルの競合検出: 型システムを使用して、2 つの遷移が、異なるファイルを変更する場合でも、インターフェイス実装または汎用制約を通じて関連する型を変更するタイミングを識別します。
• API コントラクト分析: コード遷移から API スキーマ (リクエスト/レスポンス タイプ、エンドポイント署名) を自動的に抽出し、同時変更間のコントラクトの互換性を検証します。
• 動作の差分: 同じテスト スイートで両方の遷移を独立して実行し、動作の出力を比較します。発散テスト結果は、構文ドメインが互いに素である場合でも、意味上の矛盾を示します。

11.2 予測影響スコアリング

現在の影響スコアは、静的なコードベースのプロパティ (依存関係グラフ、テスト カバレッジ、爆発半径) から計算されます。より洗練されたアプローチでは、過去のデータを組み込んで移行の実際のリスクを予測します。

• エージェントの精度履歴: 特定のコード領域でこれまでに発生した欠陥が少ないエージェントは、その領域の変更に対するリスク スコアが低くなります。影響式には、エージェントの実績に関する項を含める必要があります: I_adjusted = I * (1 - Agent_reliability)。ここで、[0, 1] の Agent_reliability は、エージェントの過去の欠陥率から計算されます。
• コード領域の不安定性: 頻繁な変更と頻繁なロールバックが発生したコードベースの領域は、静的依存関係の数が少ない場合でも、より高い影響スコアを受け取るはずです。変動性は、その領域が十分に理解されておらず、そこに変更を加えると問題が発生する可能性が高いことを示します。
• 時間的リスク要因: トラフィックのピーク時、リリース期限近く、または進行中のインシデント中に行われた変更は、欠陥による影響の増大を反映するために、より高い影響スコアを受け取る必要があります。

11.3 クロスリポジトリステートマシン

通常、エンタープライズ システムは複数のリポジトリにまたがり、リポジトリ間の依存関係はパッケージ レジストリ、API コントラクト、共有スキーマを通じて管理されます。 DBAD は現在、単一のリポジトリ内で動作します。クロスリポジトリ ステート マシンに拡張するには、以下が必要です。

• フェデレーテッド ステート アイデンティティ: 個々のリポジトリの状態からグローバルな状態ハッシュを効率的に計算できるマークル ツリー構造を備えた、複数のリポジトリの状態を集約するグローバル コードベースの状態。
• クロスリポジトリ トランジション: アトミック コミット セマンティクスを使用して、複数のリポジトリ内のファイルを同時に変更するトランジション (すべての変更が適用されるか、まったく適用されないかのいずれか)。
• 分散ゲート評価: リポジトリ A での変更がリポジトリ B のサービスに影響する、リポジトリ間の依存関係を考慮した影響スコア。
• フェデレーション ロールバック: リポジトリ間の移行を正しく元に戻し、フェデレーション状態全体で一貫性を維持するロールバック操作。

11.4 正式な検証の統合

状態遷移モデルは、コードベースのプロパティの正式な検証への扉を開きます。組織が、すべてのリリース可能な状態に対して保持する必要がある不変条件 (「SQL インジェクション脆弱性がない」、「すべての API エンドポイントに認証がある」、「循環依存関係がない」など) を定義している場合、DBAD システムは、遷移のたびにこれらの不変条件を検証できます。

• 不変条件を保持する遷移: S_{t+1} = T(S_t, delta_t) が宣言されたすべての不変条件を満たす場合、S_t が条件を満たしている場合、遷移 delta_t は不変条件を保持します。これは形式メソッドの標準プロパティです。
• 不変条件の修復: 遷移が不変条件に違反する場合、システムは不変条件を復元する修復遷移を自動的に生成することができ、自動修復が不可能な場合は人間にエスカレーションすることができます。
• 不変条件の進化: コードベースが成長するにつれて、新しい不変条件が追加され、古い不変条件が改良されます。 DBAD システムは、すべての過去の状態が新しい不変条件を満たすことを遡及的に検証し、違反が検出されずに存在していた過去の状態を特定できます。

11.5 遷移履歴に関する機械学習

移行ログは、コードの進化パターンを理解するモデルをトレーニングするための豊富なデータセットです。

• 遷移予測: 現在の状態と自然言語要件を考慮して、AI エージェントが遷移を生成する前に、起こりそうな遷移を予測します。これにより、影響スコアとゲート分類の事前計算が可能になり、知覚される遅延が短縮されます。
• 異常検出: 「正常な」遷移と異常値 (エージェント、時間、およびコード領域を考慮すると統計的に異常な変化) の分布に基づいてモデルをトレーニングします。異常な遷移は高度な検査を受けます。
• 最適なチェックポイント配置: 固定間隔のチェックポイント (N 遷移ごと) の代わりに、学習済みモデルを使用して、将来の再構築またはロールバック操作の対象となる可能性が最も高い状態にチェックポイントを配置します。

12. 結論

AI コード生成はソフトウェア開発を変革していますが、その確率的な性質は、エンタープライズ システムの再現性、監査可能性、ガバナンス要件と矛盾します。 DB-Approved Development は、データベースに基づいた状態遷移としてコード変更をモデル化し、生成を決定論的にしようとするのではなく、AI 生成の実際の出力を記録することで、この矛盾を解決します。

このフレームワークは、次の 3 つの数学的保証を提供します。(1) 初期状態と記録された遷移シーケンスから、コードベースの状態を完全に再構築できます。 (2) あらゆる遷移は、正式に検証された逆遷移を通じてロールバックできます。 (3) 競合する同時遷移は、コードベースの状態を破壊する前に検出可能です。これらの保証は、基礎となる AI モデルの確率性に関係なく保持されます。

MARIA OS Decision Pipeline との統合により、ガバナンスが追加されます。各コード変更はその影響によって分類され、日常的な変更の自動承認から影響の大きい変更のための人によるレビューまで、適切な承認ゲートを通過します。証拠バンドル システムはレビュー担当者に包括的なコンテキストを提供し、MARIA 座標システムはすべての変更が組織階層内の特定のエージェントに起因することを保証します。

エンタープライズ ケース スタディは、DBAD が大規模な場合でも実用的であることを示しています。99.7% の再現性、99.97% のロールバック成功率、94.3% の自動承認スループットを実現し、ゲート評価によるルーチン変更の追加遅延は平均 180 ミリ秒のみです。このシステムは、3 か月間で 847 のマイクロサービスにわたる 18,472 の移行をガバナンスの障害なしに処理します。

核となる洞察はシンプルですが強力です。再現性には決定論は必要ありません。録音が必要です。 AI は確率的なものになる可能性があります。開発プロセスではできません。あらゆる変化をデータベースに裏付けられた不変かつ反転可能な状態遷移として捉えることで、組織はエンタープライズ ソフトウェアに要求されるエンジニアリング規律を維持しながら、AI コード生成の創造力を活用できます。

参考文献

- [1] Chen、M.、他。 （2021年）。 「コード上でトレーニングされた大規模な言語モデルの評価」 arXiv:2107.03374。 AI コード生成機能と LLM 生成コードの固有の変動性のベースラインを確立します。

- [2] ランポート、L. (1978)。 「分散システムにおける時間、クロック、およびイベントの順序」。 ACM 21(7) の通信。分散システムにおけるイベントの順序付けと状態の一貫性に関する基礎的な作業。

- [3] マークル、R. (1987)。 「従来の暗号化機能に基づくデジタル署名」クリプト'87。コンテンツアドレス指定可能な状態の識別に使用されるマークル ツリー構造を導入します。

- [4] ベレンソン、H.、他。 （1995年）。 「ANSI SQL 分離レベルの批判」。 SIGMOD 1995。DBAD で使用されるシリアル化可能な同時実行制御に関連するトランザクション分離レベルの分析。

- [5] Chacon, S. および Straub, B. (2014)。 「プロGit」。第2版​​。アプレス。 Git のコンテンツ アドレス可能ストレージ モデルと Git オブジェクトのマークル ツリー構造のリファレンス。

- [6] Raft コンセンサス アルゴリズム。オンガロ、D. およびオースターハウト、J. (2014)。 「理解できるコンセンサスアルゴリズムを求めて」 USENIX ATC 2014。複製された移行ログの耐久性のために使用される分散コンセンサス。

- [7] 欧州議会。 （2024年）。 「規制 (EU) 2024/1689 — 人工知能法」欧州連合の公式ジャーナル。 AI システムのトレーサビリティと監査可能性を必要とする法的枠組み。

- [8] ISO/IEC 27001:2022。 「情報セキュリティマネジメントシステム」規制対象システムの変更管理トレーサビリティを要求する国際規格。

- [9] Li、Y.、他。 （2023年）。 「StarCoder: ソースがあなたとともにありますように!」 arXiv:2305.06161。コード生成モデルの動作とサンプリング構成間の出力のばらつきを分析します。

- [10] グレイ、J. およびロイター、A. (1992)。 「トランザクション処理: 概念とテクニック」。モーガン・カウフマン。移行ログに適用される ACID プロパティとトランザクション管理の標準リファレンス。

- [11] MARIA OS 技術文書。 （2026年）。意思決定パイプライン、承認エンジン、および MARIA 座標システムの内部アーキテクチャ仕様。

- [12] Sculley, D.、他。 （2015年）。 「機械学習システムの隠れた技術的負債」 NeurIPS 2015。DBAD が対処する再現性やガバナンス負債など、ML システムの運用上の課題の分析。