MERIT ひろば
一覧に戻る
シェア

シェア

2023年03月

07

【てくさぽBLOG】IBM Power Virtual ServerのAIX環境とIBM Cloud Object Storageを接続してみた（Part1）

ブログ

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

2021年に IBM Power Virtual Server（以下 PowerVS）のプロビジョニング、バックアップ、x86環境との接続をトライしたやってみたBLOG「IBM Power Virtual Server でAIX環境を作ってみた」を公開しました。
今回は PowerVS から IBM COS へバックアップ取得を想定し、AIX環境から Proxyサーバ経由で IBM COS へファイル転送を行う手順をご紹介します。

IBM COS については以前のブログ「【早わかり】IBM Cloud Object Storageを見積してみよう」でご紹介しているのでご覧ください。

それでは早速構築手順をご紹介いたします。

1）接続イメージのご説明

図の赤い線が今回検証したプライベートネットワーク経由の PowerVS から IBM COS の接続です。青い線はパブリックネットワーク経由で端末から各サービスに接続する経路になります。

接続イメージ

まず PowerVS と IBM Cloud（x86環境）接続ですが、両者はネットワークが独立に管理されているため直接通信はできません。そのため、Direct Link Connect を作成して接続します。

次に IBM COS と PowerVS の接続ですが、パブリックネットワーク経由で IBM COS のパブリックエンドポイントへアクセス可能ですが、プライベートネットワーク経由から IBM COS のプライベートエンドポイントへは直接アクセスすることは出来ません（2023年2月現在）。
プライベートネットワークから接続する場合は IBM Cloud の x86環境を経由して IBM COS に接続する必要があります。

今回は IBM Cloud の x86環境に Proxyサーバを立て Proxyサーバ経由で接続する方法を試してみたいと思います。
なお、構築手順は Qiita の BLOG「Power Virtual ServerからICOSにファイルをアップロードする」を参考にさせて頂きました。

2）IBM Power Virtual Serverの作成

・PowerVSの作成はこちらのBLOG「IBM Power Virtual Server でAIX環境を作ってみた」でご紹介しましたが、プロビジョニング画面がアップデートされました。
IBM Cloud にログインし、カタログから「Workspace for Power Virtual Server」をクリックします。

Workspace for Power Virtual Server

・ワークスペースを作成します。
ワークスペースは、PowerVSのデプロイする場所をゾーン毎に作成できる無償の作業環境です。任意のワークスペース名を入力し、リージョンは “東京04” を選択して作成します。

ワークスペースを作成

・PowerVS を作成した後にプライベートネットワークを作成するとうまくネットワークが認識されなかったので、先にプライベートネットワークを作成します。
左側メニューから「サブネット」をクリックします。プライベートネットワーク用に192.168.1.0/24のサブネットを作成します。

プライベートネットワークを作成

・次に「仮想サーバ・インスタンス」を選択しインスタンスを作成します。

インスタンスを作成

・今回は以下の構成でインスタンスを作成します。

  • インスタンス名：任意の名前
  • CPU:0.25
  • CPUタイプ:上限なし共有プロセッサー
  • メモリ：4GB
  • ストレージボリューム：Tier3（SSD）30GB
  • OS：AIX7.3 TL1
  • プライベートネットワーク:192.168.1.0/24

右側の月額費用を確認し「作成」をクリックします。

月額費用

・仮想サーバインスタンスの画面に戻り、しばらくするとプロビジョニングが完了しました。
ここまでは特に問題無く進みほっとします。

仮想サーバインスタンスの画面

3）VSI for VPCの作成

・次にProxy Serverを作成します。今回はVSI for VPCにProxy Serverをたてます。

「ナビゲーションメニュー」から「VPCインフラストラクチャー」を選択します。
左のメニューから「VPC」を選択し、「作成」をクリックします。

VPCインフラストラクチャー

VPC は以下のパラメータで作成しました。

  • 地域：アジア太平洋
  • リージョン：東京
  • 名前：任意の名前
  • リソースグループ：Default
  • ssh許可
  • ping許可

VPCパラメータ

・サブネットの追加をクリックしてサブネットを追加します。
以下のパラメータで作成しました。

  • 名前：sn-20230214-01（デフォルト値）
  • ゾーン：東京1（東京1-3を選択可）
  • リソースグループ：Default
  • アドレス接頭部:10.244.0.0/18
  • アドレスの数:256
  • IP範囲：10.244.0.0/24
  • パブリックゲートウェイ：接続無し

サブネットを追加

・最後に「仮想プライベート・クラウドの作成」をクリックします。
VPCのプロビジョニングが完了しました。

VPCのプロビジョニングが完了

・次に作成した VPC に VSI を作成します。
左側のメニューから「仮想サーバ・インスタンス」を選択し「作成」をクリックします。

VPC に VSI を作成

VSI は以下のパラメーターで作成しました。

  • インスタンス名：任意の名前
  • アーキテクチャー：Intel x86アーキテクチャー
  • ホスティングタイプ：パブリック（マルチテナント）
  • 地域：アジア太平洋
  • リージョン：東京
  • ゾーン：東京2
  • 名前：proxy-test（任意の名前）
  • リソースグループ：Default
  • オペレーティングシステム：RedHatEnterprise Linux
  • バージョン：ibm-redhat-9-0-minimal-amd64-1
  • プロファイル：2vCPU, メモリ4GB
  • 配置グループ：デフォルト値
  • ブート・ボリューム：デフォルト値
  • データ・ボリューム：デフォルト値
  • ネットワーキング：tok-vpc-01（先ほど作成したVPCを選択）
  • アドレス接頭部：10.244.64.0/18
  • IP範囲：10.244.64.0/24

・パラメーターを入力したら右側画面の金額を確認し「仮想サーバの作成」をクリックします。

金額を確認

プロビジョニングが完了しました。PowerVS よりもプロビジョニングは速かったです。

プロビジョニングが完了

・作成したVSI（RHEL）に Tera term を使用し SSH でログインします。

作成したVSI（RHEL）に Tera term を使用し SSH でログイン

ログインしようと試みましたが、rootユーザのデフォルトパスワードでログインが出来ません。
調べたところレスキューモードで初期パスワードの再設定が必要であることがわかりました！
今更ですが、私は現場から離れかれこれ10数年、Linux のレスキューモードは初めてです。いきなりハードルが高くなりました…

そしていざレスキューモード！と思い、VNCコンソール画面を開こうと思ったら…今度は VNCコンソールがグレーアウトされ開けません。
今回検証で使用するユーザは所有者ユーザではないため、こちら（IBMサイト）の説明にある通りVNC/シリアルコンソールの使用には権限の付与が必要であることがわかりました。更に回り道です。お付き合いください😢

・IBM Cloudサービスへのアクセス権限はアクセス管理システム “IBM Cloud Identity and Access Management（以下 IAM）” で設定することができます。
IBM Cloud画面の「管理」⇒「アクセス（IAM）」⇒「ユーザー」をクリックします。

IBM Cloud画面

・「アクセス権限の割り当て+」をクリックします。

アクセス権限の割り当て+

・「ポリシーの作成」でサービスから「VPC Infrastructure Services」を選択します。

VPC Infrastructure Services

・「リソース」は「すべて」、「役割とアクション」はサービス・アクセスで「Console Administrator」、「プラットフォーム・アクセス」は「Operator」以上を選択し、最後に追加をクリックして完了です。

「リソース」「役割とアクション」「プラットフォーム・アクセス」

・VNCコンソールが開けるようになりました！

VNCコンソール

・やっとレスキューモードの準備が整いました。
レスキューモードは RHEL の Customer Portal「23.3. 起動時のrootパスワードのリセット」の手順を参考に行いました。ここでは手順は記載しませんが、Customer Portal の手順で問題なくパスワード設定ができます。システム再起動からすばやく [e]キーを押して起動プロセスを中断しなければいけないので目を凝らして行いました！
（ご参考に下の画面は起動プロセス中断直後の画面です。）

起動プロセス中断直後

・VNCコンソールから rootログインをしてみたところ、無事ログインできました！
今回の検証では検証用のユーザを作成してsuして作業したいと思います。

ログイン完了

・Teraterm から検証用ユーザで SSHログインし、root にスイッチします。
無事ログインできました。

Teraterm から検証用ユーザで SSHログイン

4）Direct Link Connectの作成

前述した通り、PowerVS と VPC を接続するため Direct Link Connect を作成します。

・作成した PowerVS のワークスペース（PowerVS_Tokyo_01）に入り、左側メニューの「クラウド接続」をクリック、「作成」をクリックします。

Direct Link Connect を作成

以下のパラメーターで作成しました。

  • 名前：任意の名前
  • 速度：1Gbps（50Mbpsから選択可）
  • グローバルルーティング:選択無し
  • Enable IBM Cloud Transit Gateway：選択無し（Transit Gatewayを使用する場合はチェックします）
  • 宛先の構成：VPC
  • VPC名：tok-vpc-01（作成済みのVPC）
  • サブネット：PowerVSで作成したプライベートサブネット

・作成をクリックします。
しばらくすると Direct Link Connect の状況が “確立済み” になりました。以前は Case起票をしてプロビジョニングを行う必要がありましたが、ユーザーの操作からできるようになり使いやすくなりましたね。

Direct Link Connect の状況

5）AIXで静的ルーティングの設定

・PowerVS から VPC への静的ルートを設定します。
AIX なので smit を使用します。

PowerVS から VPC への静的ルートを設定1

PowerVS から VPC への静的ルートを設定2

・netstatコマンドで静的ルーティングが設定されたことを確認します。

netstatコマンド

・pingコマンドで疎通を確認します。

pingコマンド

これで PowerVS から VSI に接続ができるようになりました。
PowerVS、VSI のプロビジョニングはスムーズでしたが慣れない RHEL の操作と IAM の仕組みの理解に時間がかかりました。IAM の仕組みについては今後整理してご紹介したいと思います。

6）IBM COSの設定

・IBM COS にバケットを作成します。
今回は以前作成した Liteプランのストレージインスタンスにバケットを追加します。
以下のパラメータで作成しました。

  • バケット名：任意の名前
  • 回復力：Regional
  • ストレージクラス：Smart Tier

IBM COS にバケットを作成

・バケットが作成されました。
こちらのバケットにファイルを転送します。（バケット自体に課金は発生しません）

バケットが作成

これでサービスのプロビジョニングができました。
あらかじめ準備していた手順通りには進みませんでした…が全体の半分まで完了です！！

さいごに

IBM Cloud も初めて、慣れない Linux の構築、VNCコンソールが開けないトラブルなど…多々問題にあたり苦戦しましたがなんとか全体の半分まで完了しました。
10数年ぶりの構築作業でしたがデリバリSEの感覚が残っていてよかったです。

次回は AIX の設定、RHEL の Proxy の設定、ファイル転送試験です。
実際作業してみてわかった点をご紹介予定ですので是非ご覧ください。

お問い合わせ

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

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

 

このページを見ている人におすすめのページ

  1. 【てくさぽBLOG】IBM watsonx Orchestrateを使ってみた（Part2）
  2. 【てくさぽBLOG】VMwareユーザー必見！IBM CloudのVCFaaSで、コストを抑えたままVMwareを継続利用
  3. 【参加レポート】「Think 2025」に参加した ～AIとハイブリッドクラウドで描く未来のビジネス変革～
シェア

シェア

その他の記事

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); }

ブログ

Copyright © NIandC PARTNERS Inc

back to top