「フロントエンドカンファレンス東京✕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

「JaSST'26 Niigata」に参加してきました

感想

  • 今回で3回目の参加でした
  • LTが増えたりセッションがいつもより多くて楽しめました
  • 懇親会でいろんな会話ができたのがためになりました
  • 食事が豪華でまた新潟に行きたくなりました

LT

Explore It!

じゅんぺーさん
https://speakerdeck.com/sadonosake/explore-it

  • 集中してると大事なものに気づきにくい
  • 仕様通りに確かめるチェックはAIが得意な領域
  • 誰も気づいていない価値やリスクを見つける探索が求められる
  • 探索的テストが重要な技術に

AI駆動開発におけるテストのトレーサビリティ

江尻 好治さん(enehain)
https://speakerdeck.com/ejirikoji/ai-kudou-kaihatsu-niokeru-tesuto-no

  • トレーサビリティ
    • 要件とテストと実行結果の紐づき
  • AIで機能とテストが大量に増えるとどの要件が検証済みか把握が難しい
  • 仕様書からテストを考え実装させることで紐づける
  • 要件以外からのテストもある
    • 過去の障害やプロジェクトリスク

プロンプトの良し悪しを数値で判断してみた

komatsunaさん(メルペイ)
https://speakerdeck.com/komatsunaqa/no-yoshi-warushi-o-suuchi-de-handan-shi-te-mita

  • テスト設計を生成するプロンプト
    • 1つのツールを多くのメンバーが使うようになった
    • フィードバックを受けて反映して仕様書も修正するのが大変
  • 人が読み比べずにAIで数値化する
    • 退行を検知できるように

エンジニアのAI利用実態と障壁を調べてみた

山田 涼太さん

  • AIが組織にどれくらい価値をもたらしてるか
  • 利用実態と阻害要因
    • チームの中でも個人ごとに利用状況は違う
    • skillsを共有する環境が整ってない

APIテストをAIスキルでやろう

すずき しょうごさん(マネーフォワード)

  • APIのテスト設計

基調講演:AIに任せた品質は、誰が見立てるのか ── AI時代のテストマネジメント

中野 直樹さん(LayerX)
https://speakerdeck.com/nakanao/ai-ni-makaseta-hinshitsu-ha-dare-ga-mitateru-no-ka-ai-jidai-no-tesuto-manejimento

  • AIはテストの作業をやってくれる
    • 品質に責任は持てない
    • AIがやって人が責任を持つための技術がテストマネジメント
  • AIに任せること
    • 優秀な新人に仕事を任せる感覚で
    • 言わなくても伝わることはない
    • 会話の文脈から拾って理解することができない
    • 任せ方は新人と同じでも伝え方は変えないとダメ
  • 従来のテストプロセスでの最適化
    • リスク
      • 発生確率と影響度で数値化して評価
      • 本来は本番障害が起きた時の損失額
    • 文書
      • テスト計画は要点
      • 詳細は他文書とコミュニケーション
    • 判断
      • 判断基準や優先順位や許容範囲はコミュニケーションで決定
  • AIに全部任せると
    • QCDSのうちCの制約が外れた
    • スコープを広げるようになってくる
    • 人の工数の制約が外れて新しい戦略を試せるようになった
      • 新しいテストピラミッドがあるかも
  • テスト計画
    • Agile型:1.5ページで内容が薄い
      • 参照がついて分散しているだけ
      • 書かれていない前提は口頭で補う
    • Traditional型:7ページ
  • テスト設計
    • 決めることと書くこと
    • AIがやること
      • 仕様を調べて機能を洗い出す
      • テスト計画とケースを作る
      • 実行して記録して報告
    • 人がやる
      • リスクと判断基準を渡す
      • 計画を確かめて実行していいか決める
      • AIが迷った項目を判断する
      • 探索的テスト
  • テスト実行
    • 実行と検証を分けて考えると良い
      • 結果の記録だけだと終わったということしか分からない
      • 検証の記録を残させる
    • 何を正常とするかを人が決めておく
  • テストレポーティング
    • レポートから何を知りたいか
      • 残存リスク
      • 判断の根拠
    • AIに作らせるテストレポート
      • 確かめたこと確かめてないこと
      • 減らしたこと
      • 人の判断がいること
      • 残存リスク
  • 成果物のレビュー
    • 最終成果物だけでは妥当性は判断できない
    • 中間成果物が判断材料になる
  • テストの精度改善
    • テストの十分性が最も問われるのはテストを減らす判断
    • テストケースを減らしたことで落ちたとしても気づきにくい
      • 減らせる根拠を残しておかないといけない
    • コードカバレッジではユーザ価値は測れない
      • 誰が測ってもぶれない次のカバレッジの発明が求められる
  • AIに任せると
    • どの工程も評価する側がボトルネックになる
      • 1言って10返ってくる人ができる人だった
      • AIは1言って1000返ってくる
      • 評価する仕組みの設計が必要
    • 入力と出力が直接つながる作業はAIに任せていけそう
      • 同じ入力でも状況が変わる仕事は人のコントロールが必要

プログラミング未経験者を含むQA組織で、コードベースE2E自動テストをどう始め、どう続けるか — “書ける”と“続く”の間にある運用設計

山口 鉄平さん(LayerX)
https://speakerdeck.com/teyamagu/starting-and-sustaining-code-based-e2e-testing-for-non-coding-qa-teams

  • 自動テストの普及
    • みんなで書いていこうと言っても難しい
    • 1人が型を作りきって広めるアプローチ
  • 自動テストを1本書くまでのハードル
    • ファイルをどこに置くか
    • テストケース名メソッド名
    • 処理の共通化
    • 待ち方
    • ロケーターはどれを選ぶか
    • アサーションの粒度
    • これらを自分だけで決めていいのか
  • 普及の工夫
    1. 型を作り切る
      • ルールやガイドやサンプルを作る
    2. 巻き込む
      • 判断がブレないように1人がレビュー
    3. 軌道に乗ってきたら
      • 1人でのレビューをやめる
  • 型を作り切る
    • コピペ&モディファイでテストケースを書ける状態
      • ロケータの優先順位
      • 新規ファイルの命名規則
      • 要素の変数の命名
      • 名前は情報が揃うと自然と決まるように
    • 作成ガイドとコーディングルール
    • 主要フローを含むテストケースのサンプル
      • テストケースの設計書へのリンク
  • 巻き込む
    • ペアプロでセットアップから
    • やって見せながら考えていることを実況する
    • テストが少ない時は品質と一貫性を維持
      • コピペする時に迷わないように
    • 書く人同士のレビューに移行

確率と戦うAIプロダクト〜「守り」と「攻め」を分ける2層テストアーキテクチャ〜

松山 晃大さん(LayerX)
https://speakerdeck.com/matsu802/jasst-26-niigata-kakuritsu-to-tatakau-ai-purodakuto

  • AIを組み込んだプロダクトは確率的
    • 同じ操作でも結果がブレる
    • 時間の経過でLLMが変化して結果が変わる
  • テストのアプローチ
    • pass/failではなくスコアで判定
    • リリース後も精度を測り続ける
      • 変更がなくても測る
      • 差分で検知
      • 評価を育てていく
  • AIによる有給付与ルールの登録
    • 就業規則から条文を検出しルールを取得してデータを登録
  • 品質定義の作成
    • QA4AI.Guidelines
    • System Quality
      • システム全体の信頼性
      • 受け入れ基準のような
    • Accuracy
      • 精度を評価するための基準
    • Customer Expectation
      • ユーザの期待値に対する仮説
  • テストを2層にわけた
    • 壊れていないことを確認するテストと精度を伸ばすためのテスト
      • 前者は結合テストで後者は単体テスト
    • 用途が違うから扱い方が違う
      • スコープ
      • 実行頻度
      • 判定基準
  • 結合テスト
    • runn
    • システム全体の動作担保
    • APIにリクエスト送ってレスポンスを判定
    • 絶対値でスコアリング
  • 単体テスト
    • Langfuse
      • LLMアプリの監視評価プラットフォーム
      • プロンプトの管理も出来るのでアプリのリリースを待たずにテスト出来る
    • プロンプトの変更を検知して自動実行
    • 出力を検証し相対値で判定

QAエンジニアの暗黙知を可視化する:自動テスト戦略とAIの差分から見えたもの

髙橋 諒さん(LayerX)

  • AIコーディングで機能開発の速度があがった
    • リリース辺りの機能が増える
    • 複雑機能が短期間でリリース
    • リグレッションテストの範囲が広がっている
  • リグレッションテスト
    • 手動テストだけでは時間が足りずに回らない
    • 自動テストをAIで実装することは容易になったがメンテコストが増えていく
  • 自動テストをどう増やしていくか
    • 何を自動化する
    • レイヤーをどう分ける
    • 優先度をどうつける
  • 自分とAIで認識を合わせてテストを作りたい
    • それぞれがどこをどう設計するかやってみて比較
    • 手動でやる領域と自動でやる領域
    • テストレイヤーの配分

「AIエージェントマニアNight #5 〜AIエージェント×UXデザイン〜」に参加してきました

AI時代に改めて考える、「良いデザイン」とは?

伊藤セルジオ大輔さん(株式会社マネーフォワード)

  • デジタルツールとAIエージェントの違い
    • 決まった項目を入力してたところが指示をして埋めてもらうへ
    • 決まった形式で表示していたのが依頼に応じて内容も量も変わる
  • 品質レベル
    • 機能がある - 使いやすい - 心が動く
    • エージェントだとこれらも変わってくる
  • 良いデザインはユーザの理解からということは変わらない
  • デザインプロセスの変化
    • これまでは職種ごとに専門性をつないでいく
    • 今は職種を問わず形にして動くものを前に協働
  • デザインハーネス
    • デザインの実装とレビューのセット
    • agentの設定やskillなど
    • PRDを渡すとプロトタイプの作成まで
    • 回しながら知識を蓄積していく
    • 良いデザインの定義はプロダクトによって違う
    • 機械的に判断できることは自動で
      • デザインシステムに則ってるか
    • 人が見ないといけないことは人が
      • 使いやすさ
      • 情報の優先順位
      • 認知負荷の適切さ
      • ブランドらしさ

実践に見る、デザインの態度変容

田中 裕一さん(株式会社MUSUBI)

  • 自身の役割を主とした越境
    • デザイン - エンジニア - プロダクトマネージャー
    • 境界を動かすという感覚ではない
  • 価値のかたまりの中にみんな入っている
    • その中で自分たちが何をできるかそれぞれとっていく
    • 見えやすい近い位置からで
    • 経営者の視点だと区切られない
    • 職能の形にとらわれずみんなでいいものを考える

テーマトーク「AIエージェント×UXデザインの現在地と未来」

伊藤セルジオ大輔さん(株式会社マネーフォワード)
田中 裕一さん(株式会社MUSUBI)
山本 大策さん(株式会社マネーフォワード)

  • 信頼と納得感をどうデザインするか
    • 信頼は時間をかけた積み重ね
    • ストーリーを描いて作ることは人の方ができる
      • 関係性のコンテキストをとらえたデザイン
  • 非デザイナーがデザインする時代のデザイナーの価値
    • 価値が増える減るというより職能の在り方が変わる
    • エンジニアなんかも同じ
    • デザインに責任を持つ立ち場
    • ビジネス/デザイン/エンジニアリングを全て1人で満たすのは難しすぎる
    • 補完し合いながら働いていくのは変わらない
  • 3年後のデザイナーの仕事
    • ビジョンドライバー
    • デザインガバナンス
    • アーティスト/インスパイアー
    • コミュニケーター

「Frontend Conference Fukuoka 2026」に参加してきました

日経電子版を支えていく Kasane Design System

田中 泰斗さん(株式会社日本経済新聞社)
https://speakerdeck.com/nikkei_engineer_recruiting/fec-fukuoka

  • 日経電子版
    • 有料会員106万人
    • 毎日1000件の記事が出る
    • 毎日Webだけで3000万リクエスト
  • 日経電子版のデザインシステム
    • アクセシビリティ
    • AI活用
    • デザインと実装のブレをなくし民主化
      • エンジニア/デザイナー/企画やPdMも
  • 日経グループのデザインシステム
    • Origami
      • 買収した会社のデザインシステム
    • NikkeiUI
      • 2016年
      • 当時の技術スタック
        • Sass,Handlebars,Fractal
      • IEも考慮
      • これはメンテされず続かなかった
  • デザインシステムが続かなかった理由
    • 事業要件が複雑化
    • アプリケーションの肥大化
    • リソースの限界
    • 組織再編でチームが解散
    • 1人のスペシャリストに頼ってしまっていた
    • 技術の変化に追従できず
    • プロダクトの技術刷新に取り残された
  • 過去からの学び
    • 無理のない体制
      • 全社的なデザインシステムとしない
        • ステークホルダーが多すぎる
        • 日経電子版のみを対象に
      • 最小限の人数で集中的に
        • 多すぎても少なすぎても難しい
        • エンジニア2人とデザイナー2人
        • 意思決定をはやく
    • コンテキストを残す
      • LLM WIKI
      • notionやslackやfigmaなどに散らばった情報をWIKIに
    • Web標準によせる
      • 後方互換性
      • 特定ライブラリに依存しない
  • Kasane Design System
    • 設計思想
      • 堅さ/快適さ/明快さ
      • 時事性にこたえる
    • 設計原則
      • ブランディング
        • デザイントークンから参照
          • ブランディングを整えて定義されてる
        • 規約を読まなくてもブランドイメージを守れる仕組み
        • 変えられないものを決めて仕組みで自由を縛る
      • 機能面
        • アクセシビリティ
        • パフォーマンス
        • アニメーションは最小限に
      • 利用者に向けて
        • 使う人にとっての選択肢を最小限に
        • 新しい機能を足す時は削ることも考える
        • 新しい独自の言葉を生み出さない
        • 世間のUI慣習
    • 技術スタック
      • TypeScript
      • Vitest, Chromatic, Storybook
      • Oxlint, Oxfmt, Stylelint
      • pnpm workspace
    • デザイントークン
      • Design Tokens Specificationに準拠
      • Component - Semantic - Primitive
      • tokenからcssを生成しReactとWeb Componentsで利用
    • 実装
      • ReactとWeb Components
      • JavaでJSPのプロダクトでWeb Componentsを使っている
    • カラーパレット
      • WCAGとAPCA両方を考慮
        • APCAも見てるのはダークモードを意識して
        • WCAGを満たしていても見づらい場面がある
        • オレンジ色がWCAGだと判定が厳しい
        • https://huetone.ardov.me/
      • OKLCH
        • 色ごとの同じレベル感でコントラスト比が揃いやすい(異なる色の100同士とか200同士とか)
        • 同じ明度であれば色相が異なってもコントラスト比が概ね揃う
      • ライトモードとダークモード両方でのチェック
    • フォント
      • 和文と英文のウェイトを揃えたい
      • 英字だけ太く見えてしまいがち
        • font-weightのどの値を持ってるかの違い
      • 独自のHiragino Sans JPを採用
        • 和文だけにHiragino Sans
        • 欧文はSan Franciscoにフォールバック
      • WindowsでMeiryoからNoto Sans JPへ
        • Meiryoは古くからあるフォント
        • 低解像度で明瞭に見えるというものだった
      • 行頭記号の文字詰め
        • text-spacing-trim: trim-start
        • 「や(などが行頭に来ると隙間が空いてしまうのを整える

Webプラットフォームで議論されているセキュリティ課題

森内建太さん(pixiv)
https://speakerdeck.com/petamoriken/security-issues-being-discussed-on-web-platforms

  • DOM Clobbering
    • document.xxx は <img name="xxx" /> を拾ってしまう
    • document.currentScript とかやろうとした時に差し替えられて何か被害にあったり
    • Document-Policy ヘッダーでこれを防ぐ仕組みが考えられてるが進んでない
  • Prototype Pollution
    • 全てのオブジェクトはprototypeを持っている
    • prototype経由で任意のプロパティを生やすことができてしまう
    • これを利用することで攻撃につながってしまう
      • isAdminにtrueを勝手に付与してみたり
    • polyfillを読み込むのには便利
      • polyfillを読み込んだら凍結したい
      • Object.freezeでwritableをfalseにすると凍結できる
      • ただ副作用が大きすぎる
      • たとえばlodashが壊れる
      • Object.stabilize で安全にフリーズ
        • ただあらゆるものに当てないといけない
        • stage1の lockdown() でまとめてやれる提案
        • Secure ECMAScript(SES)
  • Thenable
    • Promiseが入る前のES5.1の頃はjQueryなどのライブラリで似たことをやっていた
      • Promise/A+としていろいろなライブラリでサポート
      • その後Promiseやacync/awaitなど取り込まれた
      • thenを特別なものとして扱うようになったということ
    • thenがexportされたモジュールをDynamic Importすると壊れる
      • 修正しようとするとライブラリが壊れる
        • Comlinkで副作用のあるthenable
      • DOMとの境界で防ぐようにする提案
        • WebIDLに限定して対応を進めてる
  • TC39のTask Group
    • TG1-5のうち3がSecurity

Webの地図

古川陽介さん
https://speakerdeck.com/yosuke_furukawa/web-no-chizu

  • fetchAPIはなぜECMAScriptに入ってないのか
    • fetchはWHATWG
    • DateとかMathはECMA
  • Webをとりまく言語の仕様は多様
    • HTMLはWHATWG
    • CSSはW3C
    • JSはECMAScript
    • HTTPはIETF
    • でもどこで定義されてるかは知らないと困ることはあまりない
  • Before Web
    • 論文や資料は各々で保存してアクセスしてた
      • それぞれの方式で保存してビュアーで閲覧して
      • 共通化しようとしていたが決定打がない
    • 1990年に最初のWebブラウザが誕生
      • Tim Berners Lee
      • ここがWorld Wide Webの始まり
    • 最初のブラウザ
      • 共通のファイルフォーマット:HTML
      • 共通の通信:HTTP
      • 共通のアクセス表現:URL
  • 1990年代のブラウザ
    • 大学など研究機関を中心に
    • 1993年Mosaic Browser
      • 画像とテキストを同じブラウザで
    • 企業が商用ブラウザを出し始める
      • Netscape
      • Internet Explorer
    • HTMLの仕様をIETFで発行(後に失効)
      • 独占されないように強者を縛る鎖
      • HTML, HTTP, URLが仕様化
    • マルチメディアへの対応後装飾表現が増える
      • 文書と装飾は分離されるべき
      • HTMLだけに使うとも限らない
      • CSSが誕生
    • IETFから独立してW3Cを発足
      • HTMLとCSSはここで
    • Netscapeが商用ブラウザを作るのに多くの表現を求めてきた
      • プログラミング言語が動けばダイナミックな表現
      • Javaのような言語をブラウザで
      • ブレンダン・アイクがJavaScriptを一週間で開発
    • ブラウザの差別化と混乱
      • MicrosoftはIEにJScriptを同梱
      • JavaScriptと文法は似てるがAPIは違う
      • Windowsが流行ってMicrosoftが強者の時期
      • Microsoftが一強にならないようにJavaScriptをW3Cに持っていくが断られる
        • ECMAに参加し国際標準へ(1997年)
  • 2000年代の変化
    • ティムがXHTMLを提唱
    • HTMLをXHTMLに移していこうとしたがその後廃盤になる
      • WHATWGに吸収されHTML5に取り込まれる
    • 仕様策定に時間がかかりすぎた
      • ブラウザベンダーがしびれを切らしてW3Cじゃない団体で仕様を決める
      • HTMLの仕様がWHATWGへ
    • Webブラウザを文書だけでなくアプリケーションとして使う動き
      • Web2.0
      • ajax
      • XMLHttpRequestはIEの独自実装が始まり
      • Mozillaも互換性をもたせる
      • Ajaxと名付けられる
      • その後XMLHttpRequestはW3Cで策定
        • WHATWGに引き継がれた
    • 2008年にGoogle Chrome
    • DOM
      • ブラウザごとにdocumentオブジェクトの中身が違う
      • W3Cが標準化
      • なんでECMAじゃなくてW3Cなのか
      • JavaScriptはコア機能と実行環境によって必要なオブジェクトを分けて考える設計
        • ブラウザの一機能だけとして考えていたわけではない
        • ブラウザでもサーバでも
      • なのでDOMはECMAScriptには含まなかった
        • documentがECMAに入らず拡張され続けていてW3Cがまとめた
    • W3C/WHATWGはブラウザの仕様しか決めてない
      • 最近はWinterCGなどでブラウザとサーバを合わせる動き
    • fetchは実行環境として切り離されたものという扱いなのでECMAじゃない
      • XMLHttpRequestはIEの独自実装から始まり、W3Cで策定されたのでWHATWGに引き継がれた
  • fetchの仕様
    • 単にHTTPリクエストを送るだけのものではない
    • クロスオリジンとかクッキーとか仕様に含まれてる
      • これらはブラウザ固有の話
    • なので共通的なコアであるECMAにあるのは違和感がある

ウェブコンポーネントの進化

丹羽亮介さん(Apple)

  • WebComponents
    • コンポーネントを隔離することができる
  • v0時代
    • Web向けのコンポーネントモデルを定義する試み
    • さまざまなブラウザで取り組まれていた
      • ベンダー固有だし広まらなかった
    • テンプレート要素
      • <template>
      • これはずっと安定している
      • レンダリングされず再利用できるマークアップ
      • 単体では機能せずscriptで利用する
    • ShadowDOM
      • HTMLのカプセル化
      • ブラウザ標準のDatePickerで使われた
      • それが公開された
      • CSSを外の世界と隔離できる
      • shadowRoot作ってinnerHTMLで挿入する
      • v0では同じshadowRootに複数回createShadowRootを呼べる
        • コンポーネントの継承
        • 何がレンダリングされるか把握するのが難しい
      • v0では :: や /xx/ でカプセル化を貫通してCSSを適用できた
        • コンポーネントの中身を気軽に変えられなくなった
    • カスタム要素
      • document.registerElement("my-element", { prototype: myPrototype })
      • v0の当時にES6のクラス構文が出た
      • classのextendsに対応してなかった
      • 悪いAPIではなかったがclassと噛み合わずすでに時代遅れ
    • HTMLインポート
      • <link rel="import" href="my-card.html">
      • <my-card> として使える
      • htmlにhtmlをimportできる
      • v0の当時にES6モジュールが登場した
      • import構文や動的読み込みなど便利な機能が出てきていた
      • これに対応していなかったのでCustomElementsと同じで時代遅れに
  • v1で基本コンセプトはそのままに再設計
    • ShadowDOM
      • contentをslotに変更
      • attachShadowは1つしかできない
      • 貫通はしなくなった
        • コンポーネント側が外部から設定可能なスタイルを宣言する
    • カスタム要素
      • ES6のクラスを使って定義
      • HTMLElementをextendsして作る
      • newすることで使える
      • コンストラクタを経由して使われることに
    • HTMLインポート
      • v0はChromeでしか実装されず結局削除された
      • <script type="module">
      • ES6のモジュールを使う方向になった
  • ブラウザ相互運用性
    • v0で正しかったこと
      • テンプレート要素
      • ShadowDOMのカプセル化の考え方
      • HTML要素として再利用可能なコンポーネントを作ること
    • v0が普及しなかった理由
      • ShadowDOMをポリフィルで再現するのが困難
      • スピードははやいがchrome以外がついてこれなかった
    • v1は3ブラウザで実装された
      • ポリフィルやエミュレーションが不要
      • ReactやLitなどなど多くのによるサポート
  • ロングテールな普及
    • カスタム要素はフォームで使用不可に
    • カスタムステート
      • ステートに応じてCSSを切り替えたりできる
    • WebComponentsをアクセシブルに
      • 従来対応できてなかった
        • ShadowDOMの隔離の弊害
      • JSを使って対応できるようになった
        • ShadowDOMの外と中でaria-labelledByなどのIDでの紐づけ
    • Declarative ShadowDOM
      • SSR対応
      • templateにカスタム要素の内容を書いておくとJS読み込み前にそれが表示される
    • スコープドカスタム要素の登録
      • 同じ名前のコンポーネントが読み込めなかった
        • ライブラリの都合とか新旧の以降とかで発生し得る
      • CustoomElementRegistryとして対応が進んでいる

Web エコシステムとサイバースペース地政学

Jxckさん

  • JavaScriptのエコシステム
    • npmのパッケージが大量にある
      • 他の言語と比べてもかなり多い
      • 40万パッケージ
    • アプリケーションを作ると言っても自分で書かないコードが多い
  • npmパッケージ
    • モジュールを分割してnpmにあげてそれらをつなぎあわせて開発するスタイル
    • みんなで細かく分割して組み立てて使う文化
    • 欲しいと思ったものはだいたいある
  • セキュリティ上の問題
    • 依存の数だけリスクがある
    • 攻撃側のエコシステムが発展している
    • 機密情報をかき集めてその人のGitHubアカウントで公開リポジトリにpushされたり
    • 報道されてるような重大事案になってしまうことも
    • npmの文化的に成功率が高いから狙われやすい
  • パッケージ管理での対策
    • pnpm使うようにしたり
      • minimumReleaseAge設定したり
      • provenanceをチェックする?
        • やってるパッケージがどれだけあるか
      • postinstall止めたり
    • NXの事案
      • 開発者が気づいて対処するまでに4時間かかった
      • 利用者が多くその間にインストールしてしまった人が多くいた
      • アクティブなパッケージでこのスピード
      • アクティブでないパッケージで起きたらどうなっていたか?
      • minimumReleaseAgeは根本的な対策になってるのか?
    • 結局決定的な対策はできない
  • 感染することは防げないから感染しても問題ないように対策する
    • 今はクレデンシャルを盗んでるがユーザ権限とられてたら何でもできる
      • ワンパスワードに移すだけとかは本質じゃない
    • デスクトップ/ドキュメント/ダウンロードのファイルをとられる
      • 企業としてはとられた時点でアウト
    • コンテナ環境で開発するか
      • ワンパスワードが届かないから仕組みがややこしくなっていく
      • これはしょうがないというのが出てきたらそこから芋づる式
    • エンジニアたちがガチガチにやったとしても隣の非エンジニアはAIの言われるがままにやってしまう
      • その人たちまで守れないと企業としては守れてると言えない
  • npmにパブリッシュする人が被害にあわないようにできないか
    • npmの2要素認証は必須に
    • approve複数とか仕組み化してるところも
    • でもどれだけのパッケージがそれをやっているか
    • パッケージ公開側の負荷も高い
      • 大きな何かの依存に含まれてしまったら
      • 自分のパッケージが原因で多くの人に被害が出てしまったら
  • これからのパッケージの公開
    • OSSに不足があると感じた時にコントリビュートするよりも自分で新しく作れちゃう時代
    • 作ったものを公開するよりもそのアイデアを公開すれば誰でも作れる
    • パッケージを公開するという動機が減ってきている
  • セキュリティハーネス
    • mythosやClaude Securityなど自分たちでチェックしていかないといけない
    • 依存の先にあるとスキャンの対象にできない
    • 自分で作ってればチェックできるからセキュアなのでは
    • Reactを丸ごと再現する?
      • トークン的にも厳しくなる
      • 経済合理性の分岐点がある
  • 安全なパッケージの公開
    • 資本のあるところは自分でスキャンして安全であることを保証したものを自分で公開もできる
    • プラットフォーム側に機能として入ってくれるのが一番嬉しい
      • Nodeやブラウザ
  • 攻撃者が経済合理性がなくなった時に初めて安全になる
    • 使う人がいなくなった時?

杜甫々が語るフロントエンド開発技術の歴史と今後

杜甫々さん

Reactの設計論

うひょさん(株式会社カオナビ)
https://speakerdeck.com/uhyo/react-no-sekkeiron

なぜJavaScriptは異常なほど速いのか?

Sosuke Suzukiさん

なぜテストを書くか?

lacolacoさん
https://docs.google.com/presentation/d/1nlYpJ3cgt1LEUNnyGZCfHTt_AGfWHplQZCQpfvjOqHE/preview

歴史から紐解くデザインとマークアップの話

ゆうてんさん

How browser engines get made

sideshowbarkerさん

フロントエンドUIフレームワークのこれまでとこれから

ssssotaさん(株式会社ZOZO)
https://speakerdeck.com/ssssota/frontend-ui-framework-futures

AI時代のWebフレームワークはどこへ行く?

Yusuke Wadaさん(Cloudflare)
https://slides.yusu.ke/web-frameworks-in-the-ai-era

AI Agent時代のリアーキテクチャ戦略と実践

hokacchaさん(Ubie Inc.)
https://speakerdeck.com/hokaccha/ai-agent-jidai-no-senryaku-to-jissen

ツールチェーンから見た新JS仕様の難所

翠さん

Webで実用的な縦書きエディタは可能か?

コサキンさん(サイボウズ株式会社)
https://speakerdeck.com/karintou8710/web-de-jitsuyoutekina-tategaki-edita-ha-kanou-ka-genzaichi-to-fukyuu-ni-muke-te

安心して変更できるWebフロントエンドのつくり方

穴井宏幸さん(株式会社LayerX)
https://speakerdeck.com/pirosikick/anshin-shi-te-henkou-dekiru-web-furonto-endo-no-tsukurikata

速さを追い求めたらHTMLになった

菅原孝則さん(Studio)
https://speakerdeck.com/ts020/hrc-frontend-conference-fukuoka-2026

「Qiita AI Summit AI駆動開発を実現するエンジニアリング戦略」に参加してきました

PoCで終わらせない 〜バックエンド起点のAI駆動開発で、本番運用までもっていく〜

加藤 健太さん(株式会社ディバータ)

  • kuroko
    • ヘッドレスCMS
    • MCP接続してAIツールから使える

プログラマーがコードを書かなくなる日

清水 亮さん(ギリア株式会社)

AI駆動開発のボトルネックの考察と立ち向かい方

田中 幹衡さん(レッドハット株式会社)
齋藤 一鳳さん(レッドハット株式会社)

  • AIで生産性を上げるために
    • 人の関与を減らしていくこと
  • AIに任せると
    • 説明ができなくなってくる
    • 経験が積めなくなる
  • どこまで人の関与を残すかは組織の戦略
    • 関与しすぎると工数が無駄になる
    • 関与を減らしすぎるとあとから直す必要が出てくる
  • 人の手で戻せる状態を作っておく
    • 教育に投資
    • テストに投資
  • AIでボトルネックの場所が変わった
    • 実装が速くなってレビューがボトルネック
    • 遅い工程が1つでもあると全体のスピードが遅いところに合わせたスピードになってしまう
  • TOCの5ステップ
    • 制約を特定
      • バリューストリーミングマップ
      • どこにどれくらいかかっているか可視化
    • 制約を活用
      • まずは今ある能力を無駄なく使う
      • 追加投資はまだ投入しない
    • すべてを制約のペースに従わせる
      • 全ての工程を制約のペースにあわせる
      • 見えない在庫が悪さしていく
    • 制約の能力を高める
      • 追加投資で制約部分を強化していく
    • サイクルを繰り返す

「AI協働力」の可視化〜開発組織の新しい物差し〜

葛岡 宏祐さん(株式会社ハイヤールー)

  • AI利用の質を測る
    • 量は質ではない
      • トークンの消費量
      • 利用時間
      • 生成したコード量
  • AI Fluency
    • 委譲/記述/識別/誠実
  • CoderPad
    • AIの戦略的活用
    • 問題のフレーミング
    • 説明とアーキテクチャー
    • 批判的評価と修正
    • 問題解決
  • どうやって質を測るか
    • AIの行動のログ
    • AI協働力という独自指標
      • 共同推論
      • 環境構築
      • 実行の統制
      • 意図の仕様化
      • 出力の品質保証
  • AIのキャッシュヒット率
    • 同じコードベースを読み込んだまま使う
    • 前提文書を読ませてそのまま進める
    • セッションを作り直さず継続して使う
  • AIの並列数
  • リポジトリの整備
    • スキルやMCPが用意されてるか
    • エージェント用のインデックス
    • プロジェクトの形式知化

No Randomness, No Computing ― 量子が導く「乱数」という未踏領域

赤木 真さん(クオルガ株式会社)

  • 量子計算の進化で暗号の強さに課題が
    • 暗号を強くする
    • エントロピーを高める

AI駆動開発を実現するエンジニアリング戦略 〜エンジニアの新たな役割と次世代マネジメント〜

和田 卓人さん
吉羽 龍太郎さん(株式会社アトラクタ)
木口 佳南さん(ソフトバンク株式会社)

AI駆動開発で品質とエンジニアリングはどう変わるのか

  • どこまでAIに委ねられるか
    • 周辺のコードの品質が大きく影響する
    • 作っているものの性質による

AI時代にエンジニアと開発組織はどう変わるべきか

  • エンジニアは増やすべきか
    • 減らす理由があまりない
      • 今までと同じことを少ない人数でやれるだけ
    • 解くべき問題はたくさんある
      • 椅子取りゲームで椅子を取りに行かないといけない
  • エンジニア以外の職種は
    • エンジニアじゃない人もプロダクトを作っていく
  • 時間に対して報酬を払う体系
    • 同じ時間で生み出せるものの量が増えた
    • 相対的な比較の構造は変わらない
    • 時間に対してお金をもらうのは厳しくなる
      • 自分の価値を値付けできるようにならないと
      • 不況の時にも起きてたこと
  • エンジニアをどう評価するか
    • 数字だけだとハックを生む
    • 事業の成果だと配属先のガチャがある
    • 360度評価での周囲からの評価
    • エンジニアのスキルは同僚が一番分かる

「Product Engineering Talks」に参加してきました

データ組織を受託からプロダクトオーナーへ変える

くんぺさん(Ubie株式会社)
https://speakerdeck.com/ymdpharm/0908-product-engineering-talks

  • プロダクト開発の取り巻く状況
    • 現場解像度が重要になる
    • 非言語の感覚が専門家の価値
  • プロダクト開発の変化
    • 人間主体からAI主体の開発プロセスへ
    • 既存の延長からAgents as a Service
  • Agents as a Service
    • Journey
    • Tool
    • Rule/Policy
    • Workflow
    • Knowledge
    • Memory
    • Glossary
  • データチーム
    • 非言語感覚の強い領域
    • 現場にアプローチしてデータを使ってもらえるように
    • 他部門に深く入り込む

AI時代だからこそ、スケールしないことをやろう

重村優太さん(株式会社TOKIUM)

  • 立ち上げ期はスケールを一度忘れていいのでは
    • 業務にDeepDiveする
  • AI出張手配
    • チャットで出張の申請
      • 予定を提案して予約
    • 最初はヒアリングから情報を集める
      • 質もスピードもなかなか上がらない
    • 自社の出張手配を自分で全部やってみる
      • 100超のビジネス本部の社員
      • これもやってほしいなど生の声
  • ドメインに深くふれて
    • データモデリング
      • 経験から必然的に導くことができた
    • 業務の勘所
      • 利用者の外せないことが見えてくる
  • スケールしないことをしよう
    • ユーザを満足させるためにやってることは正しい

エンジニアがビジネスに踏み込むために共通言語として「会計」を学ぶ

大石悠真さん(株式会社BuySell Technologies)
https://speakerdeck.com/umaidashi/enjinia-ga-bijinesu-ni-fumikomu-tame-ni-kyoutsuu-gengo-toshite-kaikei-o-manabu

  • リユースプラットフォーム
    • 買取
    • 査定
    • 商品化
    • 販売
  • 仕事の変化
    • システムの開発から事業のグロースへ
    • 事業部 -> PdM -> エンジニアの流れから職種一体へ
  • 事業全体を見てどこを変えるとどこが変わるか
    • 査定の速度を30%あげたらどうなるか
    • 後続のフェーズで詰まるところが出てきたり
    • KPIに紐づけてどこの数値に影響してくるか
    • 計測することで正しく把握する

『寄り添うラジオ』をAIで作る ― 体験価値から逆算した、会話しないUXと品質設計

内山大悟さん(テオリア・テクノロジーズ株式会社)
https://speakerdeck.com/theoriatec2024/yorisou-rajio-o-ai-de-tsukuru-taiken-kachi-kara-gyakusan-shita-kaiwa-shinai-ux-to-hinshitsu-sekkei

  • わたしのラジオ
    • その日の振り返りと翌日の予定を送る
    • 翌朝その人向けのラジオが届く
  • 開発初期
    • 人手でAIを使ってラジオを作りチャットで送る
    • フィードバックからプロダクトの価値を定めていく
  • 会話しないUX
    • チャットで会話してインプットを渡してもらうアプリだった
    • 人力のときのアンケート形式で質問を事前に投げるほうがうまくいった
    • 会話だと短文の一問一答になりやすいという違いがあった

エンジニアはどこまで越境すべきなのか

Takeさん(株式会社UPSIDER)

  • プロダクトエンジニアの価値
    • 仕様と開発のトレードオフ
    • 顧客との直接のコラボレーション
    • リリース後のアウトカム検証
  • 役割を分断すると
    • 意思決定が遅くなる
    • 認識齟齬で手戻りが発生
    • 全体最適がうまくいかない
  • 越境しすぎることの弊害
    • 自分がボトルネックになる
    • エンジニアリングに集中できなくなる
    • 抱えすぎて疲弊する
  • 越境するが役割までは奪わない

新卒PdEのリアル

ryuさん(タイミー)
https://speakerdeck.com/ryu1013/shinsotsu-pde-no-riaru

敢えて溶かさないPdMとエンジニアの境界

山本洋暉さん(カイテク)
https://speakerdeck.com/hirokiyamamoto14/pdm-engineer-boundary

「Enterprise IT CONFERENCE 2026」に参加してきました

自ら試して組織を動かす、ライオンにおけるAI駆動開発の導入

中林紀彦さん(ライオン株式会社)

  • もうすぐ創業135年
    • オーラルヘルスケア/衛生/環境保全
  • 2030年に向けて
    • 次世代ヘルスケアのリーディングカンパニー
    • ReDesign
  • DXの取り組み
    • デジタルテクノロジーを駆使して「良い習慣づくり」
    • 経営情報基盤
      • データプラットフォーム
      • グローバルなデータの一元管理
      • タイムリーな可視化
      • 意思決定のスピードを上げる
    • 生成AIの日常化
      • Difyで非IT人材がローコードで作る
  • 個人での取り組み
    • 業務外で生成AIを使って開発してZennに記事を投稿
    • LLMの性能の違いの調査
      • Copilotは使える環境だったがやはりClaudeがいい
      • 社内でClaude導入へ
  • AI駆動開発の体制
    • CCoEの立ち上げ
      • CI/CDやDevOpsの環境を整備
      • 生成AIのガードレール整備
    • データマネジメントチーム
      • 社内データとの連携
      • 使える形でデータを管理
  • AI駆動開発の事例
    • COBOLやJCLが大量に残っている
      • ドキュメントも残ってないしロジックを誰も知らない
      • 演繹的なアプローチではなく帰納的に答え合わせ
    • 単なる移行から業務変革へ
      • イレギュラーなルールのあぶり出し
        • 複雑すぎるものはルールそのものを変えていく
      • セマンティックレイヤーの活用
        • 帳票を1対1で移植するのではなく共通辞書を用意してデータ配布基盤を作ったり
        • MCP化して社内に公開

AI時代、開発組織をどう再設計するか ~専門性と越境性を両立する人材・組織とは

地家 伶人さん(パーソルキャリア株式会社)

  • 分業前提の時代
    • 従来は分業は合理的だった
    • 開発は業務委託で
  • 役割の境界が溶け始めてきた
    • PdM/コンサル/エンジニア
    • 内製化へ
    • 同じ組織の中で複数の職種が一緒に考える
      • 隣の職種としか会話しないと伝言ゲームで正しく伝わらない
    • AIによって職種を超えた情報の取得がしやすくなった
  • これからの価値
    • 作ることのコストが下がった
    • 作るだけでは差がつかない
    • 何を作るかが重要に
  • 経験の設計
    • 複数の職種を経験する
      • AIでハードルが下がった
    • 専門性と越境性がより良い意思決定につながる

AIエージェント時代の内製開発~金融品質のプラットフォームとアジャイル開発~

齋藤 悠士さん(みずほフィナンシャルグループ デジタル戦略部)

  • AIネイティブなプロセスへ
    • 従来の人間中心からAIネイティブへ
    • 人間の認知能力の限界を前提としない
    • 並列で非線形的なプロセス
    • 〜2030で10倍、〜2035で100倍の生産性
  • AIエージェントの量産
    • 金融品質なAIエージェントである必要がある
    • AI特有の不確実性
    • AIを阻む課題
      • ビジネスとテックのコンフリクトで要件が決まらない
      • 金融機関特有の審査の問題
  • 内製開発ラボ
    • ビジネスとテックが一体となったスクラムチーム
    • エンジニア60人15チーム
    • AI駆動開発
  • 金融品質の担保
    • AIエージェント統合開発プラットフォームを構築
    • 閉域接続のためのネットワーク環境
    • 開発ツールの整備
    • 運用共通基盤(AWS)
    • データ基盤
  • AIエージェントファクトリー
    • ノーコードも含めてエージェントを量産できる仕組み
    • Difyでローコードで
    • エンジニアはBedrock AgentCore使ったり

AI×内製開発を成功に導く、開発組織戦略

前田 翔さん(株式会社Branding Engineer)

  • AIプロジェクトの導入で停滞/頓挫した経験が多いというアンケートデータ
    • AI活用の目的テーマが決まらない
    • 構想を計画に落とし込めない
    • 開発面ではそんなに困っていない
  • AI内製開発で必要なこと
    • 課題設定や推進継続のスキル
    • 主導機能を社内で持つべき
    • 専門性の高い実行機能は社外から
      • 特に希少性/一時性が高い分野
  • 採用の考え方
    • 将来自社に残す能力から逆算

AI×内製化の成果は、なぜ見えないのか──測る順番の話

松浦 直樹さん(ファインディ株式会社)

  • 作り続ける能力への投資
    • 外注は支払ったコストと納品物を比べてた
    • 内製だとできたシステムとかかった人件費
  • AI利用の成果の判断
    • 判断材料を持っていない企業が多い
    • 測れないものを経営判断に活用できない
      • 活用量を測っても意味がない
      • 能力がどう蓄積されているかは難しい
  • 蓄積される能力
    • 開発資本
    • Speed/Quality/Control
    • この中でQualityが成果に一番影響がありエンジニアの定着にもつながる

コクヨの挑戦 AI駆動開発での内製システム開発と組織の成長

小谷 侑哉さん(コクヨ株式会社 ビジネスサプライ事業本部)
新田 誠一郎さん(コクヨ株式会社 ビジネスサプライ事業本部)

  • 120年の歴史ある企業でゼロから内製エンジニア組織を立ち上げた
  • 内製エンジニア組織
    • 2024年に立ち上げ
    • 2025年に新卒11名
    • 2026年9月で31名
  • Adapt for Impact
    • さまざまな変化に合わせて適応していく
  • AI駆動の挑戦
    • 新卒11人でWebアプリのリニューアル
    • AIを活用して要件定義から開発まで
  • AIを活用した開発の苦労
    • AIに何を聞いたらいいか分からない
    • AIが出したものを評価できない
  • AIの使い方
    • ジュニアは丸ごと投げてしまう
      • 評価も修正も難しくなる
    • 経験のあるエンジニアはタスクを区切って指示できる
      • 理解しながら進めることができる
  • ツールへの適応
    • さまざまなAIツールを使っていた
    • 2025年12月頃からClaudeメインに
    • スキルの登場でチームで共有しながら整備
    • Claudeを中心に置いてハブとした開発運用スタイルへ

AI時代における「開発組織の内製化」の再定義〜ベンダーロックイン脱却、組織の壁、そしてAI協働力の可視化へ〜

泉水 翔吾さん(株式会社ハイヤールー)
及川 卓也さん(Tably株式会社)

  • 内製化はなぜ進まなかったか
    • 技術者の確保の難しさ
      • AIで変わった
    • コードを書ける人を多く確保する必要がなくなった
      • これで内製化は進むのか
  • だいじなのは手の内化しておくこと
    • 何がいいのか判断できるようにしないといけない
    • 判断の材料と能力が必要
  • 脱ロックイン
    • 属人性の排除
    • 暗黙知の形式知化

現場起点のPoCから全社AI変革へSMBCにおけるAI浸透とスケール化の実践知

ラジェーンドラ・マヨランさん(株式会社三井住友銀行)

  • AIを使う企業からAIで経営する企業へ
    • 仕事そのものをどう再設計するか
    • AIを経営判断につなげる
    • 効率化にとどまらずどう変革していくか
  • AIの変化
    • チャットからエージェントへ
    • エージェントを作ることから管理することへ
    • 競争力はモデルよりもデータや文脈
    • AIの成果は効率化ではなく収益、品質、意思決定速度
    • AI前提での業務、組織、顧客サービスの再設計
  • 中計での取り組み
    • システム基盤
      • 大前提のITインフラ
    • データ
      • AIの前提となるデータ基盤
    • ガバナンス
      • 多数のAIを回すための仕組み
    • カルチャー
      • AIを自然に使う
    • 人材
      • AIがある前提での働き方
    • ユースケース
      • 効率化ではなく価値創出
    • パートナーシップ
      • 誰と組んでやっていくか
  • データ活用の進め方
    • データ整備から始めてると進まない
    • 目的を決めてまず試作を
    • 逆引き的に

AI時代の内製開発と自律分散型組織

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

  • 大企業だと決めるまでの距離が長い
    • 作りたいものを作り始めるまでのステップの量
  • 東急での内製化
    • コスト削減ではなく顧客体験の向上のために始めた
    • 判断を内製したかった
    • 考える人 = 作る人
    • 現場に判断がある組織
      • マネージャーを置かない
    • 100人規模になっても階層は作らない
      • 判断が遅くなってしまうから
  • 100人規模でも自律分散を維持するために
    • プロダクト開発/職能コミュニティ/委員会
    • 10%を組織貢献に充てる
    • 自分たちの組織を自分たちで運営する
    • マネージャーはいないがマネージメントはなくなってない
      • 採用/評価/育成/チーム形成
  • AIで作るコストが下がった
    • ボトルネックの位置がずれた
    • 次に詰まるのは判断すること
    • 何を解くか課題設定の価値が上がる
    • 事業側とテック側が共創することで同じチームで意思決定
  • 自ら変わり続けられる組織
    • 内製化で判断を内側に
    • 自律分散で判断を現場に
    • 事業と接続し判断を顧客価値につなぐ

「AI時代のソフトウェアエンジニアリングを再定義する夜 Loglass AI TALK vol.8」に参加してきました

パネルディスカッション

和田卓人さん 広木大地さん(株式会社レクター)
伊藤博志さん(株式会社ログラス)
松岡幸一郎さん(株式会社ログラス)

AIが書いたものを人間がどこまで理解するべきか

  • AIが書いたものを全部読んでると限界が来る
    • レビューをどうにかして回るようにする
  • 長期的な意思決定と短期的な意思決定
    • 長期的なポリシーやビジョンを置いて変わらないことは判断しなくていいように
  • 理解すべきこととは?
    • そもそもどこまで理解してる?
    • 抽象化が漏れる部分を理解しないといけない
  • 技術的負債
    • メタファーとして変化してきている
      • 保守性の低いコード
      • 当時は良くても状況が変わっているコード
    • 昔はそういう力技コードをAIが書いていた
      • 最近は保守性の問題になるようなコードは出なくなってきた
    • 認知的負債
      • 人間が考えてるものとコードがずれてきている
      • どうなっているかどうなっているはずかが分からなくなる
      • それに気付く仕組みがない
      • 理解が浅いなら頑張ればいいがそれに気付けない
      • 理解を置き去りにしても速度も品質も出せるようになってしまった
  • 責務を果たすために必要な理解は手放せない
    • 社長が全て理解してるかというとそうではない
    • 人に任せることで理解してないところはある
    • AIには任せられないか?
  • 理解を手放さない
    • 今理解してなくてもたどれる状態を作っておく
  • 人間向けのハーネス
    • 人間が理解しないと実装しないような仕組み

組織全体のアウトカムを最大化するには

  • 本当に解くべき問題に定める
    • 機能が多くてもしょうがない
    • 仮説検証を高速化
  • 環境の変化
    • ソフトウェアの開発の単価が下がってる
    • AIによってできるようになったことが出てきてる
    • 新しい経済領域にあったやり方に変えていかないといけない
  • これまでと同じことを同じ人数でやっていくわけにはいかない
    • 同じことをより少ない人数で
    • 越境していくことが必要
  • 偉くなるか起業するか
    • 今の環境でも越境して冒険することで新しいこともある

AI時代にエンジニアが身につけるべき素養

  • 人間に興味を持つこと
    • 価値提供の先に人間がいる
    • 個人戦の方向に行きがちだがその先にいるのは人間
    • 起点と終点が人間
    • 痛みペインに共感を持つ

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

文化芸術をひらかれたものに

山上庄子さん(Palabra株式会社)

  • エンタメ分野のバリアフリーコンサル
    • 映画/映像
    • 舞台芸術の鑑賞
    • 展示施設の鑑賞
  • サポート内容
    • 字幕
    • 音声ガイド
    • 手話
    • 多言語
  • アプリでの提供
    • 音声ガイドや字幕のアプリ
    • 特定の上映会でしか対応できなかったが個人が使えるように
  • バリアフリー日本語字幕
    • セリフだけでなく話者や効果音など耳で聞こえる情報を文字化
      • 翻訳字幕はセリフをそのままだけだがそれとは違う
    • 迷いなく読めるように必要なところはルビをふったり
    • わかりにくさも表現の1つ
      • 音声で表現されているニュアンスを伝える手段
    • 無音を表現する難しさ
      • 無音と書く?字幕が空気感を壊してしまう?
    • スクリーンに表示/タブレット/AR眼鏡
  • バリアフリー音声ガイド
    • 映像が伝えている情報をナレーションで
    • 場面や人物の動きまで
  • 手話
    • 手話通訳を映像に入れ込む
    • 手話演者をつけることも
    • 照明や座席の配慮

わたしの一歩一歩

かのんさん

アクセシビリティから見つけた、エンジニアとしての軸〜変わる技術、変わらない目的〜

徳山申太郎さん(株式会社ノベルティ)
https://docs.google.com/presentation/d/1ZF0Y3cegyhzbBrhW-7EFsWHreUN60k0HsSu27n4Dl4Q/edit?usp=drivesdk

  • アクセシビリティはもともと知識として知っていた
    • カンファレンスに参加し使えなくて困ってる人の話を聞いて考えが変わった
  • アクセシビリティはWebの本質
    • 情報を伝える
    • 操作をする
  • エンジニアとしての軸の1つに

Issue駆動でスペシャリストの意図を届けるAIコーディングエージェントによるアクセシビリティ向上

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

  • AI以前のアクセシビリティ開発
    • 専門家の意図をチームに浸透させていく
  • AIワークフローになって
    • 正しいコピペコーディングをさせる
    • AIが正しいことを選択できる状態にする

営業がウェブアクセシビリティを話せると、プロジェクトが変わる〜提案から組織浸透まで〜

堀口真人さん(株式会社コンセント)

  • 営業がアクセシビリティ
    • Webの担当者の困りごとでアクセシビリティがあがることは多い
  • 世の中の人はアクセシビリティの品質が高い製品に多くふれている
    • GAFAMが作るようなもの
    • 海外だと訴訟にもつながるので対応されている

JAL独自のアクセシビリティ施策~社内資格制度を通じた人財育成~

堀川 さくらさん(日本航空株式会社)
北 彩乃さん(日本航空株式会社)
池内 風香さん(日本航空株式会社)

  • JALグループアクセシビリティに関するサービスポリシー
    • プライオリティゲストという概念
    • プライオリティゲストセンターという組織を作って人材を育成
  • ハード面
    • 機内エンターテイメントの画面の機能
    • SPECIAL ASSISTANCEカウンター
  • ソフト面
    • Webサイトとアプリのリニューアル
      • 体験を統一
  • ヒューマンホスピタリティ面
    • サービス介助士
    • JAL Accessibility Assistant
      • JAL独自の社内資格制度
      • 最上位のランクだとバッジを付けている
    • 2025年D&I AWARD大賞
  • JAL Accessibility Assistant
    • JALサンライト
      • JALの特例子会社
    • 3段階の認定
      • Specialist/Advance/Basic
    • 設立当時の課題
      • 機内環境におけるアクセシビリティの知識対応力
        • 機内という特殊な環境
        • さまざまな障害に対する知識と対応方法
      • 資格制度の構築
        • 知識習得にとどまらず伊月を行動へつなげる教育の確立
    • JALさんライトとの協働
      • 障害のある社員との対話を通じた対応力の強化
  • 利用時の心理的なハードル
    • 丁寧なサービス=安心して利用できるとは限らない
    • 当事者ならではの心理的な遠慮
  • ハードルの解消
    • 具体的な選択肢の提示
      • 何が出来るか伝えることでそれならお願いしてみようと伝えやすくなる
    • +αのコミュニケーション
      • いつでも頼っていいと思えるように

「AI時代のコードレビュー最前線 〜AIにどこまで任せる?これからのコードレビューを考える〜」に参加してきました

GitHub Copilotで書いたコード、レビューはどうしてる?

草場友光さん(FutureOne株式会社)

  • GitHub Copilotのrubber-duckコマンド
    • 違う観点でレビューを走らせる
  • Copilot code review
    • プルリク出した時に動いてくれる

AIエージェント時代のコードレビュー

noguさん(Software Engineer)
https://speakerdeck.com/nogu66/ai-ejento-jidai-no-kodo-rebyu-o-sekkei-suru

  • レビューの対象
    • 正しさ/品質/安全性
      • これらはAIや自動化対象
    • 設計意図/知識共有
      • これらは人間
  • AIを足すだけでは負荷は減らない
    • 些細な指摘で埋もれる
    • レビューされるべき箇所が見過ごされる
  • レビューの設計
    • タイミング
      • フェーズごとに全てのタイミングでAIのチェック
    • 観点
      • Skillやルールとして用意しておく
    • 検証
      • hookで必ず挟む
    • 環境
      • サブエージェントで観点を分けてチェック
  • 複数AIによる相互レビュー

レビューするAIに何を読ませているか

Sadahiro Inoueさん(株式会社estie)

  • 初回のレビューをAIにやってもらう
    • CodeRabbit
  • プロジェクトの決定事項をコンテキストで与える
    • 書き方
      • コーディングルール
    • 語彙
      • ドメインの用語集
    • 仕様
      • 画面の振る舞い
    • 却下
      • 却下した仕様の記録
    • 蓄積
      • レビューの実績
  • CONTEXT.md
    • Avoidで言い換えしてほしくない用語の定義
  • コンテキストはメンテしていく必要がある
    • 量が膨大になっていく
    • 多重管理の箇所があると必ず陳腐化する
    • 役にたっていないものを捨てていく判断も必要

「Platform Engineering Meetup #16 - Backstageで広げる、AI時代の開発者プラットフォーム」に参加してきました

Backstageでつくるセルフサービスな社内開発基盤

坂﨑菊之介さん(ソフトバンク)

  • Backstage
    • Software Catalog
    • Software Templates
    • TechDocs
    • Plugins
  • AI以前の組織の課題
    • 何をやるにも開発チームに依頼しないといけなくて時間がかかっていた
    • AIの登場で小さな修正は誰でも出来るようになった
  • AI時代の課題
    • 保守性を考慮した開発
    • 実行環境構築のハードル
    • 自由に作ってしまう中でのガバナンス
  • Backstageの活用
    • 雛形/ルール/ドキュメント
    • Backstageからテンプレートを選択するとセットアップ済みのリポジトリが作られる
      • AI向けの整備も済んでいるので開発を始められる
  • 事例
    • GAS開発のテンプレートを準備
      • 30分かかっていた作業を5分で
    • ポータル上で成果物をカタログ化
      • どんなアプリケーションがあるか見える

AI駆動開発時代のBackstage ― AIがコードを書く世界で、Golden Pathは誰が為に?

北村慎太郎さん(Red Hat)

  • Developer PortalはAI時代も必要なのか
    • これまでは人間向けに入口を一つにする役割があった
    • AI時代は人が見ずにエージェントにお願いする動きに変化
    • UIとしての価値は下がった
  • 全部をMCPで直接つなげば不要になる?
    • アクセス出来ることと何を見るべきか分かることは違う
    • 大量の情報があるなかでエージェントがどうやって目的にたどり着くか
      • トークン消費や呼び出し回数の問題
  • AI時代のBackstageの価値
    • Backstageを経由して各サービスにアクセス
    • コンテキストをベースに目当てのものを探せる
  • 今後のBackstageの使い方
    • 人間向けにWebUIの提供
    • エージェント向けにMCP経由で提供
  • 情報の管理はこれまで同様必要
    • 境界設計と品質維持
    • 古い情報や質の低い情報の整備
  • テンプレートはなぜ必要だったか
    • Golden Path
    • 個々の開発者が毎回同じ作業を繰り返させない
  • AIはGolden Pathがなくても実装できるのか?
    • 実装はできる
    • 毎回各開発者のエージェントに判断させるべきではない
    • 例えばコンテナのベースイメージを毎回各自にやらせたらどうなるか
      • 同じ原則に従っても毎回違うものを選んでしまう可能性がある
      • 実現できるイメージが複数あるから
    • Platform Engineerが慎重に選定してGoldenPathに含めた方がいい
  • Platform Engineerのしごと
    • AIも開発者の1人なので従来と変わらない
    • 標準を疑う仕組みも必要
      • 開発者のエージェントが気付くこともある
    • 提案を投げてもらって改善していくサイクルがあるといい

エンタープライズInnerSourceと開発者ポータル

能城冬馬さん(三菱電機)

  • あらゆる事業があって専門性が高くサイロ化している
  • InnerSourceの取り組み
    • 社内リポジトリ1000以上
    • Backstageでソフトウェアをカタログ化
      • リポジトリをクローリングし作成
  • InnerSourceの目的
    • 共創するため
      • 部門を横断してソフトウェアを使う
    • 実態を見ると
      • 一人で作って一人で使ってるのが6割
      • 部署内で使ってるのが2割
      • 部署を跨いでクローンして使ってるのが1割
      • 横断してるのは1割
  • 共創のジャーニー
    • 共創がどのように起きるのか経路を考える
    • 欲しいものを探して見つかったときに起きる
      • さらにコントリビュートなどでやりとりまで
    • AI時代だと自作の方がはやいケースが増える
  • 共創の計測
    • 良い影響を及ぼしてるかを計測して可視化
    • 上位の目標は難しい
      • 利用者の組織のゴールにどう寄与したかとか
    • 使えるものか/使えたか/効果があったか