プロポーザル

筆者の在籍する会社では大規模Railsアプリケーションの開発・保守を行っています（500以上のテーブル、1300以上のModelクラス、20000以上のテストケース数）。2025年5月時点でのテストの実行時間は9(きゅう)並列で約11分と、開発効率のボトルネックとなっていました。
CI高速化に取り組んだ結果、プロポーザル執筆時点で約5分半までテストの実行時間を短縮することに成功しました。

このセッションではテストの「きゅう」速な改善で得た知見を、上手くいったこともいかなかったことも赤裸々にお話します。どの言語でも応用可能な実践的ノウハウを提供します。

お話しする予定の内容

• ボトルネックの計測・分析
  • GitHub Actionsの実行時間の継続的な計測
  • test-profを利用したRubyのテスト分析
• 並列実行の最適化
  • 並列ジョブとparallel_testsの活用
  • ジョブ・プロセス毎のテスト実行時間均一化
• GitHub Actionsワークフローの最適化
  • 不要ジョブの削減・実行タイミングの調整
• テストコード中に作られるデータ量の削減
  • ネストされたFactoryの生成（Factory Cascade）との戦い
  • moznion/be-let-it-beを利用した改善
• MySQLの最適化
  • tmpfsの活用
  • my.cnf最適化
  • MySQLダンプのキャッシュ
• Flakyテストとの戦い
• 利用するランナーの選定
  • サードパーティマネージドランナー
  • セルフホステッドランナー
    • 物理マシンを活用する試み
• 今後の展望
  • 増えていくテストに対する対処
  • 組織横断的な改善活動

新しくプロジェクトにジョインしたばかりのエンジニアや、そもそも現場が初めてだというジュニアエンジニアの方は、今自分が直面しているプロダクトが一体どういう状況で、そしてどうあるべきか、を全てドキュメントから攫うことは容易ではありません。
ドキュメントがどれだけ整備されていても、僅かな行間を捉えられなくてドメイン知識の理解が遅くなってしまうことは多々あり得ます。

長くプロジェクトにいるメンバであっても、他のメンバとの会話をしないといけない場面は多々あり、そこで自分の考えと違うことが決まりそうになるが納得しかねる、ということも多く経験されていると思います。

上記のいずれのケースであっても、多くの場合メンバとコミュニケーションを取ることで容易に解決できる問題に分類されます。
そして、そのコミュニケーションは、何も綿密に裏付けられた知識が全てというわけではありません。
筆者はスムーズな意思疎通の重要な要素の1つに、「疑問（Question）」があると考えています。

本セッションでは、

• ジュニアエンジニアが疑問を持ち続けて日々の業務に取り組んできた結果
• 対エンジニア、対チームメンバとのコミュニケーションを取っていく中で得られた学び
• 疑問を解消していくことが自身のスケーリングにつながること

をお話できればと思います。

昨今はAIが台頭し、エンジニアが他の業種のメンバとコラボレーションしていくことが益々多くなってきました。
エンジニアを取り巻く多くの状況が変貌していく中、それでも変わらないコミュニケーションについて皆さんと考えていければと思います。

ここ数年、LLMによりソフトウェア開発の効率はかなり向上しました。そしてこれからもさらに向上し続けると思われます。
新機能実装や不具合修正、それに付随する調査などの効率が向上した結果、次にソフトウェアのリリースにおけるボトルネックになるのはどこでしょうか？
私は、品質保証のための自動テストがその一つであると考えています。

本セッションでは品質保証に必要な多数の自動テストを高速に実行する方法について、主に並列実行というアイデアに着目して考えていきます。
しかし一般に高効率な並列処理は難しいことが知られており、たとえば単にコア数の多いマシンを利用したり多数のマシンを同時に立ち上げるだけでは思ったほどの効果は得られません。
そこで、長らく研究されてきた並列計算一般に適用可能な諸概念の紹介および、それを踏まえた自動テスト特有の並列化事情についてお話しします。

"餅は餅屋"と言うけれど

実際、IT エンジニアのリソースは常に逼迫しており、急に"餅屋"の手が空くことはありません。
未経験の領域に踏み込むとき IT エンジニアはどこか「素人餅焼き職人」のようです。

そんな職人たちの中でも、あえて専門分野を一つに絞らず、様々な"餅"を焼いてきた「何でも屋」としての私の経験をお話しします。

就職に伴うプログラミングに始まり、開発チームがいなくなった Web アプリやデータ基盤の保守、認証基盤の導入や運用まで——。
こんな経験から見えてきた、専門性を深めるだけではない技術者の在り方を、一例としてご紹介します。

このセッションで話すこと

• 学び方の変遷：「レールを敷いてもらう」→「手探りで探索する」→「理解して地図を描く」→「改めて応用方法を模索する」という道のり
• 何でも屋の価値観：最適な手段はいつだって変わるし、その手段の可否を含めて学び続ける必要がある
• 生成 AI 時代の何でも屋：多様な基礎知識、初見への対応力、正しい情報を辿る能力が、AIツール活用時代に重要かもしれない
• 素人餅焼き職人という生き方：専門性を深めることと並行して、時々餅屋に頼りながら餅を焼き続ける、そんな生き方もある気がする、多分

そんな吸収と探求の話を、九州でさせてください。

AI Agent開発が急速に広まり、AI Agentはユーザーのサービス体験を支える重要なコンポーネントとなりました。LayerXでは直近で数千から数万のAI Agentを本番リリースする目標があり、急速に組織のあり方、基盤のあり方が変化しています。本発表では、組織の全てのエンジニアをAI Agent開発Readyにするための取り組みと、AI Agent開発基盤づくりの難しさ、それをどう突破するかについてお話しします。

組織づくりに関しては、開発に関わる全ての人間がAI Agentを理解し、それをサービスに組み込むマインドセットを育むことが必要です。仕組みづくりについては、今までのソフトウェア設計の上に基盤を構築するだけでは困難です。AI Agentのための認証認可の再設計、AI Agent評価のためのデータエンジニアリングなど、やるべきことがAIの進化とともに急速に増えています。そこで、本発表ではLayerXでの仕組みの再設計についてお話しし、大量のAI Agent開発を支える基盤に必要なものを取り上げ、皆様の組織でも再現性のあるノウハウとしてお伝えします。

具体的には次のトピックに触れます

• 全員をAI Agent開発Readyにする理由
• 全員をAI Agent開発Readyにするための取り組み
• AI Agent開発基盤は元のソフトウェア設計を根本から変える
  • AI Agentの為の認証認可を考え直す
  • AI Agent評価の為のデータの持ち方、扱い方を考え直す
  • LayerXで実際に行なっている仕組みづくり

これらの内容をテーマ「急（きゅう）」として発表します。
意味：急速な、緊急の
理由：AI技術の急速な発展と、それに対応するための急務な組織変革

皆様の各組織でAI Agent開発が加速する一助になると幸いです。

私は2024年の2月からWebKit（実際にはその中のJavaScript処理系であるJavaScriptCore）への貢献を開始し、1年後の2025年2月にレビュワーという最も強い権限を持つメンバーの一人になりました。
そして、2025年8月にはWebKitへの貢献が評価され、それに関連する職を手にいれることができました。

私はこれまで基本的に一人でWebKitへの貢献を行ってきました。
周りに質問できる人が全くいない中、コードベースへの理解はもちろん、独自の開発文化なども身につけながら、コミュニティからの信頼を得られるように努力してきました。

その中で「大規模なOSSに一人で立ち向かう」ためのアプローチが少しずつ見えてきました。

この発表では、WebKitのような大規模かつ技術的に複雑で歴史の長いOSSプロジェクトに一人で立ち向かい、技術的な理解を身につけながらコミュニティからある程度認められるようになるための方法について、なるべく再現性のあるアプローチについてお話しします。

昨今、AIブラウザと呼ばれる「AIエージェントによって操作されるブラウザ」の普及が急速に進んでいます。本発表では、自らAIブラウザを試作・実装することによって、以下の4点について確認していきます。

• エージェントAIの作りかたの再確認
• ブラウザ拡張の実装方法の現在地
• AIブラウザに固有の、原理的に回避困難なセキュリティ上の脆弱性
• AIブラウザなんて簡単だし、自分専用のものを作ってみることはとても楽しいし有効だということについて

想定聴衆

• AIエージェントや自動操作型AIの構造に関心を持つ人
• ブラウザ拡張に興味がある人
• 腹減ったでピザが届くことについて覚えている人

このプロポーザルは独自AIブラウザ拡張に作成したものを微修正しています https://gyazo.com/56257769a3f96128bdf147fb13421c49

概要

自由にアクセスできるHTTPサーバに対して、クライアントが自らの身の証を立てるのは難しいものです。IPアドレスは完全ではないですし、User-Agentヘッダはなりすましが容易です。

この問題を解決するため、10年以上の議論を経て去年勧告されたのがHTTP Message Signatures(RFC9421)です。

このセッションでは、本仕様をPerlで実装した経験を基に、実例を交えつつ本仕様を概説します。

また、本仕様の理解に必要で、今後生まれるHTTP仕様の理解の前提になることがが想定される、Structured Field Values for HTTP(RFC 9651)についても触れます。

想定聴衆

• AIボット、クロウラーなど、機械的に不特定多数のサーバにアクセスするクライアントを作成したい方
• 逆に、このようなクライアントからのアクセスを識別したいサーバ管理者の方

募集要項の冒頭にも書かれていたように、凄まじい変化の契機は急速に進化するAI技術でした。
最初はAIの面白チャットボットだったのものが、2022のCopilotのAIコーディングから始まり、今や、開発をサポートするだけにとどまらず、自走してコーディングするようになりました。そんな”AI”の旧と、急な進化の様子、そして現在地点を、時系列にわかりやすく説明します。もはやAIが当たり前になった今だからこそ、一度立ち止まって、どのように動いていて、どのような歴史があって、どのようになっていくのかということに思いを馳せる発表になっています。

はなすこと

• AI(特にLLM)についての仕組みや原理の説明
• 研究分野におけるAIコーディングの進化の説明
• これまでのAIコーディングツールとそれによる開発の変化
• これからのAI前提のコーディングの見通しの紹介

はなさないこと

• 特定のAIツールにおけるTips
• 最新のLLMの研究

技術情報のリアクションへの見方を考えます

2025年もプログラミングに関して様々な変化・発展がありました。
その最たるものは、AIエージェントによるコーディングが導入されたことであるというのはもう論を待たないでしょう。
Clineに全部賭けたくなったのも束の間、Cursor/Devin/Claude Codeなどなど百花繚乱のコーディングエージェントたちの新時代、我々プログラマもこれらコーディングエージェントをどれだけ使いこなすかが業務において重要なファクターになってきました。

コーディングエージェントに代表されるAIがコードを書くとき、その良し悪しは誰が決めるのでしょうか。
AIがコードを量産するおかげで人間がレビューする負荷が上がったという声もよく聞かれます。この意見には、暗黙のうちにコードの良し悪しを判断するのは人間であるという仮定が含まれていますが、この仮定は今後も置き続けてよいものなのでしょうか。

AI時代に良いコードと呼ばれるものはどんなものなのか、私はそのヒントがソフトウェア開発の歴史の中にあると考えています。
Perlの作者であるLarry Wallは元々は言語学を学んでおり、様々な言語での詩などにも深い知識を持っていました。彼はそういったバックグラウンドがPerlという言語の設計に影響を及ぼしたと言及しています。
プログラミング言語はたまたま機械が解釈できますが、言語である以上は人間が扱う言語の制約や可能性を受け継いでいます。生成AIの結果としてコーディングエージェントが出現したのも当然の成行きなのです。

本講演では、Perlをはじめとしてそこに強い影響を受けたRubyや、さらに先達であるLispやSchemeなど様々なプログラミング言語を取り上げながら、AI時代である現代において「良いコード」とはどんなものなのかを考察し、私の考えを示します。

新卒Webエンジニアです。大学院卒業までは機械学習を専門としていました。

私は、入社後の5か月間、『とりあえずやってみる』を指針として、社内勉強会への参加、社内コンペでの発表、社外同期とのハッカソン参加、初のCTF、社外LT登壇、テックブログ執筆など、さまざまなことに挑戦してきました。

何かを『やってみたい』と思ったときに、『もう少し勉強してからにしようかな...』や『チームメンバーに迷惑をかけてしまいそうだからな...』などといった気持ちがブレーキになることってありませんか？
本トークでは、完璧主義者の自分や心配性な自分を脇に置き、『興味を持っている自分』を最優先して行動することの価値について共有します。

〈コンテンツ〉

• 『興味を持っている自分』を優先しないともったいない！という話
• 入社後の5か月間で私が挑戦してきたことについて
• 本トーク応募からYAPC当日までの約2か月間で取り組んだこと
• 新しいことに挑戦するときに、意識していることについて

新卒1年目の挑戦を共有することで、会場の皆さんにも『自分もやってみよう』と思うきっかけをお届けできればと考えています。

ちなみに、こちらに応募したのも挑戦の一つです。11/15, 16に初めてのデザフェス出展を控えていて、『初日だけの参加なんてありなのか？このスケジュールをこなせるだろうか？』と思いながら、この文章を書きました。

本当です。そしてこの事は、2025年現代のプログラミング環境において意外で根強い影響をあちこちに及ぼしています。本Talkではその証拠を提示した上で、なぜそうだったのか、その結果どうなったかを論じます。

• 証拠 - Proof
  • 語彙 - Vocaburary
  • "use strict";
• 理由 - Reason
  • Y'all can pop it. but can you shift it?
• 影響 - Consequence
  • typeof null === "object"
  • "🐫".length !== ["🐫"].length
• 結論 - Conclusion
  • Why Javascript matters -- and Perl doesn't (so much)
  • It sucks? Then why are you suckin' it?
  • Q&A

Coding Agentの登場により、「このタスク、AIで一気に終わるかも」と感じる場面が増えました。ところが実際には、

• 仕様を盛り込みすぎて泥沼化した
• AIの失敗を人力で修復して余計に時間がかかった
• 新規プロジェクトと既存プロジェクトでの成果がまるで違った
  といった落とし穴にはまった方も多いのではないでしょうか。

このトークでは発表者がCoding Agentを過信して見積もりが崩壊した事例を共有し、「AIが導入する新たな不確実性をどう見積もりに織り込むか」を考察します。まだ試行錯誤中ではありますが、実務に応用できる視点や工夫を提案します。

概要

「このPRだれかレビューして〜！」という日常的な課題を開発ボトルネックとして捉え、レビュワーをランダムにアサインしと定期リマインドするツールharuotsu/slack-review-notifyを開発・運用しました。

開発速度の「急激な」向上に伴い、ボトルネックが日々移り変わる現代の開発現場。
YAPC::Fukuoka 2025のテーマ「きゅう」に込められた「現在地を示す」という意味で、この1つのOSS開発を通じて新卒2年目の若手エンジニアとして見えてきた「現在地の変動」に対してどうアプローチし、自身・チームが未来の当たり前とのギャップを埋めていくための歩き方をお話しします。

技術実装・設計プロセスの詳細はもちろんのこと、個別問題解決から構造的解決への転換やそこから見えてくる、チーム内の当たり前を加速する知見を掘り下げます。

発表内容

• 失敗から学んだWebhook処理とSlack API連携の実装パターン
• 開発効率を最大化する通知システムの設計
• レバレッジの効く横断的開発による価値創出のための思考転換に伴うDB再設計の道のり
• チーム課題を個別解決から構造的解決への転換
• 1つのプロジェクトから複数の学びをチーム・業界に昇華する動き
• 変動し続けるエンジニアリングの「現在地」と未来の当たり前とのギャップを埋め続けるための歩き方

伝えたいこと

あなたの「現在地」はどこですか？そして、「きゅう」に対してどう歩んでいきますか？

この発表では、技術的なノウハウはもちろん、変わりゆく業界の中の当たり前に対して、チーム・社内とのギャップを埋め続けていくための歩き方をお話しします。
私が悩みながら歩んだ設計と思考プロセスをお持ち帰りいただき、自身のチームの課題解決をする際の一手となれば幸いです。

概要

OpenTelemetryとは、メトリックやトレースといったテレメトリーデータの生成・投稿を、ベンダーの違いを超えて標準化するオブザーバビリティフレームワーク・ツールキットです。

このプロジェクトの一つとして、テレメトリーの受信・処理・投稿を担うOpenTelemetry Collector（以後 OTel Collector）というエージェントツールがあります。OTel Collectorはユーザーが複数のコンポーネントを組み合わせて動作させられる仕組みになっています。コンポーネントは自作したり、自作したものをライブラリとして配布したりできます。例えば、私はIoT製品のAPIを呼ぶReceiverを自作し、これを組み込んだOTel Collectorを常駐させることにより、IoT製品が電池切れしていないかを継続的に監視する仕組みを構築しています。

このハンズオンでは、OTel CollectorのうちReceiverと呼ばれる種類のコンポーネントを自作し、さらに、これを組み込んだOTel Collectorのバイナリをビルドし動かしてみることを目標とします。OTel Collectorコンポーネント開発の知識だけでなく、利用者として既存のコンポーネントのコードを読むときや、Collectorカスタムビルド時に役立つ知識も得られます。

思い思いのOTel Collector Receiverを自作して、お土産に持ち帰りませんか？

必要なもの

• PC (OS: macOS / Linux)
  • Windowsでもできなくないと思いますがトラブル時にサポートできません
• Go 1.24以上の開発環境
• （任意）どんなReceiverを作ろうかというアイデア

deckはk1LoWさんが開発された、MarkdownからGoogleスライドを継続的に作成するための非常に優れたOSSであり、Goで書かれています。

筆者は、7月からこのツールを使い始めると同時に、その後の数ヶ月で多くの改善提案及びpull requestを行いました。コード行数にすると1万行以上に及びます。最終的にはコア開発者にも加えてもらいました。

deckを使いやすくするための数多くの変更をおこないましたが、中でも特筆すべきはそのパフォーマンス向上でしょう。10分以上かかっていたスライド生成が10秒以内で完了するようになったケースもあり、実に100倍以上の高速化を達成しています。

これらは、良く言われる「計測」で達成できた部分もありますが、実際にはTidy First的に仕様やコードの整理整頓をする中で自然と速くなったもの、その過程で高速化のアイデアが湧いて実現できた物も少なくありません。その過程で作者のk1LoWさんとも議論を重ねることもありました。それらの段階的な改善が、結果的に劇的なパフォーマンス向上に繋がったのです。

本トークでは、実際のdeckの高速化の旅路を具体的事例にとり、OSSやソフトウェア開発におけるパフォーマンスチューニングの秘訣についてお話します。

Web アプリケーションでマイクロサービス間通信に gRPC を採用するケースが増えています。

長年開発・運用されている、とある SaaS プロダクトでは、当初 Ruby で .proto ファイルから gRPC クライアントを生成する際、標準的な protoc コマンドベースの grpc_tools_ruby_protoc gem を使用し、生成手順を Makefile で管理していました。

しかし、システムの成長とともに複数の gRPC クライアント生成を管理する必要が生じ、Makefile が肥大化・複雑化し、新規追加・メンテナンスが困難になりました。
この課題を解決するため、YAML ベースで proto ファイル間の依存関係を管理できる Buf を導入し、より効率的かつ簡潔な gRPC クライアント管理を実現しました。

また、Ruby で生成されるコードの依存関係記述が Ruby on Rails のオートロードと相性が悪く、シェルスクリプトのワンライナーを使用していました。こちらをメンテナンス性向上のため Ruby の Rake タスクに変換するなどの運用改善も行いました。

本セッションでは、従来の protoc コマンドベースの管理から Buf への移行プロセスを実体験に基づいて紹介します。
移行時の互換性担保やチーム運用面での工夫、導入後の効果について具体的な事例とともにお話しします。

Buf について知り、proto ファイルからのコード生成における新たな選択肢を探求してみませんか？

アウトプットすることの意義が唱えられて久しいですが、LLMを用いたAIサービス・AIエージェントが台頭している現在においてヒト自身が知見や考えをアウトプットすることはどんな意味を持つのでしょうか。

わたしはClassi開発者ブログという企業組織が運営するブログの編集部長を務めています。また、ひとリのブログ・Web日記愛好家でもあります。

Classi開発者ブログは活動方針としてPVなどではなく執筆者のUU数・アウトプットの質を目標にしています。これは編集部長としてのわたしが強く打ち出したもので「アウトプットがヒトを豊かにする」という哲学を反映したものです。
執筆者は開発組織のおよそ3割近くになり、月数記事以上のペースを3年近く保っており、この哲学に共感する仲間を増やせたという自負があります。

しかしAIによる情報の収集・出力が圧倒的に効率化されている今、ヒトが時間や労力をかけてアウトプットする意義とは何なのでしょうか？
また、アウトプットを継続するためにどんな工夫や効率化を図るべきでしょうか？あるいはどんなことを避けるべきでしょうか？

執筆者やネタの発掘作業、レビュー・校正のワークフロー、目標の立て方と血の通わせ方について具体例を交えてお話しします。
またぜひ懇親会やSNSで「こういう取り組みをしているよ」「こう考えているよ」という情報が飛び交うきっかけとなる話をしたいと考えています。

ここ数年、来るべきクッキーレス時代に備え、デジタルマーケティング分野に関わるエンジニア達は人知れず戦ってきました。現役の広告エンジニアである筆者もその最前線に身を投じた一人です。しかし、 2025 年 4 月、 Google は 3rd party cookie の廃止を事実上断念し、その壮大な挑戦は突如として大きな転換点を迎えます。

このトークは、その激動の渦中に生まれた Attribution Reporting API (ARA) という技術へ捧げる、筆者からの鎮魂歌です。

ARAは、プライバシーを守るという理想が生んだ、あまりにも複雑で難解な人工遺物です。しかし、その複雑さの奥には、最先端の Google エンジニア達による知恵と格闘の跡が刻まれています。このトークでは、2024 年 1 月のプロジェクト発足以来 1 年以上 Attribution Reporting API (ARA) の実装に携わった筆者が、 ARA の仕様を読み解くために必要な知識を短時間で効率よく収集することを目標に、以下のキーワードを解説します。

• Attribution Reporting API (ARA)
• registration
• attribution source/trigger
• source type event/navigation
• event-level/aggregatable&summary report
• Publishser / Advertiser / Adtech / Browser
• contribution budget
• ノイズと差分プライバシー
• Aggregation Service と TEE