データと計算リソースがますますアクセスしやすくなったため、機械学習 (ML) モデルの構築は以前ほど困難ではなくなりました。そのため、さまざまな規模や業界の企業がデータ サイエンス チームに投資し、ML を通じてビジネス価値を提供しています。
しかし、本当の課題は、ML モデルの構築だけにとどまりません。従来のソフトウェア システムとは対照的に、ML システムのパフォーマンスは急速に低下する可能性があるため、綿密な監視と頻繁な再トレーニングが必要になります。したがって、重要な課題は、統合された ML パイプラインを構築し、それを本番環境で継続的に運用することです。
この記事では、以下のトピックを取り上げながら、ML システムに DevOps (開発と運用) の原則を適用して ML システムを開発および運用する方法について説明します。
MLOps (ML Operations) は、DevOps の原則を ML システムに適用します。具体的には、データ サイエンティストやソフトウェア エンジニアが大規模な ML システムを開発および運用するのに役立つ一連のプラクティス、パラダイム、および開発者ツールです。
MLOps を実践するということは、ML システムの構築と運用のすべてのステップでコラボレーション、自動化、継続的な改善を推進することを意味します。MLOps を成功させる鍵は、人材、プロセス、ツールです。総合的な MLOps アプローチを実装する方法の詳細については、このホワイトペーパーを参照してください。
DevOps と MLOps
MLOps と ML システムの関係は、DevOps と従来のソフトウェア システムの関係と同じです。どちらも、コラボレーション、自動化、継続的な改善という同じ概念に基づいています。しかし、一般的なソフトウェア システムと機械学習システムの違いにより、考慮すべき点が異なります。主に、DevOps と MLOps は、チーム構成、開発プロセス、インフラストラクチャ管理が異なります。
DevOps は、大規模なソフトウェア システムを開発および運用するための一連のプラクティス、パラダイム、および開発者ツールです。DevOps の目的は、柔軟で効率的なソフトウェア開発および配信プロセスを実現し、開発者が大規模な機械学習システムを確実に構築および運用できるようにして、最終的にビジネス成果を向上させることです。
これは、さまざまなチーム間のコラボレーションを改善するためのシステムを設定し、自動化を使用してプロセスを加速し、継続的な改善の概念を適用することによって行われます。
DevOps の継続的な改善のために知っておくべき 2 つの中核概念は次のとおりです。
- 継続的インテグレーション (CI)は、開発者が定期的にコードの変更を中央リポジトリにマージし、自動ビルドと一連のテストをトリガーして、新しいコードが既存の機能を壊さないことを確認するソフトウェア開発手法です。CI はコードの品質を向上させるのに役立ち、新しいソフトウェア更新の検証とリリースにかかる時間を短縮します。
- 継続的デリバリー (CD) は、ステージング環境または本番環境にコード変更を展開するプロセスを自動化することで、CI の原則を拡張します。これは、統合が成功した後に本番環境へのリリース用にコード変更が自動的に準備されるソフトウェア開発手法です。CD は、ソフトウェア配信の高速化と信頼性の向上に役立ち、展開可能なビルド成果物を提供することで、ソフトウェアが常に展開可能な状態であることを保証します。
従来のソフトウェア開発では、CI/CDを使用してソフトウェアのテスト、ビルド、デプロイを自動化しますが、これは ML プロジェクトにも適応できます。
機械学習システムはソフトウェア システムであり、MLOps でも同様のプラクティスが適用されますが、ML システムとソフトウェア システムには大きな違いがあります。下の図に示すように、従来のソフトウェア システムでは、開発者がルールとパターンを定義して、システムが特定の入力を処理して応答する方法を決定します。一方、ML システムはトレーニングを通じて入力と出力のパターンと関係を学習します。
DevOps vs MLOps: チーム構成
DevOps と MLOps の違いの 1 つは、チームの構成にあります。両方に存在する役割もありますが、MLOps チームに固有の役割もあります。
DevOps チームと MLOps チームの両方における一般的な役割は次のとおりです。
- プロダクトマネージャー: 構築するソリューションを定義し、さまざまな関係者と協力してプロジェクトの優先順位を決定し、実行します。
- ソフトウェア エンジニア: ソフトウェア エンジニアリングと本番環境対応ソリューションの構築を専門としています。また、MLOps で既存のアプリケーションに ML 機能を統合します。
- DevOps/MLOps エンジニア: MLOps の ML プラットフォームを含む運用システムをデプロイおよび監視します。
MLOps チームには、ML プロジェクトの独自の性質に対応するために、いくつかの追加の役割が含まれます。
- データ エンジニア: データ インフラストラクチャを管理し、データ パイプライン、集約、ストレージ、監視を構築します。
- データ サイエンティストおよび機械学習エンジニア: ML モデルの開発、トレーニング、評価を行います。
ML プロジェクトにおける役割の詳細な説明については、The Full Stack の「ディープラーニング コース」の講義 13 で詳しく学ぶことができます。
DevOps と MLOps: 開発プロセス
このセクションでは、ML システムの開発とソフトウェア システムの開発のどの側面が異なるのか、またその影響について説明しながら、MLOps に固有の考慮事項と課題の一部について説明します。
- 開発: ソフトウェア システムの開発とは異なり、機械学習モデルの開発は実験的なプロセスです。ML モデルの開発は、さまざまな機能、モデル、ハイパーパラメータ構成を使用して多くの実験を実行し、ビジネス ケースに最適なソリューションを見つける反復的なプロセスです。
- 検証とテスト: DevOps の CI には通常、コードとコンポーネントをテストおよび検証するための単体テストと統合テストが含まれますが、MLOps ではデータとモデルもテストおよび検証する必要があります。
- デプロイメント: DevOps の CD には通常、単一のソフトウェア パッケージまたはサービスのデプロイメントが含まれますが、MLOps の CD は、MLOps のレベルに応じて、ML モデルのデプロイメント、または ML システムを自動的にデプロイする ML パイプライン全体のデプロイメントを指す場合もあります。
- 運用監視: 一般的なソフトウェア システムとは異なり、ML システムは導入後すぐに機能しなくなる可能性があります。ML モデルのパフォーマンスは、特徴分布とデータ分布の変化に敏感です。したがって、ロールバックやモデルの更新などの適切な対策を講じるためには、運用中のモデルのパフォーマンスと入力データの分布を監視する必要があります。
この記事では、「MLOps パイプライン」のセクションで、MLOps パイプラインがこれらの MLOps 固有の課題をどのように考慮するかについて詳しく説明します。
DevOps vs MLOps: インフラストラクチャ管理
DevOps と MLOps はインフラストラクチャ管理でも異なります。主な違いはデータ ストレージ、具体的にはアーティファクトのバージョン管理にあります。DevOps と MLOps のバージョン管理により、追跡可能性、再現性、ロールバック、デバッグ、コラボレーションが保証されます。
ソフトウェア システムのコア アーティファクトは、ソース コード、ライブラリ、オブジェクト ファイル、および実行可能ファイルであり、コード バージョン管理システムとアーティファクト ストレージでバージョン管理されます。ただし、ML システムにはデータセットとモデルの追加アーティファクトがあり、これらには別のバージョン管理システムが必要です (「MLOps の概要: データとモデルのバージョン管理」を参照)。
コンプライアンスと規制のための MLOps
最近、欧州連合と米国政府は機械学習を意味のある形で規制することを検討し始めており、これらの法律は終わりではなく監視強化の始まりであるのは間違いないでしょう。規制自体は意味のある形で異なりますが、重複している部分もあります。
- プライバシーや平等保護などの基本的権利に影響を与える可能性のある機械学習システムを持つ企業や連邦政府機関は、より厳しい監視を受けることになる。例えば、監視や金融の公平性に関わるモデルはほぼ確実に規制されるが、従業員がシステムを照会できる社内LLM システムは規制されない可能性が高い。
- より大規模で影響力の大きいモデルは、効果的である可能性がはるかに高くなります。ここで、数十億のパラメータを持つ LLM と推奨システムのようなものとの違いについて考えてみましょう。
- データの系統とガバナンスは、ML システムを構築するエンジニアや企業にとって最優先事項です。データは、時間の経過とともに悪化する可能性のある有害な結果をもたらすべきではありません。
興味深いことに、両法は政府と業界の両方でイノベーションを奨励しています。これらは下流に起こりうる悪影響を規制する試みであり、研究を妨害したり機械学習の最先端を鈍らせたりするものではありません。
監査証跡とドキュメントのための MLOps
データとモデルの系統を記録する実験追跡ソリューションは、本格的な機械学習パイプラインに不可欠なだけでなく、コンプライアンスにとっても不可欠です。
上記の規制を含むコンプライアンス体制では、どのデータがどのモデルに情報を提供しているか、モデルはどのようにトレーニングされたか、そして可能な限りモデルの解釈可能性を報告することが求められています。スプレッドシートや中途半端な対策では、これらの要件を満たすことはできません。
代わりに、モデル トレーニング パイプラインを可能な限り追跡することをお勧めします。これには追加の利点 (デバッグ、パフォーマンスの低いものの早期停止、GPU 使用率の最大化など) がありますが、モデルの系統、パフォーマンス、および出力を追跡できることは、規制当局が頻繁に要求するものです。Weights & Biases はまさにこれを実現するために作られています。
MLOps パイプライン
ビジネス ユース ケースが定義され、その成功基準が確立されると、下の図に示すように、MLOps パイプラインには次の段階が含まれます。
このセクションでは、これらの各ステージについて簡単に説明します。これらのステージは、「MLOps の 3 つのレベル」セクションで説明したように、手動で完了することも、自動パイプラインで完了することもできます。
データエンジニアリング
従来のソフトウェア システムとは対照的に、ML モデルはデータからパターンを学習します。したがって、データはあらゆる機械学習プロジェクトの中核であり、MLOps パイプラインはここにあります。通常、データ エンジニアリング チームがこの段階を実施します。次の段階でデータをモデル トレーニングに使用するには、いくつかの重要な手順を実行する必要があります。
最初のステップはデータ収集です。まず、必要なデータを特定し、関連データが存在するかどうか、またその場所を特定する必要があります。次に、さまざまなデータ ソースから ML タスクに関連するデータを選択して収集し、それらを 1 つのまとまりのある形式に統合します。
次に、探索的データ分析 (EDA) を実行してデータ探索を 実施し、データの品質を確保するとともに、データに対する理解を深めます。
- データ品質チェックでは、分布の期待値などをチェックすることで、データが正確、完全、一貫していることを確認します。
- EDA は、データ スキーマと特性を理解し、モデルに必要なデータ準備と機能エンジニアリングを特定することを目的としています (次の手順を参照)。
透明性を確保するには、この初期段階の分析手順を文書化し、再現可能にする必要があります。そのためには、 W&B テーブルまたはW&B レポートを使用できます。
最後に、データ準備ステップでは、MLOps パイプラインの次のステージに向けてデータが処理されます。データ準備には以下が含まれます。
- データのクリーニング、外れ値の処理、欠損値の補完などのデータ前処理。
- モデルがターゲット タスクを解決できるようにするための、集約機能、ラベル エンコーディング、スケーリングなどの機能エンジニアリング。
- データセットをトレーニング データ、検証データ、テスト データに分割するなどのデータセットのパーティション分割。
このステップの出力は、準備された形式で分割されたデータです。このステップではソース データが変更されるため、データセットの変更を保存、追跡、管理するW&B Artifactsなどの何らかのデータ バージョン管理を適用することをお勧めします。これにより、データが一元化され、バージョン管理され、異なるチーム間で簡単にアクセスできるようになります。データのバージョン管理は、データ ソース、データ使用情報、データ リネージを示す信頼性の高いデータ記録としても使用でき、より優れたコラボレーションが可能になります。
モデル開発
データの準備ができたら、機械学習モデルの開発とトレーニングを開始できます。MLOps パイプラインのこの段階では、最も多くの ML 知識が必要となり、通常はデータ サイエンス チームが行います。モデル開発は反復的なプロセスであり、どのモデルを本番環境に昇格させるかを決定する前に、モデルのトレーニング、評価、および実現可能性とビジネスへの影響の見積もりに関する複数の実験が必要です。
ML モデルはトレーニング プロセスを通じてデータからパターンを学習するため、モデル トレーニングはモデル開発の不可欠な部分です。通常は、シンプルなベースライン モデルを構築し、モデル アーキテクチャを微調整したり、ハイパーパラメータ チューニングを適用したりして、モデルを繰り返し改善すると効果的です (「MLOps の概要: ハイパーパラメータ チューニング」を参照)。機能性と精度を確認するには、たとえば、クロス検証テストを使用できます。
実験はさまざまなステージでの反復を含む反復プロセスであるため、関係者やさまざまなチームとの迅速な反復とコラボレーションを確立することが重要です。コラボレーション、実験の複製、同じ結果の再現を容易に行うには、トレーニング プロセスで実験追跡を通じてデータセット、メトリック、ハイパーパラメータ、アルゴリズムを追跡する必要があります (「MLOps の概要: 機械学習実験追跡」を参照)。W &B 実験はこれらのタスクを容易にします。
次に、モデルはモデル評価ステップに進みます。モデル評価の目的は、モデルの品質を確保することです。モデルの品質は、トレーニング セットと検証セットとは別の追加のテスト セットであるホールドアウト テスト セットで評価されます。このステップの出力は、モデルの品質を評価するためのログに記録されたメトリックのセットです。
モデル開発段階の最後のステップは、モデル検証ステップです。モデル検証の目的は、モデルが現在のビジネス メトリックを改善し、デプロイメント段階に進むべきかどうかを判断することです。このステップは手動で実行することもできますが、CI/CD を使用することをお勧めします。
各リリースでユニット テストと統合テストを実行するだけでなく、A/B テストを実施して、新しいモデルが現在のモデルよりも優れていることを確認することも役立ちます。デプロイメント ワークフローの A/B テストと可観測性を有効にするには、MLOps パイプラインの成果物であるモデル デプロイメント候補のバージョン管理と追跡が必要です。このモデル成果物は、W&B モデル レジストリなどのモデル レジストリに記録して、モデル、トレーニングに使用された入力データ、およびモデルの生成に使用されたコード間のリンクを記録できます。
モデルの展開
モデルが開発され、そのパフォーマンスが本番環境で確認された後、MLOps パイプラインの次のステップは、トレーニング済みのモデルを本番環境にデプロイして予測を実行し、ビジネス価値を実現することです。
これは、MLOps パイプラインが「Ops」ステージに移行するときです。このステージは通常、MLOps チームによって実行されます。ML チームと Ops チーム間のスムーズで合理的な移行を可能にするために、モデル成果物は通常、W&B モデル レジストリなどのモデル レジストリに保存されます。モデル レジストリはモデルの中央リポジトリであり、ML モデルへの変更を保存、追跡、管理するモデル バージョン管理でよく使用されます。
モデルを本番環境にデプロイするには、一般的なデプロイメント戦略 (ブルー/グリーン デプロイメント、シャドウ デプロイメント、カナリア デプロイメントなど) を使用します。さらに、デプロイメントは手動で行うことも、CI/CD パイプラインを使用して自動化することもできます。
生産監視
機械学習モデルが本番環境に導入されたら、ML モデルが期待どおりに動作することを確認し、パフォーマンスの低下を早期に検出するために、モデルを監視する必要があります。
ML プロジェクトに関連付けられたビジネス メトリックを監視することによってのみモデルのパフォーマンスを監視することができますが、モデルへの入力も監視すると役立ちます。入力データの分布を監視することで、データ ドリフトをより迅速に検出して対応できます。
理想的には、運用中のモデルを監視する際に、自動的かつ体系的な監視とアラート システムを組み合わせる必要があります。これにより、必要に応じてモデルの再トレーニングを自動的にトリガーできるようになります。
MLOps の 3 つのレベル
これらのステップの自動化レベルによって ML プロセスの成熟度が定義され、新しいデータで新しいモデルをトレーニングする速度、または新しい実装で新しいモデルをトレーニングする速度が反映されます。次のセクションでは、Google による MLOps の 3 つのレベルについて説明します。完全に手動のレベル (レベル 0) から始まり、部分的に自動化されたレベル (レベル 1)、そして ML と CI/CD パイプラインの両方を自動化するレベル (レベル 2) まであります。
以下では、MLOps の 3 つのレベルを簡略化して説明しています。詳細については、元のソースを参照してください。
通常、ML プロジェクトを始めたばかりの組織では自動化があまり行われておらず、手動のワークフローに従っています。ただし、組織が ML プロジェクトに慣れてくると、ビジネス価値を高めるために、より自動化された MLOps パイプラインを徐々に実装することが必要になる場合があります。
レベル 0 MLOps: マニュアル
レベル 0 の MLOps では、データ エンジニアリングからモデルの展開まで、MLOps パイプラインのすべてのステップとすべての遷移が手動で行われます。CI も CD もありません。自動化がないと、通常、アクティブな運用監視が不足します。
次の図は、レベル 0 MLOps パイプラインのワークフローを示しています。
レベル 0 の MLOps は、機械学習を使い始めたばかりの企業でよく見られます。この手動プロセスは、ほとんど変更されない (たとえば、年に数回のみ) モデルが少数しかない場合は十分かもしれません。しかし、実際には、ML モデルは実際の環境にデプロイされると壊れることが多く、常に監視して頻繁に更新する必要があります。したがって、アクティブな本番環境の監視と ML パイプラインの自動化は、次のレベルの MLOps で説明するように、これらの課題に対処するのに役立ちます。
レベル 1 MLOps: パイプライン自動化
レベル 1 MLOps では、アクティブなパフォーマンス監視が導入され、MLOps パイプラインが自動化され、特定のトリガーでモデルを継続的に再トレーニングし、モデルの CD を実現します。そのためには、自動化されたデータとモデルの検証手順およびパイプライン トリガーを導入する必要があります。
次の図は、レベル 1 MLOps パイプラインのワークフローを示しています。
レベル 1 MLOps は、次の点でレベル 0 と異なります。
- デプロイされる内容: レベル 1 では、トレーニング済みのモデルを予測サービスとしてデプロイする代わりに、トレーニング パイプライン全体が本番環境にデプロイされます。この ML パイプラインは、ML 実験のステップを調整し、1 つ以上のトリガーに基づいてモデルを自動的かつ定期的に再トレーニングします。
- CD の導入: ML パイプラインの後、モデルの展開は CD によって自動化され、トレーニングされたモデルが予測サービスとして提供されます。
- アクティブ プロダクション モニタリング: レベル 0 とは異なり、レベル 1 では、入力データとモデル パフォーマンス統計を収集するためのアクティブ プロダクション モニタリングが導入されます。したがって、アクティブ プロダクション モニタリングでは、データ検証とモデル検証の手順を自動化する必要があります。理想的には、プロダクション モニタリングは、特定のイベントに基づいてトリガーを送信できるアラート システムと連携されます。
パイプラインを自動的に実行して ML モデルを再トレーニングするトリガーは、次の 1 つ以上になります。
- トレーニングとサービスの偏りについて: レベル 0 では、MLOps パイプラインの ML 部分と Ops 部分は、通常、切断されています。この切断により、たとえば、低レイテンシのサービスを提供するために、必要な機能を本番環境で利用できるようにする必要がある場合に、トレーニングとサービスの偏りが生じる可能性があります。
- モデルのパフォーマンス低下について: モデルのパフォーマンスが予想範囲から大きく逸脱した場合。
- データ ドリフトについて: 入力データの分布が予想値から大きく外れている場合。データ ドリフトを早期に検出すると、モデルのパフォーマンスが低下する前にモデルを改善するのに役立ちます。
- 新しいトレーニング データの可用性: 新しい、新しくラベル付けされたデータを使用してモデルのパフォーマンスを向上できます。
- 新しい要件について: モデルを変化する環境や要件の変更に適応させる必要がある場合。
- オンデマンド: パイプラインのアドホックな手動実行。
- スケジュールに従って: パイプラインのスケジュールされた実行 (例: 毎日、毎週、毎月)。スケジュールは、データ パターンが変化する頻度と、モデルの再トレーニングにかかるコストによって異なります。
レベル 1 MLOps は、新しいデータに基づいて新しいモデルを定期的にデプロイするが頻繁ではなく、少数のパイプラインのみを管理する企業で一般的です。ただし、ML モデルがビジネスの中核である場合、ML チームは新しい ML のアイデアと改善に継続的に取り組む必要があります。ML チームが ML コンポーネントの新しい実装を迅速に構築、テスト、デプロイできるようにするには、次のレベルの MLOps で説明されている堅牢な CI/CD セットアップが必要です。
レベル 2 MLOps: CI/CD パイプラインの自動化
レベル 2 MLOps では、MLOps パイプライン全体が自動化された CI/CD システムであり、データ サイエンティストは特定のトリガーだけでなく新しいアイデアを迅速に反復することで ML モデルを改善できます。レベル 1 の ML モデルの CD に加えて、自動化されたパイプラインに CI/CD が導入されています。
次の図は、レベル 2 MLOps パイプラインのワークフローを示しています。
レベル 2 MLOps とレベル 1 MLOps の主な違いは、MLOps パイプラインに CI/CD が導入されていることです。これにより、ML と Ops の側面が切り離されなくなります。これを実現するには、まず ML パイプラインの開発を部分的に自動化する必要があります (たとえば、データとモデルの分析手順は通常、依然として手動プロセスです)。次に、ML パイプラインの新しいコードがソース コード リポジトリにプッシュされたときに実行される CI/CD パイプラインを実装できます。
- パイプライン CI : 新しいコードがソース コード リポジトリにコミットまたはプッシュされると、パイプラインとそのコンポーネントが構築、テスト、パッケージ化されます。ユニット テストと統合テストでは、機能エンジニアリング、モデル トレーニング、推論、監視が適切に機能することも確認します。CI の出力は、後の段階でデプロイされるパイプライン コンポーネント (パッケージ、実行可能ファイル、成果物) です。
- パイプライン CD : CI ステージによって生成された成果物がターゲット環境にデプロイされます。
レベル 2 MLOps は、ML をビジネスの中核に据えている企業でよく使用されます。このシステムにより、データ サイエンティストとエンジニアは共同作業環境で作業し、新しいアイデアを迅速に検討し、新しいパイプライン実装を自動的に構築、テスト、およびデプロイできます。レベル 2 MLOps 戦略では、新しいデータを使用してモデルを頻繁に (毎日、毎時間) 再トレーニングし、数千台のサーバーに同時に更新をデプロイできます。
MLOps 戦略の策定
すべての人に当てはまる MLOps 戦略はありません。ビジネス ケースに最適な MLOps 戦略を開発するには、次の点を確立する必要があります。
- 目標の定義: アプリケーションにおける機械学習の可能性を探り始めたばかりですか、それともビジネス モデルの中核に ML を取り入れる予定ですか?
- 目指すべき場所を理解する: 目標によって、必要な MLOps のレベルが決まります。モデルをどのくらいの頻度で、いつ更新する予定ですか? パフォーマンスの低下などの特定のトリガーでのみ ML モデルを更新すれば十分でしょうか。それとも、最先端の ML 機能を顧客に提供するために、技術の進歩を常に把握しておく必要がありますか?
- チーム/能力の評価: MLOps 戦略を成功させるには人材が不可欠です。多様性に富んだ部門横断的なチームを持つことが不可欠であるだけでなく、ML がビジネスにどのような価値をもたらすかを理解している幹部が率いる文化を持つことも重要です。
- インフラストラクチャと環境の評価: 必要なインフラストラクチャ投資は、運用規模に大きく依存します。シンプルな ML アプリケーションが 1 つある場合は、インフラストラクチャは必要ありません。ただし、1 時間あたり数百万件のリクエストを処理する可能性のある大規模なアプリケーションに移行する場合は、汎用化されたインフラストラクチャまたは高度に専門化されたインフラストラクチャに移行する必要があります。
これらのポイントを明確に把握することで、ビジネス価値を高め、リスクを軽減し、ML プロジェクトの成功率を高める MLOps への総合的なアプローチを開発するのに役立ちます。MLOps 戦略を開発するための最初のステップとして、40 の質問に基づいて成熟度評価を実施することから始めることができます。
強力な MLOps 戦略のメリット
組織が機械学習プロジェクトの実験を始めたばかりでも、すでに大規模な ML アプリケーションを構築して運用している場合でも、強力な MLOps 戦略を持つことが成功の重要な要素となります。
DevOps の原則であるコラボレーション、自動化、継続的な改善を ML プロジェクトに適用することで、ML アプリケーションの市場投入までの時間を短縮し、最終的にはコストとリソースの使用率を最適化しながらビジネス価値を高めることができます。明確に定義された MLOps 戦略により、企業は開発と展開のギャップを埋め、常に進化する AI テクノロジーの分野でイノベーションと持続的な成功の基盤を築くことができます。
機械学習がビジネスの中核となるにつれ、MLOps の導入は単なる戦略的な選択ではなくなります。ML イニシアチブの可能性を最大限に引き出すことを目指す組織にとって、これは必須事項です。