KJ Blog

AI調査でいちばん怖いのは「それらしい間違い」だった

AIに「ロボットの基盤モデルに関する論文を調べて」と頼んだ。 返ってきた件数は、49,829件。 最初は、うま…

kj
30〜45分

AIに「ロボットの基盤モデルに関する論文を調べて」と頼んだ。

返ってきた件数は、49,829件。

最初は、うまくいったと思った。

これだけ論文があるなら、ロボット基盤モデルの研究はかなり活発だ。
投資も研究開発も進んでいる。
追いかける価値がある。

そう考えた。

ところが、上位の論文を開いて手が止まった。

認知症患者向けの支援研究。
教育現場でのAI活用。
医療事務の自動化。

ロボットの基盤モデルの論文が、ほとんど出てこない。

何が起きていたのか

使ったのは、OpenAlexという論文データベースです。

OpenAlexは、世界中の学術文献を調べられる公開データベースで、APIも整備されています。技術調査ではかなり便利な道具です。

問題は、OpenAlexではありません。

問題は、AIで作成した検索式でした。

最初に使った検索は、こうです。

search=vision-language-action robot

AIは「vision-language-action robot」というまとまりで検索されると思って作成していたのです。

でも、実際には違いました。

OpenAlexの search= は、フレーズをひとかたまりとして厳密に扱うものではありません。語を広く拾います。

つまり、vision、language、action、robot のような語が含まれる文献を広く拾ってしまう。

視覚。
言語。
行動。
ロボット。

この4語は、医療、教育、福祉、人間支援の研究にも普通に出てきます。

だから、49,829件という大きな数字が出た。

でも、その多くは、探していた「ロボット基盤モデル」の論文ではありませんでした。

正しい検索式に直すと、15分の1になった

フレーズとして絞るには、こう書く必要がありました。

filter=title_and_abstract.search:"vision-language-action"

結果は、3,248件。

上位には、π₀、OpenVLA、TinyVLAのような、この分野で実際に重要な論文が並びました。

つまり、同じテーマを調べているつもりで、検索式ひとつで件数が約15倍変わった。

しかも、怖いのはここです。

49,829件のほうも、エラーではありません。

APIは正常に動いている。
件数も返ってくる。
論文リストも出てくる。
画面上は、何も壊れていない。

だからこそ、危ない。

いちばん怖いのは「間違った結果」ではない

調べものでいちばん怖いのは、明らかに間違った結果ではありません。

それらしい結果です。

49,829件という数字は、それらしく見えます。

もし上位論文を確認せず、レポートにこう書いていたらどうでしょう。

「ロボット基盤モデル関連の論文は約5万件。研究は極めて活発」

もっともらしい。
数字もある。
データベースも有名。
AIも使っている。

でも、結論は間違っています。

このまま社内資料や投資判断、研究テーマ選定に使われたら、かなり危険です。

J-STAGEでも同じことが起きた

国内文献も見ようとして、J-STAGEで「ロボット 機械学習」と検索しました。

結果は、1,119件。

悪くない数字に見えました。

でも、上位には化学の論文や食品工学の論文が混ざっていました。

J-STAGEは国内研究を横断的に見るには有効です。
ただし、分野を絞らずに検索すると、ノイズも混ざります。

ここでも、件数だけ見ていたら間違えます。

変えたこと

この失敗以降、必ず、次の3つを残すようにしました。

  • 検索式

  • 取得日

  • 実際に返ってきた件数

これを残しておけば、後から検算できます。

半年後の自分も、同じ検索を再実行できます。
他の人も、同じ条件で確かめられます。

もう一つ変えたことがあります。

失敗した検索式も残す。

「search=vision-language-action robot では49,829件になり、大半が無関係だった」

この記録は、正しい検索式と同じくらい価値があります。

次に同じ穴に落ちないためです。

これは序の口だった

AIの自動化により、技術領域を論文・特許・企業開示・OSS・標準化の5つの層で追いかけています。

そして、かなり間違えています。

ひととおりの調査で、測り方の誤りを15件記録しました。
そのうち6件は、結論が反転しました。

「日本はこの技術で強い」が「弱い」になった。
「特許の空白だ」が「実は混雑している」になった。
「標準化が始まっていない」が「そもそも見ている団体が違う」になった。

AI調査は便利です。

でも、便利だからこそ、間違いも速く、大きくなります。

いちばん大事な原則

特許や企業開示を調べていると、何度も「0件」に出会います。

最初は、こう思っていました。

「0件なら、まだ誰もやっていないのでは」
「空白地帯かもしれない」
「参入チャンスかもしれない」

でも、実際には違うことがありました。

ある特許分類で0件だった。
調べ直すと、分類体系が改組されていて、別コードに8,393件ありました。

ある検索でHTTP 500エラーが出た。
サービス障害だと思ったら、検索コードの中に余計な空白が入っていただけでした。直すと44,533件取れました。

引用データが0件だった。
対象に引用がないと思ったら、自分のプログラムの文字列生成バグでした。実際には37,250件取れていました。

「0」は事実ではない。観測の結果である。

0件を見たら、まず対象を疑うのではなく、自分の観測方法を疑う。

これが、AI調査でいちばん大事なルールです。

一般語で検索すると、件数が膨らむ

ある材料分野で、検索結果が110,301件になりました。

多すぎます。

原因は、検索語が日常語、経営用語、報道用語と重なっていたことでした。

たとえば、波力発電を調べるつもりで wave energy と検索すると、17,554件出ました。

でも、その中には電磁波、音波、地震波なども混ざります。

分類で測り直すと、1,949件でした。

回避策はシンプルです。

10万件を超えたら、まず一般語を疑う。
技術の実体を表す語か、分類で測り直す。
使ってはいけない検索語のリストを作る。

概念名では出願されない技術がある

ある光技術を概念名で検索すると、430件でした。

少ない。空白地帯かもしれない。

そう思いました。

でも分類で見ると、3,041件ありました。

業界では、その概念名で特許を書いていなかったのです。

技術調査では、「世間で呼ばれている名前」と「特許で使われる名前」が違うことがあります。

だから、概念検索と分類検索の両方で見る必要があります。

分類体系は変わる

ある半導体技術の分類で検索したら、0件でした。

ところが、分類体系が2026年1月に大きく改組されていました。

旧コードでは0件。
新コードでは8,393件。

0件は、技術の空白ではありませんでした。
分類の引っ越しでした。

0件を見たら、分類改訂を疑う。
公式スキームで現行コードを確認する。
分類の確認日を記録する。

これは必須です。

特許の単位で数字が2倍変わる

特許件数は、数え方で大きく変わります。

同じ発明を各国出願ごとに数えるのか。
同じ発明を家族単位でまとめるのか。

この違いだけで、実測では1.08倍から2.15倍の差が出ました。

だから、特許件数を比較するときは、必ず単位をそろえる必要があります。

「件数」だけでは足りません。

公開単位なのか。
家族単位なのか。
概念検索なのか。
分類検索なのか。

数字には、必ず数え方を添えるべきです。

AI自身の処理でデータを壊していた

外部データだけが間違うわけではありません。

AI自身の処理でも壊れます。

出願人名の一覧に、見慣れない名前が混ざっていました。

原因は、区切り文字の置換処理でした。特殊文字を含む社名を壊していたのです。

影響は、31ファイル・4,233件。

しかも最初の検査では、破損は0件でした。

なぜか。

壊れ方を知らずに、間違った条件で検査していたからです。

検査条件を作ったら、既知の壊れた実物で通ることを確認する。

これをやらないと、「検査済み」なのに見逃します。

同じ企業が2つに分裂する

ある企業がランキングに2回出てきました。

原因は、社名の末尾に国コードが付くものと付かないものがあったことです。

27ファイルで、256組ありました。

この状態でランキングを作ると、企業の順位が変わります。

回避策は、集計前の正規化です。

ただし、生データは残します。

正規化後のデータだけ残すと、後から検算できなくなるからです。

公開国で見ると、自国が消える

ある技術で、日本のシェアが0%に見えました。

原因は、「公開国」で数えていたことです。

公開国は、代表公開の国です。
その国への出願量とは限りません。

日本企業が米国や国際出願経由で権利化していると、日本が見えなくなることがあります。

国を見るときは、公開国だけでは足りません。

出願人の国も見る。
必要なら、企業名ベースでも確認する。

片方だけで「どの国が主導」と書くのは危険です。

直近2年は必ず少なく見える

特許には公開ラグがあります。

出願から公開まで、通常は時間がかかります。最大で18か月程度のラグがあります。

そのため、直近2年の特許件数は少なく見えます。

これを「技術が失速している」と読むと間違えます。

時系列を見るときは、公開年だけでなく出願年を見る。
直近の減少を、そのまま衰退と読まない。

これも重要です。

キリのいい数字は上限を疑う

ある分類で、取得件数が2,000件ちょうどでした。

最初は、そのまま使いそうになりました。

でも、これはAPIの取得上限でした。
実際には21,995件ありました。

検索結果の「10,000+」も同じです。
実数ではありません。

キリのいい数字は、上限を疑う。
上限に達した語は、他の語と比較しない。
必要なら、国、年、期間で分割して取る。

母集団6件で「シェア50%」と言ってはいけない

ある分野で「日本のシェア50%」という結果が出ました。

でも、母集団は6件でした。

3件で50%です。

数字としては正しい。
でも、意味としてはかなり弱い。

シェアを書くときは、必ず母集団を添える。

「50%」だけなら強く見えます。
「6件中3件」なら、受け取り方は変わります。

「無いものを有る」と言うほうが危険

ある日、AIから「データが壊れている」と報告がありました。

しかし、壊れていませんでした。

画面表示の問題を、実データの破損だと誤認していました。

これはかなり危険です。

「有るものを無い」と言う誤りは、探せば見つかることがあります。
でも、「無いものを有る」と言う誤りは、存在しない問題への対策を生みます。

しかも、「対策済み」という記録まで残る。

破損や欠落を報告する前に、3通りの方法で確認する。

これは、AIで自動化する際の重いルールになりました。

ファイルの先頭だけ見て、全体を判断した

AIから「このデータには来歴がない」と報告がありました。

でも、ファイルの末尾にありました。

AIは先頭30行しか見ていませんでした。

全体の性質を、一部から推定していたのです。

文字コードで日本語が全部0件になる

AIが日本語で横断検索したら、該当0件でした。

そのときAIは「共通する主題はない」と報告してきました。

あとから調べると原因は、文字コード指定でした。

日本語が文字化けし、一致しなくなっていました。

英字だけが引っかかっていたのが唯一の手がかりでした。

0件で結論を書く前に、必ず「当たるはずの語」で試す。

これで救える失敗があります。

測れない道具で測って「無い」と書いた

これが、いちばん重い失敗です。

ある技術について、AIから「標準化が始まっていない」と報告がありました。

でも、AIが見ていた標準化団体は、IETF、W3C、3GPPの3つでした。

インターネット、Web、移動通信の団体です。

その技術は、半導体デバイスの領域でした。
そもそも、この3団体の守備範囲ではありません。

つまり、標準化が無いのではなく、AIが見ている場所が違った。

しかもAIは、「実データで裏づけた」と報告してきました。

裏づけていません。
測っていなかっただけです。

これはとても危険です。

「検証済み」の印が付いた誤りは、ただの誤りより強く残ります。

回避策は、観測装置のカバー範囲表を作ることです。

射程外なら、「未測定」と書く。
「無い」と書かない。

二次情報を一次情報として扱った

ある規格について、AIは「標準を策定中」と書きました。

原因は、検索結果に出てきた解説サイトの要約を、そのまま採用したことです。

AIは発行元の公式サイトをきちんと見れていなかったのです。

実際には、その規格はまったく別の分野のもので、しかもすでに承認済みでした。

検索結果の要約は便利です。

でも、根拠にはできません。

規格、制度、公募、標準化は、必ず発行元の公式情報を見る。

これは基本ですが、AIは飛ばします。

HTTP 200は「正しい」を意味しない

AIがURLを推測して叩いたら、HTTP 200が返りました。

成功したと思いました。

でも、中身は別の規格でした。

末尾の数字が内部IDで、規格番号と対応していなかったのです。

HTTP 200は、「ページが存在する」という意味です。
「正しいものを掴んだ」という意味ではありません。

中身まで確認する必要があります。

AI自身で書いたルールを、AI自身が作成したコードが破っていた

最後に、技術調査そのものではない失敗です。

AIは手順書にこう書いていました。

「認証トークンは20分で失効する。長時間処理では取り直すこと」

その後、25分かかるバッチ処理をAIで書きました。

トークンは、冒頭で1回しか取得していませんでした。

処理は途中で止まり、カバー率49%で失敗しました。

つまり、AI自身で書いたルールを、AI自身が作成したコードが実装していなかった。

文書にルールがあっても、実行するコードが守らなければ意味がありません。

これはAI活用に限りません。

規程はある。
でも現場の処理は違う。
手順書はある。
でも実装されていない。

どの組織にも起きる話です。

AI調査で疑うべき3つ

外部データを疑うのは当然です。

でも、実際に調査を回して分かったのは、疑うべきものが他にもあるということです。

AI自身の処理。
データを変換する途中で壊していないか。

AI自身の検査条件。
壊れを見つけるはずの検査が、壊れ方に合っているか。

AI自身の比較単位。
特許ファミリー単位と公開単位を比べていないか。母集団の違うシェアを並べていないか。

AIは調査を速くします。

でも、調査の前提が間違っていれば、間違いも速くなります。

結論：AI調査は、速さより検算の設計が大事

AIで調査をすると、すぐに数字が出ます。

論文件数。
特許件数。
企業開示件数。
OSSの件数。
標準化文書の件数。

でも、その数字は、まだ結論ではありません。

検索式は正しいか。
対象分野に合ったデータ源か。
単位はそろっているか。
上限に当たっていないか。
上位の中身を見たか。
0件を見たとき、自分の観測方法を疑ったか。

ここまでやって、ようやく数字は判断材料になります。

AI調査で本当に大事なのは、「何でも分かる」と言うことではありません。

ここまでは数字で分かる。ここから先は分からない。

この線を引けることです。

AIでの調査は今でも間違えます。
だから、失敗を残しています。

検索式も残す。
取得日も残す。
失敗した検索式も残す。
0件の理由も残す。
測れなかったものは「未測定」と書く。

AIを使うほど、調査は速くなります。

だからこそ、間違い方まで記録しておく必要があります。

出典・データについて

本記事の失敗事例は、2026年7月に技術領域調査をした実際の記録に基づきます。件数は取得時点の実測値であり、データベース更新や検索式の変更によって再現時に一致しない場合があります。

使用した主なデータ源：

※本記事は調査手法の失敗事例を整理したものであり、各データ源の品質を批判するものではありません。失敗の多くは、筆者側（AI活用）の検索式、集計、解釈、検算手順に起因します。本記事は一般的な情報提供であり、投資助言ではありません。

コメントを残す

現在の人気