金融ソリューション事業部の石沢です。ふだんは所属部門の様々なプロジェクトの支援をしています。今回の記事では、当社でやっている 「伴走型研修」 を受講者の立場で紹介します。資格試験については会社の補助で制限なく受験できるのですが、それでも勉強するのは大変ですよね。 くじけずにやりきる ために今回は伴走型研修というものを利用して、無事に資格合格したというお話です。 受験のきっかけ 今回挑戦したのはタイトルにある通り、 AWS Certified Solutions Architect - Associate（以下SAA）です。さすがに説明は不要だと思いますが、詳細は AWS さんのサイトをご確認ください。 AWS Certified Solutions Architect – Associate 認定 自分は、より初心者向けの AWS Certified Cloud Practitionerという資格を3年前に取得していました。この資格の有効期限が切れるので、再受験して維持するのか、より上位の資格にチャレンジを悩んでいたところでした。悩んだポイントは 実務としての AWS を利用したシステム構築経験がない SAAは中級向けの資格であり、難易度はそこそこ高いらしい 割と忙しいので受験を先延ばしにしたり、挫折することになりそう です。組織的にはそれなりの職級にいるので、別に上司から資格を取れと言われるわけでもありません。どうしよっかなー、失敗したら恥ずかしいしパスしようかなー……。 と悩んでいたところに、伴走型研修の案内が来たのでした。 伴走型研修とは もともと社では AWS 認定資格受験希望者に対して学習コンテンツや学習用環境、資格受験費用の全額補助が提供されているのですが、さらに昨年から任意参加型の「伴走型研修」も利用できるようになっていました。 伴走型研修では、以下のサポートを受けることができます（2023年現在の情報） キックオフウェビナーでの、学習の進め方についての全体ガイダンス 講師による個別面談（スキルや状況に応じた学習計画についてアド バイス してもらえる） 毎週30分のミニ勉強会（試験問題解説や情報共有など） 学習中につまづいたポイントや不明点に関する相談や質疑応答など 私はSAAコースを選択しましたが、 AWS Certified Solutions Architect - Professionalコースも選択可能です。心強い！ 実際にやったこと キックオフウェビナー 資格の概要に始まり、学習方法についてひととおり説明していただき助かりました。インターネットにたくさんの情報が公開されているのですが、書いてある内容はバラバラなので、まとめて確認し質疑応答できるのはかなり助かる！ 個別面談 キックオフ後、講師による個別の1on1で学習スケジュールと資格受験日程を決めました。受講の目的や AWS 経験などをアド バイス してもらえます。私の場合はだいたい基礎知識学習1カ月＋問題集などを利用した試験対策1カ月の2カ月コースが良さそうということでスケジュールを組みました。また挫折防止のために、試験を予約したほうが良いとのこと。えーっと思いながらも従順に2カ月後の試験予約もしてしまいます。デッドラインが決まって身が引き締まります。 なお、この伴走型研修では学習自体は各自が自由に進めることになります（座学の講義があるわけではない）。おすすめコンテンツなどを紹介いただきながら、書籍、 AWS が公開しているコンテンツやUdemy講座を中心のカリキュラムを自分で選択することになります。私自身は学習期間にあまりまとまった時間が取れない見込みだったので、基礎知識の学習についても書籍やドキュメントなどの読み込みではなく、Udemyの講座でキャッチアップすることにしました（スキマ時間を活用するため）。 毎週30分のミニ勉強会 技術資格の勉強は、わりと孤独なものになりがちです。ですが、伴走型研修では毎週30分のオンライン勉強会があるので孤立感が軽減されていて良かったです。業務時間内でも30分という時間なので調整しやすく、欠席をしても録画でキャッチアップすることができるようになっています。勉強会では講師の出す例題を皆で解いたり、理解しにくい点について解説を受けたりしました。 受講者チャネルでのフォローアップ 上記以外には、受講者の参加するコミュニケーションチャンネル（ Microsoft Teamsの専用Teamでのチャット）でのフォローアップがあります。学習コンテンツでわからなかった点や、模擬試験集の解説で腑に落ちない点などについて質問をできます。しっかり活用しました。 自習 伴走型研修で伴走してもらいながら、実際に自分でやった事は以下のとおりです。いずれも個人の費用負担はありません。 ハンズオン用の AWS 学習環境の取得（社内で簡単なフォームに入力するだけ。各種ガード設定付きです） いくつかの AWS 提供ドキュメントの通読（読んでおくと良いとアド バイス されたもの） Udemy：【ベストセラー完全日本語化】AWS 認定ソリューションアーキテクト アソシエイト SAA-C03 対応 2022 最新版 書籍での学習を断念し、こちらの講座をUdemy for Business枠で受講。また講座内のハンズオンは極力自分でも手を動かしています。27時間を少しスピードを上げて視聴しています Udemy：【SAA-C03版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） 試験対策として有名なコースですね。当初想像していた問題よりこちらの模擬試験のほうが難しく感じ、また最初はまったく正解できず焦りましたが、復習をしっかりやって知識を補完していきました 試験受験 最後は試験の受験です。自宅だと集中しにくいのでテストセンターで受験し、無事に1回で合格できました。 よかったこと 伴走型研修に参加して一番良かったのは、途中でくじけずに完走して予定通りに資格取得が完了したことです。伴走型研修を利用せずに個人学習のみでチャレンジしていたら、おそらくもっと時間がかかったと思います（ズルズルと試験日を延ばしていたはず）。もしかしたら、途中であきらめてしまったかもしれません。 なお、毎週の勉強会で講師から 「進捗どうですか、質問はいつでもどうぞ」 と言われていたのが自分にとっては先延ばし防止効果がありました。別に進捗報告の必要はなく単なる声掛けだったのですが、勉強が出来ていない週は「ウッ」となって、あわててやっていました。 加えて、世の中にあふれている資格情報に惑わされなかったという点も自分にとっては大きかったです。試験日が近づくにつれて、つい 銀の弾丸 を求めてネットをさまよってしまい「〇〇をやればよい」とか「〇〇だけでは不十分だ」といったブログ記事を見てしまい不安になってしまうのですが、信頼できる講師と話ができるので不安もだいぶ緩和されたと思います。 まとめ 伴走型研修というものを使って、 AWS 実務経験なしでもくじけずに資格取得が出来て良かった という話でした。個人の学習で詰まっている人は、伴走者を見つけると良いかもしれません。 もちろん当社に入社していただければ、ここで紹介した伴走型研修そのものに参加することもできます。興味があればぜひ以下のページもご覧ください！ 私たちは一緒に働いてくれる仲間を募集しています！ ISID 募集職種一覧 執筆： Ishizawa Kento (@kent) 、レビュー： @sato.taichi （ Shodo で執筆されました ）

ISID X（クロス） イノベーション 本部 の池田です。 2023年2月にGAした Azure Load Testing で利用する機会がありましたので使い方のご紹介です。 目次 目次 Azure Load Testingとは Azure Load Testingの価格 試験環境の概要 Azure Load Testing リソースの作成 テストシナリオの作成 負荷テストの実施 負荷テストの実行結果 まとめ Azure Load Testingとは Azure Load Testingは、Azureの クラウド インフラスト ラク チャを使用して、アプリケーションの負荷テストを実行するためのサービスです。使い慣れた JMeter スクリプト で作成したテストシナリオを クラウド 上で実行できます。 自分で 負荷試験 をしようとすると、試験用の端末を複数用意したり、ネットワーク関連のOSパラメータの変更したり考慮すべき点が多いです。また、社内から実行すると ファイアウォール で制限されたりネットワーク環境も考慮する必要があります。 Azure Load Testingを利用することで、こうした面倒な環境作成はAzureにお任せして、利用者は負荷テストシナリオ作成と試験結果の分析に注力できます。 azure.microsoft.com Azure Load Testingの価格 基本的に、仮想ユーザー時間という概念での課金となっています。 JMeter スクリプト 内の仮想ユーザー（並列スレッド）数と、テストエンジン インスタンス の数によって算出されます。 仮想ユーザーの合計数 = （ JMX ファイル内の仮想ユーザー数） * （テスト エンジン インスタンス の数） インスタンス 数だけでなく JMeter スクリプト 内で指定する並列実行数も課金額に影響しますので注意しましょう。 また、テストを実行していなくても少額の課金があります。 Azure Load Testing の価格 試験環境の概要 今回使用するテスト環境の構成は以下のとおりです。App Service 既定のWebサイトをテスト対象としてAzure Load TestingからHTTPリク エス トを連続送信します。その上でAzureリソースの負荷状況をAzure Load Testingの ダッシュ ボードで観測します。 Azure Load Testing リソースの作成 以降では実際にテストを作成します。 Azure Portal からリソースを作成します。 執筆時点で東西日本リージョンではまだ提供されていませんでしたので東アジアリージョンを利用します。 リソースが作成されました。 テストシナリオの作成 Azure Load Testing では「クイックテストを作成する」 および 「 JMeter スクリプト のアップロード」の2種類の方法でテストが作成できます。 クイックテストでは、特定のURLに対しシンプルなGETリク エス トを繰り返す JMeter スクリプト を作成できます。 しかし、認証を含んだシナリオやPOSTリク エス トを含んだシナリオは Azure Load Testing 上で作成できません。様々なケースのシナリオをテストしたい場合には外部で JMeter スクリプト を作成してアップロードする必要があります。 今回のシナリオではクイックテストでも十分ですが、実務を模して スクリプト を取り込む手順でテスト作成します。 JMeter の入手 スクリプト 作成に使用する JMeter はサイトからダウンロードしましょう。Azure Load Testing以外の クラウド 負荷試験 ツールも JMeter スクリプト を取り込んで実行するツールが多いです。初版が2001年のソフトウェアですが JMeter はまだまだ現役です。 jmeter.apache.org スクリプト の作成 ダウンロードした JMeter を使ってローカルでテストを作成します。どこか懐かしい気持ちに浸りながらテストを作成します。スレッド数の設定はコストに影響する部分ですので、過剰に大きくしないよう注意しましょう。 負荷テストの実施 「 JMeter スクリプト のアップロード」を選択しテストを作成します。 まずは、テスト名、説明を入力します。 先ほど作成した JMeter スクリプト をアップロードします。 スクリプト 内で使用するパラメータをこちらで指定できます。 機密性の高いパラメータはKeyVaultから持ってくることも可能です。 スクリプト を実行するエンジンの インスタンス 数を指定します。 テスト抽出条件の設定です。 テスト抽出条件は、レスポンスタイムやエラー率、 スループット の しきい値 を設定し、 しきい値 を超えるとテスト不合格となりテスト全体が終了します。 自動停止テストは、構成エラーによる異常を検知しエンジンを停止する目的で利用します。エラーの割合はエンジン単位で判定されエンジン単位で個別に終了されます。テスト全体としては継続されますので利用方法に注意しましょう。 テスト結果画面でメトリックを表示する インスタンス を選択します。 インスタンス を選択すると既定で設定されているメトリックが試験結果 ダッシュ ボードに表示されます。 ダッシュ ボードに表示する インスタンス やメトリックはテスト後に追加削除が可能です。 メジャーどころのAzureリソースはサポートされていますが、執筆時点ではApplication Gateway がサポートされていませんでした。こちらは今後の追加を期待したいところです。 参考： サポートされている Azure リソースの種類 設定した内容でテストを作成します。 負荷テストの実行結果 実行画面に遷移すると ダッシュ ボードで各種状態が確認できます。実行中に試験結果が随時プロットされて表示されます。クライアント側の試験状況 と サーバー側の負荷状況 が一画面で確認でき大変便利です。 クライアント側メトリック こちらはクライアント側のメトリック情報になります。 各エンジン インスタンス から収集した内容を集計した結果が表示されます。 サーバー側メトリック Azureリソースの各種メトリックが表示されます。テスト後に表示メトリックを追加することもできます。 各種メトリックを一覧表示してどこが ボトルネック となっているのか把握できます。 ただし、項目による分割 や 条件によるフィルタ などの詳細分析はできません。そうした分析は通常のメトリック画面から別途分析しましょう。 エンジン状態 JMeter スクリプト を実行しているエンジン個別の状態も表示できます。 まとめ Azure Load Testingは、 クラウド 上での負荷テストを簡単かつ効果的に行うための強力なツールです。従来の手法に比べて手軽さや柔軟性があり、リアルタイムでの結果の監視も可能です。アプリケーションのパフォーマンスを向上させたい場合や、スケーラビリティの評価を行いたい場合には、Azure Load Testingを検討してみてはいかがでしょうか。 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @ikeda.jun 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

ISID X（クロス） イノベーション 本部 の池田です。 2023年2月にGAした Azure Load Testing で利用する機会がありましたので使い方のご紹介です。 目次 目次 Azure Load Testingとは Azure Load Testingの価格 試験環境の概要 Azure Load Testing リソースの作成 テストシナリオの作成 負荷テストの実施 負荷テストの実行結果 まとめ Azure Load Testingとは Azure Load Testingは、Azureの クラウド インフラスト ラク チャを使用して、アプリケーションの負荷テストを実行するためのサービスです。使い慣れた JMeter スクリプト で作成したテストシナリオを クラウド 上で実行できます。 自分で 負荷試験 をしようとすると、試験用の端末を複数用意したり、ネットワーク関連のOSパラメータの変更したり考慮すべき点が多いです。また、社内から実行すると ファイアウォール で制限されたりネットワーク環境も考慮する必要があります。 Azure Load Testingを利用することで、こうした面倒な環境作成はAzureにお任せして、利用者は負荷テストシナリオ作成と試験結果の分析に注力できます。 azure.microsoft.com Azure Load Testingの価格 基本的に、仮想ユーザー時間という概念での課金となっています。 JMeter スクリプト 内の仮想ユーザー（並列スレッド）数と、テストエンジン インスタンス の数によって算出されます。 仮想ユーザーの合計数 = （ JMX ファイル内の仮想ユーザー数） * （テスト エンジン インスタンス の数） インスタンス 数だけでなく JMeter スクリプト 内で指定する並列実行数も課金額に影響しますので注意しましょう。 また、テストを実行していなくても少額の課金があります。 Azure Load Testing の価格 試験環境の概要 今回使用するテスト環境の構成は以下のとおりです。App Service 既定のWebサイトをテスト対象としてAzure Load TestingからHTTPリク エス トを連続送信します。その上でAzureリソースの負荷状況をAzure Load Testingの ダッシュ ボードで観測します。 Azure Load Testing リソースの作成 以降では実際にテストを作成します。 Azure Portal からリソースを作成します。 執筆時点で東西日本リージョンではまだ提供されていませんでしたので東アジアリージョンを利用します。 リソースが作成されました。 テストシナリオの作成 Azure Load Testing では「クイックテストを作成する」 および 「 JMeter スクリプト のアップロード」の2種類の方法でテストが作成できます。 クイックテストでは、特定のURLに対しシンプルなGETリク エス トを繰り返す JMeter スクリプト を作成できます。 しかし、認証を含んだシナリオやPOSTリク エス トを含んだシナリオは Azure Load Testing 上で作成できません。様々なケースのシナリオをテストしたい場合には外部で JMeter スクリプト を作成してアップロードする必要があります。 今回のシナリオではクイックテストでも十分ですが、実務を模して スクリプト を取り込む手順でテスト作成します。 JMeter の入手 スクリプト 作成に使用する JMeter はサイトからダウンロードしましょう。Azure Load Testing以外の クラウド 負荷試験 ツールも JMeter スクリプト を取り込んで実行するツールが多いです。初版が2001年のソフトウェアですが JMeter はまだまだ現役です。 jmeter.apache.org スクリプト の作成 ダウンロードした JMeter を使ってローカルでテストを作成します。どこか懐かしい気持ちに浸りながらテストを作成します。スレッド数の設定はコストに影響する部分ですので、過剰に大きくしないよう注意しましょう。 負荷テストの実施 「 JMeter スクリプト のアップロード」を選択しテストを作成します。 まずは、テスト名、説明を入力します。 先ほど作成した JMeter スクリプト をアップロードします。 スクリプト 内で使用するパラメータをこちらで指定できます。 機密性の高いパラメータはKeyVaultから持ってくることも可能です。 スクリプト を実行するエンジンの インスタンス 数を指定します。 テスト抽出条件の設定です。 テスト抽出条件は、レスポンスタイムやエラー率、 スループット の しきい値 を設定し、 しきい値 を超えるとテスト不合格となりテスト全体が終了します。 自動停止テストは、構成エラーによる異常を検知しエンジンを停止する目的で利用します。エラーの割合はエンジン単位で判定されエンジン単位で個別に終了されます。テスト全体としては継続されますので利用方法に注意しましょう。 テスト結果画面でメトリックを表示する インスタンス を選択します。 インスタンス を選択すると既定で設定されているメトリックが試験結果 ダッシュ ボードに表示されます。 ダッシュ ボードに表示する インスタンス やメトリックはテスト後に追加削除が可能です。 メジャーどころのAzureリソースはサポートされていますが、執筆時点ではApplication Gateway がサポートされていませんでした。こちらは今後の追加を期待したいところです。 参考： サポートされている Azure リソースの種類 設定した内容でテストを作成します。 負荷テストの実行結果 実行画面に遷移すると ダッシュ ボードで各種状態が確認できます。実行中に試験結果が随時プロットされて表示されます。クライアント側の試験状況 と サーバー側の負荷状況 が一画面で確認でき大変便利です。 クライアント側メトリック こちらはクライアント側のメトリック情報になります。 各エンジン インスタンス から収集した内容を集計した結果が表示されます。 サーバー側メトリック Azureリソースの各種メトリックが表示されます。テスト後に表示メトリックを追加することもできます。 各種メトリックを一覧表示してどこが ボトルネック となっているのか把握できます。 ただし、項目による分割 や 条件によるフィルタ などの詳細分析はできません。そうした分析は通常のメトリック画面から別途分析しましょう。 エンジン状態 JMeter スクリプト を実行しているエンジン個別の状態も表示できます。 まとめ Azure Load Testingは、 クラウド 上での負荷テストを簡単かつ効果的に行うための強力なツールです。従来の手法に比べて手軽さや柔軟性があり、リアルタイムでの結果の監視も可能です。アプリケーションのパフォーマンスを向上させたい場合や、スケーラビリティの評価を行いたい場合には、Azure Load Testingを検討してみてはいかがでしょうか。 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @ikeda.jun 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

はじめに こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 みなさん GitHub Codespaces( https://github.co.jp/features/codespaces ) をご存知ですか？ 昨年一般提供された GitHub で利用できる 統合開発環境 ( IDE )です。 GitHub Codespacesは、ブラウザ上で動作する開発環境となります。 GitHub から起動することができて、ブラウザが動く環境であれば、追加でソフトウェアのインストールを必要とせず、いつでもどこでも開発作業が可能です。 この記事では、その特徴、使い方、そして便利な点について解説します。特にチームの開発で開発環境を統一したい場合や素早く開発環境を用意したい場合には GitHub Codespaces を検討しても良いかもしれません。 GitHub Codespacesの特徴 GitHub Codespacesは、 クラウド 上に開発環境を構築し、 クラウド 上で完結する開発環境です。開発者はデ バイス や場所に依存せず、どこからでもコードの編集や実行が可能になります。従来の開発環境では、各個人のPCに環境を構築する必要がありましたが、Codespacesを使用するとその必要がありません。 Visual Studio Code と完全に統合されているため、その強力な機能を利用できます。コードの補完、 シンタックス ハイライト、 リファクタリング 、 デバッグ といった機能はもちろんのこと、 拡張機能 をインストールしてカスタマイズすることも可能です。 この記事では GitHub Codespacesの概要を紹介しますが、詳細は公式のドキュメントも参照して下さい。 https://docs.github.com/ja/codespaces GitHub Codespacesの利用方法 GitHub Codespacesの利用はとても簡単です。 GitHub の リポジトリ ページにアクセスし、"Code"ボタンの下にある"Open with Codespaces"を選択するだけでCodespaceを作成できます。 Codespaceが作成されると、その リポジトリ 専用に GitHub が提供している クラウド 上に開発環境が構築され、アクセスすると Visual Studio Code がブラウザで立ち上がります。 しかも リポジトリ の ソースコード は既に git clone されていて、すぐにコードの編集や デバッグ を開始できます。また起動した Visual Studio Code はローカルで使用しているのとほぼ同じ機能が実現されています。普段から Visual Studio Code に慣れている開発者であれば、普段通りコードの編集や デバッグ が可能です。もちろん、コード補完、 シンタックス ハイライト、 リファクタリング 、 拡張機能 も利用できます。 GitHub Codespacesの便利な点 ここでは、自分が GitHub Codespacesを使っていて便利だと思った点をいくつか紹介していこうと思います。 Dev Containerを使った環境のカスタマイズ GitHub Codespacesでは、Dev Containerを使った開発環境のカスタマイズを行うことも可能です。 .devcontainer/devcontainer.json を作成して、Dev Container環境を作成することが出来ます。この設定ファイルでは、使用する基本イメージの指定、必要なツールのインストール、VisualStudio Codeの設定、ポートの開放などを定義できます。 先日、このテックブログにもDev Containerを使った Python の開発環境を構築する記事が公開されています。Dev Containerの設定についてはそちらが参考になるかと思います。 Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 Dev Container用の設定ファイルは、 リポジトリ に含めて共有することで、チーム全体で統一した開発環境を簡単に構築できます。 Dev Containerの設定については、 GitHub Codespacesにも説明があるので確認してみてください。 https://docs.github.com/ja/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers GitHub Codespacesでの 拡張機能 の扱い GitHub Codespaces上では起動した環境上でMarketplace から 拡張機能 のインストールが可能です。 もし普段、 Visual Studio Code の設定の同期機能を利用している場合であれば、 GitHub Codespacesとも設定を同期させることも可能です。VisualStudio Codeの設定の保存に GitHub を利用している場合、起動した GitHub CodeSpacesに同期している設定が自動的に読み込まれます。この機能とDev Containerを組み合わせることで柔軟に開発環境を構築することが可能となります。Dev Containerではチームで使う 拡張機能 を共通でインストールして、 Visual Studio Code の同期機能で個人の 拡張機能 をインストールするというような運用が可能となります。 GitHub Codespacesのパーソナライズの項目に説明があるので確認してみてください。 https://docs.github.com/ja/enterprise-cloud@latest/codespaces/customizing-your-codespace/personalizing-github-codespaces-for-your-account GitHub との統合 GitHub との統合も大きな特徴の一つです。起動した GitHub Codespacesの環境では起動した状態で git clone が実行されている状態であることは紹介しました。さらに、 GitHub への認証が完了している状態で起動しているので、 リポジトリ へのコードの git push といった操作を行なう際に追加の設定作業は不要です。起動して、コードを修正して、テストして、すぐにpushするという作業に集中できます。 GItHub 用の 拡張機能 もインストールされているため、Pull Requestの作成、マージ、コードレビュー、イシューの管理も行えます。 クラウド 上に開発環境があることのメリット ここまでで、 GitHub Codespacesの便利な機能を簡単に紹介しました。この他に GitHub Codespacesが クラウド 環境に開発環境が構築されることによるメリットもあります。 開発環境の構築が高速 まず一つ目として、新規プロジェクトを開始する際に、従来のローカル環境と比べて環境設定の時間を大幅に短縮できる点が挙げられます。新たに必要なツールやライブラリをインストールする手間が省け、すぐに開発に取りかかることができます。 開発で利用するマシンが自由 二つ目として、異なるOSやデ バイス での開発が容易になる点です。たとえば、普段は Mac を使って開発している人でもブラウザさえ起動できれば同一の環境がすぐ手に入ります。 開発環境の統一の実現 そして、最も大きな利点として、チームの効率化を挙げることができます。全てのチームメンバーが同じ開発環境を簡単に共有できるため、環境差による問題が大幅に減少します。また、Codespaceはブラウザ上で動作するため、どのデ バイス からでもアクセスできます。これにより、場所にとらわれずに作業が可能となります。 GitHub Codespacesの注意点と制限 使用料金はリソースの使用量によります。無駄な費用を避けるためには、使用しないCodespacesは閉じるなど、適切な管理が求められます。Codespacesは開発環境を起動している時間と利用しているストレージの料金の2種類が請求されます。使っていない環境は自動的に削除されるので、無駄な起動時間の請求はあまり発生しないと思います。しかし、ストレージの方は自動的に削除されないため注意が必要となります。 GitHub Codespacesの利用料金は以下のページを参照してください。 https://docs.github.com/ja/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces また、一部のハードウェア依存の開発や、特定の開発を GitHub Codespacesでは行なうことが出来ません。例えば、高度な3Dグラフィックスを必要とする開発作業や、特別なハードウェアに依存した開発作業は、現在のところCodespacesではサポートされていません。 まとめ 今回は GitHub Codespacesについて紹介しました。 GitHub Codespacesは、 クラウド 上に開発環境を提供することで環境設定の手間を省き、どこからでも安全に開発を行うことができる便利なツールです。ただし、料金や対応できない開発がある事など一部の問題を理解した上で使用することが重要となります。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

はじめに こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 みなさん GitHub Codespaces( https://github.co.jp/features/codespaces ) をご存知ですか？ 昨年一般提供された GitHub で利用できる 統合開発環境 ( IDE )です。 GitHub Codespacesは、ブラウザ上で動作する開発環境となります。 GitHub から起動することができて、ブラウザが動く環境であれば、追加でソフトウェアのインストールを必要とせず、いつでもどこでも開発作業が可能です。 この記事では、その特徴、使い方、そして便利な点について解説します。特にチームの開発で開発環境を統一したい場合や素早く開発環境を用意したい場合には GitHub Codespaces を検討しても良いかもしれません。 GitHub Codespacesの特徴 GitHub Codespacesは、 クラウド 上に開発環境を構築し、 クラウド 上で完結する開発環境です。開発者はデ バイス や場所に依存せず、どこからでもコードの編集や実行が可能になります。従来の開発環境では、各個人のPCに環境を構築する必要がありましたが、Codespacesを使用するとその必要がありません。 Visual Studio Code と完全に統合されているため、その強力な機能を利用できます。コードの補完、 シンタックス ハイライト、 リファクタリング 、 デバッグ といった機能はもちろんのこと、 拡張機能 をインストールしてカスタマイズすることも可能です。 この記事では GitHub Codespacesの概要を紹介しますが、詳細は公式のドキュメントも参照して下さい。 https://docs.github.com/ja/codespaces GitHub Codespacesの利用方法 GitHub Codespacesの利用はとても簡単です。 GitHub の リポジトリ ページにアクセスし、"Code"ボタンの下にある"Open with Codespaces"を選択するだけでCodespaceを作成できます。 Codespaceが作成されると、その リポジトリ 専用に GitHub が提供している クラウド 上に開発環境が構築され、アクセスすると Visual Studio Code がブラウザで立ち上がります。 しかも リポジトリ の ソースコード は既に git clone されていて、すぐにコードの編集や デバッグ を開始できます。また起動した Visual Studio Code はローカルで使用しているのとほぼ同じ機能が実現されています。普段から Visual Studio Code に慣れている開発者であれば、普段通りコードの編集や デバッグ が可能です。もちろん、コード補完、 シンタックス ハイライト、 リファクタリング 、 拡張機能 も利用できます。 GitHub Codespacesの便利な点 ここでは、自分が GitHub Codespacesを使っていて便利だと思った点をいくつか紹介していこうと思います。 Dev Containerを使った環境のカスタマイズ GitHub Codespacesでは、Dev Containerを使った開発環境のカスタマイズを行うことも可能です。 .devcontainer/devcontainer.json を作成して、Dev Container環境を作成することが出来ます。この設定ファイルでは、使用する基本イメージの指定、必要なツールのインストール、VisualStudio Codeの設定、ポートの開放などを定義できます。 先日、このテックブログにもDev Containerを使った Python の開発環境を構築する記事が公開されています。Dev Containerの設定についてはそちらが参考になるかと思います。 Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 Dev Container用の設定ファイルは、 リポジトリ に含めて共有することで、チーム全体で統一した開発環境を簡単に構築できます。 Dev Containerの設定については、 GitHub Codespacesにも説明があるので確認してみてください。 https://docs.github.com/ja/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers GitHub Codespacesでの 拡張機能 の扱い GitHub Codespaces上では起動した環境上でMarketplace から 拡張機能 のインストールが可能です。 もし普段、 Visual Studio Code の設定の同期機能を利用している場合であれば、 GitHub Codespacesとも設定を同期させることも可能です。VisualStudio Codeの設定の保存に GitHub を利用している場合、起動した GitHub CodeSpacesに同期している設定が自動的に読み込まれます。この機能とDev Containerを組み合わせることで柔軟に開発環境を構築することが可能となります。Dev Containerではチームで使う 拡張機能 を共通でインストールして、 Visual Studio Code の同期機能で個人の 拡張機能 をインストールするというような運用が可能となります。 GitHub Codespacesのパーソナライズの項目に説明があるので確認してみてください。 https://docs.github.com/ja/enterprise-cloud@latest/codespaces/customizing-your-codespace/personalizing-github-codespaces-for-your-account GitHub との統合 GitHub との統合も大きな特徴の一つです。起動した GitHub Codespacesの環境では起動した状態で git clone が実行されている状態であることは紹介しました。さらに、 GitHub への認証が完了している状態で起動しているので、 リポジトリ へのコードの git push といった操作を行なう際に追加の設定作業は不要です。起動して、コードを修正して、テストして、すぐにpushするという作業に集中できます。 GItHub 用の 拡張機能 もインストールされているため、Pull Requestの作成、マージ、コードレビュー、イシューの管理も行えます。 クラウド 上に開発環境があることのメリット ここまでで、 GitHub Codespacesの便利な機能を簡単に紹介しました。この他に GitHub Codespacesが クラウド 環境に開発環境が構築されることによるメリットもあります。 開発環境の構築が高速 まず一つ目として、新規プロジェクトを開始する際に、従来のローカル環境と比べて環境設定の時間を大幅に短縮できる点が挙げられます。新たに必要なツールやライブラリをインストールする手間が省け、すぐに開発に取りかかることができます。 開発で利用するマシンが自由 二つ目として、異なるOSやデ バイス での開発が容易になる点です。たとえば、普段は Mac を使って開発している人でもブラウザさえ起動できれば同一の環境がすぐ手に入ります。 開発環境の統一の実現 そして、最も大きな利点として、チームの効率化を挙げることができます。全てのチームメンバーが同じ開発環境を簡単に共有できるため、環境差による問題が大幅に減少します。また、Codespaceはブラウザ上で動作するため、どのデ バイス からでもアクセスできます。これにより、場所にとらわれずに作業が可能となります。 GitHub Codespacesの注意点と制限 使用料金はリソースの使用量によります。無駄な費用を避けるためには、使用しないCodespacesは閉じるなど、適切な管理が求められます。Codespacesは開発環境を起動している時間と利用しているストレージの料金の2種類が請求されます。使っていない環境は自動的に削除されるので、無駄な起動時間の請求はあまり発生しないと思います。しかし、ストレージの方は自動的に削除されないため注意が必要となります。 GitHub Codespacesの利用料金は以下のページを参照してください。 https://docs.github.com/ja/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces また、一部のハードウェア依存の開発や、特定の開発を GitHub Codespacesでは行なうことが出来ません。例えば、高度な3Dグラフィックスを必要とする開発作業や、特別なハードウェアに依存した開発作業は、現在のところCodespacesではサポートされていません。 まとめ 今回は GitHub Codespacesについて紹介しました。 GitHub Codespacesは、 クラウド 上に開発環境を提供することで環境設定の手間を省き、どこからでも安全に開発を行うことができる便利なツールです。ただし、料金や対応できない開発がある事など一部の問題を理解した上で使用することが重要となります。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは、金融ソリューション事業部の岡崎、若本です。 3DCG空間では、オブジェクトに関する情報を過度に表示し過ぎることはユーザー体験を阻害する要因になります。その一方で、あまりに情報が少ないと世界観の欠如に繋がります。そのため、質問応答などのユーザーが求める情報を必要なだけ表示する仕組みが求められることがあります。 そこで今回は、 Unreal Engine （UE）上のオブジェクトの情報についてChatGPTに問い合わせる実装を行ってみたいと思います。 下図のように、あらかじめ 格納した関連文献を基に、UE上でObjectに対する質問をChatGPTに答えさせる ことがゴールです。 準備するもの 処理概要 手順①. GPTを用いたAPIを作成 1.1 APIの環境構築 1.2 エンドポイントの作成 1.3 機能の作成 1.4 動作確認（データ登録） 1.5 動作確認（検索） 手順②. オブジェクトの準備 2.1 チャット可能な範囲に入ったとき、アイコンを表示する機能 2.2 オブジェクト（Actor）をクリックしてチャット画面を表示する機能 手順③. チャットUIの実装 3.1 チャットのページUIを実装 3.2 チャットの吹き出しUIを実装 3.2.1 自分のチャットを表示する 3.2.2 GPTの返信を表示する 手順④. HTTPリクエスト用のC++クラス作成 4.1 C++クラスを作成 4.2 C++クラスを編集 4.3 作成したクラスをブループリント化 手順⑤. 質問送信時の処理を実装 5.1 「送信」ボタンが押されたとき、送信した内容を表示する 5.2 HTTPリクエストを送信する 5.3 GPTの返信内容を表示する デモ動画 おわりに 準備するもの Unreal Engine 5.2.0 OpenAI API GPT-3.5-turbo（0301）を使用します。 事前にユーザー登録と、 API キーの発行を実施しておきます。 FastAPI API として、下記の機能を作成します。 オブジェクトに関連したドキュメントを登録する オブジェクト名と質問を与え、答えを返す Docker API の環境構築に使用します。 処理概要 下記の処理を実装します。 それぞれの機能について、（）内の担当者が作業を行いました。 コリジョン 判定（岡崎） チャット可能な範囲に入ったとき、アイコンを表示します。 チャットUIの表示（岡崎、若本） コリジョン 状態でオブジェクト（Actor）をクリックし、チャット画面を表示します。 GPTへのリク エス ト（若本） UE上の情報を基に、GPTにリク エス トを送ります。 結果の表示（若本） API から返ってきたレスポンスをUIに反映します。 以降では、各機能の概要や実装について説明します。 手順①. GPTを用いた API を作成 本手順は若本が説明します。 GPTはUE内のオブジェクトについて情報を持たないため、そのままChatGPTに問い合わせても的確に質問に答えることができません。 そこで、以下の2つの機能を持つ API を作成します。今回は Unreal Engine を実行するPC上で構築することとしました。 オブジェクトに関連したドキュメントを登録する（インデックス登録） オブジェクト名と質問を与え、答えを返す（問い合わせ） それぞれの機能についてエンドポイントを用意し、HTTPリク エス トで実行できるようにします。 最終的には下記のようなファイル構成となります。 1.1 API の環境構築 まずはDockerで API のベースとなる環境を作成します。 以下は最終的に使用したDockerの設定ファイルです。 フォルダ上でdocker containerをupするとアプリケーションが起動します（ http://localhost:8000/docs/ からアクセスすることができます）。 docker-compose.yml（クリックで表示） version: '3' services: backend: container_name: gpt-api build: context: . dockerfile: ./Dockerfile volumes: \- type: bind source: './api' target: '/src' ports: \- 8000:8000 stdin_open: true Dockerfile（クリックで表示） FROM python:3.8-slim-buster RUN pip install --upgrade pip RUN pip install --upgrade setuptools COPY requirements.txt / RUN pip install -r requirements.txt WORKDIR /src CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--reload"] requirements.txt（クリックで表示） numpy openai transformers llama_index langchain fastapi uvicorn[standard] pandas 1.2 エンドポイントの作成 次に、 API が持つ2つの機能についてエンドポイントを作成していきます。 routers/index.pyにインデックス登録のエンドポイントを、routers/search.pyに問い合わせ用のエンドポイントを記述しています。 main.py（クリックで表示） from fastapi import FastAPI from routers import search, index import os os.environ[ 'OPENAI_API_KEY' ] = 'YOUR_OPENAI_API_TOKEN' app = FastAPI() app.include_router(search.router) app.include_router(index.router) routers/index.py（クリックで表示） from fastapi import APIRouter from functions.index_operation import create_index router = APIRouter() @ router.post ( "/index" ) def service_create_index (dir_name: str ): _ = create_index(dir_name) return 200 routers/search.py（クリックで表示） from fastapi import APIRouter from pydantic import BaseModel from functions.search_operation import search router = APIRouter() class SearchRequestItem (BaseModel): dir_name: str = None query: str = None class SearchResponseItem (BaseModel): text: str = None @ router.post ( "/search" ) def service_search (item: SearchRequestItem) -> SearchResponseItem: response_text = search(item.dir_name, item.query) response = SearchResponseItem(text=response_text) return response 1.3 機能の作成 最後に、それぞれのエンドポイントで呼び出される処理を記述します。 functions/index_operation.pyにインデックス登録の処理を、functions/search_operation.pyに問い合わせの処理を実装しました。functions/ api _handling.pyでは、使用するmodel（gpt-3.5-turbo）の設定を行っています。 ここで、インデックス登録はドキュメントをあらかじめベクトルにしておき、問い合わせが来た際に検索するために行います。 今回の実装では、フォルダ内の CSV /PDF/TXTファイルについて読み込みベクトル化できるようにしました。 ※データの大きさや権限によってエラーが発生する可能性はありますが、今回そのエラーハンドリングまでは行っていません。 functions/api_handling.py（クリックで表示） from llama_index import LLMPredictor, ServiceContext, PromptHelper from langchain.chat_models import ChatOpenAI def get_service_context (): llm_predictor = LLMPredictor( llm=ChatOpenAI( temperature= 0 , model_name= "gpt-3.5-turbo" , max_tokens= 512 ) ) prompt_helper = PromptHelper( max_input_size= 4096 , num_output= 256 , max_chunk_overlap= 20 ) service_context = ServiceContext.from_defaults(llm_predictor=llm_predictor, prompt_helper=prompt_helper) return service_context functions/index_operation.py（クリックで表示） from llama_index import GPTVectorStoreIndex, SimpleDirectoryReader, download_loader from functions.api_handling import get_service_context import glob def create_index (dir_name: str ): input_dir = f 'data/{dir_name}' service_context = get_service_context() index = None all_files = glob.glob(f '{input_dir}/*' ) for file in all_files: if file .endswith( '.csv' ): Reader = download_loader( "SimpleCSVReader" ) loader = Reader() docs = loader.load_data( file = file ) if file .endswith( '.pdf' ): Reader = download_loader( "CJKPDFReader" ) loader = Reader() docs = loader.load_data( file = file ) if file .endswith( '.txt' ): loader = SimpleDirectoryReader(input_files=[ file ], required_exts=[ 'txt' ]) docs = loader.load_data() if index is None : index = GPTVectorStoreIndex.from_documents( docs, service_context=service_context ) else : for doc in docs: index.insert(doc) # indexを保存する if index: index.storage_context.persist(f "index/{dir_name}" ) return index functions/search_operation.py（クリックで表示） from llama_index import StorageContext, load_index_from_storage from functions.api_handling import get_service_context def load_index (dir_name: str ): \ # インデックスの読み込み storage_context = StorageContext.from_defaults(persist_dir=f "index/{dir_name}" ) index = load_index_from_storage(storage_context, service_context=get_service_context()) return index def search (dir_name: str , query: str ): index = load_index(dir_name) \ # クエリエンジンの作成 query_engine = index.as_query_engine() text_query = f '下記の質問に対して、敬語で簡潔に答えてください。 \n {query}' response = query_engine.query(text_query) return response.response 1.4 動作確認（データ登録） 上記のコードを記述後、動作確認を実施します。 アプリを立ち上げ後、以下のURLにアクセスすることでSwagger UI（下図）が表示され、直接動作確認をすることができます。 http://localhost:8000/docs/ まずはデータを登録してみましょう。 dataフォルダ下に新しいフォルダを作成します。ここでは、「BookInfo」というフォルダを作成しました。 なお、検索時にもこのフォルダ名を使用します。 ※ フォルダ名をもとにした管理やリク エス トは少し危険ですが、今回は簡単な検証のため実装を簡略化しています。 フォルダ作成後、「BookInfo」フォルダ内に CSV /PDF/TXTファイルを格納します。 今回は自作のsample.txtを格納しました。ファイルの中身は下記のようになっています。 格納後、 http://localhost:8000/docs/ にアクセスし、/indexから下記のようにインデックス登録を実行します。 indexフォルダ下に同名のフォルダが作成されます。 下記の3種類の json ファイルが入っていれば正常にインデックスが登録できています。 1.5 動作確認（検索） 検索についても動作確認してみます。 http://localhost:8000/docs/ にアクセスし、/searchを下記のように実行してみます。 少しするとResponseが返ってきます。登録した文章の情報を基に答えられており、動作が確認できました。 複数インデックスを登録した場合はdir_nameのパラメータを変えることで、検索対象を変えて回答させることができます。 手順②. オブジェクトの準備 次に、UE上で使用するオブジェクトの準備を行っていきます。本手順は岡崎が説明します。 ここでは以下の機能や画面を作成します。 チャット可能な範囲に入ったとき、アイコンを表示する機能 オブジェクト（Actor）をクリックしてチャット画面を表示する機能 それでは各機能について説明していきます。 2.1 チャット可能な範囲に入ったとき、アイコンを表示する機能 今回はゲームでよくあるような、プレイヤーがオブジェクトに一定の距離近づくと、「ここにアイテムがあります」という意味のアイコンが表示される処理の作成。 また、さらに近づくと「アイテムにクリックできます」という意味のアイコンに変更し、アイテムがクリックできるようになる処理を作っていきます。 まずはプレイヤーがオブジェクトに近づいたことを判定する処理を作成します。 以前 こちらの記事（UE5でコリジョン（衝突）判定機能を使って色々な機能を作成してみた） でも紹介しましたが、 コリジョン 機能を使っていきます。 まずはアクターブループリントを作成し「BP_P_Item」と 命名 します。 コンポーネント 追加から、「 Sphere Collision」を2つ追加し、それぞれ「BigSphere」と「SmallSphere」とします。 この2つの コリジョン は、「BigSphere」にプレイヤーが入った時、アイテムの上にアイコンを表示し、「SmallSphere」に入った時、アイコンを変更してアイテムをクリックできる状態に変更するために使用します。 上記を再現するため、「BigSphere」を大きく作成し、その中に「SmallSphere」を配置しています。 次にアイテムの上に表示するアイコンを作成します。 ユーザーインターフェース から ウィジェット ブループリントを作成し、「WBP_ItemIcon」と 命名 します。 作成後、下記画像のようにアイコンの ウィジェット を作成し、「Is Variable」にチェックを入れておきます。 次に コリジョン 用のブループリント（BP_P_Item）に戻り、「SmallSphere」の下に「Static Mesh」と「 Widget 」の コンポーネント を追加します。 画像では Widget の名前をWidgetItemIconに変更しています。 「 Widget 」の コンポーネント の詳細タブより、「 Widget Class」を先ほど作成した ウィジェット ブループリントの名前（WBP_ItemIcon）に変更します。 また、同じ詳細タブより「 レンダリング 」内の「Visible」のチェックを外しておきます。 次にイベントグラフに移動し、「On Component Begin Overlap（BigSphere）」と「On Component End Overlap（BigSphere）」のノードを作成します。 このノードは、左側の コンポーネント 一覧から「BigSphere」を右クリックし、イベント追加から選ぶことができます。 下記画像のように、プレイヤーが「BigSphere」内に入った際に、デフォルトで見えない設定にしておいたアイコン ウィジェット の「Visibility」の値を変更し、画面上に レンダリング させる処理を作成します。 同様にプレイヤーが「BigSphere」からプレイヤーが出た際にアイコンを見えなくする処理も追加します。 ここまでで、下記のようにプレイヤーの位置によってアイコンが表示されたり、消したりする処理ができました。 続いてさらに近づいた際（SmallSphereに入った際）にアイコンの表示を変更する処理を作成します。 アイコン用のブループリント（WBP_ItemIcon）に戻り、アイコンを変更するための関数を「AreaEvent」という名前で作成します。 「AreaEvent」には引数として「IsInside」というBoolean値を設定しておきます。 下記画像のように「AreaEvent」から「IsInside」の値によってイメージ画像を変更するために「Set Brush from Texture」ノードを繋ぎます。 「選択する」ノードに、Falseの場合にはSmallSphereに入っていない時用の画像を設定し、Trueの場合はSmallSphereに入っている時用の画像を設定します。 （本プロジェクトの場合は下記画像の「arrow」と「circle」を使用） 「Set Brush from Texture」のターゲットには ウィジェット ブループリントでimageを作成した際に 命名 した名前の変数が左側のタブに追加されているのでそれを使用します。 次に コリジョン 用のブループリント（BP_P_Item）に戻り、「SmallSphere」に入った際にアイコン ウィジェット の画像を変えるために「AreaEvent」の関数を使用する処理を作成します。 「SmallSphere」から「On Component Begin Overlap（SmallSphere）」と「On Component End Overlap（SmallSphere）」のノードを作成します。 下記画像のように「On Component Begin Overlap（SmallSphere）」と「On Component End Overlap（SmallSphere）」を「Area Event」繋げます。 「Area Event」の引数としてプレイヤーが「SmallSphere」の内部にいるかどうかの値を変数にして「In Small Collision Area」とします。 （後述の処理で使用するため変数にしておきます。） ここまでの処理で「BigSphere」の内部にいる時に矢印のアイコンを出現させ、「SmallSphere」の内部にいる時に二重丸のアイコンに変更させる処理ができました。 2.2 オブジェクト（Actor）をクリックしてチャット画面を表示する機能 続いて実際にオブジェクトを配置し、「SmallSphere」の内部にプレイヤーがいる時のみオブジェクトにクリックができる機能と、クリックした後にチャット画面を表示する機能を作成します。 まず初めに、プレイ画面上にマウスカーソルを出現させ、クリックを有効にするために、レベルブループリントを開きます。下の画像のように「イベントBeginPlay」に「Show Mouse Cursor」と「Enable Click Events」の設定をどちらもオンに変更します。 これでプレイ画面上にマウスカーソルを出現させ、クリックができるように設定されました。 次に、先ほど作成した コリジョン 用のブループリント（BP_P_Item）から子ブループリントを作成します。 親のブループリント上で右クリックを行い、「子ブループリントクラスを作成します」ボタンを押し「BP_C_Item_Book」と 命名 します。 子ブループリントを開き、親ブループリント作成時は特に編集しなかった「Static Mesh」に任意のメッシュ素材を選びます。 今回は「Quixel Bridge」内のメッシュを使用しました。 こちらの記事（Unreal Engine 5 を使ってワールドの地形を作成してみました） で、「Quixel Bridge」の使用方法を紹介しています。 イベントグラフを開き、「イベント ActorOnClicked」のノードを追加します。 「In Small Collision Area」の値からIF文を作成し、プレイヤーが「Small Collision」の中にいる場合のみチャット画面用の ウィジェット を作成するために「 ウィジェット を作成」ノードを繋げ、「Add Viewport」を付けます。 ここでチャット画面用の ウィジェット ブループリントを作成します。 （チャット機能の詳細は後述するので、ここでは大枠だけ作成します。） クリックしたいオブジェクト用（今回は本のオブジェクト）の ウィジェット ブループリントを作成し、「WBP_BookInfo」と 命名 します。 「 Canvas Panel」内に、本のタイトルや、サムネイル用画像を置き、チャット用のスペースも確保します。 こちらの記事（UE5でコリジョン（衝突）判定機能を使って色々な機能を作成してみた） で、 ウィジェット の作成方法について触れているので参考にしてください。 今回は閉じるボタン（×マーク）を押すことで ウィジェット を閉じる挙動にしたいので、「 Canvas Panel」内に、ボタンも追加します。 パレット追加欄に「Button」と検索し、ボタン内部に「Text」で「×」を記述し閉じるボタンを作成しました。 （ボタンの名前を「CloseButton」に変更してあります。） 階層タブより「CloseButton」を選択中に、詳細タブ内のイベント＞On Click の追加ボタンを押し、イベントグラフに「On Click（CloseButton）」ノードを追加します。 「On Click（CloseButton）」ノードに「Remove from Parent」を繋ぎ、閉じるボタンが押された時チャット画面用の ウィジェット が閉じるようにします。 「BP_C_Item_Book」を再び開き、「 ウィジェット を作成」ノードの「Class」を今作成した「WBP_BookInfo」に変更します。 これで画面上の本のオブジェクトをクリックした際に、画面上にチャット画面の ウィジェット が現れ、閉じるボタンで閉じる処理ができました。 ただこのままだと、本のオブジェクトをクリックした分だけ ウィジェット が開いてしまうので、現在 ウィジェット が開かれている状態かどうかを判別するために「IsOpenDetailWidget」という変数を作成し、下記画像のようにフラグとして使用します。 「WBP_BookInfo」でチャット画面を閉じた後で「IsOpenDetailWidget」の変数をFalseに戻しておきます。 ここまでで、オブジェクト（Actor）をクリックしてチャット画面を表示する機能が完成しました。 手順③. チャットUIの実装 ここまでで、ベースとなるUEのオブジェクトやUI、外部 API の作成が完了しました。 以降の手順は若本が説明します。 本手順では、GPTのリク エス トとのやり取りに必要になる追加のUIを用意していきます。 3.1 チャットのページUIを実装 次に、チャットのやり取りを行うためのUIを作成します。 チャットの 吹き出し は動的に追加されていくため、ここでは必要な コンポーネント のみ用意します。 まずはチャット画面のベースとして、手順②で作成した「WBP_BookInfo」にText_box、button、scroll boxを追加します。 Text_boxとscroll boxをわかりやすい変数名に変更しておきます。 また、呼び出すために「Is Variable」にチェックを入れておきます。 次に、buttonにOnClickイベントを追加します。 詳細画面のOnClickを押すことで、OnClickイベントが有効になります。こちらを押しておきましょう。 詳細な処理は後の手順で作成します。 また、ここでItemの属性値を設定しておきます。 属性値を用いて後段でGPTに問い合わせる際の検索対象を変更するため、その下準備となります。 まずは Widget の「WBP_BookInfo」に変数「WidgetAttributes」を作成します。 次に、「BP_C_ItemBook」クラスに属性値を設定しておきます。ここでは変数名を「ItemAttributes」、デフォルト値を「BookInfo」としました。 最後に、「BP_C_ItemBook」のブループリント上で、 ウィジェット の作成時に自身の持つ「ItemAttributes」を「WidgetAttributes」にセットする処理を追加します。これで完成です。 3.2 チャットの 吹き出し UIを実装 3.1でやりとりを行う画面は作成しましたが、メッセージを入れるための 吹き出し がありません。 そこで、別途チャットの 吹き出し 用UI（自分用/GPT用）を作成します。 それぞれ ユーザーインターフェース から ウィジェット ブループリントを作成しましょう。 作成後、 Canvas PanelとText Box(Multi-Line)を配置します。 こちらもText Boxはわかりやすい変数名に変更し、「Is Variable」にチェックを入れておきます。 3.2.1 自分のチャットを表示する 自分用の 吹き出し は下記のように設定しました。背景色とFontの色/サイズを調整しています。 3.2.2 GPTの返信を表示する GPT用の 吹き出し も同様に作成します。 手順④. HTTPリク エス ト用の C++ クラス作成 4.1 C++ クラスを作成 Unreal Engine では、デフォルトでHTTPへのリク エス トを送信するクラスは用意されていないため、 API にリク エス トを送り、レスポンスを受け取るクラスを新規作成する必要があります。 ブループリントでは実現できないため、今回は C++ で実装することとしました。 まずは、ツールから新規の C++ クラスを作成します。 ここで、親クラスは「Actor」、名前は「HTTPActor」としました。 クラスを作成すると、エディタに飛ばされます。エディタ上でクラスを編集していきます。 4.2 C++ クラスを編集 API にリク エス トを送り、レスポンスを受け取るための処理を追加していきます。 まずは、Build.csのDependencyModuleに"HTTP", " Json ", "JsonUtilities"の3つを追加します。 Build.cs（クリックで表示） // Fill out your copyright notice in the Description page of Project Settings. using UnrealBuildTool; public class TechBlog9 : ModuleRules { public TechBlog9(ReadOnlyTargetRules Target) : base(Target) { PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs; PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "HTTP", "Json", "JsonUtilities" }); PrivateDependencyModuleNames.AddRange(new string[] { }); // Uncomment if you are using Slate UI // PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" }); // Uncomment if you are using online features // PrivateDependencyModuleNames.Add("OnlineSubsystem"); // To include OnlineSubsystemSteam, add it to the plugins section in your uproject file with the Enabled attribute set to true } } また、Engine.iniの末尾にHTTPリク エス トの設定を記載しておきます。 Engine.ini（クリックで表示） [HTTP] HttpTimeout=60 HttpConnectionTimeout=5 HttpReceiveTimeout=-1 HttpSendTimeout=-1 HttpMaxConnectionsPerServer=32 bEnableHttp=true bUseNullHttp=false HttpDelayTime=0.1 上記が終わったら、HTTPActor.hクラスを変更します。 筆者はEpicのcommunityを参考に#include "CoreMinimal.h"を コメントアウト しました。 後ほどブループリント上で呼び出すため、HTTPリク エス トを実行するHttpMethodはUFUNCTIONを、結果を格納する変数である outputStringにはUPROPERTYを設定しておきます。 HTTPActor.h（クリックで表示） // Fill out your copyright notice in the Description page of Project Settings. #pragma once // #include "CoreMinimal.h" #include "GameFramework/Actor.h" #include "Http.h" #include "HTTPActor.generated.h" UCLASS() class TECHBLOG9_API AHTTPActor : public AActor { GENERATED_BODY() public: // Sets default values for this actor's properties AHTTPActor(); protected: // Called when the game starts or when spawned virtual void BeginPlay() override; public: // Called every frame virtual void Tick(float DeltaTime) override; FHttpModule* Http; UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Default) FString outputString; // HTTP通信 UFUNCTION(BlueprintCallable, Category = "Http") void HttpMethod(FString query, FString dir_name); // レスポンス後のイベント処理 void OnResponseReceived(FHttpRequestPtr Request, FHttpResponsePtr Response, bool bWasSuccessful); }; 最後に、HTTPActor.cppに具体的な処理内容を記述します。 手順①で実装した API の仕様に合わせ、dir_name（インデックスのフォルダ名）とquery（質問）の2つを引数としてHTTPリク エス トを送り、返ってきた Json の「text」をoutputStringに格納する処理を追加しました。 HTTPActor.cpp（クリックで表示） // Fill out your copyright notice in the Description page of Project Settings. #include "HTTPActor.h" // Sets default values AHTTPActor::AHTTPActor() { // Set this actor to call Tick() every frame. You can turn this off to improve performance if you don't need it. PrimaryActorTick.bCanEverTick = true; Http = &FHttpModule::Get(); } // Called when the game starts or when spawned void AHTTPActor::BeginPlay() { Super::BeginPlay(); } // Called every frame void AHTTPActor::Tick(float DeltaTime) { Super::Tick(DeltaTime); } void AHTTPActor::HttpMethod(FString query, FString dir_name) { // Jsonデータ作成 TSharedPtr<FJsonObject> JsonObject = MakeShareable(new FJsonObject); JsonObject->SetStringField("dir_name", dir_name); JsonObject->SetStringField("query", query); // OutputStringに Json 格納 FString OutputString; TSharedRef<TJsonWriter > JsonWriter = TJsonWriterFactory<>::Create(&OutputString); FJsonSerializer::Serialize(JsonObject.ToSharedRef(), JsonWriter); // HTTPリク エス ト TSharedRef Request = Http->CreateRequest(); Request->OnProcessRequestComplete().BindUObject(this, &AHTTPActor::OnResponseReceived); Request->SetURL(" http://localhost:8000/search "); Request->SetVerb("POST"); Request->SetHeader(TEXT("User-Agent"), "X-UnrealEngine-Agent"); Request->SetHeader("Content-Type", TEXT("application/ json ")); Request->SetContentAsString(OutputString); Request->ProcessRequest(); } void AHTTPActor::OnResponseReceived(FHttpRequestPtr Request, FHttpResponsePtr Response, bool bWasSuccessful) { TSharedPtr<FJsonObject> JsonObject; TSharedRef<TJsonReader<>> Reader = TJsonReaderFactory<>::Create(Response->GetContentAsString()); if (FJsonSerializer::Deserialize(Reader, JsonObject)) { // Json からtextを抽出 outputString = JsonObject->GetStringField("text"); } } 上記の変更が終わったらbuildします。 筆者は VS Code で編集していたため、Launch＜project_name＞Editor(development)でbuildしました。 Unreal Engine が起動され、projectが表示されれば C++ クラスの作成は完了です。 4.3 作成したクラスをブループリント化 最後に、作成した C++ クラスをブループリントから呼び出すため、Blueprintクラスを作成します。 名前は「BP_HTTPActor」としました。 作成した「BP_HTTPActor」をワールドに配置すれば完了です。 手順⑤. 質問送信時の処理を実装 ここまででオブジェクトの準備、GPTの準備、UIの準備が全て終わりました。 最後に、Brueprint上ですべてを繋ぎこむ処理を「BP_C_Item_Book」のブループリント上で実装します。 以下が本手順で作成したブループリントの全体像です。 長くて見づらいため、それぞれ分けて解説します。（見やすさのため、拡大時にレイアウトを調整しています） 3.1で作成したOnclickイベント（チャットの送信ボタン押下）を起点としてブループリントを作成しました。 5.1 「送信」ボタンが押されたとき、送信した内容を表示する 送信ボタンが押下されると、TextBoxの値を取得して新しい 吹き出し として表示します。 ここでは、3.2.1で作成した自分用の 吹き出し を作成し、TextBoxの値を入れてScroll Boxの中に入れています。 5.2 HTTPリク エス トを送信する 4.3で配置した「BP_HTTPActor」クラスを呼び出し、HTTPMethodを実行します。ユーザーの入力と ウィジェット の持つ変数「WidgetAttributes」の値をGPTの API 側へリク エス トとして送信しています。 このとき、outputStringの変数にGPTのレスポンスが格納されるまでは、Delayとloopを使用してwaitします。 また、HTTPリク エス トを送った後、自身が入力したテキストをクリアする処理を記述しました。 5.3 GPTの返信内容を表示する 5.1と同様、今度はGPT用の 吹き出し を作成し、outputStringの値を入れてScroll Boxの中に格納します。 最後に、outputStringの変数をクリアすれば処理は完了です。 デモ動画 本のオブジェクトに近づくことでタッチが可能になり、タッチすることでUIが表示されます。 さらにUI上で問い合わせると、オブジェクトの関連文章を基に回答できていることを確認できます。 これまでの実装により、ストレスの少ない問い合わせをUE上で実現することができました。 おわりに 今回はチャットUIを用いた、オブジェクトに対する問い合わせを実装しました。 以下、実装を担当した岡崎と若本のそれぞれの所感となります。 岡崎：今回の実装で、ブループリントでのチェンジイベント（オンクリックなど）や、 コリジョン イベントに関する使用方法の基礎的な学習を行えました。今後プロダクトを作成する際、プレイヤー起因で任意の情報を出したり、プレイヤー情報を変更させるといった機能を作成する際に、数多く使うことになる機能を作成することができたため、より応用的な使い方など引き続き調査したいと思います。 若本：UE初学者であり、今回広く Python の実装/ブループリントの実装/ C++ の実装を行いましたが、慣れて以降はストレスレスに開発を行うことができました。今回の実装を発展させ、非同期処理の実装や会話履歴の入れ込み、UIのリッチ化など、さらに作りこむことによってよりよいユーザー体験が得られることが期待できると感じました。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 執筆： @wakamoto.ryosuke 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは、金融ソリューション事業部の岡崎、若本です。 3DCG空間では、オブジェクトに関する情報を過度に表示し過ぎることはユーザー体験を阻害する要因になります。その一方で、あまりに情報が少ないと世界観の欠如に繋がります。そのため、質問応答などのユーザーが求める情報を必要なだけ表示する仕組みが求められることがあります。 そこで今回は、 Unreal Engine （UE）上のオブジェクトの情報についてChatGPTに問い合わせる実装を行ってみたいと思います。 下図のように、あらかじめ 格納した関連文献を基に、UE上でObjectに対する質問をChatGPTに答えさせる ことがゴールです。 準備するもの 処理概要 手順①. GPTを用いたAPIを作成 1.1 APIの環境構築 1.2 エンドポイントの作成 1.3 機能の作成 1.4 動作確認（データ登録） 1.5 動作確認（検索） 手順②. オブジェクトの準備 2.1 チャット可能な範囲に入ったとき、アイコンを表示する機能 2.2 オブジェクト（Actor）をクリックしてチャット画面を表示する機能 手順③. チャットUIの実装 3.1 チャットのページUIを実装 3.2 チャットの吹き出しUIを実装 3.2.1 自分のチャットを表示する 3.2.2 GPTの返信を表示する 手順④. HTTPリクエスト用のC++クラス作成 4.1 C++クラスを作成 4.2 C++クラスを編集 4.3 作成したクラスをブループリント化 手順⑤. 質問送信時の処理を実装 5.1 「送信」ボタンが押されたとき、送信した内容を表示する 5.2 HTTPリクエストを送信する 5.3 GPTの返信内容を表示する デモ動画 おわりに 準備するもの Unreal Engine 5.2.0 OpenAI API GPT-3.5-turbo（0301）を使用します。 事前にユーザー登録と、 API キーの発行を実施しておきます。 FastAPI API として、下記の機能を作成します。 オブジェクトに関連したドキュメントを登録する オブジェクト名と質問を与え、答えを返す Docker API の環境構築に使用します。 処理概要 下記の処理を実装します。 それぞれの機能について、（）内の担当者が作業を行いました。 コリジョン 判定（岡崎） チャット可能な範囲に入ったとき、アイコンを表示します。 チャットUIの表示（岡崎、若本） コリジョン 状態でオブジェクト（Actor）をクリックし、チャット画面を表示します。 GPTへのリク エス ト（若本） UE上の情報を基に、GPTにリク エス トを送ります。 結果の表示（若本） API から返ってきたレスポンスをUIに反映します。 以降では、各機能の概要や実装について説明します。 手順①. GPTを用いた API を作成 本手順は若本が説明します。 GPTはUE内のオブジェクトについて情報を持たないため、そのままChatGPTに問い合わせても的確に質問に答えることができません。 そこで、以下の2つの機能を持つ API を作成します。今回は Unreal Engine を実行するPC上で構築することとしました。 オブジェクトに関連したドキュメントを登録する（インデックス登録） オブジェクト名と質問を与え、答えを返す（問い合わせ） それぞれの機能についてエンドポイントを用意し、HTTPリク エス トで実行できるようにします。 最終的には下記のようなファイル構成となります。 1.1 API の環境構築 まずはDockerで API のベースとなる環境を作成します。 以下は最終的に使用したDockerの設定ファイルです。 フォルダ上でdocker containerをupするとアプリケーションが起動します（ http://localhost:8000/docs/ からアクセスすることができます）。 docker-compose.yml（クリックで表示） version: '3' services: backend: container_name: gpt-api build: context: . dockerfile: ./Dockerfile volumes: \- type: bind source: './api' target: '/src' ports: \- 8000:8000 stdin_open: true Dockerfile（クリックで表示） FROM python:3.8-slim-buster RUN pip install --upgrade pip RUN pip install --upgrade setuptools COPY requirements.txt / RUN pip install -r requirements.txt WORKDIR /src CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--reload"] requirements.txt（クリックで表示） numpy openai transformers llama_index langchain fastapi uvicorn[standard] pandas 1.2 エンドポイントの作成 次に、 API が持つ2つの機能についてエンドポイントを作成していきます。 routers/index.pyにインデックス登録のエンドポイントを、routers/search.pyに問い合わせ用のエンドポイントを記述しています。 main.py（クリックで表示） from fastapi import FastAPI from routers import search, index import os os.environ[ 'OPENAI_API_KEY' ] = 'YOUR_OPENAI_API_TOKEN' app = FastAPI() app.include_router(search.router) app.include_router(index.router) routers/index.py（クリックで表示） from fastapi import APIRouter from functions.index_operation import create_index router = APIRouter() @ router.post ( "/index" ) def service_create_index (dir_name: str ): _ = create_index(dir_name) return 200 routers/search.py（クリックで表示） from fastapi import APIRouter from pydantic import BaseModel from functions.search_operation import search router = APIRouter() class SearchRequestItem (BaseModel): dir_name: str = None query: str = None class SearchResponseItem (BaseModel): text: str = None @ router.post ( "/search" ) def service_search (item: SearchRequestItem) -> SearchResponseItem: response_text = search(item.dir_name, item.query) response = SearchResponseItem(text=response_text) return response 1.3 機能の作成 最後に、それぞれのエンドポイントで呼び出される処理を記述します。 functions/index_operation.pyにインデックス登録の処理を、functions/search_operation.pyに問い合わせの処理を実装しました。functions/ api _handling.pyでは、使用するmodel（gpt-3.5-turbo）の設定を行っています。 ここで、インデックス登録はドキュメントをあらかじめベクトルにしておき、問い合わせが来た際に検索するために行います。 今回の実装では、フォルダ内の CSV /PDF/TXTファイルについて読み込みベクトル化できるようにしました。 ※データの大きさや権限によってエラーが発生する可能性はありますが、今回そのエラーハンドリングまでは行っていません。 functions/api_handling.py（クリックで表示） from llama_index import LLMPredictor, ServiceContext, PromptHelper from langchain.chat_models import ChatOpenAI def get_service_context (): llm_predictor = LLMPredictor( llm=ChatOpenAI( temperature= 0 , model_name= "gpt-3.5-turbo" , max_tokens= 512 ) ) prompt_helper = PromptHelper( max_input_size= 4096 , num_output= 256 , max_chunk_overlap= 20 ) service_context = ServiceContext.from_defaults(llm_predictor=llm_predictor, prompt_helper=prompt_helper) return service_context functions/index_operation.py（クリックで表示） from llama_index import GPTVectorStoreIndex, SimpleDirectoryReader, download_loader from functions.api_handling import get_service_context import glob def create_index (dir_name: str ): input_dir = f 'data/{dir_name}' service_context = get_service_context() index = None all_files = glob.glob(f '{input_dir}/*' ) for file in all_files: if file .endswith( '.csv' ): Reader = download_loader( "SimpleCSVReader" ) loader = Reader() docs = loader.load_data( file = file ) if file .endswith( '.pdf' ): Reader = download_loader( "CJKPDFReader" ) loader = Reader() docs = loader.load_data( file = file ) if file .endswith( '.txt' ): loader = SimpleDirectoryReader(input_files=[ file ], required_exts=[ 'txt' ]) docs = loader.load_data() if index is None : index = GPTVectorStoreIndex.from_documents( docs, service_context=service_context ) else : for doc in docs: index.insert(doc) # indexを保存する if index: index.storage_context.persist(f "index/{dir_name}" ) return index functions/search_operation.py（クリックで表示） from llama_index import StorageContext, load_index_from_storage from functions.api_handling import get_service_context def load_index (dir_name: str ): \ # インデックスの読み込み storage_context = StorageContext.from_defaults(persist_dir=f "index/{dir_name}" ) index = load_index_from_storage(storage_context, service_context=get_service_context()) return index def search (dir_name: str , query: str ): index = load_index(dir_name) \ # クエリエンジンの作成 query_engine = index.as_query_engine() text_query = f '下記の質問に対して、敬語で簡潔に答えてください。 \n {query}' response = query_engine.query(text_query) return response.response 1.4 動作確認（データ登録） 上記のコードを記述後、動作確認を実施します。 アプリを立ち上げ後、以下のURLにアクセスすることでSwagger UI（下図）が表示され、直接動作確認をすることができます。 http://localhost:8000/docs/ まずはデータを登録してみましょう。 dataフォルダ下に新しいフォルダを作成します。ここでは、「BookInfo」というフォルダを作成しました。 なお、検索時にもこのフォルダ名を使用します。 ※ フォルダ名をもとにした管理やリク エス トは少し危険ですが、今回は簡単な検証のため実装を簡略化しています。 フォルダ作成後、「BookInfo」フォルダ内に CSV /PDF/TXTファイルを格納します。 今回は自作のsample.txtを格納しました。ファイルの中身は下記のようになっています。 格納後、 http://localhost:8000/docs/ にアクセスし、/indexから下記のようにインデックス登録を実行します。 indexフォルダ下に同名のフォルダが作成されます。 下記の3種類の json ファイルが入っていれば正常にインデックスが登録できています。 1.5 動作確認（検索） 検索についても動作確認してみます。 http://localhost:8000/docs/ にアクセスし、/searchを下記のように実行してみます。 少しするとResponseが返ってきます。登録した文章の情報を基に答えられており、動作が確認できました。 複数インデックスを登録した場合はdir_nameのパラメータを変えることで、検索対象を変えて回答させることができます。 手順②. オブジェクトの準備 次に、UE上で使用するオブジェクトの準備を行っていきます。本手順は岡崎が説明します。 ここでは以下の機能や画面を作成します。 チャット可能な範囲に入ったとき、アイコンを表示する機能 オブジェクト（Actor）をクリックしてチャット画面を表示する機能 それでは各機能について説明していきます。 2.1 チャット可能な範囲に入ったとき、アイコンを表示する機能 今回はゲームでよくあるような、プレイヤーがオブジェクトに一定の距離近づくと、「ここにアイテムがあります」という意味のアイコンが表示される処理の作成。 また、さらに近づくと「アイテムにクリックできます」という意味のアイコンに変更し、アイテムがクリックできるようになる処理を作っていきます。 まずはプレイヤーがオブジェクトに近づいたことを判定する処理を作成します。 以前 こちらの記事（UE5でコリジョン（衝突）判定機能を使って色々な機能を作成してみた） でも紹介しましたが、 コリジョン 機能を使っていきます。 まずはアクターブループリントを作成し「BP_P_Item」と 命名 します。 コンポーネント 追加から、「 Sphere Collision」を2つ追加し、それぞれ「BigSphere」と「SmallSphere」とします。 この2つの コリジョン は、「BigSphere」にプレイヤーが入った時、アイテムの上にアイコンを表示し、「SmallSphere」に入った時、アイコンを変更してアイテムをクリックできる状態に変更するために使用します。 上記を再現するため、「BigSphere」を大きく作成し、その中に「SmallSphere」を配置しています。 次にアイテムの上に表示するアイコンを作成します。 ユーザーインターフェース から ウィジェット ブループリントを作成し、「WBP_ItemIcon」と 命名 します。 作成後、下記画像のようにアイコンの ウィジェット を作成し、「Is Variable」にチェックを入れておきます。 次に コリジョン 用のブループリント（BP_P_Item）に戻り、「SmallSphere」の下に「Static Mesh」と「 Widget 」の コンポーネント を追加します。 画像では Widget の名前をWidgetItemIconに変更しています。 「 Widget 」の コンポーネント の詳細タブより、「 Widget Class」を先ほど作成した ウィジェット ブループリントの名前（WBP_ItemIcon）に変更します。 また、同じ詳細タブより「 レンダリング 」内の「Visible」のチェックを外しておきます。 次にイベントグラフに移動し、「On Component Begin Overlap（BigSphere）」と「On Component End Overlap（BigSphere）」のノードを作成します。 このノードは、左側の コンポーネント 一覧から「BigSphere」を右クリックし、イベント追加から選ぶことができます。 下記画像のように、プレイヤーが「BigSphere」内に入った際に、デフォルトで見えない設定にしておいたアイコン ウィジェット の「Visibility」の値を変更し、画面上に レンダリング させる処理を作成します。 同様にプレイヤーが「BigSphere」からプレイヤーが出た際にアイコンを見えなくする処理も追加します。 ここまでで、下記のようにプレイヤーの位置によってアイコンが表示されたり、消したりする処理ができました。 続いてさらに近づいた際（SmallSphereに入った際）にアイコンの表示を変更する処理を作成します。 アイコン用のブループリント（WBP_ItemIcon）に戻り、アイコンを変更するための関数を「AreaEvent」という名前で作成します。 「AreaEvent」には引数として「IsInside」というBoolean値を設定しておきます。 下記画像のように「AreaEvent」から「IsInside」の値によってイメージ画像を変更するために「Set Brush from Texture」ノードを繋ぎます。 「選択する」ノードに、Falseの場合にはSmallSphereに入っていない時用の画像を設定し、Trueの場合はSmallSphereに入っている時用の画像を設定します。 （本プロジェクトの場合は下記画像の「arrow」と「circle」を使用） 「Set Brush from Texture」のターゲットには ウィジェット ブループリントでimageを作成した際に 命名 した名前の変数が左側のタブに追加されているのでそれを使用します。 次に コリジョン 用のブループリント（BP_P_Item）に戻り、「SmallSphere」に入った際にアイコン ウィジェット の画像を変えるために「AreaEvent」の関数を使用する処理を作成します。 「SmallSphere」から「On Component Begin Overlap（SmallSphere）」と「On Component End Overlap（SmallSphere）」のノードを作成します。 下記画像のように「On Component Begin Overlap（SmallSphere）」と「On Component End Overlap（SmallSphere）」を「Area Event」繋げます。 「Area Event」の引数としてプレイヤーが「SmallSphere」の内部にいるかどうかの値を変数にして「In Small Collision Area」とします。 （後述の処理で使用するため変数にしておきます。） ここまでの処理で「BigSphere」の内部にいる時に矢印のアイコンを出現させ、「SmallSphere」の内部にいる時に二重丸のアイコンに変更させる処理ができました。 2.2 オブジェクト（Actor）をクリックしてチャット画面を表示する機能 続いて実際にオブジェクトを配置し、「SmallSphere」の内部にプレイヤーがいる時のみオブジェクトにクリックができる機能と、クリックした後にチャット画面を表示する機能を作成します。 まず初めに、プレイ画面上にマウスカーソルを出現させ、クリックを有効にするために、レベルブループリントを開きます。下の画像のように「イベントBeginPlay」に「Show Mouse Cursor」と「Enable Click Events」の設定をどちらもオンに変更します。 これでプレイ画面上にマウスカーソルを出現させ、クリックができるように設定されました。 次に、先ほど作成した コリジョン 用のブループリント（BP_P_Item）から子ブループリントを作成します。 親のブループリント上で右クリックを行い、「子ブループリントクラスを作成します」ボタンを押し「BP_C_Item_Book」と 命名 します。 子ブループリントを開き、親ブループリント作成時は特に編集しなかった「Static Mesh」に任意のメッシュ素材を選びます。 今回は「Quixel Bridge」内のメッシュを使用しました。 こちらの記事（Unreal Engine 5 を使ってワールドの地形を作成してみました） で、「Quixel Bridge」の使用方法を紹介しています。 イベントグラフを開き、「イベント ActorOnClicked」のノードを追加します。 「In Small Collision Area」の値からIF文を作成し、プレイヤーが「Small Collision」の中にいる場合のみチャット画面用の ウィジェット を作成するために「 ウィジェット を作成」ノードを繋げ、「Add Viewport」を付けます。 ここでチャット画面用の ウィジェット ブループリントを作成します。 （チャット機能の詳細は後述するので、ここでは大枠だけ作成します。） クリックしたいオブジェクト用（今回は本のオブジェクト）の ウィジェット ブループリントを作成し、「WBP_BookInfo」と 命名 します。 「 Canvas Panel」内に、本のタイトルや、サムネイル用画像を置き、チャット用のスペースも確保します。 こちらの記事（UE5でコリジョン（衝突）判定機能を使って色々な機能を作成してみた） で、 ウィジェット の作成方法について触れているので参考にしてください。 今回は閉じるボタン（×マーク）を押すことで ウィジェット を閉じる挙動にしたいので、「 Canvas Panel」内に、ボタンも追加します。 パレット追加欄に「Button」と検索し、ボタン内部に「Text」で「×」を記述し閉じるボタンを作成しました。 （ボタンの名前を「CloseButton」に変更してあります。） 階層タブより「CloseButton」を選択中に、詳細タブ内のイベント＞On Click の追加ボタンを押し、イベントグラフに「On Click（CloseButton）」ノードを追加します。 「On Click（CloseButton）」ノードに「Remove from Parent」を繋ぎ、閉じるボタンが押された時チャット画面用の ウィジェット が閉じるようにします。 「BP_C_Item_Book」を再び開き、「 ウィジェット を作成」ノードの「Class」を今作成した「WBP_BookInfo」に変更します。 これで画面上の本のオブジェクトをクリックした際に、画面上にチャット画面の ウィジェット が現れ、閉じるボタンで閉じる処理ができました。 ただこのままだと、本のオブジェクトをクリックした分だけ ウィジェット が開いてしまうので、現在 ウィジェット が開かれている状態かどうかを判別するために「IsOpenDetailWidget」という変数を作成し、下記画像のようにフラグとして使用します。 「WBP_BookInfo」でチャット画面を閉じた後で「IsOpenDetailWidget」の変数をFalseに戻しておきます。 ここまでで、オブジェクト（Actor）をクリックしてチャット画面を表示する機能が完成しました。 手順③. チャットUIの実装 ここまでで、ベースとなるUEのオブジェクトやUI、外部 API の作成が完了しました。 以降の手順は若本が説明します。 本手順では、GPTのリク エス トとのやり取りに必要になる追加のUIを用意していきます。 3.1 チャットのページUIを実装 次に、チャットのやり取りを行うためのUIを作成します。 チャットの 吹き出し は動的に追加されていくため、ここでは必要な コンポーネント のみ用意します。 まずはチャット画面のベースとして、手順②で作成した「WBP_BookInfo」にText_box、button、scroll boxを追加します。 Text_boxとscroll boxをわかりやすい変数名に変更しておきます。 また、呼び出すために「Is Variable」にチェックを入れておきます。 次に、buttonにOnClickイベントを追加します。 詳細画面のOnClickを押すことで、OnClickイベントが有効になります。こちらを押しておきましょう。 詳細な処理は後の手順で作成します。 また、ここでItemの属性値を設定しておきます。 属性値を用いて後段でGPTに問い合わせる際の検索対象を変更するため、その下準備となります。 まずは Widget の「WBP_BookInfo」に変数「WidgetAttributes」を作成します。 次に、「BP_C_ItemBook」クラスに属性値を設定しておきます。ここでは変数名を「ItemAttributes」、デフォルト値を「BookInfo」としました。 最後に、「BP_C_ItemBook」のブループリント上で、 ウィジェット の作成時に自身の持つ「ItemAttributes」を「WidgetAttributes」にセットする処理を追加します。これで完成です。 3.2 チャットの 吹き出し UIを実装 3.1でやりとりを行う画面は作成しましたが、メッセージを入れるための 吹き出し がありません。 そこで、別途チャットの 吹き出し 用UI（自分用/GPT用）を作成します。 それぞれ ユーザーインターフェース から ウィジェット ブループリントを作成しましょう。 作成後、 Canvas PanelとText Box(Multi-Line)を配置します。 こちらもText Boxはわかりやすい変数名に変更し、「Is Variable」にチェックを入れておきます。 3.2.1 自分のチャットを表示する 自分用の 吹き出し は下記のように設定しました。背景色とFontの色/サイズを調整しています。 3.2.2 GPTの返信を表示する GPT用の 吹き出し も同様に作成します。 手順④. HTTPリク エス ト用の C++ クラス作成 4.1 C++ クラスを作成 Unreal Engine では、デフォルトでHTTPへのリク エス トを送信するクラスは用意されていないため、 API にリク エス トを送り、レスポンスを受け取るクラスを新規作成する必要があります。 ブループリントでは実現できないため、今回は C++ で実装することとしました。 まずは、ツールから新規の C++ クラスを作成します。 ここで、親クラスは「Actor」、名前は「HTTPActor」としました。 クラスを作成すると、エディタに飛ばされます。エディタ上でクラスを編集していきます。 4.2 C++ クラスを編集 API にリク エス トを送り、レスポンスを受け取るための処理を追加していきます。 まずは、Build.csのDependencyModuleに"HTTP", " Json ", "JsonUtilities"の3つを追加します。 Build.cs（クリックで表示） // Fill out your copyright notice in the Description page of Project Settings. using UnrealBuildTool; public class TechBlog9 : ModuleRules { public TechBlog9(ReadOnlyTargetRules Target) : base(Target) { PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs; PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "HTTP", "Json", "JsonUtilities" }); PrivateDependencyModuleNames.AddRange(new string[] { }); // Uncomment if you are using Slate UI // PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" }); // Uncomment if you are using online features // PrivateDependencyModuleNames.Add("OnlineSubsystem"); // To include OnlineSubsystemSteam, add it to the plugins section in your uproject file with the Enabled attribute set to true } } また、Engine.iniの末尾にHTTPリク エス トの設定を記載しておきます。 Engine.ini（クリックで表示） [HTTP] HttpTimeout=60 HttpConnectionTimeout=5 HttpReceiveTimeout=-1 HttpSendTimeout=-1 HttpMaxConnectionsPerServer=32 bEnableHttp=true bUseNullHttp=false HttpDelayTime=0.1 上記が終わったら、HTTPActor.hクラスを変更します。 筆者はEpicのcommunityを参考に#include "CoreMinimal.h"を コメントアウト しました。 後ほどブループリント上で呼び出すため、HTTPリク エス トを実行するHttpMethodはUFUNCTIONを、結果を格納する変数である outputStringにはUPROPERTYを設定しておきます。 HTTPActor.h（クリックで表示） // Fill out your copyright notice in the Description page of Project Settings. #pragma once // #include "CoreMinimal.h" #include "GameFramework/Actor.h" #include "Http.h" #include "HTTPActor.generated.h" UCLASS() class TECHBLOG9_API AHTTPActor : public AActor { GENERATED_BODY() public: // Sets default values for this actor's properties AHTTPActor(); protected: // Called when the game starts or when spawned virtual void BeginPlay() override; public: // Called every frame virtual void Tick(float DeltaTime) override; FHttpModule* Http; UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Default) FString outputString; // HTTP通信 UFUNCTION(BlueprintCallable, Category = "Http") void HttpMethod(FString query, FString dir_name); // レスポンス後のイベント処理 void OnResponseReceived(FHttpRequestPtr Request, FHttpResponsePtr Response, bool bWasSuccessful); }; 最後に、HTTPActor.cppに具体的な処理内容を記述します。 手順①で実装した API の仕様に合わせ、dir_name（インデックスのフォルダ名）とquery（質問）の2つを引数としてHTTPリク エス トを送り、返ってきた Json の「text」をoutputStringに格納する処理を追加しました。 HTTPActor.cpp（クリックで表示） // Fill out your copyright notice in the Description page of Project Settings. #include "HTTPActor.h" // Sets default values AHTTPActor::AHTTPActor() { // Set this actor to call Tick() every frame. You can turn this off to improve performance if you don't need it. PrimaryActorTick.bCanEverTick = true; Http = &FHttpModule::Get(); } // Called when the game starts or when spawned void AHTTPActor::BeginPlay() { Super::BeginPlay(); } // Called every frame void AHTTPActor::Tick(float DeltaTime) { Super::Tick(DeltaTime); } void AHTTPActor::HttpMethod(FString query, FString dir_name) { // Jsonデータ作成 TSharedPtr<FJsonObject> JsonObject = MakeShareable(new FJsonObject); JsonObject->SetStringField("dir_name", dir_name); JsonObject->SetStringField("query", query); // OutputStringに Json 格納 FString OutputString; TSharedRef<TJsonWriter > JsonWriter = TJsonWriterFactory<>::Create(&OutputString); FJsonSerializer::Serialize(JsonObject.ToSharedRef(), JsonWriter); // HTTPリク エス ト TSharedRef Request = Http->CreateRequest(); Request->OnProcessRequestComplete().BindUObject(this, &AHTTPActor::OnResponseReceived); Request->SetURL(" http://localhost:8000/search "); Request->SetVerb("POST"); Request->SetHeader(TEXT("User-Agent"), "X-UnrealEngine-Agent"); Request->SetHeader("Content-Type", TEXT("application/ json ")); Request->SetContentAsString(OutputString); Request->ProcessRequest(); } void AHTTPActor::OnResponseReceived(FHttpRequestPtr Request, FHttpResponsePtr Response, bool bWasSuccessful) { TSharedPtr<FJsonObject> JsonObject; TSharedRef<TJsonReader<>> Reader = TJsonReaderFactory<>::Create(Response->GetContentAsString()); if (FJsonSerializer::Deserialize(Reader, JsonObject)) { // Json からtextを抽出 outputString = JsonObject->GetStringField("text"); } } 上記の変更が終わったらbuildします。 筆者は VS Code で編集していたため、Launch＜project_name＞Editor(development)でbuildしました。 Unreal Engine が起動され、projectが表示されれば C++ クラスの作成は完了です。 4.3 作成したクラスをブループリント化 最後に、作成した C++ クラスをブループリントから呼び出すため、Blueprintクラスを作成します。 名前は「BP_HTTPActor」としました。 作成した「BP_HTTPActor」をワールドに配置すれば完了です。 手順⑤. 質問送信時の処理を実装 ここまででオブジェクトの準備、GPTの準備、UIの準備が全て終わりました。 最後に、Brueprint上ですべてを繋ぎこむ処理を「BP_C_Item_Book」のブループリント上で実装します。 以下が本手順で作成したブループリントの全体像です。 長くて見づらいため、それぞれ分けて解説します。（見やすさのため、拡大時にレイアウトを調整しています） 3.1で作成したOnclickイベント（チャットの送信ボタン押下）を起点としてブループリントを作成しました。 5.1 「送信」ボタンが押されたとき、送信した内容を表示する 送信ボタンが押下されると、TextBoxの値を取得して新しい 吹き出し として表示します。 ここでは、3.2.1で作成した自分用の 吹き出し を作成し、TextBoxの値を入れてScroll Boxの中に入れています。 5.2 HTTPリク エス トを送信する 4.3で配置した「BP_HTTPActor」クラスを呼び出し、HTTPMethodを実行します。ユーザーの入力と ウィジェット の持つ変数「WidgetAttributes」の値をGPTの API 側へリク エス トとして送信しています。 このとき、outputStringの変数にGPTのレスポンスが格納されるまでは、Delayとloopを使用してwaitします。 また、HTTPリク エス トを送った後、自身が入力したテキストをクリアする処理を記述しました。 5.3 GPTの返信内容を表示する 5.1と同様、今度はGPT用の 吹き出し を作成し、outputStringの値を入れてScroll Boxの中に格納します。 最後に、outputStringの変数をクリアすれば処理は完了です。 デモ動画 本のオブジェクトに近づくことでタッチが可能になり、タッチすることでUIが表示されます。 さらにUI上で問い合わせると、オブジェクトの関連文章を基に回答できていることを確認できます。 これまでの実装により、ストレスの少ない問い合わせをUE上で実現することができました。 おわりに 今回はチャットUIを用いた、オブジェクトに対する問い合わせを実装しました。 以下、実装を担当した岡崎と若本のそれぞれの所感となります。 岡崎：今回の実装で、ブループリントでのチェンジイベント（オンクリックなど）や、 コリジョン イベントに関する使用方法の基礎的な学習を行えました。今後プロダクトを作成する際、プレイヤー起因で任意の情報を出したり、プレイヤー情報を変更させるといった機能を作成する際に、数多く使うことになる機能を作成することができたため、より応用的な使い方など引き続き調査したいと思います。 若本：UE初学者であり、今回広く Python の実装/ブループリントの実装/ C++ の実装を行いましたが、慣れて以降はストレスレスに開発を行うことができました。今回の実装を発展させ、非同期処理の実装や会話履歴の入れ込み、UIのリッチ化など、さらに作りこむことによってよりよいユーザー体験が得られることが期待できると感じました。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ 私たちは共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 最新テクノロジー事業企画・推進担当　◎Web3/メタバース/AI AIソリューション開発エンジニア　◎AIビジネス創出・推進に関われる 　　 株式会社電通総研 新卒採用 執筆： @wakamoto.ryosuke 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは、ISID金融ソリューション事業部の孫です。 この記事は、私が Unreal Engine （以下UE）のネットワーク同期（以下 レプリケーション ）に関する知識を学んだ知見です。 UEの レプリケーション 機能は、 マルチプレイヤー ゲームの開発において非常に重要なコアな機能です。 Web上に公開されているUEの レプリケーション プログラミングは、現在BluePrintを用いたビジュアルプログラミングが主となっています。 確かにBluePrintは便利で迅速な開発が可能ですが、UEの内部動作ロジックをより深く理解するためには C++ プログラミングが不可欠です。 この記事では、 C++ を使用してシンプルなネットワーク同期のデモを実装する方法を紹介します。このデモの開発を通じて、UEの レプリケーション 機能の実装方法を学ぶことができます。 はじめに UEの レプリケーション 部分について触れると、Dedicated Serverという概念をまず理解する必要があります。 ゲームネットワーク アーキテクチャ においてDedicated Serverが導入された背景については、 金融ソリューション事業部の山下さんの記事 を参照していただければと思います。 UEのDedicated Serverについて、UEのクライアントコードとサーバーコードは一体であることが特徴です。 通常、一般的なフロントエンドとバックエンドの分離とは異なり、UEではクライアントとサーバーが同じプロジェクト内に存在します。このため、クライアントとサーバーのコードは混在していることになります。 ※コードの間で以下のマクロを使ってサーバーコードとクライアントコードの区別が可能： WITH_EDITOR : コードがエディタ環境で動作しているときにTrueになります。 UE_SERVER : コードがサーバー環境で動作しているときにTrueになります。 UE_CLIENT : コードがクライアント環境で動作しているときにTrueになります。 Dedicated Serverが必要な理由は、C/S（クライアント/サーバー）モードではサーバーがクライアントの業務も担当するため、運用負荷が高くなるからです。Dedicated Serverの導入により、クライアントとサーバーの役割が分離され、負荷を軽減できます。 Dedicated Serverは、UEが FPS の同期問題を解決するために設計された専用のサーバーです。また、Dedicated ServerはEpicが開発した特別な最適化されたネットワーク プロトコル を使用しており、高性能な同期（遅延問題の解決）を実現できます。 Dedicated Serverの構築方法については、以前の 記事 を参照してください。 開発環境/ツール Unreal Engine 5.2.0 Windows10 21H2 x64 RAM 16GM, SSD 1TB NVIDIA GeForce GTX 3080 Visual Studio 2019 version 16.11.21（以下VS2019） それでは、デモの制作を開始しましょう。以下の手順で進めていきます。 ※デモはUEのサードパーソンテンプレートの上で レプリケーション 機能を実装 UEのネットワーク知識とActorの権限確認（ユーザーネーム表示用キャ ラク ターの作成含め） ユーザー名入力画面の作成 ユーザーネームの レプリケーション 実装 Dedicated Server側の実装 デモの確認 このような手順でデモの制作を進めていくと、ユーザーネームを持つキャ ラク ターを生成し、それを全てのクライアントで同期できます。 1.UEのネットワーク知識とActor権限の確認 本番の作成を開始する前に、まずは2点の前提知識を説明します。 UEのネットワークモデル UEのネットワークモデルでは、Actorの レプリケーション を通じてゲームオブジェクトの状態をクライアント間で同期します。これにより、各クライアントが一貫したゲームワールドを見ることができます。 UEのネットワークモデルには、いくつかのキーポイントと概念があります： Actor Replication（アクターレプリケーション） ： Unreal Engine では、各ゲームオブジェクトはActorと呼ばれます。サーバー内のActorの状態はクライアントに レプリケーション （複製）される可能性があり、これを「 レプリケーション 」と呼びます。どのActorが レプリケーション され、どのように レプリケーション されるかは、開発者が特定の属性と関数を設定することで決定されます。 State Synchronization（状態同期） ：サーバーは自身の状態をネットワークを通じて各クライアントに送信し、全てのクライアントが一貫したゲームワールドを見ることができるようにします。この過程を状態同期と呼びます。これがサーバーコンテンツを各クライアントに分散する必要性の理由です。この過程がなければ、クライアントは古いか、または一貫性のないゲームワールドの状態を見ることになりゲーム体験が低下します。 Client Prediction（クライアント予測） ：ネットワークの遅延がゲーム体験に影響を与えるのを減らすために、クライアントは「クライアント予測」と呼ばれる技術を使用します。つまり、サーバーからの応答が到着する前に、クライアントはあらかじめいくつかのアクションを実行します。サーバーからの応答を受け取ったら、クライアントは自身の状態を調整してサーバーの状態に一致させます。 Lag Compensation（ラグ補償） ：これはネットワーク遅延の影響を減らす別のテクニックです。サーバーは、クライアントがリク エス トを発行した時点のゲーム状態に戻って、その状態でリク エス トされた操作を実行します。 これらの コンポーネント やテクニックを組み合わせることで、UEのネットワークモデルは安定性と効率性を持ち、多人数プレイにおける一貫したゲーム体験を実現します。 各 コンポーネント は重要な役割を果たしますが、その中でも核心的な概念は「状態同期」です。状態同期は、すべてのプレイヤーが一貫したゲームワールドを見ることを保証し、各自異なる視覚体験やインタ ラク ション体験が生じることを防ぎます。 Actorの所有権-ROLE クライアントとサーバーの間に区別がある以上、Actorの所有権においてもクライアントとサーバーの区別があることは当然です。 UEでは、Actorの制御権限を3つのカテゴリに分けています。それらは以下のとおりです： ROLE_None ：特定の制御権限に属さない状態を表します。 ROLE_Authority ：サーバー側でActorの制御権を持つことを示します。 ROLE_AutonomousProxy ：クライアント側でローカルなActorの制御権を持つことを示します。 ROLE_SimulatedProxy ：他クライアントがActor制御権を持つことを示します。 これらの三つの属性はUEがActorを設計する際に、Actorに固有属性として設計されています。これはActorがどこに存在するかを判断するために使われます。 UEでは、サーバーのコードとクライアントのコードが一体化しているため、Actorがこの属性を持つことは非常に必要です。 その辺の権限関係をテストしてみましょう。 テンプレートのCharacterにRendertextを追加します。 xxxCharacter.h #include "Components/TextRenderComponent.h" ... public: UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = playername, meta = (AllowPrivateAccess = "true")) class UTextRenderComponent* playerNameTag; ... xxxCharacter.cpp #include "Components/SkeletalMeshComponent.h" // コンストラクタ関数にキャラクターのSkeletalメッシュ配下にTextRenderComponent追加 xxxCharacter::xxxCharacter() { ... // Create a Text Component playerNameTag = CreateDefaultSubobject<UTextRenderComponent>(TEXT("playerName")); USkeletalMeshComponent* SkeletalMesh = GetMesh(); playerNameTag->SetupAttachment(SkeletalMesh); playerNameTag->SetText(FText::FromString("test")); // Set Component Location Rotation playerNameTag->SetHorizontalAlignment(EHTA_Center); playerNameTag->SetRelativeLocation(FVector(0.0f, 0.0f, 180.0f)); playerNameTag->SetRelativeRotation(FRotator(0.0f, 90.0f, 0.0f)); ... 制御Roleを表示します。 xxxCharacter.cpp void Atest_DEServerCharacter::BeginPlay() { if (GetLocalRole() == ROLE_Authority) { playerNameTag->SetText(FText::FromString("ROLE_Authority")); UE_LOG(LogTemp, Warning, TEXT("This Actor is on the server.")); } else if (GetLocalRole() == ROLE_AutonomousProxy) { playerNameTag->SetText(FText::FromString("ROLE_AutonomousProxy")); UE_LOG(LogTemp, Warning, TEXT("This Actor is on the owning client.")); } else if (GetLocalRole()== ROLE_SimulatedProxy) { playerNameTag->SetText(FText::FromString("ROLE_SimulatedProxy")); UE_LOG(LogTemp, Warning, TEXT("Other Client Actor is ROLE_SimulatedProxy.")); } else { playerNameTag->SetText(FText::FromString("ROLE_None")); UE_LOG(LogTemp, Warning, TEXT("This Actor is on a non-owning client.")); } } 権限Roleを確認します。 サーバーのウィンドウでは、すべてのキャ ラク ターが「ROLE_Authority」と表示されていることがわかります。 それに対して二つのクライアントのウィンドウでは、自分が制御しているキャ ラク ターだけ「ROLE_AutonomousProxy」と表示され、他のすべては「ROLE_SimulatedProxy」と表示されています。 その中にはサーバーが生成したキャ ラク ターも含まれていますが、このクライアントにとってはそれも他のエンドのActorに属するものとなります。 次に、ステップ バイス テップで レプリケーション デモを作成します。 2.ユーザー名入力画面の作成 入力用 Widget UIの作成 Content Browserで Content フォルダを開き、右側の空白部分で右クリックして User Interface -> Widget Blueprintを選択してUIを作成します。 新しく作成したBlueprintをダブルクリックして開き、以下の画像のように「ゲーム開始Button」「ユーザー名入力のEditableText」とタイトル表示の「TextBlock ウィジェット 」を追加します。 Widget UIの親Classファイルの作成 Content Browser で C++Classes フォルダを開き、右側の空白部分で右クリックし New C++ Class -> UserWidget を選択します。 新しく作成したクラスファイルが自動的に Visual Studio で開かれます。 このクラスがBlueprintのUIを制御するために、Blueprintの親クラスを新しく作成したクラスに変更します。 UIのBlueprintをダブルクリックして開き、 File -> Reparent Blueprint をクリックし、表示されるダイアログで新しく作成したクラスを選択します。 ユーザー名の取得コードの実装 制御する ウィジェット の定義を追加します。 定義に UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) を追加して、Blueprint Widget 内の対応する ウィジェット にバインドできるようにします。 //LoginHUDWidget.h UCLASS() class TEST_DESERVER_API ULoginHUDWidget : public UUserWidget { GENERATED_BODY() public: void NativePreConstruct(); UFUNCTION() void OnPlayGameButtonClicked(); UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) class UEditableText* inputName; UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) class UTextBlock* statusLabel; UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) class UTextBlock* playLabel; UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) class UButton* playBtn; }; コンスト ラク タ関数で ウィジェット を初期化します。 Button ウィジェット には OnPlayGameButtonClicked という処理関数を追加します。 //LoginHUDWidget.cpp void ULoginHUDWidget::NativePreConstruct() { Super::NativePreConstruct(); inputName->SetHintText(FText::FromString("Please input your name")); statusLabel->SetText(FText::FromString("Test Replication Demo")); playLabel->SetText(FText::FromString("Play")); FScriptDelegate StartPlayDelegate; StartPlayDelegate.BindUFunction(this, "OnPlayGameButtonClicked"); playBtn->OnClicked.Add(StartPlayDelegate); }; ゲーム開始ボタンがクリックされた後の処理ロジックを追加します。 UGameplayStatics::OpenLevel 関数を使用してDedicated Serverに接続します。 ユーザーが入力したプレイヤー名はOptionsを通じてDedicated Serverに渡されます。 void ULoginHUDWidget::OnPlayGameButtonClicked() { FString NickName = inputName->GetText().ToString(); FString LevelName = "127.0.0.1:7777"; FString Options = FString::Printf(TEXT("?NickName=%s"), *NickName); UGameplayStatics::OpenLevel(GetWorld(), FName(*LevelName), false, Options); } GameModeで Widget コンポーネント をロードします。 //xxxGameMode.h protected: UPROPERTY(EditAnywhere, Category = "UI") TSubclassOf<UUserWidget> LoginWidgetClass; private: UPROPERTY() ULoginHUDWidget* loginWidget; //xxxGameMode.cpp AxxxGameMode::AxxxGameMode() { static ConstructorHelpers::FClassFinder<UUserWidget> LoginWidgetObj(TEXT("/Game/UI/LoginHUD_UI")); LoginWidgetClass = LoginWidgetObj.Class; }; void AxxxGameMode::BeginPlay() { Super::BeginPlay(); APlayerController* PlayerController = GetWorld()->GetFirstPlayerController(); if (PlayerController != nullptr) { PlayerController->bShowMouseCursor = true; } if (LoginWidgetClass != nullptr) { UUserWidget* loginWidget = CreateWidget<UUserWidget>(GetWorld(), LoginWidgetClass); if (loginWidget != nullptr) { loginWidget->AddToViewport(); } } } 3.ユーザーネームの レプリケーション 実装 クライアントの属性が変更されたときに、その属性値が他のクライアントに同期するためには、以下の2点を覚えておく必要があります： ① 属性のReplicationはReplicated or ReplicatedUsingに設定すべきです ② 属性を変更するコードはDedicated Server上で実行されます Actorの レプリケーション ReplicationはUObjectから派生した任意クラスの変数の固有属性で、この変数がネットワーク同期を許可するかどうかを指定します。 ブループリントでは、以下の3つの項目がReplication属性に対して設定可能です： None ：ネットワーク同期を許可しません。 Replication ：ネットワーク同期を許可します。 RepNotify ：属性はネットワーク同期を許可し、さらにコールバック関数にバインドします。属性が変化すると、このコールバックが呼び出されます。ブループリントでは、このコールバック関数はFUNCTION内に自動的に作成され、OnRep_で始まり属性名で終わるようになっています。例えば、pos属性のコールバック関数はOnRep_posとなります。 C++ でこの部分は、 APlayerState クラスで実装されます。 APlayerState は Unreal Engine のクラスであり、各プレイヤーに関連するゲーム情報を格納および管理するために使用されます。 この情報は、プレイヤーが現在のシーンにいるかどうかに関係なく、通常はゲームセッション全体で永続的です。この設計により、 APlayerState はゲームセッション全体のレベル内でプレイヤー情報を格納する理想的な場所となります。 ※ 注意 ： APlayerState はプレイヤーの入力やゲームワールド内での状態（位置、速度、アニメーションの状態など）を格納するためのものではありません。これらの情報は APlayerController に格納する必要があります。 該当する C++ コードの例は以下のようになります。 # ネットワーク同期を許可しません UPROPERTY() # ネットワーク同期を許可します UPROPERTY(Replicated) # 属性はネットワーク同期を許可し、さらにコールバック関数にバインドします UPROPERTY(ReplicatedUsing=OnRep_xxx) ユーザーネームの レプリケーション 実装 Playstateのサブクラスを新規作成します。 Widget Classを作成したのと同じ手順で、 C++ Classesフォルダで右クリックし、 New C++ Class -> playerState を選択します。 作成が完了すると、 Visual Studio が自動的に新しいクラスファイルを開きます。 Replicatedとして定義します。 DOREPLIFETIME Unreal Engine のネットワークプログラミングにおけるマクロであり、特定のプロパティがネットワーク上で複製可能であることを設定するために使用されます。 //playerstate.h public: UPROPERTY(Replicated) FString NickName; virtual void GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const override; //playerstate.cpp void AMetaPlayerState::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMetaPlayerState, NickName); } GameModeのコンスト ラク タ関数に PlayerState をロードします。 AxxxGameMode::AxxxGameMode() { PlayerStateClass = AMetaPlayerState::StaticClass(); }; サーバーからの更新メッセージを受け取り、キャ ラク ターに値を割り当てます。 コン トロール しているキャ ラク ターについて、上記で定義したNickNameが変更された場合、 OnRep_PlayerState 関数が実行されます。 OnRep_PlayerState 関数は APlayerState クラスに定義されており、それを継承する必要があります。 //xxxCharacter.h private: virtual void OnRep_PlayerState() override; //xxxCharacter.cpp void AxxxCharacter::OnRep_PlayerState() { Super::OnRep_PlayerState(); APlayerState* OwningPlayerState = GetPlayerState(); if (OwningPlayerState != nullptr) { AMetaPlayerState* MetaPlayerState = Cast<AMetaPlayerState>(OwningPlayerState); if (MetaPlayerState != nullptr) { FString NickName = MetaPlayerState->NickName; if (NickName.Len() > 0 ) { playerNameTag->SetText(FText::FromString(NickName)); } } } } 4.Dedicated Server側の実装 UEの AGameModeBase および AGameMode クラスは、ゲームの基本ルールとロジックを定義するために使用されます。 以下に、これらのクラスでいくつかの重要なライフサイクル関数と、それらが通常どのような役割を果たすかを示します。 InitGame() ：この関数はサーバーが起動し、すべてのオブジェクトがロードされ、ゲームがまだ実行されていない状態で呼び出されます。ここで変数や状態を初期化できます。 PreLogin() ：これはクライアントが接続を許可される前にサーバーで呼び出される関数です。プレイヤーの資格情報（例：ユーザー名やパスワードの確認）を検証したり、プレイヤーの接続を他の形式で事前検証したりするために使用できます。検証が失敗した場合、ここでプレイヤーの接続を拒否できます。 PostLogin() ：プレイヤーが正常に接続され、検証された後、PostLogin()関数が呼び出されます。ここでは、プレイヤーがゲームに参加した後すぐに実行する必要のあるコードを実行できます。例えば、歓迎メッセージを送信したり、プレイヤーのゲームデータを初期化したりできます。 InitNewPlayer() ：この関数はプレイヤーがサーバーに接続して初期化されたときに呼び出されます。この関数では、「プレイヤーの属性の初期化」「プレイヤーのチームの割り当て」「新しいプレイヤーに必要なゲーム情報の送信」など、多くのタスクを実行できます。 BeginPlay() ：この関数はゲームの開始時に呼び出されます。ゲーム開始時に実行する必要があるコードをここで実行できます。 Logout() ：プレイヤーがゲームから退出するときにこの関数が呼び出されます。ここでは、プレイヤーがゲームから退出する際に実行する必要のあるコード（例：プレイヤーのゲームデータの保存や、プレイヤーの退出メッセージの送信など）を実行できます。 これらの関数は最も一般的に使用され、ゲームの異なる段階で何を実行するかをサーバーサイドで処理するために使用されます。　　　 これらの関数により、ゲームのロジックや要件に合わせて特定のコードを適切なタイミングで実行できます。 前述のように、同期を実現するには2つの条件を満たす必要があります。 「② 属性の変更コードはDedicated Server上で実行される」 という条件を満たすために、上記の関数の中で、特に InitNewPlayer() 関数を選択する必要があります。 なぜなら、この関数はプレイヤーの PlayState 初期化が行われるタイミングですから。 //.xxxGameMode.h virtual FString InitNewPlayer(APlayerController* NewPlayerController, const FUniqueNetIdRepl& UniqueId, const FString& Options, const FString& Portal) override; //.xxxGameMode.cpp FString xxxServerGameMode::InitNewPlayer(APlayerController* NewPlayerController, const FUniqueNetIdRepl& UniqueId, const FString& Options, const FString& Portal) { FString InitializedString = Super::InitNewPlayer(NewPlayerController, UniqueId, Options, Portal); const FString& nickName = UGameplayStatics::ParseOption(Options, "NickName"); if (NewPlayerController != nullptr) { APlayerState* PlayerState = NewPlayerController->PlayerState; if (PlayerState != nullptr) { AMetaPlayerState* ServerPlayerState = Cast<AMetaPlayerState>(PlayerState); if (ServerPlayerState) { ServerPlayerState->NickName = nickName; } } } return InitializedString; } 5.デモの確認 ここまでで、ユーザーネームの レプリケーション に関する実装が全部完了しました！ Dedicated Serverをパッケージ化して試してみましょう。確認ポイントは以下となります： 各クライアントでユーザーがユーザーネームを入力し、ゲームが開始できること 各クライアントで対応するキャ ラク ターの名前が表示されること 上記の確認が取れましたら、いわゆるネットワーク上での状態同期が成功し、すべてのクライアントが一貫したゲーム世界を見ることができるようになりました！ ※パッケージング手順については Amazon GameLift × Unreal Engines 5 でオンラインマルチプレイゲームを作る の記事を参照してください。 注意事項 属性の同期を実装する際には、以下の点を注意してください。 それは、キャ ラク ターモデルの変更をAPlayerStateクラスに実装しないということです。 筆者がコードを書く際、最初に APlayerState クラスに以下のようなコールバック関数を書いたことがありました。 void ATestPlayerState::OnRep_NickName() { APlayerController* PC = GetGameInstance()->GetFirstLocalPlayerController(); if (PC && PC->GetPawn()) { AMetaPlayerController* PlayerController = Cast<AMetaPlayerController>(PC); if (PlayerController) { Atest_DEServerCharacter* MyCharacter = Cast<Atest_DEServerCharacter>(PlayerController->GetPawn()); if (MyCharacter) { MyCharacter->playerNameTag->SetText(FText::FromString(NickName)); } } } } 実行結果として、もともとPlayer1を制御していたユーザーが、Player2がログインした後に制御しているキャ ラク ターの表示がPlayer2のユーザー名になってしまうという問題が発生しました。　　　 これは、私が APlayerState の OnRep_NickName 関数でキャ ラク ターを取得し、名前ラベルを変更していたためです。 この関数は、NickNameフィールドがクライアントに複製されたときに呼び出されます。しかし一部の場合では、NickNameフィールドがクライアントに複製された時点では、クライアントが新しいキャ ラク ターの情報をまだ受信していない可能性があります。つまり、GetPawn()関数がnullを返すか、もしくはキャ ラク ターが存在していても既に存在する他のプレイヤーのキャ ラク ターになるかもしれません。 この問題を解決するための方法は、 APlayerState のOnRep関数内でキャ ラク ターを取得し、名前ラベルを変更しないことです。 代わりに、キャ ラク ターのOnRep_PlayerState関数内で、キャ ラク ター自身のPlayerStateを取得しキャ ラク ターの名前ラベルを変更する必要があります。先ほど実装したコードと同様に、キャ ラク ター自身のOnRep_PlayerState関数でこれを行ってください。 終わりに このユーザーネーム属性の レプリケーション デモを通じて、 Unreal Engine のネットワーク同期モデルについて一定の理解を得ることができました。 Unreal Engine は、さまざまなタイプのゲームや仮想現実アプリケーションをサポートする強力な ゲームエンジン です。3Dおよび メタバース の開発領域では、ネットワーク同期、 マルチプレイヤー ゲーム、物理シミュレーション、シーンの レンダリング など、さまざまな技術と応用を探求できます。学習と研究を続けることで、この領域においてより深い理解と高い技術力を身につけることができます。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 参考文献 https://docs.unrealengine.com/5.2/en-US/networking-overview-for-unreal-engine/ 執筆： @chen.sun 、レビュー： @yamashita.yuki （ Shodo で執筆されました ）

こんにちは、ISID金融ソリューション事業部の孫です。 この記事は、私が Unreal Engine （以下UE）のネットワーク同期（以下 レプリケーション ）に関する知識を学んだ知見です。 UEの レプリケーション 機能は、 マルチプレイヤー ゲームの開発において非常に重要なコアな機能です。 Web上に公開されているUEの レプリケーション プログラミングは、現在BluePrintを用いたビジュアルプログラミングが主となっています。 確かにBluePrintは便利で迅速な開発が可能ですが、UEの内部動作ロジックをより深く理解するためには C++ プログラミングが不可欠です。 この記事では、 C++ を使用してシンプルなネットワーク同期のデモを実装する方法を紹介します。このデモの開発を通じて、UEの レプリケーション 機能の実装方法を学ぶことができます。 はじめに UEの レプリケーション 部分について触れると、Dedicated Serverという概念をまず理解する必要があります。 ゲームネットワーク アーキテクチャ においてDedicated Serverが導入された背景については、 金融ソリューション事業部の山下さんの記事 を参照していただければと思います。 UEのDedicated Serverについて、UEのクライアントコードとサーバーコードは一体であることが特徴です。 通常、一般的なフロントエンドとバックエンドの分離とは異なり、UEではクライアントとサーバーが同じプロジェクト内に存在します。このため、クライアントとサーバーのコードは混在していることになります。 ※コードの間で以下のマクロを使ってサーバーコードとクライアントコードの区別が可能： WITH_EDITOR : コードがエディタ環境で動作しているときにTrueになります。 UE_SERVER : コードがサーバー環境で動作しているときにTrueになります。 UE_CLIENT : コードがクライアント環境で動作しているときにTrueになります。 Dedicated Serverが必要な理由は、C/S（クライアント/サーバー）モードではサーバーがクライアントの業務も担当するため、運用負荷が高くなるからです。Dedicated Serverの導入により、クライアントとサーバーの役割が分離され、負荷を軽減できます。 Dedicated Serverは、UEが FPS の同期問題を解決するために設計された専用のサーバーです。また、Dedicated ServerはEpicが開発した特別な最適化されたネットワーク プロトコル を使用しており、高性能な同期（遅延問題の解決）を実現できます。 Dedicated Serverの構築方法については、以前の 記事 を参照してください。 開発環境/ツール Unreal Engine 5.2.0 Windows10 21H2 x64 RAM 16GM, SSD 1TB NVIDIA GeForce GTX 3080 Visual Studio 2019 version 16.11.21（以下VS2019） それでは、デモの制作を開始しましょう。以下の手順で進めていきます。 ※デモはUEのサードパーソンテンプレートの上で レプリケーション 機能を実装 UEのネットワーク知識とActorの権限確認（ユーザーネーム表示用キャ ラク ターの作成含め） ユーザー名入力画面の作成 ユーザーネームの レプリケーション 実装 Dedicated Server側の実装 デモの確認 このような手順でデモの制作を進めていくと、ユーザーネームを持つキャ ラク ターを生成し、それを全てのクライアントで同期できます。 1.UEのネットワーク知識とActor権限の確認 本番の作成を開始する前に、まずは2点の前提知識を説明します。 UEのネットワークモデル UEのネットワークモデルでは、Actorの レプリケーション を通じてゲームオブジェクトの状態をクライアント間で同期します。これにより、各クライアントが一貫したゲームワールドを見ることができます。 UEのネットワークモデルには、いくつかのキーポイントと概念があります： Actor Replication（アクターレプリケーション） ： Unreal Engine では、各ゲームオブジェクトはActorと呼ばれます。サーバー内のActorの状態はクライアントに レプリケーション （複製）される可能性があり、これを「 レプリケーション 」と呼びます。どのActorが レプリケーション され、どのように レプリケーション されるかは、開発者が特定の属性と関数を設定することで決定されます。 State Synchronization（状態同期） ：サーバーは自身の状態をネットワークを通じて各クライアントに送信し、全てのクライアントが一貫したゲームワールドを見ることができるようにします。この過程を状態同期と呼びます。これがサーバーコンテンツを各クライアントに分散する必要性の理由です。この過程がなければ、クライアントは古いか、または一貫性のないゲームワールドの状態を見ることになりゲーム体験が低下します。 Client Prediction（クライアント予測） ：ネットワークの遅延がゲーム体験に影響を与えるのを減らすために、クライアントは「クライアント予測」と呼ばれる技術を使用します。つまり、サーバーからの応答が到着する前に、クライアントはあらかじめいくつかのアクションを実行します。サーバーからの応答を受け取ったら、クライアントは自身の状態を調整してサーバーの状態に一致させます。 Lag Compensation（ラグ補償） ：これはネットワーク遅延の影響を減らす別のテクニックです。サーバーは、クライアントがリク エス トを発行した時点のゲーム状態に戻って、その状態でリク エス トされた操作を実行します。 これらの コンポーネント やテクニックを組み合わせることで、UEのネットワークモデルは安定性と効率性を持ち、多人数プレイにおける一貫したゲーム体験を実現します。 各 コンポーネント は重要な役割を果たしますが、その中でも核心的な概念は「状態同期」です。状態同期は、すべてのプレイヤーが一貫したゲームワールドを見ることを保証し、各自異なる視覚体験やインタ ラク ション体験が生じることを防ぎます。 Actorの所有権-ROLE クライアントとサーバーの間に区別がある以上、Actorの所有権においてもクライアントとサーバーの区別があることは当然です。 UEでは、Actorの制御権限を3つのカテゴリに分けています。それらは以下のとおりです： ROLE_None ：特定の制御権限に属さない状態を表します。 ROLE_Authority ：サーバー側でActorの制御権を持つことを示します。 ROLE_AutonomousProxy ：クライアント側でローカルなActorの制御権を持つことを示します。 ROLE_SimulatedProxy ：他クライアントがActor制御権を持つことを示します。 これらの三つの属性はUEがActorを設計する際に、Actorに固有属性として設計されています。これはActorがどこに存在するかを判断するために使われます。 UEでは、サーバーのコードとクライアントのコードが一体化しているため、Actorがこの属性を持つことは非常に必要です。 その辺の権限関係をテストしてみましょう。 テンプレートのCharacterにRendertextを追加します。 xxxCharacter.h #include "Components/TextRenderComponent.h" ... public: UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = playername, meta = (AllowPrivateAccess = "true")) class UTextRenderComponent* playerNameTag; ... xxxCharacter.cpp #include "Components/SkeletalMeshComponent.h" // コンストラクタ関数にキャラクターのSkeletalメッシュ配下にTextRenderComponent追加 xxxCharacter::xxxCharacter() { ... // Create a Text Component playerNameTag = CreateDefaultSubobject<UTextRenderComponent>(TEXT("playerName")); USkeletalMeshComponent* SkeletalMesh = GetMesh(); playerNameTag->SetupAttachment(SkeletalMesh); playerNameTag->SetText(FText::FromString("test")); // Set Component Location Rotation playerNameTag->SetHorizontalAlignment(EHTA_Center); playerNameTag->SetRelativeLocation(FVector(0.0f, 0.0f, 180.0f)); playerNameTag->SetRelativeRotation(FRotator(0.0f, 90.0f, 0.0f)); ... 制御Roleを表示します。 xxxCharacter.cpp void Atest_DEServerCharacter::BeginPlay() { if (GetLocalRole() == ROLE_Authority) { playerNameTag->SetText(FText::FromString("ROLE_Authority")); UE_LOG(LogTemp, Warning, TEXT("This Actor is on the server.")); } else if (GetLocalRole() == ROLE_AutonomousProxy) { playerNameTag->SetText(FText::FromString("ROLE_AutonomousProxy")); UE_LOG(LogTemp, Warning, TEXT("This Actor is on the owning client.")); } else if (GetLocalRole()== ROLE_SimulatedProxy) { playerNameTag->SetText(FText::FromString("ROLE_SimulatedProxy")); UE_LOG(LogTemp, Warning, TEXT("Other Client Actor is ROLE_SimulatedProxy.")); } else { playerNameTag->SetText(FText::FromString("ROLE_None")); UE_LOG(LogTemp, Warning, TEXT("This Actor is on a non-owning client.")); } } 権限Roleを確認します。 サーバーのウィンドウでは、すべてのキャ ラク ターが「ROLE_Authority」と表示されていることがわかります。 それに対して二つのクライアントのウィンドウでは、自分が制御しているキャ ラク ターだけ「ROLE_AutonomousProxy」と表示され、他のすべては「ROLE_SimulatedProxy」と表示されています。 その中にはサーバーが生成したキャ ラク ターも含まれていますが、このクライアントにとってはそれも他のエンドのActorに属するものとなります。 次に、ステップ バイス テップで レプリケーション デモを作成します。 2.ユーザー名入力画面の作成 入力用 Widget UIの作成 Content Browserで Content フォルダを開き、右側の空白部分で右クリックして User Interface -> Widget Blueprintを選択してUIを作成します。 新しく作成したBlueprintをダブルクリックして開き、以下の画像のように「ゲーム開始Button」「ユーザー名入力のEditableText」とタイトル表示の「TextBlock ウィジェット 」を追加します。 Widget UIの親Classファイルの作成 Content Browser で C++Classes フォルダを開き、右側の空白部分で右クリックし New C++ Class -> UserWidget を選択します。 新しく作成したクラスファイルが自動的に Visual Studio で開かれます。 このクラスがBlueprintのUIを制御するために、Blueprintの親クラスを新しく作成したクラスに変更します。 UIのBlueprintをダブルクリックして開き、 File -> Reparent Blueprint をクリックし、表示されるダイアログで新しく作成したクラスを選択します。 ユーザー名の取得コードの実装 制御する ウィジェット の定義を追加します。 定義に UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) を追加して、Blueprint Widget 内の対応する ウィジェット にバインドできるようにします。 //LoginHUDWidget.h UCLASS() class TEST_DESERVER_API ULoginHUDWidget : public UUserWidget { GENERATED_BODY() public: void NativePreConstruct(); UFUNCTION() void OnPlayGameButtonClicked(); UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) class UEditableText* inputName; UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) class UTextBlock* statusLabel; UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) class UTextBlock* playLabel; UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (BindWidget)) class UButton* playBtn; }; コンスト ラク タ関数で ウィジェット を初期化します。 Button ウィジェット には OnPlayGameButtonClicked という処理関数を追加します。 //LoginHUDWidget.cpp void ULoginHUDWidget::NativePreConstruct() { Super::NativePreConstruct(); inputName->SetHintText(FText::FromString("Please input your name")); statusLabel->SetText(FText::FromString("Test Replication Demo")); playLabel->SetText(FText::FromString("Play")); FScriptDelegate StartPlayDelegate; StartPlayDelegate.BindUFunction(this, "OnPlayGameButtonClicked"); playBtn->OnClicked.Add(StartPlayDelegate); }; ゲーム開始ボタンがクリックされた後の処理ロジックを追加します。 UGameplayStatics::OpenLevel 関数を使用してDedicated Serverに接続します。 ユーザーが入力したプレイヤー名はOptionsを通じてDedicated Serverに渡されます。 void ULoginHUDWidget::OnPlayGameButtonClicked() { FString NickName = inputName->GetText().ToString(); FString LevelName = "127.0.0.1:7777"; FString Options = FString::Printf(TEXT("?NickName=%s"), *NickName); UGameplayStatics::OpenLevel(GetWorld(), FName(*LevelName), false, Options); } GameModeで Widget コンポーネント をロードします。 //xxxGameMode.h protected: UPROPERTY(EditAnywhere, Category = "UI") TSubclassOf<UUserWidget> LoginWidgetClass; private: UPROPERTY() ULoginHUDWidget* loginWidget; //xxxGameMode.cpp AxxxGameMode::AxxxGameMode() { static ConstructorHelpers::FClassFinder<UUserWidget> LoginWidgetObj(TEXT("/Game/UI/LoginHUD_UI")); LoginWidgetClass = LoginWidgetObj.Class; }; void AxxxGameMode::BeginPlay() { Super::BeginPlay(); APlayerController* PlayerController = GetWorld()->GetFirstPlayerController(); if (PlayerController != nullptr) { PlayerController->bShowMouseCursor = true; } if (LoginWidgetClass != nullptr) { UUserWidget* loginWidget = CreateWidget<UUserWidget>(GetWorld(), LoginWidgetClass); if (loginWidget != nullptr) { loginWidget->AddToViewport(); } } } 3.ユーザーネームの レプリケーション 実装 クライアントの属性が変更されたときに、その属性値が他のクライアントに同期するためには、以下の2点を覚えておく必要があります： ① 属性のReplicationはReplicated or ReplicatedUsingに設定すべきです ② 属性を変更するコードはDedicated Server上で実行されます Actorの レプリケーション ReplicationはUObjectから派生した任意クラスの変数の固有属性で、この変数がネットワーク同期を許可するかどうかを指定します。 ブループリントでは、以下の3つの項目がReplication属性に対して設定可能です： None ：ネットワーク同期を許可しません。 Replication ：ネットワーク同期を許可します。 RepNotify ：属性はネットワーク同期を許可し、さらにコールバック関数にバインドします。属性が変化すると、このコールバックが呼び出されます。ブループリントでは、このコールバック関数はFUNCTION内に自動的に作成され、OnRep_で始まり属性名で終わるようになっています。例えば、pos属性のコールバック関数はOnRep_posとなります。 C++ でこの部分は、 APlayerState クラスで実装されます。 APlayerState は Unreal Engine のクラスであり、各プレイヤーに関連するゲーム情報を格納および管理するために使用されます。 この情報は、プレイヤーが現在のシーンにいるかどうかに関係なく、通常はゲームセッション全体で永続的です。この設計により、 APlayerState はゲームセッション全体のレベル内でプレイヤー情報を格納する理想的な場所となります。 ※ 注意 ： APlayerState はプレイヤーの入力やゲームワールド内での状態（位置、速度、アニメーションの状態など）を格納するためのものではありません。これらの情報は APlayerController に格納する必要があります。 該当する C++ コードの例は以下のようになります。 # ネットワーク同期を許可しません UPROPERTY() # ネットワーク同期を許可します UPROPERTY(Replicated) # 属性はネットワーク同期を許可し、さらにコールバック関数にバインドします UPROPERTY(ReplicatedUsing=OnRep_xxx) ユーザーネームの レプリケーション 実装 Playstateのサブクラスを新規作成します。 Widget Classを作成したのと同じ手順で、 C++ Classesフォルダで右クリックし、 New C++ Class -> playerState を選択します。 作成が完了すると、 Visual Studio が自動的に新しいクラスファイルを開きます。 Replicatedとして定義します。 DOREPLIFETIME Unreal Engine のネットワークプログラミングにおけるマクロであり、特定のプロパティがネットワーク上で複製可能であることを設定するために使用されます。 //playerstate.h public: UPROPERTY(Replicated) FString NickName; virtual void GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const override; //playerstate.cpp void AMetaPlayerState::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMetaPlayerState, NickName); } GameModeのコンスト ラク タ関数に PlayerState をロードします。 AxxxGameMode::AxxxGameMode() { PlayerStateClass = AMetaPlayerState::StaticClass(); }; サーバーからの更新メッセージを受け取り、キャ ラク ターに値を割り当てます。 コン トロール しているキャ ラク ターについて、上記で定義したNickNameが変更された場合、 OnRep_PlayerState 関数が実行されます。 OnRep_PlayerState 関数は APlayerState クラスに定義されており、それを継承する必要があります。 //xxxCharacter.h private: virtual void OnRep_PlayerState() override; //xxxCharacter.cpp void AxxxCharacter::OnRep_PlayerState() { Super::OnRep_PlayerState(); APlayerState* OwningPlayerState = GetPlayerState(); if (OwningPlayerState != nullptr) { AMetaPlayerState* MetaPlayerState = Cast<AMetaPlayerState>(OwningPlayerState); if (MetaPlayerState != nullptr) { FString NickName = MetaPlayerState->NickName; if (NickName.Len() > 0 ) { playerNameTag->SetText(FText::FromString(NickName)); } } } } 4.Dedicated Server側の実装 UEの AGameModeBase および AGameMode クラスは、ゲームの基本ルールとロジックを定義するために使用されます。 以下に、これらのクラスでいくつかの重要なライフサイクル関数と、それらが通常どのような役割を果たすかを示します。 InitGame() ：この関数はサーバーが起動し、すべてのオブジェクトがロードされ、ゲームがまだ実行されていない状態で呼び出されます。ここで変数や状態を初期化できます。 PreLogin() ：これはクライアントが接続を許可される前にサーバーで呼び出される関数です。プレイヤーの資格情報（例：ユーザー名やパスワードの確認）を検証したり、プレイヤーの接続を他の形式で事前検証したりするために使用できます。検証が失敗した場合、ここでプレイヤーの接続を拒否できます。 PostLogin() ：プレイヤーが正常に接続され、検証された後、PostLogin()関数が呼び出されます。ここでは、プレイヤーがゲームに参加した後すぐに実行する必要のあるコードを実行できます。例えば、歓迎メッセージを送信したり、プレイヤーのゲームデータを初期化したりできます。 InitNewPlayer() ：この関数はプレイヤーがサーバーに接続して初期化されたときに呼び出されます。この関数では、「プレイヤーの属性の初期化」「プレイヤーのチームの割り当て」「新しいプレイヤーに必要なゲーム情報の送信」など、多くのタスクを実行できます。 BeginPlay() ：この関数はゲームの開始時に呼び出されます。ゲーム開始時に実行する必要があるコードをここで実行できます。 Logout() ：プレイヤーがゲームから退出するときにこの関数が呼び出されます。ここでは、プレイヤーがゲームから退出する際に実行する必要のあるコード（例：プレイヤーのゲームデータの保存や、プレイヤーの退出メッセージの送信など）を実行できます。 これらの関数は最も一般的に使用され、ゲームの異なる段階で何を実行するかをサーバーサイドで処理するために使用されます。　　　 これらの関数により、ゲームのロジックや要件に合わせて特定のコードを適切なタイミングで実行できます。 前述のように、同期を実現するには2つの条件を満たす必要があります。 「② 属性の変更コードはDedicated Server上で実行される」 という条件を満たすために、上記の関数の中で、特に InitNewPlayer() 関数を選択する必要があります。 なぜなら、この関数はプレイヤーの PlayState 初期化が行われるタイミングですから。 //.xxxGameMode.h virtual FString InitNewPlayer(APlayerController* NewPlayerController, const FUniqueNetIdRepl& UniqueId, const FString& Options, const FString& Portal) override; //.xxxGameMode.cpp FString xxxServerGameMode::InitNewPlayer(APlayerController* NewPlayerController, const FUniqueNetIdRepl& UniqueId, const FString& Options, const FString& Portal) { FString InitializedString = Super::InitNewPlayer(NewPlayerController, UniqueId, Options, Portal); const FString& nickName = UGameplayStatics::ParseOption(Options, "NickName"); if (NewPlayerController != nullptr) { APlayerState* PlayerState = NewPlayerController->PlayerState; if (PlayerState != nullptr) { AMetaPlayerState* ServerPlayerState = Cast<AMetaPlayerState>(PlayerState); if (ServerPlayerState) { ServerPlayerState->NickName = nickName; } } } return InitializedString; } 5.デモの確認 ここまでで、ユーザーネームの レプリケーション に関する実装が全部完了しました！ Dedicated Serverをパッケージ化して試してみましょう。確認ポイントは以下となります： 各クライアントでユーザーがユーザーネームを入力し、ゲームが開始できること 各クライアントで対応するキャ ラク ターの名前が表示されること 上記の確認が取れましたら、いわゆるネットワーク上での状態同期が成功し、すべてのクライアントが一貫したゲーム世界を見ることができるようになりました！ ※パッケージング手順については Amazon GameLift × Unreal Engines 5 でオンラインマルチプレイゲームを作る の記事を参照してください。 注意事項 属性の同期を実装する際には、以下の点を注意してください。 それは、キャ ラク ターモデルの変更をAPlayerStateクラスに実装しないということです。 筆者がコードを書く際、最初に APlayerState クラスに以下のようなコールバック関数を書いたことがありました。 void ATestPlayerState::OnRep_NickName() { APlayerController* PC = GetGameInstance()->GetFirstLocalPlayerController(); if (PC && PC->GetPawn()) { AMetaPlayerController* PlayerController = Cast<AMetaPlayerController>(PC); if (PlayerController) { Atest_DEServerCharacter* MyCharacter = Cast<Atest_DEServerCharacter>(PlayerController->GetPawn()); if (MyCharacter) { MyCharacter->playerNameTag->SetText(FText::FromString(NickName)); } } } } 実行結果として、もともとPlayer1を制御していたユーザーが、Player2がログインした後に制御しているキャ ラク ターの表示がPlayer2のユーザー名になってしまうという問題が発生しました。　　　 これは、私が APlayerState の OnRep_NickName 関数でキャ ラク ターを取得し、名前ラベルを変更していたためです。 この関数は、NickNameフィールドがクライアントに複製されたときに呼び出されます。しかし一部の場合では、NickNameフィールドがクライアントに複製された時点では、クライアントが新しいキャ ラク ターの情報をまだ受信していない可能性があります。つまり、GetPawn()関数がnullを返すか、もしくはキャ ラク ターが存在していても既に存在する他のプレイヤーのキャ ラク ターになるかもしれません。 この問題を解決するための方法は、 APlayerState のOnRep関数内でキャ ラク ターを取得し、名前ラベルを変更しないことです。 代わりに、キャ ラク ターのOnRep_PlayerState関数内で、キャ ラク ター自身のPlayerStateを取得しキャ ラク ターの名前ラベルを変更する必要があります。先ほど実装したコードと同様に、キャ ラク ター自身のOnRep_PlayerState関数でこれを行ってください。 終わりに このユーザーネーム属性の レプリケーション デモを通じて、 Unreal Engine のネットワーク同期モデルについて一定の理解を得ることができました。 Unreal Engine は、さまざまなタイプのゲームや仮想現実アプリケーションをサポートする強力な ゲームエンジン です。3Dおよび メタバース の開発領域では、ネットワーク同期、 マルチプレイヤー ゲーム、物理シミュレーション、シーンの レンダリング など、さまざまな技術と応用を探求できます。学習と研究を続けることで、この領域においてより深い理解と高い技術力を身につけることができます。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 参考文献 https://docs.unrealengine.com/5.2/en-US/networking-overview-for-unreal-engine/ 執筆： @chen.sun 、レビュー： @yamashita.yuki （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 今回は、 Expoの公式チュートリアル をやっていきたいと思います。 プロジェクトの作成 Download assets Install dependencies アプリの実行 コードの編集 テキストの文字色の変更 イメージの表示 ImageViewerコンポーネント Buttonコンポーネント PhotoButtonコンポーネント 画像の選択 まとめ 仲間募集 プロジェクトの作成 StickerSmash プロジェクトを作成しましょう。 npx create-expo-app StickerSmash && cd StickerSmash Download assets https://docs.expo.dev/static/images/tutorial/sticker-smash-assets.zip をダウンロードしてから解凍し、StickerSmash/assetsに格納します。既存のファイルは置き換えてください。 Install dependencies Webでも実行できるようにするために、必要なモジュールをインストールします。 npx expo install react-dom react-native-web @expo/webpack-config アプリの実行 プロジェクトの ディレクト リで、 npx expo start を実行します。 wを押すと、Webアプリを試すことができます。 次のように表示されました。 コードの編集 プロジェクトの ディレクト リで、 code . を実行して、 VS Code を立ち上げます。 背景を #25292e に変更しましょう。 const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: "#25292e", alignItems: "center", justifyContent: "center", }, }); 次のように表示されました。 テキストのデフォルトの文字色は黒なので、背景が黒っぽくなったことで、文字が見え辛くなってしまいました。 テキストの文字色の変更 Textタグのstyle属性で、文字の色を白に指定しましょう。 <Text style={{ color: "#fff" }}> Open up App.js to start working on your app! </Text> 次のように表示されました。 イメージの表示 イメージを表示しましょう。 Image コンポーネント をインポートします。 import { StyleSheet, View, Image } from 'react-native'; 次は、イメージパスの設定です。 const PlaceholderImage = require('./assets/images/background-image.png'); Imageタグを使う前に、 スタイルシート の設定をしましょう。 const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: "#25292e", alignItems: "center", }, imageContainer: { flex: 1, paddingTop: 58, }, image: { width: 320, height: 440, borderRadius: 18, }, }); 準備ができたので、Image コンポーネント を使ってみましょう。 <View style={styles.imageContainer}> <Image source={PlaceholderImage} style={styles.image} /> </View> 下記のように表示されました。 ImageViewer コンポーネント 先ほど作ったイメージ表示機能を コンポーネント 化しましょう。 StickSmash ディレクト リの中にcomponents ディレクト リを作成します。 .../StickerSmash$ mkdir components VS Code で ImageViewer.js を作成します。 code components/ImageViewer.js 下記のコードを ImageViewer.js に書き込みます。 import { StyleSheet, Image } from 'react-native'; export default function ImageViewer({ placeholderImageSource }) { return ( <Image source={placeholderImageSource} style={styles.image} /> ); } const styles = StyleSheet.create({ image: { width: 320, height: 440, borderRadius: 18, }, }); App.js から ImageViewer.js を呼び出します。 import ImageViewer from './components/ImageViewer'; const PlaceholderImage = require('./assets/images/background-image.png'); export default function App() { return ( <View style={styles.container}> <View style={styles.imageContainer}> <ImageViewer placeholderImageSource={PlaceholderImage} /> </View> <StatusBar style="auto" /> </View> ); } 見た目はもちろん以前と一緒です。 Button コンポーネント これからボタンを2つ作りますが、その前に、Button コンポーネント を作ってそれを利用することにしましょう。 VS Code で Button.js を作成します。 code components/Button.js 下記のコードを Button.js に書き込みます。 import { StyleSheet, View, Pressable, Text } from 'react-native'; export default function Button({ label }) { return ( <View style={styles.buttonContainer}> <Pressable style={styles.button} onPress={() => alert('You pressed a button.')}> <Text style={styles.buttonLabel}>{label}</Text> </Pressable> </View> ); } const styles = StyleSheet.create({ buttonContainer: { width: 320, height: 68, marginHorizontal: 20, alignItems: 'center', justifyContent: 'center', padding: 3, }, button: { borderRadius: 10, width: '100%', height: '100%', alignItems: 'center', justifyContent: 'center', flexDirection: 'row', }, buttonLabel: { color: '#fff', fontSize: 16, }, }); App.js から Button.js を呼び出します。 import Button from './components/Button'; <View style={styles.footerContainer}> <Button label="Choose a photo" /> <Button label="Use this photo" /> </View> const styles = StyleSheet.create({ // Styles that are unchanged from previous step are hidden for brevity. footerContainer: { flex: 1 / 3, alignItems: 'center', }, }); 下記のように表示されました。 PhotoButton コンポーネント 写真アイコンが表示されるボタンを作りましょう。 @expo/vector-icon をインストールします。 npx expo install @expo/vector-icons VS Code で PhotoButton.js を作成します。 code components/PhotoButton.js 下記のコードを PhotoButton.js に書き込みます。 import { StyleSheet, View, Pressable, Text } from "react-native"; import FontAwesome from "@expo/vector-icons/FontAwesome"; export default function PhotoButton({ label }) { return ( <View style={styles.buttonContainer}> <Pressable style={styles.button} onPress={() => alert("You pressed a button.")} > <FontAwesome name="picture-o" size={18} color="#25292e" style={styles.buttonIcon} /> <Text style={[styles.buttonLabel, {}]}>{label}</Text> </Pressable> </View> ); } const styles = StyleSheet.create({ buttonContainer: { width: 320, height: 68, marginHorizontal: 20, alignItems: "center", justifyContent: "center", padding: 3, borderWidth: 4, borderColor: "#ffd33d", borderRadius: 18, }, button: { borderRadius: 10, width: "100%", height: "100%", alignItems: "center", justifyContent: "center", flexDirection: "row", backgroundColor: "#fff", }, buttonIcon: { paddingRight: 8, }, buttonLabel: { color: "#25292e", fontSize: 16, }, }); 下記のように表示されました。 画像の選択 画像を選択する機能を実装しましょう。 expo-image-picker をインストールします。 npx expo install expo-image-picker App.js で pickImageAsync ファンクションを実装しましょう。選択した画像は、 result.assets[0].uri に入っています。 import * as ImagePicker from 'expo-image-picker'; const pickImageAsync = async () => { const result = await ImagePicker.launchImageLibraryAsync({ allowsEditing: true, quality: 1, }); if (!result.canceled) { alert(result.assets[0].uri); } else { alert('You did not select any image.'); } }; PhotoButton でボタンを押したときの動作が定義できるように、 onPress 属性を追加しましょう。 export default function PhotoButton({ label, onPress }) { return ( <View style={styles.buttonContainer}> <Pressable style={styles.button} onPress={onPress} > <FontAwesome name="picture-o" size={18} color="#25292e" style={styles.buttonIcon} /> <Text style={styles.buttonLabel>{label}</Text> </Pressable> </View> ); } App.js で PhotoButton が押されたときに、 pickImageAsync ファンクションを呼び出します。 <PhotoButton label="Choose a photo" onPress={pickImageAsync} /> ImageViewer で選択した画像を表示できるように、 selectedImage 属性を追加します。 export default function ImageViewer( { placeholderImageSource, selectedImage }) { const imageSource = selectedImage ? { uri: selectedImage } : placeholderImageSource; return <Image source={imageSource} style={styles.image} />; } App.js で、写真が選択されたら、 ImageViewer に表示します。 import { useState } from "react"; const PlaceholderImage = require("./assets/images/background-image.png"); export default function App() { const [selectedImage, setSelectedImage] = useState(null); const pickImageAsync = async () => { const result = await ImagePicker.launchImageLibraryAsync({ allowsEditing: true, quality: 1, }); if (!result.canceled) { setSelectedImage(result.assets[0].uri); } else { alert("You did not select any image."); } }; return ( <View style={styles.container}> <View style={styles.imageContainer}> <ImageViewer placeholderImageSource={PlaceholderImage} selectedImage={selectedImage} /> </View> <View style={styles.footerContainer}> <PhotoButton label="Choose a photo" onPress={pickImageAsync} /> <Button label="Use this photo" /> </View> <StatusBar style="auto" /> </View> ); } 下記のように表示されました。 切りが良いので、前編はここまでとします。 まとめ Expoの公式チュートリアル は、難易度もちょうどいい感じで、実践的な力が身につくなと感じました。ただ、 JavaScript じゃなくTypeScriptにしてほしかったところです。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 今回は、 Expoの公式チュートリアル をやっていきたいと思います。 プロジェクトの作成 Download assets Install dependencies アプリの実行 コードの編集 テキストの文字色の変更 イメージの表示 ImageViewerコンポーネント Buttonコンポーネント PhotoButtonコンポーネント 画像の選択 まとめ 仲間募集 プロジェクトの作成 StickerSmash プロジェクトを作成しましょう。 npx create-expo-app StickerSmash && cd StickerSmash Download assets https://docs.expo.dev/static/images/tutorial/sticker-smash-assets.zip をダウンロードしてから解凍し、StickerSmash/assetsに格納します。既存のファイルは置き換えてください。 Install dependencies Webでも実行できるようにするために、必要なモジュールをインストールします。 npx expo install react-dom react-native-web @expo/webpack-config アプリの実行 プロジェクトの ディレクト リで、 npx expo start を実行します。 wを押すと、Webアプリを試すことができます。 次のように表示されました。 コードの編集 プロジェクトの ディレクト リで、 code . を実行して、 VS Code を立ち上げます。 背景を #25292e に変更しましょう。 const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: "#25292e", alignItems: "center", justifyContent: "center", }, }); 次のように表示されました。 テキストのデフォルトの文字色は黒なので、背景が黒っぽくなったことで、文字が見え辛くなってしまいました。 テキストの文字色の変更 Textタグのstyle属性で、文字の色を白に指定しましょう。 <Text style={{ color: "#fff" }}> Open up App.js to start working on your app! </Text> 次のように表示されました。 イメージの表示 イメージを表示しましょう。 Image コンポーネント をインポートします。 import { StyleSheet, View, Image } from 'react-native'; 次は、イメージパスの設定です。 const PlaceholderImage = require('./assets/images/background-image.png'); Imageタグを使う前に、 スタイルシート の設定をしましょう。 const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: "#25292e", alignItems: "center", }, imageContainer: { flex: 1, paddingTop: 58, }, image: { width: 320, height: 440, borderRadius: 18, }, }); 準備ができたので、Image コンポーネント を使ってみましょう。 <View style={styles.imageContainer}> <Image source={PlaceholderImage} style={styles.image} /> </View> 下記のように表示されました。 ImageViewer コンポーネント 先ほど作ったイメージ表示機能を コンポーネント 化しましょう。 StickSmash ディレクト リの中にcomponents ディレクト リを作成します。 .../StickerSmash$ mkdir components VS Code で ImageViewer.js を作成します。 code components/ImageViewer.js 下記のコードを ImageViewer.js に書き込みます。 import { StyleSheet, Image } from 'react-native'; export default function ImageViewer({ placeholderImageSource }) { return ( <Image source={placeholderImageSource} style={styles.image} /> ); } const styles = StyleSheet.create({ image: { width: 320, height: 440, borderRadius: 18, }, }); App.js から ImageViewer.js を呼び出します。 import ImageViewer from './components/ImageViewer'; const PlaceholderImage = require('./assets/images/background-image.png'); export default function App() { return ( <View style={styles.container}> <View style={styles.imageContainer}> <ImageViewer placeholderImageSource={PlaceholderImage} /> </View> <StatusBar style="auto" /> </View> ); } 見た目はもちろん以前と一緒です。 Button コンポーネント これからボタンを2つ作りますが、その前に、Button コンポーネント を作ってそれを利用することにしましょう。 VS Code で Button.js を作成します。 code components/Button.js 下記のコードを Button.js に書き込みます。 import { StyleSheet, View, Pressable, Text } from 'react-native'; export default function Button({ label }) { return ( <View style={styles.buttonContainer}> <Pressable style={styles.button} onPress={() => alert('You pressed a button.')}> <Text style={styles.buttonLabel}>{label}</Text> </Pressable> </View> ); } const styles = StyleSheet.create({ buttonContainer: { width: 320, height: 68, marginHorizontal: 20, alignItems: 'center', justifyContent: 'center', padding: 3, }, button: { borderRadius: 10, width: '100%', height: '100%', alignItems: 'center', justifyContent: 'center', flexDirection: 'row', }, buttonLabel: { color: '#fff', fontSize: 16, }, }); App.js から Button.js を呼び出します。 import Button from './components/Button'; <View style={styles.footerContainer}> <Button label="Choose a photo" /> <Button label="Use this photo" /> </View> const styles = StyleSheet.create({ // Styles that are unchanged from previous step are hidden for brevity. footerContainer: { flex: 1 / 3, alignItems: 'center', }, }); 下記のように表示されました。 PhotoButton コンポーネント 写真アイコンが表示されるボタンを作りましょう。 @expo/vector-icon をインストールします。 npx expo install @expo/vector-icons VS Code で PhotoButton.js を作成します。 code components/PhotoButton.js 下記のコードを PhotoButton.js に書き込みます。 import { StyleSheet, View, Pressable, Text } from "react-native"; import FontAwesome from "@expo/vector-icons/FontAwesome"; export default function PhotoButton({ label }) { return ( <View style={styles.buttonContainer}> <Pressable style={styles.button} onPress={() => alert("You pressed a button.")} > <FontAwesome name="picture-o" size={18} color="#25292e" style={styles.buttonIcon} /> <Text style={[styles.buttonLabel, {}]}>{label}</Text> </Pressable> </View> ); } const styles = StyleSheet.create({ buttonContainer: { width: 320, height: 68, marginHorizontal: 20, alignItems: "center", justifyContent: "center", padding: 3, borderWidth: 4, borderColor: "#ffd33d", borderRadius: 18, }, button: { borderRadius: 10, width: "100%", height: "100%", alignItems: "center", justifyContent: "center", flexDirection: "row", backgroundColor: "#fff", }, buttonIcon: { paddingRight: 8, }, buttonLabel: { color: "#25292e", fontSize: 16, }, }); 下記のように表示されました。 画像の選択 画像を選択する機能を実装しましょう。 expo-image-picker をインストールします。 npx expo install expo-image-picker App.js で pickImageAsync ファンクションを実装しましょう。選択した画像は、 result.assets[0].uri に入っています。 import * as ImagePicker from 'expo-image-picker'; const pickImageAsync = async () => { const result = await ImagePicker.launchImageLibraryAsync({ allowsEditing: true, quality: 1, }); if (!result.canceled) { alert(result.assets[0].uri); } else { alert('You did not select any image.'); } }; PhotoButton でボタンを押したときの動作が定義できるように、 onPress 属性を追加しましょう。 export default function PhotoButton({ label, onPress }) { return ( <View style={styles.buttonContainer}> <Pressable style={styles.button} onPress={onPress} > <FontAwesome name="picture-o" size={18} color="#25292e" style={styles.buttonIcon} /> <Text style={styles.buttonLabel>{label}</Text> </Pressable> </View> ); } App.js で PhotoButton が押されたときに、 pickImageAsync ファンクションを呼び出します。 <PhotoButton label="Choose a photo" onPress={pickImageAsync} /> ImageViewer で選択した画像を表示できるように、 selectedImage 属性を追加します。 export default function ImageViewer( { placeholderImageSource, selectedImage }) { const imageSource = selectedImage ? { uri: selectedImage } : placeholderImageSource; return <Image source={imageSource} style={styles.image} />; } App.js で、写真が選択されたら、 ImageViewer に表示します。 import { useState } from "react"; const PlaceholderImage = require("./assets/images/background-image.png"); export default function App() { const [selectedImage, setSelectedImage] = useState(null); const pickImageAsync = async () => { const result = await ImagePicker.launchImageLibraryAsync({ allowsEditing: true, quality: 1, }); if (!result.canceled) { setSelectedImage(result.assets[0].uri); } else { alert("You did not select any image."); } }; return ( <View style={styles.container}> <View style={styles.imageContainer}> <ImageViewer placeholderImageSource={PlaceholderImage} selectedImage={selectedImage} /> </View> <View style={styles.footerContainer}> <PhotoButton label="Choose a photo" onPress={pickImageAsync} /> <Button label="Use this photo" /> </View> <StatusBar style="auto" /> </View> ); } 下記のように表示されました。 切りが良いので、前編はここまでとします。 まとめ Expoの公式チュートリアル は、難易度もちょうどいい感じで、実践的な力が身につくなと感じました。ただ、 JavaScript じゃなくTypeScriptにしてほしかったところです。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア 執筆： @higa （ Shodo で執筆されました ）

こんにちは！コミュニケーションIT事業部5年目の石田です。 普段は、 iPLAss というローコード開発プラットフォームの企画・開発・利用者サポートを主に担当しています。 この記事では、「若手による仕事の紹介」シリーズの一環として、私の業務内容や働き方についてお話しします。 自己紹介 まずは、簡単に自己紹介です。 2019 年に新卒入社し、2023 年で 5 年目を迎えました。 大学時代は 情報科学 を専攻しており、コンピュータやネットワークに関する知識・技術を系統的に学びつつ、 C言語 や Java を用いたプログラミング・研究開発といった実習も行っていました。 就職活動時点での方向性としては、専門性（技術力）を高めていくというよりは、ビジネス応用（IT・システムを手段として、如何に顧客の課題を解決していくか）により興味・関心がありました。 そこで、多種多様な業種・業態の顧客と接するチャンスがあり、 システム開発 の上流工程にも携わることのできると捉えていた システムインテグレーター （ SIer ）をターゲットに就職活動を進め、最終的には縁あってISIDに入社を決めました。 ところが、、、。 入社後に行われた システム開発 研修において、「実際に世の中で使用されているような実用的なWebアプリケーションを複数人のチームで開発する」という大学時代は得られなかった経験を通じて、すっかり「ものづくり」の面白さに魅了されてしまいました。 そこからは、専門性を磨き上げ、「自分で手を動かしてものづくりがしたい」、「高度な専門性をもって事業に貢献したい」という 就活時点とは全く異なるキャリア を志すようになりました。 これから業務内容に触れていきますが、そんな私にぴったりの業務を今は任せられており、毎日楽しく充実して働くことができています。 そして、 SIer という枠にはとどまらないほど、ISIDには多様な仕事があるということを入社して改めて知ることができました。各社員の強みや適性に合った業務があり、まさに今の私はその恩恵を受けることができているのだと思います。 製品開発という仕事 iPLAssとは 冒頭で述べた通り、配属後から一貫して「iPLAss」を軸に業務を行っています。 iPLAssとは、簡単に言えば、「複雑なシステムを早く作る」を実現する ISID製の ローコード開発プラットフォームです。公共分野や金融分野を中心に幅広い適用実績を持つ製品です。 iPLAssの詳細が知りたい方は、是非、 iPLAssのホームページ や ハンズオン記事 をご覧ください。 業務内容 製品開発の仕事は多岐に渡ります。例えば、チームマネジメント、新規機能の企画・開発、バグ報告への対処、品質向上、ホームページや開発者ドキュメントの整備、対外発信活動（技術記事の執筆など）、利用者サポート（問い合わせ対応、不具合調査など）が主な業務内容になります。 製品開発に終わりはなく、iPLAssは日々進化を続けています。iPLAssの利用者（iPLAssを利用してシステムを開発し、顧客に提供するチーム）は、現状、ISID社内のプロジェクトチームであることがほとんどです。その為、開発者と利用者とで密にコミュニケーションを取り、利用者が求める機能を迅速に開発したり、利用者から得られたフィードバックを基に製品の改良を重ねています。iPLAss開発チーム内でも、iPLAss利用者の利便性向上を目的とした機能追加や開発プラットフォームとしての機能充実化・既存機能の強化を日々検討し、改善に取り組んでいます。 また、iPLAssの開発を通じて得られたソフトウェア開発に関する知識や経験を、技術課題の解消やプロトタイピングなどといった形でプロジェクトチームに還元するといったことも自身の役割として上司からは期待されています。 やりがい やりがいは大きく2つあります。 1つ目は、iPLAssを利用して開発されたアプリケーションが世の中に公開され、多くの方に利用されていることが実感できた時にやりがいを感じます。やはり、自分の作ったものが広く利用されれば嬉しいものです！ 2つ目は、技術的な探究です。iPLAssの開発には、高度かつ幅広いプログラミングスキル・設計スキルが要求されます。また、 クラウド 連携など、技術トレンドに追随する能力も求められます。このように技術を突き詰める環境にいられることは、専門性を高めたいと考える私にとっては大きなやりがいとなっています。 働き方 業務の性質上、顧客と直接関わる機会は多くありません。また、社内外問わず、会議の頻度も他の社員と比べて多くはなく、どちらかと言えば1人でもくもくと作業をする時間が多いです。 ただ、毎週グループ内で雑談や情報共有を行う機会があったり、毎月上司と1on1ミーティングを実施していたりとコミュニケーションの不足をそれほど感じてはいません。 最後に 最後までお読みいただきありがとうございます。 ISIDでは、新卒・中途関わらず一緒に働く仲間を募集しています！ この記事を読んで、ISIDに少しでも興味を持っていただけたら、是非新卒採用サイトを覗いてみてください。 www.isid.co.jp 執筆： @ishida_yuma 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは！コミュニケーションIT事業部5年目の石田です。 普段は、 iPLAss というローコード開発プラットフォームの企画・開発・利用者サポートを主に担当しています。 この記事では、「若手による仕事の紹介」シリーズの一環として、私の業務内容や働き方についてお話しします。 自己紹介 まずは、簡単に自己紹介です。 2019 年に新卒入社し、2023 年で 5 年目を迎えました。 大学時代は 情報科学 を専攻しており、コンピュータやネットワークに関する知識・技術を系統的に学びつつ、 C言語 や Java を用いたプログラミング・研究開発といった実習も行っていました。 就職活動時点での方向性としては、専門性（技術力）を高めていくというよりは、ビジネス応用（IT・システムを手段として、如何に顧客の課題を解決していくか）により興味・関心がありました。 そこで、多種多様な業種・業態の顧客と接するチャンスがあり、 システム開発 の上流工程にも携わることのできると捉えていた システムインテグレーター （ SIer ）をターゲットに就職活動を進め、最終的には縁あってISIDに入社を決めました。 ところが、、、。 入社後に行われた システム開発 研修において、「実際に世の中で使用されているような実用的なWebアプリケーションを複数人のチームで開発する」という大学時代は得られなかった経験を通じて、すっかり「ものづくり」の面白さに魅了されてしまいました。 そこからは、専門性を磨き上げ、「自分で手を動かしてものづくりがしたい」、「高度な専門性をもって事業に貢献したい」という 就活時点とは全く異なるキャリア を志すようになりました。 これから業務内容に触れていきますが、そんな私にぴったりの業務を今は任せられており、毎日楽しく充実して働くことができています。 そして、 SIer という枠にはとどまらないほど、ISIDには多様な仕事があるということを入社して改めて知ることができました。各社員の強みや適性に合った業務があり、まさに今の私はその恩恵を受けることができているのだと思います。 製品開発という仕事 iPLAssとは 冒頭で述べた通り、配属後から一貫して「iPLAss」を軸に業務を行っています。 iPLAssとは、簡単に言えば、「複雑なシステムを早く作る」を実現する ISID製の ローコード開発プラットフォームです。公共分野や金融分野を中心に幅広い適用実績を持つ製品です。 iPLAssの詳細が知りたい方は、是非、 iPLAssのホームページ や ハンズオン記事 をご覧ください。 業務内容 製品開発の仕事は多岐に渡ります。例えば、チームマネジメント、新規機能の企画・開発、バグ報告への対処、品質向上、ホームページや開発者ドキュメントの整備、対外発信活動（技術記事の執筆など）、利用者サポート（問い合わせ対応、不具合調査など）が主な業務内容になります。 製品開発に終わりはなく、iPLAssは日々進化を続けています。iPLAssの利用者（iPLAssを利用してシステムを開発し、顧客に提供するチーム）は、現状、ISID社内のプロジェクトチームであることがほとんどです。その為、開発者と利用者とで密にコミュニケーションを取り、利用者が求める機能を迅速に開発したり、利用者から得られたフィードバックを基に製品の改良を重ねています。iPLAss開発チーム内でも、iPLAss利用者の利便性向上を目的とした機能追加や開発プラットフォームとしての機能充実化・既存機能の強化を日々検討し、改善に取り組んでいます。 また、iPLAssの開発を通じて得られたソフトウェア開発に関する知識や経験を、技術課題の解消やプロトタイピングなどといった形でプロジェクトチームに還元するといったことも自身の役割として上司からは期待されています。 やりがい やりがいは大きく2つあります。 1つ目は、iPLAssを利用して開発されたアプリケーションが世の中に公開され、多くの方に利用されていることが実感できた時にやりがいを感じます。やはり、自分の作ったものが広く利用されれば嬉しいものです！ 2つ目は、技術的な探究です。iPLAssの開発には、高度かつ幅広いプログラミングスキル・設計スキルが要求されます。また、 クラウド 連携など、技術トレンドに追随する能力も求められます。このように技術を突き詰める環境にいられることは、専門性を高めたいと考える私にとっては大きなやりがいとなっています。 働き方 業務の性質上、顧客と直接関わる機会は多くありません。また、社内外問わず、会議の頻度も他の社員と比べて多くはなく、どちらかと言えば1人でもくもくと作業をする時間が多いです。 ただ、毎週グループ内で雑談や情報共有を行う機会があったり、毎月上司と1on1ミーティングを実施していたりとコミュニケーションの不足をそれほど感じてはいません。 最後に 最後までお読みいただきありがとうございます。 ISIDでは、新卒・中途関わらず一緒に働く仲間を募集しています！ この記事を読んで、ISIDに少しでも興味を持っていただけたら、是非新卒採用サイトを覗いてみてください。 www.isid.co.jp 執筆： @ishida_yuma 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回はUE5でワープ機能（キャ ラク ターの移動とワープ時のカメラワーク）を作成します。 はじめに UEでは、ロードを挟まないひとつづきのマップのことを「レベル」と呼びます。 今回はそのような、同一のレベル内でプレイヤーが操作するキャ ラク ターを任意の場所へ移動させるワープの機能を紹介します。 レベル間移動をする場合（ロードをはさむ違うマップへの移動）には、違った処理が必要になるので、今回は同一レベル内でのみの移動について、紹介します。 検証環境/ツール OS： Windows 11 pro GPU ： NVIDIA GeForce RTX 4070 Ti Game Engine： Unreal Engine 5.2.0 実装手順 ワープゲートの作成 ワープ機能の作成 ワープ時の演出（カメラワーク） ワープ時の演出（フェードアウト） 1. ワープゲートの作成 今回はThirdPersonテンプレートを利用したプロジェクトで進めていきます。 まずはキャ ラク ターがワープをする際に使用するゲートを作成します。 ゲートのメッシュを作成しても良いですが、今回は簡略化のためにスターターコンテンツに入っている「SM_Doorframe」を使用します。 レベル上に入り口用と、出口用に2つ配置し、わかりやすいように「WarpGate1」「WarpGate2」と 命名 します。 それぞれのゲート用にマテリアルを作成します。 コンテンツドロワーよりマテリアルを作成し、下記画像のように設定を行いました。 詳細画面より「WarpGate1」のマテリアルに先ほど作成したマテリアルを適応させゲートを黄色くします。この黄色いゲートをワープの入り口として使用します。 同様に「WarpGate2」用のマテリアルを作成し適応させます。今回は青色のゲートにし、これをワープの出口として使用します。 本筋とは関係ないですが、もう少しワープゲートをリッチにしていきます。 コンテンツ追加からキューブを追加します。 サイズと位置を調整し、ワープゲートの内側と同じサイズに変更します。 また当たり判定をなくすために コリジョン プリセットの値を「No Collision」に変更しておきます。 次にマテリアルを作成し、「M_WarpEffect」と 命名 します。 「エミッシブカラー」のピンを「Multiply」に接続し、「A」のピンと「Vertex Color」と繋げます。さらに「B」のピンには「Constant」と繋げ、値を「50」に設定します。これにより光っているマテリアルが作成できます。 先ほど作成したキューブのマテリアルに適応させることで、ワープゲートがよりリッチになります。 複製して出口の方のゲートにも追加しておきます。 続いてワープの機能を作成していきましょう。 2. ワープ機能の作成 ワープの機能を実装するためにBlueprintを作成します。 コンテンツドロワーよりアクターのBlueprintを作成し「BP_ Warp 」とします。 コンテンツ追加より「Box Collision」を2つ追加し、「In」「Out」と 命名 します。 「DefaultSceneRoot」の大きさを、ワープゲートの内側の大きさに合うように調整します。 次に「BP_ Warp 」をレベル上に配置し、入り口の黄色いゲートの内側に配置します。 （下の画像で、出口の青いゲートはキャ ラク ターのワープをわかりやすくするために少し遠くに配置し直しています。） また、右側の詳細画面よりBoxCollisionの「Out」を選択し、出口の青いゲートに移動します。 このときBlueprint全体ではなく、「Out」だけを選択していることを確認してください。 次にキャ ラク ターが「In」の コリジョン に侵入した際に、キャ ラク ターの座標を「Out」の位置に変更する処理を作っていきます。 まずは「BP_ Warp 」を開き、 コンポーネント 一覧から「In」の コリジョン を右クリックして、 イベントを追加＞OnComponentBeginOverlapを選択します。 ノードが配置されたら、「Set Actor Location」ノードを配置して「On Component Begin Overlap」と繋ぎます。 「Set Actor Location」の「New Location」には出口のゲートの座標をセットするために「Get World Location」ノードを追加して、ターゲットに「Out」を繋げます。 開発中はキャ ラク ターの動きが見づらかったので、光るゲートの演出をオフにしています。 3. ワープ時の演出（カメラワーク） 続いて、キャ ラク ターがワープした際の演出を作成していきます。 アクタを配置からCineカメラアクタを選択して設置します。 設置をすると画面の右下に設置したカメラから見える映像が出てくるので、出口ゲートが見えるアングルへ移動させます。 （Current Focal Length の値を変えることで 焦点距離 を変えることができ、カメラの写りを調整できます。） 次にキャ ラク ターがワープをした時にカメラワークを切り替えたいので「BP_ Warp 」内に、ワープの最中かどうかを判定するためのフラグを「InWarpZone」という名前で作成します。また、後続の処理のために「Delay」を3秒に設定して下記画像のように設定します。 次にレベルブループリントを開きます。 キャ ラク ターがワープをしているかチェックするために「イベントTick」を使用して「InWarpZone」の変数を監視します。 「InWarpZone」がTrueになった場合に、カメラワークを切り替えるため「Set View Target with Blend」ノードを追加します。 「Set View Target with Blend」の「New View Target」には先ほど設置したCineカメラアクタを繋げます。 下記画像のようにレベルのViewPort詳細画面からイベントグラフへ ドラッグ&ドロップ を行います。 ターゲットには「Get Player Controller」をつなげます。 ここまででキャ ラク ターがワープをした時に、出口のワープゲートにカメラが移動し、ワープを演出するカメラワークができました。 ワープ完了後、視点を元に戻すため「Delay」を2秒でセットし、再び「Set View Target with Blend」ノードを作成します。 ターゲットには「Get Player Controller」、「New View Target」に「Get Player Character」をセットします。 4. ワープ時の演出（フェードアウト） ここまでの工程でカメラワークの設定が完了しましたが、もうすこし演出を加えるためにフェードアウト機能を追加します。 ユーザーインターフェイス より ウィジェット ブループリントを作成し「WBP_FadeOut」と 命名 します。 キャンバスパネル上にImageを追加し、画面いっぱいに広げます。 Tintのカラーピッカーを使用してimageの色を黒く変更します。 続いてフェードアウトのアニメーションを作成するため、タブからアニメーションを選択します。 アニメーション追加ボタンを押し「FadeOutAnimation」と 命名 します。トラック追加から「Image_31」を追加します。 さらに追加したレコードのプラスボタンから「Color and Opacity」を選択します。 追加された「Color and Opacity」の編集画面で、 RGBAのAlfaの値を下記のように設定します。 0秒：0 3秒：1 これにより、3秒間かけてゆっくりと暗転していくFadeOutのアニメーションができました。 再度レベルブループリントを開き、アニメーションを追加します。 カメラを移動させる1度目の「Set View Target with Blend」の前にフェードアウトを入れます。 「WBP Fade Out ウィジェット を作成」ノードから「Add Viewport」を繋げ、さらにアニメーションを再生するために「Play Animation」ノードを繋げます。 「Play Animation」のターゲットには「WBP Fade Out ウィジェット を作成」の返り値を繋げ、「In Animation」には「WBP Fade Out ウィジェット を作成」より引き出した「Fade out Animation」を使用します。 （細かい調整なので本筋とは関係ないですが、フェードアウトのアニメーションの後に3秒間の「Delay」を置いた方が綺麗な演出だったので「Delay」を追加しました。） カメラワークがゲートの出口に移動したタイミングでフェードアウトの ウィジェット を「Remove from Parent」を使用して削除します。 「イベントTick」で ウィジェット を作成しているため、「InWarpZone」のフラグがTrueのままだと ウィジェット を作り続けてしまうので、下記画像の位置でフラグをFalseに戻す処理も追加しておきます。 最後にウェジェットを作成しアニメーションを再生している最中はプレイヤーのキャ ラク ター操作をできないようにしておきたいので、 「WBP Fade Out ウィジェット を作成」の前に「Disable Input」ノードを追加します。 アニメーションが終わったタイミングでキャ ラク ター操作を有効化させるために、「Enable Input」を「Remove from Parent」の後に繋げます。 以上でワープ機能（キャ ラク ターの移動とワープ時のカメラワーク）が完成しました。 所感 UEを使用したゲームや ノンゲーム の領域でも、ワープ機能はUXを高めるために有効な手段だと考えているので、今回の実装でキャ ラク ターのワープ方法を学べてとてもためになりました。 またそれに伴ったカメラワークの方法や、フェードアウトなどのアニメーションの追加も、ユーザーがストレスなく体験するためにはとても重要なことだと感じました。 違和感なくユーザーが操作するためには、必要な要素がまだまだたくさんあるので、引き続きUEの勉強を続けようと思います。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 最後まで読んでいただきありがとうございました。 参考 https://historia.co.jp/archives/3198/ https://mostoad.com/ue4-part15 執筆： @okazaki.wataru 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回はUE5でワープ機能（キャ ラク ターの移動とワープ時のカメラワーク）を作成します。 はじめに UEでは、ロードを挟まないひとつづきのマップのことを「レベル」と呼びます。 今回はそのような、同一のレベル内でプレイヤーが操作するキャ ラク ターを任意の場所へ移動させるワープの機能を紹介します。 レベル間移動をする場合（ロードをはさむ違うマップへの移動）には、違った処理が必要になるので、今回は同一レベル内でのみの移動について、紹介します。 検証環境/ツール OS： Windows 11 pro GPU ： NVIDIA GeForce RTX 4070 Ti Game Engine： Unreal Engine 5.2.0 実装手順 ワープゲートの作成 ワープ機能の作成 ワープ時の演出（カメラワーク） ワープ時の演出（フェードアウト） 1. ワープゲートの作成 今回はThirdPersonテンプレートを利用したプロジェクトで進めていきます。 まずはキャ ラク ターがワープをする際に使用するゲートを作成します。 ゲートのメッシュを作成しても良いですが、今回は簡略化のためにスターターコンテンツに入っている「SM_Doorframe」を使用します。 レベル上に入り口用と、出口用に2つ配置し、わかりやすいように「WarpGate1」「WarpGate2」と 命名 します。 それぞれのゲート用にマテリアルを作成します。 コンテンツドロワーよりマテリアルを作成し、下記画像のように設定を行いました。 詳細画面より「WarpGate1」のマテリアルに先ほど作成したマテリアルを適応させゲートを黄色くします。この黄色いゲートをワープの入り口として使用します。 同様に「WarpGate2」用のマテリアルを作成し適応させます。今回は青色のゲートにし、これをワープの出口として使用します。 本筋とは関係ないですが、もう少しワープゲートをリッチにしていきます。 コンテンツ追加からキューブを追加します。 サイズと位置を調整し、ワープゲートの内側と同じサイズに変更します。 また当たり判定をなくすために コリジョン プリセットの値を「No Collision」に変更しておきます。 次にマテリアルを作成し、「M_WarpEffect」と 命名 します。 「エミッシブカラー」のピンを「Multiply」に接続し、「A」のピンと「Vertex Color」と繋げます。さらに「B」のピンには「Constant」と繋げ、値を「50」に設定します。これにより光っているマテリアルが作成できます。 先ほど作成したキューブのマテリアルに適応させることで、ワープゲートがよりリッチになります。 複製して出口の方のゲートにも追加しておきます。 続いてワープの機能を作成していきましょう。 2. ワープ機能の作成 ワープの機能を実装するためにBlueprintを作成します。 コンテンツドロワーよりアクターのBlueprintを作成し「BP_ Warp 」とします。 コンテンツ追加より「Box Collision」を2つ追加し、「In」「Out」と 命名 します。 「DefaultSceneRoot」の大きさを、ワープゲートの内側の大きさに合うように調整します。 次に「BP_ Warp 」をレベル上に配置し、入り口の黄色いゲートの内側に配置します。 （下の画像で、出口の青いゲートはキャ ラク ターのワープをわかりやすくするために少し遠くに配置し直しています。） また、右側の詳細画面よりBoxCollisionの「Out」を選択し、出口の青いゲートに移動します。 このときBlueprint全体ではなく、「Out」だけを選択していることを確認してください。 次にキャ ラク ターが「In」の コリジョン に侵入した際に、キャ ラク ターの座標を「Out」の位置に変更する処理を作っていきます。 まずは「BP_ Warp 」を開き、 コンポーネント 一覧から「In」の コリジョン を右クリックして、 イベントを追加＞OnComponentBeginOverlapを選択します。 ノードが配置されたら、「Set Actor Location」ノードを配置して「On Component Begin Overlap」と繋ぎます。 「Set Actor Location」の「New Location」には出口のゲートの座標をセットするために「Get World Location」ノードを追加して、ターゲットに「Out」を繋げます。 開発中はキャ ラク ターの動きが見づらかったので、光るゲートの演出をオフにしています。 3. ワープ時の演出（カメラワーク） 続いて、キャ ラク ターがワープした際の演出を作成していきます。 アクタを配置からCineカメラアクタを選択して設置します。 設置をすると画面の右下に設置したカメラから見える映像が出てくるので、出口ゲートが見えるアングルへ移動させます。 （Current Focal Length の値を変えることで 焦点距離 を変えることができ、カメラの写りを調整できます。） 次にキャ ラク ターがワープをした時にカメラワークを切り替えたいので「BP_ Warp 」内に、ワープの最中かどうかを判定するためのフラグを「InWarpZone」という名前で作成します。また、後続の処理のために「Delay」を3秒に設定して下記画像のように設定します。 次にレベルブループリントを開きます。 キャ ラク ターがワープをしているかチェックするために「イベントTick」を使用して「InWarpZone」の変数を監視します。 「InWarpZone」がTrueになった場合に、カメラワークを切り替えるため「Set View Target with Blend」ノードを追加します。 「Set View Target with Blend」の「New View Target」には先ほど設置したCineカメラアクタを繋げます。 下記画像のようにレベルのViewPort詳細画面からイベントグラフへ ドラッグ&ドロップ を行います。 ターゲットには「Get Player Controller」をつなげます。 ここまででキャ ラク ターがワープをした時に、出口のワープゲートにカメラが移動し、ワープを演出するカメラワークができました。 ワープ完了後、視点を元に戻すため「Delay」を2秒でセットし、再び「Set View Target with Blend」ノードを作成します。 ターゲットには「Get Player Controller」、「New View Target」に「Get Player Character」をセットします。 4. ワープ時の演出（フェードアウト） ここまでの工程でカメラワークの設定が完了しましたが、もうすこし演出を加えるためにフェードアウト機能を追加します。 ユーザーインターフェイス より ウィジェット ブループリントを作成し「WBP_FadeOut」と 命名 します。 キャンバスパネル上にImageを追加し、画面いっぱいに広げます。 Tintのカラーピッカーを使用してimageの色を黒く変更します。 続いてフェードアウトのアニメーションを作成するため、タブからアニメーションを選択します。 アニメーション追加ボタンを押し「FadeOutAnimation」と 命名 します。トラック追加から「Image_31」を追加します。 さらに追加したレコードのプラスボタンから「Color and Opacity」を選択します。 追加された「Color and Opacity」の編集画面で、 RGBAのAlfaの値を下記のように設定します。 0秒：0 3秒：1 これにより、3秒間かけてゆっくりと暗転していくFadeOutのアニメーションができました。 再度レベルブループリントを開き、アニメーションを追加します。 カメラを移動させる1度目の「Set View Target with Blend」の前にフェードアウトを入れます。 「WBP Fade Out ウィジェット を作成」ノードから「Add Viewport」を繋げ、さらにアニメーションを再生するために「Play Animation」ノードを繋げます。 「Play Animation」のターゲットには「WBP Fade Out ウィジェット を作成」の返り値を繋げ、「In Animation」には「WBP Fade Out ウィジェット を作成」より引き出した「Fade out Animation」を使用します。 （細かい調整なので本筋とは関係ないですが、フェードアウトのアニメーションの後に3秒間の「Delay」を置いた方が綺麗な演出だったので「Delay」を追加しました。） カメラワークがゲートの出口に移動したタイミングでフェードアウトの ウィジェット を「Remove from Parent」を使用して削除します。 「イベントTick」で ウィジェット を作成しているため、「InWarpZone」のフラグがTrueのままだと ウィジェット を作り続けてしまうので、下記画像の位置でフラグをFalseに戻す処理も追加しておきます。 最後にウェジェットを作成しアニメーションを再生している最中はプレイヤーのキャ ラク ター操作をできないようにしておきたいので、 「WBP Fade Out ウィジェット を作成」の前に「Disable Input」ノードを追加します。 アニメーションが終わったタイミングでキャ ラク ター操作を有効化させるために、「Enable Input」を「Remove from Parent」の後に繋げます。 以上でワープ機能（キャ ラク ターの移動とワープ時のカメラワーク）が完成しました。 所感 UEを使用したゲームや ノンゲーム の領域でも、ワープ機能はUXを高めるために有効な手段だと考えているので、今回の実装でキャ ラク ターのワープ方法を学べてとてもためになりました。 またそれに伴ったカメラワークの方法や、フェードアウトなどのアニメーションの追加も、ユーザーがストレスなく体験するためにはとても重要なことだと感じました。 違和感なくユーザーが操作するためには、必要な要素がまだまだたくさんあるので、引き続きUEの勉強を続けようと思います。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 最後まで読んでいただきありがとうございました。 参考 https://historia.co.jp/archives/3198/ https://mostoad.com/ue4-part15 執筆： @okazaki.wataru 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 皆さん kubernetes (以降 k8s )は使っていますか？ 今回はGKEなどのマネージドな k8s ではなく、オンプレミス環境での k8s 向けのノウハウを紹介する記事になります。 オンプレミス環境の Ingress で社内向けサービスと社外向けサービスを公開したい k8s で様々なサービスを提供していると、特定のサービスの公開先を制限したい場合があります。 認証などで制限を行うことも可能ですが、 IPアドレス などで制限したい場合もあります。具体的には、社外向けサービスと社内向けサービスでアクセスする先の IPアドレス が違うように設定することで、 ファイアウォール などの設定を行えるような状況が望ましいです。 マネージドサービスであれば、EKSだと標準の Ingress (Application LoadBalancer)を使って簡単に実現できる話だと思います。今回は同じようなことを Ingress -Nginx Controllerを使って実現する方法について紹介します。 オンプレミス環境における Ingress Controller k8s には公式の機能として Ingress Controllerは提供されていません。例えば、 kubeadm という k8s の公式な インストーラ があります。 このkubeadmで構築された k8s には Ingress Controllerはインストールされていません。 Ingress Controlerが存在しない状態だとユーザーは Ingress のリソースを作っても上手く動きません。 Ingress リソースをデプロイしてもControllerがないためPendingのまま起動しないといった結果になります。 マネージドな k8s の環境だとインフラとして、LoadBalancerが提供されておりそれらを k8s に統合するような Ingress Controllerの提供がされていることが多いです。例えば、 AWS ではApplication LoadBalancerを利用する Ingress Controlerの AWS Load Balancer Controllerが提供されており、ユーザーは自前でそれをインストールして使うといった具合です。 オンプレミス環境で利用可能な Ingress Controllerも存在しています。ソフトウェアのLoadBalancerと k8s を統合するような仕組みになっているものが多いようです。例えば、以下のようなものが比較的利用されていることが多い印象です。 Ingress -Nginx Controller ( https://kubernetes.github.io/ingress-nginx/ ) Traefik ( https://github.com/traefik/traefik ) contour ( https://github.com/projectcontour/contour ) 他にも様々な Ingress Controllerがあります。 Learnk8sという企業の方が、 Ingress Controllerを比較した資料( Google Spread Sheets)があります。 もし、これから Ingress Controllerを選択するという場合には参考になるかもしれません。 https://docs.google.com/spreadsheets/d/191WWNpjJ2za6-nbG4ZoUMXMpUK8KlCIosvQB0f-oq3k/ 今回は、このなかの Ingress -Nginx Controllerについてのノウハウを公開するものになります。 また、 Ingress -Nginx Controllerは Type: Loadbalancer を指定した Service を作ることができる k8s でなければ上手く動作しません。今回は、 MetalLB を採用している環境を想定しています。 Ingress -Nginx Controllerのインストール Ingress -Nginx Controller は helm を使ってインストールすることが出来ます。 helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm install ingress-nginx ingress-nginx/ingress-nginx --create-namespace -n ingress-system 上記の手順で、 ingress -systemというnamespaceに ingress -nginxがインストールされます。 インストール後、 kubectl get pod -n ingress-system などを実行すると 動作が確認できるかと思います。また、 ingressclass というリソースも作成されます。 上記の手順では、 nginx という名前のingressclassが作られるかと思います。 Ingress -Nginx で Ingress を複数作った場合の動作 さて、これで Ingress を利用できる k8s 環境になりました。 例えば以下のような形で Ingress を作ることができる様になりました。 apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : public-service-ingress namespace : public-service spec : ingressClassName : nginx rules : - host : public.example.com http : paths : - backend : service : name : nginx port : number : 80 path : / pathType : Prefix これで、外部公開しても良いサービスを Ingress で公開できました。 次に、内部に限定公開するサービスを同様に Ingress で作ろうとします。 例えば、以下のようなリソースになるでしょうか。 apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : private-service-ingress namespace : private-service spec : ingressClassName : nginx rules : - host : private.example.com http : paths : - backend : service : name : nginx port : number : 80 path : / pathType : Prefix うまく動くように思いますが、実際に適用すると問題があります。 何が問題なのでしょうか？ kubectl get ingress -A などで ingress の状況を確認してみます。 以下のような結果が得られます。(若干編集してあります) NAMESPACE NAME CLASS HOSTS ADDRESS PORTS AGE public-service public-service-ingress nginx public.example.com 192.168.1.10 80, 443 XXd private-service private-service-ingress nginx private.example.com 192.168.1.10 80, 443 XXd ADDRESSのところを見てみると、なんと同じ IPアドレス が使われていますね。 IPアドレス なども含めて社外と社内のサービスを分けたいと考えていたのでこれは困ります。 これは、 Ingress -Nginxの仕様でingressclassが同じものは同一のnginxにまとめてしまう動作によるものです。 マネージドな k8s だと Ingress に対応してロードバランサが払い出されるものが多いです。これと同じ挙動を期待してはいけないようです。 IPが別の Ingress を作成するには？ Ingress -NginxでIPが異なるNginxを払い出すにはどうすればいいのでしょうか？ 公式のマニュアルに解説があります。 https://docs.nginx.com/nginx-ingress-controller/installation/running-multiple-ingress-controllers/ Ingress -NginxはIngressClassが別に指定されているControllerを追加で起動する必要があるようです。 controllerから完全に別のものをインストールする必要があるので、helmを使って別途インストールするのが手っ取り早そうです。 private-ingress-nginx という ingressclass を指定した ingress -nginx をhelmでインストールします。 helm install -n private-ingress \ --set controller.ingressClass="private-ingress-nginx" \ --set controller.ingressClassResource.name="private-ingress-nginx" \ --set controller.ingressClassResource.controllerValue="k8s.io/private-ingress-nginx" \ --create-namespace \ private-ingress-nginx \ ingress-nginx/ingress-nginx インストール後、 kubectl get pod -n private-ingress-system などを実行してコントローラが動作していることを確認します。さらに、ingressclassが新しく生成されているかを kubectl get ingressclass で確認します。 ingressclassが2種類出力されれば無事設定できています。 NAME CONTROLLER PARAMETERS AGE private-ingress-nginx k8s.io/private-ingress-nginx <none> XXXd nginx k8s.io/ingress-nginx <none> XXXd この環境で先ほどと同じように複数 Ingress を作成してみましょう。 まずは、publicな Ingress です。これは前回と同じものを作成します。 apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : public-service-ingress namespace : public-service spec : ingressClassName : nginx rules : - host : public.example.com http : paths : - backend : service : name : nginx port : number : 80 path : / pathType : Prefix 次に、内部に限定公開するサービスを作ります。 今回は、 ingressClassName に private-ingress-nginx を指定します。 apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : private-service-ingress namespace : private-service spec : ingressClassName : private-ingress-nginx rules : - host : private.example.com http : paths : - backend : service : name : nginx port : number : 80 path : / pathType : Prefix さて、 ingress にちゃんと別の IPアドレス が付与されたか確認してみます。 kubectl get ingress -A を実行してみます。 NAMESPACE NAME CLASS HOSTS ADDRESS PORTS AGE public-service public-service-ingress nginx public.example.com 192.168.1.10 80, 443 XXXd private-service private-service-ingress private-ingress-nginx private.example.com 192.168.1.11 80, 443 XXXd ちゃんと別の IPアドレス が付与されていることを確認できました！ これで、アクセス先の IPアドレス が社外サービスと社内サービスで違う状態になったので、アクセス制御などが実施しやすくなりました。 まとめ 今回は、オンプレミス環境の k8s 上で Ingress を使う方法、 Ingress -Nginx controllerを使う場合に社外向け、社内向けといった区分けで異なるIPを持っている Ingress を作成する方法について紹介しました。オンプレミス環境で k8s を運用している方の参考になれば幸いです。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 皆さん kubernetes (以降 k8s )は使っていますか？ 今回はGKEなどのマネージドな k8s ではなく、オンプレミス環境での k8s 向けのノウハウを紹介する記事になります。 オンプレミス環境の Ingress で社内向けサービスと社外向けサービスを公開したい k8s で様々なサービスを提供していると、特定のサービスの公開先を制限したい場合があります。 認証などで制限を行うことも可能ですが、 IPアドレス などで制限したい場合もあります。具体的には、社外向けサービスと社内向けサービスでアクセスする先の IPアドレス が違うように設定することで、 ファイアウォール などの設定を行えるような状況が望ましいです。 マネージドサービスであれば、EKSだと標準の Ingress (Application LoadBalancer)を使って簡単に実現できる話だと思います。今回は同じようなことを Ingress -Nginx Controllerを使って実現する方法について紹介します。 オンプレミス環境における Ingress Controller k8s には公式の機能として Ingress Controllerは提供されていません。例えば、 kubeadm という k8s の公式な インストーラ があります。 このkubeadmで構築された k8s には Ingress Controllerはインストールされていません。 Ingress Controlerが存在しない状態だとユーザーは Ingress のリソースを作っても上手く動きません。 Ingress リソースをデプロイしてもControllerがないためPendingのまま起動しないといった結果になります。 マネージドな k8s の環境だとインフラとして、LoadBalancerが提供されておりそれらを k8s に統合するような Ingress Controllerの提供がされていることが多いです。例えば、 AWS ではApplication LoadBalancerを利用する Ingress Controlerの AWS Load Balancer Controllerが提供されており、ユーザーは自前でそれをインストールして使うといった具合です。 オンプレミス環境で利用可能な Ingress Controllerも存在しています。ソフトウェアのLoadBalancerと k8s を統合するような仕組みになっているものが多いようです。例えば、以下のようなものが比較的利用されていることが多い印象です。 Ingress -Nginx Controller ( https://kubernetes.github.io/ingress-nginx/ ) Traefik ( https://github.com/traefik/traefik ) contour ( https://github.com/projectcontour/contour ) 他にも様々な Ingress Controllerがあります。 Learnk8sという企業の方が、 Ingress Controllerを比較した資料( Google Spread Sheets)があります。 もし、これから Ingress Controllerを選択するという場合には参考になるかもしれません。 https://docs.google.com/spreadsheets/d/191WWNpjJ2za6-nbG4ZoUMXMpUK8KlCIosvQB0f-oq3k/ 今回は、このなかの Ingress -Nginx Controllerについてのノウハウを公開するものになります。 また、 Ingress -Nginx Controllerは Type: Loadbalancer を指定した Service を作ることができる k8s でなければ上手く動作しません。今回は、 MetalLB を採用している環境を想定しています。 Ingress -Nginx Controllerのインストール Ingress -Nginx Controller は helm を使ってインストールすることが出来ます。 helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm install ingress-nginx ingress-nginx/ingress-nginx --create-namespace -n ingress-system 上記の手順で、 ingress -systemというnamespaceに ingress -nginxがインストールされます。 インストール後、 kubectl get pod -n ingress-system などを実行すると 動作が確認できるかと思います。また、 ingressclass というリソースも作成されます。 上記の手順では、 nginx という名前のingressclassが作られるかと思います。 Ingress -Nginx で Ingress を複数作った場合の動作 さて、これで Ingress を利用できる k8s 環境になりました。 例えば以下のような形で Ingress を作ることができる様になりました。 apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : public-service-ingress namespace : public-service spec : ingressClassName : nginx rules : - host : public.example.com http : paths : - backend : service : name : nginx port : number : 80 path : / pathType : Prefix これで、外部公開しても良いサービスを Ingress で公開できました。 次に、内部に限定公開するサービスを同様に Ingress で作ろうとします。 例えば、以下のようなリソースになるでしょうか。 apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : private-service-ingress namespace : private-service spec : ingressClassName : nginx rules : - host : private.example.com http : paths : - backend : service : name : nginx port : number : 80 path : / pathType : Prefix うまく動くように思いますが、実際に適用すると問題があります。 何が問題なのでしょうか？ kubectl get ingress -A などで ingress の状況を確認してみます。 以下のような結果が得られます。(若干編集してあります) NAMESPACE NAME CLASS HOSTS ADDRESS PORTS AGE public-service public-service-ingress nginx public.example.com 192.168.1.10 80, 443 XXd private-service private-service-ingress nginx private.example.com 192.168.1.10 80, 443 XXd ADDRESSのところを見てみると、なんと同じ IPアドレス が使われていますね。 IPアドレス なども含めて社外と社内のサービスを分けたいと考えていたのでこれは困ります。 これは、 Ingress -Nginxの仕様でingressclassが同じものは同一のnginxにまとめてしまう動作によるものです。 マネージドな k8s だと Ingress に対応してロードバランサが払い出されるものが多いです。これと同じ挙動を期待してはいけないようです。 IPが別の Ingress を作成するには？ Ingress -NginxでIPが異なるNginxを払い出すにはどうすればいいのでしょうか？ 公式のマニュアルに解説があります。 https://docs.nginx.com/nginx-ingress-controller/installation/running-multiple-ingress-controllers/ Ingress -NginxはIngressClassが別に指定されているControllerを追加で起動する必要があるようです。 controllerから完全に別のものをインストールする必要があるので、helmを使って別途インストールするのが手っ取り早そうです。 private-ingress-nginx という ingressclass を指定した ingress -nginx をhelmでインストールします。 helm install -n private-ingress \ --set controller.ingressClass="private-ingress-nginx" \ --set controller.ingressClassResource.name="private-ingress-nginx" \ --set controller.ingressClassResource.controllerValue="k8s.io/private-ingress-nginx" \ --create-namespace \ private-ingress-nginx \ ingress-nginx/ingress-nginx インストール後、 kubectl get pod -n private-ingress-system などを実行してコントローラが動作していることを確認します。さらに、ingressclassが新しく生成されているかを kubectl get ingressclass で確認します。 ingressclassが2種類出力されれば無事設定できています。 NAME CONTROLLER PARAMETERS AGE private-ingress-nginx k8s.io/private-ingress-nginx <none> XXXd nginx k8s.io/ingress-nginx <none> XXXd この環境で先ほどと同じように複数 Ingress を作成してみましょう。 まずは、publicな Ingress です。これは前回と同じものを作成します。 apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : public-service-ingress namespace : public-service spec : ingressClassName : nginx rules : - host : public.example.com http : paths : - backend : service : name : nginx port : number : 80 path : / pathType : Prefix 次に、内部に限定公開するサービスを作ります。 今回は、 ingressClassName に private-ingress-nginx を指定します。 apiVersion : networking.k8s.io/v1 kind : Ingress metadata : name : private-service-ingress namespace : private-service spec : ingressClassName : private-ingress-nginx rules : - host : private.example.com http : paths : - backend : service : name : nginx port : number : 80 path : / pathType : Prefix さて、 ingress にちゃんと別の IPアドレス が付与されたか確認してみます。 kubectl get ingress -A を実行してみます。 NAMESPACE NAME CLASS HOSTS ADDRESS PORTS AGE public-service public-service-ingress nginx public.example.com 192.168.1.10 80, 443 XXXd private-service private-service-ingress private-ingress-nginx private.example.com 192.168.1.11 80, 443 XXXd ちゃんと別の IPアドレス が付与されていることを確認できました！ これで、アクセス先の IPアドレス が社外サービスと社内サービスで違う状態になったので、アクセス制御などが実施しやすくなりました。 まとめ 今回は、オンプレミス環境の k8s 上で Ingress を使う方法、 Ingress -Nginx controllerを使う場合に社外向け、社内向けといった区分けで異なるIPを持っている Ingress を作成する方法について紹介しました。オンプレミス環境で k8s を運用している方の参考になれば幸いです。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

ISID X（クロス） イノベーション 本部 の三浦です。 筆者の関わっている案件では、多数の AWS アカウント、ec2、ecsが存在しています。 で、大量のリソースがあるとSavings Plansの管理も大変であり、下記のようなツールを作成してSavings Plansの購入をしております（以後Savings PlansはSPと省略します）。 フェデレーションでアカウントの認証情報一括取得（200アカウント弱） ec2一覧、ecs task一覧を作成（SP購入不要の場合は、タグによって除外） 各アカウントごとに必要なSP量を計算 現在購入済みSP料と比べ、SP不足分を算出 不足分のSPを購入 で、上記のような作業をエクセルベースでやっている方も多いかと思いますが、 AWS のホームページから手動でSPの額をコピーするのは骨が折れる作業です。 なので、今回は、上記の情報に該当するデータを csv として取得する方法について記述します。 目次 目次 スクリプト内容解説 その他SP運用に関するFAQ まとめ スクリプト 内容解説 下記、リンクはcloudshell 上で使うことを前提とした スクリプト です。 ############ ステップ1：まずはこのコマンドをCloudShellで実行してください ############ pwsh ############ ステップ2：ここから下を全てコピーして実行してください ############ Import-Module AWSPowerShell.NetCore function Get-Ec2ComputeSavingsPlans { [CmdletBinding()] param ( $region , $productDescription ) $fileter = @( @{Name = "tenancy" ; Values = "shared" } , @{Name = "region" ; Values = $region } , @{Name = "productDescription" ; Values = $productDescription } ) $sp = Get-SPSavingsPlansOfferingRate -Product EC2 -SavingsPlanPaymentOption "All Upfront" -ServiceCode AmazonEC2 -SavingsPlanType Compute -region ap-northeast-1 -MaxResult 1000 -Filter $fileter $result = $sp | % { $xxx = "" | select Region , Rate , instanceType , productDescription , UsageType , UsageType_ARC_CPU_GB , OfferingId , PaymentOption , PlanDescription , PlanType , DurationSeconds , KEY $xxx .Region = $_ .Properties | ? Name -eq region | % { $_ .Value } $xxx .Rate = $_ .Rate $xxx .UsageType = $_ .UsageType $xxx .instanceType = ( $_ .Properties | ? Name -eq instanceType | % { $_ .Value }) $xxx .productDescription = $productDescription $xxx .UsageType_ARC_CPU_GB = ( $_ .Properties | ? Name -eq productDescription | % { $_ .Value }) + "_" + ( $_ .Properties | ? Name -eq instanceType | % { $_ .Value }) $xxx .OfferingId = $_ .SavingsPlanOffering.OfferingId $xxx .PaymentOption = $_ .SavingsPlanOffering.PaymentOption.Value $xxx .PlanDescription = $_ .SavingsPlanOffering.PlanDescription $xxx .PlanType = $_ .SavingsPlanOffering.PlanType.Value $xxx .DurationSeconds = $_ .SavingsPlanOffering.DurationSeconds $xxx .Key = $xxx .Region + "_" + $xxx .DurationSeconds + "_" + $xxx .UsageType_ARC_CPU_GB $xxx } return $result } $productList = @( "Linux/UNIX" , "Windows" , "Red Hat Enterprise Linux" ) $resultList = @() $productList |% { $p = $_ ## 一部の条件は決め打ち ## 全額前払い、共有テナンシー、 ## 対象は、Amazon EC2 の Compute Savings PlansのみでFargate の Compute Savings Planや ## インスタンスファミリー Savings Plan の料金は取得対象外 $l = Get-Ec2ComputeSavingsPlans -region ap-northeast-1 -productDescription $p $resultList += $l } $exportPath = "sp_list.csv" $resultList | Export-Csv -Path $exportPath -Encoding UTF8 -NoTypeInformation なお、コアの部分は下記となります。各社、必要な条件に変えご利用ください（ISIDの場合、全額前払いでよいので割引率重視で全額前払い固定にしてます）。 #$productList = @("Linux/UNIX","Windows","Red Hat Enterprise Linux") $fileter = @( @{Name = "tenancy" ; Values = "shared" } , @{Name = "region" ; Values = $region } , @{Name = "productDescription" ; Values = $productDescription } ) $sp = Get-SPSavingsPlansOfferingRate -Product EC2 -SavingsPlanPaymentOption "All Upfront" -ServiceCode AmazonEC2 -SavingsPlanType Compute -region ap-northeast-1 -MaxResult 1000 -Filter $fileter 下記に実行イメージを示します。 CloudShellの右上の「Actions > Dwonload file」から、下記のようなダイアログでファイルを取得できます。 コア部分は上ぐらいの非常にシンプルなコードです。productDescriptionはかなりの種別が存在しますので、上記以外のプロダクトタイプが必要な場合は追記してください。 その他SP運用に関するFAQ Q1. 　「Savings Plans > 推奨事項」 で簡易に必要SP量が見積もれるはずですが、なぜいちいち計算しているのですか？ A1. 　上記の機能は、一括請求配下ですと他のアカウントの リザーブ ド インスタンス 、SPの影響を受けてしまい正しい予測ができません。アカウント単位で必要なSP量を都度計算するようにしています。 Q2. 　一括請求有効化、 リザーブ ド インスタンス 共有の場合、アカウント単位の正しいコストを把握するのは非常に難しい認識ですがどのように計算しているのですか？ A2. 専用の会計ツールを導入しております。 リザーブ ド インスタンス を共有している場合、 AWS 純正の機能で正しいコストを判断するのは非常に難しいです。 まとめ ということで、アカウントが多い場合、SP購入業務は結構大変な業務だと感じておりますが、自動化の一助になるかと思いSPの価格取得について記述しました。 なお、実業務としては↑全体を スクリプト 化して運用しております。しかし、バグがあるとかなり大変なので、この業務の自動化を検討される方は入念なテストを強くお勧めします。 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @miura.toshihiko 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

ISID X（クロス） イノベーション 本部 の三浦です。 筆者の関わっている案件では、多数の AWS アカウント、ec2、ecsが存在しています。 で、大量のリソースがあるとSavings Plansの管理も大変であり、下記のようなツールを作成してSavings Plansの購入をしております（以後Savings PlansはSPと省略します）。 フェデレーションでアカウントの認証情報一括取得（200アカウント弱） ec2一覧、ecs task一覧を作成（SP購入不要の場合は、タグによって除外） 各アカウントごとに必要なSP量を計算 現在購入済みSP料と比べ、SP不足分を算出 不足分のSPを購入 で、上記のような作業をエクセルベースでやっている方も多いかと思いますが、 AWS のホームページから手動でSPの額をコピーするのは骨が折れる作業です。 なので、今回は、上記の情報に該当するデータを csv として取得する方法について記述します。 目次 目次 スクリプト内容解説 その他SP運用に関するFAQ まとめ スクリプト 内容解説 下記、リンクはcloudshell 上で使うことを前提とした スクリプト です。 ############ ステップ1：まずはこのコマンドをCloudShellで実行してください ############ pwsh ############ ステップ2：ここから下を全てコピーして実行してください ############ Import-Module AWSPowerShell.NetCore function Get-Ec2ComputeSavingsPlans { [CmdletBinding()] param ( $region , $productDescription ) $fileter = @( @{Name = "tenancy" ; Values = "shared" } , @{Name = "region" ; Values = $region } , @{Name = "productDescription" ; Values = $productDescription } ) $sp = Get-SPSavingsPlansOfferingRate -Product EC2 -SavingsPlanPaymentOption "All Upfront" -ServiceCode AmazonEC2 -SavingsPlanType Compute -region ap-northeast-1 -MaxResult 1000 -Filter $fileter $result = $sp | % { $xxx = "" | select Region , Rate , instanceType , productDescription , UsageType , UsageType_ARC_CPU_GB , OfferingId , PaymentOption , PlanDescription , PlanType , DurationSeconds , KEY $xxx .Region = $_ .Properties | ? Name -eq region | % { $_ .Value } $xxx .Rate = $_ .Rate $xxx .UsageType = $_ .UsageType $xxx .instanceType = ( $_ .Properties | ? Name -eq instanceType | % { $_ .Value }) $xxx .productDescription = $productDescription $xxx .UsageType_ARC_CPU_GB = ( $_ .Properties | ? Name -eq productDescription | % { $_ .Value }) + "_" + ( $_ .Properties | ? Name -eq instanceType | % { $_ .Value }) $xxx .OfferingId = $_ .SavingsPlanOffering.OfferingId $xxx .PaymentOption = $_ .SavingsPlanOffering.PaymentOption.Value $xxx .PlanDescription = $_ .SavingsPlanOffering.PlanDescription $xxx .PlanType = $_ .SavingsPlanOffering.PlanType.Value $xxx .DurationSeconds = $_ .SavingsPlanOffering.DurationSeconds $xxx .Key = $xxx .Region + "_" + $xxx .DurationSeconds + "_" + $xxx .UsageType_ARC_CPU_GB $xxx } return $result } $productList = @( "Linux/UNIX" , "Windows" , "Red Hat Enterprise Linux" ) $resultList = @() $productList |% { $p = $_ ## 一部の条件は決め打ち ## 全額前払い、共有テナンシー、 ## 対象は、Amazon EC2 の Compute Savings PlansのみでFargate の Compute Savings Planや ## インスタンスファミリー Savings Plan の料金は取得対象外 $l = Get-Ec2ComputeSavingsPlans -region ap-northeast-1 -productDescription $p $resultList += $l } $exportPath = "sp_list.csv" $resultList | Export-Csv -Path $exportPath -Encoding UTF8 -NoTypeInformation なお、コアの部分は下記となります。各社、必要な条件に変えご利用ください（ISIDの場合、全額前払いでよいので割引率重視で全額前払い固定にしてます）。 #$productList = @("Linux/UNIX","Windows","Red Hat Enterprise Linux") $fileter = @( @{Name = "tenancy" ; Values = "shared" } , @{Name = "region" ; Values = $region } , @{Name = "productDescription" ; Values = $productDescription } ) $sp = Get-SPSavingsPlansOfferingRate -Product EC2 -SavingsPlanPaymentOption "All Upfront" -ServiceCode AmazonEC2 -SavingsPlanType Compute -region ap-northeast-1 -MaxResult 1000 -Filter $fileter 下記に実行イメージを示します。 CloudShellの右上の「Actions > Dwonload file」から、下記のようなダイアログでファイルを取得できます。 コア部分は上ぐらいの非常にシンプルなコードです。productDescriptionはかなりの種別が存在しますので、上記以外のプロダクトタイプが必要な場合は追記してください。 その他SP運用に関するFAQ Q1. 　「Savings Plans > 推奨事項」 で簡易に必要SP量が見積もれるはずですが、なぜいちいち計算しているのですか？ A1. 　上記の機能は、一括請求配下ですと他のアカウントの リザーブ ド インスタンス 、SPの影響を受けてしまい正しい予測ができません。アカウント単位で必要なSP量を都度計算するようにしています。 Q2. 　一括請求有効化、 リザーブ ド インスタンス 共有の場合、アカウント単位の正しいコストを把握するのは非常に難しい認識ですがどのように計算しているのですか？ A2. 専用の会計ツールを導入しております。 リザーブ ド インスタンス を共有している場合、 AWS 純正の機能で正しいコストを判断するのは非常に難しいです。 まとめ ということで、アカウントが多い場合、SP購入業務は結構大変な業務だと感じておりますが、自動化の一助になるかと思いSPの価格取得について記述しました。 なお、実業務としては↑全体を スクリプト 化して運用しております。しかし、バグがあるとかなり大変なので、この業務の自動化を検討される方は入念なテストを強くお勧めします。 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @miura.toshihiko 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 1年ほど前に書いたブログ では、組織横断的に Security Hub の利用をサポートするための準備について書きました。あれから1年が経ち、今は社内の数百アカウントの Security Hub 利用をサポートしています。この記事では、 Security Hub の社内展開の運用で利用しているツール群をご紹介します。 なお、Security Hub の利用サポートは社内の SOC という組織で行っています。 SOC の組織的な立ち位置や役割は こちらのブログ でご紹介しています。 改めてまとめると、SOC は社内の各事業部のプロジェクトに対し、以下の2つのサービスを提供しています。 クラウド サービスのセキュリティ設定不備のチェック（Security Hubのセキュリティ基準） クラウド アカウントに対する脅威の検出（Security Hub + GuardDuty） 概要 ①アカウント連携申請フォーム（Jira Service Management） ②アカウント管理台帳（Excel） ③アカウント連携招待ツール（Lambda関数） ④アカウント連携セットアップスクリプト（PowerShellスクリプト） ⑤アカウント連携チェックツール（Lambda関数） ⑥検出結果配信ツール （ECSバッチアプリ） ⑦脅威検知通知ツール（Lambda関数） ⑧アカウント連携解除ツール（PowerShellスクリプト） ⑨セキュリティコントロールの対応方針、 セキュリティ設定ガイド（Excel, PowerPoint） まとめ 概要 SOC のサービスの運用で使用しているツールなどを1つの図にまとめました。 各プロジェクトが使用している AWS アカウントの Security Hub から、SOC の AWS アカウントへクロスアカウント連携することで、 SOC 側で一括してセキュリティ設定やアラートを取得し、情報配信や監視を行う組織体制です。各ツールの詳細を図の番号順で見ていきます。 ①アカウント連携申請フォーム（Jira Service Management） SOC のサービスを利用するかどうかは、各プロジェクトの判断に委ねています。 SOC を利用する場合は社内向けの Jira Service Management を利用し、申請を受け付けています。申請の種類には AWS アカウントの追加、変更、解除が含まれます。 ②アカウント管理台帳（ Excel ） AWS アカウントIDとプロジェクトの連絡先などの マッピング を記載したアカウント管理台帳を用意し、プロジェクトから申請を受け付けたら更新します。 現在の申請数であれば特に運用負荷となっておらず、自動化するとなると申請者の権限管理が逆に難しそうなので、今のところ手動作業です。 ③アカウント連携招待ツール（Lambda関数） ②のアカウント管理台帳を更新したら、SOC の AWS アカウントにある S3 バケット にファイルをアップロードします。 S3 バケットのイベント通知機能 を利用し、ファイルがアップロードされると自動でLambda関数を起動し、ファイルの内容を読み取って、未招待のプロジェクトアカウントへ Security Hub の連携招待 を送信します。 ④アカウント連携セットアップ スクリプト （ PowerShell スクリプト ） Security Hub の招待を受けたメンバーアカウントではいくつかのセットアップ作業が必要です。 Security Hub の有効化と、セキュリティ基準の有効化（まだ有効化していない場合） Security Hub 招待の承諾 AWS Config の有効化（まだ有効化していない場合） GuardDuty の有効化（まだ有効化していない場合） これらを社内のプロジェクト担当者に簡単に実施してもらえるように、CloudShell で流すだけで一連のセットアップが完了する PowerShell スクリプト を用意しています。 ⑤アカウント連携チェックツール（Lambda関数） プロジェクト担当者が④の スクリプト を実行するタイミングは任意です。そこで②のアカウント管理台帳や SOC アカウントの Security Hub などからデータを取得し、セットアップが完了していないアカウントがあるかどうか Lambda 関数で定期的にチェック、結果を SOC 担当のチャットに通知しています。 ⑥検出結果配信ツール （ECSバッチアプリ） プロジェクトアカウントに対して定期的に Security Hub の検出結果を Excel レポートとして配信するバッチアプリを ECS Fargate で実行します。 詳細は 以前のブログ でご説明しています。 ⑦脅威検知通知ツール（Lambda関数） クラウド アカウントに対する緊急度の高い脅威（今まさに侵入されている可能性がある、など）が発生した場合、⑥の検出結果のレポート配信のタイミングに関わらず、なるべく早い段階でプロジェクト担当者に通知されるべきです。Security Hub の連携を行うと、メンバーアカウントの GuardDuty アラートも SOC アカウントにニアリアルタイムで連携されるため、 EventBridge と Lambda 関数によるイベントドリブンで緊急度の高い GuardDuty アラートを SOC 担当のチャットに通知します。 SOC 担当はアラートの内容を確認し、プロジェクト担当者に連絡を取ります。 ⑧アカウント連携解除ツール（ PowerShell スクリプト ） プロジェクトアカウントを SOC サービスから解除する場合は、 SOC アカウントの CloudShell で実行することで連携を解除できる PowerShell スクリプト を利用します。プロジェクトアカウント側の設定（Security Hub の無効化）などはプロジェクト側の作業に委ねています。 ⑨セキュリティコン トロール の対応方針、 セキュリティ設定ガイド（ Excel , PowerPoint ） Security Hub のアラートに対する理解は、プロジェクトによってまちまちです。プロジェクト側のアラートへの対応をサポートするため、 SOC 担当で Security Hub のコン トロール を調査し、対応方針やノウハウの資料をプロジェクト向けに公開しています。 まとめ ISID 社内で Security Hub の利用をサポートするためのツール群（資料、 スクリプト 含む）をざっとご紹介しました。 ただし今の形がベストだと思っているわけではなく、運用に必要なツールやその仕組みは、今後の SOC の成長に応じて変わってくるだろうなと思っています。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア(セキュリティ設計) 執筆： @kou.kinyo 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）