mirror of
https://github.com/simstudioai/sim.git
synced 2026-04-06 03:00:16 -04:00
* feat(rippling): expand Rippling integration from 16 to 86 tools * fix(rippling): add required constraints on name and data subBlocks for create operations * fix(rippling): add subblock ID migrations for removed legacy fields * fix(docs): add MANUAL-CONTENT markers to tailscale docs and regenerate * fix(rippling): add missing response fields to tool transforms Add fields found missing by validation agents: - list_companies: physical_address - list/get_supergroups: sub_group_type, read_only, parent, mutually_exclusive_key, cumulatively_exhaustive_default, include_terminated - list/get/create/update_custom_object: native_category_id, managed_package_install_id, owner_id - list/get/create/update_custom_app: icon, pages - list/get/create/update_custom_object_field: managed_package_install_id * fix(rippling): add missing block outputs and required data conditions - Add 17 missing collection output keys (titles, workLocations, supergroups, etc.) - Add delete/bulk/report output keys (deleted, results, report_id, etc.) - Mark data subBlock required for create_business_partner, create_custom_app, and create_custom_object_field (all have required params via data JSON spread) - Add optional: true to get_current_user work_email and company_id outputs * fix(rippling): add missing supergroup fields and fix validation issues - Add 5 missing supergroup fields (allow_non_employees, can_override_role_states, priority, is_invisible, ignore_prov_group_matching) to types, list, and get tools - Fix ok fallback from true to false in supergroup inclusion/exclusion member update tools - Fix truthy check to null check for description param in create_custom_object_field * fix(rippling): add missing custom page fields and structured custom setting responses - Add 5 missing CustomPage fields (components, actions, canvas_actions, variables, media) to types and all page tools - Replace opaque data blob with structured field mapping in create/update custom setting transforms - Fix secret_value type cast consistency in list_custom_settings * fix(rippling): add missing response fields, fix truthy checks, and improve UX - Add 9 missing Worker fields (location, gender, date_of_birth, race, ethnicity, citizenship, termination_details, custom_fields, country_fields) - Add 5 missing User fields (name, emails, phone_numbers, addresses, photos) - Add worker expandable field to GroupMember types and all 3 member list tools - Add 5 optional params to trigger_report_run (includeObjectIds, includeTotalRows, formatDateFields, formatCurrencyFields, outputType) - Fix truthy checks to null checks in create_department, create/update_work_location - Fix customObjectId subBlock label to say "API Name" instead of "ID" * update docs * fix(rippling): fix truthy checks, add missing fields, and regenerate docs - Replace all `if (params.x)` with `if (params.x != null)` across 30+ tool files to prevent empty string/false/zero suppression - Add expandable `parent` and `department_hierarchy` fields to department tools - Add expandable `parent` field to team tools - Add `company` expandable field to get_current_user - Add `addressType` param to create/update work location tools - Fix `secret_value` output type from 'json' to 'string' in list_custom_settings - Regenerate docs for all 86 tools from current definitions Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): add all remaining spec fields and regenerate docs - Add 6 advanced params to create_custom_object_field: required, rqlDefinition, formulaAttrMetas, section, derivedFieldFormula, derivedAggregatedField - Add 6 advanced params to update_custom_object_field: required, rqlDefinition, formulaAttrMetas, section, derivedFieldFormula, nameFieldDetails - Add 4 record output fields to all custom object record tools: created_by, last_modified_by, owner_role, system_updated_at - Add cursor param to get_current_user - Add __meta response field to get_report_run - Regenerate docs for all 86 tools Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): align all tools with OpenAPI spec - Add __meta to 14 GET-by-ID tools (MetaResponse pattern) - Fix supergroup tools: add filter to list_supergroups, remove invalid cursor from 4 list endpoints, revert update members to PATCH with Operations body - Fix query_custom_object_records: use query/limit/cursor body params, return cursor instead of nextLink - Fix bulk_create: use rows_to_write per spec - Fix create/update record body wrappers with externalId support - Update types.ts param interfaces and block config mappings - Add limit param mapping with Number() conversion in block config - Regenerate docs Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): address PR review comments — add dedicated subBlocks, fix data duplication, expand externalId condition - Add dedicated apiName, businessPartnerGroupId, workerId, dataType subBlocks so required params are no longer hidden behind opaque data JSON - Narrow `data: item` in custom object record tools to only include dynamic fields, avoiding duplication of enumerated fields - Expand externalId subBlock condition to include create/update custom object record operations Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): remove data JSON required for ops with dedicated subBlocks create_business_partner, create_custom_app, and create_custom_object_field now have dedicated subBlocks for their required params, so the data JSON field is supplementary (not required) for those operations. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): use rest-destructuring for all custom object record data output The spec uses additionalProperties for custom fields at the top level, not a nested `data` sub-object. Use the same rest-destructuring pattern across all 6 custom object record tools so `data` only contains dynamic fields, not duplicates of enumerated standard fields. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): make update_custom_object_record data param optional in type Matches the tool's `required: false` — users may update only external_id without changing data. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): add dedicated streetAddress subBlock for create_work_location streetAddress is required by the tool but had no dedicated subBlock — users had to include it in the data JSON. Now has its own required subBlock matching the pattern used by all other required params. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): add allOrNothing subBlock for bulk operations The bulk create/update/delete tools accept an optional allOrNothing boolean param, but it had no subBlock and no way to be passed through the block UI. Added as an advanced-mode dropdown with boolean coercion. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): derive spreadOps from DATA_OPS to prevent divergence Replace the hardcoded spreadOps array with a derivation from the file-level DATA_OPS constant minus non-spread operations. This ensures new create/update operations added to DATA_OPS automatically get spread behavior without needing a second manual update. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * updated * fix(rippling): replace generic JSON outputs with specific fields per API spec - Extract file_url, expires_at, output_type from report run result blob - Rename bulk create/update outputs to createdRecords/updatedRecords - Fix list_custom_settings output key mismatch (settings → customSettings) - Make data optional for update_custom_object_record in block - Update block outputs to match new tool output fields Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix landing * restore FF * fix(rippling): add wandConfig, clean titles, and migrate legacy operation values - Remove "(JSON)" suffix from all subBlock titles - Add wandConfig with AI prompts for filter, expand, orderBy, query, data, records, and dataType fields - Add OPERATION_VALUE_MIGRATIONS to migrate old operation values (list_employees → list_workers, etc.) preventing runtime errors on saved workflows Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(rippling): fix grammar typos and revert unnecessary migration - Fix "a object" → "an object" in update/delete object category descriptions - Revert OPERATION_VALUE_MIGRATIONS (unnecessary for low-usage integration) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * feat(landing): add interactive workspace preview tabs Adds Tables, Files, Knowledge Base, Logs, and Scheduled Tasks preview components to the landing hero, with sidebar nav items that switch to each view. * test updates * refactor(landing): clean up code quality issues in preview components - Replace widthMultiplier with explicit width on PreviewColumn - Replace key={i} with key={Icon.name} in connectorIcons - Scope --c-active CSS variable to sidebar container, eliminating hardcoded #363636 duplication - Replace '- - -' fallback with em dash - Type onSelectNav as (id: SidebarView) removing the unsafe cast * fix(landing): use stable index key in connectorIcons to avoid minification breakage --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
208 lines
9.5 KiB
Plaintext
208 lines
9.5 KiB
Plaintext
---
|
||
title: ガードレール
|
||
---
|
||
|
||
import { Callout } from 'fumadocs-ui/components/callout'
|
||
import { Image } from '@/components/ui/image'
|
||
import { Video } from '@/components/ui/video'
|
||
|
||
ガードレールブロックは、複数の検証タイプに対してコンテンツをチェックすることで、AIワークフローを検証し保護します。データ品質の確保、ハルシネーション(幻覚)の防止、個人情報の検出、フォーマット要件の強制などをワークフローに組み込む前に行います。
|
||
|
||
<div className="flex justify-center">
|
||
<Image
|
||
src="/static/blocks/guardrails.png"
|
||
alt="ガードレールブロック"
|
||
width={500}
|
||
height={400}
|
||
className="my-6"
|
||
/>
|
||
</div>
|
||
|
||
## 検証タイプ
|
||
|
||
### JSON検証
|
||
|
||
コンテンツが適切にフォーマットされたJSONであることを検証します。構造化されたLLM出力を安全に解析できることを確認するのに最適です。
|
||
|
||
**ユースケース:**
|
||
- 解析前にエージェントブロックからのJSON応答を検証
|
||
- APIペイロードが適切にフォーマットされていることを確認
|
||
- 構造化データの整合性をチェック
|
||
|
||
**出力:**
|
||
- `passed`: 有効なJSONの場合は `true`、それ以外の場合は `false`
|
||
- `error`: 検証が失敗した場合のエラーメッセージ(例:「無効なJSON:予期しないトークン...」)
|
||
|
||
### 正規表現検証
|
||
|
||
コンテンツが指定された正規表現パターンに一致するかどうかをチェックします。
|
||
|
||
**ユースケース:**
|
||
- メールアドレスの検証
|
||
- 電話番号形式のチェック
|
||
- URLやカスタム識別子の確認
|
||
- 特定のテキストパターンの強制
|
||
|
||
**設定:**
|
||
- **正規表現パターン**: 照合する正規表現(例:メールの場合は `^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
|
||
|
||
**出力:**
|
||
- `passed`: コンテンツがパターンに一致する場合は `true`、それ以外の場合は `false`
|
||
- `error`: 検証が失敗した場合のエラーメッセージ
|
||
|
||
### 幻覚検出
|
||
|
||
検索拡張生成(RAG)とLLMスコアリングを使用して、AI生成コンテンツがナレッジベースと矛盾している場合や、ナレッジベースに根拠がない場合を検出します。
|
||
|
||
**仕組み:**
|
||
1. 関連するコンテキストについてナレッジベースに問い合わせる
|
||
2. AI出力と取得したコンテキストの両方をLLMに送信
|
||
3. LLMが信頼度スコア(0〜10のスケール)を割り当てる
|
||
- **0** = 完全な幻覚(まったく根拠なし)
|
||
- **10** = 完全に根拠あり(ナレッジベースで完全にサポートされている)
|
||
4. スコアが閾値以上(デフォルト:3)であれば検証に合格
|
||
|
||
**設定:**
|
||
- **ナレッジベース**: 既存のナレッジベースから選択
|
||
- **モデル**: スコアリング用のLLMを選択(強力な推論能力が必要 - GPT-4o、Claude 3.7 Sonnetを推奨)
|
||
- **APIキー**: 選択したLLMプロバイダーの認証(ホスト型/OllamaまたはVLLM互換モデルの場合は自動的に非表示)
|
||
- **信頼度しきい値**: 合格するための最小スコア(0-10、デフォルト: 3)
|
||
- **Top K**(高度な設定): 取得するナレッジベースのチャンク数(デフォルト: 10)
|
||
|
||
**出力:**
|
||
- `passed`: 信頼度スコア ≥ しきい値の場合は `true`
|
||
- `score`: 信頼度スコア(0-10)
|
||
- `reasoning`: スコアに対するLLMの説明
|
||
- `error`: 検証が失敗した場合のエラーメッセージ
|
||
|
||
**ユースケース:**
|
||
- ドキュメントに対するエージェントの回答を検証
|
||
- カスタマーサポートの回答が事実に基づいていることを確認
|
||
- 生成されたコンテンツがソース資料と一致することを確認
|
||
- RAGアプリケーションの品質管理
|
||
|
||
### PII検出
|
||
|
||
Microsoft Presidioを使用して個人を特定できる情報を検出します。複数の国と言語にわたる40以上のエンティティタイプをサポートしています。
|
||
|
||
<div className="flex justify-center">
|
||
<Image
|
||
src="/static/blocks/guardrails-2.png"
|
||
alt="PII検出の設定"
|
||
width={700}
|
||
height={450}
|
||
className="my-6"
|
||
/>
|
||
</div>
|
||
|
||
**仕組み:**
|
||
1. 検証するコンテンツを渡す(例:`<agent1.content>`)
|
||
2. モーダルセレクターを使用して検出するPIIタイプを選択
|
||
3. 検出モード(検出またはマスク)を選択
|
||
4. コンテンツが一致するPIIエンティティをスキャン
|
||
5. 検出結果と、オプションでマスクされたテキストを返す
|
||
|
||
<div className="mx-auto w-3/5 overflow-hidden rounded-lg">
|
||
<Video src="guardrails.mp4" width={500} height={350} />
|
||
</div>
|
||
|
||
**設定:**
|
||
- **検出するPIIタイプ**: モーダルセレクターからグループ化されたカテゴリを選択
|
||
- **一般**: 人名、メール、電話番号、クレジットカード、IPアドレスなど
|
||
- **アメリカ**: 社会保障番号、運転免許証、パスポートなど
|
||
- **イギリス**: NHS番号、国民保険番号
|
||
- **スペイン**: NIF、NIE、CIF
|
||
- **イタリア**: 納税者番号、運転免許証、VAT番号
|
||
- **ポーランド**: PESEL、NIP、REGON
|
||
- **シンガポール**: NRIC/FIN、UEN
|
||
- **オーストラリア**: ABN、ACN、TFN、Medicare
|
||
- **インド**: Aadhaar、PAN、パスポート、有権者番号
|
||
- **モード**:
|
||
- **検出**: PIIを識別するのみ(デフォルト)
|
||
- **マスク**: 検出されたPIIをマスク値に置き換え
|
||
- **言語**: 検出言語(デフォルト:英語)
|
||
|
||
**出力:**
|
||
- `passed`: 選択したPIIタイプが検出された場合は `false`
|
||
- `detectedEntities`: タイプ、位置、信頼度を含む検出されたPIIの配列
|
||
- `maskedText`: PIIがマスクされたコンテンツ(モード = "Mask"の場合のみ)
|
||
- `error`: 検証が失敗した場合のエラーメッセージ
|
||
|
||
**ユースケース:**
|
||
- 機密性の高い個人情報を含むコンテンツをブロック
|
||
- データのログ記録や保存前にPIIをマスク
|
||
- GDPR、その他のプライバシー規制への準拠
|
||
- 処理前のユーザー入力のサニタイズ
|
||
|
||
## 設定
|
||
|
||
### 検証するコンテンツ
|
||
|
||
検証する入力コンテンツ。通常、以下から取得されます:
|
||
- エージェントブロックの出力: `<agent.content>`
|
||
- 関数ブロックの結果: `<function.output>`
|
||
- APIレスポンス: `<api.output>`
|
||
- その他のブロック出力
|
||
|
||
### 検証タイプ
|
||
|
||
4つの検証タイプから選択:
|
||
- **有効なJSON**: コンテンツが適切にフォーマットされたJSONかどうかを確認
|
||
- **正規表現マッチ**: コンテンツが正規表現パターンに一致するか検証
|
||
- **幻覚チェック**: LLMスコアリングによる知識ベースとの検証
|
||
- **PII検出**: 個人を特定できる情報を検出し、オプションでマスク
|
||
|
||
## 出力
|
||
|
||
すべての検証タイプは以下を返します:
|
||
|
||
- **`<guardrails.passed>`**: 検証が成功したかどうかを示すブール値
|
||
- **`<guardrails.validationType>`**: 実行された検証のタイプ
|
||
- **`<guardrails.input>`**: 検証された元の入力
|
||
- **`<guardrails.error>`**: 検証が失敗した場合のエラーメッセージ(オプション)
|
||
|
||
タイプ別の追加出力:
|
||
|
||
**幻覚チェック:**
|
||
- **`<guardrails.score>`**: 信頼度スコア(0-10)
|
||
- **`<guardrails.reasoning>`**: LLMの説明
|
||
|
||
**PII検出:**
|
||
- **`<guardrails.detectedEntities>`**: 検出されたPIIエンティティの配列
|
||
- **`<guardrails.maskedText>`**: PIIがマスクされたコンテンツ(モード = "マスク"の場合)
|
||
|
||
## ユースケース例
|
||
|
||
**解析前のJSONの検証** - エージェント出力が有効なJSONであることを確認
|
||
|
||
```
|
||
Agent (Generate) → Guardrails (Validate) → Condition (Check passed) → Function (Parse)
|
||
```
|
||
|
||
**幻覚の防止** - カスタマーサポートの回答を知識ベースと照合して検証
|
||
|
||
```
|
||
Agent (Response) → Guardrails (Check KB) → Condition (Score ≥ 3) → Send or Flag
|
||
```
|
||
|
||
**ユーザー入力のPIIをブロック** - ユーザーが提出したコンテンツをサニタイズ
|
||
|
||
```
|
||
Input → Guardrails (Detect PII) → Condition (No PII) → Process or Reject
|
||
```
|
||
|
||
## ベストプラクティス
|
||
|
||
- **条件ブロックと連携**: `<guardrails.passed>`を使用して検証結果に基づいてワークフローロジックを分岐
|
||
- **解析前のJSON検証**: LLM出力を解析する前に常にJSON構造を検証
|
||
- **適切なPIIタイプの選択**: パフォーマンス向上のため、ユースケースに関連するPIIエンティティタイプのみを選択
|
||
- **合理的な信頼度しきい値の設定**: 幻覚検出では、精度要件に基づいてしきい値を調整(高い = より厳格)
|
||
- **幻覚検出には強力なモデルを使用**: GPT-4oまたはClaude 3.7 Sonnetはより正確な信頼度スコアリングを提供
|
||
- **ログ記録用のPIIマスク**: PIIを含む可能性のあるコンテンツをログに記録または保存する場合は「マスク」モードを使用
|
||
- **正規表現パターンのテスト**: 本番環境にデプロイする前に正規表現パターンを徹底的に検証
|
||
- **検証失敗の監視**: `<guardrails.error>`メッセージを追跡して一般的な検証問題を特定
|
||
|
||
<Callout type="info">
|
||
ガードレールの検証はワークフローで同期的に行われます。幻覚検出については、レイテンシーが重要な場合は、より高速なモデル(GPT-4o-miniなど)を選択してください。
|
||
</Callout>
|