2026年7月16日・17日、東京・丸の内で開催された Developers Summit 2026 Summer に参加しました。
Developers Summit、通称「デブサミ」は、2003年から毎年開催されている ソフトウェア開発者向けカンファレンスです。長く続いてきたからこそ、 技術の移り変わりを会場の空気ごと感じられる場でもあります。
そして2026年の夏、会場を覆っていたテーマは、ほぼAIでした。
私が選んだ16セッションのうち、タイトルに「AI」を含むものだけで9本。 タイトルに含まれないセッションでも、エンジニアの役割、アジャイル、組織変革、 プロダクト開発、SREといった話題の前提にAIがありました。
デベロッパーとAIは、すでに切り離して考えられません。
「何を作るか」を問い直す。AIの有無にかかわらず、開発の出発点になる問いです。
「AIを使う」話から「AIを回す」話へ
二日間を通じて感じたのは、議論の重心が変わったことです。
少し前まで、生成AIの話題は「どのモデルが賢いか」「コードを何行書けるか」 「プロンプトをどう工夫するか」に寄りがちでした。今回は、そこから先の問いが 多く語られていました。
- AIをどの業務に組み込むのか
- どのデータとコンテキストを渡すのか
- 誰が何を決め、何をAIに任せるのか
- どう評価し、安全に本番へ出すのか
- 速く作るだけでなく、どう事業価値へつなげるのか
「AIがコードを書く時代に、開発者は何を設計すべきか」 というセッション名は、今回のデブサミ全体を象徴していたように思います。 開発者の価値は、実装速度だけでは決まりません。AIを継続的に動かすための 実行基盤、データ、コスト、ガバナンス、そして意思決定を設計することが 重要になります。
AIがコードを書くほど、開発者はコードの外側まで設計しなければならない。 これは矛盾ではなく、自然な役割の移動です。
日本の生成AI活用に足りないのは、ツールより「型」ではないか
率直な感想として、日本の生成AI活用はまだ遅いと感じました。
ただし、ChatGPTやコーディングエージェントを触っている人が少ない、という 意味ではありません。個人の試行はかなり広がっています。遅れていると感じたのは、 生成AIを開発プロセス全体に組み込み、チームで再現できる方法にする段階です。
AI活用が個人技のままだと、成果は使う人の経験とプロンプトに依存します。 うまくいった理由も、失敗した理由も、チャットの中に消えていきます。別の人や 別のAIに引き継げません。本番へ出すときだけ人間の確認が集中し、速く作れたはずの コードがレビュー待ちになります。
必要なのは、優秀なAIを導入したという事実ではありません。次の流れを、 一つのワークフローとして定義することです。
- 何を実現し、なぜ必要なのかを仕様にする
- 仕様を小さなIssueと受け入れ基準へ分ける
- AIが既存の制約と文脈を読んで実装する
- テスト、レビュー、画面、ログで結果を検証する
- 証拠をそろえてリリースを判断する
- 失敗と学びを仕様や運用へ戻す
この一連の流れがなければ、AIの速度は局所最適で終わります。実装だけが速くなり、 意思決定、検証、リリース、学習が次のボトルネックになります。
私が今回「まだ体系だった開発手法が十分に共有されていない」と感じたのは、 この点です。
AIには、コードより先に「意味」を渡す必要がある
当日のNotionメモを読み返して、特に印象に残った例があります。
AIエージェントにデータベースのDDL、つまりテーブルやカラムの構造だけを渡しても、 業務上の意味までは伝わりません。当日のデモでは「顧客LTV」を売上の合計から ユニーク顧客数で割る指標として定義していましたが、この計算ルールは テーブル構造だけからは確定できません。
セマンティックレイヤーは、データの構造と業務の意味の間をつなぎます。指標、 計算式、同義語、テーブル間の関係を明示することで、AIは業務文脈に沿ったSQLを 生成しやすくなります。
これは、ソフトウェア開発でも同じです。
コードだけを渡しても、AIには「なぜこの機能が必要か」「何を壊してはいけないか」 「どの状態を完成と呼ぶか」までは分かりません。AIが必要としているのは、 ファイルの一覧だけではなく、プロダクトと業務の意味です。
仕様は、AIにとってのセマンティックレイヤーだと言えます。
アジャイルは、AIの速度を価値へ変える
今回、AIと並んで多かったのがアジャイルの話題でした。
実装の先で、人とエンジニアの役割そのものが問われていました。
生成AIとアジャイルは、とても相性が良いと考えています。AIは仮説を素早く形にし、 テストや修正の反復を速めます。アジャイルは、その速度を顧客の反応と学習へ つなぎます。
ただし、速く出せばよいわけではありません。
「早く出す」より「事業に効く」 というセッションでは、顧客の業務サイクルや変更負荷を無視したリリースは、 価値より負担を増やすことがあると語られました。AI機能を小さく実験するループと、 基盤を安定して改善するループを分ける「二重ループ」という考え方です。
私なりに言い換えると、AI時代のアジャイルには二つの循環があります。
- 価値を学ぶループ：顧客の課題を捉え、仮説を作り、使われ方から学ぶ
- 信頼を育てるループ：AIに任せる範囲を決め、検証し、証拠に応じて広げる
仕様は、この二つのループを止めるための固定文書ではありません。学びに合わせて 更新される、チームとAIの共通言語です。
AI仕様駆動開発は、信頼を段階的に広げる方法
二日目には、 「Spec-Driven Development は消えたのか？」 という、そのものずばりのセッションもありました。紹介文では、SDDという言葉が 廃れたのではなく、各社のAI開発ツールが実質的に同じ方向へ収束し、当たり前に なりつつあると説明されています。
この方向性には強く共感します。
一方で、現場の実践として「当たり前になった」と言い切るには、まだ距離があります。 仕様を作ることだけでなく、Issue分解、AIへの委任、検証、レビュー、リリース、 知見の還流までを一続きの方法として運用しているチームは、まだ多くありません。
フィールフロウが提唱する AI仕様駆動開発は、そのための開発ワークフローです。
最初からすべてをAIに任せるのではありません。小さく任せ、結果を検証し、 成功条件と失敗条件を残す。証拠が積み上がった範囲から、AIへの委任を広げます。
AIを「チームメイト」にするなら、共有する知識と役割の境界が必要です。
目指しているのは、人間が一行ずつコードを書く状態から、目的、制約、リスク、 顧客価値を判断する側へ移ることです。人間は仕様をAIと一緒に考え、重要な トレードオフを決め、最終的には実際の動きや利用者への価値を確認する。 その間の実装、テスト、レビュー、リリース準備は、信頼できる範囲からAIが担う。
これは「全自動にすればよい」という話ではありません。人間が介入すべき場所を、 作業量ではなく判断の重要度で決め直すという話です。
エンジニアが設計するものは、意思決定の構造になる
トヨタ、SUBARU、日産のアジャイルと組織変革のセッションで、当日のメモに残した 問いがあります。
意思決定の構造を作ることに努力しているのか。
SUBARUの事例では、エンジニアの成長を実行力、構造設計力、意思決定力という 段階で捉え、決める人を現場へ移す「分散」、部門の境界を越える「横断」、 ID・データ・プロセスを標準化する「構造化」が示されていました。
AIが実行を担うほど、この問いは重くなります。
AIに何を任せるか。何をもって完了とするか。どの証拠なら本番へ出せるか。 どの判断は人間が握り、どこは専門家やAIに任せるか。
AIプロダクトのリリース判断 でも、検証結果、差分、承認、状態を証拠としてそろえ、人間が判断しやすい形にする ことが扱われていました。また、クロージングの 「プロダクト全域」への越境 では、市場、予算、マーケティング、法務まで、何を決めて何を任せるかという 判断軸が問われました。
AI時代のエンジニアが設計するのは、コードだけではありません。 意思決定の構造そのものです。
参加したセッション
二日間で参加したセッションは次のとおりです。個別の内容は 公式タイムテーブル で確認できます。
7月16日
- トヨタ・SUBARU・日産が語る、巨大組織を動かす「アジャイル」と「組織変革」のリアル
- AIがコードを書く時代に、開発者は何を設計すべきか
- アジャイルに取り組む東急の内製開発
- AI Agent は“データの意味”を理解できるか？
- AI時代こそ、スケールしないことをしよう
- AI エージェントに Salesforce と Slack をつないでみたら
- 「早く出す」より「事業に効く」
- 紙とExcelからの脱却！ドメイン知識ゼロから始めた社内SaaS開発の舞台裏
- AI時代のSIerはどこへ向かうのか？
7月17日
- 我々はどう生きるか
- Spec-Driven Development は消えたのか？
- AIエージェントは「チームメイト」になれるか
- エンジニアに、お客様の声の「先」は見えているか？
- 一人のエンジニアから始める、横の影響力のつくり方
- AIプロダクトの本番変更をどう判断するか
- エンジニアに求められる“プロダクト全域”への越境
技術だけでなく、コミュニティの熱量を直接感じられる二日間でした。
まとめ
2026年のデブサミは、AIが特別なテーマではなく、ソフトウェア開発の前提に なったことを強く感じる場でした。
同時に、AIを導入することと、AIで開発を変えることは別だとも感じました。
モデルやツールは急速に進化します。しかし、目的を仕様にし、仕事を分け、 結果を検証し、判断の証拠を残し、学びを次へ戻す流れは、ツールが変わっても 残ります。
生成AIは、アジャイルの反復速度をさらに上げます。アジャイルは、AIの速度を 顧客価値へ向けます。そしてAI仕様駆動開発は、その循環をチームで再現し、 AIへの信頼を段階的に広げるための型になります。
今回の参加を通じて、フィールフロウがこの方法論を提唱し、実践知として 広げていく意味を、あらためて確信しました。