LLM活用事例 16件
自社で開発し、いま動いているものだけ

製品相談チャット — 回答ヒット率 91%

課題: 製品仕様や取引条件の問い合わせが繰り返し届き、営業担当の時間を削っていた。

作ったもの: 製品ナレッジに基づいて答えるチャットボット。本番稼働で回答ヒット率91%。答えられない質問は無理に答えず、人へ引き継ぎます。

LLMだけでは解けなかった点: ヒット率を上げる鍵はモデルではなくナレッジの整備でした。「何を聞かれているか」を先に分類してから答えに当てる二段構えにしています。

AIコンシェルジュ — 即答と空室照会をひとつの窓口に

課題: 施設への問い合わせ対応に人手が取られ、営業時間外は答えられない。

作ったもの: 施設のナレッジを事前に読み込ませ、よくある質問にはAIを介さず即答。空室の照会は裏で並行して走らせ、待たせない構成にしました。業務範囲外の質問には答えないガードレール付きです。

LLMだけでは解けなかった点: 全部をAIに任せると、遅く・高く・時々間違えます。「即答できるもの」「照会が要るもの」「答えるべきでないもの」を先に分けるのが実用の条件でした。

学生支援AI — 1相談あたりの運用費を1円未満に

課題: 入試・履修・学生生活の質問が窓口に集中する。大学ごとに答えが違う。

作ったもの: 大学ごとのナレッジで答える学生支援AI。大学ごとに答えの根拠を分離して持つ設計（他校の情報が混ざらない）。1相談あたりの運用費を1円未満に抑えた構成です。

LLMだけでは解けなかった点: 複数の組織に同じ仕組みを配る場合、ナレッジを1つの索引に混ぜると他組織の情報が漏れます。根拠の分離は精度ではなく事故防止の要件でした。

行政書士向けの申請書の下書き生成 — 掲載制度 844件（2026-09-27 時点）

課題: 補助金・助成金は制度が分散し、要件の確認と申請書作成に時間がかかる。

作ったもの: 全国の制度を横断検索できるサービス。申請書の下書きを作る機能は行政書士向けのプランに限る。掲載制度844件（うち受付中392件、2026-09-27 時点）、要件・上限額・補助率を出典つきで整理しています。

LLMだけでは解けなかった点: 単一のモデルに書かせて終わりにしていません。申請書の生成は複数のAIが分担し、書いたものを別のAIが審査する構成にしています。書き手と審査役を分けることが、下書きとして使える水準の条件でした。

点検所見の生成とCAD反映 — 「描く」作業そのものを無くす

課題: 橋梁・トンネルの点検では、損傷を記録したあとの所見文の作成と、損傷図をCADに描き込む作業に時間が取られていた。

作ったもの: 損傷の記録（部材・種別・程度）から所見文と判定区分の案を出し、損傷図を図面データ（DXF）に自動で反映する仕組み。

LLMだけでは解けなかった点: 判定区分はルール表で決め、AIには文章の整えだけを任せています。またお客様の最大の負担は「CADの作り込み」でした。損傷リストから座標を起こして図面を機械生成すれば、描く作業そのものが無くなります。LLMが要らない工程を見極めるほうが、効果は大きくなりました。

検査結果の読み取り — 書式の違いを吸収して突き合わせる

課題: 健康診断・血液検査の結果は紙で戻り、経年の変化を自分で追えない。

作ったもの: 検査結果の写真から項目と数値をAIで読み取り、正規化して蓄積・グラフ化するアプリ。検査機関ごとに違う書式を吸収して同じ項目として突き合わせられるようにしました。

LLMだけでは解けなかった点: 読み取りより正規化が本体です。「GOT」と「AST」が同じ項目だと知っているかどうかで、データの使い物になる度合いが決まります。文字が読めることと、データが使えることは別の量でした。

施術後シミュレーター — 3方式を実機で比較検証

課題: 施術（眉の縮毛矯正）の仕上がりが想像しにくく、来店の決め手に欠けていた。

作ったもの: 顔写真から施術後の見た目を合成するシミュレーター。AI生成・ハイブリッド・フィルターの3方式を実機で比較検証し、品質と速度と費用の釣り合いが取れる方式を提案しました。

LLMだけでは解けなかった点: 「AI生成が一番きれい」とは限りません。方式ごとに向き不向きを実測してから選ぶ。この比較検証の工程こそが納品物でした。

判例から取扱分野を辿る — 弁護士 41,752人・判例 57,841件

課題: どの弁護士がどんな分野を扱ってきたかは、公開情報からは辿りにくい。

作ったもの: 公開されている判例から取扱分野を辿れる検索サービス。掲載弁護士41,752人／収録判例57,841件。

LLMだけでは解けなかった点: 判例の代理人欄には弁理士や特許庁職員も混ざります。人手で定義を切り分けてから集計しました。元データの意味を確かめずに集計すると、件数は出ても中身が違うものになります。

訳あり物件の損得計算 — 地価 46,989地点

課題: 再建築できるか・いくらか・災害リスクはどうか。判断に要る数字がバラバラの場所にある。

作ったもの: 一画面に並べて30秒で計算するサービス。接道要件（42条道路）を機械チェックし再建築可否の見当を出し、公示地価と地価調査の46,989地点と国交省の取引価格データから価格帯を算出、47都道府県のハザード情報を重ねて表示します。

LLMだけでは解けなかった点: 接道要件の判定は法令の条件式であって、生成の対象ではありません。機械チェックで確定できる部分を先に確定させ、LLMは説明の文面に限定しています。

土地判定レポート便 — システム操作を一切させない設計

課題: 蓄電所・太陽光の用地検討では、系統の空き・規制条例・地番・申請リスクを個別に調べる必要がある。

作ったもの: 住所を送るだけでレポートが翌営業日に届く仕組み。調査は専門チームと自社の判定基盤で実施します。初回1件無料。

LLMだけでは解けなかった点: 利用者にシステムを操作させない形にしました。画面を作ると使われないことがあるため、「住所を送るだけ」を接点にしています。AIの性能ではなく受け渡しの形が採用を決める場面があります。

問診の振り分け — 判定と確からしさを分けて返す

課題: 利用者の相談内容はさまざまで、どの窓口・どの対応につなぐべきかの判断が人に集中していた。

作ったもの: 問診の応答から相談内容を解析し、振り分け先の判定とその確からしさのスコアを返す仕組み。本番稼働中で、判定の根拠を後から追える形で記録しています。

LLMだけでは解けなかった点: 医療に関わる領域では「AIが決める」のではなく「人が決めるための材料を出す」。判定とスコアを分けて返すのはそのためです。根拠を後から追えることを、精度と同じ重さの要件として扱いました。

自己申告と実測のズレを測る — 16問・約3分

課題: 「自分ではこう思っている」と「実際にはこう出ている」は一致しない。その差が見えない。

作ったもの: 16問・約3分で能力と内面の8軸を出す診断。土台に、人の判断の再現を扱う自社基盤（ペルソナ2,449件を蓄積したAPI層と、その中核のデータSDK）を使用しています。診断結果を外部のAIから読める形でも提供（MCP対応）。

LLMだけでは解けなかった点: 自己申告と実測を混ぜずに別々に出すのが設計の核です。平均してしまうと、いちばん知りたい「ズレ」が消えます。軸に優劣はなく、判定は参考値であり、選抜・評価への単独使用は不適です。

留学生管理と入管への報告をひとつに

課題: 日本語学校の学籍情報は紙とExcelに分かれ、入管への報告業務が負担になっている。

作ったもの: 在籍・出席・生活状況の管理と入管への報告業務をまとめたSaaS。2026年4月の入管法改正で増える報告義務に対応しています。

LLMだけでは解けなかった点: 制度が要求する項目は法令で決まっており、生成で埋めてよい欄ではありません。まず情報の一元化を先に済ませることが、報告を自動化する前提でした。

この用途で分かったことを、検証記録ごとに分けて公開しています（11本）

効いた手法だけでなく、棄却したもの・再現しなかったもの・取り消したものを含みます。数値は自社の検証記録に基づき、対象は「対戦型ゲームの上位プレイヤー47名」「本人のSNS返信アーカイブ」「自社が運用する2体のAIキャラクター」のように性質だけを示しています。

• 抽象度には山がある　粗くすると上がり、粗すぎると消える
• 評価器が測定対象に盲だったとき　「無価値」ではなく「未測定」を見分ける
• 判断の再現が成立する条件　選択肢集合と場面の繰り返しで決まる
• 複数エージェントの批判が全滅判定を出すとき、何を疑うべきか
• 相方の記憶を失うとAIキャラクターの会話に何が起きるか
• 前例は何件から効くか　100件の境目と中途半端な履歴が生む害
• 判断の注入が害になるとき　3つの試みが再現しなかった理由
• 状況の表現を変えると、判断の結果が反転する
• 案件を受ける前に見るべき3条件と、超えられない壁
• モデル単体の性能よりシステム全体の性能が判断を分ける
• 判断を誰から借りるか　種類が変われば正解も反転する

開発支援AIの導入検証 — 「作らない」と結論した案件

課題: ゲームエンジン（Unity）の開発をAIで支援するツールを自社開発すべきか判断したい。

作ったもの: 検証用の試作を実際に組みました。コンパイル結果を読んでAIが修正し直す自動ループと、エディタの再読み込みをまたいでも接続が切れない仕組みです。既存のオープンソースと比較し、「この領域はオープンソースで急速にコモディティ化しており、製品としての優位は立たない」と結論して製品化を見送りました。

LLMだけでは解けなかった点: 作る前に「作らない」と言えるかが、検証を引き受ける側の責任です。検証費用は開発費用の数十分の一で済みます。検証で得た仕組みは捨てず、自社のUnity・Unreal Engine開発の工程にそのまま組み込み、AIで自動化しています。

Q. LLMの活用事例で最も多い用途は何ですか

当社が引き受けた案件では、問い合わせ対応の自動化が最も多い用途でした。ただし全問をLLMに答えさせる構成は採っていません。よくある質問はLLMを介さず即答し、照会が要るものだけをLLMに回す二段構えが、速度とコストと正確さの釣り合う実装でした。

Q. 精度を上げる鍵はモデル選定ですか

当社の実装では、モデルよりナレッジの整備で精度が動きました。回答ヒット率91%に到達した案件で効いたのは、「何を聞かれているか」を先に分類してから答えに当てる二段構えの設計であって、モデルの差し替えではありません。

Q. RAG（検索拡張生成）はどの事例で使っていますか

製品相談チャット、旅館AIコンシェルジュ、convai がナレッジを参照して答える構成です。convai では大学ごとに答えの根拠を分離して持たせています。複数の組織に同じ仕組みを配る場合、ナレッジを1つの索引に混ぜると他組織の情報が混ざるため、根拠の分離は精度ではなく事故防止の要件として扱っています。

Q. AI導入の検証だけを依頼できますか

検証のみの依頼も引き受けています。ゲーム開発向けの案件では、試作を組んだうえで製品化を見送る結論を出し、その判断材料を納品しました。検証費用は開発費用の数十分の一で済みます。

Q. LLMを使うべきでない工程はありますか

判定そのものをLLMに任せない設計を採る場面があります。インフラ点検では判定区分をルール表で決め、LLMには文章を整える工程だけを任せました。不動産の接道要件も法令の条件式であり、機械チェックで確定できる部分を先に確定させています。