ウィリソンさんはなぜ、エージェントで開発が難しくなると言うのか

コーディングエージェントを入れてから、書く量は増えたのに、レビューとテストで前より疲れていませんか？

Datasetteの作者でDjangoの共同作者でもあるサイモン・ウィリソンさんが、2026年9月24日（現地時間）、自分のブログに「エージェントでソフトウェア開発はさらに難しくなる」という短いノートを書きました。本人が書いたこと、書いていないこと、私の読み方を分けて整理します。

コーディングエージェントについて、ウィリソンさんが書いたのは2文だけ

原文はこの2文で全部です。

The more time I spend working with coding agents, the more convinced I am that they make software engineering even harder. We can do amazing things with them, but unlocking their full potential requires extraordinary discipline and knowledge.

訳すとこうなります。「コーディングエージェントと過ごす時間が長くなるほど、エージェントはソフトウェアエンジニアリングをさらに難しくするという確信が強まる。驚くようなことができるのは確かだが、その力を出し切るには並外れた規律と知識が要る」。

本文にリンクは1つもなく、特定の記事や発言に返信した形跡もありません。同じ週のブログにはClaude Opus 5.5やGPT-6を扱った投稿が並んでいて、その合間に置かれた独立した所感です。

「難しくなる」だけが切り取られると、AI懐疑論に見えるかもしれません。ただ本人は2文目で「驚くようなことができる」とはっきり書いています。私は、否定されているのは道具の価値ではなく「エージェントを入れれば開発が楽になる」という期待のほうだと受け取りました。

規律と知識の中身は、このノートには書かれていない

「並外れた規律と知識」が具体的に何を指すのか、ノートには一語も書かれていません。もし「ウィリソンさんはTDDが必須だと言った」のような要約を見かけたら、それはこの2文から読み取れる範囲を超えています。

では、中身はどこに探せばいいのか。手がかりは2つあります。本人が別の場所で書き続けているガイドと、同じ9月に出た他のエンジニアの実践記録です。どちらも今回の発言の「答え」ではないので、補助線として読んでください。

あなたのチームでは、エージェントに渡す前の「規律」を言葉にできていますか？

ウィリソンさんのガイドに見える、規律の手がかり

ウィリソンさんは2026年2月から、コーディングエージェントの使い方をまとめたガイドを書き足しています。

目次には、原則、Gitとの併用、サブエージェント、Red/Green TDD、コードを順に読み解くウォークスルーといった章が並びます。私が一番「規律」に近いと感じたのはFirst run the testsの章です。セッションの最初に「まずテストを走らせて」と頼むと、エージェントはテストの在りかと実行方法を自分で探し、以降もテストを足す前提で動くようになる、という内容です。本人はこの4語のプロンプトを「モデルにすでに染み込んでいるソフトウェアエンジニアリングの規律を、まとめて呼び出すもの」と説明しています。

もう1本、Writing code is cheap nowの章では、新しいコードを出すコストはほぼタダになったが、良いコードを出すコストは今も高い、と書かれています。動くこと、テストがあること、エラー処理、保守しやすさ。そうした条件を満たしているかを確かめる仕事は、使う人の側に残ります。

2つの章を並べると、「書く手間が減ったぶん、何を良しとするかの判断が全部こちらに回ってくる」と読めます。今回の「さらに難しくなる」もその延長にある、というのが私の推測です。本人がそう書いたわけではありません。

同じ9月、別のエンジニアは品質管理を7層に積んだ

9月14日、ユーリ・フラムツォフ（Iouri Khramtsov）さんが個人ブログで「AIコーディングでコード品質が下がっているなら、品質管理のやり方が間違っている」という記事を公開しました。挙げている層は次の7つです。

1. 仕様駆動で要件を詰め、抜けや境界ケースをAIにもレビューさせる
2. カバレッジ95%超の単体テスト
3. 人間による手動テスト
4. 自動化したE2Eテスト
5. セキュリティや複雑さ、命名を見るAIの品質チェック（実装時間に5〜15分ほど上乗せ）
6. 人間とAIの両方によるPRレビュー
7. 本番環境の監視とアラート

著者はこの体制で、出力を2〜3倍に増やしながらバグの数を横ばいか減少に保てたと書いています。10倍にならない主な理由として挙げているのは、手動テストの工程があまり速くならないことでした。書く速さがいくら上がっても、確かめる工程が追いつかなければ全体の伸びはそこで止まります。

同じ構図をCIの側で受け止めた会社もあります。Linearは9月21日、エージェントで出せるコードの量に検証が追いつかなくなったとして、CIのランナーや型チェックを組み直した経緯を公開しました。

ウィリソンさんの言う規律が、この7層やCI改修と同じものだとは言えません。ただ、書く速さが上がるほど検証の設計が重くなる。その一点で、3つの記事の話はつながっています。あなたの現場で一番手薄なのは、7層のうちどこでしょうか？

コーディングエージェントに渡す前に、私が決めていること

ここからは私のやり方です。業務システムもWebサービスも、コードはほぼClaude Codeに書かせていて、コードレビューはあまりしません。そのかわり、タスクを渡す前に次のことだけは決めています。

• 何ができたら完了か。受け入れ条件を先に文章で書く
• どのテストが通れば完了とみなすか。テストを先に書かせ、落ちるのを確かめてから実装させる
• エージェントに触らせない範囲。マイグレーションや認証まわりなど、壊れたときの影響が大きい場所は明示する

どれも目新しい手法ではありません。ただ、書く手間がほぼ消えた今、この3つを決めることが作業の中心になりました。

ウィリソンさんが「さらに難しくなる」と書いた理由を、私はここに見ています。手を動かす難しさが消えたぶん、何を正しいとするかを先に決める難しさが前に出てきた。知識がなければ受け入れ条件が書けず、規律がなければテストを省いた瞬間にエージェントは暴走します。

あなたが最後にエージェントへ渡したタスクには、完了条件が書いてありましたか？

次のタスクでは、プロンプトの先頭に「まずテストを走らせて」と完了条件を1行ずつ足してみてください。5分もかかりません。原文も2文だけなので、一度そのまま読んでおくと、要約で出回る言い換えに振り回されずに済みます。