【ITニュース解説】EdTech Report Deletion: A Production Upload Strategy for Large AI-Generated Files in Private Buckets

システム開発において、AIが生成したような大きな画像ファイルなどのデータを、インターネット経由で、かつ認証されたユーザーに安全に届けることは、表面上は単純に見えても、実は複雑な課題を多く含んでいる。特に、教育分野の製品で生成されるレポートのように、ユーザー一人ひとりに個別化されたデータの場合、その生成から配布、そして最終的な削除に至るまでの管理は、極めて慎重に行う必要がある。この記事では、そのような「巨大なAI生成ファイルを、外部から直接アクセスできないプライベートな保存場所（通常は『バケット』と呼ばれるクラウドストレージの単位）にアップロードし、適切に管理・削除する方法」について、具体的なアプローチが述べられている。

まず、最も基本的な考え方として、顧客に提供するレポートファイルは、インターネットから直接アクセスできない「プライベートなオブジェクトストレージバケット」に保存することが必須となる。そして、もし生成される画像ファイルが非常に大きくなる可能性があるなら、ファイルを一気にアップロードするのではなく、いくつかに分割して順次アップロードする「マルチパートアップロード」という方法を検討することが賢明だ。さらに重要なのは、ファイルが「いつまで保存されるべきか」や「いつ削除されるべきか」といった情報は、アプリケーション自身が持つデータベースでしっかりと管理する必要があるということだ。ファイルが一度完全にアップロードされたからといって、無条件に永遠に保存されるわけではない。

もし、生成される画像ファイルが比較的小さく、そのサイズも概ね予測できる範囲であれば、最もシンプルなのは「一度のリクエストでファイル全体をアップロード」する方法だ。このアプローチであれば、システムの複雑さを最小限に抑えることができる。しかし、AIが生成するレポートのように、出力されるファイルが極めて大きくなったり、利用者のネットワーク接続が不安定で途中で切断される可能性があったり、あるいはアップロード作業を途中で中断して後から再開したいといった要件が出てきた場合、マルチパートアップロードの持つ複雑さを受け入れるだけの価値が生まれる。この方法では、ファイルを細かく分割して少しずつ送ることで、途中で失敗しても最初からやり直す必要がなく、失敗した部分だけを再送すれば良いため、効率性が高まる。ただし、この分割アップロードは新たな課題も生じさせる。システムは、「現在アップロードが進行中のデータ」「部分的にアップロードされたまま、何らかの理由で放置されたデータ」「完全にアップロードが完了したデータ」など、さまざまな状態を正確に管理しなければならなくなるのだ。

この種類のシステムを構築する上で本当に重要な問いは、「ファイルが無事にストレージに届くか」だけではない。それよりも、「誰がそのファイルを取得する権限を持つのか」「そのファイルはいつまで存在すべきなのか、つまり保持期限はいつまでか」「ファイルが確かに削除されたことを、どのように証明するのか」という点が、システムの信頼性とコンプライアンス（法令遵守）の観点から非常に重要となる。

具体的な実装戦略としては、まずレポートがAIによって生成される時点で、そのレポートの情報を管理するための「データベースレコード」を作成することから始める。このレコードには、レポートを一意に識別するためのID、オブジェクトストレージにファイルを保存する際に内部で使うキー（ファイル名とは異なる）、そして「いつまで保存すべきか」という保持期限、さらに「アップロード待機中」「アップロード中」「準備完了」「期限切れ」「削除済み」といったレポートの状態を持たせる。マルチパートアップロードを使う場合は、そのアップロード作業全体を識別するためのIDや、各分割されたデータ（『パーツ』と呼ぶ）が無事にアップロードされたことを示す情報も、このデータベースレコードに紐づけて保存する。これにより、もしアップロードが途中で中断しても、システムはどのパーツまで完了したかを正確に把握し、残りの作業を再開したり、あるいは意図的にアップロード作業を中止したりすることができるようになる。

オブジェクトストレージのバケットは「プライベート」な状態を維持すべきだ。顧客が自身のレポートにアクセスする際は、アプリケーションがまずその顧客がアクセスする正当な権限を持っているかを確認し、さらにレポートの保持期間がまだ有効であるかをチェックする。これらの条件が満たされた場合にのみ、アプリケーションは「短期間だけ有効な署名付きURL」を発行する。このURLは、一時的にファイルに直接アクセスするための特別な認証情報のようなものであり、直接ファイルへのアクセスを許可する。しかし、このURLはあくまで一時的なものであり、顧客側で永久に保存したり、ウェブブラウザのキャッシュに保存したりするべきではない。常にアクセスごとにアプリケーションが認証・認可を行い、新しいURLを発行する仕組みにすることが重要だ。

システム設計においては、「レポートを生成する責任」と「生成されたファイルを保存・管理する責任」を明確に分離することが望ましい。レポート生成を担当する部分は画像データと関連する情報（メタデータ）のみを生成し、ストレージへの保存を担当する部分は、保存場所のキーの割り当て、マルチパートアップロードの状態管理、エラー時の再試行、アップロードの完了処理、中断処理、そして署名付きURLの発行といった役割を担う。この責任の分離は、特にファイル削除の際にその重要性が際立つ。顧客からレポートの削除リクエストがあった場合、アプリケーションはデータベースのレコードを「削除済み」に更新し、それ以降のアクセスを拒否する。そして、実際のオブジェクトストレージからのファイル削除を別の非同期タスクとしてキューに入れ、その削除の結果を記録する。この一連のプロセスは、単にユーザーのブラウザがURLを忘れることに頼るべきではない。

なぜマルチパートアップロードが、ファイルの保持や削除といった管理作業を複雑にするのか。それは、この方法が「複数の手順を厳密に調整するプロトコル」だからだ。典型的な流れは、まずアップロード作業を開始し、ファイルを分割したパーツを順番に送り、各パーツがオブジェクトストレージに届いたことを確認する応答を受け取り、最後にすべてのパーツが揃ったことをシステムに伝えてアップロードを完了する。もし、この途中でシステムが停止したり、ネットワークが切れたりして、例えば12個のパーツのうち7個だけ送って作業が中断してしまった場合、システムは「利用可能な完全なレポート」も持たず、「不完全なパーツをいつまでも保持しておくべき理由」もない、という中途半端な状態になる。

この問題を解決するため、マルチパートアップロードの各作業は「リースされた（借りられた）作業」として扱うことが推奨される。データベースには、そのアップロード作業の「担当者」「開始時刻」「最終進捗時刻」、そして「最終的にどうするか（完了させるか中断するか）」といった情報を記録する。そして、定期的にシステム内の「調整役（リコンサイラー）」と呼ばれるプログラムが、リース期間が切れたレコード、つまり長時間進捗がなく放置されているアップロード作業を探す。もしレポートがまだ有効で、単純に作業が中断しているだけなら、別の担当者が記録された情報をもとにアップロードを再開できる。もしジョブがキャンセルされたか、レポートの保持期限がすでに過ぎていた場合は、調整役がそのアップロード作業を中止（アボート）し、データベースのレコードを適切に更新する。

ファイル削除には大きく二つの経路がある。一つは「完全にアップロードされたオブジェクトの削除」で、これはオブジェクトストレージに対する認証された削除操作と、アプリケーションの状態遷移（例えば、『準備完了』から『削除済み』への変更）が必要となる。もう一つは「不完全なアップロードの中止」で、これはストレージサービスにアップロード作業を『アボート』するよう指示する操作を伴う。一般的なオブジェクトストレージの自動削除ルールは、このような不完全なアップロードのクリーンアップポリシーを全てカバーしているわけではないため、調整役が両方の経路を考慮する必要がある。また、監査記録では「削除が要求されたこと」「オブジェクトの削除がストレージ側で確認されたこと」「部分アップロードが中止されたこと」を明確に区別して記録することが、後々のシステム監査や確認作業で非常に役立つ。

エラー発生時の「リトライ（再試行）」処理も、厳密な管理が必要だ。例えば、短時間に多くのリクエストを送りすぎたことによる「429エラー」が発生した場合は、「指数バックオフ」という方法で、少しずつ待機時間を長くしながら再試行する。また、ストレージAPIが対応していれば、同じ操作を何度実行しても結果が変わらないことを保証する「冪等性キー」を使用することが推奨される。さらに、どのパーツを、何バイト、何回試行して、どういう応答ステータスだったかを詳細に記録しておくことも重要だ。

アプリケーションの「ストレージアダプター」は、外部のオブジェクトストレージサービスと連携するためのプログラム部品だ。このアダプターは、レポート生成コードがストレージサービスの複雑な内部処理を知ることなく、シンプルな形で連携できるような「契約（API）」を提供すべきだ。具体的には、「アプリケーションが管理するキーでアップロード作業を開始する」「各パーツを転送し、その完了データを永続化する」「記録されたアップロードと期待されるパーツセットのみを完了する」「アップロード完了が成功した場合にのみレポートを『準備完了』とマークする」「認証と保持期間のチェック後にのみ署名付きURLを発行する」「キャンセル、期限切れ、または最終的なジョブの失敗の場合にはアップロードを中止または削除する」といった機能だ。

ストレージアダプターはまた、システムの状態変化を「観測可能」にすることも大切だ。アップロードの開始、各パーツの完了、最終的な完了、アップロードの中止、署名付きURLの発行、オブジェクトの削除といった重要なイベントが発生した際に、そのイベントを記録したり、別のシステムに通知したりする仕組みを設ける。その際、レポートのIDや関連する作業IDを含めるが、顧客の個人情報や署名付きURLのような機密情報は通常のログには含めないよう細心の注意を払う必要がある。

どのようなストレージ設計が、認証されたレポートサービスに適しているかという問いに対しては、システムの「データの保持」「障害からの復旧」「アクセス制御」といった側面をどれだけ開発チームが細かく制御できるかで判断すべきだ。AI生成レポートのようなケースでは、バックエンド（サーバー側）が介在してアップロードを管理するマルチパートアップロードが、最も扱いやすく、システムの状態管理に対する理由付けがしやすい。なぜなら、レポート生成のジョブ自体がすでに認証された所有者を持ち、その作業の状態を永続的に記録する仕組みが備わっているからだ。

しかし、「プライベートバケット」というだけでは、完全なデータ保持ポリシーにはならない。レポートの保持期限が過ぎた後に復元できるのか、法的な理由でデータを保持しなければならない「法的保持（リーガルホールド）」が必要なケースがあるのか、削除リクエストが元の画像だけでなく、そこから派生して作成されたサムネイルなども含めて削除するのか、といったより複雑な要件には、単にプライベートバケットを使うだけでは対応できない。もし、変更不可能なデータの保持（イミュータブルストレージ）、自動的な地理的レプリケーション（複数の地域へのデータ複製）、サーバー側でのメタデータ検索、または公開URLが必要なシステムであれば、それらの機能を提供するような、より広範なアーキテクチャを最初から選択すべきであり、マルチパートアップロードの技術だけで全てが解決すると誤解してはいけない。

最後に、このようなシステムを本番環境へ導入するにあたっては、まず一つのレポートタイプから始め、短い明確な保持期間を設定することから始めるのが良い。そして、様々な異常事態、例えば「アップロード完了前のキャンセル」「パーツ転送中に担当ワーカーが交代するケース」「同じアップロードが二重に完了されるケース」「期限切れの署名付きURLが使われた場合」「削除リクエストとファイル取得が同時に行われる競合状態」「長時間放置された放棄されたアップロードを調整役が見つけて処理する動作」といった状況を想定し、徹底的にテストすることが重要だ。最初は実際のオブジェクトストレージサービスではなく、テスト用の「フェイクストレージアダプター」を使って単体テストを行い、その後に実際のストレージで小規模な書き込みテストを行うと良いだろう。

本番リリース時には、新しいシステムが「準備完了」の状態になるまでは、古いレポート読み取り経路も利用できるようにしておくと安全だ。また、削除操作は「冪等性（何度実行しても結果が変わらないこと）」を持つように設計し、法令遵守のために監査イベントを一定期間保持する。そして、不完全なアップロードの件数や、それがどのくらいの期間放置されているかを常に監視する。これらの指標が説明できない状態であれば、まだアップロードの管理プロトコルが完全に運用可能になっていない証拠となる。

要するに、生成される画像が比較的小さく安定している場合は、シンプルな単一リクエストでのアップロードを選び、大きなファイルやネットワーク障害が発生しやすい転送にはマルチパートアップロードを選ぶべきだ。ただし、どちらの方法も、「レポートの保持状態を適切に管理する仕組み」の代わりにはならない。EdTechのレポートサービスでは、顧客は認証された後にのみ読める画像を受け取るべきであり、システムはその画像がなぜまだ存在しているのかを、いつでも明確に説明できなければならないのだ。