こんにちは！先進技術戦略室の中谷です！

2026年7月30日・31日に東京ビッグサイトで開催された Google Cloud Next Tokyo 26 に参加してきました。本記事では、初日に聴講した「AI エージェント時代の『分業設計』」のレポートをお届けします。

パネルディスカッション形式のセッションで、AI をどう使うかという技術の話ではなく、AI を使う側の組織と評価の仕組みをどう変えるかという話が中心でした。ツールの話に寄らないぶん、聴きながら自分の現場に置き換えて考えさせられる時間になりました。

セッション概要

項目 内容
セッションID D1-BFE-01
日時 2026年7月30日（木）16:00 – 16:30
会場 Room 3
種別 カスタマー セッション
レベル 初級者向け

登壇されたのは以下の3名です。

登壇者 所属
及川 卓也 氏 Tably株式会社 代表取締役
鐵尾 周平 氏 株式会社 本田技術研究所 SDV研究開発センター シニアチーフエンジニア
清水 岳之 氏（司会進行） Google Cloud パートナー事業本部 パートナーデベロップメント マネージャー

公式セッションカタログでは、以下のように紹介されていました。

AI が単なるツールを超え、自律的な「エージェント」へと進化を遂げる今、人間とテクノロジーの関係性は大きな転換期を迎えています。本セッションでは、これからの時代における「人と AI の最適な分業設計」について探求します。私たちは AI とどのように役割を分かち合い、新たな価値を共創していくべきなのか。未来の組織と働き方のグランド デザインを議論します。

セッションは、Google の DORA 研究を出発点として提示したうえで、2つの討議テーマを順に扱う構成で進行しました。

討議のスタートポイント

議論は、Google Cloud の DORA（DevOps Research and Assessment）による最新研究「The ROI of AI-assisted Software Development」の紹介から始まりました。

AI 駆動開発について顕在化している課題として、以下の2点が挙げられていました。

課題 内容
J カーブ AI 導入によって一時的に生産性が低下する現象
検証税（Verification Tax） AI が24時間体制で大量に出力したコードを、人間が監査・レビューする認知的負担の爆発

そして「AI を導入したのに成果の線が引けない」という世界的な戸惑いが起きている、という現状認識が共有されました。

補足すると、J カーブは導入直後にいったん成果が落ち込み、その後に回復して伸びていく曲線のことです。新しいやり方に慣れるまでの谷をどう乗り越えるかという話であり、AI 導入に限った現象ではありません。ただし検証税のほうは AI 特有で、生成量が人間のレビュー能力を超えることで生じます。この2つが重なることで「入れたのに成果が出ない」という状態になる、というのが議論の出発点でした。

討議テーマ1

1つ目のテーマは、AI 時代の委託型 SDV（Software Defined Vehicle）開発における、「ビルドトラップの回避」と「アウトカム評価」の不整合をどう乗り越えるか、というものでした。

ビルドトラップとは、機能を作ること自体が目的化してしまい、顧客価値や事業成果につながらないまま開発が回り続ける状態を指します。プロダクトマネジメントの文脈でよく使われる言葉です。

AI は増幅器である

議論のなかで繰り返し出てきたのが、AI は単なるツールではなく増幅器である、という捉え方でした。

すでに高い水準の開発ができている組織に導入すれば成果がプラスに増幅される一方、うまくいっていない組織に導入すればマイナスのほうが増幅される。AI さえ入れれば良くなるという話ではない、という指摘です。

この前提に立つと、ビルドトラップに陥っている組織に AI を入れることは、無駄な機能を作る速度を上げるだけになります。コーディングのコストが下がるほど、作る前の判断の重さが増していく構図です。

開発生産性の測り方を変える必要がある

DORA はこれまで開発生産性の指標をリードしてきましたが、その多くはデプロイ頻度のような「どれだけ出せたか」を見るものでした。AI によってデプロイの数がいくらでも増やせるようになった今、この指標だけでは意味をなさなくなってきています。

開発できたことよりも、それが本質的に事業に貢献しているかどうか。ROI で成果を測るかたちに変えていかなければ、今の時代には意味がない、という話が展開されました。

及川氏からは、コーディングのコストが下がる代わりに、別のところでコストが上がっているはずだという指摘がありました。そのひとつが「理解負債」です。書かれたコードを人間が理解できていない状態が積み上がっていくというもので、目に見えないぶん厄介です。

アウトカムの評価は元々難しいものですが、その重大性はどんどん増している。開発のコストが下がった分だけ大量のものが上がってくるので、それをしっかり評価できるようにしないといけない、という話でした。

業界の構造そのものを変える必要がある

鐵尾氏からは、自動車業界の当事者として踏み込んだ話がありました。

機能を作れば作るほどインセンティブが増える構造そのものを変えなければ、今のままでは厳しくなる。AI によってどんどん簡単に機能が開発されていくからです。人月で商売が成り立ってきた構造も、AI で効率化が進むほど利益が下がっていくことになります。

また、職種の概念そのものが変わってきており、数か月単位で必要とされるものが変わっていく。時代に合わせて適切に方針を変えていく必要がある、という話もありました。

技術トレンドの話として聞き始めたセッションでしたが、ここは商流の話でした。効率化した分だけ売上が減る構造を持っている限り、AI 活用は現場の努力では進みません。開発の内側だけを見ていても解けない問題があるということが、当事者の言葉で語られたのが印象的でした。

討議テーマ2

2つ目のテーマは、「検証税」による「責任のスポンジ化」を、AI と人間の間の「Radical Candor（徹底的な率直さ）」と「HRT（謙虚・尊敬・信頼）」によってどう防ぐか、というものでした。

Radical Candor は、相手を気にかけたうえで直接的に指摘する姿勢を指す言葉です。HRT は Humility（謙虚）、Respect（尊敬）、Trust（信頼）の頭文字で、Google のソフトウェアエンジニアリング文化を語るうえでよく引き合いに出される原則です。

セッションでは、その HRT の出典が引用されていました。

ソフトウェア開発とはチームによる取り組みであるということだ。そして、エンジニアリングのチームで（あるいは他のどんな創造的共同作業でも）成功するためには、「謙虚、尊敬、信頼」という中心的原則をめぐる自身の行動を改革する必要がある

出典：『Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス』（Titus Winters、Tom Manshreck、Hyrum Wright 編、竹辺靖昭 監訳、久富木隆一 訳、オライリー・ジャパン）

評価できる形で残していく

AI の生成物に対して抱いた疑問や批判を、そのまま流さずに残しておき、後から評価できるようにする必要がある。そしてその評価の仕組みそのものを作っていく必要がある、という話がありました。

外部への委託と比べると、AI が入った開発は構造が複雑になります。人に頼むのであれば、なぜそうしたのかを聞けば返ってきますが、AI の出力にはその経緯が残りません。だからこそ、疑問を持った側が記録に残す作業が要る、という理解をしました。

率直に言える組織であること

及川氏からは、開発はチームプレイであり、そこで効いてくるのが HRT だという話がありました。

いかに率直に自分の意見を言えるか。そして、それを言える組織になっているか。理想の状態に対して率直に言える個人がいて、その文化を作る組織であることが、AI 時代には重要になる。この2つを徹底する必要がある、という指摘でした。

そして、その組織づくりができて成果が出始めてから AI を入れることで、成果が増幅される。本来やれていないといけないことができていない状態では、AI を入れても効果がない、という順序の話につながりました。

さらに、自分たちとして何をするべきか、何を重視するべきかというガードレールや倫理観を自分たちで引く必要がある、という話もありました。

セッションの締めくくりとして示されたのが、この図です。

心理的安全性の担保を土台として、謙虚・尊敬・信頼が積み上がり、そこに Radical Candor が加わることで徹底的な意見交換が生まれ、アウトカムへの集中につながる。そしてその流れのなかで、AI Agent はインプットの一つとして位置づけられていました。

AI を中心に据えるのではなく、人間のチームによる討議のインプットとして扱う。この図の構造が、セッション全体の主張をそのまま表していたと思います。

まとめ

30分の討論を通して、以下の3点が軸になっていたと受け止めました。

  • AI は増幅器であり、組織の状態がそのまま拡大される。良い開発ができている組織はプラスが、そうでない組織はマイナスが増幅される
  • コーディングのコストが下がったことで、デプロイ数のような従来の生産性指標は意味をなさなくなり、アウトカムをどう評価するかが問われている
  • 機能を作るほど儲かる構造そのものを変えないと、AI 活用は現場の努力では進まない

さいごに

聴き終えて一番頭に残ったのは、次にやるべきなのはアウトカムを評価する仕組みづくりだ、ということでした。

AI を導入する話は、すでにどの現場でも動いています。一方で、それによって何が良くなったのかを測る側は、ほとんど手つかずのまま残っています。開発のコストが下がった分だけ生成物は増えていくので、評価の仕組みがないまま進めば、良いものと悪いものが混ざったまま積み上がっていくことになります。J カーブの谷から抜け出せているのかどうかも、測る手段がなければ分かりません。

作れる量が増えたことよりも、増えた量をどう捌くかのほうが、これからの課題になっていくのだと思います。そしてそれは、ツールを入れれば解決する類の話ではありませんでした。

まずは議論の出発点だった DORA のレポート「The ROI of AI-assisted Software Development」を読み、AI 駆動開発の成果がどう測られようとしているのかを確かめるところから始めます。

最後までお読みいただき、ありがとうございました。