Zenn
✨

OpenRouter APIクライアント実装とシステム設計の可視化（開発日記 No.045）

に公開
TDD
開発日記
apiクライアント
idea

関連リンク

はじめに

昨日はTDDによる開発基盤を構築し、markdown_utilsモジュールを実装しました。今日は、その基盤を活かしてOpenRouter APIクライアントをTDDで実装し、さらにシステム全体の設計を可視化することに取り組みました。

背景と目的

これまで、LLMを活用したnote記事作成システムの開発を進めてきましたが、LLMとの連携部分の実装がまだでした。OpenRouter APIクライアントを実装することで、システムが実際にLLMと通信し、コンテンツを生成できるようになります。また、システム全体の設計を可視化することで、各モジュールの役割や連携が明確になり、今後の開発や保守が容易になると考えました。

検討内容

OpenRouter APIクライアントの実装にあたり、TDD（テスト駆動開発）を採用することにしました。まずテストケースを定義し、そのテストをパスするように実装を進めることで、品質の高いクライアントを開発できると考えました。また、システム設計の可視化には、モジュール間のデータフロー図、システムのレイヤー構造図、LLM変換処理のシーケンス図などを作成することにしました。

実装内容

まず、OpenRouter APIクライアントのテストファイル tests/unit/test_openrouter_client.py を作成し、以下の主要な機能に関する11個のテストケースを実装しました。

  • API認証とセッション管理
  • プロンプト生成と送信
  • レスポンス処理
  • エラーハンドリング（認証エラー、レートリミット、サーバーエラー）
  • リトライ機能
  • プロンプトフォーマットとトークン制限
  • レスポンス解析

次に、これらのテストをパスするように、scripts/openrouter_client.py にOpenRouter APIクライアントを実装しました。具体的には、以下のクラスとメソッドを実装しました。

  • OpenRouterClient: メインクライアントクラス
  • 各種例外クラス: OpenRouterAPIError, OpenRouterRateLimitError, OpenRouterAuthError
  • 重要なメソッド: generate_text(), format_prompt(), check_token_limit(), extract_content_from_response()

実装後、すべてのテストケースが正常に通過することを確認し、コードカバレッジが90%に達していることを確認しました（docker-compose run --rm test-coverage コマンドを使用）。

また、システム全体の設計を可視化するために、以下の図を作成し、詳細設計書 @Note_Publishing_System_Detailed_Design.md に追記しました。

  1. モジュール間データフロー図: 各モジュール間のデータの流れを明確に表示
  2. システムのレイヤー構造図: UI層、アプリケーション層、ドメイン層、API層、エラー層の構造
  3. LLM変換処理のシーケンス図: ユーザーからの入力から最終出力までの時系列処理

さらに、LLM処理前後のマークダウン処理の意義について、以下の点を説明する節を詳細設計書に追加しました。

  • 処理の責任分離によるモジュール性向上
  • トークン消費の最適化によるコスト削減
  • 出力品質の安定化による一貫性確保
  • カスタマイズ性の向上による柔軟な対応
  • エラーハンドリングの精緻化

技術的なポイント

OpenRouter APIクライアントの実装において、特に重要だったのはエラーハンドリングです。OpenRouter APIは様々なエラーを返す可能性があり、それぞれに対して適切な処理を行う必要がありました。具体的には、認証エラー、レートリミットエラー、サーバーエラーなどを検出し、適切な例外を発生させるようにしました。また、一時的なエラーに対しては、リトライロジックを組み込むことで、システムの可用性を高めました。

所感

今日は、OpenRouter APIクライアントの実装とシステム設計の可視化という、2つの大きなタスクを達成することができました。特に、TDDアプローチでAPIクライアントを実装できたことは、大きな自信につながりました。テストを先に書くことで、実装すべき機能が明確になり、無駄なコードを書かずに済んだと感じています。また、システム設計を可視化することで、システム全体の理解が深まり、今後の開発がよりスムーズに進められるようになるだろうと確信しています。

LLM処理の前後でマークダウン処理を分離することの意義を改めて言語化できたのも大きな収穫でした。この設計判断は、システムの効率性、安定性、柔軟性を高める上で非常に重要だと考えています。

今後の課題

OpenRouter APIクライアントは実装できましたが、まだnote.com APIクライアントの実装が残っています。次回は、note.com APIクライアントの実装に着手し、記事の投稿機能を実装したいと思います。また、エラー処理共通モジュールの実装も検討しており、より堅牢なシステムを目指していきたいと考えています。

まとめ

今日は、OpenRouter APIクライアントの実装とシステム設計の可視化に取り組みました。TDDアプローチによるAPIクライアントの実装、システム設計の可視化、LLM処理前後のマークダウン処理分離の意義の明確化など、多くの成果を得ることができました。これらの成果は、今後の開発を加速させ、より高品質なシステムを構築するための基盤となると確信しています。

GitHubで編集を提案

Discussion