そのClaude Codeの使い方損しているかも？

Claude Codeを使い始めてから、こんな感覚を抱いたことはないでしょうか。
気づけば、同じような修正を何度もお願いしている。
高性能なモデルを選んでいるのに、なぜか仕事が早く終わらない。
安いモデルで節約しているつもりなのに結局一日が終わってしまう。

Opus、Sonnet、Haiku、Fableモデルが増えるほど、どれを選べばいいのか迷う時間まで増えていく。
便利な道具のはずなのに、使うほどに何かを損しているようなはっきりしないモヤモヤ。
そう感じている方は、決して少なくないはずです。

本当のコストは「モデルの単価」ではなかった

以前の私は、「この一回のやり取りにいくらかかるか」という一回単位の視点でしかコストを見ていませんでした。
しかし実際に仕事の総量を左右していたのは、モデルの単価ではなく、「その仕事を終えるまでに何往復したか」という回数のほうだったのです。
安いモデルでも五往復すれば高くつく。
高性能なモデルでも条件をまとめて伝えて一回で終われば、結果的に安く済むことがある。
逆に、判断の余地がない単純作業に高性能モデルを使えば、「じっくり考える」という長所が、そのまま余計な待ち時間に変わってしまう。

中でも一番もったいなかったのが、指示のズレによる全面的なやり直しです。
あるレポート出力機能を「見やすい形式でまとめて」とだけ頼んだところ、きれいに整えられたHTML形式のレポートが返ってきました。
私が欲しかったのは、メールにそのまま貼り付けられるシンプルなテキストでした。
気づいたときには見た目の微調整まで何往復も重ねたあとで、そのやり取りのほとんどが無駄になりました。
「見やすい」という言葉が思い浮かべさせるものは、人によってまったく違うのだと痛感しました。
つまり、損の正体はモデル選びの失敗というより、「やり直し」と「性能の持て余し」でした。
そして振り返ってみると、そのやり直しの多くは、モデルの性能不足ではなく、指示を出す側である私自身の準備不足から生まれていたのです。

無駄を減らすために私が続けていること

こうした失敗を重ねる中で、少しずつ自分なりの使い方の型ができてきました。
作業に取りかかる前に、目的、読んでほしい関連ファイル、完了条件、テスト条件の四つを簡単にでも整理してから指示を出すようにしています。
たとえば検索機能なら、「精度を上げて」ではなく「部分一致で、全角半角の表記ゆれも吸収できたら完了」と伝える。
フォームなら、正常な入力だけでなく、空欄のまま送信した場合や規定より長い文字数の場合も確認してほしいと最初から含めておく。
不具合については、いきなり修正を頼まず、まず原因を調べてもらう。
この習慣だけで、一つの作業を終えるまでのやり取りは体感で三割から四割ほど減りました。

モデルに役割を割り振る

今の私の基本は、設計はOpus、実装はSonnet、数時間規模の大がかりな調査はFable、判断の余地がない定型作業はHaikuという役割分担です。
迷ったときは、まずSonnetから始めます。
「考える」工程と「作る」工程を分けるだけで、高性能モデルの待ち時間を本当に必要な場面に絞れるようになったのです。
振り返ってみるとSonnetで始めた作業のうちOpusへの切り替えが必要になったのは、体感で二割から三割程度でした。

モデルを上げる前にEffortを見直す

結果に満足できないとき、以前の私はすぐに上位モデルへ切り替えていました。
しかし管理の不具合調査で、SonnetのままEffortを高めに設定し直したところ、表面的な原因の奥にある根本原因まで調べてくれたことがあります。
足りなかったのはモデルの能力ではなく、考える時間でした。
今は、まずEffortを上げ、それでも改善しなければモデルを切り替えるという順番を守っています。
切り替えの目安は「言い換えを含めて二度伝えても望む方向に進まなかったとき」です。
安いモデルを選ぶことも高性能なモデルを選ぶことも、それ自体が悪いわけではありませんでした。
損をしていたのは、仕事全体を見ずに目先の一回だけで判断し、準備と確認を省いていたからです。
その場の気分でモデルを選ぶのではなく、自分なりの小さなルールを決めておく。
それだけで、迷う時間もやり直しも確実に減っていきます。
今どこかで無駄を感じているなら、その気づきは決して無駄ではありません。
一つの工夫から始めれば十分です。
この記事でお伝えしたのは、私が書いた『そのClaude Codeの使い方損しているかも？モデルを使い分けて時間・料金・失敗を減らす方法』のほんの入り口にすぎません。

書籍では、

• 「1回の料金」ではなく「仕事を終えるまで」でコストを考える視点

• 「見やすく」「使いやすく」といった言葉が指示のズレを生む理由と具体例を一つ添える工夫

• 表面的な修正が新しい不具合を呼ぶ「修正の連鎖」と原因調査の進め方

• 共通コンポーネントや「ついでに」の変更で、意図しない範囲まで変わってしまうのを防ぐ方法

• 依頼を大きくしすぎず、細かくしすぎないための仕事の区切り方

• low・medium・highのEffortとモデルを組み合わせる考え方

• Opus・Sonnet・Fable・Haikuを一つの仕事の中で使い分ける役割分担の型

• 失敗しにくい使い方を「仕組み」として作るための7つのルール

このような内容を私自身が実際にたどってきた順番に沿って、失敗談とともに一つずつまとめています。
なお本書は、Kindle Unlimitedで無料読み放題の対象になっています。
気になった方は、ぜひ手に取ってみてください。

そのClaude Codeの使い方損しているかも？モデルを使い分けて時間・料金・失敗を減らす方法

まさひろのKindle書籍で他の書籍を探す

※本記事にはAmazonアソシエイトのリンクが含まれています。
Amazonのアソシエイトとして、まさひろは適格販売により収入を得ています。