トーク

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プロジェクトに一人で立ち向かい、技術的な理解を身につけながらコミュニティからある程度認められるようになるための方法について、なるべく再現性のあるアプローチについてお話しします。

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

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

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

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

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

現在は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化

「OSS」ってキラキラして見えるかもしれないけど、憂鬱になることがたくさんある。これまで愚痴を表に出すことはしなかったけど、このトークではあえてそれをさせてくれ。今までの苦労を成仏させてくれ。

僕は2021年の年末からHonoというOSSを作っている。それは驚くほど人気になった。2025年8月現在、GitHubのスター数は「26K」。日本人発のプロダクトだと世界で第3位の数字である。この規模のOSSを開発・メンテナンスをできるのは非常に貴重な経験で「僕にしか見れない景色」を見ている。今回はその景色を少しでもあなたに見てもらいたい。決して、OSSにコントリビュートすることを促すわけではない。ただ、あなたが使っているソフトウェアの背景にはとんでもないドラマがあるってことを知ってもらいたい。

具体的には以下のトピックを話します。

• Honoの現状
• 僕らはCPANで息を吸うようにOSSをしていた
• GitHubのInboxが恐怖
• ありがたいIssueと厄介なIssue
• Whyを聞かれると辛い
• Share a minimal project to reproduce it!
• 中学生コントリビューター
• 登山をしてたら向かいから集団が来て全員に挨拶しなくてはいけない問題
• 嫉妬される
• Noを言うのは大変
• やりたいことをシェアしない
• Hono Conference
• 外向的性格がOSSをやると
• You are a legend!
• 頑張ればなんとかなる
• そして、希望

まぁ、大変だけどすごく楽しいよ！

同タイトルのプロポーザルをYAPC::Hakodate 2024の際に出しましたが、個人的都合で当日行けなくなりました。テーマは同じですが、当時とは状況が変わっているのでアップデートした内容になります。

はてなアンテナは登録したURLの更新情報を定期的に取得し、更新内容をまとめるウェブサイト巡回サービスです。
サービス開始以来20年を越えたはてなアンテナでは、Perlで書かれたコードベースの置き換えを進めています。
最初の一手として、数百万件のページを効率よく巡回するクローラをGoで書き直しました。クローラをゼロからつくる中でおこなった実装の選択や、既存のクローラからの移行および運用、既存のバックエンドとのコミュニケーションなど、プロダクトを漸進的に新しくしている過程についてお話しします。

以下のような内容について話す予定です。

• モチベーション: PerlからGoへ
• 実装編
  • ストレージの選定
  • キューの実装
  • producer-consumer パターン
  • http.Transport
• 運用編
  • カナリアリリースと移行戦略
  • ローカル開発
  • テスト
  • 旧バックエンドとのコミュニケーション
  • 中間証明書の問題
  • 健全性の監視

このトークでは、技術の変遷とともにどのようにPerlが変化してきたのか歴史を探求しながら、最近のモダンなPerlを紹介していきます。

Perlを使っている人、かつて使っていた人、プログラミングに興味がある人、プログラミングの歴史に興味がある人など
そんな人たちに「懐かしい〜」「へ〜」と思ってもらえるような内容を、わいとんとkobakenの2人でお送りします。

1990年から2025年現在までのWeb開発を「インターネット掲示板（BBS）」を題材に駆け上がり、各時代の変化のキッカケや背景に触れていきます。

お品書きは次の通りです。

1. CGI
2. PSGI/Plack
3. 複雑化するプロダクトにPerlはどう立ち向かってる？
4. 外圧による変化
5. 未来はどうなるか

このトークは「エンジニアがこの先生きのこるためのカンファレンス」 の前夜祭企画をベースに、
YAPC::Fukuoka 2025 用に再編・改善した内容になります。

最近、大規模言語モデル（LLM）が急速に普及していますが、すべての分野でLLMが万能というわけではありません。例えば、金融やセキュリティといった高い信頼性が求められる業界では、回帰やブースティング系の "古典的な" 機械学習の技術が、今なお第一線で活躍しています。

その理由は、旧来の機械学習では「この取引は不正利用の可能性が80%」といったように確率を使って物事を予測したり、「なぜそのように予測値が出たのか」という理由を人間が理解しやすい形で説明できる点にあります。身近な例では、金融での与信スコアリングやカード決済や送金等の不正利用の検知などの "予測タスク" に機械学習が今でも使われています。

このトークでは、機械学習のユニークなポイントと私が機械学習を好きな理由について、過去に熱中して作っていた "競馬" を題材にお伝えします。勘や経験則、あるいは人間が地道に作るルールだけでなく、機械学習という道具を手に入れると、競馬の収支を改善するためにどのようなアプローチが可能になるのか？ 最近話題のLLMに尋ねるのとは、何が違うのか？私の過去の実践経験を元に、詳しく説明します。

機械学習について初めて知る人でも楽しめるよう、以下の流れでお話しする予定です。

• 機械学習の基本
  • 機械学習とは何か？特に教師あり学習について
  • 機械学習が使われている分野
  • 機械学習の利点と欠点
  • 機械学習のシステム構築の流れ
  • 最近の機械学習の潮流
• 競馬と機械学習
  • 競馬の簡単な紹介
  • 競馬に適した機械学習手法の紹介
• 競馬の勝ち馬予測モデルの作り方
  • 予測の元になるデータを集める
  • 予測の精度を高めるための特徴量エンジニアリング
  • 予測モデルの構築方法と評価手法
• 勝ち馬予測モデルの実践
  • 予測値の活用方法
  • 実戦での評価検証

JSer.info・textlint・jsprimerというプロジェクトを通じて、私は「書くことは読むことである」という理解に辿り着きました。
この発表では、興味本位で始めた日々の情報収集がツール開発を経て大規模プロジェクトの設計技術へ発展するプロセス、
読む→書く→伝えるの段階的変化についてお話しします。

まず「読む技術」として、JavaScriptの情報サイトである JSer.info （14年間で750記事）の更新を支える情報収集システムを紹介します。

• 参考: https://jser.info/2021/01/16/jser-10th/

次に「書く技術」として、読むだけでは物足りず「書いてみよう」と思った経験から始ったPromise本執筆時の表記揺れ問題をきっかけに作った、textlintについて紹介します。
書くことで増える読む量や、AI時代における文章品質の自動化の進化についても、textlintのMCP対応のデモも交えて紹介します。

• 参考: https://efcl.info/2022/06/29/why-create-textlint/

最後に「伝える技術」として、jsprimer という JavaScript 入門書を継続開発する際の文章設計について紹介します。
Design Doc による文章の設計、Living Standard アプローチ、既知→未知の原則、書きやすさより読みやすさを優先する設計思想などを扱います。
また、オープンソースとして100人以上がコントリビューターと参加してもらった仕組みやGitHub Sponsors/Open Collectiveによる経済も触れます。

• 参考: https://efcl.info/2025/05/24/tskaigi-2025-jsprimer/

普段から業務でPerlのWebアプリケーションを開発・運用している方であっても「cpanfileに ::XS とついたモジュールがいくつか並んでいるところまではわかっているが、難解そうで、実装を追ったりするのはなんとなく避けてしまっている」というような方は少なくないのではないでしょうか (かくいう私もそのような時期がありました……)。

そんなXS、Perlにおけるネイティブ拡張のための仕組みは、

• データベースクライアントなど既存のCライブラリへのラッパー
  • （libmysqlclientに対応するDBD::mysqlや、ImageMagickに対応するPerlMagickなど）
• ネイティブコードによる最適化がウリのライブラリ
  • （JSON::XS、Type::Tiny::XS、……）

など、Webアプリケーション開発において必須とも言えるモジュール群で使われている技術です。一方で、とっつきにくく思われている節があり、なかなか手ほどきを受ける機会もないように思います。

本セッションでは、普段Perlを読み書きしているがXSにはあまり触れたことがない方を主な対象に、XSモジュールに対する心理的なハードルを下げ、リファレンスなどを参照しながら既存のライブラリなどの実装を理解したり、トラブルシューティングができるようになることを目指します。また、Perlに馴染みがない方にとっても、スクリプト言語におけるネイティブ拡張の仕組みのケーススタディとして楽しんでいただければと思います。

トーク内容

• CPANモジュールを取り巻くツールチェインのおさらい
• XS "急"速入門
  • 「XS言語」の基本的な文法・構造から、外部ライブラリの呼び出しなど
• XSモジュール探訪
  • 実際のXSモジュールのコード読解

クラウドの利用が広がる中で、複数のプロダクトを横断して安定したインフラ基盤を提供することは、プラットフォームエンジニアリングにおける大きな課題です。

我々の組織hacomonoでは、1,000万人以上の登録ユーザーを抱えるサービスを提供しており、今後はさらに複数のプロダクト展開を計画しています。
これまでプロジェクトごとにAWSアカウントを発行し個別にリソースを管理してきましたが、組織の成長とともに、このやり方だけではスケールしていくのが難しいと考えています。

そこで現在、共通基盤をKubernetes上に構築する取り組みを進めており、その一つの施策として導入しているのが Crossplane です。
CrossplaneとはAWSやGCPなどのパブリッククラウドやKubernetesリソースなどをKubernetesの抽象で管理可能にするOSSのツールです。

Crossplaneによるリソースの抽象化は、開発者がより楽かつ安全にインフラを扱えるようにし、同時に基盤側も裏で進化を続けられる柔軟さをもたらします。
一方で、トラブルシューティング時の原因特定の難しさや、従来のIaCツールとは異なる運用フローへの適応、チーム全体での新たな技術スタックに関する知識共有などの課題も少しずつ見えてきています。

本セッションでは、Crossplaneの概要と、取り組みを通じて見えてきた可能性と難しさ、そして今後の展望を共有します。プラットフォームエンジニアや、Crossplaneの導入を検討している方にとって、参考になる話を届けられればと思います。

おしゃべりAIサービス Cotomo (https://cotomo.ai/) の開発のために必要な、ステートフルなAI agentを作る技術についてお話します。

「LLM」と「AI agent」の決定的な違いはなんでしょうか。そもそも「AI agent」の定義が人それぞれなので一概には言えませんが、人とコミュニケーションするのが主な仕事であるAI agentに関していえば、それは「状態」があるかどうかというのは一つの決定的な違いです。つまり、LLMは記憶を持たず、AI agentは記憶を持ちます。正確にいうと、記憶を持っているように見せかけています。

本セッションでは、そもそも「LLMがステートレス」とは何かという話から始め、ステートフルなAI agentのミニマムな実装を見せつつ、「AI agentの記憶」というテーマを深掘りします。

それにしても、この「AI agentの記憶」というものは大変厄介で、技術的にはすべての記憶を同時に持つわけにはいきません。そこで何らかの形で「今必要な記憶」だけを差し込みたいわけですが、そのあたりのソフトウェアエンジニアリング的な面白さも紹介できればと思います。

タイパや効率が最優先されがちな現代ですが、あえて正解までの最短コースだけを目指さず、道のりそのものを味わうプログラミングの楽しみ方を探求し、共有します。
題材の一つとして、毎年12月に小さなパズル問題が毎日出題される「Advent of Code」を紹介します。同じ問題に対しても解法は無数にあり、用いるプログラミング言語もアルゴリズムも様々、まさにTMTOWTDI！ 素朴にコードを書いて正解を導出して終わりにするのではなく、美しく効率的なコードを目指してみたり、業務では絶対に書かないような難解で突飛なものを考えたり、色々な楽しみ方があります。正解とは関係なくパズル入力の可視化に注力している参加者もいて、他の人の取り組みを見るだけでも学びがあり、とても面白く刺激的です。
また、私は個人の趣味活動としても「Pentomino」や「だんご屋のひまつぶし」といったパズルを自ら題材として取り上げ、プログラムで解く取り組みをしてきました。効率的な解法を調査し検証し、また得られた解をWebブラウザ上でインタラクティブに可視化するなど、自分なりのこだわりを持ったやり方で楽しみました。正解だけを求めて一直線で終わらせないからこそ得られた経験や学びを紹介します。
「コードはAIに書かせるもの」になりつつある現在ですが、やっぱり自分でコードを書くのは楽しいものです。自分流のプログラミングの楽しみ方を広げるためのヒントを持ち帰っていただき、“自分も何かやってみよう”という最初の一歩を後押ししたいと思います。