AIは、写真や図をどう読んでいるのか自社4,564枚を数えてみました

AIは画像そのものより、画像に添えた文を読んでいる

まず、よくある誤解をひとつ外しておきます。「AIは画像を読めない」というのは、正しくありません。画像を渡せば、いまのAIはその中身を説明できます。Anthropicの公式ドキュメントにも、画像を受け取って解釈する機能があるとはっきり書かれています。

問題は「渡したとき」と「AIが自分でホームページを見にきたとき」は別だ、というところです。ページを読みにきた機械が確実に受け取っているのは、画像そのものではなく、画像に添えられた文のほうです。

これは推測ではありません。Googleの公式ドキュメントに、次のように書かれています。

Googleの「画像SEOのベストプラクティス」には、「Googleは、altテキストと画像認識アルゴリズムとページの内容を合わせて、画像の主題を理解する」と書かれています。3つのうちのひとつ、ではありません。3つを合わせて、です。説明文が無ければ、3本の柱のうち1本が最初から立っていないことになります。

そして2026年7月に更新された、Googleの生成AI向けの公式ガイドには、もう一段はっきりした記述が加わりました。ブラウザを操作するAIエージェントは、画面の描画（スクリーンショット）・DOM構造・アクセシビリティツリーを解釈して情報を集める、というものです。

この「アクセシビリティツリー」というのは、読み上げソフトがページを読むときに使う構造のことです。画像の説明文は、そのアクセシビリティツリーの中身そのものです。つまり、読み上げソフトのために書く文と、AIエージェントが受け取る文は、同じものだということになります。

出典：Google 検索セントラル「画像SEOのベストプラクティス」（最終更新 2026年3月2日）／同「生成AI機能への最適化ガイド」（最終更新 2026年7月10日）／Anthropic「Vision」公式ドキュメント。いずれも2026年9月4日に原典で確認。

ここから先は、当社が自分のサイトで実際に数えた話です。「AIの中で何が起きているか」は当社には測れません。測れるのは「自分のサイトに何が書いてあるか」だけです。その範囲で、正直に書きます。

世界の100万サイトを調べた人たちがいます

自社の話をする前に、世の中の相場を見ておきます。これを知らないと「うちだけがひどいのか」が分かりません。

数字を3つだけ拾います。以下はすべて、この世界調査の数字です（当社の実測は第3章から）。

ひとつ目。世界の上位100万サイトでは、説明文が無い画像が16.2%ありました。ここでいう「無い」は、属性そのものが書かれていないものだけを数えています（意図的な空欄は含みません。この違いは第4章で詳しく書きます）。

ふたつ目。説明文がある画像のうち10.8%が「疑わしい、または繰り返し」でした。中身が「image」「写真」といった無意味なものや、ファイル名がそのまま入っているもの、そして隣の画像とまったく同じ文になっているものです。

この「繰り返し」を独立した問題として数えているところが重要です。世界最大級の調査が、空欄とは別に「中身が同じ」を数えている。これは後半で当社の事故につながります。

みっつ目。説明文の欠落は、全ページの53.1%で検出されました。低コントラストの文字に次いで、2番目に多い問題です。つまりこれは、珍しい話ではありません。

日本語のページは、平均より悪い

同じ調査に、言語別の集計があります。日本の中小企業の社長に、いちばん関係がある部分です。

出典：WebAIM「The WebAIM Million」2026年版（2026年2月調査・最終更新 2026年3月30日）

日本語のページは、世界平均より1割ほどエラーが多い。英語のページとは16件の差があります。理由までは調査に書かれていないので、当社も推測は書きません。事実として、そうなっているということです。

「うちのホームページの作りが悪いのでは」と思う前に

同じ調査には、使っている道具別の集計もあります。ここは読者の誤解を先に外しておきたい部分です。

出典：WebAIM「The WebAIM Million」2026年版。⚠ この数字は「その技術を使うと悪くなる」という因果を示したものではなく、相関です。原典もそう注記しています。

WordPressを使っていること自体は、悪くありません。むしろ平均より良い。一方で、トップページのスライダーと、埋め込んだYouTube動画は、エラーが増える側に並んでいます。中小企業のホームページに、だいたい両方あります。

そして当社が実際に事故を起こしたのは、まさに動画のサムネイル画像でした。第6章で書きます。

原典が「AIで作ることが一因かもしれない」と書いている

この調査の結論部分に、ひとつ気になる記述があります。ページの複雑化と、AIに手伝わせるコーディング（原文では “vibe coding”）が、悪化の一因と考えられる、というものです。画像は1年で13.6%増え、ページの部品数は1年で22.5%増えました。

AIで作るのが悪い、という話ではありません。速く大量に作れるようになった分、間違いも速く大量に複製されるということです。当社の事故も、まさにその形でした。

自社サイトの画像4,564枚を、1枚ずつ数えました

ここからが本題です。他社の話ではなく、自分のサイトを数えました。

出典：ytbs.jp の公開データを機械で全数走査（2026年9月4日実施・未ログイン状態）。再現手順は本記事の第12章に簡略版を載せています。

3枚に1枚に説明文が無い。最初にこの数字を見たときは、正直まずいと思いました。

ただし、この数字をそのまま「3割の画像が問題だ」と読むのは間違いです。次の章で、その理由を書きます。

「3枚に1枚」を分解したら、話が変わりました

画像の説明文には、実は3つの状態があります。ここを混ぜると、数字が意味を失います。

出典：ytbs.jp 全数走査（2026年9月4日）。正誤の判定基準は W3C WAI「Decorative Images」による。

W3C（ウェブの標準を決めている団体）の公式ドキュメントには、はっきりこう書かれています。飾りの画像には空の説明文（alt=""）を付けるべきで、これによって読み上げソフトはその画像を無視できる。飾りに文を付けると、読み上げが邪魔になるからです。

そして、そのすぐ後にこうも書かれています。「属性を省略するのは選択肢ではありません」。省くと、読み上げソフトが代わりにファイル名を読んでしまうことがあるからです。

つまり「空にする」と「書き忘れる」は、見た目は同じでも、正しさが正反対です。当社の1,411枚は、ほとんどが前者でした。

出典：W3C WAI「Images Tutorial」（Decorative Images / Informative Images / Functional Images）。2026年9月4日に原典で確認。

世界の16.2%と、当社の0.2%は並べていいのか

第2章で、世界では説明文が無い画像が16.2%だと書きました。当社は0.2%です。桁が2つ違います。

ただし、ここは正直に書きます。この2つは、厳密には同じ土俵の数字ではありません。WebAIMが調べたのは各サイトのトップページ全体（メニューやロゴを含む、ブラウザで表示された状態）で、当社が数えたのは記事の本文の中だけです。数え方が同じ（属性そのものが無いものだけを数える）という点は揃っていますが、対象が違います。

だから「当社は世界平均の80分の1」とは書きません。言えるのは「同じ定義で数えたとき、当社の記事本文には書き忘れが11枚しかなかった」ということだけです。

そして、ここが本題です。この11枚を直しても、当社の本当の問題は1つも解決しませんでした。

その3割は、3つの違う集団を混ぜた平均でした

当社のサイトは、記事の作られた時期によって設計が3世代に分かれています。それぞれで数えてみました。

出典：ytbs.jp 全数走査（2026年9月4日）。世代は本文HTMLのラッパークラス名で判定しています。

これが、この記事でいちばんお伝えしたいことのひとつです。「サイト全体で3割」という数字からは、何をすればいいかが出てきません。全部直すのか、と気が遠くなるだけです。

世代別に分けると、やることが決まります。古い記事から手を付ける。新しく作る分は最初から正しく作る。そうすれば、この数字は自然に減っていきます。実際、当社の新しい設計の160ページはゼロ枚です。

平均値は、便利です。でも平均値は「どこを直すか」を隠します。これは画像の話に限りません。

怖かったのは「空欄」ではなく、「中身が同じ」でした

ここからが、当社が実際に踏んだ失敗の話です。

最初、当社は「説明文が空の画像はいくつあるか」を数えました。動画のサムネイル画像については、空欄はゼロ枚でした。合格です。

次に「説明文の種類はいくつあるか」を数えました。212本の動画に対して、212種類の説明文。1対1です。完璧に見えました。

それでも念のため、観測点をもう一段変えてみました。「同じ文が、別々の動画に付いていないか」を数えたのです。

出典：ytbs.jp 全数走査（2026年9月4日）。動画IDはサムネイル画像のURLから抽出し、同一の説明文が何本の別IDに付いているかを数えました。

実際に付いていたのは「YouTubeアイコン（ロゴ）の作り方・サイズ・設定方法を解説する動画」という文でした。それ自体は、悪い文ではありません。1本の動画については、正確です。

問題は、まったく関係のない34本の動画にも、同じ文が付いていたことです。機械から見ると、当社のサイトには「YouTubeアイコンの作り方の動画」が34本あることになります。

もうひとつ、付け加えておきます。「同じ説明文が使い回されている」こと自体は、悪いことではありません。当社のサイトで最も多く使われている説明文は、著者の顔写真の407回、書影の400回と248回です。同じ画像なら、同じ説明文で正しい。

実際、説明文がある3,153枚のうち、2回以上使われている文が付いているものは1,910枚（60.6%）あります。数字だけ見ると多いように見えますが、大半は正常です。

だから「使い回しを数える」だけでも足りません。「同じ画像に同じ文」なのか、「違うものに同じ文」なのか。そこまで見て、初めて事故と正常が分かれます。

リンク切れチェックでは見つからない壊れ方

もうひとつ、同じ調査で出てきた話です。

YouTubeのサムネイル画像には、いくつかのサイズがあります。高画質版は、古い動画には存在しないことがあります。問題は、存在しないときの返事の仕方です。

普通、ページや画像が存在しなければ「404（見つかりません）」が返ります。リンク切れチェックのツールは、この404を探します。

ところが高画質サムネイルの場合、存在しなくても「200（正常です）」が返り、中身として120×90ピクセルの灰色の画像が渡されます。当社が以前に調べたときは、動画201本のうち55本（27.4%）がこの状態でした。

ここで、第1章の表を思い出してください。Anthropicの公式ドキュメントには、「低品質・回転した・200ピクセル未満の非常に小さい画像では、誤った解釈をしうる」と書かれています。120×90ピクセルは、その条件に当てはまります。

ただし「だからAIが必ず間違える」とは書きません。当社が言えるのは、公式が「誤りうる」と書いている条件に、当社の画像55本が当てはまっていたという事実までです。

この章のポイントは、灰色画像そのものではありません。「200が返ってきたから正常」というのも、測る面を1つに絞った判断だったということです。第6章と同じ形の失敗が、別の場所でも起きていました。

同じサイトを2か所で測ったら、40ポイント違いました

ここは、この記事を書いている途中で見つけたものです。

WordPressを使っていると、画像をアップロードするときに説明文を入力できます。ここに入れておけば大丈夫だと思っていました。

ところが、記事の本文に画像を貼った時点で、そのときの説明文が本文のHTMLに焼き付けられます。あとからメディアライブラリ側を直しても、すでに貼ってある記事には反映されません。逆も同じです。

出典：ytbs.jp の公開データを機械で走査（2026年9月4日・未ログイン状態）。メディアライブラリ側は、公開APIから取得できた2,133件（うち画像2,127枚）を対象としています。

読者にとって大事なのは、本文のほうです。機械が読むのは、実際にページに書かれているHTMLだからです。メディアライブラリ側は、これから貼る画像のための「元」にあたります。

とはいえ、両方そろっているに越したことはありません。当社は2026年8月2日から「画像をアップしたら説明文を必ず設定する」を社内ルールにしています。そのうえで、72.9%が空でした。ルールを作った会社でも、こうなります。

なぜ気づけなかったのか、どう直すと決めたか

事故の原因は、はっきりしています。動画の表示を軽くするために、サイト全体の埋め込み方法をまとめて変えたときに、1つの説明文がそのまま全体に複写されたのです。

一括処理は速い。ただし、間違いも同じ速さで複製されます。第2章で見た「AIに手伝わせると悪化する一因かもしれない」という指摘と、形は同じです。

直すときに決めた3つのこと

同じ型が、もう1か所で見つかりました

この記事を書くにあたって、当社のメディアライブラリも点検しました。そこで見つかったものを、そのまま書きます。

4枚の画像に、まったく同じ説明文が付いていました。「Googleアナリティクス（GA4）の管理画面」という文です。

しかも、確かめてみるとそのうち実際に「管理画面」だったのは1枚だけでした。残りの3枚は、ホーム画面・リアルタイムのレポート・トラフィック獲得のレポートで、まったく別の画面です。

出典：ytbs.jp メディアライブラリの実測と是正（2026年9月4日実施）。是正後、4枚とも別々の説明文になっていることを再取得して確認しました。

ここで分かったことが、ひとつあります。「同じ文の使い回し」は、同時に「間違った説明」でもありました。4枚に同じ文を付けた時点で、少なくとも3枚は事実と違うものになっていたわけです。

使い回しが危ないのは、手抜きだからではありません。1つの文が、それが正しくない場所まで運ばれていくからです。

分かっていないこと

この記事で、当社が確かめていないことを3つ挙げます。

3つ目は、この記事を書きながら当たったものです。

メディアライブラリを数えたとき、WordPressが「全部で3,412件あります」と答えたのに、実際に取り出せたのは2,133件でした。差は1,279件です。下書きに戻した記事に紐づく画像が、公開用のデータから外れているのだろうと考えていますが、確かめていないので断定はしません。

この記事の数字は「取り出せた2,133件」で計算しています。「ツールが表示する総数」と「実際に取り出せる件数」が違うことがある――これも、数え方の話です。

結局、どう書けばいいのか

Googleの「画像SEOのベストプラクティス」には、4段階の例が載っています。日本語にすると、こうなります。

出典：Google 検索セントラル「画像SEOのベストプラクティス」（最終更新 2026年3月2日）。例は原典の犬の写真の例を日本語に置き換えたものです。

長さの目安は、当社の実測から

「何文字くらい書けばいいですか」とよく聞かれます。決まりはありません。当社の実測値を目安として出しておきます。

記事本文の説明文は、中央値38字・最長231字でした。231字は、明らかに長すぎます。1文で「何が写っているか」と「なぜそれを載せたか」が分かれば十分です。

会社のホームページなら、たとえばこう書きます。「自社工場で職人が家具に手作業でオイルを塗っている様子」。固有名詞と、具体的な動作が入っていれば、だいたい足ります。

図（グラフ・イラスト）と、背景画像の注意

2つだけ、見落とされがちな点を書いておきます。

ひとつ目。ページに直接描かれた図（インラインSVG）には、<title>という別の書き方を使います。これもGoogleの公式ドキュメントに、写真の説明文と並べて書かれています。当社は図197個のうち104個で、これが付いていませんでした。これから直します。

ふたつ目。CSSの背景画像として置いた画像は、Googleがインデックスしませんと公式に明記されています。デザイン上の飾りなら問題ありませんが、見せたい写真を背景として置いているなら、置き方から見直したほうがいいということです。

自分の会社で3分で確かめる方法

ここまで読んでいただいた方が、月曜に実際にできることを書きます。

③で使う考え方だけ、もう一度書きます。同じ画像に同じ説明文が付いているのは、正常です。会社のロゴが全ページに出ていて、全部同じ説明文なのは、当たり前です。

異常なのは、違うものに同じ説明文が付いているとき。商品Aと商品Bの写真に同じ文が付いていたら、機械から見て両者は区別できません。

制作会社に任せている場合、何を聞けばいいか

自分で触らない社長のために、そのまま使える質問を3つ用意しました。

質問2に答えられる制作会社は、多くありません。それは能力の問題ではなく、この観点があまり知られていないからです。当社も、自分のサイトを数えるまで気づきませんでした。

どこまでが0円で、どこから先が違うか

ここまでの点検は、すべて0円でできます。ツールも要りません。

費用がかかるのは、見つかったものを直す作業からです。数十枚なら自社で十分に終わります。数百枚を超えて、しかも一括で直す必要が出てきたときは、一括処理そのものが事故のもとなので（当社がまさにそれで壊しました）、手順を決めてから進めることをおすすめします。

よくある質問（FAQ）

まとめ