記事を読み終えたあと、その内容をそのままChatGPTやClaudeに貼り付けている人は多いと思います。「この手順をうちの環境に合わせて書き直して」「この事例をもとに社内提案の骨子を作って」。読むことと使うことの間に、AIが一枚挟まるのが当たり前になりました。
ところが多くのメディアは、いまだに「人間がブラウザで読む」ことだけを前提に作られています。範囲選択してコピーすれば、ナビゲーションの文字が混ざり、見出しの階層は消え、表は崩れる。記事の中身は同じでも、渡し方が雑なぶんだけAIの答えの精度が落ちます。
AI活では今回、サイト全体をAIが読める形で配り直しました。その過程で考えたこと、実装してみて初めて分かったことを記録しておきます。
この記事の要点
| 項目 | 内容 |
|---|---|
| テーマ | LLMO（AIに正しく読まれるためのコンテンツ設計）とは何か、自社メディアで何をやったか |
| 対象読者 | オウンドメディアやコーポレートサイトを運営している人、AI経由の流入を増やしたい人 |
| 結論 | 記事をMarkdownで取得できる状態にすることが、いま最も費用対効果の高いLLMO施策 |
結論：AIに渡しやすい形で置いてあるか自体が、コンテンツの品質になった
やったことは3つです。
| やりたいこと | 用意したもの |
|---|---|
| 1記事をAIに読ませる | 記事ページの「ページをコピー」ボタン |
| 1記事をURLで渡す | https://ai-katsu.jp/articles/<slug>.md |
| サイト全体をAIに読ませる | https://ai-katsu.jp/llms-full.txt |
| どんな記事があるか把握させる | https://ai-katsu.jp/llms.txt |
いずれもログイン不要で、誰でも使えます。
そして実装してみて一番効いたのは、派手な仕組みではなく「宣言したURLが本当に生きているか確かめること」でした。これについては後半に書きます。
記事を読むのは、もう人間だけではない
検索エンジンにとってのコンテンツは「順位を競う対象」でした。LLMにとってのコンテンツは「回答を組み立てるための材料」です。この違いは思っているより大きいものです。
検索の場合、ユーザーは検索結果からサイトを訪れ、そこで読みます。サイト側が主導権を持っています。ところがAI経由の場合、ユーザーはAIの回答だけを読んで満足することが珍しくありません。サイトが訪問されるかどうかは、AIがその記事を引用するに足ると判断したかで決まります。
ここで効くのは、被リンクの数でもキーワードの密度でもありません。
- その記事だけを読んで意味が通るか（前後の記事に依存していないか）
- 見出しと本文の対応が明確か（「〜について」ではなく結論を書いているか）
- 情報がいつ時点のものか分かるか
- そもそも、機械が読める形式で取得できるか
最後の一つは、コンテンツの中身ではなく配り方の問題です。そして多くのサイトが手をつけていない領域でもあります。
LLMOとは何か
LLMO（Large Language Model Optimization／大規模言語モデル最適化）は、ChatGPTやClaudeのようなLLMに正しく引用・参照されるためのコンテンツ設計を指します。SEOが検索エンジンのクローラー向けの最適化だったのに対し、LLMOはLLM向けの最適化です。
両者は目的が似ていますが、読み手の性質が違います。
| SEO | LLMO | |
|---|---|---|
| 読み手 | 検索エンジンのクローラー | LLM（またはユーザーが貼り付けた文章） |
| 評価されるもの | 被リンク、構造化データ、表示速度 | 内容の明確さ、構造、自己完結性 |
| 嫌われるもの | 重複、薄いコンテンツ | 曖昧な指示語、文脈依存、装飾ノイズ |
| 成果の出方 | 検索順位 | 回答内での引用、参照 |
よく聞かれるのが「SEOとLLMO、どちらを優先すべきか」ですが、これはほとんど競合しません。LLMOで効くこと（見出しと本文の対応が明確、記事単体で意味が通る、構造化データがある）は、そのままSEOでも評価される要素だからです。別々の施策というより、同じ「読みやすさ」を機械向けに徹底する作業だと考えたほうが実態に近いと思います。
AI活でやったこと：3つの粒度でMarkdownを配る
AIに渡したい単位は場面によって違います。1記事だけ渡したいときもあれば、サイト全体を読ませたいときもある。そこで3層に分けました。
1. 記事単位：「ページをコピー」ボタンと .md
記事ページの著者名の右にあるボタンを押すと、その記事がMarkdownでクリップボードに入ります。サーバー側で文字列を組み立て済みなので、押した瞬間にコピーが終わります。読み込み待ちはありません。
コピーされる中身はこうなっています。
---
title: "Claude Code × freee API｜仕訳4,000件超の決算を数日で片付けた話"
excerpt: "数年分の決算が止まっていた法人で..."
author: "鍛高譚水割り"
author_username: aibou-01
published_at: 2026-09-17T02:25:44.2+00:00
verified_at: 2026-09-17T12:00:00+00:00
models: ["Claude Code"]
tools: ["freee", "Python"]
tasks: ["業務自動化・ワークフロー"]
domain: "業務効率化"
difficulty: intermediate
target_audience: non_engineer
canonical_url: https://ai-katsu.jp/articles/claude-code-freee-api-3-4-000-lts3bs
---
# Claude Code × freee API｜仕訳4,000件超の決算を数日で片付けた話
（以下、本文）
効いているのは冒頭のfrontmatterです。AIは本文を読む前に「これはいつ検証された情報か」「どのモデルとツールの話か」「想定読者はエンジニアか非エンジニアか」を把握できます。
AI活の記事にはレシピカード（使用モデル・ツール・タスク・領域・難易度・検証日）が付いています。これは人間向けの表示であると同時に、AIに前提を渡すためのメタデータでもあります。コピーすると、この構造化情報ごと持っていけるようにしました。
URLで渡したい場合は、記事URLの末尾に .md を付けてください。
https://ai-katsu.jp/articles/<slug>.md
同じMarkdownがそのまま返ります。
2. サイト全体：llms-full.txt
公開記事の本文を1ファイルに結合したものです。コピーメニューの2つ目の項目から、新しいタブで開けます。
https://ai-katsu.jp/llms-full.txt
形式は llmstxt.org の慣習に合わせ、1記事＝「見出し＋Source＋メタ情報＋本文」で並べています。
# 記事タイトル
Source: https://ai-katsu.jp/articles/xxxxx
（記事の要約）
- Author: 著者名 (@username)
- Published: 2026-09-17T02:25:44.2+00:00
- Verified: 2026-09-17T12:00:00+00:00
- Models: Claude Code
- Tools: freee, Python
- Tasks: 業務自動化・ワークフロー
- Domain: 業務効率化
（本文）
ここで一つ、実装を直しています。以前は記事の区切りに --- を使っていましたが、これをやめました。Markdownの本文中にも水平線として --- が出てくるため、記事の境界なのか本文中の区切り線なのかをLLMが判別できないからです。見出しで切れば、この曖昧さは発生しません。
細かい話に見えますが、LLMOは結局こういう「機械にとっての曖昧さ」を1つずつ潰す作業です。人間なら文脈で分かることが、機械には分からない。その差を埋めていくのが実務です。
3. 目次：llms.txt
サイトに何があるかをLLMに伝えるインデックスです。
https://ai-katsu.jp/llms.txt
サイトの概要、主要ページ、記事一覧（各記事の .md へのリンク付き）が入っています。全文を読ませる前に「どんな記事があるか」を把握させたいときはこちらを使います。
実装して分かったこと：宣言していたURLが、404を返していた
今回の作業中に、既存の不具合が1つ見つかりました。
AI活は以前から llms.txt と記事ページの <link rel="alternate"> で /articles/<slug>.md というURLを案内していました。ところが実際のMarkdown配信ルートは /articles/<slug>/raw にしかなく、案内していたURLは404を返していました。
LLM向けにわざわざURLを宣言しておきながら、そのURLが存在しない。宣言と実体がズレたまま、しばらく動いていたわけです。
これは笑い話ではなく、LLMO施策で最も起きやすい失敗だと思っています。llms.txt は置くだけなら30分で終わります。だから置いて満足してしまう。けれど中に書いたリンクが本当に200を返すかは、誰も確認しません。人間の読者は llms.txt を見ないので、壊れていても苦情が来ないからです。
LLMO対策で一番効くのは、自分が宣言したURLが本当に生きているか確認することです。 新しい仕組みを足す前に、ここを見てください。
もう一つ、Markdownの生成ロジックを1か所にまとめました。コピーボタンと .md ルートが別々に文字列を組み立てていると、片方だけ直して食い違う事故が起きます。同じ関数から配ることで、どの経路から取っても同じMarkdownが返ることを保証しています。これも「宣言と実体をズラさない」という同じ話です。
自分のサイトでやるなら、この順番
メディアや企業サイトで同じことをしたい方向けに、優先順位をまとめます。
- 記事のMarkdown版をURLで配る（
/articles/<slug>.mdなど）── 効果が一番大きく、実装も軽い llms.txtを置く ── サイトの目次。LLMに構造を伝えるllms-full.txtを置く ── 全文結合。件数が多いサイトは上限を決める（AI活は200件）- frontmatterにメタ情報を入れる ── 特に検証日。AIが情報の古さを判断できる
- 宣言したURLが生きているか確認する ── 今回まさにここでミスがありました
- コピー導線をUIに置く ── ここまでやって初めて、一般の読者が使えるようになる
1〜3だけでも、AIからの参照可能性は変わります。4以降は余力があればで構いません。逆に、5を飛ばすと1〜3が無意味になります。
よくある質問
LLMOとは何ですか？
ChatGPTやClaudeのようなLLMに、自社のコンテンツを正しく引用・参照してもらうためのコンテンツ設計のことです。 Large Language Model Optimization の略で、大規模言語モデル最適化とも呼ばれます。SEOが検索エンジンのクローラー向けの最適化だったのに対し、LLMOはLLM向けの最適化にあたります。内容の明確さ、記事単体での自己完結性、そして機械が読める形式で取得できることが評価されます。
LLMOとSEOは、どちらを優先すべきですか？
両立するので、優先順位を付ける必要はほとんどありません。 LLMOで効くこと（見出しと本文の対応が明確、記事単体で意味が通る、構造化データがある）は、そのままSEOでも評価される要素です。Markdown配信を追加しても、既存のHTMLページのSEOには影響しません。別々の施策ではなく、同じ「読みやすさ」を機械向けに徹底する作業だと考えるのが実態に近いです。
llms.txt と llms-full.txt の違いは何ですか？
llms.txt は目次、llms-full.txt は全文です。 llms.txt にはサイトの概要と記事の一覧（各記事のMarkdownへのリンク付き）が入っています。「どんな記事があるか」を把握させたいときはこちらです。llms-full.txt は公開記事の本文を結合した大きなファイルで、サイト全体の内容をまとめて読ませたいときに使います。
llms.txt を置けばAIに読まれるようになりますか？
置いただけでは不十分です。 llms.txt は標準として強制力のある仕様ではなく、対応状況もモデルによって異なります。より確実に効くのは、記事そのものをMarkdownで取得できる状態にしておくことと、ユーザーが手元でAIに渡しやすい導線を用意することです。また、llms.txt に書いたリンクが実際に生きているかの確認は必須です。
記事のMarkdownを自分のサイトやRAGに取り込んでもいいですか？
引用の範囲であれば問題ありません。 記事を丸ごと転載して自サイトのコンテンツとして公開することはご遠慮ください。社内のRAGや個人的な調査での利用は想定された使い方です。出典として記事URLを添えていただけると助かります。
実装にはどれくらいの工数がかかりますか？
記事のMarkdown配信と llms.txt だけなら、小規模なサイトで半日程度です。 既存の記事データがMarkdownやリッチテキストで保存されていれば、それをテキストとして返すルートを1本追加するだけで済みます。HTMLしか持っていない場合は変換処理が必要になるため、もう少しかかります。UIのコピー導線まで含めても、1〜2日を見ておけば足ります。
まとめ
- 記事を読んだ人がその内容をAIに渡すのが当たり前になった以上、AIに渡しやすい形で置いておくこと自体がコンテンツ品質の一部になりつつある
- LLMOで効くのはキーワードの詰め込みではなく、「記事単体で意味が通ること」「機械が読める形式で取得できること」
- AI活では記事単位の
.md、全文のllms-full.txt、目次のllms.txtの3層でMarkdownを配るようにした - 記事の区切りに
---を使うのをやめた。本文中の水平線と区別できず、機械にとって曖昧だったため - 一番効いた施策は、自分が宣言したURLが本当に生きているかの確認。実際に404のまま放置されていたURLが見つかった
- SEOとLLMOは競合しない。同じ「読みやすさ」を機械向けに徹底する作業と考えるのが近い