WordPress CPT+ACF+REST APIで商品管理を刷新した話

WORDPRESS TECHNICAL LOG — 2026

「商品を1件追加するのに、
何分かかっているか？」この問いが、すべてを変えた。

CSVを手作業で編集し、URLをコピーし、FTPでアップロードし、表示を確認し、崩れていたら直す——。
猫工艦のショップページはかつて、その繰り返しで動いていた。
そして今、管理画面で「公開」を押すだけで、コレクションが更新される。

2026年、猫工艦のコレクションページには13のアイテムが並んでいる。
航空自衛隊のF-2戦闘機、護衛艦ひゅうが、戦艦大和、陽炎型駆逐艦・雪風—— それぞれが個別の商品ページを持ち、価格・購入先・カテゴリが整理されて表示されている。カテゴリフィルターで絞り込み、ショップ別に並べ替え、アイテムタイプで検索できる。

この体験を「当然」だと感じるかもしれない。しかし一年前、同じことをやるにはまったく異なるコストがかかっていた。

SECTION 01 — BEFORE

CSVと手作業が支配していた時代

最初のコレクションページは、CSVファイルから生成されていた。
構造はシンプルだ。スプレッドシートに商品名・価格・画像URL・購入先URLの列を作り、それをJavaScriptで読み込んでカードを描画する。エンジニア的には「ありがち」な実装だ。動く。機能する。問題なさそうに見える。

だが、問題は「商品を追加するとき」に噴出した。

T-TRINITYで新しいTシャツを登録する。商品ページが生成されてURLが発行される。そのURLをコピーして、CSVを開いて、新しい行に貼り付けて、画像のURLを確認して、カテゴリを手で入力して、保存して、 FTPでサーバーにアップロードして、ブラウザで確認する。もし表示が崩れていたら、また開いて、また直して、また上げる。

PAIN POINTS — CSV管理の構造的問題

商品の追加・変更に毎回エンジニア作業が必要
1件の追加に15〜30分。ミスがあれば倍
CSVの列ズレ・文字化け・パス誤りで表示が壊れる
T-TRINITYのURL変更があった日には連鎖的に修正が必要
商品が増えるほど管理コストが加速度的に増大する

本質的な問題は「データ」と「コード」が分離されていないことだった。商品情報はCSVという「ファイル」の中に閉じ込められていて、それを扱うにはコードを知っている人間が介在しなければならない。これはブランド運営の速度を、エンジニア作業の速度に縛りつけるということだ。

「商品を増やすたびに、
作業が増える設計だった。」

— スケールしない構造の本質

ブランドの規模が小さいうちはまだ許容できる。だが13アイテムを超え、ショップが複数（T-TRINITY / SUZURI / BASE）になり、アイテムタイプも多様化（Tシャツ・ロングT・マグカップ・バッグ…）していくと、このCSVはもはや「管理ツール」ではなく「負債」になっていた。

BEFORE — CSV時代

手作業の連鎖

CSVを開いて編集
URLを手でコピー
FTPでアップロード
ブラウザで確認・修正
コードを知らないと触れない

商品1件の追加にかかる時間 15〜30分

AFTER — CPT+ACF+REST API

管理画面だけで完結

管理画面を開く
商品情報を入力
「公開」を押す
コレクションページに即反映
コードに一切触れない

商品1件の追加にかかる時間 2〜3分

SECTION 02 — THE TURNING POINT

「商品もコンテンツの一種だ」
——その一行が、設計を変えた

転機は発想の転換から始まった。

WordPressには「投稿（post）」と「固定ページ（page）」という 2つの標準コンテンツタイプがある。記事はpostで書く。「お問い合わせ」「Aboutページ」はpageで作る。これは多くの人が知っている。

では——「Tシャツ」はどちらに近いか？

考えてみると、Tシャツには「タイトル（商品名）」がある。「本文（説明文）」がある。「アイキャッチ（商品画像）」がある。さらに「価格」「購入URL」「カテゴリ（航空機・戦艦…）」「ショッププラットフォーム（ttrinity / suzuri / base）」「アイテムタイプ（Tシャツ / ロングT / マグカップ…）」という 追加の属性を持つ。

これは——「投稿」の構造と完全に一致する。
ならば、「tshirt」という独自の投稿タイプを作ればいい。そしてその追加属性を、カスタムフィールドとして定義すればいい。

CONCEPT — 商品をWordPressのコンテンツとして定義する

WordPressのコンテンツ構造は、どんなデータにも適用できる。
「ブログ記事」だけでなく、「商品」「イベント」「レシピ」「スタッフ」—— 繰り返し登録するものはすべて「投稿タイプ」として定義できる。

重要なのは「WordPressをCMSとして使う」という視点の転換だ。
管理画面がインターフェースになり、データベースがストレージになる。
コードに触れることなく、誰でも商品を追加・編集・削除できるようになる。

この視点が固まった瞬間、設計の方向性が決まった。

① カスタム投稿タイプ（CPT）で「tshirt」という型を定義する。
② Advanced Custom Fields（ACF）で追加属性（価格・URL・プラットフォーム等）をフィールドとして登録する。
③ WordPress REST APIでそのデータをJSON形式で取得し、コレクションページに表示する。

三つの技術の組み合わせ。だが概念的にはシンプルだ。
「管理画面に入力したデータが、そのままページに出てくる。」
それだけのことを、堅牢に実現する構成だ。

CONTINUED

NEXT — SECTION 03 & 04

CPTの定義・ACFのフィールド設計・REST APIとの接続——実装の全貌へ

PART 02 →

商品をCSVで管理していた時代は終わった—— WordPress CPT＋ACF＋REST APIで実現した「管理画面から即時反映」の仕組み