チームが開いて確認し、承認できるバージョンを納品しましょう。

相手に何ができるようにするかを決める

同じ結果でも、受け取る理由は人によって異なります。品質を確認する、ファイルを別のツールに取り込む、制作を引き継ぐなどです。リンクを送る前に、その目的を明確にしましょう。構図について話し合うだけならプレビューで十分なこともありますが、実寸の書き出しを確認するには足りないことがあります。

具体的なレビューを依頼しましょう。開くべきファイル、確認する基準、フィードバックの場所、希望する期限を伝えます。作業ディレクトリ全体を既定で送らないでください。除外したバリエーション、完全なログ、不要なリソースは選別を難しくし、納品と無関係な情報を晒すおそれがあります。

ここで説明する共有は、ご自身のツールや保存先で行うものです。BriefGPUの管理画面にチーム機能、メッセージ機能、ファイルスペースが備わっていることは想定していません。受け取る人が使用を許可されている保存先を選んでください。

口頭での説明なしに理解できるパッケージを組み立てる

パッケージにはプロジェクト名とバージョン番号を付けます。たとえば collection-v01 のようにします。内容とステータス（レビュー待ち、承認済みなど）を説明する短いメモを添えてください。一覧表があれば、出力を数え、例外を確認できます。CornellのREADMEガイドでは、ファイルとその利用に必要な情報を文書化することが推奨されていますが、あなたのメモは研究資料よりもずっと短くてかまいません。

制作を引き継ぐ場合は、必要な設定と依存関係を別途添えてください。完成した結果を使うだけなら、作業アーカイブは手元に置いておきましょう。

例：18枚の画像を3人でレビューする

この架空の例では、ある人が18枚の画像を制作し、同僚が参照資料を確認し、責任者が配信用としてレンダリングを承認します。パッケージ v01 には、再確認すべき18点の出力とインベントリ（一覧）が含まれています。同僚は画像を閲覧してチェック表に記入できますが、納品ファイルを変更する必要はありません。

指示では、参照と記載を確認し、画像の識別子との差異を記録することが求められています。その後、担当者が仕上がりを合意された基準と比較します。フィードバックは一つの表にまとめられたうえで、修正の可否が判断されます。提案があっても、公開されているバージョンが自動的に変更されることはありません。

任された作業に合わせて権限を設定する

共有スペースでは、関係者をそれぞれのアカウントで招待し、作業に合った権限を選びます。出力をレビューする場合は、ファイルの閲覧とコメント用の別の場所を優先してください。パッケージの変更は、納品物を準備する担当者だけに許可します。

権限の名称と効果はサービスによって異なります。たとえば OneDrive は、特定の相手向けのリンクと、リンクを受け取った誰でも使えるリンクを区別しています。また同社のドキュメントによると、閲覧アクセスでもコピーやダウンロードが可能な場合があります。つまり「閲覧のみ」は「持ち出し不可」を意味しません。ご自身のアカウントで実際に利用できるオプションと、チームのルールを確認してください。

共有フォルダ全体を確認してください。すでにアクセス可能な場所にファイルを追加すると、同じ宛先に公開される可能性があります。納品専用のフォルダを用意し、機密の原本、契約書、アクセス手段がパッケージに含まれないようにしましょう。

パスワードをレビューの流れから排除する

結果を見せるために BriefGPU アカウントのパスワードを貸さないでください。それはアカウントの管理情報へのアクセスを許すものであり、特定ファイルに限定した権限ではありません。ご自身の保存先の共有機能を使うか、許可された宛先に独立したパッケージを渡してください。

納品メモ、スクリーンショット、注文履歴にサービスのパスワード、秘密鍵、アクセストークンを記載しないでください。複数人で作業を引き継ぐ場合は、各人が自分の役割に適したアクセス手段を持つようにします。共有ツールで必要な権限を設定できない場合は、チームで別の受け渡し方法を選んでください。

注文の責任者は、ログイン情報を渡すことなく、プロジェクトに役立つ概要を共有できます。

修正したら新しいバージョンを公開する

例のフィードバックの後、パッケージ v02 は修正された2枚を差し替え、残りの16枚を保持します。そのメモには2つの変更点を正確に示し、これらの修正を確認するよう求めます。また、パッケージに常に18件の異なるリファレンスが含まれていることを確認するよう求めます。v01 に対する意見は v01 に紐づいたままです。

レビューの途中で関係者に知らせずにファイルを黙って差し替えないでください。同じ名前のまま別の内容にコメントしてしまう可能性があります。メッセージとメモに現在のバージョンを明記し、承認後にどのバージョンを使用してよいかをはっきり示してください。

一人の担当者が、口頭でのやり取りの後も含め、決定事項とその理由、ステータスを共通のグリッドにまとめます。

受け取り手の導線を確認する

完全に送信する前に、想定された権限を持つ人に、その人自身のアカウントでファイルを開いてもらいましょう。正しいフォルダへのアクセス、表示されるバージョン、目的のツールでの開き方、フィードバックを返せるかどうかを確認します。あなた自身のオーナーとしてのセッションは、他の人も同じアクセスを持てることを証明するものではありません。

アーカイブの場合は、展開できることと、取得したコピーからサンプルを開けることも確認します。「リンクを受け取りました」というメッセージは、アクセス、ダウンロード、承諾のいずれも確認するものではありません。段階に応じた返答を求めましょう。アクセス確認済み、レビュー完了、またはバージョン承諾といった形です。

納品後は、不要になったアクセスを見直します。サービスによっては、リンクと親フォルダから継承された権限が重なっていることがあるため、リンクを削除してもすべてのアクセスが消えるとは限りません。Microsoft のドキュメントでは、OneDrive と SharePoint におけるこれらの経路が詳しく説明されています。すでにダウンロードされたコピーは、リンクを削除しただけでは取り戻せません。

最後は承諾されたバージョンと保存された決定で締めくくる

受け取る人が、使用すべきバージョン、合意された制限があればその内容、ファイルの場所を把握していれば、納品は明確です。決定は目録と一緒に保存しましょう。例では、承諾の対象は collection-v02 とその 18 枚の画像であり、プロジェクトのすべてのバリエーションを承認するものではありません。

パッケージを読むことは、そのバックアップの代わりにはなりません。自分自身で再開するために必要なコピーを保管し、レンタルを終える前に確認しましょう。この納品方法は、レンタルしたサーバー上での共有機能、保存期間、特定の権限を保証するものではありません。これらの設定は、使用しているツールで確認する必要があります。