不確実なAIエージェント開発を前に進める「2つの勘所」
──AIエージェントは進化の最前線にあると思いますが、そういった技術の不確実性に対してどのような観点で選定して検証していけばよいのでしょうか。
宮脇：初期段階で不確実性を解消するポイントは2つ。1つは完成形にこだわりすぎないこと。2つ目は小さく素早くとにかく改善サイクルを回していくことです。
完成形にこだわりすぎないために、弊社では「UIを後回しにする」ことを提唱しています。まずは技術的に実現可能かを試し、最小限の検証を行うことです。また初期段階においては、ドリフトが発生しやすい定量評価ではなく、チーム間で共通認識を素早くとれる定性評価を行うことが重要です。AIで5段階評価をとにかくやってみて、その入力データやAIの回答をエキスパートに確認してもらい、メンバー間でその精度感を共有する。そうすると精度の改善方針やリスク管理が早期から行えるようになります。
小さく素早く改善を回していくために私が行っているのは、ペアプログラミングのようにドメインエキスパートとペアを組みながら改善を回すことです。しかし、クライアントワークだとアジャイルに回すのが難しいというイメージがあると思います。お客さまとスケジュールの合意形成について、阿田木さんからアドバイスありますか？
阿田木：そうですね……。小さく速く回すために、まずはタスクを一つずつ分解し、カテゴライズします。そして、代表的なものを検証しています。それを第1ステップとして、全てのタスクを検証するにはどのくらいかかるかを予測し、スケジュールを提案しています。
宮脇：タスクはどのように分解していますか。
阿田木：例えばお客さまの要望が「AIエージェント」ではなく「属人化している業務をAIで代替したい」ということであれば、「属人化している業務がどういう入力でどんな作業をやっており、どういう出力をしているか」をヒアリングして整理することから始めます。ヒアリングして標準化を図ることにはかなり力を入れています。これがうまくできないと、期待通りにAIエージェントは動いてくれませんからね。
宮脇：AIエージェントの開発は「属人化している部分の言語化」が肝みたいなところがありますからね。
西見：それに付け加えて大事にしたいのがAIエージェントに代替したことでインパクトが得られるかどうかという点。AIエージェントの開発って、結構大変なんです。というのも人間が暗黙的にやっていることも、AIエージェントのワークフローに組み込んでいく必要があるからです。だから開発には泥臭さが伴う。
よくあるのが、簡単そうだと思って取り組んだところ、意外に開発に手こずり、できたとしても性能があまり上がらないというケース。代替業務の選定は、簡単そうかどうかではなく、インパクトが出るのか、継続して改善していけば性能が上がるのかという観点も重要だと思います。
AIエージェントを組み込んだプロダクトを開発する前にやるべきこと
「なんか惜しい」から進まない！開発を停滞させる罠
──AIエージェントは、開発を行っていく上で品質保障を担保しなければならないと思いますが、評価はどのように行っていけばよいのでしょうか。
太田：アウトプットされたものが業務として使えるかどうかで評価します。最近、増えているドキュメントワークを対象としたAIエージェントであれば、生成された内容に間違いがないかについて確認することが大切です。
具体的な方法としては、人間がつくった成果物と比較してみること。AIエージェントが作成したものと見比べて、どちらが優れているかを評価する方法があります。
難しいのは、AIエージェントが作成した内容の事実性について、業務エキスパートなど業務の専門家にしか判断できない部分があることです。例えば、Wordで10ページ分の資料をAIが生成して、その中身に専門的な知見が必要な箇所、グラフや表など数値に関する箇所、別の資料からの引用箇所などが含まれたとき、全て確認をするのは、非常に時間がかかります。しかし、判断を常に専門家に頼んでいては、時間と工数がかかってしまいます。とはいえ、アウトプットのパターンはいろいろなので、自己完結できるような仕組みを作るのも難しいです。
従って品質保証を行うためには、プロジェクトが始まった段階で評価するデータと評価の仕組みを整備することだと思います。なるべく「AIが評価できる箇所」と「業務の専門家しか評価できない箇所」を見極めて、検証していくことが失敗しないコツだと思います。
──AIエージェントの開発がうまくいかない場合、どんな問題があると思いますか。
西見：うまくいかない理由によって変わるとは思いますが、一番多いのがAIエージェントでできないものをやろうとしているなど、問題設定が間違っていることだと思います。また、AIエージェント化するためには欠かせないドメインエキスパートが近くにいない場合も、うまくいかないことが多いと思います。
やっかいなのが、最近のLLMの性能がすごく良いので、かなりいいところまでできているように感じることです。そのままずるずると改修を続けても、一向に精度は上がらないパターンは、AIエージェント開発あるあるです。LLMの性能が高いからこそ、小さな実験を繰り返しながら、検証していくことが重要になります。
阿田木：開発者の観点では、まずは要件を整理することが大事だと思います。入力情報は十分あるか、人間がやっている作業が整理出来ているか、出力の評価観点が正しく設定できているかをドメインエキスパートや業務担当者に入念にヒアリングすること。というのもヒアリングすると暗黙知がぽろぽろと出てくるからです。業務知識や暗黙知の保管や改善する仕組みがないと使ってもらえるAIエージェントはできないと思います。
次に新人を教育するかのような長期的な視点を持つことも大事です。段階的に評価し、修正していくことが重要です。なぜなら、AIエージェントは多段階で処理を行い、段階が進むにつれ不確実性が高くなっていくからです。
太田：機械学習の考え方を持つことも大事ですね。AIエージェントをシステム開発と捉える以前に、機械学習モデルを作っているという自覚が大事です。AIエージェントはタスクを実行するのに時間がかかるので、サンプル数を多めに検証することは少ないです。ですが、手元のデータではうまくいっても、他のケースでは精度が全く出ないことがよくあります。データを多めにしていろいろ評価するのも大事だと思います。
宮脇：また、開発の段階でAIエージェントと人の接点を設定することも重要です。AIアプリケーションとして業務代行型を目指すべきなのか、チャットボットのような支援型サービスを目指すべきなのか、ユーザーの技量に合わせて設定することも大切です。例えば、データ分析に従事している方には、チャットボットのような支援型サービスがマッチすると思います。一方、データ分析に従事していない方は、分析の内容を考えることが難しかったりするので業務代行型のサービスの方がマッチすると思います。
AIプロダクトを開発する際のポイント
最終的にフルオートを目指すものの、最終判断はまだ人に任せている場面は多々あると思います。そういう場面では、顧客による判断やAIの精度に応じてレベル間を切り替え可能な２つのタイプ（高度自動化と部分自動化など）を用意し、まずは部分自動化によってある程度業務を回し、人に決定権を持たせなくてもAIが業務を回すことができると判断可能になった段階で高度自動化に切り替えるようにします。
太田：業務代行型か支援型かによって、裏側のエージェントの仕組みは大きく変わります。最初に適切でない方を選んでしまうと、後の開発はかなり苦労すると思います。ですが、始めは「チャットボットのような支援型サービスがほしい」と言われる方が大多数です。自由なフォーマットで好きに質問すれば、それなりの回答を返してくれるという汎用性の高いエージェントは、自由度が高い分、パフォーマンスが落ちる可能性が高いですからね。
なので、パフォーマンスが不安定な支援型サービスの場合は、成果物をWordやPowerPointなど、編集可能な形式でダウンロードできるようにして、人が直接修正できる余地を与えるのがよいと考えています。
