プロポーザル

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

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

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

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

アジェンダ (予定)

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

このトークでは、技術の変遷とともにどのように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といった機能が実装されました。また、Chef、Puppet、Ansible等の既存の構成管理ツールとどう使い分けるべきかが議論されていました。

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

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

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

根本的な違い

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

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

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

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

想定する聴衆

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

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

「AIに仕事を奪われたら農家になろうかな」――最近、そんな声を冗談交じりに耳にします。

私は数年間ソフトウェアエンジニアとして働いた後、大学で1年間農業を学びました。その後、エンジニアと兼業して花農家になり、最後はふたたび専業エンジニアへ戻りました。
家でPCと向き合っていた日々から、炎天下の中で花と向き合うようになりました。「きゅう」変した環境下で農業を営んだ経験は、その後のキャリアにも通じる学びをもたらしました。

このセッションでは

• 地域の特性や自分が持っている環境を最大限活かす「農業版スタートアップ思考」
• エンジニアの経験が農業で役立ったこと・全く通用しなかったこと
• 「JA」や「直販」だけじゃない、多様な農業ビジネスモデル
• 「百姓ってのは百のことができなあかんから百姓やねん。」父が語った農業と、そこから知ったプロダクト開発との共通点
  をお話しします。

農業とエンジニアという、完全なる異分野を経験した稀有なキャリアだからこそ学べたことをお伝えします。

次のリンクは私のnoteの記事です。私が農業で具体的に何をしていたかは、こちらを参考にして下さい。
https://note.com/naoya7076/all

急に決まったし急に終わった
旧に満ちていたし求に溢れていた

ここ９年くらいでさまざまなクラウドインフラを見てきたのですが、これほどとは、と思ったのは初めてでした。

誰もわからない全貌、オフショアメンバーしか入り方を知らないサーバー、本番しかない環境、デプロイはもちろんぬくもりある手動、ユーザーからの問い合わせでわかる機能停止、・・・

こういった状況から、モダンな・なるべく理想形に近い、少なくともコントローラブルなサービス運用に引き戻していこうとした数々の試みと、取り組みを途中で終わりにせざるを得なくなった時に感じた諸行無常を、記憶がホットなうちにお話しします。

なかなかに数奇であった自分の現在地を聞いていただければ幸いです。

PostgreSQLのRow Level Security（RLS）は、行単位でアクセス制御を行う仕組みで、マルチテナント環境での利用に適しています。

弊社でもRLSを用いてマルチテナント運用を行っていますが、実際に運用してみると意外な悩みどころが見えてきました。
本発表では「RLSとは何か」という基本から始め、運用を通じて得られた“リアル”を軸に、導入や設計に役立つ知見を紹介します。
RLSとともに歩んできた私たちの現在地（いま）を共有し、そこから見える設計上の判断や工夫についてお話します！

話すこと

• RLSの概要と基本的な使い方
• RLS運用とクエリパフォーマンスの現実
• VIEWにおけるRLSとアクセス制御の落とし穴
• 正規化されたテーブルでのRLS適用方針
• テナントごとの接続切り替え設計