運用中のヘッドレス CMS のフィールドを触るのは、正直怖い作業です。
フィールドの削除はデータベースの列削除に直結するので、操作ひとつでコンテンツデータが消える 可能性があります。
先日、まさに運用中の Directus でフィールドの整理（不要な項目の非表示化・命名の見直し・不要フィールドの削除）を行い、データを一切壊さずに完了 できたので、そのとき守った手順を紹介します。
同じようにヘッドレス CMS の運用で「触るのが怖い」と感じている方の糧にしていただけたら幸いです。
本記事は 2026 年 6 月時点の Directus で確認した内容です。スキーマ操作の挙動はバージョンによって変わる可能性があるので、必ずご自身の環境でも確認してください。
Directus のフィールド操作は「DB スキーマ操作」である
Directus は、データベースのテーブル・列をそのまま管理画面に映し出す思想の ヘッドレス CMS です。
つまり、管理画面でのフィールド操作は データベースのスキーマ操作に直結 します。
| 管理画面での操作 | データベースで起きること | 可逆性 |
|---|---|---|
| フィールドを隠す（hidden / conditions） | 何も起きない（表示の設定だけ） | ✅ いつでも戻せる |
| フィールドを追加する | 列が追加される | ✅ ほぼ安全 |
| フィールド名（キー）を変えたい | 列の作り直しに相当 | ⚠️ 危険 |
| フィールドを削除する | 列ごとデータが消える | ❌ 不可逆 |
ポイントは、操作によって 可逆性がまったく違う ことです。
この表を意識して、「可逆的な操作から始めて、不可逆な操作は確認が取れてから」という順番で作業します。
今回題材にしたい状況
私が関わっているプロジェクトでは、1 つの記事コレクションをテンプレート（記事の種類）によってフィールドを出し分けて運用しています。
その中で、3 つの整理が必要になりました。
- あるテンプレートに 不要なフィールドが表示されている
- あるフィールドの名前が 用途に対して狭すぎる（特定用途専用のような名前だが、汎用的に使いたい）
- その結果、使われなくなるフィールドが出る
雑にやるなら「フィールドを消して、リネームして、終わり」です。
ですが運用中の CMS でそれをやると、入稿済みのコンテンツデータが巻き添えで消える リスクがあります。
そこで、データに触れない操作から順番に 進めることにしました。
この記事で伝えたいこと
運用中の CMS でフィールドを整理するときの原則は、これに尽きます。
可逆的な操作から始めて、不可逆な操作は「使われていない」ことを確認できてから。
具体的には、次の 3 ステップで進めます。
- まず「隠す」（データ無傷・いつでも戻せる）
- リネームせず「新フィールドを併存」させる（古いデータを残したまま移行）
- 削除は「利用箇所ゼロ」を確認してから（不可逆な操作は最後）
手順① 削除ではなく、まず「隠す」
「このテンプレートではこのフィールドは不要」というとき、最初に検討すべきは削除ではなく 非表示 です。
Directus には conditions（条件付き表示）という機能があり、他のフィールドの値に応じて hidden / readonly / required を切り替え られます。
{
"name": "非表示",
"rule": {
"template": { "_eq": "sample" }
},
"hidden": true
}
これは 表示レイヤーだけの変更 で、データベースには一切触れません。
「間違って隠しすぎた」となっても、設定を戻せば元通りです。
conditions を組み合わせるとき1 つの condition の rule 内に条件を複数書くと AND、condition 自体を分けて追加すると OR 的 に効きます。
「テンプレート A でも B でも隠したい」ときに rule へ条件を足すと AND になってどちらにも効かなくなるので、condition を分けましょう。
「不要に見えるフィールド」が本当に不要かは、この時点では確定していません。
隠した状態でしばらく運用して、誰も困らないことを確かめる ことが、削除の前の安全確認を兼ねます。
手順② リネームせず、新フィールドを「併存」させる
次に、フィールド名の見直しです。
注意したいのは、Directus では フィールドのキー（DB の列名に対応する識別子）を後から変更できない ことです。
表示名（ラベル）は安全に変えられますが、キーを変えたければ実質「作り直し」になります。
ここで「古いフィールドを消して、新しい名前で作り直す」と一気にやると、古いフィールドに入っていたデータが消えます。
そこで取ったのは 併存 です。
1. 汎用的な名前で新フィールドを作成（列の追加 = 安全な操作）
2. 管理画面上は同じフィールドグループに配置（編集者からは自然に見える）
3. 古いフィールドはそのまま残す（データも残る）
この時点で、新旧のフィールドが両方存在する状態になりますが、データは何も失われていません。
古いフィールドの削除は、次の手順③で「消してよい」と確認できてからです。
手順③ 削除は「利用箇所ゼロ」を確認してから
最後に、不要になったフィールドの削除です。ここだけが 不可逆な操作 なので、いちばん慎重にやります。
ヘッドレス CMS のフィールドが「使われているか」は、CMS 側だけ見ていても分かりません。
利用者はフロントエンドのコードだからです。削除の前に、コードベースを検索します。
# フィールド名（キー）でフロントエンドのコードを検索
grep -r "old_field_name" ./src
確認する観点は次のとおりです。
- フロントエンドのコードでフィールド名を参照している箇所はないか
- API レスポンスの型定義（zod スキーマや TypeScript 型）に含まれていないか
- 入稿済みデータでそのフィールドに値が入っているレコードはないか
今回は検索の結果、コード側での利用がゼロであることを確認できたので、ここで初めて削除を実行しました。
「たぶん使ってない」ではなく「検索して利用ゼロを確認した」 という状態を作ってから消すのが肝心です。
コードを検索しても、外部連携（他システムが API 経由でそのフィールドを読んでいる等）までは分かりません。
外部にデータを提供している CMS の場合は、利用先のチームへの確認も削除前のチェックリストに入れてください。
まとめ
操作の可逆性と実行順序
今回の作業を「可逆性」の観点で並べ直すと、こうなります。
| 順序 | 操作 | データへの影響 | 可逆性 |
|---|---|---|---|
| 1 | conditions で隠す | なし（表示のみ） | ✅ いつでも戻せる |
| 2 | 新フィールドを追加して併存 | 列の追加のみ | ✅ ほぼ安全 |
| 3 | 利用箇所を検索して確認 | なし（読むだけ） | ✅ 安全 |
| 4 | 古いフィールドを削除 | 列ごと消える | ❌ 不可逆 |
不可逆な操作（削除）が 一番最後の 1 回だけ になっているのがポイントです。
途中のどの段階で「やっぱりやめた」となっても、データは無傷のまま引き返せます。
これはフィールド整理に限らず、運用中のシステムに変更を加えるときの一般的な原則 だと思っています。
「destructive な操作を後ろに寄せて、その前に可逆的な確認ステップを積む」— データベースのマイグレーションでも、ファイル操作でも、同じ考え方が通用します。
本記事の要点は下記のとおりです。
- Directus のフィールド操作は DB スキーマ操作に直結 する。削除 = 列ごとデータ消失（不可逆）
- 不要なフィールドは、まず conditions で隠す（データ無傷・可逆）
- フィールドキーはリネームできないので、新フィールドを併存 させて移行する（古いデータは残る）
- 削除は コードの利用箇所を検索して「ゼロ」を確認 できてから。外部連携があるなら利用先にも確認
- 原則は「可逆的な操作から始めて、不可逆な操作は最後に 1 回だけ」
運用中の CMS を触る怖さは、手順の設計でほとんど消せます。
「消す前に隠す、作り直す前に併存させる」ぜひフィールド整理の参考にしてみてください！