動く日と動かない日を並べて AI に見せる── 症状を一語で伝えるより、動いた入力と動かなかった入力とあるべき規則の三つを渡すほうが、AI は直す場所を絞れる

01並べた瞬間に、直す場所が決まった

2026 年 3 月の記録に、短いやり取りが残っている。運営者は予定を登録する仕組みを使っていて、日付がうまく読み取られないことに気づいた。最初の指摘は、それだけだった。

その一言では話は進まなかった。次に運営者は、書き方を変えた。ある日の分は登録できる。その前日と翌日は登録できない。そして、普通はどの日付でも扱えるはずだ、と期待を言葉にした。

この二度目の伝え方には、一度目に無かったものが三つ入っている。動いた入力、動かなかった入力、そして本来あるべき規則である。三つがそろうと、AI は「読み取りがおかしい」ではなく「特定の日付にだけ合う書き方をしている」という、もっと狭い場所を疑える。

読者に持ち帰ってほしいのは、この三つの組である。AI に不満を伝えるときは、形容詞を足すのではなく、例を一つ足す。それも、動かなかった例ではなく、動いた例のほうを先に探す。

02二つの例の対は、規則の切れ目を指し示す

動かない例だけを渡すと、AI に分かるのは「ここで失敗した」という一点である。動く例を隣に置くと、情報が一点から一本の線に変わる。二つの入力の違いこそが、壊れている規則の在りかになる。

この読み方は、ソフトウェアの試験で古くから使われている。入力を、同じ扱いを受けるはずのまとまりに分け、まとまりごとに一つ試す。この分け方は同値分割と呼ばれる。そして分け目の前後は、動きが切り替わる場所なので誤りが集まりやすい。境界値分析はそこを狙って試す。

利用者が「この日は通る、この日は通らない」と書くとき、本人は試験の手法を使っているつもりはない。それでも実際にやっていることは、境界を一つ差し出すことである。

03症状を一語で伝えると、AI はその一語だけを直す

言語モデルは、渡された記述の範囲で解こうとする。「日付が読めない」と書けば、日付の読み取りだけを見る。その入力が通るように手当てして、直ったと報告する。前日と翌日は、話に出ていないので確かめられない。

この直し方の困る点は、失敗が一度では見えないことである。指摘した一つの入力は通るようになる。だから、その場では直ったように見える。同じ原因の別の入力で、後日また止まる。

不具合の報告の書き方については、公開された手引きがある。Mozilla のバグ報告の手引きは、再現の手順を最も重要な部分と位置づけ、その上で「本来どうなるはずだったか」と「実際にどうなったか」を分けて書くよう求めている。人の開発者に向けた要求だが、相手が AI でも要求は変わらない。むしろ、AI は画面の向こうを見ていないので、書かれていないことは存在しないに等しい。

04そろえるのは三つ、それに確かめ方を足して四つ

この回で言う「例で示す」とは、次の四つを一度に渡すことである。長い文章は要らない。四行で足りる。

この型が向かない場面もある。毎回は起きない不具合、まだ作っていない機能、好みの問題である。毎回は起きないなら、まず起きる条件を探す作業が先に来る。好みの問題なら、例ではなく手本を見せたほうが早い。

逆に、この型がよく効くのは、一部の入力だけ通る症状である。日付、言語、区分、桁数、書式。こうした「種類がある入力」で一部だけ通るときは、ほぼ例外なく、書き方が特定の種類に寄っている。

05資材審査でも、通った資材と止まった資材を並べると基準が言葉になる

製薬企業の資材審査で AI に下見をさせるとき、同じ問題が起きる。「この判定はおかしい」とだけ書くと、AI はその一件の判定を変える。基準そのものは変わらないので、次の似た資材でまた同じ判定が返る。

代わりに、二つの資材を並べる。同じ表現を含みながら審査を通った資材と、止まった資材である。そして、この二つを分けている条件は何か、と問う。AI が挙げた条件が、審査担当者の頭の中にあった基準と一致するとは限らない。一致しないとき、食い違っているのは AI の判定ではなく、担当者がまだ言葉にしていなかった条件のほうである場合が多い。

この使い方には、記事の前の回で触れた話がつながる。審査の個人差は、判断そのものより、判断の根拠を言葉にできているかの差として現れる。動いた例と動かなかった例を並べる作業は、その根拠を外に出す作業でもある。出た条件は、そのまま次の資材の確認の材料になる。

注意も一つある。社内の資材を例として AI に渡せるかどうかは、会社の規程で決まる。渡せないなら、実際の資材ではなく、表現の型だけを取り出して作った例で同じことをする。

06一部の入力だけ通る不具合は、書式の決め打ちから生まれる

なぜ、ある日付は通って別の日付は通らないのか。原因はたいてい単純である。日付という文字の並びを解釈する部分で、想定した書き方が一通りしかない、という状態である。

日付の書き方は、もともと国や場面でばらつく。RFC 3339 は、インターネットでやり取りする日時の書き方を定めた文書だが、その中で「10/11/1996」という並びは国によって解釈が違うため、世界でのやり取りには全く適さない、と述べている。年・月・日の順に四桁の年で書くことを求めているのは、この食い違いを消すためである。ばらつきがあるということは、どれか一つだけを想定した書き方は、必ずどこかで外れる。

外れ方が「一部だけ」になるのにも理由がある。米国立標準技術研究所が 1999 年から 2004 年にかけて行った調査によれば、ソフトウェアの不具合の大半は、一つか二つの条件の組み合わせで起きており、三つ以上が絡むものは急に少なくなる。条件が一つか二つなら、その条件を満たす入力だけが落ちる。全体が止まるのではなく、一部だけが落ちる。

この調査からは、試し方の指針も出ている。すべての組み合わせを試さなくても、二つの条件の組み合わせを網羅すれば、検出できる不具合の数はほとんど変わらない。利用者が動く例と動かない例を一組出すことは、その網羅の入口を人の手で一つ開けることにあたる。

07指摘の前に、動いた例を一つ探す

明日からの手順は四つである。

1. まず動く例を探す。不満を書く前に、期待どおりに動いた入力を一つ見つける。見つからないなら、それは一部の不具合ではなく、全体が動いていない。
2. 近い失敗例を選ぶ。動いた入力と一箇所だけ違う入力を選ぶ。差が小さいほど、AI が疑う場所は狭くなる。
3. 範囲を一文で書く。「どの日付でも」「どの言語でも」と、満たすべき範囲を言い切る。ここを省くと、例だけを通す直しが返る。
4. 直ったと言える条件を先に渡す。指摘した入力と、その前後と、端の値。この三種類で動いたときに直ったとする、と先に決める。

この四つは、AI の側の作法とも合っている。Anthropic が公開しているプロンプトの手引きは、例を示すとき、実際の使い方に近く、端の場合を含み、互いに違いのある例を三つから五つ入れるとよい、と勧めている。指摘のときに渡す例も同じである。似た例を並べても、示せる境界は一つも増えない。

最後に、この型は AI のためだけのものではない。動いた例を探す作業をすると、自分が何を期待していたのかが、自分にも初めて言葉になる。その言葉が無いまま「何かおかしい」と伝え続けると、返ってくるのは、おかしさを一つずつ埋める継ぎ足しの直しだけである。