エージェンティック・エンジニアリング・パターン

 (simonwillison.net)
82 ポイント 投稿者 GN⁺ 2026-03-05 | 1件のコメント | WhatsAppで共有
  • Claude CodeやCodexのようなコーディングエージェント時代の開発手法を整理したガイドで、エージェントと協働する新しいエンジニアリングパターンを提示
  • コード記述コストが急激に下がった環境で、開発習慣やワークフローをどう変えるべきかをさまざまなパターンで説明
  • 原則、テスト、コード理解、プロンプト設計など、エージェント中心開発の中核領域を構造的に整理
  • 各パターンは実際のコード例や作業手法、プロンプト活用事例などを含む実務中心のパターンドキュメントの形
  • コーディングエージェント時代の開発者が、エージェントベースのコーディング環境を体系的に設計し、品質を維持するための実践的な参考資料

Agentic Engineering Patterns 概要

  • **コーディングエージェント（Claude Code、OpenAI Codex など）**と一緒に開発する際の効果的なエンジニアリング手法を整理したガイド
  • Writing about Agentic Engineering Patterns 紹介記事を参照
    • 従来の「Design Patterns」形式のように、複数の**パターン（chapter）**を継続的に追加していく構成のドキュメント
    • コード記述コストが大きく下がった環境での、開発者のワークフローと意思決定の変化を中心テーマとして構成
    • ブログ記事ではなく、更新可能なguide形式のコンテンツとして運用され、今後も継続的に拡張予定

1. Principles

  • Writing code is cheap now

    • AIコーディングエージェントの登場により、初期のコード記述コストはほぼ無料に近い水準まで低下
    • かつてはコードを書くことが高コストだったため設計・計画中心で開発していたが、今ではアイデアをすぐコードで試すアプローチが可能
    • コード生成コストは下がった一方で、良いコード（テスト、保守性など）には依然としてコストがかかる

  • Hoard things you know how to do

    • 開発者の重要な資産は、「何が可能かを知っている知識の蓄積」
    • 多様な問題解決事例や小さなコード実験を、保存して再利用できる形で蓄積する習慣を強調
    • こうして集めたコードや例は、コーディングエージェントに新機能を作らせる際の強力な入力資料として活用できる

  • Anti-patterns: things to avoid

    • エージェントが生成したコードであっても、レビューなしで共有したりPRを提出したりする行為は避けるべきアンチパターン
    • エージェントが書いたPR説明も、人間が直接検証し修正する必要がある
    • コードレビュアーの時間を無駄にしないため、テスト、検証プロセス、実装選択の理由なども併せて提示すべき

2. Testing and QA

  • Red/green TDD

    • テスト駆動開発（TDD）は、コーディングエージェントと一緒に使うと特に効果的な開発パターン
    • 先にテストを書くことで、エージェントはそのテストを満たす方向でコードを生成できる
    • 最小限のプロンプトでも、正確で信頼できるコード生成に役立つ

  • First run the tests

    • コーディングエージェントと作業する際、自動テストは選択肢ではなく必須要素
    • テスト作成コストが下がった環境では、エージェントがテストを素早く生成・修正できる
    • コードは実際に実行されるまでは正しく動く保証がないため、テストが重要

3. Understanding code

  • Linear walkthroughs

    • エージェントが作成したコードやプロジェクトを、最初から最後まで順番に読み進めて構造を理解するパターン
    • シンプルなプロジェクトであっても、コードの流れを追いながら新しい技術や構造を学べる
    • AIによるコード生成が学習速度を落とすという懸念に対し、コード探索そのものが学習機会になり得る

  • Interactive explanations

    • コードやシステムを理解する際、エージェントと対話しながら説明を求める方式
    • 質問を重ねながら、コードの動作原理と構造を段階的に把握
    • コード理解のプロセスを、対話型学習の形へ拡張するパターン

4. Annotated prompts

  • GIF optimization tool using WebAssembly and Gifsicle

    • WebAssemblyとGifsicleベースのGIF最適化ツールを作るためのプロンプト例を収録
    • HTML、JavaScript、CSSを含む単一ページツールの実装方法を提示
    • 実際のプロンプトとコード例を通じて、コーディングエージェントの活用方法を説明

5. Appendix

  • Prompts I use

    • 実際に使っているコーディングエージェント向けプロンプト例のまとめ
    • さまざまな作業で使える実践的なプロンプトパターンを整理
    • エージェントと協働する際に使える実用的なテンプレートを提供

関連記事

1件のコメント

 
GN⁺ 2026-03-05
Hacker Newsのコメント

  • また同じことを繰り返そうとしているように見える
    「まずテストを書け」 や「小さく組み合わせ可能なモジュールを作れ」のような単純で筋の通った概念を、複雑な名前で包み直して、それでコンサル業界を作り上げようとしている感じがする
    ただ今回は相手が「しゃべる機械」だというだけ。もう言葉で指示すればいい世界だ

    • COBOLも似たような約束をしていた。人間が読みやすい言語だからプログラマーは不要になると言われたが、結局は問題を細分化して解くために人間がプログラマーのように考える必要があった。つまり、言語が人間にやさしいからといってプログラマーが消えるわけではない
    • 今回もAIブームのサイクルが繰り返される気がする。今は批判すると「わかっていない」と返されるが、じきに問題が噴き出すはずだ。特に「AIがコードを作りすぎて、人間にもAIにも扱いきれない状況」が起きるだろう。その頃にはまたパターンとアンチパターン、そしてそれを解決すると称するコンサルタントが現れるはずだ
    • AIは英語で話し、理解するので、インターフェースの明確さが下がる。CLIのように強力ではあるが、どんなやり方が有効なのかは不透明だ。だから「何をどう指示すればよい結果が出るのか」を文書化して共有することが重要だ。ただし、それがまたOOPコーチング産業のように変質しないようにしなければならない
    • その通り。またそうなるし、今回はもっと速く進むだろう。ブロガー → 講演者 → 本 → コンサルタント → 認証機関という10年がかりのサイクルが、数年で圧縮されて現れるはずだ
    • タイトルが複雑すぎるという指摘には同意しない。ただ、「ただ言葉で指示すればいい」という誤解こそが問題だ。実際には人によって結果に大きな差が出る。結局、**「人間にとって良い開発習慣はAIにとっても良い」**という教訓が見えてきている。AIは人間っぽいが人間ではない。だからこそ、より多くの説明が必要になる

  • Simonに聞いてみたい — 「コードが安くなった世界」ではコードレビューをどうすべきか？
    チームメンバーが構造を理解しないまま「動くんだからいいでしょ」という感じで進めている。レビューはどんどん大きくなり、私はボトルネックになっている。AIレビュアーを代理に使う方法も考えたが、人間的な感覚が失われるのは嫌だ

    • 本当に興味深いテーマだ。コード生成速度が上がると、レビューがボトルネックになる。コードが安いならレビュー基準を下げることもできるかもしれないが、私はむしろより高い品質を求めたい。特にセキュリティレビューは絶対に省けない。大規模組織のセキュリティチームのような体系的アプローチが必要になるかもしれない
    • エージェントベースのレビューを使うなら、コンテキスト設定が重要だ。計画 → 実行 → テスト/修正 → レビュー/リファクタ → QAガイド生成というループを回せば、コードだけでなくドキュメントやテストガイドも一緒に進化していく
    • 「動くんだからいいでしょ」は技術の問題ではなく組織文化の問題だ。今でも読みやすいコードを重視する会社はある。それが競争力になる可能性もある
    • 私は静的・動的解析の自動化に投資している。カスタムlintルール、強力な型検査、mutation testingのような品質ツールを積極的に使っている。レビューだけでは遅く非効率なので、早期フィードバックの自動化が鍵だ
    • こうした態度は簡単には変わらない。むしろソフトウェア品質を重視するチームへ移るほうがよいかもしれない

  • 私はAIを主にボイラープレートコードやドキュメントまわりの問題解決に使っている
    エージェント型の作業も試したが、成果物はまだ信頼しにくい。それなのに「もうほとんどコードを書かない」と言う人もいる。その差が興味深い

    • 私の場合、AIより自分でコーディングしたほうが速いことが多い。計画を立てて実行させ、検証する過程のほうがかえって遅い。ただし、大規模リファクタリングはAIのほうがずっと速い
    • この数か月でエージェント性能が急上昇した。今では単純な自動補完の域を超えて、機能全体の実装まで可能になっている
    • AIコードに「これはAIが書いたな」という**違和感（eww）**を覚える開発者と、そうでない開発者の違いで説明できる気がする
    • 結局、作業の種類によってAIが向くケースと向かないケースがはっきり分かれる
    • 私も最初の成果物は気に入らないことが多いが、レビューのループを何度も回すと品質は確実に上がる。AI同士にレビューさせたり、テスト基準を明確にしたりすると、かなり改善する

  • 最近、エージェント型コーディングループを実験している
    たとえば feshプロジェクト では、「Linuxバイナリをもっと小さく圧縮する」ことを目標にしている。テストが明確な問題なので、AIループに向いていた
    学んだことは次の通りだ:

    • テストハーネスがすべてだ。検証ループがないと方向がずれる
    • AIに実験的な試行をさせることが重要だ
    • セッション間で**.mdスクラッチパッド**を残さないと学習が続かない
    • テストは本当に重要だ。AIは妙な失敗のしかたをするので、テスト自動生成を積極的に活用すべきだ
    • テストなしではループの結果を信頼できない。決定的な検証手順が不可欠だ
    • 決定ログと却下ログを分けて記録するのが有用だった。特に rejections.md の価値が高かった。**「なぜこのアプローチを捨てたのか」**を残しておかないと、AIが同じミスを繰り返してしまう
    • ブラウザ自動化でも似たようなことが言える。機能的な検証だけでなく、**行動的検証（人間らしく見えるか）**を追加してこそ有用になる。そして .md ログは次のセッションの品質を大きく高める

  • テストのセクションで、LLMが作る「自己充足的テスト」の問題も扱ってほしい
    テストが実際には何も検証していなかったり、ひどい場合は    ハードコードされた値    で通ってしまったりする。人間がAIを厳格なテスト習慣へ導かなければならない

    • 具体例が気になる。単純なロジックミスではなく、見た目はもっともらしいのに実際には無意味なテストのことを言っているようだ
    • 悪いテストは、ないより危険だ。 一度信頼が崩れると、テストスイート全体への信頼まで失われる
    • だからmutation testingが重要になる。コードを変形してもテストが通るなら、それは悪いテストだ
    • AIにコードの一部を意図的に変えさせて、テストが失敗するか確認すればいい。失敗しないなら役に立たないテストだ
    • もちろん、人間にこういうテストを書かせないようにするのも簡単ではない

  • LLMの世代が変わるたびに、これまでの教訓がすべて無効化されるように感じる
    LangChainのように旧世代モデルの限界を回避するために作られた複雑な構造は、GPT-3.5以降では不要になった。いずれは単一エージェントだけで十分にすべて処理できるようになるのかもしれない

    • だから私はモデルのバージョンに依存しないパターンを整理しようとしている。たとえば red/green TDD は、いずれモデルが自分でやるようになるかもしれないが、概念そのものは依然として有用だ
    • 結局、すべてがClaudeVMのような形に収束するのかもしれない
      関連記事を見る

  • エージェントエンジニアリングの議論で、よく抜け落ちている点がある
    多くの教訓が普遍的な真理のように語られるが、実際にはチーム規模、コードベースの成熟度、テスト水準、リスク許容度によって変わる。重要なのは、**「いつこのパターンが有効なのか」**を明確にすることだ

    • だから私は本ではなく、Webサイトの形でパターンを整理している。継続的に更新しながら、適用範囲を明示する予定だ
    • コンサルタントとしてさまざまなコードベースを見てきたが、Claude Codeの性能はコードベースの品質によって極端に変わる。強い型付けとテストがあるプロジェクトではほぼ完璧に動くが、緩いJavaScript環境ではあまりよくない
    • それでも一部のパターンは普遍的だ。たとえば独立した**ソース・オブ・トゥルース（harness）**を置くことは、どこでも有効だ。showboat や rodney のようなツールがそれを助けている

  • 最近は「エージェントチームフレームワーク」が日に何十個も出てくる
    初期のソフトウェア工学のような混沌とした実験期だ。しかし最終的には、いくつかのパターンが標準として定着するはずだ。
    私たちのチームでは、人間のチームのように進めるのが効果的だった — まず製品仕様書（spec）を書き、AIで磨き込み、それをもとに役割分担されたエージェントのフローへ渡す

  • 今日、学部の授業でCPU・GPUアーキテクチャの進化を講義した
    以前はMoore’s Lawのおかげでハードウェアがすべてを解決してくれたが、今は並列性が鍵だ。
    Simonの言う**「コードは安い」という概念も、これと似たパラダイムシフトだ。
    並列ハードウェア時代に効率的なコードがまったく変わったように、AI時代には    開発プロセス自体が変わる**だろう。これを先に理解した人が10〜100倍の利益を得るはずだ

  • 私たちのチームでは、**「途中途中に人間の検証を入れるループ」**が最も実用的だった
    完全自律型エージェントはテストには通っても、暗黙の不変条件を壊すことが多い。
    そこで、取り返しのつかない決定の直前で人間が介入するようにしている。
    ただし、何が取り返しのつかないのかをAIに理解させるのは別の課題だ。
    CLAUDE.md のような文書以外に、暗黙的なコードベースのルールを伝える体系的な方法を探している