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の動作原理ときれいにつながります。

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

AIに「読んで」と言っても「読まない」問題の本質と対策

（AIが95%書いた・描いた記事です）

「指示したファイルを読んでくれない問題」は、AIの理解力の問題というより、

AIにどのファイルを渡すかという仕組み（Retrieval）と、人間の指示の出し方の問題です。

AIは渡された情報しか読めません。

そのため、

• 必要なファイルがAIに渡されていない
• AIがどのファイルを優先すべきか判断できていない
• 読み込み確認をしていない

といった状況で作業してしまうことがあります。

なぜ起きるのか？

原因1：AIは渡されていないファイルを読めない

AIは入力されたテキストだけを処理します。

たとえば先生から、

教科書10ページまで読んできなさい

と言われても、

実際に渡されたのが1〜3ページだけなら、4〜10ページは読めません。

AIも同じです。

多くの開発環境では、

• 現在開いているファイル
• 最近使ったファイル
• 関連性が高そうなファイル

だけがAIへ渡されています。

そのため、例えば

skill.md以外も読んで

と書いてあっても、

そのファイルの内容自体が渡されていなければ読むことはできません。

---

原因2：「全部読んで」は具体的な指示になっていない

人間なら、

このフォルダ全部読んで

と言われれば、

1. フォルダを開く
2. 中身を確認する
3. 必要なものを読む

という行動を想像できます。

しかしAIは、

フォルダを開く

という行動を自動で行うわけではありません。

AIは基本的に、

与えられた文字列から次の文字列を予測する

仕組みです。

そのため、

全部読んでね

という指示は理解できても、

実際に追加ファイルを読み込むとは限りません。

---

原因3：ごく一部のファイルだけが目立っている

多くのプロジェクトでは、

• skill.md
• README.md

のような説明ファイルが最初に読まれます。

一方で、

• schema.json
• handlers.rb
• config.yml

などは、

役割が分かりにくかったり、 別フォルダにあったりして、 AIの優先順位が下がることがあります。

結果として、

skill.md → 読む
その他 → 読まない

という偏りが起きやすくなります。

---

どうすれば防げるのか？

対策1：読むフェーズと実装フェーズを分ける

最も効果的な方法です。

フェーズ1：必要ファイルを特定する

まずコードを書かせず、

1. プロジェクト内のファイル一覧を確認してください
2. 各ファイルの役割を推定してください
3. 今回の作業に必要なファイルを
   「必須」
   「参考」
   に分類してください
4. まだコードは書かないでください

と指示します。

するとAIは、

今回の作業には何が必要か

を整理します。

---

フェーズ2：必要ファイルを読ませる

次に、

AIが「必須」と判断したファイルをまとめて渡します。

その後で、

これらのファイルを理解した上で実装してください

と指示します。

こうすると、 目立つファイル以外の情報も確実にAIの入力へ入ります。

---

対策2：目立つファイルを「目次」にする

目立つファイルは説明書ではなく、

プロジェクトなどの地図

として使う方が効果的です。

例：

# ファイル構成

- skill.md
  - 全体説明

- schema.json
  - データ構造

- handlers.rb
  - 実装ロジック

- config.yml
  - 設定情報

# 推奨読書順

1. skill.md
2. schema.json
3. handlers.rb

こうしておくと、

AIも人間も、

次に何を読むべきか

を判断しやすくなります。

---

対策3：読んだ証拠を提出させる

「読んだつもり」を防ぐ方法です。

たとえば、

以下を完了してください。

- [ ] skill.md の要約
- [ ] schema.json の主要フィールド一覧
- [ ] handlers.rb の主要関数一覧

まだコードは書かないでください。

と指示します。

すると、

AIは各ファイルに注意を向ける必要があります。

また、人間側も

本当に読んだのか

を確認できます。

---

対策4：ファイル構成を分かりやすくする

AIは人間と同じように、

名前から役割を推測します。

たとえば、

docs/
 ├─ skill.md
 ├─ schema.md

src/
 ├─ handlers.rb

config/
 ├─ config.yml

tests/
 ├─ test_xxx.rb

のように整理すると、

AIも重要ファイルを見つけやすくなります。

---

まとめ

「読んで」と言っても「読まない」問題の本質は、

AIの理解能力ではなく、情報の供給方法にあります。

そのため有効な対策は次の3つです。

1. 読むフェーズと実装フェーズを分離する
2. 目立つファイルを目次・地図として使う
3. 要約やチェックリストで読了確認を行う

つまり、

「全部読んで」と頼むよりも、「何を読むべきかを整理させ、その内容を確認してから作業させる」

方が、はるかに安定して動作します。

（注：筆者は検証中です。悪しからず）