プロポーザル

MySQL，MariaDBで高速な全文検索を可能にするストレージエンジンにMroonga（むるんが）があります。
MroongaはMySQL, MariaDBのLTSのみサポートしていますが、それでも現時点で以下の6つのバージョンをサポートする必要があります。

• MySQL 8.0
• MySQL 8.4
• MariaDB 10.6
• MariaDB 10.11
• MariaDB 11.4
• MariaDB 11.8

バージョンによって、同じテストが使える場合もありますが、互換性のない変更が入った場合はバージョンによって動かないテストが出てきてしまいます。
その都度、別ファイルを作成していてはテストファイルが膨大になってしまいメンテンナンスできなくなってしまいますが
Mroongaでは、一つのテストファイルで複数のバージョンのテストを実行できるようにしてメンテンナンス不能になるのを防いでいます。

このトークでは、(Perlで作られている)MySQL Test Frameworkを使って、一つのテストで複数バージョンのMySQL、MariaDBをテストする方法を実例を交えて解説します。

Mroongaのテストで得たノウハウから、一般的なテストでも役立つメンテナンスしやすいテストを書く工夫を解説する予定なので、テストでお困りの皆さんはご期待ください！

ウェブアプリケーションの文脈で「データモデリング」と聞くと、多くの方は OLTP (Online Transaction Processing) を想起するのではないでしょうか。具体的には、RDB (Relational DataBase) のテーブル設計や最適化を思い浮かべる方が多いと思います。

一方で、ウェブアプリケーションの顧客や製品に関する情報を分析のために処理するプロセスも存在します。これが OLAP (Online Analytical Processing) と呼ばれるものです。人によっては ETL や ELT の方が馴染み深いかもしれません。

一見すると同じデータベース操作に見えますが、実際には求められる機能や特性は大きく異なります。たとえば、OLTP では Read/Write がともに多いのに対し、OLAP では Read に偏っている傾向があります。こうした背景から、データモデリングの手法も RDB のベストプラクティスとは大きく異なってきます。

本セッションでは、OLAP に従事するエンジニアが、OLAP の概要紹介と、OLTP と OLAP におけるモデリング手法の違いに焦点を当ててお話しします。OLTP に慣れている方にとって、新たな視点を得るきっかけになるでしょう。福岡の地で、新しい知識を吸収してみませんか？

想定対象者

OLTPに関わるソフトウェアエンジニア
自社のRDSのデータの利活用に興味のある方

前提知識

OLTPにおけるデータモデリングの基礎理解
OLAPについては前提知識を問いません

Fibenis is an adaptive platform shaped by Perl’s expressiveness and TPS principles. Starting as a small code generator, it evolved into an application builder through refinements. Its core lies in absorbing communication patterns in the BREAD cycle (Browse, Read, Edit, Add, Delete) to generate code with a few vital inputs. While implementations expanded in PHP, automation and non-linear actions are still handled in Perl. With an EAV schema builder, built-in app/CMS/e-commerce features, and multi-domain apps with customizable behavior and skin, Fibenis’ modularity enables reuse, recycle, and reduce—cutting cost and time for rapid, standardized development. This talk shares how Perl has strengthened its capabilities in overcoming uncertain real-time challenges.

クラウドネイティブ環境に移行したら、なぜかコストが想定以上に膨らんでしまった経験はありませんか？

8年間オンプレで運用してきたRails製サービスのEKS移行において、まさにこの課題に直面した私たちが実践した解決策を紹介します。
既存のRails APIをGoで再実装し、API仕様を完全に維持しながら大幅なインフラコスト削減、パフォーマンス向上を実現したプロジェクトの全容について話します。

マイクロサービス環境では、一つのサービス変更が数十の下流サービスに影響を与える可能性があります。
このリスクを回避しながら新技術の恩恵を受けるため、全面的なリプレイスではなくRailsとGoの共存アーキテクチャを採用しました。段階的な移行戦略により、運用リスクを最小限に抑えながらクラウド環境での最適化を実現した実例を、実際の運用で得られた具体的な数値とともに共有します。

主な内容：

• EKS環境におけるRailsとGoのリソース効率比較と実測データ
• API互換性を保ちながらの段階的な言語移行手法
• 実際のプロダクション環境で得られた定量的な成果

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

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

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

ある日セールスから、とあるエンタープライズ企業のトライアルが始まることを知らされました。嬉しい知らせでしたが、詳細を聞いてみると対象のテナントは従来のテナントと比べて50倍以上のデータ規模であるということが判明します。

ISUCONのように既存リソースを極限まで最適化し、解決することが理想です。しかし実際の運用では、「サービスを止められない」、 「データの欠損は許されない」 など運用上の制約があり難しい場合があります。
一方でスケールアップやリソースの追加といった、お金をかけて解決する選択も実際の運用中では有効なオプションとなり得ます。 また、スピードを優先することで長期的には技術的負債になり得そうな選択肢を取ることも出てきます。

本発表では、アプリケーション、バッチジョブ、インフラ に渡って トライアルから本契約に至る過程で直面した"急"な大規模データリクエストにおいて、どのような対策を事前にとったのか、どのような問題が起こったのか、どのように解決していったのかを紹介します。

この発表を通じて、制約下でどうスケールアップ/リソース追加を選択し改善を重ねたかを共有し、急な要求に直面した際の一つの参考事例になればと思います。

アジェンダ (予定)

• サービスおよびシステムについての紹介
• あらまし
• 課題の洗い出し
  • システムを止めないといけない対応
  • システムを止めなくてもできる対応
• 実際の対応例
  • DBのスケールアップ
  • kubernetesのserviceの分離
  • PostgreSQLのJSONBサイズの限界と対応
  • BigQueryは1行あたり１GBまで
  • など
• 振り返り および 今後
• まとめ

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

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

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

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

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

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

ソースコードを解析するには、静的解析や動的解析などの手法があります。 また、昨今ではLLMの進化が激しいためChatGPTなどにソースコードの解析を任せるケースが増えてきたのではないでしょうか？

従来の手法では、精度が高いが実装コストが高く、LLMだけに任せた場合は柔軟なフォーマットですが精度に疑問が残ります。
特に解析対象のソースコードの量が増えていくと、一筋縄で行かない問題が増えていきます。

実例: 大規模Android アプリに含まれる画面一覧をソースコードより取得したい。
・手動でドキュメント等をメンテナンスするのは限界があるから自動化したい
・Cursor等に単純にリクエストを投げるだけだと、かなりの数の取り残しが発生した。
・静的解析だけでは、画面の存在は知ることができるが、どのような画面なのか判別できない

そこで、このセッションではメルカリの大規模ソースコードを解析するために静的解析とLLMを組み合わせ、従来の弱点を克服する手法を提案します。
また、単純に静的解析とLLMを組み合わせただけでは、限界があります。 LLMとのSessionのContextが埋まってしまい、精度高く処理を完了することができません。
Claude Code の Sub-Agent 機能を有効活用し、意識的なContext Engineeringを実施することで、より効果的に、精度高く解析を完了させることができます。

本セッションでは、従来手法の課題、実際のユースケース、導入による改善、そしてLLMを活用する際の限界や工夫を共有します。
「なぜそうなるのか」も時間の許す限り丁寧に説明していきます。 今後のLLMを業務で活用する場合に、活きる話を手堅くしていきます。

対象

• 事業の成長に伴い、複雑化・サイロ化したシステムの再設計や改善に取り組むソフトウェアエンジニア。
• 複数のプロダクトやチームにまたがる横断的なプロジェクトで、技術とビジネスの橋渡しに課題を感じているTech Lead、Tech PdMの方々。
• ドメイン駆動設計（DDD）やモデリングの理論は学びつつも、実務の混沌とした要求を前に、どこから手をつければよいか悩んでいる方。

セッションのゴール

このセッションを通じて、聴講者が以下の状態になることを目指します。

• RDRAを活用し、チーム横断の複雑な業務を分析・構造化する手法を習得する。
• 保守性と変更容易性を高めるイミュータブルデータモデリングの設計原則を学ぶ。
• LLMを用いて要求分析とモデリングを高速化する具体的な手法を習得する。

概要

「プロダクトが増えるたびに、システム間の連携は複雑になり、誰も全体像を把握できない…」 あなたのチームでも、そんな「見えない負債」が開発のボトルネックになっていませんか？ 私が所属する医療SaaSの現場も、まさにその課題に直面していました。

このセッションでは、混沌とした業務知識を紐解き、チームで共通の地図を描くための実践的な歩み方をお話しします。まず、要求分析手法RDRAを用いて、散らかった業務と情報の関係性を構造化します。次に、その構造を「事実」の積み重ねとして捉えるイミュータブルデータモデリングによって、変更に強く、監査性にも優れた堅牢な業務システムを設計します。

そして、これらのプロセスを、LLMを相棒としていかに高速化するか、具体的な事例を交えて紹介します。複雑なドメインに立ち向かうための思考のフレームワークと、明日から使える具体的なアクションをお届けします。

「メンタルモデル」という言葉は、認知心理学にその起源を持ち、人間中心デザイン（HCD）などデザイン領域でも重要な概念のひとつとなっています。ソフトウェア開発の領域でも一般的に使われる言葉となりましたが、良いソフトウェアを設計するためにはより深く本質的な理解が必要です。

人間は、おかれている環境（社会）において様々な課題を解決するために道具を制作し、利用します。道具をうまく活用し、目的を達成するには良いメンタルモデルを構築することが重要です。
ソフトウェアはその構造が複層的であり、無形かつ有形であり、新規性や変幻自在性といった意味において従来のハードな道具とは根本的に異なる性質を持ちます。
ドメイン駆動設計のアプローチを上手に進めるためにも、メンタルモデルに対するメンタルモデルを正しく構築しておくことは重要だと考えます。

本トークでは、認知心理学、HCD、そしてドメイン駆動設計という異なる文脈で語られてきたメンタルモデルを統合的に捉え直し、問題空間と解決空間、そして複数のステークホルダー（エンドユーザー、ドメイン専門家、開発者）の視点から、ソフトウェア開発におけるモデリングのあり方を探求（きゅう）します。

コードを読んでいると、この変数はどこで定義され、どこで値が設定されたのか？を確認することがしばしばあります。
再代入が多いとどのタイミングで値が変更されるのか？を確認するコストが発生するので、私はめんどうだと思ってしまいます。
また、再代入がないほうがメンテナンス性が高いと信じています。なぜならば、すべてが再代入なし（= すべてが定数）の方がバグが生まれにくいはずだからです。
（いわゆる関数型プログラミング、というやつです。）

と、いうことで私は基本的に再代入をしないコードを書くように心がけています。
（もちろん、それによるデメリットがあるのも承知でそのようにしています。）

私が始めたOSSではありませんが、現在は9割方私が書いたコードになっているnode-lambda ( https://github.com/motdotla/node-lambda ) （JavaScriptです）を例に、頑なに再代入をしない（関数型プログラミング）を実践した例を紹介します。
（これまではデメリットについて、厳密に検証したことがなかったのですが、改めて検証してまとめてデメリットについても発表します。）

大規模開発の参考になること間違いなし！

近年、AIの進化により、私たちの仕事は大きく変わりつつあります。
AIツールを上手に使える人と使えない人の差が出てきています。なぜでしょうか？それは、職種や分野を超えた考え方ができるかどうかです。
エンジニアやデザイナーは不要と言われていますが、私はエンジニアやデザイナーのスキルがあってこそ、AIを活用できると考えています。

本セッションでは、AIを単なる便利なツールで終わらせないための課題を抽象化する考え方をお伝えします。
このスキルは特定の職種に縛られない汎用的なものです。

私は営業、エンジニア、デザイナー、マネージャーなど様々な仕事を経験しました。
これらの経験から「問題を見つける力」が身につきました。エンジニアリング、デザイン、問題発見の力を組み合わせることで、AIをもっと活用できるようになりました。

このセッションでは、私の経験を交えながら、以下の内容を掘り下げていきます。
・ なぜAI時代に「職種に縛られないこと」が重要なのか
・AIへ問いをたてるために、課題を抽象化する力の重要性と考え方
・ 明日から実践できる「コンフォートゾーン脱出術」と、キャリアを広げるための具体的なヒント

AI時代をチャンスと捉え、自身のキャリアをさらに進化させたいすべての方へ。
職種の壁を越えた先には、AIを使いこなすための新たな視点とキャリアの可能性が広がっています。

プログラムを再利用可能なモジュールとして書きつつ、それを実行可能なプログラムとしても使えるようにする、Modulino（モジュリーノ） という書き方が存在します。 Modulino の有用性について、筆者は過去に何度か Perl Advent Calendar や吉祥寺PM 等で発表してきました。最近 Claude Code を使い始めて、
Modulino の有益性は更に増したと感じています。

このセッションでは、
Modulino や（筆者の提唱する）JSON 指向の OO Modulino について解説した上で、
筆者の CPAN 上の Modulino を改良する際に AI エージェントを使った
実際のやりとりを振り返りながら、
次のような知見を皆さんと共有したいと考えています。

• JSON 指向の OO Modulino という（大半の皆さんが聞いたことも無いような）珍しい使い方でも、それが CLI として自然なら、エージェントは理解して活用してくれる

  • エージェントが生成する動作確認スクリプトファイルの数を減らすことが出来る

• 独自性の強いメタプログラミング・フレームワークでも、自然な宣言的 DSL になっていて、静的検査の手段が提供されていれば、エージェントは理解して活用してくれる

  • 静的検査ツールの存在が一層重要に

「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の際に出しましたが、個人的都合で当日行けなくなりました。テーマは同じですが、当時とは状況が変わっているのでアップデートした内容になります。

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

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

今やクラウドにおいて一般的となった「サーバーレスアーキテクチャ」ですが、本来は「サーバーの管理負荷をなくす」ためのアーキテクチャです。

しかし、確かにサーバーの管理負荷はほぼ不要になりましたが、その反面
　・ 気が付いたら、Lambda関数の数が管理しきれないほど膨大になっていた
　・ 「このLambda関数、何に使用しているんだっけ？」というような用途が不明な関数が多くなっていた
となってしまい、むしろ「Lambda関数の管理が負荷になってしまっている」というケースは結構あるのではないかと思います。

そこでこのセッションでは、そのようなサーバーレスにおけるLambda関数の管理負荷を削減するためのアプローチとして、Lambda-lessとLambda-lithという2つのアプローチ、
そしてその詳細やユースケースなどを紹介したいと思います。
また私が業務で実際にLambda-lithを採用して学んだこと、そしてLambda-lithはAmazon BedrockなどAIとの連携でもよく使われることから、
「なぜLambda-lithはAIとの相性が良いのか」についてもお話ししたいと思います。

※なおタイトルは「Lambda」とAWS準拠のタイトルになっていますが、セッションで紹介する内容はもちろんMicrosoft AzureやGoogle Cloudでも適用可能なものとなっております。

Vibe coding のためのツールは日々進化しています。
イベント開催日 2025年11月14-15日 において、一番最先端なツール・技術を最速でキャッチアップしてVibe Coding のライブコーディングを行います。

Cursor Meetup Tokyo (参加者 6000人以上) や Devin Meetup Tokyo、 Claude Code Meetup Tokyo などを開催し、様々なツールを爆速でキャッチアップし使いこなしてきた筆者が全力で行います💪

参加者は、Tipsも交えてイベント開催時、最先端のVibe coding toolについての知見を得ることができます。
事前に決められたお題だけではなく、当日お題を聞いて、Live coding していきたい！

現時点での内容候補(変更する可能性が多々あります)
・Claude Code が2025年8月時点では、最もよく使われているツールです。 なので、Live Vibe Coding でも採用します
・前半にて、 Claude Code の概要、強み(CLIである柔軟性、 長時間実行を想定した設計、Sub-Agentsとコンテキスト管理の柔軟性）について解説します。
・後半にて、実際に説明した強みを活かした Live Vibe Coding を行います。 題材は、その場で視聴者から募集する予定です。
・Sub-Agentsとコンテキスト管理の柔軟性 に関しては、世間では注目されていませんが、他のツールに対する明確な優位な特徴です。

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

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

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

• ReAct
• Function Calling

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

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

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

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

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

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

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

根本的な違い

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

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

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

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

想定する聴衆

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

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