YAPC::Fukuoka 2025 参加記録

Yet Another Perl Conference

11 月 13、14 日に開催された YAPC::Fukuoka 2025 へ参加しました。 YAPC は “Yet Another Perl Conference” の略で、Perl コミュニティによるカンファレンスイベントです。 Perl を軸としつつ、そこから派生する様々な技術に関するセッションが行われました。

福岡工業大学の門の前にある YAPC の案内板

自分と Perl、YAPC

コピーprint chr(0x1F9F6), "\n"

自分は現在、株式会社はてなでエンジニアアルバイトをしています。 はてなでは複数のプロダクトのバックエンドに Perl を使用しており、自分も業務の開発で Perl を使用することがあります。

Perl を書きはじめたこともあり、以前から知っていた YAPC に参加する良いチャンスだと思い、参加を決めました。 福岡開催でかつ宿泊費の高騰などもあり、なかなかハードルが高かったのですが、Japan Perl Association による学生向けの旅費支援制度によって気軽に参加できました。 Japan Perl Association、並びにスポンサーの企業には深く感謝しています。

Day 1

一日目はセッションを中心に聴講しました。

なぜ強調表示できず ** が表示されるのか — Perl で始まった Markdown の歴史と日本語文書における課題

最初は hkws さんのセッションを聴講しました。

チャット形式の AI サービスでよく見かける Markdown の強調表示がうまく動作しない問題を起点に、Markdown の歴史と日本語文書における課題について解説されていました。

自分も同様の強調が動作しない問題に遭遇したことがありました。 その際には Markdown パーサーのバグかと思って雑に流してしまっていたのですが、それは実際には仕様に起因する問題でした。 CommonMark には括弧などの約物があり、それと分かち書きをしない CJK の扱いの難しさが関係しているとのことでした。

Markdown は自分も日常的に使用しており、このブログも Markdown で書かれています。 複雑な歴史と仕様があることはなんとなく知っていましたが、改めて整理して聞くことで理解が深まりました。 まだまだ知らない仕様や挙動があると思うので、この機会に調べてみたいです。

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

次はゲストスピーカーである福岡工業大学の 山澤 一誠 教授のセッションを聴講しました。

このセッションでは福岡工業大学における「人工知能プログラミング」の講義での AI 活用と学生の変化について紹介されていました。 この授業では、パックマン、迷路、じゃんけんなどのゲームを解く、より賢い AI を作ることが課題となります。 近年の LLM やコーディングエージェントの発展により、学生の成果物に大きく変化があったということでした。

自分も大学生として課題に AI を活用しているため、他人事ではなく自分ごととして聴いていました。 実際に AI を使用したことで新しい領域を学びやすくなった反面、AI に頼りすぎて自分の理解が浅くなってしまうこともあると実感しています。

発表内で重要とされていたのは、 AI が書いたコードを自分で理解しレビューできる必要がある という点でした。 この点には同意しつつも、それを学生に求めることの難しさも痛感します。

また、発表内で紹介されていた、ここ数年での学生の解答の変化は面白かったです。 AI を使った場合に出力されがちな「賢い書き方」を単に grep してその件数を比較しただけで、あんなにも顕著な差が出るのは驚きでした。

k1LoW/deck を急激に (100 倍以上) 高速化する方法

次は songmu さんのセッションを聴講しました。

このセッションでは、k1LoW/deck のパフォーマンス改善をするにあたった過程が紹介されていました。 OSS プロダクトへの関わり方から、 k1LoW/deck とのどのように関わってきたか、そこからパフォーマンスチューニングの心得に繋がります。

k1LoW/deck は Markdown から Google スライドのスライドを生成するツールです。 一般的な Markdown からスライドを作成するツールとは異なり、Google Slide API を使用して Google スライド上に作成するアプローチをとっています。 このアプローチを取ることにより、Google スライド上で変更したデザインを保持したままスライドを更新できるという利点があります。

deck でのパフォーマンス改善は、 Google Slide API のバッチリクエストを最大限活用することで実現されています。 バッチリクエスト内でのリクエスト数に上限がないという富豪ぶりには思わず笑ってしまいました。

Slide API の話は deck 固有の事情ですが、後半のパフォーマンスチューニングの心得は汎用的でした。 今後の開発でも活かしていきたいです。

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

次は moznion さんのセッションを聴講しました。

このセッションでは、プロダクト開発におけるデータの重要性とデータを作る際の向き合い方について紹介されていました。

特に印象に残ったのは、「データは無くても困らない」 と 「データはソフトウェアの一部である」 という言葉です。

「データは無くても困らない」こう聞くとデータを集める必要がないように聞こえます。 しかし、この言葉はデータがない場合には困っていることにも気づけない、という意味で使われていました。

この話は自分にも思い当たる節があります。大学の講義の一環で開発しているプロダクトで、必要なデータを自分達で集めた経験があるからです。 データがもしなかったら、可能性が狭まり本来の目的を達成できなかったでしょう。

「データはソフトウェアの一部である」という言葉は考えたことがありませんでした。 しかし、データもソフトウェアと同様に自動化やテストができると考えれば、この視点は腑に落ちます。

大規模 OSS に一人で立ち向かうには

次は Sosuke Suzuki さんのセッションを聴講しました。

「情熱をエミュレートする」この言葉がとても心に残っています。 必ずしも情熱を維持する必要はなく、情熱がある人だったらどうするかを考えることが重要という意味です。

また、後半の大規模 OSS へ貢献するための TIPS は大規模な OSS に複数関わってきた経験に基づいており、説得力がありました。 「寝ること、自然を歩くこと」は人間の基礎にして一番難しいことだと感じます。

自分は大規模な OSS に継続的に貢献したことは今のところありませんが、今後その機会があった場合はこの内容を思い出していきたいです。 また、この内容は OSS に限らず、普段の開発にも応用できる部分があるでしょう。

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

次は hitode909 さんのセッションを聴講しました。 ここに来てほぼ初めて Perl のお話です。

AI によるコード書き換えは信頼できない部分があるため、静的解析するツールを AI で作成するという内容でした。 ただの静的解析ツールではなく 正規表現 で静的解析する プロジェクト固有の ツールを作るのがポイントでした。

正規表現であれば簡単に作成でき、プロジェクト固有にすることで必要最低限の記法で済みます。 様々な記法で書くことができる TMTOWTDI (There’s More Than One Way To Do It) の Perl ならではのアプローチだと感じました。

「偽陰性」は許容するが「偽陽性」は許容しない、という考え方も興味深かったです。 必要なコードを誤って書き換えてしまうことは避けなければならない一方で、完璧を求めずに見逃しても良い、というバランス感覚が重要だと感じました。

発表では Perl コードの例が多く紹介されていましたが、他の言語でも応用できる部分が多いため、今後の開発にも活かしていきたいです。

Perl ブートキャンプ

次は Takafumi ONAKA さんによる Perl ブートキャンプを聴講しました。

Perl のコードを読むための取っ掛りとして、Perl の基礎的な文法や概念について解説するセッションです。 このセッションの目標は約 1 時間で「Perl 完全に理解した」になることです。

自分はアルバイトで Perl を書いていたため、一度基礎的な学習はしています。 しかし、ちょうどここ 2 ヶ月ほど私用によりアルバイトを休んでいたため、ちょうど良い復習になりました。

周りの友人は Perl の独特な記法や挙動に困惑していました。 自分が最初に学習したときを思い出して共感もしつつ、困惑した反応はおもしろかったです。

無事ブートキャンプを修了し、 Perl を完全に理解しました。

頑なに再代入しない！

次は、 abetomo さんのセッションを聴講しました。

このセッションでは JavaScript における再代入の問題点と、代替手段との比較について紹介されていました。 再代入することでコードの可読性が下がったり、バグの温床になったりすることがあるという内容でした。 一方、再代入を避けた場合のパフォーマンスへの影響についても触れられていました。

自分も JavaScript を書くことが多く、再代入はあまり使用したくないと考えています。 また、自分は JavaScript を書く際には Biome というリンターを使用することが多いです。 Biome ではそもそも推奨設定で let の使用を禁止しており、再代入を避けることを強制しています。

パフォーマンスについては普段あまり気にしていなかったため、実際に計測された具体的な数値を見ることで意識が変わりました。 ただ、多くの Web アプリケーションではネットワーク通信の時間が支配的なため、この差が問題になることは少ないでしょう。 とはいえ、パフォーマンスが重要な場面もあるため、状況に応じて判断していきたいです。

学生支援プログラム懇親会

スポンサーの企業の方と学生参加者でわいわいもつ鍋を囲みました。 自宅サーバーの話などで盛り上がっていた記憶があります。

博多といったらもつ鍋

もつ鍋を食べてホテルに戻り、寝落ちをして一日目は終了しました。

Day 2

慣れないアパホテルのベッドでアラームに起こされ、寝坊する友人を置いて再び会場へ戻ってきました。 二日目はセッションを聞いたり、スポンサーブースを回ったり、踊り場の企画に参加したりと盛りだくさんでした。

OSS 開発者の憂鬱

次は yusukebe さんのセッションを聴講しました。

yusukebe さんが開発している OSS の TypeScript フレームワーク Hono での話を中心に、これまでの OSS 開発の変化とその憂鬱な部分について紹介されていました。

Hono は以前から自分も使用しており、比較的身近な OSS です。 自分が使っている Hono だからこそ、OSS として成長する中での苦労という話はリアルに響きました。

大規模 OSS に一人で立ち向かうには のセッションが「貢献者側」の視点だったのに対し、こちらは「作者側」の視点であり、対照的で面白かったです。

自分もエンジニアとして、OSS エンジニアに対しては多かれ少かれ憧れを持っています。 OSS は良いことだけではない、むしろ辛いことの方が多いというのは以前から知っていましたが、具体的な話を聞くことで改めて認識できました。

また、憂鬱を減らすための貢献者側の心得として、Minimal Reproduction を作成しバグの再現を助けることが重要だという指摘は、自分も心がけていきたいです。 自分も OSS へ Issue や PR を送るときは、できるだけ再現手順を丁寧に書くよう心がけています。 今後もこの点は深く意識し、メンテナーが心地良く開発できるように貢献していきたいです。

機密情報の漏洩を防げ！ Web フロントエンド開発で意識すべき漏洩ポイントとその対策

次は mizdra さんのセッションを聴講しました。

このセッションでは、Web フロントエンド開発における機密情報漏洩のリスクとその対策について紹介されていました。

自分はフロントエンドを書くことが多く、とても身近な話題でした。 幸い普段から意識していることが多く、特に Server Components は使用することが多いので、改めて知識を整理できました。

どのように漏洩するかについては既知の情報が多かったのですが、後半の漏洩の有無を調べたり漏洩を防ぐための機能については知らないことも多かったです。 特に、Chrome DevTools での検索機能は知っていたものの活用できていなかったので、今後活用したいです。 また、 React の Taint API については知らなかったので experimental ではありますが、情報を追っていきたいです。

探求の技術

次は azukiazusa さんのセッションを聴講しました。 このセッションでは、azukiazusa さんが技術を探求しアウトプットするための、原動力と記事の書き方について紹介されていました。

自分もよく azukiazusa さんのブログを読むことが多く、その記事はとてもわかりやすいと感じています。

翻って自分の探求はというと、技術に関する情報収集は好きで Twitter の TL や GitHub の Feed をよく追っています。 しかし、それらの情報を咀嚼し言語化することがあまりできておらず、その力が不足している自覚があります。 セッションの中であった 「自分の学習効果を最大化するためにアウトプットを行う」 というものは自分にとってまさに足りていない部分であり、今後意識していきたいです。

技術記事の書き方についても、実践的なノウハウが詰まっていました。 中でも AI を構成の壁打ちや構成の確認に用いるのは、自分も取り入れたい方法です。 例にあった textlint MCP は、CLI の方は既に使用しているので MCP も試してみたいです。

懇親会

セッションやキーノートが修了し、バスに揺られて懇親会会場へ。 これまでいくつかのカンファレンスに参加してきましたが、会場が別に用意されているのは初めてで少々驚きました。

懇親会といったらお寿司

懇親会では様々な方とお話しました。 特に、バイトでお世話になっているはてなの方々と初めてお話しできたのは嬉しかったです。 他にも学生の方や、様々なエンジニアの方とオリジナルのビールを片手に歓談しました。

あっという間に時間が過ぎ、名残惜しさを感じつつも会場を後にしました。

まとめ

初めての YAPC 参加でしたが、幅広い内容のセッションを聴き、たくさんの人と交流できました。 Perl に限らず、日々の開発や OSS との向き合い方について持ち帰れるものが多かったです。 コミュニティの温かさも印象的で、来年、再来年も参加したいです。

また、繰り返しにはなりますが、Japan Perl Association による旅費支援制度には非常に感謝しています。 本当にありがとうございました。

来年は …

YAPC::Tokyo 2026 in Tokyo Big Sight

また来年、有明でお会いしましょう !

おまけ - 福岡観光の写真

0 日目 博多到着後に食べた博多ラーメン

2 日目 深夜に食べたラーメン (なんと 290 円 !!!)

3 日目 博多ポートタワーから眺めた景色

4 日目 太宰府天満宮の参道にて 梅ヶ枝餅と抹茶

4 日目 飛行機から眺めた博多の夜景