AIが書く記事の「根拠の一覧」を、公開前に人が確認できる形で残す考え方

AIに記事を書かせる時、「何を根拠にしたか」を人が公開前に確認できる形で残しておくと、材料の混入に気づけます。J-WORKSの実際の記録から整理します。

この記事で分かること

AIに文章を書かせる時、本文だけを見て「問題なし」と判断すると、材料の側の問題を見落とすことがあります。J-WORKSでは、毎日の運営記録をnote記事にする自動生成で、材料にする「事実の一覧」を残し、公開前に運営者が根拠を確認できるようにしています。この一覧を調べたことで、材料への混入が見つかりました。その経過と、そこから整理した考え方を紹介します。

J-WORKSの記事づくりの流れ

noteの運営記録(DAY記事)は、次の順で作っています。まず、社内のさまざまな記録(作業指示の実行ログ、市場調査、SNSの投稿状況、商品の状態など)を集めて、「今日あった出来事の事実一覧」を機械で作ります。次に、その一覧を材料としてAIが記事を書きます。一覧は記事の材料であると同時に、公開前に運営者が根拠を確認できる記録としても残してあります。編集方針でも、公開する内容は、実際に確認できた事実のみを基本としています(編集方針・AI利用方針)。

一覧を調べたら、材料に混入があった

この一覧の作り方を見直したところ、一覧に、記事を書くためにAIへ送った指示の記録が混ざっていました。修正前に公開された最初の4本の記事の、実際に保存されていた事実一覧を調べると、混入の割合は約26%(135件中35件)、約46%(133件中61件)、約34%(256件中86件)、約27%(215件中58件)でした。原因は、一覧を作る処理が、複数の社内記録を時間帯だけで集める作りで、「その日実際にあった業務」と「記事を書くための指示」を区別できなかったことです。

読者への影響と、気づけた理由

公開された4本の本文を直接確認した範囲では、指示文が読者向けの本文に表示された事実はありませんでした。本文への混入は、一覧の作成とは別の校正のチェックで防がれていました。一方で、材料の側の問題は、校正のチェックだけでは見えません。一覧が人の確認できる形で残っていたから、割合を数えることができました。

どう直したか

記事を作る仕組みの登録・保存の操作には決まった名前があり、AIへの指示は必ず「(その名前)で保存してください」の形になります。その名前の一覧を元の定義から自動で取得し、いずれかを含む指示の記録だけを、事実一覧から外すようにしました。2026年9月2日に修正し、9月25日に自動テスト20件がすべて合格しています。修正後に完全に生成された記事3本の一覧(32件・50件・62件)には、この種の指示の記録が0件でした。経過の全体はAIが自分への指示文を記事の「事実」として集めていた不具合にあります。

残っている課題

この対応は、言い回しが一致するかどうかで判定する、対象を絞った方法です。たまたま同じ言い回しを含む別の指示があれば、区別されずに外される可能性があります。記録の目的そのものを区別できる仕組みへの作り直しは、まだ行っていません。修正前に保存されていた4本の一覧も、さかのぼって直していません。

自分の仕組みに当てはめる時のチェックポイント(編集部の考察)

ここは編集部の考察です。同じ問題が他の仕組みにもあると確認したわけではありません。

根拠

2026年9月2日に実装した修正と、9月25日に再実行した自動テスト20件(全件合格)、および同日に社内データベースのnote記事の記録(事実一覧・本文)を直接確認した結果による、J-WORKS内部の実施記録です。