AIワークフローを構築する方法 — プロンプトチェーンと条件分岐の設計

単発のプロンプトが破綻するタイミング

1つのプロンプトに「読み取り」「判断」「加工」「出力形式の整形」を全部詰め込むと、最初のうちは動きます。しかし入力のバリエーションが増えるにつれて、指示が長くなり、モデルがどの条件を優先すべきか曖昧になっていきます。結果として、ある入力では正しく動くのに、似た別の入力では出力形式が崩れる、といった不安定さが出てきます。

目安として、1つのプロンプトの中で「もし〜なら」という条件分岐の言及が3つを超え始めたら、チェーンに分割するタイミングと考えてよいでしょう。分割の効果は、各ステップの入力と出力が単純になることで、どこで誤りが起きたかを特定しやすくなる点にあります。

プロンプトチェーンの基本設計 — 入力・処理・出力を分割する

プロンプトチェーンとは、1つの大きな指示を複数の小さなステップに分け、前段の出力を次段の入力として渡す設計です。基本形は次の3段です。

1. 抽出ステップ — 入力データから必要な情報だけを構造化して取り出す（自由文ではなくJSONなど決まった形式で出力させる）
2. 判断・加工ステップ — 抽出した情報をもとに分類や要約、文章生成を行う
3. 整形ステップ — 最終的な出力を、後続のシステム（スプレッドシートや通知ツール）が読み取れる形式に整える

ステップを分けると、各段の指示が短くなり、モデルの出力が安定しやすくなります。次の例は、問い合わせメールを分類する抽出ステップのプロンプトと、期待される出力形式です。

プロンプト（抽出ステップ）:
以下のメール本文から、次の情報をJSON形式で抽出してください。
出力はJSONのみとし、説明文は含めないこと。
- category: "請求" | "技術的な問題" | "その他" のいずれか
- urgency: "high" | "normal" のいずれか
- summary: 1行の要約

メール本文:
{{メール本文}}

期待される出力例:
{"category": "技術的な問題", "urgency": "high", "summary": "ログインできないという申告"}

この出力をそのまま次のステップ（自動化ツールの条件分岐ノード）に渡すことで、後段の処理を安定させられます。

条件分岐とルーティングの実装パターン

抽出ステップでカテゴリやスコアを構造化して出力させておけば、条件分岐は自動化ツール側（Zapier・Make・n8nのルーターやフィルター機能）で組めます。AIに分岐そのものを判断させるより、AIには分類結果を出させ、分岐の実行は決定的なルールに任せる方が、動作が読みやすく、デバッグもしやすくなります。

典型的なパターンは次の2つです。

• ルールベースのルーティング — 抽出ステップが返した category の値によって、後続の処理を完全に分岐させる（"請求" なら経理チームへの通知、"技術的な問題" ならサポートチケット作成）
• スコアによる足切り — urgency や confidence（確信度）のスコアが閾値を下回った場合は自動処理を行わず、人による確認に回す

後者は誤判定を減らすうえで重要です。AIの分類は完全ではないため、確信度が低い入力を無条件で自動処理に流すと、誤りがそのまま外に出てしまいます。

エラー処理とリトライの設計

多段パイプラインでは、途中のどこか1段が失敗すると全体が止まります。エラー処理では最低限、次の3つを設計しておく必要があります。

1. タイムアウトとリトライ — API呼び出しが一定時間応答しない場合、一定回数まで自動で再試行する（無限リトライは避け、上限回数を決める）
2. フォールバック — 抽出ステップの出力が期待した形式（JSONなど）でなかった場合、パイプラインを止めずに「要確認」フラグを立てて後段に流す
3. 人による確認への切り戻し — 規定回数リトライしても失敗する場合は、担当者への通知に切り替える

次は、n8nのFunctionノードやMakeのモジュール内で使うような疑似コードで、リトライとフォールバックの考え方を示したものです。

let attempts = 0;
let result = null;

while (attempts < 3 && result === null) {
  try {
    const response = callAiApi(input);
    result = JSON.parse(response); // 形式が崩れているとここで例外
  } catch (e) {
    attempts++;
  }
}

if (result === null) {
  // 3回失敗した場合は人の確認に回す
  routeToHumanReview(input);
} else {
  routeToNextStep(result);
}

外部データの取り込み

プロンプトチェーンの精度は、モデルの知識だけに頼らず、外部データをどれだけ正確に渡せるかで大きく変わります。代表的な方法は次の2つです。

• API呼び出しによる取得 — 社内システムやSaaSのAPIから最新データ（在庫数、顧客情報など）を取得し、プロンプトの一部として渡す
• 検索結果の統合 — 社内ドキュメントや過去の対応履歴から関連する部分だけを検索して渡す設計（いわゆる検索拡張生成、RAGに近い考え方）

外部データを渡す際は、機密情報が含まれていないかを事前に確認し、社内の情報取り扱いポリシーに従う必要があります。特に顧客情報を含むデータを外部のAI APIに渡す場合は、各社のデータ利用ポリシーを確認したうえで運用してください。

よくあるつまずきと次のステップ

よくあるつまずきは、抽出ステップの出力形式が安定しないことです。自由文で答えさせると、句読点や改行の違いで後段のパースが失敗しやすくなります。JSON形式を明示的に指定し、「出力はJSONのみ」と繰り返し指示することで安定度は上がりますが、それでも稀に崩れることがあるため、パース失敗時のフォールバックは必須です。もう一つは、条件分岐を増やしすぎて全体の見通しが悪くなることです。

ただし、分岐が3段階を超えて複雑になり、状況に応じて次に何をすべきかをその都度判断する必要が出てきた場合は、固定されたプロンプトチェーンではなく、目的・使えるツール・判断の境界を設計したAIエージェントの設計パターンに切り替えることを検討すべきです。チェーンとエージェントの境界は、分岐のパターンが事前にすべて洗い出せるかどうかにあります。洗い出せるならチェーン、状況次第で経路が変わるならエージェントが向いています。