はじめまして。増山友司（ますやまともし）と申します。SNSや講師業では「とまだ」の名前で活動しています。普段はフリーランスのソフトウェアエンジニアとして開発の現場に立ちながら、Udemyの講座や記事でAI駆動開発の使い方をお伝えしています。

その開発の現場、そしてUdemy講座や記事といった発信の場でも、AI駆動開発に関する質問をいただくことがあります。なかでも多いのが「どこまで細かく指示を書けばいいのか」と「どうすれば一発で思った通りのものを出せるのか」の2つです。

背景にあるのは、ツールそのものの変化です。2025年、AIコーディングツールは大きな転換点を迎えました。コードを部分的に提案する道具から、「⁠プロジェクトを作って、テストも書いて」といったタスク全体を引き受ける道具へと変わり、いまはそれが前提になっています。

一方、任せられる範囲が広がった分、出てくるものの当たり外れの幅も大きくなりました。細かさを尋ねる質問も、一発で当てる方法を尋ねる質問も、突きつめれば「この幅（期待していたものと実際に出てきたものの差）をどう小さくするか」という1つの問いです。

一度にまとめて指示するほどやり直しが増える

そもそも、なぜ外れるのでしょうか。それは、指示に書かれていない部分をAIが推測で補ってしまうからです。たとえば「検索機能をつけて」とだけ伝えた場合、タイトルだけを探すのか、それとも本文まで含めるのかは決まりません。それでもAIは手を止めず、よくあるパターンから推測して実装してしまうことがあります。人間同士なら経緯や文脈が行間を埋めますが、AIはその前提を持っていません。

では、指示を細かく書けば解決するのでしょうか。たしかに、明確に書くことは効果的です。ただし、それだけでは足りません。指示する範囲が広がれば、そのぶんAIが推測で埋める箇所も増えるからです。どれだけ細かく書き込んでも、一度に指示する範囲が大きすぎれば外れは大きくなります。「⁠指示の明確さ」と「一度に指示する範囲の大きさ」は別の軸です。

たとえば、メモアプリに検索、お気に入り、並べ替えという3つの機能が欲しくなり、一度にまとめてAIに実装させたとします。ここで検索の画面が想定と違っていれば、同じ思い込みで書かれた残り2つの機能も似たようにずれてしまうため直す範囲は全機能に広がります。しかも、その問題に気づけるのは3つの実装がすべて終わったあとです。その頃には機能どうしが絡み合っているので、手戻りの修正にかかる時間もAIとやり取りする分量（トークン）も余計にかかってしまいます。

一方、1つの機能ずつ指示するのはどうでしょうか。仮にずれがあったとしても、小さな成果物をチェックする時点で問題が見つかるため、直す範囲も小さく済みます。そのぶんAIとのやり取りは増えますが、指示を何度か出し直す手間は、出来上がった実装をまるごと作り直す損失に比べればはるかに軽く済みます。

実のところ、AIをうまく使いこなしている人も、一発で当てているわけではありません。大きく頼めば大きく外れ、小さく頼めば小さく外れる。それが分かっているから、外れても傷が浅い大きさにはじめから区切っているのです。「⁠一発で当てにいかないこと」が結果としていちばんの近道になります。

「合っているか分からない」も区切れば減る

区切ることの効果は、手戻りを減らすことだけではありません。「⁠動いてはいるが、これで合っているのか分からない」という声もよく聞きます。画面上は期待どおりに動いていても、品質まで考えられたコードになっているのかどうかはなかなか判断がつきません。

この不安も、一度に指示する範囲の大きさから来ている場合があります。まとめて大量のコードが返ってくると、どこから見ればいいのかが決まりません。AIの生成したコードを読むだけで時間がかかり、見落としも増えていきます。

しかし、AIに任せる範囲をひと機能ずつに区切れば、そのまま確認しやすい大きさに収まります。見るべき範囲がはっきりしていれば、動くかどうかだけでなく、その書き方でよいのかまで踏み込めます。

確かめられないものは任せられない

自分の目で確かめる理由は、効率の問題だけではありません。AIが書いたコードでも、取り込んだ瞬間から自分たちのコードです。バグや脆弱性が見つかったときに、AIが書いたからと責任を免れることはできません。だから、否定も盲信もせず、出てきたものを自分で確かめるようにします。開発の現場でもよく引かれる「信頼するが検証する（Trust but Verify⁠）⁠」とは、そういう姿勢のことです。

では、どこまでAIに任せて、どこから自分で見るのか。線を引く手がかりは2つあります。

1つ目は「出てきたものが正しいこと」を自分で判定できるかどうかです。たとえば、テストが通る。画面を触って確かめられる。似た実装と並べて比べられる。こうした手段があれば、任せた結果は検証できます。

逆に、確かめる手段がないまま任せると、それらしく見えるだけなのか、それとも本当に正しいのかを見分けられません。

厄介なのは、詳しくない技術領域ほどAIに任せたくなることです。裏を返せば、そこは自分では結果を評価できない領域でもあります。AIに任せたい内容ほど、先に確かめる手段が必要なのです。

2つ目は、その実装について「なぜそうしたのか」を、自分の言葉で説明できるかどうかです。書いたコードを先輩エンジニアにレビューしてもらう場面を思い浮かべてください。「⁠なぜこの書き方にしたのか？」と聞かれて答えに詰まるなら、その部分はまだ、AIに任せきってよい段階に来ていません。

この2つの手がかりに答えられる範囲が、いまAIに任せて問題ない範囲です。ただし、その範囲は固定ではありません。テストを先に書いておいたり、動かして目で見える形から始めるなど、自分で確かめる手段を増やしていけば、任せられる範囲も広がります。広げていった先で、人間は「何を作るか」に、AIは「どう実装するか」に集中できるようになります。

その確認の積み重ねが、実力になる

ここまでの話は、冒頭の2つとは別の、もう1つよくいただく相談への答えにもなっています。それは「AIに任せてばかりで、実力がつくのか不安」という声です。

伸ばしたい力は、3つに分けると扱いやすくなります。他人やAIの書いたコードが何をしているかをつかむための「読める」力。動かなくなったときに原因の見当をつけるための「直せる」力。そして、複数のアプローチの違いを説明し、どれかを選ぶための「選べる」力です。

どれも、コードを手で打った量ではなく、自分の頭を通した回数で伸びます。

• 出てきたコードを読んで確かめる
• おかしいところがあれば原因を調べる
• なぜその書き方なのかを説明する

ここまで「確認」と呼んできた作業は、これら3つの力を使う場面とそのまま重なります。つまり自分で確認する行為は、品質のためであると同時に、頭を通す機会そのものなのです。

ただし、新しく機能を追加する経験だけでは、読む力と直す力までは伸びにくいところがあります。すでに動いているコードを前にして意味を読み取り、足りないテストを補い、構造を整え直すという具体的な場面を通らないと使わない力だからです。

だから、段階的に積み上げる形にした

先ほど述べたAIが書いたコードを確かめる3つの力は、一度に揃うものではありません。そこで、9月8日に発売の新刊『Claude Codeで作って学ぶ AI駆動アプリ開発入門』では、確認の手段が一段ずつ増える順番で並べ、これらの力が段階的に身に付くように設計しました。

まず、目で見て確認できる架空の企業サイトを作ります。次に、触って確認できるメモアプリへ進みます。その先には、すでにあるコードにテストを書いて確認する題材を挟みました。そして最後のタスク管理アプリでは、自分の手元だけでなく公開した先でも動くことを確かめるところまで進みます。作りながら、確かめられる範囲がそのたびに広がっていきます。

考え方は文章でも説明できますが、確認を積み重ねる場そのものは読むだけでは経験できません。AIツールを触ってみたものの思い通りにならなかった経験のある実務経験1〜3年程度のエンジニアに向けて、その場をハンズオンという形で用意したのが『Claude Codeで作って学ぶ AI駆動アプリ開発入門』です。