非エンジニアの経営者がAI開発に挑んだ記録——Claude Codeで500行を作り、AIにダメ出しをもらった話

⏱ この記事は約11分で読めます

非エンジニアの経営者がAI開発に挑んだ記録——Claude Codeで500行を作り、AIにダメ出しをもらった話

「AIを使って業務を効率化したい。でも、プログラミングの知識がないから自分には無理だろう」——そう思いながら、ChatGPTをただの壁打ちツールとして使い続けていませんか。

私もそうでした。ところが先日、対話型AIツール「Claude Code」を使って約500行のPythonスクリプトを開発し、さらにその開発プロセス自体をClaude Codeに採点してもらうという体験をしました。
私は中小企業やクリニックの経営を「番頭代行」として支援しています。CFO・COO・CHRO・CMOの4領域を1人で回す立場ですが、プログラミングの知識はありません。変数の意味も、関数の書き方も、正直よく分かっていません。

この記事は、そんな非エンジニアの経営者がAI開発に挑んだ体験記です。


何を作ろうとしていたのか——繰り返しの投稿作業を自動化したい

繰り返しの手作業を、AIに代わってもらうことが目的でした。

当社のブログ(このサイトです)は、Markdownというテキスト形式で原稿を書き、WordPress(ウェブサイトの管理システム)に投稿しています。

記事を書き上げた後にやることは毎回同じです。WordPressへの投稿、メタディスクリプションやOGP(SNSシェア時の表示情報)の設定、カテゴリーやタグの割り当て、管理用ファイルの更新。これだけで15分以上かかります。

最初はClaude Codeにこの投稿作業を丸ごとやってもらっていましたが、ある記事を読んで「固定的な処理はPythonスクリプトに切り出し、AIにはAIにしかできない判断だけを任せるべき」だと知りました。

毎回同じ手順を踏んでいるのに、そのたびにAIに「考えさせる」のは、AIの利用料金(トークン消費)の無駄遣いです。この「仕込み」をPythonに任せるツールを作ろうと決めました。


非エンジニアがAI開発でまず直面する壁——「いきなりコード」でいいのか?

結論から言えば、「いきなりコード」は避けた方がいいです。

プログラムの開発には、いきなりコードを書くのではなく「要件定義」という設計図を先に作る工程がある。これは一般的な知識として知っていました。

Claude Codeに「WordPress投稿を自動化するスクリプトを作って」と指示すると、AIはすぐにコードを書き始めようとしました。そこで「まず要件定義をしてほしい」と待ったをかけました。

AIが出力した要件定義書は約300行。「入力は何か」「出力はどうなるか」「エラー時にどう振る舞うか」が整理されていました。正直、内容を100%理解できたわけではありません。ただ、「こういうケースではこう動く」という分岐が目に見える形になっていたので、「これなら大丈夫そうだ」という判断はできました。

要件定義の承認後、AIが実装したスクリプトは約500行。所要時間は要件定義を含めて約30分でした(その多くは私が要件定義書を読む時間)。テスト段階でWindows環境特有の文字化けなど2つの不具合が見つかりましたが、事前に搭載していたテストモードですぐに発見・修正できました。

結果、毎回15分かかっていた投稿作業が、コマンド1行、数秒で終わるようになりました。


AI自身に開発プロセスを採点してもらった——非エンジニアの進め方は正しかったのか?

「AIに開発プロセスを採点させる」という試みは、非エンジニアにとって強力なフィードバック手段です。

ツールが動くようになった時点で、ふと思いました。「この開発の進め方は、果たして良かったのだろうか?」と。

私はエンジニアではないので、自分の開発プロセスが適切だったのか判断できません。そこで、開発を一緒にやったClaude Codeに「今回の開発プロセスを評価し、改善点があれば教えてほしい」と聞いてみました。

以下が、AIから返ってきた評価の要約です。

Good: 要件定義を先に作った判断は正解だった

Claude Codeの評価:今回の開発規模(約500行、外部API連携あり)に対して、要件定義を先に作ったのは適切だった。

具体的に効いたポイントとして、3つが挙げられました。

1. 曖昧さの事前排除

要件定義を書く過程で「既に投稿IDがある場合はどうする?」「タグが指定されなかった場合は?」といった分岐条件が明確になった。これがなければ、AIは「たぶんこうだろう」と推測でコードを書いていた箇所がある。

2. スコープの固定

「やらないこと」を明記したことで、AIが勝手に範囲を広げることが防げた。生成AIは指示が曖昧だとスコープを広げる傾向がある。

3. テスト基準の事前定義

チェック項目を事前に表で定義していたため、テスト時に「何が正しい動作か」が明確だった。

Bad: 改善できた点も率直に指摘された

Claude Codeは良い点だけでなく、改善点も率直に返してきました。

1. 要件定義の粒度が過剰だった

500行のスクリプトに対して300行の仕様書は、少し詳しすぎた。「AIの判断が分かれそうな箇所」に集中して書けば、もっと短くて同じ効果が得られた。

2. テストケースを要件と同時に決められた

「この入力に対してこの出力が出たら正解」という具体的なテストケースを、要件定義と同時に決めておけば、テスト工程がもっとスムーズだった。

3. 段階的に作る選択肢もあった

全機能を一気に実装するのではなく、「まずHTML変換だけ動くものを確認してから、次の機能を足す」という段階的なアプローチも取れた。ただし今回の規模(500行)なら一括でも問題なかった、と補足がありました。


非エンジニアがAI活用でツールを作るとき——業務効率化に使える4つの知見

Claude Codeの評価を踏まえて、非エンジニアがAIでツールを開発する際に使える知見を4つに整理します。

1. AIに「考えさせる前」に、人間が「なぜ」と「境界」を決める

AIに対しては「何を作るか」は最低限でよいのです。AIが補完できるからです。重要なのは「なぜ作るのか(目的)」と「何をやらないか(境界)」。この2つが曖昧だと、AIは親切心でスコープを広げます。

2. 100行を超えそうなら、要件定義を挟む

Claude Codeからのアドバイスをそのまま転記します。

規模目安 アプローチ
100行以下 そのまま作らせてOK
100〜500行 要件定義を挟む
500行超 要件定義 + 段階的に実装

要件定義といっても、エンジニアが書くような厳密な仕様書である必要はありません。「AIの判断が分かれそうな分岐条件」だけ押さえれば十分です。

3. 「壊れない方法」で先にテストする

--dry-run(副作用なしのテストモード)のように、本番に影響を与えずに動作確認できる仕組みを最初に作らせる。今回、テストモードがなければ文字化けした記事が公開されるところでした。

4. テストはダミーデータではなく実データで

テスト用に作った仮のデータではなく、実際に使っているファイルでテストする。「よくあるご質問」と「よくある質問」の1文字の差は、実データでしか発見できませんでした。


「うちの業務にもAIを使えるだろうか」と気になっているなら、まず現状の棚卸しから始めてみましょう。

番頭代行では、業務フローの棚卸しからAI活用の優先順位整理まで、無料相談(約30分)を承っています。

  • どこから始めるか迷っている段階でも歓迎です
  • 費用は無料、技術的な知識は一切不要です
  • 「まだ何も決まっていない」という状態が、むしろちょうどいい出発点です

無料相談に申し込む


よくある質問——非エンジニアのAI活用・業務ツール開発

Q. プログラミングの知識がゼロでも、本当にAIで業務ツールを開発できますか?

私自身、プログラミング言語の文法は理解していません。ただし「自分の業務で何が非効率か」「ツールにどう動いてほしいか」を言語化する力は必要です。むしろ、業務を熟知している経営者だからこそ的確な指示を出せる場面があると感じています。

Q. AIが生成したコードの品質や安全性は大丈夫ですか?

セキュリティ調査会社Veracodeの2025年の報告によると、AI生成コードの45%にセキュリティ上の欠陥があります。社内の業務効率化ツールであればリスクは限定的ですが、顧客向けサービスや個人情報を扱うシステムの場合は専門家のレビューが不可欠です。

Q. 作ったツールが壊れたとき、非エンジニアでも自分で直せますか?

複雑なバグの修正は難しいですが、エラーメッセージをそのままAIに渡せば多くの場合は修正案を出してくれます。要件定義書が残っていれば「本来こう動くはず」という基準があるため、AIへの説明もスムーズです。

Q. 「バイブコーディング(ノリでAIに作らせる方法)」ではダメなのですか?

一時的に動くものは作れますが、それ以上は難しくなる場面があります。バイブコーディングという言葉を広めたAndrej Karpathy氏自身が、自身のプロジェクト「Nanochat」では「AIエージェントがまったく役に立たなかった」としてほぼ手書きに切り替えています。「ノリで作る」と「設計して作らせる」の間には、要件定義という1ステップがあるだけです。

Q. 番頭代行に相談すると、すぐにツール開発の話になりますか?

いいえ。最初は「どの業務に時間がかかっているか」をお聞きします。AIツール開発が最善手でないケースも多く、業務フローの整理や既存SaaSの活用提案になることもあります。まだ何も決まっていない段階でのご相談を歓迎しています。


まとめ——AIで何を作るかを決める力は、経営者の仕事

今回の体験で実感したのは、AIで何かを作ること自体は驚くほど簡単だということ。そして、「AIに何を作らせるか」を考える部分こそが、人間の仕事として残り続けるということです。

2025年に「バイブコーディング(AIにノリで指示を出してコードを書かせる手法)」がCollins辞書の年間最優秀単語に選ばれるほど話題になりましたが、提唱者のAndrej Karpathy氏自身が、自ら開発した「Nanochat」というプロジェクトでは「AIエージェントがまったく役に立たなかった」として、ほぼ全てのコードを手書きしたと明かしています。

「ノリで作る」と「設計して作らせる」の間には、要件定義という1ステップがあるだけです。その1ステップが、成果物の品質を大きく変える。プログラミングの知識がなくても、「何が必要で、何が不要か」を言語化する力さえあれば、AIは強力な開発パートナーになります。

業務の流れを知り尽くしている経営者こそ、この力を一番持っています。


「うちの業務にもAIを活用できるだろうか」とお考えの経営者の方へ

番頭代行では、業務フローの棚卸しからAI活用の優先順位整理まで、無料相談(約30分)を承っています。

  • 技術的な知識は不要です
  • まずは「どこに時間がかかっているか」をお聞かせください
  • 相談後に契約をお願いすることはありません

無料相談に申し込む


参考資料