Cohere Parseとは 使い方と料金

PDFの請求書をAIに読ませたら、表の行が1つずれて出てきた。

ドキュメント処理の自動化は、だいたい最初にここでつまずきますよね。

Cohereが2026年8月27日に出した Parse はそこを正面から潰しに来た製品ですが、公表ベンチマークをそのまま受け取ると判断を間違えます。

Cohere Parseとは 表とレイアウトを保ったままMarkdown化するAI

PDFやPPTを渡すと何が返ってくるか

PDF、PPT、JPEGを投げると、Markdownが返ってきます。

ここまでは他のOCRと同じに見えるんですが、中身が違う。

テーブルはHTMLとしてMarkdownに埋め込まれるので、結合セルや階層のある表が形を保ったまま残ります。

要素ごとのバウンディングボックス（ページ内の座標）と、図版の説明文も一緒に返ってくる。

先に制約も書いておくと、構造化JSONは返りません。

返るのはMarkdownなので、項目を取り出す処理は自前で持つ必要があります。

Cohere Documentation

This page describes how Cohere's Parse models work and how to use them.

docs.cohere.com

23億パラメータで9言語、日本語も安定動作の対象に入っている

正式名称は parse-v5.0。

23億パラメータの視覚言語モデルで、フットプリントは約4.6GB、コンテキストは8,192トークン、速度は標準構成で毎秒4.5ページです。

安定動作を公称しているのは9言語（アラビア語、英語、フランス語、ドイツ語、イタリア語、日本語、韓国語、ポルトガル語、スペイン語）。

日本語が最初から入っているので、国内のバックオフィス業務にそのまま持ち込めます。

それ以外もゼロショットで通りますが、精度は落ちます。

公表ベンチマークの79.2は、どこまで信じていい数字か

79.2は5軸のうち3軸だけを平均した数字

Cohereが公表している ParseBench のスコアは79.2。

同じ表に並ぶ Mistral OCR 4 が74.5、Azure Document Intelligence が74.3。

数字だけ見れば頭ひとつ抜けています。

ただ、ParseBench はもともと5軸で評価するベンチマークなんですよ。

テーブル、チャート、内容の忠実性、セマンティックな書式、視覚的グラウンディングの5つ。

79.2はこのうち3軸の平均で、内訳はテーブル87.0、内容の忠実性86.6、セマンティックな書式64.0です。

落ちた2軸が、チャートと視覚的グラウンディング。

視覚的グラウンディングは、抽出した内容がページのどこにあるかを正しく対応づけられるかを見る軸です。

Parseがバウンディングボックスを返せることを売りにしているのを思い出すと、そこが公表値から外れているのは引っかかります。

5軸すべてのリーダーボードに、Parseは載っていない

ParseBench には公開リーダーボードがあります。

約2,000ページの人手検証済み文書に、16.7万件を超える判定ルール。

5軸込みの総合首位は LlamaParse で、Parse発表時点のスコアは84.88。

そしてCohere Parseは、そこに載っていません。

GitHub - run-llama/ParseBench: ParseBench - A Document Parsing Benchmark for AI Agents

ParseBench - A Document Parsing Benchmark for AI Agents - run-llama/ParseBench

github.com

これは「Cohereがズルをした」という話ではなく、読み方の問題です。

請求書のように罫線の表が中心ならテーブル87.0が判断材料になりますが、IR資料のようにチャートが主役なら、79.2からは何も分かりません。

念のため付け加えると、ParseBench を作っているのは LlamaParse の開発元でもあります。

だからどちらの数字も、「測る側に都合のいい設計になっていないか」まで見たうえで使う。

ここを飛ばすと、導入後に「思ったより取れない」が確実に出てきます。

使い方 Base64にしてAPIに投げるだけ

多段パイプラインが1回のAPI呼び出しになる

これまでのドキュメント処理は、OCRをかけて、レイアウトを解析して、テーブルを抽出して、と段を重ねる構成でした。

段ごとに精度が落ちるので、どこで壊れたかの切り分けにも時間がかかる。

Parse は単一パスです。

ファイルをBase64にしてAPIに送ると、そのままMarkdownが返る。

検証環境を立てるのに要るのは、実質APIキーだけです。

EmbedやRerankと繋いでRAGの入口にする

Parse単体はあくまで入口で、Cohereは Embed と Rerank に繋いで検索や検索拡張生成のパイプラインを組む使い方を想定しています。

その一段目を担うのがParseです。

提供経路は Cohere API、Microsoft Foundry、Amazon SageMaker、そしてプライベート環境やオンプレミスに置ける Model Vault。

料金は従量課金と月額、切り替える分岐点を計算しておく

従量課金は1,000ページで225円前後

API従量課金は1,000ページあたり1.50ドル。

1ドル150円で換算して約225円、1ページあたり0.225円です。

月に5万ページ処理しても11,250円。

請求書処理のような業務なら、コストが導入のブレーキになることはまずありません。

月額プランが有利になるのは月167万ページから

Model Vault の料金は、Medium が1時間600円または月375,000円（2,500ドル）、XL が1時間1,050円または月645,000円（4,300ドル）。

分岐点を出しておきます。

375,000円 ÷ 0.225円 = 約167万ページ。

1日あたり5万5千ページを超えて初めて、Medium の月額プランが従量課金より安くなる計算です。

つまり、コストを理由に月額へ乗り換えるプロダクトはほとんどありません。

Model Vault を選ぶ理由は値段ではなく、「その書類を外部APIに出せない」という制約のほうです。

金融や医療のように持ち出し制限がかかるなら料金表より先にそこで決まりますし、逆に制約がないなら、毎月要らないコストを払うだけになります。

請求書処理と契約書検索、最初に試すならどこから手をつけるか

内訳スコアを業務に当てはめると、向き先がはっきりします。

• 請求書・納品書の読み取り: テーブル87.0が効く領域。明細行の構造が保たれるかで成否が決まる
• 契約書の全文検索: 内容の忠実性86.6。条項を1つ取りこぼすと意味がなくなる業務なので相性がいい
• 社内文書の検索拡張生成: 座標が返るので、回答の根拠に元ページのどこを見たかを示せる。社内に配るとき「なぜその答えなのか」に答えられる

逆に期待しすぎないほうがいいのが、セマンティックな書式の64.0。

見出しの階層やリスト構造の再現は3軸で最も低く、目次から章立てを自動生成するような使い方は厳しいです。

で、結局どうするか。

自社の書類を30ページほど選んで投げてみるのが最短です。

1,000ページで225円なので、検証にかかるのは数円。

ベンチマークの平均値ではなく、毎日さばいている書類で判断できます。