なぜ、AIで生産性があがっていると錯覚してしまうのか？
広木 大地さん(レクター)
https://hirokidaichi.github.io/presentation/devsummit.html
- AIコーディングでの生産性
- 期待と現実のギャップ
- 10倍くらいになってほしい
- あって2,3倍程度で頭打ち
- 場合によっては遅くなる
- 体感と価値のギャップ
- 体感の速さは価値の増加を意味しない
- 本質的複雑性と偶有的複雑性
- 前者はAIでも高速化は難しい
- ソフトウェアの本質的な複雑さ
- 複雑性/同調整/可変性/不可視性
- アムダールの法則
- 並列できない部分が全体を支配する
- 並列出来るところを高速化しても詰まるところが出てくる
- 本質的複雑性の割合が多いとスピードは頭打ちになる
- AIの仕事は密度をあげる
- 精神負荷の高い仕事ばかりになる
- AIを長時間動かす設計
- AIにいちいち聞かなくていい環境
- コンテキストエンジニアリング
- 本質的複雑性の比率を下げる
- 並列化の上限が上がっていく
- テンプレート化/大域アーキテクチャ
- 認知負荷を下げる設計
- 本質的複雑性の発生源に向き合う
- 課題解決のプロセス自体をAI化
- 暗黙知の形式知化
- 暗黙知をコンテキストに
- 問題の本質を捉えてAIが自律的に動けるように
- AIにいちいち聞かなくていい環境
- 消える生産性
- 空いた時間がどうでもいい仕事に吸収される
- ブルシットジョブの増殖
- ゆとりある労働
- チームの改善が組織に届かない
- AIのマクロ生産性への寄与は小さい
- 価値を軸に仕事を再設計していく
- やめる仕事を決める
- 成果指標を返る
- 学習へ再投資
- 空いた時間がどうでもいい仕事に吸収される
- AI活用は競争のスタートライン
- 競争するのは人と人や企業と企業
- お金を払ってでも人にやってもらいたい価値をうまないといけない
- 差がつくのは使い方
- 速くなってるのは自分たちだけじゃない
- 相対優位が価値を決める
- 学習速度が相対位置を決める
- エンジニアリングの本質
- AIがhowをやるほど人はwhatとwhyに集中する
- やり方が決まったプログラミングはAIができる
- 道の問題への試行錯誤がエンジニアリング
- 意思決定中心のしごとへ
- 何をなぜ作るのか
- 長期的な判断
- 創造性
- ボトルネックの上流化
- 暗黙知を取り出してAIが扱える形に変換する
- 下流ほどAIで解決したり支援したりしやすい
- 正しさは時代とともに変わる
- 1980-90
- 標準化/マニュアルの時代
- 2000-10
- 可視化/最適化
- 2020-
- できる化(頼む)
- 人がやっていたことを他の人もできるようにすること
- 判断基準の言語化
- 自働化(任せる)
- ワークフローやエージェントで仕組みで回す
- 自分から手離れさせる
- 自創化(指し示す)
- 仮説検証や想像フェーズも自動化
- できる化(頼む)
- 1980-90
- アンラーニング
- タスクは1つずつやる？
- 自分がTODOをこなす側？
- 速くすれば全体が良くなる?
- 5人で半年のプロジェクトというくらいの粒度
- 議論してから作業するという順序？
- 職種ごとの役割の壁
- 5万行のコードは大きいのか？
- レビューは人間がやるものか？
- 1リポジトリ1チーム？
- 1チームは2ピザ？
2万人が「使える」生成AIをどう育てるか？ 〜 損保ジャパン2万人の社員が使う生成AI機能を育てた、プロンプト改善とUX設計の軌跡 〜
小林 勇喜さん(SOMPO Digital Lab)
藤野 智彦さん(SOMPO Digital Lab)
- 現場の業務改善
- ユーザとのやりとりがLINEやメールなど多様で管理が大変
- コミュニケーションの相互プラットフォーム
- 生成AI活用で効率化も
- 開発プロセス
- 1週間単位のスプリント
- ビジネスと開発が一体のチーム
- フィーチャーフラグで安全かつスピーディーに
- AIによる要約機能
- 品質の安定性
- 担当者の感覚に依存してしまう
- コストのジレンマ
- 品質を人が担保しようとするとトータル工数がむしろ上がる
- 品質下限とコスト上限
- 評価の自動化
- 品質の安定性
- ビジネスと開発のコミュニケーション
- 品質の共通認識を持つ
- 許容範囲の合格ラインを合意する
- ワークショップでドメインを再認識
- 開発とテスト
- AIで定量的に評価 a - ビジネスサイドが改善のサイクルを回せるようにGUIからも確認できるように
- プロンプトの改善提案も
AIが書けるからこそ、書かせない ― 少人数内製チームが、AI駆動開発で大規模なレガシー刷新に立ち向かう現実解
巣籠 悠輔さん(マルイユナイト)
https://speakerdeck.com/0101unite/2026-dot-2-20-developers-summit-2026-deng-tan-zi-liao
- マルイグループのエンジニア組織
- 20年物のシステムを内製化
- EPOSカードが収益のメイン
- 会員80万人
- エンジニアは10人いない
- 少人数のエンジニアチームでの開発
- エンジニアチームがボトルネックにならないように
- エンジニア以外でも内製出来る仕組み
- Studio
- microCMS
- AI駆動開発で人間が何をするか
- 理解/設計/実装のステップをAIは一気にやる
- それらを紐解いてレビューしないといけない
- コードの量というより理解/判断する量が増えているのが課題
- 3段のフェーズをまたいだ作業をいっぺんにさせない工夫
- ドキュメント用意してフェーズごとに作業させる
- Claudeのskillsで
- フェーズを分けることでアウトプットの質をコントロールできてきた
- 制約をつけることでクオリティを安定させる-
- 制約がないと独自の判断解釈で実装してしまう
- 決定論的に近づける
- フェーズの分離
- 問を1つにする
- 理解：どういう現状？
- 設計：どう変える？
- 実装：どう作る？
- やっていいことやってはいけないこと
- 実装フェーズではAIはただの作業者
- うまくやると設計フェーズだけ人が判断すればいいという状態を作れる
- 問を1つにする
- AIへの期待
- 賢さではない
- 制約下での再現性
2026年のAIエージェント構築はどうなる？
御田 稔さん(KDDIアジャイル開発センター)
https://speakerdeck.com/minorun365/2026nian-noaiezientogou-zhu-hadounaru
- 2025年はAIエージェント利用の元年
- コーディング以外へのエージェント活用はまだそんなに
- AIエージェントでパワポ作ったりM365にアクセスして操作したりなどいろいろできる
- AIエージェントの作り方
- フレームワークが充実してきた
- LangGraph
- mastra
- Strands Agents
- インフラ戦隊は簡単ではない
- ストリーミング
- 時間のかかる非同期処理
- 認証認可
- お金かけたくない
- AWSのAgentCoreが便利
- 作ったエージェントをAPI化してコンテナでデプロイすればいい
- フロントエンドはどうするか
- streamlit
- Amplify Gen2
- インフラ
- IaCはどんな状況でも必須
- コードになればAIが扱える
- 型ができればアレンジも量産もできる
- フレームワークが充実してきた
- コスト削減
- アプリはサーバーレスで作れるからかからない
- ほとんどはLLMの費用
- 工夫
- 品質を保てるギリギリのモデルの見極め
- プロンプトキャッシュ
- 会話履歴のトリミング/要約
- マルチエージェントは不要なことが多い
- アプリはサーバーレスで作れるからかからない
「触らないとわからない」を武器にする──AI時代のエンジニアが獲得すべき肌感覚と、没頭できる時間の確保
檀野 隆一さん(トヨタコネクティッド)
- 組織への生成AIの導入
- 使える環境ができても浸透には思ったより時間がかかる
- 自分は使ってるのに周りは使えない状況
- 個人差がある
- 便利だと分かってもらう
- 本人の特性
- ポジティブ - ネガティブ
- 手を動かす - 様子を見る
- 活用してもらうために
- 慣らし運転
- 業務の中で使っていく
- 答えがあるものからはいるといい
- OJT&レビュー
- 曖昧なところをさわって試してみる
- 自分のやり方がいいやり方かフィードバックしてもらう
- ストレッチしたゴール
- これは出来ないだろうというギリギリをやってみる
- どこまでできて何ができないか知る
- 思った以上にできるかもしれない
- どこまでできるか知ってるとモデルのアップデートで評価しやすい
- 慣らし運転
- 肌感覚を3つの観点で
- 自分の実力がそのまま跳ね返ってくる
- 周辺領域への拡大はできそうで難しい
- 万能感と無能感
- どれくらい信頼するか
- 人間の方が間違ってるケースが増えてくる
- 絶対AIがおかしいと思っても一回試してみるといい
- それはすごいですねを真に受けない
- 批評的な目線でというと辛辣になる
- 運用/継続の視点
- クラウド型はダウンする前提で
- モデルのサービス終了
- 代わりの新しいのが日本リージョンにないとかも
- 作り込みすぎない設計を
- 開発中にモデルが変わることは当たり前
- なおすコストと乗り換えるコストの天秤
- 自分の実力がそのまま跳ね返ってくる
- 学ぶにあたって
- ソフトウェアエンジニアだからってだれてもすぐに適応できるわけではない
- 人による
- MLの領域だから性質は違う
- すぐに成果がでるという誤解
- 学習というより適応
- 失敗じゃなくて投資
- プロジェクトで慣れる時間を確保
- 期間を人がやる時と同じだけとってダメだったら人力の選択を
- ソフトウェアエンジニアだからってだれてもすぐに適応できるわけではない
HTTP最前線
奥 一穂さん(ファストリー)
- HTTP
- バージョン固有なもの
- どのバージョンでもあるもの
- Semantics
- HHTPメソッドとかステータスコードとか
- ほとんどがSemantics
- プロキシはSemanticsレイヤで動作
- 1で来ようが2で来ようが受け取って任意のバージョンで返す
- HTTPバージョンはhop by hop
- Semanticsじゃないやつはこれ
- ほとんどのヘッダーはend to end
- Semanticsなやつはこれ
- HTTP Semantics
- HTTPバージョンに依存しない機能
- end to endで使える
- これだけでアプリケーションを作れば互換性があって安心
- Incremental HTTP
- リクエストやレスポンスを徐々に送信したいケース
- HTTPの上でそれをやる機能
- 他だとServer-sent EventsとかgRPCとか
- HTTPでサポートするべきものなのかという話はある
- 現在の状況だとうまく動かないことが多い
- 6本までしか同時に繋がらないからそれ以降は待たされる
- Incrementalヘッダをつけることができる
- 6本使ってたらエラー返してくれる
- デバッグで原因が分かるようになる
- RFC発行しようとしてるところ
- PTTH
- 現在はクライアント - CDN - ロードバランサー - HTTPサーバ
- PTTHだとクライアント - CDN - HTTPサーバ
- CDNで優先度に基づいた順序入れ替えが可能になる
- 2025/7にカバーするユースケースを議論
- どこのWGで標準化するか
- QMax
- Semanticsの下が複雑
- 3つのプロトコル
- 2つのTCP
- HTTP3 -> QUIC -> UDPとHTTP2 -> TCP両方を対応し続けないといけない
- TLSとQUICのAPIが違うのが原因
- TLSの上にQMうｘｔおいう層を設けてAPIの互換性をもたせる
- Semanticsの下が複雑
- SCONE
- Standard Communication with Network Elements
- エンドポイントとネットワーク機器が強調して帯域利用を最適化
- QUICの特殊なバージョンのパケット
- ネットワーク帯域の大半は動画配信が占めている
- 動画のフローをIPとかSNIで検出してスロットリング
- 誤判定が多い
- 無線電波の利用効率が低い
- Standard Communication with Network Elements
- Rapid Start
とっても大きく育ったプロダクトを整頓しよう ～ モジュラーモノリスへ向けた段階的アプローチ方法～
深見 高志さん(楽天カード)
- 楽天カード
- サービスが増大
- リファクタリングも困難
- 属人化した知識
- 改修が入った機能と別のところで不具合が置きたり
- 大きなモノリスを分割したい
- マイクロサービス化できるほど整ってない
- モジュラーモノリス
- 大きなモノリスをモノリスの中で整理していく
- マイクロサービスを見据えた途中のステップ
- モジュラーモノリス化に向けて
- 単体テストを拡充してリファクタリング出来るように
- 入口からDBまでつないだテスト
- ベストケースと名付けた流れを網羅的に
- Step by Stepで泥臭く仕様を読み解きながら
- 正しい置き場に移動して業務知識の境界線
- Presentation/Application/Infraなど
- さらにそれを業務ごとに区切る
- 境界をまたいだ呼び出しをなくしていく
- 境界からのアクセスを受け取る場所を一箇所に
- マイクロサービス化も見据えて
- DDDの文脈でドメイン集約
- 機械的にできるところから整理
- ValueObjectを作っていく
- 機能を1つのモジュールにまとめる
- プロキシ的なAPI層にもロジックがあった
- ビジネスロジックの層に移動していく
- APIの受け口も統合してしまう
- 単体テストを拡充してリファクタリング出来るように
