Skip to main content

概要

ベンダーアダプターパターンは、ドメイン特化型エージェントやツールをShannonに統合することを可能にし、コアコードベースを汚染しません。このパターンは、以下の間にクリーンな分離を維持します:
  • 汎用Shannonインフラストラクチャ(オープンソースにコミット)
  • ベンダー特有の実装(プライベートまたは別のリポジトリに保持)

コア変更なし

Shannonのコアコードベースに変更は不要

クリーンな分離

汎用インフラストラクチャとベンダー特有のロジック

簡単なメンテナンス

ベンダーロジックは別のディレクトリに隔離

優雅なフォールバック

ベンダーモジュールがなくてもShannonは動作

ベンダーアダプタを使用するタイミング

ドメイン特有の要件を持つ独自または内部APIを統合する際にベンダーアダプタを使用してください。
ベンダーアダプタを使用する場合:
  • 独自/内部APIをドメイン特有の要件と統合する
  • OpenAPIツール用のカスタムリクエスト/レスポンス変換が必要
  • 特定のビジネスドメイン向けの専門的なエージェントを構築する
  • フィールド名の命名規則が内部システムと異なる
  • セッションコンテキストからの動的パラメータ注入が必要
  • カスタム認証またはヘッダーロジックが必要
使用例:
  • アナリティクスプラットフォーム(メトリクスのエイリアス、時間範囲の正規化)
  • Eコマースシステム(製品フィールドのマッピング、SKUの変換)
  • CRM統合(連絡先フィールドの正規化)
  • 内部マイクロサービス(カスタム認証トークン、テナントID)
  • ドメイン特有のデータ検証

アーキテクチャ

ファイル構造

コンポーネントの責任

クイックスタート例

架空のアナリティクスプラットフォーム「DataInsight」の完全なベンダー統合を作成しましょう。
1

ベンダーアダプタの作成

python/llm-service/llm_service/tools/vendor_adapters/datainsight.pyを作成します:
2

アダプタの登録

python/llm-service/llm_service/tools/vendor_adapters/__init__.pyを編集します:
3

設定オーバーレイの作成

config/overlays/shannon.datainsight.yamlを作成します:
4

ベンダーロールの作成(オプション)

python/llm-service/llm_service/roles/datainsight/analytics_agent.pyを作成します:
注:allowed_toolsの意味は/agent/queryに対して:
  • 省略/null → ロールプリセットがツールを有効にする可能性あり
  • [] → ツール無効
  • ["name", …] → これらのツールのみが利用可能(名前は登録されたツールと一致する必要あり)
python/llm-service/llm_service/roles/presets.pyに登録します:
5

環境変数の追加

.envに追加します:
6

統合のテスト

再構築してテストします:

コンポーネントガイド

1. ベンダーアダプタークラス

目的: ベンダー固有のAPI規約に合わせてリクエスト/レスポンスを変換する 一般的な変換パターン:
  • フィールドエイリアス: revenuetotal_revenue
  • メトリックプレフィックス: usersmy:users
  • 時間範囲の正規化: {start, end}{startTime, endTime}
  • ソート形式の変換: {field, order}{column, direction}
  • フィルタ構造の再構築: リスト → 論理演算子を持つオブジェクト
  • デフォルトの注入: セッションコンテキストから不足している必須フィールドを追加

2. 設定オーバーレイ

目的: 基本設定を変更せずにベンダー固有のツール設定を定義する ヘッダー値:
  • "${ENV_VAR}" - 環境変数から解決される
  • 静的文字列 - そのまま使用
リクエストボディからの動的ヘッダーテンプレート(例: {{body.field}})はサポートされていません。ヘッダーがボディ/セッションの値に依存する必要がある場合は、次のいずれかを行ってください:
  • OpenAPI仕様で明示的なヘッダーとして定義し、ツールパラメータとして渡す、または
  • ベンダーアダプターを使用してリクエストボディを整形し、ヘッダーは静的/環境駆動のままにする。

3. ベンダー役割

目的: ドメイン固有の知識とツール制限を持つ専門のエージェント テンプレート:
注: allowed_toolsを明示的に渡すと、リストに記載されたツールのみがLLMに利用可能になります。ツールを無効にするには空のリスト[]を渡してください。

ベストプラクティス

✅ 良い例: フィールド名を変換し、デフォルトを注入
❌ 悪い例: アダプター内のビジネスロジック
✅ 良い例:
❌ 悪い例:

テストと検証

ユニットテストアダプター

統合テスト

トラブルシューティング

症状: ログに「Vendor adapter ” applied」と表示される(空文字)修正:
症状: ImportError: No module named 'myvendor'修正:
症状: APIが元のボディを受け取る(変換されていない)デバッグ:
確認:
  1. __init__.pyにアダプターが登録されている
  2. 設定でベンダー名が一致している
  3. auth_config.vendorフィールドが存在する
  4. アダプターが修正された辞書を返す(Noneではない)
症状: アダプター内のprompt_paramsがNone原因: オーケストレーターがセッションコンテキストを送信していない修正: gRPCリクエストでコンテキストが送信されていることを確認:

概要

ベンダーアダプターの利点

  • ✅ クリーンな分離: 一般的なコードとベンダー固有のコード
  • ✅ Shannonコアの変更は不要
  • ✅ 優雅なフォールバックを伴う条件付き読み込み
  • ✅ 環境ベースのシークレット管理
  • ✅ 隔離してテスト可能
  • ✅ メンテナンスと拡張が容易
3つのコンポーネント:
  1. ベンダーアダプター - リクエスト/レスポンスの変換
  2. 設定オーバーレイ - ツールの設定
  3. ベンダーロール - 専門的なエージェント(オプション)
クイックリファレンス:

次のステップ

カスタムツール

カスタムツールの追加方法を学ぶ

Shannonの拡張

他の拡張方法を探る

設定

設定の完全なリファレンス

アーキテクチャ

Shannonのアーキテクチャを理解する