Claude Codeは自律して実装を行えるAIコーディングエージェントです。
Claude Codeは特定のオプションを与えると持ちうる権限の範囲内の操作は何でも行います。
悪い方向に働くと、ホームディレクトリが削除されたり、大事なデータが削除された事例も…

本セッションでは、そんなClaude Codeや他のAIコーディングエージェント全般を如何にして安全に扱うのかプラクティスを紹介します。
具体的には、脅威モデリングの手法であるSTRIDEモデル（なりすまし、改ざん、否認、情報漏えい、サービス拒否、特権の昇格の6つの観点）を応用してClaude Codeがもちうる脅威を分析します。それぞれの脅威に対して、どんな対策が講じられるか、DockerやIaCのサンプルコードを用いてご紹介します。

AIコーディングエージェントは今後生産性を向上する要となりますが、組織として扱うには権限と制約のバランスを考える段階がどこかで発生します。2026年はおそらくその年になるので備えましょう。

セッションという場ではありますが、一方的にお話するというより自分たちのチームで改めて脅威を考えるためのきっかけや、組織での考え方の一助として使っていただければ幸いです。

BuriKaigi 2025では「2024年のWebフロントエンドのふりかえりと2025年」について話しました。
https://www.docswell.com/s/sakito/Z82RGP-burikaigi2025

話の中では、2025年のフロントエンドはどうなっていきそうかの推測もしていました。

今回は2024年の推測が当たっていたのか、2025年を振り返りつつ話をします。
そして、2026年のフロントエンドがどうなっていくのかも考察していきます。

ローコードやノーコードサービスが台頭して久しい昨今、組織によっては、様々なローコードやノーコードのサービスが統制なく使われているといった現状も存在します。
そんな折、
「どちらがいいのか？」「どちらかに寄せるべきなのか？」
と、聞かれることがよくあります。

ここでは、Microsoft 365 を主軸に活用しつつも、Power Platform と kintone が混在する組織の中で、どういう構成であれば最適な組み合わせとなりうるのか、ロールプレイング的なセッションとして、デモを交えながら解説していきます。

デモの内容

Power Apps with AI Builder x kintone で
極力オペレーションを減らした 在庫管理システム
https://x.com/Rinatamu_ITDR/status/1982679540712505828
など

※本内容は Cybozu Day 2025 で軽くお見せする内容をもっと深堀した内容となっています。
※本内容は業務担当者や開発者、DX推進者など幅広い層に見ていただける内容です。

「本当にメモリ管理は難しすぎてわからなぁぁぁい‼︎」と思っているみなさん！
メモリ管理への理解を深めるために、その発展の歴史を学んでみませんか？

たった一つのメモリ確保処理を見直しただけでCPU使用率を57%、メモリ使用量を99%も削減できた例があるほど、メモリ管理の知識はアプリケーションのパフォーマンス向上に直結します。
しかしメモリ管理に関する教材の多くは、ガベージコレクションの具体的なアルゴリズムやコンパイラ内部のメモリ構造といった複雑な機能が「どのように(How)」動作するのかに焦点を当てており、初学者向けとは言えません。
本来「How」を理解するためには、「なぜ(Why)」その機能が必要とされ、「何を(What)」実現するかの理解が不可欠です。
そうした土台がないまま「How」の議論を追うのは困難でしょう。

ヒープ、スタック、ガベージコレクションのような仕組みは、プログラミング言語におけるデータ管理をわかりやすくするために進化してきたものです。
動機を知ることでこれらの仕組みをより深く理解し、メモリ管理を語れるエンジニアになりましょう！
本セッションでは、特にGo言語のメモリ管理機能を取り上げてその進化の軌跡を紐解きつつ、発展的なメモリ管理の知識を修得するにあたって強固な土台となる知識を提供します。

[対象者]

• メモリ管理という言葉すら知らない方
• メモリ管理について学びたいが、理解に苦しんでいる方

[話すこと]
以下のメモリ管理機能がなぜ必要とされ、何を実現するかについて、それぞれの相関関係を強調しながら話します。

• ヒープ・スタックのメモリ構造
• GC (ガベージコレクション)
• ヒープエスケープ・エスケープ解析 (Go特有)
• スタックコピーによる可変サイズスタック (Go特有)
• メモリ管理の知識がプロダクション環境のパフォーマンスに大きな影響を与えた例とその解説

[話さないこと]
メモリ管理機能の詳細な処理ロジックや実装

[アウトライン]

1. はじめに (5分)
   • 自己紹介
   • メモリ管理はパフォーマンス向上のため非常に重要
     • たった1か所のメモリ確保処理の見直しで、CPU使用率が57%、メモリ使用量が99%も削減された事例が存在
   • メモリ管理に関するセッションは難しい
     • 実装の詳細やロジック (How) に関する技術的な内容が多い
     • 処理の抽象的な解釈や、必要性に対する理解 (What, Why) が不足している
   • Goの高度なメモリ管理を学ぶには、幅広い機能の基礎知識が必要
     • 各機能が「何を」して「なぜ」あるのかを理解することで初めて習得できる
     • 「How」の前に「What」と「Why」に焦点を当てるのが、修得の最短ルート
2. メモリとは何か / 古のメモリ管理 (2分)
   • メモリ＝プロセスの一時的なデータ保存領域
   • メモリへの直接的なデータ挿入 (アセンブリのデータ管理)
3. 変数の誕生 / スタックとヒープ (5分)
   • 【課題】人間が全てのメモリアドレスを把握する必要がある
   • 高級プログラミング言語の登場
     • 変数＝データの抽象化
     • 人間はアドレスを気にしなくてよくなるが、言語側が代わりにアドレスを管理する必要がある
   • スタックの発明
     • 関数呼び出しのネスト構造や変数スコープをメモリ空間上でうまく表現できる
   • スタックの図解説明
     • 【例】Goでの変数定義や関数呼び出し
   • 直接的な挿入も可能にする、ヒープとポインタ
     • 大きいデータ・サイズ不定のデータ
     • 関数をまたいで利用されるデータ
     • 【例】C言語のmalloc / free
4. ヒープの自動管理 / ガベージコレクション (2分)
   • 【課題】ヒープ上の使い終わったデータは人間が削除する必要がある
     • メモリリークやOOM Killのリスクが高まる
   • ガベージコレクション (GC)
     • ヒープ上の未使用データを検出
     • 未使用データを自動的に削除
5. Goのヒープエスケープ (6分)
   • 【課題】ヒープに大量のデータを置くとGCの負荷が高くなる
     • 【例】構造体や配列をすべてヒープに置く→半分以上の変数がGC対象に
   • ヒープエスケープの導入
     • できるだけスタックにデータを置く
     • 型で判断するのではなく、必要なものだけヒープへ「逃がす」
   • エスケープ解析
     • ヒープへ逃すか決まるのは、実行時ではなくビルドの段階
     • どの変数がエスケープするか見るためのビルドオプションがある
   • ゼロアロケーションライブラリ
     • 関数内でヒープに置かれるデータを一切出さないパッケージ
     • 非常に効率的で、基本的にパフォーマンスが向上する
     • 実装はやや複雑で、コードリーディングが難しい
6. スタックコピーによる、可変サイズスタック (4分)
   • 【課題】通常の言語ではスタックには上限が設けられ、スタックオーバーフローが起きる
   • あらかじめ大きなスタックを確保しておくか…？
   • 【課題】常に大きなスタックを持つと、ヒープが小さくなって不便
   • 可変サイズのスタックにより、効率的なメモリ利用を実現
     • セグメント化スタック (旧実装)
     • スタックコピー (現行の実装)
7. はじめに紹介した事例の解説 (4分)
   • 参考: https://developers.cyberagent.co.jp/blog/archives/54653/
   • フィルタリング関数が呼び出されるたびにヒープ上にスライスを1つ作成
     • このヒープに置かれた変数がボトルネックになっていた
   • 既存のスライスを利用することで割り当てを無くし、メモリ使用量99%削減
     • たった1つのアロケーションがパフォーマンスに大きく影響することを示している
   • CPU使用率57%削減
     • アロケーションとGCコストの削減の合計
8. まとめ (2分)
   • 今回のセッションはあくまで出発点
   • 他のセッションや資料で、各機能を深堀りしてみよう！
9. 次に見るべきおすすめの過去セッション紹介 (時間が余ったら)
   • このセッションで得た基礎知識を土台に、次のステップに進もう！
   • ヒープエスケープとエスケープ解析: "Escape Analysis in Go: Understanding and Optimizing Memory Allocation" - Go Conference 2023 Online
   • GCの条件: "Go1.19から始めるGCのチューニング方法" - Go Conference 2023 Online
   • pprofを使ったパフォーマンスチューニング: "Memory Management in Go: The good, the bad and the ugly" - GopherCon UK 2023
   • 【発展】ヒープ・スタックの、OSレベルでの割り当て: "Goのメモリ管理" - Go Conference 2023 Online
   • 並行処理に対するメモリ設計 (memory model): "よくわかるThe Go Memory Model - 行間を図解で埋め尽くす" - Go Conference 2023 Online

---私はこんな人！---
私は日頃、QA（テストエンジニア）として案件にアサインされています。

作業範囲はIT、ST、リグレッションなど状況に応じて様々。
管理ツールなどは利用しつつ、未だテスト設計そのものはほぼ手書きになっているのが現状です。
そんな中、社内外ともに積極的なAI利用が求められ、苦手なAIと真正面から向き合わないといけない日々が到来してしまいました。。

---こんな方に聞いて欲しい---
開発に関わるすべての方。
現場でバリバリ開発やテストをしている方も、案件管理などマネジメントラインの方も、すべてが対象です。

---テスト設計とAI---
私はテスト設計（≒QA）とAIはとても「相性が悪いもの」だと思っています。

本当は気軽にあれもこれもAIに読み込んで処理してもらいたい・・・
でも現実はそうはいかず、ただ資料を読み込ませたりルールを指定するだけだと、結果を出力する度に内容が変わっていたり、あるものを「ない！」と元気に返してくれたり、なんだかんだで使い物にならず頭を抱えます。

仕様書／設計書は基本的に日本語で書かれていますので、時に書き手により文体や表現の違う文章を処理しないといけません。
フローチャートなど、AIが苦手とする図表などがふんだんに含まれている場合も多々あります。
そもそも、昨今アジャイル開発が増えている中、仕様書がちゃんと作成されていないことも・・・

そう、テスト設計はAIと相性の良さそうなプログラミング言語ではなく「自然言語」、ひいては「人」を相手にしないといけない、という大きな壁が立ちはだかるのです。

また、利用できるAIには制限があります。
できれば日本語の処理に強いものを利用したいのですが、予算や会社都合が発生したりします。

私はいまcursorを利用しているのですが、そもそも開発者ではないのでエディタ系の画面がまず見慣れない・・・
こんな思わぬ落とし穴もあったりします。

---この登壇でお伝えしたいこと---
近年、AI活用をテーマにした有効なお話はたくさんありますが、たまには扱いが下手な人が、苦手なりに頑張るお話があっても良いんじゃないかな？と思い、この内容で応募させて頂きました。
特に開発とQAではAIが作業効率に寄与する割合に大きな差があるものの、現場目線だとそれが伝わりにくく「やりたくないだけでしょう？」と思われてしまうこともしばしば。
そんな誤解を少しでも解消すべく、どのようなことに苦戦し、試行錯誤しているのか・・・をお話する予定です。
また、この問題の解決にはエンジニアの協力がとても重要だと感じていることもお伝えできればと思っています。

テーマ

webフロントエンドにおいて、実用的なプラグインシステム(ユーザーの書いたコードを安全に実行する環境)をどのように実現するか

想定する参加者層（前提知識）

• JavaScriptの実行環境自体に興味があるようなフロントエンドの中上級者の方
• CORSやCSPなどのブラウザのセキュリティ機構について最低限の知識がある方
• 「プラグインシステム」や「ユーザーカスタマイズ」といったユーザーの書いたコードを実行する機能を提供するサービスを開発してる・したい方

トーク概要

SaaSなどのWebサービスには画面や挙動をユーザでカスタマイズできる機能を提供するものがあり、Webフロントエンドにおいてはユーザの作成したJavaScriptを実行することでこれらの機能を実現することが多いです。

一方で、ユーザーの作成したコードを無責任に実行することは重大なセキュリティリスクに繋がります。また仮に悪意がないコードだとしても、以下のような問題を容易に発生させます。

• 過大な権限による不可逆な操作を行えてしまう / 逆に権限を制限しすぎるとプラグインで実行したいことができない
• 追加したコードによって製品本体の挙動が不安定になる
• 製品の挙動や構造に強く依存するコードが原因で製品自体のアップデートがしづらくなる

これらの問題を避けるためには、ユーザーの作成したコードを安全に隔離しつつ、細かく権限を設定できる仕組みが必要です。

このセッションでは、「ユーザーが追加したスクリプトを実行する機能」や「プラグイン/カスタマイズ機能」の開発における課題と、その解決策となる関連技術について解説します。より具体的には、実際にtoBのSaaSサービスで「ユーザーの作成したコードを実行する新しいプラグイン機能」を設計・開発した経験をもとに、以下のような内容について話します。

• ユーザーの作成するコードを実行する難しさについて
  • セキュリティ上の問題だけでなく、製品の可用性などにも関わる
• 現状考えられる隔離の方式とメリット・デメリット
  • iframe / web worker / JSEngine on WASM / Realm Shims
• iframeを選択した理由と注意すべきこと
  • オリジンによるリソースアクセス制限やCookieについて
• 機能やアクセス先を制限するための仕組み
  • CSPの設定・Channel Messaging APIによる疎通と注意点
• これから期待される関連仕様
  • ShadowRealm について

これらの「プラグイン/カスタマイズ機能」開発に携わる方々をサポートするとともに、「JavaScriptを安全に実行する」という観点から、ブラウザのセキュリティ機構やJavaScriptエンジンの仕組みへの理解を深めるきっかけを提供することを目指します。

私たちは常日頃からありとあらゆるエラーメッセージと向き合っています。ソフトウェアエンジニアに限った話で言えば、コンパイラや言語処理系のエラーメッセージは最も頻繁に向き合うインターフェースの一つであり、毎日眺め、頭を悩ませていることでしょう。
そういった中で、Rustコンパイラ(rustc)はわかりやすいエラーメッセージ(diagnostics)を出すことに注力しています。そして、そのエラーメッセージは一つひとつが丁寧に設計され、コードレビューで磨かれ、ユーザーフィードバックにより改善されています。

わかりやすいエラーメッセージとはどういったものなのか。どのように実装、改善されているのか。どのように開発者体験、あるいはユーザー体験を向上させているのか。
このセッションではRustコンパイラへのコントリビューションで得た経験をもとにして、Rustコンパイラで行われているエラーメッセージの実装・改善活動を例に、わかりやすいエラーメッセージのあり方などについてご紹介します。

ここではRustやコンパイラを題材としますが、これらへの深い造詣は必要ありません。
Rustコンパイラの開発がどのように行われているのかといったOSS開発に関する知見だけでなく、日頃の開発においてエラーメッセージを通して開発者・ユーザー体験を向上させるテクニックや考え方をご紹介できる内容を目指します。

※政治に関する話題は最低限にしている、あくまで技術的な視点でのトークです。
※特定の政治家・政治団体・政党のお名前を一切お話しません。

テーマ

テクノロジー × デモクラシー

想定する参加者層（前提知識）

何かを作ってみたい、アウトプットをしてみたい方
政治なんてさっぱりわからない！という方（政治の知識は不要です。私も無いです）
学生の発表なので難しい話はしません、できません！

トーク概要

みなさんは「デジタル民主主義2030プロジェクト」をご存知でしょうか。
「デジタル民主主義2030」は、技術の力で市民の声を活かし、政治をより良い形に進化させることを目指したプロジェクトです。透明性と信頼を重視し、多くの人々が政策に参加できる未来を目指しています。
今回は、このプロジェクトから生まれたオープンソースソフトウェア（OSS）である "Polimoney" について、技術的な視点からご紹介します。

「Polimoney」は、政治とお金にまつわる「複雑なデータ」や「アナログな業務フロー」といった課題を、テクノロジーの力でボトムアップに解決しようとする「シビックテック」（※）の取り組みです。
（※市民がテクノロジーを活用して社会課題を解決する活動）
このプロジェクトは誰でも活動に参加できるのが特徴で、学生である私もcontributorとして開発に参加しています。

「なぜ今、この領域にエンジニアリング（OSS）が必要なのか？」という視点から、私たちが直面している課題と、それをどう乗り越えようとしているかをお話しします。

• 「政治とカネ」の現場にある「技術的負債」
• なぜデータ活用が進まないのか？制度と実務のギャップ
• Polimoneyによる課題解決のアプローチ
• 学生エンジニアが政治系OSSに参加したリアルな体験
• 「コードを書く」だけじゃない！ OSSへの貢献方法

デジタル民主主義2030 https://dd2030.org/
polimoney https://polimoney.dd2030.org/

近年のWindows OSに実装されているデバッグ機能について解説します。デバッグは、ソフトウェア開発者がプログラムの複愛を特定したり、動作を確認したりするための一般的な動的解析技術であり、その特性から近年ではサイバーセキュリティでの問題分析や攻撃検知にも活用されています。Windows OSでの動的デバッグに用いられるソフトウェアとしてはWinDbgが広く知られていますが、Windows OS自体にもプログラムの動的解析を支える複数の機能が実装されています。本講演では、Windows OS自体に実装されている動的解析を支援する機能の中から、いくつかの機能に焦点を当てて、デモンストレーションを交えて解説します。

去年の Burikaigi では WebDriver BiDi とは何なのか話しました
https://speakerdeck.com/yotahada3/webdriver-bidi-burikaigi2025

今回は 2025 年の WebDriver BiDi の動向として

• 仕様についてどう言った議論があったか
• 各ブラウザベンダーの実装状況
• ブラウザツールの対応状況

をふりかえり、2026 年の WebDriver BiDi がどうなっていくのかを予想します。

【テーマ】
アプリケーション設計において、「この処理はどこに置くべきか？」という問いは常につきまといます。
特にオブジェクト指向言語では、クラスやオブジェクトが自由に設計できる反面、責務と状態の境界が曖昧になりやすく、気づけば副作用があちこちに散らばります。
一度拡散した副作用は、バグやテストの不安定さを呼び、まるで割れ窓理論のように保守性の低下を加速させます。

本テーマでは、オブジェクト指向設計の原則（単一責務・不変条件・副作用の分離）に立ち返り、
「コールバック・イベント・非同期処理といった選択肢の中で、どのように責務と状態の境界を見極めるか」を体系的に整理します。
具体的な設計判断の基準と、現場で使える“判断ツリー”を共有することで、日々の開発における「処理をどこに置くか問題」に自信を持って向き合えるようになることを目指します。

【想定する参加者層】

• オブジェクト指向プログラミングの基礎（クラス・責務・状態）を理解している方
• 何らかのオブジェクト指向言語（Ruby / Java / PHP / Python / TypeScriptなど）で業務アプリケーションを開発している方
• ミドル〜シニア層のエンジニア（コード設計やレビューを担う人）

※発表者はRailsエンジニアであり、サンプルコードはRubyで示しますが、設計原則は言語・フレームワークを問わず応用可能です。

【トーク概要】
「コールバックに書くべき？」「イベントに切るべき？」「非同期に逃がすべき？」
日々の開発で誰もが悩む“副作用をどこに置くか問題”に悩むかと思います。この判断をセンスや慣習に頼らず、オブジェクト指向設計の原則に基づいて整理するのが本トークの目的です。
副作用を

1. エンティティ内部の不変条件を守る処理（DB内で完結）
2. 状態確定後の通知（他の関心へ伝える）
3. 外部I/Oや重い処理（非同期・再試行を前提とする）

という3層に分類し、それぞれをコールバック／ドメインイベント／非同期ジョブに対応づけた「設計判断ツリー」を提示します。
また、現場で陥りがちなアンチパターンとして

• コールバックが連鎖して依存が見えなくなる
• 順序依存で動作が壊れる
• ロールバック後に外部I/Oが発火してしまう

といった問題を、責務と状態の境界設計の観点から分解します。実際のコード例（Rubyで示します）を通じて、「副作用をどこに置くべきか」を説明できるようになることを目指します。

「IPv4 のアドレスがもうすぐ枯渇する！」と言われ続けてはや◯年。

これは決してオオカミ少年的な話ではなくて IPv4 アドレスの節約・やりくりを頑張っている人たちのおかげでもあると思うのですが、そんな「努力の限界」がいつ来るかについてはわれわれ素人には正確にはわかりません。

そこで、X デー（？）がいつ来ても良いように、今のうちに「完全に理解した」とは言わないまでも「雰囲気は掴んだ」というレベルになっておこう！というのが当セッションの目的です。

■話す内容（一部）

• IPv4 との違い
  • アドレスの構成と表記
  • アドレスの種類
  • アドレスの割り当て方
• ホスト（ノード）間通信
• IPv4・IPv6 共存技術
  • デュアルスタック
  • NAT64 + DNS64
• AWS のリソースを IPv6 で組んでみる
  • IPv6 の仕組みのうち AWS で隠蔽されている（意識しなくても良い）部分について軽く説明
  • IPv6 専用 VPC で組んでみる
  • デュアルスタックで組んでみる
  • 結局 IPv4 パブリックアドレスは減らせるの？（安くなるの？）
  • アプリケーション側での考慮点
• IPv6 を使うときの注意点
  • GitHub、もしかして使えない？
  • マネージドサービスを使わずにメールをまとめて送ろうとすると…？

などなど

■想定する参加者層（前提知識）

• IPv4 のことは概ね理解しているが IPv6 については何もわからない方
• 主に AWS を使われている方

▪️テーマ

耐量子計算機暗号 (PQC)、暗号技術、セキュリティ、NIST標準化 (FIPS 203, 204, 205)

▪️想定する参加者層（前提知識）

前提知識

• 特定のプログラミング言語に関する知識は不要です
• 高校程度の数学の知識があるといいが、必須ではないです
• 公開鍵暗号方式（RSAなど）の基本的な概念を理解しているといいが、必須ではないです

想定する参加層

• Webアプリケーションやシステムのセキュリティに関わるエンジニア
• 暗号技術の最新トレンドや量子コンピュータの動向に興味がある方
• 将来の標準技術（PQC）の仕組みや実装状況を早めにキャッチアップしたい方

▪️トーク概要

耐量子計算機暗号（Post-Quantum Cryptography: PQC）は、将来登場が予測される高性能な量子コンピュータによる解読の脅威に耐え得る、新しい暗号技術の総称です。
PQCの基盤となる数学的問題は一つではなく、様々なアプローチが研究・開発されています。

特に大きな動きとして、2024年8月、NIST（米国国立標準技術研究所）は2016年から進めてきたPQC標準化プロジェクトの成果として、FIPS 203、204、205という3つの標準を正式に発表しました。
これにより、PQCは研究段階から「実装段階」へと大きくシフトし始めています。

本トークでは、まず「なぜ今PQCが必要なのか？」という背景や、NISTによる標準化の最新動向といった概要を解説します。
その上で、標準化されたPQCがどのような仕組みで安全性を担保しているのか、代表的な方式（例：格子ベース暗号など）の技術的な仕組みを分かりやすく紐解きます。
最後に、私たちエンジニアが最も関心のある、主要なプログラミング言語（Java, Go, Rust など）におけるPQCライブラリのサポート状況を紹介します。

想定しているアジェンダ

• 耐量子計算機暗号入門
  • なぜ耐量子計算機暗号が必要なのか
  • NIST の耐量子計算機暗号の標準化について（FIPS 203、FIPS 204、FIPS 205）
  • 主要な耐量子計算機暗号の紹介（格子暗号、同種写像暗号、符号ベース暗号、多変数多項式暗号、暗号学的ハッシュ関数）
• 各プログラミング言語に関するサポート状況
  • Java （Java 24での機能提供）
  • Go （1.24での機能提供）
  • Rust （Rust Crypto での提供）　など

このトークで得られること (Takeaway)

• 量子コンピュータがなぜ現在の暗号（RSA, ECC）に脅威となるのかを理解できる
• NISTによって標準化されたPQC（FIPS 203, 204, 205）の概要と重要性を学べる
• 代表的なPQCアルゴリズムの基礎的な仕組みを把握できる
• 主要言語（Java, Go, Rust等）でのPQC対応ライブラリの現状を知ることができる

よりパワフルで柔軟な UI を実現する、エキサイティングな Web の機能が、今年も多く登場しました。

CSS Containment、Value Processing、UA による DOM のクローン、Top Layer、そしてレンダリングエンジンにおける最適化。
針の穴に糸を通すような仕様と実装の工夫が積み重ねられ、不可能だったことを可能にする基盤が今、整ってきました。
その結果、ずっと絵に描いたモチだと思っていた機能が、気づけばポンっと実体化した。
それが、 2025 年の Web UI です。
参考：https://blog.sakupi01.com/dev/articles/2025-css-advent-25

そんな今年の Web UI を取り巻く HTML&CSS&JS 機能のアップデートと、今後登場が期待される機能、そして"Declarative" に焦点を当てた Web UI 進化の方向性をご紹介します。

AI時代の今、あえて「ライブラリを使い倒す」経験は必要なのか？

キャッチコピー: バイブコーディングが教えてくれないこと 〜なぜ私はReact Hook Formに“育てられた”のか〜

ターゲット: AIコーディングに慣れ始めた若手・中堅エンジニア、技術選定を行うテックリード

概要:

（導入）昨今の開発はAIアシスタントの登場で劇的に変化した。「バイブコーディング」でそれなりの実装が瞬時に手に入る。

（過去）しかし、私（発表者）が学んだ時代は違った。特にフロントエンドは「正解」がなく、React Hook FormやFullCalendarのような複雑なライブラリを、文字通り「片っ端から試し」ながら使い倒す必要があった。

（対比）この「使い倒す」泥臭い経験は、単にライブラリの使い方を覚えるだけでなく、「なぜこのAPI設計なのか」「状態管理のどのパターンが最適か」といった実装の裏にある『Why』を深く理解するプロセスだった。

（問い）AIが最適なコードを提示してくれる今、この「苦しみながら使い倒す」経験は不要になったのか？ AIが提示するコードの「意味」を真に理解できているか？

（結論）「使い倒した」経験こそが、AIの出力を鵜呑みにせず、より良い設計を判断・選択できるエンジニアの「幹」となる。バイブコーディングの時代だからこそ、意識的に「使い倒す」経験が重要である。

ITエンジニアとしてのキャリアは、技術スキルだけでなく「どんな選択をするか」によって大きく形が変わっていきます。
どの技術を学ぶか、どんなコミュニティに飛び込むか、そしてチャンスが目の前に来たときに一歩踏み出すかどうか。
その一つひとつの選択が、自分のキャリアを作り上げていきます。

私は、Microsoft技術との出会いをきっかけにキャリアが大きく動き出しました。
コミュニティでの学びや仲間との交流が新たな視野を開き、Microsoft MVPを受賞することで次の扉が開きました。
そこからさらに挑戦を続け、現在はアバナード株式会社でDirectorという立場に至っています。

このセッションでは、私がどのように選択を重ね、どのような失敗や葛藤を経てチャンスを掴んできたのかを、リアルな体験談としてお伝えします。
いつもは.NETやMS技術系のテーマでしたが、今年は自身のふりかえりをかねてソフトスキル系のお話をさせていただこうかと思います。
エンジニアとして成長の道を模索している方、次のキャリアステップを考えている方に、キャリアを切り拓くための「勇気」と「ヒント」を持ち帰っていただければと思います。

【テーマ】
Webページのパスキーに対応できるかどうかを明らかにするため、WebViewのビルドに挑戦した新卒エンジニアの試行錯誤

【想定する参加者層】
・WebViewを使ったAndroidアプリ開発に携わっている方
・ブラウザ、パスキーに関心がある方
・WebView（Chromium）やカスタムROMのビルドに興味がある方
・「やってみた」系の話が好きな方

【トーク概要】
WebViewは最小限のブラウジング機能を有しますが、Chromeと異なりWebページのパスキーに対応していません。
AOSP（Android Open Source Project）のWebViewに関するコードを調べたところ、パスキーを利用可能にする「CHROME_3PP_ENABLED」定数が設定不可にされている一方、別箇所ではその定数の設定を想定しているようなコードも存在しました。
この矛盾する発見について、上司から次のように提案を受けました。 「もしこの定数を設定できるようコードを修正し、パスキーを動作させられれば、それをPoCとしてGoogleに機能拡張を提案できるかもしれない。AOSPをビルドして検証してみてはどうか？」

本セッションでは、この仮説に基づいて行った検証実験を以下の内容で共有します。
・前提１： 基本的なWebViewのパスキー実装
・前提２： パスキー実装の制約、その技術的背景
・WebViewのビルド： Azure VMを使ったビルドマシンの用意、ビルド成功までの試行錯誤
・さらなる課題： WebViewの実行環境としてのLineage OS（カスタムROM）のビルド、エミュレータの起動
・ようやくたどり着いた検証実験、その結果

本セッションはサクセスストーリーではありません。新卒入社２年目のエンジニアが情報リソースの限られた中で、いかにしてWebViewのパスキー実装に関する調査や、WebViewおよびLineage OSのビルドを行い、検証実験に至ったのか、その過程を共有します。

Webブラウザはこれまで、数々の機能を実装し、セキュリティを強化し、相互運用性を高めながら発展してきました。
現在では情報アクセスの一部がAIを介した対話的UIへと移り始め、ブラウザでUIを提供する時代は終わるという声も聞かれるようになりました。

現代、もしくは近い未来私達が情報の消費者としてもコンテンツを作り出す開発者としても、Webブラウザに何を求めるのかを問い直します。

また、モダンブラウザと呼ばれる主要なブラウザエンジンに加えて、新興ブラウザエンジンの開発も進んでいます。
実際に1つのブラウザエンジンプロジェクトにコントリビュートしている発表者の視点から、ブラウザ開発に関わるモチベーションを紹介し、日本人開発者が参加する意義についても考察します。

"Why do you need End-to-end Encryption in Ruby? Because..."

国際情勢の緊張が高まる現在、メッセージングのエンドツーエンド暗号化技術はかつてなく重要性が高まっています。
Eメールはその仕組み上エンドツーエンドでの暗号化を持たず、どうしても暗号化を実現しようと思うとS/MIMEなどの高価な仕組みやPGPなどの「オタクしか使っていない」仕組みに頼るしかありません。一方で我々が日常的に利用しているメッセージングアプリにはエンドツーエンド暗号化の仕組みが搭載されていますがベンダーごとに個別の方式で実装されており相互運用性を持ちません。
これらを解決すべくIETFで標準化が行われているMessaging Layer Securityという相互運用可能な鍵交換の技術があります。
現在私はMessaging Layer Security Protocol (RFC 9420)のRuby実装を進めています。この実装を通してMessaging Layer Securityの仕組みを解説することで、皆さんが日常使っているメッセージングアプリのセキュリティについて安心感を持つことができるようになるでしょう。

技術的には以下の内容をカバーする予定です:

• 求めるセキュリティ性質: Forward SecrecyとPost-Compromise Security
• 2人でこれを実現するのは容易だが3人以上の場合は難しい
• MLSの構成要素: Key Schedule, Secret Tree, TreeKEM
• 進行中のRuby実装について

ハッシュ化、共通鍵暗号、公開鍵暗号の概念程度の暗号技術の知識をある程度前提としますが、トークの内容自体はセキュリティに興味のある全技術者向けの内容です。

テーマ

AIエージェントの導入によって、開発の現場は実際にどのくらい生産性が向上したかをテーマに、導入した現場での定量的な実測値とAIエージェントのベンチマークを深掘って考察した結果を発表します。
いくつかのAIエージェントの導入(2023年のCopilot、2024年のCursor、2025年のClaude Code)による社内でのマージ頻度やリードタイムの変化と考察、AIエージェントの研究開発の分野で参照されるHumanEval / SWE-Bench等のベンチマークの深掘り、そのベンチマークによる定量評価がどれくらい現場での定性的な評価と合っているのかを考察した内容を発表します。

想定する参加者層（前提知識）

機械学習やLLMに関する研究の知識などを必要とせず、コード生成をするAIエージェントを見聞きしただけの人にもわかりやすいような基礎からの発表にします。特に、ベンチマークについては、具体的にどのような課題があってどのように判定されているのかを噛み砕いて説明します。

トーク概要

本セッションでは、AI コードエージェント導入による開発加速の実態を、現場データとベンチマークの両面から整理してご報告します。
当社では 2023 年以降、その時点で有効と判断したコード生成 AI エージェントを導入してきました。マージ頻度やリードタイムの集計の結果、ある事業部では Cursor 導入後にマージ頻度がおよそ 3 倍、Claude Code 併用後にリードタイムがおよそ 1/2 となる変化を観測しました。この事実をもとに、「AI でどれくらい加速したのか」「どう評価すべきか」を定義し直します。

AI 導入初期はコード生成の品質が安定せず、人手による修正が前提となる場面が多いと感じていました。その後、モデル世代の変化に伴いコード生成の「精度」が向上し、コードエージェントの導入により開発体験が実際に変化した手応えがありました。ただし、この「精度」が具体的に何を指すのかに疑問を持ちました。変化量を外部基準でも確認するため、研究開発分野で一般的なベンチマークが何を測り、どのスコアを KPI としているかを整理する必要があると判断しました。

そこで、HumanEval と SWE-Bench を取り上げ、研究・開発分野で何を指標としてスコアを伸ばそうとしているかを解説します。これらのベンチマークでは、HumanEval は明確な入出力をもつ小粒度タスクに対する関数レベルの正確性を測定し、SWE-Bench は既存リポジトリ上での Issue 修正達成（文脈統合・依存解決・テスト通過）を測定します。現場では前者をユーティリティ／純粋関数の自動実装の置換可能性、後者を既知バグ修正や小〜中規模改修の到達率として読み替えます。本発表では、実際のテストデータを参照しながら両者の評価対象と前提条件を具体的に説明します。

あわせて評価指標にも短く触れます。pass@k は同一課題に対して k 本のコード生成を行い、少なくとも 1 本がテストを通過する確率を示します（例：pass@1 は単発生成の正答率、pass@5 は多様サンプルからの到達率）。SOTA（state of the art） は特定ベンチマーク・評価手順・バージョンにおける当時点の最高到達成績を指します。いずれも評価プロトコルと前提条件への依存性が高いため、比較は同一条件で行う必要があります。

そのうえで、ベンチマークの数値は次の三点で位置づけて読み解きます。第一に、何を前提に何を測っているか（課題の明確さ、必要コンテキスト、依存・ビルド環境、採点方法）を明示します。第二に、どの作業単位に対応するか（例：小粒度の実装、既知 Issue の修正、結合起点の不具合対応）を対応付けます。第三に、影響しやすい成分／しにくい成分を仮説化します。なお、研究分野の「コード精度」は pass@k やテスト合否が中心であり、仕様の曖昧さの解消、非機能要件、ステークホルダー調整、セキュリティやロールバック設計、コードデザイン（責務分割・凝集／結合・API 境界）といった現場要素は評価外になりやすい点を前提にします。本セッションでは、この読み替えを対応表と最小手順として提示し、新しいモデル・ツール・論文に出会った際に、作業単位や手元の指標へトレースする実務的なガイドとして持ち帰っていただきます。

聴講者が得られること
• AI 導入による効果が定量的にどのくらいあるかと、その評価方法
• 研究開発分野での AI エージェントの扱われ方と、どのスコアを KPI として伸ばしているかの整理
• 研究ベンチマークが開発現場でどの程度・どの領域に起用できるかを考え、議論するための視点