伝票作成AIエージェントを支える、LLMOpsとインフラの選択肢 / AICon2026_takeda

Transcript

1. 2026/7 #RAKUS AI Conference 2026 Summer 伝票作成AIエージェントを支える、 LLMOpsとインフラの選択肢 株式会社ラクス 開発推進部

   AIエージェント課 © RAKUS Co., Ltd. 竹田 舜 1

2. 自己紹介 氏名：竹田 舜 所属：AIエージェント課所属 経歴： Webアプリエンジニアとして、2023/4 ラクス新卒入社 → SRE課に異動して、社内基盤・Platform Engineering系の業務

   → 2025/5〜の発足時からAIエージェント課所属 メインの業務はインフラ〜プラットフォーム系、一部アプリ、組織横断施策 #RAKUS Meetup © RAKUS Co., Ltd. 2

3. 伝票作成AIエージェントとは？ 領収書を選択したあとは確認作業だけ！問題なければそのままの内容で申請できます。 STEP1 STEP2 STEP3 STEP4 領収書の選択 紐づけデータの確認 通知を確認 申請内容の確認

   3 ※現時点での予定となり、リリース内容は変更となる可能性がございます。 #RAKUS Meetup © RAKUS Co., Ltd. 3

4. 今日の本題 伝票作成エージェントを作る上での チームの判断と技術詳細 #RAKUS Meetup © RAKUS Co., Ltd. 4

5. 伝票作成AIエージェントの構成は？

6. 全体アーキテクチャ概要 6

7. なぜこの技術選定にしたのか？

8. 実行基盤の選択肢 前提：少人数での開発、開発速度が要求 選択肢 選択肢 良い点 懸念 Lambda 運用が軽い、イベント駆動と相性が良い ECS コンテナ実行環境として扱いやすい

   既存資産の転用が弱い、AWSの知 見が少ない AgentCore AIエージェント向け機能に期待できる 成熟度、社内運用知見、周辺基盤と の接続 EKS 既存資産の転用・キャッチアップ工数低い Kubernetesの知見はエコシステム含め、かなりある AWS/EKSは未経験 8

9. 実行基盤の選択肢 前提：少人数での開発、開発速度が要求 選択肢 選択肢 良い点 懸念 Lambda 運用が軽い、イベント駆動と相性が良い 長時間処理、複数サービス構成、既 存K8s資産の転用で弱い

   ECS コンテナ実行環境として扱いやすい AgentCore AIエージェント向け機能に期待できる 成熟度、社内運用知見、周辺基盤と の接続 EKS 既存資産の転用・キャッチアップ工数低い Kubernetesの知見はエコシステム含め、かなりある AWS/EKSは未経験 EKSを採用 (一部lambda) 既存資産の転用が弱い、AWSの知 見が少ない 9

10. EKSを採用した理由 • 既存資産の活用 • キャッチアップ速度 • オンプレでもほぼ同等の環境を用意可能 ❌ AI→専用の特殊なもの こちらを優先

    ⭕ 慣れている・知見のあるもの 10

11. CD基盤はArgoCD＋Github Actionsを採用 ・社内に知見蓄積がある ・Actionsによる自動化 + UIがある →最低限操作覚えれば、リリース作業可能 オンボーディングコスト低 ・失敗時もすぐわかる →エスカレーションが容易

    総合的に意外と難しくない！！ 11

12. ここまで基盤よりの話、次はアプリ

13. AWSマネージドサービス・OSSのハイブリッド構成 M + OSS OSS Managed 13

14. サービス分割 スケールリング必要‧ スケールリング必要・ 技術‧プロトコルの 技術・プロトコルの 移り変わりが 移り変わりが 早そうなもの 早そうなもの コア機能に

    コア機能に 関係ない 14

15. PJ開始当時(2025/5〜)はある程度の正解すらない • 後からでも変更できる分割構成 • プラットフォームに関しては社内のスタックとの親和性を重視 • 自チームで運用できるようにマネージドサービスを多数採用 当時の状態でのBetterと言える判断をした 15

16. そして... 「楽楽AIエージェント for 楽楽精算」として 2025年12月1日 β版を提供開始！！ ↓ 現在は 「伝票作成AIエージェント」として 正式版を2026年6月16日（火）より提供中！！

17. ここまで触れてないやつが１つある

18. KEDA！！！

19. 実はKEDAは最初から入っていたわけではない 顧客UXを考えた上で要求に答えるため導入された β版→正式版の間の大きな改善

20. KEDA導入前の非同期リクエスト処理 • AIエージェントの処理の一部を非同期化していた • 定期起動→キューを一定数処理の繰り返し ◦ • 一定数に収まらないキューは次のバッチ処理へ システムのキャパシティ範囲内になるように十分に間隔を開ける必要あり バッチ間隔

    短：キャパオーバー 長：待ち時間を持て余すリスク 処理 待ち 待ち 20

21. タイミングが悪いとかなりユーザーが待つ →UXに悪影響

22. KEDA導入前の非同期リクエスト処理 • AIエージェントの処理の一部を非同期化していた • 定期起動→キューを一定数処理の繰り返し どうにか無駄なく、 ◦ 一定数に収まらないキューは次のバッチ処理へ キャパオーバーせず使 えないか。

    システムのキャパシティ範囲内になるように十分に間隔を開ける必要あり • リソースの余裕ある時は 即時に近い状態で リクエストに反応したい バッチ間隔 短：キャパオーバー 長：待ち時間を持て余すリスク 処理 待ち 待ち 22

23. そこで、、、

24. Kubernetes Event-driven Autoscaling （KEDA） キューと連動したJobの処理を可能にするK8s Operator 同時並列起動数やスケーリング比率(4キュー待機→2Pod起動)制御が可能 24

25. 定期実行からリアクティブなイベント駆動へ変更 キャパオーバー → 可能性 低 待ち時間を持て余すリスク → 可能性 低 待ち時間削減

    → UX改善 K8sとの親和性 もバッチリ

26. ここまでがアプリ寄りのインフラの話 次はLLMOpsに繋がる可観測性(observability:o11y) の話

27. observability基盤の全体設計 • トレース＆メトリクスはOtel Collector & AWSマネージド サービスで構築 • ログはFluent-bitを採用 送信先はCloudWatch(+S3)

    27 ※1. ラクス社員による記事： https://speakerdeck.com/gumamon/otelcol-tailsampling-and-spanmetrics

28. なぜobservability基盤が必要なのか？

29. 複雑＆不確実な動作をするため、詳細が追いたい • スケーリングや役割分担の観点からサービスを分割 ◦ • AIエージェントの非決定的な動作 ◦ • 処理を追うためには分散トレースが不可欠 同じエラーでも原因となる中身の要因が全然違うことがある

    トークン数の追跡 ◦ 実際に１セッションでどれくらいのトークン数がかかったのか ◦ 異常な動作の検知にも役立つ 各種テレメトリ※でサービスやAIエージェントの動作の透明性を担保 29 ※システムの内部状態を把握するために収集‧分析されるデータ群

30. トレースやメトリクスの技術的工夫ポイントを一部紹介 主にコスト制御がメイン

31. トレース：サンプリングとLLMコスト制御 CloudWatch GenAI Dashboardからトークン数と処理が追跡可能なように 対象 サンプリング率 理由 LiteLLMかつGenAI属性 あり 100%

    トークン利用量とモデル利用状況を把握 Statusが Error/UNSET 100% 障害調査に必要 通常トレース 5% コストを抑えて傾向を見る、 初期は70% 持続可能なコストと可観測性を両立させる 31

32. container insight Receiverによるメトリクスの収集 container insight Receiverを利用してコスト削減しつつメトリクスを収集 • CPU、メモリなどのメトリクスを取得 • container

    insightをCloudWatch Agentで取ると、メトリクスのフィルタリングができずコストがかかる ◦ Otel Collector経由で取ることでフィルタリングによるコスト削減、不要なメトリクスの削減が可能 ◦ 普段はsampling間隔を落とし、負荷試験環境ではsampling間隔を上げる。取得メトリクスの変更 container insight Receiver Filter Processor awsemf Exporter CloudWatch logs Otel CollectorによるContainer Insightコスト最適化についてはこちらが参考になる https://aws.amazon.com/jp/blogs/containers/diving-into-container-insights-cost-optimizations-for-amazon-eks/ 竹田が書いた記事はこちら https://tech-blog.rakus.co.jp/entry/20251202/otel-collector 32

33. LLM関連のメトリクスはInvocation logから自動算出 • CloudWatchの機能 • トークン数やレイテンシーのメ トリクスが取得可能 33

34. チームで必要とするものを 節約して取得できるようにしている

35. ここまでは基盤の必要性・技術的な話 次は取れるデータをどう生かしていくのかの話

36. トレース・ログの結果を元にデータセット構築 失敗内容を分析し、データセット構築に繋げる トレース/ 実行結果 • 人間による 原因の分析 データセット への反映 トレースで詳細にエージェントの動作を残しておくことで、推論・Tool・バリデーションのどこで失敗したのかが

    わかる→場合によっては顧客ヒアリングなどで情報調査 • 原因を元に同等の状態を再現するダミーデータセットを作り、エラーなく動くようにすることで動作の改善がで きる 36

37. 他にも発展的な取り組みを紹介

38. （今後）オンライン評価からのフィードバックループの構築 現在 トレース/ 実行結果 人間による 原因の分析 データセット への反映 (自動化) 原因の分析

    データセット への反映 目標 トレース/ 実行結果 オンライン判定 オンライン評価対象をどうするかなど AIエージェント課の専任メンバーが取り組んでいる 38

39. (今後)評価ピラミッドによるテストスコープ分割 テストの分類基準を作成し、評価対象を明文化する 伝票作成AIエージェントの評価安定、組織全体への展開による品質アップ レイヤー 主な対象 役割 見るもの Simulations 確率的・統合 入力から最終出力ま

    でまとめて評価 業務成果 Evals & Optimization 確率的・個別 個別ステップを評価 ステップ↔品質間の 影響関係 Unit Tests 決定的 LLMを介さない処理 の検証 決定論的処理が崩れ てないか AIエージェント課の専任メンバーが取り組んでいる 39

40. (今後) 評価観点タクソノミーによる評価目的に応じた観点の整理 • タクソノミーを作成して観点整理 これを元に評価範囲を考慮 • エージェントの振る舞いにフォーカス タスク達成・出力品質 • 他の項目を普段から見るのはコストが高い

    不具合や指標悪化時にみる タクソノミーの出典：https://arxiv.org/html/2507.21504v1#:~:text=Figure%201.,LLM%20Agent%20Evaluation AIエージェント課の専任メンバーが取り組んでいる 40

41. 発展的な内容についても要求が決まってきたら プラットフォーム整備対応を進める予定

42. まとめ #RAKUS Meetup © RAKUS Co., Ltd. 42

43. ラクスAIエージェント課の意思決定 • 実行基盤 ❌ AI→専用の特殊なもの ⭕ 慣れている・知見のあるもの • UX 実装の工夫でリソースが許す範囲内で最適なものを提供

    KEDAによるイベント駆動 • observability 最初から手厚く、評価にも生かす 43