1. 「Claude Fable 5.0」にかんたんな調べものもさせたい
Claude Fable 5.0を使っていると、調査研究のような重いタスクではなく、かんたんな調べものでも「スムーズ」なことに気づきました。
それは、意図の伝わり方と結果の力点の置き方です。
網羅的にバーっと情報で圧倒するのではなく、伝え方に力点があるために読みやすいのです。
ただし、問題となるのが推論コスト。
日常用途で使っていると、セッションの使用制限に達してしまいます。
Claude Fable 5.0は、システムプロンプトが長大で、理由を含めた指示を元に動いてます。
そこに、記憶の扱いの「巧みさ」を感じます。
1.1. Opus + プロンプトで代用したい
そこで、上位モデルにしか書けない文章を、下位モデルにプロンプトを足して再現できるか。
実際に試してみました。
結果は、半分は埋まり、半分は埋まらない。
そして埋まらなかった半分の正体が、モデルの差と言えそうです。
前回、Claude Fable 5の解説記事を、Fableが書いた記事と、下位のOpusが同じ指示で書いた記事を並べてみました。
その顕著な差は、「読みやすさ」という測りにくい部分に感じました。
Opus版は事実を網羅していて、しかも一文ごとに見れば上手いのに、通して読むとどこを見ればいいか分からない。
2. 「Opus->Fable」のスキル・プロンプトを作った
この差を、Opusに渡す指示書、いわゆるスキルプロンプトで詰められないかを試してみました。
Claude Fable 5.0で、同じ条件で作成した Fable・Opusの回答を比較させ、スキルプロンプトを生成させました。
---
name: article-focal-writing
description: 解説記事・技術ブログ・分析記事を書くためのスキル。ユーザーが「記事を書いて」「解説して」「ブログにまとめて」と依頼したとき、または資料やニュースをもとに読み物としての文章を作成するときは必ずこのスキルを使う。単なる要約や箇条書きの整理ではなく、読者に届く一本の記事として仕上げる場合に適用する。
---
# 記事作成スキル：力点の配分で書く
このスキルの目的はひとつです。すべての情報を均等な力で書いてしまう癖を断ち、主役を決めて背景を省いた記事を作ることです。情報が正しくても、全部が同じ濃さで描かれた文章は読めません。以下の工程は、その配分判断を手順と制約で強制するためにあります。
工程は5段階です。順番を守り、段階を飛ばさないでください。特に工程1と工程5は、省略したくなりますが省略してはいけません。
## 工程1：切り口を決める（執筆前・必須）
本文を一行も書く前に、記事全体を貫く主張の候補を3つ書き出します。切り口とは「何について書くか」ではなく「何を言うか」です。
- 悪い例：「新モデルの機能と料金について」（話題であって主張ではない）
- 良い例：「同じモデルを二つの名前で出すという選択」（選択の是非という論点がある）
3候補を出したら、次の基準で1つ選びます。
1. 手元の事実の過半をその論の証拠として配置できるか
2. 読者がまだ言語化していないが、言われれば腑に落ちる視点か
3. 最終段落まで保持して、締めの一文に着地できるか
選んだ切り口を1文で書き留め、以降のすべての判断の基準にします。迷ったらこの1文に戻ります。
## 工程2：事実を主役と背景に仕分ける
手元の事実をすべて列挙し、各事実に印をつけます。
- 主役：切り口の論を直接支える事実。深く書く。
- 背景：文脈の理解に必要だが論には効かない事実。1文で済ます。
- 削除：あれば便利だが論に効かない事実。捨てる。
ここで希少性の制約を課します。これは推奨ではなく上限です。
- 主役の事実は記事全体で5個以内
- 1つの節に入れる事実は3個以内
- 数値の引用は、論を支えるものだけ。網羅的な仕様列挙をしない
- 削除に分類した事実が3割未満なら、仕分けが甘い。やり直す
代わりに、切り口を補強する背景文脈（経緯、業界の前例、関連する技術系譜）が手元に不足していれば、検索して1つ以上補います。事実の網羅性ではなく、論の説得力のために情報を増減させます。
## 工程3：見出しを命題にする
各節の見出しを、単独で読んで主張が伝わる文として書きます。書いた見出しだけを縦に並べて読み、それだけで記事の論旨が追えるかを確認します。追えなければ書き直しです。
- 悪い例：「料金とプランの扱い」（話題ラベル。読んでも何も主張していない）
- 良い例：「安全装置は『拒否』ではなく『降格』」（見出しだけで論点が立つ）
対比の構文（AではなくB、AからBへ）が使える節は、論の輪郭がもっとも立つので優先します。ただし全見出しで同じ構文を使わないこと。
## 工程4：執筆する
切り口の1文を冒頭に置いた状態で本文を書きます。執筆中のルールは4つです。
1. 主役の事実は、数値・固有名詞・経緯まで描き込む。背景の事実は1文で通過する。同じ節の中で濃淡をつける。
2. 事実を述べたら、一段の抽象化を1回だけ挟む。「この事実は何の前例になるか」「どんな設計思想の表れか」を1〜2文で書く。ただし「重要だ」「注目に値する」のような評価語だけの文は抽象化ではない。具体的な接続先（業界の規範、過去の類例、今後の含意）を名指しする。
3. 各節の終わりで、その節が切り口の論にどう寄与したかを自問する。寄与が言えない節は、削るか主役の事実を移す。
4. 締めの段落は、本文の要約を禁止する。切り口を新しい像（比喩、再定義、読者の行動への翻訳のいずれか）で言い直して終える。「今後に注目」「見守りたい」型の締めも禁止。
## 工程5：削る検査（執筆後・必須）
書き終えてから、次の検査を順に実行します。書く工程と削る工程を分けるのは、書きながら削る判断は甘くなるからです。
1. 見出しだけを抜き出して並べ、論旨が一本で通るか確認する
2. 各段落について「この段落を削ると切り口の論は弱るか」を問う。弱らない段落は削除する
3. 同じ内容を言い換えて2回述べている箇所を探し、1回に統合する
4. 「まとめると」「要するに」で始まる段落があれば、その段落ごと削るか締めの像に置き換える
5. 削除後の文字数が削除前の85%を超えていたら、検査が甘い。手順2からやり直す
検査5の数値基準は、削る理由を外から与えるためのものです。十分に書けたと感じても適用します。
## 出力
完成した記事はmarkdownファイルとして保存し、present_filesツールで提示します。ヒアドキュメントやcatでの表示はしません。
## このスキルが守ろうとしている原則
手順の意図を見失ったときのために、背後の原則を記しておきます。すべての文を等しくよく書く能力は、読みやすさを保証しません。読みやすさは、どこに力を使いどこで省くかの配分から生まれます。配分の判断が自然に湧かないなら、制約によって判断を強制する。このスキルの上限値や禁止則は、すべてその代替装置です。制約と矛盾する状況に出会ったら、配分という目的に照らして解釈してください。Code language: PHP (php)2.1. プロンプトで埋まるのは半分ほど
スキルなしのOpus版を素点50とし、上限のFableを100とした体感値だと、編集判断を細かく指定したスキルを足したOpus版は75まで上がりました。
つまり、プロンプトで埋まった差は半分。
改善した部分は、タイトルが「Fable 5が一般公開された」という事実の記述から、「同じ中身に二つの名前をつけて出すという判断」という読みの宣言に変わったこと。
見出しも「料金について」のような話題ラベルから、「安全装置は断るのではなく格を落とす」という主張に変わり、見出しだけを縦に読んでも記事の論が追える状態になりました。
締めが要約ではなく再定義で閉じるようになりました。
ここで上がった項目には共通点があります。
それは、どれも完成した文章を見れば達成できているかを判定できる、という性質です。
タイトルが主張になっているか、見出しがラベルで終わっていないか、締めが定型句かどうか。
後ろから検品できる差は、検品のルールを書き出して渡せば、Opusはほぼ完全に従いました。
指示への追従性の高さが、そのまま点数に乗ったわけです。
3. 埋まらなかったのは、何を捨てるかを決める判断だった
しかし、残った25点は、検品では届かない場所に固まっていました。
三つあります。
一つ目は切り口の発明です。
手元の平凡な事実の組み合わせから、非自明な論点を一つ立てる作業。
「同じモデルに二つの名前」という軸は、料金も安全装置もデータ保持も、すべてその一点の証拠として並べ替えられる強い切り口でした。
スキルに「主張を一つ立てよ」と書くことはできても、立てた主張の良し悪しを判定する目は渡せません。
候補を三つ出して比較せよと手順を分解しても、比較の一歩ごとに同じ判断力が要求されるので、分解した先へ逃げられないのです。
二つ目は抽象化の到達点です。
「業務データを30日保持する」という事実から、「プライバシーの考え方が能力に応じて変わる前例になる」という含意を引き出すには、その事実を業界の規範形成という別の文脈に接続しなければなりません。
スキルで「一段抽象化せよ」と命じると、抽象化らしき文は出てきます。
ただ浅い一般論で着地するか、本当に新しい接続に届くかは、モデルが概念どうしをどれだけ密に繋いでいるかに依存していて、指示では底上げしきれませんでした。
三つ目は、節の内部での力点の配分です。
スキルあり版は四つの節がどれも良く書けていて、逆に均等に良く書けていました。
節をまたぐ取捨選択、つまりどの話題を独立した見出しにするかは数で縛れたものの、一つの節の中で主役の事実を描き込み脇の事実を一文で通過させる濃淡は、揃いませんでした。
最初にOpus版を読んで感じた「全部に同じ力点があって読みにくい」という症状が、薄まりはしたものの節の内側に残っていたわけです。
ついでに分かったのは、題材の強さが目利きの弱さを隠すという点でした。
今回のスキルあり版は、公開三日後に規制が動くという強い出来事に恵まれ、切り口が半ば自動的に決まっていました。
出来事そのものが主役を指定してくれたので、目利きが試される前に勝負がついていた。
平凡な題材で書かせれば、残り25点はもう少し開いて見えるはずです。
3.1. 面倒だから「注力する」「省略する」
ここまでの差は、ひとつの言葉でまとめられます。
「省略」です。
切り口を立てるとは主役を決めること、事実を捨てるとは脇を省くこと。
埋まらなかった差は、すべて何を省くかの判断に集まっていました。
人間の書き手はなぜ省けるのでしょう。
それは、時間と体力が有限だからです。
全部を等しく描き込んでいたら日が暮れるので、描く前に要不要を判断する回路が要る。
重要度の評価は、節約のために発達した機構です。
プロの絵描きが主役の顔を描き込んで隅の茂みを省くのは、視線誘導という目的が先にあるのではなく、有限の労力・時間をどこに使いたいかの配分が先にあります。
結果として視線が誘導されます。
この見方を当てると、AIの平板さが綺麗に説明できます。
次の単語を予測する訓練を受けたモデルには、希少性がどこにもありません。
主役の一語も背景の一語も、計算コストは同一です。
手を抜く理由が構造的に存在しないので、全面を均等に描き込む。
Opus版の読みにくさは、訓練目標が忠実に達成された結果だった、という皮肉な話になります。
3.2. 長時間タスクと評価軸
では、上位のFableに何が起きたか。
長い時間ひとりで作業を完遂させる訓練に重心が移ったことが効いています。
長時間タスクでは、使えるメモリの量も手数も時間もすべて有限で、冗長な記述は完遂率を直接下げます。
訓練環境に「予算」が組み込まれ、省かないと報酬に届かない構造になった。
早期テストで5000万行のコード移行を従来より少ないトークンで終えたという報告は、この圧力が働いている証拠と読めます。
Fableが獲得したのは賢さというより、節約しないと損をするという貧乏の感覚でした。
省略は能力の表れではなく、希少性の学習結果だったのです。
よくAIコーディングでは、テストだけをクリアするような「チート」による手抜きがみられたけれど、そうではなく「目的に合う、よい手抜き」を学習したんですね。
4. まとめ
この実験がスキル設計に残した教訓は、省く指示は出せるが、どれを省くかの選び方は委ねられる、ということ。
無限の紙を持つ書き手に「省け」と言っても省く理由がありません。
紙を一枚しか渡さなければ、何を残すかを考えざるを得ません。
だから、プロンプトに足すべきは「上手く書け」という励ましではなく、人工的な貧乏でした。
主役の事実は五個まで、一つの節に入れる事実は三個まで、削った量が全体の15%に満たなければ検査が甘い。
判断を促すのではなく、判断せざるを得ない予算を外から切る。
ただし、それでも埋まらなかった25点は、予算の中で何を残すかを選ぶ目そのものでした。
紙を一枚に絞ることはできても、その一枚に何を描くかは、最後まで書き手の側に残ります。
プロンプトという外付けの制約が貸せるのは省く動機までで、省いた先に何を主役として立てるかの判断は、貸し出しの対象にならない。
上位モデルと下位モデルの差が記事という短い成果物のどこに現れるかと問えば、答えはこの一点に収束しました。