業務で言われる『AI』の実態 — LLM・RAG・エージェントの動作を図で理解

TL;DR

• LLM が AI 利活用の中核: 業務で「AI を使う」と言うときの実体は、ほぼ大規模言語モデルへの API 呼び出しです。
• RAG で社内知識を補完: LLM 単体は社内情報を知らないため、検索（Vector DB）と組み合わせて回答を作るのが定番構成です。
• エージェントは Tool 呼出しの繰り返し: 「自律的に動く AI」とはループの中で Tool を使い続ける仕組みで、特殊な発明ではありません。
• 業務適用は 4 類型に整理可能: コールセンター・コード生成・社内検索・レポート作成のいずれかに大半が収まります。
• 過信は厳禁: ハルシネーション・コスト・データ漏洩の 3 リスクを前提に、出力検証を必ず挟む運用が必要です。

要点サマリ表

観点	内容
何の話	業務で言われる「AI」の実態を、アーキテクチャ単位で分解
AI の正体	LLM API 呼び出し（多くはクラウド側で稼働）
どこで動いているか	Anthropic / OpenAI / Google / Microsoft 等のクラウドサーバ。社内 PC ではない
業務での効果	一次応対・要約・検索の自動化。判断業務の代替ではない
私の評価	仕組みを知れば過大評価も過小評価も避けられる。ブラックボックス視するのが一番損

背景・経緯

「AI 利活用」という言葉が業務会話で日常的に使われるようになったのは、2022 年末の ChatGPT 公開以降 です。それ以前にも機械学習は需要予測や不正検知で使われていましたが、現場担当者が触れるものではありませんでした。

ChatGPT 以降の変化は、自然言語で AI と対話できるようになった ことです。Excel 関数を覚えるような学習コストなしに、業務担当者が直接 AI を呼び出せるようになりました。これが「AI 利活用」の主役を、データサイエンティストから業務担当者・コンサル・中間管理職に移しました。

ただしここで多くの人が誤解しているのは、「AI = ChatGPT という 1 個の便利アプリ」 という理解です。実際は、ChatGPT も社内 AI チャットも RAG システムも自律エージェントも、ほぼすべてが「LLM API への呼び出し」を中核に持つ別形態 にすぎません。

業務サイドが「AI 利活用」を語るとき、実態として 3 つの構成要素のどれか、または組み合わせを指しています。本記事ではこの 3 要素を順番に分解します。

本題の詳細

AI の正体は LLM — 入力 → 推論 → 出力の本質

業務で「AI に質問する」「AI に書かせる」と言うときの実体は、ほぼすべて LLM（Large Language Model、大規模言語モデル）への API 呼び出し です。LLM は、巨大な文章データから「次に来る単語」を予測する仕組みを大規模に拡張したものです。

仕組みを最小単位で書くと、こうなります:

flowchart LR
U[ユーザー] -->|質問| App[アプリ画面]
App -->|プロンプト| API[LLM API]
API -->|推論結果| App
App -->|回答| U
classDef user fill:#cfe2ff,stroke:#0d6efd,color:#0f172a
classDef app fill:#fff3cd,stroke:#ffc107,color:#0f172a
classDef llm fill:#d1e7dd,stroke:#198754,color:#0f172a
class U user
class App app
class API llm

ここで重要な事実は 2 つあります。1 つ目は、LLM 本体は社内 PC ではなく、Anthropic や OpenAI のクラウドサーバで動いている ということです。質問文はインターネット越しに送信されます（社内データ漏洩の懸念はここに起因します）。

2 つ目は、LLM はあなたの会社のことを何も知らない ことです。学習に使われたのは公開されたインターネット上の情報なので、社内規程・顧客名簿・過去案件の議事録は学習データに入っていません。だから「うちの就業規則では…」と聞いても答えられません。

このときに使われるのが トークン（token、文章を細切れにした単位） と コンテキストウィンドウ（context window、一度に扱える文章の長さ） という概念です。LLM には一度に処理できる文字数の上限があり、それを超える長い社内文書をまるごと渡すことはできません。これが次節の RAG が必要になる根本理由です。

LLM 単体ではない — RAG が知識を補完する

社内文書を AI に答えさせる仕組みが RAG（Retrieval-Augmented Generation、検索拡張生成） です。AWS の説明では「LLM の出力を、訓練データ外の権威ある知識ベースを参照して最適化するプロセス」とされています。IBM も同じく「retrieval（検索）・augmentation（拡張）・generation（生成）」の 3 部構成として定義しています。

図にするとこうなります:

flowchart TD
Q[質問文] --> Emb[Embedding 変換]
Emb --> VDB[(Vector DB)]
VDB --> Ctx[関連文書を抽出]
Ctx --> Prompt[質問+文書をプロンプト化]
Q --> Prompt
Prompt --> LLM[LLM 推論]
LLM --> Ans[出典付き回答]
classDef store fill:#e7d6ff,stroke:#6f42c1,color:#0f172a
classDef llm fill:#d1e7dd,stroke:#198754,color:#0f172a
class VDB store
class LLM llm

仕組みを業務サイド向けに言い換えると、こうなります。質問文を受け取ったら、まず Vector DB（ベクトル検索データベース、「意味で似ている文書を引ける検索エンジン」） から関連しそうな社内文書を抜き出します。次にその文書と元の質問を一つのプロンプトにまとめて LLM に渡し、回答を生成させます。

この方式の利点は 3 つあります。1 つ目は モデルを再訓練しなくても社内知識を反映できる こと。2 つ目は 回答の出典（どの社内文書から引いたか）を提示できる ため、監査や根拠確認が可能になることです。IBM Research も「RAG の回答は引用元文書を指し示せるため、エンタープライズ用途で監査性が確保できる」と指摘しています。3 つ目は ハルシネーション（hallucination、実在しない判例・架空の社内規程番号・誤った数値などを、まるで事実のように出力する現象）の抑制 です。ただし RAG を入れてもハルシネーションが完全に消えるわけではなく、文献によっては数 % から十数 % 程度の誤生成が残存することが知られています。

社内ドキュメント検索・FAQ ボット・ナレッジマネジメントといった業務適用は、ほぼ例外なくこの RAG 構成です。「ChatGPT に社内データを学習させたい」という要望は、技術的には大半が「RAG を組む」という意味になります。

動くだけの AI = エージェント — Tool を使って業務を完結させる

ここまでの LLM・RAG は、いずれも 「質問 → 1 回の応答」で終わる仕組み でした。これに対して AI エージェント（agent） は、ループの中で繰り返し LLM を呼び、必要に応じて外部 Tool を実行しながら、タスク完了まで自律的に動き続ける 仕組みです。

Anthropic は「エージェントは LLM が自身のプロセスとツール利用を動的に方向づけるシステム」と定義し、Oracle 開発者ブログも「LLM Thinks + System Acts + Repeat」というシンプルな構造として説明しています。OpenAI・Anthropic・Google・Microsoft の主要各社が、この 「while ループの中で Tool を呼ぶ」というほぼ同一のパターン に収束しています。

図にするとこうです:

flowchart LR
Start[ユーザー指示] --> Think[LLM が次の手を推論]
Think --> Decide{Tool が必要か}
Decide -->|はい| Call[Tool 呼出し]
Call --> Result[結果取得]
Result --> Think
Decide -->|いいえ・完了| Done[最終回答]
classDef loop fill:#fff3cd,stroke:#ffc107,color:#0f172a
classDef tool fill:#cfe2ff,stroke:#0d6efd,color:#0f172a
class Think,Decide loop
class Call,Result tool

ここで言う Tool（ツール） は、業務サイドの感覚で言えば「AI から呼べる外部サービスの窓口」です。ファイル読み書き・Web 検索・社内 API 呼出し・メール送信など、何でも Tool として登録できます。OpenAI ではこれを Function calling（関数呼出し） と呼び、Anthropic では Tool use と呼びますが、仕組みはほぼ同じです。

業務での具体例を挙げます。「先週の売上レポートをまとめてメールして」と指示したとき、エージェントは内部で次のように動きます。「売上データが必要 → 社内 BI Tool 呼出し → 結果を受け取る → 集計を依頼 → 集計 Tool 呼出し → メール文を作る → メール下書き保存 Tool 呼出し（送信前に人間最終承認）→ 完了報告」。ChatGPT 単体との違いは「行動できる」かどうかに尽きます。

なお本番運用では、外部に作用する Tool（メール送信・課金・物理操作など）を呼ぶ前に人間承認ステップを挟む設計が定石です。

クラシック ML との違い — 何が新しいのか

最後に補助的に触れます。クラシック ML（machine learning、需要予測・スコアリング・不正検知などの機械学習） は今も現役で、業務 AI 利活用の友軍です。違いを業務サイド向けにまとめると次の通りです。

軸	クラシック ML	LLM ベースの生成 AI
入出力	数値・カテゴリのテーブルデータ	自然言語・画像・音声
訓練	業務データで個別訓練	巨大事前訓練 + 必要に応じて RAG / 微調整
主な用途	予測・分類・異常検知	要約・生成・対話・自動化
業務担当者の関与	データサイエンティスト経由	自然言語で直接呼出し可

両者は競合ではなく 使い分け です。需要予測（来月の在庫発注量予測）・不正検知（クレジットカードの異常取引検出）・レコメンド（EC サイトの「あなたへのおすすめ」）といった 数値・パターンを扱う業務 は、今もクラシック ML のほうが正確で、しかも判断根拠を説明しやすいという優位性があります。一方で、文章生成・対話インタフェース・要約・コード補完といった 言語を扱う業務 は、生成 AI が圧倒的です。

ここで業務サイドが陥りがちな失敗は、クラシック ML 領域の業務に生成 AI を投入してしまう ことです。例えば「来月の売上を ChatGPT に予測させる」と数値精度が出ず、過去データと乖離した数字をもっともらしく返してきます。あるいは「決定木で十分なリスクスコアリング」を LLM 推論で代替するとコストが跳ね上がり、説明可能性も失われます。

整理すると、生成 AI は 「言語の処理」、クラシック ML は 「数値・パターンの処理」 が住み分けの基本軸です。両方を組み合わせる構成（例: ML で異常検知 → LLM で対応文を起案）も実務では有効で、競合関係ではなくレイヤーが違うと考えるのが正しい捉え方です。

比較・代替手法（業務利活用パターン）

業務での AI 利活用は、ほとんどの場合次の 4 類型のどれかに収まります。「自社で何の AI を入れるか」の議論は、まずこの表のどの行を狙っているのかを確定させると論点が整理されます。

業種 / 業務	入力	処理（実態）	出力	主な効果
コールセンター（FAQ 応答）	顧客の問い合わせ文	RAG で社内 FAQ・契約情報を検索 → LLM が応対文生成	応対候補文・要約	一次応対の所要時間短縮、新人教育コスト低減
ソフトウェア開発（コード生成）	関数仕様・既存コード断片	LLM が補完候補を生成（テスト実行は Tool 経由）	コード断片・テスト結果	定型コード執筆時間の削減
社内ドキュメント検索（社内 QA）	社員の自然言語質問	RAG が社内 Wiki・規程集を Vector DB 検索 → LLM が要点抜粋	出典付き回答	人事・経理問い合わせの一次自動応答
業務レポート作成（議事録要約）	会議音声・録画	文字起こし → LLM が要約・アクション抽出	構造化レポート	議事録作成時間の大幅短縮

他方、LLM ベースの生成 AI が向かない（または苦手な）業務 も明確に存在します。導入検討時は次のような領域を除外候補として最初に切り分けると、無駄な PoC を避けられます。

• 数値の厳密一致が要求される経理計算・税務処理: LLM は確率的出力なので桁ズレや丸め誤差が混入する可能性があり、決算数値や納税額の自動生成には不向きです。
• 法的最終判断・契約書の最終承認: 責任主体が必要な意思決定はハルシネーションリスクと齟齬し、人間の弁護士・法務担当の代替にはなりません。
• 個人情報・医療情報の外部送信が許容できない処理: データガバナンス観点で、エンタープライズ契約や社内ホスティング型 LLM が前提になります。
• 物理計測が絡む現場作業の自動化: センサー値や物理動作との連携は LLM 単体では完結せず、別系統の制御システムが主役になります。
• 完全な再現性が要求されるバッチ処理: LLM は同じ入力でも出力がブレるため、temperature を下げても 100% 同一出力は保証されません（クラシック ML や決定論的アルゴリズムが向きます）。

実装スタックとしては、上 2 つは LLM + 軽量 RAG、下 2 つは LLM + RAG + Tool（エージェント寄り） が一般的です。「AI で何ができるか」という抽象的な議論よりも、この表のどこを狙うかから入ったほうが意思決定が速くなります。

私の考察

私は、業務サイドの方が「AI 利活用」を語るときに最も損をしているのは、実態をブラックボックスのまま扱うこと だと考えています。仕組みを知れば、過大評価（万能視）も過小評価（ただの検索置換と誤認）も避けられます。本記事の 3 構成要素（LLM・RAG・エージェント）は、技術書 1 冊を読まなくても押さえられる粒度に整理したつもりです。

私が業務サイドの方に推奨したいアクションは 3 つです。1 つ目は 小さく始める こと。いきなり全社エージェント化ではなく、定型業務 1 つ（議事録要約・FAQ 応答など）から始め、効果と落とし穴を体感するほうが学習が速いと考えます。2 つ目は 出力検証を必ず挟む こと。LLM の出力には一定確率でハルシネーションが含まれるため、「最終チェックは人間」という運用設計を最初から組み込むのが安全です。3 つ目は データ漏洩リスクへの自覚 です。社内機密を扱うなら、エンタープライズ契約（API のデータ非学習保証）や社内ホスティング型 LLM の選択肢を技術部門と握ることが必要です。

最後に一言加えると、「AI で仕事がなくなる」議論よりも、「AI を使える人と使えない人で生産性差が広がる」議論のほうが業務サイドにとって現実的 だと私は感じています。仕組みの解像度を上げることは、その差をつくる側に回るための最低限の投資だと考えます。

参考リンク

• Building Effective AI Agents — Anthropic, 2024-12-19
• Function calling | OpenAI API — OpenAI 公式ドキュメント
• What is RAG? - Retrieval-Augmented Generation AI Explained — AWS
• What is Retrieval-Augmented Generation (RAG)? — IBM
• What Is the AI Agent Loop? — Oracle Developers Blog
• AI Agent Orchestration Patterns — Microsoft Learn