重要な決定を下す前に AI によるセカンドオピニオンを得る

決断する必要があることから始めましょう

「私のアイデアを評価してください」だけでは、感じのよい総評で終わり、判断が何も変わらない可能性があります。選択肢、期限、判断基準を示してください。例えば、試験導入を今始めるかデータ確認後にするか、サービスを購入するか既存システムを拡張するか、全範囲を引き受けるか段階に分けるか、といった選択です。

現在のプロセスを維持するなど、信頼できる代替案を含めます。その後、話し合いで行動が必要かどうかを検討できます。回答を読む前に、利用可能なスタッフ、必要な能力、支出制限、作業を停止する条件などの基準を定義してください。

具体例：一か月以内の納品を約束できるか

ある代理店が、問い合わせ対応用のCRMを四週間で導入する仕事を検討しているとします。責任者は引き受けたいと考えています。チームはそのシステムを知っており、作る画面も少ないからです。しかし依頼資料には、既存データの品質、外部システムとの連携に必要なアクセス、クライアントが承認に対応できる日程が明記されていません。これは仮の例であり、顧客の実績ではありません。

別の視点からの検討により、画面設計よりもそうした前提条件が重要だと分かるかもしれません。検証すべき主張は、未整備のデータでもチームが納品できるかどうかです。納期を確定するために必要な証拠を列挙した、事前調査段階の提案が有用な成果になることもあります。実際のスケジュールと範囲については、引き続きチームが責任を負います。

すべてのエージェントが当初の期限を支持する場合は、裏付けとなる事実を尋ねてください。合意しても不明な依存関係は解決されません。異議が架空の複雑さに依存している場合は、証拠を要求するか、それを仮説として保持してください。

参加者に同じ依頼内容を渡す

文書のタイトル、電子メールの日付、スプレッドシートの行など、各重要な事実の横にソースを配置します。これにより、最終的なチェックが容易になります。関連するサービスと共有することが許可されている情報を使用します。多くの場合、最初のレビューには匿名化された条件で十分です。

• 意思決定：何と何を、いつまでに選ぶのか。
• 確立された事実: 要件、合意された条件、および利用可能な文書。
• 仮定: 観察または合意されていない期待。
• 制約: 人員、予算、依存関係、必須条件。
• 停止条件: オプションが受け入れられなくなるもの。

有益なセカンドオピニオンを求めるプロンプト

「この決定の検討に協力してください: [選択肢と期限]。確立された事実: [事実と情報源]。前提: [リスト]。制約: [条件]。各選択肢に対する最も強い主張、最も強い反対意見、そしてまだ変更しないという選択肢を検討してください。私の好みを証拠として扱わないでください。結論を変える可能性が最も高い欠落している事実を特定してください。条件付きの推奨事項で終了し、重要な意見の相違を保存し、チェック項目をリストします。数値や裏付けとなる証拠をでっち上げないでください。」

各欄を自分の依頼内容で置き換えてください。Colayでは、議論と統合した結論が必要ならConsensusを選びます。まず個別の回答を得たい場合はAsk separatelyを使ってください。その後で回答をまとめるよう依頼する際は、関連する抜粋と元の依頼内容を渡します。個別のチャットが自動的に文脈へ取り込まれるとは考えないでください。

有用な結果に含めるべき内容

CRM の例では、アクセスの確認とデータの検査が次の決定をサポートします。 「すべてのモデルが実現可能だと考えている」だけでは、日付を約束するのに十分ではありません。後でどの条件が変更されたかを特定できるように、元の概要をメモと一緒に保管してください。

答えが 1 つだけで十分な場合

メールの編集や独自のテキストの要約には、1 つのモデルと通常のレビューだけが必要な場合があります。実際に代替案があり、見落とされた条件によって決定が変わる可能性がある場合、議論はテストする価値があります。 Colay サブスクリプションではクレジットと制限が使用されます。追加レビューで実際に明らかになった内容と使用量を比較してください。

最初の試行は、確認できる成果で判断してください。裏付けのない前提を発見できたか、計画を修正できたか、クライアントへの質問を特定できたか。文章量が増えただけでは価値があるとはいえません。資料があり、結論を検証する方法もある一つの意思決定から始めてください。