Pytestとは？Pythonテストフレームワークの基本・使い方・フリーランス案件単価への影響を徹底解説
最終更新日：2026/05/28
Pytestとは、Pythonで書かれたテストコードを効率的に実行・管理するためのオープンソースのテストフレームワークです。標準ライブラリのunittestと比べて少ないコードでテストを書け、fixtureやparametrizeなどの強力な仕組みを持つことから、多くのPython開発現場で広く採用されています。本記事ではPython案件でテスト自動化を担うフリーランスエンジニア向けに、基本機能から学習手順、案件単価への影響までを整理します。
先に結論
Pytestは、Pythonで広く使われるテストフレームワークの一つです。少ないコードで書け、実務ではfixtureやparametrize、CI連携まで含めて使われています。
Pytestは、Pythonのテスト自動化案件で有力な選択肢として扱われるフレームワーク。学習コストが低く、表現力の高さで現場の支持を集めている
標準のunittestと比べて、テスト関数の書き方がシンプルで、assert文がそのまま使える点が大きな違い
fixtureとparametrizeを使いこなせるかが、現場で「テストが書ける人」と見なされる分岐点
フリーランス案件では、Python本体スキルにPytest経験が加わることで参画できる案件の幅が広がりやすい。単価への直接的な上乗せは限定的だが、CI/CDやテスト戦略の文脈で評価される
Web系（Django・Flask）／データ分析・機械学習／インフラ自動化など、Pythonが使われる領域全般で需要がある
この記事でわかること
Pytestがどんなフレームワークで、なぜ選ばれているのか
unittestや他のテストツールとの違い、使い分けの考え方
実務でよく使うfixture・parametrize・marker・pluginの基本
フリーランスエンジニアにとってPytestスキルが案件単価や受注幅にどう影響するか
案件参画前に確認しておきたい現場のテスト運用のチェックポイント
目次
Pytestとは？Pythonテストの定番フレームワーク
Pytestとunittest・その他テストツールとの違い
Pytestでできること（実務での使われ方）
Pytestの始め方（インストールから初回実行まで）
Pytestの主要機能（フリーランス現場でよく使うもの）
Pytestを使うフリーランス案件の単価相場と動向
Pytestの学習ロードマップ
Pytestを案件で活かすためのキャリア戦略
よくある失敗と対策
案件参画前に確認したいPytest関連のチェックポイント
まとめ
よくある質問
Pytestとは？Pythonテストの定番フレームワーク
Pytestとは、Pythonで書かれたコードのテストを記述・実行・管理するためのサードパーティ製のテストフレームワークです。インストールはpipで行い、Pythonの標準ライブラリには含まれていません。シンプルな書き方と柔軟な拡張性が評価され、Web開発、データ分析、機械学習、インフラ自動化まで、Pythonが使われるあらゆる領域で採用されています。
Pytest公式ドキュメント によれば、最小構成のテストは「test_」で始まる関数を作り、assert文で条件を書くだけで実行できます。クラス継承や特別なメソッド名のルールは必須ではないため、初学者でも書き始めやすい設計です。
Pytestの基本的な特徴
Pytestには、現場で評価されている特徴がいくつかあります。
assert文がそのまま使える：unittestのassertEqualやassertTrueといった専用メソッドを覚える必要がない
失敗時の出力が読みやすい：assert失敗時にローカル変数の値を整形して表示する
fixtureによる前処理・後処理の共通化：setUp/tearDownを書くより柔軟に組める
parametrizeで同じテストを複数データで回せる：データ駆動テストが簡潔に書ける
プラグインエコシステムが豊富：pytest-mock、pytest-django、pytest-asyncioなど、用途別の拡張が揃う
なぜPytestが選ばれるのか
Python本体には標準ライブラリのunittestが存在するため、フレームワークを別途導入する必要は本来ありません。それでもPytestが選ばれる理由は、「テストを書く負担を減らす」設計思想にあります。
unittestがJavaのJUnitを参考にしているのに対し、Pytestは「Pythonらしさ」を重視した設計です。クラスを継承せず関数だけで書ける、assert文がそのまま動く、fixtureが関数の引数として宣言できる——こうした記法は、テストコードを読み書きする時間を短縮します。Python案件でテスト自動化が議題に上がるとき、新規導入時にPytestが有力候補として扱われることが多いです。
なお、Javaのテスト領域では JUnit が広く使われており、JavaからPythonに転向する場合はPytest独自の書き方を学び直す方がスムーズです。
ミニFAQ
Q. Pytestはどのバージョンを学べばよいですか？
執筆時点ではPytest 8系が安定版として配布されています。PyPIのpytestページ で最新の安定版を確認したうえで学習を始めるのが安全です。古いバージョンの解説記事に従うと、対応Pythonバージョンや一部APIの違いで詰まることがあるため、公式ドキュメントを併用してください。
Pytestとunittest・その他テストツールとの違い
PythonのテストツールにはPytest以外にも複数の選択肢があります。違いを整理すると、選定や案件参画時の判断がしやすくなります。
ツール | 位置づけ | 特徴 |
|---|---|---|
unittest | Python標準ライブラリ | クラスベース。JUnitに近い書き方。標準なので追加インストール不要 |
Pytest | サードパーティ | 関数ベース。assert文をそのまま使える。fixture・parametrizeが強力 |
nose2 | サードパーティ | 旧noseの後継。利用ケースは限定的 |
doctest | Python標準ライブラリ | docstring内の例をテストとして実行する |
unittestとの違い（標準ライブラリ vs サードパーティ）
unittestはPython標準ライブラリのため追加導入不要というメリットがあります。一方Pytestは、unittestで書かれたテストもそのまま実行できるという互換性を持っています。既存のunittestテスト資産がある現場では、まずPytestをランナーとして導入し、新規テストはPytest流で書いていく、という移行が一般的です。
新規プロジェクトであればPytestを最初から選ぶケースが多く、移行を検討する場合も「Pytest側で全て吸収できる」点が判断材料になります。
nose・nose2の現在地
かつてはnoseがPytestと並ぶ選択肢でしたが、オリジナルのnoseは公式に開発終了が宣言されています。後継のnose2は維持されていますが、新規採用の事例は減っており、現場でnose2を求められるケースは限定的です。古い保守案件でnose系のテストが残っている場合は、Pytestへの移行計画の有無を参画前に確認すると安全です。
PytestとPython標準ライブラリのunittestの選び分け
選び分けの目安は次のとおりです。
新規プロジェクト：Pytestを採用するケースが多い
小規模スクリプトのテストを最小構成で：標準のunittestで十分
テストデータが多い／前処理が複雑：Pytestのfixtureとparametrizeで簡潔に書ける
JUnit経験者が多いチーム：unittestのクラスベース記法が読みやすい場合もある
Pytestでできること（実務での使われ方）
Pytestは「単体テストを書くだけのツール」ではありません。実務では、テスト戦略の幅広いレイヤーで使われます。
ユニットテスト
関数やクラスメソッドの入出力を検証する基本的な使い方です。Pytestはassert文だけで書けるため、テスト対象の関数仕様を読みやすく宣言できます。fixtureで前提条件を組み立て、parametrizeで境界値を網羅する、という流れが定番です。
統合テスト
複数モジュールを組み合わせた動作を確認するテストです。WebアプリであればDBやキャッシュを含めた挙動の確認、データ処理パイプラインであれば入力ファイルから出力までの一連の確認、といった用途で使われます。pytest-djangoやpytest-flaskといったフレームワーク統合用プラグインが整備されており、Django や Flask を使う案件では歓迎要件として求められやすくなっています。
E2E（End to End）テスト
ブラウザ操作を含むE2Eテストは、PytestとSelenium・Playwrightを組み合わせて構築されます。テストランナーとしてPytestを採用しつつ、UI操作部分はPlaywrightに任せる、という分業が一般的です。
CI/CDパイプラインへの統合
Pytestは GitHub Actions や Jenkins との統合実績が豊富で、プルリクエストごとに自動でテストを回す運用が組みやすい点も評価されています。JUnit互換のXMLレポートを出力するオプションがあり、CIツール側の集計と相性が良い構造になっています。
ミニFAQ
Q. Pytestはデータ分析や機械学習のコードでも使いますか？
はい、pandasやNumPyを使う処理のロジックテスト、機械学習モデルの前処理関数のテストなどで使われます。データ系の現場ではテストが整備されていないコードベースも多く、テストを書ける人材の希少性が高い側面があります。
Pytestの始め方（インストールから初回実行まで）
Pythonと仮想環境の扱いに慣れていれば、Pytestのインストールから最初の動作確認までは短時間で進めやすい構成になっています。
環境準備
Python公式サイト からPython本体を導入し、仮想環境（venvまたはvirtualenv）を作成します。仮想環境内でpip install pytestを実行すると、Pytestのインストールは完了します。プロジェクト直下にrequirements.txtを用意し、テスト依存をまとめておくと、CI環境での再現性が高まります。
最初のテストを書く
プロジェクト直下、もしくはtests/ディレクトリに、ファイル名を「test_」で始めるPythonファイルを作ります。ファイル内では、「test_」で始まる関数を定義し、assert文で期待値を書きます。たとえば足し算をする関数をテストする場合、テスト関数の中で関数を呼び出し、結果が期待した値と等しいかをassertで宣言する、という流れになります。
実行と結果の見方
ターミナルでpytestコマンドを実行すると、プロジェクト配下のテストファイルが自動で検出され、まとめて実行されます。多くの環境では結果が色付きで表示され、失敗時はassert失敗箇所の前後数行が抜粋表示され、変数の値も整形されて出ます。原因の特定が早いことが、Pytestの初学者にも好評な理由のひとつです。
Pytestの主要機能（フリーランス現場でよく使うもの）
実務でPytestを使う場合、純粋なassert文だけでは足りない場面が出てきます。現場で頻出する機能を押さえておくと、参画初日からテストを書く側に回りやすくなります。
fixture（前処理・後処理の共通化）
fixtureは、テストの前に共通で準備したいオブジェクト（DBセッション、設定オブジェクト、テストデータなど）を関数として定義し、必要なテストの引数として宣言して使う仕組みです。conftest.pyというファイルにfixtureをまとめると、複数のテストファイルから自動で参照されます。
unittestのsetUp/tearDownと比較すると、fixtureはスコープ（function/class/module/session）を柔軟に指定でき、必要な箇所だけで呼び出せる点が利点です。たとえばDB接続を1テストセッション全体で共有したい場合、scope="session"を指定することで、毎回の接続オーバーヘッドを抑えられます。
parametrize（テストデータのバリエーション）
@pytest.mark.parametrize というデコレーターを使うと、同じテストロジックを複数の入力データで自動的に繰り返し実行できます。境界値テスト、異常系テスト、複数言語のロケールテストなど、データ駆動のテストを簡潔に書けます。テストケースの数が増えても、本体のコードを増やさずに済むのが大きな利点です。
marker（テストの分類・条件付き実行）
markerは、テストにタグを付けて分類する仕組みです。重いテストにslowマーカーを付けておき、CIでは普段はslow以外だけを実行し、夜間ビルドでslowを含めて全て実行する、といった運用ができます。@pytest.mark.skipや@pytest.mark.skipif を使うと、特定の条件下でテストをスキップできます。
plugin（pytest-mock、pytest-cov、pytest-xdistなど）
Pytestはプラグインで拡張する文化が強く、現場では以下が頻出します。
pytest-mock：標準のunittest.mockをPytest流に使えるようにする
pytest-cov：テストカバレッジを計測してレポート出力する
pytest-xdist：テストを複数プロセスで並列実行して時間短縮する
pytest-django：Djangoプロジェクト向けの統合ユーティリティを提供する
pytest-asyncio：async/awaitなテストを書けるようにする
これらは公式パッケージというより、サードパーティの実績あるプラグインです。プロジェクトのrequirementsに何が入っているかを確認すると、その現場のテスト戦略の一端が読み取れます。
ミニFAQ
Q. fixtureを増やしすぎるとどうなりますか？
fixtureが多すぎたり、fixture同士の依存関係が深くなったりすると、テストの可読性が落ちます。「このテストで何が準備されているのか」を追うのに時間がかかるようになり、保守の負担が増します。conftest.pyに置くfixtureは「複数のテストで本当に共通化が必要なもの」に絞り、単発のセットアップは関数内で書く判断が現場では取られます。
Pytestを使うフリーランス案件の単価相場と動向
ここでは、Python案件でPytestがどう評価されるか、フリーランスとしての受注に与える影響を整理します。相場の数値は条件依存が大きく、ここで挙げる数字は2025〜2026年時点で主要フリーランスエージェントの公開案件（週3〜5日・業務委託・リモート可含む）を横断的に確認した際の傾向です。非公開案件・直請けは含みません。
案件で求められるレベル感
Pytestを案件で使う場合、求められる水準はおおむね3段階で観測できます。
入門レベル：既存テストの実行・修正、簡単なテスト追加ができる
中級レベル：fixture・parametrize・markerを使い分け、新規モジュール向けのテストを設計できる
上級レベル：テスト戦略を立てる、CI/CDに統合する、カバレッジ運用やテスト分割で開発サイクル全体を最適化する
入門レベルでも「テストが書ける人」として参画はできますが、中級以上になると単価の交渉余地が広がります。
単価相場の目安
公開案件ベースでは、Python本体経験がある前提で、Pytest経験を組み合わせた場合の傾向として次のような分布が見られます。
案件タイプ | 単価レンジ（月額・目安） | 主な要件 |
|---|---|---|
Webアプリ開発（Django/Flask）＋Pytest | 60〜90万円 | フレームワーク経験3年以上、テスト設計の経験 |
データ分析・機械学習＋Pytest | 70〜100万円 | データ系の実務経験、テストでの品質担保の経験 |
インフラ自動化・SRE文脈＋Pytest | 70〜110万円 | クラウド／インフラスキル＋Python＋テスト自動化 |
テスト自動化専任（QAエンジニア寄り） | 60〜90万円 | テスト戦略・E2E・CI連携の経験 |
これらの単価は、いずれも複数年のPython実務経験を前提とした目安です。Pytest単体での加算というより、「Pythonエンジニアとして案件に参画する際、テストを任せられる人材かどうか」が評価ポイントになります。レンジに入る人物像の目安として、60〜80万円帯は実装・既存テストへのテスト追加が中心の人、90万円超はテスト戦略の設計・CI/CD整備・レビュー方針策定・E2E運用まで担当できる人が対象になりやすい傾向があります。月額90〜110万円前後の高単価帯は、複数年のテスト戦略実務に加えて、品質指標を設計・運用した経験があるシニア層を想定して募集されるケースが目立ちます。
フリーランスエンジニアの単価相場 も合わせて参考にしてください。
Pytestスキルが評価される文脈
単価そのものを引き上げる要素というより、Pytestは「参画後の貢献の幅を広げる」スキルと捉えるのが現実的です。次のような場面で評価されます。
既存コードベースの品質改善：テストが薄いコードに後追いでテストを書く案件
新規プロジェクトの立ち上げ：テスト戦略を最初から設計する案件
レビューの質向上：プルリクエストにテストが付いてくるエンジニアは信頼されやすい
CI/CD整備：GitHub Actions 等での自動実行設定までできると重宝される
Pytestの学習ロードマップ
初心者から実務で使えるレベルに到達するまでの順序を整理します。
初心者がまず押さえること
最初に取り組むべきは、次の3点です。
pip install pytest から最初のテスト実行までを自力でできること
assert文の基本パターン（等値、近似、例外発生の確認、コレクションの中身確認）
fixtureの最小例（戻り値を持つ関数を引数として受け取る形）
ここまで身につけば、自分が書いたコードに対する簡単なテストは書けるようになります。
中級レベルへのステップ
中級では、現場でよく見るパターンに対応できる力が問われます。
conftest.pyを使ったfixtureの共有
parametrizeでの境界値テスト、異常系テストの設計
markerによるテスト分類
カバレッジ計測の基本（pytest-cov）
pytest-mockによる外部依存（API呼び出し、DB等）のモック化
このあたりまで来ると、新規モジュールのテストを任されても自走できる水準になります。
学習リソース
公式ドキュメント以外では、技術書とオンライン教材を組み合わせる学習が定番です。
公式のチュートリアルセクション：Getting Started、Fixtures、Parametrizing tests のページが基本
英語が苦にならなければ、公式のExamples and customization tricks のページが実務寄り
Python本体の理解が浅い場合は、先に Pythonとは？できること、将来性、年収・キャリアまで徹底解説！ を読んで全体像を掴んでからPytestに進むと、学習効率が上がります。
ミニFAQ
Q. 学習時間の目安はどのくらいですか？
学習時間は個人差が大きいため一概には言えませんが、Python本体の基礎ができている人であれば、Pytestの入門レベルは比較的短期間で押さえられる傾向があります。中級レベル（fixture・parametrize・marker・カバレッジを使い分けられる）に到達するには、実プロジェクトで使いながら一定期間の経験を積む必要があります。机上学習だけで完成させるより、実際の案件・個人プロジェクトで使いながら習得するアプローチが現場では一般的です。
Pytestを案件で活かすためのキャリア戦略
Pytestを単独スキルとして売るのではなく、他スキルとの組み合わせで案件の幅を広げる戦略が現実的です。
テスト自動化案件で重宝されるスキルセット
テストエンジニア として参画する場合、Pytestに加えて以下があると評価されやすくなります。
E2EテストツールのSeleniumまたはPlaywrightの経験
CI/CDの実装経験（GitHub Actions、Jenkins、CircleCIなど）
テスト戦略の立案経験（テストピラミッド、テスト分割の判断）
カバレッジツールの運用経験
Web開発エンジニアとしての組み合わせ
Django・Flask案件では、Pytestを使えることが「テストまで含めて任せられるエンジニア」の条件になりつつあります。
データ・機械学習領域での価値
データ分析・機械学習の現場ではテストが薄いコードベースが残っているケースが少なくありません。「データ系の知見」＋「テスト自動化」を併せ持つ人材は、品質改善の文脈で重宝される傾向があります。データ前処理関数のロジックテスト、モデルの推論結果に対するリグレッションテストなどが代表例です。
よくある失敗と対策
Pytest導入や運用で陥りやすいパターンを整理します。
fixtureの乱用と依存関係の肥大化
fixtureを共通化しすぎると、conftest.pyが肥大化し、各テストでどのfixtureが効いているのか追えなくなります。「2回以上同じ前処理を書きそうになったら共通化する」程度の温度感で進め、単発のセットアップは関数内に書く判断が現場では取られます。
テストが遅くなる原因
テスト数が増えると実行時間が問題になります。原因は、DB接続を毎回張り直している、本番に近いデータを毎回ロードしている、外部APIを実際に叩いている、といったケースが典型的です。fixtureのscopeを見直す、モックを使う、pytest-xdistで並列実行する、といった対応が効きます。
CI/CDとの統合での落とし穴
ローカルでは通るがCIで落ちる、というケースの多くは、テストの実行順依存（あるテストが他のテストの結果に依存している）、環境変数の不一致、タイムゾーンの違いなどが原因です。テスト間の独立性を保つ、CIと同じイメージでローカル実行する、といった対策がポイントになります。
テストを書く時間が確保できない問題
「テストを書く時間がない」と現場で言われるケースは多くあります。実際は、テストがないことで生まれるバグ対応や手動確認の時間が、テストを書く時間を超えていることが多くあります。新規追加コードにだけテストを書く、というルールから始めると、既存全部にテストを書くプレッシャーなく自動化を進められます。
案件参画前に確認したいPytest関連のチェックポイント
参画する案件のテスト運用は、参画前にある程度確認しておくと参画後の負担が読みやすくなります。
確認項目 | チェック内容 |
|---|---|
テストの有無 | そもそもPytest（または他のテストツール）が導入されているか |
カバレッジ | どの程度カバレッジが取られているか、目標値があるか |
CI連携 | プルリクエストごとに自動でテストが実行されているか |
テスト方針 | テストを書く文化があるか、誰が書く前提か |
旧バージョン依存 | Python本体・Pytest本体・主要プラグインのバージョンと、サポート切れの可能性 |
特にPythonやPytestのバージョンが極端に古い場合は、依存ライブラリのEOL（公式サポート切れ）と併発しているケースがあり、保守案件で残っていてもセキュリティアップデート計画の有無を確認する必要があります。
まとめ
Pytestは、Python案件で品質担保まで任せられる人材になるための実務スキルです。assert文がそのまま使える書きやすさ、fixtureとparametrizeによる柔軟な構成、豊富なプラグインエコシステムを背景に、Web系・データ系・インフラ系まで幅広く採用されています。
標準のunittestと比べて、シンプルな関数ベースで書ける点が大きな違い
fixture・parametrize・markerを使いこなせると、現場の即戦力に近づく
フリーランス案件では、Pythonスキルと組み合わせることで参画できる案件の幅が広がる
単価への直接的な上乗せは限定的だが、テスト戦略やCI/CD整備まで担えると評価される（特にDjango/FastAPIでの開発経験＋テスト追加＋CI連携の経験を持つ層）
学習は公式ドキュメントを軸に進め、執筆時点ではPytest 8系を対象に学ぶのが妥当
Pythonエンジニアとして案件の選択肢を広げたいなら、Pytestは早めに身につけたいスキルです。テスト自動化の経験を積みたい場合は、まず手元のプロジェクトに小さく導入し、CI連携まで含めて運用してみると、案件で求められる感覚が掴めます。フリーランスとしてのキャリア設計や案件探しは、フリコン のキャリア相談も合わせて活用してください。
参考リンク
よくある質問
Q1. Pytestは無料ですか？商用利用に制限はありますか？
PytestはMITライセンスのオープンソースソフトウェアで、商用利用を含めて無料で使えます。ライセンス条件を満たせば、業務システムでも個人プロジェクトでも自由に利用できます。
Q2. Pytestを使う場合、unittestの知識は不要ですか？
不要ではありませんが、必須でもありません。Pytestはunittestで書かれたテストもそのまま実行できるため、移行プロジェクトの場合はunittestを読める知識があると助かります。新規プロジェクトであれば、最初からPytestの書き方で進めて問題ありません。
Q3. Pytestを覚えるとフリーランス案件の単価は上がりますか？
大きくは上がりにくいですが、案件の幅は広がりやすいです。Pythonエンジニアとしての実務スキルに加えて、テストまで責任を持てる人材になることで、参画できる案件の選択肢が増え、結果として単価交渉の余地が生まれる流れが現実的です。
Q4. PytestとSeleniumの関係は何ですか？
Pytestはテストランナー、Seleniumはブラウザ操作のライブラリです。E2Eテストを書く場合、Pytestをランナーとして使い、その中でSeleniumを呼び出してブラウザを操作する、という組み合わせが一般的です。PlaywrightやCypressと比較されるのはSelenium側であり、Pytestは引き続きランナーとして使えます。
Q5. Pytestのテストが多くなりすぎて実行時間が長くなった場合の対処は？
pytest-xdistで複数プロセスに分けて並列実行する、markerでテストを分類して必要なものだけ実行する、fixtureのscopeを広げて初期化コストを下げる、外部APIや重い処理をモック化する、といった対応があります。CIでは並列度を上げ、ローカルでは変更箇所周辺だけを実行するなど、ユースケースに合わせて使い分けます。
Q6. Pytestは非同期コード（async/await）にも対応していますか？
標準では非同期テストに対応していませんが、pytest-asyncio というプラグインを導入すると、async関数をテストとして書けるようになります。FastAPIや非同期ライブラリを使うプロジェクトではよく採用されるプラグインです。
Q7. PytestとJUnitの違いは何ですか？
両者ともテストフレームワークですが、JUnitはJava向け、PytestはPython向けです。設計思想も異なり、JUnitはクラスベース、Pytestは関数ベースで書くのが基本です。JUnit経験者がPytestに移る場合は、クラス継承を前提にせず関数だけで書けることが最初の発見になります。詳細は JUnitとは？Javaエンジニアの年収と未来を変える「テスト自動化」 も参照してください。
Q8. Pytestの設定ファイルはどこに書きますか？
pytest.ini、pyproject.toml、setup.cfg、tox.iniのいずれかに書きます。新規プロジェクトではpyproject.tomlに集約するケースが増えています。設定で指定する代表項目は、テストディレクトリのパス、デフォルトのオプション（カバレッジ計測の有無など）、markerの登録などです。
Q9. 初学者がPytestで最初につまずく箇所はどこですか？
fixtureの仕組みでつまずくケースが多くあります。「関数の引数にfixture名を書くと、その関数の戻り値が渡される」というPytest独自の発想に最初は戸惑いやすいです。公式ドキュメントのFixturesセクションのサンプルコードを写経して動かすところから始めると、感覚を掴みやすくなります。
Q10. Pytestは将来も主流であり続けますか？
執筆時点ではPythonテストフレームワークの中で最も広く使われている部類に入ります。短期で別のフレームワークに置き換わる兆候は見られないため、当面は学んだ知識を活かせる前提で取り組んでよいといえます。ただし技術トレンドは変化するため、毎年公式ドキュメントとリリースノートを確認する習慣をつけておくと安心です。
