投稿者 投稿日: カテゴリー Claude
100万トークンのコンテキストとは、全商品データを一度に読ませられる作業領域のことです。
Anthropicが2026年7月24日に公開したOpus 5は、100万トークンのコンテキストウィンドウを標準で備えています。商品3,000点分の商品名・価格・説明文・在庫を1回のリクエストで読ませ、横断的な矛盾や抜けを洗い出す使い方が現実的な選択肢になりました。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、楽天RMSやSeller Centralから落としたCSVを丸ごと読ませる手順を5段階で整理します。
100万トークンで何が変わったのか
変わったのは分析の粒度です。従来は商品を100点ずつ小分けにして投げていたため、「このジャンルだけ価格表記のルールが違う」「型番の付け方が3種類ある」といった、全体を並べて初めて見える問題を拾えませんでした。全件を一度に読ませられると、この横断的な比較が可能になります。
仕様を確認しておきます。Anthropicの公式ドキュメントによると、Opus 5のコンテキストウィンドウは100万トークンで、これが既定値かつ上限です。小さいコンテキストの別バリアントは用意されていません。出力は標準APIで最大128,000トークン、Batch APIでは300,000トークンまで対応します。推論（thinking）は既定で有効になっており、推論の強度として従来の「high」の上に「xhigh」、さらに上限なしの「max」という段階が追加されました。料金は100万トークンあたり入力5米ドル・出力25米ドルで、前世代のOpusから据え置きです。
ただし注意点があります。利用するクライアントやSDKの設定によっては、実効的なコンテキストが100万トークンより小さく制限されるという指摘が技術者コミュニティから出ています。この挙動は環境依存の可能性があり、公式に整理された説明を確認できていないため「要確認」としておきます。全件処理を本番運用に載せる前に、自社の実行環境で実際に何トークンまで受け付けるかを1度測ってください。
推論が既定で有効という点も、実務では効き方が変わります。従来は「考えさせるかどうか」を利用者が判断していましたが、既定で有効になったことで、単純な突き合わせ作業でも内部的に推論トークンが消費されます。棚卸しのように大量の行を機械的に照合する処理では、この推論が精度に効く場面と、費用だけ増える場面の両方があります。強度の段階が細かく分かれたのは、この使い分けを可能にするためだと理解しておくと、設定の意味が掴みやすくなります。
日本のEC事業者にとって、100万トークンという数字がどの程度の規模かを換算しておきます。日本語は1文字あたりおおむね1〜1.5トークンとされ、商品1点あたり商品名・価格・在庫・カテゴリ・簡易説明で400文字程度なら、約500トークン。単純計算で2,000点分が100万トークンの枠に収まる規模感です。説明文をフルで含めると1点あたり2,000トークンを超えるため、500点前後が上限になります。全件を読ませるか、列を絞って点数を増やすかは、分析の目的で決めます。
5手順：CSVを丸ごと読ませて棚卸しする
順番が重要です。列を絞らずにいきなり全件を投げると、トークン上限に当たるか、出力が散漫になります。
第1手順は、目的の確定です。何を見つけたいのかを1文で書きます。「価格表記のゆれを見つけたい」「送料区分の設定漏れを見つけたい」「商品名の型番フォーマットを統一したい」。目的が決まれば、必要な列が決まります。目的を決めずに全列を投げると、AIは無難な要約を返してきて、実務で使えない結果になります。
第2手順は、列の絞り込みです。楽天RMSの商品データダウンロードは列数が多く、そのまま投げるとトークンの大半を使わない情報が占めます。目的に必要な列だけを残したCSVを作ります。価格の棚卸しなら商品管理番号・商品名・販売価格・表示価格・送料区分の5列で足ります。列を5つに絞れば、3,000点でも十分に枠内に収まります。
絞り込みの作業自体は表計算ソフトで完結します。ダウンロードしたCSVを開き、不要な列を削除して別名保存するだけです。この工程を面倒に感じて全列のまま投げてしまうと、トークンの8割以上が分析に使われない情報で埋まります。文字コードの扱いにも注意が必要で、楽天RMSのCSVはShift-JISで出力されるため、そのまま貼り付けると文字化けすることがあります。UTF-8に変換してから渡すのが確実です。ここは毎回同じ作業になるので、手順書を1枚作っておくと担当者が変わっても回ります。
第3手順が、読み込みと横断分析です。CSVをそのまま貼るか、ファイルとして渡します。ここで効くのが、出力形式を先に指定しておくことです。
プロンプト1：全商品の価格表記ゆれ検出
あなたはECの商品マスタ整備に詳しいデータ分析者です。
添付のCSVは当店の全商品データです（列：商品管理番号／商品名／販売価格／表示価格／送料区分）。
以下の観点で全件を横断的に確認し、問題のある行を抽出してください。
1. 販売価格と表示価格の関係が他の商品と異なるパターン
2. 同一シリーズ・同一容量なのに価格の付け方が揃っていない組み合わせ
3. 送料区分が同カテゴリの他商品と食い違っている行
4. 価格が0または空欄の行
条件：
- 推測で値を補完しない。読み取れない箇所は「判定不可」と書く
- 抽出結果はCSV形式（列：商品管理番号／該当観点／現状値／想定される正しい値／確信度）
- 確信度は「高／中／低」の3段階
- 全件のうち何件を確認し、何件を問題ありと判定したかを冒頭に記載する
第4手順は、抽出結果の検算です。AIの出力をそのまま信じないための工程です。出力されたCSVの行数と、元データの該当行を突き合わせます。ここで多いのが、実在しない商品管理番号が混ざるケースです。件数が合わない、番号が元データにない、という時点で分析をやり直します。
プロンプト2：抽出結果の自己検算
先ほどあなたが抽出した問題行のリストについて、以下を検算してください。
1. 抽出した商品管理番号が、すべて元のCSVに実在するか
2. 抽出行の「現状値」が、元のCSVの値と一致しているか
3. 同じ商品管理番号を重複して抽出していないか
不一致があれば、その行を削除したうえで修正版のリストを出してください。
検算の結果、削除した行数と理由を報告してください。
新たに行を追加しないでください。
第5手順が、修正指示への変換です。分析結果を、そのまま作業者が動ける形に落とします。楽天RMSなら一括更新用のCSV、Seller Centralならフラットファイルの形式に合わせます。
プロンプト3：修正作業リストへの変換
検算済みの問題行リストを、作業者がそのまま処理できる指示書に変換してください。
出力の構成：
1. 修正の優先順位（売上上位商品を優先）
2. 一括更新で処理できる行と、個別確認が必要な行の分離
3. 一括更新できる行は、変更前と変更後の値を並べたCSV
4. 個別確認が必要な行は、確認すべき内容を1行で
条件：
- 価格の変更を伴う修正は、すべて「個別確認が必要」に分類する
- 作業時間の目安を、一括分と個別分それぞれで示す
全件処理でつまずく3つのパターン
最も多いのが、トークン上限に当たって処理が途中で切れるケースです。切れたことに気づかず、出力された分析を全件の結果だと思い込む。これが一番危険です。回避策は、プロンプトに「全件のうち何件を確認したかを冒頭に記載する」と入れておき、その数字が元データの行数と一致しているかを毎回見ることです。一致しなければ、列を減らすか分割します。
次に多いのが、商品管理番号の捏造です。長い入力を扱うとき、生成側が実在しない識別子を作ってしまうことがあります。第4手順の検算を省くと、存在しない商品への修正指示が作業リストに載ります。検算プロンプトは必ず通してください。
3つ目は、機密データの扱いです。仕入原価や取引先名を含む列をそのまま外部APIに投げてよいかは、社内の情報管理規程で判断が分かれます。棚卸しの目的に原価が不要なら、CSVを作る段階で列を落とす。必要な場合は、社内で完結する環境を検討します。ここを曖昧にしたまま運用を始めて、あとから止まる事例を見ています。
補足として、抽出の網羅性という論点も挙げておきます。全件を読ませたからといって、全件を等しく丁寧に見ているとは限りません。入力の中盤に置かれた情報の扱いが端に比べて弱くなる傾向は、長文脈を扱うモデル全般で指摘されてきた性質です。Opus 5でこの傾向がどの程度残るかは、公開されている検証結果からは判断できないため要確認としますが、実務上の対策は決まっています。重要なカテゴリを先頭に置く、同じ分析を並び順を変えて2回走らせて結果を突き合わせる。この2つで、取りこぼしのリスクはかなり下げられます。売上上位の商品だけは別途小さいバッチでも確認しておくと、なお安全です。
費用と工数はどれくらいか
商品3,000点、5列に絞ったCSVで1点あたり120トークンとすると、入力は36万トークン。Opus 5の単価で1.8米ドルです。出力を2万トークン見込むと0.5米ドル。1回の全件棚卸しで合計2.3米ドル、日本円で350円前後（1ドル155円換算・為替は要確認）になります。
これを人手で行う場合と比較します。3,000点の価格表記を目視で突き合わせると、1点あたり10秒でも8時間以上。実際には集中力が続かないため、複数日に分けて数日がかりの作業になります。しかも見落としが出ます。金額の差より、作業として成立するかどうかの差のほうが大きい領域です。
工数の実感としては、列の絞り込みとCSV作成に1時間、プロンプトの実行と検算に30分、修正リストの確認に1〜2時間。半日で一巡します。四半期に1度の棚卸し作業として組み込むのが現実的な頻度です。
効果の測り方も決めておきます。棚卸しのKPIは「見つけた問題の件数」ではありません。件数は初回が最も多く、回を重ねるほど減るのが正常な形なので、件数を目標に置くと運用が歪みます。見るべきは、修正した行が売上や指標にどう跳ねたかです。価格表記の不整合を直したカテゴリのCVR、送料区分の設定漏れを直した商品の注文数、商品名の型番フォーマットを揃えたシリーズの検索経由アクセス。この3つを修正の前後30日で比較します。全項目で効果が出るわけではなく、実務では検索経由アクセスが最も反応しやすい傾向にあります。
ある食品ギフト系の中規模店舗では、初回の棚卸しで商品名の容量表記が3種類に分かれていることが判明しました。「300g」「300ｇ」「300グラム」の混在です。統一後、該当シリーズの検索経由アクセスが約2割増えました。数字は商材と競合状況で変わるため、自社では1カテゴリの試行から始めて反応を測ってください。全件を一度に直すより、効果が確認できたパターンから横展開するほうが、社内の合意も取りやすくなります。
推論の強度設定も費用に効きます。効いてくるのは複雑な判断を伴う分析で、単純な突き合わせでは強度を上げても結果があまり変わりません。この使い分けについては推論の強度とコスト最適化の考え方にまとめてあります。長い出力を生成する側の話は128K出力で商品説明文を一括生成する手順を、他社モデルとの費用比較は主要モデルのコスト比較を参照してください。
長いコンテキストが変える、EC分析の作法
100万トークンが日常的に使えるようになると、分析の前処理という工程の位置づけが変わります。従来はデータを絞り込んでから分析するのが定石でした。絞り込みの過程で、分析者の仮説が入り込みます。「価格の問題を見たいから価格列だけ抜く」という判断自体が、価格以外の要因を見えなくします。
全件を読ませられるなら、仮説を持たずに「気になる点を挙げてください」と投げる使い方ができます。この使い方で出てくるのは、担当者が問題だと認識していなかった項目です。ある店舗では、カテゴリの付与ルールが年度ごとに変わっており、古い商品が検索に乗りにくくなっていたことがこの方法で見つかりました。仮説ベースの分析では、疑っていない箇所は永遠に見つかりません。
ただし、この使い方には限界もあります。全件を読ませても、AIは「重要そうに見える」ものを優先して報告します。売上規模との紐付けはデータに含まれていないと判断できないため、売上列を含めるかどうかで報告の質が変わります。何を重要とみなすかの基準は、人が与える必要があります。
もう一つの展望として、AIエージェントが商品データを直接読みに行く動きがあります。この流れが進むと、社内分析のためにCSVを落とす作業自体が減ります。ただしモール側のAPI提供範囲と規約の整理が追いついておらず、当面はCSVでの受け渡しが実務の中心であり続けると見ています。
よくある質問
Opus 5のコンテキストは本当に100万トークン使えますか
公式ドキュメント上は100万トークンが既定値かつ上限です。ただし利用するクライアントやSDKの設定によって実効値が小さくなるという指摘があり、この点は要確認としています。本番運用の前に、自社の実行環境で実際の受付上限を1度測ってください。
商品何点まで一度に読ませられますか
列の絞り方で決まります。商品管理番号・商品名・価格など5列程度に絞れば3,000点規模が枠内に収まり、説明文をフルで含めると500点前後が目安になります。日本語1文字あたり1〜1.5トークンという換算で、自社データから概算してください。
費用はどれくらいかかりますか
商品3,000点・5列のCSVで1回あたり2〜3米ドル程度が目安です。入力100万トークンあたり5米ドル、出力25米ドルという単価から計算した値で、実際の消費量はデータの内容によって変動します。
仕入原価が入ったCSVを読ませても大丈夫ですか
社内の情報管理規程によります。棚卸しの目的に原価が不要なら、CSVを作る段階で列を落とすのが確実です。原価を含めた分析が必要な場合は、外部APIに送信してよいかを先に社内で確認してください。
出力された修正リストをそのまま一括更新に使ってよいですか
いいえ、検算を挟んでください。実在しない商品管理番号が混ざる可能性があるため、抽出結果が元データと一致しているかを必ず確認します。価格変更を伴う修正は、一括更新に載せず個別確認に回すのが安全です。
楽天とAmazonのデータを同時に読ませられますか
可能ですが、列の意味が異なるため、どちらのデータかを示す列を追加してください。同じ「価格」でも税込・税抜の扱いが異なる場合があり、前提を揃えずに突き合わせると誤った差分が出ます。
導入の最初の一歩は何ですか
主力カテゴリ1つ、100点程度の小さいCSVで手順を一巡することです。ここで検算まで通し、出力が使える形になるかを確認してから全件に広げます。いきなり全件で始めると、うまくいかなかったときの原因が切り分けられません。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Anthropic｜What’s new in Claude Opus 5
- Anthropic｜Claude Opus
- MarkTechPost｜Meet the New Claude Opus 5: Frontier-Class Agentic Coding and Computer Use at Unchanged Opus Pricing
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
