生成AIによって、開発者がコードを書く量は減りつつあります。しかし、それによってソフトウェア開発の課題そのものがなくなったわけではありません。
むしろ、「何を作るのか」「どのように意思決定するのか」「どう品質を担保するのか」といった、これまで別の場所にあった課題がより鮮明になってきています。

2026年9月に開催された「XP祭り2026」では、まさにそうした変化を感じさせる講演が数多くありました。本稿では、それらを振り返りながら、AI時代におけるアジャイルとXPについて考えてみたいと思います。

イベントはオンラインとオフラインのハイブリッド形式で開催され、今回、私はオンラインで参加しました。
XP祭りは、その名のとおりXP（eXtreme Programming）を中心としたイベントです。今年の講演を振り返ると、ペアプログラミングやテストといったXPのプラクティスだけでなく、生成AI、プロダクト探索、組織変革、品質、開発基盤など、幅広いテーマが扱われていました。

XP祭り2026（日本XPユーザーグループ 公式サイト）

公式のタイムテーブルをもとに整理すると、基調講演1件、通常講演35件、ワークショップ6件の計42セッションがありました。すべてを単純に「XP」「スクラム」「AI」といったテーマで分けることは難しく、複数の論点をまたぐ講演も少なくありません。
そこで今回は、講演が「何を大切にし、どのような問題に着目し、何を改善しようとしているか」という観点から、私なりに6つに分類して振り返ります。

私が全体を通して特に感じたのは、「AIによってコードを作る速度が上がるほど、開発全体のボトルネックは別の場所へ移っていく」ということでした。コードを書くことが速くなっても、何を作るかを決めること、チームで理解すること、品質や価値を確かめることまで自動的に速くなるわけではありません。むしろ、これまで目立たなかった制約が、よりはっきり見えるようになったように感じます。

価値・思想・主体性
― XPは「プラクティス集」なのか

この分類を代表する講演として、基調講演の角征典さん「サンキューXP」があります。
講演では、かつて「エクストリーム」と呼ばれたXPのプラクティスの多くが、現在では名前を意識せず使われるほど一般的になった一方で、XPそのものを単なるプラクティス（形式）※1の集合として理解してしまうと、背後にある「何のためにやるのか」（理想）を見失ってしまうことへの問題提起がなされていました。さらに、その理想は個人やチーム、顧客や組織の利益にとどまらず、自分たちを超えた何かにまで及ぶのではないか、といった問いかけもありました。そのうえで、外側から他人を変えようとするのではなく自分自身がその変化の内側にいること、異なる考えをどちらが正しいかの二元論で切り捨てず両方を同時に抱える器の大きさを持つこと、そしてともに働く人や自分が作るものと共鳴（互いに影響を与え合い、変化すること）しながら動き続けること、それこそが「エクストリーム」ではないか、という考えが語られていました。

講演資料：「サンキューXP」（角征典）*外部サイト

編集部注

• ※1. プラクティス（形式）はソフトウェア開発で用いる具体的な実践手法。ここでは、背景にある目的や理想に対する「実践の形」を指します。

この講演から私が改めて考えたのは、ペアプログラミングやTDD（テスト駆動開発）、CI（継続的インテグレーション）などの「形」を守ること自体が目的ではないということです。技術や環境が変われば、適したプラクティスも変わります。しかし、なぜそのプラクティスを行うのか、その背景にある価値や原則、理想まで失ってしまうと、改善ではなく単なる置き換えになってしまいます。

これは、以前の私のコラムで取り上げた「形だけのアジャイルから中身のあるアジャイルへ」（Agile Japan 2023講演レポート）というテーマともつながります。AI時代だからこそ、手法をそのまま残すか捨てるかではなく、「何のために行っていたのか」を問い直す必要があると感じました。

共同理解・対話・学習
― AIで実装が速くなっても、人の理解は速くならない

この分類で特に印象に残ったのが、友野敬大さんの「ペアプロの価値は、コードを書くことだけじゃない」です。

講演では、生成AIを利用することで、従来2～3日を見込んでいた実装が0.5日で完了した事例が紹介されました。一方で、コードが速く生成されても、人間がその設計意図や変更内容を理解する速度まで同じように上がるわけではありません。巨大なDiff（差分）を後からレビューするだけでは認知負荷が高くなり、理解そのものを諦める危険もあります。

そこで実践されたのが、何でも常に2人で実装するのではなく、計画やタスク分割など、合意が重要な部分はペアで行い、実装は1人＋AI、最後にPull Requestをペアでレビューするという進め方でした。ペアプロの価値を「2人でコードを書くこと」ではなく、「設計や判断の理由を会話し、合意すること」と捉え直している点が、非常に興味深かったです。これは、対話を単なる情報伝達ではなく「理解を揃えて、次の判断につなげる活動」として扱っているということです。AIが情報やコードを大量に生成できるようになるほど、人同士で何を理解し、どこで合意するのかを意識的に設計することが重要になるのではないでしょうか。

講演資料：「ペアプロの価値は、コードを書くことだけじゃない」（友野敬大）*外部サイト

プロダクト探索・意思決定
― AIにたくさん考えてもらえば、良いアイデアにたどり着けるのか

プロダクト探索では、もっくまさんの「生成AI全盛の時代に、ぼくらはなにをつくるべきか ～生成AIと785kトークン議論して、事業アイデアがボツになるまで～」が印象的でした。

会社やプロダクト、メンバーのスキル、これまでの仮説検証結果など、さまざまなコンテキストを構造化し、複数のAIエージェントと延べ785kトークン※2にわたって議論するという取り組みです。生成AIは多くの案を出し、発散や収束を支援できましたが、最終的には自分たちが「これに賭けたい」と思える事業アイデアには到達できなかったといいます。

重要なのは、ここから「AIは役に立たない」と結論づけていないことです。その後は、仮説を持って人に会いに行く、自分たち自身が当事者になれる領域を探す、といった行動へ切り替えています。

私はこの事例から、AIが既に持っているコンテキストを使って思考を広げることと、新しい事実を外部から得ることは別の活動だと感じました。AIと何十万トークン議論しても、顧客との一度の対話や、実際にプロダクトを使って得られる新しい事実を必ずしも代替できるとは限りません。

プロダクト探索では、アイデアを生成する回数ではなく、「新しい事実を得て、仮説を更新できたか」を見ることが重要です。

講演資料：「生成AI全盛の時代に、ぼくらはなにをつくるべきか ～生成AIと785kトークン議論して、事業アイデアがボツになるまで～」（もっくま）*外部サイト

• ※2 日本語で50〜80万文字程度

フロー・制約・デリバリー
― 一つの工程が速くても、全体が速くなるとは限らない

Ren Edakawaさんの「僅か半年未満で大規模toCサービスの新規開発・リリースを果たして見えてきたアジャイルの成功・失敗と実践知」では、短期間でのサービス開発の中で発生した問題と改善が紹介されました。

当初はアプリ、BFF（Backend For Frontend）、コンテンツ基盤といったチームが縦割りになっており、チーム間のコミュニケーション不足からAPIの修正や手戻りが発生し、スケジュール遅延につながりました。このコミュニケーション構造がシステム構造にも表れた状況をコンウェイの法則と結び付けて振り返っています。

その後、変更可能な開発プロセスへ見直し、チームをまたいだアドホックな相談の場を設け、PO（プロダクトオーナー）に早い段階で動くものを確認してもらうといった改善が行われています。

特に印象に残ったのは、「シフトレフト」を試験の前倒しだけではなく、仕様確認や品質特性、他チームとの調整、POからのフィードバックまで含めて捉えていた点です。

一つのチームや作業工程だけが速くなっても、後工程や他チームに待ち行列ができれば、プロダクト全体としては速くなりません。AIによって実装速度が大きく向上する現在は、なおさら「どこが次の制約になっているのか」を全体で見ていく必要があります。

講演資料：「僅か半年未満で大規模toCサービスの新規開発・リリースを果たして見えてきたアジャイルの成功・失敗と実践知」（Ren Edakawa）*外部サイト

技術的卓越性・品質フィードバック
― AIに任せるためにも、技術的な仕組みが必要になる。

伊尾木将之さんの「変化を抱擁するドキュメントの作り方 - ビジネスルール駆動開発がもたらす、コードとの新しい関係」では、ビジネスルール駆動開発（BRDD）という取り組みが紹介されました。

ドキュメントは人が理解しやすい一方でコードとズレが生じやすく、コードは実際の挙動とズレない一方で「なぜそのようになっているのか」を表現しにくいという問題があります。この講演では、「このビジネスで何が真か」というビジネスルールを適切な抽象度で残し、それをAIが参照して実装し、変更時にはビジネスルールも更新する仕組みを紹介しています。

興味深かったのは、「決めるのは人、書くのはAI」という役割分担です。AIに多くを任せるほど、人がすべてのコードを逐一読むことには限界があります。だからこそ、何を正とするのか、どの段階で矛盾や抜けを検出するのかを、仕組みとして定めておく必要があります。講演では、ビジネスルールを実装前にAIで検証し、コードとルールの対応関係を保つ仕組みまで紹介されていました。

これは、XPが重視してきた自動テスト、継続的インテグレーション、リファクタリングなどにも通じます。これらは人間の開発を効率化するためだけではなく、AIが大量の変更を行う時代には、安全に変更するためのガードレールとして、さらに重要になると感じました。

講演資料：「変化を抱擁するドキュメントの作り方 - ビジネスルール駆動開発がもたらす、コードとの新しい関係」 （伊尾木将之）*外部サイト

組織適応・ガバナンス・計測
― AI活用を「使った量」だけで評価しない

外山大さんの「AI活用の現在地、ちゃんと見えてますか？」では、ビズリーチにおけるAI活用の可視化が紹介されました。

AIのトークンやクレジットといった利用量だけを見るのではなく、Pull Request数、変更行数、リードタイム、障害混入率、手戻り、レビュー負荷などを同じ時間軸で確認し、「AIを使った結果、開発がどう変わったのか」をチームで考えるためのダッシュボードを構築しています。

講演では、FY26 Q2（2025年11月～2026年1月）とFY26 Q4（2026年5～7月）の比較として、マージ済みPull Request数は2.2倍、変更行数は4.1倍に増加し、Pull Requestのリードタイムの中央値は17.31時間から1.41時間に短縮し、障害混入率は0.61%から0.41%に減少した、という数値も示されています。ただし、これらはAIだけによる効果を証明するものではありません。講演でも、速さ・信頼性・経済性を一つだけ最適化せず、数字を現場の問いや実験につなげていくことが重要だと説明されていました。

この点はガバナンスの考え方としても気づきがありました。開発やAI利用を細かなルールや承認で縛るだけではなく、何が起きているのかを観測できる状態を作り、それをもとにチームが振り返って、必要なところに介入できるようにする。AI時代には、そのようなガバナンスがより重要になるのかもしれません。

講演資料：「AI活用の現在地、ちゃんと見えてますか？」（外山大）*外部サイト

XP祭り2026から考えたことを4つの視点で整理

ここまで6つの分類で講演を振り返りましたが、最後にアジャイル、スクラム、XP、AIという4つの視点で整理します。

アジャイル ― 「速く作る」と「機敏である」は同じではない

まずアジャイルの視点では、「速く作ること」と「機敏であること」は同じではない、と改めて感じました。

アジャイルソフトウェア開発宣言には「個人と対話」「顧客との協調」「変化への対応」が掲げられ、その背後の原則では、価値あるソフトウェアの継続的な提供、ビジネス側と開発者の日々の協働、技術的卓越性、定期的な振り返りが示されています。

参考：アジャイルソフトウェア開発宣言 *外部サイト

AIによって実装が速くなったとしても、現実から学び、必要に応じて方向を変えるまでが速くならなければ、それだけでアジャイル（機敏な状態）になったとは言えません。

今回の多くの講演に共通していたのは、単純な「作業速度」ではなく、現実とのギャップに気づくまでの時間を短くすることだったように思います。

スクラム ― AI時代だからこそ、スクラムの「外側」が重要になる

スクラムの視点では、AIによってスクラムが不要になるというよりも、スクラムが意図的に規定していない部分をどう補うかが、より重要になったと考えています。

スクラムガイドは、スクラムを「意図的に不完全」なフレームワークとし、その中でさまざまなプロセス、技法、手法を利用できるとしています。また、スクラムは経験主義に基づき、透明性・検査・適応によって複雑な問題に対応するものです。

参考：スクラムガイド *外部サイト

つまり、スクラムが示しているのはチームが学習・適応するための大きな枠組みであり、その中でどのように設計し、テストし、コードを書き、品質を確かめるかまでを細かく規定しているわけではありません。

スプリントという大きなフィードバックループの中に、XPのTDD（テスト駆動開発）、CI（継続的インテグレーション）、ペアプログラミング、小さな変更といった、さまざまな単位のフィードバックをどう組み込むか。AI時代には、その組み合わせがより重要になると考えます。

XP ― プラクティスではなく、その目的に立ち戻る

XPの視点では、価値・原則・プラクティスの関係に立ち戻る必要があります。

XP祭りのオープニングでは、XPを以下のように紹介していました。

• 価値がプラクティスに目的を与え、原則が価値とプラクティスの隔たりを埋めるもの
• プラクティスだけでは活動そのものが目的になってしまう場合がある
• XPは技術だけを対象にするのではなく、役に立たない技術的・社会的な習慣を捨て、機能する新しい習慣へ変えていく「社会的な変革」という側面も持っている

プラクティスだけを残せば活動そのものが目的になり、逆に新しい技術が登場したからといってプラクティスだけを捨てれば、そのプラクティスが担っていた価値まで失う可能性があります。

今回のペアプロに関する講演は、そのことをとても分かりやすく示していました。AIがコードを書くならペアプロをやめる、という単純な話ではなく、ペアプロが担っていた「会話」「理解」「判断」「学習」という役割を見つけ直し、必要な部分へ再配置するという考え方です。

AI ― 制約をなくすのではなく、制約の場所を動かす

そしてAIの視点です。今回の講演群から私が感じたのは、AIが開発者を単純に置き換えるのではなく、「制約の場所を動かす」ということです。

コード生成が速くなれば、次はレビューや理解が制約になります。そこを改善すれば、今度は価値検証や意思決定が制約になるかもしれません。さらにAIが自律的に開発ループを回すようになれば、人は何を観測し、どこで介入し、どのような場合に止めるべきかを考える必要があります。

AIによって生成能力が上がること自体は大きな変化です。しかし、プロダクト開発全体から見れば、その能力は一つの工程を大きく高速化したとも捉えられます。重要なのは、その結果として次にどこが詰まったのかを観測し、そこへ新しいフィードバックの仕組みを作ることではないでしょうか。

おわりに

今回のXP祭り2026を私なりに一言でまとめるなら、
「AIによる生成能力の増大によって移動した制約を見つけ、そこにフィードバックの仕組みを再配置する」
ことが、これからのアジャイル開発に必要になる、ということです。

これまで私は、アジャイルの「形」をなぞるのではなく、その背景にある価値や原則を理解することの重要性を何度か取り上げてきました。今回のXP祭りでは、AIという大きな変化を通して、その考えを別の角度から再確認することができました。

技術が変われば、私たちのプラクティスも変わっていきます。しかし、現実を早く知ること、顧客やチームと対話すること、小さく試して学ぶこと、技術的卓越性によって変更しやすい状態を保つこと。こうしたアジャイルやXPが長く大切にしてきた考え方は、AI時代だからといって不要になるわけではありません。

むしろ、「なぜこのプラクティスを行うのか」「今のボトルネックはどこにあるのか」「より早く適切なフィードバックを得るには何を変えるべきか」を、これまで以上に問い続ける必要がある時代になったのではないでしょうか。

XP祭りは日本XPユーザーグループ（XPJUG）が主催しているイベントです。