トーク

テーマ

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（リンクボタン）を実装するときに配慮すべきことに気づける

テーマ

定理証明：複雑なロジックと事実上無限の入力を持つソフトウェアに対して、テストケースの網羅性に依存せず、論理的に挙動を保証する手法およびその実例

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

• 計算機科学に興味があるが敷居の高さを感じている方
• 設計と一体化した品質保証に興味がある方
• 形式手法や定理証明に関する前提知識は仮定しません
• 特定の CPU 命令セットに関する前提知識は仮定しません
• 特定のコンパイラバックエンドに関する前提知識は仮定しません
• 型システムに関する理論的な前提知識は仮定しませんが、何らかの静的型付き言語によるプログラミング経験は前提とします
• 基本情報技術者試験に出題されるような計算機アーキテクチャの初歩、例えば「メモリとは何か」のような知識は前提とします

トーク概要

本セッションでは、定理証明支援系 Lean を用いたコンパイラの実装技法を解説します。ただしこれは本質的にはコンパイラのトークではありません。頭の痛い複雑なロジックや、うんざりするほど多様な入力データと戦っている、すべてのソフトウェアエンジニアに贈る新しい世界への招待状です。

今日、プログラムを書く際に一緒に単体テストを書くことは、一種のマナーとして広く普及しています。しかし、かつて Dijkstra はこう言いました。「テストではバグの存在を示すことはできても、不在を示すことはできない」つまりテストが成功していたとしても、それはたまたまテストケースが不足していてバグを踏まなかった可能性が否定できない、というのです。一方で、仮に全通りのテストケースを生成してバグの不在を示そうとした場合、組み合わせの爆発により膨大な数のテストが必要になってしまいます。例えば「長さ 3 以下の char の配列を受け取る関数」をテストするだけでも入力パターンは 16,843,009 通り。通常の任意長の配列を受け取る関数ならば文字通り「無限個のテストケース」が必要です。

本セッションで紹介する定理証明は、文字通り、この「無限個のテストケース」を扱うための手法であるといえるでしょう。テストしたい関数の性質を型レベルの制約として表現することで、単体テストのような実行時ではなく静的な型検査時に、かつ「任意の char 配列」のような事実上無限個のテストケースに対して関数の性質を保証できます。

いくつかある定理証明支援系の中でも、Lean は単に証明を記述するだけでなく、実際に動くプログラミング言語であるという面で近年注目を浴びています。一例として、Amazon Web Service では、認可ポリシー記述言語である Cedar の開発と最適化のために、この Lean を採用しています。認可ポリシーエンジンの実装は「ロジックが複雑」「あらゆるパターンに対応する必要がある」「最終結果がぱっと見で分からない」「ミスがあると被害が甚大」という点で、まさに定理証明向きの事例と言えます。また、国内においてもちょうど日本語書籍『ゼロから始める Lean 言語入門』が出版されたばかりで、今 Lean が盛り上がりつつあるのは間違いないでしょう。

本セッションでは、Lean を利用して、自作言語をコンパイルしてシンプルな CPU 上で動かすための「証明付きコンパイラ」を実装します。コンパイラもまた、複雑なロジックと多様な入力が求められるソフトウェアの典型です。ところで、引数と戻り値を持つ個別の関数のテストならともかく、ここで言う「コンパイラの正しさ」とは何でしょう？ コンパイルしたプログラムの挙動が正しいこと？ ではその「正しい」とはどういう状況か、定義できるでしょうか？

この問いへの答えとして、今回の解説では、コンパイラの性質を「ソース言語の意味論」と「ターゲット言語の意味論」の間をつなぐものとして定式化し、実装したコンパイラが意味論を保存することを証明します。また、コンパイラの挙動を保証するための理論的な解説に加え、実際に動くプログラムを書けるという Lean の特性を活かして、「インタプリタ」「VM」そしてその間をつなぐ「コンパイラ」をそれぞれ実装し、簡単なプログラムをコンパイルして動かす様子もお見せします。

受講にあたって必要なものは、プログラミング経験者であれば普通に知っている程度の知識と、ほんの少しの知的好奇心だけです。定理証明や特定の CPU 命令セットに関する前提知識は要求しませんし、それどころかコンパイラとしては、最適化も行わない、本当に素朴な実装しかしません。むしろ「コンパイラの正しさとは何か？」を題材として、複雑なプログラムの挙動も数学的にきちんと定式化できるのだ、そしてそのための理論や考え方は、他ならぬあなた自身とも無関係の世界ではないのだ、という感動を味わって頂ければと思います。

テーマ

4つの異なる言語・フレームワークにおける「列挙型（Enum）」の比較から学ぶ、設計思想の多様性と型安全性の未来

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

中級者以上を対象 （複数の言語のいずれかで開発経験があり、基本的な型システムやデータベース連携の概念を理解しているエンジニア）
Java、C#、Ruby、JavaScript（TypeScript）を想定しています。異なるコミュニティが集まるこの場所で、あえてすべての言語に共通する、そして最も設計思想の違いが表れる機能の一つ、「列挙型（Enum）」を徹底的に解剖します。

一見シンプルなEnumですが、その実装は言語の哲学そのものです。本セッションでは、この共通概念が各言語でどのように進化し、開発者にどのような設計上の恩恵と制約をもたらしているのかを、実用的なコード例を交えて比較・考察します。

トーク詳細

本トークでは次の内容について話を進めます。

1. Enumとは一般的にどのようなものか？
2. Enumはクラスか定数か
   　2.1. JavaとC#でのEnumの比較
   　2.2. 後発言語、PHPでの扱い
3. ネイティブでEnumを持たない言語のアプローチ比較
   　3.1. TypeScriptでのEnumの工夫
   　3.2. Ruby on RailsでのEnumの使われ方
4. 全体への洞察
   　4.1. Enumの役割を改めて見直す
   　　4.1.1. 多値の表現力、振る舞いのカプセル化、永続化やリファクタリングといった観点からそれぞれのEnumについてまとめ直します
   　4.2. 言語の思想への考察

Enumは「クラス」か「定数」か？

まず、JavaとC#という兄弟のような言語におけるEnumの根本的な違いを明確にします。

JavaのEnumはEnum定数がフィールドとコンストラクタを持つ「クラスインスタンス」です。これにより状態と振る舞いをカプセル化し、ポリモーフィズムを実現する設計哲学を解説します。

C#のEnumは「名前付きの整数定数」として扱います。拡張メソッドや[Flags]属性による実用的な拡張に焦点を当てます。

そして後発のPHPのEnumはJavaのメソッドとC#のバッキング値の良いところを取り入れ、特にDB連携を意識したモダンな設計になっている点を紹介します。

ネイティブでEnumを持たない言語のアプローチ比較

ネイティブでEnumを持たない言語が、いかにしてこの概念を取り込んだかを探ります。

TypeScriptのEnumは開発時の型安全性と、それがJavaScriptにトランスパイルされた際の挙動の危うさ（数値の型安全性の問題など）を示します。最近のJavaScriptへのネイティブEnum導入に関するTC39の議論にも触れ、この機能の未来を予測します。

一方、Ruby on Railsのenumは言語本体ではなく、フレームワーク（Rails）の機能としてDB連携に特化することで、生産性と利便性を極限まで高めたアプローチを考察します。静的型付けの世界では見られない、Rails特有の「規約の力」を強調します。

全体への洞察

最後に、これらの比較を通して得られる重要な知見を共有します。

多値の表現力としてJavaの複数のフィールド vs PHPの単一のバッキング値 vs TSの柔軟性。
振る舞いのカプセル化としてEnum自身にロジックを持たせるべきか、外側でswitchで分岐すべきか。
永続化とリファクタリングとしてDBに依存するRailsのenumと、依存しないJava/C#のEnum、どちらが長期的な保守性に優れるのか。
など、Enumを基準として各言語ごとにどのように「列挙型」と向き合っていくべきかを示します。

このセッションは、単なる機能紹介に留まらず、あなたの日常的なコーディングにおける「良い設計とは何か」「型安全性とは何か」という問いに、複数の視点から答えを与えます。他言語のEnumを知ることで、あなたのメイン言語のEnumが持つ強みと制約を再認識し、より深く、より保守性の高いコードを書くための新たな視点と熱意を持ち帰ってください。

Webの縦書きについてご紹介します。

Webで縦書きをすることの意義について私が考えていること、
縦書きと横書きでは様々なことが異なっていて、ただ向きを変えるだけではないこと、
Webで縦書きを実現する現行の技術にはどのようなものがあるか、
縦書きを中心にしたWebサイトを構築しようとするとぶつかる困難と現状、
縦書きを取り巻く周辺状況、
をご紹介します。

Webの世界で縦書きができることと、それはとても日本語を扱う者にとってうれしいことであること、
そしてそれは日本語だけでなく、Webの世界にとっても、よいことなのだ、という主張をします。

Webフロントエンド領域に習熟する必要はなく、少しCSSの専門的な話をすることはありますが、すべて理解に十分な解説を付けます。

テーマ

例外とResult型の解説、エラーハンドリング設計

想定する参加者層

例外処理やエラーハンドリングについて関心がある初級〜中級の開発者

トーク概要

例外処理は、単なるコード上の仕組みではなく “失敗とどう向き合うか” を決める設計上の意思決定です。
エラー対応が「起きた後の対処」だけに偏ると、再発と手戻りは減りません。

Result型は、失敗の可能性を型で表し、例外に頼らずエラーを設計する手法です。
これにより、エラーの種類や処理責任が明確になり、設計の一貫性を保ちながら保守性を高められます。

本セッションでは、例外（try-catch）を用いる言語のプロジェクトにResult型を取り入れる設計方法を紹介します。
実務での知見を踏まえ、例外の扱いをより明確にし、エラー処理を改善するためのヒントと指針をお持ち帰りください！

Javaで外部デバイスを直接制御する―
かつてそれは、JNI（Java Native Interface）による煩雑な連携とJVM外でのメモリ管理が必要で、できれば避けて通りたい領域でした。
しかし、Java 22で正式に導入されたFFM API（Foreign Function & Memory API） によって状況は大きく変わりました。

FFM APIは、Javaからネイティブ関数や外部メモリを安全かつ効率的に扱うための新しい標準APIです。
MemorySegmentやLinkerといった抽象化を通じて、JNIのようなヘッダ生成やネイティブラッパー無しで、Cの関数ポインタや構造体を安全に操作できます。
JDK標準として提供されるため、追加ライブラリに依存せずポータブルなコードを書くことが可能です。
本セッションでは、FFM APIを活用して Cライブラリやデバイス制御をJavaから安全かつ簡潔に扱う方法 を解説します。
簡単な電子工作を題材に、JNIとの違い、FFM APIの基本的な構造、メモリ管理モデル、そして実際のコード例を交えながら、Javaがネイティブの世界とどう橋渡しできるのかを紹介します。

想定する参加者層

Javaの最新動向に興味があって、Javaでいろんなことがしてみたい人。
電子回路は最低限しか扱わないので電子工作未経験でも大丈夫です。

テーマ

Javaもどんどん進化してるということを見てもらいたい

AIと共創する時代に、プラットフォームをどう設計すべきか？

AIやAIエージェントが開発のパートナーとなったAgentic AIの時代には、「生成AI／エージェントとのコラボレーションを支えるプラットフォームづくり」が欠かせません。
開発者が創造性を発揮できる「自由」を確保しながら、AIが扱う膨大な開発データや知識をどう「統制」するか。プラットフォームの自由と統制のバランスを見失うと、生産性の低下だけでなく、情報漏洩やシャドーAIのリスクにもつながります。
開発者が創造性を発揮できる「自由」を確保しながら、AIが扱う膨大な開発データや知識をどう「統制」するか。そのバランスを見失うと、生産性の低下だけでなく、情報漏洩やシャドーAIのリスクにもつながります。Agentic AI時代においては、プロンプトエンジニアリングを超えて、AIのコンテキストとなるデータをどう整備し、プラットフォーム全体をどう設計するか――つまり、AIが“理解しやすい環境”そのものを構築することが必要です。

本セッションでは、Platform Engineering と Context Engineering をひとつなぎで捉え、AIのパフォーマンスを最大化するための開発基盤設計と、プラットフォームにおける最適なデータマネジメントを探ります。また、機密データの漏洩、モデル汚染、プロンプトインジェクションなどの「生成AI時代ならではのプラットフォームに対する脅威」にどのように備えるか、ガードレールとしてのDevSecOpsやポリシー設計の観点から、「ゴールデンパスとしての自由」「統制しすぎないガバナンス」「AIとの安全なコラボレーション」を実現するためのプラクティスを、具体的なアーキテクチャや事例を交えてご紹介します。

Agileがクライアントと開発者の協調に挑んだように、DevOpsがDevとOpsのコラボレーションを追求したように、
Agentic AI時代は、人とAIのコラボレーションのためのエンジニアリングをどのように実現するかが問われています。
人と人、AIと人とのコラボレーションについてinsightを得たい方、AI-readyな開発プラットフォームの構築/運用に興味がある方はぜひご参加ください！

■対象レベル
中〜上級

■想定する参加者

• 開発プラットフォームの構築・運用に関わるプラットフォームエンジニア、DevOpsエンジニア、SREの方
• 生成AI／AIエージェントの活用や導入を検討しているエンジニア・アーキテクト
• 開発生産性や開発体験（DX）の向上とセキュリティの両立に関心がある方

■必要な前提知識

• GitHub や GitLab などの開発プラットフォームに関する基本的な理解
• 生成AIを活用した開発やプロンプトエンジニアリングに関する基礎知識
• 開発生産性や開発体験（DX）の向上とセキュリティの両立に関心がある方

PHPのコミッターをしています。
主にUnicode周り(intl、grapheme関数)、レガシー文字エンコーディング周り(mbstring)のメンテナンスを行っています。

最近、PHPでgrapheme関数という、Unicodeで言う拡張書記素クラスター（以下、書記素クラスター）に対応した関数を作成しています。
RubyでString.grapheme_clustersの性質を持ったgrapheme_str_split関数、
書記素クラスター単位で2文字列間のレーベンシュタイン距離を測るgrapheme_levenshtein関数などを作ってきました。

JavaScriptでIntl.Segmenterのようなものもアイデアとしてありますが、
他言語での書記素クラスターの対応はどうなっているのでしょうというのを伺いたいと思い、本プロポーザルに応募いたします。

想定する参加者としましては、Unicodeで文字が読み書きできるのであればどなたでもよく、
またPHPを使っている方でも、そうでない方でも歓迎します。
ただし、レーベンシュタイン距離と言ったように、少し技術的に難しかったり、Unicodeについてマニアックな内容も含まれているかと思われます。

テーマ

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

• スマホ/衛星直接通信（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の開発とフィールドテストから得られた通信特性、スマホアプリ開発上の注意点、周辺地形に関して考慮すべき点を紹介します。
おすすめのテストスポットと、その探し方も紹介できれば、と考えております。