「AIにコードを書かせる」と聞くと、「プロンプトを投げて、出てきたコードを見もせずに動かす」いわゆる vibe coding（バイブコーディング）を思い浮かべる人が多いはずです。ところが、Django（Pythonの代表的なWebフレームワーク）の共同開発者であり、AI界でもっとも読まれているブロガーの一人、Simon Willison氏は2026年2月、それとははっきり区別した Agentic Engineering（エージェンティック・エンジニアリング） という言葉を掲げ、コーディングエージェントから最良の結果を引き出す「実践パターン集」を新プロジェクトとして公開しました。この記事では、そのガイド「Agentic Engineering Patterns」の骨子を、エンジニアではない方にも読めるように、そして現場のエンジニアが明日から使える形で読み解きます。図を3枚つけたので、まず図だけ眺めてもらっても全体像はつかめます。
※この記事は原文の翻訳ではなく、株式会社Four Youによる要点の紹介と解説です。ガイドは著者自身が「どの章も完成ではなく、随時更新する」と明言している「生きた文書」で、本記事は2026年9月時点の内容に基づいています。原文リンクは記事末尾にあります。
1. Simon Willisonとは誰か、なぜこのガイドが重要なのか
Willison氏は2000年代にDjangoを共同開発し、その後もオープンソースのデータツール（Datasette、LLMコマンドラインツールなど）を作り続けてきた開発者です。2023年以降は、生成AIの動きを毎日のように自分の手で検証してブログに書き続けており、「プロンプトインジェクション」や「Lethal Trifecta（致命的な三点セット）」といった、AIのセキュリティを語るときに欠かせない概念を広めた人物でもあります。
そのWillison氏が今回始めたのは、ブログ記事ではなく「ガイド」という新しい形式です。1994年の名著『デザインパターン』（Gang of Four）を意識し、「特定の問題に対する具体的な解決策」を章ごとに書き、時間が経っても書き換えていく。技術ブログの記事は半年で古くなるが、パターンは残る──という発想です。技術クラスタの「ネタ元」として一級品なのは、この「流行を追わず、道具が進化しても残る型だけを集める」姿勢にあります。
2. Agentic Engineeringの定義：「コードを書けて、実行もできる」がすべて
Willison氏の定義はシンプルです。
コーディングエージェントとは、コードを「書く」だけでなく「実行」もできるAIツールのこと。代表例はClaude Code、OpenAI Codex、Gemini CLI。
エージェントとは何かについては、AI研究者が1990年代から揉めてきた難問ですが、氏が採用する定義は一文です──「エージェントとは、ゴールを達成するためにツールをループで回すもの」。
つまりコーディングエージェントの中身は、①人間がゴールを伝える → ②AIがコードを書く → ③実行してみる → ④結果を見て直す → ⑤ゴールに届くまで③④を繰り返す、というループです。ここで決定的なのが「実行できる」こと。実行できなければ、AIが出したコードは「動くかもしれない文字列」に過ぎません。実行できるからこそ、「実際に動くソフトウェア」に向かって自分で寄せていけるのです。
3. 「じゃあ、それは vibe coding では？」への答え
vibe codingは2025年2月、Andrej Karpathy氏が「コードの存在すら忘れて」AIに書かせるやり方を指して名付けた言葉です。奇しくもClaude Codeの初リリースの3週間前でした。
Willison氏は、この言葉が「AIを使ってコードを書くこと全般」に広がってしまった現状を明確に否定します。vibe codingは元の意味、つまり「レビューされていない、試作品レベルのAI生成コード」を指す言葉として残しておくべきだ、と。それと区別するために、「作者が本番品質まで責任を持って引き上げたコード」を作る営みに Agentic Engineering という別の名前を与えたわけです。
一言でいえば、違いはツールではなく、人間が責任を取るかどうかです。同じClaude Codeを使っても、出てきたコードを読まずにマージすれば vibe coding、テストとレビューで「動くと確信できる」状態にして出せば Agentic Engineering。この線引きが、ガイド全体の背骨になっています。
4. 原則①「コードを書くのは安くなった。でも『良いコード』はまだ高い」
ガイドの第2章は、氏が「いちばん受け入れるのが難しい」と言う変化から始まります。
これまでコードは高価でした。数百行のきれいでテスト済みのコードを書くには、開発者が丸1日かかる。だから私たちは、企画に時間をかけ、見積もりをし、「この機能はコストに見合うか」を吟味してきました。「このリファクタリング、1時間余計にかかるならやめておこう」「このエッジケースのテスト、書く価値あるかな」という日々の小さな判断も、すべて「コードを書く時間が高い」という前提の上に成り立っていました。
コーディングエージェントは、その前提を壊しました。しかも並列で複数のエージェントを走らせれば、一人のエンジニアが同時に何か所も実装・テスト・ドキュメント化できる。個人の直感も、組織の習慣も、まるごと見直しを迫られます。
ただし氏はすぐに釘を刺します。安くなったのは「コードを出すこと」であって、「良いコードを届けること」ではない。 良いコードの条件として氏が挙げるのは、動く／動くと確認できている／正しい問題を解いている／エラー時の振る舞いが予測できる／必要最小限でシンプル／テストで守られている／ドキュメントが現状と一致している／将来の変更を邪魔しない設計、そして安全性・保守性・観測性といった各種の「〜ility」。エージェントはこの多くを手伝ってくれますが、「このプロジェクトに必要な『良さ』はどこまでか」を決め、担保するのは依然として人間の仕事です。
面白いのは、氏が提案する「新しい習慣」の作り方です。「時間の無駄だから作らない」と直感が言ったら、あえてプロンプトを投げてみる。非同期のエージェントセッションなら、最悪でも10分後に「トークンの無駄だった」と分かるだけ。直感のほうが古い前提に縛られている可能性を、毎回疑ってみる、というわけです。
5. 原則②「できることを貯め込め」と「AIは『より良いコード』のために使え」
第3章「Hoard things you know how to do（できることを貯め込め）」は、氏が長年実践してきた「小さな道具や解法を手元に蓄えておき、組み合わせて新しい問題を解く」スタイルを、エージェント時代に拡張したものです。コーディングエージェントがあれば、貯め込んだ知識を組み合わせて試す速度が桁違いに上がる。これは私たちが「業務固有のプロンプトやスキルを社内に蓄積する」とお伝えしている話と、そのまま重なります。
第4章「AI should help us produce better code」の主張は、AIは「速く書く」ためではなく「より良く書く」ために使うべきだ、というもの。人間なら面倒で後回しにしていたドキュメント更新、エッジケースのテスト、複数の設計案の比較──こうした「技術的負債を防ぐ作業」こそエージェントに回せば、コードの質は上がるはずだ、と。
6. すぐ使える2つの「4語プロンプト」
ガイドの中でもっとも実用的で、かつ拡散されているのが「テストとQA」の章です。氏は、モデルに既に染み込んでいるソフトウェア工学の規律を、たった4語で呼び出すプロンプトを2つ紹介しています。
「Use red/green TDD」（レッド／グリーンTDDで）
TDD（テスト駆動開発）は、コードより先にテストを書く開発スタイルです。「red」はまずテストが失敗するのを確認する段階、「green」は実装してテストが通る段階。氏いわく、これはコーディングエージェントと「驚くほど相性がいい」。エージェントの大きなリスクは「動かないコードを書く」「誰も使わない余計なコードを書く」の2つで、テストファーストはその両方を防いでくれるからです。しかも、まず失敗を確認する手順を飛ばすと「最初から通ってしまうテスト」を作ってしまう危険があるので、redの段階が重要。良いモデルはこの4語を、長い手順説明と同じ意味に解釈してくれます。
「First run the tests」（まずテストを走らせて）
既存プロジェクトでエージェントとの新しいセッションを始めるとき、氏が必ず最初に打つ言葉です。狙いは3つ。①テストスイートの存在を知らせ、実行方法を把握させる（以後、変更のたびにテストを回すようになる）、②テストの数から、プロジェクトの規模感をつかませる、③エージェントを「テストする気分」にして、後で自分のテストも足すよう誘導する。
氏は「テストはもう任意ではない」と言い切ります。「書き直しが大変」という昔の言い訳は、エージェントが数分で整えてくれる今では通用しない。そして、一度も実行されていないAI生成コードが本番で動くのは「純粋な運」に過ぎない、と。
7. アンチパターン：「レビューしていないコードを人に押しつけるな」
ガイドは「やってはいけないこと」の章も置いています。筆頭は、自分でレビューしていないコードでプルリクエスト（PR）を出すこと。
エージェントが書いた数百〜数千行を、動くか確かめもせずレビューに出すのは、「実際の仕事」を他人に丸投げしているのと同じ。レビュアーは自分でエージェントに頼めたはずで、あなたは何の価値を足したのか──という、かなり厳しい問いかけです。
氏が挙げる「良いエージェンティックなPR」の条件は、①動くと確信できている、②レビューしやすい小ささ（大きな1本より小さな数本。コミットの分割はエージェントに任せればよい）、③変更の背景や関連するIssue・仕様へのリンクがある、④エージェントが書いたPR説明文も自分で読んで検証している。加えて、手動テストのメモやスクリーンショット・動画など「自分が手間をかけた証拠」を添えることを勧めています。
8. ガイドの他の章：仕組み、Git、サブエージェント、コード理解
ここまでで触れられなかった章も簡単に。
- コーディングエージェントの仕組み：LLM、チャットテンプレート、トークンキャッシュ、ツール呼び出し、システムプロンプト、推論──を「ループで回す」という構造で解説。
- Gitとの付き合い方：エージェントにGitの操作を任せるときの基本概念と、履歴の書き換え。
- サブエージェント：Claude Codeの探索用サブエージェント、並列実行、専門特化したサブエージェントの使い分け。
- コードを理解する：エージェントに「線形のウォークスルー」を作らせる、対話しながら説明させる、といった「読む側」のパターン。
- 注釈付きプロンプト集：GIF最適化ツールをWebAssemblyで作った実例など、実際のプロンプトと追加指示を解説付きで公開。
9. Four Youの見解：日本の開発現場でどう使うか
このガイドが日本の中小規模の開発チームや、開発を外部に発注する側にとって意味を持つのは、次の3点です。
1. 「AIで作ったコード」の受け入れ基準が言語化できる。 発注側が「動くと確信できているか」「テストで守られているか」「PRは小さく、背景説明があるか」を要件に書けば、vibe codingの成果物をそのまま納品されるリスクが下がります。Willison氏の「良いPRの条件」は、そのまま検収項目の下敷きになります。
2. 4語プロンプトはチームの共通語にできる。 「First run the tests」「Use red/green TDD」をCLAUDE.mdやAGENTS.mdのような指示ファイルに書いておけば、メンバーごとの使い方のばらつきが減ります。海外では、氏のガイドを自社の開発ルールに反映し続けることをタスク化しているチームも出てきています。
3. 見積もりと企画の前提を見直す時期に来ている。 「コードは安くなった」は、機能の取捨選択の基準が変わったということです。「作る価値があるか」より「作ってみて、テストと運用に耐えるか」で判断する。Four Youでもこの前提で、受託開発の進め方を「小さく作って検証する」型へ寄せています。
コーディングエージェントを使ったチームの開発ルール作りや、AI生成コードの品質検証（テスト・レビュー体制の設計）については、勉強会やご相談の形でお手伝いしています。「うちの現場だとどこから手を付けるべきか」を一緒に整理したい方は、お気軽にご連絡ください。
出典
Simon Willison, "Agentic Engineering Patterns"（ガイド、2026年2月23日開始・随時更新）
https://simonwillison.net/guides/agentic-engineering-patterns/
Simon Willison, "Writing about Agentic Engineering Patterns"（プロジェクト紹介記事、2026年2月23日）
https://simonwillison.net/2026/Feb/23/agentic-engineering-patterns/
#AgenticEngineering #SimonWillison #コーディングエージェント #ClaudeCode #Codex #vibecoding #TDD #テスト駆動開発 #AI開発 #生成AI #ソフトウェア開発 #FourYou
