「無料版Copilot、やるやん!」Gemini 3.5 Flashの仕様書×エージェント機能で、レトロなWebアプリを爆速ビルドした話

はじめに

今回の試みでは、VSCode拡張機能のGitHub Copilot 無料版で「どこまで実用的なWebアプリを作れるか」を検証するために「モールス信号デコーダー」を作りました。結論として、仕様を先に整理しておけば、思いついたものを短時間で作って GitHub Pages に公開するくらいなら無料版でも十分に実現できる という印象です。なお、AI をうまく使うには、spec.md のような設計書や、改善点をまとめるメモのような人間側の整理能力が必要だと改めて実感しました。

きっかけ

参考にしたのは、Dave Nathanson 氏(アマチュア無線コールサイン: KG6ZJO)の「Morse Code Recieve Decoder Chart(a-z)」です。モールス記号のツリー構造が視覚的に分かりやすく、今回のアプリのベースとして適していました。

ビジュアルモールス信号デコーダーの完成イメージ
実際に作ったものがこちら

作成の流れ

1. 仕様を作る

まずは spec.md を用意して、画面構成・機能要件・デザイン方針を整理しました。ここでは Gemini 3.5 Flash を使って仕様書を作成しています。

作成した際のプロンプトがこちら:

※添付画像はこちらから拝借しました

結構、雑な指示ですがGemini 3.5 Flashが優秀なのでいい感じに文脈を埋めてくれました。できあがったものをレビューしましたが、1箇所修正しただけでした。

2. 画面要件・レイアウト (UI/UX Layout) のセクション

  • Before: 添付画像のトポロジーを完全再現
  • After: 5.1 モールス符号マッピングおよびツリー定義のトポロジーを完全再現

spec.mdの全文はGithubを見てください。

2. 実装は GitHub Copilot に任せる

実装本体は index.html にまとめ、HTML / CSS / JavaScript を一括で生成してもらいました。無料版の Copilot でも、単一ファイルの Web アプリならそこそこ良いものが作れました。

3. UI の問題点を Playwright で検証

最初の実装では、レスポンシブ対応がまだ不足していました。そこで、Copilot にレイアウトを検証し、修正を依頼しました。

投げたプロンプトはこちら:

Copilot はこのプロンプトを受けると、Playwright で実際の画面サイズを測定しようとしました。人間の私は提示されたコマンドの実行許可を与えただけで、どこで横方向・縦方向のはみ出しが起きているかを確認してくれました。その後、改善案をまとめて修正を入れてくれています。

改善内容は、adr01.md にまとめた内容に沿っています。ここで少しだけセルフツッコミを入れると、仕様変更のたびに「ADRを作るクセ」がついていたため adr01.md のようなファイルを作ってしまいました。実際にはこれは ADR ではなく、改善メモのような整理ファイル です。

主な修正点は次のとおりです。

  • タブレット・モバイルでの縦方向のオーバーフロー対策
  • SVG エリアの高さ調整
  • body のスクロール制御見直し
  • 小さい画面向けの余白・間隔の圧縮

adr01.mdの全文はGithubを見てください。

4. 人間がやったこと

人間側でやったのは、軽微な文言の修正と最終確認です。Copilotで実装を進め、UIの問題点を Playwrightで検出・修正してもらった後に、git commitしただけです。

どこまでできたか

無料版の Copilot で、以下のようなことは十分にできました。

  • 単一ページの Web アプリ作成
  • SVG を使った視覚的なモールスツリー描画
  • ボタン・キーボード入力の実装
  • タイマー駆動の自動確定
  • レスポンシブ対応の改善

リポジトリと公開ページ

まとめ

  • 仕様を先に整理しておけば、無料版の GitHub Copilot でも短時間で実用的な Webアプリを作れる(着手から公開まで1時間でできました)
  • UI の改善は Playwright を使うと、検証と修正がかなり効率化できる
  • spec.md のような設計書や、改善メモのような整理ファイルは、AI との協業を安定させる
  • 今回の制作では、AI で実装を進めつつ、人間が最終調整を担う流れが有効だった

今後の方向性

今回の spec.md と adr01.md をベースに、Antigravityで作り直すと、より体系的な再実装の道筋が見えてきそうです。特に、UI の改善点が整理されているので、アーキテクチャや実装方針を見直しながら進めるのが面白そう。(そういえば、以前もUIに苦しめられたことを思い出しました)

また、ロジックのテストをしっかり残したいなら、Playwright のテストも入れたいですね。今回のように UI の見た目や挙動が変わるプロジェクトでは、画面の回帰を防ぐ意味でも、テストを先に用意しておくのが良さそう。

この記事は役に立ちましたか?

⭐をクリックして評価してね!

Average 5 / 5. 投票数: 1

おめでとう!あなたがこの記事の最初の評価者です

役に立たなくて申し訳ありません…!

この記事の改善点を教えていただけますか?

SNSでもご購読できます。