Anthropicが2026年10月13日に公開した「Redesigning source control at Anthropic」を読みました。記事そのものも興味深かったのですが、私が少し意外に感じたのは、それに対する反応です。
私が見たスレッドでは、「実装はAIに任せているけれど、レビューはまだ人間がやっている」という声が目につきました。Claudeをかなり使い込んでいる人でも、人間がコードを確認する工程は残している。レビューまでAIに任せる運用は、私が思っていたほど当たり前にはなっていないのかもしれません。
これは、私が見た範囲での印象です。ただ、その反応を見て、あらためて書いておきたいと思ったことがあります。
AI仕様駆動開発で私が目指しているのは、人間の介入ポイントを極力減らし、人間によるコードレビューをなくすことです。
そのうえで、動くものをレビューするのは人間の仕事だと考えています。実際に操作して、目的を満たしているか、業務で使えるか、使いやすいかを判断する。このレビューには、人間が集中する意味があります。
私はAI仕様駆動開発について、Kindleで何冊か本を書いてきました。仕様の書き方、開発の進め方、エージェントに渡す情報の整え方。切り口は違っても、この考え方は共通しています。
AIが速く動けるようになったとき、その速度を受け止められる開発プロセスを、人間の側が作れているか。今回の記事と反応は、その問いを考えるきっかけになりました。
Anthropicの記事が示す、人間の規模で作られた仕組みの限界
Anthropicの記事は、AIによるコード生成が増えるなかで、ソース管理などの開発基盤がボトルネックになり、社内のモノレポを独自のバージョン管理システム「Scion」へ移行した経緯を紹介しています。Scionは同社の特殊な規模に向けたもので、一般用途でGitを置き換える提案ではありません。
レビューについても、Scionを開発・運用するチームは、すべての変更要求を今も人間がレビューすると説明しています。ただし、確認の中心はコードの各行から、変更の意図へ移っています。AIによる対抗的なレビューにも、過剰な複雑化を招く場合があり、人間の方向づけが必要だったとしています。出典は原文の「What we learned building Scion」です。
この事例を、完全に人間のレビューをなくした成功例として紹介することはできません。それでも私は、人間の規模に合わせて作られた開発の仕組みを、AIが動く前提で見直す必要性を示す記事として読みました。
その対象には、ソース管理やCIだけでなく、私たち自身が置いている「人間が確認してから次へ進む」という工程も含まれるはずです。
人間がコードを読み続ける構造を変える
AIに実装を任せれば、コードを書く時間は短くできます。しかし、変更のたびに人間がコードを読み、その承認を待つのであれば、開発全体が進む速度は、その確認の速度に制約されます。
たとえば、AIが複数のタスクを並行して進めても、最後に一人の担当者がすべての差分を読む必要があるとします。担当者が会議に入れば、完了したタスクが待ちます。確認対象が増えれば、レビュー待ちも積み上がります。
これは、人間がもっと速く読めば解決する問題なのでしょうか。私は、毎回その人が見なければ進まない構造を見直す必要があると考えています。
人間がコードを読む工程をなくした先にも、成果物のレビューは残ります。むしろ、そこでこそ人間の判断を使いたいのです。コード上は仕様どおりでも、実際に使うと操作が分かりにくい、業務の流れに合わない、欲しかった結果が得られない。そうした問題は、動くものを見て評価し、次の仕様へ返していく必要があります。
コードの品質を確かめる工程を自動化し、人間が動くものを評価する時間を確保する。私が変えたいのは、この役割分担です。
「信じる前提」で、モデルの動きを研究する
ここで私が大切だと思うのは、人間の側が「AIに任せて進める」という前提を持つことです。
AIを信じられるかどうかを議論するだけでは、任せられる範囲は広がりません。任せるつもりで使い、どのように指示を出せば、どのように動くのかを深く研究する。その積み重ねが必要です。
たとえば、次のようなことを観察します。
- 目的だけを渡したとき、何を補って実装するのか
- 変更してはいけない制約を明示したとき、その制約を守れるか
- 受け入れ基準を渡したとき、どの証拠をもって完了と判断するのか
- レビュー観点を指定したとき、何を発見し、何を見落とすのか
- テストが失敗したとき、原因を直すのか、それともテストを弱めてしまうのか
一度うまく動いたかだけでなく、条件が変わったときの振る舞いまで見る。失敗したら、人間がその場で直して終わりにせず、どの情報や検証が足りなかったのかを調べる。
その結果をもとに、「この確認はテストにする」「この観点はAIレビューへ渡す」「この条件を満たしたら、人間のコード確認を待たずに次へ進む」と定義していきます。
私にとって「信じる前提」とは、モデルに任せられる条件を、人間が本気で見つけにいく姿勢です。モデルやツールが変われば、その条件も確かめ直します。
人間が毎回言っていることを、仕様と検証へ移す
AI仕様駆動開発で仕様を書く意味も、ここにつながります。
AIが実装した後に、人間が「その動きは違う」「そこは変えないでほしかった」と伝える。このやり取りが繰り返されるなら、その判断は最初からAIに渡せるかもしれません。
たとえば、入力チェックを修正する場面を考えます。「入力チェックを直して」だけでは、AIが周辺の処理まで作り替える可能性があります。そこで、対象の入力、期待するエラー表示、正常時に維持する振る舞い、変更しないAPIを仕様に書きます。
さらに、正常系と異常系のテストを用意し、レビューには「仕様を満たすか」「既存の振る舞いを壊していないか」「不要な変更を加えていないか」という観点を渡す。人間が毎回同じ指摘をする工程を、再利用できる条件へ移せます。
そのためには、AIが何を根拠に完了としたかも確認できる必要があります。テストの実行結果、仕様との対応、残った未確認事項を記録させ、実際の結果と照合できるようにする。AIの「完了しました」という返答だけで次へ進む設計では、任せる範囲を広げにくいからです。
仕様、制約、検証方法、完了条件を整えるほど、人間が都度説明する必要は減っていきます。書籍でさまざまな角度から扱ってきたのも、この設計がAIに任せる範囲を決めると考えているからです。
コードの検証を、AIと自動テストで回す
コードレビューをAIに任せるなら、その指示と完了条件も設計する必要があります。
実装したAIに「問題ないですか」と聞くだけでは、同じ前提や見落としを引き継ぐ可能性があります。実装とは別のレビュー工程を設け、仕様との一致、境界条件、権限、既存機能への影響など、見るべき観点を渡す。必要に応じて別のモデルも使い、指摘には再現条件や根拠を求める。
複数のAIが同意したことだけで品質を保証することはできません。テストや型検査などで確かめられる部分と組み合わせ、指摘の修正後に再検証し、未解決の問題が残るなら止まる。こうした一連の流れを、自動で回る工程として作っていきます。
実装途中で人間に判断を求める条件も、同じように明示できます。仕様が矛盾していて選択が必要なとき、決められた権限を超えるとき、失敗時にデータを戻せない操作が必要なとき。何が起きたら止まり、何が揃えば進めるかを決めておけば、既に合意した範囲の変更で毎回承認を待つ必要はなくなります。
そして、残した介入ポイントも定期的に見直します。同じ理由で何度も人間を呼ぶなら、その判断を仕様や自動検証へ移せないかを考える。人間が入る場所を固定せず、減らし続けることが大切です。
動くものをレビューするのは、人間の仕事
人間によるコードレビューをなくしたら、人間は何を見るのか。私は、動くものを見るべきだと考えています。
たとえば、入力フォームなら実際に入力してみる。初めて使う人が迷わないか、エラーからやり直せるか、入力後に次の行動が分かるかを確かめる。集計機能なら、出てきた結果が業務の判断に使えるかを見る。仕様に書いた要件を満たしていても、それだけでは分からないことがあります。
そこで得た気づきを、次の仕様や受け入れ基準へ戻します。AIが修正し、自動テストとAIレビューでコードを検証する。人間は、修正後の動作と体験を再び評価する。この循環を作りたいのです。
人間がコードの各行を確認する役割から、実際の成果を評価する役割へ移れば、AIの実装速度を生かしながら、作るものの価値に時間を使えます。
以前、AIへの委任とレビューの設計についての記事でも、目的や仕様、制約を整える必要性を書きました。今回、あらためて明確にしたいのは、その設計によって減らす対象は人間によるコードレビューであり、人間が動くものをレビューする仕事は残る、ということです。
AIの速度を、成果の改善につなげる
AIに書かせる部分だけを増やしても、人間がコードを確認する回数が変わらなければ、確認待ちは残ります。実装の自動化に続いて、コードレビュー、修正、再検証まで、任せられる範囲を広げていく必要があります。
そこで人間が研究すべきなのは、モデルがどう動き、その動きをどの条件で再現できるのかです。観察して、仕様に落とし込み、検証し、自動化する。うまくいかなかった条件を残し、次の実行へ反映する。
その積み重ねで、コードを作り、確かめる途中の人間の介入ポイントを極力減らしていく。私は、それがAI仕様駆動開発の本質だと考えています。
AIの速度が上がるほど、人間が毎回コードを読む工程の影響は大きくなります。AIをもっと速く動かすことと同じくらい、人間がその速度を止めなくても済む条件を作ることが必要です。
コードの検証はAIと仕組みに任せ、人間は動くものをレビューする。その役割分担によって、AIの速度を、使えるものを改善する速度につなげていきたいと思います。
AI開発の一番のボトルネックを、結局は人間にしてしまわないために。