「JAWS-UG横浜 #91 AWS re:Invent 2025 宇宙一早い re:Cap」に参加してきました

15分でわかる AWS DevOps Agent

新居田 晃史さん(JBCC)

  • Frontier Agent
    • 自律的かつ大規模でスケーラブルなAIエージェント
    • 3つ発表された
      • Kiro autonomous Agent
      • AWS Security Agent
      • AWS DevOps Agent
  • AWS DevOps Agent
    • システム運用や障害対応を自動化してくれる
      • 24時間稼働してくれるDevOpsエンジニア
    • o11yツールやGitHubと連携できる
    • 特定のタグを付けておくとそれを検出対象にできる
    • システム間の連携どう見えてるか可視化してくれてる

今年のイケてるサービス

大栗 宗さん

  • AWS Interconnect - Multicloud
  • これまではGoogle Cloudは対応しててAWS側はDirect Connectが必要だった
    • 数週間かかってた
    • それが数分になる
  • 2箇所の施設で合計4重化
    • SLA99.99%
  • 論理接続を切り替えて- スケールアップ/ダウンが可能
  • Googleの人が一緒に登壇した
    • AWSGoogleがパートナーシップを結んだ
  • Auroraの話
    • Limtless Databaseの話がなかった
    • 厳しいサービスだった
  • AWS Graviton5
  • Nitro Isolation Engine
    • Graviton5から使われてる
    • 区画化/形式検証/透明性

S# Access PointsのAmazon FSx for NetAoo ONTAPサポートの宇宙いち早い、詳しい解説 〜Keynoteでの発表までの裏話と、この機能の何が嬉しいのか〜

藤原 善基さん

  • Keynote
    • AIの話が続く
    • 最後の10分で25の新機能を紹介した
    • ONTAPにあるデータをシームレスにS3にあるかのように扱える
      • S3にコピーしないで使える
  • ONTAPのデータをもっと連携したい
    • S3として扱えればあいろんな連携ができる
  • ニアリアルタイムでS3互換
  • AI/ML/Analyticsサービスとの連携
  • ファイルとオブジェクトストレージとしてのアクセス両方可能

初めてのre:Invent!人生変わった!?

Hirota Koudaiさん(ウフル)

  • 変わるきっかけになるか
    • これから次第
    • 登壇などでアウトプットしたり
    • 仕事で活かしたり
  • 海外で何があるか分からないので体調管理大事

初参加でレベル500のセッションに参加しました、、、

Takumi Aoyagiさん(三菱電機)

  • レベル500セッション
    • 最高レベルのセッション
    • 先端研究や理論的な基盤
    • 理論と実装を結びつけた高度なアーキテクチャ

re:Invent 初参加で学んだこと

Masataka Kuboさん

  • 新たなネットワーキング構築
    • 日本で交流がある人をつてに拡大
    • 自分と同じ会社の人を紹介
  • スピード感のあるアウトプット
  • 5k race

re:Inventを写真で雑に振り返る

Yuji Oshimaさん

  • 時間には余裕を持って行った方がいい
    • 飛行機もバスも

DevOps Agent vs CloudWatch Investigations -比較と実践-

Shintaro Fukatsuさん

  • どちらも生成AIが解析し根本原因を示す
  • DevOps AgentはリポジトリSaaSなど横断して学習してくれる
  • CloudWatch Investigationsは調査の補助
    • 原因の特定はできても変更の契機はできない
    • ポストモーテムまで作成してくれるのは便利

CBとして行く、初めてのreinvent

Haruki Fukuchiさん(NEXソリューションイノベータ)
https://speakerdeck.com/har1101/cbtositexing-kuchu-re-invent-tiao-zhan-toshi-bai

  • Community Buildeersが集まる交流
    • 現地の人とディスカッションしたい

#kwntravel 2025活動報告〜LEARNINGS IS SOCIAL〜

Shinichiro Kawanoさん

地方とエンジニアとPolymath

あべたくさん(KDDIアジャイル開発センター)

  • Deep Domain/Broad in Understanding
    • T型人材
    • 特定ドメインを深く理解
    • 別のドメインへ適応していく
    • そこから新しい知識を得る
    • 適応できる範囲を広げていくのが大切

「アクセシビリティカンファレンス福岡2025」に参加してきました

アクセシビリティでつながるせかい

岡上 洋子さん

  • サニーバンク
  • 障害者と一緒に働く
    • 基本リモートで非同期に
  • 困ること
    • クライアントからもらった資料がスクリーンリーダーで読めない
    • 求められるツールが使えない/使いづらい
  • 気をつけていること
    • テキストが理解しやすい人や口頭が嬉しい人
    • オンライン会議
      • カメラはonでもoffでも
      • 長時間姿勢を保ってなくてもいいように楽な体制で
      • 声で話してもチャットでもOK
  • 障害のある人に意見を聞いたり話をする
    • 想定してないニーズや課題に気づかせてくれる
    • すごく困ってる人の意見を聞くと少し困ってる人の役にも立つ
    • 意見をどう活かしていくか
      • たくさんの属性の人にきく
      • 専門家や経験豊富な人

Yahoo! JAPANトップページ〜アクセシビリティのせかいをつなぐ〜

最強のおもてなし

グリズデイル・バリージョシュアさん

  • 脳性麻痺
    • 脳のダメージ
    • 症状は人それぞれ
    • ジョッシュさんは両手と両足
    • 電動車椅子を使っている
  • 日常生活
    • ヘルパーさん
    • 交通
      • 乗りたくてもすぐ乗れなかったり
    • レストラン
      • 段差があったり狭くて入れないようなお店
    • 旅行
      • 事前にチェックしないといけない
  • 多数派の世界
    • 例えば右利き用の机や駅の改札
    • 多数派に向けて作られているものが多い
  • 日本のユニバーサルツーリズム
    • 電車でスロープで車椅子でも乗れる
    • 点字ブロック
      • 日本が発祥
    • 車椅子用トイレ
    • 車椅子でも入れる温泉
    • 観光スポットもスロープやエレベーターが多い
    • ビーチを車椅子で歩けるマット
    • 人力車に車椅子の人でも乗れる
  • イメージの問題
    • バリアフリーになっているとイメージがつかない場所もある
    • ホームページなどでしっかりアピールするといい
  • インフラの問題
    • 最初からバリアフリーを意識した設計に
    • 後からつけると無理やりになってしまう

アクセシビリティ推進という山登りを支える――理念を道しるべに

宮本 采佳さん

  • アクセシビリティ向上
  • アクセシビリティ推進
    • 取り組み続けられる状態や文化を作ること
  • 推進の取り組み例
    • 既存のサービスを調査
      • 現状の課題や改善案をまとめる
    • 取り組むための情報整理
      • どうやって取り組んでいくか計画書
    • ガイドライン作成
      • WCAGを分かりやすく説明したり例示を用意したり

東急・東急電鉄アクセシビリティへの取り組みについて

  • URBAN HACKS
    • 東急の内製開発組織
    • まちづくりDX
  • アクセシビリティの取り組み
    • 社内での勉強会
    • カンファレンスの合同オンライン視聴
    • デザインシステムの構築
  • 東急電鉄バリアフリー
    • すべてのお客さまが利用しやすい鉄道
    • 駅施設の改善
      • ホームドア/センサー
      • 点字運賃表
    • 社内の改善
      • 2016年以上の車両はフリースペースがある
      • 乗降の段差隙間解消
    • 係員教育
      • 接客サービス選手権
  • 東急・東急電鉄公式サイト
  • リアルとデジタルをつなぎ一気通貫な体験

WCAGと先行する海外からの学びを実践につなげる

植木 真さん

  • WCAG
    • WCAG -> ISO -> JIS
    • 日本語特有の基準をWCAGに入れられるの
      • 他国でも同じような課題はあった
        • 「日時」を「日 時」と書くとか
      • WCAG2.0には日本から提案したものも追加された
      • もともとのJISの基準が抜け落ちることはなく改定できた
    • ウェブアクセシビリティ基盤委員会
  • WCAG3.0
    • 現在検討中
    • 2030年が目標
    • WCAGをゼロから作り直す
    • Webだけでなくデジタルコンテンツ全般に
      • W3c Accessibility Guidelines
    • AGWG
      • Accessibility Guideline Working Group
      • 毎週定例が行われて議論している
      • 8つのサブグループ
    • 現行は難しくて取り組むハードルをあげてしまう
      • 読みやすくて取りかかりやすいようにすることを目指してる
  • アクセシビリティに取り組む人がバーンアウトしないように
    • シフトレフト
      • 早い段階から取り組めるように
    • 相談フロー
      • 個人に集中しないように
      • Intakeフォームを用意する
    • デザインシステム
    • 伴走型のQA
      • 対立構造ではなく協業へ
      • ダメ出しをするだけでなく一緒に考える
    • 当事者参加
      • 当事者レビューをしてもらうことで何のためにやるかたち戻れる
    • ハームリダクション
      • ユーザにとって影響が大きいところから取り組む
      • 完璧主義を捨てる
  • ユーザのトラウマを考慮したデザイン
    • 安全性
    • 信頼と透明性
    • 選択肢と主導権
    • 協働
    • エンパワーメント
    • ->これらはユーザ向けだけでなくアクセシビリティに取り組む人にも当てはまる
  • Progress Over Perfection
    • 完璧よりも前進を

「2025年総決算!エンジニアリングマネージャーお悩み相談室 LIVE」に参加してきました

パネルディスカッション ー お悩み相談室 LIVE

Makoto Arataさん(LayerX)
Odanaka Ikuoさん(カケハシ)
Mitani Shoheiさん(スマートバンク)
miisanさん(令和トラベル)

  • どうやってできることを増やしていくか
    • マネージャーがスーパーマンじゃないといけないと思ってしまう
      • 自分自身も周囲も
      • 分解していった時に誰でもできることも出てくる
    • 前任者を見てハードル高く感じてしまうこと
      • EMの領域が広いからその人のやってることが全てではない
      • 組織の中で穴があいてるところに飛び込んでいく
    • 分からないということを自覚して学んでいく
    • コミュニティの中での知見の共有
  • メンバーのスキルや知見の方がマネージャーより上回ってる場合の成長支援
    • 障壁になっているところを取り除く
      • 全力で走れる環境を作る
      • 問題設定をしっかりしてあげる
    • どう評価するか
      • どのように組織に貢献してほしいか
    • 自分よりスキルが低い人しかいなかったら全部自分がやった方がいいとなってしまう
    • 評価をする期待値の設定
      • グレードの定義など等級があがるほど抽象的
      • 具体的すぎてもそれをする環境が整ってないこともある
  • マネージャーにとってメンバーがやってくれると嬉しいこと
    • 自分がチームに対してどういう影響を及ぼしたいか
    • コーチされる状態
      • 否定されてるわけではないという心持ち
    • willがある人の方が後押ししやすい
    • willがない段階もあるのが普通
      • 目の前のことをまずはしっかりと
  • EMやってて自分が成果を出しているのかと思うこと
    • マネージャーは時間軸が長い
      • エンジニアの方が成果を出すまでの時間が短い
    • 自分がやるべきじゃないことをあえて手放す
    • それをやらなかったらどうなっているか
      • 実は意味があることかもしれない
    • チームと同じ目標を持って退路を断つ
      • 自分はメンバーじゃないけどチームの成果に責任を持つ

2025年11月に読んだ本

  • 2025年11月に読んだ本の記録です
  • 今月は資格の本含めて2冊
  • 資格の勉強に時間を費やしてるので少なめ

ソフトウェアテスト技法練習帳

gihyo.jp

  • QA/テスト界隈のコミュニティでよく紹介されるので買ってみた本
  • 読み物というよりは問題集
  • 解説を通して技法を学べるので読み進めやすいし実践向けの訓練にもなった

AWS認定資格試験テキストAWS認定AIプラクティショナー

https://www.sbcr.jp/product/4815631505/www.sbcr.jp

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

- 2025/11/30

なぜフロントエンド技術を追うのか?なぜカンファレンスに参加するのか?

sakitoさん(サイボウズ)
https://speakerdeck.com/sakito/nazehurontoendoji-shu-wozhui-unoka-nazekanhuarensunican-jia-surunoka

なぜフロントエンド技術を追うのか

  • 流行を追うのは疲れる
  • 技術を点でなく線で追う
    • 流れを追う
  • ビルドツールの流れの例
    • バンドラーなしの時代
    • Grunt/Gulp/Browserify
    • Webpack/Rollup/Parcel
    • Vite
    • Bun/Turbopack/Rspack
  • エコシステムからWeb標準
    • エコシステムで作られる -> Web標準へ -> エコシステムでそれを使う
      • Web標準を考えてる人たちはエコシステムのことをよく見ている
    • JS0/JSSugar
    • ランタイム側に取り込まれていく流れが進んでる
      • 実装が膨らんでセキュリティの問題が起きたりも
      • 取り込んでいく流れに限界が
    • ランタイムとエコシステムの役割分担の流れ

なぜカンファレンスに参加するのか

  • 記事で得られる情報との違い
    • 現場で使った生の体験を聞ける
    • 疑問に感じたことを直接聞ける
  • カンファレンスは全員が共通の話題を持ってる

俺流レスポンシブコーディング 2025

TAKさん
https://speakerdeck.com/tak_dcxi/an-liu-resuponsibukodeingu-2025

  • ピクセルパーフェクトはゴールにしない
    • 変数が多すぎる
    • 多様なデバイスサイズ/解像度
    • 雑に作っていいというわけではない
    • 限られた環境で満点より全ての環境で合格点
  • ブラウザに仕事をさせる
    • 特定サイズのみでなく中間/外部領域のことも考慮しないと行けない
      • デザインは特定サイズのみなことも
      • 例えば
        • CSSでグラデーション
        • 画像のobject-fit
    • CSSはブラウザがよしなにやってくれるのでそれに頼る方が良い結果になることが多い
    • イントリンシックデザイン
      • 本来備わってる性質を活かすデザイン
      • ブラウザに情報を与えて頼る
    • 命令書ではなく提案書
  • 変化に耐えるレイアウト設計
    • Webはデフォルトでレスポンシブ
      • 親要素いっぱいに広がったり
      • 自然に折り返されたり
      • それを壊すのは実装者
    • 固定サイズを避ける
      • width: 800 とかしたらそれより狭くなるとあふれる
        • max-widthとかの方がいい
      • height: 100svh とかすると画面の高さがコンテンツの高さを下回るとあふれる
        • min-heightを使う
      • min-やmax-を使う
      • min()やmax()やclamp()を使う
        • paddingやmarginでも
      • 固定サイズを使うのはborderやbox-shadowなど
        • 小さいアイコンとかは例外
      • font-sizeの拡大で変化してほしくないやつはpxでいい
      • min-width: min(32px, 100%)
    • カードレイアウト
      • 画面サイズでcolサイズを帰るよりauto-fillやauto-fitがいい
  • メディアクエリとコンテナクエリ
    • 従来のレスポンシブは画面サイズに依存していた
    • コンテナクエリを使うと親の幅を気にせずに使い回せるようになる
    • コンテナクエリは無限ループするような指定はできないので注意
    • ビューポートは部屋でランドマークが家具
    • 家具の上に置かれてるものはコンテナクエリ
  • スマホ/タブレット/デスクトップという概念を捨てる
    • 画面幅が複雑化しすぎて3分類なんてできない

なぜ僕たちのNext.js導入はうまくいかなかったのか

奥山 聡さん(akippa)

  • PHPの巨大なレガシープロダクト
  • フロントエンドのアジリティのために刷新へ
    • ページごとに段階移行
    • 認証周りなどもあって最初の1ページを出すまででも苦労した
  • 移行ののつらみ
    • レガシーの複雑さがフロントエンドに染み出してくるのできれいに書けない
    • Nextのキャッチアップも必要
    • 却ってスピードが落ちていた
  • 優先順位を考えて撤退へ
    • 他の技術夫妻もたくさんある状態だった

「え?!それ今ではHTMLだけでできるの!?」驚きの進化を遂げたモダンHTML

西 悠太さん
https://speakerdeck.com/riyaamemiya/e-sorejin-dehahtmldakededekiruno-jing-kinojin-hua-wosui-getamodanhtml

  • Popover
    • 自前でやると細かいところではまることがある
      • z-index
      • フォーカス管理
      • 外側クリックで閉じる
    • popover属性とpopvertarget属性で作れるようになった
  • Dialog
    • これも自前で作るとちゃんと作るのが難しい
    • dialog要素で作れるようになった
  • detailsの排他制御
    • 複数のdetailを置いた時にどれか1つだけ開くようにしたい
      • 開いた状態で他のを開くと元のは閉じてほしい
    • detail要素のname属性でグルーピングできる
  • inert属性
    • 隠れてる要素を無効化したい
    • 指定した配下の要素をツリーから見えなくさせることができる
  • search要素
    • 従来は roll="search" としていた
    • 今はsearch要素が使える
  • loading属性
    • 画像の遅延読み込みさせたいときに使える
    • 従来ならビューポートに近づいたら〜とか自前で書いてた
  • fetchpriority
    • 画像の優先度を指定できる
    • LCPに影響するものを優先度あげるといい
  • blocking属性
    • フォントの読み込みが遅くてちらつくことがあった
    • blocking属性で防止できる
  • inputmode属性
    • 入力要素に指定するとキーボードをいい感じにしてくれる
  • enterkeyhint
    • 検索なのにEnterに改行とか出さないように

堅牢なフロントエンドテスト基盤を構築するために行った取り組み

Shogo Fukamiさん
https://speakerdeck.com/shogo4131/jian-lao-nahurontoendotesutoji-pan-wogou-zhu-surutamenixing-tutaqu-rizu-mi

  • フロントエンドのテスト
    • 重要なところをカバーできてない
    • テストの量が無駄に多くなる
  • テスト対象をどう絞るか
    • プロダクトで最も重要な導線をテストする
  • テストガイドライン
    • スタイルが決まってないとAIが書けない
      • 両方が理解できるフォーマットが必要
    • Testing Trophy
    • BDDで書く
      • 振る舞い駆動開発
      • 実装に依存しないテスト
      • ユーザの操作をそのままシナリオにする
    • Given - When - Then
      • 前提 - 操作 - 期待結果
  • AIにテストを書かせる
    • そのまま書かせても上手くいかなかった
    • テスト専門のカスタムサブエージェントを活用する

心地よいアニメーションのつくりかた

wattanxさん
https://talks.wattanx.dev/2025/fec-kansai/

  • 心地よいアニメーション
    • 目的を考える
    • 適切なイージング
    • 適切なスピード
  • Motion
    • JSライブラリ
    • Spring Animation
    • Shared Layout Animation
  • アニメーションとアクセシビリティ
    • 体験を損なわないために望まない人向けの対応
    • prefers-reduced-motion
      • メディアクエリでユーザの設定を読み取れる
      • reduceを設定してる人には自動アニメーションを起こさないように実装しないといけない

レイアウト構築の基本を理解しよう ~ 横スクロールが起きない!? Flex脱却編 ~

澤 佳祐さん
https://speakerdeck.com/optim/20251130-fec-kansai-sawa

その複雑な型、いつ使うんですか?OSSから学ぶ、高度な型定義の活用方法

Shimmyさん
https://speakerdeck.com/kaminashi/learning-advanced-type-definitions-from-open-source

useEffectってなんで非推奨みたいなこと言われてるの?

マグロさん
https://speakerdeck.com/maguroalternative/useeffecttutenandefei-tui-jiang-mitainakotoyan-wareteruno

ウェブ上の学術論文 — PDFの代替になれるか / アクセシビリティーの観点 / 先進的取組の事例

tarekさん

BCD Designに学ぶ、package by featureのための一貫したfeatureの切り方

airRnotさん
https://speakerdeck.com/airrnot1106/bcd-designnixue-bu-package-by-featurenotameno-guan-sitafeaturenoqie-rifang

TypeScriptがブラウザで実行されるまでの流れを5分で伝えたい

ジンさん
https://speakerdeck.com/jina293/typescriptgaburauzadeshi-xing-sarerumadenoliu-rewo5fen-dechuan-etai

Matter.jsでつくる「ぷにゃっ」と動く物理演算Webエフェクトとパフォーマンス改善

てつを。さん
https://speakerdeck.com/teppei0717/matter-dot-jsdetukuru-puniyatu-todong-kuwu-li-yan-suan-webehuekutotopahuomansugai-shan-7a2123c5-16fe-44ca-ad6d-39b5d55587e9

ソースマップはどのように元コードへの参照を保持するか

yuta-ikeさん
https://www.docswell.com/s/4136989/574PP1-fec_kansai_long

Design System Documentation Tooling 2025

takanoripさん(カンム)
https://speakerdeck.com/takanorip/design-system-documentation-tooling-2025

このプロパティいつ使うん?~mdnのCSSリファレンス、全部読んでみた~

yataさん(LayerX)
https://www.arfes.jp/slides/frontend-conference-kansai-2025
https://maple-saturn-78d.notion.site/CSS-23c986c806a5804a8cdbfc4cfa9a16dc

細粒度リアクティブステートのスコープ設計 - React と Jotai/Bunshi に見るスコープ管理の課題と解決策

恩田 崇さん
https://speakerdeck.com/takonda/fec-kansai-2025

Wasm×C++で実現するフロントエンドAI画像処理

Ken Watanabeさん
https://speakerdeck.com/kaminashi/frontend-ai-image-processing-with-wasm-and-c-plus-plus

「MTDDC Meetup TOKYO 2025」に参加してきました

今日からはじめるWebアクセシビリティ

ymrlさん(フリー株式会社)
https://docs.google.com/presentation/d/1l6pznNkfzXrtIM8DadlgCQTHVmM7GOLTFwkL8IY8eaQ/edit?slide=id.p#slide=id.p

  • Webアクセシビリティ
  • 障害者の社会モデル
    • 個人モデル
      • 医学的な観点での「障害者」
    • 社会モデル
      • 社会がマジョリティに最適化されていて障壁となっていること
      • 社会の障壁がなくなれば障害者として扱う必要がなくなる
  • Webアクセシビリティに完璧なんてない
    • 聞いたこともない種類の障害のある人が使うかもしれない
    • 聞いたこともないブラウザやツールを使ってアクセスせざるを得ない人がいるかもしれない
    • 日本語や英語が母語ではないかもしれない
    • 作り手の想定を超えた状態のユーザは常に存在する
  • 想定ユーザにそんな人はいない?
    • もともとのユーザが病気や怪我になるかもしれない
    • ユーザの家族や友人などが代わりにアクセスするかもしれない
    • 本当は使えないのにアクセシビリティが低くて使えない人がいるかもしれない
  • Webアクセシビリティに取り組む意味
    • Webはすでに社会のインフラ
      • 障壁は減らしていく責任
    • Webアクセシビリティが高まることで可能性が広がる
  • ガイドライン
    • 不便に感じる状況を完全に理解するには不可能
      • どの程度考慮してるか客観性を持たせられる
    • WCAG(Web Content Accessibility Guidlines)
      • W3Cによるガイドライン
      • 最新版は2.2
      • 国際規格のISOと国内規格のJISとの互換性
      • 抽象的で理解するのは難しい
      • ガイドラインは障壁の最大公約数でしかない
  • 2025年のおすすめルート
    • 自分や周囲の人が「使いづらいと思っていることを見つける
    • ツールを使って機械的に問題を見つける
      • ツールで見つかる問題は2-3割
        • 修正箇所の数は体感7-8割くらい
      • コーディングスキルや知識の差が如実に現れる
      • axeとLighthouse
        • Lighthouseは内部でaxeを使ってる
      • Accessibility Bisualizer
        • 緑の人間マークはアクセシブルネーム
          • ここに変なのが出てるとまずい
        • 赤や黄色で警告が出てたら調べる
    • AIに相談してなおす
      • 身近に詳しい人がいなくてもAIがけっこう正しいことを言ってくれる
      • 必ず最後は人間が判断するように
    • もっと詳しく知りたくなったら書籍を読んでみるといい

デザインシステムでA11y品質が担保できなかった「3つの理由」

たじまんさん(株式会社SmartHR)
https://docs.google.com/presentation/d/1hEoFqfJfDWL-Xv2h9uLEVWky_XNwewoGHY0J2VVNAlw/edit?slide=id.p#slide=id.p
https://speakerdeck.com/schktjm/dezainsisutemude-akusesibiriteipin-zhi-ga-dan-bao-dekinakatuta-3tunoli-you

  • SmartHR Design System
  • デザインシステムがあるだけではアクセシビリティの品質を担保できなかった
  • 発生してしまった問題事例
    • チェックボックスのアクセシブルネームがない問題
      • アクセシブルネームがないとどんなチェックボックスなのか伝わらない
      • 提供するコンポーネントでarai-labelledbyの指定を必須にした(紐づくテキストがあるIDを設定する)
      • しかし適当な文字列を入れられてしまった
    • 空文字問題
      • 入力要素は特に気を使う必要がある
      • アクセシブルに実装しやすいコンポーネントを提供していた
      • 不足があればESLintでエラーになるから気づけるはず
      • 空文字を入れることでエラーを回避できてしまった
    • コンポーネント利用者と提供者で最低品質の認識が違っていた
      • 提供者はエラーが出て理由を調べて対応してくれることを期待
      • 利用者はスピードを求めるのでエラーを回避してはやくリリースしたい
    • そもそも知らなかった可能性
    • 知っているけどやれなかった可能性
    • 機能実装と学習の両立の難しさ
      • linterでエラーが出てもそこに踏み込んで学習している余裕がない
      • エラーは教育コンテンツにならない
    • 専任チームがいることによる課題
      • 意識しなくても品質担保ができるようになってくる
      • 問題が少ないと関心を持つ機会も減ってしまう
  • 3つの対策
    • 品質の定点観測
      • 現状の品質が見えていない問題
        • テスター不足など
      • ページを無作為に抽出してテストするようにした
        • 他チームとの比較もできるようになった
    • 人の育成
    • 意識の醸成

Spindle 2025:AIエージェント×デザインシステムで変わるWeb開発

原 一成さん(株式会社サイバーエージェント)
https://speakerdeck.com/spindle/spindle-2025-how-ai-agents-and-design-systems-are-transforming-web-development-f79b09e0-d0be-4cb1-bfe3-9015768eba14

  • Spindle
  • 去年までとの変化
    • Spindleの開発フロー
      • Suggest - Design - Document - Develop - Publish
      • 全ての工程にAIが組み込まれた
  • Spindle MCP
    • すでにある資産をAIから適切に使えるようにしたかった
    • 提供ツール
    • 活用例
      • コンポーネント作成時に作るDesign Docで活用
        • 使い方など文章を書いたりしないといけないから大変だった
        • 必要な情報を取得してAIにドラフトを書いてもらえるようになった
      • デザイントークンの命名
        • 新しいトークンの名前を考えるのに悩む
        • 過去の命名を参考に作ってとAIに頼むと楽
        • 新しく余白のトークンを作るといったこともベースを作ってくれた
    • MCP作成のコツ
      • 実装だけでは暗黙的な部分が多くて安定しなかった
        • サンプルコードがあるといい
      • 暗黙知のドキュメント化が大切
        • 過去の経緯で暗黙的なルールができてるものなど
        • 明文化することで認識してくれる
  • Design to Code
  • リポジトリの改善
    • たくさんの変更が来ても受け入れられる状態に
      • 依存ライブラリの更新
        • AIがリリースノート見てやってくれたりする
      • テスト環境のアップデート
        • 不要なテストを整理したり
    • AIエージェント向けのドキュメント整備
      • AGENT.md/CLOUD.md
        • タスクの最初にしてほしい設定
        • 既存コードのパターンを尊重してほしいということ
        • コミットの記法
        • レビューする時に用意したコマンドを実行すること
      • Custom Commands
        • 繰り返し使うフロー
        • DesignDocを作るコマンドとか
      • Review Guidelines

UIデザインに役立つ2025年の最新CSS

池田 泰延さん(株式会社ICS)
https://speakerdeck.com/clockmaker/the-latest-css-for-ui-design-2025

「Platform Engineering Meetup #15」に参加してきました

感想

  • 書籍の概要を紹介してくれるのが興味が増すし読むときの予備知識になるからありがたい
  • 積読は多いけど買おうと思いました

プラットフォームエンジニアリングとは何であり、なぜプラットフォームエンジニアリングなのか

松浦 隼人さん(Autify)
https://speakerdeck.com/doublemarket/puratutohuomuenziniaringutohahe-deari-nazepuratutohuomuenziniaringunanoka

  • 「プラットフォームエンジニアリング」
    • 原著は2024/10発売
    • 日本語訳が2025/11/29発売
    • 第一部が「プラットフォームエンジニアリングとは何であり、なぜプラットフォームエンジニアリングなのか」
    • 第二部が実践の話
    • 第三部は成功指標の話
    • ツールの使い方やコードの話は出てこない
    • プラットフォームをどうやって成功させるかにフォーカスを当てた本
    • どんなタイミングでどう始めてどういう人がいるといいかなどが書かれている
  • プラットフォームエンジニアリングとは
    • プラットフォームを開発運用する技術分野
    • 自己完結型のツールやサービスや知識やサポートを構成した基盤
  • プラットフォームエンジニアリング
    • ビジネスのレバレッジを実現する
      • 少数が頑張ることで組織全体の業務を削減できる
    • システム全体の複雑さを管理する
      • 複雑さをプラットフォームに閉じ込める
    • プラットフォームをプロダクトとして扱う
      • ユーザ中心に提供物を考える
  • なぜプラットフォームエンジニアリングが必要か
    • ない時に起きること
      • 選択肢の増加
      • グルーの蔓延
      • 保守コストの増大
      • 運用負荷増加
  • 4つの柱
    • プロダクトとして扱う
      • ユーザ中心
      • 対象を明確にして提供物を厳選する
    • ソフトウェアベースの抽象化
      • 複雑さを管理するにはソフトウェアが必要
      • つまり開発者も必要
    • 幅広いアプリ開発者向けの基盤
      • 個別最適ではなく多くの関係者をカバーできる必要
        • セルフサービスに使える
        • 利用者から見たオブザーバビリティ
        • ガードレール
        • マルチテナンシー
    • 運用の規律を持つ
      • プラットフォームチームがプラットフォームの責任を持つ
      • 自分たちで制御できないものに依存しすぎないように
  • ツールやプロセスを導入することだけがプラットフォームエンジニアリングではない

ギフティにおけるプラットフォームエンジニアリングことはじめ

じぇまきさん(ギフティ)

  • 全エンジニアがフルスタック
    • 組織の拡大につれて認知負荷が拡大してきた
    • 開発の合間でインフラのメンテが必要
    • 運用等のベースラインが横断で揃えられてない
  • プラットフォームエンジニアリングチームの立ち上げ
    • 何を目指していけばいいか分からない
      • CNCFのプラットフォームエンジニアリング成熟度モデル
      • 5つの特性と4つのレベル
      • 現在地を認識するためのもの
    • 何でもやってくれると期待値が上がりすぎる
      • ビジョンを作成して公開する
      • どこを目指しているか理解してもらう
      • ラディカルビジョンステートメント
    • 何から始めるといいのか分からない
      • 優先度判断
        • ビジョンフィットとサバイバル可能性の2軸
  • 技術面の取り組み

Azure API Management × API Centerで実現する生成AIプラットフォームエンジニアリング

折田菜津子さん(エーピーコミュニケーションズ)
https://www.docswell.com/s/windagecat/ZQXWQE-2025-11-28-021055

  • 生成AI活用の現状と制約
    • 生成AIツールの利用が進む
    • MCPなどの活用も進む
  • MCPの課題
    • 企業ガバナンスに準拠した利用が必要
    • 独自のMCP開発/管理の需要
  • Azureによる解決
    • Azure API Management(APIM)
      • AIGateway
      • AIモデルの公開管理基盤
      • 独自MCPの統合管理
      • オブザーバビリティ
    • Azure API Center(APIC)
      • ライフサイクル全てのガバナンスを一元管理できる

「リアルとデジタルで叶える“まちづくり”【URBAN HACKS Talk vol.1】」に参加してきました

東急のDXリアル ― 生活を変える『線』と『面』のデザイン

宮澤 秀右(Sean)さん(東急株式会社 VPoE)

  • 東急
    • 鉄道
    • 不動産
    • 生活サービス
    • ホテル/リゾート
  • 豊富なリアル接点にデジタルなノウハウを合わせる
    • 投球グループの資産をハックしてより豊かな暮らしを
  • 組織
  • デジタルプラットフォームの構築
    • 点/線/面の3段階
    • デジタルを活用することで連携がしやすくなる

データから見る東急沿線の未来を握る鍵とリアルxデジタルの可能性

松本 直也さん(東急株式会社 リードプロダクトマネージャー)

  • 東急ブランド
    • 信用信頼は高い
    • 使いやすさは低い
  • リアルなアセット
    • 百貨店/スーパー/ホテル
    • ポイント会員/CATV
  • 沿線人口
    • 40代以降はそこに住み続ける事が多い
    • 30-40代が鍵

デジタル領域で完結しない世界でのアジャイルな事業創出への挑戦

石神 哲博(Tegami)さん(東急株式会社 リードプロダクトマネージャー)

  • QSKIP
    • コロナ禍で鉄道事業の収益が下がった
      • 事業構造の変革
    • QRコードで改札を通過できる仕組み
      • ただデジタル化しただけではない
      • 沿線の店舗との連動
  • QSKIPの開発
    • 鉄道業界でアジャイル開発
      • 東急電鉄/東急(URBAN HACKS)/改札機メーカー
      • 短期間でリリースするサイクルは難しかった
    • 職能横断チーム
      • チーム内で意思決定できるといい
      • 受発注なバックグラウンドのメンバーは慣れるまでに時間はかかった
    • チームビルディング
      • ビジネスとプロダクトが現地に出向いて一緒にフィールドテスト

まちの情報をつなぐ『東急・東急電鉄公式サイト』― グループ横断DXの裏側

北浦 幸葉(Yuki)さん(東急株式会社 プロダクトマネージャー)

  • 東急・東急電鉄公式サイト
  • 背景
    • 東急グループを横断した接点がなかった
    • サービス個々のサイトはあってもそれが東急だと認知されないことも
    • 東急の街に愛着を持ってもらうためのプラットフォーム
  • 開発
    • 各サービスの情報を集約するコンテンツ基盤
    • 事業者とのコミュニケーション強化
      • サイトに情報を載せてくれるサービスを増やしたい
      • ワークショップやったり
      • 2年がかりで
    • URBAN HACKSが先導してコンテンツ制作も
      • 沿線98駅を散策したり

「After JJUG CCC 2025 Fall」に参加してきました

Java Virtual Threads / Kotlin Coroutines / Go Goroutinesの比較

和田 隆道さん(LINEヤフー株式会社)

  • 1リクエスト1OSスレッドだとC10K問題が発生する
  • tomcatの方式
    • 1リクエスト1OSスレッド
    • ブロッキングI/O
    • 処理は同期的
    • OSが参照するスタックを切り替えて処理対象を切り替える
    • OSスレッドの数は性能によって上限があるので達していると待たされる
  • イベントループ
    • 1つのOSスレッド上でループを回して複数のリクエストを処理する
    • ノンブロッキングI/Oにする必要がある
      • 同じスレッドで多数のリクエストをさばくので
    • IO完了時の処理は非同期で行う
  • Coroutine
    • イベントループでノンブロッキングに処理をする
    • Kotlinでは完了後の処理を同期的に書ける
      • CPS変換という処理が行われるから
  • 軽量スレッド
    • OSスレッドを共有して1リクエスト1軽量スレッドで処理する
    • 軽量スレッドをOSスレッドにスケジューリングする
    • JVMがノンブロッキングに書き換えてくれる
    • Virtual Threadのスタックで実行状態を持ってる

初めてのKotlin:Javaチームが挑んだマイクロサービス開発

三木 一馬さん(株式会社出前館)

  • Java開発者が新規のKotlinアプリを作った
    • クイックマートのAPIの一つ
    • 数千店舗の数万商品のデータが流れる
    • 開発者6-8名
    • Kotlin/SpringBoot/gRPC/Kafka
  • 開発中の課題
    • モデルが増え続ける
      • 操作ごとにモデルを量産
      • 同じフィールドが多くの場所にある
      • 同じフィールドでも型が違うこともある
      • -> sealed interfaceで共通フィールドを一箇所に集約できる
    • 型安全性の問題
      • 複数フィールドがStringで定義されてると渡し間違えが起きる
      • -> ValueObjectで専用の型を定義
        • バリデーションもその中に閉じ込める
  • gRPCの実装
    • マイクロサービス間の通信はgRPC
    • gRPC Server Streaming
      • 1リクエストに複数レスポンスを返せる
      • 逐次でレスポンスを受け取れる
    • 処理時間は改善した
    • toListで全件まとめようとすると結局streamingのメリットがなくなる
      • REST APIのレスポンスをストリーミングにできればいいがそれもできない仕様
  • エラーハンドリングの実装
    • ビジネスエラーと非検査例外と混在し複雑化
    • Result型によるエラー管理
      • ビジネスエラーがエラーだが正常系という扱いになる
      • 非検査例外と区別できる
  • Kotest
    • テストケースを階層的に書ける

意外と難しいドメイン駆動設計の話

木目沢 康廣さん(株式会社ZOZO)

  • DDDでの設計パターン
    • SQLにロジックを持つか
    • SQLはシンプルに取得してアプリケーションでロジックを持つか
  • 仕様変更に強い設計
    • SQLだけ変えればよくてアプリケーションは変わらない方があいいか、その逆がいいか
    • 多くの箇所を修正しないといけないのは避けたい

「TSKaigi Hokuriku 2025」に参加してきました

TypeScript 6.0で非推奨化されるオプションたち

うひょさん
https://speakerdeck.com/uhyo/typescript-6-dot-0defei-tui-jiang-hua-sareruopusiyontati

  • TS7.0からネイティブ版のtsgoになる
    • 今は5.9で次は6.0
      • 6.0はネイティブ版に向けた準備のような位置づけ
    • 6.0は2026/1,2くらいで7.0はその1ヶ月後くらい
    • 6.0での非推奨項目
      • 7.0では使えなくなるもの
  • TSのバージョン
    • セマンティックバージョニングにのっとってない
      • 4.9の次が5.0だっただけ
    • 初期は大きめな特別なリリース扱いしていた
      • 1.8から1.9を飛ばして2.0になってたり
      • 3.0以降は順番に上がってるだけ
    • 5.0のdeprecationサイクル
      • 5.0で警告
      • 5.5でエラーにならないが動かなくなる
      • 6.0でエラーになる
    • 6.0はdeprecationサイクルが完遂するタイミング
  • 6.0で非推奨化されるもの
    • target: es5
      • ES5へのトランスパイル廃止
      • 最小ターゲットはes2015に
      • デフォルト値はリリース時点の最新版
        • tsc --initするとesnextになる
      • es2015すらサポートしてない環境はもうないと言っていい
      • トランスパイルは他のツールを使ってるケースも多い
    • outFile
      • outDirではなくoutFileを指定すると1つに統合したjsを出力していた
      • CommonJSやESMに対応してなかった
      • 原始的なバンドルのような動き
    • moduleResokution: classic
      • モジュールの解決方式
      • CommonJSよりも古いやつでNodeですらない?やつが使えなくなる
    • alwaysStrict: false
      • use strict と書かなくても常にstrict modeで扱うオプション
      • 実質strict modeで今は書かれてるから
    • module構文
      • namespaceより昔のmodile構文が廃止
      • 一部使えるパターンも残る
      • JS側でmoduleが入る動きがあるのでts側にあると邪魔という背景も
    • import ... asserts
      • assertsじゃなくてwithが今の書き方
        • 当初assertsでwithに仕様変更された名残
      • chromeやNodeはもうasserts消してwithに移ってる
  • 6.0で挙動が変わるもの
    • typesのデフォルト
      • どの @types パッケージを読み込むかのオプション
      • デフォルトでは何も読み込まなくなる
    • rootDirのデフォルト値
    • tscにファイル名を渡した時の挙動
      • 従来はtsconfig.jsonを無視する
      • 今後はtsconfig.jsonがあったらエラーが発生
        • 使わないときはignoreのオプションをつける
        • 使うときは指定する
    • enum merging
      • 同じファイルで同じ名前のenumを宣言するとマージされてた
      • あまり使われないので廃止される
    • 複数namespace間での変数参照
      • 変数参照する時の挙動が変わる
  • まとめ
    • 以下のような理由で古いものが整理されることになる
      • 不要な実装の削減
      • パフォーマンスの最適化
    • 2026/1か2に6.0が来るので準備は必要
      • その後の7.0を使いたいならなおさら
    • ただし普段の開発にインパクトが大きいものはそんなにない

Fullstack TSでマルチプロダクトの基盤開発

鈴木翔大さん(MOSH)
https://speakerdeck.com/soarteclab/tskaigi-hokuriku-2025

  • フルサイクル開発
    • ドメイン理解への集中
    • 開発運用を降るサイクルで
    • やるべきことが増えてスピードに影響が
  • マルチプロダクト
    • 複数チームで機能の重複
    • 振る舞いの違い
  • TSで共通基盤の開発
    • 決済/通知/メッセージ管理/アカウント管理など
    • 一貫したユーザ体験
    • 技術的複雑性のカプセル化
  • スキーマ駆動開発
    • 各基盤でOpenAPIの定義
    • clientとserverのソースコードを自動生成
      • 呼ぶ側と呼ばれる側を同時に変更させることで整合性を保つ

denoとtypescriptの関係について改めて考えてみる

比嘉 一晃さん

  • Deno
    • JavaScript Runtime
    • Nodeの作者が反省点を踏まえて作ったもの
      • JS Conf EU 2018で発表
    • TSをゼロコンフィグでサポート
    • npmとnodeもサポート
    • Web標準APIもサポート
      • fetchなど
    • deno lint
    • deno fmt
    • deno test
    • ファイル実行時にセキュリティチェックが走る
      • 実行していいかプロンプトで問い合わせが来る
      • ネットワークアクセス
      • ファイルへのアクセス
      • など
  • 動かしてみる例
    • deno init
      • templateを指定することができる
      • react-tsとかある
    • CLIアプリ

TypeScript×CASLでつくるSaaSの認可

坂津 潤平さん
芹澤 和也さん
https://speakerdeck.com/saka2jp/authz-with-casl

  • 各レイヤーでの認可ロジック
    • UI: 権限のないボタンを表示しない
    • API: 不正な操作をガードする
    • DB: 他社のデータを取得しない
  • 認可モデル
    • RBAC
      • ロールベースアクセスコントロール
      • 役割に権限が紐づく
      • 複雑になるとこれでは足りなくなり
    • ABAC
      • 属性ベースアクセスコントロール
      • ユーザ属性とアクセス対象のレベルを比較して判断
    • PBAC
      • ポリシーベースアクセスコントロール
      • 細かいロジックを含めた判定ができる
    • ReBAC
      • 関係性ベースアクセスコントロール
      • GoogleDriveのような権限管理
  • AI面接サービス
    • テナント管理者はテナントの設定変更ができる
      • RBAC
    • 評価担当者は自部署の応募者のみ閲覧化
      • ABAC
  • 認可サービス
    • Auth0 FGA
      • Oktaの一部
      • Google Zanzibarに基づく
    • Oso Cloud
      • 独自ポリシー言語Polarを使う
      • BtoBでよく使われる
    • Permit.io
      • ローコードでの権限管理
      • UIベース
  • SaaSの懸念
    • 従量課金
    • レイテンシ
      • セルフホストの選択もあるが
  • CASL
    • OSSの認可サービス
    • Isomorphic
      • 定義したポリシーをフロントエンド/バックエンドで再利用化
    • Ability
      • 誰が何をどうするという認可のルールを詰め込むオブジェクト
      • Prismaの型をすのままSubjectとして使える
    • NestJSだとデコレーターで実装できる
      • コントローラーに到達する前にはじく
      • フィールドレベルの認可もできる
    • Canコンポーネントを作って出し分けたい要素を囲う
      • 権限がある場合だけ表示されたり制御してくれる

同期APIの壁を越える:TypeScriptで設計する、堅牢さとUXを両立した非同期ワークフローの実現

moekaさん(アセンド)
https://speakerdeck.com/moeka__c/typescriptdeshe-ji-suru-jian-lao-satouxwoliang-li-sitafei-tong-qi-wakuhuronoshi-xian

  • オールインワンSaaS
  • 同期APIの壁
    • 整合性要件の高さ
    • ピーク時の大量処理
    • 整合性/堅牢性と拡張性を両立したアーキテクチャ
  • 非同期データ連携
    • イベントソーシング + イベントドリブン
    • ワークフロー
      • Sagaパターン
        • ローカルトランザクションの連続として扱う
        • 途中で失敗したら打ち消す処理を逆方向に投げていく
      • コレオグラフィ方式
        • 各サービスがlistenして取得していく
        • シンプルな連携
        • 補償が大変
      • オーケストレーション方式
        • 中央で管理
        • 状態管理が複雑
    • イベントの発行
      • DBトランザクションとイベント送信
        • どちらか一方が失敗した時どうするか
      • Outboxパターン
        • 少なくとも1回送ることを保証する方式
    • イベントの受け取り
      • 重複配信された場合の考慮
      • アプリ側で冪等性を担保
  • TypeScriptでの実装
    • 技術的な複雑性がとても多い
      • どこまで整合性を担保するかは事業要件とあわせて判断していくことになる
    • フローの全体像を型で表現
      • 型付きステートマシンとイベントでモデル化
      • 実装を見なくても型を見るとフローが分かる
      • 早期に考慮漏れを検知できることにもなる
    • EventSourcingとOutboxを型で強制
      • eventのapplyやsaveを実装で縛る
    • サービス重複呼び出し防止
      • フローの状態管理テーブル
      • idとstatusでロックして重複を防ぐ
      • ロック済みであることを保証する型

レガシーシステム刷新におけるTypeSpecスキーマ駆動開発のすゝめ

karacoroさん(LIXIL)
https://speakerdeck.com/tsukuha/regasisisutemushua-xin-niokeru-typespec-sukimaqu-dong-kai-fa-nosu-me

  • レガシーシステムの技術的な観点
  • システム刷新時の考慮ポイント
    • デグレがないか
      • 刷新前後で動作が変わらないように
    • マイグレーション後の動作保証
      • 各種テストを行って動作の担保が必要
    • 技術のモダナイズ
      • 技術刷新を合わせて行うことも
  • スキーマ駆動開発
    • フロントエンドとバックエンドを分離し段階的にやることが多い
    • バックエンドのデータ構造は変更しづらいのでフロントエンドが先行しがち
    • API仕様書がない場合に適用しやすい
  • OpenAPIとTypeSpec
    • OpenAPI
      • API仕様のフォーマット
    • TypeSpec
    • TypeSpec -> OpenAPI -> 仕様書やコードなど
  • 開発の進め方
    • モノレポで
    • typespec配下で定義を管理
      • 新旧並行稼働があるならnewとlegacyを分けておくといい
      • 移行中に旧に手が入っても対応しやすい
    • frontend配下でフロントエンドの実装を管理
    • 出力した型定義をfrontend配下に配置する
      • 問題があればエラーになるので変更の影響分かりやすい
    • Orvalを使ってzodのスキーマも自動生成できる
    • Contruct Testing

型情報を手繰り寄せる技術〜TypeScript Compiler APIによる型解析実践〜

jiko21さん

  • 型からHTMLを作りたい
    • タグの親子関係のルールなどを型で縛る
  • TypeScript Compiler API

Building AI Agents with TypeScript

izumin5210さん(LayerX)
https://speakerdeck.com/izumin5210/building-ai-agents-with-typescript

  • AI機能の開発の変化
    • APIベースになった
    • モデルを自前で構築しなくて良くなった
    • SDKが充実してきた
  • TypeScriptのAIエージェント
    • vercel/aiを使ったサンプル
      • どのモデルでも同じAPIで使えるようにしたライブラリ
      • 薄いのがいい
    • toolを渡すといい感じに使ってくれる
      • aiSDKを使うと簡単に作れる
    • useChatでメッセージを管理できる
      • AIからのレスポンスの内容を型安全に扱うことができる
      • jsonなので永続化すると履歴を残せる
    • ワークフロー
      • 決まった流れがある時に定義しておける
      • Deep Researchもワークフロー
      • 小さく分けることでコンテキストを小さくできる
      • LLMにやらせる必要がない決定論的なものは別で処理できる
    • Durable
      • 途中で中断しても最後まで実行できるように
      • Resumableであるように
      • vercel/workflow

tsc --init の設計思想の変化とその背景を追う - “教育的”アプローチから実用性重視への転換

大塚竜太郎さん(チームラボ)

  • ts5.9から tsc --init の内容が変わった
    • 全てのオプションとコメントが出力されていた
    • かなりミニマルになった
  • 変えた理由
    • ESMを推進しているのでcommonjsベースをやめた
    • コメントが大量なのが威圧的とフィードバックが
    • ほとんどすぐに削除されていると分かった
  • 変更点
    • typesでグローバル型を明示的に管理
      • 意図しないグローバル型の混入を防ぐ
    • noUncheckedIndexedAccessとexactOptionalProperty...
      • 後から有効化するのは大変なので最初は有効化がいい
    • verbatimModuleSyntaxとisolatedModules
      • ベストプラクティスに寄るように
    • moduleDetection: forceを明示
      • import/exportがないファイルも常にモジュールとして扱うように
      • グローバルを汚染させない

TypeScript ASTを活用した意味差分抽出の紹介

武井勇也さん
https://speakerdeck.com/takewell/introduction-to-design-difference-extraction-using-typescript-asta

  • AIコーディングでレビューが大変
    • AIでレビューさせてもいいけど自分で理解したい
    • 構造が複雑だとレビューが大変
    • レイヤーが多い
    • 多くの依存が絡む
    • 全体の構造と変更の有無が図示されると嬉しい
  • 依存関係の図示
    • ts-morphでASTを解析
    • diffと解析結果を合わせてmermaid化

TS 5.9で使えるようになった import defer でパフォーマンス最適化を実現する

おおいしさん(ファインディ)
https://speakerdeck.com/bicstone/typescript-import-defer

  • ts5.9から import defer が使えるようになった
    • 読み込みは即時だが評価は遅延させることができる
  • 今までは
    • 同期だと即時取得/即時評価
    • 非同期だと遅延取得/遅延評価
  • 非同期importだと読み込みから全て動くので待ちが長くなってしまう
    • import deferがちょうどいい動きになる
  • エラーハンドリング
    • 実行時エラーになることがあるから注意

フロントエンドにおける「型」の責務分離に対する1つのアプローチ

kinocoboyさん
https://speakerdeck.com/kinocoboy2/hurontoendoniokeru-xing-noze-ren-fen-jie-nidui-suru1tunoapuroti

「TSのAPI型安全」の対価は誰が払う? 不公平なスキーマ駆動に終止符を打つハイブリッド戦略

Halさん
https://speakerdeck.com/hal_spidernight/tsnoapixing-an-quan-nodui-jia-hashui-kafu-u-bu-gong-ping-nasukimaqu-dong-nizhong-zhi-fu-woda-tuhaihuritutozhan-lue

Welcome to the “Fantasy Land” 🧚 − 代数的構造をめぐる冒険 −

TAKASE Kazuyukiさん
https://speakerdeck.com/guvalif/welcome-to-the-fantasy-land-dai-shu-de-gou-zao-womegurumou-xian

LT

「GDG DevFest Tokyo 2025」に参加してきました

AI の力で解き放とう、 開発者の無限の可能性を。

蔡欣眉さん

Webの再生と技術者の今後

及川卓也さん

  • Web2.0
  • 2つのクラウド
  • HTML5
    • 2008年にChromeが出る
    • プラグイン費用な開かれたWeb
    • アプリのような体験をブラウザで
  • Webは誰も支配していない
    • Webとメールだけは誰のものでもない
    • 他はお金になるのでどこかが囲い込んでしまっている
  • 2025年のWeb
    • 結果としてブラウザの多様性は失われて寡占化
    • 標準化プロセスの混沌
    • オープン性と制御
    • プライバシーと利便性
  • Web vs アプリ
    • アプリであればフィッシングの危険性は低い
    • GoogleAppleが最低限のチェックをしてくれてる
  • WebとAI
    • WebがAIの餌場
      • もともとは人に届けるためだった
      • AI向けでお金になるなら人にとっての質が下がっていく
    • AIのリスクからWebを守る
      • AI利用の制御
      • 利用許可の明示
      • AI生成物のラベル付け
        • テキストはラベル付けできないので倫理観が問われる
    • AI時代のWeb再設計
      • Webのメタデータの補足
      • AIが扱えるデータ空間としての再設計
      • 画面を操作するWebからの脱却
    • NLWeb
      • Webの会話形インターフェース
  • 技術者
    • レイヤーがなくなってきてる
      • 単一レイヤーでは戦えない
    • 実装 -> 事実標準 -> 公式標準
      • まずは作ることから
    • 人間のためのWebを設計する

異分野クロストーク

データ分析エージェントでBQを活用

なかむら さとるさん

  • BigQuery
    • データウェアハウス
  • BigQueryから生成AIを使う
    • クエリのなかでgeminiを使うと書くと使える
    • selectにプロンプト書く
    • データをselectしつつ生成AIの結果も含ませることができる
    • データとして持ってる画像や音声の内容も解釈できる
  • 生成AIからBigQeuryを使う
    • ADK BigQuery Tool Set
    • 自然言語で質問した時にBigQeuryを見て回答してくれる

Chrome Dev Toolsとバックエンド

矢倉 眞隆さん

  • DevTools
  • Networkパネル
    • 通信の内容を確認できる
    • 通信を書き換えたりもできる
    • ネットワークの強さをエミュレート
      • throttling
      • 特定のリクエストだけ遅くすることもできる
    • 通信を編集してヘッダーを追加したりできる
      • リロードしても編集は生きてて書き換えた内容で通信できる
    • ServerTiming
      • API側でどの処理にどれくらいかかってるか返すことができる
      • 実例だとCDNサービスがキャッシュの処理にどれくらいかかってるかとかShopifyが画像の加工にどれくらいかかってるかとか
  • DevToolsのAI機能
    • AI機能がビルトインされている
    • チャットで聞けたり質問がテンプレで用意されてたりする
  • DevToolsMCP

Next Generation Web Frontend 2025

State of Angular with AI

lacolacoさん
https://docs.google.com/presentation/d/1mPZZW61yePUnGAtY5Iu_AgNGo7UMQncj8DS941Yz7j4/preview?slide=id.SLIDES_API2000280013_0

Angular v21

  • Signal Forms
    • Signalベースの新しいFormAPI
    • Experimentalで入った
    • 今で2種類のフォームがあった
      • どっちを使うか迷っていた
      • 今後はこれになるはず
  • Angular Aria
  • Zonelessがデフォルトに
    • Zone使ってないのがデフォルトに
    • パフォーマンスが向上
  • Vitestがデフォルトに
    • v4にも対応してる
  • TailwindCSS integration
    • ng newでtailwindセットアップ済みで雛形ができる

Angular with AI

  • Develop with AI
    • Angularのベストプラクティスに従ったコードを書くためのルールを提供
      • ng generate ai-config gemini とかすると自動でセットアップしてくれる
    • Angular MCP Server
      • ng mcp
      • Angularを効率よく開発するためのセットアップを全部やってくれる
  • Build with AI
    • FirebaseのGenkitとの統合
  • Learn with AI
    • Angular AI Tutor
      • チュートリアルをやる時にチューターになってくれる機能
      • Firebase Studio内でやるとローカルのエディタなしでできる
  • Design with AI
    • AngularのAPIをどう作るかAIを活用してやってる
      • デザインdocを与えてコードサンプルを作らせる
      • 結果を見てフィードバックサイクルを回して最適を探してる
    • AIが間違えやすいとかで改善も進めてる

Getting started with Chrome build-in AI APIs

Yuriko Hirotaさん

  • WebにAI機能を作る時
    • サーバーサイドAI
    • クライアントサイドAI
      • クライアントにモデルを置いてそれを使う
      • ローカルにいるので無料
      • バイスに閉じているので使えるようになるデータもある
      • オフラインでも使える
    • クライアント/サーバーのハイブリット
  • ChromeにビルトインされたAI
    • ブラウザにモデルが内蔵されている
      • ChromeにはGeminiNanoが入ってる
      • 標準化に向けて動いているので他のブラウザも進むことになる
    • WebAPIを通じてアクセスする
      • Prompting
      • Writing
      • Translating

Web UI 2025 Updates & What's Coming!

sakuさん
https://sakupi01.github.io/slides/ja/2025_11_22_gdgdevfest_web-ui-updates-whats-coming/

  • Baseline
    • Limited Availability
      • まだ全てのブラウザで使えない状態
    • Newly Available
      • 全ての主要ブラウザで実装された状態
    • Widely Available
      • ブラウザ利用状況も踏まえて広く使えるようになった状態
  • Container Query
    • @container でコンテナのサイズに応じてスタイルの使い分けができる
    • これまではJavaScriptによる実装が必要だった
    • 今年にWidely Availableになった
  • PopoverAPI
    • トリガーとなるボタンと押した時に表示するフローティングな要素
  • Invoker Commands
    • JSを使わずボタンを押したら何か表示するみたいなトリガー機能を実現できる
  • Interest Invokers
    • 興味を示したかどうかをイベントで取得できる
    • 興味を示すとはホバーした時
  • Anchor Positioning
    • トリガー要素に対してフローティングな要素を表示する時にどこに表示するかの機能
    • 余白のある方向に表示を切り替えたりもできる
      • それに応じたCSSの変更もできる
  • Customizable Select
    • PopoverAPIやAnchor Positioningも関連してる
    • 見た目をカスタマイズしたセレクトボックスを作ることができる
      • 今までは標準のselectを非表示で隠してカスタムの見た目と連動させたりしないといけなかった
    • menuやcomboboxへの派生も始まってる

「アーキテクチャConference 2025(2日目)」に参加してきました

ドメイン駆動設計とマイクロサービスアーキテクチャ

しょぼちむさん(アマゾンウェブサービスジャパン合同会社)
福井 厚さん(アマゾンウェブサービスジャパン合同会社)
成瀬 允宣さん(株式会社コドモン)
https://speakerdeck.com/syobochim/ddd-x-microservice-architecture-findy-architecture-conf-2025

  • マイクロサービス
    • 1つのサービスの単位でデプロイできるように分けたもの
    • 大きくなりすぎたものを分けていくというのが正攻法
    • 最初からマイクロサービスするのはいいパターンではない
  • サブドメイン
    • 業務を分析し分割したもの
    • 地形みたいな人の手が入らないもの
  • 境界づけられたコンテキスト
    • モデルを作るための境界
    • 同じ意味の用語を適用できる範囲
    • 市町村の線引きのように人の手が入るもの
  • サブドメインと境界づけられたコンテキストの関係性
    • 1対1?どちらかが大きい?
      • 理想は1対1
      • 言語は伝わるが現場の業務が分かれているパターン
    • モデルの共有
      • モノレポだとサービスの依存が見えて分かり易いが、CIなど共通のコードが膨らむのがつらい
      • モノレポじゃないときにAIに他のプロジェクトがどこにあるか伝えるといい
  • マイクロサービスどこから手をつけるか
    • コアドメイン
      • そこがうまくいかないと話にならないから
      • 成果を早めに出したいから
  • 効率的に作るには
    • AI-DLC
      • AI駆動開発ライフサイクルe
      • AI-ManagedとAI-Assisted
      • AIはプランニング、タスク分解、アーキテクチャ提案
      • 人は検証、意思決定、最終的な責任保持

SaaS拡大期の成長痛 〜モジュラーモノリスへのリアーキと生成AIの活用〜

今中 公紀さん(株式会社Finatext)
山崎 蓮馬さん(株式会社Finatext)

  • 保険のシステム
    • 商品が複雑
    • 商品改定がある
    • 会社によって微妙に違う商品がある
    • 複雑なドメイン知識が必要
  • アーキテクチャ
    • CoreAPIで共通の保険ロジック
    • 各テナントごとにBFF
  • 数年の運用をして
    • 似た構成のサービスの乱立
      • 個社ごとにBFFを持ってる負荷
      • プロジェクトごとの差異を見極める難しさ
      • BFFにドメインロジックが流出
    • マルチテナントとセキュリティ要件
      • DBが完全にぶんりされているかとか
  • モジュラーモノリス
    • モジュール感はPublicAPIで連携する
      • Applicationは共有
      • Usecase/Domain/Infraはそれぞれで
      • UsecaseをたたくPublicAPIを置く
    • DBは共有とモジュールごとどちらにするか
      • 整合性が重要で高トラフィックではないから共有にした
      • ただし基本は担当モジュールのPublicAPI経由でデータにアクセスする
  • 同期呼び出し
    • モジュール間の直接呼び出し
    • Applicationレイヤー経由での複数モジュール順次呼び出し
  • トランザクション
    • さまざまなパターン
      • Applicationレイヤーで複数モジュールまとめて
      • Useecase単位
      • UsecaseからUsecaseを呼んでネスト
    • 外側のトランザクション優先
  • アーキテクチャでの生成AI活用
    • TDD
      • 明確な指示が必要
    • ナレッジ共有
      • コーディング規約
      • CLOUDE.md
    • タスク分解
      • タスクを分けて段階的に作らせる
      • 自分ならどういうステップでやるか考えてそれをプロンプトに

セキュリティアーキテクトの設計思考──変化と制約を前提とした“再現性ある判断軸”とは

石川 朝久さん(東京海上ホールディングス株式会社)

  • セキュリティアーキテクト
    • 複雑な制約条件の中で「守れる」アーキテクチャを設計する
    • 多様なレイヤーをまたぐトレードオフを紐解き可視化し意識っていに至る思考を提案する
  • セキュリティアーキテクチャ
    • 技術的アーキテクチャがどうなっているかで変わってくる
    • エンタープライズアーキテクチャに整合する形にする
    • セキュリティリスクを低減するアプローチ
    • 全レイヤーを横断的に
    • 全てを実現するのは現実的ではないのでどれをやるのかの判断がいる
  • パターン
    • Security Design Principles
    • Security Architecture Pattern
    • 予防 - 検知 - ハント
  • 課題の洗い出し
  • トレードオフ
    • ビジネス要件との競合
      • コストなど
    • 他のアーキテクチャとの競合
      • パフォーマンスなど
    • いつ判断するか
      • 制約が判明したらすぐに
      • セキュリティチームが早めに関与することも必要になってくる
    • どのように判断するか
      • 真に判断するべき部分を見極める
        • 既存の仕組みを使える要素はそっちに誘導
        • 真に対応するべきところに注力
      • 最も影響が大きいシナリオに注力
        • 発生確率x影響度
        • 多層防御を前提に
          • 95点を1つよりも80点を多段に
        • 追加対策可能なアーキテクチャ
          • 残存リスクに後から対応できる構成
          • 後戻りできない決定は慎重に
  • Bold-onからBuild-in
    • 早期関与が非常に重要
      • セキュリティもシフトレフト
      • 手戻っての対応はコスト30倍というデータ
  • 早期相談できる文化
    • 技術的施策
      • 開発者が行うセキュリティを減らす
        • 共通基盤を作ったり
      • ソリューションの活用
    • 組織プロセス的施策
      • 開発者がやらないといけないことを仕組み化伴走支援
      • レビューをいっしょにやる
        • レビュー結果にセキュリティチームも責任を負う体制
      • パイプラインにSASTなどを入れて認識できるように
    • 人的施策
      • 最終的な人の判断のための意識付け
      • ビジネス要件に最大限に寄り添う
        • 人質にはされないように

出前館アプリ進化論 〜アーキテクチャと組織のリアルな変革の舞台裏〜

植松 啓誠さん(株式会社出前館)

  • 出前館
    • 2000年サービス開始で25年の歴史
  • 変革の契機
    • 2020年にLINEと提携しサービス合併
    • コロナ禍のタイミングも重なる
  • 事業の成長を止めずに技術基盤を刷新する
    • コロナ禍で400%の利用量
    • 歴史があるシステムを止めずに対応
  • コンポーネントの対応
    • インフラ
      • オンプレだったが限界を迎える
        • 物理的にもうサーバーを増やせない
      • ピークに備えてリソースを確保しないといけない
      • 運用が特定メンバーに属人化
        • 影響範囲の把握など依存してしまう
    • バックエンド
    • Webフロントエンド
      • 巨大な1ファイルに7000行のコントローラー
      • dead codeが大量
      • 大量のビジネスロジックを持ってしまっている
      • PHPエンジニア不足
    • モバイルアプリ
      • アウトソースしていてノウハウがない
        • zipで受領しているだけ
      • テストがないので何が正しいか分からない
  • アーキテクチャ
    • Web/App - (GraphQL) - BFF - (gRPC) - マイクロサービスAPI
    • Webフロントエンド
      • CodeIgniter(PHP) -> Next -> Next + Apolloサーバー
      • 100以上の画面を段階的に
    • バックエンド
      • ロジックを小さく切り出す
      • テーブルへのアクセスを背営利
      • 別DBにテーブルを移動
      • 切り離しが終わればIFを変えなければあ自由に改善ができる
    • アプリ
      • 80のAPIを呼んでいた
        • オーバーフェッチ/アンダーフェッチも多発
      • Webフロントエンドの対応でBFFが出来た後はそれを見るように
    • 組織
      • 責務とオーナーが明確に
      • 関わるべき人がわかりやすくなり動きやすくなったe
  • 次の10年に向けて
    • なぜこうなっているかをしっかり残す
      • それがないのがつらかった
    • 技術的負債との付き合い方
      • ゼロ負債ではなくコントロールされた負債に

事業状況で変化する最適解。進化し続ける開発組織とアーキテクチャ

山田 圭一さん(キャディ株式会社)
https://speakerdeck.com/caddi_eng/shi-ye-zhuang-kuang-debian-hua-suruzui-shi-jie-jin-hua-sisok-kerukai-fa-zu-zhi-toakitekutiya

  • 製造業で置きてる問題
  • CADDiでは
    • 資産化してテクノロジーで効率化していく
    • 分断されたデータを統合整備し価値につなげる
  • 事業状況の変化
    • 初期は加工品の受発注プラットフォーム
    • 今は製造業のAIデータプラットフォーム
  • プロダクトの変遷
    • 最初は社内向け
    • その後外部向けにローンチ
      • MVP最速立ち上げvs本番の品質
      • 事業成長vs技術的負債
      • 事業成長に振り切ったのは成功だった
        • 使われないと意味がない
    • システム拡張期
      • グローバルに拡大
      • 導入実績の拡大
      • 拡張性に課題あり
        • ますは技術的な課題を解消
        • その後止めていた機能開発を進めた
      • 自律は進んだがサイロ化が発生

不確実性に備える ABEMA の信頼性設計とオブザーバビリティ基盤

永岡 克利さん(株式会社AbemaTV)
山本 哲也さん(株式会社AbemaTV)
https://speakerdeck.com/nagapad/bu-que-shi-xing-nibei-eru-abema-noxin-lai-xing-she-ji-toobuzababiriteiji-pan

クラウドアーキテクチャ

  • 発展性を考慮してハイブリッドクラウド
    • 配信システムはAWS
      • メディアアセット管理
    • ユーザシステムはGoogleCloud
      • 行動ログ分析
      • レコメンド牙案
    • 一部システムはCloudflare
      • 画像変換
      • 仮想待機室
  • マルチリージョン
    • 配信は信頼性重視で東京/大阪/ソウル
      • 原則各リージョンに閉じたすステム
    • ユーザシステムは東京/大阪/台湾
      • 拡張性を重視して一部は台湾に
  • 透過的な活用
    • 開発者がどのクラウドか意識しなくていいように
    • k8sを中心としたマイクロサービス
    • addonでどのクラウドの差異を吸収
    • クラウドの統合された監視基盤

オブザーバビリティ

  • 統合監視基盤の課題
    • システムが複雑
    • 経験が浅いとどこで何が起こっているか判断できない
  • 分散トレーシングの課題
    • コストとのトレードオフ
    • head based samplingしていてほしいとレースがとれないことも
      • ランダムに選ばれるのでエラーのトレースが残らないことも
  • Grafanaの活用を強化
    • メトリクス/トレース/ログ/プロファイルをつなげるコストが高い
    • 開発工数が必要
      • これをやらないと辿ることができなくなり効率が落ちる
  • 潜在的な未知の検証
    • 製品はあっても有償でコストとの兼ね合い
  • SaaS連携強化
    • otelベースで連携を強化
      • 標準的な方式なのでいつでもSaaSを切り替えられる
    • Honeycombによる大規模トレースの効果的な分析
    • Datadogによるシームレスなシグナル探索と異常検知
    • tail based samplingで分析精度を落とさずSaaS落とさずコストを制御
      • エラーなどほしい情報化判断した上で後続に流すか制御
  • コスト課題
    • インフラコストの7%をモニタリングとオブザーバビリティに投資すると合意

オブザーバビリティ基盤

  • インフラ基盤の整備
    • Istioでtail based samplingができない
      • Istioにより大量のspanが生成される
      • Istioのトレースは全て捨てるという判断をした
    • マルチクラウド間のトレース
      • AWSX-rayGoogle CloudはGoogle Cloud Traceを使っていたのでつながっていなかった
      • otelベースにすることでつながるようになった
  • SDKの整備
    • 開発者による計装の負荷を下げたい
    • otelベースで共通SDKを作成した
      • 内部で使ってるプロトコルの統一などもその時に
      • W3CベースでOtelを任意のサービスに遅れるSDK
      • 設定は環境変数で制御できるようにしたのでコード上で変更する必要がないようになった
    • HoneycombとDatadogの併用
      • それぞれに情報を送らないといけない
      • 共通SDKの処理で2箇所にexporterされるように
  • オブザーバビリティ基盤の構築
    • コストを予算内におさめるにはサンプリングが必要
    • head based sampling
      • 確率で対象とするか判定
      • 統計的な情報はとれる
      • 必要な情報がとれないことも
    • tail based sampling
      • エラーやレイテンシーが高いなど条件をつけて対象とできる
      • 設定するために開発が伴う

AIで加速する次世代のBill Oneアーキテクチャ ― 成長の先にある軌道修正

市川 達裕さん(Sansan株式会社)
https://speakerdeck.com/sansantech/20251121-2

  • マイクロサービスの方針
    • 業務ドメインで分割
    • サービスごとのデータベース分割
    • 非同期で連携
    • 独自性と全体としての統一感のバランス
  • AIエージェント時代への適応
    • これまではアシスタント/今は自律的に行動
    • Vibe CodingかっらAgentic Coding
      • Vibe Codingでは中長期的な整合性や可変性が失われてしまう
      • 人間が目的と制約を提示し動かす
  • 開発プロセスのAI適用
    • AI活用の4原則
      • 常にAIを参加させる
      • 人間参加型にする
      • AIを人間のように扱う
      • AIの進化を前提とする
    • AI-Driven Development Lifecycle
      • AIが実行し人間が監視
      • AIがルーティンタスクを処理
      • 人間は課題解決や価値創造
    • マイクロサービスとの親和性
      • コンテキストサイズが小さく保たれる
      • チーム単位で管渠の整備ができる
  • マイクロフロントエンド化
    • モノリスなReactのSPAだった
      • コンポーネントは200を超える
      • リリースプロセスが硬直
      • オーナーシップが曖昧
      • AIが見るコンテキストも膨大になってしまう
    • 期待する効果
      • リリースの独立化
      • 領域ごとのオーナーシップ
      • 自律的なAI活用
  • AIの効果
    • プラス
      • 開発スピードの向上
    • マイナス
    • AIを活用するために

「アーキテクチャConference 2025(1日目)」に参加してきました

モダナイズの現実と選択:マイクロサービスが最適解か?

Sam Newmanさん

  • マイクロサービス
    • 技術ではなくビジネス領域を境界にすると独立していい
  • モノリス
    • 少しの修正でも全てをデプロイしないといけない
  • 分散モノリス
  • モジュラーモノリス
    • ここから初めて切り出していく

AWS特別企画】実践的アーキテクチャレビュー会 〜KDDIアジャイル開発センター・gumi・ソラコム 〜

山﨑 翔太さん(アマゾンウェブサービスジャパン合同会社)
伊野瀬 出さん(KDDIアジャイル開発センター株式会社)
清水 佑吾さん(株式会社gumi)
片山 暁雄さん(株式会社ソラコム)

エーザイ戦略子会社が挑む、社会課題に「新しい答え」を生みだすマイクロサービスアーキテクチャ

安藤 圭吾さん(テオリア・テクノロジーズ株式会社)

  • 認知症プラットフォーム
    • 健康な人が増えることによるいいサイクル
      • 医療介護費の削減
      • 介護負担の軽減
      • 労働力不足の解消
  • 発症リスクを下げる5finger
    • 食事/運動/認知トレーニング/社会的活動/血管リスク管理
    • これらの助けとなるアプリHugWayを作っている
  • アーキテクチャ
    • マイクロサービス
    • Google Cloud
    • AWSはBedrock
  • AIによる開発
    • マイクロサービス化された中で機能が小さいものはAIに自走させてみる
  • ポータビリティ
    • 個々のサービスが独立している
    • クラウド移行もスムーズにできた
  • API仕様
  • オブザーバビリティ
    • 専用のOtelサーバー
    • AI関連はLangfuseへ
    • それ以外はDatadogへ
    • アプリ側はOtelのライブラリに依存するだけ
  • AIとの会話
    • 買い物に行くと言ったら何を買いに行くのかと聞いてあげたり
    • AI側から話しかけてあげたり
      • 最初のメッセージを内部的にAIに送ってあげることで会話をスタートさせる
      • コンテキストなどをそこに入れておく
    • ユーザの意見を肯定し続けるだけにならないように
      • エコーチェンバー
      • 過去のやりとりをそのまま保存するのではなく偏りを除去する
      • 会話履歴を渡しすぎない
    • ペルソナの活用
      • ユーザ像を覚えさせて会話させる
      • 毎日同じ行動してるかのように固定されてしまう
      • 1ヶ月の予定を作成することで幅を持たせるよう工夫
  • AIコンプライアンス
    • 医療に関するやりとりをすることもある
    • 例えば副作用はと聞かれても応えてはいけない
      • 医師に聞いてと言わないと
    • ガードレールのすり抜けはゼロにはできない
      • プロダクトチームでアウトプットを検証
      • JaDHA(日本デジタルヘルス・アライアンス)のチェックリスト
      • リスクアセスメントシート
        • Difyでシートを埋めていく

三菱UFJ銀行アーキテクチャ戦略(エンタープライズアーキテクチャ~全行戦略~その後)

脇田 恭一郎さん(三菱UFJインフォメーションテクノロジー株式会社)

  • EAの取り組み
    • IT構築の都市計画
    • 中長期的で持続的な取り組み
      • 安心安定安全
      • 開発保守効率の向上
      • アジリティの向上
    • EA推進からガイドラインを出したりレビューをしたり
  • システムの複雑化肥大化
    • 160システムで1億5000万ステップ
    • あらゆる要望に愚直に応えて膨れ上がった
    • 分岐が大量の解読困難なコード
  • 人材問題
    • 大規模合併などを経験したそうが高齢化し抜けていく
    • このままだと数年で有識者がいなくなってしまう
  • 全行アーキテクチャ戦略
    • 2021年から指導
    • MUFG社長をトップに委員会を
    • 銀行システム部門とMUITだけでなく経営企画も巻き込んで現場の声を取り入れる
    • トップが社長なので各部門が協力的な方向に

AI x Platform Engineeringでスケーラブルな組織を作るには

橋本 和宏さん(株式会社タイミー)
https://speakerdeck.com/kazutb/ai-x-platform-engineeringdesukeraburunazu-zhi-wozuo-runiha

  • Platform Engineeringチーム
    • タイミーはチームトポロジーベースの組織構造
    • 開発チームだけでさばききれないタスクが多く出てきたのがきっかけ
    • 開発チームの認知負荷を軽減する
    • SRE/インフラエンジニアな職能
    • 支援のモデル
      • Embedded/Enabling/XaaS
      • Embeddedはリソースが足りなくなるので基本はそれ以外にしたい
  • PFEのスケール
    • 少数になりやすく詰まりやすい
    • タイミーでは7人で開発者の5%くらい
    • 属人化してボトルネックになることも
    • 人を増やしたとしてもそのオーバヘッドの問題もある
    • スケールのしかたが難しい
  • AI活用
    • インフラの情報をドキュメント化
    • AIに調査させたドキュメントを人が補足して仕上げる
    • IaCのコードとMCPでなんとかならないか?
      • 試した結果イマイチだった
      • 直接CLIを叩くような情報の方が強い
    • DevinなどがPFEの1人として振る舞ってくれることを期待
      • EmbeddedとEnablingを加速させることにつながらないか
      • PFE側の人の入れ替えなどの際にも役立つ

複数事業を支える共通ID基盤のデータ設計とデータ・ID連携のアーキテクチャ

浦野 勝由さん(ウェルスナビ株式会社)
https://www.docswell.com/s/WN_Tech-PR/KPG18L-2025-11-20-154347

  • ID基盤導入
    • マルチサービス化
    • 技術的負債
      • 各サービスで似てるが差分があるという状態
      • 難易度が高く保守が大変
  • ID基盤の設計
    • IDとメールアドレスを基板側でマスタとして持つ
    • 更新されたらイベント駆動で各サービスに連携する
    • 逆方向で更新する時はAPI
  • アーキテクチャ
    • 可能な限り外部システムとの結合度を下げる
    • 同期ではなく非同期でやりとりする

アーキテクチャの選択 ー <悩んだこと・変えたこと>

無秩序からの脱却

nrsさん(株式会社コドモン)
https://speakerdeck.com/nrslib/emergence-from-chao

  • 新規プロジェクト
    • アーキテクチャについて勉強してるような人がほとんどいない
    • まずは話し合うことからスタート
      • 今の課題を解決する手段があることの動機づけ
      • 変化への受け入れ度合いの確認
      • 視座を変える
    • 手本を作る
      • 簡単/中難度/高難度
    • ツール化してそっちに流れるように
  • 他プロジェクトへの展開
    • 新しいプロジェクトは過去のものを参考にされる
    • 成功してるとしっているとなおさら
  • 成功事例をスケールさせるために
    • 考え方の型を学ぶ

完璧を求めない意思決定

竹内 健太さん(株式会社SmartHR)
https://speakerdeck.com/bmf_san/wan-bi-woqiu-menaiyi-si-jue-ding-akusesuzhi-yu-ji-pan-niokeruzhi-yue-tonoxiang-kihe-ifang

  • 権限基盤
    • 開発効率
    • 統一的ユーザー体験
    • セキュリティ
  • マルチプロダクトで下図がどんどん増えていく
  • 従来の構成
    • モノリスで中央集権
    • プロダクト固有対応が難しい
  • 理想的なアプローチ
    • 各プロダクトが自律的に開発できるように
    • ただし制約は出てしまう
  • 落とし所の見つけ方
    • 制約を設計のパラメータとしてとらえる
  • ポリシーベースアーキテクチャ
    • 既存UIを維持しながらポリシー層を追加
    • 段階的に責務を分離していく
    • アクセス性gyの仕組みだけ切り出した
    • 中長期的な改善に向けた最初のステップ

LUUPの事業成長と変化の速さに耐えるモジュラーベースアーキテクチャの設計思想

安元 耀さん(株式会社 Luup)

  • 事業成長に伴う課題
    • データ量の増加
      • LUUPのポート数が3年で1000倍
    • 独自ドメイン領域が広がっている
  • モジュールベースのアーキテクチャ
    • モジュラーモノリス
    • 30以上のモジュール
    • 1つ目を品質高く作って模倣しやすく

DMMプラットフォームのAI推進を支える情報アーキテクチャ

玉澤 裕貴さん(合同会社DMM.com)

  • AX
    • AI Transformation
    • AIで業務を根本から再設計
    • 競争力と価値創造を高める
    • これまでは人が集めて整理していた
    • これからはAIが集めて提案し人が判断 3つの情報負債
    • 分散
      • データが散らばっている
        • 人もAIも探しづらい状態
      • 誰が責任を持つかが曖昧だしスピード優先で整理されない
        • そもそも設計思想がなかった
      • AIナレッジベースで一元化
    • 形骸化
      • 更新されず複数バージョンが並ぶことも
      • 誤ったデータを元にAIが処理してしまうことも
      • 陳腐化しないような仕組み作りが必要
      • リポジトリ管理する
        • AIにレビューもさせやすい
        • プロダクトの一部という認識にもなりやすい
    • 属人化
      • 暗黙知が特定の人の頭の中やDMに埋もれてる
        • AIも人も活用できない
      • 業務プロセスを見直して仕組みを作る
  • ドキュメントの活用
    • 同じリポジトリにドキュメントがあれば仕様通りに実装されてるかのチェックも楽にできる
  • AIの使い分け
    • 推測
      • 曖昧な情報から類推
    • 推論
      • 構造化された情報から導出
    • 機械的
      • ルール通り確実に
    • 土台を整えて推測させなくてすむようにすると安定する

「開発組織でアクセシビリティを進める技術 by SmartHR」に参加してきました

アクセシビリティチェックができるFigmaプラグインを作った

satakeさん(株式会社SmartHR)
https://docs.google.com/presentation/d/1UNMg-EAPKY5GQfQyIRkDXTv12s_jXvJS/edit

  • プロダクトデザイン企画室
    • デザインシステムの策定推進
  • 使いやすいプロダクトのために
  • うまく運用していくために
    • チェックリストが遠くにあると負荷や漏れが起きる
    • 探して確認して反映する
  • Figmaプラグインでチェック
    • チェックしたい対象を選んでチェックスタートすると結果が出てくる
      • 機械的な基準はこれでチェックできる
    • ガイドライン以外のことはLLMのチャット機能で聞けるように
      • こういう色の組み合わせは基準関係なく見えにくいことがあるとか

セマンティックHTMLで始める アクセシビリティ改善の基礎

hiro (@hiro0218)さん(株式会社ZOZO)
https://docs.google.com/presentation/d/1LkpbpQIsCiMxD167BJVk1tSxFx3-Ndvyo37q5KbFikE/edit
https://speakerdeck.com/zozotech/semantic-html-accessibility-basics

  • HTML要素が与える影響
    • divにonClickつけてボタンにしたら
      • キーボード操作できない
      • 支援技術が構造を理解できない
      • ブラウザ標準操作がきかない
    • buttonを使えばあらゆる課題が解決
    • 正しいHTMLを選ぶだけで誰でも使える状態にできる
  • セマンティックHTML
    • 単なる見た目だけではなく情報の意味を強化する
  • WAI-ARIA
    • HTMLだけで表現できない役割や状態を補助するもの
    • ARIAなしの方が悪いARIAを使うよりいい
      • とにかくつけておけばいいというものではない
    • 使い所
      • HTMLで表現できない複雑なUI
      • 支援技術に状態変化を伝える必要があるとき
    • APGを参考に実装するといい
  • どのように判断するといいか
    • どんな情報が含まれているか
      • 大きい文字は見出しなのかリード文なのか
    • 見た目でなく文脈で
      • 段落/強調/見出し
    • 正しい組み合わせ
      • pの中にdivは入れられないとか

持続可能なアクセシビリティ開発

azukiazusa (@azukiazusa9)さん(株式会社はてな)
https://docs.google.com/presentation/d/1i6H1g_LvDU9qSb4o45k_ycbd_I6o32n88lhyJFUka8s/edit
https://speakerdeck.com/azukiazusa1/chi-sok-ke-neng-naakusesibiriteikai-fa

  • 持続可能なアクセシビリティを目指してる
    • 誰が書いても80%満たすくらいなところ
  • AIが書くコードのアクセシビリティ
    • 基本的な部分は人が書くより品質がいい
    • 複雑な要素だと余計なことをしてかえって悪くなる
      • 無駄にariaをつけたり
      • linterなどではエラーにならないのでフィードバックを受けられず気づかない
  • 取り組み
    • コンポーネントライブラリ
      • アクセシブルなコンポーネントを用意してそれを使ってもらう
      • airaなど難しいことを自分でやらなくてよくなるように
      • ヘッドレスUIライブラリを使うのもいい
      • AIも使ったりマネしてくれるので相性がいい
    • ドキュメントの整備
    • ガードレール
      • linterやテスト

入社したばかりでもできる、 アクセシビリティ改善の第一歩

うな (@unachang113)さん(株式会社LayerX)
https://docs.google.com/presentation/d/1ltFeaex0_v8WZQq3cGlRGePGBGTgWQU4oiObcMRP2UA/edit
https://speakerdeck.com/unachang113/ru-she-sitabakaridemodekiru-akusesibiriteigai-shan-nodi-bu

  • 入社して最初の取り組み
    • アクセシビリティに興味がある人と認知してもらう
      • まず自己紹介で興味があると伝えた
      • slackチャンネルあれば入る
    • コードを読んでプロダクトをさわってみる
      • キーボードだけで操作できるとか
    • チームを観察する
      • フロントエンド/バックエンドもで職種が分かれてない
      • チーム外から修正が入ってくることも多い
  • 改善の取り組み
    • まずはセマンティックなHTMLに
    • Markuplintを小さくいれてみた
      • reviewdogでdiffだけに適用

アクセシビリティの向上がそのまま事業貢献になると良い

Pasta-K (@pastak)さん(株式会社Helpfeel)
https://docs.google.com/presentation/d/1trkBgfi-5jHzehXhGqX5oXftVMboe-ZvvsB4_GS9Y6c/edit
https://speakerdeck.com/pastak/akusesibiriteinoxiang-shang-gasonomamashi-ye-gong-xian-ninarutoliang-i

「JJUG CCC 2025 Fall」に参加してきました

開発と運用を楽にするSpring Boot on AWSテクニック集

Masatoshi Tadaさん
https://docswell.com/s/MasatoshiTada/537VVD-spring-boot-on-aws

テスト

  • ローカルでのテスト
    • 何も考えずに起動して動くのが理想
    • でも壁がある
    • DockerCompose
      • ミドルウェアのセットアップが入ったものを
      • spring-boot-docker-compose
        • 起動時に勝手にdocker composeしてくれる
        • テストの時も勝手に起動して停止してくれる
        • DBの接続情報などをapplication.ymlに持たなくて良くなる
    • モックとプロファイルでの切り替え
      • @Profile("local") とか @Profile("production") とか
      • ローカルは固定値返すなどのモックで
      • 本番は外部のサービスへ
      • application.ymlのspring.profiles.activeにlocalを指定する
      • 環境変数のSPRING_PROFILES_ACTIVEでも
    • Local StackでAWSサービスを再現
      • コンテナイメージが提供されている
      • AWSのセットアップのBeanをProfileで切り替えてLocalStackに向けるように

デプロイ

  • Amazon ECS
    • コンテナ実行環境
    • 永続的なアプリ/スケジュールドなバッチ
    • デプロイするためにはコンテナ化する
    • 用語
    • ecspresso
      • サービスとタスクをデプロイするCLI
      • クラスター/ロードバランサー/IAMなどはTerraformなど別のもので
      • Terraform連携も対応してる
      • Terraformだけでもできるけど
        • アプリだけデプロイできるのがいい
        • 想定外のデグレードを防げる
      • 薄いラッパーなのでECSのjsonそのまま書く感じに近い
        • 変数参照したりできるのが違う
    • ルートファイルシステムは変更不可にするといい
      • セキュリティ的な観点で
      • ただし組み込みTomcatは起動時にファイルを作るのでそれ用のボリュームが必要
    • Dockerfile
      • ベースイメージに脆弱性がないかは必ず確認
      • アプリ用のユーザを作成しそのユーザでアプリを実行する
        • 何も考えないとルートユーザで動いちゃう
      • 組み込みTomcatが使うフォルダをVOLUMEで指定
        • Buildpacksだとこれができない
      • imageのタグはコミットハッシュにすると内容と紐づいて便利
      • ecspresso deployでデプロイ
  • AWS Lambda
    • サーバーレス/FaaS
    • aws-lambda-java-coreを追加すればOK
    • RequestHandoerインターフェースの実装クラスを作るとそこがエントリーポイントになる
    • lambrollでデプロイ
      • ecspressoと同じ出自
      • Lambdaのコードだけをデプロイできる
      • 理由もecspressoと同じで想定外の変更をしてしまう心配がない
    • jarが50MB超えるとS3に置いてそれをアップロードすることになる

耐障害性

  • 自システム
    • マルチAZ
    • 負荷分散の問題
      • 異なるアプリにリクエストがいくとセッションがどれかに保存されてると問題になる
      • SpringSessinで外部ストレージにセッションを持てる
        • どのアプリに振り分けられても問題なし
        • 外部ストレージはRDB/Redis
        • MongoDBとHazelcastもあるがSpringチームがメンテしてるわけではない
    • SpringSessionの注意点
  • 連携先システム
    • 少し時間を置けば成功するタイプのエラーもある
    • Spring Retry
      • 7からcoreに入った
      • org.springframework.core.retry
    • リトライで考えること
      • どれだけ待たせていいのか
      • 待ち時間をどうするか
        • 固定とかだんだん増やしていくかとか
      • 最大リトライを何回にするか
    • 使い方
      • RetryTemplate
      • AOP

その他

  • 構造化ログ
    • ログはJSONにする
  • Microsoft Entra ID連携
    • ALBにEntraIDを設定
    • Spring Securityで設定
  • @SpringBootTest
    • テストは全てこれを使う
    • @WebMvcTest とか @JdbcTest などもある
      • AutoConfigurationの範囲を縮めてる
      • 効果は小さい割にハマると面倒なので使わなくていい
  • SpringBoot4.0
    • 2025/11/20リリース
    • 変更点がたくさんある
    • マイグレーションガイドを見るといい
    • ライブラリ名がリネームされてるもの
      • starter-webstarter-webmvc
      • starter-test が細分化されたり
    • RestTemplateが非推奨化
      • まだだけどいずれ使えなくなる
      • RestClientに移行する
    • Jacksonが2から3へ
      • パッケージ名とグループIDが変わる
      • ただしjakson-annotationsのみ変更されない

nullの10億ドルの過ちから未来へ:Spring Boot 4とJSpecifyが描くnull安全設計

  • 尾形さん(ウェルスナビ株式会社)
  • 藤原さん(ウェルスナビ株式会社)
    https://docswell.com/s/WN_Tech-PR/ZM6PPE-2025-11-15-125730

  • SpringBootのアップデートをしていて

    • 古いバージョンを使っているアプリが多くアップグレード対応
    • SpringBoot4でJSペシfy準拠のnull安全アノテーションが導入されることを発見
  • Javaとnull
    • 1995年にJavaが登場
    • その時からnullが導入されていた
    • 何も参照していない状態
  • Javaのnullの課題
    • 型システムでnullを判別できない
      • つまり静的解析で判定できない
    • null許容化明示されないので設計書やコメントで補足しないといけない
      • この変数はnull入れて良いの?という議論が起きてしまう
  • null安全アノテーションの乱立
  • Java標準のnull安全アノテーション
  • Optional
    • Java8から使える
    • nullの有無を型で明示的に表現できる
    • 値の存在確認が強制させる
  • Kotlinの台頭
    • null安全な言語
  • Helpful NullPointerException
    • java14から
    • 何がヌルポになったか分かりやすくなった
      • 具体的に何がnullで落ちたのか
  • JSpecify
    • null安全の標準化に向けた動き
    • null関連のアノテーションのライブラリ
    • 4つのアノテーション
      • @Nillable
        • フィールド/戻り値/引数などにつけられる
      • @NonNull
        • フィールド/戻り値/引数などにつけられる
        • これは基本使わない
      • @NullMarked
        • NonNullをつけて回るのが面倒
        • これをパッケージにつけると全部NonNullにできる
        • Nullableをつけるとそれで上書きれる
      • @NullUnmarked
        • パッケージやメソッドやクラス内がNullチェックの対象外になる
  • NullAway

間も無くリリース Spring Boot 4!

makingさん
https://docs.google.com/presentation/d/1qK72RCPPOM1ALKPb-NWgO9KP03XUcQOM_58NX_IiwG0/mobilepresent?slide=id.p

  • SpringFramework7が11/14にリリース
  • SpringBoot4が11/20リリース
  • OSSサポートは13ヶ月
    • 毎年マイナーバージョンを上げていくとちょうどいい
  • Spring Boot 4.0
    • Spring Framework 7.0
    • Spring Security 7.0
    • Spring Batch 6.0
    • Spring Data 2025.1
    • Spring Integration 7.0
    • Spring gRPCは1.1でSpring Boot 4.1に含まれる予定
      • Spring gRPC 1.0はSpring Boot 4に対応

Spring Boot4.0の変更点

  • モジュール化
    • 今までAutoconfigurationがモノリスで1つのjarだった
      • 機能が増えるにつれてサイズも増大
      • 保守性も悪くなった
      • 利用側でも必要ない機能が入ってしまったり時間がかかったり
    • 各技術ごとにjarが分割された
      • それに伴ってパッケージ名が変わった
    • アップグレード
      • Spring Initializrで改めて必要なモジュール選んで生成したものをコピーして持っていくといい
        • 何が必要なのかの選別が大変だから
      • 暗黙的に有効になっていたやつをもらさないように注意
        • ライブラリが内部的に使ってたとかもあるので
      • 過渡期用の全部入りセットもある
        • spring-boot-starter-classic
      • サードパーティがAutoConfiguration使ってたらライブラリ側が対応してくれるのを待たないといけない
  • Jackson3
    • 2から3に上がる
    • パッケージ名が変わる
    • ObjectMapperを使っていたとこがJsonMapperなどそれぞれ用意されるようになった
    • 例外がチェック例外から非チェック例外になって扱いやすくなった
    • 2は非推奨だけど使うことはできる
    • サードパーティが暗黙的に使ってることもあるので注意

Spring Framework 7.0の変更点

  • レジリエンス機能
    • リトライサポート
      • Spring Retryがコアに入った
      • Java Configクラスに@EnableResilientMethodsつけておくと有効化される
      • @Retryableでリトライの定義
      • @ConcurrencyLimitで同時実行数の制限ができる
  • APIバージョニング
    • headerでバージョン入れてもらって振り分けるようなケース
    • 従来は自前で振り分けてた
    • 設定とGetMappingなどに書いたversionでいい感じにできる
  • Interface HTTP Client
    • インターフェースベースのHTTPクライアント
    • 従来は同じような設定をコピペで毎回書かないといけなかった
    • 同じような設定をグループとしてまとめられるようになった
  • RestTestClient
    • WebClientに対応するWebTestClientのRestClient版
    • JSONのアサートできたり
    • どこまで組み込んだ状態で使うかバリエーションがある
  • JmsClient
    • JdmcTemplateに対するJdbcClientのJmsTemplate版
    • FluentなAPIで扱えるようになる
    • priorityとかtimetolieveを設定したいとかなると良さが見えてくる
  • BeanRegistration
    • プログラマティックにDIコンテナにBeanを登録する方法
      • ifとかforを使ってということ
    • 今までは1個ずつやってかないといけなかった
  • JSpecify
    • Null Saftyにする取り組み
    • GAになってSpring Framework7に入った
    • IDEやNullAwayで検出する
    • org.springframework.lang.NullableはDeprecated
    • フレームワークの内部は全部これに移行された
    • @NullMarkedをつけると全部NonNullになる
      • nullが入るものに@Nullableをつけていく
    • NullAway

AI駆動開発の最前線:GitHub Copilot Agent Mode と Coding Agent で実現する高速マイクロサービス開発

てらだよしおさん

  • AI駆動開発に適応できないといけない時代
  • マイクロサービスなECアプリをを数日で動くものまでできる
    • モノリスよりもマイクロサービスの方が相性がいい
  • AIコーディング
    • 同じ指示でも結果が違う
    • Vibeコーディングは運任せ
      • やらせるにしても仕様をしっかり書いて単位を小さく
    • 設計仕様を作らせる
    • 実装計画をたてさせる
  • GitHub Copilot Agent Mode
    • VSCode上でプロンプト渡して動かすやつ
  • GitHub Coding Agent
    • issueに作業を登録
    • copilotを担当者にアサイ
    • そうするとコードを書いてプルリクエストを作ってくれる
    • プランに応じてAPIアクセスの上限などもあるので注意
      • 4並列くらいならできる
    • 内部的にはGitHub Actionsが動いてるので注意
      • 課金も対象
    • 仕様書をしっかり作っておくことが重要
      • つまりやることが決まっているような場合に強い
  • AIとの向き合い方
    • AIは嘘を付くしごまかすし壊してしまう
    • 常に検証/テスト/レビューを実施する

アーキテクチャと考える迷子にならない開発者テスト

irofさん

  • テストは難しい
    • テストエンジニアと呼ばれる専門家がいるくらい一大トピック
    • 片手間でできるようなものではない
  • 開発者とテスト
    • 誰もがテストと向き合ってる
    • スペシャリストになるのは難しくても知識を取り入れる必要がある
  • 開発者テスト
    • 今回の話のスコープ
    • 作ったものが思ったとおりに動くか自分でやるテスト
  • アーキテクチャは難しい
    • アーキテクトと呼ばれる専門家がいるくらい一大トピック
    • 片手間でできるようなものではない
  • アーキテクチャという言葉の曖昧さ
    • 抽象的な概念
    • 構造をモデルで表したとしても単一に定まらない
    • 複数同時に存在することもある
      • 切り口によっていろいろ
  • アプリケーションアーキテクチャ
    • 今回の話のスコープ
  • アプリケーションを構造で捉える
    • 言語構造
      • Javaだとパッケージがあってクラスがあってメソッドがあってみたいな
      • この構造はテストにあまり役に立たない
      • メソッドしか見ない
      • メソッドのテストが最小粒度
    • アーキテクチャを捉える
      • Controller - Service - Repository
      • それぞれに暗黙の期待がある
      • 各レイヤーに役割をもたせるのがアーキテクチャ
    • テストの意味とコツ
      • こういう欠陥を見つけたいという視点でテストが存在している
      • 関係ない理由で結果が変わらないような紛れが少ない状態でテストする
      • 見つけ痛い欠陥の近くでテストする
        • そうすれば原因が分かりやすく修正しやすい
  • テストする範囲と道具
    • 自分の作ったコードで存在し得る欠陥を考える
    • その欠陥がないことを確認するテストを書く
    • アーキテクチャに持たせている意味が成立していることを見ていく
      • 意味があれば各レイヤーで何をテストするべきかが分かりやすくなる