前々回は判断の軸、前回は高性能モデルを使うべき場面を扱いました。最後に、軽量モデル(低コストモデル)で十分な場面と、それらを組み合わせた実践的なワークフローをまとめます。あわせて、冒頭の「新しいものを考えながら作るときはバイブコーディング的に軽量モデルでいい」という考え方についても、一部賛成・一部注意という形で整理していきます。
軽量モデルで十分な場面
- 定型的なコード生成:CRUD処理、Reactコンポーネントの雛形、単体テストの雛形など、既存パターンをなぞるだけの作業
- 機械的なリファクタリング:命名規則の統一、import文の整理、既に決まった書き方への揃え直し
- ドキュメント・コメントの生成:関数の説明コメント、READMEの叩き台作成
- 小さな修正:1〜2箇所の明確なバグ修正、タイポの修正
- 選択肢を絞った上での実装:「この設計方針で、この関数を実装して」というように、判断すべき部分をすでに人間側が決め切っている作業
これらに共通しているのは、「何を作るか」がすでに明確で、あとは手を動かすだけという点です。ここに高性能モデルを使うのは、単純に無駄遣いになりやすいです。
「新しいものを考えながら作る」は要注意ゾーンです
ここが今回一番お伝えしたいポイントです。「全く新しいものを考えながら作る」というフェーズは、実は次の2つが混ざっています。
- 方向性を決める部分(どういう構造にするか、どこまで作り込むか、技術選定)は、前回述べた「判断が主役」のタスクです
- 決めた方向性の上で手を動かす部分(実際にコンポーネントやAPIを書いていく)は、軽量モデルで十分な「作業」です
「バイブコーディング的に軽量モデルで進める」という発想自体は、②のフェーズでは理にかなっています。ラフに試作を繰り返して「動くものを見ながら考える」進め方は、むしろ軽量モデルで高速に回したほうがいい場合が多いです。
ただし①の「最初の方向性」を軽量モデルに任せてしまうと、あとから設計の前提がひっくり返るリスクが高くなります。とくに新規プロジェクトの初期段階で、状態管理の方式やデータの持ち方、モジュール分割の基本方針といった「あとから変えると影響範囲が広い決定」を軽量モデルの提案のまま進めてしまうと、プロトタイプが育った頃に大きな手戻りが発生しやすくなります。
つまり実務的には、「新しいものを考えながら作る=ずっと軽量モデル」ではなく、最初の方向づけだけ高性能モデルに相談し、そのあとの試行錯誤は軽量モデルでどんどん回すというハイブリッドが、最もクレジット効率が良いと言えます。
実践的なワークフロー例
- 企画・設計フェーズ(高性能モデル):作りたいものの要件整理、技術選定、大枠のアーキテクチャ決定を高性能モデルと壁打ちします。ここで方針をドキュメント(READMEやdesign.mdなど)に落としておきましょう。
- 実装フェーズ(軽量モデル):決まった方針に沿って、軽量モデルでどんどんコードを生成させます。バイブコーディング的にテンポよく試作を進めるのはここです。
- 詰まったら一時的に高性能モデルへ(必要なときだけ):原因不明のバグ、想定外の複雑な依存関係、セキュリティに関わる箇所が出てきたら、その部分だけ高性能モデルに切り替えます。全体を高性能モデルに戻す必要はなく、局所的な相談で済むことが多いです。
- 仕上げフェーズ(軽量〜中間モデル):リファクタリング、テスト追加、ドキュメント整備は軽量モデルで十分なことが多いです。
まとめ
高性能モデルと軽量モデルは対立する選択肢ではなく、「意思決定のコスト」と「実装のコスト」を別々のモデルに割り振るための道具だと考えると、クレジットの使い方に迷いがなくなります。「新しいものを考えながら作る」ときほど、最初の一手だけは高性能モデルに相談する習慣をつけておくと、あとで痛い目を見にくくなるはずです。