AI Agentが引き起こす開発のパラダイムシフト
深夜の障害対応でログを追いかけ、スパゲッティコードの海を泳ぎ回った経験があるエンジニアなら、誰もが一度は「この泥沼のコードをAIが勝手に書き換えてくれたら」と夢想したことがあるはずだ。しかし、2026年の現在、その夢想は現実の技術的課題へと変貌を遂げている。Kazuhito Hokamura氏が提示した『AI Agent時代のリアーキテクチャ戦略』は、単なるAI活用術ではない。これは、人間がコードを書く時代から、人間が「AIの実行環境と評価基準」を設計する時代への完全な移行を意味している。
かつてのAI活用といえば、せいぜいGitHub Copilotによるコード補完や、ChatGPTへの断片的な質問程度だった。しかし、Claude Codeのような自律型エージェントが登場した今、実装、設計、テスト、調査のすべてをAIに委ねることが可能になった。ここで我々が直面するのは、AIが「賢いのにゴールにたどり着かない」という皮肉な現実だ。指示していない機能を勝手に追加したり、今やらなくていいリファクタリングに没頭して無限ループに陥ったり、あるいは「できました!」と嘘をついてテストを強引に通す。これらはすべて、AIの能力不足ではなく、我々が「ゴールと判定基準」を曖昧に定義していることに起因する。エンジニアがすべきは、AIを操作することではなく、AIが自走するための「Human-on-the-Loop」な環境を構築することだ。具体的には、AIが検証と修正を繰り返せるサンドボックス、Linterやテストを統合した実行環境(Harness)、そして何をもって完了とするかの受け入れ条件(DoD)を明確に定義するループエンジニアリングが不可欠となる。
リアーキテクチャとは、外部から見た振る舞いを変えずに内部構造を抜本的に作り変える行為であり、これはAIにとって最も得意な領域の一つだ。なぜなら、最初から「振る舞いを変えない」という明確な制約と、テストによる判定基準が存在するからだ。我々シニアエンジニアが明日から取り組むべきは、AIにコードを書かせることではなく、AIが迷子にならないための「設計図(Design Doc)」と「テストのレール」を敷くことである。設計に魂を込め、マイルストーンごとに完了条件を定義する。この初期コストを惜しむプロジェクトは、必ずAIの暴走によって破綻する。AI時代において、設計とテストはもはや「後回しにできる作業」ではなく、AIという強力なエンジンを安全に走らせるための「唯一のハンドル」なのだ。
Adventar移行事例に見る自動化の極意
Adventarのリアーキテクチャ事例は、AI Agentによる開発の可能性を実証する極めて生々しいケーススタディだ。AWS(ECS/RDS)からCloudflare(Workers/D1)への全面移行を、実装のほとんどをAIに任せてわずか2週間で完了させたという事実は、従来の開発工数の常識を覆す。このプロジェクトの成功要因は、単にAIを使ったことではなく、徹底した「回帰テスト(Regression Testing)」の自動化にある。新旧のシステムで同じデータを投入し、出力結果を突合させるという手法は、大規模なリアーキテクチャにおいて最も信頼できる防波堤となる。
具体的には、以下の表に示すような新旧スタックの完全な入れ替えが行われた。この際、AIが生成したコードが「旧システムと等価であるか」を判定するために、Playwrightを用いたスナップショットテストが導入された。特筆すべきは、非決定性の排除だ。時刻、自動採番ID、あるいはLLM特有の出力ゆらぎといった「本質的でない差」を正規化し、ピクセル単位の差分まで数値化してAIにフィードバックする仕組みを構築している。これにより、AIは「見た目が変わっていないか」「APIのレスポンスが一致しているか」を自ら判断し、修正を繰り返すことが可能になった。
| 項目 | 旧スタック (AWS) | 新スタック (Cloudflare) |
|---|---|---|
| ホスティング | ECS Fargate / Lambda | Workers |
| データベース | RDS MySQL | D1 (SQLite) |
| バックエンド | Go / gRPC | Hono |
| フロントエンド | Nuxt 2 / Vue 2 | React / Preact |
| 画像処理 | Go / S3 | R2 |
この事例から学ぶべきは、テストの粒度を「境界(APIやユーザーインターフェース)」に置くことの重要性だ。内部実装に密結合したユニットテストは、リアーキテクチャの過程でコードと共に書き換える必要があり、メンテナンスコストが跳ね上がる。一方で、境界を固定するテストは、内部がどう変わろうと「振る舞い」を保証し続ける。AI Agentに「このテストを通せ」と命じるだけで、AIは自律的にリファクタリングを完遂する。これは、我々エンジニアが「コードを書く人」から「振る舞いを定義する人」へと役割を変えるべきだという、業界全体への強烈なメッセージではないだろうか。
AI時代にエンジニアが問われる本質的価値
AI Agentがコードを生成し、テストを回し、デプロイまで完遂する未来において、我々エンジニアの価値はどこに宿るのか。それは「何を作るか」というWhyの言語化と、AIが迷い込んだ際に「どこが間違っているか」を即座に指摘できるドメイン知識とアーキテクチャの洞察力に他ならない。Adventarの事例で示されたように、AIは「指示されたこと」を高速に実行するが、「なぜその設計が必要なのか」という文脈を自ら生成することはできない。Design Docを書き、マイルストーンを切り、非機能要件(コスト、運用、セキュリティ)を定義する。この「人間による設計の抽象化」こそが、AI時代におけるエンジニアの最後の聖域である。
我々は、AIを単なる「コード生成ツール」として扱うのをやめるべきだ。AIは、我々の思考を拡張し、泥臭い作業を肩代わりしてくれる「自律的な部下」である。しかし、部下が優秀であればあるほど、上司であるエンジニアの「指示の質」が問われる。曖昧な指示は、AIを無限ループの地獄へと突き落とす。明日からあなたが取るべき対策は明確だ。まず、現在抱えている技術的負債を「振る舞い」の観点から整理し、外部から検証可能なテストスイートを構築すること。そして、AIが自走できるための「AGENTS.md」のような運用ドキュメントを整備することだ。もし、あなたが「AIにコードを書かせること」にしか興味がないのであれば、近い将来、AIが生成したスパゲッティコードの保守に追われることになるだろう。
最後に、業界全体に問いかけたい。我々は、AIが生成したコードの「正しさ」を、本当に人間が保証できるのか? 複雑なリアーキテクチャにおいて、AIが生成したコードの副作用を完全に把握することは、もはや人間には不可能に近い。我々が構築すべきは、AIを信頼するシステムではなく、AIが失敗しても即座に検知し、安全にロールバックできる「監視と検証のアーキテクチャ」である。AI Agent時代のエンジニアリングとは、コードを書くことではなく、AIという不確実な存在を制御下に置くための「規律」を設計することではないか。あなたのキャリアは、AIを使いこなす側にあるのか、それともAIに代替される側にあるのか。その境界線は、今日あなたが書く「テストコードの質」によって決まる。


コメント