（下記のテキストは gemini 2.5 proに提案してもらったものに修正をくわえたものです）
このメモはなんのメモか：LLMまかせっぱなしコーディング（vibe coding）は、めちゃ便利だけど、まあまあ行き詰まるポイントがあるので、そのメモです。このメモの作成者はプログラマーではない人間なので、そういう人間の備忘録以上のものではありません。主にやっているのはブラウザベース2Dゲームの開発とかです。「LLMに任せるにしても、とはいえ、ある程度のリテラシーはやっぱり必要」の「ある程度」がどこらへんにあるのかを手探りで確認していくためのメモです。
1. AI支援でプログラムを作る人に求められる要素
1.1 そもそも何をつくりたいか
あたりまえなので省略。
1.2 技術に対する理解に基づいた作成手順（ある程度複雑なものの場合）
簡単なプログラム（500行ぐらいまで）だと、o1 proとかgemini 2.5 proならあまり悩まずにお願いできる。ただ、それを超えて、ある程度複雑な仕組みを作る場合には、いろいろとて考える必要が出てくる。実際に動く、ある程度しっかりしたプログラムを作るためには、技術的な部分を意識する必要はやはりある。
1.2.1 要求仕様の明確化（何を作るか具体的に決める）：
- 要求仕様の明確化自体も「雑な案」をLLMに投げて、案をつくってもらうことができる。ただ、そこで出てきた仕様がいきなり長大で細かすぎると、読むのがダルくなるので、いきなり「雑な案」→「めっちゃ細かい仕様」にいくのではなく、「もう少しだけ細かい仕様の案に落としてみてくれる？」みたいな手順を踏むとよいかもしれない。
1.2.2 段階的な実装（少しずつ作る）：
中心的な機能や、まずは簡単な部分から少しずつ作り始め、試しながら改善を繰り返していく方法（反復開発）がベター
1.2.3 既存技術とツールの活用（便利な部品や道具を使う）：
プログラムの動き（物理演算）、画面操作、ネットワーク通信など（後述）はライブラリ、フレームワークに頼ったほうがよい。HTML5 Canvasやゲーム作成を助けるPhaser.js。※UnityやGodot Engineなどの「使い方」をAIに教えてもらうというのもありだが、ゲームエンジン利用は言うほどLLM丸投げにはならないので、ライブラリやPhaser.jsなどのほうがLLM丸投げ感がある。
1.2.4 全体構造の設計（プログラム全体の骨組みを考える）
- 機能を適切な単位（部品＝モジュール）に分け、それらの関係性を整理する必要があるが、正直、技術的なリテラシーがないと、その設計自体がいま一つ謎なので、この設計もLLMに相談しながらすすめるほかない。設計内容をLLMに伝える際には、MermaidやPlantUMLといったフォーマットでUML図などを表現する書き方を使うと、構造を分かりやすく示せ、より具体的な相談がしやすくなるはず。
2. 環境と道具
- 高機能なLLM／APIとの契約：GoogleないしOpen AIに金を払うべし
- AI機能付きコードエディタ: Cursor, Clineもいいらしい。これも金がいる。
- テキストによる作図ツール: MermaidやPlantUML
- 変更履歴の管理（バージョン管理）: Git（およびGitHub/GitLabなどの関連サービス
Claude Codeがいいらしいがまだ試してない。
3. ライブラリやフレームワーク等の活用が推奨される機能例リスト
下記の項目を無理にLLMにやらせるとやるにはやってくれるけど「ライブラリなしで」とか言うとまあまあバグる。（ライブラリとか、フレームワーク前提でもまあまあバグる）
- 画面表示・グラフィックス関連
- 高度な2D/3Dグラフィックス描画 (影、光、特殊効果など)
- 複雑なユーザーインターフェース部品 (表計算のようなグリッド表示、ファイルツリー表示など)
- グラフやチャートの描画 (棒グラフ、折れ線グラフ、円グラフなど)
- ウィンドウや要素の配置を自動調整する仕組み (レイアウト管理)
- 滑らかなアニメーション (キャラクターの動き、画面の切り替わりなど)
- マウスなどによるドラッグ＆ドロップ操作
- 動きの計算・シミュレーション
- 物体のリアルな衝突や跳ね返り (物理演算)
- 水や煙などの流体の動き
- 布やロープのような、柔らかい物体の動き
- データの扱い
- データベースとのやり取り (データの保存、読み出し、検索など)
- 入力されたデータが正しいかどうかのチェック (バリデーション)
- データを特定の形式（JSON、XMLなど）に変換したり、元に戻したりする処理 (シリアライズ/デシリアライズ)
- 大量のデータを効率よく扱ったり、検索したりする仕組み
- 特定の形式を持つファイル（画像、音声、Excelファイルなど）の読み書き
- ネットワーク・通信
- リアルタイムでの双方向通信 (チャット、オンラインゲームの同期など - WebSocket等)
- WebサーバーやWeb APIとの通信 (データの送受信、ログイン認証など)
- 他のWebサービスや機能との連携 (API連携)
- AI・機械学習関連
- 画像の内容を認識する (画像認識)
- 人の言葉を理解したり、処理したりする (自然言語処理)
- データから学習して予測などを行う (機械学習モデルの利用)
- ゲームキャラクターの賢い動き (経路探索、行動決定AI)
- セキュリティ関連
- ログイン認証や権限管理の仕組み (本人確認、アクセス制御)
- データの暗号化や、パスワードを安全に保存するための処理
- 不正な入力からシステムを守るための処理 (セキュリティ対策)
- その他
- 複数の処理を同時に、または効率よく進めるための制御 (並行処理・非同期処理)
- 多言語対応や、国・地域ごとの表示形式の違いに対応する処理 (国際化・地域化)
- プログラムが正しく動くかを確認するためのテストコード作成や実行の仕組み (テストフレームワーク)
- プログラムの動作記録（ログ）を効率よく収集・管理する仕組み
4.現時点までで困ったこととその対策
- ワーキングメモリーの限界（よくある）
- 機能別モジュール切り分け失敗（よくある）
- エラーがループ（よくある）
- 例：何度エラーコードを貼って、修正してもらっても同じエラーがでる。
- 対策：
- （１）うまくいっていたところまで戻って、モジュールに切り分ける
- （２）用いる技術自体を別のものにする
- （３）自分でソースコードを読む
- （４）デバック用に問題を切り分けて、問題が発生している部分を特定する
- （５）利用するLLMを変える
- （６）複雑な実装ではなく、愚直で着実な実装にする
- （７）「YES」「ACCEPT」ばっかりおさずにLLMが言っていることをちゃんと読む。
- 明らかに実現してほしい状態ではないのに完璧だと言い張られる（よくある）
- 例：JavaScriptで座標が反転した状態で表示されてしまうが、LLMにいくら修正をお願いしても「バグはない」とつっぱねられる。
- 対策：
- （１）生じているバグをなるべく細かく具体的にLLMに述べる
- （２）生じているバグの原因となっているかもしれないものについて、可能な限り推測をめぐらしてLLMに相談する（推測をめぐらす脳みそを使うのをLLMに相談してもよい）
- （３）実装環境ごとに起こり得るバグについて勉強する・経験を積む
5.Vibe Codingの限界
- 柔軟性の限界：つくることを指示した人間が中身の構造を理解していないので、特に大規模なものになってくると「ちょっとした変更」がうまくいかないことが多い
- 不正確、安全性に欠ける、パフォーマンスの低いコード
