🤖
LLMアプリケーション開発の極意〜ドメイン知識を活かした設計と評価〜 レポート
はじめに
2025年4月22日に開催された「LLMアプリケーション開発の極意〜ドメイン知識を活かした設計と評価〜」は、実際にLLM（大規模言語モデル）を活用したプロダクトを開発・導入しているエンジニアが集まり、LLMアプリ開発の舞台裏を詳細に共有する濃密なイベントとなりました。セッションでは、開発の実務フローからドメイン知識の取り込み方、さらに運用フェーズでの評価やチューニングまで、多彩なノウハウが語られました。
登壇者は、営業AIエージェント「アポドリ」を開発している株式会社Algomaticの池谷さんと、エンタープライズ向けAIワークフロー「AIワークホース」を手がける株式会社LayerXの恩田さん。いずれも 「ただLLMを導入するだけではない」 、実際に動くプロダクトとしてサービス化し、より大きな組織に届ける際の苦労や工夫がリアルに語られました。
質疑応答でも、「プロンプトのチューニングはどう進めるのか」「ドメインエキスパートの知見をいかに活かすか」「大規模データを扱う際のアーキテクチャや評価方法」など、開発者同士のやりとりが盛り上がりました。本レポートでは、池谷さん・恩田さんそれぞれの発表のポイントと、Q&Aの議論をまとめてお届けします。
池谷さんご講演：「営業AIエージェント『アポドリ』のつくり方」
1. プロダクト概要と背景
池谷さんは、リクルートで長年PMとしてサービス立ち上げを担当した経験を生かし、現在はAlgomaticで営業AIエージェント「アポドリ」の開発を推進しています。アポドリは「人の代わりに営業活動を行うAIエージェント」であり、電話やメールでの新規アプローチにかかる負担を大幅に軽減することを目指しています。営業担当者が1日に20件ほどしか連絡できないところを、AIならばスケールを狙えるという発想です。
しかしながら、「営業活動は単純なタスクの集合ではない」ことが大きなチャレンジ。企業情報の収集、メッセージの個別調整、成果の検証など、多数のタスクを並行してこなす必要があります。池谷さんいわく、アポドリはあえて人間による営業代行からスタートし、プロセスを細分化して徐々にAI化する「段階的アプローチ」で構築してきたとのことでした。
2. 開発のフェーズとポイント
初期フェーズ：営業課題の探索 エンジニア含むメンバーが実際に営業代行を行い、そこで発生するタスクを一つずつ洗い出しながらAI導入の可能性を探ったそうです。初期段階はすべて人力で回すことで、どのタスクがAI化しやすいかを正確につかむ狙いがあったといいます。
複数顧客への拡大 ある程度実績が出ると、同じ手法を複数顧客に展開。しかし、営業メッセージの個別チューニングや企業情報の解析などが一気に増加し、開発よりも運用負荷が高くなる課題が浮上。そこで外部化・自動化の仕組みを導入し、エンジニアでなくてもプロンプトを調整できる環境を整備しました。
フルオート化に向けた実装 大量の営業活動を安定してこなすため、細かなタスクをワークフロー的に自動化。さらに、AIが生成したメッセージをAIが評価する仕組みを作り、人的チェックを最小化していったそうです。ただし、最終的にも人間のレビューやドメイン知識の注入は不可欠で、そこは「最小限に効果的に挟む」デザインが必要と強調されました。
3. 成功の鍵と学び
まず人間がやってみる AIエージェントとはいえ、「ドメイン知識の深い人間が実際に作業することで初めてワークフローが明確化され、チューニングの方針が見えてくる」と強調されました。
プロンプト管理を外部化 「プロンプトを書き換えるたびにエンジニアが対応していては、拡大時に破綻する。ビジネスメンバーがプロンプト編集に参加できる仕組みが重要」とのことです。
評価の仕組み作り AIが大量のメッセージを生成するようになると、人間の目視チェックは現実的でなくなる。そこをAIに再チェックさせる仕組みを整備し、最終的に必要な部分のみ人間が確認するフローを構築したそうです。
恩田さんご講演：「現場で動くAIワークフロー〜チューニングを効率化する工夫〜」
1. AIワークホースのコンセプト
続いて登壇した恩田さんは、LayerXでエンタープライズ向けのAIワークフロー「AIワークホース」を開発中。契約書や長大なレポートなど、「知的だが単純作業が多い」文書処理をLLMが手伝い、人間との適切な分業を図る仕組みを提供しています。
企業ごとに異なるチェックリストやデータフォーマットを反映するため、ワークフローをノーコードで作れるように設計。LLM単体に過度な期待をするのではなく、ルールベースとAIを組み合わせたモジュール化を進めることで、より再現性の高い処理を目指しています。
2. 評価とチューニングの難しさ
正解データの作成コスト ドキュメント解析のタスクには数多くの項目があるため、最初から完璧な正解データを用意するのが困難。そこで、まずはLLMに処理させ、その出力をコピーして差分だけ手動修正し、それを正解データとする方式を採用しているそうです。
プロンプト変更の影響範囲 プロンプトを少し変えただけで、関係のない別の項目の精度が落ちたりする現象が多発。まるで“風が吹けば桶屋が儲かる”ように、影響範囲が予測しにくい点が苦労の種と語られました。
関節的評価指標 要約や比較など、定量化が難しいタスクの場合、出力に含まれるべきキーワード数などの「関節的指標」を導入して効率的に評価する手法が紹介されました。上達度合いを部分的に把握しながら、改善を継続しているそうです。
3. 今後の展望
AIワークフローを高度化するにあたり、まずは「人間が教え、AIが学ぶ」モデルからスタートし、将来的にはAIが自ら学習・改善するシステムを目指すとのこと。過去の実行事例を蓄積・分析し、次回のワークフローに活かす仕組みを構築しているそうです。最終的には、AIが自己対戦的に最適化していく“自己学習サイクル”の可能性を感じているとのことでした。
Q&A抜粋
プロンプトチューニングとモデルの進化
Q: モデルがアップデートされるとプロンプトを大幅に変える必要がありますか？ A: 池谷さん、恩田さんともに「完全に無駄になることは少ない」と回答。ドメイン知識や前提条件が含まれる部分は長く使える。ただし、モデルの特性が変わると推奨手法（例：チェイン・オブ・ソートの要否など）に微修正が必要になる場合はある。
技術選定の方針
Q: ライブラリやフレームワークをどう選んでいますか？ A: 池谷さんは「スピード重視。小さく作り、早くアウトプットすることをCTOがとても重視している」。恩田さんは「ADRを作成し、社内レビューで歴史的経緯や既存実装を考慮しながら最適なものを選んでいる」とのことでした。
ドメインエキスパートの負荷を減らすには
Q: AIで評価するにもドメインエキスパートの確認が不可欠では？ どう負担を軽減していますか？ A: 池谷さんは「LLMに評価の手助けをさせる。出力の中でも怪しい箇所だけ人間がレビューする設計にする」と回答。例えば、AIがどの文書を参照して回答を生成したかを可視化し、専門家が最小限の確認で済むように工夫する、といった取り組みを進めているそうです。
全体を踏まえた感想 —— 地道な積み重ねこそLLMアプリ開発の鍵
今回のイベントを通じて共通していたのは、 「LLMが全自動で完璧にやってくれるわけではない」 という現実です。もちろん、強力な生成能力を備えたLLMは劇的な効率化をもたらす可能性を秘めています。一方で、それを実際のビジネスに組み込むには、ドメイン固有の知識を正しく構造化し、日々の運用改善に反映させる地道な努力が欠かせません。
池谷さんの「アポドリ」は営業現場の細かなプロセスを分解し、一歩ずつAI化を進める手法で成功を収めています。恩田さんの「AIワークホース」ではルールベースとLLMを組み合わせ、エンタープライズの複雑な要望に応えるワークフローを構築しています。いずれの事例も、「開発者とドメインの専門家がタッグを組み、評価プロセスを最適化しながら改良していく」姿勢が印象的でした。
これからLLMを活用したアプリ開発を始める方は、まずは小規模な領域から着手し、人間とのハイブリッド運用を通じてドメイン知識を吸収しつつ、段階的に自動化を進めるのがおすすめです。地道な積み重ねが「LLMアプリにしかできない独自の価値」を開花させる鍵になるでしょう。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...