トーク

2026年1月9日か10日、その場で rails new してそのバージョンでライブコーディングします。
何を作るかはその場にいるみんなとノリで決めよう。

Python風言語でプログラミングするゲーム「農家は Replace() されました」のエンドコンテンツ、リーダーボードでは、より効果的な農場をプログラミングして世界中のプレーヤーとタイムを競います。
タイムを縮めるためには計測が大切です。どのようにタイムを縮めるのか、その考え方を紹介します。

Webサービス開発、特に自社事業の開発では、機能要件と非機能要件がしばしば明確に分けて扱われます。
企画や施策を実現し、売り上げるを上げるものは「機能要件」、パフォーマンス・UX・セキュリティ・アクセシビリティなどの領域は、「非機能要件」として扱われます。

果たしてここで分類された非機能要件は、本当に非機能的なものでしょうか。

本セッションでは、「機能要件」と「非機能要件」と二分化された分類を1からもう一度捌き、これらが離散的ではなく連続的に捉えるものであり、エンジニアだけではなく全ロールの人が向き合う必要があるという考察をします。

想定参加者:

• Webサービス開発者(エンジニア、デザイナー)
• プロダクトマネージャー・プロダクトマネージャー
• カスタマーサポート・セールス

【テーマ】
・ AWS の IAM RoleやIAM Policy、およびAWSにおけるアクセス可否の判定の仕組みなど

【想定する参加者層】
・ AWSを業務・私用問わず触っている方
・ IAM RoleやIAM Policyについて詳しく知りたい方（特にIAM RoleのAssumeRoleやPrincipalなど）
・ アイデンティティベースポリシー、リソースベースポリシーなどポリシーの種類やそれによる最終的なアクセス可否の判定について知りたい方

【トーク概要】
2025年もいろいろなセキュリティ事故がニュースになり、特に2025年後半はサプライチェーン大手企業に対する攻撃により、我々の生活に関係するほどの影響がありました。
このようなセキュリティ事故ですが、「セキュリティ関連の設定不備」が原因となる事例がかなり多いのも事実です。
IPAの「情報セキュリティ10大脅威 2025」でも3位となっていることからも、「セキュリティ関連の設定不備」がどれほど致命的であるかがわかります。

そしてAWSにおいてセキュリティの基本であり、かつ最も重要なもの、それはIAM PolicyとIAM Roleです。
しかし、それだけ重要なIAM PolicyとIAM Roleですが、意外と十分に理解しきれていない、という方もいらっしゃると思います。
特にIAM RoleのAssume RoleやPrincipal、そしてアイデンティティベースポリシー、リソースベースポリシーなどの各種ポリシーが
複雑に絡み合った場合のアクセス許可・拒否判定の挙動がどうなっているかについて、なかなか把握できないという方もいらっしゃると思います。

そこでこのセッションでは、そんなセキュリティ的に最重要項目であるIAM PolicyとIAM Roleについて、
・ IAM PolicyとIAM Roleの基本
・ IAM RoleのAssume RoleやPrincipal
・ 各種ポリシーが複雑に絡み合った場合のアクセス許可・拒否判定のしくみ

についてお話しし、皆さんが携わっているシステムにおいて、思わぬセキュリティ事故が発生することを防ぐためのお役に立てればと思います。

【セッションゴール】
・ IAM PolicyとIAM Roleの基本、およびAssume RoleやPrincipalなどの仕組みを理解できるようになる
・ AWSにおけるアクセス許可・拒否判定のしくみを理解できるようになる

概要

人生で何度も入力したことのある住所フォーム。
しかし、入力するたびに「郵便番号のハイフンの有無でエラーになる」「全角しか受け付けない」「ブラウザの自動補完が効かない」など、細かな苛立ちを感じたことはないでしょうか。

では、ユーザーにとって使いやすく、迷いのないフォームを作るにはどうすればよいでしょうか。
その判断の指針となる考え方として、「驚き最小の原則」があります。
この原則は「どう振る舞うべきか迷ったときには、相手が最も驚かない選択をする」という考え方です。

このセッションでは、住所フォームを題材に「驚き最小の原則」を具体的な設計判断に落とし込む方法を紹介します。
具体的には次のような内容を予定しています。

• サービスにおける「住所」という重要情報の立ち位置
• 「驚き最小の法則」とは何か、サービス開発ではどのように応用できるのか
• 住所フォームでのHTMLで構築するための input 要素や select 要素、または補強する属性 (placeholderなど）の正しい使い方
• システムによる住所自動入力と、ユーザーの意図した手動入力を両立させる工夫

日々 UI を設計・実装するエンジニアに向けて、ユーザーが自然に感じる動作を実現するための具体的な指針を提供します。
セッションを聞いた後、判断に迷ったときには「驚き最小の原則」に立ちかえり、より良い選択ができるようになることをゴールとします。

想定する参加者

• UI を実装する際にどのような画面を作ればよいか判断に迷う初級〜中級エンジニア
• UI 設計の判断基準をジュニアエンジニアに伝えていきたいベテランエンジニア
• 専任のフロントエンドエンジニアやデザイナーがいない現場で UI を作る必要があるエンジニア

想定する参加者に持ち帰ってほしいこと

• サービス開発をしていて迷ったときに「ユーザーが驚きが少ない選択」を取れるようになる「驚き最小の原則」という判断軸を身につけること
• input 要素や select 要素など、フォーム構築する上で必要なHTML要素を定義に沿って正しく使うこと

Nxの被害など、npmパッケージのサプライチェーン攻撃が現実の脅威となった今、開発環境のセキュリティ対策は全ての開発者にとって避けられない課題です。

本セッションでは、実際の攻撃事例から学ぶ教訓をもとに、今すぐ実行できる対策から1Password CLIとコンテナ技術を組み合わせた理想形まで、段階的にセキュリティを強化していく現実的で実践的なアプローチを紹介します。

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

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

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

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

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

Goは、Kubernetesやコンテナランタイムをはじめクラウドネイティブ基盤の中核を担っている言語です。
しかし、Goは決して「何でもできる」万能言語ではありません。

Goの非常に扱いやすい並行処理モデルは、OSプロセスを直接扱うような低レベルな領域との相性が悪いという側面を持ちます。
このような処理は、実際にOSに干渉してコンテナを生成する、低レベルコンテナランタイムに欠かせない技術です。
現在低レベルランタイムのデファクトスタンダートであるruncはGoで書かれていますが、そのプロセス制御はCGoという仕組みで呼び出されるC言語のロジックに強く依存しています。

このセッションでは、上で述べたGoの設計と低レベルランタイムのギャップを紐解きながら、以下のようなトピックを深掘りします。

• コンテナとは何か、OSプロセスとsyscallの基礎
• コンテナランタイムの構造 (高レベル/低レベル)
• Go特有の並行処理、goroutineとプロセス作成に及ぼす影響
• CとGoの2言語で簡素なコンテナを作るライブコーディング
• 代替ランタイムであるyouki、crunの紹介

コンテナランタイムやGo言語の並行処理の仕組みを理解し、プロジェクトに適した言語を選ぶ重要性を一緒に再確認していきましょう。

[対象者]

• コンテナを日常的に使っており、その裏側を理解したい方
• Go言語の並行処理(goroutineとその中身)に興味がある方
• 普段はアプリケーション開発が中心だが、OSの動きを学んでみたい方
  • OSやシステムプログラミングに興味があるアプリケーションエンジニアが、言語・OSやコンテナの裏側を覗く第一歩として最適です。

[アウトライン]

1. コンテナとは何か/OSプロセスとsyscall
2. コンテナランタイムのアーキテクチャ
3. ライブコーディング: Cで作る簡素なコンテナ
4. Goの並行処理、goroutineとその実行モデル
5. ライブコーディング: Goで作る簡素なコンテナ
6. runcにおけるCGoでのプロセス管理
7. 代替ランタイム: youki、crun、etc...

ソフトウェアが複雑になるにつれ、安全に扱うことができ、バグが発生しにくいイミュータブル性の重要性が増しています。Javaでイミュータブルなデータといえばレコードですが、自作のクラスであってもイミュータブルにすることができます。

そこで、本セッションではミュータブルとイミュータブルとはどういうことなのかを解説し、ミュータブルなデータの問題点と、その解決法としてのイミュータブルについて紹介していきます。さらに、イミュータブルなコレクションなどについても紹介します。

2025年5月、Java 25がリリースされました。

「えっ、Javaってもう25まで進んでるの？」――そう驚いた方、実はJavaはその間、驚くほど大きく変わりました。
あなたのイメージするJavaのバージョンはいくつでしょうか？
Java 11ですか？それとも8ですか？まさか7以前なんてこと…。

Java 8/11の時代から、Javaは6ヶ月ごとに新バージョンをリリースしながら着実に進化を続けてきました。
型推論、レコード、パターンマッチング、仮想スレッドなど、新しい機能が次々と投入されており、昔の知識のままで最新のコードを見たら、「これ、本当にJava？」と二度見してしまうことでしょう。
Java仮想マシンやガベージコレクタの改善、AOTコンパイラのサポートなどによって、実行時のパフォーマンスも劇的に向上しました。

本講演では、「懐かしのJava」から「モダンなJava」への変化を、実際のコード例とともに紹介します。
「Javaは古い」「冗長で書きにくい」というイメージを持っている人にこそ、変貌したJavaを見ていただきたいです。

対象者

• Javaの最近の動向が知りたい人
• 古いバージョンのJavaを使っていて、時代に置いていかれたくない人
• Javaは随分触ってないけど今どうなっているのか気になる人

テーマ

Javaもどんどん変わっているということを知ってもらいたい

【テーマ】
・ ノーコードツールによるコードレス（=コードを書かない）開発の導入による恩恵・課題など
・ Lambdaレス（=コードレス）アーキテクチャの特徴
※以後「コードレスアーキテクチャ」について「Lambdaレスアーキテクチャ」と記載します。

【想定する参加者層】
・ ノーコードツールやLambdaレスアーキテクチャについて興味を持っている方、知りたい方
・ 業務改善に興味を持っている方、業務改善が課題となっている方
・ AWS Step Functionsについて興味を持っている方、知りたい方（使用経験は必須ではありませんが、経験があるとなお一層理解が深まります）
※ エンジニアである必要は全くありません。非IT部門の方にとっても十分役に立つ内容となっています。

【トーク概要】
私は今年、KDDIグループ約4000人が使用するJira/Confluenceのオンプレ→クラウド移行を実施しました。
そしてその際、業務改善として実施したオペレーションの自動化において、AWS Step FunctionsおよびJira Automationなどノーコードツールによる「Lambdaレスアーキテクチャ」を導入しました。

もともとアプリ開発といえば「コードを書く」ものであり、AIが台頭した現在は「AIにコードを書かせる」という流れになっていますが、やはり現在でも「コードを書く」のが主流だと思います。
しかし近年は運用工数削減や非エンジニアの方でもアプリ開発ができる事、そして「Lambdaレスアーキテクチャ」の普及もあり、AWS Step Functionsのようなノーコードツールによる「コードを書かない」開発を導入するケースも増えています。

はたして「コードを書かない」開発は「コードを書く」開発と比較して何が良いのでしょうか？
そして、何が課題になるのでしょうか？

そこでこのセッションでは、先ほどの業務でのLambdaレスアーキテクチャの導入経験から学んだ
・ Lambdaレスアーキテクチャの特徴
・ ノーコードツールの恩恵と課題
・ AWS Step Functionsを導入する際の注意点・ノウハウ

について、エンジニアおよび非エンジニア、両方の観点からお話ししたいと思います。

【セッションゴール】
・ Lambdaレスアーキテクチャ、ノーコードツールの概要、およびノーコードツール導入によるメリット・注意点をエンジニアと非エンジニア、両方の観点から理解できるようになる
・ AWS Step Functionsを導入する際のノウハウや注意点を理解できる

【テーマ】
・ システムやデータベースなどの大規模マイグレーションを担当する際、それをどう実施するか（=担当者観点）
・ 大規模マイグレーションが発生した際、それに対して何をすべきか（=ユーザー観点）

【想定する参加者層】
・ 大規模マイグレーションを担当する可能性のある方（インフラ管理、IT資産管理者など）
・ システムやデータベースなどを利用したアプリケーションを開発・運用使用している方（アプリケーションエンジニア、クラウドエンジニアなど）
※自分が大規模マイグレーションの担当者でなくても、十分役に立つ内容となっています。

【トーク概要】
皆さんが普段使用しているシステム・データベースなどのリソースは、いつの日か必ずEoL(End of Life)がやってきます。
そしてその際、もしかしたら会社並びにアプリユーザー全体に影響を及ぼすような大規模なマイグレーションが発生するかもしれません。

もし自分がそんな大規模マイグレーションの担当になったとしたら、皆さん何をすればいいのか、何に気を付けたらいいのか、お分かりになるでしょうか？
またそうでなくても、大規模マイグレーションが発生したリソースを使ったアプリを開発・運用していた場合に、何を対応すればいいでしょうか？

このセッションでは、某有名決済アプリ関連のデータベースマイグレーション、そして弊社にてKDDIグループ4000人以上が使用するJira/Confluenceの大規模マイグレーションの経験から、
・ 自分が大規模マイグレーションの担当になった際、何に注意し、何をすればいいのか
・ 大規模マイグレーションが発生したリソースを使ったアプリを開発・運用していた場合に、どんな対応をすればいいのか

についてお話したいと思います。

また大規模マイグレーションの担当者観点から見た「大規模マイグレーションが発生した際のアドバイス」もお話しする予定です。

【セッションゴール】
・ 大規模マイグレーションの担当になった際に注意すべきこと、意識すべきこと、実施すべきことを理解できる
・ 大規模マイグレーションが発生した際に対応すべきこと、意識すべきことが理解できるようになる

生成AIの普及により、エンジニアの開発スタイルは劇的に変化しました。
Claude CodeやCodexなどのコーディングエージェントを利用することで、誰でもある程度のコードを書けるようになり、知らないことの調査やエラー解決も短時間で可能になりました。
しかし、その一方で「生成されたコードを理解できていない」や「AIの回答の成否を判断できていない」といった課題も顕在化してきており、AIに使われる側に回ってしまうケースも増えています。

だからといって、AIを禁止にするのはナンセンスです。
むしろ、これからの時代、AIを使いこなす力は不可欠なスキルとなります。
そのために必要なのは、AIに依存するのではなく、AIを活用して成長するための新しい育成デザインです。
開発スタイルが変化したのと同じように、育成のアプローチも変化させる必要があります。

本セッションでは、AI時代のエンジニア育成において実際に遭遇した課題と、それに対する実践的なアプローチを紹介します。
実際にチームで試行錯誤しながら取り組んでいる施策として、AIを使わずに問題解決を考える「No AI Day」や、AIとの対話を通じて理解を深める「learnコマンド」、「パーソナライズされたAIコードレビュー」などを共有します。

AI時代に求められるのは、AIに「使われる側」ではなく「使う側」になるための育成です。
現場での試行錯誤から得た知見を通して、明日からチームで試せる実践的なアプローチを共有します。

登壇や記事執筆といった発信活動は、エンジニアのキャリアアップに良い影響をもたらします。

発信活動を通して、自身の知見・経験が言語化され、誰かの課題を解決し、キャリアの可能性が広がる。発信活動を継続することで、新たな仲間との出会いも生まれ、活動そのものが「楽しい！」と感じるようになる。

多くの人々が「何かを得られる」「何か楽しいことがある」と信じ、実際にリターンがあるからこそ、富山の地でのイベントが10年も続くのだと思います。

そんな発信への熱い想いを持つであろうみなさんの組織に、発信文化は根付いているでしょうか？

発信が組織の文化として根付くには、自分以外のメンバーも継続的に発信へと取り組んでいる必要があります。一方で見落としがちですが、発信活動（特に外部への発信）は、しばし多くの労力を伴います。自身の思考整理にはじまり、情報の裏取り、執筆作業、発表練習などなど。発信をしたことのない誰かに、発信活動を通して「何かを得られる」「何か楽しいことがある」と感じてもらい、能動的な行動へとつなげるには、様々な壁を超えなければなりません。

本セッションでは、長らく個人で発信活動を続けつつ、業務ではDevHRとして試行錯誤を積み重ね、組織全体の発信数が年間10件にも満たなかった状態から、直近半年で50件を超えるまで引き上げた実績も交えつつ、「組織全体で壁を超え、発信を文化として根付かせる」ために必要なことについて、シェアできたらと思います。

Learning Outcome

• 発信活動のモチベーションは、大きく3つに分類できる
  • 「発信そのものが楽しいから」
  • 「個人の成長・ブランディングのため」
  • 「組織の成長・ブランディングのため」
• 人を発信活動へと向かわせるには、「腹落ちする理由」と「機会」が必要である
• 発信活動の継続に必要なのは、外部露出を増やすことではなく、言語化習慣を身につけ、発信に対するFBが得られる環境を用意すること

想定する聴講者

• 身近に発信活動の仲間が欲しいと感じる方
• 三日坊主になりがちな発信活動を長く継続させたいと感じる方
• 組織に発信文化が根付かず困っている、または根付かせたいが何から着手すればいいか分からないマネージャーの方

セッションの流れ

1. 我々はなぜ発信するのか？

• 発信活動のモチベーションの3分類について
• もし誰かを発信へと向かわせるのなら、発信以外の活動を上回る楽しさ、あるいは意義を提示しなければならない

2. 我々は発信活動から何を得るのか？

• 発信活動の継続に最も重要なのは、言語化の習慣を身につけることである
• そして、発信活動によって得られる最大のメリットは、自身の言語化に対するレスポンス・FBを通して、言語化の精度が発信を繰り返すたびに上がっていくことである

3. 我々は発信文化を広めるために何をすべきなのか？

• そもそも、1や2の考えに至ったのは、7年以上続けている自身の登壇活動から得た成功体験と、自身が所属する組織に発信文化を持ち込もうとして頓挫し続けた失敗経験が背景にある

成功体験

• 外部への発信を継続することで、エンジニアとしての成長の天井を自ら引き上げることに成功した
• いつしか「組織の顔」として社内で認識されるようになり、人事職という新しいキャリアのルートを切り拓いた

失敗体験

• 「発信そのものが楽しい」という自身のモチベーションを自分以外の人にも当てはめてしまい、最初の一歩すら踏ませることができない
• 「個人の成長・ブランディング」につながるメリットを示すも、組織が「他者や組織に対する貢献・ホスピタリティを重視する」カルチャーであるために、高い心理的ハードルを超えるほどの価値を感じてもらえない

転機

• 難航するエンジニア採用へのテコ入れのため、これまで殆ど注力してこなかった採用広報・技術広報の領域に大きな投資をすることが決まる
  • そして、その予算編成と年間の活動計画の立案を突然任される
• 上位スポンサーを決めたカンファレンスのうち、3件はスポンサーセッションをもらえることに
  • ここで初めて「登壇を業務として、自分以外の誰かに依頼する」経験をする
  • 登壇のネタは、依頼先のメンバーとすり合わせしつつ、こちらから提案
  • 結果、「組織の成長・ブランディングのため」にお願いした登壇は、自分では絶対に生み出すことのできない素晴らしい内容のものとなった

※以降、直近の発信文化醸成の試行錯誤を交えつつ、Learning Outcomeへとつなげていきます。

【テーマ】
サーバーサイドレンダリング（SSR）における「クロスリクエスト状態汚染」の危険性と、その根本原因となる設計上の問題の解説。モダンWebフレームワーク「Astro」を例に、リクエストごとに状態を安全に分離するための具体的な設計パターンと実践的対策。

【想定する参加者層（前提知識）】
Webアプリケーションの開発経験がある方 (特定のフレームワーク（Astroなど）の知識は必須ではありません。)

【トーク概要】
「ローカル開発では完璧に動くのに、本番環境で時々データがおかしくなる…」 そんな経験はありませんか？その原因、もしかしたらサーバーサイドでの「状態管理」の実装にあるかもしれません。

サーバーサイドレンダリング（SSR）のような、サーバー上でリクエストごとに処理を行うアーキテクチャは、Webのパフォーマンスを向上させる強力な手法です。しかし、クライアントサイドの感覚で安易に状態管理ライブラリを導入すると、実は時限爆弾を抱えている可能性があります。

同時リクエストが多発するサーバー環境では、あるユーザーのために用意された状態が、競合によって別のユーザーに漏洩してしまう、「クロスリクエスト状態汚染」という深刻な問題を引き起こす可能性があるのです。これは単なる表示の不具合に留まらず、個人情報漏洩に直結しうる、極めて危険なセキュリティリスクです。

このセッションでは、多くのWeb開発者が見落としがちな、このサーバーサイド特有の落とし穴を深掘りします。 なぜこの問題が起こるのか？その根本原因は、サーバー上でただ一つの共有データ置き場を、複数のリクエストで使い回してしまうという、設計上の問題にあります。 セッションでは、モダンなWebフレームワーク「Astro」と状態管理ライブラリ「Nanostores」を具体的なケーススタディとして取り上げ、どのようなコードが「地雷」となり、公式ドキュメントがなぜサーバーサイドでの安易な利用に警鐘を鳴らしているのかを、実際のコードを交えて解説します。

昨今のITエンジニアは求められる知識と技能が広がり続けています。私自身もWeb業界にいてその変化を強く感じてきました。これまでも新しい技術を学び、自分のできることを増やす機会は多くありましたが、生成AIの登場によって学び方は少し変わりました。

これまでバックエンドエンジニアとしてキャリアを積んできた私がフロントエンド開発に挑戦し、日々の実践と生成AIの活用を通じて成長していった過程をお話しします。
最初はTypeScriptでCLIツールやREST APIを作るところから始め、React.jsで小さなアプリを作ってアウトプット。転職後は実務でフロントエンド開発を進んで担当し、ペアプログラミングを実施することで自然と自らフロントエンド開発を進められるようになりました。

学びを支えたのは「継続して手を動かすこと」と「生成AIを学習の加速装置として使う姿勢」です。自分に無い実装の引き出しを他の人と一緒に実装することで獲得したり、AIの出力を鵜呑みにせず一次情報を調べ、実装で確かめることで理解を深めました。人との協働による実践的な成長と生成AIによる学習サイクルの高速化がうまく融合しました。

その積み重ねの結果、私はフロントエンド中心のプロジェクトに参加し、自身の責務を果たすことができました。
このセッションでは、「新しい領域を学ぶためにできる工夫」、「生成AIによって変化した自学習」、「実践を通じてどう変わっていったか」を、私自身の経験をもとにお話しします。

話すこと(変更の可能性あり)
・ 新しい領域を学ぶときの工夫
・ 生成AIによって自学習がどのように変化したのか
・ たくさんの実践を経て自分がどう変化したのか

プログラムを書いたり文章を入力したりする際に欠かせないキーボード。
その中には、スイッチやキーキャップなどのパーツを自分で選び、好みの打鍵感やレイアウトを追求する自作キーボードという世界があります。

自作キーボードのファームウェアは、従来は C 言語で書かれることがほとんどでした。
しかし、 Go 言語で書けるとしたらどうでしょうか？

このトークでは、組込環境で使える Go である TinyGo を使って、自作キーボードのファームウェアを作る過程を紹介します。

• 自作キーボードを作るために必要な要素
• TinyGo を選択した理由と、そのメリット
• TinyGo で実際に開発する際の流れ

さらに、セッション後半ではライブコーディングを行い、 TinyGo でシンプルなキーボードファームウェアを一から作るデモを行います。

具体的には、キー入力、レイヤー機能、 USB HID 出力を最小構成で実装します。
Go でこんなに簡単にキーボードが作れるのか、という体験をお届けします。

テーマ

ドメインイベント導入と責務分離の実践

想定する参加者層

保守・機能追加で副作用や依存の整理に悩む初級〜中級の開発者

トーク概要

ドメインイベント、使っていますか？
これは、注文完了やユーザー登録などビジネス上の“出来事”を表すモデルです。
状態変化を出来事として切り出すことで、副作用が見える場所にまとまり、設計の見通しが良くなります。

本セッションでは、既存コードに潜むイベントの見つけ方から始めて、責務分離から非同期処理への段階的なリファクタリング手順を紹介します。
小さな一歩から始められる実践に絞るので、無理なく取り入れられます。
ぜひ「あ、こう設計すればいいのか」という発見を持ち帰ってください！

2024 年の re:Invent で発表され、2025 年 5 月に GA（一般提供開始）となった Aurora DSQL。Google Spanner 対抗（？）のサーバーレス分散 SQL データベースとして注目を集めた割に、（2025 年 10 月中旬時点では）具体的な採用事例の話はほとんど聞きません。その一方で「従来の Aurora PostgreSQL から移行する形で採用しようとして失敗した」というネガティブな話は聞こえてきたりします。

（たぶんそれ、目的・用途に合わせたデータベース選定になっていなかったんじゃないかと…？）

私自身は、これまで「ゲームで体感！Aurora DSQL の OCC」（JAWS ミート 2025）や「攻略！Aurora DSQL の OCC」（JAWS FESTA 2025 in 金沢）などのセッションを通じて、Aurora DSQL のキモである OCC（楽観的同時実行制御）の特性を紹介・説明してきましたが、参加者の反応などから、やはり具体的なアプリケーションの実装例が示されないと理解が難しい印象を受けました。

というわけで、今回は架空の予約サイト（例：宿泊予約）の実装に Aurora DSQL を使い、

• 対象（例：人数・日程・プラン）の選択（仮確定）を先着順に処理する【⭐︎1】
• 対象選択後、必要事項（例：氏名・連絡先など）の入力および決済完了まで一時確保する【⭐︎2】
• 必要事項入力・決済完了後に予約を成立させる
• 一時確保の状態のまま一定時間経過したら予約不成立として在庫に戻す

という一連の流れを、NG 実装例と比較しながら説明していきます。

【⭐︎1】 Aurora DSQL では OCC の特性上、同一キーを持つ行を挿入または更新する処理の実行（成功）が「必ずしもトランザクションの開始順・コミット順にならない」という問題があります。
　→参考 : https://www.docswell.com/s/hmatsu47/ZJQYXX-aurora-occ-jaws-festa-20251011#p36

【⭐︎2】 Aurora DSQL には一般的な RDBMS が持つ行ロックの機構がないので、DBMS レベルでのロックを使わず、かつ一時確保した側が優先されるよう排他制御する必要があります。

■想定する参加者

• データベースが好きな方
• データベースは好きじゃないけれど、アプリケーション開発でデータベース周りの処理の実装から逃れられない方
• Aurora DSQL が気になる方
• 業務案件で Aurora DSQL を扱わないといけなくなりそうな方

一見難しそうですが、実際にはあまり高度な技術は使わない想定です。

（実装言語やフレームワーク・ORM（利用有無を含め）などは検討中です）

■注

• こちら↓の記事で扱っている内容とは全く別物・別趣旨です（ちなみにこの記事の著者の方とは知り合いです）
  • https://blog.serverworks.co.jp/_dsql-reservation