コンテンツ管理の分離：なぜ技術記事とエッセイを分けるのか

ブログの裏側の話をします。 A3roプロジェクトでは、コンテンツ管理ディレクトリを意図的に2つに分けています。

• projects/: 技術記事（A3ro.cc用）
• note/: エッセイ（note.com用）

最大の理由はシンプルで、「noteには記事投稿APIが存在しないから」です。

APIがないなら、管理フローを分けるしかない

技術記事（projects/）は、GitHubにPushすれば自動でデプロイされる「完全自動化」の世界です。 manager.py がMarkdownを解析し、画像をR2に上げ、Astroに引き渡す。これが理想的なCI/CDです。

しかし、noteへの投稿はこのルートに乗せられません。APIがない以上、どうしても「ブラウザを開いてコピペする」という手作業が発生します。 自動デプロイされるディレクトリの中に、手動でしか出せない原稿が混ざっていると、管理スクリプトが無駄に複雑になります。 「自動化できるもの（projects）」と「できないもの（note）」を物理的に分ける。これが最もミスのない解決策でした。

ディレクトリ構造が表す「距離感」

projects/ は web/ ディレクトリ（Astro本体）と同じシステムの一部として扱います。

A3ro/
├── web/       (System)
├── projects/  (Content with Auto-Deploy)
└── note/      (Content for Manual-Post)

逆に note/ はシステムから切り離されています。たとえ明日A3ro.ccの構成が変わろうとも、note/ の中身はMarkdownアーカイブとしてそこにあり続けます。 この「システムへの依存度の違い」をディレクトリ階層で表現するだけで、エージェント（AI）に対しても「ここは自動処理の対象」「ここはアーカイブ」という指示が明確になります。

まとめ

• projects/: manager.py で自動処理する場所。
• note/: 人間が手動で扱う場所。

API制限というネガティブな理由から始まった分離ですが、結果として「技術」と「思想」の管理場所が整理され、メンテナンス性が向上しました。