author
authorDisplayName
Keisuke Yoshida
category
AI
event
mainImage
published
published
publishedAt
Aug 12, 2026
slug
aidevex2026
tags
Engineering Management
AI
こんにちは。令和トラベル AX室のyoshikeiです！
2026年7月22日~7月23日の2日間に渡り「AI DevEx Conference 2026 - Future of Development Productivity -」が開催されました。参加されたみなさま、カンファレンス運営に携わったみなさまお疲れさまでした。
今回は AI DevEx Conference 2026 において印象に残った内容や、当日の様子を交えてイベント内容をお伝えしたいと思います。
『AI DevEx Conference 2026』について
カンファレンス概要
AI DevEx Conference 2026 とは？
今、私たちは「つくる」ことの歴史的な転換点にいます。
AIのめまぐるしい進化の波は、
「開発生産性」という言葉の意味さえ変えつつあります。
単につくるだけなら、瞬時にアウトプットできるようになった時代に、
エンジニアに求められることは何か？開発組織に求められることは何か？
それが企業にとってどのような変化をもたらすのか？
アウトプットではなく、アウトカムへ。
プロダクトではなく、価値へ。
個人のパフォーマンスを超え、人とAIが協働できる環境へ。
AI DevEx Conference 2026 - Future of Development Productivity -は、
その最先端の知見や、世界のベストプラクティスを通して、
これからの時代の開発のヒントを提供します。
※ AI DevEx Conference 2026 (イベントサイト) より
タイムテーブル
イベントはセッションパートと懇親会パートの二部構成で開催されました。
セッションはA~Dの4つのホールに分かれて実施され、同時にスポンサーブースの出展や企画ブースが用意されていました。
▼ タイムテーブルの詳細はこちら
イベント当日の様子
AI DevEx Conference 2026 は、去年までは 開発生産性カンファレンス として開催されていました。AIの台頭によって単につくることのコストが省力化された中で改めて「開発生産性」とは何なのか？を問い直すセッションが多かったように思います。まだまだ過渡期といえる状況の中で各社の考え方や取り組み、スタンスを目の当たりにすることができ、自分たちの現在地を見つめ直すきっかけになりました。
セッション以外にも、ブースや AI DevEx Gallery という形でのポスターセッション、スタンプラリー、懇親会など多くの意見交換の場が用意させており、議論が活発に行われていたように思います。
印象に残ったセッション
#1 AI時代の開発生産性を捉え直す — 経営と現場をつなぐ「開発組織のオブザーバビリティ」 — | 京和 崇行
本セッションでは、Four Keysに代表される開発生産性指標がどこまで到達し、どこで限界を迎えているのかという問い直しから、開発組織そのものを観測可能にするという構想が語られました。
まず提示されたのは、いま計測できていることの範囲です。 かつて計測不可能とまで言われた開発生産性は、Four Keysの普及によって「速度と品質はトレードオフではない」ことを示せるようになり、ハックされにくい優れた指標設計として評価されています。一方で、そこで観測できているのはソフトウェアのデリバリー能力に過ぎず、以下についてまでは捉えきれていないという限界が指摘されていました。
- 企画から事業成果（アウトカム）に至るプロダクト開発の全体像
- コードベースの内部品質
そのうえで語られたのが、AIによるボトルネックの移動です。 実装が劇的に高速化した結果、詰まる場所は「作る」から、その前後にある「何を作るか（意思決定）」と「確かめる（検証）」へと移っている。ここで効いてくるのが経営の視点でした。経営者は売上が上がったという数値をそのまま答えとして受け取るのではなく、それが一時的なのか構造的なのかと問いを連鎖させ、事前には想定できない「未知の未知」を探りながら自社の前提を書き換え続けている。同じ性質の問いが開発組織にも向けられているのに、既存の指標ではそれに答えられない。だから必要なのは指標を増やすことではなく、想定外の変化に気づき、個別の事象まで掘り下げ、仮説を書き換えていく探索能力なのだ、という論の運びには強く納得させられました。
実践として紹介されたのが、開発組織を複雑系のシステムとみなすアプローチです。 カカクコムでは「事業の戦略意図とエンジニアの投下リソースが合致しているか」という問いを起点に、全活動を次の4つに分類したプロジェクトツリーを構築しているとのことでした。
- 戦略投資
- 成長投資
- 運用保守
- 間接業務
このツリーに個別のプロジェクトや投下時間、工程、個人の活動を紐づけることで、経営層が集計値から現場の実態へドリルダウンできる状態をつくっている。人が詳細な活動記録を残すことには限界がありましたが、AIが日常のフットプリントから活動イベントを自動生成することで観測の限界そのものを押し広げられる。人とAIを同じ実行主体として記録するという発想には、視界が開ける感覚がありました。
特に印象的だったのは、グッドハートの法則への向き合い方です。 指標が悪いのではなく、単一の操作しやすい指標を置くことが問題であり、明細まで観測できる状態をつくれば小手先の細工は効かなくなる。そのうえで未来から逆算して組織に求める行動を指標化すれば、組織のベクトルは自然と未来へ向く、という提言は、昨年の開発生産性Conferenceで語られた「指標が目標になると、それはもはや良い指標ではない」という警鐘に対する、ひとつの実践的な回答を受け取ったように感じました。AIネイティブな企業とは、AIを高度に使いこなす企業ではなく、人とAIを横断して学びを蓄積・増幅する学習ループを企業システムとして持てる企業である。組織を観測可能にすること自体がエンジニアリングの対象なのだと、視座を上げてもらえるセッションでした。
Proposal
#2 UberのAI時代の開発生産性：エージェントによる効率最大化とワークフローの進化 | Matas Rastenis
本セッションでは、Uberが自社の開発者プラットフォームをエージェント型プラットフォームへと転換し、コードの作成・レビュー・テスト・マイグレーションに至るまでをAIで回している事例が語られました。
まず提示された数字に、規模の違いを突きつけられました。エンジニアの約98%がAIを導入し、コードの約70%がローカルまたはバックグラウンドのAIエージェントによって書かれ、リリース速度は2倍に向上している。この水準に到達しているのは、個々のエンジニアがツールを使いこなしているからではなく、エージェントが安全に動ける土台を組織としてつくり込んでいるからだ、という前提が明確に示されていたのが印象的でした。
その土台として紹介されたのが、5つの基盤コンポーネントです。
- Model Gateway：全エージェントのリクエストを一元的に中継し、機密データの社外送信やコードインジェクションを防ぐ。1日1億リクエストを処理
- MCP Gateway：社内インフラや外部ツールへの接続口。全ツール情報を読ませるとコンテキストが溢れるため、CLIやPythonスクリプト経由で結果だけを抽出させる
- Devpods：Kubernetes上の仮想開発環境。PCを閉じてもエージェントが動き続け、複数リポジトリを単一環境に統合できる
- Agent Skills：タスク単位の機能を社内で検索・共有。モデル間の仕様差を標準フォーマットで吸収する
- Context Graph：ドキュメント・コード・インシデント・チーム情報を相互に結ぶグラフDB。リサーチ速度が14倍、コストは7分の1に
特にコスト管理の話は生々しく、エージェントがループに陥って数日で15万ドルを消費した過去の反省から上限設定と追跡を組み込んだ、というエピソードが共有されていました。エージェントの自律性を上げるほど、ガードレールの設計がそのまま組織の意思決定になるということを、実感を伴って理解させられた部分です。
そのうえで語られたのが、開発ワークフローへの実装でした。 アイデア出しではエンジニアやPMが社内ツールと連携したチャットで対話しながら要件を詰め、モックアップやPRD・ERDの作成まで支援を受ける。実装ではDevpods上でバックエンド・iOS・Androidの複数リポジトリに同一セッション内で変更を加え、Pull Requestのドラフトまで自動で作成する。検証では約75秒でAIレビューが指摘を返し、シミュレーターでUI変更前後のスクリーンショットや動画を自動生成して視覚的に差分を確認できる。CIが落ちればコンフリクト解消やテスト修正をエージェントが提案し、ワンクリックで適用できる。結果としてレビュー時間は1〜2時間短縮されたとのことでした。依存関係のバージョンアップやA/Bテスト後のデッドコード削除といった、後回しにされがちな維持作業が自動で流れていく点も強く惹かれました。
最も印象に残ったのは、自動化をスケールさせた結果として新たにCIキャパシティの確保が課題になっている、という締めくくりです。 ボトルネックは消えるのではなく移動する。前のセッションで語られた「ボトルネックの移動」が、実際に運用しきった組織の言葉として現れたことに説得力がありました。AIをどう使うかという議論の一段先に、エージェントが安全かつ高速に動ける環境をプラットフォームとして提供できているか、という問いがある。マネジメントする立場として、投資すべき対象がどこにあるのかを考え直すきっかけになるセッションでした。
Proposal
#3 AI × 開発生産性を取り巻く予算戦略と投資対効果 | 石垣 雅人
本セッションでは、AIの導入によって予算・会計・人事評価といった経営の土台がどう変わり、そのうえで投資対効果をどう最大化するのかが、実務の手触りを伴って語られました。
まず示されたのは、コスト構造そのものが移動しているという事実です。 これまでは人を増やして生産性を上げるのが基本でしたが、いまは個人の生産性をAIで上げ、さらにエージェントを増やしてスケールさせる形へと変わっている。その結果、コストの中心は人件費からソフトウェア利用料へとシフトしています。ここで厄介なのが会計上の扱いで、
- 人件費はソフトウェア資産として減価償却しやすい
- 一方でAIエージェントのツール費用は単月の費用として計上されがち
という非対称があるため、同じ投資をしてもP/L上では営業利益が悪化して見えてしまう。トークンコストが定額制から従量課金へ移行するなかで「1億円使ったらどこに投資対効果が表れるのか」を厳しく問われる、という話は、数字を説明する立場として非常にリアルに響きました。
評価の話も、避けて通れない論点として提示されていました。 年収500万円の人が500万円分のAIツールを使って成果を出したなら、実質1,000万円分の価値を担保できているかで見る必要がある。一方で、AIでサーバーコストを削減したとしても作業難易度自体が低ければ能力給として評価すべきか、といった新しい判断軸が求められる。技術スキルの伝承が「人から人へ」ではなく、プロンプトや環境の共有を通じて「スキルからスキルへ」スケールするようになったという指摘も含めて、評価制度が前提としてきたものが静かに崩れていることを突きつけられました。
生産性の捉え方については、「認知的負債」という言葉が強く印象に残りました。 AIが高速にコードを生成し、テストも通って動く状態になる一方で、それを構築したエンジニア自身の理解が追いついていない。この測れないギャップが、仕事への不安として現れてくるという整理です。あわせて、生産性の指標は経営層（P/L・B/S）、事業責任者（工数・金額）、現場エンジニア（内部品質・スループット）で意味が異なり、無理に直結させるのではなく、BigQuery等で財務指標からバリューストリーム、開発ライフサイクルまでを一元化して繋ぎ合わせるべきだと語られていました。
そのうえで、投資回収の打ち手が2つの戦略として整理されていたのが白眉でした。 投入工数に対する付加価値を1.5倍にするために、出口と入口の両方を広げるという発想です。
- 戦略1：開発プロセスのAIネイティブ化（出口を1.5倍に） — 「何を作るか」の前半は人がPilot・AIがCopilot、「どう実装するか」の後半はAIがPilot・人がCopilotとして品質を担保する。そしてスピードではなく品質特性を先行指標に置く。品質が上がれば遅行指標としてリードタイムは自然に縮む
- 戦略2：OpsのAI代替による工数創出（入口を1.5倍に） — 人事評価の作成や技術的負債の分析といった非開発業務・保守業務をAIに置き換え、生まれた余力を新規開発に回す
特にスピードではなく品質を先行指標に置くという判断は、目先の速さを追って失敗する典型を避ける現実解として、そのまま持ち帰りたい考え方でした。
最も印象に残ったのは、締めくくりの「AI-Ready」という視点です。 AIで生産性を上げる以前に、そもそもアジャイル開発ができているか、コードがAIリーダブルな状態になっているかという根本の問題にぶつかる。その下準備は、人が泥臭くリファクタリングするしかない。人の役割が入口（コンテキストの定義）と出口（品質とセキュリティの担保）に集約されていくからこそ、ドメイン知識と設計・アーキテクト能力が今まで以上に問われる。華やかな数字の裏側で、結局は地道な足場づくりが投資対効果を決めるのだと、背筋が伸びるセッションでした。
Proposal
#4 Built Our Own Background Agent at LayerX | izumin / itkq
本セッションでは、コーディングエージェントを自社で動かすための基盤をゼロから内製したLayerXの試行錯誤が、アーキテクチャの変遷とともに語られました。
出発点は、ローカルでエージェントを動かすことの限界でした。 Claude CodeやCodexを使った開発が当たり前になるなかで、次のような困りごとが顕在化していったといいます。
- PCを閉じるとエージェントが止まる。夜間や移動中も動かし続けたい
- ローカルマシンに強い権限と秘密情報が集まることによる、プロンプトインジェクションや悪意あるパッケージ実行のリスク
- git worktree等で並列開発する際、エージェントの動作環境も並列化するとCPUとメモリが枯渇する
- 環境構築コストと再現性。「手元で動かない」はエージェントにとっても大きなコストになる
- サブスクリプションの利用制限や従量課金におけるトークン最適化を自前で行う必要がある
興味深かったのは、そこから導かれた結論です。 必要なのはリモートで動くCoding Agentそのものではなく、エージェントをHTTP API等で呼び出し、イベントドリブンかつ自律的にタスクを遂行させられる仕組みだった。DevinやClaude Codeといった既存製品も検討したものの、社内の既存ツールが使えずブラックボックス化すること、特定プロバイダへのロックインなどから見送られています。欲しかったのは特定のAgentではなく、自由にAgentを動かせる「環境」だったという言い切りが、この取り組み全体の背骨になっていました。
その環境が、段階を踏んで進化していく過程が具体的でした。
- v0：GitHub Codespaces — 手軽に始められたが、CORSのPreflightが認証を通過できず、必須要件だったプレビュー機能が実質使えずに撤退
- v1：Modal Sandbox — コンテナの高速起動を得て、Temporalによる耐久性のあるワークフロー管理（Durable Execution）でエージェントのターンとライフサイクルを管理する基礎を確立。ただしVPC外であること、gVisorの制約、最長24時間の実行制限が機密データの扱いに不十分だった
- v1.5：Amazon EKS — VPC内に閉じ、素のDockerが使え、時間制限もない。CRDでワークスペースを作りライフサイクル管理をエコシステムに任せ、Gateway APIでポートごとのプレビューURLを自動発行。devcontainerをそのままビルドできるため、ローカルと同じメンタルモデルで開発できる
うまくいかなかったv0やv1の理由まで含めて語られていたのが良く、選択の背景にある制約が手に取るように伝わってきました。
さらに一段抽象度が上がったのが、Agent基盤「Haro v2」への進化です。 ここでの気づきは、コードの読み書きはあらゆるタスクの1つに過ぎず、「環境」はAgentのパラメータの1つでしかない、というもの。NotionやSlackのログを調査するだけのタスクに重いコンテナは要らず、高速に起動できるべきだからです。そこでVercelのAI SDKを使い、環境不要なToolLoopAgentと、EKS上のワークスペースでClaude Code等のランタイムを駆動するHarnessAgentを透過的に扱えるようにした。Agentは「モデル＋プロンプト＋ツール」のループにすぎないという整理のもと、SubagentもツールとしてTemporalのChild workflowで起動し、社内リソースへのアクセスはRemote MCPとして共通化する。Lead Agentがタスクを分解して特化したSubagentに委譲する構造まで、無理なく積み上がっていました。
最も印象に残ったのは、今後の展望として掲げられていた「Close the loop」です。 メールやWebhook、cronを起点に自律的に動くAmbient Agent、誰でもカスタムAgentを作って全社に配布できるMarketplace化、そしてプラットフォーム側でログとフィードバックを回収してAgent自身とツールの改善に還元し続ける。使えば使うほど賢くなる自己進化基盤という構想は、#1で語られた「学びを蓄積・増幅する学習ループ」を、基盤の設計として具体化したものに見えました。エージェントを配るのではなく、エージェントが育つ場所をつくる。組織としてどこに手をかけるべきかを考えさせられるセッションでした。
Proposal
他にも開催期間中にたくさんのセッションが企画されていました。詳しくはこちらをご覧ください！
おわりに
今回のカンファレンスを通じて強く感じたのは、「開発生産性」という言葉が指す範囲そのものが、この1年で大きく広がったということです。昨年までの開発生産性カンファレンスでは、Four Keysをどう計測し、どう改善するかという議論が中心にありました。しかしAIによって「つくる」コストが劇的に下がったいま、問われているのは計測の精度ではなく、何を観測の対象に置くのかという設計そのものです。指標を増やすのではなく探索能力を持つべきだという提言は、その問いに対するひとつの明確な回答だったように思います。
複数のセッションを通じて繰り返し現れたのが、ボトルネックは消えるのではなく移動する、という視点でした。実装が速くなれば「何を作るか」と「確かめる」が詰まり、そこを自動化しきれば今度はCIキャパシティが次の制約になる。生産性の改善は一度きりの施策ではなく、移動し続けるボトルネックを追いかけ続ける営みなのだと、複数社の実例を通して腹落ちさせられました。裏を返せば、いま自分たちがどこで詰まっているのかを見誤らないことが、投資判断の精度をそのまま決めるということでもあります。
もうひとつ印象に残ったのは、各社が投資している対象が個々のツールではなく「環境」だったことです。UberのModel GatewayやContext Graph、LayerXのHaro v2に至る道のりは、アプローチは異なるものの、エージェントが安全かつ高速に動ける場所を自分たちで用意するという点で共通していました。エージェントを配るのではなく、エージェントが動き、育つ場所をつくる。「誰がどのツールを使うか」ではなく「組織としてどんな環境を持つか」へと、議論の主語が移りつつあることを実感しました。
同時に、地に足のついた話が多かったことも印象的でした。人件費とツール費用の会計上の非対称、AIを前提とした評価軸の再定義、そして「AI-Ready」という言葉。AIで生産性を上げる以前に、そもそもアジャイル開発ができているか、コードがAIリーダブルな状態になっているか。その下準備は人が泥臭く積み上げるしかない、という指摘は、華やかな事例の並ぶカンファレンスにおいて最も現実的なメッセージだったと思います。
令和トラベルでも、AIを前提とした開発の進め方や、そこへの投資判断について日々議論を重ねています。まだまだ過渡期であり、正解が定まっているわけではありません。だからこそ、各社がどこで悩み、何を選び、どこで失敗したのかを共有し合えるこうした場の価値は大きいと改めて感じました。今回持ち帰った視点を、自分たちの現在地に照らしながら、ひとつずつ形にしていきたいと思います。
非常に学びの多い2日間でした。運営のみなさま、素敵なカンファレンスの企画・運営をありがとうございました！
令和トラベルでは一緒に働く仲間を募集しています
この記事を読んで会社やプロダクトについて興味を持ってくれた方は、ぜひご連絡お待ちしています！お気軽にお問い合わせください！
フランクに話だけでも聞きたいという方は、カジュアル面談も実施できますので、お気軽にお声がけください。
それでは次回のブログもお楽しみに！Have a nice trip ✈️
