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

「Agentic Engineering Patterns」はどんなガイドか

Simon Willison の「Agentic Engineering Patterns」は、コーディングエージェントを使ってソフトウェアを作るときの、作業の組み立て方をまとめたガイドだ。一度書いて終わりの記事ではなく、更新され続ける前提で書かれている。2026年5月時点では、原則、エージェントの仕組み、テストと検証、コードの理解、注釈つきの実例、日常で使うプロンプト集まで入っている。

この文章は、2026年5月9日にSubstackに書いた読書メモを、このサイト向けに整理し直したものだ。ガイドを読みながら、自分の実践と重なったところを書いている。

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

毎日エージェントで開発していると、便利さより先に、作業の前提が変わっていることに気づく。速くなったあとに何を人間が握り、何をエージェントに渡すのか。このメモで考えたいのはそこだ。

Willison はエージェントを「Agents run tools in a loop to achieve a goal.」と定義している。ゴールに向けて、ツールを繰り返し回すもの、という意味だ。このループを、エンジニアが目的と制約と品質基準に沿って設計し、検証する。それが Agentic Engineering だ。

その反対側にあるのが Vibe coding で、コードへの注意をいったん手放して、LLMに大きく任せる作り方を指す。動けばよしとして、コードは深く読まない。生成物が膨らんでも、まずは触って前へ進む。プロトタイプや週末のプロジェクトには向いているけど、本番で運用するソフトウェアの作り方ではない。

どちらもAIにコードを書かせるところは同じで、違いはその前と後に出る。同じ作業を2つのやり方で並べると、こうなる。

Vibe coding を否定したいわけではない。ただ、運用するソフトウェアに残すなら、実装をエージェントに任せても、何を作るか、どこまで担保するか、どう確かめるかは人間の側に残る。AIツールはその判断を置き換えるものというより、その判断ができる人に強いレバレッジをかけるものだと思う。

コードが安くなったら、何が高くなるのか

定義の次の章「Writing code is cheap now」に、ガイドで一番根本的な主張が出てくる。コードを書くコストが大きく下がった、という話だ。

以前は、数百行のきれいなコードを書くこと自体に時間がかかった。プロジェクトの計画も見積もりも、設計やリファクタリング、テスト追加、ドキュメント整備も、そのコスト感を前提に組まれていた。エージェントはこの前提を崩した。夜にいくつものセッションを走らせておいて、朝に結果を見ることもできる。

ただ、安くなったのは「とりあえず書かれたコード」のほうで、「良いコード」のコストまでゼロになったわけではない。目的に合っているか。将来の変更に耐えるか。エラー処理は妥当か。セキュリティやアクセシビリティを落としていないか。テストに意味はあるか。ここにはまだ判断が要る。

Willison は「AI should help us produce better code」の章で、AIは粗いコードを増やすためでなく、より良いコードを作るために使うべきだとも書いている。命名の統一、重複の整理、APIの見直し、時間を理由に見送っていた小さな改善。人間だけでは後回しにしていた仕事を、エージェントに試させられる。

コードが安くなると、同じIssueから複数のエージェントを走らせて、結果を比べるやり方が自然になる。たとえば、エージェントAには既存の構造に寄せた最小限の変更を、Bには設計を整理してから実装を、Cにはテストと検証ログを厚めに作らせる。

一発で正解を出させる必要はない。正解に近い候補をいくつか作り、人間が選べる状態にする。候補を増やすコストが下がると、判断の仕方も「最初の案を直す」から「複数の案から選ぶ」に変わっていく。

実装が安くなるほど、希少になるのは上流の仕事だ。コードの外側にある設計と、作ったものを手入れし続ける責任が、差をつけるところになる。

エージェントは毎回、文脈を組み立て直している

ガイドの「Working with coding agents」の章は地味だけど、エージェントをブラックボックスとして扱わないための土台になっている。

コーディングエージェントは、LLMにシステムプロンプトとツール定義を渡し、モデルが求めたツールを実行して、その結果をまたモデルへ返す仕組みだ。この仕組みをハーネスと呼ぶ。会話の履歴も、ルールファイルも、ツールの実行結果も、LLMが覚えているわけではなく、ハーネスが毎回文脈として組み立て直している。

そう考えると、うまくいくかどうかはプロンプトの書き方だけでは決まらない。どのツールを持たせるか。どの情報を先に読ませるか。どの作業を新しいコンテキストに切り出すか。どこでキャッシュや履歴が効くか。Agentic Engineering は、モデル単体よりも、ハーネス全体を設計する話でもある。

Git の章もここにつながる。エージェントにとって Git は、保存と復元の道具である以上に、過去の作業や設計判断、失敗と修正の流れを読むための外部記憶になる。新しいセッションに「最近の変更を読んで」と渡せば、git log と diff から文脈を作れる。複数のブランチで別々の実装案を走らせて、あとで比べることもできる。git bisect のような面倒な調査も、失敗する条件さえ渡せば手順に落とせる。

Git を次のエージェントの文脈として使うところは、自分の運用にもかなり近い。エージェントを使うほど、Git の履歴を人間のための記録としてだけでなく、その文脈として整えたくなる。コミットメッセージや PR の説明、検証ログの粒度が、次の作業の速さに効いてくる。

知っていることを、エージェントが読める形で残す

一見キャリアアドバイスに見える章「Hoard things you know how to do」が、実はかなり重要だった。ソフトウェアを作る仕事の大部分は、何が可能かを知っていて、実現方法の大まかな見当がつくことでできている、という話だ。

たとえば、ブラウザで OCR を動かすなら Tesseract.js、PDF を画像にするなら PDF.js、という組み合わせを知っているとする。細かい実装はエージェントに任せられても、その組み合わせを知っていること自体が、出発点として強い。一度理解したトリックを、動くコード例や設計メモとして残しておけば、次に似た問題が来たときにエージェントがそれを読める。

CLAUDE.md や AGENTS.md、スキルファイルは、そのための置き場だ。

ただ、自動生成した長いルールファイルを置くだけでは足りない。効くのは、人間がハマって気づいたこと、チームで議論して決めたこと、ドキュメントに残しそびれた口伝を、あとで使える粒度に直したものだ。大事なのはファイルを作ることより、次の作業で実際に参照される状態にしておくことだと思う。ルールファイルには、触ってよい境界、規約、テストの走らせ方、過去に壊した箇所を書く。社内 Wiki やデータ基盤には、判断の経緯や作業履歴を残す。実行ログや失敗ログは、次のエージェントに読ませる材料にする。

「動きました」をどう確かめるか

Testing and QA の章は、エージェントを毎日使っている人ほど効いてくる。「実装して」とだけ渡すと、動いたように見える成果物が返ってくる。問題は、その「動いたように見える」をどう扱うかだ。

Willison が強調するのは「First run the tests」という短い指示だ。最初にテストを走らせると、エージェントは既存のテストスイートを認識し、プロジェクトの複雑さをつかみ、以降の実装でもテストを足して走らせる方へ寄っていく。

Red/Green の形で、先に失敗を確認してから実装させるのは、テストを形だけにしないためだ。Red を確認しないままテストを書かせると、最初から通るテストを書いてしまうことがある。実装に合わせて書かれたテストでは、確かめる意味が薄い。

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

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

自動テストだけでも、人間の目視だけでも足りない。人間が両端を持ち、間をエージェントに回させる分担に寄せるほど、作業はスケールしやすくなる。

速く書けても、理解が追いつかない

Understanding code の章は、コードを書かせる話から離れて、理解する話をしている。ここで出てくるのが認知債務（cognitive debt）という考え方だ。

認知債務は、エージェントが書いたコードの動きを理解できないまま進むと溜まっていく負債を指す。エージェントは短い時間で数百行を書けるし、それは動くし、テストも通る。でも、書かせた本人は、なぜその実装なのかを説明できない。書く速さと理解する速さの差が、そのまま認知債務として積み上がっていく。

対策の一つは、別のエージェントセッションに、コードを順に追うウォークスルーを書かせることだ。そのとき、説明を記憶に頼らせないようにする。コードスニペットは実ファイルから取らせ、ファイル名や関数名を明示させて、説明と実装の距離を縮める。

アルゴリズムや状態遷移を、HTML で動く図にさせるのも効く。テキストの説明だけでなく、触って分かる理解の補助までエージェントに作らせられるのが面白い。

コードレビューは死ぬのか、変わるのか

Anti-patterns の章で引っかかったのは、レビューの話だった。Willison は、エージェントが生成した大量のコードを、自分で検証しないまま PR に出すことを強く戒めている。動作確認が済んでいること、適切なサイズであること、文脈が説明されていること、その説明文自体も確かめてあること。

この指摘はもっともだと思う。少なくとも今は、検証していない生成物を他人に渡すのは、実作業をレビュー相手に押し付けているのに近い。

一方で、Latent.Space の「How to Kill the Code Review」が書いているように、人間のチェックポイントを、下流の diff 確認から上流の spec、制約、検証ルールへ移す流れも強くなっている。極端に言えば、コードは spec から作られる成果物で、人間が読むべき中心は「何を満たすべきか」に寄っていく。人間が行単位の diff を全部読むやり方は、生成される量に対してスケールしない。

変わるのは、誰がレビューするか、何をレビューするか、どういう流れでやるか、の3つだと思う。一次レビューはエージェントに任せて、人間は最終判断に集中する。

レビューの対象も、行単位の diff から、spec に対して意図どおりに動くかへ移る。ブラウザでどう操作させるか、どの API 応答を確かめるか、どの失敗を拾うべきか。見る範囲は、コードから作業の仕組み全体へ広がる。

人間がレビューから降りるわけではない。レビューの重心を上流へ移して、最終責任を持つ人が、何を承認したのかを説明できる状態にしておく。

書くことから、証明することへ

ガイド全体を読んで最後に残ったのは、verifiability、つまり検証できるかどうかの話だった。AI コーディングで問われるのは、書くことより、出てきたものを誰がどう担保するかのほうに移っている。

AI が作った PR や、クラウドで動く複数のエージェントが増えてくると、人間がローカルで一つずつ動作確認するやり方はスケールしにくい。確認作業そのものも AI に寄せていくことになる。

ただ、担保する層を AI にすると、その層自体を評価する必要が出てくる。レビューエージェントの指摘は妥当か。ブラウザでの検証は本当にバグを拾っているか。複数の案から選ぶ基準は再現できるか。ここを測れないうちは、AI に任せたとは言えない。

AI コーディングが進むほど、評価の比重は上がっていく。これは AI プロダクト開発と同じ構造だ。

Agentic Engineering は、AI にコードを書かせることだけを指すのではなく、AI が書いたものを仕事として成り立たせるための設計だと思う。人間が握るものは、意図、制約、品質基準、理解できること、そして検証の設計へ移っていく。

「Agentic Engineering Patterns」は、AI コーディングの実践知に名前を付けてくれるガイドだ。GoF のデザインパターンがオブジェクト指向の共通言語を作ったように、このガイドは Agentic Engineering の共通語彙になるかもしれない。少なくとも、毎日エージェントを使っているエンジニアなら、「自分がやっていたことに名前があった」と感じるところが多いはずだ。