はじめに

社内でMacBook Proを1台購入し、ローカルLLMを動かせる環境を用意しました。

せっかく社内ネットワーク内でAIを動かせるなら、RedmineやSlackの情報を参照して、プロジェクトの進捗をまとめてもらいたいところです。

そこで今回は、以下を組み合わせた構成を考えます。

ローカルLLM
MCP
LangGraph

目標は、

「プロジェクトAの進捗どう？」

と聞くだけで、RedmineとSlackを横断して状況をまとめてくれる社内向けAIです。

1. MCPで社内システムに接続する

MCP（Model Context Protocol）は、LLMと外部ツールを接続するためのプロトコルです。

今回の構成は次のようになります。

                 ┌──────────────┐
                 │     LLM      │
                 └──────┬───────┘
                        │
                        │ MCP
                        ▼
                 ┌──────────────┐
                 │  MCP Server  │
                 └──────┬───────┘
                        │
             ┌──────────┴──────────┐
             ▼                     ▼
         ┌────────┐           ┌────────┐
         │ Redmine│           │ Slack  │
         └────────┘           └────────┘

MCP Serverでは、例えば次のようなツールを提供します。

get_issue(issue_id)
search_issues(query)
list_open_issues()

search_messages(query)
get_thread(channel_id, thread_ts)
get_channel_history(channel_id)

LLMはこれらのツールを呼び出し、RedmineやSlackの情報を取得します。

2. 最初は読み取り専用にする

社内データを扱うため、最初のPoCでは読み取り専用にします。

Redmine
├── list_issues       ○
├── get_issue         ○
├── search_issues     ○
├── create_issue      ×
├── update_issue      ×
└── delete_issue      ×

Slack
├── search_messages   ○
├── get_thread        ○
├── get_history       ○
└── send_message      ×

重要なのは、プロンプトで「書き込み禁止」と指示するのではなく、MCP Serverに書き込み用ツールを実装しないことです。

これなら、LLMが誤って判断しても、RedmineやSlackを変更する操作自体を呼び出せません。

3. LangGraphで処理フローを組み立てる

MCPはツールを提供しますが、ツールを呼ぶ順番や、結果をどう処理するかまでは管理しません。

そこでLangGraphを使います。

                    ┌─────────────┐
                    │   User      │
                    └──────┬──────┘
                           ▼
                    ┌─────────────┐
                    │ LangGraph   │
                    │   Agent     │
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │    LLM      │
                    │   oMLX      │
                    └──────┬──────┘
                           │
                      Tool Call
                           │
                           ▼
                    ┌─────────────┐
                    │ MCP Client  │
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │ MCP Server  │
                    └──────┬──────┘
                           │
                  ┌────────┴────────┐
                  ▼                 ▼
              ┌────────┐        ┌────────┐
              │Redmine │        │ Slack  │
              └────────┘        └────────┘

例えば、次のような処理をGraphとして定義できます。

LLM
 ↓
Redmineを検索
 ↓
結果を整理
 ↓
Slackを検索
 ↓
情報を比較
 ↓
進捗レポートを生成

4. LLMはどうやってツールを知るのか

LLMがMCP Serverを直接知っているわけではありません。

MCP ClientがMCP Serverからツール定義を取得し、それをLangGraph経由でLLMに渡します。

例えば、ツール定義は次のような形式です。

{
  "name": "get_issue",
  "description": "Get a Redmine issue",
  "input_schema": {
    "type": "object",
    "properties": {
      "issue_id": {
        "type": "integer"
      }
    },
    "required": ["issue_id"]
  }
}

LangGraph側では、概念的には次のようにLLMへツールをバインドします。

tools = mcp_client.get_tools()

llm_with_tools = llm.bind_tools(tools)

流れは次のとおりです。

MCP Server
   │
   │ tools/list
   ▼
MCP Client
   │
   │ ツール定義
   ▼
LangGraph
   │
   │ bind_tools()
   ▼
LLM

LLMはRedmine APIやSlack APIを直接扱うのではなく、get_issue や search_messages といったツールとして認識します。

5. Tool Callの流れ

ユーザーが、

「プロジェクトAの未完了チケットを教えて」

と質問したとします。

LLMは search_issues を使うと判断し、次のようなTool Callを返します。

{
  "name": "search_issues",
  "arguments": {
    "status": "open",
    "project": "project-a"
  }
}

LangGraphはこのTool Callを受け取り、MCP経由でRedmineを検索します。

LLM
 ↓
search_issues
 ↓
MCP Client
 ↓
MCP Server
 ↓
Redmine

取得結果はLLMに戻され、最終的な回答が生成されます。

Redmine
 ↓
MCP Server
 ↓
MCP Client
 ↓
LangGraph
 ↓
LLM
 ↓
回答

6. LangGraphの基本的な構成

Agentの処理は、単純化すると次のようになります。

START
  │
  ▼
┌──────────┐
│   LLM    │
└────┬─────┘
     │
     ├── 通常回答 ──────► END
     │
     └── Tool Call
             │
             ▼
       ┌──────────┐
       │ ToolNode │
       └────┬─────┘
            │
            ▼
          MCP
            │
            ▼
         Redmine
            │
            ▼
       ┌──────────┐
       │   LLM    │
       └────┬─────┘
            │
            ▼
           END

単純なチャットなら User → LLM → Answer で済みます。

一方、RedmineとSlackを順番に検索したり、結果を比較したりする場合は、LangGraphで処理を明示的に管理できます。

7. 目指す構成

最終的には、次のような処理を実現します。

ユーザー

「プロジェクトAの進捗どう？」

          ↓

      LangGraph
          ↓
        LLM
          ↓
   ┌──────┴──────┐
   ▼             ▼
Redmine         Slack
   │             │
   ▼             ▼
チケット        会話
   │             │
   └──────┬──────┘
          ▼
        LLM
          ↓
     進捗を分析
          ↓
        回答

回答例は次のようなものです。

プロジェクトAは現在78%のチケットが完了しています。
未完了チケットのうち3件は期限を超過しています。
SlackではAPI開発の遅延を示すやり取りが確認されており、Redmine上の期限とSlack上の認識にも差があります。

8. 計算はプログラム、解釈はLLM

進捗率のような計算は、LLMに任せずプログラムで処理します。

全チケット: 100
完了: 75

であれば、

progress = completed / total

で計算します。

LLMに任せるのは、次のような処理です。

Slackの文脈を理解する
チケットの状況を要約する
遅延リスクを読み取る
情報同士の矛盾を見つける
人間向けの報告文にまとめる

役割分担は次のとおりです。

正確な処理
    ↓
プログラム

意味理解・要約・推論
    ↓
LLM

9. ローカルLLMを使う理由

今回扱うのは、RedmineやSlackなどの社内データです。

これらを外部のLLM APIへ送信する場合、セキュリティやデータ取り扱いを検討する必要があります。

一方、社内ネットワーク内で処理を完結できれば、社内データを外部に出さずに済みます。

Slack
  ↓
MCP
  ↓
LangGraph
  ↓
oMLX
  ↓
ローカルLLM

ただし、ローカルだから自動的に安全というわけではありません。

APIキーの管理
MCP Serverの認証
ネットワーク制御
ログ・監査
最小権限
読み取り専用

といった対策は必要です。

10. 構成要素の役割

コンポーネント	役割
oMLX	ローカルLLMを動かす
LLM	推論・自然言語理解
LangGraph	Agentの処理フローを制御
MCP Client	MCP Serverと接続
MCP Server	AIにツールを提供
Redmine	プロジェクト情報
Slack	コミュニケーション情報

全体の構成は次のとおりです。

                ┌──────────────┐
                │    User      │
                └──────┬───────┘
                       │
                       ▼
                ┌──────────────┐
                │  LangGraph   │
                │  Agent       │
                └──────┬───────┘
                       │
                       ▼
                ┌──────────────┐
                │     LLM      │
                │    oMLX      │
                └──────┬───────┘
                       │
                  Tool Calling
                       │
                       ▼
                ┌──────────────┐
                │  MCP Client  │
                └──────┬───────┘
                       │
                       ▼
                ┌──────────────┐
                │  MCP Server  │
                └──────┬───────┘
                       │
              ┌────────┴────────┐
              ▼                 ▼
          ┌────────┐        ┌────────┐
          │Redmine │        │ Slack  │
          └────────┘        └────────┘

おわりに

今回の構成では、次のように役割を分担します。

oMLX：ローカルLLMを動かす
MCP：RedmineやSlackをツールとして公開する
LangGraph：ツール呼び出しや処理フローを制御する

まずは読み取り専用でRedmineのチケット検索から始め、最終的にはRedmineとSlackを横断した進捗報告Agentを目指します。

次のステップでは、実装編に移りたいと思います。