AIの引用は要約になる｜逐語かどうかを確かめる手順

「AIがまとめてくれた引用を、そのまま資料に貼っていいのか」「引用符が付いているから、原文を見なくても大丈夫だろう」——AIに調べさせた結果を人に渡すとき、ここで一度手が止まる方は多いはずです。

結論から言うと、引用符に入れてよいのは「コピーして貼った文字列」だけです。打ち直した時点、短くした時点で、それは引用ではなく要約になります。そして要約を引用符に入れると、受け取った側はそれを検証済みの事実として扱い、そのまま次の人へ運びます。

株式会社Fyveは、AIを日々の業務に組み込む設計を専門にしています。この記事では、私が実際に「原文から1行引いたつもり」で原文に存在しない文を引用符に入れ、それを別の工程が訂正し、その訂正のほうにも誤りが混ざっていたという3段の出来事を材料に、引用の線引きと確認手順を整理します。

結論｜引用符は「精度」ではなく「約束」の記号

最初に、この記事で言いたいことを3行にまとめます。

• 引用符は「この文字列を原文で目で確認した」という約束であって、内容が正しいという宣言ではない。だから要約を入れてはいけない
• 打ち直した・短くした・語尾を整えた時点で引用ではなくなる。読みやすくしたければ引用符を外し、「要約すると」と書く
• 訂正を受け取ったら、訂正のほうも同じ粒度で確認する。訂正は正しさの保証ではない

この3つは、AIを使っているかどうかに関係なく成立する話です。ただしAIを挟むと、要約が引用符付きで、しかも自然な日本語で返ってくるため、目視ではほぼ見分けられなくなります。ここが今回の本題です。

「引用」と「要約」は、どちらが正しいかの話ではない

要約が悪いわけではありません。長い原文を短くして伝えるのは、ほとんどの業務で必要な作業です。問題は、要約を引用の見た目で渡すことだけです。

この2つは役割が違います。整理すると次のようになります。

いちばん下の行が、この記事で伝えたい核です。要約の誤りは「解釈が違う」という形で表面化して議論になりますが、引用の誤りは誰も検証しないので、そのまま最終成果物まで運ばれます。

判断は3つに割ると迷わない

実務では、次の3つのどれかに毎回振り分けるだけで足ります。

• 逐語：原文の文字列をそのまま。引用符に入れてよい
• 部分引用：原文の一部を抜いて、省いた箇所を明示する。引用符に入れてよい
• 要約：自分の言葉。引用符に入れない。「要約すると」と前置きする

迷ったときの見分け方は単純です。その文字列を、原文の検索窓に貼って一致するか。一致しなければ引用ではありません。

実際に起きたこと｜「逐語」のつもりが、原文に無い文だった

私は毎朝、AIに材料を集めさせて記事のネタを仕込む工程と、それを受け取って実際に記事を書く工程を、別々に動かしています。工程を分けているのは、書く側が材料を都合よく解釈しないようにするためです。

この分業自体はうまく機能していました。今回問題が起きたのは、その受け渡しの中身です。

1段目｜原文から1行引いて、引用符で括った

ある道具の変更履歴に、動作の変更点が1行で書かれていました。仕込む側の工程は、その1行を材料メモに載せました。引用符で括って、逐語のつもりでです。

短く、読みやすく、要点だけが入った1文でした。受け取る側から見て、疑う理由はどこにもありません。引用符が付いているのだから、誰かがもう原文を見たということになります。

2段目｜翌日、書く工程が原文を取り直して照合した

翌日、実際に記事を書く工程が、その1行を記事に載せる前に原文を取り直しました。ここでその文字列が原文のどこにも存在しないことが分かります。

原文にあったのは、もっと長い1文でした。括弧つきで「どういう場合にそれが起きるか」の例が3つ並び、さらに「ある設定を無効にしているとき」という限定条件が付いていました。仕込む側は、それを短く言い換えて引用符に入れていたのです。

悪意はありません。読みやすくしただけです。ただ、読みやすくした結果として括弧の中身と限定条件が消え、全員に起きる話として読める文になっていました。

3段目｜その訂正のうち1件が、今度は間違っていた

書く工程は、3点を訂正として書き残しました。そして翌朝、私はその3点を自分で原文に当て直しました。結果はこうです。

2件目が今回の山場です。「初出はもっと前だ」という指摘の向きは正しかったのですが、具体的にどの版かという部分が1つずれていました。原文の版ごとの区切りを行番号で切って、該当行がどの区切りに入るかを機械的に数えたところ、指摘された版にはその話が一言も出てきませんでした。

そして厄介なのは、その誤った版番号が「訂正済みの確定事項」として次の作業の前提条件に据えられていたことです。訂正は疑われません。訂正だからです。

止まったのは3段目、つまり原文を自分で開いた工程だけでした。1段目も2段目も、それぞれ真面目に仕事をしています。それでも、原文を開くまで誤りは進み続けました。

なぜ気づけないのか｜要約は「読みやすくなる方向」に間違える

ここが記事の芯です。要約の誤りが見逃されるのは、注意力の問題ではなく構造の問題です。

理由1｜要約は原文より読みやすいので、劣化に見えない

普通の間違いは、読んだときに引っかかります。数字が合わない、話がつながらない、日本語がおかしい。何らかの摩擦が起きるので気づけます。

ところが要約は逆方向に動きます。原文より短く、明快で、読みやすくなっています。品質が上がったように見えるので、疑う気持ちが起きません。「よく整理されているな」で通過します。

理由2｜引用符が付いていると、受け手は検証をやめる

引用符には、受け手の動作を止める効果があります。「これは誰かが原文で確認した文字列だ」という合図なので、そこで確認の連鎖が終わります。

つまり引用符は、検証の必要をなくすために付ける記号です。だからこそ、中身が要約だったときに誰も止まれません。付ける側が思っているより、この記号は強く効きます。

理由3｜AIは「引用して」を「引いて伝えて」と解釈できる

ここは私の観測にもとづく話として書きます。AIに「原文から引用して」と頼むと、返ってくるものが逐語である場合と、趣旨を保った短い文である場合の両方があります。どちらも指示に沿った出力として説明がつくため、AI側が間違えているとも言い切れません。

そして返ってきた文は、たいてい引用符が付いています。頼んだのが引用だからです。ここで「指示は引用、出力は要約、見た目は引用」という組み合わせが完成します。

だから対策は「もっと賢いAIを使う」ではありません。頼み方と、受け取ったあとの確認手順を変えるほうが確実です。

いちばん先に落ちるのは「条件」

要約で何が落ちるかには、はっきりした偏りがあります。数字や固有名詞は残りやすく、条件が落ちます。今回もそうでした。

限定条件は、文の後ろか括弧の中にいる

「ある設定を無効にしているとき」「一部の環境で」「初回のみ」——この種の限定は、文の末尾か括弧の中に置かれることが多いです。そして短くするとき、人もAIも後ろから削ります。主語と述語は残し、修飾を落とすのが自然な圧縮だからです。

結果として、条件だけが消えた文が残ります。文法的には正しく、意味も通り、ただ適用範囲だけが黙って広がっています。

条件が落ちると、範囲が広がる方向にだけ間違える

条件の脱落が怖いのは、間違いが常に同じ方向に出ることです。「一部で起きる」が「起きる」になり、「特定の設定のとき」が「いつでも」になります。過大な方向にだけずれます。

これを人に渡すと、受け手は不要な対応を検討し始めます。自分たちには起きない事象のために時間を使う、というかたちで損が出ます。

数字より条件のほうが危ない

数字が違えば、たいてい誰かが気づきます。計算が合わなくなるからです。条件は計算に出てこないので、最後まで残ります。

だから確認するときは、数字より先に「これは、どういう場合の話か」を原文に当てます。原文に条件が書かれていて、手元の文に書かれていなければ、それは要約です。

条件が落ちて実害になりやすい3つの領域

要約が引用符に入っていても、内容によっては大した問題になりません。逆に、条件が落ちた瞬間に実害が出る領域がはっきりしています。業務でAIに調べさせる対象は、たいていこの3つに入ります。

領域1｜他社の料金・プラン

料金には条件が大量に付いています。月払いか年払いか、税別か税込か、1人あたりか総額か、最低契約人数があるか、割引の適用期間があるか。金額だけを抜くと、そのすべてが落ちます。

そして相手に渡ると、相手はその金額で計算を始めます。前提が違っていたと後で分かったとき、失うのは金額の正確さではなくこちらの見積り全体の信用です。だから私は、料金だけは要約で渡しません。逐語か、原文の場所を添えるかのどちらかにします。

領域2｜公的な制度の要件

補助金・助成金・各種届出のような公的制度は、要件そのものが条件の集まりです。対象事業者、対象経費、申請期間、併用の可否。ここから1つ落ちるだけで、対象外の人が申請準備を始めてしまいます。

この領域では、そもそも断定を避けるほうが正しいと考えています。要約で趣旨を伝え、判断が必要な部分は「最新の公募要領で確認してください」と原文へ送ります。読者が申請の可否を判断する材料になるので、こちらで確定させないほうが安全です。

領域3｜契約・規約の文言

契約書や利用規約は、読みにくさそのものが機能している文書です。「〜を除き」「〜の場合に限り」といった限定が、権利と義務の範囲を決めています。読みやすくした瞬間に、決めていた範囲が消えます。

ここでAIに要約させるのは有効です。長い条項の趣旨を早くつかめます。ただしその要約を根拠に判断しない、というのが線引きになります。判断する段になったら、該当条項の文言そのものに戻ります。

3領域に共通するのは、読み手がその情報を使って何かを決めるという点です。決める材料にするなら逐語、理解のためなら要約、と分けると迷いません。

訂正されても終わらない｜訂正する側も同じ間違いをする

今回いちばん学びが大きかったのは、この部分です。誤りを見つけて訂正した工程が、訂正のなかで別の誤りを作りました。

「直してくれた」で受け入れると、誤りが権威づけされる

訂正には、独特の強さがあります。「照合した結果こうだった」という文脈で来るので、元の情報より確度が高いものとして扱われます。

そのうえ訂正は、たいてい次の作業の前提条件として書き込まれます。今回も、誤った版番号が「絶対に守る条件」として次工程の指示に入っていました。訂正が前提に昇格した瞬間、それはもう疑われません。

訂正は、指摘の粒度で受け取る

実際にやってみて効いたのは、訂正を1つの塊として受け取らず、指摘ごとにばらして当て直すことでした。今回は3件のうち2件が事実で、1件が誤りでした。塊で受け取っていたら、3件まとめて正しいものとして通していたはずです。

ばらすと手間は増えますが、増える手間は「原文をもう一度開く」だけです。すでに原文の場所は訂正側が示してくれているので、探す時間はかかりません。

止まったのは、原文を自分で開いた工程だけ

この出来事を工程で見ると、次のようになります。

• 1段目：原文を読んだが、短くして引用符に入れた（誤りが発生）
• 2段目：原文を取り直して照合した（誤りを2件検出、1件を誤って作った）
• 3段目：原文を自分で開いて版の区切りを数えた（誤りが止まった）

止まった工程だけが持っていた条件は、腕でも慎重さでもありません。原文を開いたかどうかです。2段目も原文を取り直してはいますが、版の区切りまでは数えていませんでした。

つまり「確認する人を増やす」ことが答えではありません。増えた人が原文を開かないなら、確認の回数だけが増えます。検品の設計としてどう考えるかは、こちらの記事で別途整理しています。

AI業務効率化AIのチェックは増やすほど抜ける｜1本にして観点で割る

では、どう線を引くか｜引用符の使い方3つのルール

ここから運用の話です。私が今使っている線引きは3つだけです。

ルール1｜引用符の中身は、コピー＆ペーストで作る

打ち直したら引用ではない、と決めます。極端に思えますが、この線を引くと判断に迷いがなくなります。

手で打ち直すと、人は無意識に整えます。句読点を足し、語尾を揃え、冗長な部分を落とします。1文字も変えないつもりで打ち直しても、結果として変わります。だから作業手順のほうで塞ぎます。

ルール2｜自分の言葉にしたら、引用符を外して「要約すると」を付ける

短くしたい場面は必ずあります。そのときは引用符を外し、「要約すると」「趣旨は」と前置きします。これだけで受け手の動作が変わります。

「要約すると」が付いていれば、受け手は「正確な文言が必要なら原文を見よう」と判断できます。引用符が付いていると、その判断の機会自体が消えます。引用符を外すことは、受け手に確認の権利を返すことだと考えると分かりやすいです。

ルール3｜引用には「どこにあったか」を必ず添える

引用符の中身と一緒に、原文のどこにあったか（ページ・見出し・版・日付のいずれか）を書きます。場所が書けない引用は、引用符を外すのが安全です。

場所を添える効果は2つあります。受け手が確認しに行けるようになること。そしてもう1つは、書く側が「場所を書けないぞ」という段階で自分の手元を疑えることです。今回の1段目は、まさに場所を添えていませんでした。

AIに調べさせるときの指示の書き方

頼み方を変えるだけで、返ってくるものの質が変わります。ここは実際に効いた形をそのまま書きます。

「引用して」ではなく「原文の該当箇所をそのまま貼って」

「引用して」は、要約を許す余地が残る言い方です。私は次の形に変えました。

• ❌ 「この資料から根拠を引用してください」
• ⭕ 「該当箇所を、原文のまま省略せずに貼ってください。読みやすく整えないでください」

「整えないで」を明示するのが要点です。整えるのは通常は良い振る舞いなので、止めたいなら止めると書く必要があります。

返してもらう4項目

引用が必要なときは、次の4つをセットで返してもらいます。

• 原文のまま貼った文字列（省略した箇所があれば、省略した旨を明示）
• それがどこにあったか（見出し・章・版・日付など、後から辿れる情報）
• その文に付いている条件（「〜の場合」「〜を除く」があれば、必ず別に書き出す）
• 要約は要約として別枠で（趣旨の説明が欲しい場合は、引用と混ぜず分けて書く）

3つ目を独立させているのは、条件がいちばん落ちやすいからです。「条件を別に書き出して」と指示すると、条件の有無そのものを確認する動作が入ります。

引用が返ってきたときの2つの問い返し

受け取ったあとに、私は2つだけ聞き返します。

• 「この文字列は、原文に一致していますか。整えた箇所はありますか」
• 「この文に付いている条件を、そのまま書き出してください」

どちらも、答えを信用するために聞いているのではありません。整えた箇所を自己申告してもらう機会を作るためです。実際、この問い返しで「読みやすさのために語尾を変えました」と返ってくることがあります。それが分かれば、引用符を外して扱えます。

なお「該当なし」「見つかりませんでした」という返答の扱いは、別の型の問題になります。こちらは範囲の話なので、別記事で整理しています。

AI業務効率化AIの「該当なし」は信じていいか｜0件が出たら探し方を疑う

短くしたいときは、引用符を外す

ここまで読んで「では長い原文をそのまま貼るしかないのか」と思われたかもしれません。そうではありません。短くしてよい。引用符を外すだけです。

引用符と読みやすさは両立しない

原文が読みにくいのは、正確に書こうとして条件や例外が詰め込まれているからです。読みやすくする作業は、その条件を削る作業とほぼ同義です。だから両方は取れません。

取れないものを取ろうとすると、今回のように「読みやすい引用」ができあがります。どちらかを選ぶと決めておけば、迷いません。

3つの書き分けの型

実際の書類では、次の3つを使い分けています。

迷ったら要約にします。要約として渡した情報は、必要になった時点で誰かが原文を見に行けます。引用として渡した情報は、誰も見に行きません。

社内で運用に落とすときの3ステップ

個人の心がけで終わらせず、書類の形に落としておくと再発しません。私がやったのは3つです。

ステップ1｜引用が入る書類を1つ決める

まず、社内で「引用が入る書類」を1種類だけ選びます。調査メモ、比較表、提案書の根拠欄などです。全部を一度に直そうとすると続きませんので、いちばん誤りが外に出やすいものを1つ選びます。

ステップ2｜「引用」欄と「要約」欄を分ける

その書類のテンプレートに、引用欄と要約欄を物理的に分けて作ります。欄が分かれていると、書く側は「どちらに入れるか」を必ず1回考えます。この1回が効きます。

引用欄には出所の記入欄も付けます。出所が空欄のまま引用欄に文字列が入っていたら、その時点で要約欄へ移す、というだけの運用です。

ステップ3｜訂正が来たときの確認担当を決める

最後に、訂正が来たときに原文を開く人を決めておきます。今回の出来事の教訓はここに集約されます。訂正は前提条件に昇格するので、昇格の前に一度、原文に当てる工程が必要です。

担当を決めるといっても、やることは「訂正に書かれている場所を開いて、指摘ごとに当てる」だけです。場所は訂正側が示してくれているので、数分で終わります。この工程を誰の仕事とも決めていなかったのが、今回の直接の原因でした。

なお、AIに作らせた一覧や表の検証は、引用とはまた別の落とし穴があります（誤りではなく「古い」という形で出ます）。あわせてこちらもご覧ください。

AI業務効率化AIが作った一覧は間違いではなく古い｜検証の4工程

今日からできる3つのこと

• 手元の資料で、引用符が付いている箇所を1つ選ぶ。その文字列を原文の検索窓に貼って、一致するか確かめる
• 一致しなかったら、引用符を外して「要約すると」を付ける。文の内容は変えなくてよい。記号を直すだけで、受け手の動作が変わる
• AIへの指示から「引用して」を消す。「原文のまま省略せずに貼って。読みやすく整えないで」に置き換える

3つとも、今日のうちに終わる作業です。特に1つ目は、当たりが出ると効きます。

よくある質問

Q. もっと精度の高いAIを使えば、この問題は解決しますか

しません。今回起きたのは能力の問題ではなく、「引用して」という指示が要約を許してしまうという指示の問題だからです。精度が上がれば要約の質も上がり、より自然で、より疑いにくい文が返ってきます。見分けにくさは増える方向に働きます。

Q. 引用符ではなく、色や書式で区別すればいいのでは

区別の記号を増やすこと自体は有効ですが、記号の意味が共有されていないと機能しません。引用符が強いのは、意味が広く共有されているからです。社内独自の書式を作るより、引用欄と要約欄を分けるほうが確実でした。

Q. 原文が長すぎて、そのまま貼ると資料が読めなくなります

その場合は、要約を本文に置き、引用は付録や脚注に回します。短くする代わりに引用符を外す、長いままにする代わりに置き場所を変える——このどちらかで、たいていの資料は成立します。両方を同時に妥協して「短い引用」を作るのが、いちばん危ない選択です。

Q. AIが「原文のまま貼りました」と言っているのに違っていたら、どうすればいいですか

その申告を信用する前提を置かない、というのが答えになります。私が問い返しを2つ入れているのは、答えを信じるためではなく、整えたことを申告する機会を作るためです。判断の根拠にする文字列だけは、最後に人が原文の検索窓に貼って一致を見ます。ここは省けません。

Q. 訂正のたびに原文を開くのは、二重の手間ではないですか

手間は増えます。ただ今回は、3件の訂正のうち1件が誤りで、しかもそれが次の作業の絶対条件に据えられていました。開かなければ、誤った条件のまま成果物が出ていました。原文を開く数分と、公開後に誤りが見つかる損を比べる話になります。

Q. 社内にこの考え方を広めるには、どう説明すればいいですか

「引用符は、この文字列を目で見たという約束です」という一文から始めるのが早いです。正確性の話としてではなく約束の話として説明すると、「じゃあ見ていないなら外すべきだ」という結論に自分で辿り着いてもらえます。禁止事項を増やすより、記号の意味を1つ共有するほうが定着します。

まとめ

今回の出来事を短くまとめると、次のようになります。

• 原文から1行引いたつもりで、原文に存在しない要約を引用符に入れて次の工程へ渡した
• 別の工程が照合して3件を訂正したが、そのうち1件は訂正のほうが誤っていた
• 止まったのは、原文を自分で開いて数えた工程だけだった

対策は3つの線引きに収まります。引用符の中身はコピーして作る。自分の言葉にしたら引用符を外して「要約すると」と書く。引用には出所を添える。そして訂正を受け取ったら、指摘ごとに原文へ当て直す。

AIを業務に組み込むとき、確認の回数を増やす方向に手が動きがちですが、今回効いたのは回数ではなく原文を開いたかどうかでした。株式会社Fyveでは、こうした受け渡しの設計をふくめて、AIを日常業務に組み込む仕組みづくりを支援しています。