2026年7月22日(水)掲載 2,843本日 0
HN5812

LLMの使い分け術:フロンティアモデルは「ここぞ」という一発で使え!

You only need the frontier model for one single edit

jxmorris127日前

議論

11
0jxmorris12スレ主587日前

全工程を高性能なフロンティアモデルに頼る必要はありません。本当に価値を発揮するのは、複雑な推論や最後の仕上げとなる「たった一度の編集」のタイミングだけです。それ以外の単純作業は、より軽量でコスト効率の高いモデルに任せてしまいましょう。

1pistoriusp約23時間前

どうやら「/prewalk」は https://github.com/can1357/oh-my-pi に組み込まれているみたいだね。これって「Oh My ZSH?」のPi版で、必要なものが全部入りって感じかな。興味深いアイデアがいろいろ詰まってるけど、自分のワークフローにはまだ取り入れてないかな。使ったことある人いる?

2the_gipsy約23時間前

シニアアーキテクトにジュニアエンジニア。最高に聞こえるだろ?

コンサルという名の食肉処理場って感じだな。Java Enterprise Solutionsを想像してみてくれ。まあ、ソフトウェアエンジニアリングの頂点(笑)ってやつだ。

3wrs約22時間前

最近はこんなバリエーションを試してる:メインのエージェントに段階的な実装計画を立てさせて、各フェーズごとにフォーカスを絞ったプロンプトで実装用サブエージェントを立ち上げ、その成果をメインセッションでレビューするっていうやり方。こうすればメインセッションにすべての調査結果を残しつつ、実装セッション全体のコンテキストを抱え込まずに差分だけを確認できるという理屈だ。

元の投稿にはコスト比較のレビューが含まれてないけど、個人的にはその場でレビューするほうがミスをたくさん拾える気がする。

4Almondsetat約22時間前

この記事もGemini Flashで書かせたの?正直言って、読むに堪えないんだけど。

5rwc約21時間前

効率的なモデルを使うのは、タスク実行のコストが上位モデルを使うより安く済む場合に限定すればいいだけだよ。Fableならその指示に基づいたルーティングなんて余裕でこなせる。

6viccis約21時間前

私のワークフローも似たような感じだな。Fable 5 / Sol on Highに要件を設計できる状態になるまで話し合わせる。その後、設計をチケットに分割させるんだ。私はエージェント指向の課題トラッカーであるkataを使ってる。もし肥大化してきたら自分で作るつもり。大した機能は必要ないからね。とにかく、実装用エージェントが受け取れるように、各チケットに十分なコンテキスト(明確なユーザーストーリーやCucumberスタイルの受け入れ条件など)を含めるよう指示してる。

それが終わったら、小さいモデルに切り替えて「/goal」で kata ready を呼び出し、チケットを作業可能な状態にさせる。各ゴールのイテレーションでチケットを1つずつ片付けて、完了したらコミット。チケットがすべてクローズするか、自分待ちの状態になったら終了。

これ、めちゃくちゃ上手くいくよ。iOSアプリ丸ごと(比較的単純なものなら)月額20ドルの5時間セッション枠内で完成させられるし。

さらに良い結果を得るために、フロンティアモデルを使ったQAセッションで「実装スペック」と「Claude Design用の設計プロンプト」という2つの成果物を作らせることもある。そのプロンプトをClaude Designに通して結果を調整すれば設計スペックが完成する。計画を立てる時に、フロンティアモデルに以前の実装スペックと設計スペックの概要ファイルを読み込ませるんだ。

この方法だと、Fable 5とSolでA/Bテストをしても書かれるアプリはほぼ同じになる。いわゆる「サブエージェント艦隊を放つ!」系のコンテキスト管理よりずっと安上がりだよ。

まだフロンティアモデルの検証サイクルはループに組み込んでない。みんな「デカいモデルがドローンたちの成果をレビューする」みたいなフローの話ばかりするけど、受け入れ条件をうまくエンコードできれば、ドローンだけでも十分満足いく仕事をしてくれるよ。

7hankbond約21時間前

「棒グラフが本棚になってて、背表紙にホバーするとカバーが見える」っていうあの最高にイケてる可視化手法、名前わかる人いる?これまで見たことがなくて。

8Bolwin約20時間前

「プランファイルを作らずセッションを新しくしてモデルを切り替える」っていうのを、かなり回りくどく言ってるだけじゃないかな。私はどのみちそうしてるし。

ただ、プランを読むのに時間がかかって休憩を挟むと、その間にキャッシュが切れてることが多いんだよね。そうなると最初からやり直す方がマシなこともある。

9pphysch約20時間前

どのエージェント、どのモデル、どの足場を使おうと、料金は実質的にO(読み込み量)に依存する

つまり、トークンを売る側には、冗長で読みづらいコードを生成させるインセンティブが働いてるってことか。

10figmert約20時間前

私が「計画してから実装」の手順を踏むのは、計画なら調整がきくからだよ。いきなり実装させると、修正が難しい間違った判断を(よく)しちゃうし、後から直す羽目になるからね。