プロポーザル

AWSで業務効率化（自動化）を行う際、AWS Step Functionsが採用されるケースが増えてきており、最近ではWorkflow StudioやJSONataの登場もあり、一層それに拍車がかかっています。
特にJSONataの登場でLambdaを使用せずともAWS Step Functionsだけで処理が完結するケースが増えたこともあり、これからますます業務効率化、ひいてはDXの現場でAWS Step Functionsが採用されることが多いと思います。

ただ、確かにAWS Step FunctionsでAWSのオペレーションの大部分は自動化できますが、それだけで社内業務の業務効率化を完全に実現するのは難しいのではないでしょうか？
かといってノーコードツールなどの社内業務用ツールだけを使用してもかゆいところに手が届かず、なかなか思うように業務効率化が進まない...という事もあると思います。

そこでこのセッションでは、実際に私が自社において約4000ユーザーが使用するJira/ConfluenceをCloud版に移行した際、Jira AutomationとAWS Step Functionsのハイブリッド化による業務効率化を実現した経験を元に、上記の課題を「ノーコードツールとAWS Step Functionsのハイブリッド化」で解決した方法やそのノウハウ、特に「JSONataを始めとするAWS Step Functionsの効果的な使用方法」や「どのような処理にノーコードツール／Step Functionsを使用すべきか」などについてお話ししたいと思います。

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

2025年（今年！）2月にOpenAIがdeep research機能を発表しました。
そこからの進展は目覚ましく、商用サービス・OSS問わず様々なdeep researchの実装が提案されています。
発表者は好奇心から、また業務で同様の機能開発に取り組む都合から、GitHubにあるdeep research公開実装やarXivの論文を追いかけ、Pythonで手を動かしています。
その中で「動作しているようだが、LLMのコンテキストには何が入っているのかが明確に分からず、挙動を説明しきれない」という課題を感じ始めました。

この課題感の解消に向けて、OpenTelemetryに目を向けました。
OpenTelemetryはなかなか広範な技術で独学で進めるにはだいぶ苦労しましたが、deep research中のLLMのコンテキストを詳らかにできました！
例：https://pypi.org/project/llm-deep-research/0.0.2/

この発表では、PythonでLLMアプリケーションを開発していて、OpenTelemetryは初めてという方に向けて、OpenTelemetryでLLMのコンテキストを可視化する方法を紹介します。

1. OpenTelemetryの諸概念（テレメトリ、計装などなど）からはじめ
2. 多数あるopentelemetry-xxx Pythonパッケージの整理
3. GoogleのGemini APIを例に、LLMのコンテキストをログやメトリクスで計装するまで

をお伝えし、Geminiを使ったdeep researchの挙動を説明します。
なお、LLM Semantic Convention WGが現在進行系で活動中で、このトークの内容は2025年時点の現在地となります。

タイトルは「スペードのQ」という楽曲オマージュです

「ブログを書くまでがYAPC」と言われます。
ということでこのワークショップで、YAPC::Fukuoka 2025参加ブログを書きましょう！

基本的に各自参加ブログを書く時間です。
ワークショップのゴールは、「参加ブログを公開」または「あとこことここを書いたら公開できるという状態になる」ことです。
書き慣れている方はひたすらもくもくと執筆を進めていただいてかまいません。

書き方がわからない方、ご安心ください。
発表者は1000日ほど前から毎日ブログを1記事書いています。
技術記事中心に執筆しており、900記事は軽く超えるでしょう。
毎日ブログを執筆する中で、30分程度でもブログの内容をまとめられるようになりました。
「ブログ記事を小さくする」考え方や、生成AIの力の借り方（補完、検索代行、生成AIに全部書かせるか）といった発表者の型を共有し（10分程度）、初めて参加ブログを書く方の手助けができればと思っています。
型を知っても実際に書くと直面する不明点についても、質問に回答する形でサポートします。

ちなみに1000記事書く中で得られた型は、頻度高いブログ執筆だけでなく、ふだんの開発にも活かせるものだと実感しています。
参加者の方のアウトプットを加速する気づきを持ち帰っていただけたら、ワークショップ企画者として嬉しいです

個人ウェブサイトの素晴らしい世界を紹介します。

20年にわたって個人サイトを続けてきた経験を背景に、技術ネタを交えながら、個人ウェブの多様なあり方・繋がり方・文化を軽く分析し、取り上げます。

こんな切り口から見ていきます。
【型】仕上げたものを配信する？オープンな場で思考やノートを磨き続ける？ ー ブログ、個人wiki、ポートフォリオなどの典型的な形式を多次元モデルで捉え、ハイブリッドも考える。
【縁】Webringってなーに？ ー 個人ウェブサイトを繋ぐ仕組みや、配信・購読の方法を紹介。古き良いRSS、今どきの/nowページ、...llms.txtも？
【心】作って何が嬉しいの？ ー 個人サイトを作る様々な動機や、自分自身の「作って良かった」エピソードを話す。

本発表が、個人ウェブサイトに関心を持ち、作ったり見たり語ったりするきっかけとなれば幸いです。

私が所属するチームで刷新に取り組んでいる大規模レガシープロダクトは社内外問わず多くの方に利用していただいており、SLAも高く設定されていることから高水準のシステム運用とリリースサイクルが求められています。

こうした障害を許容せず、発生した場合速やかな原因特定・復旧が求められる環境において、現体制で見えてきた課題の解決とオブザーバビリティ改善に挑戦しました。
本セッションでは、その取り組みの内容をご紹介します。

紹介予定の内容

• オブザーバビリティの重要性に気づいた出来事
• 既存システム監視体制で見えた課題
• クラウド移行により見えた監視の課題
• 組織統制を意識した監視体制と技術選定
• SaaSに依存しないオブザーバ構築
• 分散トレーシングでオンプレとクラウドを繋ぐ
• RUMとAPM、そしてSentry
• 同調（トレース）、開始（オン）
• 負荷の監視とテスト
• Open Telemetryとトレースサンプリング戦略
• オブザーバビリティを継続させるためのバランスとチーム力
• 次に見えた課題と新たな挑戦

「かつて日本は、「24時間戦えますか？」の国でした。ハードワークが美徳とされ、強制的なチャレンジの中で成長する文化がありました。しかし働き方改革を経てホワイト化した現在の組織では、そうした手法は現実的ではありません。

その結果、私たちは「成長自己責任時代」を迎えています。黙っているとチャレンジは降ってこない。成長のための負荷を自分でかける必要がある。しかし、自分で自分にチャレンジを課すことができる人は少ないのが現実です。

さらに2029年には、AIネイティブ世代の新卒が入社してきます。高校で情報Iを学び、AIにプログラムを書かせるのが当たり前の世代です。彼らを迎えるいま、エンジニアの成長パラダイムは根本から変わろうとしています。

このセッションでは、ホワイト化とAI導入が進む社会で、若手エンジニアが自律的に成長していく手法を探ります。『コミュニティから技術力を』『上司から仕事力を』学ぶメソッドを通じて、若手エンジニアには自律的に成長していくための行動を、その育成者には若手の成長を後押しするためのツールをお伝えします。

TypeSpec は型（Type)を定義するの為作らっれた言語ではあります。TypeSpec Emitter で Java の Interface や OpenAPI スペックを生成することによって、多言語対応にはいい武器と思います。

今回は一つ例として、Perl の Type::Tiny モジュールの「型」を出力する TypeSpec Emitter を作って、使ってみたのはなしてす。

Gleamは、Erlangの堅牢性とモダンな型システムを組み合わせた新しい関数型言語です。
プログラムの正しさを型システムで保証しながら、Erlang VMの持つ高い信頼性と並行処理能力を活用できます。
また、JavaScriptバックエンド(Node.js/Deno/Bun)にもコンパイル可能で、
Erlang OTPに基づいた堅牢なバックエンドアプリケーションから、フレームワークを用いたSPAまで同じ言語で開発できる点が特徴です。
シンプルで表現力の高い構文と強力な型推論により、初めての関数型言語としても学びやすい設計になっています。

Stack Overflow Developer SurveyのAdmired and Desiredにおいて、2年前から登場し昨年はRustに次ぐ2位にランクインするなど、
急速な注目を集めています。GitHub Starsも1年で2倍と急上昇しており、欧州を中心に採用が広がっています。
また、最近ではイギリスのスタートアップ企業Strand社の社内システムとして使われるなど、
実運用の事例なども登場しており、リアルワールドの問題解決にも使われ始めています。

WebフレームワークのwispやThe Elm ArchitectureベースのSPAフレームワークLustreなど、
様々なライブラリやフレームワークが登場しエコシステムも成長しています。

本登壇では、そんな今のGleamとこれからのGleamの展望について話します。

対象者:

• 型安全な開発に関心のあるJavaScript/TypeScriptユーザー
• Erlang OTPを使った並行処理に興味がある方
• 関数型プログラミングに興味のある方

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

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

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

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

エンジニアリングって楽しいですよね。要件を深掘りして作るべきものをシャープにしていく過程や、生み出したい価値にぴったりなアーキテクチャを模索することはもちろん、実際に開発したものが動いて、価値としてユーザーに届く瞬間の喜びったらありません。

とはいえ、複数人が携わる中でよいエンジニアリングをする・し続けるためには、「エンジニアリング」の周辺といかにうまく付き合うか、という問題がつきまといます。「自分はエンジニアリングがしたいだけなのに、なんでこんなに会議ばっかりしているんだ…」と思うことも、しばしばあるのではないでしょうか。

とはいえ、こうした仕事は大事なものでもあり、どんなに効率化を図ってもゼロにはできません。なぜなら、よりよいエンジニアリングをするには、課題の本質を捉える必要があるから。そのためには、他の役割の目線を借り、ユーザーやユーザーを取り巻く環境を理解する引き出しを多く持つことが不可欠です。技術的な意思決定を後押しする情報をより多く集め、よいプロダクト作りを探「究」するための対話のコツを、今日からできるちょっとしたエクササイズとともにお伝えします。

Perlでの開発経験の全くない筆者が、AIとペアプログラミングしながら初めてPerlに挑戦しgrepライクなCLIツールを開発します。
まずは基本的な検索機能を実装し、その後は「ファイルタイプの指定」「行番号の表示」など、(リアルタイムの要望を取り入れながら?)オプションを拡張していきます。

さらに、同じ機能をGoで実装したツールも用意し、両言語の開発体験を比較しながら、言語ごとの特徴や得られた気づきを共有します。

また、本セッションでは「AIに頼って新しい言語を書くとき、提案されたコードが正しいかどうか判断できない」という課題にも触れます。AIからの回答をどのように取捨選択し、少しでも確からしいコードに近づけていくか、その実体験と工夫も紹介します。

このセッションで体験できること

• Perlを触ったことがない方でも、筆者と同じ目線でPerlの性質や開発体験を学べる
• AIが提案するコードの正しさをどう判断するか、そのヒントやTipsを得られる
• 「新しい言語を学びたいけれどハードルが高い」と感じる方が、AIを活用して一歩を踏み出すきっかけになる

現在HTTP Cacheに関するRFCは7234...ではありません。
2022年に改訂され、RFC「9」111 HTTP CachingとしてInternet Standardになっています。

本発表ではRFC9111、特に共有キャッシュについて見ていきます。
プロキシサーバのアップストリームに位置するWebアプリケーションとしてどうすればキャッシュをしてくれるのか、もしくは拒否できるのか。
理解すれば、実装にはよりますが少なくともRFCに沿った議論ができるようになります。
発表者はRFC9111に沿ったキャッシュミドルウェアを実装しています。
https://github.com/2manymws/rc
この実装経験に基づいた紹介をします。
（なお、2025年8月現在rfc9111で検索して出てくるのは我々のリポジトリを含めて5つ https://github.com/search?q=rfc9111&type=repositories ）

この機会に「RFC9111完全に理解した」になりましょう！

皆さん、アウトプットしてますか？
SNSへの投稿、技術ブログ、登壇など、様々なアウトプットの形がある中で、商業出版は実現のハードルの高さという意味で「究極のアウトプット」の一つと言えるでしょう。

私は今年9月に技術評論社から人生初の単著を商業出版しました。
約1年間の執筆経験は、自分の知識と徹底的に向き合い、それを正確に伝える技術を磨くと同時に、仕事に対する基準そのものを変革する機会となりました。

このトークでは、商業出版を通じて学んだ「知識との向き合い方と伝え方」について、以下の「きゅう」の観点からお話しします。

【求】正確性と伝わりやすさの追求
・ 読者に誤った情報を伝えないための徹底的な調査と検証
・ 対象読者に伝わりやすいように前提や暗黙知からの整理

【究】究極のアウトプットへの挑戦
・ 自分の知識と向き合い、体系化するプロセス
・ 執筆初心者だからこそ直面した壁とその乗り越え方

【急】執筆がもたらした急成長
・ 論理的な構成力と説明力の向上
・ 理想を言語化したことで生まれた、仕事への高い基準

商業出版という経験は、単に本を書く技術だけでなく、自分の知識との向き合い方、それを伝える責任、そして日々の仕事におけるあるべき品質を教えてくれました。この貴重な経験で得られた学びを共有し、皆さんが自分なりの『究極のアウトプット』に挑戦したくなるようなトークを目指します。

MySQLで「暗号化」と主語を広くした場合、そこにはいくつかの定石があります。

• Transparent Data Encryptionと同一に扱われることが多い、物理ファイルの暗号化について。
• End2End暗号と呼ばれる「そもそもMySQLに入れる前に暗号化したバイナリ列にしてvarbinaryやBLOBに格納する」方法
• データをバックアップしたならばそれもデータ、その暗号化は？

MySQL Community Edition(GPL版)とその他のOSSを組み合わせて2026年に使える/選べる手順書紹介します。
これはひょっとしたらRDS for MySQLとかでも使えるかもしれませんというかほぼ使えると思います。

皆さんは CRE (Customer Reliability Engineering) という職種をご存知でしょうか？
CRE は 2016 年に Google が提唱した、顧客の信頼性をエンジニアリングする職種です。

さて4年前、私は保守・運用チームの一員として、主にカスタマーサポートからの問い合わせを対応しつつ、並行して改善・障害対応・技術的負債解消などを行っていました。
このチームは重要であるがエンジニアのモチベーションが上がりにくいという慢性的な課題を抱えていました。そこで私はこのチームの役割を単なる保守・運用ではなく CRE と定義し、さまざまな工夫を行ってきました。
例えば、以下のように攻めと守りの運用を定義し、攻めの割合を増やす、といった工夫です。

• 攻めの運用: 将来顕在化する見込みのある運用上の問題に対し、発生前に先んじて対応を行うもの
• 守りの運用: すでに運用上の課題が発生しており、期限内に対応が求められるもの

このような工夫を続け、顧客信頼性を真剣に考えた結果、いつしかプロダクト全体の技術的課題について取り組むようになりました。
そして私は現在、テックリードとしてプロダクトの技術的課題の解決に取り組んでいます。

本セッションでは、まだあまり知られていない CRE という職種から、テックリードへのキャリア変遷の実例と、その経験がどのように活かされているかをお話しします。

本セッションを通じて、日々の保守・運用業務に従事されているすべてのエンジニアに、その経験こそが将来のテクニカルエキスパートへの礎となることをお伝えしたいと思います。一見地味に見える運用業務の中にも、プロダクト全体を深く理解し、技術的課題を発見・解決する力を育む機会が溢れています。
本セッションが終わる頃には、明日からの運用業務が、きっと違った景色に見えてくるでしょう。

私が開発している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年間のメンテナンスから得られた実践的な知見を共有します。

背景

　現代のWebサービス開発において、サブスクリプション型の課金は切っても切れない存在と言えます。ブラウザ、iOS、Androidなどマルチプラットフォームにおけるサービス提供を考えると、この課金も様々な課金プラットフォームに対応する必要があります。
　それぞれの課金プラットフォームは、それぞれ固有のロジックを持つので、場当たり的に結合した場合、様々な矛盾を生み出しかねません。結合には一貫したポリシーが必要になります。それを決めるのは課金プラットフォームの開発者ではなく、プロダクトの開発者に他なりません。
　この発表では、ポリシーを持ってサブスクリプション型課金機能を組み込んでいくために必要なことを、Perlで開発しているアプリケーションであるGigaViewerの開発において直面した課題を中心にして論じます。

章立て

世界はプラットフォームで閉じていない 〜境界線上での困難〜

• プラットフォーム同士の境界: プラットフォーム横断的に付与される権利の取り回し
• プラットフォームとビジネスの境界: 提供したいサービスとプラットフォームが想定するサービスのライフサイクルギャップ
  -プラットフォームとアプリケーションの境界: 我々は確定した結果を受け入れることしかできない

境界線の上で転ばないために

• どこまでを課金プラットフォームに委ねるか
• エッジケースにおける運営不利益 vs. ユーザー不利益の最小化トレードオフ
• 石橋を叩いて渡れ

ゴール

• アプリストアにおける定期購読の全体像が概観できる。
• 決済プラットフォームという「自分たちでコントロールできない外部仕様」と向き合うための、具体的な設計思想や開発・運用ノウハウを得られる。

• とある デジタル庁におけるガバメントクラウド整備のためのクラウドサービスの提供（令和5年度募集） にはこんな調達仕様書がついています。
  • DBのバックアップを差分で取得できること。取得したバックアップはいつでもDBの復元に使用できること。復元時は別のサイズを選択できること。
  • DBのバックアップは、一定期間（例：5分）以前のどの時点にでも戻せるかたちで（Point In Timer Restore）取得できること。
  • DBのバックアップは、予め設定したタイミング、周期、世代で自動的に定期実行できること。
  • DBのバックアップイメージは、CSPの中であれば、別のシステム、別のネットワーク、別の環境からも利用できること。

RDBMS as a Serviceでは当たり前に提供されてきたこの機能を、もし自分たちで提供しないといけないとしたら、今この2025年ではどんなツールを使うのが良さそうなのか。

• mysqldump ..?
• Percona XtraBackupってどうなったのだろう？
• MySQL Shellでもバックアップは取れるらしいが本当に使えるの？
• Cloneプラグインでリモートバックアップが取れるって本当？
• 5分以前のどの時点でも戻せるかたちで取得ってどうする？
  試行錯誤してたどり着いたバックアップの取り方をお話しします。

メルペイでは、エンジニアの情報発信を“組織として当たり前のものとして根付かせる文化”へと変えていくために、FY25に初めて「Merpay Tech PR Roadmap」を策定しました。
Qごとに開催する社内Tech Talk、カンファレンス登壇に向けたネタ出し会、年2回のブログ企画などを通じて、発信を仕組み化し、みんなで取り組む環境づくりを進めてきました。
この1年間の試行錯誤を通じて得られた成果や課題、メルペイからメルカリグループのFintech事業全体へと広がる手応え、さらには「FT Tech PR Award」という表彰企画の誕生まで、実際にどんなことをやってきたのかを率直に共有します。
いまの“発信文化の現在地”を共有しつつ、これからどこへ向かうのか――その一端をお届けできればと思います。