# Proposal: ログ出力重複問題の修正

## Why

現在のコードベースにおいて、ログ出力の重複問題が発生しています。複数のロガーインスタンスが同時に起動され、同じメッセージが複数回出力される問題があります。この問題は以下の理由で修正が必要です：

- MCPサーバー起動時に重複ログメッセージが表示される
- デバッグ時の混乱とログファイルの不必要な肥大化
- 性能への軽微な影響とシステムの保守性低下

## What Changes

この変更では以下を実装します：

- 統一されたLoggerManagerクラスの新規追加
- ログ設定の集約化機能の実装
- 重複ハンドラー防止機能の実装
- 既存API互換性の完全維持
- 包括的なテストスイートの追加

## 概要

## 問題の詳細

### 根本原因分析

1. **複数のsetup_logger呼び出し**
   - `start_mcp_server.py`: `logger = setup_logger(__name__)`
   - `tree_sitter_analyzer/mcp/server.py`: `logger = setup_logger(__name__)`
   - 複数のツールファイルで`logger = setup_logger(__name__)`

2. **混在するロガー取得方法**
   - `setup_logger(__name__)` (カスタム実装)
   - `logging.getLogger(__name__)` (標準ライブラリ)

3. **グローバルロガーインスタンス**
   - `utils.py`で`logger = setup_logger()`が定義
   - 複数のモジュールで独立したログ設定

4. **パフォーマンスロガーの重複**
   - `create_performance_logger`と`setup_performance_logger`の両方が存在

### 影響範囲

- MCPサーバー起動時の重複ログメッセージ
- デバッグ時の混乱
- ログファイルの不必要な肥大化
- 性能への軽微な影響

## 提案する解決策

### 1. ロガー設定の集約化

- 単一のロガー設定エントリーポイントの確立
- モジュール間でのロガーインスタンス共有
- 標準的なログ階層の採用

### 2. 最小修正原則

- 既存のAPIを維持しつつ内部実装を改善
- レガシーコードとの互換性保持
- 段階的移行による安全性確保

### 3. 統一されたロガー管理

- シングルトンパターンによるロガーマネージャー導入
- 重複ハンドラーの検出と防止
- パフォーマンスロガーの統一

## 技術的アプローチ

### ログマネージャーの実装

```python
class LoggerManager:
    """統一されたロガー管理クラス"""
    _instance = None
    _loggers = {}
    
    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance
    
    def get_logger(self, name: str) -> logging.Logger:
        """重複を防ぐロガー取得"""
        if name not in self._loggers:
            self._loggers[name] = self._create_logger(name)
        return self._loggers[name]
```

### setup_logger関数の改善

```python
def setup_logger(name: str = "tree_sitter_analyzer", level: int | str = logging.WARNING) -> logging.Logger:
    """改善されたロガー設定関数"""
    manager = LoggerManager()
    return manager.get_logger(name)
```

## 実装計画

### Phase 1: ロガーマネージャー導入
- `LoggerManager`クラスの実装
- 既存の`setup_logger`関数の内部改善
- 重複ハンドラー検出機能の追加

### Phase 2: 段階的移行
- 主要モジュールでの新しいロガー利用
- テストケースの更新
- パフォーマンステストの実行

### Phase 3: 最終統合
- 全モジュールでの一貫性確保
- ドキュメント更新
- 回帰テストの実行

## 品質保証

### テスト駆動開発

1. **単体テスト**
   - ロガーインスタンス重複検出テスト
   - ハンドラー重複防止テスト
   - パフォーマンスロガー統一テスト

2. **統合テスト**
   - MCPサーバー起動時のログ出力検証
   - 複数モジュール間でのログ一貫性テスト

3. **パフォーマンステスト**
   - ログ出力性能の測定
   - メモリ使用量の監視

## 設計原則

### 最小侵襲修正
- 既存のAPIインターフェース保持
- 内部実装の改善に集中
- 破壊的変更の回避

### 最佳実践の採用
- Pythonロギングベストプラクティス準拠
- シングルトンパターンによる一意性確保
- ファクトリーパターンによる柔軟性

### 文書駆動開発
- 技術仕様書の先行作成
- API文書の更新
- ユーザーガイドの改善

## 期待される効果

### 直接的効果
- ログ重複の完全除去
- デバッグ効率の向上
- システム性能の軽微な改善

### 間接的効果
- コードの保守性向上
- 新規開発者のオンボーディング簡素化
- 将来的な機能拡張基盤の確立

## リスク評価

### 低リスク
- 既存API互換性の維持
- 段階的実装による安全性確保
- 十分なテストカバレッジ

### 緩和策
- 詳細な回帰テスト
- ロールバック計画の準備
- 段階的リリース戦略

## 結論

この変更により、ログ出力の重複問題を根本的に解決し、システム全体の品質と保守性を向上させることができます。最小修正原則とテスト駆動開発により、安全で確実な改善を実現します。