AIで作る順序｜「まず数を作り、当たってから整える」で手が止まらなくなる【2026年7月】
AIで何かを作るときは、最初から正しい設計やきれいな構成を目指さないでください。まず動くものを数多く作り、当たった型が見えてから整える——この順序なら手が止まりません。 完璧に組み立ててから走り出そうとすると、多くの人は走り出す前に止まります。この記事では、思いつきで散らかしたものを後から片づけたみやっち🧑💻が、AIでものを作るときの「作る順序」を実録で解説します。
AIでものを作るときの正しい順序: バイブコーディング（作りたいものを自然言語でAIに伝え、動作を確かめながらアプリを形にする開発スタイル）では、最初から共通化された正しい設計を目指すのではなく、まず動くものを数多く作り、当たった型が見えてから共通化・整理・リファクタリングする順序が効率的です。これはスタートアップのソフトウェア開発——まず当たるためにたくさん作り、当たってから設計の見直しやリファクタリングにコストをかける——と同じ順序です。
なぜ「最初からきれいに作る」と手が止まるのか
理由はシンプルで、当たるかどうか分からないものに、先に「正しい構造」を用意しようとするからです。
きれいに作ろうとすると、フォルダの分け方、部品の共通化、名前の付け方……と、まだ1つも動いていない段階で決めごとが増えます。決めごとが増えるほど最初の一歩が重くなり、「設計が固まってから」と後回しにしているうちに、作りたかったものが宙に浮きます。せっかくAIが目の前で動いてくれるのに、その手前で止まってしまうのはもったいない。
しかも、当たる型は作る前には分かりません。頭の中できれいに設計しても、実際に動かすと「思っていたのと違う」が必ず出ます。当たってもいない構造をきれいに整えるのは、多くの場合ただの空回りです。整える価値が出るのは、当たった後です。
正しい順序は「まず数、整えるのは当たってから」
みやっち🧑💻が実際にものを作りながらたどり着いた教訓は、ひとことで言うとこうです。
まず当たるまで数をやり、当たってから抽象化・リファクタリングする。
これはスタートアップのソフトウェア開発と同じ順序です。当たるかどうか分からないうちにコードをきれいにしてもしょうがない。だから、まず当たるためにたくさん作り、当たった後で設計の見直しやリファクタリングにコストをかける。順番は「量産 → 当たりを見つける → 整える」であって、その逆ではありません。
大事なのは、これは「整えなくていい」という話ではないことです。整える工程は必要です。順番を、先ではなく後に置くだけです。100%の設計を先に用意しようとする気持ちを、いったん外す。まず動くものを1つ、そしてもう1つ、と数を作るほうに時間を回す。整理はその後でいくらでもできます。
実例: 3つのリポジトリに散らかったものを、当たってから1日で片づけた
これは机上の理屈ではありません。みやっち🧑💻自身がこの順序でやって、後から片づけました。
日々の業務を自動化する仕組みを、思いつくたびにその場で作っていったら、気づけば3つのリポジトリに、置き場所を考えないままファイルやナレッジが散らかっていた状態になりました。最初からこの設計が見えていれば苦労しなかった——と思いたくなりますが、実際には、作って動かした後でなければ、何が必要でどこが重複しているかは見えませんでした。まず数を作ったからこそ、どれが当たりかが見えました。
整理に踏み切ったのも、当たった型が見えて「きれいにするところにコストをかける意味があるフェーズになった」と判断できたからです。そこから1日かけて整理しました。やったことは大きく2つです。
- 共通で使う部品を1か所（共有リポジトリ）に集約し、各プロジェクトはそれを参照する形にした。同じコードのコピーを各所に持たせる二重管理をやめました
- ナレッジ（メモや手順）は、Notionにも入れる二重管理をやめ、AIが作業中に勝手に参照できるリポジトリへ一本化した。これで格段に仕事がしやすくなりました
遠回りに見えても、仕事全体の設計に丸1日を充てたのは意味がありました。ただし、その設計をやったのは「当たってから」です。散らかること自体は失敗ではなく、当たりを探すための正しい過程でした。
「当たってから整える」で具体的に何をするのか
当たった後の「整える」は、感覚ではなく決まった作業です。非エンジニアでも、AIに頼み、内容と動作を確かめながら進めれば十分にやれます。
- 重複した部品を1か所にまとめる（共通化）。同じものを複数の場所にコピーで持たない。二重管理をやめる考え方はAI時代のファイル管理にまとめました
- 情報の置き場所を1か所に決める（Single Source of Truth）。前提やルールを1か所に集め、AIがそこを見て動くようにする。やり方はCLAUDE.mdとはで解説しています
ここで効いてくるのが、Claude Code・Codexのように自分の手元でファイルを扱えるAIエージェントを使っていることです。部品もナレッジも自分のリポジトリに集約できるので、「当たってから整える」の“整える先”を自分で持てます。汎用のチャットや既製のSaaSは、当たりを量産するには使えても、当たった型を自分の資産として集約する置き場所にはなりにくい。ここが、AIに手順ごと任せて自分専用の仕組みを作ることの効きどころです。
これは「学ぶ順序」ではなく「作る順序」の話
ここまで読んで、パラシュート学習法を思い出した方がいるかもしれません。まず動くものを1つ作り、詰まった箇所だけ学ぶ——というAIの学び方です。似ています。ただ、軸が違います。
- パラシュート学習法やバイブコーディングの進め方が扱うのは、あなたが何を「学ぶ」順序です
- この記事が扱うのは、あなたが何を「作る」順序——量産してから整える、という開発の進め方です
2つは対になっています。学ぶときも作るときも、共通するのは「先に完璧を目指さない。まず動かし、必要になってから深掘りする」という順序の入れ替えです。学ぶ側の詳しい話は上の2記事に譲り、この記事は作る側だけを扱いました。
今日からやること
作る順序を短くまとめると、こうなります。
- 最初から共通化・きれいな設計を目指さない。まず動くものを数多く作る
- どれが当たりかは、作る前ではなく作った後に見える
- 当たった型が見えてから、共通化・整理・リファクタリングに時間を充てる
最初の一歩は、いま頭の中で「設計が固まってから」と止めている作りかけを、1つ動かしてみることです。道具の入口はClaude Codeとはに、業務アプリまで作る流れはVibe Codingとはにまとめてあります。散らかっても大丈夫です。散らかりは、当たりを探した証拠だからです。
AI Crewの講座は、この「まず作って、当たってから整える」を、受講生自身の実際の業務を題材に伴走する場です。自分の場合は何から数を作ればいいか知りたい方は、まず無料セミナーでお会いしましょう。
