---
title: "モデルの Meta オプション"
version: 5.2
locale: ja
source: https://docs.djangoproject.com/ja/5.2/ref/models/options/
canonical: https://djangodocs.dev/ja/5.2/ref/models/options/
---
# モデルの `Meta` オプション

このドキュメントでは、モデル内部の `class Meta` 内でモデルに与えられる、すべての可能な [メタデータオプション](/ja/5.2/topics/db/models/#meta-options) を説明します。

## 利用可能な `Meta` オプション

### `abstract`

#### `Options.abstract`

`abstract = True` の場合、このモデルは [抽象基底クラス](/ja/5.2/topics/db/models/#abstract-base-classes) になります。

### `app_label`

#### `Options.app_label`

モデルが [`INSTALLED_APPS`](/ja/5.2/ref/settings/#std-setting-INSTALLED_APPS) でアプリケーションの外部で定義されている場合、どのアプリケーションに属するかを宣言する必要があります：

```
app_label = "myapp"
```

モデルを `app_label.object_name` または `app_label.model_name` という形式で表現したい場合は、それぞれ `model._meta.label` または `model._meta.label_lower` を使用します。

### `base_manager_name`

#### `Options.base_manager_name`

モデルの [`_base_manager`](/ja/5.2/topics/db/managers/#django.db.models.Model._base_manager) に使用するマネージャの属性名、例えば `'objects'` です。

### `db_table`

#### `Options.db_table`

モデルに使用するデータベーステーブルの名前：

```
db_table = "music_album"
```

#### テーブル名

手間を省くために、Django はモデルクラスとそれを含むアプリの名前から、データベーステーブルの名前を自動的に生成します。モデルのデータベーステーブル名は、モデルの "app label" ([`manage.py startapp`](/ja/5.2/ref/django-admin/#django-admin-startapp) で使った名前) とモデルのクラス名をアンダースコアでつないで作ります。

例えば、アプリ `bookstore` (`manage.py startapp bookstore` で作成) がある場合、`class Book` として定義されたモデルは `bookstore_book` という名前のデータベーステーブルを持ちます。

データベーステーブル名を上書きするには、 `class Meta` の `db_table` パラメータを使用します。

データベースのテーブル名が SQL の予約語だったり、 Python の変数名では許されない文字（特にハイフン）を含んでいたりしても大丈夫です。Django は裏でカラム名とテーブル名をクォート処理します。

> **MariaDB と MySQL では小文字のテーブル名を使いましょう**
>
> 特に MySQL バックエンドを使用している場合は、`db_table` でテーブル名をオーバーライドする際に小文字のテーブル名を使うことを強くお勧めします。詳細は [MySQLのノート](/ja/5.2/ref/databases/#mysql-notes) を参照してください。

> **オラクルのテーブル名のクォート処理**
>
> Oracle のテーブル名の上限である 30 文字の制限を満たし、Oracle データベースの一般的な慣例に合わせるため、 Django はテーブル名を短くしたり、すべて大文字にしたりすることがあります。このような変換を防ぐには、 `db_table` の値として引用符で囲まれた名前を使います：
>
> ```
> db_table = '"name_left_in_lowercase"'
> ```
>
> このような引用符で囲まれた名前は、Django がサポートしている他のデータベースバックエンドでも使用できます。詳しくは [Oracleのノート](/ja/5.2/ref/databases/#oracle-notes) を参照してください。

### `db_table_comment`

#### `Options.db_table_comment`

このモデルに使うデータベーステーブルのコメントです。あなたの Django コードを見ていない、直接データベースにアクセスできる人のために、 データベーステーブルをドキュメント化するのに便利です。たとえば以下のようにします：

```
class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    answer = models.TextField()

    class Meta:
        db_table_comment = "Question answers"
```

### `db_tablespace`

#### `Options.db_tablespace`

このモデルに使用する [データベーステーブル空間](/ja/5.2/topics/db/tablespaces/) の名前です。デフォルトはプロジェクトの [`DEFAULT_TABLESPACE`](/ja/5.2/ref/settings/#std-setting-DEFAULT_TABLESPACE) 設定です。バックエンドがテーブル空間をサポートしていない場合、このオプションは無視されます。

### `default_manager_name`

#### `Options.default_manager_name`

モデルの [`_default_manager`](/ja/5.2/topics/db/managers/#django.db.models.Model._default_manager) に使用するマネージャの名前。

### `default_related_name`

#### `Options.default_related_name`

リレーション先オブジェクトからこのオブジェクトへのリレーションにデフォルトで使用される名前です。デフォルトは `<model_name>_set` です。

このオプションは [`related_query_name`](/ja/5.2/ref/models/fields/#django.db.models.ForeignKey.related_query_name) も設定します。

フィールドの逆引き名は一意でなければならないので、モデルをサブクラス化する場合は注意してください。名前の衝突を回避するため、名前の一部に `'%(app_label)s'` と `'%(model_name)s'` を含めるべきです。これらはそれぞれ、モデルが存在するアプリケーションの名前とモデルの名前に置き換えられます。[抽象モデルの related name](/ja/5.2/topics/db/models/#abstract-related-name) の段落を参照してください。

### `get_latest_by`

#### `Options.get_latest_by`

モデル内のフィールド名またはフィールド名のリスト。通常は [`DateField`](/ja/5.2/ref/models/fields/#django.db.models.DateField),  [`DateTimeField`](/ja/5.2/ref/models/fields/#django.db.models.DateTimeField), [`IntegerField`](/ja/5.2/ref/models/fields/#django.db.models.IntegerField) です。これはモデル [`Manager`](/ja/5.2/topics/db/managers/#django.db.models.Manager) の [`latest()`](/ja/5.2/ref/models/querysets/#django.db.models.query.QuerySet.latest) と [`earliest()`](/ja/5.2/ref/models/querysets/#django.db.models.query.QuerySet.earliest) メソッドで使用するデフォルトのフィールドを指定します。

実装例:

```
# Latest by ascending order_date.
get_latest_by = "order_date"

# Latest by priority descending, order_date ascending.
get_latest_by = ["-priority", "order_date"]
```

詳しくは [`latest()`](/ja/5.2/ref/models/querysets/#django.db.models.query.QuerySet.latest) のドキュメントを参照してください。

### `managed`

#### `Options.managed`

デフォルトは `True` です。つまり、 Django は [`migrate`](/ja/5.2/ref/django-admin/#django-admin-migrate) やマイグレーションの一部として適切なデータベーステーブルを作成し、 [`flush`](/ja/5.2/ref/django-admin/#django-admin-flush) 管理コマンドの一部として削除します。つまり、 Django はデータベーステーブルのライフサイクルを *管理* します。

`False` の場合、このモデルに対してデータベーステーブルの作成、変更、削除の操作を行いません。これは、モデルが既存のテーブルや他の方法で作成されたデータベースビューを表す場合に便利です。これは `managed=False` の場合の *唯一の* 違いです。モデルの処理に関する他のすべての側面は、通常とまったく同じです。これには以下が含まれます。

1. 主キーフィールドを宣言しない場合、モデルに自動的に主キーフィールドを追加します。 後でコードを読む人の混乱を避けるために、管理対象外のモデルを使うときには、モデル化しているデータベーステーブルのすべてのカラムを指定することをお勧めします。
2. `managed=False` のモデルが [`ManyToManyField`](/ja/5.2/ref/models/fields/#django.db.models.ManyToManyField) を含み、それが別の管理対象外モデルを指している場合、多対多の結合のための中間テーブルも作成されません。しかし、1つの管理モデルと1つの管理対象外モデル間の中間テーブルは *作成* されます。

   このデフォルトの動作を変更する必要がある場合は、(`managed` を必要に応じて設定した) 明示的なモデルとして中間テーブルを作成し、 [`ManyToManyField.through`](/ja/5.2/ref/models/fields/#django.db.models.ManyToManyField.through) 属性を使用してカスタムモデルとのリレーションを作成します。

`managed=False` のモデルを含むテストでは、テストのセットアップの一部として正しいテーブルが作成されるようにする必要があります。

モデルクラスの Python レベルでの動作を変更したい場合、 `managed=False` を使って既存のモデルのコピーを作成することもできます。しかし、その場合はもっと良い方法があります。 [プロキシモデル](/ja/5.2/topics/db/models/#proxy-models) です。

### `order_with_respect_to`

#### `Options.order_with_respect_to`

このオブジェクトを指定されたフィールドに対してソート可能にします。通常は `ForeignKey` です。これは、リレーション先オブジェクトを親オブジェクトに対してソート可能にするために使用できます。例えば、 `Answer` と `Question` オブジェクトにリレーションがあり、質問には複数の答えがあり、答えの順番が重要である場合、次のようにします：

```
from django.db import models

class Question(models.Model):
    text = models.TextField()
    # ...

class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    # ...

    class Meta:
        order_with_respect_to = "question"
```

`order_with_respect_to` が指定されている場合、リレーション先オブジェクトの順序を取得・設定するための2つのメソッドが追加されます。 `get_RELATED_order()` と `set_RELATED_order()` で、 `RELATED` は小文字のモデル名です。たとえば、ある `Question` オブジェクトが複数の `Answer` オブジェクトにリレーションしているとすると、返されるリストにはリレーション先の `Answer` オブジェクトの主キーが含まれます：

```pycon
>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]
```

Questionオブジェクトのリレーション先の `Answer` オブジェクトの順番は、 `Answer` の主キーのリストを渡すことで設定できます：

```pycon
>>> question.set_answer_order([3, 1, 2])
```

リレーション先オブジェクトには `get_next_in_order()` と `get_previous_in_order()` というメソッドもあり、これらのオブジェクトに適切な順番でアクセスできます。 `Answer` オブジェクトが `id` で並べられていると仮定すると、下記のようになります：

```pycon
>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>
```

> **order_with_respect_to は暗黙で ordering オプションを設定します。**
>
> 内部的には、 `order_with_respect_to` は `_order` という追加のフィールド/データベースカラムを追加し、モデルの [`ordering`](#django.db.models.Options.ordering) オプションをこのフィールドに設定します。そのため、`order_with_respect_to` と `ordering` を一緒に使用することはできません。また、`order_with_respect_to` によって追加された順序は、このモデルのオブジェクトのリストを取得する際に常に適用されます。

> **order_with_respect_to を変更するとき**
>
> `order_with_respect_to` は新しいデータベースカラムを追加するので、初期マイグレーションの [`migrate`](/ja/5.2/ref/django-admin/#django-admin-migrate) の後に `order_with_respect_to` を追加または変更する場合は、適切なマイグレーションを作成して適用してください。

### `ordering`

#### `Options.ordering`

オブジェクトのリストを取得するときに使用する、オブジェクトのデフォルトの順序：

```
ordering = ["-order_date"]
```

これは文字列やクエリ式のタプルまたはリストです。各文字列はフィールド名で、オプションのプレフィックス "-" は降順を表します。先頭の "-" がないフィールドは昇順に並びます。ランダムに並び替えたい場合は、文字列 "?" を使用します。

例えば、 `pub_date` フィールドで昇順にソートするには、次のようにします：

```
ordering = ["pub_date"]
```

`pub_date` の降順でソートするには、次のようにします：

```
ordering = ["-pub_date"]
```

`pub_date` の降順でソートし、 `author` の昇順でソートするには、次のようにします：

```
ordering = ["-pub_date", "author"]
```

[クエリ式](/ja/5.2/ref/models/expressions/) を使うこともできます。 `author` の昇順で並び替え、null値を最後にソートしたい場合、これを使います:

```
from django.db.models import F

ordering = [F("author").asc(nulls_last=True)]
```

> **Default ordering and GROUP BY**
>
> In [GROUP BY queries](/ja/5.2/topics/db/aggregation/#aggregation-ordering-interaction) (for example,
> those using [`values()`](/ja/5.2/ref/models/querysets/#django.db.models.query.QuerySet.values) and [`annotate()`](/ja/5.2/ref/models/querysets/#django.db.models.query.QuerySet.annotate)), the
> default ordering is not applied.

> **Warning**
>
> ソートには計算コストがかかります。ソート条件に追加した各フィールドに、データベースへのコストが発生します。追加する各外部キーには、暗黙的にすべてのデフォルトのソート条件が含まれます。
>
> クエリでソートが指定されていない場合、データベースから返される結果の順序は指定されません。特定の順序が保証されるのは、結果内の各オブジェクトを一意に識別するフィールドの組み合わせでソートした場合だけです。例えば、 `name` フィールドが一意でない場合、そのフィールドでソートしても、同じ名前のオブジェクトが常に同じ順序で表示されるとは限りません。

### `permissions`

#### `Options.permissions`

このオブジェクトを作成するときに permissions テーブルに入力する追加のパーミッション。追加、変更、削除、表示のパーミッションはそれぞれのモデルに対して自動的に作成されます。この例では `can_deliver_pizzas` という追加のパーミッションを指定しています：

```
permissions = [("can_deliver_pizzas", "Can deliver pizzas")]
```

これは `(permission_code, human_readable_permission_name)` の形式の2値タプルのリストまたはタプルです。

### `default_permissions`

#### `Options.default_permissions`

デフォルトは `('add', 'change', 'delete', 'view')` です。このリストはカスタマイズできます。例えば、アプリがデフォルトのパーミッションを必要としない場合は、空のリストを指定します。暗黙的にパーミッションが作成されるのを防ぐには、 [`migrate`](/ja/5.2/ref/django-admin/#django-admin-migrate) によってモデルが作成される前に、モデルに指定する必要があります。

### `proxy`

#### `Options.proxy`

`proxy = True` の場合、他のモデルをサブクラス化したモデルは [プロキシモデル](/ja/5.2/topics/db/models/#proxy-models) として扱われます。

### `required_db_features`

#### `Options.required_db_features`

現在の接続が持つべきデータベースの機能のリストで、このリストに基づいてモデルがマイグレーションフェーズで考慮されます。たとえば、このリストを `['gis_enabled']` に設定すると、そのモデルはGISが有効なデータベース上でのみ同期されます。これは、複数のデータベースバックエンドでテストする際に、一部のモデルをスキップするのにも便利です。作成されるかどうかわからないモデル間のリレーションは避けてください。ORMはこれを処理しません。

### `required_db_vendor`

#### `Options.required_db_vendor`

このモデルが特定する、サポートされているデータベース・ベンダーの名前。現在の組み込みベンダー名は `sqlite`, `postgresql`, `mysql`, `oracle` です。この属性が空ではなく、現在の接続ベンダーがこの属性と一致しない場合、モデルは同期されません。

### `select_on_save`

#### `Options.select_on_save`

Django が 1.6 より前の [`django.db.models.Model.save()`](/ja/5.2/ref/models/instances/#django.db.models.Model.save) アルゴリズムを使うかどうかを決定します。古いアルゴリズムでは、 `SELECT` を使って、更新する既存の行があるかどうかを判断します。新しいアルゴリズムは `UPDATE` を直接試みます。まれに、既存の行の `UPDATE` が Django から見えない場合があります。たとえば、PostgreSQL の `ON UPDATE` トリガーは `NULL` を返します。このような場合、新しいアルゴリズムは、データベースに行が存在しても、 `INSERT` を実行してしまいます。

通常、この属性を設定する必要はありません。デフォルトは `False` です。

新旧の保存アルゴリズムについては [`django.db.models.Model.save()`](/ja/5.2/ref/models/instances/#django.db.models.Model.save) を参照してください。

### `indexes`

#### `Options.indexes`

モデルに定義したい [インデックス](/ja/5.2/ref/models/indexes/) のリストです：

```
from django.db import models

class Customer(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=["last_name", "first_name"]),
            models.Index(fields=["first_name"], name="first_name_idx"),
        ]
```

### `unique_together`

#### `Options.unique_together`

> **代わりに UniqueConstraint を constraints オプションとともに使用してください。**
>
> [`UniqueConstraint`](/ja/5.2/ref/models/constraints/#django.db.models.UniqueConstraint) は `unique_together` よりも多くの機能を提供します。 `unique_together` は将来廃止される可能性があります。

組み合わせが一意でなければならないフィールドのリストを指定します。

```
unique_together = [["driver", "restaurant"]]
```

これは、一緒に考えたときに一意でなければならないリストのリストです。Django の管理画面で使われ、データベースレベルで強制されます (つまり、 `CREATE TABLE` ステートメントに適切な `UNIQUE` ステートメントが含まれます)。

利便性のために、`unique_together` は1つのフィールドセットしかないときは1つのリストにできます：

```
unique_together = ["driver", "restaurant"]
```

[`ManyToManyField`](/ja/5.2/ref/models/fields/#django.db.models.ManyToManyField) を `unique_together` に含めることはできません（それが何を意味するのかさえ不明です！）。[`ManyToManyField`](/ja/5.2/ref/models/fields/#django.db.models.ManyToManyField) に関連する一意性を検証する必要がある場合は、シグナルを使うか、明示的な [`through`](/ja/5.2/ref/models/fields/#django.db.models.ManyToManyField.through) モデルを使用してみてください。

制約に違反したときにモデル検証中に発生する `ValidationError` は `unique_together` エラーコードを持ちます。

### `constraints`

#### `Options.constraints`

モデルに定義したい [制約](/ja/5.2/ref/models/constraints/) のリスト：

```
from django.db import models

class Customer(models.Model):
    age = models.IntegerField()

    class Meta:
        constraints = [
            models.CheckConstraint(condition=models.Q(age__gte=18), name="age_gte_18"),
        ]
```

### `verbose_name`

#### `Options.verbose_name`

人間が読めるオブジェクトの名前（単数形）：

```
verbose_name = "pizza"
```

指定されない場合、 Django はクラス名を小文字にして使います。 `CamelCase` は `camel case` になります。

### `verbose_name_plural`

#### `Options.verbose_name_plural`

オブジェクトの名前の複数形：

```
verbose_name_plural = "stories"
```

指定されない場合、 Django は [`verbose_name`](#django.db.models.Options.verbose_name) \+ `"s"` を使用します。

## 読み取り専用の `Meta` 属性

### `label`

#### `Options.label`

オブジェクトの表現。`app_label.object_name` を返します。例： `'polls.Question'`

### `label_lower`

#### `Options.label_lower`

モデルの表現。`app_label.model_name'` を返します。例： `'polls.question'`