データは表ではなく、構造で持つ。
JSON / YAML / SQLite がそれを可能にする。

データを持つ道具を、JSON・YAML・SQLite・Parquet に変える(人間 が見る表は Excel/OnlyOffice の .xlsx)。

共通する原則はひとつ ── データは必要な構造とともに保存する。 階層は階層として、設定はコメント付きで、更新があるものはスキーマと トランザクションで、大量データは列指向と型で。CSV のように「全部 の値を文字列の表に押し込む」のではなく、データの形が要求する構造 を選ぶ。

なお、Excel ファイル(.xlsx)は捨てない ── シート・型・関数・ 書式という構造を保つから。捨てるのは CSV のほう ── 構造を保たず、 情報を失う形式だから。

四つの構造を学ぶ ── syntax ではなく、構造の種類を

「データの形に合わせて構造を選ぶ」ためには、選択肢を知っている 必要がある。だから、本章で次の四つを学ぶ:

「四つも学ぶのは大変では?」── ここでも、第1章の 「書く能力では なく使う能力」 が効く。

• syntax(文法)は Claude が書く ── CREATE TABLE、SELECT、 JSON の括弧、YAML のインデント、Parquet のスキーマ ── 全部 AI
• 人間が学ぶのは「どの構造をどの場面で使うか」だけ ── 上の表の 四列を頭に入れておけば足りる
• 「これは階層あり」「これは更新あり」「これは大量」と判断できれば、 Claude が適切な形式とコードを返してくれる

構造を選ぶ目 だけ持てばいい。文法を覚える必要は無い。 これは文書で「Markdown / AsciiDoc / MyST / LaTeX を用途で選ぶ」 (第2章)のと同じ作法だ。

そして、CSV は捨てる。上の四つのどれにも該当する構造を持たない ── 長年「表のデフォルト形式」と思われてきたが、構造化が弱すぎて、 AI ネイティブな道具立てには合わない。本章でその理由を見る。

Excel は表ではない

Excel ファイルを開く。罫線、セル結合、色分け、太字、フォントサイズ、コメント、フィルタ、ピボットテーブル。これらすべてが「データ」と一緒に保存されている。

「2026年度の売上」を集計するつもりが、気づけばセルの配色を整えている。「青は確定、赤は仮、黄色は要確認」── このルールは、ファイル名にも、コメントにも、別ドキュメントにも、どこにも書かれていない。作った本人の頭の中にだけある。

その人が辞めたら、ルールも消える。Excel は、構造を書式で表現するために、構造そのものをファイルから消す。

これは Excel の欠陥ではない。Excel は人間が表を整えるための道具だ。書式が前面に出るのは設計通りである。

しかし、データの本質は書式ではない。本質は構造だ。「これが日付」「これが金額」「これが顧客 ID」── データを成り立たせているのはこの定義である。書式は表示のための装飾にすぎない。

JSON は構造をそのまま持つ

JSON はテキストだ。データの形をそのまま書く。

{
  "customer": "山田農園",
  "orders": [
    { "date": "2026-04-01", "item": "キャベツ", "qty": 12, "price": 180 },
    { "date": "2026-04-08", "item": "玉葱", "qty": 24, "price": 95 }
  ]
}

これだけで、顧客と注文が階層を持って表現できる。「顧客に複数の注文がぶら下がる」という構造は、ファイルを開いた瞬間に分かる。書式情報は一切ない。色も罫線もフォントもない。それは、必要ないからだ。

書式が要るのは表示のとき。データを保存するときには要らない。

CSV は捨てる ── 構造化が弱すぎる

「表ならとりあえず CSV」── これは捨てる。理由は 構造化が弱い こと。CSV はテキスト形式で AI が読めるが、型もスキーマも無く、 階層も表現できず、Excel が黙ってデータを書き換える。AI ネイティブ な道具立てには合わない。

構造がどうなっているかが見えない

データを扱うとき、構造がどうなっているか ── 列が何を表すか、 型は何か、null と空文字の区別、階層はあるか ── は決定的に重要だ。 CSV では、それがわからない。

同じ「2026-04-01 / 001 / キャベツ / 12」というデータを、二つの形式 で書き比べる:

date,id,name,value
2026-04-01,001,キャベツ,12

{
  "date": "2026-04-01",
  "id": "001",
  "name": "キャベツ",
  "value": 12
}

構造がどうなっているかは重要だ。CSV では、それがわからない。 読み手(人間も AI も)が、毎回「これは何か」を推測する。 推測が外れれば、データが化ける。

これは、文書で プレーンテキスト(.txt)を捨てて Markdown を 選ぶ(第2章)のと 同じ原理 だ。「テキスト形式で読める」 だけでは足りない ── 構造を明示する形式 を選ぶ。

• 文書: .txt → Markdown / AsciiDoc / MyST / LaTeX(見出し・ 階層・強調が型として表現される)
• データ: CSV → JSON / YAML / SQLite / Parquet(型・スキーマ ・階層・コメントが表現される)

構造が弱い形式は、AI にも人間にも、長期にも不利。

構造的な欠陥

• 型情報が無い(全部文字列扱い)── 001 も 2026-04-01 も 123.45 も、ファイル上は単なる文字の並び。読むたびに型を 「推測」する必要がある
• スキーマが無い ── 「この列は必須か」「日付の形式は?」「数値 の単位は?」がファイル自体に書かれていない。作った人の頭の中 だけにある
• 階層が表現できない ── 顧客と注文のような 親子関係 を CSV で持つには、ファイルを複数に分けて自前で結合する羽目になる
• コメントが書けない ── 「なぜこの値か」「いつ追加した行か」 を残せない
• 同時編集の事故が止められない ── 最後に保存した方が勝つ
• 1 行の編集ミスで全体が壊れる ── カンマやクオートを間違え ると、全行が崩れる

Excel が黙ってデータを書き換える

最大の問題は、Excel(や OnlyOffice)で CSV を開くと、データが 黙って書き換えられる ことだ。

代わりに何を使うか

CSV を諦めても、行き先はある:

「CSV は ASCII で、どこでも読めるから安全」── これは過去の発想だ。 AI ネイティブな世界では、型を持つ JSON / SQLite / Parquet の ほうが、Claude にも人間にも安全で、しかも速い。

既存の CSV が届いたら

組織から CSV が届くこと自体は無くならない。受け取った瞬間に、 JSON / SQLite / Parquet に変換 する(Claude が Python コードを 書く)。CSV のまま 保管しない、編集しない、Excel で開かない。

# 届いた CSV を、即座に JSON や Parquet に変換
import polars as pl
df = pl.read_csv("received.csv", schema_overrides={"id": pl.Utf8})  # ID は文字列で
df.write_parquet("received.parquet")     # 型を保ったまま保存
df.write_json("received.json")           # 受け渡し用に JSON

Office を「使う」のではなく「通過させる」のと同じ構造で、 CSV も「通過させる」だけ。自分の手元では持たない。

Excel(.xlsx)は捨てない。捨てるのは CSV のほう

ここで誤解してはいけない ── Excel ファイル(.xlsx)は構造を 持っている。シート・列名・型(数値・文字列・日付・通貨)・関数・ 書式 ── これらすべてがファイルの中に保存されている。だから Excel ファイル自体は捨てない。人間が見て触る表は .xlsx で 持ってよい(編集器に Microsoft Excel を強要されない ── OnlyOffice で十分、後述)。

捨てるのは CSV のほう。.xlsx から CSV に書き出した瞬間に、 シート構造・型・関数・書式 ── すべての構造情報が消える。 Excel ファイル → CSV は、情報を失う変換だ。

ソフトウェアエンジニアの罪 ── CSV を勧める文化

ここではっきり言っておく。「データは CSV で持て」と勧めてきた ソフトウェアエンジニアの文化は、間違っていた。

CSV を強く推奨する理由として、よく挙げられてきたのは:

• 「テキストだから何でも読める」 ── 正しい。だが 型情報が消える という代償 を払っている
• 「Unix の哲学に従う」 ── CSV はそれより 30 年古いだけだ
• 「軽量で速い」 ── Parquet は型を保ったままさらに圧縮できる
• 「機械可読」 ── JSON / Parquet / SQLite のほうがずっと機械可読
• 「DB のエクスポート先として標準」 ── 標準であることと、適切で あることは別

これらは 「型なしの表」を扱う技術文化の延命 にしかなっていない。 そして、その代償を払うのは ── 事務職・研究者・農家・個人事業主 ── ソフトウェアエンジニアではない側の人々だ:

• 社員番号の先頭ゼロが消える → 人事担当が修復作業
• 遺伝子名が日付に化ける → 研究者が論文を再執筆(実際の事件あり)
• 顧客の電話番号が指数表記になる → 営業が顧客に連絡できない
• 文字化けで日本語が読めない → 現場が手作業で復元
• .xlsx を CSV で「軽量化」させられる → 関数・書式・シート 構造がすべて消える

これらは、データを 構造とともに保存していれば起きない事故だ。

CSV を勧めてきた人たちは、「自分は困らないが、誰かが困る形式」 を業界標準として押し付けてきた。AI ネイティブな時代に、その文化 は終わりにする。

代わりに、型と構造を持つ形式 を選ぶ:

• .xlsx(Excel / OnlyOffice) ── 人間が見て触る表(構造あり)
• JSON / YAML ── 階層・設定・受け渡し
• SQLite ── 更新があるデータ
• Parquet ── 大量・分析用

Excel ファイル(.xlsx)は情報を保つから捨てない。捨てるのは CSV のほうだ。

YAML は設定をそのまま持つ

設定ファイル ── システムの動作を決めるパラメータには YAML が向く。

site:
  name: aiseed.dev
  language: ja
  features:
    - markdown
    - rss
    - sitemap

build:
  output: html/
  cache: true
  threads: 4

JSON より人間に読みやすく、コメントも書ける。# で始まる行はコメント。「この設定は何のためか」を、設定そのものに書き残せる。

YAML は Markdown 記事のフロントマター(冒頭の --- で囲まれた部分)にも使われる。

AI が読むのは構造

ここが決定的に重要な点だ。

Claude に Excel ファイルを渡すと、まず .xlsx を解凍して XML を読む。書式情報をすべて剥がして、セルの値だけを取り出す。AI が必要としているのは、最初から剥き出しの構造だ。

JSON・CSV・YAML を渡せば、変換は要らない。直接読める。直接書ける。

データを構造で持てば、AI は同僚になる。

これは比喩ではない。技術的事実だ。AI とテキストでやり取りする限り、JSON・CSV・YAML はデータの共通語である。

どれを使うか

選び方はシンプルだ。

一つのプロジェクトで全部使ってもいい。更新がある顧客マスタは SQLite、人間が触る月次集計表は OnlyOffice、請求書のデータは JSON、 受け渡しも JSON、システム設定は YAML、大量の取引履歴は Parquet ── というふうに使い分ける。CSV は レガシーな入口 で、届いたら即 JSON / SQLite / Parquet に変換、自分の手元には保管しない。

迷ったら、Claude に「このデータをどの形式で持つべきか」と聞けば、データの性質を見て答えてくれる。

人間が見る表は OnlyOffice ── Excel UI を捨てずに、Microsoft を捨てる

「表は人間が触るもの。書式・色分け・列幅・関数 ── これら全部要る」 ── そういう用途は、確かに残る。月次の集計表、顧客への提示資料、 予算管理表、シフト表、見積もり表。

ここで SQLite や JSON を持ち出すのは間違いだ。人間が見て触る表 には、表計算 UI がそのまま要る。ただし、Microsoft Excel に縛ら れる必要はない。OnlyOffice を使う。

OnlyOffice とは

OnlyOffice は、Excel と高い互換性を持つ表計算ソフト だ (Word / PowerPoint 互換のエディタも同梱)。OSS で、デスクトップ版 は無料、サーバー版もコミュニティエディションは無料で使える。

• .xlsx 形式をネイティブで読み書き ── 相手から届いた Excel ファイルをそのまま開ける、保存も .xlsx のまま、ほぼ 完全な互換性
• 書式・関数・ピボット・グラフを保持 ── 罫線、色分け、 SUM、VLOOKUP、条件付き書式、ピボットテーブル ── すべて動く
• Microsoft アカウント不要・サブスク不要 ── 月額課金から 解放される
• ブラウザ版で共同編集 ── Google Sheets / Microsoft 365 の 代替として、自社ホスティングできる
• REST API でプログラム連携 ── Python から OnlyOffice の サーバーに渡せば、.xlsx ↔ PDF 変換などが自動化できる
• Linux でも動く ── Mac / Windows / Linux すべてで動作

Excel との比較

どこで OnlyOffice を選ぶか

• 業務の表計算(月次集計、シフト、予算)── OnlyOffice デスク トップ版で開く、.xlsx のまま運用
• チームでの共同編集 ── OnlyOffice サーバーをセルフホスト、 Google Sheets / Microsoft 365 を抜ける
• 顧客に渡す表 ── OnlyOffice で作って .xlsx で送る、 相手が Excel で開いても問題ない

古い CSV が届いたら、即 OnlyOffice か Parquet に逃がす

外部システムから CSV が届くこと自体は無くならない。受け取ったら、 自分の側で CSV のまま持たない。用途で行き先を分ける:

• 人間が触る表として残したい → OnlyOffice で開いて、書式と 型を付けて .xlsx で保存。以後は .xlsx で運用
• プログラムで集計・分析したい → Polars / DuckDB で読んで Parquet に変換(型・スキーマがファイルに残る)
• API で他システムに渡したい → JSON に変換 して持つ

CSV は 入口の互換層 にすぎない。Office を「使う」のではなく 「通過させる」のと同じ構造で、CSV も 通過させる だけ。

Excel が届いたら

組織の中では、相手から .xlsx が届く。それを そのまま OnlyOffice で開く。Microsoft 365 を購入しなくていい。返信時も .xlsx で 保存して送る。相手は Excel で開く、自分は OnlyOffice で開く ── 違いはほぼ見えない(ごく一部の高度な機能 ── 一部の VBA、 複雑なピボット、PowerQuery ── を除く)。

Excel という UI(行と列、書式、関数)は捨てない。 Microsoft というベンダーは捨てる。 その分離を可能にするのが OnlyOffice だ。

SQLite ── 更新があるデータの本命

ここまでで CSV を捨て、JSON と YAML を「データを持つ」道具立て に据えた。しかし、頻繁に更新するデータ には JSON / YAML も 最適とは言えない:

• JSON / YAML ファイルを手で書き換えると、括弧やインデントの ミスで全体が壊れやすい
• 二人が同時に編集すると、最後に保存した方が勝つ(編集衝突を 検知できない)
• ファイル全体を読み書きするので、数万件を超えると遅くなる
• インデックスや制約(UNIQUE、NOT NULL)が無い
• 「最後に書き換えたのは誰か・いつか・なぜか」が ファイルだけ では追えない

更新があるデータ ── 顧客マスタ、商品マスタ、出納帳、在庫台帳、 予約管理、タスク管理 ── には SQLite を使う。

SQLite とは

SQLite は 単一ファイルのデータベース だ。サーバーは要らない。 my_data.db というファイル一つに、複数のテーブル・スキーマ・ インデックス・データすべてが入る。Python の標準ライブラリに sqlite3 が組み込まれているので、追加インストールすら要らない (Polars や DuckDB からも、SQLite ファイルを直接開ける)。

import sqlite3

con = sqlite3.connect("customers.db")
con.execute("""
    CREATE TABLE IF NOT EXISTS customers (
        id        INTEGER PRIMARY KEY,
        name      TEXT NOT NULL,
        email     TEXT UNIQUE,
        joined_at DATE NOT NULL
    )
""")
con.execute(
    "INSERT INTO customers (name, email, joined_at) VALUES (?, ?, ?)",
    ("山田農園", "yamada@example.com", "2026-04-01"),
)
con.commit()

JSON / YAML との違い

JSON / YAML は 設定や受け渡し に最適、SQLite は 更新のある データ に最適 ── 用途で使い分ける。

最大のハードル ── 「ターミナル + Python + SQL」の三点セット

正直に言う。SQLite を使うことは、本書全体で最も大きな壁だ。

• ターミナル(コマンドライン)を開く必要がある
• Python のスクリプトを書く・実行する
• SQL という新しい言語が出てくる

これまで Excel しか触ってこなかった人にとって、この三つを同時に 扱うのは確かに重い。ここを越えるかどうかが、AI ネイティブな 仕事の最大の分岐点 である。

しかし AI がいる時代では、この三つ全部を自分で書く必要はない:

• スキーマ設計(どんな列・型にするか)── 「顧客マスタを SQLite で作って。氏名・メール・登録日が必須。メールは重複不可」 と Claude に頼むと、CREATE TABLE 文が返る
• データ追加・更新のスクリプト ── Claude が INSERT / UPDATE の Python コードを書く
• 検索・集計 ── Claude が SELECT の SQL を書く。自分は 「先月入ってくれた顧客の一覧」と日本語で投げる

人間がやるのは、意図を言葉にする・出てきたコードを実行する・ 結果を確認する。これは第1章「Python で書く」とまったく同じ作法 だ。SQLite を入れることは、Python での処理対象が「ファイル」から 「データベース」に変わるだけ ── 同じ作法でやれる。

Excel との接続も Claude が書く

組織の中では、相手から Excel が届く。SQLite に取り込むのも、 SQLite から Excel に書き戻すのも、Claude が Python コードを書く。

# Excel → SQLite(取り込み)
import polars as pl
df = pl.read_excel("customers_2026Q1.xlsx")
df.write_database("customers", "sqlite:///customers.db")

# SQLite → Excel(書き戻し)
df = pl.read_database("SELECT * FROM customers", "sqlite:///customers.db")
df.write_excel("customers_export.xlsx")

入口で SQLite に取り込み、中身は SQLite で運用、出口で Excel に 書き戻す。自分の作業領域は SQLite に保たれ、組織との境界では Excel に変換する ── 第5章「事務処理を変える」で見た「入口/中身/ 出口の分離」と同じ構造だ。

JSON / YAML は「持つ」用、SQLite は「育てる」用、Parquet は 「集計する」用。CSV は使わない。 このハードルを越えれば、Excel で運用していたあらゆる更新データが 構造に変わる。

大量のデータには Parquet と DuckDB

JSON は人間が直接読める利点がある一方、サイズが大きくなると処理が 遅くなる(数十万件以上)。数百万〜数億行のデータには、Parquet と DuckDB を組み合わせる。

Parquet ── 列指向の保存形式

Parquet は、Apache が開発した 列指向(columnar) のバイナリ 保存形式だ。「行ごと」ではなく 「列ごと」 にデータを並べる。

行ごと(JSON / 旧来 CSV のイメージ):
  { date: 2026-04-01, item: キャベツ, qty: 12, price: 180 }
  { date: 2026-04-08, item: 玉葱,    qty: 24, price:  95 }

Parquet(列ごと):
  [date]:  2026-04-01, 2026-04-08, ...
  [item]:  キャベツ,    玉葱,        ...
  [qty]:   12,          24,          ...
  [price]: 180,         95,          ...

これによって、

• 圧縮率が高い ── 同じ列のデータは似ているので、辞書圧縮や ランレングス符号化が効く。テキスト系の 1/5 〜 1/10 のサイズ
• 必要な列だけ読める ── 100 列のうち 3 列だけ集計したいとき、 3 列分のデータだけディスクから読む(I/O が劇的に減る)
• スキーマがファイル内にある ── 列名と型がファイル自身に保存 されており、CSV のような型推測の罠が消える
• 業界標準 ── Polars、DuckDB、Spark、BigQuery、Athena ── ほぼ すべての解析ツールが直接読める

DuckDB ── ファイルに SQL を直接かける

DuckDB は「分析のための SQLite」 だ。サーバーが要らない、 インストールは pip install duckdb 一行、そして Parquet や JSON のファイルそのものに対して SQL クエリを書ける。

$ duckdb -c "
    SELECT date, SUM(qty * price) AS sales
    FROM 'orders.parquet'
    WHERE date >= '2026-01-01'
    GROUP BY date
    ORDER BY date
"

データベースに「インポート」する必要すらない。Parquet がそのまま テーブルとして扱える。1 億行のデータでも、必要な列と必要な行だけを 読み込んで、数秒で集計が返る。

Polars ── pandas より速く、AI が書きやすい

Python 側でデータを加工するときの第一選択は Polars(Rust 実装、 列指向、遅延評価)だ。pandas より 数倍〜数十倍速く、メモリ消費も 少なく、API も読みやすい。Parquet とも完全に相性が良い。

import polars as pl

# Parquet を直接読む(必要な列だけ)
df = pl.read_parquet("orders.parquet", columns=["date", "qty", "price"])

# 月別売上を集計
monthly = (
    df.with_columns(month=pl.col("date").dt.strftime("%Y-%m"))
      .group_by("month")
      .agg(sales=(pl.col("qty") * pl.col("price")).sum())
      .sort("month")
)
print(monthly)

三つの組み合わせ

実際の使い分けは、規模で決まる。

届いた CSV を一度 Parquet に変換しておけば、以後の集計が劇的に 速くなる ── そして元の CSV はもう要らない(捨ててよい):

# 届いた CSV を Parquet に変換、以後は Parquet で運用
$ duckdb -c "COPY (FROM 'received.csv') TO 'orders.parquet' (FORMAT PARQUET)"

# 以後はすべて Parquet で処理(数千万行でも秒単位)
$ duckdb -c "SELECT item, SUM(qty) FROM 'orders.parquet' GROUP BY item"

なぜ jq や awk より Python なのか

「ターミナルで jq と awk を組み合わせれば速い」── これは部分 的には正しい。しかし、

• 構造が複雑になると jq の式が読めなくなる ── 三段以上ネスト すると、書いた本人も翌日には解読できない
• AI が書きにくい ── jq / awk の独特な構文は、Claude も他の AI も Polars / DuckDB ほど安定して書けない(訓練データが少ない)
• 再現性と可搬性 ── Python スクリプトはチームで共有できる、 Git で管理できる、テストできる、import で部品化できる
• 大量データで頭打ち ── awk は 1 GB を超えると遅くなる。 Polars / DuckDB は 100 GB 級まで普通に動く

ワンライナーで済むなら shell でよい。少しでも複雑なら Python (Polars / DuckDB)に切り替える。Claude が書きやすい、読みやすい、 保守できる。

Excel ファイルが届いたら ── 二つの分岐

組織の中で働く限り、Excel ファイルは届き続ける。来た Excel を どうするかは、用途で二つに分かれる。

人間が見る・触る用なら → そのまま OnlyOffice で開く 書式・色分け・ピボットを保ったまま編集して、.xlsx で送り返す。 Microsoft 365 の課金は要らない。

プログラムで処理する・更新を続ける用なら → 取り込んでから運用 Polars / Claude が一回 Excel を読んで、用途に応じて:

• 更新を続けるマスタデータ → SQLite に取り込む
• その場限りの集計 → Polars でメモリ上で処理(出力は OnlyOffice の .xlsx や JSON)
• 大量の取引履歴 → Parquet に書き出す(以後 DuckDB で分析)
• 他システムに渡す → JSON でエクスポート

自分の作業領域は構造に保つ。組織が要求する形式は、入口と出口 の変換だけで吸収する。中身は SQLite / Parquet / JSON / YAML、 人間が見るものだけ OnlyOffice。CSV は中身に持たない。

具体例:どのデータをどこに置くか

抽象的な原則を、具体的なシナリオで見る。

小売店の在庫管理

• 商品マスタ(SKU、商品名、仕入先、原価、定価):更新あり → SQLite(UNIQUE(sku)、NOT NULL(name))
• 日次の販売記録(取引履歴):追記のみ、大量 → Parquet (週次でローテーション、月次で集約)
• 発注書(取引先ごとに 1 件、階層あり):JSON(JSON で 発行して PDF 化、第1章で扱う pandoc などで印刷)
• 棚卸し集計表(人間が見る、書式付き):OnlyOffice .xlsx (集計は Polars で SQLite から作る、第1章)
• 設定(税率、消費税の表示方式、運送業者の選択):YAML (バージョン管理可、コメントで「なぜこの設定か」を残せる)

個人事業主のコンサルティング業

• 顧客マスタ(社名、担当者、メール、契約状態):SQLite
• 案件履歴(顧客 ID にぶら下がる複数案件):SQLite (FOREIGN KEY で関連付け)
• 請求書テンプレート + 個別データ:Markdown + JSON (Markdown が雛形、JSON が各顧客の差し込みデータ)
• 月次レポート(配布用):Markdown → PDF(中身は Markdown、 グラフは Altair、第3章)
• API レスポンス(freee / MoneyForward から取得):JSON そのまま受け取り、SQLite へ取り込む

研究室・大学研究者

• 実験データ(数百万〜数億行のセンサ記録、画像メタデータ): Parquet(列指向で圧縮、DuckDB で SQL 直接)
• 論文ノート(調査・引用・自分のメモ):Markdown(第2章)
• 共同研究者との交換用データ:JSON / Parquet
• 学会発表のスライド:Markdown + Marp(第3章)
• 過去 10 年の実験設定アーカイブ:YAML(設定 + コメント)

小規模法律事務所

• 案件管理(顧客、案件種別、期日、状態):SQLite
• 判例の自分用ノート(検索可能にしておく):Markdown (第2章、Forgejo の Wiki としても機能、第2章)
• 契約書テンプレート + 案件別データ:Markdown + JSON
• 会計記録:SQLite(個人情報を含むのでセルフホスト必須、 第2章「プライバシー → セルフホスト」)
• 公開する事務所のブログ:Markdown(第7章で Web 化)

これらすべてに共通する作法は 第1章 の「Python が読み書きする」 ── 道具立てが揃った瞬間、業種を問わず同じ操作で扱える。

10年後も読める

20年前の Excel ファイル(.xls 形式)は、今の Excel で開くとレイアウトが崩れることがある。マクロが動かない。フォントが置換される。

JSON と YAML は、ただのテキストファイル(構造付き)だ。10年後も 20年後も、テキストエディタがあれば読める。AI ならもっと簡単に読める。 SQLite ファイルもオープン仕様で、米国議会図書館が「長期保存に推奨」 する形式の一つだ。Parquet もオープン仕様で、Apache が標準として 維持している。

構造を残せ。書式は捨てろ。

書式は今を飾る。構造は時間を超える。

実例: 数字で見る

10,000 行の売上データ。Excel .xlsx で 1.2 MB、JSON で 800 KB、 Parquet で 60 KB。Excel の 20 分の 1、JSON の 1/13。 書式と冗長なキー情報が消える。

Excel ピボットテーブルで月別売上集計: マウス操作で 5 分、再現性 ゼロ(操作の記録は残らない)。同じ集計を Polars で書くと 3 行、 実行 0.05 秒、Python スクリプトとして残るので翌月も使える。

100 個の .xlsx から特定列を抽出する月次作業: Excel VBA で半日。 Polars で glob を使って一気に処理すれば 15 秒(pandas より 2〜3 倍速い)。Claude に頼めばコードはすぐ出る。

1 億行の取引履歴から月別の商品別売上を集計: pandas で読み込み中に メモリ枯渇 → 不可能。DuckDB なら Parquet ファイルに直接 SQL を かけて 数秒で完了(必要な列・必要な行だけストリーム読み)。

JSON / YAML / SQLite を Claude に渡したときの認識率: ほぼ 100% (型・スキーマつき構造)。CSV を渡したときは、型推測の罠で ID の先頭ゼロや日付が化けることがあり、信頼性が一段落ちる。 Excel .xlsx の認識率: 形式によっては 70〜80%(セル結合・書式が あると劣化)。型とスキーマがあるほど、AI が間違わない。

5,000 件の顧客マスタを Excel で運用していた事務職の事例: 編集中の保存ミスで月 1〜2 回データ破損、その都度バックアップから 復元 → SQLite に移行後 0 件(トランザクションで保護)。 「重複メールを登録できないように」「退会フラグの列を追加して」と Claude に頼めば、スキーマ変更の Python コードが返る。運用の 心理負荷が下がる。

まとめ

道具を AI 時代に合わせれば、データの扱い方が変わる。

• 階層・受け渡し → JSON
• 設定・人間が編集する構造 → YAML
• 更新があるデータ → SQLite + Python(最大のハードルだが、 Claude が書いてくれる)
• 人間が見る表 → OnlyOffice(Excel UI そのまま、Microsoft 不要)
• 大量・分析用 → Parquet + DuckDB
• CSV は捨てる ── 構造化が弱すぎる。届いたら即変換、自分の 手元には持たない。

これは、文書で プレーンテキストを捨てて Markdown を選ぶ(第2章) のと同じ原理だ。構造を明示する形式を選ぶ ── 文書も、データも、 それが AI ネイティブな働き方の前提になる。

ここまでの 4 章で、共通の作法 ── Python・Markdown・Mermaid・ データ各種(JSON / YAML / SQLite / OnlyOffice / Parquet) ── が 揃った。これらは職種を問わない、AI ネイティブな仕事の最小スタックだ。

次の章から、仕事の種類別の話に進む。まずは事務職の方へ。

関連記事

• 第2章: 処理を書く ── AIにPythonで書いてもらう
• 第3章: 文書を書く ── Markdownという最小の選択
• 序章: 事務処理はOffice、業務ソフトはJava/C#、しかしAIはPythonとテキスト
• 構造分析08: 企業ITの税を引く

実例

再現可能なソース・コマンド・実測結果を、別ページにまとめてある。

• 実例 1 — 100 個の Excel を 30 秒で集計する
• 実例 2 — CSV ⇄ JSON ⇄ YAML 相互変換 + jq / awk クエリ