WEB問題集
小売企業のアナリストが、過去2年分の売上データ（BigQueryに格納済み、約500GB）を用いて翌月の売上を予測するモデルを最短で構築したいと考えています。SQLは扱えますがPythonでのMLパイプライン構築経験はありません。最も適切なアプローチはどれですか。
解説
正解の根拠
SQLだけを扱えるアナリストが、BigQuery に格納済みの約500GBのデータから翌月の売上を最短で予測するには、データを動かさずクエリだけで学習できるBigQuery MLが要件に合致します。時系列予測ではCREATE MODEL文でmodel_type='ARIMA_PLUS'とtime_series_timestamp_col、time_series_data_colを指定するだけでモデルが学習され、トレンドと季節性の分解、欠損値の補間、外れ値の処理、祝日効果の考慮までが内部で自動的に行われます。予測はML.FORECASTで予測値と予測区間として取得でき、エクスポート工程も学習基盤の構築もPythonの実装も不要です。
| 観点 | BigQuery ML ARIMA_PLUS |
|---|---|
| 必要スキル | SQLのみ |
| データ移動 | 不要（BQ内で完結） |
| 用途適合 | 時系列予測に最適化 |
不正解の理由
- A: TensorFlowでのカスタム実装はPython経験必須で、最短要件に反します。
- C: Pipelines構築は学習コストが高く、SQLのみのアナリストには過剰です。
- D: データのエクスポート工程が不要であり、表形式AutoMLは時系列特化ではありません。
あなたはBigQuery MLでロジスティック回帰モデルを学習しました。学習済みモデルを使い、新しい顧客テーブル new_customers に対してチャーン確率を予測するために実行する関数として正しいものはどれですか。
解説
正解の根拠
ML.PREDICT は学習済みモデルと入力テーブルを受け取り、行ごとにモデルを適用して予測結果を列として返す推論用の関数です。ロジスティック回帰では予測ラベルの列に加えて、各クラスの確率を格納した predicted_<label>_probs が返るため、チャーン確率をそのまま取り出せます。入力側は学習時と同じ名前の特徴量列を持っていればよく、SELECT * FROM ML.PREDICT(MODEL my_model, TABLE new_customers) と書くだけで、データを BigQuery の外へ出さずに新しい顧客テーブル全体を一括で推論できます。
| 関数 | 用途 |
|---|---|
| ML.PREDICT | 分類・回帰の推論 |
| ML.FORECAST | 時系列予測専用 |
| ML.EVALUATE | モデル精度評価 |
不正解の理由
- A: ML.FORECAST は ARIMA_PLUS などの時系列モデル専用で、ロジスティック回帰モデルには適用できません。
- C: ML.EVALUATE は正解ラベルを含むデータからログ損失や AUC などの評価指標を返す関数で、行ごとの予測値は得られません。
- D: BigQuery ML の説明機能は ML.EXPLAIN_PREDICT や ML.GLOBAL_EXPLAIN として提供され、返るのは特徴量の寄与度です。
ある運送会社が、商品画像から損傷の有無を自動で判別したいと考えています。社内にはMLエンジニアがおらず、ラベル付き画像が約2000枚あります。最も短期間に高精度モデルを得る方法はどれですか。
解説
正解の根拠
Agent Platform の AutoML 画像分類は、ラベル付き画像をアップロードして学習を実行するだけで、モデル アーキテクチャの選択とハイパーパラメータの探索をマネージドに行います。内部で転移学習が使われるため、数千枚規模のデータでも実用的な精度に到達しやすく、損傷あり・なしという独自のラベル体系をそのまま学習できます。学習後は混同行列や適合率・再現率の確認、エンドポイントへのデプロイまでコンソールの操作で完結するので、ML エンジニアが不在の組織でも短期間で判別モデルを本番に載せられます。作業として必要なのは損傷あり・なしのラベル付けだけで、モデルのコードを書く工程は発生しません。
| 選択肢 | 適合性 |
|---|---|
| AutoML Vision | カスタムラベル対応・ノーコード |
| Vision API | 事前定義ラベルのみ |
不正解の理由
- A: スクラッチ学習はアーキテクチャ設計から学習の安定化まで専門知識と長い開発期間を要し、社内に経験者がいない状況では要件に合いません。2000 枚規模では事前学習なしに十分な精度も得にくいです。
- B: Vision API が返すのは汎用的な事前定義ラベルで、損傷の有無という独自の判定基準は学習していません。カスタマイズせずに使う限り、求める分類そのものを出力できません。
- C: 損傷の判別には画素が持つ形状や質感の情報が必要です。メタデータの数値統計量だけを入力にすると判断材料が欠落し、ロジスティック回帰でも十分な精度に届きません。
BigQuery MLで CREATE MODEL を実行する際、モデルの種類を指定するオプションとして正しいものはどれですか。
解説
正解の根拠
BigQuery MLのCREATE MODEL構文では、モデル種別をOPTIONS句のmodel_typeに指定します。例：CREATE MODEL `ds.m` OPTIONS(model_type='LOGISTIC_REG') AS SELECT ... のように記述します。
| 句 | 役割 |
|---|---|
| OPTIONS | モデル種別やハイパーパラメータの指定 |
| AS SELECT | 学習データのクエリ |
不正解の理由
- A: PARAMSはBigQuery MLの構文ではなく、エラーになります。
- C: WITH句はCTE用であり、モデル種別の指定には使えません。
- D: USING MODEL TYPEという構文はBigQuery MLには存在しません。
顧客サポートチームが、問い合わせメール文面を「請求」「技術」「解約」の3カテゴリへ自動分類するモデルを内製したいと考えています。学習用にラベル付きメールが約5000件あります。コーディング工数を最小化したいとき、どのサービスが最適ですか。
解説
正解の根拠
Agent Platform の AutoML テキスト分類は、ラベル付きテキストを CSV や JSONL で読み込ませるだけで、モデル構造の選定、学習、ハイパーパラメータ調整、評価までをマネージドに実行します。「請求」「技術」「解約」といった自社定義のラベルをそのまま学習対象にでき、約 5000 件という規模は AutoML で学習を回すのに十分な量です。学習後はコンソール上の操作で Endpoint にデプロイして予測を呼び出せるため、モデルコードも学習インフラの構築も不要です。独自ラベルへの対応とコーディング工数の最小化という二つの要件を同時に満たせるのはこの選択肢だけであり、内製の初期投資を最も小さくできます。精度はラベル付きデータの質と量に依存するため、手元の約 5000 件を追加実装なしにそのまま活かせる点も有利です。
選択肢比較
| 選択肢 | 方式 | 独自ラベル | コード量 |
|---|---|---|---|
| C | AutoML テキスト分類 | 可 | ほぼ不要 |
| A | Natural Language API のエンティティ抽出 | 不可（事前定義） | 少 |
| B | 翻訳＋ルールベース | 規則を都度作成 | 継続的に大 |
| D | カスタム トレーニング | 可 | 大 |
不正解の理由
- A: エンティティ抽出は文中の人名や組織名などの語句を取り出す機能で、文書全体を任意のカテゴリへ割り当てる処理ではありません。返るラベル体系も事前定義のため、自社の 3 カテゴリを表現できません。
- B: 翻訳とキーワード規則の組合せは、表現の揺れや新しい言い回しが現れるたびに人手で規則を追加し続ける必要があります。手元にある 5000 件の教師データを精度向上に活かせない点でも合理的ではありません。
- D: カスタム トレーニングでのスクラッチ構築は、前処理、モデル定義、学習ループ、評価をすべて自分で実装することになります。精度は追い込めますが、コーディング工数を最小化したいという前提条件に正面から反します。