赤兎馬EC運用支援
AIに時事の文章を書かせると、読みやすいのに確かめようのない一文が混ざります。
2026年10月4日〜26日の3週間で、私たちは自社で運営しているAI活用コミュニティ向けに、AIニュースをAIに書かせて配る仕組みを作りました。この記事では次の3つをまとめます。
- 「何が話題か」と「何が事実か」を別の経路に分けた設計
- 試験運用で実際に起きた失敗と、そのあと足した規則
- 商品ページ・SNS・メルマガでAIに文章を書かせるときにも使えるチェックリスト
作ったもの：話題と事実を別の経路にした5段の流れ
既存のサーバに、Pythonと軽量なデータベースで組みました。流れは次の5段です。
- 監視：主要AI企業の公式7ソース（公式ブログ・リリースノート・ヘルプ）を15分間隔で読み取り専用で監視し、見出し・日時・原文URLを候補として保存する
- 根拠カード：取得した記事本文から、本文と完全一致する引用が付いた事実だけをAIがカードにする
- 原稿：週次原稿と速報原稿は、根拠カードだけを材料にAIが書く
- 承認：確認用のチャットルームへ依頼を出し、人が承認の返信をしたものだけをコミュニティへ配信する
- 安全装置：生成回数の上限・停止・復元・バックアップを用意し、外部への送信は最初はOFFにしておく
設計の核は、話題と事実の経路を分けたことです。話題はXの反応で選び、事実は公式の一次情報の本文からしか取りません。自動テストは10月26日の時点で190件になりました。
10月9日の試験：64候補のうち、本文が取れたのは35件
実際の記事64候補で試験した結果です。
- 本文が取れた：35件
- 公式RSSの説明文しか取れなかった：20件
- 取得を拒否された（403）ため保留：9件
半分近くは本文まで届きません。ここで最初の落とし穴が見つかりました。10月13日の週次原稿の試作（配信はせず、改善候補として扱いました）で、RSSの短い説明文に頼った記事について、公式の本文には書かれていた提供条件（有料プランから始めて、翌日に無料へ広げる）を、AIが「書かれていない」と書いていたのです。
短い説明文しか見ていないAIは、そこに無い情報を「存在しない」と言い切ってしまいます。同じ試作では、ほかにも次の問題が出ました。
- 対象が限られる話題を、誰でも使えるように書いていた
- X検索（直近24時間・10件）は宣伝や雑談が混じり、その週の盛り上がりを表していなかった
ここから決めた判断基準は「本文が取れない記事は、RSSの説明文で断定させない」です。「確認できない」と「書かれていない」は別物として扱います。
AIは具体例を「それっぽく」補う
10月17〜18日は、外に出さない形で24時間の速報試験をしました。速報の対象は新着記事に絞り、AIを呼び出す回数にも上限を付けました。
このとき週次原稿で目立ったのが、具体例の補完です。公式発表には「40以上のアプリと連携」としか書かれていないのに、原稿には「在庫状況を確認」「決まった形式で画像を書き出す」といった個別の操作例が入っていました。どれも根拠では確認できません。読み手には便利そうに見える分、むしろ危ない一文です。
そこで「根拠カードに無い操作例は書かない」規則と、採用・不採用の判定が食い違っていないかを見る矛盾チェックを足しました。続けて次の改善もしています。
- 10月23日：速報は軽量なモデルで1回要約するだけにし、1日あたりの上限を設定できるようにした
- 10月25日：速報の根拠は原文のブロック単位で選ばせ、引用が原文と食い違わないようにした。失敗した理由を記録し、1記事だけ手動でやり直せるようにした
引用は「それらしい要約」ではなく「本文と一致する箇所」を原文の単位で指定させる。引用の食い違いを止めるうえでは、これがいちばん効いた対策でした。
話題はXで選ぶ。ただし事実には格上げしない
10月18日の実データでは、Xの69投稿から23の話題がまとまりました。そのうち、複数の独立した発信者が確認できた話題はわずかでした。原稿の本文に入った1話題も、観測できた投稿は1件だけで、しかも米国限定の内容でした。
10月21日に、Xの収集は検索に特化した別のAIに任せ、話題選びは原稿を書くAIが「話題性」（反応の大きさ・独立した発信者への広がり・増え方・議論の中身）を第一の基準にして行う形に変えました。あわせて、観測時刻の推定値は捨てました。検索期間の終わりの時刻を入れていただけだったからです。増え方の速さは「不明」と扱います。
10月26日には、選んだ話題がすべて使用感・噂・意見で、公式記事の根拠カードが0件という回がありました。これまでは、ここで処理が止まっていました。そこで「X紹介カード」を用意しました。
- 投稿URL・投稿者・主張の要約・まだ確認できていない点を記録する
- 事実には格上げしない
- そのまま引用したり、性能を言い切ったりする材料には使わない
これで「X上の投稿」と出どころを明示した下書きを作れるようになりました。通常配信で公式の根拠を求める条件は、変えていません。
もう一つ決めたのは、公式記事が無い話題を「情報を取りやすい別の話題」に自動で差し替えないことです。出どころを明示して紹介するか、調査待ちのリストに残すか。そこは人が決めます。
承認フローの入口は、実際の返信で試すまで分からない
10月21日に見つかった不具合です。承認の返信の先頭にある宛名の行を認識できず、承認が記録されていませんでした。実際の返信の形式は、本番と同じ形で試すまで分からないものでした。同じ日に、承認者が複数いる場合にも対応させました。
この仕組みで人が持ち続けている作業は次のとおりです。
- 配信してよいかの承認
- 公式記事が無い話題をどう扱うかの判断
- 調査待ちリストの消化
- その話題が対象の読者に合っているかの判断
EC実務への着地：商品ページ・SNS・メルマガも同じ構造
AIに商品ページやメルマガを書かせるときも、構造は同じです。成分・仕様・対応範囲・比較といった事実は、メーカー資料や公式の仕様書の本文と一致する引用から書かせます。口コミや使用感は「お客様の声」「SNS上の投稿」と出どころを示して分けます。
この2つが混ざると、使用感が事実のように読める文章になり、表示の面でも問題になりかねません。資料に無い「〜にも使えます」をAIが足すのは、AIニュースで操作例を補ったのと同じ現象です。公開後に表示を直したり差し戻したりすると、手戻りの時間がかかり、ページを止めている間の売上も落ちます。最初から経路を分けておくほうが安く済みます。
AIに書かせた文章を公開する前に見る6項目です。
- 事実の出典は本文まで取れたか（説明文や要約だけで言い切っていないか）
- 根拠に無い具体例（使い方・対応範囲・数字）をAIが補っていないか
- 引用は原文と一致しているか（原文の段落単位で指定させたか）
- 口コミ・SNSの声は出どころを明示し、事実と分けたか
- 人の承認を通ってから公開される流れか
- 承認の返信の形式を、実際の返信で試したか
まとめ
AIに時事や商品の文章を書かせるなら、「何が話題か」と「何が事実か」を別の経路にします。話題は反応で選び、事実は一次情報の本文と一致する引用だけから書かせる。公式の情報が無い話題は、出どころを明示して事実に格上げしない。最後の承認は人が持つ。3週間の試行錯誤で残ったのは、この4つでした。
店舗 URL での無料 EC 診断もやっています：https://ec-sekitoba.jp/#contact
AI の導入・内製化のご相談も同じ窓口で受けています。