[エージェント設計 #3] AIコンテンツパイプライン設計、生成から公開まで

AIコンテンツ生成を一発プロンプトではなく、生成・レビュー・アセット作成・公開という独立した工程に分ける設計です。工程ごとの出力スキーマの固定、別工程でのレビュー、失敗時にも原本を保持する構造を整理します。

SeokWoo LeeシニアiOSソフトウェアエンジニア公開 2026年8月14日更新 2026年8月26日読了 5 分

AIでコンテンツを作ると聞くと、たいてい「一発プロンプト」を思い浮かべます。しかし一発で生成した成果物は品質にばらつきがあり、結局は人がすべて手直しすることになります。

発想を変えて、生成を工場のラインのように段階へ分けてみてはどうでしょう。下書き生成、品質レビュー、画像生成、公開をそれぞれ独立した工程にし、工程の間に検証を挟みます。

この構造でブログ記事の制作を自動化したパイプラインを実際に運用し、得られた設計原則をまとめました。特定ドメインの事例ですが、構造自体はあらゆるAI自動化に移植できます。

この記事では、パイプラインの段階構成、段階間の検証機構、失敗処理の設計まで整理します。

まずは要点から見ていきましょう。

段階分離、一発生成との決定的な違い

パイプラインの骨格は次のとおりです。

キーワード入力 → 本文生成 → 文体レビュー（推敲） → 画像生成 → 保存 → 公開。各段階は前段階の出力だけを入力として受け取る独立した工程です。

一発生成と比べた利点は3つあります。

モジュール化シリーズで扱った凝集度・結合度の原則をそのまま適用できます。一緒に変わるロジックをまとめ、工程間はスキーマで通信します。

段階分離を成立させるには条件が1つあります。各段階の出力が検証可能な形式であることです。

このパイプラインでは、本文生成段階の出力スキーマを「タイトル候補配列＋本文＋画像プロンプト配列＋タグ配列」に固定しています。本文中の画像位置は、[画像マーカー]のような規約で示します。

スキーマを固定すると、パイプラインコードはLLMの出力を信頼するのではなく、検証できるようになります。

LLMをパイプラインに組み込んだ瞬間、出力は「信じるもの」ではなく「検証するもの」になります。スキーマはその検証の基準線です。

興味深いのは文体レビューの段階です。AIが書いた文章には、均一なリズム、翻訳調、機械的な並列構造といった特有の癖が残ります。これを取り除く推敲を、別のLLM工程として分離しました。

生成プロンプトに「自然に書け」と追加するより、分離したほうがよい理由があります。

生成段階は内容の正確さだけに、レビュー段階は文体だけに集中します。1つのプロンプトに目標を詰め込むと両方が中途半端になりますが、工程を分ければ各段階が1つの目標だけを最適化できます。

単一責任原則をプロンプトに適用したものと言えます。

ここには1つルールがあります。レビュー工程は内容・数値・引用を絶対に変更せず、文体だけを整えなければなりません。

そのためレビュー後に、画像マーカーと主要な数値が保持されているかを機械的に照合し、損傷を検知したらレビュー結果を破棄して原文を使います。

LLM呼び出し、画像生成API、レンダリングツールに至るまで、パイプラインの外部呼び出しはすべて失敗する可能性があります。だから失敗処理は付加機能ではなく、骨格そのものです。

原則は3つです。

1つ目は原本の保持です。どの工程も前段階の出力を上書きしません。レビューに失敗しても原文がそのまま残る必要があります。

2つ目は部分的な成功を許容することです。4枚の画像のうち1枚が失敗したら、3枚を保存して失敗だけを記録します。全体のロールバックは過剰対応です。

3つ目は失敗の可視化です。エラーを握りつぶさずステータスフィールドに残し、ダッシュボードから人が失敗した工程だけを再実行できるようにします。

まとめると、AI自動化の品質はモデルではなく工程設計から生まれます。段階を分け、スキーマで検証し、失敗を設計することです。

従来のパイプラインエンジニアリングの原則は、LLM時代にもそのまま有効です。

ハーネスエンジニアリング、コンテキストエンジニアリングの回と合わせて読むと、「モデルをうまく使う技術」の全体像が見えてくるはずです。