製造業の購買担当が、ある部品を代替品に切り替えられるか調べるとします。手元にあるのは、複数年度の仕様書と変更履歴です。古い仕様書では使用可能でも、その後の変更で、特定の温度や製造時期に制約が加わっているかもしれません。関連資料をまとめてAIに渡せれば、各文書から条件を探し、突き合わせる作業を助けられると考えられます。
この使い方を考える手がかりが、DeepSeekが2026年4月24日に発表したV4のプレビューです。同社は学習済みのモデルの重みを公開し、100万トークンの文脈を扱えると案内しました。本記事では4月の発表を振り返り、長い資料を読める仕組みと、仕事で役立つかを確かめる方法を考えます。
100万トークンは、回答のために扱う情報の広さ
文脈とは、AIが回答を作る際に参照する情報の範囲です。その長さを数えるトークンは、文字や語を細かく区切った単位を指します。100万トークンは日本語100万文字と同じではなく、この数字だけで仕様書を何冊渡せるかは決められません。
長い文脈の利点は、関連する記述を同じ入力の中に置きやすくなることです。たとえば、部品の寸法を示す仕様書、使用環境を定める文書、後から加わった変更履歴をまとめ、互換性に関わる条件を整理させる使い方が考えられます。
人が先に必要そうなページを選ぶ方法に比べ、資料を絞り込む手間を減らせる可能性があります。ただし、長く渡せることと、全ての条件を正しく拾えることは別です。文脈の長さは扱う情報の範囲を示し、回答の正確さを表す点数ではありません。
資料を入力し、内部で処理して、条件の整理を受け取る
入力には、仕様書や変更履歴の内容に加え、代替できる条件、できない条件、記述が食い違う箇所を整理するよう依頼を添えます。これは想定する使い方です。文書ファイルをそのまま読み込めるか、表や注記をどう取り出せるかは、利用する環境で確かめる必要があります。
入力を受けた内部の処理について、DeepSeekはトークンごとの圧縮と、疎な注意機構を使う構成を説明しています。注意機構は、入力のどの部分を参照するかに関わる仕組みです。「疎な」とは、参照するつながりを絞って扱うことを意味します。同社は、こうした構成で長い入力を扱う計算やメモリの負担を抑えるとしています。
ここでいう圧縮は、担当者が文書を短い要約に書き換えることと同じではありません。モデル内部で情報を扱う仕組みを指します。この説明だけから、仕様書にある細かな例外条件まで必ず保持されるとは判断できません。
出力として求めたいのは、互換条件と、その判断につながる記述の整理です。たとえば、条件ごとに資料名と参照ページを示すよう依頼すれば、担当者が該当箇所と照合する流れを作れます。参照先を正しく示せるかも含め、実務で試す際の設計案であり、V4で確認済みの業務能力を示すものではありません。
モデル全体の大きさと、処理時に使う部分は異なる
発表された数値では、Proは総パラメータ1.6兆に対して稼働490億、Flashは総2840億に対して稼働130億です。パラメータは、モデルの振る舞いを決める数値を指します。公開重みとは、こうした学習済みの数値を公開することです。
この数字には、モデル全体が持つ量と、処理時に稼働する量という違いがあります。Proでは全体の1.6兆に対して490億が稼働し、Flashでは全体の2840億に対して130億が稼働する、という関係です。
組織全体の人数と、一つの案件に参加する人数を分けて考えると、二つの数字の違いを捉えやすくなります。ただし、これは量の関係を理解するための比喩です。実際にモデルの中で、人のような担当者が仕事を分担しているという意味ではありません。
稼働する部分が全体より小さくても、その数値だけで手元の機器で動くか、費用がいくらになるかは決まりません。総パラメータが多いことだけを理由に、部品の互換条件をより正確に抽出できるとも言えません。文脈の長さ、モデルの大きさ、業務で必要な正確さは、分けて確かめる必要があります。
正解が分かる問いで、例外条件まで拾えるかを試す
購買業務で導入を検討するなら、担当者が正解と参照ページを把握している少数の問いから試すと、回答の良し悪しを判断しやすいと考えられます。以下は実務向けの検証案であり、DeepSeekが公表した評価結果ではありません。
まず、既に確認済みの代替条件を一つ選び、仕様書と変更履歴を渡します。AIが正しい条件を答えたかに加え、示したページに本当にその記述があるかを確認します。寸法の条件が合っていても、適用時期や除外条件が抜けていれば、そのまま購買判断には使えません。
次に、古い仕様書と後の変更履歴で条件が食い違う例を試します。文書には名称、年度、ページを識別できる情報を添え、AIが食い違いを示せるかを見ます。どちらの条件を採用すべきか資料から決まらない場合に、勝手に一つの結論へまとめないかも確認したい点です。
さらに、問いを変えずに関連資料を増やすと、入力が長くなっても必要な条件を拾えるかを調べられます。少ない資料で答えられた問いについて、資料を増やした場合の回答と比べる方法です。正解した問いは多いほどよく、条件の見落としや参照先の誤りは少ないほどよい、という基準を置けます。
応答時間と費用も、使った資料と依頼をそろえて記録すれば、比較の判断材料になります。4月の発表だけで現在のAPI価格や最新バージョンの優劣を判断せず、試す時点の利用条件と実際の結果を確かめる必要があります。
長い資料をまとめて渡せるようになると、担当者の作業は、必要なページを探す段階から、抽出された条件を確かめる段階へ比重を移せる可能性があります。購買担当が出典と条件を照合し、資料だけでは決められない箇所を設計担当へ照会する。その流れで判断を左右する一行まで拾えるかが、100万トークンを仕事に生かせるかどうかの試しどころです。