- 一貫性を最優先にしながら、プロジェクトの規模、アーキテクチャ、チームのニーズに基づいて、ファイル タイプと機能ベースのレイアウトを選択します。
- FastAPI の型ヒント、Pydantic モデル、依存性注入を活用して、ルーティングをシンプルに保ち、ロジックをモジュール化し、検証を強力かつ再利用可能にします。
- セキュリティ、テスト、非同期 I/O、構成を第一の考慮事項として構造化することで、本番環境や複数のチームに拡張しても完全な書き換えが必要なくなります。
- 明確な命名、移行、およびツール規則を採用して、成長し続ける FastAPI モノリスまたはマイクロサービス フリートを長期にわたって保守可能に保ちます。
FastAPIプロジェクトのためのクリーンでスケーラブルな構造を設計することは、最初は些細なことのように思えますが、6か月後には人生を完全に変えるような決定の1つです。コードベースが拡大し、チームも拡大し、複数のモジュールにまたがるバグの追跡をしなければならない状況では、適切なレイアウトはオンボーディングを加速し、リグレッションを減らし、リファクタリングの負担を大幅に軽減します。
FastAPIは非常に柔軟性が高いが、それはまた、規則を積極的に選択して強制する必要があることも意味する。このガイドでは、実際の運用中の FastAPI プロジェクトとよく知られているベストプラクティス リポジトリから最も役立つアイデアをまとめ、主要なプロジェクト レイアウトを比較し、依存性注入、検証、非同期 I/O、テスト、デプロイメントなどのコア FastAPI 概念とどのように相互作用するかを確認します。
FastAPI においてプロジェクト構造がなぜそれほど重要なのか
堅固な構造は、FastAPI アプリケーションが規模と複雑さが増しても理解しやすい状態を保つバックボーンです。それがなければ、人間工学的に優れたフレームワークであっても、すぐにアドホックモジュール、循環インポート、重複ロジックの山になってしまいます。
エンジニアリングの観点から見ると、構造はスケーラビリティに直接影響します。: モジュールが分離され、責任が明確になると、すべてを書き直すことなく、サービスを分割したり、キューを導入したり、システムのさまざまな部分を個別に拡張したりできるようになります。
保守性も大きなメリットすべてのルート、スキーマ、データベースモデルが予測可能な場所に配置されていれば、開発者はファイルの検索に費やす時間を減らし、実際のビジネス問題の解決に多くの時間を費やすことができます。また、全員が同じメンタルモデルを共有しているため、コードレビューも容易になります。
チームプロジェクトでは、一貫したレイアウトがコラボレーションを大幅に向上させます新入社員は新しい機能をどこに配置するかを推測でき、QA はテストする適切なエントリ ポイントを発見でき、DevOps はアプリの起動に重要な部分 (たとえば、ASGI アプリ オブジェクトが存在する場所やデータベースの接続方法) を理解できます。
FastAPIプロジェクトを構築するための基本原則
フォルダレイアウトを選択する前に、アーキテクチャの決定を導くいくつかの原則について合意しておくと役立ちます。これらのアイデアは、成功した FastAPI コードベースに繰り返し登場します。
関心事の分離 最初の柱は、ルーティング、永続性、ビジネスルール、そして統合コードを別々の場所に保管することです。エンドポイントはユースケースをオーケストレーションするものであり、SQLクエリ、JSON操作、外部サービス呼び出しをすべて1つの長い関数に埋め込むべきではありません。
モジュール性は第二の柱である巨大なモノリシックパッケージではなく、関連する動作をカプセル化した、より小さく焦点を絞ったモジュールやサブパッケージを目指しましょう。これにより、各部分を再利用し、個別にテストし、必要に応じてマイクロサービスに分割することがはるかに容易になります。
依存性注入は、密結合なしでこれらのモジュールを接続する接着剤です。FastAPI の依存関係システムを使用すると、ルートまたはサービスに必要なもの (データベース セッション、構成、認証されたユーザーなど) を宣言し、フレームワークにそれを提供させることができるため、テスト容易性と再利用に最適です。
テスト可能性自体は第一級の要件として扱われる必要がある構造上、アプリをメモリ内で起動したり、依存関係をオーバーライドしたり、テストクライアントでエンドポイントにアクセスしたりすることが困難な場合、テストを省略するか、独自のアーキテクチャと格闘することになります。適切な構造であれば、副作用はローカルに保持され、テストからパスをインポートできます。
2つの主要なFastAPIプロジェクトレイアウト: ファイルタイプ別 vs 機能別
FastAPIエコシステムでは、通常、2つの明確なレイアウトファミリーが見つかります。: ファイルの種類（ルーター、モデル、スキーマ、CRUD）別に整理されたプロジェクトと、ドメインまたは機能（認証、ユーザー、投稿、支払いなど）別に整理されたプロジェクト。それぞれが異なるコンテキストで活躍します。
ファイルタイプベースの構造（ルーター、スキーマ、モデル、CRUD）
ファイルタイプのアプローチは、多くの公式の例やチュートリアルでFastAPIを紹介する方法を反映しています。ルーティング層、ピダンティック スキーマ、データベース モデル、CRUD 操作、ユーティリティなどの技術的な役割に応じてコードをグループ化します。
最小限だが現実的なレイアウトは次のようになるだろう （わかりやすくするために短縮しています）：
レイアウト例： .├── app
│ ├── __init__.py
│ ├── main.py # FastAPI app initialization
│ ├── dependencies.py # shared dependencies
│ ├── routers
│ │ ├── __init__.py
│ │ ├── items.py # endpoints for items
│ │ └── users.py # endpoints for users
│ ├── crud
│ │ ├── item.py # item CRUD
│ │ └── user.py # user CRUD
│ ├── schemas
│ │ ├── item.py # pydantic models for items
│ │ └── user.py # pydantic models for users
│ ├── models
│ │ ├── item.py # ORM models for items
│ │ └── user.py # ORM models for users
│ ├── external_services
│ │ ├── email.py # email provider client
│ │ └── notification.py # push / notification client
│ └── utils
│ ├── authentication.py
│ └── validation.py
├── tests
│ ├── test_main.py
│ ├── test_items.py
│ └── test_users.py
├── requirements.txt
└── README.md
このスタイルでは、 app/ 単一の責任を持つ。 例えば、 routers/ HTTPエントリポイントを記述します。 schemas/ 入力/出力形状を宣言し、 models/ データベーステーブルを表します。
このレイアウトは、小規模から中規模のサービスやマイクロサービスに非常に適しています。通常、ドメインは十分に狭いため、技術的な役割ごとに分割しても摩擦は生じません。ほとんどのエンドポイントは同じ限られたモデルセットを使用しており、同時にコードに触れるチームは少数です。
ファイルタイプの構造の主な利点は、初心者にとって認知負荷が非常に低いことです。 FastAPIのドキュメントに忠実に従ったディレクトリツリーです。フレームワークを学習している人にとっては、専用の routers/ フォルダと schemas/ 多くの場合、フォルダーを使用すると、ドメイン駆動型パッケージングに直接ジャンプするよりも直感的に感じられます。
機能またはモジュール指向の構造 src/
プロジェクトが多くのドメインを持つモノリスに成長すると、ファイルタイプのレイアウトがきしみ始める巨大なディレクトリが表示されます。 routers/ 数十のファイル、複雑なモジュール間インポート、および無関係なパッケージに散在するビジネス ロジックが含まれます。
よりスケーラブルな代替案は、機能ベース、またはドメイン駆動型構造である。ここでは、ルート、スキーマ、モデル、サービス、構成、モジュール固有の例外など、特定のドメインのすべてのコードを 1 つのサブパッケージに配置します。
一般的なベストプラクティスリポジトリにヒントを得た代表的なレイアウトは次のようになります。:
代表的なファイルツリー: fastapi-project
├── alembic/
├── src
│ ├── auth
│ │ ├── router.py # auth endpoints
│ │ ├── schemas.py # pydantic models
│ │ ├── models.py # DB models
│ │ ├── dependencies.py # auth-specific dependencies
│ │ ├── config.py # local configs
│ │ ├── constants.py # auth error codes / constants
│ │ ├── exceptions.py # auth-specific exceptions
│ │ ├── service.py # business logic
│ │ └── utils.py # helpers
│ ├── aws
│ │ ├── client.py
│ │ ├── schemas.py
│ │ ├── config.py
│ │ ├── constants.py
│ │ ├── exceptions.py
│ │ └── utils.py
│ ├── posts
│ │ ├── router.py
│ │ ├── schemas.py
│ │ ├── models.py
│ │ ├── dependencies.py
│ │ ├── constants.py
│ │ ├── exceptions.py
│ │ ├── service.py
│ │ └── utils.py
│ ├── config.py # global configs
│ ├── models.py # shared DB models
│ ├── exceptions.py # shared exceptions
│ ├── pagination.py # reusable pagination logic
│ ├── database.py # DB connection & session management
│ └── main.py # FastAPI app factory / entry point
├── tests
│ ├── auth
│ ├── aws
│ └── posts
├── templates
│ └── index.html
├── requirements
│ ├── base.txt
│ ├── dev.txt
│ └── prod.txt
├── .env
├── logging.ini
└── alembic.ini
この世界では、 src/ 内部アプリケーションツリーの最上位ですあらゆるドメイン、例えば auth or postsは、ほぼミニサービスになります。独自のルーター、スキーマ、モデル、定数、エラー タイプ、ビジネス サービス レイヤーを備えています。
主な利点は変化の局所性である: 新しい機能を追加すると posts関係のないパッケージに触れる必要はほとんどありません。テストは機能と一緒に存在することもできます（例えば tests/posts/）、より高いカバレッジを促進します。
この構造は、多くのドメインとチームを持つモノリシックアプリケーションに特に適しています。並列作業をサポートし、マージの競合を減らしたい場合に最適です。また、境界付きコンテキストや集約といったドメイン駆動設計の概念とも相性が良いです。
FastAPIプロジェクトに適したレイアウトを選択する
ファイルタイプと機能ベースの構造のどちらを選ぶかは、正しいか間違っているかではなく、アーキテクチャと成長の期待を一致させることです。エンドポイントがほんの数個しかない小さな内部ツールでは、複雑なドメイン レイアウトから得られるメリットはあまりありません。
マイクロサービスやスコープが狭いAPIの場合、ファイルタイプのレイアウトは通常よりシンプルになります。各サービスは、多くの場合、単一の責任（課金 API、通知送信者、レポート マイクロサービス）に焦点を当てており、開発者は新しいルートやスキーマをどこに配置するかをすでに直感的に把握しています。
大きなモノリスの場合、ドメインごとに分割することが長期的にはほぼ常に有利になります。プロファイル、サブスクリプション、コンテンツ、決済、分析などのモジュールがある場合、すべてのルーターを単一のディレクトリ下に置くと混乱が生じます。機能ごとにグループ化することで、システムの各スライスを自己完結的に維持できます。
チーム構成も考慮する1つの小規模なチームがコードベース全体を所有している場合、シンプルなレイアウトの方が一貫性を維持しやすいかもしれません。複数のチームがモノリスを共有し、それぞれがドメイン領域を所有している場合は、機能ベースの構造を採用することで、互いの足を引っ張ることなく、より迅速に作業を進めることができます。
何を選ぶにしても、木の正確な形よりも一貫性が重要ですプロジェクトの途中でレイアウトを変更するのは面倒なので、早い段階で検討し、短い社内スタイル ガイドを作成しておくと、後で役に立ちます。
FastAPI自体を理解する：何を構造化しているのか
賢明な構造を設計するには、FastAPIが実際に何を行うのかを明確に理解する必要があります。本質的に、FastAPI は、型ヒントを使用して Python 3.7 以降で HTTP API を構築することに重点を置いた ASGI Web フレームワークです。
FastAPIはデータの検証とシリアル化にPydanticを多用している単純な「必須フィールドとオプションフィールド」以上の機能を提供し、モデル上で豊富な制約や変換を直接表現できます。
OpenAPIスキーマはエンドポイントとモデルから直接派生するため、FastAPIはインタラクティブなドキュメントも生成します。すぐに使えるSwagger UIは /docs そしてReDocで /redocこれらは、フロントエンド開発者やサードパーティのインテグレーターと共同作業する際に非常に役立ちます。
内部的には、FastAPIはUvicornなどのASGIサーバー上で実行されます。これにより、アプリは多数の同時接続を効率的に処理できるようになり、余分な手間をかけずに長時間有効な WebSocket 接続などの機能を実現できます。
FastAPIはリクエストとレスポンスについても明確に述べています各エンドポイントは、通常のPython関数（同期または非同期）であり、 @app.get, @app.post およびフレンドは、パス/クエリ/本文データを受け取り、通常は辞書または Pydantic モデルなどの応答を返します。
非同期 vs 同期: パフォーマンスと構造の交差
FastAPIは主に非同期フレームワークとして設計されていますが、非同期エンドポイントと同期エンドポイントの両方をサポートしています。内部でどのように動作するかを理解することで、サービスの設計方法、クライアントの選択方法、I/O を処理するモジュールの構造が決まります。
宣言すると async def ルートの場合、FastAPIはイベントループ内で直接実行します。フレームワークは、内部の長時間実行される操作は非同期データベースドライバやHTTPクライアントなどの非ブロッキング待機可能オブジェクトであると想定しています。 asyncio.
誤ってブロック電話をかけてしまった場合（例： time.sleep()非同期ルート内に、CPU負荷の高いループやネットワークI/Oを同期的に行う低速ライブラリを配置すると、イベントループが実質的にフリーズする。その操作が完了するまで他のリクエストは処理されません。これでは非同期の目的が達成されません。
同期ルートは異なる動作をします: FastAPIはそれらをスレッドプールで実行しますこれらのルートで作業をブロックすると、イベントループ全体ではなくワーカースレッドのみが保持されるため、サーバーは引き続き新しいリクエストを受け入れることができます。これにより、同期ライブラリに依存せざるを得ない場合でも、FastAPIは柔軟性を維持できます。
依存関係にも同じ原則が適用される同期依存関係と非同期依存関係の両方がサポートされていますが、同期依存関係もスレッドプールで実行されます。I/Oを伴わない小さなヘルパーの場合は、不要な場合はスレッドのオーバーヘッドや制限を回避するために、非同期としてマークする方がよい場合が多いです。
CPU依存のワークロードは別の話プロセス内で同期または非同期で実行する場合でも、GIL（グローバルインタープリタロック）により、一度に1つのスレッドのみがPythonバイトコードを実行します。負荷の高いデータ処理、画像トランスコーディング、機械学習推論などのタスクの場合は、別のプロセスまたは外部キューのワーカーに作業をオフロードすることを検討してください。
Pydanticによるデータの検証と整形
PydanticはFastAPIの検証とシリアル化機能を支えるエンジンです。単純な「必須フィールドとオプションフィールド」以上の機能を提供し、モデル上で豊富な制約や変換を直接表現できます。
典型的な使用例には、文字列の長さ、数値の範囲、電子メールの形式、複雑なネスト構造の検証が含まれます。モデルは、列挙型、正規表現、カスタム検証、その他多くのツールを使用して、入力がビジネス ロジックに到達する前に入力をサニタイズすることもできます。
強力なパターンは、プロジェクト用のカスタムベースモデルを定義することです単一の基本クラスからすべてのスキーマを継承することで、日時シリアル化形式、JSON 対応の値のみを返すユーティリティ メソッド、共通の構成フラグなどの横断的な動作を標準化できます。
Pydanticは純粋なデータ検証には最適ですが、データベースや外部サービスについては何も知りません。ルールがクエリに依存している場合（ユーザー ID が存在するか、電子メールが一意であるかを確認するなど）、一般的なベスト プラクティスとしては、それらの検証を Pydantic モデル検証ではなく依存関係に移動します。
こうすることで、スキーマを宣言的に保ち、複数のエンドポイント間で検証を再利用することができます。依存関係はエンティティを取得し、アクセス ルールを適用して結果をルートに挿入できますが、FastAPI はリクエストごとに結果をキャッシュして、同じ依存関係が複数回使用される場合に重複作業を回避します。
クリーンアーキテクチャの構成要素としての依存関係
FastAPIの依存性注入システムは、単なるパラメータの構文糖ではなく、コアアーキテクチャツールです。依存関係を適切に使用することで、ロジックを共有し、不変条件を適用し、ルートを非常に小さく表現力豊かに保つことができます。
一般的な例としては、データベースセッションプロバイダ、構成ローダー、認証ヘルパー、ページ区切りパーサーなどがあります。セッションを手動で開いたり閉じたり、ページ区切りパラメータをあらゆる場所で繰り返したりするのではなく、それらを依存関係として一度宣言して再利用します。
微妙だが重要な設計のヒントは、依存関係を小さく構成可能な単位に分割することです。1つの巨大な get_current_user_with_all_checks 関数によっては、JWT の解析、ユーザーの読み込み、アカウントがアクティブであることの検証、ユーザーが特定のリソースを所有していることのチェックなど、個別の依存関係が存在する可能性があります。
FastAPIは依存関係の結果を単一のリクエスト内でキャッシュするため、それらを構成するのは安価である。3 つの異なる依存関係が下位レベルのヘルパー（たとえば、JWT クレームの解析）を再利用する場合、そのヘルパーは複数回参照されていてもリクエストごとに 1 回だけ実行されます。
ルートを設計する際に、パス名は依存関係の再利用を助けるか妨げるかのどちらかとなる。例えば、複数のエンドポイントが profile_id パスパラメータで同じ名前を一貫して使用することで、単一の依存関係を簡単にプラグインできるようになります。 profile_id、多くのバリエーションを発明する代わりに、 creator_id 同じ意味を持ちます。
構造内のセキュリティ、認証、承認
セキュリティは、明確な構造がすぐに成果をもたらす領域の一つです認証ロジックをランダムルートに直接混在させると、アクセス ルールの監査が難しくなり、誤ってデータが公開されやすくなります。
フィーチャベースのレイアウトの一般的なパターンは、 auth 独自のルーター、スキーマ、サービス層、例外を備えたパッケージこのモジュールは、ユーザー登録、ログインフロー、トークンの発行と検証を処理し、次のような依存関係を定義する可能性があります。 get_current_user 他のモジュールがインポートします。
この認証パッケージでは複数の認証メカニズムをサポートできますパスワードとベアラートークンを使ったOAuth2、サービス間呼び出し用のAPIキー、ステートレスAPI用のJWTベースのトークンなど。FastAPIの fastapi.security ユーティリティは、OpenAPI でもこれらのフローを記述するのに役立ちます。
認証（ユーザーが誰であるか）と認可（ユーザーが何を実行できるか）を区別することが重要です。権限チェックがどこにあるのかを明確にする構造にする必要があります。例えば、散在するアドホックな場所ではなく、専用のサービスまたはポリシー層に配置するなどです。 if すべてのルートにわたるステートメント。
パスワードを扱うときは、確立された暗号化の慣例に従ってください。信頼できるライブラリを使用して、bcrypt や argon2 などの低速のソルト付きアルゴリズムで秘密をハッシュし、手動の暗号化を避け、トークンの保存、CSRF 保護、トランスポート セキュリティ (HTTPS) を設計の第一級の要素として扱います。
FastAPI アプリケーションを効果的にテストする
構造とテストは互いに強化し合う：きれいなレイアウトは自然にテストしやすいコードにつながるFastAPI を使用すると、サービスの純粋な単体テストから HTTP レイヤーにアクセスする完全な統合テストまで、複数のレベルでテストできます。
ユニットテストは、副作用のない小さな部分に焦点を当てるべきである純粋関数、Pydanticバリデータ、メモリ内データを操作するビジネスサービスなど。これらは非常に高速であり、回帰に対する第一の防御線となります。
実際のHTTPエンドポイントを実行するには、Starletteをベースにした組み込みのテストクライアント、またはhttpxなどの最新の非同期クライアントを使用できます。アプリをインポートし、必要に応じて依存関係をオーバーライドし（たとえば、テスト データベース セッションを挿入する）、外部サーバーを実行せずにリクエストを送信するという考え方です。
非同期データベースドライバやその他の非同期統合を使用している場合は、最初から非同期テストクライアントを設定する価値があります。後から同期テストと非同期テストのスタイルを混在させると、混乱を招くイベント ループの問題が発生することが多く、単純に 1 つのアプローチを標準化するよりもデバッグが難しくなります。
テストでのデータベースの使用は構造とも相互作用します中央集権的な database.py エンジンとセッション ファクトリを定義するモジュールを使用すると、テスト データベースの起動、トランザクションでのテストのラップ、実行間でテーブルを切り捨てるフィクスチャの使用が容易になります。
ローカル開発から本番環境への展開まで
FastAPIアプリケーションはローカルで実行するのは簡単ですが、本番環境ではもう少し計画が必要です。プロジェクト構造により、アプリがどのように作成されるか、構成がどこから来るか、ログ記録とヘルスチェックがどのように配線されるかが明確になります。
開発チームの多くは、自動リロード機能を備えたUvicornを使用しています。通常は次のようなコマンドで uvicorn app.main:app --reload あるいは、新しい設定では、 fastapi devこれにより、高速なフィードバック ループが提供され、反復処理に最適です。
生産段階では通常、より堅牢なセットアップが必要になります: UvicornまたはHypercornワーカーは、プロセススーパーバイザーまたはGunicornなどのWSGI/ASGIラッパーによって管理され、多くの場合リバースプロキシ（NGINXまたはマネージドロードバランサー）の背後に配置されます。目標は、ワーカー数、タイムアウト、そしてグレースフルリスタートを制御することです。 最新のDevOpsプラクティス.
設定はハードコードされた値ではなく環境変数によって制御されるべきであるPydantic の設定管理や同様のツールを使用すると、型指定された設定クラスを宣言して起動時にロードし、環境固有のノブをすべて 1 か所に一元化することができます。
アプリを本番環境対応にする前に、いくつかの重要な点を確認してください。: 構造化ログ、基本メトリクス、生存および準備プローブの正常性エンドポイント、適切なボディサイズ制限、および API が一般使用を目的としていない場合に非公開環境でのみドキュメントを公開するという明確なポリシー。
命名、データベース設計、移行
モデルやスキーマファイル内での命名方法もプロジェクト構造の一部です一貫性のない命名は、自分が作成していないコードベースで作業する開発者を混乱させる最も早い方法の 1 つです。
シンプルで効果的な慣例の一つは、 lower_case_snake テーブルと列の名前単数形のテーブル名を推奨します（例： post, post_like, user_playlist）のような共通のプレフィックスを持つ関連テーブルをグループ化します。 payment_ or post_.
時間フィールドの場合、次のような接尾辞が付きます _at 日付時刻と _date 単純な日付の場合は、明確にするここで厳密にすることで、スキーマや生のクエリを読み取るときに「これはタイムスタンプか日付か」と推測する必要がなくなります。
移住には特別な配慮が必要; 決定論的、可逆的、記述的であるべきである。以下を検討すること。 データベース移行の実践多くのチームは移行ファイル名に次のようなパターンを採用しています。 YYYY-MM-DD_slug.pyこれにより、完全な差分を読まなくても、履歴を追跡して何が変更されたかを理解しやすくなります。
複雑なレポートやネストされたレスポンスの場合は、Pythonで過剰に処理するのではなく、データベースを活用しましょう。最新の SQL エンジンは、CPython よりもはるかに高速に結合、集計、JSON 構築を実行でき、事前に形成された構造を FastAPI に返すことで、応答モデルが簡素化されることがよくあります。
ツール、フォーマット、チームの慣例
適切に構造化されたプロジェクトでは、スタイルルールを強制するツールを導入することで、整理整頓しやすくなります。コードフォーマッタ、リンター、およびコミット前フックを使用すると、コードレビューで空白について議論するのではなく、ビジネスロジックに集中できます。
最近、Ruffのようなツールは複数の役割を1つにまとめているため人気が高まっています。フォーマット、インポートのソート、リンティングのために個別のユーティリティを操作する代わりに、コードベース全体に何百ものルールを適用する単一の高速ツールを実行できます。
これらのツールをシンプルなスクリプトやコミット前のフックで実行することで、障壁を低く抑えることができます。すべてのチームが複雑なフック設定を必要とするわけではありませんが、コード レイアウトを標準化するコマンドを少なくとも 1 つ用意すれば、簡単に成功します。
最後に、社内の慣例を短い「エンジニアリングハンドブック」に文書化することを検討してください。 その参照 アジャイルソフトウェア開発手法モジュールの命名方法、新しいドメインパッケージを作成するタイミング、テストの構造、必須のセキュリティパターンなどを記述します。これにより、知識が上級開発者の頭の中に留まってしまうことを防ぎます。
FastAPIプロジェクトの構造を設計することは、将来の作業を予測可能で退屈なものにすることです。すべての新しいエンドポイント、モデル、またはサービスに明確なホームがある場合、開発者は予期せず迅速に移行でき、セキュリティの監査が容易になり、アプリケーションが自重で崩壊することなく実際の成長に耐えられる可能性が大幅に高まります。
