Zenn
🧪

OpenRouter API連携テストとGitHub Actions自動化（開発日記 No.057）

に公開
GitHub Actions
OpenRouter
開発日記
idea

関連リンク

はじめに

昨日は、開発日記をZenn記事に自動変換するシステムの基本機能を完成させ、CI/CDパイプラインの整備を行いました。今日はその最終確認として、実際のOpenRouter APIキーを使ったテスト（今回はエラーケースの確認）と、GitHub Actionsによる自動変換・コミットのワークフローが正しく動作するかを確認します。

背景と目的

開発した日記自動変換システムが、実際のAPI連携シナリオでどのように振る舞うか、特にエラーハンドリングが機能するかを確認することが重要です。また、GitHub Actionsを使って開発プロセスを自動化することで、今後の開発効率を向上させ、システムの信頼性を確保することを目指します。具体的には、開発日記ファイルをリポジトリにプッシュするだけで、自動的にZenn記事の雛形が生成・コミットされる状態を目指します。

検討内容

まず、システムがOpenRouter APIキーをどのように扱っているか、コード (note_converter.py, openrouter_client.py) を再確認しました。設計通り、環境変数 OPENROUTER_API_KEY からキーを取得する仕組みになっていることを確認しました。

次に、テストのステップを考えました。いきなり有効なAPIキーを使うのではなく、まずは以下の手順を踏むことにしました。

  1. ドライラン実行: スクリプト全体の流れやファイルパスなどに問題がないかを確認します。
  2. ダミーAPIキーでの実行: 無効なAPIキーを設定して実行し、API認証エラーが想定通りに発生するか、そしてエラーハンドリングが機能して処理が継続されるかを確認します。
  3. GitHub Actionsワークフローの設計: どのようなトリガーで、どのようにシークレットを扱い、どんな処理（変換とコミット）を実行するかを具体的に検討しました。

実装内容

検討した内容に基づき、以下の実装とテストを行いました。

APIキーテスト

  1. ドライラン実行:
    スクリプトをドライランモードで実行し、特にエラーが発生せず、処理の流れが正常であることを確認しました。

  2. ダミーAPIキーでの実行:
    環境変数 OPENROUTER_API_KEY にダミーの文字列を設定し、スクリプトを実行しました。予想通り、OpenRouter APIへの接続時に認証エラーが発生しました。

    ERROR - LLM API呼び出しエラー: Authentication failed: {"error":{"message":"No auth credentials found","code":401}}

    このエラーが発生してもスクリプトは停止せず、最終的に note-articles/ ディレクトリに新しい記事ファイルが生成されました。ファイルの中身を確認すると、「APIエラーが発生しました」というメッセージと共に、元の開発日記の内容がそのまま含まれていました。これは、APIエラー時でも元のコンテンツを失わずに処理を継続するという、意図したエラーハンドリングが機能していることを示しています。

GitHub Actionsワークフロー作成

次に、この変換プロセスを自動化するためのGitHub Actionsワークフローファイル (.github/workflows/note-converter.yml) を作成しました。

このワークフローの主な機能は以下の通りです。

  • トリガー:
    • Docs/dev-records/ ディレクトリ内のファイルが変更され、main ブランチにプッシュされた時。
    • 手動実行 (workflow_dispatch) も可能で、その際には対象の開発日記ファイルを指定できます。
  • シークレット管理:
    • OpenRouterのAPIキーは、GitHubリポジトリのSecretsに OPENROUTER_API_KEY という名前で登録し、ワークフロー内で環境変数として読み込みます。
    • セキュリティ向上のため、シークレットを production という名前のEnvironmentに関連付けました。これにより、将来的には承認フローなどを追加することも可能です。
  • 実行処理:
    • 指定された開発日記ファイルを note_converter.py スクリプトで処理します。
    • 生成された記事ファイルを note-articles/ ディレクトリに配置します。
    • 変更を自動的にコミットし、リポジトリにプッシュします。

これで、リポジトリに有効なAPIキーをSecretとして設定すれば、開発日記を Docs/dev-records/ に追加してプッシュするだけで、自動的にZenn記事の雛形が生成される準備が整いました。

技術的なポイント

今回の実装における技術的なポイントは以下の通りです。

  • APIキーの安全な管理: 環境変数とGitHub Secretsを利用することで、APIキーをコード中にハードコーディングすることを避け、安全に管理できるようにしました。
  • 堅牢なエラーハンドリング: OpenRouter APIの呼び出しで認証エラーなどが発生した場合でも、処理を完全に停止させるのではなく、エラー情報を記録しつつ元のコンテンツを保持したファイルを生成するようにしました。これにより、APIの一時的な問題などで変換が失敗しても、手動でのリカバリーが容易になります。
  • GitHub Actionsによる自動化:
    • paths フィルターを使った特定ディレクトリ変更トリガー。
    • workflow_dispatch による手動実行と入力パラメータの活用。
    • environment を利用したシークレットの保護。
    • actions/checkout や git コマンドを使った自動コミット・プッシュの実装。

所感

昨日構築したシステムが、実際のAPI連携（今回は意図したエラーケースですが）やGitHub Actionsによる自動化の文脈でどのように動作するかを具体的に確認できて、非常に満足しています。

特に、ダミーキーを使ってエラーハンドリングの動作を事前に確認できたのは大きな安心材料です。いきなり本番キーで試して予期せぬエラーに遭遇するリスクを減らせました。

GitHub Actionsのワークフロー設定は、YAMLの記述など少し慣れが必要ですが、一度設定してしまえば、開発日記を書く→プッシュする、という簡単な操作だけで記事生成が自動化されるため、今後の開発体験が格段に向上すると期待しています。production 環境を使ったシークレット管理も、セキュリティを意識した開発プラクティスとして良い学びになりました。

これで、あとは本物のAPIキーを設定するだけで、開発日記が自動でZenn記事に変換される未来が見えてきました！

今後の課題

  • 本番APIキーでの最終テスト: 実際に有効なOpenRouter APIキーをGitHub Secretsに設定し、ワークフローがLLMによる変換を正常に実行し、期待通りの記事が生成されるか最終確認が必要です。
  • 生成記事の品質確認: 自動生成された記事の内容が適切か、プロンプトの調整が必要ないかを評価します。
  • 手動実行UIの改善: workflow_dispatch でファイル名を指定する方法が、長期的に見て使いやすいか検討の余地があります。

まとめ

今回は、開発した日記自動変換システムの最終確認として、OpenRouter API連携のテスト（エラーハンドリング確認）と、GitHub Actionsによる自動化ワークフローの構築を行いました。ダミーAPIキーを用いたテストでエラーハンドリングの有効性を確認し、GitHub Actionsワークフローを作成することで、開発プロセス自動化の基盤を整えることができました。次のステップは、実際のAPIキーを設定して本番環境での動作を確認することです。

GitHubで編集を提案

Discussion