特集・ブログ
日本アイ・ビー・エム株式会社 代表取締役社長執行役員 山口 明夫 氏 こんにちは。ソリューション推進部の村上です。 2023年10月31日と11月1日の2日間、久しぶりにオンサイト（ベルサール東京日本橋）で IBM の Bigなテクノロジーイベント「IBM TechXchange Conference Japan」が開催されました。セッション数は100を超え、IBM製品のテクノロジーに関する最新情報がふんだんに盛り込まれていました。 見所としては、デモの数々が挙げられます。参加者は最新の IBMテクノロジーを直接目の当たりにし、その操作感や性能をチェックすることができました。またハンズオンの場も提供され、テクノロジーに触れながら学べる環境も整っていました。 TechXchange はただ情報を吸収する場というだけではなくコミュニティ形成も大切にされていることから、IBM技術者との交流の場も用意されており、気鋭の技術者から新たな知識や視点を得ることができる貴重な機会となりました。 今回エヌアイシー・パートナーズからは10名程度の社員が本イベントに参加しました。以下に、参加者から寄せられたコメントをブランド別にピックアップしご紹介いたします。ぜひご覧ください。 目次 ブランド・カテゴリ別レポート Business Automation Data Management & watsonx.data Power AIOps Apptio Storage Cloud Mainframe Security まとめ お問い合わせ ブランド・カテゴリ別レポート Business Automation 「第一生命におけるIBM BAWとODMの導入上の設計課題と対策」セッションに参加しました。第一生命様の情報システム子会社である第一生命情報システムの方が登壇されていました。 保険業務について全く詳しくないのですが、保険の種類の多さやその支払い条件に関わるルールが15,000以上もあるということにまず驚きました。 重要な処理はメインフレームを使っているので、ODM のシステム構成としてもパフォーマンスと運用性を考慮して選択したということが説明されていました。確かにメインフレームの中だけで完結する処理のルールエンジンを外部で実行したらパフォーマンスに影響することは容易に想像できます。それを実験しながらパフォーマンスを担保できるような構成にした、ということが勉強になりました。 また、ルールエンジンである ODM の導入期間が1年程度だったのに対し、ワークフローエンジンである BAW の導入期間が3年にも及んだと説明されていました。 効果として、いずれも開発期間や情報が届くまでの期間の短縮が挙げられています。新しい施策を素早く実施するためには現場で使えるようになるまでの期間を短縮することが必要なので、ユーザー視点でもメリットがある導入だったと理解を深めることができました。 Data Management & watsonx.data IBM Watson の最新情報に関するセッションに参加しました。 その中で印象に残ったのは、watsonx Assistant と Watson Discovery を組み合わせたコールセンターシステムの導入事例でした。 紹介されていた事例では、コールセンターの業務負担の増加や新人研修の増加に対応するため、2020年1月から watsonx Assistant と Watson Discovery を組み込んだ AIシステムの運用を開始したそうです。その結果、オペレーターの対応時間が短縮し管理者の業務負担が軽減され、さらに品質も向上したとのことで、AI の導入効果を強く実感できました。 特に印象的だったのは、ユーザーとオペレーターの会話をリアルタイムにテキスト化し警戒すべきワードを抽出する機能や、自動生成する評価シートで管理職の負担を軽減している点です。通話テキストを抽出し翌営業日にフィードバックを得ることで業務改善を図っているところも、現場レベルでの AI活用の秀逸な事例だと感じました。 今後は生成AI の導入を検討しているとのことで、watsonx.ai と組み合わせたシステムのさらなる可能性を感じることができました。 Power 「オンプレ環境でas a Serviceを実現するには」セッションに参加しました。 IBM Powerシステムはオンプレミス環境に「as a Service」を提供することで、使った分だけのコストでクラウドの利便性を享受しセキュリティを強化させることを可能にしています。これはオンデマンド容量の提供により予測不可能なビジネス環境下でも迅速な対応を可能にし、コスト削減と効率的なリソース管理を実現します。また、デモシミュレーションを通じて投資効果を具体的に示し、ハイブリッドクラウドのトレンドに対応します。 新しいコンセプト「Power Private Cloud with Shared Utility Capacity」は、プライベートクラウド内で使った分だけ支払うというクラウドのメリットを実現。これにより、企業は必要な時に必要なリソースを使用し、余剰コストを削減できます。さらに、簡易見積ツールやアセスメントサービスを提供し、運用の最適化をサポートします。 このように、Powerシステムはまだパブリッククラウドには抵抗があるユーザーにもオンプレでクラウドを疑似体験しやすい環境であることを、改めて実感できました。 AIOps 「Turbonomic×クラウドコスト最適化事例紹介 FinOpsの実践に向けて」セッションに参加しました。 登壇者の山崎さんは別のセミナーでは Instana についてのお話をされていましたが、今回は Turbonomic という ARM（Application Resource Management）製品を FinOps の観点でお話されていました。”FinOps” というまだ馴染みのない単語を事例を交えながら話をしてくれたので、どのようなことを指しているのかが非常にイメージしやすかったです。 セッションの中でもあった「「無駄」なのか「備え」なのか、それが問題だ」という言葉がインフラコストの最適化を難しくしていることを端的に表現しており、私としても判断が難しいところだなぁと考えさせられました。 「最適化」をいざ始めようとしても「どこから着手してよいのか？」が分からず、手探りで闇雲に実施することになります。それを Turbonomic を使って可視化するところから始め、最適化についてもこのツールの支援をもらいながら人間が判断して実施していくことでより無駄を省くことができる、ということが理解できたよいセッションでした。 Apptio Apptio 田中さんと IBM 上野さんが登壇された「Apptio社との統合戦略と製品のご紹介」セッションの参加レポです。 Apptio Inc. は、2023年8月に IBM に戦略的買収がなされた IT投資の最適化ソリューションのリーダー的企業です。11月1日から正式に IBM に加わることになったそうです。 本セッションの前半では TBM（Technology Business Management）の詳しい解説があり、企業が IT支出を管理・最適化し自動化を推進することの必要性を実感することができました。TBM は奥が深い方法論ですが、じっくり読み込むととても面白いです。後半は、ApptioOne が TBM の実現にどのように役立つ製品なのかの解説がありました。ビジネスの中で IT の重要性は増すばかりで、企業は IT の具体的な財務価値や業務改革を実現することに注力してくるはずです。 このセッションを通じて、IBM が Apptio を戦略的に組織に加えることで、企業の IT運用の最適化と業務改革実現に向けた強力な支援体制を築き上げていることが伺えました。 Storage セッション「DXを支えるAI＆データ活用に必要不可欠なインフラ基盤とは？」に参加しました。 AI とデータ活用が日常業務に取り入れられるようになり非構造化データも増えていますが、その管理・活用が企業の大きな課題となっています。ただデータが増えていくだけではなくあらゆるところに散在しているため、必要なときにすぐに利用できる状態にすることが求められています。 その解決の鍵を握るのが、データ中心の考え方と、一貫した統一されたデータ・サービス基盤の構築です。なぜこの考え方が重要なのかというと、あらゆる拠点で大量のデータがリアルタイムに発生し、それを高速に柔軟に活用できるインフラが求められるからです。 非構造化データを一元管理する次世代データ基盤が「IBM Global Data Platform（GDP）ソリューション」です。AI、分析、バックアップなど、あらゆるワークロードに柔軟に対応可能です。その中で鍵となるのが「IBM Storage Scale」と「IBM Storage Discover」です。データ配置を最適化し、スモール・スタートでも容易にデータを扱うことができます。 事例としては、車載センサーデータや動画データを一元管理し自動運転体験を実現している企業の例や、ヘルスケア分野で複雑な課題解決に役立てられている病院の例が紹介されました。 このセッションに参加して感じたのは、AI やデータ活用だけでなく、それらを支えるインフラ基盤の重要性です。デジタル時代に向けて進む我々にとって、これからのデータ活用とそのインフラの重要性を再認識できたセッションでした。 Cloud IBM Cloud では「生成系AIの基盤を支えるCloud Native Super Computer「Vela」の実態」のセッションが印象的でした。 「Vela」は、AI に最適化されたクラウドネイティブのスーパーコンピューターとして IBM が開発し、最新の GPU と Openshift AI が構成要素となります。話題の製品「watsonx」もこの Vela を活用して開発されているそうです。画像認識AI の Maximo Visual Inspection が IBM Cloud上の GPU で稼働できることは知っていましたが、AI のモデル開発にも利用できることを興味深く思いました。 AIモデルの開発には巨大な計算能力を持つ最新の GPU が必要不可欠ですが、一方で GPU は消費電力を膨大に使用してしまいます。IBM Cloud上で稼働する Vela は GPU を利用しつつも、IBM Cloud が掲げている通り環境への負荷を軽減できているそうです。 本セッションを通して、クラウドネイティブなスーパーコンピューティングの時代が確実に到来していることを実感しました。引き続き Vela の動きに注目していきたいと思います。 Mainframe 「メインフレーム技術者が元気になる！テクノロジー・アーキテクチャーとは何か」の参加レポートになります。 このセッションは、メインフレームの特長とそのアーキテクチャーについての理解を深めることを目的としています。 メインフレームの特長として、堅牢性、高スループット、高セキュリティ、オープン技術の取り込み、地球環境に優しい省エネと仮想化技術が挙げられています。また、新たな特長として API対応とデータ連携ハブが追加されており、トランザクション処理やデータベース処理などのニーズに応える能力があります。 特に強調されているのは、2023年5月から z16全モデルに適用された「zIIP入れ放題」で、汎用CP（GCP）と zIIP の個数制限1:2を撤廃し、Java、Python、RESTful APIアクセス、DRDA など、様々なワークロードを汎用CP からオフロードすることが可能で、zIIP分のソフトウェア料金はかかりません。これによりメインフレームを利用するコストを大幅に削減し、メインフレームの利活用を進めることができます。 全体を通して、メインフレームはこれからも多くのトランザクションを取り込もうという意志を感じました。 Security 多くのセキュリティ製品がセミナーで紹介されていました。 QRadar では、まず SOAR が紹介されました。SIEM に集まる場合、そのパフォーマンスとキャパシティに影響があるため、一台の SIEM に集約せずとも各センサーから SOAR に集約して処理するという考え方です。インテリジェントになっている EDR などは、確かに SOAR で処理させるのは良いと思います。 QRadar ではさらに UAS（Unified Analyst Experience）についても紹介されました。各拠点に散らばった SIEM を横串で見る場合や SIEM のリアルタイム検知が不要な場合、複数の SIEM やログサーバを横串で見る場合には、UAX でも可能という方式です。 Trusteer では、サイバーアタックにおける三大侵入経路「脆弱点」「ウィルス」「なりすましログイン（不正ログイン）」と、その対策について紹介されていました。「システムへ直接攻撃」「システムに関与する社員への間接攻撃」「サービス利用者になりすます」という課題があり、「サービス利用者になりすます」を防げるのが Trusteer だというわかりやすい説明がありました。外部サービスを公開されている企業様には有効なソリューションだと思います。 IBM では、x-forceサービスをはじめ多くの知見を元に IBM Security製品が提供されていますので、ぜひご利用ください。 まとめ 以上のように、今回の TechXchange はテクノロジーコミュニティとの交流の場として、また、最新の IBM製品やテクノロジーについての学習の場として、大いに活用することができました。 次回の開催が待ち遠しいですね。 ※本ブログは参加者の主観や体験内容が中心であり、記載されている情報は正確性に欠ける場合があります。記載したブランドの紹介をご希望の方は、以下の問い合わせ先までご連絡ください。 お問い合わせ エヌアイシー・パートナーズ株式会社技術支援本部E-Mail：nicp_support@NIandC.co.jp .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; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの宮里です。 既に Windows Server 2012/R2 は End Of Support（以下 EOS）となっていますが、その後もそのまま使い続ける方も多いと思います。EOS のまま使い続けた場合にはセキュリティ面・障害対応の観点でリスクがあるので、何らかの対策が必要です。 Windows Server 2012/R2 を使い続けられる方は、ぜひ本ブログを参考にしてリスク軽減のためのセキュリティ対策をご検討ください。 目次 Windows Server 2012 / R2のEOSの概要 EOS後のリスク 対応方法 まとめ 関連情報 お問い合わせ Windows Server 2012 / R2のEOS概要 EOS（End Of Support）とは、ソフトウェアやハードウェアのメーカーがその製品のサポートを終了することを意味します。 Windows Server 2012/R2 のサポートが終了した場合、具体的にどのようなサポートが得られなくなるのかご存知でしょうか。 まず Microsoft のサポート内容からご説明いたします。 Microsoftのサポート内容 Microsoft のサポートは、メインストリームと延長サポートの2段階に分かれています。 メインストリームサポート セキュリティ更新プログラムに加え、新機能の追加や仕様変更などのサポートも提供されます。（Windows Server発売後5年間） インシデント サポート（無償/有償インシデント サポート、1時間ごとに課金されるサポート、保証請求のサポート） セキュリティ更新プログラムのサポート セキュリティ以外の更新プログラム要求 延長サポート セキュリティ更新プログラムのみが提供されます。（メインストリームサポート終了から5年間） 有償サポート セキュリティ更新プログラム（追加料金不要） セキュリティ以外の更新プログラム要求 つまり、メインストリームサポートではセキュリティ更新プログラムに加え、Windows Server の最新機能を活用することができます。一方延長サポートではセキュリティ更新プログラムのみが提供されるため、既存機能のアップデートや新機能の追加はされません。 なお、Windows Server 2012/R2 は以下の通り2023年10月10日で既に EOS を迎えています。 参照：Microsoft ライフサイクル ポリシー EOS後のリスクと対策 EOS になった製品を使い続けると、脆弱性を利用したサイバー攻撃によって被害を受けるリスクが高まります。 ランサムウェア攻撃による被害事例がありますので、以下にご紹介します。 ＊ ＊ ＊ ＊ ＊ ＊ とある会社で、ランサムウェア攻撃により基幹系の会計システムなどの複数のシステムやパソコンに被害が生じました。同社グループ会社のネットワークから侵入されランサムウェア攻撃を実行されたことで、パソコン上のデータや Windowsサーバーのデータが暗号化され、脅迫文も残されていました。 この攻撃により、復旧に2か月かかっただけでなく個人情報の漏洩も発生しており、顧客や従業員に関する氏名や生年月日、電話番号、メールアドレスなど、約186万件の個人情報の流出が懸念されています。 ＊ ＊ ＊ ＊ ＊ ＊ 上記の事例からも分かる通り、ランサムウェア攻撃の被害を受けるとビジネス機会が損失するばかりか、システムやデータの復旧に莫大な費用・時間がかかり、さらに、大量の個人情報漏洩の可能性は企業イメージを著しく低下させてしまいます。 セキュリティインシデントを防ぐためにはデジタル環境を安全に保つための防御策を立て、常に注意を払うことが必要です。 また、Windows 2012/R2 の EOS が及ぼす影響の範囲として、Windows上で稼働するソフトウェアにも注意が必要です。 EOS を迎えると、周辺機器やソフトウェアとの互換性も保証されなくなります。そのため、周辺機器やソフトウェアのアップデートにより製品が利用できなくなる可能性があります。 これらのリスクを回避するために、EOS への対策を講じることはとても重要です。以下に2つの具体的な対策をご紹介します。 EOSリスク回避のための2つの対策 1. 新バージョンまたは新製品への移行を検討する 早めに新バージョンまたは新製品への移行を検討しましょう。新製品への移行にはコストがかかりますが、リスク回避のためには必要な投資と言えます。 2. セキュリティ対策を強化する EOS となったバージョンを使い続ける場合は、残り続ける脆弱性のリスクを軽減するために、IPS/IDS/UTM の強化など自社の環境に合わせたセキュリティ対策を講じましょう。 EOS は ITインフラの担当者にとって避けて通れない課題です。リスクを理解し早めに対策を講じることで、安全かつ円滑な移行を実現しましょう。 対応方法 ここまでは、EOS後のリスクとリスク軽減のための対策について解説してきました。次に、具体的な対応方法について確認していきます。 Azure Stack HCIへ移行 バージョンアップが出来ないという場合も多いかと思います。その場合は、Azure Stack HCI への移行を検討しましょう。 Azure Stack HCI* では、Windows Server 2012/R2 の拡張セキュリティ更新プログラムを2026年10月まで受けることが可能です。バージョンアップの対応が無理なので、あればこの期間を利用して段階的に移行を進めるのが良いでしょう。 Azure Stack HCIとは：Microsoft が提供しているハイブリッドクラウドインフラストラクチャサービスの一つです。HCI とはハイパーコンバージドインフラストラクチャの略で、コンピューティング、ストレージ、ネットワーク機能を一つに統合したソリューションを指します。3層構造の仮想環境をx86サーバー＋ソフトウェアにシンプルに統合管理することができます。 Azure Stack HCI への移行は、デジタルトランスフォーメーション戦略に一石を投じることになります。これにより、企業は効率性の向上、柔軟性、さらなる拡張性を享受する機会を得ることができます。また、サーバー管理であるパッチ管理やバックアップなどの一部タスクの自動化が可能なため、不必要な管理タスクから解放されます。 Azure Stack HCIアプライアンス&認定ノードとしておすすめする製品が、「Lenovo ThinkAgile MX」です。 Lenovo のサーバーは最もセキュリティに優れた x86サーバーの評価を獲得しています。ITICグローバルサーバーハードウェアセキュリティレポートによると、Lenovo ThinkSystemサーバーは、4年連続ですべてのx86サーバーディストリビューションの中で最高のセキュリティスコアを達成したとして評価され、また2022年には、ハッキング攻撃によるダウンタイムを経験した Lenovo ThinkSystemサーバーはわずか4%と報告されています。 Azure Stack HCI は、小規模な環境やミディアムエンタープライズをご利用のお客様全てに推奨できますが、Microsoft製品を中心に扱われているお客様や Windows Server をお使いのお客様、これからクラウド利用を進めたいとお考えのお客様には特に親和性が高い製品です。最小1ノードから構成でき、他の HCI製品に比べ一番低い価格帯から幅広くご提供が可能です。 ロックダウンまたは仮想パッチで対応 「環境を変更できないが、その上で稼働するアプリケーションの互換性が問題で Windows 2012/R2 を使い続ける必要がある」というお客様は非常に多いと思います。その場合は、ロックダウンまたは仮想パッチでリスクを減らすことができます。 ロックダウンと仮想パッチの違いについては、以下の図の通り対応方法や対応箇所が変わってきますので、今使っている環境にあった方法をご選択ください。 ロックダウンと仮想パッチについて、以下でさらなる詳細をご説明します。 ロックダウン ロックダウン方式とは、ユーザーが承認したアプリケーションのみが動作する状況を作り出す方式です。 事前に許可された挙動や機能以外の全ての動き（例えばマルウェアや不正行為）を阻止することができます。これにより、産業用アプリケーションに対してファイルやレジストリの変更をブロックし、正規アプリケーションに見せかける DLLインジェクション等を防ぐといった、未知の脅威やゼロデイ攻撃の予防が可能です。 また、サポート終了OSもサポートし、かつパターン更新等の手間がかからないため、セキュリティ運用の負担軽減も可能です。 ロックダウンを実現するための製品としてお勧めなのが、「TXOne StellarProtect」です。 TXOne StellarProtect には以下の機能が備わっており、Windows 2012/R2環境であっても USB経由でのマルウェア侵入やランサムウェアへの対策を実現できます。 産業用PCに適したウイルス対策 産業用アプリケーションの保護 USBデバイス制御 ファイルレス攻撃対策 レガシーOS対応 仮想パッチ 脆弱性を狙う攻撃コードをネットワークレベルでブロックし仮想的にパッチが当たっている状態にすることだけでなく、脆弱性が悪用される前に迅速にシステムを保護し、実質的に脆弱性を悪用した攻撃を無効化する Intrusion Prevention System/Intrusion Detection System（IPS/IDS）の技術が利用されています。 システムに影響を与えず、サポート終了OSの利用が可能なこともメリットの1つです。 仮想パッチを実現するための製品が、「Cloud One Workload Security」です。以下の機能によって Windows 2012/R2 などの EOS後の OS を保護します。 ホストベースの仮想パッチ機能により脆弱性攻撃をブロック サーバーセキュリティに必要な機能を1つの保護モジュールに実装 管理サーバーの構築・運用が不要 まとめ EOS後のサーバー更改は企業にとって重要な課題です。EOS を迎えたサーバーをサイバー攻撃から守るため、Azure Stack HCI へ移行し延命させる、あるいは OS を守るためのセキュリティを行うなどの対策を進めましょう。 強固なセキュリティ対策は IT環境の持続的な安全性を確保するために不可欠であり、TXOne StellarProtect によるロックダウンや Cloud One Workload Security による仮想パッチを活用することで、Windows Server 2012/R2 であってもより高度なセキュリティ環境を構築することが可能です。 EOS後のサーバー更新、そしてそのセキュリティ対策については、細心の注意を払い最適な対策を行いましょう。 この記事が参考となれば幸いです。また、おすすめとして紹介した Azure Stack HCI を導入して検証したブログもございますので、是非そちらもご覧ください。 関連情報 第一回：【やってみた】Azure Stack HCIを導入してみた：Azure Stack HCI構築編（ブログ） 第二回：【やってみた】Azure Stack HCIを導入してみた：管理機能編（ブログ） 第三回：【やってみた】Azure Stack HCIを導入してみた：Azureと連携編（ブログ） IBM Security Verify（製品情報） お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社技術支援本部E-Mail：nicp_support@NIandC.co.jp .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; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの高村です。 IBM の定例イベント「Think 2023」で発表された IBM watsonx はご存じでしょうか？ AI開発の最前線を走り続けている IBM Watson は、2023年7月に企業向けAI及びデータ・プラットフォーム IBM watsonx（以下 watsonx）のサービス提供を開始しました。なお、watsonx の概要は製品紹介ページで紹介していますので、是非ご覧ください。 今回は watsonx製品の一つ、生成AI開発プラットフォームを担う「IBM watsonx.ai」（以下 watsonx.ai）を使用し、その感想を二部構成でご紹介したいと思います。 Part1（本記事）では、watsonx.ai のご紹介とサービスのプロビジョニング、UI画面にてプロンプトを使ってみた感想を、Part2では、watsonx.ai を利用した Retrieval-Augmented Generation（RAG）検証をご紹介します。 乞うご期待ください。 目次 ビジネスにおける生成AIの活用 watsonx.aiとは？ プロンプト・ラボを使ってみる さいごに お問い合わせ ビジネスにおける生成AIの活用 2022年の ChatGPT公開を機に生成AI は脅威的なスピードで生活に普及されています。企業も生成AI をビジネスに取り入れる動きが加速しており、例えば、OpenAI社は企業向けに ChatGPT Enterprise、Microsoft社は Azure上で Azure OpenAI Service を提供しています。 このように企業向け生成AIサービスも次々発表されている状況で、企業はビジネスの目的に合ったサービスを選ぶことが重要になってきています。 それでは、生成AI を採用する際にどのような考慮点があるでしょうか。以下にいくつかご紹介します。 生成AI採用時の考慮点 回答精度の問題：生成AI は状況や文脈を完全に理解しておらず、適切な回答を生成することが困難となる場合があります。そのため、モデルのチューニングや精度の高い回答を出せるように指示を設計する仕組みが必要です。 他社との差別化：今後多くの企業が生成AI を活用したビジネスを展開していくと、他社との差別化がますます重要となります。ベンダー独自の大規模言語モデルを利用することは勿論ですが、AI開発の先駆者であるサード・パーティーが提供するモデルを利用できることなど、複数のモデルから選択できる点もポイントになります。 セキュリティ対策：ビジネスで生成AI を活用する上では機密情報の取り扱いを注意しなければいけません。個人情報を含んだ情報が他のユーザの回答に利用されることが無いよう、セキュリティ対策が求められます。 このように、企業が求める精度の高い AIモデルを実現でき、他社との差別化及び生産性向上を図ることが可能なサービスが watsonx.ai です。 watsonx.aiとは？ サービス提供形態 はじめにサービス提供形態をご紹介します。 2023年10月時点、watsonx.ai は IBM Cloud からの SaaS提供のみとなっています。また、watsonx.ai を利用するには従来から提供されている Watson Studio（機械学習モデルを開発するための統合環境）と Watson Machine Learning（機械学習環境）の2つのサービスが必要です。 IBM Cloud のカタログ上では「watsonx.ai」という名前のサービスは無く、Watson Studio をプロビジョニングし Watson Machine Learning を紐づけることで、watsonx.ai が利用できるようになります。 料金は Lite/Essentials/Standard のプランが提供されています。（2023年10月時点）Lite は容量制限のある無料プランです。機能を試したい場合はこのプランをご選択ください。Essennsials、Standard は以下の①②③を合計した料金プラン（月額請求）です。 ①プランの基本料金 ※Essentials の基本料金は$0/月です（2023年10月時点）②基盤モデルの利用料③Watson StudioとWatson Machine Learningの利用料 watsonx.aiの特徴 以下の図の通り、watsonx.ai は基盤モデルの選択から調整、テスト、デプロイまでを一貫して行うことができる AI開発スタジオです。 基盤モデル（Foundation Model） watsonx.ai は基盤モデル（Foundation Model）を利用した AI開発スタジオです。 従来の機械学習による AI開発は用途ごとにモデルを作成していましたが、基盤モデルによる AI開発は大量のデータで事前学習を行い、一つの基盤モデルを作成し、用途別に少量のデータでカスタマイズしモデルを作成します。これにより用途向けのモデルは少量のデータで学習が可能となり、今までのような学習時間やリソースを大幅に削減できます。 IBM独自の基盤モデル、サード・パーティーの基盤モデルを提供 watsonx.ai は IBM独自の基盤モデル、サード・パーティーのモデルを提供しており、用途によって選択することは勿論、最先端な技術をサービスに取り入れることが可能です。 2023年10月現在、IBM独自の基盤モデルは2つ、Hugging Face などのサード・パーティーの基盤モデルは7つ提供されています。詳細は「watsonx.ai で使用可能なサポート対象のファウンデーション・モデル」（IBMサイト）をご確認ください。 プロンプト・ラボ watsonx.ai では抽出や生成、分類などのタスクをプロンプトラボで調整します。 プロンプトラボには最大トークン数などのパラメータを調整する機能やサンプルプロンプトも提供されており、迅速なデプロイが可能です。こちらは後ほど試してみようと思います。 今後基盤モデルのチューニング・スタジオも提供予定です。アップデートが楽しみですね。 プロンプト・ラボを使ってみる watsonx.ai をプロビジョニングし、UI画面からプロンプト・ラボを使用してみましょう。（※前提としてIBM Cloudアカウントが作成されていることとします） IBM Cloud のカタログ画面から「Watson Studio」を検索し、クリックします。 料金プランはライトプラン、ロケーションは「ダラス（us-south）」を選択します。※基盤モデルの推論とプロンプト・ラボはダラスとフランクフルトのリージョンでのみ使用可能 以下の画面が表示されるので「Launch in」をプルダウンしてプラットフォームを「IBM watsonx」にします。 以下の画面が表示されるので閉じます。 以下の画面が表示されるので閉じます。 以下の画面で「新規プロジェクト +」をクリックします。 プロジェクト作成画面で「空のプロジェクトを作成」をクリックします。 新規プロジェクト作成画面で任意の名前を入力し「作成」をクリックします。 プロジェクトが作成されました。 左側メニューから「すべてのプロジェクトの表示」をクリックし、作成したプロジェクトを選択します。 「サービスおよび統合」を選択し「サービスの関連付け +」をクリックします。 「Watson Machine Learning」にチェックを入れサービスを関連付けます。 Watson Machine Learning が関連付けられました。 ホーム画面に戻り「ファウンデーション・モデルを試し、プロンプトを作成する」をクリックします。 サンプル・プロンプトから「Questions about an article」を選択し、命令箇所に命令と対象のArticleを入力します。（今回はサンプル・プロンプトを使用してみます） 「llama-2-70b-chat」は一つ以上の例を指定するとより効果的に機能するため、例の箇所に QuestionとAnswer の例を入力します。（このプロンプトは基盤モデル「llama-2-70b-chat」を指定しています） Question へ「トマトの栽培になぜマルチを使用すべきなのか」と入力し「生成」をクリックします。 Answer の箇所に回答が生成されました。（原文と照らし合わせると、適切な箇所を参考にして生成していることがわかります） なお、「モデルパラメータ」をクリックすると最大トークン数などのパラメータ調整もすることが可能です。 UI画面もわかり易く、サンプルをベースに目的のプロンプトを作成できそうです。他にもコールメモの要約やコード生成などのサンプル・プロンプトがありますが、ここでのご紹介は割愛させていただきます。 基盤モデルは IBM独自の基盤モデルやオープンソースの基盤モデルが選択できますが、どれを選べばよいのか迷うところです。基盤モデルを選択においては「watsonx.ai でのファウンデーション・モデルの選択」（IBMサイト）に考慮点が掲載されていますので、こちらを参考に選択いただければと思います。 さいごに いかがでしたでしょうか。watsonx.ai のご紹介とサービスのプロビジョニング、UI画面にてプロンプトを使ってみた感想をご紹介しました。 watsonx.ai には複数の基盤モデルが用意され、今後基盤モデルのチューニングスタジオもリリース予定されています。目的にあったモデルの選定、検証は考慮が必要ですが、カスタマイズの幅が広く、ビジネスの目的にあったAIモデルを実現できますね。 次回の Part2 では、watsonx.ai を利用した Retrieval-Augmented Generation（RAG）の検証結果をご紹介します。watsonx.ai をビジネスにどのように繋げられるかのヒントになると思いますので、ぜひご覧いただければ幸いです。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@NIandC.co.jp .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; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの高村です。 今回は IBM Cloud Schematics（以下 Schematics）を利用して IBM Power Virtual Server のプロビジョニングを検証してみました。 IBM Cloud Schematics とは、Infrastructure as a Code（以下 IaC）を提供する IBM Cloud のマネージドサービスです。IaC や Schematics などについてご存じでない方もいらっしゃると思いますので、順番にご紹介します。 目次 IaCとは？ Schematicsとは？ 検証の概要 Githubの設定 Schematicsワークスペースの設定・プランの実行 さいごに お問い合わせ IaCとは？ IaC はインフラストラクチャの設定や管理をコードで行うアプローチです。具体的には、サーバーやネットワークなどのインフラストラクチャをコードで定義し、必要な時に実行し展開・変更することができます。 IaC を利用するメリットとしては以下が挙げられます。 構築・管理の効率化： インフラストラクチャをコードとして管理することで構築・管理を自動化することができます。またコードを再利用することもできるため、複数の環境に対して同じ構成やリソース追加を効率的に構築することができます。 共有の容易化： IaC は通常、ソースコード管理システム（Githubなど）を使用してコードを管理します。これにより、チームメンバーとの共有・変更の管理が容易になります。 人為的ミスの削減： 人為的なミスのリスクが減り、変更の管理やインフラストラクチャの状態の監視も容易になります。 以下はコードが実行される流れを表した図です。作業者がコードを作成し、そのコードを Gitリポジトリなどにアップロードすると構成管理ツールによってコードが実行され、自動的に環境が構築される流れになります。 IaC を実現するためには構成管理ツールを利用します。代表的なツールとしては「Terraform」「Ansible」「chef」などがあります。以下に簡単にご紹介します。 Terraform： インフラストラクチャのコードを記述することで、インフラストラクチャの作成、構成、および変更を自動化します。Terraform は主に IaaS に焦点を当てており、インフラストラクチャの構成及び状態の管理に使用されます。 Ansible： 構成管理、アプリケーションのデプロイ、タスクのオーケストレーションなど、幅広い自動化タスクに使用されるツールです。主に構成管理とアプリケーションのデプロイに使用されます。 Chef： Chefサーバーとクライアントを使用して設定を管理します。主にシステム設定やソフトウェアの導入などの自動化に使用されます。 ツール毎に得意とする分野があり、使用目的や環境に応じて使い分けられています。これからご紹介する Schematics は上記の Terraform や Ansible の機能を統合し、IBM Cloud環境での IaC を実現するマネージドサービスです。 Schematicsとは？ Schematics は IBM Cloud のサービスの一つとして提供されるマネージドサービスです。 Schematics自体は無償サービスで、プロビジョニングしたリソースに対し費用が発生します。2023年8月時点で、Schematics自体のリソースは北アメリカやヨーロッパなど一部の地域に作成されます。ただし IBM Cloud のリソースを作成する場合は、Schematics のロケーションに関係なくどこでも作成することができます。 Schematics は大きく分けて3つの機能を利用することができます。 Schematicsワークスペース： Terraform の機能を利用し、IBM Cloud環境へのリソースのプロビジョニングと構成の管理の自動化を行います。 Schematicsアクション： Ansible as a Service機能を利用し、構成の管理及びアプリケーションを IBM Cloud環境にデプロイします。 Schematics Blueprints（2023年8月現在ベータ版）： 定義したインフラコードをモジュールとして取り扱い、組み合わせることで大規模環境をデプロイします。 Schematicsワークスペースと Schematicsアクションの使い分けとしては、リソースのプロビジョニングは Schematicsワークスペースを利用し、ソフトウェアのデプロイや設定管理には Schematicsアクションを利用することが推奨されています。 今回の検証では、Schematicsワークスペースを利用した Power Virtual Server のプロビジョニングをご紹介いたします。 検証の概要 Schematicsワークスペースの利用シーンとしては、複数の区画をプロビジョニングしたり、構成変更や別環境へ同一構成をプロビジョニングすることなどが考えられます。 今回の検証では Power Virtual Server を東京リージョンにプロビジョニングし、メモリ容量を変更を行います。また、大阪リージョンにも同じ区画をプロビジョニングしていきます。 なお、事前に Power Virtual Server のワークスペースを東京と大阪に作成しておきます。ワークスペースの作成方法につきましては「【やってみた】IBM Power Virtual ServerのAIX環境とIBM Cloud Object Storageを接続してみた -Part1-」の「2) IBM Power Virtual Serverの作成」をご参照ください。 以下は検証の構成図です。コードは Github のプライベートリポジトリに配置します。外部のソースコード管理ツールを使用したくない場合は IBM Cloud Toolchain の Gitlab を利用することも可能です。 Githubの設定 プライベートリポジトリの作成 Github の使用は初めてなので、アカウントやリポジトリ作成方法は Web で検索しました。以下の画面は Github のトップ画面です。デザインがカッコいいですね。 アカウントを作成し、ダッシュボード画面に入ります。コードは外部公開しない想定のため、プライベートリポジトリを使用します。任意のリポジトリ名を入力、[Private] を選択し [Create a new repository] をクリックします。 プライベートリポジトリが作成できました。作成したリポジトリにコードを配置していきます。 コードの作成 Power Virtual Server をプロビジョニングするためのコードですが、こちらの Github に「サンプルコード」が公開されています。5つのコードファイルがありますが全て使用します。以下各コードファイルの説明です。 README.md：Readmeファイル main.tf ：インフラ定義を記述するファイル provider.tf ：対象のクラウドなどの情報を記述するファイル（リージョンなども記述） variable.tf ：変数を記述するファイル versions.tf ：使用するモジュールとバージョンの組み合わせを記述 プライベートリポジトリの画面に戻り、[Add file] から [Create new file] をクリックします。 ファイル名を入力し、サンプルコードをコピー＆ペーストします。最後に [Commit change] をクリックします。 5つのコードファイルを作成しました。 コードの編集 検証では以下構成の Power Virtual Server をプロビジョニングしていきます。 リージョン：東京 インスタンス名：test_AIX OS：AIX V7.3 CPUタイプ：Uncapped Shared CPU：0.25 メモリ：2GB ストレージタイプ：Tier3 外部ディスク名：dg 外部ディスクサイズ：1GB NW名：pvs_test_nw サンプルコードのままでは上記の構成を作成することはできないため、変数ファイル「variable.tf」を編集する必要があります。main.tf、provider.tf は variable.tf の値をみて動きますので特に編集は不要です。versions.tf は変更無し、README.md は適宜編集します。 以下は variable.tf の内容です。各パラメータの説明は割愛いたしますが、ピンク字①～③の値の確認方法は下にご紹介します。 // Service / Account variable "ibm_cloud_api_key" { description = "API Key" type = string default = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }＜① variable "region" { description = "Reigon of Service" type = string default = "tok" } variable "zone" { description = "Zone of Service" type = string default = "tok04" } variable "cloud_instance_id" { description = "Cloud Instance ID of Service" type = string default = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }＜②// Image variable "image_name" { description = "Name of the image to be used" type = string default = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }＜③// Instance variable "instance_name" { description = "Name of the instance" type = string default = "test_AIX" } variable "memory" { description = "Instance memory" type = number default = 2 } variable "processors" { description = "Instance processors" type = number default = 0.25 } variable "proc_type" { description = "Instance ProcType" type = string default = "shared" } variable "storage_type" { description = "The storage type to be used" type = string default = "tier3" } variable "sys_type" { description = "Instance System Type" type = string default = "s922" }// SSH Key variable "ssh_key_name" { description = "Name of the ssh key to be used" type = string default = "ssh_20230719" } variable "ssh_key_rsa" { description = "Public ssh key" type = string default = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }＜公開鍵を入力// Network variable "network_name" { description = "Name of the network" type = string default = "pvs_test_nw" } variable "network_type" { description = "Type of a network" type = string default = "pub-vlan" } variable "network_count" { description = "Number of networks to provision" type = number default = 1 }// Volume variable "volume_name" { description = "Name of the volume" type = string default = "dg" } variable "volume_size" { description = "Size of a volume" type = number default = 1 } variable "volume_shareable" { description = "Is a volume shareable" type = bool default = false } variable "volume_type" { description = "Type of a volume" type = string default = "tier3" } ピンク字①～③の値の確認方法は以下です。 ①APIキー APIキーの作成方法は「APIキーの作成方法」（IBMサイト）をご参照ください。作成したAPIキーを控えます。 ②クラウドインスタンスID IBM Cloudリソースリストから Power Virtual Server のワークスペースを選択すると GUID が表示されるので控えます。 ③イメージID IBM Cloud Shell からコマンドを実行してブートイメージのイメージIDを取得します。Cloud Shell は管理コンソール画面の右上のアイコンから入ります。 Cloud Shell で以下コマンドを実行します。 $ ibmcloud pi servicelist ＜ワークスペースのcrnが表示されます $ ibmcloud pi service-target crn:XXXXXXXX ＜表示された対象ワークスペースのcrnを入力します $ ibmcloud pi images ＜イメージIDが表示されるのでIDを控えます 以下は出力結果画面です。マスキングが多く申し訳ございませんが、ご参考ください。 これでコードの編集が完了しました。サンプルコードが提供されているので、variable.tf の変数を編集すれば目的のコードを作ることができますね。 トークンの取得 Schematics から Github のプライベートリポジトリにアクセスする際にパーソナルアクセストークンが必要となるため、Github からパーソナルアクセストークンを取得します。メニューから [Settings] をクリックします。 左側メニューの [<>Developer settings] をクリックします。 [Tokens(classic)] をクリックします。 [Generate new token(classic)] をクリックします。 [Note] に適宜入力し、[Expiration] を30日に設定し、"Select scopes" では [repo] にチェックを入れます。画面を下にスクロールし、[Generate token] をクリックします。 パーソナルアクセストークンが作成できました。後程Schematicsワークスペースの作成で必要になるためメモ帳などに控えておきます。 リポジトリーのURL取得 プライベートリポジトリのURLを取得します。リポジトリ画面に戻り [<>Code] をクリックし、[HTTPS] を選択して URL を控えておきます。 これで Github の設定は完了しました。 Schematicsワークスペースの設定・プランの実行 Schematicsワークスペースの作成 Schematicsワークスペースから Power Virtual Server をプロビジョニングにしてみましょう。 IBM Cloud のカタログから "Schematics" を選択します。 Schematics のホーム画面に入りました。[ワークスペースの作成+] をクリックします。 ワークスペース作成画面です。[GithubのURL] にはプライベートリポジトリの URL、[パーソナル・アクセス・トークン] には Github で作成したトークンを入力します。[完全リポジトリーの使用] のチェックボックスはデフォルトままにします。[Terraformバージョン] は最新バージョンを指定して [次へ] をクリックします。 [ワークスペース名] に任意の名前を入力し、[ローケーション] を北アメリカ/ロンドン/フランクフルトの中から選択し、[次へ] をクリックします。 設定値が表示されるので確認し、[作成] をクリックします。 約1分程でワークスペースが作成できました。variable.tf の変数が読み込まれ、ワークスペースの変数に表示されています。 [README] を選択すると、README.md が読み込まれていることがわかります。 Power Virtual Serverのプロビジョニング 右上の [プランの生成] をクリックし、コードのチェックを行います。 プランの生成が成功すると、[ジョブ] 画面に以下のように表示されます。 ちなみに失敗時は以下の画面が表示されます。失敗した場合はエラーメッセージから原因を確認します。ここでは記載しませんが、何回かプランの生成に失敗しコードを修正しました。 コードを修正した場合は、[最新をプル] をクリックすると最新の状態にすることができます。 話がそれましたが、プランを適用してプロビジョニングを実行します。[プランの適用] をクリックします。 進行状況は [ジョブ] から確認できます。 適用が進んでいますね。 約15分程でプランの適用が完了しました。 Power Virtual Server のワークスペースを確認すると、指定通りのインスタンスが作成されていました。 構成変更 Schematicsワークスペースにてメモリ容量を2GBから4GBへ変更します。Github のコード編集ではなく、ワークスペースから変数を上書きすることができます。ワークスペースの変数画面から [memory] の編集アイコンをクリックします。 値を [4] にして [保存] をクリックします。なお、デフォルト値に戻したいときは [デフォルトの使用] にチェックを入れて保存します。 メモリの変数がデフォルトは2、オーバーライド値が4になりました。 プランの生成、適用を行い正常に行われたことを確認します。 Power Virtual Server を確認するとサイズ変更が実行されていました。 数分後、メモリが2GBから4GBに変更されたことを確認できました。 大阪リージョンへプロビジョニング 東京リージョンに作成した区画と同じ構成を大阪リージョンに作成します。リソース変更手順と同様にワークスペースの変数を編集します。[region] を選択して [編集] をクリックします。 大阪リージョンの [osa] を入力して [保存] をクリックします。 同様に、zone, cloud_instane_id, image_name の変数を大阪リージョンの値に上書きします。 変数の上書きをした後、プランの生成を行ったところ生成が失敗してしまいました。ログをみると、イメージを Get できない内容のエラーが出力されています。 しかし、変数のオーバーライド値には大阪リージョンの値を入力しています。Github のコードを編集して Schematicsワークスペースを更新してみましたが、同様のエラーで失敗しました。プラン適用時に環境変数が残ってしまっているのかも？と考え、新たに大阪リージョンの用の Schematicsワークスペースを作成し、変数は大阪リージョンの値を登録しました。 プランの生成・適用を行ったところ、無事成功しました。変数の値は間違っていないようです。 大阪のワークスペースを確認すると、指定した構成で作成されていました。Schematicsワークスペースはリージョン毎に分けた方が良いのかもしれません。 以上で検証は完了です。 コード作成の経験がない私でも、Schematicsワークスペースから Power Virtual Server をプロビジョニングすることができました。サンプルコードはカスタマイズや修正を行えば実行できたので、作業の難易度はそこまで高くありませんでした。 さいごに いかがでしたでしょうか。 Schematicsワークスペースを利用して Power Virtual Server のプロビジョニング、構成変更、別環境へ同一構成のプロビジョニングを行いました。コード作成はスキルが必要と思われる方も多いかと思いますが、サンプルコードが提供されているため初心者でも取り掛かりやすいと思います。 検証では1区画のみの作成でしたが、複数区画作成する場合は GUI で作業するよりもコードを定義し Schematicsワークスペースから実行した方が工数・ミスを削減できるのではと感じます。また、ワークスペース上で変数のデフォルト値が保持されているため、デフォルト値に戻したい場合はクリック一つで設定を戻すことができ、デフォルト値がわからなくなるといったミスを防ぐことができます。 別環境へのプロビジョニングでは変数を上書きしてもプランを適用できなかったため、別リージョン専用のワークスペースを作成しました。明らかな原因を突き止めることができなかったのですが、環境ごとに Schematicsワークスペースを分けた方が運用面では管理がしやすいですね。 また今回は検証しませんでしたが、ベータ版の Schematics Blueprints は定義したコードをモジュールとして取り扱い・組み合わせることで大規模環境をデプロイすることができる機能です。例えば本番環境と同一構成を別リージョンに作成したい場合、通常は一つ一つリソースをプロビジョニングし別環境にも同じ作業を行います。コードを定義し Schematics Blueprints を使用すればコードを組み合わせて環境をデプロイできるため、作業工数の削減が期待できます。 システムの構築は設計から始まり、構築、試験の実施、運用手順書の作成など多くの過程があり、長い時間と労力が必要です。昨今 Schematics をはじめとする IaC の実現ツールが徐々に広まりつつありますが、これからは従来の構築作業がコードとツールを利用した作業や運用に移行していくかもしれません。 最新情報 2023年8月23日に Terraform バージョン0.x が2023年9月末で営業活動終了、2024年9月末にサポート終了されることが発表されました。既存でバージョン0.xをご利用されている場合は2024年9月末までにバージョン1.x以上にアップグレードする必要があります。 Schematics に限らず、IBM Cloudサービスの営業活動終了/サポート終了などは定期的に発表されますので、留意してご利用いただくことが重要です。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@NIandC.co.jp .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; } .bigger { font-size: larger; }
グリーン・ファイナンスや代替えエネルギーへの投資など、脱炭素化や ESG投資（「Environment：環境」「Social：社会」「Governance：企業統治」を考慮した投資活動や経営・事業活動への取り組み）は、もはやムーブメントではありません。これらの取り組みが企業の財務戦略と並ぶ重要な位置を占めるようになっています。 そして、脱炭素化を目指す企業のサステナビリティ・パフォーマンスの最適化に必要不可欠なのが、正確なレポートデータから得る洞察です。 本コラムでは、データ収集と分析を包括的なソフトウェア・プラットフォームにより多岐にわたる ESG指標を報告・管理して排出量を削減するためのアクションを特定し、最終的にはデータ基盤の構築やレポートの合理化、チームのエンゲージメント向上へと導き脱炭素化の加速を実現する IBM の ESGデータ管理プラットフォーム「Envizi ESG Suite」を紹介します。 目次 ESG情報開示の世界的な潮流と日本の状況 改正温対法による排出量情報のデジタル化・オープンデータ化の推進 ESG投資の急拡大と求められる情報開示 Scope毎のCO2排出量の把握はサプライチェーン脱炭素化実現の第一歩 ESGレポート、ESGパフォーマンス、エネルギー管理、施設の最適化 お客様の大きな価値となるサステナビリティ・イニシアチブ促進を目指して お問い合わせ 関連情報 ESG情報開示の世界的な潮流と日本の状況 「ESG」「サステナビリティ」「排出量」「脱炭素化」など、かつては企業にとって馴染みのなかったコンセプトがここ10年間で今や企業戦略の欠かせない一部となりました。 脱炭素に向けた動きは世界的に加速し、国連気候変動枠組条約第26回締約国会議（COP26）が終了した2021年11月時点で、154カ国・1地域が2050年などの年限を区切ったカーボンニュートラル（温室効果ガスの排出を全体としてゼロにすること）の実現を表明しています。 日本でも2020年10月、菅首相による「実質ゼロ表明」宣言（2050年カーボンニュートラル宣言）がありました。これに呼応して地球温暖化対策推進法が一部改正され、「改正地球温暖化対策推進法」（以下 改正温対法）として2021年5月に成立しています。 そもそも温暖化対策については1997年の「京都議定書」を継承して、2015年12月にフランスのパリで開催された COP21 にて世界約200カ国が合意し成立した条約（通称 パリ協定）が対策目標の基準となっています。そのパリ協定を受けて日本政府は2016年に「地球温暖化対策計画」を閣議決定し、その時点で提示されていた目標は「2030年までの中期目標として温室効果ガス排出を2013年対比26％削減。そして、2050年までに80％削減する」というものでした。 しかし「2050年カーボンニュートラル宣言」ではこの80％という目標削減数値が一気に引き上げられ100％に。すなわち、2050年までに排出ゼロにするということです。当然、企業対策も強化されることとなり、これに対し産業界には激震が走りました。 改正温対法による排出量情報のデジタル化・オープンデータ化の推進 改正温対法の主なポイントは次の3点です。 2050年までに温暖化ガスの排出を実質ゼロにすることを基本理念として明記 地域の再エネを活用した脱炭素化を促進する事業推進のための計画・認定制度の創設 脱炭素経営の促進に向けた企業の排出量情報のデジタル化・オープデータ化の推進 このなかで特に注目したいのが「企業の温室効果ガス排出量情報のオープンデータ化」です。 従来、温室効果ガスを多量に排出する企業に対しては毎年度の排出量の報告が義務づけられています。その情報は企業単位で公表されていますが報告の多くは紙媒体を中心に行われており、公表までに約2年もの期間を要していました。 そこで改正温対法では排出量情報の公表までにかかる時間を短縮することを目的とし、企業の温室効果ガス排出量報告を、排出量情報活用促進の弊害にとなっている紙媒体中心の報告から原則デジタル化しています。さらに、企業における脱炭素化の取り組みをより透明性高く可視化するため、従来は開示請求手続きが必要だった事業所単位での排出量情報を、手続きなしでも閲覧可能としています。 これにより、国内外の企業や投資家などに向けて温室効果ガスの排出量情報の活用を促すとともに、脱炭素経営や ESG投資の呼び込みを促進させる考えです。 ESG投資の急拡大と求められる情報開示 金融市場においてはコロナ禍にともなう金融緩和も相まって、ESG投資が急拡大しています。 ESG投資とは "ESGの3要素を重視し社会的責任を果たしている企業に対し投資をすること" を意味します。 2021年7月19日、世界の ESG投資額の統計を集計している国際団体の GSIA（Global Sustainable Investment Alliance）*1 から、ESG投資の統計報告書「Global Sustainable Investment Review（GSIR）」の2020年版が発行されました。 同報告書によれば、2020年の世界の ESG投資額が18年比で15%増の35.3兆ドル（約3900兆円）で、これが全運用資産に占める比率は35.9%と18年比で2.5ポイント上昇しています。日本の ESG投資額も2020年には2.8兆円（約320兆円）と、2018年と比べて31.8％も増加しました。 これにともない、気候変動に関する情報開示を企業に求める動きが世界的に広がっています。日本でも東京証券取引所のプライム市場上場企業は、TCFD提言*2 またはそれと同等の国際的枠組みに基づく開示を求められています。 こうした動きに加えて、2021年11月には IFRS財団（The IFRS Foundation）により「国際サステナビリティ基準審議会（ISSB）」が設立されました。これにより、ESG情報の開示に関する統一的な国際基準を策定する ISSB基準に準拠したサステナビリティ開示基準の公開草案を2024年3月31日までに公表し、2024年度中（遅くとも2025年3月31日まで）に確定する計画も進んでいます。 産業界では、国内外で取引先まで含めたサプライチェーン全体の脱炭素化やそれにともなう経営全体の変容（グリーントランスフォーメーション（GX））が加速し、デジタル技術の活用でサプライチェーン上の CO2排出量を算定し可視化するサービスの開発も活発になっています。 参考情報 *1. Global Sustainable Investment Alliance（GSIA） GSIA は2年に一度、日米欧など世界5地域のESG投資の普及団体が年金基金や資産運用会社などを対象に実施したアンケートを基に「Global Sustainable Investment Review（GSIR）」でESG投資額を公表している。 ※サステナブル投資（SRI・ESG投資）の発展に寄与することを目的とした NPO日本サステナブル投資フォーラム（JSIF）作成の「Global Sustainable Investment Review 2020」日本語訳ダウンロードは「こちら」 *2. TCFD提言 「気候変動関連財務情報開示タスクフォース（Task Force on Climate-related Financial Disclosures）」の略称。 G20財務大臣・中央銀行総裁会議の要請を受け、2015年12月に金融安定理事会（FSB）により気候関連の情報開示および気候変動への金融機関の対応を検討するために設立された。TCFD は2017年6月公表の最終提言をはじめ、関連ガイダンス等複数の刊行物を公表。そのメインレポートが「Final Report: Recommendations of the Task Force on Climate-related Financial Disclosures（気候関連財務情報開示タスクフォースによる提言 最終報告書）」で、通称「TCFD提言」といわれる。 TCFDとは（TCFDサイト） ESG情報開示枠組みの紹介：気候関連財務情報開示タスクフォース（Task Force on Climate-related Financial Disclosures, TCFD）提言（JPXサイト） JPXからのお知らせ：「TCFD提言に沿った情報開示の実態調査（2022年度）」の公表について（JPXサイト） Scope毎のCO2排出量の把握はサプライチェーン脱炭素化実現の第一歩 これらの状況の中でカーボンニュートラルに向けて企業が取り組むべきことは、まず CO2排出量を正しく把握・可視化し、サステナビリティ・パフォーマンスを最適化することです。その目的は、気候関連の財務情報の開示、顧客企業への排出量報告、Scope情報の収集、省エネ法・温対法への対応です。 特に日本が目指す「カーボンニュートラル」は CO2 だけに限らず、メタン、N2O（一酸化二窒素）、フロンガスを含む「温室効果ガス」を対象にしたものであり、「全体としてゼロに」とは「排出量から吸収量と除去量を差し引いた合計をゼロにする」ことを意味します。そのため企業の排出責任の範囲は自社単体からサプライチェーン全体に広がり、排出量を把握することの重要性が高まっています。 国際的な温室効果ガス排出量の算定・報告の基準となるのが「温室効果ガス（GHG）プロトコル」です。その中で設けられている温室効果ガスのサプライチェーン排出量の算定方法・範囲のことをScope（スコープ）と呼びます。 サプライチェーン全体の排出量は「スコープ3基準」として次のように区分されています。 Scope1：事業者自らの燃料の燃焼や工業プロセスにともなう排出量を示す指標 Scope2：他社から供給された電気・熱・蒸気などのエネルギー使用にともなう排出量を示す指標 Scope3：サプライチェーン排出量のうち、Scope1とScope2以外の間接排出量を示す指標 Scope3 では、自社内だけではなく部品メーカーや原材料メーカーなど、自社製品の生産に必要な部品製造のために他社が排出した温室効果ガスの排出量を把握することが求められています。日本全体の CO2排出量削減目標を達成するにはこの Scope3 の排出量にも着目する必要があります。したがって、Scope3 の算出は複雑さをともなうと同時にサプライチェーン全体での脱炭素化実現の第一歩だといえます。 これに対応して CO2 を可視化するサービスは近年クラウドを中心に様々なものが登場しており、マクロ視点での非財務情報としての温室効果ガス排出量実績や削減目標・取り組みの公開まで実現できていますが、可視化までの取り組みで止まってしまい、次のアクションへつなげられていないケースも少なくありません。 図1：温室効果ガス（GHG）排出量のスコープ3基準の範囲 ESGレポート、ESGパフォーマンス、エネルギー管理、施設の最適化 IBM は2022年1月、環境パフォーマンス管理においてデータ分析ソフトウェア・プロバイダー大手Envizi社 の買収を発表しました。 Envizi社は炭素排出量の管理で組織をサポートするというビジョンを持って2004年に設立され、これまで20年近い歴史の中で英国と米国の市場で成長し、10年以上の運用ノウハウを活用したベストプラクティスを提供しています。IBM の「Envizi ESG Suite（以下 Envizi）」には、同社の実績がそのまま活かされています。 正確なデータから得る洞察は脱炭素化の道筋に不可欠です。Envizi の15種類のモジュールは、全体で排出量管理、ESGレポート、ESGパフォーマンス、エネルギー管理、および施設の最適化など様々な機能を提供しており、お客様のニーズに合わせてソリューションを拡張できます。Scope1 および Scope2、さらには Scope3 の全カテゴリをカパーする500を超えるデータ・タイプの収集と集約を自動で実行でき、カスタム・フィールドの追加も容易です。 図2：Enviziがカバーするデータの種類 これにより ESG指標を報告・管理できるようになるだけではなく、データと分析を包括的なソフトウェア・プラットフォームで提供し、現状の可視化や適切な情報開示を支援、そして、サステナビリティ・パフォーマンス管理を促進します。また、国際的に認められた主要な ESG報告書作成フレームワークに対応し、強力な視覚化機能と簡単にカスタマイズ可能なダッシュボードを使用することで環境目標の管理や効率性を向上させる機会の特定、サステナビリティ・リスクの評価を行うことが可能です。 温室効果ガス排出量係数は様々な国や地域、カテゴリごとに次々と更新されていく状況で、ユーザー自らが管理することが非常に難しくなっています。これに対しても、Envizi ではお客様が活動量に関するデータを入力するだけで自動的に排出量が算出されるようなっています。また、毎年のように変わる ESG情報開示フレームワークに対しても Envizi を使うことで簡単にレポーティング作業を管理することができます。 お客様の大きな価値となるサステナビリティ・イニシアチブ促進を目指して 500種類以上のデータの収集と統合を自動化する Envizi は、前述の TCFD の他にも ESG要素に関する開示基準として国際的なサステナビリティ報告基準を運営する「CDP*3」や「SASB*4」など、主要なサステナビリティ・レポートの開示フレームワークをサポートしています。 さらに Envizi は、以下のような IBM のより広範な AI搭載ソフトウェアを共に使用することで企業の環境イニシアチブと日常業務における運用エンドポイントとの間で生成されるフィードバックを自動化し、現状を把握しながら素早い改善アクションの実行を可能にします。 IBM Maximo（設備保全管理ソリューション） IBM Sterling（サプライチェーン・ソリューション） IBM Environmental Intelligence Suite（気候変動による経済的影響を事前に計画・管理） IBM Turbonomic（ITインフラの「リアルタイム最適化」を実行） これによりお客様は ESG対応状況を迅速に把握し、目的にあったテンプレートを用いることでゴールを明確にしてデータの可視化を進め、レポートの作成とプロジェクトを円滑に運営してサステナビリティ活動を加速することができます。そして、レポートを公開することで透明性をアピールするとともにカーボンニュートラルを企業の大きな価値に転換し、サステナビリティ・イニシアチブの促進や環境目標を実現することが可能になるのです。 エヌアイシー・パートナーズは IBM認定ディストリビューターとして、Envizi ESG Suite および Envizi ESG Suite と連携可能な製品の販売を通し、お客様のよりレジリエントで持続可能な運用とサプライチェーンの創出、そして、持続可能性への取り組みをスケーラブルにするための重要なステップを支援いたします。 参考情報 *3. CDP 英国の慈善団体が管理する非政府組織（NGO）であり、投資家、企業、国家、地域、都市が自らの環境影響を管理するためのグローバルな情報開示システムを運営。2000年の発足以来グローバルな環境課題に関するエンゲージメント（働きかけ）の改善に努めており、日本では2005年より活動開始。（一般社団法人 CDP Worldwide-Japan） *4. SASB 「Sustainability Accounting Standards Board（サステナビリティ会計基準審議会）」の略称。2011年に米国サンフランシスコを拠点に設立された非営利団体で、企業の情報開示の質向上に寄与し、中長期視点の投資家の意思決定に貢献することを目的に将来的な財務インパクトが高いと想定されるESG要素に関する開示基準を設定している。2018年11月に11セクター77業種について情報開示に関するスタンダードを作成・公表。 「ESG情報開示枠組みの紹介：SASB（Sustainability Accounting Standards Board, サステナビリティ 会計基準審議会）スタンダード」（JPXサイト） お問い合わせ この記事に関するお問い合せは以下のボタンよりお願いいたします。お問い合わせ 関連情報 NI＋C Pサイト情報 IBM Envizi ESG Suite- 企業の透明性ある情報開示と脱炭素に向けた取り組みをサポートする、ESGデータ管理プラットフォームです。 IBMサイト情報 IBM Envizi ESG Suite Envizi ソリューション概要紹介ビデオ サステナビリティ・レポートの作成を製造業のポートフォリオ全体で変革 IBM Maximo 設備保全管理ソリューション IBM Sterling サプライチェーン・ソリューション IBM Environmental Intelligence Suite IBM Turbonomic .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; } .bigger { font-size: larger; }
2023年、IBMの主力製品である「IBM MQ」「Db2」および「WebSphere Application Server」が、それぞれ30周年と25周年のアニバーサリー・イヤーを迎えました。この3製品は IBM のソフトウェアの歴史の中でも特に長い活躍の歴史を持っています。 その最大の特長は、既存の業務アプリケーションを保護しながら常に最適化や運用費用の削減、DX・UX の向上を目指して新しいアーキテクチャーや標準技術を導入し続けてきたことにあります。これによりアプリケーションの近代化やクラウド移行への要望にも柔軟に対応し、現在に至ってますますその存在感を増しています。 その中でも特に注目すべき製品が、通称 WAS と呼ばれる「IBM WebSphere Application Server」です。WAS は、業務アプリケーションの既存資産を守りつつアプリケーションサーバーの持つデメリットを克服し、Java EE 8 / Java 11 や MicroProfile への対応、コンテナ対応の強化など、お客様の様々な環境に合わせて進化し続けてきました。 本コラムでは、この WAS の現状と将来の展望についてご紹介します。 目次 WASの歴史 WASの現在 WASのこれから 25周年おめでとうございます お問い合わせ WASの歴史 25年にわたりJava EEサーバーをリード WAS は、Webアプリケーションをホストする APサーバーの IBM の主力となる製品です。WebSphereブランドの中核をなす製品として1998年の発表以来現在に至るまで継続的に進化し、Java EEサーバーをリードする存在として業界技術への継続的な対応と信頼性・管理機能の強化、製品戦略に基づく一貫した機能拡張を続けてきました。 近年、企業は "アプリケーションの最適化" と "運用費用の削減" に焦点を当てる新たなアーキテクチャーや標準技術の実装を求めています。同様に、"アプリケーションのモダナイズ" や、マルチクラウドやハイブリッドクラウドへの対応を迅速かつ安全に実現するための "クラウドネイティブ化" にも関心が高まっています。 これらの要求に応えるために WAS が活用されており、Java EEサーバーのリーディングプロダクトとしての地位を堅持し続けています。さらに将来においても、WAS は競争力のあるシステムを構築するための最新鋭ソリューションとして役割を果たすことが期待されています。 図1：WAS年表 アプリケーションの最新化戦略をサポート 現在、企業の IT部門には競争力を高めるためのビジネス戦略が求められています。その中でアプリケーションやサービスの開発を迅速化するためには、アプリケーションの最新化に合わせた反復的なアプローチを提供するソリューションが重要です。 これらのソリューションは、ビジネスニーズやアプリケーションの複雑さに即応して ITインフラ管理の対応を迅速化することで、変化の速い現在の市場に対応した製品の導入や更新を行うことができます。また、信頼性のある既存のソフトウェア投資やインフラストラクチャーを活用することも重要です。そのためには、新しいテクノロジーの採用だけでなく組織のペースに合わせた制御と実装も必要です。 さらに、企業がビジネスの俊敏性と速度を向上させるためには、アプリケーションを素早く組み立てるための再利用可能なコンポーネントが必要です。このアプローチには次のような技術と環境を提供するアプリケーションプラットフォームが必要となります。 モジュラーなアーキテクチャー 次世代の統合技術 クラウドファーストおよびモバイルファーストのマインドセット ハイブリッドな環境でのシームレスな移植性 こうした要件に最も適しているのが WAS です。IBM は WAS を通じて、次にご紹介する2つのランタイムを提供しています。これにより、お客様の既存の資産を活用しながらビジネス変換の基礎となるアプリケーションの最新化戦略をサポートしています。 WASの現在 2つのランタイム WAS は1998年の初リリース以来、数多くのバージョンアップを経て進化し続けてきました。 既存資産を活用するための従来の「WebSphere Traditionalランタイム」に加え、2012年にはモダンなアプリケーション開発とサーバー運用に対応した「WebSphere Libertyランタイム」が登場します。WebSphere Liberty は、更新頻度の増加（年4回から12回）、Java EE 8 / Java 11 への対応、MicroProfile対応、コンテナ対応など、お客様の要求に合わせて進化し続けています。 つまり WAS は、最も長い歴史を持つアプリケーションサーバーでありながら、最新の技術も取り入れた最新のアプリケーションサーバーでもあるのです。 WebSphere Traditional は、従来の運用を継続したいお客様に、"JAX-RPC" や "Entity Bean" などの古い API を使用しているアプリケーションの実行環境として活用されています。そのため、Java EE 7 / Java 8 に対応した最新の実装が最後のバージョンとなり、今後は新機能の実装や新しい仕様への対応は行われません。ただし、8.5.5/9.0.5 に対する標準サポートは少なくとも2030年まで延長される予定です。 一方 WebSphere Liberty は WebSphere Traditional とは異なる設計思想を持ち、モダンなアプリケーション開発とサーバー運用に特化しています。2017年にオープンソース化され "Open Liberty" としても知られています。 Open Liberty にはオープンソースのソフトウェアのライセンスの1つである "EPL（Eclipse Public License）" が採用されており、拡張されたソースコードの公開義務がないため、ビジネスにおいても使いやすいのが大きな特長です。そのため新機能は Open Liberty で開発され、IBM はこれをベースに製品版である WebSphere Liberty として提供しています。 WebSphere Libertyランタイムのメリット WebSphere Liberty はオープンソースの Open Liberty で開発されているため、継続的な統合と配信により、ビジネス価値を提供するアプリケーションを高速でデプロイできるように設計されています。その構成は非常にシンプルであり、自動化やコンテナ化に適しています。 WebSphere Liberty のもう一つの大きな特長は、機能が "Feature" としてモジュール化されていることにあります。これにより、必要な機能だけを有効化できるだけでなく、わずか数秒で起動できるランタイムのサイズ（数十MBのメモリ消費と100MB以下）によって需要に応じて環境を柔軟に構築することができます。 また、軽量さを活かした Agile開発や継続的デリバリー（CD）、自動化された運用や DevOps（Platform as a Code / Immutable Infrastructure）に対応することも可能です。そのため、クラウド環境やコンテナ環境、リソースが限られた限定された IoT環境に最適だといえます。 さらに、WebSphere Liberty独自の機能として "ゼロマイグレーションポリシー" があります。WebSphere Liberty はオープンソースの "Open Libertyプロジェクト" に基づき、年に12回の頻繁な更新に頻繁な更新（年に12回）によって常に最新の状態を保っていますが、その一方で古いバージョンのモジュールも提供し続けています。これがゼロ・マイグレーション・ポリシーと呼ばれる機能で、新しいバージョンの仕様が提供されても古いバージョンのモジュールも提供し続けるため、構成ファイルのバージョンを変更することなく古いバージョンのフィーチャーを利用することが可能です。このゼロマイグレーションポリシーは、Java EE から Jakarta EE への移行にも大きな効果を発揮します。 図2：WebSphere Libertyのメリット WASのこれから 最先端のソフトウェア・ベンダーおよびオープン・ソフトウェア・コミュニティーとの連携でさらに進化 Java EE は2018年に「Jakarta Enterprise Edition（Jakarta EE）」に名称変更されました。しかし、Java EE / Jakarta EE は今後もクラウド・ネイティブの基幹業務アプリケーションのデプロイメントや開発者のスキル向上において重要な役割を果たし続けるでしょう。 IBM は Jakarta EE をサポートする WAS の将来のリリースを提供する予定を表明する一方で、クラウド・ネイティブの世界向けにビジネスアプリケーション開発を加速するために Java EEテクノロジーを Eclipse Foundation に移行する取り組みも行っています。これにより、最先端のソフトウェアベンダーやオープンソフトウェアコミュニティと連携し、さらなる進化を遂げる考えです。 Eclipse MicroProfileをサポートし、マイクロサービス・アプリケーションにも対応 WAS はさらに、"Eclipse MicroProfileプログラミングモデル" をサポートしています。これは、マイクロサービスアーキテクチャーを採用する際に必要な機能を多数のベンダーで標準化する取り組みです。そのため、WAS はマイクロサービスアプリケーションに最適な Java EEプラットフォームとしても活用されています。 バージョン19.0.0.1以降では OpenJDK（11.0.2以降）を使用した OpenJ9 を活用し、Java SE 11 もサポートしています。WebSphere Liberty はクラウドに適した軽量かつ高速な起動性能を維持しながらプログラミングモデルの追加や DevOpsワークフローとの簡単な統合を通じて機能を拡張してきたため、最新のアプリケーションデリバリー・ライフサイクルを短縮するだけでなくオンプレミス環境にも容易にデプロイでき、適切な構成でサブキャパシティライセンスを適用できるのです。 WebSphere Liberty は Java EE / Jakarta EE に対応しながらも従来のアプリケーションサーバーのデメリットを克服し、新しい流れである MicroProfile や Spring Framework にも対応できる柔軟なランタイムです。この多様な要件に対応できる万能な実行環境は多くの技術者にとって非常に重要な存在となっており、国内での WebSphere Traditional からの移行実績が増えています。 25周年おめでとうございます この25年間、WAS は多くの企業の業務プロセスやアプリケーションの開発に貢献し、現在もなお企業のビジネスの発展に欠かせない存在でい続けています。一方世界では、デジタルトランスフォーメーションの時代とともに AI や IoT、クラウドコンピューティングをはじめとする多数の新しいテクノロジーが登場し、企業のビジネスプロセスが劇的に変貌し始めました。 WAS が引き続き利用される理由は何でしょうか？ まず第一に挙げられるのは "高い安全性" です。多数の企業にビジネスプロセスにおける基幹として現在に至るまで使用されて続けていることが、そのことを十分に証明しています。また、"他のテクノロジーとの相互運用性に対する強力なサポート" も WAS の魅力であり、"常に発揮し続ける高いパフォーマンス" も、WAS が活用され続ける大きな理由です。 高度なスケーラビリティと信頼性に優れた WAS は、企業のビジネスにおけるデータ処理やアプリケーションの展開において、将来も軽快なパフォーマンスを保ち続けるでしょう。 エヌアイシー・パートナーズは IBM の認定ディストリビューターとして、WAS の長年にわたる信頼性と高いパフォーマンスを称えて25周年を祝し、今後も WAS が高性能のアプリケーション・サーバーとして企業を支援し続けることを強く期待しています。 お問い合わせ この記事に関するお問い合せは以下のボタンよりお願いいたします。お問い合わせ .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; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの高村です。 今回は IBM Cloudアカウントとユーザのアクセス管理についてご紹介します。IBM Cloud を利用する上で欠かせない情報になりますので、ぜひ最後までお読みいただければと思います。 目次 IBM Cloudのアカウントとは？ ユーザのアクセス管理 注意したいポイント さいごに お問い合わせ IBM Cloudのアカウントとは？ IBM Cloudアカウントとは IBM Cloud を利用するために必要な資格情報で、IBM Cloud を利用するには、まず IBM Cloudアカウントの作成が必要です。 IBM Cloud の利用形態は以下の4種類があり、支払い方法が異なります。ご要件によって選択いただきますが、エヌアイシー・パートナーズで販売可能な利用形態はサブスクリプションとなっております。サブスクリプションは PAYG（Pay as You Go）などの後払いとは異なり、事前に使用権を購入し、毎月使った分だけ消費される支払い方法です。 アカウント登録方法や消費の仕組みは本ブログではご紹介しませんが、ご質問は弊社担当営業または本ページの下部記載の お問い合わせ からご連絡ください。 利用形態 説明 ライトアカウント クレジットカード不要で期限なしで使えるアカウント※新規申し込みは終了 PAYG クレジットカードで使った分だけ後払いするアカウント サブスクリプション デパート商品券のように使用権を事前購入するアカウント 契約書 契約書ベースで契約し、請求書による支払いが可能なアカウント ユーザのアクセス管理 IBM Cloudアカウントを作成したら利用スタートです。 多くの案件はプロジェクトメンバーなど複数人でアカウント内のリソースにアクセスしたり操作を行うと思いますが、その際に利用するのが「ユーザ」です。IBM Cloud では IBM Cloud Identity and Access Management（IAM）という仕組みを利用し、ユーザ及びリソースに対するアクセス管理を行います。 ユーザの種類 アカウントで作成できるユーザは4種類あります。1つのアカウントに1名のアカウント所有者が割り当てられ、アカウント所有者がユーザとアクセス管理を行います。 アカウント所有者：アカウント内のユーザ、リソースの管理責任を負う担当者です。 ユーザ：IBMid により認証される個人の利用者です。アカウント所有者に招待され、リソースに対して作業を実施できます。 サービスID：サービスまたはアプリケーションに付与することができる ID です。サービスID を作成することで、IBM Cloud の外部にあるアプリケーションが IBM Cloudサービスにアクセスできるようになります。 アクセスグループ：複数のユーザやサービスID をまとめてグループしたものです。グループ内のメンバー変更があった場合でも個々のユーザの設定を変更することなく管理が可能です。 リソースへのアクセス管理 管理権限を持つユーザは、ユーザ/サービスID/アクセスグループにアクセス・ポリシー*を設定してリソースへのアクセス許可を実施します。 *アクセス・ポリシー ユーザ/サービスID/アクセスグループがどのリソースに対してどのようなアクションを実施できるかというルール。以下の2種類のアクセス・ポリシーを設定可能です。 プラットフォーム・アクセス：IBM Cloudプラットフォーム上でのアクション実行権限。"管理者" "エディター" "オペレーター" "ビューワー" の4つのロールから指定します。 サービス・アクセス：リソースがもつ独自のツールへのアクセス（API/CLIの実行など）の実行権限。"管理者" "ライター" "リーダー" の3つのロールから指定します。 注意したいポイント 以上、アカウント、ユーザのアクセス管理についてご紹介しました。設定値が複数あり複雑なため、以下に注意すべきポイントをご紹介します。 アカウント間の接続、プロビジョニングの制限 既存でアカウントAをお持ちで、新規でアカウントBをご契約する場合、アカウントAとB内のリソースで通信することは可能ですが異なるアカウントにリソースをプロビジョニングすることはできません。 例）PAYGアカウント内にサブスクリプションアカウントの仮想サーバはプロビジョニング不可 アカウント所有者のメールアドレス 会社のシステムで IBM Cloud をご利⽤される場合、アカウント所有者のメールアドレスは管理用の共有メールアドレスをご登録いただくことをお勧めします。 個⼈のメールアドレスを登録した場合、退職・⼈事異動などでアカウント所有者がログインできなくなってしまう可能性があります。 アクセス・ポリシーの設定し忘れ 「【やってみた】IBM Power Virtual ServerのAIX環境とIBM Cloud Object Storageを接続してみた -Part1-」でご紹介した通り、プラットフォーム・アクセスとサービス・アクセスの両方が設定されていないと、仮想サーバのコンソールがオープンができないなど、全ての機能を利用することができません。 作業を行う前に、アクセス・ポリシーが正しく設定されているかご確認いただくことをお勧めします。 さいごに IBM Cloud を利用する上で、アカウントとユーザのアクセス管理は重要です。 オンプレミスではアカウントという概念は無いため、ご要件にあったアカウントの選定、アカウント毎の制限事項に注意してご利用ください。また、ユーザのアクセス管理は複雑になっていますので、オンプレミスの構築と同様にユーザ管理、アクセス・ポリシーの設計を行ってからご利用されることをお勧めします。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@NIandC.co.jp .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; } .bigger { font-size: larger; }
依然として、多くの企業がランサムウェア攻撃の脅威にさらされ続けています。もはや組織の規模や業種・業態は関係なく、攻撃者はセキュリティの甘いところを容赦なく狙っています。そのため、重要なデータを搭載したストレージは特に可及的速やかに有効な対策を講じることが重要です。 そうした中、IBM FlashSystem のストレージ仮想化ソフトウェア最新版「IBM Storage Virtualize V8.6.0」がリリースされ、ランサムウェア対策に有効なセーフガード・コピーが始めやすくなりました。 本記事ではその詳細とともに IBM Storage Virtualize V8.6.0 の機能拡張について見ていきます。 目次 もはや侵入を覚悟し、可及的速やかに有効な対策を IBM Storage Virtualize V8.6.0で始めやすくなった セーフガード・コピー iSCSIパフォーマンスも大幅改善、コスト削減のチャンス エヌアイシー・パートナーズがお手伝いします この記事に関するお問い合わせ もはや侵入を覚悟し、可及的速やかに有効な対策を ランサムウェア攻撃が猛威を振るい続けています。 独立行政法人 情報処理推進機構（以下 IPA）が発行している「情報セキュリティ白書2022」によると、ランサムウェア攻撃には「広く多数のコンピュータを狙うランサムウェア攻撃」と「侵入型ランサムウェア攻撃」があり、従来の主流は前者であったといいます。しかし、2018～2019年ごろから後者や「二重の脅迫」が観測され始めました。「二重の脅迫」とは、データの復旧のために金銭を要求するだけでなくデータを窃取し、身代金を支払わない場合データを公開するといった脅迫を行うというものです。 また同書は警察庁の公表した資料として、2020年下期の企業・団体等におけるランサムウェア被害の報告件数が21件であったものが、2021年上期は61件、2021年下期は85件と急増したと伝えています。2022年2月自動車部品会社で自動車会社が操業停止に陥ってしまった被害事例や、2021年10月に国内病院で電子カルテデータが取り戻せないため機能が低下した状態で2カ月かけて新システムを構築した被害事例を見ると、この攻撃によっていかに大きな損失を被るかを実感します。 情報セキュリティ白書2022では侵入型ランサムウェア攻撃の手口として5つのステップを挙げており、その初期に "ネットワークへの侵入" "ネットワーク内の侵害被害範囲拡大" があります。侵入経路としては、"ウイルスメールによるもの" "インターネットを経由したもの" "脆弱性を悪用したも" のがあり、そのようにして侵入に成功するとネットワーク構成の把握や管理者権限の奪取を行い、ネットワーク内で侵害範囲拡大を行います。 そのため、特に重要なデータを搭載したストレージについては、可及的速やかに有効性の高い対策を講じなければなりません。 IBM Storage Virtualize V8.6.0で始めやすくなったセーフガード・コピー そうした中、日本でも導入実績の高い IBM FlashSystem に搭載されているストレージ仮想化ソフトウェアの最新版にして Long Term Support（LTS）版である、IBM Storage Virtualize V8.6.0 がリリースされました。 「ん？そんな製品は知らない」と思われたかもしれません。それも当然です。これまでは IBM Spectrum Virtualize という名称であったのが、このバージョンから上記の名称に変わっています。 この新生IBM Storage Virtualize の大きな特長に、IBM FlashSystem 5200 から上位の機種においてランサムウェア攻撃によるデータ暗号化に備えるセーフガード・コピーが内部スケジューラーで行えるようになった、という点があります。これまでのバージョンではほかに FlashCopy と Copy Service Manager（CSM）のライセンスが必要で、CSM に関しては動かすためにサーバーや仮想マシンを構築する必要がありました。しかし、V8.6.0 ではこうしたものを用意しなくても単独でセーフガード・コピー機能を実装できるようになっています。 ここで簡単にセーフガード・コピーの機能をおさらいします。 ストレージのデータは、ポリシーにしたがって定期的にセーフガード・コピー・プールと呼ばれる保護された子プールにスナップショットが作成されます。セーフガード・コピー・プールに置かれるコピーデータはイミュータブル（作成後の変更不可）なもので、ほかのサーバーやアプリケーションからはアクセスできません。ランサムウェア攻撃を受けデータに侵害があったことがわかったら、まだ侵害を受けていない世代のコピーデータを見つけ出してリカバリーボリュームにリストアします。そうすると、サーバーやアプリケーションからデータにアクセスできるようになります。 図1：セーフガード・コピーのしくみ ランサムウェアの手口がどんどん巧妙化・凶悪化しており、必ず侵入は試みられるものとして対策を講じることが重要な今日、セーフガード・コピーの実装は企業・団体にとって1つの安心材料になります。 図2：IBM Storage Virtualize V8.6.0では内部スケジューラーでの運用が可能に ただ、内部スケジューラーによるセーフガード・コピーは単純なポリシーに基づくことを前提としています。 例えば、データの最低取得間隔は1時間に1回です。多くはこれで十分かとは思われますが、リアルタイムに近い感覚でコピーを取得したいといった場合は適していないということになります。また、データの世代保存に関して適用業務に合わせてきめこまかく管理し分けたいといった場合も難しいかもしれません。 データのコピーに関して確たる要件が存在する場合は、CSM の出番です。これがコピー・スケジュールとバックアップの保存期間管理を受け持ち、IBM Storage Virtualize でポリシーを作成すれば CSM はそれを発見し、そのポリシーに従って管理を自動化します。 その一方で、ランサムウェア対策はもはや急務といえ、そのような設計に時間をかけていられないというのも一面の事実です。すでに IBM FlashSystem 5200以上のストレージをお持ちのお客様においては、IBM Storage Virtualize V8.6.0 へアップデートするだけで「いちばん重要なデータだけでもすぐさま守る」「試しに使って効果を見る」といった具合に、内部スケジューラーによるセーフガード・コピーで対策を施すことは非常に重要な施策になります。 iSCSIパフォーマンスも大幅改善、コスト削減のチャンス IBM Storage Virtualize V8.6.0 の機能強化によって、これまで性能要件のためにファイバーチャネルを使わざるを得なかったところへ iSCSI を適用できるケースも出てくるものと思われます。プロトコルを iSCSI に一本化可能となれば導入するスイッチの数を削減できるかもしれませんし、そのスイッチも安価なイーサネットスイッチが選択肢になります。アダプタもしかりです。iSCSI を活用することで、トータルでコストダウンが図れるというわけです。 加えて IBM Storage Virtualize V8.6.0 では、データセンター環境で制限なく NVMeパフォーマンスを発揮できる NVMe over TCP も提供しています。こちらは1回あたりのデータ転送スピードを上げるのに有効で、比較的容量の小さいデータが中心となるケースに効果を発揮します。 エヌアイシー・パートナーズがお手伝いします IBM製品のトライアルが可能な IBM Technology Zone では、現在「ランサムウェア攻撃を受けても迅速な業務復旧をIBMストレージ」というタイトルのセッションを提供しています。これはシナリオに基づいてセーフガード・コピー機能を試せるもので、IBMid をお持ちのお客様であればどなたでもオンライン参加できます。 また、「実際にストレージの容量を試算してみたい」「パフォーマンスを事前シミュレーションしてみたい」というお客様には、エヌアイシー・パートナーズでも IBM Storage Modeller という専用ツールを活用して製品選定を支援しています。 エヌアイシー・パートナーズではランサムウェア対策や ITインフラのコスト削減を検討中のお客様のために、技術的アドバイスや構成支援を提供するだけではなく、まだ顕在化されていない隠れたニーズの掘り起こしもお手伝いします。さらに、未来を見据えたシステム全体の提案支援も行っています。 リセラーの皆様と協力し、お客様が抱える課題を解決するために私たちは存在します！どんなことでもぜひお気軽にご相談ください。 お問い合わせ この記事に関するお問い合せは以下のボタンよりお願いいたします。お問い合わせ .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; } .bigger { font-size: larger; }
Oracle Database を比較的低コストで利用できるエディションとして Oracle SE2 は知られた存在ですが、このデータベースを動かすなら「IBM Power10 S1014」が最も有力な候補であることをご存じでしょうか。 TCOコストやパフォーマンス、バージョン対応、セキュリティという観点で、旧世代の Powerシリーズよりも、何より x86サーバー環境よりも多大なメリットを有しています。 本記事では Oracle SE2サーバーとしての IBM Power10 S1014 の魅力を深堀りしていきます。 目次 Oracle SE2を最も経済的に使うならIBM Power10 S1014 対x86サーバー環境ではさらに大きな優位性を発揮 セキュリティでも一歩先行く機能を実装 Oracleに関する悩みはNI+C Pにご相談ください この記事に関するお問い合わせ Oracle SE2を最も経済的に使うならIBM Power10 S1014 Oracle Database は、企業情報システムのデータベースとして他には代えがたい独特のポジショニングを有しています。その一方、ライセンスコストに関しては企業の懸念材料になり続けていることも事実です。 そうした中、Oracle Database の標準機能を実装していながら低コストで利用できるエディションが「Oracle Standard Edition 2（SE2）」です。SE2 の上位エディションである Oracle EE を EE特有の機能を駆使することなく使っているのであれば(*1)、Oracle SE2 にスイッチするだけでもコストダウンを図ることができます。 加えてハードウェアの選択でもコストダウン効果を得ようというなら、ぜひ、IBM Power10 の「S1014」を第一候補として検討してみてください。S1014 は IBM Power10ラインナップのエントリークラスに相当するスケールアウトモデルのサーバーですが、実はとても有用なのです。 さらに、IBM Power10 の採用は、性能の高さを生かしたサーバー統合という形でのコストメリットも生み出せます。下図の表は、Power8 や Power9 と比較したときに、Oracle SE2用サーバーとしてどれだけパフォーマンスが高いかを示したものです。 図1：Oracle SE2サーバーとしてのIBM Power10の実力比較 見かけの価格は高いように感じても、サーバー統合により全体コストを下げられます。Oracle SE2 が分散して何台もある状況であれば、ご検討いただく価値は十分にあるでしょう。 *1. Oracle Database製品およびエディションによる機能の差異 Oracle Database製品 Oracle Database製品で許可される機能、オプションおよびManagement Pack Oracle Databaseオプションおよび許可される機能 Oracle Management Packおよび許可される機能 対x86サーバー環境ではさらに大きな優位性を発揮 このように、IBM Power10 は従来の Powerラインナップと比較してさまざまなメリットがありますが、対x86サーバー環境ではさらにそれ以上の優位性を発揮します。 そもそも、IBM Power10 は1ソケットで高いパフォーマンスを有します。x86サーバーが HMT2（Hardware Multithreading 2）実装であるのに対し、IBM Power10 は SMT8（Simultaneous Multithreading 8）をサポートしており、トランザクション処理のキャパシティが非常に高く、まさにデータベースに適したサーバーであるといえるでしょう。 一方で Oracle SE2 は、1データベースあたりの同時処理可能スレッド数が16に制限されているため、プラットフォームに関わらず SE2用の基盤にデータベースを仮想統合することで、今時のハードウェアリソースを余すところなく活用でき TCO削減につながります。 IBM Power10 には仮想化技術である PowerVM が搭載されているため、複数の SE2データベースを仮想統合する際にも仮想化ソフトウェアを追加で購入する必要がありません。DBごとにリソース管理が行えるというメリットもあります。 さらに、PowerVM はハードウェアと密接に連携した仮想化のため、オーバーヘッドが非常に少ないという特長があります。CPUシェアが可能であるとともに CPU利用効率が高いため、より多くのデータベースを効率的に稼働させることができます。 ある調査では、S1014 24Coreモデルでの Oracle SE2搭載は、上位機種のx86サーバーと比べて24％、Oracle製データベースアプライアンスとの比較では最大38％、TCO が低くなると算出されています。 IBM Power10 では OS である AIX のライブアップデートができ、OSアップデート時は一部の更新を除いてほぼ再起動が不要です。"信頼性" "可用性" "セキュリティ" という点でも、サーバープラットフォームとして業界で高い評価を受け続けています。このように、様々な観点で安定した稼働を実現でき、運用負荷を大きく軽減します。 古いバージョンの Oracle Database もそのまま稼働できます。IBM Power10 で Oracle Database を動かすメリットとして、比較的古いバージョンを搭載できる、ということがあります。 以下の図は IBM Power10 における Oracle Database のシングルインスタンスの構成サポート状況の図で、表の中の〇は推奨バージョン、△は稼働可能バージョン（現在はOracleがサポート終了しているがかつて動作保証されていた組合せ）であることを示しています。 図2：IBM Power10におけるOracle Databaseのシングルインスタンスサポート状況 これを見ると、さかのぼって Oracle 11.2（11gリリース2）まで対応可能になっています。 データベースサーバーは基幹システムであり、その変化が実業務にインパクトを与えるためになかなかバージョンを上げられないというケースも多々あるかと思います。そのような場合でも IBM Power10 であれば、バージョンを上げずにそのままの状態で稼働させながら大きなパフォーマンス向上を実現させることが可能です。 セキュリティでも一歩先行く機能を実装 セキュリティもまた、ビジネスの継続性を考える上で非常に重要なポイントです。ここでも IBM Power10 S1014 は Oracle SE2 の稼働に大きく貢献します。 AIX上で稼働することで、競合する OS と比較し脆弱性を低く抑えることができます。脆弱性に関するレポートは、23年間で286件、年あたり平均14件という少なさです。 また、IBM Power10 は物理メモリ上のデータを常に暗号化するという透過的メモリ暗号化を実装しており、処理性能に影響を与えることなく脅威からデータを守ることが可能です。AIX ではファイルシステムの暗号化も標準機能として提供しているためデータベース側で特段の対応が不要である点も、運用負荷の軽減につながります。 図3：IBM Power10は透過的メモリ暗号化でデータを保護 Oracleに関する悩みはNI+C Pにご相談ください エヌアイシー・パートナーズでは、IBM Power10 S1014 をインフラとする Oracle SE2サーバー構築に当たり、潜在ニーズを含めたシステム構成の検討から具体的な構成案の作成までサポートします。また、データベースサーバーを取り巻くシステム全体の提案支援も行っています。 エンドユーザーのお客様の課題を解決するために、リセラーの皆様と一緒に知恵を絞り、汗をかくことがモットーです。 「何となく次もx86サーバー」という提案は、いったん脇に置いてみてください。Oracle で悩んでおられるお客様のその課題、IBM Power10 S1014 であっさり解決できるかもしれません。 この記事に関するお問い合わせ この記事に関するお問い合せは以下のボタンよりお願いいたします。お問い合わせ .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; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの佐野です。 海外で開催されたイベント「IBM Think 2023」に参加してきました。久しぶりの海外出張なので、移動も含めてレポートしていきます。 IBM Thinkとは 「IBM Think」はIBMが年次で開催するテクノロジーとビジネスソリューションにフォーカスしたグローバルなフラッグシップイベントです。コロナ禍のためオンサイトでの開催は2020年、2021年の2年間中止していましたが2022年から小規模に再開をし、今年は2022年に比べて少し規模を大きくした開催となりました。 2023年度のイベントが「IBM Think 2023」となり、今年は5月9日から11日までの3日間、アメリカ合衆国のフロリダ州オーランドで開催されました。 IBM Think では基調講演内で IBM の CEO から最新の動向や IBM の進む道、新たな製品発表などが行われます。また、AutomationやSecurityといったカテゴリ毎の基調講演もあり、それぞれのより詳細な内容を聞くこともできます。 基調講演だけではなく個別のセッションや多数のゼネラルセッションもあるので、今後の動向や今現在何ができるかを把握しておきたい分野・ソリューションについてより深く知ることができるイベントです。 出発 Think会場のあるオーランドへは日本からの直行便はありません。そのため、アメリカ国内で飛行機を乗り換える必要があります。今回は羽田からワシントンDC経由でオーランドへ向かいます。 出発日は大雨で羽田空港に向かう電車が遅れていましたが、GW明け直後だったためか空港内は閑散としておりスムーズに出国手続きをすることができました。 羽田：5月8日（月）10:55 → ワシントン：5月8日（月）10:35所要時間 12時間40分（時差13時間） 飛行機の中ではあまり寝られなかったので時差ボケが心配ですが、無事に定刻でワシントンへ到着。 入国審査の税関では疲れのせいか英語があまり聞き取れず何度も聞き返してしまったために係員がかなり不機嫌でした…（笑）が、印刷しておいた飛行機の予約やホテル情報を渡してなんとか無事通過できました。 ワシントンでの乗り換え時間は約2時間取っていましたが、入国がスムーズだったため余裕を持って乗り継ぎの時間に間に合いました。 空港に着いてふと気づいたのですが、アメリカではマスクをしている人はほとんどおらず、付近でマスクをしているのは日本人っぽい人たちだけ。日本とはマスクに対しての意識が全く違うなぁと感じました。 ここまでくれば目的地まであと少しです。オーランド行きの飛行機に搭乗します。 ワシントン：5月8日（月）12:44 → オーランド：5月8日（月）15:04所要時間 2時間20分 その後トラブル無く定刻でオーランド空港に到着！リゾート地なので空港の雰囲気がほかの空港とも全然違います。 滞在するホテルまでUberを使って20分ほどで到着し、ひとまず一安心です。 少し部屋で休憩をし、イベント会場で参加登録を行ってからイベント前日夕方から開催されているウェルカムレセプションへ。 日本時間では真夜中を過ぎそろそろ朝になる時間ですが、外が明るいので物凄く眠たいということはなく、他に日本から来ている方々とご挨拶させて頂き歓談を楽しみました。 その日の夜はぐっすり眠れる・・・わけもなく、まとまって眠れたのは3時間程度でした。。。 IBM Think 2023イベント さぁ、ここからがイベント本番です！ Think 2023 の初日は IBM CEO である Arvindさんの基調講演からスタート。この講演の目玉は「watsonx」の発表でした。 既にメディア各社で基調講演の概要がまとめられているので詳細は割愛しますが、watsonx について一言でいうと、企業向けに ChatGPT のような機械学習モデルをカスタマイズして利用するためのプラットフォームです。 私自身 ChatGPT（3.5）を時々使っていますが、社内の情報は当然答えてくれないので聞けませんし、入力情報を学習に使われてしまうという情報漏洩のリスクがあり機密情報を入れてはいけないという会社のガイドラインもあるため、当たり障りのないことしか聞けません。 しかし、モデルを自社用にカスタマイズし動かす場所を自分で決められるようになればこのような懸念がなくなるので、仕事で使える場面がかなり増えそうだという期待を感じます。 watsonx は「watsonx.ai」「watsonx.data」「watsonx.governance」の3つの製品に分かれています。 watsonx.ai：AIモデルのトレーニングやチューニングを行います。 watsonx.data：AIモデルの学習に使うためのデータを整備します。 watsonx.governance：運用しているAIモデルをモニタリングし、モデルのライフサイクル管理や信頼性を管理しコンプライアンスを遵守しリスクを緩和します。 このように、watsonx を利用することで自社でAIモデルを開発し運用を効率的に実施できるようになります。 watsonx以外にもこれから出荷開始となる製品がセッション内で紹介されていたり展示会場内のブースがあったりしたので、出荷前にどんな製品なのかを知ることができました。 最近の IBM はまず SaaS でリリースした後にソフトウェア版を提供するという順番となることが多いです。一般的にも製品の初期バージョンは改良すべき点が多いため、メーカー側で製品を改善しやすいSaaSから提供開始となるのはユーザーにとってもいいことですね。 イベント開催に伴い展示会場もオープンになっています。 従来の展示会場と比べると控えめな大きさでしたが、基調講演で発表があったwatsonxの展示スペースは初日、たくさんのお客様で大盛況でした！ レゴで作ったサーバーがあったりスケルトンのIBM z16があったりと、普段は見られないものが設置されているのもイベントならではです。 イベント期間中の朝食・昼食はセルフ形式なので、自分の体調やお腹の具合に応じて食べるものや量を調節できます。朝食にはこんなものが置いてあります↓ イベント最終日前日（5/10）の夜は、ユニバーサルスタジオのパークを1つ貸し切ってのパーティーです！ ところどころにIBMのロゴがプロジェクションされ、貸し切りであることを実感できスケールの大きさに感動しました。 帰国 Think2023は5月11日の午前中で終わりなのですが、当日の帰りの飛行機が取れなかったため、帰国は翌日の5月12日になりました。 帰りはオーランドからシカゴ経由で羽田へ向かいます。 オーランド：5月12日（金）7:30 → シカゴ：5月12日（金）9:33所要時間 3時間3分（日本とは14時間の時差）※オーランドは東部時間ですが、シカゴは中部時間のため1時間の時差があります 飛行機の乗り継ぎ時間の確保のため早朝の便になってしまい、ホテルの出発時間は朝の5時…前日の夜にUberで予約ができるのは非常に便利で助かります！ 朝早かったこともあるのか、空港内の人は少なめです。搭乗手続きもすんなり終えることができました。 これからの移動も長いので、オーランド空港で朝ごはんです。 シカゴ：5月12日（金）13:10 → 羽田：5月13日（土）15:55所要時間 12時間45分 シカゴ空港内で迷ったこと以外は特にトラブルも無く、ようやく帰国便への搭乗です。 帰国便は偏西風に乗れないので行きに比べて1時間ほど時間がかかりますが、ワシントンよりシカゴの方が日本に近いため所要時間はあまり変わりません。しかし、単純に移動時間が長いので長距離移動は疲れます… 無事に羽田空港へ到着し、帰宅のための電車に乗ることができました。 帰宅した後2時間ほど仮眠をとったのですが、起きたら真っすぐ歩けない状態！それほど疲れていたとは自分でも思っていなかったのでびっくりしました。 まとめ 今回のイベントの目玉は新しく発表があった「watsonx」です。出荷開始は7月とのことなので情報はこれから徐々に入ってくると思いますが、最近の流行りであるGenerative AIを企業向けに使いやすくするためのIBMらしいソリューションだなぁと感じました。また基調講演内でもメッセージがありましたが、これからどんどんAIを活用したソリューションが出てくるので、個人的には楽しみです。 watsonx以外にも、サステナビリティーソリューションである Envizi や XDR を含めたセキュリティソリューションスイートである QRadar Suite のような、今後の展開が楽しみな製品がありました。これら最新の IBMソリューションがどういう場合に使えるものなのかをしっかり理解して状況に応じて適切なものをご提案できるよう、引き続き情報収集していきます！ 以上、「IBM Think 2023」参加レポートでした。最後までお読み頂きありがとうございました。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社技術支援本部E-Mail：nicp_support@NIandC.co.jp .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; } .bigger { font-size: larger; }
