AIは画像を読めているか｜alt・キャプション・図解テキスト化の実務

「最近のAIはマルチモーダルだから、画像もそのまま理解してくれる。altテキストはもう頑張らなくていい」——AI検索の話題でよく聞くようになった誤解です。実務ではこの逆を前提にしてください。ChatGPTやGoogleのAIによる概要（AI Overview）が回答を組み立てる工程で確実に材料になるのは、画像そのものではなく、altテキスト・キャプション・周辺本文としてテキスト化された部分です。図解の中にどれだけ重要な数字や比較を描き込んでも、それが本文のどこにもテキストとして存在しなければ、AIの回答材料からは抜け落ちる前提で設計すべきです。

結論を先に言うと、画像まわりのLLMO対策でやることは3つに集約されます。(1) 画像を「装飾」と「意味」に分類し、意味のある画像だけにaltを書く。(2) 図解・チャートの中身は、図とは別に本文かキャプションでテキスト化する。(3) ファイル名・構造化データ・OGPという機械向けのラベルを整える。本記事はこの3つを、判断表と実装チェックリスト付きで解説します。

なお、AIクローラーにサイト全体をどう巡回させるかはサイトマップとAIクローラー設計、実際にどのAIボットが何を取得しているかの調べ方はAIクローラーのログ分析で扱っています。本記事はその隣接テーマとして「画像コンテンツのAI可読性」だけに絞ります。

画像のAI可読性とは：この記事で使う定義

画像のAI可読性とは、画像が伝えている情報を、AI検索や大規模言語モデルが回答生成の材料として利用できるテキスト形式（altテキスト・キャプション・周辺本文・構造化データ）でどれだけ提供できているかの度合いを指します。画像認識技術で画像自体を解析できるかどうかではなく、「サイト運営者がテキストの形で手渡せているか」を問う概念です。

この定義がそのまま実務の優先順位になります。AIモデル側の画像認識能力は運営者にはコントロールできませんが、alt・キャプション・本文のテキスト化は今日から自社で整えられるからです。

事実と仮説を分ける：AIは画像をどこまで扱っているか

画像とAI検索の関係は、確認できる事実と、確認できない仮説を分けて押さえておく必要があります。ここが混ざると「画像を作ればAIに引用される」のような根拠のない期待が生まれます。

確認できる事実は次の通りです。Googleは画像検索のベストプラクティスとして、altテキストは「ページコンテンツに沿った、情報に富む役に立つもの」にすること、キーワードの詰め込みはスパム判定の要因になること、ファイル名は内容を示す具体的なものにすること、キャプションやタイトルなど画像周辺のテキストから画像情報を抽出することを公式に述べています（出典は文末）。またアクセシビリティの国際的な指針であるW3Cは、装飾目的の画像には空のalt（alt=""）を、情報を持つ画像には意味を伝えるaltを使い、グラフのような複雑な画像は「画像内の情報をページの別の場所に記載する」ことを推奨しています。OGPの仕様にも、og:imageを指定するならその内容を説明するog:image:altを併記すべきと明記されています。

一方、仮説として扱うべきこともあります。ChatGPT・Perplexity・Geminiなどの各AI検索が、回答生成時に画像ファイルそのものをどの程度取得・解析しているかは、各社が仕様として公開しておらず、外部から網羅的に検証もできません。自社サーバーのアクセスログでAIボットの挙動を観察することはできますが（方法はAIクローラーのログ分析を参照）、それも「自社サイトで観察できた範囲」に留まります。だからこそ実務では、「図の中の文字はAIに読まれない」という保守的な前提で書くのが安全です。この前提で作ったコンテンツは、仮に将来AIの画像解析が進んでも損をしません。テキスト化は人間の読者・スクリーンリーダー利用者・従来の検索エンジンすべてに同時に効くからです。

最初の分岐：装飾画像と意味画像の判断表

altテキストの書き方を調べると「すべての画像に丁寧なaltを」という説明を見かけますが、これは正確ではありません。W3Cの判断基準では、装飾目的の画像にはむしろ空のalt（alt=""）を指定するのが正解です。装飾画像に無理やりテキストを付けると、スクリーンリーダーやAIにとってはノイズが増えるだけです。

まず自社サイトの画像を次の表で分類してください。

この分類はW3Cのalt判断ツリー（画像チュートリアル）の考え方に沿ったものです。ポイントは、altを書く・書かないの判断が「画像の重要度」ではなく「その画像が消えたときに情報が失われるか」で決まることです。消えても本文の意味が変わらないなら装飾、変わるなら意味画像です。

altテキストの書き方：画像の説明ではなく「本文の代わり」を書く

意味画像のaltは、「画像を説明する文」ではなく「画像が無い読者に対して、本文の流れの中でその画像の代わりを務める文」として書きます。この視点の違いが品質を分けます。

たとえば税理士事務所の料金ページに料金体系の図が入っているケースを考えます。

• 悪いalt: alt="料金表の画像" ——何の情報もありません。
• ありがちなalt: alt="税理士 料金 顧問料 相場 格安 比較" ——キーワードの羅列で、Googleが公式に避けるよう明言しているパターンです。
• 良いalt: alt="顧問契約の月額料金体系の図。年商規模別に3プランを比較" ——図の主題と構造が1文でわかります。

書き方の実務ルールをまとめます。

• 本文の文脈に沿わせる。 同じ写真でも「事例紹介ページの施工写真」と「会社案内の社屋写真」ではaltに書くべきことが変わります。Googleもaltは「ページコンテンツに沿ったもの」にすべきとしています。
• 長さの目安は1〜2文。 図の中身を全部altに詰め込みません。複雑な内容は次章の通り本文側でテキスト化します。
• 「〜の画像」「〜の写真」は原則不要。 img要素であることは機械側が既に知っています。ただし「手書きスケッチ」「レントゲン写真」のように画像の種別自体が情報になる場合は書きます。
• キーワードを羅列しない。 詰め込みはユーザー体験を損ない、スパム判定の要因になるとGoogleが明言しています。AI検索対策のつもりでaltにキーワードを積むのは逆効果です。

WordPressの場合、メディアライブラリの「代替テキスト」欄に入力した内容がalt属性として出力されます。ページ表示速度などの診断ツールで「画像にalt属性が指定されていません」と警告される場合、この欄が空のまま挿入された画像が原因であることがほとんどです。ただし前章の通り、装飾画像はalt=""が正解なので、警告を消すためにすべての画像へ機械的にテキストを入れる対応は誤りです。

図解・チャートは「図の中の文字は読まれない」前提でテキスト化する

本記事でいちばん強調したいのがこの章です。多くのサイトで、記事の核心情報——料金比較、手順フロー、調査結果のグラフ——が図解画像の中にだけ存在しています。人間の読者には親切ですが、AI検索の回答材料という観点では、その情報はページに存在しないのと同じ扱いになり得ます。

対応は「図をやめる」ことではありません。図と同じ情報をテキストでも持つことです。W3Cも複雑な画像については「画像が含む情報をページの別の場所に記載する」方式を推奨しており、これはアクセシビリティとAI可読性の両方に効きます。

具体的なテキスト化のパターンは3つです。

• 図の直後に結論文を置く。 グラフなら「このグラフが示す通り、◯◯は△△の傾向がある」と、図が伝えたい結論を本文の地の文で書きます。図を見なくても論旨が追える状態にします。
• キャプション（figcaption）に図の要点を書く。 「図1：問い合わせから契約までの5ステップ。最短の分岐は◯◯」のように、図番号＋要点の形式にします。Googleはキャプションを画像情報の抽出元として明示しています。
• 表・リストに変換できるものは変換する。 比較図はHTMLの表に、フロー図は番号付きリストに、それぞれ「図＋テキスト版」の二段構えにします。比較表自体の設計は比較表のAI引用設計で詳しく扱っています。

どこまでやるかの判断基準は単純で、「この図が表示されなかったとき、読者は同じ結論に辿り着けるか」です。辿り着けないなら、その図はテキスト化が必要な図です。なお、図解をPDFで配布しているケースはさらに条件が厳しくなります。PDFのAI可読性で書いた通り、PDF内の画像化された文字はテキスト抽出自体が失敗しやすいためです。

ファイル名・ImageObject・画像サイトマップ：機械向けラベルを整える

alt・キャプション・本文が「読者と共用のテキスト」だとすれば、ファイル名と構造化データは「機械専用のラベル」です。優先度はテキスト化より下がりますが、整えるコストが低いので一緒に済ませます。

• ファイル名。 IMG_4823.jpg のような自動命名ではなく、kansa-flow-zu.png（監査フロー図）のように内容を示す名前にします。Googleが公式に推奨している基本項目です。既存画像のリネームはURL変更を伴うため、これから追加する画像から適用すれば十分です。
• ImageObject構造化データ。 schema.orgのImageObjectタイプを使うと、画像のライセンスやクレジット、内容説明を機械可読な形で宣言できます。記事の構造化データ（Article等）のimageプロパティに含める形が一般的です。実装の全体像は構造化データとAI検索を参照してください。構造化データは宣言であって保証ではない、という原則もそちらで述べた通りです。
• 画像サイトマップ。 画像の存在をクローラーに伝える補助手段です。サイトマップ全体の設計はサイトマップとAIクローラー設計で扱っているため本記事では重複させませんが、「画像を発見させる」施策と本記事の「画像を理解させる」施策はセットで機能します。

注意点として、これらの機械向けラベルはaltや本文テキスト化の代わりにはなりません。ラベルだけ整えて中身のテキストが無い状態は、荷札だけ立派で中身が空の荷物と同じです。

OGP画像とAI検索：og:image:altまで書いて完成

OGP（og:image）はSNSでのシェア表示用と思われがちですが、AI検索の文脈でも意味を持ちます。AI検索サービスの中には、回答に引用元ページのカードやサムネイルを表示するものがあり、その素材としてOGP画像が使われる場面があるためです（どのサービスがどの条件で表示するかは仕様非公開のため、ここは仮説の範囲です）。

実務で確認すべきは3点です。

• og:imageが全ページで正しく出力されているか。 WordPressではSEOプラグインが出力しているケースが多いので、主要ページのHTMLソースで実際のURLを確認します。
• og:image:altを併記しているか。 OGPの仕様（ogp.me）は「og:imageを指定するページはog:image:altを指定すべき」と明記しています。og:image:altは「キャプションではなく、画像に何が写っているかの説明」です。文字入りのOGP画像なら、その文字情報をog:image:altに書きます。
• OGP画像の中の文字に依存しすぎていないか。 記事タイトルや要点をOGP画像に焼き込むデザインは一般的ですが、その情報は必ずページ本文とtitle要素にもテキストで存在させます。画像の中にしかない情報を作らない、という本記事の原則はOGPでも同じです。

当社7サイト運用での確認範囲と、約束しないこと

AI検索攻略を運営するUravationでは、自社で複数のメディアサイトを運用し、AIクローラーのアクセスログ確認とAI検索への実際の質問を継続しています。その経験から言える範囲を、誇張せずに書いておきます。

言えるのは、運用手順として何を確認すべきかです。(1) サーバーログでAIボットのUser-Agentを抽出し、HTMLと画像ファイルのどちらに何がアクセスしているかを観察する。(2) ChatGPTやPerplexityに自社記事のテーマを質問し、図解にしか書いていない情報が回答に反映されるか、本文にテキスト化した情報と差が出るかを記録する。(3) 記事更新で図解をテキスト化した前後で、AI検索での言及内容が変わるかを定点観測する。——この3つは自社サイトがあれば誰でも再現できる確認手順です。

一方で、約束しないことも明確にします。「altを整えれば引用が増える」「図解をテキスト化すれば表示される」という因果関係は、当社の観察範囲でも統計的に主張できるものではなく、そもそもAI検索側の仕様が非公開・変動する以上、誰にも保証できません。本記事の施策は「AIが利用できる形で情報を渡す」ための整備であり、利用するかどうかの最終判断はAI側にあります。この線引きをせずに効果を断定する情報源には注意してください。

よくある失敗例

• 失敗例1：全画像に長文altを機械生成で一括付与。 装飾画像にまでテキストが付き、ノイズが増えます。先に装飾／意味の分類をしてから、意味画像だけに人の目でaltを書くのが正順です。
• 失敗例2：altにキーワードを詰める。 「LLMO AIO GEO AI検索 対策 会社 おすすめ」のようなaltは、Googleが公式に警告するキーワードの詰め込みそのものです。
• 失敗例3：料金・比較・手順を図解画像だけで提供。 ページの核心情報がテキストとして存在せず、AIにも従来検索にもスクリーンリーダーにも渡りません。本記事で最優先に直すべきパターンです。
• 失敗例4：文字入りバナーで重要告知を出し、本文に同じ文言が無い。 営業時間変更や価格改定など、画像の中にしか無い告知は機械には存在しない告知です。
• 失敗例5：OGP画像は設定したがog:image:altが無い。 仕様上の推奨を満たしておらず、画像の内容説明が機械に渡りません。
• 失敗例6：構造化データだけ整えて満足する。 ImageObjectを宣言しても、alt空欄・本文テキスト化なしでは中身が伴いません。宣言より先に本文です。

FAQ：画像とAI検索でよくある質問

Q. 画像のaltとは何ですか。AI検索とどう関係しますか

alt（代替テキスト）は、画像が表示できない環境や読み上げ環境向けに、画像の代わりとなるテキストをimg要素へ指定する属性です。AI検索との関係では、クローラーや言語モデルが画像の内容を把握するための最も基本的なテキスト情報源になります。もともとアクセシビリティのための仕組みであり、AI向けに特別な書き方をする必要はありません。人間の非視覚環境に伝わるaltは、そのまま機械にも伝わります。

Q. 「画像にalt属性が指定されていません」という警告が出ます。全部埋めるべきですか

全部を文章で埋めるのは誤りです。意味のある画像には内容を伝えるaltを書き、装飾画像には空のalt（alt=""）を指定します。alt属性自体を省略すると機械は「書き忘れ」と「意図的な装飾指定」を区別できないため、装飾画像でも属性そのものは付けて空にするのが正解です。

Q. altの内容が適切かどうかは、どう確認すればいいですか

2つの確認方法があります。ひとつは機械的な確認で、ブラウザの開発者ツールやチェックツールでalt欠落・重複を洗い出す方法。もうひとつは品質の確認で、「画像を非表示にしてaltだけ読んだとき、本文の流れが通るか」を人が読む方法です。品質は後者でしか確認できません。ページ数が多い場合は、問い合わせ・料金・主力サービスなど引用されたいページから順に見ます。

Q. AIはOCRで図の中の文字も読めるのではないですか

モデルによっては画像内の文字を読み取る能力があります。ただし、AI検索の回答生成パイプラインで自社サイトの画像が実際に解析されるかどうかは仕様として公開されておらず、期待して設計するのは危険です。「読まれない前提でテキスト化しておく」方が、読まれた場合にも損をしない設計です。

Q. まず何から着手すべきですか

自社サイトで最も引用されたいページ（料金・サービス説明・主力記事）を1つ選び、(1) そのページの図解・グラフの中にしか無い情報を本文へテキスト化、(2) 意味画像のaltを本文文脈に沿って記述、(3) 装飾画像をalt=""に整理、の順で直すのが費用対効果の面で堅実です。サイト全体の一括修正から始めると、重要ページの改善が後回しになりがちです。

実装チェックリスト

要点の整理

画像まわりのAI検索対策は、突き詰めると「画像の中にしか無い情報を作らない」という一つの原則に集約されます。altは装飾と意味を分けてから本文の文脈に沿って書く。図解の結論は本文かキャプションでテキスト化する。ファイル名・ImageObject・og:image:altという機械向けラベルは、テキストの中身を整えた後に付ける。どれもGoogleとW3Cが公式に示している基本の延長線上にあり、AI検索のためだけの特殊な技術ではありません。だからこそ、AI側の仕様が変わっても無駄になりにくい施策です。

着手順は、引用されたいページを1つ選んで「図解のテキスト化 → 意味画像のalt → 装飾画像のalt="" → OGP・構造化データ」の順が堅実です。そのうえで、自社の画像や図解の情報が現時点でAIにどう扱われているか——ChatGPTやPerplexityに聞いたとき回答に反映されているか——を一度確認しておくと、直す優先順位が具体的になります。AI検索攻略では、こうした現状確認を含むLLMO診断（AI検索ドック）の相談も受け付けています。まずは自社の主力ページを1つ開き、「この図が消えても読者は同じ結論に辿り着けるか」の確認から始めてください。