なぜAI駆動開発でExcelは嫌われるのか

AI駆動開発でのドキュメントをExcelにすることがなぜ嫌われるのかの理由と、その代替手段にはどういうものがあるかの紹介

Transcript

1. MD なぜAI駆動開発でExcelは嫌われるのか 〜 資産になるドキュメントツール構成 〜
2. AGENDA このセッションで話すこと 「Excel禁止」ではなく「Excelの役割をテキストベースのツールに置き換える」構成の話 Excelドキュメントは、生成AIとの協働で大きなハンデになる 話す順番 なぜダメなのか（根拠） → どうしても使う場合の注意 → 置き換えツール構成 対象: ドキュメントをExcelで書く文化のあるプロジェクトにいる人 なぜダメか → どうしても使うなら なぜAI駆動開発でExcelは嫌われるのか → 置き換えツール構成 2 / 16
3. WHY なぜExcelをドキュメントにしてはいけないか 生成AIはバイナリファイルをそのまま読み書きできない。Excelドキュメントは AI協働の入り口で詰む .xlsx の実体は、ZIP圧縮された XML の塊（バイナリファイル） LLMが直接扱えるのはテキスト。バイナリは一度「変換」を挟まないと読めない 変換で自動的に残るのはセルの値だけ。レイアウトの意図は失われ、図形はほぼ取り出せない テキスト（Markdown）なら: そのまま読める・そのまま書ける・diffが取れる・Git管理できる Excel .xlsx（バイナリ） → 変換（情報が欠落） テキスト .md（テキスト） → そのままAIが読める・書ける なぜAI駆動開発でExcelは嫌われるのか → ようやくAIが読める 3 / 16
4. REALITY Claude CodeでExcelを扱うとどうなるか 「読むたび・書くたびにスクリプト変換」という運用になり、コストと事故リスクを常に払い続ける 読み: openpyxl / pandas 等でスクリプトを書く → テキスト化 → ようやくAIが読める 自動で取れるのはセルの値だけ。セル単位のコメント・着色・結合は、種類ごとに専用の抽出処理を書き足せば取れるが、その分の実装とトー クンが増える 図形（テキストボックス・吹き出し等）はほぼ取り出せず、本当に欠落する 書き: AIがスクリプト経由でセルを操作 → 描画結果を直接は確認できず、人間がExcelを開いて目視確認 AIに見せることも一応可能（xlsx→PDF→画像化）だが、変換工程とトークンをさらに積むことになる レイアウト崩れ・書式破壊に気づきにくい。方眼紙Excelはほぼ再現不能 毎回の変換処理でトークンと時間を消費し続ける なぜAI駆動開発でExcelは嫌われるのか 4 / 16
5. Excel資料も、書かれた当時は間違いなく資産だった AIと一緒に直せるドキュメントは資産 AIが読めないドキュメントは負債 変わったのは資料ではなく前提 ── 開発の隣に常にAIがいる時代になった。 この分岐は今後、プロジェクトごとに明確な差になって現れる なぜAI駆動開発でExcelは嫌われるのか 5 / 16
6. COMPROMISE どうしても Excel を使うなら 正しく「表」として扱うこと。それでも余計なトークン消費は避けられない 1シート1表・ヘッダ1行・セル結合禁止・図形/方眼紙レイアウト禁止 正しい「表」なら、CSV / Markdown への機械変換が安定する それでも読み書きのたびに変換を挟むので、余計なトークンを消費し続けることは留意する 結論: データは「表」として持ち、ドキュメントはテキストへ ここから先は、用途別の置き換えツール構成 なぜAI駆動開発でExcelは嫌われるのか 6 / 16
7. OVERVIEW 置き換えの全体マップ Excelの用途を分解すると、それぞれにテキストベースの代替がある Excelでやっていたこと 置き換え先 文書・手順書 Markdown + VSCode拡張 拡張で「書きにくさ」を解消 納品用ドキュメント Vivliostyle / Pandoc MarkdownからPDF・Word化 テーブル定義書 tbls スキーマから自動生成 フロー図・UML Mermaid / PlantUML / D2 / draw.io テキストから図を生成 汎用的な表 Markdownの表 VSCode拡張でほぼ足りる スケジュール管理表 GitHub Projects / Jira / Backlog 等 Git連携できるサービスへ 議論用の図形お絵かき FigJam / Miro / Excalidraw なぜAI駆動開発でExcelは嫌われるのか ポイント ホワイトボード専用ツールへ 7 / 16
8. TOOLS 01 — MARKDOWN Markdownを書きやすくする: VSCode拡張 「Excelの方が書きやすい」問題は、拡張でほぼ解消できる Markdown All in One ショートカット・目次生成など、Markdown執筆の基本装備 Markdown Table 表の整形・編集を支援。表を書くストレスを軽減 「Excel to Markdown Table」系拡張 Excel / Googleスプレッドシートで範囲コピー → 貼り付けで Markdown テーブルに変換 既存のExcel資産をMarkdownへ移行するときにも効く なぜAI駆動開発でExcelは嫌われるのか 8 / 16
9. TOOLS 02 — PUBLISHING 納品物はPDF / Wordに: Vivliostyle と Pandoc 「客先にはPDFやWordで出す必要がある」も、テキスト起点で解決できる Vivliostyle CSS組版で Markdown → 美しいPDF。デザインの自由度が高い Pandoc Markdown → PDF / Word（docx）など多形式に変換。Word納品の要件にも対応 ソースはMarkdownのままGit管理し、出力形式は納品時に選ぶだけ Markdown（Git管理） なぜAI駆動開発でExcelは嫌われるのか → Vivliostyle / Pandoc → PDF / Word で納品 9 / 16
10. TOOLS 03 — DB SCHEMA テーブル定義書は tbls で自動生成 テーブル定義書は「書く」ものから「生成する」ものへ tbls: DBスキーマからテーブル定義書を Markdown で自動生成する Go製CLI カラム名・型・制約・インデックス・外部キー、ER図の作成まで可能 手書きの定義書Excelは、必ず実体とズレていく 生成なら常にスキーマと一致 ── 「ドキュメントの鮮度」を人が保守しなくてよい なぜAI駆動開発でExcelは嫌われるのか 10 / 16
11. WORKFLOW tbls を軸にした運用フロー 「ドキュメントが常に正」ではなく「スキーマが常に正」の運用に変わる 初回 テーブル案を表で書く 以降 スキーマ変更 → → AIでDDL化 tbls再実行 → → スキーマ作成 → tblsでドキュメント生成 ドキュメント更新 初回のテーブル案は、スプレッドシートでも何でもよい（正しい「表」であれば） 応用: ドキュメント側を直してAIに渡し、スキーマを変更 → tbls再実行 指示用に修正したドキュメントは破棄してよい ── 正はあくまでスキーマ なぜAI駆動開発でExcelは嫌われるのか 11 / 16
12. TOOLS 04 — DIAGRAM フロー図・UML図もテキストで 図もテキストで書けばdiffが取れ、AIに描かせて直させることができる Mermaid / PlantUML: テキストから図を生成する定番。GitHub等でそのままレンダリング D2（Terrastruct製）: コンテナのネスト・アイコン・コネクションのラベル管理が綺麗 CLIでSVG/PNG出力、VSCode拡張でプレビュー可能 レイアウトエンジンは無料のELKあり。有料のD2 Studio（手動編集ツール）もある draw.io（diagrams.net）: どうしても手で図形を動かしたい人の受け皿 保存形式はXMLテキストなのでGit管理可。ただし座標入りXMLでAIとの相性は△ 使い分け: AI起点なら Mermaid / D2、手作業起点なら draw.io なぜAI駆動開発でExcelは嫌われるのか 12 / 16
13. TOOLS 05 — OTHERS 残りの用途: 汎用的な表・スケジュール・ホワイトボード 残りの用途も「Markdownで足りるか」「専用ツールに任せるか」で片付く 汎用的な表: Markdown + VSCode拡張でほぼOK 何かと連携したいなら、YAMLでデータを持つ自作ツールという選択肢もあるが最終手段 スケジュール管理表: Excelガントチャートをやめ、Git連携できるサービスへ GitHub Projects / Jira / Backlog / Redmine 等 議論用のホワイトボード: Excelの図形+矢印お絵かきは専用ツールへ FigJam / Miro: リアルタイム共同編集の定番 Excalidraw: OSS。保存形式がJSONテキストでVSCode拡張あり → 図ごとGit管理できる なぜAI駆動開発でExcelは嫌われるのか 13 / 16
14. OBJECTION 「Excelは図形でコメントできてレビューが便利」への回答 テキストベースなら、レビューコメントすら構造化データになり、AIが反映まで代行できる 方法1: PDF注釈 → AI反映 PDFの注釈は画像ではなく構造化データ。「ページ・位置・本文・対象テキスト」を機械抽出できる（OCR不要） 方法2: PRレビュー（本命） GitHubのPRで行単位コメント → AIがコメントを読んでそのまま修正。AI駆動開発と最も相性がよい Excelの図形コメントは「見た目の情報」── AIに渡す時点で欠落する側に戻ってしまう 方法1 Vivliostyle等でPDF化 なぜAI駆動開発でExcelは嫌われるのか → 人がPDFにコメント → AIが注釈を抽出 → Markdownに反映 14 / 16
15. SUMMARY まとめ ドキュメントをテキストにすることが、生成AI活用の土台になる Excelドキュメントはバイナリゆえに生成AIと相性が悪い（変換コスト・情報喪失・トークン消費） どうしても使うなら「正しい表」として。ただしトークン消費は残る 用途ごとの置き換え先はそろっている Markdown + VSCode拡張 / Vivliostyle・Pandoc / tbls / Mermaid・D2・draw.io / FigJam・Excalidraw / Git連携サービス AIが参照でき、コードと同時に直せるドキュメントは「資産」── テキスト化はその第一歩 なぜAI駆動開発でExcelは嫌われるのか 15 / 16
16. MD CLOSING Excelを嫌うのではなく、役割をテキストベースのツールへ AIが読める・書ける・レビューできるドキュメントへ テキスト化で、ドキュメントを資産に ご清聴ありがとうございました