簡潔に言うと、 AIの前処理とは、生の高分散データを、クリーニング、エンコード、スケーリング、トークン化、画像変換などを含む、一貫性のあるモデル入力に変換する一連の反復可能な手順のことです。トレーニング入力と本番入力が異なると、モデルがエラーを隠蔽してしまう可能性があるため、前処理は重要です。手順でパラメータを「学習」する場合は、リークを防ぐためにトレーニングデータのみで適合させてください。
AIの前処理とは、モデルが実際に学習できるように、学習や推論の前（場合によっては学習中）に生データに対して行うすべての作業です。単なる「クリーニング」ではありません。データのクリーニング、整形、スケーリング、エンコード、拡張、そして後でモデルに悪影響を与えない一貫した表現へのパッケージ化まで、データの処理が含まれます。[1]
重要なポイント:
定義: 前処理では、生のテーブル、テキスト、画像、ログをモデル対応の機能に変換します。
一貫性: 不一致の障害を防ぐために、トレーニングと推論中に同じ変換を適用します。
Leakage: スケーラー、エンコーダー、トークナイザーをトレーニング データのみに適合させます。
再現性: アドホックなノートブック セル シーケンスではなく、検査可能な統計を使用してパイプラインを構築します。
生産状況の監視：入力データの偏りや変動を追跡し、徐々にパフォーマンスが低下しないようにする。
この記事の次に読むとよい記事:
🔗 AIモデルの実世界パフォーマンスをテストする方法
精度、堅牢性、バイアスを迅速に評価するための実用的な方法。.
🔗 テキスト読み上げAIとは何か？どのように機能するのか？
TTS の基本、主な用途、および現在の一般的な制限について説明します。.
🔗 AIは今日、筆記体を正確に読み取ることができるか
認識の課題、最適なツール、正確さのヒントについて説明します。.
🔗 一般的なタスクにおけるAIの精度はどの程度か
精度要因、ベンチマーク、実際の信頼性について詳しく説明します。.
平易な言葉で説明する AI 前処理（そしてそれが何ではないのか）🤝
AIの前処理 とは、生の入力データ（表、テキスト、画像、ログ）をモデル化可能な特徴量に変換することです。生データが散らかったガレージだとすると、前処理とは、箱にラベルを貼り、壊れたガラクタを捨て、実際に歩いて怪我をすることなく通り抜けられるように物を積み重ねることです。
モデルそのものではありません。モデルを可能にする要素です。
-
カテゴリを数値に変換する（one-hot、順序数など）[1]
-
大きな数値範囲を適切な範囲にスケーリングする（標準化、最小最大など）[1]
-
テキストを入力ID（通常はアテンションマスク）にトークン化する [3]
-
画像のサイズ変更/切り取りと決定論的変換とランダム変換の適切な適用 [4]
-
訓練と「現実の」入力が微妙に乖離しないように、繰り返し可能なパイプラインを構築する[2]
ちょっとした実用的な注意点：「前処理」とは、 モデルが入力データを見る前に一貫して行われるすべての処理。一部のチームではこれを「特徴量エンジニアリング」と「データクリーニング」に分けていますが、実際にはその境界線は曖昧です。
AI の前処理が人々が認める以上に重要な理由😬
モデルはパターンマッチングを行うものであり、心を読むものではありません。入力に矛盾があれば、モデルは矛盾したルールを学習します。これは哲学的な話ではなく、文字通りの意味です。.
前処理は次のことに役立ちます:
-
特徴量を推定器が確実に使用できる表現にすることで学習の安定性を向上させる（特にスケーリング/エンコードが関係する場合）。[1]
-
雑然とした現実を、モデルが一般化できるもののように見せることで（奇妙なアーティファクトを記憶するのではなく）、ノイズを削減します。
-
リークやトレーニング/サービングのミスマッチ（検証では「素晴らしい」ように見えても、本番環境では大失敗に終わるようなもの）といった、サイレントな障害モードを防止します。[2]
-
繰り返し可能な変換はノートブックのスパゲッティよりも優れているため、反復処理が高速化されます。
それに、実は「モデルのパフォーマンス」の多くはここから生まれているんです。というか…驚くほどたくさん。時々不公平に感じることもありますが、それが現実なんです🙃
優れた AI 前処理パイプラインの条件 ✅
前処理の「優れたバージョン」には通常、次のような特性があります。
-
再現性：同じ入力→同じ出力（意図的な増加でない限り、不可解なランダム性は存在しない）。
-
訓練とサービングの一貫性：訓練時に行うことはすべて推論時に同じように適用されます（同じ適合パラメータ、同じカテゴリマップ、同じトークナイザー設定など）。[2]
-
リークセーフ：評価/テストにおいて、いかなる
適合ステップも影響を受けません。（この罠については後ほど詳しく説明します。）[2] -
監視可能：何が変わったか（特徴統計、欠損値、カテゴリ数）を調べることができるため、デバッグは雰囲気に頼ったエンジニアリングではなくなります。
前処理がfinal_v7_really_final_okという名前のノートブックセルの山である場合…その状況はご存知でしょう。うまくいくのですが、うまくいかなくなるまでです 😬
AI前処理のコア構成要素🧱
前処理は、パイプラインに結合する一連の構成要素と考えてください。.
1) クリーニングと検証 🧼
典型的なタスク:
-
重複を削除する
-
欠損値を処理する（欠損値を削除、補完、または明示的に表現する）
-
種類、単位、範囲を強制する
-
不正な入力を検出する
-
テキスト形式を標準化する（空白、大文字と小文字のルール、Unicode の癖）
この部分は華やかではありませんが、非常に愚かなミスを防ぐことができます。愛を込めてそう言っています。.
2) カテゴリデータのエンコード 🔤
ほとんどのモデルは「red」や「premium_user」のような生の文字列を直接使用することはできません。
一般的なアプローチ:
-
ワンホットエンコーディング （カテゴリ→バイナリ列）[1]
-
順序エンコーディング （カテゴリ → 整数ID）[1]
重要なのは、 どの エンコーダーを選ぶかではなく、マッピングがトレーニングと推論の間で一貫性を保ち、「形状が変わらない」ことです。そうでないと、オフラインでは問題なく動作するのに、オンラインでは不安定な動作をするモデルになってしまいます。[2]
3) 特徴量のスケーリングと正規化 📏
機能が大きく異なる範囲に存在する場合、スケーリングは重要になります。.
2つの古典:
-
標準化：平均を除去し、単位分散にスケールする[1]
-
最小最大スケーリング：各特徴量を指定された範囲内にスケーリングする[1]
「ほぼ対応できる」モデルを使用している場合でも、スケーリングによってパイプラインの判断が容易になり、誤って破損しにくくなることがよくあります。.
4) 特徴エンジニアリング（別名、便利なチート）🧪
ここでは、より優れた信号を作成してモデルの作業を容易にします。
-
比率（クリック数 / インプレッション数）
-
ローリングウィンドウ（過去N日間）
-
カウント（ユーザーあたりのイベント数）
-
重裾分布の対数変換
ここに芸術があります。機能を作って、誇りに思うこともあるでしょう…でも、それが何も生まないこともあります。あるいはもっとひどい場合は、傷つくこともあります。それは普通のことです。機能に感情的に執着してはいけません。機能から愛されることはありませんから。😅
5) データを正しく分割する✂️
これは明白なことのように思えますが、そうではありません。
-
iidデータのランダム分割
-
時系列の時間ベースの分割
-
エンティティが繰り返される場合のグループ化された分割（ユーザー、デバイス、患者）
そして重要なのは、 データから学習する前処理を適合させる前に分割することです。前処理ステップでパラメータ（平均値、語彙、カテゴリマップなど）を「学習」する場合は、トレーニングデータからのみ学習する必要があります。[2]
データタイプ別の AI 前処理: 表形式、テキスト、画像 🎛️
前処理は、モデルに入力する内容に応じて形状が変化します。.
表形式のデータ（スプレッドシート、ログ、データベース）📊
一般的な手順:
-
欠損値戦略
-
カテゴリカルエンコーディング [1]
-
数値列のスケーリング [1]
-
外れ値の処理（ドメインルールはほとんどの場合「ランダムクリッピング」よりも優れています）
-
派生機能（集計、ラグ、ローリング統計）
実践的なアドバイス：列グループを明示的に定義しましょう（数値、カテゴリ、識別子）。将来の自分が感謝するでしょう。.
テキストデータ（NLP）📝
テキストの前処理には、多くの場合、次のものが含まれます。
-
トークン/サブワードへのトークン化
-
入力IDへの変換
-
パディング/切り捨て
-
バッチ処理のための注意マスクの構築[3]
苦労を省くためのちょっとしたルール：Transformerベースの設定では、モデルの想定されるトークナイザー設定に従い、特別な理由がない限りフリースタイルは避けましょう。フリースタイルは「学習はできるけど変な結果になる」という結果に繋がります。
画像（コンピュータービジョン）🖼️
一般的な前処理:
-
一貫した形状にサイズ変更/切り取り
-
評価のための決定論的変換
-
トレーニング拡張のためのランダム変換（例：ランダムクロッピング）[4]
人々が見落としがちな点があります。「ランダム変換」は単なる雰囲気ではなく、呼び出されるたびにパラメータをサンプリングするのです。多様性の訓練には最適ですが、ランダム性をオフにし忘れると評価には最悪です。[4]
誰もが陥る罠：データ漏洩 🕳️🐍
リーケージとは、評価データからの情報が、多くの場合は前処理を通じてトレーニングに紛れ込むことです。検証時にはモデルが魔法のように機能しているように見えても、実世界では期待外れになる可能性があります。.
一般的な漏洩パターン:
-
フルデータセット統計を使用したスケーリング（トレーニングのみではなく）[2]
-
訓練とテストを組み合わせてカテゴリーマップを構築する [2]
-
テストセットを「見る」 fit
()またはfit_transform()ステップ[2]
経験則（シンプル、厳格、効果的）:
-
フィットステップのあるものは、トレーニング時にのみフィットする必要があります。
-
次に、適合したトランスフォーマーを使用して検証/テストを変換します。[2]
そして、「どれほどひどいことになるのか？」という直感的な確認をしたいなら、scikit-learnのドキュメント自体に、誤った前処理順序によってランダムなターゲットに対して精度が約0.76になり、リークが修正されると約0.5まで低下するというリークの例が示されています。リークがどれほど明らかに間違っているように見えるかがわかります。[2]
混乱なく前処理を本番環境に導入する 🏗️
多くのモデルが実運用で失敗するのは、モデル自体が「悪い」からではなく、 入力となる現実の状況 が変わったり、パイプラインが変わったりするためです。
生産を考慮した前処理には通常、次のものが含まれます。
-
保存されたアーティファクト （エンコーダマッピング、スケーラパラメータ、トークナイザ設定）により、推論では学習した変換が正確に使用される [2]
-
厳密な入力規約 （予想される列/型/範囲）
-
生産データは変動するため、スキューとドリフトを監視する必要がある[5]
具体的な定義が必要な場合は、Google の Vertex AI モデル監視機能では、 トレーニングとサービングの偏り (プロダクションの分布がトレーニングから逸脱する) と 推論ドリフト (プロダクションの分布が時間とともに変化する) を区別し、カテゴリカル特徴量と数値特徴量の両方の監視をサポートしています。[5]
サプライズはお金がかかるから。しかも楽しいサプライズじゃない。.
比較表: 一般的な前処理 + 監視ツール (および対象者) 🧰
| ツール/ライブラリ | 最適な用途 | 価格 | なぜそれが機能するのか（そして少しの正直さ） |
|---|---|---|---|
| scikit-learnの前処理 | 表形式のMLパイプライン | 無料 | 堅牢なエンコーダー＋スケーラー（OneHotEncoder、StandardScalerなど）と予測可能な動作[1] |
| ハグフェイストークナイザー | NLP入力準備 | 無料 | 実行/モデル全体で一貫して入力IDとアテンションマスクを生成する[3] |
| トーチビジョン変換 | 視覚の変革 + 拡張 | 無料 | 決定論的変換とランダム変換を1つのパイプラインで混在させるクリーンな方法 [4] |
| Vertex AI モデルモニタリング | 製品版でのドリフト/スキュー検出 | 有料（クラウド） | モニターにはスキュー/ドリフト機能があり、閾値を超えると警告を発する[5] |
（はい、テーブルにはまだ意見があります。でも少なくとも正直な意見です😅）
実際に使える実用的な前処理チェックリスト📌
トレーニング前
-
入力スキーマ（タイプ、単位、許容範囲）を定義する
-
欠損値と重複値を監査する
-
適切な方法でデータを分割する（ランダム / 時間ベース / グループ化）
-
トレーニング時のみフィット前処理（
fit/fit_transformはトレーニング時に残る）[2] -
前処理の成果物を保存して推論で再利用できるようにする[2]
トレーニング中
-
適切な場合にのみランダム増強を適用する（通常はトレーニング分割のみ）[4]
-
評価前処理を決定論的に保つ [4]
-
モデルの変更と同様に前処理の変更を追跡する（実際そうである）
展開前
-
推論では同一の前処理パスと成果物を使用することを確認する [2]
-
ドリフト/スキュー監視を設定する（基本的な特徴分布チェックでも大いに役立ちます）[5]
深掘り：よくある前処理の間違い（およびその回避方法）🧯
間違い1：「すべてをすぐに正常化します」😵
データセット全体に対してスケーリングパラメータを計算すると、評価情報が漏れてしまいます。訓練時にフィッティングし、残りを変換してください。[2]
間違い2: カテゴリーが混乱に陥る 🧩
学習と推論の間でカテゴリマッピングが変化すると、モデルは無意識のうちに世界を誤読する可能性があります。保存されたアーティファクトを使用してマッピングを固定しておきましょう。[2]
間違い 3: 評価にランダムな拡張が紛れ込む 🎲
ランダム変換はトレーニングには最適ですが、パフォーマンスを測定する際には「密かにオン」にすべきではありません。（ランダムとはランダムであることを意味します。）[4]
最終的なコメント🧠✨
AI前処理 とは、複雑な現実データを一貫性のあるモデル入力に変換する、高度な技術です。クリーニング、エンコード、スケーリング、トークン化、画像変換、そして最も重要な、繰り返し可能なパイプラインとアーティファクトが含まれます。
-
前処理は、適当にではなく、意図的に行うようにしましょう。[2]
-
最初に分割し、トレーニング時にのみ変換を適合させ、漏れを回避します。[2]
-
モダリティに適した前処理（テキストにはトークナイザー、画像には変換）を使用する。[3][4]
-
モデルが徐々に意味をなさなくなるのを防ぐため、生産の偏り/ドリフトを監視します。[5]
もし行き詰まったら、
「この前処理ステップは、明日全く新しいデータで実行しても意味があるだろうか？」と
答えが「うーん…たぶん？」なら、それがヒントです😬
実例：顧客離脱予測のためのリークセーフな前処理パイプラインの構築
シナリオ
小規模なSaaSチームが、今後30日以内に解約する可能性が高い顧客を予測しようとしている状況を想像してみてください。彼らの生データは、請求書のエクスポート、製品の使用ログ、サポートチケットの3つの場所に存在します。.
モデルの最初のバージョンは検証段階では非常に優れているように見えますが、新しい1か月分の顧客データでテストするとパフォーマンスが低下します。問題はモデルのアーキテクチャではなく、前処理にあります。.
チームは誤ってデータセット全体を使用して数値特徴量をスケーリングし、トレーニングデータとテストデータを一緒にカテゴリマッピングし、キャンセル後に追加されたサポートチケットタグを含めてしまった。典型的なリーク。厄介だが、修正可能。[2]
パイプラインに必要なもの
実用的な構成としては、以下のようなものが含まれるでしょう。
-
固定入力スキーマ: customer_id、plan_type、account_age_days、logins_30d、tickets_30d、last_payment_status、region
-
1月から9月までトレーニングを行い、10月にテストを行うなど、時間に基づいた分割方法。
-
数値スケーリングはトレーニングデータのみに適用した。
-
カテゴリエンコーダーはトレーニングデータのみに適合させた。
-
保存された前処理パイプラインにより、本番環境でも同じマッピングとスケーラー値が使用されます。
-
展開後の欠落列、未確認カテゴリ、分布変更に関する基本的な監視
基本ルールはシンプルです。まず分割を行い、次に前処理を適用します。データから学習するものはすべて、トレーニング期間からのみ学習する必要があります。[2]
指示例
前処理ステップの作業概要として、以下を使用してください。
顧客の請求、使用状況、およびサポートデータを使用して、解約予測モデル用の前処理パイプラインを構築します。変換器を適用する前に、データを時間で分割します。トレーニングデータのみに数値スケーラーとカテゴリエンコーダーを適用し、その後、適用した変換を検証データとテストデータに適用します。本番モデルが同じスキーマ、カテゴリマッピング、およびスケーリングパラメータを使用するように、すべての前処理成果物を保存します。予測を行う前に、欠落している列、予期しないデータ型、未知のカテゴリ、および大きな分布の変化をフラグ付けします。.
テスト方法
モデルを信頼する前に、意図的に扱いにくいレコードをいくつか使用して、前処理パイプラインをテストしてください。
-
トレーニングに参加していなかったプランタイプの顧客
-
地域またはlast_payment_statusが欠落している行
-
30日間で1万回ログインするなど、異常に利用頻度の高い顧客
-
列の順序が間違っている本番環境用ファイル
-
フィッティング中に使用されなかった、将来の月のテストセット
次に、次の3つの点を確認してください。
-
パイプラインは、フィーチャーの順序を変更せずに実行されますか？
-
未知のカテゴリは一貫して処理されていますか？
-
情報漏洩を除去した後、検証性能はより信頼できるレベルまで低下するだろうか？
最後の点は重要です。不自然に高い検証スコアは、奇跡ではなく、多くの場合、前処理上の問題の兆候です。.
結果
ノートブックの手順を保存済みパイプラインに変換する前と後で、5つのサンプル前処理実行時間を計測した結果を例示します。
-
データセットの更新ごとに、手動による前処理時間が55分から8分に短縮された。.
-
機能順序エラーは、5回のテスト更新で3件発生していたのが、5回の更新で0件に減少しました。.
-
リークを除去した後、検証精度は91%から74%に低下したが、新規月テストの精度は62%から71%に向上した。.
-
チームは、欠落している列、無効な型、未知のカテゴリ、null値の変化、数値範囲の変化、およびトレーニングとサービス提供スキーマの不一致という6つの自動チェックを追加しました。.
これらの数値は普遍的なベンチマークではありません。これらは、チームが更新のタイミングを計り、失敗した実行回数を数え、検証結果を将来の月のデータと比較することで再現できる、単純な前後比較の指標です。.
何が問題になる可能性があるか
最大のリスクは、パイプラインをきれいに見せかけながら、密かに情報漏洩を放置してしまうことです。例えば、「前回の解約警告メール送信からの日数」は有益な情報のように思えるかもしれませんが、そのメールが社内での解約レビュー後にのみ送信される場合、将来的に情報が漏洩する可能性があります。.
その他のよくある落とし穴：
-
保存済みのマッピングを読み込む代わりに、生産現場でエンコーダを再装着する
-
新しいカテゴリが静かに機能の位置を変更するようにする
-
実際のタスクが時間ベースである場合に、ランダム分割でテストを行う
-
トレーニング時に欠損値のある行を削除するが、推論時にはそれらを処理しない
-
入力ドリフトを無視してモデルの精度を監視する
実践的な教訓
優れた前処理パイプラインは、生データを整理するだけでなく、モデルを不適切な評価、破損した本番環境入力、そしてゆっくりとしたサイレントドリフトから保護します。顧客離脱モデルの場合、巧妙な前処理と信頼性の高い前処理の違いは、特にモデルがこれまで見たことのない月のデータが使用される場合に、同じ適合変換が毎回再利用されるかどうかにかかっていることが多いのです。.
よくある質問
AI 前処理とは簡単に言うと何でしょうか?
AI前処理とは、ノイズが多くばらつきのある生データを、モデルが学習できる一貫性のある入力データに変換する、繰り返し可能な一連の手順です。これには、クリーニング、検証、カテゴリのエンコード、数値のスケーリング、テキストのトークン化、画像変換の適用などが含まれます。その目的は、トレーニングと本番環境の推論で「同じ種類の」入力データを使用し、モデルが後で予測できない動作に陥らないようにすることです。.
AI 前処理が製造においてなぜそれほど重要なのか?
モデルは入力データの表現に敏感なので、前処理は重要です。トレーニングデータが本番環境データとは異なる方法でスケーリング、エンコード、トークン化、または変換されている場合、オフラインでは問題ないように見えるトレーニング/サーブの不一致エラーが発生し、オンラインではエラーが発生することがあります。強力な前処理パイプラインは、ノートブックのスパゲッティを解く必要がないため、ノイズを低減し、学習の安定性を向上させ、反復処理を高速化します。.
前処理時にデータ漏洩を回避するにはどうすればよいですか?
シンプルなルールで対応できます。 適合 ステップを含むものはすべて、トレーニングデータのみで適合させる必要があります。これには、平均値、カテゴリマップ、語彙などのパラメータを学習するスケーラー、エンコーダー、トークナイザーなどが含まれます。まずデータを分割し、トレーニングデータで適合させ、適合させたトランスフォーマーを使用して検証/テストデータを変換します。データリークがあると、検証結果は「魔法のように」良好に見えても、本番環境では崩壊する可能性があります。
表形式データの最も一般的な前処理手順は何ですか?
表形式データの場合、通常のパイプラインには、クリーニングと検証（型、範囲、欠損値）、カテゴリエンコーディング（One-Hotまたは順序）、数値スケーリング（標準化または最小最大化）が含まれます。多くのパイプラインでは、比率、ローリングウィンドウ、カウントなどのドメイン駆動型特徴量エンジニアリングが追加されます。実用的な方法としては、列グループ（数値、カテゴリ、識別子）を明示的に定義することで、変換の一貫性を維持できます。.
テキスト モデルの前処理はどのように機能しますか?
テキストの前処理とは、通常、トークン／サブワードへのトークン化、それらを入力IDへの変換、そしてバッチ処理のためのパディング／トランケーション処理を意味します。多くのTransformerワークフローでは、IDに加えてアテンションマスクも作成されます。一般的なアプローチは、即興で設定するのではなく、モデルの想定されるトークナイザー設定を使用することです。トークナイザー設定のわずかな違いが「学習はできるが、予測できない動作をする」という結果につながる可能性があるためです。.
機械学習用の画像の前処理にはどのような違いがありますか?
画像の前処理は通常、形状とピクセル処理の一貫性を確保します。具体的には、サイズ変更／切り取り、正規化、そして決定論的変換とランダム変換の明確な区別が挙げられます。評価においては、変換は決定論的であるべきで、指標を比較検討できます。トレーニングにおいては、ランダムな拡張（ランダム切り取りなど）によって堅牢性を向上させることができますが、ランダム性はトレーニングの分割範囲に限定する必要があり、評価時に誤って残されないようにする必要があります。.
前処理パイプラインが脆弱ではなく「良好」になる理由は何でしょうか?
優れたAI前処理パイプラインは、再現性、リークセーフ、そして観測可能性を備えています。再現性とは、ランダム性が意図的な拡張でない限り、同じ入力から同じ出力が得られることを意味します。リークセーフとは、適合ステップが検証/テストに一切影響を与えないことを意味します。観測可能とは、欠損値、カテゴリ数、特徴量分布などの統計情報を検査できるため、デバッグは直感ではなく証拠に基づいて行えることを意味します。パイプラインは、アドホックなノートブックシーケンスよりも常に優れています。.
トレーニングと推論の前処理の一貫性を保つにはどうすればよいですか?
重要なのは、推論時に学習済みの成果物（スケーラーパラメータ、エンコーダマッピング、トークナイザー設定など）を全く同じものを再利用するということです。また、本番環境のデータがいつの間にか無効な形状に変化してしまわないように、入力コントラクト（想定される列、型、範囲）も必要です。一貫性とは、「同じ手順を実行する」ということではなく、「同じ適合パラメータとマッピングで同じ手順を実行する」ということです。
ドリフトやスキューなどの前処理の問題を時間の経過とともに監視するにはどうすればよいでしょうか?
堅牢なパイプラインを構築しても、本番環境のデータは変化します。一般的なアプローチは、特徴量の分布の変化をモニタリングし、トレーニングとサービングのスキュー（本番環境がトレーニングから逸脱すること）と推論ドリフト（本番環境が時間の経過とともに変化すること）をアラートで通知することです。モニタリングは、軽量（基本的な分布チェック）または管理型（Vertex AI Model Monitoringなど）から選択できます。目標は、入力の変化がモデルのパフォーマンスを徐々に低下させる前に、早期に検知することです。.
参考文献
[1] scikit-learn API: sklearn.preprocessing (エンコーダー、スケーラー、正規化)
[2] scikit-learn: よくある落とし穴 - データリークとその回避方法
[3] Hugging Face Transformers ドキュメント: トークナイザー (入力 ID、アテンション マスク)
[4] PyTorch Torchvision ドキュメント: 変換 (サイズ変更/正規化 + ランダム変換)
[5] Google Cloud Vertex AI ドキュメント: モデル監視の概要 (特徴の偏りとドリフト)