「Agentic Engineering Patterns」を読んで考えた、AIコーディング時代の開発の型

Simon Willison の「Agentic Engineering Patterns」は、AIコーディングを単なる便利ツールではなく、ソフトウェア開発の作業設計として捉え直すためのガイドです。

元のSubstackでは、ガイドを読みながら自分の実践と重なる部分を書きました。ここでは、そのメモをこのサイト向けに整理し直します。

焦点は「エージェントを使うと速い」ではありません。速くなったあとに何を人間が握るのか、そして何をエージェントに渡すのかです。

AIエージェントによる開発を毎日使っていると、便利さより先に、作業の前提が変わっていることに気づきます。

コードを書くこと自体は安くなる。一方で、仕様を決める、品質を定義する、検証を設計する、理解できないコードを残さない、といった仕事は消えない。むしろ重くなる。

「Agentic Engineering Patterns」は、単発の記事というより、更新を前提にした常緑のガイドです。

この記事を書いている2026年5月時点では、原則、作業の仕組み、検証、コード理解、注釈つき実例、付録まで含まれています。

並んでいるのは、AIコーディングを仕事として成立させるための基本動作です。

コードを書く前の原則、エージェントの仕組み、Gitとサブエージェント、テストと手動検証、コード理解、具体的なプロンプト例まで扱っている。

読んでいて面白いのは、話題の中心が「どのAIツールがよいか」ではないことです。むしろ、エージェントに仕事を渡すために、ソフトウェア開発の基本動作をどう組み替えるかが主題になっている。

ここからは、特に自分の実践と重なった部分を中心に書きます。

コードが安くなること、知識を蓄積すること、テストと手動検証を組み合わせること、認知債務とレビューの位置づけが変わること。このあたりが、今の自分にとっての核心です。

定義に続く章で、最も根本的な主張が出てきます。コードを書くコストが大きく下がった、という話です。

以前は、数百行のきれいなコードを書くこと自体に時間がかかりました。そのコスト感が、プロジェクト計画、見積もり、設計、リファクタリング、テスト追加、ドキュメント整備の前提になっていた。

エージェントはこの前提を壊しました。実装、リファクタリング、テスト追加、ドキュメント作成を、同時に複数走らせることができる。夜にいくつかのセッションを走らせておき、朝に結果を見ることもできる。

ただし、「どんなコードでも」のコストは下がったが、「良いコード」のコストまでゼロになったわけではありません。

目的に合っているか。将来の変更に耐えるか。エラー処理は妥当か。セキュリティやアクセシビリティを落としていないか。テストは意味を持っているか。ここはまだ判断が要る。

同じPrinciplesの中で、WillisonはAIを粗いコードを増やすためではなく、より良いコードを作るために使うべきだとも書いています。

命名の統一、重複の整理、APIの見直し、後回しにしていた小さな改善。人間だけでは時間を理由に見送っていた仕事を、エージェントに試させられる。

コードが安くなるほど、希少になるのは「どのコードを書くべきか」を決める力です。

実装が安くなるほど、希少資源は上流に移っていきます。何を作るか。どう進化させるか。どの品質で出荷するか。コードの外側にある設計とスチュワードシップこそが差別化要因になる。

だから、同じIssueから複数のエージェントを走らせ、結果を比較する運用が自然になります。一つの案に賭けるより、複数案を見て選ぶ。

エージェントAは最小変更、エージェントBは設計整理から、エージェントCはテストを厚めに。結果を比べ、良いところを採る。

重要なのは、一発で正解を出させることではありません。正解に近い候補を複数作り、人間が選べる状態にすることです。オプショナリティのコストが下がると、意思決定の仕方そのものが変わる。

Testing and QA の章は、エージェントを日常的に使っている人ほど重要になります。

エージェントに「実装して」とだけ渡すと、動いたように見える成果物が返ってきます。問題は、その「動いたように見える」をどう扱うかです。

Red/Green の形で先に失敗を確認してから実装させる。Willison は「First run the tests」という短い指示を強調しています。
まずテストを走らせる。既存のテストスイートを認識させる。プロジェクトの複雑さを把握させる。以降の実装でもテストを追加・実行する方向へ寄せる。

Red を確認しないままテストを書かせると、すでに通るテストを書いてしまう危険があります。
エージェントは賢いので、実装に合わせてテストを書くこともできてしまう。それではテストの意味が薄い。

もう一つ重要なのが、Agentic manual testing です。自動テストが通っても、意図通りに動いているとは限らない。
Web UIならブラウザを実際に操作させる。APIならリクエストを叩かせる。コマンドと出力をMarkdownに残させる。エージェントの「動きました」を、証跡に変える。

自分の実践でも、最初にspecを書き、ブラウザ操作まで含めたVerifyシナリオを定義してから実装に入ることが多くなっています。
エージェントに「このspecのVerifyを全部Greenにして」と渡す。逆に、specなしで「いい感じにして」と投げると、作業が散らばりやすい。

自動テストだけで十分ではないし、人間の目視だけでも足りない。
エージェントが作り、エージェントが動かし、エージェントが記録し、人間が判断する。この分担に寄せるほど、作業はスケールします。

ガイド全体を読んでいて、最終的に残るのは verifiability の話でした。AIコーディングの重心は「書くフェーズ」から「出てきたものをどう担保するか」に移っている。

コーディング自体は、汎用ツールでそれなりに動くものが作れる時代になった。重要なのは、誰がどう担保するかです。

AIが生成したPRや、クラウド上で動く複数のエージェントが増えてくると、ローカルで人間が一つずつ動作確認するモデルはスケールしにくくなります。

ブラウザを起動し、自動操作で挙動を検証し、結果をログとして残す。確認作業そのものも、AIに寄せていく。

ただし、担保レイヤーをAI化すると、その担保レイヤー自体を評価する必要が出てきます。

レビューエージェントの指摘は妥当か。ブラウザ検証は本当にバグを拾っているか。複数案から選ぶ基準は再現可能か。ここを測れない限り、「AIに任せた」とは言えない。

AIコーディング時代でも、評価からは逃げられない。むしろ、AIコーディングが進むほど評価の比重は上がる。

これはAIプロダクト開発と同じ構造です。

「Agentic Engineering Patterns」は、AIコーディングの実践知に名前を与えてくれるガイドです。

GoFデザインパターンがオブジェクト指向の共通言語を作ったように、このガイドはAgentic Engineeringの共通語彙になりうる。

少なくとも、日常的にエージェントを使っているエンジニアにとっては、「自分がやっていたことに名前があった」と感じる箇所が多いはずです。