トーク

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

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

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

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

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

コードを読んでいると、この変数はどこで定義され、どこで値が設定されたのか？を確認することがしばしばあります。
再代入が多いとどのタイミングで値が変更されるのか？を確認するコストが発生するので、私はめんどうだと思ってしまいます。
また、再代入がないほうがメンテナンス性が高いと信じています。なぜならば、すべてが再代入なし（= すべてが定数）の方がバグが生まれにくいはずだからです。
（いわゆる関数型プログラミング、というやつです。）

と、いうことで私は基本的に再代入をしないコードを書くように心がけています。
（もちろん、それによるデメリットがあるのも承知でそのようにしています。）

私が始めたOSSではありませんが、現在は9割方私が書いたコードになっているnode-lambda ( https://github.com/motdotla/node-lambda ) （JavaScriptです）を例に、頑なに再代入をしない（関数型プログラミング）を実践した例を紹介します。
（これまではデメリットについて、厳密に検証したことがなかったのですが、改めて検証してまとめてデメリットについても発表します。）

大規模開発の参考になること間違いなし！

ここ数年、来るべきクッキーレス時代に備え、デジタルマーケティング分野に関わるエンジニア達は人知れず戦ってきました。現役の広告エンジニアである筆者もその最前線に身を投じた一人です。しかし、 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

「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の際に出しましたが、個人的都合で当日行けなくなりました。テーマは同じですが、当時とは状況が変わっているのでアップデートした内容になります。

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

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

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

このトークでは、技術の変遷とともにどのようにPerlが変化してきたのか歴史を探求しながら、最近のモダンなPerlを紹介していきます。

Perlを使っている人、かつて使っていた人、プログラミングに興味がある人、プログラミングの歴史に興味がある人など
そんな人たちに「懐かしい〜」「へ〜」と思ってもらえるような内容を、わいとんとkobakenの2人でお送りします。

1990年から2025年現在までのWeb開発を「インターネット掲示板（BBS）」を題材に駆け上がり、各時代の変化のキッカケや背景に触れていきます。

お品書きは次の通りです。

1. CGI
2. PSGI/Plack
3. 複雑化するプロダクトにPerlはどう立ち向かってる？
4. 外圧による変化
5. 未来はどうなるか

このトークは「エンジニアがこの先生きのこるためのカンファレンス」 の前夜祭企画をベースに、
YAPC::Fukuoka 2025 用に再編・改善した内容になります。

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

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

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

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

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

本当です。そしてこの事は、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

35歳になる目前、私はそれまで当たり前のように身を置いていたプロダクト開発の現場から離れ、人事担当として急転身しました。
エンジニアにとって、近いようで遠い存在である人事。果たして、お互いのことをどれくらい理解しているのでしょうか？
エンジニアから見た人事、人事から見たエンジニア。両方を経験したからこそ分かる、お互いの誤解と理解。人事の日常業務のリアル、エンジニア組織への貢献の仕方、そして技術者と人事の間に橋を架ける意味について、転身してからの4年間の体験をもとにお話しします。

アウトライン

• 「コードを書かない」決断と「急」転身の理由
  • EMキャリアから「またコードを書く？」に対する違和感
  • 技術者アイデンティティ・クライシス
• 両方やったからこそ見えた世界
  • エンジニア時代に持っていた人事への誤解
    • 「人事って面接だけやってるんでしょ？」
    • 「技術のことなんて分からないでしょ？」
• 人事になって分かった人事の世界
  • 実際の日常業務とその深さ
  • 組織課題解決への真剣な取り組み
  • HR業界のプロフェッショナリズムとは
• 技術者出身だからできること
  • エンジニアとの信頼関係構築
  • 技術組織の課題理解と解決への貢献
  • 両方の言葉で話せることの価値
• 4年経った今の率直な感想と学び
  • コミュニティとの新しい関わり方
  • 「技術者 vs 人事」ではなく「技術者 & 人事」という視点
• 橋を架ける意味
  • 技術者のキャリアパスの多様性
  • 組織をより良くするための協働の可能性

聴衆が得られるアウトカム

• 人事という職種への理解
• キャリアチェンジの現実的な体験談
• 技術者と人事の協働の可能性

Web サイトの JavaScript や CSS はブラウザから閲覧できます。従ってそれらに機密情報が入らないよう、細心の注意を払わなければなりません。なになに? 「minify してるから大丈夫。」「モダンなフレームワーク使ってるから大丈夫。」...だって? 本当にそうですか?

機密情報の漏洩を招くポイントは、様々な場所に潜んでいます。このトークでは、一般的なWebフロントエンド開発で意識すべき漏洩ポイント、そしてその対策についてお話します。

• Source Map 経由での漏洩
• Client Component 経由での漏洩
• Next.js Pages Router の _buildManifest.json
• その他注意すべき漏洩ポイント
• 漏洩の確認方法
• 漏洩を防ぐには

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/

普段から業務でPerlのWebアプリケーションを開発・運用している方であっても「cpanfileに ::XS とついたモジュールがいくつか並んでいるところまではわかっているが、難解そうで、実装を追ったりするのはなんとなく避けてしまっている」というような方は少なくないのではないでしょうか (かくいう私もそのような時期がありました……)。

そんなXS、Perlにおけるネイティブ拡張のための仕組みは、

• データベースクライアントなど既存のCライブラリへのラッパー
  • （libmysqlclientに対応するDBD::mysqlや、ImageMagickに対応するPerlMagickなど）
• ネイティブコードによる最適化がウリのライブラリ
  • （JSON::XS、Type::Tiny::XS、……）

など、Webアプリケーション開発において必須とも言えるモジュール群で使われている技術です。一方で、とっつきにくく思われている節があり、なかなか手ほどきを受ける機会もないように思います。

本セッションでは、普段Perlを読み書きしているがXSにはあまり触れたことがない方を主な対象に、XSモジュールに対する心理的なハードルを下げ、リファレンスなどを参照しながら既存のライブラリなどの実装を理解したり、トラブルシューティングができるようになることを目指します。また、Perlに馴染みがない方にとっても、スクリプト言語におけるネイティブ拡張の仕組みのケーススタディとして楽しんでいただければと思います。

トーク内容

• CPANモジュールを取り巻くツールチェインのおさらい
• XS "急"速入門
  • 「XS言語」の基本的な文法・構造から、外部ライブラリの呼び出しなど
• XSモジュール探訪
  • 実際のXSモジュールのコード読解

クラウドの利用が広がる中で、複数のプロダクトを横断して安定したインフラ基盤を提供することは、プラットフォームエンジニアリングにおける大きな課題です。

我々の組織hacomonoでは、1,000万人以上の登録ユーザーを抱えるサービスを提供しており、今後はさらに複数のプロダクト展開を計画しています。
これまでプロジェクトごとにAWSアカウントを発行し個別にリソースを管理してきましたが、組織の成長とともに、このやり方だけではスケールしていくのが難しいと考えています。

そこで現在、共通基盤をKubernetes上に構築する取り組みを進めており、その一つの施策として導入しているのが Crossplane です。
CrossplaneとはAWSやGCPなどのパブリッククラウドやKubernetesリソースなどをKubernetesの抽象で管理可能にするOSSのツールです。

Crossplaneによるリソースの抽象化は、開発者がより楽かつ安全にインフラを扱えるようにし、同時に基盤側も裏で進化を続けられる柔軟さをもたらします。
一方で、トラブルシューティング時の原因特定の難しさや、従来のIaCツールとは異なる運用フローへの適応、チーム全体での新たな技術スタックに関する知識共有などの課題も少しずつ見えてきています。

本セッションでは、Crossplaneの概要と、取り組みを通じて見えてきた可能性と難しさ、そして今後の展望を共有します。プラットフォームエンジニアや、Crossplaneの導入を検討している方にとって、参考になる話を届けられればと思います。

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

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

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

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

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