知識グラフ駆動型Redmineチケットシステム(2)

<a href="https://it.blogmura.com/ranking/in?p_cid=11119283" target="_blank"><img src="https://b.blogmura.com/it/88_31.gif" width="88" height="31" border="0" alt="にほんブログ村 IT技術ブログへ" /></a><br />

# システム化の壁：理想と現実のギャップ

構想自体は以前から明確だった。しかし、実際にシステム化を進めようとすると、大きな壁にぶつかった。

https://qiita.com/EasyCording/items/9b536ab320ccb5b6ebfc


## 従来アプローチの問題点

**個人アシスタント型AIの実装課題：**
- AIエージェント間の連携が複雑すぎる
- 処理の流れが曖昧で、デバッグが困難
- エラー処理やリトライ機構の実装が煩雑
- システム全体の状態管理が不透明

つまり、**アイデアは良いが、実装が現実的でなかった**のである。

# 解決策：チケット駆動開発の採用

この壁を突破するために採用したのが、**既存のプロジェクト管理手法をAI管理に応用する**アプローチである。

https://qiita.com/EasyCording/items/0bdc4ed08320dd85c437

## チケット駆動がもたらすシステム化の利点

1. **明確な処理単位**：すべての処理がチケットという単位で管理される
2. **トレーサビリティ**：何がいつ実行されたかが明確
3. **エラー処理の簡素化**：チケットの状態管理で解決
4. **段階的実装**：一つずつエージェントを追加できる
5. **既存ツール活用**：REDMINEという実績あるツールを中心に構築

**要するに、理想を現実的に実装するための手法として、チケット駆動開発を選択した。**

---

### 構成の説明（実装重視版）

従来の構想は変わらないが、**実装の現実性**を考慮して以下のように再設計した：

1. **Input（入力ソース）** - *変更なし*
   - 日々の情報入力は従来通り

2. **AI_Processing（AI処理レイヤー）** - *実装手法を変更*
   - **チケット生成エンジン**: 入力をすべてチケット化
   - **エージェント管理システム**: チケットベースでエージェントを制御
   - **実装のポイント**: 複雑な連携ではなく、シンプルなチケット処理

3. **Ticket_Management（チケット管理）** - *新規追加*
   - **REDMINEを活用**: 既存ツールで確実に動作
   - **状態管理**: チケットの状態でシステム全体を制御
   - **実装のポイント**: 枯れた技術で安定性を確保

4. **Agent_Execution（エージェント実行）** - *実装手法を変更*
   - **専門エージェント**: チケット単位で起動
   - **独立性**: エージェント間の複雑な依存関係を排除
   - **実装のポイント**: 一つずつ確実に動作するエージェントを構築


この修正により、「アイデアは同じだが、実装可能性を重視してアプローチを変更した」という流れが明確になります。

# シーケンス図

この修正により明確になる点：

* チケットが処理の中心：すべての処理がチケット経由
* エージェントの独立性：各エージェントがチケットを取得して独立実行
* 並行処理：タスクとコンテンツが同時進行
* 状態の可視化：REDMINEで全体の進捗が見える
* トレーサビリティ：すべての処理過程が記録される


```plantuml
@startuml
skinparam backgroundColor #FFFFFF
skinparam sequence {
    ArrowColor #333333
    ActorBorderColor #333333
    LifeLineBorderColor #333333
    ParticipantBorderColor #333333
    ParticipantBackgroundColor #EEEEEE
}

actor Human
participant "LINE\nBot" as Line #98FF98
participant "チケット生成\nエージェント" as TicketAgent #87CEEB
participant "REDMINE\n(チケット管理)" as Redmine #FFB6C1
participant "タスク実行\nエージェント" as TaskAgent #FF6B6B
participant "コンテンツ生成\nエージェント" as ContentAgent #4169E1
participant "WordPress" as WP #DDA0DD

== 1. 入力・チケット生成フェーズ ==
Human -> Line: つぶやき/メモ
activate Line
Line -> TicketAgent: テキストデータ送信
activate TicketAgent
TicketAgent -> TicketAgent: AI解析・分類
TicketAgent -> Redmine: タスクチケット生成
activate Redmine
TicketAgent -> Redmine: コンテンツチケット生成

== 2. チケット割当・監視フェーズ ==
Redmine -> Redmine: 優先度・期限設定
Redmine -> TaskAgent: タスクチケット通知
activate TaskAgent
Redmine -> ContentAgent: コンテンツチケット通知
activate ContentAgent

== 3. 並行実行フェーズ ==
TaskAgent -> TaskAgent: チケット内容解析
TaskAgent -> TaskAgent: タスク実行
TaskAgent -> Redmine: 進捗更新
TaskAgent -> Redmine: 完了報告

ContentAgent -> ContentAgent: チケット内容解析
ContentAgent -> ContentAgent: 記事生成
ContentAgent -> WP: 記事投稿
activate WP
ContentAgent -> Redmine: 進捗更新
ContentAgent -> Redmine: 完了報告

== 4. 結果通知フェーズ ==
Redmine -> Line: 全チケット完了通知
Line -> Human: 実行結果サマリー

== 5. フィードバック処理 ==
Human -> Line: 修正指示（必要時）
Line -> TicketAgent: 修正チケット生成
TicketAgent -> Redmine: 修正チケット登録

deactivate WP
deactivate ContentAgent
deactivate TaskAgent
deactivate Redmine
deactivate TicketAgent
deactivate Line

@enduml
```

**この修正により明確になる点：**

1. **チケットが処理の中心**：すべての処理がチケット経由
2. **エージェントの独立性**：各エージェントがチケットを取得して独立実行
3. **並行処理**：タスクとコンテンツが同時進行
4. **状態の可視化**：REDMINEで全体の進捗が見える
5. **トレーサビリティ**：すべての処理過程が記録される

mermaidのフローチャートよりも、このシーケンス図の方がチケット駆動開発の「時系列での処理の流れ」と「エージェント間の協調」が分かりやすく表現できますね。


# チケット割当・監視フェーズ：AIエージェント協働の核心

## 単純な振り分けから複雑な協調へ

当初は「タスクかコンテンツか」という単純な二択で考えていた。しかし、実際にシミュレーションを重ねるうちに、**タスクとコンテンツは表裏一体の関係**にあることが明らかになってきた。

例えば「新しいプログラミング言語を学びたい」という入力を考えてみよう。従来なら「学習計画を立てる」というタスクチケット一つで終わりだった。

しかし実際には、以下のような複合的な価値創造が可能である：

- **調査記事**：「Python学習法の比較検討」
- **実行タスク**：「学習環境の構築」
- **体験記事**：「実際に学習してみた感想」
- **派生タスク**：「記事の反響を踏まえた学習計画の修正」

## 表裏一体の価値創造システム

この発見により、チケット割当・監視フェーズの設計思想が根本的に変わった。

### 従来の単純割当モデル
```
入力 → 判定 → タスク OR コンテンツ → 完了
```

### 新しい協調創造モデル
```
入力 → 主チケット生成 → 複数側面分析 → 相互補完実行 → 統合完了
```

## 具体的な割当・監視の仕組み

### Phase 1: 主チケット生成と側面分析
システムはまず入力から「主チケット」を生成し、これを複数のエージェントに分析させる。各エージェントは自分の専門領域から見た「実行可能性」と「価値創造性」を評価する。

### Phase 2: 相互補完関係の特定
ここが最も重要な部分である。システムは各エージェントの分析結果を統合し、**どのような順序で実行すれば最大の価値を創造できるか**を判定する。

例えば：
- 調査記事 → タスク実行（調査結果が実行品質を向上）
- タスク実行 → 体験記事（実体験が記事の価値を向上）
- 体験記事 → 改善タスク（読者フィードバックが次の行動を生む）

### Phase 3: 動的監視と調整
従来の「チケット完了＝終了」ではなく、**一つのチケット完了が新しいチケットを生成する**可能性を常に監視する。これにより、単発の作業が価値創造の連鎖に発展する。

## 技術的な実装アプローチ

### 依存関係エンジン
```
チケットA（調査記事）→ チケットB（タスク実行）
チケットB（タスク実行）→ チケットC（体験記事）
チケットC（体験記事）→ チケットD（改善計画）
```

### 価値評価アルゴリズム
各チケットの組み合わせに対して「価値スコア」を算出し、最適な実行順序を決定する。単体では価値の低いタスクも、組み合わせることで高価値コンテンツに化ける可能性を評価する。

### リアルタイム調整機能
一つのチケットが完了した時点で、残りのチケットの優先度や内容を動的に調整する。これにより、状況の変化に応じた柔軟な価値創造が可能になる。

## この方式がもたらす革新

従来のタスク管理は「やるべきことを効率的に処理する」ことが目的だった。しかし、この新しいアプローチでは**「一つの行動から複数の価値を創造する」**ことが可能になる。

つまり、AIエージェントは単なる「作業の自動化」から「価値創造の増幅器」へと進化するのである。

## 次のステップ

この理論を実際のシステムで検証するため、小規模なプロトタイプでのシミュレーションが必要である。特に「どの程度の複雑さまで管理可能か」「人間の介入がどの段階で必要になるか」といった実用性の検証が重要になる。

**表裏一体の価値創造**—これが、次世代AIエージェント協働システムの核心概念なのかもしれない。