AIワーカー

ワーカー編集画面のサイドバーには「指示」「スキル」「連携」「トリガー」「API」の5タブだけがあり、「ナレッジ」タブはありません。これはZemuのナレッジがチーム単位の共有プールで、ワーカーごとに割り当てる設計ではないためです。

ワーカーがナレッジを参照するときは、「スキル」タブで knowledge-manager などのナレッジ系ビルトインスキルを有効化すると、そのスキル経由で参照できます。「ワーカーAだけが見られるナレッジ」のような分離はできず、参照範囲はチーム共通のナレッジツリー側のフォルダ構成と命名で制御します。

設定の責務分担：

• 指示：このワーカーの役割・口調・出力形式・禁止事項
• スキル：再利用可能な作業手順（ナレッジ参照もここで有効化）
• 連携：外部SaaSへの接続（次セクション参照）
• トリガー：自動起動の条件
• API：このワーカーを外部から呼び出すためのエンドポイント設定

同じ「ツール」のように見えて、スキルと連携はレイヤーが違います。

• スキル（やり方）：Zemuが提供する／チームが定義する再利用可能な作業手順。docx pdf xlsx gemini-image-generation knowledge-manager などのビルトインスキルと、独自に作るカスタムスキルがあります。スキルタブで有効化／無効化し、ワーカーが必要なときに呼び出します。
• 連携（接続先）：外部SaaSやMCPサーバーへの接続。連携タブの「アプリを参照」でSlack / Notion / GitHubなどのネイティブ・Composio連携プロファイルを、「カスタムMCP」で独自MCPサーバーを紐づけます。

判断基準：「Zemuの中で完結する手順か → スキル」「外部システムへアクセスするための接続か → 連携」。同じ目的でも、内蔵の gemini-image-generation スキルで画像生成するのと、Composio連携経由でCanvaを操作するのは別レイヤーです。

同じワーカーでも、起動する経路によって設定箇所と挙動が変わります。

• チャット：ワーカー一覧の「チャット開始」から起動。プロンプトとモデルはチャット画面で都度入力・選択します。
• トリガー：ワーカー設定→トリガータブで作成。スケジュール（cron／繰り返し）と外部イベント（Composio OAuthイベント）の2種があり、起動時のプロンプトとモデルをトリガーごとに固定します。
• 受信チャネル：ダッシュボード左メニューの「受信チャネル」（別画面）で設定。Slack / Discord / LINE WORKS のDM・メンション・チャンネル投稿を入口にします。ワーカー設定のトリガータブには表示されないため、「Slack起動の設定が見当たらない」と詰まる人が多い箇所です。

モデルの優先順位は「ワーカー既定 ← トリガー上書き／受信チャネルルート上書き／チャット上書き」で解決されます。受信チャネルからの起動とトリガーは設定箇所が分かれているので、運用時には両方を独立に確認します。

スケジュールトリガー作成の3ステップ目「実行」に、トグル「ワーカープロンプト／ワークフロースキル」があります。これは「トリガー時刻に何が走るか」を決める分岐で、選択を間違えると意図と違う動作になります。

• ワーカープロンプト（API上は agent_prompt）：実行時にプロンプト本文をワーカーに渡して、その都度ワーカーが内容を解釈して動きます。本文には {{variable_name}} で変数を埋め込めます。「日次でその日のSlack要約を作る」のように、毎回の入力が違うが指示の枠組みは同じ用途向け。
• ワークフロースキル（API上は workflow_skill）：あらかじめ定義したワークフロースキルを丸ごと実行します。手順・入力・出力が固定された定型作業向けで、保守時はトリガーではなくスキル本体だけ更新すれば全トリガーに反映されます。

判断基準は「実行内容が毎回違うか／いつも同じか」。手順が固定なら workflow_skill のほうが、複数トリガーから同じ手順を呼ぶときの一元管理が効きます。