オープンウェイトAIはユーザーに制御権を与えるが、オープンソースにはより高い基準が求められる

Google Newsは、欧州で新たな規制執行が始まる数日前、AIをめぐるおなじみの対立を改めて取り上げた。ダウンロード可能な重みがあるからといって、モデルが自動的にオープンソースになるわけではない。

この違いは、開発者が学習時の判断を監査し、モデルを再現し、制約のあるライセンスの下で導入しようとするまでは、単なる用語の問題に聞こえるかもしれない。オープンウェイトAIは学習済みパラメータを公開する一方、オープンソースAIは、意味のある改変に必要な資料へのアクセスと、より幅広い権利を約束する。

この違いは今や、Meta、Google、モデル配布者、エンタープライズの購入者、規制当局にとって実務的な意味を持つ。中心的な争点は、もはやオープンモデルとクローズドAPIの対立ではない。「オープン」という言葉を業界が柔軟に使うことと、具体的な自由、文書化、ライセンスを求める正式な基準との対立だ。

Google NewsがオープンウェイトAIをめぐる論争を再燃させる

今回の報道が重要なのは、ダウンロードページが似ていても、「オープン」という言葉が実質的に異なる複数の公開形態を指すようになっているためだ。

Google Newsを通じて配信されたFierce Networkの見出しは、答えるのが難しい基本的な問いを投げかけている。オープンウェイトAIとオープンソースAIを分けるものは何か。短く言えば、アクセス、法的権利、再現可能性だ。

モデルの重みとは、学習によって生成される数値パラメータである。これらは、学習済みモデルが入力を出力へと変換する仕組みを決定する。これらのパラメータを公開すれば、別の主体も、すべてのリクエストを元の提供者に送ることなくモデルを実行できる。

このアクセスは、ローカル推論、プライベート環境への導入、ファインチューニング、独立したテストを支援し得る。企業は自社のセキュリティ境界内にモデルを置ける。研究者はリモートインターフェースに全面的に依存せず、挙動を調べられる。

しかし、重みはモデル開発の成果物の一つにすぎない。そこから、すべての学習データ源、データフィルタリングの判断、評価手順、最適化設定が分かるわけではない。また、モデルの利用や再配布について無制限の法的許可を自動的に与えるものでもない。

このため、開発資料が不完全なダウンロード可能モデルには、通常「オープンウェイト」という表現のほうが正確だ。これは提供者が何を公開したかを示すものであり、すべての構成要素が確立されたオープンソース基準を満たすことを意味しない。

オープンソースAIは、より広い約束をする。Open Source AI Definitionは、ユーザーがAIシステムをあらゆる目的で利用、研究、改変、共有できなければならないとしている。

こうした自由は、完全なシステムとその関連コンポーネントを対象としなければならない。したがって、この定義ではモデルパラメータ、学習・推論コード、そして学習データに関する十分に詳細な情報が求められる。

このデータ要件は、保護された、あるいは非公開の学習項目をすべて公開することを求めるものではない。だが、熟練者が実質的に同等のシステムを構築できる程度に、出所、範囲、選定、ラベリング、処理に関する情報を提供することは求める。

これは、チェックポイントファイルを公開リポジトリに置くことより高い基準だ。パラメータを読み込み、応答を生成する推論コードを公開するだけでも足りない。

このGoogle News上の議論は、時期的にも重みを増している。欧州当局は、より新しいモデルに対する汎用AI義務の本格施行を2026年8月2日に控えている。

欧州委員会によれば、これらの義務は当初、2025年8月2日に適用開始となった。その後の1年は、提供者との協力にも一部焦点を当てた移行期間だった。

この用語は今や、コミュニティでの評判以上のものに影響する。文書化義務、規制上の免除、調達時のレビュー、下流の開発者が利用できる証拠に影響を与え得る。

読者にとって重要な変化は、ダウンロード可能なモデルの存在そのものではない。そうしたモデルは長年利用可能だった。変化したのは、オープン性の主張が、定義された技術的・法的基準に照らしてますます検証されるようになったことだ。

なぜオープンウェイトへのアクセスはオープンソースに及ばないのか

オープンウェイトはユーザーに運用上の制御権を与えるが、オープンソースにはシステムを理解し再構築するために必要な自由と情報も求められる。

企業がモデルをダウンロードした後に何が起こるかを考えてみよう。エンジニアはパラメータをホストし、性能を測定し、量子化を適用し、社内の事例を使ってモデルをファインチューニングできる。

量子化は、メモリと計算の要件を下げるために、モデル値の精度を落とす処理だ。ファインチューニングは、特定のタスク向けに挙動を調整するため、より狭いデータセットで学習を継続することを指す。

これらの機能には価値がある。ホステッドプロバイダーへの依存を減らし、機密性の高いプロンプトを管理されたインフラ内に保てるようになる。

しかし、これらのいずれも、元のモデルがどのように作られたかを必ずしも明らかにしない。エンジニアは、どのデータソースがその挙動を形作ったのかを知らない場合がある。前処理コード、学習設定、中間チェックポイント、元の評価スイートが不足していることもある。

この隔たりは再現可能性を制限する。研究者が体系的な失敗を発見した場合、出力を調べ、利用可能なパラメータを変更することはできる。しかし、その失敗をデータの選択にまで遡ったり、元の学習プロセスを再現したりできるとは限らない。

ライセンスも別の境界線を作る。提供者は重みを公開しながら、特定の用途、ユーザー数、再配布、競合サービスに制限を課すことができる。

こうした制限には、正当な商業的または安全上の目的があるかもしれない。それでも、個別の許可なしにあらゆる目的での利用を求める定義を満たすことは妨げる。

したがって、このラベルが示すのは単一の二値状態ではなく、スペクトラムだ。ある公開物は幅広いアクセスを提供しながら、学習データを非公開にする場合がある。別の公開物はコードを開示していても、重みに用途分野の制限を付ける場合がある。

Linux FoundationのModel Openness Frameworkは、このスペクトラムを評価するためのより詳細な手法を提示している。モデル開発ライフサイクル全体の17要素を評価するものだ。

Class IIIは、アーキテクチャ、パラメータ、基本的な文書をオープンライセンスで提供するレベルを対象とする。Class IIでは、主要なデータセットに加え、学習、評価、推論のツール群が追加される。

Class Iでは、生の学習データセット、中間チェックポイント、ログ、広範な研究文書までパッケージに含める。このレベルは、エンドツーエンドの科学的再現可能性を目指す。

こうした階層により、購入者は曖昧なラベルを具体的な質問に置き換えられる。どの成果物が利用可能か。各成果物にはどのライセンスが適用されるか。別のチームがそれらを調査、改変、再配布できるか。

その答えは日常業務で重要になる。例えば、医療ソフトウェアベンダーが、ローカルでホストでき、専門文書向けに適応可能なモデルを求めているとする。

オープンウェイトは導入要件を満たすかもしれない。しかし、学習コーパスに不適切な資料が含まれていたか、ライセンスが意図する商用ワークフローを許可するかという問題までは解決しない。

セキュリティチームは別の問題に直面する。ローカルアクセスにより、敵対的テストと導入済みパッケージの検査が可能になる。一方、学習に関する詳細が欠けていれば、記憶化、隠れたバイアス、異常な失敗パターンの調査は依然として制約される。

機密情報向けのツールを選ぶナレッジワーカーも、関連する問題に直面する。ダウンロード可能なモデルはローカル処理を支援し得るが、モデルのオープン性だけでは、アプリケーションが個人文書をどのように扱うかは決まらない。

アプリケーションのストレージ、検索、ログ、権限設計も依然として重要だ。personal knowledge baseを評価するユーザーは、モデルのラベルだけでなく、データ経路全体を評価すべきだ。

したがって、オープンウェイトは欠陥のあるカテゴリではない。明確な運用上の利点を持つ、有用な配布モデルだ。問題は、提供者や論評者がそれを完全なオープンソースと同等のものとして提示するところから始まる。

そうした置き換えは、購入判断から重要な情報を取り除く。また、ライセンスや開発の透明性が大きく異なる二つの公開物を、比較可能に見せてしまうこともある。

Metaとオープンソース基準は異なる方向へ引っ張られている

Metaの立場は中心的な対立を表している。モデルメーカーは実用的なオープン性を望む一方、標準化団体は企業の裁量を越えて存続する自由を求めている。

Metaは、ダウンロード可能な基盤モデルを商業・研究の大きな力へと押し上げる役割を果たした。同社のLlama公開は、クローズドなホステッドシステムに全面的に依存する以外の選択肢を開発者に与えた。

これらのモデルは、単純な期待を広めることに貢献した。高性能なAIモデルは、ローカルテスト、カスタマイズ、開発元のクラウド外での導入に利用できるべきだという期待だ。

MetaはLlamaを頻繁にオープンソースと表現してきた。しかし、同社のライセンスと開示の慣行は、その表現をめぐる継続的な意見の対立を生んでいる。

Open Source Initiativeは2024年10月、AI定義のバージョン1.0を公開した。この公開により、緩やかな用語論争は標準をめぐる直接的な対立へと変わった。

Metaは、一つの定義で現代のAI開発の複雑さを完全に捉えられるという考えを退けた。同社の広報担当者は、従来のソフトウェア定義では急速に進化するAIモデルを包含できないと述べた。

この対立は、学習データの開示にも一部焦点を当てたopen-source disputeに記録されている。MetaはLlamaの重みを利用可能にしているが、OSIの枠組みで求められるすべての要素を公開しているわけではない。

双方の立場は現実的な制約に対応している。モデル開発者は、公開、ライセンス取得済み、生成、利用制限付きの膨大な資料を混合して学習を行う。すべての項目の公開は、プライバシー、契約、セキュリティ、著作権上の義務と衝突し得る。

標準の擁護者は、ユーザーには出所と処理に関する意味のある情報がなお必要だと反論する。それがなければ、システム全体を研究したり、実質的に同等のモデルを作ったりできない。

OSIの定義は、すべてを公開する代わりに詳細情報を求めることで、利用できないデータに対応しようとしている。共有できないデータを説明し、学習資料をどのように取得、選定、ラベル付け、フィルタリングしたかを明らかにするよう、提供者に求める。

この妥協案にも批判はある。一部のオープンソース支持者は、真の再現を目指すなら、データの説明で元のデータセットを置き換えることはできないと主張する。

一方で、すべての学習コンポーネントを求めれば、大半の大規模モデルにとってこのラベルは到達不能になると考える人もいる。その見方では、過度に厳格な定義は、根本にある法的障壁を解決しないまま、有用な公開を減らすことになる。

この対立を、Meta対透明性という構図に単純化すべきではない。Metaには、自社モデルを軸に大規模な開発者コミュニティを支援する動機がある。同時に、高価な学習手法を守り、影響の大きい用途への制御を維持する動機もある。

OSIには異なる組織的役割がある。ユーザーの自由、改変、再配布を軸に発展してきた用語の意味を守ることだ。

このインセンティブの違いは、一方が実用的な利用可能性を重視する理由を説明する。もう一方は、下流の自由が完全で、法的に信頼でき、元の提供者から独立しているかを重視する。

Googleの立場は、企業のカテゴリ分けが単純なラベルに収まりにくい理由を示している。GoogleはGeminiを通じてクローズドなサービスを提供する一方、ダウンロード可能なGemmaモデルも公開している。

単一の企業が、ホステッド、オープンウェイト、より透明性の高い研究という戦略を同時に追求することはあり得る。したがって、分析の単位として重要なのは企業全体のブランディングではなく、個々のモデルリリースとライセンスである。

同じ考え方はMistral、Alibaba、その他のモデル開発企業にも当てはまる。各リリースでは、ウェイト、コード、データに関する情報、利用権の組み合わせが異なる場合がある。

エンタープライズの購入者は、導入前にこうした組み合わせを文書化すべきだ。「オープンソース」とだけ記されたチェックボックスが一つの調達フォームでは、最も重要な詳細が見えなくなる。

より確かなレビューでは、少なくとも四つの問いを分けて考える。組織はパラメータを入手できるか。それを実行・改変できるか。成果物を再配布できるか。元のシステムがどのように作られたかを検証できるか。

こうした問いは、オープンウェイトAIの実用的な利点を維持しつつ、「オープンソース」という呼称を本来の意味以上に拡張しないために役立つ。

Google Newsの見出しがエンタープライズ購入者に意味すること

この用語の違いは現在、法的リスク、技術的な独立性、そしてエンタープライズのリスクレビューで得られる証拠の量を左右する。

最も差し迫った懸念はライセンスだ。モデルはダウンロード可能であっても、企業がオープンソースソフトウェアに期待するすべての権利を付与するとは限らない。

チームは、統合やファインチューニングに投資する前にライセンスを確認すべきである。パイロット段階では管理可能に見える制約も、製品が顧客を獲得したり新たな市場に参入したりすれば重大になり得る。

再配布には特に注意が必要だ。企業はモデルを社内で運用できても、顧客向けソフトウェアに組み込む際には異なる条件に直面する可能性がある。

利用制限も確認を要する。一部のライセンスは、定義された有害行為を禁じたり、非常に大規模なサービス向けの権利を留保したり、標準的なオープンソースライセンスでは認められない条件を課したりする。

第二の懸念はサプライヤーへの依存だ。オープンウェイトは、顧客が実行可能なモデルのコピーを保持できるため、運用上のロックインを減らせる可能性がある。

ただし、その保護には限界がある。組織は依然として、独自のトレーニングデータ、文書化されていないツール群、特定のハードウェアスタック、または元のプロバイダーが管理する更新に依存する可能性がある。

切り替えコストも上流へ移ることがある。一つのモデルファミリーを中心に大規模なファインチューニング、検索、評価システムを構築した企業は、置き換えに高いコストがかかる場合がある。

オープンソースAIは、その構成要素が再構築と改変を可能にする場合、理論上はより強い独立性を提供する。もっとも、実際の独立性は依然としてエンジニアリング能力と計算資源に左右される。

アクセス可能であっても、運用コストがなくなるわけではない。ダウンロード可能なモデルには、インフラ、監視、セキュリティパッチ、評価、熟練した人材が必要となる。

ホステッドシステムでは、その負担の多くをプロバイダーに移転できる。その代償として、モデルの挙動、更新時期、リクエスト処理に対するコントロールは小さくなる。

第三の懸念は証拠だ。規制対象の組織は、システムがなぜそのように動作するのか、またどのような管理策が講じられているのかを説明しなければならないことが多い。

完全なトレーニングデータへのアクセスがあっても、大規模ニューラルネットワークを完全に解釈可能にするわけではない。それでも、詳細なデータ情報、評価コード、トレーニング文書は監査の改善に役立つ。

オープンウェイトは独立した挙動テストを支える。オープンなツール群があれば、こうしたテストを開発者の元の手順と比較しやすくなる。

この違いは、企業が雇用、与信、医療、教育、または重要インフラにAIを用いる場合に重要になる。こうした用途では、基盤モデル自体を規律するルールを超える義務が発生する可能性がある。

EU AI Actは、その重要性を示している。欧州委員会のGPAI guidelinesでは、一定の自由かつオープンソースのリリースは、複数の文書化要件の免除を受けられる可能性があるとされている。

この免除には条件がある。ライセンスはアクセス、利用、改変、配布を認めなければならず、パラメータ、アーキテクチャ、利用情報は公開されていなければならない。

これは著作権ポリシーやトレーニングコンテンツの要約に関する義務をなくすものではない。また、システミックリスクをもたらすと分類された汎用AIモデルも対象外ではない。

委員会は、10^25回を超える浮動小数点演算でトレーニングされたモデルについて、プロバイダーがその分類に異議を申し立てる機会を条件として、システミックリスクを推定する。当局は能力や影響に基づき、他のモデルを指定することもできる。

システミックリスクモデルのプロバイダーには、評価、インシデント報告、リスク軽減、サイバーセキュリティに関する義務が課される。モデルがオープンソースであっても、これらの要件は適用される。

この枠組みでは、安易なラベリングは危険である。マーケティングページが、モデルをオープンと呼ぶだけで規制上の免除を生み出すことはできない。

エンタープライズは、プロバイダーの規制上の地位が自動的に下流へ移転すると考えるべきではない。顧客の義務は、その役割、改変、導入コンテキスト、意図する用途によって決まる。

委員会によれば、ほとんどのファインチューニングは、改変者を新たな汎用AIモデルのプロバイダーにはしない。そのガイドラインは、元のトレーニング計算量の3分の1を超える場合に結び付く例外的なしきい値を示している。

これは通常の適応にとって安心材料となる。ただし、下流システムを、その固有のリスク区分に関連する要件から免除するものではない。

セキュリティチームにも、バランスの取れた評価が必要だ。オープンなパラメータにより、防御側はベンダーのインターフェースに依存せずモデルを検査・テストできる。

同じアクセスは、悪意ある行為者が安全策を外したり、悪用を最適化したりする助けにもなり得る。クローズドAPIはパラメータへの直接アクセスを制限する一方で、コントロールと可視性を一つのプロバイダーに集中させる。

どちらの形態も自動的に安全というわけではない。より適した選択は、脅威モデル、導入時の管理策、人員体制、接続されるデータの機微性によって決まる。

エンタープライズのレビューでは、あらゆるオープン性の主張を裏付ける証拠を記録すべきである。リポジトリが公開されているだけでは不十分だ。公開ファイルでも、制限的な条件が付されていたり、重要な開発資料が欠けていたりする可能性がある。

Google Newsの見出しが成功しているのは、実際の契約に影響するカテゴリーエラーを明らかにしているからだ。オープンウェイトは利用可能性を表す。オープンソースは、より広範な資料、権利、自由の組み合わせを表す。

真のトレードオフはコントロールと再現性の間にある

オープンウェイトAIは、科学コミュニティやオープンソースコミュニティが期待する再現性を提供せずに、導入におけるコントロールを最大化できる。

これが本稿の中心的なトレードオフである。利用者は推論を直接制御できる一方で、元の開発プロセスを再現することはできないままである。

この中間的な立場は、モデルベンダーにとって魅力的だ。トレーニングのレシピ、データセット、商業上の優位性を守りながら、導入と外部開発を促進できる。

多くの顧客にとっても魅力がある。大半の企業は、基盤モデルを最初から再トレーニングするつもりはない。

彼らが望むのは、高性能なシステムを非公開で運用し、より狭い領域へ適応させ、一つのAPIへのリクエストごとの依存を避けることだ。オープンウェイトはこうした目標を満たせる。

こうした購入者にとって、すべてのトレーニング成果物を求めても、直ちに得られる価値は小さいかもしれない。組織には、それらの資料を活用するための計算予算や専門知識が不足している場合がある。

研究者、監査人、公的機関には異なるニーズがある。データの来歴を調査し、実験を再現し、安全性に関する主張を検証し、モデルを独立して保存する必要があるかもしれない。

ウェイトのみのリリースでは、これらすべての目標を満たすことはできない。最終パラメータをファインチューニングすることは、上流のデータ選択を変更し、トレーニングを繰り返すことと同じではない。

プロバイダーが安全性やバイアスについて広範な主張をする場合、再現性の隔たりはより深刻になる。外部研究者は、そうした主張を検証するために、比較可能な評価コード、データセット、手順を必要とする。

モデルの挙動は導入後にも変化する。量子化、ファインチューニング、検索システム、システムプロンプトはいずれも出力を変え得る。

このため、責任の所在を割り当てることは難しい。障害は元のモデル、下流での改変、アプリケーション層、または利用時に提供されたデータに起因し得る。

完全なオープン性でも、この複雑さがなくなるわけではない。挙動がシステムのどこで生じたのかを連鎖的に検査し、特定する機会が増える。

完全開示の批判者が提起する安全上の懸念には正当性がある。詳細なトレーニング手法や制限のないウェイトを公開すれば、悪用への障壁が下がる可能性がある。

しかし、秘密性を完全な安全策として扱うことを裏付ける証拠はない。クローズドシステムも、インターフェースを通じて悪用されたり、盗まれたり、リバースエンジニアリングされたり、十分な監督なしに導入されたりする可能性がある。

オープンなリリースは防御を強化することもできる。独立した研究者は脆弱性を特定し、評価を構築し、大手プロバイダーが見落とした言語やコミュニティ向けにモデルを適応できる。

正しい結論は、すべてのモデルがすべての構成要素を公開すべきだということではない。プロバイダーが自らのリリースを正確に説明すべきだということである。

「オープンウェイト」は、完全な再現性を約束せずに意味のあるアクセスを伝える。「オープンソース」は、開示された基準を満たすリリースのために留保されるべきだ。

段階的なクラスを持つフレームワークは、より高い精度をもたらせる。Linux Foundationによる17コンポーネントのモデルは、成果物とライセンス全体でオープン性を測定できることを示している。

このアプローチは、完全にクローズドか完全に再現可能かという誤った二者択一を避ける。厳格な定義を最上位に保ちつつ、利用者が具体的な次元を比較できるようにする。

標準化された文書化があれば、こうした比較は容易になる。すべてのモデルカードに、ウェイトへのアクセス、アーキテクチャ、推論コード、トレーニングコード、データ情報、評価、ライセンス制限を記載できる。

また、カードでは公開済みの成果物と、将来の提供が約束された資料を区別すべきである。後によりオープンになる予定のリポジトリは、今それらの構成要素を提供しているリポジトリと同等ではない。

独立した検証も引き続き必要だ。大半のモデルカードはプロバイダー自身が作成しており、必須成果物の欠如が広い表現によって覆い隠される場合がある。

リポジトリホストやモデルカタログは、構造化されたオープン性フィールドを表示することで支援できる。ダウンロード可能なパラメータだけを根拠に、単一の「オープン」バッジを付与することは避けるべきだ。

エンタープライズチームも同じパターンを社内で採用できる。ライセンスや成果物はリリース間で変わる可能性があるため、レビュー記録には正確なモデルバージョンを記載すべきである。

この文書化は将来の移行を支える。また、法務、セキュリティ、エンジニアリングの各チームが、「オープン」の異なる解釈に頼るのではなく、同じ対象について議論できるようにする。

懐疑的な点も重要である。OSIの定義もLinux Foundationのフレームワークも、企業がより緩い用語を使うことを防ぐことはできない。

標準は、開発者、政府、購入者、配布プラットフォームによる採用を通じて影響力を得る。その実効性は、それらの主体が証拠を要求するかどうかにかかっている。

したがって、定義をめぐる議論は調達を通じても決着する。顧客が正確な開示を評価すれば、モデル開発企業にはより完全な資料を公開する理由が生まれる。

性能があらゆる意思決定を支配するなら、「オープンソース」は引き続き伸縮自在なマーケティング用語として機能するかもしれない。技術的な違いは残るが、多くの購入者がそれに直面するのは導入後だけになるだろう。

EUでの執行開始に伴い注視すべきこと

三つのシグナルによって、オープンウェイトAIとオープンソースAIが明確な市場カテゴリーになりつつあるのか、それとも単に別々のラベルにすぎないのかが分かる。

第一のシグナルは、2026年8月2日以降の規制上の取り扱いだ。欧州委員会は、その日から新しいモデルに対する汎用AI義務の全面的な執行を開始すると述べている。

プロバイダーが自由かつオープンソースの免除を主張するか、当局がその主張をどのように評価するかに注目したい。公開された判断は、ライセンス、利用可能なパラメータ、アーキテクチャ、利用情報をめぐる実務上の境界を示す可能性がある。

厳格で証拠に基づく取り扱いであれば、ここで説明した区別を強化する。プロバイダーのブランディングに基づく広範な免除であれば、それを弱める。

第二のシグナルは、Meta、Google、Mistralなどの開発元が公開するモデルリリース文書だ。新リリースについては、学習コード、データの来歴、評価資料、ライセンス変更を確認する必要がある。

より完全なパッケージが提供されれば、open weightとオープンソースの隔たりは縮まる。一方、継続的な制約を伴う重みのみの公開が続けば、ベンダーが中間的なカテゴリーを好んでいることが裏付けられる。

第三のシグナルは調達行動だ。大企業や公的機関は、モデル選定時に成果物レベルの質問をすることで、より明確な用語の使用を促すことができる。

重みの入手可能性と再配布権、再現可能性を区別する入札案件、ガバナンスポリシー、モデルカタログに注目したい。こうした変化は、標準を巡る議論を、持続的な購買要件へと変えるだろう。

Google Newsでは、単に「オープン」と説明されるモデルが今後も表示され続けるだろう。しかし読者は、その言葉に立ち止まるべきだ。どのファイルが利用可能か、どの権利が付与されているか、学習プロセスのどの部分が依然として非公開なのかを確認したい。そして、その答えを実際の用途に照らし合わせるべきだ。ローカル環境への導入には、アクセス可能な重みだけで足りる場合もあるが、監査や科学的な再現には、はるかに多くの情報が求められる。次のモデル発表は、そのラベルやベンチマークだけで判断すべきではない。利用可能であることをオープン性と見なす前に、ライセンス、開発資料、データ開示、規制上の状況を確認しよう。