2025-03-06 開発日記: LLM APIを活用した開発日記自動変換ツールの実装

この記事はClaude 3.7 Sonnetによって自動生成されています。
私の毎日の開発サイクルについては、LLM対話で実現する継続的な開発プロセスをご覧ください。

LLM APIを活用した開発日記自動変換ツールの実装

はじめに

開発日記をZenn向けに公開する際、ProjectLogsディレクトリに記録した会話ログベースの開発日記を、読みやすいストーリー形式に変換する作業が必要です。この作業を自動化するため、今日はGemini APIを利用した開発日記変換ツールのプロトタイプ開発に取り組みました。

開発の流れ

APIと実装言語の選定

まず、どのLLM APIを利用するか検討しました。コスト面を考慮し、無料利用可能なGoogle Gemini APIを採用することにしました。

実装言語については、CI/CDパイプラインからの実行のしやすさを重視し、以下の理由からPythonを選択しました：

1. Gemini APIの公式Pythonクライアントライブラリが充実している
2. テキスト処理に強く、マークダウンの解析や生成が容易
3. GitHub Actionsでの実行環境が整っている
4. 依存関係の管理が比較的シンプル

ディレクトリ構成の決定

スクリプトを配置するディレクトリ構成について検討しました。フロントエンドやバックエンドとは別の分類となるため、以下のような選択肢を考えました：

1. tools/ ディレクトリ：開発支援ツールやユーティリティスクリプト用
2. scripts/ ディレクトリ：自動化スクリプトやバッチ処理用
3. utils/ ディレクトリ：ユーティリティ機能用

検討の結果、tools/diary-converter/ という構成を採用しました。この構成には以下のメリットがあります：

• 目的が明確（ツールであることがわかりやすい）
• 将来的に他のツールも追加しやすい
• CI/CDパイプラインから参照しやすい
• フロントエンド・バックエンドとは明確に分離されている

スクリプトの実装

次に、以下のファイルを作成しました：

1. diary_converter.py：メインスクリプト
2. requirements.txt：必要なライブラリの一覧
3. README.md：使用方法の説明

diary_converter.py の主な機能は以下の通りです：

def main():
    """メイン処理"""
    args = parse_arguments()
    
    # 開発日記を読み込む
    source_content = read_source_diary(args.source)
    
    # ファイル名から日付を抽出
    date = extract_date_from_filename(args.source)
    
    # デバッグモードの場合
    if args.debug:
        print(f"ソースファイル: {args.source}")
        print(f"抽出された日付: {date}")
        print(f"使用モデル: {args.model}")
    
    # Gemini APIで変換
    converted_content = convert_diary_with_gemini(source_content, date, args.model)
    
    # 変換結果を保存
    save_converted_article(converted_content, args.destination)
    
    print("変換が完了しました")

Gemini APIへのプロンプトには、以下のような変換ルールを設定しました：

1. 「会話ログ」セクションを対話形式からストーリー形式に書き直す
2. 技術的な内容を保持しつつ、読みやすく整理する
3. 「所感」セクションを充実させ、開発者の視点や感想を追加する
4. マークダウン形式を維持し、コードブロックなどを適切に整形する
5. Zenn用のfrontmatterを追加する

今後の課題

今回はプロトタイプとして基本機能を実装しましたが、明日以降に以下の改善を行う予定です：

1. ローカル環境での動作確認
2. 必要に応じたスクリプトの修正・改善
3. CI/CDパイプラインへの組み込み（明後日以降）

所感

Gemini APIを利用することで、開発日記の変換作業を自動化できる見通しが立ちました。特にプロンプトエンジニアリングが重要な要素となり、適切な指示を与えることで質の高い変換が期待できます。

今回はプロトタイプとして基本機能を実装しましたが、今後はエラーハンドリングの強化やバッチ処理機能の追加など、実用性を高める改善が必要だと感じています。

CI/CD環境での実行を考慮し、環境変数でAPIキーを設定する方式を採用しましたが、セキュリティ面でも問題ないか、明日の動作確認で検証していきたいと思います。

明日は実際にスクリプトを動かして変換品質を確認し、必要に応じてプロンプトの調整も行う予定です。自動化によって開発日記の公開プロセスがどれだけ効率化されるか、とても楽しみです。