AIにコードを書いてもらうと、本当に便利です。
自分では書けない処理でも、やりたいことを伝えれば一気に出てくる。 Claude Codeのようなツールなら、ファイル作成も修正もエラー直しも進めてくれる。
「もう全部AIに任せればいいのでは？」
私も何度も思いました。
でも、ここにひとつだけ、譲れない注意があります。
AIにコードを書いてもらうこと自体は、悪くありません。 むしろ非エンジニアにとっては大きな味方です。
危ないのは、AIが出したコードを、中身を見ずにそのまま使うことです。
この記事では、非エンジニアの会社員目線で、「丸投げすると何が危ないのか」を整理します。
AIにコードを書いてもらうこと自体は、悪いことではない
前提から。AIにコードを書いてもらうのは、とても有効です。
非エンジニアの個人開発では、AIがいなければ最初の一歩すら踏み出せないことがあります。
画面を作る。ボタンを動かす。入力内容を保存する。エラーを直す。
私自身、AIと一緒にアプリを作る中で、「自分だけでは絶対にここまで来られなかった」と感じる場面が何度もありました。
以前書いた、AIと一緒に家族用アプリを作った体験についてはこちらでも触れています。
ただ、便利だからこそ、全部任せきりにする誘惑が生まれます。 そこが落とし穴です。
丸投げの危なさは「コードが書けるかどうか」ではない
丸投げが危ないのは、「自分でコードを書けないから」ではありません。
何をしているコードなのか分からないまま使ってしまうことが危ないんです。
AIが出したコードが、一見動いたとします。
画面も表示される。ボタンも押せる。保存もできているように見える。 「完成した！」と思いますよね。
でも、その裏にこんなことが隠れている場合があります。
- たまたま自分の入力では動いているだけ
- エラーが出たときの処理がない
- データを上書きしてしまう可能性がある
- 公開してはいけない情報を扱っている
- あとから直そうとしても、どこを触ればいいか分からない
料理に例えると、AIのコードは見た目のきれいな料理です。 味見もせず、材料も確認せず、そのまま人に出せますか？
動いたように見えても、何が入っていて、どこまで安全なのか。 そこを見るのは、こちらの仕事です。
「動く」と「安心して使える」は別物
ここが一番勘違いしやすいところです。
動くコード ＝ 安心して使えるコード、ではありません。
VBAでも、Webアプリでも、GASでも同じです。 一度動いても、条件が少し変わると止まります。
入力欄が空だったら？ 想定外の文字が入ったら？ 同じデータを2回登録したら？ 通信が失敗したら？
この確認をしないまま使うと、「普段は動くけれど、肝心なところで壊れる」コードになります。
しかも、AIのコードには特有の罠があります。 こちらの説明不足を、AIが勝手に補っていることです。
人間側は「たぶんこう伝わっているだろう」と思っている。 AI側は別の前提でコードを書いている。
このズレは、動かしただけでは見えません。 「動いたかどうか」だけでなく、「どんな前提で動いているか」を見る必要があります。
非エンジニアでも確認できる3つのポイント
とはいえ、コードを全部読んで理解するのは無理があります。 私も、すべてを完璧に理解しているわけではありません。
でも、全部読めなくても確認できるポイントが3つあります。
1. 入力：どんな情報を受け取っているか
そのコードは、何を受け取って動いているのか。
文字か、数字か、ファイルか、フォームの内容か、外部サービスの情報か。
入力はコードの「入口」です。 入口が雑だと、その後の処理も不安定になります。
数字を入れる前提なのに文字が入ったら？ 必須項目が空欄だったら？
この確認は、コードが読めなくても、実際に試せば分かります。
2. 処理：何を変更しているか
そのコードは、何を変えているのか。
データを追加しているのか。既存データを上書きしているのか。ファイルを削除しているのか。外部に送信しているのか。
特に注意するのは、削除・上書き・送信の3つ。 失敗したときの影響が大きいからです。
テストのつもりで動かしたコードが本番データを上書きする——ありえない話ではありません。
AIにコードを書いてもらったら、
「このコードは、どのファイルやデータを書き換えますか？」
と聞くだけでも違います。
3. 出力：結果がどう残るか
動かした結果、何が残るのか。
画面に表示されるだけか。ファイルが作られるのか。データベースに保存されるのか。メールが送られるのか。
特に、外部に送信されるもの・公開されるものは要注意です。 自分の画面では問題なく見えても、外から見たら想定外の情報が出ている可能性があります。
コードの構文を読むより、**「何を入れて、何を変えて、何が出るのか」**を確認する。 非エンジニアには、これが現実的で、これで十分です。
AIは「作る係」、人間は「決める係」
役割分担をはっきりさせると、安心して進められます。
AIに任せるのは、作ること。 たたき台を作る。コードを書く。エラーを直す。別案を出す。説明する。
人間が握っておくのは、目的を決めることと、採用してよいか判断すること。
「これは自分の目的に合っているか」 「本番で使ってよいか」 「今の自分が直せる範囲に収まっているか」
ここをAIに渡してしまうと、あとで詰みます。
AIが高度なコードを書いてくれても、自分が全く理解できない状態なら、少し動かなくなっただけでお手上げです。
完成した瞬間はうれしい。でも、あとから直せない。 これが、AI丸投げの一番怖いところです。
個人開発は、最初から完璧なものを作るより、自分が扱える範囲で少しずつ育てるほうが長続きします。
そのまま使う前に、コピー環境で試す
AIのコードをいきなり本番で動かすのは、避けてください。 特に、データを書き換える処理、削除する処理、外部送信する処理。
まず、コピー環境で試します。
- 本番ファイルではなくコピーしたファイルで試す
- 本番データではなくテスト用データで試す
- 公開ページではなく下書きページで試す
- いきなり全部ではなく、1件だけで試す
子どもが新しいハサミを使うとき、いきなり大事な紙を切らせませんよね。 まず、いらない紙で試させる。
コードも同じです。 壊れてもいい場所で試す。この一手間だけで、安全性がまるで変わります。
AIに「説明させる」と理解しやすくなる
コードが読めなくても、AIに説明させることはできます。
このコードについて、非エンジニアにも分かるように説明してください。 特に、次の3点を教えてください。
- 何を入力として使っているか
- どのデータやファイルを変更するか
- 実行後に何が残るか
危険な処理がないか確認したいときは、こうです。
このコードの中に、削除・上書き・外部送信・権限変更など、実行前に注意すべき処理があれば教えてください。
AIにコードを書かせるだけで終わらせず、説明係もやってもらう。
AIはコードを書くのも得意ですが、説明するのも得意です。 分からないまま進めるのではなく、分かる言葉に戻してもらう。
これをやると、丸投げが共同作業に変わります。
「よく分からないけど動いた」は危険サイン
AI開発をしていると、「よく分からないけど動いた」という瞬間があります。
うれしいんです、これが。 私も最初は小さくガッツポーズしていました。
でも、これは危険サインでもあります。
誤解しないでほしいのは、「全部理解しろ」という話ではないことです。 非エンジニアがAIで開発する以上、「全部は分からない」は普通です。
危ないのは、この状態です。
- 何をしているか全く分からない
- どこを直せばいいか分からない
- 失敗したときに戻せない
- 本番データに影響するか分からない
「分からない部分がある」のは問題ではありません。 分からない部分を、分からないまま本番で使うのが問題なんです。
AIにアプリ開発を頼む前に画面イメージを言葉にする話は、こちらの記事でも書きました。
今回の話は、その次の段階。 頼む前に整理するだけでなく、頼んだ後に確認することです。
丸投げしないための聞き方
受け取った後の聞き返しの例を挙げておきます。
このコードをそのまま使う前に、確認すべき点を3つに絞って教えてください。
このコードで、失敗したときに影響が大きい部分はどこですか？
このコードを初心者でも管理しやすい形にするなら、どこをシンプルにできますか？
本番データを触る前に、テスト用データで確認する手順を作ってください。
ポイントは、「完成させて」とだけ頼まないこと。
「確認点を出して」「危ない部分を教えて」「テスト手順を作って」と頼むと、AIは先生役にもなってくれます。
作らせるだけでなく、説明させる。 この一手間が、丸投げを防ぎます。
自分が直せるサイズにしておく
もうひとつ、意識したいのはコードのサイズです。
AIは放っておくと、大きな機能を一気に作ろうとします。 「いい感じに作って」と頼むと、便利そうな機能をどんどん足してくれます。
でも、機能が増えるほど、あとから直すのは難しくなります。
最初は、1画面だけ。1機能だけ。1つの入力と1つの保存だけ。
小さいコードなら、AIに説明させても理解できます。 エラーが出ても、原因を探せます。
立派なものを一気に作るより、自分が説明できるサイズで積み上げる。 AI開発の安全運転は、これに尽きます。
AIと一緒に作るなら「確認する力」が必要になる
AIがコードを書いてくれる時代に、非エンジニアに必要なのはこの力です。
- 何を作りたいか言葉にする力
- AIが出したものを確認する力
- 危ない部分を質問する力
- 小さく試す力
- 自分が扱える形に戻す力
中でも今回の主役は、確認する力。
「AIが作ってくれたから大丈夫」ではなく、「これは何をしているのか」「どこに影響するのか」「自分があとから直せるのか」を確認する。
この感覚があるだけで、AI開発の安心感は別物になります。
Claude Codeで最初に感じた壁については、こちらの記事でも書いています。
非エンジニアがClaude Codeでアプリを作るとき、最初に感じた壁
まとめ：AIに任せるほど、確認する目が大事になる
AIにコードを書いてもらうのは、これからますます普通になります。 非エンジニアでも、今まで作れなかったものが作れる。大きな可能性です。
ただし、丸投げは別の話です。
AIのコードを受け取ったら——
- 入力を見る
- 処理を見る
- 出力を見る
- コピー環境で試す
- AIに説明させる
- 自分が直せるサイズにする
AIは、コードを書いてくれる頼もしい相棒です。 でも、「これを使っていい」と決めるのは、最後まで人間です。
丸投げではなく、共同作業。 この感覚さえあれば、非エンジニアのAI開発は、ちゃんと続けられます。