0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIに同じ質問を3経路で投げたら、入力トークンが約1,200倍違った — Claudeの「プログラム利用専用クレジット」と構造化APIの関係

0
Posted at

本記事は EDINET DB のブログ記事 「"AIが高くなる"のではなく"適正化される" — 入力トークンで差がつく時代の、構造化データベースの存在理由」 の転載です。最新版はそちらに掲載しています。

2026年5月14日、Anthropicが告知を出しました。6月15日から、Claudeの有料プラン(Pro / Max 5x / Max 20x / Team / Enterprise)に「プログラム利用専用の月次クレジット」を導入する、というものです。Claude Agent SDK、claude -p、Claude Code GitHub Actions、サードパーティのAgent SDKアプリの利用が、この専用クレジットから引き落とされる形になります。

金額はProが月20ドル、Max 5xが100ドル、Max 20xが200ドル。サブスク料金とちょうど同額です。繰り越しはなく、使い切った後に「usage credits」をONにすればAPIレートで従量課金、OFFのままなら次サイクルまで停止します。

一見、料金体系の整理に見えます。でも背景にあるのは、AI利用料が「人件費のように積み上がる」段階に入ったということです。誰かに作業を頼めば工数に応じて費用がかかる、という当たり前の感覚にAIが寄っていく。今回はその構造変化を、上場企業データを例に実演してみます。

月200ドルでAPI換算5,000ドル分焼けていた歪みが補正される

Claude Code Maxの月200ドルプランは、これまで対話UIだけでなくClaude Agent SDKやclaude -pも同じレート上限の中で動かせていました。重いagentic loopを回せばClaude Opusで1日に数百万トークン処理するのも珍しくなく、API直叩きに換算すれば月数千ドル相当の使い方ができていたわけです。

6月15日以降は、プログラム利用は専用クレジット(Max 20xなら月200ドル分)の枠内だけ。それを超えたら「usage credits」を有効にして従量課金にするか、その月は止めるか、どちらかを選ぶ形になります。レート制限自体はClaude Codeおよびチャットと共有のままで、別枠化されるのは金額の方です。

ユーザー側から見ると実質的な値上げに映ります。ただ提供側の経済合理性から見ると、これまで意図せず提供していた「サブスク料金の20倍以上のAPI価値」が正規価格に近づくだけです。Anthropicから見れば当然の補正で、OpenAIやGoogleも同じ方向に動くと考えるのが自然でしょう。

つまり、AI料金そのものが値上がりするというよりは、サブスクで吸収しきれていた裁定が消えて、「使った分だけ乗ってくる」構造に戻る、ということです。ここから先は、AIを業務で動かすときの判断軸が変わります。

読むコストが、出すコストより大きい

AI利用が「使った分だけ」になるなら、これから何を最適化すべきか。選択肢は大きく2つあります。1つはモデル単価を下げる方向(Opusではなく Sonnetを使う、安いモデルに切り替える、ローカルLLMを立てる)。もう1つは、そもそも渡すトークンの量を減らす方向です。

前者ばかり議論されがちですが、後者の方が削れる桁が圧倒的に大きいケースが大半です。

理由はシンプルで、ほとんどのAI業務処理では入力トークンが出力トークンの5〜20倍を占めるからです。長いドキュメントを読ませて短い答えを返させる、という形が典型だからです。Claude Sonnetの入力単価は出力単価の5分の1ですが、量で圧倒的に逆転し、結局月のコストの大半は入力側で決まります。

ここから言えることは1つ。「AIに何を読ませるか」をコントロールできる側が、これからのコスト勝負で有利になります。入力をPDFの全文渡しから必要な構造化データに置き換えられれば、モデルを安いものに替えるより遥かに大きい削減が出る、という構図です。

同じ質問を、3つの経路で投げてみる

ここからは実演に入ります。題材はソフトバンクグループ(東証9984、EDINETコードE02778)。質問は1つだけ。

ソフトバンクグループ(証券コード9984)の直近5年の純利益の推移を教えてください。

これを3つの経路で投げて、結果と入力トークン量を比べます。

  • 経路1: AIエージェントにそのまま質問する(Web検索ベース)
  • 経路2: 有報PDFを手元にダウンロードして、丸ごと添付する
  • 経路3: EDINET DBのMCPを繋いで、構造化APIから取らせる

経路1: Web検索だけで答えてもらう

まず一番素朴なやり方から。質問だけ投げて、AI側に勝手にWebを検索して答えさせます。今回はPerplexityを使いました。AI検索エンジンとして広く使われていて、MCPなどの外部データソース接続はなく、純粋にWeb検索ベースで答えるツールです。

Perplexity が SBG の純利益5年推移を Web 検索ベースで答えている画面

結果はそれっぽく出ます。FY2021が4.99兆円の最高益、FY2022〜FY2024が赤字、FY2025で1.15兆円の黒字復帰。さらに「2026年3月期は純利益5兆22億円で過去最高水準」と速報も補足してくれます。Web検索ベースの強みは、ここにあります。新しい情報も拾える。

一方、弱みは出典が分散することです。今回は10ソース参照したと表示されていますが、それぞれが証券会社サイト、地方新聞、ニュースアグリゲーターなど、独立した二次ソースです。数字が微妙に違ったとき、どれが正しいのかをAI側でも検証していません。出典がバラバラなため、後で「この数字の根拠は?」と聞かれたときの説明責任が分散します。

入力トークン量は、ユーザー側の質問文と、AIが取得した複数Webページの本文を合算する形になり、典型的には数千〜数万トークン規模です。Perplexity側は内部で要約・圧縮を入れているため絶対値は見えにくいですが、Web全文を全部読むほどではない、という量感です。

経路2: 有報PDFを丸ごと添付する

次は反対側の極端、「AIに有報そのものを読ませる」やり方。ソフトバンクグループの最新の有価証券報告書(FY2025、2025年6月26日提出)をEDINETからダウンロードして、PDFごとClaudeやChatGPTに添付して同じ質問を投げます。

Claude.ai に SBG 有報 PDF を添付して質問した直後、PDF 読み取りツールがフォント問題でラスタライズ処理に入っている画面

この経路の長所は、出典が一次情報(EDINET提出の有報)一本に絞られることです。AIが推論に使う情報源は、提出書類そのもの。説明責任は明確になります。

一方、量はかなり大きい。今回のPDFは320ページ、テキスト抽出すると約40万文字。OpenAIのトークナイザ(GPT-4o系)で測ると 約30万トークン です。Claude Sonnet 4.6の入力単価は100万トークンあたり3ドルなので、1社あたり 約0.9ドル。同じ質問を100社で繰り返すと、入力側だけで90ドルです。

さらに、AI側にも負担がかかります。30万トークンのコンテキストを推論で処理するのには時間がかかり、レイアウト崩れや単位の取り違え(千円・百万円・億円)といった誤読の余地も残ります。「PDFから純利益を抜き出す」だけのために、AIに320ページを読み切らせるのは、人を雇って財務諸表を読ませているのに近い、コストの構造です。

ここまでが、現状の「Webで聞く」と「PDFを読ませる」の両極です。間にあるのが構造化APIです。

経路3: 構造化API(MCP)から必要なフィールドだけ取る

3つ目は、EDINET DBが提供している構造化APIをMCP(Model Context Protocol)経由でAIに繋ぐ方法です。AIが対話の中で必要なフィールドだけを取り出せるようになります。今回はClaude.aiにEDINET DBのMCPコネクタを接続した状態で、同じ質問を投げました。

Claude.ai が EDINET DB の MCP 経由で SBG の純利益データを取得し、5年分のカードとチャートで可視化した画面

Claudeはまずsearch_companiesでEDINETコードを引いて、次にget_financialsで5年分の財務時系列を取得します。返ってきたJSONには、各年度の純利益・売上・営業利益などが揃った確定値で入っているので、AIはそれを元にそのままチャートと表に整形します。

今回の質問のために実際にAPIから受け取った入力トークン量は、必要な3指標(売上・営業利益・純利益)だけに絞れば、5年分でわずか 約250トークン です。全フィールドを取っても5,700トークン程度。30万トークンのPDFと比べれば、文字通り桁が違います。

出典は経路2と同じく、有報の構造化済みXBRLデータです。EDINETに提出された数字を、連結ベース・通貨単位を揃えた状態で持ってきているので、桁の誤読は構造的に起きません。

並べてみる: 入力トークンは約1,200倍違う

3つの経路を、同じ質問・同じ企業で比較するとこうなります。

経路 入力トークン量の目安 PDF全文を基準にした比 出典
1. Web検索のみ 数千〜数万 およそ 1/30 〜 1/100 複数の二次ソース
2. PDF全文添付 約30万 1(基準) 有報PDF(一次)
3. 構造化API + MCP 約250 およそ 1/1,200 有報XBRL(一次・構造化済み)

ざっくり整理すると、Web検索は安いが出典が散る、PDF全文は出典は綺麗だが重い、構造化API+MCPは出典は綺麗で軽い、という三層構造になっています。

これからAI料金が適正化されていくと、選ばれる経路は変わります。今までは「PDFを全部読ませても、サブスクの中なら無料同然」だったので、PDF経路にも合理性がありました。これからは、その重さが料金に直接乗ってきます。「軽くて、出典が一次で、必要な分だけ取れる」経路に流れていくのは、自然な動きです。

入力トークンを減らすと、精度も上がる

入力トークンを構造化APIに寄せると、コスト面以外にもうひとつ大きい変化が起きます。精度です。

有報PDFをAIに直接読ませると、誤読が起きやすい箇所がいくつかあります。3桁区切りの数値を読み間違える、単位(百万円・千円・億円)を取り違える、連結と単体を混同する、複数ページにまたがる表を集計し損なう。AIの推論ミスというよりは、PDFのレイアウトと数値表現の癖に由来する誤読です。長い入力を渡すほど、そこから取り出す中間値の誤読が下流タスク全体を歪めます。

構造化APIから返るデータは、XBRL(金融庁EDINETのXMLベース開示)の構造化値を、連結ベースで正規化して提供しています。「revenue」「operatingIncome」「netIncome」というフィールドが全社共通の定義で、桁・単位・通貨が揃った確定値で返ります。AI側の処理は「数値を読み解く」ではなく「すでに確定した数値を使って何かをする」になり、ハルシネーションの入る余地が大きく減ります。

つまり構造化APIに切り替えると、入力トークン削減によるコストダウンと、ハルシネーション減少による精度向上が同時に起きる。コストと品質がトレードオフではなく同方向に動く、という珍しい構図になります。

EDINET DBがもとからこの設計でやってきた理由

EDINET DBは、日本の上場企業3,800社超の有価証券報告書・四半期報告書・決算短信を、XBRLから構造化してREST APIとMCPで提供しているサービスです。同じ運営母体で、不動産・REITを対象にしたFUDOSAN DB、防災・気象・災害領域のBOUSAI DBを運営しており、さらに法人データベースなど、別領域の構造化データインフラも整備を進めています。

これらに共通している設計思想は1つです。

「公開されているけれど、AIや人がすぐに使える形になっていない」一次情報を、構造化して開放する。

有報は法的には公開データです。誰でもアクセスできる、はずです。でも、PDFの中に閉じ込められていて、業種分類はバラバラで、企業ごとに財務項目の名前まで違う。制度的にはオープンでも、実質的にはクローズドに近い状態が長く続いてきました。

少し補足すると、有報は2014年以降、PDFと並行してXBRLという機械可読フォーマットでも提出されています。これは構造化済みの一次情報そのものなのですが、企業ごとに独自タクソノミ拡張が許されている関係で、項目名(element_id)が会社ごとにバラつきます。「売上高」という同じ概念でも、A社はjpcrp_cor:NetSales、B社はjpcrp030000-asr_E12345-000:CustomNetSalesElementのように違うラベルで提出されてくる。さらに連結ベースか単独ベースかの区別、IFRS/JP GAAP/US GAAPの差、過年度遡及修正のフラグなど、生のXBRLを実用できる状態に持っていくには、業界横断で名寄せ・正規化する処理層が必要になります。EDINET DBがやっているのは、まさにこの層を全社・全年度ぶん固めて、AIから1クエリで使えるようにすることです。

この「公開されているけれど、使えない」状態が、個人投資家とプロのアナリスト、中小企業と大手、地方と東京の間に情報の非対称性を生んできました。データインフラを整える、というのは、その非対称性を制度的にではなく実質的に潰すことに直結します。

「ラストワンマイル」のその後

2026年3月に、関連するエッセイを1本書きました。「"知っている"が武器だった時代が終わる」— 情報格差のラストワンマイルです。要点をひとつ引用します。

世の中には「人間がデータを見るためのUI」が無数に存在する一方で、「AIがデータを読むための構造化データ」が圧倒的に不足している。

印刷革命は「情報の量」を変えた。インターネットは「情報へのアクセス」を変えた。AIは「情報の処理能力」を変えた。でも、AIが本来の力を発揮するための「ラストワンマイル」が残っている。それが、1次データの構造化です。

あのときは「思想」として書きました。今回6月15日のClaudeの料金体系変更は、その思想が経済合理性の側から追認された出来事だと感じています。

AIが安く・無制限に使えた時代には、ラストワンマイルを誰がやるかは曖昧でした。AI側がPDFを力技で読めばよかったし、サブスクの裁定の中でコストが見えていませんでした。これからは違います。「読むコストが見える」状態で、構造化されたデータがあるかないかが、AIエージェント運用の月次コストを左右します。

思想として正しかったかどうかではなく、構造化されていないと事業として続かない、という地点に移ってきている、ということです。

まとめ

同じ質問を3つの経路で投げたときの入力トークン量比較

6月15日のClaude料金体系見直しは、単発のニュースとして見れば「プログラム利用が別枠課金になる」だけの話です。ただ背景にあるのは、AIの単価が長期的に適正化される流れであり、これはAnthropicに限った動きではありません。

この流れの中で、AI活用のコスト勝負はモデル選びから「何を読ませるか」に重心が移ります。月200ドルで好きなだけAPIを焼けた時代が終わると、入力トークンを構造化された一次データに寄せられるかどうかが、運用コストの桁を決めるようになります。

EDINET DBが日本の上場企業データに対してやっている取り組みは、この構造変化に先回りした設計です。同じ思想で、不動産(FUDOSAN DB)・防災(BOUSAI DB)など、領域を横に広げて整備を進めています。AIが安く・正確に扱える一次データを揃えておけば、AI料金がどう変わっても、運用側の選択肢として機能し続けます。

無料プランからAPIキーを発行できます。MCPサーバーは設定ファイル1行で接続可能です。Claude Codeをはじめ、お使いのAIクライアントから一度試してみてください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?