非エンジニア役でAIとアプリ開発を進めた検証の総括
はじめに
今回、PVNM（Palette Visual Novel Maker）というノベルゲーム制作ツールを完成させる過程で、生成AIを活用した開発の検証を行った。
特に意識したのは、単に「AIでアプリを作れるか」ではなく、次の問いである。
ITエンジニアではない人が、AIとの自然言語による対話だけで、1つのアプリを完成まで持っていけるのか？
検証では、Claudeと対話する際には「エンジニアではない自分」を演じ、専門用語やコードの直接提示を極力避けた。
一方で、Codexと作業する際には「エンジニアである自分」として、技術的な語彙、ログ、ファイル構造、実装方針などをそのまま扱った。
本記事は、その結果と所感をまとめたものである。
検証の前提
本検証ではClaudeに対して以下のような制約を置いた。
- Claudeに関する事前知識を持たない、または知らないふりをする
- ITエンジニアではない人物として対話する
- ソースコードや構成ファイルを直接読まない
- 具体的なコード例の提示は極力避ける
- 自然言語による要求や状況説明だけで開発を進める
目的はClaude単体が非エンジニアをどこまでアプリ完成に導けるかを確認することだった。
なお、この検証はClaudeとCodexの性能比較を目的としたものではない。
むしろ、AIを活用する際に「利用者側の知識や伝え方」がどの程度結果に影響するのかを観察するためのものであることを付け加えておく。
成果物
最終的にPVNMは以下のような機能を備えたツールとして完成に近い状態まで到達した。
- シーン編集
- 背景画像、キャラクター画像の設定
- BGM / SEの設定
- 選択肢と分岐
- タイトル画面
- エンディング画面
- EXTRAS
- セーブ / ロード
- Markdownインポート
- Windows / Web / Android などへのエクスポート
- 日本語・英語ドキュメント
- ライセンス、第三者ライセンス通知、公開用README
単なるプロトタイプではなく、公開や配布を意識した状態まで整えることができている。
Claudeとの作業で起きたこと
Claudeとの作業では、自然言語で機能追加や修正を依頼しながら開発を進めた。
ただし、実際には「非エンジニアがAIに導かれて開発した」というよりも、こちらがかなり能動的に仕様整理、バグ報告、画面設計、挙動確認を行う必要があった。
Claudeとのやりとりがヒートアップしてくると、こちらも専門的な用語や技術的なワードを使って応答してしまい、「非エンジニア」を演じることが徹底できなかったのは反省点の一つである。
ちなみに残っていたClaudeとの会話メモを見ると、こちらからClaudeへ投げていた内容には、次のようなものが多く含まれていた。
- 画面上のボタンが効かない
- ESCキーで戻れない
- キャンセルできない
- 日本語が表示されない
- UIの文字が被る
- ボタンと文字の位置がずれる
- 画像が画面外に表示される
- BGMが停止しない
- エラーのTracebackを貼る
- スクリーンショットを見てほしいと依頼する
- 仕様を変更する
- 実装方針を再定義する
つまり、ユーザー側(私)は単に「こういうアプリが欲しい」と言っていたわけではなく、実際には、かなり細かくQAを行い、仕様を分解し、再現条件を伝え、期待する挙動を定義してしまっていた。
見えてきた課題
今回もっとも強く感じたのは、AIとの開発では「何を作りたいか」以上に、「今何が起きているか」を正確に伝える力が重要だということだった。
非エンジニア役として会話していると、次のような場面で開発が詰まりやすかった。
- エラーの原因をどう説明すればよいかわからない→開発が詰まる
- 画面の崩れを言語化できない→開発が詰まる
- どの操作で不具合が起きたのか整理できていない→開発が詰まる
- 期待する仕様と現在の挙動の差分を伝えられない→開発が詰まる
- AIが修正した内容が本当に正しいか判断できない→開発が詰まる
AIは自然言語で応答してくれるが、開発そのものは依然として具体的な作業である。
画面、状態、入力、出力、ログ、ファイル、再現手順といった情報が不足すると、AIの支援精度は大きく落ちることがわかった。
Codexとの作業で感じた違い
一方、Codexとの作業では、こちらがエンジニアとして会話したため、作業はかなりスムーズである。
たとえば、こちらからの指示を明確にした。
- アルゴリズムを指示する
- ロジックを指示する
- 具体的な処理内容を指示する
これらに加えて以下のような情報もそのまま扱うようにした。
- ファイルパス
- Gitの状態
- エラーログ
- 実装箇所
- ランタイムの構造
- ビルド手順
- AndroidやWebのエクスポート仕様
- ドキュメント構成
- ライセンス整理
この違いは、単純に「ClaudeよりCodexが優れていた」という話ではない。
むしろ、AIに渡せる情報の粒度がまったく違っていたことが大きい。
ちゃんとしたエンジニアとしてAIと会話する場合、問題をかなり正確にAIへ渡せる。
その結果、AIも具体的に調査し、修正し、検証しやすくなるということだ。
より円滑に作業を進めたいならskillsがあれば同じ説明を何度もやり直す負担や、仕様のブレ、確認漏れはかなり減ったはずという感じ。
ここでいうskillsを「AIに事前に渡しておく開発手順書・専門知識・判断基準」と考えるなら、PVNM開発では特に効果が大きかったと思う。
例えば以下のようなskillがあれば効果的であると考える。
| skill | 効果 |
|---|---|
| PVNM開発ルール | 画面構成、用語、保存形式、エクスポート方針を毎回説明しなくて済む |
| Pyxel UI設計ルール | 文字被り、ボタン中央寄せ、日本語フォント、ESC戻りなどの失敗を減らせる |
| バグ報告・修正手順 | 「再現条件→期待結果→修正→確認」の流れをClaude側が毎回守りやすい |
| ファイルピッカー共通仕様 | BG/BGM/SE/Font/PaletteでUIがバラつく問題を防げる |
| パレット/画像処理仕様 | 254色パレット、マスターカラー、シーン別パレットの混乱を減らせる |
| リリース前チェック | ドキュメント、ライセンス、エクスポート確認を漏らしにくくなる |
今回のClaudeとのやり取りを見ると、何度も発生していた摩擦は「実装能力」そのものより、むしろ以下のようなことだった。
- 以前決めた仕様が次の修正で崩れる
- 似たUIなのに画面ごとに挙動が違う
- ESC、キャンセル、戻るなどの共通操作が抜ける
- 日本語表示や文字サイズの問題が繰り返される
- ユーザーが毎回かなり細かく仕様を言い直す必要がある
skillsは、こういう「毎回覚えていてほしい前提」を固定するのに向いている。
一方で、skillsだけでは解決しきれない部分もある。
特に今回のようなGUIアプリでは、実際に起動して、画面を見て、ログを見て、操作して確認する工程が重要。
skillsがあっても最終的にはユーザー側の確認負担は残る可能性が高い。
なので私の見解としては・・・
skillsがあれば、Claudeとの開発はかなりスムーズになった可能性が高い。
ただし、実用品質まで持っていくには、skillsに加えて、実行環境へのアクセス、ログ確認、スクリーンショット確認、テスト手順の標準化が必要だった。
今回の検証では、Claudeとの会話では「非エンジニア役」なのでskillsなんぞ作れるわけもなく、AIに都度自然言語で仕様を伝える方式を取ったため、仕様の再説明や修正方針の揺れが多く発生した。
もしPVNM専用の開発ルールやUI設計基準をskillsのような形で事前定義していれば、Claudeとの開発はより安定し、ユーザー側の説明負担も軽減された可能性が高い。
ただし、skillsは検証作業そのものを代替するものではなく、実行確認や不具合再現、成果物の品質判断には依然として人間側の関与が必要であると考える。
評価
今回の検証結果を当初の評価軸に沿って整理すると次のようになる。
| 評価項目 | 評価 | 所感 |
|---|---|---|
| 完成到達性 | ○ | PVNMは公開準備に近い水準まで到達した |
| 誘導成功度 | △ | Claudeは一定の支援をしたが、ユーザー側の誘導もかなり必要だった |
| 問題解決能力 | △ | 単純な修正は進むが、複合的な不具合ではユーザー側の切り分けが重要だった |
| 一貫性・持続性 | △ | 長期開発では仕様の積み上げや整合性維持が難しかった |
| ユーザー依存度 | 高い | 完成にはユーザー側の検証力、設計判断、AIへの伝達力が大きく影響した |
最終評価としては、以下のように整理するのが妥当だと考えている。
| 観点 | 評価 |
|---|---|
| AI活用によるアプリ完成 | ○ 条件付き成功 |
| Claude単体が非エンジニアを完成まで導けたか | △ 限定成功 |
| 教育・教材としての価値 | ○ 有効 |
結論
今回の検証から得られた結論は、次の一文に集約できる。
AIを使えば開発できる、ではなく、AIに正しく状況を渡せる人ほど開発をより円滑に進められる
とは言いつつもClaudeとの対話では、自然言語だけでも多くの作業を進めることができている。
つまり、簡単なアプリ程度なら自然言語によるAI開発は問題なくできる可能性が高いということ。
これは大きな成果であると考える。
しかし、実用品質のアプリを完成させるには、単にAIへ依頼するだけでは足りなかった。
不具合を観察し、再現条件を整理し、期待する挙動を言語化し、必要に応じて仕様を修正する力が必要であることを感じた。
これは、従来のプログラミングスキルとは少し違うと考える。
しかし、開発現場でAIを活用するうえでは非常に重要なスキルだと感じた。
教育的な示唆
自分はこれまでエンジニアを育成し、実務現場へ送り出す業務に関わってきた。
その観点から見ると、今回の検証はAI活用教育の教材として非常に有用だと感じている。
生成AIの教育では、しばしば「AIを使うと便利」という説明に留まりがちである。
しかし実際には成果を出すためには次のような力が必要になる。
- 要件を分解する力
- 不具合を観察する力
- 再現手順を伝える力
- エラーやログを読む力
- 期待する挙動を明確にする力
- AIの出力を検証する力
- 仕様変更を管理する力
つまり、AI活用スキルとは「プロンプトを書く力」だけではない。
ITエンジニアとしての基本的な能力に加えて、AIと一緒に開発を進めるための、実務的なコミュニケーション能力そのものだと感じた。
最後に
PVNMの開発を通じて、AIは確かに強力な開発支援者になり得ると実感した。
特にこちらの意図を汲んだ実装をしてくれるシーンも多々あった。
「遅い」「分かりづらい」「こんな感じにしてほしい」といった、人間の感覚的な感想・要求までもある程度正確に把握して、それをコードとして具現化させてくれることが非常に助かった。
一方で、AIがすべてを自動的に解決してくれるわけではない。
特にアプリ開発のように、仕様、UI、状態管理、ファイル、ビルド、配布が絡む作業では、利用者側の理解や伝え方が結果を大きく左右する。
今回の検証は、「非エンジニアでもAIだけで簡単にアプリを作れる」と証明するものではなかった。
むしろ、次のことを示す検証だったと思う。
AIを使うことと、AIを使いこなすことは違う
そして今後のエンジニア教育では、この「AIを使いこなす力」をどう育てるかが重要になると考えている。
以上