社内資料を迷わず保存・検索するアプリ｜上書き防止とバックアップの仕組み

社内資料を適切な場所に保存し、必要なときに探せるようにする。さらに、資料と検索用の情報をバックアップする。そんな一連の作業を支えるアプリを、CodexとSitesで作る案です。

この記事は構築案です。紹介するアプリは未制作であり、機能や保存先との接続、自動バックアップの動作は検証していません。導入前に、利用環境で実現できるか確認してください。

1．こんな困りごとはありませんか

社員が資料をドラッグ＆ドロップすると、部門や用途などのルールに従って保存先へコピーする案です。コピー完了後、ファイル名、保存日時、登録担当者、用途、保存場所などを検索用のインデックス（索引）へ登録します。元のファイルは残します。

社員は部門別・用途別・担当者別の一覧やキーワード検索から資料を探します。担当者などが未設定の資料は一覧で確認し、複数件を選んで変更します。手動・定時のバックアップも設けます。

管理者が部門・用途・資料の種類と保存先の対応を決めます。例えば「経理・請求・ひな形」の保存先を定め、社員がファイルをドラッグ＆ドロップした際に適用します。用途や保存先を確定できない場合は、候補を表示して社員が選びます。

同じ名前のファイルがある場合は、日時や連番を付けて別名で保存し、既存ファイルを上書きしません。複数人が同時に保存した場合も上書きしないことを確認します。保存先でのコピー成功後にインデックスへ登録し、途中で失敗した場合は成功と表示せず、コピー済みかどうかを確認してから再処理します。

登録担当者はアプリへ資料を登録した人であり、作成者や管理責任者とは限りません。必要なら別項目にします。資料の実体が外部で移動・削除された場合は、検索結果と保存先が一致しなくなるため、照合と再登録の方法も用意します。初期の検索対象は登録情報とし、資料本文の全文検索は別途検討します。

管理者は担当者、部門・分類、用途を追加・変更・削除できます。資料に使われている項目を削除する際は対象件数を表示し、別の項目へ変更するか、未設定にするかを選びます。

未設定の資料は一覧で確認でき、「担当者が未設定」などの条件で絞り込みます。複数の資料にチェックを入れて担当者などを一括変更でき、変更前に対象ファイル・件数・変更内容を表示します。変更しない項目は維持し、実行者、日時、変更前後を記録します。失敗があれば成功と失敗を分けて表示します。

インデックスから資料の登録を削除しても、保存先のファイルは削除しません。担当者・分類・用途の変更時も、ファイル自体は自動で移動・削除しません。必要な場合は、残ったファイルを確認してインデックスへ再登録します。

管理者がバックアップ先、対象、保存期間または世代数、実行時刻と確認担当者を設定します。「今すぐバックアップ」と、指定した曜日・時刻の自動実行を用意し、資料・インデックス・復元に必要な設定を圧縮保存する案です。

ファイル名に日付と連番を付け、既存のバックアップを上書きしません。実行日時、成功・失敗、ファイル名、容量を履歴に残し、途中で失敗した場合は成功として扱いません。保存先そのものの障害や不正操作に備え、元の資料とは別の場所への保存と権限管理も検討します。

復元時は対象の内容と復元先を確認し、既存資料を意図せず上書きしないよう、まず別の場所へ戻します。保存しただけで復元できるとは限らないため、定期的に試験用の場所で復元を確認します。復元後のリンク先やインデックスの再作成方法も決めておきます。

保存場所をそろえやすくなり、検索や担当変更の手間を減らせます。上書き防止とバックアップによって、資料を失うリスクに備えやすくなります。効果は保存ルールや実際の運用によって異なります。

Codexに画面、保存ルール、検索、権限、バックアップの要件を伝え、Sitesで実装する案です。Rustは使用せず、データベースの検索用索引や絞り込みを活用します。最初は架空の資料で、同名保存、複数人の同時操作、検索、一括変更、バックアップと復元を試します。

実際に利用する保存先へSitesから接続・コピーできるか、ブラウザを閉じていても定時実行できるか、対象容量を圧縮保存できるかは未検証です。クラウドストレージと社内サーバー・NASでは接続条件も異なります。利用環境、費用、容量、失敗時の対応を確認してから構成を決めます。

資料とインデックスには社内情報が含まれます。誰が閲覧・保存・編集・削除できるかというアクセス制御を、アプリ、資料の保存先、バックアップ先のそれぞれに設けます。URLを知るだけで利用を許可するのではなく、利用者ごとの権限を確認してから実データを扱います。