本セッションでは、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完全に理解した」になりましょう！

deckはk1LoWさんが開発された、MarkdownからGoogleスライドを継続的に作成するための非常に優れたOSSであり、Goで書かれています。

筆者は、7月からこのツールを使い始めると同時に、その後の数ヶ月で多くの改善提案及びpull requestを行いました。コード行数にすると1万行以上に及びます。最終的にはコア開発者にも加えてもらいました。

deckを使いやすくするための数多くの変更をおこないましたが、中でも特筆すべきはそのパフォーマンス向上でしょう。10分以上かかっていたスライド生成が10秒以内で完了するようになったケースもあり、実に100倍以上の高速化を達成しています。

これらは、良く言われる「計測」で達成できた部分もありますが、実際にはTidy First的に仕様やコードの整理整頓をする中で自然と速くなったもの、その過程で高速化のアイデアが湧いて実現できた物も少なくありません。その過程で作者のk1LoWさんとも議論を重ねることもありました。それらの段階的な改善が、結果的に劇的なパフォーマンス向上に繋がったのです。

本トークでは、実際のdeckの高速化の旅路を具体的事例にとり、OSSやソフトウェア開発におけるパフォーマンスチューニングの秘訣についてお話します。

YAPC::Japanがリブートした2016年当時、Terraformはまだv0.7の段階で、インポート、Data Sources、ステート管理CLIといった機能が実装されました。

あれから9年、Terraformはv1.12となり、ツールとして成熟しました。モジュール機能も2014年のv0.3から実装されています。

しかし、Terraformでモジュール化を進めると、様々な「辛さ」に直面し、時に「窮」地に陥ります。大量のパラメータ、どんなリソースが作られるか分からない不安、細部を制御できないもどかしさ、モジュールの多層化による見通しの悪さ——これらは単なる実装の問題ではなく、インフラコードとアプリケーションコードの本質的な違いから生まれる必然的な課題です。

なぜこのような辛さが生まれるのでしょうか？本セッションでは、両者の根本的な違いである「記述の視点」から出発し、そこから必然的に生まれるモジュール化アプローチの違いを紐解いていきます。

根本的な違い

• 記述の視点：状態を記述する vs 処理を記述する

この違いから生まれるモジュール化の特徴

• 抽象化の目的：構成のテンプレート化 vs 処理のカプセル化
• 再利用の考え方：ホワイトボックス的利用 vs ブラックボックス的利用
• 設計の難しさ：抽象化と可視性の板挟み vs 抽象化に専念できる
• 階層化の影響：モジュールの多層化による透明性の低下 vs 階層化による整理

これらの違いを理解することで、インフラコードのモジュール化が難しい本質的な理由と、その難しさとどう向き合うべきかを考察します。

想定する聴衆

• インフラエンジニア、SRE
• インフラにも関わるアプリケーション開発者

話者が所属する組織ではプリペイドカードを用いた決済機能とそれに付随した家計簿アプリを開発しているのですが、そこでは日々膨大な量の「名前」と格闘しています。カードの決済店舗名、家計簿の支出名、レシートからの店舗名や費目名などなど……これら名前が各々何であるのかを機械が理解できるようにするにはどうすれば良いでしょうか。
例えば「セブンイレブン」という名前を見た時、人間はそれが「コンビニ」の名前であることを一目で理解できますが、未学習の計算機にこれをやらせるのは困難です。ではどうするかというとパッと思いつくのは計算機に推論させるという方法があります。昨今の大規模言語モデルであれば例に挙げたようなタスクはこなせる可能性がある一方、現状ではコストが高くなりがちという問題もあります。そもそも人間に判断が付かないものは機械にとっても難しいものです。仮に「たんぽぽ」という店舗名を見た時、これがどんな種類の店であるかを自信を持って回答できるでしょうか？　人が見ても判然としないものを機械に推論させても有意義なものが出てくるかというと難しいものがあります。
我々はこうした課題を解決するためにマスターデータ（辞書）を地道に作っています。本トークでは自然言語処理の理論・手法を要するものを、プロダクト作りの現場においてどうシステムや良い体験に適用していくかという実践的な話題を取り上げます。主に取り上げる予定の話題を紙幅の都合上以下に箇条書きにします:

• LLM時代ではその知識の源泉となるデータは益々重要
• 推論せずに結果が得られるならば推論する必要は無い
• 何の解決を目的としてデータを作るか
• データが無いところからどう作りはじめると良いのか（一定の根性の話）
• どのように作ったデータを育てるか
• 作ったデータを有効に使う方法
• データを作り、育て、有効活用できるチームをどう構築するか

今年はPerl 5.42のリリースが遅れたこともあり、次期バージョンについての情報はまだほとんどありませんが、現在の安定版である5.42の情報を中心に最近のPerl界隈のニュースなどを紹介します。

私が開発しているAmazon ECSデプロイツール「ecspresso」は、前回福岡で開催されたYAPC::Fukuoka 2017の半年後に誕生しました。8年間にわたって開発を継続した結果、GitHub Stars 950+を獲得し、現在でも国内企業で広く利用されています。本セッションでは、長年個人で開発しているecspressoがECSの新機能追加に急速に追従し続けられる理由と、その設計を探求します。

ecspressoは「AWS SDKをほぼそのまま使う薄いラッパー設計」を採用しています。これは実は怠惰ゆえだったのですが、結果的には新機能に即日対応できる、急速な追従性を実現する要因となりました。実際にEFSマウントやBlue/Greenデプロイメントへの追従は、コード数行の変更で実現されています。一方、TerraformやAWS Copilotなどの他のIaCツールは、独自DSLや抽象度の高いインターフェースを採用し、異なる設計上のトレードオフを選択しています。

2025年7月に開催された「設計ナイト2025」での発表 https://speakerdeck.com/fujiwara3/sekkeinight2025
では、ecspressoの設計思想に至る道のりを振り返りました。そこでは、組織構造と責任分界点がツールの設計に与える影響について語りました。

今回の発表はその続編です。設計思想を実装に落とし込む過程と具体的なコードやエピソードを交えながら、「正しい抽象化」を探求します。「抽象化しない勇気」「制約が生む創造性」「適材適所の設計」など、8年間のメンテナンスから得られた実践的な知見を共有します。

私は2024年の2月からWebKit（実際にはその中のJavaScript処理系であるJavaScriptCore）への貢献を開始し、1年後の2025年2月にレビュワーという最も強い権限を持つメンバーの一人になりました。
そして、2025年8月にはWebKitへの貢献が評価され、それに関連する職を手にいれることができました。

私はこれまで基本的に一人でWebKitへの貢献を行ってきました。
周りに質問できる人が全くいない中、コードベースへの理解はもちろん、独自の開発文化なども身につけながら、コミュニティからの信頼を得られるように努力してきました。

その中で「大規模なOSSに一人で立ち向かう」ためのアプローチが少しずつ見えてきました。

この発表では、WebKitのような大規模かつ技術的に複雑で歴史の長いOSSプロジェクトに一人で立ち向かい、技術的な理解を身につけながらコミュニティからある程度認められるようになるための方法について、なるべく再現性のあるアプローチについてお話しします。

Quineというのは自分自身を出力するプログラムのことで，プログラミングによるアートです。Web上には様々なQuineが公開され，その芸術を競っています。皆さんはそういったQuineを見てQuineとは難しいものだと思われているかもしれません。しかし恐れることはありません。Quineは皆さんと共にあります。ライブコーディング形式でやりますので皆さんもノートPCを持参して一緒に書いてみてください！

この話はもともとYAPC::Kyoto 2020で話す予定でしたが、COVID-19で延期になってしまい、結局Rebootできずお蔵入りになったものです。今回のYAPCのテーマは「きゅう」ということでこの機会にQ(uine)のお話を復活させたいと思います。

普段はPythonやRubyを書いているのですが、Quineは言語はあまり関係ないのでYAPCですしPerlでお話します。

ある日突然、あるサービスに急（きゅう）なスパイクアクセスがやってきました。その数、700並列。サーバーは悲鳴をあげ、DBは沈黙しました。

高負荷対策の定石といえば、キュー (Job Queue) を思い浮かべるかもしれません。しかし、安易にジョブを Queue に入れるだけでは、結局700並列の重い処理が非同期に実行されるだけ。そこから、いかにして本当に必要な処理だけを「間引く」かが本当の課題でした。

こうした処理の間引きには、一般的にスロットル (Throttle) が用いられます。では、なぜその一般的な手法である Throttle ではダメだったのか？ 本トークでは、似て非なる Throttle とデバウンス (Debounce) の違いを解説しつつ、サーバーサイドでの Debounce 実装に至るまでの道のりを赤裸々にお話しします。

単純な実装だったv1から、その改良版であるv2ですら対応できなかった現実の複雑なユースケース、そして最終的にたどり着いた動的な遅延制御ロジック(v3)まで――3度の再実装の過程を、v1からv3へと進化していく実際のコードを追いながら、その思考と共に解説します。

この実例で語る負荷制御の勘所と設計思想が、あなたの武器庫に加わる新たな一つになれば幸いです。

• とある デジタル庁におけるガバメントクラウド整備のためのクラウドサービスの提供（令和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という長く開発、運用されているシステムを調査/開発する楽しさを共有します。

いいか、みんな
　　　　　　　　(ﾟдﾟ )
　　　　　　　　(|　y |)

ハッシュリファレンスと package では手続き型プログラミングしかできないが
　　　　　 {}　 ( ﾟдﾟ)　package
　　　　　　　＼／|　y |＼／

　　　　二つ合わさればOOPとなる
　　　　　　　　( ﾟдﾟ)　 bless
　　　　　　　　(＼／＼／

Perl を初めて触る方を対象とした、1 時間の速習ワークショップです。対象は他の言語に慣れている Web エンジニアを想定しています。

Perl における OOP の歴史や、強力な正規表現、特殊変数の世界など、現代から見る Perl の奇妙さを体験しつつ、現代的な Perl プログラミングまで駆け抜けます。

文法の細部よりも、Perl 独特の仕組みと速習のポイントを凝縮し、短時間で「Perl を読める」「ここに戻ってきたら分かる」という感触を得られる構成です。

はてなサマーインターンシップで使ってきた はてな教科書 を下敷きにしています。

2025年はコーディングエージェントによる自動コーディングが、仕事の現場でも浸透し始めた年であると言えます。

ところでChatGPTが出た2022年末を思い出してください。確かに受け答えは出来るし、このようなコードを書いてという指示を出すと確かにコード片は出せましたが、それを仕事の中でメインで使ったり、ましてや自動で指示をしたら勝手に書いてくことは想像できませんでした。
もちろんLLM自体の進化もありますが、LLMをどのように使えば効果的にタスクを実行できるか、つまり"エージェント"である部分の進化がコーディングする機械としての実用性を向上させたと私は考えます。

このセッションの前半では「エージェントとは何か」をその概念のもととなった論文などをもとに説明します。具体的には以下のような項目です。

• ReAct
• Function Calling

このセッションの後半では、ReActループおよび、Function Callingを備えたコーディングエージェントのライブコーディングを行います。使用する言語はPerlですが、出来るだけ他言語の方でも分かりやすいように解説を多めに述べます。

このセッションに参加した方は以下のものが得られます。

• コーディングエージェントに代表されるAIエージェントの概念の習得
  • LLMとエージェントシステムの境界線の認識
• コーディングエージェントを作成する際に考慮すべきこと
  • コンテキストサイズに収まるファイル読み込み
  • Function Calling
  • ReActループ
• 「コードを書く」とは何なのかを洞察する機会
  • コーディングとはコードをただ書くだけではなく周囲のコードを読んだり、ドキュメントを読むことで成り立っている行為

現在はPerl5.42となったPerlですが、1994年から31年間ずっとPerlはPerl5です。
そのPerlの「きゅう」バージョン、すなわちPerl5前史に目を向けると、1987年にラリー・ウォールによって公開されたPerl1.0が最初のバージョンであることがわかります。

ところで私は今年からRubyの会社に転職しました。Perlで育ってきた私がどのようにRubyを勉強していけばいいのか悩みました。そこで思ったのです。最もかける言語であるPerlをRubyで書いたらすべてが解決するのではないかと———。

このトークではPerl1.0のソースコードを紐解き、Rubyインタプリタによって再実装していきます。

【多分こういう内容】

• Perl1.0のソースコード徹底解説
• AIを使って古いコードを読むテクニック
• StringScanner/Racc入門
• ASTのVM化

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

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

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

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