「非エンジニアが開発者になるのは幻想」論に、実際に手を動かして答える

「非エンジニアが開発者になるは生成AI時代の幻想でしかなかった」という検索クエリが実在する。この言い切りに対して、実際にAIエージェントで物を作ってきた非エンジニアの立場から答えを出したい。結論を先に書くと、「幻想」でも「もう検証はいらない」でもなく、その中間にある。何が実際にできて、何が今も人間の手元に残っているかを、具体的な事実で分けて書く。

3行まとめ

1. 非エンジニアがAIエージェントに実装を任せて、動くツールサイトや動画制作パイプラインを公開まで持っていくこと自体は、実際にできている。ここは「幻想」ではない
2. ただし、「実行した結果が本当に正しいか」の最終確認、「動いていない」という状態判断、数値や出典の裏取りは、AIに任せたままだと事故につながった実例がある
3. 変わったのは「コードを書けるかどうか」ではなく、「AIの出力を検証できるかどうか」が実務上の壁になったという点。壁の位置が動いただけで、壁自体が消えたわけではない

実際にできたこと

まず、できたことをはっきり書いておく。非エンジニアの立場から、AIエージェントに実装を任せて、投稿・承認・公開の一連の仕組みを持つツール紹介サイトを本番で動かしている。動画制作でも、台本の検証やYouTube統計の取得を行う自作ツールをAIエージェントに実装させ、実際に運用に使っている。これらは「いずれできるようになる」という将来の話ではなく、現時点で動いているものだ。この過程の記録は非エンジニアがAIエージェントに個人開発を任せてみた実測記録に書いている。

「非エンジニアはコードが書けないから何も作れない」という意味での懐疑論であれば、それは実態と合っていない。実装そのものの壁は、AIエージェントを使うことでかなりの部分が下がった。ツール実装の役割分担や、Skills機能を使った運用の型については非エンジニアがClaude CodeのSkills機能を設定した手順にも書いた通り、構文を暗記していなくても、正しく指示を出して結果を検証できれば、実装自体はかなりの部分をAIに委ねられる。

実際にできなかったこと・今も人間の手元にあること

一方で、AIに任せたままにしておくと事故が起きた場面もある。実際に起きたことを並べる。

• 「動いていない」という状態判断を誤った: 長時間のビルド処理が実際には走っていたのに、確認コマンドの出力を最後まで見ずに「走っていない」と判断し、同じ処理を2重に起動してしまったことがある。同一の出力ファイルに2つの処理が同時に書き込む形になり、両方をやり直す羽目になった
• プロセスを「止めた」つもりが止まっていなかった: レンダリング処理を止めるコマンドを実行したのに、実際には対象のプロセスが生き残ったまま次の処理が始まっていた。この時の実測では、残ったプロセスが数十個たまり、macOSの画面描画が一時的に無応答になるところまで発展した。詳しい実測はpkillはレンダプロセスを取り逃すに書いている
• 調べれば分かるはずの数値を、記憶のまま書いて公開してしまった: 価格のような具体的な数値を、その場で情報源を確認せずに書き、実際とは違う数値のまま公開してしまったことがある。これが後から「数値は必ず出典を確認する」というチェック機能を作る原因になった
• 認証エラーの原因切り分け: 決まったエラーメッセージだけを見て、それが認証切れなのか設定ミスなのかを人間が切り分ける必要があった場面がある。切り分けの手順はClaude Codeがエラーで動かない時の切り分け手順にまとめている

これらに共通しているのは、AIエージェントが明らかに間違った操作をしたわけではなく、「実行はできたが、その結果が意図通りかどうかを確認する工程」が抜け落ちていたという点だ。コマンドは実行された。エラーも(多くの場合)出なかった。それでも結果は意図と違っていた。

4つの事例を整理すると、次のようになる。

4件とも、AIエージェント側の「実行」自体は問題なく完了している。ズレていたのは、実行結果を人間側がどう確認するかという手順の方だった。

「幻想」論のどこが当たっていて、どこが外れているか

「非エンジニアが開発者になるのは幻想」という言い切りを分解すると、2つの主張が混ざっていると思う。1つは「非エンジニアがAIを使って動くものを作れるようになる、というのは嘘だ」という主張。これは、上に書いた通り実態と合わない。もう1つは「AIに任せれば、非エンジニアはもう何も検証しなくてよくなる」という主張への反論だとすれば、こちらは実際に当たっている。検証の手間はなくなっていない。

Claude Code公式ドキュメントには、特定のコマンドを実行前に機械的にブロックする仕組み（hooks）が用意されており、終了コード2を返すことでツール呼び出し自体を止められると説明されている。

終了 2 はブロッキング エラーを意味します。（中略）PreToolUse はツール呼び出しをブロックし、UserPromptSubmit はプロンプトを拒否します。

見落としやすいのは、終了コード「1」ではこの効果が得られないという点だ。公式ドキュメントは「ほとんどのフック イベントでは、終了コード 2 のみがアクションをブロックします。Claude Code は終了コード 1 を非ブロッキング エラーとして扱い、1 が従来の Unix 失敗コードであっても、アクションを進行させます」と明記している。フックでポリシーを強制したいなら、明示的にexit 2を書く必要がある。

ブロック可能なフックイベントはPreToolUseだけではない。公式ドキュメントが挙げる一覧の一部を抜き出すと、次のようになる。

つまり、「まだ実行されていない操作」を止められるイベント（PreToolUseなど）と、「すでに実行された後にしか気づけない」イベント（PostToolUseなど）が、公式仕様の時点ではっきり分かれている。二重起動やプロセスの停止漏れのような事故は、後者──実行後にしか結果が分からない性質のものだった。

こうした仕組みを使えば、危険なコマンドを実行前に止めるところまでは機械化できる。実際、Claude Codeの設定ファイル（settings.json）には、hooksとは別にpermissions.denyという許可・拒否ルールの仕組みもあり、公式ドキュメントの設定例では"Bash(curl *)"や"Read(./.env)"のようなパターンを明示的に拒否リストへ入れられる、と説明されている。ただし、これでブロックできるのは「あらかじめ危険だと分かっている操作」だけだ。「動いていないと誤判定する」「数値を確認せずに書く」といった、実行前には危険と分類しづらい失敗までは防げない。仕組みで防げる範囲と、人間が結果を見て気づくしかない範囲は、はっきり分かれている。hooksの具体的な作り方はAIに「ルールを読め」は効かない──読むまで作業をブロックする仕組み（hooks）の作り方に書いた。

権限ルールの専用ドキュメント「権限を設定する」を確認すると、この仕組みが機械的にしか防げない理由がより明確に書かれている。

"権限ルールは Claude Code によって実装されており、モデルによってではありません。プロンプトまたは CLAUDE.md の指示は、Claude が何をしようとするかを形作りますが、Claude Code が許可する内容は変わりません。"

つまり、CLAUDE.mdに「このコマンドは使うな」と書いておくのは、あくまでモデルの振る舞いに影響を与える「お願い」でしかなく、実際に呼び出しをブロックする力を持つのはClaude Code本体が評価するsettings.jsonの権限ルール（allow/ask/deny）とPreToolUseフックの方だ、という区別になる。同ドキュメントによれば、ルールはdeny・ask・allowの順に評価され、最初にマッチしたルールが結果を決める。Bash(aws *)のような広いdenyルールは、より狭いallowルール（Bash(aws s3 ls)など）にマッチする呼び出しも含めてすべてブロックするため、denyルールに例外を混ぜることはできないとも説明されている。「ルールを文章で伝える」のと「ルールを機械的に強制する」のは別のレイヤーだという点は、本記事で挙げた4つの事故のうち、少なくとも「危険なコマンドの事前ブロック」に関わる部分の裏付けになっている。

もう一つ、実行前に人間の目を挟む仕組みとして「プランモード」がある。公式ドキュメント「Permission modes」には、「計画モードは Claude に変更を加えずに調査と提案を行うよう指示します。Claude はファイルを読み、シェルコマンドを実行して探索し、計画を書きますが、ソースを編集しません」「編集は計画を承認するまでブロックされたままです」とある。これは前述の4つの事故のうち「数値の記憶書き」のような、実行前に計画段階でレビューできる性質の作業には有効に働く。一方、ビルドの二重起動やプロセスの停止漏れは、コマンド実行後の状態確認（本当に走っているか、本当に止まったか）に関わる失敗で、プランモードのようにコード変更を事前レビューする仕組みでは直接は防げない。フックとプランモードは、どちらも「実行前に人間・仕組みを挟む」点では共通しているが、防げる失敗の種類は異なる。

実際に変わった壁の位置

非エンジニアがAIエージェントで物を作れるようになったこと自体は事実で、そこは「幻想」ではない。変わったのは、実務上どこに壁があるかという位置の方だ。以前は「構文を知らないと1行も書けない」という壁があったが、今その壁はかなり下がっている。代わりに残っているのは、「AIが出した結果や『成功しました』という報告を、鵜呑みにせず確認できるか」という壁だ。この壁は、非エンジニアだから高くなるわけでも、エンジニアだから低くなるわけでもない。AIに任せる作業と、AIに任せず自分で確認し続ける作業の線引きは、非エンジニアが起業・個人開発でAIに任せる作業と任せない作業の線引きに一覧の形でまとめている。

「幻想でしかなかった」と過去形で切り捨ててしまうと、この確認の壁ごと見えなくなる。実際に手を動かして初めて分かったのは、壁がなくなったのではなく、壁の種類が「書けるか」から「見抜けるか」に変わったという、地味だが具体的な事実だった。

この記事はサンプル数1の観測記録である

• 本記事の「できたこと」「できなかったこと」は、すべて筆者1人・運用しているサイトと動画制作パイプライン1系統ぶんの経験にもとづく。他の非エンジニアが同じようにAIエージェントで開発したときに、同じ壁にぶつかるかどうかは確認していない。
• 冒頭で触れた「非エンジニアが開発者になるのは幻想」という言い切りは、特定の記事や研究者の主張を指しているのではなく、そうした検索クエリが存在するという事実だけを起点にしている。この主張を明確に唱えている一次資料（specific な記事・調査）は、本記事では特定できていない。したがって本記事は、名指しの反論ではなく、ありうる主張のパターンに対する応答という位置づけになる。
• 「実行はできたが確認が抜け落ちていた」事故が何回中何回起きたか、つまり失敗率にあたる分母のデータは記録していない。挙げた4件は「印象に残っている事故」であり、日々の作業のうち何パーセントが同様の見落としにつながったかは分からない。
• Hooksやプランモードで防げる範囲・防げない範囲の整理は、Claude Code公式ドキュメントの仕様に基づく一般論であり、筆者自身がこれらの仕組みを本記事で挙げた4つの事故すべてに事後適用して「防げたかどうか」を再現テストしたわけではない。