- 公開日
要約、比較、提案が一つの依頼に混ざっているときは、作業ごとに「何を材料に、どの基準で、何を出すか」を分けます。原資料に書かれた事実と、比較から導く評価、新しく考えた提案を別の欄に置けば、どの段階で情報が追加されたかを追えます。送信や設定変更まで含む場合は、文章を作る工程と外部へ作用する工程も分けて扱います。
この振り分けをタスク種別ルーティングと呼びます。必ず複数のAIや専用システムを用意するという意味ではありません。一つの依頼文の中で出力欄を区切るだけで扱える場合もあれば、途中の確認結果によって別の処理へ進める方がよい場合もあります。
この記事は、一つの依頼に混ざった作業を分けて処理する手順（出力欄の分離、作業の順序、途中の目的変更）を扱います。要約・比較・提案・判定・翻訳・抽出のそれぞれの違いは「「要約」「比較」「提案」「判定」「翻訳」「抽出」をAIに混同させない」で解説しています。
作業名より、出力に何を足してよいかを見る
要約では、原資料の重要な意味を保ちながら短くします。比較では、二つ以上の対象を共通の観点に沿って並べます。提案では、目的や制約に合わせて新しい選択肢や推奨を加えます。同じ資料を使っていても、出力に加えてよい内容が違います。
例えば規程を要約する段階で「この制度は非効率なので廃止すべき」と書けば、原資料にない評価や提案が混ざっています。比較欄で「費用の記載がない」を「費用がかからない」と変えるのも、比較の材料を勝手に補ったことになります。作業名を見出しに置くだけでは、こうした混同は防げません。
実行には、別の確認が加わります。「運用案を推奨して」と「その案で共有設定を変更して」では、必要な権限や影響が異なります。前者を終えたから後者も許可されたとみなさず、実行する対象、変更内容、承認の要否、結果を確認する方法を確かめます。
Anthropicの技術解説は、入力を分類して専門化した処理へ送るルーティングと、前段の結果を次の段階へ渡すプロンプト連鎖を区別しています。本記事では、その区別を日常の依頼の整理に応用します。工程を分ければ自動的に正確になるという性能保証ではなく、確認する場所を明らかにするための考え方です。
「規程を要約して、二案を比較し、推奨して」を分解する
次の架空例で考えます。利用者は、チームの在宅勤務の運用を見直すため、AIに「規程を要約して、二案を比較し、推奨して」と依頼しました。材料は次の三点です。
- 規程：在宅勤務は週2日まで。実施日は上長の承認が必要。顧客対応の当番日は出社する
- A案：毎週火曜・木曜を基本の在宅勤務日とし、当番日に重なる場合は出社する
- B案：週ごとに希望日を申請し、当番日を除いて上長が承認する
ここでAIが「柔軟なB案が最適です。規程でも自由な在宅勤務が認められています」と答えると、二つの問題があります。規程の要約から週2日と上長承認が抜け、推奨の基準である「柔軟性」も利用者が指定したものか分かりません。
改善した依頼は、例えば次のようにできます。
「上記の規程とA案・B案を使い、三つの欄で回答してください。第一欄は規程の要約です。週の上限、承認、当番日の条件を保持し、評価を加えないでください。第二欄は、規程との整合、予定の見通し、申請作業の観点で二案を比較してください。資料にないことは未確認としてください。第三欄は、毎週の調整負担を減らすことを優先した条件付きの提案です。原資料にない補足案は提案と明記し、採用前に確認する点も示してください。設定変更や関係者への連絡は行いません。」
この例で差し替えるのは、規程、二案、比較軸、優先する目的です。「調整負担を減らす」を別の目的へ変えれば、推奨の条件も変わります。文末の実行範囲は今回の依頼が文書検討だけだから置いたもので、すべての作業を一律に止めるための文言ではありません。
三つの出力欄を、原資料と照合する
第一欄の要約なら、「在宅勤務は週2日までで、実施日には上長承認が必要です。顧客対応の当番日は出社します」と書けます。三条件を保っており、A案かB案かの評価は入っていません。
第二欄では、案ごとに何が書かれているかを確認します。次の表は説明用の期待出力で、AIへ入力して得た実測結果ではありません。
| 観点 | A案 | B案 |
|---|---|---|
| 週2日の上限 | 火曜・木曜の2日を基本とする | 希望日を申請するが、上限の明記がない |
| 上長承認 | 案の文章に承認方法の記載がない | 上長承認を明記している |
| 当番日の出社 | 当番日に重なる場合は出社と記載 | 当番日を申請対象から除いている |
| 予定の見通し | 基本曜日を固定できる | 週ごとの申請と承認後に確定する |
| 申請作業 | 申請頻度・例外時の扱いは未確認 | 毎週の希望申請を想定している |
A案に承認の記載がないことは、承認を行わないと決定したことと同じではありません。B案に上限の記載がないことも、週3日以上を許す証拠ではありません。比較欄では資料の不足を示し、運用の実態を断定しないようにします。
第三欄では、「調整負担を減らす目的ならA案を検討候補にできます。ただし承認方法と例外時の申請手順を追加で決める必要があります」と提案できます。「承認済みの基本曜日を登録する」という補足案を考えるなら、それが現行規程の説明なのか、新しく提案した運用なのかを明示します。規程上可能かは、規程の管理者に確認する事項として残します。
回答を受け取った後は、要約の三条件、比較表の各セル、提案の優先目的を順に原資料へ戻して確認します。一つの提案が魅力的でも、その土台となる比較が「未記載」を「実施しない」に変えていれば、比較から直す必要があります。
一度に答えさせるか、途中で区切るか
短い規程と二案を扱い、比較軸が明確で、結果が社内検討用の文章にとどまるなら、一回の依頼で三欄を出す方法から試せます。工程ごとに何度も呼び出すと、待ち時間や確認の手間が増えます。分類が目的にならないよう、必要な分離だけを選びます。
一方、比較の前に不足条件を確認しないと推奨が変わる場合は、途中で区切ります。先ほどの例で、A案の承認方法が実は毎週個別申請だったと分かれば、「調整負担が軽い」という推論は弱まるかもしれません。先に「比較に不足する情報」を出し、人の回答を受けて提案へ進む方が、仮定を重ねずに済みます。
資料が長く、複数の担当者が別々の規程を持つ場合も同様です。まず対象の版と適用範囲を揃え、要約が原資料に対応するかを確認してから比較へ進めます。前段が未確認なら、後段をもっと詳しく生成するだけでは不足を解消できません。
すべてを並行に進められるわけでもありません。二案の記載事項を独立に抽出する作業は並行化できても、両方の抽出が揃う前に最終推奨を確定するのは避けます。どの結果が次の判断の前提になるかを確認すると、順序を決めやすくなります。
途中で目的が変わったら、変わる部分を更新する
利用者が途中で「やはり、申請作業の少なさより毎週の柔軟性を重視して」と変更したとします。この場合、原規程の内容は変わっていないので要約を作り直す必要はありません。比較軸の重みと提案の理由を更新し、B案が候補になる条件を検討します。
ただし、比較欄に「A案の方が負担が少ない」といった評価を含めていたなら、その根拠と前提も見直します。目的変更に影響されない事実まで書き換えると、何が変わったのか分からなくなります。「規程と案の記載は同じ。優先する目的だけを変更した」と分けておくと、変更理由を説明できます。
次に「その内容でチームへ知らせて」と依頼が変わった場合は、連絡という新しい作業が加わります。採用が決まった案、宛先、本文、発信者の権限が必要です。検討候補しかできていない段階なら、正式決定のお知らせを作って送るのではなく、候補の共有なのか決定の通知なのかを確認します。
目的の変更が前の指示を置き換えるのか、追加するのかも重要です。「比較はいらないので要約だけ」という依頼なら、比較・提案を続ける必要はありません。「要約に加えて英訳も」という依頼なら、内容を確定した要約を翻訳工程へ渡します。作業の増減と、材料の変化を別々に追ってください。
タスク種別を分けるだけで、資料の正しさや操作権限まで確認済みになるわけではありません。要約には原文照合、比較には共通条件、提案には目的、実行には権限と結果確認が必要です。それぞれの確認を適切な位置へ置くことが、混在した依頼を扱う出発点になります。
基本から確認する：この記事の前提になる考え方は、「プロンプトの書き方ガイド（依頼文の基本6項目と例文）」にまとめています。
