「東急URBAN HACKSのデザイナーの現在地 〜Designer Night #2〜」に参加してきました

URBAN HACKSの紹介

宮澤秀右さん

  • URBAN HACKSは5周年
  • 東急は1922年創業
  • 4つの事業
    • 交通
    • 不動産
    • 生活サービス
    • ホテル/リゾート
  • 東急のサービス
    • リアルのサービスが強い
    • リアルとデジタルの融合へ

企業サイトを毎日楽しむ情報プラットフォームへ

押味美由貴さん
森山ひかるさん

  • 東急・東急電鉄サイト
    • 運行情報や沿線の情報
    • 2025/6にリニューアル
  • これまでは企業情報や運行情報が中心
    • 多くのサイトがあってアクセスが分散していた
  • リニューアル
    • 顧客調査コンセプト作成から
    • ペルソナ作ったりプロダクトビジョンボードを作ったり
  • メディア領域
    • 各事業を束ねるハブへ
    • 各駅のまちの情報
    • 子育て支援の事業部と共創でコンテンツ
    • さらなる改善に向けたリサーチ
      • アンケート6000件
      • AIインタビュー66名
  • 電鉄領域
    • 誰もが使うサイト
      • WCAGのAAを目標に
    • やりたいことは多いが誰もが対象になる
      • 認知的ウォークスルー
      • セグメント洗い出し
      • リサーチャーのメンバーも一緒に
      • 分析し事業部の意思決定へ

デジタルに閉じない移動領域のおもしろさ

藤森大樹さん

  • 移動領域
    • 電車/バス
    • 移動した後の目的地
  • 移動の価値を追求する
    • Fun/Smart/Unique
  • サービス
    • 東急線アプリ
    • Q SKIP
  • 体制
    • 東急
      • ビジネスオーナー
      • 現場メンバー
    • URBAN HACKS
      • プロダクトオーナー
      • アカウントマネージャー
      • プロダクトマネージャー
      • デザイナー
      • エンジニア
      • リサーチャー
      • QA
  • Q SKIP
    • 新たな移動の創出
    • 東急線のデジタルチケットサービス
      • お得な乗車券
      • 施設やイベントと連携
      • スマホを持ってれば電車に乗れる
    • デジタルとリアルの両面の難しさ
      • 改札が混んでたら
      • 電波が悪かったら
      • さまざまなイベントの体験をスムーズに
    • サービスデザイナーとして
      • 実際に使って調査
      • QRの物理機器の検証

Shibuya TOQ Pass ここで働けてよかったをどうデザインするか

仙田浩之さん

  • 渋谷で働いている人への優待
    • 不動産事業の中のワーカー向けの施策の一つ
    • 渋谷ヒカリエ/渋谷ストリーム/渋谷スクランブルスクエア
    • クーポンとか
  • 初期は紙のパスからスタート
    • どう使えるか分からない
    • どう使われてるか分からない
    • 2023年にアプリ化
    • 2024年にリニューアル
  • ユーザーを知るところから
    • アンケート
      • 優待はお店選びのきっかけに
    • デプスインタビュー
      • さまざまな属性の人
    • 探す - 選ぶ - 思い出す
      • つまずきポイントを見つける
  • 探しやすく思い出しやすく
    • 施設店舗入居企業との接点
      • クリエイティブを作って掲載してもらったり
      • 自分が行く姿を想像してもらえるように
    • 店の中にいるのにお店を検索しないといけない体験
      • 店舗コードを入れてすぐにたどりつけるように
      • 置いてもらうポップも自分たちで
      • 掲示してもらう案内やマニュアルも
    • 250店舗
      • パワポで雛形作って事業部の人も作れるように
  • ユーザの体験とそれを届ける仕組みまでデザインできる

パネルディスカッション

  • URBAN HACKSの文化
    • 自考自走な組織
  • 事業部との共創
    • お互いの常識を共有しながら進められるように
  • どこまでデザインの上流に関われるか
    • 事業部の課題を相談してもらうところからスタート
    • サービスデザイナーは広くだけどUIUXデザイナーでも案件による
  • URBAN HACKSのデザイナーに共通するところ
    • 思いを持って入社してる人が多い
      • 自分の生活や人生
    • ポジティブな人が多い
      • 失敗を許容する文化
      • それを糧に次に繋げられる人
    • 相手の声を受けて自分を変える覚悟を持っている人

「DevFest Kansai 2026 〜AIと最新技術を一日で総まとめするカンファレンス〜」に参加してきました

面接で人は見抜けるのか? Google 採用改革の舞台裏

及川 卓也さん(Tably株式会社)
小川たかこさん(パナリット株式会社)
湯川洋平さん(Cicero Aware)
川中 真耶さん(ソフトウェアエンジニアリング協会 / 株式会社ナレッジワーク)
石原 直樹さん(GDG Greater Kwansai)

  • 「グーグルのすごい採用」という本がこのパネルディスカッションの背景
  • 2000年代の採用
    • PM
      • 初期のGoogle
      • 4,5ヶ月で面接8回とか10回
      • 多い人は15回とか
    • 人事
      • 入社して初日に席がなかった
      • カオスな時代
    • エンジニア
      • 2日間で1日目にコーディングとか2日目に4回面接
  • 2012年から構造化面接
    • トンチ問題をやめた
      • 入社してからの定着に相関がなくてやめた
    • 学歴を重視するのをやめた
      • これも相関がなかった
      • 卒業してから3年以上たっていると特に
    • Googleが見極める要素
      • カルチャーフィット
    • ホワイトボードでコーディングしてたのをPCで
      • PC操作が記録とられている
    • 面接官によるぶれの解消
      • 構造化面接
      • 設問と評価軸の定義
      • 自由度は減るがフェアになる
      • インタビューする人は情報を集めて判断は採用へ
  • どうやったら内定もらえるのか
    • その会社が求めてるスキル
    • 中の人になった気持ちで考える
      • 同じ部屋で心地よく過ごせる人かどうか見られる
      • 自分も同じ気持ちで
    • 自分が企業を選ぶ
      • 心地よく働けるかどうか
    • 採用担当は多くの人を見ている
      • 全体の分布を相対的に見てしまうことが多い
      • 平均的な人はなんなのか
      • 個性を出すにはどうするといいか
    • ただ答えるだけでなくNoも言える人
      • それを相手をリスペクトして伝えられる

Web UI 2026 Updates & What's Coming!

sakuさん(サイボウズ)
https://sakupi01.github.io/slides/ja/2026_10_18_gdgdevfest_web-ui-updates-whats-coming

  • ベースライン
    • Widely
      • 全ての主要ブラウザでstableになってから30ヶ月
    • Newly
      • 全ての主要ブラウザでstable
    • Limited
      • 少なくとも1つのブラウザでstable
  • リッチなUIにする対応
    • Temporal
      • 新しい日時管理のAPI
      • Date周りのつらみを解消してくれるもの
      • 従来はDayjsとか使うことが多かった
      • イミュータブル
      • タイムゾーンの計算
      • 文字列へのシリアライズ
      • SafariがまだなのでLimited
      • polyfill使いながら段階的にがいい
    • Customizable select
      • セレクトタグはOSやブラウザの見た目に依存していた
      • FormControl系全般に言えること
      • OpenUIでFormControlのカスタマイズについて検討が進んでいる
      • appearance: base-select で自由にカスタムできる
    • OS-level Text Scale
      • OSの文字サイズに合わせてルートのfont-sizeを調整できる
      • remやemを使っていると全体に反映できる
  • レイアウトシステムの変化
    • Grid Lanes
      • Masonryと呼ばれるもの
      • 石積みに並べていくレイアウト
  • プラットフォームの機能でSPA
    • NavigationAPI
      • HistoryAPIの改良以上の機能
      • 遷移をnavigateで一貫して管理
      • interceptで遷移の始まりと終わりを検知できる
      • ブラウザが遷移中という状態を認識できる
      • 戻る進むでのスクロール位置やフォーカスの復元をブラウザがやってくれる
      • historyを自前管理しなくていい
    • Out of Order HTML Streaming
      • HTMLをDOMの順番通りに送らなくてよくなる
      • ストリームで送って後からプレースホルダーをデータに置き換えたりできる
    • CSS Navigation Matching
      • CSSだけでURLの変化に応じた画面の切り替えができる
    • Same document View Transitions
      • 遷移中のアニメーション
      • DOMの更新全部のスナップショットを撮ってくれてアニメーションできる
      • 通常のView Transitionsはページ全体を撮っていた
        • 遷移中の操作を受け取れなかった
      • Scoped View Transitionsで特定要素だけに適用できる
  • エージェントとWeb標準
    • Responsively sized iframe
      • iframeのサイズを親のサイズに応じてレスポンシブにできなかった
        • プライバシーやセキュリティの問題
      • 埋め込む側がサイズを指定してオプトインできるようになった
      • 埋め込む側と埋め込まれる側が相互にOKしていれば適用される
    • WebMCP
      • Imperative API
      • AIエージェント向けにページのセマンティクスを補足する
      • エージェントは画面のDOMを読んで推測しながら操作するがあくまで推測
      • WebMCPを使ってサイトがtoolを用意して説明を伝えることで正しく理解できるようにする
      • descriptionとinputSchema
      • あるべきとしてはこれがなくても伝わる画面を作るべきという思想の機能
  • Modern Web Guidance
    • Webのプラクティスのスキル
    • ベースラインのどの基準で作りたいかとか言うとやってくれたり

Flutterは3Dゲームを作れるのか? Flutter Scene × AIで挑戦

Goldner Lucasさん(株式会社YOUTRUST / Google Developers Expert)

  • Flutter
    • クロスプラットフォームのフレームワーク
    • iOS/Android/Web/MacOS/Windows/Linux
    • 1つのコードベースで全て動く
  • Flutterの仕組み
    • 全部のピクセルを自分で描く
    • DartのWidgetの組み合わせでUIを作る
    • RenderTreeでレイアウトしてペイントする
    • Impellerエンジンで描画
    • GPUにコマンドを送ってる
  • Flutter Scene
    • これまでのFlutterでの3D
      • UnityやWebViewを埋め込む
      • Flameで2D
      • Canvasで自前の3D
    • 最新だとFlutter GPUとFlutterSceneでDartだけで3Dが描けるようになった
    • Flutter Sceneは影とかアニメーションをやってくれる
    • DartからFlutter GPUでGPUを直接叩く
    • 全プラットフォームに対応している
  • 使い方
    • パッケージ追加
    • コマンド実行で生成
    • GPUを有効化
    • アプリケーション実行
  • 3Dを作るためには
    • シーングラフ
      • 形や見た目の定義
      • Flutter Sceneの中にnodeを追加するだけでできる
      • Widgetとして置けばいい
    • 3Dモデル
      • .glb ファイル置いて読み込むだけ
    • カメラ
      • どの角度からどこを見るか
      • Flutter Sceneでカメラの定義が作れる
    • ライトや影
      • これもFlutter Sceneで定義できる
      • どこから光が出るか
    • 3Dモデルの動き
      • glTFに入ってるアニメーションをそのまま呼べる
    • タップの判定
      • どの位置のカメラから見てるかで同じ地点をタップした場合に同じであると処理するのが大変
      • ライブラリを使うと楽にできる

AIでコードは書けるのに、つくりたいものがつくれないあなたへ

蜂須賀 大貴さん(Newbee株式会社)
https://www.docswell.com/s/PassionateHachi/KN73NR-2026-10-18-161120

  • ソフトウェアは書けてるけどプロダクトになってない
  • 機能の積み重ねではなく体験を考える
    • 誰のどの場面をどう変えるのか
    • 自分の行動体験 - 必要な要素を洗い出す - 実現方法を具体化 - UXとして一連の体験にする
    • 操作の流れと利用条件を踏まえて考えていく
  • 欲しいを必要条件へ
    • 要望:欲しい機能
    • 要求:実現したい変化
    • 要件:満たすべき条件
  • PRD
    • 目的と必要な条件や完成の条件を書く
    • どういう状況で使うもの
    • スコープに入れないもの
    • 予算やビジネスとして成り立たせるための仕組み
    • 背景も入っていればAIも想像して必要なものを考えられる
  • 条件を確かめられる言葉に
    • 何ができたらできたと言えるかを言語化できること
    • 受け入れ条件
    • 制約
    • 未確定事項
  • AIに判断してもらえる余地を定めておく
    • 変えて良いところと守るべきところを定義しておく

AIが賢くなるほど、UIは不親切であるべき―Cognitive Surrenderを防ぐ UXデザイン

安藤 幸央さん(株式会社エクサ)
https://drive.google.com/file/d/1awn3EX1w851yeuvCYAG3nO21hcB8E0lj/view

  • Friction(摩擦)
    • これまでのUIはフリクションを除去してきた
      • 迷わせない待たせない
      • クリックさせない覚えさせない
  • AI時代はスムーズなだけでは満足できない
    • 従来
      • 機能を知る - 目的 - 考える - 実行 - 結果
    • AI時代は
      • 目的 - AI - 結果
    • 考える過程がなくなっている
  • 自動運転
    • Waymo
      • 完全自動運転
      • 人間は何の判断も不要
      • テスト済みの地域でしか今は動いてない
    • Tesla
      • 自動運転のモードがある
      • 人間は運転席にいないとダメ
      • 人間が運転しないといけない場面もある
      • 必要な判断は人間がする
  • Cognitive Surrender(思考の放棄)
    • AIが言ってることを正しいだろうと自分の判断として採用してしまう
    • AIチャットは重要なこともそうでないことも同じ聞き方で許可を求めてくる
    • 判断が明け渡される瞬間
      • 最初の結論が判断基準に
      • 他の選択肢と比較しなくなる
      • 理由を持たずに確定してしまう
    • ファスト&スロー
      • System1:直感
      • System2:熟考
      • System3:AIと考える
    • AIが正しければ人は拡張され誤ると人も通常よりも誤るという調査
  • AIの使い分け
    • 全部AI
      • Waymoのように条件が整えば全部任せられる
    • 人が方向を決める
      • Teslaのように判断と責任は人がやる
    • AIは考える材料を出す
      • 人が主体で比較検証する
  • human in the loop
    • 人間がループの中に入って判断をする
    • 承認を押すことと判断することは違う
    • 思考と判断はそのループに入っているのか
    • 判断するために必要なこと
      • 考える
        • 立ち止まって確かめる
      • 根拠と反証
        • AIの結論を検証
      • 比較する選択肢
        • 別案と比較する
      • 拒否と修正権
        • Noと言って止められる
  • 思考放棄を避けるために必要なパターン
    • AIより先に自分で判断
    • 重要な操作だけ立ち止まる
    • 重要な選択は未選択で始める
    • 最適解より比較可能な選択肢を
    • AIにあえて反論させる
    • 結論の前提を問い直す
    • 不確実性を隠さない
    • 要約の背後の一次情報を確認
    • AIに渡す権限は段階的に
    • それでいいかではなく何が起きるかを問う
    • 失敗を戻せる設計
    • 判断の後になぜそうしたかの学びを残す
  • どこでどれだけ摩擦を残すか
    • なくす
    • 気付きを与える
    • 判断を促す
    • 意図的に止める
    • リスクの大きさでどのレベルにするか決める
      • 思考の引っ掛かりと操作の摩擦の2軸

デジタルネイチャーと人間の再定義——AI時代の「共創」を問い直す

落合 陽一さん(筑波大学 / 東京大学)

  • 理由はわからないけど使えるものが増えていっている
    • 自然化
    • 人工物がバイオマスの量を超える
  • 従来の制作は人間中心
    • 素材は人間の外側
    • 人間が生成していく
    • 道具を補助して作っていく
  • 計算機自然における制作は脱人間中心
    • 環境側から新しいものが作り出されて人間がフィードバック
    • そういった時代に人はどういった道具で選ぶのか
    • どういうコスト曲線を描くのか
  • 自然の変化の速度の変化
    • 自然の進化は低速
    • 科学は自然を追いかけることができた
    • 計算機が満ち溢れて自然が変化する
    • 理由はわからないけど何故か使えるという状態へ
  • デジタルネイチャー
    • パラダイムシフト
      • 人間中心から計算機自然中心
    • 物質と情報の融合
      • 計算機能力の肥大化による区別不可視に
    • 重要な視点思想
      • 映像から物質へ
  • 技術革命とライフサイクル
    • AIは今どこにいるか
    • あと数年で突き抜けるタイミングが来る
    • 道具が自然化していく
      • 道具が見えなくなってくるし作ってる人も見えなくなってくる
    • 自然の側から道具が出てくるようになる
    • 道具 - 助手 - 相棒 - 環境
  • 考える文明の限界
    • 著作者と所有者と責任の境界が揺らいでる
    • 主体と対象が分離されなくなってくる
    • 味わいは思考の媒体であり余韻
    • 人間同士の問題であれば味わいは重要

コードはエージェントに任せて、「プロダクトエンジニアリング」はチームで磨き続ける

nagaさん(GDG Tokyo / 株式会社MIXI)

  • AndroidアプリのEdge to Edge対応
    • 全部で350画面
    • AIにガイドラインを渡して90%対応
    • ガイドラインには実装パターンやよくある問題と参考プルリクを書いた
  • 対応の流れ
    • ガイドラインを渡す
    • AIが計画を書く
    • 人が検証
  • 実機特有の動作
    • 実機での操作は人間が担当
    • キーボードの操作など
  • プロダクトエンジニアリング
    • 決める - 作る - 運用する - 測る - 改善する
    • これらをAIエージェントに任せたい
  • 初期の対応
    • ドキュメントを人間が整えて実装をAIに任せる
    • できたものの確認は人間がやる
    • この段階ではコーディングをやらせてるだけ
    • 決めるフェーズと確かめるフェーズも任せたい
  • 施策検討
    • AIペルソナの活用
    • UXリサーチチームがインタビュー結果をもとに作成している
    • エージェントに聞くとペルソナとして回答をくれる
  • 事後分析
    • ABテストの結果を分析するスキルを作った

生成AIを「なんとなく改善」するのをやめる

太田 満久さん(ユビー株式会社 Ubie Lab)
https://docs.google.com/presentation/d/e/2PACX-1vRy3_5RLR-4AvX9_F8qwj9-qp3HKgCEBcN6fdxlM6ZhMCS2twBE8qvXRiBPWG-Sou_8GcvB6Gq5CYsT/pub

古い指輪から広がった,Javaコミュニティとのつながり

山﨑 大介さん(筑波大学)
https://speakerdeck.com/yamad/furui-yubiwa-kara-hirogata-java-komyuniti-tono-tsunagari

「AIでWeb制作はどこまで変わる?|電DE電LAB. #5 SPECIAL」に参加してきました

AIでWebデザインはどこまでつくれる?

ロックオン柳田さん(合同会社ホームランオフィス)

  • AIに作らせるための事前準備
    • デザインルール
      • カラーパレット
      • 文字のスタイル
  • イラストの配色
    • イラストの色がデザインルールに合わないことがある
      • 色の調整を手動でやるのは面倒
      • イラレで扱いたい
  • 画像の切り抜き
    • フォトショで背景削除したら残したいものも消えちゃう
    • 周辺の残したいものも簡単に切り抜きたい
  • AIの活用
    • デザインアプリに搭載されたAIに頼む
    • 生成AIアプリからデザインアプリを操作する
  • イラストの配色を揃える作業比較
    • イラレbetaのAIでは全然変化なし
    • Codex経由でやったらいい感じになった
  • 画像の背景透過の作業比較
    • フォトショbetaのAIではいい感じだけど細かいところがうまくできてない
      • 人が調整できるようにマスクを残してくれたりはする
    • Codex経由だと全然うまくいかない
      • 編集可能なpsdは用意してくれる
    • ChatGPTにやらせると上手く切り取れるが画像サイズが小さくなる
      • フォトショのスケールアップと組み合わせる
  • Figmaでテキストからデザインを作る
    • いい感じにやってはくれる
    • ただしやるたびに全然違うものが出てくる

Adobe Fireflyボードで変わる、アイデア探索とWeb制作の入口(仮)

岩本 崇さん(アドビ株式会社)

  • Adobe Firefly
    • デザインのAIツール
  • 他製品との違い
    • 安全な商用利用
    • ワークフローの統合
  • パートナーモデル
    • OpenAIなど他社のモデルも使える
    • 生成クレジットで利用量を管理
  • Fireflyボード
    • Figmaみたいなあれこれ配置できるボード
    • プロンプトが打てるようになってて画像を生成させたり
  • 写真1枚からヒーロー画像を作る
    • 生成アップスケールで画像の解像度を上げられる
    • 生成拡張で画像を引き伸ばして追加部分を勝手に補完してくれる
  • アイコンイラスト制作
    • ベクターの生成ができる
      • パートナーモデルも使い分けられる
      • 効果やトーンのオプションを設定すると雰囲気を指定できる
    • 生成再配色
      • 作成済みのデザインの色を変えたパターンを試せる
      • 色のセットを用意してくれてる
  • 静止画からファーストビュー動画作成
    • 画像の背景削除し新しい背景を生成
    • 画像を元にFireflyで動画を生成できる

AIエージェントと並走するWeb制作

長谷川広武さん(株式会社HAMWORKS)

  • AIとの関わり方
    • 壁打ち
    • 丸投げ
    • 並走
  • AIとの並走
    • 要件整理
      • AIに整理させる
    • デザイン検討
      • Figmaで画面案検討
    • 実装
      • AIに任せる
    • 画面確認
      • AIに画面撮影させて人がチェック
    • 修正
      • 必要なところを
    • レビュー
      • 別AIに評価させて人が決める

全自動並列AI駆動開発への取り組み

石川栄和さん(株式会社ベクトル)

  • GitHubのissueから自動でプルリクまで
  • ルール化
    • コミットやプルリクのルール
    • そのままchangelogに載ったり人が見るやつはしっかりと
  • スキル作成
    • ルールをスキルにして自動で守れるように
    • ルールは一箇所にしてそれを参照するように
    • サブエージェントで役割を持たせて並行で
  • トークン消費対策
    • ClaudeとCodexを併用して消化具合で使い分ける
    • 工程ごとに実行モデルを変える
    • issue単位で複雑度を設定しそれを見てモデルの切り替え
    • 軽微すぎる修正でチェックが回りすぎないような調整

AIと並走する組織に必要な「決める人」の仕事

綿貫佳祐さん(株式会社エイチームホールディングス)

  • 組織の速度
    • 速くて効率がいい人を増やすより遅くて効率の悪い人を減らすのが重要
    • ある人や部署だけ仕事が速くなっても前後が変わらなければ全体は変わらない
  • 決める人が遅いポイント
    • 決める人の仕事は部下から指摘されづらい
    • レイヤーが上がるほどAIでの改善を現場に求めがち
    • 変わるのは部下より先に決める人
  • 情報の集め方
    • 知りたい時に都度説明を求めていないか
      • 現場に余計な仕事を課して作業を止めていないか
      • 決める人自身の処理速度が変わっていない
  • 情報を記録し取り出せる環境
    • 決める人だけでAIを使って確認できる状態に
    • 加工した後の数字しかないと欲しい情報を作り出せない
    • どの情報をもとに何を意思決定したいか
    • 仕事の流れと情報が残る場所を把握する
    • 経緯や判断理由も残す
      • 背景、迷い、失敗
    • 自分の指示もそれと同じレベルの情報を渡せるようにしないといけない
  • 決める人が設計する
    • 何を参照しどこに記録するか
    • 残すものをゆだねると個々の判断になってしまう
  • 人間にしかできない仕事とは
    • 仕事と情報の流れがわからないとその線引きはできない
    • 人間の仕事と思っていても言語化ができていないだけ
  • 選択の責任を引き受けるなら自分の考えも更新し続けないといけない

「「誰もどれも取り残さない」は、どうつくる?|PROJECT SOLITの実践」に参加してきました

「誰もどれも取り残さない」は、どうつくる?|PROJECT SOLITの実践

田中美咲さん(PROJECT SOLIT)

  • 社会が変わる時
    • 純度の高い前例
    • 追随するためのエビデンスや成功事例
    • 協力者
  • 変えやすいもの
    • カルチャーは時間がかかる
    • コマースやファッションは早い方
  • 二元論や中心主義
    • カテゴリにハマらない存在を見落としてきている
  • 複雑だが解決しないといけないことを解決する
  • DEI Studio
    • 異なる専門家と対話
    • 実践者同士の継続的なコミュニティ
    • 毎年全5回

「AIを「導入」で終わらせない——経営から開発まで、AI活用をどうつなぐか」に参加してきました

ディスカッション

山口徹さん(株式会社タイミー)
日比野淳さん(テックタッチ株式会社)

  • AIプロダクトマネジメント
    • AIビルダー
      • 基盤となるAI技術やモデルの開発に注力し技術チームと密に連携してロバストなシステムを構築する
    • AIエクスペリエンス
      • AIの能力をいかした魅力的かつ革新的なユーザー体験の設計に重きを置く
    • AIエンハンスド
      • 既存のワークフローにAIツールを取り込み生産性向上を目的とする
  • AIビルダーと全社組織
    • スピードを守りながら何を競争資産として蓄積するか
    • どこにリソースを投入するかの判断
    • 現場を知ること
  • AIビルダーとプロダクト組織
    • 実現したい顧客価値に対してどの技術をどこまで持ち本番で運用するか
    • 今あるサービスの資産を他にいかす
    • コンパウンド戦略
      • どんなデータをとってどこで使うか
  • AIエクスペリエンスと全社組織
    • AIによってどの事業価値を伸ばしたいのかそのためにどこへ投資するか
    • 現場を理解する
    • 技術のブレークスルーによって課題が解消するところ
    • ピーク性の特定にデータサイエンスの活用
      • データはとれている
  • AIエクスペリエンスとプロダクト組織
    • モデルの能力をユーザーにとっての使いやすい役に立つ安心できるにどう変えるか
    • 検索や推薦の精度向上
      • マッチングに至るまでの推薦を内部的には1つのサービスにするくらい
    • 売上やコストに影響するところ
    • 業務にとって革新性があるところ
    • 課題ドリブンと技術ドリブン
      • 技術の進歩にともなってそれで何ができるようになるか
  • AIエンハンスドと全社組織
    • 人を減らすことではなく売上拡大に比例して人員が増える構造をどう変えるか
    • AIへの投資とそこから生み出された価値
      • エンジニアの領域はやりやすい
      • 全社でみるとはかるのは難しい
  • AIエンハンスドとプロダクト組織
    • AIを使うチームが速度だけでなく品質と成果を高めるための条件は何か
    • 昨今の情報漏洩

SRE・情シス・データの三位一体で、組織の AI ケイパビリティを底上げ!

市川悠人さん(テックタッチ株式会社)

  • 組織の変化
    • 2025年安全に全社に渡し切る
      • 止まったら乗り遅れる
      • 野放しは危険
    • そのために組織統合
      • SREと情シスを統合
      • Security & Reliability
  • DORA AIケイパビリティ
    • 開発組織に関するケイパビリティ
    • 7つの条件
  • 実施したケイパビリティ
    • 明確で周知されたAIスタンス
      • AIごとの規約の違い
      • スキルやMCPを申請制に
        • 定番以外は申請で
        • 多くは自作
        • 安易に導入しない
      • 使っていい悪いなどの細かいルールもAIに聞けば分かるようにすれば守りやすい
        • SlackAIボットで回答
    • 質の高い社内プラットフォーム
      • AIは隔離せず各自の端末で動かす判断
        • 守る範囲は端末全部
      • 個人設定に任せずMDMで強制上書き
        • Takumi Guardで検査済みのライブラリしか入れられないように
        • AIエージェントの設定も配って上書きできないように
        • 設定はGitHubで管理し閲覧やプルリク出せるように
  • 進行中のケイパビリティ
    • AIがアクセス出来る社内データ
      • 聞けば答えるボットで部門をこえたつながり
      • データを開くほど問題はある
        • アクセスできてはいけない情報
        • AIに読まれることを意識してない古い情報でもっともらしく間違える
    • 健全なデータエコシステム
  • 未着手のケイパビリティ
    • 小さなバッチ
    • 強固なバージョン管理
    • ユーザー中心

AIが広がった開発組織で、次に整えるもの 〜 開発の変化を測り、AIに任せられる環境をつくる 〜

橋本和宏さん(株式会社タイミー)

  • Agent Harness G
    • インフラやSREやハーネス設計など
    • コーディングエージェントを開発組織に入れて生産性と安全性をあげていく
  • AIによるコーディングの割合
    • 2025秋から2026夏で30%から70%近くまで
    • 組織で使う段階へ
  • AWSのUnicorn Gym
    • 3日の研修
    • AIへの指示のしかたの浸透
    • 非エンジニアもClaudeの利用が増える
  • AI活用が浸透したがコストが急増した
    • コントロールしないと無限に使ってしまう
    • 可視化と申請フロー
    • ツール別の個人の状況を確認し使い分ける
  • 開発の成果は上がっているのか
    • コードの変更量
      • マージプルリクエストは増えた
      • 1.8倍
    • 変更にかかった時間
      • デプロイリードタイム
        • 30時間程度から20時間程度へ
      • マージリードタイム
        • 悪化はしてない
    • 変更失敗率
      • AI拡大期に上昇した後低下した
      • その後も揺れてるので要ウォッチ

「 「仕様通りに作る」から「価値を生むために作る」へ。SIer出身者の転職記」に参加してきました

SIer出身エンジニアが、エンジニア1人体制で「アソビュー!ふるさと納税」を立ち上げて気づいたこと

川又亜弓さん(アソビュー株式会社)
https://speakerdeck.com/chronos2074/todoke-kiru-chikara-mo-migakikomu-chikara-mo-kachi-o-umu-monozukuri-ni-kakasenai-sier-shusshin-enjinia-ga-enjinia-1-jintaisei-de-furusato-nouzei-o-tachi-age-te-kizuita-koto

  • SIerから事業会社へ
    • 入社1年で新規事業の立ち上げを担当
  • SIer時代
    • 1次受けの受託開発
    • 新規開発の案件
    • つくって収めて守り続ける
      • 知りに行く力
      • プロジェクトマネジメント
      • 保守性を意識した開発
    • 対価は契約で決まって成果物や工数に支払われる
      • 精度と付加価値
  • ふるさと納税の新規事業
    • 物の返礼品だけでなく体験をする機会を創出
    • 事業責任者と営業とエンジニアの3人
    • 開発期間は5ヶ月
      • 2023年の話
      • 当時は年末がピーク
    • 進め方の工夫
      • ユーザーストーリーマッピング
      • 期限優先で必要なものを取捨選択
      • 事業部も巻き込んでスクラムで
    • ふるさと納税でアソビューのクーポンをもらえるサービス
      • すぐに使える
      • 配送がいらない
      • でも最初はなかなか使われない
      • ふるさと納税しようという流れでは使おうと思いづらい
        • 週末どこかに遊びに行こうという人に訴求する
    • 届けて使われて選ばれ続ける
    • 使われて初めて対価が生まれる

金融ドメイン知識ゼロから始まった挑戦

室井大輝さん(ウェルスナビ株式会社)
https://www.docswell.com/s/WN_Tech-PR/ZQ2J3J-2026-10-13

  • SIer時代
    • サービスを使う顧客と開発者の距離があった
      • ドメインの情報を得るのが難しい
      • 接点も限られる
      • 仲介者が多いのでスピード感が出ない
    • 内製で素早く開発してる事業会社へ
  • 事業会社でぶつかった壁
    • 気持ちの持ち方の切り替えが必要だった
      • 作ることに集中していた
      • 曖昧なところを確かめないまま進めていた
      • 材料は近くにあった
    • 事業側と開発側での当たり前が違う
      • 言われたまま作ると運用に耐えられない
        • システムの観点で翻訳して認識を合わせないといけない
      • 距離が近いだけで全てが解決するわけではない
        • 具体例で会話し必要な情報を引き出す
      • 同じドメインに関わり続けることができる
        • 腑に落ちるまで理解し育て続ける

納品して終わり、を事業会社でやった話 ── 現場の隣に座るまでの4ヶ月

盛田崇弘さん(Ubie株式会社)
https://speakerdeck.com/tamosan01/nouhin-shi-te-owari-o-jigyou-kaisha-de-yata-hanashi

  • 納品して終わりはSierかどうかの問題ではない
    • 事業会社でも起こりうるしSIerでそうでないこともある
    • ユーザとの距離の問題
  • 失敗事例
    • 営業の商談文字起こしツール
      • 最初の10日だけフィードバックはあったがその後使われない
        • 作った後に追いかける数字を決めていなかった
        • 現場から離れて作っていると受託と変わらない
      • 自席で作っているだけではダメ
        • 隣の席に行って開発
        • 商談にも一緒に出る
      • 作ることより作らないことが大切
        • 作ってものを持っていっても使えないものだと意味がない
        • 自動であれこれ連携しても情報過多になる
        • 体験をしっかり設計して本当に必要なものを

パネルディスカッション・Q&A

中薗昴さん(モデレーター)
川又亜弓さん(アソビュー株式会社)
盛田崇弘さん(Ubie株式会社)
室井大輝さん(ウェルスナビ株式会社)

  • 転職直後に取り組んだこと
    • ドメインのキャッチアップ
      • 問い合わせや障害対応など積極的に
    • エンジニアじゃない人とたくさん話す
  • ステークホルダーのインサイトを引き出すために工夫してること
    • 大事にしていることを引き出す
    • 当たり前の常識になっているような知識を持つところから
    • すぐ近くの席に行って会話に入り込んでいったり
      • 何か相談したら役に立ちそうと思ってもらえるように
      • 打ち合わせでは聞けない話を見つけ出す
  • SIerで学んでおくといいこと
    • 議事録書いたりとか地道な作業
    • 自分が月いくらで売られているのか
      • 自分の価値を考えて動く

「Minato.dev#01 [非公式]Vue Fes Japan直前回!フロントエンド特集」に参加してきました

  • 2026/10/13
  • https://minato-dev.connpass.com/event/402521/

    感想

  • 港区周辺の新しいコミュニティということで職場から近いので参加してみました

  • 少人数でいい空気感だったので次回もまた行ってみたいです

主催セッション:なぜMinato.devを立ち上げたのか / コミュニティと企業の距離

Halさん(Minato.dev)

  • コミュニティはOSSと似たような構図
    • 使ってる側参加してる側が受け身になりやすい
    • 中に入って貢献していくのもだいじ

スポンサーセッション:このままでは刷新が終わらない-基幹システム刷新にループ開発基盤を持ち込んだ話

福田勇斗さん(株式会社LIXIL)

  • LIXIL
    • 顧客 - 施工店 - 流通 - LIXIL
    • 見積もりしたりする基幹システム
  • 基幹システムの刷新
    • 45画面
    • インフラやCICDは整えた
    • 現在残り39画面
    • 期限は2028/3必着
  • 人を増やすだけでは速くならない
    • リードエンジニアの負荷増
    • 人に依存しないループエンジニアリング
    • 従来までの土台の上にContextとHarness
    • 現行のJavaコードに仕様がある
  • AI駆動開発のフロー
    • Loop-managerがサブエージェントを呼び分けてタスクを処理していく
      • 最初は作った本人が活用できる環境
      • 新任メンバーでも活用できる状態までたどりついた
    • レビューのルール
      • 放っておくとレガシーコードマネてしまう
      • デザイナーも入ってデザインルールに準拠できるように

LT:JSのProxy割と使われている

てるし〜さん

  • JSのProxy
    • 別のオブジェクトの代理となってデータを返す
  • Vueのreactiveの仕組みでも使ってる
  • UIライブラリなどでも使われてる

LT:ファン1万回の『こっち』でEveのセトリを作る。LMArenaの仕組みをライブに持ち込んでみた。

乳酸カルシウムさん

  • VueのTransitionとTransitionGroup
    • ViewTransitionAPIが使える
    • ページ遷移のアニメーション
  • ページ遷移せずに一部分をアニメーションさせたい
    • Vue標準だとまだできない
    • startViewTransitionなど呼んで操作
    • ランキング一覧がリアルタイムで切り替わるようなUI

LT:型はネットワークの境界を越えない

いけちりさん

  • フロントもバックもTypeScript
    • APIの型はそれぞれでベタ書き
    • 同じ内容をそれぞれ修正するのでレスポンスの型のチェックをしてなかった
  • バックエンドだけプロパティ名を変えてみると
    • どこでもエラーが出ないが表示で壊れた
  • ネットワークをまたぐと型がきかなくなる
    • JSONはただの文字列
      • 型情報は届かずDateも文字列になる
    • 型は実行時に消える
  • 型を共有する
    • コンパイル時に確認できる
  • 実行時に検査する
    • 実行する時にエラーで落とす
  • Hono RPC
    • 実装から型を推論する
    • 型の違いがあれば実行時に検知できる

LT: VueのSuspenseで楽にフォールバックコンテンツを再表示したかったけど

rkyuritさん

  • VueのSuspense
    • fallbackをReactみたいに楽に書くことが出来ない
    • propsが変わった時にfallbackが表示されない
      • setupはやり直さないから
      • keyをつけてそれが変わると再表示できる

LT:大型犬好きによるPugの紹介

yamanokuさん
https://speakerdeck.com/yamanoku/hey-its-pug-woof

  • 犬の名前がついたライブラリやツールはいろいろある
  • フロントエンドだとPug
    • htmlのテンプレートライブラリ
      • コンポーネント化したり
      • ループや条件分岐を書いたり
    • hamlに影響を受けた
      • インデントで表現
    • v2からPugでそれまではJadeだった
  • PugはVueでも使える
    • <template lang="pug">
    • @vue/language-plugin-pug
  • 今Pugを選択することがあるか
    • 今はUIライブラリのコンポーネント志向が浸透してる
    • htmlを直接書くことがスタンダード
    • ツール周りとの親和性のなさ
    • AIが書くことも考えると

「フロントエンドカンファレンス関西2026」に参加してきました

HTMLを着たCanvas 2D - HTML-in-Canvasで作る未来のWeb UI表現

池田 泰延さん(ICS)
https://speakerdeck.com/clockmaker/html-in-canvas

  • Canvas
    • Canvas2D
    • WebGL
    • WebGPU
    • HTML in Canvasは3つ全てに対応
  • HTML in Canvasの活用
    • 画面遷移
    • 3D空間へのHTML配置
    • ページの画像化/動画化
  • CSSのぼかしやマスク
    • backdrop-filter
  • CanvasにHTMLの機能を
    • Canvasはテキストの描画が苦手
    • 折り返しを自分で座標計算しないといけなかったり
    • CSSだと自動での改行はもちろん禁則処理や文節での折り返しもできる
    • HTML in CanvasだとCanvasにCSSでレイアウトした内容を持っていける
  • Canvasをマシンリーダブルに
    • 通常のCanvasは画像なのでわからない
    • HTML in Canvasだとhtmlなので解釈できる
  • Canvasにフォームを置ける
    • htmlを書けるので
  • 実装手順
    • canvasタグの子要素にdivなど書いていく
    • canvasのcontent属性にdrawableを書く
    • JSで drawElementImage() で描画
      • canvasなのでずらしたり傾けたり何でも
      • クリックエリアなども自動で追従
      • ただしシェーダーで変形させても矩形エリアしか押せない
  • ライブラリ
    • VFX-JS
    • Canvas UI
    • Three.js
    • PixiJS
  • 対応ブラウザ
    • Chromeが一番はやい
    • Chromeの157に載ってくるかも

ブラウザとサーバーから考えるAI時代のフロントエンド監視

Shogo Fukamiさん(Canary)
https://speakerdeck.com/shogo4131/to-saba-kara-kangaeru-ai-jidai-no-furonto-endo-kanshi

  • 監視とは
    • 可視化
      • 稼働状況を見えるように
    • 検知
      • 異常を見つける
    • 対応
      • 異常に対処する
  • 監視がないと
    • リリースして壊れていても気付けない
    • 気付けないエラーの実例
      • APIのレスポンスサイズが大きすぎて表示できない
      • ABテストの片方がエラー
      • ライブラリの破壊的変更でエラー
    • ユーザからの問い合わせで気づくことになってしまうことも
  • AI時代の開発
    • 攻めは速度が上がって進んでいる
    • 壊れたことにすぐ気がつける守りの仕組みも必要
  • フロントエンドの監視
    • JSのランタイムエラー
    • ブラウザ/OSのバージョン依存のエラー
    • API通信のネットワークエラー
    • 拡張機能によるエラー
  • フロントエンドの監視領域
    • SSRが普及してSPA時代よりも責任範囲が増えた
    • SPAならブラウザだけでよかった
    • フロントエンドサーバを持つようになった
      • サーバやインフラの監視もスコープに
  • 監視設計
    • アラート設定しすぎると鳴り止まなくなる
    • ブラウザのエラーはユーザ環境によるエラーも多くある
    • 自分たちで直せるか x 売上に響くか の2軸
  • アラート対応
    • 誰かが見るだろうにならないように
      • エラーの重要度を判断できるように
      • 誰がいつまでにどう対応するか
    • 運用ルール
      • 即時/当日/24時間等
      • 平日日中はローテーション
      • Runbookで手順化
    • Runbook
      • 障害の対応手順書
      • どこを見てどう直して誰に上げるか
      • 対応要否の条件など
      • 誰がやっても同じ初動対応ができるように
  • AIを活用した運用
    • 全て人間でやるとそれなりの工数がかかる
    • 監視ツール開いてエラー読んで調べて・・・
    • Devinで判断と修正までを自動で
      • 監視ツールに縛られないようDatadogのAIなどではなく
      • 他の領域の運用でも使えるもの
    • Devin Automations
      • Slackに来たアラートをトリガーに動くとか
      • Runbookを見て作業させる

トレードオフの中で体験を設計する、長期運用プロダクトのデザインエンジニアリング

わっきーさん(Fusic)

  • 360度評価のサービス
  • 管理者が公開前にコメントを削除したいという要望
    • 匿名性というサービスの思想との競合
    • 評価者の心理的負担の悪化
  • AIに要件を渡せば作れるが何でも作っていいのかの判断が必要
    • 思想と一貫性を維持したままの体験設計
    • これまでのユーザとの信頼を壊さないように
  • 回答時に説明モーダルを開かないと評価基準がわからない
    • 近くに置いた方が見やすいが他の操作の体験も変わってしまう
    • 思いつく案のマイナス面も対処できるような選択を

フロントエンドのモデルに境界を引く ── AIがコードを書く時代に、人間が決めること

Hiroki.Mさん(KINTOテクノロジーズ)
https://speakerdeck.com/babywkb/furonto-endo-no-moderu-ni-kyoukai-o-hiku

  • 仕様変更のコスト
    • 業務側と認識合わせるのが大変
      • 日常的に顔を合わせられない環境だとなおさら
    • 機能が散らばっていると影響範囲の調査が大変
    • 他の人がAIで修正を大量に入れていく状況
  • 仕様の関心のレイヤーが混在している
    • 業務の話
    • 体験の話
    • 表現の話
    • 認知負荷が上がって理解が難しい
  • ドメインモデリング
    • 業務知識を意味ある構造として表したもの
    • 同じシステムの中では同じドメインモデルに従う
      • フロントエンドもバックエンドも
    • モデリングをするのには体力がかかる
      • 関係者を巻き込んで会話を重ねて
  • フロントエンドにおけるモデル
    • 見せ方のための決め事と業務ルールの適用を含める
      • バックエンドの状態を見せるための変換ルールとか
    • 表示の制御は含めない
    • モデルは画面に依存せずに使える判断
  • フロントエンドモデルの実装
    • 表示の分岐や入力の制御を片っ端から抜き出して関数化
    • 判断を問いに変えていく
      • キャンセルボタンを活性にするか、の例
      • UIの都合は除いていく(ボタンを非活性にとか)
      • 主語を明確にする
      • 注文をキャンセルできるか、のようになる
    • APIレスポンスモデルから自分たちの型に変換する
      • APIレスポンスはいろいろな都合で組み立てられることがあるからそのまま使わない
    • どこでモデルに変換するか
      • UIコンポーネントには概念の型だけ渡す
      • Container/Presentationパターン
    • フロントエンドモデルのルールを誰が所有するか
      • 所有している
        • 画面の見せ方の都合で決められるか
        • なぜそうなってるかの答えが画面にあるか
        • 勝手に変えてどこに影響出るか
      • 所有してない
        • 普遍的な業務ルールか
        • この領域は周囲と認識合わせをしていく必要がある
  • 既存アプリのモデル切り出し
    • 仕様変更のタイミングで
      • ドメインエキスパートと会話できるタイミング
      • 学習し直す価値が高いタイミング
    • 画面単位で
      • いきなり横断で整えていくのは難しい
  • 抽出の自動化
    • AIにモデリングさせるのはうまくいっていない
      • 余計な情報まで含めてくる
    • ドメインモデルのテスト
      • モデルのテストを書く中で業務を理解することにもつながる
      • AIが想像でそれっぽいものを出してきた時に見抜かないといけない
  • ドメインモデルをどこに記録するか
    • フロントエンドに閉じないものをどう残していくか
    • ドキュメントにしたとしてメンテしていけるのか
    • バックエンドにおくのがあるべきかもしれないがフロントエンドがどう参照するか

複雑なUIコンポーネントとの長い付き合い方:波及するバグからテスト戦略を経て、安全な再設計へ

あさマックさん(ログラス)
https://speakerdeck.com/mixplace/fukuzatsuna-ui-konponento-tono-i-tsukiai-hakyuu-suru-bagu-kara-tesuto-senryaku-o-he-te-anzenna-saisekkei-he

  • UIコンポーネントライブラリ
    • シンプルなものから複雑なものまで
    • これの品質がプロダクトの品質につながる
    • 複雑なものはそもそも作りたくないけど必要な場面はある
  • 複雑なUIコンポーネント
    • マスタ選択UI
      • ツリー構造で複数選択できるUI
      • 部署のツリーで複数選んだり親を選んだりのセレクト
      • 性能と複雑性を両立させる必要があった
  • 品質を保つ難しさ
    • 細かな機能の不具合が出てくる
    • テストを拡充してもカバーしきれない
    • あらゆるところで使われるので利用している全プロダクトに影響が出てしまう
  • 品質改善の取り組み
    • このUIがなぜプロダクトにとって大切なのか
      • アプリケーションを通じて届けたい価値のどこにつながるか
    • 何をテストで守りたいか
      • 機能が動いてる
      • 見た目がずれない
      • 勝手に変わらない
      • 動作が重くならない
    • 網羅性を上げる
      • 状態遷移テスト
        • 現在の状態と発生したイベントによってどんな状態に変わるか
        • 状態遷移図
        • Nスイッチカバレッジ
          • スイッチ数を増やすと指数関数的にケースが増える
          • 3スイッチを超えたあたりで未確認の不具合が見つかったりはした
      • プロパティベーステスト
        • 自動生成した入力データでルールが成り立つか検証するテスト
  • 安全な再設計
    • 不要な機能を減らす
      • 公開済みの機能だと消すのも大変
      • 他職種も巻き込む必要あり
    • アーキテクチャの根本的変更
      • 相当なリソースが必要
    • ステークホルダーとの合意が必要
      • 長期的な戦略の話になってくる

宣言型部分更新は何を解決しどこへ向かうのか

did0esさん(CyberAgent)

  • DPU
    • Declarative partial updates
    • 宣言的部分更新
    • Chrome148から実験的機能で入った
    • 文書のコンテンツを組み替えられる
    • HTML要素とJS API
  • DPU登場の背景
    • HTMLは上から下に配信される
    • CSSで順序を強制的に変更できる
      • 目で見たときだけ変わる
    • JSではDOM操作が複雑でパフォーマンスの考慮も必要
    • ライブラリを使うと文書を書くというよりコンポーネント
  • DPUのAPI
    • Patching
      • 順不同ストリーミング
      • <?marker name="xxx">を <template> で置き換える
      • ?は処理命令プレースホルダー
      • <?start> / <?end> で表示までのローディングとか
      • 内部的にはMutationObserverで動くのでHTMLパーサーに介入するわけではない
    • 動的マークアップの刷新
      • innerHTML
        • サニタイズが必要になる
        • Declarative Shadow DOMに非対応
      • setHTMLUnsafe
        • innerHTMLの後継
        • サニタイズは必要
        • DSDに対応
      • setHTML
        • サニタイズあり
      • createContextualFragment
        • ただのフラグメント
      • insertAdjacentHTML
        • サニタイズは必要
        • 指定した位置に挿入できる
      • DPU
        • サニタイズできるようにする
        • ストリーミングで速度を上げる
        • 従来の各処理を拡張したり置き換えるものが用意されている
        • setHTML/replaceWithHTML/beforeHTML/prependHTML/appendHTML/afterHTML
        • Router Match
          • CSSで @navigation
          • URLを捕捉する(ViewTransition周りでの活用)
          • ロードの検知
  • DPU関連技術
    • DOM Parts API
      • {{}} の注釈を置き換える
      • DPUと併用するもの
      • contentrevision 属性でページ遷移しても再読み込みしない要素?
    • View Transition API
      • Router Matchと組み合わせると戻るでも発火させられる

気持ちぃ〜角丸 Squircles

ryuさん(タイミー)
https://speakerdeck.com/ryu1013/kimochi-sumi-maru-squircle

  • Squircle
    • 四角と丸の間
    • 直線から曲線への変化が滑らか
  • border-radiusと corner-shape: squircle を併用する
    • 使えるブラウザはまだ少ない
    • 使えなくても無視されるだけ

パスキーの自動テストはどこまでいけるのか

志田洋斗さん(チームラボ)

  • パスキー
    • パスワードの代わりにスマホなどの顔認証や指紋認証でログインできる仕組み
    • スマホとブラウザがWebAuthnという仕組みでやりとりする
  • パスキーの自動テスト
    • Playwrightで仮想認証器が使える
    • 実際の認証器依存は個別にテストは必要
      • 例外系とか
      • 認証器のバリエーションとか

Webの常識が通じないHTMLメールのダークモード

takeさん(チームラボ)

  • HTMLメール
    • htmlとcssで作るメール
    • メールアプリのクライアントで表示される
  • メールでのダークモード
    • 一般的なWebならprefers-color-scheme
    • メールだと上手く動かない
      • メーラーによって表示のされ方も違う
    • caniemailでどのメールクライアントで何が使えるか見れる
    • 対処方法
      • metaタグでcolor-schemeを宣言
      • 自動反転されても崩れにくいデザインに

AI時代に、みんなでフロントを作るためのNix

ぶりおさん(千)
https://slide.burio16.com/nix-for-everyone

  • Nix
    • 純粋関数型パッケージマネージャー
    • 再現性/宣言的/信頼性
  • devShell
    • 利用できるshell環境を定義できる
  • direnv
    • ディレクトリごとに環境変数を切り替えられる

AIがユーザーになる時代のフロントエンドのシステム境界を考える ~ Generative UIに共通する設計思想 ~

daitasuさん
https://talks.daitasu.work/talks/2026/261012_frontendconf_kansai/#/1

  • Generative UI
    • LLMがその場でUIを作成
    • ユーザが求めるUIをAIが作る
    • 捨てる前提で会話ごとに使い捨てる
  • json-render
    • カタログでスキーマを定義
    • コンポーネントを作る
    • カタログからシステムプロンプトを作る
    • AIがさわるのはjsonだけでそれを元にUIを構築

今さら理解するウェブフォント2026

takanoripさん(カンム)
https://speakerdeck.com/takanorip/imasara-rikai-suru-ver-2026

UI実装者が書いたシナリオだからこそ、意味を持つk6負荷試験

梅木和弥さん
https://www.figma.com/deck/PsvOgbFBfXsUaNQJciQKP5/UI%E5%AE%9F%E8%A3%85%E8%80%85%E3%81%8C%E6%9B%B8%E3%81%84%E3%81%9F%E3%82%B7%E3%83%8A%E3%83%AA%E3%82%AA%E3%81%A0%E3%81%8B%E3%82%89%E3%81%93%E3%81%9D%E3%80%81-%E6%84%8F%E5%91%B3%E3%82%92%E6%8C%81%E3%81%A4k6%E8%B2%A0%E8%8D%B7%E8%A9%A6%E9%A8%93?node-id=1-98&t=YmMVnoKAvNTIMBeT-1

開発を高速化。AIコーディングエージェントとCodeRabbitでループエンジニアリング

中津川篤司さん(CodeRabbit)
https://speakerdeck.com/moongift/kaihatsu-o-kousokuka-ai-kodingu-ejento-to-coderabbit-de-rupu-enjiniaringu-9c1a98ee-8ce5-4dc0-8444-bec1c848bf8e

Figmaをゲームエディタに!コードを書かなくてもSPAゲーム制作に参加できる仕組み

まぁしさん(TAM)

AIで速く作れる時代に、整合性をどう保つか 〜動くものを作る前にチームで決めること〜

小泉岳人さん(ニッセイ情報テクノロジー)
https://www.docswell.com/s/Insurtech-lab/ZR87NN-2026-10-12-131905

二歩目のフロントエンド・ウェブアクセシビリティ

神原 拓海さん
https://speakerdeck.com/camiha/nihome-no-furonto-endo

V8のArray.prototype.flatを最大約20倍速くするまでと、巨大OSSへの大規模コミットの道のり

西 悠太さん
https://speakerdeck.com/riyaamemiya/v8-no-array-prototype-flat-o-saitaiyaku-20-bai-hayaku-suru-madeto-kyodai-oss-heno-daikibo-komitto-no-michinori

速すぎるUIに、待ち時間を

irieさん

AIに画面を壊してもらう:MCPで広げるフロントエンドの探索的モンキー試験

Chen Xuさん

Webの限界を越える、Web NFCでタッチ

Seiさん

8年前のNode.jsを動かして分かった、npm install の裏側

Keisuke Ikedaさん

SharedWorkerを使ったキャッシュでネイティブアプリに負けないユーザー体験を目指す

Nokogiriさん(カケハシ)
https://speakerdeck.com/kakehashi/sharedworker-caching-for-native-grade-web

「Designship 2026(Day2)」に参加してきました

音楽と映像が、私に教えてくれたこと。

林響太朗さん(DRAWING AND MANUAL)

  • 図画工作という意味の社名
    • ミュージックビデオ
    • プロモーション動画

デザインシステムを手放してみる - AIを信じたマルチブランド開発の再設計

大澤 健太郎さん(GMOメディア株式会社)

  • ブランドごとに異なるアプリケーション
    • 共通となる部分をデザインシステムで
  • 開発スピードと自由度のバランス
    • ブランドが違うとペルソナやクライアントの要望も違う
    • 各ブランドの要望全てに応えるわけにはいかない
  • AIで速度が上がった
    • しかし求められるスピードも上がった
    • AIに上手く動いてもらうための制約も増えた
    • AIのことを信用しきれてない
  • 速度と自由度はトレードオフな関係なのか
    • 仕組みの改善で両立できないか
  • デザインシステムを手放してみる
    • なくしてみたらデザインのフローがどう変わるか
    • なくしたもの
      • 共有するソースコード
      • コンポーネントライブラリ
    • 残したもの
      • デザイン原則
      • トークンの構造
      • アクセシビリティ規則
    • 実装基準がないのは上手くいかなかった
  • 必要なものは制約にならずに判断する時に立ちかえれるもの
    • ライブラリ型から見本型へ
    • 架空のブランドサイト

企業のアート活動は、何をデザインしているのか ― 「アートでないもの」から始まるコミュニティデザイン ―

花崎 徹治さん(株式会社野村総合研究所)

  • アートではないものとは何か
  • アート部
    • 社内のクラブ活動
    • 203名
    • 成果を求められないスペース
    • 趣味としての活動を話せる場
  • これからの組織デザイン
    • 内発的動機
    • 心理的安全性
    • チーミング

ゆるすためのデザイン—AIと80万人に揺れながら

中川 孟さん(アクセンチュア株式会社 / Accenture Song)

  • 重厚なデザインシステム
    • デザインに詳しくない人でも作れるような厳重なルール
    • ルールが厳しいと決められたことしかやらなくなる
    • 新しい発想を出そうとしなくなる
  • 組織の変化
    • ゆめみからアクセンチュアへ
    • 組織の大きさの違いによるルールの厳格さの違い
  • AIを使えばすぐにできるものを3日かけて綻びだらけで出してきたらどうするか
    • 過去AIがない時代に許されて成長してきた
  • 許しの構造
    • 逸脱が負の帰結につながる
    • このつながりを断ち切ったり時間を置いたり
      • 分散/戻し/転嫁/読み替えなど

「課題と未来を接続する」デザイン組織のつくり方

篠原 健さん(株式会社エス・エム・エス)

  • 40以上の事業がある組織
    • 事業が強くて縦割り
    • 横のつながりが薄い
  • 現場の声と経営陣の声
    • 持っている課題が全然違う
    • 今解きたい課題と未来の理想
  • 課題と未来を接続する
    • 課題を3つの資産に
      • リソース
      • ナレッジ
      • 共通基盤
    • 未来を3本の柱に
      • AIで余白をつくる
      • 一次情報を集める
      • 事業数字につながるKPI
    • 横断組織でこれらを実現する
      • 専任は一人
      • 役目を終えたらなくす

人工物と人との対話から学ぶ、情報デザインの可能性

駒田 瑛則さん(株式会社U'eyes Design)

  • UIデザインの工夫
    • 操作した時に反応がないと困る
    • ローディング中であることを示すとよい
  • 人との会話も同じ
    • 考えていることを伝えることがだいじ
  • あるべき順番は逆
    • 人とのコミュニケーションをデザインに活かすのがいい
  • AIによる自律システム
    • 人の指示で動く道具だった
    • AIを活用されると次に何が起きるかわからない
    • 自動運転のバスで左折中であると示す
      • ウィンカーだけで伝えることはできる
      • 運転手が歩行者である自分を見ていると分かることが安心になってた
    • 工場の自動ロボットが状況を予測して動いてくる
      • 無言で近づかれると怖い
      • ロボットは人を認識していると人に伝わることがだいじ
  • 相手の考えが読めること
    • 内面が読めること
      • このあとどうするつもりか分かること
    • 分かってくれていること
      • 認識してくれている
    • この2つがあって人と人工物の間の信頼が生まれる
  • そのためにやれること
    • 信頼できる振る舞いを人間が観察
    • なぜそう感じたか理由を分解
    • それを人工物の振る舞いに翻訳する

AIが変える体験の先に、人が大切にしたい価値 ― AIと人の調和に向けて ―

國島 綾子さん(株式会社野村総合研究所)

  • AI時代のプロダクト開発
    • リサーチやデザインや開発などを1人でできるようになった
  • 人が身体で感じる体験が減っている
    • 画面や情報に感覚を奪われすぎている
    • AI時代における心地よさにつながる
  • 人との会話を通した会話型CX
    • AIがユーザの意図を汲み取る
    • また話したいと思える体験
  • 人が過ごす環境に溶け込む
    • 日常で感じる違和感や気付き

社会課題は、正しさだけでは変えられない。 公共空間の譲り合い・助け合いから考える、行動を促す仕組みのデザイン

重浦 正俊さん(株式会社U'eyes Design)

  • 人を治療していくよりも社会環境の整備が必要
  • 駅での障害者の困りごと
    • 守られるルールと守られないルール
      • マナーへの合意の強さ
      • ホームの整列は守られる
      • 階段の上り下りの分離は守られない
  • エレベーターの混雑
    • 優先してもらうための工夫をどうするか
    • 共用設備だと認識してる人が多い
    • 優先であることの周知とナッジによる誘導
  • 譲られる側の気持ち
    • 思いやりで譲られるのはおかしい
    • 優先設備を使うのは権利である
    • マナーをやさしさの問題で片付けるのはよくない
    • 困っている事実を伝えること
  • 視覚障害者の見守りと声掛け
    • 助け合いをどう促せるか
    • 困ってることが不明瞭だと声掛けをためらってしまう
    • ホーム転落の事故
      • 反対のホームに電車が来たのを勘違いしてしまう
  • 正しさだけでは社会課題は変わらない
    • 環境や設備上の制約
    • 譲る人と譲られる人それぞれの立場
    • 社会としての合意

アプリはどう変わってきたか──生成AI時代のものづくりを考える

櫻井 裕基さん(フラー株式会社)

  • アプリの利用量
    • 8年前より2倍の数のアプリを使っている
    • 月間の利用数が25->49
  • アプリデザインに大切な観点
    • スマホを家と捉えてデザイン
      • 毎日使うもの
      • 非常時に必要なもの
      • 1つだけあれば十分なもの
      • 生活の中のどんな役割でそこにあるのか
    • ジョブとしてデザインする
      • アプリの使い方は多種多様
      • 世代を超えて同じような使い方をする人もいる
      • なので年代や性別では捉えきれない
      • ジョブ(用事) で考える
    • AI体験はこれから作られる
      • AIアプリを月に1回以上使う人が31%
        • 習慣化してる人は3.4%
      • 使ってない人もけっこういる
      • AIは浸透し始めているところ
      • 利用時間の中央値と平均値が離れている
      • ジョブの中にAIを組み込んでいく方が馴染みやすい

変革を支える共通言語「人間中心デザイン」-産官学で探るHCDの可能性-

高岡 綾さん(ソニー株式会社)
山本 光彦さん(経済産業省)
安藤 昌也さん(千葉工業大学)

全社員がユーザーを語れる組織へソニーのHCD人材育成とその成果

  • 昔は自分だったらどう使うかを意識して取り組んでいた
    • 自身が欲しいものと求められるものが一致していた
    • 今の時代は基本機能に追加でほしいものは多様になっている
  • 顧客の声を聞いてものづくりをする
    • 全社員向けにHCD基礎研修
      • 入社時に必須で受講
      • e-learningで
    • 実践者向けの育成講座
      • 安藤先生監修のプログラム
      • 全13回の講座を半年かけて
  • UX/HCD戦略コミッティ
    • グループ横串での活動
    • ソニーグループ全体でのUX基本理念や基本原則を設定
  • インクルーシブデザインの実践
    • テレビのリモコン
    • プロトタイプを何度も作ってフィードバックから改良
    • ボタンのサイズよりも間隔や形状の違いが重要
  • 自分はどう使う?ではなくあの人はどう使いたい?

AI時代に必要なデザインの素養

  • デザインスキルを全てのビジネスパーソンへ
    • 企業のDXのために
  • 日本のDX
    • 進んではいるが世界と比べるとまだ劣る
    • 日本はコスト削減や効率化がメイン
    • 海外は価値の創出を重視
  • 構造と文化風土の問題
    • サイロ化された組織
      • 横断した協働が進まない
      • 顧客起点の価値創出が起きにくい
    • 変革を忌避する文化風土
      • 前例踏襲や失敗回避の意識
      • 挑戦を後押しできない文化
  • デザインが果たす役割
    • DXによる変革
      • 製品サービスビジネスモデルの変革
      • 業務組織プロセス企業文化の変革
    • デザインによってこれらの変革にいい影響を及ぼす
      • 理解する力
      • 構想する力
      • 伝える力
  • デザインスキルを備えたうえで
    • 顧客中心に考える
    • 仮説検証を繰り返す
    • サイロを超える
  • 経済産業省が定義するデジタルスキル標準
    • デジタルスキル標準にデザインスキルが組み込まれた
    • 試験化も検討されている

組織文化を変える基盤としての人間中心デザインー大学での取り組みとこれから

  • 大学での取り組み
    • 社会人を対象にしたデザインを学ぶプログラム
      • デザイン技能だけでなく価値創造や組織変革
      • 社会への働きかけ
    • さまざまな大学が取り組んでいる
  • AIの時代だからこそ人を中心に捉える
  • デザイン的態度の醸成
    • 人間中心で語れるようになる - 意思決定や対話の仕方が変わる - 組織文化が変わる
    • HCDが土台の基礎知識

デザイン思考の次にくるもの ― デザインフィクションで、未来の日常から現在を問い直す

瀬下 翔太さん(NPO法人bootopia)
太田 知也さん(NPO法人bootopia)
山口 真幸さん(学術バーQ / 合同会社タウマゼイン)
中村 純典さん(経済産業省)

  • デザインフィクション
    • 未来の試作品を作り出すことで意思決定の方向性を検討する方法
    • アメリカやフランスなどで利用されている
    • デザインフィクションの問い
      • 未来の視点に立つと現在はどう見えるか
        • 未来に流通する製品を試作してみる
        • そこからどんな気付きを得られるか
      • 多様性を反映して未来をつくるには
      • 1つの未来を自分たちで選んだと思えるか
  • デザイン思考疲れ
    • 浸透したことでビジネスの中に入り込んでしまった
    • ものをつくるというところにフォーカスした考え方が新しく出てきている
      • その1つとしてデザインフィクション
  • 事例
    • IKEAがカタログの形で未来を描く
      • 2015年の事例
    • エネルギー政策で未来の暮らしを比べる
      • 2017年の事例
      • 都市の中のエネルギーの流れを想像
    • SF作家と考える国防
      • フランスでの事例
  • SFプロトタイピングとの違い
    • 本当に試作を作るかどうか
    • デザインフィクションはものをつくるところを重視している
    • SFプロトタイピングは依頼されたシナリオに沿ってSFを作るまで
  • デザインフィクションはデザインなのか
    • 建築家が都市計画も考えてる
    • デザインもリサーチを当たり前に含めていきたい
    • リサーチから試作づくりまで
  • 何がデザインフィクションの成否を決めるのか
    • フェイクニュース的に使うこともできてしまう
  • ビジョンを作るところにデザイナーが入るようになっている
    • 昔はコンサルタントとか
    • 省庁の取り組みで未来洞察的な取り組みも増えている
      • SFプロトタイピングやってたり
      • こういったところにデザインフィクションを付け加えていける
      • 経験していない暮らしを予測して別の角度から語れる

「Designship 2026(Day1)」に参加してきました

感想

  • 普段はWebの話ばかり聞いてるので違った世界のデザインの話を聞けるのがリフレッシュになってよかったです
  • ブースのクオリティが高すぎて全然時間が足りないくらいでした

つなげる建築

重松 象平さん(OMA / 九州大学大学院)

  • AIでの建築設計
    • 道路や住宅などの配置
    • AI活用してビジュアルで
    • 環境を意識したパラメータも含んで
    • これまでの資産を元に学習させられる
  • 建築家の意義
    • どこでどういう変化が起きているか
    • それが人間の生活にどう影響するか
  • デジタルツイン
    • 実際の街と同じものをシミュレーションで作る
    • センサーから取得したデータを使って
    • ゲームに転用したりもできる
    • センサーなので監視にもつながる
  • 衣食住集
    • 建築を都市化
    • 集まるということの利点
    • 集まるために作られたところじゃないところで集まる
  • パッケージ化された都市
    • 弁当箱
    • 同じようなものばかり
    • 大規模商業開発
  • 高層ビル同士のつながり
    • 連絡通路でつながったり
    • 歩いてつながるようにしたり
  • 都市の延長としての美術館
    • 美術館は計画して作っていくのに何十年もかかる
    • 都市の中に自然と配置していく

Applied Creativity is here - what is next for designers?

Eduardo Kranzさん(アクセンチュア株式会社)

  • AIとデザイナー
    • AIはデザイナーの存在を脅かすものなのか
    • デザイナーやクリエイターなくしてAIの成功はない
  • 技術は機能してるが定着してない
    • AIの結果は認める人が多い
    • どういう判断でそうなったかを知りたい人が多い
  • アイデアとそれを役に立つものにするまでの距離
    • 時間やお金がかかっていた
    • 多くの人が関わって手渡していくことになっていた
    • それが一気に縮まった
    • 試すことが安くなれば人に引き渡す必要がなくなる
      • 最初から最後までデザイナーが携われる
  • PurposeとTasteの2つのループ
    • 作る価値があるか検証するループ
    • 正しい形になっているか検証するループ
    • 両者の間を行き来する
    • AIがループを回すがクラフトと判断は人間

「食べたい。でも、食べられない。」から生まれるデザイン

宮下 芳明さん(明治大学)

  • エレキソルト
    • 電気の力で塩を舌に集める
    • 塩分は控えないといけなくても食べられる
  • 味覚メディア
    • インクを混ぜてプリントするように味を混ぜて作り出す
  • テレイート
    • 離れたところに味を届ける
    • 音声や映像を離れたところに届けるかのように
      • テレフォン
      • テレビジョン
    • 話しながら味を再現させる
    • レシピを公開することでその味を誰でも体感できるようになる
  • 全ての人類の食べたい
    • 数百年後には世界の人口はピークに
    • そんなときに全ての人が食べたいものを食べられないときがくるかも
    • 絶滅しそうな食べ物
    • 複製できれば食べられる
  • 味のインク
    • これがなくなると作れなくなる
    • 豆からあらゆるものを作っていく
      • 甘味酸味うま味苦味
    • 塩は備蓄した岩塩から作るしかない

早く、正しく、安心を届けるために。事故調査の現場でデザインが変えたこと

原口 紘一さん(SOMPOホールディングス株式会社)

  • 損害保険
    • 海上での輸送は海上保険が必須
    • 地震での損害
  • 損害調査
    • 保険金サービスの中の一部
    • 事故による損傷なのか
    • 修理見積もりは適切か
    • 資格を持った専門職
    • 人材不足や高齢化
    • デジタル非デジタル両面で業務変革
  • インハウスデザイナーの立ち位置
    • 本社と現場の食い違い
    • 当事者ではないが同じグループの一員
    • プロトタイプを中心にした議論
    • 現場の些細な手間を改善していく
    • 標準化と現場の創意工夫のバランス

私がなぜ「行政」に惹かれ続けるのか

林敬子さん(印西市役所 / Code for Japan)

  • 印西市
    • 千葉にある人口11万人の市
  • 印西市役所
    • 760人10部46課
  • 行政の情報の伝わりにくさ
    • CMSで作っていることが多い
    • 探しにくかったり言葉が難しかったり
  • シビックテック
    • 東京都の新型コロナのサイト
    • 公開後に市民とともに改善が続けられた
    • Code for Japan
  • 印西市がデザイン戦略担当の求人
    • 外から中に入って
    • 職員の困りごとを聞く場作りから
      • 1年で100件
      • 最初は来なかったが一度関係ができると次につながる
    • 行政は情報が多すぎる
      • 整えていく必要がある
      • 組織全体の広報戦略
      • 選んで整理してつなぐ
      • 誰に何を伝えたらどんな行動になるか

イマーシブテクノロジーによる空間体験のデザイン

深澤 研さん(ティフォン株式会社)

  • 現実世界の空間にVRを組み合わせた体験
    • 何もない建物を歩き回る中でVRを見せる
    • 現実の部屋の構造見えてきたりしないよう意識させない工夫
    • ゲームエンジンにモデルを取り入れて
  • ARを使ったカフェ
    • コースターからキャラクターが出てきたり
    • 待ち時間に楽しませる
    • パフェを置くことで演出
  • MRを使った商業施設
    • グラングリーン大阪
    • 施設内にキャラクター
    • 現実と合成して花を咲かせたり
  • スクリーンから空間へ

ユーザーインタビューを、デザインする - AIで誰もが顧客の声に没頭できる世界に

米山 弘恭さん(株式会社はてな(toitta))

  • ユーザーインタビューのデザイン
    • 人間同士のやりとり
    • 自由に話してもらいたいという一方で調査の目的にたどり着きたい
  • ユーザーインタビューの目的
    • わかるため
      • タスク分析型
    • 見つけるため
      • 課題探索型
    • 確かめるため
      • 仮説検証型
    • 聞くこと
      • 状況/出来事/理由
    • 理由には深さの段階がある
      • 特徴にとどまる
      • 本人への結果も踏まえる
      • 本人の価値まで影響する
      • どこまで深く聞く項目かを考えて深掘る
  • ユーザーインタビューで聞くこと
    • 点ではなく線を聞く
    • 状況
      • 5w1h
    • 出来事
      • エピソードの顛末
      • what else 他に考えたことはないか
      • how X どの程度かの感覚のすり合わせ
    • 理由
      • So ThatとWhy Not
        • そのことでどうなったのか
        • 他の選択肢はなぜ選ばなかったか
      • なぜなぜだけでは引き出すのは難しい
  • ユーザーインタビューの聞き方
    • 質問されてから回答するまでの流れ
      • 解釈 - 記憶から探す - 判断 - 表現
    • この流れを邪魔しない
    • 途中で打ち切って答えてしまうことを避ける
      • 質問の難しさ / 回答者の能力 * 回答者のやる気
    • 質問の難易度を下げる
      • 答えてほしい範囲を明確にする
    • 主語をずらして一緒に考える
      • 合理的でない行動を本人に直接聞くと角が立つような時
      • 弁明のような回答にさせたくない
      • 主語をずらして他人事のように一緒に考える
  • ユーザーインタビューの場作り
    • 回答者の考え続ける意欲を保つ
    • 全体像を伝えておく
    • 話題を切り替える時は明確に伝える
    • 話題ごとに要約して確認する

関係性は、素材である。― 組織に「未来を演じてもらう」デザイナーの4つの原則

栄前田 勝太郎さん(アクセンチュア株式会社 / Accenture Song)

  • 関係性を1枚の絵にする
    • 描く/触れる/演じる/手を入れ続ける
  • 演じることで普段と違った視点から見る
    • 反対をする人はただ不安なだけのことがある
    • 自分が何を感じていて他の人が何を感じていたのか
      • ふりかえりの場の習慣化
  • すぐにやれること
    • 会議で立場を変えた気持ちで発言してみる
    • チームで役割を入れ替える

都市を実験場に ― TOKYO PROTOTYPEが描く都市体験デザイン

石澤 滝太郎さん(森ビル)
岸 遼さん(日本テレビ放送網株式会社)

  • TOKYO NODE
    • 虎ノ門ヒルズにある情報発信拠点
    • アートやエンターテインメント
    • テクノロジーによる既存IPの再開発
      • 人を集める - 人をつなげる - 価値を高める
  • TOKYO PROTOTYPE
    • 実験的なプロダクトやアート
      • 未来を想像する実験場
      • 建物全体を使った展示
        • オフィスフロア以外は廊下なども
    • 場の枠を超える
      • 誰もがフラットに集う空間に
    • 領域の枠を超える
      • デザインやアートの枠にとらわれない
      • 特定の領域を見に来た人の新しい気付きの場
    • 出会いの枠を超える
      • 作り手との対話を通した次のコラボの結節点
      • 展示場でも話していい雰囲気
  • 新虎通りの両端が森ビルと日本テレビ
    • 都市全体をデザイン
    • 日本最大級の巡回デザインフェスティバルに

AI時代のデザイン・クリエイティブに求められるもの —デザインミュージアム設立の活動を通して実感すること

洪 恒夫さん(日本デザイン団体協議会(DOO) / 丹青社)
小松 尚平さん(デザインシップ / 東京大学)

  • 経済産業省の戦略的デザイン活用研究会
    • 競争力強化に向けた40の提言
    • その中にデザインミュージアム
  • 取り組み
    • 60年代と00年代の比較をテーマにした展示
    • ジャパンデザインのクロニクル
    • ジャパンデザインの本質をさぐるアナトミー
      • 時代背景としてデザインが求められてきた
    • 豊島区との連携事業
      • 芸術文化に力を入れている
      • その次はデザイン
      • デザインを語るシンポジウム
      • 池袋でデザインミュージアム
        • 街中にあるもののデザイン
  • デザインクリエイティブを推進するのに必要なナレッジ
    • ナレッジ・コモンズ
    • 定理知
      • 既知の事象
      • ストックされた知
      • 調べて分かること
      • 昔は図書館で調べてた
    • 適合知
      • 社会の中での新しい解決策
      • 定理知を加工して作る
    • 改革知
      • 改善ではなく本質的に変える
      • 認識していなかった事象や技術
    • 人の改革知とAIの定理知/適合知

「フロントエンドカンファレンス東京✕Vue Fes Japan✕JSConf JPコラボイベント」に参加してきました

Vue Fes Japan 2026の見どころ紹介

kazuponさん(PLAID)

  • 去年は800名規模
  • 去年はEvanとDanとDominikgのパネルディスカッション
  • 今年も海外からゲストが来てパネルディスカッション
    • JavaScriptエコシステムの境界線を問い直す
    • サーバーサイドフレームワークの未来を語る
  • chibivueのハンズオン

JSConf JP 2026の見どころ紹介

古川陽介さん(一般社団法人Japan Node.js Association)

  • 原点回帰とセキュリティがテーマ
    • 言語そのものや実行エンジン
  • Brendan Eichが登壇
    • JavaScriptは1995年に10日で作った
    • JavaScriptを作った人
    • JavaScriptができた背景など話してくれる

フロントエンドカンファレンス東京2026 見どころ紹介

did0esさん(CyberAgent.)

  • 今年は半分が招待講演
    • 去年は全部公募だった
    • Web標準
    • デザイナーが3,4割
    • 2部屋のうち片方がデザイン寄り

Vue Fes Japan の“作る側”に関わってみて

naokihabaさん(ANDPAD)
https://speakerdeck.com/naokihaba/vue-fes-japan-no-tsukuru-gawa-ni-kakawa-te-mi-te

  • Vue Fes Japanは今年で9周年
  • 外の世界とのつながりを大事に

見出しとは何か

ken7253さん

  • h1-h6タグの見出しが文章をグルーピングする
  • コンポーネント化
    • Headingとか作りがち
    • Sectionにtitleのpropsを渡す方がメンタルモデルとしてはよい

大規模フロントエンド開発におけるmonorepoという選択肢

ryomaejiiさん(株式会社リクルート)

  • 複数リポジトリで共通部分も別で管理してた
    • 共通部分がなかなか活用できない
    • モノレポに移行した
  • モノレポだと
    • 品質改善が全リポジトリに波及する
    • 案件を移動しても知識が活用できる

インフラエンジニアがNode.jsのホスティングサービスを作った話

ryuchさん

  • JSのアプリをホスティングしたい
  • npm installやnpm run buildは任意スクリプトの実行もある
  • 隔離された環境での実行が必要

contenteditable と日本語入力に向き合う

takiさん(GMOペパボ株式会社)
https://speakerdeck.com/colorful12/contenteditable-to-nihongo-nyuuryoku-ni-mukiau

  • WYSISYGを作った
    • inputやtextareaで作ると編集とプレビューで出し分けないといけない
    • contenteditable属性をつけると表示だけの要素も編集できるようになる
  • contenteditable
    • 改行するとdivとbrになったり
    • ブラウザによって挙動が違ったり
    • 改行の操作に介入してJSで処理
    • エンターの検知だと日本語変換でうまくいかない
    • 変換中は動かさないようにしてもSafariだと上手くいかなかったり
    • contenteditable="plaintext-only" で改行文字が入らないようにできるが完璧ではない

フレームワークが違うと、ミドルウェアの扱い方が全然違った話

takumibvさん(株式会社Gaji-Labo)
https://speakerdeck.com/takumibv/furemu-waku-ga-kawaru-to-midoru-wea-no-yakuwari-ga-zenzen-chigata-hanashi

  • サーバ側でリクエストに介入する処理
  • React Router
    • データ取得をloaderだと共有ができない
    • middlewareでやると1回で済む
  • Nextのproxy
    • アプリ全体で単一の介入
    • 薄く使うような思想

Nuxtカスタムディレクティブにより堅牢な権限管理を実現する

karacoroさん(株式会社LIXIL)
https://tsukuha.github.io/v_tokyo_fec_collaboration/1

  • ロールの判定を効率よく堅牢に書きたい
  • 権限管理の種類
    • RBAC
    • ABBAC
    • RuBAC
    • ACL
  • カスタムディレクティブでの制御
    • v-permission みたいなのを作って :edit.hide="admin" みたいに設定
    • pluginsに処理の実態を置く
      • 実行タイミングを制御
      • 判定のロジック

「チームを強くするAI駆動開発 - AIDD Meetup」に参加してきました

各社セッション

スキルを作る、その前に!複数人で使われるスキルを作るためのプロセス

ふるじゅんさん(合同会社DMM.com)
https://speakerdeck.com/junkifurukawa/sukiru-o-tsukuru-sono-mae-ni-fukusuujin-de-tsukawareru-sukiru-o-tsukuru-tame-no-purosesu

  • AXグループ
    • 横断的なAI推進のチーム
  • 組織でスキルを作ってみて
    • なかなか使われない
    • 複数人で改善する体制にもならない
    • 自分が使いやすいのと継続して使われるのは違う
  • AIへの投資の成果を可視化するスキル
    • AIコストを成果として説明していく流れ
    • 視覚的にわかりやすく整理する
  • イシューから始める
    • AXグループとして何をするべきかから
    • 課題の整理
    • 全体像の理解
  • 利用者によって重視する方向性が違う
  • 改善を続けるための仕組み
    • スキルの品質は一定で高止まってその後は落ちる危険がある
    • 点数つけて定量評価
    • 複製してバージョン付けして使えるように

3つのアプローチで目指す チームを強くする AI駆動開発

高橋 利明さん(株式会社Gaji-Labo)

  • AI駆動開発のハードル
    • 個人から組織
    • 職能を跨いだフロー
    • 企画や検証フェーズから
  • Issue駆動開発
    • 指示や受け入れ条件をIssueにかく
      • チームでレビューして改善する
      • 個人のローカルではなくIssueに残る
    • Issueドリブンで開発
    • 結果を付き合わせる
  • デザインハーネス
    • 職能を横断したAI活用
    • Storybookを正としてコンポーネントを整備
      • エンジニアとデザイナーが共通してさわる
      • それ以外の職種も
  • AI-DLC
    • 今後検討
    • そのままではなく世界観を

AI駆動開発、viviONの1年 ー うまくいったこと・いかなかったこと

本田 大悟さん(株式会社viviON)
https://speakerdeck.com/vivion/ai-kudou-kaihatsu-vivion-no-1-toshi-umaku-ita-koto-ikanakata-koto

  • 横断プロジェクト
    • 2025年10月〜2026年3月
    • 全員が兼務でAIを推進するプロジェクト
    • 各チームから有志で
    • SDDの標準ワークフロー整備
    • 社内に浸透させることはできた
    • 大多数のチームはお試し止まりで根付かなかった
      • 兼務ゆえの限界
      • AIエージェントの過渡期
  • 専任チーム
    • 2026年4月〜
    • AI駆動開発の浸透を専任とするチーム
    • AIを中心にフローを整備
      • AIの力を人が制限することがないように
      • 職能の中に閉じ込めない
    • meta repo構成
      • フロントもバックエンドも混ざったモノレポ
      • その中にAI向けのファイルも置く
    • ハーネスの作成
      • 整備ではなく蒸留
      • 1タスクの完全自動化で終わってしまう
      • 動かして失敗を見て人間がフィードバックしやりたいことに導く

パネルディスカッション

本田 大悟さん(株式会社viviON)
高橋 利明さん(株式会社Gaji-Labo)
ふるじゅんさん(合同会社DMM.com)

  • AI駆動開発の数値を取って分析しても傾向が全然違う
    • チームによって開発スタイルが違う
    • ツールの使い方
    • コミットやプルリクのルール
  • AIを使えるような整備から
    • 何を整備すべきかの言語化
    • 整備してるだけだと成果はでない
  • AIの外側にボトルネック
  • 機敏に動くキャッチアップの早い人を追う人が必要
    • 置いてきぼりで情報格差が発生しないように
    • チームに還元できる仕組み
  • ハーネスは横断で共有できるのか
    • チームごとに変わってくるところは多い
      • 共通化することで動きにくくなるところ
    • 開発のプロセスを標準化してから
      • 土台を作ってチームに持っていってそれぞれカスタマイズしてもらう
      • 社内規程に近いレベル感
    • ハーネスを作るためのメタハーネス
    • ハーネスは薄く捨てやすいほうがいい
      • 素早くハーネスを作れる仕組みを

「DeNA × AI Talks #9 LLMとどこまで付き合ったか」に参加してきました

GPU不要!SLM・BERTによる音声対話向け高速ターン検出モデル

yuto.satoさん(DeNA)

  • ターン検出器
    • 複数のLLMをフェーズごとに使い分ける
    • 音声を受け取って応答を生成して音声を合成する
    • いつ応答するべきか判定するのがターン検出器
      • 人間が喋ってる時に話しちゃったりしないように
  • VAD
    • 無音期間を検出するモデル
    • そのままだと言い淀みとかで応答してしまう
    • なのでターン検出モデルが必要
  • ターン検出モデル
    • 日本語だと低コストに使えるものがない
      • 重くてGPU必須
      • 軽量だと品質が安定しない
    • クローズドモデルはレイテンシに課題
    • 自前で作るにも日本語のデータが足りない
  • テキストベースの判定器
    • リアルタイムの文字起こしで判定する
    • テキストベースだけだと課題もある
      • 言い切る場合と続きを考えてる時がおなじになってしまう
    • 音声無しでテキストだけで学習データが作れる
    • Qwen
      • 全語彙の予測から終端トークンを判定
    • BERT
      • 先頭の512次元表現を全結合
    • 学習済みモデルをONNXに変換
  • 評価
    • 誤終了率
    • 平均速度

そのライブラリ、モデルと相性いいですか?

tomoki.yoshidaさん(DeNA)

  • 構造化出力のストリーミング
    • フィールド単位じゃなくてフィールド内でもストリーミングしたい
    • ライブラリを使うと単位が荒かったりする
    • 自分でパースする方が細かく出力できていい
    • かっこが閉じられていない不完全なJSONをパースする関数がLangChainにある
      • geminiとは相性が悪い

QA領域でのLLM活用:確認を楽にする工夫と利用データの活かし方

yuki.sugawaraさん(DeNA)
atsuhiro.matsuyamaさん(DeNA)

  • DeNA AI Advanced Quality(DAAQ)
    • 内製の品質チェックツール
  • QAの難しさ
    • 仕様書からテスト項目を設計
      • 仕様全体の把握が大変
    • テストを実装し実行
      • テスト設計のスキルが人に依存
  • DAAQによる支援
    • 仕様書からテスト項目表を生成
    • テストを自動実行してエビデンスの取得まで
    • テスト項目表の質が要
  • DAAQの仕組み
    • 柔軟な入力の受け取り
      • さまざまなフォーマットや形式
      • プロジェクトごとに必要なコンバーターを用意する
      • プロジェクトの差分をできるだけ上流で吸収
    • LLMに頼りすぎない
      • 機械的にチェックできるところはそっちでやる
    • テスト生成のステップ
      • 要件整理 - テスト分析 - テスト設計 - 検証手順生成
      • 各工程のアウトプットを人がレビュー
  • 表示テストの生成
    • 画面に表示された文字やUIの崩れを確認するテスト
    • FigmaなどからUI要素の種別や位置や文言を抽出
      • 位置検出は100%LLMで
    • UI要素ごとにテスト観点を考え組み立て
    • テストそのものの評価
      • 正解データを持って自動で評価できる仕組み
      • どういう単位で要素を捉えるかのブレ
      • 要素検出の出力に座標も追加

スマホ操作をLLMに任せよう

yuta.sugafujiさん(DeNA)

  • スマホアプリを動かして確認する
    • バージョンが増えるほど確認の回数が多い
      • 更新が多いアプリは月に数十本
    • 人手の負荷が非常に高い
  • AIにスマホ操作させる
    • 単発操作はやれる
      • 長いシナリオを操作し評価させるのは難しい
      • スクロールしないと出てこないもの
      • 戻った時に元の画面ではなく別画面と認識してしまう
  • AIによる操作の仕組み
    • 人間の操作ログを貯める
    • ログから台本を作ってシナリオを作る
      • ここだけAIを使う
    • あとは台本通りに操作させる
      • 座標も決まってるから決められたとおりにやるだけ
    • AIを中心に置かない
  • 技術的な工夫
    • 過去の操作をそのまま再現できないことも
      • タイミングによって表示要素が変わってずれるとか
      • 過去の知見が活きない場面
    • LLMに座標を書かせない
      • バウンディングボックスを作ってマーキングして判断する
      • 画像認識だけで判別できる
    • タップミスの抑制
      • 押す前に照準を重ねた画像で確かめる
      • ズレがあったら指摘してから押すようにする
    • 毎回違う画面をどう吸収するか
      • スリープを入れたり
      • 入口と出口を設定して中間はフレキシブルに
      • 2問に分けて処理が終わった後のサインを掴めるように
    • AIを使わなくていいものは使わない
      • 計算と検算
      • DOMや通信結果が取れる時はそれを活用

「Featured Projects 2026 (Day3)」に参加してきました

"真ん中"以外の選択肢、ローカルにひらくものづくりの場と仕事

川口貴之さん(Staple)
加藤駿介さん(NOTA&design)
水島七恵さん

  • なぜ真ん中以外に場をつくるのか
    • 2009年頃までは東京が真ん中
    • メディアが普及し始めて変わってきた
    • コロナ禍でバラけてきた
  • コンテキストのないプロダクト
    • 偶発性から生まれるもの
    • コンテキストを練りすぎると似たものができてしまう
    • 場があることで偶発性が生まれる
  • コントロールできないところにゆだねる
    • 焼き物は最後はゆだねるしかない
    • ホテルの運営を現場にゆだねる
    • あえて言語化せずに創造性に任せる
  • 都市部が同一化してきてる
    • 同じようなものばかりある
    • マーケティングとかターゲットを考えたものしかない
    • 都市部が落ちてることでローカルに流れてきてる
    • ローカルの方がそこにあってほしいものを作れる
      • そこにいる人の顔が見えること

三世代のグラフィックデザイン──引き継ぐもの、変えていくもの、その間

田中義久さん(centre)
竹田美織さん(LAND OF LAVA)
山口日和さん
川上 典李子さん(21_21 DESIGN SIGHT)

  • 自分のデザイン表現
    • 自分にできることをやるという姿勢
    • いいと思っていなくても受け入れられるものもある
  • 次の時代へ手渡す
    • 失敗が個性の一部になっていくこと
      • AIがあることで間違えることが難しくなってる
    • 上から受け取ったものを下に渡していくだけではない
      • 下から学ぶことも多くある
  • グラフィックデザイナーとして期待されること
    • 問い自体を考え直すところから
      • 泥臭く時間をかけてやる仕事
      • できあがったものだけを見てるとインスタントに感じる
    • クライアントの意向がないとデザインはできない
      • 理解できるまで話をする
      • 理解できなかったら仕事を受けない

哲学対話:ものがうまれる、その「間」

山田紗子さん(山田紗子建築設計事務所)
嶌村 吉祥丸さん(写真家)
藍 にいなさん(ソニーミュージックエンタテインメント)
松永昂史さん(WOW inc.)
片栁 那奈子さん

  • いいものが生まれるまで
    • 時間をかけるほどいいのか
    • ゾーンに入ってる状態
      • 具現化するのに時間がかかる場合
    • 創造にかけるエネルギーを継続できる期間には限界がある
    • イメージしてから着地までの変化
      • どこに表現するのかで変わる
  • 制作物の正しさ
    • 写真や映像など正解がないもの
    • 大学で講評されてもその場で腑に落ちるのは難しい
    • 過去のキャンセル
      • 蓄積された経験を見直して問い直していく
    • 蓄積しすぎたノウハウがない方がいい発想につながることも
  • アイデアの創出
    • 考えながら物理的に作っていくのを同時にやれること
      • 建築で模型を作りながら考えると違う
    • 3Dでイメージを作ってから作成
      • 実物を見るとなんか違うという感覚
    • カメラを通してみたものと写真のずれ
    • イメージと実物のずれが大事
  • 完成するタイミング
    • 締め切りなど決まった時間が来た時
    • 強制的に完成が来る時
    • 完成したものの説明を求められて考えている時

「Platform Engineering Kaigi 2026」に参加してきました

全社員がAIを「使う」の次へ ── ノンエンジニア1,500人が安全に業務を作り変えるゴールデンパスとガードレール

河野智則さん(株式会社リンクアンドモチベーション)
https://speakerdeck.com/lmi/pek2026-link-and-motivation

  • 非エンジニアもAI活用
    • 1500人
    • 社内のAIツール3000個
    • 誰でも作れるかつ安全に
  • AIツールを配るだけでは使われない
    • 配って研修をやってもなかなか使われない
      • 活用できる業務がわからない
      • 指示の出し方がわからない
  • AIを浸透させるために
    • 特定の部門から
      • 深く狭く成功体験を
    • トップダウンで目標とつながるように
      • リターンとセットで部門のトップに伝える
    • AX推進者のアサイン
      • AIスキルよりも広めていくスキル
    • 座学から伴走へ
      • 習慣として定着させる
  • 成果につなげるために
    • 成果の指標をアウトカムマップで
      • 先行指標 - 遅行指標 - インパクト
      • 観測してモニタリング
  • 非エンジニアによる開発
    • 想定してないツールを使われてしまう
    • 危険な操作をapproveしてしまう
  • ガードレール
    • 活用レベルで配布するツールを分ける
      • 非エンジニア向けのorgを作って分けてる
    • ノーコード
      • Claude Cowork
        • Claude Codeまで不要なケースが多い
        • Coworkの方が安全
      • Gemini
    • ローコード
      • Dify
      • n8n
    • プロコード
      • Claude Code
  • AIセキュリティチーム
    • 開発部門
    • 情シス
    • 法務
  • ゴールデンパス
    • 学ぶ機会がないまま突然作れるようになってしまっている
      • リターンよりリスクが勝ってしまう危険性
    • ゴールデンパスの整備
      • 開発標準手順
      • フィットジャーニー
      1. CPF
      2. 課題特定
      1. PSF/SPF
      2. 価値検証
      3. セキュリティやコストのチェックなども
      1. PMF
      2. 浸透
      3. 使われているかログでチェック
      1. GTM
      2. 他部署展開
    • 作っても使われないツールは量産させない

AI Slopを生まないPlatform Service設計:価値仮説と効果測定ってどうやるの?

木嶋幸子さん(レッドハット)
https://speakerdeck.com/skijima404/ai-slop-o-umanai-platform-service-sekkei

  • AI Slop
    • AIによる低品質な成果物
    • 人の目によるチェックに時間がかかってむしろコスト増に
    • 受け手がそう感じたら信用が落ちてしまう
  • 成果物やサービスの渡し手と受け手
    • 期待値があっているかどうかが大切
    • 価値が高くて負荷が低いちょうどいい状態を目指したい
    • これがずれるとAI Slopと受け取られてしまうことも
  • Value Streamのマネジメント
    • 企画から運用まで全体を通した効率を見る
    • Value Stream Mappingで現状の可視化
      • リードタイムとプロセスタイム

開発者とSREが同じ仕組みを使う、ローカルに閉じない自律AIエージェントのつくり方

安部 修平さん(ウェルスナビ株式会社)
https://www.docswell.com/s/WN_Tech-PR/ZY8QXP-2026-09-07-111839

  • 開発者向けのAIエージェント
    • slackで質問や依頼をして使う
    • DatadogやAWSやGitHubなどにつながる
    • 修正が必要ならプルリク作ってくれる
  • エージェント作成の背景
    • 開発者からSREチームへの問い合わせが多く発生していた
      • 定型的な質問や調査も多くあった
    • チケットを切って対応してとなるので待ち時間が発生してしまっていた
  • Slackボット
    • メンションするだけで使える
    • やりとりがスレッドに残る
    • 最初はSRE内部でのナレッジ検索ボットとしてスタート
  • 技術構成
    • EKS上でエージェントを動作
      • Claude Agent SDK
      • Socket ModeでSlackと連携
    • BedrockのClaude
    • AgentCore Memory
    • MCPでNotionやGitHubやDatadog
    • AWS DevOps Agentも
  • やりとりの仕組み
    • スレッドの内容を踏まえて作業を始める
    • アラートをトリガーに動かすケースも
    • Skillは独自で作ってリポジトリ管理
      • プルリク作成
      • ナレッジ検索
      • 問題調査
  • AWS DevOps Agent
    • 本番用とそれ以外でAgent Spaceを分け必要な方をエージェントから呼ぶ
  • Bedrock AgentCore Memory
    • エージェント向けの長期記憶
    • スレッドをまたいで共有できる
    • 会話の要点を記録しておく
    • メモリだけを根拠としないように現在の情報もあわせて見る
  • Claude Agent SDK
    • 権限を制御しできる操作を絞りたい
    • 入出力のマスクなど制御やログの記録をしたい
    • 外部エージェントを状況に応じて呼び分けたい
  • AIエージェントの安全性
    • 参照更新対象の制限
      • slackはpublicチャンネルのみ
    • 意図しない漏洩に備える
      • slack投稿前にマスキング処理
    • 外部通信の制限
      • 許可した接続先のみ許可
      • shellや任意のwebアクセスはそもそもtoolとして持たせない
  • エージェントの回答
    • 利用者が確認できるように
      • 事実と推測を分けて示す
      • 根拠となるリンクをつける
      • 確認できなかったことも書く
    • 処理中の表示と中断
      • 途中の処理状況を表示
      • 意図しない場合は止められるように
  • 動作状況のチェックと改善
    • Datadog Agent Observability
      • エラーの傾向
      • 処理時間
      • コスト
    • Datadog Dashboard
      • セッション数
      • skillごとの利用数
      • チームごとの利用数
    • エージェントが自律的に振り返りと改善

人にやさしく、AIにやさしく、書き手を選ばないIaCのガードレール再考

杉本 浩平さん(株式会社MIXI)
https://speakerdeck.com/kohbis/rethinking-iac-guardrails-for-humans-and-ai-alike

  • AIの登場での変化
    • コードの書き手が変わった
      • IaCを書く負担を減らすための工夫をしてきた
      • 品質を守るということは変わらない
    • ルールやガイドラインの想定読者が変わった
      • AIも人間同様構造化した文章が読みやすい
      • 長い文章も文句言わずに読んでくれる
    • IaCを書く難しさが変わった
      • 表面的な難しさはなくなった
      • 抜けや漏れは発生する
    • プラットフォームがやるべきこと
      • 品質の下限を揃えて下振れを防ぐ
  • プラットフォームエンジニアリングの役割
    • ゴールデンパス
      • 標準の提供
    • ガードレール
      • ルールから外れないように
    • セルフサービス
      • 利用者が変更や改善をできる
    • 認知負荷の軽減
      • ルールを覚える必要がない
    • シフトダウン
      • ルールを守る責任をプラットフォーム側へ
  • IaCのレビュー
    • これまでは機械的チェックはCIがそれ以外は人間が
      • AIに移行させていく
    • レビューの観点
      • 下限を守っているか
        • ポリシーテスト
      • ガイドラインの遵守
        • AI向けドキュメント
      • 高い品質を目指す
        • 人間がやる
  • 同じものが同じように適用されるようにしたい
    • 書き手にかかわらず同じチェックを
      • 認証や権限に依存しないように
    • 読めるドキュメントを揃える
      • 人間もAIも
    • プラットフォームが提供する情報にエラーケースも含める
      • 失敗の原因から次のアクションを判断できるように
  • どのレイヤーで守るか
    • Lint
      • Lintエラーやformat自動修正
    • CI
      • ポリシーテスト
    • レビュー
      • AIや人のチェック
  • 例外許容のリスト
    • 既存のコードでルール違反なものがあるケース
    • リストで管理し例外扱いできるように
    • ルールが追加された以降に作成するものはルールを守るように
    • 既存のものは影響を与えないように

ソニーのクラウド共通基盤の変遷とAI時代の開発スタイルに合わせた進化

米山兼治さん(ソニー株式会社)

  • ハードウェア機器に付加価値を提供するソフトウェア
    • 横断的なクラウドやデータやAIの共通基盤で管理
  • サービス継続の民主化とビジネス継続性の民主化
  • 民主化により開発チームの自由度が上がった
    • コスト観点を意識せずにUXを追求してしまうことも
      • アプリ通知のドットを出すために大量のサーバリクエストが発生するようになったり
      • コスト管理も民主化したい
    • 異なるデバイスでGraphQLを共有していた
      • Device というプロパティがあっても使い手によって全然別物
      • どこかで標準化の整備をしないといけない
  • コーディングエージェント
    • コストレポートを確認できる状態で公開
      • Bedrock
      • Budgets -> SNS -> teamsへ通知
    • コストアラートも
  • AI開発向けのSandbox環境
    • 無邪気にvibe codingできる環境
      • 小規模なチームが気軽にクラウドで実験する受け皿
      • 動くものを早く試せる
      • 学習のための動作確認
    • Innovation Sandbox on AWSとAWS Service Catalogでセルフサービスコンソール
    • AWSアカウント自体を使い捨てできる
      • ハンズオンで使い捨てで立てるようなやつに近い
    • コスト上限に到達したらアカウント凍結

AIエージェント時代のPlatform as a Product —— テックリードがPdMとして回す発見・導入・計測

杉田寿憲さん(株式会社LegalOn Technologies)
https://speakerdeck.com/toshi0607/platform-as-a-product-in-the-ai-agent-era

  • 複数プロダクトを支えるプラットフォーム
    • エンタープライズ向けのアプリ
    • 他国へ展開するアプリ
  • プラットフォームとして何をするかの判断
    • 誰のどの課題を解くか
    • 日々の作業で使われるか
    • 何を計測して次につなげるか
    • Discovery - Delivery - Enabling - Measurement

インフラとアプリの境界線と委譲の設計

鈴木勝史さん(株式会社スリーシェイク)

  • インフラとアプリの境界
    • 全部インフラが持つと安全重視にできるが開発が止まる
    • 全部アプリが持つと速いけど野良運用が広まってしまう
  • 境界
    • 機能の境界
      • プロビジョニング
      • アプリのデプロイ
    • 役割の境界
      • プラットフォームチームと開発チーム
      • 共通プラットフォーム
  • 機能の境界
    • たとえばECSのタスク定義やCloud Runの設定
      • インフラで決めたいこととアプリで決めたいことがある
    • どこでインフラリソースを管理するか
      • Terraformで持つ
      • アプリが設定するところをignore_changesで除外しTerraformで管理しない
    • インフラとデプロイで分けると受け渡しが発生する
      • 名前で引いたり
      • Terraformでoutputを定義してそれを読んだり
      • JSONなどでストアに書き出してそれを読んだり
      • 手動で書き写したり
  • 役割の境界
    • ゴールデンパスの提供と利用
      • 標準から外れるケースは起こる
      • 外れる時にフルスクラッチになるのは極端すぎる
    • IaCをどこまで権限を渡すか
      • 書く権限だけ渡してレビューする
      • 適用まで権限を与える
      • 結果の責任はどっちが持つのか
    • IaCの習熟度と標準構成からの逸脱具合から個別判断
  • 機能と役割の連動
    • 片方の境界が動くともう片方も動く
    • チームやツールにも影響が出てくる

CI/CDではもう遅い - 人とAIが迂回しないDevSecOps Verify基盤の再設計 -

島村 純平さん(KINTOテクノロジーズ)
https://speakerdeck.com/kintotechdev/cd-deha-mou-osoi-hito-to-ai-ga-ukai-shinai-devsecops-verify-kiban-no-saisekkei

  • AIエージェントの普及でのCIの変化
    • プルリク数が30%増加
    • 標準RunnerだとWorkflowが詰まる
      • GitHubのorgで同時に60Workerまで
    • GitHub Actionsのコストがあがる
      • 呼び出しも実行時間も2倍
    • CIで動かしたいものが増えて待ち時間が長くなる
  • アプリデプロイまでの流れ
    • 従来
      • プルリクの段階でCIでチェックしたり人のレビューしたり
    • AI時代
      • プルリクを上げるまでのスピードが上がり回数も増えた
      • プルリク作成でのCIの待ちが長くて外したいという要望も出てくる
        • セキュリティスキャンや静的解析はコーディング時にAIでやってるからいいのでは?
  • AI駆動開発でのCIの再定義
    • やりたいこと
      • 速度を上げたい
        • CI待ちせずに開発端末でループを回したい
      • コストを削減したい
        • プルリクでのCIの実行回数削減
        • AIレビューでの既知ルールの分析トークン削減
      • 品質の担保
        • いままで完全に準拠しきれなかった既存ルールへの対応
    • 仕組みの整理
      • 静的解析
        • ベストプラクティスへの準拠
        • 重複やメンテナンス性
        • 既知の脆弱性パターン
        • 基本定額
      • 各種スキャン
        • 脆弱性/EOL/ライセンス
        • OSSもあるし安価
      • AIコードレビュー
        • ロジックやバグの確認
        • 改善提案
        • 従量課金が多い
      • より安価なやり方でチェックし後ろへ流す
        • ローカルでやれてることを前提に後段を軽くしていく
  • プラットフォームでの整備
    • hooksとskillsを整備し利用は任意
      • Plugin Repositoryで管理
      • フィードバックをベースに改善中
      • 開発に悪影響を与えないことを確認できるまでは任意
    • MCPの接続増によるトークンコストの増加対策
      • MCPを常時ONにすると消費が増えてしまう

プラットフォームの複雑性はどこに住むべきか - 認知負荷を吸収し、プロダクトをまたぐPR Preview基盤の設計事例

小野 大器さん(enechain)
https://speakerdeck.com/taiki45/ninchi-fuka-o-kyuushuu-shi-purodakuto-o-matagu-pr-preview-kiban-no-sekkei-jirei

LC4RIによる実行可能ドキュメントとナレッジ化の実践記(LLM時代のドキュメントプラットフォームの現在地)

加藤 泰隆さん(株式会社スリーシェイク)
https://www.docswell.com/s/ma_anago/ZJW12G-2026-09-26-130252

spanner-autoscalerに学ぶCRD設計パターン 〜自動化と緊急時対応を両立するKubernetesコントローラーの作り方〜

tkuchikiさん(株式会社メルペイ)
https://speakerdeck.com/tkuchiki/spanner-autoscaler-ni-manabu-crd-sekkei-patan-jidouka-to-kinkyuuji-taiou-o-ryouritsu-suru-kubernetes-kontorora-no-tsukurikata

AIに書かせて、プラットフォームで縛る ― EKSプラットフォームで実践した責任境界と権限設計

中井 綾一さん(株式会社ログラス)
https://speakerdeck.com/elmodev09/designing-responsibility-boundaries-and-authorization-on-the-eks-platform

そのTerraform、マージする前に本当に安全か分かっていますか ― AI時代のCI/CDに組み込むIaCセキュリティの実践

ハオさん(テナブルネットワークセキュリティジャパン)

AI Native Platform Engineering 〜PlatformとAgileで“作る速さ”を“価値”へ〜

三改木 裕矢さん(ソフトバンク株式会社)
河村 信宏さん(ソフトバンク株式会社)

3人で1000GPU超を統合運用する?マルチクラウド&オンプレを跨ぐ、構築と運用のリアル!

大戸 一希さん(Turing 株式会社)

半永久的に提供し続けられるプライベートクラウドを目指して ― 利用者の認知負荷を抑えるAPI抽象化とハードウェア世代交代の基盤設計

近藤 智文さん(株式会社サイバーエージェント)
長井 佑太さん(株式会社サイバーエージェント)
https://speakerdeck.com/tomokon/haneikyuuteki-ni-teikyou-shi-tsuzukerareru-o-mezashi-te-riyousha-no-ninchi-fuka-o-osaeru-api-chuushouka-to-hadowea-sedai-koutai-no-kiban-sekkei

Agentic Platform Engineering on AWS

小西 杏典さん(アマゾンウェブサービスジャパン合同会社)
松岡 雄地さん(アマゾンウェブサービスジャパン合同会社)
https://speakerdeck.com/matsyuj/agentic-platform-engineering-on-aws

セルフサービスのオブザーバビリティ基盤をOpenTelemetryで作る

山口能迪さん(Grafana Labs)
https://speakerdeck.com/ymotongpoo/observability-platform-with-otel

メルカリにおけるAI時代の高速プロトタイピング基盤「Arca」

荒井 良太さん(株式会社メルカリ)
https://speakerdeck.com/ryotarai/niokeru-ai-jidai-no-kousoku-kiban-arca

メルカリにおける AI エージェント時代の Platform API

azrshさん(株式会社メルカリ)
https://azr.sh/slides/platform-api-in-the-ai-agent-era-at-mercari

Argo CDとAtlantisで実現するインフラ管理のセルフサービス化──小規模SREチームで支えるプラットフォーム

角井 暖さん(株式会社アンドパッド)
https://speakerdeck.com/cassius7/platform-engineering-kaigi-2026

HolmesGPTで始めるSREエージェント入門!プラットフォームの障害調査はAIにお任せ〜

イ サンヒョックさん(レバレジーズ株式会社)
https://speakerdeck.com/sanghyuk/holmesgpt-de-hajimeru-sre-ejento-nyuumon-purattofomu-no-shougai-chousa-ha-ai-ni-omakase

プラットフォームを「作る」、チームに「入り込む」──両輪を支える「なぜやるのか」という問い

増田 圭佑さん(Sansan株式会社)
https://speakerdeck.com/sansantech/260926