本セッションでは、iPhone のマイナンバーカードを使った本人確認の機能について、Verifier における技術的な観点や開発経緯などをお話しします。
先日、メルカリアプリの本人確認で iPhone のマイナンバーカードが使えるようになる機能がリリースされました。
「iPhoneのマイナンバーカード」は、 iPhone （Apple ウォレット） に入れて利用できるマイナンバーカードであり、2025 年 6 月 24 日にデジタル庁および Apple によってリリースされた新しい仕組みです。本機能は、Verify With Wallet API 経由で Apple ウォレットに登録されたマイナンバーカードに含まれる情報を取得および検証することで実現しています。
ここでは、Verify with Wallet API 経由で取得したデータを扱う Verifier の観点で、実際にサービスに導入する際に考慮したポイントを技術的な面などから共有できればと思います。

Markdown記法で記述された文書は、GitHubやQiita、そしてこのforteeなど我々がよく利用するサービスで数多く見つけることができます。さらに最近では、AIからのテキスト出力もMarkdown形式であることが多く、馴染み深い方も多いでしょう。

しかしAIからの出力の中には、たまに強調表示に失敗し、 「おや？」と思うことってありませんか？
我々は単にアスタリスクで囲われた内部を強調して欲しいだけなのに、どうしてそんな一見シンプルな処理に失敗することがあるのでしょうか。
この身近な問い（Q）を解くためには、Markdownの原点に遡らなければなりません。2004年に公開された最初のMarkdownは、一つのPerlスクリプトでした。本トークは、強調表示の失敗という身近な問題をきっかけとして、この"旧"Markdown（Markdown.pl）まで遡ります。

まず、なぜ単純に見える強調表示に失敗しうるのか、Markdown記法の標準化プロジェクトであるCommonMarkの強調ルールとともに解説します。次に、原点であるMarkdown.pl、Markdownの普及と相互運用性という課題、CommonMarkの始まりと強調表示の仕様策定経緯に触れ、この問題に至るまでの歴史を紐解きます。さらに、現状のコミュニティでの議論と、正しく強調表示するために我々が採りうる手段についても共有します。
加えて、日本語の改行（soft line break）問題やルビ表記といった、日本語固有の他の課題にも焦点を当てる予定です。

このトークを通じて、普段何気なく使っているMarkdownの現在地を、その歴史から日本語という観点で再確認し、より快適な日本語ドキュメンテーションへの道筋を皆さんと共有します。

概要

自由にアクセスできるHTTPサーバに対して、クライアントが自らの身の証を立てるのは難しいものです。IPアドレスは完全ではないですし、User-Agentヘッダはなりすましが容易です。

この問題を解決するため、10年以上の議論を経て去年勧告されたのがHTTP Message Signatures(RFC9421)です。

このセッションでは、本仕様をPerlで実装した経験を基に、実例を交えつつ本仕様を概説します。

また、本仕様の理解に必要で、今後生まれるHTTP仕様の理解の前提になることがが想定される、Structured Field Values for HTTP(RFC 9651)についても触れます。

想定聴衆

• AIボット、クロウラーなど、機械的に不特定多数のサーバにアクセスするクライアントを作成したい方
• 逆に、このようなクライアントからのアクセスを識別したいサーバ管理者の方

正規表現はPerlや多くの言語で重要な機能です。
しかし、正規表現は独特の文法から、自分の手で書くのは煩わしいです。
生成AIに書かせることもできますが、本当に期待しているものになっているのかという保証がありませんし、ReDoSなどの脆弱性を生んでしまう可能性もあります。

「正規表現をつくる」プログラム

そこで、「マッチしてほしい文字列」と「マッチしてほしくない文字列」を与えたら自動で、*や+を使ったいい感じの正規表現を作ってくれるプログラムがあったら便利だと思いませんか？
今回は、そういった「正規表現をつくる」プログラムについて話します。

オートマトンと正規表現のはざまで

「正規表現をつくる」プログラムといえば、PerlにはRegexp::Assembleがあります。
ですが、Regexp::Assembleでは単にマッチしてほしい文字列を|でつないだ正規表現のようなものが出てくるだけで、*や+を使った期待する正規表現にはなりません。

期待する正規表現についてはオートマトンを使うことで定義できます。
一方、オートマトンから人間の読みやすい正規表現を得ることは簡単ではありません。
この問題の解決ために、SATソルバなどを使って解決を試みます。

むすびに

この発表では、次のような内容を話します。

• 「正規表現をつくる」問題について
  • いい感じの正規表現とは何か？
• オートマトンの場合の解決方法
  • 受動的オートマトン学習
  • RPNIアルゴリズム
• 正規表現として求めるには？
  • 正規表現への変換の困難さ
  • SATソルバを使った探索

「正規表現をつくる」問題を、理論的な方法を用いながらも現実的に対処していくトークにご期待ください。

現在HTTP Cacheに関するRFCは7234...ではありません。
2022年に改訂され、RFC「9」111 HTTP CachingとしてInternet Standardになっています。

本発表ではRFC9111、特に共有キャッシュについて見ていきます。
プロキシサーバのアップストリームに位置するWebアプリケーションとしてどうすればキャッシュをしてくれるのか、もしくは拒否できるのか。
理解すれば、実装にはよりますが少なくともRFCに沿った議論ができるようになります。
発表者はRFC9111に沿ったキャッシュミドルウェアを実装しています。
https://github.com/2manymws/rc
この実装経験に基づいた紹介をします。
（なお、2025年8月現在rfc9111で検索して出てくるのは我々のリポジトリを含めて5つ https://github.com/search?q=rfc9111&type=repositories ）

この機会に「RFC9111完全に理解した」になりましょう！

• とある デジタル庁におけるガバメントクラウド整備のためのクラウドサービスの提供（令和5年度募集） にはこんな調達仕様書がついています。
  • DBのバックアップを差分で取得できること。取得したバックアップはいつでもDBの復元に使用できること。復元時は別のサイズを選択できること。
  • DBのバックアップは、一定期間（例：5分）以前のどの時点にでも戻せるかたちで（Point In Timer Restore）取得できること。
  • DBのバックアップは、予め設定したタイミング、周期、世代で自動的に定期実行できること。
  • DBのバックアップイメージは、CSPの中であれば、別のシステム、別のネットワーク、別の環境からも利用できること。

RDBMS as a Serviceでは当たり前に提供されてきたこの機能を、もし自分たちで提供しないといけないとしたら、今この2025年ではどんなツールを使うのが良さそうなのか。

• mysqldump ..?
• Percona XtraBackupってどうなったのだろう？
• MySQL Shellでもバックアップは取れるらしいが本当に使えるの？
• Cloneプラグインでリモートバックアップが取れるって本当？
• 5分以前のどの時点でも戻せるかたちで取得ってどうする？
  試行錯誤してたどり着いたバックアップの取り方をお話しします。

大規模なプロダクトでは、lintや、use漏れチェック、使ってないファイルの検出といった、静的解析を伴う開発支援ツールが重宝されます。
しかし、存在するすべての記法を扱う必要のある汎用ツールでは、どうしても実行時間が伸びてしまったり、プロジェクト固有のかゆいところに手が届きにくかったり、といった課題がつきものです。
発表者が携わる、開発期間約10年・数十万行規模のリポジトリでは、近年注目されている"vibe coding"の考えを下敷きに、プロジェクト専用の軽量なツールを開発して、開発支援に活用しています。
本発表では、プロジェクト固有の静的解析ツールをAIとともに開発し、レガシーコード改善に活用する「バイブス静的解析」を提唱します。

静的解析を用いたツールのこれまで

• PPI, PPRを使った汎用ツールのおさらい
• 汎用的がゆえに、いかなるソースコードも正しく解釈しなければならない宿命
• ツールの実行時間増加への利用者側の工夫

バイブス静的解析のアプローチ

• プロジェクトに合わせた専用の静的解析ツールを「バイブス」重視、すなわち、勢いで開発する
• 完璧を目指さず、コードベース上で必要な表現だけに対応する
• AIの力を借りて、誰でも保守でき、壊れても機能開発の片手間に短時間で直せるものを目指す

ゴール

• 「バイブス静的解析」の考えを使って、新たなツールを勢い重視で開発できるようになる
• お手元のリポジトリから、数秒以内にuse漏れや不要ファイルといったエラーを検出できるようになる

DNS Full ResolverはIDCやISPなど多くの環境で構築/運用されています。
Office NetworkやIDC内での利用ではあまり問題にはなりませんが、ISPやさらに大きいスケールでの運用では問題が発生する事があります。
このセッションでは、小規模から中規模でどのような運用パターンが実施されているのかを解説し、また、大規模な環境ではどのようにDNS Full Resolverをスケーリングさせているのかについてまず解説します。
その後、さらに巨大なPublic DNSのようなHyper-Scalerは巨大なDNS Full Resolverをどのように構築しているのかを、PublicなDocumentから分かる範囲で調査した内容を解説します。
また、Hyper-Scalerが実際に行って居るDNS Full Resolverをどのように実装するのかの簡単なPoCを実装し解説します。
DNSという長く開発、運用されているシステムを調査/開発する楽しさを共有します。

およそ事業運営では「汲」めども尽きぬ問題・課題に立ち向かわなければなりませんが、セキュリティにおいても同様でしょう。

GMOペパボのセキュリティ対策室は、過去のインシデント再発防止を契機として設立された組織であり、私 @hiboma は当初から技術職上位等級としてコミットしてきました。 「急」な対応を要するセキュリティイベントは尽きることがありません。脆弱性の対応、不審なアラート通知、脅威の検出、障害・ヒヤリハット・セキュリティインシデントの発生 ... と何かが起きる度に「窮」する思いで立ち向かっています。

実施してきた対策を上げればきりがなく、基盤技術の導入、組織体制・規定・ガイドライン・プロセスの整備、インシデント対応の支援自動化、シフトレフト・DevSecOps の実践、Web セキュリティ・クラウドセキュリティ・エンドポイントセキュリティ, Security for AI / AI for Security ... 未だ課題が山積みです。

ある時は 「やっていき」（リーダーシップ）を発揮して、また、ある時は同僚に「のっていき」（フォロワーシップ）しながら、セキュリティの実践を 「ふつう」にやっていく 技術・体制・文化の追求についてトークします。

皆さんもクレジットカードを使った際に、身に覚えのない決済が来て、不正に利用されてしまっていたという経験があるのではないでしょうか？
不正といっても、クレジットマスターアタック、スキミングといった外部からの攻撃、カード所有者による悪意のある決済など、多岐に渡り不正決済は年々増加しています。

本トークではカード事業者が不正を防止するために日々行っている攻撃の検知、分析、対策、評価といった一連の運用やそれらを支えるシステムの開発をどのように行っているかを技術的な文脈を元にお話しします。

具体的には以下のような内容をお話しする予定です。

• カード決済における代表的な攻撃とそのパターン検知、および対策をどうやっているか
• 不正決済を検知し防止、抑制するためのシステムをどのように構築しているか
• 不正対策を行っているチームの日常、どのようなKPIを設定して攻撃の予防や改善を行なっているか

本トークを聞くことで、皆さんのカード決済が安心に行えている一旦が垣間見れるかもしれません。

コードを読んでいると、この変数はどこで定義され、どこで値が設定されたのか？を確認することがしばしばあります。
再代入が多いとどのタイミングで値が変更されるのか？を確認するコストが発生するので、私はめんどうだと思ってしまいます。
また、再代入がないほうがメンテナンス性が高いと信じています。なぜならば、すべてが再代入なし（= すべてが定数）の方がバグが生まれにくいはずだからです。
（いわゆる関数型プログラミング、というやつです。）

と、いうことで私は基本的に再代入をしないコードを書くように心がけています。
（もちろん、それによるデメリットがあるのも承知でそのようにしています。）

私が始めたOSSではありませんが、現在は9割方私が書いたコードになっているnode-lambda ( https://github.com/motdotla/node-lambda ) （JavaScriptです）を例に、頑なに再代入をしない（関数型プログラミング）を実践した例を紹介します。
（これまではデメリットについて、厳密に検証したことがなかったのですが、改めて検証してまとめてデメリットについても発表します。）

大規模開発の参考になること間違いなし！

ここ数年、来るべきクッキーレス時代に備え、デジタルマーケティング分野に関わるエンジニア達は人知れず戦ってきました。現役の広告エンジニアである筆者もその最前線に身を投じた一人です。しかし、 2025 年 4 月、 Google は 3rd party cookie の廃止を事実上断念し、その壮大な挑戦は突如として大きな転換点を迎えます。

このトークは、その激動の渦中に生まれた Attribution Reporting API (ARA) という技術へ捧げる、筆者からの鎮魂歌です。

ARAは、プライバシーを守るという理想が生んだ、あまりにも複雑で難解な人工遺物です。しかし、その複雑さの奥には、最先端の Google エンジニア達による知恵と格闘の跡が刻まれています。このトークでは、2024 年 1 月のプロジェクト発足以来 1 年以上 Attribution Reporting API (ARA) の実装に携わった筆者が、 ARA の仕様を読み解くために必要な知識を短時間で効率よく収集することを目標に、以下のキーワードを解説します。

• Attribution Reporting API (ARA)
• registration
• attribution source/trigger
• source type event/navigation
• event-level/aggregatable&summary report
• Publishser / Advertiser / Adtech / Browser
• contribution budget
• ノイズと差分プライバシー
• Aggregation Service と TEE

本当です。そしてこの事は、2025年現代のプログラミング環境において意外で根強い影響をあちこちに及ぼしています。本Talkではその証拠を提示した上で、なぜそうだったのか、その結果どうなったかを論じます。

• 証拠 - Proof
  • 語彙 - Vocaburary
  • "use strict";
• 理由 - Reason
  • Y'all can pop it. but can you shift it?
• 影響 - Consequence
  • typeof null === "object"
  • "🐫".length !== ["🐫"].length
• 結論 - Conclusion
  • Why Javascript matters -- and Perl doesn't (so much)
  • It sucks? Then why are you suckin' it?
  • Q&A

35歳になる目前、私はそれまで当たり前のように身を置いていたプロダクト開発の現場から離れ、人事担当として急転身しました。
エンジニアにとって、近いようで遠い存在である人事。果たして、お互いのことをどれくらい理解しているのでしょうか？
エンジニアから見た人事、人事から見たエンジニア。両方を経験したからこそ分かる、お互いの誤解と理解。人事の日常業務のリアル、エンジニア組織への貢献の仕方、そして技術者と人事の間に橋を架ける意味について、転身してからの4年間の体験をもとにお話しします。

アウトライン

• 「コードを書かない」決断と「急」転身の理由
  • EMキャリアから「またコードを書く？」に対する違和感
  • 技術者アイデンティティ・クライシス
• 両方やったからこそ見えた世界
  • エンジニア時代に持っていた人事への誤解
    • 「人事って面接だけやってるんでしょ？」
    • 「技術のことなんて分からないでしょ？」
• 人事になって分かった人事の世界
  • 実際の日常業務とその深さ
  • 組織課題解決への真剣な取り組み
  • HR業界のプロフェッショナリズムとは
• 技術者出身だからできること
  • エンジニアとの信頼関係構築
  • 技術組織の課題理解と解決への貢献
  • 両方の言葉で話せることの価値
• 4年経った今の率直な感想と学び
  • コミュニティとの新しい関わり方
  • 「技術者 vs 人事」ではなく「技術者 & 人事」という視点
• 橋を架ける意味
  • 技術者のキャリアパスの多様性
  • 組織をより良くするための協働の可能性

聴衆が得られるアウトカム

• 人事という職種への理解
• キャリアチェンジの現実的な体験談
• 技術者と人事の協働の可能性

Web サイトの JavaScript や CSS はブラウザから閲覧できます。従ってそれらに機密情報が入らないよう、細心の注意を払わなければなりません。なになに? 「minify してるから大丈夫。」「モダンなフレームワーク使ってるから大丈夫。」...だって? 本当にそうですか?

機密情報の漏洩を招くポイントは、様々な場所に潜んでいます。このトークでは、一般的なWebフロントエンド開発で意識すべき漏洩ポイント、そしてその対策についてお話します。

• Source Map 経由での漏洩
• Client Component 経由での漏洩
• Next.js Pages Router の _buildManifest.json
• その他注意すべき漏洩ポイント
• 漏洩の確認方法
• 漏洩を防ぐには