生成AIにアプリを作らせるコツ

Claudeの3.5-sonnet最新版(20241022)は間違いなく現時点では最高性能のLLMの一つである。Claude Professional PlanならそれをウェブUI・アプリ上から無制限と言ってもいいほど使える。

もともと、ある要件を実現するためにどうするのがいいか？選択肢を知りたくて、Claude sonnetやChatGPT Plus(gpt-4o, o1-preview)などに聞いてみたら、Claude sonnetが一番好みのアイデアを返してくれたので、さらに深掘りしてアプリを作らせたみた。

• OpenAI o1-previewは思いもよらないスマートな解決方法を提示してくれることがある。アイデアを知りたいときに一考の余地はある

• OpenAI gpt-4oは割とベタというか、微妙？

• SearchGPTは現時点ではコンテキストを無視しがち（単体の検索はいいけど、それ以上を求めると、指示への追従が著しく悪くなることがある）

• sonnetは現実的でユーザーのほしいものを提示してくれる傾向があるかもしれない。現時点では文句なしに一番賢い

最新のsonnetは結構本格的なアプリを作れてしまうが、同時にコツも必要だなーと感じたので、どうやって本格的なアプリを作らせるのか？というのを記事としてまとめた。

• sonnetなら、現実的にアプリを作らせられそうだがノウハウとかコツが必要

• エラーメッセージを貼り付けると大体いい感じに修正してくれるか、理解するためのデバッグ出力をふやしてくれる

• 初手で「デバッグ出力を必ず埋め込むようにして」「関数や型には必ずJSDocを書いて、書ける限りユニットテストを書いて」と書いておくと、色々捗る

• 都度リファクタリングや、設計方針を指示する必要がある

• いつもの結論になるが「結局は指示を出す人次第」ではある

今回ほしかったもの

仕事や趣味で、環境を分けたい。完全な独立環境じゃ無くてもいいから、アカウントは分離したい。環境はMac

やりたいこと:
* その仕事の始まりに、コマンド一つで、昨日の続きを「全部そのまま」立ち上げる
* その環境の中で快適に仕事ができる
* その仕事の最後、その状態を維持したまま終了

使いたいソフト:
* VSCode
* Safari（どうしても無理ならFirefoxなどでも可能）
* Slack
* terminal

実現したいこと:
* なるべく軽いこと。少なくとも快適に仕事ができること
* VMWare/Parallels/Virtualboxなどは重いため使いたくない
* これをいくつも用意したい（案件ごとに切り替えたい、趣味用に切り替えたい）

というようなプロンプトだ。このプロントの仮想マシン（VMWare…）に関する文言は何度かやりとりして追加したもの。gpt-4oなんかは特にこの選択肢を執拗に進めてくる。（その環境の中で快適に仕事ができるに反するため、プロンプトに追加した）

この文言の場合、gpt-4oはdockerを推奨し、o1-previewだと「ユーザーを作成して、切り替えろ」と言ってくる。ユーザーを切り替えるのはある程度まではありだなーと納得できたのだけど、「これをいくつも用意したい」を軸に考えるとユーザーを大量に作るのはちょっと面倒だ。

ぼくの想定: 会社の仕事、技術探求（テーマにより複数）などを想定しているので、数多く作成したい。

別の選択肢としてUTMを提案されることもあった。個人的にはUTMはよく知らないので、今後UTMも検証してみたい気持ちはわいてきたが、今回は置いておく。

さて、我らがClaude Sonnet最新版はというと、「簡単なシェルスクリプトで良くない？」というとてもエンジニア好みの解決法を提示してくれた。

アプリを作らせる

そこでそのアイデアを発展させるために「BunでうごくTypeScriptで」という指示を出し、さらなるアイデアや修正をあれこれ投げていくと、結構長大なコードにまで発展したのだ。アプリと言えるだけのものにはなった。

• ターンを重ねても破綻しない。これまでのLLMだとあまりにもやりとりが増えると、破綻することがあったけど、sonnetの持つコンテキスト長（200kトークン）のぎりぎりまでは破綻しないっぽい

• ただし、ターンを重ねると、部分的な修正案を出しがち。複数ファイルは基本的に全部一つのartifactにまとめてくるので、手作業で分離する必要がある

  • 指示すれば、フルサイズのソースをだしてくれるから、実は冒頭で必ず全部フルサイズで出してという指示をしておくのはありかもしれない。ただしその場合、コンテキスト長が増えがちなので一長一短あり

  • まだ実験してないけど、手作業で分離しなくていいような形式で出させれば良いかもしれない。diffを吐き出させるのはありか？

  • 一つのartifactにまとめている場合コメント分でソースコード名が書いてあるので、それを手がかりに分離してソースを更新するツールを用意しておけばいいかも

• 基本的には、動作の様子とコンソール出力を全部提示してあげるとデバッグなり改善なりしてくれる。修正の精度はかなり優秀

  • もちろん仕組みそのものに問題がある場合は駄目な可能性が高めなので「この仕組みだとこうだから、こういう仕組みの方が良いのでは？」みたいに指示する必要はあるかも。ただし、何度も失敗するといい感じに新しい仕組みを考えようとはしてくれる

• 修正の方法がわからないときはデバッグ出力を埋め込もうとしてくれる

  • それによって「ああ、こうこう、こういう理由で失敗してますね」と言ってくる

  • これは、最初に「デバッグ出力を必ず埋め込むようにして」と指示しておくと捗るかもしれない

• 力作になってきたら「日本語でREADME.mdを書いて」とか「設計書を書いて」という指示を出すと良い

• 「exportしてる関数や変数には必ずJSDocを書いて」「ユニットテストを書いて」も有効

  • これも、最初に「関数や型には必ずJSDocを書いて、書ける限りユニットテストを書いて」と指示しておくと捗るかもしれない

• 力作になってくると、相手がデバッグしてくれるとしても結構面倒になるので「プロセス起動と終了だけを分離して、簡単に動作検証できるようにして」というような感じで、技術的課題を分離した方がいい

• というか、都度リファクタリングはさせておくと良い

  • 「ハードコーディングはやめて分離して」くらいでも結構ちゃんとリファクタリングしてくれる

  • リファクタリングをしておくと、ファイル一つのサイズが減るのでコンテキスト長を結果的に減りそう

  • 人類がプログラミングするのと同じだ…

• 「全部にコメント書いて」と言っておくとコメントを書いてくれるので、コードが理解しがたい物になってきたらそうした方がいいかもしれない（コンテキストが増えるのと理解し終わったあとに面倒なので、別チャットを開いてやるか、GitHub Copilot Chatでやった方がいいかもしれない）

• 途中でコンテキスト長がえげつないことになったので、新しく作り直させたのだけど、READMEとか設計書があればある程度の継続も可能

  • うまく追求すれば、より自在に継続ができるようになるかも。要検証

• このツールに名前を付けてで名前を付けてくれる

• マジでsonnetかしこいわ

コード生成はGitHub Copilotのインライン補完派なので、ここまでがっつりコードを書かせていなかったのだけど、sonnetならかなり実用的だと思う。とは言え、ポイントを押さえないといけないことが分かった。次回はもっとうまくやれそう。このアプローチは引き続き検証していきたい。

オチ

ちなみにアプリのみでやるのは技術的に面倒な点が多いことは分かった。

• 特定workspaceのソフトだけをストップさせるのは面倒が多い

  • そもそも手動で操作すると破綻する

  • まぁいい刺激にはなった

• mission controlを使って、デスクトップの切り替えとかもできるけどCLIツールでそれをやるのはかなり難しそう

  • これもデスクトップ間の操作を手動でやると破綻する

  • というかVSCodeのアップデートは、問答無用で全部のVSCodeを再起動するので破綻する

  • まぁいい刺激にはなった

• 素直にDockerかUTMかユーザー切り替えを考慮した方がいいかもしれない