デブサミ夏2026のセッションで学んだこと
はじめに
2026年7月16日・17日に Developers Summit 2026 Summer に参加しました。
私はスピーカーとして登壇しました発表スライドはこちらが、セッションもたくさん聴いたので、それらのセッションの中で特に学びになったものをまとめます。
タイムテーブルは以下です。
https://event.shoeisha.jp/devsumi/20260716/timetable
石垣 雅人さん [DMM.com]
テーマ：誤解だらけの開発生産性～DMM.comで見てきた誤解～
発表スライド：https://speakerdeck.com/i35_267/myths-and-misconceptions-about-developer-productivity
概要
開発生産性は数値で測りづらく、誤解だらけである、という前提のもと、以下のような重圧とその乗り越え方が紹介されました。
-
すぐに改善して！と言われる重圧
よくわからない開発生産性という曖昧な言葉で現場が崩壊しやすい。外発的動機はアンチパターン。内部品質にこだわることは速さの敵ではなく、損益分岐点は1ヶ月程度という話もありました。 -
測れない生産性を求められる重圧
技術的負債の影響がわからないと困る。測れる数字＝正しい生産性とは限らない。測るのが難しい指標にこそ課題がある。計画工数に比べて実績工数が増えるのは負債の影響であり、理解が追いつかないと負債は加速する＝認知的負債（AIで開発していくと増える傾向）という指摘がありました。 -
重圧から生み出される小手先の指標
指標が目標化し、本質的価値から乖離する。グッドハートの法則、キャンベルの法則。人は見えるものを優先的に処理する傾向がある、という話がありました。 -
開発者だけが開発生産性を考える重圧からの脱却
ビジネスサイドと開発サイドで、開発生産性はレイヤーごとに意味が違う。工数入力してどのプロジェクトにどれくらいかかっているのかを計測・分析している。開発者だけでなく、PdMやデザイナーや運営職も含めて考えるべき、という話がありました。 -
標準化を求められる重圧
プロダクトごとに事情がぜんぜん違うので、あまり標準化しない方がいい、という考え。チーム間の相対評価は意味がない、という話もありました。
所感
ビジネスサイドと開発サイドで、開発生産性に対する解釈が違う。この生産性という言葉は、レイヤーごとに意味が違うので、それを理解した上でコミュニケーションすることが大事、というのは大きな学びでした。
プロダクトごとに事情がぜんぜん違うので、あまり標準化しない方がいい、という話にも共感しました。
廣井 智一さん [メルカリ]、斉藤 杏奈さん [Notion Labs Japan]
テーマ：メルカリがAI時代にナレッジマネジメントへ投資する理由 - Notion全社導入と開発ナレッジのこれから
所感
AI時代のナレッジマネジメントでは、「記録しない」「発見できない」「活用できない」「更新されない」という課題を改善することが大事、という話でした。AIによってナレッジの価値が上がるのは、ナレッジマネジメントの面倒くささがAIで減少するから、という整理です。
Notionを導入した理由として、フローとストックの両方の情報を残しやすいこと、エンジニア以外の人もAI活用しやすいことが挙げられました。推進チームを立ち上げ、「全社でAIとNotion活用を進める」というメッセージを何度も繰り返した、という話もありました。
その効果として、Notionでの情報集約が進み、Notion AIを使っている社員の比率は95%以上。エージェントデー（AIだけを使う1日）を時々設け、全社員で取り組んでいる、という話もありました。
今後のエンジニア像として、守備範囲をどんどん広げ、PdMの領域まで含めて「何を作るのか」「なぜ作るのか」に意見・助言・フィードバックを出せる人が求められる、という話がありました。フロントかバックどちらかではなく、インフラも含めてすべてをやれるフルスタックが求められていく、という話もありました。
今後のキーワードとしてIntentが重要、という話も印象的でした。AIによってドキュメントは簡単に書けるようになった一方で、仕様の結果だけでなく「なぜこういう仕様なのか」という意図や背景を残すことが大事、という話をよくしている、とのことでした。機能を終了させるときは、使わなくなったドキュメントも削除することが重要。AIのコンテキストに無駄なものを渡してしまわないため、ちゃんとドキュメントを削除する、という話もありました。
伊達 拓郎さん [NECソリューションイノベータ]
テーマ：なぜAI活用が進むほど、エンジニアは考えなくなるのか？ ～パイプライン構築で見えた便利さの副作用と、手放してはいけない仕事～
発表スライド：https://www.nec-solutioninnovators.co.jp/career/assets/pdf/DevelopersSummit2026Summer.pdf
概要
RFPからE2EテストまでをGitHub ActionsとClaude CodeのSkillsで一気通貫に回すAI駆動開発パイプラインを構築・運用した経験がベースでした。パイプラインは確かに回っていたが、現場から3つの違和感が出てきた、という話です。
- 伝わる：AIの成果物は技術的には正確でも、お客様が見たいのはクラス名ではなく業務サマリーや業務フロー。読者ごとに書き分ける必要がある。
- 判断：AIが「できない」と言った瞬間に探索が止まる。前提を疑い、人の経験・知見で問い直すことは手放せない。
- やりがい：効率化の結果、「確認だけ」の作業が残り、判断・探索・意思決定が人から奪われていた。
これらは別問題ではなく「深く考えるのをやめていないか」という一つの問いだった、という結論。全自動の流れに人のゲートを設け、AIが担う「正確さ」と人が担う「深く考えること」の分業が、AI時代のエンジニアの仕事になる、という話でした。
最後に「手放してはいけない、3つの仕事」として、次の3点がまとめられていました。
- 相手に伝える：正確さではなく、「伝わったか」を問う
- 結果について考える：答えを疑い、ゴールと背景の「なぜ」を考える
- やりがいのある仕事：判断が戻れば、働く手応えも戻る
AIが賢くなるほど、この3つを手放さないことが人の仕事になる、という締めくくりでした。
所感
AIが進化して確認するだけの作業がとても多くなったが、それが果たして楽しいのか、という問いが印象に残りました。
ここでいうお客様はSIerの文脈での発注元のお客様です。設計書を納品するにあたって、AIでドキュメントは簡単に作れるようになったものの、「なぜこういう設計なのか」が伝わらない、という話がありました。ドキュメントはしっかり書いてあるように見えるのに細かすぎて結局わからない、と言われた——正確でも伝わらない、ということだったので、結局、人に伝わるドキュメントが大事だよねという点は共感しました。
澁井 雄介さん [Snowflake]
テーマ：LLMやAIエージェントをソフトウェアに組み込むプラクティス
発表スライド：https://speakerdeck.com/shibuiwilliam/llmyaaiezientowosohutoueanizu-miip-mupurakuteisu
概要
コーディングエージェントで開発できるようになった一方、LLM/AIエージェントを組み込む共通の実装方針がないと、高品質な一貫性のないコードが量産され、運用負債になる、という問題提起から始まりました。
LLMソフトウェア向けにSOLID原則を読み替え（1プロンプト1責務、eval契約への依存など）、AGENT.md・Harness・Eval・Loopで「作り方の作り方」をエンジニアリングする話が中心でした。不確実性への鉄則として、(1) LLM利用の局所化とスキーマ管理、(2) 最小エージェンシー、(3) 決定論ファースト・LLMロングテール——エントリーポイントは決定論で解き、LLMはエッジケースに寄せていく、という3点が紹介されました。Harnessの目標関数は「信頼可能な変更量」であり、Loop Engineeringでレビュー指摘数や変更失敗率を最適化していく、という話もありました。
所感
AIエージェントで動くけれど信頼できるソフトウェアを作ることが、エンジニアの仕事として大事だ、という話が印象的でした。不確実なAIは局所化して制限するのがセオリー、という考え方にも納得感がありました。ハーネスを改善しながらループを回すことがとても重要だ、という点もわかりました。
稲葉 洋幸さん [セールスフォース・ジャパン]、小田 祥平さん [セールスフォース・ジャパン]
テーマ：AI エージェントに Salesforce と Slack をつないでみたら ～ MCP とスキルで変わる開発のこれから ～
所感
セッションは前半がSalesforceのMCPの話、後半がSlackの話、という二部構成でした。Salesforceのパートはおだしょーさんが担当しており、隙あらば笑いどころを作ろうとする姿勢が素晴らしいな、と思いました。
Salesforceが5月にMCPで接続可能になったことは知らなかったです。無償版とChatGPTのプラグインですぐにMCPに接続できるデモが行われ、びっくりしました。Slackのアプリ作成も、CLIを入れればAIエージェントでできる、という話も驚きでした。サンドボックス環境も用意されていました。
稲垣 剛之さん [ラクス]
テーマ：「早く出す」より「事業に効く」―― 顧客の業務サイクルから逆算する、AI時代の二重ループ開発と「変化の設計者」
発表スライド：https://speakerdeck.com/rakus_dev/devsumi2026
概要
楽楽精算・楽楽明細など複数のBtoB SaaSを展開するラクスにおける、プロセス設計の話でした。AIが実装速度を上げる今、「早く出すこと」自体が目的化しやすいが、toBプロダクトでは顧客の業務サイクルや学習コストを無視した変更は、価値より負荷が大きくなることがある、という問題提起から始まりました。
AIへの考え方として「協働型AI」——人間・ルールベース・AIが役割分担して業務を完遂させる——が紹介されました。経費精算の例では、証憑登録や伝票作成はAI、電帳法適合の格納や承認ルート判定はルールベース、承認・確認は人間が担う、という分担です。
アジャイルとウォーターフォールの二項対立は終わり、正しいプロセスは状況が決める、という整理がありました。「早く出す」を信じて不具合が頻発した事例と、法改正対応をウォーターフォールで貫いて成功した事例が対比され、「不確実性が高い＝アジャイル」とは限らない、という話でした。
顧客の変更負荷×不確実性を軸に、どこを定期リリースで安定化し、どこを小さく実験するかを判断する「二重ループ」が紹介されました。基盤機能は作り込みで不確実性が減る一方、AI機能は出してみないと正解が分からない。同一プロダクト内でも性質の異なるものを同じプロセスで回すと破綻するため、探索ループとデリバリーループを使い分けます。実験から本流に載せる「ゲート」では、精度・コスト・UX評価などの基準で判断し、Feature Flagで撤退できる設計にする、という運用も紹介されました。
リリース頻度は正義ではなく、顧客が受け止められるかが最優先。月末・決算期など業務カレンダーを見てリリースタイミングを決める、という話もありました。AI時代のエンジニアは「作る人」から、どこを探索しどこを安定化するかを決める「変化の設計者」へ——開発プロセスは信じるものではなく、設計するもの、という締めくくりでした。
所感
楽楽精算などの話で、自社のプロダクトとも近い状況が多く、とても参考になるセッションでした。ラクスさんはさまざまなプロダクトを展開し、それぞれクロスセルできるよう連携しているようですが、なかなか難しい、という話もありました。
開発サイクルの話で印象的だったのは、アジャイルで早く出した結果、不具合が多い状態になりそうだった、という体験談です。何でもアジャイルで開発すればいいわけではなく、しっかりウォーターフォールで品質の高いものを作ることも必要、という話はなるほどと思いました。リリースする機能によって、不確定要素の高いもの（例：AIをプロダクトに組み込む機能）はアジャイルで開発途中のものにフィードバックを重ねるサイクルで回し、不確実性の低い機能は品質重視でウォーターフォールで開発する——二種類のサイクルを明確に分けている、というのはとても納得感がありました。
アジャイルでリリース頻度が高ければそれでいいのか、というとそうではなく、お客様の都合を考えて繁忙期を避け、あえて繁忙期の後に送らせてリリースするなど、お客様視点でリリース頻度を決める、という考え方も学びになりました。
AIをプロダクトにリリースするときは、まず一部のユーザーにのみリリースし、ログを確認して精度が大丈夫かどうかを見て、さらに主観評価も含めて分析している、という話は参考になりました。不確実性の高い機能には機能フラグを用いて、うまくいかなければすぐに撤退・クローズできる設計にしていることも、なるほどと思いました。
黒田 樹さん [インディードリクルートテクノロジーズ]
テーマ：開発は速く安くなる。開発量は増える。ボトルネックは移動する。AI時代のエンジニアリング組織論
発表スライド：https://speakerdeck.com/recruitengineers/developerssummit2026summer_kuroda
概要
AIで開発コストが下がり、ROIの成立する境界が下がる。作った後の保守運用のI（Investment）は残る、という話がありました。
開発の全工程からふりかえりまでをぜんぶSkillsにして新人でもできるようにした取り組みや、AIで大きな問題を一発で出そうとして失敗した話なども紹介されました。与えるコンテキストを増やすか減らすかしかレバーはない。フルスタック＋フルプロセスが良く、人による境界が少ない方が効率的、という話もありました。
所感
エンジニアの守備範囲はどんどん増えていくという話が印象的でした。
山中 勇成さん [AbemaTV]
テーマ：10年目を迎えた「ABEMA」がどのように AI 活用を推進して、AI 駆動開発にシフトしているのか
概要
エンジニア版AI番付で、チームがどこまでAI前提のチームにできるかを測る仕組みを導入。推進チームが組織標準を定着させ、組織目標を合意済みなのが重要、という整理でした。毎月アンケートで個人の活用レベルをモニタリングし、PR数1.6倍、変更行数1.8倍、マージ時間-37%といった成果が示されました。
ChatGPT、Gemini、Claude、Cursorを利用。一人当たり月に22,000円（ビジネス側メンバも合わせた金額）。障害対応にBotやMCP活用。変更リスクに応じて、レビュー責任者などの要件を変える取り組みも紹介されました。リファクタリング、テストコード、ログ出力変更、ドキュメント修正はLowとする、1件のApproveで済む、といったルールもありました。成果は測定して初めて語れる、という話もありました。
所感
やはり全社員のAI活用を促進していくためには、それぞれの社員がどのレベルまでAIを活用しているのかを見える化していくことが大事だと思いました。
石田 健太さん [LayerX]、谷村 祐樹さん [LayerX]
テーマ：AIプロダクトの本番変更をどう判断するか：怖いリリースを今日出せる変更に変えるSREの実践
概要
「デプロイできる」と「リリースしてよい」は別物、という整理から始まりました。CIを通過しても、変更内容や品質を保証できなければリリース判断は人の意思決定に委ねられ、そこに4つの不確実性（何が変わるか／検証物＝本番か／状態変更の影響／誰がなぜ承認したか）が潜む、という話でした。
Ai Workforce事業部のSREとして、3つの解決策が紹介されました。
- 変更リスクをトリアージする：AIコードレビューで差分要約・危険度ラベリング、PRチェックリスト化、リリースタグを承認単位に固定。
- システム変更にガードレール：スキーマ差分の可視化、検証環境でのDB変更の先行適用、AIによる影響解説。「絶対安全」ではなく「説明できる」を目指す。
- 証跡を一箇所に残す：判断根拠を後から追えるようにする。
8ヶ月前はGitHub/Slack/Notionに情報が散在し、毎回情報収集から始まっていたが、仕組み化によって「何が変わるか」が一目でわかるようになった、というBefore/Afterも示されていました。
所感
すべてのプルリクをマージし終えてデプロイ可能になった状態で「さあリリースするぞ」となったとき、変更内容がたくさんあって本当にリリースして大丈夫なのか怖くなることはないか、という質問に、会場の多くが「怖いと思ったことがある」と答えていました。私も怖いと思ったことはあります。
それをどう解決したかという話が印象的でした。どんな変更があるのかをしっかり見える化し、リスクのない変更とリスクのある変更を分ける。リスクのない変更は基本的にあまり見なくていいので畳んで表示し、どうしても見たければ見れるようにする。リスクのある危ない変更だけを目立たせて、その変更が大丈夫かというところだけを人が判断する、という仕組みです。
DBの変更についても、何が変わるのかを説明できるようにすることがポイントでした。DBの変更で怖いのは、何がどう変わるのかが説明できなくて怖い、ということだったので、それをわかるようにした、という話でした。
今回のセッションでは、変更内容を説明できるようにして自信を持ってリリースできるようにしようと取り組んだ結果、結果的にリリースが早くできるようになった、という話はとても学びになりました。
蜂須賀 大貴さん [Newbee]
テーマ：エンジニアに求められる"プロダクト全域"への越境――市場・予算・マーケ・法務まで「決める」と「任せる」を使い分ける技術
概要
AIで作れる人は増えたが、価値のあるものを作れる人は増えていない、という問題提起から始まりました。高速につくれる時代は高速にゴミを生む時代でもあり、MVPに価値を感じない顧客はブラッシュアップを待ってくれない、という話です。
差別化は「作る技術」から「意思決定の質」へ移っている。勝てるプロダクトは勝てる市場選びから始まる、という整理のもと、エンジニアの越境について語られました。
- 越境1.0：専門領域を前提に外へ広げる（営業もプロトタイプを作る、エンジニアも営業をする、など）。
- 越境2.0：得意な領域の外側も自分の仕事とする。
「ジョブ型」の終焉と総合職の復権、Security/Architecture/Legal/Financeなど専門職との「決める」と「任せる」の使い分け（丸投げ＝責任ごと押し付ける、ではない）がテーマでした。対AIに培ってきたエンジニアリングのスキルを、対顧客・対事業に応用する時が来た、という締めくくりで、著書『勝てるプロダクト開発の教科書』（翔泳社、2026年7月22日発売）の紹介もありました。
所感
これからのエンジニアは「作る」だけではNGで、意思決定の質が高いことが求められる、という話が印象的でした。
仕事の範囲も、エンジニアに限らず様々な職種の人が、プロダクト開発の全体を守備範囲とし、得意な領域が違うだけ、という位置づけになっていくだろう、という話にはなるほどと思いました。
質問として、どうやって組織のエンジニアの仕事の範囲を広げていけばいいのかを聞いてみたところ、急に守備範囲を広げてくださいと言ってもうまくいかないので、納得感を持ってもらうようにするのが大事、という答えでした。例えば1on1などで本人のWillを確認しつつ、納得感を持って守備範囲を広げてもらうように促すことが必要になってくるのかな、と思いました。
まとめ
2日間で多くのセッションを聴きましたが、バラバラに見えても、いくつかのテーマが繰り返し現れていました。
ひとつは、AIで「作る」は速くなっても、人が担う仕事は残るということです。伝わるかを問うこと、答えを疑って深く考えること、判断の手応えを取り戻すこと——伊達さんの「手放してはいけない3つの仕事」に象徴されるように、確認作業だけが増えても、それは人の仕事の代替にはなりません。
もうひとつは、見える化と設計です。ABEMAのAI活用レベルの可視化、LayerXのリリース変更のリスク仕分け、ラクスの二重ループと顧客視点のリリース判断、澁井さんのHarnessとEval——いずれも、不確実なものをそのまま出すのではなく、説明でき、測定でき、必要なら戻せるように仕組みを設計している、という共通点があります。
そして、エンジニアの役割は実装者から**「変化の設計者」**へ広がりつつある、という感覚も強く残りました。何を作るか、なぜ作るか、どこを探索しどこを安定させるか——稲垣さんや蜂須賀さんの話に通じるように、意思決定の質と、守備範囲を広げるときの納得感が、これからますます問われていくのだろうと感じました。
デブサミ夏2026は、AI時代の開発現場が「もっと速く」だけでなく「どう信頼し、どう届け、どう決めるか」を真剣に考えている場でした。自社のプロダクト開発にも持ち帰れる学びがたくさんありました。
X(旧Twitter)でも役立つ情報を発信しますのでフォローしてもらえると嬉しいです → @kojimadev