本文へ移動
AI Dev Lab Japan AI開発ツール、AIコーディングエージェント、M...

Codexにファイルアップロード機能を任せる前に決めること

Codexにファイルアップロード機能を任せる前に決めることの要点をタイトルと確認軸で示すアイキャッチ

3行まとめ

Visualupload前の4点受け取る前に決めます。
Type

種別。

Size

上限。

Scan

検査。

Access

公開。

ファイルアップロードは、保存する前の制限で安全性が大きく変わります。

  • Codexにファイルアップロード機能を任せる時は、UIやAPIだけでなく、許可する種別、MIME検証、サイズ上限、保存先、公開範囲、削除まで先に決めます。
  • presigned URLを使う場合も、期限、method、object key、content type、size、権限を絞り、検査前のファイルを公開領域へ置かないようにします。
  • upload後はscan、隔離、audit log、owner、retention、削除要求を扱うため、単なるform実装として頼まないほうが安全です。

ファイルアップロードは、Codexに任せるとすぐ形になります。inputを置く。API routeを作る。S3へ保存する。URLを返す。画像previewを出す。CSVを読ませる。小さなdemoなら簡単です。

ただ、uploadは外部から任意のファイルを受け取る入口です。拡張子だけで判定する。サイズ上限がない。検査前に公開URLを返す。presigned URLが長すぎる。object keyをユーザー入力で作る。削除できない。こうした差分は、動いていても本番では危険です。

この記事では、Codexにファイルアップロード機能を任せる前に決めることを整理します。外部API連携や本番データの扱いは公開済み記事でも扱いましたが、ここでは「ファイルを受け取り、保存し、見せ、消す」流れへ絞ります。

この記事でわかること

Visual確認する材料Codexへ渡す前の整理です。
MIME

検証。

Storage

保存。

Signed URL

期限。

Delete

削除。

upload機能は、UIだけでなく保存後の扱いまで決めます。

  • ファイルアップロード機能をCodexへ頼む前に決める7項目
  • MIME、拡張子、magic numberをどう組み合わせて見るか
  • サイズ上限、一時保存、private/public storageを分ける理由
  • S3 presigned URLを使う時の期限と権限の絞り方
  • scan、quarantine、公開前承認を入れる考え方
  • 公開範囲、所有者、削除、audit logを先に決める方法
  • Codexへそのまま渡せる依頼packet
  • reviewで止めるべきupload差分

この記事は防御目的の実装整理です。OWASP File Upload Cheat Sheetでは、許可リスト、拡張子検証、Content-Type検証、file signature検証、ファイル名の扱い、サイズ制限、保存場所などの考え方が説明されています。AWS S3のDocsでは、presigned URLに期限があり、URLを持つ人がその操作を実行できることが説明されています。

前提知識

Visual見る一次情報防御とstorageです。
項目内容見方
OWASPupload。
S3署名URL。
IAM権限。
Scan隔離。

uploadは入力検証、保存先、公開範囲を合わせて設計します。

ファイルアップロードは、入力、保存、処理、公開、削除の機能です。

テキスト入力と違い、ファイルは大きく、形式が複雑で、解析やpreviewや変換を伴います。画像、PDF、CSV、ZIP、音声、動画ではリスクも処理も違います。

uploadは入力検証だけでは終わらない

uploadでは、受け取る前の制限、受け取った直後の隔離、検査、保存、公開、削除が必要です。入力検証だけ通っても、保存先や公開URLが危険なら意味がありません。

まず用途を絞る

「ファイルをアップロードできるようにする」では広すぎます。プロフィール画像、請求書PDF、CSV import、support attachment、社内資料、AIに渡す資料では、許可種別、サイズ、保存期間、公開範囲が違います。

upload前に決める7項目

Visual7つの決定実装前の条件です。
項目内容見方
Purpose目的。
Types種別。
Size上限。
Storage保存。
Access公開。
Scan検査。
Delete削除。

何でも受け取るuploadは、あとから制限しにくくなります。

Codexへ頼む前に、7項目を決めます。

項目決めること曖昧なまま起きること
purpose何のためのuploadか種別が広がる
types許可する拡張子/MIME任意fileになる
size最大サイズと件数storageや処理が詰まる
storage一時、private、public検査前に公開される
access誰が見られるかURL共有で漏れる
scan検査と隔離危険fileが処理される
delete削除、TTL、監査消せない

Codexは実装を作れますが、受け取ってよいファイルの種類や公開範囲は知りません。ここを人間が渡します。

許可リストから始める

許可する種類を小さく始めます。プロフィール画像ならJPEG/PNG/WebPだけ。CSV importならCSVだけ。PDF添付ならPDFだけ。denylistではなくallowlistで考えます。

保存後の利用者を決める

アップロードした本人だけか、同じorganizationのmemberか、管理者だけか、公開URLを知る全員か。保存後の見える範囲を決めます。

reviewで見ること

reviewでは、許可種別、サイズ、保存先、object key、公開ACL、署名URLの期限、scan前公開、削除手順、audit logを見ます。

MIMEと拡張子を両方見る

Visualtype validation見た目だけで判断しません。
Extension

拡張子。

MIME

種別。

Magic

中身。

Allowlist

許可。

拡張子だけ、Content-Typeだけの判断にしないようにします。

拡張子だけ、Content-Typeだけで判断しないようにします。

OWASPのFile Upload Cheat Sheetでは、拡張子検証、Content-Type検証、file signature検証など、複数の検証を組み合わせる考え方が説明されています。どれか1つだけでは不十分です。

拡張子

拡張子はユーザーが変えられます。ただし、許可リストとして見る価値はあります。二重拡張子や大文字小文字、URL encodingも考慮します。

MIME

MIME typeも送信側が指定できます。信頼しすぎず、server側で判定します。

file signature

file signatureやmagic numberは、中身の形式を確認する材料です。画像やPDFなどでは、実際の中身と拡張子が合うかを見ます。

注意点

検証に通ったから完全に安全という意味ではありません。検証後も、scan、変換、隔離、権限、保存期間を分けます。

サイズ上限と保存先を分ける

Visualstorage policy置く場所を分けます。
項目内容見方
Max size上限。
Temp一時。
Private非公開。
Public公開。
TTL期限。

一時保存、検査済み保存、公開配信を同じ場所にしない設計にします。

サイズ上限は、UIだけでなくserver側でも持ちます。

大きすぎるファイルは、network、memory、storage、scan、thumbnail生成、CSV parseを詰まらせます。件数上限、1ファイル上限、ユーザー別上限、organization別上限、日次上限を決めます。

一時保存と公開保存を分ける

upload直後のファイルは、検査前です。一時領域やquarantineへ置き、検査済みだけを本保存へ移します。

object keyを安全に作る

object keyにユーザー入力のファイル名をそのまま使わないようにします。UUID、tenant ID、日付prefix、用途prefixを使い、元ファイル名はmetadataとして安全に扱います。

条件

Codexへは、public bucketへ直接保存しないこと、ACLを広げないこと、検査前URLを返さないことを明記します。

presigned URLを短く使う

Visualsigned URL flow権限を短く渡します。
  1. 1Request

    要求。

  2. 2Authorize

    確認。

  3. 3Sign

    発行。

  4. 4Upload

    送信。

  5. 5Verify

    確認。

presigned URLは便利ですが、期限、method、object key、sizeを絞ります。

S3 presigned URLは、期限付きで特定操作を許可するURLです。AWSのDocsでは、presigned URLを持つ人がそのURLで指定された操作を実行でき、有効期限を設定できることが説明されています。

便利ですが、長い期限や広い権限にすると危険です。

URL発行前に認可する

presigned URLを発行する前に、ユーザーがその用途でuploadしてよいかを確認します。organization、role、quota、file type、sizeを見ます。

methodとkeyを絞る

PUT用なのかGET用なのか、object keyはどこか、Content-Typeは何か、期限は何分かを絞ります。

reviewで見ること

期限が長すぎないか、object keyに推測しやすい値がないか、任意pathへuploadできないか、upload後のserver-side確認があるかを見ます。

scanと隔離を入れる

Visual検査の流れ公開前に止めます。
  1. Receive

    受信。

  2. Quarantine

    隔離。

  3. Scan

    検査。

  4. Approve

    承認。

  5. Publish

    公開。

検査前のファイルを、そのまま公開領域へ置かないようにします。

scanは、upload後の処理です。

検査前のファイルをすぐ公開したり、AI処理やPDF変換へ渡したりしないようにします。まず隔離し、検査し、OKなら次へ進めます。

quarantineを作る

quarantineは、検査前ファイルの置き場です。外部から直接読めない場所にします。検査済みだけを別prefixや別bucketへ移します。

scan結果を状態として持つ

pendingcleanrejectedfailedのように状態を持ちます。検査失敗と危険判定を分けます。

注意点

scanが非同期なら、UIは「処理中」を表示します。検査前にdownload linkやpreviewを出さないようにします。

公開範囲と削除を決める

Visualaccess lifecycle見える範囲と消し方です。
項目内容見方
Private限定。
Public公開。
Owner所有。
Audit記録。
Delete削除。

アップロード後の公開範囲、所有者、削除権限を先に決めます。

upload後のファイルは、誰が見られるかを決めます。

private、organization内、admin-only、public、temporary publicなどです。公開URLを作る場合も、永続URLか期限付きURLかを分けます。

ownerを持つ

ファイルにはownerが必要です。user、organization、project、ticket、articleなど、所属先を持ちます。ownerがないファイルは、削除や権限変更で困ります。

deleteとretentionを決める

削除要求、退会、ticket close、期限切れ、scan rejected、quota超過でどう消すかを決めます。削除ログも必要です。

Codexへ渡す依頼packet

Visual依頼packetそのまま渡せる型です。
項目内容見方
Allowed許可。
Limits制限。
Storage保存。
Tests確認。
Owner担当。

packet化すると、Codexが危険な便利実装へ寄りにくくなります。

Codexへは、次のようなpacketで渡します。

目的:
  support ticketに画像添付を最大3枚まで付ける。

許可:
  jpg/png/webpのみ。
  1ファイル5MBまで。
  support ticket ownerとsupport adminだけ閲覧可能。

禁止:
  public bucketへ直接保存しない。
  検査前に公開URLを返さない。
  ユーザー入力ファイル名をobject keyに使わない。
  任意拡張子を許可しない。

storage:
  quarantine prefixへupload。
  scan clean後にprivate attachments prefixへ移動。

presigned URL:
  PUT専用、5分以内、object keyはserver生成。

test:
  許可画像、拡張子偽装、大きすぎるfile、MIME不一致、scan rejected、削除を確認する。

review:
  MIME、size、storage ACL、signed URL期限、audit log、delete pathを見る。

このpacketがあると、Codexは「動くupload」ではなく「制限されたupload」を作りやすくなります。

よくある失敗

Visualbad patternsuploadで崩れやすい点です。
Any file

無制限。

Public temp

即公開。

Long URL

長期限。

No scan

未検査。

upload事故は、受け取れることを優先しすぎた時に起きます。

何でも受け取れる実装にする

最初から任意fileを受けると、あとで制限しにくくなります。用途別にallowlistを作ります。

public URLをすぐ返す

検査前にpublic URLを返すと、危険なファイルが外から見える可能性があります。検査済みだけ公開します。

presigned URLの期限が長い

長すぎるURLは共有されやすくなります。用途に必要な短い期限にします。

ファイル名をそのまま保存keyにする

ユーザー入力のファイル名をobject keyに使うと、衝突や推測や表示上の問題が出ます。server側で生成します。

削除導線がない

uploadできても消せないと、retentionや容量の問題になります。削除と監査を先に決めます。

FAQ

Visual判断の入口迷った時の見方です。
項目内容見方
Image?検証。
CSV?容量。
Public?権限。
Delete?期限。

迷ったら、誰が何をアップロードし、誰が見て、いつ消えるかへ戻ります。

画像だけなら安全ですか

安全とは限りません。画像でもサイズ、形式、metadata、変換、preview、公開範囲を確認します。

presigned URLならserverを通らないので安全ですか

違います。presigned URLは権限を短く渡す仕組みです。発行前の認可、期限、method、object key、upload後確認が必要です。

scanは必須ですか

用途によります。外部ユーザーから受け取り、他人が閲覧したり、後続処理へ渡したりするなら、scanや隔離を検討します。

CSV uploadも同じですか

基本は同じです。さらにencoding、delimiter、行数、列数、formula injection、preview、import dry-runを確認します。

Codexにstorage設定まで触らせてよいですか

候補作成やIaC差分は任せられますが、bucket policy、public access、IAM、lifecycleは人間reviewを必須にします。

次に読むなら

参照した主な情報源

更新履歴

Visual更新メモ公開時点の整理です。
  1. 2026.06.01

    初版。

storageやsecurityの仕様は変わるため、導入時に公式Docsを確認します。

  • 2026.06.01: 初版公開。Codexへファイルアップロード機能を任せる前のMIME検証、サイズ上限、presigned URL、scan、公開範囲を整理しました。