Nalyエンジニアリングノート：継続的で監査可能な公開のためのソースファーストRAG記事ドラフティング

TL;DR検索拡張生成（RAG）は、Nalyの記事パイプラインを、モデルの記憶からの作文ではなく、ソースに根ざした公開システムへと変える。すべての下書きリクエストはまずWebとarXivの証拠を収集し、ソースURLを正規化して永続化し、その後モデルにanswer-firstドラフトと最終HTML記事の生成を依頼する。これによりリスクは「モデルが幻覚を起こすかどうか」から「取得レイヤーが完全で追跡可能かどうか」へ移り、編集者は安定した成果物、再実行可能なジョブ、そして防衛可能な公開主張を得られる。

要約

NalyにおけるRAGは次の原則で設計すべきである ソースの永続化と決定論的契約。2026年6月27日、実運用での信頼性は、より大きなモデルよりも、取得アーティファクトが照会可能で、バージョン管理され、公開前に検証されているかにより決まる。この記事では、取得・保存用のevidence planeと、ドラフティング用のgeneration planeという二層設計を提案し、このアーキテクチャが編集信頼性とインシデント対応をどのように直接改善するかを論じる。

Naly内の位置づけ

NalyはこれをNext.js 16.0.7 App Routerスタック（next + react）内の本番コンテンツサブシステムとして実行しており、記事公開は別途のオフライン執筆ステップではなく実行時コードパスの一部である。記事ジョブの経路こそが制約を強制する場所であり、ソースレコードが存在し、要約構造が検証され、HTMLが具現化されるまで、ジョブは「書き込まれた」と見なされない。

スタック整合性は意図的に設計されている。

next@16.0.7 + React Server Componentsはサーバー側でジョブ起点レンダリングをホストし、記事のサーバーサイド出力契約と一致させる。
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 型付きの永続ジョブテーブルとソーステーブルを定義し、あらゆる主張を追跡可能にする。
ai@6.0.0-beta.105 生成時にスキーマ認識の出力制御を提供する。
marked@17.0.1 生成済みのMarkdown要約を公開向けにレンダリング済みHTMLへ変換する。
@vercel/blob@2.0.0 生成アセットを再利用可能な永続URLとして保存する。
Anthropicのツールは同一契約の中で代替モデル提供者として追加可能だが、構造化制約から逃げるための抜け道としては使わない。

これは「生成して校正する」モデルを、次のモデルに置き換える。 根拠に基づく作成ループ：取得、検証、生成、レンダリング、公開の各段階がすべて通過して初めて記事が表示される。

技術的な仕組み

堅牢なNaly設計は5つの境界付きステージで構成される。

証拠計画とクエリオーケストレーション

トピック、日付窓、証拠ポリシーを含むジョブ仕様を定義する。
一次ソースに対してWeb検索とarXiv検索の両方を実行する。
正規URLで重複を除去し、プロトコル、ホスト、クエリ文字列を正規化する。

ソース永続化レイヤー

URL単位でメタデータを保存する（url、正規化されたURL、取得ステータス、取得タイムスタンプ、タイトル、抜粋、ソース種別）。
モデル入力用スニペットを生データから分離して保存し、上流ページが変化しても再実行が決定論的に再現可能になるようにする。
ソースごとのチェックサムを追加してドリフトを検知する。

コンテキスト形成と制約

関連性と新しさの順で取得コンテキストを構築する。
プロンプト契約に明示的なソースIDを必須化する。
回答優先の出力形式を強制する（intro claim, evidence bullets, risk caveats, uncertainty）、および順序付きのソース参照。

厳密なスキーマを用いた構造化生成

構造化出力を使い、形式不備やスキーマ違反の応答は即時失敗させ、より厳密なコンテキストで再試行する。
生成はサーバーコンテキスト内で実施し、対応するソースIDなしで事実を主張する下書きは拒否する。

レンダリング、公開、検証

検証済みMarkdownをHTMLに変換し、MarkdownとHTMLの両方を永続化する。
検証成功後のみ最終成果物をキャッシュする。
運用指標と監査フィールドを出力する：ソース数、却下された主張数、再試行回数、生成レイテンシ。

最も重要な設計変更は 関心の分離である。取得品質と生成品質は異なる障害領域であり、評価指標も異なる。Next.js Server Componentsはこの分離に適している。理由は、レンダリングを決定論的に保ちながら、取得と生成を制御された非同期タスクで実行できるからである。

文献の示すところ

最新のRAG文献はこのアーキテクチャ・パターンを支持している。2024年のRAGアーキテクチャ調査は、取得拡張システムが外部証拠に基づいて生成を条件付けることで事実ドリフトを減らす一方、パイプラインの複雑性とモジュール間調整にトレードオフがあることを示している [Gupta et al., 2024]。2025年の追補調査では、堅牢性は現在、生成品質だけでなく適応的取得、デコード制御、エンドツーエンド評価に依存することを追加で指摘している [Sharma, 2025]。

本番の品質管理に関しては、2025年の評価重視調査で、評価を内部のretriever/generator指標と外部システム指標に明確に分割している。この分解は、言語品質が高くても「誤ったソース選択」が“bad article”を生む可能性がある記事パイプラインでは特に有用である [Gan et al., 2025]。Groundedness固有の研究は、取得コンテキストとNLI的チェックを用いた主張サポート分類へ向かっており、生成後検証の実務的価値を補強している [Gerner et al., 2025]。

要するに、これらの論文は一つの論旨に収束している。RAGは単なる文脈注入手段ではなく、 取得と生成の間を結ぶエンジニアリング契約 である。したがってNalyは、プロンプトだけではなく、この契約自体を最適化すべきである。

設計トレードオフ

鮮度と決定論性：厳密なTTLは陳腐化を減らすが再取得コストを増やす。スナップショットを永続化すれば、鮮度ウィンドウを再検証しながらも決定論的レンダリングを維持できる。
取得の再現率対精度：広い取得範囲はカバレッジを上げるがノイズも増やす。第2段階の関連性フィルタが主張品質を保護する。
スキーマ厳密性対文章の流暢性：厳密な出力スキーマは機械的信頼性を高めるが、文体の自由度を下げることがある。answer-firstスキーマは可読性を保ちながらガードレールを維持する。
静的レンダリング速度対監査可能性：事前レンダリングHTMLは配信性能を改善し計算の再実行を減らすが、使用するソースアセットが不変参照である場合に限る。
複雑さ対運用コスト：追加される検証工程（ソースチェック、スキーマチェック、アーティファクト永続化）ごとにレイテンシが増える。Nextの本番ガイダンスに従ったキャッシュ戦略、ルート境界、ビルド時検証が運用可能性を保つ上で重要である。

失敗モード

ソースドリフト：ジョブ作成後にURLが404やソフトチェンジを返す。対策：正規キー＋スナップショットハッシュ＋フォールバックソース連鎖。
取得の過剰展開：精度より再現率が高すぎると、妥当性の薄い推測的要約が増える。対策：証拠優先の制約を要求し、ソース一致のない主張をブロックする。
モデルのフォーマット失敗：生成時のスキーマ不一致やJSONトランケート。対策：厳密なスキーマ検証と、削減されたコンテキストでの再試行。
二重公開競合：同時ワーカーが部分的なアーティファクトを公開する可能性。対策：ジョブの冪等性キー、行レベルの状態遷移（pending -> drafting -> validated -> published）。
レンダリングの後退：不正なMarkdownや危険なHTML変換。対策：決定論的 marked 変換パスとサンプルマニフェストに紐づくHTML出力テスト。
キャッシュの錯覚：サーバー出力の動的データが古いと、公開済みテキストとソースインデックスが同期しなくなる。対策：証拠鮮度が必要な場合は、実行時鮮度方針に合致したルートレンダリング戦略を採用し、暗黙のキャッシュを避ける。

実装ノート

実際のロールアウトでは、これを公開契約として扱うべきである。

Drizzleでソーステーブルを明示的制約付きで定義する：正規化されたホスト/パスによるURL一意性、取得ステータス列挙、チェックサム列。
サーバーレス実行動作に合わせてNeon互換のドライバーパスを一貫して使用する。 neon-* Drizzleのドキュメントにはランタイム固有とドライバーオプションの両方が説明されている。
生成時には構造化出力契約を強制し、レンダリング前に無効なオブジェクトは失敗させる。
Next.jsの本番ガイダンスに従って、サーバー境界、エラーページ、キャッシュ、記事ルートのSEOメタデータを最適化し、公開の可視性と速度を維持する。
生成済みblob（例：表紙画像、添付ファイル、エクスポート）をVercel Blobで明示的なアクセス方針と決定論的命名を使って保存し、重複を防止する。
公開前に運用チェックを発行する：最低ソース数、最低ソース多様性、証拠鮮度、マッピング済み主張の最低完了率。

これは重要な転換点である。記事はもはやモデルの巧みさで評価されるのではなく、再試行や再デプロイ時でも証拠と生成が同期しているかで評価される。