連載「carb-icr 規制日誌」· 第4編/全4編
根拠は、買って確かめる
孫引きをやめて、原典を開く(提出編 4)
「これの根拠は?」と聞かれて、ネットの孫引きで済ませていませんか。出典を本で買って該当ページを開いたら、もっと適切な出どころが見つかりました。根拠を現物で確かめる地味な一手の話を、一緒に。
連載「carb-icr 規制日誌」· 第4編/全4編
孫引きをやめて、原典を開く(提出編 4)
「これの根拠は?」と聞かれて、ネットの孫引きで済ませていませんか。出典を本で買って該当ページを開いたら、もっと適切な出どころが見つかりました。根拠を現物で確かめる地味な一手の話を、一緒に。
何かを「これはこういう手順に基づいています」と書くとき、その手順の出どころを、自分の目で開いて確かめたこと、どれくらいありますか。ネット上の要約や、誰かの引用の、そのまた引用。いわゆる孫引きで済ませてしまうこと、正直、少なくないと思います。私も、あやうくそうなりかけました。
前回までで、窓口を選び、機能で割り、事例に重ねて、「医療機器ではない」という整理を組み立てました。最後に残ったのは、その整理の足元——根拠です。なかでも1つ、自分の目で確かめていない出典が混じっていました。
私のアプリの集計には、1つの決めごとがあります。糖質をインスリン単位で割る比を集計するとき、食前と食後の血糖の差が一定の範囲(±30 mg/dL)に収まった食事だけを使う、というものです。比がうまく合っているかを見るための、よく知られたやり方に沿っています。
この「±30」にも、当然、根拠が要ります。どこから来た数字なのか。AIに尋ねると、ある洋書の名前とISBNを、すらすらと、もっともらしく返してきました。最初、私はそれをそのまま様式の出典欄に書きました。書けてしまった。
AIの返事は、いつもよどみがありません。それらしい体裁で、すっと差し出してくる。その滑らかさに、つい「合っているのだろう」と乗ってしまう。けれど、流暢であることと、正しいことは、別です。よどみなく出てくるからこそ、確かめる手間を飛ばしたくなる——そこが、いちばん危ないところでした。
けれど、手が止まりました。これは役所に「根拠です」と差し出す紙です。その本の、そのページに、本当にこの記述があるのか——自分で1度も開いていない本を、根拠として書いていいのか。動くと言われたコードを、画面を見ずに「できた」と言うのと、同じ気持ち悪さがありました。
それで、本を買いました。取り寄せて、届いて、読みました。
すると、思っていたのと少し違いました。AIが挙げた本にも、近い話はあった。けれど、別の本のほうが、まさにこの±30の手順を、比を検証する正式な方法として、はっきり書いていたのです。「正確な比なら、食事のあと、血糖は開始時の±30 mg/dL以内に戻る」。探していたのは、これでした。出典を、こちらの本に差し替えました。
ついでに、もう1つの土台も確かめました。糖質をインスリン単位で割る、その比そのものの定義です。これは国内の学会がまとめた指導書に当たり、該当のページに「比とは、追加インスリン一単位に対応する糖質量のこと」と、明確に載っていました。何ページのどこ、まで特定できた。出典が、書名だけのふわっとしたものから、ページまで指させるものに変わりました。
買って開くという、たったそれだけのことで、根拠の解像度がまるで変わったのです。
念のため書いておくと、これらは特別に入手しづらい資料ではありません。糖尿病の食事療法やインスリンの本として、よく知られたものです。かかったのは、数千円と、読む数時間。役所に出す根拠に、自分で確かめていない出典を1つ混ぜてしまう危うさに比べれば、ずいぶん安い保険でした。確かめないまま出して、あとで「その本にそうは書いていない」となるより、先に開いておくほうが、心穏やかでいられます。
ただ、開いたからこそ、正直に添えなければならないことも出てきました。
その本の手順は、管理された条件で行う、きちんとした検証でした。直前に追加のインスリンを打たず、炭水化物も控えた状態で、数時間かけて比を確かめる。一方、私のアプリは、同じ±30という数字を、日常のふつうの食事記録に当てているだけです。本のテストそのものではなく、その閾値を簡略に借りている。ここは、ぼかせばぼかせる部分でした。
でも、ぼかしませんでした。「本書の手順は管理下の検査だが、本アプリは同じ閾値を日常の記録に当てる簡略運用である」と、違いをそのまま書き添えた。根拠を強く見せたいときほど、都合の悪い差を隠したくなります。けれど、自分から差を明かすほうが、かえって信用される。隠した一点が後で見つかるより、最初から「ここは簡略です」と言っておくほうが、ずっと誠実で、ずっと強い。
これは、相手が役所のときには、なおさら効きます。出典を大きく見せて、あとで「その本にそこまでは書いていない」と気づかれたら、揺らぐのはその一点だけではありません。ほかの根拠まで、ぜんぶ疑わしく見えてしまう。逆に、自分から「ここは簡略です」と限界を先に示しておけば、残りの説明は、かえって信じてもらいやすくなる。正直さは、気持ちの問題であると同時に、話の通りやすさの問題でもありました。
これは、AIと一緒に作るときの、私の習慣になりつつあります。
AIは、それらしい出典をすらすら出します。書名も、著者も、番号も、よどみなく。でも、その本の、そのページに、その記述が本当にあるかどうかは、AIの記憶では保証されません。出典らしきものと、確かめた出典は、別物です。前者をそのまま信じて差し出すと、一番大事な根拠のところで、足をすくわれかねない。
実際、今回もそうでした。AIが挙げた本は、まるきり的外れだったわけではありません。近い話は載っていた。けれど、いちばんぴたりと来る本は、別にあった。AIの出力は、出発点としては役に立ちます。当たりをつけ、探す範囲をぐっと狭めてくれる。ただ、そこが終点ではない。出発点を終点と取り違えないことが、任せ方のこつでした。
だから、人に見せる根拠になる部分こそ、最後は自分が現物と突き合わせる。コードなら動かして画面を見るのと同じで、引用なら、その本を開く。手を動かして確かめるところまでが、AIに任せた作業の、人の側の持ち場でした。判断し、確かめるのは人。実装し、下書きするのはAI。その分担の最後の一マスが、この「現物を開く」だったのです。
根拠は、現物で確かめる。とくに、誰かに「これが根拠です」と差し出すものは。
もしあなたが、何かの手順や数字を引用しようとしているなら——1つでいいので、孫引きをやめて、原典を開いてみてください。開くと、思っていたのと少し違うこともあります。今回の私のように、もっと適切な出どころが見つかることも。たしかに手間はかかります。本を1冊買うお金も、読む時間も要る。でもその一手で、自分の言葉に、ぐらつかない足元ができます。
確かめるときは、そのページに語が載っているかだけでなく、前後の一文まで読むのがおすすめです。同じ言葉でも、文脈が変われば意味はずれます。「載っていた」で安心せず、「自分が言いたいことと、同じことを言っているか」まで見る。そこまでして、はじめて根拠になります。
この4回、窓口を選び、機能で割り、事例に重ね、根拠を確かめてきました。派手な技術の話は、1つもありません。けれど、個人が作った小さな道具を、胸を張って人の前に出すために要ったのは、こういう地味な手つきの積み重ねでした。怖い相手だと思っていた制度は、近づいて、分けて、重ねて、確かめてみれば、ちゃんと話のできる相手だった。
相談の答えは、まだ待っているところです(2026/6 現在)。返ってきたら、その先で見えたことを、またここに書きます。