Claude Code開発でClaude 3.5 Sonnetの評価を自動化し作業時間を半減させる理由

AI開発のフェーズが変わった。

モデルのパラメータ数やベンチマークの結果を追いかける時代は終わった。

今の最前線は「いかに精緻な評価指標（eval）を持つか」と「AIと人間の役割をどうデザインするか」にある。

これを理解しているかどうかで、開発スピードには2倍以上の差が出る。

Claude Codeを使い倒している僕の視点で、最新のAIエージェント設計思想を解剖する。

エージェント設計の核心は推論力から評価と役割へ

最新の開発者向けカンファレンスで語られた内容は、これまでの常識を覆すものだった。

エージェント開発の焦点は、単なるモデルの賢さから、客観的な評価ループの構築へと移行している。

具体的には、高性能な知能をどう使いこなすかという「設計の妙」が問われている。

開発者が注目しているのは、AIエージェントが消費するトークンを 3種類に分類する という考え方だ。

これまでは単に「トークンを消費する」と一括りにしていたが、役割ごとにコストを意識する。

effort というパラメータは、このトークン配分をコントロールするためのダイヤルとして機能する。

これは、エンジニアやデザイナーを雇うときに、時間単価を細かく管理するのではなく「優先順位」を伝えるようなものだ。

適応的な思考プロセスである adaptive thinking も進化している。

モデル自身が「このタスクにどれだけ思考リソースを割くべきか」を判断する仕組みだ。

たとえば、2足す2という計算に膨大な思考トークンを使うことはない。

こうした最適化が、実質的な 開発速度の向上 に直結している。

現場でのケーススタディも示唆に富んでいる。

あるカスタマーサポートボットの事例では、never や always といった強い言葉をプロンプトに含めることの弊害が報告された。

「間違った情報を絶対に出すな」と指示しすぎた結果、手元にある正しいデータまで出し渋る 慎重すぎるモデル が生まれた。

防御的なパッチをプロンプトに継ぎ足すと、ルール同士が矛盾し始め、システムは崩壊する。

また、計算処理をプロンプト内で頑張らせるのも間違いだ。

日割り計算などの数学的な正確さが求められる場面で、プロンプトに「非常に重要！」と書き足しても 精度は1ミリも上がらない。

正解は、計算専用のツールをAIに渡し、AIには「ツールを使うかどうかの判断」だけをさせることだ。

さらに、エスカレーションの境界線も明確に引く必要がある。

コストを意識させすぎると、人間が対応すべき深刻なトラブルまでAIが自力で解決しようとする。

ルールを書くときは必ず 逆方向のガイド をセットで記述する。

「ただし、請求トラブルは常に人間に回すこと」といった具体的な制約だ。

こうした細かいプロンプトの衛生管理（prompt hygiene）と、すべての変更前後で eval（評価）を回す という大原則がある。

これこそが、本番環境でAIを運用するための最低条件となっている。

しんたろー：
プロンプトに「重要！」と書くのはついやりがちだ。
でも結局、計算などの論理的な部分はツールに任せるのが一番速い。
Claude Codeを使っていると、AIが自分でツールを叩いて解決してくれるから、この辺の設計思想の重要性を感じる。

開発者の作業時間を削るための心理学的アプローチと評価の自動化

AIエージェントを単なる「命令を聞く機械」として扱うのは古い。

これからの開発者は、認知心理学や社会心理学の知見をエージェント設計に取り入れる。

人間の思考パターンを分析する 9つの軸 を理解することで、AIへの指示の質は変わる。

1つ目の軸は 心理的距離（抽象と具体） だ。

概念から入るタイプか、具体的な事象から入るタイプかによって、情報の与え方を変える。

2つ目は 問題解決スタイル だ。

既存の枠内で修正を積み重ねるか、それとも別のアプローチに切り替えるか。

3つ目は 共感と体系化 だ。

他者の内的状態にどれだけ注意を払うかという視点だ。

4つ目は ポライトネス（丁寧さ） だ。

断定的な命令か、それとも提案ベースの対話か。

5つ目は 概念の結合 で、遠い領域同士をいかに接続するかだ。

6つ目は フレーム効果 で、情報を「利得」として捉えるか「損失」として捉えるかだ。

7つ目は 認知欲求 だ。

複雑な問題を考えること自体に喜びを感じるかどうかだ。

8つ目は 思考複雑性 で、複数の枠組みを統合する能力だ。

そして9つ目は 好奇心のタイプ だ。

これら9つの軸をベースにエージェントの役割を設計することで、AIの出力に 意図的な揺らぎ を持たせることができる。

この「揺らぎ」こそが、複雑なタスクをこなす鍵になる。

厳密な命令系統（階層構造）だけでは、AIは想定外の事態でフリーズする。

そこで、エージェントに 部活 のような役割を持たせる設計が注目されている。

たとえば、どんどん議論を広げる 発散役 と、それを最小案にまとめる 整理役 だ。

そして、議論を現実の制約に引き戻す 現実接続役 と、実装の可否を判断する 技術判断役 だ。

これらを組み合わせることで、AI同士が自律的に議論を整理し、人間が介入しやすい隙間が生まれる。

特に 整理役 の設計は重要だ。

「議論が広がりすぎたときに最小案を出す」という 重心 を与える。

これにより、会話の流れが自然になり、人間が納得感を持って運用できるようになる。

そして、この設計が正しいかどうかを判断するのが eval（評価） だ。

最新の知見では、PR（プルリクエスト）のレビューを 複数のAIモデルで相互チェック させる運用が推奨されている。

AIに任せきりにするのではなく、AI自身にクロスチェックを行わせる。

ハルシネーション対策としても、「もう一度チェックして」と繰り返させるのは効果がある。

最終的には人間がレビューするにしても、AIによる事前のスクリーニングがあるだけで、人間の負担は 半分以下 になる。

最新モデルは、旧世代のモデルに比べて「結果的に速い」。

推論スピードそのものが上がっていなくても、修正指示の回数が減るため、トータルの作業時間は短縮されるのだ。

しんたろー：
AIに性格を持たせるのは一見遊びに見えるが、実は実用的だ。
役割がハッキリしていると、どこでAIが迷っているのかがすぐ分かる。
ThreadPost開発でも、この「役割分担」の考え方を取り入れてから、デバッグの迷子が減った。

開発者が今すぐ着手すべき実務へのアクションアイテム

結論として、自前のevalセット構築にリソースを割く。

モデルが新しくなるたびに「なんとなく賢くなった」と喜ぶのは卒業する。

自分のプロジェクトにおいて、何が「正解」で何が「失敗」なのかを数値化する。

まず、過去の失敗事例を 10件から20件 抽出する。

それを「理想の回答」とセットにしてリスト化する。

新しいプロンプトを試したり、モデルを入れ替えたりしたときに、そのリストを自動で回して 合格率 を出すスクリプトを書く。

これがあるだけで、デプロイ時の不安は一掃される。

次に、マルチエージェントのルーティングを実装する。

すべての処理を最高性能のモデルに任せるのは、コストの無駄だ。

初期のアイデア出しや情報の探索には、レスポンスが速く安価なモデルを使う。

そして、最終的なコード生成や複雑な論理判断が必要な場面でだけ、高性能なモデルを呼び出す。

このルーティングを自分で行うのが面倒なら、Claude Code のようなツールを標準で使う。

Claude Codeの内部実装は、まさにこの「探索は安いモデル、本丸は強いモデル」というルーティングを体現している。

ツールを使う側から、その設計思想を盗む側に回る。

また、AIとの対話において 人間が介入するタイミング を意図的に設計する。

完全に無人で動くシステムを目指すのではなく、AIが「ここから先は自信がない」とか「判断材料が足りない」と声を上げてくれる仕組みを作る。

特定のイベントをトリガーにエージェントを動かし、実行中に人間が割り込んで軌道修正できるワークフローが理想的だ。

最後に、ドッグフーディングの徹底だ。

AIエージェントを作るなら、自分自身がそのエージェントの最初のユーザーであり続ける。

開発者が毎日AIを使ってコードを書き、AIにレビューをさせ、AIにドキュメントを書かせる。

その過程で感じる「使いにくさ」や「違和感」こそが、次世代のエージェント設計のヒントになる。

「もう自分ではほとんどコードを書かない」と言い切れるレベルまで、AIとの協働を深める。

しんたろー：
結局、一番のボトルネックは「人間によるレビュー」だ。
ここをどう減らすか、あるいはどう効率化するか。
AIにAIをチェックさせる仕組みは、1人開発者こそ導入すべき武器だ。

AIエージェント開発に関するよくある質問

Q1: 自前のevalセットはどうやって作ればいい？

手元の顧客データや過去の成功事例から「正解」となる入出力ペアを抽出する。

まずは10〜20件程度の「失敗したケース」と「理想の回答」をリスト化し、モデルの出力がそれに合致するかを自動判定するスクリプトを書く。

これが蓄積されると、プロンプト変更やモデル入れ替え時のリスクが下がる。

evalは一度作って終わりではなく、開発が進むにつれて成長させていく資産だ。

Q2: エージェントに「部活」のような役割を持たせるメリットは？

厳密な命令系統だけだと、AIは指示待ちになりやすく、想定外の事態でフリーズする。

役割に「どの局面で前に出るか」という傾向を持たせることで、会話に揺らぎが生まれ、AI同士が自律的に議論を整理したり、人間が介入しやすい隙間ができたりする。

結果として、複雑なタスクでも人間が納得感を持って運用できるようになる。

遊び心に見えて、実は「AIの自律性」と「人間の管理可能性」を両立させる設計手法だ。

Q3: AIエージェントのコストを抑えるには？

すべてのステップで最高性能のモデルを使うのは非効率だ。

タスクを「探索・発散」と「決定・実行」に分け、前者は軽量モデル、後者は高性能モデルに任せるルーティングを実装する。

また、AI自身に自動コードレビューやクロスチェックを行わせることで、人間がレビューする回数を減らすことが、トータルの開発コスト削減に直結する。

トークン単価を気にするよりも、人間の時間単価をいかに削るかという視点が重要だ。

結局、設計の妙が勝敗を分ける

AI開発の主戦場は、モデルの性能から 設計と評価の仕組み へと移った。

最新モデルを使いこなすには、単なるプロンプトエンジニアリングを超えた、心理学的な役割設計と厳密な eval が欠かせない。

開発者がやるべきことは、AIに丸投げすることではなく、AIが最高の結果を出せる 土俵 を作ることだ。

この設計思想を取り入れることで、作業時間は目に見えて減る。

チームでも、まずは小さな evalセット を作るところから始めてみてはどうだろうか。

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