トーク

テーマ

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

【テーマ】

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分後、きっとあなたの ”推しランタイム” が見つかりますよ

テーマ

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

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

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

トーク概要

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

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

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

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

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

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

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

VS Codeのオープンな文化と、IBMが推進するエンタープライズ開発者体験(DX)。その交差点には、"ギーク的思考"と"企業的スケール"を融合する挑戦があります。本セッションでは、今日現在、IBMが早期アクセス提供中のIBM Bob （オープンソース版のVS Code互換のIDE） 概要や、IBM、Red Hat、HashiCorpが提供する拡張機能を用いたコンテナアプリ開発デモ実演を交えてお届けします。

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

・想定する参加者層

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

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

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

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

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

テーマ

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の専門的な話をすることはありますが、すべて理解に十分な解説を付けます。

■概要
生成AIの台頭により、GitHub Copilot（GHCP）の企業活用が急増しています。Copilotをセキュアかつ組織統制下で活かすには、その基盤となる GitHub Enterprise Cloud（GHEC）の整備が実質的に必須です。
現場では「試用 → 本番」や「通常アカウント → EMU（Enterprise Managed Users）」への段階移行が増加中。本セッションでは、実案件およびコミュニティでの知見（※GitHub Stars受賞者としての最新動向も踏まえ）から、GEI / GitHub Migration Analyzer / gh-repo-stats等の実運用ノウハウを整理します。
“移せる／移せない”の線引き、ガバナンスを崩さないCopilot活用の判断軸、スモールスタートの実例まで、明日から使えるチェックリストとともに解説します。

■こんな人におすすめ
・企業内でGitHub導入・統合・再編をリードするDevOps／プラットフォーム担当
・既存GitHub資産を落とさず移行したい技術責任者・PM
・Copilot導入を見据え、まず基盤とガバナンスを整えたい方

■前提知識
・GitHub Enterpriseの基本概念（Org／Repo／Teams／Policies）の基礎理解（薄くでOK）
・IaCやCI/CDの一般知識があると理解が早い（なくても可）

■持ち帰れること
・「計画 → 解析 → 検証 → 本番」の実務フレーム＆チェックリスト
・GEI／Migration Analyzer／gh-repo-statsの使いどころと限界
・“移せないもの”の代表例と代替策（再作成・自動化・割り切りの判断）
・EMU移行時のセキュリティ／ガバナンス観点（ID、監査、ポリシー）の勘所

■発表者プロフィール（短）
外資系コンサルのDevOpsエンジニア／マネージャー。GitHub Stars。GitHub Enterprise／EMUの導入・統合・運用、Copilot展開、監査ログ連携やセキュリティ統制の実装支援に従事。

テーマ

例外と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には課金か大きいモデルを動かせるハードウェアが必要です。毎日何万回も出すコンパイルエラーをそのたびに課金していたら破産してしまいますね。大きいモデルを動かす環境を用意するのも大変です。
そこで、小さいサイズのLLMをファインチューンして、コンパイルエラー説明専用のLLMを作れば、手元のパソコンでいくらでもコンパイルエラーを説明してくれるはずです。
ファインチューンにはデータセットが必要です。しかし元気にコンパイルエラーを説明するデータセットなんかありません。
このセッションでは、そんなファインチューンのためのデータセットの作成やファインチューンの方法を解説します。

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

テーマ: 文字コード、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以外のマルチバイトエンコーディングのコードをどうにかしたいと考えている開発者の参考になれば幸いです。

「暗号化って難しそう...」そんな方でも大丈夫！GoでECC（楕円曲線暗号）を簡単に実装してみましょう。
RSAより軽くて速いECCを、Goの標準ライブラリでサクッと実装。
鍵を作って、署名して、検証する。

たったこれだけで暗号化の世界に足を踏み入れられます。

• テーマ：Go言語によるECC（楕円曲線暗号）の実装と理解
• 想定層：Goでの実装経験がある初級〜中級者。暗号理論の知識は不要。
• 狙い：ECCを難解な理論でなく、コード実行を通じて直感的に理解してもらう。

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

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

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

テーマ

Webアプリケーションにおけるファイルアップロード機能のセキュリティリスクと、実装時に考慮すべきベストプラクティスを解説します。

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

初心者〜中級者のエンジニア

• 基本的なWebアプリケーション開発の経験がある方
• ファイルアップロード機能を実装したことがある、またはこれから実装予定の方

トーク概要

CSV一括登録、プロフィール画像の登録、動画音声ファイルのアップロード――これらは多くのWebサービスに不可欠な機能ですが、その実装、本当に安全ですか？

「拡張子をチェックしているから大丈夫」

「Content-Typeを見てるから大丈夫」

こんな風に思っていませんか？実は、それだけでは不十分かもしれません。

本セッションでは、以下の4つのステップで当たり前の機能の裏に潜むセキュリティリスクを解説。ファイルを介した深刻な攻撃手法を具体的に示し、安易な対策では防げない見落とされがちなポイントと、いますぐ導入できる具体的な防御策をお伝えします。

1. 実際に動く「危険なコード」のデモ

2. ファイルアップロードに潜む主な脆弱性

3. セキュアな実装のベストプラクティス

4. 実装チェックリスト

このLTを通じて、ファイルアップロードの「危険性」に対する意識が変わり、皆さんのコードのレベルを引きあげることができるはずです。

もう「拡張子をチェックしたから大丈夫」とは言わないはず。

安心・安全なサービス開発を、共に実現しましょう！

テーマ

Webに関する様々な情報がまとめられている MDN Web Docs に、日本語翻訳で貢献する方法を紹介します。OSSコントリビューションの第一歩として、翻訳を通じてWebの知識を広める活動を取り上げます。

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

GitやGitHubの基本操作（git pull / commit / push）を理解しており、Node.jsの環境が整っている初級〜中級レベルのWebエンジニアを想定しています。
OSSへの貢献に興味がある方、英語のドキュメント翻訳に挑戦してみたい方も歓迎です。

トーク概要

Webアプリケーション開発者であれば、一度は見たことがある MDN Web Docs。
この膨大なドキュメントの多くは、世界中の開発者コミュニティによって日々翻訳・更新されています。

本セッションでは、MDN Web Docs 日本語翻訳コミュニティのガイドラインに沿って、誰でも簡単に翻訳に参加できるプロセスを、初心者の立場からわかりやすく紹介します。
環境構築から翻訳の反映までの流れ、貢献時のポイント、そして実際に翻訳して感じた「MDN翻訳の面白さ」や「学び」を共有します。

英語が得意でなくても、翻訳活動は技術理解を深め、世界中のエンジニアとつながるきっかけになります。
OSSに関わる最初の一歩として、MDN翻訳の世界を一緒に覗いてみましょう！

TechTrainでCSとして働く中で、エンジニアとのやり取りやGitHubの読み込みを通じて、その魅力を言語化してきました。
多方面でエンジニアの推し活を続けるうちに、いつの間にかDevRelと呼ばれる役割を担うようになっていました。

本トークでは、技術者出身ではない私から見えたエンジニアとの関わり方をお話しします。
本トークを通して、私が関わっているTechTrainにも、少しでも興味を持っていただけたら嬉しいです。