一人開発でAIを使うなら何から始める？5段階で試した活用法

速くなったのは、正解が外にあって、確かめられる作業でした。既存のコードに合わせて書く、同じ直しを複数のファイルに当てる、リンク切れを全ページから洗い出す。こういうものは渡すだけで終わります。

変わらなかったのは、決める作業です。どの機能を捨てるか、どの言い回しを選ぶか、いつ公開するか。材料は増えましたが、決まる速さは変わりませんでした。

この2つを混ぜると、判断したつもりで判断していない状態になります。私はそこで一度つまずいたので、以降は分けて考えています。

意外だったのは、確認の時間が増えたことです。作る速度が上がったぶん、出てきたものを見る量も増えました。差し引きで速くなっているかは作業によります。速くなったのは確かですが、どの作業でも一律に速い、という話ではありませんでした。

以降は、企画・実装・確認・調べもの・公開の順に、どこで何をしているかを書きます。

先に結論を書くと、5段階のどこでも分け方は同じでした。材料を集めるところは任せて、選ぶところは手元に残す。段階が変わると作業の中身は変わりますが、この線の引き方は変わりませんでした。

思いつきを形にする段階です。ここでAIに求めるのは答えではなく、質問でした。

理由は、この段階でこちらが持っている情報が少なすぎるからです。少ない材料で答えを出させると、足りない部分は埋められます。埋められた部分は、それらしく書かれているので、読んでいるうちに自分が決めたことのように思えてきます。

「仕様書を書いて」と渡すと、それらしいものが返ってきます。ただ、足りない情報は埋められるので、一般的なアプリの姿が入ります。代わりに「実装できる形にするために足りない情報を質問してください。推測で埋めないでください」と頼むと、自分の中で決まっていない場所が見えます。手順はAIに仕様書を書かせる方法｜曖昧なアイデアを開発できる形にするにまとめました。

同じ時期にやるのが競合と名前の確認です。どちらも、広げるのは任せて、確かめるのは自分という分担にしています。AIを使った競合調査の進め方｜裏の取り方と、任せない判断とAIでアプリ名を考えるときの質問例と、埋もれない絞り込み方に分けて書きました。

この段階で気をつけているのは、出てきた案を早く絞らないことです。候補が10個あるうち1個を選ぶのはこちらの仕事ですが、10個を3個にする作業まで渡すと、切った理由が見えないまま候補が減ります。広げるところまでを任せる、というのはそういう意味です。

実装が一番効きます。ただ、渡し方で結果が変わりました。同じ機能を頼んでも、条件を先に書いたときと書かなかったときで、やり直しの回数がはっきり違いました。

短く頼むと、短く返ってきて、そこから長く直すことになります。目的、動かす環境、使ってはいけないもの、終わったと言える条件、触ってほしくない場所。この5つを先に決めてから渡すようになって、捨てる回数が減りました。詳しくはAIにコードを書かせる前に決めるべき5つと、その置き場所に書いています。

決めたことは会話に残しません。プロジェクトの規約ファイルへ置きます。作業の前に読まれるので、こちらが言い忘れても効くからです。使っている道具そのものの説明はClaude Codeとは？できること・始め方・任せない作業にまとめました。

一番痛い失敗は、実装ではなく確認で起きました。エラーが出ないまま、意図と違うものができている状態です。エラーで止まるものは、放っておいても気づきます。困るのは止まらないほうでした。

実際にあったのが、あるページで本体は404を返すのに、画像だけ200を返していた件です。画面を開いても何も起きないので、目で見ても気づけません。検索エンジンの管理画面に上がってきて初めて分かりました。

この種のものは、人が気をつける話にしないほうが早い。気づけない失敗だけを、ビルドを止める検査に移す。いまは6本の検査が走っていて、書式や台帳との食い違いでビルドが落ちます。考え方はAI開発で起きやすい「動くけれど仕様と違う」を3層で防ぐに、テストの洗い出しはAIでテストケースを作る方法｜正常系だけで終わらせない頼み方にまとめました。

調べものは速くなりますが、そのまま採用すると事故ります。間違いも正しい答えと同じ調子で書かれるので、読んだだけでは見分けがつきません。

私は数字、日付、固有名詞、URLを必ず自分で開いて確かめます。変わりやすいものは確認した日も残します。確認の項目は生成AIの回答は正しい？そのまま採用する前に通す確認5つに並べました。

文章は下書きまで任せて、題材と、出すかどうかは自分で決める形にしています。出すのは自分の名前なので、ここは渡しません。

実際に一度、書かれた下書きに、確認できない過去の出来事が入っていたことがあります。読むとそれらしく、危うくそのまま出すところでした。事実かどうかを確かめる工程を、文章にも入れるようになったのはこれ以降です。

この失敗が示していたのは、確かめる工程は作業の種類で決まらないということでした。コードなら検査を通す、文章なら読み返す。形は違っても、確かめずに外へ出すと同じところで転びます。

文章のほうで効いたのは、書いていないことを書かないという一点でした。実測していない数字、確認していない出来事。下書きの中でそれらしく収まっていると見落とすので、数字と固有名詞だけを先に拾って確かめる順番にしています。

ここだけは分け方をはっきりさせています。コードの編集はまとめて任せ、記録を残す操作と、外へ出す操作はそれぞれ別に承認します。

このサイトは特定のブランチへ反映した時点で本番公開になるので、最後の一押しは必ず自分で行います。分けておくと、変更は全部できているけれど今日は出さない、という判断ができます。ひとまとめに任せていたころは、気づいたときには公開されていました。戻す作業のほうが、確認する手間よりずっと重い。

任せる範囲の決め方そのものはAIに任せてよい作業・任せない作業をどう決める？三つの基準にまとめました。可逆性、影響範囲、正解の在りかの3つで見ています。

公開したあとに見る場所も決めてあります。検索エンジンの管理画面と、実際のURLを外から開くこと。手元で通った検査と、外から見える状態は別なので、ここは公開のたびに確かめています。

• 読ませるだけの指示から始める。壊れないので失敗が安い。
• うまくいった指示は、その場で規約ファイルへ移す。
• 同じ説明を二度したら、手順にする合図。
• 確認の方法を先に決めてから、作業を渡す。
• 元に戻しにくい操作は、自動で許さない。

一人開発でAIを使うなら、何から始めればいいですか？

読ませるだけの指示からです。「このファイルが何をしているか説明して」なら壊れません。失敗しても安いので、任せ方の感覚をつかむのに向いています。書き換えを伴う依頼は、そのあとで足していきます。

AIを使うと開発は速くなりますか？

作業によります。正解が外にあって確かめられる作業は速くなりました。一方、確認する量も増えるので、差し引きで速くなっているかは作業ごとに違います。私は速さを測っていないので、数字では書きません。

AIに任せると自分の力がつかなくなりませんか？

確かめる側に回ることは増えました。出てきたものが正しいかを判断するには、結局その分野を分かっている必要があります。確かめる方法を持っていない作業を渡すと、良くなったか悪くなったかも分かりません。そこは手放せない部分だと思っています。

どのAIツールを使えばいいですか？

この記事では比較を書きません。私はターミナルで動くものを中心に使っていて、他の道具を十分に使っていないからです。使っていないものについては書かないと決めています。

AIが書いたコードをそのまま公開していいですか？

私は公開の操作だけ手元に残しています。理由は品質ではなく、取り消せないからです。コードの編集は履歴が残るので戻せますが、公開したものは消しても誰かが見たあとです。

どの段階から任せる範囲を広げればいいですか？

仕組みを足したあとです。戻せない作業でも、戻せる形に変えれば任せられます。逆の順番、つまり先に範囲を広げてから備えを足そうとすると間に合いません。広げた直後がいちばん壊れやすいからです。

この記事では「どれくらい速くなったか」を数字で書いていません。測っていないからです。体感では速くなった作業と、確認が増えて差し引きゼロの作業があります。きちんと測れる形にしてから、別の記事で扱う予定です。測っていないことを、速くなったと書かない。これも一人でやるうえでの決まりの一つにしています。

もう一つ書いていないのは、道具ごとの比較です。私はターミナルで動くものを中心に使っていますが、エディタに統合されたものも併用しています。使い分けについては、それぞれの得意が分かってきたところなので、別で扱います。