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

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

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

AIの時代だからこそプログラマは3Dプリンターやりましょう。 コードはAIが書いても、物理的な仕組みを理解するという喜びは誰にも奪えません。そしてプログラマーとしての経験も生かせる最高の体験ができます。

Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them.（かつて人間は、機械に思考をゆだねれば自由になれると期待したが、それは、機械を持つ別の人間が彼らを奴隷にすることを許したにすぎなかった） -- "Dune" Frank Herbert

今の時代は右を向いても左を向いてもAI、AIです。AIは現時点ではまだ不満点が多いですが、今後起こるであろう急激な進化を考えるならばそのうち人間にも匹敵する何かがうまれる予感もしますし、みんながわくわくするのもよくわかります。

しかしAIの進化を見守りながら我々人間はどうやって生きていけばいいでしょう。というか、AIに何か作らせてその結果で遊ぶとか、つまらなくないですか？どんなときでも我々人間は何かを作りながらいままで生命をつないできたはずです。

冒頭の引用文のような社会構造の話はまた別の機会で話すことにして、とりあえず我々がこれからのAI時代を、物を作る人として楽しんで生きていけるようにしませんか。

特にコンピュータと戯れ、プログラミングでこれまで様々なものを作り上げてきた我々プログラマはどこに目を向けるべきか？それはコンピュータのモニターの外の物理世界でしょう。そこで今まで培ってきたシステム構築の経験を生かして物理世界での継手、ギア、ラッチ、カム、それ以前にそもそも単純にパーツを組み合わせることなどを含めたさまざまな仕組みを知ると、我々が当たり前だと思って受け入れているこの世界が全く違うように見えてくるでしょう。

このトークでは3Dプリンターの軽い入門話と、物理的な仕組みを作る際に知っているべき3Dプリンターの基本ノウハウを皆さんにお伝えして、皆さんがこれから何か仕組みを物理的に作る最初の一歩を踏み出すためのお手伝いをしたいと思います。

個人開発で 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 も活用しています。

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

概要

低レイヤコンテナランタイムの内部構造を題材とし、Kotlin/Native で自作した 1000 行程度の最小構成のランタイムを動作させながら仕組みを分解して解説します。namespace と cgroup v2 によるプロセス隔離から OCI Runtime Specification に準拠したライフサイクル管理まで、実装過程で直面した課題と解決策を共有します。

このトークで得られるもの

• namespace と cgroup v2 が提供する隔離機能の具体的な使い方
• pivot_root を中心としたファイルシステム切り替えの手順
• OCI Runtime Specification が定義する create, start, kill, delete の各操作を CLI で実装する方法

対象者

• コンテナ技術の動作原理をソースコードで学びたいエンジニア
• 低レイヤーの実装経験を積みたいが、着手点を探している方

このトークはどう役に立つのか

コンテナは日常的に利用されていますが、その基盤となるランタイムの実装情報は限定的です。本セッションでは 1000 行規模のコードとライブデモにより、複雑に見える処理を段階的に示します。仕組みを自分の手で確かめる過程を追体験することで、抽象化の背後にある Linux カーネル機能と OCI 仕様の関連を理解できます。

近年、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 を採用しましたが、このセッションを聞いた方が各自の好きな言語で自作を始めることも可能です。

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

私はこの数年「趣味: CPU」と自称していくつかのCPUを作っています。
このトークは私が作った3つのCPUの紹介を通して、CPUとはどのようなものなのか、このように動作するのかを解説します。

1）CPUと機械語の基礎知識
そもそもCPUとは何か、CPUが実行出来る唯一のプログラミング言語"機械語"とは何か、メモリアクセス・I/Oアクセスなどの基礎知識を解説します。

2）ソフトウェアエミュレータから見たCPU
CPUについて理解を深めるためにCPUの動作をソフトウェア的に再現するCPUエミュレータの実装を見てみましょう。
ここでは私がPHPで実装したファミコンエミュレータ php-terminal-nes-emulator を題材にCPUの動作をソフトウェア的に再現するとはどういうことか、どんなソフトウェアを書ければCPUエミュレータになるのかを解説します。

3）ハードウェアエミュレータから見たCPU
CPUについての理解が深まったところでもう1つレイヤーを降りてみましょう。
ここでは私がRaspberry Piを使って実装したZ80ハードウェアエミュレータ z80-hardware-emulator - 既存のZ80システムからZ80 CPUのICを取り外してその代わりに取り付けて動作させることを目標としたハードウェアエミュレータを題材に、さらに深くCPUのハードウェアインタフェイスについて解説します。

4）電気回路から見たCPU

ここではCPUのハードウェアインタフェイスを理解できた皆さんをCPU動作の最下層: 電気回路としてのCPUのレイヤにご案内します。
このレイヤではCPU命令は電気回路の配線として表現されます。CPUに供給されたクロックが指揮する電気回路のオーケストラを楽しみましょう！

このトークを聞いたみなさんがCPUを好きになり、みなさんなりのCPUを作り、アツいCPUトークをいっしょにできるようになることを願っています！ Love CPU！

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

直近1年ぐらいで私が実装した楽器などを製作した成果の発表をします

1. groovebox-ruby
   RubyKaigi 2025 で「How to make the Groovebox」というタイトルで登壇したときに発表しました。
   RubyKaigi

VCOやVCF といった基本回路を Ruby でモデル化し、dRuby で分散シーケンサを構築した過程を振り返ります。
ここでは「波形を出すだけなら数行で始められる」という敷居の低さを示しつつ、簡単なMIDIの仕組みなどをふまえてデモをやります

2. Generative Sequencer
   groovebox-rubyで得られた知見を元にランダムな音楽を奏でられるGenerativeなシーケンサーの実装をしました。これはRubyKaigi 2025の事後勉強会で発表しました。
   connpass

とある本に紹介されていた「占い的作曲法」を読んだ衝撃から rand で音楽を作曲してもよいという発想から200行程度のシーケンサーのを実装をしました。
こちらは事後勉強会の登壇当時はRubyで実装しましたが、PicoRubyでの再実装をして小さなマイコンがGenerative Sequencerとして機能します。
こちらもデモをする予定です

3. 自作ミニモジュラーシンセ
   これも趣味で制作しているものですが、ブレッドボードに載せたマイコン（Raspberry Pi pico）から出ているPWMのジャンパ線を差し替えることで波形の合成やフィルターをかけられるような小さなモジュラーシンセを実装中です。
   Lチカの先に何ができるのか？を考えた時にひとつのアイデアとして音が鳴らせると面白いかなと思って実装中です。

今回のトークで聴衆の方々には、2025年は僕にとって楽器をつくる年で普段仕事で使っている領域とはまた違った学びがあったのでそれをbuildersconに参加される方々にも持ち帰っていただければと考えています。

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

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

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

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

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

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

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

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

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

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

想定する聴講者：

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

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

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

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

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

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

YouTubeやニコニコ動画、諸君らも大好きだよね？その一大ジャンルとして色々な事柄を解説してくれる動画、いわゆる「解説動画」というカテゴリが存在します。

普通こういった動画は汎用的な動画編集ソフトウェアや各種のプラグインを用いてGUI上で編集していくのが一般的です。でも操作の再現性がないしGUI編集は大変！いつしか動画作成のためには動画を編集するスキルが必須となっていきました。でもそれって良い解説動画のために本当に必要なのかな？知識と文才さえあれば動画を作れる時代のほうが面白いのでは？

そもそも、よく考えると解説動画って画面をセリフごとにレンダリングしていけば割とプログラム的に作れるのではないか？だったら俺たちが慣れ親しんだHTML使ってレンダーできらあっ！

そこで私はXMLをベースとした原稿ファイル、イラスト、BGMといったアセットから自動的に解説動画を生成するためのソフトウェアを開発しました。

私はこのソフトウェアの開発過程において、レンダリングエンジンとしてブラウザを利用したり、原稿を編集しても生成済みの箇所をキャッシュさせてレンダリングは最小限で済むなど、効率的な編集を支える様々なテクニックを導入しました。

音声合成とシーンレンダリングといった非同期処理の塊といってもよい機構を支えるのは何か？複雑な透過合成を支えるffmpegのトリックとは？なぜ口パクにモナドが必要なのか？テキストベースの利点は何なのか？荒れ狂うグラフィックボード、たまにSEGVを吐くブラウザ、かわいいずんだもん、全てをお話しします。

スマホ端末でのタッチ決済、便利ですよね。
私の所属する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など他の言語での実装にも道が拓けました。

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