探せることと、見せてよいことを同時に設計する。

深いフォルダ階層を、検索できる業務入口に変える

対象は、業務で発生するドキュメントやデータをNASに蓄積している企業です。フォルダ階層が深くなると、保存場所を知る担当者に問い合わせるか、階層を順番にたどる必要があります。

AMELAは、NASを巡回するクローラ、Elasticsearchによる検索、Web画面、ファイル配信、利用者・権限管理を含む基盤を構築しました。企業名、プロジェクト名、画面内のファイル名・件数・日時・応答時間は、機密保持のため承認済みの仮名・モックに置き換えています。

クロール、検索、取得を一つの流れにした実装

Pythonのクローラが対象パスを巡回し、検索に必要な情報をElasticsearchへ登録します。Web APIにはExpress、業務データ管理にはTypeORMとMySQLを用い、検索結果から許可された操作へ進める構成としました。

この事例の根拠と読み方

• 根拠：AMELAの移行元ケース資料、CMS登録内容、2026年8月25日に確認した公開デモの動作と画面。
• 対象期間：公開資料に記載された開発範囲と、上記確認日時点のデモ。
• 確認できること：NASクロール、Elasticsearchへの登録、名前・パス検索、取得操作、登録対象管理、ロール・利用者管理を含む構成。
• 確認できないこと：本番データ量、処理性能、更新頻度、検索精度、権限の正本との同期方式、可用性、監査・認証・法令適合の水準、業務時間の削減率。
• 公開上の扱い：企業名、プロジェクト名、画面、ファイル名、件数、日時、応答時間は機密保持のため仮名またはモックです。実在する顧客や個人を示すものではありません。

導入前に、正本と検索索引の境界を決める

検索索引はNASの代わりになる正本ではありません。ファイルの移動・削除・権限変更が検索結果へどう反映されるか、暗号化・破損・未対応形式をどう扱うか、NASへ接続できない場合に何を通知するかを決める必要があります。

ダウンロード時には、検索時点だけでなく取得時点でも権限を確認する設計が必要です。監査ログ、保存期間、バックアップ、復旧、負荷試験の条件は、設置先の情報管理方針とデータ量に合わせて別途検証してください。

読者が使える実践ツール

要件定義の前に、次の検索対象・権限・更新・受入確認シートを埋めると、NAS側と検索基盤側の責任を整理できます。記入例は公開デモから確認できる機能を使い、数値目標は置いていません。

• 正本：NASを正本、Elasticsearchを検索用索引とする。移動・削除時の反映方法を決める。
• 検索対象：承認済みの共有フォルダだけを登録する。除外パスと追加申請者を決める。
• 操作権限：閲覧者は検索・取得、運用者は再登録、管理者は利用者・権限管理を担当する。
• 更新運用：定期登録と手動再登録を用意する。失敗の通知先、再実行、未処理確認を決める。
• 受入確認：許可外の利用者に結果を表示しない、移動・削除を反映する、取得時に再認可する、失敗を記録する。

応答時間や更新間隔を評価する場合は、対象件数、ファイル形式、同時利用者、測定環境、除外条件をそろえて、導入前に受入基準を定義してください。