課題:「繰り返し判断業務」の構造的限界
どの事業にも、ある種の業務が必ず存在する。
「これは問題があるか?」「条件を満たしているか?」という判断を、一件ずつ人が処理し続ける業務だ。件数が増えるほど対応が追いつかなくなる。担当者が変われば判断のぶれが生じる。「誰かがやらないといけないが、増やすにも限界がある」という状態に陥りやすい。
AIで自動化できそう、という発想は自然に出てくる。実際、出てきた。
最初の試み:ノーコードAIで動かした
最初に選んだのは、ノーコードAIツール「Dify」だった。
ビジュアルでフローを組み、段階的なスコアリング判定を実装した。動いた。審査は自動化された。処理件数もこなせるようになった。「これでいける」という手応えがあった。
しかし使い込むほど、見えてくるものがあった。
限界:ノーコードで制御できなかったもの
業務上の判断基準には、例外がある。
「原則NG、ただし〇〇の場合はOK」という条件が、業務を深く理解するほど増えていく。ノーコードツールでは、この例外をプロンプトの記述だけで制御することになる。それが限界だった。
出力がぶれる。どこで何が起きているか追えない。直そうとしても、どのノードが原因かを特定するのに時間がかかる。修正が別の箇所に影響する。
ここで気づいたのは、これはツールの問題ではないということだ。AIそのものの構造的な特性だ。
LLMは確率的な出力をする。同じ入力を渡しても、毎回まったく同じ結果が返るとは限らない。これはバグではなく、アーキテクチャの仕様だ。Anthropicも公式ドキュメントに明記している。「temperature=0に設定しても、出力の完全な一致は保証されない」と。
プロンプトだけで例外ルールを制御しようとするのは、確率的な出力を決定論的に動かそうとする試みだ。構造的に無理がある。
数ヶ月かけて動かしたシステムだった。ゼロに戻すということは、その作業の全てを捨てることを意味した。それでも判断できたのは、「この設計では先がない」という確信があったからだ。直しても直しても、根本的な問題は変わらなかった。完成したシステムを捨てる判断をした。
ノーコードAIで止まっている方、構成の相談はこちらから。
再設計:「AIを信頼しない」という設計思想
新しい実装で変えたのは、ツールより設計思想だった。
キーワードは「AIを信頼しない」。AIに判断させる。でも出力をそのまま業務に使わない。
この考え方には、業界的な文脈がある。AI設計の世界では「Human in the Loop(HITL)」と呼ばれるアーキテクチャだ。AIが処理し、コードが検証し、ルールと状態を管理するのはコード側。AIは「提案」し、コードが「その提案を業務ルールに照らして確定させる」。この役割分担が業務に組み込める自動化の条件になる。
具体的には二つの層を設けた。
Layer 1:プロンプト設計
AIに正しく考えさせる。業務ルールを構造化したデータとして渡し、判断の根拠を出力させる。
Layer 2:コードによる補正
AIの出力を、業務固有のルールでコードが矯正する。「このキーワードが含まれていたら強制的に判定を上書きする」「このパターンが揃ったら一段引き上げる」という明示的なルールをコードで書く。AIが迷う箇所は、コードが確定させる。
LLMs should propose actions. Software should decide whether those actions are allowed.
——この原則を構造として実装したのが、この二層設計だ。
さらに、出力した判断をAI自身に再確認させる「自己チェック」も加えた。「あなたの判断に矛盾がないか確認してください」と問い直す、2回目のAPI呼び出しだ。
この二層構造が、ノーコードでは実現できなかった部分だった。
結果:設計を変えて何が変わったか
判断精度は大幅に向上した。
ノーコード実装と比較して、精度のぶれが明確に減った。「なぜこの判定になったか」をコードレベルで追跡できるようになり、改善サイクルも速くなった。
その後、チームの体制に変化があった。異動や退職が重なった時期がある。しかし業務は止まらなかった。自動化の設計を整えていたから、体制が変わっても継続できた。
転用:この設計はあなたの業務で使えるか
なぜ業種が違っても同じ設計が使えるのか。繰り返し判断業務には、共通する三つの条件があるからだ。
- ルールが明文化できる(「〇〇の場合はOK」と言語化できる)
- 繰り返し発生する(1回きりではなく、定期的に起こる)
- パターンがある(過去の判断の積み上げが、次の判断を改善できる)
この三条件が揃う業務なら、AIの「提案」とコードの「検証」の役割分担が機能する。
業種別:自動化できる繰り返し判断業務の例
| 業種 | 自動化できる判断業務の例 |
|---|---|
| 士業 | 相談内容の初期分類・要件の確認 |
| EC | 商品説明・規約適合チェック |
| 不動産 | 問い合わせ内容の種類と緊急度の振り分け |
| 工務店 | 見積もり対応可否の初期判断 |
| 整骨院・サロン | 予約時の症状ヒアリングと担当振り分け |
大規模言語モデル入門 [ 山田 育矢 ]
業種が違っても、判断の構造は同じだ。
まとめ
AIは使えば動く。ノーコードツールで自動化を始めることは正しい一手だ。
ただ、業務の複雑さがある一定を超えると壁が来る。判断のぶれを制御しきれなくなり、修正のコストが積み上がる。原因はAIの確率的な性質にある。同じ入力でも出力がぶれる。それはツールを変えても解決しない。
その先に必要なのは「設計」だ。AIに何を任せ、コードで何を補い、AIにどこで再確認させるか。この二層の役割分担を決めることが、業務に組み込める自動化と、動くだけの自動化の分岐点になる。
AI導入の設計から実装まで、tosakafunkでは個別相談を受け付けています。「自社の業務に使えるか知りたい」という段階からでも対応します。

