はてなアンテナは登録したURLの更新情報を定期的に取得し、更新内容をまとめるウェブサイト巡回サービスです。
サービス開始以来20年を越えたはてなアンテナでは、Perlで書かれたコードベースの置き換えを進めています。
最初の一手として、数百万件のページを効率よく巡回するクローラをGoで書き直しました。クローラをゼロからつくる中でおこなった実装の選択や、既存のクローラからの移行および運用、既存のバックエンドとのコミュニケーションなど、プロダクトを漸進的に新しくしている過程についてお話しします。

以下のような内容について話す予定です。

• モチベーション: PerlからGoへ
• 実装編
  • ストレージの選定
  • キューの実装
  • producer-consumer パターン
  • http.Transport
• 運用編
  • カナリアリリースと移行戦略
  • ローカル開発
  • テスト
  • 旧バックエンドとのコミュニケーション
  • 中間証明書の問題
  • 健全性の監視

皆さんもクレジットカードを使った際に、身に覚えのない決済が来て、不正に利用されてしまっていたという経験があるのではないでしょうか？
不正といっても、クレジットマスターアタック、スキミングといった外部からの攻撃、カード所有者による悪意のある決済など、多岐に渡り不正決済は年々増加しています。

本トークではカード事業者が不正を防止するために日々行っている攻撃の検知、分析、対策、評価といった一連の運用やそれらを支えるシステムの開発をどのように行っているかを技術的な文脈を元にお話しします。

具体的には以下のような内容をお話しする予定です。

• カード決済における代表的な攻撃とそのパターン検知、および対策をどうやっているか
• 不正決済を検知し防止、抑制するためのシステムをどのように構築しているか
• 不正対策を行っているチームの日常、どのようなKPIを設定して攻撃の予防や改善を行なっているか

本トークを聞くことで、皆さんのカード決済が安心に行えている一旦が垣間見れるかもしれません。

「チーム内のコミュニケーションをシミュレーションしてみたい」みなさん一度は思ったことがあるのではないでしょうか？
昨今見かけるAI Agentでチームを組んで協働させるアプローチに着想を得て、あえて口論をさせてチームが破綻していく様子をシミュレーションできるのではないか？と思ったことをきっかけに、このシステムを実装してみました。

• パワハラをする上司
• 反抗的な部下
• 事なかれ主義の部下
• 派閥を作ろうとする部下
  現実世界で起こり得ることをシミュレートしてみることで、どうなったかを発表します。（動画にて実際のシミュレーションをお見せする予定です。）

また、より人間的な動きを再現するために、Peer to PeerでAI Agentがコミュニケーションできる仕組みを整えました。
AI Agentに相互にコミュニケーションをさせることは一見単純そうに見えて、"キュー"を活用したファンアウトの制御やAgentのメモリ設計など、意外と複雑でいくつかの課題を乗り越える必要がありました。
このアプリケーションではMastra、Vercel、Inngestを使い、どのようにPeer to Peerのコミュニケーションを実現したのかについてもご紹介します。

タイパや効率が最優先されがちな現代ですが、あえて正解までの最短コースだけを目指さず、道のりそのものを味わうプログラミングの楽しみ方を探求し、共有します。
題材の一つとして、毎年12月に小さなパズル問題が毎日出題される「Advent of Code」を紹介します。同じ問題に対しても解法は無数にあり、用いるプログラミング言語もアルゴリズムも様々、まさにTMTOWTDI！ 素朴にコードを書いて正解を導出して終わりにするのではなく、美しく効率的なコードを目指してみたり、業務では絶対に書かないような難解で突飛なものを考えたり、色々な楽しみ方があります。正解とは関係なくパズル入力の可視化に注力している参加者もいて、他の人の取り組みを見るだけでも学びがあり、とても面白く刺激的です。
また、私は個人の趣味活動としても「Pentomino」や「だんご屋のひまつぶし」といったパズルを自ら題材として取り上げ、プログラムで解く取り組みをしてきました。効率的な解法を調査し検証し、また得られた解をWebブラウザ上でインタラクティブに可視化するなど、自分なりのこだわりを持ったやり方で楽しみました。正解だけを求めて一直線で終わらせないからこそ得られた経験や学びを紹介します。
「コードはAIに書かせるもの」になりつつある現在ですが、やっぱり自分でコードを書くのは楽しいものです。自分流のプログラミングの楽しみ方を広げるためのヒントを持ち帰っていただき、“自分も何かやってみよう”という最初の一歩を後押ししたいと思います。

ある日突然、あるサービスに急（きゅう）なスパイクアクセスがやってきました。その数、700並列。サーバーは悲鳴をあげ、DBは沈黙しました。

高負荷対策の定石といえば、キュー (Job Queue) を思い浮かべるかもしれません。しかし、安易にジョブを Queue に入れるだけでは、結局700並列の重い処理が非同期に実行されるだけ。そこから、いかにして本当に必要な処理だけを「間引く」かが本当の課題でした。

こうした処理の間引きには、一般的にスロットル (Throttle) が用いられます。では、なぜその一般的な手法である Throttle ではダメだったのか？ 本トークでは、似て非なる Throttle とデバウンス (Debounce) の違いを解説しつつ、サーバーサイドでの Debounce 実装に至るまでの道のりを赤裸々にお話しします。

単純な実装だったv1から、その改良版であるv2ですら対応できなかった現実の複雑なユースケース、そして最終的にたどり着いた動的な遅延制御ロジック(v3)まで――3度の再実装の過程を、v1からv3へと進化していく実際のコードを追いながら、その思考と共に解説します。

この実例で語る負荷制御の勘所と設計思想が、あなたの武器庫に加わる新たな一つになれば幸いです。

大規模なモバイルアプリやWebサービスの開発現場では、UI・バックエンド・複数マイクロサービス間の依存関係が複雑化し、機能追加や保守時の影響範囲把握が大きな課題となります。

本発表では、AI技術を活用して画面設計データやコードベースから依存関係を自動抽出・可視化し、エンジニアやPMが短時間で全体像を把握できるナレッジ基盤の開発事例を紹介します。

PoC開発を通じて直面した技術的・組織的な壁や、現場での実践から得られた工夫・知見、今後の展望についても具体的にお話しします。大規模サービスの開発・運用に携わる方や、依存管理・ナレッジ共有に課題を感じている方に役立つ内容です。

2025年6月、Cursor Meetup Tokyoを主催し、現地350名・オンライン5,800名、計6,000人規模の技術イベントを運営しました。
当初は100人規模を想定していたものの、SNSでの「Build in Public」型プロモーションやコミュニティの盛り上がりにより、想定を大きく上回る参加者が集まりました。

本発表では、受付オペレーション（1人40秒×4レーン）、Google Meetの1,000人上限をYouTube Live＋StreamYardで乗り越えた配信設計、イベントページのサーバーダウンやトラブル対応、現地誘導や会場設営の工夫、SNS活用による参加者拡大など、現場で得た具体的なノウハウと課題解決のプロセスを余すところなく共有します。
大規模イベント運営が未経験の方にも再現性のある実践知を提供し、コミュニティ運営や技術イベントの未来像についても考察します

ソフトウェアエンジニアとして、常に「エンジニアとしてどう事業に貢献していくか」を考え続けてきました。技術力を磨くことだけでなく、その技術をどう事業価値に変換するか。この問いに向き合い続けた結果、私は「半歩越境」という独自のキャリア戦略にたどり着きました。

エンジニアでありながら：

• プロダクトマネジメントの視点を持つ
• ビジネス戦略の基礎を理解する
• デザインやUXの原則を知る
• マーケティングの基本を押さえる

これは「フルスタック」とも「ジェネラリスト」とも異なります。あくまでエンジニアリングという軸足は動かさず、必要に応じて隣接領域の「共通言語」を獲得していくスタイルです。

生成AIの登場により、ソフトウェアエンジニアの役割は大きく変わり始めています。

従来のエンジニア像

• コードを書くことが主な価値
• 技術的な深さが競争優位性
• スペシャリストが有利

AI時代のエンジニア像

• AIを活用して事業価値を創出することが主な価値
• 技術と事業の橋渡しができることが競争優位性
• 複数の視点を持つ人材が有利

正直に言えば、私のようなキャリアは長らく「器用貧乏」と呼ばれ、キャリアとしては不利だと考えられてきました。深い専門性を持つスペシャリストと比べて、市場価値が低いとされることも多かったのです。

しかし、生成AIの登場により状況は一変しました。AIが基本的なコーディングを担当できるようになった今、求められるのは：

• AIに適切な指示を出せる広い知識
• 複数の領域を横断的に理解できる視野
• 技術的な実装と事業インパクトを結びつける能力

まさに「半歩越境」してきた経験が、強みとして活きる時代になったのかなと思っています。

また、飲食店を経営する経験もしっかりエンジニアリングに生きているのでそういった話をしていきます。

JSer.info・textlint・jsprimerというプロジェクトを通じて、私は「書くことは読むことである」という理解に辿り着きました。
この発表では、興味本位で始めた日々の情報収集がツール開発を経て大規模プロジェクトの設計技術へ発展するプロセス、
読む→書く→伝えるの段階的変化についてお話しします。

まず「読む技術」として、JavaScriptの情報サイトであるJSer.info（14年間で750記事）の更新を支える情報収集システムを紹介します。

• 参考: https://jser.info/2021/01/16/jser-10th/

次に「書く技術」として、読むだけでは物足りず「書いてみよう」と思った経験から始ったPromise本執筆時の表記揺れ問題をきっかけに作った、textlintについて紹介します。
書くことで増える読む量や、AI時代における文章品質の自動化の進化についても、textlintのMCP対応のデモも交えて紹介します。

• 参考: https://efcl.info/2022/06/29/why-create-textlint/

最後に「伝える技術」として、jsprimer という JavaScript 入門書を継続開発する際の文章設計について紹介します。
Design Doc による文章の設計、Living Standard アプローチ、既知→未知の原則、書きやすさより読みやすさを優先する設計思想などを扱います。
また、オープンソースとして100人以上がコントリビューターと参加してもらった仕組みやGitHub Sponsors/Open Collectiveによる経済も触れます。

• 参考: https://efcl.info/2025/05/24/tskaigi-2025-jsprimer/

大規模なプロダクトでは、lintや、use漏れチェック、使ってないファイルの検出といった、静的解析を伴う開発支援ツールが重宝されます。
しかし、存在するすべての記法を扱う必要のある汎用ツールでは、どうしても実行時間が伸びてしまったり、プロジェクト固有のかゆいところに手が届きにくかったり、といった課題がつきものです。
発表者が携わる、開発期間約10年・数十万行規模のリポジトリでは、近年注目されている"vibe coding"の考えを下敷きに、プロジェクト専用の軽量なツールを開発して、開発支援に活用しています。
本発表では、プロジェクト固有の静的解析ツールをAIとともに開発し、レガシーコード改善に活用する「バイブス静的解析」を提唱します。

静的解析を用いたツールのこれまで

• PPI, PPRを使った汎用ツールのおさらい
• 汎用的がゆえに、いかなるソースコードも正しく解釈しなければならない宿命
• ツールの実行時間増加への利用者側の工夫

バイブス静的解析のアプローチ

• プロジェクトに合わせた専用の静的解析ツールを「バイブス」重視、すなわち、勢いで開発する
• 完璧を目指さず、コードベース上で必要な表現だけに対応する
• AIの力を借りて、誰でも保守でき、壊れても機能開発の片手間に短時間で直せるものを目指す

ゴール

• 「バイブス静的解析」の考えを使って、新たなツールを勢い重視で開発できるようになる
• お手元のリポジトリから、数秒以内にuse漏れや不要ファイルといったエラーを検出できるようになる

私はあるスタートアップ企業で業界特化型のSaaSをRuby on Railsで開発しています。そのSaaSには店舗に予約する機能があり、当初はシンプルな空き枠計算ロジックだったのですが、創業3年目に顧客ニーズに応えるため、より複雑なロジックが必要となりました。動的計画法などを用いることでニーズを満たす機能は作れましたが、そのままでは十分な速度が出ませんでした。

「マルチスレッド化すれば良いのでは？」と考えましたが、そこでRuby（CRuby）にはGVL（Global VM Lock）がある事を知りました。新しいロジックは、複雑な組み合わせを計算するCPUバウンドな処理であったため、マルチスレッド化してもGVLの制約により速度改善は期待できないと分かりました。

本セッションでは、私たちが直面したCPUバウンドな処理の問題とそれをどう解決したのかについてお話しします。Webアプリケーションは一般的にI/Oバウンドと言われますが、急に特定の機能でCPUバウンドな処理が必要になるかもしれません。同様の課題に直面した際の参考になれば幸いです。

最近、大規模言語モデル（LLM）が急速に普及していますが、すべての分野でLLMが万能というわけではありません。例えば、金融やセキュリティといった高い信頼性が求められる業界では、回帰やブースティング系の "古典的な" 機械学習の技術が、今なお第一線で活躍しています。

その理由は、旧来の機械学習では「この取引は不正利用の可能性が80%」といったように確率を使って物事を予測したり、「なぜそのように予測値が出たのか」という理由を人間が理解しやすい形で説明できる点にあります。身近な例では、金融での与信スコアリングやカード決済や送金等の不正利用の検知などの "予測タスク" に機械学習が今でも使われています。

このトークでは、機械学習のユニークなポイントと私が機械学習を好きな理由について、過去に熱中して作っていた "競馬" を題材にお伝えします。勘や経験則、あるいは人間が地道に作るルールだけでなく、機械学習という道具を手に入れると、競馬の収支を改善するためにどのようなアプローチが可能になるのか？ 最近話題のLLMに尋ねるのとは、何が違うのか？私の過去の実践経験を元に、詳しく説明します。

機械学習について初めて知る人でも楽しめるよう、以下の流れでお話しする予定です。

• 機械学習の基本
  • 機械学習とは何か？特に教師あり学習について
  • 機械学習が使われている分野
  • 機械学習の利点と欠点
  • 機械学習のシステム構築の流れ
  • 最近の機械学習の潮流
• 競馬と機械学習
  • 競馬の簡単な紹介
  • 競馬に適した機械学習手法の紹介
• 競馬の勝ち馬予測モデルの作り方
  • 予測の元になるデータを集める
  • 予測の精度を高めるための特徴量エンジニアリング
  • 予測モデルの構築方法と評価手法
• 勝ち馬予測モデルの実践
  • 予測値の活用方法
  • 実戦での評価検証

いかにして速いWebフレームワークを作るかのテクニカルな話をします。JavaScriptランタイムで動くバックエンドWebフレームワークです。Honoを例に挙げます。

• 対象ランタイム - Cloudflare Workers / Deno / Bun / Node.js
• HonoはAOTを使わない実用的なフレームワークでは一番速い
• サーバーを立ち上げないベンチマーク
• 立ち上げるベンチマーク
• ベンチマークソフト - abを使わない
• 何もしないのが一番速い
• ランタイムの実装によって速度が異なる
• awaitすると遅い？
• JSONのパースを速くするには？
• Perlの知恵
• TrieRouterが遅くてRegExpRouterが速い理由
• 5つのルーターと3つのプリセット
• 小さいは速い
• クエリパーサを書く
• GitHub Actionsで継続的に速度を測る
• 一番最後に一度だけインスタンスを作る
• Node.jsアダプタの挑戦 - 2.7倍速くする
• AOT最適化
• 速いとは何か？

生成AIでのコーディングが当たり前になってきて、
一番楽しいところをもっていくんかい！と思っているソフトウェアエンジニアの方も多いと思います。

私自身、かつてはコードを書くことが一番好きなソフトウェアエンジニアでした。(今も好きです)
15年のエンジニアのキャリアの中で、コードを書く以外にもプロダクトをユーザーに届けるためにさまざまなことをやってきました。
顧客先データセンターでヘルメットをかぶり一人きりでPoCをしたり、トイレの屋根裏にラズパイを設置したり、
工場の録音データを1日中聞いていて頭おかしくなりそうになったり、目の前の問題を解決するために何でもやってきました。
また、自身が企画・開発提案の中心だった1億円以上かけたプロダクトが一つも売れなかった経験もしてきました。

時にはもっとコードを書きたいと思うことも。
その欲のままにコードばかり書いていると、もっと他の課題に取り組むべきでは？という気持ちになることもあります。
さらに、なんでもやってきたからこそ、自分でも器用貧乏だなあ、得意なことってなんだっけと思うこともあります。

「これってエンジニアの仕事なんだっけ？」と思ったこともたくさんありました。
課題を前に進めるため、あるいは、問題を解決するために、役割の境界を越えてなんでもやるうちに、
曖昧な状況でもとりあえずやってみる力が身につき、今ではそれがエンジニアリングの幅やエンジニアとしての考え方を広げる結果にもなりました。

本トークでは、「なんでもやる」ことで広がったことと成長できたこと、
そしてそれが現在にどのようにつながったかをN1の具体的な経験をもとにお話します。
エンジニアとしてのキャリアに悩んでいる方に改めて考えるきっかけになると嬉しいです。

急に「この開発、いつできる？」と聞かれることがあります。
仕様はまだ固まっていない。 決めないと見積もれないのに、決める時間もないし、そもそも決めきれるものでもない。 根拠の薄い数字を出せば後で現場が苦しくなり、「分かりません」と返せば会話が止まってしまう。 そんな状況は多くの人が経験しているのではないでしょうか。

私も何度もこの問いに直面してきました。 その中で実践してきたのは、適当な数字でもなく、過度なバッファでもなく、現場として納得できる見積もりとスケジュールを素早く示すことです。 それは、不確実度の高いプロジェクト初期の状況を使える情報へ翻訳する作業でもあります。
プロジェクト初期の見積もりと実績のずれを検証し、経験を重ねる中で、不確実性の高いプロジェクトでも不確実性を扱えるようになってきました。

このセッションでは、

• 不確実性のコーンを前提に、初期見積もりの誤差をどう扱うか
• ターゲット/コミットメント/見積もりの違い
• 急な見積もり、スケジュール出しの事例
  を紹介します。

急な「いつできる？」に対して、根拠を持ちつつ納得できる答えを出す。 そのための実践知を共有します。

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でお話します。