YAPC::Fukuoka 2025 に参加してきました

日本最大級のPerlカンファレンスであるYAPC::Fukuoka 2025が開催されました。現地で参加してきたのでその雰囲気やセッションの感想などを綴っていきます。

YAPC / YAPC::Fukuokaとは

YAPC はPerlユーザーが集まるコミュニティベースのカンファレンスです。世界各地で開催されており、Perlに関する技術情報だけでなくさまざまな技術分野に関する情報交換の場でもあります。日本のインターネットサービスを支える多くのエンジニアが参加しています。

おおむね1年に1回開催され、過去には函館や広島などで開催されました。ちなみに前身のイベントは YAPC::Asia と呼ばれており、2006年から2015年まで開催されていました。

YAPC::Fukuoka はその名の通りですが福岡の福岡工業大学で開催されました。11/14-11/15の2日間にわたって行われました。

会場は福岡工業大学のキャンパス内にある大講義室や教室が使われ、同時に3トラックのセッションが行われました。会場は広いものの、参加者が多く満員御礼となるセッションも多かったイメージです。

こちらが今回のタイムテーブルです。

メインのセッション以外にも、お馴染みのライトニングトークや、踊り場トークのような飛び込みでトークできるような場もあり多様な形で楽しめるような工夫がされていました。

私と YAPC

久しぶりにYAPCの参加記事を書いたので私とYAPCの歴史を振り返りたいと思います。

私が初めてYAPCに参加したのは、YAPC::Asia 2009でした。東工大の大岡山キャンパスで開催されました。
このような技術カンファレンスに参加するのは初めてで、当時のWebサービスを支えているハッカー達が登壇し、廊下や大学の芝生の上でワイワイ技術について話している姿を見てこんな世界があるのかと感動した覚えがあります。

ちなみにこちらが当時のスケジュールです。

このイベントに参加してから、あのエンジニアの中に入れるようになれたらという思いで日々のエンジニアの仕事に向き合ってきたような気がします。自分のエンジニア観みたいなものを変えたイベントだったなぁと改めて感じました。
まだ当時の皆さんの領域には到達できていませんが、その後も他のYAPCに参加したり、また何度か YAPC や他のイベントでも登壇させていただいたり、少しでもイベントを盛り上げることには貢献できてるのかなぁと思ってます。

次回はYAPC::Asiaスタイルを再現する(意気込み)ということなので今から楽しみですね！

https://x.com/karupanerura/status/1989618369247805940?s=61

参加したセッション

私が聞いた中で特に印象に残ったセッションをいくつか紹介します。

なぜThrottleではなくDebounceだったのか？ 700並列リクエストと戦うサーバーサイド実装のすべて

テストの実行プラットフォームにおける、サーバーサイドでのDebounce実装に関するセッションでした。私はこちらのセッションをベストトークにしました。

サーバーサイドで大量のリクエストを直列的に逐次処理する方法として、ThrottleとDebounceの比較やその実装までの道のりを紹介されていました。複数のサーバーの同期方法としてRedis をロック機構として使い、分散処理を実現するアイデアを採用されていました。

クライアント側のサジェストのような機能の実装でそのようなロジックを使ったことはあるのですが、サーバーサイドの処理制御の仕組みとして活用するというのは斬新でした。またRedisでLuaが実行できることは初めて知りました。

Jenkins の作者である山口さんが上司で、その山口さんのアドバイスでレースコンディションを防ぐことができたり、テストの実行ケースのパターンによってDelayをウィンドウサイズのようなものを活用して動的に変化させたりするなど、実際の運用で得られた知見が盛り込まれており非常に興味深かったです。スライドもわかりやすく図解で説明されていたので必見です。

セッションリンク・スライド

OSS開発者の憂鬱

Hono 開発者である @yusukebe さんからみた大規模 OSS 開発者の体験談です。

ここ4年ほどで急成長したHonoですがその裏でのさまざまな悩みを語られていました。

自分の知らない領域のIssueに対応するために幅広い知識が必要、バグの再現ができない Issue が多い、仕様のWhyを聞かれてモヤモヤする、他のフレームワーク作者から妬まれる、政治的な問題に巻き込まれるなど大規模OSSの開発者だからこそのケースがありました。

私もIssueをあげる時は気をつけようと心に誓いました。。。
同時にメンテナとしてIssueを放置しない、ちゃんとフィードバックに向き合うという姿勢は見習わないといけない点だと思いました。

セッションリンク・スライド

大学における人工知能関連の教育について

福岡工業大学の山澤先生による人工知能教育に関するセッションでした。

福岡工業大学ではAIに関するカルキュラムを以前より導入しており、機械学習やそれに関する数学的な基礎、コンピューターサイエンスの基礎などを教えているということでした。AIに関するカルキュラムモデルがあるというのは初めて知りました。

一方で昨今の生成AIの登場により、学生が生成AIを使って課題を解決するケースが増えてきており、教育現場としてはその利活用に議論があるようでした。

挙げられた例として、C言語を学習したての学生に向けたパックマンのロジックを実装するという課題でした。
2023年以前はサンプルのコードをベースに試行錯誤の形が見えるコードを書く学生が多かったのに対し、2025年現在ではBFSやキューを使ったコードをみかけるそうです。
マトリックスで点数の遷移を表現されて明らかに2025年の点数が高くなっていたのが印象的でした。

一方で生成AIを使わずに課題を解く学生もいるということで、生成AI利用の教育や評価は悩みのポイントということでした。

セッションリンク

HTTP Message Signatures ― HTTPクライアントの身の証を立てる

HTTP のヘッダーに署名を付与する仕組みのRFCについての紹介セッションでした。

クライアントからのリクエストを特定・識別するための手法としてIPアドレスやUser-Agentなどがありますが、これらは偽装が可能であり信頼性に欠けます。HTTP Message Signaturesは、リクエストメッセージにデジタル署名を付与することで、メッセージの完全性と送信元の認証を提供します。この仕組みを RFC 9421 として2023年に標準化されました。

あとで調べてわかりましたが、RFC が出る以前もすでにGitHubなどで独自実装が行われており、GitHub の Webhook の送信元を検証するために使われています。

セッションリンク・スライド

「データ無い！腹立つ！推測する！」から「データ無い！腹立つ！データを作る」へ ― ゼロからデータを作り、チームで育てられるようにするまで

AI がどれだけ進化しても無から何かを生み出すことはできません。扱うデータをどう生み出すかというのは引き続き取り組まなければいけない課題ですが、その知見が詰まったセッションでした。

データの必要性について、データがないことは困らない = データがないと困っていることにすら気づいていないというのは首がもげるくらい同意でした。

後半ではクレジットカードの店舗名のクレンジングの方法が紹介されていました。店舗名はPOSレジの設定として人力で入力されているらしく、「welcia 」が「wekcia」にタイポされているようなケースがあったり、「北電」は北陸電力なのか北海道電力なのかわからないことがあったりするらしいです。超地道な作業を繰り返して品質の高いデータを作っていくことを聞くと、普段使っている家計簿アプリにはもっと敬意を表さないといけないなと心に刻みました。。。

SQLiteに一度データをダンプすることでポータビリティを持たせるという点は普段自分もやっていたりしていて他での事例を知れたのは良かったですね。

セッションリンク・スライド

「バイブス静的解析」でレガシーコードを分析・改善しよう

正規表現と構文木ライブラリのPPIによってデットコードを削除した際の知見が詰まってました。
レガシーコードの分析やデッドコード削除のコンテキストでは、まずは当たりをつけるという用途で厳密な静的解析をしなくても雰囲気で Vibe codingを活用できるという点は共感できました。

「勢いでツールを開発し、冷静にコードを消す」は響いたワードでした。

セッションリンク・スライド

セキュリティを 「ふつう」にやっていく 技術、体制、文化の追求

以前にセキュリティインシデントのあったGMOペパボの取り組みの紹介でした。

ちなみに当時のインシデントの報告がこちらのページに書かれています。

セキュリティを「ふつう」にするためにどのようなプロセス、技術、文化を醸成していったかということをお話しされていました。

セキュリティのオンボーディングトレーニング、セキュアコーディング研修、ガイドラインの作成、SIEMの導入、エンドポイントセキュリティの導入など、私が持っているセキュリティの知識でもどれも全部聞いたことがある内容で正直何か特別な取り組みをされている印象はありませんでした。

ただ、それを実行し根付かせるということがどれだけ難しいかということは身に沁みて感じており、その「ふつう」を当たり前にしていくには大変な苦労があった(る)んだろうなぁと感じることができました。トップが当たり前やっていることは文化になる、という点も共感できました。

セッションリンク・スライド

Other Sessions

他にも私が参加したセッションをリストアップします。

• Perlブートキャンプ by Hatena
  • Perlの基礎から実践的な内容まで体系的にまとまっており、Perlをこれから学ぶ方やざっと復習したい方におすすめのスライドでした。
• なぜインフラコードのモジュール化は難しいのか by mizzy
  • Terraformのモジュール化における課題や、抽象化の難しさについて語られていました。インフラコードを書く際に感じていたモヤモヤが言語化されており、非常に共感できる内容でした。
• AIコーディングの弱点、やっぱりプログラミングは人間が(も)勉強しよう by きしだ なおき
• Agentに至る道 〜なぜLLMは自動でコードを書けるようになったのか〜 by macopy
  • きしだなおきさんのセッションとセットで聞くとAIエージェントの理解が深まるのでおすすめ。
• クレジットカードの不正を防止する技術 by Yuta Horii
  • 不正な取引と言っても決済のカテゴリや決済国、加盟店などなど様々な要素がありそれらを検知する手法も多岐にわたることがわかりました。クレジットカードという普段ブラックボックスな領域の裏側を見れたのは面白かったです。
• 競馬で学ぶ機械学習の基本と実践 by 三谷 昌平
  • ちょうど機械学習の勉強をしていたのでタイムリーでした。競馬データという具体例があったので理解しやすかったです。
• 読む技術・書く技術・伝える技術 - 15年続けて分かった持続可能なオープンソース開発 by azu
  • JSer.info や textlint、JavaScript Primerを運営されているazuさんの登壇でした。それぞれ、読む・書く・伝えるという観点でプロダクト開発や運用をされており想いが伝わってきました。
• ステートレスなLLMでステートフルなAI agentを作る by 藤吾郎 (gfx)
  • Cotomo 開発の試行錯誤が聞けて面白かったです。記憶を残すのにRAGを使うもののあまり確実に覚えているわけではなく一方で記憶は人間も忘れていくという点からバランスを考えるとベターな実装という点は納得感がありました。

まとめ

当日の案内や懇親会など迷うことがなく、このような素晴らしいイベントを開催していただいた運営の方は感謝です。

今度は登壇できるように日々頑張っていきたいと思います！