RAGだけでは業務AIにならない──失敗の構造と、Agentによる正しい設計(全文版)

第0章RAGだけではダメな理由

0-1. はじめに

ChatGPT、Geminiが出てきたことで生成AIは誰でも使える時代になり、その便利さは皆さん体験いただいている通りです。

そして効率化を狙い生成AIをビジネスに組み込む取り組みも色々と聞かれ、その中には成功や失敗もあります。

私自身ビジネスに活用していくという取り組みは日本全体にとって必須と考えており、AI講師の経験や自身の失敗を踏まえ、仕事で使えるAIを導入するにはどうしたらよいかを、皆さんにお伝えできればと思いこの記事を書きました。

本記事は、業務AIの課題は“性能”ではなく“設計”が大切ということ、AIの精度を上げる方法ではなく業務で“安全に使える設計”にするための考え方をお伝えします。

0-2. RAGとは何か

・RAG＝AIが社内文書を参照しながら回答する仕組み
LLMはある時点までの情報しか持っていませんし、公開されていない情報はわかりません。そういった情報を参照し回答させることができます。

ここから先は会員のみ読めます

・「知識を与える」点では非常に強力
外部情報を元に回答を得ることが出来るので知識量はどんどん増やせる

・多くの現場で最初に選ばれる王道アーキテクチャ
企業でまずAIを導入するならRAGから！！

0-3. それでもRAGだけでは業務AIにならない

RAGは入れたけど。。。

・「期待した回答が返らない」
・「それっぽいけど間違っている」
・「業務ルールを守らない」

ということがしばしば発生します。

原因はRAGそのものではなく、
業務で使うことを前提にした設計が行われていないことにあります。

0-4. RAG単体で起きる“典型的な失敗（FAIL）”

・RAG万能化：何でも答えさせようとする
・混在検索：契約書・重説・FAQが混ざる
・推測回答：文書に無いことを“常識”で補完
・横断不可：複数文書をまたぐ質問に弱い

⇒「RAGが悪い」のではなく「RAGに役割を持たせすぎている」
※これらの失敗は、RAGを作る人の能力不足ではなく、
「RAGに業務判断まで求めてしまう設計」が原因です。

0-5. 業務とは「判断の連続」である

人の仕事は「質問→判断→次の行動」の連続

実務では以下を常に判断している

・どの資料を見るか
・答えるべきか
・断るべきか

だけどRAG単体では「判断」をしない　

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

判断をしないAIは業務では危険

業務では「分からない」と答えることも重要です。
しかしRAGは、分からなくても何かを答えようとする設計になりがちです。

0-6. 業務AIに必要なのは「知識」ではなく「責務分離」

・業務AIには役割分担が必要
・「判断」と「検索」と「回答」を分ける発想
・これを担うのが Agent

0-7. 本教材で扱う全体像

第1章：RAG単体で“正しく出来ること／出来ないこと”

第2章：Agentによる責務分離設計

第3章：業界業務フローからの設計

第4章：他業界へ横展開するテンプレ

第5章：導入・運用・評価の実務設計

この教材は作って終わりではなく現場に持ち帰って使用できるテンプレを提供します。

0-8. まとめ：RAGは土台、業務AIは設計

・RAGは必要。だがそれだけでは不十分

・業務AIに必要なのは「正しい失敗構造の理解」

・次章から、その構造を1つずつ解体していく

RAGは“脳”ではなく“記憶庫”
業務AIに必要なのは、その記憶庫をどう使うかを決める設計が重要

第1章RAG単体で「正しくできること／できないこと」

1-1. 本章の目的：RAGを“正しく期待する”

要点

RAGは万能ではない

だが「使えない技術」でもない

問題は 期待値の置き方 にある

伝えたいこと

なぜRAGだけだと業務で失敗するのか

それを「感覚」ではなく「構造」で理解する

👉 第0章で提示したFAILを、ここで“分解・検証”する章

1-2. RAGの内部構造を整理する（最小限）

RAGの構成

流れ
[ ①ユーザー質問 ]
│
▼
[② Retriever ]
├─ Embedding
├─ Vector Search（top-k）
└─ filter（doc_type 等）
│
▼
[ ③取得文書群 ]
│
▼
[③ LLM ]
│
▼
[ ​回答 ]

RAGは 「質問 → 類似文書 → 回答生成」 の一直線構造
途中に 判断・分岐・拒否 は存在しない

RAGの基本構成
・文書分割
・Embedding
・Vector Search
・LLM回答生成

「検索」と「生成」は別物
RAGは 判断をしない

RAGは
❌ 正しい文書を「選ぶ」
❌ 答えるべきかを「判断する」
ことはできない

👉 あくまで「与えられた条件の中で文章を作る装置」

1-3. RAGで“正しくできること”

要点

単一文書・明示記述がある質問

事実抽出・要約

定型FAQ的質問

例

「この契約書の解約条項は？」

「重要事項説明書に書かれている制限事項は？」

結論

RAGは
「答えが明確に文書内に存在する問い」には非常に強い

1-4. RAGで“できない（失敗しやすい）こと”

（第0章のFAILを正式定義）

❶ RAG万能化FAIL

何でも答えさせようとする
業務判断まで期待してしまう

❷ 混在検索FAIL

契約書・FAQ・社内ルールが混在
どの文脈の正解か分からなくなる

❸ 推測回答FAIL

文書に無いことを補完
「一般常識」「慣習」で埋める

❹ 横断不可FAIL

複数文書の関係性が必要
条件分岐・前提整理ができない

👉 ここで初めて「FAIL分類」が正式登場

1-5. FAILは“精度の問題”ではない

要点

Embeddingやモデルを変えても治らないFAILがある

Chunkサイズをいじっても解決しない

1-6. FAILを「評価できる形」にする

要点

「なんとなく変」では改善できない
FAILは構造として測定できる

導入する概念

FAIL分類ラベル
簡易評価指標（正答／推測／逸脱）
NGパターン例

👉 第5章の運用・評価フローにつながる伏線

1-7. まとめ：RAGは“答える装置”であり“考える装置”ではない

まとめポイント

RAGは非常に強力な基盤

しかし「業務判断」を担わせてはいけない

FAILは避けるものではなく、設計改善のサイン

第2章Agentによる責務分離設計

― なぜ「判断役」をAIに持たせる必要があるのか ―

第1章では、RAG単体で**「正しくできること」と「できないこと」**を整理しました。 RAGは非常に強力な仕組みですが、万能ではありません。特に重要なのは、次の点です。

RAGは「判断」をしない構造であり

・文書を検索し
・見つかった情報を元に
・文章を生成する

という一直線の仕組みであり、

・答えるべきか
・どの資料を見るべきか
・この質問を断るべきか

といった 業務上の判断 を行う工程を持っていません。そのため、第1章で整理した以下のFAILは モデル選定やEmbedding調整では解消できません。

・RAG万能化
・混在検索
・推測回答
・横断不可

これらはすべて、 **「RAGに判断役まで期待してしまうこと」**で発生する構造的な問題でした。

「RAGを強くする」のではなく「役割を分ける」

ここで一度、発想を切り替える必要があります。

業務AIで起きている問題は、

・検索精度が足りないから
・モデルが賢くないから

ではありません。

そもそも、RAGに“その役割を任せる設計”になっていることが問題なのです。

業務では、本来

・どの情報源を使うか判断し
・答える／答えないを決め
・必要な情報だけを取りに行く

という 判断のステップ が必ず存在します。

この「判断」をRAGに担わせるのではなく、
専用の役割として切り出す。

その考え方が Agent（エージェント） です。

ここでよくある誤解があります。

Agentとは、

「LLMをより賢くする仕組み」 ではありません。

Agentの本質は、

業務の判断構造をAIに実装するための“役割分解設計”

です。

Agentは、RAGの代わりに検索する存在でも
すべてを理解して動く万能AIでもありません。

Agentの役割は、

いつ・何を・どこまでRAGにやらせるかを決めること

にあります。

この章では、

・第1章で整理した FAIL を
・**「誰の責務が曖昧だったか」**という視点で分解し、
・RAGが本来得意な役割に集中できる構造を設計します。

具体的には、
・Agentが担う判断とは何か
・Tool（RAG）との責務の分け方
・FAILが「どの判断不在」で起きていたのか

を、構成図とルールベース思考で整理していきます。

2-1. 業務を「判断単位」で分解する

なぜ「業務」をそのままAI化してはいけないのか

業務AIの設計で、最初にやりがちな失敗があります。

それは、

業務フローを、そのまま質問応答に置き換えようとすること

です。

例えば、

・「この契約内容は問題ありますか？」
・「このケースは実行していいですか？」
・「顧客にどう説明すればいいですか？」

一見すると自然な質問ですが、 これらはすべて 複数の判断が混ざった質問 です。

人間は無意識にこれを処理していますが、 AIにとっては「何をすればいいか」が曖昧になります。

業務を構造として分解すると、実体は次の繰り返しです。

もう少し具体的にすると、

１、どの情報を見るべきか判断する
２、その情報を確認する
３、答えるか／答えないか判断する
４、どういう形式で返すか判断する
私たちは普段、これを無意識に行っています。

しかし RAGはこの「判断」を一切しません。

RAGはただ、

与えられた質問に対して、近い文書を探して文章を作る

だけです。

判断を含む質問の危険性（例）

例として、不動産業務を考えてみます。

「この物件は契約して問題ありますか？」

この質問の中には、以下の判断が含まれています。

・どの文書を見るか （契約書？重説？社内ルール？）
・判断する権限はあるのか
・判断材料は揃っているか
・「問題あり／なし」を断定してよいか

しかしRAGに渡されるのは 最終質問1行のみ です。

結果として起きるのが、第0章・第1章で整理したFAILです。
・なんとなくそれっぽい判断をする
・文書に無いことを補完する
・異なる文脈を混ぜてしまう

「判断単位」で業務を切るという発想

ここで必要なのが、 業務を「質問単位」ではなく「判断単位」で分解する という視点です。

判断単位とは、次のようなものです。

・この質問は「回答してよい」か？
・情報源は「契約書」か「FAQ」か？
・これは「事実確認」か「判断要請」か？

つまり、
Yes / No / 分岐が発生する点が判断単位
です。

判断単位に分解すると、業務はこう見える

一見1つに見える質問も、実はこう分かれます。

一見1つに見える質問も、実はこう分かれます。

ユーザー入力
↓
① この質問は何のタイプか？
↓
② 参照すべき情報はどれか？
↓
③ 十分な情報は揃っているか？
↓
④ 回答すべきか／拒否すべきか？
↓
⑤ 回答を生成する

このうち、

⑤ は RAGの得意領域
①〜④ は 判断領域
です。
これを切り分けずにRAGだけで処理すると、 FAILが発生するのは当然と言えます。

Agentの登場理由がここにある

Agentとは何かを一言で言うと、

上記①〜④の判断を担当する役割

です。

Agentは、
・知識を増やす存在ではなく
・回答を賢くする存在でもなく
「どのRAGを、どの条件で使うか」を決める存在です。

だからこそ、
・RAG万能化を防げる
・混在検索を事前に遮断できる
・推測回答を拒否できる
ようになります。

まとめ：業務AI設計で最初にやるべきこと

業務AIの設計で、最初に考えるべきは

「何を検索させるか」ではなく 「どこで判断が必要か」

です。

・判断を構造として洗い出す
・判断をAgentの責務にする
・RAGは「答えること」に集中させる

これが、業務AI設計の出発点になります。

2-2. Agentが担うべき判断／担ってはいけない判断

なぜ「Agentなら何でもできる」は危険なのか

第2-1節で、業務は「判断の連続」であり、
RAG単体ではその判断を扱えないことを整理しました。

ここで次に陥りやすいのが、

「じゃあ全部Agentに任せればいい」

という発想です。

しかし、これもまた危険です。

Agentはあくまで “判断を振り分ける存在” であり、
業務判断そのものを勝手に下す存在ではありません。

Agentにも、担うべき判断 と 担ってはいけない判断 の線引きが必要です。

Agentの役割を一言で定義する

本教材におけるAgentの役割を、最初に明確にしておきます。

Agentとは 「業務ルールに従って、使うRAG・使わないRAGを決める存在」

重要なのは、

・Agentは 知識を持たない
・Agentは 答えを創らない
・Agentは 推測しない

という点です。

Agentは「決める」だけであり、「答える」のは常にRAGです。

Agentが担うべき判断（やるべきこと）

Agentが担うべき判断は、大きく次の4つに整理できます。

① 質問タイプの判別

② 参照すべき知識源の選択

③ 検索条件の制御（filter / top-k）

④ 回答可否の判定（Gate）

この4つに対して詳しく見ていきましょう。

① 質問タイプの判別

・事実確認か？
・要約か？
・業務判断か？
・本来は「答えてはいけない」質問か？

この分類ができないと、 RAGは何に対して答えているのか分からなくなります。

👉 質問の意味を理解する、ではなく「分類する」

ここが重要です。

② 参照すべき知識源の選択

Agentは、

・契約書RAG
・重要事項説明RAG
・FAQ RAG
・社内ルールRAG

といった Tool（RAG）単位の選択 を行います。

ここで初めて、
・混在検索FAIL
・文脈混乱
を防げるようになります。

③ 検索条件の制御（filter / top-k）

Agentは、

・doc_type を固定する
・契約種別・物件種別で絞る
・top-k を用途別に変える

といった 検索条件のガード を担います。

これによって、
・関係ない文書の混入
・意味の薄いチャンクの混在
を抑制できます。

④ 回答可否の判定（Gate）

これが最も重要です。

Agentは、

・根拠となる文書が無い
・判定材料が不足している
・判断を下すべき質問である

と判断した場合、
「RAGを呼ばない」という選択
をします。

つまり、

❌ 無理に答えさせない
✅ 答えないことを決める

この判断こそが、業務AIにおいて最も重要です。

Agentが担ってはいけない判断（やってはいけないこと）

❌ 業務判断そのものを下すこと

例：

「この契約は問題ありません」
「この条件なら進めてOKです」

これはAgentの仕事ではありません。
それをやってしまうと、
・推測回答FAIL
・責任所在の不明確化
に直結します。

❌ 文書に無い知識で補完すること

Agentが「常識的にこうだろう」と判断するのはNGです。

Agentは、
・文書があるか
・条件が揃っているか
しか見てはいけません。

❌ 回答フォーマットを勝手に作ること

AgentはUI設計や表示制御には関与しますが、

・専門的な表現
・法的な言い回し
・文案作成

はRAGの役割です。

良いAgent設計／悪いAgent設計の違い

Agentは「賢くする」ためでなく「事故を止める」ためにある

Agentを導入すると、
・回答精度が上がる
・賢く見える
と思われがちですが、本質は違います。

Agentの最大の価値は 「間違った回答が出る前に止めること」

です。

・答えない判断ができる
・適切なRAGだけを使う
・RAGに無理な期待をさせない

これによって、業務AIは “使える”状態 になります。

補足
【Agent責務マトリクス表】

業務AIで越えてはいけない線

AIは判断を自動化できても、責任を自動化することはできない

だから図の最下段は必ず：

最終判断・責任 = 人

になります。

RAG、Agent、人の責務分け

続いて判断分類ルールを見ていきましょう。

① 判断分類の基本思想

業務AIに聞かれる質問は、必ずこの3種に分解できる

１ 答えるべき質問

２ 注意付きで答える質問

３ 答えてはいけない質問

👉 Agentは 知識を使わず、この振り分けだけを行う

② 判断分類マトリクス

③ 各分類のAgent動作ルール（具体）

１ 回答OK（RAG実行）

条件
文書に明示的記載あり
判断・解釈を含まない

例
「この契約書の解約条項は？」
「重要事項説明書に書いてある制限事項は？」

Agent動作
- 適切なTool（RAG）を選択
- filter + top-k を指定
- 回答生成を許可

⚠️２ 注意付き回答（条件提示）

条件

文書に書いてあるが
業務判断・解釈・条件分岐を含む

例
「この契約は途中解約できる？」
「このケースは違反になりますか？」

Agent動作
- RAG実行（根拠取得）
- 回答時に条件・前提・注意書きを付与
- 最終判断は人に委ねる文言を付ける

定型フレーズ

「文書には以下の記載がありますが、 最終判断は担当者にてご確認ください」

🚫 ３ 回答禁止（人へ誘導）

条件
文書に書いていない
業務判断・責任・例外判断を含む

例
「この契約、結局どう判断すればいい？」
「今回は特別扱いできますか？」

Agent動作
- RAGを実行しない
- 回答拒否
- 人に確認させる導線を提示

定型フレーズ

「該当する明確な記載が文書内に存在しないため、 本件は担当者による判断が必要です」

④ FAIL分類との対応関係（再接続）

第3章 業務フローから Agent / RAG を設計する

3-0. 「AIを作る」のではなく「業務をそのまま映す」

第1章・第2章では、

・RAGは「答える装置」であること
・業務AIに必要なのは「判断」であり、その判断をAgentが担うこと
・FAILは精度不足ではなく、責務設計の問題であること
を整理してきました。

本章では、いよいよ **「実際の業務をどうAI構成に落とすか」**を扱います。

業務AIは「自然言語AI」ではない

多くの生成AI導入が失敗する理由は、 業務が“曖昧な会話”ではなく“判断の連続”でできている という事実を軽視している点にあります。

現場の仕事は、次のような流れで進んでいます。

・どの資料を確認するか判断する
・今回は答えてよいかを判断する
・例外として扱うべきかを判断する
・判断できない場合は、人にエスカレーションする

つまり、業務とは 「質問→検索→回答」ではなく 「質問→判断→次の行動」 なのです。

RAGを業務に直接当てはめてはいけない理由

RAGは優れた検索・生成機構ですが、
・業務の流れを理解しない
・判断点の存在を知らない
・責任の境界を意識しない
という性質を持っています。

そのため、業務フローを無視してRAGを「質問箱」として置くと、
・判断すべき場面で答えてしまう
・答えてはいけない場面で推測する
・文書横断や例外処理で破綻する
というFAILが発生します。

本章でやること：業務フローを「判断単位」に分解する

この章では、AI視点ではなく 業務視点から設計を始めます。

具体的には、

１、業務フローをそのまま書き出す
２、フロー内の「判断点」を抽出する
３、それぞれを
・Agentが止める
・RAGに渡す
・人に返す に分類する
４、FAILが起きない構成として再構成する

という手順で進めます。

本章を読み終えたときに得られるもの

この章を通して、読者は次の状態になります。

・業務フローを見て 「ここはAgent」「ここはRAG」「ここは人」 と自然に切り分けられる
・「Agentを何体作るか」で悩まなくなる
・新しい業務でも、同じ設計思想で展開できる

つまり本章は、 業務AI設計を“再現可能な技術”にする章です。

3-1. 業務フローを「作業」ではなく「判断」で分解する

業務フロー図がAI設計に使えない理由

多くの業務設計では、次のようなフロー図が使われます。
・受付
・確認
・入力
・回答
・完了
しかしこのような「作業ベース」のフローは、 AI設計にはそのまま使えません。

なぜなら、AIが失敗するポイントは 「作業」ではなく 「判断」 に集中しているからです。

人の仕事は「判断の連続」でできている

実際の業務をよく観察すると、 人は作業の合間に、常に次の判断を行っています。
・この質問は、どの資料を見るべきか
・今回は即答してよいか
・例外的なケースではないか
・自分の判断範囲か、それとも上司判断か

これらは業務マニュアルには 明示的に書かれていない判断であることがほとんどです。

しかし、業務の品質を左右しているのは まさにこの「暗黙の判断」です。

NG例：作業フローのままAIに落とす

よくある失敗例は、次のような流れです。

・業務フローを書き出す
・各作業をそのままAI処理に割り当てる
・「受付 → RAG → 回答」で完成した気になる

この構成では、

・判断が必要な場面もRAGに丸投げされ
・AIが「答えてはいけない場面」で答え
・FAILが量産されます

👉 これは精度の問題ではありません。構造の問題です。

正しい分解単位は「判断ポイント

業務フローをAI設計に使うためには、分解単位を「作業」から「判断」に切り替えます。

具体的には、業務を次の問いに置き換えます。
・ここで人は何を判断しているか？
・Yes / No で分かれる地点はどこか？
・判断結果によって次の行動は変わるか？

この 判断が入る地点 がそのまま Agent設計の起点 になります。

判断単位で見た業務フローの例（不動産業務）

例として、不動産契約関連の問い合わせを考えてみます。
従来の作業フロー

・問い合わせ受付
・契約書確認
・回答作成
・返信

判断単位で分解すると

１この質問は「契約書」で答えるものか？
２「重要事項説明書」も参照が必要か？
３文書に明記されている内容か？
４解釈・判断が必要ではないか？
５人に確認すべき案件ではないか？

👉 作業は4つでも、判断は5つ以上存在する。

ここで重要なのは、 これらの判断はRAGにはできない という点です。

判断単位とFAILの対応関係

第1章で扱ったFAILは、すべて「判断不在」から発生しています。

つまり、
FAILを潰す＝判断ポイントを明示する
という関係になります。

この章以降の設計方針

ここまでで分かるのは、

業務フローは
✅ 作業ではなく判断で見る

判断は
✅ Agentの責務として切り出す

RAGは
✅ 判断後に「使われる道具」にする

という設計原則です。

3-2. 判断を「Agentの責務」として定義する

なぜ「判断」を明示的に定義する必要があるのか

前節で見た通り、業務フローには多数の判断ポイントが存在します。 しかし多くのAI導入では、この判断が
・暗黙のまま
・人の経験に依存したまま
・RAGに丸投げされたまま
になっています。

その結果、

「どこまでAIがやってよいのか分からない」 「失敗したとき、どこが悪いのか特定できない」

という状態に陥ります。

👉 判断をAgentの責務として言語化し、構造に落とすこと これが第3章の核心です。

Agentの役割を先に定義する

ここで一度、Agentの役割をはっきりさせます。

Agentは次のことを行います。
・文書を読む ❌
・知識を持つ ❌
・回答を生成する ❌

では何をするのか。

✅ 判断する
✅ 選ぶ
✅ 制御する
✅ 止める

Agentは 「業務上の門番（Gate）」 の役割を担います。

判断責務の4分類（最小構成）

業務で必要な判断は、ほぼすべて次の4種類に分解できます。

① 質問タイプ判定

・この質問は何に関するものか
・契約か、FAQか、業務ルールか
・単一資料か、横断が必要か

👉 どのRAGを使うかを決める判断

② Tool（RAG）選択判断

・契約書RAGか
・FAQ RAGか
・複数RAGを順番に使うか

👉 検索対象を混在させないための判断

③検索条件制御判断

・top-k をどの程度取るか
・filter（doc_type など）をどう掛けるか
・広く探すか、狭く探すか

👉 RAGの振る舞いを制御する判断※ RAG「内部の精度調整」ではなく、外からルールで縛ることが重要

④ 回答可否判断

・文書に明示されているか
・解釈・推測が必要ではないか
・人に返すべき案件ではないか

👉 「答えない」という選択を含む判断RAG単体では、 この判断は 絶対にできません。

判断責務を持たせないと起きるFAIL

この4つの判断がAgentに無い場合、第1章で扱ったFAILが発生します。

👉 FAILは「精度が悪い」からではなく
👉 判断責務が空白 だから起きる
ここが非常に重要なポイントです。

判断は「Yes / No」で定義する

Agent責務を設計する際の原則はひとつです。

判断は必ず Yes / No にする

・解釈不要
・曖昧表現なし
・LLMに雰囲気で決めさせない

例：
❌「答えられそうか？」
✅「文書内に明示されているか？」

❌「業務上問題なさそうか？」
✅「業務判断を含むか？」

👉 Agentは 業務ルールを実行する装置であり、 創造する存在ではありません。

Agent責務は「制御点」として実装する

ここまでの判断は、 以下のような制御点として実装されます。

・if / else
・ルールベース判定
・スコア閾値
・明示的なSTOP

LLMを使う場合でも、
・出力は分類のみ
・YES / NO のみ返す

という 役割限定 が原則です。

第3層への接続：人の責任との切り分け

Agentが「止める」判断をした場合、

・曖昧な回答を出さない
・勝手に解釈しない
・人に戻す

ここで初めて 人の判断 が入ります。

👉 AIの誤回答を止める最後の砦は、Agent設計そのもの

3-3. 業務フローから Agent / RAG 構成を起こす

本節の目的は明確です。

業務フロー → Agent判断 → RAG構成 を一筆書きでつなぐこと

ここまでで、

第1章：RAGが「できない理由」
第2章：判断をAgent責務として分離する

を整理してきました。

この3-3節では、それを 机上の設計論で終わらせず、

✅ 実際の業務
✅ 実際の質問
✅ 実際のAI構成

へと落とし込みます。

ステップ0：まず「AI」を忘れる

最初にやることは AIのことを考えない です。

RAG構成やAgent設計から入ると、必ず失敗します。

代わりにやるのはこれです。

人が仕事をしている流れを、そのまま書き出す

ステップ1：業務フローを「人視点」で書く

例：不動産業務（シンプル化）

① 質問を受ける

② 質問内容を把握する

③ どの資料を確認すべきか判断

④ 資料を読む

⑤ 回答してよいか判断

⑥ 回答 or 上長に確認

この段階では、

・AI
・RAG
・Agent

という単語は出てこなくてOKです。

ステップ2：判断ポイントだけを抜き出す

次にやるのは、「考えている瞬間」を抜き出す先ほどのフローから判断部分だけを抽出します。

ステップ3：判断をAgentの4責務にマッピングする

次に、判断を 第2章で定義した4分類 に当てはめます。

ここで初めて Agentが登場します。
👉 Agentは業務フローの「判断部分だけ」を担当する

ステップ4：「読む」作業をRAGに割り当てる

次にやるのは、判断ではない作業を、RAGに渡すことです。

人の業務でいうと、

・資料を読む
・関連箇所を探す
・要約する

この部分が RAGの責務 になります。

重要な整理

・RAGは「資料を読む装置」
・Agentは「読ませ方を決める装置」

役割が完全に分かれます。

ステップ5：Agent → RAG → Agent の往復構造を作る

構成は一直線ではありません。

ユーザー質問
↓
Agent（判断）
↓
RAG（検索・要約）
↓
Agent（回答可否判断）
↓
回答 or STOP

2回Agentが出てくる のがポイントです。

なぜAgentは2回必要なのか

① 前段Agent

どのRAGを使うべきか
どう検索させるか

② 後段Agent

得られた結果で答えてよいか
推測が混ざっていないか

👉 RAGは途中で止まれない
👉 だから Agent が前後を挟む

ステップ6：FAILがどこで止まるかを明示する

この構成の強さは、FAILの止まる位置が決まることです。

結果として、
・変な答えが出ない
・原因が特定できる
・改善点が明確になる

Agent / RAG構成は「業務の写像」

ここまでの流れを一言で言うと、
Agent / RAG構成は業務フローの構造をそのままAIに写したもの
です。

・新しいことはしていない
・人の仕事を、そのまま分解しただけ

これが 再現性 の正体です。

3-4. 業務フロー × UI（Streamlit / FastAPI）

この節で伝えたいことはシンプルです。

UIが変わっても、業務AIの中身は変わらない

・Streamlit
・FastAPI
・将来的なLINE / Webフォーム / 社内システム

どれを使っても Agent / RAG 設計は再利用できる という状態を作ります。

まず結論：UIは「入口」でしかない

多くの失敗は、ここから始まります。

・Streamlit用に設計する
・FastAPI用にロジックを書く
・UIごとにAI構成がズレる

👉 これは 業務AIとしては破綻 です。

正しい考え方はこうです。

UIは質問を渡すだけ
業務判断はすべて Agent が担う

業務フローとUIの対応関係

人の業務フローを思い出します。

質問を受ける
→ 判断する
→ 資料を読む
→ 判断する
→ 回答する

これをAIに写像するとこうなります。

UI（質問入力）
→ Agent（判断）
→ RAG（読む）
→ Agent（判断）
→ UI（回答表示）

👉 UIは前後にいるだけ
👉 中央はすべて業務ロジック

Streamlit の役割（教材UI）

Streamlitは、教材・PoC・可視化に最適です。

Streamlitが担うもの
・質問入力フォーム
・実行ボタン
・回答表示
・使用ツール表示
・FAIL・評価結果の可視化

Streamlitが担わないもの
・判断
・検索制御
・回答可否判断
👉 これらは 一切やらない
　　理由は1つだけUIに業務知識を持たせると、設計が壊れる

FastAPI の役割（業務API）

FastAPIは、本番・業務連携向けです。

FastAPIが担うもの
・外部からのリクエスト受付
・入力形式の統一
・Agent実行のトリガー
・結果返却（JSON）

FastAPIが担わないもの
・判断ルール
・業務フロー解釈
・人的判断代替ロジック
👉 これらは Agentコードに閉じる

同一Agentを2UIで使う理由

ここがこの節の核心です。

❌ よくある間違い
・Streamlit用Agent
・FastAPI用Agent
👉 UIごとに仕様がズレる
👉 評価不能

正しい構成は

Agentは1つ、UIは複数、判断ロジックは共通

なぜ教材では Streamlit から入るのか

理由は明確です。

・内部挙動が見える
・Tool選択が見える
・FAILの原因が見える
・評価をUIに出せる
👉 学ぶには Streamlit 👉 使うには FastAPI

この段階的移行ができる構成こそが 教材としての正解 です。

UIと責務分離の整理

ここで一度、責務を整理します。

👉 UIは 業務を知らなくてよい

UIに評価を載せる意味

Streamlitでは以下を表示できます。

・選択されたTool
・filter / top-k
・FAIL分類ラベル
・回答可否（OK / STOP）

これにより、

・Agent設計が正しかったか
・FAILはどこで止まったか

が一目で分かります。

👉 これは FastAPI単体では難しい
👉 教材が先に Streamlit である理由

「UIを変えても壊れない」状態とは

この章までで作っているのは、

・Streamlit用アプリ
・FastAPI用API

ではありません。
作っているのは、

業務フローを写像したAIコア

UIは差し替え可能
Agentは不変
RAGは資産

3-5. 第3章まとめ → 第4章接続

― 業務設計ができれば、業界は変えられる

3章で何をやったのか（要約）

第3章のテーマは一貫していました。

業界固有なのは「業務」
AI設計は業界共通である

そのために、以下の順で整理してきました。

① 業務フローを「処理」ではなく「判断」で分解した
・作業手順ではなく
・人が何を判断しているか に注目
・「どの資料を見るか」
・「答えるか / 断るか」
・「誰の責任か」
👉 これが Agent設計の起点

② 判断を Agent の責務として定義した

・Agentは文書を読まない
・Agentは知識を持たない
・Agentは 判断だけを行う

判断する
↓
読むべきRAGを選ぶ
↓
答えるか決める
👉 RAGを「使う側」に回した

③ 業務フローから Agent / RAG 構成を起こした

・契約書RAG
・重説RAG
・FAQ RAG

それぞれを Tool単位で分離

👉 「混在検索FAIL」を設計で封じた

④ UI を業務設計から切り離した

・Streamlit
・FastAPI

どちらから入っても

UI → Agent → RAG → Agent → UI

👉 業務ロジックは一切ブレない

ここで第0〜2章で扱ったFAILと照合します。

👉 RAG単体では解決できなかったFAILが、設計で解消された

重要なポイント：これは不動産特有ではない

ここまで読んで、

「不動産だからできたのでは？」

と思った方がいるかもしれません。

結論は逆です。

業界固有なのは「資料」と「業務用語」

・文書の種類
・契約内容
・法規
・用語

👉 ここは業界で変わる

業界共通なのは「判断構造」

・どの資料を見るか
・回答可否判断
・責任分解
・業務フロー上の分岐

👉 ここはどの業界も同じ

つまり何が移植可能か

第3章で作ったもののうち、

🔁 横展開できるもの
・Agent設計思想
・判断分類ルール
・Tool分割の考え方
・FAIL分類 × 評価方法
・UI × Agent分離構成
🔄 置き換えるだけのもの
・文書内容
・業務用語
・ナレッジソース

第4章― 設計ができれば、業界は変えられる

第3章では、不動産業務を題材にして 業務フローから Agent / RAG 構成を起こす方法を整理しました。

ここまで読んで、次のように感じている方も多いはずです。

このやり方は他の業界でも使えるのか？

不動産だから成立しているのでは？

自分の業務に当てはめるには、何を変えればいいのか？

第4章は、その疑問に正面から答える章です

第4章の結論

業務AI設計で業界ごとに違うのは、知識だけです。

・判断の構造
・Agentの責務
・RAGの分離方法
・FAILの出方

これらは、業界が変わってもほとんど同じです。

なぜ多くの業務AIが「業界ごとに作り直し」になるのか

現場導入でよく見る失敗があります。

・業界ごとにフルスクラッチで作り直す
・文書が変わるたびに設計をやり直す
・モデルやRAG構成から考え直す

この原因は明確です。

業務を「知識中心」で捉えているから

しかし実際の業務は、

・文書が違っても
・用語が変わっても
・法規が違っても

その中で人がやっていることは、
判断 → 選択 → 責任整理
という構造からほとんど変わりません。

第4章の役割

この章では、第3章までで作った設計を

👉 「業界非依存テンプレ」
👉 「再利用可能な設計型」

として整理します。

本章でやること

・不動産業界の設計を抽象化する
・どの業界でも使える粒度に落とす
・「差し替えるだけで使える部分」と
・「必ず共通になる部分」を分離する

本章で扱わないこと

・各業界の専門知識
・業界特有の法解釈
・個別業務の細部ルール
👉 それらは RAGに閉じ込める対象 です。

第4章で得られる状態

この章を読み終えた時、あなたは
・新しい業界の業務フローを見て
・「ここにAgent」「ここにRAG」
・「ここで止める」

を 1枚の図に落とせる ようになります。

第4章の構成

4-1：業界が変わっても共通な「判断構造」

4-2：業界固有で変わる部分／変わらない部分

4-3：他業界テンプレ（業務 → Agent → RAG）

4-4：FAILの出方はどう変化するか

4-5：全業界共通で使える設計チェックリスト

4-1「業界が変わっても共通な判断構造」

AI導入を検討する現場では、よくこんな言葉が出てきます。

「この業界は特殊だから」
「他社事例は参考にならない」
「業務が違いすぎる」

ですが、ここまで業務フローと判断単位を分解してきた人なら、 少し見え方が変わってきているはずです。

業務の“表面”は業界ごとに違う

確かに、表面的には違います。

・不動産：契約書・重説・法令
・金融：約款・商品条件・規制
・製造：仕様書・図面・工程
・人事：規程・評価ルール・制度

扱う文書も、用語も、法律も全部違います。

👉 これは「知識の差」です。

業務の“中身”はほぼ同じ

一方で、第3章の分解手法で業務を見てみると、

どの業界でも必ず現れる判断があります。

✅ 共通する判断①

「この質問は、答えてよいか？」
・情報が揃っているか
・社外公開してよいか
・想定外の質問ではないか

👉 不動産でも、金融でも、医療でも必ず存在

✅ 共通する判断②

「どの情報源を見るべきか？」
・約款か、FAQか、社内規程か
・最新版か、過去版か
・個別案件か、一般ルールか

👉 文書が違うだけで、構造は同じ

✅ 共通する判断③

「この情報だけで結論を出してよいか？」
・例外条件は無いか
・複数文書をまたぐ必要はないか
・人確認が必要ではないか

👉 ここを誤ると業務事故になる

✅ 共通する判断④

「止めるべきか／人に渡すべきか？」

・判断責務を超えていないか
・推測になっていないか
・責任が持てない回答ではないか

👉 業務AI最大の安全装置

重要なのは「判断の型」

ここで重要なのは、

・何を判断しているか → 〇
・どう判断しているか → ◎

という点です。

業界ごとに違うのは
・判断材料（＝知識）
・判断根拠（＝文書）

であって、判断の型そのものは変わりません。

なぜRAG単体では業界展開できないのか

RAG中心で設計すると、
・文書が変わる
・用語が変わる
・ルールが変わる

たびに、

👉 設計全体を作り直すことになります。

なぜなら、
・RAGは知識依存
・判断を持たない
・業務構造を抽象化できない
からです。

判断構造を抽象化するという発想

業界横展開できる業務AIは、
・文書を抽象化するのではなく
・判断を抽象化している
という共通点があります。

👉 表現が違うだけで、判断位置は同じ

第4章でやることの位置づけ

ここまでで分かる通り、

・業界固有部分 → RAGに閉じ込める
・業界共通部分 → Agent設計として固定

これが 横展開できる業務AI の前提条件です。

4-2. 業界固有で変わる部分／変わらない部分

第4章の狙いはシンプルです。

「どこを作り替え、どこを固定すればよいか」 を明確にすること

これが曖昧なままでは、
業界が変わるたびに AI システム全体を作り直すことになります。

多くの失敗は「全部まとめて変えようとする」

よくある失敗パターンはこうです。
・業界が変わる
・文書が変わる
・ルールも変わる
👉 だから全体設計も変える

結果として、
・プロンプトが業界ごとに肥大化
・Agent設計が場当たり的
・評価基準が流用できない
という状態になります。

正解は「変わる場所」と「変わらない場所」を切る

業務AIは以下の2層で考えるべきです。

① 業界が変わっても 変わらない部分

これは 設計として固定 すべき領域です。

✅ 判断構造（Agent責務）

・質問タイプ判定
・情報源選択
・回答可否判断
・人へのエスカレーション

👉 これは業界非依存

なぜなら、

どの業界でも
・「答えてよいか／止めるか」の判断は必須
・判断しないAIは業務で使えない

からです。

✅ FAIL分類・評価軸

・推測回答
・文脈逸脱
・混在検索
・横断不可

👉 これも業界に依存しません

「事例の中身」は変わっても、
失敗の型は同じ です。

✅ UIの役割設計（Streamlit / API）

・評価を見る
・失敗を分類する
・改善前後を比較する

👉 画面テーマは変わっても
UIの目的は共通

② 業界ごとに 変わる部分

こちらは 差し替え可能 に設計します。

✅ 質問分類ルールの中身

・分類ラベル自体は共通
・分類条件（キーワード・例）は業界依存

例
・不動産：「重要事項」「特約」
・金融：「元本」「利回り」

👉 枠は同じ、中身を入れ替える

✅ 人の役割（責任所在）

・誰にエスカレーションするか
・どの部門が最終判断か

👉 組織構造に依存

まとめるとこうなる

■ 固定すべきもの（テンプレ化）
・Agent責務構造
・判断フロー
・FAIL分類
・評価方法
・UIの役割

■ 差し替えるもの（業界依存）
・文書
・ルール
・用語
・組織

ここが“横展開できるAI”の分かれ道

業務AIが横展開できない理由の多くは、
・知識（RAG）を中心に設計している
・判断をテンプレ化していない
ことにあります。

RAGを差し替えるだけで使えるそれを可能にするのがAgent判断設計の共通化

次は、この分離を前提に、 実際にどうやって「テンプレ構成」に落とすかを具体化します。

4-3. 他業界展開テンプレ構成（Agent／RAG／UI）

前節までで、

○業界が変わっても
　　・判断構造は共通
　　・失敗の型も共通

○変わるのは
　　・文書
　　・ルール
　　・用語
であることを確認しました。

本節ではそれを受けて、
「業界が変わった時、実際に何を用意すれば動くのか」
を テンプレ構成 として明確にします。

他業界展開の基本思想

業務AIを横展開するための原則は1つです。
Agentは固定、RAGは差し替え、UIは共通
これを崩すと横展開は失敗します。

① Agentテンプレ（業界共通）

Agentは 判断専門 です。
Agentが持つもの
・判断フロー
・質問分類ラベル
・FAIL防止ルール
・Tool選択ロジック

✅ 文書は持たない
✅ 知識は持たない

Agentテンプレ定義例（概念）

質問タイプ：
・参照質問
・解釈質問
・判断要求
・業務外質問

行動：
・RAG呼び出し
・拒否
・人に回す
NG条件：
・根拠不足
・文書不一致
・複数RAG横断要求

👉 業界が変わっても この骨格は不変

② RAGテンプレ（業界差し替え）
RAGは 知識の容器 です。
業界ごとに変わるもの

RAGの原則

・判断しない
・拒否しない
・与えられた条件で検索・生成するだけ

これは 設計上の制限 であり欠陥ではありません。

③ UIテンプレ（共通）

UIは 運用と評価のための装置 です。

教材でも実務でも共通
・入力欄（質問）
・実行ログ表示
・Agent判断の可視化
・FAIL分類結果表示

👉 AgentとRAGは UIに依存しない

業界追加時にやるべきこと（チェックリスト）

✅ やること
１、対象業界の文書収集
２、RAG作成（Embedding / Vector DB）
３、filterルール定義
４、質問例を少量追加

❌ やらないこと
・Agent判断ルールを書き換える
・プロンプトを業界特化で肥大化させる
・FAIL定義を変える

横展開テンプレの価値

この構成にすると：
・新業界立ち上げが速い
・失敗が予測できる
・教育・評価が共通化できる

つまり、

「AI導入」ではなく 「設計資産の展開」になる

第4章まとめ

・横展開できるAIの正体はAgent設計の再利用
・RAGは交換部品
・UIは評価装置

変える場所を間違えない設計が重要

第5章：導入・運用・評価の実務設計

― 業務AIは「作って終わり」ではない ―

なぜ「導入後」が一番重要なのか

第1章から第4章までで、
私たちは以下を整理してきました。

・RAG単体では業務AIにならない理由
・Agentによる判断責務の切り出し
・業務フローに基づいた設計方法
・他業界へ横展開できるテンプレ構造

ここまで来ると、多くの人がこう思います。

「これで業務AIは完成したのでは？」

結論から言うと、ここからが本番です。

現場で多く見かける失敗は、
性能不足でも モデル選定ミスでもありません。

失敗の本質は次の3つです。

・作ったAIが どう評価されるか決まっていない
・FAILが 改善につながる設計になっていない
・運用の中で 人とAIの役割が崩れていく

つまり、

AIの「使われ方」と「育て方」が設計されていない

これが最大の原因です。

第5章で扱うのは、
アルゴリズムでも、ライブラリでもありません。

扱うテーマは以下です。

・どうやって導入するか
・どうFAILを検知するか
・どう改善判断をするか
・どこまでをAIに任せ、どこで人が止めるか
言い換えると、

「AIを業務に責任を持って組み込む方法」

です。

本章では、業務AIを以下の循環構造として整理します。

設計
↓
導入（業務に組み込む）
↓
利用（質問・判断・回答）
↓
FAIL検知（分類・可視化）
↓
改善判断（人が行う）
↓
再設計・再評価

重要なのは、
・FAILは「異常」ではない
・FAILは「改善の入口」である
という考え方です。

多くのAI導入では、
・accuracy
・正答率
・モデル性能
だけが評価されます。
しかし業務AIで重要なのは、

・止めるべき質問を止められたか
・推測回答を防げたか
・責任の所在が明確か
・改善判断を人ができる状態か
つまり、

正解率より「事故率」をどう下げるか

が評価の中心になります。

本章では、以下を順に整理します。
・導入フェーズで決めるべきこと
・FAIL分類 × 評価指標の設計
・「FAIL → 改善 → 再評価」の運用ループ
・Streamlit / FastAPI を使った可視化例
・人が判断すべきポイントの明確化
この章を読み終えたとき、
読者が持ち帰れる状態は次の通りです。

「このAIは、現場で運用しても大丈夫か？」
を自分で判断できる

・第1〜4章：作り方の設計
・第5章：使い続けるための設計

業務AIはプロジェクトではなく、
業務の一部として存在し続けます。

そのために必要なのが、
この第5章です。

5-2-1. FAIL分類 × 評価指標マトリクス

この章の目的は 「失敗を感覚で語らない」 ことにあります。

・「なんか変だった」
・「精度が悪い気がする」

では、業務AIは改善できません。

👉 FAILを「型」として定義し、 どこで・誰が・止められるかを評価可能にする そのための設計が本マトリクスです。

FAIL分類 × 評価指標マトリクス

5-2-2. 各評価指標の「業務AI的」定義

✅ 正答

・文書根拠あり
・質問意図と一致
・業務ルール逸脱なし

📌 「それっぽい」ではなく「根拠がある」

✅ 推測回答（要注意）

・文書に明確な記載なし
・LLMの常識・慣習補完
・見た目は自然で危険度が高い

📌 最も業務事故につながる

✅ 逸脱回答

・検索対象・業務範囲を逸脱
・本来答えてはいけないことを回答

📌 「答えたこと自体がNG」

✅ 正拒否（重要）

・文書不存在・権限外・判断不能
・答えない判断ができた状態

📌 業務AIとしては成功

5-2-3.FAIL別に「どこで止めるべきか」

ここまでで本教材では、

・FAILを感覚ではなく「分類」として定義し
・それぞれを「評価指標」で判定できる状態にし
・どのFAILを、誰が止めるべきかを明確にした

つまり、 「評価可能な業務AI設計」 がここで初めて成立しました。

しかし、 評価軸を持つだけでは業務は回りません。

次に必要になるのは、

・FAILをどう検知し
・どの設計を直し
・どう再評価して収束させるか

という 運用の設計 です。

👉 次節 5-3 では、 「FAIL → 改善 → 再評価」 を一連のループとして回す 実務向け改善フロー を図解で整理します。

5-3：FAIL → 改善 → 再評価

この図は、業務AIにおける典型的な失敗（FAIL）がどのように改善されるかを、Before／After の比較で整理したものです。左側の「Before」では、RAG単体に判断を任せてしまった結果、混在検索、推測回答、横断不可などの問題が発生している状態を示します。RAGは本来「検索 → 回答生成」に特化した仕組みであり、業務判断や回答の是非を制御する責務を持ちません。このため、正しい文書を選べず、根拠のない補完や誤解釈が起きる構造的弱点を抱えています。

一方、右側の「After」では、Agentを導入し、判断を明確に分離することで問題が解消される流れを表しています。

まず Agent が質問意図や文書種別を判定し、適切な Tool（RAGユニット）を選択。さらに top-k や filter など検索条件を制御し、回答可否の判断も Agent が担います。RAG は知識参照の役割に徹するため、混在検索や推測回答が発生しにくくなります。最終的に業務判断の責任は人が保持する構造とすることで、安全性と精度の両立が可能になります。

終わりに

本記事では、RAG の実装から Agent 設計、評価・運用に至るまで、業務AIとして成立させるための“設計”という視点から体系的に整理しました。
AIは性能ではなく構造で成果が決まります。
業務フローの理解、責務の分離、FAILの把握と改善、そして運用サイクルまでを一貫して設計することで、現場で本当に使える業務AIが実現できます。

皆さまの現場で、この教材が役に立ち、より良いAI活用につながれば幸いです。

sampleコードはGitHubにあります。
https://github.com/xyzyuji/realestate.git