Claude Code の使用：労力を費やす

最新のClaudeモデルの最大の魅力の一つは、Claude Codeのプロンプトキャッシュを破ることなく「エフォート」に反応する点ですが、この点についてユーザーから多くの質問が寄せられています。「エフォート」とは一体何なのか、どのエフォートレベルをいつ使うべきなのか？そもそもなぜエフォートが必要なのでしょうか？

この疑問に答えるため、評価結果を徹底的に分析し、通常の業務における労力について独自に検証を行うことにしました。

大まかに言えば、努力を惜しまないことが、Claudeによる検証やエッジケーステストの実施範囲や、独自の判断をどの程度反映させるかを調整する上で非常に有効な方法であることがわかりました。ハードウェア、コードレビュー、セキュリティなど、検証やエッジケーステストが特に有用な分野では、より多くの努力を注ぐことで、より良い結果が得られました。

通常のソフトウェア開発では、モデルにインタビューを受けさせ、その後、手間をかけずに実装を行い、モデルが構築したものを確認し、さらに手間をかけて検証を行う、というサイクルを繰り返しています。

「努力」とは何か？

大まかに言えば、「effort」は、そのタスクにモデルにどれだけの計算リソースを割くべきかという目安をモデルに与えます。これは、タスクの難易度をモデル化することと多少関係があります。

こう考えてみてください。もし誰かが「12時間ぶっ通しでこれをやってほしい」と頼んできたとしたら、あなたは「ただそれをやって、一生懸命頑張れと言っているだけだ」と解釈するかもしれません。一方、同じ仕事を「1時間でやってほしい」と頼まれたら、その依頼に応える最高の成果物を提出しようと努め、そこからさらに改善を重ねていくことを期待するでしょう。

あるいは、そのタスクには少なくとも3時間かかると反論し、実際に3時間かけて仕上げるという手もあります。

「労力」についても同様に考えるべきです。Claudeは常に合理的な範囲でタスクを処理しようとしますが、労力を高く設定すると、Claudeが判断や検証のために、より自主的な行動をとるようになります。

努力曲線

Fable 5.1およびOpus5.5の負荷曲線は、これまでで最高の結果を示しています。各レベルにおいて、ベンチマークスコアと消費トークン数が増加しています。

Terminal-Bench 3.0

図A Terminal-Bench 3.0。すべてのモデルで同じ70のタスクが実行された（4つのGPUタスクは除外されている）。Opus 5.5は約3週間後に実行され、応答は128kトークンに制限され、GitHubやPyPIへのアクセスは許可されなかった。Opus 5の最大値は、effort-120の実行結果である。

しかし、これは実際にはどういうことなのでしょうか？これを評価するために、私はさまざまな難易度のタスクをいくつか試してみて、ベンチマークを綿密に分析しました。

努力を込めて築く

モデルの仕組みを理解する最良の方法は、実験を行うことです。Opus 5.5 を使用して、モデルがどのような処理を行うのかを理解するために、いくつかの異なる労力レベルで同じタスクを実行してみました。実際には多種多様な作業で試しましたが、ここではいくつかの単純な例を用いて説明します。

仕様が不十分なビルドタスク

Claudeに「個人用のフィットネス・ワークアウト追跡アプリを作成してほしい」と依頼した場合、その「労力」の程度によってアプリの完成度が劇的に変わるだけでなく、Claudeが開発の過程でより多くの選択肢を提示することにもつながります。労力が低い場合、フィットネスアプリは単なるログとシンプルなグラフに過ぎません。労力が高くなるほど、アプリはより複雑になり、詳細な機能が追加されます。労力を最大にすると、ヒートマップが表示されます。

もし、反復作業の土台となるシンプルなものが欲しければ、最小限の労力で済みます。最大限の労力を費やすのは、Claudeの最高のワンショットを再現したい場合でしょう。

要件が簡素な設計課題

すでにかなり具体的に定義されているタスクがあるものの、Claudeを使って少し試してみたい場合はどうすればよいでしょうか？例として、の /config メニューを再設計するよう依頼してみました。どのパスでも、サブメニューの活用や検索機能の改善といった、ほぼ同じアイデアが提案されました。

わずかな手間（1分ほど）で、アイデアは伝わるものの、Claude Codeにはあまり似ていないインタラクティブなスケッチができあがりました。

全力を尽くした結果（28分かかりましたが）、Claude Codeに非常によく似たモックアップと、さまざまなフローに関する一連の操作手順を作成することができました。

もし私の目標が反復作業を行いフィードバックを与えることなら、手抜きをした方がはるかに早くその目標に到達できるでしょう。しかし、全力を尽くせば、最初からより洗練された成果物が得られます。この特定のタスクに関しては、Claudeのビジョンを理解するために、手抜きをする方がよいと思います。

高度に詳細なビルドタスク

もし「Claude」に詳細な情報をたくさん与えたらどうなるでしょうか？私は「Claude」に、このフィットネスアプリについて詳しくインタビューしてもらうよう依頼し、その仕様を、さまざまな労力レベルを持つ異なるモデルに実装させました。

この仕様を前提にすると、各モデルの挙動がはるかに似通っていることがわかりました。見た目はかなり似ており、実装も類似しているものの、細部が異なる設計案が得られました。最大限の努力を払った結果、Claude では、いくつかの細部を簡略化するために多少の時間がかかりました。

要点

通常のソフトウェア開発、特に新機能の開発においては、必要な労力の程度は、私がどの程度開発プロセスに関与したいかによって大きく左右されます。労力を抑えれば、Claude が素早く初期案を提示してくれますが、労力を増やせばより多くの作業が進む反面、Claude が私の代わりに多くの仮定を立てることになります。

私が機能開発で活用している、特に成果の上がるループは以下の通りです：

Claudeに仕様を指定して、私が見落としている詳細についてインタビューするよう依頼してください
手間をかけずに実装する
要点が正しく理解できているか確認し、必要に応じて手間をかけずに修正を繰り返す
多大な労力を要する作業について、検証とテストを行う

困難な課題において、努力のレベルが成果に与える影響

しかし、これらは明らかに単純な例であり、Claudeなら問題なく処理できます。では、Claudeがタスクを完了できるか、できないかという違いがある場合はどうでしょうか？

こうした難解な問題を見つけるには、ベンチマークを参照する必要があるため、私は気に入っているベンチマークの一つ、コミュニティ主導のベンチマークである「Terminal-Bench 3.0」を詳しく調べてみました。

Terminal-Bench 3.0の問題は、大まかにセキュリティ、ハードウェア、機械学習、科学、ソフトウェア、運用、メディアといったカテゴリーに分類できます。すべての課題はこちらでご覧いただけます：https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0。これらはコミュニティから寄せられたものなので、誰でも投稿できます。

これらのモデルが直面している問題の性質を把握するには、一読の価値があります。私は、こうした課題の多くが持つ規模や野心に驚かされました。それらは、私が普段扱う平均的な課題よりもはるかに複雑なのです。

例えば、その業務には次のようなものがありました：

ハードウェア (retro-console-soc): 小型FPGAに収まり、テストROMをレンダリングできる8ビットゲーム機をVerilogで構築する。
科学 (takens-embedding-lean）：Lean 4 を用いて、タケンスの埋め込み定理を形式的に証明する。
ML (mp-checkpoint-consolidation): ミックス・オブ・エキスパートのチェックポイントの16個のシャードを、リファレンスのロジットを再現できる1つのファイルにマージする。
業務（intrastat-meldung）：企業の月末におけるEU貿易統計の提出業務を、最初から最後まで一貫して遂行する。
メディア (layout-config-recreation): ポスター画像を編集可能なレイアウトファイルとして再構築します。

エッジケースが多い場合、より高い努力レベルが役立ちます

『Terminal-Bench』3.0の結果を読んで私が得た主な教訓は、隠れたエッジケースが多いタスクにおいては、より多くの労力をかけることが最善であるということでした。

わかりやすい例としては html-js-filter、Terminal-Bench 3.0のタスクで、ページへのJavaScriptの不正な埋め込みをあらゆる手段で排除するHTMLサニタイザーを求めているものです。Fable 5.1は、低（low）レベルで1/5だった評価が、xhighレベルで5/5に上昇しました。¹

「手間をかけない」という典型的な試行には、約2分かかります。これらの試行では、それぞれおおよそ1回のパスでフィルタを作成し、手書きのページ1ページに対してそのフィルタをテストしました。

高負荷の実行は約33分で終了します。私が追跡した実行では、最初のドラフトを対抗的にレビューした後、インストール済みのパーサーのソースコードを読んでバグを確認し、入力と同じ出力が得られるまで多くのクリーンなテストケースを実行し、標準的なXSSテストスイートを実行し、最後にランダムドキュメントファザーを作成しました。

HTMLサニタイザーのようにエッジケースの多いケースでは、この余分な手間をかける価値は十分にあります。パフォーマンスの最適化やセキュリティレビューなど、本番環境での要件が厳しい複雑なタスクにおいても、徹底性を高めるためにより多くのリソースを割くことは理にかなっています。

しかし、すべてのタスクにこれほどの労力を費やす必要はありません。

以下の図は、さまざまなモデルや開発工数レベルにおける、Terminal-Bench 3.0のすべての結果と、その失敗原因を示しています。全体として、開発工数を増やすことで、エッジケースの漏れによる失敗（紫色のブロック）は減少する傾向にありますが、モデルのアプローチ自体が間違っている場合（青色のブロック）の失敗は解消されません。

努力が役立つ問題点

Terminal-Bench 3.0 上でこれらのモデルを評価した結果、私にとって最も興味深い発見の一つは、他の領域よりも特に注力することで大きな成果が得られる問題領域がいくつかあったという点でした。その内訳は、次の図に示されています：

これを説明するために、『Terminal-Bench 3.0』からさまざまな分野の問題をいくつか選びました。これらは、『Opus 5.5』が「低労力」では失敗したものの、「高労力」では成功した問題です。その主な理由は、エッジケースをテストし、考慮に入れていたためです：

mvcc-lsm-compaction：Terminal-Bench 3.0 のタスクで、コンパクションを中断させることなく、クラッシュレポートに基づいてストレージエンジンのバグの修正を求めるものです。Opus 5.5 は、低（low）で 0/5 だった評価が、xhigh で 4/5 になりました。

実行回数が少ない場合（1回の試行につき約1分）、Claudeはビルドやリプロデューサーの実行前にコードを編集していましたが、その新しいテストで元のバグが検出されるかどうかを確認していませんでした。

xhigh（約11分）の時点で、Claudeが最初にクラッシュを再現し、コンパクト化が決して行われないリファレンスに対してランダム化されたテストを作成し、そのテストが中途半端な修正に対して失敗することを確認しました。

cli-2ph-simplex：Pythonで記述されたCLIベースの線形計画法ソルバーを求める、Terminal-Bench 3.0の課題です。Opus 5.5は、低評価時の0/5から高評価時の5/5へと評価が上がりました。

試行回数が少なかったため、1パスでソルバーを作成し、いくつかの小規模な問題で検証した後、約1万トークンの時点で中止しました。最後のメッセージで、Claudeは、大規模な問題では処理が遅くなる可能性があると警告していましたが、実際に検証は行っていませんでした。

試行回数が多かった時期、Claudeは、ランダムな問題に対して自社のソルバーと別のブルートフォース型ソルバーを比較テストし、その後、より大規模な問題の実行時間を計測して、実行時間が著しく長くなったりクラッシュしたりするケースを特定し、探索アルゴリズムを改良しました。

gsea-proteomics：Terminal-Bench 3.0のタスクで、プロテオミクスデータに対して遺伝子セットエンリッチメント解析（GSEA）を行い、8つの治療法のどれが標的組織に類似しているかを特定するものです。Opus 5.5の評価は、低レベルでは0/5でしたが、高レベルでは4/5になりました。

Claudeは、手間をかけずに、理にかなったと思われる方法でデータを準備し、その方法で分析を実行し、結果を報告しました。

高校時代、Claudeはデータの前処理について2つの方法を試し、有意な処置のリストが変わったことに気づき、その理由を詳しく調べた上で、正しい方法を選択しました。

もしユーザーが関与していたなら、Claudeは問題の設定方法についてユーザーに確認していたかもしれませんが、ユーザーが関与していない場合は、手間のかかる方法の方が良い結果をもたらします。

Claude Code で、さまざまな負荷レベルをいつ使用すべきか

どのレベルの努力をいつ使うべきかについて、私の経験則は次の通りです：

「低」：ブレインストーミングやスケッチ、簡単な変更など、その場ですぐに反応が得られ、流れに乗った状態で進めたい場合
Medium：日常的なソフトウェアエンジニアリング業務の大部分、例えば新機能の実装など。
「高」：検証が重要である作業や、エッジケースが存在する作業の場合。例：既存のコードベースにおけるバグの修正など。
マックス：Claudeに、アプリのエンドツーエンドでの構築や検証、重要なソフトウェアのセキュリティ脆弱性の発見といった難しい問題を解決するために、完全に自律的に動作させたいときです。

Opus 5.5 および Fable 5.1 では、タスクに応じて、あるいは会話の途中でさえも、 /effort Claude Codeのこの機能を活用し、これがあなたの直感と一致するかどうか教えてください。

¹ 数値に関する注記：これらの数値は、Fable 5.1において本番環境の安全対策機能を無効にした状態で、タスクごとに5回ずつ実行した社内テストの結果に基づいています。Claude製品では、Fable 5.1の安全対策機能により、一部のセキュリティリクエストがOpusに委譲されます。また、セキュリティタスクはインターネットに接続できない状態で実行されたため、ここでのタスクごとの実行回数は、公開リーダーボードやリリース記事の数値とは一致しません。実例は個々の実行結果に基づくもので、その一部は中程度の難易度設定で実行されたものです。