7-3 Claude Code で大量 CSV を処理｜Python 自動化

このレッスンで身につくこと

ここまでの章で、Excel ファイルを整理したり（第 3 章）、複数ブックを統合したり（第 4 章）、ダッシュボードに可視化したり（7-2）してきました。本レッスンはその下の層、CSV というプレーンテキスト形式の大量データ を、Python スクリプトで一気に料理するパートです。

Excel が 「人間が見るための表」 なら、CSV は 「機械が読むための表」 です。1 万行・10 万行・場合によっては 100 万行を超えるデータになると、Excel ではフリーズしますが、CSV と Python なら数秒で処理できます。Claude Code はそのスクリプトを 書く・走らせる・直す の全工程を担当できるので、SQL や Python に強くない人でも、SQL や Python の能力を持っている人と同じ景色 にたどり着けます。

所要時間 — 約 45 分（実機ハンズオン込み。読むだけなら 20 分） 難易度 — ★★★☆☆（第 3 章「Excel 整理」を済ませている前提）

CSV 処理がスクリプト化に向く理由

Excel 整理（第 3 章）との一番の違いはどこか、というところから入ります。Excel と CSV、見た目は似ていますが、Claude Code に任せたときの 適性 がまるで違います。

理由 1 — 1 行 1 レコードのストリーム処理ができる

CSV は ==1 行 = 1 レコード の単純なテキストフォーマットです。先頭から 1 行ずつ読み込みながら処理できるので、ファイル全体をメモリに乗せなくても済む== ケースが多い。これは Excel の .xlsx（内部は ZIP + XML）には絶対に真似できない強みです。

たとえば 50 万行のアクセスログを Excel で開こうとするとメモリエラーですが、Python の csv.reader でストリーム処理すれば 100MB 程度のメモリで完走します。データ量が大きくなるほど CSV の優位性 が出てきます。

理由 2 — 再現性が高い

Excel ファイルは「開いたら書式が崩れた」「保存時に勝手にカンマ区切りが書き換わった」など、環境依存の罠 が無数にあります。CSV は テキストファイルなので、いつ・誰が・どの OS で開いても同じバイト列 です。差分が取れる、git で管理できる、テスト可能。スクリプト化と圧倒的に相性が良いです。

理由 3 — 同じ処理を 1 コマンドで再実行できる

CSV 処理を Python スクリプトに落としておけば、来月・来年に同じ作業が来たときも python process.py 一発で再実行できます。1 度書いたら永遠の資産 になります。Excel の手作業は、人が異動したり退職したりすると 誰も再現できないブラックボックス になりますが、スクリプトはそうなりません。

理由 4 — Claude Code が 書いて動かして直す まで一気にやってくれる

ここが本丸です。CSV 処理のスクリプトは、ふつう次の流れで作ります。

1. データの先頭数行を見て構造を把握する
2. pandas か csv モジュールでスクリプトを書く
3. 走らせる
4. エラーが出る（文字コード、型崩壊、列名違い等）
5. 直す
6. もう一度走らせる

この 6 ステップが Claude Code 1 回のセッションで完結 します。エラーが出たら Claude Code がエラーメッセージを読んで自分で直しに行きます。人間がやる作業は 「何をしたいか」を 1 文で伝える ことだけ。

パターン 1 — ファイル結合・分割

CSV 処理で最も頻出するのが 結合と分割 です。月別・支店別・日別に分かれたファイルを 1 つにまとめたり、逆に巨大な 1 ファイルを切り分けたりします。

ケース 1-1 — 月別 12 ファイルを 1 年分に結合

> data/ フォルダにある 01月.csv 〜 12月.csv を 1 つの yearly.csv に結合して。
> - ヘッダー行は最初のファイルからのみ取得
> - 「ソース月」列を追加（例: 2026-04）
> - 日付列を YYYY-MM-DD 形式に統一
> - 元の 12 ファイルは変更しない
> - Python スクリプト merge.py として保存して、来月以降も再実行できるように

「来月以降も再実行できるように」 の一言で、Claude Code はハードコードではなく ==フォルダ内の *.csv を glob で拾う== 書き方をしてくれます。来月になったら 13 個目のファイルを置いて python merge.py を叩くだけ。

ケース 1-2 — 100 万行のログを月別に分割

逆に、巨大な 1 ファイルを切り分けるパターンです。

> access-log.csv（約 100 万行）を「日付」列の月別に分割して。
> - 出力: split/access-log-2026-01.csv 〜 split/access-log-2026-12.csv
> - ストリーム処理で、メモリに全行ロードしない
> - 進捗を 10 万行ごとに stdout に表示
> - 元ファイルは変更しない

「ストリーム処理で、メモリに全行ロードしない」 がポイントです。これを書かないと Claude Code は pandas で一気に読み込む コードを書きがちで、巨大ファイルだとメモリ不足で落ちます。

ケース 1-3 — 列数が違うファイルの結合

実務でいちばん厄介なのが、列構成が微妙に違うファイルの結合 です。

> 以下の 3 ファイルを縦結合して。列の順番・名前が違うので正規化が必要。
> - sales-old.csv:  Date, Item, Qty, Price
> - sales-mid.csv:  日付, 商品, 数量, 単価
> - sales-new.csv:  取引日, 品目コード, 個数, 単価, 売上額
>
> 共通列を「日付 / 商品名 / 数量 / 単価 / 売上」に正規化。
> sales-old / sales-mid は売上列がないので「数量 × 単価」で計算して埋める。
> 元の 3 ファイルは変更しない。出力は sales-unified.csv。

マッピング表を指示文に直接書く ことで、Claude Code は曖昧な推測をせずに済みます。ここを「いい感じに揃えて」と省略すると、毎回違う列に揃えられて後工程が壊れます。

パターン 2 — 大量データの絞り込み・集計

10 万行を超えるデータから 必要な行だけを抜き出し、グループ別に集計 するパターンです。SQL を書ける人なら WHERE + GROUP BY の世界ですが、Claude Code には日本語で渡すだけで済みます。

ケース 2-1 — 絞り込み

> orders.csv（約 30 万行）から、以下の条件に合う行だけを
> orders-filtered.csv に書き出して。
>
> 条件:
> - 注文日 2026-04-01 〜 2026-04-30
> - ステータス = "出荷済み"
> - 金額 >= 10,000
> - 顧客ランク IN ("Gold", "Platinum")
>
> 列はすべて保持。並びは注文日昇順。元ファイルは変更しない。
> 処理前に「入力 N 行 → 出力見込み M 行」を報告してから実行して。

「処理前に件数を報告して」 は、第 3 章でも触れた最強の一文です。CSV 処理ではこれを必ず添えてください。30 万行が 1 行に絞られていた ような事故を早期発見できます。

ケース 2-2 — グループ集計

> orders.csv を以下の軸で集計して。
> - 行: 顧客ID
> - 値: 注文金額の合計、注文回数、最終注文日
>
> 出力: customers-summary.csv
> 列順: 顧客ID, 合計金額, 注文回数, 最終注文日, 客単価
> 客単価 = 合計金額 ÷ 注文回数（小数 0 桁で四捨五入）
> 並び: 合計金額 降順

pandas の groupby 1 行で済むコードですが、Claude Code に依頼する側は SQL も pandas も書けなくて大丈夫 です。「軸・値・出力列順・並び」さえ言語化できれば結果が出ます。

ケース 2-3 — 二段集計（月別 × 商品別）

> orders.csv から「月別 × 商品カテゴリ別」の売上ピボットを作って。
> - 行: 注文月（YYYY-MM）
> - 列: 商品カテゴリ
> - 値: 売上合計
> - 合計行・合計列を追加
>
> 出力: pivot-monthly-category.csv
> 数値はカンマなし（後で BI に投入するため）

BI ツールに投入する CSV はカンマ区切りの数値表現にしない のがコツです。Excel で開く前提なら カンマ付き の方が見やすいですが、再加工する CSV では 生の数値 が正解です。同じデータでも、用途で出し分ける 発想を持っておくと事故が減ります。

パターン 3 — 重複削除・名寄せ

CSV を結合した後、ほぼ必ず襲ってくるのが 重複と表記揺れ です。同じ会社が「株式会社ブルーエーアイ／㈱ブルーエーアイ／BlueAI Inc.／BLUE AI」のように 4 通りで現れる、というのが普通です。

ケース 3-1 — 完全一致での重複削除

> customers.csv の重複行を削除して。
> - 重複判定キー: メールアドレス（完全一致）
> - 重複行が複数ある場合、「最終ログイン日」が新しい方を残す
> - 削除された行は customers-duplicated.csv に別途出力
> - 削除前後の件数を報告
> 元ファイルは変更しない。出力は customers-deduped.csv。

削除された行を別ファイルに残す のが鉄則です。「消した気になってたら大事な情報まで消えていた」をリカバリ可能にできます。

ケース 3-2 — 表記揺れの名寄せ

完全一致では消えない 表記揺れ をどう処理するか、ここが本番です。

> customers.csv の「会社名」列で表記揺れを名寄せしたい。
> 以下のルールで正規化した「会社名_正規化」列を追加して。
>
> 1. 「株式会社」「㈱」「(株)」「Inc.」「Inc」「Co., Ltd.」を除去
> 2. 全角英数 → 半角英数
> 3. 全角スペース・連続スペース → 半角スペース 1 つ
> 4. 大文字小文字を区別しない（小文字に統一）
> 5. 「ブルーエーアイ」「BlueAI」「Blue AI」のようなカタカナ・英字混在は
>    レーベンシュタイン距離が 2 以下なら同一視して、最頻出の表記に統一
>
> 「会社名_原文」列は保持。==判定に迷ったものは「要確認」フラグ列を 1 にする==。
> 元ファイルは変更しない。出力は customers-normalized.csv。

「要確認フラグ」 は名寄せの命綱です。AI の名寄せは 100% にはなりません。自信のないものを人間に返す 動線を作ると、後工程の品質が一気に上がります。

ケース 3-3 — 複数キーでの突合（マスター照合）

外部からもらった CSV を、社内マスターと突き合わせて「マスターにある／ない」を判定するパターンです。

> 以下 2 つのファイルを突き合わせて、import.csv の各行を分類して。
> - master.csv: 取引可能な会社のマスター（列: 法人番号, 会社名, ステータス）
> - import.csv: 新規取り込み候補（列: 法人番号, 会社名, 担当者, メール）
>
> 突合キー: 法人番号 完全一致
> 出力 3 ファイル:
> 1. matched.csv — マスターに存在し、ステータスが「取引可能」
> 2. blocked.csv — マスターに存在するが、ステータスが「取引停止」等
> 3. unknown.csv — マスターに存在しない
>
> 各ファイルの件数を最後にサマリーで報告。

1 つの入力を 3 つの出力に振り分ける 構造は、CSV 処理の典型パターンです。これができるようになると、=='手作業の VLOOKUP' が一気に消えます。

パターン 4 — エンコード変換（SJIS ↔ UTF-8）

日本のビジネスデータは Shift_JIS（CP932） と UTF-8 の混在地獄です。Excel が出力する CSV は今でも Shift_JIS が多く、API や Web から取れる CSV は UTF-8 が標準。この 2 つを行き来する 場面が必ず来ます。

ケース 4-1 — 文字コード自動判定して UTF-8 に統一

> received/ フォルダの CSV ファイル群（取引先から届いた、文字コードがバラバラ）を、
> すべて UTF-8（BOM 付き）に統一して unified/ に保存して。
>
> - 入力ファイルの文字コードは chardet で自動判定
> - 改行コードは LF に統一（CRLF や CR が混在しているので）
> - 元ファイルは変更しない
> - 変換結果のサマリー（ファイル名・元エンコード・変換後）を report.csv に出力

UTF-8 BOM 付き にしておくと、Excel でダブルクリックしたときに文字化けしません。社内に Excel ユーザーが多い環境では BOM 付きが圧倒的に安全 です。

ケース 4-2 — 会計ソフト用に Shift_JIS で出力

逆に、会計ソフトや古い基幹システムが Shift_JIS しか読めない ケースもあります。

> sales-utf8.csv を Shift_JIS（CP932）で保存し直して sales-sjis.csv に出力。
> - 改行コードは CRLF
> - Shift_JIS にない文字（例: ① や 髙）があれば、変換できない文字を
>   warnings.csv にリストアップ
> - 変換できない文字は ? に置換せず、行をスキップして除外行リストを出力

Shift_JIS で表現できない文字をどう扱うか を明示するのが鉄則です。デフォルトの ? 置換だと、データの中身が静かに壊れて後で原因不明のエラーを引き起こします。「変換できないなら除外して報告」 の方が安全です。

ケース 4-3 — Excel の謎挙動への対処

Excel が CSV を保存すると、勝手に文字コードが変わる ことがあります。

> Excel で開いて編集した data-edited.csv の文字コードを判定して。
> Shift_JIS だった場合、UTF-8 BOM 付きに変換し直して、
> data-edited-utf8.csv として保存。
> あわせて「行頭の '」（先頭シングルクオート）が混入していないか、
> 「2026/4/1」のような Excel 由来の日付表記が混入していないかも確認。
> 混入があれば fix-needed.txt に該当列をリスト。

Excel が編集に絡んだ瞬間、CSV は別物に変わる のが日本のオフィスの現実です。Excel をパイプラインに挟むなら、必ず Excel 直後にエンコードと書式の正規化スクリプト を 1 段挟んでください。

pandas を AI に書かせる際のコツ

CSV 処理スクリプトを Claude Code が書くとき、ほぼ pandas を使います。pandas は便利な反面、書き方を間違えると遅くてメモリを食う ライブラリでもあります。AI に任せるときの 4 つのコツを置いておきます。

コツ 1 — 列の型（dtype）を最初に指定させる

何も指定しないと pandas は 全列を推定 します。これが遅さとメモリ消費の最大要因。先に型を渡すと一気に速くなります。

> orders.csv を pandas で読み込むスクリプトを書いて。
> dtype を以下で明示:
> - 注文ID: str
> - 顧客ID: str（先頭 0 が消えるので必ず str）
> - 商品コード: str
> - 注文日: 文字列で読み込み後、pd.to_datetime で変換
> - 数量: int32
> - 単価: int64
> - 金額: int64
> usecols で実際に使う列だけ読む（メモリ削減）

dtype を指定する / usecols で必要列だけ読む — この 2 つを書くだけで、100 万行クラスの CSV が 数倍速く・メモリ半分 で扱えます。

コツ 2 — chunksize で分割読み込み

巨大ファイルを一気に読み込まず、チャンク で処理させます。

> 1GB の log.csv を pandas で集計して。
> - chunksize=100000 で分割読み込み
> - 各チャンクで「日付ごとのアクセス数」を集計
> - 最後に全チャンクの結果をマージ
> - メモリ使用量が 500MB を超えないように

「メモリ使用量が 500MB を超えないように」 のような 制約条件 を渡すのが効きます。Claude Code はこの制約を満たすために chunksize や ストリーミング処理を選びます。

コツ 3 — apply より vectorize / map

df.apply(lambda x: ...) は遅いです。pandas のベクトル演算を使った方が 10〜100 倍速い ことがあります。

> 既存スクリプト process.py の遅い箇所を最適化して。
> - apply / lambda を vectorize / np.where / map に置き換え可能なら置き換える
> - 置き換えできない場合はその理由をコメントで残す
> - 処理時間を before/after で計測して表示

「最適化して。理由をコメントで残して」 と書くだけで、Claude Code はベンチマーク付きで最適化版を出してきます。これを人力でやろうとすると半日仕事。

コツ 4 — Polars という選択肢

pandas に限界を感じたら Polars というライブラリがあります。Rust 製で pandas の 5〜30 倍速い場面が珍しくありません。

> 既存の pandas スクリプト merge.py を Polars 版に書き換えて。
> - インターフェースは可能な限り pandas に近づける
> - 処理時間を pandas 版と Polars 版で比較
> - 結果が完全一致することをテストで確認

pandas → Polars に書き換えるだけで月次バッチが 10 分 → 30 秒 というケースもあります。「もっと速くしたい」と感じたら 1 度試す価値があります。

失敗パターン

CSV 処理を Claude Code に任せると、ほぼ必ずこの 4 つのどれかで 1 回はハマります。先回りして対策を入れておきます。

失敗 1 — 文字化け

ファイルを開いたら ==� や ��== がびっしり、というあれです。

対策 は次の通りです。

> 入力 CSV の文字コードを chardet で自動判定してから読み込んで。
> 判定結果（信頼度含む）を最初に標準出力に表示。
> 信頼度が 0.8 未満なら、ユーザーに確認を求める。

「文字コードを自動判定して、判定結果を最初に出力して」 をプロンプトに必ず入れる。これだけで文字化け事故の 9 割は防げます。

失敗 2 — 数値型崩壊

商品コード 001234 が 1234 に、電話番号 09012345678 が指数表記 9.01E+09 に、郵便番号 0790001 が 790001 に。pandas の型自動推定が 先頭 0 を律儀に削る のが原因です。

対策 は次の通りです。

> 以下の列は必ず str（文字列）として読み込んで。
> - 顧客ID
> - 法人番号
> - 商品コード
> - 郵便番号
> - 電話番号
>
> カンマ区切り数値（"1,200" のような表記）は、読み込み後に
> str.replace(",", "") + astype(int) で数値化。

「文字列のままにすべき列」を明示 するのが鉄則です。これを書かないと、毎回違う列が壊れます。

失敗 3 — メモリ不足

50 万行・100 万行クラスの CSV を ==pd.read_csv で一気に読む== と、メモリ不足で OS ごと固まることがあります。

対策 は次の通りです。

> 入力ファイルのサイズが 100MB を超える場合、
> 自動で chunksize=100000 のストリーム処理に切り替えて。
> 処理開始前にファイルサイズと推定メモリ使用量を表示。
> 推定が 4GB を超えるならエラー停止して、ユーザーに警告。

「サイズに応じて処理方式を切り替えて」 は地味に効きます。小さなファイルは pandas に一括で読ませた方が速いので、サイズ依存の分岐 をスクリプトに組み込むのが理想です。

失敗 4 — 改行コード混在

Windows で作った CSV（CRLF）と Mac/Linux で作った CSV（LF）と古い Mac の CSV（CR）が混在すると、行のカウントが壊れたり、最後の列に \r がくっついたりします。

対策 は次の通りです。

> 入力ファイルの改行コードを自動判定して、すべて LF に統一してから処理。
> 全ての文字列カラムは前後の空白・\r・\n・\t を strip。
> strip 後に空文字になった行は、別ファイル empty-rows.csv に書き出す。

「全文字列カラムを strip」 と書いておくと、目に見えない不可視文字混入をほぼ全部潰せます。見えない文字との戦いは CSV 処理の通過儀礼 なので、最初からスクリプトに組み込んでください。

プロンプトテンプレート 4 つ

ここまでの内容を コピペで使えるテンプレート に圧縮しました。手元の Notion / Obsidian / ~/templates/csv/ あたりにコピペして、来週から使ってください。

テンプレート 1 — 結合・縦積み

{folder}/ 内の CSV ファイル（{pattern}）をすべて読み込み、
1 つの {output.csv} に縦結合して。

ルール:
- ヘッダー行は最初のファイルからのみ
- 「ソースファイル名」列を追加
- 列名・列順が違うファイルは {正規化マッピング} に従って統一
- 文字コードは自動判定、出力は UTF-8 BOM 付き
- 改行コードは LF に統一
- 元ファイルは変更しない
- 処理前に「対象 N ファイル → 結合後の見込み M 行」を報告
- スクリプトは merge.py として保存（来月以降も再実行可能に）

テンプレート 2 — 絞り込み・集計

{input.csv} から以下の条件で行を抽出し、集計してください。

絞り込み条件:
- {列名 1}: {条件 1}
- {列名 2}: {条件 2}
- 期間: {start} 〜 {end}

集計軸:
- 行: {行軸}
- 値: {値列}（合計 / 平均 / 件数）

出力 {output.csv}:
- 列順: {列順を明記}
- 並び順: {ソートキー}

ルール:
- 処理前に「入力 N 行 → 出力見込み M 行」を報告
- 文字列として扱う列: {ID 系列名}
- 数値カンマは除去してから集計
- 元ファイルは変更しない

テンプレート 3 — 名寄せ・重複削除

{input.csv} の {キー列} の表記揺れを正規化し、重複行を削除してください。

正規化ルール:
1. {ルール 1}（例: 「株式会社」を除去）
2. {ルール 2}（例: 全角英数を半角に）
3. レーベンシュタイン距離 <= {N} なら同一視

重複判定:
- キー: {キー列_正規化}
- 重複時の生存ルール: {最終更新日が新しい方 等}

出力:
- {output.csv}: 重複削除後
- duplicated.csv: 削除された行（元データ）
- review.csv: 判定に迷った行（要確認フラグ = 1）

ルール:
- {キー列_原文} を保持
- 元ファイルは変更しない
- 削除前後の件数を報告

テンプレート 4 — エンコード変換・改行統一

{folder}/ 内の CSV をすべて以下の仕様に統一して unified/ に保存して。

入力:
- 文字コード: chardet で自動判定
- 改行コード: CRLF / LF / CR の混在を許容

出力仕様:
- 文字コード: UTF-8 BOM 付き
- 改行コード: LF
- 全文字列カラムを strip（前後の空白・\r・\n・\t を除去）
- BOM 起因の  混入を除去

ルール:
- 変換不可文字があれば warnings.csv にリスト（ファイル名・行・列・元文字）
- 元ファイルは変更しない
- 変換結果のサマリーを report.csv に出力（元エンコード / 行数 / 変換結果）

月次バッチへの育て方

1 回の処理で終わらせず、月次バッチ として育てておくと ROI が跳ねます。仕上げのパートとして、スクリプトをスケジュール実行可能にする型を見ておきます。

ステップ 1 — ファイル名にパラメータを抜き出す

> merge.py を以下のように改良して。
> - コマンドライン引数で「年月」を受け取れるように
>   例: python merge.py --month 2026-04
> - 出力ファイル名に年月を埋め込む
>   例: yearly-2026-04.csv
> - 引数なしなら「今月」をデフォルトに

パラメータ化 ができていないスクリプトは、毎月コードを書き換える羽目になります。コマンドライン引数で完結 させるのが資産化の第一歩。

ステップ 2 — エラー時の通知

> merge.py の処理結果を Slack に通知する仕組みを追加して。
> - 正常終了: 件数サマリーを #data チャンネルに投稿
> - 異常終了: スタックトレースとエラー内容を #data-alerts に投稿
> - Slack の Incoming Webhook URL は環境変数 SLACK_WEBHOOK_URL から読む

「失敗したことに気づかない」 が月次バッチで最大の事故源です。Slack 通知を入れておけば、最低でも 止まったことだけは即時に分かる 状態になります。

ステップ 3 — cron / launchd で定期実行

> 毎月 1 日 9:00 に merge.py を実行する crontab エントリを書いて。
> ログは logs/merge-YYYY-MM.log に出力。
> エラー時は stderr もログに含める。
> macOS なら launchd の .plist 版も併記。

月初 9 時にコーヒーを淹れている間に、先月分のレポートが Slack に飛んできている — ここまで来ると、自動化の本当の威力を実感できます。

まとめ

このレッスンで押さえてほしいことを 7 つに絞ります。

1. CSV 処理は 結合・絞り込み集計・名寄せ・エンコード変換 の 4 パターンに分解できる
2. Excel と違って 1 行 1 レコードのストリーム処理ができるので、巨大データに強い
3. pandas を AI に書かせるなら dtype 指定 / usecols / chunksize / ベクトル演算 の 4 箇条
4. 文字化け / 数値型崩壊 / メモリ不足 / 改行コード混在 は CSV 処理の 4 大失敗パターン
5. 文字列として扱う列を明示 / 要確認フラグ / 元ファイル保護 が安全運用の三種の神器
6. テンプレート 4 種類（結合・集計・名寄せ・エンコード変換）を テンプレ化 して再利用
7. 月次バッチに育てる とコスパが跳ねる。パラメータ化 → 通知 → スケジュール実行の 3 段階で資産化

<Quiz question="100 万行クラスの CSV を pandas で扱うとき、メモリ不足を避けるために最も効果が大きい指示はどれ？" options={["chunksize で分割読み込みし、必要な列だけを usecols で指定する","Excel で開いて事前に行数を減らしておく","Claude Code のモデルを Opus に切り替える"]} answer={0} />

<Quiz question="CSV 処理で「数値型崩壊」を防ぐベストプラクティスは？" options={["顧客ID・郵便番号・電話番号など先頭0が消えると困る列は、str（文字列）として読み込ませる","Excel で開き直して列の書式を「文字列」に設定する","pandas の自動型推定に任せる"]} answer={0} />

次の第 8 章では、Claude Code の世界が一段広がる MCP（Model Context Protocol） を扱います。本章で作った CSV パイプラインを、Notion / Google Drive / Slack といった外部ツールと直結させる仕組みです。本章のスクリプトが「ローカルで動く単体ツール」だったのに対し、第 8 章以降は SaaS と組み合わさった業務オートメーション に育てていきます。

次のステップ

• 8-1: MCP とは — 第 8 章の入口。MCP の全体像と、本章の CSV パイプラインを SaaS に接続するイメージを掴みます
• 7-2: KPI ダッシュボードを作成 — CSV の次のステップ。集計結果をダッシュボード化する流れを学べます
• 6-1: LP（ランディングページ）作成 — CSV で得たデータを LP に組み込んで打ち出すアイデアを得られます