はじめに：5つの工程を、毎回手動でこの順番に呼んでいた

これまで2本の記事で、ブログ記事執筆のためのAIエージェント自動化パイプラインを紹介してきました。テーマから企画を立てるblog-plan、見出し構成を設計するblog-design、設計書を懐疑的にレビューするblog-verify、本文を執筆するblog-write、そして校閲と公開を担うblog-review。この5つのスラッシュコマンド（プロジェクトスキル）が揃ったことで、1本の記事ができるまでの品質は着実に上がってきました。

ただし、便利になったはずの仕組みに、新しい不便さも生まれていました。5つのスキルを、毎回この順番通りに手動で呼び出す必要があったのです。工程が2〜3個のうちは順番を覚えていられても、5個ともなると「次はどれを呼ぶんだったか」を都度思い出す負担が出てきます。体感の話にはなりますが、1本の記事を仕上げるのに最低5回のコマンド入力が必要という事実だけは、はっきりしていました。

そこで今回、この5工程を1回の呼び出しでまとめて実行するblog-pipelineというオーケストレータースキルを追加しました。今回はその設計判断についてお話しします。

「一つのことをうまくやる」を、スキル設計の土台にした

5つの専門スキル：plan → design → verify → write → review

このパイプラインは、最初から5工程だったわけではありません。まず4工程（企画・設計・執筆・校閲）でスタートし、前回の記事で紹介した通り、設計書を懐疑的にレビューするblog-verifyが後から追加されて5工程になりました。段階的に育ってきた仕組みです。

ただし、その「増え方」には一貫した姿勢があります。新しい工程を足すときも、既存工程の中身には手を入れず、独立した一つのスキルとして切り出す。今回追加したblog-pipelineもそうで、以下のようにそれぞれの役割は一つずつに絞られています。

  • blog-plan：テーマからペルソナ・slug・企画書を作る
  • blog-design：企画書から見出し構成とセクション要点を設計する
  • blog-verify：設計書の主張を懐疑的にレビューし、進行可否を判定する
  • blog-write：設計書に基づいて本文を執筆する
  • blog-review：校閲・重複チェックをして公開する

UNIXの哲学としてよく知られる「一つのことをうまくやる」という考え方を、そのままスキル設計に当てはめた形です。そして今回のオーケストレーター追加にあたっても、この5つのスキルのファイル（SKILL.md）は一切変更していません。blog-pipeline自身の本文にも「既存5スキルのSKILL.mdは一切変更しません」と明記されています。分業の単位そのものは、今回変更する対象ではなかったということです。

車は一つの工場で作らない

この構造は、車の製造を思い浮かべるとイメージしやすいかもしれません（例えとしては大きすぎるかもしれませんが）。車はエンジン、ハンドル、タイヤなど、多様な部品の組み合わせでできています。しかし、それらすべてを一つの工場で作るわけではありません。それぞれ得意な工場で部品を作り、最終的に組み立てラインで一台の車に仕上げます。

今回の構造もこれと同じです。blog-planからblog-reviewまでの5つのスキルが「部品工場」、そして新しく追加したblog-pipelineが「組み立てライン」にあたります。部品工場を無理に統合しても、部品そのものの品質が上がるわけではありません。むしろ部品工場は部品作りに専念させ、組み立てラインだけを別に用意する方が、変更の影響範囲を小さく保ちやすいと考えています。

工程は変えずに、繋ぎ方だけを後から足す

生成物が、次の工程の入力になる

このパイプラインは、各工程がファイルを生成し、次の工程がそのファイルを読み込んで動く、というファイルベースの構造になっています。specs/blog-posts/<slug>/というディレクトリの下に、plan.md→design.md→verify.md→draft.md→review.mdの順で成果物が積み上がっていき、最終的に校閲を通過した記事だけがsrc/content/blog/<slug>.mdとして公開されます。この公開ディレクトリへの書き込みができるのはblog-reviewだけ、という役割分担も、疎結合な設計の一部です。

次に何をすべきかを、ファイルの状態から判定する

今回追加したblog-pipelineは、この「部品工場」たちを呼び出す順番を、人間の記憶に頼らずファイルの状態から自動判定する仕組みです。各工程のファイルの有無と更新時刻を見て、次に呼ぶべきスキルを決める12行の決定表を本文に持っています。たとえば「plan.mdが無ければblog-planを実行する」「verify.mdの判定が要修正で、かつ試行回数が3回未満なら自己修正へ進む」「src/content/blog/<slug>.mdが存在すれば完了」といった具合です。

呼び出し時の引数（/blog-pipeline <テーマ または slug>）についても、対応するディレクトリが既に存在するかどうかで、新規テーマとしてblog-planから始めるのか、途中のslugとして状態判定から再開するのかを自動で切り分けます。実際に、blog-verifyの直後で作業を止めた状態からこのオーケストレーターを起動し、blog-planとblog-designを正しくスキップしてblog-verifyから再開できることも確認済みです。UNIXのパイプ（|）が標準出力を次のコマンドの標準入力に繋ぐように、このオーケストレーターはファイルシステム上の状態を使って工程同士を繋いでいます。

「要修正」は人間を呼ばずに、まず自分で直させる

前回の記事で、blog-verifyは設計書の事実や主張を懐疑的にレビューし、「進行可」か「要修正」かを判定する仕組みだと紹介しました。今回のオーケストレーターは、この「要修正」判定が出たときも人間をすぐには呼びません。まずは指摘の内容に沿ってdesign.md（blog-review側であればdraft.md）をオーケストレーター自身が編集し、再検証させます。ただしこの自己修正は無制限ではなく、工程ごとに最大3回までです。実際、意図的に曖昧で反証不可能な主張を仕込んで「要修正」を発生させたテストでは、指摘に基づいてdesign.mdを修正し、1回の再検証（3回の上限内）で「進行可」まで通過させることを確認しています。

もう一つ気をつけたのが、人間が手直しした場合の扱いです。design.mdやdraft.mdの更新時刻が判定ファイルより新しくなっていれば、それは人間が直接修正した合図と見なし、オーケストレーターは無修正のまま再検証だけを行います。この場合は自己修正の試行回数を増やしません。人間の介入を、AIの失敗回数と混同させないための配慮です。

そして3回失敗した場合は、それ以上の自動修正はせず、直近の指摘事項全文・これまでの修正内容の要約・次に人間が取るべきアクションを添えて停止します。自律性と、暴走させないための歯止め、その両方を仕組みとして組み込んだつもりです。

まとめ：疎結合な工程は、壊さずに束ねられる

今回の変更で行ったのは、既存5スキルの中身に一切手を入れず、それらを束ねる薄いレイヤーを後から追加しただけです。それだけで、冒頭で挙げた「順番を覚える負担」「毎回5回の入力」という運用上の不便さは、うまくいけば1回の呼び出しで完結するところまで改善できました（自己修正が3回失敗した場合は、人間の介入と再実行が必要になります）。

これができたのは、そもそも各工程を「一つのことをうまくやる」独立した単位として切り出していたからだと考えています。工程同士が疎結合であれば、後から統合のためのレイヤーを足すときも、既存の部分を壊さずに済みます。ブログ執筆パイプラインに限った話ではなく、業務プロセスを言語化し、専門化された単位に分業させ、それらを繋ぐレイヤーは別に用意する——この考え方は、他の業務自動化の場面にも応用できるはずだと考えています。

私は、品質とプロセス設計に一切妥協しないシステムエンジニアリングを提供しています。AIを活用した高度な業務自動化や、堅牢なシステム設計に関心がある方は、ぜひコンタクトフォーム、またはSNSからお気軽にご相談ください。