ChatGPT Projectsへ会社の資料をまとめるときは、ファイル形式ではなく、目的・顧客・権限・保存期間の4つで分けます。目的の違う業務や複数顧客の資料を同じ場所へ入れると、どこまで参照し、誰と共有してよいのかが曖昧になるためです。
実データを入れる前に、ダミー資料で一つの業務だけ試します。便利な置き場所を先に作るのではなく、入れてよい情報と止める条件を決めてから使い始める順番です。
この記事でわかること
- Projectsを分ける4つの基準
- 入れる情報、別にする情報、最初は入れない情報
- 共有とプロジェクト限定メモリを使う前の確認点
- ダミー資料で一つの業務を試す手順
- 自分で進められる範囲と、社内確認を挟む条件
Projectsはファイル形式ではなく作業の境界で分ける
一つのプロジェクトには、関連するチャット、ファイル、指示をまとめられます。だからこそ「PDF用」「議事録用」といった形式ではなく、何のために誰が使う場所かで分けるほうが整理しやすくなります。
たとえば「営業資料」というプロジェクトへ、共通の会社案内、顧客Aへの提案書、顧客Bとの打ち合わせメモをまとめるとします。ファイルの種類は近くても、使う目的と見せてよい相手は同じではありません。後から共有メンバーを増やしたとき、どこまで見せてよいかを一件ずつ確認することになります。
私なら、共通資料は「営業資料テンプレート」、顧客ごとの資料は「顧客A」「顧客B」と最初から分けます。プロジェクト名が増える面倒より、入れてよい資料を毎回迷わないことを優先します。
目的・顧客・権限・保存期間の4つで分ける
四つのうち一つでも扱いが違うなら、別プロジェクトにする候補です。特に顧客と権限が違う場合は、同じ場所へまとめないほうが判断を単純にできます。
| 基準 | 確認すること | 分ける目安 |
|---|---|---|
| 目的 | 何を作る場所か | 問い合わせ返信と採用原稿のように、成果物や確認者が違う |
| 顧客 | 誰の情報を扱うか | 顧客、案件、契約ごとに資料の取り扱いが違う |
| 権限 | 誰が見て、編集し、共有できるか | 参加メンバーや担当範囲が違う |
| 保存期間 | いつ見直し、削除するか | 案件終了後に消す資料と、継続して使う共通資料が混ざる |
「同じ部署が使うから一緒」で決めると、境界が広がりがちです。部署ではなく、作業の出口を見ます。完成物、確認する人、利用を終える時期が同じなら、一つにまとめやすい状態です。
保存期間は、Projects内に期限を書くだけで終わりません。プロジェクトへ追加したファイルは、プロジェクトを削除するまで保持されるという案内があります。削除後の処理にも期間と例外があるため、自社の「いつ消すか」とサービス側の保持のしかたは分けて確認します。
案件終了日、見直す担当者、削除判断を記録する場所まで決めておくと、置いたままになりにくいです。
入れる情報・分ける情報・入れない情報を先に決める
資料を追加するたびに担当者が悩む運用は続きません。最初に三つへ分け、迷うものは「入れない」側へ置いて社内で確認します。
| 扱い | 情報の例 | 判断 |
|---|---|---|
| 継続して入れやすい | 公開済みの会社情報、承認済みの文章ルール、共通テンプレート、匿名化したFAQ | 目的と利用者が同じプロジェクトへまとめる |
| プロジェクトを分ける | 顧客別の原稿、案件メモ、個別の問い合わせ記録、社内限定の作業手順 | 必要性と社内ルールを確認し、顧客・案件・権限ごとに分ける |
| 最初は入れない | パスワード、APIキー、秘密鍵、決済情報、不要な個人情報、利用許可のない契約書や他案件の資料 | 代替データで進める。必要になっても担当者だけで判断しない |
匿名化する時は、氏名を消しただけで終わりません。会社名、メールアドレス、電話番号、注文番号、日時。これらは単体では問題なく見えても、組み合わせると相手が特定できてしまうことがあります。
判断に必要な項目だけ残して、あとは削る。プロンプトを工夫するより、こちらを先に片づけます。
問い合わせメールを使う場合は、氏名以外に消す情報と匿名化テンプレートへ一度移し、要件だけにしてからプロジェクトへ追加します。
共有する前に、参加者と役割を決める
共有プロジェクトでは、参加者が同じファイル、指示、会話履歴を使って作業できます。共有してから資料を整理するのではなく、誰が何を扱うかを決めてから招待する順番が合っています。
最低限、次の項目を共有前のメモへ残します。
- プロジェクトの所有者
- 参加してよい人
- ファイルや指示を変更してよい人
- 新しい参加者を招待してよい人
- 案件終了や異動時に参加者を見直す日
共有できる範囲や権限の表示、参加人数の上限は、契約プランやワークスペースの設定で変わります。ここで押さえておきたいのは、画面に共有ボタンがあることと、その資料を社内で共有してよいことは別の話だという点です。ボタンは、社内ルールを知りません。
対象アカウントの設定と社内ルールの両方がそろうまでは、実データを入れずに止めておきます。
プロジェクト限定メモリだけに境界を任せない
プロジェクト限定メモリは、同じプロジェクト内の会話を参照し、プロジェクト外の会話を参照しないための設定です。ただし、一つのプロジェクト内へ複数顧客の資料を入れた場合、その内側まで顧客別に分離してくれる設定ではありません。
つまり、メモリ設定は境界を補助しますが、分類の代わりにはなりません。顧客Aと顧客Bを別プロジェクトに分けたうえで、利用環境に合うメモリ設定を確認する順番です。
既存プロジェクトの設定状態や、利用に必要なメモリ設定はアカウントによって確認が必要です。表示が分からないまま「たぶんプロジェクト限定だろう」と判断せず、実データを入れる前に管理者へ確認します。
実データの前にダミー資料で一つの業務を試す
最初の検証では、実在する顧客名、問い合わせ、契約情報を使いません。架空の内容で一つの成果物を作り、入力から人の確認までの流れを見ます。
問い合わせ返信の下書きを例にすると、次の順番で試せます。
- 「問い合わせ返信テスト」という検証用プロジェクトを作る
- 架空の問い合わせと、公開しても問題のない回答ルールを用意する
- プロジェクト指示へ、目的、出力形式、参照してよい資料、判断できないときの扱いを書く
- 返信の下書きを作り、元資料にない内容や固有名詞が足されていないか人が確認する
- 指摘を反映した再出力まで試し、誰が最終確認するかを記録する
- 入れる情報、入れない情報、中断条件を見直す
この検証で見るのは、文章のうまさではありません。必要なファイルをちゃんと参照できたか、指示にない情報を勝手に補っていないか、担当者が確認しやすい形で出てきたか。この3つです。
4番目に「人が確認する」を入れているのは、意図的です。私は、AIに全部を任せきらないほうが結果的に速いと思っています。
資料を集めて下書きを作るところまでは、驚くほど早い。ただ、顧客名や金額が元資料と合っているか、この内容を本当に社外へ出していいのか。
最後のこの部分は人が持ったままにしておく。そのほうが、安心して残りを任せられます。
うまくいっても、すぐ実データへ置き換えません。共有範囲とデータ設定を確認してから次へ進みます。
この業務を外部アプリの操作まで広げる場合は、送信・公開の直前に置く承認ルールも先に決めます。資料の置き場所と、実行を許可する範囲は別の設計です。
自分で進められる範囲と、いったん止める条件
公開情報とダミー資料だけを使い、共有せずに一つの業務を試すところまでは進めやすい範囲です。目的、入力、完成条件、人が確認する項目を一枚のメモへ整理すれば、プロジェクトを分ける基準も見えてきます。
次に当てはまる場合は、実データの追加をいったん止めます。
- 顧客情報や個人情報を扱うのに、利用許可と社内ルールが分からない
- 複数部署や社外の人と共有するが、参加者と権限を決めていない
- プロジェクトの所有者、見直し日、削除する人が決まっていない
- 契約プラン、メモリ、データ利用、保持ポリシーの設定を確認できない
- 法務、情報セキュリティ、契約上の判断が必要
法令や契約への適合は、AI活用の相談だけで確定できるものではありません。必要な場合は、社内の管理者、情報セキュリティ担当、法務担当などへ確認する範囲です。
おわりに
ChatGPT Projectsへ会社の資料をまとめるときは、ファイルの種類より、目的・顧客・権限・保存期間を先に見ます。公開情報とダミー資料で一つの業務を試し、入れる情報と止める条件を決めるところまでは自分でも進められます。
顧客ごとの分け方や、人が確認する工程まで決めきれずに止まっている。そんな場合は、まず一つの業務に絞るところからお力になれるかもしれませんので、お気軽にご相談ください。
