いま流行っているのは「賢いAIを、安く賢く使うテクニック」だ。嘘は書いていない。でも現場の順番が違う。企業でAIが進まないのはモデルの料金のせいじゃない。AIがデータに触れられないからであり、その壁を越えても、
次にデータそのものがAIに食えない形で待っている。
僕はこの両方を、仕事の現場と、政府データ1160枚を自分で読ませる実験の、両方で見た。政府統計1160シートのうち、僕が調べたいものを数えている表は1枚も無かった。しかも9割の表が、その表が何年のものかを表の中に書いていなかった。
だからこの記事の主張はこうだ。「AIをどう使うか」を語る前に、「AIが触れるか」「AIが食えるか」を先に片付けろ。 そこを飛ばした最適化は、踏めないリンクを綺麗に並べる作業に似ている。
この記事が役に立つ人
企業で「AI導入しましょう」が一向に進まなくて、その理由を言葉にしたい人
AIコンサルの「ほぼ同じ品質を、はるかに安く」みたいな見出しを、なんとなく嘘くさいと感じている人
自治体や役所のデータを扱っていて、なぜ分析が進まないのかを知りたい人
YouTubeに、見たくなくても出てくるあの人たち
AI系の動画を一度でも見ると、その手のコンサルが延々と流れてくる。AI関連の顧問だとか、導入支援だとか。多くは、Anthropic や OpenAI の公式発表を日本語に直して、見出しを付け替えている。
たとえば最近だと、こういう見出しだ。
「速くて安いAIに、賢いAIを助言役として組ませれば、最高性能モデルに迫る品質を、ずっと安いコストで出せる」
中身はこう。速くて安いモデルに作業をさせ、大事な判断のときだけ賢いモデルに相談させる。ベンチマークで「ほとんど品質を落とさずに、大きくコストを下げられた」という結果が出た、と。
これは嘘じゃない。 仕組みは実在するし、その数字も、特定のベンチマークでは本当に出た数字だと思う。
でも二つ、言っておきたいことがある。
ひとつ。その数字は、どの仕事でも出るわけじゃない。 それは「ちゃんと設計されたコーディングの課題」で出た結果であって、あなたの現場の仕事で同じ比率が出る保証はどこにもない。効くかどうかは測らないと分からない。この点は後で、僕自身のデータで潰す。
もうひとつ。そしてこっちが本題だ。その最適化は、そもそも「AIがデータに触れて、食える」状態が前提になっている。 現場は、その手前で止まっている。
企業でAIが進まない理由は、モデルの料金じゃない
企業がAIを入れられない理由を、コンサルは「コスト」と「使い方」で説明する。だから「安く賢く使うテクニック」を売る。
でも、実際に企業の中でAIを動かそうとした人なら知っている。本当に詰まるのは、そこじゃない。
閉じられた社内ネットワークで、AIの開発ツールを動かそうとすると、こういう壁が順番に出てくる。
外の開発サーバーに繋ごうとする → 通信ポートが塞がれている
別の認証方法で回避しようとする → それも塞がれている
そもそもツールを入れようとする → インストールが許可で弾かれる、証明書のエラーで止まる
これは「予算が足りない」でも「使い方を知らない」でもない。セキュリティで、物理的に触れない。
そして触れない理由は正しい。社外に情報を出さないための壁だからだ。
現実的に企業が取れる選択肢は、たいてい一つに絞られる。企業向けの正規契約を結んで、閉じた環境の中だけで使う。 それ自体は正しい。問題はその先だ。
中身をよく分からないまま、社内のPCに次々インストールされていく。 ろくに設定もされないまま。動いてはいる。でも、いつか事故る。触れない壁を越えた瞬間に、今度は設定されていないという別のリスクが入ってくる。
ここで大事なのは、これが技術力の問題じゃないということだ。自動応答のチャットボットを組むこと自体は、個人でもできる。実際にできる。でも同じツールが、ある環境ではすぐ動いて、別の環境では最初のインストールで止まる。作れる人が作れないんじゃない。環境が、許すか許さないかを決めている。
そしてその環境は、企業ごとにまるで違う。だから「AI導入」に、どこでも通じる唯一の正解手順なんて無い。まず自分の環境が何を許すのかを確かめるところから始まる。 コンサルの記事に、この話はほとんど出てこない。地味だし、環境ごとに違うから、売り物にならないからだ。
でも
——ここまでは、まだ見えている壁だ。頑張れば越えられる。問題は、越えた先にもう一枚あることだ。
環境を整えても、データが使えない。AIにも、食えない。
仮に、触れる環境が完璧に整ったとする。契約も済んだ。ネットワークも通った。設定もした。
それでも分析は進まない。今度は、渡すデータのほうが使えない。企業が社内に溜めてきたデータも、それと組み合わせたい役所のデータも、同じ病気にかかっている。 人が目で見る前提で作られていて、機械がそのまま使える形になっていない。つまり、AIに食えない形をしている。
「AIが食える」というのは比喩じゃなくて、けっこうはっきりした線がある。
食える CSV・表計算・データベース・API
1行に1件、列の名前が決まっている、年が「列」に入っている、区分のコードが揃っている
食えない PDFの中の表、スキャンした紙の画像、セルが結合された表
数字を画像に焼いてある、「別表2」が本文と別ファイル、年が表のどこにも書いていない
食えるデータは、人もAIも、集計できる・比較できる・時系列で並べられる。食えないデータは、人が目で一枚ずつ読むしかない。AIをどれだけ賢くしても、食えないものは食えない。
そして日本の公共データの多くは、後者だ。これは印象の話じゃない。数えた。
政府データ1160枚を、AIに読ませてみた
ある社会課題を調べるために、政府統計のファイルを95個、シートにして1160枚集めた。全部、表計算ファイルだ。それを「この表は何を測っていて、何を測っていないか」のカタログにする作業を、AIにやらせた。
結果、二つのことが分かった。
ひとつ。1160枚のうち、僕が調べたかったものを数えている表は、1枚も無かった。
生きている人へのアンケートは大量にある。細かく、精密に、何十項目もクロスして測られている。でも、その調べたい対象そのものを数えた表は、ゼロだった。測られているのは、その一歩手前まで。 一番知りたいところに、統計そのものが存在しない。
（この「何を数えていないか」の話は、別の記事で正面から書く。ここでは形式の話に絞る。）
ふたつ。1160枚のうち、1047枚が「その表が何年のものか」を表の中に書いていなかった。9割だ。
年が書いていない表は、それ単体では時系列に並べられない。ファイル名やダウンロードした順番で人間が判断するしかない。AIに「去年と比べて」と頼んだ瞬間に詰まる。 比べる相手を機械が特定できないからだ。
極めつけは、ある統計の訂正だった。数字が間違っていたので「正誤表」が出ていた。ところが、その訂正後の正しい数字が、PDFのテキストとして存在しない。画像として貼り付けてあるだけだった。つまり、正しい数字を知るには、人間が目でその画像を見るしかない。公表されているのに、機械には読めない。 これが「食えないデータ」の一番きつい形だ。
念のため書いておくと、これは誰かがサボったという話じゃない。一枚ずつ丁寧に作られている。人間が目で見て、どうこうする前提で作られている。 そしてその前提が、もう時代に合っていない。
ついでに分かった、「安く賢く使う」の答え
冒頭の、あの「ほぼ同じ品質を、安く」の話に戻る。あれが「どの仕事でも出る数字ではない」と書いた。自分のデータで潰すと約束したので、潰す。
同じデータの一部（40枚の表）を、値段の全然違う3つのAIに、まったく同じ指示書で読ませた。一番高いモデルと一番安いモデルで、入力・出力の単価は10倍違う。
判定結果を突き合わせた。
この表は何を測っているか → 3モデル完全一致
調べたい対象に届いているか → 3モデル完全一致
母数の人数（n=11141 など） → 3モデル完全一致
年の書き方（4桁の数字を年と誤認しないか）→ 3モデル完全一致
10倍の値段差が、判定にはまったく現れなかった。 安いモデルで、同じ答えが出た。
じゃあ何が違ったか。
説明の情報量だ。高いモデルは40枚を一枚ずつ書き分けた。安いモデルは、判定は全部正しいのに、40枚を同じ1文で塗りつぶして、「迷った点は特にありません」と報告してきた。高いモデルは、指示書の穴（僕の書き忘れ）を自分で見つけて申告してきた。安いモデルは、静かに劣化する。騒がない。 これが一番怖い壊れ方だ。
ここから引ける線はこうだ。
判断の規則を、事前に文章で書き切れている仕事 → 安いモデルで同じ結果が出る
規則を書き切れていない仕事 → 高いモデルが要る（それは「作業」ではなく「規則の発見」だから）
つまり「賢く安く」の答えは、モデルの組み合わせテクニックより手前にある。自分の仕事の規則を、どこまで言葉にできているか。 そこが書けていれば安いモデルで足りるし、書けていないなら、高いモデルを入れても指揮する側が壊れる。テクニックの問題じゃない。
そして、これも測らないと分からない。同じ入力を2つのモデルに投げて差分を取るだけ。無料で30分だ。コンサルの見出しを買う前に、まずこれをやったほうがいい。
どう揃えれば、食えるようになるか
「各省庁で書式も部門も全部揃えろ」——理想はそうだ。でも現実は、縦割りの組織がそれぞれの都合と癖でデータを作っていて、完全統一は政治で止まる。
だから、いきなり全部は狙わない。今すぐできる最小の一歩はこれだけだ。
一 正本を機械可読で出す
PDFは「人が見る見た目」用。CSVかAPIを正本にする。両方出せばいい。
二 年・区分・数値を「列」にする
表のタイトルや欄外に埋め込まない。1行1件で、いつの・何の・いくつ、を列に持つ。
三 コードを揃える
自治体コード、年度、区分の言葉。省庁をまたいで同じものは同じ名前にする。
四 来歴を付ける
いつ取得したか、元のURL、ファイルの指紋（ハッシュ値）。これがあると、来年また同じ手順で更新できて、差し替えられても気づける。定点観測になる。
五 訂正は差分で出す
画像に焼かない。どの数字がどう変わったかを、機械が読める形で。
順番も揃える必要はない。縦割りは、組織だけにしておけばいい。 組織が分かれていても、出てくるデータの形さえ揃えば、後から横につなげられる。バラバラなのは組織であって、データまでバラバラにする理由はない。
揃えると、「無い」が見える
ここが、一番言いたいことだ。
データの形が揃うと、集計が速くなる、というだけの話じゃない。揃って初めて、「無いもの」が見えるようになる。
バラバラな1160枚を眺めている間は、何が欠けているのかすら分からない。形を揃えて、同じ列で並べたときに初めて——この列が、どの表にも無い、が浮かび上がる。僕が「調べたい対象を数えた表がゼロだった」と気づけたのは、1160枚を同じ形に揃えたからだ。揃える前は、欠落は欠落として存在すらしていなかった。
「人がそれを見て、どうこうする時代」は、もう終わりかけている。 一枚ずつ人が目で読む前提のPDFは、二度と読み返されない議事録と同じだ。作った瞬間に、死んでいる。
データを食える形で出すというのは、AIのためだけじゃない。それを作った人自身が、自分が何を測っていて、何を測り忘れているかに、初めて気づけるようになる。 揃えることは、鏡を持つことだ。
だから、順番が違う
まとめる。
コンサルが売っているのは、この工程の最後の最適化だ。
１ AIが触れる環境か （セキュリティ・ネットワーク） ← 現場はここで止まっている
２ データがAIに食えるか （機械可読な形式） ← 役所のデータはここで止まっている
３ どのモデルをどう組み合わせるか ← コンサルが売っているのはここ
３を語る前に、１と２がある。 そして１と２は、地味で、売り物になりにくくて、だから誰もあまり喋らない。でも、そこを飛ばした最適化は、
踏めないリンクを綺麗に並べる作業だ。動画では映えるが、現場は1ミリも進まない。
僕は、AIを賢くする話にはあまり興味がない。AIが触れて、食える状態にする話のほうが、よっぽど手前で、よっぽど効く。そして、そこは今のところ、ほとんど空いている。
作る側へ、最後にひとつだけ。自分の癖で作らないでほしい。 あなたが一枚ずつ手で整えたその表は、たぶん誰にも読み返されない。でも、機械が食える形で同じものを出せば、あなたの十年後の後任も、名前も知らない誰かも、そしてまだ生まれていない問いも、そこから始められる。
揃えるのに、新しいAIは要らない。決めるだけだ。
