LangGraph interruptsでマーケティング原稿のレビューを設計

LangGraph interruptsで原稿のレビュー工程をどう設計しますか？

AIが作成したキャンペーン原稿を次のチームへ渡す前に、担当者は全文を確認し、承認によって何が許可されるかを理解する必要があります。確認中に原稿が変わる設計では、「承認」ボタンを用意するだけでは不十分です。

LangGraphは、グラフで構成したワークフローを実行する仕組みです。interruptsのドキュメントでは、処理を一時停止して外部入力を待ち、checkpointerを通じてグラフの状態を保存する動作が説明されています。Checkpointerは状態を保存する部品で、本番環境では永続的に保存できるものが必要です。これは人の判断を待つための技術的な基盤であり、完成済みのマーケティング承認システムではありません。

設計で結び付けるべきものは、担当者が見たバージョン、返された判断、指定した次の工程へ渡すバージョンの3つです。以下は、この仕組みを基にした設計上の提案です。

AI生成コンテンツの承認フローには、確認できる原稿を渡す

レビュー専用ノードに入る前に、元の原稿と予定する処理を保存する設計を勧めます。ノードはワークフローの実行単位です。中断時には、JSONとして表現できるデータを呼び出し側に提示できます。また、ドキュメントのreview-and-editパターンでは、処理を続ける前に人がモデルの出力やツール呼び出しを確認・修正できます。JSONとして表現できるデータとは、構造化された文字列、オブジェクト、リストなどです。

キャンペーンのSNS原稿なら、バージョン識別子と全文、対象市場、チャネル、予定する次の処理を提示します。出典リンクと未確認の訴求も同じ場所に添え、別の会話を探さなくても判断できるようにします。引き継ぎ記録にはレビュー担当者も明記します。

原稿と一緒に、次の確認項目を用意すると判断対象が明確になります。

• 事実： 製品情報、価格、キャンペーン条件に根拠があり、現在も有効ですか？
• ブランド： 承認済みの語り口とポジショニングに沿っていますか？
• 出典と利用権： 根拠を再び開けますか？予定する再利用は許可されていますか？公開ページであることは、文章や画像の転載許可を意味しません。
• 表現： 比較、最上級、曖昧な約束に根拠がありますか？
• 最終版： 判断の対象となる内容と次の処理が特定されていますか？

これらは提案する運用の確認項目であり、LangGraphに組み込まれたマーケティング機能ではありません。

承認・却下・修正を別の結果として扱う

判断フィールドはapprove、reject、reviseのように明示し、確認したバージョンの識別子、必要に応じた修正内容、理由を添える設計にします。判断した人も記録します。そのうえで、担当者に承認権限があるか、バージョンが一致するか、承認を妨げる未確認の訴求が残っていないかをアプリケーション側で確認します。

承認では、承認対象の版そのものを合意した次の工程へ渡します。却下では提案した処理を取り消し、記録を残します。修正では新しい版を保存し、再度レビューに回します。編集したという事実を、そのまま承認として扱ってはいけません。

架空の例として、v1に「すべてのお客様にとって最良のスキンケア」と書かれているとします。比較と全員への適合を裏付ける根拠がなければ、担当者はその表現を削除し、v2を「スキンケアシリーズをご覧ください」に変更できます。この判断は理由を添えたreviseです。V2もキャンペーンのブリーフに照らして確認します。根拠のない表現を1つ削除しただけで、代わりの原稿が承認されたことにはなりません。

MIAのCoworkの人によるレビューポイント設計では、確認可能な引き継ぎと、人のレビュー・修正・承認を待つ工程が説明されています。チームがどこで管理権限を持つべきかを考える際の参考になります。ただし、別製品の設計であり、LangGraphとの連携を示すものではありません。アクセス権限、保持期間、導入環境の制御は個別に確認する必要があります。

入力形式の提示と入力検証を区別する

ドキュメントでは、中断への応答スキーマにlanggraph>=1.2.12が必要とされています。Pydanticモデル、typing_extensionsのTypedDict、dataclassといった対応する型付きスキーマは、Pydanticの検証・型変換ルールに従って再開時の入力を検証します。無効な入力ではpydantic.ValidationErrorが発生し、修正した入力で同じthread上から再試行できます。

JSON Schemaの辞書を直接渡した場合、呼び出し側にはその形式が提示されますが、LangGraphはそれに基づいて再開時の入力を検証しません。response_schemaを省略した場合も、スキーマ検証は行われません。

型の検証に通っても、訴求の正しさや、現在の版が承認対象かどうかは確定しません。内容、権限、バージョンの確認はアプリケーション側のルールとして設計します。

再開時にはノードの先頭から実行される

再開にはCommand(resume=...)を使い、中断時と同じthread IDを指定します。Thread IDは対象ワークフローを識別するものです。渡した応答は、中断呼び出しの戻り値になります。

再開時には、中断したノードが先頭から実行され、interrupt()より前のコードも再実行されます。その前にレビュー原稿の再生成や外部への操作を置き、一度しか実行されないと考えてはいけません。レビュー用ノードは保存済みの提案を変更せずに読み取り、重複書き込みや後続の操作への対策は別途設計することを勧めます。一時停止と再開だけでは、厳密に一回限りの実行は保証されません。

実装前に、残すレビュー記録、3種類の判断の結果、再実行の影響を受ける処理を開発チームと合意してください。「誰がどの版を確認し、その判断が次に何を許可するか」を説明できることが、引き継ぎ仕様の出発点です。