Microsoft Decision-1モデル登場、ただしNadellaの後押しは本筋ではない

Microsoftは2026年10月9日、速度、一貫性、36のベンチマークにわたる性能について異例なほど直接的な主張を伴ってMicrosoft Decision-1モデルを発表した。Satya Nadellaもこの発表を後押ししたが、根本となるリリースを担ったのはMicrosoftのエンジニアリング組織だ。この違いは重要である。Decision-1は、CEOを中心に据えた製品ストーリーを伴う、また別の汎用アシスタントではない。

このモデルが対象とするのは、より限定的な問題だ。多くのAIアプリケーションは、入力を繰り返し分類し、出力を採点し、リクエストを振り分け、エージェントが継続すべきかを判断する。開発者は、自由形式の文章作成や長い推論が不要な場合でも、こうした処理を大規模言語モデルに委ねがちだ。

Microsoftは、そのパターンを、より高速で範囲を限定した予測に置き換えようとしている。同社はMicrosoftの基盤モデルから始めるのではなく、Qwen3.5-9Bをポストトレーニングして構築した。この選択は、発表の中心的な緊張関係を生み出している。Microsoftは専門特化型AIを推進する一方、当初はAlibabaのQwenファミリーのモデルに依存している。

これは単に、小さなモデルが大きなモデルと競合するという話ではない。Microsoftは、多くのエージェントワークフローが、汎用LLMをあらゆる問題への答えとして扱うべきではないと主張している。その主張が成り立つなら、市場は単一モデルのアプリケーションから、専門化されたモデル群によるパイプラインへ移行する可能性がある。

Microsoft Decision-1モデルが実際に変えるもの

Microsoft Decision-1は、構造化された選択を自由形式の生成から切り分け、ソフトウェアが直ちに利用すべき判断のための専用モデルを開発者に提供する。

従来のLLMは、アプリケーションがカテゴリー、スコア、あるいはYesかNoの回答だけを必要とする場合でも、通常はテキストを返す。その後、ソフトウェアは応答を解析し、その表現が許可されたアクションに対応するかを判断しなければならない。この追加の解釈はレイテンシーを増やし、別の障害点も生む。

Decision-1は固定された選択肢を受け取り、それらの選択肢に対する確率を返す。YesかNoの判断、多肢選択式の質問、開発者定義のルーブリックに基づくスコアに対応する。Microsoftはこれを単一パスの意思決定スコアリングと説明しており、モデルはまず長い推論応答を生成することなく、提示された証拠を評価することを意味する。

例えばサポートアプリケーションでは、顧客メッセージを渡して、Decision-1に緊急度レベルを選択させることができる。同じリクエストで、どのチームがケースを受け取るべきか、人によるレビューが必要かも尋ねられる。アプリケーションコードは、段落からラベルを抽出せずに、こうした範囲が限定された回答を読み取れる。

Decision-1も言語モデルを起点としているため、この違いは見落としやすい。Microsoftによると、より限定された振る舞いに向けてQwen3.5-9Bをポストトレーニングした。そのため、モデルは言語理解を保ちながら、プログラムによるアクション向けに設計された出力を提示する。

Microsoftは、想定される用途としてルーティング、分類、優先順位付け、検証、データラベリング、ワークフロー制御を挙げている。ほかにも、AIの応答評価、提案されたエージェントアクションの確認、検索結果のランキング、インシデント報告の振り分けなどが例として示されている。

こうしたタスクはエージェントシステム全体に現れる。エージェントはモデルを選択する前にリクエストを分類し、生成後に下書きを採点し、別のツールを呼び出すべきかを判断するかもしれない。各段階で大規模な推論モデルを使用すると、遅延と不要な計算が積み重なる可能性がある。

Microsoftは、その蓄積を単純な時間の例で説明している。20件の連続した判断のそれぞれに100ミリ秒を加えると、ワークフローには2秒が追加される。開発者がチェックポイントや分岐を増やすほど、高速な分類器の価値は高まる。

同社の発表分析によると、Decision-1はMicrosoftによる36ベンチマークの比較で最高精度を記録した。これらのベンチマークには、ルーティング、ランキング、多言語入力、長いコンテキスト、安全性、推論などの領域を網羅する、約15万件の質問が含まれていた。

Microsoftはまた、Decision-1が比較対象の次点となる高速モデル、H2O-Lightning-4Bより2.5倍高速だったとしている。GPT-6 Solと比べた中央値のレイテンシーは約35分の1だったと報告した。これらの数値は独立したベンチマーク機関ではなく、Microsoft自身の評価によるものだ。

このモデルは、AIモデルの発見、評価、デプロイのための同社プラットフォームであるMicrosoft Foundryを通じて利用できる。Vercelも、モデル識別子microsoft/microsoft-decision-1を用いてAI Gateway経由で提供を開始した。

この発表が変えるのは、AIが理解できる内容というより、利用可能なアーキテクチャだ。開発者はすでに、ルーティングに従来型の分類器、ルール、埋め込み、小規模LLMを使用している。Decision-1は、複数の範囲限定型の意思決定フォーマットを共通のモデルインターフェースにまとめている。

このパッケージ化により、専門化された意思決定レイヤーを導入しやすくなる可能性がある。また、モデルが会話的な文章ではなく型付きの予測を返す、発展途上のソフトウェアカテゴリーの中心にMicrosoftを位置付ける。

このニュースは、アプリケーションチームに具体的な問いを投げかける。既存のLLM呼び出しのうち、本当に生成的なものはいくつあるのか。かなりの割合が事前定義された選択肢から選ぶだけなら、Decision-1は、ますます高コストになっている設計習慣に対するMicrosoftの答えを提示する。

Microsoftが意思決定を生成から切り離す理由

Decision-1は、単一構造のAIアシスタントから、各タスクを適切な形状のモデルに割り当てるモジュラーシステムへの、より広範な移行を反映している。

初期の生成AIアプリケーションでは、ほぼすべてのリクエストを1つの最先端モデルに送ることが多かった。同じエンドポイントでテキストの要約、チケットの分類、フィールドの抽出、応答の作成を行えたため、このアプローチはプロトタイプを簡素化した。アプリケーションのトラフィックやエージェントのステップが増えるにつれ、その魅力は薄れていった。

本番システムには、デモでは見えにくい3つの圧力がある。モデル呼び出しのたびにレイテンシーが加わる。トークンごとに計算能力が消費される。自由形式の応答は、フォーマットや後続処理の振る舞いに関する不確実性を生む。

意思決定モデルは、出力空間を狭めることでこうした圧力に対処する。文書化された4つのアクションから選ぶよう求められたモデルは、5つ目を書く必要がない。選択したアクションと、コードが評価できる信頼度の値を返せる。

信頼度シグナルは重要だが、慎重な解釈が必要だ。MicrosoftはDecision-1の確率をキャリブレーションしたいと考えている。90%にキャリブレーションされた予測は、比較可能なケース全体で10回中およそ9回正しいはずだ。

これは、90%というスコアが基礎となる事実を検証することを意味しない。提示された証拠と基準のもとで、モデルが自身の回答にどの程度の確信を持つかを表す。開発者は、自らのデータでそのスコアが信頼できるかを知るため、依然としてラベル付きの例を必要とする。

VercelのDecision-1ガイドは、この境界を具体的に示している。モデルはユーザーの報告を分類できるが、報告された製品上の問題が実際に存在することを確立するわけではないと指摘する。その製品を管理するシステムが権威となる。

この役割分担は、よりモジュラーなエージェントアーキテクチャを示唆する。生成モデルは曖昧な目標を解釈したり応答の下書きを作成したりできる。その後、Decision-1が下書きを採点し、経路を選択し、人間がレビューすべきかを判断できる。

判断が完全に決定論的である場合、ルールは引き続き適切だ。組織が大量のラベル付きかつ安定したデータを保有する場合、従来型の機械学習分類器も魅力的である。Decision-1は、入力が自然言語で表現される一方、出力は宣言された境界内に収める必要がある領域を担う。

この位置付けにより、固定的なルールエンジンより柔軟性を得られる。開発者はあらゆる表現を手作業で符号化する代わりに、言語で基準を説明できる。それでも汎用LLMより自由度は低く、それこそが狙いである。

Microsoftは、同等の入力は同等の判断につながるべきだとしている。堅牢性テストでは、選択肢の並べ替えや無害な書式変更の導入を含む8通りの方法でリクエストを変更した。同社によると、Decision-1はこうした摂動に対して平均1.3%で回答を変更した。

Microsoftのテストでは、選択肢の説明を言い換えたり、選択肢を逆順にしたりシャッフルしたりした際に、モデルは回答を一度も変えなかった。判断がアプリケーションの分岐を制御する場合、一貫性は重要である。同等の選択肢が別の順序で表示されたという理由だけで、ユーザーが異なるワークフローに到達すべきではない。

繰り返すが、これらはベンダーが報告した結果だ。Microsoftはモデルを設計し、評価フレームワークを選定し、比較結果を公表した。開発者はこれらの数値をテストの代替ではなく、テストする理由として扱うべきだ。

複数のプラットフォームを通じたモデル公開は、その評価を加速させる可能性がある。Microsoft FoundryはAzure志向のチームに直接的なデプロイ経路を提供する。Vercelのゲートウェイは、型付き選択、スコア、Boolean質問をサポートする意思決定インターフェースを介してモデルを公開する。

OpenRouterでの提供も、潜在的な利用者層を広げる。これらの配布チャネルは、Decision-1を既存の分類器やLLMプロンプトと比較するために必要なセットアップを減らす。

したがって、この発表はワークロードのレベルで汎用モデルプロバイダーに圧力をかける。Decision-1は、文章作成、コーディング、リサーチにおいて最先端モデルを上回る必要はない。十分な数の反復的な意思決定呼び出しを、許容可能な精度と低いレイテンシーで処理できればよい。

これはより狭い競争だが、潜在的には大きなものになり得る。エージェントアプリケーションは、ユーザーに見える応答1件ごとに、多数の内部的な判断を生成できる。こうしたアプリケーションが拡大するにつれ、見えないルーティングや評価の呼び出しがインフラの重要な部分になる可能性がある。

MicrosoftのQwen基盤が戦略を複雑にする

最も示唆的な詳細は、Microsoftの専門特化型モデルがQwen3.5-9Bから始まり、Microsoftが将来のバージョンをMAIおよびOpenAIモデルにリベースする予定である点だ。

Microsoftは長年、顧客を単一のプロバイダーに縛り付けるのではなく、幅広いモデルカタログを推進してきた。Decision-1は、その思想をモデル自体に持ち込んでいる。最初の基盤はQwenに由来する一方、将来の基盤にはMicrosoftとOpenAIが含まれると明言されている。

これは実用的なエンジニアリングだ。既存モデルをポストトレーニングすれば、Microsoftは意思決定の振る舞い、評価セット、構造化インターフェース、デプロイ体験に集中できる。基盤モデルをゼロから構築すれば、こうした範囲限定タスクを必ずしも改善することなく、時間とコストが増える。

同時に、戦略上は居心地の悪い選択でもある。MicrosoftはOpenAIに多額の投資を行い、自社のMAIファミリーも構築している。Qwen上でMicrosoftの名を冠したモデルを発表したことは、別の基盤モデルが当面のエンジニアリング目標に適している場合、モデルの出自が二次的になり得ることを示している。

Microsoftはこの出自を隠していない。技術投稿では、Decision-1は高速な単一パスのスコアリングに向けてQwen3.5-9Bをポストトレーニングして作られたとしている。また、将来の反復ではOpenAIおよびMAIモデルにリベースするとも述べている。

このロードマップは、Decision-1を単なる1組の重みより大きなものに変える。永続的な製品は、Microsoftのトレーニング手法、意思決定API、ベンチマークスイート、Foundryの配布レイヤーとなる可能性がある。その下にあるベースモデルは変更できる。

これは、アプリケーション開発者がすでにデータベースやクラウドインフラを扱う方法に似ている。開発者が重視するのは安定したインターフェース、予測可能な振る舞い、運用上の制御だ。こうした契約が維持される限り、基盤となる実装は進化できる。

Microsoftのアプローチは、モデルのブランド名が単一の基盤アーキテクチャを指すべきだという前提にも異議を唱える。Decision-1は、代わりに役割を表す名称だ。その目的は、言語表現をどの基盤モデルが提供するかにかかわらず、制約された選択肢を迅速にスコアリングすることにある。

したがって、主な競争軸はMicrosoft対Qwenではない。特化型の意思決定システム対汎用LLM呼び出しである。QwenはMicrosoftがどのように市場へ到達したかを示す補足的な文脈ではあるが、製品が直面する主戦場を定義するものではない。

OpenAIやその他のモデルプロバイダーも、同じアーキテクチャ上の問いに直面している。最先端システムは分類や評価を実行でき、多くの場合で高い精度を発揮する。しかし、そうした能力があるからといって、あらゆる社内意思決定において最良の運用上の選択肢になるとは限らない。

より小規模な特化モデルは、より汎用的な能力を獲得しなくても勝てる。予測可能な出力、より高速な応答、より簡単なパース、そして低いインフラ需要によって成功できる。これは、広範な知能を重視するベンチマーク競争とは異なる最適化目標である。

Microsoftの社内事例は、この位置づけをさらに裏付けている。Xbox ResearchはDecision-1を用い、アンケート、Steam、Xから得た1万件超の自由記述フィードバックを分類した。研究者がテーマを定義し、モデルがフィードバックをそのカテゴリーに振り分けた。

Microsoftによれば、このタスクでモデルはGPT-6 Solと競争力のある品質を示しながら、14倍以上高速に動作したという。また大幅なコスト優位性も報告しているが、組織は自らのデプロイ条件でこの比較を再現すべきだ。

Copilotチームは、このモデルをチャットおよびエージェントの応答評価に使用した。Microsoftによると、Decision-1はGPT-5.6 Lunaと競争力のある品質を示しつつ、100倍高速に動作した。

Microsoftはまた、エンジニアがログ、チケット、メッセージ、通話、その他の情報源から関連知識を取得するインシデント対応にもこのモデルを試験した。同社は、この検索関連の意思決定タスクにおいてDecision-1がLLMよりも高い性能と速度を示したとしている。

これらの例は依然として社内ケーススタディである。特定可能なワークロードを説明しているため抽象的な約束より有用だが、実装と報告の両方をMicrosoftが管理している。

Xboxの例は、顧客インタビュー、製品レビュー、サポートメッセージを扱うチームにとって特に関連性が高い。制約された分類器は大量のフィードバックを整理でき、ナレッジシステムはレビューのために元の資料を保持できる。チームは、各テーマの割り当ての根拠となった証拠にも引き続きアクセスできなければならない。

この分離は個人のワークフローでも有用だ。モデルはラベルや優先順位を提案できる一方、個人ナレッジベースは基礎となるメモや情報源を利用可能な状態に保つ。分類は、記録そのものを置き換えることなく検索性を向上させるべきである。

MicrosoftがQwenを明示したことは、将来の比較基準も生み出している。同社がMAIベースのDecision-1後継モデルをリリースすれば、開発者は基盤を変更しつつ、Microsoftがレイテンシー、キャリブレーション、一貫性を維持したかを検証できる。

ベンチマークは自動化に関する問いを決着させない

高速かつ高精度なベンチマーク結果は、監督なしで高影響のワークフローをDecision-1に制御させても安全だということを立証するものではない。

Microsoftは、約15万問を含む36のベンチマークでこのモデルを評価した。また、有害コンテンツ、プロンプトインジェクション、ジェイルブレイクの試みを対象とする11のベンチマークから得た5,250件のリクエストを用いて、安全性も試験した。

これらは意義ある評価の取り組みだが、ベンチマークの広さはデプロイ固有のエラーをなくすものではない。サポート振り分けモデルは全体として良好に機能しても、まれな医療、法務、セキュリティ関連のリクエストを繰り返し誤処理する可能性がある。

同じ懸念は、キャリブレーションされた確率にも当てはまる。キャリブレーションは事例の分布に依存する。あるリクエスト構成でテストされたモデルは、ユーザーの言葉遣い、ポリシー、製品が変化した場合に過信する可能性がある。

したがって開発者は、意図するワークロードからラベル付けされた事例に対してDecision-1を評価しなければならない。テストセットには通常のケース、曖昧なケース、不完全な証拠、敵対的な入力、そして2つのカテゴリーがもっともらしく適用できる事例を含めるべきだ。

チームは平均精度だけでなく、自信度の高い誤りを検証すべきである。自信度の低い誤りはレビューへ回せる。一方、高い確信を伴う誤答は自動アクションを引き起こしやすい。

Microsoftは、自信度を行動、保留、レビュー依頼の判断機構として提示している。この設計が有用なのは、チームが使用予定の閾値でエラー率を測定する場合に限られる。すべてのカテゴリーに適した普遍的な自信度の閾値は存在しない。

必要な証拠は、その結果によって決まるべきだ。顧客フィードバックの自動タグ付けは、アカウントのブロックよりリスクが低い。検索結果の優先順位付けは、支払いの承認や本番インフラの変更とは異なる。

Decision-1は、開発者が記述する基準にも依存する。曖昧または重複するカテゴリー記述は、モデルが設計どおりに動作していても不安定な挙動を生む可能性がある。構造化出力は、不適切に構造化された意思決定を修復できない。

アプリケーションは、アクションポリシーを予測から分離して維持しなければならない。モデルは、あるインシデントがセキュリティキューに属すると推定できる。それでもアプリケーションコードは、許可されるアクションを強制し、監査証跡を保持し、不確実なケースをエスカレーションすべきである。

エージェントがツールを呼び出せるようになると、これはさらに重要になる。Microsoftは、エージェントが継続、停止、再試行、または別のモデルや人への作業引き継ぎを行うべきかの判断を含め、エージェント制御をユースケースとして挙げている。その時点での誤った選択は、その後のステップに影響を与えうる。

エージェント制御モデルは、他のモデルが生成した入力にも直面する。これらの入力には、ハルシネーション、不正な形式の計画、外部ソースからコピーされたプロンプトインジェクションの内容が含まれる可能性がある。Decision-1独自の安全性試験は、周囲のすべてのアーキテクチャにわたる保護を保証するものではない。

Microsoftは、有害なリクエスト、ジェイルブレイク、プロンプトインジェクションをテストしつつ、有用な挙動を維持したとしている。独立評価では、これらの結果を再現する必要がある。また、分類対象の文書やWebページ内に悪意ある指示が現れる間接的なプロンプトインジェクションもテストすべきである。

同社の科学的発見の例にも同様の注意が必要だ。Microsoft Discoveryは、実験を評価し、計画を修正する適応型の再計画ループを使用する。Microsoftは、Decision-1が大幅に一貫性の高いスコアを生成し、再計画プロセスを加速したと報告している。

一貫性は長期にわたる実験の助けとなりうる。しかし、それは科学的正確性を立証するものではない。一貫して誤った評価基準は、繰り返される作業を非生産的な経路へ導く可能性がある。

このため、Decision-1は当初、疑う余地のない権威ではなく、測定可能なコンポーネントとして機能すべきである。開発者は予測をレビュー担当者に示し、修正を収集し、実際のエラーを観察した後に限定的なカテゴリーを自動化できる。

組織はデプロイ後の監視も必要とする。新製品、変化するポリシー、季節的な言語、ユーザー行動は、入力分布を変化させうる。ローンチ時の評価に合格したモデルでも、重みをまったく変更せずに性能が劣化する可能性がある。

意思決定ログには、入力、基準、利用可能な選択肢、選ばれた回答、確率値、モデルバージョン、下流のアクションを保持すべきである。この記録により、チームは誤りを調査し、将来のモデル改訂を比較できる。

これらの統制はMicrosoft固有のものではない。あらゆる意思決定モデル、分類器、LLMベースの評価器に適用される。Decision-1は出力をソフトウェアが扱いやすくするが、運用上の単純さを認識論的な確実性と混同してはならない。

したがって、パブリックプレビューというラベルには意味がある。Microsoftは開発者に評価すべき製品を提供しており、あらゆる分類システムの確立された代替品を提示しているわけではない。最も有用な初期デプロイは、範囲が限定され、元に戻せて、測定可能なものになるだろう。

Microsoft Decision-1ローンチ後に注目すべきこと

Decision-1が標準的なエージェントコンポーネントになるのか、それとも興味深いFoundryの選択肢にとどまるのかは、3つのシグナルによって決まる。

第1のシグナルは、独立したベンチマーク再現である。Microsoftが報告した速度、精度、キャリブレーション、堅牢性は、強力なローンチ根拠を形成している。外部の研究者や本番チームは今、透明なハードウェアとワークロード条件の下で同じ主張を検証する必要がある。

有用な独立評価には、従来型分類器、コンパクトLLM、最先端モデル、競合する意思決定システムを含めるべきだ。測定すべきものは集計精度だけではない。レイテンシーの分布、キャリブレーション誤差、障害の安定性、入力シフト後の性能も重要である。

Microsoftの数値に近い独立結果は、特化モデルの論拠を強めるだろう。大きな差があれば、ローンチ時のベンチマークが有利な条件やワークロードを捉えていたことを示唆する。

第2のシグナルは、MAIおよびOpenAIの基盤モデルへの計画的な移行である。Microsoftは後続のイテレーションでこれらのモデルファミリーを使用するとしているが、基盤変更が挙動にどう影響するかはまだ明らかにしていない。

後継モデルは、測定可能な性能を改善しながら構造化APIを維持すべきである。開発者は、確率値が比較可能なままか、プロンプトを問題なく移行できるか、従来の閾値が引き続き機能するかを知りたいはずだ。

広範な再テストを強いる基盤変更は、Decision-1を安定した製品レイヤーとする考え方を弱める。円滑な移行は、ベースモデルを交換可能な実装詳細として扱うMicrosoftの戦略を支持するだろう。

第3のシグナルは、Microsoft自身のチームを超えた本番導入である。Xbox、Copilot、インシデント対応、Microsoft Discoveryは有用な実証例を提供するが、いずれもベンダーの組織内にある。

外部のケーススタディは、ワークロード、ベースライン、レビュー工程、測定されたエラーコストを開示すべきである。時間を節約しつつエスカレーションを増やすルーティングシステムは、正味の改善をもたらさないかもしれない。フィードバック分類器は、重要な少数派のテーマを隠すことなく手作業による仕分けを減らせるなら成功しうる。

導入状況は、開発者が専用の意思決定APIと、使い慣れたチャット補完インターフェースのどちらを好むかも示すだろう。構造化された意思決定フォーマットはより明確な契約を提供するが、チームはすでにプロンプトやJSON出力を中心とした広範なツール群を持っている。

開発者が明確に区別されたモデルの役割を中心にエージェントパイプラインを設計し始めれば、Decision-1は戦略的に重要になる。あるモデルが生成し、別のモデルが検索し、Decision-1が分類または制御する。知能を担うのは単一のモデルではなく、アプリケーションそのものになる。

このアーキテクチャは新たなエンジニアリング作業を生む。チームはコンポーネント間の意思決定を追跡し、バージョンを管理し、各ステップをどのモデルが担うかを決めなければならない。また、システム全体を表す共有評価データも必要になる。

その見返りは、より大きな制御性だ。モジュール型パイプラインは、本当に難しいケースのために高価な推論を確保できる。反復的な分類はより高速なモデルに送り、不確実な出力は人に回すことができる。

ナレッジワーカーにとって、実用上の影響は多くの場合、目に見えないままである。より高速な分類は、目に見える文章を生成することなく、受信資料を整理し、通知に優先順位を付け、リクエストを振り分けられる。それでも、こうした隠れた意思決定の質は、ユーザーが目にするものを形作る。

このようなワークフローを評価する人は、直接的な問いを投げかけるべきだ。システムは、なぜある項目がそのラベルを受けたのかを示し、元の証拠を保持できるだろうか。ナレッジブレンディングのためのツールは、ユーザーがソース資料を横断して作業する助けになるが、それだけで信頼できない意思決定ポリシーを修正することはできない。

Microsoft Decision-1が注目に値するのは、CEOがそのローンチを発表したからではなく、汎用LLMをデフォルトで利用するという前提に挑戦しているからだ。MicrosoftはQwen3.5-9Bを制約付きの意思決定エンジンへと変え、Foundryで拡大を続けるモデルカタログに加えた。

同社のベンチマーク結果は、このモデルを試す価値があることを示している。ただし、それによって予測の正しさが自動的に検証されるわけではなく、重要なワークフローにおける人間のレビューが不要になるわけでもない。

開発者は、すでにラベル付きの事例があり、明確なフォールバック手段もある限定的な意思決定から始めるべきだ。Decision-1を既存の手法と比較し、高い確信度で生じた誤りを精査したうえで、単一のベンチマークスコアではなくワークフロー全体を測定する必要がある。

特化型の意思決定モデルはAIエージェントの制御レイヤーになるのか。それとも、進化した汎用モデルが同じ役割を担うのか。答えは、独立したテスト、Microsoftが約束するリベース、そして実運用から得られる証拠によって明らかになるだろう。