トーク

みなさん、DiscordBotを作ったことはありますか？
DiscordのAPIは拡張性が高く、やろうと思えば大規模サービスに劣らない規模のBotを組むことが可能です。
LINE,Twitter,YouTubeなどといった外部サービスのAPIを利用すればさらにやれることが増えます。

しかし外部サービスには仕様変更が付き物です。
DiscordBotに限らず、外部APIの仕様変更は避けられない課題です。
本セッションでは、各種Web APIやWebhookとの連携を前提としたBotの設計において、「変更に強いアーキテクチャ」をどのように組み立てるかに焦点を当てます。

DiscordBotを通して外部のAPIとどう向き合うか、知見となれば幸いです。

個人開発で AI をフル活用してプロダクトを作っています。

昨今、AIエージェントで“バイブコーディング”する人が増えてきました。しかし、多くの人が経験しているように、品質を保ちながら高速で作るのは現段階では簡単ではありません。とはいえ、適切なフィードバックを与え、品質を期待値に収束させる仕組みを作ることは不可能ではないとも感じます。まだ道半ばですが、私はそれができると信じ、夢中で取り組んでいます。

本セッションのポイントは3つです。
(1) セッションごとの記録の徹底。 AWSの kiro に着想を得て、毎回「同じ形式の設計ドキュメント（ログ／要件／作業メモ）」を自動生成します。同時に ccstats という自作ツールにセッション統計を書き込み、後から分析できる土台を用意。
(2) 俯瞰と計画を担う“マネージャーAI”。 スクリプトと CCA（Claude Code Action） の定期実行で状況を観察し、「コスト/開発者体験/Backend/Frontend/AIシステム」各領域の課題発見と改善計画を自動提案。人間はその計画を承認・調整する役割に専念します。
(3) きめ細かな自動化を支えるOSSツール群。 フィードバック付与や並列実行などを小さな部品として提供します。たとえば workbloom（Git worktree運用の標準化）、branch2ports（ブランチ名→動的ポート割当）、get-sonar-feedback（SonarCloud観点の自動注入）など作成し、再利用性を高めています。もちろん Claude Code の custom command や subagent も活用しています。

ここに至るまで、たくさんの失敗をしました。効率が良いのか悪いのか分からない日も多いです。それでも、それなりにものは出来上がっていくし、何より楽しい。夢中になれている——本セッションでは、その過程で見つけたヒントを、少しでも持ち帰っていただける形で共有します。

近年、Claude CodeやCursorやClineなど各種開発支援AIツールの登場によってコードを書く速度が格段に上がり、開発者は以前の数倍のペースでプルリクエストを作成できるようになった一方で、レビュープロセスがボトルネックになっていないでしょうか？
それと同時に、レビューがボトルネックになって、開発速度がなかなか上がらない。なんてことはないでしょうか？
例えば、

• 「このPRだれかレビューして！」
• 「レビュー依頼したけど、誰も引き受けてくれない・・・」
• 「レビューリクエストしたのに一向に進まない・・・」
• 「私ばかりレビューしてる・・・」

こういった悩みをSlack Botで解決する、Slack Review Notifyというツールを開発しました。
https://github.com/haruotsu/slack-review-notify

今回の発表では、実際に導入してチームの声を聞きながら改善を重ね、辿り着いた効果的な設計パターンとSlack block kit builderの実装ノウハウを体系的に解説します。
具体的には以下を発表します。

技術面:

• 失敗から学んだWebhook処理の堅牢な実装パターン
• GitHub→Slack連携における署名検証と非同期処理のベストプラクティス
• Slack Block Kit Builderの書き方と実践的な活用テクニック

設計・運用面:

• 運用データから導いたDB設計の大幅リファクタリング判断基準
• チームワークフローを考慮した機能設計の思考プロセス
• 定量的な効果測定と継続的改善のアプローチ

Slack統合は単なるAPIコールの組み合わせではありません。 適切なアーキテクチャ設計、運用を見据えたDB設計、そして実際のチームワークフローを理解した上での機能実装が必要です。
今回の開発経験から、技術はもちろんのこと、実際の運用体験を踏まえた設計パターンを体系的にお伝えします。

私が悩み抜いた、チーム開発の課題を技術で解決するための思考プロセスをお持ち帰りいただき、自身のチームの課題解決をする際の一手となれば幸いです。

本セッションでは、定理証明支援系 Lean を用いたコンパイラの実装技法を解説します。コンパイラの挙動を保証するための理論的な解説に加え、自作の Lean 製コンパイラで実際に簡単なプログラムをコンパイルして動かす様子もお見せします。

今日、プログラムを書く際に単体テストをつけることは、一種のマナーとして広く普及しています。しかし、かつて Dijkstra は言いました - テストではバグの存在を示すことはできても、不在を示すことはできない。つまり、たとえテストが成功していても、それはたまたまテストケースが不足していた可能性が否定できないのです。

一方、仮に全通りのテストケースを生成してバグの不在を示そうとすると、組み合わせの爆発により膨大な数のテストが必要になってしまいます。例えば「長さ 3 以下の char の配列を受け取る関数」をテストするだけでも入力パターンは 16,843,009 通り、通常の任意長の配列を受け取る関数ならば文字通り「無限個のテストケース」が必要です。

本セッションで紹介する定理証明は、文字通りこの「無限個のテストケース」を扱うための手法です。テストしたい関数の性質を型レベルの制約として表現することで、単体テストのような実行時ではなく静的な型検査時に、かつ「任意の char 配列」のような事実上無限個のテストケースに対して関数の性質を保証できます。

定理証明支援系の中でも、Lean は実際に動くプロダクトが実装できる点で近年人気があり、かの AWS の認可エンジンの検証にも採用されています。本セッションではこの Lean の特徴を活用して、自作言語をコンパイルしてシンプルな CPU 上で動かすための「証明付きコンパイラ」を実装します。

ところで、個別の関数の戻り値ならともかく「コンパイラの正しさ」とは何でしょうか？ 本セッションではこの問題に対して、「ソース言語の意味論」と「ターゲット言語の意味論」の間をつなぐものとしてコンパイラの性質を定式化し、実装したコンパイラが意味論を保存することを証明します。

受講にあたって、定理証明や特定の CPU 命令セットに関する予備知識は要求しません。「コンパイラの正しさとは何か？」に焦点を当て、複雑なプログラムの挙動も数学的にきちんと定式化できるのだ、という感動を味わって頂ければと思います。

ただツールを使うだけの形式手法から、自作する形式手法へ。本セッションでは Go 言語でモデル検査器を実装する流れを紹介しながら、その内部的な仕組みを学びます。

形式手法は計算機システムを何らかの数学的な対象によって記述し、その性質について理論的な保証を得る手法の総称です。通常の単体テストと比較すると記述コストは高くなりますが、その代わりに保証できる内容は数学的な裏付けに基づいており、テストケースの抜けや漏れが発生しません。そのため、分散システムなどの複雑な挙動を設計する場合や、医療・航空宇宙など極めて高い信頼性が求められる場合、言い換えれば高い記述コストを支払っても十分にペイする分野において威力を発揮します。

特に、本セッションで扱う形式手法はモデル検査と呼ばれるものです。形式手法には大きく分けて定理証明とモデル検査の二つの分野がありますが、検査時に人の手が必要な定理証明に対して、モデル検査では基本的に全自動で実行することができます。システムの挙動を Kripke モデルと呼ばれるある種のグラフ構造に変換し、その上で探索を行うのがモデル検査器の基本的な動作原理です。Kripke モデルのノードは可能世界と呼ばれ、モデル検査器は「常に〇〇が成り立つ」「いつかは必ず〇〇が成り立つ」といった時間的な広がりを持った仕様を検査します。それを扱う我々は、さしずめ可能世界を渡り歩く時間旅行者といったところでしょうか。

本セッションでは、講演者が技術書典 16 で頒布した同人誌『モデル検査器をつくる』をベースにして、実際に動作するモデル検査器をスクラッチから実装する流れを紹介します。既存のツールを使用するモデル検査のチュートリアルは巷に多数ありますが、単にユーザとしてツールを使用するだけでは、その背後にある理論や動作原理は見えません。今回は単に「ツールを動かしてみた」で終わらないよう、自作を通してその内部のアルゴリズムまで突っ込んで解説したいと思います。実装言語としては親しみやすさの点で Go を採用しましたが、このセッションを聞いた方が各自の好きな言語で自作を始めることも可能です。

受講にあたって形式手法に関する予備知識は要求しません。また、複雑なシステムの設計や謎の挙動で苦しんだ経験がある人はより楽しめるはずです。さあ、君もその手でモデル検査器を作ろう。

Agentic Codingは、その大量のPRで我々のキャパシティを試しています。Vibe Codingは、ビジネスサイドに「動くが脆い」シャドウITを生み出す力を与えました。
AIによる暴力的なまでのアウトプット量は、これまでも存在した「品質や負債に無頓着な(無邪気な)エンジニアリング」と結びつき、技術的負債をかつてない速度と規模で深刻化させる可能性を孕んでいます。

このトークは、この新たなカオスに対する警鐘であり、処方箋です。
なぜ、学び続けるあなたの隣で、無邪気なエンジニアが新たな負債を生み続けるのか？その答えは、個人の資質ではなく、当事者意識を奪う組織構造にあります。
私は事業会社のエンジニアリング部門で長く過ごしたキャリアから、多くの現場でこの「無邪気さ」が価値あるシステムを蝕む光景を目の当たりにしてきました。この個人的な物語を通じて、私がいかにしてこの問題構造に気づき、「無邪気さからの脱却」というプロフェッショナリズムの問いに至ったかを共有します。

そして、このセッションは、学び続けるあなたにこそ聞いてほしい。
今はまだ無邪気なチームメイトのプロフェッショナリズムを覚醒させてほしい。
「学ぶ人」と「学ばない人」との越境者となり、エンジニアのプロフェッショナリズムとは何か、真のBuilderの在り方とは何かを伝え、共通の価値観とするチームへの変革者になってほしい。

このトークでは、そのためのちょっとした武器をお贈りします。
その武器とは、ビジネス価値を見極め、戦略的負債を可視化し、対話のきっかけを生む、ごく簡単な「モデリング」です。面倒な記法など必要ありません。

チームの、そして業界の「無邪気さ」を終わらせるためのセンスメイキングを一緒に始めましょう。

ターゲットオーディエンス:

• 技術探求に熱心で、自身のチームや組織のエンジニアリング文化をより良くしたいと考えている中堅からシニアのエンジニア、テックリード、アーキテクト。
• 「なぜウチのチームは品質に対する意識が低いままなのか」「どうすれば負債と向き合える組織になるのか」という構造的な問題意識を持っている方。

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

筆者は、7月からこのツールを使い始めると同時に、1ヶ月間で多くの改善提案及びpull requestを行いました。コード行数にすると1万行近くに及びます。最終的にはコントリビューターにも加えてもらいました。

これらは、まず、仕様の整理やコードの整理を行い、その上での機能追加やパフォーマンス改善を行いました。

これらの改善により標準MarkdownをGoogle Slide上で必要十分に表現できる様になり、パフォーマンスとしても、スライド生成が実測で30倍以上高速化されました。100倍以上になったケースもあります。

これらの改善を行う為にオリジナル作者のk1LoWさんとどの様に協調したか、どの様に考えて機能追加やパフォーマンス追加していったかをTidy Firstの観点を含めてお話しします。

Claude Code と Max plan の登場により、なるべく長時間 Claude Code を働かせれば働かせるほどお得、という時代が到来しました。
コードは Claude Code に書かせつつ、人間としてやるべきことは何なのか、そしてその出力を最大化するにはどうすればいいのか。
私の現状の結論は以下です:

• プロンプトは渾身のものを書き上げる
• Claude Code が止まっている時間の最小化
  • Permission を求められたら即時に対応する
  • 作業が完了したら即時に対応する
• 人間はやるべきことが無ければ体力の回復に努める

渾身のプロンプトを書き上げる時間を除けば、これらの全てをベッドの中やお風呂の中など、できる限りリラックスできるシチュエーションの中でも実行できることを目指す必要があります。
そのために私は以下の 2 つのソフトウェアを開発しました。

• cchh: Claude Code Hooks Handler
• cc-slack: Slack から Claude Code を操作する

これらのソフトウェアはほぼ 100% Vibe Coding により開発されています。
この発表では、これらを使うことでどのような開発体験を実現できるのか、そしてこれらを使っての Vibe Coding の精度を最大化するために私が心がけているプラクティスについて紹介します。

この発表を通じて、皆さんと共に令和における Lazy Programmer のあるべき姿を模索していけるようになりたいと考えています。

毎日大量に届くスーパーのチラシ。それは、お得な情報が詰まった「宝の山」であると同時に、レイアウトやデザインに小売店の"こだわり"が凝縮された、いわば「一点物のアート作品」とも言える非構造データの塊です。

私が所属するくふうカンパニーでは、チラシ情報サービス「トクバイ」を運営しています。トクバイでは、「お得な商品をたのしく探したい」という体験を大切にする一方で、「忙しい中でも自分に最適な情報だけを効率的に知りたい」という切実なニーズにも応えるべく、チラシ画像から個々の商品情報を自動で抽出する「チラシ切り抜きAI」の開発に挑戦しています。

本セッションでは、店舗ごとの特色が色濃く現れるレイアウトや、温かみのある手書きPOPといった、画一的ではないチラシならではの"ゆらぎ"に対して、AIを駆使していかに向き合ったか、その開発の裏側をお話しします。

さらに、AIが生み出したデータの価値を最大化するために、RedshiftからBigQueryへのデータ基盤移行プロジェクトにも焦点を当てます。なぜ移行が必要だったのか？移行の過程で直面した「悪戦苦闘」のリアルなエピソードとは？そして、新しいデータ基盤がもたらした分析体験の向上や、新たなサービス価値創出の可能性について、具体的な事例を交えてご紹介します。

長年にわたって運用されているFintechサービスでは、かなり前の段階でマイクロサービスアーキテクチャが導入され、現在もその構成が踏襲されています。しかし、当時の設計や実装方針が明文化されておらず、「なんとなく前例に倣って」新しいサービスを作る状況が続く中で、設計の不統一や責務の重複、運用しにくさといった“つらみ”が蓄積されています。

このセッションでは、Go言語で構築されたFintechサービスのサーバーサイド開発現場から、「マイクロサービスが既に存在している前提で、それを模倣しながらどうにか開発を回しているが、いろいろとしんどい」という状況をリアルに共有します。

お話しする予定のトピック：

• すでに存在するマイクロサービスの構成を“なぞって”開発することの難しさと歪み

• サービスごとにバラバラな設計を引き継がざるを得ないつらさ

• 技術的負債とわかっていながら改善できない背景（リソース不足、優先度のジレンマ）

• 金融サービスに求められるセキュリティ対応と、それが設計に与える影響

• 生成AIやAIエージェントを活用して、設計整理やドキュメント補完を試みる実験的な取り組み

• 今すぐには解決できない課題も多い中で、少しずつ前に進むための工夫や試行錯誤

本セッションでは、AWSなどのインフラ構成には深く立ち入らず、アプリケーションエンジニアの視点で語る、設計・開発・改善のリアルにフォーカスします。

想定する聴講者：

• マイクロサービスはあるけど、統一されていない・メンテしづらいと感じている方

• Go言語を使ったプロダクト開発に関心のある方

• 技術的負債や設計のブレに向き合っている現場の方

• AIを使って開発体験やドキュメント整理を良くしたいと考えている方

• 理想と現実の間で試行錯誤しながらプロダクトと向き合っているすべての開発者

設計は完璧じゃない。ドキュメントも少ない。でも、それでもプロダクトを前に進めている。
そんな過渡期のFintech開発現場のリアルを、正直に共有します。

スマホ端末でのタッチ決済、便利ですよね。
私の所属するKyashでも、2025年6月にVisaタッチでの決済に対応し、ユーザーからもご好評をいただいています。

タッチで決済できるまでに何が起きているのか、なぜタッチするだけで決済できるのか、説明できる方は意外と少ないのではないでしょうか。
このトークでは「なぜスマホタッチで決済できるのか」というテーマで、実際にVisaタッチ決済に対応した経験をもとに以下の内容に触れながら "歴史" と "技術" の話をしていきます。

• カード関連情報をどこに持っているか
• トークナイゼーションの導入と歴史
• Secure Element / Host Card Emulation とは何か
• Type A/B と Type F (Felica) と日本での普及

スマホ端末でのタッチ決済、便利ですよね。
私の所属するKyashでも、2025年6月にVisaタッチでの決済に対応し、ユーザーからもご好評をいただいています。

タッチで決済できるまでに何が起きているのか、なぜタッチするだけで決済できるのか、説明できる方は意外と少ないのではないでしょうか。
このトークでは「なぜスマホタッチで決済できるのか」というテーマで、実際にVisaタッチ決済に対応した経験をもとに以下の内容に触れながら "歴史" と "技術" の話をしていきます。

• カード関連情報をどこに持っているか
• トークナイゼーションの導入と歴史
• Secure Element / Host Card Emulation とは何か
• Type A/B と Type F (Felica) と日本での普及

概要

本発表では動的で時間認識型のナレッジグラフエンジンであるGraphitiを搭載したメモリレイヤーを紹介し、その有用性を経費精算申請バリデーション機能で実験した結果を紹介する。

内容

従来のRAGアプローチは、主に「静的なドキュメント検索（データが頻繁に変わらない）」に焦点を当てていた。しかし、現実世界のアプリケーションでは、継続的な会話やビジネスデータといった多様なソースからの「動的な知識統合」が求められる。特に経費精算申請のチェックにおいては会社ごとに違う規定、ルール、承認者の独自ルール、会社の変化による暗黙的なルールの変化に対応していく必要がある。

Graphitiは、新しい情報でナレッジグラフを動的に更新し、事実と関係のタイムライン（有効期間を含む）を維持する。このアプローチにより、ナレッジグラフは複雑で進化する世界を表現できる。さらにzepを利用することで高速にナレッジグラフ基板を立ち上げることも可能。

そこで本発表ではGraphitiを搭載したメモリレイヤーを紹介し、その有用性を経費精算申請バリデーション機能で実験した結果を紹介する。

学べること

• Graphitiの論文を引用しながら、裏側の仕組みを紹介する
• 時間経過で暗黙的に変化する申請ルールやコードルールなどへどのようにAIに対応させるか
• 実際に私が行った実験を紹介し、Graphitiの有用性を評価する。

ドキュメントや本を読んでRAGをやってみただけでは得られない「知らなかった」世界を皆様にも共有し、AI Agentが時間経過で複雑な世界を捉えるようになるワクワクを届けます。

概要

LLMが苦手な麻雀点数計算問題生成タスクの精度をAgentic Workflowの構築で30%から90%に上げた話をします。

麻雀点数計算問題生成は計算問題かつ複雑なルールの包括的理解が必要という、LLMが最も苦手とするタスクの一つです。そこで、そのようなタスクをどのようにAgentに解かせるべきかを複数の実験から明らかにしていきます。さらに、このようなタスクを抽象的に捉え、応用先を考えることで皆さんの実際の業務への応用も提案します。

Agentic Workflowを構築するにあたり、不可欠な知識もお伝えします。

• コンテキストエンジニアリング
• 自己検証ループの取り扱い
• Agent分割の考え方

何が学べるか

• 「無数の選択肢の組み合わせを考えるタスクだが、正解は検証できる」という特性を持つタスクに立ち向かう際の知見。
• プロンプトエンジニアリング単体での限界とその性質。
• Agentic Workflow構築に必要な知識。
• 実際のAgentの構築方法。
• Langfuseを使った評価基盤構築

麻雀点数計算問題生成の精度追求の経験があったからこそ得られた「知らなかった」を皆様にも共有し、みなさんが趣味のためにAI Agentを作るワクワクを届けます。

CloudBees傘下となった Launchable は、スタートアップとして5年間、高速な開発サイクルを優先し、モノリシックなアーキテクチャで成長してきました。しかし、機械学習部分が他のコンポーネントと密結合していたせいで、Javaセキュリティ脆弱性への対応や最新機能の取り込みに必要なライブラリのアップデートが極めて困難になってしまいました。 特に、JavaEEからJakarta EEへのパッケージ変更に伴う広範囲なコード修正、SparkとScalaのバージョン制約によるJavaバージョンアップの遅延、そしてEMR環境特有の依存関係が、開発速度の大きな足かせとなっていました。

このセッションでは、そのようなモノリスの現実としっかり向き合い、インターネットフェイシングなサービスと、計算資源を多用する機械学習の推論プロセスを無停止で完全に分離した道のりをお話しします。 この分離によって、外部に公開されたサービスはSparkやEMRの依存性から解放され、より迅速なライブラリのアップデートが可能に。 さらに、推論プロセスの独立により、リソース配分も最適化でき、将来的にPythonなど他の言語での実装にも道が拓けました。

なぜここまでライブラリ更新が大変だったのか、その技術的な背景から、直面した具体的な課題、そしてそれらを乗り越えるためにどのようなアーキテクチャを選び、どのようなステップで移行したのか、得られた教訓までをガッツリ解説します。この話は、特にこれからマイクロサービス化やシステムの分割を考えている、成長期のスタートアップエンジニアにとって、きっと役立つヒントがたくさん見つかるはずです。

モバイルアプリのUIは、ユーザーの直感と期待に応えるインタラクションデザインが核となります。しかし、単なるデザインガイドラインの遵守に留まらない、特定のOSバージョンでのUI挙動の差異、複雑なジェスチャーの実装における落とし穴、あるいはUIコンポーネントの微細なパフォーマンス最適化など、細部に宿る課題が多数存在します。

本セッションでは、ユーザーの心理的側面（例: なぜ特定のジェスチャーが自然に感じるのか）をデザイン理論から掘り下げつつ、それをSwiftUI/Jetpack ComposeのGesturesやUIKit/Android ViewのTouchEventといった具体的なUI実装へどう落とし込むかを解説します。複雑なジェスチャーの認識アルゴリズム、複数のジェスチャー間の競合解決、そして洗練されたアニメーションとの連携など、デザイナーの意図を正確にコードに変換するためのエンジニアリング的な挑戦と、その過程で得られた「職人技」とも呼べる知見を共有します。

具体的なプログラムの書き方、アプリの動きを詳細に分析する性能測定の結果、そして問題を見つけて修正するデバッグの手法を交えながら、これらのUI実装に関する考察と実践的なアプローチをご紹介します。これにより、モバイルアプリ開発者が日々直面するであろうUI実装の課題に対し、より質の高い、使い心地の良いユーザー体験を作り出すための一助となれば幸いです。

人を増やして売上を拡大する。
タスクを細分化してEVMで進捗を管理する。
進捗が計画通りであることが、プロジェクト成功の指標となる。

それが18年間、受託開発の現場で私が学び、自然と身につけていた開発との向き合い方でした。
ただ、目先の利益のためだけに働いている感覚に違和感を抱くようになりました。
もっと“作ること”そのものに意味や目的を持ちたいという思いが芽生えました。

プロダクトを成長させ、価値を実現する。
チーム全体で認知を揃え、同じ目的に向かって一緒に開発を進めていく。
ストーリーを捉え、最小限の成果物を届け、そこから得られる経験を次に活かす。

「人を管理してプロジェクトを進める」という発想から、
「チームでプロダクトを育てる」という発想へと、志向がシフトしていきました。

このトークでは、私がどのようにして「納品のための開発」から「価値実現のための開発」へと視点を変え、
作ることに対するオーナーシップを持てるようになったのか、そのきっかけと実践、そして得られた学びをお話しします。