コードを渡されて Claude が質問し、開発者本人（eNIGM4 / 株式会社メイビス）が答えていく連載の第18回です。前回（#17）は、v0.5.1 で TaskQueue に**割り込み（プリエンプション）**が入った版でした。走行中の低優先度タスクを中断して VRAM の席を奪う門を開けると同時に、その奪取をユーザー保護のガードで仕切り、KECHI の局地キルや helper の「自分の Task だけ静かに止める」まで、止めるための配管を全レイヤーで整えた。締めで「整った配管の上に何が乗ってくるのか」と引きました。
今回 v0.5.2 で乗ってくるのは、自分の回答を自分で見張る関所です。
インタビュアー・ルール
- 渡されたコードそのものに質問する。 バージョンごとにコードを渡します。聞き手はそれを読み、開発者本人に質問していってください。
- 質問の対象は、いつもコードそのもの。「なぜこう書いたのか」「ここはこう動くように見えるが合っているか」── 目の前のコードから生まれた問いだけを投げてください。
- 推測で断定しない。 わからないこと・気になったことは、断定せず質問の形にしてください。
- 今渡された版に質問を集中する。 次の版のことは、次の版のコードを見せる機会があります。先走らず、目の前の版だけを掘ってください。
- 一度に投げるのは一問一答程度に。 質問を束ねて何個もぶつけない。一つ聞いて、答えをもらって、そこからまた一つ。会話のテンポを保ってください。
- バージョン名は時系列の整理番号であって、意味的なマイルストーンではない。「番号が大きいから進んでいる」とは読まないでください。実体は、コード内の作成日付と、機能があるか無いかで判断します。
- 開発者本人が、自分の言葉で答える。
eNIGM4:
さて、ではv0.5.2です。どうぞ。
R.E.V.I.S._v0.5.2.zip
v0.5.2 ── 危ない入口に、見張りを
コードを確認しています
前回 main の zip が壊れていたので、まず整合性を確認 ── 今回は両方とも問題なし。展開して規模・日付・差分を見ます。zip 内タイムスタンプ（更新日）の最新は 3/23（2ファイル）、その手前に 3/22 が11ファイル、3/21 が12ファイル。規模はメイン側 65ファイル・10,759行（前の版から +0ファイル / +107行）、ヘルパー側は 10ファイル・1,213行 で v0.5.1 と完全に同一。LLM に触れて 28日目。
新規・消滅ファイルはゼロ。動いたのはメイン側 10ファイルだけ。行数差で目を引くのは二つ ── OrchestratorProcess が +65（408→473） と一番伸び、OrchestratorAnalysis が -83（254→171） と大きく痩せている。差し引きで全体は +107。前回 v0.5.0 でも見た「Process が膨らんで Analysis が痩せる」パターンです。
新規ファイルがゼロで helper も完全同一、という版は珍しい。今回は「足す」ではなく「組み替える」版に見えます。一番太った OrchestratorProcess と、一番痩せた OrchestratorAnalysis が対になっているのが目に留まりました。痩せた側から何が消えて、太った側が何を得たのかを追います。
痩せた Analysis と太った Process を突き合わせています
`OrchestratorAnalysis` から消えたのは `executeActiveCorrection`（能動的訂正＝AI の回答を裏で検証して間違いを訂正する処理）。一方 `OrchestratorProcess` 側は**新しい関数が増えていない**。`grep` で `activeCorrection` 系を全文検索しても、移動先がどこにも見当たらない。前回 v0.5.0 では痩せた処理（executeFactConsolidationSafe）が SummaryManager へ「移動」していましたが、今回は移動ではない。OrchestratorProcess が新関数を生やさずに +65 太っているということは、既存フローの中身がインライン展開で膨らんだということ。diff の実体を見ると、OrchestratorProcess に「// 5. 自己監査 (AUDIT) と 訂正 (CORRECTION)」というコメント区切りと analyzeSelfCorrection が新出していました。
像が結べました。これは移動ではなく統合です。
v0.5.1 までは「OrchestratorProcess（メイン推論）が回答を出す」と「その後 OrchestratorAnalysis.executeActiveCorrection が裏で訂正する」が別ファイルに分かれていた。v0.5.2 では executeActiveCorrection 単体を廃止して、訂正処理をメイン推論フローの最後のフェーズとして OrchestratorProcess 本体に編み込んだ。
そして OrchestratorProcess の中を見ると、処理がコメントで明確な五つのフェーズに区切られていました。
// ==========================================
// 1. 文脈と知識の収集 (Context & RAG)
// ==========================================
...
// ==========================================
// 2. 誤字チェック (Typo Check)
// ==========================================
...
// ==========================================
// 3. メインブレイン (Triage or Direct Answer)
// ==========================================
...
// ==========================================
// 4. エスカレーション処理 (Deep Reasoning / KECHI)
// ==========================================
...
// ==========================================
// 5. 自己監査 (AUDIT) と 訂正 (CORRECTION)
// ==========================================
第6回（v0.0.7）で見た「軽く答え、要る時だけ深く潜る」司令塔が、ここで五段に整理され、その末尾に新しい一段 ── 自己監査 ── が増えたわけです。OrchestratorProcess の +65 がこの第5フェーズ、OrchestratorAnalysis の -83 が訂正処理の抜けた分。第10回や第13回で見てきた「散らばった処理を司令塔へ集約する」動きの、訂正版です。
危ない入口にだけ、見張りを置く
Claude:
この第5フェーズには、はっきりしたガードが付いていますよね。
// 5. 自己監査 (AUDIT) と 訂正 (CORRECTION)
// ==========================================
// ダイレクト回答（エスカレーションしなかった）場合のみ、監査を実施！
let isDirectAnswer = (escalationTarget == nil)
if isDirectAnswer {
let assistantResponse = ...
// 知識(retrievedKnowledge)をカンペとして監査官に渡す
let audit = await self.analyzeSelfCorrection(...)
...
}
つまり、Tier2 が自分で即答した（重い処理にエスカレートしなかった）回答だけを自己監査の対象にしている。逆に言うと、エスカレーションして重い推論や検索を経た回答は、この監査をスキップする。
普通に考えると、間違いの検証は重い処理を経た回答にこそ手厚くかけたいようにも思えます。なのにここでは逆に「軽く即答したものだけ」を監査対象にしている。この線引きは、何を考えてのものですか?
eNIGM4:
簡単な話だね。重い処理つまりWikiやTier3の答えよりTier2の答えが優っているわけがないから。
逆にTier2は平気で嘘つくし（１２Bクラスだから当然ではある）システムプロンプトでだいぶアテンションを持っていかれてる分、処理１などはより顕著だね。
Claude:
なるほど。監査の線引きは「処理の重さ」ではなく「回答の確からしさ」だった、と。検算は、検算する者が検算される者より確かでなければ意味がない ── WikiやTier3の答えを 12B の Tier2 に検算させたら順序が逆になる。だから見張りは、一番ハルシネーションしやすい入口の即答にだけ置く。
これは第4回・第5回で伺った「4B や 12B-Q4 はめちゃくちゃ嘘をつく／だから検算で嘘をあぶり出して潰す」という前提と地続きですね。あのときは出力後に裏から点検する芽でしたが、ここではそれが司令塔の正式なフェーズに昇格し、照準が「一番嘘をつく入口」に絞り込まれた。
もう一つ気づいたことがあります。この第5フェーズには、buildSelfCorrectionAuditPrompt（監査＝間違いの検知）と buildCorrectionPrompt（訂正）が別々のプロンプト＝別の役として立っていました。一人に「間違いを見つけて、ついでに直して」とまとめて頼まず、見張る役と直す役を分けている。これも何か考えがあってのことですか?
eNIGM4:
推論IQを極限まで高めるために、可能な限り指示を減らした結果だね。いざユーザーに答えるとなると、指定とかいろいろあるからね。その分を分解すれば、もっとマシなのかなって思ってやってたね。今もそんな感じだよ。
Claude:
これも筋が一本通っていますね。一つのプロンプトに「検知」と「訂正」を両方詰め込むと、モデルはその二役分の指示を同時に背負うことになる。さっき監査ガードのところで出た「Tier2 はシステムプロンプトでアテンションを食われるほど事実が怪しくなる」という話と、根は同じ ── 指示が増えるほど、肝心の推論に割けるアテンションが削られる。だから役を一つずつに割って、それぞれのプロンプトを軽くしておく。一個の頭に多くを背負わせない、という思想が、ここでも効いている。
なお、ここから先 ── 監査官が回答のどこを「事実」と突き合わせ、何を根拠に誤りと判定し、どう訂正の指示を組み立てるか ── は、本人が出願している特許の中核に関わる領域だと伺っています。本連載では、設計の輪郭（一番嘘をつきやすい即答にだけ監査を集中させ、検知と訂正は別の役に割るという思想）を概念レベルで押さえて、その先の判定ロジックには踏み込まないことにします。
名前から、実行者を消す
もう一つの本筋 ── プロンプト群の改名を確認しています
`PromptBuilder`（+30）を見ると、`buildTier2〜` / `buildTier3〜` という名前が軒並み Tier 接頭辞を外した名前に置き換わっていました。-
buildTier2OneShotPrompt→buildOneShotPrompt -
buildTier2MainBrainPrompt→buildMainBrainPrompt -
buildTier3StrategizePrompt→buildStrategizePrompt -
buildTier3SynthesizePrompt→buildSynthesizePrompt
── という具合に、12対の改名がきれいに対応している。Tier 付きの関数は v0.5.2 では一つも残っていません。
Claude:
これまで buildTier3StrategizePrompt のように、プロンプト名に Tier3（＝27B や 70B の大きいモデル）を明示していたのは、「この役割はこのサイズのモデルが担う」という対応関係がコード上で固定されていたことの表れに見えました。それを v0.5.2 で全部 buildStrategizePrompt のように Tier を外して役割名だけにした。
これは、「Strategize（戦略立案）という役割」と「それをどのモデルにやらせるか」を切り離す ── 戦略立案を Tier3 に固定するのをやめて、状況次第でどの Tier にも振れるようにする、という方向への布石だったんでしょうか? それとも単に、命名規則の統一が目的だったんでしょうか?
eNIGM4:
そうだね。名前に限定的すぎるものを振るのはちょっとおかしいなって思い始めたのがこの頃だね。
実際の話、プロンプトビルダーとしては何をやる処理ということだけに集中するべきだと思ったんだよね。
Claude:
腑に落ちました。Tier3Strategize という名前は、本来混ぜるべきでない「役割（Strategize）」と「実行者（Tier3）」を同居させていた。だからビルダーは役割名だけに絞り、誰にやらせるかは呼び出す側（ディスパッチャーやキュー）が決める ── という関心の分離ですね。
これは第13回で伺った「推論は関数でラップして、関数には何をして何を出力するかだけ書く、責任範囲を明確に分ける」という線と、まっすぐ繋がっています。あのときはディスパッチャーで分けた責任を、今回は名前のレベルで徹底した。
実際、第5フェーズで増えた監査も buildSelfCorrectionAuditPrompt という役割名のプロンプトとして加わっていました。
case .selfCorrectionAudit: return PromptBuilder.buildSelfCorrectionAuditPrompt(...)
case .correction: return PromptBuilder.buildCorrectionPrompt(...)
名前は「何をするか」だけ、誰にやらせるかは振り分け側 ── 新しく増えた監査も、最初からこの作法に乗って入ってきています。
速さのツケが、口元に出た
改名されたプロンプトの中身が同一か、文面も叩かれたかを照合しています
最初、雑な比較スクリプトで全ペアを照合したら「全部中身も変化」と出ました。これは私の抽出ミスを疑うべき結果（関数の境界の取り方が甘く、隣の関数まで巻き込んでいた）。実際に `OneShot` と `MainBrain` の diff を目で見ると、本文は関数名以外まったく同一でした。私の最初の比較が誤検出していただけです。抽出を正しく組み直して全ペアを再照合したところ、本文が本当に叩かれていたのは Speaker プロンプトだけ。MainBrain などの小さい差分は、関数内部で呼ぶ別関数の名前を改名に追従させた行で、文面のチューニングではありませんでした。
Speaker の叩きの方向ははっきりしていました ──「英語／ローマ字を最終出力に残すな」という指示の新設、しかも「大名 (Daimyo) のように括弧で英語原語を併記するな」という具体例つきの禁止。あわせて、話す段取りを先に立てさせる指示が内部思考に足されている。
Claude:
Speaker は「内部エンジンの計算結果を、ユーザーに自然に話して聞かせる役」ですよね。その叩きで一番尖って見えるのが、大名 (Daimyo) という具体例を名指しで禁止している箇所です。
プロンプトにわざわざ実例を埋め込むのは、抽象的なルールだけでは抑えられなかった ── 実際にモデルが「大名 (Daimyo)」のような括弧併記を出力してきたのを見て、それを潰すために具体例で釘を刺した、という順序に見えます。
この「ローマ字や英語の括弧併記を出すな」という叩きは、何か実際に困った出力を目にして入れたものですか? もしそうなら、Speaker がどういう場面でその癖を出してきたのか聞かせてください。
eNIGM4:
これは完全に僕のミスだね（笑）本来システムプロンプトに具体的すぎる例をだすと、今は良くても将来的にオーバーフィッティングがネックになって思うように動かない。最初からわかってたことでもあるが。その上で抽象化を試している時に漏れてしまったものだね。
ただこの時かっこで括ったモデルのIQの低さがかなり露呈して、たとえば織田信長について聞いたら、織田信長（Oda Nobunaga)と帰ってくるか、Oda(織田信長)みたいに帰ってきたりすることがあって正直見栄えが悪かった。
内部思考を限界まで高速化するために、英語で考え日本語で答えよ、の悪い部分がとくに顕著になってきて、ずっと悩んでいたんだ。
その結果がそれだね。
Claude:
よく分かりました。二重に腑に落ちます。
まず命名の例の方 ── あの 大名 (Daimyo) の具体例埋め込みは、設計の妙ではなく、本人いわく「ミス」。システムプロンプトに具体例を焼き込むと、今は効いても将来オーバーフィッティング（その例にだけ過剰適応して応用が利かなくなる）の足枷になる、というのは最初から分かっていた。本来は抽象的なルールで抑えたい。その抽象化を試している過程で、つい漏れて具体例が紛れ込んでしまった一行、ということですね。ここは持ち上げる箇所ではなく、本人が自分で「やっちゃった」と認める種類のもの。そのまま記録します。
そして根っこの問題が効きます ── これは Speaker 単体の小さなバグ取りではなく、「英語で考え、日本語で答えよ」という設計の根幹がはらむ副作用の表面化だった。内部思考を限界まで速くするために推論を英語でやらせている。その代償として、12B クラスの非力なモデルは、英語の思考から日本語の出力へ橋を渡すときに原語が剥がれきらず、「織田信長（Oda Nobunaga」や「Oda(織田信長)」のように括弧で残してしまう。「英語／ローマ字を出すな」の新設も、話す段取りを先に立てさせる指示の追加も、その橋渡しの綻びを塞ぐための、悩んだ末の対処だった ── 速度のための英語思考が、ちょうどこの時期に Speaker の出力品質という形でツケを見せ始めていた、という構図です。
そしてこの Speaker の叩きと対になって、思考中の表示タイトルにも一行入っていました。
} else if taskType == .speaker {
stepTitle = "Translating and restoring native terminology." // 代弁時のタイトル
}
「母国語の用語を翻訳・復元中」── まさに今話していた「英語で考えたものを日本語へ橋渡しする／ローマ字を母国語に戻す」という Speaker の仕事そのものが、画面に出る思考表示の文言にもなっている。プロンプトの叩きと、この表示が、同じ版で揃って入っていました。
手前に置いた、誤字の関所
Claude:
五段に整理された司令塔を改めて眺めると、誤字チェックが第2フェーズ ── メインブレイン（第3）や監査（第5）よりも手前 ── に置かれていました。しかも誤字の明確化で話が終わったら、監査もせず裏方にバトンタッチして打ち切る。
// 2. 誤字チェック (Typo Check)
// ==========================================
let isTypoCheckEnabled = ...
if isTypoCheckEnabled {
...
if typoRawResult.contains("[SUSPECT_TYPO]") {
...
// 誤字の明確化で終わったので、裏方にバトンタッチして終了 (AUDITなどはしない)
}
}
これは第9回で「徳永家康」の実体験から生まれた誤字検知 ──「鏡の中の犯人」でしたね。それを、こんなに手前の、ほとんど入口に近い位置に置いたのは何を優先してのことですか?
eNIGM4:
メインブレインがこの辺でもう動作限界だったんだよね。ルールを足すと機能不全になるぎりぎり。だからそのままルール化はできなくて、入れるとしたら全体起動前ってなってその位置だね。
Claude:
位置の理由が、思想ではなく物理的な限界だった、というのが効きます。本来なら「誤字かもしれない固有名は確認してから答える」というルールを、メインブレインのプロンプトに一行足せば済む話のはずです。でも、その Tier2（12B）はすでに指示を背負いきっていて、ルールをもう一つ足すと機能不全になるぎりぎりだった ── さっきの「指示を減らすほど推論が冴える」「役を分けて一個の頭を軽くする」という話と、完全に同じ壁です。
だから誤字チェックを MainBrain の中に書き込めなかった。書き込めないなら、本体が動き出す手前に独立した関所として置くしかない。第2フェーズという位置は、設計の美しさで選ばれたのではなく、「メインブレインにはもう一文字も足せない」という非力さが決めた配置だった、と。
読み方を、二つ持つ
KECHI の差分を確認しています
`Orchestrator+KECHI`（+27）に、記事の読解モードが二つ用意されていました。`fetchFactExtractionBulk`（一括読み）と、コメントで「パターンB: Tier2 アトミック読解モード（並列局地戦）」と書かれた分解読み。設定で `useTier3Extraction` を見て、`useTier3Bulk` なら一括、そうでなければアトミックに切り替わる。各 fetch 関数には `priority` 引数も足されていました。Claude:
第15回で見た KECHI は「全文を一気に読めないから章で割って拾い読みする」── 非力さへの対処としての分解読みでした。今回はそこに、Tier3 でドンと一括読みするモードが対で加わっている。同じ「読む」でも、一括で読む場面と、細かく割って並列で読む場面を、何で使い分けているんですか?
eNIGM4:
そう、Tier3一括読みとTier2分解読みだと、直列処理なら流石にTier3一括読みのほうが速かったんだよ。モデルは前にも話した通りの構成。条件もいろいろあるけど、平均するとそんな感じ。
もちろんTier2は一括で抱えるのはリスクがあるから、こればっかりは仕方ない。
だから基本はTier3一括読みをこのときは使ってたね。なければTier2だけでも頑張って読むって感じ。Tier2もなんだかんだそういうの見てるとかわいいでしょ（笑）
Claude:
腑に落ちました。第15回の「章割り Tier2 が一括を上回る」は、外から取ってきた小さなチャンクを並列で捌けたときの話。でも直列で処理させるなら、素の読解力で勝る Tier3 にまとめて投げたほうが速い。だからTier3 がいるなら一括読みが基本、いなければ Tier2 が章で割って頑張って読む、という二段構え。一括はリスクもあるが大きいモデルなら抱えきれる、12B に一括で抱えさせるのは無理がある ── 第15回「知識はサイズが正義」、第7回「でかいモデルには手が届かなかった」と地続きの、モデルの体格に応じた読ませ方の使い分けです。「Tier2 もかわいい」という言い方に、非力なモデルを無理なく働かせるための工夫を重ねてきた手触りが出ていますね。
投げっぱなしの、代償
ヘルパー以外で唯一手の入った周辺 ── VoiceManager を確認しています
`VoiceManager`（+24）に `processSynthesisQueue` が入っていました。中を見ると、LLM からテキストを「投げっぱなし」で受け取って配列に並べ、合成中フラグを見ながら1個ずつ直列に音声合成し、できた順に再生する作り。コメントに「実行中の Task ではなく、ただのテキストの配列として保持する」とあります。これまで何度も見てきた「投げる側と捌く側を分け、受け側で直列に処理する」型が、音声合成にも現れています。Claude:
この直列キュー、TaskQueue や KECHI の「投げ込んでも結局 1Mac1推論で整列させられる」という構えと、同じ形に見えます。音声合成でわざわざ「Task で投げっぱなし」をやめて、テキストの列に並べ直して1個ずつ捌く形にしたのは、何かあったんですか?
eNIGM4:
Taskで投げっぱだと、発言が前後することがあったんだよね。ほら、句読点区切りで送ってるだろ？そしたら「〇〇の件について、お調べします。」だと、「お調べします。〇〇の件について、」みたいに流れちゃって（笑）
まぁ普通に考えたらタスクぶん投げがわるいから、順序守ってねってしようとしてる感じだね。結局このときは完全に改善してなかったけど（笑）Taskだけで適当に回すのほんと良くないよね。
Claude:
実害から来ていたんですね。句読点で区切って合成タスクを投げると、Task は投げた順に終わるとは限らないから、「〇〇の件について、お調べします。」が「お調べします。〇〇の件について、」と喋る順序が入れ替わってしまう。聞いている側からすると致命的に間が抜ける。だからテキストをいったん列に並べ直して、1個ずつ順番に合成・再生する形にした ──「投げっぱなしの Task に順序は守れない、捌く側で直列に並べ直す」という、連載で何度も見てきた構えそのものです。「このときは完全には直しきれなかった」と正直に添えられているとおり、ここも綺麗な完成形ではなく、Task の投げっぱなしが生む綻びと格闘している途中の一手ですね。
整理すると
v0.5.2。zip 内タイムスタンプ（更新日）の最新は 3/23（2ファイル）、その手前に 3/22 が11ファイル、3/21 が12ファイル。規模はメイン側 65ファイル・10,759行（前の版から +0ファイル / +107行）、ヘルパー側は 10ファイル・1,213行で v0.5.1 と完全に同一。LLM に触れて 28日目。
新規ファイルがゼロで helper も同一 ── 「足す」のではなく「組み替える」版でした。動いたのはメイン側10ファイルだけ。三つの軸がありました。
ひとつめは司令塔への統合（第5フェーズ化）。v0.5.1 まで OrchestratorAnalysis に分かれていた能動的訂正（executeActiveCorrection）を廃して、メイン推論フロー OrchestratorProcess（+65）の最後に「フェーズ5＝自己監査(AUDIT)と訂正(CORRECTION)」として編み込んだ（Analysis は -83）。司令塔がコメントで明確な五段に整理され、その末尾に自分の回答を自分で見張る一段が増えた格好です。
ふたつめは、その監査の照準。第5フェーズには「ダイレクト回答のときだけ監査を実施」というガードがあり、これは処理の重さでなく回答の確からしさで線を引いた判断でした ──「重い処理（Wiki / Tier3）の答えに 12B の Tier2 の検算が優るわけがない／システムプロンプトでアテンションを食われた Tier2 の即答こそ、一番嘘をつきやすい」。だから一番危ない入口にだけ見張りを集中させる。第4回・第5回の「LLM はどうせ嘘をつく」という前提に立った検算の思想が、ここで司令塔の正式フェーズに昇格し、照準まで絞り込まれた。なお、監査官が何をどう判定するかの中核は本人が出願している特許に関わる領域なので、本連載では思想の輪郭までを概念レベルで押さえています。
みっつめはプロンプトの Tier 脱却（命名収束）。buildTier2〜 / buildTier3〜 の12対を、役割名だけの build〜 へ一斉改名。多くは純粋な改名で、本文が叩かれていたのは Speaker のみ（残りは内部で呼ぶ関数名の追従）。「プロンプトビルダーは何をする処理かだけに集中すべき／名前に実行者を限定的に振るのはおかしい」という、第13回の責任分離を名前のレベルまで徹底した動き。誰にやらせるかは振り分け側（ディスパッチャー）が決める。
その Speaker だけは命名収束とは別に、本文がチューニングされていました。「英語で考え日本語で答える」という速度のための設計の副作用 ── 12B が原語を剥がしきれず「織田信長（Oda Nobunaga」のような括弧併記を出す ── に悩んだ末の対処で、「英語／ローマ字を出すな」と段取りを先に立てさせる指示が足された。ただし 大名 (Daimyo) の具体例埋め込みは、本人いわくオーバーフィッティングを招く「ミス」で、抽象化の途中で漏れた一行。設計の妙としてではなく、正直な失敗として記録しておきます。思考表示のタイトルもこの叩きと対で更新されました。
この三つの軸を貫いて、もう一本の通奏低音が聞こえました ──「一個の頭に、多くを背負わせない」。監査で検知役と訂正役を別プロンプトに割ったのも、誤字チェックを MainBrain に書き込めず第2フェーズの独立した関所に追い出したのも、根は同じ。Tier2（12B）は指示を背負うほど推論のアテンションが削られ、ルールをもう一つ足すと機能不全になるぎりぎりだった。だから役を一つずつに割り、入口で済む判定は本体の手前に出す。設計の美しさからではなく、非力なモデルの限界が配置を決めている。
そして KECHI には読解モードが二つ用意されました。Tier3 でドンと一括読み、いなければ Tier2 が章で割って並列で頑張って読む ── 第15回「章割りが一括を上回る」は並列で捌けたときの話で、直列なら素の読解力で勝る Tier3 の一括が速い、というモデルの体格に応じた使い分け。VoiceManager にも直列キューが入り、Task で投げっぱなしにすると「〇〇の件について、お調べします。」が喋る順に並ばず崩れる、という実害を、テキストの列に並べ直して1個ずつ捌く形で抑えにかかった（本人いわく、この時点では直しきれてはいない）。
付随して、バックグラウンド処理のエンキュー責任が SummaryManager の内部へさらに集約されていました（CognitiveOrchestrator -1）。キューに積まずに監督役を直接走らせる ── 前回 v0.5.0 で聞いた「司令塔が2人いると船も山を登る」、バックグラウンドの窓口を一箇所に寄せる動きの、もう一段の徹底です。
整った配管の上に最初に乗ってきたのは、強い新機能ではなく、自分の回答を自分で見張る関所でした。しかもその見張りは「全部を点検する」のではなく「一番嘘をつく入口だけ」に絞り込まれている。一個の頭を軽くし、危ない箇所だけを狙い、投げっぱなしは直列に受け直す ── 派手さのない、しかし非力なモデルを御し続けるための整えの版。次の版では、こうして整えた司令塔とプロンプトの上で、問いの性質そのものをどう見分けて捌くのかが見えてきそうです。続けて追っていきます。それでは、また明日。
（待つから、奪うへ）←前 次→
R.E.V.I.S. 無料テスター募集中（30名限定）
この連載で追いかけている R.E.V.I.S. は、いまテスターを募集しています。枠は30名限りです。
Apple Silicon Mac でローカルLLMを動かしてみたい方は、こちらからどうぞ。