この記事は、2026/04/22 に行われた TechLead Conference 2026 にあった、和田氏のセッション内容をまとめたものです。
注意: この記事は筆者が会場で取ったメモに基づいて再構成したものであり、発言の正確な書き起こしではありません。本文中の「佐藤氏：」「和田氏：」形式の発言部分も逐語ではなく、文意を損なわない範囲でのメモに基づく要約・再構成です。実際の発言とは表現や細部が異なる場合があります。内容に誤りがある場合は筆者の責任です。
まとめ
セッションでは佐藤氏が大事にしてきた 4 つのエンジニアリングの価値観（V字モデル＝開発工程を V 字型に対応付けて品質を作り込む枠組み、プロセス品質、インサイドアウト品質、手戻りコスト）を前段として共有したのち、AI エージェント時代にこれらの原則がどう変わるかを和田氏と対談形式で議論しました。TDD（テスト駆動開発）の変化と不変、伴走モードと委託モード、コードレビューの解体と再構築、内部品質における理解容易性と変更容易性のバランス変化、要件定義とコンテクストエンジニアリングといった幅広いテーマが扱われました。
一貫していたのは「AI はアンプリファイア（増幅器）であり、エンジニアリングの積み上げの差をより顕著にする」という DORA 2025 レポート（Google が毎年公開している DevOps 領域の大規模調査レポート）に基づく視点と、「変わらないものをしっかり積み上げつつ、前提が変わった部分はアンラーニングしていく」という姿勢です。特に、コード変更の主体が人間から AI に移ったことで、変更容易性よりも理解容易性の重要性が相対的に高まったという品質特性のバランス変化は、ソフトウェアエンジニアリングの歴史における大きな転換点として語られました。
登壇者紹介
冒頭のキーノートセッションは「AI 時代のエンジニアリングの原則」と題し、タワーズ・クエスト株式会社 取締役社長の和田卓人氏（通称 t-wada さん）と、株式会社ビープラウド 代表取締役社長の佐藤治夫氏が登壇しました。
佐藤氏は株式会社ビープラウドを 2006 年に設立し、IT 勉強会支援プラットフォーム「connpass」を運営しています。ドメインモデリングやソフトウェアエンジニアリングに関心を持ち、2007 年 9 月から「BPStudy」という勉強会を主宰し、登壇時点で 223 回を数えるまでに至っています（第 224 回は 2026 年 4 月 30 日に開催予定）。
和田卓人氏はインターネット上で「t-wada」の名で広く知られ、技術顧問としてのコンサルティングやオープンソースソフトウェアの開発を行っています。日本においてはテスト駆動開発（TDD）を国内に紹介・普及させてきた活動で最も知られており、書籍の出版・翻訳なども手がけています。
佐藤氏の前段：エンジニアリングで大事にしてきた 4 つの価値観
本題の対談に入る前に、佐藤氏がこれまでの開発経験を通じて大切にしてきたエンジニアリングの価値観について、前段として 4 つの視点が共有されました。
大前提：ソフトウェアは「運用・継続開発」の期間のほうが圧倒的に長い
佐藤氏がまず強調したのは、すべての価値観の土台となる前提認識です。
佐藤氏： システムやソフトウェアというものは、最初に開発する期間よりも、それを運用したり継続的に開発したりしていく期間のほうが圧倒的に長い。この点を意識していないと、開発してテストしてリリースしたはいいものの、その後の開発生産性が悪化したり、不具合が大量に発生したりして、大変なことになってしまう。だから自分はずっとそうならないように気をつけてきた。長期的な保守性を高めること、つまり変更容易性——変更のしやすさ——を重視して、それが高まっていくにはどうすればいいかをずっと考えてきた。
この前提の上に、佐藤氏が大事にしてきた 4 つの価値観が置かれています。
価値観 1：V字モデルを「開発の地図」として頭に持つ
1 つ目の価値観は、V字モデルを開発の地図として常に頭の中に持っておくことです。
佐藤氏： V字モデルというとウォーターフォール開発のことですかと聞かれることも多いが、自分はそうではないと思っている。アジャイル開発であっても、企画、要件定義、設計、プログラミング、テストというプロセスを高速で回していくことに変わりはない。頭の中にV字モデルの地図を持っていると、今どの仕事やタスクをやっているのか、次に何をやらなければいけないのか、今の仕事をやるために必要な情報は何か、次のプロセスのために何を準備すべきか——こうしたことをしっかり考えられるようになる。こうした思考の枠組みを開発ライフサイクルと呼ぶ。
価値観 2：プロダクト品質はプロセス品質から生まれる
2 つ目の価値観は、品質はプロセスから生まれるという視点です。
佐藤氏： ビジネス側から「早くリリースしたい」という要望が来ると、とりあえず突貫で作って、最後に QA チームに渡してテストして品質保証してリリースしよう、設計の見直しや内部コードの整理、リファクタリングは後でやればいい——という目先の開発量重視になってしまうことが多い。しかし、それでは長期的に見たときに品質が下がり、開発生産性も下がっていく。だから自分はプロセスごとに品質を高めていくことに取り組んできた。
具体的には、設計レビューやコードレビューを開発の早い段階から組み込み、テストも単体テスト、結合テスト、システムテストと段階的に粒度を上げていく。日々のプロセスの品質を高めていくことが、最終的にプロダクト品質につながるという考え方です。
価値観 3：インサイドアウトで品質を高める
3 つ目の価値観は、内側から外側へ向かって品質を段階的に高めていくという考え方です。
佐藤氏： まずプロセス品質を高める。これは自分たちのチーム内のプロセスの話で、要件をしっかり変更管理すること、設計基準をしっかり定めること、コードレビューを行うこと、早期テスト——シフトレフトと呼ばれることもあるが——つまり要件や設計の段階で品質を作り込んでいくこと。次に内部品質を高める。これはコードがきれいであるということで、保守性や再利用性、テストのしやすさを品質として確保していく。その上で外部品質——外から見える機能や性能、セキュリティといった品質を高めていく。その結果として利用時の品質、つまり本来の開発目的が達成され、価値が生まれる。これを一連のプロセスとして取り組んでいくと、最終的に長期的な品質が高まり、開発生産性も向上していく。
価値観 4：手戻りコストの影響を常に意識する
4 つ目の価値観は、手戻りコストの怖さを常に頭に置いておくということです。
佐藤氏： 自分は『ソフトウェア開発 201 の鉄則』という 1990 年代に出版された本をずっと大事にしてきた。その中の「今すぐ要求仕様書の誤りを直せ」という鉄則がある。要求に誤りがあると、後のプロセスやフェーズになればなるほど対処コストがかかる。極端なところでいえば、納入時点やリリース後に残っていると 200 倍のコストがかかる。
リリース後にバグ報告や「使いにくい」というフィードバックが来て、その原因が「そもそも要件が間違っていた」となると、要件を直すと設計も修正しなければならず、DB 設計を直すと多くのプログラムに影響が波及し、リグレッションテストを実施して慎重にリリースする必要が出てくる。だからこそ要件はなるべく早く修正すべきであり、「あとで直せばいい」という考え方が結局は納期やコストを破壊してしまう——これが佐藤氏が長年大事にしてきた原則です。
AI エージェント時代の到来
佐藤氏が大事にしてきた 4 つの価値観を共有した後、話題は大きく転換します。ここ 1〜2 年で急速に台頭してきた AI エージェントの時代が、これらの価値観にどのような影響を与えるのかという問いへと移っていきました。
「開発ライフサイクルはなくなる」という主張
佐藤氏： ところが、去年から今年にかけて、皆さんもご存知のように AI エージェントの時代が到来してきた。
佐藤氏は今年 2 月頃に公開されたある記事を紹介しました。従来の開発方法では要求、システム設計、実装テスト、コードレビュー、デプロイ、モニタリングと順にプロセスが進んでいく。一方、AI エージェント時代ではインテント（意図）をエージェントに渡し、エージェントがコードを書いてテストしてデプロイする。動作しなければ再びエージェントに指示を与えて修正させる。つまり開発ライフサイクルはなくなり、エンジニアリングもなくなる——という主張です。
さらに Anthropic の CEO ダリオ・アモデイ氏が「ある程度コーディングがなくなる」「ソフトウェアエンジニアリングもなくなるだろう」と述べたことにも言及しました。
エンジニアリングは過去の遺物になるのか
佐藤氏： これらを見て、自分はこれまでエンジニアリングに必死に取り組んできたし、すごく大事にしてやってきた。しかし、エンジニアリングは本当に終焉するのか。それとも AI エージェントとともに進化していくのか。エンジニアリングが過去の遺物になってしまうのか。ひょっとしたらエンジニアリングまで不要になってしまうのか。
佐藤氏はバイブコーディング（Vibe Coding）にも触れました。企画者やビジネスサイドの人間が「こういうものを作りたい」と指示するだけで成果物が出来上がるため、エンジニアがそれほど必要でなくなるのではないか——そうした懸念まで頭に浮かんだと率直に語りました。
和田氏への対談オファーの経緯
佐藤氏： そこで今回の TechLead Conference を一緒に開催するにあたって、和田さんにオファーをさせていただいた。和田さんは 2、3 年前から AI やエージェントと開発の関係について積極的に発信されていて、自分もその内容に共感していた。今の時代、和田さんならどのように考えるのだろうと思い、登壇をお願いした。
セッション後半には Slido を使った質問セッションも設けられ、エンジニアリングに限らず幅広い質問を受け付けるとのことでした。
テーマ設定：AI がコードを書く時代に何が変わり、何が変わらないのか
佐藤氏が設定した対談のテーマは、「AI がコードを書く時代に何が変わり、何が変わらないのか」です。スライドには V字モデルの図が表示され、「今この辺の話をしている」という目印として使われていました。
佐藤氏： TDD というのはテストをするだけ、単体テストをするだけではなく、プログラミングと一体となったプロセスである。プログラミングと一体であるということは、コードレビューも関わってくるし、詳細設計も入ってくる。つまり、詳細設計、プログラミング、単体テスト、コードレビューが一体となったプロセスが TDD だ。この TDD が今の AI エージェント時代によってどのように変わっていくのか、あるいは変わらないところはどこなのか——それを教えていただきたい。
TDD は AI エージェント時代にどう変わったか
佐藤氏： では、さっそく議論に入りたいと思います。プログラミングやテストコードというスコープについて、去年からコーディングエージェントが登場し、1 年ほどコーディングエージェントと一緒にプログラミングをする時代になっています。何が変わって、何が変わらないのか——このあたりからお聞かせください。
和田氏： 変わったところでいうと、コードを書く主体が変わりました。2026 年の現在、いろいろな現場を見ていくと、ほぼ人間はコードを書かなくなってきています。テストコードも含めて、実際にコードを書いているのは Claude Code や Codex といったコーディングエージェントです。だから、テスト駆動開発をやっている主体もコーディングエージェントになりました。
僕の中では実装はテスト駆動開発でやるというのが 20 年間一貫しています。何が変わったかというと、テスト駆動開発を実際に実行するのがコーディングエージェントになったという点です。
世の中全体でいうと、僕は 20 年くらい日本でテスト駆動開発の紹介やデモをやってきました。「TDD ブートキャンプ」を立ち上げて日本全国でワークショップを開催したり、本を翻訳したりしてきたのですが、テスト駆動開発が本当に普及したのは去年——2025 年なんです。コーディングエージェントがテスト駆動開発を実行できるようになったからです。僕の 20 年より、コーディングエージェントの 1 年のほうが、よほど世の中にテスト駆動開発を普及させた。悔しいと認めるしかないのですが、テスト駆動開発で実装するプロジェクトの数は明確に増えた。ただし主体は人間ではなく AI に変わった——というのが現在の状況です。
佐藤氏： TDD をみんながやるようになったということは、今まではやろうと思っていたけれど学習コストが足りないとか、そういったハードルがあったのでしょうか。
和田氏： そうですね。テスト駆動開発には 2 つのコストがあります。1 つ目は学習コスト——テスティングフレームワークの使い方やテストから先に書く考え方に慣れる必要がある。2 つ目は実装コスト——テストコードを書くこと自体の手間です。この 2 つの壁があったために、テスト駆動開発を実践する人はなかなか増えなかった。
一方で、古典的な TDD は置いておいて、後からでもいいのでテストコードを書く人は順調に増え続けていました。自動テストで救われた人が増えているからです。僕の立場としては「TDD は個人のコードの書き順の話だから好きな人がやればいい。でも自動テストは絶対やってくれ。プルリクエストの中には自動テストがある状態で完了しようね」と言ってきた。これが去年までの状況でした。
ところが去年、コーディングエージェントが進化し始めました。コーディングエージェントは、ただバイブコーディングのようにコードを書かせると迷走する傾向があります。どうやって手戻りなく着実に望んだ方向に進んでもらうか——その観点から、去年の春から初夏にかけて、テスト駆動開発がコーディングエージェントと非常によくフィットすることが発見されました。Anthropic のドキュメントでも「テスト駆動開発はコーディングエージェントと非常によくマッチする」と明記されるようになり、一気に普及しました。
コードが増えるほど、何かをいじると既存のコードが壊れるリスクが高まる。それを抑えてきたのが自動テスト、リンター、コンパイラでした。動的検査としてのテストコードの意味が大きく変わったのがこの 1 年です。
伴走モードと委託モード——エンジニアの関わり方
佐藤氏： AI エージェントやコーディングエージェントが TDD をやってくれるとして、エンジニアはどういうマインドで、どのように関わっていけばいいのでしょうか。指示を出して終わりというわけではないですよね。
和田氏： 2026 年の現在、コードを書くというレベルでエンジニアがどう関わるかというと、大きくは 2 つのモードがあるというのを去年見つけました。今年も基本的にはこの枠組みは変わっていないと思っています。
1 つ目は伴走モードです。コーディングエージェントがコードを書いているところを同期的に見守る、リアルタイムで見守るというモードです。
2 つ目は委託モードです。コーディングエージェントに一括で指示を出して、コードを書かせる。その中ではテスト駆動開発でやってもらうのだけれど、テスト駆動開発をやっているところをリアルタイムで目撃することはない——というモードです。
補足: 和田氏のスライド（Agile Japan 2025 等）における原表記は「AI と伴走のパターン／AI に委託のパターン」です。本記事では会場で口頭で用いられた呼称に合わせて「伴走モード／委託モード」と表記しています。
両方のモードにおいて、テスト駆動開発にエンジニアはどう関わるのか。まず伴走モードについてお話しします。
テストファーストプログラミングとレッドグリーン TDD の違い
「テスト駆動開発でやってください」と指示しても、コーディングエージェントが実行するのは厳密なテスト駆動開発ではなく、テストファーストプログラミングであることが多いのです。
何が違うのか。先にテストを書く点は同じですが、書く量が違います。テスト駆動開発は少しテストを書いて実装し、また書いて実装し——と小出しにしていく。一方、テストファーストプログラミングはプランに沿ったテストコードをまとめて一気に書き、失敗するテストがたくさんできて、それを一気に実装して全部グリーンにする。1 回 1 回の歩幅が大きいのです。
歩幅の大小と使い分け
放っておくとコーディングエージェントはテストファーストプログラミングをやるわけですが、人間が介入しないのであれば歩幅は大きくても構わないという考え方もできます。委託モードや非同期で開発する場合は、古典的な小さい歩幅の TDD ではなく、大きい歩幅のテストファーストプログラミングでやってもらってもいいという場合もあるでしょう。一方で、小さい歩幅でやってもらったほうがうまくいくという場合もあります。
同期的開発におけるレッドグリーン TDD
伴走モードのように、一緒にリアルタイムでコーディングエージェントとコードを書いていくときは、テスト駆動開発の中でも古典的なテスト駆動開発でやってくださいという指示のほうがうまくいきます。人間がレビューしやすいからです。
ポイントは「TDD でやってください」と指示するだけでは不十分で、もっと具体的に指示することです。「絵を描いてください」と「ジブリ風の絵を描いてください」で結果が違うように、TDD にもスタイルの幅がある。ケント・ベックのスタイルで TDD をやってくださいと指示するとオリジナルに近い TDD になりますし、**「レッドグリーン TDD をやってください」**と指示すると古典的な細かい TDD を実行するようになります。
なぜレッドグリーン TDD が伴走モードで有効なのか
端的に言うと、一度に出てくる差分（diff）が小さくなるのです。テストファーストプログラミングでは大量の差分が一度に生成され、人間としては「良さそうだから OK」としか言えない。レッドグリーン TDD で小刻みにしてもらうと、リアルタイムレビューができ、必要に応じて即座に介入できます。品質を高めたいケースにおいては、歩幅の小さい TDD で人間が即時レビュー・即時介入できる体制を作ることが非常に有効です。
現時点での TDD と人間・AI の関係
整理すると、現時点でのテスト駆動開発とコーディングエージェントと人間の関係は、次のようになります。
同期的に開発する場合は、AI と一緒にまず要件をプランニングします。次にレッドグリーン TDD を回します。そのとき、自分だったらこうやるだろうという予想を持ちながら、AI も同じような方法をたどるかどうかを見ていきます。
予想と違う場合に、2 つの反応があります。1 つは良い驚き——「ああ、なるほど、そういうやり方もあるのか。悪くないね」という形です。もう 1 つは悪い驚き——「いや、そっちに行くな」という形で、ブレーキペダルを踏む、エスケープキーを押すという反応になります。
この「予想を持って見守り、良い驚きと悪い驚きを判別する」というところが、テスト駆動開発の現代的な位置づけです。
AI とのペアプログラミングとコードレビューの未来
佐藤氏： 今のお話を聞いていて、AI とペアプログラミングをしている感じだなと思ったのですが。
和田氏： はい、まさにそうです。ペアプログラミングとしてやっています。
人間がボトルネックになるか
佐藤氏： その場合、人間がボトルネックになったりしないでしょうか。先ほどレビューというキーワードが出てきましたが、AI が大量にプルリクエストを出してきて、それを全部レビューできないという話にもつながります。AI の生産性と人間のスピードをどう折り合いつけていくのかという点でいうと、ペアプログラミングだと人間のスピードに合わせる形になりそうですが。
和田氏： そうですね。なので、ここも広い視点で開発全体を考えていく必要があります。
コードレビューの解体と再構築——2026 年のテーマ
2026 年のテーマは、コードレビューをどう作り変えていくかです。
AI がたくさんコードを書いて人間がコードレビューする——これだと人間の負荷が高すぎてスピードも出ない。従来コードレビューが果たしていた役割をどう解体して、他のところに再配置していくか——これが今年のテーマです。伴走モードでのリアルタイムレビューは、その再配置の一つです。
佐藤氏： コードレビューのスピードが人間に律速されるという問題は残りませんか。
フロー効率とリソース効率
和田氏： ポイントは、AI 時代の伴走モードではAI を止めないということです。オートアクセプトモードで AI がどんどんコードを書いていくのを見ている形なので、そこまで遅くはなりません。
ここにフロー効率とリソース効率の考え方が関わってきます。後から人間がレビューしてからシップするのであれば、人間がその場で即時レビューして、セッションが終わったらデプロイできる状態にするほうが全体の流れが良い。これがフロー効率重視の考え方です。一方、8 並列で AI にコードを書かせて大量のプルリクエストを順番にレビューするのはリソース効率重視ですが、リソース効率を重視してもあまり意味がないというのは、我々が何十年もかけて学んできたことです。
内部品質のバランスが変わった——理解容易性と変更容易性
佐藤氏： 先ほどのスライドで「内部品質」というキーワードを出しましたが、やはりレビューは必要なのでしょうか。去年、いろいろな方の記事を読んでいると、「もう AI が読んで AI が書くのだから、内部品質は担保しなくてよい。単体テストが動いていればいいのではないか」と言っている人もいました。和田さん的にはどうお考えですか。
和田氏： そこは変わるところと変わらないところがあると思っています。
まず、内部品質——特にメンテナビリティ（保守性）ですね。保守性は理解容易性、変更容易性、テスト容易性、再利用性といった品質副特性に分解できます。
理解容易性の重要性は変わらない
システムの規模が大きくなると、どこをいじるとどこが壊れるという状態になり、理解容易性やモジュール性を高めていかないと開発が進まなくなる。コーディングエージェントでどんどんコードを書くほど、そうなるポイントが前倒しになります。だから理解容易性の重要性は変わらない——むしろ AI と一緒にコードを書く時代にはもっと大事になってくる。AI にとってのコードの読みやすさと人間にとっての読みやすさは今のところ一致しています。これは幸せな一致です。
変更容易性のバランスが変化した
一方、ここ 1〜2 年で一番変わったのは「変更容易性」です。変更容易性はこれまで「人間がコードを変更するうえでの容易さ」として定義されてきましたが、この 2 年でコードを変更する主体が人間から AI に変わりました。AI は「変えろ」と言えば淡々と変えるし、24 時間働ける。変更量に対する許容量がまったく異なります。
理解容易性と変更容易性のシーソー
理解容易性と変更容易性は基本的にはともに高まっていくのですが、どこかでトレードオフになるタイミングが訪れます。その分かれ道で、テックリードやアーキテクトは厳しい判断に向き合わされる。しかし今や「変えろ」と言ったらひたすら変える存在が変更の主体になるので、理解容易性のほうに倒す——そのシーソーのバランスが変わったのです。
品質特性の再構築
これまでのソフトウェアエンジニアリングは人間がシステムを変えることを前提に設計原則やメトリクスが設計されてきました。コードを読むのは人間も AI も読む一方で、変更するのは AI が主体になっていく。品質特性の再構築が必要な段階に入ってきています。内部品質の重要性は変わりませんが、品質副特性のパワーバランスは変わった。変更容易性よりも理解容易性のほうが相対的に大事になった——そういう変化です。
要件定義とコンテクストエンジニアリング
佐藤氏： ここまで TDD や詳細設計、単体テストといった話でしたが、もう少し上流のほうに行きたいと思います。要件定義や、先ほど「インテント」という言葉が出てきましたが、やりたいことを AI エージェントに渡してコーディングするところまで、どのように持っていくかという点で何かありますか。バイブコーディングで雰囲気でバンバン渡してしまう場合もあれば、それだと手戻りが多くなるからと「振る舞い駆動設計」のような話も出てきていますよね。そのあたりはどうお考えですか。
プロトタイピングが容易になった時代
和田氏： まず、詳細設計のようなものは、コーディングエージェントと一緒にやっていくという段階にはもうすでに入っていると思っています。その詳細設計自体を SDD（Specification-Driven Development）のような形でやってもいいですし、プランナーモードでやってもいいですし、これまでのイテレーションの積み重ねで議論するというのでもいいでしょう。
どちらかというと要件定義や企画のほうがやりやすくなりました。試行錯誤のための物的生産性が高まったので、仮説検証やプロトタイピングがここ 2 年で非常にやりやすくなった。動くシステムを触ってもらうのが要件を決めるときに一番前に進むのは経験してきたことですが、「8 種類のプロトタイプを作るのは難しい」と 1 つ作るのが精一杯だったところが、8 種類持っていくこともできるようになった。価値探索とプログラミングが去年一番近づいた時代になりました。
プレーンテキスト化とモノレポの親和性
佐藤氏： コンテクストエンジニアリングという言葉がそのあたりで入ってくると思うのですが、いろいろな企業を見ておられるなかで、要件をエージェントに渡してプロトタイプを作るという取り組みは進んでいますか。
和田氏： そうですね。要件定義という観点で大きく変わってきたのは、要件定義のアウトプットをプレーンテキストに近いもので扱うようになったということです。
エクセルでやってきたものをプレーンテキストに近いフォーマットで扱い、コードの近くに置く。「何を作るか」「どう作るか」を同じリポジトリに入れていく。これがモノレポが増えている理由の一つです。コードを管理するように文書も要件も管理する時代になってきています。
大規模な企業ではエクセルの定義書類をプレーンテキストに変換するか、エクセルのまま AI に読ませるためのチューニングをするか、バリエーションがあります。基本的にコンテクストエンジニアリングはモデルに対する入力のキュレーションです。
情報の整理整頓がすべてを左右する
情報が整理されていればコンテクストエンジニアリングはやりやすく、乱雑だとやりにくい。どの情報がどこに置いてあって、どう管理されているか。整然としているほどやりやすいし、乱雑だとやりにくい。本質はこれまでと変わりません。
佐藤氏： そこはやっぱり人も AI も一緒ですね。今まで情報がいろいろなところに分散していると、何かあったときに発掘するのが大変で、結局コードを読むしかないという状況になっていましたから。
和田氏： はい、まさにその通りです。
総括：AI はアンプリファイアであり、アンラーニングが必要
佐藤氏： 総括的なところで伺いたいのですが、今日は和田さんからプログラミング・詳細設計・テスト・コードレビューを中心にお話しいただきました。AI 時代のエンジニアリングの原則という観点で、大事にしたほうがいいことは何でしょうか。
DORA 2025 レポート——AI は増幅器である
和田氏： 原則ですので、変わるものと変わらないものという話になるかと思います。今日もそういう話をしてきました。ここでは 2 点に絞ります。
まず 1 つ目。去年の DORA のレポート——DORA 2025 レポートで、「AI はアンプリファイア（増幅器）である」という結論が出ています。つまり、AI が出てくるとみんな等しく底上げされるかというと、そうではない。
DORA の前提は、企業の業績とソフトウェア開発力には因果関係があるということです。去年のレポートが示しているのは、ソフトウェア開発が上手い企業は AI によってさらに上手くなり業績も高まる。一方で苦手な企業は AI によってより混乱が高まり、競争力がさらに厳しくなる——という身も蓋もない結論です。
つまり、変わらないのです。AI より前に「DX をちゃんとやろうね」と言っていたことは、「コンテクストエンジニアリングをちゃんとやろうね」と実は変わっていない。コツコツ積み上げていくことが掛け算となって差につながる。内部品質への投資、情報の整理整頓——変わりません。アンプリファイアとして、その差がよりえげつない形で出ていくだけです。
アンラーニングの必要性——変更の主体が変わった
1 つ目は「AI はアンプリファイアである」ということでしたが、2 つ目は「とはいえ、アンラーニングしなければならないことが出てきた」という点です。
50〜60 年のソフトウェアエンジニアリングの歴史の中で、常にコード変更の主体は人間でした。ここ 2 年で人間以外がソフトウェアを変更する時代に急速に入った結果、考え方が通用するところと変えてよいところが出てきています。キャリアが長い人ほど、大事にしてきたことのいくつかは変更の主体が人間だからこそ大事だったという側面がある。自分の手でコードを書くということも、我々はすでにアンラーニングの最中にあります。僕はコードを書くのが大好きだったので辛くてたまらないのですが、それでもアンラーニングしていくわけです。
人事評価の問題——理解と出力の乖離
たとえば、今のところ計測できなくなって世の中が大変な騒ぎになっているのが「人事評価」です。
これまで、コードの出力とエンジニアの対象に対する理解というのは、基本的に連動が取れていました。対象を理解できているからコードが書けている、という関係だったので、コードレビューをすれば、相手が対象を理解しているかどうかをある程度推測・測定できました。
しかし、ここ 2 年で、理解していなくてもコードが出てくるようになりました。結果的に、「理解しているかどうか」が今は計測できていないのです。
今後のインシデント予測
理解していないけれどコードが出てきて動くものが、長期的にどうなるか——それを我々はまだあまり体験していません。これからだんだんと、今年や来年にかけて、何らかの重大な障害や何らかのインシデントによって、我々はそれを目撃していくことになると思います。
それによって、新たな時代のメトリクスとして、コードを書いた人の理解度をどう計測するか、どこでブレーキをかけるか——そういったところにも議論が入ってくるでしょう。
佐藤氏： そうですよね。開発するときもそうですけれど、本番にリリースしてトラブルがあったときに、中身がわかっていないと対応できないですよね。
和田氏： 実際にもそうなってきていて、「それを調べるのも AI にやらせればいいじゃないか」という話もあります。それはそうなのですが、そうすると「なんでこうなっていたの？」ということを目撃することになるんですね。なので、まだまだいろいろ混乱はあるだろうなと思います。AI に「なんでこうしたんだ」とトラブルが起きてから聞いても、もう遅いですからね。
佐藤氏： ありがとうございます。それでは、そろそろ時間になりましたので、このセッションはここで終わりにしたいと思います。ありがとうございました。
参考リンク・出典
本記事中で言及した第三者発言・ドキュメント・書籍の出典です。
- TechLead Conference 2026 公式サイト: https://eight-event.8card.net/techlead-conference/
- 佐藤治夫氏 当日スライド「AI 時代のエンジニアリングの原則 / Engineering Principles in the AI Era」: https://speakerdeck.com/haru860/engineering-principles-in-the-ai-era
- DORA 2025 レポート（State of AI-assisted Software Development）: https://dora.dev/dora-report-2025/
- Anthropic 公式「Claude Code Best Practices」（TDD と Agentic Coding の親和性に言及）: https://www.anthropic.com/engineering/claude-code-best-practices
- アラン・M・デービス『ソフトウェア開発 201 の鉄則』（原書: 201 Principles of Software Development, McGraw-Hill, 1995 / 邦訳: 日経 BP, 1996）— 鉄則 41「今すぐ要求仕様書の誤りを直せ」
- ダリオ・アモデイ氏（Anthropic CEO）の発言（Council on Foreign Relations, 2025 年 3 月 10 日）— 「3〜6 か月で AI が約 90% のコードを書く世界になる」等の趣旨。報道のひとつ: https://www.windowscentral.com/software-apps/work-productivity/anthropic-ceo-dario-amodei-says-ai-will-write-90-percent-of-code-in-6-months
- 和田卓人氏 Agile Japan 2025 キーノート資料「AI 時代のソフトウェア開発を考える（2025/11 版）」: https://2025.agilejapan.jp/wp-content/uploads/2025/11/1114_1000-1050_キーノート_agentic-software-engineering-agile-japan-202511.pdf
- 和田卓人氏 × やっとむ氏 対談「AI エージェント時代に、テスト駆動開発（TDD）は『ガードレール』になる」（Agile Journey, 2025/08/29）: https://agilejourney.uzabase.com/entry/2025/08/29/103000
- 和田卓人氏ブログ「【翻訳】テスト駆動開発の定義」（Kent Beck "Canon TDD" の和訳）: https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck