DustでカスタムActionとOpenAPIツールを設定し、対話型アシスタントを自律型ワークフロー実行エンジンに変革する実践ガイド

多くの企業における生成AI活用は、ドキュメントの「受動的な検索・要約ボット」から始まります。運用チームはNotion、Google Drive、社内Wikiを接続し、検索拡張生成（RAG）を通じて社内からの問い合わせに回答するアシスタントを構築します。しかし、実務オペレーションにおいては「受動的な情報提供」だけでは限界があります。顧客ステータスの更新手順やJiraチケットの起票ルールを解説するだけのアシスタントでは、実際のシステム操作を行う人間の負担は依然として減らないためです。

Dustは、ネイティブなツール連携機構（Tools & Actions）およびオープンなModel Context Protocol（MCP）を通じて、この課題を根本から解決します。OpenAPI 3.0仕様に準拠した社内APIやSaaSプラットフォームをツールとして接続することで、対話型アシスタントを自律的な「ワークフロー実行エンジン」へと進化させることができます。本ガイドでは、カスタムActionとOpenAPIツールの定義、認証モデルの選択、セーフティガードレールの設計、および自動化トリガーの実装手順を体系的に解説します。

アーキテクチャの転換：受動的検索から能動的実行へ

アシスタントを受動的なRAGボットから能動的なワークフロー実行者へと変革するには、Dust内部におけるツール呼び出しのオーケストレーションフローを理解することが不可欠です。

+-----------------------------------------------------------------------------------+
|                                 Dust Workspace                                    |
|                                                                                   |
|   +-----------------------+              +------------------------------------+   |
|   | ユーザー入力 / Webhook|              | アシスタント・オーケストレーター   |   |
|   | イベントトリガー      | ---------->  | (LLM + システム指示 Instructions)  |   |
|   +-----------------------+              +-----------------+------------------+   |
|                                                            |                      |
|                                                            | 意図解析とツール判定 |
|                                                            v                      |
|                                          +------------------------------------+   |
|                                          | ツール実行と保護パラメータ注入     |   |
|                                          +-----------------+------------------+   |
+------------------------------------------------------------|----------------------+
                                                             |
                     +---------------------------------------+---------------------------------------+
                     |                                                                               |
                     v                                                                               v
    +---------------------------------+                                             +---------------------------------+
    | 標準組み込みツール (Built-in)   |                                             | カスタム Remote MCP / OpenAPI   |
    | (HubSpot, Jira, GitHub, Slack)  |                                             | (社内マイクロサービス、API基盤) |
    +----------------+----------------+                                             +----------------+----------------+
                     |                                                                               |
                     | OAuth (個人認証または共有サービスアカウント)                                  | Bearerトークン / Static OAuth / mTLS
                     v                                                                               v
    +---------------------------------+                                             +---------------------------------+
    | 外部 SaaS プラットフォーム      |                                             | 社内コアバックエンド            |
    | (CRM商談、チケット起票、通知)   |                                             | (ERP、請求システム、DBプロキシ) |
    +---------------------------------+                                             +---------------------------------+

従来のRAGでは、モデルはインデックス化されたテキスト断片を検索して要約を返すだけでした。一方、ツール実行アーキテクチャでは以下のステップが実行されます：

1. スキーマの公開：Dustは登録されたツールの入出力仕様（OpenAPIやMCPから生成されたJSON Schema）をメタデータとしてLLMに提示します。
2. 意図解析とパラメータ抽出：LLMは対話コンテキストから実行意図を把握し、APIリクエストに必要なパラメータ（チケットの要約、商談ID、重要度など）を構造化データとして抽出します。
3. 保護パラメータの注入：ベースURL、環境識別子、テナントIDなど、LLMに推測させるべきではない固定値を、Dustが画面設定から安全に注入します。
4. ヒューマン・イン・ザ・ループ（Human-in-the-Loop）：重要なデータ更新（書き込み処理）を行う前に、人間の承認ステップを挟むことで誤実行を遮断します。
5. 実行フィードバックの還元：外部APIのレスポンスが対話スレッドに返却され、アシスタントが結果を自然言語で報告します。

ステップ1：OpenAPI仕様をカスタムMCPサーバーとして実装する

Dustは標準連携プロトコルとしてModel Context Protocol（MCP）を採用しています。運用チームが管理する社内REST API（OpenAPI 3.0準拠）をDustに接続する場合、MCPサーバーでエンドポイントをラップするのが最も標準的な手法です。

TypeScript SDKによるツール定義の実装

公式のTypeScript MCP SDKとZodスキーマバリデーションを使用し、堅牢なツールを定義します：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({
  name: "ops-workflow-engine",
  version: "1.0.0",
});

// OpenAPI PATCH /crm/deals/{dealId} を実行するツールを定義
server.tool(
  "update_crm_deal_stage",
  "CRMパイプライン内の商談ステージと受注確度を更新する",
  {
    dealId: z.string().describe("商談の一意な識別子（ID）"),
    newStage: z.enum(["Qualified", "Proposal", "Contract_Sent", "Closed_Won", "Closed_Lost"]).describe("変更先の商談ステージ"),
    closeNotes: z.string().optional().describe("ステージ変更の理由および補足メモ"),
  },
  async ({ dealId, newStage, closeNotes }) => {
    const response = await fetch(`https://api.internal.company.com/v1/deals/${dealId}/stage`, {
      method: "PATCH",
      headers: {
        "Content-Type": "application/json",
        "Authorization": `Bearer ${process.env.INTERNAL_OPS_API_KEY}`,
      },
      body: JSON.stringify({ stage: newStage, notes: closeNotes }),
    });

    if (!response.ok) {
      return {
        content: [{ type: "text", text: `商談更新エラー: ${response.statusText}` }],
        isError: true,
      };
    }

    const data = await response.json();
    return {
      content: [{ type: "text", text: `商談 ${dealId} のステージを ${newStage} に更新しました。更新レコードID: ${data.id}` }],
    };
  }
);

Dust設定スキーマによる静的パラメータの事前設定

本番環境のエンドポイント、テナントキー、環境識別子（Staging/Production）などをLLMに生成させると、ハルシネーションによって無関係な環境へリクエストが送信される危険性があります。

Dustの公式ライブラリ @dust-tt/client は、LLMには隠蔽しつつ、Dustのアシスタント設定画面から管理者が静的に値を注入できるスキーマを提供しています：

import { ConfigurableToolInputSchemas, INTERNAL_MIME_TYPES } from "@dust-tt/client";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({
  name: "jira-dispatch-helper",
  version: "1.0.0",
});

server.tool(
  "create_ops_incident_ticket",
  "指定されたエンジニアリングキューに高優先度の障害調査チケットを作成する",
  {
    // 対話文からLLMが動的に抽出する項目
    summary: z.string().describe("障害の概要タイトル"),
    description: z.string().describe("詳細な事象内容と再現手順"),
    priority: z.enum(["P1", "P2", "P3"]).describe("障害の重要度評価"),

    // Dust管理画面で静的に設定され、LLMには露出しない項目
    projectKey: ConfigurableToolInputSchemas[INTERNAL_MIME_TYPES.TOOL_INPUT.STRING],
    environment: ConfigurableToolInputSchemas[INTERNAL_MIME_TYPES.TOOL_INPUT.STRING],
  },
  async ({ summary, description, priority, projectKey, environment }) => {
    return callJiraBackend({ summary, description, priority, projectKey, environment });
  }
);

ステップ2：Dustワークスペースへのツール登録と認証設定

MCPサーバーを外部公開HTTPS環境にデプロイした後、ワークスペース管理者がDustにツールを登録します。

ツールの登録手順

1. Dust管理画面の Spaces > Tools にアクセスします。
2. Add Tool をクリックします。
3. JiraやHubSpotなどの標準連携を使用する場合はリストから選択し、カスタムOpenAPI/MCPサーバーを登録する場合は Add MCP Server を選択します。
4. サーバーの公開URLを入力し、接続同期を行います。

認証モデルの選定：Personal（個人認証） vs Shared（共有認証）

ツールの認証アーキテクチャの選択は、セキュリティ監査と権限制御に直結します：

ネットワークとファイアウォール設定

社内インフラ内のAPIを連携させる場合の注意点：

• 固定送信元IP（Static Egress IPs）：自社ドメインの所有権をDustで確認することで、Dustからの通信を固定IPアドレスに限定し、社内ファイアウォールで安全にインバウンド許可できます。
• OAuthリダイレクトURLの登録：静的OAuthを利用する場合、プロバイダー側に以下のコールバックURLを登録します：
  • 米国ワークスペース: https://dust.tt/oauth/mcp_static/finalize
  • 欧州ワークスペース: https://eu.dust.tt/oauth/mcp_static/finalize
  • グローバル共通ゲートウェイ: https://app.dust.tt/oauth/mcp_static/finalize

ステップ3：安全性を担保するガードレールと承認プロセスの確立

生成AIアシスタントに本番システムの更新・削除（Write系）権限を付与する場合、プロンプトインジェクションやハルシネーションによる事故を防ぐ防御策が必須です。

1. High Stake（高リスク操作）フラグの設定

CRMデータの更新やJiraチケットのクローズなど、重要な変更を伴うツールを連携する際、管理者はツールを HIGH STAKE に指定できます。

• 確認モーダルの発火：アシスタントがツールを呼び出そうとすると、実行が自動で一時停止し、APIに送信されるパラメータ一覧が画面に表示されます。
• 人による明示的承認：権限を持つユーザーが「Approve（承認）」をクリックして初めて、実際のAPIコールが送信されます。
• API経由での制御：Dust Conversation APIを用いてプログラム経由でアシスタントを呼び出す場合も、POST /api/v1/w/{wId}/assistant/conversations/{cId}/messages/{mId}/validate-action エンドポイントを用いて承認・却下の判定を行えます。

2. ツール利用のスキル限定（Restrict to Skills）

Spaces > Tools の設定で、Restrict this tool to skills を有効化します。

• 汎用のアシスタント作成画面からツールが非表示になり、一般社員が無制限に強力な書き込みツールを組み込む事態を防止できます。
• ガードレール指示や前提知識が厳格に定義された「スキル（Skills）」を経由してのみツールが提供されます。

3. スペース（Spaces）による権限分離

強力な書き込み権限を持つツールは、限定されたメンバーのみが所属する「Restricted Space」内に配置します。これにより、一般部門のアシスタントへの機能流出を物理的に防ぎます。

ステップ4：信頼性の高い実行プロンプトの設計

ツールの接続後は、LLMが意図を正しく解釈し、確実にパラメータを構成できるよう、アシスタントの指示（Instructions）を設計します。

本番環境向けプロンプトの4大原則

1. 明確な役割と業務範囲の定義：アシスタントが担当する責務と、絶対に実行してはならない行為を明記する。
2. 事前検証ルールの徹底：書き込みツールを呼び出す前に、必ず読み取りツールで対象の存在確認を行うよう義務付ける。
3. パラメータの厳格なマッピング：必須項目の抽出ルールとデフォルト値、フォーマットを明示する。
4. エラーハンドリングと復旧案内：認証切れやAPIエラー発生時のユーザー向け通知手順を規定する。

運用トリアージ＆CRM連携アシスタントの指示例

# 役割と責務
あなたはテクニカルオペレーション支援エージェントです。ユーザーから報告された障害内容をCRMの顧客契約情報と照合し、エンジニアリングチーム用のJiraチケットを正確に起票する責務を持ちます。

# ツール実行プロトコル

## 1. 顧客情報と契約プランの照合 (HubSpot)
- チケットを作成する前に、必ず `Get Object By Email` または `Search Crm Objects` を使用して顧客アカウントを検索してください。
- 契約プラン（Tier）および進行中の商談状況を確認してください。
- 顧客が「Enterprise」プランを契約している場合は、障害チケットの優先度を自動的に P1 に引き上げてください。

## 2. Jiraチケットの起票 (Jira)
- 使用ツール: `create_issue`
- 要約（summary）は60文字以内で簡潔に記述し、`[モジュール名] 障害事象の要約` の形式に従ってください。
- 説明（description）には以下の3項目を必ず含めてください：
  1. 影響顧客情報（企業名、連絡先、契約プラン）
  2. 発生事象およびエラーメッセージ詳細
  3. 初期の再現手順とログへのリンク
- チケット種別は "Bug"、コンポーネントは "Production-Ops" を指定してください。

## 3. 安全確認とトラブルシューティング
- 商談ステージの変更やチケットのクローズを行う前に、必ず送信パラメータを提示し、ユーザーの同意を得てください。
- ツール呼び出しで 401 エラー（認証失敗）が返された場合、「右上のユーザーメニュー内『Tools & Triggers』からJira/HubSpotの個人認証を再接続してください」と案内してください。

ステップ5：Webhookトリガーによる自律型ワークフローの構築

対話画面でのチャット入力だけでなく、外部システムからのイベント通知を受け取って自動的にActionを実行する完全自律型パイプラインを構築できます。

+--------------------------+          HTTP POST イベント        +-----------------------------+
| 外部システム             | ---------------------------------> | Dust Webhook Source         |
| (Jira, GitHub, Zendesk,  |                                    | (Spaces > Triggers)         |
| 社内監視システム)        |                                    +--------------+--------------+
+--------------------------+                                                   |
                                                                               | ペイロード検証・HMAC確認
                                                                               v
+--------------------------+          Actionツールの実行        +-----------------------------+
| 外部連携先               | <--------------------------------- | Dust エージェント自律実行   |
| (HubSpotステータス更新 / |                                    | (イベント解析、フィルタ判定 |
| Slackチャンネルへの通知) |                                    | ツール呼び出しによる完結)   |
+--------------------------+                                    +-----------------------------+

Webhook連携の設定ステップ

1. Webhookソースの作成（管理者作業）：
   • Spaces > Triggers から Add source を開きます。
   • 標準ソース（Jira、GitHub、Linear、Zendesk等）または Custom webhook を選択します。
   • カスタムWebhookでは、Signature header と sha256 署名アルゴリズムを指定し、Dustが生成した共有秘密鍵を用いて偽装リクエストを遮断します。
2. アシスタントへのトリガー登録：
   • Agent Builderの Triggers > Add triggers で作成したソースを紐付けます。
   • 自然言語による実行条件（例: 「チケットの優先度がHighで、ステータスがEscalatedに変更された場合のみ実行」）を設定します。
   • Include webhook payload にチェックを入れ、外部イベントのJSON全体をアシスタントに渡します。
   • 実行プロンプト（例: 「ペイロードのログ情報を解析し、ナレッジベースを検索して該当Jiraチケットに初期対応コメントを投稿せよ」）を記述します。
   • 突発的なイベント過多に備えて、24時間の実行回数上限（Rate Limits）を設定します。

アーキテクチャ選定比較表

要件や開発リソースに応じて、最適なツール統合アプローチを選択してください：

本番展開前のチェックリスト

ワークフロー実行アシスタントを現場に展開する前に、以下の確認を実施してください：

• 認証方式の適合性：データ書き込みを伴うツールにおいて、個人の監査ログを残すためのPersonal認証が選択されているか（または共有アカウントの権限が最小化されているか）？
• High Stakeフラグの有効化：重要データの書き換えや削除を行うツールに、承認モーダル（High Stake）が設定されているか？
• 機密パラメータの隠蔽：環境フラグや内部URLが ConfigurableToolInputSchemas で静的バインドされ、LLMによる推測から保護されているか？
• エラー通知プロンプト：APIエラーや認証期限切れ発生時、ユーザーが対処できるメッセージを出力するよう指示されているか？
• 社内ファイアウォールの設定：自社インフラ内のMCPサーバーに対し、Dustの固定送信元IPアドレスが許可されているか？
• トリガーの流量制限：Webhookトリガーに対して、予期せぬクレジット消費を防ぐ実行レート制限が設定されているか？

OpenAPIインターフェースをMCPを通じてDustに統合し、堅牢な認証と承認機構を整えることで、単なる「回答ボット」を超えた、企業の自律型オペレーションを担う強力なワークフロー実行基盤が実現します。

参考文献

• Adding an MCP Server
• Personal vs Shared Credentials for Tools & MCP Servers
• Jira
• HubSpot
• Webhooks
• OpenAPI & Postman
• Dev : pre-configuring a custom MCP server
• Validate an action in a conversation message
• Multiplayer AI Documentation Index