はじめに — 「もっともらしさ」という落とし穴
AI と一緒に文章を書いたり、設計を評価したり、人物像を整理したりしていると、推論が静かに「ありそうな型」へ引き寄せられていく瞬間があります。事実と矛盾はしていない、それなりに筋が通っている、でも現場の手触りからはズレている、そういう推論です。
私はこれを同じ週のうちに3回経験しました。題材も粒度もまったく違うのに、ミスの構造はほとんど同じです。1つ目は記事を書いていてシニア層の生活時間を取り違えました。2つ目はある社内構想を評価していてボトルネックを取り違えました。3つ目は反復回数から働き方を推論して、本人像を取り違えました。
たて続けに同じ型を踏んだので、これは個別のうっかりではなく、AI と協業するときに構造的に起きるパターンだと判断しました。この記事は、その3連続事例を素材に、「ありそうな型に収束する推論」をどう疑い、現場照合をどう工程化するかを書きます。コードは出てきません。AI と一緒に何かを書いたり評価したりする人への俯瞰した気づきです。
なお、私はプロダクトマネージャー（PdM）として AI と協業して開発を進めていて、本記事に登場する推論は私が AI に出させた一次推論と、それを現場照合で覆した経緯です。AI 批判の記事ではなく、AI を使い倒すための作法の記事として読んでください。
ケース1: 平日昼問題 — 役所イメージからの外挿
最初のケースは、コーポレートブログの記事執筆中に起きました。「自治会に若い世代が参加しない理由」というテーマで初稿を書いていたとき、AI と一緒に進めていた構成案に「情報が平日昼に偏る」という主張が入りました。働いている世代は平日昼の会合に出られない、だから入口から外れていく、という筋立てです。
文章としては自然でした。読み手も違和感なく通すだろうと思いました。ところが、その記事を書く前に「現場照合6問」の工程に通したところ、自治会理事として現場にいる自分自身の感覚からすぐに訂正が出てきました。
実際の時間設計はこうでした。理事会は平日夜19時に開かれています。これは仕事を持つ世代にとって、保育園のお迎えや夕食準備の時間と完全にぶつかります。一方、イベントは休日に開かれています。今度は家族の予定と競合します。「平日昼に偏る」という外形像とは違うところで、働く世代は時間軸ごと締め出されていました。
開発日記には、この推論ミスについてこう残しています。
初稿の「情報が平日昼に偏る」は、典型的な役所・組織イメージから外挿した外形的にもっともらしいシナリオ。実際は「平日夜19時の理事会＋休日イベント」で、むしろ働く世代を別の形で外していた。
外形のもっともらしさという表現が鍵です。「自治会＝平日昼の会合」は、自治会という言葉から連想される役所・組織イメージのテンプレに引き寄せられた推論でした。事実とは違うけれど、初見の読者にも違和感なく通る。だから訂正の機会を逃すと、そのまま記事として世に出てしまう種類のミスです。
似た構造のミスは、それ以前の記事執筆でも繰り返し起きていました。「春先の引き継ぎ」を「段ボールに資料を詰める作業」として描いた草稿、「紙の連絡網」を「順送りで回す」という想定で書いた段落。どれも実際の運用とはズレていて、現場照合で訂正されています。型の中身は違いますが、ミスの構造は同じ「外形からの外挿」でした。
ここで生まれた仮説はシンプルです。AI の推論ミスは、ランダムに散らばらず、もっともらしさの方向に偏る。だから現場照合は「事実関係を一つひとつ確認する」というよりも、「ありそうな型をわざと疑う」という姿勢で回す方が、釣果が大きい。
ケース2: ボトルネックの取り違え — 文書に残る事実への過信
2つ目のケースは、別の日に、ある未公開の社内構想を AI と評価していたときに起きました。詳細は伏せます。シニアがアプリを初めて使うときの体験を改善するための、長期研究開発枠の構想で、まだ実機もなく、紙の設計書段階です。
評価のために、AI には手元の豊富な材料を渡しました。これまでの認証エラーの調査記録、登録時のバグの原因分析、ユーザーテストの観察ログ、運用ガイドの「やってはいけないことリスト」。これらをすべて読み込んだ上で、AI は次のように推論を出してきました。
「ボトルネックは認証や登録手続きの周辺に集中している。この構想を導入しても、その手前で詰まっている人を救うことにはならない。構想はボトルネックでない場所を解決する施策だ」
文書ベースでは筋が通っていました。実際、調査記録のヒット率は認証エラーが圧倒的に高く、データはそう示していました。私自身も最初は「そうかもしれない」と読み流しかけました。
ところが、これも違いました。シニアの真横に座って初回登録に伴走した自分自身の一次観察を持ち出してみると、推論が一気に書き換わりました。マニュアル通りに進んでいて、次に何をすべきかは目の前に提示されている、それでも実行に踏み出せない、という瞬間が現場にはありました。
ボトルネックは認知（次に何をすべきか分からない）ではなく、情緒（実行する瞬間の麻痺）にありました。これは認証エラーログにも調査記録にも一切残らない種類の事実です。「次に何をすべきかは分かっている、やり方も分かっている、でも踏み出せない」という瞬間は、ログの中では「ユーザーが操作を中断した」という一行にしかなりません。中断の理由までは記録されません。
この一次観察を AI に持ち込んだことで、評価の枠組みを撤回できました。構想の本質は「技術的な機能の置き換え」ではなく、「シニアの不安に寄り添い、踏み出す瞬間を支える存在」だ、と書き直しました。設計書にも、評価が撤回された経緯ごと残しました。結論だけ書き換えると、将来同じ推論ミスを繰り返すからです。
開発日記には、この経験から導かれた一般化を残しています。
AI の評価ループは手元の文書（テスト記録・設計書・運用ガイド）に深く入り込むため、文書に残らない種類の事実（その場の空気・恐れ・ためらい）が抜け落ちる。
ここで効くのは、データの量を増やすことではありません。データを増やしても文書に残らない種類の事実は埋まりません。「これは文書に残る種類の事実か、それとも現場でしか観測できない種類の事実か」を、推論の前に必ず問う。後者だと判断したら、現場経験者の一次観察を取りに行く工程を挟む。これがケース2から得た拘束条件です。
ケース3: 人の働き方の解釈違い —成果物は両方の解釈を許す
3つ目のケースは、対人推論で起きました。同じ日の延長で対話していたとき、私自身の働き方を AI にコミット履歴や反復回数から推論してもらっていました。
材料はこうです。コーポレートページのレイアウト調整が16ラウンド、住民向けチラシが12ラウンド、ロゴ修正が4回。どれも公開前の磨き込みで、外から見ると完成にずいぶん時間をかけているように見えます。
ここから AI は「磨き切る完璧主義タイプ。完成しないと出せない罠に陥りやすい」という人物像を提示してきました。データに矛盾はしていなくて、コミット履歴をそのまま素直に読んだ推論です。
ところが、これは自分の実感とは違っていました。読みながらすぐに訂正の言葉が浮かびました。
完璧に作らないと出せない人間ではない。まず世に出して反応を見たい。ダメと分かるのも無駄ではない。
同じ反復回数が、まったく違う解釈を許していました。自分の実際の働き方は「出して反応を見て直す」で、反復は完璧主義の証拠ではなく、フィードバックに当てながら回した結果でした。コミット履歴という成果物は、その両方の解釈と完全に整合します。どちらが正解かは成果物からは決定できません。
この瞬間、対話を中断して、対人推論の作法を AI と一緒に言語化しました。それを記事用に再構成したのが、次の対話です。
ZeronovaZeronovaZeronovaこの対話のあと、対人推論で成果物を一次情報扱いしないことを自分の作法として明文化しました。本記事の素材になっている開発日記にも、次の一文を残しています。
人の働き方・性格を成果物から推論するときは、本人の自己報告を一次情報、成果物を曖昧な傍証として扱う。
ここで効くのも、データの精緻化ではありません。同じデータが正反対の解釈を許す、という性質そのものへの理解です。
3つのケースに共通する構造
事例の中身はそれぞれバラバラです。記事の表現、構想の評価、対人推論。題材も粒度も違います。それでもミスの構造は同型でした。整理するとこうなります。
- AI が一次推論を出す（事実と矛盾しない、もっともらしい）
- 文書ベースで詰めると、推論はそれなりに筋が通る
- ところが現場の一次情報や本人の自己報告と突き合わせると、推論がズレている
- ズレ方は「ありそうな型」の方向に偏っている
ケース1の「平日昼」は役所・組織イメージのテンプレに、ケース2の「ボトルネックは認証」はテスト記録の集計に、ケース3の「磨き切る完璧主義」はコミット履歴のパターンに、それぞれもっともらしく引き寄せられていました。どれも事実関係そのものは正確で、でも事実の解釈が型に収束しています。
なぜそうなるかは、構造的に説明がつきます。AI の推論は、手元にある文書・データ・パターンを使って、もっとも自然な接続を組み立てます。「もっとも自然な接続」は、定義上「もっともありそうな型」に近づきます。これは性能の問題ではなく、推論というプロセスがそもそも持っている重力です。
だから、「もっともありそうな型」を疑う工程を、推論の外側に置く必要があります。AI の中に組み込むよりも、人間の側のワークフローに組み込む方が確実です。
現場照合の回し方 — 3つの拘束条件
この3連続事例から、自分の作業に組み込んだ拘束条件を3つ書きます。順番が大事で、上から効きます。
拘束条件1: 「ありそうな型をわざと疑う」を工程に入れる
AI の一次推論を読むとき、「これは事実か」をチェックするだけでは足りません。事実関係には誤りがないことが多いからです。代わりに、「この推論は、自治会・役所・組織・スタートアップ・マネージャー職・シニアといった単語のテンプレ像に引き寄せられていないか」をチェックします。
引き寄せられている疑いがあれば、「この型の逆を仮置きしたら、どこに矛盾が出るか」を試します。ケース1なら「平日昼ではなく平日夜だったら？」を仮置きしてみる。逆を置いて辻褄が合うなら、最初の推論は型の重力で偏っていた可能性が高いです。これが「ありそうな型をわざと疑う」工程の中身です。
「事実確認」より「型の逆を試す」方が、推論ミスの釣果が大きい、というのが3連続事例で得た一次データです。
拘束条件2: 「文書に残る事実か、残らない事実か」を必ず問う
推論の対象になっている事実が、文書に残る種類なのか、それとも現場でしか観測できない種類なのかを、推論の前に必ず分類します。
文書に残る事実というのは、ログ・コミット履歴・調査記録・運用ガイド・テスト結果のような、明示的に記録される情報です。AI はこれに強い。
文書に残らない事実というのは、ためらい・恐れ・空気・反復の理由・選択の動機のような、その場で観測しないと消えてしまう情報です。AI はこれに弱い。ログには「中断した」しか残らず、「なぜ中断したか」は残らないからです。
ケース2の「踏み出す瞬間の麻痺」は典型的に後者でした。テスト記録をいくら読んでも到達できない種類の事実です。後者と判断したら、現場経験者の一次観察を取りに行く工程を、推論を確定させる前に挟みます。
拘束条件3: 人の解釈は本人に当てる
人の働き方や性格や動機を成果物から推論するときは、成果物を一次情報扱いしません。本人の自己報告を一次情報、成果物を曖昧な傍証として扱います。
順序としては、成果物から仮説を立てるのは構わない。ただし仮説を確定させる前に、本人に当てる工程を必ず挟む。「データがこう示すから、あなたはこういう人だ」と AI が断じる前に、本人にその仮説を見せて反応を見る。
これはケース3で得た拘束条件ですが、対人推論に限らず、「本人だけが知っている解釈の手がかりがあるすべての推論」に転用できます。ユーザーの行動推論、共同開発者の意思決定背景、プロダクトオーナーの優先順位、いずれも本人にしか書けない解釈の層があります。
なぜ「もっともらしさ」は静かなのか
最後に、3連続事例の通底する性質について書いておきます。
「ありそうな型」への収束が厄介なのは、それが静かに進むからです。明らかに間違った推論なら、読み手も書き手も即座に止められます。ところが「ありそうな型」の推論は、初見の読者が違和感なく通してしまう種類のもっともらしさを持っています。AI も人間も、止める動機が弱い。
ケース1の「平日昼」も、現場照合の工程がなければ初稿のまま記事になっていました。記事として世に出ていたら、初見の読者の多くは違和感を持たずに通したでしょう。それくらい自然です。間違いだと気づけるのは、現場を実際に運用している人だけです。
ケース2の「ボトルネックは認証」も同じです。テスト記録のヒット率を集計すれば、誰がやっても同じ結論に到達します。現場で踏み出せない瞬間を観察した人だけが、その推論を覆せます。
ケース3の「磨き切る完璧主義」も、コミット履歴という共有資産を見れば誰でも到達できる人物像です。本人だけが、自分のコミットがどういう動機で打たれたかを知っています。
静かなミスは、もっともらしさの陰で蓄積します。事故にはなりにくいけれど、コンテンツ・設計・対人関係のどこかで、ゆっくりと現場とのズレを生みます。だから、推論を「面白い」「鋭い」と褒める前に、上の3つの拘束条件で疑う工程を、自分のワークフローに先に組み込みます。
おわりに — 同じ週の3度を1記事にした理由
この俯瞰した気づきは、1つの事例だけからは原則化しませんでした。1つ目の「平日昼問題」は、現場照合で訂正された瞬間に「AI の外形推論ミス」として開発日記に書きましたが、まだ個別の事例として扱っていました。
2つ目の「ボトルネックの取り違え」が起きたとき、別の領域で同じ構造のミスを踏んだので、これは個別ではなく型だと判断しました。
3つ目の「磨き切る完璧主義」で対人推論まで同じ型が出たとき、現場照合を3つの拘束条件として明文化できました。同じ週に3度同じ型を踏まないと、自分のワークフローに組み込む覚悟は固まりませんでした。1度や2度だと「次は気をつけよう」で済ませてしまうからです。
AI と協業して何かを書いたり評価したりする人へ、伝えたいのはここです。1度のミスは事故、2度のミスは偶然、3度のミスは構造です。3度目を踏んだら、その日のうちにワークフローを変える。「ありそうな型をわざと疑う」工程を、AI の中ではなく自分の手元に置く。これが本記事の唯一伝えたいことです。
自分が書いた文章や評価が「もっともらしい」と感じたとき、それは静かなアラートかもしれません。アラートのうちに、現場に当てに行く工程を入れてください。
Zeronova（呑名 健造）
PdM × AI-Native Builder × Senior UX × Civic Tech
Web/IT業界19年以上・20以上のWebサービスを担当した PdM。コロプラ子会社（株式会社ビジプル）元代表として事業経営を経験。現在はシニア向け BtoC プラットフォームの PdM、かんたん連絡網合同会社（自治会DX）・Koship合同会社の共同代表として ZERONOVA LAB を並行運営。