はじめに
「カミナシ レポート」を開発しているかわりくです！ 日本最大級のテックカンファレンス、Developers Summitに初参加してきました。 2日目のセッションの感想や持ち帰れそうなことをメモっております。
会場の雰囲気は、デデデデカイ！規模がデカい！今まで参加したどのカンファレンスよりも人の数と会場のキャパシティと、ブースの数が桁違い...！スタッフさんも多い...!ありがとうスタッフさん...! タダでサンドイッチもらってごめんなさい...!スタッフさんの分まで楽しみます！ 興奮しながらの入場となりました。
（2026/2/19終了後、最速レポとして投稿されたものです。）
セッションレポート
LLM利用率80%への道筋：ピクシブが実践した「People・Process・Technology」三位一体の変革とは？
登壇者: bash（ピクシブ） 川口 修平（GitLab） セッション詳細
ざっくりまとめ
ピクシブさんが自社の開発者向けにLLMの利用を推進していく中で、組織にどんな変化が起きたか？という話。Technology、Process、Peopleの3つの要素が相互に変化を起こし続けるのがポイント。
- (Technology)開発プロセスをツールチェーンで構築するのではなく、AIによる開発支援の強力なパイプラインを持つプラットフォーム(GitLab)を採用。ツールの選定やアップデート、チーム間の知見共有のコストをごっそり削減した。
- (Technology)リリース前にセキュリティ診断を「一方通行で」やるんじゃなくて、GitLabの基盤で常にセキュリティ診断が回り続ける仕組み（DevSecOps）を作った。
- (Process)開発プロセスに対する健康診断の仕組みでボトルネックを特定する。経営層もAI推進にコミットする。
- (People)開発プロセスの全てを行うWhole Teamとしてチームを設計する。AIをチームメンバーと考えてチーム設計をする。
クローズアップ
- 「エンジニアリングとは、再現可能なプロセスを確立して継続することである。」ピクシブさんの社内Docに書かれた言葉らしい。AIによってエンジニアは不要になる・何を作るか？だけが重要になる。といった言説が増えたが、エンジニアの価値は再現性とそれを持続すること。そう考えると、AIが爆速でコードを書いてくれることと、エンジニアの本質的な価値はバッティングしないどころか、互いに補完しあう存在だと思った。
- 統合開発プラットフォーム（GitLab）に組織横断的なAIパイプラインを敷くことで、ツールや開発プロセスのサイロ化を防ぐ。一方で、コーディングツール（Claude CodeやCodexなど）やハードウェア（PC）といった手足の部分には一定の選択の自由度を残す。全てをトップダウンで強制しない、このバランス設計が良いと思った。
持ち帰り
- 再現性が高く、持続的な仕組みを作る。短期的な再現できない成果"だけ"を求めない。
- 自チームだと、QAフェーズをもっと開発チームが主体的に取り組むことができるはずなので、Whole Teamとして、QAフェーズにもオーナーシップを持って進められる仕組みをつくる。
意志を実装するアーキテクチャモダナイゼーション
ざっくりまとめ
書籍からの引用と、登壇者の考えを交えながら、レガシーシステムをモダナイゼーションするためのhowとマインドセットの話。
- 実装はAIがこなせる時代になったが、組織や事業ドメインを織り込んだアーキテクチャ設計はできない。人が意志を持ってアーキテクチャを設計する。
- AIが進化しても、組織の構造や人間の感情など、人の性質は変化しない。組織（人）と技術が相互作用しながら開発を進めるための技術がこれからも必要。
- コンウェイの法則（システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう）は避けられない。むしろ利用する。そのためにはドメイン境界をうまくモデリングすることが重要。
- 技術的負債は事業課題になる。変化に耐えられないシステムは競合に負ける。
クローズアップ
- ソシオテクニカル。俺たちはコーディングから逃げられたとしても人間からは逃げられない...
- モダナイゼーションは派手な技術選定より、地味な現状把握。説明しやすい嘘より、説明しにくい真実を話す。
- 技術負債は開発者体験やデリバリー速度が低下するだけじゃない...!プロダクトが...会社が終わる...!
持ち帰り
- 技術的負債について議論する時、技術的な課題に閉じずに、組織的な課題をセットで考えます。はい。やります。
- 人と向き合う時を増やす。
- 短期的で派手な成果よりも、地道な本質と向き合う。
2重リクエスト完全攻略HANDBOOK
ざっくりまとめ
フィンテック（2重リクエストが起きたら洒落にならない領域）の開発者が、Webサービスにおける2重リクエストの問題と対策をフロントからバックエンドまで段階的に解説してくれた。
- まずフロントで発生頻度を下げる。submitボタンのdisabled化、PRGパターンでリロード対策。これはやらない理由がない。
- バックエンドではDBのユニーク制約や状態遷移のバリデーションで、仮にリクエストが到達しても不整合なデータを作らせない。
- さらに排他制御（悲観的ロック）やAPIレスポンスキャッシュで、並行リクエストやリトライにも対応する。
- 意図的なリクエストと事故を区別するために、idempotency-keyヘッダという選択肢もある。
クローズアップ
- 技術の概要だけでなく、実例が多く、ユースケースがイメージしやすかった。実例があると取り入れやすい。
- 2重リクエスト対策はめちゃくちゃ手段があって、それぞれのメリデリがあるので、パターンを知っておいて、適切に選択できる必要がある。人が意思を持って選ぶんだ！
持ち帰り
- 自分のプロダクトで2重リクエストが起きたら何が困るか、一度洗い出してみる。プロダクトの性質に合わせて優先度を整理して、なんらか解消してみます。やるゾス。
Claude Codeで実践するスペック駆動開発入門
登壇者：吉田 真吾(ジェネラティブエージェンツ/セクションナイン) セッション詳細
ざっくりまとめ
実践Claude Code入門の 著者によるスペック駆動開発（SDD）の話。仕様書を信頼できる唯一の情報源として、コード生成はAIが行うというアプローチとAI-DLCを比較しながら解説。
- AIエージェントとは、目標に向けて環境と相互作用しながらタスクをこなす知能システム。ツールを実行し続けるループで目標を達成する。
- SDD（Spec-Driven Development）では、spec（要件定義書・実装の設計・タスクリスト）を整備して、AIに実装させる。作業単位で永続的なドキュメントを作ってメンテしていく。
- コーディングスタイルだけでなく、spec駆動のやり方自体もclaude.mdでポリシーとして定義しておく。
- さらにAI-DLC（AI Development Life Cycle）という概念も紹介されていた。（ちょっと時間内だとSDDとAI-DLCの違いが理解しきれなかった...出直してきます）
- 簡素なSDDだと、laude.mdの肥大化によるコンテキスト消費、監査ログが残らない、ユーザーとのやり取りの詳細が不十分、といった課題もある。
クローズアップ
- 「Spec駆動開発は試してみるというフェーズを終えて、当たり前になりつつある」
持ち帰り
- AI-DLCを理解して、開発プロセスに取り入れます。
コードが物理世界を動かす興奮と責任 ～フィジカルAIの最前線でソフトウェアエンジニアは何と戦っているのか～
登壇者：梅田 弾(ティアフォー)、山田 勲(T2) 司会：森崎 修司(名古屋大学) セッション詳細
ざっくりまとめ
自動運転業界がどのようにAI開発をしているのか、というパネルディスカッション。
- 自動運転といっても、センサーやハードだけじゃなく、ソフトウェアもクラウドもめちゃくちゃある。
- ハードウェアの制約（計算資源、電源、センサーのタイムスタンプ同期...）がある中での最適化が必要。泥臭い。
- あらゆるパーツが壊れても安全に動作する冗長なシステム設計が求められる。（人命かかりすぎてる。尊敬します。すごい。）
- 以前は技術導入すると後戻りできなかったが、今はシミュレーション環境が整ってきて、新しい技術もスピーディーに試して導入判断ができるようになった。
クローズアップ
- 「泥臭くやる」を登壇者が何度も強調していたのがカッコ良かった。最先端のAIも、データのタイムスタンプ合わせや電源の接続不良みたいな地味な問題と戦っている。華やかさの裏にある泥臭さ。
- ソフトウェア開発を支えるためのソフトウェア。みたいなものをたくさん開発している。（データ不整合に気づく仕組みなど）
持ち帰り
- webシステムの開発でも「ソフトウェアのためのソフトウェア」（データ品質の自動検出、開発プロセスの自動化）という発想はもっと取り入れられるはず。開発を支える仕組みに投資する意識を持つ。
おわりに
day2はサミットの熱量を最速で届けるレポートでしたが、day2,3の通しのレポートは日を改めて公開いたしますので、そちらもチェックお願いします！
弊チーム積極採用しております！来年はご一緒にデブサミいきましょう！
