大きな機能を頼む前に、作業を小さな単位に分けて付箋に書き出し、ひとつずつ進めようとしている落ち着いた開発者
AIコーディング約12分

AIコーディングは小さく切る｜関数1個から始めるスコープ設計

AIに「この機能、まるっと作って」と頼んで、返ってきた大量のコード。 動かしてみると、どこかで落ちる。でも直そうにも、どこがどう間違っているのか分からない。結局ぜんぶ読み直して、手を入れて、また落ちて——気づけば、自分で最初から書いた方が速かったかもしれない。そんな夜、ありますよね。

これはあなたの読み込みが甘いわけでも、AIが賢くないわけでもありません。 多くの場合、原因は「一度に頼みすぎ」です。大きなかたまりで受け取ると、正しい部分と間違った部分が混ざり合って、切り分けができなくなる。だから直しづらい。

この記事は、AIコーディングを関数1個・1ファイルくらいの小さな単位に切って、検証しながら積み上げる進め方の話です。スコープを小さくするのは、AIを信用していないからではありません。間違いを早く・小さく見つけるための、実務的な段取りです。深掘りなので少し長めですが、一度に全部やる必要はありません。まず効く所から、一緒に見ていきましょう。

結論：AIに頼む単位は、「返ってきたコードを、自分がその場で読んで正しさを判断できる大きさ」まで小さく切ります。目安は関数1個〜1ファイル、差分にして数十行。大きな機能は、いきなり全体を頼まず、①入出力の決まった小さな部品に分解 → ②1つ頼む → ③すぐ動かして確認 → ④OKなら次を頼むの順で積み上げます。こうすると、間違いが混入しても直前の小さな差分の中に閉じ込められ、原因の切り分けと手直しが一気に楽になります。逆に大きく頼むほど、正しい所と間違った所が混ざって「どこから直せばいいか分からない」状態に陥ります。速さは大きく頼むことからではなく、小さく確かめながら進むことから生まれます。

急がば回れ、ではありません。 小さく切る方が、結果的に速い。これは根性論ではなく、手戻りの総量を減らすための段取りの話です。

なぜ「大きく頼む」と遅くなるのか

大きな依頼では正しいコードと間違ったコードが混ざって切り分けできず、小さな依頼では間違いが小さな範囲に閉じ込められることを示した比較図

AIは、大きな依頼でもそれらしいコードを一気に返してくれます。 ここが落とし穴です。返ってくる量が多いほど「たくさん進んだ」気がしますが、実際には検証していないコードが一気に積み上がっただけです。動くかどうかは、まだ分かっていません。

大きく頼むと、具体的にこういうことが起きます。

つまり、大きく頼んで遅くなるのは、書く時間ではなく「直す・確かめる時間」が膨らむからです。 AIが数秒で吐き出したコードの検証を、人間が数十分かけて追いかける。この非対称が、体感の「AIで速くなったはずなのに」の正体です。

対策はシンプルです。一度に検証できる大きさまで、頼む単位を小さくする。次から、その「小さく切る」を具体的に見ていきます。

どこまで小さくするか——「その場で判断できる大きさ」

まず、切る大きさの基準を1つ決めます。 おすすめは、「返ってきたコードを、自分がその場で読んで、正しいかどうか判断できる大きさ」です。読んで判断できないほど大きいなら、それは切りすぎではなく、まだ大きすぎるサインです。

具体的な目安を出します（あくまで目安で、言語や難しさで前後します）。

単位目安の大きさ向いている場面
関数1個数行〜数十行ロジックが1つに閉じている処理。まずここから
1ファイル数十行〜100行台関連する関数がまとまった単位。部品ができてきたら
機能まるごとそれ以上原則、いきなり頼まない。分解してから

いちばん扱いやすいのは、やはり関数1個です。 「入力はこれ、出力はこれ」がはっきりしていて、単体で動かして確かめられる。間違っていても、その関数の中だけを見れば済みます。まず関数1個をAIと組んで確実に通す——これがAIコーディングの安全な最小単位です。

判断に迷ったら、こう自問します。 「返ってきたら、自分は5分でこのコードの正しさを見極められるか？」——イエスなら、その大きさでOK。ノーなら、もう一段小さく切ります。

大きな機能を「小さく切る」分け方

一つの大きな機能を、入出力の決まった小さな部品に分解し、依存の順に一つずつ組み立てていく流れを示した図

「小さく」と言っても、大きな機能をどう割ればいいか。ここでつまずく人が多いので、分け方の観点を挙げます。

分解のコツは、「一つひとつが、入出力の決まった単体で試せる部品になっているか」を確認することです。 ここがはっきりしていれば、AIにも頼みやすく、返ってきたコードも検証しやすい。逆に「なんとなく前半・後半」で割ると、境界が曖昧なままで結局まとめて直す羽目になります。

分解そのものをAIに手伝ってもらうのもありです。「この機能を、単体で試せる小さな部品に分けるとしたら、どういう単位が考えられる？」と設計の壁打ちから入ると、頼む前の見取り図が作れます。壁打ちの問いの立て方はAIを設計の壁打ち相手にする問いの立て方にまとめました。

小さく積み上げる4ステップ

分け方が決まったら、あとは1つずつ回します。基本の型はこの4つの繰り返しです。

1. 1つだけ頼む 分解した部品を、1つだけAIに頼みます。このとき、その部品の入力・出力・制約をそろえて渡すと、一発目の精度が上がります。渡す前提のそろえ方はAIにコードを書かせる前に渡す前提と制約が下敷きになります。「ついでにあれも」と欲張らず、1回1部品を守ります。

2. すぐ動かして確かめる 返ってきたら、溜めずにその場で動かします。関数1個なら、簡単な入力を与えて期待どおりの出力が返るかを見る。テストを1つ書いてもいいし、手で呼んで結果を見るだけでもいい。ここで「読んで理解できる」「動かして正しい」の2つを通します。最低限の動作確認の型は生成コードをそのまま使わない｜最低限の動作確認を参照してください。

3. OKになってから、次に進む 確認が通ってから、次の部品を頼みます。前の部品が緑になっていない状態で先に進まない——これが積み上げの肝です。土台がぐらついたまま上に積むと、後で全部崩れます。もしここで直しが必要なら、直すのも小さな差分の中で済みます。

4. 部品がそろったら、つなぐ所だけを小さく頼む 部品が出そろったら、それらを組み合わせる部分（呼び出し順やデータの受け渡し）を、また小さく頼みます。つなぎ目も一つの「小さな単位」として扱えば、全体を一気に組ませて崩れるのを避けられます。

この4ステップの効きどころは、間違いが混入しても、直前の小さな差分の中に閉じ込められることです。 「さっき動いていたのに、今おかしい」なら、原因は直近で足した1部品にほぼ絞れます。切り分けにかかる時間が、大きく頼んだときとは比べものになりません。

それでも大きく頼みたくなったら

正直、小さく切るのは少し面倒です。一気に頼んで一気に返ってくる快感もあります。 だからこそ、大きく頼みたくなったときの歯止めを一つ持っておくと安心です。

大きく頼むこと自体が悪ではありません。 検証できない量を、検証しないまま本番に積むことが危ういのです。そこさえ守れば、場面に応じて大きさは選んでかまいません。

明日からやること（小さく始める3つ）

全部を仕組み化しようとすると重いので、まずこの3つから。

  1. 次の依頼を、関数1個に絞ってみる：いつも機能単位で頼んでいるなら、今日は1つだけ「関数1個」に切って頼む。返ってきたコードの見やすさが変わります。
  2. 頼む前に、部品への分け方を1回書き出す：「この機能は、どんな小さな部品に分かれるか」を箇条書きで3つほど。迷ったらAIに割ってもらう。頼む順番の地図ができます。
  3. 1部品ごとに、動かしてから次へ：溜めずに、1つ通してから次を頼む癖をつける。「前が緑になってから進む」を今日だけ守ってみてください。

この3つだけでも、「どこから直せばいいか分からない」夜がぐっと減ります。 慣れてきたら、分解の観点やつなぎ目の頼み方も足していけば十分です。

スコープを切るときのチェックリスト

依頼を送る前・受け取った後に、さっと確認します。全部に○が要るわけではなく、その依頼で関係する行だけで十分です。

頼む前（切り方）

受け取った後（積み上げ）

この記事のまとめ

小さく切るのは、AIを疑うためではありません。 間違いを、早く・小さく・直しやすい形で見つけるための段取りです。関数1個から始めて、動かして確かめて、緑になったら次へ。この地味な積み上げが、実は一番の近道になります。

小さな部品を一つずつ確かめながら積み上げて機能が形になり、落ち着いた表情で次の一つに進もうとしている開発者

一度に全部を、うまくやろうとしなくて大丈夫です。 今日ひとつ「関数1個に絞って頼む」ができたなら、それはもう「どこから直せばいいか分からない」を減らす確かな一歩です。小さく頼んで、確かめて、次へ。前提のそろえ方は渡す前提と制約の型、受け取った後の見方はAI生成コードのレビュー・検証チェックリスト。この3つがそろうと、AIコーディングはずいぶん落ち着きます。

関連用語