検証の追求：PydanticとVonage Verifyを用いたPythonでのデータ検証

このブログ記事では、Pythonで広く利用されているデータ検証ライブラリ「Pydantic」について紹介します。また、Vonage Verify API を使用して、Pydantic がもたらす価値を実演します。 

はじめに

Pythonにおけるダックタイピングとは何ですか？

その理由を理解するには Pydantic がこれほど有用なライブラリであるのかを理解するには、まずPythonにおける型付けの仕組みを理解することが重要です。プログラミングにおいて、「型付け」とは、データを分類・カテゴリ分けする仕組みを指します。データの型によって、そのデータに対してどのような操作が可能かが決まります。例えば、「two」という単語と数字の2を足し合わせることはできません。

Pythonの成功と人気の多くは、型に関する柔軟性に負っています。型を明示的に宣言する必要があるほとんどのコンパイル型言語とは異なり、Pythonでは ダックタイピングと呼ばれる仕組みを採用しています。ダックタイピングとは、「アヒルのように歩き、アヒルのように鳴くなら、それはアヒルに違いない」という前提に基づく動的型付けシステムです。

より具体的には、 Pythonのドキュメントによると、ダックタイピングとは：

「オブジェクトの型を確認して適切なインターフェースを持っているかどうかを判断するのではなく、単にメソッドや属性を呼び出したり使用したりするプログラミングスタイル……特定の型ではなくインターフェースを重視することで、適切に設計されたコードは多態的な置換を可能にし、柔軟性を高める。ダックタイピングでは、次のような型チェックを回避する type() または isinstance()を用いたチェックを回避する。」

実際の例としては、Pythonの len 関数です。 len() は「オブジェクトの長さ（要素の数）」を返します。以下のコードでは、 len() 呼び出されたオブジェクトの型に関係なく、正常に出力が生成される様子に注目してください：

>>> example_1 = "Hello? World!"
>>> type(example_1)
<class 'str'>

>>> example_2 = [1, 3, 5, 8]
>>> type(example_2)
<class 'list'>

>>> example_3 = {"hello" : "world", "foo": "bar"}
>>> type(example_3)
<class 'dict'>

>>> len(example_1)
13                                 # 13 letters in "Hello? World!"

>>> len(example_2)
4                                  # 4 items in the list

>>> len(example_3)
2                                  # 2 key-value pairs in the dictionary

現実のPythonで実際に目にする可能性が高い動的型付けの例として、以下のコードでは、それぞれ bark():

class Pug:
    def bark(self):
        print("The pug goes arf arf!")

class LabradorRetriever:
    def bark(self):
        print("The labrador retriever goes arf arf!")

class Wolfhound:
    def bark(self):
        print("The wolfhound goes arf arf!")

各犬種について1頭ずつインスタンスを作成し、 bark() 各犬に対して インターフェースを備えているため、各犬種のインスタンスを1つずつ作成し、それらすべてに対してを呼び出してもエラーは発生しません。ダックタイピングのおかげで、次のコードは正常に実行されます：

>>> pets = [Pug(), LabradorRetriever(), Wolfhound()]

>>> for pet in pets:
...     pet.bark()

The pug goes arf arf!
The labrador retriever goes arf arf!
The wolfhound goes arf arf!

pet クラス Pug、 LabradorRetriever、あるいは Wolfhound であっても、Pythonは bark 関数をエラーなしで呼び出します。

 これは便利であり、多くの場面ではまさに望ましい動作です。スクリプト作成、データサイエンス、探索的な作業において、Pythonの動的型付けはバグではなく、むしろ機能なのです。 ダックタイピングにより、厳格な型宣言によるオーバーヘッドなしに、迅速に反復処理を行うことができます。これが、PythonがAIやデータサイエンスのワークフローにおいて主流の言語となった大きな理由の一つです。

しかし、本番環境のバックエンドコードでは状況が大きく異なります。型が宣言されていない Flask や Django アプリケーションでは、メンテナンスやデバッグの際に支障が生じることがあります。Python のダックタイピングでは、型の不一致は明確で早期に検出されるエラーではなく、意味不明な実行時エラーとして現れます。 この問題は、APIとの連携、設定ファイルの処理、ユーザー入力の処理など、Applicationsが意図した通りに動作するために特定のデータ型に依存している場合、さらに深刻になります。 

たとえば、次のようなクラスを定義した場合：

class Sphynx:
    def meow(self):
        print("The sphynx goes meow meow!")

そして、サンプルコードを更新して、 Sphynx を pets を反復処理する際、エラーが発生します：

>>> pets = [Pug(), LabradorRetriever(), Sphynx()]

>>> for pet in pets:
...     pet.bark()
...     

The pug goes arf arf!
The labrador retriever goes arf arf!
Traceback (most recent call last):
  File "<python-input-74>", line 2, in <module>
    pet.bark()
    ^^^^^^^^
AttributeError: 'Sphynx' object has no attribute 'bark'

この例が示すように、特定の状況下では、ダックタイピングの柔軟性がかえって足かせとなることがあります。たとえば、API呼び出しに誤った型が渡されても、リクエストがすでに送信されてからでないとエラーにならない場合があり、最初から失敗が確定していた有料の呼び出しに対して、無駄な費用が発生する可能性があります。

動的型付けに伴う問題のいくつかを解決する方法の一つは、Pythonの 型ヒントです。

型アノテーションとは何ですか？

型ヒントとは、「変数、クラス属性、関数の引数や戻り値に対して期待される型を指定する」ことを示すコード注釈です。したがって、 型アノテーション とは、Pythonにおいて型ヒントが構文的にどのように使用されるかを指します。

以下のコードは、型アノテーションの使用に関する基本的な例です：

def greeting(name: str) -> str:
    return 'Hello ' + name

この例では、型ヒントは str であり、型アノテーションは name: str であり、 -> str という構文です。この型注釈は、パラメータ name の期待される型が文字列であり、関数 greeting の期待される戻り値の型が文字列であることを示しています。

例に型注釈を追加すると、 Pug クラスの例に型注釈を追加すると、次のようになります:

class Pug:
    def init(self, name: str) -> None:
        self.name: str = name

    def bark(self) -> None:
        print(f"The pug {self.name} goes arf arf!")

また、 pets 反復処理のコードを型注釈を含めるように更新すると、次のような形になるでしょう：

def make_dogs_bark(pets: List[Pug | LabradorRetriever | Wolfhound ]) -> None:
    for pet in pets:
        pet.bark() 

make_dogs_bark([Pug(), LabradorRetriever(), Sphynx()])

その名の通り、これらは単なる のヒントに過ぎませんに過ぎません。これらはコードの可読性や保守性を高めるのに役立ちますが、Pythonインタプリタによって強制されるものではありません。 mypy のような追加ツールを使って型をチェックし、次のようなエラーメッセージを受け取ることもできます：

error: List item 2 has incompatible type "Sphynx"; expected "Pug | LabradorRetriever | Wolfhound"  [list-item]

これは追加の手順として実行する必要があります。このコードが実行され、実行時にエラーが発生することを妨げるものは何もありません。

承認を求めて

実行時のエラー（誤ったデータによるAPI呼び出しなど）を防ぐために、次のようにすることもできます。 リクエスト内のデータを リクエスト内のデータを検証 送信する前に 送信する前にリクエスト内のデータを検証することができます。サンプルコードでは、リスト内の各項目が pets が bark():

def make_dogs_bark_safely(dogs):
    """Manual validation in the function"""
    for dog in dogs:
        if not hasattr(dog, 'bark') or not callable(getattr(dog, 'bark')):
            raise TypeError(f"Invalid dog type: {type(dog).__name__}")
        dog.bark()

# Now this fails immediately with a clear message:
pets = [Pug(), Sphynx()]

make_dogs_bark_safely(pets)
# TypeError: Invalid dog type: Sphynx

このパターンは、すぐに煩わしく扱いにくくなるだけでなく、Pythonが本来持つ動的型付けの利便性を損なう一方で、型注釈のメリットの一部も享受できなくなってしまいます。

幸いなことに、 Pydantic は、すでに組み込まれている構文を活用することで、この言語の使いやすさと処理速度を維持しつつ、データ検証機能を提供しています。

Pydanticとは何ですか？

Pydantic は、Python用のデータ検証ライブラリであり、次のような利点があります：

• 活用 型ヒント を利用して スキーマの検証とシリアライゼーションを制御する。

• 用途 内部ではRustを採用 コアとなる検証ロジックにRustを採用しているため、パフォーマンスへの影響は最小限に抑えられています。

• 以下の 多くの標準ライブラリ型の を含む dataclass および TypedDictなど。

• どちらのモードでも動作します 厳格モードまたは寛容モードの で動作します。

• 出力可能 JSONスキーマを を標準で出力できるため、他のツールとのシームレスな連携が可能です。

• モデルからドキュメントを自動的に生成します。

これらの機能が実際にどのように組み合わさり、Pythonの構文や構造と調和しながら、信頼性が高く効率的なデータ検証を実現するのか、詳しく見ていきましょう。

Pydanticの主な検証機能

Pydanticにおいて、「バリデーション」とは「指定された型や制約に従うモデル（またはその他の型）をインスタンス化するプロセス」を指すことを理解することが重要です。つまり、Pydanticのバリデーションは、入力データではなく、モデルのインスタンス化の結果に適用されます。そのため、データをモデルのインスタンスとして正常にパースできない場合、Pydanticは ValidationError を発生させます。

BaseModel

BaseModel はPydanticの中核をなすものです。これから継承することで、型注釈付きのフィールドを持つデータモデルを定義します。Pydanticでスキーマを定義する主な方法の一つは、モデルを用いることです。 BaseModel Pydanticは、定義されたスキーマに基づいてデータを自動的に検証します。

Pydantic を使用すると、 Pug クラスは次のような形になります：

class Pug(BaseModel):
    name: str
    age: int
    color: str = "fawn"

    def bark(self):
        print(f"The pug {self.name} goes arf arf!")

もし Pug場合、Pydanticは結果として得られるオブジェクトが name 文字列型のプロパティ、 age 整数型の、および color 文字列型の fawn がデフォルト値として設定された文字列型のを持つことを保証します。

型ヒントと必須フィールド

型アノテーションは、スキーマの検証とシリアライズを制御します。型アノテーションのみで宣言されたフィールドは必須であり、デフォルト値が設定されたフィールドはオプションです。

例えば Pug この例では、 name フィールドには str と注釈が付けられており、任意の文字列で構わないことを意味しますが、文字列 は 指定する必要があります。これは age フィールドにも同じことが当てはまります。ただし、 color フィールドについては、デフォルト値として fawn が設定されているため、 Pug。

型の強制変換

Pydantic は、厳格モードまたはデフォルトの寛容モードのいずれかで使用できます。寛容モードでは、ライブラリがデータをスキーマで定義された型に自動的に変換します。

たとえば、 "5" を age の引数として文字列として渡した場合、 Pugの引数としてを文字列として渡した場合、Pydanticはそれを整数に変換します。

フィールドの設定

この Field この関数を使用すると、スキーマフィールドに対してメタデータや制約を追加できます。

よく使われるパラメータには、次のようなものがあります：

• 制約条件 例えば、 gt) や「より大きいか等しい」 ge）や min_length および max_length

•  エイリアス 以下の機能を使用して、入力および出力フィールド名をマッピングするための alias、 validation_alias、および serialization_alias)

• 厳格モード 特定のフィールドでの型変換を防ぐため strict=True)

name フィールドに対して Pugに対して制約を適用するには、次のコードを使用します：

class Pug(BaseModel):
    name: str = Field(..., min_length=1, description="The pug's name")
    age: int
    color: str = "fawn"

    def bark(self):
        print(f"The pug {self.name} goes arf arf!")

連載

Pydanticのモデルインスタンスは、 model_dump()を使用することで、追加のシリアライズコードを記述することなく、Pydanticのモデルインスタンスを辞書に変換できます。これにより、プロジェクト内の他の場所で利用するために、JSONやその他の形式へ簡単にシリアライズできます。例えば、 model_dump_json() は、モデルを直接 JSON にシリアライズします。

以下は、 Pug インスタンスを作成し、Pydanticの組み込み関数のいずれかを使用してそれをシリアライズする例です：

matty_pug = Pug(name="Matty", age=14)

result = matty_pug.model_dump()

print(result)

これにより、次のような出力が得られます：

{'name': 'Matty', 'age': 14, 'color': fawn}

Pydanticの実際の活用事例にはどのようなものがありますか？

Pydanticは登場以来、Python向けのデータ検証ライブラリとして、瞬く間に最も広く利用されるものの一つとなりました。PyPI上では、FastAPI、huggingface、Django Ninja、SQLModel、LangChain、Vonageなど（中でも特に有名なものとして）、約8,000のパッケージがPydanticを利用しています。

2024年11月、Vonageは は、Vonage Python SDKをゼロから全面的に書き直したバージョンをリリースしましたをリリースしました。一から作り直すのは必ずしも容易なことではありませんが、この書き換えは、重要な構造的強化を行い、SDKとのユーザーインタラクションを改善する絶好の機会となりました。

この取り組みに含まれる変更点の一つとして、Vonage APIの呼び出しやレスポンスの解析を容易にするため、SDKにPydanticが追加されました。

以下のVideoをご覧いただき、Python SDKの開発に携わる当社の開発者の一人が、Pydanticの使用についてどのような感想を語っているか、ぜひお聞きください。

Vonage Python SDK における Pydantic モデルの活用方法

Pydantic モデルを使用してリクエストを構成することで、正しい型付けが保証され、Vonage API へ適切なオブジェクトを簡単に渡すことができます。SDK バージョン 4 では、API のレスポンスが完全にドキュメント化された Pydantic モデルとして逆シリアル化されるようになり、以前のバージョンのように辞書（ディクショナリ）を返す場合よりも一貫性が高まっています。 さらに、 model.model_dump および model.model_dump_json を使用して、Pydanticモデルをそれぞれ辞書やJSON文字列に変換することも可能です。

このデモでは、Vonage Verify API について、また SDK 内で Pydantic を使用してどのようにモデル化されているかを見ていきます。

Vonage Verify APIとは何ですか？

Verify APIは、Vonageが提供する次世代の二要素認証（2FA）製品です。Verify APIを利用すれば、2FAの複雑さを世界規模で抽象化した、シンプルで使いやすいAPIを通じて、ユーザーの認証を行い、不正利用を防止することができます。

この技術は、SMS、Voice、電子メールに加え、WhatsAppのようなオーバー・ザ・トップ（OTT）チャネルなど、より幅広いチャネルに対応することで、従来の認証手法を拡張しています。このAPIは、 JSON Webトークン （JWT）と ベーシック認証の両方をサポートしています。ベーシック認証は導入が容易ですが、ACL（アクセス制御リスト）などの高度な機能にはの両方をサポートしています。Basic認証は導入が容易ですが、ACLなどの高度な機能には対応していません。JWTまたはBasic認証のいずれかを使用できますが、両方を同時に使用することはできません。認証に関する詳細は、 ドキュメントで詳しく確認できます。

大まかに言えば、Verify API のワークフローは以下の通りです：

1. エンドユーザーがアプリケーション内で2FAのリクエストを発行する

2. バックエンドでは、この2FAリクエストによってVerify APIリクエストが開始されます

3. Verify APIは、設定された通信手段（SMS、音声、WhatsApp、またはメール）を通じて、エンドユーザーにワンタイムパスワード（OTP）を送信します。

4. エンドユーザーは、アプリケーションにOTPを入力します

5. これにより、エンドユーザーから提供されたOTPと、APIによって生成されたOTPとを照合するためのVerifyリクエストが開始されます。

6. その確認の結果によって、その後の処理（エンドユーザーの認証など）が決まります。

A diagram of the Verify V2 Request with Summary Callbacks.典型的な初期検証リクエストには、次のようなペイロードが含まれます：

{

   "locale": "es-es",
   "channel_timeout": 180,
   "client_ref": "myPersonalRef",
   "code_length": 4,
   "code": "e4dR1Qz",
   "brand": "ACME",
   "template_id": "4ed3027d-8762-44a0-aa3f-c393717413a4",
   "workflow": [
      {
         "channel": "silent_auth",
         "to": "44770090000",
         "redirect_url": "https://acme-app.com/sa/redirect"
      },
      {
         "channel": "sms",
         "to": "44770090000"
      },
      {
         "channel": "voice",
         "to": "44770090000"
      }
   ]
}

これについては、以下でさらに詳しく説明しています：

APIの詳細やその仕組みについては、 Vonage Verifyのドキュメントを参照してください。

リクエストが成功すると、 202 OK を返し、検証リクエストが開始されたことを示します。また、この応答には、 request_id が含まれており、これは検証プロセスを完了するために必要です：

{
   "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
   "check_url": "https://api.nexmo.com/v2/verify/c11236f4-00bf-4b89-84ba-88b25df97315/silent-auth/redirect"
}

同時に、Vonageは設定されたワークフローを通じてエンドユーザーにOTPを送信し、定義された順序に従って各チャネルを順次試行します。

エンドユーザーがOTPを受け取り、アプリケーションにそのOTPを入力すると、Verifyエンドポイントにまた別のリクエストを送信する。 request_id をパスパラメータとして指定し https://api.nexmo.com/v2/verify/:request_id）を指定し、リクエスト本文にOTPを code key:

{
   "code": "1234"
}

提供されたコードが、Vonageによって生成・送信されたコードと一致する場合、 200 OK レスポンスが返されます。

デモ：Verify API は Pydantic をどのように利用しているのか？

Vonage Python SDK を使用すると、Python アプリケーション内で Vonage API を実装しやすくなります。この SDK に Pydantic を導入することで、API の利用がさらに簡単になります。Pydantic を使用すれば、エラーを個別に特定する必要がなく 後に API呼び出しを行って課金が発生してしまうのではなく、リクエストモデルが 実行 実行前に検証されるため、追加のコードを記述する必要がありません。

このブログ記事で紹介するデモは、FastAPIフレームワークを使用した最小限の2FAアプリケーションです。エンドユーザーはWebページにアクセスし、メールアドレスを入力します。その後、アプリケーションはVerify APIを使用してOTPコードを生成し、エンドユーザーが指定したメールアドレスに送信します。 エンドユーザーはそのコードをアプリケーションに入力し、Verifyの検証に成功すると、アニメーションGIFが報酬として表示されます。 

もしよければ、 コードに直接アクセスし、READMEを参照して動作させることも可能です。

Verifyリクエストが作成されるのは、以下のコードの部分です：

   verify_request = VerifyRequest(
        brand=settings.verify_brand_name,
        workflow=[
            EmailChannel(to=email),
        ],
        channel_timeout=60,
        code_length=5,
    )

もし VerifyRequest オブジェクトの中を覗いてみると、Pydanticモデルが見つかります：

class VerifyRequest(BaseModel):
    brand: str = Field(..., min_length=1, max_length=16)
    workflow: list[
        Union[
            SilentAuthChannel,
            SmsChannel,
            WhatsappChannel,
            VoiceChannel,
            EmailChannel,
        ]
    ]
    locale: Optional[Locale] = None
    channel_timeout: Optional[int] = Field(None, ge=15, le=900)
    client_ref: Optional[str] = Field(None, min_length=1, max_length=16)
    code_length: Optional[int] = Field(None, ge=4, le=10)
    code: Optional[str] = Field(None, pattern=r'^[a-zA-Z0-9]{4,10}$')

    @model_validator(mode='after')
    def check_silent_auth_first_if_present(self):
        if len(self.workflow) > 1:
            for i in range(1, len(self.workflow)):
                if isinstance(self.workflow[i], SilentAuthChannel):
                    raise VerifyError(
                        'If using Silent Authentication, it must be the first channel in the "workflow" list.'
                    )
        return self

このスキーマは、APIリクエストをPythonの注釈と Field 関数を用いて制約を定義します。 workflow fieldは、 Union 他のモデル化された型の型として定義され、型がどのようにネストできるかを示しています。

最後に、 model_validator(mode='after') は、 VerifyRequest モデルの検証方法に関する追加の設定を提供するPydanticのデコレータです。この場合、 def check_silent_auth_first_if_present メソッドは 実行されます モデルが VerifyRequest モデルが構築された後に実行され、 SilentAuthChannel がワークフローに含まれている場合は、必ず最初にリストアップされなければなりません。

メールによる確認

仮想環境を生成・有効化し、 READMEに従って必要な依存関係をインストールした後、以下のコマンドでデモアプリケーションを実行できます：

fastapi dev

これにより、 http://127.0.0.1:8000:

A screenshot of the index page inviting the end-user to enter their email address to try out the Vonage Verify API.をクリックすると 「認証コードを送信」 をクリックすると、Verify APIのワークフローが開始されます。指定したメールアドレスに送信されたコードを入力できるWebページに遷移します：

A screenshot of the verification page inviting the end-user to enter the code they received in their email.ここに正しいコードを入力すると、成功ページに移動します。

内部的には、この コードは、SDK内のPydanticモデルを活用して を活用し、Verifyリクエストが正しく構成され、処理されるようにしています。

検証なしの検証：Pydantic を使わないテスト

それでは、PydanticがVerify APIをどのように活用しているのかを見てみましょう。

以下のコードには、同じタスク、つまり /verify エンドポイントへのリクエストを行う。一方の関数はリクエスト本文を手動で作成し、もう一方の関数はPydanticを使用しています。

手動で作成したリクエスト本文を使用する場合：

def without_pydantic(request_payload):

    jwt_client = JwtClient(
        application_id=settings.vonage_application_id,
        private_key=settings.vonage_private_key_path,
    )

    jwt_token = jwt_client.generate_application_jwt()

    payload = {
        "brand": request_payload["brand"],
        "workflow": [
            {
                "channel": "email",
                "to": request_payload["to_email"],
            }
        ],
        "channel_timeout": request_payload["channel_timeout"],
        "code_length": request_payload["code_length"],
    }

    response = requests.post(
        "https://api.nexmo.com/v2/verify",
        headers={
            "Authorization": f"Bearer {jwt_token.decode()}",
            "Content-Type": "application/json",
        },
        json=payload,
    )

    return response

Pydantic の使用方法：

def with_pydantic(request_payload):

    client = Vonage(
        Auth(
            application_id=settings.vonage_application_id,
            private_key=settings.vonage_private_key_path,
        )
    )

    verify_request = VerifyRequest(
        brand=request_payload["brand"],
        workflow=[EmailChannel(to=request_payload["to_email"])],
        channel_timeout=request_payload["channel_timeout"],
        code_length=request_payload["code_length"],
    )

    client.verify.start_verification(verify_request)

    last_response = client.http_client.last_response

    return last_response

その後、このコードでは unittest を使用して、APIパラメータに違反する test_data APIのパラメータに違反する値で関数をテストします：

   test_data = {
        "brand": 12345,
        "to_email": 678910,
        "channel_timeout": "sixty",
        "code_length": "five",
    }

次のコマンドでテストを実行してください：

python -m unittest -v

テストを実行すると、2つの異なる結果（エラーと失敗）が得られるはずです。

Pydantic を使用する関数のテストでは、次のエラーが返されるはずです：

pydantic_core._pydantic_core.ValidationError: 1 validation error for EmailChannel
to
  Input should be a valid string [type=string_type, input_value=678910, input_type=int]
    For further information visit https://errors.pydantic.dev/2.13/v/string_type

ここで重要なのは、このテストが は失敗しなかった ――むしろ、Pydanticが不正なデータ型を検出したためにエラーが発生した リクエストが送信される前に リクエストが送信される前に、Pydanticが不正なデータ型を検出したため、エラーが発生したということです。さらに、エラーメッセージ自体も、一般的な型エラーメッセージではなく、デバッグに役立つ情報を提供しています。提供されたデータ型がモデルの要件を満たしていなかったことが分かるだけでなく、期待される型や渡された型についても把握できます：

Input should be a valid string [type=string_type, input_value=678910, input_type=int]

関数 がない場合の Pydanticを使用しない場合、失敗が返されます：

AssertionError: 422 != 202 : Test without Pydantic failed with: 422. Expected: 202

これは、リクエストが行われたことを意味し、 APIの定義通り、無効なパラメータが返された 422 無効なパラメータのため、 

この限定的なテストシナリオでは、1回の誤ったAPI呼び出しは無視できる程度ですが、より広い規模では、これは大きな損失につながる可能性があります。API呼び出しを行う前にPydanticを使用してリクエストモデルを検証することで、無駄なAPI呼び出しを最小限に抑え、よりスムーズなエラー処理が可能になり、開発者の作業が円滑になります。

まとめ

Pydantic は、Python におけるデータ検証のための強力かつ高性能なソリューションを提供し、開発者がダックタイピングに伴う潜在的な落とし穴を回避できるよう支援します。 Pydantic モデルを用いてスキーマ、制約、および検証ルールを定義することで、データの整合性を確保し、API リクエストが送信される前にエラーを捕捉することができます。これにより、コストのかかる無効な API 呼び出しを防ぎ、エラー処理をよりスムーズに行うことができます。

Vonage Python SDKとVerify APIの統合例が示すように、Pydanticを使用することで、複雑でネストされたリクエストモデルを簡単に扱えるだけでなく、コードの可読性と保守性も維持できます。 SDK バージョン 4 では、API レスポンスが完全にドキュメント化された Pydantic モデルにデシリアライズされるため、一貫性が向上し、ツールによるサポートが強化され、全体としてよりクリーンな開発体験が得られます。

関連文献および参考文献

• Verify APIにおけるサイレント認証の更新: Verify APIにおける新しいサイレント認証の更新により、開発・テスト環境での体験が向上します。

• Silent AuthとVideo APIを活用したパスワード不要のビデオログインの構築: Vonage VideoとSilent Authを組み合わせて、パスワードや認証コードなしでユーザーを自動的にVerifyし、リアルタイムセッションをより迅速に開始しましょう。

• WhatsApp向け「ゼロタップ認証」のご紹介: Vonage Verify v2 API を通じて、WhatsApp向けのゼロタップ認証が利用可能になったことをお知らせします。