はじめに
ChatGPT から MCP 経由で Redmine を操作できるようになると、次に問題になるのが権限管理です。
最初は利用者が1〜2人であれば、1つの MCP Server と1つの Redmine API Key だけでも運用できます。
しかし利用者が増えてくると、次のような要求が出てきます。
- 閲覧だけできる利用者を作りたい
- チケット更新は許可したいが、管理操作は許可したくない
- 人間と AI Agent で権限を分離したい
- CI や Agent Runner には必要最小限の操作だけ許可したい
- 誤操作や Agent の暴走時にも被害範囲を限定したい
このとき重要なのは、MCP Server の機能だけで権限を管理しようとしないことです。
基本方針としては、
MCP 側の制限と Redmine 側の権限を組み合わせて、権限境界を作る
のが分かりやすい構成になります。
1. MCP Tunnel Client は常駐させる
MCP Tunnel Client は手動起動するより、Linux サーバー上で systemd 管理する方が運用しやすくなります。
例えば Redmine が稼働しているサーバー上で、
ChatGPT
↓
Secure MCP Tunnel
↓
MCP Tunnel Client
↓
Redmine MCP Server
↓
Redmine REST API
↓
Redmine
という構成にします。
MCP Tunnel Client と MCP Server を systemd で常駐させれば、
- OS 起動時の自動起動
- プロセス異常終了時の自動再起動
- journal によるログ確認
- サービス単位での起動・停止
が可能になります。
利用者が数人程度であれば、Kubernetes や大規模な実行基盤を用意する必要はありません。
まずは Redmine サーバーや専用 VM 上で systemd 管理する構成で十分です。
2. 利用者ごとではなく権限境界ごとに分離する
利用者が増えたときに、単純に
ユーザーA → MCP Server A
ユーザーB → MCP Server B
ユーザーC → MCP Server C
と人数分のプロセスを作る必要はありません。
基本的には、利用者ではなく権限クラスごとに MCP Server を分離します。
例えば、
ChatGPT Users
│
├─ Reader
│ ↓
│ Tunnel A
│ ↓
│ MCP Server A
│ ↓
│ Read-only Redmine API Key
│
└─ Writer
↓
Tunnel B
↓
MCP Server B
↓
Write-enabled Redmine API Key
という構成です。
systemd 上でも、
redmine-mcp-reader.service
redmine-mcp-writer.service
のようにサービスを分ければ管理できます。
3. Read-only は二重に制限する
閲覧専用 MCP を作る場合、MCP Server 側の read-only 設定だけに依存しない方が安全です。
例えば Reader 用 MCP を、
Reader MCP
├─ MCP Server: read-only
└─ Redmine API Key: 閲覧専用権限
とします。
Writer は、
Writer MCP
├─ MCP Server: write enabled
└─ Redmine API Key: 必要な書き込み権限あり
とします。
つまり、
MCP Tool の公開範囲
+
Redmine の認可
の二重構造にします。
仮に MCP Server 側に書き込み Tool が誤って公開されていたとしても、Redmine API Key 側に書き込み権限がなければ、その操作を Redmine 側で拒否できます。
権限管理を MCP Server の実装だけに依存しないことが重要です。
4. Redmine は MCP の権限設計と相性が良い
Redmine はロールとプロジェクト権限を中心に認可を設計できるため、MCP 経由の操作権限を分離しやすい構造になっています。
例えば、
Reader
├─ チケット閲覧
├─ Wiki閲覧
└─ 書き込み不可
Developer Writer
├─ チケット閲覧
├─ チケット作成
├─ チケット更新
└─ コメント追加
Agent
├─ チケット閲覧
├─ Agent Brief関連の更新
├─ コメント追加
└─ プロジェクト管理不可
Administrator
├─ チケット管理
├─ Version管理
├─ Member管理
└─ Project管理
のように役割を分けられます。
MCP Server から Redmine REST API を呼び出す場合も、最終的な認可を Redmine 側に任せられます。
ChatGPT
↓
MCP Tool
↓
MCP Server
↓
Redmine API Key
↓
Redmine Role / Permission
↓
許可された操作だけ実行
この構造は非常に分かりやすいものです。
5. 人間と AI Agent は分離する
将来的に AI Agent Runner を導入する場合、人間用 MCP と Agent 用 MCP は分けた方がよいでしょう。
例えば次の4系統です。
1. redmine-mcp-reader
人間向け
閲覧専用
2. redmine-mcp-writer
人間向け
Ticket作成・更新
3. redmine-mcp-agent
Agent / Handler / Runner向け
Agent Briefや状態遷移など限定操作
4. redmine-mcp-admin
管理者向け
必要な場合のみ利用
これによって、Agent に必要以上の権限を与えずに済みます。
例えば Agent Runner が必要とする操作が、
- 対象 Ticket の取得
- Agent Brief の取得
- Journal への記録
- 特定のステータス遷移
- 進捗更新
だけであれば、それ以上の権限を与える必要はありません。
理想的には、
Agent
↓
Agent用MCP
↓
Agent専用API Key
↓
限定Redmine Role
↓
特定Project
という複数の境界を通します。
6. Agent の暴走を前提に権限を設計する
AI Agent の権限設計では、
「Agent が正しく動くこと」
だけを前提にしてはいけません。
例えば Agent が誤動作して、
- 大量の Ticket を更新する
- 不要な Ticket をクローズする
- Version を変更する
- Member を操作する
といったことが起きても、Redmine 側の権限で止められるようにします。
Agent
↓
許可されたMCP Tool
↓
許可されたRedmine Role
↓
許可されたProject
という形で被害範囲を限定します。
これは一般的な least privilege、つまり最小権限の考え方そのものです。
7. 人数が増えてもプロセス数を人数に比例させない
例えば利用者が10人になったとしても、
10人
↓
10個のMCP Server
とする必要はありません。
むしろ、
10人
├─ Reader 5人
├─ Writer 3人
├─ Agent Operator 1人
└─ Administrator 1人
であれば、
Reader MCP
Writer MCP
Agent MCP
Admin MCP
という4つ程度の権限境界で運用できます。
つまりスケール単位は、
人間の人数ではなく Trust Boundary
です。
これなら人数が増えても構成が複雑化しにくくなります。
8. GitHub より Redmine の方が分かりやすい場面
Issue 管理だけを目的とした権限設計では、Redmine の方が扱いやすいと感じる場面があります。
GitHub は、
Read
Triage
Write
Maintain
Admin
のような Repository 全体を中心とした権限モデルです。
一方 Redmine は、Issue Tracker を中心にロールを作成し、
閲覧
作成
更新
コメント
関連付け
Version管理
Member管理
といった責務を分けやすい構造です。
そのため、
「AI Agent に Issue 更新は許可するが、Project 管理は許可しない」
といった設計が比較的自然にできます。
9. GitHub と Redmine は役割を分ける
AI Agent を利用した開発では、Redmine と GitHub のどちらか一方にすべてを寄せる必要はありません。
むしろ、
Redmine
├─ Requirement
├─ Roadmap
├─ Ticket
├─ Agent Brief
├─ Approval
└─ Workflow State
GitHub
├─ Source Code
├─ Branch
├─ Commit
├─ Pull Request
└─ CI
と責務を分ける方が自然です。
Redmine を、
開発要求と Agent Workflow の SSOT
として扱い、
GitHub を、
コードと CI の SSOT
として扱います。
10. Agent Brief Workflow と権限を対応させる
例えば Agent Brief の状態遷移を、
Brief Draft
↓ Human Review
Brief Ready
↓ Handler Validation
Ready for Agent
↓ Agent Runner
Implementation
↓
CI
とする場合、それぞれの操作者に同じ権限を与える必要はありません。
例えば、
Human Writer
├─ Brief Draft編集
└─ Human Review
Handler
├─ Brief検証
└─ Ready for Agentへの遷移
Agent Runner
├─ Ready for Agent取得
├─ 実行状態記録
└─ 実装結果記録
CI
└─ 検証結果記録
という分離が可能です。
つまり Workflow の状態遷移と Redmine Role を対応させることで、
誰がどの状態を変更できるか
を技術的に制限できます。
11. 最終的な構成
小規模な状態では、
ChatGPT
↓
MCP Tunnel
↓
systemd
↓
Redmine MCP Server
↓
Redmine API
だけでも十分です。
利用者や Agent が増えてきたら、
┌─ Reader MCP ─ Reader API Key
│
ChatGPT / Agent ────┼─ Writer MCP ─ Writer API Key
│
├─ Agent MCP ── Agent API Key
│
└─ Admin MCP ── Admin API Key
│
↓
Redmine
へ発展させます。
MCP Server の分離単位はユーザー単位ではなく、
権限・責務・Trust Boundary 単位
とします。
まとめ
Redmine と MCP を組み合わせる場合、権限管理を複雑な独自認可システムとして実装する必要はありません。
基本構造は、
利用者 / Agent
↓
権限別 MCP Server
↓
権限別 Redmine API Key
↓
Redmine Role
↓
Project Permission
で十分強力です。
特に重要なのは、
- MCP Tunnel Client は
systemdで常駐させる - 人数ではなく権限境界ごとに MCP Server を分ける
- MCP 側と Redmine 側で二重に権限制御する
- 人間用 MCP と Agent 用 MCP を分離する
- Agent には最小権限しか与えない
- Redmine を Workflow / Requirement の SSOT にする
- GitHub は Source / PR / CI の SSOT にする
という点です。
少人数のうちは Reader / Writer の2系統だけでも十分です。
AI Agent Runner を導入する段階で、
Reader
Writer
Agent
Admin
へ分離すれば、現在の小規模構成を捨てることなくそのまま拡張できます。
この意味で Redmine は、単なる Issue Tracker としてだけでなく、AI Agent 時代の開発 Workflow における認可・状態管理基盤としても扱いやすいシステムです。