Redmineのカスタムフィールド移行でデータを失わない手順 ― 独自項目・選択肢を欠落させずに安全移行する設計と実例

「チケットの基本情報は移行できたのに、長年蓄積した『顧客名』や『リリースバージョン』『不具合原因区分』が消えてしまう」。Redmineのカスタムフィールドが移行先で崩れやすいDB構造（EAVパターン）の仕組みから、移行前に必ずやるべき棚卸しSQL、CSVエクスポート時の罠、そして移行先での安全な保持パターンまでを完全解説します。

「チケットの題名や期日、担当者はきれいに移行できた。 ……でも、業務でいちばん重要だった『顧客名』や『不具合起因』『リリース対象』がきれいさっぱり消えている」

Redmine から新しいタスク管理ツールへ乗り換える際、最もトラブルになりやすく、現場からの突き上げを食らいやすいのが「カスタムフィールド（独自項目）」の移行です。

長年運用されたRedmineほど、標準の項目（トラッカー、ステータス、優先度など）よりも、現場が追加してきたカスタム項目に固有の業務ノウハウや検索条件が蓄積されています。これが欠落したり別の列に混ざってしまうと、移行後に「過去の不具合履歴が検索できない」「どの顧客の案件か分からない」という大混乱を引き起こします。

この記事では、Redmineがカスタム項目を保持する内部データベースの仕組みから、移行前に必ず実行すべき棚卸しSQL、CSVエクスポート時に潜む3つの罠、そして移行先で破綻しないデータモデリングまでを体系的に解説します。

1. なぜカスタム項目は移行で崩れやすいのか？

標準項目（題名や期日など）とカスタム項目では、データベースでの持たれ方がまったく違います。

Redmine の「EAV（Entity-Attribute-Value）パターン」という仕組み

一般的なリレーショナルデータベースでは、テーブルに列（カラム）を追加してデータを保持します。しかしRedmineでは、ユーザーが画面上から自由に項目を増やせるようにするため、EAV（縦持ち）構造を採用しています。

issues テーブル（標準）: チケット番号、題名、期日などの標準カラムのみを持つ（横持ち）。
custom_fields テーブル（定義）: 項目の定義（項目名、型、必須フラグ、選択肢など）を持つ。
custom_values テーブル（値）: 実際のチケットごとの値を「1項目＝1行」のレコードとして縦持ちで保存する。

sql

-- custom_values テーブルの基本構造
customized_type | customized_id (チケットID) | custom_field_id | value
----------------+----------------------------+-----------------+----------------
Issue           | 1001                       | 3 (顧客名)      | 株式会社A商事
Issue           | 1001                       | 7 (原因区分)    | 設計漏れ
Issue           | 1001                       | 7 (原因区分)    | テスト不足

この縦持ち構造こそが、移行時に次の3つの重大な落とし穴を生み出す原因です。

登録不要・ブラウザで1秒体験

この記事で解説している操作感を、デモ画面ですぐ試してみませんか？

メアド登録・クレカ不要。サンプルプロジェクト（カンバン・午前午後ガントチャート・スプリント・Redmine互換UI）が投入された状態で今すぐ触っていただけます。

デモ画面を1秒で開く

2. EAV構造がもたらす3つの技術的落とし穴

① 全データが「文字列（TEXT）」として保存されている

Redmineの custom_values テーブルでは、日付型でも数値型でも真偽値型でも、すべての値が TEXT 型として一括保存されています。

例えば「納品予定日」という日付型フィールドを作っていても、DB上は単なる '2026-10-31' という文字列です。空欄の場合は NULL ではなく空文字 '' が入ることもあります。これをそのまま移行先ツールの「日付型」カラムへ流し込もうとすると、フォーマットの不一致や空文字エラーによってインポート処理が途中でクラッシュします。

② 複数選択リストで「行が分裂」する

不具合の原因などで「複数選択（チェックボックス）」を許可している場合、Redmineは同じチケットIDに対して値の数だけ別々のレコードを INSERT します（上記テーブルの例を参照）。

これをCSVとしてエクスポートするとき、ツールや設定によって次のように挙動が分かれます。

カンマ区切りで1つのセルに結合される（例: "設計漏れ, テスト不足"）
最初の1件だけが出力され、2件目以降が静かに消失する
チケット自体が複数行に重複して出力され、全体のチケット件数が狂う

③ トラッカーやプロジェクトごとの設定差異

同じ「顧客名」というフィールドであっても、Redmineでは「バグ報告トラッカーでは非表示」「機能開発トラッカーでは必須」「一部のサブプロジェクトでは無効化」といった細かな表示制御が可能です。移行先ツールが一律のフィールド構造しか持てない場合、「不要なチケットにまで大量の空欄フィールドが表示される」という画面の肥大化を招きます。

3. ステップ1：移行前に必ず実行する「棚卸しSQL」

移行を成功させる鉄則は、「移行作業に入る前に、実態を数値で把握する」ことです。

Redmineを数年以上運用していると、過去に一度だけ使われて放置された「ゾンビ項目」が必ず大量に眠っています。使われていない項目まで律儀に移行しようとすると、移行先の設計が複雑化して破綻します。

以下のSQLをRedmineのデータベース（PostgreSQL / MySQL）で実行し、カスタム項目の利用実態を洗い出してください。

sql

-- カスタムフィールドごとの利用件数と最終利用日を集計するSQL
SELECT 
  cf.id AS field_id,
  cf.name AS field_name,
  cf.field_format AS data_type,
  cf.is_required,
  COUNT(cv.id) AS total_entries,
  COUNT(DISTINCT cv.customized_id) AS tickets_count,
  MAX(i.updated_on) AS latest_used_at
FROM custom_fields cf
LEFT JOIN custom_values cv 
  ON cf.id = cv.custom_field_id 
  AND cv.customized_type = 'Issue'
  AND cv.value IS NOT NULL 
  AND cv.value != ''
LEFT JOIN issues i 
  ON cv.customized_id = i.id
WHERE cf.type = 'IssueCustomField'
GROUP BY cf.id, cf.name, cf.field_format, cf.is_required
ORDER BY tickets_count DESC;

足切りルールの設定

このSQLの結果をもとに、チーム内で以下の基準を決めて項目を断捨離します。

直近1年以上更新がない項目: 移行先には持っていかず、アーカイブ用DBやスプレッドシートへの退避に留める。
利用率が全チケットの1%未満の項目: チケット本文の末尾にテキスト（【旧顧客名】: A商事）として追記・統合する。
日常的に使われている上位の項目: 移行先で正式なカラムまたはタグとして再設計する。

これを行うだけで、移行対象となるカスタムフィールドの数を30個から5〜8個程度まで絞り込むことができ、移行コストを劇的に削減できます。

4. ステップ2：CSVエクスポート時の3つの罠

棚卸しが終わったらCSVでデータを出力しますが、ここでもRedmine特有の仕様による事故が多発します。

罠1：長文テキスト内の改行とクォートの不整合

「仕様詳細」や「顧客要望メモ」などの長文テキスト型カスタムフィールドには、改行コード（CRLF / LF）やダブルクォート（"）が含まれています。 Redmineの標準エクスポート機能は比較的正しくエスケープしてくれますが、サードパーティ製プラグインやスクリプト経由で出力した場合にエスケープが漏れ、1つのチケットが改行の場所で途切れ、後続の行が全滅する事故が多発します。

対策: エクスポートしたCSVをテキストエディタで開き、行数とRedmine上のチケット総数が一致しているか必ず確認してください。

罠2：複数選択値のカンマと、選択肢文字列自体のカンマ衝突

選択肢の中にカンマが含まれている場合（例: "Ver 1.0, Build 202"）、複数選択のデリミタ（カンマ）と衝突してパースが狂います。

対策: 移行前のRedmine管理画面で、選択肢の中にカンマ（,）が含まれていないか事前に確認し、必要に応じて全角カンマ（，）やスラッシュ（/）へ置換しておきます。

罠3：ユーザー名・バージョン項目のID表記

「担当者」以外のカスタムフィールドとして「承認者」や「検証者」といったユーザー選択フィールドを設けている場合、CSVエクスポート時に「表示名（田中太郎）」が出るのか「ユーザーID（14）」が出るのかを確認してください。移行先ツールでユーザーを自動紐付けするためには、IDではなく「メールアドレス」または「正確な表示名」が必要です。

5. ステップ3：移行先での受け皿設計（3つのアプローチ）

移行先ツールでカスタム項目をどう受け止めるべきか。すべての項目を「専用カラム」として定義するのはアンチパターンです。以下の3つのアプローチで分類します。

アプローチ	適した項目例	特徴・メリット
A. 専用カラムへの昇格	顧客名、リリース日、完了予定日	頻繁に検索・並び替え（ソート）を行い、一覧画面で常に見たい重要項目。
B. タグ（Labels）への変換	不具合原因、影響機能、OS・環境名	カンバンボードのバッジ表示や、ワンクリックでの絞り込みフィルターとして威力を発揮。
C. JSONB / 補足属性での保持	旧チケット番号、外部連携ID、過去ログ	普段の入力では邪魔にならず、必要なときだけ参照できる柔軟なメタデータ。

とくに選択肢（リスト）形式のカスタムフィールドは、「タグ」に変換するのが現代のタスク管理ツールでは最も扱いやすい方法です。カンバン上での色分けや、複数タグによる多角的な絞り込みが自然に行えるようになります。

6. Taski（タスキ）でのカスタムフィールド移行設計

国産タスク管理ツール Taski では、Redmineからの移行におけるこうした苦痛をゼロにするため、CSVインポーターを独自に最適化しています。

ドラッグ＆ドロップで自動列判定:
Redmineから出力したCSVを取り込むだけで、標準項目（題名、開始日、期日、担当者）とカスタム項目を自動判別します。
選択肢項目をスマートにタグへ自動変換:
Redmineで複数選択されていた原因区分や環境情報を、チケットの「タグ」として自動生成・付与。移行直後からカラーバッジ付きの直感的なカンバンで運用を開始できます。
登録不要のブラウザ完結デモ:
会社の機密情報を含む本番CSVを取り込む前に、まずはダミーデータやサンプルCSVで「正しくカラムがマッピングされるか」を1秒で検証可能です。