# 社内業務を自動化するマルチLLM AIエージェント基盤の設計と実装 URL: https://technosphere.co.jp/de-blog/2026-04-24-multi-llm-ai-agent-architecture ## はじめに：なぜ「AIエージェント基盤」が必要なのか ChatGPTやClaudeを業務に使っている企業は増えていますが、多くは「人がプロンプトを入力して、回答を受け取る」という対話型の使い方にとどまっています。 しかし、**AIが自ら判断し、ツールを使い、複数のステップを自律的に実行する**——いわゆる「AIエージェント」の仕組みを構築すれば、業務自動化の幅は劇的に広がります。 弊社では、社内の定型業務（レポート作成、データ集計、メール対応、調査タスクなど）を自律的に処理するAIエージェント基盤を構築・運用しています。本記事では、その設計思想とアーキテクチャを技術的に解説します。 --- ## システム全体像 ``` ┌──────────────────────────────────────────┐ │ Communication Layer │ │ Slack / API / Web UI │ └────────────────┬─────────────────────────┘ │ ┌────────────────▼─────────────────────────┐ │ Agent Orchestration │ │ タスク分解・スキル実行・メモリ管理 │ └────────────────┬─────────────────────────┘ │ ┌────────────────▼─────────────────────────┐ │ LLM Proxy Layer │ │ Claude / Gemini / Codex │ │ 自動フォールバック・負荷分散 │ └────────────────┬─────────────────────────┘ │ ┌────────────────▼─────────────────────────┐ │ Tool / Skill Layer │ │ Web検索 / ファイル操作 / シェル実行 │ │ メール送信 / ドキュメント生成 │ └──────────────────────────────────────────┘ ``` この4層アーキテクチャにより、**LLMの選定・通信チャネル・実行スキルをそれぞれ独立して変更・拡張**できる設計になっています。 --- ## 設計の3つの柱 ### 1. マルチLLMプロキシ：1つのモデルに依存しない AIエージェントの頭脳であるLLMを1つのモデルに固定すると、以下のリスクがあります。 - **API障害**でエージェント全体が停止する - **コスト変動**で運用費が予測不能になる - **タスクとモデルの相性**（コード生成はCodex、長文要約はGemini等）を活かせない そこで、**OpenAI互換APIを提供するLLMプロキシ層**を設計しました。 ``` リクエスト → LLMプロキシ（ポート8000） → モデル選択（タスクに応じて最適なLLMを自動選択） → フォールバック管理（障害時は次のモデルへ自動切替） → ヘルスチェック（各プロバイダーの稼働状況を追跡） → レスポンス整形（統一フォーマットで返却） ``` #### 対応モデルと使い分け | モデル | 用途 | コンテキスト長 | |--------|------|--------------| | Claude Sonnet | 標準的な推論・業務処理 | 200K | | Claude Opus | 複雑な分析・長文生成 | 200K | | Claude Haiku | 高速応答・単純タスク | 200K | | Gemini Pro | 大規模ドキュメント処理 | 1M | | Gemini Flash | 高速要約 | 1M | | Codex | コード生成特化 | 128K | #### フォールバックの実装 ```javascript // プロバイダーごとの状態管理 const providerState = { 'claude-sonnet': { healthy: true, lastError: null, cooldownUntil: null }, 'gemini-pro': { healthy: true, lastError: null, cooldownUntil: null }, // ... }; async function routeRequest(request) { const providers = selectProviders(request.model); for (const provider of providers) { if (!isAvailable(provider)) continue; try { return await callProvider(provider, request); } catch (error) { // 障害発生 → 5分間クールダウン provider.cooldownUntil = Date.now() + 5 * 60 * 1000; provider.healthy = false; console.log(`${provider.id} failed, falling back...`); } } throw new Error('All providers unavailable'); } ``` **ポイント**: 障害が発生したプロバイダーは5分間のクールダウン期間を設け、回復を待ちます。同時リクエスト数の上限（プロバイダーごとに2リクエスト）も設定し、レートリミットを防止しています。 --- ### 2. スキルシステム：AIが「手足」を持つ LLMは「考える」能力に長けていますが、実際に「行動する」にはツール（スキル）が必要です。 当基盤では、以下のスキルを組み込んでいます。 | スキル | できること | |--------|----------| | Web検索 | インターネット上の情報を検索・取得 | | ファイル操作 | ドキュメントの読み書き・整理 | | シェル実行 | コマンド実行による自動処理 | | コード実行 | Python/JavaScriptのコード実行 | | メール操作 | IMAP/SMTPによるメール送受信 | | ドキュメント生成 | Excel・PDF・プレゼン資料の作成 | | 画像生成 | FLUX/SDXLモデルによる画像生成 | #### スキルの呼び出しフロー ``` ユーザー: 「先月の売上データをまとめてExcelで送って」 AIエージェント: 1. [ファイル操作] NAS上の売上CSVを読み込み 2. [コード実行] Pythonでデータ集計・グラフ生成 3. [ドキュメント生成] Excelファイルを作成 4. [メール操作] 依頼者にExcelを添付して送信 5. [Slack通知] 「送信完了しました」と報告 ``` このように、**1つの依頼に対して複数のスキルを連鎖的に実行**できるのがエージェントの強みです。 --- ### 3. 3層メモリアーキテクチャ：AIが「覚える」仕組み LLMは本質的にステートレス（状態を持たない）です。会話が終われば、文脈は失われます。しかし業務では「先週の会議で決まったこと」「あのプロジェクトの経緯」といった文脈の蓄積が重要です。 そこで、**3層のメモリアーキテクチャ**を設計しました。 ``` ┌─────────────────────────────┐ │ Layer 1: セッションメモリ │ ← 今日の作業ログ │ memory/YYYY-MM-DD.md │ 毎日リセット ├─────────────────────────────┤ │ Layer 2: 長期メモリ │ ← 重要な知識・判断基準 │ MEMORY.md │ 数日おきに更新 ├─────────────────────────────┤ │ Layer 3: 永続ストレージ │ ← ファイル・成果物 │ NAS共有ディレクトリ │ 永続保存 └─────────────────────────────┘ ``` #### セッションメモリ（短期） その日の作業内容をMarkdown形式で記録します。 ```markdown ## 2026-04-24 作業ログ ### 10:05 売上レポート作成依頼（営業部 佐藤さん） - 3月度売上CSVを /nas/sales/ から取得 - 前年同月比を算出、グラフ付きExcel生成 - 佐藤さんにメール送信完了 ### 14:30 サーバー監視アラート対応 - CPU使用率90%超過を検知 - 原因: バッチ処理の並列実行過多 - 対応: cron設定を調整、正常化を確認 ``` #### 長期メモリ（中期） セッションメモリから抽出した「今後も役立つ知識」を蓄積します。 ```markdown ## 業務知識 - 月次売上レポートは毎月5日までに提出（経理部ルール） - サーバーCPU閾値は80%でアラート、対応手順はWikiの「障害対応」参照 - 佐藤さん（営業）はExcel形式を好む、PDF不可 ``` **「書き留める」原則**を徹底し、口頭での申し送りに相当する情報を確実に蓄積しています。 --- ## Docker基盤によるデプロイ エージェント基盤全体をDockerコンテナで構成し、再現性と可搬性を確保しています。 ```yaml # docker-compose.yml（簡略版） services: agent: image: agent-base:latest volumes: - ./workspace:/home/node/workspace - /mnt/nas/shared:/mnt/nas:ro environment: - TZ=Asia/Tokyo - LLM_PROXY_URL=http://llm-proxy:8000/v1 depends_on: - llm-proxy healthcheck: test: ["CMD", "curl", "-f", "http://localhost:18789/health"] interval: 30s timeout: 10s retries: 3 llm-proxy: build: ./services/llm-proxy ports: - "8000:8000" monitor: build: ./services/monitor-api ports: - "8200:8200" ``` ### 運用監視 モニターAPIで各コンポーネントの稼働状況をリアルタイムに把握できます。 - **ヘルスチェック**: 30秒間隔で全サービスの死活監視 - **LLM使用量**: モデルごとのリクエスト数・レスポンス時間を記録 - **エラートラッキング**: フォールバック発生回数・失敗パターンの可視化 --- ## 導入効果 社内で3ヶ月間運用した結果、以下の効果が得られました。 | 業務 | 導入前 | 導入後 | 削減率 | |------|--------|--------|--------| | 月次レポート作成 | 4時間/月 | 30分/月 | 87% | | メール一次対応 | 2時間/日 | 20分/日 | 83% | | 社内問い合わせ対応 | 1.5時間/日 | 15分/日 | 83% | | データ集計・分析 | 3時間/回 | 20分/回 | 89% | 特に**定型的だが手順が多い業務**で大きな効果を発揮しています。 --- ## 構築時に注意すべき3つのポイント ### 1. LLMの幻覚（ハルシネーション）対策 AIエージェントが自律的に行動する以上、誤った情報に基づく行動は大きなリスクです。 **対策：** - **確認ステップの挿入**: 外部送信（メール・Slack投稿）前に人間の承認を挟む - **事実確認スキル**: 社内ドキュメントや公式情報源との照合を必須化 - **行動ログの完全記録**: 全アクションをログに残し、事後検証を可能にする ### 2. セキュリティ境界の設計 エージェントがアクセスできるリソースを明確に制限します。 - **読み取り専用マウント**: 他部署のファイルはread-onlyでマウント - **メモリの非共有**: エージェントの長期メモリは他のコンテキストに漏洩しない設計 - **認証情報の分離**: APIキー等は環境変数で注入し、コード内にハードコードしない ### 3. フォールバック戦略の設計 「AIが動かない」状態を極力防ぐための多重化です。 ``` プライマリ: Claude Sonnet ↓ 障害時 フォールバック1: Gemini Flash ↓ 障害時 フォールバック2: Claude Haiku ↓ 全滅時 人間にエスカレーション（Slack通知） ``` --- ## まとめ 社内AIエージェント基盤の設計と実装について解説しました。 **重要な設計原則：** 1. **マルチLLMプロキシ**で単一障害点を排除し、モデル特性を活かす 2. **スキルシステム**でAIに「行動する手足」を与える 3. **3層メモリ**で文脈を蓄積し、業務品質を継続的に向上させる 4. **Docker基盤**で再現性・可搬性・監視性を確保する テクノスフィアでは、こうしたAIエージェント基盤の設計・構築支援も行っています。社内業務のAI自動化に興味がある方は、[お気軽にお問い合わせください](/contact)。