Claude Code開発でLLMの質を上げる理由：モデル性能より重要な設計と評価の徹底

LLMの限界を「モデルのせい」にするのをやめるだけで、開発の景色は一変する。

モデルを上位版に差し替えても、精度は上がらない。

コストだけが増え、ツール呼び出しの成功率は横ばいのままだ。

この壁はモデルの知能指数ではなく、開発者側の「工学的規律」の欠如が原因である。

10億トークンのコンテキストを「ただのゴミ箱」にしないための設計思想が問われている。

エージェント開発の主戦場は「モデルの外側」へ移行している

AIエージェントの品質を決める要素において、モデルそのものが占める割合は低い。

「精度が出ないからOpusに上げよう」という判断は、サーバーのCPUを増やすだけの安易なアプローチと同じだ。

エージェントの失敗の多くは、プロンプトの不備、ツールの設計ミス、エージェント構成の甘さに起因する。

エージェントの不具合は主に4つの階層で発生する。

「モデル」「プロンプト」「ツール定義」「実装コード」だ。

モデルの変更はコストが高く、他の要因を不透明にする「最後の手段」である。

多くの「動かないエージェント」は、モデルを据え置いたままプロンプトとツール定義を修正するだけで正常に動作し始める。

コンテキストウィンドウの巨大化についても考え方を改める必要がある。

100万トークンという広大なスペースは、何でも詰め込める「容量」ではなく、慎重に運用すべき「資源」だ。

入力が長くなればなるほど、モデルの忠実性や検索性能、推論精度は劣化する。

各ターンで「今、本当に必要な情報は何か」を動的に判断し、情報を削ぎ落とすロジックが不可欠だ。

しんたろー：
賢いモデルを使えば解決すると思っていた。
Claude Codeで開発していると、結局はツール定義の1行をどう書くかのほうが効く。
モデルに丸投げするのは、仕様書を書かずに新人に丸投げするのと同じだ。

ツールの説明文（description）の書き方も重要だ。

「人間に向けたドキュメント」のように詳細に書く。

形式、制約、具体的な入力例をセットで記述することで、モデルの「推測」という不確定要素を排除できる。

曖昧な指示は推論のブレを生み、システムの信頼性を損なう。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

開発者が習得すべき「エージェント工学」の3つの柱

モデルの性能に依存しない「エージェント工学」のスキルセットが求められる。

第一の柱は、「動いた」を「測れる」に変える評価スイートの構築だ。

評価スイートがない状態での開発は、目隠しをして走るようなものだ。

実装の前に評価コードを書く「評価スイート先行型開発」がエージェント品質を担保する。

評価の基準は5つの要素で構成される。

「入力」「期待される出力」「実際の出力」「採点ロジック（Grader）」「スコア」だ。

採点ロジックに安易にLLMを使わない。

コードで判定できるものはコードで書く。

これがコストを抑え、評価の安定性を確保するための鉄則だ。

第二の柱は、モデルの内部状態に直接介入する手法への理解だ。

プロンプトによる「お願い」ではなく、モデルの計算過程である「残差接続（residual stream）」に特定のベクトルを足し算することで、出力を強制的に操作する技術がある。

これは「アクティベーション・ステアリング」と呼ばれ、感情やトーン、特定の思考プロセスをモデルに定着させる手段になり得る。

プロンプトエンジニアリングの限界を超え、モデルの「脳内」を直接書き換えるアプローチだ。

しんたろー：
プロンプトで「明るく話して」と100回書くより、内部ベクトルを1回いじるほうが確実だ。
実験段階だが、これが実用化されればプロンプトの「おまじない」が不要になる。
Claude Codeの挙動も、いつかこうやってチューニングできるようになるかもしれない。

第三の柱は、推論エンジンとモデルの最適な組み合わせの選定だ。

どのエンジン（Ollama、vLLM、SGLangなど）を使い、どの量子化手法を選択するかが、ツールコールの成功率に直結する。

特定の環境では「Qwen3.5」や「Gemma 4」といったモデルが、速度とツールコール精度のバランスで高いパフォーマンスを示す。

開発者は、有名なモデルを選ぶのではなく、自分の実行環境における「実測値」に基づいた選定眼を持つ必要がある。

僕らの開発に「規律」を取り戻すための具体策

まずは、「モデルを上げる」という選択肢を自分の中で禁止する。

今使っているモデルのままで、どうすれば問題を解決できるかを徹底的に考える。

プロンプトの構成を見直し、ツールの説明文に具体的なJSONスキーマや制約条件を書き加える。

これだけで、多くの問題が解決する。

次に、コンテキストを「動的」に管理するロジックを実装する。

過去の履歴をすべて送るのではなく、現在のタスクに関連する情報だけをフィルタリングして抽出する「コンテキスト・エンジニアリング」を導入する。

これは、プログラムにおけるメモリ管理と同じくらい重要な、エージェント開発の基礎教養だ。

そして、「LLM-as-Judge」に頼り切らない評価系を組む。

出力のJSONが正しい形式か、必須のキーが含まれているか、期待される数値範囲に収まっているか。

これらはすべて、従来のユニットテストと同じようにコードで判定できる。

LLMによる評価は、言語的なニュアンスが必要な部分だけに限定する。

しんたろー：
AI開発も「地味な作業の積み重ね」だ。
派手な新モデルのニュースに踊らされる前に、手元のプロンプトを1行直す。
その積み重ねが、最終的に「使えるプロダクト」と「おもちゃ」の差になる。

新しい技術へのアンテナを張りつつも、常に「自分の環境での実測」を重視する。

海外のベンチマーク結果は参考にはなるが、自分のプロダクトのユースケースで同じ結果が出るとは限らない。

「$1,000のGPUで、何トークン/秒出せるか」「ツールコールの成功率は何%か」

こうした具体的な数字を積み上げることが、開発者としての信頼を築く方法だ。

FAQ

Q1: LLMのツールコール精度が低い場合、まず何をすべきですか？

モデルを変更する前に、まずはツールの「説明文（description）」を徹底的にブラッシュアップしてください。

人間が見ても迷わないレベルの仕様書として記述し、パラメータの形式、制約条件、具体的な入力例（Few-shot）をセットで明記します。

モデルが「推測」しなければならない余地をゼロにすることが、精度向上の最短ルートです。

それでも改善しない場合は、推論エンジンや量子化設定がツールコール性能に与える影響を疑い、環境側の最適化を検討してください。

Q2: コンテキストウィンドウを「資源」として管理するとはどういうことですか？

巨大なコンテキストウィンドウが利用可能であっても、情報を詰め込みすぎると「コンテキスト・ロット（情報の腐敗）」が発生し、精度が低下します。

これを防ぐには、実行時の意思決定ロジックを組み込み、現在のターンで本当に必要な情報だけをプロンプトに含める設計が必要です。

情報を削ぎ落とし、モデルの注意力を特定のタスクに集中させることこそが、高度なエージェント設計の核心です。

Q3: アクティベーション・ステアリングは実務で使えますか？

現時点では探索的な技術ですが、プロンプト指示に従わないモデルの挙動を、内部ベクトル操作で強制的に補正できる可能性を示しています。

特定の感情トーンを固定したり、安全性を担保したりする手段として、プロンプトエンジニアリングの限界を突破する有望な技術です。

ただし、モデルのアーキテクチャに深く依存するため、まずは特定のモデルを用いた小規模な実験から開始し、その挙動を慎重に観察してください。

まとめ

LLMエージェントの品質は、モデルの賢さではなく、開発者の「設計」と「評価」の密度で決まる。

「モデルを差し替える」という誘惑を捨て、ツール定義を磨き、評価を自動化する。

この地味で泥臭い工学的アプローチこそが、AIを「信頼できる道具」へと変える道だ。

👉 ThreadPostでSNS運用を自動化する