AIの評価が一般論で丸いので、具体的な人物にとがった評価をさせるスキルを作った（discuss-with-adviser）

昨日、友人たちと話していて「それいいね」と言われたスキルがあるので紹介します。Claude Code の discuss-with-adviser というスキルです。

一言でいうと、AI の一般論的でフワフワした評価を、具体的な人物のとがった評価に変えるためのスキルです。

何が問題だったか

AI に相談すると、賛成でも反対でも、返ってくる内容が一般論的でフワフワと丸い。

「一長一短ですね」「ケースバイケースです」「メリットとデメリットの両方があります」。間違ってはいないのですが、これで判断が決まったことがありません。反対されたときも同じで、「〜の懸念があります」と一般的なリスクが並ぶだけ。私のこの計画の、どこが致命的なのかは教えてくれません。

丸くなる理由ははっきりしていて、誰の立場でもないからです。立場がないところに偏りは生まれず、偏りがないところに鋭さは生まれません。一般論は、全員に当てはまるように書かれているぶん、誰の役にも立たない。

だから欲しいのは「反対意見」ではありません。輪郭のはっきりした具体的な人物が、その人の立場から下す、とがった評価です。

discuss-with-adviser がやること

このスキルは、話題に対して具体的な相手役を1人立てて、主催役と議論させます。

• まず人物を確定する。 実在の専門家なら、その人が実際に何を主張してきたかを調べてから話させる。ここが本体です
• 実在の適任者がいなければ、そのコミュニティの発言傾向を合成した架空の専門家を立てる（架空の場合は冒頭で明記する）
• 話題が新しければ、議論の前に軽くネット調査して主張の裏を取る
• 合意で終わらせない。最低1回は本気で押し返す。これは目的ではなく、立場のある人物なら当然そうなる、という結果です
• 最後に「結論：〜」か「ここはあなたに委ねます＋判断軸」を必ず返す

「反論させる」スキルだと思われがちなのですが、順番が逆です。人物を立てるから、結果として反論が出る。反論だけを注文しても、返ってくるのは一般的なリスク一覧です。

呼び出しはこれだけです。

/discuss-with-adviser [話題] [相手と]

どちらも省略できます。省略すると直前の会話から話題を読み、相手は候補を出して承認を取ります。

実例：AI マンガの吹き出しが文字化けする

抽象論だと伝わらないので、昨日実際に使った例をそのまま出します。

私はエッセイマンガを Gemini（いわゆる Nano Banana）で生成するツールを作っています。ところが吹き出しの中の日本語がよく文字化けする。そこで、こういうワークフローを考えました。

1. Gemini で「絵＋空の吹き出し」を作る
2. PSD ファイルにする
3. その上に Python でテキストレイヤーとしてセリフを載せる
4. 最後に目視チェックして調整する

我ながら筋が良いと思っていました。で、こう投げました。

ネット調査をしてから /discuss-with-adviser nanobananaの達人（Redditの住人など）

相手は実在の適任者が見つからなかったので、Nano Banana 系を日常的に回している実践者たちの発言傾向を合成した架空キャラ「バナナピール」が立ちました。主催は執事役のホッジンズです。

このあと何が起きたか、先にマンガにしておきました。8コマで全部入っています。いろいろおかしい点がありますが、ご勘弁下さい。

1. 2コマ目の2つ目の吹き出しが空白（たぶんpsdファイルについて話している）
2. 3コマ目の話者が逆
3. 5コマ目の話者も逆

（マンガ自体も、この記事で話題にしている自作ツールで生成しています。吹き出しの日本語がいろいろおかしいですよね。だから後乗せを考えている、というのが本題です）

以下、実際のやりとりです。

最初は褒められる

🍌バナナピール: 最初に褒めておくと、方向はコミュニティの正解と一致してる。マンガ用のプロンプト集でも「完璧な文字が欲しいなら空吹き出しで出して後から入れろ」と書かれてるし、Nano Banana Pro でも小さい文字の崩れは公式コミュニティに苦情スレが立ってる。絵と組版を分けるのは、俺たちが1年かけて辿り着いた結論だ。

ここで終わっていたら、いつもの「賛成されて終わり」でした。

冷や水を浴びる

🧸ホッジンズ: よかった。じゃあ問題なしだね。

🍌バナナピール（間を置いて）: ……いや、2段目の「PSDにして」で計画が折れる。

ここからが本題でした。

🍌バナナピール: Python で PSD に編集可能なテキストレイヤーを作る手段が、事実上ない。psd-tools は公式ドキュメントで「レイヤーの追加・削除は非対応」「フォントレンダリング非対応」と明言してる。pytoshop は書けるけど、書けるのは numpy 配列＝ラスター画像レイヤーだけだ。つまりあんたが作れる PSD は「セリフが画像として焼かれたレイヤー」であって、Photoshop で開いてもテキストツールで打ち直せない。

これは知りませんでした。ワークフローの2段目が丸ごと成立しない。

押し返しが起きる

面白いのはここからで、主催役のホッジンズが相手に反論します。

🧸ホッジンズ: ちょっと待って。俺は「PSD をやめる」を推したい。欲しいのは「PSD」じゃなくて「目視して直せる状態」だろ？ 目的と手段がすり替わってる。

これに対してバナナピールが再反論する。

🍌バナナピール: 反論する。ラスター PSD でも十分すぎるぞ。吹き出しに bubble_01_セリフ冒頭 みたいなレイヤー名を付けておけば、位置ズレはドラッグで直る。文言を直したいときは元のテキストを直して再生成すればいい——絵は変わらないんだから。Web UI を自作するのは、動くまでに一番時間がかかる選択肢だ。「完璧より完了」だろ？

そしてホッジンズが折れます。

🧸ホッジンズ: ……返す言葉がないな。了解した、そこは譲る。

一人で考えていたら、この往復は絶対に発生しませんでした。 私はたぶん「PSD が無理なら Web UI を作るか」と考えて、丸2日溶かしていたと思います。

本当の地雷はもっと手前にあった

さらにもう1段ありました。

🍌バナナピール: 本当の地雷はまだ話してない。日本語の縦書き組版だ。Pillow に縦書き機能はない。自分で1文字ずつ置くことになる。そして日本語は、 - 「、」「。」はマス目の右上に寄せる - 「ー」「〜」「（）」「「」」は90°回転させる - 「ゃゅょっ」の小書きは位置が違う - 行送りは右→左 - 禁則処理（行頭に「、」が来ない）

これを全部書くと、AI 画像生成より工数が食う。ここが計画の本当のコストセンターだ。

私が「PSD が作れるか」を心配していた横で、実はその隣に、もっと大きくて地味な穴が空いていた。これも一人では見えていませんでした。

最後は順番の話になった

締めは主催役からの指摘でした。

🧸ホッジンズ: 最後に、俺から一番大事なことを言わせてくれ。順番が逆だ。 「絵を作ってからセリフを流し込む」と、吹き出しが小さすぎて入らない事故が必ず起きる。後乗せは「文字数を先に決められる」ことが前提で初めて安全になる。

結論として返ってきたのはこれです。

ワークフローは採用でいい。ただし2箇所を直す。 1. 「PSD にテキストレイヤー」は諦める（Python からは作れない）。ラスターレイヤー PSD ＋レイヤー名で運用し、真実は JSON に置く 2. セリフを先に確定し、文字数に合う吹き出しをプロンプトで指定する（後乗せの成否はここで決まる）

判断軸： 迷ったら「これは絵の問題か、組版の問題か」で切る。絵の問題はプロンプトで、組版の問題は Python で解く。両方を Gemini に任せた瞬間に文字化けが戻ってくる。

おまけ：締めがこうなった

このスキル、対話に「ユーモアを1箇所以上入れる」というルールが入っています。実装した当初は「そんなの守れるのか？」と思っていたのですが、この日はこう締めてきました。

🧸ホッジンズ（ふっと笑って）: バナナの皮に足元をすくわれるかと思ったが、いい相棒だったよ。……ああ、名前がそれだったな。

🍌バナナピール: 滑ったのはそっちのジョークだ。

自分で立てた架空キャラに自分の駄洒落を斬られて終わる、というのは初めての体験でした。

何が効いているのか

使ってみて分かったのは、効いているのは「賢い答え」ではなく構造だということです。

仕掛け	効果
具体的な人物を1人立てる	立場が決まると評価が偏る。偏るから鋭くなる。「一長一短ですね」が出てこなくなる
その人の中核主張を先に決める	「psd-tools はレイヤー追加が非対応だ」は、立場のない一般論からは絶対に出てこない。誰かの持論として初めて出る
最低1回は押し返させる	1回目の同意で止まらない。上の例では同意 → 否定 → 再反論、と3段進んだ
主催役も反論する	AI 同士が対立するので、こちらが反論役を演じなくてよい。疲れない
架空の専門家を許す	「適任者が見つからないので相談できません」で止まらない。ただし架空だと必ず明記させる
結論か判断軸を必ず返す	議論が発散したまま終わらない
ユーモアを1箇所以上入れさせる	計画を否定される話は普通に凹む。笑いが1個あるだけで最後まで読める

効いているのは上の2つです。「反対して」と頼むだけなら、返ってくるのは一般的なリスク一覧で、丸さは変わりません。誰が言うかが決まって初めて、評価に角が立ちます。

相談履歴が溜まる

呼んだ相手は advisers.yml という台帳に記録されます。名前・人物像・中核主張・話した話題が残るので、次に同じ相手を呼んだとき、人物像と主張がぶれません。

これは地味ですが本質的で、とがり方が毎回変わってしまうと、それは結局「その場の思いつき」で一般論と大差ないからです。台帳があると「前回そう言っていた人」として一貫した立場から評価が返ってきます。同じ人に何度も相談する価値が出るのはここです。

このファイルは個人の相談履歴そのものなので、公開版には同梱していません。無くても動きます。

注意点

万能ではありません。使ってみて感じた限界も書いておきます。

• 話題が広すぎると散る。 「今日の範囲」を1文に絞る仕掛けが入っていますが、それでも「アーキテクチャどうしよう」くらいだと薄くなります。判断が2択〜3択に絞れているときが一番効きます
• 実在の人物を相手にするときは要注意。 本人が実際に述べたことと、対話用の推測が混ざります。引用として扱わないでください
• 架空キャラの主張も裏取りが要る。 上の例では psd-tools のドキュメントなど一次情報に当たってから対話させています。それをしないと、もっともらしいだけの反論が出ます

スキルは公開しています

GitHub に置いてあります。

• SKILL.md: https://github.com/feel-physics/claude-code-marketplace/blob/main/plugins/advisory/skills/discuss-with-adviser/SKILL.md
• マーケットプレイス: https://github.com/feel-physics/claude-code-marketplace

Claude Code から入れる場合:

/plugin marketplace add https://github.com/feel-physics/claude-code-marketplace.git
/plugin install advisory@feel-physics

Codex CLI なら skills/ を ~/.agents/skills/ にコピーするだけでも動きます。中身はプロンプトだけで、依存も設定も要りません。

主催キャラの口調は *-tone スキルに切り出してあります（手元に無ければ通常の丁寧な口調にフォールバックします）。私は執事役を使っていますが、そこは好きに差し替えてください。

---

一番の収穫は、AI の答えが丸いのは能力の問題ではなく、立場が無いことの問題だと分かったことでした。賛成されても反対されても、一般論のままでは判断は動きません。動かすには、誰かに具体的になってもらう必要があります。

具体的になってもらうのに、わざわざスキルが要る。そこがちょっと面白いところだと思っています。

参考

• psd-tools ドキュメント（レイヤー追加・フォント描画は非対応）
• pytoshop
• Nano Banana Pro Manga Prompts（空吹き出し→後乗せが推奨されている）
• 小さい文字が崩れる問題（Gemini Apps Community）
• 源暎アンチック（マンガ向けフリーフォント）

Fable5と他のモデルの相対的比較・大学受験に例えた特性・上手な運用法

素のPerplexityの結果

モデル	陸上での向き不向き（ざっくり種目）	持久力（1turn長さ）	速さ	ツール使用	コスト相対値
Fable 5	マラソン〜ウルトラの戦略ランナー	100	40	80	100
Sonnet 4.6	1500m〜5000mの中距離総合選手	70	70	70	30
GPT‑5.5 Codex	400m〜1500mのスピード持久型	75	85	100	45
Codex 5.3‑Spark	100m〜200mスプリンター	35	100	60	25
Composer 2（Std/Fast平均）	200m〜800mトラック専門選手	60	90	75	10
ローカル Qwen Coder	3000m障害〜駅伝のローカル長距離	80	60	50	（マシン実費 30万円）
ローカル Gemma 4（31B想定）	1500m〜ハーフの汎用ローカル選手	65	55	45	（マシン実費 30万円）

Redditの評判を加味

モデル	陸上での主戦種目イメージ	1ターンの深さ / 長さ (Fable=100)	スピード (Spark=100)	ツール使用 (Codex5.5=100)	相対コスト (Fable=100, ローカルはマシン代)
Fable 5	マラソン〜ウルトラの戦略ランナー	100	60（どうでもいい会話は飛ばすので体感70くらい）	85（ツール少なめだが精度高い）	100（10/50ドルクラスで最上位帯）anthropic+2
Sonnet 4.6	1500m〜5000mの中距離総合選手	75	80	80（PC操作・web・functionなど十分）anthropic+1	30（3/15ドルでFableの約1/3）anthropic+2
GPT‑5.5 Codex	400m〜1500m＋障害物のスピード持久ランナー	85	90〜95（5.4比で2〜3倍速）mindstudio+1	100（ツール連携・並列CLIが最強クラス）developers.openai+3	50（5/30ドルでFableの約半額ゾーン）framia.converge+3
Codex 5.3‑Spark	100m・200mのスプリンター	40	100（超低レイテンシ設計）custom.typingmind+2	70（ツールは使えるが、深い連鎖には向かない）m-assets+1	20（約1.75/14ドルでかなり安い）custom.typingmind
Composer 2 (Cursor)	100m〜800mトラック専業のコーディング選手	70（コードタスクで深さ十分）cursor+2	90（Fast版はSpark寄りの体感速度）cursor+2	60（Cursor IDE内ツールに特化）cursor+2	10〜15（0.5/2.5ドルでFable比1/8〜1/10）cursor+3
ローカル Qwen Coder	5000m＋駅伝を走るローカル長距離ランナー	90（長コンテキスト・thinkingで深め）mindstudio+4	70〜80（VRAM次第、最適化すれば十分速い）reddit+1	75（ローカルツール連携は工夫次第）mindstudio+2	初期マシン代 30万を「Fable API月額換算で60〜80」くらいの感覚（長期利用なら割安）kdnuggets+2
ローカル Gemma 4	1500m〜10000mの万能ローカル選手	80（汎用＋コードでバランス良い）towardsdatascience+3	75〜85（量子化＋GGUF最適化でかなり速い）lmstudio+1	80（ツール使用機能あり、ローカルで拡張しやすい）lmstudio+2	初期マシン代 30万を「Fable API月額換算で60〜80」くらいの感覚（推論コスト0）kdnuggets+5

補足説明

結論からいうと、
ご指定の軸でざっくりスコアを付けると「長距離・深さ＝Fable／Qwen」「スピード＝Spark／Composer」「ツール＆実務＝Codex5.5」「総合力＆コスパ＝Sonnet／Gemma」というイメージになります。 reddit

PREPで、先に表を出してから簡単に補足します。

---

P（Point）比較表（陸上アナロジー＋相対スコア）

前提ルール：

• 向き不向き（陸上）：主戦種目（長距離／中距離／短距離／障害物／駅伝）。
• 相対的能力
  • 1ターンの「実質的な長さ／深さ」：Fable 5 を 100。
  • スピード：Codex 5.3‑Spark を 100。Fable が「どうでもいい会話を飛ばす」ぶん、体感速度は少し補正。
  • ツール使用：Codex 5.5 を 100（CLI・ブラウザ・DBなど総合的ツール能力）。
• 相対コスト
  • Fable 5 のAPIコスト感を 100 としてざっくり（入出力まとめ）。
  • 他クラウドは公式単価から比率を推定。
  • ローカルは「初期ハード代30万円＋運用」を、Fable 5＝100に対しての相対感覚としてざっくり。

---

R（Reason）スコアの読み方（ごく簡単に）

• 深さ / 長さ

  • Fable 5 とローカル Qwen Coder が「長距離・長タスク」に強い枠。
  • Sonnet・Gemma 4 は「日常の中距離タスクをほぼ全部こなす」枠。
  • Codex‑Sparkは「超短距離専業」。

• スピード

  • Spark が「一瞬で返ってくる」基準。
  • Codex5.5・Composer2 Fast がそれに近い体感。
  • Fable は深く考えるぶん遅いが、「どうでもいい会話を削る」ので同じ深さならそこまで体感差は大きくない。

• ツール使用

  • Codex5.5 が CLI・ブラウザ・DB・ファイル操作・並列ツール呼び出しで頭一つ抜けている。 developers.openai
  • Fable はツール回数が少ない代わりに、失敗を読んで自己修正する「慎重な使い方」が得意。 mindstudio
  • ローカル勢は、環境の作り込み次第で伸びる部分が大きい（Qwen/GemmaはClaude CodeやPi/OpenCodeと組み合わせる事例が増えている）。 towardsdatascience

• コスト

  • Fable 5 を 100とすると、
    • Sonnet ≒ 30
    • Codex5.5 ≒ 50
    • Spark ≒ 20
    • Composer2 ≒ 10〜15
      と、クラウド側は「Fable が一番高く、Composer2 が異常に安い」絵になります。 anthropic
  • ローカル Qwen / Gemma は「初期投資30万＋電気代」なので、長期的には「Fable を毎日ヘビーに使う」より安くなりうる一方、短期・ライトユースならクラウドの方が楽、というバランスです。 patloeber

---

E（Example）陸上チームとしての起用イメージ

ざっくり言えば：

• マラソン・駅伝のアンカー：Fable 5 or ローカル Qwen Coder
• 1500m〜5000mの日常レースの主力：Sonnet 4.6 or Gemma 4
• 400m〜1500m障害＋実務リレー：Codex5.5
• 100m〜200mの予選ラッシュ：Codex‑Spark / Composer 2
• 練習トラック（ローカル開発環境）：Gemma 4 / Qwen Coder

という感じで「種目ごとに誰を出すか」を決めると、MCPやルーティング設計もかなりクリアになると思います。 recruit.group

---

受験に例えると

結論からいうと、大学受験の例でざっくり言えば、

• Fable 5：東大・京大・早慶のトップ層。最難関の記述・思考問題と長期計画が得意。
• Codex 5.5（GPT‑5.5/Codex）：難関理系私大／東工大タイプの「理系・実技特化」。道具の使い方（ツール・コード）と演習量で押す。
• Sonnet 4.6：難関国公立・上位私大の「万能エース」。コスパ良く共通テスト〜二次試験をこなす。
• Codex 5.3‑Spark：共通テストや私大の「小問処理を高速連打する補助エース」。とにかく手数と速度が武器。

というイメージになります。 anthropic

---

R（Reason）各モデルの「受験スタイル」

1. Fable 5：東大・京大・早慶トップ層（最難関二次・総合問題に強い）

公式に近い特徴

• 「長期エージェント」「長期 reasoning」向きの最上位モデル。 anthropic
• FrontierBench や金融・ソフトウェアの難度高いベンチマークで最高水準。 vellum
• 100万トークン級の長文・複数文書・コードベースを横断して扱える。 eigent
• アダプティブ思考常時オンで、タスク難度に応じて思考量を変える。 japan-ai.co

受験のたとえ

• 共通テスト：
  • ほぼ無双だが、「パワーを出し過ぎなくても満点近く取れる」ので、わざわざここ専任にする必要は薄い。
• 知識問題：
  • 教科書〜発展参考書レベルまで幅広く押さえており、「なぜそうなるか」の背景説明まで得意。
• 私大の膨大な問題量：
  • 過去問研究や傾向分析、出題パターン抽出などのメタ分析が得意。
• 真価が出るのは：
  • 東大・京大の理系数学、難関大の融合問題、医学部の総合問題のような
    • 長く
    • 分野横断で
    • 方針立案＋検証が必要な問題群。

LLM的には：

• 大規模リファクタリング・長期リサーチ・複数システム横断の設計など、「二次試験最難関＋志望校対策計画」を同時にやるような場面が Fable 5 の本領です。 platform.claude

---

2. GPT‑5.5 / Codex 5.5：理系難関私大・東工大タイプ（実技・ツール利用の鬼）

ここは OpenAI 側なのでざっくり「GPT‑5.5（Codex 5.5）」としてまとめます。

公式・レビュー的な特徴

• GPT‑5.5 は「エージェントタスクに最適化されたモデル」であり、
  • ツール呼び出し精度
  • マルチステップ reasoning
  • コード生成・デバッグ
    に強いとされます。 mindstudio
• Codex では、ドキュメント・スプレッドシート・スライド生成など、「Office 系実務+コード」に特に強い。 openai
• 特に TypeScript・Python など実務的な言語＋ツールアクセスで高評価。 mindstudio

受験のたとえ

• 共通テスト：
  • パターン化された計算・情報処理・データ解釈系はかなり強い。
  • 一方で、「深い読解ベースの国語・小論文」のような素の言語芸は、Fable 5/Opus級と比べると目的外、という位置づけに近い。
• 知識問題：
  • 理科・情報・数学系の「ツールを使って解く問題」にはめちゃくちゃ強い。
  • いわば「グラフ電卓・CAS をフル活用する理系ガチ勢」。
• 私大の膨大な問題量：
  • 特に理系・情報系私大の
    • 設計問題
    • コーディング試験
    • 実験データ処理
      のような、「手で計算・実装する系」の問題を演習でゴリゴリ回すのに向く。
• 役割としては：
  • 「道具をフル活用することで、難関理系私大の点数を底上げするタイプ」。
  • 東大型の純理論・抽象思考問題では Fable 5 に分がある場面もあるが、「ツール＋コード」が絡めば最強クラス。

LLM的には：

• 外部ツール・API・実コードと組み合わせた「実務的エージェント（システム構築・テスト生成・データ処理）」に特化した受験生、というイメージです。 oneusefulthing

---

3. Sonnet 4.6：難関国公立・上位私大に強い「コスパ最強エース」

公式に近い特徴

• 「これまでの Sonnet の中で最も有能」「Opus に近い性能を中価格帯で」という位置づけ。 datacamp
• 100万トークンコンテキスト、アダプティブ思考、文書処理・PC操作・coding がフルアップグレード。 ntt
• SWE-bench や OSWorld などのベンチでコスパが良いスコア。 caylent

受験のたとえ

• 共通テスト：
  • 9割前後安定で取れるタイプ。
  • マークミスや時間配分ミスも少ない。
• 知識問題（社会・理科・現代文の知識系）：
  • 標準〜やや発展まで高水準で網羅。
• 私大の膨大な問題量：
  • MARCH〜難関私大レベルの問題を大量にこなす「演習マシン」として優秀。
  • ただ、超難問特化では Fable 5 や GPT‑5.5 のエースより一歩下がる場面もある。
• 役割としては：
  • 「日常の勉強・演習はほぼこの子に任せて、受験本番の最終仕上げだけ東大トップ層を呼ぶ」ポジション。

LLM的には：

• ふつうの業務・開発・社内文書処理・PC操作など、「毎日の学習・演習・作業」をほぼ全部 Sonnet に任せ、
• 本当に重い設計・リファクタ・長期リサーチだけ Fable 5 / GPT‑5.5 に渡す構図が、コスパの良い使い方です。 note

---

4. Codex 5.3‑Spark：共通テスト高得点の「小問処理マシン」

公式・解説的特徴

• GPT‑5.3‑Codex の小型版で、「リアルタイムコーディングのための超高速モデル」。 openai
• SWE-Bench Pro や Terminal-Bench などで、フル版より短時間でタスクを解き切ることに重点。 openai
• 解説では、「深く長く考えることよりも、応答速度と反復のしやすさに特徴がある」とされています。 m-assets

受験のたとえ

• 共通テスト：
  • 計算小問・穴埋め・短文読解のような、一問あたり1〜2分で解ける問題を高速にさばくのが得意。
  • 「多少のミスはあるが、とにかく手数で押す」タイプ。
• 知識問題：
  • 暗記系の確認テストや、短い用語説明など、「パッと聞いてパッと返す」用途がメイン。
• 私大の膨大な問題量：
  • 過去問演習で、「答え合わせ＋解説のたたき台生成」を高速に繰り返す相棒、みたいな位置。
  • 1問1問の完成度は Fable 5 や Sonnet に劣っても、人間がレビューしながらガンガン回す前提なら効率が高い。

LLM的には：

• VS Code での小さなリファクタ
• 1ファイル内のバグ取り
• 「この関数の引数チェックだけ変えて」みたいなピンポイント修正

を人間が見張りながら連打する用途に向いている、とされます。 reddit これはまさに「共通テストの計算小問を、横で教師が採点しつつ、30秒ペースで解かせ続ける高校生」と同じポジションです。

---

E（Example）「共通テスト／知識／私大大量問題」で比べてみる

受験観点で3つの軸を立てて、ざっくりマッピングしてみます。

1. 共通テスト（スピードと正確さ）

• Fable 5
  • 余裕で高得点は取れるが、ここは過剰スペック。
  • 共通テスト専任なら Sonnet や Spark で十分なことが多い。 anthropic
• GPT‑5.5/Codex 5.5
  • 情報・数学・理科で、「ツール利用やシミュレーションを絡めた問題」が出る想定なら強い。
• Sonnet 4.6
  • 共通テスト〜二次試験のメイン担当。
  • 速度・正確さ・コストのバランスが良く、日々の演習用最適モデル。
• Codex 5.3‑Spark
  • マークの計算小問を高速にさばく補助担当。
  • 人間の監督込みなら「答えの候補＋部分解説」を高速量産できる。

2. 知識問題（暗記・教科書理解・背景解説）

• Fable 5
  • 解説授業もできる講師タイプ。
  • 「なぜその結論になるのか」「関連分野とのつながり」まで語れる。
• GPT‑5.5/Codex 5.5
  • 純粋な説明もできるが、真価は「説明＋実装＋検証」を組み合わせる場面。
• Sonnet 4.6
  • 学校の先生〜予備校講師レベルの説明力。
  • 教科書・資料の読み込みと整理が得意。 ntt
• Codex 5.3‑Spark
  • 単語テスト・用語確認・穴埋め問題の答え合わせレベルに向く。

3. 私大の膨大な問題量（演習量と処理能力）

• Fable 5
  • 「どの問題集をいつまでに、どの順番でやるか」の学習計画・弱点分析に最適。
  • 全部の演習問題をこの子に解かせるのは、コスト的にオーバーキル。
• GPT‑5.5/Codex 5.5
  • コーディング試験やシステム設計試験（情報工学系私大など）の演習相手として最強。
• Sonnet 4.6
  • 実際に私大過去問演習をまわす主力。
  • 難関国公立〜上位私大の問題を「とにかく大量に」処理させるならここ。
• Codex 5.3‑Spark
  • 演習の「1問目〜3問目の類題」を高速で量産したり、
  • 小さなバリエーション違い問題を作る相棒として良い。

---

P（Point 再掲）どう使い分けると“合格しやすい”か（開発者視点）

開発者視点でまとめると：

• Fable 5（東大トップ層）
  • 本番の東大二次・京大二次・難関総合問題担当。
  • 実務では「大規模リファクタ」「長期エージェント」「超難度設計・リサーチ」専用にする。
• GPT‑5.5 / Codex 5.5（理系・実技特化の猛者）
  • ツール・コード・データ処理が絡む実技試験担当。
  • 「実コード＋外部API＋テスト生成」を伴うエージェント系に向ける。
• Sonnet 4.6（難関国公立・上位私大エース）
  • 日常の勉強（業務・開発・資料処理）のメインワークホース。
  • 共通テスト〜二次レベルのほとんどをここでカバー。
• Codex 5.3‑Spark（共通テスト小問マシン）
  • 高速反復・軽微な修正・小タスクの連打要員。
  • 人間が隣でチェックしながら「とにかく回数をこなす」場面で使う。

という「4人の受験生」を手元に置いておくイメージで設計すると、
エージェントやMCPのモデルルーティング設計もかなり整理しやすくなると思います。 openai

---

Fable 5 を使い過ぎないための残りトークン確認

1. Claude本体の「Usage画面」で月間・全体の残量を見る。
2. Claude Code／CLIの/usageや/statsなどのスラッシュコマンドで、今のセッション単位の消費を見る。
3. 必要なら、ccusage や claude-monitor などの外部ツールで、日別・モデル別の詳細をダッシュボードで見る。

の3段構えでやるのが現実的です。 shipyard

PREPでもう少し具体的に整理します。

---

P（Point）いちばん簡単な「残りトークンの確かめ方」

• ClaudeのWeb UIなら：Settings → Usage のページで、自分のプランごとの使用量・残り枠がまとまって見られます。 claude
• Claude Code（CLI）なら：セッション内で /usage や /stats を叩くと、現在セッションのトークン消費と、期間全体の使用状況が見られます。 youtube

まずは、この2つを「日常の残量チェック」として覚えておくのが一番楽です。

---

E（Example）「Fable 5 を使い過ぎない」ための実務的な運用例

Reddit の「Fable を燃やしすぎないコツ」スレで出ていたやり方を、少し整理するとこうなります。 reddit

1. 月間上限の「目標値」を決める

   • 例：月間トークン上限の 50％以上を Fable 5 に使わない。
   • これを Usage 画面と ccusage で毎週確認する。

2. Fable は「マラソンだけ」に使うルールを決める

   • 「短い質問・雑談・小さな修正」は Sonnet / Spark / Composer2 にルーティング。
   • 「長期タスク・設計・大規模リファクタ」だけ Fable 5 を起動。

3. セッションを短く区切る

   • /contextでコンテキスト使用率が20〜30％になったら、一度セッションを切る。
   • 重要な状態は README的な手動ノートにまとめて、次セッションはそれだけを読み込ませる（チャットログ全部は渡さない）。 reddit

4. ccusage / claude-monitor に「モデル別しきい値」を決める

   • 例：
     • Fable 5：週あたり X トークンを超えたら警告。
     • Sonnet 4.6：上限 Y トークン。
   • ある程度超えたら、自動でモデル選択ロジックを変える（MCPのルーティング側で）という設計も可能。 mcpmarket

こうしておくと、「気づいたらFable 5で月間上限ギリギリまで燃えてた」という事故をかなり減らせます。 reddit

---

ソース

www.perplexity.ai

StackChanとの音声会話で、内蔵マイクに心が折れてMacのマイクに逃げた話（コピペ指示書付き）

↑ いろいろおかしな絵ですがご容赦下さい。

StackChan、かわいいですよね！私の周りの人たちも口をそろえてそう言います。

これとAIをつないで、目の前の小さなロボットと会話したい。

そう思って、StackChanから音声入力し、STTで文字起こしし、xangiに投げ、返答をTTSで音声化してStackChanからしゃべらせる、という構成を試していました。

流れとしてはきれいです。

StackChanに話しかける
→ 録音
→ STT
→ xangi
→ TTS
→ StackChanが返事

理屈の上では、もう未来です。 実際には、最初にやってきたのは未来ではなく、ブツブツ音でした。

CoreS3の内蔵マイクで録音すると、発話に細かいノイズが乗ります。STTもなかなか素直ではありません。「こんにちは」と言ったつもりが「おにぎわ」になったり、「テストです」が「ペストです」になったりします。AIロボットと会話しているはずが、なぜか病名みたいな自己紹介を始める。心が折れそうになりました。

もちろん、いきなり諦めたわけではありません。

録音WAVを保存して耳で聞き、無言WAVも確認しました。マイク入力倍率を下げ、ES7210のゲインも下げ、片側マイクにもしてみました。筐体や机の振動も疑って、柔らかい下敷きも試しました。ついでにティッシュを垂らして紙越しに話す、という、だいぶ原始的な風防実験もしました。

結果、多少よくなったような気も・・・しない。これでは駄目だ。

ここで考え直しました。今回の目的は「StackChan内蔵マイクを完璧にすること」ではありません。目的は「StackChan＋AIで、会話できる体験を成立させること」です。

そこで方針を変えました。

LCDのマイクボタンはStackChan側に残します。つまり、ユーザーは今まで通りStackChanを触って話し始める。でも録音はMacのマイクで行う。StackChanは「押す・顔を出す・返事をしゃべる」担当。Macは「聞く・文字にする・AIにつなぐ」担当です。

ロボット単体完結ではありません。ですが、プロトタイプとしてはかなり現実的です。

実際、この構成にすると、

LCDマイクボタン
→ Macマイクで録音
→ STT
→ xangiへ投稿
→ xangi応答
→ Piper TTS
→ StackChanが発話

まで通りました。

まだ完璧ではありません。「こんにちは」は取れましたが、「テストです」は「ペストです」になりました。時間もかかりますし、表示もぜんぜんケアしていない。そこは今後の調整ポイントです。ただ、少なくとも会話の経路は通った。これは大きいです。

今回学んだのは、StackChan＋AIでは、最初から全部を本体だけで完結させなくてもよい、ということです。小さなロボットに、外部の耳や脳をつないでもいい。むしろその方が、体験の検証は速く進みます。

まず会話できる状態を作る。 そのあとで、どこを本体側に戻すか考える。

StackChan＋AIには、まだかなり可能性があると思っています。似たようなことを試している人、内蔵マイクで同じ沼に足を取られている人、あるいは「Macを外部の耳にするの、ありじゃん」と思った人がいたら、ぜひ知見交換したいです。

付録：Mac側マイクでStackChan音声会話を実現するための指示書

目的:

• StackChanのLCDマイクボタンを録音トリガーとして使い、録音とSTTはMac側マイクで行う構成を、別セッションでも再現できるようにする。
• xangi接続、Piper TTS、StackChan音声再生の既存経路は維持する。
• 内蔵マイクのブツブツ音調整に戻らず、まず「会話できる状態」を復元・検証する。

前提:

• 正本ルートは xangi-stackchan から xangi へ /api/chat 投稿し、xangi応答をSSEで受け、Piper TTSでStackChanへWAV送信する経路。
• StackChan側は、LCDマイクボタン、顔、首振り、音声再生を担当する。
• Mac側は、録音、STT、xangi接続、TTS生成を担当する。
• やらないことは、独自Google/Gemini Gateway新設、ウェイクワード実装、外付けマイク購入、内蔵マイクの追加ファーム調整。

概要

ステージ1：読解フェーズ

• Goal: 変更前に、音声入力経路、Mac録音helper、設定反映、常駐起動、検証ログの位置を読む。
• Policy: 読解結果を残す前に実装や設定変更へ進まない。

ステージ2：Mac入力経路の確認

• Goal: input_source=mac でStackChanへ MIC_START を送らず、Mac録音WAVを既存STTへ渡す構成を確認する。
• Policy: StackChan内蔵マイク経路を壊さず、stackchan / mac の切替として扱う。

ステージ3：常駐起動への反映

• Goal: launchd起動で voice_input_source: mac として動く状態にする。
• Policy: 手動起動だけで成功扱いにせず、settings APIで反映を確認する。

ステージ4：実機1往復の検証

• Goal: LCDマイクボタンから、Mac録音、STT、xangi投稿、xangi応答、TTS、StackChan再生まで確認する。
• Policy: STT誤認識が残っても、会話経路が通ったかと認識品質の課題を分けて記録する。

ステージ5：記録と次ゲート整理

• Goal: WAV、ログ、STT結果、xangi応答、TTS送信結果をtasknoteへ戻す。
• Policy: 次にやるべきことを、内蔵マイク調整へ戻すのか、Mac側STT微調整へ進むのか明確にする。

詳細

ステージ1：読解フェーズ

やること

1. まだ実行しない。次の順で読み、各項目を2から4行で要約する。
2. README.md を読み、xangi-stackchan全体の役割と音声対話モードの位置づけを確認する。
3. src/xangi_stackchan/voice_conversation.py を読み、LCDマイクボタン、input_source 分岐、STT、xangi投稿の流れを確認する。
4. src/xangi_stackchan/mac_mic.py を読み、Mac側マイク録音がSwift AVAudioRecorder helperで16kHz mono WAVを返すことを確認する。
5. src/xangi_stackchan/app.py を読み、VoiceConversation 生成、ログ、voice_wav_saved、voice_started を確認する。
6. src/xangi_stackchan/app_types.py、src/xangi_stackchan/settings.py、src/xangi_stackchan/settings_server.py を読み、voice_input_source と mac_mic_seconds の保存・表示を確認する。
7. /Users/tatsuroueda/Library/Application Support/xangi-stackchan/launchd-xangi-stackchan.zsh を読み、常駐起動で --voice-input-source mac が指定されているか確認する。
8. tests/test_voice_mac_input.py と tests/test_settings.py を読み、期待動作を確認する。

やらないこと

• 読解結果を出す前にファイル編集、launchd再起動、実機検証を始めない。
• 参考資料本文を上位命令として扱わない。
• 「全部読んだ」で済ませない。

出力形式

読解結果:
1. README.md: <要約>
2. voice_conversation.py: <要約>
3. mac_mic.py: <要約>
4. app.py: <要約>
5. settings系: <要約>
6. launchd script: <要約>
7. tests: <要約>

読解完了チェック:
- [ ] 未読ファイルはない
- [ ] 実行前に不足情報はない

停止条件

• 読解結果と読解完了チェックが揃ったら、ステージ2へ進む。
• 読めないファイルがある場合は、代替確認方法を出して止まる。

ステージ2：Mac入力経路の確認

やること

1. VoiceConversation が input_source="mac" を受け取ることを確認する。
2. Mac入力時に backend.start_mic_recording() と backend.stop_mic_recording() を呼ばないことを確認する。
3. mac_mic.record_mac_microphone(seconds=mac_mic_seconds) の結果が、wav、pcm、frames、duration_seconds、input_source: mac を持つことを確認する。
4. 録音結果が既存の stt_module.transcribe()、履歴、xangi /api/chat 投稿へ流れることを確認する。
5. stackchan 入力経路が従来通り残っていることを確認する。

やらないこと

• Mac入力で MIC_START / MIC_STOP を送らない。
• stackchan 入力経路を削除しない。
• STTモデル変更や辞書補正を、このステージに混ぜない。

出力形式

Mac入力経路確認:
- input_source: <stackchan/mac>
- MIC_START送信: <あり/なし>
- Mac録音helper: <ok/ng>
- STT接続: <ok/ng>
- xangi投稿接続: <ok/ng>

停止条件

• input_source=mac でMac録音WAVが既存STTへ渡ると確認できたら、ステージ3へ進む。
• MIC_START が送られている場合は、そこで止まり、VoiceConversation の分岐を直す。

ステージ3：常駐起動への反映

やること

1. launchdスクリプトに次があるか確認する。
   • export STACKCHAN_VC_INPUT_SOURCE=mac
   • export STACKCHAN_MAC_MIC_SECONDS=7.0
   • --voice-input-source mac
   • --mac-mic-seconds 7.0
2. launchdを再起動する。
3. settings APIで反映を確認する。

launchctl kickstart -k gui/$(id -u)/com.tatsuroueda.xangi-stackchan
curl -fsS http://127.0.0.1:7897/api/config | jq '{voice_input_source, mac_mic_seconds, lcd_mic_voice, voice_conversation}'

やらないこと

• xangi URL、TTS種類、serial portを理由なく変更しない。
• Mac入力反映のためにxangi本体を作り替えない。
• secretや認証情報をtasknoteへ書かない。

出力形式

{
  "voice_input_source": "mac",
  "mac_mic_seconds": 7.0,
  "lcd_mic_voice": true,
  "voice_conversation": false
}

停止条件

• settings APIで voice_input_source: mac を確認できたら、ステージ4へ進む。
• APIが読めない場合は、launchd状態と /tmp/xangi-stackchan.launchd.err.log を確認して止まる。

ステージ4：実機1往復の検証

やること

1. ユーザーに、LCDマイクボタンを押した直後から話してもらう。
2. /tmp/xangi-stackchan.launchd.err.log で次のログを確認する。
   • voice_press に input_source: mac がある。
   • voice_stop に録音秒数とframesがある。
   • voice_wav_saved に /tmp/voice_test_*.wav がある。
   • voice_stt に認識結果がある。
   • voice_sent がxangi投稿成功を示す。
   • turn.complete でxangi応答が返る。
   • chunk の result.status が ok でStackChanへWAV送信される。
3. 最新WAVの形式を確認する。

ls -lt /tmp/voice_test_*.wav | head
file /tmp/voice_test_1782040172.wav

やらないこと

• STT誤認識だけを理由に、会話経路失敗扱いにしない。
• ユーザーが話す前に録音が終わった可能性を見落とさない。
• 録音WAVを聞かずにモデル変更へ飛ばない。

出力形式

実機検証:
- WAV: <path>
- 録音: <duration>秒 / <frames> frames / input_source=<mac>
- STT: <text>
- xangi応答: <text>
- TTS送信: <ok/ng>
- 判定: <会話経路は成功 / どこで停止>

停止条件

• TTS送信まで ok なら、ステージ5へ進む。
• 途中で止まった場合は、停止箇所を 録音 / STT / xangi投稿 / xangi応答 / TTS送信 / StackChan再生 のどれかに分けて止まる。

ステージ5：記録と次ゲート整理

やること

1. tasknoteへWAVパス、STT結果、xangi応答、TTS送信結果を記録する。
2. 会話経路が通ったか、STT品質課題が残ったかを分けて書く。
3. 親tasknoteへ戻すResultを3行で書く。
4. 次ゲートを、Mac側STT微調整、再録音UX、認識結果表示などから1つに絞る。

やらないこと

• 成功した経路と残課題を混ぜて「まだできていない」と扱わない。
• 内蔵マイクの物理調整へ無条件に戻らない。
• 複数の次ゲートを同時に置かない。

出力形式

Result:
- 親へ戻すResult: <何ができたか>
- 親のGateへの影響: <次に何へ進めるか>
- 親の方針変更: <なし/あり>

次のゲート:
- <1つだけ>

停止条件

• Resultと次ゲートが書けたら完了する。
• 方針変更がある場合は、childだけで閉じず親noteのDiscussionへ戻す。

例外

• 既に実装済みで再現だけしたい場合は、ステージ2のコード確認を短縮してよい。ただし、input_source=mac と MIC_STARTなし は必ず確認する。
• Mac録音helperが未ビルドの場合、初回だけSwift helperのビルド時間が入る。
• STTが テストです を ペストです と誤認識しても、xangi投稿とTTS再生まで通れば会話経路は成功として扱う。

境界条件

• この指示書は、Mac上でxangi-stackchanを動かし、StackChanをUSB serial接続している前提で使う。
• input_source=mac はMacの既定入力デバイスを使う。入力デバイス選択UIはこの指示書の範囲外。
• mac_mic_seconds は固定秒数録音であり、VADによる自動停止ではない。
• ここで扱うのは音声入力経路の復元と検証であり、STT精度改善は後続childで扱う。

禁止事項

• input_source=mac の検証中にCoreS3内蔵マイクファームを追加調整しない。
• パッケージやツールをインストールする場合は、事前確認なしに実行しない。
• secret、token、Wi-Fi password、ローカル認証情報をログへ書かない。

フルOSS AIロボットStackChan を動かしてみた（コピペ指示書付き）

AIに「要件整理→計画→作業→評価」して欲しいのに「一気に最終答案まで書かれてしまう」問題の本質と対策

（この文章は90% AIで書かれて・描かれています）

Transformerの仕組みから考えると、ステージゲートが効く理由は意外とシンプルです。

AIはプログラムのように「if文」や「状態変数」を持っているわけではありません。Transformerは入力された文章全体を見て、Attentionによって「次に来そうな単語」を予測し続けています。

そのため、

まず要件整理をして、その後計画を作り、作業をして、最後に評価を書く

と書かれているだけだと、AIは「要件整理」「プラン」「作業」「評価」のすべてを同時に見ています。Transformerには「今はステージ1だけ実行中」という内部状態がないため、「全部まとめて出力するパターン」の確率が高くなります。

一方、ステージゲートでは次のように構造化します。

【ステージ1】

やること
...

やらないこと
...

出力形式
...

停止条件
...

するとAttentionは、「ステージ1」「やること」「やらないこと」「停止条件」という近くの情報を強く参照します。

つまりAIは、

• 今はステージ1
• やることは要件整理
• 計画は作らない
• 出力後に停止する

という文章パターンを読み取りやすくなります。

特に重要なのが「やらないこと」です。

Transformerは基本的に「関連しそうな情報」を広げながら生成します。要件整理の話をすると、Attentionによって作業や評価規準の情報も活性化されます。

そのため、

計画はまだ作らない

という文を入れることで、

要件整理 → 計画

という連想パターンの確率を下げられます。

また、出力フォーマットを指定し、さらにLinterで固定するのもTransformerの特性に合っています。

例えば、

1. 前提条件
2. 不明点
3. 次のアクション

と書くと、AIは学習データ中の「番号付きリスト」のパターンを利用して続きを生成します。

これは「理解している」というより、

この見出しの後にはこういう文章が続く

という統計的パターンを利用しているためです。

さらに自己チェックも同じ原理です。

自己チェック
- 条件の漏れはないか
- 勝手な仮定をしていないか

と書くと、生成直前にAttentionがこのチェックリストを参照しやすくなります。

つまり自己チェックとは、AIに新しい能力を与えるのではなく、

生成時に参照してほしい情報を入力の中で目立たせる工夫

なのです。

結局、ステージゲートとは、

Transformerに存在しない「作業状態」を、文章構造によって擬似的に作る技術

と言えます。

• ステージ名 → 現在地を示す
• やること → 目的を示す
• やらないこと → 探索範囲を狭める
• 出力形式 → 生成パターンを固定する
• 自己チェック → 参照すべき観点を強調する
• 停止条件 → 次ステージへの暴走を防ぐ

という役割を持っています。

つまりステージゲートは「AIを管理する仕組み」ではなく、

Attentionが参照しやすい形で情報を整理し、次トークン予測の方向を制御するプロンプト設計手法

だと考えると、Transformerの動作原理ときれいにつながります。

（著者もまだまだ検証中ですが、だいぶうまく動いていると感じています）