---
title: "Pydantic model_dumpの使い方：exclude・mode・by_aliasとmodel_validateでのORM変換【2.14対応】"
url: "https://www.issoh.co.jp/tech/details/19777/"
published: 2026-11-14
updated: 2026-11-14
categories: ["開発"]
publisher: "株式会社一創"
---

# Pydantic model\_dumpの使い方：exclude・mode・by\_aliasとmodel\_validateでのORM変換【2.14対応】

Pydanticの`model_dump()`は、モデルを辞書に書き出すメソッドです。逆向きに、辞書やORMの行からモデルを作るのが`model_validate()`です。この記事では、2026年11月時点の最新版pydantic 2.14.3を前提に、`model_dump()`の引数で出力を絞る方法、PATCHの部分更新で`exclude_unset`を使う手順、SQLAlchemyの行を`from_attributes`で変換するときの落とし穴を、コードで示します。v1の`dict()`や`parse_obj()`からの置き換え表も載せています。

## まとめ：model\_dumpとmodel\_validateで入出力をそろえる結論

APIの応答やファイルに書き出すなら`model_dump(mode="json")`か`model_dump_json()`を使います。既定の`mode="python"`は`datetime`や`Decimal`をそのまま残すため、`json.dumps()`に渡すと`TypeError`で止まる点が落とし穴です。出さない項目は、毎回の`exclude`ではなく`Field(exclude=True)`でモデルに固定する方が、出し忘れの事故を防げます。

部分更新では`exclude_unset=True`で「送られてきた項目だけ」を取り出し、元の値と合わせて`model_validate()`で作り直します。`model_copy(update=...)`は値を検証しないためです。ORMの行は`from_attributes`で変換できますが、リレーションは変換前に読み込んでおかないと、セッションを閉じた後にエラーになります。

## model\_dumpの引数一覧とmode=”python”と”json”の出力の違い

最初に引数の全体像と、`mode`で出力の型がどう変わるかを押さえます。[PyPIのpydantic](https://pypi.org/project/pydantic/)では、2026年11月14日時点の最新が2.14.3（11月5日公開・Python 3.10以上）です。

### model\_dumpとmodel\_dump\_jsonの引数と既定値を一覧で確認する

[v2.14.3のmain.py](https://github.com/pydantic/pydantic/blob/v2.14.3/pydantic/main.py)で、`model_dump()`の引数はすべてキーワード専用です。よく使うものを表にまとめます。

| 引数                        | 既定値      | 役割                 |
| ------------------------- | -------- | ------------------ |
| mode                      | “python” | “json”でJSON向けの型にする |
| include ／ exclude         | None     | 出す項目・出さない項目        |
| by\_alias                 | None     | 別名をキーにする           |
| exclude\_unset            | False    | 渡されなかった項目を除く       |
| exclude\_defaults         | False    | 既定値と等しい項目を除く       |
| exclude\_none             | False    | Noneの項目を除く         |
| exclude\_computed\_fields | False    | computed\_fieldを除く |
| context                   | None     | シリアライザへ渡す値         |
| warnings                  | True     | 型の食い違いの扱い          |

`model_dump_json()`も同じ引数を持ち、加えて`indent`と`ensure_ascii`を受け取ります。`exclude_computed_fields`と、呼び出しごとに型を判定し直す`polymorphic_serialization`は比較的新しい引数で、同じリポジトリの変更履歴ではそれぞれ2.12と2.13で追加されています。古い版に固定している環境では使えません。

### mode=”json”でdatetime・Decimal・setの出力が変わる型の対応表

```
from datetime import datetime
from decimal import Decimal
from uuid import UUID

from pydantic import BaseModel


class Order(BaseModel):
    order_id: UUID
    amount: Decimal
    tags: set[str]
    ordered_at: datetime


o = Order(
    order_id="6f1c2b1e-8a4d-4c3e-9b55-0d7c1e2f3a4b",
    amount="1280.50",
    tags={"gift"},
    ordered_at="2026-11-14T10:30:00",
)

print(o.model_dump())
# {'order_id': UUID('6f1c2b1e-8a4d-4c3e-9b55-0d7c1e2f3a4b'), 'amount': Decimal('1280.50'),
#  'tags': {'gift'}, 'ordered_at': datetime.datetime(2026, 11, 14, 10, 30)}

print(o.model_dump(mode="json"))
# {'order_id': '6f1c2b1e-8a4d-4c3e-9b55-0d7c1e2f3a4b', 'amount': '1280.50',
#  'tags': ['gift'], 'ordered_at': '2026-11-14T10:30:00'}
```

[公式のSerializationの解説](https://pydantic.dev/docs/validation/latest/concepts/serialization/)のとおり、`mode="json"`ではJSONで表せる型に変換されます。主な型の変わり方は次のとおりです。

| フィールドの型         | python（既定） | json      |
| --------------- | ---------- | --------- |
| datetime ／ date | そのまま       | ISO形式の文字列 |
| Decimal         | そのまま       | 文字列       |
| UUID            | そのまま       | 文字列       |
| set ／ tuple     | そのまま       | リスト       |
| ネストしたモデル        | 辞書         | 辞書        |

金額を`Decimal`で持つ場合、JSONでは数値ではなく文字列になる点に注意します。受け取る側が数値を前提にしているなら、後述の`field_serializer`で出力の型を決めておくのが確実です。ネストしたモデルは、どちらのモードでも再帰的に辞書へ変換されます。

### model\_dump\_jsonで日本語のエスケープとインデントを調整する指定

```
from pydantic import BaseModel


class Shop(BaseModel):
    name: str


s = Shop(name="一創")
print(s.model_dump_json())                   # {"name":"一創"}
print(s.model_dump_json(ensure_ascii=True))  # {"name":"一創"}
print(s.model_dump_json(indent=2))           # 2文字下げで改行した形
```

`model_dump_json()`の`ensure_ascii`は既定が`False`なので、日本語はそのまま出力されます。標準ライブラリの`json.dumps()`は既定が`True`で、`\u`から始まる表記に変わります。ログやファイルで日本語が読めない原因の多くは、`model_dump()`の結果を`json.dumps()`に渡していることです。既定の出力は空白を含まない詰めた形で、人が読む用途なら`indent`を指定します。

## include・excludeでネストしたモデルやリストの項目を絞る方法

`include`と`exclude`には、項目名の集合だけでなく、入れ子の辞書も渡せます。社内向けの値を応答から外すときによく使います。

### 辞書形式のexcludeでネスト先とリストの要素番号を指定する

```
from pydantic import BaseModel


class User(BaseModel):
    id: int
    name: str
    password_hash: str


class Item(BaseModel):
    sku: str
    cost: int   # 原価。社外に出さない
    price: int


class Order(BaseModel):
    user: User
    items: list[Item]


order = Order(
    user={"id": 1, "name": "taro", "password_hash": "x"},
    items=[{"sku": "A-1", "cost": 300, "price": 500}, {"sku": "B-2", "cost": 800, "price": 1200}],
)

print(order.model_dump(exclude={"user": {"password_hash"}, "items": {"__all__": {"cost"}}}))
# {'user': {'id': 1, 'name': 'taro'}, 'items': [{'sku': 'A-1', 'price': 500}, {'sku': 'B-2', 'price': 1200}]}

print(order.model_dump(include={"items": {0: {"sku"}}}))
# {'items': [{'sku': 'A-1'}]}
```

辞書の値に項目名の集合を書くとネスト先の項目を、整数のキーを書くとリストの何番目かを指定できます。`"__all__"`はリストの全要素に同じ指定を当てる書き方です。公式の解説では、`-1`で最後の要素も指定できます。ただし、除外の中で一部だけ戻すような`False`による反転は使えません。

### Field(exclude=True)とexclude\_ifで常に出さない項目を決める

```
from pydantic import BaseModel, Field


class Member(BaseModel):
    id: int
    login_id: str
    password_hash: str = Field(exclude=True)                       # どの呼び出しでも出さない
    point: int = Field(default=0, exclude_if=lambda v: v == 0)    # 0 のときだけ出さない


m = Member(id=1, login_id="taro", password_hash="x")
print(m.model_dump())                            # {'id': 1, 'login_id': 'taro'}
print(m.model_dump(include={"password_hash"}))   # {}
```

パスワードのハッシュや内部の管理番号のように、どの経路でも外に出してはいけない項目は`Field(exclude=True)`で固定します。公式の解説によると、フィールドに書いた除外はメソッドの`include`より優先されるため、呼び出し側の指定ミスで漏れることがありません。値に応じて出し分けたいときは、2.12で加わった`exclude_if`に判定の関数を渡します。Fieldの他の引数は[Pydantic Fieldの使い方と引数一覧](https://www.issoh.co.jp/tech/details/19771/)にまとめています。

## PATCHの入力で使い分ける未設定値・既定値・Noneの除外条件

名前が似た3つの除外オプションは、何を基準に除くかが異なります。取り違えると、部分更新で値を消せない不具合につながります。

### 3つの除外オプションを同じ入力に適用した場合の出力結果の比較表

```
from pydantic import BaseModel


class Profile(BaseModel):
    nickname: str
    bio: str | None = None
    theme: str = "light"


p = Profile(nickname="taro", theme="light")
print(p.model_fields_set)                    # {'nickname', 'theme'}（順序は不定）
print(p.model_dump(exclude_unset=True))      # {'nickname': 'taro', 'theme': 'light'}
print(p.model_dump(exclude_defaults=True))   # {'nickname': 'taro'}
print(p.model_dump(exclude_none=True))       # {'nickname': 'taro', 'theme': 'light'}
```

| オプション             | 除く基準        | 上の例のtheme |
| ----------------- | ----------- | --------- |
| exclude\_unset    | 作成時に渡されていない | 残る（渡した）   |
| exclude\_defaults | 既定値と等しい     | 消える       |
| exclude\_none     | 値がNone      | 残る        |

`exclude_unset`の判定に使われるのは`model_fields_set`で、作成時に明示的に渡した項目の集合です。既定値と同じ値でも、渡していれば残ります。公式の解説によると、作成後に属性へ代入した項目もこの集合に加わります。

### PATCHで未送信の項目を除外して更新値を再検証する実装の手順

```
from pydantic import BaseModel


class Profile(BaseModel):
    nickname: str
    bio: str | None = None
    theme: str = "light"


class ProfilePatch(BaseModel):   # PATCH 用。全項目を任意にする
    nickname: str | None = None
    bio: str | None = None
    theme: str | None = None


stored = Profile(nickname="taro", bio="Pythonが好きです", theme="dark")

patch = ProfilePatch.model_validate({"bio": None})   # 自己紹介だけ消したい
changes = patch.model_dump(exclude_unset=True)       # {'bio': None}

updated = Profile.model_validate(stored.model_dump() | changes)
print(updated)   # nickname='taro' bio=None theme='dark'
```

ここで`exclude_none`を使うと、「送られなかった」と「空にしたい（null）」の区別が付かず、`bio`を消せません。`exclude_unset`なら、送られてきた`null`だけが残ります。

合成には`model_copy(update=changes)`も使えますが、[公式のModelsの解説](https://pydantic.dev/docs/validation/latest/concepts/models/)のとおり、`update`の値は検証されません。クライアントが`{"nickname": null}`を送ると、`str`のはずの項目に`None`が入ったモデルができてしまいます。元の値と合わせた辞書を`model_validate()`に通せば、この入力は検証エラーとして止まります。

## field\_serializerとcomputed\_fieldで出力の形を作り替える方法

型ごとの既定の変換で足りないときは、シリアライザで出力の形を決めます。入力側の検証は[field\_validatorの使い方](https://www.issoh.co.jp/tech/details/19775/)で扱っており、ここは出力側の話です。

### field\_serializerのwhen\_usedでJSON出力時だけ形式を変える

```
from datetime import datetime

from pydantic import BaseModel, computed_field, field_serializer


class Invoice(BaseModel):
    subtotal: int
    issued_at: datetime

    @computed_field
    @property
    def tax(self) -> int:
        return int(self.subtotal * 0.1)   # 端数は切り捨て

    @field_serializer("issued_at", when_used="json")
    def to_jp_date(self, v: datetime) -> str:
        return v.strftime("%Y年%m月%d日")


inv = Invoice(subtotal=1000, issued_at="2026-11-14T09:00:00")
print(inv.model_dump())
# {'subtotal': 1000, 'issued_at': datetime.datetime(2026, 11, 14, 9, 0), 'tax': 100}
print(inv.model_dump(mode="json"))
# {'subtotal': 1000, 'issued_at': '2026年11月14日', 'tax': 100}
print(inv.model_dump(exclude_computed_fields=True))
# {'subtotal': 1000, 'issued_at': datetime.datetime(2026, 11, 14, 9, 0)}
```

[v2.14.3のfunctional\_serializers.py](https://github.com/pydantic/pydantic/blob/v2.14.3/pydantic/functional%5Fserializers.py)では、`field_serializer`の`when_used`に`"always"`（既定）、`"unless-none"`、`"json"`、`"json-unless-none"`の4種類を指定できます。`"json"`にすると、Pythonの処理で使う`model_dump()`では`datetime`のまま、画面やAPIに出すJSONでだけ和暦表記などに変えられます。

`computed_field`は、保存していない値を出力に足す仕組みです。既定で`model_dump()`に含まれるため、出力を入力として読み戻すと、存在しない項目として扱われます。読み戻す経路では`exclude_computed_fields=True`で外す指定が必要です。なお、v1でモデルの設定に書いていた`json_encoders`は、公式の移行ガイドで非推奨とされており、`field_serializer`か`PlainSerializer`に置き換えます。

### サブクラスの項目が落ちる件とserialize\_as\_anyの使いどころ

```
from pydantic import BaseModel, SerializeAsAny


class Animal(BaseModel):
    name: str


class Dog(Animal):
    breed: str


class Owner(BaseModel):
    pet: Animal


owner = Owner(pet=Dog(name="pochi", breed="shiba"))
print(owner.model_dump())                        # {'pet': {'name': 'pochi'}}
print(owner.model_dump(serialize_as_any=True))   # {'pet': {'name': 'pochi', 'breed': 'shiba'}}


class OwnerAny(BaseModel):
    pet: SerializeAsAny[Animal]   # このフィールドだけ実際の型で出す
```

v2では、型注釈が親クラスのフィールドに子クラスのインスタンスを入れても、出力されるのは親クラスで宣言した項目だけです。公式の移行ガイドにも、v1からの挙動の変更点として記載されています。子クラスで足した項目を出したいなら、フィールド単位で`SerializeAsAny`を付けるのが安全です。`serialize_as_any=True`は全項目に効くため、意図しない項目まで出る恐れがあります。2.13以降は、モデルの設定と呼び出しの両方で`polymorphic_serialization`も指定できます。

## model\_validateとfrom\_attributesでORMの行をモデルへ変換する

`model_validate()`は、辞書やオブジェクトを1つ受け取り、検証してモデルを作るクラスメソッドです。入力の形ごとに兄弟のメソッドがあります。

### model\_validateの引数とJSON・文字列辞書を検証するメソッドの選択

```
from pydantic import BaseModel, ValidationError


class Page(BaseModel):
    page: int
    size: int = 20


print(Page.model_validate({"page": "2"}))           # page=2 size=20（文字列を数値に変換）

try:
    Page.model_validate({"page": "2"}, strict=True)  # 呼び出しごとに厳密にする
except ValidationError as e:
    print(e.errors()[0]["type"])                    # int_type

print(Page.model_validate_json('{"page": 3}'))       # JSON 文字列はそのまま渡す
print(Page.model_validate_strings({"page": "4", "size": "50"}))   # 値がすべて文字列の入力

Page.model_validate({"page": 1, "debug": True}, extra="forbid")  # 余分な項目を拒否（2.12以降）
```

2.14.3の`model_validate()`は、`strict`、`extra`、`from_attributes`、`context`、`by_alias`、`by_name`を受け取ります。モデルの設定を変えずに、特定の経路だけ扱いを変えたいときに使う引数です。`model_validate_strings()`はJSONモードで検証するため、CSVやクエリ文字列のように値がすべて文字列の入力を、日時や数値へ変換できます。モデル全体の設定として持たせる場合は[ConfigDictの設定一覧](https://www.issoh.co.jp/tech/details/7583/)を参照してください。

### SQLAlchemyのリレーションを変換するときの遅延ロードの罠

`from_attributes`を有効にすると、辞書ではなく属性で値を持つオブジェクトを変換できます。v1の`orm_mode`に当たる設定です。SQLAlchemy 2.0系の書き方で、ユーザーと注文の1対多を変換する例を示します。

```
from pydantic import BaseModel, ConfigDict
from sqlalchemy import ForeignKey, create_engine, select
from sqlalchemy.orm import DeclarativeBase, Mapped, Session, mapped_column, relationship, selectinload


class Base(DeclarativeBase):
    pass


class UserOrm(Base):
    __tablename__ = "users"
    id: Mapped[int] = mapped_column(primary_key=True)
    name: Mapped[str]
    orders: Mapped[list["OrderOrm"]] = relationship(back_populates="user")


class OrderOrm(Base):
    __tablename__ = "orders"
    id: Mapped[int] = mapped_column(primary_key=True)
    user_id: Mapped[int] = mapped_column(ForeignKey("users.id"))
    total: Mapped[int]
    user: Mapped[UserOrm] = relationship(back_populates="orders")


class OrderOut(BaseModel):
    model_config = ConfigDict(from_attributes=True)
    id: int
    total: int


class UserOut(BaseModel):
    model_config = ConfigDict(from_attributes=True)
    id: int
    name: str
    orders: list[OrderOut]


engine = create_engine("sqlite://")   # メモリ上の SQLite
Base.metadata.create_all(engine)

with Session(engine) as session:
    session.add(UserOrm(id=1, name="taro", orders=[OrderOrm(id=10, total=1280)]))
    session.commit()
    # 注文を先に読み込んでおく（selectinload を外すと、下の変換で失敗する）
    user = session.scalars(select(UserOrm).options(selectinload(UserOrm.orders))).one()

print(UserOut.model_validate(user).model_dump())
# {'id': 1, 'name': 'taro', 'orders': [{'id': 10, 'total': 1280}]}
```

`from_attributes`による変換は、フィールド名と同じ属性を順に読みます。SQLAlchemyのリレーションは既定で遅延ロードなので、`orders`を読んだ瞬間がSQLの発行タイミングです。セッションを閉じた後だと、[SQLAlchemyのエラー解説（bhk3）](https://docs.sqlalchemy.org/en/20/errors.html#error-bhk3)にある`DetachedInstanceError`で失敗します。セッションの中で変換を済ませるか、[リレーションの読み込みガイド](https://docs.sqlalchemy.org/en/20/orm/queryguide/relationships.html)にある`selectinload`で先に読み込んでおきます。一覧の応答でユーザーごとにSQLが走るN+1問題を避ける意味でも、読み込み方は明示する方が安全です。

公式のModelsの解説の例では、ネストした側のモデルにも`from_attributes=True`を設定しています。応答用のモデルはまとめて設定しておくと迷いません。ORMとPydanticのモデルを1つのクラスにまとめる方法は[SQLModelの使い方](https://www.issoh.co.jp/tech/details/10322/)で扱っています。テーブル設計と合わせてAPIの入出力モデルを整理し直す改修は、[データベース設計・移行支援](https://www.issoh.co.jp/service/system/database/)でご相談を受け付けています。

### ORMから変換したモデルではexclude\_unsetが効かない理由

`from_attributes`で変換すると、属性として存在したフィールドはすべて「渡された値」として`model_fields_set`に入ります。ORMの行は全列を属性に持つため、`model_dump(exclude_unset=True)`にしても何も除かれません。NULLの列を応答から外したいなら`exclude_none=True`、既定値と同じ値を外したいなら`exclude_defaults=True`を使います。`exclude_unset`は、クライアントから届いた入力を扱うPATCHのような場面に限って使う、と覚えておきます。

## v1の辞書・JSON・ORM変換メソッドをv2へ置き換える手順と差異

v1のメソッドは2.14.3でも残っていますが、`PydanticDeprecatedSince20`の非推奨警告の対象です。[公式の移行ガイド](https://pydantic.dev/docs/validation/latest/get-started/migration/)の対応をまとめます。

### v1メソッドとv2メソッドの対応表と書き換え時に確認する挙動の差

| v1の書き方                | v2の書き方                      |
| --------------------- | --------------------------- |
| m.dict()              | m.model\_dump()             |
| m.json()              | m.model\_dump\_json()       |
| m.copy()              | m.model\_copy()             |
| Model.parse\_obj(d)   | Model.model\_validate(d)    |
| Model.parse\_raw(s)   | Model.model\_validate\_json |
| Model.from\_orm(o)    | Model.model\_validate(o)    |
| Config.orm\_mode      | from\_attributes            |
| Config.json\_encoders | field\_serializer           |

名前を置き換えるだけでは済まない箇所は、次に挙げる3つです。1つ目は`from_orm()`で、2.14.3のソースでは`from_attributes`を設定していないモデルで呼ぶと`PydanticUserError`になります。2つ目は`json()`で、移行ガイドによると`indent`などの引数を渡した場合は、分かりにくいエラーになる可能性があるため注意が必要です。3つ目はサブクラスの出力で、前の章のとおり親クラスの項目だけになります。

### copy(include=…)とexclude付きの複製を書き換える方法

v2の`model_copy()`は`update`と`deep`しか受け取らず、`include`や`exclude`はありません。2.14.3のソースにある`copy()`の説明では、次の形に書き換える方法が示されています。

```
# v1：order.copy(exclude={"items"}, update={"note": "再発行"})
data = order.model_dump(exclude={"items"}, round_trip=True)
data = {**data, "note": "再発行"}
copied = Order.model_validate(data)   # 複製し直すので値も検証される
```

`round_trip=True`は、書き出した値をそのまま入力として読み戻せる形にする指定です。複製し直す形なので、更新した値も検証の対象です。移行後のテストは`-W error::DeprecationWarning`を付けて走らせ、残った`dict()`や`parse_obj()`を洗い出します。メソッド名の対応はBaseModelの入門である[Pydanticの読み方・BaseModelの使い方とV1との違い](https://www.issoh.co.jp/tech/details/4838/)でも一覧にしています。

## よくある質問

model\_dumpとmodel\_validateについて出てくることの多い質問に、2026年11月時点の版（pydantic 2.14.3）で答えます。

### model\_dump()とdict(model)は何が違いますか？

`dict(model)`は、最上位のフィールド名と値の組を並べるだけです。ネストしたモデルはモデルのまま残り、`exclude`や別名、シリアライザも効きません。辞書の中まで変換したい、出力の規則をモデルの定義どおりに当てたい、という目的なら`model_dump()`を使います。

### model\_dumpのキーを別名（camelCase）にするにはどうすればよいですか？

呼び出しごとなら`model_dump(by_alias=True)`、モデル全体の既定にするならConfigDictの`serialize_by_alias=True`です。FastAPIの応答は既定で別名を使うため、テストで`model_dump()`した結果とキー名が食い違うことがあります。仕組みは[Fieldの使い方](https://www.issoh.co.jp/tech/details/19771/)の別名の章で説明しています。

### FastAPIの応答で未送信の項目を省くにはどうすればよいですか？

パス操作のデコレータに`response_model_exclude_unset=True`や`response_model_exclude_none=True`を指定すると、応答を作るときに同じ名前の除外が効きます。ただし、ORMから変換したモデルでは前述のとおり全項目が「渡された値」になるため、`exclude_unset`は効きません。リクエストの受け方と422の読み方は[FastAPIでPOSTを受け取る方法](https://www.issoh.co.jp/tech/details/19737/)で扱っています。

### 数千件のモデルをまとめてJSONにするときの書き方は？

リストを`for`で回して1件ずつ`model_dump()`するより、`TypeAdapter(list[OrderOut])`を作って`dump_json()`を呼ぶ方が、変換がpydantic-coreの中で1回で済みます。読み込みも同じで、JSON配列は`validate_json()`に文字列のまま渡す形です。`TypeAdapter`の生成には時間がかかるので、関数の中で毎回作らず、モジュールの最上位で1回だけ作ります。

### model\_dumpで「serialized value may not be as expected」と警告が出るのはなぜですか？

フィールドの型と実際の値が食い違っているときの警告です。`validate_assignment`を有効にしていないモデルに後から別の型の値を代入した場合や、`model_construct()`や`model_copy(update=...)`で検証せずに値を入れた場合に起きます。`warnings="error"`を指定すると例外に変わるので、テストではこちらにして食い違いを早めに見つけます。

## 関連記事

- [Pydanticとは？読み方・BaseModelの使い方とV1との違い【2.14対応】](https://www.issoh.co.jp/tech/details/4838/)：model\_dumpとmodel\_validateの土台になるBaseModelの入門です。
- [Pydantic v2のConfigDict設定一覧｜model\_configの書き方とv1からの移行【2.14対応】](https://www.issoh.co.jp/tech/details/7583/)：from\_attributesやserialize\_by\_aliasなどモデル全体の設定です。
- [Pydantic Fieldの使い方：default\_factory・alias・制約の引数一覧とOpenAPIへの反映【2.14対応】](https://www.issoh.co.jp/tech/details/19771/)：Field(exclude=True)や別名の種類の詳細です。
- [Pydantic field\_validatorの使い方：mode4種の違いとmodel\_validator・v1からの移行【2.14対応】](https://www.issoh.co.jp/tech/details/19775/)：model\_validateで動く入力側のバリデータです。
- [SQLModelとは？使い方・モデル定義・unique制約・FastAPI連携【0.0.48対応】](https://www.issoh.co.jp/tech/details/10322/)：ORMとPydanticのモデルを1つのクラスで扱う方法です。

---

出典: [Pydantic model\_dumpの使い方：exclude・mode・by\_aliasとmodel\_validateでのORM変換【2.14対応】](<https://www.issoh.co.jp/tech/details/19777/>)（株式会社一創）