複数の協力会社とプロジェクトを進めるとき、仕様書・図面・作業指示書・進捗資料・納品データなどを安全に共有する仕組みが必要になります。メール添付ではファイルサイズや版管理に限界があり、クラウドストレージ上で協力会社向けのゲストIDを発行して共有するケースも増えています。

一方で、協力会社との外部共有では、「招待できること」だけでは不十分です。問題になりやすいのは、誰にIDを発行したかよりも、どの協力会社に、どのフォルダを、どの権限で見せているかです。共有範囲を少し広く設定しただけで、社内向け資料や他社との契約情報まで見えてしまうことがあります。プロジェクトが長期化すれば、当初の権限設定と実際の業務範囲がずれ、不要なアクセス権が残り続けることもあります。

本記事では、協力会社にゲストIDを発行してクラウドストレージを共有する際に、どのようにフォルダを分け、権限を設定し、契約終了時にアクセスを切り離すべきかを実務目線で整理します。

協力会社への外部共有で問題になること

協力会社との外部共有では、単に「外部ユーザーを招待している」こと自体が問題なのではありません。必要な相手に、必要な資料だけを、安全に共有できていれば、クラウドストレージはメール添付よりも管理しやすい手段になります。問題は、共有範囲がプロジェクトの実態に合っていないことです。

たとえば、協力会社に見せる資料だけをまとめたつもりでも、親フォルダの権限を継承していたため、プロジェクト全体のフォルダが見えていた。あるいは、A社向けの資料とB社向けの資料が同じフォルダに置かれており、協力会社間で本来見せるべきでない情報が見えていた。こうした事故は、ID発行そのものよりも、共有フォルダの設計ミスから起こります。協力会社共有で特に注意すべきなのは、次の3点です。

  • 協力会社ごとに見せる範囲が分かれているか
  • 編集・アップロードできる場所が限定されているか
  • 契約終了や担当範囲変更のタイミングでアクセスを外せるか

この3点が曖昧なままゲストIDを発行すると、プロジェクトが進むほど権限が複雑化し、後から整理しにくくなります。

協力会社共有で起きやすい4つの事故パターン

協力会社とのファイル共有では、技術的な不具合よりも、日常的な運用判断の積み重ねによってリスクが生まれます。ここでは、特に起きやすい事故パターンを整理します。

パターン1:親フォルダの権限を継承して、見せすぎる

もっとも起きやすいのが、フォルダ階層の設計ミスです。たとえば、「プロジェクトA」フォルダの中に協力会社向けの資料を置き、そのフォルダだけを共有したつもりだったとします。しかし実際には、親フォルダの権限を継承していたり、上位フォルダに広い権限が付いていたりして、協力会社からプロジェクト全体が見える状態になっていることがあります。

プロジェクト全体のフォルダには、社内向けの原価資料、他社との契約書、未確定の検討資料、顧客から受け取った機密情報などが含まれている場合があります。協力会社に必要なのは一部の仕様書だけだったとしても、階層設計を誤ると、本来見せる必要のない情報まで外部に出てしまいます。

協力会社向けの共有では、社内用の作業フォルダと、外部共有用のフォルダを分けることが基本です。社内で使っているプロジェクトフォルダをそのまま共有するのではなく、外部共有専用の領域を作り、そこに必要な資料だけを配置する設計にしてください。

パターン2:複数の協力会社を同じフォルダに入れてしまう

複数社が関わるプロジェクトでは、協力会社ごとに共有すべき情報が異なります。設計会社には図面を共有する必要がある一方で、施工会社には作業手順書だけを見せればよい場合があります。制作会社には素材データを渡すが、見積資料は見せない。保守会社には運用手順書を共有するが、開発中の仕様書は見せない。実務では、このように会社ごとに共有範囲が変わります。

それにもかかわらず、「協力会社共有」フォルダを1つだけ作り、関係する外部ユーザーをまとめて招待してしまうと、各社が必要以上の情報を見られる状態になります。特に、同じプロジェクトに競合関係のある外部会社が関わる場合、協力会社間で資料が見えてしまう状態は避けるべきです。協力会社ごとに見せる情報が異なる場合は、次のように分けるのが安全です。

  • 協力会社A社用フォルダ
  • 協力会社B社用フォルダ
  • 全社共通で見せる資料フォルダ
  • 納品物を受け取る専用フォルダ

「全社共通で見せてよい資料」と「会社ごとに分ける資料」を最初に切り分けておくことで、後から権限を修正する負担を減らせます。

パターン3:納品・提出用フォルダに編集権限を広く付けすぎる

協力会社にファイルを提出してもらう場合、アップロード権限が必要になります。ただし、アップロードできることと、既存ファイルを編集・削除できることは別です。

たとえば、納品物を提出してもらうために編集権限を付与した結果、協力会社が過去の納品ファイルを上書きしてしまう、他社が提出したファイルを削除してしまう、社内側が確認中のファイルを誤って更新してしまう、といった事故が起こることがあります。納品・提出用のフォルダでは、可能であれば次のように権限を分けてください。

  • 協力会社はアップロードのみ
  • 自社担当者は閲覧・移動・承認が可能
  • 他社の提出物は閲覧できない
  • 確定版フォルダは自社側のみ編集可能

特に、提出物を受け取る場所と、確定版を保管する場所は分けるべきです。協力会社が作業する領域と、社内で正式管理する領域を分けることで、誤更新や誤削除のリスクを下げられます。

パターン4:契約終了後もプロジェクトフォルダに残り続ける

協力会社との契約が終了しても、クラウドストレージ上のアクセス権が自動的に消えるとは限りません。契約書上の業務期間が終わっていても、ゲストIDや共有フォルダの権限が残っていれば、元協力会社が引き続き資料にアクセスできる状態になります。特に、プロジェクト担当者が異動・退職した場合、誰がその外部共有を管理していたのか分からなくなり、残存権限が見落とされやすくなります。

協力会社共有では、契約終了日、検収完了日、プロジェクト離脱日などを、アクセス権見直しのタイミングとして明確にしておく必要があります。「契約が終わったらそのうち消す」ではなく、契約終了時の作業項目に、ゲストIDの無効化・共有フォルダの権限削除・提出物の保管場所移動を含めるべきです。

協力会社向けフォルダ設計の基本

協力会社との共有で重要なのは、発行するIDの数よりも、フォルダ構成です。フォルダ構成が曖昧なままIDを発行すると、後から権限を細かく調整しようとしても、どこを直せばよいか分からなくなります。

社内用フォルダと外部共有用フォルダを分ける

まず、社内用のプロジェクトフォルダと、外部共有用のフォルダを分けます。社内用フォルダには、検討中の資料、社内メモ、原価情報、他社との契約情報、顧客から受領した機密資料などが含まれます。これらは、協力会社に共有する資料とは性質が異なります。

外部共有用フォルダには、協力会社に見せてよい資料だけを配置します。社内用フォルダの一部をそのまま共有するのではなく、必要な資料を外部共有用フォルダにコピーまたは移動して共有する運用にした方が安全です。例としては、次のような構成です。

  • プロジェクトA_社内用
  • プロジェクトA_外部共有用
  • プロジェクトA_協力会社A社用
  • プロジェクトA_協力会社B社用
  • プロジェクトA_納品受領用

このように分けることで、社内資料と外部共有資料の境界が明確になります。

会社別フォルダと共通資料フォルダを分ける 

すべての協力会社に同じ資料を共有する場合と、会社ごとに異なる資料を共有する場合を分けて設計します。複数の協力会社に共通して見せてよい資料は、共通資料フォルダに置きます。 たとえば、全体スケジュール、共通仕様、作業ルール、連絡先一覧などです。

一方、会社ごとに内容が異なる資料は、会社別フォルダに分けます。A社向けの作業指示書、B社向けの見積関連資料、C社向けの納品データなどを同じフォルダに置かないようにします。共通フォルダと会社別フォルダを混在させると、権限設定が複雑になります。フォルダの役割を最初に分けておくことで、権限設定のミスを減らせます。

提出用フォルダと確定版フォルダを分ける

協力会社からファイルを受け取る場合は、提出用フォルダと確定版フォルダを分けます。提出用フォルダは、協力会社がファイルをアップロードする場所です。ここでは、アップロード権限が必要になります。一方、確定版フォルダは、自社側で確認・承認したファイルを保管する場所です。ここに協力会社の編集権限を残す必要はありません。

この2つを分けないと、協力会社が確定版ファイルを上書きしてしまう、確認前のファイルと承認済みファイルが混在する、どれが最新版か分からなくなる、といった問題が起こります。納品や成果物管理を行う場合は、少なくとも以下のような構成を検討してください。

  • 01_共有資料
  • 02_協力会社提出用
  • 03_社内確認中
  • 04_確定版
  • 05_アーカイブ

協力会社に編集・アップロード権限を与えるのは、原則として「02_協力会社提出用」までに限定します。

協力会社に付与する権限の考え方

協力会社への権限設定では、「業務に必要な最小限」を基準にします。ただし、実務では単に閲覧のみ・編集可という二択では足りません。資料の用途に応じて、閲覧、ダウンロード、アップロード、編集の範囲を分ける必要があります。

閲覧のみで足りる資料

仕様確認、作業ルールの確認、スケジュール確認など、協力会社が内容を参照するだけでよい資料は、閲覧のみを基本にします。たとえば、作業手順書、共通ルール、参考資料、全体スケジュールなどです。これらは、協力会社が内容を書き換える必要はありません。ダウンロードを許可するかどうかは、資料の機密度や業務上の必要性に応じて判断します。

特に、社外に保存されたくない資料や、最新版を常に参照してほしい資料は、ダウンロードを制限し、クラウド上で閲覧してもらう運用が適しています。

ダウンロードを許可する資料

図面、仕様書、作業用データなど、協力会社が自社環境で確認・加工・印刷する必要がある資料は、ダウンロードを許可する場合があります。ただし、ダウンロードを許可すると、ファイルのコピーが協力会社側に残ります。契約終了後にクラウド上の権限を削除しても、ダウンロード済みファイルまでは消せません。そのため、ダウンロードを許可する資料は、事前に範囲を絞る必要があります。

ダウンロードを許可する場合は、以下を確認してください。

  • その資料は社外保存されてもよいか
  • 最新版管理が必要な資料ではないか
  • 契約終了後の取り扱いを契約・業務ルールで定めているか
  • ダウンロードログを確認できるか

重要資料については、ダウンロードを許可する代わりに、透かし、閲覧期限、ログ確認などを組み合わせることも検討します。

アップロードを許可する資料

納品物、報告書、作業結果、画像データなどを協力会社から提出してもらう場合は、アップロード権限が必要です。ただし、アップロード権限を付与するフォルダは限定してください。プロジェクト全体フォルダに編集権限を付けるのではなく、提出専用フォルダを作り、そのフォルダだけにアップロードを許可します。

提出専用フォルダでは、他社の提出物が見えないようにすることも重要です。複数の協力会社から成果物を受け取る場合は、会社別に提出先を分けるか、提出者が他のファイルを閲覧できない設定にします。

編集権限を許可する資料

共同編集が必要な資料に限り、編集権限を付与します。たとえば、進捗管理表、課題管理表、レビューコメント用の資料などです。ただし、編集権限は誤更新や削除のリスクが高いため、対象ファイルと期間を限定します。編集権限を付与する場合は、次の条件を満たしているか確認してください。

  • 編集対象のファイルが明確である
  • 編集できる期間が決まっている
  • 変更履歴やバージョン管理を確認できる
  • 編集不要になった時点で閲覧権限へ戻せる
  • 誤更新時に復元できる

「とりあえず編集可」は避けるべきです。編集が必要な場面だけ、一時的に付与する運用にします。

協力会社共有の業務シーン別設定例

協力会社との共有は、業務内容によって適切な権限が異なります。以下は、実務でよくあるシーン別の考え方です。

シーン1:図面・仕様書を協力会社に共有する

建設、製造、システム開発などでは、図面や仕様書を協力会社に共有する場面があります。この場合、協力会社が資料を確認するだけであれば閲覧のみ、印刷や作業用の確認が必要であればダウンロード可にします。ただし、図面や仕様書は最新版管理が重要です。古い版を参照して作業されると、手戻りや品質問題につながります。

そのため、図面・仕様書を共有する場合は、最新版フォルダと過去版フォルダを分け、協力会社には最新版フォルダを参照してもらう運用が必要です。過去版を残す場合も、協力会社が誤って参照しないように、フォルダ名や権限で区別します。

シーン2:協力会社から納品物を受け取る

制作物、報告書、画像、設計データなどを協力会社から受け取る場合は、提出専用フォルダを作成します。協力会社には、提出用フォルダへのアップロード権限だけを付与します。社内担当者は提出物を確認し、問題がなければ確定版フォルダへ移動します。差し戻しがある場合は、コメントや差し戻し用フォルダを使って、再提出の流れを明確にします。

このとき、協力会社が確定版フォルダを編集できる状態にしないことが重要です。提出と承認後の保管を分けることで、納品物の管理がしやすくなります。

シーン3:複数社で同じプロジェクト資料を共有する

複数の協力会社が同じプロジェクトに関わる場合、全社共通で共有する資料と、会社別に共有する資料を分けます。全社共通フォルダには、作業スケジュール、共通ルール、会議体、全体連絡などを置きます。会社別フォルダには、各社向けの作業指示書、個別見積、個別成果物、会社ごとの連絡資料を置きます。

この設計にしておくと、共通資料の更新は一箇所で済み、会社ごとの機密情報は分離できます。逆に、すべてを1つのフォルダで管理すると、共有範囲の調整が難しくなり、見せすぎや見せ漏れが発生しやすくなります。

シーン4:短期の外部作業者に一時的に共有する

短期の業務委託者や一時的な外部作業者に資料を共有する場合は、最初から期限付きで設計します。この場合、広いフォルダ権限を付けるのではなく、作業に必要な資料だけを集めた専用フォルダを作成します。契約期間や作業期間が短いほど、権限の削除忘れが起きやすいため、発行時点で終了日を設定しておくことが重要です。

短期利用では、共有フォルダの名前にも期間や目的を入れておくと、後から見直しやすくなります。

  • 外部作業者A_2026年6月レビュー用
  • 協力会社B_見積依頼資料_回答期限2026年6月30日
  • 制作会社C_納品提出用_2026年7月案件

フォルダ名に目的と期限を入れるだけでも、後から不要な共有を発見しやすくなります。

契約終了・プロジェクト終了時に確認すべきこと

協力会社との共有では、終了時の対応が最も漏れやすいポイントです。契約やプロジェクトが終わっても、クラウドストレージ上の権限が残っていれば、外部からアクセスできる状態は続きます。終了時には、少なくとも次の項目を確認します。

  • 対象の協力会社に発行しているゲストID
  • 対象会社に共有しているフォルダ
  • 共有リンクの有無
  • アップロード専用フォルダに残っている提出物
  • 確定版フォルダへの移動状況
  • ダウンロードログやアクセスログの確認要否
  • 契約終了後に保持すべき資料と削除すべき資料

特に、提出用フォルダにファイルが残ったままになっている場合は、社内の正式な保管場所へ移動してから、協力会社側の権限を外す必要があります。また、契約終了時には、協力会社側の担当者交代や退職の情報が自社に届いていない場合もあります。そのため、終了時点で「この会社にどのIDを発行しているか」を確認できる状態にしておくことが重要です。

クラウドストレージ選定時に確認したい機能

協力会社との共有を安全に行うには、運用ルールだけでなく、ツール側の機能も重要です。クラウドストレージを選定・見直しする際は、次の機能を確認してください。

  • フォルダ単位・ファイル単位で権限を設定できるか
  • 外部ユーザーごとに閲覧・ダウンロード・アップロード・編集権限を分けられるか
  • 親フォルダからの権限継承を確認・変更できるか
  • 共有リンクに有効期限を設定できるか
  • 協力会社ごとのアクセスログを確認できるか
  • ファイルの更新履歴やバージョンを確認できるか
  • 誤更新時に復元できるか
  • ゲストIDの無効化や権限削除を管理者側で実行できるか

たとえばFleekdriveのような法人向けクラウドストレージでは、ファイル共有や権限設定、操作ログの確認を前提にした運用設計がしやすくなります。協力会社との共有では、単に「外部共有できるか」ではなく、どの会社に、どの資料を、どこまで操作させるかを細かく制御できるかを確認することが重要です。

まとめ

協力会社へのゲストID発行では、IDを発行すること自体よりも、共有範囲と権限設計が重要です。社内用フォルダをそのまま共有したり、複数の協力会社を同じフォルダに入れたり、提出用フォルダに広い編集権限を付けたりすると、必要以上の情報が外部から見える状態になります。契約終了後に権限が残れば、プロジェクトが終わった後もアクセス経路だけが残り続けます。

協力会社との外部共有は、便利さとリスクが隣り合わせです。だからこそ、「誰を招待したか」だけでなく、「どの会社にどの範囲を見せているか」を基準に見直す必要があります。フォルダ設計と権限設定を先に整えておくことで、協力会社とのファイル共有を、安全かつ管理しやすい運用に変えられます。