Claude Fable 5.2は指示を文字通り守る。5.1の時の注意書きと設定を見直す方法

出典: まさおAIじっくり解説ch「【公式ガイド】『Claude Fable 5.2』で変更になった9つの特徴を解説！Effortの重要性が高まってます」

Claude Fable 5.2 に替えたとき、effort（AIがどれだけ考えるかの段階）はどこに設定していますか？

まさおさんがいちばん大事だと挙げたのが、この effort です。その前に、5.2 の性格をこう言い切っています。

動画では（0:42〜）

まず結論からいきますと、5.2っていうのは、え、書かれた指示を文字通り守るそんなモデルになっているので、ま、ちょっとエフォートの部分であったりね、どうしていいか分からないよみたいなのも、ま、出てきたりするのかなと、え、思っていたりします。

書いたとおりに動くモデル。だから、書いていない所の扱いが、前より効いてきます。

API の既定は high で、まさおさんのスライドには「effort は high から始め、5.1 の設定は持ち越さない」とまとめられています。最難関の長時間作業なら xhigh か max、普段使いは medium、コンパクトに狙うなら low。low は大量処理や、速いサブエージェント（本体のAIが仕事を分けて頼む別のAI）に向くそうで、公式の言葉では「伸びの大半は high まで」です。

まさおさんは Artificial Analysis のグラフも開いて、effort ごとにかかり方が全然違うことを確かめていました。

動画では（3:04〜）

ミディアムとハイの間に、あの、壁があるという風に個人的にはね、感じてるんですけど。

そのうえで、普段は medium か high を中心に使う方針だと話します。

選ぶ前に知っておきたい癖も、スライドに並んでいました。低い effort ほど、途中で止まりやすい。high 以上だと、挨拶にも考えてから答える。それから、effort を変えても返答の長さはほとんど変わりません。長さを変えたい時は、プロンプト（AIへの指示の文章）のほうで変えます。

おもしろいのは、まさおさんの検証です。API で各5回、問いは1つという条件で、「考えずに答えて」の1行がある時とない時を比べています。5.1 ではこの1行で考えるかどうかが変わったのに、5.2 の high は1行ありでも5回中5回考えました。medium は、1行なしで4回、1行ありで0回。公式のガイドには「medium 以上で止まらなかった」とあり、まさおさんの問いでは medium は止まった。ここは公式とまさおさんの結果が食い違っています。

挨拶と「17×23」の計算を各10回聞いた検証では、5.1 は0回、5.2 の high は20回中20回考え、medium は20回中5回（挨拶だけ）、low は0回でした。直し方は、「熟考せず直接答えて」の行を消して、そのターンの effort を下げること、と話します。Claude Code（ターミナルで動くAIの道具）の対応も含めた発表そのものは、Claude Fable 5.2の発表と、Claude Codeの対応を扱ったAIニュースの記事にまとめています。

で、ここからは私の話です。5.2 ではなく、別の新しいモデルが出た日のこと。私はAIに頼んで、使っているモデルと effort の設定を全部点検してもらいました。2026年10月1日の朝までに終えた点検です。

結果は、完璧ではありませんでした。設定の抜けが10件。たとえば Claude の Sonnet 5.5 は、effort を設定していないと公式の既定の high で動きます。そこで medium を明示しました。

書いていない設定は、無いのではなく、既定のまま動いているんです。あなたの設定でも effort が書かれていない所があれば、そこは今も既定で動いています。

5.1 の設定は持ち越さず、測り直す。その手前で、測る前に、書いてあるかを確かめる。

長い作業を頼むと、まだ作業が残っているのに、AIがターンを終えてしまうことがあります。公式のガイドでは、特に low や medium の effort で起きやすいとされています。

終わり方にも型があって、残りの一覧を出して止まる時もあれば、「続けましょうか」と聞いてくる時もある。タイムアウトのような普通の障害で、そのまま止まることもあります。まさおさんは、対処をこう話します。

動画では（5:47〜）

ま、例えばなんですけれども、ま、頼まれてる作業が残ってるうちは止まらないでくださいとね、え、ちょっと変えてみたりだとかポイントとしてあります。

作業が残っているうちは止まらない、の一文。

公式のガイドでは、これが Finishing work（作業をやり切る）の見出しの文面でした。肝は、障害の種類を分けて伝えることです。普通の障害は、原因を調べて乗り越える。触るなと書かれたファイルや、与えていない権限、安全上の制限には触らず、見つけたことを報告して、別の安全な方法を探す。止まる所を先に決める話は、AIに任せる仕事で、止まる所を先に決める話を扱った記事にも書きました。

公式のテストでは、途中で終わるセッションが約半分になり、出力トークンは約30%増えました。確認を求める回数は減っても、危険な操作や元に戻せない操作の確認は残ります。

ここで大事なのが、返し方です。「続けて」と一言返すより、してほしいことを具体的に書くほうが効くんです！ 承認のルールも、対象の操作を名指します。「この会話の外の人へのメッセージ送信」と広く書いたら、同僚や他チームへの日常的な依頼の約半分を控えた、と公式のガイドにあります。5.1 のガイドは「ユーザーは見ていない」と伝える向きでしたが、5.2 では障害の種類を分けて伝える向きに変わりました。

実は私の環境でも、AIに任せた作業で、似たことがありました。2026年10月29日、AIは手順を説明しただけで「残りは無い」と判断して、完了の確認を出してきたんです。頼んだことが実際に済んだと確かめられるまでは、完了の確認を出させない。これは今、私の決まりに書いてあります。

動画の話と同じ向きで、作業が残っているのに終わろうとする話です。

私がAIに委ねたいのは、作業だけではありません。約束を覚えて、期限まで運んで、成果か本当に必要な判断だけを返す。その責任まで含めて渡したいんです。「続けましょうか？」と聞かれて、私が進み具合を思い出して催促した瞬間、管理のボールは私の手に戻ってきます。

だから、終わりの条件は、頼む前に書く。

請求メールを送る関数を足して、と頼む場面。

持ち主を書かないと、5.2 は send_welcome や send_reset の隣に send_invoice を足して、似た関数を並べます。持ち主を書くと、共通の処理が send_mail 1つにまとまる。近くで見つけたバグも、頼まれなくても直します。

動画では（6:44〜）

え、ま、コードの持ち主を、え、伝えてあげると、ま、つまりは、え、このコードはあなたのものですよみたいな形で、え、伝えてあげると

公式のガイドには、英語の1文が載っています。意味は「このコードはあなたのもの。何のためのものか、どう作るかはあなたが決め、この先も作り続ける」。公式のテストでは、この1文で、重複の統合が1割未満から約半数になりました。

この数字を受けて、まさおさんはこう続けます。

動画では（7:38〜）

ま、そのエージェントプロンプトとして伝えてあげるみたいなことをすると、より自立的に、え、細部までやってくれるっていうところが強まるのかなっていうのね、え、この共有から個人的に思いましたけれども。

ただ、いいことばかりではありません。出力は約1.5倍に増え、頼んでいない変更も増えます。中身は新しいテストやドキュメントが多いそうで、既存機能の挙動を変えたのは6〜10回に1回。要約は小さな変更をよく省くので、diff（変更の差分）を見るように、と公式は書いています。

「No drive-by refactors, renames or cleanups」と書いても、約3分の1で統合した結果も公式のテストにあります。5.1 のガイドは、頼まれていない修正を抑える文面でした。

抑える書き方から、持ち主を言う書き方へ。

私の判断軸では、委ねる時は一つのボールを、人でもAIでも仕組みでも、誰か一人が全部持ってやり切ります。複数人の共同責任にはしない。所有者は一人です。だから「このコードはあなたのもの」には、賛成です！

といっても、渡すのは作業と、最後までやる責任まで。公式のガイドには、コードを持っているのが人のほうで、できるだけ小さく変えたい時は、持ち主を渡す一文そのものを入れないでおく、と書かれています。だから私の判断では、頼んだ範囲より広く動いてほしくない時は、範囲を書き足して抑えるのではなく、渡すか渡さないかを先に決める。それが私の線の引き方です。

持ち主は一人。渡す範囲を決めてから渡す。

長いターンの途中で、画面に何も出てこない時間。

AIが止まったのか、考えているのか、見ている側には分かりません。手が止まっているように見えて、不安になる場面です。

動画では（8:24〜）

これもあの、言われていることなんですけれども、途中にその作業途中に黙って見えてしまうっていう部分があったりするのですが、

まさおさんは、その原因は表示の設定かもしれない、と話します。作業の合間の経過報告は、thinking ブロック（AIの考えの途中の報告が入る場所）に入ります。既定の "omitted" では、その中身が空のまま。画面には text しか映らないので、黙って見えるわけです。

"updates"（beta）にすると、各報告の短い要約が届きます。"summarized" なら、報告と要約された推論まで届く。最初のツール呼び出しの前に毎回ひと言発言させるプロンプトを足す手もあります。まさおさん自身はループで放置することが多く、特別なことはしていないけれど試してみるつもりだ、と話していました。

続いてサブエージェント（本体のAIが仕事を分けて頼む別のAI）の量の話です。公式のガイドでは、その量はハーネス（AIの動きを周りで支える仕組み。指示・メモ・道具の置き方など）の書き方で決まります。短い作業で、起動の道具が最小限なら、ほとんど呼びません。委譲を促すプロンプトがある製品では、すぐに任せます。そして xhigh や max では、5.1 になかった動きが出る。自分の成果を、サブエージェントにレビューさせるんです！

動画では（9:50〜）

ま、僕個人的にはね、え、結構な頻度でコンテキストフレッシュのサブエージェントにレビューしてもらってみたいなことを、え、ま、あの、初めにね、プロンプトに入れてたりだとか、ま、スキルに入れてたりだとか、え、してたので、ま、普通にありがたいなと思うんですけども。

対処として公式のガイドが書くのは、まず「委譲せよ」の行を見直すこと。それでも呼びすぎるなら、起動の道具の説明文にコストを先に書きます。説明文に入れるのは、サブエージェントがセッションのコストに何を足すのか。委譲が割に合う時と、割に合わない時。そして、起動したサブエージェントへの指示の出し方です。公式のテストでは、委譲の回数が約3分の1減り、頼んだ仕事の成功率は同じでした。最近のモデルは1つのセッションで複数の関心ごとをある程度扱えるので、うまくない切り分け方はしない。これはまさおさんの持論です。

私は2026年4月17日、AIに頼んで、自分のエージェントの設定を棚卸ししてもらいました。モデルを opus に指定したままの設定が、161件。サブエージェントは、モデルを書かないと親の会話と同じモデルで動きます。記録には「Inherits from main conversation」とありました。そこで、文章を書くサブエージェントと、機械的に実行するサブエージェントの合わせて21体を、sonnet に書き換えました。

書いていない一行が、そのまま重さになっていたんです。サブエージェントがどれだけ動き、どのモデルで動くかは、書き方で決まる。まさおさんの話と、同じ構造でした。

あなたの設定でも、サブエージェントの定義にモデル名が書いてあるかを開いて見てください。使っている環境によっては、モデルを書いていないサブエージェントは、親の会話と同じモデルで動くことがあります。私の環境では、そうでした。サブエージェントは、呼ぶ前に量とモデルを書く。

昔のメモ12件のうち、たった1件の「再試行するな」。

公式のテストでは、その1件だけで動きが変わっていました。ツールが busy を返した時に、5.2 はその古いメモを今日も守って、再試行しない。再試行した割合は、ほぼ毎回から約4割まで落ちていました。注意書きがたまる場所は、メモリ、作業メモ、指示ファイル、agent 同士のメッセージです。

動画では（11:14〜）

こういうね、注意書きが溜まってしまう場所、ま、こういうのをね、貯めないようにしましょうみたいなのを、え、共有してくれています。

直し方として、まさおさんは公式のテストの結果を順に紹介します。古いメモを消すと、約4割がほぼ毎回に戻りました。

やってよいことを名指す手もあります。「再試行は、承認なしでやってよい」と書くと、再試行はほぼゼロから約半数に増えた。

ルールそのものを書き直すと、もっと大きく動きます。「〜は、先に承認を得てからする」の形にした時は、約1割から約9割でした。消すだけが正解ではないんです。

古い指示の見直しも続きます。移行で見直す指示は7つあって、スライドには「良かれと思って入れた物が裏目に出る」例が並んでいました。

たとえば、プロンプトの中に書いた大きなトークンの予算。外したら、コストが下がって性能は同じだったそうです。スライドによると、「その回答は完了済み」と書いた場合は、AIが過去の自分の誤りを指摘することが大きく減ったそうです。「1文1指示・20語以内」と書けば、文章がぶつ切りになる。どれも、守らせたくて書いた一行が、文字どおりに効きすぎた形に見えるんですよね。

残りの、委譲を促す指示、過去のターンを編集するコード、「考える量を減らせ」の指示、たまったルールやノートやメモリも、見直す対象に入っています。

2026年10月19日、私は公開のXにこう書いていました。「AIを作るほど、どこに何があるか分からなくなっていませんか？」「覚えてほしいことを、毎回伝え直していませんか？」。そして「原因は、AIの性能ではなく「置き場所とルール」が決まっていないことです。」と続けています。

私の説明書とメモの置き場の話は、AIエージェントの記憶は足し続けるより、何を残すかを人が決めて減らす、とまさおさんが話した動画を紹介した記事に詳しく書いたので、ここでは繰り返しません。

私の読みでは、足すこと自体より、置き場所と見直す機会を決めないまま足し続けることのほうが問題になる。5.2 では、それが動きとして表に出てくるのだと思います。

古い注意書きは、書いた時の気持ちではなく、今の目的から選び直す。残すのか、書き直すのか、消すのか。今のワクワクから古いボールを選び直す、という私の判断軸と同じ向きです。

AIの報告を読んで、結局何が起きたのか分からなかったことはありませんか？

まさおさんは、5.2 の出力のテキストは個人的にいい、と話します。報告は、作業の経過を見ていない人が読むもの。そこが出発点です。

動画では（12:56〜）

結局これね、報告っていうのは、ま、作業の経過をあの、読む人は見ていないわけなので、ま、これだけで分かるか報告がね、それだけで意味が通る必要があるんですけれども、

公式のガイドには、報告の文面の骨子が5点あります。賢いけれど文脈を持たない読者に向けて書くこと。要点を最初の数文に置くこと。作業中に自分で作った用語や略語を使わないこと。短い文で1文に1つの考えを書き、同じ物には同じ語を使うこと。つながる話は段落に、別々の項目は箇条書きにすること。

公式のテストでは、最終報告の密度が下がり、セミコロンが減りました。ワークフロー自動化の作業では、文も短くなっています。5.1 の時は密で飾った文体だったけれど、ここは良くなっている、というのがまさおさんの評価です。

私は2026年10月8日、AIの報告について決まりを1つ書きました。報告の中に、AIが作業中にだけ使う短い言葉が、説明なしで入っていたんです。「落ちた」「通った」「部品」「段」「枠」。読んでも、何が起きたのか分かりませんでした。

それで、報告は「何が・どこで・どうなったか」の普通の文で書く、と決めました。経過を見ていない人とは、報告を受け取る私のこと。動画の言う「経過を見ていない人」は、報告を受け取る側の私と、同じ立場だと読めます。

断られた時の見方も、報告を読む側の話の続きです。依頼が断られると、stop_reason（止まった理由）が "refusal" になります。stop_details.category（断った理由の種類）は5種類のどれか。cyber、bio、frontier_llm、reasoning_extraction、general_harms です。reasoning_extraction は、内部の推論を応答の本文に再現させる依頼のこと。対処は「推論を応答に書け」という指示を消し、推論は display: "summarized" の thinking ブロックで読むことです。

動画の最後では、5.1 から対処の向きが逆になった所がまとめられます。考える量は、1行で止めるのではなく、effort を下げる向きに。やり切らせ方は、「ユーザーは見ていない」と伝えるのではなく、障害を2種類に分けて伝える向きに。コードの変更は、抑えるのではなく、持ち主を言う向きに変わりました。

動画では（15:12〜）

ハーネス全体を見直す機会ね、一旦また見直してもいいんじゃないかなと個人的には思っております。

最後のスライドに書かれていたのは、足す前に消し、入れたら測る、の一行でした。

新しいモデルの日は、指示を足す日ではなく、足してきた物を見直す日にする。足す前に消し、入れたら測る。これが私の線引きです！

新しいモデルが出た日は、前の設定を持ち越さない。書いていない所が既定のまま動いていないかを、先に確かめます。

作業を渡す時は、終わりの条件を先に書く。誰が持ち主で、どこまで任せるのかも、そこに添えておきます。

そして、足す前に消し、入れたら測る。古い注意書きは、書いた日の気持ちではなく、今の目的から選び直すものです。

まさおさんは動画の最後を、これから Fable を使い込んで共有していく、という言葉で締めくくっていました。

あなたの設定で、前のモデルの日から書き換えていない一行は、どれですか？