生成AI基礎講座 第2回：Transformerの次に理解すべき3つの実務キーワード
本記事で得られる3つのポイント
- RAGが、生成AIに外部知識を参照させる仕組みであることが分かる。
- MoEが、大規模AIを効率よく動かすためのモデル設計であることが分かる。
- AIエージェントが、単なるチャットAIから業務実行型AIへ進む流れであることが分かる。
なぜ重要か
2026年の生成AI活用では、単にChatGPTやClaudeに質問するだけでは不十分です。
RAG、MoE、AIエージェントを理解すると、業務導入、コンテンツ制作、社内ナレッジ活用、自動化支援の設計力が大きく変わります。
続きを読む：※公開時に記事URLを設定
Transformerだけでは、現在の生成AI活用は説明できない
生成AIは「モデル単体」から「仕組みの組み合わせ」へ進んだ
前回の記事では、TransformerとAttentionが現在の生成AI・大規模言語モデルの基盤になったことを整理しました。
Transformerは、文章、画像、音声、動画などの情報同士の関係性を扱うための重要な構造です。
しかし、2026年現在の生成AI活用は、Transformerだけを理解していれば十分という段階ではありません。
現在のAIシステムは、主に次のような技術を組み合わせて構成されています。
| 技術 | 役割 |
|---|---|
| Transformer | 文章・画像・音声などの文脈や関係性を処理する基盤 |
| RAG | 外部文書やデータベースを検索して回答に反映する仕組み |
| MoE | 必要な専門部分だけを使い、巨大モデルを効率よく動かす設計 |
| AIエージェント | AIが外部ツールを使い、業務タスクを実行する仕組み |
| AIガバナンス | 安全性、権限、監査、説明責任を管理する枠組み |
つまり、現在の生成AIは「一つの賢いモデル」ではなく、モデル、検索、ツール、データ、権限管理を組み合わせた業務システムへ変化しています。
本記事では、その中でも特に重要な RAG、MoE、AIエージェント を整理します。
RAGとは何か
RAGは、AIに外部資料を参照させる仕組み
RAGは、Retrieval-Augmented Generation の略です。
日本語では「検索拡張生成」と訳されることが多い技術です。
簡単に言えば、RAGとは、AIが回答を生成する前に、外部文書やデータベースを検索し、その情報をもとに回答する仕組みです。
通常の大規模言語モデルは、学習時点までの知識を内部に持っています。
しかし、その内部知識には限界があります。
| 通常のLLMの課題 | 内容 |
|---|---|
| 最新情報に弱い | 学習後に発生した情報は知らない |
| 社内資料を知らない | 社内マニュアル、議事録、仕様書は学習されていない |
| 出典を明示しにくい | どの情報を根拠にしたか分かりにくい |
| ハルシネーションが起きる | 事実ではない内容を自然な文章で出すことがある |
RAGは、この課題を補うために使われます。
代表的なRAG論文である “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” では、事前学習済みモデルの内部知識と、検索可能な外部文書インデックスを組み合わせる考え方が示されました。論文では、RAGモデルが知識集約型タスクにおいて、より具体的で多様かつ事実性の高い文章を生成できることが報告されています。
参照URL：
https://arxiv.org/abs/2005.11401
RAGの基本構造
RAGの流れは、次のように整理できます。
ユーザーの質問
↓
関連文書を検索
↓
検索結果をAIに渡す
↓
AIが文書を参照して回答を生成
↓
出典付きで回答たとえば、社内FAQでRAGを使う場合は、次のような流れになります。
社員：
「経費精算の締切はいつですか？」
↓
社内規程・経費精算マニュアルを検索
↓
AI：
「毎月25日締切です。詳細は経費精算マニュアル第3章を確認してください。」このようにRAGは、AIを「物知りな文章生成装置」から、資料を確認しながら回答する業務支援ツールへ近づけます。
RAGが実務で効く領域
RAGは、特に次のような業務に向いています。
| 業務 | RAGの活用例 |
|---|---|
| 社内FAQ | 就業規則、経費精算、IT手順書を検索して回答 |
| 顧客対応 | 製品マニュアル、過去問い合わせ、契約条件を参照 |
| 営業支援 | 商品資料、提案書、価格表を参照して回答案を作成 |
| 技術サポート | 障害対応手順、ログ解析手順、ナレッジベースを検索 |
| 法務・規制調査 | 法令、ガイドライン、契約書の該当箇所を抽出 |
| ブログ・レポート制作 | 公式資料、論文、ニュースを参照して記事化 |
個人事業主や小規模企業にとっても、RAGは実用性が高い技術です。
理由は、既存の文書、記事、PDF、マニュアル、議事録をAI活用の資産に変えられるからです。
RAGの注意点
ただし、RAGを使えば自動的に正確になるわけではありません。
| 課題 | 内容 |
|---|---|
| 検索漏れ | 正しい文書が検索されなければ、回答も不正確になる |
| 文書品質依存 | 元の資料が古い・曖昧・矛盾していると回答も崩れる |
| 権限管理 | 見てはいけない文書をAIが参照するリスクがある |
| 出典の誤用 | 検索結果をAIが正しく解釈しない場合がある |
| 更新管理 | 文書が更新されてもインデックスが古いままだと危険 |
特に企業導入では、RAGそのものよりも、文書整理、権限設計、更新フロー、回答検証が重要です。
RAGの導入は、AI導入であると同時に、社内ナレッジ整理のプロジェクトでもあります。
MoEとは何か
MoEは、巨大AIを効率よく使うための仕組み
MoEは、Mixture of Experts の略です。
日本語では「専門家混合モデル」と訳されることがあります。
MoEの基本的な考え方は、巨大なモデルの中に複数の専門家、つまりExpertを用意し、入力内容に応じて必要なExpertだけを使うというものです。
人間の組織でたとえると分かりやすいです。
すべての相談を一人の万能社員に処理させるのではなく、法律の話は法務、経理の話は経理、ITの話は情報システム、営業の話は営業企画に回す。
これに近い考え方がMoEです。
入力内容
↓
ルーターが判断
↓
必要なExpertだけを呼び出す
↓
回答生成Denseモデルとの違い
従来の多くのLLMは、Denseモデルと呼ばれます。
Denseモデルでは、基本的にモデル全体のパラメータを使って処理します。
一方、MoEモデルでは、総パラメータ数は非常に大きくても、実際に1回の推論で使うパラメータは一部に限定されます。
| モデル構造 | 特徴 |
|---|---|
| Denseモデル | 全体を使って処理する。安定しやすいが計算コストが大きい |
| MoEモデル | 必要なExpertだけを使う。効率化しやすいが制御が難しい |
たとえばDeepSeek-V3の技術報告では、総パラメータ671Bに対し、各トークンで活性化されるパラメータは37Bとされています。これは、非常に大きなモデル能力を持ちながら、推論時には一部のExpertだけを使う設計です。
参照URL：
https://arxiv.org/abs/2412.19437
また、Qwen3の技術報告では、DenseモデルとMoEモデルの両方が展開され、0.6Bから235B規模までのモデル群が示されています。これは、利用目的や計算資源に応じてモデルを選ぶ流れが強くなっていることを示しています。
参照URL：
https://arxiv.org/abs/2505.09388
なぜMoEが重要なのか
MoEが重要な理由は、AIの大規模化に伴うコスト問題がより深刻になっているからです。
単純にモデルを大きくすれば性能が上がる時代は、完全には終わっていません。
しかし、巨大化には明確なコストがあります。
| コスト | 内容 |
|---|---|
| 学習コスト | GPU、電力、時間、データセンター費用が増える |
| 推論コスト | 1回の回答生成にかかる計算量が増える |
| レイテンシ | 応答速度が遅くなる可能性がある |
| 運用費 | API利用料、サーバー費用が増える |
| 環境負荷 | 電力消費、冷却、データセンター負荷が増える |
MoEは、この問題に対する一つの回答です。
すべてを常に全力で動かすのではなく、必要な部分だけを使う。
この設計は、今後のAI利用料金、ローカルAI、企業内AI導入にも影響します。
MoEの注意点
MoEにも課題があります。
| 課題 | 内容 |
|---|---|
| ルーティングの難しさ | どのExpertを使うかの判断が重要 |
| 負荷分散 | 一部のExpertに処理が集中すると効率が落ちる |
| 品質のばらつき | 入力によって性能が変動する可能性がある |
| 実装複雑性 | Denseモデルより設計・運用が難しい |
| 説明性 | どのExpertがなぜ使われたかを説明しにくい場合がある |
MoEは、一般利用者が日常的に直接操作する技術ではありません。
しかし、モデル選定やコスト比較をする際には、理解しておく価値があります。
特に今後は、「大きいモデルだから高性能」と単純に判断するのではなく、実際に活性化されるパラメータ、推論コスト、用途適合性を見る必要があります。
AIエージェントとは何か
AIエージェントは、回答するだけでなく行動するAI
AIエージェントとは、AIが単に文章を返すだけでなく、外部ツールやサービスを使って、一定の目的に向けて作業を進める仕組みです。
従来のチャットAIは、基本的には次のような使い方でした。
人間が質問する
↓
AIが回答する
↓
人間が実行するAIエージェントでは、この流れが変わります。
人間が目的を伝える
↓
AIが手順を考える
↓
必要なツールを使う
↓
途中結果を確認する
↓
成果物を作る
↓
必要に応じて人間が承認するつまりAIエージェントは、回答生成AIから 業務実行AI への進化です。
ReActが示した「考える」と「行動する」の組み合わせ
AIエージェントの考え方を理解するうえで重要な研究の一つが、ReActです。
ReActは、Reasoning、つまり推論と、Acting、つまり行動を組み合わせる考え方です。
ReActの論文では、LLMが推論過程とタスク固有の行動を交互に生成することで、外部情報源や環境とやり取りしながらタスクを進められることが示されました。さらに、Wikipedia APIを使った質問応答や事実検証において、ハルシネーションやエラー伝播を抑えられる可能性も示されています。
参照URL：
https://arxiv.org/abs/2210.03629
これは、現在のAIエージェントの基本思想に近いものです。
AIが自分だけで答えを作るのではなく、必要に応じて外部ツールを使い、情報を確認しながら作業する。
この方向性が、現在の生成AIサービスやAPIに広がっています。
2026年現在のAIエージェント動向
OpenAI：Responses APIとエージェント構築ツール
OpenAIは2025年3月に、Responses API、Web search、File search、Computer use、Agents SDKなど、エージェント構築向けのツール群を発表しました。Responses APIは、OpenAIモデルと組み込みツールを組み合わせてagentic applicationsを構築するための基盤として説明されています。
参照URL：
https://openai.com/index/new-tools-for-building-agents/
また、OpenAIはその後、Responses APIにremote MCP server supportを追加しています。MCPは、アプリケーションがLLMにコンテキストを提供する方法を標準化するオープンプロトコルとして説明されています。
参照URL：
https://openai.com/index/new-tools-and-features-in-the-responses-api/
Anthropic：MCPによる外部データ・ツール接続
Anthropicは2024年11月に、Model Context Protocol、MCPを発表しました。
MCPは、AIシステムとデータソースを接続するためのオープン標準として説明されており、AIアプリケーションと外部データ・ツールの接続を標準化する動きとして重要です。
参照URL：
https://www.anthropic.com/news/model-context-protocol
MCPの仕様書でも、LLMアプリケーションと外部データソース・ツールを統合するための標準化された方法としてMCPが説明されています。
参照URL：
https://modelcontextprotocol.io/specification/2025-11-25
Google Cloud：Gemini Enterpriseとエージェント基盤
Google CloudのGemini Enterpriseは、企業向けのagentic platformとして、従業員がAIエージェントを発見・作成・共有・実行できる安全な環境を提供するものとして説明されています。
参照URL：
https://cloud.google.com/gemini-enterprise
また、Google CloudのGemini Enterpriseリリースノートでは、2026年6月25日にAgent RegistryからA2A agentsやMCP serversを追加でき、Agent Gatewayのegress policiesで許可・拒否制御を設定できる機能が記載されています。これは、AIエージェントが業務利用される際に、ガバナンスと接続制御が重要になっていることを示しています。
参照URL：
https://docs.cloud.google.com/gemini/enterprise/docs/release-notes
AIエージェントの実務例
AIエージェントは、次のような業務で使われ始めています。
| 業務 | AIエージェントの役割 |
|---|---|
| 調査業務 | Web検索、資料収集、要約、比較表作成 |
| カスタマーサポート | FAQ検索、回答案作成、チケット分類 |
| 営業支援 | 顧客情報整理、メール案作成、CRM更新 |
| ソフトウェア開発 | コード修正、バグ調査、Pull Request作成 |
| 経理・総務 | 書類確認、申請内容チェック、手続き案内 |
| コンテンツ制作 | 記事構成、素材整理、公開前チェック |
| 社内ナレッジ | 文書検索、要約、関連資料提示 |
ただし、AIエージェントは「完全自動化」と考えると危険です。
実務では、まず 人間承認付きの半自動化 から始めるべきです。
RAG・MoE・AIエージェントの関係
3つは別々の技術だが、実務では組み合わせて使う
RAG、MoE、AIエージェントは、それぞれ別の概念です。
しかし実務では、これらは組み合わせて使われます。
MoEなどで効率化された大規模モデル
↓
RAGで社内文書や外部資料を参照
↓
AIエージェントがツールを使って業務を実行
↓
人間が確認・承認
↓
成果物として出力たとえば、中小企業向けのAI問い合わせ対応システムを考えると、次のようになります。
| 要素 | 役割 |
|---|---|
| LLM | 顧客の質問を理解し、回答文を生成 |
| RAG | 商品マニュアル、FAQ、契約条件を検索 |
| エージェント | チケット登録、担当者振り分け、CRM更新 |
| ガバナンス | 顧客情報の権限管理、ログ記録、誤回答防止 |
| 人間 | 最終確認、例外対応、品質改善 |
この構造を理解すると、生成AI導入を「どのモデルを使うか」だけで考えなくなります。
重要なのは、どの情報を参照させ、どの作業を任せ、どこで人間が確認するかです。
2026年の実務導入で見るべきポイント
1. まずRAGから始める
小規模事業者や中小企業がAI活用を始めるなら、最初に検討すべきはRAGです。
理由は明確です。
- 既存資料を活用できる
- 効果が分かりやすい
- 完全自動化しなくても使える
- 社内FAQや問い合わせ対応に展開しやすい
- AIの回答根拠を示しやすい
特に、以下のような資料がある場合はRAG向きです。
| 資料 | 活用例 |
|---|---|
| 社内マニュアル | 社員向けFAQ |
| 製品資料 | 顧客問い合わせ対応 |
| 過去記事 | ブログ再構成、内部リンク設計 |
| 議事録 | プロジェクト履歴検索 |
| 規程類 | 総務・人事・経理の問い合わせ対応 |
| 技術文書 | サポート対応、教育資料 |
2. MoEはモデル選定の判断材料として見る
MoEは、ユーザーが直接操作するものではありません。
しかし、AIモデル比較では重要な判断材料になります。
今後、AIモデルを比較するときは、次の観点を見るべきです。
| 観点 | 確認内容 |
|---|---|
| DenseかMoEか | 構造の違い |
| 総パラメータ | モデル全体の規模 |
| 活性化パラメータ | 実際に推論で使う規模 |
| 推論速度 | 実務での応答性 |
| API料金 | 継続利用コスト |
| 日本語性能 | 国内業務への適合性 |
| 商用利用条件 | 事業利用できるか |
| データ取り扱い | 入力データが学習に使われるか |
大切なのは、カタログスペックだけで判断しないことです。
実務では、自分の業務データで試す評価が必要です。
3. AIエージェントは段階導入する
AIエージェントは便利ですが、導入順序を間違えると危険です。
推奨する導入段階は、以下です。
| 段階 | 内容 |
|---|---|
| レベル1 | AIが回答案を作る。人間が実行する |
| レベル2 | AIが資料を検索・要約する。人間が確認する |
| レベル3 | AIが下書き・入力案を作る。人間が承認する |
| レベル4 | AIが一部ツールを実行する。ログを残す |
| レベル5 | AIが定型業務を自動実行する。例外時は人間へ戻す |
最初からレベル5を目指すべきではありません。
特に顧客対応、金銭処理、法務、人事、医療、セキュリティ関連では、AIに直接実行権限を与える前に、必ず承認プロセスとログ管理を設計する必要があります。
リスク管理の入口
RAG・MoE・AIエージェントには、それぞれ異なるリスクがある
生成AI活用では、便利さだけでなくリスクも見なければなりません。
| 技術 | 主なリスク |
|---|---|
| RAG | 誤検索、古い文書参照、権限外文書の参照 |
| MoE | 品質ばらつき、説明性、ルーティングの不透明性 |
| AIエージェント | 誤操作、過剰権限、情報漏洩、プロンプトインジェクション |
| MCP・外部ツール連携 | 接続先管理、ツール権限、サプライチェーンリスク |
| 業務自動化 | 誰が責任を持つか不明確になるリスク |
NISTはAI Risk Management Framework、AI RMFを公開しており、AI製品・サービス・システムに信頼性の観点を組み込むための枠組みとして説明しています。また、NIST AI 600-1は生成AI向けのプロファイルであり、生成AI特有のリスクを特定し、Govern、Map、Measure、Manageの観点から行動を整理する資料です。
参照URL：
https://www.nist.gov/itl/ai-risk-management-framework
NIST AI 600-1 PDF：
https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
この領域は、次回の記事で扱う AIガバナンス に直結します。
個人・小規模事業者はどう活用するべきか
まずは「AIリサーチ」と「コンテンツ制作」に組み込む
個人事業主や小規模事業者が、いきなり大規模なAIエージェントシステムを作る必要はありません。
まずは、次の3つから始めるのが現実的です。
| 優先度 | 活用領域 | 実行内容 |
|---|---|---|
| 1 | AIリサーチ | 公式資料、論文、ニュースを収集・整理 |
| 2 | コンテンツ制作 | ブログ、YouTube概要欄、比較表、教材化 |
| 3 | 業務テンプレート化 | 議事録、FAQ、問い合わせ対応、調査手順書 |
この段階では、RAGの考え方を使って、情報源を明確にしながら記事やレポートを作るだけでも十分に価値があります。
たとえば、次のような流れです。
- テーマを決める
- 一次情報を集める
- AIに要約させる
- 人間が事実確認する
- 比較表に整理する
- 記事化する
- 参照URLを明記する
- 更新履歴を残す
これは、RAGの考え方を人間の編集プロセスに組み込んだ形です。
専用システムを作らなくても、十分に実務価値があります。
収益化につなげるなら「導入支援」より先に「整理力」を見せる
AI活用支援で収益化する場合、いきなり「御社にAIエージェントを導入します」と言っても信用されにくいです。
最初に見せるべきは、次のような成果物です。
| 成果物 | 目的 |
|---|---|
| AI技術解説記事 | 専門性の可視化 |
| AIモデル比較表 | 判断材料の提供 |
| 業務別AI活用テンプレート | 実務支援力の証明 |
| 無料PDF | リード獲得 |
| 有料レポート | 低単価商品の販売 |
| 個別診断 | 高単価支援への入口 |
つまり、最初に売るべきものは「AI導入そのもの」ではなく、AI活用を判断するための整理された情報です。
この方が、倫理的にも堅実です。
相手に不要な自動化を売るのではなく、まず何が必要かを判断できる材料を提供する。
これが、信頼を損なわないAIビジネスの入口になります。
まとめ：2026年のAI活用は「検索・効率化・実行」の組み合わせで考える
RAG、MoE、AIエージェントは、現在の生成AI活用を理解するうえで重要な3つの技術です。
RAGは、AIに外部資料を参照させる仕組みです。
これにより、社内文書、公式資料、論文、マニュアル、FAQなどを活用しながら、より根拠のある回答を作れるようになります。
MoEは、巨大AIを効率よく動かすための設計です。
すべてのパラメータを常に使うのではなく、入力に応じて必要なExpertだけを使うことで、大規模モデルの性能とコスト効率を両立しようとする流れです。
AIエージェントは、AIが外部ツールを使い、調査、入力、検索、コード修正、問い合わせ対応などの業務を進める仕組みです。
ただし、完全自動化を急ぐのではなく、人間承認付きの段階導入が現実的です。
2026年のAI活用では、次の視点が重要になります。
- RAGで、AIに参照させる情報を設計する。
- MoEで、モデル性能とコスト効率の見方を理解する。
- AIエージェントで、どこまで業務を任せるかを設計する。
- AIガバナンスで、権限・ログ・責任・安全性を管理する。
- 人間が、最終判断と品質管理を担う。
結論として、現在の生成AIは「質問すれば答えてくれる道具」から、情報を探し、判断を補助し、ツールを使って業務を進める基盤へ移行しています。
ただし、その価値を引き出すには、AIの性能だけでなく、業務設計、情報管理、権限設計、人間の確認プロセスが必要です。
AI活用の本質は、AIにすべてを任せることではありません。
AIに任せる部分と、人間が責任を持つ部分を切り分けることです。
参照URL
Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
https://arxiv.org/abs/2005.11401
DeepSeek-V3 Technical Report
https://arxiv.org/abs/2412.19437
Qwen3 Technical Report
https://arxiv.org/abs/2505.09388
ReAct: Synergizing Reasoning and Acting in Language Models
https://arxiv.org/abs/2210.03629
OpenAI: New tools for building agents
https://openai.com/index/new-tools-for-building-agents/
OpenAI: New tools and features in the Responses API
https://openai.com/index/new-tools-and-features-in-the-responses-api/
Anthropic: Introducing the Model Context Protocol
https://www.anthropic.com/news/model-context-protocol
Model Context Protocol Specification
https://modelcontextprotocol.io/specification/2025-11-25
Google Cloud: Gemini Enterprise
https://cloud.google.com/gemini-enterprise
Google Cloud: Gemini Enterprise release notes
https://docs.cloud.google.com/gemini/enterprise/docs/release-notes
NIST AI Risk Management Framework
https://www.nist.gov/itl/ai-risk-management-framework
NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf