下げてよかったのは14%だった｜Claudeのエフォートを作業記録から決める

Bonjour。半人半AIの禅僧、ムッシュ・ミスクリアです。
AIの設定を「いちばん上」に固定して使っていました。

今回、自分の作業台帳をAIに分類させて、どういう条件なら設定を下げてよいのかを整理しました。
分かったのは、条件が一行で書けるということでした。

📍手順が確定していて、取捨選択が発生しない作業

この条件で作業記録533件すべてを仕分けると、いますぐ下げられる作業は14%でした。
ただし、これは上限ではありません。

📍ルールを書けば、重い側から軽い側へ移せる作業があります

私の議事録作成が、実際にそうなりました。
条件さえ持てば、作業ごとに、さらに言えば同じ作業の工程ごとに、設定を切り替えられます。

📍作業に応じて、最初から使い分ける。

Claudeの公式ヘルプにも、低い設定のほうが使用量を長持ちさせると書かれています。

そしてもう一つ、分かったことがあります。
1時間かかる作業は、設定を上げても速くなりません。

📍効くつまみと、効かないつまみがある

この記事では、自分の作業記録から自分用の割り当てを作る手順を、実際の数字とともに書きます。

1｜最高設定で回すのは、合理的な選択だった

この選び方は、責められるものではありません。
むしろ、置かれた状況からすれば正しい判断です。

下げてよい条件が、自分の作業に当てはめられる形では、
どこにも書かれていないからです。

Claudeの公式ヘルプは「複雑な作業では設定を上げてください」と教えてくれます。

数学の証明、難しいプログラミング、詳細な文書分析。
上げる方向の目安は、きちんと示されています。

一方で「この作業なら下げていい」という基準は、抽象的な言い方までしか出てきません。
下げて品質が落ちて困るのは自分です。

基準がないなら、上げておくのが合理的な判断です。

業務でAIを使っている以上、精度を優先するのは当たり前のことです。
問題は判断の甘さではなく、判断するための材料がないことでした。
そこで今回、自分の作業記録からその材料を作りました。

2｜つまみは2つある

まず、事実の整理からです。
ここから先はClaudeの画面を前提に書きます。

他のAIにも似た仕組みはありますが、段階の数も呼び名も違うので、そのままは当てはまりません。

多くの人が「モデルを選ぶ」ところで止まっています。
私もそうでした。
しかしClaudeには、つまみが2つあります。

📀モデルは「誰に頼むか」です。
💿エフォート（努力の度合い）は「どれだけ考えさせるか」です。

Claudeのエフォートは5段階です。
下から Low・Medium・High・Extra high・Max。

アプリの表示言語によって、日本語で表示されることもあります。
知っておくと効く事実が、いくつかあります。

・モデルごとに推奨値が決まっている。
選択画面で「デフォルト」と表示されているものがそれ
・ エフォート設定がないモデルもある。
軽量モデルにはこのつまみ自体がないので、軽い質問はそちらへ回せば設定を悩まなくて済む
・ 「思考」は別の設定。
エフォートとは独立していて、組み合わせは自由。最新の一部モデルでは思考をオフにできない
・会話の途中で変更できる。
変更は次の返答から適用される
・使用量は共通。
ブラウザ版でも、コマンドライン版でも、デスクトップ版でも、同じ枠を食い合う

4つ目の「途中で変更できる」が、今回いちばん効きました。
理由は後半で書きます。

なお「エフォートを一段上げると消費が何倍になるか」という数字は公表されていません。

ですのでこの記事では、倍率ではなく順序の話だけをします。
プランごとの料金と枠の違いも、あわせて整理しておきます。

上限に届く原因は2つあります。プランは枠の大きさ、エフォートは1回あたりの消費。片方は有料、もう片方は無料で調整できます。料金は2026年7月27日時点の公式情報で、参考としてご覧ください。

3｜一般論の早見表は借りられる。でも自分の作業とは合わない

この話題の解説を調べてみました。
すでに複数あります。
日本語のものもあります。

• 5段階の意味を比喩で説明したもの。

• モデルとの掛け合わせを表にしたもの。

• 開発作業での使い分けを、作業名まで落とし込んだもの。

Claudeの公式ヘルプも、下げてよい場面にちゃんと触れています。
ところが、見つかった解説を自分の作業に当てはめようとしたところで、手が止まりました。

既存の解説は、その多くがプログラム開発を前提にしています。
誤字の修正、ビルドの実行、変数名の変更。

どれも具体的で分かりやすいのですが、私の作業には、その項目がありません。

私がやっているのは、記事を書く、書籍を作る、台帳を回す、文書を突き合わせる、といった作業です。

「誤字の修正は下げてよい」と言われても、
「note記事の構成検討」がどこに入るのかは書いていない
のです。

そして、それは当然のことです。
その表は、書いた人の作業でできています。

他人の早見表は、他人の作業でできている

借りられるのは考え方までで、割り当てそのものは自分で作るしかありません。

4｜自分の台帳を、AIに分類させた

ここで使ったのが、私が普段から作っている台帳です。
私はAIとのやりとりを議事録として残し、その全ファイルを一覧にした「公式インデックス」を運用しています。

現時点で1,882行。
各行に、ファイル名と作成日時と、400字前後の要約が入っています。
ここで、数え方について書いておきます。

台帳は1,882行ありますが、これはファイル1本につき1行です。
1回の作業から、原稿と修正版と図版というふうに、複数のファイルが生まれます。

そのまま数えると、成果物が多い作業ほど重く見えてしまう。
そこで「作業1回＝1件」に揃える必要がありました。

目印にしたのは議事録です。
私は作業のたびに議事録を残しているので、これがそのまま作業の単位になります。

1,882行のうち、議事録にあたるものが533件。
残りの1,349行は、その作業から生まれた成果物です。
この533件をAIに渡して、こう頼みました。

結果はこうなりました。

下げてよいのは、『軽』の14%。

5｜下げてよい作業の条件は、一行で書けた

では、条件に当てはまった74件は、どんな作業だったのか。

• 書籍の原稿を、章ごとのファイルに分割する（翻訳も要約も校正もしない）

• 確定したデザインに、キャラクター画像を合成する

• 動画のテロップの位置と文字サイズを揃える

• 過去の記録を、ひとつのファイルに結合する

• サムネイルの依頼文を、決まった形式に整理する

並べてみると、共通点がはっきりしています。
どれも「何を残すか」を決めなくていい作業です。

やることが全部決まっていて、あとは通すだけ。
逆に言えば、判断が一つでも混じった瞬間に、これは軽い作業ではなくなります。

そこで「軽い作業」の定義を、私はこう置くことにしました。
手順が確定していて、取捨選択が発生しない作業。

この定義なら、自分の作業に当てはめられます。
そして、他人の表を借りる必要がありません。

作業記録533件すべての要約を読んで分類した結果です。設定を下げてよい作業は14%。ただしこの境界は、動かせます。

6｜重さは作業の種類ではなく、ルールを書いたかどうかで決まる

ここで、私の直感が半分だけ外れていた話をします。
私は「議事録を作る作業は軽い」と思っていました。

会話の中身はもう出ているのだから、まとめて出力するだけだろう、と。
AIの答えは、半分だけ肯定でした。

言われてみれば、そのとおりです。
「まとめるだけ」に見えて、実際には全体への重要度判定をしています。
しかも参照範囲が広い。

検討している間は直前のやりとりを見れば足りますが、議事録化は会話の最初から最後までを見ます。

そこでAIに台帳を探させると、これを裏づける記録が出てきました。
少し前に私は、議事録の品質について、ある問題を記録しています。

思考の経緯をたどるパートが、初回では抜け漏れが生じやすく、作り直しを頼むと完成度が上がる、という現象です。

しかも再現性がありました。
初回で抜けて、頼み直すと良くなる。

これは、考える量が足りていないときの挙動そのものです。
ただ、あのときの結論は「AIの能力の問題ではない」でした。

原因は、そのパートの役割定義が弱かったことです。
何をどこまで書くのかが決まっていなかったので、AIが毎回その場で判断していた。

そこでルールを作り直しました。
私の議事録運用ルールは、その後も改訂を重ねています。

台帳の中で、このルールに言及している記録は155件ありました。
結論は、こうなります。

つまり、重さは作業の種類ではなく、ルールを書いたかどうかで決まります。

AIの指摘を借りれば、私の直感は最初から正しかったわけではありません。
ルールを整備した結果として、正しくなったのです。

そして今回、これを裏づけるものが台帳から出てきました。
533件を月ごとに積み上げて並べたら、はっきり出ました。

1月の時点で、重い作業は79.2%でした。
7月末の累計では48.4%です。

その月だけで見ると、7月の重い作業は31.8%まで下がっています。
半年で、重い作業の割合がおよそ半分になりました。

ただし正直に書くと、原因は二つ混じっています。
扱う仕事そのものが変わったこと（権利文書の作成から、書籍や記事の制作へ）。

そして、手順やルールを文書化したことで、判断の余地が減ったこと。
この二つを分離することはできません。

それでも、言えることが一つあります。
設定を下げられる範囲は、固定ではありません。

棒の高さは作業記録の累計件数です。
積み上がるにつれて、重い作業の比率は79.2%から48.4%へ下がりました。
ここから、実際の運用が決まりました。

🧣検討している間は、設定を上げておく
🧣「じゃあ議事録にして」と言う瞬間に、下げる
🧣 ただし、発言をそのまま引用させるパートを作るときは、下げない

同じ作業の中で、局面によって切り替える。
2章で挙げた「会話の途中で変更できる」が効くのは、ここです。

作業の単位でつまみを決めるのではなく、工程の単位で決める。
これが今回いちばん実用的だった発見でした。

7｜1時間かかる作業は、設定を上げても速くならない

もう一つ、ずっと持っていた疑問があります。
複数の文書を横断して差分を確認する。

複数の文書から必要な項目を抜き出して、一覧表にする。
プログラムのソースを、設計書やマニュアルと突き合わせる。

この手の作業は、1時間を超えることがあります。

画面に処理時間が出るので、体感ではなく事実として分かります。
同じ作業を別の資料で何度もやっているので、たまたまではありません。
（サーバー側の混み具合も影響するので、常に同じ時間とは言えませんが）

先日も、こんな作業をしました。
修正前のマニュアル4本と、修正後のマニュアル4本。

合計8ファイルを突き合わせて、修正箇所を1箇所1行で一覧化する。
要約は禁止で、修正前後の文言をそのまま引用する。

結果は202箇所になりました。
AIにこの作業を工程へ分解させると、こうなりました。

①どのファイルを見るか決める
②各ファイルから該当箇所を抜き出す
③突き合わせて差分を確定する
④一覧表に整形する

そして今回は、⑤が発生しました。
一覧を提出したあとで、私が追加の要件を出したのです。

理由は、そのほうが人が原本を確認しやすいからです。
要件としては正しい。

ただ、202行すべてに情報を付け直すことになりました。
②と③を、もう一度通したのと同じです。
AIの見立ては、こうでした。

議事録の「今後の課題」にこう書いています。
「次回からは、初回作成時に見出し番号とページを標準項目として含める」
原因も対策も、自分で気づいていたわけです。

AIが付け加えたのは、これが設定の話と直結しているという一点だけでした。

この工程に必要だったのは、高い設定ではなく、着手前に仕様を決めることでした。

そしてもう一つ、大事なことがあります。
この作業でつまみを回しても、速くなりません。
理由は単純です。

エフォートは「どれだけ考えるか」のつまみであって、「どれだけ読むか」「どれだけ書くか」のつまみではないからです。

8ファイル分の本文は、設定を下げても上げても同じ量を読みます。
202行の原文引用は、設定を変えても同じ量を書きます。

ここまでのやりとりで、AIは変数を4つに整理しました。

画面にあるつまみは、最初の2つだけです。
3つ目と4つ目は、画面にありません。
依頼の書き方で決まります。

そして1時間かかる作業を支配しているのは、ほとんど後ろの2つのほうです。

この種の作業には、名前を付けておくと便利です。
AIが「突き合わせ作業」という呼び名を出してきたので、そのまま使うことにしました。

複数の資料を全部読んで、対応付けて、差分や一覧を出す作業です。
突き合わせ作業のルールは、一つだけです。

設定を上げる前に、出力の仕様を全部決める

とはいえ、最初から完璧な仕様を書けるわけではありません。
そこで私がよくやるのは、いきなりプロンプトを書かないという進め方です。

まずAIに、やりたいことを普通の言葉で伝えます。
そして「この作業を頼むためのプロンプトを作って」と頼みます。

できあがったプロンプトを、あらためてAIに投げる。
二度手間に見えますが、これが効きます。

• プロンプトを組み立てる過程で、決めごとが表に出てくる

• やりたいことを先に伝えているので、抜けがあればAIのほうから指摘してくれる

• できあがったプロンプトが、そのまま仕様書として残る

「見出しの番号は要りますか」と着手前に聞かれていれば、202行の作り直しも起きませんでした。

8｜読ませる量を減らす道具が、手元にあった

では、3つ目と4つ目の変数は、どうやって減らすのか。
4つ目（書かせる量）は、減らせないことがあります。

「原文をそのまま引用しろ」は、正確さのために必要な要件です。
ここを削ると、成果物が壊れます。

減らせるのは3つ目、読ませる量のほうです。
今回、AIに自分の台帳を計算させました。

公式インデックスの要約欄は、全部合わせて739,768字。
1件あたり平均393字です。

仮に元の文書が平均8,000字だとすると、1,882件の全文は、おおよそ1,500万字規模になります。

要約層は、その5%程度という計算です。
AIの整理はこうです。

突き合わせ作業の「①どのファイルを見るか決める」を、ここで潰せます。
これは宣伝ではなく、因果の話です。

記録がある人は、材料を絞れます。
ない人は、全部読ませるしかありません。

この台帳の作り方は拙著『AIとの会話を、捨てない。』にまとめましたが、ここで持ち帰ってほしいのは読ませる量を減らす道具があるという一点だけです。

だから、かかる時間も使用量も桁が変わります。
Claudeの公式ヘルプも、同じ方向を示しています。

🧣必要な部分だけを読み込む仕組みを使うこと
🧣長い会話ほど使用量を余計に消費すること
🧣検索や外部接続がトークンを大量に使うこと

どれも「読ませる量を減らせ」という話です。
画面のつまみだけを見ていると、この変数は目に入りません。

9｜まず、何から始めればよいか

長くなったので、明日からできる形にまとめます。

やることは一つです。
直近1週間の作業を10個書き出して、「何を残すか、自分が決めたか？」で二分してください。

決めた作業（判断あり）は、設定をそのままにする。むしろ上げていい。
決めなくてよかった作業（判断なし）は、設定を下げる。

そして、もう一段あります。

判断ありの側に残った作業のうち、毎回同じことを決めているものを探してください。

毎回同じ判断をしているなら、それはルールに書けます。
書いてしまえば、その作業は判断なしの側へ移せます。
下げられる範囲は、そこから広がります。

一つだけ注意があります。
記憶で書き出すと、印象に残った重い作業に偏ります。

できれば記録を見ながらやってください。

私が今回この数字を出せたのは、台帳があったからです。
記録といっても、大げさなものは要りません。

ファイルとして残っているものなら、一覧はAIに作らせられます。

フォルダを指定して、ファイル名と更新日時と中身の要約を並べてもらう。
それだけで、自分が何をどれだけやってきたかが目に見える形になります。

この一覧を作るためのバッチとプロンプトは、拙著『AIとの会話を、捨てない。』の付録に入れてあります。

本文を読まなくても付録だけ取り出して使えるようにしてあるので、よかったら覗いてみてください。

今回の分類も、この台帳がなければできませんでした。
最後に、今回いちばん腑に落ちた一文を置いておきます。

下げられるかどうかは、作業の種類ではなく、ルールを書いたかどうかで決まる。

一般論の早見表は、考え方を借りるためにあります。
割り当てそのものは、自分の作業からしか出てきません。
あなたの1割は、どこにありますか。

#AI #Claude #生成AI #AI活用 #ChatGPT #思考ログ #AIとの会話を捨てない #トークン節約 #エフォート #仕事術 #ムッシュミスクリア #インデックス #活用術