コーディングエージェントには最適条件があり、多くの人はそれを飛ばしている

See all postsPublished on 2026-02-25Coding Agent 有个甜蜜点，多数人直接跳过了

有两个 Vibe Coding 项目让我印象很深。

一个是 Simon Willison（Django 框架の共同創設者）が、家族とクリスマスツリーを飾りながら映画を見ている間に、Codex CLI と GPT-5.2 を使い、Emil Stenström の JustHTML（純粋な Python で書かれた HTML パーサーライブラリ）を、依存関係ゼロの純粋な JavaScript 版へ移行しました。9200 以上の html5lib-tests テストケースをパスし、約 9000 行のコードと 43 回のコミットを生み出しています。この過程で彼自身が発したプロンプトはわずか 8 個程度です。

《I ported JustHTML from Python to JavaScript with Codex CLI and GPT-5.2 in 4.5 hours》https://simonwillison.net/2025/Dec/15/porting-justhtml/

もう一つは Cloudflare で、エンジニアマネージャーが AI を率いて、わずか一週間足らずで Vite 上で Next.js の API を再実装し、vinext というプロジェクトを立ち上げました。1700 以上のユニットテストと 380 個の E2E テスト（End-to-End Test）をパスし、Next.js の API の 94% をカバーしています。すでに顧客が本番環境で稼働させています。総コストは約 1100 ドルの Token です。

《How we rebuilt Next.js with AI in one week》https://blog.cloudflare.com/vinext/

この二つのプロジェクトは規模も複雑さも決して低くありませんが、Coding Agent の完成度が驚くほど高いのです。なぜでしょうか？

それは両方とも Coding Agent のコンフォートゾーン、つまり「甜蜜点」を正確に捉えているからです。

明確なリファレンスがある：Agent に「創造」ではなく「翻訳」させる

大規模言語モデル（LLM）が最も得意とすることのひとつは「翻訳」です。自然言語であれプログラミング言語であれ、明確なリファレンスを与えられれば、素早くかつ高品質に処理できます。

Simon のプロジェクトは典型的な翻訳タスクです。すでに Python 版の HTML パーサーライブラリが存在し、API デザインもコードロジックも完成しています。Agent に求められるのは、これらを JavaScript へ「翻訳」することだけです。アーキテクチャをゼロから設計する必要も、製品に関する意思決定をする必要もなく、与えられたものを忠実に書き写せばよいのです。

Cloudflare の vinext プロジェクトはより複雑に見えますが、根底にあるロジックは同じです。Next.js の API は公開されており、ドキュメントも極めて充実しています。Stack Overflow には膨大な Q&A が蓄積されており、これらはすでに大規模言語モデルのトレーニングデータに含まれています。Cloudflare チームは AI に新しいフレームワークを発明させるのではなく、Next.js の仕様書に基づいて Vite 上で再実装させるよう指示したのです。

最初の条件：Agent に明確なリファレンスを与えることです。既存のオープンソースプロジェクトでも、API ドキュメントでも、あなたが以前書いた旧バージョンのコードでも、すべてがリファレンスとして機能します。Agent に「創造」ではなく「翻訳」を任せることで、成功率は格段に高まります。

あなた自身の仕事においても、手を動かす前に一度自問してみてください。「参照できる既存のものはないか？」と。オープンソースの実装、競合他社のコード、あるいは単なる擬似コード（Pseudo-code）であっても、それがあれば Agent のパフォーマンスは一歩跳ね上がります。

自動化された検証：エージェントが自身で正誤を確認できる仕組み

コーディング・エージェントも人間プログラマーと同様、コードを書き終えた後に検証が必要です。違いは、検証に人手を要すると効率が劇的に低下する一方で、エージェント自身がテストを実行し、結果を確認し、バグを修正できれば、高速なループに入り、疲れ知らずに反復改善を行えるようになる点です。

Simon のプロジェクトが成功した背景には、HTML5 標準に「html5lib-tests」と呼ばれるテストスイートが存在することが大きく寄与しています。このテストセットには 9200 以上のケースが含まれており、入力は HTML で、出力は正しい解析構造となります。エージェントに対してどこを間違えたかを教える必要はなく、テストを実行するだけで問題がわかります。Simon が GitHub Actions の設定を終えると、エージェントはこのループに入り、140 万トークン以上を使用し、43 回のコミットを経て、すべてのテストが緑色（合格）になるまで続けました。

Simon はこのプロセスを「デザイン・エージェント・ループ（Designing the Agentic Loop）」と呼び、これが AI のプログラミング能力を引き出すための鍵となるスキルであると指摘しています。

Cloudflare のケースも同様です。Next.js リポジトリには数千ものエンドツーエンドテストが存在し、チームはこれらのテストをそのまま受け入れ基準として採用しました。ワークフローは以下の通りです：タスクを定義し、AI にコードとテストの作成を依頼し、テストを実行します。合格すればマージし、不合格であればエラーメッセージを AI に返して修正させます。ほぼ完全な自動フィードバック・ループが構築されています。

「私のプロジェクトにはそんな完璧なテストスイートはない」とおっしゃるかもしれません。確かに、大多数のプロジェクトにはありません。しかし、この方向性に向かって取り組むことは可能です：

まずテストを記述し、その後に Agent に実装を行わせる（テスト駆動開発と Agent は相性が抜群です）

ブラウザの開発ツールを接続して実行結果を確認できるようにする

少なくとも「npm test」の自動実行を Agent に行わせる

Agent が利用する自動検証ツールの数が増えれば増えるほど、自己修復能力は高まります。

アーキテクチャ・ブループリントの活用：Agent に「作文」ではなく「穴埋め」をさせる

エージェントはコンテキストウィンドウ（文脈の記憶容量）の制限を受けるため、一度に処理できる情報の量には上限があります。複雑なプロジェクトのコードベース全体を丸ごと投げつけても、消化しきれません。また、大規模な機能を最初から最後まで一気に行うよう指示しても、後半になるほど前半の内容を忘れてしまいます。

そのため、アーキテクチャ設計が極めて重要になります。大きなタスクをアーキテクチャに基づいて小さなタスクに分解し、各タスクがエージェントのコンテキストウィンドウ内で完結するように調整することが、熟練者と初心者の間で最も大きな違いの一つです。

Simon のアプローチは賢明です。彼の最初のプロンプトは AI にコードを書かせるのではなく、Python プロジェクトを読み込んだ後に JavaScript 版の設計ドキュメント（spec.md）を作成させるというものでした。

Cloudflare チームのアプローチはより体系的です。エンジニアリングマネージャーがまず Claude と数時間にわたりアーキテクチャ案を繰り返し議論し、全体像であるブループリントを確定させた上で、モジュールごとにタスクを分割しました。各タスクの境界が明確なため、AI は一つのモジュールを書き終えるたびに独立してテストでき、プロジェクト全体の完成を待たずに検証が可能です。

アーキテクチャの専門家でなくてもこの作業は可能です。たとえ AI と 10〜30 分ほど話し合い、実行計画を立ててもらい、その計画に従って段階的に進めるだけでも、結果は格段に良くなります。「設計してから実装する」という原則は人間プログラマーにも適用されますが、Agent にとってはより一層重要なルールです。

誰かが方向性をコントロールする：エージェントが実行し、人間が意思決定する

Cloudflare のブログにはこんな一節があります。

AI に良い方向性、良い文脈、そして適切なガードレールを与えれば、高い生産性が得られます。しかし、ハンドルは人間の手に握らせておく必要があります。

AI には頭を悩ませる特徴が一つあります。それは、見た目は完全に正しくても実際には動作しないコードを書きがちだということです。構文に問題はなく、論理も一見通じているのに、実行すると正しくないのです。このような「高信頼度の誤り」を見抜くためには、現時点では人間による判断が必要です。

Simon はエージェントに対して「頻繁にコミットしてプッシュする（commit and push often）」よう指示しました。これにより、彼はスマートフォンで GitHub のコミット履歴を閲覧するだけで進捗を追跡できます。Cloudflare チームもコードレビューの一部を AI エージェントに任せていますが、アーキテクチャの意思決定、優先順位の判断、そして AI が逸脱したことを検知することについては、依然として人間がコントロールしています。

この二つのプロジェクトを担当しているのは初心者ではありません。Simon は Django の共同創設者であり、Cloudflare 側の担当者はエンジニアリングマネージャーです。彼らは大きな問題を AI が処理できる小さなタスクに分解する方法を知っており、いつ介入すべきか、いつ手を離すべきかも理解しています。

あなたが彼らと同じような達人である必要はありませんし、エージェントが書くコードのすべての行を監視する必要もありません。しかし、重要な局面で方向性が正しいかどうかを確認する必要があります。エージェントに大きすぎるタスクを与えて自分自身は去ってしまうと、通常良い結果は得られません。小刻みに進め、段階的に検証するというのが、現在最も信頼できる協働方式です。

これら四つの条件は、決して高邁な理論ではありません。振り返ればすべて常識に過ぎません：参照があること、自己検証が可能であること、計画があること、そして人間による管理があること。しかし、まさにそれらがあまりにも常識的であるがゆえに、多くの人がエージェントを使用する際にこれらの条件を無視してしまいます。

Cloudflare チーム自身は言っています。数ヶ月前まではこれを行なうことはできなかったと。それはモデルの能力がどれほど向上したからというだけでなく、正しい方法を見つけたからです。

Coding Agent の適正領域（sweet spot）がどこにあるかを知った今、意識的に自分のプロジェクトをその方向へ近づけることができます：

まず、着手する前に参照となるプロジェクトやコードがあるか確認しましょう。焦ってエージェントにゼロから書かせようとしてはいけません。類似のオープンソース実装がないか、既存の API 仕様はないか、参考になるコードライブラリはないか探してみましょう。エージェントに参照物を与えることは、単なる要件記述を与えるよりもはるかに効果的です。

エージェントに自動検証機能を備えさせましょう。手動テストはエージェントの効率における最大のボトルネックです。検証プロセスを自動化尽可能にしましょう：ユニットテスト、インテグレーションテスト、Lint（コード品質チェック）、型チェック、さらにはブラウザの自動化テストまで。エージェントが自ら実行し、結果を確認し、自ら修正できるようにします。Cloudflare は agent-browser を用いてブラウザ側のレンダリングとインタラクションを検証していますが、このアプローチは非常に参考になります。

実装の前に設計をしましょう。エージェントに作業させる前に、アーキテクチャを明確にし、タスクを適切に分割してください。各タスクの範囲は、エージェントのコンテキストウィンドウ（記憶容量）に収まるほど小さく、かつ有意義なモジュールを生み出すのに十分な大きさである必要があります。このタスク分割能力こそが、達人と初心者の分水嶺です。

フィードバックループを構築しましょう。Simon の手法は典型的です：CI（継続的インテグレーション）を設定し、コミットするたびに自動的にテストを実行します。エージェントがコードを書き、コミットし、CI でエラーが発生し、エージェントがログを読み、修正し、再度コミットします。人間は重要な局面でのみ介入すれば十分です。このループが回れば、エージェントの生産性は、あなたがそこに座って一行ずつコードをレビューするよりも遥かに上回るでしょう。

いつエージェントが機能しないかを知りましょう。すべてのプロジェクトが適正領域にあるわけではありません。明確な規範がない探索的なプロジェクト、ドメイン知識を大量に必要とするビジネスロジック、複雑な人間関係のコミュニケーションを要する要件整理などは、エージェントには苦手です。境界線を見極め、強みを活用することも同様に重要です。