はじめに
タイミーの神山です。 11/14-15 で福岡工業大学で開催された YAPC::Fukuoka 2025 に参加してきました。
私は当日のボランティアスタッフとして参加しつつ、いくつかのセッションを拝見したので、印象に残ったものをレポートという形でまとめます。
なお、タイミーには世界中で開催されている全ての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、私はこれを使って参加しました。詳しくはリンクをご覧ください。
スタッフ業の様子
クロージング！ スタッフのみなさんありがとう！#yapcjapan_memorial pic.twitter.com/ijwyjMN6Nc
— 坂井 恵(SAKAI Kei) (@sakaik) 2025年11月14日
はっ！941さん！大吉祥寺PMで『当日スタッフやりなよ、YAPC募集してるよ」って言われてその場で申し込んで今やってて！
— 941 / kushii (@941) 2025年11月15日
という方がいて、なんかいいことした気分。ちなみにスタッフの感想は「楽しいし、スタッフの尊さを知りました」とのこと。いいね。#yapcjapan pic.twitter.com/sio1TmuszK
今回 YAPC に参加しようと思ったのは、大吉祥寺.pm に参加して皆さんが YAPC はいいぞと言っており、興味を持ったことがきっかけです。 また、株式会社カケハシの 941 さんに「YAPC の当日スタッフとして参加してみたら？」と言ってもらったので、その場で申し込んで行くことが決定しました。 カンファレンスのスタッフ業、大変ですね。当日幾つも想定外のことが起きつつも柔軟に対応される皆さんすごいなあと思いました。（僕も色々とお手伝いさせてもらいました）今ではカンファレンススタッフへのリスペクトと感謝に溢れています。
また、弊社 DRE の chanyou さんがまさかのスタッフとして参加されており、初対面するというイベントもありました。色々ありましたが、初のスタッフ業楽しかったし気付きが多かったですね。参加して良かったです。
セッションの内容
なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える
インフラコードのモジュール化はなぜ難しいのか、インフラコードにおける問題点とアプリケーションコードとの対比を交えたセッションでした。
インフラコードとアプリケーションコードの性質は異なります。インフラコードだと”状態を記述”するので、個々の状態、つまり実装の詳細が関心事になる。 アプリケーションコードだと”処理を記述”するので、処理が何をもたらすか、つまり結果としての振る舞いが関心事になる。 従って、アプリケーションコードは処理自体のロジックをカプセル化して、抽象化が可能。 一方、インフラコードだと内部構造の可視性が必要なので、無理にカプセル化すると、理解が困難になってしまう。階層が多段 x モジュール化が問題をさらに困難なものにするという話もありましたね。 そもそも、モジュール化せずに書き下したり、論理的凝集ではなく機能的凝集を意識して、ディレクトリ・ファイル分割、モジュール機能を利用しようという結論でした。
自分はアプリケーションを書くことがほとんどなので、インフラコードとアプリケーションコードの違いに関して強く意識をしたことはありませんでした。アプリケーションコードなら当たり前に考える抽象化という考え方が、インフラコードだと一筋縄ではいかないという話を聞いて、新しい観点を得られた気がします。
「“状態の記述”と”処理の記述”はメンタルモデルが違うので、前者はホワイトボックス的、後者はブラックボックス的になる」という話だと認識しましたが、アプリケーションを書いている身からすると、テストコードは”状態の記述”のメンタルモデルが近いと思います。
テストコードは過度に抽象化しないというプラクティスもまさにそうだなと。テストが失敗した時に抽象化されていると、書き下されている場合に比べて原因のトレースが難しいですよね。 セッションスライドに、ソフトウェア設計の結合とバランスの書籍の紹介がありましたね。統合強度の観点でもお話をされており、興味深かったです。 新しい観点を得られた素晴らしいセッションでした。
Amazon ECSデプロイツールecspressoの開発を支える「正しい抽象化」の探求
普段何気なく使っている ecspresso の成り立ちや設計思想を知れたセッションでした。
ECS を管理できる IaC ツールを比較しながら、設計の違いに焦点を当て、https://github.com/kayac/ecspresso の設計思想を明らかにする構成でした。
https://github.com/kayac/ecspresso は、責任分界点を明確にして”どこで切るか”が設計思想になっている。ECS 以外の AWS マネージドらを相手にせず、ECS のみにフォーカス。操作自体は抽象化（ ecspresso deploy など）し、構造は抽象化しない。
セッション内で、https://github.com/aws/copilot-cliというツールに言及がされていました。Copilot CLI は処理だけでなく、構造まで抽象化して提供しているとのこと。つまり、インフラ構成の定義が DSL ということです。インフラ定義を簡単に記述できるようにした DSL は、現実のアプリケーションが必要とする複雑さをカバーしきれない。DSL を運用し続けるのは骨が折れそうですよね。特に AWS API の変更や追加があったときは、それを抽象化して提供しないといけないわけですから、抽象 I/F をその都度考えないといけないわけです。Copilot CLI は ECS の複数 LB 対応をしておらず、現在は事実上メンテナンスモードになっているとのこと。 Copilot CLI がサポートしていない機能は CloudFormation テンプレートで書き下すしかなく、結局具象を使わざるを得ない状況に。この現象を “現実世界のアプリケーションを相手にすると抽象が破れて具象が漏れてくる” と表現されていました。
このセッションは、「なぜインフラコードのモジュール化が難しいのか」のセッションとも通ずるところがありました。 インフラコードは“状態の記述”をするもので、実装の詳細が関心事になるという話でしたが、まさにその内容がそのまま具体例として言及されているようだなと。Copilot CLI は構造を抽象化して提供しているがあまり、内部的には変更容易性を担保しづらい状態だったのかもしれませんね。
“状態を記述”する類のコードは、安易に抽象化しない方が良い、抽象化する範囲は慎重に考えた方が良いなと。前のセッションの内容と合わせて2倍楽しめる内容でした。
なぜThrottleではなくDebounceだったのか？ 700並列リクエストと戦うサーバーサイド実装のすべて
CloudBees さんで700並列リクエストを捌くために Debounce の手法を使ってサーバーサイドで処理をする実装の紹介でした。
CloudBees さんでは、CI/CD プラットフォームを提供しており、テスト結果を集めて AI を使ってさまざまな処理（以下、Close 処理）をしているとのことです。その際に700並列の分散テスト実行結果が大量に送られてくるので、Close 処理をある程度まとめて実行したいが、実行が終わったかどうかを判定するのが難しく、いい感じにデータが溜まった後に Close 処理する必要があったとのこと。なので、Close 処理を最適なタイミングでまとめて実行する仕組みが必要だった。
処理回数を間引くには、n秒に1回処理の Throttle と、待ち時間内に次のイベントが発生するとタイマーがリセットされ、処理の実行が遅延する Debounce があります。Debounce の例で言うと、Google の入力サジェストがあります。 YAPC という文字を1文字ずつ入力するたびに、サジェスト結果を返すのではなく、1文字ずつ入力するごとに処理時間が Delay して、最終的に C が入力されて次の入力がなくなったタイミングでサジェスト結果を返すようにするような手法です。今回は、ほぼ同時に大量のリクエストが送られてくるが、タイミングには振り幅があるので、決まった間隔の Throttle 処理ではなく、Debounce が良さそうだったとのこと。
基本的なロジックとしては、リクエストがあった時点で UUID を生成して Redis に格納し、nmb秒待って UUID を取得して照合し、同じ値なら実行する。他のリクエストがあったら、UUID が書き換わるので最初のリクエストは UUID 照合時に弾かれて何も実行されないというものです。 Race Condition への対応含め興味深く聞かせてもらいました。Redis の SET コマンドに、GET オプションなんてあるんですね、知らなかった。
前職では、フロントエンドでサジェスト機能を作った際に Debounce のロジックを使って実現したことがあり、Debounce 自体の存在は知ってはいたものの、サーバーサイドのリクエスト負荷軽減の文脈で理解していたので、サーバーサイドのロジックそのものに適用するという視点は目から鱗でした。
Agentに至る道 〜なぜLLMは自動でコードを書けるようになったのか〜
普段何気なく使っている AI Agent の成り立ちがざっくりわかるセッションでした。
Transformer ⇒ GPT ⇒ InstructGPT の流れで一発勝負の生成ができるところから、ReAct 論文の登場。生成してダメだったら何がダメだったのか考えて再生成という、人間の営みに近い動きを実現。Reason と Act のループを回せるように ReAct。これが自律的に判断し行動する AI エージェントの基礎に。言論文から学ぶ生成 AI を積読しているのでこれを機に読もうかなと思いました。
Stay Hacker 〜九州で生まれ、Perlに出会い、コミュニティで育つ〜
pyamaさんのキーノート、とても良かったです。生成 AI 時代に変わっているのは手段であって、自分の手でよくしたいという目的は変わってない。進化しながら Hack し続けるという話が印象的でした。いい課題を見つける、研鑽、事例から学ぶ。これからの自分がどうありたいかについて深く考えさせられました。
コミュニティの話も良かったです。自分の手で世界、社会、個人、技術を少しだけよくしようとする人たちの「熱」を感じられる。そこには言語の壁や、役職、職種でもない、”Hacker” としてのあり方があると。個人的にはコミュニティの体験がより Hack を楽しく加速させると感じています。
自分も楽しく Hack し続けたいですね。とても奮い立たせられる内容でした。
まとめ
改めて、福岡という場所は最高だなと思いました。アクセス抜群、食べ物も美味しい。福岡といったら独楽蔵という日本酒がありまして、燗酒でいただきました。良かったですね。 来年は東京ビッグサイト開催です！来年もまた参加したいですね。
