外部 API SDK の具象クライアントをサービス実装に直接埋め込むと、ユニットテストが実通信・SDK内部型・環境変数に引きずられやすい。サービスの責務が「リクエスト組み立て、レスポンス変換、stream終了処理、エラー伝播、履歴やツール呼び出しの制御」にある場合は、SDK全体をモックしようとせず、サービスが実際に使うメソッドだけを持つ薄い adapter interface を内側に置くとよい。

判断基準:

• 公開サービス interface は既存利用側のために維持し、SDK差し替え用の interface は実装パッケージ内の非公開型にする。
• 本番コンストラクタは SDK クライアントを adapter で包み、テスト用コンストラクタだけ fake client を注入できるようにする。
• SDKのデータ型がドメインへ漏れていない実装内部であれば、レスポンス型まで再定義せず SDK の値型をそのまま fake で返すと変換層が増えない。
• streaming SDK では Recv/Next と Close だけを抽象化し、EOF系の正常終了、途中エラー、channel close、resource close をテストで固定する。
• チェーン状の SDK（client → model → chat session → iterator）は、各段階の状態変更を検証できる程度に小さく interface を分ける。

注意点: SDK具象型を公開 API に出すと後から差し替えにくい。逆に最初から汎用すぎる抽象を作ると SDK 仕様を二重実装することになるため、まずは対象サービスが使う最小メソッドだけに絞る。外部 API そのものの互換性確認は統合テストの役割で、単体テストでは実通信なしで自前ロジックを検証する。