Building Agent-Operable Systems Image generated by Google Gemini

AIエージェントにリファクタリングを任せたらアプリが壊れたなら、レガシーシステムをAIが作業できる環境に変えたいなら、Fortune 500のレガシー維持予算を変革予算に振り替えたいなら――この記事がそのロードマップだ。

ロックされた記憶

ITバブル時代、企業はデジタル資産を積み上げ始めた。コード、データベース、仕様書、ドキュメント、API――数十年にわたって蓄積された企業の記憶だ。

その記憶はロックされていた。探索できず、検証できず、到達不能(unreachable)な状態。人間が直接読み、直接理解し、直接修正する以外に方法がなかった。だからFortune 500のIT予算の60~80%がこのロックされた記憶の維持に使われている。開けられないから、ただ守っている。

今、我々はAIバブルと呼ばれる時代のただ中にいる。この時代の本当の意味はモデルが賢くなることではない。企業の長年ロックされていたlegacyの記憶がreachableな状態に変わり始めるということだ。

だがまだだ。2026年、AIエージェントがコードを書く。68分間で数百万トークンを燃やし、リファクタリングを終えた。アプリが完全に壊れた。毎日Xに上がる話だ。

なぜこれが繰り返されるのか。

エージェントが愚かだからではない。エージェントが作業できる環境ではないからだ。人間が働くオフィスにロボットを入れてはいけない。ロボットが働ける工場を作らなければならない。

ロックされた記憶を開くには、まず記憶が開ける形に変わらなければならない。コードだけの問題ではない。データベース、仕様書、ドキュメント、API――企業のデジタル資産全体がエージェントにとって不透明だ。

Agent-Operableとは何か

エージェントが自律的に作業するには三つの条件が必要だ。

1. 読めなければならない――ノイズなしで

2,000行のファイルから関数一つを見つけるには、1,950行がノイズだ。正規化されていないDBで顧客情報を探すにはテーブルを三つジョインしなければならない。Excelシートに隠されたビジネスルールはエージェントには発見できない。

読めるとは人間が読めるという意味ではない。機械が構造的にパースできるという意味だ。

2. 検証できなければならない――機械的に

エージェントが修正した後、何が壊れたかわからなければdoom loopに陥る。コードにはテストが、DBには制約条件が、APIにはschema validationが、仕様書にはcross-verificationが必要だ。

LLMがLLMを検証するのは、酔った友人に「俺、酔ってる？」と聞くようなものだ。go testはhallucinateしない。CHECK制約は嘘をつかない。JSON Schemaはドリフトしない。

3. 状態が永続しなければならない――エージェントが死んでも

エージェントは必ず落ちる。トークン上限、ネットワークエラー、セッション切断。進行状態が保存されなければ、毎回ゼロからやり直しだ。

エージェントAが関数200番まで処理して死んだら、エージェントBが201番から引き継がなければならない。エージェントは使い捨てだ。だが進捗は蓄積されなければならない。

ステップゼロ：バグを凍結せよ

三つの条件は目的地だ。出発点は違う。ドキュメントなし、テストなし、2,000行のファイルが300個。それが出発点だ。

この状態でエージェントに「リファクタリングしろ」と言えば何が起きるか。10年物のバグを「直す」。問題は、そのバグがバグではないということだ。

Hyrum’s Law：十分に古いAPIのあらゆる観測可能な振る舞いに誰かが依存している。10年放置された小数点丸め誤差にVIP顧客の決済ロジックが紐づいている。日付パースのバグに合わせて作られたExcelマクロが経理部門全体を支えている。古いバグは暗黙のビジネス仕様だ。

エージェントの最初の任務はコードを直すことではない。現在の動作を凍結することだ。

APIを叩く。レスポンスを記録する。そのレスポンスをHurlテストとして固定する。奇怪なバグか意図された動作か――区別しない。ありのまま凍結する。これがratchetの最初の歯だ――エージェントが勝手に「改善」できないようにロックする。

変更を決めるのは仕様を握る人間だけだ。エージェントは実行者だ。判断者ではない。

凍結が終わって初めて、三つの条件――可読性、検証可能性、永続性――に向けた転換が始まる。

コードだけではない

「agent-operable codebase」は出発点だ。企業のデジタル資産はコードだけではない。

資産現在の状態Agent-Operable状態
コード2,000行のファイル、テストなしファイル一つに概念一つ、全関数にテスト
データベース非正規化、ドキュメントなしDDL宣言的管理、マイグレーション自動生成
仕様書Wiki、口頭伝達、ドリフト9つのSSOTをcross-verify、単一identifierでチェイニング
ドキュメントPDFやExcelに隠されたルールスキーマ抽出、機械可読
APIundocumented、暗黙の契約OpenAPIキャプチャ、schema validation

個別に見れば「整理しなきゃ」だ。合わせて見ればシステムだ。

Symbolic Feedback Loop

この転換を可能にする共通構造がある。

LLMが生成する → 決定論的ツールが判定する → 結果をLLMに返す → 繰り返す

コードで、テストで、仕様書で、データで――同じループが動く。

コード構造:    filefunc validate → 違反フィードバック → LLM修正 → 繰り返し
テスト:       go test + coverage → 未カバー行フィードバック → LLM補強 → 繰り返し
仕様整合性:   yongol check → ドリフトフィードバック → LLM修正 → 繰り返し
ユーザールール: rulecat evaluate → 違反フィードバック → LLM修正 → 繰り返し

LLMが関与するのは「生成」だけだ。何を修正するか、パスしたか、次は何か、終わったか――全て機械が決める。LLMに判断権を与えない。

これは発明ではない。C. elegansは302個のニューロンのうち60個(20%)を感覚入力に投資した。生成ではなく検証に。5億年の進化が下した結論だ：ニューロンを増やすよりフィードバック品質を高める方が生存に有利だ。

業界は列車(モデル)をより速くしている。より大きなモデル、より賢いエージェント、より良いプロンプト。だが列車が速くなるほど、線路の方が重要になる。

80/20

最終状態でシステムは二層に分かれる。

SSOT (80~90%)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── 仕様から生成。ドリフトを根元で遮断。エージェントが自由に修正可能。

Custom (10~20%)
├── ビジネスルール、ドメインロジック、法的/政策的計算
└── filefuncで構造化、tsmaでテスト確保。人間がレビュー。

人間が本当に気にかけるべきコードが10~20%に圧縮される。残りはエージェントが仕様を読んで生成し、機械が検証する。

Fortune 500の60%

Fortune 500のIT予算の60~80%がlegacy維持に消費されている。開発者の時間の42%が技術的負債の処理に費やされている。手動のlegacyマイグレーションの70%が失敗する。

この予算は既に使われている。新しい予算は必要ない。方向を変えるだけでいい。保守予算を変革予算に。

legacyを丸ごと投入すれば、agent-operableなシステムが出てくる。それがBuilding Agent-Operable Systemsの約束だ。

なぜBig Techはこれをやらないのか

AnthropicとOpenAIは汎用モデルを作っている。モデルを10%改善すれば全顧客に適用される。だがGo testのfeedback loopを作ればGo開発者にしか適用されない。Pythonのcoverageツールを作ればPythonプロジェクトにしか適用されない。

symbolic verificationは本質的にdomain-specificだ。言語ごと、フレームワークごと、仕様書ごとに異なるverifierが必要だ。汎用性がないからBig TechのROIに合わない。

だからこの領域は空いている。列車を作る人と線路を敷く人は競合ではない。補完関係だ。

問い

あなたのエージェントはコードを書く。だがそのコードが正しいかどうか、誰が確認するのか。

別のエージェント？　それともgo test？

あなたのLLMは100,000行を本当に全部読んでいるのか。

それとも読んだふりをしているのか。

エージェント時代に必要なのは、より賢いエージェントではない。エージェントが働けるシステムだ。

Sources

  • Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
  • Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
  • McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
  • Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
  • Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
  • White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
  • Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
  • METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
  • GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
  • Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks