この一連の記事は、実は一つのことを伝えたいのです。AI によるブログ執筆は、単なるプロンプト一つに頼るだけでは限界が来ています。今回の記事ではまず blog-writer がなぜ生まれてきたのかを説明します。次の記事では AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（2）：blog-style-suite でスタイル学習とトークンコストをどう分離するか を続けます。そして最終回は AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（3）：ローカルモデル、オンラインモデル、Minimax は最後にどう分業するか で締めくくります。

本当に面倒なのは、原稿を書くことではなく、あの一連の機械的な動作だ

初期のワークフローは、端的に言えば外部委託されたパイプラインのようだった。 私自身がまず問題を明確にするか、あるいは大まかなアウトラインを立てる。モデルが本文を骨子として展開する。その後、人間が戻ってきて残りの公開作業を補完する。

• ローカルの md にコピーする
• title、date、slug を補完する
• タグとカテゴリを入力する
• <!--more--> を補完する
• 参考資料を整理する
• どのディレクトリに配置するかを決定する この一連の作業は、一つ一つのステップを見れば難しくはないが、繋げると非常に面倒だ。面倒なのは技術的な難しさではなく、それらがすべて機械的であるにもかかわらず、やらざるを得ない点にある。 だからこそ、私は後になって、「[コマンドラインベースのAIコーディングインタラクション](/ja/p/command-line-ai-coding-interaction/）」のような変化は、単に「入り口が変わった」だけではないと感じるようになった。AIがリポジトリ内で直接ファイルの読み書きができるようになった今、ブログ執筆がまだ「本文をローカルドキュメントにコピーする」レベルに留まっているとしたら、ワークフロー全体がすでに時代遅れになっているのだ。

blog-writer 最初の価値は文体ではなく、契約を固定化すること

blog-writer の最も初期のノードは、2026年4月1日17:00の 991536a です。gitコミット履歴を見ると、このバージョンではすでに SKILL.md、write_post.py、そして一連の初期のスタイル資料が組み込まれています。

しかし、後から振り返ってみると、このドラフトの最も価値のある点は「AI が私の文体を学んだ」ことではなく、執筆の契約を固定化したことです。

「契約を固定化する」とはどういうことか？

• 入力には最低限、アウトラインとファクトアンカー（事実の錨点）が必要であること
• 出力は必ず完全なMarkdown形式であり、未完成品であってはならないこと
• frontmatter は人手に頼ることはできないこと
• 記事はチャットウィンドウ内に留まるのではなく、直接 content/post に配置されること

この点は非常に重要です。なぜなら、プロンプト自体が不安定だからです。「以前のように書いて」と今日言っても、それはトーンが少し似ていると解釈されるかもしれません。明日もう一度同じことを言っても、表面的な構文しか学べないかもしれません。しかし、それが Skill として書かれると、ルールは「その場での即興」から「固定された工程」へと変わります。

後続のいくつかのノードも、実質的にこの契約を補強し続けています。

2026年4月2日22:54の 8eb735a では、著者フィールド、執筆に関する注記、元のプロンプトなどが固定されました。この段階に至ると、ブログ記事の完成は単に「本文が書き終われば完了」ではなくなり、メタ情報、トレーサビリティ（追跡可能性）、公開される注記までが標準化されたのです。

したがって、blog-writer の最初の価値は、モデルをより文章を書くのが上手に見せかけることではなく、執筆という行為自体に、再現可能な境界線を持たせたことなのです。

シリーズ形式は、実は執筆の契約をさらに一歩進めたもの

単発の記事で安定して書けるようになると、次の問題がすぐに浮上します。 あるテーマは、そもそも一つの記事に詰め込むのが適していません。無理に詰め込もうとすると、結局は情報量が多すぎてメインの筋が散漫になり、どの点も深く掘り下げきれない長文になってしまいがちです。 これが、2026年4月2日 23:55 の 1a5604e が重要だった理由です。あの時、シリーズ形式と write_post_series.py をまとめて追加しました。記事間は relref で繋ぎ、一括書き込みの際に統一的に置換するようにしたのです。 これは単なるファイル生成スクリプトの小さなアップグレードに見えますが、実際はそうではありません。 それは一つのことを示しています。執筆の工程化は、「この一篇をどう生成するか」だけを考える段階から、「この一連のコンテンツをどう安定して配置し、順序をどう保証し、サイト内で相互にリンクさせるか」という視点に移ってきたということです。 翌日の2026年4月3日 09:29 の 04dccb9 は、この件をさらに一歩進めました。シリーズ記事のタイムスタンプが分単位で増加し、もはや共通の時間を使用しないようにしたのです。この変更は非常に小さいものですが、エンジニアリング的な深みがあります。なぜなら、Hugoのリストページ、前後の記事リンク、シリーズの順序といった「実際の問題」を解決しているからです。 端的に言えば、シリーズ形式というのは、格好良く見せるためではなく、「複数の記事をまとめて公開する」という作業が、もはや手動でのフォローアップに頼らなくて済むようにするためなのです。

しかし、単一のスキルだけでは、後でトークン制限にぶつかることになる

問題はここにあります。 文体学習を真剣に行い始めると、blog-writer のコンテキストがすぐに肥大化します。ただ書くだけでなく、以前あなたのように書くことも期待するわけです。最も自然な方法は、過去の記事も一気に詰め込むことです。 これなら、一度だけは実行できます。 しかし、たまに記事を書くだけではなく、長期的なワークフローにしたいと思うと、すぐに問題が発生します：

• トークン消費量が高い
• 毎回同じ古い記事を繰り返し与えることになる
• モデルの注意力が古い材料によって希釈される
• 原稿執筆とスタイル維持が絡み合い、どちらも容易ではない ここから、私はblog-writerは、すべてを任せる側（生成側）というよりは、消費する側として使う方が適していることに気づき始めました。 原稿執筆という動作は、できるだけ軽く、直接的に、そしてできれば公開されたバージョンのみを参照するようにすべきです。一方、スタイルデータの生成方法、選別方法、圧縮方法は、別の生産側のパイプラインの問題なのです。この判断が、私を次のステップへと導き、それがAIでブログを書くという件は、結局エンジニアリングにする必要がある（2）：blog-style-suiteでスタイル学習とトークンコストをどう分離するかへと繋がりました。

まずプロセスを安定させてから、スタイルやモデルについて語る資格が生まれる

今振り返ると、blog-writer が生まれたのは、私が突然ブログライティングアシスタントを作りたいと思ったからではない。 むしろ、これまでのワークフロー自体が、新しい働き方に合わなくなってきたことが原因だ。 Codex のようなツールがインターネットに接続して資料を補完できたり、リポジトリ内での読み書きができたり、スクリプトを直接呼び出せるようになった場合、「ブログを書く」という行為は「本文をローカルドキュメントにコピーする」という段階で止まっているべきではない。この部分を自動化しなければ、かえって全体のプロセスの中で最も非効率な工程になってしまう。 そのため、最初の記事の結論はここまでとする。 blog-writer が最初に解決したのは、文体ではなく、公開作業における反復的な手作業だった。このレイヤー（層）という契約がなければ、後からトークンやデータ構造、ローカルモデルについて語っても、実際には根拠がない。

参考資料

• リポジトリコミット：991536a237d04aba7c44dec501b3d98c644040c8
• リポジトリコミット：8eb735aa8448c97deb2af1ea46b86772008fa9e3
• リポジトリコミット：1a5604e7e6ce0a13f260fcbb8c2c1d964cdd0892
• リポジトリコミット：04dccb98c55a6ea3b81408012b33a6219cf8ab77
• リポジトリファイル：.agents/skills/blog-writer/SKILL.md
• リポジトリファイル：.agents/skills/blog-writer/scripts/write_post.py
• リポジトリファイル：.agents/skills/blog-writer/scripts/write_post_series.py

作成上の注記

元のプロンプト

$blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その時は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づきました。そこで、これらの作業を自動化するスキルを作成できないかと考えたのが、skill blog-writer の初稿です。さらに、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したスキルでした。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それが blog-style-suite の誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いと感じたため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考え、minimaxとも連携させました。blog-style-suite と blog-writer の進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルの blog-writer および blog-style-suite のコードを基にして、設計思想や、どのようにトークン節約を実現したか、データ構造はどう設計したか、といった核となる設計思想について説明することができます。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。

ライティングのアイデア概要

• 最初の記事はワークフローのトリガーポイントに焦点を当て、トークンとモデルの役割分担を急ぎすぎず、3つの記事でメインテーマを奪い合うのを避ける。
• 「本文自体は難しくないが、公開前後の一連の機械的な作業が面倒である」という判断を重点的に残した。
• 991536a、8eb735a、1a5604e、04dccb9 などのノードを通じて、「プロセスを契約化する」ことを実際のGitの進化に落とし込む。
• シリーズ形式はこの記事で取り上げることで、ブログ執筆が単発の記事生成から一連の成果物（セット）へと移行したことを示すためである。
• 最後に意図的に問題をトークンウォールに引きつけ、次の記事でのデータエンジニアリングと前処理のための布石とする。