トーク

テーマ

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

テーマ: 文字コード、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翻訳の世界を一緒に覗いてみましょう！