note API投稿断念とMarkdown自動生成への方針転換（開発日記 No.055）

この記事はgemini-2.5-pro-exp-03-25によって自動生成されています。

関連リンク

• 前回の開発日記

はじめに

昨日は note API を利用した記事の自動投稿機能の実装を目指していましたが、残念ながら技術的な課題をクリアできず、このアプローチを断念することにしました。そこで本日は方針を転換し、記事の Markdown ファイルを自動生成して特定のフォルダに保存する、という部分までの自動化に取り組むことにしました。

背景と目的

当初の目標は、開発日記から note への記事投稿までを完全に自動化することでした。しかし、note API との連携が想定以上に複雑で、安定した動作を実現することが困難であると判断しました。
このまま API 連携に固執して時間を浪費するよりも、実現可能な範囲で自動化のメリットを享受する方が現実的です。そこで、記事作成の元となる Markdown ファイルの生成と整理を自動化し、note への投稿自体は手動で行うという、よりシンプルな運用フローに切り替えることにしました。目的は、手動投稿の手間を可能な限り削減しつつ、安定した記事作成プロセスを確立することです。

検討内容

API 経由での投稿が難しいと判断した後、いくつかの選択肢を検討しました。

1. 完全手動: 自動化を諦め、すべて手作業で行う。
2. Markdown生成のみ自動化: 既存の変換処理を活かし、Markdown ファイルの生成までを自動化する。

開発効率と実現可能性を考慮した結果、2番目の案を採用することにしました。既存の Markdown 変換スクリプト (note_converter.py) は十分に機能していたため、これを流用し、API 連携に関する部分のみを削除するのが最も効率的だと考えました。
また、生成された Markdown ファイルをどこに、どのようなファイル名で保存するかも検討しました。後で管理しやすいように、リポジトリ内に専用の note-articles/ フォルダを作成し、YYYYMMDD_title.md という命名規則で保存することに決定しました。
さらに、プロジェクトをシンプルに保つため、今回不要となった note API 関連のスクリプト、設計書、テスト結果などは、混乱を避けるためにすべて削除することも決めました。

実装内容

上記の方針に基づき、以下の作業を行いました。

1. API 連携コードの削除:
   • note_converter.py スクリプトを開き、note API への接続、認証、投稿処理に関連する関数やコードブロックを削除しました。
2. Markdown 保存処理の変更:
   • スクリプトに、変換後の Markdown ファイルを指定したフォルダ (note-articles/) に保存する処理を追加しました。フォルダが存在しない場合は自動的に作成するようにしました。
   • ファイル名は、記事の日付とタイトルから YYYYMMDD_title.md 形式（例: 20250424_api投稿断念とmarkdown生成.md）で生成するようにしました。タイトルに含まれるスペースや特殊文字は、ファイル名として使えるように適切に処理するロジックも加えました。
3. 不要ファイルの削除:
   • Git リポジトリから、note API 連携のために過去に作成した以下のファイルを git rm コマンドなどを使って削除しました。
     • API 連携用スクリプト（note_uploader.py など）
     • 関連する設計ドキュメント
     • API 連携部分のテストコード
     • README ファイル内の API に関する記述
4. 運用フローの確定:
   • 今後の記事作成フローを「LLM による開発日記変換 → note-articles/ フォルダへの Markdown 自動保存 → 手動で note にコピー＆ペーストして投稿」と定めました。

技術的なポイント

• 既存コードの再利用: 完全に動作していた Markdown 変換ロジックをそのまま流用することで、開発工数を大幅に削減できました。
• ファイルシステム操作: Python の os モジュールや pathlib モジュールを利用して、ディレクトリの存在確認・作成、ファイルパスの生成、ファイルへの書き込みといった基本的なファイルシステム操作を実装しました。
• 不要機能の整理: 単にコードをコメントアウトするのではなく、関連するドキュメントやテストも含めて完全に削除することで、プロジェクトの複雑性を低減し、将来的なメンテナンス性を向上させました。

所感

note API を使った完全自動投稿を実現できなかったのは、正直少し残念です。せっかくなら最後まで自動化したかったという思いがありました。しかし、技術的な壁にぶつかったときに、固執せずに代替案へスムーズに方針転換できたのは良かった点だと思います。「できない」ことを早めに見極め、実現可能な範囲で最善の策を取るという判断は、今後の開発でも活かせる経験になりました。
不要になったコードやドキュメントを整理する作業は、思った以上に気持ちが良いものでした。物理的な掃除と同じで、デジタルな情報も整理することで頭の中がスッキリし、プロジェクト全体の見通しが良くなったように感じます。やはり「シンプル・イズ・ベスト」ですね。

今後の課題

• Markdown 品質の向上: 自動生成される Markdown が、note のエディタで意図した通りに表示されるか、継続的に確認し、必要に応じてフォーマット（特に改行やコードブロックなど）を調整する必要があります。
• 手動アップロード手順の明文化: 新しい運用フローにおける手動アップロードの手順や注意点を、忘れないように README などに明確に記載しておく必要があります。
• CI/CD パイプラインの整備: 明日以降のタスクですが、コード変更時のテストやビルド、そして将来的には他の自動化プロセス（例えば Zenn 記事の生成など）を組み込むための CI/CD パイプライン整備は、引き続き重要な課題です。

まとめ

本日は、note API 経由での記事自動投稿を断念し、代わりに Markdown ファイルを自動生成して専用フォルダに保存する仕組みを構築しました。既存の変換処理を活かしつつ、API 関連部分の削除と保存処理の変更を行い、運用フローをシンプル化しました。これにより、完全自動化は達成できなかったものの、手動での記事投稿の手間を軽減するという当初の目的の一部は達成できました。今後は、生成される Markdown の品質改善や、CI/CD パイプラインの整備を進めていく予定です。