ローカルLLMとAIエージェントで無料の自動ブログ運営システムをAIで実装したかったが、こころがおれた

はじめに

ローカル LLM で無料で運用の自動ブログを回したかった。

Claude Codeを使って開発を進めていたが、オリジナルの記事がうまくできなかった。バイブコーディングで設計もほどほどに進めていったが、僕の心が先に折れた。

「無料でできたら最高じゃね？」くらいのテンションで始めたが、なんか途中からはもはやよくない進め方をしていた。考えるのとかサボりがちになっていくんだなぁ〜。

ただ本格的にコーディングエージェントを使っての開発？っぽいことをした経験があまりなかったので、いろいろ学べたいい機会だった。

やりたかったこと

• ローカル LLM（Ollama）でコストゼロ・無料での完全自動に。

• Claude Code で計画 → 実装 → テスト → 投稿を一気通貫。なんか、できれば乱雑なメモとか貼って、会話しながら終わっててほしい（現実はそう甘くない）。

• LangGraph で収集・整形・生成・投稿をノードで見える化。

できたこと — 流れは作れた

• Ollama の導入はスムーズ。mac は brew install ollama でいける。

• RSS を拾って、要約から下書き、投稿までひととおり自動で回るようになった。

• LangGraph のノード構成にしたことで、どの工程でコケたかがログからすぐ分かるようになった。

• タスクごとに md を切って、Plan から実装・テスト・レポートまで履歴がきれいに残るようにした。ただし、量が多すぎて斜め読みしかしてない。

できなかったこと

• ほぼモロパクリに見える

  • タイトル・見出しが元記事と激似。中身も多分ほぼ言い換えただけで返ってきた

• いろんなソースから融合して作ろうと思ったがなんか実装できなかった

  • 複数の記事やデータを読ませて、新しい記事を生み出す構想だったが、なんか一つ目の記事にずっと引っ張られてる成果物だった。ちゃんと調べ直せるフローを組んでも、うまく検索できてなかった。

• ログはある、原因追跡に踏み込めない、問題が解決できない

実際にやっていたこと — プロセスと工夫

• タスクごとに Plan → 実装（md駆動）

  • 1タスク＝1ファイルで、Plan を書いてから実装に入る流れ。これはAIエージェントには必要な作業だと思う。

• 自動テスト→レポート→ドキュメント更新

  • テストを書かせて、通ったらレポートを生成してドキュメントを更新。「一定の安心感」と「終わった感」が出るのが良い。ただTDDの理解が浅くうまく使いこなせてなくて、よくなかった点。

• Plan を別エージェント（codex 役）がレビュー

  • Plan を書いたら codex に読ませて、穴を指摘してもらう。内容はだいたい妥当。でも、ClaudeCodeがなんか鵜呑みにしてしまったり、僕自身が思考をサボって判断まで丸投げしてしまう瞬間があった。最終ジャッジはやっぱり人間がやる必要がある。

• 「AIが読めるログ」を出力

  • ログをできるだけ細かく出して、AI が自分で読んで改善できるようにした。方向としては正しかった。けど、設計が薄くて読めるけど使えないログになった。

• レポート→コミットメッセージ→ push

  • 変更理由の可視化は進んだが、品質上下の理由は残らず。履歴は残るけど、学びは残らないっていう、皮肉な結果になった。

なぜ失敗したのか — 原因の仮説

• 多源融合」ができていなかった

  • いろんな記事やデータをまとめて“ひとつの新しい文章”を作らせたかった。

  • 「主張／根拠／反証／結論」のような型（スキーマ）を最初に決めて、AI がどの段階で何を出すのかを明示しておく。混ぜる前に「どんな形にしたいか」を決めておくのが先。

•  コンテキスト肥大

  • セッションを目的ごとに分けて、MCP は本当に必要なものだけ残す。
    全部読み込ませなくても、文脈の切り替えをうまくやれば済む話だった。

• 4. 観測可能性（Observability）の設計不全

  • ログは山ほどあるのに、どの情報がどの段階のものなのか分からない。
    「見えてるのに理解できない」状態。それは観測じゃなくて、ただの記録の墓場だった。

  • 是正：trace_id / stage / token_usage / source_ids / verdict を必須キーに。

• 5. バイブコーディングの限界

  • ノリで進めるのは楽しい。でも、ノリには再現性がない。「あのときなんでそうしたんだっけ？」が誰も説明できなくなる。スピード感と設計の緊張感、両立は難しい。

  •  是正：禁則事項（やらないこと）を設計書の冒頭に貼る。

次やるなら実践ロードマップ

次やるなら、やっぱりまずは全体像から書くところかなぁ。流れが見えないと、AI も人間も迷子になりやすい。スケルトン実装とTDDをうまく使って、関数・モジュールを小さくして実装を進める方が良さそう。

AIに聞いたら「DoD（Definition of Done）を提案されたので、ちょっとそれも入れてみる。

1. 全体像を先に書く（短い設計書）

   • 1ページ設計書（目的・非目的・入出力・評価・倫理） — DoD：A4一枚・レビュー1回・履歴つき。

   • ドメイン設計（用語・ディレクトリ・役割） — DoD：用語10個・各1行説明。

   • データフロー図（RSS→フィルタ→要約→論点設計→シンセシス→執筆→校正→投稿） — DoD：7ノード以内・入出力は1語。

   • 人間のゲート（観点承認・ファクトチェック・公開判定） — DoD：出典/独自性/安全の3基準。

2. パーツは一個ずつ勝たせる

   • 収集：正規化・重複排除・メタ抽出 — DoD：重複率 < 5%・失敗理由を記録。

   • 論点設計：Evidence 単位で「主張/根拠/反証」を YAML に — DoD：主張3・反証1・出典3。

   • シンセシス：YAML を唯一の根拠に独自の観点を差し込む — DoD：各段落示唆1つ。

   • 校正：重複率/言い換え率/出典カバレッジ/レビュー提案 — DoD：数値しきい値で判定。

   • 投稿：要約・OGタグ・内部リンク自動生成 — DoD：公開前に人間承認。

3. コンテキストとログの整理

   • セッション分離 — DoD：チャット履歴を目的別に独立。

   • メモリ削減 — DoD：CLAUDE.md 300行以内、MCP 2個以下。

   • 構造化ログ — DoD：NDJSON（1行1イベント）で時系列復元可。

   • 可視化 — DoD：週次で重複率/手戻り率のPNGを1枚出す。

おわりに

バイブコーディングで心が折れるとは思わなかった。（心が折れるというか、めんどくさくなる瞬間がきて投げ出すことに近い。）

でもそれはAI のせいではない。設計を置き去りにした私のせいだ。（とAIが囁いています。）つぎはちゃんとできるだろう、本当かな。

次はKiroの仕様駆動開発（Spec-Driven Development）なるものがあるらしいので、それ試してみようかな。コマンド操作派はSpec Kit、チャット派はKiro 、とのこと。

あ〜健康になりたい。