「非エンジニアでもAIで“使えるツール”は作れる」って本当か
Cursorが月間アクティブユーザー数100万人を突破した、生成AIで作られたマイクロSaaSが四半期に何千件も生まれている、といったニュースを見るたびに、正直「話を盛りすぎでは」と思っていた。自分はWeb制作会社でコードを書く側の人間だが、それでも「非エンジニアが週末でツールをリリースする」はさすがに誇張だろうと感じていた。
ただ実際に、経理担当の同僚が毎月やっている面倒な作業を見かねて、自分が週末2日でAIコーディングツール（Claude Code）を使って小さな社内ツールを作り、実際に使ってもらうところまで持っていった経験がある。エンジニアである自分がやってすら、想像していたのとは違う難しさがいくつもあった。
この記事では、「AIで個人開発する」の実態がどのくらいのレベルの話なのかを、実際に手を動かした一次情報として書く。非エンジニアの読者が「自分にもできそうか」を判断する材料にしてもらえたら十分だ。
きっかけ: 毎月の請求書突合せが同僚にとって地獄だった
経理担当の同僚は、毎月末に外注先から届く請求書の金額と、社内の発注記録をひとつずつ目視で突き合わせる作業をしていた。件数はそこまで多くないが、金額の桁が違う、消費税の端数処理が発注先ごとに違う、といった細かいズレが必ず何件か出る。見つけるたびに発注担当に確認のメールを送る、という地味に時間を食う作業だった。
「毎月3〜4時間くらいこれに溶けてる」と聞いたとき、これは表計算とちょっとした照合ロジックさえあれば自動化できる範囲だと感じた。ちょうど自分もAIコーディングツールをどこまで実務レベルで使えるか試したかったタイミングだったので、土日を使って作ってみることにした。
週末2日でやったこと
Day1: 要件を固めて、まず動くものを作る
土曜の午前中は同僚に業務のヒアリングをして、「発注記録のCSVと請求書の金額をアップロードすると、差分がある行だけをハイライトして一覧表示する」というシンプルな仕様に絞った。欲張って自動送信メール機能なども考えたが、最初のバージョンは「差分を見つける」だけに機能を絞ったのが結果的に正解だった。
Claude Codeに要件を伝えて、CSVを読み込んで突合するだけの簡単なWebアプリの土台を作らせるところまでは、体感1〜2時間程度で動くものができた。ここは検索で見た「2週間かかっていた個人開発が3日でできる」という話に近い感覚だった。
TOI
「動くものを作る」までの速さは想像以上だった。問題はその後だった
Day2: 実データを食わせたら想定外だらけだった
日曜、同僚から実際の請求書データ（の形式を再現したサンプル）をもらって試したところ、Day1で「完成」と思っていたものが半分近くうまく動かなかった。発注先によって日付の書式がバラバラ、全角と半角の数字が混在、空白セルの扱いが違う、といった「きれいなデータ」を前提にしていた自分の甘さが一気に露呈した形だ。
ここからは、Claude Codeにエラーになったパターンを1つずつ渡して直させる、という地道な作業になった。丸一日、この「実データとの帳尻合わせ」に使うことになり、Day1の「作る」より、Day2の「実務で使えるレベルまで磨く」のほうが体感の作業時間は長かった。
個人開発で実際につまずいた3つのポイント
1. 「動く」と「実務で使える」の間には想像以上の距離がある
最初のプロトタイプは数時間でできたが、実データのクセに対応させる作業だけで丸一日かかった。個人開発の話でよく語られる「3日で完成」は、この後者の作業を含んでいるかどうかで体感が大きく変わると感じた。
2. 金額や取引先名を扱うツールは、権限まわりを自分で考える必要がある
社内ツールとはいえ、請求書の金額や取引先名という機微な情報を扱う。誰がアクセスできるか、どこにデータを置くか、外部に送信される処理が入っていないか、といった点はAIが自動で気を配ってくれるわけではない。ここは自分がWeb制作の実務でセキュリティ要件を確認する時と同じ姿勢で、意識してチェックする必要があった。
3. 「作って終わり」ではなく「使ってもらう」ハードルが一番高かった
技術的な部分より苦労したのが、ここだった。同僚に触ってもらったところ、最初は「ちゃんと動いてるか不安で結局Excelでも二重チェックしてしまう」という反応だった。差分が「本当に差分なのか、単なる表示ミスなのか」を信じてもらえるまで、1〜2週間かけて一緒に結果を見ながら微調整する期間が必要だった。ツールの完成度以上に、使う人が「信頼していい」と思えるまでの期間を見込んでおくことが個人開発を実務で活かす上では重要だと痛感した。
非エンジニアが個人開発に挑戦するなら、何から始めるべきか
同僚の反応を見ていて、「自分にもできそうか」は状況によって答えが変わると感じた。
- ExcelやGoogleスプレッドシートの関数・マクロは触ったことがある場合: Claude CodeのようなAIコーディングツールで、まず自分の身近な繰り返し作業（今回のような突合せ・集計）を1つだけ自動化してみるのがいい。要件が小さいほど「実データのクセ」への対応もAIと一緒に潰しやすい。
- コード自体にまったく触れたことがない場合: いきなりコーディングツールから入るより、Bolt.newやLovableのようなノーコードに近いAI生成ツールで、画面のあるものを触りながら「AIに何をどう伝えると欲しいものが返ってくるか」の感覚を掴むほうが挫折しにくい。
- どちらの場合も共通すること: 最初から「業務全体を自動化する」を狙わず、今の作業のうち一番地味で時間を食っている一工程だけに絞る。今回のツールも「突合せて差分を見せる」以上のことはしていない。
TOI
「作れるかどうか」より「小さく絞れるかどうか」が個人開発が続くかの分かれ目だった
まとめ: 週末の個人開発で分かったこと
- 「動くものを作る」までは、噂通りAIコーディングツールで一気に速くなる。ただしそれは全体の半分程度の工程でしかない
- 実データのクセへの対応、権限まわりの確認、使う人に信頼してもらうまでの調整に、想像より多くの時間がかかる
- 非エンジニアが挑戦するなら、業務全体ではなく「一番地味で時間を食っている一工程」だけに絞ってAIツールを試すのが現実的
- 表計算の関数を触った経験があるならAIコーディングツール、まったく未経験ならノーコード寄りのAI生成ツールから始めると挫折しにくい
「AIで個人開発できる時代」というニュースは誇張ではなかったが、そこで語られている速さは工程の半分の話だ、というのが実際に手を動かしてみた自分の実感だった。
コメント