最近 AIを用いたアプリ開発、いわゆるVibe Codingをしたんですがコーディングの99%をAI任せでほぼAI任せでアプリリリースまでたどりつけたので記念記事です。
GW中にちょこちょこ作業して実働10時間ぐらい、開発はじめてから一週間ぐらいでアプリのリリースまでたどりつけました。
日々投稿されるVibe Codingの記事を参考にさせてもらってるんですが、開発工程のうちAIと開発者がどこを担当しているのか明確にしている記事をあまり見た覚えがないので、自分で実施したこととAIに任せたことについて焦点を当てて書きます。
AIは主にCursorエディタでClaude3.7を使用しました。
本記事で指すAIはCursor上のClaudeです。
ほんで何作ったん？
Visual Studio Codeの拡張機能としてCode Visionという関数の呼び出し関係をグラフとして表示するものを作成しました！
現状、C/C++, Pythonに対応しています。よかったら使ってみてね。
https://marketplace.visualstudio.com/items?itemName=CodeVision.codevision&ssr=false#overview
拡張機能をアプリと呼ぶのは若干違和感があるかもしれませんが、広義な意味では言って良いのかなと。
筆者について
どんな人が作ったか参考として簡単に。
ソフトウェアエンジニア歴：10年いかないぐらい
仕事ではC/C++, Python, +αを主に使用
VS Codeの拡張機能開発は初めて
VS Code拡張機能開発に必要なWeb系の言語(JavaScript, TypeScript, HTMLなど)はほぼ書いたことがない
Cursor使い始めて2~3ヶ月ぐらい
開発の流れ
開発の流れとしては、ウォーターフォール開発チックに行い、コーディングとテストに関しては数機能実装するたびに挙動のテストして、またコーディングに戻るって形で進めました。
AIと開発者の主要な担当作業を図示しているとこんな感じで進めました。
(チャットによる指示は省いてます)
まるで外注に開発のほぼ全てを丸投げしてる上流工程の人みたいになってますね。
AIの生成物の確認に関して図中で記載してませんが、ドキュメントは目を通してソースコードについては問題が起こったときのみ確認してました。
要件定義・設計工程
0→1の小規模開発だったため、要件定義と設計は同時に行いました。
仕様書 兼 設計書の作成
“どんなものを作りたいのか”、”どのように実現するか”を鮮明にするために仕様書 兼 設計書作成から着手。
「こんな感じの作りたいんだけど～」、「開発する上で明らかにすべきこと教えて～」といった感じでClaudeとチャットしながら、最終的にドキュメントとしてまとめてもらいました。
自分だけだと1人日以上かかりそうなものを、1時間足らずでまとめられたのは非常に楽。
実際に作った設計書は下記に公開されてるのでよければ。
https://github.com/fujarenpaw/CodeVision/blob/main/doc/butterflyFunction-conceptualDesigh.md
技術選定
今回のソフトを開発するうえで、図形描画とコード解析の方法については自前で実装するのは大変であり、詰む可能性となりうると思っていたので設計時点であたりをつけることにしました。
図形描画ライブラリの選定
Cytoscape.js
D3.js
Vis.js
ライセンス的に問題なくやりたいことが実現できそうで手触りが良さそうな3つのライブラリを候補として検討。結果的にCytoscapeを採用することに決めました。
コード解析方法の検討
LSP（Language Server Protocol）
Call Hierarchy API
技術選定もClaudeに実現手段の候補を挙げてもらい、取捨選択だけ自分で行うという形を取っています。
類似ソフトウェアの調査
開発するソフトウェアについて、既に同じようなものがあり車輪の再発明にならないよう、この時点で類似ソフトウェアの調査しました。
実はここで早々に車輪の再発明に陥る事態が発生。
関数の呼び出し関係を図示したものを「バタフライグラフ」と呼ぶものと思って調査し、開発しようと判断したんですが、「コールツリー」として検索してみると自分が作りたかったものがチラホラと・・・。
コーディング工程
コーディング工程のソースコード、ドキュメント作成は99% AI任せで自分自身が編集したところは1%未満でした。
想像では8割ぐらいまでAIが作ってくれて2割ぐらいは自分で調整しないといけないかと思っていたので、これは本当に驚き！
雛形作成
まっさらなプロジェクトから、実現したいソフトの下記のような最低限の機能だけを実装した雛形を用意し、早々に次項のtodoリスト作成へと移行。
関数を選択して右クリックしたらバタフライグラフ作成メニューが表示される
そのメニューをクリックしたら、選択した関数のノードが表示される
todoリストの作成
雛形作成後、早い段階で実施すべきtodoリストを設計書からAIに生成させました。
これは実施すべき事とどこまで実現出来ているかが把握しづらくなりそうだったことと、Cursorで指示を一々打つのが面倒になってきたため。
途中からは「todo.mdの1-2対応して」みたいな感じで指示するだけでよくなったので、todoリストを早々に準備するというアプローチは結構いいんじゃないかと。
1つ1つの項目は早ければ数分で対応できるレベルのものなため、JiraやRedmineなどのちゃんとしたプロジェクト管理ツールを使わずテキストベースです。
実際に作ってもらったtodoリストは公開していますので、こちらもよければ。
(最低限リリースできるところまでなのでまだ終わってない項目が多々・・・)
https://github.com/fujarenpaw/CodeVision/blob/main/doc/todo.md
コーディング
todoリストに基づき、黙々とAIに対してコーディングの指示。
AIにコーディング指示した際のソースコードのパターンとしてはだいたい以下の3ケースでした。
最初からそれなりの完成度のソースコードが出来上がるケース
振る舞いが想定と違ったり、うまく動作しないケース ただし、ログや画像を入力として与えるとAI自身で問題を解決できる
AIが自力では解決できないケース。 ただし、変更点を一度破棄して動作が安定しているソースコードに戻してから再指示すると1や2のパターン
現段階では「AIが解決できないから開発者である僕自身がコードを書き直す」ということは一度もありませんでした。
テスト工程
ユニットテスト作成
ユニットテストもAIにまかせて作ってもらったんですが、Web系のユニットテストのお作法を知らず、正直現段階では機能してません。
ユニットテストに関しては、お作法含め 今後着手しようかなと。
受け入れテスト
数機能コーディングしたらその時点で挙動が意図、想像通りかちょこちょこ確認しました。
主に外部品質を確かめる受け入れテスト相当の確認を行い、問題がなければGitコミットという流れで。
第一目標として必要最低限の機能を作ってリリースすることを優先していたため、内部品質については深く追求しない方針を取りました。
バタフライグラフの挙動テストはAIに任せることができなかったため、この部分は自分が全て担当することに。
ひたすら関数を選択してバタフライグラフを生成し、グラフの挙動に問題がないかを確認する作業の繰り返しでした。
開発者としてのメインの作業がデバッガーでつらい・・・
リリース工程
ドキュメント整備
拡張機能としてリリースする準備として、以下のドキュメント類を整えました。
とはいえ、実際にはAIに「プロジェクト内を参照してドキュメント生成して」と指示するだけで完結。
Readme
ライセンス
コントリビュートガイド
この辺も自分ひとりで作ったら、数時間はかかるものですがAIに指示するだけで本当に一瞬でした。
VS Codeへの拡張機能登録
VS Codeの拡張機能登録については、AzureアカウントとVisualStudioのパブリッシャー登録が必要だったため、この部分は完全に手作業で進めることに。
最終的に拡張機能として登録する際は、CUIでパッケージを作成した後に登録作業を実施。
package.jsonにカテゴリやタグなどを記載するとリリースページにも反映されるのですが、その各種設定も「プロジェクト内参照して適切な値設定して」と指示するだけでOKだったので、地味に助かりました。
Vibe Codingの懸念
ほぼ未経験の言語を用いた開発でも短時間リリース出来て素晴らしい！人間が手動で行うソフトウェア開発はオワコン！と言えるかというと、いくつか懸念があり・・・。
言語に対する理解は全く上がってない
内部品質は気にしておらず問題の起こらない限り、ソースも見ないような姿勢で開発を行っていたのでソフトの大部分を占めるTypeScriptの理解は開発当初からほぼ変わってません。 当たり前の話ですが、仕様だけを書いて、外注さんに設計・実装を依頼する上流工程のエンジニアが年々設計・実装能力があがるかと言うとそんなわけないよねって話ですね。
コーディングを99% AIに任せられたのは僕の使い方が良かったから？
残念ながらそうではないと思っています。
主な要因としては以下の2点なのかなと。
開発言語、環境に関する知識が少なかった 知識が豊富にある領域だと「ソフトウェアとしてどうあるべきか」みたいな開発者の思想が出やすいですが、拡張機能開発、Typescriptに関する知識がないからこそ「動くならとりあえずいいんじゃない？」とAIに任せられたのかなと。
小規模開発で壁にぶつかる前に完成した 内部品質を軽視すると規模が大きくなるにつれて依存が複雑になったりし、一部を変える事で他にも無用な影響がでてしまい開発が進まない みたいなことが発生しそうですが、小規模であったため未だぶつかっていないだけなのではないかと。
もしかしたら、追加で「実現したいことがAIの得意な領域だった」、「AIの得意な言語だった」あたりもあるかもしれません。
ソフトはそれっぽく動くけど中身は見てないよってジュニアエンジニアが今後量産されそうだなというのが一番怖いですね。
終わりに
Vibe CodingにおけるAIと開発者の担当工程について書いてみました。
テスト工程についてはあまり上手に活用できなかったので、今後試行錯誤してみます。
今回作った拡張機能についてはお仕事で使いながらちょこちょこ改善、変更していこうかなと思ってます。
開発規模が大きくなる過程で内部品質を軽視したことによって開発速度の停滞や破綻が起き始めたら、それはそれで面白いと思っているので、その時はまた記事を書きます。