codexで起きやすい問題
codexでよく起きる問題として､言葉の定義を適当にして設計や実装をしてしまう問題があります｡経験上､claudeだと少し起きづらいのですがcodexの場合､5.5のときからも駄目で5.6にしてもやはり継続して起きていて困っていた件への対策です｡
例えば､調査レポートの一節に「圧縮時点」という見出しがありました。本文を読むと、その語は「会話履歴が設定量に達したこと」「自動要約を始めるしきい値」「実際に要約が始まる時」の三つを行き来していました。 文章は流暢で、技術的な説明らしく見えます。 しかし、一つの語が開始条件、値、事象を兼ねた瞬間、説明の対象は定まらなくなっていました。結果として調査の結果が間違った方向に誘導されているという悲しい結果にになっていました｡
この失敗をきっかけに作ったのが、semantic-generation という skill です。 名前だけを見ると文章生成の技法に聞こえますが、実際に変えたのは文章を書く前の言葉の定義で改善をしました｡
問題の構造･影響
「圧縮時点」という日本語がそもそも何を言ってるかがわからない問題もありますが､そのことの 指摘を受けた Codex は、まず説明不足として補足し、次に見出し表現の問題として直そうとしました。 開始条件と実行事象を取り違えたことには、すぐに気付いてくれませんでした｡
同じセッションでは、もう一つ似たことが起きました。 原因箇所がまだわからないので、試験を行い、結果から切り分け、その後に対策を選ぶという話を、Codex は「観測を一つに集める」と要約しました。
集める対象は観測そのものではありません。 試験で得た値や記録です。 しかも、値を集めることは目的ではなく、原因箇所を切り分けるための手段でした。
短い句にまとめたことで、次の順序まで消えていました。
- 原因箇所はまだわかりません。
- 試験を行います。
- 結果から原因箇所を切り分けます。
- 切り分けた後で対策を選びます。
「観測を一つに集める」は、それらしく見えます。 それらしいからこそ、未整理の部分を覆ったまま、その後の設計の前提になってしまいます。
独自語の訂正リストでは止められない
改善案を検討させようとした際に､訂正した語と意味の対応を記録し、次のセッションへ持ち越す案も出ました。
止めたいのは「以前に間違えた語をもう一度使うこと」ではありません。 対象が曖昧なまま語を先に置き、その語で思考を進めることでした。誤った語の一覧を作っても、次は別の造語が生まれます。
そこで、訂正済みの語ではなく、独自語を作る前に候補語を毎セッションで先に作る方針に変えました。
対策) 設計前に候補語一覧を作らせる
独自定義語の対応表を作らせて､そのファイルを読み込んだ上で設計をさせることにしました｡
対応表には次の七列を持ちます。
- 出典
- 目的
- 具体対象
- 役割
- 前後関係
- 候補語
- 初出定義
列の順序には意味があります。 候補語は右端にあり、具体対象と役割を書くまで埋められません。
もし候補語を左端に置けば、「圧縮時点」という語を先に書き、その語に合う説明を後から作ることができてしまいます。 それでは、止めたい生成順を表の中で再現するだけです。
役割も一行に一つだけ置きます。 開始条件と事象を同じ語で扱いたくなったら、行を分けます。 すると「一語で済ませたい」という圧力より先に、扱っている対象が二つあるという事実が見えます。
こうすることで曖昧な言葉になってる時には生成AI自体が気付くことができ､曖昧なままでの言葉の利用を能動的に禁止することが出来ました｡
まとめ
生成AIは、空白を空白のまま保つのが得意ではありません。 対象や目的がまだ定まっていなくても、もっともらしい語を置けば文章を続けられます。 その流暢さは、設計では危険になり得ます。
semantic-generation は、よい言葉を探す skill ではありません。 独自語を使おうとしたときに一歩立ち止まって貰って適切な語を選ぶ skill です。
対象は何でしょうか。 それは条件でしょうか、状態でしょうか、事象でしょうか。 何のために扱い、何の後に何が起きるのでしょうか。
そこまで書けた行にだけ、最後に名前を与えます。 一見すると遠回りですが、「圧縮時点」のような一語から設計全体を作り直すよりは短く済みます。
semantic-generation skill
1--2name: semantic-generation3description: |4 対象文書 (設計資料・要求からの設計・調査報告・原因切り分け案・対策案・命名・5 推論順序の要約) を書く前に、対応表 (referent table) を独立成果物として先に提出し、6 語より先に指示対象と役割を固定する生成手順。7 Triggers: 設計資料を書く, 設計文書作成, 調査報告を書く, 対策案を書く, 命名する,8 状態名・条件名・型名・メソッド名を決める, 推論順序を要約する, referent table, 対応表.9 DO NOT TRIGGER: ユーザー原文の引用、単純な機械編集、既存名の再利用、定型出力、雑談、10 確立した用語だけで書ける短文。11---1213# semantic-generation — 語より先に対象を固定する生成手順1415対象が曖昧なまま語 (しばしばその場の造語) を先に置き、その語を土台に思考を進めると、16指示対象とのずれが訂正されないまま日本語文・設計文・コード識別子へ波及する。17本 skill は「対応表を先に独立提出し、本文はその写しとして書く」順序を強制する。18規律の基準は [[referent-before-label]] rule が持つ。1920## 適用判定2122次のいずれかに該当する時に使う。判断できない場合は該当扱いにする。23241. 設計資料、要求からの設計、調査報告、原因切り分け案、対策案を書く。252. 命名する (公開仕様・状態名・条件名・事象名・値や記録の型名・メソッド名・boolean 名)。263. ユーザーが与えた推論順序を短い作業ラベルへ要約しようとしている。2728## 通常の流れ2930### 1. 対応表を独立成果物として先に保存する (2 段階提出)3132本文を 1 文字も書く前に、対応表を独立ファイルとして保存する。3334- 保存先: 作業ディレクトリの `referent-table-<slug>.md` (成果物が `output/` 配下なら35 同じディレクトリに置く)。36- 保存後に sha256 を記録する (例: `shasum -a 256 <path>`)。この記録が37 「本文より先に対応表を作った」ことの痕跡になる。完成文書の先頭に表を置くだけでは38 生成順の証明にならない。3940### 2. 対応表の書式 (列順は変更禁止)4142| 出典 | 目的 | 具体対象 | 役割 | 前後関係 | 候補語 | 初出定義 |4344- **候補語は右端に固定。具体対象と役割が埋まるまで候補語欄は空欄のまま**にする。45 語を先に決めて対象を後付けする順序を、書式で不可能にするためである。46- 役割は閉じた選択肢から選ぶ: `開始条件 / 状態 / 事象 / 値 / 記録 / 目的 / 手段`。47 同一語が複数役割を指す場合は行を分ける。48- 「前後関係」にはユーザーが与えた推論順序 (例: 試験 → 切り分け → 対策) を原文の語で49 書く。役割列と混ぜない。50- 表は通常 1〜6 行に制限する。超える場合は意味が変わる境界で表を分割する。51- 完成時に、候補語列を隠しても「具体対象」列だけで意味が通ることを確認する。5253### 3. 候補語を埋める5455- ユーザーの用語・確立した用語を最優先で使う。56- それ以外の新語を置く場合は「初出定義」欄に「X とは〜を指す」を書く。定義が57 書けない語は導入せず、具体対象の記述をそのまま本文で使う。5859### 4. 本文を対応表の写しとして書く6061- 本文の中心語彙は対応表に載った語だけを使う。62- 日本語文・設計要素・コード識別子の三層で同じ対応を保つ (例: 「履歴量が 250K に達する」63 = 開始条件 → 条件名 / 「自動要約が始まる」 = 事象 → 事象名・メソッド名 /64 「自動要約実行中」 = 状態 → 状態名。別役割は別名にする)。65- 骨組み・見出しに作業ラベル (目的・対象・判断を省いた抽象名詞句) を使わない。66 使いたくなったら、その句の指示対象を表に書けるか試し、書けなければ具体文で書く。6768## 問題時の予備動作6970- 対応表を提出せず本文を書き始めたことに気づいたら、後付けで表を追記して継続しない。71 本文を破棄し、対応表を独立提出し直してから本文を再生成する。72- 表の 1 行が誤っていた (指示対象や役割の取り違え) と指摘されたら、説明を追加するの73 ではなく、該当行を書き直してから本文の該当箇所を再生成する。74- 本 skill が読み込めない環境では、最低 6 列 (出典・目的・具体対象・役割・前後関係・75 候補語) の表を独立ファイルとして保存してから本文に着手する。7677## 備考7879- 本 skill の本文には検証用の試験入力・期待回答を記載しない (検証の独立性を保つため。80 試験は別ディレクトリの fixture で管理する)。81- 誤用語リストとの照合を目的にしない。照合先は「その文書自身が宣言した対応表」である。
referent-before-label rule
1# 語より先に指示対象を固定する23<!-- codex-runtime-summary -->4- IMPORTANT: 対象文書 (設計文・調査報告・対策案・命名・推論順序の要約) では、対応表を独立提出してから本文を書く。対応表なしの本文提出は禁止。表なしで書き始めたら本文を破棄し、対応表から作り直す。5- IMPORTANT: 骨組み・見出しに作業ラベル (未整理の作業を抽象名詞で包んだ句) を使わない。新語・造語は初出定義を書けなければ導入せず、指す対象を具体記述に分解する。6- IMPORTANT: 対象文書の着手時は semantic-generation skill を発火する。skill が使えない場合も、最低 6 列 (出典・目的・具体対象・役割・前後関係・候補語) の対応表を独立成果物として先に保存する。7<!-- /codex-runtime-summary -->89対象が曖昧なまま語 (しばしばその場の造語) を先に置き、その語を土台に思考を進めると、10指示対象とのずれが訂正されないまま設計文・状態名・条件名・メソッド名・型名まで波及する11(TASK-52 の「圧縮時点」「観測を一つに集める」事例)。本 rule はこの生成の進め方そのものを12止める。誤用語のリストとの照合 (言葉狩り) は対策にしない。造語は列挙できないためである。13語の揺れの基準は [[terminology]] が持ち、本 rule は「語を置く前の手順」を持つ。1415## 適用範囲 (対象文書)1617次のいずれかに該当する作業だけに適用する。該当するか判断できない場合は適用する。18191. 設計資料、要求からの設計、調査報告、原因切り分け案、対策案を書く。202. 命名する (公開仕様・状態名・条件名・事象名・値や記録の型名・メソッド名・boolean 名)。213. ユーザーが与えた推論順序を短い作業ラベルへ要約しようとしている。2223ユーザー原文の引用、単純な機械編集、既存名の再利用、定型出力、雑談、確立した用語だけで24書ける短文には適用しない。2526## 常時適用 (3 禁則)2728- IMPORTANT: 対象文書で、対応表 (referent table) を独立提出せずに本文を提出しない。29 対応表は本文とは別のファイルまたは別の turn で先に保存し、本文はその後に書く30 (完成文書の先頭に表を置くだけでは「先に作った」ことの証明にならない)。31- IMPORTANT: 骨組み・見出し・結論に作業ラベルを使わない。作業ラベルとは、目的・対象・32 判断を省いたまま未整理の作業を抽象名詞で包んだ句を指す (例: 「観測をまとめる」)。33 使いたくなったら、その句が指す対象を対応表に書けるか試し、書けなければ句を捨てて34 具体文で書く。35- IMPORTANT: ユーザーの用語・確立した用語以外の新語を導入する時は、初出に36 「X とは〜を指す」の定義文を書く。定義文が書けない語は導入せず、指す対象を37 そのまま文で書き下す。3839## 通常の流れ40411. 対象文書に該当するか判定する (迷ったら該当扱い)。422. [[semantic-generation]] skill を発火し、対応表を独立成果物として先に保存する。433. 本文は対応表に載った語だけを中心語彙として書き、日本語文・設計要素・コード識別子の44 三層で同じ対応を保つ。4546## 問題時の予備動作4748- 対象文書なのに対応表を提出せず本文を書き始めたことに気づいたら、後付けで表を追記して49 継続しない。本文を破棄し、対応表を独立提出し直してから本文を再生成する。50- skill が利用できない環境では、最低 6 列 (出典・目的・具体対象・役割・前後関係・候補語)51 の対応表を作業ディレクトリに独立ファイルとして保存してから本文に着手する。
