表計算にあった過去依頼を、日付・文字化けの誤りごと移行計画にする

原稿の管理表（13項目：記事ID・カテゴリ・要件ID・先に読むと理解しやすい記事・成果物パス・対象ツール・検証状況・最終更新日など）

管理項目	内容
記事ID	10-02
主な中カテゴリ	10-02 既存データの移行を準備する
関連中カテゴリ	05-01、00-02、01-02、11-02、10-04
関連要件ID	REQ-001、REQ-005
先に読むと理解しやすい記事	05-01（データ項目と関係を決める）、00-02（ファイル・コード・データを区別する）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	変換、件数・内容の照合、やり直し、移行前後の整合性を確認する手順を説明できる
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/10-02-migration-plan_template.md、templates/10-02-migration-plan_example.md、examples/10-02-migration-plan/（migrate.js、run.js、old_requests.csv）、evidence_public/phase5b2c2-2026-09-21/10-02/run_log.md
出典	第11節参照
対象ツール・バージョン	教材演習用にNode.js v24.18.0（node:fs、node:pathのみ使用）
検証状況	演習コードは examples/10-02-migration-plan/ を正本とし、Claude Codeが2026-09-21にローカルで実際に実行して stdout・stderr・終了コードを記録済み（第6〜7節、evidence_public/phase5b2c2-2026-09-21/10-02/run_log.md）。第5節のコードは正本からの抜粋（一字一句同じ）。実際の過去データの移行は未実施。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成）。2026-09-21（Phase 5B-2C2：コード・演習データ・実行結果は不変。第5節の抜粋を正本と一字一句一致させ「抜粋」と明記、移行前に判断すること（第4節）・変換後の照合の読み方・失敗時のやり直し・移行後の状態の扱い（第5.4節・第8.3節）を補い、実行記録を evidence に追加。読む順路・POINT・CHECKLIST・記事間の参照を追加）

この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。本文の移行データ（old_requests.csv）は説明用に作成した架空のものであり、実在する過去の依頼ではありません。本文のコードはこの記事の作成時に実際にローカルで実行して確認したものです（第7節）。

この記事は何の話か。表計算（CSV）にあった架空の過去依頼を、アプリのデータ項目（05-01）へ変換する移行計画を作り、件数・内容の照合、日付・文字化けの誤りへの対処、やり直し手順をまとめる話です。

なぜ必要か。新しいアプリを使い始めるとき、それまでメールや表計算で管理していた依頼を、そのまま失ってよいとは限りません。過去のデータを正しく持ち越すための計画と、持ち越せたかどうかを確認する方法が必要です。

この記事を読むとできるようになること。

• 変換、件数・内容の照合、やり直し、移行前後の整合性を確認する手順を説明できる
• 過去データを移行する範囲を業務上の必要性と照合の手間から判断できる
• 実際に変換処理を作り、日付・文字化けの誤りを検出して記録できる
• 移行後のデータの状態（移行時点の仮定）を、実際の業務の状態と混同せずに扱える

読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。

• 基本だけ理解する：第1節→第3節（変換・照合・やり直しの3段階）→第4節（移行前に判断すること）→第5.1節（架空の過去データ）→第6節の実行結果の表→第9節。コードを読まなくても、何を照合し、変換できなかったデータをどう扱うかが分かります。
• 作って確かめる：上に加えて第5.2〜5.3節（変換・照合コードの抜粋）→第5.4節（演習の設計：実行前に見るもの・結果の読み方・失敗したとき・元に戻せるか）→第6節の実行結果→第7節（確かめたこと・確かめていないこと）。
• 設計判断を深める：上に加えて第8節（移行する範囲、やり直し手順、移行後の状態の扱い）。

1. 今回の業務課題と完成するもの

この記事でやることは、表計算（CSV）にあった架空の過去依頼を、05-01で決めたデータ項目へ変換する処理を作り、件数と内容の照合表、変換できなかったデータのやり直し手順、移行しないデータの範囲を移行計画にまとめることです。

05-01ではこれから使うデータの形を決めましたが、それ以前にあった過去のデータをどう持ち越すかはまだ扱っていませんでした。この記事では、それを扱います。

この記事を読み終えると、次のものが手元にできます。

• 変換・照合コード（examples/10-02-migration-plan/）
• 移行計画・照合表（対象、変換ルール、件数照合、内容照合、やり直し手順、移行しないデータ）

2. 前提知識と読む順路

この記事で使う言葉を先に説明します。

移行

一言でいうと、それまで別の場所（表計算、メールなど）にあったデータを、新しいアプリで使える形に変換して持ち込むことです。

照合

一言でいうと、変換する前と後で、件数や内容が対応しているかを確認することです。件数だけでなく、内容（依頼者名や件名など）も確認します。

文字化け

一言でいうと、文字の符号化（文字コード）が正しく扱われず、意図しない文字になってしまうことです。この記事では、置換文字（読み取れない文字の代わりに表示される記号）が含まれる場合を、文字化けの疑いとして扱います。

これがないと、過去のデータを新しいアプリに移した後で、件数が合わない、内容が壊れているといった問題に、利用が始まってから気づくことになります。

読む順路：データ項目は05-01、ファイル・データの区別は00-02、既存データの所在は01-02が該当します。この記事の移行計画と出力（migrated_requests.json）は、11-01（公開前チェックの配置元）、11-02（アプリとデータを配置する）、10-04（利用開始の可否を判断する）で使います。

3. 理解する：変換・照合・やり直しの手順

3.1 移行の3つの段階

3.2 よくある誤解

「件数さえ合えば移行は成功」。件数が合っていても、内容（依頼者名や件名）が壊れていれば、正しく移行できたとは言えません。この記事では、件数照合と内容照合の両方を行います（第5.3節・第6節）。

「変換できなかったデータは、原因を直せば必ず移行できる」。原因（日付の形式、文字化け）によっては、元の表計算のデータ自体を人が確認して直す必要があり、その場ですぐに直せるとは限りません。やり直し手順と、移行しない選択肢の両方を用意します（第8.2節）。

4. 判断すること

移行を始める前に人が判断することは、次の5つです。

勝手に決めてはいけないこと：変換できなかったデータを、確認せずに移行済みとして扱いません。実際の過去データの件数・内容を、確認済みの事実として書きません（この記事のデータは架空のものです）。移行後の状態「提出済み」を、実際の業務の状態として扱いません。

AIに任せる範囲：変換処理の下書き、照合の集計、変換できなかった行の一覧化はAIに任せられます。任せてはいけないのは、移行する範囲の決定、変換できなかったデータの扱い（直す・移行しない）の判断、そして元データを見て「正しい値は何か」を決めることです。

5. 作って確かめる：変換・照合処理を作る

5.1 架空の過去データ（表計算にあった想定）

# examples/10-02-migration-plan/old_requests.csv
id,requester,title,content,approver,date
REQ-OLD-001,佐藤,会議室の予約,9/25 10時から,鈴木,2026-01-05
REQ-OLD-002,田中,備品購入申請,プリンター用紙,鈴木,2026/1/6
REQ-OLD-003,佐藤,出張申請,大阪出張,高橋,2026-02-30
REQ-OLD-004,（文字化けの例）,（文字化けの例）,文字化けの例（架空）,鈴木,2026-01-10
REQ-OLD-005,高橋,交通費精算,電車代,佐藤,2026/01/12

REQ-OLD-003は実在しない日付（2月30日）、REQ-OLD-004は依頼者・件名に文字化け（置換文字）を含む、説明用の失敗例です。

5.2 変換処理（抜粋）

migrate.js からの抜粋（正本と一字一句同じ。全文は examples/10-02-migration-plan/migrate.js）：

// 文字化けの疑い（Unicodeの置換文字U+FFFDが含まれる）を検出する。
function looksMojibake(value) {
  return /�/.test(value);
}

// "2026-01-05" と "2026/1/6" のどちらの形式も受け付け、ISO形式（YYYY-MM-DD）に変換する。
// 実在しない日付（例：2026-02-30）は変換失敗として扱う。
function convertDate(value) {
  const m = value.match(/^(\d{4})[-\/](\d{1,2})[-\/](\d{1,2})$/);
  if (!m) return { ok: false };
  const [, y, mo, d] = m;
  const iso = `${y}-${mo.padStart(2, "0")}-${d.padStart(2, "0")}`;
  const dt = new Date(iso + "T00:00:00Z");
  const roundTrip = dt.toISOString().slice(0, 10);
  if (roundTrip !== iso) return { ok: false }; // 例：2026-02-30は2026-03-02に繰り上がり、一致しない
  return { ok: true, iso };
}

5.3 件数照合・内容照合（抜粋）

run.js からの抜粋（正本と一字一句同じ。全文は examples/10-02-migration-plan/run.js）：

// 件数照合：読み込んだ行数 = 移行できた件数 + 移行しなかった件数
const countCheck = result.totalRead === result.migrated.length + result.skipped.length;

// 内容照合：移行できた各行について、変換前後で依頼者・件名が変わっていないかを抜き取り確認する。
const sourceRows = require("./migrate.js").parseCsv(fs.readFileSync(CSV_PATH, "utf8"));
const contentChecks = result.migrated.map((m) => {
  const src = sourceRows.find((r) => r.id === m.id);
  const ok = src.requester === m.requester && src.title === m.title;
  return { id: m.id, requesterMatch: src.requester === m.requester, titleMatch: src.title === m.title, ok };
});

5.4 演習の設計

6. 実行結果（移行計画・照合表）

examples/10-02-migration-plan/ で実行した stdout です（整形・省略なし。stderr への出力はありませんでした）。

$ node run.js
読み込んだ行数: 5
移行できた件数: 3
移行しなかった件数: 2

移行しなかった行と理由:
  REQ-OLD-003: 日付の形式が不正、または実在しない日付（2026-02-30）
  REQ-OLD-004: 文字化けの疑い（requester列）のため要人手確認

件数照合（読み込み行数 = 移行件数 + 移行しなかった件数）: 一致

内容照合（依頼者・件名の一致）:
  REQ-OLD-001: 一致
  REQ-OLD-002: 一致
  REQ-OLD-005: 一致
終了コード: 0

実行後に作られる migrated_requests.json の確認（同じ実行記録より）：

$ node -e "const m=require('./migrated_requests.json');console.log(m.length, m.map(r=>r.id+':'+r.state+':'+r.submittedAt).join(' '))"
3 REQ-OLD-001:提出済み:2026-01-05 REQ-OLD-002:提出済み:2026-01-06 REQ-OLD-005:提出済み:2026-01-12

読み方：移行できた3件は日付がISO形式に揃い、状態はすべて「提出済み」（移行時点の教材上の仮定。第8.3節）です。「2026/1/6」は「2026-01-06」に変換され、「2026-02-30」は実在しない日付として移行されていません。

7. 確認結果

実行環境：macOS 26.6.2、Node.js v24.18.0（node:fs、node:pathのみ使用）、2026-09-21に実行（コード・データは2026-09-20の初版から不変）。実行場所は examples/10-02-migration-plan/。stdout・stderr・終了コードは evidence_public/phase5b2c2-2026-09-21/10-02/run_log.md に整形なしで記録しています。

完了条件との照合：

この記事で確かめたこと：架空データ5件について、変換・照合・移行しない行の記録が実際に動くこと。

この記事で確かめていないこと：

残る制限：この移行は、架空データ5件を対象にした小規模な確認です。実際の過去データの件数・内容・保存形式（Excelファイル、メール本文など）は、この記事の時点では確認していません。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 移行する範囲を判断する

この記事の教材演習では、変換できたデータ（3件）は移行し、変換できなかったデータ（2件）は、元の表計算を人が確認して修正されるまで移行しない扱いとしています。

8.2 やり直し手順

いずれの場合も、修正せずに推測で埋めることはしません。元のデータを人が確認できない場合は、その依頼は移行しない扱いとします。やり直しは、元データ（old_requests.csv に相当する表計算）を直してから変換処理をもう一度実行する形で行い、出力（migrated_requests.json）を手で書き換えません。

8.3 移行後の状態の扱い

この記事の演習データには状態の列が無いため、前者を採用しています。これは教材上の仮定であり、移行した依頼が実際に「提出済み」だったという意味ではありません。実際の移行では、元データに状態の列があるかを確認してから選びます。

9. 持ち帰る成果物

自分の業務に使うときの手順は次のとおりです。

1. 過去データの所在（表計算、メールなど）と件数を確認する
2. 変換ルール（日付の形式、必須項目の有無など）を決める
3. 変換処理を作り、件数照合・内容照合を行う
4. 変換できなかったデータについて、やり直し手順と移行しない範囲を決める
5. 移行後の状態をどう扱うか（1つに揃える／元データの状態を対応づける）を決める

10. 次工程への受渡し

次へ渡すもの：移行計画・照合表、変換・照合コード。

次工程での使われ方：11-01（公開前チェック）では、この記事の出力 migrated_requests.json を配置元として確認します。11-02（アプリとデータを配置する）では、その出力を実ファイルとして配置サンドボックスへコピーします。10-04（利用開始の可否を判断する）では、この照合結果を判定材料の1つとして使います。

前工程へ戻る条件：データ項目の不足が見つかった場合は、05-01に戻って確認します。状態の対応づけが必要になった場合は、05-02の状態を確認します。

11. 根拠と更新情報

• この記事の会社・人物・データはすべて架空の設定です。
• 変換先のデータ項目は05-01に基づきます。
• 制作の来歴：本文はClaude Codeが作成しました。第5〜6節のコードは examples/10-02-migration-plan/ を正本とし、2026-09-21にmacOS 26.6.2・Node.js v24.18.0の環境で実際に実行し、stdout・stderr・終了コードを evidence_public/phase5b2c2-2026-09-21/10-02/run_log.md に記録しています（コード・データ・出力は2026-09-20の初版から不変）。人（ユーザー）による実読・内容確認は未実施です。
• 2026-09-21（Phase 5B-2C2）：コード・演習データ・実行結果は変えていない。第5節の抜粋が正本と一部異なっていた（コメントの有無）ため一字一句一致させ「抜粋」と明記した。移行前に判断すること（第4節）、演習の設計（第5.4節）、移行後の状態の扱い（第8.3節）、確かめていないことの表（第7節）を補った。
• 未確認事項：実際の過去データの件数・内容・保存形式、実際のアプリへのデータ投入（11-02で扱う）は、この記事の時点では確認していません。