Meta、Muse Sparkのオープンウェイト化を約束するも、本当の難題はこれから

MetaはMuse Spark 1.3をgoogle newsに送り出し、二つの関連する主張を掲げた。現時点でより強力なエージェント性能を提供し、続いてダウンロード可能なオープンウェイトを「まもなく」公開するというものだ。最初の主張は、Muse CodeとMetaのホスト型APIを通じてすでに検証できる。二つ目は、公開日、対象チェックポイント、ライセンス、ハードウェア要件が示されていない約束にとどまる。

この違いにより、通常のモデル更新はMetaのAI戦略を試す場へと変わる。同社はダウンロード可能なLlamaモデルによって開発者の支持を築いた後、最も強力なMuseシステムをホスト型アクセスへと移行させた。競争力のあるMuse Sparkのウェイトを公開すれば、この二つの路線は再びつながる。約束を果たせなければ、オープン開発に対するMetaの姿勢への疑念はさらに深まるだろう。

圧力を受けるのはMetaだけではない。OpenAI、Anthropic、Google、xAI、そして複数の中国研究所はいま、推論、コーディング、マルチモーダル作業、エージェント設計で競っている。Metaは、Llamaを影響力ある存在にした配布面での優位性を維持しつつ、各社のホスト型モデルに挑もうとしている。この組み合わせは魅力的に聞こえるが、ダウンロード可能なウェイトには、APIであればより厳格に管理できるコストとリスクが伴う。

Metaが実際に公開したものと、約束しただけのもの

Muse Spark 1.3は現在利用可能だが、オープンウェイト版は詳細の定まらない将来のリリースにとどまっている。

Metaは2026年9月2日、コーディングと長時間にわたるエージェント作業に焦点を当てた更新としてMuse Spark 1.3を発表した。エージェント作業では、モデルが計画を立て、ソフトウェアツールを使い、中間結果を評価し、目標に向けて作業を継続する必要がある。

このモデルはMuse CodeとMeta Model APIを通じて利用できる。現時点では、開発者が自前のインフラで実行できる、ダウンロード可能な主力チェックポイントではない。この境界は、発表を取り巻く軽妙な表現以上に重要だ。

Metaによると、この更新版は一つの長い会話の中で複数のワークフローを管理できる。相反する情報源から文脈を収集し、不完全な計画を修正し、作業が続く中でも先行する要件を維持できるという。同社は、指示が曖昧な場合には確認の質問も行うとしている。

こうした変更は、コーディングエージェントにおける実用上の弱点を狙ったものだ。モデルは個別の質問で高得点を取れても、制約を忘れたり失敗した行動を繰り返したりして、長期タスクでは失敗することがある。ツール利用も、不要な呼び出しのたびに時間とトークンを消費するため、コストが積み上がる。

Metaのリリースノートによれば、Muse Spark 1.3はバージョン1.2と比べ、ツール呼び出しを約20％、トークンを約25％削減する。これらは同社が報告した比較であり、本番環境全般にわたる普遍的な測定値ではない。

Metaはまた、このモデルが不確実性をより慎重に扱うとしている。行き詰まった際には支援を求め、重大な行動を取る前には確認するべきだという。エージェントがリポジトリ、顧客記録、業務システムに触れる場合、この振る舞いは小幅なベンチマーク向上より重要になり得る。

ただし、Metaはこうした改善が異なるツールやソフトウェアスタック間でも移転することを示す、十分な実環境の証拠をまだ公開していない。モデルの挙動は、周辺のハーネス、プロンプト、権限、再試行ロジックにも一部左右される。Muse Codeでの結果が、すべてのサードパーティ製エージェントにおける性能を自動的に予測するわけではない。

Mark Zuckerbergは、より重要な約束を公開投稿で加えた。より大規模なモデルを示唆するスイカの絵文字の予告とともに、Muse Sparkのオープンウェイト版は「まもなく」登場すると述べた。この投稿では、どのSparkバージョンがダウンロード可能なウェイトを受け取るのかは特定されなかった。

この曖昧さはいくつかの可能性を残す。Metaはバージョン1.2、圧縮版の派生モデル、選定したSparkバリアント、あるいは現行の1.3チェックポイントを公開するかもしれない。いずれの選択も、開発者がこのリリースを独自仕様の最先端モデルと比較する際に異なる意味を持つ。

オープンウェイトとオープンソースの違いにも、正確さが求められる。オープンウェイトは通常、学習済みパラメータをダウンロードできることを意味する。学習データ、完全な学習コード、評価パイプライン、制限のない商用利用権へのアクセスを保証するものではない。

最終的なライセンスによって、組織が予期しない制約なしにモデルを変更、ファインチューニング、再配布、導入できるかが決まる。Metaがそのライセンスを公開するまで、「オープン」は完全な開発者向け提案ではなく、意向を表す言葉にすぎない。

google newsを通じて広がる報道は、こうした詳細を差し迫った公開に関するより単純な見出しへと圧縮しがちだ。実際の出来事はより限定的である。Metaはクローズドウェイトのサービス更新を出荷し、それとは別にオープンウェイト化へのコミットメントを改めて表明した。

この順序が中心的な緊張を生む。開発者はいまSparkのホスト型性能を試せるが、独立した導入を通じてMetaのより大きな主張を検証することはまだできない。

Google Newsでの注目がMetaにとって重要な理由

オープンウェイト化の約束は、開発者にMetaを最先端APIの提供者であると同時に、信頼できるダウンロード可能モデルの供給元として見なすよう求めている。

Metaの初期のLlamaリリースは、同社がホスト型モデル収益を支配せずとも影響力を拡大した。開発者はウェイトを調査し、ファインチューニングを作成し、ローカルツールを構築し、特定のインフラ向けに導入を適応できた。クラウド事業者やハードウェア企業も、最適化できるモデルファミリーを得た。

Muse Sparkは当初、この関係を変えた。Metaが4月にMuse Sparkを発表した際、同システムはMeta AIと非公開APIプレビューを通じて提供された。したがって最も強力な新モデルは、広くダウンロードできるLlamaの後継ではなく、Metaが管理するサービスだった。

この判断は、OpenAI、Anthropic、Googleが採る戦略に似ている。ホスト型アクセスは、研究所に利用状況、安全方針、更新、収益化に対するより強い統制を与える。また、外部者がモデルを深く検査・変更できる範囲も制限する。

ホスト型モデルは静かに変更できる。提供者は新しいチェックポイントを配布せずに、推論システム、安全層、コンテキスト処理、ルーティングを調整できる。顧客は利便性を得る一方、提供者の可用性と方針への依存も受け入れることになる。

オープンウェイトは、この関係の一部を反転させる。組織は選んだモデルバージョンを保持し、自らのセキュリティ境界の内側で実行し、専門的な作業向けに調整できる。研究者は、制限付きAPIでは困難な評価も実施できる。

この柔軟性には運用上の負担が伴う。大規模モデルには、相当なメモリ、推論に関する専門知識、監視、セキュリティ管理が必要となる。ウェイトをダウンロードできても、モデルの運用が安価または容易になるわけではない。

MetaはすでにMuse Glimmerを通じて、より小規模な例を提供している。同社はGlimmerを、ローカルシステムで動作するよう設計された300億パラメータのオープンなエージェントモデルと説明した。また、Sparkのウェイトも続くことを示唆している。

Glimmerは、Metaがダウンロード可能なリリースを完全に放棄していないことを示した。しかし、小型モデルは主力システムとは異なるワークロードに対応するため、中心的な疑問を解消したわけではない。ローカル導入と最先端の能力の間で判断するチームには、依然としてSparkの詳細が必要だ。

そのため、オープンウェイト化の約束はMeta自身に圧力をかける。同社は、安全管理とホスト型サービスに付随する商業的優位性を守りつつ、意味のあるほど有用なリリースを実現しなければならない。

これは米国の競合他社にも圧力をかける。OpenAIとAnthropicは、主力モデルを主に管理されたサービスを通じて提供している。強力でダウンロード可能なMetaモデルが登場すれば、企業は非公開のカスタマイズとインフラの独立性に向けた別の選択肢を得ることになる。

Googleはより複雑な比較に直面する。同社は独自仕様のGeminiサービスと、ダウンロード可能なGemmaモデルを併せて提供している。Metaが管理可能な導入規模でより強いエージェント性能を提供すれば、有能なSparkのリリースはこの二本立て戦略に直接挑むことになる。

中国の開発者も、モデル競争の中心にオープンウェイトシステムを据えている。Qwen、DeepSeek、GLM、関連ファミリーは、主要な米国システムがクローズドなままである状況で、研究者や企業に代替手段を与えてきた。Metaの復帰は、この市場における米国側の競争力を強めるだろう。

Sriram Krishnanは、この見通しを米国のオープンウェイト競争力にとって重要だと述べた。Box CEOのAaron Levieは、本格的なリリースが実現すれば競争構造を変えると主張した。こうした反応は戦略的な関心を反映するものであり、今後のチェックポイントが期待に応える証拠ではない。

google newsで見られる注目が重要なのは、モデルの採用が開発者の信頼にも一部依存するためだ。エンジニアは評価ツール、統合、ファインチューニング、導入システムに時間を投じる。曖昧なロードマップは好奇心を引きつけられるが、持続的な採用には成果物と信頼できる条件が必要になる。

Metaは、このリリースをより広範な投資の説明にも結び付ける必要がある。同社はインフラに多額の投資を行い、AI事業をMeta Superintelligence Labsを中心に再編した。競争力のあるモデルは、そうした投資が利用可能な技術を生み出していることを示す目に見える証拠になる。

それでも、ベンチマークの向上だけではその戦略を裏付けられない。Metaは、Museが製品、開発者ワークフロー、運用経済性を改善することを示さなければならない。オープンウェイトは、外部チームがMetaの望む環境を超えてSparkを試せるようにすることで、その証拠を広げる可能性がある。

Metaのオープンウェイト戦略とホスト型モデルのプレイブック

Metaはオープンウェイトの到達範囲と、ホスト型最先端サービスの統制を組み合わせようとしているが、この二つの目標は本質的に衝突する。

ホスト型モデルのプレイブックには、いくつかの利点がある。提供者は、隠しプロンプト、ツールルーティング、キャッシュ、安全フィルター、モデル選択を含む完全な推論スタックを管理する。この統制は、モデルそのものの弱点を見えにくくする一方で、信頼性を向上させられる。

また、開発者との継続的な関係も生み出す。すべてのアプリケーション要求は提供者のインフラを通過するため、同社は利用データと、アップグレードを直接配布するチャネルを得る。提供者は、顧客にウェイトの再導入を求めずに新機能を投入できる。

オープンウェイトの配布は、統制を顧客側へ移す。企業は自社ネットワーク内でモデルを導入し、機密性の高いプロンプトを外部APIから遠ざけ、更新をいつ採用するか選択できる。提供者側の変更が結果に影響を及ぼさない状態で、挙動を測定することも可能だ。

ソフトウェアチームにとって、これはコードレビュー、インシデント分析、文書処理、社内調査で重要になる。こうしたワークフローには機密情報が含まれることが多い。一部の組織は、契約上の保護があっても、その情報をサードパーティのサービスへ送らない。

ローカル導入は、オフラインやエッジのシナリオにも対応できる。ツールの近くで動くモデルは、ネットワーク遅延や外部サービスの中断を回避できる場合がある。ただし、最大のSparkバリアントは、大半のチームが管理できる範囲を超えるインフラを必要とする可能性がある。

だからこそ、最終的なモデルサイズが重要になる。Metaは、約束したチェックポイントのパラメータ数、量子化オプション、メモリ要件について十分な情報を開示していない。これらの詳細がなければ、チームはそのモデルをワークステーション、エンタープライズサーバー、大規模アクセラレータクラスタのどこに置くべきか見積もれない。

周辺ソフトウェアも重要です。Muse Sparkで報告されている改善はツール利用や長期的な作業に関するものですが、重みだけでは、その結果を生み出すすべての構成要素を含んでいません。エージェントには、権限、コンテキスト、再試行、ツール出力、ユーザー承認を管理するハーネスが必要です。

Metaがモデルパラメータのみを公開した場合、開発者はMuse Codeの挙動を再現するのに苦労する可能性があります。推論レシピ、ツールスキーマ、参照用のオーケストレーションコードも公開すれば、重みの実用性は大幅に高まります。

この問題は、モデルの公開性とシステムの再現性を分けるものです。ダウンロード可能なチェックポイントは検証や適応を可能にしますが、ホスト型製品を自動的に再現するわけではありません。Metaは、MuseスタックのどこまでをSparkに付随させるか定義する必要があります。

元記事は、もう一つ重要な対比を捉えていました。Muse Spark 1.3で最も強力なベンチマーク構成は、最大推論モードが依然としてセキュリティレビュー中だったため、一般の開発者には直ちに利用できませんでした。

この制約によって公開結果が無意味になるわけではありません。ただし、リリース当日のユーザーはMetaの比較で示された構成を完全には再現できないことを意味します。独立評価では、利用可能なモードと制限付きプレビューを区別すべきです。

Metaによれば、バージョン1.3はコーディング、ツール利用、マルチモーダル推論、長文コンテキストのテスト全般で優れた性能を示します。同社の比較では、選択された複数の評価においてOpenAIやAnthropicのモデルに近い位置づけです。

報道が引用した独立テストでも、Sparkは競争力のあるフロンティアシステムの一つに位置づけられました。それでも、ベンチマーク平均は信頼性、レイテンシー、ツール互換性、エラー復旧の差を覆い隠します。あるコーディングテストで勝つモデルが、特定のリポジトリやフレームワークでは低調に終わることもあります。

長文コンテキストのスコアにも同様の注意が必要です。大きなコンテキストウィンドウは、システムが受け入れられる情報量を測るものであり、そのすべてを正確に推論できるかを示すものではありません。ベンチマークが高い再現率を報告していても、検索品質の問題や注意機構の失敗は残り得ます。

購入側にとって、より有用な指標は、時間とインフラ単位あたりの成功した作業量であることが多いでしょう。トークン効率は有用ですが、繰り返しの試行、人間による修正、ロールバックを要する失敗までは捉えられません。

オープンウェイトになれば、チームは自らのワークロードでこうした指標を算出できます。公開リーダーボードだけに頼らず、Sparkをホスト型の競合製品と比較できるでしょう。この独立性こそ、約束されたリリースが単なるAPI更新以上の重みを持つ理由の一つです。

その代償として、Metaはデプロイメントに対する一定の統制を失います。改変版が安全策を外したり、危険な作業を自動化したり、有害な出力を大規模に生成したりする可能性があります。重みが流通すれば、プロバイダーはAPIエンドポイントほど容易には取り消せません。

そのためMetaは、競争上の利益がこの統制喪失を上回るかどうかを判断しなければなりません。最大推論をめぐるセキュリティレビューは、同社が高度なエージェント的挙動のリスクをすでに認識していることを示しています。

Muse Sparkのベンチマークだけではなお証明できないこと

Metaの数値は追加テストを正当化するものですが、Sparkが本番環境でより安全、低コスト、または高信頼性であることをまだ証明してはいません。

最も期待できる主張は効率に関するものです。Metaによれば、Spark 1.3はSpark 1.2より少ないツール呼び出しとトークンで動作します。より少ない手順で正しい結果に到達するエージェントは、レイテンシーを下げ、計算消費を抑え、ツールエラーの機会を減らせます。

しかし、平均値は重要な失敗を隠し得ます。迅速に完了した簡単なタスク一つが、ループに陥ったり要件を放棄したりする困難なタスクを相殺することもあります。購入側には、成功率、介入頻度、最悪時のリソース利用を示す分布が必要です。

Metaはまた、このモデルが自らの限界についてより適切に校正されていると述べています。不確実性を認め、指示を求め、重大な行動の前に確認を要求するはずです。エージェントがコードを変更したり外部サービスと連携したりできる場合、これらは価値ある挙動です。

外部チームが敵対的条件と通常条件の両方でテストするまでは、これらは企業側の主張にとどまります。指示が不完全だったり、ツールが不正なデータを返したり、長い会話に矛盾する権限が含まれたりすると、モデルはしばしば異なる挙動を示します。

プロンプトインジェクションは特有の問題をもたらします。コーディングまたは調査エージェントは、Webサイト、文書、課題トラッカー、リポジトリ内で悪意ある指示に遭遇する可能性があります。それらの指示は、ユーザーの目的を上書きしたり、機密情報を抽出したりしようとする場合があります。

Metaはこの種の攻撃への耐性向上を報告しています。しかし、安全性評価で好成績を収めたことだけを理由に、どのモデルにも広範な権限を与えるべきではありません。本番システムには依然として、最小権限アクセス、承認ゲート、ログ、復旧可能なアクションが必要です。

未公開のライセンスも別のリスクです。開発者はSparkがMuse Glimmerや以前のLlamaリリースと同じ条件を採用すると想定できません。利用制限、再配布ルール、大規模サービスへの義務によって、公開性の実質的な意味が変わる可能性があります。

バージョンに関する問題も未解決です。ZuckerbergはMuse Sparkのオープンウェイト「リリース」に言及しましたが、Metaは1.3の最大推論チェックポイントを明確に約束していません。複数形の表現は複数の成果物を示唆しますが、その能力を定義するものではありません。

Metaは、主要ベンチマーク構成でテストされたシステムではなく、ローカル利用向けに最適化したモデルを公開する可能性があります。それでも有用ではありますが、Metaのホスト型提供とダウンロード可能な提供の同等性を確立することにはなりません。

時期に関する表現も同様に精査する必要があります。「Soon」は意図を示しますが、説明責任を伴う期限を設けるものではありません。MetaはすでにSpark 1.2の重みがGlimmerに続くと示していましたが、1.3の発表はそのリリースが広く利用可能になる前に行われました。

このパターンは通常のエンジニアリング作業を反映している可能性があります。モデル変換、ライセンス、文書化、安全性評価、配布には時間がかかります。一方で、どこまでの能力を公開するかをめぐる社内議論が未解決である可能性も示します。

発表について議論する開発者は、両方の可能性を指摘しています。ローカルデプロイ向けの競争力ある米国製モデルが増えることを歓迎する人もいます。一方で、Sparkの報告性能がプロプライエタリなハーネスや大規模な推論計算に依存しているのではないかと疑問を呈する人もいます。

こうした反応を代表的な調査データとして扱うべきではありません。ただし、Metaが答えるべき問いを示しています。外部の利用者は結果を再現できるのか、そしてそれにはどのようなハードウェアが必要なのか。

別の不確実性はデータガバナンスに関するものです。Metaは、より低い利用コストと引き換えに、モデル改善にインタラクションを利用する許可を得るコントリビューター向けアクセス経路を提供しています。機密情報を扱う組織は、その経路を選ぶ前に条件を理解しなければなりません。

オープンウェイトなら、プロンプトが顧客環境内にとどまるため、この特定の依存関係を取り除ける可能性があります。その場合、顧客はストレージ、ログ、モデル更新、セキュリティの責任を負うことになります。

これはリスクをなくすのではなく、移し替えるものです。セルフホスト型モデルは、不十分なアクセス制御、安全でないツール、侵害されたインフラを通じて情報を漏えいさせる可能性があります。プライバシーは重みの所在地だけでなく、システム全体に依存します。

google newsを通じてこの話を追う読者も、報じられた事実と宣伝的な枠組みを分けるべきです。Spark 1.3は存在し、そのホスト型インターフェースは利用可能であり、Metaは評価結果を公開しています。しかし、主力のオープンウェイトパッケージはまだ公開されていません。

この検証上の隔たりこそ、本記事における最も重要な懐疑的視点です。Metaは具体的なサービスリリースで注目を集めましたが、オープンモデル市場を変える行動をまだ完了していません。

この約束の重要性を決める三つのシグナル

Metaがチェックポイントを明示し、実用的な条件を公開し、独立したデプロイメントテストを通過して初めて、このリリースは戦略的に重要になります。

第一のシグナルは、明確に命名されたモデルバージョンを含むダウンロード可能なパッケージです。開発者は、公式配布チャネルで提供される重み、モデルカード、トークナイザーファイル、推論手順、チェックサムを確認すべきです。

Muse Spark 1.3と記されたリリースであれば、オープンウェイトの約束を現在のAPIモデルに直接結び付けられます。1.2またはより小規模な派生モデルに基づくリリースなら、競争上の主張は限定されます。どちらの結果も本質的に悪いわけではありませんが、異なる戦略を表します。

パッケージでは、対応するコンテキスト長と推論設定も説明すべきです。推論モードはしばしば追加の計算資源と時間を消費します。チームは、ダウンロード可能なシステムがMetaのホスト型最大設定で宣伝された挙動を再現できるか把握する必要があります。

Metaが現行の主力モデルを利用可能な参照コードとともに公開すれば、同社のオープンモデルへのコミットメントはより強固になります。古い、あるいは大幅に縮小されたチェックポイントだけを提供するなら、この発表は並行するコミュニティ向け提供に近く見えるでしょう。

第二のシグナルはライセンスです。商用利用の許可、改変権、再配布条件、許容利用制限、大規模プラットフォームに適用される閾値を明記すべきです。

Apacheスタイルのライセンスは、開発者に広い柔軟性を与えます。より制限的なカスタムライセンスでも相当な導入を支え得ますが、その制約は各組織の製品と配布モデルに照らして評価する必要があります。

ライセンスは、「オープンウェイト」が持続的なアクセスを提供するかどうかも明らかにします。開発者には、そのモデルを基盤としてシステムを構築した後も、安定した条件で保存・運用できるという確信が必要です。

Metaが完全なデータセットを公開しなくても、学習データと評価手法に関する文書は価値を加えるでしょう。明確な開示は、研究者が想定される限界を特定し、モデルが有害または信頼性の低いパターンを再現し得る領域を評価する助けになります。

条件が幅広い適応を許容するなら、MetaはAPI専業プロバイダーに対する立場を強めるでしょう。一般的な商用利用に不確実性を生むなら、多くの組織はSparkを引き続きホスト型サービスとして扱うはずです。

第三のシグナルは、実際のエージェント的ワークロードにおける独立した性能です。公開評価では、リポジトリ規模のコーディング、ブラウザタスク、文書調査、ツールエラー、プロンプトインジェクション、長時間の計画をテストすべきです。

研究者は完了スコア以上を報告すべきです。有用な測定には、経過時間、アクセラレータ要件、ツール呼び出し回数、人間の介入、失敗からの復旧、タスク成功あたりの総トークン数が含まれます。

比較では、同等の推論予算も用いるべきです。より多くの推論時間や隠れた足場を与えられたモデルは、基礎能力が似ていても強く見える場合があります。透明な構成により、結果は解釈しやすくなります。

同じ原則は安全性にも当てはまります。独立チームは、Sparkが破壊的または不可逆的な行為の前に一貫して確認を求めるかテストすべきです。また、取得したコンテンツ内に埋め込まれた悪意ある指示をどう扱うかも検証すべきです。

強い結果とは、組織が管理可能なインフラと明示的な統制によって有用なSparkの挙動を再現できることを示すものです。再現性が弱ければ、Metaの優位性は公開された重みではなく、部分的にはホスト型システムにあることを示唆します。

今後1〜3か月で、これらの疑問には答えが出るはずです。Metaのdeveloper catalogはすでにMuse Sparkを主要な開発者向けモデルとして提示しており、Muse Glimmerはオープンなローカル路線の基盤となっています。Sparkのチェックポイントは両者を結び付けるでしょう。

競合各社の反応は二次的な指標となります。GoogleはGemmaラインを拡充する可能性があり、OpenAIやAnthropicは重みを公開せずに開発者向けプログラムを調整する可能性があります。中国のモデル開発企業は、ダウンロード可能なシステムを高い頻度で投入し続けるでしょう。

それでも、Metaの実行力は目先の反応以上に重要だ。同社は「coming soon」という表現を選んだ。したがって最初の試金石は、その約束をファイル、利用条件、再現可能な挙動として具体化できるかどうかになる。

開発者にとって実践的な行動は、ローンチ時のチャートで勝者を決めるのではなく、代表的な評価を準備することだ。自社環境で重要となるタスク、権限、データ境界、失敗時のコストを定義しておく必要がある。

大量の技術資料を扱うチームは、モデルを比較する前に検索可能なナレッジベースを構築することもできる。一貫したソース資料があれば、エージェントの評価はより有意義になり、監査もしやすくなる。

google newsの見出しはすぐに薄れるだろうが、導入に関する証拠は残る。公式リポジトリを確認し、ライセンスを読み、ホスト型システムと自己管理型システムで同じワークロードをテストすべきだ。

Metaが実用的な条件で最新の重みを提供すれば、Muse Sparkはホスト型モデル中心の手法に代わる現実的な選択肢となる。リリース内容が曖昧なままであれば、この約束は、信頼できるAPI更新を取り巻くマーケティングにとどまるだろう。

ベンチマークスコアの向上と、自社の管理下でモデルを検査・運用できることのどちらが、あなたの組織のモデル戦略を変えるだろうか？