Zmsoft
ENJA
•••
ARDEESFRHIINPT-BRROTRUKVIZH-CNZH-TW
ObsidianのAI相談ログをWordPressに自動投稿するパイプラインを作った

ObsidianのAI相談ログをWordPressに自動投稿するパイプラインを作った

ObsidianのAI相談ログをWordPressに自動投稿するパイプラインを作った

はじめに

AIと技術的な相談をしていると、「この会話、後で役に立ちそうだな」と思う瞬間がある。しかし実際には、チャット履歴は埋もれていくだけで、ナレッジとして活かせていないことが多い。

この記事では、ObsidianにコピペしたAI相談ログを自動でブログ記事化し、WordPressに下書き投稿するパイプラインの設計と実装ポイントを紹介する。同じ課題を抱えている人の参考になれば幸いだ。

パイプラインの全体像

処理の流れはシンプルに4ステップに分けられる。

  1. Input — ObsidianのInboxフォルダにチャットログをMarkdownとして保存
  2. Trigger — ファイル変更を検知して処理を起動
  3. Process — Claude APIでログをブログ記事フォーマットに変換
  4. Output — WordPress REST APIで下書きとして自動投稿
Obsidian (Markdown)
  └─ watchdog（ファイル監視）
       └─ Claude API（記事変換）
            └─ WP REST API（下書き投稿）

技術スタックの選定

ファイル監視：Python watchdog

Pythonのwatchdogライブラリは、指定ディレクトリの変更イベントをリアルタイムで検知できる。Obsidianが保存するたびにイベントが発火するため、トリガーとして最適だ。

from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler

class MarkdownHandler(FileSystemEventHandler):
    def on_created(self, event):
        if event.src_path.endswith(".md"):
            process_file(event.src_path)

observer = Observer()
observer.schedule(MarkdownHandler(), path="./inbox", recursive=False)
observer.start()

記事変換：Claude API

ログをそのまま投稿するのではなく、Claude APIに「記事化プロンプト」を渡して整形する。ここでのポイントは記事フォーマットを事前に決めておくことだ。

  • Q&A形式で残す → 対話の流れが伝わりやすい
  • 要約記事にする → スキャンしやすく読みやすい
  • ハイブリッド → 導入＋Q&A抜粋＋まとめ

プロンプト例：

prompt = f"""
以下のAI相談ログをもとに、技術ブログ記事を書いてください。
- H2/H3見出しを使う
- コードブロックを適切に使う
- タグを3つ提案する
- 出力形式: JSON {{ "title": "", "content": "", "tags": [] }}

---ログ---
{raw_log}
"""

WordPress投稿：REST API

WP REST APIを使えば、外部からプログラムで投稿が可能だ。認証にはApplication Passwordを使うのが現在のベストプラクティスとなっている。

import requests
import base64

def post_to_wordpress(title, content, tags):
    credentials = base64.b64encode(b"username:app_password").decode("utf-8")
    headers = {"Authorization": f"Basic {credentials}"}
    
    payload = {
        "title": title,
        "content": content,
        "status": "draft",  # 必ず下書きで投稿
        "tags": tags,
    }
    
    response = requests.post(
        "https://example.com/wp-json/wp/v2/posts",
        json=payload,
        headers=headers,
    )
    return response.json()

設計で迷いやすいポイント

ログの「そのまま感」をどこまで残すか

AIとのやり取りには、試行錯誤の過程が含まれている。それを全部整形してしまうと、「なぜその結論に至ったか」という文脈が失われる。Q&A形式を一部残すことで、読者が追体験しやすい記事になる。

タグ・カテゴリの自動付与

Claude APIのレスポンスにタグ候補を含めておくと、手動作業をゼロにできる。ただし精度が安定しないうちは、投稿ステータスをdraftにして人間がレビューする運用が安全だ。

二重処理の防止

watchdogはファイル保存のたびにイベントを発火するため、同じファイルを複数回処理してしまうケースがある。処理済みファイルを記録するDB（SQLiteで十分）かファイルのハッシュ管理で防ぐとよい。

まとめ

このパイプラインの肝は「記事の出力フォーマットを先に決める」ことだ。フォーマットが決まれば、プロンプト設計もコード実装もスムーズに進む。

最初からすべてを自動化しようとせず、変換→レビュー→手動公開のフローで始めて、品質が安定してきたら自動公開に切り替えるアプローチが現実的だ。AIとの会話は、整理すれば十分ブログ記事になるクオリティを持っている。埋もれさせるのはもったいない。