この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、公開後の更新が止まりかけている運営担当
読了時間: 約14分
Shopifyストアの公開日は、制作の終わりではあっても運営の始まりです。ところが公開の翌月によくあるのは、新商品が数週間登録されないまま、トップのバナーは公開時のキャンペーンのまま、ブログは「オープンしました」の1本きり——という状態です。
原因は、担当者のやる気でも制作会社の手抜きでもありません。「誰が、何を、どの頻度で更新するのか」を公開前に決めていないからです。決めていないと、更新作業は「気づいた人が、手が空いたときに」やるものになります。そして誰の手も空かない。
この記事では、Shopifyで発生する更新作業を洗い出したうえで、社内でやる範囲と外注する範囲をどう分けるか、更新担当をどう割り当てるか、引き継ぎのために何を用意しておくかを、制作側の判断軸で整理します。アプリ紹介ではなく、体制の設計図です。
Shopifyの更新作業は「4つの層」に分かれる
「サイトの更新」と一括りにされがちですが、Shopifyの運用作業は必要なスキルも頻度もまったく違うものが混ざっています。まずこれを分解しないと、担当の割り振りができません。
第1層：日次オペレーション
- 受注確認・出荷処理
- 在庫数の増減
- 問い合わせ対応
- 返品・キャンセル処理
第2層：コンテンツ更新
- 商品登録・商品説明の改訂
- ブログ記事の投稿
- お知らせ・営業日の案内
第3層：販促・見た目の変更
- トップバナーの差し替え
- セール・クーポンの設定
- 特集ページの作成
第4層：構造・技術の変更
- テーマの改修・セクション追加
- アプリの導入・削除
- 配送設定・税設定の変更
- 計測タグ・構造化データ
層が下がるほど頻度は落ち、必要なスキルは上がる。担当を決めるときはこの単位で切る。
この4層を意識すると、ありがちな失敗の正体が見えてきます。第1層と第2層を同じ人に任せた結果、第2層が永久に後回しになるというパターンです。出荷は今日やらないと客が怒りますが、商品説明の改訂は明日でも誰も怒らない。だから後回しになり、そのまま半年経ちます。
層ごとに「止まったときのダメージ」が違う
担当を決める前に、それぞれが止まったときに何が起きるかを確認しておきます。
| 層 | 更新が止まると | 気づくまでの時間 |
|---|---|---|
| 第1層 日次オペ | 出荷遅延、クレーム、レビュー低下 | 数時間〜1日 |
| 第2層 コンテンツ | 新商品が売れない、検索流入が伸びない | 1〜3ヶ月 |
| 第3層 販促 | 季節外れの表示、機会損失 | 1ヶ月（客からの指摘で気づくことも） |
| 第4層 構造・技術 | 表示崩れ、計測欠損、決済エラー | 気づかないまま数ヶ月 |
一番怖いのは第4層です。壊れても誰も気づかない。テーマのアップデートで一部のセクションが崩れていた、アプリの解約後に残ったコードが読み込みエラーを出していた、といった事故は、売上が落ちてから原因を探して初めて見つかります。だから第4層には「異常がなくても定期的に見る人」が要る。
更新担当の割り当て方：3つの体制パターン
4層に分けたら、次は自社の規模に当てはめます。人数と商品点数で現実的な形が変わるので、よくある3つの型を、週の動き方まで具体的に示します。
パターンA：商品点数が少なく、社内に専任がいない
想定：常時取扱いが数十点、受注は1日数件、EC担当は他業務と兼任の1〜2名。
| 層 | 担当 | 動き方 |
|---|---|---|
| 第1層 | 兼任担当A | 毎日午前に受注チェックと出荷指示。午後の受注は翌営業日 |
| 第2層 | 兼任担当B | 曜日固定（例：毎週水曜の午前2時間）で商品登録とブログ |
| 第3層 | 兼任担当B＋外注 | バナー制作は外注、差し替え操作だけ社内 |
| 第4層 | 制作会社 | 四半期点検を都度見積で発注 |
この規模で最も多い失敗は、担当AとBを同じ人にしてしまうことです。兼任が悪いのではなく、第1層と第2層の兼任が悪い。どうしても1人しかいないなら、第2層は「水曜の10〜12時はEC更新の時間」とカレンダーで先に押さえ、出荷はその時間帯に回さない運用にします。
パターンB：定期的に新商品が出る、EC専任がいる
想定：常時取扱いが数百点、毎月新商品あり、受注は1日数十件、EC専任1〜2名＋出荷担当。
| 層 | 担当 | 動き方 |
|---|---|---|
| 第1層 | 出荷担当（物流兼務） | 毎日。締め時間を決めて当日分を確定 |
| 第2層 | EC専任 | 入荷スケジュールに合わせて登録。ブログは月2〜4本 |
| 第3層 | EC専任＋外注デザイン | 月次のバナー差し替えは前月中に入稿、当日は差し替えのみ |
| 第4層 | 制作会社（月額保守） | 月1回の計測確認、四半期のテーマ・アプリ点検 |
この規模で詰まるのは第3層です。企画・デザイン・原稿・設定が全部EC専任1人に乗り、セール直前に徹夜になる。バナーとLPの制作を外に出し、社内は「差し替える操作」と「内容の決定」だけ持つと安定します。
パターンC：コーポレートサイトを兼ねている
想定：ECに加えて会社案内・採用・お知らせを同じShopifyで運用。更新主体が部署をまたぐ。
| 更新対象 | 担当部署 | 権限 |
|---|---|---|
| 商品・コレクション | EC担当 | 商品、コレクション |
| 商品ブログ | EC担当 | ブログ（商品用） |
| 会社からのお知らせ | 広報・総務 | ブログ（お知らせ用）のみ |
| 採用情報ページ | 人事 | 指定の固定ページのみ |
| テーマ・アプリ | 制作会社＋管理者 | 全体 |
ここでの要点は、部署ごとに「触る場所」を1か所に絞ることです。人事に管理画面の全機能を説明しても使われません。「この1ページだけ、この手順で」に限定する。詳しくは後述します。
社内でやる範囲と外注する範囲の分け方
「全部社内でやる」も「全部外注する」も、たいていうまくいきません。前者は担当者の退職で崩壊し、後者は月額が積み上がったうえに小回りが効かなくなります。
分け方の基準はシンプルで、判断が要るか／手順が決まっているかと、頻度が高いか／低いかの2軸です。
社内でやるべき（内製）
- 受注・出荷・在庫（事業判断そのもの）
- 商品登録（商品を一番知っているのは社内）
- ブログ・お知らせ（自社の言葉が要る）
- セール価格の決定
外注が向く
- テーマ改修・セクション追加
- アプリの選定と導入
- バナー・特集ページのデザイン
- 計測の設定と月次の点検
境界は「その作業を覚えるのに何日かかるか」で引くとわかりやすい。半日で覚えられて毎週発生するなら内製、覚えるのに1週間かかって年に数回しか発生しないなら外注です。
内製すべきものを外注すると起きること
商品登録を外注している事業者は珍しくありませんが、これは長期的には不利になりやすい配分です。理由は3つあります。
- リードタイムが伸びる — 新商品を出したいのに、制作会社に素材を送って、作業待ちして、確認して、で数日から1週間かかる。売り時を逃します。
- 商品説明の質が落ちる — その商品の良さを一番わかっているのは作った人・仕入れた人です。外注先が書く説明文は、どうしても仕様の羅列になります。
- 費用が積み上がる — 商品登録は1点あたりの作業費で見積もられることが多く、点数が増えるほど効いてきます。
逆に、最初の数十点の登録ルールづくりだけを外注して、以降は社内で回すという分け方は合理的です。商品タイプ・タグ・コレクション条件・メタフィールドの設計は最初に決めておかないと後で破綻するので、ここは設計スキルのある側がやる。その型に沿って埋める作業は社内でできます。
外注すべきものを内製すると起きること
反対の失敗もあります。テーマのコードを社内の「PCに詳しい人」が直し始めるケースです。
Shopifyのテーマは、テーマエディタから触れる範囲（セクションの並べ替え、色、画像）と、コードを直接編集する範囲で難易度がまったく違います。前者は誰でも触っていい。後者は、触るとテーマのアップデートが当てられなくなったり、他のページごと表示が壊れたりします。
アップデートに耐える形で改修する方法論は、別記事でまとめています。
権限設計で「触れる範囲」を物理的に決める
体制を決めても、口頭のルールだけでは守られません。Shopifyにはスタッフごとの権限設定があるので、担当していない層は開けないようにしておくのが確実です。
最低限、分けておきたい3つの権限グループ
| グループ | 与える権限 | 与えない権限 |
|---|---|---|
| 出荷・CS担当 | 注文、顧客、在庫 | テーマ、アプリ、設定、請求 |
| コンテンツ担当 | 商品、コレクション、ブログ、ページ | テーマのコード編集、アプリ、設定、請求 |
| 管理者 | すべて | —（1〜2名に限定） |
ここで効いてくるのは「テーマのコード編集」と「アプリの追加」を分けておくことです。アプリのインストール権限が全員にあると、それぞれが良かれと思って入れたアプリで月額が積み上がり、半年後に誰も何のアプリかわからない状態になります。
これは体制の問題であって、アプリ自体が悪いわけではありません。コストの積み上がり方と抑え方は、こちらで詳しく扱っています。
制作会社のアカウントをどう扱うか
制作会社にスタッフアカウントを発行する際、注意点が2つあります。
- コラボレーターアカウントを使う：Shopifyには制作会社・パートナー向けの「コラボレーター」という仕組みがあり、これを使うとスタッフ枠の扱いが変わります。スタッフアカウントを発行すると、プランによってはスタッフ数の上限に当たります。
- 契約終了時に必ず削除する：これは意外と放置されます。契約が切れた制作会社のアカウントが管理画面に残り続けている状態は、セキュリティ上も監査上も好ましくありません。アカウント棚卸しの日を年1回決めておく。
そしてストアの所有者アカウントは必ず自社名義にしておくこと。制作会社のメールアドレスがストアオーナーになっていると、乗り換えるときに交渉から始まります。ドメインの名義も同じ論点です。
アプリで足りる範囲と、テーマ改修が必要になる境界
運用体制を決めるうえで避けて通れないのが、「やりたいことが出てきたとき、アプリを足すのか、テーマを直すのか」の判断です。ここを毎回その場の勢いで決めると、体制が壊れます。
判断の順番
見落とされがちなのは4番目です。アプリの価値は機能そのものより「非エンジニアが管理画面から設定を変えられること」にある場合が多い。逆に、一度設定したら誰も触らない機能であれば、アプリの管理画面という利点は消えて、月額だけが残ります。
アプリが向くケース / テーマ改修が向くケース
| 条件 | アプリが向く | テーマ改修が向く |
|---|---|---|
| 更新頻度 | 社内で頻繁に設定変更する | 一度組んだら触らない |
| 期間 | 数ヶ月のキャンペーン | 恒久的な仕様 |
| 外部連携 | 外部サービスとの同期が必要 | 自己完結する |
| デザイン | 見た目の自由度は不問 | ブランドの一部として作り込む |
| 複雑さ | レビュー、配送日時、決済拡張など | 表示・レイアウト・絞り込み |
外部サービスとの連携（レビューの収集と表示、メール配信、会計連携、複雑な配送計算など）は、アプリの独壇場です。自前で作ると保守が終わりません。
一方で、表示まわりの小さな機能はテーマ側で完結させたほうが、月額も表示速度も有利になることが多い。たとえばお気に入り機能のように、ログイン連携まで要らないのであればブラウザ側で完結させる作り方もあります。
選ぶときに見る4箇所
アプリを比較するとき、レビュー評価と機能一覧だけで決めないでください。運用体制の観点では、次の4つを見ます。
- 最終更新日 — Shopify自体が定期的に仕様を変えます。更新が長く止まっているアプリは、次の仕様変更で壊れる可能性があります。
- 対応言語 — 管理画面が英語のみだと、触れる社内メンバーが限られます。体制が1人に依存する原因になります。顧客に見える文言（ボタン、エラーメッセージ）が日本語にできるかも別途確認。
- サポート体制 — 日本語対応の有無、返信までの目安時間。トラブルは繁忙期に起きます。
- 自社テーマとの相性 — 特にテーマのコードに埋め込むタイプのアプリは、カスタマイズ済みのテーマと衝突することがあります。導入前に複製テーマで試す。
料金については、プランも金額も変わるので最新の料金は各アプリのページで必ず確認してください。粒度としては「無料枠があるもの」「定額の月額課金のもの」「売上や件数に応じて変動するもの」の3つに分けて、変動するものは自社の月商を当てはめて試算しておくと予算がぶれません。
より詳しい判断基準は専用の記事にまとめています。
解約したあとに残るもの
運用体制の話として、これは必ず知っておいてください。アプリを解約しても、テーマに埋め込まれたコードは自動では消えないことがあります。
解約後に残りやすいもの:
- テーマのコードに追記されたスクリプトタグ（読み込みエラーを出し続ける）
- アプリが生成したメタフィールド
- アプリブロックの残骸（テーマエディタで空のブロックとして残る）
これが積み重なると、表示速度が落ちるうえ、原因不明のJavaScriptエラーが出続けます。アプリを解約するときは「解約作業」を1工程として扱い、テーマ側の残骸を消すところまでやる。誰がそれをやるのかも、体制に含めておきます。
コーポレートサイトを兼ねている場合の追加論点
ShopifyをECだけでなく会社案内も含めたコーポレートサイトとして運用している場合、更新担当の設計はもう一段複雑になります。
会社情報・採用情報・IR的な告知は、EC担当ではなく総務・人事・広報が更新主体になるからです。ところがShopifyの管理画面は「ECの管理画面」として設計されているため、商品と無関係な部署の人がログインすると、どこを触っていいのかわかりません。
対策は3つ。
- 固定ページ（ページ）とブログを用途で分ける — 「会社からのお知らせ」と「商品ブログ」を別ブログとして作り、権限と担当を分離する
- 編集する場所を限定する — テーマエディタで触ってよいセクションを決め、それ以外は触らないルールにする
- 手順書を部署ごとに1枚で作る — 「採用情報の更新手順」だけを書いた1ページを人事に渡す。全機能のマニュアルを渡しても読まれません
3つ目は具体的に書きます。人事に渡す1枚は、「管理画面にこのURLで入る → 左メニューのこの項目 → この見出しの下のテキストを書き換える → プレビューで見る → 保存」まで、画面キャプチャ付きで完結させる。新しい職種を1つ追加するだけの操作が5分で終わる状態になっていれば、更新は続きます。
コーポレートとECを1つのShopifyで運用する考え方そのものについては、こちらで整理しています。
引き継ぎのために用意しておくもの
体制は人が変わった瞬間に試されます。担当者が退職・異動しても止まらないようにするには、属人的な記憶をドキュメントに移しておくしかありません。
公開時に制作会社から受け取るべきもの、そして自社で作り足すべきものを分けて示します。
制作会社から受け取るもの
| 項目 | なぜ必要か | ないと起きること |
|---|---|---|
| 管理画面の操作手順書 | 更新作業を再現するため | 担当交代のたびに問い合わせが発生 |
| テーマのカスタマイズ内容一覧 | どこを標準から変えたかの記録 | テーマ更新時に何が壊れるか予測できない |
| 導入アプリ一覧と用途 | 解約判断・トラブル切り分け | 何のアプリか不明なまま課金が続く |
| 各種アカウントの棚卸表 | 権限管理・退職時の処理 | 元担当者のアカウントが残る |
| 商品登録のルール定義 | タグ・コレクション設計の維持 | 途中から命名が崩れ、絞り込みが壊れる |
| 計測の設定内容 | 数字が合わないときの確認 | 計測が壊れても気づけない |
このうち「商品登録のルール定義」は特に軽視されがちです。タグの命名規則、コレクションの自動条件、商品タイプの使い分け。これが文書化されていないと、担当が変わった途端に「新作」「新商品」「NEW」が混在して自動コレクションが機能しなくなります。実際、絞り込みが効かなくなったストアを調べると、原因がタグの表記ゆれだけ、というのは珍しくありません。
自社で作り足すもの
制作会社が用意する手順書は、どうしても「機能の操作説明」になります。実際の運用で要るのは、自社の業務に合わせた手順です。
- 更新カレンダー — 何を、いつ、誰が更新するか。月次・週次で固定する
- バナー・画像の規定サイズ一覧 — 毎回制作会社に聞かなくて済むように
- 文言のトーンルール — 商品説明の書き方、敬体/常体、禁止表現
- 判断に迷ったときの相談先 — 社内の誰に聞くか、制作会社のどの窓口か
更新カレンダーは1枚の表で十分です。例として、一般的な運用頻度の目安を挙げます（業種・商品点数で当然変わります）。
| 作業 | 頻度 | 担当層 |
|---|---|---|
| 受注・出荷処理 | 毎日 | 第1層 |
| 在庫数の更新 | 毎日〜週次 | 第1層 |
| 新商品の登録 | 入荷のつど | 第2層 |
| ブログ記事 | 月2〜4本 | 第2層 |
| トップバナー差し替え | 月1回 | 第3層 |
| セール設定 | 企画のつど | 第3層 |
| アクセス数値の確認 | 月1回 | 第4層 |
| テーマ・アプリの点検 | 四半期に1回 | 第4層 |
| アカウント棚卸し | 年1回 | 第4層 |
「テーマ・アプリの点検」を四半期に置いているのは、Shopifyの仕様変更とアプリのアップデートが積み重なるからです。異常が起きてから見るのではなく、異常がないことを定期的に確認するという枠を作っておく。これがないと、第4層は永久に誰も見ません。
点検の中身も決めておきます。最低限、①主要導線（商品ページ→カート→チェックアウト）をスマホ実機で通す、②計測タグが発火しているか確認する、③導入アプリの一覧と課金額を突き合わせる、④テーマのアップデート有無を見る。この4つを1時間の作業として四半期に置くだけで、「気づかないまま数ヶ月」はほぼ防げます。
更新が止まる本当の理由は「判断が要るから」
ここまで手順の話をしてきましたが、更新が止まる最大の原因は、実は手順の不明さではありません。「これを出していいのか」の判断がどこかで詰まることです。
ブログ記事を書いた。でも公開していいか上司に確認したい。上司は忙しい。1週間止まる。これが2〜3回続くと、担当者は記事を書かなくなります。
対策は、承認が要るものと要らないものを最初に線引きしておくこと。
- 承認不要：ブログ記事、商品説明の改訂、お知らせの掲載
- 承認必要：価格変更、セールの実施、トップページの構成変更、法務に関わる表記
この線を引いておくだけで、更新頻度は目に見えて変わります。承認のハードルを下げられない場合は、「この曜日のこの時間に必ず見る」という定例を作る。
制作会社との継続契約をどう設計するか
第4層を外注する場合、契約の形を決めておく必要があります。ここも曖昧にすると、「これは契約に含まれますか」の確認だけで往復が発生します。
3つの契約形態
| 形態 | 向くケース | 注意点 |
|---|---|---|
| 都度見積（スポット） | 更新が不定期、年数回 | 依頼から着手まで時間がかかる。小さい依頼ほど割高感 |
| 月額保守（時間枠型） | 毎月一定量の作業がある | 使わなかった枠が繰り越せるか要確認 |
| 月額保守（定額点検型） | 大きな改修は少ないが放置は不安 | 「点検」に何が含まれるかを明文化 |
金額は、対応範囲・応答速度・稼働量のどれを買うかで大きく変わります。「月額いくらが相場か」ではなく「この作業量なら何時間か」で見積を取ると比較できます。同じ条件を複数社に出して、時間単価と含まれる範囲の差を見るのが実務的です。
依頼するとき、次の3点を契約書または見積書の中で明示してもらってください。曖昧なまま進むと、後から必ずもめます。
- 対応範囲 — テーマ改修は含むか、アプリの設定変更は含むか、商品登録は含むか
- 対応時間と返答までの目安 — 営業時間内のみか、障害時の連絡経路はどうか
- 含まれない作業の扱い — 別見積になる基準（作業時間◯時間以上、など）
契約形態そのものの選び方や、依頼内容の整理の仕方については、こちらも参考になります。
「壊れたとき誰が直すのか」を決めておく
もう1つ、契約前に必ず確認しておく論点があります。アプリが原因で不具合が起きたとき、誰が対応するのかです。
Shopifyの不具合は、原因の切り分けが難しい。テーマなのか、アプリなのか、Shopify本体の仕様変更なのか。制作会社の契約が「自社が作ったテーマの範囲まで」となっていると、アプリ起因の不具合は宙に浮きます。
現実的な落とし所は、「原因の切り分けまでは制作会社、アプリ側の修正はアプリのサポートへ、その橋渡しも制作会社」という形です。この役割分担を、契約前に言葉にしておいてください。
公開前にやっておく、たった1つのこと
ここまでの内容を全部準備するのは大変に見えますが、最低限やるなら1つだけです。
公開の1ヶ月前に、実際の担当予定者に管理画面を触ってもらう。
商品を1点、テスト登録してもらう。ブログを1本、下書きで書いてもらう。バナーを1枚、差し替えてもらう。それだけで、
- その人が本当にできるのか
- 何分かかるのか（想定よりずっと時間がかかることがよくあります）
- どこで詰まるのか
- 誰の承認が要るのか
がすべて見えます。公開後に「思ったより大変だった」と判明するのと、公開前にわかるのとでは、打てる手がまったく違います。制作会社にとっても、この段階で詰まりどころがわかれば、手順書の重点を変えられる。
体制設計というと大掛かりに聞こえますが、実態は「公開前に1回リハーサルをする」ということです。
よくある質問
Shopifyの運用は何人体制が必要ですか？
商品点数と受注件数によりますが、小規模なら兼任1〜2名でも回ります。ただし「出荷担当」と「コンテンツ担当」は同一人物にしないほうが安全です。同じ人だと、締め切りのある出荷が優先され、コンテンツ更新が恒常的に後回しになります。人数を増やせない場合は、コンテンツ更新の時間を曜日固定でブロックしてください。
商品登録は制作会社に依頼すべきですか？
最初のルール設計（タグ・コレクション・商品タイプ・メタフィールドの設計）と、初期数十点の登録までは依頼する価値があります。ただし以降の継続的な登録は社内で回すことをおすすめします。外注すると新商品公開までのリードタイムが伸び、点数に応じて費用も積み上がります。
テーマを自分で編集しても大丈夫ですか？
テーマエディタ上での操作（セクションの並べ替え、色や画像の変更、ブロックの追加）は問題ありません。コードエディタでのLiquid・CSS・JavaScriptの直接編集は、専門知識がないと表示崩れやテーマ更新の不能につながります。触る必要がある場合は、必ず複製テーマで試してから公開テーマに反映してください。
アプリを解約すれば料金も表示も完全に止まりますか？
料金は止まりますが、表示側には残骸が残ることがあります。テーマのコードに追記されたスクリプト、生成されたメタフィールド、テーマエディタ上の空のアプリブロックなどです。放置すると表示速度の低下やJavaScriptエラーの原因になるため、解約時にテーマ側の掃除まで含めて1工程として扱ってください。
制作会社との保守契約は必要ですか？
更新の第4層（テーマ改修、アプリ管理、計測点検）を社内で担えないのであれば必要です。ただし「何かあったときのため」という漠然とした理由で月額を払い続けるのは合理的ではありません。四半期点検＋都度見積という形でも、定期的に見る人を確保するという目的は達成できます。契約前に、点検で何を見るのかを一覧にしてもらってください。
まとめ
Shopifyの運用体制を決めるとき、押さえるべきポイントを整理します。
- 更新作業を4層に分解する — 日次オペ／コンテンツ／販促／構造・技術。必要なスキルも頻度も違う
- 第1層と第2層を同じ人に任せない — 締め切りのある作業が、ない作業を必ず押しのける
- 自社の規模に体制パターンを当てはめる — 専任なし／EC専任あり／コーポレート兼用で、担当の切り方が変わる
- 内製と外注は「覚えるのに何日かかるか」で切る — 商品登録・ブログは内製、テーマ改修・アプリ管理は外注が基本形
- 権限で物理的に分ける — 特にアプリ追加とテーマのコード編集は限定する
- アプリかテーマ改修かは、更新頻度と期間で判断する — 社内が頻繁に触るならアプリ、一度組んだら触らないならテーマ
- 解約時の残骸まで工程に含める — アプリは消しても痕跡が残る
- 引き継ぎ資料は「操作手順」と「自社の運用ルール」の2種類が要る — 制作会社が出すのは前者だけ
- 承認が要るものと要らないものを最初に線引きする — 更新が止まる本当の原因は判断待ち
- 公開1ヶ月前に担当予定者にリハーサルをさせる — これだけで詰まりどころが全部見える
サイトは作った時点が最も新しく、その後は放っておけば古くなるだけです。公開日に「明日から誰が何をするか」が全員の口から出てくる状態なら、その体制は動きます。出てこないなら、公開日を1週間遅らせてでも決めたほうが、結果的に早く回り始めます。
