Skip to main content

エンドポイント

説明

Shannonに新しいタスクを実行するために送信します。タスクは即座にキューに追加され、Temporalワークフローエンジンによって非同期に処理されます。

認証

必須: はい ヘッダーにAPIキーを含めてください:

リクエスト

ヘッダー

ボディパラメータ

リクエストボディスキーマ

例 1: 一般的なAI駆動の実行
例 2: テンプレートのみの実行(AIなし)
避けるべきパラメータの競合:
  • templatetemplate_nameの両方を使用しないでください(エイリアスです - templateのみを使用)
  • disable_ai: trueとモデル制御を組み合わせないでください - 競合が検出されるとゲートウェイは400エラーを返します:
    • disable_ai: true + model_tier → 400
    • disable_ai: true + model_override → 400
    • disable_ai: true + provider_override → 400
  • トップレベルのパラメータはコンテキストの同等物を上書きします:
    • トップレベルのmodel_tiercontext.model_tierを上書きします
    • トップレベルのmodel_overridecontext.model_overrideを上書きします
    • トップレベルのprovider_overridecontext.provider_overrideを上書きします
    • トップレベルのskillcontext.skillを上書きします
    • トップレベルのresearch_strategycontext.research_strategyを上書きします

コンテキストパラメータ (context.*)

認識されたキー:
  • role — 役割プリセット(例: analysis, research, writer, ads_research, financial_news, browser_use
  • system_prompt — 役割プロンプトを上書き; prompt_paramsからの${var}をサポート
  • prompt_params — プロンプト/ツール/アダプタ用の任意のパラメータ
  • model_tier — トップレベルが提供されていない場合のフォールバック
  • model_override — 特定のモデル名(標準; 例: gpt-5, claude-sonnet-4-5-20250929
  • provider_override — プロバイダーを強制(例: openai, anthropic, google
  • research_strategy(非推奨: トップレベルの research_strategy を使用してください。トップレベルが設定されている場合、contextの値は無視されます)
  • skill(非推奨: トップレベルの skill を使用してください。トップレベルが設定されている場合、contextの値は無視されます)
  • template — テンプレート名(エイリアス: template_name
  • template_version — テンプレートのバージョン
  • disable_ai — テンプレート専用モード(AIフォールバックなし) - モデルコントロールと組み合わせることはできません
  • ウィンドウコントロール: history_window_size, use_case_preset, primers_count, recents_count, compression_trigger_ratio, compression_target_ratio
  • Deep Research 2.0 コントロールforce_research: trueの場合):
    • iterative_research_enabled — 反復カバレッジループの有効/無効(デフォルト: true
    • iterative_max_iterations — 最大反復回数 1-5(戦略プリセットのシードデフォルト; それ以外は3にフォールバック)
    • enable_fact_extraction — 構造化された事実をメタデータに抽出(デフォルト: false
  • 広告リサーチプラットフォームトグルrole: "ads_research"の場合):
    • platforms.google — Google ショッピング広告の有効/無効(デフォルト: true
    • platforms.yahoo_jp — Yahoo Japan 広告の有効/無効(デフォルト: true
    • platforms.meta — Meta 広告ライブラリの有効/無効(デフォルト: true
    • platforms.meta_platform — Meta プラットフォームフィルタ: facebook, instagram, messenger, whatsapp, または all(デフォルト: all
ルール:
  • トップレベルのパラメータはコンテキストの同等物を上書きします: model_tier, model_override, provider_override, skill, research_strategy
  • modeは次をサポート: simple|standard|complex|supervisor(デフォルト: 自動検出)
  • model_tierは次をサポート: small|medium|large
  • 競合検証: disable_ai: truemodel_tier, model_override, またはprovider_overrideと組み合わせることはできません(400を返します)

役割プリセット

役割プリセットは、異なるタスクタイプに対して専門的なシステムプロンプトとツール許可リストを提供します。context.roleを通じて設定:
Shannon Cloud のみ: 「Shannon Cloud のみ」とマークされた役割はエンタープライズ機能であり、ベンダーアダプター設定を持つ Shannon Cloud デプロイメントが必要です。

レスポンス

成功レスポンス

ステータス: 200 OK ヘッダー:
  • X-Workflow-ID: Temporalワークフロー識別子
  • X-Session-ID: セッション識別子(提供されていない場合は自動生成)
ボディ:

レスポンスフィールド

基本タスク提出

レスポンス:

セッションIDを持つタスク(マルチターン)

コンテキストを持つタスク

ティアを強制(トップレベル)

テンプレート専用実行

スーパーバイザーモード

広告リサーチ(Shannon Cloud のみ)

プラットフォームトグルを備えたマルチプラットフォーム広告競合分析。
プラットフォームのデフォルト: すべてのプラットフォームがデフォルトで有効です。platformsオブジェクトを使用してプラットフォームを選択的に無効にするか、Metaをプラットフォーム別にフィルタリングします(facebook, instagram, messenger, whatsapp, all)。

Deep Research 2.0

Deep Research 2.0は、包括的な研究タスクのための反復的なカバレッジ改善を提供します。
Deep Research 2.0は、force_research: trueのときにデフォルトで有効になります。包括的な結果を確保するために、カバレッジ評価を伴うマルチステージワークフローを使用します。深さを制御するにはiterative_max_iterationsを使用してください(1-5、デフォルト: 3)。

冪等性を持つ

分散トレーシングを使用

エラーレスポンス

400 Bad Request

クエリが欠落:
無効なJSON:

401 Unauthorized

APIキーが欠落:
無効なAPIキー:

429 Too Many Requests

ヘッダー:
  • X-RateLimit-Limit: 100
  • X-RateLimit-Remaining: 0
  • X-RateLimit-Reset: 1609459200
  • Retry-After: 60

500 Internal Server Error

コード例

Python with httpx

Python with requests

JavaScript/Node.js

cURL with Idempotency

Go

実装の詳細

ワークフローの作成

タスクを送信すると:
  1. ゲートウェイがリクエストを受信 → 認証を検証し、レート制限を適用
  2. セッションIDを生成 → 提供されていない場合はUUIDを自動生成
  3. オーケストレーターgRPCを呼び出すSubmitTask(metadata, query, context)
  4. オーケストレーターがTemporalワークフローを開始 → 耐久性のある実行
  5. レスポンスが返される → タスクID、初期ステータス
  6. タスクが非同期に実行される → HTTP接続とは独立して

冪等性の動作

冪等性キーを使用すると、重複タスクを作成することなく、安全にタスクの再送信が可能です。 動作の流れ:
  1. 最初のリクエスト Idempotency-Keyを使用:
    • Shannonがタスクを作成
    • 24時間のTTLでRedisにレスポンスをキャッシュ
    • タスクIDとステータスを返す
  2. 重複リクエスト(同じIdempotency-Key):
    • Shannonがキャッシュされたレスポンスを検出
    • 新しいタスクを作成せずに同じタスクIDを返す
    • レスポンスは最初のリクエストと同一
  3. 24時間後:
    • キャッシュが期限切れ
    • 同じキーでの新しいリクエストが新しいタスクを作成
キャッシュの詳細:
  • ストレージ: Redis
  • TTL: 24時間(86400秒)
  • キー形式: idempotency:<16-char-hash>(冪等性キーにユーザーID、パス、リクエストボディを加えたSHA-256)
  • スコープ: 認証されたユーザーごと(ユーザーIDがハッシュの一部; 認証が無効な場合、ハッシュはヘッダー、パス、ボディに基づく)
  • キャッシュされたレスポンス: 2xxレスポンスのみが保存される; キャッシュヒットにはX-Idempotency-Cached: trueX-Idempotency-Key: <your-key>が含まれる
ボディの動作: リクエストボディが変更されると、キャッシュキーも変更されるため、ゲートウェイはそれを新しいリクエストとして扱います。重複検出は、ヘッダー、ユーザー、パス、ボディがすべて一致した場合にのみトリガーされます。 ベストプラクティス: ユニークなリクエストボディごとにユニークなキーを生成すること。 :
使用するタイミング:
  • ネットワーク再試行ロジック(タイムアウト時の重複タスクを避ける)
  • Webhook配信(重複Webhook呼び出しを処理)
  • 重要な操作(支払い、データ書き込み)
  • バックグラウンドジョブキュー(重複スケジューリングを防ぐ)

セッション管理

  • セッションIDなし: UUIDを自動生成し、新しいコンテキストを作成
  • セッションIDあり: Redisから以前の会話履歴を読み込む
  • セッションの持続性: デフォルトのTTLは30日
  • マルチターン会話: 同じsession_idを持つすべてのタスクがコンテキストを共有

コンテキストオブジェクト

contextオブジェクトはメタデータとして保存され、以下に渡されます:
  • エージェント実行環境
  • ツール呼び出し(ctx.get("key")でアクセス可能)
  • セッションメモリ(将来のターンで参照)
使用例:
  • ユーザーの好み: {"language": "spanish", "format": "markdown"}
  • ビジネスコンテキスト: {"company_id": "acme", "department": "sales"}
  • 制約: {"max_length": 500, "tone": "formal"}

ベストプラクティス

1. 重要なタスクには常に冪等性キーを使用

2. 会話にはセッションを使用

3. リッチなコンテキストを提供

4. エラーを優雅に処理

5. タスクIDを保存して追跡

一度の呼び出しで送信 + ストリーム

リアルタイムの更新が必要ですか? POST /api/v1/tasks/streamを使用して、タスクを送信し、ストリームURLを一度の呼び出しで取得できます。即時の進捗更新が必要なフロントエンドアプリケーションに最適です。例についてはUnified Submit + Streamを参照してください。

関連エンドポイント

送信 + ストリーム

POST /api/v1/tasks/stream (UIに推奨)

タスクのステータスを取得

GET /api/v1/tasks/

ストリームイベント

リアルタイムタスクイベント

タスクの一覧

GET /api/v1/tasks

Python SDK

代わりにSDKを使用