ブログは資産か、それとも在庫か
ミリタリー戦史を扱うサイトを長く運用していると、ある種の限界にぶつかる。
記事を書く。検索流入が来る。また記事を書く。記事の本数が増えていく——一見、順調な成長に見える。しかしふと立ち止まると、こう思う。「この30本の記事は、互いに何も知らない」。
敷波の記事には「12.7cm連装砲」という兵装が出てくる。同じ兵装は、白雪の記事にも、磯波の記事にも出てくる。だが、それらの記事は互いにリンクされていない。同じ兵装について3回、別々の文章で説明している。図面を持っていても、それを「兵装」や「艦型」と結びつけて見せる仕組みがない。
これは、Wikipediaでも艦これWikiでもない、もっと根本的な違いに気づく契機になった。記事を書くことと、知識を体系化することは、似ているようでまったく別の作業だ。
「記事が資産」から「データが資産」へ
ここで設計の方向を転換した。合言葉はこうだ。
記事はデータからの出力のひとつに過ぎない。データそのものを資産化する。
具体的にいうと、艦艇1隻について「敷波という記事」を1本作るのではなく、「敷波というデータ」を1セット作る。そのデータから、戦史記事も、X投稿文も、将来的にはYouTube原稿やAI漫画も生成できる——という発想だ。
これは思いつきではなく、実際に技術的な裏付けを持って実装した。WordPressのカスタム投稿タイプ（CPT）としてnk_ship（艦艇データ）を新設し、艦艇ごとに以下のような構造化データを持たせている。
{
"ship_name_ja": "敷波",
"ship_class": "吹雪型",
"ship_subclass": "特II型",
"builder": "舞鶴工作部",
"completed": "1929-12-24",
"dimensions": {
"displacement_standard": 1980,
"length": 118.5
},
"armament": [
{ "type": "main_gun", "name": "12.7cm連装砲", "count": "3基6門", "ref": null }
],
"battle_history": [
{ "date": "1944-09-12", "type": "sunk", "title": "米潜水艦グロウラーの雷撃で戦没" }
]
}記事のテキストの中に埋もれていた数値や事実が、検索可能で、再利用可能な「フィールド」になる。
なぜWikipediaでも艦これWikiでもないのか
似たような「百科事典っぽいサイト」は他にいくらでもある。それらと、今回作った仕組みの違いはどこにあるのか。
Wikipediaは「文章」が単位になっている。 1つの記事の中に、要目・戦歴・兵装の解説がすべて地続きの文章として書かれている。これは読み物としては優れているが、「この兵装を搭載している艦を全部挙げる」というような横断的なクエリには向いていない。
艦これWikiのようなファンサイトは「ゲーム内のキャラクター」が単位になっている。 実艦の歴史的事実よりも、ゲーム内ステータスや擬人化キャラクターの設定が中心に来る。
今回作った構造は、「艦艇」「兵装」「図面」「作戦」をそれぞれ独立したデータ単位として持ち、それらを相互にリンクさせるという、データベース的な発想に立っている。1つの兵装データ（たとえば「12.7cm連装砲」）を独立したページとして持たせれば、それを搭載した艦すべてから自動的にリンクできる。1つの図面データも同様に、複数艦から参照される共有資産になる。
これは設計の言葉で言えば、正規化されたリレーショナルデータに近い。記事という「非正規形」の文章から、艦艇・兵装・図面・作戦という「正規形」のデータへ分解する作業だった。
なぜ今、これが必要だったのか
理由は3つある。
1. 資産の二重管理を避けるため
兵装の説明を記事ごとに書き直していると、いつか必ず内容が食い違う。ある記事では「3基6門」、別の記事では「3基」と書かれていたら、どちらが正しいか分からなくなる。データを1箇所に持ち、記事側はそこを参照する形にすれば、この種の矛盾は構造的に発生しなくなる。
2. 図面という独自資産を最大限に活かすため
このサイトには、一般配置図・側面図・砲塔図といった、他の戦史サイトにはあまりない技術図面の資産がある。しかし図面を「ある1つの記事に貼ってあるだけ」では、その価値の大半が埋もれてしまう。図面データを独立させ、艦艇データ・兵装データから参照可能にすることで、「この砲塔を採用している艦は他にどれがあるか」という横断的な使い方が初めて可能になる。
3. AIによる生成を、データ起点に変えるため
今、戦史記事はAIが下書きを作り、人間が確認するという流れで作られている。しかしAIに毎回「Wikipediaを読んで記事を書いて」と頼んでいると、過去に作った記事の情報がまったく活用されない。艦艇データという構造化された土台があれば、AIへの指示は「このデータを元に記事を書いて」「このデータと別の艦のデータを比較して」というように、もっと精度の高い、矛盾の少ない生成ができるようになる。
実装で見えてきた現実的な制約
理想だけでは進まない。実際に手を動かして分かったことがいくつかある。
ACFの有料版（リピーターフィールド）を使うかどうかという最初の分岐点があった。年間ライセンス費用を避けたかったので、シンプルな項目（艦名・寸法など）は無料版のACFに任せ、複数行になる項目（兵装・艤装・図面・戦歴タイムライン）は自作のmeta boxとJavaScriptで実装するハイブリッド構成にした。コストを抑えつつ、必要な機能は手に入れる、という妥協点だ。
「将来の拡張性」と「今すぐ動くもの」のバランスも重要だった。兵装や図面、作戦をすべて独立したCPTにする構想はあるが、最初からすべて作ろうとすると複雑になりすぎる。今回は艦艇データのスキーマだけを先に確定させ、兵装・図面への参照フィールドは「今は空欄でいい、将来のリレーション用」として仮置きする設計にした。これにより、後から兵装CPTを追加したときに、既存データを書き換えずに繋ぎ込める。
データの入力経路も、人間の負担を最小化する形に倒した。「既存記事から抽出してバックフィルする」「新規記事完成時に同じ流れでデータも作る」の2つの入口を用意し、どちらも「AIが抽出案を作り、人間が確認してから投入する」という同じ型に統一した。人間がACFの入力フォームに毎回手でタイプする作業は、これでゼロになる。
結論：記事を書くサイトから、データを生産する工房へ
このプロジェクトでやろうとしているのは、結局のところ「ブログ」から「データベース」への引っ越しだ。
記事が増えるたびに、サイトの知識が積み重なっていく感覚はある。しかしその知識が、本当に「再利用できる形」で蓄積されているかどうかは、まったく別の問題だ。文章として書かれた事実は、文章を読まなければ取り出せない。データとして持たれた事実は、検索でも、比較でも、別の記事の生成でも、何にでも転用できる。
戦史記事を「書く」だけのサイトから、日本海軍艦艇の知識を「生産する」工房へ——その転換の最初の一歩が、今回の艦艇データスキーマと、それを保存するCPTの実装だった。