コーディングAIエージェントの支援を受けてソフトウェアを開発する手法「エージェントエンジニアリング」とは？

AIにコードを書かせること自体はすでに珍しくありませんが、最近は書いたコードを自分で実行し、その結果を見ながら修正まで進めるAIツールも登場しています。こうしたAIの支援を受けながらソフトウェア開発を進める考え方が「エージェントエンジニアリング」です。ウェブ開発者のサイモン・ウィリソン氏は、Claude Code・OpenAI Codex・Gemini CLIのようなコーディングAIエージェントを活用することで、人間は「何を作るかを決める」「必要な道具を整える」「出てきた結果を検証する」役割をより強く担うようになると主張しています。

What is agentic engineering? - Agentic Engineering Patterns - Simon Willison's Weblog
https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/

◆エージェントエンジニアリングとは何か？
ウィリソン氏はエージェントエンジニアリングを、コードを書くだけでなく、そのコードを実行して結果まで確かめられる「コーディングAIエージェント」の支援を受けながら、ソフトウェア開発を進める考え方だと説明しています。

なお、ここでいう「エージェント」とは、AIに指示を与えると、そのAIが必要に応じて外部ツールも使いながら作業を進める仕組みのことです。コーディングAIエージェントの場合は、そのツールの中にコードを実行する機能も含まれます。

ウィリソン氏によると、この「実際にコードを動かせる」という点こそがエージェントエンジニアリングを成り立たせる重要な要素とのことです。AIがコードを出力するだけなら使い道は限られますが、AIが自分でコードを動かし結果を見ながら修正できるようになると、実際に使えるソフトウェアの開発に向けて試行錯誤を進めやすくなります。

その上でウィリソン氏は「コードを書くこと」そのものはソフトウェア開発の仕事の一部にすぎないと強調しており、本当に重要なのはどんな問題をどんな方法で解くのかを見極めることだとしています。AIがコードを大量に出せるようになっても人間の役目が消えるわけではなく、必要な道具を整え、問題を分かりやすく伝え、出てきた結果を検証し、信頼できる形に仕上げるという仕事が残るとウィリソン氏は述べています。

◆今やコードを書くのは安い
ウィリソン氏がエージェントエンジニアリングの前提として挙げているのが、「今やコードを書くコストは安い」という認識です。これまでは数百行のきれいでテストされたコードを書くのに、開発者が丸一日以上を費やすことも珍しくありませんでした。そのため、設計や見積もり、優先順位づけも「コードを書くコストは高い」という前提で組み立てられてきました。

しかし、コーディングAIエージェントは少なくとも「人間がキーボードをたたいてコードを入力する手間」を大きく減らします。しかも複数のエージェントを同時に動かせば、1人の開発者が複数の実装やコード整理、テスト、文書作成を並行して進めることも可能になります。

ただし、ウィリソン氏は新しいコードを作るコストがほぼゼロに近づいたとしても、良いコードを作るコストまで消えたわけではないと指摘しています。ウィリソン氏が挙げる良いコードの条件には「正しく動くこと」「正しく動くと確認できること」「求められている課題をきちんと解決していること」「エラー時の挙動が妥当であること」「シンプルで将来も直しやすいこと」「テストが整備されていること」「ドキュメントが現状に合っていること」などが含まれます。AIによってコード生成にかかるコストが安くなっても、良いコードを作るための品質確認や問題設定まで自動で済むわけではありません。

ウィリソン氏は、「コードを書くコストが安くなった」という変化に合わせて、個人や組織の習慣も変えていく必要があると述べています。これまで「時間がかかるから後回し」とされていた作業でも、まずはAIエージェントに試させてみるという姿勢が有効だというわけです。

◆自分ができると知っていることをため込め
エージェントエンジニアリングで重要な原則として、ウィリソン氏は「自分ができると知っていることをため込め」と主張しています。ソフトウェア開発では「何ができるか」「どうやれば実現できるか」を知っていること自体が大きな武器になるからです。

しかも、理論上できると知っているだけではなく、実際に動くコードとして確かめた経験があるとその知識はさらに役立つとのこと。ウィリソン氏は、そうした知識の蓄積先としてブログや学んだことを記録するメモ、GitHubリポジトリ、さらにAIで作ったHTMLツール集を挙げています。

これらは個人用のメモとしてだけではなく、新しいものを作る際にAIエージェントへ渡す実例集としても使えます。実際にウィリソン氏は「動作確認済みの既存のものを2つ以上組み合わせて新しいものを作らせる」のがお気に入りのやり方の1つだと説明しています。

◆AIはより良いコード作りに使うべき
AIにコードを書かせると品質が落ちるのではないかという不安はよく聞かれます。しかしウィリソン氏は、もしコーディングAIエージェントの導入によって実際に品質が下がったなら、それは「AIを使ったから仕方ない」のではなく開発の進め方のどこかに問題があるのでそれを直すべきだと主張しています。

ウィリソン氏は技術的負債を最初から抱え込まないことを重視しています。技術的負債とは、後回しにすることであとで大きな手間になるコード上の問題のこと。たとえば、同じような処理が増えてしまうことや、似た機能が少しずつ重複していくこと、1つのファイルが大きくなりすぎることなどが含まれます。

こうしたコードの整理や改善こそコーディングAIエージェント向きだとウィリソン氏は述べています。コードを改善するコストが大きく下がったことで、小さな問題でも放置せずその場で直しやすくなったわけです。

さらにウィリソン氏は、AIやコーディングAIエージェントが複数のやり方を試しやすくする点も重視しています。コードの問題は実装中のミスだけでなく、設計段階でより簡単な方法を見落としたり、その機能に向かない技術を選んだりすることでも生まれるからです。

ウィリソン氏が特に強調しているのは、試作をたくさん試せることです。たとえば、大量のアクセスが集まる仕組みに高速処理向けのデータ保存システムであるRedisが向いているかどうかは、議論だけで決めるよりもまず試作品を作って確かめた方が確実。コーディングAIエージェントならこの種の検証用の試作をより低コストで複数案試せるため、設計段階の見落としを減らしやすくなるとウィリソン氏は述べています。

◆避けるべきアンチパターン
一方でウィリソン氏はAIの悪い使い方も挙げており、その代表例がAIが生成した未確認のコードをそのまま共同開発者に渡すことです。自分で確認していない数百行、数千行のコードを変更案として出すのは実質的に他人へ本来の仕事を押し付けているのと同じだとウィリソン氏は強く批判しています。

ウィリソン氏はコードの良い変更案として、「コードが動くことに自分で確信を持っていること」「変更が小さく確認しやすいこと」「何のための変更なのかが分かること」、さらに「AIが書いた説明文まで自分で確認していること」を挙げています。さらに、手動で試した内容のメモやスクリーンショット、動作動画など、自分で確かめた証拠を添えることも有効だとしています。

つまり、AIエージェントを使うことでコードを大量に出せるようになったとしても、他人に見せる前に確認する責任はあくまで自分にあるということです。AIがそれらしく書いた説明文まで含めて未確認のまま他人に回すのは、確認する側の時間を無駄にする行為だとウィリソン氏は主張しています。