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

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

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

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

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

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

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

■話す内容（一部）

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

などなど

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

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

テーマ

明日から使える！ソフトウェアテストの歩き方

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

主にソフトウェア開発に携わる一般エンジニアを対象としています。
テストを我流で行っている方、または単体テストや結合テストの品質をもう一歩上げたいと考えている初学者〜中堅エンジニアを想定しています。
JSTQBなどの体系的なテスト知識がなくても理解できる内容ですが、仕様を読みコードを書いた経験があると理解が深まります。
テストエンジニアだけでなく、開発者・PM・デザイナーなど「自分の成果物の品質に責任を持ちたい」と考えている方にもおすすめです。

トーク概要

テストって、どこまでやればいいんだろう？
機能は動いているけど、なんとなく不安。レビューでは「テストケースが浅い」と言われる。
そんな経験をしたことがある方は多いのではないでしょうか。

このセッションでは、現場で本当に役立つ「ソフトウェアテストの考え方」を、明日から実践できる形でお伝えします。
テーマは「同値分割を基本としたテスト技法」「経験ベーステスト」「生成AIを活用したレビュー技法」の3つ。
教科書でおなじみのテスト技法に加え、現場で実践している生成AIの活用方法を紹介します。

テストは、実際のプロジェクトでどう活かすかとなると、途端に難しく感じる人が多い分野でもあります。

私自身、スタートアップでQAエンジニアとして日々開発と向き合っています。
IT業界20年。開発者やマネージャーとしての経験を経て、「理論通りにやってもうまくいかない現場」と、「時間がない中でも品質を守る工夫」を何度も経験してきました。

そこで気づいたのは、テストは“やり方そのもの”ではなく“テストの考え方”を学ぶことが大事だということ。
同値分割の前に「どんな違いが意味を持つのか」を見抜く目。境界値分析の前に「どこが境界なのか」を見つける力。
そして、マニュアルに載っていない「勘」や「経験」は、実は“多くは理屈で説明できる”ものだということです。

本セッションでは、JSTQBの定義をベースにしつつ、
・仕様の読み方をどう変えるとテストがしやすくなるか
・チームで納得できるテストを作るために必要な考え方
・不具合を探索する道標の作り方
など、「ものづくりのラストワンマイル」を埋めるヒントをお話しします。

単に「テストをやる人」ではなく、
「品質をつくる人」として一歩踏み出すためのきっかけになればと思っています。

テストを専門にしていなくても大丈夫。
むしろ、今までは“なんとなく動作確認していた”という方にこそ聞いてほしい内容です。
セッション後には、自分のプロダクトや関わっているプロジェクトを少し違う視点で見られるようになり、
「ここは確認しておこう」「ここが危なそう」と、自然にテストの意図が浮かぶことを期待して準備します。

テストは退屈な作業ではなく、プロダクトを深く理解するための一番身近な探求です。
このセッションを通じて、あなたのテストが「やらされるもの」から「やりたくなるもの」に変わる。
そんな体験をお届けしたいと思っています。

「自分のテストがなんとなく不安」「レビューで指摘されがちでしんどい」そんな方に、
明日から試せる“ソフトウェアテストの歩き方・付き合い方”を持ち帰ってもらえるセッションです。

テーマ

HTMLのbutton要素とa要素の正しい使い分け、マークアップ、アクセシビリティについてを主題とします。安易な実装が引き起こすバグやアクセシビリティ低下という課題に対し、Web標準に基づいた「ボタンの定義」についてを改めて見直す内容を提供します。

想定する参加者層

• とりあえず<div>や<a>にonClickを書きがちな方
• コンポーネント設計の際に、<button>と<a>の使い分けで議論した経験のある方
• UIのセマンティクスやアクセシビリティに関心のある方

トーク概要

今やWebサイトやアプリケーションに必ず存在するようになった「ボタン」というUI。私たちは毎日当たり前のように実装していますが、「ボタンとは何か？」と聞かれたら、明確に定義できるでしょうか？

<a>タグをボタン風に装飾したUI、type属性を忘れて意図せず画面をリロードさせる<button>、そして歴史の彼方に消えつつある<input type="button">...。なぜこんなにも多様な『ボタンのようなもの』が生まれ、そしてバグの温床となるのでしょうか。

私はこれまで、マークアップのセマンティクスを重視する立場として、こうした「残念な」実装が溢れる現状を常にもどかしく感じてきました。「動けば良い」という流れの中で、なぜ「本来あるべき姿」が失われてしまうのでしょうか。
このセッションでは、「type属性の指定漏れ」でバグを踏んだ経験や、デザイナーと「ここはリンクか？ボタンか？」で実装方針が割れた際の苦い議論を基に、このボタンUIを深掘りします。

HTML仕様やアクセシビリティの観点から「ボタンとは何か」を再定義すると同時に、私が実務のコードレビューや設計議論で直面してきた葛藤と、それを乗り越えるための知見を共有します。
この発表を経て「たかが」と思っていたボタンUIについての考えを変えるきっかけになるかもしれません。

期待する聴者に持ち帰ってほしい内容

• 「ボタンとは何か？」という問いに対し、セマンティクス・振る舞い・アクセシビリティの観点から自信を持って説明できるようになる
• type属性の指定漏れによる意図せぬフォーム送信バグを、未来永劫なくすことができる
• リンクをボタンのように見せるUI（リンクボタン）を実装するときに配慮すべきことに気づける

テーマ

不確実性に立ち向かう品質マネジメント

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

開発現場では、品質に関する判断に迷ったり、リスクを後追いで発見してしまう経験のあるエンジニアを想定しています。
職種としては、開発者・QAエンジニア・テックリード・マネージャーなど、チームでプロダクト開発に関わる方を幅広く対象としています。
品質マネジメントやリスクマネジメントの専門知識がなくても理解できる内容ですが、日々の開発プロセスに課題意識を持っている方ほど共感しやすいと思います。
特に「不確実な環境での意思決定」や「リスクとどう向き合うか」に興味のある方におすすめです。

トーク概要

私は全てのマネジメントの目的は"リスクを見つけ「なるべく早く」対処することが本質だと考えています。
このトークでは、リスクを「なるべく早く」見つけるために工夫しているノウハウを共有します。

変化の激しい開発環境では、不確実性に起因する判断ミスやリスクの見落としが、重大な品質問題へと発展することが多くないと思います。
本トークでは、私がエンジニアとして取り組んできた、そうしたリスクに向き合う考え方と実践について発表します。

過去には、曖昧な仕様や品質知識の不足により十分なテストが行えず、リリース遅延や品質低下を招いた経験があります。
現在、その経験を教訓に、リスクを「プロジェクトリスク」と「プロダクトリスク」に分類し、それぞれに応じた対応を開発プロセスに実施する取り組みを行ってきました。
具体的な例としては、リスクを見分けるのための会議体を設け、開発チームと早期に情報を共有し、設計段階から品質に向き合えるプロセスを整備しました。
これにより、仕様検討段階での認識のずれや改善事項を前倒しで発見・対処する等、リスクの顕在化を未然に防ぐ効果があった。
不確実性が高まるなかで、品質に向き合うためのマインドセットと品質マネジメントの両面から対応した実践的アプローチを紹介します。

皆様にとって、現場で再現可能な品質マネジメントのヒントを提供できれば幸いです。

本トークは、昨年YAPC函館や本年開催のSQiP2025に関連する内容です。
YAPC函館）https://fortee.jp/yapc-hakodate-2024/proposal/da4c92fe-0a90-4fd1-9eec-946ce046c1e2
SQiP2025）https://www.juse.jp/sqip/symposium/detail/day2/#b3-2

テーマ

本セッションでは、次の内容を紹介します。

• スマホ/衛星直接通信（D2C）の現状を手早く把握するための通信技術概要
• AndroidプラットフォームにおけるD2Cの実用実装例。そして衛星経由のSMS送信を多様な端末環境・通信環境（例：dual SIM）で安定稼働させるための工夫
• リアルタイム位置情報というプライベートな情報を、伝えるべき相手（家族や山岳会）へと適切に届ける工夫
  時間が許せば、StarlinkベースのD2Cを使う際に周辺地形の面で考慮すべき点や、おすすめのテストスポットとスポットの探し方も紹介したいです。

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

4G・5Gといった現代スマホの通信方式について、うっすらと知識がある方を対象とします。
4G（LTE）回線の通信バンドについての事前知識があると内容を聞きやすいと思います。

Android SDKについての知識、Unixシェルの知識があると楽しく聞けると思います。

登山や海のレジャーといったアウトドアアクティビティーに馴染みのある方は興味を持ちやすいと思います。

トーク概要

主要通信キャリアの4G回線の人口カバー率は99.9%を超えていますが、実際の国土エリアカバー率は60-70%と言われています。
日本には山岳部や島嶼部が多くあり、スマホの電波が入らない場所もまだまだ多いです。

投稿者は登山を趣味としていますが、少しマイナーな山へ登ったら登山口からすでに圏外というケースも多いです。

2025年、au Starlink Directサービスの開始により、日本国内でスマホが人工衛星と直接通信（Direct to Cell; D2C）できる時代がついに幕を開けました。
今年2026年にはau以外の主要キャリア各社のサービスも本格スタートする見込みです。

投稿者は、D2Cの可能性調査と実用的なユースケース探索、そして自分自身や友人の安全確保を目的として、主に登山の文脈でD2C回線を使ってリアルタイムに家族へ位置情報を送信し圏外の安全を確保する「AnzenMap」というサービスの開発とベータ版運用を2025年5月から継続しています。
これは、「遭難してから衛星通信で助けを呼ぶ」のではなく、「圏外行動中つねに位置情報を家族へ定期送信し、不測の事態が発生したら最後の消息地点を家族が確実に把握できるようにする」というコンセプトのものです。
山岳で滑落して気を失ったら連絡できない、スマホを谷底へ落としたら連絡できない、雪山でスマホの電源が切れて連絡手段がなくなる、といったシビアなケースも想定し、それでも可能な限りの情報を家族へ伝えるためのセーフティー策といえます。

このなかでは、いくつかのシステム要素へ取り組む必要がありました。

1. スマホ上で位置情報を定期取得してau Starlink Direct回線経由でSMS送信するアプリ
2. 圏外の端末からSMS送信した位置情報を自宅ゲートウェイにてデータ変換してクラウドへ載せて家族へ共有する仕組み
3. 日本上空を飛んでいるStarlink D2C衛星の現在位置をスマホ圏外で把握して「現在通信できそうか」を判断する仕組み
   これらの内容を紹介します。

また、この派生物として、公開されている非公式の衛星軌道情報をもとにして「現在の」Direct to Cell接続可能エリアが分かるマップも作成しました。
https://d2c-map.muo.jp/

実用面について、2025年8月末にはau Starlink DirectがSMS/RCS送受信だけではなくデータ通信に対応しましたが、Androidではごく一部の機種でのサポートに留まる（2025年10月現在）ため、「SMSベースで何が出来るか」という思考・システム運用は依然として重要な要素です。

また、D2C接続は「スマホが地上基地局の電波を掴んでいない時だけ接続される」という特性を持ちます。人里において適切に空が見える状態の圏外を見つけるのは困難であるため、テストも難航しました。

本セッションでは、D2Cの現状を把握するための概要、AnzenMapの開発とフィールドテストから得られた通信特性、スマホアプリ開発上の注意点、周辺地形に関して考慮すべき点を紹介します。
おすすめのテストスポットと、その探し方も紹介できれば、と考えております。

【テーマ】
複雑なビジネスロジックを持つ機能の設計についての、現実的なアプローチ

【想定する参加者層（前提知識）】
要件定義や設計から開発まで担当しているソフトウェアエンジニアを主な対象とします。
特に、複雑なビジネスロジックの実装で悩んだ経験のある方はきっと共感できる内容となっています。
他には、今後そのような業務を行う予定、または興味を持っている方も歓迎します。

MVCやオブジェクト指向、アジャイルな開発手法についての知識があると、より深くトークを楽しめると思いますが、それらを特別に意識しない、普遍的な「設計思想と現実的な判断基準」に焦点を当てたトークをする予定です。

※特定の業界知識は不要です。
※スピーカーは、Ruby on Railsで開発を行っていますが、設計思想と現実的な判断基準が中心となるため、他言語・他フレームワークのエンジニアにも十分応用可能な知見を提供します。

【トーク概要】
私の所属する会社では、クライアントと保証契約を締結するために必須の与信審査をRuby on Railsでプログラムのソースコードに落とし込んで自動化し、現在に至るまで約2年間運用してきています。

月間1万件を超えるこの審査業務は、与信に関する高度な専門知識や経験、柔軟な判断を要し、「プログラミングによる自動化に向かない」領域とされてきました。
しかし、私たちは、アジャイルなアプローチで開発を進め、「将来が読めない」という現実と向き合いながら、必要に応じて進化できるシステムを、泥臭くも丁寧に築き上げてきました。

本セッションでは、教科書的な設計原則と現実が衝突した際に、どのように設計判断をすればよいのか、具体例を交えながら、私自身の経験を踏まえて知見を共有します。
具体的には、以下のような内容について話します。

・拡張性を生む骨格設計：すべての土台となる基本ルールを、一番初めに明確化することの必要性
・Fat Modelを恐れない：ロジックをModelに集約させることで得られる凝集度と保守性
・判断基準を「設定」として切り出すコツ：個別パターンのビジネスロジックをカテゴリ化し、設定として切り出すことのススメ
・それでも吸収できない例外パターンへの対処法：可能な限りのグループ化と、最終手段としての影響を最低限に留めるハードコーディング/割り切りの判断基準

これは単なる「実装事例」ではなく、複雑なドメインロジックに日々格闘する全てのエンジニアに贈る、泥臭くも強いコードを生み出すための設計哲学と実践録です。
理想と現実のギャップに悩むあなたの現場に、即戦力となる「泥臭くも強いコード」を生み出すためのヒントを持ち帰ってください。

テーマ: 文字コード、PHP、PHP_CodeSniffer

想定する参加者層: 中級者ぐらい。ソースコードの文字コードに悩まされている人。

トーク概要:
EUC-JPで書かれたPHPアプリケーションのコードベースを触ったことはあるでしょうか？
多くのツールはソースコードがUTF-8であることを前提に作られているため、そうしたアプリケーションの開発に関わっていると、まれに困ることがありました。

そのアプリケーションの開発をしているときは課題を感じつつ、自身の体感では大きな問題なく開発していました。しかし、、EUC-JPを上手く扱えないClaude Codeの登場をきっかけに、思い切ってUTF-8への移行の着手を決意。アプリケーションのコードを全てUTF-8に置き換えるべく動きました。

単にソースコードを一気にUTF-8に変更すればいいかというと、そういうわけではありません。EUC-JPのコードの中にマルチバイトの文字列リテラルがある場合、UTF-8にそのままコードを変えると動作が変わる可能性があります。

では、ソースコードにマルチバイトの文字列リテラルが「ない」状態を保証できたらどうでしょうか？

このLTでは、i18nを参考にしたUTF-8化の作戦と、PHP_CodeSnifferのカスタムルールを使った工夫、そして苦労、最後にこれからの展望ををお話しします。

同じくEUC-JPやShift_JISなど、UTF-8以外のマルチバイトエンコーディングのコードをどうにかしたいと考えている開発者の参考になれば幸いです。

LLM の登場で、Chrome 拡張のようなシンプルな構成でホスティングする必要のないアプリは Vibe Coding だけで驚くほど簡単に作れるようになりました。
しかし、それを「継続的に」開発・運用しようとすると、

・動作確認はどうする？
・毎回、開発者コンソールからzipを手動アップロードするのは面倒

といった壁にぶつかり、Vibe Coding の手軽さが失われます。

本セッションでは、私が個人開発している Chrome 拡張の実際の開発環境を題材に、Chrome 拡張の E2E テスト自動化の方法やデプロイの自動化といった継続的開発を行うための開発手法を紹介します。
この Chrome 拡張の開発はすべて Vibe Coding で行われており、私は要件の指示とコードレビューのみ実施しています。この経験を紹介することで、LLM 時代の新しい開発プロセスとそのリアルな実践値を共有します。

【想定する参加者層】
・Chrome 拡張の開発に興味がある方、または開発で面倒さを感じている方
・特に、Chrome 拡張のE2Eテスト自動化や自動デプロイに関心がある方
・Vibe Coding やプロンプトエンジニアリングの実践例に興味がある方
・CI/CD や開発環境の自動化・効率化に関心がある方

【このセッションで得られること】
・Chrome 拡張のテストやデプロイを自動化する具体的な手法
・Vibe Coding での開発サイクルの実例

高可用性を実現するために冗長化の設計をしてみたものの、「机上の確認では問題なさそうだが、実際に障害が起きた時に本当に動作してくれるかわからない」と不安になることは誰しも経験があるのではないでしょうか。少なくとも自分はあります。特にKubernetesの設定は複雑で本当に機能するのかに自信が持てませんでした。
ではどうするか？という一つの回答として、できるだけ障害に近い状況を再現して試してみました。今回はKubernetesのPDBやトポロジー制約等のアプリケーションの可用性を担保する仕組みを諸々設定し、さらにAWS Fault Injection Simulator（FIS）を活用してカオスエンジニアリングとして意図的に障害を発生させ動作確認をしました。
本セッションでは、設定した可用性対策についての解説とそれを実際に検証して上手くいったことや上手くいかないことを赤裸々にお話しします。

Raspberry Pi Pico 2Wという小さなマイコンをRustで動かしながら、組込み開発の面白さを“ちょっと深く”味わっていく話をします。対象は、普段はWebやアプリを触っているけれど、マイコンにも興味がある学生さんやエンジニアの方、あるいはC言語での組込みに少し触れたことがあるけれどRustでの開発は初めて、という方です。

Raspberry Pi Pico 2Wは、1,000円ちょっとで買えるボードですが、デュアルコアCPU、Wi-Fi / Bluetooth、USB通信など、かなり本格的な機能を持っています。このトークでは、そんなPico 2WをRustで動かしてみる中で見えてきた“Rustらしい組込みの考え方”を紹介します。

トークの中では、

・Lチカ（LED点滅）のプログラムを動かす
・USB経由で、PCのGUIアプリからLEDの点滅速度を変える
・Blutooth通信を使ってスマートフォンのアプリ（Flutterで自作）からLEDの点滅速度を変える

という使い方を実物で示しながら、その中身で活躍するコードのテクニックを紹介します。単なるハードウェア制御ではなく、「PC・スマホ・マイコンをRustでつなぐ」体験を通して、Rustの良さを感じてもらえることを目標とします。

Rustで組込み開発をすると、最初は「何がそんなに違うの？」と思うかもしれません。でも、実際に書いてみると、変数の所有権や型システムが“動かないバグ”を事前に防いでくれたり、スレッドや割り込みの扱いがとても安心できる設計になっていたりします。C言語では見落としがちな部分を、Rustは“コンパイルエラー”として教えてくれるのです。これは、組込みのようなハードウェアに近い開発では特にありがたい特徴です。

このトークでは、そんなRustの「安全さ」と「気軽さ」を両立させる実践方法を、Raspberry Pi Pico 2Wという分かりやすい題材を通して紹介します。コードの細かい部分よりも、「なぜこう書くと安全なのか」「どんな考え方で設計するとRustが生きるのか」というポイントを中心にお話しします。また、途中でPico 2W特有の“ちょっと変わった構造”（PIOによる柔軟なI/O制御や、無線モジュールCYW43の動作など）にも軽く触れ、マイコンの内部構造を理解する面白さも感じてもらえるようにします。

このトークを通して、Rustを使った組込み開発が「難しそう」から「やってみたい！」に変わるきっかけを届けたいと思っています。マイコンを初めて触る方にも、CからRustへ一歩踏み出してみたい方にも、ぜひ聞いてほしい内容です。

WebAssemblyとしてビルドされたロジックを利用したAndroidアプリを試作しました。この試作によって、NDKに対応していないJavaScriptなどの言語で実装されたライブラリをAndroidアプリに組み込むことが可能になることが示唆されます。
WebAssembly（Wasm）とは、ビルドターゲットの1つで、RustやC++などをビルドして作成するほか、JavaScriptやPython、Rubyなどのスクリプト言語を変換することでも作成できます。Webブラウザでの利用のほか、サーバレス環境やエッジ処理などで利用されています。
今回は、この処理系をNDKを利用して、Androidアプリに組み込みました。その処理系経由でWasmを利用しています。このセッションでは、組み込みの詳細と述べるとともに、組み込み時のいくつかの注意点と工夫についても述べます。
複数の言語をまたいで関数が呼び出される様子に興味のある方、WasmのWeb以外でのフロントエンドでの利用について興味をお持ちの方は楽しめるのではないかと思います。

昨今のITエンジニアは先人の記事にとどまらず、生成AIを活用することで学びの速度を大きく上げられるようになりました。私自身も日々の開発や調査でAIを活用しています。
ある日、ファイル判定の仕様を調べる中で「RFC」に触れる機会がありました。RFCの存在は知っていましたが、実際に読んだことはありませんでした。いざ読んでみると「ちゃんと書いてある」、「読んでいなかったから、わからなかった」。 そんな体験をしました。

このLTでは
・ RFCの概要
・ RFCの読み方
・ RFCを読むことで得た“技術的な目の深まり”
・ 生成AI時代に必要な「裏どり力」の大切さ
について、私自身の小さな発見を例にお話しします。

深い学びをしていきましょう。

■ テーマ
システム分離、リプレース、テスト、移行戦略

■ 想定する参加者層
中級者以上を対象
安全なシステム分離、移行戦略に興味のある方

■ トーク概要

新卒4年目、ECサイト構築サービス「カラーミーショップ byGMOペパボ」のエンジニアです。今年1月に別のサービスから異動し、ジョインして間もなく、私は「レンダリングシステムを分離する」というミッションを任されました。
カラーミーでは、自分のショップのデザインを「デザインテンプレート」という機能で、独自の記法のテンプレートを用いて自由にカスタマイズすることがあります。この機能は、内部ではカスタマイズされたテンプレートをレンダリングする責務を担ったアプリケーションによって実現されています。

しかしこのアプリケーションには、ショップページの「テンプレートレンダリング処理」に加え、そのテンプレートに必要なデータを取得する「データ取得処理」、その他、他のシステムから参照されるさまざまな責務が密結合していました。 この構成は、柔軟性のあるシステムの実現や、パッケージのアップデートを難しくする可能性を秘めていました。
この課題を解決し、より柔軟で堅牢なアーキテクチャを実現するため、「テンプレートレンダリング処理」の責務を別のアプリケーションに分離する必要がありました。

もちろん、サービスを止めることは許されません。 その上で、別のアプリケーションに分離した上でも、レンダリング結果が変わらないことを保証する必要があります。そこで私が採用したのが、稼働中のシステムを徐々に新しいシステムへ置き換えていく「ストラングラーフィグパターン」と「ペンギンテスト」の考え方です。

ストラングラーフィグパターンは、システムを段階的に移行するための手法、そしてペンギンテストは、NE株式会社のさくらいさんがブログで紹介している、システムの移行前と移行後の動作を担保するための手法です。後者は、新旧両方のシステムに同じリクエストを流し、その結果を比較検証することで動作を担保するアプローチです。

本登壇では、異動して半年の私が、このシステム分離にどう立ち向かったのか。 ストラングラーフィグパターンとペンギンテストを参考にした具体的な戦略、新旧の安全な切り替え手法、移行中に実感したペンギンテストのメリット、そして無事に分離を完遂するまでの道のりをお話しします。

この発表を通じて、システムの安全な移行戦略や、段階的なリリースの具体的なノウハウを持ち帰っていただけます。

【テーマ】
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のビルドを行い、検証実験に至ったのか、その過程を共有します。

【テーマ】

JavaScript 3大ランタイム Node.js、Deno、Bun についてさまざまな観点から比較を行います。
さらに各ランタイムそれぞれが持つユニークな特徴なども深掘りしていきます。

【想定する参加者層】

• JavaScript / TypeScript に興味のあるすべての人（言語自体は知らなくても OK）
• Node.js、Deno、Bun。聞いたことはあるけど何が違うかよくわかっていない人

【トーク概要】

JavaScript ランタイムといえば何を思い浮かべますか？
一番メジャーなのは Node.js ですが、Deno や Bun を聞いたことがある方も多いかもしれません。

「セキュリティや Web 標準は Deno」「高速性は Bun」といった大きな特徴ではよく比較されるものの、各ランタイムを取り巻くエコシステムや、開発環境における違いなど細かい部分についてはあまり知らない方も多いと思います。

本発表では、JS エンジンや速度面はもちろん、ランタイム自体の開発言語やエコシステム、開発環境などにも焦点を当てて、各ランタイムの比較・ユニークな特徴を紹介したいと思います！

JS を知らない方には、JS ランタイムについて知ってもらい、
Node.js を使ってきた方には、Deno や Bun の違いを知ってもらい、
3つをすでに知っている方にも、さらにディープな違いを知ってもらえる内容です！

30分後、きっとあなたの ”推しランタイム” が見つかりますよ

・テーマ
オンプレミス脳からクラウドネイティブ脳への「思考のリファクタリング」を、料理のレシピのように4つのステップで話します。現場の失敗談と成功体験を材料として混ぜ込み、クラウド移行の悩みを解消するレシピを提供します。
さらに、「思考のリファクタリング」にAIが与える可能性を、実験的な「隠し味」として紹介します。

・想定する参加者層

• オンプレミスレシピの呪縛から解放されたいエンジニア
• クラウド移行で迷子になっている方
• AIによるアレンジで開発レシピを革新してみたい技術者

・トーク概要
従来のオンプレミス環境で培われた設計思想から、クラウドネイティブな考え方への転換を、4つのステップとして体系化してお話します。技術的な詳細よりも、思考プロセスの変化に焦点を当てることで、参加者の方が持ち帰って実践できる考え方やアプローチを中心にお話しします。クラウドネイティブへの転換に悩む方々にとって、明日からの取り組みのヒントとなるような内容を目指します。
また、AI技術を使って設計プロセスの効率化や品質向上にどの程度貢献できるのかを実際に試してみた結果を紹介します。成功例だけでなく、期待通りにいかなかった事例も含めて、現実的な視点でAI活用の可能性と限界について考察します。

オンプレ思考からクラウドネイティブ思考への転換レシピ
～AI活用のスパイスを添えて～

• ステップ１　システム分離への思考転換
• ステップ２　データ戦略の思考転換
• ステップ３　処理方式の思考転換
• ステップ４　障害対応の思考転換
• アレンジ　　AI活用の可能性

共同スピーカー:加藤寛士

よりパワフルで柔軟な 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 進化の方向性をご紹介します。

◆テーマ
Webサイトのテーブル（表）表示が思い通りにいかない理由と対処法をHTML/CSSの仕様や現職における巨大テーブル開発で培った経験に基づいて紹介します。

◆想定する参加者層（前提知識）
・Webサイト制作を最近はじめてテーブル表示のじゃじゃ馬っぷりに苦しめられてる初心者
・Webサイト制作に慣れてるけど、テーブル表示のトラブルに場当たり的に対応してるので結局なにがどうダメなのか体系的に理解してない中級者

◆トーク概要
Web開発者の悩みの種に「表（テーブル）の表示が上手くいかない！」という問題があります。
装飾が上手くいかない、サイズ調整が上手くいかない、スマホ表示が上手くいかない…どの悩みを1度は抱えたことがあるはず。
そして、HTMLやCSSをガチャガチャいじったらなんか上手くいったからいいや…と場当たり的な対応でその場を凌いでる人もいるのではないでしょうか。

本セッションでは、私が現職で取り組んでいるSaaS製品の巨大テーブル開発における経験やHTML/CSSの仕様などに基づき、テーブル表示の上手くいかないところとその対処法を整理します。
歴史的経緯により仕様と挙動が混沌に満ちているテーブル表示の実態を理解して、テーブルと仲良くなりましょう！
たった30分で厄介なテーブル実装に自信を持てるようになるお得な発表です！

VS Codeのオープンな文化と、IBMが推進するエンタープライズ開発者体験(DX)。その交点には、“ギーク的思考“と”企業的スケール“を融合する挑戦があります。
このセッションでは、IBMが提供するVS Code拡張機能を通じて、クラウド(IBM Cloud)、AI (watsonx)、コンテナ(Red Hat OpenShift)のローカル開発からクラウドデプロイ、AI支援まで一気通貫で行う開発フローをご紹介します。