01記録の 14 件の多くは、1〜2 回の発言で測れる要求に変わっていた

記録に残る 2026 年 2 月から 9 月までの Claude とのやり取りを数えると、もやもや語を含む依頼は 14 件あった。もやもや語とは「なんか」「もっと」「かっこよく」「冗長」「わからない」のように、感じたことは伝わるが、合格の線が引けない言葉を指す。

14 件の多くは、そのままでは終わらなかった。次の 1〜2 回の発言で、数で測れる属性か、順序や数を決めた構造の要求に置き換わっていた。すべてではない。ただ、置き換えが起きた件では、AI が何を直せばよいかが言葉の上で決まった。

この回では、その置き換えを一覧にする。結論は三つある。もやもや語は最初の発言で出してよい。次の発言で「何を何に変えれば合格か」に直す。直し先は、属性か構造のどちらかにほぼ収まる。

02もやもや語の行き先は、測れる属性と、決まった構造の二つに分かれる

記録から、もやもや語と、その次に出た要求を並べる。左がもやもや語、中央がその後の発言で言い直された中身、右が置き換え先の型である。

最初の言葉その後に言い直された要求置き換え先
英語版の字を「かっこよく」字と字の間が広い。詰まった字形にする属性(字の間隔)
題が「ちょっと大きい」ポータルの題の文字を小さくする属性(大きさ)
読み上げるだけの説明は「無意味」各スライドで「なぜ重要か」「具体的にどういうことか」を語る構造(説明の順)
報告が「何を言っているのかわからない」読者の 100 人中 90 人が分かる水準にする属性(読者の水準を数で)
初見で「よくわからない」記号と造語初見の人が読めない記号と造語を残さない属性(残す数をゼロに)
原稿が「冗長」で、AI の話まで「遠すぎる」最初に問い、次に意味、7 節の順、要点 3 つ、結論、図 3 つ構造(順序と数)

属性とは、一つの値で合否が決まる性質である。字の間隔、文字の大きさ、分かる人の割合、残る記号の数がこれにあたる。構造とは、部品の順序と数である。どの話を先に置くか、節をいくつにするか、要点をいくつ挙げるかがこれにあたる。

図 1 もやもや語が要求に変わるまで
もやもや語で頼むかっこよく・冗長・わからないAI が最初の案を返す案と比べて違う所を指す属性か構造か測れる要求になる値・割合・順序・数もやもや語で頼むかっこよく・冗長・わからないAI が最初の案を返す案と比べて違う所を指す属性か構造か測れる要求になる値・割合・順序・数
記録では、この置き換えの多くが次の 1〜2 回の発言で起きていた。

03もやもや語のまま止めると、AI は推測で埋め、直しが往復する

もやもや語は、言った人の受け止め方を表す。「かっこよく」は字の性質ではなく、字を見た人の感想である。AI が直せるのは字の性質のほうであり、感想そのものは直せない。

そのため、もやもや語だけを受け取った AI は、どの性質を変えるかを推測で選ぶ。記録の 9 月の例では、英語版の字を「かっこよく」と頼んだ時点では、書体の種類を変えるのか、太さか、間隔かが決まっていなかった。次の発言で、字と字の間が広いことだと言い直され、直す性質が一つに定まった。

推測が外れるたびに、読む、違和感を探す、言い直す、という往復が 1 回増える。往復の数は、もやもや語を測れる言葉に直すのが遅れた分だけ増える。

要求の書き方を扱う技術文書も、同じ点を戒めている。NASA の要求の書き方の手引きは、「易しい」「十分な」「適切な」のような、達成を確かめられない語を避けるよう求め、達成を測る手段があるかを確かめさせる。Anthropic の評価の手引きも、「良い性能」ではなく何をどこまで達成するかを、数か一定の尺度で書くよう勧めている。

04もやもや語とは、受け手が合否を決められない評価の語である

この回では範囲を決めておく。もやもや語とは、評価を表すが、受け手がその語だけでは合格か不合格かを決められない語である。「なんか」「もっと」「ちょっと」「センス」「冗長」「わからない」が典型である。

もやもや語は悪い言葉ではない。違和感があることを最も早く伝える合図である。問題になるのは、合図のまま次の発言まで残ることだけである。

置き換え先は、記録ではおおむね四つの形に分かれた。

1

見た目の属性

値を一つ決める

字の間隔、文字の大きさ、行の長さ。「広い」「大きい」を、どちらに動かすかで言う。

2

読み手の水準

割合で言う

「わからない」を、100 人中何人が分かればよいかに直す。

3

残してよい数

上限を決める

説明のない記号や造語を何個まで許すか。多くはゼロにする。

4

並びと数

順序を決める

「冗長」「遠い」を、何を先に置き、節や要点をいくつにするかに直す。

この範囲に入らないものもある。AI が使った言葉の意味が分からないとき、たとえば契約や処理の方式を指す専門語が出てきたときは、もやもや語ではない。そのときに要るのは置き換えではなく、意味を聞くことである。

05資材審査の指摘でも、「強い」「わかりにくい」を測れる言葉に直すと AI に任せられる

製薬企業の資材審査でも、もやもや語はよく出る。「表現が強い」「わかりにくい」「有効性と安全性のバランスが悪い」。人どうしなら、経験を共有しているので、これで通じることがある。AI には通じない。

AI に資材の下読みや書き直しを任せるなら、同じ指摘を属性か構造に直して渡す。「強い」は、どの文のどの形容詞・副詞が、添付文書や試験成績のどの記載を超えているか、に直せる。「バランスが悪い」は、安全性の情報を有効性と同じ紙面に、同じ大きさで置く、という並びと属性に直せる。「わかりにくい」は、想定する読み手と、その何割が分かればよいかに直せる。

直した言葉は、審査の担当者どうしでも使える。指摘の根拠が測れる形で残るので、作成者に差し戻すときも、なぜ直すのかを説明しやすくなる。

06違和感は比べる物があって初めて言葉になるので、置き換えは 2 回目に起きる

記録で置き換えが「次の 1〜2 回の発言」で起きていたことは、次のように説明できる。最初の依頼の時点では、比べる物がない。違和感はまだ、何かが違うという感覚でしかない。

AI が最初の案を返すと、比べる物ができる。字が並んだ画面、仕上がった原稿、読み上げの音声である。それを見て初めて、「間が広い」「前置きが長い」のように、どこがどう違うかを言える。

図 2 2 回目の発言の分かれ道
最初の案を見て違和感が残るもやもや語を繰り返すもっとかっこよく違う所を属性で言う字の間隔を詰める違う所を構造で言う問いを先に、要点は 3 つ最初の案を見て違和感が残るもやもや語を繰り返すもっとかっこよく違う所を属性で言う字の間隔を詰める違う所を構造で言う問いを先に、要点は 3 つ
繰り返すと AI の推測が増え、往復が続く。属性か構造で言えば、直す性質が一つに定まる。

このことから、最初からもやもや語を消そうとする必要はない。消そうとして依頼が遅れるより、もやもや語のまま出して最初の案を受け取り、それと比べて言い直すほうが早い。大事なのは、2 回目の発言をもやもや語で繰り返さないことである。「もっとかっこよく」を 2 回言っても、AI の推測が増えるだけである。

Anthropic の指示の書き方の手引きは、文脈を知らない同僚に依頼文を見せ、迷うようなら AI も迷う、と書いている。2 回目の発言は、その同僚が迷わない言葉で書く。

07明日からは、2 回目の発言で「何を何に変えれば合格か」を言う

手順は四つある。

  1. 最初はもやもや語のまま出す。違和感を言葉にできるまで依頼を止めない。
  2. 最初の案と比べ、違う所を一つ指す。画面のどこ、原稿のどの段落かを決める。
  3. 属性か構造かを選ぶ。属性なら値か割合、構造なら順序か数で言う。「何を何に変えれば合格か」の形にする。
  4. 置き換えの対応を書き残す。「かっこよく → 字の間隔を詰める」のように、自分のもやもや語と行き先を一覧にしておく。次からは最初の発言で使える。

自分で置き換えられないときは、AI に手伝わせてもよい。「この依頼のあいまいな語を挙げ、それぞれ測れる言い方の候補を二つずつ出して」と頼めば、属性と構造の候補が返ってくる。どれを選ぶかは自分で決める。

図 3 置き換えの一覧を育てる手順
もやもや語で出す案と比べて一つ指す何を何に変えれば合格か対応を一覧に残すもやもや語で出す案と比べて一つ指す何を何に変えれば合格か対応を一覧に残す
一覧に残った置き換えは、次の依頼では最初の発言から使える。
Key Points ── 持ち帰る 3 つ
  1. 記録では、もやもや語を含む依頼 14 件の多くが、次の 1〜2 回の発言で、測れる属性か、順序と数を決めた構造の要求に変わっていた。
  2. もやもや語は言った人の受け止め方を表すので、そのままでは AI は推測で直す。測れる言葉に直すのが遅れた分だけ、往復が増える。
  3. 最初はもやもや語で出してよい。最初の案と比べて違う所を指し、2 回目の発言で「何を何に変えれば合格か」を言い、その対応を一覧に残す。
結語

この連載の第 1 回から第 9 回は、字の間隔、段の並び、読者の水準、語の意味など、一つひとつの置き換えを扱ってきた。14 件を並べると、それらは同じ形をしている。違和感を最初の発言で出し、AI の案と比べ、次の発言で属性か構造に直す。言語化とは、もやもや語を使わないことではなく、もやもや語を 2 回目まで持ち越さないことである。

出典·参考文献
  1. NASA. Appendix C: How to Write a Good Requirement. NASA Systems Engineering Handbook. https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/
  2. Anthropic. Define success criteria and build evaluations. Claude Developer Platform Docs. https://platform.claude.com/docs/en/test-and-evaluate/define-success
  3. Anthropic. Prompting best practices. Claude Developer Platform Docs. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
この回の材料 運営者(2023 年 3 月から生成 AI を使用)が 2026 年 2 月以降に Claude と交わした依頼と判断の記録を匿名化し、個別の事情を外して「型」として一般化しました。発言の引用はしていません。出典に挙げたのは、型の背景を確かめるための公開資料です。