取材記事を作るとき、材料は1か所にまとまっていません。現地で取ったメモ、録音の文字起こし、撮影した写真、配布資料、公式サイト、あとから届いた案内。それぞれに少しずつ違う情報が入っています。

AIへまとめて渡して「記事にしてください」と頼めば、読みやすい文章はすぐできます。しかし、どの情報を何から確認したのかが見えないまま文章だけが完成すると、数字や日時が食い違ったときに確認できません。

そこで私は、記事本文を書く前に「主張と根拠の表」を作ります。記事で伝えたい事実を1つずつ分け、元になった資料、確認状態、食い違い、掲載可否を並べる表です。

この記事では、AIに取材材料を整理してもらいながら、複数の情報源を混ぜずに記事へ進む方法を紹介します。

先に記事を書かない

取材直後は情報が多く、早く記事へまとめたくなります。ただし、最初から文章にすると、1つの段落に複数の事実が入ります。

新施設は10月に開業し、約50店舗が入り、地域交流の拠点として期待されています。

この一文には、少なくとも3つの主張があります。

開業時期は10月
店舗数は約50
地域交流の拠点として期待されている

開業時期は公式資料、店舗数は会場での説明、「期待されている」は主催者の発言かもしれません。文章だけを見ると、すべてが同じ根拠で確認されたように見えます。

まず文章を主張の単位へ分解し、それぞれの根拠を確認します。

「主張と根拠の表」を作る

最初は次のような表で十分です。

ID	記事で使いたい主張	根拠	確認状態	記事での扱い
F-01	開業日は10月20日	公式発表資料 2ページ	確認済み	事実として記載
F-02	出店数は50店舗	会場説明では50、資料では48	食い違いあり	保留
F-03	地域交流を目的とする	担当者発言 00:12:41	音声確認済み	発言として紹介
F-04	多くの来場者でにぎわった	写真と現地メモ	数値なし	見た範囲に限定

この表があると、AIは「書けること」と「まだ書けないこと」を分けやすくなります。人間も、どこを確認すれば公開できるか判断できます。

表の目的は、すべてを証明することではありません。確認できた範囲と、まだ確認できていない範囲を見えるようにすることです。

情報源の種類を分ける

情報源は、全部を同じ重さで扱いません。

公式発表

主催者や運営者が公開したページ、プレスリリース、当日配布資料などです。正式名称、日付、場所、料金、申込方法の確認に使います。

ただし、古い資料が残っている場合があります。資料名だけでなく、公開日や更新日も確認します。

取材音声

担当者の説明やインタビューです。発言の趣旨、背景、考えを伝える材料になります。

AI文字起こしだけで引用を確定せず、タイムスタンプから元音声へ戻ります。

現地メモ

自分がその場で確認したことです。入口の場所、展示の様子、案内表示など、現場で見た範囲を記録します。

「自分が見たこと」と「イベント全体で起きたこと」は同じではありません。

写真

写っている物、配置、表示などを確認できます。一方、写真の外で起きていたこと、人物の氏名、会場全体の評価までは確定できません。

AIの要約

複数の材料から話題を整理するのに便利です。しかし、AIの要約は新しい情報源ではありません。要約の根拠になった元資料へ戻れる形で使います。

主張ごとに出典を1つ以上付ける

AIへ材料を整理してもらうときは、文章ではなく主張の一覧を作らせます。

主張ID：F-05
主張：イベントは3日間開催される
出典：公式案内ページ
該当箇所：開催概要
確認日：2026-10-17
状態：確認済み
注意：最終日の終了時刻は別記載

出典が見つからない主張は、空欄を自然な推測で埋めません。

主張ID：F-06
主張：昨年より来場者が増えた
出典：見つからない
状態：未確認
記事での扱い：使用しない

写真に人が多く写っていても、昨年との比較はできません。担当者が「増えた印象です」と話していても、統計上増えたと断定するには別の確認が必要です。

情報が食い違ったらAIに決めさせない

取材では、公式ページ、配布資料、口頭説明の数字が違うことがあります。

公式ページ：参加店舗は48店
配布資料：参加店舗は50店
担当者発言：当日追加があり、全部で51店

このとき、AIへ「正しい数字を選んで」と頼むのは危険です。最新に見える数字が正式とは限らず、数え方が違う可能性もあります。

AIには、違いを消さずに比較表を作ってもらいます。

情報	値	日付	補足
公式ページ	48店	10月1日公開	事前発表
配布資料	50店	10月15日配布	当日資料
担当者発言	51店	10月15日録音	追加出店を含むとの説明

そのうえで、主催者へ確認する、記事に「当日発表では51店」と範囲を付ける、数字自体を掲載しない、という判断を人間が行います。

日付には「何の日付か」を付ける

日付の間違いは、数字そのものより意味の取り違えから起きます。

発表日
取材日
開業日
申込開始日
申込締切日
イベント開催日
記事公開日

「10月17日」だけでは、何の日付か分かりません。主張表では項目名まで残します。

日付：2026-10-20
意味：一般向け開業日
出典：公式発表資料
確認日：2026-10-17

AIへ記事を書かせる場合も、日付と意味をセットで渡します。

引用、要約、現地描写を区別する

記事には、異なる種類の文章が入ります。

直接引用：担当者が実際に話した言葉を、音声で確認して掲載する
要約：発言や資料の内容を、意味を変えない範囲で短く伝える
現地描写：記者がその場で見た範囲を書く
公式情報：公開資料に記載された内容を書く

AIが作った自然な一文を、本人の直接引用としてかぎ括弧に入れないようにします。現地で感じた印象を、公式の評価として書かないことも大切です。

主張表に文章の種類を追加すると区別しやすくなります。

主張ID	種類	公開時の書き方
F-07	直接引用	音声と照合後、かぎ括弧で掲載
F-08	要約	「担当者によると」と範囲を示す
F-09	現地描写	「取材時には」と見た範囲を書く
F-10	公式情報	資料の更新日を確認して記載

Obsidianを確認の原本にする

主張と根拠の表は、ObsidianのMarkdownへ保存します。専用サービスに閉じた形式ではないため、ChatGPT、Claude、Cursorなど、ローカルファイルを読めるAIへ同じ表を渡せます。

# 取材記事・主張確認表

- 取材日：2026-10-16
- 最終確認日：2026-10-17
- 確認済み：12件
- 保留：3件
- 使用しない：2件
- 公開判断：人間の承認待ち

別のAIに構成案を頼むときも、「確認済みだけを使い、保留は本文へ入れない」と指定できます。

AIには、新しい表の作成、重複する主張の統合、出典のない文の抽出を任せます。確認済みへの変更や、食い違う情報の採用は人間が行います。

記事を書き始める条件を決める

主張表を作ったあと、次の条件を確認します。

記事の中心となる主張に出典がある
日時、場所、料金、人数、固有名詞を確認した
直接引用を元音声と照合した
食い違いのある情報を保留または解決した
未公開情報や個人情報を除外した
写真と音声の公開可否を確認した
AIの要約だけを根拠にした文章がない

中心となる事実が確認できなければ、文章を完成させる前に止めます。公開を遅らせる、該当箇所を削る、確認できた範囲だけの短い記事にするという選択もできます。

実際に使う依頼文

複数の取材材料を整理するときは、次のように依頼します。

指定した取材メモ、文字起こし、写真台帳、配布資料から、
記事で使えそうな主張と根拠の表を作ってください。

各行に次を記載してください。
- 主張ID
- 記事で使いたい主張
- 情報の種類（公式情報、直接引用、要約、現地描写）
- 出典名
- 該当箇所またはタイムスタンプ
- 出典の日付
- 確認状態
- 他の情報源との食い違い
- 公開前に人間が確認する点
- 記事での扱い（使用、保留、使用しない）

ルール：
- 出典のない主張を補わない
- AIの要約を新しい出典にしない
- 食い違う数字や日付を勝手に統合しない
- 人物名、固有名詞、引用文を推測で確定しない
- 予定、希望、検討を決定事項へ変えない
- 未確認を確認済みに変更しない

最後に、記事に使える確認済みの主張と、
人間の確認が終わるまで使えない主張を分けてください。

この出力をそのまま記事にはしません。人間が元資料と照合し、状態を更新してから、確認済みの行だけを構成案へ渡します。

まとめ

AIは、取材メモ、音声、写真、配布資料から情報を抜き出し、比較する作業に向いています。しかし、複数の情報源を自然な文章へまとめるだけでは、どの事実が何を根拠にしているのか見えなくなります。

記事を書く前に文章を主張の単位へ分ける
主張ごとに出典、該当箇所、確認状態を付ける
公式情報、取材音声、現地メモ、写真、AI要約を分ける
食い違いをAIに解消させず、比較したまま残す
日付には開業日や取材日などの意味を付ける
直接引用、要約、現地描写を区別する
ObsidianのMarkdownを複数AIが読める確認原本にする
確認済みの主張だけを記事構成へ渡す

AIには「材料のどこが一致し、どこが食い違うか」を整理してもらい、「記事でどの事実を採用するか」は人間が決める。主張と根拠の表を1枚挟むだけで、取材材料が増えても確認の経路を失わずに記事を作れます。

この記事は、取材メモ、写真、音声を別々に整理し、確認済みの情報だけを複数AIが読めるObsidianのMarkdownへ残してきた本プロジェクトの運用をもとに構成しました。