こんにちは、パレイド技術部の橘です。
前回 (第 3 回) は、Claude Vision で 600dpi マニュアルを起こすワークフローの話でした。 46 ファイル / 200+ エントリを順に書き起こす作業を進めるうちに、マニュアル原本には書かれていないが、リファレンスとして必要不可欠な事実 が 次々と顔を出すのです。
今回はその「マニュアル外の事実」を集めた回。リファレンスの最も使える部分は、 実はここだったかもしれません。
LET は使えない
最初に発見したのが、これ。
10 LET A = 10一般的な BASIC では LET は省略可能というだけで書いてもエラーにはなりません。
ところがファミベでは ?SN ERROR (Syntax error) になります。マニュアルの代入文の
ページには LET の記載が一切なく、「書かれていないから書けない」という解釈になります。
LLM はこの暗黙仕様を知らないので、訓練データに大量に含まれる他言語 BASIC の感覚で LET A = 10 を出してきがちです。リファレンスに 「LET は使えない」と明示的に書く ことが、LLM 出力を矯正することができます。
NEXT に変数を付けるとエラー
これも頻発する罠。多くの BASIC では NEXT I のように対応する FOR 変数を NEXT に書けます。
ファミベでは NEXT 単独でなければ ?SN ERROR。
10 FOR I = 0 TO 5
20 NEXT I : REM ?SN ERROR
30 NEXT : REM これが正しいLLM はネスト構造を見ると NEXT I を付けたがります (可読性のため、訓練データの慣習)。
これも明示的に「NEXT に変数を付けるな」と LLM に伝える必要があります。
単項マイナスは実機で動く (マニュアルに記載なし)
逆方向の発見もあります。マニュアルには書かれていないが、実機・エミュで動く挙動。
10 A = 10 - 4 : REM 二項減算
20 B = -5 : REM 単項マイナス (マニュアル記載なし、動く)レビュー時に「ファミベには単項マイナスはないのでは」と疑問が出ましたが、実機で 試してみると普通に動きました。マニュアルの「演算子」ページには 減算 - の二項演算 の説明しかないので、実機検証の重要性を 示す例です。
配列は DIM 時にクリアされる
これはマニュアル明記の事実なのですが、見落としやすい。
10 DIM A(10) : REM 数値配列、要素は 0 で初期化
20 PRINT A(5) : REM → 0 (エラーにならない)
30 DIM A$(10) : REM 文字配列、要素は "" で初期化
40 PRINT A$(5) : REM → 空文字列未初期化の通常変数も同様で、数値変数は 0、文字変数はヌルストリング で初期化されるようです。LLM が他言語の感覚で A = 0: B = 0 のような初期化を 冗長に書きがちなので、これも明示しておく価値があります。
PRINT カンマは「8+8+8+4 ブロック」
マニュアル原文には「画面幅 28 文字を 4 ブロックに分けて、出力数式が各ブロックの 先頭に出力される」とあり、図には 8+8+8+4 の幅で 4 ブロックが描かれています。
PRINT "A","B","C","D"
A B C D : REM 8 文字毎にブロック先頭に揃うLLM は他言語の感覚で「カンマ区切りはスペース 1 つ」と思っていることがあるので、 ブロック揃え であることを明示する必要があります。 ちなみに連載者の検証では「6 文字間隔のように見える」場面もあり、 マニュアル記載と実装に差がある可能性として記録を残しました。
LIST のハイフンはカンマで代替可能 (マニュアルに記載なし)
これも実機検証で判明した小ネタ。
LIST 100-300 : REM マニュアル流儀
LIST 100,300 : REM 同じ意味、マニュアルに記載なし知っていると入力短縮になります。LLM には特に有用ではないかもしれませんが、 リファレンスとしては記録する価値があります。
変数 × 論理演算子はスペース必須 (マニュアル明記)
これはマニュアルに明記された規則。原文を引用すると:
注) 変数と論理演算子をつづけて書く場合は、間にスペースをあけてください。
つまり NOTX のように変数 X の前に NOT を詰めて書くと、ファミベのパーサは NO (変数 2 文字)
+ TX (別の変数 2 文字) のように解釈してしまう。NOT X と空ければ正しく解釈されます。
ただしマニュアルの規則は 論理演算子に対してのみ。算術演算子 MOD は実機検証で
10MOD3 のように詰めても動くことが確認できました。「変数の隣だけ要スペース」が
正確な実装挙動のようです。
「マニュアル外の事実」がリファレンスの中核だった
書き起こしを進めるうちに気づいたのは、LLM のコード品質を改善するのは、 マニュアル原文の引用よりも、こういう「マニュアル外の補足」の方が圧倒的に多い ということでした。
マニュアル原文は丁寧に書かれていますが、「LET は無い」「NEXT に変数を付けるな」 のような 無いものについての記述 は当然ありません。1980 年代の読者にとっては 「無いものは無い」と空気で分かったことが、LLM にとっては最大の落とし穴になります。
このため本リファレンスでは、notes_for_llm 内で **補足 (マニュアル外)**:
マーカーを必ず使い、マニュアル由来と区別して書き分ける運用にしました。
source 配列にも { type: testing } や { type: observation } を明記して、
補足の根拠も透明にしています。
次回 (最終回)
これでリファレンスは形になりました。最終回では実際に このリファレンスを system prompt に投入し、Claude にコード課題を解かせるベンチマーク に進みます。 さらにローカル LLM (Llama, Qwen, DeepSeek 等) でも同じ課題を試して、 ファミベコーディング能力の差を測ります。