LLMAgent開発におけるRedmineによるチケット管理のメリット・デメリット

Last updated at 2026-05-22Posted at 2026-05-22

はじめに

内野航希と申します。現在、LLMAgentのタスク実行をRedmineで管理するシステムを開発しており、構成や実際の使用感が参考になるかもと思い投稿しました。まだ開発途中ですが、実際に使ってみるとメリットもデメリットもかなりはっきり見えてきたので、今回はその構成と所感を共有します。

全体の実装はAIに任せており、私自身は詳細実装に関与していません。それでも、設計判断の中で得た知見が誰かの参考になれば幸いです。

現在開発しているシステムは、UnityゲームをLLMAgentによって自動開発する一連のフローを構築することを最終目標としています。

	内容
✅ メリット	タスク管理が容易／役割分担できる／障害復旧がしやすい／拡張しやすい
❌ デメリット	チケット粒度次第で複雑化／低速・重い／デッドロック発生リスク／トークン消費が多い

この構成によって、大規模タスクをチケット単位に分割し、複数のWorkerへ分散処理させることができます。

また、チケットの深度（階層）に応じた処理の切り替えも実現しています。例えば初期チケットに対しては、タイトル・ステージセレクト・インゲームといったUnityシーン単位にサブチケットを発行し、場面ごとの情報を分割して管理しています。

Redmineは人間向けのチケット管理ツールであるため、進行中・エラー・完了といった状態を人間が直接確認しやすいのが強みです。

Redmineを選定した理由は次の2点です：

この2条件を満たすツールであれば、JiraやLinearなど他のチケット管理ツールでも代替可能だと思います。また、要件がシンプルであれば自作も選択肢に入ります。

複雑な開発において、LLMAgentの役割を分けて各Agentを単一責任に徹底させることができます。

ゲーム開発では関係する職種が多岐にわたります：

LLMAgentが対応できないタスク（画像生成・音楽生成など）に対しては、チケットをトリガーに外部の生成APIを呼び出す構成も視野に入れています。この「チケット→Worker起動」のワンクッションで、タスク種別に応じたチケットの発行や、必要な情報の注入が柔軟に行えます。

New・InProgress・Resolvedといったステータスにより、進捗や残タスク量を把握しやすいです。

ポーリングが途中で停止した場合でも、完了済みチケットが保存されているため、再起動後に未完タスクから処理を再開できます。

タスク種別を追加し、ワンクッション部の分岐処理に対応方法を記述するだけで、新しい種類のタスクを扱えるようになります。チケット（文字列）という疎結合なインターフェースを挟んでいることが、拡張性の高さにつながっていると感じています。

ゲーム開発特有の問題として、「プログラム的に正しい＝ゲーム的に正しい」ではないという点があります。チケットの粒度や記述が不適切だと、「動作するだけのプログラム集」になりがちです。

現在検討している改善策：

チケットの発行・ポーリング・新規Agent起動というオーバーヘッドにより、シンプルな構成と比べて処理が重くなります。スモールなタスク管理層を自作することで改善できるかもしれません。

エラー発生時にHotFixチケットを再発行するフローを組んだところ、LLMが問題を解決できずにHotFixが無限ループする状態が発生しました。

対策として、人間による確認フロー（Human-in-the-loop）の導入が必要だと考えています。これはセキュリティ観点（LLMへのフルアクセスを与えない）からも重要です。

Workerを毎回新規に立ち上げる関係で、同じコンテキスト情報をAgentごとに繰り返し読み込むことになり、トークン消費が嵩みます。共有コンテキストのキャッシュ活用などが改善の余地になりそうです。

以上、LLMAgentをRedmineのチケット単位で管理するシステムの概要と、実際に感じたメリット・デメリットの共有でした。

まだ安定した出力まではできていませんが、こうした構成の試行錯誤が誰かの参考になれば嬉しいです。「こんな方法があるよ」「この設計は無駄が多い」といったフィードバックがあれば、ぜひコメントいただけると助かります。