Nalyエンジニアリングノート：予測記事のJSON-LD、サイトマップ、AI引用準備

要約

Nalyの記事プラットフォームでは、JSON-LD、サイトマップ、明示的なリード／メタデータ配線により、各公開予測ノートを編集品質を損なうことなく機械可読な成果物へ変換できる。主張は、発見品質は現在、2つの並行契約に依存しているというものだ。1つはページを読むユーザー向け、もう1つは規格化された情報源、構造化事実、安定した更新シグナルを必要とするクローラーやエージェント向けである。Nalyの目標は、各記事を公開時点（2026年6月23日現在）でインデックス可能、引用可能、時系列的に正確な状態にすることにある。

Naly内での位置づけ

Nalyの技術スタックは、すでにこの流れに適合している。 next@16.0.7 はReact 19.2.1上でサーバーファーストレンダリングを行い、リレーショナルな記事データには@neondatabase/serverless搭載のdrizzle-orm、安定したメディアURLには@vercel/blobを採用している。GEO目標は独立したSEOサブシステムではなく、同一の正規記事モデルから人間と機械の両方に同じ価値を提供する公開パイプラインの一部である。

現在の設計の起点は公開境界である。記事レコードはページマークアップ、メタデータブロック、サイトマップ出力、記事要約の各チャネルで同一シグナルを生成しなければならない。いずれかのチャネルがずれると、同じ記事がGooglebot、AIアシスタント、社内分析で別々に解釈され、一貫性のない挙動を引き起こす。

Nalyではこれらのデータパスが連動している。

Drizzleベースのレコードからの本文とソースグラフ
Nextサーバーコンポーネント経由のページレンダリングとメタデータ
発見制御 sitemap.xml, news-sitemap.xml、および画像メタデータ
回答優先のリードと明示的なソースURL配列による引用準備

技術的な仕組み

Nalyは記事ごとに5つの決定論的な出力を持つ公開契約を実装すべきである。

正規記事モデル各記事は安定したフィールドを公開すべきだ。対象は正規URL、見出し、スタンドファースト／リード、公開日、更新日、著者情報、セクション／トピックタグ、メイン画像URL、ソースURL、言語である。これはGoogleとAI向け解釈の双方の基盤となる。予測コンテンツではソースURLが特に重要で、外部システムが意見と検証可能な入力を分離できるようにする。
使用する generateMetadata app内で page.tsx/layout.tsx によりサーバー専用ロジックを用いることで、可能な限りクロール可能なタグを初期HTMLに含める。Next.jsはこのサーバーサイドモデルをサポートしており、メタデータ取得は生成パス間でメモ化できるため、DB/APIの重複処理を削減できる。高トラフィックページでは、公開時レイテンシを予測可能な範囲に保てる。
JSON-LD注入 NewsArticle を app ページで、 <script type="application/ld+json"> を厳密なJSON-LDオブジェクトとしてレンダリングする。必要に応じてheadline、datePublished、dateModified、author、image、mainEntityOfPage、isPartOfなどの必須フィールドを含める。Next.jsのメタデータガイダンスは構造化表現としてJSON-LDを明示的に推奨しており、コンポーネント内でスクリプトベースの構造化エンティティデータパターンを示している。
ディスカバリーマップ一般サイトマップ1件とニュース特化サイトマップ1件を生成する。Googleドキュメントでは、両者をクロール発見ツールとして扱い、Search Consoleで追跡しやすいようニュースサイトマップを分離して許可している。 loc, lastmod必要に応じて、URL単位で画像拡張・ニュース拡張を含めると、専門的なインデックス処理を補助できる。画像中心コンテンツには専用の出力があると、発見の一貫性を保ちやすい。
回答優先リードの最適化 AIおよび検索向けには、リード段落を人間向けの利便性と機械向けの利便性の両方として扱う。Open Graphのdescriptionと同一の短いリードを、記事URLの本体を保持したまま短文回答面として使用する。これにより、最初に返される1文で人間、ボット、帰属抽出器が整合する一貫したシグナル経路が形成される。

簡潔な公開ワークフローは次のとおり：

記事とソースグラフをDBに永続化する。
1つの正規化されたセレクタからメタデータ、リード、スキーマペイロードを構築する。
ページHTML、JSON-LD、およびサイトマップ行を1つの公開トランザクション群で出力する。
更新時にキャッシュを再検証または無効化する。

文献レビュー

Googleは、構造化データを大規模にページ事実をクローラーが理解するための手段として位置づける一方、適格性は条件付きであり保証ではないと警告している。公式ガイダンスは繰り返しJSON-LDを推奨フォーマットとして示し、準拠かつ代表的で誤誘導的でないマークアップのみがリッチリザルトに現れ得ることを明確にしている。

Googleはまた、サイトマップは発見補助であって保証ではないと明言している。正しくフォーマットされたサイトマップは、規模の大きいサイトや新設サイトでコンテンツを露出しやすくし、画像・ニュースなどコンテンツ固有のヒントを運べるが、インデックス化自体はクローラーの追従と可視性品質に依存する。

スキーマセマンティクスでは、schema.orgのNewsArticleはニュース報道および背景記事向けの専用サブタイプであり、具体的な更新を報じるNaly型の予測・市場分析記事には自然な適合先となる。

プラットフォーム側の観点でもNext.jsのガイダンスは整合している。メタデータはレンダリング時にサーバーで扱うのが最適であり、JSON-LDは構造化記述のための正式な明示的手法としてサポートされている。同じエコシステムは、URLが多数ある場合に適したサイトマップルート規約と生成APIも提供する。

RAG文献では、構造化リンクデータを用いたエージェント検索に関する研究で、Schema.orgやリンク化された表現が検索品質を高める可能性が示されており、特にプレーンテキストを超えるナビゲーション性と併用した場合に効果が高い。別の最近のRAG文脈研究では、フォーマットと文脈の一貫性がグラウンディング動作を実質的に変化させることが報告されている。これらは、記事メタデータの質は見栄えの最適化ではなく、下流消費を実質的に変えることを支持している。

設計トレードオフ

鮮度対キャッシュ安定性：サーバーサイドメタデータは編集時にすぐ更新される必要がある一方、キャッシュされたルート成果物は毎リクエストで振れないようにする。
最小限の妥当マークアップ対完全性：必須フィールド追加で適合性は高まるが、ソースデータ遅延があると過剰モデリングが古いリンクや誤ったリンクを生む。
クローラガイダンス対信頼シグナル：サイトマップを広げれば網羅性は向上するが、価値の低いURLが多すぎると下流のインデックス品質が希釈される。
可読性対機械可読性：リード先行のUXは主軸のまま、同一テキストが下流システムでも忠実に解釈されることが必要。
シンプルさ対将来性：まず必須フィールドと安定した型を厳密に導入し、必要性が実証されたらより豊かなエンティティグラフに進化させる。

失敗モード

構造的無効化：JSON-LDの形式崩れや必須フィールド欠落は、リッチリザルト不適格を引き起こし、AIパース時の信頼感を低下させる。
意味的ドリフト：表示されるリード／記事本文と構造化データが description 乖離すると、システムがNalyコンテンツを信頼性が低いまたは誤導的と判断する可能性がある。
タイムスタンプ不一致： dateModified 遅延は、タイミングが事業上重要な予測記事で古い鮮度動作を発生させる。
サイトマップのエントロピー： lastmod 古い値、過大なサイトマップ、またはrobotsでの経路遮断により、新しいコンテンツがクローラーから隠れることがある。
検証不能な主張の過度な最適化：構造化フィールドに検証不能な断定を含めると、構文が正しくても品質チェックで減点や制約対象になりうる。
バージョンロック不一致：レンダリング経路（キャッシュ済みルートハンドラ＋動的編集）が混在すると、分割されたメタデータと不一致なURLスナップショットが生まれる。

実装ノート

Nalyでは、実務的な展開は段階的かつ決定論的に進めるべきである。

レンダリング変更に先立ち、記事ドメインモデルに必須メタデータスキーマを追加する。
型安全な入力と決定論的な順序を備えた単一のJSON-LD生成関数を追加する。
書き込み時にリード、ソースURL、画像URLを正規化する。
追加 generateMetadata 動的な記事レベルのタグ向けに app/sitemap.ts および app/news-sitemap.ts 明示的な変更ウィンドウを付与する。
発見に実質的な影響がある画像では専用の画像参照を出力する。
JSON-LDの妥当性と構造化データガイドライン準拠をチェックするCIを追加する。
カナリアダッシュボードを追加する。対象はサイトマップ鮮度、スキーマ解析成功率、リードと本文の整合性。

この設計は既存のNalyランタイム要素と整合し、実装を公開時パスのみに限定するため、既存のコンテンツ運用を壊すことなく、信頼・継続率・発見性を高めるというチーム目標に合致する。