PyTorchとは？特徴やTensorFlowとの違い、MNIST実装例を解説

PyTorchとは、Meta（旧Facebook）が開発し、現在はPyTorch Foundationが運営する動的計算グラフ型の深層学習フレームワークです。
Pythonicなコーディングスタイルと豊富なエコシステムを武器に、2026年時点で研究フェーズと生成AI開発のデファクトフレームワークとして広く使われています。

本記事では、2026年7月にGA提供された2.13までの直近アップデート、主要な特徴とできること、環境構築とテンソル操作の基本、MNISTを使った画像分類ハンズオン、本番運用に向けた高度機能、TensorFlowやJAXとの比較、GPU/クラウドの学習コスト相場までを体系的に解説します。

PyTorchとは？Meta発・PyTorch Foundation運営の深層学習フレームワーク

PyTorch（パイトーチ）とは、Meta（旧Facebook）が2016年に発表し、現在はPyTorch Foundationが運営する動的計算グラフ型の深層学習フレームワークです。

Pythonでニューラルネットワークを直感的に書き下せる設計と、NVIDIA・AMD・Apple Silicon・Intel等の主要アクセラレータへの幅広い対応を武器に、研究・本番運用の両方で使われるインフラへと成長しました。

2022年にMetaからLinux Foundation配下のPyTorch Foundationへ移管、2025年以降はvLLM・DeepSpeed・Ray・Safetensors・Helion等が順次ホストプロジェクトに加入し、単一プロジェクトからベンダーニュートラルなエコシステム全体の名称として拡大しました。

研究から本番運用までを1本で担うポジション

PyTorchは「研究者向け」と紹介されがちですが、2026年時点では研究フェーズから本番運用までを1本のフレームワークでカバーする構造に育っています。

• 研究フェーズ
  論文実装で最も使われる動的計算グラフ・PythonicなAPI、モデル改変・実験の高速イテレーション
  
  
• 本番運用フェーズ
  torch.compileによるコンパイラ最適化、FSDP2の大規模分散学習、ExecuTorchでの組込みデプロイまで1本で対応

ポイントは、PyTorchは「研究者向け」から「研究〜本番運用の一気通貫フレームワーク」へ役割が広がった、という点です。

サーバ推論の使い分けやvLLM等専用エンジンとの併用は、後段の「本番運用に向けた高度な機能」で扱います。

PyTorch 2.12/2.13の直近アップデートで何が変わったか

2026年に入ってからのPyTorchは、リリース頻度が四半期ごとから2か月ごとへと加速し、進化のペースが一段上がりました。

本セクションでは、2026年5月にGAとなった2.12、7月にGAとなった最新版2.13の主要アップデートを、実務で影響が大きいものに絞って整理します。

2026年の4バージョンで一気に進化

2026年に入ってから公開されたリリースは、以下の4本です。

四半期リリースからの短縮により、四半期あたり約1.5リリース分の変更量が積み上がる形になっています。

新機能を追跡する負荷は上がりましたが、Inductorバックエンドの拡張・分散学習APIの整理・エッジ推論との統合といった、実務直結の改善スピードは明確に速くなっています。

2.12で追加された注目アップデート

2.12は「デバイス非依存性の強化」と「LLM向け量子化のワークフロー整備」に踏み込んだリリースです。

• torch.accelerator.Graph（デバイス非依存の統一グラフAPI）
  CUDA・XPU・Out-of-treeバックエンドをまたいでグラフ捕捉と再実行を統一する新API。従来はデバイス固有APIを叩き分ける必要があった箇所を1本化できます。
  
  

• torch.exportがMX（Microscaling）量子化フォーマットに対応
  float8_e8m0fnu型の保存・読込がサポートされ、MXFP4/6/8で圧縮したLLMをそのままエクスポート・デプロイできるようになりました。
  
  

• linalg.eighが最大100倍高速化
  バッチ処理の固有値分解の内部実装がMAGMAからcuSolverに切り替わり、多数の小行列を扱う科学計算・機械学習ワークロードで従来比100倍近い高速化を達成。
  
  

• Adagradにfused=Trueが追加
  Adam・AdamW・SGDに続き、Adagradも単一CUDAカーネルで最適化ステップを実行できるようになり、大規模学習でのカーネル起動オーバーヘッドが削減されました。
  
  

• torch.condのCUDA Graphs捕捉
  データ依存の条件分岐をCUDA Graphs内に取り込めるようになり、動的なモデル構造でもグラフキャッシュの恩恵を受けやすくなりました。

詳細な変更点はPyTorch 2.12 Release Blogにまとまっています。

すべての変更を追う必要はありませんが、torch.exportとMX量子化はLLMを扱うチームにとって押さえておく価値があるアップデートです。

TorchScriptは2.10以降も非推奨継続

2.12で明示的に扱われた大きな方向転換は、TorchScriptの非推奨継続とtorch.export／ExecuTorchへの移行推奨です。

PyTorch 2.12 Release Blogには「TorchScript was deprecated in 2.10 and torch.export should be used to replace the jit trace and script APIs, and Executorch should be used to replace the embedded runtime」と明記されています。

2.12時点では削除されておらず、既存の「.pt」モデルは引き続き読み込み・実行が可能ですが、新規開発では以下のルートが推奨です。

アップグレード時に即座に動かなくなるわけではありませんが、2020〜2023年頃に構築したTorchScript本番パイプラインは長期的には移行対象になります。

既存本番システムを持つチームは、非推奨化ロードマップと自社モデルの寿命を照らし合わせて、移行計画を早めに立てておくのが現実的です。

2.13で追加された最新機能

2026年7月8日にGAとなった最新版2.13では、注目度の高い機能がさらに追加されています。

• FlexAttentionのMPS対応と決定的バックワード（API Unstable）
  Apple Silicon（MPS）でFlexAttentionが動くようになり、疎な注意パターンで最大約12.3倍の速度向上が報告されています。
  
  ただし公式にはAPI Unstableと明記されており、本番導入は慎重に判断すべき段階です。
  
  

• CuTeDSL "Native DSL" Inductorバックエンド（API Unstable）
  Inductorが新しいCUTLASS由来のDSLをネイティブに扱えるようになり、行列演算カーネルの最適化余地が広がります。
  
  

• nn.LinearCrossEntropyLoss（API Unstable）
  線形層＋交差エントロピー損失をメモリ効率よく融合するモジュール。大規模ボキャブラリのLLM学習でGPUメモリを節約できます。
  
  

• torchcommsの新バックエンド追加（API Unstable）
  分散学習用の新しい通信バックエンドとして、torchcommsが追加されました。既存のc10dバックエンドの代替として位置づけられ、API互換性を保ちながらフォールトトレランス・スケーラビリティ・可観測性を強化します。
  
  

• Safetensors直接読み込みの試験的サポート（API Unstable）
  「torch.load("foo.safetensors")」のように、Safetensorsフォーマットを直接読み込む機能が試験的に追加されました。従来は「safetensors」パッケージを別途呼び出す必要がありましたが、標準APIから扱えるようになった形です。
  
  

• Python 3.15対応（プレビュー・Linuxのみ）
  Python 3.15の通常ビルドと3.15tのFree-threadedビルドの公式wheelが提供されますが、Linuxのx86_64／aarch64限定・torchvision非対応・torch.compile非対応・PyPIには未公開（download.pytorch.orgから直接取得）というかなり強い制約付きプレビューです。

変更全量はPyTorch 2.13 Release Blogを参照してください。ほとんどが公式にAPI Unstableと明記されており、「新しい選択肢が増えた」段階で、既存実装をすぐに置き換える必要はありません。今後の安定化状況を見ながら、必要な機能から段階的に評価するのが安全です。

PyTorchの主要な特徴——動的計算グラフとPythonicな設計

PyTorchが多くの研究者・開発者に選ばれ続けている背景には、フレームワークとしての設計思想があります。

本セクションでは、PyTorchを他フレームワークと分ける4つの主要特徴を整理します。

動的計算グラフ（Define-by-Run）

PyTorchの最大の特徴は、動的計算グラフを採用している点です。

モデルの計算グラフは、Pythonコードを実行するそのタイミングで動的に構築されます。この方式は「Define-by-Run」と呼ばれ、通常のPythonプログラムと同じ感覚でモデル構造を書けます。

具体的なメリットは以下の3点です。

• デバッグが直感的
  モデルの中間層に「print()」を挟んだり、Python標準デバッガで途中の値を確認したりが自然にできます。静的グラフ方式のようにセッション起動やグラフ再ビルドが不要です。
  
  

• 条件分岐・ループを含むモデルも自然に書ける
  入力長に応じてループ回数が変わるRNNや、条件によってレイヤー構造を切り替えるモデルも、Pythonの「if」や「for」をそのまま書き下せます。
  
  

• 試行錯誤のサイクルが速い
  モデル定義を変えるたびにグラフを再構築する必要がないため、研究フェーズでの実験サイクルが短くなります。

TensorFlowも2.0以降でEagerモードをデフォルトにして動的グラフに歩み寄りましたが、後述する「torch.compile」によって静的グラフ相当の最適化も同時に得られるようになっており、動的グラフの柔軟性は今もPyTorchの中核的な差別化要素として残っています。

Pythonicな設計とNumPy親和性

PyTorchのテンソルAPIは、NumPyの配列APIと極めて近い設計で作られています。

「view()」「reshape()」「permute()」「matmul()」など、NumPyユーザーにとって馴染みやすい命名が多く採用されており、GPU対応のNumPyの延長として直感的に触りやすい設計になっています。

ただし「view」はNumPyと意味が異なり、「permute」はNumPyの「transpose」と名称が違うといった相違はあります。

import torch

# NumPyと同じ感覚でテンソルを作成・演算できる
x = torch.zeros(3, 4)
y = torch.randn(3, 4)
z = x + y * 2

# GPUに転送するのは1行
z_gpu = z.to("cuda")

「view」はNumPyと意味が異なり、「permute」もNumPyの「transpose」と呼び分けが違うといった相違はありますが、機械学習やディープラーニングを新しく学ぶエンジニアがPyTorchから入りやすい大きな理由の一つになっています。

主要な研究分野で事実上の標準

近年の深層学習の主要国際会議（NeurIPS、ICML、ICLR、CVPR等）に採択された論文の多くはPyTorchで実装されており、研究フェーズでは事実上の標準として広く使われています。

具体的な導入率は調査手法によって数値の差はありますが、以下の循環が業界全体で観察されています。

• 論文と参照実装がPyTorchで公開される
  最新モデル（Transformer系・拡散モデル・GAN・音声モデル等）の公式実装はPyTorchで公開されるケースが増えました。
  
  

• Hugging Face の主要モデルがPyTorch優先
  Hugging Face Hub上のTransformers・Diffusers・Accelerateといった主要ライブラリは、PyTorch実装が第一級市民として扱われます。
  
  

• 社内実装もPyTorchに寄る
  論文実装をベースに社内プロダクトを組み立てるチームが増えるほど、既存資産としてPyTorchが選ばれやすくなる循環が働きます。

「まず論文を試したい」「Hugging Face Hubのモデルをそのまま動かしたい」というフェーズでは、PyTorchが有力な第一候補となる状況です。Hugging Face TransformersはTensorFlow・Flax対応モデルも公開していますが、実装ノウハウ・チュートリアル・OSSツールの厚みではPyTorchベースが広く使われています。

LLM・オープンウェイトモデルの基盤

2023年以降のLLMブームでも、オープンウェイト系モデル（Meta Llama系・Mistral・Qwen・PLaMo等）の多くがPyTorchで実装・公開されています。

推論だけでなくファインチューニングやLoRA適用、RLHF/DPOによるアラインメントまで、PyTorch＋TRLやPEFTを組み合わせるスタックが広く使われています。

企業内で大規模言語モデル(LLM)をカスタマイズする案件では、PyTorchで動く前提でチューニング・評価・デプロイパイプラインを設計するケースが多く見られます。LLM領域では、PyTorchが有力な第一候補として選ばれやすい状況です。

PyTorchでできること——CVからLLM・エッジまで

PyTorchが強い領域は年々広がり、現在は「主要なAIタスクはPyTorchでカバーできる」状態になっています。

本セクションでは、代表的な応用領域を整理します。

コンピュータビジョン（画像認識・生成）

画像認識・物体検出・セグメンテーション・画像生成のいずれの領域でも、PyTorchベースの実装が広く使われています。

• 画像分類
  ResNet・EfficientNet・ViT・SwinTransformer・DINOv2などのバックボーン実装が公式リポジトリ・timm経由で提供されており、転移学習・ファインチューニングを数十行のコードで実行できます。
  
  

• 物体検出・セグメンテーション
  Detectron2・MMDetection・YOLOシリーズなど、主要なフレームワークがPyTorchで実装されています。
  
  

• 画像生成
  Stable Diffusion・SDXL・Fluxといった拡散モデルはPyTorchが標準実装で、Diffusers経由で数行のコードから利用できます。

CNN（畳み込みニューラルネットワーク）からTransformer系まで、CV分野の主要アーキテクチャはPyTorchで組むのが最短ルートです。

自然言語処理・LLM

自然言語処理とLLM領域は、Hugging Face Transformersを中心にPyTorchで組むのが標準です。

• モデル利用
  LLaMA・Mistral・Qwen・Gemma・PLaMoなどのオープンウェイトモデルを、「AutoModelForCausalLM.from_pretrained()」で1行呼び出し可能。
  
  

• ファインチューニング
  LoRA・QLoRA・DPO・GRPOなどのアラインメント手法もPyTorchベースのTRL・PEFTで実装されています。
  
  

• 推論最適化
  vLLM・SGLang・TensorRT-LLMといった推論エンジンも、PyTorchモデルを入力として受け付けるのが標準的なインターフェイスです。

SLM（小規模言語モデル）から数百Bクラスの大規模モデルまで、規模に関わらずPyTorchでの実装ノウハウが業界に蓄積されているのが強みです。

音声・強化学習・その他

音声認識・音声合成・強化学習・時系列予測など、CV／NLP以外の領域でもPyTorchベースの実装が広く使われています。

• 音声処理
  Whisper（音声認識）・XTTS（音声合成）はPyTorchベースで提供されており、VALL-E系についてはMicrosoftの研究発表を受けて非公式のPyTorch実装も公開されています。
  
  

• 強化学習
  Stable Baselines3・CleanRL・TorchRLといった主要ライブラリがPyTorchベースで整備されています。
  
  

• 時系列・表形式データ
  DNNによる時系列予測（NeuralProphet、DeepAR等）や表形式データ用のTabTransformerなど、伝統的な機械学習からの応用領域までカバーします。

PyTorchが対応する領域は広く、AIワークロードのフレームワーク選定では有力な第一候補になります。既存TF/JAX資産の保守や特定プラットフォームの最適化を狙う場合には、他の選択肢が適するケースもあります。

エッジデバイス・組込み向け（ExecuTorch）

2025年以降本格化し、2026年4月にPyTorch Coreへ統合されたのが、ExecuTorchによるオンデバイス推論です。

ExecuTorchはPyTorchモデルをスマートフォン・組込みボード・マイクロコントローラー上で動かすためのランタイムで、iOS・Android・Linux組込み・RTOSまで幅広くカバーします。

• スマートフォン
  Meta Ray-Banなどのウェアラブルデバイスでも実運用されています。
  
  

• 組込みボード
  Raspberry Pi・Jetson・NPU搭載SoCなどでの推論に対応。
  
  

• マイクロコントローラー
  2026年のPyTorch Conference Europeでは、ExecuTorch on Microcontrollersというセッションが行われ、MCU上でのPyTorchモデル実行まで視野に入っています。
  
  公式資料によるとExecuTorchのコアランタイムは約50KBまで小さくでき、Selective BuildやEmbedded Platformsの解説にあるとおり、実行時に必要な総RAM・フラッシュ容量はモデル・カーネル構成・delegate選択で変わります。

クラウドでの学習からデバイス上での推論まで、PyTorchのエコシステム内で一気通貫に組めるようになった点は、ここ2年で最も大きな変化のひとつです。

PyTorchのインストールと環境構築

PyTorchのインストールは、公式サイトのGet Startedページで自分の環境に合ったコマンドを生成し、それを実行するのが基本です。

現行の公式Get Startedページはpipインストールを案内しており、conda公式チャンネルは既に非推奨（deprecation of conda nightly builds）となっています。

本セクションでは、まず現行の2.13を pip で導入する方法を示し、そのあとで参考として旧2.5系（Python 3.9・conda）の画面例を掲載します。画面例は仮想環境の作成〜インストール〜MNIST実装の流れを視覚的に確認する参考としてください。

現行の2.13インストール手順

Python 3.10〜3.14をインストールした環境で、公式Get StartedページからOSとCompute Platformを選ぶと、環境に合ったコマンドが生成されます。参考として代表的なコマンド例を挙げます。

# 明示的にCPU版を指定（LinuxではデフォルトがCUDA 13.0版になるため注意）
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cpu

# CUDA 13.0対応GPU版（Linux / Windows）
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu130

2.11以降のLinuxではpip既定がCUDA版wheelに切り替わっているため、CPU版を導入したい場合は「--index-url .../whl/cpu」の明示指定が必要です。macOSではCUDA／ROCm版ではなく、MPSバックエンドを含む通常のmacOS向けwheelを利用します。OS・CUDA世代の組み合わせが最終的に正しいかは、必ずGet Startedページの生成結果で確認してください。

本記事での推奨・検証環境

以下は本記事のハンズオンを進めるうえでの推奨・検証環境です。

PyTorch 2.13の公式wheelはWindows 10以降・macOS 11以降・Linuxはmanylinux_2_28配布（glibc 2.28以降）に対応しており、より古いOSでも動作するケースはありますが、実務ワークロードを回すなら以下のラインを目安にすると詰まりにくくなります。

NVIDIA GPUを使う場合、「nvidia-smi」で表示される「CUDA Version」はドライバが対応する最大CUDAバージョンであり、ローカルにインストール済みのCUDA Toolkitとは別物です。

pip wheelはCUDAランタイムを同梱するため、GPUドライバ側で選択したwheelのCUDA要件を満たしていれば動作します。

Blackwell世代GPUを使うなら、Linuxで580.65.06以降、Windowsで580.88以降のNVIDIAドライバを事前に用意しておきます。

【参考】旧2.5系の画面例

以下のスクリーンショットはPyTorch 2.5.1／Python 3.9／Anaconda公式チャンネルを使用した旧手順の画面例です。conda公式チャンネルは既に非推奨のため、2.13を新規導入する場合は前述のpipコマンドを使ってください。

ここでは仮想環境の作成〜インストール〜MNIST実行の一連の流れを視覚的に把握する参考として掲載しています。

まず、Anacondaプロンプト（Windows）で以下のコマンドを打つと、「pytorch_test」という名前のPython 3.9仮想環境を作成できます。

conda create -n pytorch_test python=3.9

コマンドを実行すると、インストール予定のパッケージ一覧と確認プロンプトが表示されます。

「y」と入力してEnterを押すと、パッケージのダウンロードとインストールが始まります。

作成が完了したら、以下のコマンドで仮想環境を有効化します。

conda activate pytorch_test

プロンプトの先頭が「(pytorch_test)」に変わっていれば、この後のインストール作業はすべてこの仮想環境内で行われます。

旧2.5系のインストール手順

旧2.5系・conda環境ではPyTorch公式チャンネルからCPU版を導入していました。以下は当時のインストールコマンドです。

conda install pytorch torchvision torchaudio cpuonly -c pytorch

実行すると、torch本体・torchvision（画像処理）・torchaudio（音声処理）と、依存する数百MB分のパッケージがダウンロードされます。

ネットワーク環境にもよりますが、数分〜十数分ほどでインストールが完了します。

グラフ描画で使うmatplotlibもあわせて入れておくと、この後のMNIST実装でそのまま使えます。

pip install matplotlib

これで最小構成のPyTorch開発環境が整いました。

インストール確認とGPU認識のチェック

インストールが完了したら、Pythonを起動して以下のコマンドでバージョンとGPU認識を確認します。

import torch

print(torch.__version__)          # インストールしたバージョンが出力される
print(torch.cuda.is_available())  # GPU版導入時はTrue、CPU版はFalse

GPU版を導入したのに「torch.cuda.is_available()」が「False」を返す場合、GPUドライバとwheelバージョンの不整合はまず確認すべき原因の一つです。

他にもCPU版wheelを誤って導入していた、GPUが対応世代でない、Docker/コンテナ環境でGPUが割り当たっていない、といったケースが考えられます。

「nvidia-smi」でドライバが対応するCUDAバージョンを確認したうえで、それに合った公式wheel（例：CUDA 12.6版）を選び直すのが最短の解決策になる場面が多くなります。

PyTorchの基本操作——テンソルと自動微分

PyTorchで扱うデータの最小単位は「テンソル」で、勾配計算は「自動微分（autograd）」が担います。

本セクションでは、この2つの基本要素を最短で押さえます。

torch.Tensorの作成と基本演算

テンソルは多次元配列のことで、NumPyのndarrayとほぼ同じ感覚で扱えます。

以下は代表的なテンソル生成の例です。

import torch

# ゼロで初期化した 3x3 テンソル
zeros = torch.zeros(3, 3)

# 標準正規分布からランダムに 2x3 テンソル
rand = torch.randn(2, 3)

# 0から10まで、2刻みで並ぶ1次元テンソル
arange = torch.arange(0, 10, 2)

print(zeros, rand, arange)

「torch.zeros」は指定した形状のゼロテンソル、「torch.randn」は標準正規分布から生成されたランダム値のテンソル、「torch.arange」は指定した範囲・刻み幅で並ぶ1次元テンソルを返します。

NumPyの「np.zeros」「np.random.randn」「np.arange」と対応しており、NumPy経験者であれば短時間でキャッチアップできます。

GPUに転送するのは「x.to("cuda")」の1行で完結し、勾配計算のためのメタデータ（「requires_grad」）を持てる点もNumPyにはない機能です。

テンソルの形状変換API

モデルの前処理では、次元の並べ替えや形状変換を多用します。

代表的な形状操作は「reshape」「view」「permute」の3つです。以下は「(2, 3)」のテンソルから、それぞれのAPIを呼び出したときの挙動を確認する例です。

import torch

x = torch.randn(2, 3)

# reshape：可能ならviewを返し、不可能なときだけコピーして形状を変える
y = x.reshape(3, 2)

# view：メモリレイアウトを変えずに次元を追加（連続でないと失敗）
y2 = x.view(1, 2, 3)

# permute：軸の順序を指定する（引数がそのままの場合は形状は変わらない）
z = x.permute(0, 1)

print(y.shape, y2.shape, z.shape)

出力は「torch.Size([3, 2]) torch.Size([1, 2, 3]) torch.Size([2, 3])」となります。「reshape」は要素の総数を保ったまま「(2, 3)」から「(3, 2)」へ形状を変更し、「view」は次元を1つ追加して「(1, 2, 3)」にし、「permute(0, 1)」は軸の順序を元のまま指定しているので形状は「(2, 3)」のまま変わりません。

軸を実際に入れ替えたい場合は「permute(1, 0)」のように別の順序を渡します。「view」は入力が連続領域である必要があるため、「permute」で軸を入れ替えた直後は「contiguous()」を挟むのが定石です。

画像を扱うときは「(N, C, H, W)」と「(N, H, W, C)」を行き来する場面が多く、「permute」と「reshape/view」の使い分けを覚えると詰まりにくくなります。

自動微分（autograd）

PyTorchの学習ロジックの中核は、テンソルに「requires_grad=True」を指定するだけで勾配計算が自動化される点にあります。

以下は自動微分の最小例です。

import torch

x = torch.tensor([2.0, 3.0], requires_grad=True)
y = (x ** 2).sum()   # y = x1^2 + x2^2

y.backward()          # dy/dx を自動計算
print(x.grad)         # -> tensor([4., 6.])

「y.backward()」を呼ぶだけで、計算グラフを遡って各入力に対する勾配（この場合「2x」）が自動で求まります。

ニューラルネットワーク学習では、この「backward()」とオプティマイザ（SGD、Adam等）の「step()」をループするだけで、任意の複雑なモデルの学習が回せます。

「勾配を手で計算しなくてよい」という体験こそが、PyTorchが研究フェーズで支持される最大の理由です。

PyTorchでMNIST画像分類モデルを実装する

ここまでの基礎を踏まえ、MNISTデータセットを使った画像分類モデルを実装します。

MNIST（Modified NIST）は、0〜9の手書き数字画像60,000枚（訓練）+10,000枚（テスト）からなる、深層学習の入門データセットです

。CPU環境でも実行可能で、コードの構造理解に集中できるため、PyTorch入門の題材として最適です。

実装ファイルの全体構成

今回は以下の4ファイル構成で実装します。

• 「mnist_utils.py」: モデル定義・データローダのユーティリティ関数
• 「mnist_example.py」: 学習を実行するメインスクリプト
• 「mnist_accuracy.py」: 学習済みモデルの精度評価スクリプト
• 「data/」: MNISTデータセットの保存先（自動生成）

単一ファイルにまとめてもよいのですが、モデル定義と実行スクリプトを分けておくと、後で推論・再学習・別データセットへの流用が容易になります。

データ読み込みとモデル定義

まず、MNISTのデータローダとCNNモデル定義をまとめたユーティリティを作ります。

# mnist_utils.py
import torch
import torch.nn as nn
import torch.nn.functional as F
from torchvision import datasets, transforms
from torch.utils.data import DataLoader


def get_dataloaders(batch_size=128, data_dir="./data"):
    """MNISTの学習/テスト用DataLoaderを返す"""
    transform = transforms.Compose([
        transforms.ToTensor(),
        transforms.Normalize((0.1307,), (0.3081,)),  # MNIST平均・標準偏差
    ])
    train_set = datasets.MNIST(data_dir, train=True, download=True, transform=transform)
    test_set = datasets.MNIST(data_dir, train=False, download=True, transform=transform)
    train_loader = DataLoader(train_set, batch_size=batch_size, shuffle=True)
    test_loader = DataLoader(test_set, batch_size=batch_size, shuffle=False)
    return train_loader, test_loader


class SimpleCNN(nn.Module):
    """MNIST用のシンプルなCNN"""
    def __init__(self):
        super().__init__()
        self.conv1 = nn.Conv2d(1, 32, kernel_size=3, padding=1)
        self.conv2 = nn.Conv2d(32, 64, kernel_size=3, padding=1)
        self.pool = nn.MaxPool2d(2)
        self.fc1 = nn.Linear(64 * 7 * 7, 128)
        self.fc2 = nn.Linear(128, 10)

    def forward(self, x):
        x = self.pool(F.relu(self.conv1(x)))  # 28 -> 14
        x = self.pool(F.relu(self.conv2(x)))  # 14 -> 7
        x = x.view(x.size(0), -1)
        x = F.relu(self.fc1(x))
        return self.fc2(x)

「transforms.Normalize」に指定した「0.1307」と「0.3081」はMNIST画像の画素値の平均と標準偏差で、この標準化を入れると学習が安定します。

CNN側は、畳み込み層2つとプーリング層で特徴抽出、全結合層2つで10クラス分類する最小構成です。パラメータ数は少ないですが、MNISTなら十分実用的な精度に届きます。

学習スクリプト（mnist_example.py）

次に、学習を実行するメインスクリプトです。今回は5エポック学習し、学習後のモデルを「mnist_simplecnn.pth」という名前で保存します。

# mnist_example.py
import os
import torch
import torch.nn as nn
import torch.optim as optim
from mnist_utils import get_dataloaders, SimpleCNN


def main():
    device = "cuda" if torch.cuda.is_available() else "cpu"
    model_path = "mnist_simplecnn.pth"

    train_loader, _ = get_dataloaders(batch_size=128)
    model = SimpleCNN().to(device)

    if os.path.exists(model_path):
        model.load_state_dict(torch.load(model_path, map_location=device))
        print(f"Loaded existing model from {model_path}")
    else:
        print("No saved model found. Training the model...")
        criterion = nn.CrossEntropyLoss()
        optimizer = optim.Adam(model.parameters(), lr=1e-3)

        epochs = 5
        for epoch in range(1, epochs + 1):
            model.train()
            running_loss = 0.0
            for images, labels in train_loader:
                images = images.to(device)
                labels = labels.to(device)

                optimizer.zero_grad()
                outputs = model(images)
                loss = criterion(outputs, labels)
                loss.backward()
                optimizer.step()

                running_loss += loss.item() * images.size(0)

            avg_loss = running_loss / len(train_loader.dataset)
            print(f"Epoch {epoch}/{epochs}, Loss: {avg_loss}")

        torch.save(model.state_dict(), model_path)
        print(f"Model saved to {model_path}")


if __name__ == "__main__":
    main()

PyTorchの学習ループは、勾配ゼロ化→フォワード→損失計算→バックワード→オプティマイザ更新の5ステップの繰り返しで書けます。

「学習ロジックの構造を1画面で把握できる」ことが、PyTorchが教材として選ばれる大きな理由です。

保存済みモデルがある場合はロードして学習をスキップする分岐を入れておくと、後で精度評価スクリプトから使い回しやすくなります。

精度評価スクリプトの作成

学習と評価をまとめて回せるよう、モデルが未保存なら学習してから評価する統合スクリプトを作ります。

# mnist_accuracy.py
import os
import torch
import torch.nn as nn
import torch.optim as optim
from mnist_utils import get_dataloaders, SimpleCNN


def train_if_needed(model, train_loader, device, model_path):
    if os.path.exists(model_path):
        model.load_state_dict(torch.load(model_path, map_location=device))
        return
    print("No saved model found. Training the model...")
    criterion = nn.CrossEntropyLoss()
    optimizer = optim.Adam(model.parameters(), lr=1e-3)
    epochs = 5
    for epoch in range(1, epochs + 1):
        model.train()
        running_loss = 0.0
        for images, labels in train_loader:
            images = images.to(device)
            labels = labels.to(device)
            optimizer.zero_grad()
            outputs = model(images)
            loss = criterion(outputs, labels)
            loss.backward()
            optimizer.step()
            running_loss += loss.item() * images.size(0)
        avg_loss = running_loss / len(train_loader.dataset)
        print(f"Epoch {epoch}/{epochs}, Loss: {avg_loss}")
    torch.save(model.state_dict(), model_path)
    print(f"Model saved to {model_path}")


def main():
    device = "cuda" if torch.cuda.is_available() else "cpu"
    model_path = "mnist_simplecnn.pth"

    train_loader, test_loader = get_dataloaders(batch_size=128)
    model = SimpleCNN().to(device)
    train_if_needed(model, train_loader, device, model_path)
    model.eval()

    correct = 0
    total = 0
    class_correct = [0] * 10
    class_total = [0] * 10

    with torch.no_grad():
        for images, labels in test_loader:
            images = images.to(device)
            labels = labels.to(device)
            outputs = model(images)
            _, predicted = outputs.max(1)

            correct += (predicted == labels).sum().item()
            total += labels.size(0)

            for i in range(labels.size(0)):
                label = labels[i].item()
                class_total[label] += 1
                if predicted[i].item() == label:
                    class_correct[label] += 1

    overall = correct / total
    print(f"Overall Accuracy: {overall * 100:.2f}%")
    print("Class-wise Accuracy:")
    for i in range(10):
        acc = class_correct[i] / class_total[i]
        print(f"Class {i}: {acc * 100:.2f}%")


if __name__ == "__main__":
    main()

ポイントは、「train_if_needed」の分岐と、「model.eval()」＋「with torch.no_grad():」のペアです。分岐によってモデルが未保存なら学習→保存→評価が一気通貫で走り、既にあれば読み込んですぐ評価に入ります。

後半の推論定型は、「model.eval()」でドロップアウトやバッチ正規化を推論モードに切り替え、「torch.no_grad()」で勾配計算を止めてメモリ・速度を最適化します。

学習実行とデータセットの自動ダウンロード

作成したスクリプトを、以下のコマンドで実行します。

python mnist_accuracy.py

初回実行時は、「data/」ディレクトリが自動で作成され、MNISTデータセット（約12MB）がダウンロードされます。「yann.lecun.com」のオリジナルURLは403応答になることがあり、その場合は自動で「ossci-datasets.s3.amazonaws.com」のミラーにフォールバックしてダウンロードが継続します。

ダウンロード後は保存済みモデルがないため学習が始まり、各エポックごとに損失値が表示されます。5エポックの学習では、Lossが約0.22から約0.03へと順調に下がっていきます。

学習が完了すると、「mnist_simplecnn.pth」ファイルが保存されます。

実行時間はCPU/GPUの型番・OS・バッチサイズなどの環境条件で大きく変わります。手元で5エポックの学習が数分〜十数分で終わる程度なら想定通りと考えて問題ありません。

精度チェックの実行結果

学習が終わると、続けて評価フェーズが走り、テスト精度が出力されます。

今回のシンプルなCNN構成でも、テスト全体の精度は**97.79%**に到達しました。クラス別に見ると、Class 1が最も高く99.30%、Class 9が最も低く95.04%で、数字の形状の紛らわしさ（7と9、4と9など）が精度差として現れています。

MNISTはデータセットとしては簡単な部類ですが、「PyTorchで書いたコードが、動的計算グラフ→自動微分→勾配更新→評価まで一気通貫で動く」という一連の流れを体感するには最適な題材です。

実装で詰まりやすい3つの落とし穴

MNISTのような入門題材でも、初めてPyTorchを触ると詰まりやすい箇所があります。実務でハマる前に押さえておきたいポイントを整理します。

• 入力テンソルの形状ミス
  Convolutionレイヤーは「(N, C, H, W)」の4次元テンソルを期待するのに対し、生の画像データは「(H, W)」や「(H, W, C)」である場合があります。
  
  「unsqueeze(0)」や「permute」で形を揃えるステップを忘れると「shape mismatch」エラーが出ます。
  
  

• 「optimizer.zero_grad()」の呼び忘れ
  PyTorchは勾配を累積する設計のため、ループの各イテレーションで明示的にゼロクリアが必要です。
  
  忘れると前ステップの勾配が加算されたまま更新が走り、意図しないパラメータ変化や損失の発散につながります。
  
  

• train/evalモードの切り替え忘れ
  学習中は「model.train()」、評価・推論時は「model.eval()」を呼ぶのが定型です。
  今回掲載した「SimpleCNN」にはDropoutやBatchNormが含まれないので実挙動には影響しませんが、これらを含む実務モデルでは切り替えを忘れると評価値が不安定になります。

この3つは新規実装でつまずきやすいポイントです。エラーメッセージや精度の異常が出たら、この3点を最初に疑うのが早道です。

本番運用に向けた高度な機能——torch.compile・FSDP2・ExecuTorch

MNISTのような入門例から一歩踏み出し、実際のサービスや大規模モデルに載せる段階で使う機能を整理します。

torch.compileによる学習・推論の高速化

torch.compileは、PyTorch 2.0で登場した「モデルを1行のデコレータで最適化するAPI」です。

内部ではTorchDynamo（Pythonバイトコードを追跡してグラフ化）とTorchInductor（Triton / C++カーネルを生成）が動き、動的計算グラフのままJITコンパイルとカーネル融合を適用します。

import torch

model = SimpleCNN().to("cuda")
compiled_model = torch.compile(model)   # これだけ

# 以降のforward/backwardは自動で最適化される
outputs = compiled_model(images)

2.11以降で安定性が向上し、Transformer系モデルでの高速化事例が多く報告されています。
実際の速度改善はモデル構造・GPU世代・バッチサイズによって大きく変わるため、自社ワークロードで計測してから採用可否を判断するのが安全です。

「1行足すだけ」で試せる割にリスクが低いため、新規実装では最初から「torch.compile()」を挟んで計測する運用が増えつつあります。

FSDP2による大規模モデルの分散学習

FSDP2（Fully Sharded Data Parallel v2）は、モデルパラメータ・勾配・オプティマイザ状態を複数GPUに分散配置しつつデータ並列で学習する方式です。

• 100億パラメータ超のモデルでも複数GPUに分割して学習できる
• モデル重み・勾配・オプティマイザ状態を段階的にGPU間で共有する
• torch.compileと併用可能（ただしFSDP2フック周辺のgraph breakや適用順に注意）

FSDP2はPyTorch 2.4で導入された、DTensorベースの新しいFSDP実装です。以降のバージョンで機能追加が続いており、PyTorch 2.13ではreduce-scatterとall-gatherを専用通信グループで重ねて実行するオプションが加わりました。

torch.compileとの組み合わせについては、「fullgraph=False」にするか「fully_shard」適用前に「torch.compile」するといった実装上の順序に留意が必要で、graph breakなしのフルコンパイルは限定的です。

数十Bクラス以上のLLMをスクラッチ学習・SFT・DPO調整するチームなら、まず候補にすべき機能です。

ExecuTorchによるオンデバイス展開

前述したように、ExecuTorchはPyTorchモデルをスマートフォン・組込み・マイクロコントローラーで動かすためのランタイムで、2026年4月にPyTorch Coreへ統合されました。

サーバ推論と同じPyTorchモデルを、「torch.export」で保存 → ExecuTorch形式に変換 → デバイス上のC++ランタイムから呼び出す、という一貫パイプラインで扱えます。

• iOS・Android: Swift/Kotlinから呼び出すサンプル多数
• Linux組込み: Raspberry Pi / Jetson等でCPU/NPU推論
• RTOS・MCU: コアランタイム約50KBの軽量構成でMCUにも対応（実行時の総メモリはモデル・delegate構成に依存）

Meta Ray-Banをはじめとするウェアラブルでも実運用されており、「クラウド学習→エッジ推論」を単一エコシステムで組める体制がPyTorch内で完成しつつあります。

torch.exportへの移行手順

先述の通り、TorchScriptは2.10で非推奨となり、2.12以降も非推奨のまま提供が続いています。既存TorchScript資産を持っているチームは、以下の順で移行を検討します。

1. 「torch.jit.trace」利用箇所を「torch.export」に置き換える
   「torch.export」は動的形状もサポートしており、新規パイプラインを構築する際に有力な選択肢です。
   
   

2. LibTorch経由の組込みランタイムをExecuTorchに切り替える
   モバイル・組込みで「.pt」ファイルを直接ロードしていた箇所は、ExecuTorch形式（「.pte」）に変換したうえでExecuTorchランタイムから呼び出す構成に置き換えます。
   
   

3. 保存フォーマットとバージョン互換を再確認
   移行後は、モデル保存フォーマット（.pt2 / .pte）とPyTorchバージョンの依存関係を明確にドキュメント化しておくと、後の本番運用時にブロッキング要因が減ります。

現行版では即座に動かなくなるわけではないため急ぐ必要はありませんが、長期運用中の本番システムは非推奨化ロードマップと照らしながら段階的に移行計画を立てるのが安全です。

PyTorch vs TensorFlow vs JAX——フレームワーク選定の軸

深層学習フレームワークの主要な選択肢としては、PyTorch・TensorFlow・JAXの3つが挙げられます。

本セクションでは、この3者の位置づけとケース別の選び方を整理します。

3フレームワークの位置づけ比較

3者の設計思想と得意領域を、以下の表に整理しました。

設計思想の違いはあるものの、日常業務での判断は「エコシステムの厚み」と「既存資産」で決まる傾向があります。

新規案件ではPyTorchが有力な第一候補になりやすく、既存TF/JAX資産を持つチームや特定プラットフォーム最適化を狙う場合には他の選択肢を検討する、というのが実務での基本線です。

市場感の違い（フローとストック）

2026年時点の実務観察を踏まえると、大まかに次のような傾向が読み取れます。

• 研究フェーズ・新規プロジェクト・生成AI関連の新規実装ではPyTorchが第一候補として選ばれる場面が多い
• 一方で、既存のエンタープライズ本番システムではTensorFlowで組まれた資産の運用が引き続き見られる
• 新規実装のドキュメント・OSSライブラリはPyTorchベースのものが多く整備されている

個別の%比較は調査主体・集計期間・母集団の取り方で幅が出るため、断定的な数値比較は避け、「フロー（新規案件）はPyTorch優位、ストック（既存本番）はTensorFlow資産が厚い」という定性的な構図で押さえておくのが安全です。

「これから新しく作る」ならPyTorchが有力な第一候補、「すでに動いているものを保守する」ならフレームワーク変更のコストと便益を天秤にかける、というのが実務での基本線です。

ケース別の選び方

支援経験を踏まえた、ケース別の使い分けを整理します。

• 新規で深層学習・生成AIを立ち上げる → PyTorchが有力な第一候補
  論文・OSS実装がPyTorchで揃っており、Hugging Face Transformersを軸に組み立てるのが最短ルート。特にLLMのファインチューニングや評価パイプラインは、実質PyTorch前提で情報が整備されています。
  
  

• 既存TensorFlow資産があり、追加開発が保守レベル → TensorFlowを継続
  Keras 3 API・TF Serving・LiteRT（旧TensorFlow Lite）で完結する既存パイプラインを、PyTorchに書き直すコストは大きい割にROIが読みにくい領域。無理な移行より、保守と局所改善に注力するのが現実的です。
  
  

• モバイル・ブラウザ推論を最優先 → LiteRT（旧TensorFlow Lite）／TensorFlow.jsが依然強い
  ExecuTorchが伸びていますが、LiteRTは長年のノウハウ蓄積があり、既存のSoC最適化・アプリ統合サンプルが豊富。iOS/Android両対応の実装量では、まだTF系の資産が厚い状況です。
  
  

• TPUやJAX/XLA資産を活用する → JAXも候補
  JAXは公式にTPU・NVIDIA GPU・AMD GPU・CPUをサポートしており、「jax.export」／StableHLOによるデプロイ経路も整備されています。
  
  Google Cloud TPU上のスケール学習やJAX/XLAで組まれた既存資産を活かす場合には有力な選択肢です。エコシステムの厚みや情報量ではPyTorchのほうが幅広いため、選定は「既存のJAX/XLA資産がある」「TPUで最大効率を出したい」といった具体的な文脈に沿って判断します。

選定は、プロジェクトの既存資産・対象ハードウェア・運用体制・チームのスキルセットといった条件に応じて判断します。

新規案件でこれらの制約が少ない場合はPyTorchから検討を始めるチームが多く、逆に既存資産や特定プラットフォーム最適化を狙う場合には他の選択肢が適するケースもあります。

PyTorch学習・推論のGPUコスト相場

PyTorch自体は完全なオープンソース（BSDライセンス）で、ライセンス料はかかりません。実務上の主要コストは、GPU計算リソースです。

本セクションでは、2026年7月時点のGPUコスト相場と、コスト最適化の打ち手を整理します。

主要クラウドのGPU料金比較

代表的なクラウドGPUインスタンスの2026年7月時点の目安価格を、以下の表に整理しました。実際の請求はリージョン・OS・契約タイプ・SKUで変動するため、契約前に必ず公式pricingページで最新値を確認してください。

2026年7月時点の公表値。AWSはAWS Price List Bulk API、AzureはRetail Prices API、GCPはGoogle Cloud公式料金、Lambda LabsはGPU Instancesより抽出。より大規模な16GPU以上のクラスタ利用には1-Click Clusters（H100は$6.16/GPU/時から）があります。

同じH100 8GPU構成でも、AWS・GCP・Azureの間には時間単価で最大$40前後の開きがあり、さらにLambda Labs等のGPU特化クラウドは3社より低い水準で提供されるケースが見られます。

ただしSLA・サポート・エンタープライズ契約の使い勝手・データ転送料などの周辺コストを含めると、単純な時間単価比較だけでは決められないのが実務の判断ポイントです。

コスト最適化の3つの打ち手

同じPyTorch学習でも、以下の3つを組み合わせるだけでコストは大きく変わります。

• スポットインスタンス活用
  AWS EC2 Spot Instances・Google Cloud Spot VMs・Azure Spot Virtual Machinesを使うと、オンデマンドより低い料金でGPUを利用できる場合があります。
  
  中断リスクがあるため、チェックポイントを頻繁に保存する設計とセットで運用します。
  
  

• 「torch.compile」＋Mixed Precision Training
  2.11以降のtorch.compileと、torch.amp（旧「torch.cuda.amp」は非推奨）によるFP16/BF16混合精度学習を組み合わせると、モデルによっては学習時間の短縮が期待できます。
  
  実際の効果はモデル・GPU・バッチサイズ次第なので、自社ワークロードで前後比較して判断します。
  
  

• 推論はvLLM・TensorRT-LLM・ExecuTorch等の推論エンジンで最適化
  学習と推論を同じPyTorchランタイムで動かすのは、コストと速度の両面で最適解ではないケースが多いです。
  
  推論はvLLM（LLM向け）・TensorRT-LLM（NVIDIA最適化）・ExecuTorch（エッジ）などに置き換えて、専用エンジンの高速化と省GPU化を狙います。

特にLLM推論では、vLLMやTensorRT-LLMへの置き換えでスループットが大きく改善する事例が多く報告されています。学習と推論のスタックを別物として設計する構成は、2026年の実務でも広く採用されているアプローチです。

自社運用 vs クラウド利用の判断軸

自社GPUを購入するかクラウドを使うかは、以下の観点で判断します。

• 利用時間: 短期・スポット利用ならクラウド従量課金、長期・高稼働率なら自社購入 or リザーブド契約
• 学習頻度: 不定期・研究フェーズはクラウドのスポット活用と相性がよい
• 推論SLA: 常時稼働・低レイテンシー要件がある場合はクラウドのリザーブド or 自社推論サーバ

GPU本体の初期投資に加え、電力・冷却・ネットワーク・保守・残価まで含めた3年TCOで見ないと自社購入とクラウドの損益分岐は正確に出せません。

「月間何時間ならクラウド」といった単純な閾値ではなく、GPU枚数・稼働率・電力単価・データセンター条件を自社の実数値で試算するのが実務目線での正解です。

PyTorchで組んだモデルを業務Agentに橋渡しするなら

PyTorchでモデルを組めるようになったあと、多くのチームが詰まるのが「学習パイプラインは動くのに業務ワークフローに繋がらない」「運用統制が取れない」「部門横断で使う仕組みにならない」という段階です。モデル選定・学習コード以外の、業務Agent実行層・権限・監査の設計を並行で整える必要があります。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。

AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化Agent群を1つのダッシュボードで統合管理し、PyTorchで組んだモデルを業務プロセスに載せる運用基盤として機能します。

• 学習=PyTorch/推論=vLLM/業務接続=Agentの分業を吸収
  記事で扱った学習と推論のスタック分離を、業務Agent層と組み合わせて設計。モデル・推論エンジン・業務ワークフローの3層を疎結合に運用できます。
  
  
• モデル世代交代を吸収する管理層
  PyTorch製カスタムモデルもClaude/GPT/Geminiなどのマネージドモデルも、業務Agent側の設計は変えずに切り替え可能。研究フェーズと本番運用フェーズの分岐設計を支援します。
  
  
• Agent単位で権限・実行ログ・セキュリティを1画面統制
  Agentごとにアクセス範囲を設計。誰がどのAgentでどのモデルを呼び出したかを不変ログで残せます。
  
  
• データは100%自社Azureテナント内に保持
  学習データ・推論データはAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、PyTorchでのモデル開発から業務Agent基盤の統合設計まで一貫して支援します。AI Agent Hubのサービスページで、PyTorchモデルを業務に載せる実装例をご確認ください。

PyTorchモデルを業務Agentへ橋渡し

モデル本番運用と業務接続を1画面で

PyTorchで作ったモデルを社内業務に組み込むには、推論の運用体制・業務ワークフロー接続・ガバナンス設計まで幅広い論点が絡みます。AI Agent Hubは業務特化Agent群を1つのダッシュボードで統合管理し、PyTorchモデルを業務プロセスに載せる運用基盤として機能します。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、PyTorchについて、2.13までの主要アップデート・特徴と機能・環境構築・MNIST実装・本番運用の高度機能・TensorFlow/JAXとの比較・GPU学習コスト相場までを、2026年7月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• PyTorchはMeta発・PyTorch Foundation運営の動的計算グラフ型フレームワークで、研究論文・LLM実装・生成AIのデファクトとして広く使われている
• 2.12〜2.13でMX量子化・torch.cond CUDA Graphs・FlexAttention・Python 3.15プレビュー対応など研究〜本番運用が拡張、TorchScriptは非推奨継続でtorch.export+ExecuTorchが推奨ルート
• TensorFlowは既存本番資産・LiteRT系モバイル推論で強く、新規の深層学習・LLM実装ではPyTorchが有力な第一候補という使い分けが実務で見られる
  
  

まずはMNIST写経で動的グラフの体験値を積み、自社の課題に応用しながらtorch.compile・FSDP2・ExecuTorchへと段階的に触れていくのが、無理のない習得ステップになります。新規案件・研究フェーズならPyTorchで組み始めるのが有力な選択肢で、後から後戻りするコストも比較的抑えやすい構成です。