ソフトウェアエンジニアの役割、コード記述から AI エージェントの境界設計へ

現代のデータプラットフォームのコミット履歴を見れば、ここ2年ほどで劇的な変化が起きていることがわかります。コード記述における摩擦が激減したのです。

Cursor や Claude Code、そして Docker コンテナや IDE 内で動作するエージェントワークフローのおかげで、分散ストリーミングパイプラインの初実装や複雑な API 連携を生成することが、もはや最大のボトルネックではなくなりました。

エージェントはリポジトリ内を移動し、テストカバレッジを作成し、スタックトレースを検査し、リファクタリング案を提示します。Kafka から Iceberg へのシンクマッピングを平易な英語で指示するだけで、エンジニアが関連ファイルを開く前に、信頼できる初期コードをエージェントが生み出せるのです。

これはソフトウェアエンジニアの問いそのものを変えます。

もしエージェントがローカルシステムロジックの主要な作成者になっていくなら、エンジニアに残された仕事とは何でしょうか？ 私たちは、妥当なプルリクエストをひたすら承認するだけのレビューアーに成り果てる業界へと向かっているのでしょうか。それとも、ロジック構築から離れ、より抽象的な領域へ業務がシフトしているのでしょうか。

これに答えるには、熱力学の視点を取り入れると役立ちます。そこには、指向性のある作業、フィードバック、損失、そして複雑なシステムを整合性あるものとして保つ境界線についての言語が存在するからです。

エージェントは熱機関である

AI への擬人化という幻想を取り払えば、残るのは計算エンジンです。指示を受け取り、それを行動に変換する装置なのです。

データセンターに置かれた大規模言語モデル（LLM）には膨大な能力が備わっていますが、意図を与えられるまで実用的な作業は行われません。プロンプト、ビジネス要件、システム指示、あるいは失敗したテストが、エージェントに方向性を示します。その方向性はコード生成、ツール呼び出し、クエリ実行、テスト作成、そして稼働中のシステムへの修正へと変換されます。

すべてのエンジンには損失が生じます。すべてのエージェント・ループにも同様の損失が発生します。

困難なリポジトリに対してエージェントを長時間実行させた経験がある人なら誰でも、この現象を目撃したことがあるはずです。最初は明確なタスクから始まりますが、やがて時代遅れの前提に依存し始めます。原因ではなく症状だけを修正したり、古いマイグレーションを現在の動作と誤解したりします。そして独自の履歴を蓄積していきます。ツール呼び出しを数回行ううちに、文脈には矛盾するがもっともらしい詳細が積み重なり、次のステップの確実性は最初の時点よりも低下します。

これを「運用上のエントロピー」と呼びましょう。これは、まだ前進しようとしているループ内部に、時代遅れの前提、分岐したコンテキスト、解決されていない依存関係が蓄積していく現象です。

人間の介入が有効なのは、新しい情報を導入するからです。失敗したテスト、厳密なデータ契約、決定論的なツール、あるいはエージェントの誤りを明確に指摘する評価も同様に役立ちます。こうしたシグナルがない場合、エージェントは正しい結果から遠ざかりながら出力を生成し続けることになります。

エージェントが明らかに動きを生み出していることは確かです。真の問題は、その周囲のシステムがその動きを実用的な作業に変換できるかどうかです。

無限の猿と加速する探索空間

無限モンキー定理は、その後の展開を捉えるのに役立つイメージを与えてくれます。繰り返しの試行、有限の制約、そしてフィードバックです。

この定理によれば、無作為にキーボードを叩くモンキーが無限の時間をかければ、シェイクスピアの全作品をほぼ確実にタイプし得るとされます。現代のエージェントは、はるかに賢いモンキーのようなものです。コンパイラやツール、リポジトリ、テストスイート、フィードバックループを備えています。彼らの作業は無作為ではありません。フィードバックが次の試行を方向づけるのです。しかし、そのダイナミクスには馴染みがあります。「提案して実行し、観察し、修正し、再び挑戦する」というサイクルです。

制約されたタスクにおいては、このループは驚くほど効果的です。

エージェントに既知の入力スキーマとターゲットスキーマを与え、小さなコードベースと関連する失敗を検出するテストを提示すればよいのです。エージェントはコードを検索し、変更を加え、テストを実行し、その結果を吸収して再び挑戦します。「完了」の定義は明確です。探索空間は狭く、ループが収束するチャンスがあります。

しかし、エンタープライズシステムには、そのような静けさはめったにありません。リアルタイム価格エンジンが依存するのは、可変的な運用状態やサードパーティ製 API、遅れて到着するイベント、地域ごとのポリシー、そしてコードの一部と人の頭の中の両方に存在するビジネスルールです。データレイクハウスは物理的には整合していても、意味論的には誤っている可能性があります。パイプラインはテストを通過しても、財務部門が認識しない数値を生み出すことがあります。

モンキーがタイピングしている間に環境は変化し続けるのです。

エンタープライズロジックにおける三体問題

これが、なぜ「三体問題」がエンタープライズソフトウェアにとって有用なイメージとなるのかの理由です。

惑星と恒星という 2 つの天体であれば、数学的な記述によってその運動を予測することは可能です。しかし、3 つ目の天体が加わると問題は劇的に複雑になります。一般的な閉じた解は存在せず、特定の配置ではカオス的な振る舞いを示すこともあります。ある場所でのわずかな変化が、別の場所で全く異なる軌道を生み出すのです。

現代のデータプラットフォームも同じ構造を持っています。クリックストリームデータは製品の変化に応じて変動し、運用データベースは顧客の活動によって書き換えられます。API はレート制限を課し、バージョンが頻繁に更新されます。スキーマは進化し、セキュリティポリシーも変化します。さらに、長年例外処理の中に埋もれて誰も文書化していないルールを持つレガシーシステムが存在します。

各システムはお互いに圧力をかけ合っています。ある場所の変更が、別の場所の意味や振る舞いを変えてしまいます。局所的な機能追加の要望から始まったことが、最終的にはシステム全体を揺さぶることになるのです。

仮定の話を考えてみましょう。エージェントに収益モデルに customer_tier フィールドを追加するよう指示が出たとします。エージェントは運用データベース内の status というフィールドを見つけ、それを変換処理にマッピングし、既存の型と nullability のテストも通過させます。コードは美しく、パイプラインも正常です。しかし、答えは依然として間違っています。

セマンティック・データ契約とは、顧客ティア（customer_tier）が過去 12 か月の支出額から導出されること、担当するビジネスオーナーが明確に割り当てられていること、そしてアカウントステータスから値を埋め込むことができないことを示すものです。この契約により、変更はダッシュボードに到達する前に拒否されます。エンジニアの貢献は変換処理そのものではなく、エージェントのミスを可視化し、具体的に特定し、回復可能にする境界線を設計した点にあります。

新たな使命：均衡の設計

ソフトウェアエンジニアの仕事はもはや、すべてのマイクロロジックを一つずつ記述することではありません。こうした作業は、より高速に実行できるエージェントが担うようになっていきます。新たな使命である「均衡の設計」とは、生成されたロジックを信頼できる状態にするための条件を整えることです。

ビジネス要件の変化が、エージェントがフィードバックを取り込む速度よりも速い場合、エンジニアは封じ込めのフィールド（領域）を構築する必要があります。厳格なセマンティック層、不変のイベントログ、データ契約、冪等性を持つ API、そして決定論的な状態機械は、単なるプラットフォームの衛生管理ではありません。これらは、エージェントが一度に仮定しなければならない事柄の数を減らす役割を果たします。

これにより、複雑に絡み合った問題を、明確な入力と明示的なルール、信頼できるフィードバックを備えた境界のあるドメインへと変換できます。

このドメインが存在すれば、エージェントは真に強力なものとなります。表やサービス一つひとつの暗黙の履歴を推測する必要なく、変換処理の記述、テストの実行、障害の修復、そして変更のリリースが可能になります。

コード生成が安価になるにつれてソフトウェアエンジニアリングの価値が消えるわけではありません。むしろその価値はより顕在化し、それが実際に重要な転換点なのです。

自律システムがソフトウェアを生成するケースは増えるだろう。しかし、そのソフトウェアが成功するか混沌に陥るかを決定づける契約、フィードバックループ、そして境界線は、依然としてソフトウェアエンジニアによって設計されることになる。

アナン・パックキルドゥライ氏はデータエンジニアリングのリーダーであり、ライター、また『Data Engineering Weekly』の著者だ。現代のデータプラットフォームや大規模パイプライン、AI を駆使したアーキテクチャに関する洞察を発信している。