【てくさぽBLOG】IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.1）

一覧に戻る

2021年08月

【てくさぽBLOG】IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.1）

ブログ

こんにちは。
てくさぽBLOGメンバーの村上です。

本ブログは、IBM Power Virtual Server をトライしてみた内容や感想をご紹介するブログです。

シリーズ化していますので、まずインデックスのご紹介をします。

インデックス

・IBM Power Virtual ServerでAIX環境を作ってみた
・IBM Power Virtual ServerのAIX環境にSWを導入してみた
・IBM Power Virtual ServerのAIX環境を日本ロケールにしてみた
・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.1） ←今回
・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.2）
・IBM Power Virtual ServerのAIX環境とIBM Cloud x86環境を接続してみた

今回は、AIX環境のバックアップ手順のご紹介です。
検証環境で2種類のバックアップ方法を試しましたので、Part.1(本ブログ)とPart.2に分けてご紹介いたします。

Power Virtual Server バックアップ方法

Power Virtual Server の AIX インスタンスでは、以下の4種類のバックアップ方法が推奨されています。
※技術寄りな人が最初に読む_IBMCloud柔らか層本を参照(情報は20210811版より抜粋)

取得方法	提供方法	取得対象
Image Capture	IBM Cloud で提供される	任意のVolumeGroup
Flash Copy	IBM Cloud で提供される	任意のVolumeGroup
mksysb / savevg	AIX OS標準でサポートされる方式	任意のVolumeGroup
バックアップ・ソフトウェア利用	お客さまが別途ソフトウェアを購入	OS領域以外のデータ領域

上記の表の太字にしていない「mksysb / savevg」と「バックアップ・ソフトウェア利用」のバックアップ方法は、オンプレミス環境で頻繁に利用されているのでイメージが付きやすいと思います。
そのため、IBM Cloud の機能で提供されている「Image Capture」と「Flash Copy」のバックアップ方法を試すことにしました。

今回は「AIX環境をバックアップしてみた Part.1」として、Image Capture によるバックアップ取得手順と、そのバックアップデータを IBM Cloud Object Storage に保管する手順をご紹介します。

セクション

以下の1)～4)のセクションに分けてご紹介します。

1） Image Capture の説明
2） Image Capture によるバックアップ取得
3） IBM Cloud Object Storage の準備
4） IBM Cloud Object Storage への保管

準備工程にかかる時間は別として、2) の「 Image Capture によるバックアップ取得」は数十秒(バックアップ容量が20GB(USEDは13GB))、4) の「IBM Cloud Object Storage への保管」は約17分程度(圧縮後のデータ容量が6.6GB)でした。

検証はAIXのインスタンスで行いましたが、IBM i のインスタンスでも同等の手順で操作を行うことができます。

利用したクライアント端末（私のPC）は、Windows10 pro バージョン2004です。

1) Image Capture の説明

Image Capture は Power Virtual Server の WEBインターフェース画面で簡単に実行することができます。

＜Image Capture とは＞

説明	・IBM Cloud で提供され、LPARのOVAイメージ(※)が出力される・OVAイメージを使って別のインスタンスのデプロイが可能となる
主な用途	・移行・複製（マスターイメージの管理）・遠隔地保管
対象	rootvg を含む任意のボリューム
保管場所	・Image Catalog ・IBM Cloud Object Storage
取得時の LPAR停止有無	不要 ※ ファイルの整合性担保のためにLPARを停止することが推奨される
制約事項など	・手順を検証した上でバックアップとしても運用可能・サービス内の同時実行数は「1」・合計のボリュームサイズは最大10TB ・Flash Copy に比べると時間がかかる

(※) OVAイメージとは、Open Virtual Appliance の略で、仮想サーバの構成や状態を丸ごとデータとしてファイルに写し取ったデータ形式のことです。

本来、Image Capture は移行や複製を目的とするようなのですが、制約事項に記載した通り、手順を確立する必要はあるもののバックアップとして利用できそうです。

また、制約事項に「Flash Copy より時間はかかる」とありますが、AIXユーザは mksysb や savevg の長時間バックアップに慣れているので、Flash Copy のような高速バックアップに比べて時間がかかる、くらいなら問題ないと感じます。

2) Image Capture によるバックアップ取得

前置きの説明が長くなりましたが、ここからは実際のバックアップ取得の手順となります。

IBM Cloud にログインし、インスタンスの詳細画面を表示します。
（インスタンスの詳細画面の表示方法は以前のブログに記載しています
【やってみた】IBM Power Virtual Server のAIX環境にSWを導入してみた）

・「サーバ詳細」の右上に表示されている「VMアクション」のプルダウンをクリックし、「取り込んでエクスポート」をクリックします。

「AIX72-test の取り込みおよびエクスポート」画面が表示されます。

・バックアップ対象ボリュームを選択します。
・エクスポート先は「イメージ・カタログ」を選択します。
・「カタログ・イメージ名」に任意の名前を入れます。「AIX72_CP」という名前にしました。
・「取り込んでエクスポート」をクリックします。この操作がバックアップ実行ボタンです。

バックアップが進行しているメッセージが出力されます。

上記のメッセージのように「completed」が表示されたらバックアップが完了です。
取得したバックアップデータを確認します。

・WEBインターフェース画面の左ペインの「ブート・イメージ」をクリックします。

・「ブートイメージ」のリストに、先ほどバックアップを取得した「AIX72_CP」がリストアップされていることを確認します。

※「AIX72_CP」の上に表示されている「7200-05-01」は、インスタンス「AIX72-test」作成時にできるイメージです。

以上で、簡単にバックアップが取得できました！

通常は数十分かかるようなバックアップが1分もかからずに実行できたので驚きました。
次のセクションでは、取得したバックアップを別の場所（IBM Cloud Object Storage）にエクスポートします。

3) IBM Cloud Object Storage の準備

2) で取得したバックアップをIBM Cloud Object Storageにエクスポートする前に、IBM Cloud Object Storage のサービスを作成する必要があります（IBM Cloud Object Storage は、これ以降、ICOS と記載します）。

バックアップをICOS上にエクスポートすることで、Power Virtual Server のサービスが削除された後もバックアップデータを残しておくことができます。

ICOS には無料のライトプランが以下の条件で提供されており、今回は以下の条件に当てはまるのでライトプランを利用します。

・1サービス、1ICOS
・最大25GBのストレージ容量
・最大20,000 GET 要求/月
・最大2,000 PUT 要求/月
・最大10GB/月のデータの取得
・最大5GBのパブリック・アウトバウンドライト・プラン・サービスは、非アクティブで 30 日経過すると削除されます。

では、ICOSの環境を準備します。
（ICOSの準備は手順が少し長いですが、難しくないのでぜひお付き合いください）

・IBM Cloud のWEB画面右上の「カタログ」をクリックします。

・検索バーに「object」と入力し、一番上にリストされる「Object Storage」を選択します。

以下の様に、ICOS のサービス作成画面が表示されます。

・「リソースの構成」の「サービス名」の欄に任意のサービス名を記載します。今回は「COS-TEST」という名前にしました。

・ライトプランなので金額が無料であることを確認し「作成」をクリックします。

ICOS サービスが作成できると下記の画面が表示されます。

ICOSサービスは、以下の通り、リソース・リストで確認でき、「ストレージ」のプルダウン以下にリストされます。

次は、「COS-TEST」内にバケットを作成します。

・リソース・リストにリストされた「COS-TEST」をクリックします。
・「バケットを作成」をクリックします。

・「バケットのカスタマイズ」をクリックします。

「カスタム・バケット」の画面に移動します。

・「固有のバケット名」に任意の名称を入れます。今回は「cos-test-2021」としました。
・「回復力」は初期状態の「Regional」を選択したままとします。
・「ロケーション」は「jp-tok」を選択します。
・「ストレージ・クラス」は初期状態の「Smart Tier」を選択したままとします。

・その他の項目は初期状態のままとし、画面の一番下にスクロールして「バケットの作成」をクリックします。

バケットが作成できました。

このバケットにアクセス・ポリシーを設定します。

・上記の画面で「cos-test-2021」をクリックします。
・左ペインに表示される「アクセス・ポリシー」をクリックします。
・「ユーザを選択」のプルダウンから権限を付与するユーザを選択します。
・「このパケットの役割」は初期状態の「ライター」を選択します。
・「アクセス・ポリシーの作成」をクリックします。

アクセス・ポリシーの設定が完了すると以下が出力されます。

ICOSサービス資格情報を生成します。

・左ペインより「サービス資格情報」を選択し、「サービス資格情報」の画面上に表示される「新規資格情報」をクリックします。

「資格情報の作成」の画面となります。

・「HMAC資格情報を含める」を「オン」にします。
・内容を確認して「追加」をクリックします。

サービスの資格情報が生成されました。

・「cos_hmac_keys」の情報は、ICOSへバックアップデータをエクスポートする際に利用するのでコピペしておきます。

ICOSの準備が完了しました。
さて、次はバックアップイメージのエクスポート作業です。

4) IBM Cloud Object Storage への保管

2)で取得したバックアップイメージを、3) で作成したICOSのバケット内にエクスポートします。

・2)で取得したバックアップイメージを表示します。
・ブート・イメージ「AIX72_CP」の右側にある上矢印のマークをクリックします。これがエクスポートのボタンです。

「AIX72_CPを Cloud Object Storage にエクスポート」の画面が表示されます。

・「リージョン」は「jp-tok」を選択します。
・「バケット名」は3)で作成した「cos-test-2021」を入力します。
・「HMACアクセス鍵」には、3) の手順でコピーしたサービス資格情報を入力します。
・「HMAXシークレット・アクセス鍵」にも、3) の手順でコピーしたサービス資格情報を入力します。
・すべての内容を確認し「エクスポート」をクリックします。

エクスポートの進捗は、ポップアップで画面に表示されます（すぐにポップアップが消えてしまい画面ショットは取れませんでした・・）。

バックアップイメージのエクスポートが完了したら、以下のようにICOSの「オブジェクト」画面にオブジェクトが追加されます。

バックアップイメージのエクスポートが完了しました！

6.6GB のバックアップイメージがエクスポートされたことが分かります。
（OVAイメージは自動で圧縮されていました）
エクスポートは約17分程度で完了しました。約6.6MB/秒の転送速度です。 ICOSはIBM Cloud の x86側のサービスを利用しているのもあり、転送速度はちょっと遅いですね。

転送速度を上げるためには、Aspera の利用を検討してみてもよいかもしれません(利用する際は別料金です)。

ICOSを初めて利用する際はICOSの準備に少し手間がかかりましたが、バックアップイメージのエクスポートはとても簡単でした！

次のブログでは、AIXインスタンスのバックアップ手順 Part.2をご紹介しています。
【やってみた】IBM Power Virtual Server のAIX環境をバックアップしてみた Part.2

最後に

実は、Power Virtual Server のバックアップの検証は2021年2月に完了していました。
本ブログを書くタイミングで、久しぶりにPower Virtual Server を触ってみると、ちょこちょこと仕様（画面の見え方など）が変わっていることに気づきまして、検証をやり直しました。

さすが、更新が頻繁に入っているPower Virtual Server ですね。
（情報発信は時間を置かずにすぐにやらないといけませんね！）

最新情報を逃さないよう、頻繁にチェックしていきたいと思います。

お問い合わせ

この記事に関するご質問は下記までご連絡ください。

エヌアイシー・パートナーズ株式会社
技術支援本部
E-Mail：nicp_support@NIandC.co.jp

2025年11月05日

クラウド環境のインフラストラクチャ自動化にIaCツール「IBM Terraform」が活用される理由

公開日：2025-11-04 企業の中で、さまざまなシステムが存在する今、環境が変わっても、システムが同じ動きをしなければ、開発者の負担となるだけでなく、ユーザーからのクレームを招くことにもなります。特に、大量のリクエストを捌くためのシステムでは、コンテナを活用してサーバー台数を自動で増減させるような仕組みが必要です。そこで今、企業に求められているものが、インフラストラクチャの効率的な管理を実現する自動化です。本コラムでは、インフラストラクチャの自動化において注目されている、「コードとしてのインフラストラクチャ : Infrastructure as Code（IaC）」の活用メリットと、今、世界のクラウド環境でもっとも多く利用されているIaC ツール「Terraform」をご紹介します。目次規模と複雑さが増大し続けるITインフラストラクチャに対して、企業に求められる課題 ITインフラストラクチャの自動化が必要な理由「Infrastructure as Code（IaC）」による自動化のメリットクラウド環境でもっとも利用されている IaC ツール「Terraform」 Terraformが選ばれる理由 TerraformとAnsibleの連携で実現するエンドツーエンドのハイブリッド・クラウド・プラットフォームまとめお問い合わせ規模と複雑さが増大し続けるITインフラストラクチャに対して、企業に求められる課題多くの企業が、1日に何百ものアプリケーションを本番環境にデプロイしています。そこでは常に、ITインフラストラクチャが要求に応じて立ち上げられ、あるいは削減され、その規模は頻繁に拡大や縮小が行われています。そのため、ITインフラストラクチャを安全かつ効率的に、構築、変更、バージョン管理することが、企業が提供するビジネスの品質・スピード・競争力を左右する最も重要な要素となりました。しかし、企業や組織のITインフラストラクチャの規模と複雑さが増大する一方で、時間やスタッフの数には限りがあり、ITチームは従来の手法ではこの拡大に対応するのが精一杯となっています。その結果、システムの更新やパッチの適用、リソースの提供に遅れが生じ始めている状況です。そこで今、企業が急ぎ導入を進めているのが、「ITインフラストラクチャの自動化」です。 ITインフラストラクチャの自動化によって、プロビジョニング、構成、デプロイ、撤去などの一般的な管理タスクを含む幅広い運用を単純化できるほか、ITインフラストラクチャに対する制御力や可視性を取り戻すことが可能となります。そのため、企業においてITインフラストラクチャの自動化は、コストを管理し、リスクを低減し、新たなビジネスチャンスや競争上の脅威に迅速に対応するためには不可欠な施策となっています。 ITインフラストラクチャの自動化が必要な理由 ITインフラストラクチャの自動化の必要性には、具体的に次のようなものが挙げられます。マルチクラウドやハイブリッドクラウドの活用マルチクラウドやハイブリッドクラウドの活用している場合、ITインフラストラクチャの管理において、多種多様な複数クラウドを管理するだけでなく、マルチクラウド間でのリソース移行や追加が求められます。また、クラウドネイティブアーキテクチャの採用においては、Kubernetesやサーバレスリソースのプロビジョニングなど、柔軟なリソース展開とスケーリングにも対応しなければなりません。コンプライアンスとセキュリティへの対応 ITインフラストラクチャの管理において、コンプライアンスとセキュリティに対応するためには、変更履歴のトレーサビリティを確保しつつ、セキュリティ要件と一貫性のある構成変更を行うことが重要となります。また、リソースコストの最適化を図るだけでなく、複数リージョンの管理と迅速な障害復旧によるグローバルな運用と展開を実現することも必要です。クラウドコストの削減クラウドに対する企業のコストは年々増加しており、クラウドコストの削減も大きな懸念事項となっています。正しいクラウドのライフサイクル管理を行えば回避可能なインフラストラクチャ関連コストとしては、ワークロードに対するリソースのオーバー・プロビジョニング未使用または十分に活用されていない開発/テスト用環境などのリソース標準化された共有サービス不足による専門知識、一貫したワークフロー、引き継ぎ不足環境削除のための有効期限未設定による一時的なクラウドリソースの稼働継続などがありますが、これらの無駄なクラウドコストを削減するためには、初期プロビジョニングだけでなく、ライフサイクル全体の管理が必要です。「Infrastructure as Code（IaC）」による自動化のメリット ITインフラストラクチャの自動化において、多くの企業から注目されているのが、インフラストラクチャをコードベースで管理・自動化できる「Infrastructure as Code（IaC）」です。 IaC は、サーバーやネットワークといったITインフラストラクチャの構成と管理に、手動プロセスではなく、高レベルの記述モデルで記述的なコーディング言語（プログラム）を用いる手法です。ネットワーク、仮想マシン、ロード・バランサー、クラスター、サービス、および接続トポロジーなど、組織のITインフラストラクチャの管理およびプロビジョニングを自動化することで、リスクとコストを抑えながら、より迅速なクラウド・アプリケーションの開発・導入・拡張を可能にします。また IaC は、ソフトウェア・デリバリー・ライフサイクルに欠かせない DevOps において、競争力のあるペースを生み出すための必須の手法でもあります。DevOpsチームは IaC を活用することで、ソースコードのバージョン管理を行うのと同じ感覚でインフラストラクチャを迅速に作成し、バージョンを管理し、バージョンを追跡することで、デプロイ時にIT環境間の不整合による深刻な問題を引き起こす可能性を回避することができます。その結果、IaC を活用することで、ソフトウェア・アプリケーションの開発、テスト、またはデプロイのたびに、サーバー、オペレーティング・システム、データベース接続、ストレージなどのインフラストラクチャを手動でプロビジョニングおよび管理する必要がなくなることから、（1）オートメーションによる構成の編集、共有、再利用の高速化（2）ITインフラストラクチャ管理の信頼性向上（3）意図しない設定変更や設定ミスによる構成の差異による構成ドリフトの防止（4）実験・テスト・最適化をサポートし新しいインフラストラクチャを迅速にスケールアップを実現し、クラウド・アプリケーションの開発・展開・拡張の迅速化とともに、リスクの軽減とコストの削減への効果が期待できます。クラウド環境でもっとも利用されている IaC ツール「Terraform」 IaC ツールは数多くありますが、AWSやGoogle Cloud 環境において、それぞれのクラウドベンダーが提供するネイティブな IaC ツールよりも多くの企業に採用されている IaC ツールが「Terraform」です。Terraformは、クラウドインフラのプロビジョニングで業界標準ツールとして、デファクトスタンダートの位置付けにあります。 Terraformは、クラウドネイティブな環境におけるインフラ運用の自動化を実現するソフトウェアです。宣言型のプロビジョニングおよびインフラストラクチャ・オーケストレーションにも対応しており、大規模なシステムやマルチクラウド環境において特に高い効果を発揮し、インフラ管理の効率化と安定化に大きく貢献します。また、インフラの設定をコードで記述し、それを基にインフラを構築・管理することで、手作業による人為的な設定ミスを減らし、環境の再現性を高めることができます。さらに、AWS、Azure、Google Cloud Platformなど、複数の主要なクラウド・プロバイダーに対応しており、プロビジョニング対象のリソースが豊富であることもTerraformの大きな特徴で、クラウドサービスの対応数は300以上に登ります。そのため、物理的なサーバーや DNSサーバー、複数のプロバイダーのリソースを同時に構築する自動化が可能です。さらに、様々な言語で書かれたアプリケーションを提供することができます。これにより、企業のクラウドベース、オンプレミスを問わず、すべてのインフラストラクチャの全側面のプロビジョニングを自動化し、クラウド環境やオンプレミス環境のインフラを効率的に管理します。また、クラウド環境で調達するサーバーの構成についても、「どのクラウドサービスで」「どのようなスペックを持つ仮想サーバーやリソースを使うか」といった指定をコードで記述することで、各クラウドのITリソースを調達し、需要に応じてリソースを割り当てるなど、効率的なシステムやサービスの運用を可能にします。 Terraformが選ばれる理由 Terraformが企業に選ばれる理由には、次のようなものが挙げられます。プラットフォームにとらわれない他のほとんどのIaCツールは、単一のクラウド・プロバイダーで動作するように設計されていますが、Terraformは、プラットフォームにとらわれず、任意のクラウド・サービス・プロバイダーで利用することが可能です。イミュータブル・インフラストラクチャ Terraformは、「イミュータブル・インフラストラクチャ」の思想に基づき設計されています。これは、一度構築したサーバーやコンテナなどのインフラに直接変更を加えず、変更が必要になった場合、新しいインフラを構築して入れ替える運用思想です。これにより、構成のずれ（環境差分）を防ぎ、システムの安定性を高め、セキュリティリスクを低減し、運用効率を向上させます。環境を変更するたびに、現在の構成は変更を考慮した新しい構成に置き換えられ、インフラストラクチャが再プロビジョニングされるため、以前の構成をバージョンとして保持したまま、意図しない設定変更や設定ミスによる構成の差異による構成ドリフトを防止し、必要あるいは要望に応じてロールバックを可能にします。マルチクラウドやハイブリッドクラウドの活用マルチクラウドやハイブリッドクラウドの活用 Terraformが提供するのは、複数クラウドを管理できる統一的なフレームワークです。そのため、マルチクラウド間でのリソース移行や追加が簡易なだけでなく、多種多様なクラウドへの対応を可能にして、クラウド・アプリケーションの開発・展開・拡張を迅速化します。クラウドネイティブアーキテクチャの採用とクラウドコストの最適化クラウドネイティブアーキテクチャを採用しているTerraformは、Kubernetesやサーバレスリソースのプロビジョニングに対応しています。そのため、柔軟なリソース展開とスケーリングを簡単に実現することが可能です。また、動的なリソースプロビジョニングと削除を自動化し、コスト分析ツールとのタグ統合でリソースコストを可視化することで、無駄なクラウドを精査してクラウドコストを最適化します。コンプライアンスとセキュリティ対応に基づくグローバルな運用・展開 Terraformは、変更履歴のトレーサビリティを確保し、ポリシー管理ツールでセキュリティ要件を自動化することで、一貫性のある構成変更と自動化のコンプライアンスとセキュリティ対応を可能にします。このコンプライアンスとセキュリティ対応を担保したままモジュール化されたコードで、グローバルに展開することも可能で、複数リージョンの管理を自動化し、迅速な障害復旧も実現して、より信頼性のあるITインフラストラクチャ管理が可能になります。 TerraformとAnsibleの連携で実現するエンドツーエンドのハイブリッド・クラウド・プラットフォーム IBMは、Terraformを開発した HashiCorp社を2025年2月に買収しました。この買収を通じてIBMは、ハイブリッドクラウドとマルチクラウド環境におけるエンドツーエンドの自動化機能の提供と、AI時代に対応するお客様の複雑なITシステムの管理を支援することを目指しています。その中でも特に、ハイブリッドクラウド環境におけるアプリケーションのプロビジョニングと構成の簡素化に大きく貢献するものとして期待されているのが、ITインフラのプロビジョニングとライフサイクル管理を自動化する「Terraform」と、オーケストレーションおよび構成管理を得意とする「Ansible」の組み合わせです。 IBMのHashiCorpの買収は、そのシナジー効果を見込んだものでもあります。 Ansibleは、IBM傘下のRedHatが開発するプロビジョニング、構成管理、およびアプリケーションのデプロイメントを自動化することを目的としたIaC ツールです。シンプルでエージェントレスなアーキテクチャを採用しており、IT運用の効率化やDevOpsの実践を支援することから、Docker コンテナや Kubernetes のデプロイメントのプロビジョニングを自動化するために多くの企業に選ばれています。ここで重要なのは、同じIaC ツールでありながら、TerraformとAnsibleでは得意な領域が違うことです。そして、両製品は競合させるのではなく、連携させることで効果が大きくなります。 Terraformが、特定のインフラベンダに依存せず、さまざまなクラウドインフラのプロビジョニング情報のIaC (による自動化を実現する)ツールであるに対して、Ansibleは、インフラ上のOSやミドルウェアの構成管理で業界標準の位置付けであり、豊富なミドルウェアの自動構成・設定機能で、ITインフラの構成管理やアプリケーションデプロイメントを自動化します。「インフラ層の構成管理」を得意とするTerraformと、「OS・ミドルウェア層の構成管理」を得意とするAnsibleは、それぞれ異なるプロビジョニングレイヤを担っており、対象となるリソースのライフサイクルも異なります。そのため、双方を効果的に使い分けることで、IaCの効果を最大化することができるのです。図版-1「インフラ層の構成管理」を得意とする Terraformと「OS・ミドルウェア層の構成管理」を得意とするAnsibleの最適な組み合わせまとめ NI+C Pは、IBM ソフトウェア(SW)とハードウェア(HW)の認定ディストリビューターとして、Terraform をはじめとするIBM のIaC製品において豊富な取扱い実績を有しています。 Terraform については、Ansibleとの連携だけでなく、「Cloudability 」や「Turbonomic」などのIBMの他製品との連携についても、お客様のニーズや要件に合わせて、IBM の SW と HW を組み合わせた最適な提案やカスタマイズの支援、 IBM 製品の特徴や利点をお客様にわかりやすく説明し、お客様・パートナー様のビジネスに最適な提案をサポートいたします。インフラ環境の複雑化とともに、さらなるニーズの高まりを見せているIaCの活用および Terraform の導入について、弊社の技術支援チームによるスキルイネーブルメント(座学勉強会や技術者認定試験の取得支援、ご提案サポート)、また、Terraform を絡めたIaC製品セールスのサポートへのご要望があれば、いつでもお気軽にお問い合わせ・ご相談ください。お問い合わせこの記事に関するお問い合せは以下のボタンよりお願いいたします。お問い合わせ .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:26px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }

コラム

2025年10月29日

水冷サーバーの違いとは？（レノボの水冷サーバー#2）

公開日：2025-10-29 こんにちは。ソリューション企画部柳澤です。前回レノボの水冷サーバーについてのブログを書かせていただき、いろいろなお客様にブログを読んでいただきました。前回の記事はこちら昨今、お客様ご自身の身の回りでもChatGPTの普及などでAIについて皆様も身近に感じてこられるようになってきたかと思います。今後はさらにAI、機械学習、HPCの台頭による計算能力の劇的な向上が見込まれます。それに伴う発熱量の増加で、従来の空冷システムの限界により水冷技術への注目度が高まっています。レノボの水冷と聞いて、レノボが今年初めて水冷サーバーを発表したのでは？と思うお客様もいらっしゃるかもしれません。しかし、レノボの水冷は2012年に発表された製品であり、その導入事例も世界に多数あります。弊社としましては、レノボの水冷サーバーについてラインナップの多さ、その歴史と導入事例の多さから、今後のAIやHPCの需要が高まる時代を取り巻く中で皆様にぜひご提案させていただきたく、今回もレノボの水冷サーバーにテーマを絞ってブログを掲載させていただきたいと思います。では早速ですが、前回お伝えできなかった部分もふくめて、下記にてさらにレノボの水冷サーバーについて、ご紹介させていただきます。目次レノボの水冷サーバーの歴史と導入事例 Lenovo Neptune®とはレノボの水冷サーバーと他メーカーの違いとはレノボの水冷サーバーの問題解決対策について関連情報お問い合わせレノボの水冷サーバーの歴史と導入事例前述のとおり、レノボの水冷サーバーは発表されてからすでに12年以上経っており、水冷サーバーについては業界をリードする存在です。導入事例も多数あり、下記の導入事例を含め、世界トップ10のパブリッククラウドプロバイダーで8社を支えるインフラとなっています。各国の研究機関や、企業でも導入が進んでおり、スーパーコンピューターから小規模な拠点まで採用されており、日本でも今後採用が進むことと思われますまた以前は空冷サーバーにくらべて10〜20％の追加コストが発生していましたが、これまでの空冷サーバーとの部品共通化でコストの違いはそこまで大きなものにならなくなってきています。 Lenovo Neptune®とは「Lenovo Neptune®」はLenovoが展開する水冷技術ブランドであり、以下の3つの技術カテゴリで構成されています。 Neptune® :システム全体の温水冷却により温水再利用を実現 Neptune® Core :コンポーネントレベル冷却（CPU、GPU、メモリ）により通気要件を削減 Neptune® Air :空冷ベースシステムでの液体補助冷却本稿で取り上げるのはこのうちの「Neptune®」の直接液体冷却構成となります。サーバー筐体からラック全体に至るまで、純水を用いた直接水冷（DWC）によって冷却を最適化。空冷ファンを排除し、最大40%の電力削減と100%の熱除去を実現します。AI・HPC用途に最適化された設計で、静音性・省スペース・環境対応の面でも優れています。導入事例から見るNeptune®の実力 DreamWorks AnimationNeptune®導入により、レンダリング性能20%向上、電力コスト削減を達成。MoonRayレンダラーやArrasクラウド計算システムの性能を最大限に引き出している。事例詳細韓国気象庁（KMA）8000台のNeptune®搭載サーバーで、気象予測の高速化と省エネを実現。SD650 V2およびSD530サーバーを活用し、精度の高い気象モデルを運用。事例詳細ハーバード大学同じスペースで従来の4倍の計算性能を実現。Neptune®による完全ファンレス運用で、研究成果の加速に貢献。事例詳細レノボの水冷サーバーと他メーカーの違いとは前回の記事でもふれましたが、水冷にはレノボや多くのIAサーバーメーカーが採用している直接液冷と、専用メーカーが採用している液浸冷却などいくつかの方式があります。直接液冷は発熱源に直接アプローチすることで効率的な冷却と省電力・静音性を実現します。液浸冷却はサーバー全体を冷却液に浸すことで非常に高い冷却能力と省エネ性能、高密度化を可能にしますが、設備投資が高額というデメリットもあります。では直接液冷のレノボのNeptuneと直接液体冷却方式を採用しているメーカーとの比較とレノボの優位性がある部分はどうなっているのでしょうか。主な違いは下図のようになっています。直接液体冷却方式のレノボと他メーカーとの違いレノボの水冷サーバーの問題解決対策について水冷サーバーというと液体を扱うサーバーゆえにこぼれたり、漏れたりするのではないか、とおっしゃるお客様もいらっしゃいます。そのための対策もレノボでは下の表のように対策されています。いやいや、でもAI×水冷サーバーといったってよくわからないし、というお客様にはレノボさんでAIディスカバリーワークショップもやっていただけます。ワークショップ→POC→アセスメント→本番環境導入という流れで実施となりますので、ご提案や、ご不明な点などございましたら、ぜひ弊社へお問い合わせいただければと思います。関連情報 Lenovo サーバー/ストレージ製品【参加レポート】Lenovo TechDay @ Interop Tokyo 2025 レノボのファンレス常温水冷サーバーって？第6世代のLenovo Neptune液体冷却が AI 時代を牽引（Lenovoサイト）【AI電力消費40％削減事例も】レノボの「直接水冷」Lenovo Neptune™（YouTube）お問い合わせエヌアイシー・パートナーズ株式会社E-mail：voice_partners@niandc.co.jp .bigger { font-size: larger; } .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .table { border-collapse: collapse; border-spacing: 0; width: 100%; } .td { padding: 10px; vertical-align: top; line-height: 1.5; } .tbody tr td:first-child { font-weight: bold; width: 20%; } .tbody tr td:last-child { width: 80%; } .ul { margin: 0 !important; padding: 0 0 0 20px !important; } .ol { margin: 0 !important; padding: 0 0 0 20px !important; } .tr { height: auto; } .table { margin: 0; } *, *:before, *:after { -webkit-box-sizing: inherit; box-sizing: inherit; } .html { -webkit-box-sizing: border-box; box-sizing: border-box; font-size: 62.5%; } .btn, a.btn, button.btn { font-size: 1.6rem; font-weight: 700; line-height: 1.5; position: relative; display: inline-block; padding: 1rem 4rem; cursor: pointer; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; -webkit-transition: all 0.3s; transition: all 0.3s; text-align: center; vertical-align: middle; text-decoration: none; letter-spacing: 0.1em; color: #212529; border-radius: 0.5rem; } a.btn--orange { color: #fff; background-color: #eb6100; border-bottom: 5px solid #b84c00; } a.btn--orange:hover { margin-top: 3px; color: #fff; background: #f56500; border-bottom: 2px solid #b84c00; } a.btn--shadow { -webkit-box-shadow: 0 3px 5px rgba(0, 0, 0, .3); box-shadow: 0 3px 5px rgba(0, 0, 0, .3); }

ブログ

2025年10月22日

今こそ着手すべきセキュリティ対策：サイバーレジリエンス法（CRA）とSBOMの関係

公開日：2025-10-22 目次はじめに：CRAとSBOMがもたらす変革 CRAが企業に課す義務とタイムライン SBOMの必要性・重要性：CRA対応を超えて CRAとSBOMの具体的な関係 SBOM生成・活用ツールのご紹介まとめ：SBOMはCRA準拠と持続的な品質維持の鍵お問い合わせはじめに：CRAとSBOMがもたらす変革「サイバーレジリエンス法（CRA）」は、EU市場で流通する「デジタル要素を持つ製品」（ハードウェア、ソフトウェア、IoTデバイスなど）のセキュリティ水準向上を目指し、EUが策定した新たな規制です。この法規制への対応において、中核的な役割を果たすのが「SBOM（Software Bill of Materials：ソフトウェア部品表）」です。 SBOMは、CRA対応に不可欠な構成要素であると同時に、本来ソフトウェアの脆弱性管理やセキュリティ維持を実現するための根本的な情報基盤です。CRAの有無にかかわらず、自社製品の安全性と品質管理の観点から、その導入は急務と言えます。本記事では、CRA対応に求められるSBOMの具体的な要件と、それが企業のセキュリティにもたらす本質的な貢献についてご説明いたします。 CRAが企業に課す義務とタイムライン CRAは、製品開発の設計段階（Secure by Design）からのセキュリティ考慮を徹底し、製品提供後の脆弱性管理までを一連の義務として企業に課します。主な要件は以下のとおりです。 Secure by Designの文書化：設計段階でセキュリティを考慮した証拠を文書として整備し、補完すること。脆弱性の特定と報告：製品に含まれる脆弱性を特定・文書化し、迅速に公開する義務。 SBOMの整備：製品構成を「一般的な形式で機械可読」な形で作成し、技術文書の一部とすること。特に日本企業が留意すべき適用スケジュールは以下の通りです。日付義務内容内容 2026年9月11日脆弱性およびインシデントの報告義務の適用開始悪用された脆弱性やセキュリティインシデントについて、EU内の当局へ24時間以内に報告することが求められます。 2027年12月11日 CRA全面施行、CEマーク非取得製品の販売禁止この日以降、CRAの全要件を満たしCEマークを取得しない製品は、EU市場での販売が原則として禁止されます。 SBOMの必要性・重要性：CRA対応を超えて SBOMは、ソフトウェアに含まれるすべてのコンポーネントや依存関係を網羅的に記録し、脆弱性発生時の迅速な影響範囲の特定と市場対応を可能にするリストです。 2021年12月のLog4j問題*1が示したように、SBOMの有無は企業の対応速度を決定づけます。SBOMが整備されていれば、脆弱性の影響範囲を素早く特定し、迅速な対応が可能となります。逆にSBOMがなければ、企業は重大な潜在的脆弱性を抱えた製品を市場に出し続け、ユーザーのセキュリティリスクを増大させることになります。このように、CRAの法的要求以前に、SBOMは製品構造を把握し、リスクを継続的に管理するための不可欠なツールです。 *1.脆弱性の重大度を示すCVSSスコアが10点中10点であった、極めて重大な脆弱性。 CRAとSBOMの具体的な関係 CRAは、SBOMを技術文書の一部として位置づけ、「製品の最上位レベルの依存関係を網羅し、一般的に使用される機械可読な形式で作成すること」を義務付けています（附属書I、Part II (1)）。脆弱性への迅速な対応の根幹 SBOMがなければ、製品に含まれるオープンソースの脆弱性情報を把握できず、CRAが求める迅速な脆弱性公開と対応（ユーザーやWebサイトでの情報提供）は実現困難です。CRAが求める「脆弱性を速やかに提出せよ」という要求に応えるための基盤情報こそがSBOMです。技術文書としての準拠証明 CRAでは、市場監査当局から要請があった場合、製品が要求事項に準拠していることを証明するための情報・文書の提供が義務付けられています。SBOMは、「Secure by Design」の設計思想と継続的な脆弱性管理が実施されていることの客観的な証拠として、極めて重要な役割を果たします。 SBOMは、ソフトウェアの構造把握による脆弱性管理という主目的とともに、CRA準拠を達成するための重要な鍵となります。 SBOM生成・活用ツールのご紹介 CRA準拠のためには、製品の提供形態や開発プロセスに応じ、適切なツールを利用してSBOMを効率的かつ正確に生成・管理する必要があります。ソースコードを所持している場合：SCA（ソフトウェア・コンポジション解析）オープンソース活用が不可欠なソフトウェア開発では、使用しているライブラリと、それに内在する脆弱性を把握するために、「SCA（Software Composition Analysis／ソフトウェア・コンポジション解析）」が必要です。ソリューション：HCL AppScan on Cloud の SCA 機能 HCL AppScan on Cloud の SCA 機能は、ソースコード内の依存関係ファイルを解析し、ソフトウェア内のOSSコンポーネントを検出、脆弱性を持つものを特定します。 OSS情報の検出と脆弱性特定：ソースコードからOSS情報を検出し、脆弱性を持つコンポーネントを特定します。業界標準フォーマット対応：SBOM出力の業界標準の一つであるSPDX 2.3フォーマットに対応。これはCRAが要求する「一般的に使用され、機械可読な形式」でのSBOM作成に貢献します。バイナリデータからSBOMを生成する場合組み込みソフトウェアやファームウェア、あるいはサプライヤーから受け取ったソースコードがない（またはアクセスできない）バイナリデータのセキュリティを検証したい場合に有効なのが、バイナリ解析ツールです。ソリューション：SBOMスキャナサイエンスパーク社の「SBOMスキャナ」は、以下のユニークな特色を持ちます。バイナリデータからのSBOM生成： PCアプリケーションやWebサイトだけでなく、監視カメラ、ネットワーク機器、IoTデバイスなどの組み込みソフトウェアのバイナリデータからも、簡単にSBOMを生成します。脆弱性レポートの生成：生成したSBOM情報（OSSのベンダー、プロダクト、バージョン）とCVE（Common Vulnerabilities and Exposures：脆弱性に付与される識別番号）を突き合わせ、脆弱性レポートを迅速に生成します。オフライン対応：オフライン環境での利用が可能であり、機密性の高い環境でも安心して利用できます。まとめ：SBOMはCRA準拠と持続的な品質維持の鍵 CRAの適用期限が目前に迫る今、SBOMによる効率的な脆弱性管理が、CRA準拠を成功させる鍵です。 SBOMは単なる法対応のための手段ではなく、企業が持続的にソフトウェアの品質を維持し、安全な製品を市場に提供するための基本情報基盤です。法施行に向けたタイムラインを強く意識し、本記事で紹介したような適切なツールを活用して、迅速にSBOMの整備に着手することが、企業の競争力維持に不可欠です。ご紹介したソリューション【HCL AppScan on Cloud】 HCL AppScan（エヌアイシー・パートナーズ株式会社サイト (AppScan 全般）） HCL AppScan on Cloud（HCLSoftware サイト（開発元）） ※HCL AppScan on Cloud の SCA 機能は、HCL AppScan on Cloudのオプションです。【SBOMスキャナ】 SBOMスキャナ（エヌアイシー・パートナーズ株式会社サイト） SBOMスキャナ（株式会社サイエンスパークサイト（開発元））お問い合わせ上記製品についてのお問い合わせ、ご説明のご依頼、お見積り依頼など、エヌアイシー・パートナーズまでご相談ください。エヌアイシー・パートナーズ株式会社技術企画本部E-mail：voice_partners@niandc.co.jp .bigger { font-size: larger; } .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .table { border-collapse: collapse; border-spacing: 0; width: 100%; } .td { padding: 10px; vertical-align: top; line-height: 1.5; } .tbody tr td:first-child { font-weight: bold; width: 20%; } .tbody tr td:last-child { width: 80%; } .ul { margin: 0 !important; padding: 0 0 0 20px !important; } .ol { margin: 0 !important; padding: 0 0 0 20px !important; } .tr { height: auto; } .table { margin: 0; } *, *:before, *:after { -webkit-box-sizing: inherit; box-sizing: inherit; } .html { -webkit-box-sizing: border-box; box-sizing: border-box; font-size: 62.5%; } .btn, a.btn, button.btn { font-size: 1.6rem; font-weight: 700; line-height: 1.5; position: relative; display: inline-block; padding: 1rem 4rem; cursor: pointer; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; -webkit-transition: all 0.3s; transition: all 0.3s; text-align: center; vertical-align: middle; text-decoration: none; letter-spacing: 0.1em; color: #212529; border-radius: 0.5rem; } a.btn--orange { color: #fff; background-color: #eb6100; border-bottom: 5px solid #b84c00; } a.btn--orange:hover { margin-top: 3px; color: #fff; background: #f56500; border-bottom: 2px solid #b84c00; } a.btn--shadow { -webkit-box-shadow: 0 3px 5px rgba(0, 0, 0, .3); box-shadow: 0 3px 5px rgba(0, 0, 0, .3); }

ブログ

2025年10月10日

現地からお届け！【参加レポート】IBM TechXchange 2025 Orlando

公開日：2025-10-10 こんにちは。現在エヌアイシー・パートナーズ技術企画本部のメンバーで、アメリカのオーランドで開催されている「IBM TechXchange 2025」に参加しています。（現地時間：2025年10月9日、日本時間：2025年10月10日時点）本記事では現地からの速報として、このイベントの概要や見どころ、最新情報をお伝えいたします。目次イベント概要 IBM Techxchange 2025 主要メッセージ - 1. Anthropicとのパートナーシップ発表 - 2. コード開発AI Agent「Project Bob」 - 3. AI基盤のための「Project Infragraph」 AI Accelerator “Spyre” Observability さいごにお問い合わせイベント概要 IBM TechXchange は世界各国のIBMファンが集う年に1度の技術者向けイベントで、今年は3回目となりました。年々規模も参加者も拡大しており、IBM TechXchange 2025 では、1,800以上の技術者向けセッションがあり、その中で400以上のハンズオンラボやデモが展開されています。今年はアメリカのフロリダ州にあるオーランドの Orange Country Convention Center にて10月6日から10月9日の4日間で開催中で、日本から100名近くの方々が参加しています。今年のテーマは「we are GO / Explore Build Launch 」です。 IBM Techxchange 2025 主要メッセージ TechXchange 2025の基調講演では、AIエージェントを活用・展開するために必要となる4つの要素を紹介していました。この4つの要素のうちEcosystem・Developer Tools・AI infrastructure managementについてお伝えします。 Ecosystem IBMが単独でAIエージェントを開発・展開するのではなくパートナーシップやIBMパートナーがAIエージェントを開発・運用することでOpenな展開をしていくという方針となります。この方針を実現するためにAgent Connectプログラムを展開しており、多数のAIエージェントを早期に提供することを目指しています。 Developer Tools Developer Toolsとしてドメインエージェントの提供があります。ドメインエージェントとは、業務特化型のエージェントを指します。例えば購買業務に特化したエージェントであったり、人事業務に特化したエージェントです。 AI infrastructure management AIを利用する上で必要となる基盤の管理を指します。これを実現するためにProject “Infragraph” というプロジェクトでソリューション提供を目指しています。他にも、TechXchangeでは様々な新しい発表がありました。その発表の中から今後大注目となる3点について共有します。 1. Anthropicとのパートナーシップ発表既に日本でもニュースとなっているので認識されている方も多いと思いますが、Anthropicとのパートナーシップの発表がありました。 IBMはAIのガバナンス、セキュリティ、オブザーバビリティ分野でソリューションを提供しており、これがIBMの強みとなっています。Anthropicとの協業は、この強みを背景とした補完的なパートナーシップであると思われます。このパートナーシップの目的は、LLMであるClaudeをIBMソリューションに組み込むことだけではありません。企業ユースでAIエージェントを開発・運用する時に検討が必要となる要素を体系化した「Architecting secure enterprise AI agents with MCP」をIBMが作成し、Anthropicがそれを検証する協業も行っています。このガイドを参照してAIエージェントを開発することで、今後拡大が見込まれるAIエージェントを安全かつ安心して活用できるベースとすることができます。 2. コード開発AI Agent「Project Bob」統合開発環境(IDE)をエージェント型で提供する「Project Bob」が発表されました。このニュースと共にかわいらしいマスコットのBobもお披露目になりました。 Project Bobを利用することで、コードをバージョンアップするための設計、テストの自動化、本番運用、コンプライアンス維持と開発のライフサイクル全体をAIエージェントを用いて自動化することができます。 Project Bobは、発表と共にPublicプレビュー段階に入りました。開発者のワークフロー負荷を軽減してくれるProject Bob の提供開始が楽しみですね！ 3. AI基盤のための「Project Infragraph」 HashiCorpが主体となって開発している基盤自動化のためのプロジェクトです。詳細は不明ですが、以下の実現を目指しています。サイロを横断した統合インサイトクラウドインフラストラクチャーリソースを単一のビューで把握できます。実用的なインテリジェンスコストの最適化、ガバナンスの強化、リスクの軽減に役立つコンテキストを提供します。自動化の基盤インフラストラクチャークラウド全体にわたる、次世代のインテリジェントなAI駆動型運用を実現します。 AI Accelerator “Spyre” IBM Spyre Accelerator はエンタープライズワークフロー向けのAIソリューションを提供し、AIサービスを簡単にインストール・構成・移動できる統合された推論プラットフォームとアクセラレートされたインフラストラクチャーを備えています。 Spyreのユースケースとしては、IT運用、開発、ERP、銀行・金融、ヘルスケア、保険、公共分野など、様々な業界でデジタルアシスタント、データ・コンテンツ管理、ディーププロセス統合などのプリビルドAIサービスを提供します。 Observability AI Firstとして各種機能提供、Intelligent、Integrated experienceとしてUIやDataレイヤーの統合がされるという情報が共有されました。またAIキーワードとしてはLLMやAIのワークロードをInstanaでObservabilityする機能が2025 4Qのロードマップとして示されました。さいごに 2日目の夜のお楽しみとして「Evening Entertainment at Universal Orlando Resorts Islands of Adventure」が開催されました。世界各国から集まった技術者とともに過ごした Universal Orlando Resorts Islands of Adventure での一夜は格別な体験となりました。さて、本日、来年のTechXchangeがアメリカジョージア州の「アトランタ」で開催されることが正式に発表されました。次回のイベントにも期待が高まります！お問い合わせエヌアイシー・パートナーズ株式会社技術企画本部 E-mail：voice_partners@niandc.co.jp .bigger { font-size: larger; } .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .table { border-collapse: collapse; border-spacing: 0; width: 100%; } .td { padding: 10px; vertical-align: top; line-height: 1.5; } .tbody tr td:first-child { font-weight: bold; width: 20%; } .tbody tr td:last-child { width: 80%; } .ul { margin: 0 !important; padding: 0 0 0 20px !important; } .ol { margin: 0 !important; padding: 0 0 0 20px !important; } .tr { height: auto; } .table { margin: 0; } *, *:before, *:after { -webkit-box-sizing: inherit; box-sizing: inherit; } .html { -webkit-box-sizing: border-box; box-sizing: border-box; font-size: 62.5%; } .btn, a.btn, button.btn { font-size: 1.6rem; font-weight: 700; line-height: 1.5; position: relative; display: inline-block; padding: 1rem 4rem; cursor: pointer; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; -webkit-transition: all 0.3s; transition: all 0.3s; text-align: center; vertical-align: middle; text-decoration: none; letter-spacing: 0.1em; color: #212529; border-radius: 0.5rem; } a.btn--orange { color: #fff; background-color: #eb6100; border-bottom: 5px solid #b84c00; } a.btn--orange:hover { margin-top: 3px; color: #fff; background: #f56500; border-bottom: 2px solid #b84c00; } a.btn--shadow { -webkit-box-shadow: 0 3px 5px rgba(0, 0, 0, .3); box-shadow: 0 3px 5px rgba(0, 0, 0, .3); }

ブログ