AIで広く見渡し、深く考え、速く価値にする ー AIを実運用へつなげるための設計

AIを現場で使える形にするには、モデルの性能だけでなく、業務の判断やシステムの設計、評価・運用まで一体で考える必要があります。本記事では、PayPayでForward Deployed Engineer（FDE）としてAI活用に取り組む岡本が、これまでの実装・評価・運用の経験をもとに、AIを現場の価値へつなげるための考え方を紹介します。

はじめに

リアルタイム音声AIの開発に取り組んだ際、電話接続を使って検証すると、AIによる回答生成自体は成功しているものの、会話の間合いや応答の安定性まで含めて見ると、実運用に向けて改善すべき点が残っていました。ログを追ってみると、課題はAIモデルの性能ではなく、利用者の発話をどこで区切るか、生成した音声をいつ返すか、再生中の割り込みをどう制御するかにありました。

開発を進める中で、AIが正しい回答を生成できることと、それを利用者が安心して使える体験に仕上げることは別だと改めて感じています。両者の間には、業務理解、体験設計、評価、運用という長い距離があります。その距離を1つずつ埋めていくことが、AIを現場へ届けるエンジニアリングだと考えています。

私自身は、大学・大学院で機械学習やコンピュータビジョンを研究していた頃からAIに関わり始め、その後はAIをプロダクトや業務の中で使える形にすることに取り組んできました。現在はPayPayでさまざまなAI活用に関わり、現場のメンバーと課題を整理し、設計、実装、検証まで一貫して担っています。

AIは目的ではなく、価値を届けるための手段です。本記事では、これまでの開発実践を例に、PayPayでAI活用に向き合う中で感じていることを紹介します。

AIの位置は、業務から決める

AIの話をすると、モデル選定、RAG（関連するナレッジを検索して回答生成に活用する仕組み）の設計、ツール連携、評価基盤といった技術や方法論から考え始めがちです。もちろん、それらは重要です。モデルやアーキテクチャ、開発プロセスを適切に設計することは、現場で使えるAIを作るうえで欠かせません。

ただ、最初に考えるべきなのは、AIに何をさせるかではありません。まず、その業務の中で何が課題になっていて、どこで判断が必要になり、どこに時間や負荷がかかっているのかを理解します。そのうえで、「AIで何ができるか」から始めるのではなく、業務のボトルネックから、AIをどこに置けば価値を出せるのかを逆算します。

AIを回答役として置くのか、情報を集めて整理する役割にするのか、複数のシステムやツールをつなぎながら業務を進める役割にするのか、人の判断を支える役割にするのか。AI単体の性能ではなく、業務全体の中での位置づけを決める必要があります。

たとえば、顧客対応のような業務を考える場合、まず理解しなければならないのは、現場で問い合わせをどのように分類し、どのような判断で対応を分けているかです。どの問い合わせは定型的に案内できるのか、どこで追加確認が必要になるのか、どの内容は慎重に扱うべきなのか、どのケースは担当者や専門部署で対応しているのか。こうした業務上の判断を整理して初めて、AIをどこに置き、どの範囲を任せるべきかが見えてきます。

これは単なるプロンプト設計ではなく、業務設計でもあります。場合によっては、AIを入れるよりも、業務フローや既存システムを改善する方がよいこともあります。固定ルールや業務整理、シンプルな業務アプリ化や可視化で解けるのであれば、そちらを選ぶことも、目的から逆算したAI活用の判断だと考えています。

音声AIで分かった「正しく答える」と「使える」の違い

音声AIでは、正しい回答を生成できることと、会話体験として成立することは別です。

ここで届けたい価値は、AIが話すこと自体ではなく、利用者が必要な情報に迷わずたどり着き、サービス側が安定した対話を提供し続けられることです。

チャットであれば、多少の待ち時間があってもユーザーは画面を見ながら待てます。しかし音声では、わずかな間の取り方や返答の長さが、会話の印象を大きく変えます。利用者の発話をどこで一区切りと判断するか、いつ応答を始めるか、うまく聞き取れなかったときにどう確認するか、発話が重なったときにどう扱うか。回答内容だけでなく、会話の流れそのものを設計しなければなりません。

電話基盤とリアルタイム音声AIの間では、音声や制御メッセージが双方向に行き交い、会話の状態を一貫して扱う必要があります。これまでに取り組んだ実装の一例では、その接続と状態管理を担うBridgeを、Pythonのwebsocketsライブラリで実装し、ECS上で動かしました。Bridgeは、音声や制御メッセージを中継しながら、発話の区切り、AI処理の開始、応答音声の送信、再生状態を管理するアプリケーションです。CloudWatch Logsでは、それぞれの処理を分けて追跡できるようにしています。

電話接続では、AIが応答音声を返している間も、接続を保つためのメッセージや次の音声入力を受け取り続ける必要があります。そこでBridgeでは、音声送信を受信処理から切り離し、非同期に動かしました。

ところが、実際に電話で試すと、前の応答が再生を終える前に次の会話ターンが始まり、再生待ちの応答がたまることがありました。ログを時系列で追うと、Bridgeが音声を送り始めてから、電話基盤から再生開始の通知が届くまでのわずかな間に、次の発話が通常の会話ターンとして処理されていたのです。

そこで、応答音声の送信開始から再生完了までを一続きの「AIの応答中」として管理し、その間に受け取った発話は一時的に保持して、再生完了後に順序どおり処理するようにしました。この変更により、再生待ちの応答をためることなく、会話を正しい順序で進められるようになりました。1つの処理を止めないことと、会話全体を正しく進めることは別の問題です。リアルタイム音声AIでは、処理を非同期化するだけでなく、会話の状態をどこからどこまで一続きとして扱うかを設計する必要があります。

この状態管理と、再生中に受け取った発話の扱いを図に示します。

ターン制御だけでなく、音声AI全体の応答を評価するため、音声区間検出、ターン終了判定、音声認識結果の確定、AI処理の開始、音声合成の初回出力、再生完了までを分けて確認しました。特に、音声が流れ始めるまでと、応答全体が完了するまでを分けて見ることで、体感上の待ち時間とシステム内部の処理時間を混同しないようにしました。ログで処理の状態や時間を確認するとともに、実際の音声を聞き、会話として不自然な間や割り込みが生じていないかも確かめました。

発話の終わりを早く確定すれば応答は速くなる一方、話し手が考えるために置いた間を終端と誤認し、発話途中で応答を始める可能性が高まります。反対に、十分な待ち時間を取れば誤判定を抑えられても、応答の遅さが会話のテンポを損ないます。こうしたトレードオフをログから追い、どこで体験が崩れたのかを評価できるようにしました。

すべてをリアルタイムに生成することが最適とも限りません。たとえば、毎回内容が変わらない冒頭の案内は、その場でAIに生成させるのではなく、事前に生成しておいた音声を呼び出して再生する方が、速く安定した体験を作れます。一方で、利用者の状況に応じて内容が変わる部分では、AIが文脈を踏まえて応答する価値があります。AIを使う部分と、決められた処理にする部分を分けることも、会話全体を設計するうえで重要な判断でした。

会話の流れに加えて、誤った応答の影響が大きいケースをどのように安全な処理へ切り替えるかも、難しい課題でした。どのケースには通常どおり応答し、どのケースでは固定的な案内、追加確認、人による対応への切り替えを行うのか。まず業務上のカテゴリと期待する挙動を整理し、AIが応答してよい範囲と、安全な処理へ切り替える条件をガードレールとして定義します。ここでいうガードレールは、慎重に扱うべき入力を見分けるだけでなく、AIが担う応答の責任範囲と、その範囲を超えたときの処理を定めるものです。

ただし、同じ意図でも、言い換え、文字起こしの揺れ、前後の文脈によって表現が変わります。ある表現で想定どおりに動いても、同じカテゴリの入力を一貫して扱えるとは限りません。

個別の失敗例に合わせてプロンプトやコンテキスト、判定ロジックを調整すると、そのケースでは改善しても、別の言い換えを見逃したり、通常の入力まで過剰に検知したりすることがあります。そのため、局所的なチューニングで終わらせず、同じカテゴリの言い換えや文字起こしの揺れに加え、誤検知しやすい通常の入力も評価セットに含め、見逃しと過剰検知の両方を確認します。

基準となる評価セットと評価指標は維持しながら、新たに失敗したケースを回帰確認用として蓄積します。変更後は、既存ケースを含む同じ基準で、狙った改善が得られたか、ほかのケースの品質を損なっていないかを確認します。期待する品質を満たさなければ変更前の状態へ切り戻す。こうした一連の流れまで運用に組み込むことで、ガードレールを継続的に改善できるようになります。

設計の対象はAIモデルだけに限らず、それを支えるアプリケーションやインフラ、運用にも広がります。現場と技術を広く見渡しながら、素早く形にして試し、失敗から学んで改善を重ねることに、AIを現場へ届けるエンジニアリングの価値があると感じています。

開発の速さを、継続的な価値につなげる

AI活用には、少なくとも2つの側面があります。1つは、開発者自身がAIを使い、調査、設計、実装、レビューを速くすること。もう1つは、AIを組み込んだプロダクトや仕組みを開発し、現場の課題を解くことです。

私自身も、ChatGPT、Codex、Claude Codeなどを調査、設計案の比較、実装、レビューに使い、作業の性質や開発フェーズに応じて使い分けています。

これにより、選択肢の比較、仕様のたたき台づくり、実装、検証観点の洗い出しは速くなりました。しかし、その速度がそのまま現場の価値になるわけではありません。AIが生成した設計やコードの前提、制約、失敗時の挙動を確かめ、業務理解、設計、評価、運用までつなげる。最終的な判断を引き受けるのは開発者です。

一方、現場で継続的に使うには、精度に加え、速度、コスト、安定性、セキュリティ、ログ、評価、更新、切り戻し、運用負荷なども考える必要があります。

RAGやFAQ連携も、検索して回答できれば終わりではありません。どの情報を参照してよいのか、更新された情報をどう反映するのか、回答根拠をどう確認できるようにするのか、誤った回答をどう抑制するのか、変更後の品質をどう評価し、問題があればどう戻すのか。ナレッジ、回答制御、評価を1つの仕組みとして扱う必要があります。

こうした評価や運用はMLOpsやLLMOpsとも呼ばれますが、要点は、現場やビジネス、技術の変化に合わせてプロダクトを育て、使い続けられるかです。

課題から逆算すると、選ぶ技術も変わる

この考え方は、音声AIに限りません。

別の業務支援の取り組みでは、当初は大規模なRAG基盤や複雑なAIエージェントのワークフローも選択肢にありました。しかし、実際の業務を見ていくと、入力の解釈や整理にLLM（大規模言語モデル）を使いながら、固定的な業務ルールとナレッジに沿って結果を返すシンプルなワークフローの方が、要件に合うと考えました。

複数の情報や根拠を確認しながら慎重に判断する業務では、AIに最終判断を任せるのではなく、人が判断するための情報を整理し、確認すべき根拠を示す役割として位置づけます。利用者に提示する情報と、内部の判断材料として扱う情報を分ける。安全性や責任が重い業務ほど、AIが担う範囲、説明可能性、監査可能性、運用上のガードレールが重要になります。

一方で、目的から逆算した結果、必要な場面では複数の技術を深く組み合わせます。外部への接続が制限される環境では、情報検索から文章生成までを環境内で完結させるため、ローカルLLM、埋め込みモデル、検索インデックスを組み合わせたRAGアプリを構築し、配布や更新まで含めて設計してきました。また、複数のAIエージェントが役割を分担しながら1つの業務を進める場面では、LangGraphを使って処理全体を制御し、実行結果の評価、監査、可観測性まで含むAIエージェント基盤を検証してきました。

大切なのは、複雑な技術を使うか、シンプルな仕組みにするかを先に決めないことです。まず、本当にAIが必要なのか。AIを使う場合でも、RAGや複雑なAIエージェントまで必要なのか。業務と制約から段階的に見極める。必要であれば技術を深く組み合わせ、必要がなければ構成を引き算する。どちらも、現場の価値から逆算したエンジニアリングです。

必要な構成を選び、評価と改善を重ねる中で生まれた工夫は、個別のプロダクト改善にとどまりません。評価、監査、更新、運用の知見をナレッジや標準、知財として組織に残し、再利用できる形にすることも、価値を継続させるための設計だと考えています。

現場と技術を往復する

PayPayで私が関わる取り組みでは、現場の知見を持つメンバーと業務上の判断を整理し、それを要件に落とし、実装し、実際の利用環境に近い形で確かめ、ログと評価結果から次の改善へ戻していきます。業務、プロダクト、開発、インフラ、セキュリティなど、それぞれの専門性を持つメンバーとの協働が欠かせません。

大規模なサービスには、多様なユーザー接点と業務があります。その分、AIを活用できる機会は多くありますが、便利さだけでなく、信頼性、安全性、継続運用まで含めて考える必要があります。課題整理から設計、実装、評価、運用改善まで関わり、AIを実際に使われる形へ育てていけることに、PayPayでAI活用に取り組む面白さがあります。

私はForward Deployed Engineer（FDE）として、現場と技術の間を行き来しながら、この一連の流れをつなぐことを大切にしています。現場の言葉をそのまま技術要件に置き換えるのではなく、業務上の目的や判断を理解する。技術的に可能なことを示すだけでなく、運用できる形まで一緒に考える。その往復によって、AIを検証から価値へ近づけていく役割です。

広く見渡し、深く考え、速く価値にする

広く見渡す。技術だけでなく、業務、プロダクト、データ、運用、ビジネスまで見る。

深く考える。選択肢、前提、リスク、品質、評価、責任範囲を考える。

速く価値にする。調査、試作、実装、フィードバック、改善のサイクルを回し、現場で使える形へ近づける。

AIによって、この一連のサイクルは確実に速くなっています。ただし、速く作ることだけがゴールではありません。速く考え、速く試し、速く学び、その結果を変化に合わせて育て続けられるプロダクトへつなげることが大切です。

AIを使いこなすだけでなく、AIをどこに置くか、どこでは使わないか、どのように現場へ届けるかを考える。PayPayでの実践を通じて、私自身もその力を磨きながら、AIを単なる技術検証ではなく、現場に届く価値へ変えていきたいです。