ONEKEY、ファームウェアセキュリティ向けのエビデンスファーストAIエージェントを発表

ONEKEYは9月1日にAIエージェントを発表した。しかし本当の試金石は、自然言語による利便性が、ファームウェアセキュリティで求められる精度を維持できるかどうかだ。Google Newsの記事が示しているのは、単なる新たなサイバーセキュリティチャットボット以上のものだ。ONEKEYによれば、このアシスタントはファームウェア抽出、バイナリ検査、コンポーネント分析、脆弱性スキャンによって得られた証拠に基づいて回答する。

この違いは重要だ。ファームウェア分析では、経験豊富なセキュリティチームでさえ圧倒されかねない大量の検出結果が生成される。アシスタントは、これらの検出結果を検索、解釈、優先順位付けしやすくできる。一方で、モデルが文脈を失ったり、コンポーネントと脆弱性の関係を捏造したりすれば、誤解を招く要約を生む可能性もある。

ONEKEYは、代わりにエビデンスファーストの設計に賭けている。このエージェントは、分離された汎用モデルでファームウェアを分析するのではなく、既存のセキュリティおよびコンプライアンスプラットフォーム内で動作する。Finite State、Binarly、Microsoftといった競合各社はすでに組み込みソフトウェア分析の主要部分を自動化しており、チャットインターフェースだけでは防御可能な優位性はほとんど得られない。

この発表は、規制面でも微妙な時期に行われた。欧州の製造事業者は2026年9月11日から、新たなサイバーレジリエンス法の報告義務に直面する。検証済みの検出結果へ迅速にアクセスできれば、厳しい通知期限への対応に役立つ可能性がある。ただし、それは基礎となる証拠が正確で追跡可能な場合に限られる。

ONEKEY AI Agentは既存のスキャン証拠の上に位置する

ONEKEYはファームウェア分析プラットフォームのスキャナーを言語モデルに置き換えるのではなく、推論とクエリのレイヤーを追加している。

同社は2026年9月1日、デュッセルドルフでONEKEY AI Agentを発表した。ベータプログラムを経て、初回リリースは9月に予定されている。続くファームウェアセキュリティレポートでは、このシステムはプラットフォームの検出結果に直接接続された自然言語インターフェースとして説明された。

これらの検出は、AIエージェントがワークフローに加わる前に始まる。ONEKEYはファームウェアを抽出し、バイナリを調査し、コンポーネントを特定し、Software Bills of Materialsを作成し、脆弱性インテリジェンスを確認する。SBOMとは、製品に含まれるソフトウェアコンポーネントの構造化されたインベントリだ。

このプラットフォームは、コンポーネント間の関係を調査し、既知の脆弱性が特定のファームウェアイメージに関連するかどうかも評価できる。この作業によって、エージェントが質問への回答に使用する証拠が生成される。

セキュリティアナリストは、選択した製品バージョンに影響する重大な脆弱性を尋ねるかもしれない。別のユーザーは、脆弱なライブラリに接続しているコンポーネントを要求する可能性がある。するとアシスタントは、対応するプラットフォームの検出結果を自然言語で取得し、説明できる。

ONEKEYによれば、このエージェントはプラットフォーム内におけるユーザーの現在のコンテキストを認識する。ユーザーがファームウェア、SBOM、コンポーネント、脆弱性評価のどれを確認しているかに応じて、回答を変えられる。

このコンテキストに応じた動作により、各プロンプトで製品識別子や分析範囲を言い直す必要は減るはずだ。また、モデルが利用できる証拠を絞り込むことで、無関係な回答を減らすこともできる。

このエージェントは、プラットフォーム内で詳細なフィルタリングと分析を行うONEKEY Query Language、すなわちOQLをサポートする。ユーザーは自然言語の指示からOQLクエリを生成、説明、改善するようアシスタントに依頼できる。

この機能により、製品リスクは理解していても専門的なクエリを日常的に書かないエンジニアの利用障壁を下げられる可能性がある。経験豊富なアナリストも、生成されたロジックを確認する前に、複雑な検索の下書きとして活用できる。

クエリの下書きと、その意味の検証は依然として別物であり、その区別は重要だ。構文的に有効なクエリであっても、誤ったセキュリティ上の前提を表現している可能性がある。チームは、生成されたOQLの出力を修正やコンプライアンス判断の指針に使う前に確認すべきだ。

顧客はONEKEYが承認したモデルを利用するか、自社のモデルとAPI認証情報を接続できる。同社はこれらの展開オプションをBring Your Own ModelおよびBring Your Own Keyと説明している。

これらの選択肢は、厳格なデータ取り扱いポリシーを持つ組織にとって実務上の懸念に対応する。一部の購入者は、ファームウェアの検出結果、製品アーキテクチャ、脆弱性の詳細を共有外部モデルに公開することをためらうだろう。

モデルの選択だけでは、すべてのガバナンス上の疑問は解決しない。顧客は依然として、どのコンテキストが自社環境の外に出るのか、プロンプトがどのように保持されるのか、どの従業員が機密性の高い検出結果にアクセスできるのかを判断する必要がある。

ONEKEYは今回のリリースを、4段階のAIロードマップにおける最初のステップと位置付けている。同社によると、より広い目標は、製品セキュリティのワークフロー全体で人間の判断を補完するアシスタントだ。

この表現は有用な境界線を示す。当面の製品は既存分析へのインターフェースであり、あらゆる脆弱性判断を安全に担える自律システムではない。

Google Newsが規制の転換点でこの発表を取り上げた理由

欧州での報告期限が実務上の要件となる中、製造事業者が脆弱性トリアージの高速化を必要としているため、このタイミングは異例なほど好都合だ。

重要なサイバーレジリエンス法上の義務が始まる数日前、この発表はGoogle Newsで取り上げられた。9月11日から、製造事業者はデジタル要素を持つ製品に影響する、現実に悪用されている脆弱性や重大なセキュリティインシデントを報告しなければならない。

CRAの報告ルールでは、製造事業者が対象となる問題を認識してから24時間以内に早期警告を出すことが求められる。より詳細な通知は72時間以内に続けなければならない。

現実に悪用されている脆弱性については、製造事業者は是正措置または緩和措置が利用可能になってから14日以内に最終報告書を提出しなければならない。重大なインシデントには、別の最終報告期限が適用される。

こうした期限は、正しい証拠を迅速に見つける価値を高める。製品チームは数時間以内に、影響を受けるファームウェアバージョン、脆弱なコンポーネント、依存関係、悪用可能性に関する情報、利用可能な緩和策を特定する必要があるかもしれない。

課題は、単にCVE番号を見つけることではない。チームは、影響を受けるコンポーネントが実際に出荷済み製品に存在するかを確認しなければならない。また、その脆弱な機能が存在し、到達可能かどうかも判断する必要がある。

製造事業者はチップセットベンダー、OEM、オープンソースプロジェクトから提供されるソフトウェアに依存することが多いため、ファームウェアはこの作業を複雑にする。単一のデバイスにも、所有者、リリース履歴、更新メカニズムが異なるコンポーネントが含まれ得る。

AIインターフェースは、これらの記録を横断するナビゲーション時間を短縮できる。日常的に分析プラットフォームを使わないインシデント対応者、プロダクトマネージャー、法務チーム、経営層向けに、検出結果を要約することもできる。

この利点は、純粋に技術的というより組織的なものだ。スキャナーは依然としてファームウェアを正しく抽出し、コンポーネントを認識し、関連する脆弱性と照合しなければならない。エージェントは既存の証拠を取得しやすく、伝えやすくする。

これが、エビデンスファーストのアプローチが注目に値する理由だ。汎用チャットボットは、どのファームウェアイメージ、コンポーネントバージョン、スキャン結果が該当するかを把握せずに、洗練された説明を提供する可能性がある。

報道によれば、ONEKEYの設計は、プラットフォームの検出結果とユーザーコンテキストを通じて利用可能な情報に回答を限定している。この境界が説明どおりに機能すれば、各回答を技術記録まで遡りやすくなるはずだ。

規制対象のインシデント対応では、追跡可能性が重要になる。チームは、問題をどのように分類したか、どの製品が影響を受けたか、どの証拠が対応を裏付けたかを記録しなければならない。

アシスタントはこの初期ナラティブの作成を助けられる可能性がある。ただし同社は、規制当局が人間によるレビューなしにAI生成の要約を受け入れることを示す証拠を公表していない。提出情報に対する責任は、引き続き組織にある。

このタイミングは、競合するファームウェアプラットフォームにも商業的な圧力を生む。CRAへの備えを進める購入者は、プラットフォームがバイナリの検出結果をどれほど迅速に説明可能な判断へ変換できるかを、ますます評価するようになるだろう。

これにより競争の焦点は、検出される脆弱性の数を超えて広がる。ワークフローの速度、証拠の系譜、アクセス制御、報告支援、誤検知の削減が、主要な購入基準となる。

ONEKEYは、このエージェントをそうしたワークフロー上の要請に沿って位置付けている。Google Newsの見出しは製品発表を捉えているが、この機能が今重要である理由を説明するのは規制カレンダーだ。

エビデンスファーストAIは製品の中心的なトレードオフだ

AIエージェントを検証済みのスキャン証拠に限定すれば信頼性を高められるが、同時にアシスタントの完全性は基礎となる分析の完全性に左右される。

ONEKEYのCEOであるJan Wendenburgは、この設計をもっともらしい言語表現ではなく技術的精度を中心に説明した。同社のAI Agent発表で彼は、重要な問いはすべての回答が検証可能な技術的事実によって裏付けられているかどうかだと述べた。

この原則は、モデルが回答前に選択されたソース資料を受け取る検索拡張生成に似ている。モデルは一般的な学習知識や制約のない会話だけに全面的に依存しない。

この場合、検索レイヤーは製品固有のセキュリティ記録から情報を取得する。これには、抽出されたファームウェアファイル、バイナリ検査結果、特定済みのコンポーネント、SBOMデータ、脆弱性インテリジェンス、影響コンテキストが含まれ得る。

このアーキテクチャは、言語モデルでよく知られた弱点の一つに対処できる。モデルは、不確実または誤った回答であっても、検証済み情報と同じ流暢さで表現することが多い。

グラウンディングは、アシスタントが利用可能なプラットフォームデータを引用または反映すべきであるため、このリスクを狭める。また、回答を現在レビュー中のファームウェアイメージに結び付け続けることもできる。

ただし、グラウンディングは正確性を保証しない。モデルは取得したデータを誤読したり、重要な条件を省略したり、個別には正確な事実を組み合わせて裏付けのない結論を導いたりする可能性がある。

ソース証拠自体も不完全であり得る。暗号化されたファームウェア、特殊なパッケージ形式、未対応のファイルシステム、独自のコンポーネント改変は、自動スキャナーが抽出できる範囲を制限する可能性がある。

ONEKEYのドキュメントによれば、同社のオープンソースunblob抽出技術は、100種類を超えるアーカイブ、圧縮、ファイルシステム形式を認識する。対応範囲の広さは有用だが、すべてのベンダー形式や保護されたイメージをカバーする抽出エンジンはない。

コンポーネントの特定には別の不確実性が伴う。バージョンメタデータが欠落、変更、または誤解を招く場合がある。ベンダーは、脆弱性照合ツールが想定するバージョン文字列を変更せずに、セキュリティ修正をバックポートすることがある。

SBOMも、最終バイナリに実際に含まれるものではなく、サプライヤーが申告した内容を記述している場合がある。バイナリ由来のインベントリはそのギャップを埋める助けになるが、その完全性は依然として識別品質に左右される。

こうした制約が、この発表における主要なトレードオフを生む。モデルを証拠に限定することで、その発言はより説明可能になるが、同時にモデルが実際の証拠の欠落を埋めることも妨げられる。

セキュリティでは、この抑制が望ましい。有用なエージェントは、利用可能なスキャンでは回答を裏付けられないと明示すべきだ。洗練された修正推奨の背後に不確実性を隠すべきではない。

同社は、エージェントが根拠のない質問をどの程度の頻度で拒否するかを示す詳細な評価結果を公表していない。測定されたハルシネーション率や、アシスタントの有無によるアナリスト比較ベンチマークも開示していない。

また、複雑なセキュリティシナリオ全体でOQLをどれほど正確に生成するかを示す公表済みの証拠もない。クエリ生成は、意図したロジックと返された結果の両方に照らして検証する必要がある。

したがって、購入者は成功した製品デモ以上のものを求めるべきだ。曖昧なプロンプト、不完全なスキャン、矛盾するコンポーネント証拠、選択したファームウェアの文脈外にある質問を試験すべきである。

さらに、重要な主張のすべてが特定の検出結果にリンクしているかを確認すべきだ。表現がもっともらしく聞こえても、証拠への経路を示せない回答の監査価値は限られる。

優れた導入では、観測と解釈を分離する。インターフェースは、スキャナーが見つけたもの、モデルが推論したもの、そして人間がなお判断すべきことを明確に示すべきである。

evidence-firstという表現は、正しい目標を示している。実運用上の圧力の下でも製品がその境界を一貫して維持できるかは、独立した評価によって決まる。

自動化されたファームウェア分析はすでに競争市場となっている

ONEKEYが導入しているのは自動ファームウェアスキャンそのものではない。焦点は、得られた証拠を人々がどのように問い、行動に移すかをめぐる競争にある。

ファームウェア分析には長年にわたり、自動抽出、コンポーネント識別、脆弱性照合、暗号化マテリアルの発見、バイナリ堅牢化チェックが含まれてきた。これらの機能はすでに複数の商用プラットフォームに搭載されている。

Microsoftのfirmware analysis serviceは、組み込みソフトウェアコンポーネント、既知の脆弱性、不足している堅牢化対策、証明書、暗号鍵、パスワードハッシュを特定する。

Finite Stateは、バイナリ分析、ソーススキャン、SBOM管理、ポリシーチェック、継続的な脆弱性インテリジェンスを組み合わせている。platform documentationでは、コマンドライン、API、継続的モニタリングとの統合についても説明している。

Binarlyは、バイナリレベルの可視性、ファームウェアのサプライチェーン検証、到達可能性分析、サプライヤー提供のコンポーネント一覧の検証に重点を置く。各ベンダーの手法は異なるものの、いずれも申告されたソフトウェア内容と出荷済み成果物の間にあるギャップを対象としている。

ONEKEYが直ちに差別化できる点は、自社の検出結果を中心に構築された自然言語レイヤーとOQLレイヤーである。この設計は、検出後に人々が大量の結果を解釈し、優先順位を付けなければならない高コストな工程を対象にしている。

この問題は、スキャンで数百件の脆弱性候補が見つかった場合に深刻化する。アナリストは、コンポーネント名の一致と実際に悪用可能な状態を区別しなければならない。

ONEKEYはすでに、特定のファームウェアビルドに適用されない検出結果を絞り込むための自動影響評価を提供している。AIエージェントは、そうした評価記録をより多くのユーザーにとって利用しやすくできる。

たとえば、製品セキュリティマネージャーは、リリース済みのどのモデルに特定のコンポーネントが含まれるかを尋ねられる。インシデント対応担当者は、影響を受けるファームウェアバージョンと、そのステータスを裏付ける証拠を求められる。

開発者は、ある脆弱性が関連ありと判定された理由をアシスタントに説明させられる。コンプライアンス担当者は、複数の技術ビューをたどることなく、関連するコンポーネントおよび製品記録を取得できる。

これらのシナリオは、会話型アクセスが役立つ場面を示している。同じ証拠を、異なる質問をし、異なるレベルのプラットフォーム知識を持つ人々へつなぐからだ。

この機能は、専門アナリストの必要性をなくすものではない。誰かが悪用可能性を評価し、緩和策を検証し、矛盾する証拠を解消し、デバイス固有の導入条件を理解する必要がある。

また、統合作業も不要にはならない。製造業者には、最新の製品インベントリ、所有責任の記録、ファームウェアバージョン、技術的検出結果と出荷済みデバイスを確実に結び付ける情報が必要となる。

単一の分析プラットフォーム内で動作するエージェントが見られるのは、そこに存在する文脈だけである。不足している資産記録を自動的に修正したり、製品所有権をめぐる組織的な混乱を解消したりはできない。

競合他社も会話型インターフェースを追加できる。大手セキュリティプロバイダーはすでに、アラートトリアージ、インシデント調査、脆弱性管理製品全体にアシスタントを組み込んでいる。

このため、ONEKEYが独自の分析深度と検証可能なワークフロー成果を組み合わせない限り、インターフェース品質の優位性は一時的なものになる。より強固な参入障壁は、抽出範囲、コンポーネント精度、影響評価、証拠系譜にある。

モデルの柔軟性は、エンタープライズ購入者にとってなお重要になり得る。BYOMおよびBYOKへの対応は、モデル選択をプライバシー、データ所在地、調達要件に合わせるのに役立つ可能性がある。

ただし、柔軟性は独自の検証負担も生む。異なるモデルは、同一の証拠を異なって解釈する可能性がある。モデルのアップグレードによって、クエリ生成、要約、拒否動作も変わり得る。

ONEKEYには、こうした変化を可視化し続けるための管理策が必要になる。バージョン記録、評価スイート、承認ワークフロー、安定した証拠引用は、購入者がモデル差異を管理する助けとなる。

したがって競争上の問いは、ONEKEYがAIを追加したかどうかではない。結論とその根拠となる証拠との関係を弱めずに、エージェントが防御可能なセキュリティ作業を短縮できるかどうかである。

Google Newsの見出しでは裏付けられないこと

この発表はアーキテクチャと意図するワークフローを説明しているが、正確性、生産性、規制対応準備を独立して裏付けるものではない。

Security Todayの報道は、ONEKEYのリリースで説明された機能をほぼそのまま反映している。これは同社が発表した内容の確認にはなるが、製品性能の独立した検証ではない。

現在、代表的なファームウェアサンプルを対象に、エージェントと手作業の調査を比較する公開ベンチマークはない。同社は、平均的な時間短縮、エラー率、ベータユーザーからの導入データを開示していない。

また、承認済み設定を通じて利用できるモデル名も公表していない。モデルの能力、保持ポリシー、地域別の処理オプションは導入判断に影響し得るため、購入者にはこの情報が必要である。

「deterministic AI」という表現は慎重に解釈すべきだ。グラウンデッドなアーキテクチャはソース資料を制約できるが、言語モデルによる生成が自動的に決定論的になるわけではない。

出力は、モデルバージョン、サンプリング設定、取得された文脈、プロンプトの文言、会話履歴によって変わり得る。再現性には、スキャン結果をプロンプトに添付するだけでは足りず、追加の技術的管理策が必要となる。

回答が実際のプラットフォーム検出結果に依拠するという同社の主張は、より具体的で検証可能である。評価者は、各回答がソース記録を特定し、根拠のない結論を拒否するかを確認できる。

まずは敵対的なプロンプトから始めるべきだ。ユーザーが、不完全な抽出にもかかわらず製品が安全であると確認するようエージェントに求める場合がある。別のプロンプトでは、存在しないコンポーネント名を誤って指定することもあり得る。

理想的な応答は、前提に異議を唱え、証拠のギャップを明示し、断定的なセキュリティ判断を避けるものだ。自信に満ちた回答は、evidence-firstという約束を損なう。

生成されたOQLには、別個のレビュー工程が必要である。チームは、その出力を運用に使用する前に、要求されたロジック、生成されたクエリ、返された記録を比較すべきだ。

アクセス制御も未解決の領域である。会話型インターフェースは、製品の依存関係、露出した鍵、脆弱なコンポーネント、未リリースのファームウェア詳細など、機微な情報を取得しやすくする可能性がある。

組織は、エージェントが既存のテナント、プロジェクト、製品、ロールの境界を遵守することを確認しなければならない。プロンプトで要求されたからといって、より広範な記録を取得すべきではない。

プロンプトログも精査に値する。ログは価値ある監査証拠になり得る一方、脆弱性情報や機密の製品詳細を保持する可能性もある。

モデル接続システムは、信頼できないテキストを取り込む際にプロンプトインジェクションのリスクに直面する。ファームウェアファイルには、自動解釈に影響を与えるよう意図的に作られた文字列、ドキュメント、ファイル名、メタデータが含まれる可能性がある。

公開発表では、ONEKEYが信頼できないファームウェア内容とエージェントへの指示をどのように分離するかが説明されていない。これは、言語モデルをセキュリティ成果物に接続するあらゆるツールにとって重要な問いである。

脆弱性の関連性は文脈に依存するため、人間による承認は依然として必要である。脆弱な機能は、あるデバイス構成では到達不能であり、別の構成では露出している可能性がある。

逆に、既知のCVEがないコンポーネントにも、未開示の弱点が存在し得る。evidence-firstの回答によって、脆弱性データベースが完全なセキュリティ判定に変わるわけではない。

NISTのfirmware resilience guidanceは、不正なファームウェア変更に対する保護、検知、復旧を重視している。会話型トリアージはその作業を支援するが、それらのエンジニアリング管理策に取って代わるものではない。

したがって、このエージェントは意思決定支援レイヤーとして評価すべきである。これを自律的と呼ぶのは、発表された能力を過大に表現し、技術レビュー担当者が果たし続ける役割を見えにくくする。

この慎重な解釈は、ローンチを重要でないものにするわけではない。製品の成功を、証拠の品質、アナリストの成果、信頼できる拒否動作によって測定可能にする。

エージェントが成果をもたらすかを示す3つのシグナル

次の段階は、ローンチ時の表現ではなく、透明性のある製品証拠、実際の顧客ワークフロー、競合他社の対応を通じて評価されるべきである。

第1のシグナルは、9月リリースにおける技術的検証である。ONEKEYは、グラウンデッドな回答、生成されたOQL、根拠のない質問、文脈切り替えをどのように評価するかを開示すべきだ。

有用な結果には、タスク定義、代表的なファームウェアサンプル、エラー分類、専門家レビュー済み回答との比較が含まれる。モデル固有の結果は、顧客がBYOMのトレードオフを理解する助けとなる。

公開評価は、evidence-firstという主張を強化する。測定可能な結果を示さずデモに依存し続ければ、その主張は弱まる。

第2のシグナルは、CRA報告が活発に行われる期間の顧客導入である。製造業者はまもなく、この規制に基づく24時間および72時間の通知期間に対応することになる。

信頼できる顧客事例では、どの調査工程が迅速化されたか、そして人間がどのように出力を検証したかを示すべきだ。また、エージェントが不足している証拠を正しく明らかにした事例も記録すべきである。

生産性に関する広範な主張から得られる情報は少ない。購入者には、脆弱性の特定、影響製品の分析、緩和策の決定、報告書の準備に結び付いたワークフロー測定が必要である。

第3のシグナルは、競合するファームウェアプラットフォームがどのように対応するかである。グラウンデッドな会話型インターフェースが急速に広がれば、自然言語による証拠へのアクセスが標準的な購入要件になったことを裏付ける。

反応が弱ければ、顧客が会話型の操作性よりも、抽出精度、バイナリ分析、統合を依然として優先していることを示唆する。いずれの場合でも、これらの基盤は不可欠であり続ける。

ONEKEYの4段階ロードマップも、もう1つの参照点となる。後続段階では、不確実性を隠したり、取り消し不可能な判断を人間のレビュー範囲外へ移したりすることなく、自動化を拡張すべきである。

製品を評価するチームは、今から準備できる。既知のファームウェア検出結果、曖昧なコンポーネント一致、未対応形式、意図的に誤解を招くプロンプトからテストセットを構築すべきだ。

エージェントの回答を専門家の結論と比較し、根拠のない記述をすべて記録すべきである。また、権限、監査ログ、モデル変更、証拠リンクもテストすべきだ。

この評価手法は、ONEKEYにとどまらず適用できる。脆弱性を要約したり、修復策を推奨したりするあらゆるエージェントを検証するために、セキュリティの購買担当者には再現可能な手法が必要だ。

Google Newsの記事を追う読者は、これをまた一つのAI機能発表として矮小化すべきではない。本質的なのは、アシスタントがセキュリティの証拠に従属し続けながら、その証拠をより使いやすくできるという考え方だ。

この考え方は、技術業務におけるより広範な変化とも合致する。チームには、検索可能なナレッジベースがエンジニアを信頼できるドキュメントへ結び付けるように、質問と管理された社内記録をつなぐインターフェースがますます求められている。

ファームウェア・セキュリティでは、洗練された誤りがインシデント対応や規制判断を歪めかねないため、リスクはさらに高い。すべての回答が基となるスキャンとの関係を保持して初めて、利便性に意味がある。

ONEKEYは、証拠を最優先するという枠組みにより、妥当な基準を示した。次に同社が示すべきなのは、このエージェントが根拠のない結論を拒み、敵対的な入力にも耐え、期限に追われる状況で測定可能な成果を生むことだ。

会話型のファームウェア分析が日常化する前に、独立したテストはこの約束を裏付けるのだろうか。セキュリティチームは証拠を求め、限界を検証し、重要な判断のすべてに人間による承認を紐付け続けるべきだ。