はじめに 最近は、AIエージェントを開発に取り入れる事例をよく見かけるようになりました。 私たちのチームでも、比較的規模の大きいシステム刷新プロジェクトでAIエージェントを本格的に導入し、約2か月実際の開発で活用しています。 導入前に期待していたのは、 「AIを使えば大量のコードも短期間で移行できるのではないか」 ということでした。 実際にやってみると、コード生成のスピードは期待以上でした。一方で、AIを安定して活用するためのルール整備や、品質を担保するためのレビュー・修正には、予想以上の時間がかかりました。 振り返ってみると、一番大きな変化は実装速度ではありませんでした。AIと一緒

こんにちは、ラクス技術広報です。 2026年7月15日に開催した主催イベント、「RAKUS AI Conference 2026 Summer」の5本のセッションのうち3本目に登壇したのが、AIエージェント開発課の竹田舜さんです。 テーマは「PoCから本番へ―楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢」。 CTOや役員による組織戦略の話に続き、現場のエンジニアが実際に何を判断してきたのかという、解像度の高い知見が語られたセッションでした。竹田さんが語ったのは、「AI専用の特殊なものというよりは、慣れているもの、知見のあるものを優先して素早く構築しました」という意思決定です。 この記事はこのような方におすすめです AIエージェントをPoCから本番運用へ進めようとしている、あるいはこれから進めようとしているエンジニアの方 AI専用の新しい基盤(AgentCoreなど)を採用すべきか、使い慣れた技術で構築すべきか迷っている方 【目次】 AI専用の基盤を採用する前に、まず問うべきこと β版からの学びを生かした有償版における顧客志向を体現した改善 「見えないAI」を、見える化する 顧客に価値を届け続けるための、地に足のついた選択 AI専用の基盤を採用する前に、まず問うべきこと 竹田さんが担当するのは、2025年12月にβ版を、2026年6月16日に正式版をリリースした、経費精算クラウドサービス「楽楽精算」に組み込まれた「伝票作成AIエージェント」です。領収書を選択し、カードや事前申請などの紐付けデータを選べば、あとはAIにお任せ。伝票ができあがると通知が届き、最後は人がチェックしてそのまま申請する。 楽楽精算初のAIエージェント機能です。 このエージェントを支える実行基盤として、当初は4つの選択肢が挙がっていたといいます。Lambda、ECS、そして開発の途中で登場したAgentCoreのようなAI専用のマネージドサービス、そしてEKS。少人数体制と開発速度を最優先するという制約のなか、竹田さんたちが選んだのはEKSでした。なかでも意見が割れたのはECSとEKSの間で、最終的にはキャッチアップコストの低さと、CIなど既存資産をそのまま活用できる点からEKSを選んだといいます。 「AI専用の特殊なものというよりは、慣れているもの、知見のあるものを優先して素早く構築しました」 理由は明快です。社内にはすでにKubernetes運用の資産とノウハウが蓄積されていて、キャッチアップにかかる時間はほとんど問題にならない。検証環境もオンプレミスでほぼ同等に再現できる。目新しいAI専用基盤に惹かれる場面もあったはずですが、「使い慣れた道具で確実に前へ進む」ことを選んだ判断は、AIエージェント開発の技術選定に悩む読者にとって、一つの参考軸になるのではないでしょうか。 CD(Continuous Delivery: 継続的デリバリー)基盤にも同じ思想が貫かれています。ArgoCDとGitHub Actionsという、社内に知見が蓄積された組み合わせを採用。GitHub Actionsによる自動化とArgoCDの分かりやすいUIによって、「最低限の操作を覚えれば、Kubernetesに詳しくないエンジニアでもリリース作業が可能」になり、オンボーディングコストの低下にもつながったといいます。万一リリースに失敗した際も、ArgoCDのUI上ですぐに気づけるため、Kubernetes有識者へのエスカレーションもスムーズです。 サービス構成は、マネージドサービスとOSSのハイブリッドです。サービス分割の基準は「スケーリングが必要か」「技術の変化が速いか」「コア機能かどうか」の3点。ストレージや監視のように自チームでの運用負荷が高くなりがちな部分には、マネージドサービスを積極的に採用しました。 「プロジェクト開始当初は、ある程度の正解すら分からない状態でした。だからこそ、後からでも要因を切り分けて変更できる構成にしました」 竹田さん自身、「当時ベストだったかは難しい」としつつも、「ベターと言える判断」だったと振り返ります。完璧な正解を最初から追い求めるのではなく、変更可能性を残した意思決定を積み重ねる姿勢は、正解の見えないAIプロダクト開発における実践知の一つだと感じました。 β版からの学びを生かした有償版における顧客志向を体現した改善 β版から正式版への道のりで、竹田さんが一番大きな改善として挙げたのが、KEDA(Kubernetes Event Driven Autoscaling)の導入です。 伝票作成エージェントは、LLM呼び出しなど時間のかかる処理を非同期化しています。当初はこの非同期処理を、キューにメッセージを保管しておき、定期的にメッセージの有無を確認して一定数ずつ処理する、ポーリング方式で実装していました。処理数は一定数で固定しており、1バッチで処理しきれなかった分は、次のバッチ処理に回す仕組みです。 この際、「メッセージ処理数」と「バッチ間隔」のバランスの見極めが悩みどころでした。間隔を短くすればキャパシティオーバーのリスクが高まり、長くすれば顧客を待たせ、UX悪化に繋がります。さらにタイミングによっては、バッチの狭間に入ったリクエストが次のバッチの最後まで待たされてしまう、UXにムラのある状態が生まれていました。 「無駄なくキャパシティオーバーせずに使いたい。リソースに余裕があるときは、即座に近い状態でリクエストに反応したい」 この課題に対して導入されたのがKEDAです。伝票作成エージェントでは、Kubernetesのジョブ単位でもスケーリングできる性質を活かし、キューの件数に応じたジョブ起動数の制御を実現しました。 KEDA導入によるポイント キューの件数に応じてジョブ起動数を比率で制御(例:キュー4件→ポッド2つ起動) 定期実行からリアクティブなイベント駆動アーキテクチャへ転換 マニフェストで運用できるため、既存のKubernetes運用との親和性を維持 これにより、キャパシティオーバーの可能性は下がり、即時反応によって顧客を待たせるリスクも減りました。派手な機能追加ではなく、地道な実装の工夫でユーザー体験を磨き続けた好例だと言えるでしょう。 「見えないAI」を、見える化する 竹田さんが最後に強調したのが、Observability(可観測性)への投資です。「監視は後回しにされがちですが、最初から手をつけてきました」という言葉どおり、伝票作成エージェントではトレース・メトリクス・ログという3種類のテレメトリーを、OpenTelemetry CollectorとFluent-bit経由でAWSのマネージドサービスへ集約する基盤を構築しています。 なぜここまで力を入れるのか。サービスが分割されている以上、処理を追うには分散トレースが欠かせません。また、AIエージェントは複雑かつ不確実に動作するため、何が起きているかの詳細を追う必要があります。AIエージェントの非決定的な振る舞いは「同じエラーでも原因が異なる」ことが珍しくありません。ログのメッセージだけでは判別しづらい不具合の原因究明に、トレースが役立っているといいます。 コストとのバランスも工夫のしどころです。サンプリング率は対象によって使い分けているとのことでした。 対象 サンプリング率 理由 LLM呼び出し関連のトレース 100% 利用状況・モデル利用状況の把握に必須 エラー系トレース(ステータスがエラー/未設定) 100% 障害調査に必須。全体量としても許容範囲 通常トレース(現在) 5% コストを抑えつつ傾向を把握 通常トレース(サービスが不安定だった初期) 70%程度 安定するまでは決め打ちで多めに取得 最初から5%だったわけではなく、安定するにつれて段階的に絞り込んでいったというプロセスが印象的でした。メトリクス収集は、CloudWatch Agentではなくコンテナインサイトレシーバー経由でOpenTelemetry Collectorを利用することで、フィルタリングによるコスト最適化と、環境に応じた柔軟なサンプリング調整を両立させています。ログについては、CloudWatchとS3を保管場所として併用し、利便性とコストのバランスを取っています。このように三種のテレメトリについて、初期からコストを考慮した構成にしています。 こうして蓄積したトレースやログは、監視のためだけでなく次の一手にもつながっています。失敗内容を分析し、推論・ツール呼び出し・バリデーションのどこでつまずいたのかを特定します。顧客からの問い合わせと類似の失敗パターンが見つかった場合は、顧客データそのものは使わずに、原因を再現するダミーデータセットを作成してオフライン評価の改善に役立てているとのことでした。 さらに、現在のオフライン評価に加えてオンライン評価からのフィードバックループの構築や、評価ピラミッドによるテストスコープの整理、評価軸の体系化にも取り組んでいるそうです。 これらはAIエージェント開発課の専任メンバーが中心となって進めており、伝票作成エージェント単体の改善にとどまらず、いずれは全社で使えるプラットフォームとしての整備も見据えているといいます。 顧客に価値を届け続けるための、地に足のついた選択 竹田さんの発表を振り返ると、そこにあったのは「AI専用の目新しい技術を追いかける」姿勢ではなく、「使い慣れた技術で確実に前に進み、実装の工夫で顧客体験を磨き、監視への投資で信頼性を担保する」という、地に足のついた意思決定の積み重ねでした。 この姿勢は、ラクス開発本部が掲げる「顧客志向×AIネイティブな開発組織」という方向性そのものだと感じます。AIネイティブとは、目新しい技術をとにかく採用することではなく、顧客に価値を届け続けるために、既存の資産とAIなどの新しい技術を適切に組み合わせていく選択の連続と言えます。伝票作成AIエージェントの裏側にある技術選定は、その実践の一つの形ではないでしょうか。 「本番運用を任せられるAIエージェントをどう作るか」に悩むエンジニアの方にとって、竹田さんの判断軸が何かのヒントになれば幸いです。 当日の発表資料はSpeakerDeckで公開しています。ぜひあわせてご覧ください。 発表資料 speakerdeck.com なお、8月下旬ごろに発表のアーカイブ動画をラクスエンジニア情報ポータルサイトにて公開予定です。 ラクスエンジニア情報ポータルサイト career-recruit.rakus.co.jp 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ AIを載せることはゴールではない。ラクスCTOと開発副本部長が語った、組織とプロダクトの変革 ・ 顧客の声から生まれた『AI返信補助機能』の開発プロセス ・ 仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える ラクスでは、こうした「顧客課題の解決」に真剣に向き合うAIエージェント開発に一緒に取り組む仲間を募集しています。ご興味を持っていただけた方は、ぜひ採用ページもチェックしてみてください。 最後までお読みいただきありがとうございました！

2026年7月15日、オンラインイベント「RAKUS AI Conference 2026 Summer」を開催しました。本記事では、その中の1セッション「顧客の声から生まれた『AI返信補助機能』の開発プロセス」（登壇：楽楽自動応対AI開発課 四方大輔さん・今井陸斗さん）の内容を、技術広報がレポート形式でまとめます。 「作ったのに使われないAI機能」、心当たりはありませんか 半年間、精度を上げ続けてもお客様の声は変わらなかった 顧客に直接聞いて分かった、担当者が本当に困っていたこと 「メール作成AI」から「メールアシスタント」への方向転換 ドキュメントではなく「動くもの」でお客様と議論する あった方がいいはずの機能が、実は「邪魔」だった AIプロダクト開発で大切な3つのこと エンジニアの仕事は「実装する」から「お客様を理解する」へ speakerdeck.com 「作ったのに使われないAI機能」、心当たりはありませんか AI機能をリリースしたものの、思ったほど使ってもらえない。精度を上げても上げても、現場からの評判は変わらない。AIプロダクト開発に携わるエンジニアであれば、一度はこうした壁にぶつかったことがあるのではないでしょうか。 今回紹介するのは、楽楽自動応対開発チームが、まさにこの壁にぶつかり、そこから立て直していった実例です。結論を先に言ってしまうと、このチームが学んだのは以下の3点でした。 お客様の業務フローを知らずに機能を作ると、使われない機能ができあがる AIで動くPoC（試作品）を即座に作り、ドキュメントではなく「動くもの」で議論する 機能の要・不要を決める「正解」は、現場のお客様だけが知っている この3点は楽楽自動応対に限った話ではなく、AIを使ったプロダクト開発に取り組むエンジニアなら誰でも実践できる考え方だと感じています。以下、実際に何が起きたのかを時系列で見ていきます。 半年間、精度を上げ続けてもお客様の声は変わらなかった 楽楽自動応対は、問い合わせメールをチームで一元管理し、過去の対応履歴を資産として活用しながら応対業務を効率化するクラウドサービスです。主にカスタマーサポートなど、メールを多く扱う現場の担当者に利用されています。 2025年10月、このサービスに「メール作成AIエージェント機能」がリリースされました。受信メールを読み取り、過去の類似の問い合わせを参照しながら、AIが返信文案を自動生成するという機能です。リリース前には精度検証を行い、ビジネスサイドと「使い物になる」ラインをすり合わせた上での公開でした。 ところが、リリース後の利用率は思っていたほど上がりませんでした。ビジネスサイド経由で聞こえてくるお客様の声は「精度が悪い」「使えない」「手で書いた方が早い」というものが多く、なかなか厳しい現実に向き合うことになったといいます。 当時は本番環境でAIがどう振る舞っているかを継続的に追う仕組みが整っておらず、プロンプトの改善やロジックの見直し、モデルの切り替えといった、いわば小手先の精度改善を重ねる日々が続きました。しかし、それでも「使えない」という声は減らず、気づけば半年が経過していたそうです。 顧客に直接聞いて分かった、担当者が本当に困っていたこと 根本的に改善するには、まず現場で今何が起きているかを知る必要がある。そう考えたチームが取った行動は、素直にお客様に話を聞きに行くことでした。 登壇した四方さんは楽楽自動応対の開発を10年近く担当しており、当初はドメイン知識も顧客理解も十分にあるつもりだったといいます。しかし実際にお客様の声を聞く中で、「お客様が実際にどうメール応対業務を行っているか」を全く理解できていなかったことを痛感したそうです。 具体的に見えてきたのは、次のような実態でした。メールの応対業務は一般的にいくつかの工程からなるフローで進みますが、AIが担当するようになったのは「作成」の工程だけでした。AIが作った文面をそのまま使うかというと、多くの担当者はやはり信用しきれず、必ず内容を確認します。つまり、AIで作成を楽にしたつもりが、確認という新たな手間を生み、かえって担当者の負荷を上げてしまっていたのです。 さらに、メール応対はいわゆるフロントオフィス業務であり、メールの品質がそのまま顧客体験の品質に直結します。だからこそ「AIに丸投げする」という発想自体が、現場の感覚とズレていたことも見えてきました。同時期に行われた市場調査でも同様の声が上がっており、「メールを自動生成する」という機能の前提そのものが、お客様に求められていなかったのではという疑いが確信に変わっていったといいます。 「AI活用やAIエージェントというのは、突き詰めればお客様の業務をAIに置き換えることだと考えていたはずなのに、その当たり前ができていなかった」と四方さんは振り返ります。 「メール作成AI」から「メールアシスタント」への方向転換 信用してもらえないという声に応えるため、チームはAIが本文をいきなり自動生成するのではなく、返信を組み立てるための材料を提示する方向へと舵を切りました。コーディングエージェントの「プランモード」に近い発想です。 具体的には、メールの内容を読み取って要点を示したり、類似の過去問い合わせを探したり、大量にあるテンプレートの中から適したものを提案したりと、担当者の作業そのものをAIが肩代わりするのではなく、担当者の判断をAIがサポートする形へと機能を再設計していきました。 とはいえ、AIプロダクト開発において「何を作れば使われるか」が最初から明確なケースは多くありません。「ざっくり楽にしたい」「なんとなく自動化したい」といった、ふわっとした要望から出発することがほとんどだと四方さんは言います。このメールアシスタント機能への転換時も、必要な機能は何か、情報を見せすぎるとかえって読まれなくなるのではないか、といった議論が社内で白熱したそうです。 最終的にたどり着いたのは「正解はお客様に聞くしかない」という発想でした。そして、その正解に最速でたどり着くために取ったアプローチが、後半で紹介する開発プロセスの変革です。 ドキュメントではなく「動くもの」でお客様と議論する 後半のセッションを担当した今井さんは、開発プロセスそのものの変革について紹介しました。 これまでの開発は、ビジネスサイドが要求資料を作成し、それに沿って開発側が要件をすり合わせ、仕様が固まってから実装するという進め方でした。この方法では、実装が完了するまで実際の動きが見えづらく、デザインモックだけでは確認しきれない部分が残ります。結果として、実装後にビジネスサイドへ触ってもらって初めて「なんとなく違う」というフィードバックが出て、手戻りが発生することも少なくありませんでした。 そこで今回は、最初から動くものを仮で作る「PoCファースト」のアプローチを取ったといいます。これを可能にしたのは、AIの進歩によってコーディングの大部分を指示ベースで任せられるようになったことが大きいと今井さんは説明します。PoCの作成にはClaude Codeを活用し、あくまで仮の実装であることを前提に、保守性やコードの綺麗さよりもスピードを優先する、いわゆるバイブコーディングで進めたそうです。 さらに、ビジネスサイドとの検討で「必要かもしれない」と挙がった機能は取捨選択せず、いったんすべてPoCに盛り込みました。実装のほとんどをAIに任せられるため、機能数が多少増えても実装コストがそこまで膨らまない、という判断があったからこそ取れた選択です。 そして重要なのは、このPoCをビジネスサイドだけでなく、実際に機能を使うことになるお客様にも直接見せたという点です。「不要かもしれない」という機能が本当に不要かどうかは、社内の議論だけでは決められません。現場を知るお客様に判断してもらうのが最も確実だと考えたからです。 あった方がいいはずの機能が、実は「邪魔」だった 実際にお客様へPoCを見せた結果は、チームの想定とは異なるものでした。 当初、メールアシスタント機能にはメール本文の要約や、質問に対する回答方針の提示など、返信に役立つと思われる機能を一通り盛り込んでいました。しかしお客様に見せてみると、要約や回答方針があってもAIの回答が100%正しいとは限らないため、結局は本文や過去のやり取りを自分の目で確認する必要があり、時短にはつながらないという意見が返ってきました。「あった方がいい」と思っていた機能が、実際には「邪魔」だった、という気づきです。 一方で、返信に使うテンプレートの提案機能や、作成した本文に対する添削機能は「使える」という評価を得られました。 ターゲットについても発見がありました。当初は返信業務を行うユーザー全員を対象に機能を検討していましたが、経験豊富なベテラン担当者にとっては、AIが出してくる情報を追加で確認する手間がむしろノイズになってしまうという声が上がりました。一方、メール作成に不慣れな新人担当者にとっては、テンプレートを探す時間や、作成したメールを先輩に確認してもらう時間を減らせるという利点が明確でした。この結果を踏まえ、ターゲットは「全ユーザー」から「新人担当者」へと絞り込まれました。 お客様と実際に対話し、業務フローを理解できたからこそ、このようにターゲットを変える判断ができたと今井さんは振り返ります。 AIプロダクト開発で大切な3つのこと 今井さんは、今回の経験から見えてきた学びを、楽楽自動応対に限らずどのようなエンジニアでも実践できるものとして、3点に整理していました。 1. お客様の業務フローを知ること 作ろうとしている機能がどう使われるかを知らずに開発すると、使われない機能ができあがる可能性が高くなります。無駄な機能を作らないためには、まずエンジニア自身がお客様の業務を把握することが欠かせません。 2. AIを使って動くPoCを即座に作ること ドキュメントや文章ベースで議論するよりも、実際に動くものを見ながら議論した方が認識のずれが生まれにくく、圧倒的に効率的です。この段階では機能を絞り込まず、思いつくものはすべて載せて、いったん全体を見える状態にしてから議論することが有効だといいます。 3. できあがったPoCを、実際に使うお客様に見てもらうこと 機能が使えるか使えないかの「正解」を持っているのは、現場を知るお客様です。答えのない状態でビジネスサイドと開発側だけで議論するのではなく、正解を知っているお客様に判断してもらう。この段階で不要な機能を見極めておけば、リリース後の手戻りも減らせます。 エンジニアの仕事は「実装する」から「お客様を理解する」へ 今回の事例のポイントは、開発プロセスを変えたことで開発スピードが上がった、という話に留まりません。AIに実装を任せることで生まれた余白の時間を、お客様と向き合う時間に転換できたことこそが本質だと今井さんは強調していました。 お客様と対話することで、実際に機能が使われる場面への解像度が上がり、より良い機能開発につながります。しかも一度きりではなく、機能をブラッシュアップするたびに繰り返し対話することで、方向性が合っているかを都度確認できるようになったといいます。お客様の業務フロー理解とフィードバックの解消をエンジニア自身が担うことで、エンジニアの仕事は「機能を実装するもの」から「機能を考えるもの」へと、上流にシフトしつつあると感じている、というのが今回のセッションの結びでした。 ラクスが大切にしている「顧客志向」という価値観と、AIによって実装のスピードが上がった「AIネイティブ」な開発とが組み合わさることで、お客様への価値提供を最大化できるようになった。これは楽楽自動応対チームに限った話ではなく、AIプロダクト開発に取り組むすべてのエンジニアにとって参考になる視点ではないかと感じています。 rakus.connpass.com 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ AIを載せることはゴールではない。ラクスCTOと開発副本部長が語った、組織とプロダクトの変革 ・ 楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢 ・ 仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える