Snowflake Document AIは、PDFや契約書から項目を抜き出すためのUIとモデル構築機能でした。ただしこの機能は現存しません。Snowflakeの公式リリースノートBCR-2156は、Document AIのUIと<model_build_name>!PREDICTメソッドが2026年3月16日に廃止されたと明記しています。日本語で読める解説記事の多くはこの廃止前に書かれたもので、そのまま手順をなぞっても画面にたどり着けません。ここでは何が止まり何が残ったのか、そして今のSnowflakeで文書を処理する場合にどの関数を選ぶのかを、公式ドキュメントの記載に沿って整理します。
まとめ
結論を先に置きます。
- Document AIのUIと
!PREDICTメソッドは2026年3月16日に廃止済み。廃止日までにSnowflake Model Registryへ移行しなかったモデルは推論に使えません。 - 移行済みのArctic-TILTモデルは
AI_EXTRACT(model => ..., file => ...)という専用シグネチャで推論だけ継続できます。ただし再学習はできません。 - これから文書処理を組むなら、モデル構築の工程がない
AI_EXTRACT（項目抽出）とAI_PARSE_DOCUMENT（テキスト化・レイアウト解析）を直接使います。 - 日本リージョンでは
AI_EXTRACTがクロスリージョン推論でしか動きません。AWS東京もAzure Japan Eastも公式の対応表では「Cross-region only」です。CORTEX_ENABLED_CROSS_REGIONの設定が事実上の前提になります。 - 課金はAIクレジット建てで、
AI_EXTRACTにファイルを渡すと1ページが970トークンとして計上されます。
以下、廃止の範囲、旧Document AIが何だったか、現行の関数の選び分け、日本リージョンの制約、コスト、そして今から着手する場合の判断基準の順に見ていきます。
Document AIの廃止で何がいつ止まったのか
廃止された範囲はUIとPREDICTメソッド
BCR-2156の記載は「The Document AI UI and the <model_build_name>!PREDICT method were decommissioned on March 16th, 2026.」です。止まったのはSnowsight上のDocument AI画面と、モデルビルドに対して推論を実行する!PREDICTという呼び出し方の2つを指します。公式ドキュメントの旧URLである/user-guide/snowflake-cortex/document-ai/overviewも、英語版・日本語版ともに/user-guide/snowflake-cortex/ai-documentsへリダイレクトされます（2026年9月7日時点の実測）。検索結果に旧URLが残っていても、開いた先はCortex AI関数の一覧ページです。
影響は既存の抽出パイプラインに直接及びます。BCR-2156は、廃止後はDocument AI UIから既存のモデルビルドにアクセスできず、Model Registryへ移行しなかったモデルは推論に利用できないとしています。廃止日は過ぎているため、移行作業そのものが今から選べる選択肢ではありません。
移行済みモデルに残された経路
期限内にModel Registryへ移した場合に限り、Arctic-TILTモデルはAI_EXTRACTの専用シグネチャで呼び出せます。通常のAI_EXTRACTとは引数が異なり、抽出したい項目をその場で書くのではなくモデル名を指定します。
SELECT AI_EXTRACT(
model => 'my_db.my_schema.my_model',
file => TO_FILE('@files_db.files_schema.files', 'agreement.pdf')
);制約もはっきりしています。1モデルあたりのエンティティは最大100個、信頼度スコアは非対応、既定では最新バージョンが使われALTER MODEL my_model SET DEFAULT_VERSION = new_version;で切り替えます。課金上はエンティティ抽出がarctic-tilt-entity、表抽出がarctic-tilt-tableというラベルで計上されます。呼び出しにはSNOWFLAKE.CORTEX_USERデータベースロールとモデルへのOWNERSHIP権限が必要です。この経路は既存資産の延命用であり、新規に組む先ではありません。
Document AIがArctic-TILTモデルを動かしていた仕組み
Document AIは、Snowflakeが自社開発したArctic-TILTという文書特化モデルを、ノーコードのUIから使う仕組みでした。ユーザーはサンプル文書をアップロードし、「請求書番号はどれか」といった質問を自然文で書き、モデルの回答を画面上で修正します。修正結果をそのまま学習データとしてファインチューニングし、完成したモデルビルドを!PREDICTでSQLから呼ぶ、という流れです。AI_EXTRACTの旧モデル向けリファレンスは今も「the Document AI Arctic-TILT model」という表現でこのモデルを指しています。
この設計の弱点は、文書の型ごとにモデルを作って育てる工程が必要だった点です。抽出したい項目が1つ増えるたびにアノテーションと再学習が発生し、書類の様式変更にも追随できませんでした。後継のAI_EXTRACTがモデル構築の工程を持たず、クエリごとに抽出項目を書き換えられるのは、この工程を丸ごと省くための設計変更です。
現在のSnowflakeで文書を処理する関数
公式ドキュメントは文書向けに4つの関数を並べています。役割が重なる部分があるため、入口で選び違えると後段の作り直しになります。
| 関数 | 出力 | 主な用途 | スキーマ定義 |
|---|---|---|---|
| AI_EXTRACT | 構造化データ | 伝票・申込書の項目抽出 | 必要 |
| AI_PARSE_DOCUMENT | テキスト・レイアウト | RAG、全文検索、要約 | 不要 |
| AI_CLASSIFY | カテゴリ | 混在文書の振り分け | カテゴリ列挙 |
| AI_COMPLETE | 自由テキスト | 上記に収まらない加工 | 不要 |
いずれも呼び出しには権限が要ります。公式の記載は「your role needs the USE AI FUNCTIONS account-level privilege and one of the CORTEX_USER or AI_FUNCTIONS_USER database roles」です。アカウントレベルのUSE AI FUNCTIONSと、データベースロールのどちらか一方、という二段構えである点に注意してください。
AI_EXTRACT：スキーマを指定した項目抽出
抽出したい項目をresponseFormatに質問文の形で並べると、キーと値の組で返ります。scores => TRUEを付ければ項目ごとの確信度も返るため、旧Document AIで信頼度による自動承認の閾値を設けていた運用はここで置き換えられます。
SELECT AI_EXTRACT(
file => TO_FILE('@db.schema.files', 'document.pdf'),
responseFormat => {'name': 'What is the last name?',
'date': 'What is the inspection date?'},
scores => TRUE
);受け付けるファイルはPDF、PNG、PPTX、PPT、EML、DOC、DOCX、JPEG、JPG、HTM、HTML、TEXT、TXT、TIF、TIFF、BMP、GIF、WEBP、MDで、上限は100MBかつ125ページです。長い契約書や年次報告書は125ページで頭打ちになるため、事前にページ分割する前処理が要ります。対応言語は日本語を含む29言語です。スキャン画質が低い文書ではconfigのscale_factorを1.0から4.0の範囲で上げるとOCR品質が改善しますが、後述のとおり消費トークンも変わります。
AI_PARSE_DOCUMENT：OCRモードとLAYOUTモード
「SnowflakeでOCRをかけたい」という要件はこの関数が受け持ちます。モードは2つで、既定のOCRはテキストのみを取り出し、LAYOUTは表などの構造を保ったまま取り出します。表組みの数値を後段で扱うならLAYOUTを選びます。
SELECT AI_PARSE_DOCUMENT(
TO_FILE('@my_stage', 'document.pdf'),
OBJECT_CONSTRUCT('mode', 'LAYOUT', 'page_split', true)
);page_splitをtrueにすると文書をページ単位に分割して処理しますが、対応形式はPDF、.pptx、.docxの3つだけです。スキャン画像を束ねたTIFFやJPEGではこのオプションが効きません。実際のクエリ例と日本語文書での挙動はSnowflakeの新AI機能「AI_EXTRACT」と「AI_PARSE_DOCUMENT」が日本語に対応で扱っています。
AI_CLASSIFYとAI_COMPLETEの守備範囲
AI_CLASSIFYは、自分で定義したカテゴリのどれに当たるかを返します。請求書と納品書と契約書が混ざって届くフォルダを、抽出前に振り分ける用途がこれにあたります。AI_COMPLETEは最も汎用的で、モデルを指定して任意のプロンプトを投げられます。前3つで型にはまらない加工が必要になったときの逃げ道として置いておくのが現実的な使い方です。関数群全体の位置づけはCortex AI（Snowflake）とは？主要機能・導入メリット・読み方を解説にまとめています。
日本リージョンではクロスリージョン推論が前提になる
ここが日本で構築する場合の最大の落とし穴です。公式のリージョン対応表でAI_EXTRACTは、AWS AP Northeast 1（東京）でもAzure Japan East（東京、埼玉）でも「Cross-region only」と記載されています。つまり東京リージョンのアカウントで素朴に呼び出しても動きません。公式の指示は「If your region is not listed for a particular function, use cross-region inference.」です。
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'ANY_REGION';設定できるのはACCOUNTADMINロールのみで、ORGADMINでは設定できません。値はANY_REGIONのほか、AWS_GLOBALやAWS_USのようにクラウドや地域を絞る指定、処理を自リージョンに限定するDISABLEDがあります。2026年3月9日以降に新しい組織で作成された商用リージョンのアカウントはANY_REGIONが既定です。裏を返せば、それ以前に作られた既存アカウントでは明示的な変更が要ります。
セキュリティ部門への説明で要点になるのは、推論のために外へ出るのはリクエストであって保管データではない、という点です。公式は顧客データがアカウントのあるリージョンにのみ保管され続けること、クロスリージョン推論でデータ転送課金は発生しないこと、クレジットは処理側ではなくリクエスト元のリージョンで消費されることを明記しています。それでも推論リクエストが国外を経由する事実は変わらないため、規程で越境処理を禁じている場合はAWS_GLOBAL等での絞り込みか、そもそも別の手段を検討することになります。データ側の統制と併せて設計するならSnowflake Horizon Catalogとは？機能と設定SQLを解説が参考になります。
コストはAIクレジットで別建てになる
文書処理の費用はウェアハウスの計算コストとは別枠です。Snowflakeの料金体系ではAIクレジットという単位が使われ、オンデマンドではグローバルルーティングが1AIクレジットあたり2.00米ドル、リージョナルルーティングが2.20米ドルとなります。通常のプラットフォームクレジットとの決定的な違いは、AIクレジットがStandard、Enterprise、Business Critical、VPSといったエディションやリージョンによらず同一価格である点。既存契約のボリューム割引率で見積もると外します。
計上の単位は関数によって違います。AI_EXTRACTを含むAI関数は処理した100万トークンあたり、AI_PARSE_DOCUMENTは処理した1,000ページあたりで課金されます。ここで見落としやすいのが、AI_EXTRACTにファイルを渡したときの換算です。公式は「Each page in a document is counted as 970 tokens.」と記載しています。125ページの文書1件で入力側だけでも12万トークン強に達する計算になるため、全件をバッチで流す設計にする前に対象文書のページ数分布を確認しておくべきです。前述のscale_factorを上げると消費トークン数も変わります。
実績の確認にはCORTEX_FUNCTIONS_USAGE_HISTORYとCORTEX_FUNCTIONS_QUERY_USAGE_HISTORYのアカウント使用状況ビューを使います。前者は関数呼び出し単位、後者はクエリ単位でモデル別に集計されます。ただしREST API経由のリクエストについては細かい利用情報が取得できないと明記されているため、アプリケーションからREST経由で叩く構成では別途アプリ側のログが要ります。
今から着手する場合の判断基準
まず、Document AIを前提に書かれた解説記事や社内手順書は破棄してください。UIのスクリーンショットが載っている資料は、その時点で2026年3月16日より前のものです。モデルを作って育てるという前提そのものが消えているため、部分的な読み替えは成立しません。
そのうえで、次のように分岐させるのが実務的です。抽出したい項目が固定的で、様式もほぼ一定ならAI_EXTRACTを単体で使います。文書をRAGの検索対象にしたい、あるいは後段でLLMに読ませたいだけならAI_PARSE_DOCUMENTでテキスト化するところで止め、抽出は後段に任せます。様式が複数混在するならAI_CLASSIFYで振り分けてから、型ごとにresponseFormatを変えたAI_EXTRACTを通します。
逆に、Snowflakeで文書処理を組むべきでない場面もあります。1つ目は、1件あたり125ページを超える文書が主対象で、かつ分割前処理を置く余地がないとき。2つ目は、抽出結果に対する人手の確認画面と差し戻しフローが業務上必須で、その画面をSnowflake内に作る予定がないとき。3つ目は、規程上、推論リクエストの越境が認められず東京リージョンで完結させる必要があるときです。3つ目については、AI_EXTRACTが東京で「Cross-region only」である以上、現時点で回避策はありません。いずれかに当たるなら、専用の文書処理サービスを外に置き、抽出後の構造化データだけをSnowflakeへ取り込む構成のほうが素直でしょう。
よくある質問
ドキュメントAIとは何ですか？
一般名詞としては、PDFやスキャン画像などの非構造化文書からAIで項目を読み取り、データベースで扱える形にする技術の総称です。Snowflakeの製品名としての「Document AI」は、Arctic-TILTモデルをノーコードUIから使う機能を指していましたが、2026年3月16日に廃止されています。現在Snowflakeで同じ目的を果たすのはAI_EXTRACTとAI_PARSE_DOCUMENTです。
Snowflakeで非構造化データを処理するAI関数はどれですか？
文書であればAI_PARSE_DOCUMENTでテキストやレイアウトに変換し、項目単位で取り出したい場合はAI_EXTRACTを使います。分類はAI_CLASSIFY、それ以外の任意加工はAI_COMPLETEです。呼び出しにはアカウントレベルのUSE AI FUNCTIONS権限と、CORTEX_USERまたはAI_FUNCTIONS_USERのいずれかのデータベースロールが必要です。
SnowflakeでOCRだけを使うことはできますか？
できます。AI_PARSE_DOCUMENTの既定モードがOCRで、抽出されるのはテキストのみです。表の構造まで保持したい場合だけLAYOUTを指定してください。スキャン品質が低い文書なら、AI_EXTRACT側のscale_factorを1.0から4.0の範囲で調整する手もあります。
SnowflakeでPDFを読み込むにはどうしますか？
PDFを内部ステージまたは外部ステージに置き、TO_FILE('@db.schema.stage', 'file.pdf')でFILE型として関数に渡します。ステージはSnowflakeがファイルを置く場所を指す仕組みで、テーブルと同じようにデータベースとスキーマの下に作ります。AI_EXTRACTに渡す場合の上限は100MBかつ125ページです。
Document AIで作ったモデルはまだ使えますか？
2026年3月16日までにSnowflake Model Registryへ移行したモデルに限り、AI_EXTRACT(model => ..., file => ...)の形で推論を続けられます。移行していないモデルは廃止日以降利用できません。移行済みモデルも追加のファインチューニングはできないため、抽出項目を変えたい場合は現行のAI_EXTRACTへ組み替えることになります。
