AIワークフロー
読み: AIワークフロー
AIワークフローとは業務を自動化
AIワークフローは既存の業務プロセスに人工知能を組み込み定型作業の代替から非定型データの分析や意思決定の補助までをシームレスに実行する一連のシステム基盤である。
かんたんに言うと
工場のベルトコンベアの途中に熟練の検品職人を配置するようなものである。単なる機械的な運搬ではなく流れてくる品物の状態を見て次の行き先を柔軟に変える判断の結節点となる。
ルールベースRPAの限界を突破するAIワークフローの基本概念
従来のRPAは画面の指定座標をクリックし決まったテキストを転記するだけの単純作業しかできなかった。APIでシステム間を連携させてもJSONのキー名が一つ変われば即座にエラーを吐いて停止する。とにかく脆い。
AIワークフローはここにLLMの推論能力を挟み込む。フォーマットの揺らぎや表記ゆれをAIが解釈し後続のシステムが処理できる形に整形して渡す。人間の曖昧な指示をシステムが理解できる構造化データに変換する翻訳機と言ってもいい。
ルールベースの限界を突破できるかどうかが導入の分水嶺になる。ただすべてのプロセスにAIを挟むべきかは悩ましい。コストとレスポンスタイムのトレードオフをどう評価するか。
AIが業務プロセスに組み込まれる仕組みと動作原理
データ入力から出力までの流れはシンプルである。特定のイベントをWebhookで検知しそれをトリガーとしてAIにプロンプトとデータを投げる。
例えばメール受信をトリガーにして本文から抽出した情報を基に返信文のドラフトを作成しSlackに通知を飛ばす。この一連の流れをDifyのようなプラットフォーム上で視覚的に構築していく。
裏側では複数のAPIが飛び交いプロンプトチェーンが回っている。LLMの出力は常に一定ではない。JSONで返せと指示しても余計な挨拶文を混ぜてくるモデルは山ほどある。エラー処理やリトライ処理をどう組み込むか。実務ではこの泥臭い設計で判断が分かれる。
法務と物流部門における具体的な活用事例
マーケティングや情シスばかりがAIの主戦場ではない。法務部門ではHubSpotにアップロードされたNDAのPDFをトリガーにMake経由でClaude 3.5 Sonnetに投げ自社に不利な条項や抜け漏れをチェックさせている。法務担当者はSlackに届いたアラートを確認するだけである。
物流部門ではドライバーからの雑多な音声日報をWhisperでテキスト化しZapierで受け取る。そこから車両の不具合報告と配送遅延の兆候を分類してKintoneのデータベースに格納する。
現場の担当者はAIを使っている意識すらない。裏で動く黒衣として機能させるのが正解である。ツールに使われるのではなく業務のパイプラインに溶け込ませる。
現場の落とし穴と運用フェーズの現実
現場主導でツールを導入すると必ずシャドーITの問題に行き着く。個人のクレジットカードで契約したMakeのアカウントで顧客データを回し始める営業マンが出てくる。
APIキーのハードコーディングやプロンプトインジェクションへの無防備さ。セキュリティ部門が気づいたときには手遅れになっていることが多い。
ガチガチに制限をかければ誰も使わなくなり野放しにすれば情報漏洩のリスクを抱える。どこで線を引くか。正解はない。
システムを構築して終わりではない。プロンプトのバージョン管理やモデルのアップデートへの追従など運用フェーズの泥臭い作業は続く。
当社の見解
当社ではClaude Code・Antigravity・Codexの3つのAIエージェントを日常業務で併用している。記憶を共有しているため、別のAIに同じ説明を繰り返す必要がない。ただし、記憶共有だけでは足りなかった。一方のAIが他方の成果物を勝手に修正して壊す事故が起きた。これを受けてファイル所有権制度を導入し、どのAIがどのファイルを所有するかを定義した。AIの自主性に頼らず、仕組みで上書きや巻き戻りを防いでいる。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。