Redmineの設定

目的¶

チケット#177のCORS/API routing問題について、コードレビューと修正方法の再検討を実施。RAGベースAIアドバイザー統合プロジェクト(#243)との関連も分析し、最適な解決策を立案する。

現状分析¶

問題の本質¶

1. task2.call2arm.com: 自身の /api/ エンドポイントを呼び出し
2. 期待動作: dev.call2arm.com のRedmine APIを呼び出し
3. RAG統合: task2-apiにはRAG機能が実装済み
4. アーキテクチャ混在: Redmine API + RAG API の統合設計が不明確

システム構成レビュー¶

task2-api (Node.js + Express)¶

• 実装済み機能: RAG、検索、チャット、分析
• 欠落機能: Redmine APIプロキシ
• 環境変数: REDMINE_URL, REDMINE_API_KEY 設定済み

nginx プロキシ層¶

• 修正済み: 複数のlocation block設定
• 課題: 優先度・マッチング問題継続

RAG統合プロジェクト(#243)¶

• 6週間プロジェクト: ベクトル検索 + Claude API
• 技術スタック: PostgreSQL + pgvector, Redis, Meilisearch
• 統合対象: ニュース、ドキュメント、チケット

修正方法再検討¶

アプローチ1: task2-api内統合 (推奨)¶

利点:

• 単一APIエンドポイント
• RAG機能とRedmine APIの統合
• エラーハンドリング統一

実装内容:

1. Redmine APIプロキシルーター追加
2. RAG機能とRedmine データの統合
3. 統一レスポンス形式

アプローチ2: マイクロサービス分離¶

利点:

• 責任分離
• 独立スケーリング

課題:

• CORS設定複雑化
• 運用複雑性増加

アプローチ3: nginx完全プロキシ¶

利点:

• アプリケーション変更なし

課題:

• 設定複雑性
• 現在の問題継続リスク

RAG統合との関連性¶

データフロー統合¶

1. Redmine チケット → ベクトル化 → 検索対象
2. Claude API → Redmine データ参照 → コンテキスト aware 応答
3. 統合UI → 単一API → Redmine + RAG機能

技術的シナジー¶

• チケット分析: RAGでチケット内容の意味的検索
• プロジェクト洞察: ベクトル検索による関連チケット発見
• AI支援: Redmineデータを活用したClaude応答

実装計画¶

Phase 1: task2-api Redmine統合 (1-2日)¶

1. Redmine APIプロキシ実装
2. エラーハンドリング統一
3. CORS設定統合

Phase 2: RAGデータ統合 (3-5日)¶

1. Redmineデータのベクトル化
2. 検索API統合
3. Claude API連携強化

Phase 3: UI最適化 (1週間)¶

1. 統一API利用への移行
2. レスポンス形式標準化
3. エラー表示改善

成功指標¶

• task2.call2arm.com でRedmine API正常動作
• RAG機能とRedmine統合デモ動作
• 統一されたエラーハンドリング
• Claude APIとRedmineデータ連携