本記事は 2026 年 4 月 2 日に公開された Nima Kaviani による “ MiniMax M2.5 and GLM-5 are now in Kiro ” を翻訳したものです。 Kiro のオープンウェイトモデルへのネイティブサポートを拡充してきました。最近では MiniMax M2.5 に続き、GLM-5 も Kiro IDE および CLI から直接利用できるようになりました。Kiro はすでにコスト・コンテキスト長・速度のバランスが異なる多様なモデルをサポートしています。今回の 2 つの追加により、その幅がさらに広がり、開発者やチームが目の前の作業に応じてモデルを選択できる余地が増えました。 モデルの詳細 各モデル が持つ特徴と、得意とする用途について詳しく見ていきましょう。 MiniMax M2.5 （クレジット乗数 0.25x）— クエリごとに 100 億パラメーターを活性化するスパース MoE (Mixture of Experts) モデルです。わずか 4 分の 1 のクレジットコストで、SWE-Bench Verified において 80.2% のスコアを記録しており、Claude Sonnet を超えた初のオープンウェイトモデルとして、Claude Opus 4.6（80.8%）に次ぐ位置につけています。Kiro の中でも最もコスト効率の高いモデルの一つです。MiniMax M2.1 と比較して複雑なエージェントタスクを 37% 高速に完了します。コードを書く前に機能を分解して構造をマッピングするため、マルチステップの実装作業や長時間のエージェントセッションに優れています。また、10 以上の言語（Go、C、C++、TypeScript、Rust、Kotlin、Python、Java、JavaScript など）にわたる強力な多言語サポートを提供し、Web、Android、iOS、Windows にまたがるフルスタックプロジェクトにも対応しています。継続的なコーディングセッションや反復的な実装作業に対して、高速かつコスト効率の高いモデルをお求めであれば、MiniMax M2.5 は有力な選択肢です。 GLM-5 （クレジット乗数 0.5x）— 200K コンテキストウィンドウを備えた大規模 MoE モデルです。GLM-5 は長期的なエージェントワークフローに最適化されています。リポジトリ規模のコンテキストを処理し、大規模なコードベースにわたるマルチステップのツール使用において一貫性を維持することに優れています。クロスファイルのマイグレーション、フルスタックの機能開発、あるいはモデルが全体像を把握する必要があるレガシーリファクタリングなどのユースケースが該当します。深いコンテキストが求められる複雑なアーキテクチャ変更に取り組んでいる場合は、GLM-5 を試してみる価値があります。 IDE と CLI で試してみましょう これらのモデルは現在、 IDE のモデルセレクター および Kiro CLI から実験的サポートとして利用できます。MiniMax M2.5 は AWS US-East-1（バージニア北部）および AWS EU-Central-1（フランクフルト）リージョンで利用可能です。GLM-5 の推論は AWS US-East-1（バージニア北部）リージョンで実行されます。 また、Kiro にすでに搭載されているオープンウェイトモデルへのアクセスも拡大しました。MiniMax M2.1、Qwen3 Coder Next、Deepseek V3.2 は、IAM Identity Center（IdC）経由で認証しているユーザーを含む全ユーザーが利用できるようになりました。推論をワークロードに近づけるため、MiniMax M2.1 と Qwen3 Coder Next は AWS US-East-1（バージニア北部）に加えて AWS EU-Central-1（フランクフルト）リージョンでも利用可能です。 設定不要、ルーティング不要、追加セットアップ不要でモデルを選んですぐに作業を始められます。モデルを切り替えたり、特定のプロジェクトタイプにデフォルトを設定したり、Auto に任せたりと、ワークフローに合わせてご利用ください。エンタープライズチームの場合、管理者は モデルガバナンス を使用して、利用可能なモデルをコンプライアンスおよびデータレジデンシーの要件に合わせることができます。いつものように、ぜひ試してみて、 使い心地をお聞かせください 。どのモデルが好評で、どのような課題が残っているかを注視しています。次にサポートしてほしいモデルがあれば、 ぜひご要望をお寄せください 。 翻訳は Solutions Architect の吉村 が担当いたしました。

こんにちは。ＳＣＳＫの池田です。 2025年11月12日にLifeKeeperが10年ぶりのメジャーバージョンアップを果たしました。これまでOS毎に異なっていたライセンス体系やサポート期間の考え方が統一されるなど、「全てをシンプルに、より分かりやすく、より使いやすく」をコンセプトに改変が行われました。 具体的な内容は以前の記事をご確認ください。 LifeKeeper v10リリース記念　これまでと何が変ったか！？ 今回は、LifeKeeperの姉妹製品であるSingle Server Protection v10のライセンスについて解説したいと思います。   Single Server Protectionの名前が変わりました まずライセンス体系に入る前に、お伝えしないといけないこととして、Single Server Protectionのライセンス名称がv10に統一されています。   以前のライセンス名 v10のライセンス名 Windows版 Single Server Protection for Windows LifeKeeper v10 for SingleServer Linux版 Single Server Protection for Linux   Windows版のライセンス体系 続いて、Windows版の旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。 こちらの図をご覧ください。 上の図のように、旧バージョンではSingle Server Protection for WindowsにDB製品やIISが同梱されていましたが、新バージョンでは、DB製品が「Recovery Kit for Database-SS」という独立した製品になっています。その分、LifeKeeper v10 for SingleServerの価格がお安くなっています。「LifeKeeper v10 for SingleServer」は、よりお求めやすい価格で可用性を実現して欲しいというサイオステクノロジー社の想いが垣間見れますね。 また旧バージョンではJP1/AJS Manager、Agent、HULFTとミドルウェアごとにARKが用意されていましたが、v10では「Recovery Kit for Enterprise Apps-SS」に集約されている点も大きな変更点になります。 LifeKeeper v10 for SingleServerの価格が安くなるのはうれしいなぁ   Linux版のライセンス体系 続いて、Linux版の旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。 こちらの図をご覧ください。 Linux版の場合、旧バージョンでは多くのRecovery Kitが同梱されていましたが、Windows同様に新バージョンでは、DB製品が「Recovery Kit for Database-SS」という独立した製品になっていまして、LifeKeeper v10 for SingleServerの価格がお安くなっています。 また本体に同梱されていたWebSphere MQや、JP1/AJSやHULFT用のRecovey Kitが「Recovery Kit for Enterprise Apps-SS」に集約されている点も大きく変わった点となります。 まとめ LifeKeeperと同様にSingle Server Protectionについても、v10でライセンスが統一されましたが、OSごとに冗長化することができるミドルウェア製品が異なることから、それぞれの利便性を確保しつつ、ライセンス体系の見直しが行われてたようです。 「以前のバージョンでは同梱されていたRecovery Kitが、新バージョンで含まれていない」という事態にならないように、十分注意を払いながら必要なライセンスを購入していただければと思います。 少しでも不安な場合は、サイオステクノロジー社から認定されたSI&サポートパートナーであるSCSKにお問い合わせください。 オステクノロジー認定のSI&Supportパートナー （サイオステクノロジー公式サイト） Lifekeeperの製品体系 （サイオステクノロジー公式サイト） 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

皆様は、「DataKeeper」という製品をご存知でしょうか。 DataKeeperとは、稼働中のサーバのデータを、リアルタイムで待機系に複製（ミラーリング）し、止めないシステム運用を実現するソフトウェアです。 クラスタノード間でボリュームをミラーリングし、あたかも共有ストレージのように扱うことが可能になります。クラスタリングソフトウェアであるLifeKeeperやWindowsのWSFC（Windows Server Failover Clustering）と連携することにより、高可用性を実現しつつ、データの冗長性を確保することが可能となります。   本記事では、DataKeeperの機能や特徴を解説し、どのような状況で活用していくかについて紹介していきます。   DataKeeperの基本機能・主な特長 基本機能 DataKeeperは、稼働系と待機系のローカルディスク上のボリュームをレプリケーションの技術で同期し、 それらのボリュームを論理的な共有ディスクのように扱い、LifeKeeperおよびWSFCとも連携する機能が特徴です。 DataKeeperの構成イメージ   サーバ毎に接続されたローカルディスク上のボリュームをレプリケーションし、 ミラーボリュームを作成することで、共有ディスクとして扱うことが可能となります。 障害発生時には LifeKeeper と連携してLifeKeeperが監視・フェイルオーバーを実行し、 DataKeeperがデータレプリケーションを担い、論理共有ディスク上のデータをそのまま待機系に引き継ぎます。   主な特徴 ■ブロックレベルのリアルタイム・レプリケーション 同期／非同期に対応しており、WAN向け最適化や圧縮も備え、レイテンシー環境でも帯域効率よく複製します。帯域制御とパフォーマンスについては、ファイル単位ではなく「ブロックレベル」となるため、高速での転送が可能となります。 同期に使うネットワーク帯域を調整できるため、業務ネットワークへの影響を最小限に抑えられます。   ■WSFCとネイティブ連携 DataKeeper VolumeをWSFCのリソースとして扱い、クラスタ側の制御に自然統合することができます。 Windows標準のクラスタ機能（WSFC）が、DataKeeperのボリュームを「物理ディスクリソース」として認識し、SQL Serverやファイルサーバの冗長化をする際、使い慣れた WSFC の管理画面で運用できるため、学習コストを増やさずに導入できます。   ■クラウド/仮想/物理を横断 AWS/Azure/GCPやVMware、オンプレ物理で同じ考え方で設計・展開が可能となります。 AWSやAzureでは、オンプレミスのような「共有ストレージ（SAN）」をマウントしてクラスタを組むのが難しい、または高価なマネージドサービスが必要となりますが、 DataKeeperを使えば、ローカルディスク同士を同期させるだけでクラスタを組むことが可能です。   ■コスト最適化 共有ストレージが不要となり、OSからは「共有ディスク」として認識されるため、アプリケーション側の対応が不要、コストを抑えることができます。   では、これらの特徴が実際の現場でどのように役立つのか、シチュエーションごとに DataKeeper の活用イメージを紹介します。   シチュエーション別、DataKeeperの活用事例 1) クラウド移行を検討中の情シス（AWS） 前提 ：既存オンプレで SQL Server FCI や ファイルサーバクラスタ を利用中 AWS に移行しても ダウンタイムを極小化した高可用性（HA） 構成 を維持したい 課題 ： AWS では、共有ディスク構成が直接使えない/FSx for Windows（共有ファイルサービス）が割高/　　マルチAZをまたいだ共有ストレージ提供が制約多い、という背景がある 解決 ：DataKeeper を使うことで、各ノードのローカル EBS（ディスク）上のボリュームをブロック単位で同期し、 共有ディスクなしでも WSFC）を構築可能。またマルチAZまで柔軟に拡張可能となります。AWS に「オンプレ同等の可用性構成」を持ち込めます。 構成イメージ(AWS)： マルチAZの SQL Server FCI/ファイルサーバ にLifeKeeper + DataKeeper を導入した構成各ノードはローカル EBS を利用 DataKeeper が ブロックレベルで EBS を同期（Sync/Async） LifeKeeper/WSFC によりAZ 障害時は自動フェイルオーバー ➡ 共有ディスクが不要なため、AWS の制約（共有ストレージ/コスト）を解消できます   2) 共有ストレージのコストや仕様で悩むエンジニア 前提 ：オンプレ/仮想環境で NAS/SAN などの共有ストレージ を利用している 課題 ：共有ストレージは高コスト、専用スキルや運用の複雑性、SPOFが気になる。 解決 ：DataKeeperは既存のローカルストレージを活用し、SPOFを排除。 SSD/フラッシュも活かせるため性能面でも優位。 アレイ依存のレプリケーションに比べ、コスト効率の高いHA/DRが構築可能。  構成イメージ ：Azure：ASCS/ERSやDBのWSFCを共有ディスク不要で内部LB・クォーラム設計のガイダンスに沿い、DataKeeperで共有相当を実現。 ➡コストを下げつつ、ストレージの複雑性・制約をすべて解消できます     他方式とのDataKeeperの比較 具体的な活用イメージをご紹介しましたが、他方式と比べてどこが優れているのか？も気になるポイントです。 代表的な方式との比較を整理してみます。  比較対象 DataKeeper導入のメリット DataKeeper導入のデメリット vs クラウド共有ストレージ（FSx/Azure Files等） ・コスト最適化（従量課金を排除） ・マルチAZ対応 ・ローカルI/Oで性能が安定 ・局所レイテンシ低減の余地 ・レプリケーション帯域の確保が必要 ・ローカルディスク障害時の運用が発生 ・一般的に2ノード中心 vs S2D （Storage Spaces Direct） ・WSFC＋既存ディスクで即構成 ・クラウド横断で利用可能 ・専用NIC/ハード不要 ・学習コストが低い ・スケールアウトストレージ機能なし ・大規模分散用途には不向き ・ソフトウェアライセンス費用が発生 vs SQL Server Always On（AG） ・DB以外も保護可能 ・SEでFCIが作れライセンス最適 ・アプリ改修不要 ・フェイルオーバーが単純 ・読み取り専用レプリカ不可 ・全ボリュームレプリケーション ・AGにあるDBレベル機能を持たない   比較を踏まえて理解が深まったところで、 実際の相談でよくいただく質問もまとめておきます。 よくある質問（FAQ） Q1. レプリケーションは同期／非同期を切り替えられますか？ A. はい。ブロックレベルで同期／非同期を選択でき、切り替えも可能です。 Q2. SQL Server Standard EditionでもFCIを構築できますか？ A. 可能です。DataKeeper＋WSFCで共有ディスク相当を提供できるため、Standard EditionでもFCIを構成できます。 Q3. ネットワーク障害でノード間の通信が切断された場合、再同期はどうなりますか？ A. フル同期のやり直しは不要です。通信が途絶えた際、DataKeeperはレプリケーションを一時停止し、変更されたブロック箇所（差分）だけを内部のビットマップメモリに記録し続けます。ネットワーク復旧後は、その差分データのみが自動的に再同期（部分再同期）されるため、システムへの負荷を最小限に抑えて正常な状態に復帰できます。 Q4. DataKeeperでレプリケーションできないデータはありますか？ A. はい。Cドライブなどの「OSシステム領域（システムボリューム）」はレプリケーションの対象外となります。また、DataKeeperはドライブ（ボリューム）単位でのブロック同期を行うため、「特定のファイルやフォルダだけ」を指定して同期することも仕様上できません。   まとめ DataKeeperでは、AWSやAzure等のクラウド・オンプレを問わず、同じアーキテクチャ思想で設計・展開・運用できるのが強みであることをお伝えいたしました。 LifeKeeper連携まで含めた“アプリもデータも守る”設計で、止めないシステム運用を支援します。  詳しい内容をお知りになりたいかたは、以下バナーからお問合せください。