Snowflake、AI_CLASSIFYの文書分類をPublic Previewに: PDFやDOCXをSQLで分類

Snowflake は 2026年5月13日、Snowflake Cortex の AI_CLASSIFY function が文書ファイルの分類に対応したことを Public Preview として発表しました。PDF、DOC、DOCX、XLS、XLSX、HTML、CSV、TXT などを入力にでき、文書あたり最大100ページまでの分類に対応します。

要点

• AI_CLASSIFY が文書ファイル入力を受け付け、SQL から document classification を実行できるようになった
• 契約書、請求書、各種レポートのような文書を分類し、後続の AI_EXTRACT や AI_PARSE_DOCUMENT などへ振り分ける用途が想定されている
• 対応形式は .pdf、.doc、.docx、.xls、.xlsx、.html、.csv、.txt
• 関数シグネチャと pricing は変更なしと説明されている
• Public Preview なので、本番導入前には精度、対象文書、例外処理、データガバナンスを検証したい

今回のリリースノートで語られていること

今回の更新は、Cortex AI の文書処理パイプラインを組みやすくするものです。これまで分類対象がテキスト中心だった場合、PDF や Office 文書を一度別の処理で取り出し、分類モデルや外部サービスへ渡し、結果を Snowflake に戻すような構成になりがちでした。AI_CLASSIFY が文書ファイルを直接扱えるようになると、文書の intake 直後に「これは請求書か、契約書か、レポートか」といった分類を SQL workflow の中で行いやすくなります。

Snowflake のリリースノートでは、manual triage の削減、下流処理への intelligent routing、high-volume document workloads における一貫した分類が利点として挙げられています。実務では、分類そのものが最終目的というより、次にどの処理へ送るかを決める前段として効きます。たとえば請求書は AI_EXTRACT で金額や取引先を抽出し、契約書は AI_PARSE_DOCUMENT やレビュー用 workflow に回し、レポートは分析・要約系の処理へ渡す、といった分岐を Snowflake 内で設計しやすくなります。

一方で、文書分類は運用設計が精度以上に大切です。ファイル形式が増えるほど、スキャンPDF、表を含むExcel、長い契約書、複数文書が混ざったファイル、分類不能な文書などの例外が増えます。Public Preview の段階では、対象文書を代表サンプルに絞って分類ラベルを設計し、confidence の扱い、再分類、人的レビューへのエスカレーション、誤分類時の影響を確認するのが現実的です。pricing は変わらないとされていても、文書量が増えれば全体の処理コストや downstream workflow の負荷は変わるため、件数・ページ数・再処理条件も合わせて見ておく必要があります。

対象になりそうなチーム

• 契約書、請求書、申請書、レポートなどの document intake を Snowflake 上で扱う data / operations team
• Cortex AI Functions を使って文書処理 workflow を作る analytics engineering / AI platform team
• 分類結果を業務プロセスや監査に接続する governance / back-office automation team

実務で確認したいポイント

まず、分類したい文書タイプとラベル体系を小さく定義し、対応形式と100ページ制限に収まる代表サンプルで精度を確認します。次に、分類結果を AI_EXTRACT、AI_PARSE_DOCUMENT、人手確認、保留キューのどこへ渡すかを設計します。Public Preview のため、誤分類・分類不能・ページ超過・破損ファイルをどう扱うかを決めてから本番データに広げるのがよさそうです。

結局、この更新をどう見るべきか

AI_CLASSIFY の文書対応は、Snowflake 上の AI document workflow を「取り込み後に人が仕分ける」形から「SQL で分類して下流処理へ流す」形へ近づける更新です。文書処理を Snowflake 中心に寄せたい組織にとっては有用ですが、Public Preview では分類ラベル設計、例外処理、ガバナンス、コスト確認をセットで進めるべきです。