ZennでUGさんが書いた「RAGだけでは業務AIにならない──失敗の構造と、Agentによる正しい設計」という記事の解説です。
派手な削減事例ではなく、業務AIを作る側が踏み抜きがちな設計の落とし穴を4類型に整理した、設計レビュー寄りのドキュメントです。 発注側の中小企業がAIベンダーと話す前に読んでおくと、提案書の何を疑えばいいかが見えてきます。
僕が注目したのは、「RAGは答える装置、Agentは判断する装置」という役割分離の考え方です。 ここを区別しないままRAGに全部背負わせると、PoCは動いても本番で破綻する、という構造をきれいに言語化しています。
RAG業務AIで詰まる課題
RAG(検索拡張生成)を業務に入れようとした現場でよく起きる問題は、UGさんの記事では以下の4類型に整理されています。
- RAG万能化FAIL — 何でもRAGに答えさせようとし、業務判断まで期待してしまう
- 混在検索FAIL — 契約書・重要事項説明書・FAQ等が同じ検索インデックスに混ざり、文脈が崩れる
- 推測回答FAIL — 文書に書いていないことを「一般常識」で勝手に補完して答える
- 横断不可FAIL — 複数文書をまたいだ質問に正しく答えられない
これらは技術的な不具合ではなく、設計の問題として整理されている点が重要です。 モデルを差し替えても、Embeddingを変えても、設計が同じなら同じ壁にぶつかる、という指摘ですね。
中小企業の発注側からすると、「精度が上がる新しいRAG」と提案されたときに、これが設計の話なのかモデルの話なのかを切り分けるための補助線として使えます。
Agentによる役割分離をどう設計するか
UGさんが提案している解決策の核は、シンプルです。
- RAGの責務: 文書から関連情報を取り出して、その範囲で答えること(答える装置)
- Agentの責務: 質問の分類・情報源の選択・回答可否の判定・人へのエスカレーション判断(判断する装置)
PoCでありがちな構成は、ユーザーの質問→RAG→回答、という一本道です。 これを、ユーザーの質問→Agent(判断)→必要に応じてRAG→Agentが回答可否を確認、という構造に組み替えるという提案です。
判断レイヤーをAIに任せきりにしない、判断の責務を「Agent」というコンポーネントに切り出して明示する、という発想がポイントだと読みました。
業務AIを「フロー」ではなく「判断ポイント」で分解する、という言い方もされています。 ここは中小企業の現場で噛み砕くと、「どの業務を自動化するか」より「どの判断をAIに渡すか」という発注の解像度の話に置き換えられます。
設計の話なので数値は出にくい
この記事は実装事例ではなく設計論なので、「●%削減」のような派手な数値はありません。 公開情報の範囲では、PoC→本番昇格率の具体的な数値も明示されていません。
代わりに書かれているのは「業務判断単位での分解」という再構成の方法論です。 たとえば不動産の問い合わせ業務だと、UGさんの整理では以下のように分けます。
- 質問が事実確認か、判断要求か(Agentが分類)
- 事実確認なら、どの文書群を検索するか(Agentが情報源選択)
- 検索結果が回答可能か、不足か(Agentが回答可否判定)
- 不足なら、誰にエスカレーションするか(Agentが判断)
「RAGが答えてくれる」ではなく、「Agentが回答プロセスを管理する」設計、という言い方ができそうです。
注意点として、これは特定プロダクトの導入記録ではなく、設計者向けの考え方の整理である点です。 数値で効果を語る記事ではなく、「設計を変えると結果が変わる」という構造を示す記事として読むのが正解だと思います。
中小企業で再現するなら
ここからが本題です。年商5億規模の会社で「RAGで社内Q&Aを作りたい」と検討するときに、この記事の知見をどう使うか。
構成
| 項目 | UG氏の記事(設計論) | 中小企業(年商5億・社員30名)に当てはめると |
|---|---|---|
| 対象 | 業務AI設計者・PdM | AI導入担当(兼任) + 委託先ベンダー |
| 道具 | 設計思考(RAG+Agent) | 既存RAGツール + Agent的な前処理層 |
| 月額費用 | なし(知見) | 推定 月3〜10万円(LLM API + RAGツール、2026年4月時点) |
| 初期費用 | なし(知見) | 推定 50〜150万円(設計・PoC・社内データ整備) |
| 体制 | 個人 | 担当者1名+外部支援月10時間 |
| 期間 | — | 2〜3ヶ月でPoC→運用判断 |
評価軸スコア
| 評価軸 | スコア |
|---|---|
| ROI(投資対効果) | ★★★☆☆ |
| 再現性(中小企業) | ★★★☆☆ |
| 難易度(低いほど簡単) | ★★★★☆ |
(難易度=数字小さいほど簡単)
スコア根拠は以下です。
- ROIは中程度。設計を正しくしないと、PoCで止まって投資回収できないリスクが大きい
- 再現性は中程度。RAG+Agentの設計を理解できる人材か支援先が必要
- 難易度は高め。RAG単体より構成が複雑で、PoCの評価設計まで含めると独学はきつい
前提条件・必要データ
- 社内文書がデジタル化されている(契約書・FAQ・マニュアル等)
- どの業務判断をAIに任せたいかが、業務側で言語化できる
- PoCの評価指標を作れる(「なんとなく使える」で止めない)
- ベンダー任せにせず、設計レビューに同席できる発注側担当者がいる
失敗条件・適用しないケース
- 「とりあえずRAG入れたら社内Q&Aが完成する」と期待している
- 業務判断を全自動化しようとしている(人間のエスカレーション設計を入れない)
- 契約書・FAQ・社内規程を同じ検索インデックスにまとめて放り込もうとしている
- PoCの成功基準が「動いた」だけで、本番運用の指標(回答可否率・エスカレーション率等)を作っていない
「RAGを入れれば社内ナレッジ検索ができる」わけではありません。
業務判断の分解 → RAGとAgentの責務分離 → 評価指標の設計 → PoC → 本番移行判断、というプロセスを踏んで初めて、業務AIが定着する形が見えてきます。
中小企業の発注側がこの記事を読む価値は、ベンダー提案を読む補助線が増える点です。 「これはRAG万能化FAIL寄りの提案だな」と気づければ、設計の打ち合わせをやり直せます。
出典・参考
市野
愛知県岡崎市でAI活用支援を手がける一人社長。 中小企業の現場でAIを実装してきた経験から、他社事例を「うちで再現するには」の視点で読み解いて発信中。
愛知県岡崎市を拠点に、中小企業向けのAI活用支援を提供。ChatGPT・Claude Code等を活用した業務自動化やSEO・広告運用の内製化を支援。経営者が自らAIを使いこなせる体制づくりをサポートしている。
＞＞詳細なプロフィールはこちら