AIで申請書・社内依頼文を作る方法

申請書や社内依頼文をAIで作るなら、先に文書の種類、宛先、依頼内容、理由、期限、対象範囲、必要な承認を揃えます。情報を文章のまま一括で渡すより、固定項目に分けてから指定Templateへ当てはめる方が、抜けや誤った補完を見つけやすくなります。分からない項目はAIに埋めさせず、確認欄として残してください。

この方法は、購入申請、アカウント発行、社内作業依頼など、必要情報が定型化できる文書に向いています。複数案、投資効果、費用、リスクを比較して承認者に選択を求める場合は、単なる依頼文ではなくDecision Briefとして材料を整理します。社内様式や承認経路は組織ごとに異なるため、既存の文書規程・権限を確認してから草案を作ります。

依頼の入力項目を揃える

まず依頼する側が必ず入力する情報と、担当者が後で確認する情報を分けます。「必要なら適当に補完」のような指示は使わず、値がない時の扱いを決めておきます。宛先が複数ある、費用や期限が未定、承認が必要か不明といった例外を入力Schemaへ含めると、文面の後から手作業で探す負担を減らせます。

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

Field	入力する内容	未入力時の扱い
Document type	購入申請、依頼、アカウント発行など	文書種別を選択
Recipient / approver	宛先、承認者、担当窓口	確認待ち
Requested action	相手にしてほしい作業や決定	依頼者へ差し戻す
Background / reason	なぜ必要か、現状の課題	根拠の有無を確認
Scope	対象者、システム、数量、範囲	対象を特定
Deadline	希望日と理由	希望日か必須期限か確認
Cost / attachment	金額、見積、添付資料	未確認と表示
Unknowns	まだ決まっていない条件	草案に残して確認

入力を分けると、依頼者自身が「何をしてほしいのか」を見直せます。たとえば「アカウントを作ってください」だけでは、対象システム、権限、開始日、終了条件が不明です。権限は最小限か、既存申請が必要か、アカウントをいつ無効化するかを社内手順で確認します。AIに権限を推測させるのではなく、権限担当者や利用責任者へ確認する欄を作ります。

文書Typeごとの必須項目

一つの巨大なTemplateですべての文書を扱うと、無関係な空欄が増え、重要な項目が埋もれます。文書Typeごとに必須・任意・条件付きの項目を定義し、記入例と入力元を付けます。購入申請なら品目・数量・費用・見積、アカウント依頼なら利用者・権限・利用期間、作業依頼なら成果物・担当・期限など、業務に必要な情報だけを残します。

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

文書Type	主な確認項目	最終確認者
購入申請	品目、数量、費用、見積、予算区分	予算・購買担当
アカウント依頼	利用者、権限、期間、承認、無効化条件	システム管理者
作業依頼	成果物、担当、期限、前提、依存先	依頼者と実行担当
社内案内	対象者、開始日、適用範囲、問い合わせ先	発信責任者

これは構造例です。実際の申請要件は組織の決裁規程、システム運用、職務権限に合わせて定義してください。金額や権限のしきい値を一般例からコピーしないでください。様式の改訂時は、どの部署がSchemaを管理し、必須項目の変更を誰が承認するかを明確にします。

指定TemplateへDraftを当てはめる

入力内容と文書構成を別々に管理します。依頼者は項目Schemaへ事実を入力し、文書生成では承認済みTemplateの見出しと順序を使います。指定された文体へ整えるために、背景や理由の意味を強くしたり、未確定の依頼を決定済みに書き換えたりしてはいけません。出力には、入力値をそのまま使った箇所と、表現だけを整えた箇所が分かるとレビューしやすくなります。

Promptの例

「次の入力情報だけを使い、指定された社内Templateの順番で申請書の草案を作成してください。依頼事項、背景、対象範囲、期限、費用、承認者を別の項目にしてください。未記入の値は推測せず『確認待ち』と表示し、金額、日付、権限、承認状態を追加しないでください。入力内容に矛盾がある場合は文面を完成させず、矛盾箇所と依頼者へ確認する質問を一覧にしてください。社内規程や承認権限を推測せず、判断が必要な箇所は担当者確認として残してください。」

出力後は、元入力と草案を並べて値を照合します。数字・日付・宛先・権限・添付・承認状態は、文章が読みやすくても必ず確認します。AIが入力の矛盾を一方へ寄せて解決した場合は、どちらが正しいか依頼者に確認するまで提出しません。承認済みの文書と、提出前の草案が同じ場所で混同されないよう、状態表示も既存ルールに従います。

架空例：アカウント発行を依頼する

新入社員向けの業務システムアカウントを申請する架空例を考えます。依頼入力には、利用者ID、所属、利用開始予定、必要な業務、上長承認、希望する権限、利用終了条件を置きます。実在する従業員情報を例に使わず、架空の値で文書の構成だけを示します。権限名は組織の正式な一覧から選び、職務に必要な範囲を管理者が確認します。

入力者が「通常権限」とだけ書いた場合、AIに権限の内容を作らせません。権限一覧から選ぶ欄を未入力として残し、システム管理者へ確認します。利用開始日が未定なら「開始日確認待ち」とし、承認が済んでいない場合は「承認依頼中」とします。下書きを整えることと、実際にアカウントが作成されたことは別状態であることを明確にします。

失敗時の切り分け

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

症状	原因候補	対応
空欄をAIが自然に補う	未入力ルールが曖昧	Unknownを明示し、生成後に差し戻す
宛先や権限が間違う	参照元や承認者が未定	正式な一覧・管理者へ確認
費用や期限が変わる	原文とDraftを照合していない	入力値との比較表を確認
Templateの順が崩れる	形式指定が弱い	承認済みTemplateを明示
依頼が承認済みに見える	文書状態が不明	草案・申請中・承認済みを区別
個人情報が不要に含まれる	入力範囲が過剰	必要性と共有範囲を確認

AIへ社内情報を渡す前に、利用環境の承認、保存、閲覧範囲、個人情報の扱いを確認します。汎用の依頼文を作るだけなら、匿名の架空例や機密を含まない入力でTemplateとPromptを調整できます。実データを使う必要がある場合は、人事・情報管理・システム管理等の担当者が許可範囲を確認してから処理します。

Human Reviewと版管理

草案を提出する前に、依頼者は依頼内容・背景・期限、承認者は権限・費用・必要添付、実行担当は実施条件を確認します。確認者の役割は組織の規程に合わせます。修正があった場合は、入力値を変えたのか、文章だけを整えたのか、承認条件を変更したのかを区別します。重要項目を後から変えた場合は、元の承認がその変更を含むか担当者へ確認します。

同じ様式を繰り返し使う場合は、Templateの版、必須項目、更新日、管理担当を記録します。Template変更によって承認項目が抜けた場合、生成AIは見た目を整えても欠落を検出できないことがあります。新しい版を使う前に、典型入力、空欄、矛盾、費用欄、権限欄を含むテストを行います。文章の自然さだけでなく、必要情報の保持を確認してください。

次にすること

まずよく使う文書Typeを一つ選び、必須項目・確認者・未入力時の扱いを表にします。次に現行Templateを固定し、架空データと未入力例で草案を作って、値が補完・変更されないか照合します。問題がなければ、組織の承認済み環境と運用ルールの範囲で利用を検討します。

AIものさしの判断

定型の申請や依頼は、入力SchemaとTemplateを分けると抜けを見つけやすくなります。AIは指定形式への整理を助けますが、事実、権限、費用、承認状態を確定するのは依頼者・承認者・実行担当です。最初の適用では一つの文書Typeだけを対象にし、空欄や矛盾を安全に確認待ちへできるかを確かめてください。

入力チェックの境界を決める

同じ依頼に開始日が二つある、宛先が役職名だけで個人か窓口か分からない、費用が税抜・税込で混在するといった矛盾は、文章生成で解決しません。事前に入力Validationとして、必須項目の空欄、日付の前後関係、金額単位、選択肢外の値を検出します。AIへ自然な表現へ直させる前に、元入力の矛盾として依頼者へ返してください。Validationの条件は、文書Typeを管理する担当者が承認し、変更時にはテスト入力を更新します。 矛盾がないことを確認できたら、草案に使った入力の版と文書Templateの版を記録します。申請者が内容を変更して再生成した場合は、どの変更が本文へ反映されたか確認し、古い承認状態を引き継がせません。 承認後に費用、対象者、権限、期限が変わった場合は、元の申請の範囲内かを人が判断し、必要なら再申請します。草案作成の自動化と、社内決裁そのものを同じ処理にしないでください。 依頼文を自動生成する範囲と、正式な提出・決裁の操作権限も分離しておくと、誤送信や未承認実行を防ぎやすくなります。

更新後の運用を確かめる

Templateや必須項目を変更したときは、以前の入力例だけでなく、未入力・矛盾・権限未確定のケースを再テストします。新しい版で必須情報が抜けたり、承認状態を誤表示したりしないか、依頼者と管理担当が確認します。変更前の版を使った申請が残る場合は、どの版が適用されたか追跡できるようにします。