EC売上の分析、AIにどこまで任せていいか今さら聞けない人へ

月初の売上報告。前月比を出して、伸びた理由を1行そえる。

「セール効果」「季節要因」。去年の同じ月にも、同じ言葉を書いた気がする。数字は正しいのに、その1行だけは毎回なんとなく埋めている。

この記事は、月次の売上分析にAIをどこまで使えるのかを、編集部が架空の売上データを自作して検証したものである。実在店舗のデータでも、EC事業者への取材でもない。まず検証の出発点として、よくある月初の運用パターンを一つ想定した。楽天RMSのデータ分析メニューから先月分を落とし、GA4の探索でセッションとCVRを日別に並べ、Shopifyの管理画面からも同じ期間を抜く。三つの数字を一枚のシートに貼り、ピボットで日別とカテゴリ別に組み直す。ここまでは手順が決まっていて迷わない、という進み方である。止まるのはその次だと想定した。グラフはできた。谷も山も見えている。それで、この数字から何を言えばいいのか。

会議で求められているのは表ではない。「なぜ下がったのか」「来月どうするのか」の二つである。表を貼っただけの資料を出せば、その場で同じことを聞かれる。だからCSVをそのままチャットの入力欄に貼り付けてみる、という運用が考えられる。ここで返ってくるのが「LPの改善を検討しましょう」「SNS施策を強化しましょう」といった、どの店にも当てはまる提案だったとき、手が止まる。自社のデータを渡したのに、自社の話が返ってこない。この記事は、そこから先を検証で埋めるものである。

結論から書く。EC売上の分析にAIは使える。ただし届くのは異常の検知と「次にどのデータを見るべきか」の指定までで、原因の断定と最終判断は人が持つ。期間・指標の分け方・事実と推測の分離指示という渡し方で、出力の質は変わる。

AIが安定して当てるのは「いつ・どの指標が・どれだけ動いたか」まで。原因は、そのデータが手元にない限り誰にも特定できない。AIの限界ではなく、データの限界である。
同じデータでも、指示の書き方で出力の形が変わった。効いたのは「指標を分けて見ること」と「事実と推測を分けて書くこと」の二つ。
危険なのは外すことではなく、外したまま断定調で返ってくることだ。根拠のない原因が、社内資料の形をとって独り歩きする。

先に断っておく。この記事で紹介する検証は、編集部が架空の売上データを自作し、本メディアの運営者が使っているAI（Claude）に分析させたものである。実在の店舗のデータではなく、実在のEC事業者への取材でもない。複数のAIツールを比較したベンチマークでもなく、単一のAIによる自己検証にすぎない。この条件で何が言えて何が言えないかは、記事の中で都度ことわる。

売上データをAIに渡すと、実際に何が返ってくるのか
検証：原因を仕込んだ架空データを、AIに当てさせてみた
渡し方をひとつ変えると、出力の質が変わった
AIが強いのは「異常の検知」と「次に見る場所の指定」まで
原理的に届かない領域——データの外側にある原因
前処理：どの画面から、何を、どの形で落とすか
AIの出力を社内提案に変えるとき、人が埋める三つの穴
「分析ができる人」の価値は、どこに残るのか
よくある質問

売上データをAIに渡すと、実際に何が返ってくるのか

返ってくるものは、性質の違う三つの層に分かれている。ここを分けずに「分析結果」とひとくくりに読むから、使えるのか使えないのかが決まらない。

一層目は集計の言い換えである。月間の売上合計、日別の最大と最小、平均注文単価の推移。渡した数字を別の言葉に置き直したものだが、ここで先に潰しておくべき点がある。この層の数値は、そのままでは信用しない。合計が一件ずれる、増減率の分母を取り違える、月をまたいだ行を含めて平均を出す。こうした計算の取りこぼしは実際に起きる。対処は単純で、合計・平均・増減率は表計算側で確定させ、確定した数字を渡す。あるいは返ってきた数値をシートの値と突き合わせてから使う。集計の正しさを人が握っていない状態では、この先の異常検知も原因の推測も全部あてにならない。ここは最初に閉じる。

二層目は異常の指摘だ。「7月10日から12日にかけて売上が約47%下落している」「7月18日が月間ピークで、平常日の約1.4倍」。目視でも気づける規模の変動なら人間でも拾えるが、指標を五つ六つ並べて三十日分を見るとき、人の目はどこかを飛ばす。特に、売上が横ばいのままCVRだけが緩やかに落ちているような、金額に出ない変化を見落とす。数値の確定を先に済ませておけば、この層はAIのほうが速く、漏れも少ない。

三層目が原因と提案である。問題は全部ここに集まっている。「7月18日の急増はSNS施策が奏功したものです」「単価上昇はまとめ買い促進の効果と考えられます」。読むと、それらしい。だが渡したCSVには施策の情報など一行も入っていない。AIは持っていない情報を推論で埋め、しかもその埋めた部分を、集計の言い換えと同じ断定調で並べて返す。「LPを改善しましょう」という一般論も、根拠のない原因の断定も、出どころは同じだ。データに答えが入っていない問いに、答えさせられている。

層	返ってくるもの	信頼のしかた
集計の言い換え	合計・平均・増減率・最大最小	表計算で確定させた値を渡すか、返り値を突き合わせる
異常の指摘	どの日に、どの指標が、どれだけ動いたか	ここが本命。人の目より漏れが少ない
原因と提案	「〇〇が原因」「〇〇すべき」	渡したデータの中に根拠があるかを一件ずつ確認する

実務として押さえるのは一点だ。三層目に出てきた文を、二層目の事実に紐づいているものと、そうでないものに分けて読む。「セッションが横ばいなのにCVRだけ落ちている」は渡したデータから言える。「配送に問題があったからだ」は言えない。前者は資料に使え、後者は調査項目にしかならない。この線引きを毎回自分の手でやるかどうかで、AIを使った分析が武器になるか事故になるかが決まる。

検証：原因を仕込んだ架空データを、AIに当てさせてみた

「どこまで当たるのか」を確かめるには、正解を知っている状態でやるしかない。実データでやると、AIの出した原因が合っているかどうかを判定する材料が、そもそも手元にない。そこで検証の設計を逆にした。先に原因を決めてから、その原因が起きたらこう動くはずだ、という数値を作る。そのうえで原因の情報を伏せ、集計値だけをAIに渡す。

前提を先に書いておく。使ったのは架空のアパレル雑貨EC「テンポ和」の2026年7月・日別実績で、編集部の自作である。実在の店舗ではない。分析させたのは本メディアの運営者が使っているClaudeで、ChatGPTやGeminiとの比較はしていない。つまりこれは単一のAIによる一回きりの自己検証であり、AI全般の性能を測ったものでも、実務者の証言でもない。読み取れるのは「この条件でこう出た」までである。

渡した列は、日付・売上・注文数・セッション数・CVR・AOVの六つ。仕込んだ「正解」は次の四つで、いずれもAIには一切渡していない。

期間	数値の動き（AIに渡した側）	仕込んだ原因（渡していない側）
7/10〜7/12	売上18万円→9.5万円。セッションは2,150で横ばい。CVRが2.05%→1.02%	配送会社のシステム障害で「お届け日未定」が出続け、購入直前で離脱
7/18	売上24.9万円（月間ピーク。平常日18万円の約1.4倍）。セッション3,800に急増。トップスに注文集中	外部のインフルエンサーが無償で商品を紹介する投稿をした
7/24〜7/31	セッションは微増。売上はほぼ横ばいだが、CVRが2.05%→1.75%へ緩やかに低下	競合が同時期に10%OFFキャンペーンを実施
月初→月末	AOVが4,000円→4,300円へ緩やかに上昇	7/5に送料無料ラインを5,000円→4,000円へ引き下げた

この四つの選び方には意図がある。実務で「なぜ下がったのか」と聞かれる原因は、たいてい社内データの外にあるからだ。配送会社の障害は自社のどのシステムにも記録が残らない。インフルエンサーの投稿は、参照元を見に行かない限り存在自体に気づけない。競合のキャンペーンは、当然どこにも入っていない。四つ目の送料無料ラインだけは社内で既知だが、それでも売上・注文・セッションの集計値からは読み取れない。

ここで三つ目については、正直に書いておく必要がある。この動き方——セッションはほぼ変わらず、CVRだけが一週間かけて0.3ポイント下がる——を見たとき、最初に競合を疑うのは順序として不自然である。先に疑うのは自社側だ。在庫切れの商品が増えていないか。サイズ欠けが進んでいないか。特定のブラウザやアプリのバージョンで表示が崩れていないか。レビューに低評価が付いていないか。競合要因は、これらを一通り潰したあとに消去法で最後に残るものであって、最初に飛びつく仮説ではない。今回この原因を仕込んだのは、「社内データにまったく痕跡が残らない変化」の代表例として置いたからで、実務での疑う順番を再現したものではない。この点は検証設計の都合であり、現場の判断順序とは別物として読んでほしい。

いずれにせよ四つとも、渡したデータの中に答えが存在しない。この状態でAIが何を言うのかを見るのが、この検証の眼目である。当てられるはずのないものを当てるかどうかではなく、当てられないときにどう振る舞うか。実務で効いてくるのは、そちらだ。

渡し方をひとつ変えると、出力の質が変わった

同じCSVを、二通りの指示で渡した。

一つ目は、最初に思いつく形である。「この30日間の売上データを分析してください」とだけ書いて、六列のCSVを貼り付ける。返ってきたものは、谷（7/10〜12）と山（7/18）の存在自体は正しく捉えていた。そこまではいい。問題はその先で、「7/18の急増はSNS施策の効果とみられます」「AOVの上昇はまとめ買い促進策が奏功していると考えられます」と続いた。SNS施策の情報は渡していない。まとめ買い促進策も渡していない。仕込んだ正解と照らすと、7/18は外部インフルエンサーの投稿であってSNS「施策」ではないし、AOV上昇の原因は送料無料ラインの変更である。

ここで注意して見るべきは、外したこと自体ではない。外した文と、当たっている文が、同じ文体で並んでいることだ。「7/18が月間ピーク」（事実）と「SNS施策の効果とみられます」（根拠なし）が、地続きの断定調で書かれている。この出力をそのままコピーして会議資料に貼れば、社内には「7月のピークはSNSのおかげ」という誤った共通認識が残る。半年後に「去年SNSが効いたはずだ」という前提で予算が組まれるところまでが、ワンセットである。

二つ目の指示は、三つ足しただけだ。「対象期間は7/1〜7/31。指標は売上・注文数・セッション数・CVR・AOVを個別に見ること。数値から言える事実と、推測を分けて書くこと。推測には必ず『推測』と明記すること」。データは一文字も変えていない。

返ってきたのは、次のような形だった。

「7/10〜12はセッション数がほぼ変動していないのにCVRのみ急落している。集客ではなく、購入直前のプロセスに阻害要因があった可能性（推測）。配送状況・決済エラー・在庫表示の確認を推奨」
「7/18はセッション・注文とも急増しており、外部流入の増加が疑われる（推測）。参照元の確認を推奨」
「AOVの上昇は送料設定や同梱施策の変更の可能性（推測）。施策実施ログとの突合を推奨」

一つ目は、仕込んだ正解（配送障害）そのものではない。だが「集客の問題ではなく、購入直前の問題」という切り分けは正しく、調べるべき先の一番目に配送状況が挙がっている。二つ目も、インフルエンサーの存在は当てていないが、参照元を見に行けという指示は正しい。実務でこの指示に従えば、GA4の参照元／メディアを開いた時点で答えが出る。三つ目に至っては、送料設定という言葉が実際の原因と一致している。ただしこれは断定ではなく候補の一つとして出ており、突合を推奨で終わっている。

変わったのはAIの知識量ではない。出力の形だ。断定の位置に「推測」というラベルが入り、結論の位置に「確認を推奨」という次の行動が入った。同じモデルが、同じデータから、使える形と使えない形の両方を出す。差は指示の三行にある。

ただし、これは一回の試行の結果であって、再現性を確認したものではない。同種の傾向が別のデータでも出るかは、次回以降の検証課題として残っている。「この指示を入れれば良くなる」と読むのではなく、「試す価値のある仮説が一つ立った」と読むのが正確なところだ。

AIが強いのは「異常の検知」と「次に見る場所の指定」まで

二つ目の渡し方で出てきたものに、名前をつけておきたい。原因ではない。かといって単なる集計でもない。調査の絞り込みである。分析の成果物としては地味だが、実務でいちばん時間を食うのは、ここが決まらないことだ。

売上が落ちたとき、確認先の候補は毎回同じだけ並ぶ。広告の配信量は減っていないか。検索順位が落ちていないか。在庫切れの商品が出ていないか。決済で落ちていないか。配送の遅延は出ていないか。競合が何かやっていないか。全部を毎回見に行けば半日が消える。半日かけて空振りすれば、翌月からその確認はやらなくなる。

絞り込みが効くのは、売上が三つの掛け算で成り立っているからだ。売上＝セッション数×CVR×AOV。この三つのどれが動いたかで、見に行く先が変わる。

動いた指標	疑う領域	最初に開く画面
セッションだけ減った	集客。広告・検索・外部流入	GA4の参照元／メディア、広告管理画面の配信実績
CVRだけ落ちた	購入直前。在庫表示・決済・配送表示・価格改定	在庫連携の反映状況、決済エラーの記録、商品ページの表示
AOVだけ動いた	商品構成・送料設定・同梱・セット販売	販促カレンダー、送料無料ライン、カテゴリ別の構成比
セッションもCVRも動いた	複合。まず期間を分けて片方ずつ見る	日別に切り直して、動き始めた日を特定する

これは分析の基本であって、AIが発明したものではない。EC担当者なら知っている。それでも毎回この順で切れているかというと、そうでもない。月末の締めと繁忙期の出荷が重なった週に、五指標×三十日を漏れなく見比べるのは、知識ではなく体力の問題だからだ。AIがここで効いているのは、賢いからではなく、疲れないからである。

もう一つ、絞り込みには金額の話がある。7/10〜12の谷を「集客の問題」と誤読すると、広告費を積む判断になる。実際の原因が購入直前の離脱なら、積んだ広告費はそのまま同じ場所で漏れる。切り分けの一行が守っているのは、調査の時間だけではない。誤った打ち手に投じる予算のほうだ。

原理的に届かない領域——データの外側にある原因

「AIには因果が分からない」という言い方は、雑すぎて実務の役に立たない。分からなさには三つの種類があり、対処がそれぞれ違う。

一つ目は、そのデータが手元にない場合。配送会社のシステム障害は、自社のOMSにもWMSにもモールの管理画面にも記録が残らない。AIどころか、その場にいた人間にも数字からは特定できない。ここは「AIの限界」ではなく、単にデータが無い。AIを別のツールに替えても、プロンプトを磨いても解決しない。

二つ目は、データはあるが渡していない場合。実はこちらのほうが件数としては多い。販促カレンダー、クーポンの発行期間と原価、ポイント倍率、在庫切れが発生した日と商品、広告の日別消化額、価格改定の履歴。どれも社内のどこかに存在している。存在しているのに、渡すCSVには入っていない。この状態でAIに「原因を教えて」と聞くのは、施策の記録を隠したまま担当者に原因究明をさせているのと同じである。二つ目は、渡せば解ける。

三つ目は、渡したうえで、それでも因果を確定できない場合。7/5の送料無料ライン変更とAOVの上昇は、時期が一致している。施策ログを渡せばAIも人も「時期が重なっている」とは言える。だが7月は夏物のセール期でもあり、単価構成そのものが動く月だ。送料変更が無くてもAOVは上がったかもしれない。これを切り分けるには、変更していない対照が要る。対照が取れていない以上、この検証から言えるのは「同時期に動いた」までで、送料変更がAOVを押し上げたとは書けない。資料を作るときにチェックすべき観点として、ここに置いておく。

実務での落としどころは、因果を書かないことではない。因果を主張せずに、判断材料を並べる書き方にすることだ。たとえばこう書く。「7/5に送料無料ラインを5,000円から4,000円へ変更。同日以降、AOVは4,000円台前半から4,300円前後で推移している。同期間に単価へ影響する他の変更は確認されていない」。読んだ側は自分で因果を推定できるし、後から別の要因が出てきても、この文は間違いにならない。「送料変更によってAOVが上がった」と書いた瞬間に、それは検証していない主張になる。

一つ目に見える限界のうち、いくつかは取りに行けば二つ目に変わる。参照元のレポートを毎月保存しておけばインフルエンサー投稿は次から見える。配送会社の遅延情報ページを月末に控えておけば障害は記録に残る。競合のセールは、自分でメルマガを購読して日付をカレンダーに書き込めば済む。限界の位置は固定ではなく、記録の習慣で動く。

前処理：どの画面から、何を、どの形で落とすか

渡し方の話は、プロンプトより手前から始まっている。どの画面から落とした数字なのかで、同じ「売上」という列の意味が変わるからだ。

取得元はチャネルごとに決まっている。楽天ならRMSのデータ分析メニュー配下（店舗カルテ・売上分析など。メニュー名と階層は改定されるため、2026年8月時点の自店の画面で要確認）、Shopifyなら管理画面のストア分析（英語UIではAnalytics／Reports）、行動指標はGA4の探索。Amazonについては、セラーセントラルのレポート系メニューのどこに日別の売上とセッションが出るかを、アカウント種別と現在のメニュー構成に照らして自分で確認するところから始めたい。ここは名称を断定せず、チェックすべき観点として置く。複数チャネルを持っているなら、OMSの受注一覧から落とすこともある。問題は、これらの「売上」が同じ定義ではないことだ。

税込か税抜か。モールの管理画面と会計側で揃っていないことがある。
受注ベースか出荷ベースか。月末に受注して翌月に出荷した分が、どちらの月に立つか。
キャンセル・返品を含むか。含んだまま渡すと、返品の多かった日が「売れた日」として集計される。
送料・ポイント原価・クーポン原価が引かれているか。ポイント倍率を上げた日は、売上が伸びても粗利が伸びていないことがある。
注文数は注文単位かSKU単位か。ここがずれると、AOVの計算そのものが変わる。

誤解のないように順序を書いておく。この揃える作業そのものは、AIに指示を書いて済ませられる類のものではない。チャネルをまたいで比較するなら、税抜へ寄せる計算列を足し、受注日と出荷日のどちらかに基準を決めて並べ直し、キャンセル行を落とし、注文単位へ丸め直す。この手作業は残る。分析の前処理で最も時間を食うのはここで、実感としても軽くならない。

そのうえで、整え終わったデータに定義を三行添える。「売上＝税抜・受注日ベース・キャンセル分を除外済み。注文数＝注文単位。セッション＝GA4のセッション、同期間」。この三行の役目は、揃える作業の代わりをすることではない。AIが列名から前提を勝手に推測するのを止めることだけである。書かなければAIは「売上」という日本語から税込の確定売上だと仮定するかもしれず、そのうえで出てきた数字は検算しても合っているように見える。前提だけが違う、というのがいちばん見つけにくい。三行はそのための保険であって、クレンジングの省略ではない。

もう一つ、集計前の生データを扱うときの注意がある。受注一覧をそのまま落とすと、注文者の氏名・住所・電話番号・メールアドレスが列に含まれる。日別集計に必要な列ではないので、貼る前に落とすのが実務上の基本になる。外部サービスへ業務データを渡すときの社内ルールや、利用しているサービスの規約・データの取り扱い方針は、事業者ごと・サービスごとに違うため、ここで一律の結論は書けない。自社で誰が何を決めているのかを先に確認したほうがいい。具体的な落とし方はネットショップの受注処理をAIで効率化する：氏名と住所を渡さずに速くする手順に書いた。

AIの出力を社内提案に変えるとき、人が埋める三つの穴

ここまでで手元にあるのは、事実と推測が分かれた分析メモである。これは資料ではない。会議に出す形にするまでに、人にしか埋められない穴が三つある。

穴1：自社施策との突合。販促カレンダーを開いて、異常が出た日に自社が何をしていたかを重ねる。7/18に何もしていないなら、それは外部要因だと分かる。逆に、その日にクーポンを配っていたなら話は変わる。この照合は五分で終わるが、AIには絶対にできない。カレンダーがAIの手元に無いからだ。

穴2：外部要因の目視確認。7/24〜31のCVR低下のように、社内データが何も語らない期間がある。ここで見に行くのは、自社の在庫状況とレビュー、そのうえで競合の販売ページ、モールのイベント日程、天候、ニュース。楽天ならお買い物マラソンやスーパーSALEの開催期間で、CVRもAOVも構造的に動く。イベント期をまたいだ比較を「前月比」で出すと、施策の評価が丸ごと歪む。この暦を持っているのは担当者だけである。

穴3：打ち手の決定。AIの出力に「配送状況の確認を推奨」とあっても、実際に配送会社へ問い合わせるかどうか、広告を止めるかどうか、価格を戻すかどうかは人が決める。決めた結果に責任が発生するからだ。ここを渡してしまうと、後から「AIがそう言ったので」としか説明できない資料になる。それは提案ではない。

書き換えの例を一つ出しておく。渡し方Aの出力にあった「7/18の急増はSNS施策の効果とみられます」は、そのままでは使えない。三つの穴を埋めると、こうなる。

「7/18はセッションが平常日の約1.8倍、売上は平常日の約1.4倍。GA4の参照元では外部SNSからの流入が最多。同日の自社施策の実施記録はなし（販促カレンダー確認済み）。外部からの言及が発生した可能性があり、該当投稿の特定を進める」

ここでセッションの伸び（約1.8倍）と売上の伸び（約1.4倍）が一致していない点は、そのまま書いておく価値がある。流入は増えたがCVRは下がった、という読みが立つからだ。倍率を二つ並べて食い違いが出たら、恒等式（売上＝セッション×CVR×AOV）に戻して検算する。AIの集計を検算せよと言う以上、自分が書いた倍率も同じ扱いにする。

長くなったが、この形なら誰も間違えない。事実の部分は検算でき、推測の部分は推測だと分かり、次の行動が書いてある。分析メモから提案書へ変換する型そのものについては、数字で語る：分析から社内提案までの型に別途まとめてある。AIが出すのは材料までで、提案の構造は人が組む。

「分析ができる人」の価値は、どこに残るのか

この検証で分かったことを、担当者の側から言い直しておく。AIが持っていったのは見落としの防止と、読み方の言語化である。三十日×五指標を漏れなく見比べる作業、異常を言葉にする作業、次に見る場所を並べる作業。ここは正直、人がやるより速い。もう戻らないと思っていい。

持っていかなかったものが三つある。どれも、社内にいないと手に入らない。

データを取りに行ける。RMSのどのメニューに何があるか、GA4の探索で何と何を掛け合わせるか、OMSから落とせる列は何か。画面と権限を知っている人しか、そもそも材料を用意できない。
定義を保証できる。この「売上」が税込か税抜か、キャンセルを含むか、ポイント原価が引かれているか。定義を間違えたデータからは、どんなに優秀なAIでも間違った結論しか出ない。数字の正しさを最後に担保するのは人のままである。
外部要因の暦を持っている。モールのイベント、競合の動き、去年の同時期に何があったか。この記憶は社内データにも公開情報にも存在しない。

逆に言えば、この三つを持たずに「分析ができます」と言うのは、これから難しくなる。ピボットを組めることや増減率を出せることは、価値の中心ではなくなった。中心にあるのはデータの意味を保証できることのほうへ移っている。数字を作る人から、数字の前提を担保する人へ。

分析ができるということは、実は市場価値の話にも直結している。EC実務者が今どのスキルに時間を投じるべきかについては、別に一本まとめてある。EC担当者がAI時代に学ぶべきスキルは、業務を3つに分けると決まるを参照してほしい。

よくある質問

無料で使えるAIでも、売上分析はできますか

今回の検証で差が出たのは、モデルの種類ではなく指示の書き方だった。ただし無料版と有料版では、扱えるファイルの形式、一度に渡せるデータ量、計算処理の実行可否などに差が設けられていることがあり、その内容はサービスごとに異なるうえ改定も入る。「無料でも十分」とも「有料でなければ無理」とも言い切れないので、使おうとしているサービスの現在の提供条件を、公式の料金ページで確認するのが確実な進め方になる。まず試すなら、日別三十行の集計データを、定義三行を添えて渡すところからで足りる。

Excelのピボットで済む話と、何が違うのですか

集計そのものはピボットでやる。数値の正確さは表計算のほうが上で、AIは計算を取りこぼすことがあるからだ。違いが出るのは、集計を確定させた後である。「セッションは横ばいなのにCVRだけ落ちている」という関係の指摘と、「だから購入直前を疑え」という言語化は、ピボットが自動ではやってくれない。役割を分けるのが現実的な形になる。数字はシートで確定させ、その確定した数字を渡して、読み方の候補を出させる。

AIの分析結果は、どのくらい信用していいのですか

信用の単位を「結果全体」ではなく「一文ごと」に落とすのが実務的な答えになる。渡したデータの中に根拠がある文は、検算すれば足りる。根拠がない文は、内容の当否にかかわらず調査項目にしかならない。今回の検証でも、正解に近い推測と、まったくの創作が、同じ文体で並んで出てきた。文体では見分けられない。見分けられるのは、根拠が手元のデータにあるかどうかだけである。