抽象的な話を先にする理由
この記事は、過去のAI関連の記事に比べると抽象的な内容になる。具体的な操作方法やツールの紹介ではなく、「そもそもAIをどこに使うか」を判断するための考え方を書く。
以前の記事では、AIに業務ルールを渡すときの書き方や、業務ルールの棚卸しについて書いた。
→ 中小製造業がAIに業務ルールを渡すとき、書き方より大事な3つのこと
→ 中小製造業の「みんなでAI」に必要なのは、RAGではなく業務ルールの棚卸し
これらは「AIをどう使うか」の話だった。この記事はその手前にある、「そもそもAIを使う場所かどうか」を考えるための視点になる。抽象的ではあるが、この視点があると使いどころの判断がブレにくくなると思う。
業務の大半は「変換」でできている
中小製造業の事務作業を観察すると、ほとんどが「変換」で成り立っていることに気づく。
受注データを生産指示に転記する。見積の数字を請求書のフォーマットに移す。Excelの集計結果を月次報告のテンプレートに貼り付ける。入力と出力で情報の量は変わらず、形式だけが変わる。
この種の作業は、VBAやGAS、あるいは既存のシステム間連携で十分に自動化できる。ルールが明確で、入力に対して出力が一意に決まるから、プログラムで書けば100%同じ結果が返る。
こういう作業にAIを使うのは、コストに見合わない。AIは毎回微妙に違う出力を返す可能性があるし、そもそも確定的な処理には確定的な道具を使うのが筋になる。
AIの出番 ── 圧縮・展開・翻訳
では、AIはどこに使うべきか。変換が「入力と出力が一意に決まる処理」だとすると、AIの出番はその逆── 一意に決められない処理 になる。
そういう処理は3つに分けられる。 圧縮 、 展開 、 翻訳 。
圧縮 は、大量の情報から少量の本質を抽出すること。過去3年分の受注データから「この得意先は毎年3月に発注が集中する」という傾向を見つける。数千行のデータが1行の判断材料に変わる。情報量が減る方向の変化になる。
展開 は、少量の入力から多くのバリエーションを生成すること。「この部品の加工手順を考えて」と投げると、複数のアプローチが返ってくる。少ない入力から多くの候補が生まれる。情報量が増える方向の変化になる。
翻訳 は、情報量は変わらないが、表現体系そのものが変わること。日本語の業務指示をソースコードに落とす、要件をSQLに組む——意味は保たれているが、自然言語の曖昧さを厳密な体系に変換する過程で判断が入る。
3つに共通するのは、入力から出力を機械的に決められないこと。そこに判断が入るから、AIの出番になる。
圧縮こそAIの本領
3つの中でも、圧縮のほうがAIの価値が出やすいと思う。
人間が膨大なデータから傾向を読み取るには時間がかかる。Excelでピボットテーブルを組んで、グラフを作って、眺めて、気づきを得る。この工程をAIに渡すと、データを食わせた瞬間に「こういう傾向がある」と返ってくる。
以前の記事で、内製DXエンジニアの道具箱としてExcel・テキストエディタ・SQL・AIの組み合わせを紹介した。
→ 中小製造業の内製DXエンジニア ── ひとりで戦うための道具箱
この道具箱の中で、AIが最も力を発揮するのが「大量のデータや情報を食わせて、少量の判断材料を出す」場面になる。SQLでデータを抽出し、AIに分析を投げて、結果を人間が判断する。この流れでは、AIは圧縮の部分を担っている。
展開は便利だが、最後は圧縮がいる
展開も便利ではある。アイデア出し、テストケースの洗い出し、文書のバリエーション生成——少ない入力から多くの出力を得られるのはAIの強みになる。
ただ、展開した結果をそのまま使えることはあまりない。
100個のアイデアを出させたら、そこから使えるものを3個選ぶ。10パターンの文書を生成させたら、最も適切な1つを選ぶ。つまり、 展開の後には必ず圧縮が来る 。展開で広げて、圧縮で絞る。このサイクルの最後は、常に人間がチェックできる量まで圧縮されている必要がある。
AIに展開させて、AIに圧縮させて、最後だけ人間が確認する——という多段階の使い方もできる。しかし、最終出力が人間のチェック能力を超えている使い方は、今の段階ではどれも危うい。
翻訳 ── 表現体系が変わる場所
「このExcelのA列を、この形式に変換するマクロを書いて」と伝えると、AIは数十行のVBAコードを返す。やりたいこと（意味）は保たれているが、自然言語からプログラミング言語へ、表現の体系が丸ごと変わっている。
これは冒頭で書いた「変換」とは違う。受注データを生産指示に転記する変換は、入力と出力が一意に決まる。しかし「こういう処理のマクロを書いて」という指示に対して、コードの書き方は一通りではない。エラー処理をどこまで入れるか、変数名をどうつけるか、処理の順番をどう組むか——指示には書かれていない部分を、文脈や慣習から判断して埋める必要がある。
この「曖昧さを解消する判断」が入るかどうかが、変換と翻訳の境界線になる。ルックアップテーブルで引けるなら変換。テーブルでは引けず、判断して埋める必要があるなら翻訳。翻訳にはAIが使える。
同じことは、SQLを書くときにも起きる。「先月の得意先別の売上を出して」という一言から、どのテーブルをJOINして、日付の区切りをどう取って、集計単位をどうするかを判断してクエリを組む。意味は保たれているが、表現体系が変わり、その間を埋めるのに判断が要る。
VBAやGASはなくならない
AIがどれだけ発達しても、変換の領域はVBAやGASのほうが適している。この棲み分けはむしろAIが発達するほどはっきりする。
AからBに決まったルールで変換する作業に、毎回AIを呼ぶのは無駄になる。確実に同じ結果が返る処理には、確実に同じ結果を返す道具を使うべきで、AIはその道具ではない。
変わるのは、VBAやGASを誰が書くかという部分。先ほど書いた翻訳がここで効いてくる。日本語で指示を出せばAIがコードを返す。自動化の道具自体は残るが、道具を作るコストが下がる。
以前の記事で、AI時代のDXエンジニアの価値は業務理解・問題分解・指示・検証に移ると書いた。
→ AI時代の内製DXエンジニア ── 「全部読む確認」から「テストで検証」へ
これを道具の観点で言い換えると、 どの工程にどの道具を使うかを判断すること 自体が価値になる。変換にはVBA、圧縮・展開・翻訳にはAI——この仕分けができることが、道具を使いこなすということだと思う。
最初の問いは「出力は一意に決まるか」
業務改善を考えるとき、AIを使うかどうかで迷ったら、まず「この作業で、入力から出力は一意に決まるか」を問うといい。
入力から出力が一意に決まるなら、それは変換。プログラムで自動化すればいい。情報量が減るなら圧縮、増えるなら展開、表現体系が変わって判断が要るなら翻訳。この3つがAIの使いどころになる。
実際の業務は混ざっている
もちろん、実際の業務はこんなにきれいに分かれない。
たとえば積算業務。「仕様を入れたら金額が出る」という全体像だけ見ると、変換に見える。しかし中を開くと、圧縮と変換が交互に入っている。決まった板厚から材料費を計算するのは変換——単価×面積の掛け算。耐圧と板厚の対応表があるなら、そのルックアップも変換になる。しかし、コスト・納期・在庫・過去のトラブルを総合して板厚や工法を決める場面は、テーブルでは引けない。複数の要因を重み付けして1つの判断に落とす——これが圧縮になる。選んだ方法で工数を掛け算するのは、また変換に戻る。
粒度を粗く見ると変換に見える業務でも、分解すると圧縮が混ざっている。この「見えない圧縮」こそ、ベテランの判断と呼ばれている部分になる。逆に、分解して圧縮が1つも出てこない業務は、本当にプログラムだけで完結する。
だから、積算全体をAIに任せるよりも、判断（圧縮）の部分だけAIに聞いて、計算（変換）はPythonやVBAで回すほうが筋がいい。AIのハルシネーションが入り込むのは判断の部分だけに限定され、計算は狂わない。全部AIにやらせると、判断も計算も一緒くたになって、どこで間違えたかわからなくなる。
以前の記事で「AIは計算が苦手。計算はスクリプト、判断はAI」と書いたが、あれも結局、変換と圧縮を分けるという話だった。
どちらが外側か ── プログラムとAIの混ぜ方
積算のように変換と圧縮が交互に出てくる業務では、プログラムとAIを組み合わせて使うことになる。そのとき、プログラムの中でAIを呼ぶのか、AIの中でプログラムを呼ぶのか——どちらが「外側」になるかという問題がある。
判断基準は、手順の順番が決まっているかどうかになる。
積算の例でいえば、「板厚判断→材料費計算→工法判断→工数計算」という順番が毎回同じなら、プログラムがステップを回して、判断（圧縮）のところだけAIを呼べばいい。プログラムが外側、AIが部品になる。
逆に、前のステップの結果によって次にやることが変わるなら、ルーティング自体に判断が入る。この場合はAIが外側でステップを制御し、計算が必要な部分だけスクリプトを呼ぶほうが自然になる。
つまり、ルーティングが変換か圧縮かという問い。ルーティングが一意に決まるならプログラムが外側、ルーティングに判断が要るならAIが外側になる。
中小製造業の実務では、ほとんどの業務は手順が決まっている。プログラムが外側になるケースのほうが多いと思う。AIが外側になるのは、対話的にデータを探索するような場面——「このデータから何が見えるか」を掘り下げていくような使い方になる。
分解して、仕分けて、組み合わせる
1つの業務を「変換」「圧縮」「展開」「翻訳」に分解してみると、AIを使うべき部分とそうでない部分が見えてくる。分解したら、変換はプログラムに、圧縮・展開・翻訳はAIに仕分ける。そして手順が決まっているならプログラムを外側にして組み合わせる。
以前の記事で「AIの未来予測はどうでもいい」と書いた。AIがインフラになる方向性は確定しているから、具体的な予測より「構え」を取ることが大事だと書いた。
→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
その構えの1つが、「AIをどこに使い、どこに使わないか」を判断できるようになること。変換・圧縮・展開・翻訳という視点は、その判断のための道具になると思う。
このシリーズの他の記事：