「AIなら賢くやってくれる」が3連敗した本当の理由：道具より先に、入力の型を見極めるべきだった
「この処理、AIに任せれば自動でやってくれるはず」
——そう思って試したら、3回連続で失敗しました。入力パターンを見直して道具を選び直したら、あっさり動いた話です。
「どの倉庫に入れる？」が毎回、人の頭の中で決まっている
複数の倉庫がある現場では、「どこに搬入・搬出するか」の判断は意外と複雑です。
たとえば「A品を30個、Xエリアへ搬入したい」という依頼が来たとき、担当者の頭の中ではこんな処理が走っています。
そのエリアに近い倉庫はどこか
受け入れる余力は残っているか
その倉庫は面積で借りているのか、個数単位で借りているのか
どれも一言でいえば「経験」の領域です。長年やっている人ほど素早く判断できますが、担当者が変わった瞬間に同じ判断ができなくなる。
急な依頼のたびに詳しい人を呼ぶ。これが現場の摩擦です。
「頭の中にしかない判断ロジック」をシステムに移せれば、この摩擦は減らせる。そう考えて、「自然文を入力するだけで候補倉庫を順位付けして返してくれる仕組み」を作ってみることにしました。
AIに任せて3連敗した話
最初の構想は、AIに自然文を読み取らせる、というものでした。
「搬入か搬出か」「品目名」「数量」「行き先」をAIに抽出させ、判定エンジンに渡す。理屈ではスマートです。
そこで手元で動かせるオープンソースの言語モデルを試してみました。結果は、3連敗です。
失敗1：出力に「考え中のメモ」が混入する
AIが本来出さなくていい内部の思考プロセスを、そのまま応答に混ぜてしまいました。タグで囲まれた部分が結果に残り、後続の処理が壊れてしまいます。
失敗2：フォーマットが崩れる
「このフォーマットで答えてください」と指定しても、項目名が変わったり、余計な説明文がついたりしました。毎回揺れるので、後続の処理に繋げられません。
失敗3：AIの処理ノードが空を返す
使っていたAIフロー作成ツールには、自然文を構造化する専用のノードがあります。ところが手元のモデルとの組み合わせでは、このノードがほぼ空の結果しか返しませんでした。
この時点で、「AIに自然文を任せる」という前提自体を見直すことにしました。方針を途中で捨てる判断は、正直ためらいました。でも、先に進めない道を押し続けるほうがコストが高い。そう判断した格好です。
道具を選び直して動いた仕組み
ここで立ち止まって、入力文をよく見直しました。
「○品を△個、□エリアへ搬入したい」
実はこのパターンさえ押さえれば、「搬入か搬出か」「数量」「品目」「行き先」——すべて機械的に取り出せます。
AIが本領を発揮するのは、表現が多様で文脈の解釈が必要な場面です。でも、入力パターンがある程度決まっているなら、シンプルな文字パターンの検索ルールで十分でした。
最終的に動いたシステムの流れは、次のとおりです。
ユーザーが自然文を入力する
文字パターンの検索ルールで、入力文からキーワードを抽出する
判定エンジンに情報を送る
候補倉庫をスコア順に並べた結果を受け取る
読みやすい文章に整形して出力する
この流れの中に、AIのノードは入っていません。AI活用の実験と言いつつAIを外している——意外かもしれませんが、「AIを使わないと決める」こともAI活用の一部だと思っています。
抽出の仕組み
入力文から項目を取り出す処理は、「数字のあとに『個』が来たら、その数字を数量として取り出す」といったパターンを、機械が読める形で書いたものです。少しとっつきにくい印象がありますが、定型的な入力文なら十分に機能します。
判定の仕組み
取り出した情報を判定エンジンに送ると、倉庫マスタと現在の在庫状態を読み込んで、条件に合う倉庫を点数化します。
ルールはシンプルです。
搬出なら、在庫が足りる倉庫を優先し、個数単位の契約を加点する
搬入なら、受け入れ余力がある倉庫を優先し、面積単位の契約を加点する
搬送先のエリアと倉庫のエリアが一致していたら加点する
このスコアで候補倉庫を順位付けし、第1候補と理由をセットで返します。
つなぎ方で一つはまった
技術的な落とし穴が一つありました。AIフロー作成ツールが仮想化環境の中で動いているため、「自分自身」を指すアドレスで外部の処理にアクセスしようとすると、仮想化の壁の外に出られません。仮想化環境の中からホスト側を指す専用のアドレスを使うことで、この問題は解決しました。
「知らないと確実に詰まる小さな設定」の一つです。動かしてみないと出てこない種類のハマりポイントで、手を動かす価値はここにあるなと改めて感じました。
やってみて分かったこと
良かった点
まず「動いた」という事実が大きかったです。自然文を入れると倉庫候補が返ってくる——この最小の動作確認が取れたことで、全体の設計の方向性が見えました。
AIを外したことで構成がシンプルになり、どこで何が起きているかを追いやすくなりました。ルールベースの処理はすべて明文化されているので、「なぜその結果になったのか」が見えやすいのは大きな利点です。
残った課題と、正直な失敗
入力文の揺れには、まだ対応できていません。
「Xエリアへ○品を△個入れたい」（語順が変わる）
「○品△個をXエリアへ移したい」（別の言い回し）
このような表現になると、現在の仕組みでは取りこぼしが発生します。「定型文に強い」ということは、裏返せば「揺れに弱い」ということ。ここは次の宿題です。
そしてもう一つの正直な失敗は、最初の構想段階で「AIならきっと賢くやってくれるだろう」と期待しすぎたことです。道具を決める前に、入力のパターンがどれだけ定型的かを見極める——この一手間を飛ばしたのが、寄り道の原因でした。
ところで、あなたの現場ではどうでしょうか。「AIに任せようとしてうまくいかなかった」処理の中に、実はもっとシンプルな方法で解けるものはありませんか？
明日から試せる一歩
自分の業務で「誰かの頭の中に入っている判断ルール」を1つ書き出してみる
その判断に必要な情報（何を見て、何を決めているか）を箇条書きにする
入力される情報は定型的か、毎回表現が違うか——どちらかだけでも確認する
「AIを使う前に、決まったルールだけで処理できないか」を一度考えてみる
まず動く最小構成を作ってから、複雑にしていく順番を意識する
次の一手（#AI活用100本ノック）
判定エンジンの「骨格」は出来上がりました。次は、入力文の揺れへの対応と、実データの反映です。「動く最小構成→安全にする→育てる」の順番を崩さずに進めます。
この記事が参考になったら「スキ」で教えてください。次の実験の励みになります。
同じテーマで読まれている記事
Difyで作る、書類読み取りアプリの失敗しやすいポイント全部のせ：https://note.com/clean_whale1844/n/nb49319d7c72e
「どこから何を動かす？」を毎回悩まない仕組み：GPTsで横持ち判断を型化した：https://note.com/clean_whale1844/n/n3c35e6c7c5f5
#AI活用100本ノック 進捗：61/100
次回の実験：入力文の表現ゆれに強くする抽出ロジックの改善
