AIで報告書の下書きを作るときは、メモをそのまま「報告書にして」と渡すより、目的・読み手・元資料を決め、事実、判断、未確認事項を分けてから構成を作る方が安全です。AIには文章の整理や下書きを任せても、根拠にない数字や原因を埋めさせません。完成条件は読みやすい文章ではなく、原資料に戻れる形で読み手が判断できることです。
ChatGPTやGeminiのファイル機能は、文書や表などを扱うための案内を提供していますが、対応形式や容量、アカウント条件はサービスと利用面によって異なります。ファイルを添付できたことは、すべての情報を正確に読み取った証明にはなりません。まず目的に必要な資料を絞り、出力した事実を原文と照合します。
目次
報告書の用途と読者を一文で決める
最初に「誰が読み、何を判断する報告書か」を書きます。障害報告なら原因、影響、復旧、再発防止が必要かもしれません。進捗報告なら完了、未完了、遅延理由、次の期限が中心です。顧客向けの実施報告なら、約束した作業、実際の結果、残課題、問い合わせ先などを確認します。目的が違えば、必要な見出しも変わります。
読み手が経営層なのか現場担当なのかも明示します。同じ事実でも、意思決定者には影響と選択肢、実務担当には作業の再現条件やログが必要です。文章を短くするだけではなく、読み手が判断するための情報を残します。
メモを原資料と一緒に整理する
会議メモ、作業ログ、メール、表計算、数値集計を分け、各資料の作成日、担当、対象期間を記録します。メモだけで意味が確定しない項目は、AIへ渡す前に原資料を探します。入力する情報に個人情報、顧客情報、社外秘が含まれるなら、社内ルールと利用サービスの設定を先に確認し、許可が不明なら匿名化や承認を行います。
資料の版が複数あるとき、どれを正本にしたか明記します。AIがファイル名や内容の新しさだけで最新版を確定するとは限りません。古い資料と新しい資料を混ぜる場合は、対象期間と優先する版を指示します。報告の結論が変わり得る欠落資料は、推測で埋めず未確認として扱います。
事実・判断・未確認を分離する
まず元メモから「原資料に書かれていること」だけを抽出します。次に、その事実からの解釈や原因の見立てを別欄に置き、判断担当を記録します。確認できていない事項は空欄のままにせず、[要確認]と担当者・期限を記します。こうすると、文章の自然さに引っ張られて仮説が事実として混ざる事故を減らせます。
例:
Fact:10月7日14時に決済処理のエラーが12件記録された。
Interpretation:特定の変更との関連が疑われるが、ログ照合前の仮説。
Unknown:影響ユーザー数と返金対象の有無は未確認。
Next action:担当者が決済ログを確認し、10月9日までに報告を更新する。
この例は形式説明用の架空データです。実際の事実を示すものではありません。
本文より先に見出し構成を確認する
AIへ最初から完成原稿を作らせず、目的に応じた見出しと必要な根拠を先に提案させます。提案された各見出しに、使う原資料、書ける事実、未確認事項を割り当てます。根拠がない節があれば資料を追加するか、その項目を削るか、未確認として保留します。見出しが埋まったこと自体を証拠にしません。
障害報告なら「概要」「発生時刻」「影響範囲」「暫定対応」「確認済み原因」「未確定事項」「恒久対応」「次回更新」のような候補がありますが、全部の報告書へ機械的に当てはめません。通常の進捗報告にインシデント節を入れる必要はないでしょう。読者の判断に不要な節は省きます。
下書きのための指示と出力形式
入力には、目的、読者、対象期間、使用資料、事実のみのルール、数字の単位、固有名詞、未確認の表し方、禁止する推測を含めます。報告書の下書きと同時に、根拠となったメモのIDやページを出力させると照合しやすくなります。
prompt例:
「以下の資料だけを使い、顧客向け作業報告の下書きを作成してください。事実、判断、未確認を区別し、資料にない原因・数字・約束は追加しないでください。根拠が見つからない項目は [要確認] とし、該当する資料名と箇所を添えてください。日時は日本時間、金額は元資料の単位を維持します。まず見出し案と不足情報を出し、承認後に本文へ展開してください。」
これはひな型であり、資料に基づく出力や正確性を保証しません。
節ごとに本文を作り、原資料へ戻る
構成が承認されたら、要点ごと、または見出しごとに本文を作ります。全資料を一度に長く要約させるより、根拠と対象範囲を絞るとチェックしやすくなります。重要な数字には、値、単位、対象期間、出典箇所をセットで残します。原資料にページ番号や行番号がある場合はそれを使い、後から確認できる形にします。
AIが「原因は設定変更」と書いても、ログや担当者確認がないなら確定事実にしません。時系列上の前後関係は原因を証明しません。再発防止策も、すでに合意された対応と提案段階の案を分け、責任者と期限を確認してから確定表現へ直します。
数字・固有名詞・引用を重点QAする
件数、金額、割合、日付、version、顧客名、部署名、サービス名、契約条件は、特に取り違えやすい項目として原資料と照らします。合計値が一致しても母数や期間が異なれば結論は変わります。引用文は元の文脈を保ち、発言者や日時を確認します。
校正では、事実の正しさ、論理のつながり、読み手が次に行うことを別々に見ます。本文だけを読んでも「何が起き、何が分かり、何がまだ分からず、次に誰が何をするか」が追える状態を目指します。機密情報の宛先誤りや添付資料の共有権限も、提出前に確認します。
読者に合わせて情報を残す
役員向けなら冒頭に結論、事業影響、必要な判断を置き、詳細ログは別添に分けることがあります。現場向けなら、再現条件、作業手順、確認箇所、担当引き継ぎを残します。顧客向けなら内部仮説や個人情報を不用意に含めず、契約上の説明範囲と承認済みの約束を確認します。
削るときは、判断に必要な条件や例外を先に落とさないようにします。要約によって「一部」が「全て」に変わる、「暫定」が消える、「予定」が確定に見える、といった変化は重要です。短い文章でも誤読されないか、読み手の立場から確認します。
AIものさしの判断
報告書づくりでAIに任せるのは、原資料の整理、構成案、文章の下書き、見落とし候補の提示までです。事実と判断を分け、数字や原因を原資料へ戻して確認し、提出責任者が最終承認します。機密情報は利用規程とサービス条件を確認するまで入力しません。
まず小さな報告書一件で、使用資料、Fact/判断/Unknownの一覧、見出し案、原資料への参照、最終承認者を試してください。原文に戻れる状態が保たれ、読者が判断と次の行動を取れるなら本文を完成させます。不明な根拠が残る箇所は公開・提出前に保留します。
報告書の受入チェック
表は横にスクロールできます
| 項目 | 質問 |
|---|---|
| 目的 | 読み手が判断することが冒頭にあるか |
| 根拠 | 重要な事実に原資料と参照箇所があるか |
| 境界 | 事実・仮説・未確認が見分けられるか |
| 数値 | 単位、対象期間、母数を照合したか |
| 行動 | 担当者、期限、次の確認が分かるか |
| 情報管理 | 入力・出力・添付先が許可範囲内か |
一項目でも未確認なら、その箇所を確定表現にせず、責任者と確認期限を付けます。
提出後の修正可能性を残す
報告書は保存先、版番号、承認者、元資料を紐付けます。後から誤りが見つかった場合に、どの根拠を使い、誰が承認した版か追えるようにします。個人情報を含む資料は、必要以上のコピーを作らず、元ファイルの共有権限と報告書の配布先を確認します。
AIへ渡したファイルの扱い、保持期間、モデル改善への利用などは、サービスの利用形態やアカウント設定で条件が異なる場合があります。社内規程に不明点があれば、機密情報を送る前に管理者やセキュリティ担当へ確認します。報告書の下書き作成を理由に、組織の情報分類を省略しません。
使える下書きかを判定する
表は横にスクロールできます
| 確認項目 | 合格の目安 | 不合格時の扱い |
|---|---|---|
| 結論 | 冒頭の要点が本文根拠と一致する | 結論を原資料から書き直す |
| 数字 | 単位・期間・母数まで一致する | 集計元へ戻って再確認 |
| 原因 | 確認済み事実と仮説を分ける | 仮説を断定から外す |
| 不足情報 | 担当者と期限がある | 未確認として残す |
| 宛先 | 読み手に必要な情報だけ含む | 機密・内部情報を削る |
| 次の行動 | 担当、作業、期限が明確 | 責任者に確認してから確定 |
各項目の根拠を追えない場合は、文章が自然でもそのまま提出しません。特に表の合計値だけを照合して終わらず、母数、集計期間、除外条件が原資料と一致するか確認します。数字が複数の資料にあるなら、どの資料を採用したかを記録します。
作業を安全に小さく分ける
報告書の種類が違うと必要な情報も違います。進捗報告では完了・遅延・次期限、障害報告では影響・復旧・原因確認、顧客向け報告では約束した範囲・実施結果・残課題が中心になります。共通の見出しを機械的に埋めるより、読者が必要とする判断から逆算してください。
一度に大量のファイルを処理する場合は、まず機密情報を除いた短いサンプルで、抽出形式と根拠参照が崩れないかを確かめます。元資料を読み切れない、表の行列関係が不明、複数版のどれが有効か分からないときは、AIに補完させずその資料を対象外にします。入力できる形式かどうかと、組織として入力を許可しているかも別に確認します。
最終承認前の実務フロー
-
報告書の読者・判断事項・対象期間を記録する。
-
正本資料と使用版を固定し、機密区分と入力許可を確認する。
-
事実、判断、未確認を分けた一覧を作る。
-
見出し案と不足資料を人が確認する。
-
節ごとに下書きを作り、根拠となる資料箇所を付ける。
-
数字、固有名詞、否定、条件、引用を原資料と照合する。
-
宛先・共有権限・承認者を確認して提出する。
途中で根拠が足りないと分かった場合は、その節だけ保留して資料を集めます。全文を再生成するより、誤りのある段落と根拠を指定して直す方が、確認済み部分を壊しにくくなります。提出後に訂正する可能性がある文書では版管理と変更履歴も残します。
引用・データ出典
公式情報を編集部が見た内容です。Hands-on未実施の記述は本文かここに分けています。
確認日:2026-10-08
OpenAI:File Uploads FAQ(新しいタブで開く)
Google:Geminiアプリでファイルをアップロードして分析する(新しいタブで開く)
OpenAI:File Uploads FAQ — https://help.openai.com/en/articles/8555545-file-uploads-faq(新しいタブで開く)
Google Gemini Help:Upload and analyse files in Gemini Apps — https://support.google.com/gemini/answer/14903178(新しいタブで開く)
