Pixel Pedals of Tomakomai

北海道苫小牧市出身の初老の日常

トップ > 技術 > 今日は YAPC::Fukuoka 2025 １日目です
最終更新日

今日は YAPC::Fukuoka 2025 １日目です

技術

YAPC::Fukuoka 2025 に来ております。一応ブログを書いた方が喜ばれると思いますので、拝聴したセッションの自分用のメモだけ置いておきます。

オープニング

  • ヘルプページ（非公開）見てね
  • 同時配信あり
  • Slido を使う
  • 飲食禁止、コーヒーNG
    • 蓋つきペットボトルの水とお茶のみ
  • ベストトーク投票
  • @yapcjapan #yapcjapan #yapcjapanA #yapcjapanB #yapcjapanC #yapcjapanD #yapcjapan踊り場
  • 踊り場・・・大学生を集めた企画？

HTTP Message Signatures ― HTTPクライアントの身の証を立てる / @argrath さん

  • Structured Field Value Data
    • ヘッダに構造化データ
    • integer decimal, string, token ,byte-sequence, boolean, date, display-string
  • ASCII、ほぼネストはできない。制限をかけている
  • パラメータ: セミコロンで付加情報
  • 既存のヘッダとの互換
  • 課題: クライアントは何者かを証明したい
    • 本当に本物からのリクエスト？
    • IP アドレス/User Agent では不十分
  • HTTP Message に署名する
    • ヘッダが変わることは許容したい
    • 一部のヘッダの未署名する→どのヘッダに署名したか
  • 例: Mastodon
    • Signature-Input/Signature
  • Signature-Input
    • 署名するフィールドのリスト、 created、key（公開鍵）
    • 派生要素（ヘッダではないもの）は @ が接頭辞となる
  • body については、 Content-Digest にハッシュ値が入り、このヘッダを署名
  • フィールドを並べた文字列を署名
  • Q). TLS ではダメ？
    • A). 特定の相手とやり取りするなら良い。相手は不明だがリクエストの出元を保証して欲しいとき
  • Q). 仕様になって嬉しい
    • A). ですよね

Introducing RFC9111 / k1LoW さん

  • 参考文献「web配信の技術」
  • 今日の HTTP キャッシュの話
  • RC7234 → RFC9111
  • Envoy (RFC7234), mod_cache(RFC2616), Fastly (RFC9111), Akamai/Cloudflare(RFC7234)
  • 3 年経つが未だに RFC7234 が参照されている
    • 破壊的変更が少ない、厳密な記述に変更、独自実装がすでに溢れている
  • github.com/2manymws
  • なぜ RFC9111 なのか
    • RFC7234 ではなくても受け入れられそう
    • そもそもすでに廃止されている
  • キャッシュ・格納と参照
  • 格納
    • どのレスポンスをキャッシュするのか
    • Cache-Control ヘッダ
      • no-store でも must-nderstand であれば、キャッシュしてよい
    • Expires ヘッダ
  • 利用
    • Fresh : そのまま再利用可能
    • Stale : 鮮度寿命が切れている
      • オリジンサーバーへの検証結果によっては利用可能
  • ディレクティブに競合があれば、より厳しいほうを使う
  • public private は格納のみに影響する
  • Tests for HTTP Caches
    • RFC9111 のテストチャート
    • ローカルでも利用可能
    • 厳しい（58.1%）
  • Q). 画像調整サーバもRFC9111は気にするべき？
    • A). CDN の挙動が大事
  • A). 複数オリジンでのキャッシュのためにライブラリを作る必要があった

AIコーディングの弱点、やっぱりプログラミングは人間が(も)勉強しよう

  • LLM、 Transformer
  • Attention is All You Need → 単語がどの単語を注目しているか
  • Transformer は Attention と NW を多層にしたもの
  • 言語モデルは金をかければかけるほど性能が上がる（GPT-3）
    • 億単位のお金をかける根拠
  • チャットに対応するチューニング（GPT-3.5）
  • 専門家モデルを複数、必要なモデルだけを使ってリソースを削減（GPT-4）
  • Function CCalling/Tool Use : LLMから外部関数を呼び出す
    • MCP リモートで可能な Function Calling
  • 考察過程を入れる（o1）
    • 深い層で出てきた知識を、浅い層に渡すために再投入
  • reasoning を並列（一番いいものを回答） (o3)
  • LLM の計算 Llama3-8B
    • ロジカルではなく、トークンの出現確率が計算が進むほど増える。
    • 3 桁の数までは1トークン
  • 「教師」を超えることはない→機会が教師なら人類を超える
  • ユニットテストが欠けない＝学習ができない＝苦手
  • AI の弱点、コンテキスト処理能力、知らないことが多い
    • 長いコンテキストが苦手 / せいぜい 30K トークンくらい / プロジェクト全体を一度に見られない
    • コンテキストの汚れに弱い→同じ失敗が続く
  • コンテキストエンジニアリングが大事→きれいにコンパクトに
  • 知らないこと→実際にどう動くか、開発過程、ファイル以上の大きな単位
  • プログラミング
    • 機能、性能、使いやすさ、安全性
    • AI が得意なのは機能だけ
  • 実行のための機能→関数型、構成のための機能→OOP
  • プログラムの最適化
    • 処理の重複の排除
    • キャッシュ
  • 多胎の活用
  • 単一責務→変更の発生源をまとめる。クラス利用者の責務
  • 非機能要件は人間が頑張りましょう！

「データ無い！腹立つ！推測する！」から「データ無い！腹立つ！データを作る」へ / moznion さん

  • サービスと「名前」
  • 機械は「セブンイレブン」を理解しない
    • 「セブン」「ブンイレ」でもわかる
    • LLM ならわかるのでは
  • 人間が見てもわからないものは機械もわからない
  • データはなくても困らない→困るのは必要になってから
    • 可能性が狭まる
  • データがない、何もわからない、どういうデータが必要かわからない、の悪循環
  • データがあるだけではダメで、使えるように整理してないと駄目
  • 「AIでよくね？」
  • 決定論的に計算できるものを LLM に計算すべきではない
  • 「大本おのデのデータ」は今後価値を持つ
  • 「何に使うのか」からデータを考える
  • データを作るための「生データ」
    • あるのか、どこにあるのか、形式や構造
    • まずはここから
    • システムがデータを生む、 WEB を使う、買う
  • ドメイン知識がないとデータを作るのは難しい
  • 「辞書」を作る
    • 名称情報から「ラベル」をつける
  • DuckDB が高機能で性能が良い、組み込み
  • Gabage In, garbage Out →前処理できれいにする
  • 人間に適したワークフロー→スプレッドシート
  • データの後処理→テスト、ベンチマーカー
  • SQLite のダンプは他の DB へ読み込ませやすい
  • データ作りにもソフトウェア開発のベストプラクティスを使える
  • LLM に Assist Tool を生成させる
  • 人力を諦めない
  • 孤独
    • 品質が高いデータができる
    • 超人以外は無理
    • ポシャりやすい
  • 「なんの役に立つのか」
    • データづくりとシステム作りのフェーズはわけない
    • データをシステムに投入しながら
  • 100% のデータというものはない
    • 小さな労力で、高い効果
    • 継続的に育てる
  • データセットは作って終わりではない
    • データがどう使われいるか
    • 目的外利用→使いまわせるのは良いデータ
  • チームを作る
  • データを買ってビジネスを進めながら、自分たちで作ることもできる
    1. 前処理の陳腐化はどうする？
      1. ベンチマークの悪化から気がつけるとよい

なぜThrottleではなくDebounceだったのか？ 700並列リクエストと戦うサーバーサイド実装のすべて / yoshiori さん

  • テスト結果の収集
    • AI でまとめる。原因、再現性、などなど
    • テストの分散→平均的に同じ時間で終わるように
  • 700 並列でテストを実行するお客さん
    • ジョブキューでは意味がない
    • 処理を間引く Throttle や Debounce
  • Debounce
    • データが集まるまで、待つ仕組み
    • タイマーをデータが来るたびにリセットする
  • 没になった案
    • Rate Limit 、や缶バッチ、スケールアップ・アウト、ジョブキュー
    • クローズ処理はまとめられる
  • Throttle より Debounce の方がより待機してよりまとめられる
    • クライアント技術→直列
    • クライアントもサーバーサイドも複数台ある
  • Redis を使った実装
    • UUID を書き込み、変わっていなければ終わったと判断
    • Redis をロック代わりにした
  • レースコンディション
    • atomiv に値を確認して一致したら削除する必要
    • LUA スクリプトを書くと解決
  • Debounce は delay 時間の調整がキモ
    • 長過ぎると遅延
    • 短すぎるとまとめられない
  • 二つの要件
    • まとめて実行したい
    • 早く届けたい
  • 速報値と確定値に分ける
    • 速報値は即時実行
    • 確定値は長い delay で debounce
  • delay を徐々に調整
    • UUID の代わりに、前回のリクエストの時間を保存
    • 実装よりコメントが大きくなった

「バイブス静的解析」でレガシーコードを分析・改善しよう / hitode909 さん

  • AI のコード生成の問題
    • 妥当性、プロジェクト固有の問題
  • Vibe coding : AI で勢いよく開発
  • バイブス静的開発
    • 人間が解釈できるものに留める
    • 自分たちのコードベースだけを正規表現で
  • 議員性は許容
  • use だけではなく、様々な依存
    • 文字列を生成していることもある
  • ツールを AI に作らせる
    • 依存関係も出力してもらう
  • 20 PE で 4 万行の削除
  • use 済テストの品質改善
  • Q). PPR は？→遅い
    1. どんなタイミングで？
      1. 消す暇がないから AI で、というのがきっかけ
    3. AI が余計なファイルを見ない、という利点もある
    1. AI が誤った時の対処法
      1. 反省させて、プロンプトを作ってもらうとよい

Agentに至る道 〜なぜLLMは自動でコードを書けるようになったのか〜 / macopy さん

  • Attention is All You Need
  • GPT, GPT-2, GPT-3
    • すごく制度の良い予測変換器
  • Instruct GPT (2022)
    • ChatGPT
  • Evaluating Large Language Models Trained on Code (2021)
    • docstring によってコードを書かせる
    • docstring や処理が複雑だと精度が落ちる
    • LLM が内部に持つ知識にのみ依存する 「圧縮された検索知識」
  • 一発勝負で生成するのはうまくいかない
    • 人間はそうしていない
    • 必要なファイルを読めない（コンテキストの中間にあるものはうまく使えない）
    • RAG も一発勝負（同じ課題）
    • HotpotQA - マルチホップ（検索が複数必要なタスク）
  • web GPT
    • LLM がツールを捜査するコマンドを発行
  • ReAct : Though, Action, Observation
    • Action の前に Though セクションがあるのがミソ
    • Few-Shot いくつか例を見せる
  • Reflexion, InterCode (2023)
    • エラーをフィードバックする
  • AI ベンチマーク
    • AI に難しそうな課題を設定し、解決する
    • HumanEval, APPS (2021)
    • SWE-Bench (2023)
      • github よりテストコードのある issue/PR を抽出したもの
      • Claude 2 でも 2% しか解けなかった
    • 2024 SWE-Agent
      • 今っぽいエージェント
    • 現在の SWE Bench の解決率は 70% ほど
      • コード生成がお金になることが判明
      • AI も開発に参加
  • ライブコーディング

企画 LT

プロジェクトの空気を読んで開発してくれるPerlのAIツールがほしい / kfly8 さん

  • + がないと is が解釈できない問題 → 5.42
  • 1; は要らない
  • AI は古い記法を使う
  • Perl TODAY という本(無料)を書いた
  • Hono CLI アプローチ
  • AI 向けの perldoc を開発中

Pythonを"理解"しているコーディングエージェントが欲しい！！ / ftnext さん

  • Calude は速くて安い。使わざるを得ない
  • Python のことわかってないよね
  • f-string と % の使い分けができない
  • Ruff を使った指摘。フックを設定
  • デモ
  • サブエージェントの出番？

基盤モデルのアーキテクチャを改造してみよう - 時系列基盤モデルのマルチモーダル拡張事例の紹介 / himuhimu467 さん

  • 生徒の離脱予測
  • 膨大な時系列を学んだモデル
  • 新規のドメインでもほどほどの予測
  • 離脱予測＝離脱を防止したい
  • 出席傾向が落ちると、回復しない
  • 出席傾向が落ちるタイミングを知りたい→時系列モデルだけでは無理
  • 振り返りのテキストデータも入力。マルチモーダル
  • Fusion Module でマルチモーダルがうまくいくか決まる→ここをチューニングしていく

認知ではなく良い体験設計を追求する、そのための広告プロダクト開発組織における『Bet AI』とは / honyanyas さん

  • AI で広告事業を考える
  • CS の人力回答を AI で
    • プロンプトの自動化
    • ドメイン知識を持っている人が輝く
  • 「本当にこれで大丈夫なのか」
  • Bet AI
  • Perl

プロダクトにも、チームにも。サイボウズがAIと共に歩む理由 / tasshi_me さん

  • AI は一人で使うツールになっている
  • kintone × AI : チームで活用する AI
  • AI に質問するだけで必要な情報に
  • アプリ作成 AI とレビュー AI

AIが見張り、人がもてなす — 全国400店舗のカラオケBanBanの運営をサポートするAI Agent / 西尾健人 さん

  • POSレジが高機能
  • レガシーシステム
    • 日次、ドキュメントしかない
  • お客様によりよいサービスを
    • 定常業務を AI でなくし、お客様に還元
  • 店長 AI 、エリアマネージャー AI 、ブロックマネージャー AI
    • 部屋のアサイン、料金作成、バイトサポート

クロージング

  • わすれもの
  • オープニング　再放送
  • ベスト企画 LT 賞
    • ftnext さん　「Claude の応援ありがとうございました」
  • 記念写真（今日しか来れないスタッフがいる）

ランキング参加中
プログラミング