AIで承認依頼の背景・目的・費用を整理する方法

承認依頼をAIで作るときは、文面を書く前に「承認者に何を決めてほしいか」を一文で固定します。背景、目的、費用、代替案、リスクを分け、金額・効果・期限の根拠と前提を添えます。資料にない効果をAIへ補完させず、未確認項目は空欄や確認待ちとして残してください。承認依頼の質は文章の丁寧さより、判断に必要な材料がそろっているかで決まります。

この手順では、社内の予算・購入・プロジェクトなどの承認メモを、元情報から整理する方法を扱います。承認権限や必要な添付は組織ごとに異なるため、既存の稟議様式、決裁規程、セキュリティ確認を先に確認します。AIは文書の下書きを整える補助で、承認者や金額、契約条件、投資効果を決める役割ではありません。

最初に決定事項を一文にする

「新しいツールを導入したい」では、何をいつまでにいくらで決めるのか分かりません。Decision requestには、対象、求める判断、時期、金額の範囲、条件を含めます。まだ決まっていない値は推測せず「未確認」と書き、必要な承認が複数あるならそれぞれ分けます。

たとえば「対象部署で試験導入を行うため、期間と上限費用を承認してほしい」のように、決裁事項を冒頭へ置きます。これは構造例であり、特定の購入や効果を勧めるものではありません。契約主体、費用負担、個人情報の取扱い、セキュリティ審査が関わる場合は、関連部署の確認も依頼事項へ含めます。

Approval Brief

表は横にスクロールできます

項目	書くこと	根拠として添えるもの
Decision request	誰が何をいつ決めるか	決裁規程、依頼期限
Background	現状と解決したい課題	現状記録、業務手順
Objective	何を確かめるか	仮説、対象ユーザー
Outcome	期待する変化と測定方法	現状値、測定計画
Cost	初期・継続費用、単位、期間	見積書、計算前提
Alternatives	現状維持、手作業、別案	比較条件
Risks	制約、未確認、軽減策	担当者、確認期限

背景と目的を分ける

背景は現在の状況と困りごと、目的は承認後に確かめたいことです。「作業時間が多い」は背景になり得ますが、「ツール導入で半分になる」は根拠がなければ期待効果に過ぎません。現在の作業時間を測っていない場合は「現状値は未計測」と示し、試験導入中に測る計画を提案します。効果を確定事項のように書き換えないことが大切です。

目的は、期間内に何を判断するのかへ落とします。たとえば「対象業務で必要な機能、運用負荷、入力情報の扱いを評価し、本導入へ進むか判断する」のようにします。導入そのものが目的になると、試験の成功条件や中止条件が曖昧になります。承認者が何を見て次の決定を行うか、開始前に合意してください。

費用は単位・期間・前提と一緒に書く

費用は合計だけでなく、初期費用、月額または年額、対象人数、利用期間、税・為替・オプションなど、見積もりに含まれる範囲を整理します。確定見積もりと概算を分け、概算には計算式と前提を付けます。情報がない値をAIに推定させず、未確認として残します。たとえば月額の安さだけで案を選ばず、同じ試験期間・同じ人数で初期費用と継続費用をそろえて比較します。見積書にない追加作業、解約条件、データ移行費などは「発生する」と断定せず、確認項目として別に置きます。代替案が手作業なら、担当時間や既存システムの追加費用など、比べる範囲を承認者と合わせてください。

表は横にスクロールできます

費用欄	入力する値	空欄時にすること
初期費用	見積の対象・一回限りの金額	見積取得待ち
継続費用	月額または年額、通貨	期間と単位を確認
利用人数	想定席数・対象部署	利用範囲を承認者へ確認
追加条件	税、超過、解約、設定支援	契約条件を確認
合計見込み	計算式と対象期間	前提が揃うまで未確定

概算の例として、年間見込みを「初期費用＋月額費用×対象月数＋追加費用」で整理できます。金額を入力するのは見積書や契約資料がある場合だけです。上限、最低利用期間、超過料金、解約条件が確認できていないなら、確定額として稟議に書かず、承認条件や追加確認事項に分けます。

代替案とリスクを同じ軸で比較する

代替案には、現状維持や手作業の継続も含めます。提案案だけを詳しく書くと、導入が既定路線のように見えます。比較では、必要な機能、費用、運用負担、データ取扱い、実施までの時間など、Decisionに関係する軸をそろえます。分からない項目は「不明」とし、推測で埋めません。

表は横にスクロールできます

選択肢	期待できること	費用・工数	未確認・リスク	次の判断
現状維持	現行手順を継続	既知の範囲を記入	課題が残るか測定	測定が必要か
手作業の改善	手順・テンプレを変更	試行工数を記入	定着・例外対応	小さく試すか
試験導入	仮説を限定して検証	見積と期間を記入	情報管理・契約条件	条件付き承認か

リスクは「AIが間違える」だけで終わらせず、何が起きると困るか、どの担当が何を確認するか、未確認なら実行を止めるかを書きます。データの持ち出し、権限、契約、運用責任、代替手段などを案件に応じて洗い出します。リスクを完全になくせると断定せず、残るリスクと承認者が選ぶ条件を分けて示します。

架空例：少人数での試験導入を申請する

ある部署が新しい文章支援ツールを試したい、という架空の相談を考えます。依頼事項は「一定期間・限定した利用者で試験するための承認」であり、本導入や全社展開の承認とは分けます。背景には現行の文書作成手順と困りごと、目的には確認したい作業時間・修正負荷・情報管理の条件を記します。ここで「時間を削減できる」とは書かず、試験中に測る項目と測定方法を決めます。

費用欄には実見積を添え、利用人数、期間、追加料金の条件を示します。見積が未取得なら費用は未確定とし、見積取得を承認条件にできるか決裁者へ確認します。代替案には現行テンプレートの改善や手作業継続を含めます。未承認のデータを入力しない、入力範囲を限定する、試験終了後に継続可否を判断する、といった条件は担当部署と合意した場合だけ記載します。この例は形式を説明する架空案であり、特定サービスや導入効果を示しません。

AIへ草案を依頼するPrompt

「以下の承認依頼情報だけを使い、指定Templateに沿った草案を作成してください。冒頭にDecision requestを一文で置き、背景、目的、期待する変化、費用、代替案、リスク、未確認事項を分けてください。金額・期間・効果・契約条件は入力資料にある値だけを使い、計算する場合は式と前提を併記してください。情報がない項目は補完せず『確認待ち』としてください。提案案だけを有利に見せず、現状維持を含む選択肢を同じ軸で並べてください。結論として承認済みであるかのように書かず、依頼する判断を明確にしてください。」

Promptには承認依頼の全資料を無差別に入れず、入力が許可された範囲で必要な情報だけ渡します。個人情報、契約上の機密、未公開の財務情報などが含まれる場合は、組織の承認環境を先に確認します。文章が自然でも数字が正しいとは限らないため、草案の各金額・日付・条件を元資料と照合します。

差し戻し前のQA

表は横にスクロールできます

確認	PASSの目安	不足時の対応
Decision request	求める承認と時期が一文で分かる	決裁事項を再確認
目的	何を検証・実行するか具体的	仮説と指標を定義
費用	単位、期間、前提、出典がある	見積または概算条件を確認
代替案	現状維持を含めて同じ軸で比較	比較可能な案を追加
リスク	担当と軽減・停止条件がある	担当部署へ確認
不明値	未確認と明示されている	推測値を削除
添付・権限	必要資料と承認経路が一致	規程と様式を確認

一項目でも承認判断に必要な根拠が欠ける場合、文体を整えて提出するのではなく、誰から何を取得するかを確認欄にします。承認者から差し戻されたら、元依頼、修正理由、採用した根拠を対応付けます。AIが追記した内容を、確認者が承認済みの事実と取り違えないように修正履歴を残してください。

次にすること

まず既存の稟議様式と決裁規程を確認し、求める決定を一文で書きます。次に背景・目的・費用・代替案・リスクを根拠資料へ結び付け、未確認値を残します。最後にAIで文案を整え、金額と条件を元資料から再確認して、判断材料がそろってから承認者へ回します。

AIものさしの判断

AIへ任せるのは、承認材料の分類、抜けの指摘、指定様式への草案化までです。費用、効果、契約条件、実施リスクを作らせず、確認できない項目は未確定のままにします。次の一件では、Decision requestと根拠付き費用欄を先に作り、承認者が決めることと作成者が確認することを分けて提出してください。

承認後の記録を残す

承認された場合も、依頼文を最終状態として保管するだけでは、後から実行条件を確認しにくくなります。承認日、決定者、承認範囲、金額上限、対象期間、付帯条件、次の見直し時点を、組織の記録方法に従って残してください。条件付き承認なら、条件が満たされたことを誰が確認し、どの記録へ残すかを決めます。否認・保留の場合も、判断理由と再申請に必要な情報を記録し、AIの草案と決裁結果を混同しないようにします。 予算・契約・情報管理の条件が変わる場合は、前回の承認を自動で流用せず、変更箇所と再確認先を明示します。承認依頼を作る工程と、契約の締結・発注を実行する工程も分けて管理してください。