本番ワークフローへの AI/ML 推論統合
ほとんどのエンタープライズ AI プロジェクトは、デモから本番への移行の過程で頓挫します。チームがサポートチケットの分類、法的文書の要約、マーケティングコピーの生成に GPT-4 を使うコンセプト実証を構築します。デモは機能します。経営幹部が興奮します。そしてプロジェクトはデモが答える必要のなかった質問に答えようとして数ヶ月停滞します：データはどこから来るのか？出力はどこに行くのか？AI の決定を誰が承認するのか？モデルが幻覚を起こした場合は何が起きるのか？何をしたかをどう監査するのか？見てはいけないデータにアクセスしないようにするにはどうするのか？誤った場所に機密情報を送るのを防ぐにはどうするのか？
これらは仮定の懸念ではありません。エンタープライズの生成 AI パイロットの 95% が財務的なリターンを提供できず、その理由は技術が機能しないからではありません。モデルは有能です。失敗の原因は配管です：セキュリティ管理、エラー処理、本番システムが必要とする監査証跡を伴って、AI 推論を実際にそれが動作する必要があるビジネスワークフローに確実に統合すること。
典型的なエンタープライズの対応はカスタム統合層を構築することです。エンジニアリングチームが AI モデルをデータソースに接続し、パイプラインを構築し、認証を追加し、ログを実装し、承認ワークフローを作成し、セキュリティチェックを追加するために数ヶ月費やします。統合が「本番準備完了」になる頃には、元のモデルは新しいものに取って代わられ、ビジネス要件は変化し、チームは最初からやり直す必要があります。
Triggerfish の解決方法
Triggerfish は、AI 推論をワークフローエンジンのファーストクラスのステップにすることで統合ギャップをなくします。このステップは、システムの他のすべての操作に適用されるのと同じセキュリティ適用、監査ログ、分類制御によって統制されます。Triggerfish ワークフローの LLM サブエージェントステップは後付けではありません。HTTP 呼び出しやデータベースクエリと同じポリシーフック、リネージ追跡、書き下し防止を持つネイティブ操作です。
別システムではなくワークフローのステップとしての AI
ワークフロー DSL では、LLM 推論ステップは call: triggerfish:llm で定義されます。タスク説明はサブエージェントが何をすべきかを自然言語で伝えます。サブエージェントは Triggerfish に登録されたすべてのツールにアクセスできます。ウェブ検索、MCP ツールを通じたデータベースクエリ、文書読み取り、ウェブサイト閲覧、クロスセッションメモリが使えます。ステップが完了すると、その出力はワークフローの次のステップに直接フィードされます。
これにより、統合すべき別の「AI システム」が存在しません。推論はワークフロー内部で起こり、他のすべてと同じ認証情報、同じデータ接続、同じセキュリティ適用を使用します。統合層はすでに存在するため、エンジニアリングチームはカスタム統合層を構築する必要がありません。
カスタムエンジニアリングを必要としないセキュリティ
AI ワークフローを本番化する際に最も時間がかかる部分は AI ではありません。セキュリティとコンプライアンスの作業です。モデルはどのデータを見ることができるか？出力はどこに送れるか？機密情報の漏洩をどう防ぐか？監査のためにすべてをどうログに記録するか？
Triggerfish では、これらの質問はプロジェクトごとのエンジニアリングではなく、プラットフォームアーキテクチャによって答えられます。分類システムはすべての境界でデータの感度を追跡します。モデルが分類データにアクセスするとセッション taint がエスカレーションします。書き下し防止はセッションの taint レベル以下に分類されたチャネルへの出力フローをブロックします。すべてのツール呼び出し、すべてのデータアクセス、すべての出力決定が完全なリネージ付きでログに記録されます。
顧客レコード（CONFIDENTIAL）を読み取ってサマリーを生成する AI ワークフローは、そのサマリーを公開 Slack チャネルに送れません。これはモデルが無視する可能性のあるプロンプト指示では適用されません。モデルが見ることができず、変更できず、迂回できない PRE_OUTPUT フックの決定論的なコードによって適用されます。ポリシーフックは LLM 層の下で実行されます。LLM はアクションをリクエストし、ポリシー層がそれを許可するかどうかを決定します。タイムアウトは拒否と同じです。モデルから外の世界への道で適用を通過しないものはありません。
最初から存在する監査証跡
Triggerfish ワークフローのすべての AI 決定は自動的にリネージ記録を生成します。リネージはモデルがアクセスしたデータ、それが運んだ分類レベル、適用された変換、出力が送られた場所を追跡します。これは有効化または設定が必要なログ機能ではありません。プラットフォームの構造的な性質です。すべてのデータ要素は作成から最終宛先へのすべての変換を通じてプロベナンスメタデータを運びます。
規制産業にとって、これは AI ワークフローのコンプライアンスエビデンスが初日から存在することを意味します。監査担当者は AI が生成した出力を完全な連鎖を通じて追跡できます：どのモデルがそれを生成したか、どのデータに基づいていたか、推論中にモデルが使ったツール、各ステップで適用された分類レベル、ポリシー適用アクションが発生したかどうか。このエビデンス収集は、報告層として後付けではなく適用フックに組み込まれているため自動的に行われます。
再アーキテクチャなしのモデル柔軟性
Triggerfish は LlmProvider インターフェースを通じて複数の LLM プロバイダーをサポートします：Anthropic、OpenAI、Google、Ollama を通じたローカルモデル、OpenRouter を通じたルーティングされたモデル。プロバイダー選択はエージェントごとに設定可能で、自動フェイルオーバーがあります。より良いモデルが利用可能になったり、プロバイダーが価格を変更した場合、切り替えはワークフロー定義に触れることなく設定レベルで行われます。
これは「プロジェクトが出荷前に時代遅れになる」問題を直接解決します。ワークフロー定義は AI が何をすべきかを説明し、どのモデルがそれを行うかは説明しません。GPT-4 から Claude に、またはファインチューニングされたローカルモデルへの切り替えは設定値を 1 つ変更します。ワークフロー、セキュリティ管理、監査証跡、統合ポイントはすべて全く同じままです。
Cron、Webhook、イベント駆動実行
スケジュールまたはイベントに応答して実行される AI ワークフローは、人間がプロンプトを入力する必要がありません。スケジューラーは定期ワークフロー用の 5 フィールド cron 式とイベント駆動トリガー用の webhook エンドポイントをサポートします。日次レポート生成ワークフローは午前 6 時に実行されます。文書分類ワークフローは webhook で新しいファイルが届いたときに起動します。感情分析ワークフローは新しいサポートチケットごとにトリガーされます。
スケジュールまたはイベントトリガーによる各実行は、新鮮な taint を持つ分離されたセッションを生成します。ワークフローはインタラクティブセッションとは独立した独自のセキュリティコンテキストで実行されます。cron トリガーワークフローが CONFIDENTIAL データにアクセスした場合、その実行の履歴のみが CONFIDENTIAL に分類されます。PUBLIC 分類で実行される他のスケジュールワークフローは影響を受けません。
エラー処理とヒューマン・イン・ザ・ループ
本番 AI ワークフローは失敗を graceful に処理する必要があります。ワークフロー DSL は明示的なエラー条件用の raise とタスク定義内のエラー処理を通じた try/catch セマンティクスをサポートします。LLM サブエージェントが低信頼度の出力を生成したり、処理できない状況に遭遇したりすると、ワークフローは人間承認キューにルーティングし、通知サービスを通じて通知を送り、フォールバックアクションを実行できます。
通知サービスは優先度と重複排除を伴ってすべての接続されたチャネルにアラートを配信します。AI が生成した契約修正が送信される前に人間の承認が必要な場合、承認依頼は承認者がいる Slack、WhatsApp、メール、その他の場所に届きます。ワークフローは承認が届くまで一時停止し、一時停止したところから続行します。
実際の使用例
法務部門は契約レビューを自動化したいと考えています。従来のアプローチ：アップロードされた契約からの条項抽出、リスクレベルの分類、非標準条項のフラグ付け、レビュー弁護士へのサマリー生成を行うパイプラインを構築するための 6 ヶ月のカスタム開発。プロジェクトには専任のエンジニアリングチーム、カスタムセキュリティレビュー、コンプライアンス承認、継続的なメンテナンスが必要です。
Triggerfish では、ワークフロー定義の作成に 1 日かかります。アップロードが webhook をトリガーします。LLM サブエージェントが契約を読み、重要な条項を抽出し、リスクレベルを分類し、非標準条項を特定します。検証ステップがメモリに保存された事務所の条項ライブラリと抽出を照合します。サマリーは担当弁護士の通知チャネルにルーティングされます。契約にはクライアントの特権情報が含まれるため、パイプライン全体が RESTRICTED 分類で実行され、書き下し防止により契約データが RESTRICTED 以下のチャネルに漏洩しないことが保証されます。
事務所が LLM プロバイダーを切り替える場合（新しいモデルが法律言語をより良く処理するから、または現在のプロバイダーが価格を上げたから）、変更は設定の 1 行です。ワークフロー定義、セキュリティ管理、監査証跡、通知ルーティングはすべて変更なしに機能し続けます。事務所が新しい条項タイプをリスクフレームワークに追加すると、LLM サブエージェントはパターンではなく意味を読むため、抽出ルールを書き直すことなく対応します。
コンプライアンスチームは初日から完全な監査証跡を取得します。処理されたすべての契約、抽出されたすべての条項、割り当てられたすべてのリスク分類、送信されたすべての通知、記録されたすべての弁護士承認、ソース文書への完全なリネージ付き。数週間のカスタムレポート作業が必要だったエビデンス収集が、プラットフォームの構造的な性質として自動的に存在します。