生成AIで企画のリスクを洗い出す方法｜実行前の確認手順

新しい備品予約の仕組みや、社内の申請方法を始める前に、生成AIで「うまくいかなかった場合の原因」を考える使い方があります。計画と未決定の条件を渡し、起こり得る困りごと、確かめる内容、対策案を整理します。

AIが挙げた懸念は、実際に起きた事故でも、将来の予測結果でもありません。現場の担当者が確かめるための候補です。福島県の中小企業で総務や業務改善を担当する方に向けて、架空の備品予約を使って試し方を紹介します。

プレモーテムは、企画を始める前に失敗を仮定する方法

プレモーテムとは、計画が失敗したと仮定して、その原因を実行前に考える方法です。「何か心配はありますか」だけでなく、「開始から2週間後、予約の行き違いが起きて運用を止めたとしたら、何が原因だったでしょうか」と具体的な状況を置きます。

Atlassianのプレモーテムの進め方でも、開始前に懸念を各自で書き、似た意見をまとめて議論する手順を紹介しています。

以下は、この考え方を生成AIとのやり取りに取り入れた編集部の実務提案です。特定のAI製品での実行結果や、当社の導入実績を示すものではありません。

実施後に良かった点や改善点を整理したい場合は、KPTによる振り返りが別の用途になります。ここで扱うのは、まだ始めていない企画の確認です。

AIへ渡す材料は、目的・決まった条件・未決定事項の三つ

「この企画のリスクを出して」とだけ頼むと、自社に当てはまるか判断しにくい一覧になります。最初に、今回の企画がどこまで決まっているかを短く書きます。

用意する材料	書く内容
目的	何ができれば、この試行を続けられるか
決まった条件	対象、期間、手順、担当者、使える時間
未決定事項	まだ確認していない操作や、担当が決まっていない場面
変えられない条件	今回追加できない設備や、守るべき運用範囲

最初は、下の架空例をそのまま使ってください。実務へ移す際は、会社が認めたAI環境と入力範囲を確認します。顧客名や社員情報を記号に変えただけで、資料全体を入力してよいとは限りません。

また、AIに聞く前に、利用者と管理担当がそれぞれ気になる点をメモしておきます。先にAIの一覧を読むと、それに沿った意見だけを出してしまうかもしれません。人の懸念とAIの追加候補を見比べる進め方を勧めます。

架空の備品予約を使い、プレモーテムを依頼する

次の材料と指示を、新しいAIチャットにまとめて貼り付けます。固有の製品機能や外部システムとの接続は前提にしていません。

新しい備品予約の運用について、実行前に困りごとを検討します。
以下は実在する会社や社員の情報を含まない練習用の設定です。

【目的】
共有備品の予約が重ならず、利用者が予約結果を確認できるようにする。

【決まった条件】
A. 共有備品3台を、1部署で2週間だけ試す。
B. 利用者は共通の予約表に希望日時を入力する。
C. 総務担当が毎朝、重複した希望がないか確認する。
D. 試行中は、利用直前に総務へ予約の確定状況を確認する。
E. 新しい有料サービスは、この試行では追加しない。

【未決定事項】
F. 同じ日に希望が重なった場合の優先順は未定。
G. 総務担当の不在時に誰が確認するかは未定。
H. 入力後の変更をどのように伝えるかは未定。

【検討する状況】
2週間の試行中に予約の行き違いが起き、運用を止めたと仮定する。

【依頼】
1. この失敗につながり得る原因を最大5件挙げてください。
2. 各候補に、関係する条件の記号、失敗へ至る流れ、
   現場で確かめる質問、予防策案を付けてください。
3. 入力にない出来事は「追加の仮説」と明記してください。
4. 発生確率や効果の数値、担当者の合意は作らないでください。
5. Dの確認手順があっても残る懸念を考えてください。
6. 最後に、実行前に人が決める事項を三つ以内で示してください。

「最大5件」は、この練習で確認できる量に絞るための指定です。5件出れば十分に調査できた、という意味ではありません。

出てきた懸念を、計画の条件と照らす

次は、元の設定と照合するために編集部が作成した例です。AIが実際に返した回答の転載ではありません。

原因候補	元の条件との関係	現場で確かめること
希望が重なったときに確定できない	Fで優先順が未定。Dの直前確認でも、その場で決まらない可能性がある	誰が何を基準に調整するか
総務担当が不在だと確認が止まる	Gで代わりの担当が未定	不在が予定される日と、代わりに対応できる人
朝の確認後に予約が変わり、認識がずれる	CとHの組み合わせ。Dで見つかっても利用直前の調整になる可能性がある	変更の連絡先と、予約表へ反映する担当

ここで「総務担当が休んだため、予約が止まった」と断定してはいけません。欠勤が起きた事実は、材料にありません。「不在の場合はどうするか」と確認するための候補に戻します。

AIが「全員が予約表を編集できるので誤って削除される」と書いた場合も、編集権限は設定にない情報です。削除事故が起きる前提で対策を決めず、「誰にどの権限を与える予定か」という質問に直します。

同じ原因を言い換えた行はまとめます。ただし、まとめる前の懸念は残しておきます。「不在時の対応がない」と「変更連絡が届かない」は、どちらも連絡の話に見えても、確認する相手や対策が異なります。

リスクの数より、開始前に何を決めるかを明確にする

懸念が並んだら、担当者が次の順で検討します。

1. 起きた場合に、今回の目的をどこまで妨げるか。
2. すでにある手順で対応できるか。
3. 開始前に確認・対策できるか。
4. 未解決のまま試すなら、誰が様子を見て、どこで止めるか。

AIが付けた「高・中・低」だけで優先順を決めないようにします。この例では、優先順と代わりの確認担当が未定なら、予約を確定する運用自体が決まりません。開始前に担当者同士で決める項目として扱えます。

対策も、実施前と問題発生時を分けて書きます。

場面	担当者が検討する対策案
試行開始前	重複時の調整役、不在時の確認役、変更連絡の方法を決める
試行中の確認	希望の重複と調整内容を記録し、決めた手順で処理できたかを見る
行き違いが起きたとき	新たな予約確定をいったん保留し、決めておいた調整役へ確認する

この表は採用前の案です。実際の担当名、確認日、合意した内容を埋めて初めて、自社の運用になります。決めた作業を分解したい場合は、WBSの作り方も参考にしてください。

対策を入れた計画で、同じ失敗をもう一度考える

対策を加えたら、修正版の計画をAIへ渡します。「先ほどの懸念のうち、解消したものと残ったものを、修正した条件に基づいて分けてください」と頼みます。

代わりの担当を決めても、その人が予約表を見られなければ対応できません。変更連絡を増やすと、総務側の確認回数が増えることもあります。対策の追加によって新しい作業が生じるため、担当者が実際の手順を一度なぞって確かめます。

試行後は、想定した困りごとが起きたか、想定外のものがあったかを確認します。起きなかったからといって、その対策が不要だったと即断はできません。試行の期間や件数、対策が働いた状況も見て判断してください。

採用した案と保留した案は、理由とともに残します。後から見直すときには、意思決定ログの形にすると、当時の条件を確認できます。

よくある質問

AIに任せれば、企画のリスクを全部見つけられますか？

すべてを見つけたとは確認できません。入力に含めていない業務条件や、現場でしか分からない事情もあります。AIの候補と担当者自身の懸念を照合し、関係する利用者へ確かめる時間を取ります。

発生確率をAIに付けてもらってよいですか？

根拠となる記録がない数値を、判断の材料にすることは勧めません。まず、起きた場合の支障と、今確認できることを整理してください。過去の記録を使う場合も、対象期間や同じ条件で起きた件数を人が確認します。

企画を否定するだけの話になりませんか？

検討の目的を「中止する理由を増やすこと」ではなく、「始めるために未決定事項を減らすこと」と共有します。問題を挙げた人に責任を求めず、確認すれば解決できる点、試行中に見る点、今回は対応しない点を話し合います。

まずは一つの計画を、架空の条件で試す

生成AIで企画のリスクを洗い出すときは、目的と条件を先に渡し、出力を事実と仮説に分けて確認します。最後に残すのは、長い懸念一覧ではなく、担当者が確認して合意した対策と、まだ決まっていない事項です。

まずはこの記事の備品予約の例を使い、条件にない断定が混じっていないかを確かめてください。実際の業務へ広げる際は、入力できる材料と確認担当を決めてから進めます。