@iwashi86 さんが X に投稿した、AWS の Clare Liguori 氏の講演メモ「このAWSの方の発表はかなり面白い」(2026-09-02 投稿、2026-09-03 取得)を読みました。講演本体は AI Engineer が公開した「From AI-Assisted to AI-Native: Building a Frontier Development Team」(2026-08-28 公開、2026-09-03 に説明文のみ取得)です。
コーディングエージェントに仕事を任せているのに、「できました」と言われるたびに自分で開いて確かめていて、席を離れられない人向けです。先に要点だけ:
- エージェントに長く任せられるかどうかは、モデルの賢さより、コードベースが機械的に誤りを返せるかで決まる。テスト、ビルドの終了コード、lint、ローカルで動くモックがその「返す仕組み」になる
- Amazon の 50 チームのパイロットでは、9 割が同じ道具を使いながら、本番へのデプロイ速度の改善は半数が 3 倍未満、残り半数が中央値 4.5 倍だった。差を分けたのは働き方を変えたかどうかで、上位半数の習慣には、新機能の開発をいったん止めてコードベースやエラーメッセージを整える期間を先に取ることが含まれる
- 最初の一手は小さくてよい。次にエージェントへ渡すタスク 1 つ分だけ、合否を返すコマンドを先に用意する
高成果チームが先に整えたのは、コードベースの型、エラーメッセージ、手元で回る検査
数値は講演の説明文と講演メモに拠ります。Amazon 内部の自社申告値で、私は追試していません。
講演の説明文によれば、Amazon は既存コードベースで働く普通の 50 チームを 1 年近く観察し、うち 9 割が同じコーディングアシスタントを使っていました。本番へのデプロイ速度の改善は、半数が 3 倍未満、残り半数が中央値 4.5 倍で 10 倍を超えるチームもありました。説明文は「道具は変数ではなかった」と書いています。講演メモは、この差を生んだのは AI に合わせて働き方を意図的に変えたかどうかだとし、上位の半数に共通する習慣を 5 つ挙げています。
5 つのうち 2 つが環境の準備です。
- 急ぐためにあえて減速する。新機能の開発をいったん止め、エージェントが動きやすいように、既存のコードベースやエラーメッセージを整理する準備期間を設けた。動的型付け言語から、コンパイラの検査が強い TypeScript や Rust へ移行したチームもあった
- テストのシフトレフト(変更を出した直後に検査が走るようにすること)。リンターやローカルで動くモックサーバーを使い、エージェントが素早く自己修正できる環境を作った
残りの 3 つは、暗黙知を指示ファイルに書くこと、細かく対話せず自己検証できるまとまったタスクを渡して放置すること、事前に仕様書を書いて意図をすり合わせることです。「まとまったタスクを渡して放置する」は、上の 2 つの準備があって初めて成り立ちます。放置している間に誤りを見つけるのは、人ではなく環境の側だからです。この記事で環境と呼ぶのは、テスト、ビルド、lint、ローカルで動くモックのように、エージェントが自分で走らせると機械が合否を返してくれる仕組みのことです。
準備には数ヶ月かかるので、経営側は生産性が一時的に下がる期間を許容する必要がある、ともメモにあります。
ベンダー 2 社の公式ガイドも、同じことを成果の条件に書いている
講演の話は Amazon の事例ですが、ベンダーも自分で書いています。
Claude Code の Best practices(2026-09-03 取得)には、「Claude に自分の仕事を検証する手段を与える」という節があります。テスト、ビルド、比較用のスクリーンショットなど、Claude が自分で走らせられる検査を渡せ、それが「見張るセッション」と「離れられるセッション」の差だ、という趣旨です。検査が無ければ「できたように見える」が唯一の信号になり、あなたが検証ループになって、すべての誤りはあなたが気づくのを待つ、と続きます。検査とは会話の中で読める合否を返すものなら何でもよく、テストスイート、ビルドの終了コード、linter、出力を期待値と比べるスクリプト、設計と比べるブラウザのスクリーンショットが挙がっています。
GitHub Copilot の cloud agent の Get the best results(2026-09-03 取得)は、Copilot が自分の開発環境で変更を build、test、validate できれば、速くマージできる良い pull request を出す可能性が高まる、と書いています。依存関係は Copilot 自身に試行錯誤で入れさせることもできるが、LLM の非決定性のため遅く不安定になりうるので、先に入れておく設定ファイルを用意せよ、というのが同ページの案内です。
どちらも「よく確認してから完了と言え」とは書いていません。確認する手段を先に用意しろ、と書いています。指示に「必ずテストを通してから」と足しても、テストがあって初めて「通してから」が指示になります。
手元では、最初の一手を 1 タスク分に絞る
ここからは私の見立てで、未検証です。
速さの本体はモデルではなく、機械が誤りを返せるコードベースの側にある、と読んでいます。型、テスト、lint、読めるエラーメッセージは、これまで人間向けの品質投資として扱われてきましたが、エージェントにとっては入力そのものです。人が読めないエラーメッセージは、エージェントも読めません。
図の下段の「環境が確かめる」の環境は、講演メモの節で書いたとおりテスト、ビルド、lint、モックのことで、エージェントが自分で走らせられる検査の総称です。上段の「人が確かめる」と何が違うかを並べます。
| 人が確かめる(以前) | 環境が確かめる(以後) | |
|---|---|---|
| いつ返るか | 人が戻ってきて開いたとき | 走らせた直後、数秒から数分 |
| 何が返るか | 感想、指摘、次の指示 | 合否と、失敗した箇所のメッセージ |
| 誰が読むか | 人が読み、エージェントに伝え直す | エージェント自身。読んで直してまた走らせる |
| 何回でも同じか | 疲れや見落としで変わる | 同じ入力には同じ結果 |
| 見つけられるもの | 設計の妥当性、読みやすさ、意図とのずれ | 機械で判定できる誤り。型の不一致、テストの失敗、lint 違反 |
環境が返せるのは最後の行の右側だけです。左側は人にしか判定できません。ただ、放置の間にエージェントが出す誤りの多くは右側だと私は見ていて、そこを人が拾っている限りエージェントは人の帰りを待ちます。環境を整えるとは、右側を機械に移して、人の目を左側だけに使えるようにすることです。
「数ヶ月の準備期間」が組織で通りにくいのは、投資の効き目が数ヶ月遅れて出るからだと思います。そこで、最初の一手を小さくします。次にエージェントへ渡すタスク 1 つについて、渡す前に「これが通れば合格」と言えるコマンドを 1 本用意する。テストが無ければ、期待する出力を書いたスクリプト 1 本でも、ビルドが通ることでも構いません。そのコマンドを指示の中に書いて、通るまで直させます。
このブログでも同じ形でやっています。記事をエージェントに書かせたあと、生成された HTML を検査するスクリプトを 1 本置いていて、太字の記号が生のまま漏れる不具合を exit 1 で止めています。以前は公開直前に自分の目で見つけていたものです。この記事を書いた直後に回した結果がこれです。
$ perl scripts/check-post-output.pl blog-site/content/posts/2026-09-03-verifiable-environment-first.md
OK: blog-site/content/posts/2026-09-03-verifiable-environment-first.md（本文 12611 文字, ソースの **=0, 本文 <strong>=0, 生の **=0, em ダッシュ=0）
エージェントには「これが OK になるまで直せ」とだけ言えば済みます。
合否を返すコマンドの有無で、機械が見つける誤りと人が見つける誤りの数がどう変わるかを、同じタスクで前後比較する実験はまだやっていません。やったら別の記事にします。
次にやること
- 次にエージェントへ渡すタスクを 1 つ選び、渡す前に「これが通れば合格」と言えるコマンドを 1 本用意する。無ければ、期待出力を比べるスクリプトかビルドで代用する
- そのコマンドを指示に書き、通るまで直させる。自分で開いて確かめるのは、コマンドが通ったあとだけにする
- エージェントに「できました」と言われて自分で確かめている回数を数える。その回数が、環境に足りていない合否信号の数