第5章 リリースと運用

学習目標

• リリース範囲（ユーザー層、機能範囲、除外する類型）を定め、シャドーテスト、カナリア、ベータ、A/Bテストの中から適切なリリース方式を選択します。
• リリース前に中断基準とロールバック方法を定め、カナリアの結果を標本サイズと対照群との比較によって判断します。
• システム・品質・ユーザー行動・事業指標に階層を分けて運用指標とアラートを設計します。
• モデルとプロンプトの変更をバージョン、回帰評価、段階的反映によって管理し、モデルのライフサイクル告知に備えます。
• インシデントが発生した場合は、拡散防止、通知と是正、原因修正と復旧、記録と非難のない振り返り、再発防止策の順に対応し、運用データに基づいて改善の優先順位を定めます。

はじめに

AI機能をリリースする日、チームは通常安堵します。評価に合格し、リリース基準もクリアしました。しかし、評価セットは昨日までの世界であり、リリース後のユーザーは評価セットになかった質問をし、モデル提供元はモデルを変更し、チームはプロンプトを修正します。AI機能の品質はリリース当日に最も明確に把握され、その後は見守っていなければ静かに変化していきます。

Anthropicは、最も効果的なチームは自動評価、運用モニタリング、A/Bテスト、ユーザーフィードバック、人手によるレビューを併用していると説明しています。自発的なリスク管理ガイドラインであるNIST AI RMFは、導入後モニタリング計画を実行し、インシデントやエラーを影響を受ける人々を含む関係者に通知することを推奨しています。リリースと運用は、この原則をスケジュールと数値に変換する作業です。

本章では、まずリリース範囲とリリース方式を選択し、カナリアと中断基準を設計します。次に、運用指標とアラート、モデル・プロンプトの変更管理を扱い、最後にインシデント対応と振り返り、運用データによって改善の優先順位を定める方法を学びます。

重要な概念

リリースは測定の始まり

リリースは開発の終止符ではなく、現実世界で性能を測定し始める出発点です。オフライン評価では答えられなかった問い、すなわち実際のユーザーがどのように使うのか、どのような入力が入ってくるのか、事業指標がどのように動くのかは、リリース後に初めて答えることができます。そのため、リリース計画には、何をいつまで測定し、どのような数値が出れば拡大し、どのような数値が出れば停止するのかが含まれていなければなりません。

例えるなら、リリースは新しい橋の開通のようなものです。設計計算（オフライン評価）をクリアしても、初期には車両の通行を制限してセンサーで揺れを測定し、基準を超えたら規制するというルールをあらかじめ決めておきます。

リリース範囲の決定

リリース範囲は3つの軸で決定します。

評価において特定の類型のみが基準に達しておらず、その類型を人間に振り向けるルートがある場合、その類型を除外してリリースするのが範囲決定です。除外は実行段階で強制されなければならないため、意図分類器やルールフィルターによって該当する類型の入力を識別し、モデルの代わりに相談員や既存の案内に送る仕組みをあわせて企画します。範囲はフィーチャーフラグのような仕組みで調整できるようにしておき、後から拡大または縮小する際にコードのデプロイなしで変更できるようにします。

リリース方式の比較

AWSのシャドーテストの説明によると、新しいバリアントは実際のリクエストのコピーを受け取るものの、呼び出し元のアプリケーションには既存（本番）バリアントのレスポンスのみが返され、シャドーバリアントのレスポンスは破棄するか記録してオフラインでの比較に使用します。Google SREは、カナリアを「サービス変更の部分的かつ時間制限のあるデプロイとその評価」と定義し、実質的なA/Bプロセスであると説明しています。

カナリア設計

Google SREのカナリアに関する章から企画者が押さえておくべき原則は5つあります。

1. 小さく始める。 欠陥が及ぼす影響は、欠陥にさらされたトラフィックに比例します。
2. 対照群と比較する。 カナリアは、変更された部分と残りのサービス（対照群）を比較するプロセスです。時間は観測指標を変化させる最大の要因の1つであるため、リリースの前後ではなく、同時期の対照群と比較します。
3. 指標を選ぶ。 指標は問題を明らかにでき、代表性があり、変更に帰属できるものでなければなりません。
4. 十分に長く、十分に大きく。 カナリアは全体デプロイを代表できるほど大規模であり、十分に長く継続され、代表性のある標本を処理できるだけのトラフィックを受け取らなければなりません。
5. 一度に1つ。 同時に複数のカナリアを実行してはなりません。2つの変更を同時にリリースすると、指標の変化をどちらの原因に帰属させるべきかわからなくなります。

AI機能のカナリアでは、システム指標（エラー、レイテンシ）だけでなく、品質やユーザー行動指標（通報率、相談転送率、再生成率）もあわせて確認します。AIの失敗はエラーレスポンスなしに発生するためです。

中断基準とロールバック

中断基準はリリース前に数値で決定します。「通報率が対照群より0.5%ポイント以上高ければ中断」「根拠の引用がない回答が2%を超えたら中断」のように記述します。結果を見た後に基準を決めると、結果に合わせて基準を選んでしまうことになります。

中断基準には判定に必要な最小標本数もあわせて記載します。60件の対話から生じた2%ポイントの差は偶然の可能性があり、2万件から生じた差はそうではありません。割合で判定する指標は、標本が不足している場合は拡大もロールバックも行わず、露出割合を維持したまま観察を継続します。十分な標本数において基準を超えた場合は、議論の余地なく停止してロールバックした上で原因を調査します。ただし、個人情報の露出、有害な生成物、法令違反のように1件も許容されない即時中断条件は、標本サイズに関係なく発見次第直ちに停止してロールバックします。どのような条件が即時中断に該当するかも、リリース前に記載しておきます。Google SREは、問題が見られた場合はデプロイを停止してロールバックするか、担当者を呼んで問題を解決するよう述べています。基準を超えた状態で修正したバージョンを直ちに再リリースすることは、検証されていない変更を再び露出させることになります。

ロールバックの方法もリリース前にテストします。フィーチャーフラグをオフにすれば以前の状態に戻るかを確認し、すでに処理された結果（送信されたメッセージ、実行されたツール呼び出し、反映された精算）をどのように修正するかを決めておきます。訂正案内の送信、反対取引による相殺・取消処理、担当者による手動補正のうち、何を誰が行うかまでリリース計画書に記載します。

A/Bテストの条件

A/Bテストは効果を機能に帰属させる最も確実な方法ですが、条件が整っている必要があります。

1. リスクが低いこと。 ユーザーの半数に新案を提示しても問題がない状態でなければなりません。
2. トラフィックが十分であること。 目標指標の差を偶然と区別できるほど標本が蓄積されなければなりません。
3. 目標指標が1つに定まっていること。 結果を見てから指標を選ぶと、偶然の差を効果だと錯覚してしまいます。
4. ガードレール指標が存在すること。 目標指標が改善しても、通報率や返金率が悪化すれば中断します。
5. 無作為に分割すること。 ユーザー自身に選択させると、傾向が異なる集団同士を比較することになります。

Anthropicは、A/Bテストは十分なトラフィックがある場合に大きな変更を検証する方法であると説明しています。トラフィックが不足している場合は、実験の代わりに運用指標、ログの確認、ユーザーインタビューを併せて確認し、結論の確実性を低めに見積もって報告します。

運用指標の階層

運用指標は4つの階層に分けてこそ漏れがなくなります。

システム指標だけを見ていると、捏造された回答を見逃してしまいます。エラーレスポンスなしに、もっともらしい誤答が出力されるためです。Google PAIRガイドが述べる背景エラー、すなわちユーザーもシステムもエラーとして認識できない失敗は、ユーザー行動指標にも捉えられないことがあります。そのため、品質階層の指標、例えば根拠引用の割合や、毎日抽出するサンプルの自動・人手による採点が必要になります。逆に、エージェントが同じツールを繰り返し呼び出した末に最終的に正しい回答を出すような失敗は、品質指標には現れず、リクエストあたりのトークン数といったコスト指標に現れます。

アラート設計

指標は確認する人がいてこそ意味があります。アラートでは3つの事項を定めます。

1. 基準。 どの値を超えたら通知するのか。通常の変動幅を把握し、その外側に設定します。
2. 受信者と対応内容。 誰が受信し、受信したら何をするのか（確認、機能縮小、停止）。
3. 緊急度。 即時対応するもの（サービス障害、個人情報の露出、コスト急増）と、次の営業日に確認するもの（緩やかな品質低下）を分けます。

コストに関しては、アラートだけでは不十分な場合があります。エージェントの繰り返し呼び出しのように、コストが数時間で膨れ上がるインシデントに備え、提供元のコンソールにおける支出限度額のような強制的な上限をあわせて設定します。Claudeのドキュメントでは、組織やワークスペースに設定した支出限度額に達すると、APIがエラーを返すと説明されています。

NIST AI RMFは、運用中のシステムの機能と動作をモニタリングするよう求め（MEASURE 2.4）、導入後モニタリング計画にユーザーや関係者の意見を収集・評価する仕組み、異議申し立てや無効化、システムの廃棄、インシデント対応、復旧、変更管理を含めるよう推奨しています（MANAGE 4.1）。アラートはこの計画の神経網です。アラートが多すぎると誰も見なくなるため、指標ごとに「このアラートを受け取ったら何をするのか」に答えられないのであれば、アラートではなくダッシュボードに配置します。

モデル・プロンプトの変更管理

AI機能は、コードがそのままでも変化します。プロンプトを修正したり、モデルを変更したり、提供元がモデルをリタイアさせたりAPIを変更したりすると、結果が変わります。そのため、プロンプトとモデルの設定もコードと同様に管理します。

1. バージョンを残す。 プロンプト、モデル名、設定をバージョンとして記録し、運用ログにどのバージョンが回答したかを残します。
2. 反映前に回帰評価を実行する。 たった1行の修正でも、別の類型の回答が変わってしまうことがあります。回帰評価セットを用いてケース別に比較を行います。
3. モデルの置き換えでは品質・レイテンシ・コストをあわせて測定する。 同じプロンプトであっても、モデルが変われば結果とコストが変わります。
4. 段階的に反映する。 大きな変更はカナリアリリースで公開します。

モデルのライフサイクルにも備えます。Claudeのドキュメントでは、モデルの状態をActive（完全サポート、推奨）、Legacy（これ以上アップデートされず今後サポート終了の可能性あり）、Deprecated（動作するが非推奨であり、代替モデルとリタイア日が設定されている）、Retired（利用不可、リクエストが失敗する）に分類しています。パブリックモデルはリタイアの少なくとも60日前に通知され、リタイア日よりも十分前に新しいモデルでテストすることを推奨しています。モデルだけではありません。同ドキュメントのパラメータ非推奨表によると、temperature、top_p、top_kといったサンプリングパラメータは2026-10-21のAPIバージョンで削除されており、指定すると400エラーが返されます。またそれ以前のAPIバージョンでも、Claude 4.7以降のモデルにデフォルト値以外の値を渡すと400エラーが発生します。提供元のアナウンスを定期的に確認することも運用業務の一環です。

インシデント対応

AI機能のインシデントは、誤った案内、個人情報の露出、不適切な生成物、コスト急増など多岐にわたります。対応手順は次のとおりです。

1. 拡散を防ぐ。 機能をオフにするか、該当する類型を人間に振り向けるか、以前のバージョンにロールバックします。
2. 影響を受けた人を特定して通知し、是正する。 誤った情報を信じて行動してしまう人が残っている場合は、通知することが最優先です。
3. 原因を修正して復旧する。 原因を究明して修正したバージョンを回帰評価で確認した上で、段階的に再公開します。
4. 記録をレポートにまとめる。 対応中は状況と措置を継続的に記録し、完了後に経緯、影響、原因、対応措置をインシデントレポートとしてまとめます。
5. 振り返りを行う。 個人を責めることなく、寄与要因を中心に分析します。
6. 再発防止策を実行し、確認する。 担当者と期限を定めます。

NIST AI RMFは、インシデントやエラーを影響を受けるコミュニティを含む関係者に通知するよう求めています（MANAGE 4.3）。原因を修正してデプロイしたからといって、インシデント対応が終わるわけではありません。すでに誤った案内を受け取った人が残っているためです。

非難のない振り返り

Google SREは、ポストモーテム（振り返り）を「インシデントとその影響、緩和や解決のために取られた措置、根本原因、再発防止のためのフォローアップ措置を盛り込んだ記録」と定義しています。ポストモーテムを実施する条件の例として、ユーザーに視認できる一定水準以上の障害や品質低下、あらゆる種類のデータ損失、担当者の介入（デプロイのロールバック、トラフィックの迂回など）を挙げています。そして、非難のない振り返りは、個人やチームを責めることなく、インシデントの寄与要因の究明に集中すべきであると強調しています。

AI機能の振り返りにおいて頻出する寄与要因には、次のようなものがあります。プロンプトの変更が回帰評価なしに反映された、評価セットに該当する類型が含まれていなかった、品質指標にアラートが設定されていなかった、レビュアーに根拠が見えていなかった、などです。再発防止策は、こうした原因を的確に標的にしなければなりません。インシデント事例を回帰評価セットに追加し、不足していたアラートを作成し、変更手順を改善します。運用の対話ログを評価セットに組み込む際は、事前に個人情報をマスキングするか匿名化処理を行います。Google SREも、インシデントコマンダーが対応中に生きたインシデントドキュメントを維持し、その記録を振り返りの分析に利用できるよう保存しておくことを推奨しています。

運用データによる改善の優先順位付け

運用データが蓄積されると、修正すべき点が多くなります。改善のためのリソースは限られているため、順序を決めなければなりません。NIST AI RMFは、記録されたリスクの処理優先順位を、影響度、発生可能性、利用可能なリソースや手法に基づいて決定するよう求めています（MANAGE 1.2）。

実務では、失敗の類型ごとに「月間発生件数 × 1件あたりの被害額 × 顧客に実際に届いた割合」を計算します。すでに導入されている統制（検証ステップ、人手によるレビュー）によって除去される分は、最後の項から差し引かれます。

この表では、最も危険に見える「根拠のない案内」よりも、過剰な拒絶への対処が優先されます。ただし、数値だけで判断しない例外もあります。法律・安全上の問題や信頼を大きく損ないかねない類型は、件数が少なくても統制が十分であるかを別途確認します。類型の名称が与える印象と実際の被害を区別することが、この判断の肝要な点です。

段階的リリース計画書

[段階的リリース計画書]
機能とバージョン：
リリース範囲：ユーザー層 / 含める類型 / 除外する類型とその処理ルート
リリース方式：シャドー / カナリア / ベータ / A/B、選択した理由
段階：例）1% → 10% → 50% → 100%（トラフィックとリスクに応じて調整）、段階ごとの最小期間と最小標本数
比較対象：同時期の対照群
中断基準：指標、基準値、判定に必要な最小標本数
ロールバック方法：フラグ、以前のバージョン、すでに処理された結果の処理
運用指標とアラート：システム / 品質 / ユーザー行動 / 事業、受信者と対応内容
変更管理：プロンプト・モデルのバージョン、回帰評価の条件、提供元の告知確認周期
インシデント対応：連絡体制、振り返りの実施条件

さらに深く

指標を変えたいという誘惑

リリース後に目標指標が動かないと、別の指標を探したくなります。「コンバージョン率はそのままだが、おすすめのクリック数は30%増えた。」この報告は嘘ではありませんが、機能が目的を達成したという証拠でもありません。クリックは増えたのに購入がそのままであるなら、おすすめが好奇心を引いただけで役に立っていないという意味かもしれません。

Google PAIRガイドは、短期的に良く見える指標（例えばシェア数）を最適化することが長期的には有害になり得ると警告し、指標が完全に最適化されたときにユーザーや社会に何が起きるかを想像してみるよう勧めています。目標指標とガードレール指標はリリース前に定め、結果が悪ければ指標を変える代わりに原因を探します。指標の変更が正当化されるのは、最初に選んだ指標が目的を測定できていないことが結果とは無関係な根拠によって判明した場合だけであり、その際にも変更した理由を記録します。

静かな品質低下

AI機能の品質は、何も変更しなくても低下することがあります。ユーザー層が広がるにつれて入力の分布が変化し（新しい地域、新しい商品群、新しい表現）、根拠文書が更新されて古い引用が残り、プロバイダーのモデルが変更されます。リリース時点の評価セットはこの変化を認識できません。

静かな低下を捉える方法は3つあります。毎日または毎週、運用ログからサンプルを抽出し、同じ採点方式でスコアリングを行って推移を見ます。入力のタイプ分布をリリース時と比較し、新しいタイプが増加したかを確認します（入力分布の変化は一般にデータドリフトと呼ばれます）。ユーザー行動指標（再生成、オペレーター相談への転換）の傾向を見ます。3つのうちいずれかが動いた場合はログを読み、新たに見つかった失敗事例を評価セットに追加します。

機能を停止する決定

すべてのAI機能が稼働し続けなければならないわけではありません。運用コストが効果を上回ったり、ユーザーが使わなかったり、リスクが制御できなくなったりした場合は、機能を縮小したり停止したりすることも運用の決定事項です。NIST AI RMFは、意図した用途から外れたシステムを代替、廃止、または停止するための仕組みと責任を設けるよう求めています。

機能を停止する際にも計画が必要です。ユーザーに事前に通知し、代替手段を案内し、機能が残したデータ（対話ログ、生成物）をポリシーに従って処理し、なぜ停止したのかを記録します。停止の判断根拠は第1章の「AI適用判断メモ」（課題、処理量、解決策、データ・コスト条件、法的検討、結論）と同じ形式で残しておけば、後で同じアイデアが再び浮上した際に、何が変わっていなければならないのかを把握できます。

実務の場面

めばえバンクの振込問い合わせ相談

インターネット銀行「めばえバンク」は、振込限度額や手数料の問い合わせに回答するAI相談窓口をリリースしようとしています。1日の問い合わせは3万件で、オフライン評価において遮断基準をすべてクリアしました。ただし、海外送金手数料のタイプは基準に達しなかったため対象範囲から外し、既存のオペレーター相談窓口へ回すことにしました。

企画者はカナリアリリースを選びました。結果を顧客が確認し、誤りがあればオペレーターが訂正できるためロールバックが容易であり、実際の顧客による申告率やオペレーター転換率を見る必要があったためです。段階は1% → 10% → 50% → 100%とし、1%の段階では最低3日・対話900件、10%の段階以降は最低3日・対話5,000件以上を判定条件として設定しました。中断基準は「手数料の誤案内申告率が対照群より0.3%p以上高いこと」と「根拠引用のない回答が1%を超えること」でした。同時期に予定されていたアプリのメイン画面リニューアルは、カナリアリリースが完了した後に延期しました。2つの変更が重なると、指標の変化がどちらに起因するのか判断できなくなるためです。

10%の段階の3日目、その段階における累積対話9,000件のうち、根拠引用のない回答が1.6%となり基準を超えました。チームは展開拡大を停止し、機能フラグをオフにしてすべての問い合わせを既存の相談窓口へ戻した上で、原因を調査しました。手数料規定の文書が改定されたことで、以前の文書と新しい文書が同時に検索されていました。1%と10%の段階のログをすべて確認したところ、以前の手数料を案内していた対話が152件あり、チームはそれらの顧客へ訂正の案内を送った後、ドキュメントのインデックスを修正し、回帰評価を経て1%から再開しました。そして振り返りを実施しました。振り返りで出された再発防止策は、「根拠文書の改定時に旧バージョンのインデックスを削除する手順」と「文書改定日を回帰評価の実行条件に追加すること」でした。却下された案は、「プロンプトに新しい文書を優先するよう指示文を追加し、同じ比率ですぐに再開する」というものでした。原因が特定される前であり、検証していない変更を再び公開することになるためです。検索インデックスに残っている古い文書は、プロンプトの指示だけで確実に防ぐこともできませんでした。

夕焼けTVの検索アシスタント運用

動画配信サービス「夕焼けTV」は、AI検索アシスタントの運用を始めて4か月目になります。改善にあたる人員は、次の四半期に2つの課題にしか対応できません。運用データから浮上した候補は5つありました。出演者の名前を誤って関連付けるエラー、成人向けコンテンツが子ども用プロフィールの検索結果に混入するエラー、応答の遅延、検索語を理解できずに回答を拒絶するケース、おすすめ結果が毎回似通ってしまう問題でした。

企画者は、月間件数、1件あたりの被害、実際に顧客へ露出した割合をもとに、月間被害を算出した表を作成しました。回答拒否は月2万件と最も多く、拒絶された後の離脱によって視聴開始数が減少していました。子ども用プロフィールのエラーは月6件でしたが、遮断フィルターをすり抜けて実際に露出したものが2件あり、法律や信頼性の問題に発展する恐れがありました。企画者は、数値の大きさから回答拒否を第1の課題とし、件数は少ないものの統制をすり抜けた子ども用プロフィールのエラーを第2の課題として選びました。すでに統制されているリスクと、実際に破られたリスクを明確に区別した判断でした。

変更管理も見直しました。これまでプロンプトは、担当者が必要に応じて運用環境で修正していました。今後はプロンプトをバージョンとして管理し、毎週火曜日の定期リリースの際のみ、400件の回帰テストスイートを実行して合格したバージョンを10%のカナリアリリースで公開することにしました。モデルプロバイダーのサポート終了告知は毎月第1週に確認し、リタイア告知が出された場合はその週に代替モデルで全体評価を実行するというルールも追加しました。

間違えやすいポイント

1. 「オフライン評価に合格したのだから、すぐに全ユーザーへリリースしてもよい。」 実際のユーザーや入力は評価セットとは異なります。露出を制限して測定しながら拡大していきます。
2. 「カナリアリリースはリリース前とリリース後を比較すればよい。」 時間の経過は指標を変化させる最大の要因の1つです。同時期の対照群と比較します。
3. 「中断基準は結果を見てから決めればよい。」 結果を見た後に設定した基準は、結果に合わせて都合よく調整されてしまいます。リリース前に具体的な数値と最小サンプル数を定めます。
4. 「基準を超えたなら、修正してすぐに再リリースすればよい。」 まずは停止して元の状態に戻し、原因を特定します。検証されていない変更を再び公開してはいけません。
5. 「複数の変更を同時に段階的リリースすれば時間を節約できる。」 どの変更に効果があったのか特定できなくなります。一度に実行するカナリアリリースは1つだけにします。
6. 「エラー応答と遅延だけを見ていれば運用状況を把握できる。」 AIの失敗はエラーを発生させずに起こります。品質指標とユーザー行動指標が必要です。
7. 「サポート終了となったモデルは、リタイア日以降も動作が遅くなるだけで動き続ける。」 リタイアしたモデルへ送られたリクエストは失敗します。リタイア日よりも十分前に代替モデルへの移行を評価します。
8. 「原因を修正してデプロイしたのだから、インシデント対応は完了した。」 誤った案内を受けたユーザーへ通知し、記録を残し、再発防止策を実行して初めて完了となります。

ひと目でわかるまとめ

公式ドキュメントで確認する

• Google SRE Workbook — Canarying Releases：カナリアの定義、対照群との比較、指標の選定、期間と規模、一度に1つ。
• Google SRE Book — Postmortem Culture: Learning from Failure：振り返りの定義と条件、非難のない振り返り。
• Google SRE Book — Managing Incidents：インシデント対応中に更新し続ける生きたドキュメント。
• AWS — Amazon SageMaker AI shadow tests：シャドウテストの仕組み。
• Claude Docs — Model deprecations：モデルのライフサイクル、リタイア告知期間、APIパラメータのサポート終了。
• Anthropic — Demystifying evals for AI agents：自動評価、運用モニタリング、A/Bテスト、人間によるレビューの組み合わせ。
• NIST AI RMF — Core：MANAGE 1.2（優先順位）、2.4（代替・廃止・停止）、4.1（デプロイ後のモニタリング）、4.3（インシデント通知）。
• Google PAIR Guidebook — User Needs + Defining Success：報酬関数と短期的な指標の最適化がもたらすリスク。

セルフチェック

5-1. Google SREがカナリア指標に求める3つの性質を記述してください。

5-2. シャドウテストで測定できないものは何であり、それが必要な場合はどのようなリリース方式を用いるべきか答えてください。

5-3. 中断基準に最小サンプル数を併記しなければならない理由を説明してください。

5-4. 運用指標の4つの層を記述し、でっち上げられた回答がエラー応答率として検知されない理由を説明してください。

5-5. Claudeドキュメントにおけるモデルライフサイクルの4つの段階を記述し、最後の段階でリクエストがどうなるかを記述してください。

5-6. インシデント対応の6つの段階を順番に記述してください。

5-7. 月50件、1件あたりの被害4万ウォン、検証段階で90%が遮断されるタイプと、月1,200件、1件あたりの被害2,000ウォン、遮断装置がないタイプがあります。月間被害額で比較するとどちらが先になるか答えてください。

5-8. （設計）現在担当しているAI機能の段階的リリース計画書を本章の様式で作成し、2つの中断基準に最小サンプル数を付記してください。

実習課題