プロンプトチェーニング

課題

1つのプロンプトで同時に複数のことを実行しようとすると、出力の品質が低下し、制御が難しくなります。また、問題が発生した際のデバッグも困難になります。

適用対象

タスクが明確で順序付けられた一連のサブタスク（例：アウトライン作成、ドラフト作成、編集など）に分解でき、各ステップが前のステップの結果を利用できる場合に、プロンプトチェーニングを使用します。

解決策

非推奨のケース

• タスクが十分にシンプルで、1回の呼び出しで済む場合。
• サブタスクが独立している場合（この場合は並列化を行います）。
• 事前に実行経路が不明な場合（この場合はエージェントループを使用します）。

テクノロジー

事例

• アウトラインを生成し、次に各セクションを執筆し、最後にトーンを修正する。
• 構造化されたフィールドを抽出し、それらを検証し、最後に要約する。
• ドキュメントを翻訳し、次に翻訳結果を原文と照らし合わせてチェックする。

KPI

エンドツーエンドの成功率

最終的に正しい結果を出力できたチェーンの割合。エラーはステップをまたいで蓄積されます。

ステップごとのエラー率

各リンクにおける失敗率。信頼性95%のステップを5回連結すると、エンドツーエンドの信頼性は約77%になります。

総レイテンシと総コスト

チェーン内のすべての呼び出しの合計。ステップ数が増えるほど、レイテンシとコストの両方が増加します。

リカバリ率

失敗した中間ステップが、暗黙的に伝播されることなく、キャッチされて修正される頻度。

観察された失敗パターン

• エラーの伝播：チェーンの初期段階での誤りが、下流のすべてのステップを損なう。
• チェーンが長くなるにつれて、レイテンシとコストが累積する。
• あるステップの出力フォーマットが、次のステップで想定されている入力フォーマットと一致しない場合に、連携が破綻しやすい。
• ステップ間でコンテキストが失われ、後続のリンクが以前に設定された制約を忘れてしまう。

得られた教訓

• エラーが伝播する前にキャッチできるよう、ステップ間で検証またはゲートチェックを行ってください。
• タスクが許す限りチェーンを短く保ってください。ステップが1つ増えるごとに出力失敗の確率が倍増します。
• 連携が暗黙的に破綻しないよう、各ステップの出力仕様（コントラクト）を固定してください。
• 真に順次実行が必要な作業にのみチェーニングを使用してください。独立したステップは代わりに並列化します。

FAQ

プロンプトチェーニングはエージェントとどう違うのですか？

プロンプトチェーニングは、事前に定義された固定の順序に従います。一方、エージェントは自身のステップを動的に決定します。実行経路が事前に分かっている場合は、チェーニングを優先してください。

ステップ間にゲートを追加すべきなのはどのような場合ですか？

処理を進める前に中間結果が特定の条件を満たす必要がある場合は常に、ゲートを追加すべきです。これにより、エラーがチェーンの下流に伝播するのを防ぐことができます。

チェーニングによってコストは増加しますか？

はい、わずかに増加します。呼び出し回数が増えることは、トークン数とレイテンシの増加を意味します。しかし、複数のパートからなるタスクにおいては、通常、信頼性の向上がそのコストを上回ります。

参考文献

• Anthropic — Building Effective Agents (2024)

関連パターン