コーディング特化のオープンモデル「Ripple-65B Preview」が登場
Ricursive Intelligence社が、650億パラメータを持つオープンウェイトモデル「Ripple-65B Preview」を公開しました。開発費に3,200万ドルを投じたこのモデルは、Apache 2.0ライセンスで提供されます。コーディング能力を測るTerminalBench 2.1において、米国のオープンソースモデルの中で最高スコアを記録したと発表されています。
解説
今回の発表は、エージェント的なコーディング能力を持つ高性能なモデルが、商用利用可能なApache 2.0ライセンスで提供された点に意義があります。特にTerminalBench 2.1などのベンチマークで高い数値を示しており、自律的なコード生成や修正を行うAIエージェントの構築において、有力な選択肢となる可能性があります。
エンジニアや開発チームにとって、機密性の高いコードベースを扱う際に、外部APIに依存せずローカル環境や自社サーバーで動作させられる点は大きなメリットです。ただし、65Bというモデルサイズはメモリ消費が激しいため、導入には十分なVRAMを搭載したハードウェア環境の整備が不可欠です。
検証にあたっては、ベンチマーク上の数値だけでなく、実際の開発ワークフローにおける精度や、他モデル（Inkling 2 Small等）と比較した際のコストパフォーマンスを確認することが重要です。また、オープンウェイトモデルであるため、ライセンス条件を遵守した運用設計が求められます。
出典: Ripple-65B Preview delivers strong agentic coding results as a fully Apache 2.0 open US model（The Decoder） / Ripple 65B Preview vs Qwen 3.8 27B vs Qwen 3.8 Flash Next（r/LocalLLaMA）
Qwen3.8-27Bの推論最適化が進展、推論エンジンと量子化の選択が鍵に
Qwen3.8-27BおよびFlash-Nextモデルを対象とした、複数の推論エンジンによる性能検証結果が報告された。検証では、GGUFやNInferなどのフォーマット比較に加え、最大256Kトークンの長文コンテキストにおける速度と出力品質の両立が測定されている。また、KVキャッシュの量子化に関する検証では、8-bit化は品質への影響がほぼなくメモリを半減できる一方、4-bit化は特に長文コンテキストにおいて品質低下が顕著になることが示された。ハードウェア面では、RTX 5080（16GB）と64GB RAMの環境で、Basaltエンジンと特定の量子化モデルを組み合わせることで、高速なデコードとプリフィルを実現した事例が報告されている。
解説
今回の検証結果は、ローカルLLMの運用において「単なるトークン生成速度」ではなく、「コンテキスト長に応じた品質維持」と「推論エンジンの最適化」が極めて重要であることを意味しています。特にKVキャッシュの8-bit量子化が実用的であるという知見は、限られたVRAMで長文を扱う際の標準的な選択肢となるでしょう。
この傾向は、大量のドキュメント解析やコードベース全体の読み込みを行うエンジニアや、自前環境でエージェントを動作させたいビジネスパーソンにとって大きなメリットとなります。推論エンジンの選択（BasaltやSaber、llama.cppなど）によって、同一モデルでも数倍の速度差が出るため、利用するハードウェア（NVIDIA GPUかAMD GPUか、あるいはMacか）に最適化したスタックの選定が不可欠です。
導入時の注意点としては、量子化レベルを上げすぎると、特に長文コンテキストにおいて推論精度が劣化する点です。また、オープンウェイトモデルを自前環境で動かす際は、ライセンスの確認に加え、KVキャッシュの消費量を見越したメモリ設計が求められます。速度を追求して投機的デコード（Drafting）を導入する場合も、最終的な出力品質がメインモデルによって担保されているかを確認する運用フローが推奨されます。
出典: Qwen3.8-27B Benchmark: 6 Inference Engines, GGUF vs NInfer, 256K Context — Comparing Both Speed AND Quality（r/LocalLLaMA） / [GUIDE] Qwen3.8 Flash-Next on a single RTX 5080 + 64GB RAM: >250 tok/s tg and 5700 tok/s prefill in real agent coding sessions (Basalt + new Unsloth UD-IQ3_XXS + Lamina drafter),+ how it compares to llama.cpp（r/LocalLLaMA） / Qwen3.8 27b hitting 6,645 tok/s on prefill and 316 tok/s decode peak on Saber（r/LocalLLaMA）
GitHub CopilotがSlack/Teams連携を一般公開、チャットから直接開発へ
GitHubは、SlackおよびMicrosoft Teamsで利用可能な「@GitHub」機能を一般公開しました。この機能により、チャットツール上からバグの調査、Issueの作成、コード変更の実装、プルリクエストの作成が直接行えます。また、Teamsでは「Canvas」を用いて、会話と並行して実装計画やコード変更のレビュー、プレビューを行うことが可能です。リポジトリの自動識別によるオンボーディングの高速化や、作成したIssue等への参照元の明記といった改善も盛り込まれています。
解説
今回のアップデートは、開発者がIDE（統合開発環境）に移動することなく、コミュニケーションツール内で開発サイクルを完結させられることを意味します。これまでチャットで合意した内容をIDEに転記し、Issueを立てるという断続的な作業が発生していましたが、この境界線が解消されます。特に、プロダクトマネージャーやデザイナーなど、非エンジニアを含むステークホルダーとの合意形成から実装への移行をスムーズにしたいチームにとって、大きな効率化が期待できます。
導入にあたっては、チャットツールというオープンな場でのコード操作に伴う権限管理や、AIが作成したIssueやプルリクエストのレビュー品質の担保が重要になります。また、GitHub Copilotのライセンスに加え、各チャットツールのAPI連携設定が必要となるため、組織的なセキュリティポリシーとの整合性を確認する必要があります。
出典: @GitHub in Slack and Teams is generally available and more（GitHub Copilot Changelog） / Beyond code generation: A developer’s guide to agentic engineering（GitHub Blog: AI & ML）
Qwen3.8-27Bを再学習し政治的バイアスを排除した「Arete-27B」が登場
Nous Researchは、AlibabaのQwen3.8-27Bをベースに、西洋的な価値観を強化するポストトレーニングを施したオープンウェイトモデル「Arete-27B」を公開しました。教師モデルにInklingを用い、約5,300万トークンの教師あり微調整（SFT）のみで構築されています。評価の結果、政治的に敏感なトピックにおけるプロパガンダを含む回答率が22%から0.9%に低下し、事実スコアも向上したとしています。一方で、汎用能力やエージェントとしての性能に大きな低下は見られなかったと報告されています。
解説
今回の発表は、ベースモデルが持つ特定の政治的バイアスや価値観が、比較的少量の微調整（SFT）によって書き換え可能であることを示した点に大きな意味があります。開発チームは、こうしたバイアスはモデルの深い層ではなく「薄い層」として適用されていると分析しており、オープンウェイトモデルの柔軟性を証明する事例となりました。
このモデルは、中国製モデルの高い基本性能を維持しつつ、客観的な視点や異なる価値観に基づいた回答を求めるビジネスユーザーや研究者に有用です。特に、グローバルな視点での情報収集や、エージェントとしての自律的なタスク実行において、特定の思想に偏らない出力を求める業務での活用が期待できます。
導入にあたっては、オープンウェイトモデルであるため、ライセンス条件の確認と、自前環境で動作させるための計算リソースの確保が必要です。また、バイアスが完全に除去されたわけではないため、出力の客観性について、実際の業務ドメインに沿った検証を行うことが不可欠です。
出典: NousResearch/Arete-27B · Hugging Face (Qwen finetune)（r/LocalLLaMA） / State propaganda in some Chinese AI models is only "a thin layer" that fine-tuning can strip away（The Decoder）
RTX 50シリーズ搭載機が続々登場、高騰するハイエンドGPUの現状
MSIは、Ryzen 9 9955HX3DとGeForce RTX 5090または5080 Laptop GPUを搭載した18型ノートPC「Raider A18」の構成モデルを、2026年11月12日に日本国内で発売する予定です。一方で、デスクトップ向けのGeForce RTX 5090は供給が増えつつあるものの、価格が高騰し、通常価格が120万円台に達しています。
解説
ハイエンドGPUの価格高騰と、最新のRTX 50シリーズ搭載ノートPCの登場が続いています。特にデスクトップ向け最上位モデルの価格上昇は著しく、個人の開発環境として導入する際のコストハードルが極めて高くなっています。
これらのマシンは、CUDA環境を必要とするAI開発者や、ローカルで大規模なモデルを動かしたい技術者にとって選択肢となります。しかし、筆者の過去の見解にある通り、CUDAが必須でないローカルLLM利用であれば、コストパフォーマンスやリセールバリューの観点からMac Studio等のAppleシリコン搭載機の方が現実的な選択肢となる可能性があります。
導入を検討する際は、単なるスペック数値だけでなく、予算に対する実用的なメリットがあるか、また特定のライブラリやフレームワークでCUDAが不可欠なワークフローであるかを慎重に見極める必要があります。
出典: 初登場時の約3倍！ でも“通常価格”の120万円台に高騰した「GeForce RTX 5090」――それでもアキバで買い手が途絶えない理由（ITmedia PC USER） / 【本日みつけたお買い得品】何と約9万2千円引き！RTX 5070搭載ゲーミングノートが超お買い得に（PC Watch（Impress）） / MSI、Ryzen 9＋＋GeForce RTX 5080／5090 Laptopを搭載したウルトラハイエンド18型ゲーミングノート（ITmedia PC USER）
llama.cppでMoEモデルの推論効率が向上、CPUオフロードと新キャッシュを導入
オープンソースの推論フレームワークであるllama.cppにおいて、Mixture-of-Experts（MoE）モデルの動作を最適化するプルリクエストが提出されました。具体的には、VRAM不足時にCPUでエキスパートを動作させる仕組みや、利用頻度に基づき優先的にキャッシュを保持するハイブリッドキャッシュ（ClassLRU）などが提案されています。また、Moonshot AIの「Kimi-K3.1-Pro」をローカルで動作させるための対応も追加されました。
解説
今回のアップデートは、特にVRAM容量が限られた環境で巨大なMoEモデルを動かしたいユーザーにとって重要な意味を持ちます。これまでMoEモデルのオフロードは速度低下が激しい課題がありましたが、CPUでの処理最適化やキャッシュ効率の改善により、低スペック環境での実用性が高まる可能性があります。
具体的には、個人のワークステーションやエッジデバイスで大規模なMoEモデルを検証したい技術者や、機密性の高いデータを扱うためローカルLLMを導入したいビジネスパーソンに恩恵があります。推論速度の向上は、そのまま業務上の待ち時間削減に直結します。
導入にあたっては、キャッシュの挙動やCPUオフロードによる速度低下の許容範囲を検証する必要があります。また、Kimi-K3.1-Proのようなモデルを動かす際は、モデルのライセンス確認に加え、十分なメインメモリ（RAM）が確保されているかを確認することが重要です。
出典: llama_moe_cache: run missed experts on CPU, add tuning script by am17an · Pull Request #30966 · ggml-org/llama.cpp（r/LocalLLaMA） / model: add Kimi-K3.1-Pro text model by usrlocalben · Pull Request #31779 · ggml-org/llama.cpp（r/LocalLLaMA） / moe-cache : LRFU/MQ-like hybrid cache, ClassLRU by sanmai · Pull Request #31233 · ggml-org/llama.cpp（r/LocalLLaMA）
NVIDIAが新CPU「Vera」を発表、AIエージェントの実行速度と電力効率を大幅向上
NVIDIAは、AIエージェントのワークロードに最適化したCPU「Vera」を発表しました。AIエージェントが頻繁に行うCPU側での実行処理において、従来のx86 CPUと比較して高い処理速度と電力効率を両立させています。100メガワットのデータセンターでの比較において、最速のx86 CPUよりワットあたりのエージェント収容数が1.6倍多く、最も電力効率の良いx86 CPUよりエージェントの動作速度が2倍速いことが示されました。PerplexityやDeepInfraなどのパートナー企業が導入・検証を開始しています。
解説
AIエージェントは推論（GPU）だけでなく、コードの実行やDBクエリ、ツールの操作といったCPU側の処理を繰り返します。これまでは速度重視か電力効率重視かでCPUの選択肢を使い分ける必要がありましたが、Veraの登場により、単一のインフラで高速なレスポンスと高密度な運用を同時に実現できる可能性があります。
特に、大量のエージェントを同時に稼働させるAIファクトリーや、サンドボックス環境を高速に立ち上げる必要がある開発プラットフォームにとって、インフラコストの削減とユーザー体験の向上が期待できます。1つのCPUで多様なエージェント負荷を処理できるため、ハードウェア構成の簡素化につながるでしょう。
導入にあたっては、既存のx86ベースのソフトウェア資産がどの程度スムーズに移行できるか、また、特定の最適化なしで性能が出るのか（ClickHouseの例のように）という互換性の検証が重要になります。また、クラウドプロバイダー経由での提供形態や、コストパフォーマンスの実際の変動を注視する必要があります。
出典: Vera Delivers the Best of Both Worlds: Highest Throughput and Fastest Agents（NVIDIA AI Blog）
PFNが翻訳特化LLM「PLaMo 3 Translate」を公開、小規模モデルでも高精度を実現
Preferred Networks（PFN）が、翻訳に特化したLLM「PLaMo 3 Translate」のウェイトをHugging Faceで公開した。モデルサイズは0.8B、2B、8B、31Bの4種類で展開され、53言語の翻訳に対応している。データ合成や自己蒸留などの手法を用いて開発されており、最小の0.8Bモデルであっても、パラメータ数が30倍以上の既存の翻訳特化モデルを上回る精度を日英翻訳などで実現した。ライセンスはPLaMo Community Licenseが適用され、個人利用や学術利用、および直近の年度収益が10億円以下の法人による商用利用（要事前登録）は無料で提供される。
解説
今回のリリースで注目すべきは、極めて小規模なモデル（0.8Bなど）で高い翻訳精度を実現した点です。従来のLLMでは精度を出すためにモデルの巨大化が必須でしたが、データ精製と蒸留に注力することで、エッジデバイスや低リソース環境でも実用的な翻訳機能を持たせられる可能性を示しています。特に文脈の考慮や用語集の適用、日本語の敬体・常体の使い分けが可能なため、定型的な翻訳業務の自動化に組み込みやすい設計となっています。
実務的には、機密性の高い文書の翻訳を外部APIに投げたくない企業にとって、オンプレミスやローカル環境で動作させる選択肢になります。MLX形式やGGUF形式が提供されているため、Mac StudioなどのAppleシリコン環境でも効率的に動作させることが可能です。導入にあたっては、利用目的が商用である場合、自社の収益規模に応じて事前登録や別途ライセンス契約が必要になる点に注意してください。
出典: PLaMo 3 Translate – a pfnet Collection（r/LocalLLaMA）
AIエージェント評価の「メンテナンス債務」を解消するTerminal-Bench 2.1
コーディングエージェントの評価指標であるTerminal-Benchにおいて、リリース後の検証を通じて約30%の課題が特定され、修正版のTerminal-Bench 2.1が公開されました。従来のベンチマークは、モデルの進化に伴い正解判定が不適切になるなどの「メンテナンス債務」を抱えやすいことが指摘されています。今回の修正により、正解率は10ポイント以上向上し、リーダーボードの順位にも変動が生じました。また、実行時間の制限設定がモデルの性能評価に大きく影響することも示されています。
解説
今回の発表は、AIモデルの性能評価が「一度作れば終わり」ではなく、ソフトウェアのように継続的なメンテナンスが必要なフェーズに入ったことを意味しています。モデルが高度化し、想定外の正解ルートを見つけた際に、評価側（検証機）がそれを正しく判定できなければ、実力以下のスコアが出るという逆転現象が起こります。
特に自社でコーディングエージェントを導入・検証しようとする技術者やビジネスパーソンにとって、公開されているベンチマークスコアを鵜呑みにせず、評価環境の前提条件（リソース制限や判定基準）まで精査する必要があることを示唆しています。特に実行時間などのリソース予算の設定次第で、モデル間の性能差が消失する場合がある点には注意が必要です。
オープンウェイトモデルを自前環境で動かす場合、ハードウェア性能による実行速度の差が、ベンチマーク上の「能力差」として誤認されるリスクがあります。評価指標を導入する際は、タスクの正誤だけでなく、どのようなリソース制約下での結果であるかを明確に定義し、継続的に検証する運用フローを組み込むことが重要です。
出典: Benchmarks as Software: Terminal-Bench and the Case for Continuous Benchmarks（Hugging Face Daily Papers（非公式）） / Harness Leaderboard – Kimi Code, Hermes, Pi, Claude Code, Codex, and Others Were Benchmarked Against Terminal Bench 2.1 & Deep SWE 1.1（r/LocalLLaMA）
22MBの超軽量視覚言語モデル「Mirage」公開、エッジデバイスでの動作を実現
Cactus Compute社が、スマートフォンやウェアラブル端末向けに設計された超軽量視覚言語モデル「Mirage」を公開しました。モデルサイズは22MB（パラメータ数51.3M）で、シーン記述、物体検出、OCR、セグメンテーションなどの機能を単一パスで実行可能です。Samsung Galaxy S26での検証では、NPUで74ms、CPUで107msの処理速度を記録しています。記述機能は英語を含む7言語に対応しています。
解説
本モデルの最大の特徴は、極限まで圧縮されたサイズでありながら、視覚情報の構造化抽出を高速に行える点にあります。従来のVLMが自然言語による記述にリソースを割いていたのに対し、Mirageは空間ヘッドや専用のテキストリーダーを用いて構造的なデータを出力することで、効率化を図っています。
このアプローチは、常時動作が求められるウェアラブルデバイスやロボットなどのエッジ環境において、低消費電力で視覚認識を組み込みたい開発者に有用です。特に、Mirageで抽出した構造化データをテキスト専用のLLMに渡すことで、LLM側にVLMのような能力を付与できる可能性が示唆されており、軽量モデルの組み合わせによるパイプライン構築という新たな選択肢を提示しています。
導入にあたっては、モデルサイズが極小である分、認識漏れなどの知覚エラーが発生するリスクがある点に注意が必要です。また、後段に接続するLLMとの相性や、出力フォーマットの遵守精度が全体のパフォーマンスに影響するため、実用的な精度が出るかどうかの検証が不可欠です。
SageMaker InferenceがMIGに対応し、GPUリソースの最適化とコスト削減が可能に
AWSは、Amazon SageMaker InferenceにおいてNVIDIAのMulti-Instance GPU（MIG）を利用したGPUパーティショニング機能を提供開始した。これにより、1つの物理GPUを最大7つの独立したパーティションに分割し、それぞれに異なるモデルを配置することが可能になる。本機能は推論コンポーネント（inference components）を利用するエンドポイントで動作し、ハードウェアレベルで計算リソースとメモリが隔離される。これにより、モデルごとのリソース最適化と、相互干渉のない安定したレイテンシの確保が実現する。
解説
これまでのSageMakerでは、モデルをデプロイする際の最小単位がGPU 1枚であったため、小規模なモデルであっても1枚分を占有し、リソースの浪費やコスト増を招いていた。今回のMIG対応により、1枚の高性能GPUを分割して複数のモデルをホストできるため、リソース利用率の向上とコスト効率の最適化が同時に達成できる。
特に、顧客ごとにファインチューニングしたモデルを多数運用する場合や、モデルサイズが異なる複数のAIを同一インスタンスで動かしたい開発者にとって大きなメリットとなる。ハードウェアレベルで隔離されるため、特定のモデルへの負荷急増が他のモデルのパフォーマンスに影響を与えない点も、実務運用上の重要な改善点である。
導入にあたっては、本機能が「推論コンポーネント」を利用する構成に限定されており、サーバーレスエンドポイントや単一モデルエンドポイントでは利用できない点に注意が必要である。また、利用するGPUインスタンスがMIGに対応しているか、および適切なパーティション分割設定を選択できるかの検証が不可欠となる。
出典: SageMaker Inference now supports Multi-Instance GPU to maximize GPU utilization for model endpoints（AWS Machine Learning Blog） / How Greenlight Financial built an autonomous SOC solution on Amazon Bedrock AgentCore（AWS Machine Learning Blog）
空研工業とRecursiveがAIナレッジ基盤を開発、図面検索時間を大幅短縮
空研工業とRecursiveは、OpenAI APIを用いた「AIナレッジ基盤システム」を共同開発しました。このシステムは、過去の図面や技術資料から情報を探す「図面検索」と、資料間の整合性を確認する「図面チェック」の2つの機能を搭載しています。試用段階の検証では、従来は数十分から半日かかっていた図面検索の時間が平均4.5分に短縮され、年間の工数を90%削減できる見込みであることが示されました。
解説
製造業における熟練者の経験に依存した「資料探し」という非効率な業務を、AIによるセマンティック検索やドキュメント解析で自動化した事例です。従来のキーワード検索では困難だった、図面や技術資料という非構造化データの探索を効率化できる点に大きな意味があります。
特に、膨大な過去資産を抱えながら、若手への技術伝承や資料の散在に課題を持つ製造業の設計・開発部門にとって極めて有用です。資料探索の時間が分単位に短縮されることで、本来の設計業務に集中できる環境が構築され、リードタイムの短縮に直結します。
導入にあたっては、図面という機密性の高い情報を扱うため、API経由でのデータ取り扱いにおけるセキュリティ担保が最優先事項となります。また、図面特有の表記や専門用語をAIが正しく解釈できるかという精度の検証、および最新の図面が正しくインデックスされる運用フローの構築が重要です。
出典: AIで過去図面を検索、資料探索を平均4.5分に短縮し年間工数90％削減へ（ITmedia AI＋）
AIエージェントの本番運用におけるリスク管理とMCPの役割
Linux Foundation傘下のAgentic AI Foundation（AAIF）が、東京・渋谷で「AGNTCon + MCPCon Japan 2026」を日本で初めて開催した。イベントではMCP（Model Context Protocol）の共同開発者らが登壇し、AIエージェントの現状と運用上の課題について講演を行った。特に、AIエージェントが誤った操作を行い、想定外の金額を処理してしまうといった暴走リスクへの対策が議論された。
解説
AIエージェントが単なるチャットボットを超え、外部ツールを操作してタスクを完結させる「エージェント機能」の実装が進んでいます。MCPのような共通プロトコルの普及は、モデルと外部データの連携を効率化しますが、同時にAIに権限を与えることによる運用リスクを増大させます。特に決済やデータ更新を伴う業務への導入では、人間による承認フロー（Human-in-the-Loop）の設計が不可欠です。
この技術は、定型的なワークフローの自動化を目指すエンジニアや、社内ツールをAIで統合したいビジネスパーソンにとって極めて有用です。ただし、導入時には「AIがどこまで権限を持つか」という権限管理の設計と、誤作動時のロールバック体制など、セキュリティとガバナンスの観点からの検証が重要になります。
出典: 「48ドルの返金が4800ドルに」 AIエージェントの暴走を止める、本番運用の勘所（ITmedia AI＋）
長期的タスクに特化した300B規模のRLモデル「FireFlash」のレシピ公開
研究チームが、長期的かつ自律的なエージェントタスクに最適化した300B規模のモデル「FireFlash」を発表しました。NVIDIA B300 GPU 64枚を用い、5日未満の学習期間で開発されており、ターミナル操作やコーディングなどのベンチマークでGPT-6 Sol等と同等の性能を達成しつつ、コストを大幅に削減しています。開発チームは、学習環境の精査やRLレシピ、最適化されたコーディングハーネスを含む全レシピを公開し、モデルのウェイトも近日中に公開する予定です。
解説
今回の発表は、数千枚規模のGPUを投入する巨大ラボでなくとも、数百枚規模のクラスターでフロンティア級の性能を持つエージェントモデルを構築できる可能性を示した点に大きな意味があります。特に、推論コストを抑えつつ高度なコーディングやターミナル操作を完結させる能力は、ソフトウェア開発の自動化や複雑なワークフローの構築を目指す技術者にとって極めて有用です。
導入や検証においては、モデルの規模が300Bと非常に大きいため、推論時のメモリ要件が最大のボトルネックとなります。オープンウェイトで提供される予定ですが、実用的な速度で動作させるには、相当なVRAM容量を持つハードウェア環境が必要です。また、レシピが公開されるため、特定のドメインに特化したエージェントを自前で強化学習（RL）させる際のベースラインとして活用できるかが焦点となります。
出典: [Paper] FireFlash : An Open Recipe for Long-Horizon Agentic RL Achieving the Performance-Cost Pareto Frontier（r/LocalLLaMA）
よくある質問
- Q.Ripple-65B Previewとはどのようなモデルですか？
- A.Ricursive Intelligence社が公開したコーディング特化のオープンウェイトモデルで、Apache 2.0ライセンスにより商用利用が可能です。
- Q.Ripple-65Bを導入する際に注意すべきハードウェア上の制約は何ですか？
- A.モデルサイズが65Bと大きいためメモリ消費が激しく、導入には十分なVRAMを搭載したハードウェア環境の整備が不可欠です。
