何が起きたか
VentureBeatに寄稿したAnanth Packkildurai氏（Data Engineering Weekly著者、データエンジニアリング領域のリーダー）は、この2年で「構文を書く摩擦」が崩壊したと述べます。Cursor、Claude Code、Dockerコンテナ内やIDE内で動くエージェント型ワークフローによって、エージェントはリポジトリを横断し、テストを書き、スタックトレースを読み、リファクタを提案できるようになりました。自然言語で指示すれば、エンジニアが関連ファイルを全部開く前に、Kafkaからicebergへのシンクのマッピング案という「それらしい出発点」が出てくる、と同氏は書いています。
そこで残る問いは単純です。エージェントがローカルなシステムロジックの主著者になるなら、エンジニアには何が残るのか。もっともらしいプルリクエストにレビュアーが判子を押すだけの世界に向かっているのか。
「動いている」ことと「仕事をしている」ことは違う
同氏は熱力学の視点を借りて、指向性のある仕事、フィードバック、損失、そして複雑系をまとまりのある状態に保つ境界を語ります。データセンターのLLMは膨大な能力を持つ計算エンジンですが、プロンプト・業務要件・システム指示・落ちているテストといった形で意図を与えられるまで、有用な仕事は一切しません。「エージェントは明らかに動きを生み出す。本当の問いは、その動きを有用な仕事に変える仕組みが周りにあるかどうかだ」というのが同氏の要点です。
そして生まれるのが「オペレーショナル・エントロピー」——古い前提、枝分かれした文脈、未解決の依存関係が、前に進もうとするループの内側に溜まっていく状態です。エージェントは古い前提をなぞり、原因ではなく症状を潰し、過去のマイグレーションを現在の挙動と取り違えることでドリフトし、もっともらしいが互いに矛盾する文脈を積み上げていきます。これを打ち消す補正信号として挙げられているのは、人間の割り込み、落ちるテスト、精密なデータ契約、決定論的なツール、そして「何をどう間違えたか」を正確に返す評価（Evals）です。
賢い猿と、三体問題
有名な無限の猿定理——無限の時間があれば、ランダムにタイプする猿はほぼ確実にシェイクスピア全集を打ち出す——を引きつつ、同氏は現代のエージェントを「コンパイラ、ツール、リポジトリ、テストスイート、フィードバックループを持った、より賢い猿」と表現します。入力スキーマと出力スキーマが既知で、コードベースが小さく、関連する失敗をテストが捕捉できる限定的なタスクなら、提案→実行→観測→修正のループは収束します。探索空間が狭く、完了の定義が目に見えるからです。
問題はエンタープライズにその静けさがないことです。リアルタイムの価格エンジンは、可変な運用状態、サードパーティAPI、遅れて到着するイベント、地域ごとの規制、そして一部はコードに、一部は誰かの頭の中にしかないビジネスルールに依存します。同氏はこれを三体問題になぞらえます。惑星と恒星の二体なら綺麗に予測できるが、三体目を加えた途端に一般解は失われ、配置によっては挙動が混沌とする。クリックストリームは製品の変更で変わり、業務DBは顧客の活動で書き換わり、APIはレート制限とバージョン変更を課し、スキーマは進化し、セキュリティポリシーは動き、レガシーは例外処理の奥に文書化されていないルールを埋めている——現代のデータ基盤は同じ形をしている、というわけです。「環境のほうが、猿がタイプしている間に変わっていく」のです。
テストが緑でも答えが間違う
記事で最も実務的なのは、この仮想例です。エージェントに「収益モデルにcustomer_tierを追加せよ」と頼むと、エージェントは業務DBのstatusフィールドを変換処理にマッピングし、既存の型・NULL許容のテストを通してしまう。コードは綺麗で、パイプラインは緑。しかし答えは間違っています。「データレイクハウスは物理的に整合していながら意味的に誤っていることがある」という指摘の実物です。
これを止めるのはテストではなく契約でした。customer_tierは直近12か月の支出から導出され、ビジネス側の責任者が割り当てられており、アカウントのstatusから埋めてはならない——そう定めたセマンティックデータ契約があれば、その変更はダッシュボードに届く前に弾かれます。同氏の言葉では「エンジニアの貢献は変換処理ではなく、エージェントの間違いを可視化し、具体化し、回復可能にした境界」でした。
新しい仕事は「均衡の設計」
同氏が提示する新���い職務は「均衡を設計すること」、つまり生成されたロジックを信頼できる条件を作ることです。そのための封じ込めの場として挙がるのが、厳格なセマンティックレイヤー、イミュータブルなイベントログ、データ契約、冪等なAPI、決定論的なステートマシン。いずれもエージェントが一度に置かねばならない仮定の数を減らします。入力が明確でルールが明示され、フィードバックが信頼できる境界づけられたドメインさえあれば、エージェントは書かれざる歴史を推測することなく、変換を書き、テストを走らせ、失敗を直し、変更を出荷できる。
結論はこうです。コード生成が安くなってもソフトウェアエンジニアリングの価値は消えず、むしろ可視化される。自律システムがソフトウェアを生成する量は増えていくが、それが成功するか混沌に落ちるかを決める契約・フィードバックループ・境界は、これからもソフトウェアエンジニアが設計する——それが本当に重要な変化だ、と。
💼 事業会社視点：これは自社にどう効くか
経営として読むべき論点は「エンジニアの生産性」ではなく「意思決定に使う数字の信頼性」です。customer_tierの例が示す失敗——業務DBのstatusを流用してテストは全通過、しかし財務が認めない数値——は、日本企業のKPIダッシュボードで最も起きやすい事故です。会員ランク、解約、粗利、有効ユーザー数の定義が、DWHのSQLと事業部のスプレッドシートと担当者の頭の中に分散している会社ほど、エージェント導入で誤りの生成速度だけが上がります。
打ち手は三つです。第一に、主要指標に「直近12か月の支出から導出」レベルの導出根拠とビジネスオーナーを紐づけたセマンティックデータ契約を、まず収益・解約・在庫の10指標程度から定義する。第二に、レビューの評価軸を「コードが綺麗か」から「契約に違反していないか」へ移し、CIで機械的に落とす。第三に、エージェントに任せる範囲を、入力・出力スキーマが既知でテストが失敗を捕捉できる境界内に限定する。
受託開発・SIerには収益構造の話が絡みます。実装工数の切り売りは単価下落が避けられない一方、セマンティックレイヤーとデータ契約の設計、冪等API・イベントログへの移行は、顧客の業務知識を必要とし代替が効きにくい。見積書の主役を「作る工数」から「境界を設計する責任」へ書き換えられるかが、今後2〜3年の粗利率を分けます。SaaS事業者なら、顧客に露出するメトリクス定義とAPIの冪等性が、そのままAI連携時代の信頼性の売り文句になります。