VS Code + GPT-5.4 と会話しながら、アプリ開発をかなり広い範囲で進めた話

Last updated at 2026-03-20Posted at 2026-03-20

はじめに

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

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

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

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 が主体的に実装を進める、という分担はかなり実用的だったように思います。少なくとも、ある程度のソフトウェア開発の専門性を人間側が持っていると、どこで介入すべきか、何をどう指示すべきかが分かるので、より効率よく作業させられるのではないかとも感じています。