YAPC::Fukuoka 2025 初参加レポート

概要

こんにちは、駅メモ！開発チームエンジニアの id:hayayanai です！

11/14-15に開催された YAPC::Fukuoka 2025 へ参加してきました。今回はそのレポートです。 「レポートを書くまでが YAPC」とのことで、社内ドキュメントとして共有したものを手直しして、このブログにも投稿しておきます。

yapcjapan.org

講演を聴いたり会場を見て回ったりして、業務で活かせないかな〜と考えたことを書き残しています。 概ね講演メモ→感想という感じの順番で書いてます。LTについてはいくつか聴きましたが、気になったものを少しピックアップして書いてます。

参加を決めた理由

• 会社のスポンサーチケットがあった
• YAPC行ってみたかった
  • モバファクの社員が元々結構参加していて、興味があった
• 福岡行きたい
• Perl あまりわからないけど、ちょっと詳しくなりたいな
• 他のカンファレンスとYAPCの雰囲気の違いを感じてみたかった

---

Day 1

オープニング

パッションを感じるオープニングトーク

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

• GPTのレスポンスで、強調表示できたりできなかったりする
• カギカッコやスペースで強調されたりされなかったり
• CommonMarkの仕様に由来
  • CommonMarkはまだv0だけど、実態はv1みたいな感じ
• Markdownの歴史
  • ** のオリジナル→CommonMarkの変化
• Markdownには強調と強い強調がある
  • strongタグに変換
  • →emタグに変換の順で処理
• **や*のネストを処理に困って、left/right-flankingの導入をした
  • 分かち書きする言語でバグる
  • 対策は考えられてるけど、CJK friendlyなParser/Rendererを利用しないといけない

感想

• Markdown、文章の改行周りや箇条書きの方言も多くて大変だなと思ってた。
• 自分が使うMarkdownパーサーはどんな解釈ルールで解釈されてるか、確認したほうが良さそう。
• CJKを意識した実装になってないものを使ってたら意図しない表示の原因になるかも。
• エディタとレンダラーで同じパーサーを使っている場合は問題なさそうだけど、異なるパーサーを使っている場合はさらに注意が必要そう。

Introducing RFC9111 by 小山健一郎

• 参考書籍: Web配信の技術
• 今回は共有キャッシュの話
• HTTPキャッシュの実装は参照してるRFCが色々ある
  • FastlyはRFC9111
  • CloudflareはRFC7234/RFC2616
• RFC7234が多め
  • 新しく作るなら、廃止されているのでRFC9111が良いだろう
• ミドルウェアがたくさんある
• どのリクエストをキャッシュしていいかというのもRFC9111に書かれている
• Tests for HTTP Cachesを使うとローカルでテストができる
• CDNのキャッシュの実装を見ると良い

感想

• 開発者ツールのNetworkタブ見るときも、no-cacheの挙動とか覚えておくと良さそう？
• キャッシュの利用を考えるとき、できるだけユーザーに近い側のキャッシュを使うというのは改めて大事だなと思った。

AIコーディングの弱点、やっぱりプログラミングは人間が(も)勉強しよう by きしだ なおき

• Transformerの解説
• 最近は変数の入力を大きくしても性能がほぼサチっている
  • 電気や人間が供給できる文章数に限界
  • チャットで人間による評価が入ってきてパフォーマンス向上(GPT3.5〜)
• Function Calling
  • LLMから外部関数を呼び出すように
  • MCP
• 一旦知識を吐き出させて、ユーザー入力と知識を投入させると精度が出やすい
  • Reasoning
• AIの計算
  • 3桁までの数字は１トークン
• LLMはユニットテストが書けるものは賢くなる
  • 非機能要件は大体苦手になる
• 長いコンテキストの対応
  • 1Mトークン対応と謳っているが、性能が出るのは30Kトークンくらい
  • どんどん遅くなっていく
• なぜ同じ失敗が続くのか
  • 間違い同士で注目して、大事な情報だと認識してしまう
  • コンテキストを汚さずコンパクトに。
    • 汚れたときにコンテキストから消し去るのは、coding agentが頑張っている部分
  • 壁打ちと実際に作業させるチャットを分けると良い
    • ダメな情報はダメなものとして認識してくれない
      • 否定文を上手く理解してくれないのと同じ
• プログラミングの話

感想

• 「失敗を繰り返さないようにログとして持たせる」vs「失敗のログが重視されてしまって誤りを繰り返される」のバランスが大変そう。
• ダラダラ書いてると人間とAIどちらにも優しくないコード書きがちだから、コードのユーザビリティを意識していきたいなと思った。
• 最近はAIが人間のプログラミング学習を支援してくれる機能もあって人間の勉強もしやすいよなと思っている。研修に活きてきたりするんだろうか。

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

• SNSアカウント一覧の中にCPANのIDもある
• データは必要になってから重要性に気づく
  • 推論は…
    • 人間がわからないものは機械にもわからない
    • 推論せずに済むなら推論しないほうが良い
• データを作る
  • 利用できる状態まで、データのソースを整理する
• 辞書作りの例
  • DuckDBを利用
• スプレッドシートからはじめよ
  • ツールのフロントエンドとしてデファクト
• 前処理など、データ作りは大変
  • SPOF回避や、マイルストーン設定が大事
  • 手順は変えてもいいが、一貫性は持たせないといけない

感想

• データが欲しくなったときに、そもそもデータが無いことに気づくのあるなと…。
• （本題とは逸れるけど）論理削除フラグみたいなbooleanを、delete_fgじゃなくてdeleted_atで持つテクニック、ちょっと前にXで見たけどわかりやすそうだなと思った。
• DuckDBが各種プログラミング向けにライブラリがあるよと紹介されたとき、Perlにもあるんだろうか…？と疑ってしまったけれど、ちゃんとあるようだった。

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

• WebKitのスクリプトはPerl/Ruby/Pythonで書かれている
• 高校生からOSSに貢献
• Prettierは人手不足でメンテナーに
• WebKit, JavaScriptCoreの話
• WebKit開発者のランクの話
• fix typoだけじゃなくて、数年単位で責任持ってやっていく
• 可能な限り時間を捻出して、集中してやる
  • 最も大事
• コードを読む（AIに読ませる）→手を動かしてデータを見る
  • プロジェクト内の常識に沿って書けるようにする
• 他の貢献者の活動を見る
• 寝よう
• コードを書く気が起きないときは、AIに書かせる
• 自分の助けのためにAIを使うのではなく、書かせる部分の性能について
  • もっと進化してほしい
  • このパッチと似た最適化を別のところに適用させたりはうまくいく

感想

• PerlもWebフロントエンドのOSSに比べれば人手不足だろうなという気がするので、Perl書けるエンジニアとして何らかの貢献してみたいなと思った。
• プログラミング言語の勉強の話、知らなかった言語がスラスラ読み書きできるようになるのは楽しかったよなぁと、昔の記憶が思い起こされた。
• 他のコントリビューターのコードを見るのは、OSSに限らず、複数人で開発しているリポジトリなら大事だよなと感じた。

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

• Perlの静的解析の話
• プロジェクト固有の静的解析ツールをAIに作らせて、AIの信用できない部分をカバー
• 静的解析は構文木をパースするけど、バイブス静的解析はコードベース内の記法のみ扱う
  • PPI等ではなく、正規表現で作る
  • 言語で扱える全ての記法に対応する必要ないよね
• 偽陰性は、デッドコードが残るだけだから問題なし
• 偽陽性は不具合のもとで危ない
• 確認、実行は人間の目に留めておくと良い
• デッドコード削除のカスタムコマンドを作っておくと便利
• useしてないのにメソッド呼び出しするコードの改善
  • 正規表現でやってたのを、AIにPPI版を実装してもらう
  • PPI版が遅すぎるから、同じ結果になるように正規表現の方を改善

感想

• 「デッドコードの一生」の図が、この通りにやったことあるな〜となって、どこも一緒なんだなという気持ち。
• use忘れでメソッド呼び出しとか、どこでも問題になるんだなぁ…😭

LT

「文字列→日付」の落とし穴

• 標準のモジュールで変換する場合も、バリデーションは手前でしないと意図しない変換になる場合がある

感想

結構トラップな挙動…。

高速化＆コスト半減！？ GitHub Actionsのサードパーティーマネージドランナーの比較 by occhi

• みんなCIは高速化したい
• ランナー
  • GitHub ホステッド
  • セルフホステッド
  • サードパーティ←この話

感想

• サードパーティランナーがGitHub ホステッドのランナーより安くなる理由ってどこから来るんだろうか

2ヶ月で新規事業のシステムを0から立ち上げるスタートアップの舞台裏

• 新規事業の立ち上げ: トップダウン
• 再現性の考察
• リサーチは人力
• SRE含めエンジニアは５人
• あらゆるものが無いところから
• 技術スタックは買えない(Ruby on Rails)
• ユーザーストーリーマッピング
• Spec-Driven Development
  • AIにPR作ってもらう
  • 仕様書等もコミットした
• １週間に40回デプロイ
• AIの0→1は瞬発力がすごい
• AIが散らかしたコードをきれいにした

感想

• RailsでAIの恩恵受けづらいの、やはりPerlと似たようなところがあるのかなと思った。

【お楽しみ】10分トークN連発 by YAPC::Fukuoka チーム （40分）

幕間CMを支えている技術

• React + GitHub Pages or Vercelでやる
• Window Management APIでフルスクリーンを制御する
• display:none でできるだけローカルキャッシュを使う
  • ネットワークが不安定なことの対策

感想

• てっきりOBSとか使ってるのかと思ってたけど、手作りで丁寧に作られていた

後天的Perl

• Rubyを先天的に獲得
• Perlの . を文字列結合からメソッド呼び出しにできた

感想

• これはPerl？ それともRuby？ クイズ思い出した
• できるもんなんだなぁ

log

• 対数ではない
• Perl/Ruby界隈はLTSVが主流
• Goはslogが来て構造化ログのトレンド？
• JSON Linesがいい感じ
  • Claude CodeのログもJSON Lines
    • thinkingのログ見たり
• テスト・静的解析のログをsub agentにさせて、コンテキストを食いつぶすのを避ける試みをしてる
  • ハルシネーションには注意
• iframeを許可するようにheaderで許可すると良い

感想

• テスト・静的解析のログをsub agentにさせるの面白そう。自動でやってくれる未来も来そう

頑なに再代入しない！

• 理由
  • if文の中で場合分けして変化していくコード…。わかりにくい
    • 読みやすさ・バグのリスク低減・保守性UP
• jsの例
  • letの時点で、変数の流れを追いかけることになる
  • constで即時実行関数にする。などで対応
• デメリット検証
  • 実行時間比較
    • IIFE > 関数を作る >= 再代入でフラグ設定
• OSSで実践した
  • node-lambda
  • 値が不変で安心
  • 関数をつくることに意識が向きやすい
    • ユニットテストが書きやすくなるメリット
      • バグが生まれにくいというところにもつながる

感想

• jsの即時実行関数みたいなことを、たまにperlでもdoやsubでやったりするので、わかりみが深かった。
• 発表の経過時間とスライドの進み具合がウサギとカメでわかるの良いなと思った
  • Rabbitというものらしい？

LT

銅鑼で発表が打ち切られるの面白い

プロジェクトの空気を読んで開発してくれるPerlのAIツールがほしい by kobaken

• 最近のPerlは初学者やAIに優しくなってる
• 古いものと混ざってわかりづらい
• 本を書いて、初学者やAIにも優しくした

感想

• 新しいバージョンに移行したときとか、適宜情報をアップデートしていくのは人間・AIどちらにも大事だよなと思った

Pythonを"理解"しているコーディングエージェントが欲しい！！ by nikkie

• Linter で指摘する
• 修正するところはsub agent に任せている

感想

• 修正をsub agent に任せるのはなるほど〜となった。

基盤モデルのアーキテクチャを改造してみよう - 時系列基盤モデルのマルチモーダル拡張事例の紹介 by himura467

• 離脱する時期や、一度落ちたら戻らないから、その手前でアラートを出せないかをやってみた

感想

• ゲームの離脱防止に繋がるかも？

---

Day 2

起床後、ホテルで急なお仕事をやっつける。ちょっと遅刻して会場入り

旧から新へ: 大規模ウェブクローラのPerlからGoへの置き換え by motemen

感想

• 20年の歴史のあるプロダクトを移行するって判断がすごい。
  • Perl実装に切り戻す判断をあらかじめ決めておくのも大事だよなと思う。
• やっぱりPerl→Goでリソース減るんだなぁ。
• gRPC/OpenAPIエンドポイントをPerl側から呼び出して共有←良さそう。
• OpenTelemetry対応、Perlでやるよりは楽だろうから言語移行のメリット出て良さそう。

Perl の生きのこり

• Perlの歴史の話
  • CGI
  • mod_perl
  • PSGI/Plack
    • Interface/実装 の関係
• 複雑なアプリケーション
  • 環境構築問題
    • Carton
  • コードの問題
  • CIで問題検知
• 複雑化するプロダクトにPerlはどう立ち向かってる？
  • プログラミング言語の変化
  • perlはbackward-compatibilityだけではなく、bugward-compatibilityも重視
    • でも、OOPは変化した
      • v5.42は組み込みで class がついてくる
      • try catchもある
• スマホ対応による変化
• ChatCPT, AIによる変化
• 新しい書き方を推し進める動機づけ
  • experimentalでないなら
  • try catchはおすすめ
    • Try::Tinyはデファクトだけどハマりどころがある

感想

• 後方互換性を保ちながら、時代に合わせて発展していったのがPerlなんだなと再認識

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

• モダンなフロントが漏洩させやすい理由
  • テンプレートエンジンとの違い
  • ViewライブラリでUIを組む
  • 特にSSRも当たり前
  • Nextでif文使って出し分けるだけだと、キャンペーン情報の存在が漏れる
  • 対策
    • サーバーから情報をfetch
    • フレームワーク特有の仕組みを使う
• 漏洩の有無を調べる方法
  • grep
  • 開発者ツールのNetworkパネル
• テクニック
  • CIでもgrep
  • Taint API(React)
    • 実行時エラーでページを見られなくできる
  • GraphQLでdata fetch
    • スキーマに書かれたfieldしか取れなくなる
    • resolverの実装コストとトレードオフ

感想

• Taint API、Nuxtにも無いかな〜
• モダンなフレームワーク、バックエンドとフロントエンドの境界が曖昧な感じで、それが漏洩に繋がりやすいのかなと思った。

読む技術・書く技術・伝える技術 - 15年続けて分かった持続可能なオープンソース開発 by azu

• 15年くらいオープンソース開発
• アウトプットではなく、アウトカムを目指している
  • 実際の影響・成果
  • 時間が必要
• 燃え尽きまでに段階がある
• 技術的依存を増やし、心理的負荷を減らす
  • 技術的依存はコントロール可能
  • 心理的負荷はコントロール不可
• JSer.infoの話
  • 新しい情報を数千から自動収集
  • 人間のキュレーション
    • さらに興味を持って見てもらう
    • 将来的には自動化される未来もあるかも
  • 13記事溜まったら公開で、心理的負担の減少
• textlintの話
  • No core rule
    • 自分でルールを選んでね
  • コアにルールを持つと、ルールのissueがコアに集まる=心理的負担増
  • ユーザーがプラグイン（ルール）を選ばないといけないのがデメリット
  • ユーザーがAIになって難しさが変化
• JavaScript Primerの話
  • 書籍版とウェブ版がある
    • ウェブ版は常に公開されているから、完成へのハードルが下がる
  • 章を書くときに、Design Docを作ってから書き始める
    • Design DocからAIにドラフトを書かせて第一歩とする
  • 既知の言葉で未知を説明する
  • サンプルコードの実行結果があっているかをテストで確認
• コントリビューターを増やす
  • 変化への対応
  • 著者を増やして心理的負担を減らす
  • 報酬も出す
  • 100人以上
• Stale issue/PRの自動閉鎖とか、心理的負担の低減に役立つ
• 技術的依存は交換（更新）可能だからいい感じ
• 更新を継続するにあたって、習慣化はどれくらい大事だと感じていますか？
  • 勝手に習慣、癖になっている

感想

• JSer.infoはよく読んでいるけれども、inputの部分がとても大きいことを始めて知った。
  • ただその中で、技術による自動化を組み込んでいるのが面白いなと思った。
• textlintもよく使っていて、技術記事に特化したルールやAIっぽさを消すルール等、自分で目的に応じて調整できるのが合ってるなとは思う。
• JavaScript Primerも新人時代に読んだ記憶があって、最新の内容を学べて良かったなと思った。
  • 裏側でかなりの人や技術が働いているんだなと
• StaleなIssueやチケットを、ちゃんと閉じていくのは大事なんだろうなという気持ち

探求の技術

• 週１でブログを書いている
• なぜ探求するのか
  • おもしろさが原動力
  • 追いかけるのではなく、楽しむ
• 報酬や評価を目的（外発的動機づけ）にするよりも、自分の興味や好奇心から（内発的動機づけ）のほうが、長期的に続きやすい
• アウトプットは自分のため
  • 外からの評価より、自分の学びを目的にする
  • 他人へ説明するために書くことで学習効果が生まれる
  • 誰かが読むかもという意識
• 習慣の力
  • 意志力に頼らず行動できる
    • 歯磨きをやるぞ！ってやるのは少ない。習慣になってるから
    • 技術ブログを書くぞ！ではなく、習慣化している
  • きっかけ→ルーティン→報酬→きっかけ
• 習慣化を根付かせた例
  • 歯磨きを習慣化させたアメリカの例
  • きっかけの創出
    • すぐできるような行動。（歯に舌で触れる）
  • 即座に報酬を得られないと習慣化が難しい
    • 虫歯がなくなって健康よりも、ミントで爽快感を得ることをアピール
• 技術探求を習慣化するには
  • 情報収集チャネルを用意
    • X, はてなブックマーク, RSSリーダー, 会社のSlackチャンネル
  • ルーティンを決める
    • 習慣が途切れることを嫌に思わせる (損失回避バイアス)
    • すぐに取りかかれるように環境を用意しておく
  • 報酬を用意
    • いいねやアクセス数は報酬にしない
      • 外発的動機づけになってしまう
    • 自分でコントロールできるものが良い
      • 記録を残す工程は自動化する
• 課題
  • 情報過多・キャッチアップの限界
  • アウトプットの質と量のジレンマ
    • どっちを優先すべきか
• わかりやすい記事が書ける理由
  • 自分が一番わかっていないから
    • 技術ブログを書くのは、自らの学習の手段
    • 精通してから書くのではなくて、逆
    • 試行錯誤しながら理解を含めていくライブ感
      • 躓きやすいポイントを押さえられる
  • 結論ファーストであるかは必ずしもそうではない
    • 上司への報告ではないから
  • コンテキストファーストで、導入部で読者の前提知識を揃える
    • Stack Overflowがこの構成
    • Situation->Complication->Question (状況→複雑化→疑問)

• テンプレートを用意

• 導入部

• 課題定期
• 解決策
• 実装例
• 結論

• 参考文献

• 登壇経験が文章力を高めた

• AIに技術記事を書かせるのはどうか
  • 学習の機会は失ってしまう
  • 壁打ち相手として文書構成を検討
    • ラバーダッキング効果
  • 文章校正
    • いきなり編集は任せない。出力フォーマットを指定しつつ、指摘のみにしておく
  • 自分の知識を増幅する道具とすると良い

感想

• 自分がXで情報収集しているのも、普段の癖を活かせてるから良いのかなと思った
• 技術広報を推進するチームのメンバーとしては、各々の開発環境に技術ブログ執筆用のリポジトリをクローンしておいてもらうのが良いのかもと思った
  • きっかけ作りに良いかも
  • 執筆までの第一歩を下げられそう
• 今後の業務で使いそうなので、また読み直したい

LT

ghqの秘密

• ghqが対応してるバージョン管理システムの話

感想

• GoogleもPerforceだったんですねぇ
  • 今はPiper

伝統的日本企業のソフトウェアエンジニアになって無双しよう！

• toCサービスたくさん
• 内製開発組織がない
• YAPC参加で認知拡大

感想

• カンファレンスでスポンサーして認知拡大させるのは良さそう
  • 企業スポンサーってそういう目的もあるよねと
• グッズでサンリオほしい
  • 自社IPのグッズ良いなとなった

---

スポンサーブース

• 全部回れました
  • コンプリート景品の煎餅はお土産に
• ブースの方とも色々話せた
  • 時間によっては登壇者の方も

懇親会

• クラフトビールを出している店が有名らしいと聞いた
  • ピーチのビールを飲んだ。美味でした
• 聞いてみた感じPerl書いたことない人や、使ってない会社も多めだった
  • Ruby(on Rails)やPHP書いている人は結構見かけた
• 学生支援制度は素晴らしい
• パックマンルールで立っている方がちらほらいて、スッと会話に混ざりやすかった
• YAPCのセッションやAI、PerlやRubyは皆の共通の話題として話が広がりやすかった印象
• 登壇していた方や学生さんとも話せて良い学びになった
• 色んな人と話して、今後の業務に活かせそうなアイデアがたくさん浮かんだ
  • 既に社内で提案してみたり
• もっと話したい！

全体の感想

• 以前お世話になった方にも久しぶりにご挨拶できてハッピー
• 福岡に住んでいる同僚や知り合いにも会えてハッピー
• Slidoで思いついたことをサクッと質問できるので楽だった
• lintエラー対応をsub agentにやらせてコンテキストを節約するの流行ってそう
  • 社内にシェアしていきたい
• AIの話は多め
  • 開発でAI使ってる話が多め。プロダクトに組み込むAIの話もあった
• Perl詳しくないから理解できるか不安だったけど、知らない人にもわかるような導入から始まるセッションが多くてわかりやすかった
• モバファクはPerlコミュニティ的には話せるネタを持ってたりするのかもしれない？
• 他のカンファレンスよりもホームのような雰囲気で参加できた
• 来年は東京。次は前夜祭から参加したい

モバファクでは中途採用・新卒採用ともに絶賛募集中です。 会社の情報については、モバファクブログでも発信しています。 技術好きな方、モバファクにご興味をお持ちの方は、ぜひご応募ください！

• モバファクブログ：https://corpcomn.mobilefactory.jp/
• 採用サイト：https://recruit.mobilefactory.jp/