Ollama v0.34.3、推論機能の発見を容易にする一方で、モデルメタデータには信頼性が求められる
Ollama v0.34.3は、9月19日のリリースから4日後、開発者による推論制御の見つけ方を変えた。モデル情報APIは現在、モデルが受け付けるthinking設定と、デフォルトで使う設定を報告できる。一見すると小さなメタデータ追加に見える。しかし実際には、拡大しつつある統合上の問題に対処している。推論モデルはもはや、予測可能な単一のオン・オフ切り替えを共有していない。
このリリースでは、MLXを通じてApple Silicon上のNemotron H visionもサポートする。macOSアプリのウィンドウ復元動作を変更し、Hugging Faceからのモデル取得も修正した。これらを合わせると、v0.34.3はプレリリース扱いのままではあるものの、単なる定例パッチ以上の更新となる。
中心的な競争軸は、宣言的な設定と実行時に発見可能な挙動の間にある。開発者は各モデルに関する前提をハードコードすることも、選択されたモデルが何をサポートするかをOllamaに問い合わせることもできる。Ollamaは後者に賭けているが、有用なメタデータはランタイムが実際に行うことを正確に記述しなければならない。
Ollama v0.34.3が実際に変えるもの
最も重要な追加は、モデル固有の推論制御に関する機械可読な契約である。
Ollamaの`v0.34.3 changes`によると、モデル情報エンドポイントは現在、各モデルでサポートされるthinking値とデフォルト値を公開する。たとえばglm-5.3-flash:cloudへのリクエストでは、low、high、maxが返され、maxがデフォルトとして識別される場合がある。
レスポンスの該当部分は次の構造に従う。
同じ情報は、コマンドラインからollama showでも取得できる。Gemma 4に関するリリース例では、バイナリ値であるfalseとtrueが報告され、trueがデフォルトとされている。ollama.comを通じてホストされるクラウドモデルも、このメタデータを公開できる。
この違いは重要だ。なぜなら、「thinking」はもはや一様な機能ではないからである。Boolean値を受け付けるモデルもあれば、複数の推論努力レベルを公開するモデルもある。すべてのモデルにfalseを送るクライアントや、すべてのモデルがmediumを理解すると仮定するクライアントは、いずれエラーまたは意図しない挙動を引き起こす。
Ollamaは、thinking出力を通常の回答内容ではなく、独立した推論フィールドとして定義している。公式の`thinking controls`ドキュメントでは、Boolean設定と、サポートされる場合のlow、medium、high、maxを含む名前付き努力レベルが説明されている。正確な選択肢は引き続きモデル依存だ。
この新しいレスポンスは、モデルを実行したり、推論動作を変更したりするものではない。モデルがサポートすると主張する制御値をクライアントに伝える。これにより/api/showは発見メカニズムとなり、ソフトウェアは生成リクエストを構築する前に能力を確認できる。
OllamaのAPI型もこの設計を補強している。リポジトリでは、推奨設定を任意の値のリストとデフォルト値として表現し、Boolean制御と文字列制御を単一のレスポンス形式で扱えるようにしている。`Show API schema`も同様に、Booleanまたは名前付きthinking値を許容している。
このリリースには、さらに3つの変更が含まれる。Nemotron H visionモデルがMLXを介してApple Siliconでサポートされ、macOSアプリはユーザーが以前に閉じたウィンドウを再び開かなくなり、Hugging Faceからのモデル取得には修正が加えられた。
リリースノートは、正確なHugging Faceの障害モードを説明しておらず、Nemotron Hの性能測定値も公開していない。これらの欠落は、導ける結論に妥当な限界を設ける。文書化された事実はサポートと修正に関する主張であり、ベンチマーク結果や、影響を受けたすべての構成が現在動作することの証明ではない。
このリリースはGitHub上でプレリリースとしてもマークされている。本番導入を評価する開発者は、この新しい挙動を、暗黙のアップグレード前提ではなく検証可能なソフトウェアとして扱うべきだ。価値は明確だが、導入への信頼は各チームのモデルとワークフローに対する検証から得なければならない。
モデルを意識したthinking制御が今重要な理由
推論制御は、目立たないモデルパラメータではなく、アプリケーションインターフェースの一部になった。
かつて開発者には、レスポンスを要求するか、しないかという比較的単純な選択肢があった。推論能力を持つモデルは、さらに別の次元を加える。アプリケーションは現在、モデルに熟考させるか、どの程度の努力を使わせるか、その推論トレースをインターフェースに表示するかを判断する。
こうした選択は、レイテンシー、リソース使用量、出力構造、ユーザーの期待に影響する。コーディングエージェントは、困難なリポジトリ変更に対してより高い推論レベルを要求するかもしれない。要約ツールは、タスクが定型的な場合には直接的な回答を優先するかもしれない。
課題は、モデルごとに異なる制御面を公開することだ。あるモデルはtrueとfalseをサポートし、別のモデルは複数の名前付きレベルを認識する。3つ目のモデルはデフォルトで推論を有効にし、完全な無効化を許可しない可能性がある。
Ollamaは、GPT-OSSがBooleanトグルではなくlow、medium、highを受け付けると文書化している。他のサポート対象モデルはBoolean設定を受け付けられる一方、選ばれたモデルはより広い範囲のレベルを認識する。このばらつきにより、普遍的なハードコード設定は信頼できないものになる。
v0.34.3以前は、アプリケーションが独自の互換性マップを維持できた。このアプローチは即座に保守作業を生む。新たに追加されるモデル、テンプレートの変更、デフォルトの改定はいずれも、アプリケーション内部のマップを古くする可能性がある。
新しいメタデータは別の道を提供する。アプリケーションは選択したモデルを確認し、有効な制御だけを表示し、報告されたデフォルトを事前選択できる。同じクライアントでも、あるモデルにはトグルを表示し、別のモデルにはレベル選択を表示できる。
モデルピッカーを備えたデスクトップチャットアプリケーションを考えてみよう。ユーザーがGemma 4を選択した場合、インターフェースはオン・オフ制御を提示できる。ユーザーが段階的な努力レベルを持つクラウドモデルを選んだ場合、インターフェースは報告された正確なレベルを提供できる。
この改善は自動化にも有用だ。サービスは、ジョブ開始後に互換性のない値を発見する代わりに、起動時に設定を検証できる。これにより、回避可能な実行時障害を、より早期で明確なチェックへと移せる。
エージェントフレームワークには、さらに注目すべき理由がある。これらはしばしば、タスクの複雑さ、プライバシー要件、利用可能なハードウェアに応じてプロンプトをモデル間でルーティングする。能力発見により、ルーターは選択したモデルに対して望ましい推論ポリシーが有効かどうかを判断できる。
ここでOllamaは、llama.cppやvLLMのようなプロジェクトを含む他のローカル推論インターフェースに圧力をかけている。問題は、それらのシステムが推論モデルを実行できるかどうかではない。圧力は、周辺アプリケーションがモデル固有の挙動をどれほど一貫して発見・設定できるかから生じる。
優れた推論性能を持つランタイムでも、クライアントが各モデルの特殊ケースを把握しなければならなければ、統合上の摩擦を生みうる。逆に、信頼できるメタデータは、多様なモデルカタログを一つの一貫したプラットフォームのように感じさせられる。
この比較を誇張すべきではない。Ollama v0.34.3は業界全体の能力標準を確立するものではない。Ollama独自のAPI内で有用な契約を定義するものであり、アプリケーションは引き続き、その契約を適切な挙動へ変換する責任を負う。
この更新によって、ドキュメントも不要になるわけではない。開発者は依然として、可視化されたthinking内容が自社製品に適しているかを理解する必要がある。推論設定がプライバシー、ログ、ユーザー体験、タスク固有の品質とどう相互作用するかを判断しなければならない。
変わるのは、基本的な互換性知識の置き場所だ。それが完全にアプリケーションコード内に存在する代わりに、一部はモデルとランタイムに付随できる。報告される値が正確であり続ける限り、これはモデル切り替えにとってより良い基盤となる。
真の変化はハードコードされたフラグから実行時発見へ
Ollamaは推論設定を発見可能なモデルメタデータへ変え、検証をなくすことなく推測を減らしている。
この仕組みは、モデル検査リクエストから始まる。クライアントは、チャットまたは生成リクエストを送る前に、名前付きモデルの情報を/api/showに問い合わせる。レスポンスには現在、モデルがサポートするthinking値とデフォルト値を含められる。
次にクライアントは、それらの値を独自のポリシーにマッピングする。コマンドラインツールは、オペレーター向けにそれらを出力できる。グラフィカルインターフェースはトグルまたはメニューを構築できる。オーケストレーション層は、トラフィックを受け入れる前に無効なデプロイメント設定を拒否できる。
これは軽量な形式の能力ネゴシエーションである。能力ネゴシエーションとは、通信方法を選ぶ前に双方がサポートするオプションを識別することを意味する。Webプロトコル、データベース、ハードウェアインターフェースでは、長年にわたり類似のパターンが使われてきた。
AIアプリケーションにとっての利点は、ユーザーインターフェースの洗練にとどまらない。開発、テスト、本番環境にまたがる設定ドリフトを減らせる可能性がある。同じ発見ステップを、ローカルワークステーション、管理環境、ollama.comのクラウドモデルに対して実行できる。
チームが一つの推論モデルで開発し、後からデプロイ先を変更する場合を考えてみよう。ハードコードされたthink: true設定は、名前付きレベルを期待するモデルでは意図したポリシーを表せない可能性がある。ハードコードされたhigh値も、代替モデルがBooleanの選択肢しかサポートしない場合には失敗しうる。
発見機能を使えば、アプリケーションはその不一致を明示的に特定できる。モデルのデフォルトを選ぶことも、内部の「balanced」ポリシーを有効なレベルへマッピングすることも、対処可能なエラーとともに停止することもできる。いずれの結果も、同等の意味を持つと暗黙に仮定するより望ましい。
デフォルトは特に重要だ。サポート値のリストはソフトウェアが要求できるものを示し、デフォルトはフィールドを省略したときに何が起きるかを示す。この違いは再現性に影響する。省略された制御も、依然として設定上の判断だからである。
モデル出力を比較するチームは、モデル名だけでなく実効設定を記録する必要がある。同じモデルに対する2回の実行でも、一方がデフォルトを使い、もう一方がより低い努力レベルを指定すれば、異なる挙動を示す可能性がある。発見可能なデフォルトにより、この隠れた変数を可視化しやすくなる。
メタデータは可観測性も改善できる。アプリケーションは、各デプロイメントとともにサポート値、要求値、デフォルトをログに記録できる。モデル更新後に挙動が変わった場合、オペレーターは原因を見つけるためのより多くの文脈を得られる。
ただし、発見機能は新たな依存関係も導入する。クライアントは、ランタイムのメタデータが実際の実行と一致することに依存するようになる。モデルがfalseで推論を無効化すると報告しながら、推論内容を出力し続ける場合、その契約は誤解を招くものになる。
このリスクは、一般にモデル統合において理論上のものではない。モデルテンプレートは設定を異なる形で解釈する可能性があり、互換性レイヤーはフィールドを破棄または変換することがある。モデルパッケージの更新によっても、対応するクライアントリリースなしに挙動が変わる可能性がある。
Ollama自身のドキュメントでは、thinking出力は最終レスポンスから分離されるとされている。実際には、クライアントは選択したモデルがストリーミングおよび非ストリーミングのリクエストで期待どおりのフィールド構造を生成するか、依然としてテストする必要がある。メタデータは有効な入力選択を説明するものであり、観測可能なすべての結果を説明するものではない。
クラウドサポートは、価値と検証負担の両方を拡大する。ローカルのモデルパッケージとクラウドホスト版は、異なるスケジュールで変更される可能性がある。アプリケーションは一つのレスポンスを無期限にキャッシュするのではなく、実際に呼び出す環境を検査すべきである。
セキュリティおよびプライバシーチームも、推論コントロールを慎重に扱うべきです。モデルの推論を公開する設定は、アプリケーションが表示、保存、またはテレメトリーへ送信し得る追加コンテンツを生み出します。検出可能性によりコントロールの管理は容易になりますが、適切な保持ポリシーを決めるものではありません。
したがって、この新しいエンドポイントは、より広範な起動時チェックの一段階として使うのが最適です。成熟したクライアントは、機能を確認し、意図した設定を検証し、小規模な挙動プローブを送信し、有効な構成を記録できます。このプロセスにより、メタデータは運用上の確信へと変わります。
AIシステムを保守する開発者にとって、これが今回のリリースにおける最大の教訓です。未来は、単一の汎用的な推論フラグではありません。モデル、ランタイム、アプリケーションが対応可能な挙動について合意する、交渉型のインターフェースです。
Apple Siliconサポートでリリースの対象が広がるが、根拠は依然として限定的
Nemotron Hのビジョンサポートにより、Apple Siliconユーザーには新たなローカル・マルチモーダルの選択肢が加わる。ただし、リリースには速度や品質のベンチマークは示されていない。
リリースでは、Nemotron HのビジョンモデルがMLXを用いてApple Silicon上で動作するようになったとされます。ビジョンモデルはテキストとともに画像を処理するため、アプリケーションはテキストのみを受け付けるのではなく、スクリーンショット、文書、図表、写真を分析できます。
MLXは、Apple Silicon向けに作られた機械学習用配列フレームワークです。公式の`MLX framework`はPython、C++、C、Swiftのインターフェースを提供し、Appleのユニファイドメモリアーキテクチャを利用します。この設計により、最新のMacでのローカル推論に関連性があります。
Ollamaユーザーにとって実用上の変化は、文書化された性能向上ではなくアクセス性です。対応するNemotron Hビジョンモデルは、別途NVIDIA GPU環境を必要とせず、Macベースのローカルワークフローの一部にできます。
開発者は、このようなモデルを用いてテスト中にインターフェースのスクリーンショットを検査できます。プライベートな文書ワークフローでは、モデルのライセンスと組織独自のセキュリティ管理を前提に、ページ画像をローカルで分析できます。
元画像に独自の素材が含まれる場合、ローカルであることは重要です。管理下にあるマシンで推論を維持すれば、入力を外部サービスへアップロードする必要性を減らせます。ただし、アプリケーションが別の場所へデータを記録または送信する可能性は依然としてあるため、プライバシーを自動的に保証するものではありません。
Nemotron HファミリーはNVIDIAのモデル開発に属し、一方でMLXはAppleハードウェアを対象としています。Ollamaはこれら二つの世界を結ぶ互換性レイヤーとして機能しています。これは、比較的一貫した開発者インターフェースの背後に多様なモデルをパッケージ化するという、このプロジェクトのより広い役割を示す有用な例です。
それでも、リリースノートにはスループット、メモリ、精度、対応量子化に関する数値はありません。どのAppleチップをテストしたかも明らかにされていません。読者は「対応」を「すべてのMacで高速」または「NVIDIAデプロイメントと同等」と解釈すべきではありません。
ビジョンワークロードは要求が厳しい場合があります。モデルサイズ、画像解像度、コンテキスト長、量子化、利用可能なユニファイドメモリはいずれも、構成が実用的かどうかに影響します。特定のMacに対する唯一信頼できる答えは、代表的なローカルテストです。
同じ注意はモデル品質にも当てはまります。ランタイムの対応は、対応パスを通じてモデルを読み込み、呼び出せることを意味します。文書抽出、インターフェース理解、その他の専門的なタスクにおけるモデルの回答を検証するものではありません。
macOSのウィンドウ変更は、別種の信頼性に対応しています。Ollamaによれば、アプリケーションをアクティブ化した際、ユーザーが閉じたウィンドウをアプリが再び開かなくなります。これはモデル機能ではありませんが、ユーザーの意図とアプリケーション状態の間にある煩わしい不一致を解消します。
デスクトップの挙動は、リリース概要が示唆する以上に採用へ影響する場合があります。ローカルAIランタイムはバックグラウンドで正しく動作していても、そのグラフィカルシェルが繰り返しユーザーの作業空間を妨げる可能性があります。閉じたウィンドウを尊重することで、アプリは予測可能なシステムユーティリティにより近い感覚になります。
Hugging Face pullの修正も同様に控えめなものです。Hugging Faceのモデルリポジトリには大容量でバージョン管理されたファイルが含まれることがあり、ダウンロードにはリダイレクト、キャッシュ、複数のストレージホストが関わる場合があります。公式の`Hub download path`では、ファイルが別個のストレージおよびコンテンツ配信エンドポイントを経由する可能性が説明されています。
Ollamaは、pullパスのどの部分が失敗していたのかを指定していません。したがって、v0.34.3がHugging Faceに関連するすべてのプロキシ、認証、ゲート付きモデル、ネットワークの問題を修正すると主張するのは不正確です。
以前に失敗を経験したユーザーは、同じモデル参照とネットワーク条件で、まったく同じpullを再実行すべきです。また、完了後に想定どおりのリビジョンとダイジェストであることも確認すべきです。転送の成功は、再現可能なモデルデプロイメントの一部にすぎません。
これらの追加変更により、リリースは推論メタデータを超えて広がります。モデル、ハードウェアバックエンド、リモートレジストリ、オペレーティングシステムの挙動を調整しなければならないデスクトップおよび開発者向けツールとして、Ollamaの位置づけを強化しています。
この広がりはリスクでもあります。対応する組み合わせが増えるたびに、回帰が起き得る領域も増えます。あるモデルファミリーやダウンロードパスに対する修正は、公開された互換性マトリクスや、一般的な環境を横断した再現可能なテストの代わりにはなりません。
メタデータ契約には依然として本番テストが必要
懐疑的な問いは単純だ。広告されたコントロールは、各モデルの実際の挙動と一貫して一致するのか。
/api/showの追加が検出の問題を解決するのは、その回答が正確であり続ける場合に限られます。古いデフォルト値や非対応の値は、メタデータがない場合よりも悪い可能性があります。アプリケーションがそれを信頼し、防御的なチェックを省略するかもしれないためです。
結果には複数のコンポーネントが影響し得ます。Ollamaのサーバーはリクエストを解析し、モデルレンダラーは設定をプロンプト形式へ変換し、モデルテンプレートはそれらの指示を解釈します。クラウドルーティングがさらに別のレイヤーを加えることもあります。
API境界で有効な値であっても、明確な挙動上の効果を保証するものではありません。単純なプロンプトでは、二つの推論レベルが似た出力を生み出す場合があります。モデルのテンプレートやバックエンドが想定されるコントロールを実装していないため、設定を無視することもあります。
この区別は、構文的サポートと意味的サポートを分けるものです。構文的サポートとは、ランタイムが値を受け入れることです。意味的サポートとは、その設定が意図した方向にモデルの挙動を確実に変えることです。
Ollamaのメタデータが主に扱うのは、第一のカテゴリです。リリースノートは、列挙されたすべてのレベルが推論の深さ、トークン使用量、レイテンシ、回答品質を変えることを示す実験を提示していません。開発者は、values配列が存在することからそうした結果を推測してはなりません。
デフォルト値も、乖離の原因になり得ます。サーバー、モデルパッケージ、ホステッドサービスは、有効なデフォルトについて合意している必要があります。メタデータが更新されないまま一つのコンポーネントが変更されると、同一のリクエストを再現することが難しくなり得ます。
キャッシュにも注意が必要です。クライアントは一度モデルを確認し、その結果を保持する場合があります。そのキャッシュされた機能レコードは、モデル更新、サーバーアップグレード、クラウド側のリビジョン後に古くなる可能性があります。
アプリケーションは、可能な限り機能メタデータを具体的なモデルIDに関連付けるべきです。モデルダイジェストまたはランタイムバージョンが変わった際には更新すべきです。長期間稼働するサービスでは、管理されたデプロイメントチェック中に再検証することもできます。
本番テストで、プライベートな推論トレースをエンドユーザーに公開する必要はありません。各対応設定で小規模かつ決定論的なプロンプトを送信し、応答構造、エラー処理、レイテンシの大まかな違いを検証できます。機密性のあるトレース内容は、通常のログから除外すべきです。
チームはフォールバックも定義すべきです。要求されたレベルがなくなった場合、サービスは新しいデフォルトを使用すべきか、最も近い有効設定を選ぶべきか、それともデプロイメントを拒否すべきか。この判断は、推論努力がコスト、レイテンシ、コンプライアンス、ユーザー向け品質に影響するかどうかに依存します。
高価値なワークフローにおいて、暗黙的なフォールバックは最も危険な選択肢です。コードレビューやデータ分析を行うエージェントは、構成変更後に異なる挙動を示す可能性があります。アプリケーションが意図するポリシーがもはやモデルと一致しない場合、運用担当者はそれを把握する必要があります。
プレリリースというラベルは、段階的なデプロイメントを特に適切なものにします。開発者は重要度の低い環境から始め、代表的なモデルを確認し、以前のOllamaバージョンと結果を比較できます。主要なワークフローが通過するまで、ロールバックの選択肢を維持すべきです。
Nemotron Hパスにも同等のテストが必要です。ユーザーは、実際のAppleハードウェアでロード時間、ピークメモリ、画像処理レイテンシ、出力品質を測定すべきです。一つのサンプルが成功しただけで、完全な検証とみなすべきではありません。
Hugging Faceの修正は、以前に失敗したモデル参照に対してテストすべきです。プロキシまたは制限的なファイアウォールを使う組織は、必要なすべてのストレージホスト名を検証しなければなりません。Hubのダウンロードアーキテクチャは、メインWebサイトへのアクセスだけではすべてのファイル転送が許可されない可能性を意味します。
これらの注意点は、リリースの価値を損なうものではありません。有用なAPI設計と信頼できる運用契約の境界を示すものです。Ollamaは機能に関する真実を置く場所を作りました。その真実を正確に保つには、継続的なテストが必要です。
Ollama v0.34.3が持ちこたえるかを示す三つのシグナル
次の試金石はクライアントによる採用であり、その後に挙動の正確性とより広範なハードウェア検証が続く。
第一のシグナルは、Ollamaクライアントが新しいthinkingオブジェクトを利用し始めるかどうかです。インターフェースが一つのグローバルコントロールをハードコーディングし続ける限り、メタデータフィールドの影響は限定的です。アプリケーションがBooleanトグルやモデル固有の努力レベルメニューを動的に描画するようになれば、採用は明確になります。
その反応は、リリースの中心的な考え方を強化します。ランタイム検出が、単に新たなレスポンスフィールドを加えるだけでなく、実際の統合作業を減らすことを示すためです。採用が見られなければ、クライアントがこの契約を不完全と見なしているか、内部マッピングで置き換えるほうが容易だと判断している可能性があります。
第二のシグナルは、広告された値と実際の出力の不一致をユーザーが報告するかどうかです。最も重要なテストは、異なるコントロール形状を持つモデル、特にバイナリ構成と多段階構成に関するものです。
一貫した結果はOllamaのアプローチを支持し、アプリケーションがエンドポイントを信頼する後押しとなります。メタデータがヒントとして有用であり続けても、不一致が繰り返されれば自動構成の根拠は弱まります。
関連する証拠には、リクエストがエラーを返すかどうか以上のものが含まれるべきです。開発者は応答フィールド、可視化された推論挙動、レイテンシ、おおよそのトークン使用量を比較すべきです。また、報告されたデフォルト値を確認するため、設定を省略したテストも行うべきです。
第三のシグナルは、Apple Siliconシステム全体におけるNemotron Hビジョンの動作品質です。報告には、モデルバリアント、チップ世代、メモリ容量、量子化、画像ワークロード、Ollamaバージョンを記載すべきです。
詳細な結果は、ユーザーが正式なサポートと実用的な使いやすさを区別する助けになります。一般的なMac構成が代表的なビジョンタスクを確実に処理できれば、v0.34.3はローカル・マルチモーダルアクセスを意味のある形で拡大したことになります。
Hugging Face pullの信頼性とmacOSのウィンドウ挙動も重要ですが、より単純な合否判定です。推論メタデータとMLXモデルパスには、より大きなアーキテクチャ上の意味合いがあります。
Ollama v0.34.3を評価する開発者は、すでにデプロイしているモデルの確認から始めるべきです。返されるthinking値を現在のアプリケーションの前提と比較し、ユーザーに公開する前に各対応設定をテストしてください。
社内向けAIツールを構築するチームは、こうした知見を検索可能なエンジニアリング・ナレッジベースに記録すべきです。構造化された`技術ナレッジベース`は、モデルのバージョン、ハードウェアの結果、設定上の判断、観測された回帰を結び付けられます。
直近の対応は控えめです。テスト環境でアップグレードし、/api/showを呼び出して、実際の生成結果に照らして仕様を検証します。より大きな問いは、モデルメタデータがアプリケーションコード内に散在する互換性マップを置き換えられるほど信頼できるものになるかどうかです。
Ollama v0.34.3は、信頼に足る出発点を提供します。クライアントがこのフィールドを採用し、動作が公表された制御内容と一致すれば、推論設定の自動化は容易になるでしょう。相違が積み重なれば、開発者は引き続き各モデルを個別の特例として扱うことになります。
