Unit7 リサーチプロダクトチームの佐藤（@riku929hr）です。
2026年7月22日と23日の2日間、ファインディさん主催の AI DevEx Conference 2026 に現地参加してきました。
Dave Farleyさんの『Modern Software Engineering』に一通り目を通してから臨んだのですが、初日の基調講演がまさにそのFarleyさんでした。 読んでおいてよかったです。
- AI DevEx Conference 2026 について
- AIは増幅器であり、鏡でもある
- 残ったボトルネックは、確認と理解
- 投資すべきは、共有知識（shared knowledge）とガードレール
- 認知負債への処方せん
- おわりに
- We are Hiring!
AI DevEx Conference 2026 について
会場はJPタワーホール＆カンファレンスで、オンラインとのハイブリッド開催でした。 クロージングセッションでは、申込2,510名、会場来場1,340名、オンライン視聴1,420名という参加者数が発表されていました。 2日間とも会場は大勢の人で賑わっていました。
海外からの登壇者が多いカンファレンスで、スクリーンの右側にAIによる同時翻訳の字幕が流れる形式でした。 英語のセッションでも内容を追いやすく、字幕を目で追いながらスライドを撮る、という聞き方ができたのはありがたかったです。
2日間で聞けたのは8セッションでした。 同じ時間帯に聞きたいものが重なることも、座席の予約がすでに埋まっていることも多かったです。 それでも、どれも学びが多く自分にとって刺激的な2日間となりました。
撮影は許可されていたものの会場限定のセッションが多かったので、資料が公開されているものを除き、スライド写真をそのまま使うことは避けようと思います。 その代わりに、登壇者の言葉を引用しながら紹介します。
振り返ると、多くのセッションが似たような主張に行き着いているようにも感じました。 そこでこの記事では、セッションごとの紹介ではなく、持ち帰った学びをテーマ横断で自分なりにまとめてみます。
AIは増幅器であり、鏡でもある
2日間で何度も出てきたのが、AIを増幅器として捉える見方でした。 初日の基調講演では、Farleyさんが、開発生産性の調査で知られるDORAのレポートを引いていました。
AI is an amplifier It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.
また2日目の基調講演では、Eirini Kalliamvakouさんが次のように述べていました。
AI is a mirror as much as an amplifier.
増幅されるものは組織がもともと持っているものでしかありません。 だからAIを入れると、いまの組織の状態がそのまま映し出される、という意味です。
では、AIは実際に何を速くしたのでしょうか。 速くなったのはコーディング作業であり、ソフトウェア開発全体のプロセスから見れば一つのステップに過ぎません。 講演で引用されていた調査によると、開発者がコードを書くことに使っている時間は、そもそも全体の14%ほどだそうです。
Kalliamvakouさんの2日目の登壇では、これをリレー競走にたとえていました。 陸上競技のリレーの勝敗はバトンパスで決まるそうです。 現に、日本代表のバトンパスは芸術的でよく話題になりますよね。 開発プロセスも同じで、一人の出力が次の人の入力になり、それがまた次へと連鎖していきます。 その連鎖のなかで誰か一人が劇的に速くなっても、全体としてはそこまで加速するわけではない、という主張でした。 この比喩は秀逸で、とても印象に残りました。
この議論は、次のような言葉で締めくくられていました。
Individual acceleration is real. It just isn't the point. The point is the system you put it through.
AIで個人が速くなること自体は実際に起きているが、その速さを通す先のシステムのほうを見なくてはならない、ということです。
残ったボトルネックは、確認と理解
最近では、AIで実装が速くなったことで、レビューやQAがボトルネックになるという事象が起こっているのをよく見聞きするようになりました。 Kalliamvakouさんの登壇では、"Speed creates new constraints that require new judgment."と述べられていました。 AI特有の「速さ」が、これまで表に出ていなかった別の制約を生み、その制約が新しい判断を要求することになります。 レビューもQAも、AIの出力を人が確かめる工程です。 速さが生んだ1つ目の制約が、この確認です。
もう1つの制約が、理解です。
2日目の最後、t_wadaさんによる Keynote「2026年のソフトウェア開発を考える」では、認知負債に多くの時間が割かれていました。 認知負債とは、AIによるコード生成が先行し、人間の理解がついてきていない状態を指す言葉です。 かつては理解していなければコードを書けなかったので、コードを書けることが理解できていることと等価でした。 AIがコードを書くようになって、理解していることの指標としてのコードという役割がなくなった、という指摘にはとても納得しました。 しかも技術的負債と違って、認知負債には測る指標が現状ありません。
t_wadaさんの登壇でも指摘されていましたが、最近のAIが出力するコードは比較的きれいで、いわゆる技術的負債は少なくなっていくのかもしれません。 その代わりに、共有された理解が損なわれ、誰も完全には把握していないコードが生まれることと、システムの背後にあった「なぜ」が失われることは大きなリスクになり得ます。
投資すべきは、共有知識（shared knowledge）とガードレール
Kalliamvakouさんが、AIで開発生産性を上げていくための2つの基盤として挙げていたのが、共有知識（shared knowledge）とガードレールでした。 僕は、共有知識とはコードに変更を加えるために必要なドキュメントやノウハウ（スタイルガイドや仕様決定の意図、ADRなど）を指していると解釈しました。 ガードレールのほうは、エージェントに何ができて何ができないかを決めて統制するもの、と説明されていました。 そしてそれらは作って集めるだけでなく、コードと同様にメンテナンスし続けなくてはならない、とも述べていました。
これと似た話を、初日のUberのセッションでも聞くことができました。 エージェントに調査させて理解を組み立てても、その学びはどこにも記録されず、別のエンジニアがまた8分、10分とかけて同じ調査を繰り返すことになります。 コストをかけて得たはずの理解がそのたびに消えていき、さらにトークンコストもかさんでいく、という指摘です。
Kalliamvakouさんは、この2つをレビューの対象に据え直していました。
Review the shared knowledge, not each line. Review the guardrails, not every diff.
レビューが追いつかないという課題に対して、何をレビューして何をレビューしないのかという線の引き方そのものを変える必要がある、という提案です。 さらに、これら2つを充実させるための投資の必要性にも話が及びました。
この投資は、AIエージェントに作業を委譲していくうえで不可欠であるということも強調されていました。 基盤を整える前にAIエージェントへの委譲を増やしていくと、いつの間にか壊れていて、しかもそれに気づかないということも考えられます。 そうならないように先に投資しておく必要がある、ということですね。
認知負債への処方せん
認知負債に対しては、t_wadaさんのセッションで1つプラクティスが紹介されていました。 コーディングエージェントが出したプランをそのまま先に進めるのではなく、途中に理解度チェックを挟むという手法です。 これはすぐに取り入れられそうな取り組みだなと思いました。
さらに、AIの活用と理解は共存できる、ということも、研究結果を交えて提示されていました。 やり方次第ではうまく「負債」をコントロールできるということなんだと思います。
おわりに
1年ほど前、「AI時代、どう学ぶか」というブログを書いたのを思い出しました。
その頃からすると、AI、LLMの性能は大幅に向上し、時代がどんどん変わりゆくのを感じます。
今回のカンファレンスでは、開発生産性について調査・研究されている海外のエンジニアが多く登壇され、貴重な話を聞くことができました。 このブログでは、AIを活用して開発生産性を上げていくためにはどうすればよいのか、という観点で参加体験を書きましたが、 本文中で触れた登壇以外にも発見の多い発表が数多くありました。 実りのある2日間になったと思います。
AIの活用強化に向け、すでに自チームで行っている取り組みもたくさんありますが、今回のカンファレンスで得た学びを還元してさらに開発生産性を上げていきたいです！
We are Hiring!
エムスリーではエンジニアを絶賛募集しています！ 少しでもご興味をお持ちの方は、ぜひカジュアル面談等にご応募ください！
