見出し画像

今バイブコーディングするならこれを選べ

今私が技術選定で利用しているものを全部書きます。

これはこの技術を使わないとだめとか、パフォーマンスがでないというものではなく、技術選定という面倒なものをする必要が無い人が、とりあえず選択したら楽になる、困りどころが少なくなるというポイントに絞って記載しています。

それぞれ理由も書きますが、基本的にはその選定をすれば大体は面倒な問題に悩まされる事は減ると思います。


Mac を使え

Mac を使わないといけない理由はシンプルで、今の AI 環境は Mac が明確に優遇されています。

そして単に優遇されているだけじゃなく、色々な要因が噛みあわさって、唯一無二の状態になっています。

Unified Memory の存在

今市販で購入できるハードであたり前のようにユニファイドメモリがついているのは Mac です。

M シリーズといわれるものはこれですが、爆速でバッテリー消費が激しくなく、今の LLM ツールを使う場合にメモリをどか食いするので必須になっています。

アクセシビリティの強さ

後述する Computer Use に関係があるのですが、Mac を AI が操作するのに必要な機能が Mac は豊富です。

そのおかげで、AI の Mac 操作の精度が非常に高く、Codex と組合せる事で異常なほどのパフォーマンスを発揮します。

私はほぼ Mac に触らず一生 AI がテスト → 改善を繰替えしています。

もちろん、この記事を書いている間にもやっています。

アプリケーションが Mac 対応から入るものが増えた

AI 関連ツールで、何かにつけて最初は Mac だけ対応というものが増えました。

もはや最新の AI を楽しめるのは Mac だけといっても過言ではないくらいです。

AI 開発体験、つまりバイブコーディング体験が一番良い環境は Mac です。

本当は Linux 派なんですが、開発体験は大事なのであらがえませんでした。

AI ツールは Codex を使え

今バイブコーディングにおいて Codex は一強というべき存在になっています。

Claude Code ?

全く人の言う事を聞かないのでバイブコーディングのメインに据えると面倒な事になります。デザインセンスや日本語能力、文章センスは Fable や Opus が高いですがそれだけです。

バイブコーディングにおいて重要なのは、指示に従って根気強く作業をしてくれる事です。

Codex の利点と予算に応じた使い方

正直、Codex の Pro プランを使って欲しいです。

理由はいくつかあります。

1 つ目:gpt-image-2 という画像生成モデルが使い放題

2 つ目:/goal を使った無限作業指示が圧倒的に強く、これに耐えるレートリミットが必要になる

3 つ目:GPT-5.6 Sol Max を気兼ねなく使える

4 つ目:Computer Use が異常に強い

この 4 つがメインの理由ですが、Pro は 30,000 円のものじゃなくて、安い方でも十分だと思います。

並列で 3~4 つを毎日動かしたかったら 30,000 円のものにするか、基本利用のモデルを Luna Max にしてください。

Sol Max 固定で利用するならプロダクトを 1 つに絞ったら安い方の Pro プランでも足ります。

そして、Computer Use + /goal をガンガン使い倒したいなら Pro 30,000 円プラン 1 択です。

Codex で画像を出力する

$imagegen というコマンドがあり、このコマンドを使う事で画像を gpt-image-2 で生成させる事が可能になります。

このコマンドをどう使うかというと、アプリケーションの UI の生成に利用します。

つまり、アプリの仕様を AI と決めていき、仕様ファイルを作成し、そのファイルの内容から良い感じの UI を画像として出力して貰い、それを元に /goal を使って UI 通りのアプリを開発させるという流れです。

Claude を契約してないならこの流れで開発すれば良い感じの UI のアプリが開発できます。

一旦下地を作ればあとは雰囲気を読みとって調整していってくれます。上手くいかなくなったら再度 UI を生成させてその通りに作らせるというのを繰り返します。

フロントは TypeScript 7 を使え

TypeScript 7 というのはバージョンの事で、このバージョンからコンパイル速度が爆速になっています。

AI は高速に開発をしてくれるので、コンパイルの速度が遅いと開発速度が顕著に下がります。

そのため、高速な環境で開発する事を強制するために必要となります。

出来れば oxlint/oxfmt や Biome などの爆速なリンタ/フォーマッタをあわせて利用するようにしてください。

バックエンドは Go を使え

Go は TypeScript と違いゆるふわな型に落とす事が不可能な言語です。

型表現は TS ほど複雑なものは出来ないですが、しっかり型で縛れますし、今の Go はそれなりに柔軟に書けます。

そして、一番良いのがコンパイル速度が爆速という点です。

それだったら TypeScript 7 でも良いじゃないかと言われそうですが、そうじゃないんです。TypeScript はフロントエンドならマストですが、それは JavaScript から離れられなく、今選択する言語としてはフロントの中で一番ポピュラーで安定しているからです。

フロントの中で安定してるからといってバックエンドで運用して良いものと言えるかというと、そうではないです。

バックエンドは選択肢が大量にあるのでわざわざ型が JavaScript レベルまで退化する可能性のある言語にする必要はありません。

AI は型を緩めたり平気でしてくるので、どれだけ設定で縛っても無意味になる事があります。

また柔軟すぎる型システムのせいで型も気を抜くと any だらけで何も意味ないみたいになります。

なので Go みたいに設定する必要がなく、ちゃんと固い言語で、コンパイルが速い言語を採用したいという訳です。

私は Go をバックエンド + AI で開発してて困った事はありません。バイブコーダーは Go を使うべきです。

あとは自由にしていいよ

ここまでは必須の理解かと思っています。

あとは Cursor を使うもよし、Claude Code を使うもよしと、自由にしていいかと。

でも大事なのは今は AI は Codex を主軸に回っていて、Claude Code だけ使ってたらいいみたいな時代はとっくに終わっています。

そして、この環境も数ヶ月たつとまた変わるかもしれません。

今日の朝、Kimi K3 が発表されていましたが、これのパフォーマンスが Fable に並ぶくらいだという話で盛りあがっていましたが、逆に Codex + GPT-5.6 の優位性は全く揺らがないなという感想なので、まだまだ安泰ではあると思います。

基本は AI は自由なものを利用するべきですが、今市場のゲームを支配しているツールは理解しておくべきだと思いますので、まだ使った事がない人は私が今回書いた内容を一度試してください。

きっと世界が変わります。


現在メンバーシップは 7 月まで初月無料のキャンペーンとしています。
メンバーシップは ↓ から加入できます

いいなと思ったら応援しよう!