Bet AI Day 2026丨バクラク Autopilot、業務システムの再設計

2026年9月3日に開催されたイベント「Bet AI Day 2026」における登壇資料です。

■ 概要
稟議、承認、帳票への転記、月次決算——私たちが「業務」と呼ぶものの多くは、かつての人間の効率化のための道具の制約が形づくった習慣です。道具が業務をつくり、業務は規程として固まり、いつしか「必然」に見えています。ここに AI をそのまま当てはめても、既存の業務を速くこなすだけで、業務そのものは残り続けます。
バクラクが取り組んでいるのは、AI を前提に業務システムをつくりなおすことです。効率化した業務ではなく、再設計された業務システムを届ける——それがバクラクの目指す「Autopilot」です。その設計思想と現在地をお話しします。

■ 登壇者情報
バクラク事業 プロダクト開発部 Tech Lead 青木 太郎
X: https://x.com/ktr_0731

2019年に株式会社メルカリへ新卒入社し、メルペイのコード決済やメルカリ ハロの開発に従事。2024年4月に株式会社LayerXへ入社し、バクラク申請・経費精算のプロダクト開発にテックリードとして携わっている。

■ 関連リンク
・イベント特設サイト： https://layerx.co.jp/events/2026/bet-ai-day/
・コーポレートサイト： https://layerx.co.jp/
・X Tech 公式アカウント：https://x.com/LayerX_tech

#BetAIDay

Transcript

1. Bet AI Day 2026 AI Agents at Work Engineering / Product バクラク Autopilot、 業務システムの再設計 青木 太郎 Taro Aoki 13:50-14:30
2. Speaker Information ⻘⽊ 太郎 Taro Aoki 2019年に株式会社メルカリへ新卒⼊社し、 メルペイのコード決済やメルカリ ハロの開発に従事。 2024年4⽉に株式会社LayerXへ⼊社し、 バクラク申請‧経費精算のプロダクト開発にテックリードとして携わって いる。
3. Agenda Chapter 1 請求書処理はなぜ複雑なのか Chapter 2 ⼈間主体から、エージェント主体へ Chapter 3 Autopilot の実装‧実践 Chapter 4 Autopilot の現在地とこれから
4. Chapter 1 請求書処理は なぜ複雑なのか
5. ⼀般的な請求書処理の流れ 毎⽉、数⼗〜数百枚の請求書処理が発⽣している。担当者‧上⻑‧経理と多くの⼈が関わっている。 受領 内容 確認 支払申請 提出 承認 仕訳 入力 支払実行 ※ 仕訳以降 消込 本セッションで スコープ外
6. 1 つの⼯程の中に数多くの確認と判断がある 請求書受領 内容の確認 請求書が届かない場合 の催促 宛先‧発⾏元‧請求⽇ などが正しいか 受領漏れや申請漏れの 検知‧催促 申請 承認 社内ルールの確認 ⼆重申請チェック インボイス制度に準拠 した請求書か 転記作業、事前稟議と の紐づけ、部⾨、明細 などの⼊⼒ 事前稟議と請求書、申 請内容がそれぞれ⼀致 しているか 事前に⾏った発注と請 求の差異はないか ⼊⼒内容やエラー内容 の確認‧修正 部⾨や費⽤の按分など の申請ルールが守られ ているか 差戻し時の再申請対応 ⽀払の妥当性の確認
7. ⼈が判断に集中できる構造になっていない • 申請者 ◦ そもそも請求書処理⾃体に不慣れ ◦ 運⽤や請求書の形式によっては⾦額の計算を伴ったりと⾮常に複雑な⼊⼒作業になりうる ◦ ⼊⼒するべき内容が申請者本⼈にも確信が持てていない • 承認者 (上⻑‧経理) ◦ ⼈によって承認時に確認する項⽬‧観点が異なる ◦ ⽉末‧⽉初のピークには⼤量の請求書処理が発⽣し、 その中にある重要な判断が求められる箇所を⾒逃してしまう ▪ 過去申請を分析すると、本来の申請‧承認ルールから逸脱して 申請‧承認されてしまっているケースが⼀定数⾒つかる
8. 事例: AI による⽀払申請の⼊⼒サポート機能 • バクラク申請にて提供中の機能 • 過去の⽀払申請をもとに⼊⼒値を予測‧補完し、申請者の⼊⼒の⼿間を軽減 • ⼈⼒に⽐べ、申請の差戻し率がおよそ 52.2% 減少 多くの定型的な⼊⼒作業では、⼈間より AI のほうが正確
9. Chapter 2 ⼈間主体から、 エージェント主体へ
10. LLM で「個社ごとに異なる業務」がシステム化できるようになった これまでのシステム A社の業務ルール B社の業務ルール C社の業務ルール LLM による変化 A社の業務ルール B社の業務ルール C社の業務ルール 共通部分だけをシステム化 システム ＋ LLM 個社ごとの差分は、 ⼈間の運⽤でカバー 各社のルールを、 そのまま解釈して実⾏ 同じ業務ルールの会社は、⼀つも存在しない。 個社運⽤を単⼀の仕組みで解けるのが、LLM の強み。
11. 再設計とは、⼈間の役割の再定義 • 申請‧承認は内部統制上、⾮常に重要 ◦ 申請者は⽀出についての説明責任がある ◦ 承認者は、取引の実在性や⽀払の妥当性を判断する責任がある • ⼈によって業務品質が異なる ◦ 申請‧承認ルールが整備されていたとしても網羅的ではなく、徹底できるとも限らない • すべての業務が等しく重要なわけではない ◦ 現在のフローにも、定型的に処理できる業務が⼀定存在する ▪ 例: 請求書の回収作業や、内容の把握、転記作業、形式的なチェック • 定型処理は形式知化してエージェントに任せ、⼈間は慎重‧重要な判断に集中する
12. Autopilot の⽬的は、業務をブラックボックスにせず、 ⼈間が判断に集中できる構造をつくること。
13. エージェント主体のシステムへ 定型処理はエージェントにより⾃律的に進められ、判断が必要な場合にのみ申請者‧承認者が対応 エージェント 請求書の受領 申請を⼊⼒‧提出 ⼀次承認 担当者による 追加対応‧判断 承認 (上⻑‧経理) ⼈間
14. Chapter 3 Autopilot 実装・実践
15. システムの詳細図 問題があれば再⽣成 エージェント 請求書の 受領 申請内容 ⽣成 ⽣成内容の 検証 承認レビュー 実⾏ 提出 ⼀次承認 Playbook ⼈間 申請者 申請を引き継ぎ、⼊⼒して 申請者⾃⾝が提出 ⼆次承認 申請者が提出
16. Playbook • ⼈もエージェントも、 読めば同じ品質で業務ができる標準業務⼿順書 • プレーンテキスト‧⾮構造化 取引先や業務ユースケース単 で⽤意 • 過去申請から⽣成後、不明点をお ◦ 過去申請だけでは限界がある 様と形式知化 # 支払申請 - 株式会社 LayerX (デモ用) ## 申請項目 - 取引先: 請求書に記載された取引先名 - 支払金額: 請求書に記載された合計金額 - 支払期日: 請求書に支払期日がある場合は その日付。記載がない場合は、請求書発行日の 翌月末日。いずれも土日祝の場合は前営業日 ## 明細項目 - 一申請一明細を原則とする - 複数の税率が記載されている場合は税率ごとに 明細を作成する。同じ税率の金額は合算する。 ## エスカレーション - 支払金額が 100 万円を超える場合、 必ず人間の確認を求める
17. 内容⽣成〜検証〜承認レビュー 1. Playbook と請求書をもとに内容⽣成 2. Playbook に沿って⽣成できているかの検証 ◦ ◦ 独⽴したエージェントによる 観的な検証 Playbook からの逸脱があればフィードバックつきで 再⽣成させる 3. 承認エージェントによる承認レビュー ◦ ◦ 承認時にチェックされるルールをすべてパスしているか 例: ⽀払期⽇は請求書に沿って正しく⼊⼒されているか i. Playbook と整合しているかぎり違反は起きない ◦ 例: ⼆重申請の疑いがあるか i. 再⽣成しても解決しない問題
18. 申請者へのハンドオフ • エージェントが継続できない場合に申請者へ委ねる • ⼊⼒された内容のどこを確認すれば良いかを伝える • 例 ◦ 申請者しか知り得ない情報 ▪ Web サービストライアルの費⽤対効果の記載 ▪ 検収が済んでいるか ◦ Playbook 通りに進められない例外 ▪ ⼆重申請の疑いがある ▪ 事前稟議 (購買申請) の予算超過 ◦ 設定によるハンドオフ ▪ 完全な⾃動化はせず、申請提出の最終確認は ⼈間が⾏う設定にしている場合
19. Playbook とバックテストを中⼼とした改善サイクル ⻘線は AI が中⼼となって⾏う部分 課題 発見 誤り・ブレ・曖昧さ 過去データや 運用ルールから 初期 Playbook 生成 バックテスト 本番デプロイ 改善 Playbook・ツール・モデル 人間が承認し、 Playbook へ反映 改善提案を生成 暗黙的なフィードバック (申請内容 修正・差戻し)
20. バックテスト • システムの予測精度を過去のデータを⽤いて 評価する⼿法 ◦ 特に Autopilot ではエージェント性能を 評価するために利⽤ ◦ ⾃動化率の概算にも有⽤ • 実⾏例 ◦ 申請内容の⽣成: 請求書と Playbook を⼊ ⼒にし、過去の承認済み申請と⼀致するか ◦ 承認レビュー: 過去申請とレビュールール を⼊⼒にし、期待した指摘ができるか
21. オフライン評価による改善 ⻘線は AI が中⼼となって⾏う部分 課題 発見 誤り・ブレ・曖昧さ 過去データや 運用ルールから 初期 Playbook 生成 バックテスト 本番デプロイ 改善 Playbook・ツール・モデル 人間が承認し、 Playbook へ反映 改善提案を生成 暗黙的なフィードバック (申請内容 修正・差戻し)
22. バックテストを使った改善の例 1. Playbook の曖昧さの解消 a. 特定の申請ルールで、エージェントが頻繁に誤った結果を出す b. Playbook の指⽰が曖昧で、解釈がブレていた c. Playbook の記載⽅法を変更。バックテストでブレが消えたことを確認してからデプロイ 2. ツール組み込み a. 「翌⽉末の最終営業⽇を⽀払期⽇に」というルールで、最終営業⽇を確率的に間違える b. 営業⽇計算ツールをエージェントに組み込み、決定論的に正しい営業⽇を求める 3. 新しいモデルの定量評価 a. ベースラインを計測 → プロンプトガイドに沿ってチューニング → 再度バックテストで改善幅を評価 4. タスクに合ったモデルの選定 a. 利⽤中のモデルにおいて、マルチモーダル性能に課題 b. 複数プロバイダのモデルで同じバックテストを実施 → 特定モデルが著しく良い性能 → 置き換え
23. オンライン評価による改善 ⻘線は AI が中⼼となって⾏う部分 課題 発見 誤り・ブレ・曖昧さ 過去データや 運用ルールから 初期 Playbook 生成 バックテスト 本番デプロイ 改善 Playbook・ツール・モデル 人間が承認し、 Playbook へ反映 改善提案を生成 暗黙的なフィードバック (申請内容 修正・差戻し)
24. お客様が信頼できるエージェントへ エージェント主体のシステムで、「お客様のエージェントに対する信頼」は⾮常に重要 • 判断を任せられない業務は、お 様⾃⾝が完全にコントロールできる ◦ 決定論的な設定と、Playbook 内での指⽰の両⽅ • エージェントがどう考えて⾏動したのかが分かる ◦ 申請者へのハンドオフには、その背景‧理由をセットで添える ◦ 思考が辿れなければ、結局⼈間が⼀から考え直すことになり、業務量が減らない 必要なのはエージェントの仕事を 評価し、信頼し、任せる領域を徐々に増やしていける環境
25. Chapter 4 Autopilot の現在地と これから
26. Autopilot の現在地 • すでに⼀部のお 様へ提供中 • スコープ内の申請の 92.5% が⾃動化可能 • Playbook の改善は⼈間による判断‧実⾏を中⼼にしつつ、改善提案は⾃動化 ◦ Playbook のカバー範囲‧内容の質がエージェント性能を⼤きく左右する ◦ ここをお 様と共に改善していくプロセスは今後も⼀定必要
27. Autopilot のこれから • よりエンドツーエンドの Autopilot、とくに仕訳まで踏み込んだ再設計も進⾏中 • Playbook の⾼速かつ⾼品質な改善がカギ ◦ お 様⾃⾝が直接フィードバックして改善できるように ◦ エージェントによる Playbook の⾃律的かつ継続的な改善により、 ⼈に強く依存しない管理を実現
28. バクラク Autopilot、業務の再設計 • Autopilot はエージェント主体のシステムへの再設計 ◦ すべてに⼈間が主体的に取り組む構造を変え、判断にフォーカスできる仕組みへ • Playbook が業務の中⼼となる ◦ Playbook をいかに⾼速に‧⾼品質につくり、 改善できるかがエージェントの性能を左右する • 任せる範囲はお 様⾃⾝が決める ◦ 絶対に⼈間が⾏う業務‧エージェントに任せて良い業務を、柔軟に設定可能 ◦ 信頼されるエージェントを構築して、 徐々にエージェントの裁量を⼤きくしていけるように
29. 顧客とともに育つエージェントで、 業務を任せられる世界をつくる