はじめに

今回、xlsx2md の開発では VS Code と OpenAI GPT-5.4 を使いました。出発点はとても単純で、「xlsx から markdown が欲しい」という私の指示です。

その後、直感的なイメージよりもかなり広範な作業が GPT-5.4 で実現できたことが印象的でした。コード生成だけでなく、仕様書、テスト、GitHub 上の文面作成まで含めて進められたので、その記録をここに残しておこうと思います。

なお、これはいわゆるバイブコーディングとは違うんだろうなと思っています。骨子になる部分は人間から伝えていて、ある程度の方針や計画も先に共有していたからです。とはいえ、与えていた情報量そのものはそこまで多くありません。その上で、実装のかなりの部分は GPT-5.4 が主体的に担当したのです。

初出: 2026-03-20
更新: 2026-03-20

VS Code + GPT-5.4 で何を作ったのか

今回作ったのは、xlsx2md という Single-file Web App です。Excel (.xlsx) をブラウザ内でローカルに読み込み、地の文、表、画像などを Markdown として抽出します。

xlsx2md そのものの紹介については、先に公開した次の記事を参照してください。

https://qiita.com/igapyon/items/cfbbc0d6112059b26522

このツールは、単に Excel を別形式へ変換するためのものではありません。Excel ブックを、生成AI に渡しやすいテキストへ変換することを主目的にしています。ブック全体をまとめて処理でき、サーバへアップロードせずに動作し、変換結果は Markdown または ZIP として保存できます。

扱いたかったのは、きれいに定義された表データだけではありません。日本の業務文書や設計書で見かけるような、地の文、画像、罫線ベースの表、いわゆる Excel 方眼的なシートも対象に含めたかったため、その方向で GPT-5.4 と開発を進めました。そのような期待に沿う既存アプリを見つけられなかったことも、このツールを自分で作ろうと思った理由の一つです。嗚呼、結果論としてはほとんどの部分を GPT-5.4 が担当したのですけれどね(笑)

技術的には、ブラウザで .xlsx を読み込み、ZIP として展開し、その中にある XML や画像ファイルを解析して Markdown を組み立てます。Excel 解析専用ライブラリには依存せず、スクラッチで組み立てていく方針を取りました。

つまり今回作ったのは、Excel ブックを生成AI向け Markdown へローカル変換するための OSS です。そしてこの記事では、そのツール自体の紹介ではなく、その OSS を VS Code と GPT-5.4 を使ってどのように作っていったのかを扱います。

最初に人間が与えた要件と制約

伝えたのは機能要求はもちろん、それだけではありません。Web ブラウザだけで動くこと、Single-file Web App であり続けること、外部と通信しないこと、UI は Material Design 3 にすること、lht-cmn という既存コンポーネント資産を使うこと、TypeScript で開発すること、Apache License 2.0 で公開することなど、かなり上位の設計条件をチャットで指示しました。

さらに、.xlsx の解析はスクラッチでやること、共有文字列のような特徴的な仕様をちゃんと扱うこと、テーブルは罫線情報を手がかりに Markdown テーブルへ落とすこと、グラフは見栄え再現をせず割り切ること、図形は少なくとも v1 では割り切ることも伝えました。

実装の途中で人間が介入したポイント

実装が進んでから追加した指示もあります。たとえば数式解析で同種のバグが頻発したときには、BNF を使ってパーサーを作ってそれを使用するように伝えましたし、main.ts が大きくなってきた段階では分割して整理するように伝えました。超巨大 main.ts の分割は GPT-5.4 は自発的には実施してくれなかったので、指示が必要でした。Markdown 出力についても、文法衝突を避けるためのエスケープや、地の文をリスト - に寄せる扱いなどを途中で指示しました。

GPT-5.4 が主体的に担った範囲

一方で、GPT-5.4 に任せた範囲もかなり広いです。ソースコードの実装だけでなく、設計 Markdown、仕様文書、テスト記述、テスト実行、さらに GitHub の PR 文や Release 文の作文まで依頼して担当してもらいました。私はコードや Markdown を直接手で編集するのではなく、要求を伝え、出力を確認し、必要に応じて方向修正する形で進めました。

驚くべきことに、人間からの指示はかなり限定的なものでした。たとえば、数式でキャッシュ値も AST 解析も使えなかった場合に、もとの式を出力するというフォールバック設計は、GPT-5.4 側で自然にそうなっていった部分です。docs/xlsx2md-spec.md や docs/xlsx2md-impl-spec.md のような仕様文書も、基本的には GPT-5.4 に作文と更新を任せています。

人間が最後まで持った役割

完全に AI 任せだったわけでもありません。GPT-5.4 から「どのようなテストデータが欲しいか」という質問をしてもらい、その回答に従って Excel のテストデータを人間が作成しました。作られたアプリの最終的な動作確認も人間が担当しました。Git 操作や GitHub 操作については GPT-5.4 側がやりたがったものの、それは断って人間が担当しました。

つまり、人間がやっていたのは要求定義、設計判断、方向修正、入力データ準備、動作確認、公開運用です。GPT-5.4 は、その条件の中で実装担当としてかなり広く担当していました。この役割分担で OSS として公開できるところまで持っていけたのは、かなり印象的でした。

専用プロンプトなしでどう進んだのか

今回、これ専用の固定プロンプトは作っていませんし、使ってもいません。一方で、開発の途中ではいくつかの Markdown 文書を GPT-5.4 に作成・更新してもらっており、結果としてそれらが文脈共有の役割を果たしていたのだと思います。

専用プロンプトで厳密に制御したというより、会話の蓄積と、途中で整備された仕様書や設計 Markdown が、実質的な行動指針になっていた感覚です。あわせて、TODO.md をきっかけに作業を進めるように指示していました。

これはバイブコーディングとは何が違うのか

これはいわゆるバイブコーディングとは違うんだろうなと思っています。骨子になる部分は人間から伝えていて、ある程度の方針や計画も先に共有していたからです。とはいえ、与えていた情報量そのものはそこまで多くありません。

ただし、コアとなる要件や外してほしくない条件を先に渡したうえで、実装のかなりの部分は GPT-5.4 が主体的に担当しました。そこは、雰囲気でコードを出させていく進め方とは少し違っていたと思います。私はバイブコーディングには不案内なので、この理解自体が間違っているかもしれませんが、少なくとも自分の感覚としてはそうでした。

このやり方で良かったこと

まず良かったのは、直感的なイメージよりもかなり広い範囲を GPT-5.4 に任せられたことです。コード生成だけでなく、仕様書の作文、テスト記述、テスト実行、GitHub 上の文の作文まで進められたのは、かなり印象的でした。

また、人間が細部の実装をずっと手で書かなくても、骨子や制約を伝え、途中で方向修正し、必要なデータを用意することで、OSS として公開できるところまで持っていけたのも大きな発見でした。

さらに、専用プロンプトを事前に作り込まなくても、会話の蓄積や Markdown 文書、TODO.md を足場にして開発を前に進められたことも良かった点です。思っていたよりも、会話そのものが十分な作業基盤になっていました。これには GPT-5.4 だからこそ可能だった側面もあると理解しています。少なくとも私の記憶では、5.1 や 5.2 のころには、ここまでは難しかったはずです。

難しかったこと

一番困ったのは、Rate limits の残りを気にしながら進めなければならなかったことです。この xlsx2md を作るのに、ChatGPT の 2 週間分のリクエスト枠を消費しました。

今回のように、実装だけでなく、仕様書、テスト、動作確認の往復、修正指示、GitHub 上の文の作文まで含めて GPT-5.4 をかなり広く使うと、当然ながらリクエスト消費も大きくなります。趣味アプリなので、まあいいか、と思いつつ進めていましたが、それでも残量は気にしながら進めました。使い切ってしまうと困りますからね。

とはいえ、ただ消費するままにしていたわけではありません。実装に対応する Markdown 文書を適切な粒度で作成し、それを GPT-5.4 に読んでもらうことで、Rate limits の消費をできるだけ抑えるように務めました。

まとめ

今回の体験を通じて、VS Code と GPT-5.4 を使うことで、アプリ開発のかなり広い範囲を会話中心で進められることが分かりました。特に、コードだけでなく、仕様書、テスト、GitHub 上の文の作文まで含めて進められたのは印象的でした。今回は趣味アプリだったこともあり、かなり実験的に踏み込んで試せたのも良かったと思っています。

その一方で、何を作るか、何を守るか、どこで介入するかは、やはり人間が持つべき役割でした。骨子と制約を人間が伝え、その中で GPT-5.4 が主体的に実装を進める、という分担はかなり実用的だったように思います。少なくとも、ある程度のソフトウェア開発の専門性を人間側が持っていると、どこで介入すべきか、何をどう指示すべきかが分かるので、より効率よく作業させられるのではないかとも感じています。

想定読者

VS Code と GPT-5.4 を使った実際の開発体験に関心がある人
生成AIにコードだけでなく仕様書やテストまでどこまで任せられるか知りたい人
自分ではコードをあまり書かずにアプリ開発を進められるか試したい人
人間と GPT-5.4 の役割分担をどう組むとよいか気になっている人

実行ページとソースコード

ブラウザですぐ試せる実行ページは、次の URL です。

https://igapyon.github.io/xlsx2md/xlsx2md.html

ソースコードは GitHub で公開しています。

https://github.com/igapyon/xlsx2md

Appendix

最初に与えた要件と制約

xlsx から markdown が欲しいという要求
Web ブラウザのみで実行可能にすること
Single-file Web App であり続けること
外部と通信しないこと
TypeScript で開発すること
UI は Material Design 3 にすること
Material Design 3 のために lht-cmn という共通コンポーネントを使用すること。既存資産の活用も意図
既存の自作アプリを参考にすること
Apache License 2.0 で公開すること

実装方針として与えたもの

.xlsx 解析はスクラッチで実装し、他ライブラリには依存しないこと
.xlsx の共有文字列のような特徴的な仕様もきちんとカバーすること
テーブルを抽出して Markdown テーブルにすること
特に、罫線情報を元にテーブル領域を導出すること
グラフは見栄え再現をせず、割り切ること
図形は少なくとも v1 では割り切ること
TODO.md に記録しながら作業を進めること
開発した部分の自動テストを追加すること
見つけたバグに対応する自動テストを必要に応じて追加すること
出力される Markdown が生成 AI にとって読みやすいものになっていることを確認すること

途中で追加した修正指示

あらためて Single-file Web App であり続けること
あらためて外部と通信しないこと
main.ts が巨大になってきたため、分割して整理すること。分割単位は会話して決定
数式解析で同種のバグが頻発したため、BNF を使ってパーサーを作成して、そのパーサーを用いて解析および対応すること
出力文字が Markdown の文法と衝突しないように、必要な箇所をエスケープすること
地の文は Markdown の通常段落ではなく、必要に応じて - のリストにすること
小さい自動テストをこまめに作ること
Excel 方眼なサンプルデータを作成し、スクリーンショットも添えて、これに対応するようにすること

GPT-5.4 側から出てきて印象的だったこと

表の抽出ロジック
数式でキャッシュ値と AST 解析の両方が失敗した場合に、もとの式を出力するフォールバック設計
docs/xlsx2md-spec.md や docs/xlsx2md-impl-spec.md のような仕様文書の作文と更新

GPT-5.4 に任せた範囲

ソースコードの実装
設計 Markdown や仕様文書の作成と更新
テスト記述とテスト実行
GitHub の PR 文や Release 文の作文

人間が担当した範囲

要求の提示
実行形態、配布形態、UI、ライセンスなどの設計判断
UI の見栄えに関する不同意の伝達
途中での方向修正と追加指示
GPT-5.4 からのリクエストに応じた Excel テストデータの作成
手動テストによる動作確認
Git / GitHub 操作
GitHub の Release を打つタイミングの判断