AIに社内資料を読ませたいとき、先に考えたいのは保存場所よりも、その情報を今回の仕事に使ってよいかです。完成した提案書、会議メモ、古いFAQが同じ場所にあっても、使える範囲と確かさは同じではありません。
この記事では、担当者が少量の資料から始めるための仕分けを提案します。法務判断や全社共通の情報管理規程に代わるものではありません。所属先のルールや契約条件を優先してください。
例：前回の提案を、次の提案準備に使いたい
新しい担当者が、過去の提案書から参考になる説明を探す場面を考えます。フォルダには、公開済みのサービス説明、社内で確認した提案の型、顧客固有の条件が混ざっています。資料を丸ごとAIへ渡す前に、各項目の利用範囲を見ます。以下は説明用の架空例です。
1. 今回の仕事に使える
利用目的と共有範囲が明確で、内容も現行と確認できた情報です。たとえば、担当者が現在の公式ページと照合したサービス説明。AIが下書きの参考に使う場合も、最終表現は人が原資料と照らします。
「使える」には、資料の出典、確認日、確認者、使える用途を一緒に残します。内容が変われば、以前の判断をそのまま引き継ぎません。
2. 条件付きで使える
社内で共有できても、案件や時期によって意味が変わる情報です。たとえば、過去の提案で採用した進め方。次の担当者が参考にする際は、どの条件で採用されたかを読み、人が今回との違いを判断します。
顧客名や個別の取引条件が含まれる資料では、転用してよい部分と取り除く部分を担当者が分けます。判断できないまま、別案件の下書きへ流し込みません。
3. 確認が済むまで使わない
出典が不明、古さが判断できない、閲覧・利用の権限が分からない情報です。AIへ渡す前に、情報の持ち主や確認者を探します。確認できない場合は、今回の入力から外します。
これは価値のない資料という意味ではありません。今は使える条件が揃っていない、という状態です。
1枚の台帳で、判断を次へ渡す
最初は複雑な分類システムを作らず、一つの資料について次の5項目を記録します。
| 項目 | 記録すること |
|---|---|
| 出典 | どの原資料から来たか |
| 確認日 | いつ内容を確かめたか |
| 利用範囲 | 誰が、どの業務で使えるか |
| 条件・除外 | どの部分は別確認が必要か |
| 確認者 | 判断を更新できる人は誰か |
一件から始め、次の担当者が実際に使うときに「使えた／追加確認した／使わなかった」と理由を戻します。資料が何件集まったかより、次の仕事で安全に判断できたかを見ます。
たとえば架空の「サービス紹介資料A」なら、出典を公式ページ、確認日を今週の照合日、利用範囲を社内の提案下書き、条件を「価格は別確認」、確認者を営業責任者として記録できます。価格の確認が終わる前に、過去資料にある金額を新しい提案へコピーしません。
使った結果も残します。AIが下書きに参考にした後、人が採用・修正・不使用を判断し、その理由を次の資料判断へ戻します。
株式会社BREW UPが説明するTeam Brainは、知識を蓄積して終えるのではなく、仕事で取り出し、人が確認し、結果を戻す循環を重視します。その全体像はTeam BrainとKnowledge Loopの記事で紹介しています。まずは手元の資料を一つ選び、上の5項目と三つの状態を確かめてみてください。
まとめ
資料をAIへ渡す前に、今回使える、条件付きで使える、確認が済むまで使わないの3状態へ分けます。まず1件の出典・確認日・利用範囲・条件・確認者を残し、使った後の採用・修正・不使用の理由も記録します。所属先の情報管理ルールや契約条件を優先してください。
私たちの考え方
株式会社BREW UPが目指すのは、資料の数を増やすことではなく、商談や提案で生まれた答えを次の担当者が使える状態にすることです。出典、利用条件、確認者に加え、使った後の修正理由を残せば、次の人は同じ資料を一人で読み解くところから始めずに済みます。新人は会社の経験を参照でき、マネージャーは同じ指摘の繰り返しを減らせます。その入口として、まず手元の資料1件を3つの状態に分け、5項目を書き添えてみてください。
