Redmine AI HelperプラグインはRedmineをAI駆動プロジェクト管理に変える可能性を秘めている #Redmine

Redmine AI Helperプラグインの講演資料を読んで改めてアーキテクチャ構造がよく考えられているなと思った。
Redmine AI Helperプラグインを知っている前提で、理解したことをラフなメモ書き。

【参考】
Redmine AI Helperとそのしくみ

第29回redmine.tokyo勉強会

2025年の年始に読み直したいAIエージェントの設計原則とか実装パターン集

Building Multi-Agent Systems with LangGraph and Ollama: Architectures, Concepts, and Code | by Diwakar Kumar | Medium

【1】Redmine AI Helperプラグインのマルチエージェントモデルは優れていると思った。

Redmine AI Helperプラグインのマルチエージェントモデルでは、Issueエージェント、Wikiエージェント、Userエージェントなどの機能に特化したエージェント群と、GitHubエージェント、Slackエージェント、メールエージェントのようなMCPエージェント群が協調して、互いに会話しながら動作する。

その時に、マルチエージェントモデルのアーキテクチャとして、@haru_iidaさんは、Networkではなく、Supervisorを選んだ。

第29回redmine.tokyo勉強会

2025年の年始に読み直したいAIエージェントの設計原則とか実装パターン集

Building Multi-Agent Systems with LangGraph and Ollama: Architectures, Concepts, and Code | by Diwakar Kumar | Medium

なぜ、Supervisorを選んだのか？
redmine.tokyo勉強会の講演で聞いたときは、NetworkよりもSupervisorの方がエージェント同士のレスポンスがいいと話していた。

理由は色々推測できる。
おそらく、複数のエージェント同士で処理を実行するために会話させたならば、誰かが全体の処理を監視してコントロールしなければ、変な方向に行ってしまう場合が多いのだろう。
エージェント同士のコミュニケーションパスが多くなるほど、統制が効かなくなるはずだ。
つまり、人間集団や組織と同様に、コミュニケーションパスを減らし、1人の管理者がコントロールできる範囲に収めるようにしなければ、本来実施して欲しい処理の品質が悪くなるのだろう。

では、Supervisor型のエージェントモデルでは、どんなコミュニケーション構造を取っているのか？
@haru_iidaさんの設計では、仮想チャットルームを作り、Supervisorが必要なエージェントのみをチャットルームに召喚して処理を実行させている。
仮想チャットルームは、まるで人間のSlackみたいな感じだ。

第29回redmine.tokyo勉強会

つまり、Slack上でエージェント同士が、チケットを更新する処理のために、Supervisorがまずエージェント達にゴールを共有した後、SupervisorがUserエージェントやIssueUpdateエージェントと会話してるイメージ。
エージェントは仮想プログラムに過ぎないのに、人間のように振る舞う点がすごく面白いと思った。

実際の仕組みは想像になるが、Supervisorやエージェント同士が会話するログのテキストファイルがあって、そのログテキストにあるプロンプトからファンクションコールされてエージェントがキックされるのだろうと思う。
つまり、会話ログというテキストファイルが仮想チャットルーム、すなわち、Slackみたいなイメージになるのだろう。

そのSlackにプロンプトが書かれると、処理すべき機能に対応するエージェントがファンクションコールで呼び出されてキックされて、プロンプト通りにエージェントが実行するわけだ。

そんな仕組みを考えると、処理を実行するプロンプトの背景、ゴールを明確に定義する必要があるだろう。
つまり、AIでよく言われるコンテキストが重要になってくるだろう。
なぜならば、背景や前提条件、制約条件というコンテキストが明確でなければ、期待した結果が出てこないからだ。
実際、ChatGPTでも前提条件を細かく書かないと、欲しい結果がなかなか出てこない。

こういうエージェントモデルでは、各エージェントのフォルダにコンテキストを事前設定するプロンプトを配置して、エージェントを制御する仕組みがあるらしいので、おそらく@haru_iidaさんは事前プロンプトにかなりのノウハウを組み込んでいるのではないかと想像する。

【2】Redmine AI Helperプラグインのアーキテクチャ構造も優れていると思った。

内部構造では、ユーザ要求処理、ビジネスロジック、外部サービスの3層構造に綺麗にレイヤ化されている。
具体的には、Webアプリ層、Agent層、MCPサーバやLLMの層の3層構造に綺麗に設計されている。
これはすごく綺麗だ。
アーキテクチャをちゃんと理解できる人しか組めないような綺麗なアーキテクチャだ。

第29回redmine.tokyo勉強会

わざわざ、マルチエージェントモデルを3層構造で分けたメリットは何なのか？
オブジェクト指向設計に慣れている人ならば効果はすぐに理解できるはずだ。

ユーザがMCP Agentや各機能に特化したドメインのAgentへ処理を実行させたい時、その処理は中身は違っても操作としては共通のインターフェイスを持つはずだ。
つまり、ユーザ要求処理とビジネスロジックの間に、Agent抽象化レイヤーを入れて、Agentへ指示する操作をインターフェイスで抽象化すれば、ポリモルフィズムを使って制御すればいい。

同様に、MCP AgentがGitHubやSlackに連携させたい時、MCP抽象化レイヤで操作をインターフェイスで抽象化しておけばいい。
あるいは、IssueAgentがOpenAIやAnthropicのLLMを使いたい時、LLM抽象化レイヤで操作をインターフェイスで抽象化すればいい。
そうすれば、LLMのバージョンが上がって追加したくなる場合、ビジネスロジック層のプログラムを変えることなく、簡単に追加したLLMを利用できるようになる。
つまり、抽象化レイヤがあるおかげで機能追加や機能修正のプログラミングが非常に楽になる。

僕は、この内部構造のアーキテクチャを見て、AIエージェントの仕組みを理解できた。
さらに、最近、AIの機能を入れました～とあらゆるWebサービスやパッケージ製品で広告を見かけるが、おそらくそれらシステムも@haru_iidaさんのようなアーキテクチャ構造に似た構造になっているに違いないと思った。
そうでなければ、大量の人員とお金を投資した案件なので、今後のシステム保守を考えれば元が取れないはずだ。

【3】Redmine AI Helperプラグインの根本テーマに「プロジェクト管理にもAIを」がある点がすごくいい。
AIが当たり前の現代では、ソフトウェア開発であれ、ホワイトカラーの仕事であれ、経営戦略をねったり、プロジェクト管理することも全てAI駆動になる。
AIを使うだけでなく、AIでいかに価値を出すか？

Redmine AI Helperプラグインによって、RedmineをAI駆動プロジェクト管理に変える可能性を秘めている。
従来は、Excelによるプロジェクト管理からの脱却がメインテーマだったが、現代では、AI駆動のプロジェクト管理により、プロジェクトリーダーやプロジェクトマネージャは本来の意思決定に専念できるようになる。
そんな機能が沢山盛り込まれているし、今後の機能追加により、さらに発展するだろう。

Redmine AI Helperプラグインは、そういう機能追加がやりやすいエージェントモデル、アーキテクチャ構造になっているので、今後の開発にすごく期待できる。
今後もウォッチしていきたいと思う。