.NET Core vs FastAPI：バックエンド開発の覇権はどっち？性能と拡張性を比較

バックエンド開発において「どの技術を選ぶか」は、単なる流行ではなく、システム全体の設計思想や将来的な拡張性に直結する重要な意思決定です。
特に近年は、クラウドネイティブ化やマイクロサービス化の流れが加速し、フレームワーク選定の重要性は以前にも増して高まっています。

本記事では、代表的なバックエンド技術である.NET CoreとFastAPIを取り上げ、それぞれの特性を性能・開発体験・拡張性の観点から整理しながら比較していきます。

両者は設計思想も得意分野も異なり、単純な優劣では語れませんが、実務では以下のような観点が意思決定の鍵になります。

• 実行性能とスループットの違い
• 非同期処理や並列性への適応力
• エコシステムとライブラリの成熟度
• チーム開発における生産性

特に.NET Coreは企業向け大規模システムでの実績が豊富であり、一方FastAPIはPythonベースの軽量性と開発速度の速さが評価されています。
どちらが「覇権」を握るのかという問いは単純ではなく、用途や組織の特性によって最適解は変わります。

この記事では、それぞれの技術を単なるスペック比較ではなく、実際の設計判断に役立つ形で整理し、最終的にどのような場面でどちらを選ぶべきかを論理的に解きほぐしていきます。

.NET CoreとFastAPIの基本比較：バックエンド開発の全体像

バックエンド開発における技術選定は、単なるフレームワークの好みではなく、システム設計の前提条件そのものを規定します。
.NET CoreとFastAPIはどちらも現代的なWebバックエンド構築に適した選択肢ですが、その設計思想とアーキテクチャには明確な違いが存在します。

フレームワークの設計思想とアーキテクチャの違い

.NET CoreはMicrosoftが提供するクロスプラットフォーム対応の実行環境であり、企業システムを強く意識した設計が特徴です。
依存性注入（DI）やミドルウェアパイプラインなど、アプリケーションの構造を厳密に制御できる仕組みが標準で組み込まれています。
これにより、大規模開発においてもコードの一貫性と保守性を維持しやすい設計になっています。

一方でFastAPIはPythonエコシステムにおける軽量かつ高速なAPIフレームワークとして設計されており、開発者体験を重視した構造になっています。
特に型ヒントを活用したバリデーションや自動ドキュメント生成機能（OpenAPI対応）が標準で備わっている点が特徴です。

両者のアーキテクチャの違いを整理すると以下のようになります。

観点	.NET Core	FastAPI
実行環境	CLR（共通言語ランタイム）	CPython
アーキテクチャ	ミドルウェアパイプライン中心	軽量ルーティング中心
型システム	静的型付け（C#）	動的＋型ヒント
主用途	エンタープライズ・大規模システム	API・マイクロサービス・高速開発

この違いは単なる技術仕様ではなく、開発プロセスそのものに影響を与えます。
.NET Coreは設計段階での構造化を重視するため、初期コストは高くなる傾向がありますが、その分長期運用における安定性が高いです。

対してFastAPIは「まず動くものを素早く作る」という思想に適しており、プロトタイピングやスタートアップの初期開発で強みを発揮します。

また、アーキテクチャの違いは拡張性にも直結します。
.NET Coreはモジュール化が強く、ドメイン駆動設計（DDD）との親和性が高い構造です。
一方FastAPIはシンプルな構成のため、必要に応じて外部ライブラリを組み合わせる柔軟性が求められます。

このように両者は優劣ではなく「設計思想の方向性」が異なるため、プロジェクトの規模やチーム構成に応じて選択基準が変わる点が重要です。

.NET Coreの性能特性とエンタープライズ向け強み

.NET Coreはエンタープライズ領域において長年採用されてきた背景を持ち、その性能特性は単なる「高速なフレームワーク」という枠に収まりません。
特に大規模トラフィックや複雑な業務ロジックを扱うシステムにおいて、その設計は安定性とスループットの両立を強く意識しています。

CLRとKestrelによる高速処理の仕組み

.NET Coreの性能を語る上で中心となるのが、CLR（Common Language Runtime）とKestrelというHTTPサーバーの組み合わせです。
CLRはJITコンパイル（Just-In-Time）によってC#コードを実行時に最適化し、ネイティブコードに近い実行効率を実現します。
この仕組みにより、静的型付けの恩恵を最大限に活かしながら高い実行性能を確保しています。

一方でKestrelは軽量かつ非同期処理に特化したWebサーバーとして設計されており、従来のIISに依存しないクロスプラットフォーム環境を提供します。
特に大量の同時接続を処理する際に、その非同期I/Oモデルが性能上のボトルネックを回避する役割を果たします。

この2つのコンポーネントの関係性は以下のように整理できます。

コンポーネント	役割	性能上の利点
CLR	実行環境・JIT最適化	ネイティブレベルの実行速度
Kestrel	Webサーバー	非同期I/Oによる高スループット

さらに.NET Coreはスレッドプールの最適化やガベージコレクション（GC）のチューニングが高度に行われており、長時間稼働するサービスでも安定したレイテンシを維持しやすい設計になっています。

特にエンタープライズ用途では以下のような要件が頻出します。

• 高トラフィック時でも応答時間が一定であること
• 長時間稼働におけるメモリ安定性
• 複雑な業務ロジックの安全な実装
• チーム開発における型安全性の確保

.NET Coreはこれらの要件に対して、言語レベル（C#の静的型付け）とランタイムレベル（CLR最適化）の両面からアプローチできる点が強みです。

また、Kestrelは単体でも高性能ですが、リバースプロキシ（Nginxなど）と組み合わせることで、さらにスケーラブルな構成を実現できます。
このように「単体性能」だけでなく「システム全体設計」に最適化されている点が、FastAPIとの差別化要因として重要になります。

FastAPIの軽量性とPythonによる開発速度の優位性

FastAPIは、現代的なバックエンド開発において「開発速度」と「シンプルな構造」を重視する設計思想を持つフレームワークです。
特にPythonエコシステムの柔軟性と組み合わさることで、プロトタイピングから本番運用までのスピードを大きく引き上げることができます。
.NET Coreが堅牢性とスケーラビリティに強みを持つのに対し、FastAPIは開発初期フェーズにおける圧倒的な俊敏性が特徴です。

この軽量性は、フレームワーク自体が最小限のコア機能に絞られている点に起因します。
余計な抽象化を排除し、必要な機能を外部ライブラリで補う設計のため、開発者は自由度の高い構成を取ることができます。

非同期処理と型ヒントによる開発効率の向上

FastAPIの技術的な優位性の中核にあるのが、非同期処理（async/await）とPythonの型ヒントの統合です。
この2つの仕組みにより、開発速度と実行効率の両立が実現されています。

非同期処理はI/Oバウンドな処理、例えばデータベースアクセスや外部API呼び出しにおいて特に効果を発揮します。
従来の同期処理ではリクエストごとにスレッドをブロックしていましたが、FastAPIではイベントループを活用することで、少ないリソースで多数のリクエストを処理できます。

さらにPythonの型ヒントを活用することで、以下のような開発上の利点が得られます。

• 入力データのバリデーションを自動化できる
• IDEによる補完精度が向上する
• APIドキュメント（OpenAPI）が自動生成される

これらの特徴は、開発サイクルの短縮に直接寄与します。
特にAPI設計においては、コードを書くと同時に仕様書が生成されるため、ドキュメントと実装の乖離が発生しにくいという利点があります。

例えばFastAPIでは以下のようなシンプルな定義でAPIを構築できます。

from fastapi import FastAPI
app = FastAPI()
@app.get("/items/{item_id}")
async def read_item(item_id: int):
    return {"item_id": item_id}

このコードはわずか数行ですが、型情報に基づき入力検証とドキュメント生成が自動で行われます。

また、FastAPIはStarletteを基盤としているため、高速なASGIサーバーとの統合が容易であり、uvicornなどと組み合わせることで軽量かつ高性能なAPIサーバーを構築できます。

このようにFastAPIは「最小構成で最大効率」を追求した設計であり、特にスタートアップや短期間でのMVP開発において強い競争力を持っています。

実行性能比較：スループットとレイテンシの違い

バックエンドシステムの性能を評価する際には、単純な処理速度だけではなく、スループットとレイテンシという2つの指標を分けて考える必要があります。
.NET CoreとFastAPIはどちらも高性能なWebフレームワークですが、その最適化の方向性は異なり、負荷条件によって評価結果が変わる点が重要です。

スループットは単位時間あたりに処理できるリクエスト数を意味し、レイテンシは1リクエストあたりの応答時間を示します。
この2つはトレードオフ関係にあることが多く、設計思想によって最適化の優先順位が変わります。

.NET Coreは高スループット環境に強く、大量の同時リクエストを安定して処理する設計になっています。
一方FastAPIは低レイテンシでの応答速度に優れ、軽量なAPIを高速に返す用途に適しています。

負荷テストにおける挙動とボトルネック分析

実際の負荷テストでは、両者の違いはより明確に現れます。
例えば高並列アクセスをシミュレーションした場合、.NET CoreはCLRの最適化とKestrelの非同期処理により、スレッド効率を維持しながらスケールします。
このため、一定以上の負荷でも応答のばらつきが少ないという特徴があります。

一方FastAPIは、ASGIベースのイベントループにより軽量なリクエスト処理を実現していますが、CPUバウンドな処理が増えるとPythonのGIL（Global Interpreter Lock）の影響を受ける可能性があります。
そのため、負荷が集中するケースではスループットが頭打ちになる傾向があります。

負荷テストにおける一般的なボトルネックは以下のように整理できます。

• .NET Core：GC（ガベージコレクション）の発生タイミング
• FastAPI：GILによる並列処理制約
• 両者共通：外部DBアクセスのI/O待ち
• ネットワーク帯域幅の上限

これらを踏まえると、ボトルネックの所在はフレームワーク単体ではなく、システム全体設計に依存することが分かります。
特にデータベースとのやり取りが多いAPIでは、ORMの設計やキャッシュ戦略が性能に大きく影響します。

また、負荷テストでは以下のような観点で比較することが重要です。

観点	.NET Core	FastAPI
高負荷時の安定性	高い	中程度
低遅延応答	良好	非常に良好
スケーリング耐性	高い	構成依存
CPU効率	最適化済み	ワークロード依存

このように、単純なベンチマークスコアだけではなく、ワークロード特性に応じた評価が必要になります。
特に本番環境ではピーク時の挙動が重要であり、平均値よりも分散や最大遅延の方がシステム品質に直結します。

したがって、.NET CoreとFastAPIの性能比較は「どちらが速いか」という単純な問いではなく、「どの条件で安定して性能を発揮するか」という観点で評価することが適切です。

開発体験とツールチェーン比較：VSCode・Visual Studio・Docker活用

バックエンド開発において、フレームワークの性能だけでなく開発体験（Developer Experience）はプロジェクト全体の生産性に直結します。
.NET CoreとFastAPIは、それぞれ異なるエコシステムを持っており、使用するIDEやツールチェーンによって開発効率が大きく変わります。

.NET CoreはMicrosoft製のエコシステムに深く統合されており、Visual Studioとの親和性が非常に高いです。
一方FastAPIは軽量な設計であるため、VSCodeやCLIベースの開発環境との相性が良く、柔軟なワークフローを構築できます。

この違いは単なるツール選択ではなく、開発プロセスそのものの設計思想に影響を与えます。

GitHub Copilotやコンテナ環境による生産性向上

近年の開発環境では、AI支援ツールとコンテナ技術の組み合わせが標準化しつつあります。
特にGitHub Copilotのようなコード補完AIは、.NET Core・FastAPIの両方においてコーディング速度を大幅に向上させています。

GitHub Copilotは文脈理解に基づいてコードを補完するため、APIエンドポイントの定義やデータモデルの生成など、定型的な作業を大幅に削減できます。
特にFastAPIのようなシンプルな構造では、その効果が顕著に現れます。

また、Dockerを用いたコンテナ開発は、両フレームワークにおいて環境差異を吸収する重要な役割を果たします。
ローカル環境と本番環境の差異を最小化することで、以下のような利点が得られます。

• 環境構築の再現性が高い
• チーム開発での依存関係の統一
• CI/CDパイプラインとの統合が容易
• デプロイ時のトラブル削減

例えばFastAPIでは以下のようなシンプルなDocker構成が一般的です。

FROM python:3.11
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

一方.NET Coreでもマルチステージビルドを活用することで、軽量なコンテナイメージを作成できます。

これらのツールチェーンを比較すると、Visual Studioは統合開発環境として強力なデバッグ機能やGUI操作を提供し、VSCodeは軽量かつ拡張性の高いエディタとして柔軟な構成が可能です。

観点	Visual Studio + .NET Core	VSCode + FastAPI
初期セットアップ	重いが統合度高い	軽量で柔軟
デバッグ機能	非常に強力	拡張依存
拡張性	中程度	非常に高い
コンテナ適合性	高い	非常に高い

結果として、エンタープライズ環境ではVisual Studio + .NET Coreの安定性が重視される一方、スタートアップや個人開発ではVSCode + FastAPI + Dockerの組み合わせが俊敏性の面で優位になります。

このように、ツールチェーンの選択は単なる好みではなく、チーム規模や開発速度要件に直結する戦略的判断となります。

スケーラビリティとクラウド対応：AWS・Azure・Kubernetes連携

現代のバックエンドアーキテクチャにおいて、スケーラビリティは単なる性能指標ではなく、ビジネス成長に直結する設計要件です。
.NET CoreとFastAPIはいずれもクラウドネイティブな開発に対応していますが、その設計思想と最適な運用環境には違いがあります。
特にAWSやAzureといったクラウド基盤、さらにKubernetesによるコンテナオーケストレーションとの連携は、システム全体の拡張性を左右する重要な要素です。

.NET CoreはMicrosoft Azureとの統合が非常に強く、エンタープライズ向けのクラウド移行において安定した選択肢となります。
一方FastAPIはクラウド非依存であり、AWS・GCP・オンプレミスなど多様な環境に柔軟に対応できる点が特徴です。

この違いは「特定クラウドへの最適化」か「環境非依存の柔軟性」かという設計思想の差に起因します。

マイクロサービス化とコンテナオーケストレーション

スケーラブルなシステム設計において、マイクロサービスアーキテクチャとコンテナオーケストレーションは不可分の関係にあります。
特にKubernetesは、.NET Core・FastAPIのいずれにおいてもデファクトスタンダードとなりつつあり、サービス単位でのスケーリングを実現する基盤技術です。

マイクロサービス化の本質は、機能を独立した小さなサービス単位に分割し、それぞれを独立してデプロイ・スケール可能にする点にあります。
この設計により、以下のような利点が得られます。

• サービスごとの独立したスケーリングが可能
• 障害の局所化によるシステム全体への影響軽減
• 技術スタックの部分的な自由選択
• CI/CDパイプラインの分割による開発効率向上

.NET Coreはこの構造に対して強い親和性を持ち、ASP.NET CoreベースのAPIをサービス単位で分割しやすい設計になっています。
またAzure Kubernetes Service（AKS）との統合により、デプロイからスケーリングまでをシームレスに管理できます。

一方FastAPIは軽量なため、コンテナ単位での分割が非常に容易であり、1サービス＝1コンテナというシンプルな構成を取りやすい点が特徴です。
特にuvicornと組み合わせたASGIサーバーは、Kubernetes上で水平スケーリングを行う際に高い適応性を持ちます。

クラウド環境における典型的な構成差異を整理すると以下のようになります。

観点	.NET Core + Azure	FastAPI + AWS
クラウド統合	非常に強い	中立的
スケーリング方式	AKS + 自動スケール	EKS + 手動/自動構成
運用管理	一元化しやすい	柔軟だが設計依存
初期構築コスト	やや高い	低い

またKubernetesを中心としたオーケストレーションでは、どちらのフレームワークも「ステートレス設計」が前提となります。
セッション管理やキャッシュ戦略を外部サービスに委譲することで、水平スケーリングが容易になります。

このように、スケーラビリティの観点ではフレームワーク単体ではなく、クラウド基盤との統合設計が重要です。
.NET Coreは統合性と安定性に優れ、FastAPIは柔軟性と軽量性に優れるため、組織のクラウド戦略によって最適解が変化します。

エコシステムとライブラリ：ORM・API設計の柔軟性

バックエンド開発において、フレームワーク単体の性能だけでなく、周辺エコシステムの成熟度は設計の自由度と保守性に大きく影響します。
.NET CoreとFastAPIはどちらも強力な基盤を持っていますが、利用可能なライブラリ群やORMの選択肢、API設計の柔軟性には明確な違いがあります。

.NET CoreはMicrosoftのエコシステムに支えられており、Entity Framework Coreを中心とした統一されたORM戦略が特徴です。
一方FastAPIはPythonエコシステムの多様性を背景に、SQLAlchemyやTortoise ORMなど複数の選択肢を柔軟に組み合わせる設計が可能です。

この違いは「統一された標準化」か「自由度の高い選択性」かという設計思想の差に起因します。

データベース連携とORMの選択肢

データベース連携はバックエンド設計の中核であり、ORMの選択はシステムの保守性と開発効率に直結します。
.NET CoreではEntity Framework Coreが事実上の標準として機能し、LINQを用いた直感的なクエリ記述とマイグレーション機能を統合的に提供します。

一方FastAPIはORMをフレームワークに内包していないため、プロジェクトごとに最適なツールを選択する必要があります。
代表的な選択肢としてはSQLAlchemyやTortoise ORMがあり、それぞれ同期・非同期の対応状況や設計思想が異なります。

ORM選択の違いを整理すると以下のようになります。

観点	.NET Core（EF Core）	FastAPI（SQLAlchemy等）
標準化	非常に高い	低い（選択制）
学習コスト	中程度	ツール依存で変動
非同期対応	限定的	高い（設計次第）
柔軟性	中程度	非常に高い

.NET Coreの強みは、ORMとフレームワークが密接に統合されている点です。
これにより、データモデルとビジネスロジックの整合性を保ちやすく、特にエンタープライズ環境での開発効率が高くなります。

例えばEntity Framework Coreでは以下のようなコードでデータアクセスを行います。

var users = await context.Users
    .Where(u => u.IsActive)
    .ToListAsync();

このようにLINQベースでクエリを記述できるため、SQLを直接意識せずにデータ操作が可能です。

一方FastAPIではORM選択の自由度が高いため、プロジェクトの特性に応じた設計が可能です。
例えば非同期処理を重視する場合はTortoise ORM、柔軟なクエリ設計を求める場合はSQLAlchemyが選ばれることが多いです。

この柔軟性は強みである一方で、技術選定の責任が開発チーム側に移るという側面もあります。
そのため設計初期段階での意思決定がプロジェクト全体の品質に大きく影響します。

またAPI設計においても同様の傾向があり、.NET Coreは規約ベースの設計が多く、FastAPIはデコレータベースで自由度の高い設計が可能です。
この違いは開発速度と保守性のバランスに直接関係します。

結果として、エコシステムとライブラリの観点では「安定した統一性を取る.NET Core」と「柔軟な拡張性を持つFastAPI」という対照的な構造が成立しています。

ユースケース別比較：企業システムとスタートアップ開発

バックエンド技術の選定において最も実務的な判断軸となるのが、「どのようなユースケースで使うのか」という観点です。
.NET CoreとFastAPIはどちらも高い完成度を持つフレームワークですが、適用される現場の性質によって最適解は大きく変わります。
特に企業システムとスタートアップ開発では、求められる要件そのものが異なるため、同じ評価基準では比較できません。

企業システムでは長期運用・高可用性・厳密な型安全性が重視されます。
一方スタートアップでは短期間でのMVP構築・変更容易性・開発速度が優先される傾向があります。
この違いが、.NET CoreとFastAPIの評価軸にそのまま反映されます。

まず企業システムの文脈では、.NET Coreの強みが明確に現れます。
C#による静的型付けと豊富なIDEサポートにより、大規模チーム開発においてもコード品質を一定に保ちやすい構造になっています。
また、Active DirectoryやAzureなどの企業向けサービスとの統合も強く、既存の業務基盤とスムーズに接続できる点は無視できません。

さらに、長期運用を前提とした場合には以下のような要件が重要になります。

• 厳密な型安全性によるバグの早期検出
• 標準化されたアーキテクチャによる保守性の確保
• 高負荷環境での安定したスループット
• ガバナンスを意識した設計統制

これらの観点において.NET Coreは非常に強力であり、金融・医療・行政システムなどのミッションクリティカル領域で広く採用されています。

一方でスタートアップ開発においては、状況が大きく異なります。
限られたリソースと時間の中で市場検証を行う必要があるため、開発速度と柔軟性が最優先されます。
この文脈ではFastAPIの軽量性とPythonの生産性が強く作用します。

FastAPIは最小限のコードでAPIを構築できるため、アイデア検証からプロトタイプ作成までのサイクルが非常に短いです。
またPythonの豊富なライブラリ群を活用することで、機械学習やデータ分析との統合も容易になります。

スタートアップ開発における典型的な要件は以下の通りです。

• 短期間でのプロダクトリリース
• 頻繁な仕様変更への対応
• 少人数チームでの高速開発
• 外部APIやSaaSとの迅速な統合

これらの条件ではFastAPIが非常に適しており、特にMVP開発やプロトタイピングでは圧倒的なスピードを発揮します。

また、スケール段階に応じた技術選定という観点も重要です。
スタートアップでは初期フェーズではFastAPIを採用し、成長に応じて.NET Coreや他のマイクロサービスへ段階的に移行するケースも見られます。
これは「初期速度」と「長期安定性」を分離して考えるアーキテクチャ戦略です。

両者のユースケース適性を整理すると以下のようになります。

観点	.NET Core	FastAPI
企業システム適性	非常に高い	中程度
スタートアップ適性	中程度	非常に高い
長期保守性	高い	設計依存
開発速度	中程度	非常に高い

このように、技術選定は単純な性能比較ではなく、プロダクトライフサイクル全体の中で評価する必要があります。
特に初期フェーズと成熟フェーズでは最適な技術が異なるため、将来的な拡張戦略を含めて判断することが重要です。

.NET CoreとFastAPIの選び方まとめ：最適なバックエンド選定指針

.NET CoreとFastAPIの比較を一通り整理すると、両者の違いは単なる性能差や言語差ではなく、ソフトウェア設計における思想の違いに起因していることが明確になります。
したがって最終的な選定は「どちらが優れているか」ではなく、「どの条件においてどちらが合理的か」という観点で行う必要があります。

まず.NET Coreは、エンタープライズ領域を強く意識した設計であり、長期運用・大規模チーム開発・厳密な型安全性を重視するシステムに適しています。
C#とCLRによる静的型付けとJIT最適化は、複雑な業務ロジックを安定して運用するための強力な基盤となります。
またAzureとの統合やVisual Studioによる開発支援も含めて、統一された開発体験を提供する点が特徴です。

一方FastAPIは、Pythonの生産性と軽量なフレームワーク設計を背景に、開発速度と柔軟性を最大限に引き出す構造になっています。
特にAPI開発やMVP構築、機械学習サービスとの統合といった領域では非常に高い適応性を持ちます。
非同期処理や型ヒントによる自動ドキュメント生成も含め、開発サイクルを短縮する設計が徹底されています。

このように両者は異なる最適化方向を持つため、選定基準を整理すると以下のようになります。

• 安定性と長期運用を重視する場合は.NET Core
• 開発速度と柔軟性を重視する場合はFastAPI
• 大規模チームでの統制が必要な場合は.NET Core
• 小規模チームやスタートアップ初期はFastAPI
• クラウド統合を重視する場合はAzure中心なら.NET Core、マルチクラウドならFastAPI

さらに重要なのは、プロジェクトのライフサイクルに応じた技術選定です。
初期段階ではFastAPIのような軽量フレームワークで迅速に仮説検証を行い、スケール段階で.NET Coreへ移行する、あるいはマイクロサービス単位で併用する構成も現実的な選択肢になります。

実務的には、単一技術で全てを解決しようとするよりも、役割分担を明確にしたハイブリッド構成が最も合理的です。
例えば以下のような構成が考えられます。

レイヤ	技術選定	役割
APIゲートウェイ	.NET Core	認証・ルーティング統制
ビジネスロジック	.NET Core / FastAPI	ドメインに応じて分割
データ処理API	FastAPI	高速開発・AI連携
管理系システム	.NET Core	長期運用・安定性重視

このように役割を分離することで、それぞれの強みを最大限に活かすことができます。

最終的な結論として、.NET CoreとFastAPIは競合関係というよりも補完関係に近い存在です。
設計者として重要なのは「どちらを選ぶか」ではなく、「どの部分にどちらを適用するか」という視点でシステム全体を設計することです。
その判断が、長期的な保守性・拡張性・開発効率を大きく左右することになります。