はじめに
長い技術資料が複数あると、個々の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が元資料を資料別ページと横断ページへ整理し、質問や修正の成果を再び蓄積する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へ戻せます。
今回確認できた最大の価値は、質問と修正を繰り返しながら、技術資料の知識構造を育てられることでした。