はじめに：非エンジニア管理人がChatGPTでゲーム開発していたら…
非エンジニアの管理人。現在、ChatGPTを使って一人でゲーム開発を進めています。いわゆる“バイブコーディング”──AIとの対話を通じてコードを生成し、試行錯誤しながら形にしていくスタイルで作成しています。
最初は、何も考えずにGPT-5のAutoモードを使っていました。とにかく速いし、返ってくるコードもちゃんと動く。非エンジニアの自分でも「動くもの」が作れていました。
でも、ある時ふと違和感を覚えました。
「あれ？この処理、前にも似たようなの見た気がする…」
コードの整合性が崩れたり、同じような処理を何度も繰り返したり。無駄な工数が積み重なっていくのです。
そこで試しにThinkingモードに切り替えてみたら、世界が変わりました。
Thinkingモードの真価：遅いけど、賢い
ThinkingモードはAutoよりも応答に時間がかかります。ですが、その分、得られるものが違います。
- ✅ コードの再利用性が高い：過去の文脈を踏まえた提案が増える
- ✅ 構造的な提案が多い：関数分割、命名規則、エラーハンドリングなどに配慮
- ✅ 無駄な工数が減る：一発で「使える」コードが出てくる確率が高い
非エンジニアの管理人にとって、これは大きな違いでした。Thinkingモードでは、複雑だったり長かったり多岐にわたったファイル群だったりをかなり正確に把握し修正・改修・提案してくれます。いっぽうAutoでは「とりあえず動く」コードが出てくるのですが、コードが複雑になるにつれて二歩進んで一歩さがるようなことが増えて、ストレスを感じました。
なぜAutoを使いがちなのか？その“罠”を考える
多くの人がAutoモードを使っている理由は、単純です。最初からそれが選ばれているから。モードの違いを意識することなく、そのまま使い続けている人がほとんどでしょう。
そして実際、Autoで十分な場面も多い。ちょっとしたアイデア出しや、簡単なコード修正、日常的な質問には、Autoのスピード感が心地よく感じられます。
筆者も最初は「速く返ってくる＝正しい」と思っていました。非エンジニアだからこそ、テンポよく進むことに安心感があったのです。
でも、ここに“罠”があります。
「速いけど、浅い」
Autoは“その場しのぎ”には向いていますが、プロジェクトの中長期的な整合性や保守性を考えると、思わぬ落とし穴があるのです。命名規則がバラバラだったり、似たような処理が何度も繰り返されたり、設計思想がブレたり…。
Thinkingモードはその逆。遅いけれど、深い。文脈を踏まえた提案、構造的な設計、将来の保守性まで見据えた回答が得られることが多く、結果的に工数が減ることも珍しくありません。
筆者のおすすめはこうです：
- 🛠 Autoで試して、違和感があったらすぐThinkingに切り替える
- 🧩 設計や構造の相談は最初からThinkingで行う
- 🧠 非エンジニアこそ、Thinkingの“説明力”に助けられる
Thinkingは、ChatGPTの“本気”を引き出すモード。Autoが「便利な助手」なら、Thinkingは「頼れる共同開発者」です。適材適所ですね。
ChatGPTも、やはりツール。状況を判断してThinkingモードを進めては来ませんでした。使用者がツールの特性をしっかりと把握することによって、モードの選び方ひとつで、プロジェクトの質も、理解の深さも、工数も変わってきます。
騙されたと思って、Thinkingを使ってみてください。
きっと、ChatGPTの“別の顔”が見えてくるはずです。
コメント