認知負荷との戦い〜 freee AIアシスタントの誕生からハーネス改善まで 〜

freee 技術の日 2026 のセッション資料です。

Transcript

2. 認知負荷との戦い 〜 freee AIアシスタントの誕⽣からハーネス改善まで 〜 鈴⽊康平（kouhei） 2026年10⽉3⽇
3. 「これ、Claudeでよくない？」 freee AIアシスタントのプロトタイプを見た、 社内のメンバーからのフィードバック
4. エンジニア 鈴木康平 株式会社MIXIにてモバイルアプリ開発→スター トアップ数社→2023年に情シス領域のプロダクト をfreeeにM&A。 M&A後の情シス領域プロダクトのPMIや機能開 発に携わり、現在は「freee AIアシスタント」の開 発を主導。
5. freee AIアシスタントとは • デモ動画をご覧ください
7. 目次 01 AIアシスタント⽴ち上げの背景 02 新規プロダクト⽴ち上げの難しさ 03 「今ひとつのAI」から「実務を任せられるAI」へ 04 品質をどう保証するのか
8. 01 AIアシスタント誕⽣の背景
9. 情シス領域に向き合いfreee AIヘルプデスクを開発 • 従業員のITリテラシーが⾼くないためヘルプデスク業務に時間を割かれる • →社内の問い合わせ対応を⾃動サポートする「freee AIヘルプデスク」を開発
10. AIに読ませるドキュメントは、どこにも無かった 100社近くのお客様と話して分かったこと ◦ AIに読ませるナレッジがそもそも存在しない ◦ ドキュメントはあるが、従業員に公開する前提の資料ではない ◦ ナレッジはベテランの頭の中にあり、ベテランが現場に出ていると MTGすら開けない ➜ ナレッジを収集するサービスが必要なのでは？など悩む
11. 想定外の使われ⽅が、隠れたニーズを教えてくれた お客様は、ヘルプデスクを"別のこと"に使おうとしていた ◦ 経営企画室の⽅：「経営データをナレッジに登録したら、経営陣がAIと 経営について壁打ちできますか？」 ヒアリングを重ねて分かったこと ◦ 欲しいエージェントは、会社ごとに違う ➜ ユーザー⾃⾝でエージェントを作れる仕組みがあると良さそう
12. スモールビジネスのためのUXを考えた 認知負荷を下げる ◦ Claude Codeの様な黒い画⾯は怖い‧⼼理的ハードルが⾼い ◦ デスクトップアプリもよく分からない ◦ Claude webなどの新しいWebサービスを使うのも億劫 ➜ いつも触っているfreeeの画⾯なら使える
13. 02 新規プロダクト⽴ち上げの難しさ
14. 新規事業は構造的に通しにくい（気がしていた） freee は会社としてボトムアップを推奨している。それでも、起案する側 には構造的なハードルがあると思っていた。 ◦ JM(EM)に⽅針を理解してもらうのは時間がかかる ▪ 「メンバーの話をよく聞く。だが、迎合せずに正しく⽅向づけ、最 後は責任をもって決める。」 ◦ ロードマップを期中に変えて合意をとるのは難しい ◦ 評価を⼿放す覚悟が要る ➜ 最初はヘルプデスクの「1機能」として出すつもりでいた
15. ビジネスアラインで独⽴したプロダクトになった 「AI系のプロダクトで、こういうことをやろうとしています」と相談 ◦ 「やるなら、2ヶ⽉後の『freee 統合ワールド』に動く状態で出そう！」 ◦ 新規事業としてのGOがでて、2〜3営業⽇で10⼈規模の開発チームを組成 ◦ ボトムアップの会社だった ➜ 2週間で動くプロトタイプを作った
16. 「これ、Claudeでよくない？」 freee AIアシスタントのプロトタイプを見た、 社内のメンバーからのフィードバック
17. 03 「今ひとつのAI」から「実務を任せられるAI」へ
18. 「Claudeでよくない？」の正体は、遅い‧⾼い‧間違える 原因 ◦ 遅い → 応答に1〜2分かかる ◦ ⾼い → データ量に⽐例してトークンが膨らむ ◦ 間違える → APIリクエストや集計、計算を間違える ➜ 「モデルが働きやすい環境を整える」ハーネスの改善へ
19. ハーネスとは？ エージェントを構成するモデル以外のすべて エージェント = モデル + ハーネス ハーネス （モデルを取りまく制御のしくみ） ループ制御 ツール実行 モデル （LLM） 終了判定 メモリ
20. モデルが働きやすい環境を整えるとは 問題を、モデル（LLM）が得意な問題に変換すること LLMにやらせないこと LLMにやらせること 複雑な判断をする シンプルな判断を積み重ねる 計算する プログラムを書く ⼤量データを扱う 少量のデータを扱う … …
21. ケース1：500件の取引明細の、合計⾦額を求めたい 取引⼀覧APIのレスポンスを、LLMに渡して合計⾦額を求めさせていた ◦ トークンコストが増える ◦ 計算ミスも発⽣ ➜ APIレスポンスをオフロード
22. APIレスポンスをオフロード（改善前） 💥 計算 freee-api-get 💥 巨大なJSON freee-mcp 回答生成
23. APIレスポンスをオフロード（改善後） freee-api-get Pythonコードを書く 計算結果 JSON Schema freee-mcp DB JSON 回答生成
24. ケース2：500件の取引を、他社形式のCSVにして出したい Pythonで変換した500⾏のCSVを、LLMのコンテキストを介してCSVにしていた ◦ トークンコストが増える ◦ 500⾏のCSV出⼒に1〜2分かかる ➜ Pythonの実⾏結果をオフロード ◦
25. プログラムの実⾏結果をオフロード（改善前） freee-api-get Pythonコードを書く 💥 CSV freee-mcp 💥 create-artifact CSV JSON DB artifact生成 Artifact
26. プログラムの実⾏結果をオフロード（改善後） freee-api-get Pythonコードを書く create-artifact DB Key DB Key freee-mcp JSON DB CSV DB artifact生成 Artifact
27. ハーネス改善のまとめ 「早い」「遅い」に効く改善 ◦ LLMのコンテキストにデータを載せない ◦ LLMにはデータを処理させず、処理するPythonコードを書かせる ➜ LLMの認知負荷を下げる 「間違える」に効く改善 ◦ Skillの修正やシステムプロンプトの改善
28. 04 その品質を、どう保証するのか
29. リリース前レビューで突きつけられた問い 「AIに任せた結果、freee のデータや設定がぐちゃぐちゃになって元に戻 せなくなったらどうするのか？」 ◦ 今のfreeeでも会計データがどうなっているのか分からない⼈がいる ◦ その上でAIに操作させたら、余計分からなくなるのではないか ➜ 精度評価‧改善のしくみを整備することに
30. 精度評価のしくみ オフライン評価 この後の他のセッ ションで詳しく聞け ると思います！ ◦ 期待結果を定義したデータセットで、リリース前に定量検証 ◦ 現状の精度を下回ったらリリースしない オンライン評価 ◦ AIの動作に対するユーザーの反応やフィードバックを収集 ◦ LLM as a Judgeでスコアリング ➜ &サポート体制の構築などと合わせてリリースGOの判断
31. 最後 まとめ
32. まとめ 「これ、Claudeでよくない？」 ◦ ユーザーの認知負荷とモデルの認知負荷の両⽅と戦った ➜ ユーザーの認知負荷を下げるため、普段使い慣れているfreeeの画⾯で、 エージェントを使えるようにした ➜ モデルの認知負荷を下げるため、エージェントのモデルにやらせるタス クをモデルの外に出すハーネス改善へ その品質を、どう保証するのか ◦ ユーザーにはAIが間違えたらどうしようという不安がある ➜ 徹底的に精度に向き合う
33. Thank you! スモールビジネスを、世界の主役に。 中小企業の約7割が、まだAIを使えていないというデータがあります。 そんなスモールビジネスにAIを実装したいのです。