AIで社内申請・稟議の下書きを作る方法

AIで稟議書や社内申請の下書きを作るときは、完成文をいきなり生成させず、「承認してほしいこと」「確認済みの事実」「未確定の条件」を分けて渡します。AIに任せるのは構成と文章化までです。費用、効果、契約条件、社内規程は原資料や担当者が確定し、推測で空欄を埋めさせないでください。

稟議の判断材料を先に揃える

起案前に、承認者が何を決めるのかを一文にします。「新しいツールを導入したい」ではなく、「問い合わせ対応の記録を一元化するため、対象部署で3か月の試行利用を承認してほしい」のように、対象・行為・期限・求める判断を入れます。例は書き方の見本で、実際の効果や期間を保証するものではありません。

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

欄	入れる内容	根拠の例	未確認なら
承認事項	購入・契約・実施など、決めてほしいこと	申請者の目的	承認案を確定してから起案
背景・課題	現在の業務と困りごと	件数、作業記録、問い合わせ	「要確認」と残す
費用・期間	初期費用、月額、期間、更新、解約	見積書、契約条件、公式料金	数値を生成させない
期待効果	測定方法と仮説、既存実績	現状値、試行結果	実績と予測を分ける
リスク・代替案	導入時の懸念、現行手段、別案	セキュリティ確認、比較条件	未評価と明記
承認ルート	誰が何を確認するか	社内規程	社内ルールを参照

背景は「なぜ今検討するか」、課題は「どこで何が起きているか」、目的は「何を変えるか」です。この3つを混ぜると、AIが背景から効果を作り出したり、課題を解決済みのように書いたりしやすくなります。申請対象の利用者、開始時期、対象範囲、既存手段も別々に記録します。

AIへ渡す前の素材を作る

まず資料から事実を集め、各項目に根拠と確度を付けます。たとえば「現状の月間処理件数＝社内集計」「月あたり作業時間＝担当者の計測」「削減見込み＝試算」「契約更新日＝見積書未確認」のように、出所と状態を同じ行に残します。AIが文章を整えるときに、予測を実績へ言い換えたり、欠けた条件を常識で補完したりするのを防ぐためです。

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

ラベル	意味	稟議での扱い
確認済み	原資料・担当部署で確認した値	根拠名または日付を付けて使う
仮説	試行前の期待、推計	算出方法と前提を明記
要確認	根拠不足、担当者未回答	数値・断定を保留
対象外	今回の判断範囲に含めない	省略理由を短く記載

プロンプトには、出力先の社内テンプレートや必須欄を貼り付けます。OpenAIの公式Prompting guidanceも、指示、背景、望む成果、形式などを明確にする方法を案内しています。特定の生成AIに限定せず、以下のように「推測禁止」「未確認を表示」「原資料へ戻れる参照」を指定します。

目的：次の事実を社内稟議の下書きに整理する。

承認してほしいこと：[一文]

確認済み事実：[項目と出典]

仮説：[前提と試算方法]

未確認：[要確認項目]

制約：入力にない金額・効果・契約条件・法務判断を追加しない。

出力：社内様式の各欄に分け、事実・仮説・未確認をラベル表示する。

最後に、承認者が判断するため不足している情報を箇条書きで返す。

一度目の出力をそのまま申請書へ貼らず、次の順で直します。まず事実と推測が混ざっていないか確認し、次に承認事項が具体的か、最後に社内の用語・文体・欄順へ合わせます。文章の自然さを先に直すと、根拠のない効果や費用まで整った文として残るおそれがあります。

費用・効果・リスクを検証する

金額は見積書や契約画面の記載に従い、月額か年額か、税別か税込か、最低契約期間、自動更新、利用人数、超過料金、解約方法を分けて確認します。料金ページは閲覧時点の情報として記録し、個別見積がある場合は公開価格より契約書を優先します。AIに料金を検索させた場合も、原資料と一致するか担当者が再確認します。

効果欄では、試算と実績を分離します。「作業時間を削減できる見込み」と「試行後に実測した削減時間」を同じ書き方にしません。試行を計画するなら、対象業務、測定期間、比較する現状値、例外処理、成功条件を明示します。母数の小さい試行結果を全社へ一般化しないことも大切です。導入しない場合のコストや、既存運用を改善する案を比較対象に入れると、承認者が「導入するか」だけでなく「何を変えるべきか」を検討できます。

リスク欄は、情報管理、運用負担、既存システムとの連携、誤出力の確認責任、ベンダー依存などを対象範囲に応じて整理します。チェックしていない項目を「問題なし」と書かず、「情報システム部門の確認前」「契約条件確認中」と状態を明記します。リスクの高い申請では、関係部署へ渡す確認事項と承認前の停止条件を具体化します。

社内情報を扱う前に確認する

社内申請には、顧客情報、従業員情報、未公開の見積や事業計画が含まれる場合があります。どのAIサービス・アカウントへ入力してよいかは、組織の情報分類、契約、管理者設定によって異なります。一般向けアカウントに入力してよいと決めつけず、社内ポリシーで許可された環境を使います。承認前の資料をAIへ送ること自体が禁止されている場合は、社内で許可されたテンプレートやローカル手段に切り替えてください。

不要な氏名・顧客名・契約番号を除く、固有情報を置換する、必要な箇所だけ抜き出すなど、データを最小限にします。ただし匿名化で元の意味が壊れるなら、無理に変換せず担当者に確認します。プロンプトや生成結果の保存・共有権限も、稟議の機密区分に合わせます。

起案者・承認者の最終チェック

提出前に次の項目をひとつずつ原資料へ照合します。

• 申請者、対象部署、利用範囲、開始希望日が正しい

• 金額、税、契約期間、更新・解約条件が資料と一致する

• 実績・試算・未確認が区別されている

• 誰が何を承認するかが冒頭で分かる

• 代替案と導入しない場合の影響が必要な範囲で説明されている

• 承認者が見るべき添付資料、担当部署、期限がそろっている

• 生成文に存在しない社内ルールや事実が混じっていない

最後に、起案者が各欄の根拠を説明できるかを確認します。説明できない表現は、AIらしい整った文章でも提出しません。承認者は文章の出来栄えではなく、判断材料の不足と意思決定範囲を見ます。

AIものさしの判断

AIは稟議の決裁者にも、費用・効果の根拠にもなりません。素材の分類、欄ごとの下書き、読みやすさの整理に使い、数字・規程・契約・リスクの確認は責任者が行う構成が適切です。対象範囲と根拠を揃えられない時は、文章作成を進めるより「要確認」を埋めるところで止めます。

具体例：導入稟議の素材から提出案まで

以下は手順を説明する架空の例です。実際の会社やツールの効果を示す実績ではありません。申請者は、社内FAQの問い合わせ履歴を検索できるようにする案を検討し、承認者へ「対象チームで試行を開始してよいか」を判断してもらいたいとします。

最初の素材は、次のように分けます。

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

素材	例として記録する内容	状態
現状	問い合わせ記録が複数の場所に分かれている	担当者が記録を確認
課題	過去の回答を探すのに時間がかかる	測定方法と期間を記す
施策	対象チームで検索ツールを試す	提案
費用	見積書・契約条件を参照	見積取得前なら要確認
効果	検索時間の変化を試行前後で測る	期待であり実績ではない
リスク	権限設定、データ移行、運用担当	情報システム等の確認待ち

この素材からAIに作らせるのは、承認事項、背景、目的、選択肢、費用欄、期待効果、リスク、未確認事項の下書きです。料金や削減時間の欄を空欄のままにし、文章が完成して見えても未確定項目を残します。試行の開始日や終了日、対象チームが決まっていなければ、稟議本文へ断定的に挿入せず、決裁対象として提示するか事前に確定します。

提出前は、AIの文面を原資料へ戻して一文ずつ点検します。「問い合わせ対応を効率化する」は目的の説明であって、削減効果の証拠ではありません。「効果が見込まれる」と書くなら、どのデータからその見込みを作ったのか、試行後に何を計測するかを添えます。根拠がなければ「効果は試行で測定する」と表現します。

稟議が通らない原稿を直す診断

承認者が判断できない原因を、文章の長さではなく不足している判断材料から探します。

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

症状	原因の候補	直す順番
何を決めるか分からない	承認事項が広い	対象・期間・選択肢を特定
費用が比較できない	税・人数・期間が不明	見積条件を同じ単位に揃える
効果が大きく見える	仮説を実績のように記載	出典・前提・測定計画を付ける
リスクが「問題なし」だけ	確認部署と項目が不明	未確認・確認済みを分離
説明が長い	背景と判断材料が混在	判断事項→根拠→補足の順へ整理
代替案がない	導入ありきの構成	現行継続・小規模試行等も並べる

書き直しでは、表現を簡潔にしただけで判断条件が欠けていないか確認します。稟議の様式、必要な添付、決裁区分は会社ごとに異なります。社内の正式templateや規程がある場合、この記事の例よりそちらを優先します。