社内業務を自動化するマルチLLM AIエージェント基盤の設計と実装

はじめに：なぜ「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等）を活かせない

リクエスト → LLMプロキシ（ポート8000）
  → モデル選択（タスクに応じて最適なLLMを自動選択）
  → フォールバック管理（障害時は次のモデルへ自動切替）
  → ヘルスチェック（各プロバイダーの稼働状況を追跡）
  → レスポンス整形（統一フォーマットで返却）

対応モデルと使い分け

フォールバックの実装

// プロバイダーごとの状態管理
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は「考える」能力に長けていますが、実際に「行動する」にはツール（スキル）が必要です。

当基盤では、以下のスキルを組み込んでいます。

スキルの呼び出しフロー

ユーザー: 「先月の売上データをまとめて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形式で記録します。

## 2026-04-24 作業ログ
10:05 売上レポート作成依頼（営業部 佐藤さん）

3月度売上CSVを /nas/sales/ から取得

前年同月比を算出、グラフ付きExcel生成

佐藤さんにメール送信完了

14:30 サーバー監視アラート対応

CPU使用率90%超過を検知

原因: バッチ処理の並列実行過多

対応: cron設定を調整、正常化を確認

長期メモリ（中期）

セッションメモリから抽出した「今後も役立つ知識」を蓄積します。

## 業務知識
月次売上レポートは毎月5日までに提出（経理部ルール）

サーバーCPU閾値は80%でアラート、対応手順はWikiの「障害対応」参照

佐藤さん（営業）はExcel形式を好む、PDF不可

「書き留める」原則を徹底し、口頭での申し送りに相当する情報を確実に蓄積しています。

Docker基盤によるデプロイ

エージェント基盤全体をDockerコンテナで構成し、再現性と可搬性を確保しています。

# 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ヶ月間運用した結果、以下の効果が得られました。

構築時に注意すべき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基盤で再現性・可搬性・監視性を確保する