伝票作成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 運用が軽い、イベント駆動と相性が良い 長時間処理、複数サービス構成、既 存K8s資産の転用で弱い ECS コンテナ実行環境として扱いやすい 既存資産の転用が弱い、AWSの知 見が少ない AgentCore AIエージェント向け機能に期待できる 成熟度、社内運用知見、周辺基盤と の接続 EKS 既存資産の転用・キャッチアップ工数低い Kubernetesの知見はエコシステム含め、かなりある AWS/EKSは未経験 8
9. 実⾏基盤の選択肢 前提：少⼈数での開発、開発速度が要求 選択肢 選択肢 良い点 懸念 Lambda 運用が軽い、イベント駆動と相性が良い 長時間処理、複数サービス構成、既 存K8s資産の転用で弱い ECS コンテナ実行環境として扱いやすい (⼀部lambda) 既存資産の転用が弱い、AWSの知 見が少ない AgentCore AIエージェント向け機能に期待できる 成熟度、社内運用知見、周辺基盤と の接続 EKS 既存資産の転用・キャッチアップ工数低い Kubernetesの知見はエコシステム含め、かなりある AWS/EKSは未経験 EKSを採⽤ 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