集客AI · Instagram自動化 — 要件定義・設計書

要件定義 & システム設計書(実装向け)

代理店向け事業戦略(鰻人モデルケース)とUX分析を前提に、素材投入→自動編集→多言語化→エンドユーザー承認→投稿を一連で完結させる制作エンジンを、エンジニアが実装できる粒度で定義する。操作者はA(PC・制作)とB(スマホ・確認)に分離し、承認者はエンドユーザー。統制原則は「計算=script/判断=AI/実行=人の承認後」。

v0.1 draft / scope: MVP(鰻人パイロット)/ 前提: 自社運用・白label(黒子)/ infra: Git→Cloudflare

目次

  1. 目的・スコープ
  2. 用語・前提
  3. 機能要件(FR)
  4. 非機能要件(NFR)
  5. システムアーキテクチャ
  6. データモデル(スキーマ)
  7. ジョブ・パイプライン設計
  8. リール制作サブパイプライン
  9. 勝ちパターン×店舗別学習(9:1)
  10. Meta API 連携設計
  11. 内部API・インターフェース
  12. インフラ・デプロイ
  13. 受け入れ基準・未決事項
01

目的・スコープ

目的:代理店が外注している「制作の一段」を、品質×速度のAI制作エンジンで白label置換する。MVPは鰻人(うなぎ専門店)を証明台に、一連の流れを実際に完結させる。素材はクライアントのテスト素材が主(我々のデフォルト素材から生成・整形はしない)。勝ち筋はリサーチ→分析でAIが仮説する(v0.2で詳細化)。

MVPスコープ(やる)

  • 1エンドクライアント(鰻人)× Instagramリール
  • 4言語(日/英/韓/繁体中)=字幕+TTSナレーション
  • ジョブ:依頼→素材解析→自動編集→多言語→人QA→投稿→分析を1本通す
  • 勝ち筋はリサーチ→分析でAIが仮説(3幕は現状仮説)+店舗別スタイル(特徴DB)※v0.2参照
  • 承認UI(プレビュー→承認/差戻し)

MVP後(やらない)

  • 代替ツールの選定・切替機能
  • 素材供給体制(当面テスト素材)/DM自動返信
  • マルチテナントSaaS・代理店セルフサーブ・課金基盤
  • 全自動動画生成、多アカウント一斉展開
02

用語・前提

用語意味
エンドクライアント飲食店(鰻人・ジンミダン)。証明の舞台。素材(mov)の供給元
代理店主顧客。白labelで制作エンジンを使う(MVPでは未接続、データモデルには用意)
勝ち型テンプレ実績で勝った投稿の型(フック・3幕構成・shot-list・字幕・音)
特徴DB(StoreFeature)店舗ごとの独自要素。パクリ9割に対し独自1割の源泉
操作者A(作る人)代理店の運用担当(または社内)。PCで制作・比較・確認依頼を行う
操作者B(確かめる人)店舗オーナー。スマホで数秒見て2択で承認/指摘する
承認ゲート投稿など後戻り不可の行為の前に必須で挟む承認。承認者はエンドユーザー(A または B)
確認依頼AがBへ送るリンク1つの依頼。開封状況が送り手に見える
司令塔オーケストレーター。現状Claude Code、製品化はClaude Agent SDK

統制原則(全体に適用)

  • 計算=script:集計・整形・KPIなど決定的処理はコード(再現性・監査性)
  • 判断=AI:型選択・生成・要約・ローカライズなど曖昧な選択はAI(Claude)
  • 実行=人の承認後:投稿・送信・出稿は承認ゲート通過後のみ
03

機能要件(FR)

各要件に受け入れ基準を付す。MVPは FR-01〜FR-10 を必須、FR-11/12 は最小実装。

ID要件詳細受け入れ基準
FR-01依頼受付クライアント・対象言語・本数・テンプレを指定してジョブ生成ジョブが status=received で作成され、必須項目が検証される
FR-02素材取込mov/画像をアップロードしAssetとして登録(ストレージ格納)公開URLが払い出され、Jobに紐付く
FR-03素材解析・QCVisionでシーン分類・内容タグ(例:unagi/蒲焼/炭火)・品質チェック・使用可能尺の抽出各Assetにvision_tags・shot_role・qc_statusが付与される
FR-04戦略・型選択業種と特徴DBから勝ち型テンプレを選択し、独自要素を1割抽出(9:1)compose_brief(template_id+applied_original_elements)が生成される
FR-05自動編集(複数案)clips+仮説→9:16リール/4:5ポストを複数案生成(1案提示にしない)1ジョブにつき2案以上のRenderが生成され、差分が比較できる
FR-06多言語化日/英/韓/繁中の字幕・オーバーレイ・TTSナレーションを差し替え4言語分の ReelRender が揃う(文字化けなし)
FR-07キャプション生成型+言語+独自要素からキャプション・ハッシュタグを生成言語別キャプションが Post ドラフトに保存される
FR-08承認(エンドユーザー)プレビュー→承認/差戻し。承認ゲート。承認者はA または B承認なしに公開へ進めない。誰がいつ承認したかがApprovalに残り画面に表示される
FR-13確認依頼フローAがBへ確認リンクを送信。開封/視聴状況をAが確認。催促は自動リンク1つでBが開けて即再生。開封状況がAの画面に反映される
FR-14選択肢式の指摘差戻し理由を候補から選択(映り/情報が違う/表現が強い等)。自由記述は任意Bが記述なしで差戻しでき、理由が構造化データで残る
FR-15対訳の確認原文(日本語)と訳を対応表示し、確認済みの印と確認者を記録言語ごとに対訳が並び、確認済み状態が可視化される
FR-16成果の言い換え表示専門用語を使わない表現へ翻訳し、前回との比較を添えるB向け画面にreach等の語が出ず、前回比が表示される
FR-17スマホからの素材投入Bがその場で撮影/選択して送信。形式を問わず受けるスマホから送った素材がAssetとしてジョブに紐づく
FR-18契約前トライアル入口登録・契約を挟まず素材を渡し、試作を見られる導線未登録状態で素材投入→試作閲覧まで到達できる
FR-19次の一手の提示実績を次の候補生成に反映し「次はこれ」を提示実績反映後、次案の推奨がAの画面に表示される
FR-20店舗コンテキストの明示常にどの店舗の作業中かを表示し、素材・成果物を店舗単位で隔離画面上で店舗が常時視認でき、他店舗の素材が混ざらない
FR-09投稿・予約Meta Graph APIでリール公開/予約(承認後のみ)ig_media_id・permalinkが保存され status=published
FR-10分析取得Insights取得(reach/plays/保存/プロフ訪問/海外リーチ比)Post に日次でInsightが記録される
FR-11ナレッジ更新実績→勝ち型テンプレのスコア更新・店舗別ルール更新(当初手動トリガ)performance_score/KnowledgeRuleが更新できる
FR-12オペログ各ステージの時刻・担当・処理・コストを記録(監査)1ジョブの全ステージが時系列で追える
04

非機能要件(NFR)

ID分類要件
NFR-01統制実行(投稿/送信)は承認ゲート通過後のみ。計算はscript・判断はAIに分離
NFR-02安全API はGET中心、書込は承認後。エージェントにターン上限・スペンド上限・最小権限
NFR-03信頼性各ステージは冪等(idempotency key)+リトライ可能。長時間処理は非同期ジョブ
NFR-04監査全ステージの入出力・ツール・コストをOperationLogに保存
NFR-05拡張性各ステージ・各モデル/ツールはアダプタで疎結合。差し替え・追加が容易
NFR-06スケール将来のマルチテナント(代理店/店舗単位のデータ分離)を壊さないスキーマ設計
NFR-07デプロイGit push→自動デプロイ(Cloudflare)。CI/CDでテスト→本番。IaCで再現可能
NFR-08レート/コストMeta投稿レート(~100/24h/アカ)を管理。生成AIコストを可観測化
NFR-10UI原則説明せず見せる/作らせず選ばせる/言語化を強いない/勝手に進まない/1画面1判断(特にB)。詳細編集は初期画面に出さず、要求時に展開
NFR-11画面分離A=PC(情報量多・制御)、B=スマホ(情報量最小・2択)。同じ機能を両方に載せない
NFR-12内部機能の露出範囲エージェント名編集・API選択・ワークフロー設定は社内/A限定。Bには出さない
NFR-09権利・規約素材/肖像/音楽ライセンス、景表法・薬機法、Metaポリシー遵守のチェック項目
05

システムアーキテクチャ

レイヤードに分離。司令塔(オーケストレーター)がジョブを制御し、各処理はアダプタ経由で外部AI/ツール/APIを呼ぶ。

# レイヤー構成
[UI層]        承認UI / 依頼UI / ジョブ実行ビュー / オペログ    (Cloudflare Pages)
     |  REST/WebSocket
[API層]       Job API / Approval API / Webhook受信            (Workers / Container)
     |
[オーケストレーター] 司令塔 = Claude Code(現) -> Agent SDK(製品)
     |   ステージ実行・状態遷移・承認待ち・リトライ
     |--- サブエージェント(部署): 解析 / 制作 / 多言語 / 分析
[アダプタ層]   モデル/ツール/APIを抽象化(差し替え可能)
     |--- Vision(Claude/Gemini)  --- 動画編集(Shotstack/Creatomate)
     |--- LLM(Claude)            --- 画像(GPT Image2/Nano Banana/Seedream)
     |--- TTS(ElevenLabs)        --- Meta Graph/Insights/Messaging API
[データ層]     Postgres(業務データ) / R2(メディア) / Queue(非同期) / KVS(状態)

設計方針

  • ステージは「入力→出力」の契約で疎結合(あるステージの内部実装/モデルを差し替えても他に影響しない)
  • 外部依存はすべてアダプタ越し(ベンダーロックイン回避=NFR-05)
  • 重い処理(動画レンダリング・エージェント実行)は非同期ワーカー。Workersの実行時間制約を超える処理はコンテナ基盤へ
06

データモデル(スキーマ)

PostgreSQL想定。将来のマルチテナントに備え agency_id / client_id を保持(MVPでは agency_id は null 可)。

agency(              -- 代理店(白label顧客・将来)
  id uuid pk, name text, brand_logo_url text, contact jsonb, created_at timestamptz)

client(              -- エンドクライアント(店舗)
  id uuid pk, agency_id uuid null fk->agency,
  name text, cuisine_type text,           -- 業種: 'unagi'
  google_place_id text,
  target_languages text[],                -- ['ja','en','ko','zh-Hant']
  ig_account_id text,                      -- 投稿先IGアカウント(誰名義かは未決)
  created_at timestamptz)

brand_profile(       -- ブランドの声・世界観
  id uuid pk, client_id uuid fk->client,
  brand_voice text, world_view text,
  signature_menus jsonb,                   -- 蒲焼/白焼/ひつまぶし…
  ng_list jsonb, updated_at timestamptz)

store_feature(       -- 特徴DB = 独自1割の源泉
  id uuid pk, client_id uuid fk->client,
  feature_tags jsonb,                      -- ['三度の食べ方','炭火','老舗']
  strengths jsonb, unique_elements jsonb,  -- 独自要素の候補
  discovery_gap text, updated_at timestamptz)

template(            -- 勝ち型テンプレ / WinningPattern
  id uuid pk, name text, vertical text,    -- 'unagi'/'yakiniku'…
  structure jsonb,                         -- 3幕: hook/guide/info
  shot_list jsonb,                         -- 必要ショット定義
  caption_template text, hashtag_set jsonb,
  subtitle_style jsonb, music_style text,
  performance_score numeric, scope text,   -- global/vertical/client
  client_id uuid null, updated_at timestamptz)

asset(               -- 素材(clip/photo)
  id uuid pk, client_id uuid fk->client,
  type text,                               -- 'video'/'photo'
  storage_url text, public_url text, duration_ms int,
  vision_tags jsonb,                       -- {scene, foods:['unagi'], ...}
  shot_role text, quality_score numeric,
  qc_status text,                          -- pending/ok/rejected
  created_at timestamptz)

job(                 -- 依頼(1リクエスト)
  id uuid pk, client_id uuid fk->client,
  requested_by text, target_languages text[], count int,
  template_id uuid null fk->template,
  compose_brief jsonb,                     -- 型+独自要素(9:1)
  status text,                             -- enum(下記)
  priority text, created_at, updated_at timestamptz)
  -- status enum: received|setup|analyzing|strategizing|producing|
  --   localizing|awaiting_qa|approved|publishing|published|analyzing_insights|failed

job_stage(          -- ステージ実行ログ(冪等/リトライ)
  id uuid pk, job_id uuid fk->job, stage text,
  status text,                             -- pending/running/done/failed/waiting_approval
  idempotency_key text, input jsonb, output jsonb,
  tool text, cost numeric, error text,
  started_at, finished_at timestamptz)

reel_render(        -- 言語別の完成リール
  id uuid pk, job_id uuid fk->job, language text,
  video_url text, duration_ms int, thumbnail_url text,
  subtitle_track jsonb, voiceover_url text,
  spec jsonb,                              -- {ratio:'9:16',codec:'h264'}
  status text, created_at timestamptz)

approval(           -- 承認ゲートの記録(承認者=エンドユーザー)
  id uuid pk, job_id uuid, reel_render_id uuid,
  reviewer text, reviewer_role text,       -- 'agency_staff'(A) / 'store_owner'(B)
  decision text,                           -- approve/reject/revise
  issue_codes text[],                      -- 選択肢式の指摘: looks/info_wrong/tone_strong…
  comment text,                            -- 自由記述は任意
  target_stage text, created_at timestamptz)

review_request(     -- 確認依頼(A -> B、リンク1つ)
  id uuid pk, job_id uuid, candidate_id uuid,
  sent_to text, link_token text, sent_at timestamptz,
  opened_at timestamptz, viewed_at timestamptz,
  reminder_count int, status text)         -- sent/opened/answered

candidate(           -- 複数案(1案提示にしない)
  id uuid pk, job_id uuid, reel_render_id uuid,
  variant_label text, diff_meta jsonb,     -- 案ごとの差分(フック/尺/構成)
  selected boolean, created_at timestamptz)

translation_pair(   -- 原文↔訳の対応(多言語の確認)
  id uuid pk, reel_render_id uuid, language text,
  source_text text, translated_text text,
  verified boolean, verified_by text, verified_at timestamptz)

post(                -- 公開投稿
  id uuid pk, job_id uuid, reel_render_id uuid,
  ig_account_id text, ig_media_id text, permalink text,
  caption text, scheduled_at, published_at timestamptz, status text)

insight(            -- 投稿実績(日次)
  id uuid pk, post_id uuid fk->post, captured_at timestamptz,
  reach int, plays int, saves int, avg_watch_ms int,
  profile_visits int, overseas_reach_ratio numeric, dm_count int)

knowledge_rule(     -- 学習ルール(勝ち型の根拠)
  id uuid pk, scope text, vertical text, client_id uuid null,
  language text, rule jsonb, evidence_post_ids uuid[],
  confidence numeric, updated_at timestamptz)

operation_log(      -- 監査ログ
  id uuid pk, job_id uuid, actor text, action text,
  tool text, payload jsonb, ts timestamptz)
07

ジョブ・パイプライン設計

司令塔がステージを順に実行。種別:計算判断実行。★=承認ゲート。各ステージは job_stage に記録し、失敗時は当該ステージから再開。

#ステージ種別入力 → 出力担当/ツール
1received判断依頼 → Job(検証済)API+司令塔
2setup計算Job → 作業フォルダ・client-profile初期化case-setup script
3analyzing判断Asset → vision_tags・shot_role・qcVision(Claude/Gemini)
4strategizing判断業種+特徴DB → compose_brief(型9:独自1)Claude+template+store_feature
5producing判断clips+brief → 9:16動画(基準言語)動画編集API
6localizing判断動画+言語 → 4言語 reel_render+captionClaude+字幕+TTS
7awaiting_qa実行前プレビュー → approve/revise/reject承認UI
8publishing実行承認済 → IG公開/予約Meta Graph API
9analyzing_insights計算media_id → Insight(日次)Insights API+集計
10knowledge_update判断実績 → score/rule更新Claude+DB(手動トリガ)

状態遷移・エラー処理

  • 各ステージ開始時に job_stage を running で記録、idempotency_key で二重実行防止
  • 失敗は status=failed+error記録 → 同一ステージから再開(前段の output を再利用)
  • awaiting_qa は人の入力待ちで停止。revise は指定ステージへ差戻し(例:producingへ)
08

リール制作サブパイプライン(ステージ5-6の詳細)

"生成"でなく実素材のテンプレ自動編集。鰻人の勝ち型=「無音で伝わる寄り(シズル)」→「食べ方ガイド(三度の食べ方)」→「予約・立地」の3幕。

# R1 shot-list(templateから): 必要ショットと役割
required_shots = [exterior, dish_closeup, sizzle, pour/plating, reaction]
# R2 clip解析: asset.vision_tags と shot_role をマッチング(不足は警告)
# R3 自動編集(動画API): テンプレJSONにclipを流し込む
timeline = {
  ratio:'9:16', fps:30,
  scenes:[ {role:'sizzle', clip:asset_a, dur:1800, text_overlay:hook},
           {role:'guide',  clip:asset_b, dur:6000, captions:lang},
           {role:'info',   clip:asset_c, dur:3000, text:reserve+map} ],
  music: template.music_style, brand: client.logo }
render(timeline) -> mp4(9:16, h264/aac, 5-90s)
# R4 多言語: 字幕トラック+TTSを言語ごとに差し替えて再レンダ
for lang in ['ja','en','ko','zh-Hant']:
    subtitles = translate(script, lang)         # Claude(文化適応)
    voiceover = tts(script, lang)               # ElevenLabs(任意)
    reel_render[lang] = render(timeline + subtitles + voiceover)
# R5 人QA -> 承認後に確定・書き出し

ツール候補(アダプタで抽象化)

  • 動画編集:Shotstack / Creatomate / CapCut(Jianying) API / 自前(FFmpeg/Remotion)
  • 字幕:Submagic / OpusClip / 自前(Whisper+焼込) TTS:ElevenLabs / OpenAI TTS
  • 静止画(サムネ/カルーセル):GPT Image 2 / Nano Banana Pro / Seedream(中韓文字)
09

勝ちパターン × 店舗別スタイル学習(パクリ9:独自1)

再現性(勝てる型)と独自性(その店らしさ)を両立。ステージ4で compose_brief を作る際のロジック。

# 入力: client, vertical, store_feature, 勝ちtemplate候補
def build_compose_brief(client, vertical):
    tmpl = pick_template(vertical, scope in [client, vertical, global])  # 9割=型
    # 独自1割: 特徴DBから、その店ならではの要素を1-2個レコメンド/抽出
    originals = recommend_originals(          # Claude
        store_feature.unique_elements + store_feature.feature_tags,
        constraint = "テンプレの3幕を壊さず、hook/captionに1割だけ差し込む")
    return {template_id: tmpl.id,
            base_structure: tmpl.structure,   # 90%そのまま
            applied_originals: originals,      # 10%差し込み
            ratio: "9:1"}
# 学習ループ: 投稿実績 -> スコア更新 -> 店舗専用の勝ち型が育つ
on insight_captured(post):
    update template.performance_score (by reach/save/来店反応)
    upsert knowledge_rule(scope='client', client_id, rule=勝ち要因)
    # 次回 pick_template は client scope を優先 = その店専用に賢くなる

ポイント

  • 独自要素は「特徴DB」由来に限定=根拠のあるオリジナリティ(ハルシネーションでない)
  • 差し込みは hook とキャプションに限定し、勝ち型の骨格(3幕・尺)は崩さない
  • 実績が溜まるほど client スコープの勝ち型が優先され、店舗専用に最適化される
10

Meta API 連携設計(ステージ8-9)

リールは公式 Content Publishing で投稿可能。動画は公開URLでホストし、コンテナ生成→処理完了→publishの3手。

# 投稿(Reels)
1) POST /{ig_user_id}/media
     { media_type:'REELS', video_url:, caption, share_to_feed:true }
   -> { id: creation_id }
2) poll GET /{creation_id}?fields=status_code   # 指数バックオフ, FINISHEDまで
3) POST /{ig_user_id}/media_publish { creation_id }  -> { id: media_id }   # 承認後のみ
4) GET /{media_id}/insights?metric=reach,plays,saved,total_interactions,...

# 制約
- 動画: 9:16 / 5-90秒 / H.264+AAC / 公開URL必須
- レート: ~100投稿/24h/アカウント(新規は低め)→ 1日1-3本推奨
- 要件: Business/Creator + FBページ + アプリ審査(instagram_content_publish)
- DM(後): 24h枠 / ~200件/時 / Webhookはレート非消費

実装上の注意

  • publish は承認ゲート(Approval=approve)後にのみ発火(NFR-01)
  • status_code ポーリングはタイムアウト・失敗時リトライを設計(NFR-03)
  • 投稿先アカウント(代理店名義 or クライアント名義)とアプリ審査状態は未決(→13章)
11

内部API・インターフェース(例)

UI↔バックエンドの契約。REST想定。ステージ進行はイベント/ポーリングで反映。

POST   /jobs                      # 依頼作成
       req: {client_id, target_languages[], count, template_id?}
       res: {job_id, status:'received'}
POST   /jobs/{id}/assets          # 素材添付(署名付きURLでアップロード)
GET    /jobs/{id}                 # 状態+stages+reel_renders
       res: {status, stages:[{stage,status,...}], renders:[{language,video_url}]}
POST   /jobs/{id}/approve         # 承認ゲート(承認者=A または B)
       req: {candidate_id, decision:'approve|revise|reject', issue_codes[], comment?, target_stage?}
POST   /jobs/{id}/review-requests # A -> B へ確認依頼(リンク1つ)
       req: {candidate_id, send_to}
       res: {review_request_id, link_url}
GET    /review/{token}            # B用・未ログインで即再生できる確認画面
       res: {video_url, store_name, is_prepublish:true, issue_options[]}
POST   /review/{token}/answer     # B の2択回答
       req: {decision:'ok|issue', issue_codes[], comment?}
GET    /jobs/{id}/candidates      # 複数案と差分
GET    /jobs/{id}/translations    # 原文↔訳の対応・確認済み状態
POST   /trials                    # 契約前トライアル(登録を挟まない入口)
POST   /jobs/{id}/publish         # 承認済のみ許可。予約可
       req: {reel_render_ids[], scheduled_at?}
GET    /jobs/{id}/insights        # 実績
POST   /webhooks/meta             # コメント/DM受信(後)
POST   /webhooks/render           # 動画レンダ完了通知
12

インフラ・デプロイ

現状のGit→Cloudflare運用を踏襲し、スケール前提・自動デプロイ。

要素採用(候補)備考
UI/承認画面Cloudflare PagesGit push で自動デプロイ
API/オーケストレーターCloudflare Workers / 重処理はコンテナ基盤Agent SDK常駐・動画レンダは実行時間制約に注意→ワーカー/コンテナ
メディアCloudflare R2Meta要件の公開URLを払い出し
キューCloudflare Queues非同期ジョブ・リトライ
DBマネージドPostgres(Neon / Supabase)業務データ
CI/CDGit連携(テスト→デプロイ)ステージング→本番、IaCで再現

司令塔の製品化

  • 現状:Claude Codeで対話的に実装・検証(自社運用)
  • 製品化:同ロジックを Claude Agent SDK へ移植(Skills/MCP/hook継承・書き直し不要)。ヘッドレスでバックエンド常駐。部署=サブエージェント
  • ガードレール:ターン上限・スペンド上限・最小権限・承認ゲート(NFR-02)
13

受け入れ基準・未決事項

MVP受け入れ基準(鰻人パイロット)

  • 鰻人の実素材から、勝ち型3幕のリールを4言語(日/英/韓/繁中)で生成できる(字幕+TTS、文字化けなし、9:16/5-90s)
  • ジョブが依頼→解析→編集→多言語→人QA→投稿→分析を一連で完走する
  • 承認ゲートを通らずに公開されないことを確認(承認者=エンドユーザー、証跡が残る)
  • 複数案が提示され、比較して選べる
  • Aが確認依頼を送り、Bがスマホで即再生→2択→選択肢式の指摘まで一往復で完了する
  • 原文↔訳の対応表示で、多言語の確認ができる
  • 公開後にInsight(reach/海外リーチ比/保存/プロフ訪問)が取得できる
  • 1本あたり制作時間(B/A)が計測でき、"見せられる1枚"(実物4本+数字+工数圧縮)が出力できる

未決事項(着手前に確定)

  • 投稿アカウント名義:代理店名義かクライアント名義か。Metaアプリ審査・ビジネス認証の状態(知人からのAPI共有見込みを確定)
  • 鰻人パイロット合意:KPI・素材供給範囲・掲載許諾・対象言語の主軸・見せ場メニュー
  • マネタイズ:スポット単価/月額/レベニューシェア(実装は課金非依存で進められる)
  • ツール確定:動画編集・字幕・TTSの第一候補をMVP用に1つ選定(切替はMVP後)