AIの要約で『できる』が『できない』に化けた話——Claude CodeのWebFetchが表を誤読

AIにWebページを要約させて、その答えをそのまま鵜呑みにしていませんか。先日、まさにそれで足をすくわれかけました。

受託開発の商談で、あるレンタルサーバーの設定について「これは変更できるのか、できないのか」を公式サイトで確かめる必要がありました。ここが「できる」か「できない」かで、提案そのものが成り立つかどうかが決まる、という場面です。公式のよくある質問ページをAI（Claude Codeの「WebFetch」＝Webページを取ってきて要約してくれる機能）に読ませたところ、返ってきたのは「できます」という答えでした。ところが後で見直すと、まったく同じページから「できない」とも読めてしまう。答えが真逆にひっくり返る、きわどい状態だったのです。

先に結論から

なぜこんなことが起きたのか。ひとことで言えば、AIの要約が「表のかたち」を平らにしてしまったからです。表のマスの結合や、箇条書きの「大きな項目とその注釈」といった上下の関係は、要約されて普通の文章になる過程でぽろりと抜け落ちます。すると隣の行の値を取り違えて、意味が正反対になってしまう。同じ落とし穴を避けるための勘どころは、次の4つに尽きます。

1. 「できる／できない」を左右する一文は、AIの要約ではなく元ページのそのままの中身を自分の目で確かめる。とくに表の「マスの結合」に注意する。
2. 「〜できません」という否定文を見つけたら、それが何に対する制限なのかをまず疑う。全体の話なのか、すぐ隣の一項目だけの話なのかで、意味が正反対になる。
3. 制限の文をいくら読み直すより、「〜が可能です」という肯定文を1つ探すほうが、答えに早くたどり着く。
4. AIに確かめさせるときは「もう一度調べて」ではなく「この結論は間違っているはずだ、覆してみろ」と、逆向きに指示する。

以下、なぜ「できる」が「できない」に化けたのか、その仕組みを実際のページで順に追っていきます。

表のセル結合（rowspan）が消えると、行がまるごとズレる

最初のつまずきは、変更できるDNSレコード（＝ドメインの住所録のようなもの）を一覧にした表で起きました。この表には、縦に並んだ複数の行で1つのマスを共有する「マスの縦結合」が使われています。エクセルで「セルを結合」するのと同じ発想で、HTMLでは rowspan（ロウスパン）という指定で表します。公式FAQ「DNSレコード情報を変更できますか?」の該当箇所を、表示前のそのままの中身で取り出すと、こうなっていました。

黄色の rowspan="2" が「このマスは下の行にも続きます」という結合の指定です。つまり「www」の行にある値（Aレコード、CNAMEレコード）は、1つ下の「システム予約語以外のホスト名」の行にも当てはまります。ところが要約でこの結合が消えると、「システム予約語以外のホスト名」の行は値のない空っぽの行に見えてしまいます。

すると読み手は、その空欄を埋めようとして、すぐ下にある「SPFレコード」の行の値（有効／無効）を、間違って結びつけてしまう。こうして「一般のホスト名で変更できるのは、SPFの有効／無効だけ」という、表のどこにも書かれていない読みができあがってしまいました。

「・」と「※」の段差が消えると、注意書きの掛かる先がずれる

もう一つの誤読は、別ページ「管理者機能（Webサービス）」マニュアルの箇条書きで起きました。実際の記載はこうです。

末尾の「※」の注意書きは、すぐ上の「・TXTレコードは〜」という1行だけに掛かる注釈です。ところが「・」（独立した項目）と「※」（その直前の項目への注釈）という段差が要約で平らになると、「任意のIPアドレスは変更・追加できません」が、Aレコードも含めた全体の制限のように読めてしまいます。

でも実際には、同じページに「・ 外部サーバ（他社ホスティング・自社サーバ）への変更が可能です。」という肯定文があり、Aレコードの欄はまさにIPアドレスを入れるための欄でした。「できない」と読んでいた結論は、丸ごと裏返っていたわけです。

効いたのは「もう一人に聞く」ではなく「間違いを探せ」と命じること

この誤読は、同じ調査をもう一度別のAIにやらせても、たぶん見つかりませんでした。肯定的な答えを探す調査は、肯定的な要約が返ってきた時点で満足して止まってしまうからです。

今回効いたのは、確認役に対して「この結論を崩せ。同じ情報源から逆の読みが成り立たないか確かめろ」と、指示の向きそのものを反対にしたことでした。「間違っているはずだ」という前提で見に行った側だけが、要約を信じずに元ページのそのままの中身を curl（ページを丸ごと取ってくるコマンド）で開き、マスの結合に自分の目で気づいています。同じ情報源でも、指示の向きを変えるだけで別の答えが出てきたのです。

もう一つ、否定文（「〜できません」）を見つけたら、その掛かる先を疑うのが近道でした。日本語の説明文では「Aについて。〜できません」の「A」が、実は直前の一項目だけを指していることがよくあります。制限の文を何度も読み直すより、「〜が可能です」という肯定文を1つ見つけるほうが、ずっと早く確実に結論にたどり着けました。

おまけ：ホームページ用の設定変更が、メールに響くことがある

今回の調査で、もう一つ見落としやすい仕組みに気づきました。「メール関連の設定さえ触らなければ、メールには影響しない」という思い込みは危ないのです。

ここで出てくるのが SPF という仕組みです。SPFは「このドメインのメールは、このサーバーが正規に送っています」と宣言して、なりすましやスパム扱いを防ぐためのものです。このSPFの書き方に a という指定が混じっていると、ホームページ用の住所（Aレコード）の値が、そのままメールの正当性チェックにも使われます。仕様書RFC 7208 §5.3でも、この指定を「送信元のIPアドレスが、対象ドメインの住所録（A/AAAAレコード）のどれかと一致するかを確かめる」仕組みと定めています。

つまり、SPFがIPアドレスを直に書く形（ip4:...）なら、ホームページ用の住所を変えても無関係です。しかし a を使う形なら、ホームページの引っ越しがメールの認証結果まで巻き添えにします。「ホームページとメールでサーバーを分けたい」というときは、SPFの中身を先にのぞいておく価値があります。

判断の土台にする一文は、要約で読まない

冒頭の4つに立ち返ると、根っこにあるのは「一見ただしそうな答えで満足しない」という一点です。要約は速くて便利ですが、「できる／できない」を分ける一文の”入れ物”（表の結合や箇条書きの段差）を、静かに壊してしまうことがあります。速さと引き換えに、判断の土台が抜け落ちていないかを疑う。この一手間が要ります。

AIが「公開しました」と報告したのに、本番には何も反映されていなかった話でも書きましたが、AIの出力はもっともらしいほど、つい確認を省いてしまいます。あちらは完了報告の嘘、今回は調査の途中結果の誤読でしたが、「もっともらしさに引きずられない」という点で根は同じでした。ここまでの経験をまとめたClaude Code実務運用ガイドや、AIにどこまで任せるかも、よければあわせてどうぞ。