はじめに

こんにちは。

私は本業で基幹システム領域のPMとして働く、ごく普通の会社員です。

普段はシステム導入や運用プロジェクトに携わっていますが、Webサービス開発の経験はほとんどありません。

そんな私が、AIの進化に衝撃を受けたことをきっかけに個人開発へ挑戦し、現在は小説執筆支援サービス「me-editor」を運営しています。

正直なところ、最初は「本当に自分にサービスなんて作れるのだろうか」と思っていました。

開発経験が豊富なエンジニアならともかく、私は本業で要件定義やプロジェクト管理を行う立場です。プログラムを書くことが仕事ではありません。

しかし、AIの支援を受けながら試行錯誤を繰り返した結果、サービスを公開し、実際にユーザーに利用していただけるところまで到達することができました。

もちろん、順風満帆だったわけではありません。

本番環境でしか発生しない不具合
サーバーのメモリ不足
認証機能とSNSログインの実装
スマートフォン対応

「AIに聞けば全部解決するだろう」と思っていた時期もありましたが、現実はそう甘くありませんでした。

むしろ、AIが優秀だからこそ、人間側に求められる役割があることを強く実感しました。

本記事では、私が「me-editor」を開発・公開するまでに経験したことを、できる限り正直にまとめています。

AIを使ってどのように開発を進めたのか。
どんな技術を選び、なぜその技術を選んだのか。
どこでつまずき、どのように解決したのか。

そして、サービス公開後に見えてきた現実についてもお話しします。

本記事は、次のような方を対象としています。

AIを活用して個人開発をしてみたい方
Webサービスを作ってみたい方
プログラマーではないが何かを形にしてみたい方
CodexやChatGPTの活用方法に興味がある方

逆に、短期間で大きく稼ぐ方法や、AIだけで何でも実現できる魔法のような話を期待している方には向いていないかもしれません。

この本でお伝えしたいのは、「AIを使えば誰でも成功できる」という話ではありません。

「AIを活用することで、これまで挑戦できなかった人でも一歩踏み出せるようになった」という話です。

もし今、

「自分にも何か作れるだろうか」

と考えているのであれば、本記事がその背中を少しでも押すことができれば嬉しく思います。

それでは、私が「me-editor」を作ることになった経緯からお話ししていきます。

なぜWebサービスを作ろうと思ったのか

個人開発への憧れ

会社員として働いていると、日々の仕事はどうしても「誰かが決めた要件を、決められた期限までに形にする」ものになりがちです。もちろんそれ自体に価値はありますし、チームで作るからこそ学べることも多いです。

どこかでずっと「自分で考えたものを、自分の責任で作って、世の中に出してみたい」という気持ちがありました。

個人開発への憧れは、きれいな成功談から始まりました。SNSで見かける「週末で作ったサービスが使われた」「小さなツールが収益化した」という話を見るたびに、自分もいつかやってみたいと思っていました。ただ、実際にはなかなか始められませんでした。

本業が終わると疲れている。土日は休みたい。子供と過ごす時間も必要。作りたいものを考えても、ログイン、DB、デプロイ、UI、利用規約、OGP、スマホ対応と、必要なものが多すぎる。

頭の中では何度も完成しているのに、手元には何も残っていない期間が長くありました。

AIの進化を見て感じたこと

そこに出てきたのが、Codexのような開発支援AIでした。

最初に触ったとき、「これは全部作ってくれる魔法だ」とは思いませんでした。むしろ、使ってみるほどに「自分の曖昧さがそのままコードになる道具だ」と感じました。

雑に頼むと雑な実装が返ってくる。前提を伝え忘れると、平気でこちらの意図と違う方向に進む。便利だけれど、勝手にプロダクトの責任を取ってくれる存在ではありません。

それでも大きかったのは、最初の一歩の重さがかなり軽くなったことです。

FastAPIでログイン機能を作る。SQLAlchemyでモデルを追加する。CSSの崩れを直す。これらを一人で全部調べながら進めると、途中で気力が切れます。でもAIと一緒なら、「まずここまで作る」「次にこの不具合を見る」と区切って前に進める。

個人開発で一番つらい、相談相手がいない時間が減りました。

「小説執筆支援サービス」というテーマを選んだ理由

me-editorのテーマは、小説を書く人向けの執筆支援エディタです。理由は単純で、自分自身が文章を書くことに関心があり、既存のエディタに少しずつ不満があったからです。

小説を書くときに欲しいのは、派手なAI生成よりも、本文を落ち着いて管理できること、縦読みで見え方を確認できること、同じ言葉を使いすぎていないか見られること、SNSに載せやすい画像を作れることでした。

ここは意識的に、AI機能を前面に出しませんでした。

me-editorのアプリ機能としてLLMは使っていません。

誤字脱字チェックや本文分析は、ローカルルール、辞書、Janomeによる形態素解析が中心です。

AIで開発したサービスだからといって、サービス自体にAIを無理に入れる必要はないと考えました。ユーザーにとって必要なのは「AIっぽさ」ではなく、執筆中に邪魔にならないことです。

創作者界隈における生成AIへのタブーといった点にも着目しており、あえてAI機能を実装しないことによる「創作者の安心感」にも繋がると考えました。

最初に考えたMVP

最初のMVP(必要最小限の機能のみ実装した試作品)はかなり小さく考えました。

ログインできる。
文書を作れる。
本文を書ける。
自動保存される。
文字数が見える。

最低限、これだけです。

ただ、ここで最初の失敗もありました。

MVPと言いながら、頭の中ではすぐに「縦読みも欲しい」「履歴も欲しい」「スマホでも書きたい」「SNS画像も出したい」と膨らんでしまう。

AIに頼めば実装速度が上がるので、余計に欲張りやすくなります。

でも機能を増やすほど、DB設計、UI、エラー処理、スマホ対応、本番環境の確認が増えます。

MVPは小さく切ったつもりでも、公開までの道のりは思ったより長くなりました。

個人開発では、作る機能を減らすことも立派な技術判断だと、この時点で少しずつ分かってきました。

開発前の自分のスキルレベル

本業での経験

開発前の自分は、まったくの未経験ではありませんでした。

本業でシステムやWebまわりに触れる機会はあり、コードを読むことへの抵抗もそこまでありませんでした。

エラー文を見て原因を探す、ログを確認する、仕様を分解する、そういった基礎体力はありました。

ただし、個人開発で必要になる力は本業のそれとは少し違います。

本業では役割が分かれています。インフラを見る人、フロントを見る人、レビューしてくれる人、リリース判断をする人がいる。

個人開発では、それを全部自分でやります。認証のCookie設定も、DBのマイグレーションも、CSSの1pxのズレも、OGP画像がXで表示されない問題も、全部こちらに戻ってきます。

Web開発経験

Web開発経験は一切ありませんでした。本業では基幹システムの導入を主戦場としており、既存のパッケージシステムを顧客業務に合わせて設定していく仕事です。中学生の時に買ってもらったホームページビルダーで黒歴史を生産した記憶しかありません。

最近は基幹システムのSaaS化の流れもあり、システムの構造自体は理解していました。HTML、CSS、JavaScript、API、DBの関係は理解していても、ゼロから公開サービスとしてまとめる経験は別物です。

me-editor-webはFastAPIでHTMLを返し、静的なJavaScriptとCSSでSPA風に動かす構成です。ReactやNext.jsを使った今どきの構成ではなく、比較的素朴な作りにしました。

この選択は、自分のスキルレベルに合っていました。フロントエンドのビルド環境まで抱えると、詰まったときの原因が増えます。今回は「まず公開する」ことを優先し、FastAPI、Jinja2テンプレート、static配下のapp.jsとapp.cssで進めました。

その結果、app.jsはかなり大きくなりました。これは反省点でもあります。最初はシンプルでも、機能追加を続けると巨大な単一ファイルになりやすい。

AIは追記が得意なので、放っておくとどんどん同じファイルに実装が積まれます。

AI活用経験

AI活用については、文章生成や調査補助としては使っていましたが、実際のサービス開発を継続的に任せるのは別の経験でした。

最初は「この機能を作って」と大きく頼みがちでした。すると、動くには動くけれど、既存の状態管理に合っていなかったり、UIの細部が崩れたり、あとで直しにくい形になることがありました。

途中から、AIへの頼み方を変えました。「このファイルのこの関数の周辺を読んで」「既存の保存処理に合わせて」「本番でメモリが増えないように」「スマホのスクロール挙動を確認して」といった具合に、制約と観点を渡すようにしました。

AIは手を動かす速度が速い分、方向づける人間側の言葉が重要になります。

「本当に作れるのか？」という不安

一番大きかった不安は、公開できる状態まで持っていけるのか、ということでした。

ローカルで動くものを作るだけなら何とかなります。でも、公開サービスにするには、認証、DB、環境変数、HTTPS、Cookie、エラー画面、スマホ表示、利用者のデータ保護など、急に現実的な問題が増えます。

実際、me-editorでも公開前に何度も止まりました。

RenderでOOMが起きる。本番だけログイン挙動が違う。XログインのリダイレクトURIで詰まる。OGP画像が思った通りに出ない。スマホで左メニューがうまくスクロールしない。

こういった問題は、チュートリアルにはあまり出てきません。AIに聞けば候補は出ますが、最後に「このサービスではどれが原因か」を決めるのは自分です。

開発前の自分に十分な自信があったかと言えばありませんでした。

今振り返ると、不安がある状態でも始めてよかったと思います。

全部分かってから作ろうとすると、たぶん今も作っていません。

分からないまま小さく進め、詰まったところで調べ、AIに相談し、動いたら次に進む。

その繰り返しで、少しずつ公開に近づいていきました。

技術選定

前提として、技術選定はCodexに任せた点が非常に多いです。というのも、先述の通りWebアプリ開発の知見が無かったためです。

そのうえで、Codexの提案を抑えつつ、サービスに合った言語かどうかをChatGTPとの協議の上で選定しております。

技術的なバックボーンが無い方でも、ChatGPTとの対話をしながら技術選定の妥当性確認は可能です。個人的には、ここまでしなくても、全てCodexに任せて大きな事故にはならないと思われます。

開発環境

開発環境は、Python 3.11、FastAPI、Uvicorn、SQLAlchemy、Alembic、Jinja2、素のJavaScript/CSSが中心です。

ローカルではSQLiteも使える形を残しつつ、本番はPostgreSQLを前提にしました。

AIとの開発では、まずローカルで動かし、必要に応じてGitの履歴を残し、本番に反映して確認する流れでした。このとき、差分を小さくすることの重要性を痛感しました。

AIに大きな修正を頼むと、一度に複数の問題が混ざり、どこで壊れたのか分かりにくくなります。「スマホ左パネルのスクロールを安定化」「SNSカードプレビュー初回描画を安定化」のような細かい修正を多く行うことになりました。

なぜFastAPIを選んだのか

me-editorのバックエンドにはFastAPIを選びました。理由は、Pythonで書けること、APIを作りやすいこと、構成が比較的見通しやすいことです。

個人開発では、技術的に最先端かどうかより、自分が詰まったときに戻ってこられるかが大事です。その意味で、FastAPIはちょうどよい選択でした。

FastAPIを選んでよかった点は、APIの追加が速いことです。

一方で、フロントを素のJavaScriptで書いたため、バックエンドの見通しの良さに比べて、フロント側はだんだん重くなりました。

なぜRenderを選んだのか

デプロイ先はRenderにしました。

GitHubと連携してデプロイしやすく、Pythonアプリをそのまま動かしやすいからです。

個人開発で最初に公開する場所としては、かなり入りやすい選択肢でした。

一方で、Renderは公開すれば終わりではありません。特にメモリ制限には悩まされました。ローカルでは問題なく動く処理でも、本番の小さなインスタンスではOOMになることがあります。

あまりにもOOMが頻発したタイミングがあったため、起動時処理、履歴一覧、旧documents一覧APIなどを軽量化を図りました。

公開後に「動いた」ではなく、「限られたリソースで落ちない」状態に近づける必要がありました。

なぜNeonを選んだのか

DBにはNeonのPostgreSQLを選びました。

RenderのWeb Serviceはファイルシステムが永続化前提ではないため、SQLiteのローカルファイルに依存する運用は避けたかったからです。

PostgreSQLにしておくと、将来的にユーザーが増えた場合にもSQLiteより安心です。SQLAlchemyとAlembicを使い、ユーザ情報、ドキュメント情報、バージョン管理、フォルダ管理、ルビ管理などを行いました。

最初はシンプルな文書保存だけでしたが、あとからフォルダ、履歴、Xログイン、ルビ一覧、分析イベントが増えていきました。この「あとから増える」を受け止めるには、最初から外部DBにしておいてよかったです。

ただし、DBを外に置けば全部解決するわけではありません。

接続プール、マイグレーション、本番DBだけで起こるスキーマ差分、起動時のcreate_allやスキーマ同期の扱いなど、考えることは増えます。

実際、あとからRUN_SCHEMA_SYNCやRUN_CREATE_ALLのような環境変数を用意し、起動時に何を実行するか制御するようになりました。

今振り返ってどうだったか

今振り返ると、FastAPI、Neon、Renderという選択は、個人開発の初公開には合っていました。小さく始められ、必要な機能を足しやすく、デプロイも比較的分かりやすい。ただし、フロントを素のJavaScriptで大きく育てすぎた点は反省しています。最初はビルド環境を避けたことで楽になりましたが、機能が増えるほど状態管理とDOM操作が複雑になりました。

次に作るなら、最初からフロントの責務分割をもう少し考えます。

Reactなどを使うかどうかは別として、少なくともファイル分割、状態管理、UIコンポーネントの境界は早めに作ると思います。

AIは追記には強いですが、設計の整理は人間が意識しないと後回しになります。

技術選定は「作れるか」だけでなく、「半年後の自分が直せるか」で選ぶべきでした。

Codexとの開発

最初に出した指示

codexとの開発で最初にやったのは、「小説を書くためのWebエディタを作りたい」というかなり大きな指示でした。

ログイン、文書管理、エディタ、自動保存、文字数カウント、履歴、誤字脱字チェックなど、頭の中にあるものをまとめて伝えました。

結果として、最初の足場作りにはかなり助けられました。FastAPIの構成、SQLAlchemyのモデル、ルーター、テンプレート、静的ファイルの配置など、一人でゼロから作るより圧倒的に早かったです。

最初の「動くもの」が見えると、個人開発は急に現実味を帯びます。真っ白なエディタ画面が表示され、文字を打てて、保存できる。その体験は大きかったです。

ただ、最初の指示は抽象的すぎました。

AIは広い指示にも答えてくれますが、その分、こちらが気づかないところで判断が入ります。たとえば、認証の扱い、エラー時の表示、保存間隔、履歴をいつ作るか、スマホでどう見せるか。こうした細部は、サービスの使い心地に直結します。あとから「やっぱりこうしたい」と直す場面が何度もありました。

上手くいった指示

上手くいった指示には共通点があります。