Zenn
🤝

note-converterとDiary-Converterの統合方針を検討（開発日記 No.059）

に公開
Python
リファクタリング
開発日記
idea

関連リンク

はじめに

昨日はCI/CDパイプラインの不具合修正に取り組みました。今日は、現在並行して開発を進めている2つのMarkdown変換ツール、「note-converter」と「Diary-Converter」の統合について、本格的に検討を開始しました。

背景と目的

現在、私の手元には以下の2つのツールがあります。

  • note-converter: Markdownファイルをnote.comの記事形式に変換するツール（OpenRouter API利用）
  • Diary-Converter: 開発日記（Markdown）をZennの記事形式に変換するツール（Gemini API利用）

どちらも「Markdownを入力とし、LLMを使って特定のプラットフォーム向けに変換・整形する」というコア機能は共通しています。しかし、対象プラットフォームや使用するLLM API、開発の成熟度が異なります。

このまま個別に開発を進めると、コードの重複やメンテナンスコストの増大が懸念されます。そこで、両者の機能を統合し、より効率的で拡張性の高い単一のツールへと進化させることを目的として、今回の検討を行いました。

検討内容

まず、LLMに両プロジェクトの概要、共通点、差異を分析してもらいました。

共通点:

  • Markdown入力 → LLM処理 → 特定フォーマット出力、という基本フロー
  • Pythonベース、LLM API利用、CLI実行、テンプレート機能

差異:

  • 対象: note.com vs Zenn
  • LLM: OpenRouter vs Gemini
  • 開発状況: note-converter（約84%） vs Diary-Converter（成熟、Docker/CI/CD統合済）
  • 環境: シンプル vs Docker/GitHub Actions
  • テンプレート: 初期段階 vs 洗練
  • コード構造: 関数ベース寄り vs クラスベース・モジュール分割

これらの分析を踏まえ、統合の方向性として以下の3つの選択肢を検討しました。

  1. Diary-Converterベースでの拡張: 成熟したインフラを活かす。
  2. note-converter機能をDiary-Converterへ移植: OpenRouter対応などを追加。
  3. 新規プロジェクトでの統合: 両者の良い点を組み合わせた汎用コンバーターを作成。

さらに、両プロジェクトのコード（コア変換機能、拡張機能、依存関係、インターフェース）を比較分析しました。Diary-Converterはクラスベースでモジュール化が進んでおり、拡張性が高い一方、note-converterはOpenRouterクライアントの実装やエラーハンドリングが詳細に行われている点が特徴でした。

依存関係を見ると、note-converterの方が多くのライブラリに依存していることも分かりました。

これらの分析結果から、Diary-Converterの堅牢な基盤とモジュール設計を活かしつつ、note-converterの機能（特にOpenRouterクライアント）を取り込む形で、新しい統合プロジェクトを立ち上げるのが最善であると判断しました。

実装内容

本日は具体的なコード実装は行わず、上記の方針決定のための調査、分析、検討に時間を費やしました。

技術的なポイント

統合にあたり、以下の技術的なポイントが重要になると考えられます。

  • LLM APIクライアントの抽象化: GeminiとOpenRouter（将来的には他のAPIも）を切り替えられるように、ファクトリーパターンなどを導入してAPIクライアント部分を抽象化する必要があります。
  • プラットフォームごとの処理分離: Zenn向け、note.com向けなど、プラットフォーム固有の処理（API連携、テンプレート、メタデータ生成など）を明確に分離する設計が必要です。platformsのようなディレクトリを設け、プラットフォームごとのモジュールを配置する案が考えられます。
  • テンプレート管理の拡張: TemplateManagerを拡張し、プラットフォームごとに異なるテンプレートや共通テンプレートを管理できるようにします。
  • 設定管理の統合: 複数のAPIキーやプラットフォーム固有設定を管理する仕組みが必要です。
  • 段階的な移行アプローチ: 既存のプロジェクト（特にCI/CDが稼働しているDiary-Converter）に影響を与えずに統合を進めるため、新規プロジェクトとして立ち上げ、機能を段階的に移植・テストしていくアプローチが有効です。

所感

類似した機能を持つツールが2つ存在することは、以前から気になっていました。今回、それぞれの特徴やコードを改めて比較分析することで、統合の具体的な道筋が見えてきました。

Diary-ConverterはCI/CDパイプラインも整備されており、開発基盤としては安定しています。一方、note-converterで実装したOpenRouterクライアントは、リトライ処理なども含めて比較的よくできています。

それぞれの良い点を活かすためには、やはり新規プロジェクトとして再設計するのがベストだと感じました。特に、既存のCI/CDを壊さずに安全に移行できる「新規プロジェクト立ち上げ」というアプローチを選択できたのは大きな収穫です。これにより、安心して統合後の新しいツールの開発に集中できます。

プロジェクト名は「Content-Converter」や「Markdown-Publisher」などが候補として挙がりましたが、これは追々決めていこうと思います。まずは、新しいリポジトリを作成し、Diary-Converterの基本構造をベースに、LLMクライアントの抽象化やプラットフォーム分離の設計から着手していく予定です。統合によって、今後のコンテンツ変換作業がより一層効率化されることを期待しています。

今後の課題

  • 新しい統合プロジェクト（仮称: Content-Converter）のリポジトリ作成。
  • Diary-Converterの基本構造を新プロジェクトにコピー。
  • LLM APIクライアントの抽象化設計と実装。
  • プラットフォームごとの処理分離のためのディレクトリ構造設計。
  • note-converterからの機能（OpenRouterクライアント等）の移植計画策定。
  • 統合後のテスト戦略の立案。

まとめ

本日は、note-converterとDiary-Converterという2つのMarkdown変換ツールの統合方針について検討しました。両者の機能、コード、開発状況を比較分析した結果、Diary-Converterの安定した基盤を活かしつつ、両者の機能を統合した新しいプロジェクトを立ち上げるという方針を決定しました。この段階的なアプローチにより、既存システムへの影響を最小限に抑えながら、より高機能でメンテナンス性の高いツールへと進化させることを目指します。明日から、新プロジェクトの立ち上げに着手する予定です。

GitHubで編集を提案

Discussion