ほぼAIでWebアプリ作ったので、意識したことを振り返ってみる
非エンジニアがAI駆使してサービス作った話
初めまして。ぽにーと申します。
Xのアカウントはこちらです。
https://twitter.com/ponystark25
タイトル通り、非エンジニアがAIを駆使して、Webアプリを作ってみたお話です。
やっと公開できる最低限レベルに達することができたのかなと思ったので、これを機にまずは、サービスの紹介をさせてください。
そして、今後の誰かの参考になるよう、要点を記事にしておこうかと思います。
ちなみにAI利用が8 ~ 9割、残りが人力です。
Tickioというサービス（こちらは2024/12/17をもって公開を停止しました！）
サービス名は「Tickio」です。
一言でいうと「何にどれくらいの時間をかけたをシェアするソーシャルサービス」です。
コンセプトは、
「努力の指標は時間だけで良い」
「他人がかけた時間を見て自分の立ち位置を把握しよう」
です。
何かを新しく始める時や、何かについてより成長したい時、大体「効率的なやり方」とか「コツ」とか「センス」とかそういうものを気にしすぎたり、「自分にはセンスが無い」とか「もっと良いやり方があるはずでは？」とかグルグル考え始めて、途中であきらめてしまうか、そのまま興味が無くなってやめてしまうケースがあると思うんです。
ただ実際は意外とシンプルで「その道で結果出してる人、スキルを身に着けている人は、ただただそれに時間かけてる」という、それだけの事です。
学校のテストでA君の成績がめちゃくちゃ良い？自分は頑張ってるつもりでもA君には敵わない？自分はバカだからいくら勉強しても仕方ない？
「ま、A君は、君の3倍くらい勉強してるけどね」ってのが意外と真実だったりすると思います。
※一部のマジの天才を除く。ただあなたが見るべきはそこじゃない。
だから、あれこれ悩んでたり、ぐちぐち言ってる暇があったら、時間を淡々と積み上げよう！という事を、このサービスを通して誰かの気づきになったり勇気になったりすると嬉しいなと思い、作ってみました。
サービスの運用について
今後サービスとして運用継続するかは色々試行錯誤したうえで、急遽サービス閉じる可能性もあるかもしれませんが、サービス開発・運用のド素人が思い付きで作ったものなので、それは許してくださいｗ！
思いのほか受け入れられそうなものであれば、しっかり運営したいなとも思っています。
勿論現時点でこのサービスの性質とグロースするために必要なことはある程度の仮説はあるのですが、まあゆるゆると様子見をして細かな改善を重ねていければなと思います。
補足
本当に開発や運営の知見無いので、至らない部分があるかもしれないけど温かい眼差しで見守っててくださいｗ
では、深夜のテンションで思い付きで書いていきます
この記事の対象者
多分ここからが皆さん知りたい事ではないでしょうか。
正直本職エンジニアの方々は、この記事読まずとも、ちょちょいのちょいでサービス作れるので、ブラウザバックでも問題ないと思います。
想定している読者は、
ITやコーディングちょっとわかるけど、自分で0から作るのは少し難しい、みたいな方々です。
軽く前置きといきなりの見解
ちなみに、当初は記事で共有することなんて考えていなかったので、詳細な手順とか、チュートリアルはありません。
必要あれば、その内しっかりまとめるか、何か題材決めてチュートリアル用に0から作り直すかもしれないですが、ニーズ無いうちは無駄な労力をかけるのは避けようと思います。
まず、前提として私は本職エンジニアでは無いのですが、個人の趣味嗜好や今までの経験上、
コードちょっと読める、書ける
新しいコードを学習することに抵抗無い
趣味でたまに友達と開発したりしてる
公式のテクニカルドキュメント読むのに抵抗無い
何となくのITの勘所はある（大学は情報系、新卒で応用情報まで取得）
元々IT業界の人間だった（今は全く違う仕事）
といった感じの人です。
なので、まったくのIT初心者とはちょっと毛色が違います（本職エンジニアからすると、素人に産毛生えた程度ですが。。）ので、一応伝えておきます。
んで、今のうちに言っちゃいます。
開発やコーディングの知見が全くないと、AI駆使しても、個人で0からアプリを作るのは現状厳しい。というか多分そもそもアプリ作る以前に、開発においてAIを駆使できない。
マジのIT初心者の自覚ある方は、素直にITの基礎知識と、コーディングの基礎を半年～１年くらい勉強したほうが良いです。
いきなりのヘイトかもしれませんが、この記事が対象の読者の皆さんは「○○のAIサービスでアプリ一瞬で作れた！もうこれで良くない？エンジニア不要！？詳細はスレッド！」みたいなツイートは無視して良いです。
それで作れる自信ある方はこの記事見る必要ないです。それより少し大変な事やるので。
本当は、かなーーーーーーーーーーり前途多難なものです。
一連のフロー
んで、いきなり話が飛ぶのですが、自分がTickioを作った際にたどったフローは下記です。
アイデア思いつく
Claudeと会話して壁打ちし、アイデアを固める
ある程度固まったらv0でデザイン案を練る
1と2を繰り返して、要件をできる限り詳細に詰める、デザインも詰める
AIと対話して、詳細な技術仕様、DB設計に落とし込む
Cline（旧Claude-dev、VSCodeの拡張機能）で作成
（これが途方も無く長い。でも1からサービス作れない自分からしたらかなりのショートカットになっています。）
↑Githubのリンクだけど、VSCodeの拡張機能検索でも出てくる。
この記事はチュートリアルではないのですが、今回の経験を振り返り、要所要所で意識したことを語っていきたいと思います。
意識したこと①
利用する技術スタックは自分なりに結構意識しました。
ベースはNextJS(AppRouter)、TypeScript、DBはSupabase、認証はClerk、デザインはShadcnUI、DB操作はPrismaを利用しています。
ホスティングはVercelですが、Github連携で自動デプロイさせてます。
正直外部サービス利用しまくりなのですが、まあ、プロトタイピングだし良いかなと思いました。
あと、正直大規模に運用するためのインフラやアーキテクチャを自分は知らないというのもありますが、そんなの気にしてたら何も動けないので、とりあえず作り始めました。
では、なぜこれらを選んだのか。なんですが、NextJSは言わずもがな、ど定番のフレームワークです。AIもおそらくこれには詳しいので、深く考えずに選択しました。
TypeScriptも同じ理由ですね。あと、まあ静的型付けってやっぱり安心。
それ以外ですが、まず私は、素人に産毛が生えた程度なのでAWSとかそういったしっかり目のインフラサービスの知見が無く、利活用できる自信がありませんでした。そして知見が無いのにAIに何を指示するんだって話なので、AWSやAzureを使う選択肢がまずありませんでした。
その時点で、ホスティングやDBはVercelとかBaaSとかそういったものを利用する必要があるのですが、Supabaseは結構新進気鋭で有名であるので使ってみたかったのと、SQLは流石にAIわかるでしょｗということで、まあ、浅い理由ですが、選択しました。
認証なんですけど、Supabaseにも認証機能確かあるし、様々な有名サービスがあります。ただ、認証機能の開発に関して全く知見無いし、セキュリティのリスクを抱えたくなかったので、なるべく信頼がおける有名なサービスかつ、いくらAIに頼れるからと言っても、自分がAIのコードを評価できないので、できる限り少ないコードで実装できるものを探した結果、Clerkにたどり着きました。結構便利です。
他にも有名なサービス、NextAuthとかAuth0とかあるのは知っています。生じき正確に比較してないので、どっちのが本当に良いのかはわかりません。興味ある方は調べてみてください。
Shadcnuiはv0でデザイン案を練ると、嫌でも使うことになるのと、実際結構便利なのでまあ必要最低限で良いかなという雑な理由です。
そしてPrismaですが、最初はSQLを直書きするか、AIに指示を仰いで、自分の手を動かしてSupabaseのGUIをいじくりまわす形を考えていたんですけど、たまたま色々勉強したり調べていくうちに、Prismaにたどり着きました。
AIって皆さんご存じの通り、コンテキスト＋命令ありきで望み通りの動きをするのですが、Prismaは事前にスキーマを定義し、それを実際に利用してDB操作することが可能とでも言いますか、プログラマブルな要件定義？設計？ができることによって、AIへの命令時のコンテキストとしてスキーマファイルそのものが有効活用できるなと思い、知った瞬間に即採用を決めました。
技術スタックの話はこんな感じですかね。
今個人的に扱えるようになりたい技術系の話としては、
Remix、Cloudflare(Workers含む)、Hono、とかとかですかね。
TypeScript以外に何か言語使おうかなと思っているのですが、正直TypeScriptで事足りちゃっているのと環境が大分発展していて便利ライブラリもあるので、しっかりした理由が無い限りはTypeScriptを使い続けるかなと思っています。
意識したこと②
コーディング前は時間しっかり書けて良い、要件定義書、設計書類、かなり大事
まず、誰しも個人レベルで開発、しかもプロトタイピングする時って、頭の中でふわっと思い浮かんだものをとりあえず開発着手してみようって思うかもしれませんが、AIを利活用する場合は、話が変わります。
まずAIにやらせるときには言葉として支持する必要があり、かつその上で、本当に破綻せずに開発ができて、かつ運用も考えられるものを作りたいのなら、コーディング前のフェーズはかなーり大事です。
要件定義書
仕様書
設計書
シーケンス図
フローチャート
DBリレーションズ
その他もろもろ
正直思いつく要件定義、設計フェーズの成果物全部作って良いんじゃない？と思うくらいに大事です。
これがどんだけしっかり詰められてるかでそのあとの効率や破綻する/しないがガラッと変わります。
このあたりは気を抜くことなく、詳細に詳細に詰めていきたいです。
（余談ですが、これはもしかしたら今後AI駆使した開発の知見が世の中に溜まっていく過程で色々最適な形に洗練されていくかもしれません。）
もちろん、自分で作成する必要はありません、AIと壁打ちしては書き出してもらって、ダメだしして、考え直して、さらに壁打ちしてって流れで満足いくやつを書き出せばよいです。
自分が書くわけではないので、要件定義書を書くためのコストとか時間が無駄～とか、そういう従来のアジャイルなまたは個人開発で正しかった思想は、AI開発では真逆になると思います。
↑そして自分がTickio作ってる中での大きな反省点の1つでもあります。もっとドキュメント詰めておけばもっと早く効率的にできたのに、、、、
※実は今回のリリースにたどり着くまでに約3か月、3回プロジェクトが破綻し、今回(4回目のチャレンジ)も何度か破綻の危機がありましたけど、どうにかなりました。そして大分知見がたまったので今後はよりスムーズに開発できると思います。
勿論それと合わせて常にv0とも議論してください。納得いくUI、できる限りUIを詰めるのもかなり大事です。
ここで言う「詰める」は、おしゃれなデザインとかではなく、ユーザー目線で見たときのボタンの配置や全体の挙動や、導線、そういったものです。デザインのおしゃれさは、あなたが相当なデザインセンスやイメージを持って、AIに指示できない限りは、AI任せにするにはまだ早いので、あきらめてください（今は）。
あと、v0任せでshadcnui使って作れるものは味気は無いですが、無難なデザインにはなるので、そこまで汚いデザインになるかも？とかの心配は不要です。
意識したこと③
自分の手で調べる、自分の目で見る、自分の頭でも考える
AIに開発を任せるのは正直まだ不完全なところがあります。LLMの性質に起因するのでこれは時間の問題かもしれないですが、やはり指示通りにやらない、前やったこと忘れる、コンテキストも忘れる、いらない修正をしてしまう、Aを直す命令出したら、A直すのと同時にBに不要な修正加えて、エラー起こした挙句、エラー直してたらCまで修正加えやがった。みたいなこと、ちょくちょくおきます。
あと、特に自分は外部のライブラリを多用していたので、ライブラリのアプデがあると、書くべきコードも変わったりします。AIにはナレッジカットオフという概念が存在するので、古いコードで書こうとしてエラー起こしたりします。
↑これらの課題が、今は当たり前のように生じます。なのでAI任せと言いつつも生成されたコードの内容をきちんと確認したり、不穏な動きを見せたら、きちんと自分が手を動かしてGoogleやAI検索サービスで調べたり、公式Doc見に行ったりして、手修正します。
あと、プロジェクトが大きくなると、ファイル分割に伴い、1つのファイルや関連する数ファイル見てAIが修正するだけでは、上手く修正ができない時があります。その時は自分がコードを読み解き、正しい指示を出すかそのまま手を動かして修正する必要があります。
ここまで言いましたが、正直このあたりはトータルで見ると、そこまで時間がかかるものではありません。
意識したこと④
AIを信用しない
AIを推す記事なのに、何言ってんだこいつって感じですが、gpt3？3.5？からずっと何かしらかAIサービス触っている身からすると、頼りになるけど、自然と息を吸うように嘘をつきやがります。AIは。
というか、彼らはただの複雑な関数なので、悪意があるわけでもないです。
③に通ずることですが、間違いを犯して当たり前である、という前提で共同作業をすべきです。
意識したこと⑤
Gitをうまく活用する
いきなり開発の具体的な話になりましたが、③④あたりで、何となくわかると思いますが、人間のチェックも完ぺきではないので、気づいたらとんでもないびっくり仰天なやばい修正をAIはしてきたりします。
苦労して指示出ししてつけたちょっと説明がややこしい機能をやった実装できたのに、そのあとの別の実装で、なぜか削除しやがった。とか、DBからデータを取るロジックを変えただけなのに、なんかUIのレイアウトが崩れてぐちゃぐちゃになっちゃった。とか。
人間が開発するよりも、びっくりするような大きな不具合やバグ、なんならサービス壊すミスをします。
こういうのを平気でやってくるので、都度修正したものを保存する必要があります。
そこできちんとGitなりGithubなりを活用して、断面断面でやったことを保存していくと安心です。
後、きちんとmain、dev、featとか、よくあるGit戦略に合わせてGit運用したほうが良いです。
「あ、とんでもないミスをしたな」と発覚したら、Gitを使って前のコミットまで巻き戻すか、ブランチを切り捨てればOKです。
意識したこと⑥
指示する際は、なるべく具体的に、色々な情報を付け加える、AIが対処するまたは、原因分析する範囲をなるべく絞ってあげる（いらん事しないように）
なにか挙動がおかしい時、不具合修正したいとき
駄目な指示例
なんか動かないんだけど、直して
とりあえずエラーコードコピペ（これだけで動くときもあるが、もっと情報付け加えたい）
〇〇の画面の挙動がおかしい
画面まで実装できたけど、値が出てきてないよ（これで動くときもあるけど、ファイル分割が進んで行くと、次第に読み取れなくなってくる）
良い指示例
XXというファイルについてなんだけど、XXの処理をさせたあと、期待値としてXXを返してほしいんだけど、出てないから原因分析したうえで修正してほしい
きちんと要件と処理の流れを伝えて、それに照らし合わせてコードを見直してもらう
XXの画面のXXの項目があるんだけど、ここはXXのボタンを押した時にXXという流れで動いてほしい。けど、何故か今はXXのボタンを押しても、そのように動いていないくて、コンソールやターミナル見たらエラー出てたから、調査と修正して。ちなみに、DB確認するときちんと値が入っているから、DB側の問題ではないよ。 以下、エラー文ね XXXXXXXXXXX（ここにエラー文をコピペ）
要件と処理もそうだが、伝えられる周辺情報をできる限り詳細に、この場合だとエラー文も伝える
また、要件を伝えたうえで、きちんとここまではできてて、ここからができていないという話も伝える
この画面のこの項目がおかしいんだけど、ソースコード見てると、XXの引数が渡っていないように見えるよ、見直してみてほしい
今までAIに実装を依頼していたやり取りの流れで修正依頼も出したけど、実はコンテキスト長くなるとちょっと前にやったこと忘れたり、そもそも直接的に関係してなさそうなコードを見たり、見なかったりするから、人間がある程度わかっているなら、具体的なソースコードレベルで伝えてあげる
UIから一連の処理やロジックの流れを辿って、原因分析してほしい
これはこっちもいちいち原因特定するのがめんどい時に使ったりする、わりかし万能
意識した事⑦
プロジェクトの要件次第だから万能ではないが、なるべくPrismaなど（Prismaしかパッと思いつかなかった）、事前にスキーマ定義できるツールを使う
LLMは御存知の通り、指示や要件＋コンテキストで動くので、事前に余すことなく詳細に要件や仕様を伝えることが肝だったりします。その際にDB定義資料を作るのでも良いですが、Prismaなどのスキーマ定義してそのファイルをプロジェクトの一部として使って処理もできるツールを使うと、Clineに毎回要件定義資料を読ませるよう指示しなくても、Prismaのスキーマを適宜読み取ってくれ「たり」する（くれ「たり」する。重要なので2回言いました。ゆーて100%ではないが、要件定義資料よりは読んでくれる）
ここで言いたいことは、要件定義資料に代わるプログラマブルな定義ができるなにかをプロジェクト内で導入すると結構便利よ。というお話です。（Prisma以外でもそういった便利ツールあるならめちゃくちゃ知りたい）
余談ですが、「ソースコード読めば仕様がわかる」とかそういうのではなくて（ソースコードが間違っていたらAIは間違って仕様を理解しちゃうので）、「正しい定義を明示できて（Prismaの定義は大抵最初に要件決める時に定義してしまうので）かつ、それが実際のプロジェクトファイルとしても機能する」みたいなツールが今後のAIコーディングで重要になるのではないかと思ったりしています。
意識したこと⑧
リーダブルコードを意識して、コードやファイル、ディレクトリを作るように指示出しする
なんか「リーダブルコード」という単語を使い慣れてない人みたいなタイトルですが、まあ、ニュアンスは伝わるという事でｗ
人間でもよく言われていると思うけど、他人が読んで意味がわかるコードにしようねって話です。
特に人間はまだ「なんだこれ、、、意味わからん」で止まれるけど、AIは「勘違いという単語は俺の辞書にねえ！」という勢いで、勘違いしながら突き進み、修正してはいけない物をガラッと修正することがあるので、厳密には別物であることがわかるようにもファイル名や変数名、ディレクトリ構造は明確に目的や意図が読みやすいような命名を心がけ、また、コメントをAIにコーディングさせる時に残させるべきです。
そして、リーダブルコードの原則というかルールに従っていないプロジェクトに関しては、直しては行けないものは、なるべく指示出すたびにしっかり伝えるようにします。
例えばですが、
人口の計算と、お金の計算の2つの機能を作る必要があるとします。
人間ならば、おのずと別々の関数名を付けるかもしれませんが、AIは、人口の計算をする関数を「calculate」とつけて、お金の計算の関数は「calculateMoney」とつけたりします。
お金のほうは良いんですけど「calculate」だけでは何の話か分かりません。
これ作ってハイ終わり。となれば、良いんですが、後で例えば、面積の計算みたいなものを機能追加したい場合「「calculate」という関数があるけど、面積の計算してないから、面積の計算するように修正しとくわ」みたいな、やばいことを言い出します。
※実際はもう少し精度良く、思慮分別ある形で動いてくれますが、似たような事象は全然起きます。
それは、できる限り関数名やファイル名をわかりやすいものを意識し、コメントも付けると正確に対応してくれます。これに合わせて事前の仕様書とかのドキュメントも読ませれば、万全だったりします。
意識したこと⑨
こまめにリファクタリングする
AIにはコンテキストが～とか、プロンプトが長すぎと良くない～みたいな話をしましたが、これはそれに通じます。
特にCursorやClineみたいなエディタ埋め込みのAI機能は、良しなにソースコードを読み込んで、プロジェクトの事もピンポイントながら、理解しつつ実装してくれて大変便利です。
ただ、ソースコードが長い分、それはAIへの命令が長くなることにつながりますし、まあ、別の観点でそもそも運用保守性とか、プログラミングのお作法的に、1つのファイルに大量の機能なりを乱雑に実装するのはあまり良しとされていません。
そして、AIに開発を任せると、特に法則なく、良しなに既存のファイルに追記したり、ファイル作ったり消したりしてきます。
そうすると、気づいたらプロジェクトがぐっちゃぐちゃになります。
その時に、人間が何か手を食分けたりしようとするのは至難の業になってきます。
なので、適宜機能やコンポーネントの分割、または統合して再利用性を高めるなどの観点でAIに指示出しをして、リファクタリングを実行してもらったほうが良いです。
ただ、リファクタリングは慎重に進めていかないと、プロジェクトに破壊的な変更を加えて破綻することにもなるので、きちんと監視して、ちょっとでも変なところや違和感ある処理があったらAIを止めて、口を挟むスタンスでいたほうが良いです。
一旦こんなところ
拙い文章で読みづらい部分も多々あったかと思いますが、ここまで読んでいただいて、ありがとうございます。
他にも思い返せば色々あると思うしもう少し体系的に纏められるなとも思ったのですが、早く出しちゃいたい思いもあって、今回はここまでにとどめておきたいと思います。
この記事が誰かの参考になれたら幸いです。
今後も適宜記事上げて自分の経験をシェアしていきますので、良かったらXもフォローお願いします！
あとTickioも触ってみてください！そして、良かったら感想教えてください！！！