プラグインごとに格闘せずにRedmineをAIとつなぐ方法

最初は各プラグインのAPIを手作業で洗い出し、そのメソッドをMCPツールに変換していました。1つのプラグインなら機能しますが、多くなると破綻します。

Redmine MCP はRedmine内部で動作し、共有Registryを公開します。他のプラグインはそこに自分たちのツール、リソース、prompt、capability を登録できます。MCPサーバーがそれぞれの業務ロジックを知る必要はありません。

Redmine、Agile、Checklists、さらに各社内モジュールごとに別々のMCPサーバーを立てる代わりに、経路は1つです。AIクライアント → Redmine MCP → Redmine → 対象プラグイン。

プラグインはMCPサーバーのforkではなく、MCP拡張になります。 プラグインを編集できるなら、連携コードは `lib/.../mcp.rb` に置き、`RedmineMcp::ExtensionApi` を拡張してツールを登録します。名前は `redmine_<plugin>_<action>` に従います。

サードパーティ製プラグインをパッチできない場合は、adapter を `redmine_mcp/lib/redmine_mcp/extensions/` 配下に置けます。MCP対応のためだけに他人のプラグインをforkする必要はありません。どちらの経路でも同じ Extension API と Registry を使います。

この統合作業の一部はAIエージェントに任せられます。 Redmine MCP には `redmine-mcp-plugin-integration` skill が付属しており、プラグインAPI、serializer、service の読み方、機能のツール分割、入出力schemaの定義、権限の適用、テスト方法を示しています。

Workflowはシンプルです。エージェントにプラグインのソースコードを渡し、skill を有効にして、MCP対応を追加するよう依頼します。checklistプラグインであれば、`redmine_checklists_get_checklist`、`redmine_checklists_add_checklist_item`、`redmine_checklists_update_checklist_item`、`redmine_checklists_delete_checklist_item` が得られるかもしれません。

その後、ユーザーは「チケット #1234 を調べて、未完了のチェックリスト項目を一覧にして」と依頼できます。モデルはプラグインの非公開APIを推測する代わりに、名前付きのツールを選びます。

エージェントが生成したコードは、そのままでは本番品質ではありません。 実際のプラグインAPIに対して、権限、schema、成功系と失敗系を検証してください。テストでは Registry の経路全体、つまり validation → permission → handler → response をカバーすべきです。

最初の試行でうまくいくこともあれば、プラグイン固有のヒントが必要なこともあります。いずれにせよ、毎回ゼロから設計するより安く済みます。

権限はRedmineの権限のままです。 MCPはユーザーのAPI keyで認証します。アクセスには `Use MCP` 権限も必要です。プロジェクトとチケットには標準の可視性チェック（`Project.visible`, `Issue.visible`）が使われます。書き込みを止めたい場合は、グローバルなread-onlyモードも利用できます。

拡張はRedmineの権限チェックを呼び出すか、現在のユーザーとして既存のプラグインREST endpointを再利用すべきです。RedmineのACLを迂回するAIスーパーユーザーは存在しません。

実装の詳細は extension guide、インストールとクライアント設定は project README を参照してください。

私たちは、あらゆるRedmineプラグインを自動発見するMCPを作ったわけではありません。それは目指すべきゴールではありません。

作ったのは、プラグインが自分のツールを登録できるRegistryと、AIエージェントが統合作業の大部分を下書きできるだけの詳細なskillです。

次のプラグインにMCP対応が必要になったら、まずコードをエージェントに渡します。手作業に入るのは、エージェントが失敗したときだけです。