はじめに

長い技術資料が複数あると、個々のPDFを要約するだけでは資料間の関係が見えません。

そこで、PostgreSQLエンタープライズ・コンソーシアム（PGECons）の移行ワーキンググループ（WG2）が公開している4資料、合計155ページを、CodexでMarkdownのwikiへ整理してみました。

複数資料を横断して知識を整理し、質問への回答と修正結果をwikiへ蓄積できました。一方で、照合した範囲ではLLMの推測が1箇所含まれており、人による確認は必要でした。

この記事では、次の点を検証します。

複数の長い技術資料をLLM Wikiへ整理すると、根拠を追跡できる横断回答を作れるのか。

主題はPostgreSQL移行の解説ではなく、LLM Wikiの検証です。
PGECons WG2資料は、横断整理と出典管理を試す題材として使わせていただきました。

LLM Wikiとは

LLM Wikiは、Andrej Karpathy氏のgistで紹介されている考え方です。

LLM Wiki by Andrej Karpathy

本記事では、LLMが元資料を資料別ページと横断ページへ整理し、質問や修正の成果を再び蓄積するMarkdownリポジトリをLLM Wikiと呼びます。

PDF
  ↓ ingest
資料別ページ・横断ハブ
  ↓ query
根拠付きの横断回答
  ↓ 人による照合・修正
wikiへ再統合
  ↓ lint
リンク・索引・構造を点検

検証条件

次の3点を確認します。

複数資料をまたいで回答できるか
回答から元PDFのページへ戻れるか
資料の記述とLLMの解釈を区別できるか

検証用の質問は次の3問です。

PostgreSQL移行時の主要な課題は何か
移行方式ごとの注意点は何か
複数資料に共通する推奨事項は何か

使用した資料

資料	内容	ページ数
移行ガイドブック	移行作業の全体像	44
DB移行開発見積り編	棚卸し、影響度、コスト	26
スキーマ移行調査編	DDLやDBオブジェクトの差異	25
データ移行調査および実践編	データの抽出、変換、投入	60
合計		155

各PDF内でCC BYまたはCC BY 2.1 日本の表記を確認しました。原文は転載せず、要約に資料名、版、参照ページを残します。

これらは作成当時のPostgreSQLや移行ツールを前提とする資料です。以下の結果はLLM Wikiの検証用であり、現在の製品仕様を示すものではありません。

実行環境はCodex CLI 0.146.0、pdfinfo／pdftotext 24.02.0です。

検証手順

1. 雛形を作る

最初の指示はこれだけです。

以下のgistを参考に、このディレクトリにLLM Wikiの雛形を作って。

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

raw/、wiki/、索引、ログ、テンプレートと、運用規約を記したAGENTS.mdが作られました。

2. 題材を伝える

- PostgreSQLへのデータベース移行に関する情報を整理したい

これにより、移行情報を整理するルールと横断ハブの雛形が追加されました。

3. PDFを取得する

PGECons WG2の次の4資料をダウンロードして、raw/ に配置して。

- 移行ガイドブック
- DB移行開発見積り編
- スキーマ移行調査編
- データ移行調査および実践編

版、ページ数、ライセンス表記も確認して。

版、改訂日、ページ数、ライセンス、URL、SHA-256はraw/README.mdへ記録されました。

4. wikiへ取り込む

取得したデータをもとにwikiを更新して。

Codexは資料別ページ4件と、工程別の横断ハブを作りました。

資料別ページには、対象バージョン、要点、参照ページ、不確実性が記録されています。

質問への回答はwiki内の記述から作成し、そこに記録された資料名とページ番号を示してもらいます。元PDFは、回答後に内容の妥当性を照合するために使います。

3つの質問を試す

質問1：主要な課題

PostgreSQL移行時の主要な課題は何か。
wikiに入っている4資料だけを使い、根拠となる資料名とページ番号も示して。

代表的な課題	根拠
移行範囲・実現可能性・工数	『移行ガイドブック』PDF pp.10–12／『DB移行開発見積り編』PDF p.8
スキーマ非互換と自動変換	『スキーマ移行調査編』PDF pp.5–23
アプリケーションへの波及	『移行ガイドブック』PDF pp.25–32
データ変換の一貫性	『データ移行調査および実践編』PDF pp.8–44
移行結果と移行後運用	同PDF pp.45–47, 53–57／『移行ガイドブック』PDF pp.36–43

元PDFと照合し、参照ページに根拠があることを確認しました。

質問2：方式ごとの注意点

移行方式ごとの注意点は何か。
何を対象にした方式なのかを明示し、4資料だけを使って整理して。
根拠となる資料名とページ番号も示して。

対象・方式	注意点	根拠
スキーマ：手作業とOra2Pg	生成DDLも確認・修正する	『移行ガイドブック』PDF pp.22–24／『スキーマ移行調査編』PDF pp.5–23
非対応機能：別機能で代替	アプリケーションへの影響も確認する	『DB移行開発見積り編』PDF pp.20–22／『スキーマ移行調査編』PDF p.19
データ抽出・変換：中間ファイル	NULL、文字コード、型、日時書式を一体で設計する	『データ移行調査および実践編』PDF pp.16–40
データ投入：COPY／psql	入力形式、エラー処理、制約・索引の順序を検討する	同PDF pp.41–47
データ投入：pg_bulkload	性能だけでなく制御ファイルの準備工数も考慮する	同PDF pp.54, 58

元PDFとの照合では、LLMの推測が1箇所見つかったため、原資料に沿った表現へ修正しました。

質問3：共通する推奨事項

複数資料に共通する推奨事項は何か。
2資料以上に根拠があるものだけを対象にして、資料名とページ番号を示して。

共通した推奨事項	根拠
対象を棚卸しし、移行可否と影響範囲を評価する	『移行ガイドブック』PDF pp.10–12, 21／『DB移行開発見積り編』PDF p.8
移行ツールの出力を確認し、必要に応じて修正する	『移行ガイドブック』PDF pp.22–24／『スキーマ移行調査編』PDF pp.7–9
データ移行を抽出、変換、投入、確認まで一体で設計する	『移行ガイドブック』PDF pp.32–35／『データ移行調査および実践編』PDF pp.8–47

ここでは、資料に直接書かれた推奨と、複数資料からの解釈を分ける必要がありました。

質問結果をwikiへ戻す

照合済みの回答を、主要課題、移行方式、共通推奨事項の3ページとしてwikiへ戻しました。

最後にテンプレートを除く全8ページをlintし、索引、相対リンク、frontmatter、重複、相互参照を確認しました。リンク切れや索引漏れはありませんでした。

これでingest、query、人による照合、再統合、lintまでを一巡できました。

結果

評価項目	結果
複数資料をまたいだ回答	できた
元PDFページへの追跡	できた
資料記述とLLM解釈の区別	おおむねできた
根拠の妥当性の自動保証	できなかった

まとめ

LLM Wikiは、根拠の妥当性を自動で保証するものではありません。一方で、回答を元資料へたどり、人が修正した知識を再びwikiへ戻せます。

今回確認できた最大の価値は、質問と修正を繰り返しながら、技術資料の知識構造を育てられることでした。