AIエージェント開発／運用入門 生成AI深掘りガイド 読んでみた

AIエージェント開発／運用入門　生成AI深掘りガイドを読んでみた

深掘りしながら読んでるので実際の書籍ではシンプルな著述になっています。
気になる方はぜひ購入してみてください。

第1章　LLMエージェントの基本

簡単にいうとLLMエージェントは、ユーザーの代わりに自律的にタスクを実行するAI

タスク自動化

LLMエージェントは、以下のような業務を自動で実行できます。

• 情報処理

  • 情報収集 → 要約 → レポート作成
  • CSVデータの加工・分析

• 業務オペレーション

  • メール送信
  • スケジュール調整

• 開発支援

  • テスト仕様書の作成
  • コード修正・改善提案

意思決定支援

• 複数の選択肢の比較・評価
• リスク分析
• シミュレーション結果の提示

業務フローの実行

• 単発作業だけでなく、業務フロー全体を一貫して担当できます。

マルチエージェント協調

LLMエージェントは1体で動かすだけでなく、専門分野ごとに役割分担した複数エージェントで構成。

担当エージェント	役割
企画AI	要件整理・構想
調査AI	技術・競合リサーチ
開発AI	コード実装
テストAI	バグ検知・QA
管理AI	タスク進捗管理

CoT（Chain of Thought：思考の連鎖）

大規模言語モデルの特性

• 一発回答
  → 曖昧・間違いやすい

• 多段思考
  → 正確で根拠のある回答になりやすい

複雑な推論や計算問題では、「思考の途中経過」を内部的に活用させることで精度が向上することが分かっている

CoTが有効な領域

• 数学の文章題
• 複雑な条件分岐を含む問題
• 論理パズル
• 設計問題
• トラブルシューティング

CoTの限界

• 思考のハルシネーション

  • CoTの文章自体は「説明生成」であり、実際の内部推論と一致しない場合がある

• 完全正解は保証されない

  • 手順を書かせても推論がズレることがある

• トークンコスト

  • 詳細なCoTはレスポンスが長くなり、API費用が増加する

ReAct（Reason + Act）

ReActとは、Chain of Thought（思考）を実際の「行動」と結びつけるAI設計パターン

推論（考える）と行動（実行）をループで繰り返す

Thought（考える）
↓
Action（ツール実行）
↓
Observation（結果取得）
↓
Thought（再考）
↓
Action（次の実行）
…
↓
Answer（最終出力）

なぜReActが必要なのか

CoT単体の限界

• 知識が正しいか確認できない
• 憶測や作話（ハルシネーション）をしやすい
• 「調べる」「操作する」といった実務行動ができない

ReActによる解決

「考える → 調べる → 判断し直す」を繰り返す

• 必要ならWeb検索
• DB照会
• 計算プログラム実行
• API呼び出し
  これにより、事実検証と実行を伴った推論が可能になる

CoTとReActの比較

項目	CoT	ReAct
目的	正しく考える	正しく実行する
構造	思考の連鎖のみ	思考＋行動のループ
外部ツール使用	なし	あり
実務対応力	弱い	非常に強い
ハルシネーション耐性	低い	高い（検証込み）

ReActとAIエージェント

ReActは、現代AIエージェント設計における代表的かつ影響力の大きいアーキテクチャの一つ

多くのエージェントは以下を組み合わせています。

Plan → Execute → Observe → Reflect

Toolformer / Function Calling / Agent Loop
などと 統合的に使われることが多い

Function Calling（Tool Use）

AIエージェントが外部ツールを実行するための仕組みです。

MCP（Model Context Protocol）

Anthropicが発表したAIエージェントと外部リソース（ツール・データ・サービス）の接続仕様

MCPが標準化するもの

• コンテキストの受け渡し
  • ユーザー情報
  • 会話履歴
  • 状態（state）
  • 外部データ
• ツールの定義方法
  • どんなツールがあるか
  • どう呼び出すか
  • 引数・戻り値の型
• セキュリティ境界
  • モデルが「何をしていいか」
  • ツールが「何をさせるか」

MCPとFunction Callingの違い

項目	Function Calling	MCP
スコープ	単一モデル内	システム全体
標準化	モデル依存	プロトコルとして独立
セキュリティ	弱い※1	明示的
再利用性	低い	高い
エージェント向き	△	◎

※1 Function Callingも設計次第で担保可能
※MCPは「組織・チーム間再利用」に強い

MCPがもたらす本質的価値

安全性

• モデル側の「やっていいこと」

• ツール側の「やらせていいこと」
  を明示的に分離・宣言できる

  MCPは「完全な安全」を保証するものではなく、安全な設計を強制しやすくするプロトコル

スケーラビリティ

• ツール追加が容易
• 複数エージェントで共有可能
• 組織・チーム・エージェント数が増えても破綻しにくい
• ツールを共通資産として再利用可能

アーキテクチャの明確化

• AIを「システムの一部」として扱えるようにする
• 推論と実行の分離
  • Clean Architecture / Hexagonal に近い構造
    • 推論（LLM）
    • 実行（ツール）
    • 境界（MCP）
      が明確になることで、
    • テストしやすい
    • 置き換えやすい
    • 障害切り分けしやすい

ガバナンス・運用性

• 利用履歴の可視化
• 権限制御・監査対応
• エンタープライズ展開への耐性

ガードレール（Guardrails）

AIが「やってはいけないこと」をしないための制約・保護機構です。

問題	例
権限逸脱	本来触れないDBを読む
意図しない実行	テスト環境で本番APIを叩く
誤操作	メール・Slackの誤送信
セキュリティ事故	個人情報の出力
コスト暴走	無限ループによるAPI連打

RAG（Retrieval-Augmented Generation）

RAGとは、LLMが外部データを検索（Retrieval）してから生成（Generation）する仕組みです。

RAGが解決する課題

• 知識が古い
• ハルシネーションが起きやすい
• 社内情報を知らない
• 情報の根拠が不明確

Retrievalで行っていること

Retrievalとは

ユーザーの質問に対して「関連性の高い外部情報を取り出す処理」です。

• 質問をベクトル化
• ドキュメントをベクトル検索
• 関連度の高い情報を取得
• LLMに渡す

よく使われる技術

• ベクトルDB（FAISS / Pinecone / Weaviate など）
• Embedding
• Top-K検索

RAGの利点

• 必要な情報だけを取得
• トークン削減
• ノイズ低減
• 精度向上

RAGの落とし穴

• 検索精度が低い
  • チャンク分割が雑
  • メタデータ不足
• LLMがコンテキストを無視する
• 情報量過多（Top-K過剰）

有名なAIエージェントツール

• Perplexity
• Manus
• Cursor
• AutoGPT
• OpenAI Operator
• Microsoft Agent 365
• Salesforce Agentfoce 360
• Maisai AI

AIエージェントの活用事例

• A-BOSS：社内コンサルタントエージェント
• キミガタリ：物語創作支援プラットフォーム
• KDDI「議事録パックン」
• 住友化学「ChatSCC」