■ 1. 勉強会開催の背景
- 社内勉強会の実施:
- TypeSafe AI の Jev を題材に社内勉強会を開催し、エンジニアが50人以上参加
- 30分の短い会だったが、サービスに Jev を組み込むアイデアが50件を超えた
- 置き換え発想の限界:
- 既存の LLM 呼び出しのうち Jev が使える箇所を置き換えるだけでは「少し安くなった」で終わる
- これまで AI を使うと考えもしなかった場所に差し込む頭に切り替えないと本領が出ない
- 集合知が必要な理由:
- 発想の切り替えは一人で考えていても筋の良いパターンが出てこない
- プロダクトも業務ドメインもバラバラな人が「うちの業務ならここに刺さる」を持ち寄るほうが圧倒的に速い
- タイムテーブル:
- Jev とは（5分）、Jev 組み込みデモ（5分）、みんなの妄想共有（20分）
- 前半を最小限にし、時間の大半を妄想に充てる構成
■ 2. Jev の解説方針
- 既存解説への委譲:
- Jev 自体の解説は既に良いものが多く出ているため、そちらに譲る
- 勉強会では公式発表ブログと npaka 氏の解説記事の2本を共有
■ 3. 転換1: 文章生成を選択肢に落とす
- 文章生成という無意識の前提:
- AI 機能を作るとき、要約する、抽出する、理由を説明するなど文章を書かせることを前提にしている
- Jev はそれができず、できるのは判断だけ
- 判断しかしていない箇所の多さ:
- 業務システムの中を眺めると、判断しかしていない箇所がやたらと多い
- 書類が契約書か対象外か、申請を自動承認してよいか人が見るべきか、といった判断が該当
- 問い合わせが過去のエスカレーション事例と似ているか、取引先名がマスタと同一か、といった判断も該当
- noul と choice での記述:
- これらは全部 noul と choice で書ける
- 従来はここに LLM を持ち込むと遅く、コストもかさんでいた
- 選択肢化を考える癖:
- 勉強会では判断しかしていない箇所の棚卸しが大量に出た
- 「これは選択肢という形に落とせないか」と考える癖をつけることで Jev に落とせるポイントが増える
■ 4. 転換2: confidence を設計の部品化
- LLM の自信度への不信:
- LLM に自信の度合いを出力させても、返ってくる数字はあまり信用できない
- そのため根拠を出力させて人間が読むという運用にしてきた
- Jev のキャリブレーション:
- Jev は confidence がキャリブレーションされていることを売りにしている
- 勉強会では X で公開された検証結果を共有し、メール分類タスクで Jev と Gemini を比較
- 検証結果の内容:
- 全体の精度は Gemini のほうが少し上だった
- confidence の高いものはほぼ正解し、低いものは実際に間違っていた
- 自己申告性の価値:
- 精度の絶対値で比べるのではなく、モデルが自分で間違いを申告してくれる性質に使い道がある
- 閾値による設計の拡張:
- confidence が高ければ自動処理し、低ければ人間にフォールバックするか重いモデルに回す
- 自動処理できる範囲を confidence の閾値で調整する考え方は公式 cookbook でも繰り返し登場する
- 分類に uncertain を明示的に足す、confidence が低ければ粗い上位カテゴリを返すといったパターンがある
- 今後の活用意向:
- これまで LLM の出力する自信度を信頼できていなかったが、今後は機能開発の検討に入る使い方
■ 5. 転換3: 大量かつ頻繁な呼び出し
- 呼び出し回数の感覚の変化:
- 安くて速いため、全レコードを走査する使い方が現実的な選択肢になる
- キーストロークなどユーザーのリアルタイム行動を起点に頻繁に発火させられる
- リアルタイム UI/UX の成立:
- リアルタイム発火を諦めていた理由は応答が遅いことであり、ミリ秒で返るなら成立する
- キーストローク発火やマウス移動を起点に AI が頻繁に発火する使い方は面白い
■ 6. まとめ
- 勉強会の狙い:
- Jev の使い方を教えることではなく、自分の担当プロダクトのどこが変わるのかを各自に考えてもらうこと
- アイデアの広がり:
- 契約管理、経費精算、人事労務、社内の AI 基盤など、まったく違う領域から沢山のアイデアが出た
- 具体的なアイデアは機能として検討が進むものもあるため今回は割愛
- 本番投入の結果:
- 実際に本番に乗せてどうだったかは別の記事で書く
- LayerX の文化:
- 新しい技術が出てきたときに「で、うちの業務のどこに効くんだっけ」を全員で考える文化がある