Snowflake Document AI:概要・料金・コスト監視

Snowflake Document AIは、非構造化ドキュメントをAIでクエリ可能な構造化データに変換するサービスです。請求書や契約書、各種フォームをSnowflake内で直接処理できます。独自開発のArctic-TILTモデルを採用し、PDFや画像からテキスト・表・エンティティを抽出。ANLSベンチマークで90%の精度を達成し、GPT-4を上回ります。Arctic-TILTは単一GPUで動作するため、コスト効率にも優れています。料金はStandard Editionで1ページあたり約$0.012〜$0.018からで、企業データの80〜90%を占めるとされる非構造化データの活用課題に応えるサービスです。事前学習なしで新しい種類のドキュメントから情報を抽出するゼロショット対応に加え、わずか5〜20件のサンプルでファインチューニングも可能です。

Document AIは、モデル構築と推論の2フェーズで構成されるワークフローを通じて、非構造化ドキュメントをクエリ可能な構造化データに変換します。

フェーズ1:抽出モデルの構築

モデルはSnowsight UIの「AI & ML → Document AI」から作成します。SNOWFLAKE.DOCUMENT_INTELLIGENCE_CREATORデータベースロールが必要です。

USE ROLE ACCOUNTADMIN;

CREATE ROLE doc_ai_role;
GRANT DATABASE ROLE SNOWFLAKE.DOCUMENT_INTELLIGENCE_CREATOR TO ROLE doc_ai_role;
GRANT ROLE doc_ai_role TO USER your_username;

処理対象となるドキュメントタイプを代表するサンプルを10〜20件アップロードします。続いて「請求書番号は?」「ベンダー名は?」「明細にはどの項目が記載されているか?」といった自然言語の質問形式で抽出項目を定義します。抽出結果を確認して誤りを修正し、モデルを学習させたうえで(任意ですが、20件以上のドキュメントを使う場合は推奨)、本番利用に向けて公開します。

モデルは修正内容から抽出パターンを学習します。MLの専門知識は不要で、ドキュメント内のどこにデータがあるかという質問に答えるだけで構築できます。

フェーズ2:インフラの構築

ドキュメント処理用のウェアハウス、データベース、スキーマ、ステージを作成します。

CREATE WAREHOUSE doc_ai_wh
  WAREHOUSE_SIZE = 'X-SMALL'
  AUTO_SUSPEND = 600
  AUTO_RESUME = TRUE;

CREATE DATABASE doc_ai_db;
CREATE SCHEMA doc_ai_db.doc_ai_schema;

-- 重要:SNOWFLAKE_SSE暗号化を必ず指定すること
CREATE STAGE doc_ai_stage
  DIRECTORY = (ENABLE = TRUE)
  ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');

PUTコマンド、またはS3・Azure Blob・GCSへの外部ステージ連携を使ってドキュメントをステージにアップロードします。

フェーズ3:抽出クエリの実行

model!PREDICTメソッドでデータを抽出します。

SELECT
  RELATIVE_PATH as file_name,
  invoice_model!PREDICT(GET_PRESIGNED_URL(@doc_ai_stage, RELATIVE_PATH), 1) as extracted_data
FROM DIRECTORY(@doc_ai_stage);

出力は、抽出された値と信頼度スコアを含むJSON形式で返されます。

{
  "invoice_number": [{"value": "INV-2024-001", "score": 0.95}],
  "vendor_name": [{"value": "Acme Corp", "score": 0.92}],
  "total_amount": [{"value": "1250.00", "score": 0.98}],
  "__documentMetadata": {"ocrScore": 0.89}
}

抽出結果を構造化テーブルに整形する

JSON出力を扱いやすいカラムに変換します。

WITH extraction AS (
  SELECT
    RELATIVE_PATH as file_name,
    invoice_model!PREDICT(GET_PRESIGNED_URL(@doc_ai_stage, RELATIVE_PATH), 1) as json
  FROM DIRECTORY(@doc_ai_stage)
)
SELECT
  file_name,
  json:invoice_number[0]:value::STRING AS invoice_num,
  json:invoice_number[0]:score::FLOAT AS invoice_confidence,
  json:vendor_name[0]:value::STRING AS vendor,
  json:total_amount[0]:value::STRING AS total,
  json:__documentMetadata.ocrScore::FLOAT AS ocr_quality
FROM extraction;

結果を複数行にフラット化したり、StreamsとTasksで自動化したりと、さらに発展させる余地は数多くありますが、サンプルはここまでにとどめます。

SnowflakeはDocument AIの利用料金をSnowflake管理のAIサービス用コンピュートとして課金しており、workloadに応じて自動的にスケールします。クレジットはコンピュート時間に基づき1時間あたり8クレジット(2025年9月時点)で消費され、消費量はページ数、ドキュメントの密度、抽出する値の数によって変動します。これは、他のCortex LLM機能で採用されているトークンベースの課金とは根本的に異なる仕組みです。

1,000ページあたりのクレジット消費量

コストはドキュメントの密度と抽出の複雑さに応じて変動します。Snowflake公式の料金ドキュメントに記載されている範囲は以下のとおりです。

低密度ドキュメント(請求書、スライドなど)― 1件10ページのドキュメント100件:

• 抽出値10個:1,000ページあたり4〜7クレジット
• 抽出値20個:1,000ページあたり6〜11クレジット
• 抽出値40個:1,000ページあたり10〜24クレジット

高密度ドキュメント(研究論文、法律契約書など):

• 抽出値10個:1,000ページあたり7〜10クレジット
• 抽出値20個:1,000ページあたり11〜15クレジット
• 抽出値40個:1,000ページあたり21〜35クレジット

表の抽出(プレビュー機能)― 1件2〜10ページのドキュメント1,000件:

• 極小サイズの表(10セル未満):5〜37クレジット
• 小サイズの表(11〜25セル):14〜52クレジット
• 中サイズの表(26〜50セル):24〜86クレジット
• 大サイズの表(51〜400セル):37〜369クレジット

実例で考えるコスト

発注書(PO)処理の例:

年間10,000件の発注書を処理するケースで考えてみましょう。各POは典型的な書式の1ページ・低密度ドキュメントとし、抽出項目は顧客名、顧客住所、PO番号、PO日付、明細項目(表)、合計金額です。合計10,000ページで、1件あたり約10個の値を抽出することになります。1ページのドキュメント1,000件分の低密度推定値に基づくと、1,000ページあたり9〜12クレジットを消費するため、年間で90〜120クレジットの消費となります。

Enterprise Editionで一般的な1クレジットあたり$3で計算すると、年間コストは$270〜$360と試算できます。実際のコストは使用するコンピュート量によって変動します。

この例からもわかるように、Document AIなら年間数千件のドキュメント処理が数百ドル程度で実現可能です。本来であれば多大な工数を要する手作業のデータ入力を自動化する手段として、コスト効率の高い選択肢といえます。

その他のコスト

仮想ウェアハウスのコスト

Document AIのジョブを起動するには仮想ウェアハウスが必要です。AI処理自体はユーザーのウェアハウス上では動作しませんが、ジョブを開始する処理にはウェアハウスを使用します。ウェアハウスのサイズはAIタスクの処理速度には影響しないため、常にX-Smallの利用を推奨します。

ストレージコスト

ステージ内のドキュメントや結果テーブルのストレージは、通常のストレージ料金で課金されます。たとえばEnterprise Editionでは、$23/TB/月程度が一般的です。

Snowflakeでは、Document AIの消費量を追跡するための専用ビューがACCOUNT_USAGEに用意されています。レイテンシは約2時間、データ保持期間は365日です。

メインの監視ビュー

DOCUMENT_AI_USAGE_HISTORYビューには、クエリ単位のクレジット消費量が記録されます。

SELECT
  START_TIME,
  END_TIME,
  CREDITS_USED,
  QUERY_ID,
  OPERATION_NAME,
  PAGE_COUNT,
  DOCUMENT_COUNT,
  FEATURE_COUNT
FROM SNOWFLAKE.ACCOUNT_USAGE.DOCUMENT_AI_USAGE_HISTORY
WHERE START_TIME >= DATEADD(day, -30, CURRENT_TIMESTAMP())
ORDER BY START_TIME DESC;

日次のクレジット消費量

支出のトレンドを把握するために、利用状況を日次で集計します。

SELECT
  DATE_TRUNC('DAY', START_TIME) AS usage_date,
  COUNT(*) AS total_queries,
  SUM(CREDITS_USED) AS total_credits,
  SUM(PAGE_COUNT) AS total_pages,
  SUM(DOCUMENT_COUNT) AS total_documents,
  ROUND(SUM(CREDITS_USED) / NULLIF(SUM(PAGE_COUNT), 0), 4) AS credits_per_page,
  ROUND(SUM(CREDITS_USED) / NULLIF(SUM(DOCUMENT_COUNT), 0), 4) AS credits_per_document
FROM SNOWFLAKE.ACCOUNT_USAGE.DOCUMENT_AI_USAGE_HISTORY
WHERE START_TIME >= DATEADD(day, -90, CURRENT_TIMESTAMP())
GROUP BY DATE_TRUNC('DAY', START_TIME)
ORDER BY usage_date DESC;

ユーザー別・ロール別のコスト

どのユーザーやロールがDocument AIのクレジットを消費しているかを把握します。

SELECT
  qh.USER_NAME,
  qh.ROLE_NAME,
  COUNT(DISTINCT dh.QUERY_ID) AS query_count,
  SUM(dh.CREDITS_USED) AS total_credits,
  SUM(dh.PAGE_COUNT) AS total_pages,
  ROUND(SUM(dh.CREDITS_USED) / NULLIF(SUM(dh.PAGE_COUNT), 0), 4) AS credits_per_page
FROM SNOWFLAKE.ACCOUNT_USAGE.DOCUMENT_AI_USAGE_HISTORY dh
JOIN SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY qh
  ON dh.QUERY_ID = qh.QUERY_ID
WHERE dh.START_TIME >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY qh.USER_NAME, qh.ROLE_NAME
ORDER BY total_credits DESC;

ウェアハウス別のコスト

どのウェアハウスがDocument AIクエリを処理しているかを特定します。

SELECT
  qh.WAREHOUSE_NAME,
  qh.WAREHOUSE_SIZE,
  COUNT(DISTINCT dh.QUERY_ID) AS query_count,
  SUM(dh.CREDITS_USED) AS docai_credits,
  SUM(dh.PAGE_COUNT) AS total_pages,
  SUM(dh.DOCUMENT_COUNT) AS total_documents
FROM SNOWFLAKE.ACCOUNT_USAGE.DOCUMENT_AI_USAGE_HISTORY dh
JOIN SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY qh
  ON dh.QUERY_ID = qh.QUERY_ID
WHERE dh.START_TIME >= DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND qh.WAREHOUSE_NAME IS NOT NULL
GROUP BY qh.WAREHOUSE_NAME, qh.WAREHOUSE_SIZE
ORDER BY docai_credits DESC;

上記のクエリを応用し、X-Small以外のウェアハウスが使われた場合に通知を飛ばす仕組みにしておくのもおすすめです。

ダッシュボードだけでなくアラートも設定する

前述の監視クエリも、誰も実行しなければ意味がありません。Snowflakeで監視したい項目があれば、SQLをスケジュールタスクでラップし、Notification Integrationと組み合わせることで、SlackやTeamsにアラートを送るカスタムモニターを構築できます。手軽に使える監視機能をお探しなら、SELECTのモニター機能もぜひご覧ください。

ウェアハウスはX-SmallかSmall一択

Document AIはSnowflake管理のサーバーレスコンピュート上で動作します。ユーザー側のウェアハウスは、PREDICTメソッドをラップするSQLクエリを実行するだけです。ウェアハウスを大きくしてもDocument AIの処理速度はまったく向上しません。一方でコストは1クレジット/時間(X-Small)から4クレジット/時間以上(Medium以上)へと跳ね上がります。

本当に必要な値だけを抽出する

抽出フィールドが1つ増えるごとに、処理時間とコストは増加します。中密度ドキュメントの場合、10個の値を抽出すると1,000ページあたり4〜7クレジットですが、40個になると16〜30クレジット(2〜3倍)に増えます。

抽出モデルは、後続のアプリケーションで実際に必要なフィールドだけを対象に設計しましょう。「いつか役立つかもしれないから全部」ではなく、「今必要なもの」だけを抽出するのが鉄則です。後からフィールドを追加した新しいモデルを構築することはいつでもできます。

処理前にドキュメントをタイプ別にまとめる

ドキュメントをタイプごとにグループ化すると、処理効率が向上します。まず分類モデルでドキュメントタイプを識別し、それぞれ専用の抽出モデルにルーティングしましょう。

WITH classification AS (
  SELECT
    RELATIVE_PATH as file_name,
    classifier!PREDICT(GET_PRESIGNED_URL(@doc_ai_stage, RELATIVE_PATH), 1) as doc_type_result
  FROM DIRECTORY(@doc_ai_stage)
)
SELECT
  file_name,
  doc_type_result:document_type[0]:value::STRING as doc_type,
  CASE
    WHEN doc_type_result:document_type[0]:value::STRING = 'invoice'
      THEN invoice_model!PREDICT(GET_PRESIGNED_URL(@doc_ai_stage, file_name), 1)
    WHEN doc_type_result:document_type[0]:value::STRING = 'contract'
      THEN contract_model!PREDICT(GET_PRESIGNED_URL(@doc_ai_stage, file_name), 1)
  END as extraction

コードを展開

このアプローチは、各モデルが1つのドキュメント形式に特化できるため、精度向上にもつながります。

信頼度スコアの閾値と人によるレビュー工程を組み込む

Document AIは抽出値ごとに信頼度スコアを返します。すべての抽出結果を鵜呑みにせず、品質管理の仕組みを設けましょう。

-- 高信頼度の抽出結果はそのまま本番テーブルへ
CREATE TABLE production_data AS
SELECT
  file_name,
  json:invoice_number[0]:value::STRING as invoice_number,
  json:total_amount[0]:value::STRING as total_amount
FROM extraction_results
WHERE json:invoice_number[0]:score::FLOAT > 0.90
  AND json:total_amount[0]:score::FLOAT > 0.90;

-- 低信頼度の抽出結果は人によるレビュー対象へ
CREATE TABLE manual_review_queue AS
SELECT
  file_name,
  json as full_extraction

コードを展開

閾値はリスク許容度に応じて設定します。財務データなら0.95以上の信頼度を求め、社内ドキュメントなら0.75以上で許容する、といった具合です。サンプルドキュメントで閾値を試しながら、自動化と精度の最適なバランスを見つけましょう。

Document AIは、ドキュメント処理の大規模な自動化を、低密度ドキュメントなら1件あたりわずか数セントで実現できる手頃な手段です。コストを抑えるカギは、何がコストを左右するかを理解すること。ページ数、ドキュメント密度、抽出値の数は、いずれもコンピュート時間とクレジット消費量に直結します。PREDICTメソッドの実行には小さなウェアハウス(X-SmallかSmall)を使い、本当に必要なフィールドだけを抽出し、品質管理のために信頼度スコアの閾値を設定しましょう。さらに重要なのは、前述の監視クエリにアラートを設定し、月次の請求書を見て初めてコストの急増に気づくという事態を避けることです。まずは少量のドキュメントから始め、消費パターンをよく観察しながら、実コストを把握したうえで段階的にスケールアップしていくのがおすすめです。

Document AIをどう活用しているか、ぜひ教えてください。実際の導入事例や、効果に対する率直なご意見をお待ちしています。

Jeffはデータ&アナリティクスのコンサルタントとして15年以上にわたり、インサイトの自動化やデータを活用したビジネスプロセスの制御に携わってきました。技術面ではSnowflake + dbt + Tableauを得意とし、業務領域では公益事業、臨床試験、出版、CPG、製造業での経験があります。お気軽にご連絡ください:[email protected]