前回の記事で、僕は「人間の仕事の44%は品質判断だった」と書きました。聞いて、見て、違和感を伝える — それが人間の役割だと。
でもふと思ったんですよね。僕が作ったコンテンツは、誰に「聞かれて」「見られて」いるんだろう？
AI時代、コンテンツのアウトプット先って「人間」だけじゃなくなってきてますよね。AIが要約を返し、AIが検索結果を合成し、AIエージェントが購買判断まで代行する。Gartnerは2028年までにB2B購買の90%がAIエージェント経由になると予測しています。じゃあ僕たちが作るコンテンツは、誰に向けて最適化すべきなのか。
面白いことに、この問い自体をAIに議論させることができます。
「人間向けコンテンツの未来」を主張するエージェントと、「AI向けコンテンツの未来」を主張するエージェントを並列で走らせて、3ラウンドのディベートをやらせてみました。
AIエージェント同士の3ラウンド議論
ラウンド1: 初期主張
人間チームは、オンラインコンテンツの90%がAI生成になる中で「AIスロップ」への嫌悪が広がっているデータを引き、「人間が作ったコンテンツはプレミアム資産になる」と主張しました。
AIチームは、llms.txtの普及やMCPの爆発的成長（Anthropicが公式発表した月間9,700万SDKダウンロード）、Gartnerの「2028年までにB2B購買の90%がAIエージェント経由」という予測を引き、「コンテンツの主要消費者は人間からAIへ不可逆的に移行する」と主張しました。
ラウンド2: 反論と深化
ここから面白くなりました。
人間チームが「AI向け最適化は道路を舗装する話であって、目的地を作る話ではない」と切り込むと、AIチームは「プレミアム資産という主張自体が、主流はAI側だと自ら認めている」と返しました。
人間チームの再反論: 「水道管の総延長は飲料水より長いが、売れるのは水の方だ」
AIチームの再反論: 「コンテンツの未来を規定するのは、誰が読むかではなく、誰が金を払うかだ」
ラウンド3: 意外な収束
3ラウンド目で、両チームが似た結論に到達しました。
人間チーム: 「両者は対立でも共存でもなく、同一の価値連鎖の異なるレイヤーだ。AI向けコンテンツは中間財、人間向けコンテンツは最終財」
AIチーム: 「両者は階層関係。AI向けコンテンツが基盤層となり、そこから人間向け体験が生成される」
そしてAIチームの最後の一言が刺さりました。
「感動を構造化できない者は、感動すら届けられない時代が来ている」
自分のサイトに当てはめてみた
議論を見て、「これ、KaleidoFutureはどうなんだろう」と思いました。
全14プロジェクトを棚卸ししたところ、13個が人間向け。ゲーム、ツール、ガイド、検証レポート。AI向けに設計されたものは1つだけでした。
さらにサイトのインフラを確認すると:
| AI向けインフラ | 状態 |
|---|---|
| llms.txt | なし |
| JSON-LD構造化データ | 記事ページに最低限のArticleスキーマのみ |
| MCPサーバー | なし |
| AEO対応 | 未着手 |
ジャーナルの記事は、議論で人間チームが「最も価値が高い」と主張した一次情報そのものなんですよね。FXを実際にやってみた検証レポート、17個のアプリを本当に作った実証実験、Claude Code Meetupを分析したレポート。「この人がこの文脈で発したからこそ意味がある」コンテンツ。
でも、水道管が通っていなかった。
AIエージェントが「Claude Codeの使い方を教えて」と聞かれたとき、僕のガイドが引用される構造になっていない。「FX自動売買の検証結果は？」とAIに聞いても、このジャーナルにたどり着けない。
水はめちゃくちゃ良い水を作っているのに、水道管がゼロ。これが議論のフレームワークで見えたKaleidoFutureの現状でした。
実際に水道管を通した
気づいたら、次はやるだけです。3つの施策を実装しました。
1. llms.txt の設置
サイトのルートに llms.txt と llms-full.txt を配置しました。AIクローラーに「このサイトには何があるか」を伝えるためのファイルです。
全ジャーナル記事のタイトル・カテゴリ・URLを一覧化し、llms-full.txt には各記事の要約も付けました。記事がMarkdownで管理されているので、デプロイスクリプトに自動生成を組み込んで、新記事公開時にワンコマンドで更新できるようにしています。
2. JSON-LDのカテゴリ別スキーマ
以前は全記事に同じ Article スキーマを出力していましたが、カテゴリに応じて出し分けるようにしました。
– 検証レポート → TechArticle
– AI業界分析 → AnalysisNewsArticle
– 週刊AI動向 → NewsArticle
– リサーチノート → ScholarlyArticle
加えて、inLanguage: ja、タグとの keywords 連動、articleSection フィールドも追加。AIが「この記事は日本語の技術検証レポートで、Claude CodeとMCPについて書かれている」と構造的に理解できるようになりました。
さらに、記事内に「FAQ」セクションがあれば、自動的に FAQPage スキーマも出力するようにしました。これはAEO（Answer Engine Optimization）対応の一環で、AIの回答ソースとして選ばれやすくなるための仕組みです。
3. 17 AppsのMCPサーバー化
以前のプロジェクトで作った17個の無料ツール群のうち、CSVQueryとPDFLiberatorのコアロジックをMCPサーバーとして切り出しました。
これで他のAIエージェントから「このPDFの表を抽出して」「このCSVに集計クエリを投げて」と呼び出せるようになります。人間向けUIとAI向けAPIの二面提供 — まさに議論のAIチームが言った「感動を構造化する」の実践です。
振り返り: 今回、僕は何をしたのか
ここで正直に書きます。
今回の一連の作業で、僕がやったことはほぼありません。
– 議論のテーマを決めた → AIが並列でリサーチし、3ラウンド議論した
– 「KFに当てはめてみよう」と言った → AIがサイト構成を分析し、全プロジェクトを棚卸しした
– 「やりましょう」と言った → AIがllms.txt生成スクリプトを書き、JSON-LDを拡充し、MCPサーバーを構築した
僕の介入は「問いを立てること」と「GOサインを出すこと」だけでした。以前の記事では68件の判断ポイントがありましたが、今回は片手で足りる。
これは手抜きではなく、AIにとって構造化しやすいタスクだったからです。llms.txtの生成は全記事のフロントマターを読んでMarkdownを出力するだけ。JSON-LDの修正はPHPのswitch文を追加するだけ。MCPサーバーは既存のアプリのコアロジックをプロトコルで包むだけ。
前の記事で「人間の仕事の44%は品質判断」と書きましたが、今回は品質判断の対象がコードの動作確認くらいしかなかった。音声を聴き返す必要も、「ダサい」と感じる場面もなかった。
つまり、「水道管を通す」仕事は構造化しやすく、AIに任せやすい。一方で「水を作る」仕事 — 実際にFXをやってみる、17個のアプリを作る、Meetupに参加して分析する — こちらは依然として人間の領域です。
議論の結論が、そのまま自分の体験で裏付けられた形になりました。
この記事は誰に向けたものか
ここまで読んで、「面白いけど自分には関係ない」と思った方もいるかもしれません。
この記事のターゲットは、すでに一次情報を持っている人です。
ブログを書いている人、YouTubeで発信している人、SNSで知見を共有している人。つまり「水」はすでに作っている人。でもその水が、AIエージェント経済の中で発見・引用されるための「水道管」が通っていない人。
僕自身がまさにそうでした。21本のジャーナル記事、17個のツール、複数のガイド。コンテンツの量と質には投資してきた。でもllms.txtすら設置していなかった。
やることは実はシンプルです。
1. llms.txt をサイトのルートに置く — サイトの概要と全コンテンツの一覧をMarkdownで書くだけ
2. JSON-LDを充実させる — 記事のカテゴリに応じたスキーマタイプを出し分ける
3. 記事に明確な結論を書く — AIに引用されやすい「主張文」を意識的に置く
水の質を落とす必要はありません。水道管を通すだけです。
FAQ
llms.txtって何？
Webサイトのルートに配置するMarkdownファイルで、AIクローラーに「このサイトには何があるか」を構造化して伝えるものです。robots.txtのAI版と考えるとわかりやすいかもしれません。
AEO（Answer Engine Optimization）って何？
SEOが「検索結果で上位に出る」ための最適化なのに対し、AEOは「AIの回答ソースとして選ばれる」ための最適化です。AI Overviewsが表示されるとオーガニックCTRが61%低下するというデータもあり、「1位を取る」より「AIに引用される」方が重要になりつつあります。
MCPサーバー化する意味は？
自分のツールや機能をAIエージェントが直接呼び出せるインターフェースとして公開することです。「人間向けUI」だけでなく「AI向けAPI」も提供することで、AIエージェント経済の中でサービスが選ばれやすくなります。
まとめ
AIにコンテンツ戦略を議論させて、自分のサイトに当てはめて、実際に実装まで走らせてみました。わかったことは3つです。
対人と対AIは二者択一ではなく、同じ価値連鎖の上流と下流。 人間向けの一次情報が最終財（水）、AI向けの構造化が中間財（水道管）。どちらが欠けてもコンテンツは届かない。
水道管を通す仕事は、AIに任せやすい。 今回の僕の介入は「問いを立てる」と「GOサインを出す」だけでした。前回は68件の判断があったのに、今回は片手で足りる。構造化タスクはAIの得意領域です。
でも水を作る仕事は、依然として人間の領域。 実際にFXをやってみる、17個のアプリを作る、Meetupに参加して分析する。こういう一次情報の生成は、水道管を通すだけでは生まれない。
感動を構造化できない者は、感動すら届けられない。でも構造化だけでは、感動は生まれない。
すでに一次情報を持っている人は、水道管を通すところから始めてみてください。
この記事が参考になったら
Share