技術的成功の先に見えた、本質的な課題
AIとの対話が成立し、プロジェクトは順風満帆に見えました。しかし、このAIを「全社で使える本当に賢いアシスタント」にしようと考えたとき、私たちは本質的で大きな2つの壁に突き当たりました。
壁①:言葉の「揺れ」の壁
AIエージェントは、ユーザーの無限にある言い回しに完璧に対応しようとすると、プロンプトを延々と調整し続ける、終わりなきチューニング作業が必要になること。VertexAIの”ゆらぎ検索”が効きすぎで賢明すぎるのです。
ユーザーの曖昧な話し言葉を、プログラムが理解できる正確な命令に「翻訳」できるかにかかっています。この「言葉の揺れ」に対応することが奥深い課題でした。
例えば、AIに「品番1581の在庫数を調べてほしい」という一つの意図を伝えるだけでも、人間は無数の表現を使います。
揺れの種類 | ユーザーの入力例 | AIが解釈すべき本当の意図 |
同義語・言い換え | 「1581のストック、ある?」<br>「1581、今いくつ?」 | get_inventory(hinban=’1581′) |
省略・文脈依存 | 「じゃあ1580は?」<br>「在庫、1581」 | (会話の流れから)<br>get_inventory(hinban=’1580′) |
多義性・曖昧さ | 「1580の在庫は?」 | 1580には複数サイズがあるため、ユーザーに追加情報を求める必要がある |
誤字・音声認識エラー | 「ひんばん15通知の在庫は?」 | get_inventory(hinban=’1581′) |
丁寧さ・間接表現 | 「お忙しいところ恐縮ですが、1581の在庫状況など分かりますでしょうか?」 | get_inventory(hinban=’1581′) |
これらの無数のバリエーションに、従来のプログラムのように一つ一つルールを設定して対応するのは不可能です。この課題を乗り越えるには、プロンプトを延々と調整し続けるか、以下で触れるような、より高度な「社内LLM」の構築が必要になります。
「言葉の揺れ」を社内LLMで解決するという選択肢
一般的なクラウドLLMでも、プロンプトの工夫である程度は対応できます。しかし、社内特有の専門用語や非公開情報が絡むと、その精度には限界があります。そこで最もパワフルな選択肢となるのが、自社のデータを使ってAIをカスタマイズする「社内LLM」環境の構築です。
これは、AIを単に「使う」のではなく、自社の「専属アシスタント」として育て上げるアプローチです。
- 高度なRAG — AIに社内専用の図書館を与える
RAG(Retrieval Augmented Generation)とは、「検索」と「生成」を組み合わせる技術です。「AIの賢い頭脳はそのままに、参照する教科書を社内専用のものに限定する」というイメージで、社内に散在するあらゆる情報(製品仕様書、議事録、過去のメールなど)をベクトルデータベースという特殊なデータベースに格納します。 ユーザーからの曖昧な質問に対し、LLMはまずこのデータベースから意味が近い情報を検索し、その正確な内容を根拠として回答を生成します。これにより、情報の鮮度と正確性が劇的に向上します。
- ドメイン特化ファインチューニング — AIに社内業務を「経験」させる
ファインチューニングは、LLMそのものに自社の「言語」と「業務」を追加学習させる、より根本的なアプローチです。「汎用的な頭脳を持つAIに、自社業務のOJTを受けさせて専門家にする」イメージです。 社内で実際に交わされた「多様な質問」と「それが意図する正しい行動」のペアを大量に学習させることで、モデルの思考回路自体が、貴社特有の言葉のニュアンスを理解するように変化します。これにより、究極の意図理解と、業務フローに沿った独自の振る舞いをAIに獲得させることができます。
このように、自社でAIを育て上げる道は非常にパワフルですが、相応の技術力とリソースを要します。私たちはこの点を踏まえ、自社の現状と照らし合わせ、もう一つの壁にも目を向けました。
壁②:情報の「サイロ化」と「一元管理」の壁
AIは、私たちが与えたデータベースの情報しか知りません。本当に賢くするには、社内に散在するあらゆる情報(製品マニュアル、仕様書、議事録など)を一元管理する必要があり、これは壮大なデータ基盤整備のプロジェクトでした。
光明:Google サービスとの出会い
そんな悩みを抱えていた時期に、Googleのあるサービスが登場しました。これは、私たちが直面していた壁、特に社内情報の検索に関する課題を、いとも簡単に解決してくれたのです。
- 言葉の揺れに強い: 「意味」で検索するため、多少言い回しが違っても的確な答えを資料から探し出してくれます。
- 情報管理が圧倒的に楽: ただPDFやテキストファイルをアップロードするだけで、AIの知識ベースが完成します。メンテナンスの手間が比較になりません。
コスト面から見た、今回の実験の「価値」
今回のAIエージェント開発は、コスト面でも非常に価値のある示唆を与えてくれました。
今回のプロトタイプは「驚くほど低コスト」
私たちが構築した音声AIエージェントは、各種GoogleのAPIを利用しましたが、当社の利用頻度では月額費用は合計しても数百円〜多くても数千円程度の見込みです。 つまり、初期の開発工数(人件費)を除けば、驚くほど低いランニングコストで、高機能な社内アシスタントが動き続けるのです。
一方、「本格的な社内LLM」への道は大きな投資
先程触れたような、より高度な「社内LLM」の構築(RAGやファインチューニング)は、インフラコストや専門人材コストで月額数十万〜数百万円、あるいはそれ以上の投資が必要になる全く異なる規模の話です。
【最終結論】自作したからこそ見えた、最適なツールの役割分担
この一連の経験とコスト分析を通じて、私たちはAI活用の重要な結論にたどり着きました。それは「AIにも得意・不得意があり、費用対効果を見極めて適材適所で使い分けるべきだ」ということです。
- 情報検索・参照(Knowledge)は「任せるべきAI」
- 社内の資料やドキュメントに基づいて答えを探す、いわば「博識な社内司書」。
- → これは専用ツールに任せるのが合理的。 メンテナンス性と検索精度、そしてコスト面で圧倒的に優位。
- タスク実行(Action)は「作るべきAI」
- 外部のAPIと連携してリアルタイムな在庫を取得・操作する、いわば「実務をこなすアシスタント」。
- → これは、私たちの作ったAIエージェントのように、自社で開発する価値がある。 ランニングコストを低く抑えつつ、外部サービスでは代替できない能動的なタスクを実行できる。
今回のAIエージェント開発実験プロジェクトは、「自社の課題に対して、どのAI技術を、どの程度のコストをかけて、どのように使うのが最も賢明か」という、AI導入の核心となる戦略的知見を私たちにもたらしてくれました。
今回は基本的な技術の組み合わせの実験でしたが、日々技術が進化しているので
将来的にはより高度な仕組みにも挑戦予定です。
この記事が、皆さんの会社の業務改善、そしてAI活用のヒントになれば幸いです。