先に結論
AI案件の相談を受けると、最初に出てくるのはたいてい「ユースケース」です。
請求書を自動で登録したい。問い合わせに自動応答したい。契約書をチェックしたい。
ただ、ユースケースが教えてくれるのは業務の処理フローだけです。
そのフローの中でAIが担当する箱の中身は、実データを見るまで一行も決まりません。
今回書きたいことを一言でまとめると、次の3つです。
- ユースケースは「どこにAIを置くか」を決めるだけで、「AIが何をするか」は決めてくれない
- AI部分の設計は、結局 入力は何か / 処理は何か / 出力は何か の3点に収束する
- そしてこの3点は、実データを分析して初めて確定する
プロンプトは、この3点が決まったあとに出てくる結果です。出発点ではありません。
ユースケースは「地図」であって「設計図」ではない
たとえば「請求書をシステムに登録したい」というユースケースを考えます。
処理フローはどの会社でもほぼ同じです。
受領 → 内容の読み取り → 検証 → 基幹システムへ登録 → 例外は人間へ
ここまでは、データを1件も見なくても書けます。
そして、ここまでしか書けません。
実際にサンプルを100件もらうと、たいてい次のようなことが起きます。
- PDFだと思っていたら、半分はスキャン画像で、しかも傾いている
- 取引先が80社あって、レイアウトが80通りある
- 明細行が2ページにまたがっていて、合計欄だけ2ページ目にある
- 「備考」欄に、業務上とても重要な手書きメモが入っている
- 全体の7割は同じ3フォーマットに収まっていて、残り3割が地獄
この時点で、AIに解かせるべき問題は最初の想定とまったく別物になっています。
ユースケースは変わっていないのに、です。
AI部分の設計は、結局この3つに落ちる
AIを組み込む箱の中身は、どんな案件でもこの3つに分解できます。
そして3つとも、実データの分析なしには決められません。
入力：何をモデルに渡すのか
「請求書を渡す」では設計になりません。
ページ全体の画像なのか、切り出した領域なのか。OCRのテキストなのか、座標付きのレイアウト情報なのか。
過去の取引先マスタを一緒に渡すのか、渡さないのか。
これは好みの問題ではなく、データを見て決まる問題です。
レイアウトが80通りあるなら座標情報が要るし、逆にフォーマットが3種類なら領域を切り出したほうが精度もコストも良くなります。
処理：AIに何を判断させるのか
ここが一番、実データの分析が効きます。
100件を手作業でやってみると、「7割はルールで確定できて、AIの判断が必要なのは残り3割」という構造が見えることがあります。
そうなると設計は変わります。全部をAIに投げるのではなく、AIは3割の曖昧な部分だけを担当し、残りは決定的な処理に任せる。
「AIに何をさせるか」より、**「AIに何をさせないか」**のほうが、実は難しい設計判断です。
出力：次の工程が受け取れる形になっているか
出力形式は、AI側の都合ではなく下流システムの都合で決まります。
金額は税込か税抜か。日付のフォーマットは何か。読み取れなかった項目はnullか空文字か。
確信度が低いときに「わからない」と言えるようになっているか。
ここを実データで詰めずにJSONスキーマを決めると、あとで必ず作り直しになります。
プロンプトは、この3点が決まったあとに書くもの
入力・処理・出力が定義できると、プロンプトは驚くほど素直に書けます。
逆に、プロンプトがどうしても長く複雑になるときは、たいてい原因はプロンプトの外にあります。
- 入力に不要な情報が多すぎる
- AIに任せる範囲が広すぎる
- 出力の定義が曖昧で、モデルに判断を丸投げしている
「プロンプトを改善しても精度が上がらない」という相談の多くは、プロンプトの問題ではなく設計の問題です。
そして設計の問題は、データを見ないと見つかりません。
同じことを言っている記事
この感覚は自分の現場経験だけかと思っていましたが、調べると同じ主張がかなり前から積み重なっていました。
1. Hidden Technical Debt in Machine Learning Systems（Google, NeurIPS 2015）
実世界のMLシステムのうち、実際の学習・予測コードはごく一部にすぎず、周辺のデータ依存や設定、グルーコードのほうが圧倒的に大きい、という論文です。有名な「真ん中の小さな黒い箱」の図の出典でもあります。
https://papers.neurips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf
2. "Everyone wants to do the model work, not the data work"（Google Research, CHI 2021）
53人のAI実務者へのインタビュー調査。データ品質を軽視する慣行が下流に連鎖的な障害を生む「データカスケード」を定義し、その発生率が92%だったと報告しています。データ作業が過小評価される構造そのものを扱っている点が刺さります。
https://research.google/pubs/everyone-wants-to-do-the-model-work-not-the-data-work-data-cascades-in-high-stakes-ai/
3. Andrew Ng: From Model-centric to Data-centric AI
鋼板の欠陥検出で、モデル側を改善しても精度がほぼ変わらなかった一方、データ側を改善したら大幅に精度が上がった、という有名な比較。プロジェクト時間の8割はデータ側に費やされているのに、研究の大半はモデル側を向いている、という指摘も含みます。
https://www.forbes.com/sites/gilpress/2021/06/16/andrew-ng-launches-a-campaign-for-data-centric-ai/
論じている時代もレイヤーも違いますが、結論はほぼ同じです。
効くのはモデル側ではなくデータ側で、そこが一番後回しにされる。
明日からできる5つのこと
1. サンプルは「平均」ではなく「端」をもらう
きれいな代表例を10件もらっても意味がありません。
最新のものを100件、そして「これは面倒なやつ」と現場が思っているものを別途もらいます。設計を壊すのは常に端のデータです。
2. まず自分の手で20件やってみる
AIに投げる前に、人間として20件処理してみる。
すると「取引先名がここにない場合は請求元の住所から判断している」といった、誰も仕様書に書いていない暗黙のルールが必ず出てきます。これがそのままプロンプトの中身になります。
3. 入出力のスキーマを先に固定する
プロンプトより先に、入力と出力の型を決めます。
決められないなら、それはまだデータの理解が足りないサインです。
4. AIに任せない範囲を明示的に決める
計算、突合、マスタ参照、形式チェック。決定的にできることはAIに渡さない。
AIの担当範囲が狭いほど、精度も再現性も運用コストも良くなります。
5. 失敗をカテゴリに分けて数える
「なんとなく精度が低い」では改善できません。
失敗を100件集めて分類し、件数を数えると、直すべき箇所が入力なのか処理なのか出力なのかが見えます。プロンプトの修正は、その次です。
まとめ
AIアプリ開発は、外から見るとプロンプトを書く仕事に見えます。
でも実際に時間を使っているのは、その手前です。
- どんなデータが本当に来るのか
- そのうちAIでしか解けないのはどこか
- 何を入力として渡し、何を出力として受け取るのか
- 何をAIに任せないのか
ここが決まっていれば、プロンプトは短く素直になります。
決まっていなければ、プロンプトをどれだけ磨いても精度は頭打ちになります。
AI案件で差がつくのは、プロンプトの文章力ではなく、データの解像度です。
同じところで詰まっている人がいれば、まずはプロンプトを閉じて、実データを100件開いてみることをおすすめします。