Cloud

概要 AWSは2026年8月3日公開の週次まとめ記事「AWS Weekly Roundup」で、Amazon Bedrock上のOpenAI GPT-5.6モデルの大幅値下げと、Amazon CloudWatchへのPrometheusメトリクス向けフルマネージド型コレクター追加を発表した。両施策とも、AIワークロードおよび監視運用にかかるコストと運用負担の軽減を狙ったものである。 Bedrock上のGPTモデル値下げ Bedrock上で提供されるGPT-5.6には「Luna」と「Terra」の2つのバリエーションがあり、2026年7月30日付でオンデマンド推論価格がそれぞれ引き下げられた。GPT-5.6 Lunaは価格が80%引き下げられ、入力トークン100万あたり0.20ドル、出力トークン100万あたり1.20ドルという水準になった。一方、GPT-5.6 Terraの価格は20%引き下げとなっている。値下げは既存ユーザーにも自動的に適用される形で実施されており、追加の設定変更は不要である。 CloudWatchのPrometheusメトリクス管理型コレクター Amazon CloudWatchには、AWSインフラストラクチャからPrometheus形式のメトリクスを収集するフルマネージド型コレクターが新たに追加された。この機能により、Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、Amazon OpenSearch Serviceといった主要ワークロードのメトリクスを、エージェントのデプロイや管理を一切行うことなく収集できるようになる。従来、Prometheus形式のメトリクス収集にはユーザー自身がスクレイピング用のインフラを構築・維持する必要があったが、この負担が解消される。 その他のアップデート 同じ週次まとめでは、OCI(Oracle Cloud Infrastructure)向けのマルチクラウド接続を可能にするAWS Interconnectの一般提供(GA)開始、IAM Identity Centerにおけるディレクトリのマルチリージョン対応拡張、Amazon S3 TablesでのApache Iceberg V3 Variantデータ型サポート追加なども紹介されている。 今後の展望 GPTモデルの大幅値下げは、Bedrock上でOpenAIモデルを利用する開発者にとって導入・運用コストの引き下げに直結する。また、CloudWatchのPrometheus管理型コレクターは、Kubernetesやコンテナ環境を中心に監視の運用自動化を進める企業にとって、既存のPrometheusベースの可観測性スタックをAWSネイティブな形でよりシンプルに統合する選択肢となりそうだ。

概要 AIクラウド大手のCoreWeaveは、インドネシア・ジャカルタ近郊に3つのAIデータセンター施設を建設すると発表した。合計IT電力容量は360MWに達し、2028年の稼働開始を予定している。北米・欧州を中心に事業を展開してきた同社にとって、これがアジア太平洋地域への初進出となる。CoreWeave COOのSachin Jain氏は「今回の拡張により、企業やAIネイティブ企業、政府は必要などこであってもローカルおよびグローバルでより多くのコンピュートを確保し、競争優位につなげられるようになる」と述べ、パイオニアに必要な容量・パフォーマンス・信頼性を提供できる地域に進出する方針を示した。 技術的な詳細 CoreWeaveは2026年3月31日時点で世界49カ所のデータセンターを運営し、1GW以上のアクティブ電力と3.5GW以上の契約電力を保有する。インドネシアの新施設はこの契約電力の約10%に相当する規模となる。3拠点にはCoreWeaveの完全なAIクラウドプラットフォームが導入される予定で、対象顧客はAIラボ、スタートアップに加え、東南アジア全域にワークロードを展開するエンタープライズ企業を想定している。 進出の背景 インドネシアが選ばれた理由として、AI教育への投資、政府・民間によるデジタルインフラ投資、スケーラブルな電力供給が挙げられている。IDCのアナリストDave McCarthy氏は今回の展開を「北米・欧州のプレーヤーからグローバルAIインフラプラットフォームへの転換」と評価する。インドネシアは東南アジアで最も急速に成長する技術投資先の一つとなっており、遅延に敏感なワークロードやデータ局所性(レジデンシー)の要件が、地域へのインフラ投資を後押ししている。 今後の展望 CoreWeaveはインドネシア現地での技術チーム構築や人材育成にも投資し、長期的な事業運営体制を整える方針を示している。今回の動きは、AIインフラがこれまでの集中型配置から、データレジデンシー規制やレイテンシ要件に対応した地域別・主権的な配置へとシフトしつつある業界全体の流れを象徴するものといえる。2028年の稼働開始に向け、シンガポールや日本といった既存のAPACデータセンター拠点との競合構図にも注目が集まる。

概要 Samsung重工業(Samsung Heavy Industries)とMousterian Corporationは、テキサス州向けに係留型の浮体式データセンターを開発するための設計契約を締結した。両社は基本設計・詳細設計・製作設計を共同で担当し、次段階としてEPC(設計・調達・建設)契約の締結を見込んでいる。パイロットサイトはヒューストン近郊の既存のコンバインドサイクルガスタービン発電所に隣接する場所に設置される予定で、既存の電力インフラを活用できる立地が選ばれた。陸上の適地不足や電力供給の制約を回避する新たなデータセンター建設手法として、AIインフラの急拡大を背景に注目を集めている。 技術的な詳細 各施設は50MWのIT負荷容量を持つ設計で、飲料水を一切消費せず排水も発生しない非蒸発冷却技術を採用する。従来の空冷式チラーやファンを排除することで、水消費と騒音の両方を低減し、係留された構造物を取り囲む水を冷却源として利用する仕組みになっている。この水上施設は米国船級協会(American Bureau of Shipping)によって分類される予定で、海事分野の基準をデータセンターインフラに適用する点も特徴だ。浮体式であることにより、土地開発をめぐる競合を避けられるほか、必要に応じて施設を移動できる可動性も備え、AI向けの大規模IT容量を工場生産的に短期間でスケールさせられるとされている。 規制上の課題と今後の展望 Samsungは、サーバーメーカーのSupermicroとの提携により2028年の稼働開始を目標としているが、テキサス州の規制動向が計画に影響を及ぼす可能性がある。同州のグレッグ・アボット知事は最近、監査が完了するまでERCOT(テキサス電力信頼性評議会)への新規データセンター接続承認を一時停止した。現在ERCOTに寄せられている接続申請は474GW超に上り、そのうち約9割をデータセンターが占め、ピーク需要の5倍に達しているという。こうした需要急増を背景とした規制強化により、浮体式データセンターのような新形態のインフラ整備計画も、スケジュールの見直しを迫られる可能性がある。

概要 セキュリティ研究者のHedi Ingber氏とAviyam Ivgi氏（Stealth共同創業者）は、Black Hat USA 2026において、AWS Bedrock AgentCore、Google ADK for Python、Vercel AI SDKという主要なAIエージェント基盤に共通する脆弱性パターン「CoreBreak」を公表した。この問題は、モデルの推論ターンを一切経ることなく、偽造されたツール呼び出しがそのまま実行系に到達しうるというもので、5件のCVEが割り当てられている。研究者らは各ベンダーに事前に検証コード（PoC）を提供済みだが、公開はしていない。大半の脆弱性は既に修正されているが、AWSがオープンソースで公開しているStrands Python SDKの一部の経路は、記事執筆時点で未パッチのまま残っているという。 発見されたCVEと影響範囲 CoreBreakとして報告された主なCVEは以下の通り。 AWS Bedrock AgentCore（CVE-2026-18830、CVSS 8.6）: InvokeHarness APIの入力検証が不十分で、認証済みユーザーがツール利用ブロックを直接注入できた。2026年7月31日までにサーバー側で自動的に修正済み。 Google ADK for Python（CVE-2026-18236、CVSS 9.3）: 「continuation forgery」と呼ばれる継続偽造の問題に加え、resumableモードでユーザーが作成した関数呼び出しを受け入れてしまう別のバイパスも確認された。バージョン2.5.0（2026年7月16日）で検証チェックの追加とユーザーメッセージ内の関数呼び出し拒否が行われ、両方の問題が修正された。 Vercel AI SDK（CVE-2026-64650／@ai-sdk/harness-codex、CVE-2026-64651／@ai-sdk/harness-opencode、いずれもCVSS 6.3）: 承認済みヘルパースクリプトを含むコマンドラインを信頼してしまうプロセスパス認可の問題。2026年7月10日に、フォールバック処理を廃止し、モデルのイベントに紐づく一回限りの厳密な認可を必須とする修正が行われた。 Strands Python SDK: 個別のCVEは発行されておらず、AWSは顧客側の責任範囲としている。最新のtoolUseメッセージに対してモデルをスキップしてしまうショートカットがアップストリームのコードに残存しており、外部からの注入リスクを警告した4月のプルリクエストも未マージのままだという。 技術的な仕組み 通常のAIエージェントは、ユーザーのリクエストを受けてモデルがツール呼び出しを判断し、それをSDKが実行するという流れをとる。CoreBreakは、この「モデルが判断する」ステップを迂回できてしまう欠陥で、ツール呼び出しの形をしたデータが正当なモデルの認可を経て生成されたものかどうかを検証していない経路が悪用される。攻撃条件はプラットフォームごとに異なり、AWSでは認証済みのリモートリクエスト、Googleでは攻撃者が制御可能なセッションイベントやユーザーが作成した呼び出し、Vercelではすでにサンドボックス内で実行されている信頼できないコードが起点となる。研究者らは「モデルは一度も実行されていないため、システムプロンプトやコンテンツフィルター、モデルレベルのガードレールが介入する機会すら与えられない」と指摘しており、モデルの推論を欺くプロンプトインジェクションとは根本的に異なる性質の脅威だとしている。 対応状況と今後の課題 ベンダー各社は該当パッケージの修正版を速やかに提供しているが、AWSのStrands Python SDKについては未パッチの経路が残るとされ、利用者側での注意が必要な状況が続いている。研究者らは、対策として影響を受けるパッケージの速やかなアップグレードに加え、会話履歴やツール利用ブロックを信頼できない外部入力として扱うこと、各ツール呼び出しを特定のモデルイベント・引数・セッション状態に紐付けること、エージェントの権限を必要最小限のツールに限定することを推奨している。今回の事案は、AIエージェント基盤において「モデルの判断」を前提とした従来のセキュリティモデルだけでは不十分であり、実行系そのものの認可設計が問われる新たな脅威分類として注目されている。

概要 Cloudflareは、AIエージェントがオンラインで安全に取引を行うための2つの新機能を発表した。1つは、エージェントの恒久的な身元を表す人間可読の識別子体系「cloudflare.pay」、もう1つは人間が設定した上限内でエージェントが自律的に支払いを行える「Cloudflare Wallets」だ。企業がやり取りの相手を正規の顧客代理AIか不正なプログラムかを判別できないという課題に対応し、AIエージェントによる自律的な商取引の信頼基盤を整備する狙いがある。Cloudflareは今回の発表の背景として、「エージェントには安定した識別子がなく、API代金を支払う本質的な方法も欠落している」という2つの根本的な問題を挙げている。 背景・課題 現状、AIエージェントが新しいAPIを試すことには多くの障壁がある。ログインページは人間の利用を前提に設計されており、支払い方法の追加には人間の介入が必要で、APIキーの発行手続きも煩雑だ。こうした摩擦は、エージェントが自律的に必要なサービスを発見し利用するという体験を大きく妨げている。加えて、マーチャント側にも問題がある。アクセスしてきた相手が正規の顧客の代理として動くAIエージェントなのか、それとも悪意あるボットなのかを判別する手段が乏しく、AIエージェント経済の健全な発展を阻んでいるという。 技術的な仕組み Cloudflare Walletsは、HTTPリクエストに支払い情報を直接添付できるマイクロペイメントプロトコル「x402」を採用する。これにより、AI推論やデータ、コンテンツへの支払いをリクエストの流れの中でシームレスに処理できる。 ウォレットは2種類に分かれる。人間のCloudflareアカウント所有者が保有する「アカウントウォレット」は、資金の追加や仮想ウォレットへの支出権限の委譲、資金の引き出しを行える。一方、エージェント向けの「仮想ウォレット」はAPIキーによって操作され、アカウント所有者があらかじめ設定した上限の範囲内でのみ支出できる。 支出管理のためのガードレール機構も用意されており、支出上限や許可リスト、1件あたりの最大トランザクション額などを柔軟に設定可能だ。異常な支出パターンが検出された場合には、人間が内容を確認・承認するフローも組み込まれている。cloudflare.payでは、エージェントが「research.example.cloudflare.pay」のような形式のハンドルを取得し、身元情報を自発的に取引先へ宣言できる。 対象ユーザーと今後の展開 想定される利用者は幅広い。エージェント開発者は複数のAPIを低摩擦で試験・評価できるようになり、Monetization Gatewayを通じてコンテンツやAPIを販売するCloudflareの顧客企業は新たな収益機会を得る。また企業の管理者にとっては、従業員が利用するAI推論サービスへの支出予算を管理する手段にもなる。 現時点でCloudflareはcloudflare.payのハンドル取得受付を開始しており、マイクロペイメント機能は近日開始予定としている。対象地域限定でVirtual Walletのステーブルコイン自己資金調達オプションも段階的に展開する方針だ。今回の取り組みは、既存のWeb Bot Authなどのセキュリティ技術や、標準化を進めるx402 Foundationのイニシアティブとも連携しており、AIエージェントが人間の監督のもとで安全に経済活動を行える基盤づくりの一環と位置付けられている。

概要 GitHubは2026年8月6日（現地時間午前11時22分/UTC15時22分)、GitHub Actionsのパフォーマンス低下を検知し、これが約10時間半に及ぶ大規模障害へと発展した。原因は実行ランナーに対して無効なジョブが継続的かつ誤って割り当てられていたことで、ワークフローの失敗や遅延が世界中のCI/CDパイプラインを直撃した。障害はActions単体にとどまらず、GitHub Pagesの可用性低下、Copilotのコードレビューおよびコーディングエージェント機能の劣化、ホステッドランナーの不調、GitHub Enterprise Importerの移行ジョブ停止、ウェブフック配信の遅延（処理能力が通常の15%まで低下）へと波及した。一部のトリガーイベントは自動再実行の対象外となり、失われたままとなっている。GitHubは発生から約2時間後に原因を特定したとするも当初は技術的詳細を明らかにせず、その後複数の緩和策と修正を段階的に適用し、現地時間午後8時1分に復旧を宣言した。修正適用後、ワークフロー実行の成功率は99%まで回復したという。 背景にある信頼性の低下 今回の障害は単発の事故ではなく、GitHubのインフラが抱える構造的な問題の一端として位置づけられている。IncidentHubの集計によれば、過去12カ月間でGitHub全体は257件のインシデント（うち48件が「メジャー」）を記録し、累積ダウンタイムは112時間を超える。GitHub Actionsだけでも57件のインシデントが報告されており、月別でも2026年4月に26件、5月に23件、6月に23件、7月に26件、8月も6日時点で既に6件と、高止まりが続いている。GitHubは以前、AI関連ワークロードの急増をシステム負荷の一因として説明し、構造的改善を約束していたが、今回の障害はその効果が十分に表れていないことを示した。GitHubは現在Azureへのインフラ移行を進めているものの、今回の障害発生時点でトラフィックの移行率はわずか12.5%にとどまっており、完全移行までは同種の負荷問題が続く可能性がある。 開発者コミュニティの反応 相次ぐ障害に対し、開発者コミュニティの不満は深刻化している。ターミナルエミュレータGhosttyの開発者Mitchell Hashimotoは「ほぼ毎日のようにインシデントで作業がブロックされている」と述べ、プロジェクトのGitHubからの移行を発表した。Zig言語財団もすでにCodebergへの完全移行を完了させている。ある開発者は、現状のGitHubのプラットフォームは「本格的な業務利用には適さない」との評価も示しており、CI/CD基盤としての信頼性そのものが問われる状況となっている。

概要 AWSは2026年8月5日、Amazon Aurora Serverlessのスケーリング性能を強化したと発表した。新機能により、負荷が急増した際にわずか1秒以内で最大12 ACU(Aurora Capacity Unit)まで到達し、その後も需要に応じて最大256 ACUまで拡張し続けることが可能になった。ワークロードが終了すればクラスターは自動的にゼロまでスケールダウンし、アイドル時のコストは発生しない。 この強化はプラットフォームバージョン3および4で自動的に有効化されるため、ユーザー側での追加設定は不要だ。バージョン1や2を利用している場合は、バージョン4へ直接アップグレードすることでこの機能を利用できる。現在使用しているバージョンは、AWS Management Consoleのインスタンス設定セクション、またはRDS APIのServerlessV2PlatformVersionパラメータから確認できる。 想定されるユースケース AWSは今回の強化について、突発的なアクセス集中、長いアイドル期間、予測が難しいトラフィックパターンを持つアプリケーションに特に有効だとしている。中でも主なターゲットとして挙げられているのが「エージェント型AI」アプリケーションだ。AIエージェントは、タスク実行時に短時間で大量のデータベースクエリを発行し、処理が完了すると一気にアイドル状態へ戻るという、瞬間的かつ極端な負荷変動を伴うことが多い。従来のオートスケーリングでは、こうした急激な立ち上がりに追従しきれずレイテンシが悪化したり、逆に不要な容量を確保し続けてコストが膨らんだりする課題があった。今回の高速スケーリングは、こうしたバースト特性の強いワークロードに対して、性能とコスト効率を両立させることを狙っている。 背景と今後の展望 Aurora Serverless(v2)はもともと、需要に応じてデータベースの処理能力を自動的に増減させることでコスト最適化を図る仕組みとして提供されてきた。生成AIやエージェント型AIの普及に伴い、アプリケーションのトラフィックパターンはより予測不可能かつスパイク状になっており、データベース基盤にもそれに追従できる俊敏性が求められるようになっている。今回のアップデートは、AWSがそうした新しいワークロード特性に合わせてマネージドデータベースサービスを継続的に進化させている一例と言える。既存クラスターへの適用に追加コストや移行作業が発生しない点も、導入のハードルを下げる要素となりそうだ。

概要 Samsungは8月4日から米カリフォルニア州サンタクララで開催された「Future of Memory and Storage(FMS)2026」において、AIデータセンター向けの次世代メモリ技術3種、zHBM・zNAND-O・V10 BV-NANDを発表した。いずれも先進的なウェハー接合(wafer bonding)技術を基盤としており、大規模AIトレーニングにおけるメモリ帯域幅のボトルネック、発熱、電力効率という3つの課題への対応を狙う。SamsungはzHBMとzNAND-Oについて業界初のコンセプトモデルを披露したとしている。 zHBM:メモリをアクセラレータの真上に積層 zHBMは、HBM(High Bandwidth Memory)を根本的に再設計したアーキテクチャである。従来のHBMはAIプロセッサの隣に水平配置されるのが一般的だが、zHBMは次世代ウェハー接合技術を用いてメモリをAIアクセラレータの真上に垂直積層する。これによりメモリとプロセッサ間の物理的距離を最小化し、データ転送の遅延を大幅に削減する狙いだ。 性能面では、HBM5比で最大8倍の性能向上、同じ実装面積で10倍以上のメモリ密度、エネルギー効率は3倍改善、熱抵抗は50%以上削減されるとしている。また、カスタマイズ可能なIP層を備え、特定のAIワークロード向けにロジックを追加できる点も特徴として挙げられている。ただし、これらの数値の詳細な算出根拠は現時点で公開されていない。 zNAND-OとV10 BV-NAND:NANDにもウェハー接合を適用 zNAND-Oは、SamsungのV-NAND技術をベースにしたエッジAI向けの高性能NANDソリューションで、4層および8層構成の開発が進められている。高い空間効率と改善されたI/O性能、低レイテンシを特徴とし、リアルタイムのデータ処理を要するエッジAI用途を想定する。 一方のV10 BV-NAND(Bonding V-NAND)は、業界で初めてウェハー接合技術をNANDフラッシュに適用したアーキテクチャで、400層を超える積層数を実現したプロトタイプとして披露された。ウェハー接合では、メモリセルとペリフェラル(周辺)ロジックを別々のウェハーで製造し、後から貼り合わせる製法を採る。これにより、従来の単一ウェハー上に全層を積み上げる方式に比べ高密度化がしやすくなる。前世代のV9と比較して、ストレージ密度は約58%向上したほか、読み書き性能やI/O性能も改善されたという。 今後の見通し 今回発表された3技術はいずれもコンセプトモデルやプロトタイプの段階であり、量産・製品化の具体的な時期は明らかにされていない。生成AIの普及に伴いAIアクセラレータの計算能力は急速に向上している一方、メモリからのデータ供給が追いつかない「メモリウォール」問題が業界共通の課題となっている。Samsungは今回の技術群を通じて、演算性能の向上にメモリ側の帯域・密度・熱特性を追随させる方向性を示した形で、HBMやNANDの次世代開発競争は今後さらに激化するとみられる。

概要 Snowflakeは8月7日、Native Apps向けにAIエージェント機能「Cortex Agents」とMCP(Model Context Protocol)サーバーのサポートが正式提供(GA)となったと発表した。これにより、Native Appsの開発者はアプリ内にネイティブな会話型AI体験を組み込み、アプリが持つ共有データや機能に対してユーザーが自然言語で対話できるようになる。企業のデータ基盤上でAIエージェントを直接構築・実行できる環境が整ったことで、Snowflakeプラットフォーム上でのAIエージェント活用がさらに進むことになる。 Cortex AgentsとMCPサーバーの仕組み Cortex Agentsは、Native Appsのプロバイダーがアプリ内に会話型AIエージェントをデプロイできる機能で、エージェントはアプリが共有するデータや機能と連携してユーザーとの自然言語でのやり取りを担う。これと合わせて提供されるMCPサーバーサポートには2つの実装形態が用意されている。1つは「Snowflake管理型MCPサーバー」で、Cortex Search服務、セマンティックビュー、プロシージャ、UDF(ユーザー定義関数)といったアプリが所有するリソースをMCPツールとして公開する。もう1つは「SPCSホスト型MCPサーバー」で、プロバイダーは既存のSnowpark Container Services(SPCS)エンドポイントをMCPサーバーとして登録できる。 アプリ間連携とガバナンス 今回のGAで注目すべき点は、エージェント同士、あるいはエージェントとMCPサーバー間の連携によって、複数のNative Apps間で機能を横断的に利用できるようになったことだ。ただしアーキテクチャ上、各アプリは自身のデータとロジックを非公開に保ち、エージェントはプロバイダーが明示的に公開したツールを通じてのみ他アプリにアクセスできる仕組みになっている。また、エンドユーザー(コンシューマー)側にも、呼び出し元への権限付与管理、機能ポリシーの設定、特定ユーザーロールへのエージェントアクセス委任といったガバナンス手段が用意されており、データプライバシーと利便性の両立が図られている。 今後の展望 Snowflakeはこの機能に関連して、エージェントとMCPサーバーの構築方法、アプリ間連携パターンの実装、コンシューマー視点でのリソース管理という3つの観点から開発者向けドキュメントを整備している。Native Appsの枠組みにAIエージェントとMCPという業界標準プロトコルを組み込んだことで、企業データを扱うアプリケーション開発者は、既存のデータガバナンスを維持しながらAIエージェントによる高度な自動化や連携をより容易に実現できるようになりそうだ。

概要 Amazon、Google（Alphabet）、Microsoftのクラウド大手3社が、2026年の設備投資予測を相次いで上方修正し、3社合計で約5950億ドルに達したことが明らかになった。背景にあるのはAI関連需要の急拡大で、各社ともコンピュート能力の確保が追いついていない状況が浮き彫りになっている。AWSはCEOのAndy Jassy氏が「2026年にすべての需要を満たすのに十分な容量がない」と認めるなど、供給不足が業界全体の課題となっている。 各社の投資動向 AWSは2026年の設備投資予測を、当初の約2000億ドルから2200億ドルへ引き上げた。Jassy氏は、この上方修正の主因をメモリコストの上昇にあると説明している。Google/Alphabetも同様に、当初1800億〜1900億ドルとしていた予測を1950億〜2050億ドルへ引き上げた。CFOのAnat Ashkenazi氏は「容量供給の加速が必要となり、この範囲に更新した」と述べており、実際に同社のクラウド収益は前年比82%増の248億ドルに達している。Microsoftについては約1750億ドルの投資予測が示されているが、これはリース会計処理の変更による調整分を含んでおり、実質的な投資削減を意味するものではない点に留意が必要だ。 背景と今後の展望 3社が投資を積み増す背景には、メモリ、GPU、ハードディスクといった主要部材の深刻な供給不足がある。この供給制約はPC出荷やスマートフォン販売にも影響を及ぼしているが、一方で自社インフラを構築する余力のない企業をパブリッククラウドへ押し出す要因にもなっている。実際、企業のクラウドインフラ支出は前年比43%増となり、四半期あたり1430億ドルを超える規模に成長した。AI需要の伸びが各社の投資ペースを上回る状況が続く中、GPUやメモリの供給制約が解消されない限り、クラウド大手による大規模投資はさらに拡大していく可能性が高い。