Everforthと株式会社A（エース）様 (以下A社) で「AIサーチ・エージェント」というAIエージェントを開発しました。
A社がこれまで提供していたインフルエンサーマーケティングツール Astream（エーストリーム）のデータや機能を活用し、これまでにない新たなインフルエンサーマーケティングの体験を実現・提供をしています。
Everforthは約6ヶ月 (実稼働期間は2〜3ヶ月) という短い期間で実証実験を繰り返し、実際にA社のスタッフがプロダクトを使ってお客さまと会話・提案ができるクオリティにまでAIエージェントの精度を高めていきました。
A社とのプロジェクトは、「AIを自社の事業に組み込んだ時に実際に何ができるのかが分からないので、相談させて欲しい」というお話をA社からEverforthのCOO生谷宛にいただいたことから始まりました。
生谷がA社の事業状況を確認していくと「AIで顧客の期待をこれまで以上に満たすことができそうなことは分かるのだけど、本当に自分たちにできるのかがわかっていない」ということを思っているようでした。
実際、A社内にはエンジニアがいましたが、既存の事業で手一杯でうまくAI文脈の検証を進められていない状況がありました。
そこでA社の今の事業文脈を確認するために、営業資料やAstreamという現状のプロダクトのアクセス権限をもらって一通り触っていきました。ここでは「このような体験ができるようになれば、Aとして事業やビジネスが一歩先に進むのではないか」という視点で事業を見ていきます。
Astreamであれば以下のような部分にプロダクトの課題があると感じました。
もっとプラットフォームとしての価値を広げたいが、現状はインフルエンサーを検索する価値にとどまっている
検索体験だけ見ても本当は使えるのに今は使えていないデータがたくさんある
これを既存のシステムからAIを使った検索体験へとアップデートすれば、A社として「インフルエンサー活用戦略の提案」などこれまで以上の体験に注力していくことができるはずです。
この課題感や戦略の方向性をA社のCEO / COOとアラインする過程で「Everforthと一緒に今スタートすべきだと思ったので始めましょう」と伝えられました。
Everforthではこのタイミングで「相手のコードやデータ状況的に、できると確信しているもの以外は提案しない」ことを心がけます。
例えば、世の中的には技術的に可能なものであったとしてもA社においてできるかどうかは別です。GitHubのアクセス権限をもらい一通りコードを確認、データモデル・外部利用API・データの内容や綺麗さも確認しながら本当に実現できそうかどうかを確かめていきました。
このような流れで、AIサーチ・エージェントが事業的にも必要で技術的にも実現可能だと捉えたので開発をスタートさせています。
このプロジェクト全体で最も重視していたのは「検証のために大きく壊すことも厭わない」ことでした。
AIサーチ・エージェントが事業的に意義があり技術的な実現可能性もあることは分かっていたので、プロジェクトの中でやるべきことは「より良い体験に向けて磨き込む」ということのみでした。
ここで通常のプロダクト開発であれば、まずは丁寧にユーザーの行動や課題をヒアリングしながら仕様を固め...と進めるかもしれません。一方で私たちは1週間でv1を提供開始し、約2〜3ヶ月の間にAIエージェントのアーキテクチャも大きく更新しながらv3までAIエージェントを開発していきました。
私たちはAIエージェント開発においては、結局実際のプロダクトをユーザーに触ってもらいながら行動を観察することでしか課題の理解もソリューションの検証もできないだろうと考えています。
そのためv1を即開発して触り始めてもらい、そのログを見ながらプロンプトの調整だけではなく必要ならばアーキテクチャごと大きく壊して、より良い体験に向けて検証と開発を何周も回していきました。
プロジェクトが始まると同時に「まずは実データを使って、聞いたら返ってくる体験のみ実装したv1をすぐにつくる」というゴールが設定されました。
ゴールが決まった後はプリンシパルエンジニアの岩越が1~2週間でv1を実装し、すぐにA社のスタッフに触ってもらえる状態をつくりました。
ここでポイントになるのは「実データで触れるものを実装すること」「とにかく早く現場に投入して実感を得ること」です。
一般的にはよく分かっていない業務に対してプロダクトをつくっていく場合、ヒアリングや調査からスタートすることも多いかもしれません。ただそのように時間をかけても、やはり普段からインフルエンサーを探す業務をしていない僕たちが肌感を得るのはどうしても時間がかかります。
それよりも業務に取り組むA社のスタッフに触ってもらい「業務で実際に使えるものか」を確かめてもらうことが一番学習が得られることだと考えています。となると汎用的なLLMのプロダクトでは検証にならないので、最初から実データを読み込ませたプロダクトを用意するようにしました。
業務で使われるAIエージェントをつくるには、体験を確認しながらアーキテクチャ自体をチューニングしていく必要があります。なので、後で壊す前提でv1の構造は簡易に設計していました。
v1の目的は最もシンプルな形で実データを読み込ませたAIエージェントを提供した時に「これだけでも良いことと、改善が必要なこと」を見極めることです。
v1の簡素な設計でも適切に会話が出力されている部分はそのまま残します。逆にうまく出力されてない部分は、重要度や代替案を確認した上でアクションを分解してアップデートをかけます。今回でいうと以下のような検証結果が得られました。
・最初のコミュニケーションや要件を整理する会話はシンプルな設計で十分そう
⚙️v1の改善ポイント
・インフルエンサー検索は素のままでは苦手、明らかに条件にヒットしないフィルターをつくってしまう
・文章が多すぎて、インフルエンサーの検索結果がわかりづらい
v1をすぐに提供開始したもう1つの目的はログを回収することです。v1開発の時点でA社のスタッフのお試し環境を提供して自由に触り倒してもらいつつ、その裏側ではすべての発言や行動がログとして蓄積されるようにしています。
前述の通り、自分たちがヒアリングをするよりも実際に業務に取り組む方による行動を観察することが一番顧客理解につながります。なのでv1を早く出し、ログをもとにv2, v3とアップデートをしていける環境をいかに早くつくるかが大事だと思っています。
v1での学習結果をもとにv2をすぐに作成します。インターフェースの調整はここでは最小限にとどめています。
どちらかというとv2で一番力を入れたのは、AIエージェントを分離させることでの出力精度を高めるためのフロー改善です。以下のように、複数のAIエージェントとプログラムを組み合わせたアーキテクチャとしています。
非常にシンプルな構造でまとめていたv1と比べると、v2では出力精度を高めるための工夫をかなり増やしています。
例えば、LLMを使うところとプログラムで処理するところを適切に見極めるようにしています。
ユーザーのメッセージ内容を解釈して検索条件に落とし込んだり、インフルエンサーを分析するようなアクションはAIが処理する方が得意なので、そこはLLMで担うようにします。逆に、条件に沿って検索をかけるのはプログラムで行う方が早く、このような部分は従来通りソフトウェアで担います。
またLLMも「ユーザーコミュニケーション用AIエージェント」「分析用AIエージェント」「文章のフォーマット用AIエージェント」などといくつか用途を分けたものを組み合わせてフローを設計しました。
一つのLLMに複数の情報を読み込ませると出力される情報にブレが出てくるため、各役割に必要な情報のみ最小限に渡すようにしています。
v2では業務を分割することで一つひとつのAIエージェントに渡す情報を絞り込み、それによって出力精度を高めることを検証しました。
AIエージェントを分離したことで格段に検索条件に合うインフルエンサーが見つかる精度が向上し、A社内ではこの時点で「これは業務で使えそう」「早くプレスリリースを打ちたい」と温度感が高まりました。
お試し環境を触る社員数や利用回数も増え、このままでもリリースできそうとA社内で期待が高まっていきます。
Everforthとしてはこのようにお客さまが良いと思ってきたタイミングだからこそ徹底的にクオリティを高めることにこだわります。
先方としても「業務に使えそう」と思ってきた以降は、こちらから何を出しても「良いね」という反応が返ってくるようになっていきます。
納品をゴールとしているならここで止めることもあるかもしれませんが、Everforthが追いかけているのはあくまで「相手の事業が変わること」なので自律的に課題を見つけて品質を磨き続けます。
v2の利用ログを確認する中で、以下のような部分に改善点があることは分かっていました。
⚙️v2の改善ポイント例
LLMを複数組み合わせたことで処理が重くなった
すべての検索・分析が終わってからメッセージが出るまでに長い時は5分以上かかってしまう
プロンプトを調整しても検索部分のLLMの出力精度が高まりきらない
なぜこのようなインフルエンサーが表示されたのか？他にはどんな選択肢があったのか？については触れられておらず分かりづらい
これらはプロンプト改善だけではまだ精度が高まりきらないだろうと判断し、ここでもう一度アーキテクチャをつくり直すことを意思決定しました。
以下がv3のアーキテクチャです。v2と大きな流れは変えず、さらに検索業務を分解してそれぞれの役割に絞ったLLMを用意しました。(インフルエンサー情報検索用、検索実行用、分析用...)
Everforth内で行う週2回のシンクmtgでも毎回ログを確認しながら継続して課題を抽出します。さらにプロジェクトメンバーだけでなく社内で幅広く参加を募った感想会も数回開催して、ゼロベースで大きな問題を発見できるようにしています。
結果としてアーキテクチャのつくり変えだけでなく、プロンプト調整やプログラム改善などあらゆる範囲で改善を続けました。v2くらいまでAIエージェントをつくり込んでいると、以降はプロンプトの改善だけで何とかしてしまおうと思いがちですが
プロンプトエンジニアリング
アーキテクチャ改善
ソフトウェア実装
インターフェース改善
などどこで問題を解決すべきかを見極めて、必要ならばアーキテクチャを大きく壊したりソフトウェアを書き換えるなど柔軟な対応をすることが沼に入らないためにとても大切だと思います。
v3では、世の中に公開できるくらいにインターフェースを磨き込んでいます。
基本的にAIエージェントの価値は「正しい出力がされる」という部分から生まれます。なのでv1, v2の段階ではUIにはほとんど触れていません。
ただv2の時点でA社のスタッフからの前のめりな声が生まれてきたため、v3では外部提供をしても違和感がないくらいにインターフェースも磨き込みました。
ちなみにデザインはプリンシパルエンジニアの岩越がv3を開発するのと平行して、生谷が一晩で用意しました。得意不得意に沿ってチームで役割分担し、高速で各パートの業務を進められるからこそこのようなフローが実現できます。
このような流れで無事にプロジェクトが進み、2025年秋にベータ版をプレスリリースとして公開しました。ここまでの実期間は3ヶ月くらいかと思います。
このプレスリリースをきっかけにA社に対する多くのお問い合わせが来ています。大手クライアントとのPoCが開始していたり、東南アジアへの展開も始まっていたりと、このプロダクトを起点にA社の事業展開に広がりが見られています。
A社のCEOとCOOからも「今回のプロジェクトを通したディスカッションによって、Astreamの目指す世界を新たに言語化することができた」という声をもらっています。
さらに、Everforthの開発スタイルへの期待が高まりAstream本体のシステム改善プロジェクトも一緒に動き出すこととなりました。
単にプロダクトを納品するということではなく、同じ会社の一員として事業が前進するための次の一手をつくることにコミットするのがEverforthのスタイルです。
私たちは単なる開発会社でもAIプロダクト開発屋でもなく、パートナーの事業に経営責任を持つ存在であることを意識しています。
今回のように「AIについて知りたい」という相談をもらったとしても、現在のプロダクト・営業資料・お客さまの声・システムのデータ構造などを全て確認し「現在の事業から考えて、最適な次の一手は何か？」ということを確信を持って提案します。
ここまで必要性/実現可能性が確認できた状態でプロジェクトを始められるので、あとはとにかくプロダクトを磨き込むことに集中できます。
プロジェクト期間中も必要以上に議論や進捗確認などを行わず自律駆動で進めます。毎週チームでログを確認して「次はこの課題を改善しよう」と話し、そこからはプリンシパルエンジニア岩越がメインでAIエージェントのアップデートをゴリゴリ推進していきました。
責任も大きいからこそ実験できることも多く「より良い体験をつくるためにできることは全てやる」という姿勢を維持できています。
「もしも相手の会社の中に “Everforth” というタスクフォースがあるなら何をするべきか？」という目線を常に意識し、御用聞きになるのではなく同じ会社の一員として経営目線でベストな打ち手を技術・ものづくりの観点から提案する。これがEverforthが徹底していることです。
今後もさまざまなクライアントと一緒に、新しい体験からビジネスの価値を広げることにチャレンジしていきます。
