よくある質問

大量に発生するワークフローを1つ選び、単一のチャネルで起動します。回答が正確であり、エスカレーションが適切な人に届くことを証明してから、より多くのチャネルとパックに拡大します。

汎用コパイロットは、1つのベンダーのモデルに縛られています。Threada は業務プラットフォームです。あらゆる LLM にわたって、すべての依頼がポリシー制御、ガバナンスされた実行、成果分析を備えた追跡可能な WorkItem になります。

いいえ。Threada は既存のツールと連動します。依頼を取り込んで構造化し、すでにお使いのシステムで承認済みアクションを実行します。

AI は理解と構造化を担当します。ポリシー制御、レビューキュー、承認が例外に対処します。高リスクな案件では人がループに入り続けます。

封じ込め率、解決時間、エスカレーション品質、承認サイクル時間、アクション成功率——インタラクション数ではなく、記録に残る成果です。

抽出、ルーティング、根拠付け、アクション動作をテストする評価ゲートを実行します。カナリアトラフィック、シャドウモード、ワンクリックロールバックで段階的にロールアウトしてください。

説明責任のもとで大量の運用業務を遂行するチームです。カスタマーオペレーションとサポート、IT と調達、セキュリティとコンプライアンス、そして財務オペレーション。記録を伴って回答または対応すべきリクエストとして業務が届くなら、それはガバナンスされた WorkItems として Threada 上で運用できます。

業務とアクションが存在するシステムです。Zendesk のようなサポート・チケットツール、Jira のような課題トラッカー、Slack のようなチャット、さらにメールや API・Webhook による受付。リクエストが入り、承認されたアクションがガバナンスされたアクションとして出ていきます。最新の一覧は連携ページをご覧ください。

いいえ。チャットボットはメッセージに答えればそれで忘れてしまいます。Threada は業務そのものを管理します。各リクエストは、引用付きのエビデンス、ポリシー制御、人による承認、ガバナンスされたアクション、そして監査証跡を備えた、追跡可能な WorkItem になります。だからこそ業務は単なる返信ではなく、端から端までガバナンスされ監査可能なのです。

WorkItem は Threada の中心的な作業単位であり、すべてのリクエストの取り込み、決定、実行、結果をとらえる、型付きでライフサイクル管理されたオブジェクトです。

従来のメッセージ中心の自動化ツールは、リクエストを1件ずつ処理します。Threada は、受付、ポリシー、承認、アクション、成果測定までを、監査証跡とガバナンス制御付きで管理します。

はい。ほとんどのチームは、1 つのチャネルまたはワークスペースを対象とした単一のワークフローから開始し、自信が高まるにつれて徐々に拡張していきます。

ウェブサイト、アップロードされた文書、API コネクタ、フィードベースのソースです。それぞれが、独自の鮮度・保持ポリシーを持つ管理対象のナレッジアセットとして登録されます。

ソースごとに同期の頻度と陳腐化のしきい値を設定します。Threada は鮮度のドリフトや同期の失敗をアラートするため、エビデンスは最新の状態に保たれます。

はい。引用の要件はワークフローおよびインテントごとに適用できます。エビデンスの乏しい回答は、自動的にレビューまたはエスカレーションへ振り向けられます。

はい。意思決定ステップと承認要件は構成によって決まります。

はい。チャネル固有のポリシーオーバーレイは、ベースラインのワークフロー動作をオーバーライドできます。

はい。キルスイッチで、チャネル、ワークフロー、または連携のスコープごとに実行を無効にできます。

はい。テレメトリのディメンションにはチャネルとワークフローの両識別子が含まれ、横断的な分析が可能です。

はい。実行テレメトリにはインテグレーションとアクションのディメンションが含まれ、成功・再試行・失敗の状態を区別します。

はい。ポリシーバージョンは、品質と成果の分析のためのファーストクラスのレポートディメンションとして利用できます。

Threadaは、引用付きの根拠からセキュリティ質問票の回答を作成し、レビューへとルーティングします。リスクが低く十分に根拠のある回答は、ポリシーに従って自動承認できます。機微なものは、指名されたセキュリティ担当者の対応を待ちます。ポリシーで明示的に許可されていない限り、レビューされていない回答が送信されることはありません。

Threadaは、過去の質問票、セキュリティポリシー、SOC 2レポート、DPAなど、あなたが承認したソースから回答を導き出し、回答ごとに取得元を引用します。根拠が回答を裏付けない場合、WorkItemは推測せずに人による確認のためフラグを立てます。

Threadaは、作成されたすべての回答、編集、承認を、引用された根拠とともにタイムスタンプ付きのイベントとして記録します。そのため、後日の監査、更新、統制の変更があっても、誰が何にどのような根拠で回答し、誰が承認したかを再構成できます。

Threadaは、あなたのソースを対象とした検索によって財務の回答に根拠を与え、特定のページやレコードを引用し、リスクの高い主張には出所ラベルを付けます。コンテキストが不十分で棄権モードが有効な場合は、推測する代わりに無回答フォールバックを返します。

Threadaの判断ステップは、人によるレビュー、マネージャー承認、セキュリティ承認、自動化されたゲート、例外キューをモデル化します。また、ポリシーオーバーレイが決定論的な優先順位で承認要件を設定します。

はい。Threadaの統制されたアクションは、idempotency keysとリトライを用いて実行され、可逆であり、監査可能な実行記録を生成します。あわせて、統一されたテレメトリエンベロープと、CSV/NDJSONのエクスポートも提供します。

Threadaは、Web、アプリ内、Slack、Teams、メール、API、カスタムエンドポイントから型付けされた受け付けを取り込みます。インバウンドのプロバイダーチャネルには、Gmail、Twilio SMS、WhatsApp、ソーシャル、Discord、TeamsのWebhookが含まれ、すべてWorkItemsに正規化されます。

棄権モードを有効にすると、Threadaは関連性のしきい値を用い、回答を捏造する代わりに明示的な無回答フォールバックを返します。また、生成される回答にはいずれも引用が含まれます。

Threadaは、チケットの更新や顧客への通知といったサポートアクションを、判断ステップの背後でゲートできます。承認は記録され、アクションはidempotency keysによって可逆であり、実行は監査可能な履歴として記録されます。

受付、ドラフト作成、承認、アクション、WorkItem の操作など、プラットフォームの利用台帳によって計測されるランタイムイベントを指します。

アップロードまたは同期されたコンテンツから処理されたページで、インデックス作成とエビデンスに使われるドキュメントページ枠にカウントされます。

はい。いつでも。変更は次回請求サイクルから適用されます。

上限に近づくと警告が表示されます。上限を超えると利用は上限で制限されます（利用可能な場合は超過分のクレジットが適用されます）。7日間の猶予期間は支払いが失敗した場合に適用されるもので、利用上限とは別です。

年額課金で20%お得。

いいえ。検索用にのみインデックスされます。

当社は、自動スケール、自動バックアップ、テスト済みのリストア手順により、社内の可用性目標に沿って運用しています。契約上の稼働率目標やサービスクレジットによる救済は、注文書ごとに合意します。

いいえ。Threada は AI 業務自動化内でポリシーを適用します——既存の GRC および ID ツールと統合し、それらを置き換えるものではありません。

ポリシーオーバーレイはテナント、チャネル、パック、ワークフローごとにバージョン管理・スコープされます。すべての実行は、有効だったポリシーバージョンを記録します。

はい。ライフサイクル、ポリシー、アクションのイベントは、外部監査、SIEM 統合、規制報告のためにエクスポート可能です。

明確な RTO（4 時間）および RPO（24 時間）目標と、文書化されたインシデントランブックを伴う月次可用性 99.9% です。

Stripe サブスクリプション + 使用量カウンター。猶予期間の警告自動化と、猶予期間後の制御された無効化を行います。

はい。エクスポートフィード（GCS および BigQuery）とオンデマンドダウンロードを、コンプライアンスレビューに利用できます。

いいえ。Threada は連携と統制されたアクションを通じて既存システムの周囲をオーケストレーションするよう設計されています。

はい。承認要件はワークフロー、チャネル、リスククラス、アクション種別ごとに適用できます。

広範な展開の前に、抽出・ルーティング・グラウンディング・アクション挙動について EvalSuite のゲートを使用します。

はい。Web を最初のチャネルとして使用しながら、将来のチャネルでも同じワークフロープリミティブを維持できます。

はい。統合の実行は非同期であり、監査可能なエラークラスでの再試行をサポートします。

相関 ID、WorkItem 履歴、決定イベント、および実行ログを使用して、エンドツーエンドのフローを再構築します。