こんにちは！AIエージェント開発課です。
近年、生成AIの進化スピードは凄まじく、単なるテキストの要約やドラフト生成の枠を超え、自律的に判断してタスクを実行する「AIエージェント」が大きなトレンドとなっています。
このような技術的な潮流の中、私たちのチームは2025年5月に「AIエージェント開発課」として産声を上げました。累計導入社数 約20,000社以上の顧客基盤と、16年以上にわたって蓄積された膨大な業務データ（ドメイン知識）というラクスの強みを活かし、バックオフィス業務の「完全自動化」という未来へ向けて、日々泥臭く開発を続けています。
私たちがメインで取り組んでいるのは、主力プロダクトである「楽楽精算」へのAIエージェント機能の実装です。
この記事では、私たちが直面した「3つの壁」とそれを突破した設計原則、そしてそこで得られた知見を社内の他プロダクトへ共通LLM基盤として還元していくファーストペンギンならではの面白さについて、生々しい試行錯誤のプロセスを交えてお届けします。
「プロダクトへAI機能を実装してみたいけれど、何から手をつければいいかわからない」「大規模言語モデル（LLM）の不確実性を前にアーキテクチャ設計で立ち止まっている」というエンジニアの皆さんに、明日から試せるヒントとして届くことを願っています。
- ラクス最先端の挑戦を担う「AIエージェント開発課」とは
- 主力プロダクト「楽楽精算」をAIネイティブへ進化させるミッション
- 理想と現実。リリースへ向けて立ちはだかった「3つの壁」
- 技術的工夫で壁を突破した「設計原則」
- ファーストペンギンとして「共通LLM基盤」を検証・構築する面白さ
- 技術を「机の上から社会の中へ」実装したいエンジニアへ
ラクス最先端の挑戦を担う「AIエージェント開発課」とは
AIエージェント開発課は、エンジニアだけでなくUXデザイナーやビジネスサイドのメンバーも内包する、9名のクロスファンクショナルな少数精鋭チームとして立ち上がりました。
従来のラクスの開発スタイルは、「熟考を重ねた綿密な設計と、確実な法要件対応」を最大の強みとしていました。しかし、数日単位で前提が変わる現在のAI領域においては、既存のやり方に縛られない高速な試行錯誤（仮説検証ループ）が求められます。
そこで私たちは、顧客の「一次情報」に最も早くアクセスできるよう、開発本部の枠からあえて飛び出し、ビジネスサイド直結の組織という特異な構造を選択しました。職能の垣根を完全に取り払い、顧客ヒアリングの結果を受けて全員でUI/UXの改善案を出し合うような「オールラウンド型チーム」を醸成するのが狙いでした。
※現在はファーストリリースを終えたため、開発本部へ戻っています。
主力プロダクト「楽楽精算」をAIネイティブへ進化させるミッション
私たちが最初に課されたミッションは、「楽楽精算」における経費申請ワークフローの自動化、すなわち「伝票作成AIエージェント」の開発です。
従来の経費精算では、申請者がスマートフォンなどで領収書をアップロードした後、自ら手作業で関連する事前申請やクレジットカードの利用明細をデータの山から探し出し、それらを一つひとつ目視で確認しながら紐付ける必要がありました。この「めんどくさい」「煩わしい」という体験を、AIエージェントの力で根本から変えることが私たちの目的です。
利用イメージとしては、ユーザーが領収書を選択するだけで、AIエージェントがその内容を意味的に推論し、関連するデータを裏側で自動的に探し出して申請用の伝票の下書きを作成します。申請者は、最後に「内容を確認するだけ」という、入力作業ゼロの世界を目指す挑戦が始まりました。
理想と現実。リリースへ向けて立ちはだかった「3つの壁」
「領収書を投げれば、AIが考えていい感じに伝票をつくってくれる」と言葉にするのは簡単ですが、いざ本番運用を前提とした開発に着手すると、AIならではの不確実性と、大規模なプロダクトゆえの制約が、重い壁となって私たちの前に立ちはだかりました。
【コストの壁】大規模クラウドサービスならではの推論量とLLM費用の問題
最初の壁は「コスト」でした。
LLMに対して、領収書データ、事前申請の候補リスト、個社ごとの勘定科目マスタ、さらには過去の申請履歴といった大量のコンテキストを愚直に流し込んで推論させると、1リクエストあたりのトークン消費量が爆発的に跳ね上がります。
検証段階でLLM費用の試算を行った際、このまま数万社という規模のお客様に機能を提供すれば、莫大な運用コストが発生し、事業継続性（Viability）が破綻しかねないという現実に直面しました。
【精度の壁】個社ごとに異なる複雑な社内ルールにどう寄り添うか
2つ目の壁は「精度」です。
経費精算というドメインは、法規制だけでなく、「この部署のこの用途なら勘定科目は交際費にする」「交際費の備考欄には必ず同席者の氏名と人数を記載する」といった、企業ごとに異なる明文化しづらい独自のルールが無数に存在します。この独自ルールが汎用的なLLMモデルでの推論精度に大きく影響しました。
【応答速度の壁】完了までの待ち時間、ユーザー体験を損なわないための葛藤
3つ目の壁は、ユーザーが体感する「応答速度（パフォーマンス）」でした。
伝票作成のワークフローの中で、データの検索、仕訳の推論、構造化出力の生成など、複数回のLLM呼び出しを同期的に（順番に待ちながら）実行する設計にしていたため、画面のローディングが完了するまでに最低でも5～15分という、とてつもない時間がかかってしまうことが判明しました。
その結果、画面遷移を同期的にすると「自分で入力した方が早い」という感想を持たれてしまったのです。この応答速度の遅さは、リリースを阻む最大のボトルネックとして私たちの前に横たわっていました。
技術的工夫で壁を突破した「設計原則」
これらの課題に対して、私たちは「最新のモデルをただ叩く」というアプローチを捨て、ラクスが大切にしてきた「顧客志向（誰のどんな課題を解決するか）」の原点に立ち返り、泥臭いアーキテクチャの変更と設計原則の再定義を行いました。
「ルールを考えさせる」から「お手本を真似させる」への転換
開発が大きく前進したブレイクスルーは、β版公開後のタイミングで導入した「ベクトルDBを用いた過去伝票のコンテキスト注入」でした。
それまでは、LLM自身に「複雑な社内規定や多様な仕訳ルール」を解釈させてゼロから深く推論させようとしていましたが、これでは推論の難易度が上がり、精度が出ないばかりか処理コストも膨らむ一方でした。
そこで私たちは、アプローチを転換しました。過去に確定した膨大な伝票データから、ベクトルDBを用いて「申請者本人が過去に作成した、今回と最も類似している確定伝票（真に正しいお手本）」を高速に検索。そのお手本データをプロンプトの「コンテキストとして補強する」RAGアーキテクチャを採用しました。
LLMに高度なルール解釈を強いるのをやめ、目の前に提示した正しいお手本を「そのまま真似しなさい（Few-Shot）」と指示する。この設計により、LLMが迷うことなく一瞬で正確な伝票を作成できるようになり、精度が劇的に向上しました。さらに、深く考えさせるプロセス（推論の難易度やループ回数）を大幅に下げられたことで、高額な推論コストをカットし、LLM費用を当初の数十分の一にまで抑え込むことに成功したのです。
AIの不確実性を受け入れ、既存のルールベース機能と組み合わせるハイブリッド構成
精度の壁を乗り越えるための私たちの結論は、「AIに完璧を求めない」ということでした。ハルシネーションをプロンプトだけで完全に防ぐのは不可能です。
そこで、AIの責務を「高速にドラフト（下書き）を作成すること」に特化させ、出力されたデータの正当性の担保は、「楽楽精算」が元々持っている強力なルールベースの「規定違反チェック機能」に委ねるというハイブリッドな構成を採用しました。
AIが推論した結果に矛盾や規定違反があれば、既存の強固なシステムが検知して申請前に画面上でユーザーに「確認」を促します。人間が最終的な「確認・承認」の責任を持つ「Human-in-the-Loop」の思想を取り入れたことで、AIの利便性を活かしつつ、業務システムとしての絶対的な安心感と確実性を担保することができました。
「定期起動」から「イベント駆動」へ。非同期アーキテクチャ進化の裏側
応答速度の課題は設計段階からある程度想定していました。伝票作成のような重い処理をユーザーを待たせながら同期的に実行するのは現実的ではないと早い段階で判断し、当初からAWSの「Amazon SQS」を用いた非同期処理をアーキテクチャの前提としていたのです。
とはいえ、ファーストリリース時点では、キューに溜まったリクエストを一定間隔で確認しに行く「定期起動」方式で処理を捌いていました。ところがベータ版として実際にユーザーに使っていただくと、この定期起動の間隔そのものが待ち時間のボトルネックとなり、「思ったより遅い」という声が集まってきたのです。
そこで私たちは、Kubernetesのイベント駆動型オートスケーラーである「KEDA」を導入。キューに溜まった未処理の伝票作成リクエスト数に応じて、K8s jobをスケーリングする仕組みへと進化させました。
この改善を反映したベータ版をリリースした結果、ユーザーは領収書を「まとめて一括で投げる」だけで、ローディングを待つことなく次の画面へ進めるようになり、AIの処理が裏で完了したものから順次、確認・申請ができるという圧倒的にスムーズな体験（従来比約40%の工数削減）へと昇華させることができました。
ファーストペンギンとして「共通LLM基盤」を検証・構築する面白さ
私たちAIエージェント開発課のミッションは、単に「楽楽精算」の機能を良くすることだけではありません。ラクス開発本部のビジョンである「AIネイティブな開発組織への変革」を牽引するファーストペンギンとして、自ら検証したアーキテクチャを全社の「共通LLM基盤」として型化し、波及させていくことに大きなやりがいがあります。
ビジネスロジックと責務を分離する「LLMゲートウェイ」の構築
開発を進める中で、各プロダクトのアカウントから外部のLLMプロバイダーへ直接APIを叩きに行くと、リトライ制御やモデルのバージョン管理、レートリミット対策がアプリケーションコード内に散らばり、保守性が著しく低下するという課題が見えてきました。
そこで私たちは、独立した抽象化レイヤーとして、プロキシ層となる「LLMゲートウェイ」をAmazon EKS上に構築しました。
ここでは、プロバイダーのAPI障害が発生した際に、自動で別リージョンや別モデルへリクエストを切り替える「フォールバック制御」や、一時的なネットワークエラーに対するリトライ処理を一元管理しています。アプリケーション側のビジネスロジックから外部AIへの依存性を完全に分離したことで、外部APIとの接続に関わる改修コストを最小限に抑える足回りを構築しました。もちろん、モデルを差し替えたからといって、そのまま期待通りに動作するとは限りません。モデル固有の出力特性やハルシネーションの傾向変化に伴い、アプリケーション側でのプロンプトの微調整や追加のバリデーション改修は必要になりますが、そうした検証と変更のサイクルを素早く回すための強固な土台となっています。
他チームのコンパスとなる「オブザーバビリティ（監視基盤）」の検証・構築
AIエージェントが本番環境で「今、どんな推論をして、なぜそのエラーを起こしたのか」を追跡する仕組み（トレース収集）は、プロダクト運用において死活問題となります。
私たちは、OpenTelemetry（OTel）Collectorを活用したログ・メトリクス・トレースの収集基盤を他プロダクトに先んじてEKS上に検証・構築しました。
当初、AWS Distro for OpenTelemetry（ADOT) Collectorと呼ばれる配布ディストリビューションを利用していましたが、必要なプラグインが不足していたため、自分たちでカスタムビルドを行うなど、かなり泥臭い対応も経験しています。
この基盤により、Amazon CloudWatchのダッシュボード上に、リアルタイムでのトークン消費量やエラーレート、エージェントの推論プロセス（トレース）が綺麗に可視化できるようになりました。
楽楽精算での検証が、他プロダクトの道標になるダイナミズム
私たちが「楽楽精算」の伝票作成AIエージェントを通じて血を流しながら検証したこれら「LLMゲートウェイ」や「オブザーバビリティ基盤」のアーキテクチャマニフェストは、開発本部全体へ展開され大きな反響を呼びました。
個別最適のサイロ化に陥りがちな複数プロダクトの開発組織において、自分たちの小さな試行錯誤が、数百名の開発体験（DevEx）を一気にAIネイティブへと変革していく「全体最適」のダイナミズムを肌で感じられることこそが、この課で働く最大の面白さだと断言できます。
これら取り組みについては、Amazon Web Services ブログに寄稿した記事にも詳細がございます。ぜひ、ご覧ください。
技術を「机の上から社会の中へ」実装したいエンジニアへ
ラクスのAI開発の根底にあるのは、論文の精度を競う研究ではなく、日々の業務の中で実際に動くシステムをつくり、数万社のお客様の働き方を変えていくという「実装主義」の思想です。
AIエージェントという不確実で正解のない未知の領域だからこそ、私たちは完璧を待つよりも、仮説を立てて小さく試すスピードを何よりも大切にしています。
私たちが構築した足回りはまだ完成形ではありません。2030年の「完全自動化」という高いゴールに向けて、これからさらに「個社別のルール最適化」や、「領収書収集から伝票作成までの自動化」、「共通LLM基盤」の整備など、エキサイティングな課題への挑戦が続いていきます。
「AIの力で、働く人の日常を本質的に『楽！』にしたい」
「最先端の技術を自らの手で社会のインフラへと落とし込んでみたい」
そんな熱い顧客志向とAIネイティブな視点を持ったエンジニアのあなたと、これからのクラウドサービスの新しい常識を一緒に創り上げていける日を、AIエージェント開発課一同、心から楽しみに待っています！
