こんにちは。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 で執筆されました ）

ISID X（クロス） イノベーション 本部 の三浦です。 筆者の関わっている案件では、コンテナ利用、 AWS Fargate利用を進めております。 今日は、 AWS Fargateのコストを下げるための取り組み例についてご紹介します。 目次 目次 AWS Fargate Spotとは？ terraformのコードでAWS Fargate Spot対応 稼働率の例 まとめ AWS Fargate Spotとは？ Fargate Spotは、EC2スポット インスタンス と同じように、 AWS 内で未使用の クラウド リソースを活用することでオンデマンド料金と比べて最大70%の割引価格で一時的に利用できる インスタンス です。 Fargate Spotが空きキャパシティを確保できるかぎり、ユーザーは指定したタスクを起動できます。 AWS にキャパシティが必要になったとき、Fargate Spotで稼働するタスクは2分前の通知とともに中断されます。 そのため、本番で使おうとすると様々な検討が必要ですが、中断しても問題にならないような小規模の開発環境、技術検証環境ならデメリットを最小化して使うことができます。 AWS Fargate の料金 Amazon ECS 向け Fargate Spot の料金 AWS Fargate の料金 より terraformのコードで AWS Fargate Spot対応 terraformでecs serviceを定義している場合、resource " aws _ecs_service"に下記の赤枠のコードを追加するだけで、Fargate Spot対応が完了します。本案件では、複数コンテナを使用しておらず1コンテナを立ち上げる仕様です。 中断が問題にならないフェイズ（インフラ担当者が構築中、極一部の開発者のみが使用する段階）ではFargate Spotで起動し、本稼働のフェイズではFargateに切り替えるといったことをしています。 なお、Fargate Spotの仕様としては、weightにて通常のFargateとFargate Spotの比率をコン トロール できます。例えば、7割をfargateにし3割をspotにするとspotが落ちるような状況下でも影響を限定できます。 また1コンテナしか存在しないような場合でも、weightを1:0 ⇒0:1のように切り替えることにより、非常に小さな修正でFargate SpotとFargate を切り替えられます。 （青枠の部分は キャパシティー プロバイダーの設定とコンフリクトするため、削除が必要です） 稼働率 の例 このようにコストの削減に効果的で、かつ、対応も簡単なFargate Spotですが、あまり頻繁に立ち上がらないとつらいものがあります。 ということで、Fargate Spotが実際に、どのくらいの頻度で稼働し続けるのか、再起動はどれくらい発生するかという実例をご紹介いたします。 下記は日本リージョンで小さいコンテナを20コンテナ、1週間起動したときのコストです。 コスト エクスプローラ ーでみると、ほぼ全ての時間で安定して起動しており、特定の曜日、時間帯に大規模に中断しつづけるということはありませんでした（ アベイラビリティ ーゾーン IDはapne1-az4を使用しました）。 一方、ある程度の頻度でタスクの終了は発生しており、ログを確認したところ、20コンテナで48hで42回再起動していました。1コンテナ当たり、1日一回程度の頻度になります。なお、再起動は特定の時間帯に明らかに偏っているということはありませんでした。 ということで、ある程度の再起動とは引き換えになりますが、大幅なコスト削減が可能となります。 まとめ ということで、本格的なSpotの利用となると採用が難しいところもあるとは思いますが、まず、構築時、技術検証時、プライベート環境等からFargate Spotを使ってみるというのはいかがでしょうか？ 使ってみると、意外と中断は気にならずいいかんじでコストが抑制できるかもしれません。 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @miura.toshihiko 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

ISID X（クロス） イノベーション 本部 の三浦です。 筆者の関わっている案件では、コンテナ利用、 AWS Fargate利用を進めております。 今日は、 AWS Fargateのコストを下げるための取り組み例についてご紹介します。 目次 目次 AWS Fargate Spotとは？ terraformのコードでAWS Fargate Spot対応 稼働率の例 まとめ AWS Fargate Spotとは？ Fargate Spotは、EC2スポット インスタンス と同じように、 AWS 内で未使用の クラウド リソースを活用することでオンデマンド料金と比べて最大70%の割引価格で一時的に利用できる インスタンス です。 Fargate Spotが空きキャパシティを確保できるかぎり、ユーザーは指定したタスクを起動できます。 AWS にキャパシティが必要になったとき、Fargate Spotで稼働するタスクは2分前の通知とともに中断されます。 そのため、本番で使おうとすると様々な検討が必要ですが、中断しても問題にならないような小規模の開発環境、技術検証環境ならデメリットを最小化して使うことができます。 AWS Fargate の料金 Amazon ECS 向け Fargate Spot の料金 AWS Fargate の料金 より terraformのコードで AWS Fargate Spot対応 terraformでecs serviceを定義している場合、resource " aws _ecs_service"に下記の赤枠のコードを追加するだけで、Fargate Spot対応が完了します。本案件では、複数コンテナを使用しておらず1コンテナを立ち上げる仕様です。 中断が問題にならないフェイズ（インフラ担当者が構築中、極一部の開発者のみが使用する段階）ではFargate Spotで起動し、本稼働のフェイズではFargateに切り替えるといったことをしています。 なお、Fargate Spotの仕様としては、weightにて通常のFargateとFargate Spotの比率をコン トロール できます。例えば、7割をfargateにし3割をspotにするとspotが落ちるような状況下でも影響を限定できます。 また1コンテナしか存在しないような場合でも、weightを1:0 ⇒0:1のように切り替えることにより、非常に小さな修正でFargate SpotとFargate を切り替えられます。 （青枠の部分は キャパシティー プロバイダーの設定とコンフリクトするため、削除が必要です） 稼働率 の例 このようにコストの削減に効果的で、かつ、対応も簡単なFargate Spotですが、あまり頻繁に立ち上がらないとつらいものがあります。 ということで、Fargate Spotが実際に、どのくらいの頻度で稼働し続けるのか、再起動はどれくらい発生するかという実例をご紹介いたします。 下記は日本リージョンで小さいコンテナを20コンテナ、1週間起動したときのコストです。 コスト エクスプローラ ーでみると、ほぼ全ての時間で安定して起動しており、特定の曜日、時間帯に大規模に中断しつづけるということはありませんでした（ アベイラビリティ ーゾーン IDはapne1-az4を使用しました）。 一方、ある程度の頻度でタスクの終了は発生しており、ログを確認したところ、20コンテナで48hで42回再起動していました。1コンテナ当たり、1日一回程度の頻度になります。なお、再起動は特定の時間帯に明らかに偏っているということはありませんでした。 ということで、ある程度の再起動とは引き換えになりますが、大幅なコスト削減が可能となります。 まとめ ということで、本格的なSpotの利用となると採用が難しいところもあるとは思いますが、まず、構築時、技術検証時、プライベート環境等からFargate Spotを使ってみるというのはいかがでしょうか？ 使ってみると、意外と中断は気にならずいいかんじでコストが抑制できるかもしれません。 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @miura.toshihiko 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 入社したのが2021年の10月なのでそろそろ1年と半年くらいが経過しました。 今日は入社までの経緯や、仕事の雰囲気などについてお話出来ればと思います。 会社の雰囲気 自分が受けている印象では、ISIDは会社の雰囲気として意思決定が素早く意見が通りやすいという印象があります。 結果、会議の時間がとても短く大変驚いています。 コロナ禍での入社だったので、基本的にリモートでしか業務に参加していないのですが、皆さん意見をちゃんと言ってくれます。また自分が提案した意見についても真剣に議論して貰えます。 やっている業務内容 担当している業務ですが、社内の開発に関する改善活動全般という感じです。 例えば、CI/CDの普及活動であったり、 GitHub のCodespacesなどについての検証活動といったことをやっています。 成果の一部はテックブログとして公開したりしていますね。 また、新しい技術が出てきたらそれをキャッチアップするために試してみるといったこともやっています。 入社の経緯 前職では、家電メーカーの研究部門でソフトウェア開発の生産性に関する研究、社内施策の実施などの業務に携わっていました。例えば、ソフトウェア リポジトリ のマイニング、CI/CD環境の整備などです。 前職の業務もやりがいがあるものでした。しかし、会社規模が大きい会社ということもあり段々とマネジメントに関する業務が増え、スキルなどもマネジメント系の能力を伸ばしていくことが期待されるようになってきました。 もう少し技術に触れている時間を増やせる会社を探していたところISIDを知人に紹介されて、自分も良さそうと思って転職を決めました。 入社前に不安だったこと、実際 入社前に不安に感じていたものは以下のような物でした。 技術力の不足 業務知識や業界の常識の不足 プライベートの時間の確保 それぞれについて不安と実際どうだったかについて見ていきます。 技術力の不足 前職では研究職で、ISIDに入社すると技術職になります。これは似ている面はありますが違うものであると自分は思っています。例えば、製品開発を最初から最後まで全部やり切るといった経験は研究職だとなかなか経験できません。 なので、実際の開発で役に立つような知識を自分が持っているか不安でした。 特に入社前から技術をリードしていく立場として、メンバに技術を教える立場であることを期待されていました。上手くやれるのか不安を持っていました。結論から言うと、これは杞憂だったようです。 技術的な側面については、教える場面では高度な技術の知識が必要というよりは基本的な知識があれば十分でした。例えば計算機に関する基本的な知識、 Linux の操作に関する一通りの知識などです。なので今のところ自分の技術の能力が不足していて困ったという場面には遭遇していません。 また、ISIDでは知らない技術がある場合にはその知識を獲得するための期間や勉強する場が準備される体制になっています。知識不足で業務に支障が出るということは発生しなさそうです。 業務知識や業界の常識の不足 前職でSIのような仕事と全く無関係ということはなかったのですが、いざ当事者となると業界の ドメイン 知識が十分であるかというとかなり疑問でした。入社して1年経ちますが、過去の経験が生きている場面もありますが、やはり分からない話もあります。その場合、社内で質問すれば教えてもらえるので大変助かっています。皆さまありがとうございます。 逆に前職の経験に引っ張られてしまう場面も多く、まだまだ勉強することは多いなと感じています。 プライベートの時間の確保 前職では業務時間がやや長くなる傾向にありました。プライベートの時間に影響が出るほどではなかったのですが、ISIDに入社してからはプライベートの時間が大幅に取れるようになりました。前職と比較して会議の時間が減り、効率的な働き方が可能になったからと自分では分析しています。 また、前職では8時間と設定されていた標準の労働時間がISIDでは7時間となっており、純粋に1時間ほどプライベートの時間を確保しやすくなりました。 前職と働き方で変わった事 業務上の目標は前職で一番変化した点は意思決定が早くなり、作業時間の確保が比較的容易になったので 技術的な調査、検証といった時間を確保できるようになったのが一番の変化だと考えています。 前職では会社の規模が大きかったため、利害関係者が多くなる傾向にありました。 結果として資料作成や会議が多くなり実際の技術に使える時間は限られていました。 ISIDに入社してからは、利害関係者も少なく意思決定が早いことから調整の為の会議やそれに向けた資料の作成 といった時間が減り、技術的な調査、検証の時間が増えています。 一方で、意思決定や利害関係者が少なく、自分の判断が会社に影響を与える比率が大きくなりました、そのため責任を感じる場面も増えたなという印象があります。気を引き締めて仕事に臨まないといけない場面は増えたかもしれません。 これは、自分としてはやりたいことをやるまでの手数が減ったので良かったかなと考えています。意思決定の早さについては1年半経った今でも驚かされる事が多いので、まだまだ慣れが必要だなと考えています。 最後に 今回は、ISIDに入社して1年半経った自分の入社前の不安や働き方の変化について簡単にですが振り返ってみました。 もし、ISIDにご興味がある方は是非応募してみてください。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @handa.kenta （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 入社したのが2021年の10月なのでそろそろ1年と半年くらいが経過しました。 今日は入社までの経緯や、仕事の雰囲気などについてお話出来ればと思います。 会社の雰囲気 自分が受けている印象では、ISIDは会社の雰囲気として意思決定が素早く意見が通りやすいという印象があります。 結果、会議の時間がとても短く大変驚いています。 コロナ禍での入社だったので、基本的にリモートでしか業務に参加していないのですが、皆さん意見をちゃんと言ってくれます。また自分が提案した意見についても真剣に議論して貰えます。 やっている業務内容 担当している業務ですが、社内の開発に関する改善活動全般という感じです。 例えば、CI/CDの普及活動であったり、 GitHub のCodespacesなどについての検証活動といったことをやっています。 成果の一部はテックブログとして公開したりしていますね。 また、新しい技術が出てきたらそれをキャッチアップするために試してみるといったこともやっています。 入社の経緯 前職では、家電メーカーの研究部門でソフトウェア開発の生産性に関する研究、社内施策の実施などの業務に携わっていました。例えば、ソフトウェア リポジトリ のマイニング、CI/CD環境の整備などです。 前職の業務もやりがいがあるものでした。しかし、会社規模が大きい会社ということもあり段々とマネジメントに関する業務が増え、スキルなどもマネジメント系の能力を伸ばしていくことが期待されるようになってきました。 もう少し技術に触れている時間を増やせる会社を探していたところISIDを知人に紹介されて、自分も良さそうと思って転職を決めました。 入社前に不安だったこと、実際 入社前に不安に感じていたものは以下のような物でした。 技術力の不足 業務知識や業界の常識の不足 プライベートの時間の確保 それぞれについて不安と実際どうだったかについて見ていきます。 技術力の不足 前職では研究職で、ISIDに入社すると技術職になります。これは似ている面はありますが違うものであると自分は思っています。例えば、製品開発を最初から最後まで全部やり切るといった経験は研究職だとなかなか経験できません。 なので、実際の開発で役に立つような知識を自分が持っているか不安でした。 特に入社前から技術をリードしていく立場として、メンバに技術を教える立場であることを期待されていました。上手くやれるのか不安を持っていました。結論から言うと、これは杞憂だったようです。 技術的な側面については、教える場面では高度な技術の知識が必要というよりは基本的な知識があれば十分でした。例えば計算機に関する基本的な知識、 Linux の操作に関する一通りの知識などです。なので今のところ自分の技術の能力が不足していて困ったという場面には遭遇していません。 また、ISIDでは知らない技術がある場合にはその知識を獲得するための期間や勉強する場が準備される体制になっています。知識不足で業務に支障が出るということは発生しなさそうです。 業務知識や業界の常識の不足 前職でSIのような仕事と全く無関係ということはなかったのですが、いざ当事者となると業界の ドメイン 知識が十分であるかというとかなり疑問でした。入社して1年経ちますが、過去の経験が生きている場面もありますが、やはり分からない話もあります。その場合、社内で質問すれば教えてもらえるので大変助かっています。皆さまありがとうございます。 逆に前職の経験に引っ張られてしまう場面も多く、まだまだ勉強することは多いなと感じています。 プライベートの時間の確保 前職では業務時間がやや長くなる傾向にありました。プライベートの時間に影響が出るほどではなかったのですが、ISIDに入社してからはプライベートの時間が大幅に取れるようになりました。前職と比較して会議の時間が減り、効率的な働き方が可能になったからと自分では分析しています。 また、前職では8時間と設定されていた標準の労働時間がISIDでは7時間となっており、純粋に1時間ほどプライベートの時間を確保しやすくなりました。 前職と働き方で変わった事 業務上の目標は前職で一番変化した点は意思決定が早くなり、作業時間の確保が比較的容易になったので 技術的な調査、検証といった時間を確保できるようになったのが一番の変化だと考えています。 前職では会社の規模が大きかったため、利害関係者が多くなる傾向にありました。 結果として資料作成や会議が多くなり実際の技術に使える時間は限られていました。 ISIDに入社してからは、利害関係者も少なく意思決定が早いことから調整の為の会議やそれに向けた資料の作成 といった時間が減り、技術的な調査、検証の時間が増えています。 一方で、意思決定や利害関係者が少なく、自分の判断が会社に影響を与える比率が大きくなりました、そのため責任を感じる場面も増えたなという印象があります。気を引き締めて仕事に臨まないといけない場面は増えたかもしれません。 これは、自分としてはやりたいことをやるまでの手数が減ったので良かったかなと考えています。意思決定の早さについては1年半経った今でも驚かされる事が多いので、まだまだ慣れが必要だなと考えています。 最後に 今回は、ISIDに入社して1年半経った自分の入社前の不安や働き方の変化について簡単にですが振り返ってみました。 もし、ISIDにご興味がある方は是非応募してみてください。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @handa.kenta （ Shodo で執筆されました ）

はじめに ISID X（クロス） イノベーション 本部 の三浦です。 権限の問題でシステム部門での作業が必要だったのですが、ようやくシステム部門での作業が完了し、弊社でも AWS Chatbotが Microsoft Teamsでも使えるようになりました。 ということで今さら感もありますが、システム部門の作業前の状態、作業後の一般ユーザーによる設定例、利用方法について記述しようと思います。 目次 はじめに 目次 AWS Chatbot の概要 システム部門の作業前の状態 作業後の一般ユーザーによる設定例 利用例 エイリアスの利用 まとめ AWS Chatbot の概要 簡易な作業でTeams等から AWS の操作を可能にする機能です。同様のことは、 AWS Lambda、webhookを利用すれば実装可能でしたが、 AWS Chatbotによって非常に簡易にできるようになりました。 筆者の場合、開発環境、デモ環境の立ち上げを簡易にやりたいというニーズがありました。 エンジニアが対象の場合は、自身で AWS コンソールから立ち上げるようにする、 スクリプト で起動するといった手も取れます。しかし、非エンジニアが多い場合、依頼を受けて運用エンジニアが起動する、停止するという運用をしている例がありました。 これらの問題を AWS Chatbotを使用して対応する例を示します。 システム部門の作業前の状態 下記の要領で、『Teamsクライアント ＞ アプリ　＞ AWS で検索 ＞ チームに追加』でアプリの登録を試みます。 しかしながら、テナントの設定状況の問題でアプリが使えない状態でした。 上記の旨をシステム部門に申請し、アプリの承認および AWS からのアクセス権付与を対応していただきました。 本作業は、多くのテナントでは一般ユーザーに権限解放されていないと思いますので、システム部門に実施していただく必要があります。 作業後の一般ユーザーによる設定例 上記の対応が済んでいる場合、下記画面より先に進めます。 連携するチャネルを選択します。 しかし、privateチャネルは表示されない、5個以上のチャネルは表示されない（team名+チャネル名で絞り込めます）などのやや癖のある動きをするようです。 連携が終わると、上記のようにメッセージが投稿されます。 続いて、 AWS アカウント側で AWS Chatbot の設定を行っていきます。 まず、チャネル情報を AWS Chatbot で設定する必要があります。ですので、 Microsoft Teams のチャネル一覧から対象チャネルを右クリックし「チャネルへのリンクを取得」メニューから URL を取得します。 続いて、 AWS コンソールにログインし、 AWS Chatbot コンソールを開きます。 チャットクライアント設定画面で Microsoft Teams が選択できるようになっているので、選択します。 先ほど取得した対象チャネルの URL を設定します。 組織として認証済みのため、特に認証画面が出ることなく完了します。 続いて、チャネル登録をします。 チャネル名の表記がURL エンコード で表示されていて見た目が悪いですが、問題なく動作します。 次にこのチャットボットで何ができるか権限を指定します。 下記のように、いくつかロールのテンプレートがあるのですが、それらでは限られた権限しかありません。 そのため、下記の設定より新規にロールを作成します。 『信頼されたエンティティ』に AWS Chatbotを選び 今回はec2の起動、停止をしたいため、一旦雑にEc2FullAccessを指定します。実際に利用されるときは、そのチャネルの利用者のロールに応じて権限を設定するのがよいでしょう。 このようにして作成したIAMロールには、chatbotに対する信頼関係が設定されています。 本ロールを元の画面で設定し、チャネルガードレールポリシーにも同等の権限であるEc2FullAccessを指定します。 これで、chatbotの設定が完了しました。 利用例 それでは、chatbotを利用してみましょう。 chatbotの構文は、ほぼ、 aws cli と同じです。 ということで、 インスタンス の起動を試みます。 初回利用のため、リージョンを設定しろと言われてしまいました。 ということでchatbot上でリージョンを設定します。 再度コマンドを実行すると、本当にこのコマンドを流していいかと聞かれるため実行します。 コマンドが実行されました。 AWS コンロールで確認したところ、 インスタンス が起動していることを確認できました。 同様の手順で インスタンス の停止も可能です。 エイリアス の利用 が、 AWS CLI に相当するものをTeam上で叩けというのは敷居が高いため、 エイリアス を設定します。 下記のような要領で エイリアス の作成が可能です。 開始、停止用の エイリアス を作成したので、さっそく試します。 エイリアス を使用して環境1を立ち上げろと命じたところ、実際に実行するコマンドが展開されて表示されました。 便利ですね。 で、実行すると、下記のようにコマンドが実行されます。 なお、日本語での エイリアス は設定できませんでした。 まとめ このようにして、簡易にTeamsから AWS の インスタンス の開始、停止ができるようになりました。非エンジニアにとって非常に良い機能なのではないかと思っています。 執筆： @miura.toshihiko 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

はじめに ISID X（クロス） イノベーション 本部 の三浦です。 権限の問題でシステム部門での作業が必要だったのですが、ようやくシステム部門での作業が完了し、弊社でも AWS Chatbotが Microsoft Teamsでも使えるようになりました。 ということで今さら感もありますが、システム部門の作業前の状態、作業後の一般ユーザーによる設定例、利用方法について記述しようと思います。 目次 はじめに 目次 AWS Chatbot の概要 システム部門の作業前の状態 作業後の一般ユーザーによる設定例 利用例 エイリアスの利用 まとめ AWS Chatbot の概要 簡易な作業でTeams等から AWS の操作を可能にする機能です。同様のことは、 AWS Lambda、webhookを利用すれば実装可能でしたが、 AWS Chatbotによって非常に簡易にできるようになりました。 筆者の場合、開発環境、デモ環境の立ち上げを簡易にやりたいというニーズがありました。 エンジニアが対象の場合は、自身で AWS コンソールから立ち上げるようにする、 スクリプト で起動するといった手も取れます。しかし、非エンジニアが多い場合、依頼を受けて運用エンジニアが起動する、停止するという運用をしている例がありました。 これらの問題を AWS Chatbotを使用して対応する例を示します。 システム部門の作業前の状態 下記の要領で、『Teamsクライアント ＞ アプリ　＞ AWS で検索 ＞ チームに追加』でアプリの登録を試みます。 しかしながら、テナントの設定状況の問題でアプリが使えない状態でした。 上記の旨をシステム部門に申請し、アプリの承認および AWS からのアクセス権付与を対応していただきました。 本作業は、多くのテナントでは一般ユーザーに権限解放されていないと思いますので、システム部門に実施していただく必要があります。 作業後の一般ユーザーによる設定例 上記の対応が済んでいる場合、下記画面より先に進めます。 連携するチャネルを選択します。 しかし、privateチャネルは表示されない、5個以上のチャネルは表示されない（team名+チャネル名で絞り込めます）などのやや癖のある動きをするようです。 連携が終わると、上記のようにメッセージが投稿されます。 続いて、 AWS アカウント側で AWS Chatbot の設定を行っていきます。 まず、チャネル情報を AWS Chatbot で設定する必要があります。ですので、 Microsoft Teams のチャネル一覧から対象チャネルを右クリックし「チャネルへのリンクを取得」メニューから URL を取得します。 続いて、 AWS コンソールにログインし、 AWS Chatbot コンソールを開きます。 チャットクライアント設定画面で Microsoft Teams が選択できるようになっているので、選択します。 先ほど取得した対象チャネルの URL を設定します。 組織として認証済みのため、特に認証画面が出ることなく完了します。 続いて、チャネル登録をします。 チャネル名の表記がURL エンコード で表示されていて見た目が悪いですが、問題なく動作します。 次にこのチャットボットで何ができるか権限を指定します。 下記のように、いくつかロールのテンプレートがあるのですが、それらでは限られた権限しかありません。 そのため、下記の設定より新規にロールを作成します。 『信頼されたエンティティ』に AWS Chatbotを選び 今回はec2の起動、停止をしたいため、一旦雑にEc2FullAccessを指定します。実際に利用されるときは、そのチャネルの利用者のロールに応じて権限を設定するのがよいでしょう。 このようにして作成したIAMロールには、chatbotに対する信頼関係が設定されています。 本ロールを元の画面で設定し、チャネルガードレールポリシーにも同等の権限であるEc2FullAccessを指定します。 これで、chatbotの設定が完了しました。 利用例 それでは、chatbotを利用してみましょう。 chatbotの構文は、ほぼ、 aws cli と同じです。 ということで、 インスタンス の起動を試みます。 初回利用のため、リージョンを設定しろと言われてしまいました。 ということでchatbot上でリージョンを設定します。 再度コマンドを実行すると、本当にこのコマンドを流していいかと聞かれるため実行します。 コマンドが実行されました。 AWS コンロールで確認したところ、 インスタンス が起動していることを確認できました。 同様の手順で インスタンス の停止も可能です。 エイリアス の利用 が、 AWS CLI に相当するものをTeam上で叩けというのは敷居が高いため、 エイリアス を設定します。 下記のような要領で エイリアス の作成が可能です。 開始、停止用の エイリアス を作成したので、さっそく試します。 エイリアス を使用して環境1を立ち上げろと命じたところ、実際に実行するコマンドが展開されて表示されました。 便利ですね。 で、実行すると、下記のようにコマンドが実行されます。 なお、日本語での エイリアス は設定できませんでした。 まとめ このようにして、簡易にTeamsから AWS の インスタンス の開始、停止ができるようになりました。非エンジニアにとって非常に良い機能なのではないかと思っています。 執筆： @miura.toshihiko 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回はUE5で コリジョン （衝突）判定機能を使って、自動で開閉するドアや、 NPC との簡単な会話システムを作成してみます。 はじめに UE5ではフィールド上のさまざまなオブジェクトや、プレイヤーが操作するキャ ラク ターに コリジョン 判定機能を持たせることができます。 これにより、物体にキャ ラク ターが当たった時や、前もって設定しておいた領域に他のオブジェクトが侵入した時などに、 任意の機能を作成できます。 今回はこの コリジョン 判定機能を利用して下記2つの機能を実装します。 キャ ラク ターが近づくと開き、遠ざかると閉じる自動ドアの機能 対象キャ ラク ター（ NPC ）にプレイヤーが近づき、任意のキーボードを押すと会話が行われる機能 検証環境/ツール Unreal Engine5.2.0 AWS EC2 Windows _Server-2022-English-Full-Base-2023.01.19 実装手順 【自動ドア編】タイムラインを利用したドアのアニメーションの作成 【自動ドア編】 コリジョン を利用した自動開閉システムの作成 【 NPC 会話編】会話UI用の ウィジェット の作成 【 NPC 会話編】 コリジョン を利用した会話UI用の ウィジェット の表示 【 NPC 会話編】 NPC 毎のメッセージ内容切り替え 1. 【自動ドア編】タイムラインを利用したドアのアニメーションの作成 今回はThirdPersonテンプレートを利用したプロジェクトで進めていきます。 まず初めにドアに使用するアクターのBluePrintを作成します。 コンテンツドロワーより、BlueprintClassを選び、Actorを選択します。今回は「BP_Door」という名前にします。 「BP_Door」の編集画面に入ります。 コンポーネント 追加ボタンより、「Static Mesh」を追加し、「Door」と 命名 します。 右側の詳細パネルより、Static Meshのセレクトボックスでスターターコンテンツの「SM_Door」を選びます。 次にドアの当たり判定用に コンポーネント 追加ボタンより、「Box Collision」を追加し、ドアの大きさに合わせて変更します。 またキャ ラク ターがドアをすり抜けてしまわないよう、今作った「Box Collision」のあたり判定を設定する コリジョン プリセットの値を「BlockAllDynamic」に変更します。 続いて、作成したドアにアニメーションをつけていきます。 本ステップでは、ドアにアニメーションをつけることが目的なので、わかりやすくするため、 ゲーム開始時に、ドアが開く仕組みを作成します。 「BP_Door」のイベントグラフを開きます。 「イベント BeginPlay」の後に、ドアに動きをつけるためにタイムラインを使用します。 以前のこちらの記事（UE5 x ZBrushでタイムラインを活用したアニメーションを作成する） で、タイムラインについて詳しく説明しているので、今回は割愛します。 「DoorOpenRate」という名前でタイムラインを作成し、さらに「Rate」というトラックを作成し、下記値を追加しました。 秒数0:値0 秒数0.5:値1 イベントグラフに戻ると、返却値として「Rate」を持つタイムラインができているので、「イベント BeginPlay」のピンとつなぎます。 次に「Make Rotator」ノードを作成しZ軸の値を「90」に設定します。これはドアが90度開くための値になります。 「乗算」ノードを追加し、下の写真のように作成したタイムラインとつなぎます。 最後に「Set Relative Rotation(Door)」を選択し、「New Rotation」にタイムラインから乗算した値をつなぎます。 コンパイル し、Map上に「BP_Door」を配置を行い、ゲームを開始することでドアが開くアニメーションを確認できます。 2. 【自動ドア編】 コリジョン を利用した自動開閉システムの作成 ここでは、 コリジョン を利用して、キャ ラク ターが近づくと自動で開き、離れると自動で閉じるドアにします。 ちなみに先ほどドアに「Box Collision」を使いましたが、これはキャ ラク ターがドアを通り抜けられなくするための コリジョン のため、 これから作る自動ドアの範囲を示す コリジョン とは別のものになります。 「BP_Door」を開き、「 Sphere Collision」を追加します。 次に、「 Sphere Collision」をドアの中心へ移動し拡大を行い、キャ ラク ターが入ると自動でドアが開く領域を設定します。 詳細パネルのイベント欄から「On Component Begin Overlap」と「On Component End Overlap」の右のプラスボタンを押します。 イベントグラフに下のようなノードができていることを確認します。 作成された「On Component Begin Overlap」を「イベント BeginPlay」と入れ替えることで、キャ ラク ターが コリジョン で設定した領域に入ることでドアが開く挙動になります。 また、「On Component End Overlap」をタイムラインの「Reverse」ピンに接続することで、タイムラインで設定した値と逆の挙動が行われるので、キャ ラク ターが領域からでた際にドアが閉まります。 以上がキャ ラク ターが近づくと開き、遠ざかると閉じる自動のドアの機能の紹介になります。 3. 【 NPC 会話編】会話UI用の ウィジェット の作成 続いて、対象キャ ラク ター（ NPC ）にプレイヤーが近づき、任意のキーボードを押すと会話が行われる機能の作成手順を紹介します。 まずは会話UIに使用する ウィジェット を作成するために、「 Widget Blueprint」を「WBP_ Talk 」という名前で作成します。 ウィジェット の作成方法は 以前のこちらの記事（UE5 PixelStreamingで、マウスカーソルを別の画像に変更してクリックイベントを作成する） で紹介しております。 まずはパレット内の一般から「Border」を「WBP_ Talk 」内に ドラッグ&ドロップ し、「 Canvas Panel」でラップします。 詳細パネルからアンカーを選び、下に伸びているものを選びます。 「Brush」内の「Tint」の部分にカラーピッカーがあるので「A（アルファ）」の値を「0.5」まで下げて、先ほど作成した「Border」を半透明にします。サイズを下の写真のように大きくして簡易的な会話テキストを置く部分のUIとします。 次にパレット内から「Text」を選び、今作成した「Border」内に ドラッグ&ドロップ します。 詳細タブの「Padding」から上下左右中央そろえにします。また、「Font」から文字サイズも「36」に変更します。 これで会話UI用の ウィジェット が出来ました。 実際に画面に表示させてみます。 スターターコンテンツで初期から入っているキャ ラク ターを使用します。 ファイルは、コンテンツ＞ThirdPerson＞Blueprints＞BP_ThirdPersonCharacter にあります。 まずはこのBlueprintから ウィジェット にアクセスできるように設定します。 「 ウィジェット を作成」ノードを追加し、Class属性にWBP_ Talk を設定します。また「Owning Player」には「Get Player Controller」をつなぎます。 次に ウィジェット を作成ノードを「イベント BeginPlay」のピンとつなげます。 「WBP_ Talk ウィジェット を作成」のノードの「Return Value 」を変数としてセットし、「UI_ Talk 」と 命名 します。 次に 「Q」 を押した時に ウィジェット を画面に表示させるようにします。 「Add to Viewport(UI_ Talk )」を選び、 「Q」 のノードとつなぎます。 これで実際に画面に会話用のUIを表示することが出来ました。 ここまでで、会話用のUIに必要な ウィジェット の準備が整いました。 続いて コリジョン を利用して、プレイヤーが操作しているキャ ラク ターの前に、他のキャ ラク ターがいる時のみ 「Q」 を押すことで、会話用のUIを出す機能を作成します。 4. 【 NPC 会話編】 コリジョン を利用した会話UI用の ウィジェット の表示 まずは「BP_ThirdPersonCharacter」のキャ ラク ターに、先ほどドアを作成した時と同じように「 Sphere Collision」を作成します。 キャ ラク ターの前方に下の写真のように「 Sphere Collision」を配置します。 イベントグラフに戻り、「Get Overlapping Actors( Sphere )」を作成します。これは先ほど作成した「 Sphere Collision」に 接触 しているアクターの一覧を配列で返してくれるノードになります。 先ほど作成した 「Q」 を押した後の「ブランチ（IF文）」でfalseだった時に「For Each Loop With Break」ノードで「 Sphere Collision」に 接触 しているアクターの配列を展開します。 本ステップではまだアクターごとに会話の文章の内容を分けず、 コリジョン 内にアクターがある場合のみ会話用のUIを出すだけの処理なので下の写真のように「Add to Viewport」につなぎ、配列がなくなるまでループさせます。 これで、 コリジョン 内にアクターが1つでもあれば、 「Q」 を押すことで会話用のUIを表示できます。 また、このままだと会話用UIが出たままになってしまうので、消去する処理も作成します。 「IsTalk」というBooleanの変数を作成し、会話中ではない時のみ画面に会話用UIが出るように設定します。 また会話中の場合は、画面から会話用UIを消すために「Remove From Parent」ノードを追加し、画面から会話用UIを消去し、「IsTalk」のフラグをfalseに変更します。 実際に試してみるために、マップにいくつかアクターを設置させます。 どんなアクターでも良いですが、今回は NPC 風の人型アクターを作成して設置します。 Blueprint作成画面からCharacterを選択して「BP_ NPC 」を作成します。 コンポーネント 一覧よりより、「Mesh」を選択し、詳細パネルよりメッシュを選びます。今回は「SK_Mannequin」を選択します。 マテリアルも任意のものを選び、マップに配置します。 ここまでの実装で、プレイヤーが操作するキャ ラク ターの前にアクターがある時のみ、 「Q」 を押すことで、会話用のUIが出てくる処理が完成しました。 続いて、マップに配置した NPC ごとに会話の内容を変更させる機能を作成し説明します。 5. 【 NPC 会話編】 NPC 毎のメッセージ内容切り替え まずはアクター間を超えて共通の会話用の関数を使用できるようにブループリントインターフェースを作成します。 コンテンツドロワーからブループリントインターフェースを作成し、「BPI_ Talk 」と 命名 します。 編集画面で「CanTalk」というBooleanを返す関数と、「GetTalkMessage」というTextを返す関数を作成します。 「BP_ NPC 」で2つの関数を使用するために、「BP_ NPC 」を開き画面上部のクラス設定を押し、右側の実装インターフェースのセレクトボックスより「BPI_ Talk 」を選択します。 左側にインターフェース欄が追加され、先ほど作成した2つの関数があることを確認します。 左側のインターフェース欄から「CanTalk」をダブルクリックで開き、Booleanの返り値をtrueに設定します。 同様に「GetTalkMessage」を開き、リターンノードのTextの返り値を変数としてセットし、「TalkMessage」と 命名 します。 さらに、変数欄の右側の目のアイコンをクリックして、UEの全体の編集画面から直接変数の値を変更できるように設定しておきます。 最後のステップとして「BP_ThirdPersonCharacter」を開き、前にいるアクター（BP_ NPC ）が「CanTalk」でtrueを返しているかをチェックし、trueだった場合に「TalkMessage」でセットした文字列を会話用UIに埋め込んで表示させる処理を作成します。 先ほど配列で取得した コリジョン 内のアクターをForEachで回している部分で、「CanTalk」がtrueかどうか確認するためにノードを追加します。 trueだった場合に、さらにそのアクターが設定してある会話の内容を「GetTalkMessage」から取得します。 （BP_ NPC は全て「CanTalk」をtrueで返す設定をしています。） 「GetTalkMessage」のターゲットはアクターの配列が入っている「Array Element」です。 次に取得してきた会話の内容を「WBP_ Talk 」の中に埋め込みます。 「WBP_ Talk 」を開き、階層から「Text」を選択します。次に右上の「is Variable」にチェックを入れ、「 Widget _TalkMessage」と 命名 します。 「WBP_ Talk 」をグラフ表示に変更して、関数を作成します。今回は「 Widget _SetTextMessage」と 命名 します。 インプットにTextを設定します。 「SetText(Text)」ノードをつなぎ、ターゲットに「 Widget _TalkMessage」を設定し、ターゲットに「UI_ Talk 」をつなぎます。 「BP_ThirdPersonCharacter」に戻り、「 Widget _SetTextMessage」ノードを作成し、「GetTalkMessage」とつなぎます。 最後に「Add to Viewport」と繋ぐことでBlueprint側での処理は完了です。 全体の処理は下記のような流れになっています。 UEの編集画面からアクターを選択し、詳細タブの「 Talk Massage」欄に任意の文言を追加することで、アクターごとに会話する内容を設定できます。 実際に会話を行ってみます。 以上が コリジョン 機能を使って、自動で開閉するドアや、 NPC との簡単な会話システムの作成方法の紹介です。 所感 コリジョン を利用することで、オブジェクトを動かしたり、重なったアクターの情報を取得したりと、さまざまな使い方ができることがわかりました。 また、基本的な会話の作り方もわかったので、より複雑な会話方法や、 ウィジェット の作成方法なども学習していきます。 特に ウィジェット でできることはまだまだありそうなので、もう少し深ぼって調査していきたいと思います。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 参考 https://note.com/ak_schweitzer/n/n2a7b116c8ee8 https://qiita.com/4_mio_11/items/fed86efca7407a7975fb https://www.youtube.com/watch?v=b8AwUvTaCs0& 執筆： @okazaki.wataru 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回はUE5で コリジョン （衝突）判定機能を使って、自動で開閉するドアや、 NPC との簡単な会話システムを作成してみます。 はじめに UE5ではフィールド上のさまざまなオブジェクトや、プレイヤーが操作するキャ ラク ターに コリジョン 判定機能を持たせることができます。 これにより、物体にキャ ラク ターが当たった時や、前もって設定しておいた領域に他のオブジェクトが侵入した時などに、 任意の機能を作成できます。 今回はこの コリジョン 判定機能を利用して下記2つの機能を実装します。 キャ ラク ターが近づくと開き、遠ざかると閉じる自動ドアの機能 対象キャ ラク ター（ NPC ）にプレイヤーが近づき、任意のキーボードを押すと会話が行われる機能 検証環境/ツール Unreal Engine5.2.0 AWS EC2 Windows _Server-2022-English-Full-Base-2023.01.19 実装手順 【自動ドア編】タイムラインを利用したドアのアニメーションの作成 【自動ドア編】 コリジョン を利用した自動開閉システムの作成 【 NPC 会話編】会話UI用の ウィジェット の作成 【 NPC 会話編】 コリジョン を利用した会話UI用の ウィジェット の表示 【 NPC 会話編】 NPC 毎のメッセージ内容切り替え 1. 【自動ドア編】タイムラインを利用したドアのアニメーションの作成 今回はThirdPersonテンプレートを利用したプロジェクトで進めていきます。 まず初めにドアに使用するアクターのBluePrintを作成します。 コンテンツドロワーより、BlueprintClassを選び、Actorを選択します。今回は「BP_Door」という名前にします。 「BP_Door」の編集画面に入ります。 コンポーネント 追加ボタンより、「Static Mesh」を追加し、「Door」と 命名 します。 右側の詳細パネルより、Static Meshのセレクトボックスでスターターコンテンツの「SM_Door」を選びます。 次にドアの当たり判定用に コンポーネント 追加ボタンより、「Box Collision」を追加し、ドアの大きさに合わせて変更します。 またキャ ラク ターがドアをすり抜けてしまわないよう、今作った「Box Collision」のあたり判定を設定する コリジョン プリセットの値を「BlockAllDynamic」に変更します。 続いて、作成したドアにアニメーションをつけていきます。 本ステップでは、ドアにアニメーションをつけることが目的なので、わかりやすくするため、 ゲーム開始時に、ドアが開く仕組みを作成します。 「BP_Door」のイベントグラフを開きます。 「イベント BeginPlay」の後に、ドアに動きをつけるためにタイムラインを使用します。 以前のこちらの記事（UE5 x ZBrushでタイムラインを活用したアニメーションを作成する） で、タイムラインについて詳しく説明しているので、今回は割愛します。 「DoorOpenRate」という名前でタイムラインを作成し、さらに「Rate」というトラックを作成し、下記値を追加しました。 秒数0:値0 秒数0.5:値1 イベントグラフに戻ると、返却値として「Rate」を持つタイムラインができているので、「イベント BeginPlay」のピンとつなぎます。 次に「Make Rotator」ノードを作成しZ軸の値を「90」に設定します。これはドアが90度開くための値になります。 「乗算」ノードを追加し、下の写真のように作成したタイムラインとつなぎます。 最後に「Set Relative Rotation(Door)」を選択し、「New Rotation」にタイムラインから乗算した値をつなぎます。 コンパイル し、Map上に「BP_Door」を配置を行い、ゲームを開始することでドアが開くアニメーションを確認できます。 2. 【自動ドア編】 コリジョン を利用した自動開閉システムの作成 ここでは、 コリジョン を利用して、キャ ラク ターが近づくと自動で開き、離れると自動で閉じるドアにします。 ちなみに先ほどドアに「Box Collision」を使いましたが、これはキャ ラク ターがドアを通り抜けられなくするための コリジョン のため、 これから作る自動ドアの範囲を示す コリジョン とは別のものになります。 「BP_Door」を開き、「 Sphere Collision」を追加します。 次に、「 Sphere Collision」をドアの中心へ移動し拡大を行い、キャ ラク ターが入ると自動でドアが開く領域を設定します。 詳細パネルのイベント欄から「On Component Begin Overlap」と「On Component End Overlap」の右のプラスボタンを押します。 イベントグラフに下のようなノードができていることを確認します。 作成された「On Component Begin Overlap」を「イベント BeginPlay」と入れ替えることで、キャ ラク ターが コリジョン で設定した領域に入ることでドアが開く挙動になります。 また、「On Component End Overlap」をタイムラインの「Reverse」ピンに接続することで、タイムラインで設定した値と逆の挙動が行われるので、キャ ラク ターが領域からでた際にドアが閉まります。 以上がキャ ラク ターが近づくと開き、遠ざかると閉じる自動のドアの機能の紹介になります。 3. 【 NPC 会話編】会話UI用の ウィジェット の作成 続いて、対象キャ ラク ター（ NPC ）にプレイヤーが近づき、任意のキーボードを押すと会話が行われる機能の作成手順を紹介します。 まずは会話UIに使用する ウィジェット を作成するために、「 Widget Blueprint」を「WBP_ Talk 」という名前で作成します。 ウィジェット の作成方法は 以前のこちらの記事（UE5 PixelStreamingで、マウスカーソルを別の画像に変更してクリックイベントを作成する） で紹介しております。 まずはパレット内の一般から「Border」を「WBP_ Talk 」内に ドラッグ&ドロップ し、「 Canvas Panel」でラップします。 詳細パネルからアンカーを選び、下に伸びているものを選びます。 「Brush」内の「Tint」の部分にカラーピッカーがあるので「A（アルファ）」の値を「0.5」まで下げて、先ほど作成した「Border」を半透明にします。サイズを下の写真のように大きくして簡易的な会話テキストを置く部分のUIとします。 次にパレット内から「Text」を選び、今作成した「Border」内に ドラッグ&ドロップ します。 詳細タブの「Padding」から上下左右中央そろえにします。また、「Font」から文字サイズも「36」に変更します。 これで会話UI用の ウィジェット が出来ました。 実際に画面に表示させてみます。 スターターコンテンツで初期から入っているキャ ラク ターを使用します。 ファイルは、コンテンツ＞ThirdPerson＞Blueprints＞BP_ThirdPersonCharacter にあります。 まずはこのBlueprintから ウィジェット にアクセスできるように設定します。 「 ウィジェット を作成」ノードを追加し、Class属性にWBP_ Talk を設定します。また「Owning Player」には「Get Player Controller」をつなぎます。 次に ウィジェット を作成ノードを「イベント BeginPlay」のピンとつなげます。 「WBP_ Talk ウィジェット を作成」のノードの「Return Value 」を変数としてセットし、「UI_ Talk 」と 命名 します。 次に 「Q」 を押した時に ウィジェット を画面に表示させるようにします。 「Add to Viewport(UI_ Talk )」を選び、 「Q」 のノードとつなぎます。 これで実際に画面に会話用のUIを表示することが出来ました。 ここまでで、会話用のUIに必要な ウィジェット の準備が整いました。 続いて コリジョン を利用して、プレイヤーが操作しているキャ ラク ターの前に、他のキャ ラク ターがいる時のみ 「Q」 を押すことで、会話用のUIを出す機能を作成します。 4. 【 NPC 会話編】 コリジョン を利用した会話UI用の ウィジェット の表示 まずは「BP_ThirdPersonCharacter」のキャ ラク ターに、先ほどドアを作成した時と同じように「 Sphere Collision」を作成します。 キャ ラク ターの前方に下の写真のように「 Sphere Collision」を配置します。 イベントグラフに戻り、「Get Overlapping Actors( Sphere )」を作成します。これは先ほど作成した「 Sphere Collision」に 接触 しているアクターの一覧を配列で返してくれるノードになります。 先ほど作成した 「Q」 を押した後の「ブランチ（IF文）」でfalseだった時に「For Each Loop With Break」ノードで「 Sphere Collision」に 接触 しているアクターの配列を展開します。 本ステップではまだアクターごとに会話の文章の内容を分けず、 コリジョン 内にアクターがある場合のみ会話用のUIを出すだけの処理なので下の写真のように「Add to Viewport」につなぎ、配列がなくなるまでループさせます。 これで、 コリジョン 内にアクターが1つでもあれば、 「Q」 を押すことで会話用のUIを表示できます。 また、このままだと会話用UIが出たままになってしまうので、消去する処理も作成します。 「IsTalk」というBooleanの変数を作成し、会話中ではない時のみ画面に会話用UIが出るように設定します。 また会話中の場合は、画面から会話用UIを消すために「Remove From Parent」ノードを追加し、画面から会話用UIを消去し、「IsTalk」のフラグをfalseに変更します。 実際に試してみるために、マップにいくつかアクターを設置させます。 どんなアクターでも良いですが、今回は NPC 風の人型アクターを作成して設置します。 Blueprint作成画面からCharacterを選択して「BP_ NPC 」を作成します。 コンポーネント 一覧よりより、「Mesh」を選択し、詳細パネルよりメッシュを選びます。今回は「SK_Mannequin」を選択します。 マテリアルも任意のものを選び、マップに配置します。 ここまでの実装で、プレイヤーが操作するキャ ラク ターの前にアクターがある時のみ、 「Q」 を押すことで、会話用のUIが出てくる処理が完成しました。 続いて、マップに配置した NPC ごとに会話の内容を変更させる機能を作成し説明します。 5. 【 NPC 会話編】 NPC 毎のメッセージ内容切り替え まずはアクター間を超えて共通の会話用の関数を使用できるようにブループリントインターフェースを作成します。 コンテンツドロワーからブループリントインターフェースを作成し、「BPI_ Talk 」と 命名 します。 編集画面で「CanTalk」というBooleanを返す関数と、「GetTalkMessage」というTextを返す関数を作成します。 「BP_ NPC 」で2つの関数を使用するために、「BP_ NPC 」を開き画面上部のクラス設定を押し、右側の実装インターフェースのセレクトボックスより「BPI_ Talk 」を選択します。 左側にインターフェース欄が追加され、先ほど作成した2つの関数があることを確認します。 左側のインターフェース欄から「CanTalk」をダブルクリックで開き、Booleanの返り値をtrueに設定します。 同様に「GetTalkMessage」を開き、リターンノードのTextの返り値を変数としてセットし、「TalkMessage」と 命名 します。 さらに、変数欄の右側の目のアイコンをクリックして、UEの全体の編集画面から直接変数の値を変更できるように設定しておきます。 最後のステップとして「BP_ThirdPersonCharacter」を開き、前にいるアクター（BP_ NPC ）が「CanTalk」でtrueを返しているかをチェックし、trueだった場合に「TalkMessage」でセットした文字列を会話用UIに埋め込んで表示させる処理を作成します。 先ほど配列で取得した コリジョン 内のアクターをForEachで回している部分で、「CanTalk」がtrueかどうか確認するためにノードを追加します。 trueだった場合に、さらにそのアクターが設定してある会話の内容を「GetTalkMessage」から取得します。 （BP_ NPC は全て「CanTalk」をtrueで返す設定をしています。） 「GetTalkMessage」のターゲットはアクターの配列が入っている「Array Element」です。 次に取得してきた会話の内容を「WBP_ Talk 」の中に埋め込みます。 「WBP_ Talk 」を開き、階層から「Text」を選択します。次に右上の「is Variable」にチェックを入れ、「 Widget _TalkMessage」と 命名 します。 「WBP_ Talk 」をグラフ表示に変更して、関数を作成します。今回は「 Widget _SetTextMessage」と 命名 します。 インプットにTextを設定します。 「SetText(Text)」ノードをつなぎ、ターゲットに「 Widget _TalkMessage」を設定し、ターゲットに「UI_ Talk 」をつなぎます。 「BP_ThirdPersonCharacter」に戻り、「 Widget _SetTextMessage」ノードを作成し、「GetTalkMessage」とつなぎます。 最後に「Add to Viewport」と繋ぐことでBlueprint側での処理は完了です。 全体の処理は下記のような流れになっています。 UEの編集画面からアクターを選択し、詳細タブの「 Talk Massage」欄に任意の文言を追加することで、アクターごとに会話する内容を設定できます。 実際に会話を行ってみます。 以上が コリジョン 機能を使って、自動で開閉するドアや、 NPC との簡単な会話システムの作成方法の紹介です。 所感 コリジョン を利用することで、オブジェクトを動かしたり、重なったアクターの情報を取得したりと、さまざまな使い方ができることがわかりました。 また、基本的な会話の作り方もわかったので、より複雑な会話方法や、 ウィジェット の作成方法なども学習していきます。 特に ウィジェット でできることはまだまだありそうなので、もう少し深ぼって調査していきたいと思います。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研中途採用ページ 電通総研新卒採用ページ 参考 https://note.com/ak_schweitzer/n/n2a7b116c8ee8 https://qiita.com/4_mio_11/items/fed86efca7407a7975fb https://www.youtube.com/watch?v=b8AwUvTaCs0& 執筆： @okazaki.wataru 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 今回は、 Expo に入門します。 Expo とは、開発者が React Native 単体で開発した場合に意識しないといけなかったネイティブ部分を隠蔽して、アプリケーション本体の開発をより Web アプリケーションの開発体験に近づけたものです。 expo cliのインストール Expo Goのインストール プロジェクトの作成 QRコードの読み取り アプリの修正 まとめ 仲間募集 expo cli のインストール expo cli は、下記のようにして、npxでインストールするようです。 npx expo -h 実行すると下記のように言われるので、yでインストールします。 Need to install the following packages: expo@48.0.17 Ok to proceed? (y) Expo Goのインストール Expo Go は、ローカルで何も構築する必要がなく、Android および iOS 上で React Native アプリをテストするための無料のオープンソース クライアントです。 Android または iOS デバイスで Expo Go クライアントアプリを使用するのが、最も速く起動して実行できる方法です。これにより、Expo CLI を通じて提供されるアプリを開いて、開発時にプロジェクトをより速く実行できます。 と公式が言っているので、Expo Goを使いましょう。 iOSのApp Store や AndroidのPay Store からインストールしてください。 プロジェクトの作成 npx create-expo-app my-app でプロジェクトを作成しましょう。 my-app に移動して、プロジェクトを開始します。 cd my-app npx expo start QRコード の読み取り QRコード が表示されます。 Scan the QR code above with Expo Go (Android) or the Camera app (iOS) と言われるので、僕は、 iPhone のカメラで QRコード を読み込みました。Expo Goが立ち上がって、下記のようにアプリが表示されます。 Open up App.js to start working on your app! アプリの修正 my-app ディレクト リで、 VS Code を立ち上げます。 code . App.js のTextタグで囲まれている部分を適当に修正してください。アプリの表示もすぐ変わります(HOT Reloading)。 まとめ Expoは、Webアプリを開発しているような感覚で、Nativeアプリを開発できるというのは、本当だなと感じました。Expoはもう少し詳しく見ていきたいと思います。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 今回は、 Expo に入門します。 Expo とは、開発者が React Native 単体で開発した場合に意識しないといけなかったネイティブ部分を隠蔽して、アプリケーション本体の開発をより Web アプリケーションの開発体験に近づけたものです。 expo cliのインストール Expo Goのインストール プロジェクトの作成 QRコードの読み取り アプリの修正 まとめ 仲間募集 expo cli のインストール expo cli は、下記のようにして、npxでインストールするようです。 npx expo -h 実行すると下記のように言われるので、yでインストールします。 Need to install the following packages: expo@48.0.17 Ok to proceed? (y) Expo Goのインストール Expo Go は、ローカルで何も構築する必要がなく、Android および iOS 上で React Native アプリをテストするための無料のオープンソース クライアントです。 Android または iOS デバイスで Expo Go クライアントアプリを使用するのが、最も速く起動して実行できる方法です。これにより、Expo CLI を通じて提供されるアプリを開いて、開発時にプロジェクトをより速く実行できます。 と公式が言っているので、Expo Goを使いましょう。 iOSのApp Store や AndroidのPay Store からインストールしてください。 プロジェクトの作成 npx create-expo-app my-app でプロジェクトを作成しましょう。 my-app に移動して、プロジェクトを開始します。 cd my-app npx expo start QRコード の読み取り QRコード が表示されます。 Scan the QR code above with Expo Go (Android) or the Camera app (iOS) と言われるので、僕は、 iPhone のカメラで QRコード を読み込みました。Expo Goが立ち上がって、下記のようにアプリが表示されます。 Open up App.js to start working on your app! アプリの修正 my-app ディレクト リで、 VS Code を立ち上げます。 code . App.js のTextタグで囲まれている部分を適当に修正してください。アプリの表示もすぐ変わります(HOT Reloading)。 まとめ Expoは、Webアプリを開発しているような感覚で、Nativeアプリを開発できるというのは、本当だなと感じました。Expoはもう少し詳しく見ていきたいと思います。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア 執筆： @higa （ Shodo で執筆されました ）

こんにちは、X（クロス） イノベーション 本部 クラウド イノベーション センターの田村です。 普段は Microsoft が提供する クラウド サービスである Azure を活用した案件支援や、研究開発を担当しています。 本記事では、業務内容や 1 週間の過ごし方など、私の主な働き方についてざっくりとご紹介します。 IT 企業への就職を検討されている学生の方や、ISID にご興味をお持ちの方の参考になれば幸いです。 自己紹介 業務内容 案件支援 研究開発 その他 1 週間の過ごし方 最後に 自己紹介 タイトルにもありますが、2020 年に新卒入社した 4 年目社員です。 入社後に半年間の研修を経て、 クラウド イノベーション センターに配属となりました。 学生時代に クラウド をはじめとした IT 系の 経験がほぼなく、「絶対に クラウド に関する仕事がしたい」といった希望もなかったため意外ではありましたが、何かの縁だろうと仕事を続け今日に至ります。 業務内容 冒頭でご紹介した通り、 Microsoft Azure を活用した案件支援と研究開発が主な業務です。 Azure といっても多種多様なサービスがありますが、私の業務では主にデータ分析の領域を扱っています。 具体的に何をしているのかについては、個別でご紹介いたします。 案件支援 近年は IoT や ビッグデータ などのワードが普及し、企業においてもデータ分析のニーズが高まっています。 ISID に限らず、データ分析を中心に据えたプロジェクトは数多くありますが、私が参画する支援業務で求められるのは「お客様の抱える様々な潜在・顕在課題や要望に対して、Azure を活用したデータ分析による価値提供を行う」ことです。 実際にいただいたお客様からの要望にはこんなものがあります。 社内に散在している業務データを一元管理できるデータ分析基盤を構築してほしい オフィスビル 内の環境情報（温度/湿度/照度/空気状態など）を収集・分析し一目で把握したい オフィスビル のデジタルツインを作成する実証実験（PoC）を実施したい お客様の要望に応じて作業内容は異なりますが、大まかには ヒアリ ングを重ねて要件をすり合わせる、Azure および周辺システムの設計・構築を行う、分析結果を可視化するレポート画面の作成をする、といった業務を経験してきました。 現場ではデータ分析に限定しない Azure の幅広いサービスや 他の Microsoft 製品、場合によっては他社ソリューションに対する知識・スキルが要求されるので、 クラウド エンジニアという職種としてよい経験が積めていると感じています。 研究開発 Azure のデータ領域におけるアップデート内容の調査検証が中心です。 Azure をはじめとする クラウド サービスは一般的なパッケージ製品と比較してアップデートのスパンが短く、1 週間後には機能・仕様が変更されるというケースもあります。 そのような変化に追いついていくために、チーム内で Azure の新しいサービスや機能を共有し、「将来的に案件支援や社内ソリューションに適用できる見込みがある」と判断したものに対して調査検証を実施しています。 具体的な調査検証の内容については、以前に投稿した記事をご覧ください。 Azure Managed Grafana について調べてみた 調査検証の結果は下記の観点でまとめ、資料化して社内に展開しています。 また、インターネット上に同様の調査結果が報告されていない場合は、前述したようにこちらのテックブログや Qiita/ Twitter で社外発信する場合もあります。 どのようなアップデートなのか？ できること、できないことは何か？ 調査検証時点で考えられる具体的な使用例は何か？ 類似・競合サービスとの差別化点は？ どのくらいのコストが必要か？ 上記の他にも、Azure を活用した社内ソリューション開発、Azure データ分析プロジェクトで要件定義から運用に必要なツールやドキュメントを網羅したテンプレートの作成、データ領域におけるトレンドの調査などを実施してきました。 研究開発の内容に関わらず、ノウハウを蓄積し案件支援に活かしていくというサイクルを大事にしています。 その他 ここまで記載したもの以外にも、経験してきた業務がいくつかあります。 新卒社員向けの システム開発 研究のサポート OJT サポート業務 新規事業開発・提案 ISID は、若い年次でも「やりたい」という仕事をアピールすればチャレンジできる土壌があると感じています。 1 週間の過ごし方 プロジェクトの状況によってまちまちですが、おおよそ下図の通りです。 毎日の始業時に朝会を実施し、チーム内で本日の業務内容と全体のタスク、事務連絡等を共有します。 その後は案件支援や研究開発に関する打ち合わせや個人作業の時間となり、空き時間は自己学習やこういった記事執筆などに充てています。 基本的にテレワークなので終業後は自宅で過ごすことが多いですが、週 1 程度で同期とフットサルをしています。 最後に X（クロス） イノベーション 本部 クラウド イノベーション センターでは、新卒・キャリア採用問わず共に働いてくれる仲間を探しています。 本記事で紹介した私の働き方や、 クラウド を中心とした業務にご興味をお持ちの方は、ぜひ採用ページよりご応募ください。 新卒採用の方： ISID 新卒採用サイト キャリア採用の方： ISID グループ キャリア採用サイト - クラウドアーキテクト 執筆： @tamura.kohei 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは、X（クロス） イノベーション 本部 クラウド イノベーション センターの田村です。 普段は Microsoft が提供する クラウド サービスである Azure を活用した案件支援や、研究開発を担当しています。 本記事では、業務内容や 1 週間の過ごし方など、私の主な働き方についてざっくりとご紹介します。 IT 企業への就職を検討されている学生の方や、ISID にご興味をお持ちの方の参考になれば幸いです。 自己紹介 業務内容 案件支援 研究開発 その他 1 週間の過ごし方 最後に 自己紹介 タイトルにもありますが、2020 年に新卒入社した 4 年目社員です。 入社後に半年間の研修を経て、 クラウド イノベーション センターに配属となりました。 学生時代に クラウド をはじめとした IT 系の 経験がほぼなく、「絶対に クラウド に関する仕事がしたい」といった希望もなかったため意外ではありましたが、何かの縁だろうと仕事を続け今日に至ります。 業務内容 冒頭でご紹介した通り、 Microsoft Azure を活用した案件支援と研究開発が主な業務です。 Azure といっても多種多様なサービスがありますが、私の業務では主にデータ分析の領域を扱っています。 具体的に何をしているのかについては、個別でご紹介いたします。 案件支援 近年は IoT や ビッグデータ などのワードが普及し、企業においてもデータ分析のニーズが高まっています。 ISID に限らず、データ分析を中心に据えたプロジェクトは数多くありますが、私が参画する支援業務で求められるのは「お客様の抱える様々な潜在・顕在課題や要望に対して、Azure を活用したデータ分析による価値提供を行う」ことです。 実際にいただいたお客様からの要望にはこんなものがあります。 社内に散在している業務データを一元管理できるデータ分析基盤を構築してほしい オフィスビル 内の環境情報（温度/湿度/照度/空気状態など）を収集・分析し一目で把握したい オフィスビル のデジタルツインを作成する実証実験（PoC）を実施したい お客様の要望に応じて作業内容は異なりますが、大まかには ヒアリ ングを重ねて要件をすり合わせる、Azure および周辺システムの設計・構築を行う、分析結果を可視化するレポート画面の作成をする、といった業務を経験してきました。 現場ではデータ分析に限定しない Azure の幅広いサービスや 他の Microsoft 製品、場合によっては他社ソリューションに対する知識・スキルが要求されるので、 クラウド エンジニアという職種としてよい経験が積めていると感じています。 研究開発 Azure のデータ領域におけるアップデート内容の調査検証が中心です。 Azure をはじめとする クラウド サービスは一般的なパッケージ製品と比較してアップデートのスパンが短く、1 週間後には機能・仕様が変更されるというケースもあります。 そのような変化に追いついていくために、チーム内で Azure の新しいサービスや機能を共有し、「将来的に案件支援や社内ソリューションに適用できる見込みがある」と判断したものに対して調査検証を実施しています。 具体的な調査検証の内容については、以前に投稿した記事をご覧ください。 Azure Managed Grafana について調べてみた 調査検証の結果は下記の観点でまとめ、資料化して社内に展開しています。 また、インターネット上に同様の調査結果が報告されていない場合は、前述したようにこちらのテックブログや Qiita/ Twitter で社外発信する場合もあります。 どのようなアップデートなのか？ できること、できないことは何か？ 調査検証時点で考えられる具体的な使用例は何か？ 類似・競合サービスとの差別化点は？ どのくらいのコストが必要か？ 上記の他にも、Azure を活用した社内ソリューション開発、Azure データ分析プロジェクトで要件定義から運用に必要なツールやドキュメントを網羅したテンプレートの作成、データ領域におけるトレンドの調査などを実施してきました。 研究開発の内容に関わらず、ノウハウを蓄積し案件支援に活かしていくというサイクルを大事にしています。 その他 ここまで記載したもの以外にも、経験してきた業務がいくつかあります。 新卒社員向けの システム開発 研究のサポート OJT サポート業務 新規事業開発・提案 ISID は、若い年次でも「やりたい」という仕事をアピールすればチャレンジできる土壌があると感じています。 1 週間の過ごし方 プロジェクトの状況によってまちまちですが、おおよそ下図の通りです。 毎日の始業時に朝会を実施し、チーム内で本日の業務内容と全体のタスク、事務連絡等を共有します。 その後は案件支援や研究開発に関する打ち合わせや個人作業の時間となり、空き時間は自己学習やこういった記事執筆などに充てています。 基本的にテレワークなので終業後は自宅で過ごすことが多いですが、週 1 程度で同期とフットサルをしています。 最後に X（クロス） イノベーション 本部 クラウド イノベーション センターでは、新卒・キャリア採用問わず共に働いてくれる仲間を探しています。 本記事で紹介した私の働き方や、 クラウド を中心とした業務にご興味をお持ちの方は、ぜひ採用ページよりご応募ください。 新卒採用の方： ISID 新卒採用サイト キャリア採用の方： ISID グループ キャリア採用サイト - クラウドアーキテクト 執筆： @tamura.kohei 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回はUE5で マルチプレイ に対応したエモート機能を作成する方法をご紹介します。 エモート機能とは、 マルチプレイ のゲームにおいて、各キャ ラク ターが感情を表現する為の機能です。 例えば Fortnite ではキャ ラク ターに様々な動きやダンスをさせることができます。 はじめに UE5では「ListenServer」と「DedicatedServer」の2種類のゲームサーバー方式が使用可能です。 各サーバーについては、こちらの 金融ソリューション事業部の山下さんの記事 で紹介されているので説明は割愛します。 今回は検証を簡易にするため「ListenServer」を使用して マルチプレイ でのエモート機能を作成しますが、 「DedicatedServer」でも同じ挙動をする実装方法となります。 検証環境/ツール Unreal Engine5.2.0 AWS EC2 Windows _Server-2022-English-Full-Base-2023.01.19 実装手順 エモート用WidgetBlueprintの作成 エモート用 Widget をCharacterBlueprintに付与 CharacterBlueprintの動作作成 マルチプレイ 用 レプリケーション 設定 1. エモート用WidgetBlueprintの作成 今回はThirdPersonテンプレートを利用したプロジェクトで進めていきます。 まず初めにエモート用 Widget に使用するWidgetBluePrintを作成します。 コンテンツドロワーより、WidgetBlueprintを選び「WBP_IconEmote」で作成します。 以前紹介した UE5 PixelStreamingで、マウスカーソルを別の画像に変更してクリックイベントを作成する記事 にて、 WidgetBlueprint内に任意の画像を取り込む方法があるので、同様にエモートに使用したい画像を取り込み「IconEmote」という名前をつけました。また前回同様「 Canvas Panel」を作成し、位置を中心に変更させます。 今回は別のBlueprintでもこの Widget を呼び出して使う予定なので、詳細タブの上部にある「Is Variable」にチェックを入れておきます。 2. エモート用 Widget をCharacterBlueprintに付与 まずはCharacterBlueprintを開きます。 ThirdPersonTemplateを使用して作成したプロジェクトの場合、 All＞Content＞ThirdPerson＞Blueprints内に「BP_ThirdPersonCharacter」を見つけることができます。 「BP_ThirdPersonCharacter」のViewPortを開き、 Widget 用の コンポーネント を追加します。 ViewProt左上部の追加ボタンを押して Widget と検索し、クリックで選択します。 左側の コンポーネント 一覧に追加されるので、名前を「 Widget _IconEmote」と変更します。 次に追加した「 Widget _IconEmote」と、先ほど作成した「WBP_IconEmote」を連携させます。 右側の ユーザーインターフェース 内の「 Widget Class」のセレクトボックスで「WBP_IconEmote」を選択します。 連携すると下記画像のように追加したエモート画像がCharacterBlueprintに付与されます。 トランスフォーム欄から位置や大きさを動かすことで、エモート機能のようになってきました。 コンパイル 、保存を行い、レベルのViewPortで確認してみます。 キャ ラク ターの頭上にアイコンを出すことは出来ましたが、キャ ラク ターが横を向くとアイコンも横を向いてしまい画面から見えなくなってしまいました。 解決法として、ViewPortの ユーザーインターフェース 欄のSpaceのセレクトボックスを「World」から「画面」を選ぶことで、キャ ラク ターがどの向きを向いてもエモートアイコンが見えるように設定できます。 3. CharacterBlueprintの動作作成 今回は、キーボードの「5」を押した時に、2秒間エモートアイコンがキャ ラク ターの頭上に表示されるBlueprintを作成します。 今のままでは、アイコンが出続けてしまうのでまずゲームスタートとともにアイコンを隠す処理を行います。 まずは「BP_ThirdPersonCharacter」から「WBP_IconEmote」に接続できるように「Event BeginPlay」から「Cast To WBP_IconEmote」をピンでつなげます。 さらにObject属性に対して、「Get User Widget Object」ノードを追加し、ターゲットを「 Widget Icon Emote」にします。 これにより、「BP_ThirdPersonCharacter」から「WBP_IconEmote」に接続できるようになりました。 次に、アイコンを非表示にするために「Set Visibility」ノードを接続し、ターゲットを「Cast To WBP_IconEmote」の「As WBP Emote」に接続します。「In Visibility」の値を「非表示」にすることで、アイコンを非表示にできますが、今回は後述の マルチプレイ 用に、表示・非表示を司る変数を作成しておきます。 画面左下の変数欄からプラスを押し、「var_IconEmoteByte」という変数を作成します。タイプはByteを選択し、デフォルト値を「2」にします。 作成した「var_IconEmoteByte」を「Set Visibility」につなぎます。 ここで入力した「2」というのは、「In Visibility」の値の配列番号になり、「非表示」を意味しています。 ここまでで、キャ ラク ター頭上のアイコンは一旦非表示になっているはずです。 次にキーボードの「5」を押した時にアイコンを表示させる処理の説明を行います。 「Press 5」ノードを追加し、「Pressed」のピンに対して、「var_IconEmoteByte」をセットするためのノードを追加します。 変数の値を「0」（「In Visibility」の値の配列番号になり、「表示」の意）に書き換える処理の後に、先ほど作成した「Cast To WBP_IconEmote」の流れを複製します。 これにより、キーボードの「5」を押した時にアイコンを表示させることができます。 しかし、この状態ではまだ左右の画面（ マルチプレイヤー 間）での同期は取れていないので、 次のステップで修正していきます。 4. マルチプレイ 用 レプリケーション 設定 UEで マルチプレイ を行う際は、ゲームサーバーがゲームクライアントに対して、情報をレプリケート（複製）することで、 各クライアント間（プレイヤー間）での差異が生じないようになります。 今回作った処理は、まだクライアントで行われているだけの処理なので、クライアント間では同期されません。 まずは先ほど作成した変数「var_IconEmoteByte」を レプリケーション する設定にします。 「var_IconEmoteByte」の詳細画面から レプリケーション の設定を「RepNotify」に設定します。 「RepNotify」とは、変数の値をウォッチしており、変数の値が変わった時に後続の関数「OnRep〜」関数を起動させます。 変数を「RepNotify」設定にすると、左側の関数欄に「OnRep_var_IconEmoteByte」という関数ができます。 次に、「Cast To WBP_IconEmote」から「Set Visibility」の処理をコピーし、「OnRep_var_IconEmoteByte」内で貼り付けます。 「OnRep_var_IconEmoteByte」内への移動方法は、左側の関数欄の「OnRep_var_IconEmoteByte」をダブルクリックすることで移動ができます。 貼り付けた処理を「On Rep Var Icon Emote Byte」ノードに繋ぎ、元あった場所の処理は消してしまいます。 これで、「var_IconEmoteByte」の値が書き換わった際に、後続の処理をゲームサーバーからゲームクライアントに同期してくれるようになります。 アイコンを表示させてから2秒後にアイコンを消す処理を追加するために、下のように「Delay」ノードと「var_IconEmoteByte」のセット用のノードを追加します。非表示にする必要があるので、「var_IconEmoteByte」の値は「2」にします。 実行すると下の動画のようになります。 左側の画面のプレイヤーのエモートアイコンは右側の画面に同期されているのに対し、右側の画面のエモートは左側に同期されていないことがわかります。 この挙動はリッスンサーバーで検証を行っているためのものです。 リッスンサーバーでは１人のプレイヤーがゲームサーバーとゲームクライアント両方の機能をもち、 その他のプレイヤーがゲームクライアントだけの機能を持ちます。 上の動画では左側がゲームサーバーを持っているクライアントで、右側がゲームクライアントだけの画面になります。 UEの レプリケーション 機能では、 ゲームサーバーが情報をレプリケート（複製）してゲームクライアントの情報を書き換え、同期することは出来ますが、 ゲームクライアントがゲームサーバーの情報を書き換えて同期することは出来ません。 また、クライアントがクライアントの情報を書き換えて同期することも出来ません。 まとめると下記のようになります。 ゲームサーバーでの情報変更　→　ゲームサーバーの情報を複製して、ゲームクライアントの情報を書き換えることが可能 ゲームクライアントでの情報変更　→　ゲームクライアントの情報を複製して、ゲームサーバーの情報を書き換えることは不可能 ゲームクライアントでの情報変更　→　ゲームクライアントの情報を複製して、他のゲームクライアントの情報を書き換えることは不可能 上記の理由から、左側の行動はレプリケートされ、右側の行動はレプリケートされない処理になってしまっているので修正していきます。 まずはカスタムイベントを追加します。今回は「Press5sync」という名前のイベントにしました。 「Press5sync」を選択し、右側の詳細画面から複製欄で「サーバーで実行」を選択します。 次にキーボードの「5」を押して起動する処理を、今作った「Press5sync」に繋ぎ直し、キーボードの「5」の処理は「Press5sync」を起動させるためにつなぎます。 これにより、ゲームクライアント側で行われた処理も、ゲームサーバーで実行する形式をとるのでゲームサーバーとゲームクライアント間で同期が取れるようになります。 同様の手順で、TextタイプのWidgetBlueprintを追加することで、下記のようなエモートを追加することもできます。 以上が、 マルチプレイ に対応したエモート機能を作成する手順になります。 所感 今回のUE5で マルチプレイ に対応したエモート機能を作成する手順を調査するにあたり、 UE5でのWidgetBlueprintの使用方法や、 マルチプレイ のゲームサーバー、ゲームクライアント間の関係性などに詳しくなることが出来ました。 マルチプレイ のプロジェクトを作成するにあたり、プレイヤー間の情報の同期（ レプリケーション ）は必須事項になるので、今回の基礎的な知識をもとに、より複雑な レプリケーション の方法なども学習していきます。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 参考 https://docs.unrealengine.com/4.26/ja/InteractiveExperiences/Networking/HowTo/DedicatedServers/ https://docs.unrealengine.com/4.27/ja/Resources/ContentExamples/Networking/1_4/ https://qiita.com/Shibash/items/2408b653abe0549abe37 執筆： @okazaki.wataru 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回はUE5で マルチプレイ に対応したエモート機能を作成する方法をご紹介します。 エモート機能とは、 マルチプレイ のゲームにおいて、各キャ ラク ターが感情を表現する為の機能です。 例えば Fortnite ではキャ ラク ターに様々な動きやダンスをさせることができます。 はじめに UE5では「ListenServer」と「DedicatedServer」の2種類のゲームサーバー方式が使用可能です。 各サーバーについては、こちらの 金融ソリューション事業部の山下さんの記事 で紹介されているので説明は割愛します。 今回は検証を簡易にするため「ListenServer」を使用して マルチプレイ でのエモート機能を作成しますが、 「DedicatedServer」でも同じ挙動をする実装方法となります。 検証環境/ツール Unreal Engine5.2.0 AWS EC2 Windows _Server-2022-English-Full-Base-2023.01.19 実装手順 エモート用WidgetBlueprintの作成 エモート用 Widget をCharacterBlueprintに付与 CharacterBlueprintの動作作成 マルチプレイ 用 レプリケーション 設定 1. エモート用WidgetBlueprintの作成 今回はThirdPersonテンプレートを利用したプロジェクトで進めていきます。 まず初めにエモート用 Widget に使用するWidgetBluePrintを作成します。 コンテンツドロワーより、WidgetBlueprintを選び「WBP_IconEmote」で作成します。 以前紹介した UE5 PixelStreamingで、マウスカーソルを別の画像に変更してクリックイベントを作成する記事 にて、 WidgetBlueprint内に任意の画像を取り込む方法があるので、同様にエモートに使用したい画像を取り込み「IconEmote」という名前をつけました。また前回同様「 Canvas Panel」を作成し、位置を中心に変更させます。 今回は別のBlueprintでもこの Widget を呼び出して使う予定なので、詳細タブの上部にある「Is Variable」にチェックを入れておきます。 2. エモート用 Widget をCharacterBlueprintに付与 まずはCharacterBlueprintを開きます。 ThirdPersonTemplateを使用して作成したプロジェクトの場合、 All＞Content＞ThirdPerson＞Blueprints内に「BP_ThirdPersonCharacter」を見つけることができます。 「BP_ThirdPersonCharacter」のViewPortを開き、 Widget 用の コンポーネント を追加します。 ViewProt左上部の追加ボタンを押して Widget と検索し、クリックで選択します。 左側の コンポーネント 一覧に追加されるので、名前を「 Widget _IconEmote」と変更します。 次に追加した「 Widget _IconEmote」と、先ほど作成した「WBP_IconEmote」を連携させます。 右側の ユーザーインターフェース 内の「 Widget Class」のセレクトボックスで「WBP_IconEmote」を選択します。 連携すると下記画像のように追加したエモート画像がCharacterBlueprintに付与されます。 トランスフォーム欄から位置や大きさを動かすことで、エモート機能のようになってきました。 コンパイル 、保存を行い、レベルのViewPortで確認してみます。 キャ ラク ターの頭上にアイコンを出すことは出来ましたが、キャ ラク ターが横を向くとアイコンも横を向いてしまい画面から見えなくなってしまいました。 解決法として、ViewPortの ユーザーインターフェース 欄のSpaceのセレクトボックスを「World」から「画面」を選ぶことで、キャ ラク ターがどの向きを向いてもエモートアイコンが見えるように設定できます。 3. CharacterBlueprintの動作作成 今回は、キーボードの「5」を押した時に、2秒間エモートアイコンがキャ ラク ターの頭上に表示されるBlueprintを作成します。 今のままでは、アイコンが出続けてしまうのでまずゲームスタートとともにアイコンを隠す処理を行います。 まずは「BP_ThirdPersonCharacter」から「WBP_IconEmote」に接続できるように「Event BeginPlay」から「Cast To WBP_IconEmote」をピンでつなげます。 さらにObject属性に対して、「Get User Widget Object」ノードを追加し、ターゲットを「 Widget Icon Emote」にします。 これにより、「BP_ThirdPersonCharacter」から「WBP_IconEmote」に接続できるようになりました。 次に、アイコンを非表示にするために「Set Visibility」ノードを接続し、ターゲットを「Cast To WBP_IconEmote」の「As WBP Emote」に接続します。「In Visibility」の値を「非表示」にすることで、アイコンを非表示にできますが、今回は後述の マルチプレイ 用に、表示・非表示を司る変数を作成しておきます。 画面左下の変数欄からプラスを押し、「var_IconEmoteByte」という変数を作成します。タイプはByteを選択し、デフォルト値を「2」にします。 作成した「var_IconEmoteByte」を「Set Visibility」につなぎます。 ここで入力した「2」というのは、「In Visibility」の値の配列番号になり、「非表示」を意味しています。 ここまでで、キャ ラク ター頭上のアイコンは一旦非表示になっているはずです。 次にキーボードの「5」を押した時にアイコンを表示させる処理の説明を行います。 「Press 5」ノードを追加し、「Pressed」のピンに対して、「var_IconEmoteByte」をセットするためのノードを追加します。 変数の値を「0」（「In Visibility」の値の配列番号になり、「表示」の意）に書き換える処理の後に、先ほど作成した「Cast To WBP_IconEmote」の流れを複製します。 これにより、キーボードの「5」を押した時にアイコンを表示させることができます。 しかし、この状態ではまだ左右の画面（ マルチプレイヤー 間）での同期は取れていないので、 次のステップで修正していきます。 4. マルチプレイ 用 レプリケーション 設定 UEで マルチプレイ を行う際は、ゲームサーバーがゲームクライアントに対して、情報をレプリケート（複製）することで、 各クライアント間（プレイヤー間）での差異が生じないようになります。 今回作った処理は、まだクライアントで行われているだけの処理なので、クライアント間では同期されません。 まずは先ほど作成した変数「var_IconEmoteByte」を レプリケーション する設定にします。 「var_IconEmoteByte」の詳細画面から レプリケーション の設定を「RepNotify」に設定します。 「RepNotify」とは、変数の値をウォッチしており、変数の値が変わった時に後続の関数「OnRep〜」関数を起動させます。 変数を「RepNotify」設定にすると、左側の関数欄に「OnRep_var_IconEmoteByte」という関数ができます。 次に、「Cast To WBP_IconEmote」から「Set Visibility」の処理をコピーし、「OnRep_var_IconEmoteByte」内で貼り付けます。 「OnRep_var_IconEmoteByte」内への移動方法は、左側の関数欄の「OnRep_var_IconEmoteByte」をダブルクリックすることで移動ができます。 貼り付けた処理を「On Rep Var Icon Emote Byte」ノードに繋ぎ、元あった場所の処理は消してしまいます。 これで、「var_IconEmoteByte」の値が書き換わった際に、後続の処理をゲームサーバーからゲームクライアントに同期してくれるようになります。 アイコンを表示させてから2秒後にアイコンを消す処理を追加するために、下のように「Delay」ノードと「var_IconEmoteByte」のセット用のノードを追加します。非表示にする必要があるので、「var_IconEmoteByte」の値は「2」にします。 実行すると下の動画のようになります。 左側の画面のプレイヤーのエモートアイコンは右側の画面に同期されているのに対し、右側の画面のエモートは左側に同期されていないことがわかります。 この挙動はリッスンサーバーで検証を行っているためのものです。 リッスンサーバーでは１人のプレイヤーがゲームサーバーとゲームクライアント両方の機能をもち、 その他のプレイヤーがゲームクライアントだけの機能を持ちます。 上の動画では左側がゲームサーバーを持っているクライアントで、右側がゲームクライアントだけの画面になります。 UEの レプリケーション 機能では、 ゲームサーバーが情報をレプリケート（複製）してゲームクライアントの情報を書き換え、同期することは出来ますが、 ゲームクライアントがゲームサーバーの情報を書き換えて同期することは出来ません。 また、クライアントがクライアントの情報を書き換えて同期することも出来ません。 まとめると下記のようになります。 ゲームサーバーでの情報変更　→　ゲームサーバーの情報を複製して、ゲームクライアントの情報を書き換えることが可能 ゲームクライアントでの情報変更　→　ゲームクライアントの情報を複製して、ゲームサーバーの情報を書き換えることは不可能 ゲームクライアントでの情報変更　→　ゲームクライアントの情報を複製して、他のゲームクライアントの情報を書き換えることは不可能 上記の理由から、左側の行動はレプリケートされ、右側の行動はレプリケートされない処理になってしまっているので修正していきます。 まずはカスタムイベントを追加します。今回は「Press5sync」という名前のイベントにしました。 「Press5sync」を選択し、右側の詳細画面から複製欄で「サーバーで実行」を選択します。 次にキーボードの「5」を押して起動する処理を、今作った「Press5sync」に繋ぎ直し、キーボードの「5」の処理は「Press5sync」を起動させるためにつなぎます。 これにより、ゲームクライアント側で行われた処理も、ゲームサーバーで実行する形式をとるのでゲームサーバーとゲームクライアント間で同期が取れるようになります。 同様の手順で、TextタイプのWidgetBlueprintを追加することで、下記のようなエモートを追加することもできます。 以上が、 マルチプレイ に対応したエモート機能を作成する手順になります。 所感 今回のUE5で マルチプレイ に対応したエモート機能を作成する手順を調査するにあたり、 UE5でのWidgetBlueprintの使用方法や、 マルチプレイ のゲームサーバー、ゲームクライアント間の関係性などに詳しくなることが出来ました。 マルチプレイ のプロジェクトを作成するにあたり、プレイヤー間の情報の同期（ レプリケーション ）は必須事項になるので、今回の基礎的な知識をもとに、より複雑な レプリケーション の方法なども学習していきます。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 参考 https://docs.unrealengine.com/4.26/ja/InteractiveExperiences/Networking/HowTo/DedicatedServers/ https://docs.unrealengine.com/4.27/ja/Resources/ContentExamples/Networking/1_4/ https://qiita.com/Shibash/items/2408b653abe0549abe37 執筆： @okazaki.wataru 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

皆さんこんにちは！ISID新卒入社7年目の池内です。現在はEIT事業部（ エンタープライズ IT事業部）に所属しており、ISIDの自社開発製品である「BusinessSPECTRE」（ビジネ ススペ クトル）、「VisAP」（ヴィスエーピー）の提案、導入を担当しています。 このブログを通じ、私の仕事内容や1日の流れ、またISIDに少しでも興味を持ってもらえる就活生にとって役立つ情報を発信できればと思っています！ 1.　自己紹介 それでは早速、簡単に自己紹介させてください。 大学、大学院を卒業し、2017年に新入社員としてISIDへ入社しました。大学在学中は、特に情報系（プログラムとか）の授業をなるべく避けてきましたので、IT リテラシー はほぼ0。大学、大学院では 統計学 を専攻していました。 当時、製薬会社のデータサイエンティストを志望し、就活に励んでいましたが、残念ながらどの会社からも最終面接へのチケットをもらえず。やっぱり薬学部に進学しないとだめなのかな～とか、自分って将来どこで何して働くんだろう～とか、色々考えながら日々を過ごしていたところ、ISIDに出会うことができ入社することを決めました。 入社後の配属先としては、主に顧客の基幹システム（会計、販売、在庫など、顧客の心臓となるシステム）周りのお仕事をしている部署に配属されることになりました。 年度ごとに組織変更があり、部署名が変わってばかりですが、仕事内容は変わらず基幹システムの周辺領域（BIやDWHとも呼ばれる）のソリューションを提案したり導入したりしています。 ※ISIDの自社開発製品「BusinessSPECTRE」（ビジネ ススペ クトル）、「VisAP」（ヴィスエーピー）については、こちらのサイト（ https://erp.isid.co.jp/solution/sap-bi-businessspectre/ ）に掲載されていますので興味のある方は是非！ 2.　就活生の皆さんが気になるであろう質問に淡々と答えます Q1. どんなお仕事？ A1. ISIDの自社開発製品「BusinessSPECTRE」、「VisAP」の提案や導入活動をしています。ドイツ製の基幹システム「SAP」を導入しているお客様をターゲットに、日々の業務データを蓄積→分析→可視化するようなシステムを提案しています。 Q2. どんな職場環境？ A2. 上司や先輩とは、よくコミュニケーションを取ります。最近ではテレワークのため、社内打合せやチャットでのやり取りが主流ですが、仕事のことはもちろんプライベートなことでも気兼ねなく話できるメンバーばかりの環境だなと感じています。同期ともたまに連絡を取り合います。同期は宝物です。 Q3. 教育制度は？ A3. 入社後は新人教育のカリキュラムが組まれているため、それに則って教育を受けることができます。ITに関する研修や、社会人としてのマナー研修など内容は様々で、どれもISIDで働いていく上で必要な知識です。配属後は社内研修制度を通じて専門分野について知識習得する機会があります。半年に一度申し込むことができ、実務をこなしながら自身の スキルアップ を図ることもできるので、有効活用しています！ Q4. 働いていてやりがいを感じるときは？ A4. 一番はお客様から感謝されるときや案件が無事完了したときですが、年次が上がると責任感も増しますし、上司や先輩からの期待も大きくなります。そういった期待に応えられたときや、励ましの言葉をもらったときにやりがいを感じることが多いです。 Q5. 入社前にすべきことはありますか？ A5. 働く上で必要なことは入社してから学べるので、特にやっておくべきことはないです。逆に働いてから長期休暇を取りづらくなる（休暇は取れるけど色々調整するのが面倒）ので、海外旅行に行くとか、日ごろすぐにはできないことにチャレンジすることをオススメします！ Q6. テレワークでの難しさは？ A6. 出社時に比べて社内メンバーやお客様との雑談が極端に減ったように感じます。対面時は気にすることなくできていた雑談も、Web会議越しでは表情が見えないことで雑談しづらい気持ちになるのが正直なところです。お客様とのコミュニケーションでは雑談って結構大事なので、そのあたりのバランスが難しいですね。 Q7. ISIDに入って良かったことは？悪かったことは？ A7. 良かったことは、何よりISIDの「人柄」です。本当にみんなユーモアがあって、やさしさがあって、それでいて頭が切れて面白くて！！仕事だけではなく、プライベートでも一緒に過ごしたいと思えるメンバーばかりです。悪かったことは1つもありません（本当ですよ？笑） Q8. ISIDに入社する人の共通点は？ A8. あくまで個人的な意見ですが、、、 自分を持っていて、自分らしさを相手に伝えることができる 色んなことに興味を持っている すぐにチャレンジしたがる Q9. どんな後輩が欲しいですか？ A9. 何事にもチャレンジしてくれる、手を挙げてくれる後輩は大歓迎です。何事もやってみないとわからない、と思うので、常に前向きにトライしてくれる後輩が入ってきてくれることを願っています！ Q10 . 1日の流れは？ Q10 . こんな感じです。 3.　最後に ISIDで一緒に働きましょう！私の所属する部は、新卒入社と中途入社の社員が半々くらいです。 男女比は男：女＝8：2くらいでしょうか。 本記事でご紹介した内容や働きについて、また基幹システム周辺分野のシステム導入業務にご興味をお持ちの方は、ぜひ採用ページよりご応募ください！ 私たちは一緒に働いてくれる仲間を募集しています！ ISID 募集職種一覧 執筆： @ikeuchi.keisuke 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

皆さんこんにちは！ISID新卒入社7年目の池内です。現在はEIT事業部（ エンタープライズ IT事業部）に所属しており、ISIDの自社開発製品である「BusinessSPECTRE」（ビジネ ススペ クトル）、「VisAP」（ヴィスエーピー）の提案、導入を担当しています。 このブログを通じ、私の仕事内容や1日の流れ、またISIDに少しでも興味を持ってもらえる就活生にとって役立つ情報を発信できればと思っています！ 1.　自己紹介 それでは早速、簡単に自己紹介させてください。 大学、大学院を卒業し、2017年に新入社員としてISIDへ入社しました。大学在学中は、特に情報系（プログラムとか）の授業をなるべく避けてきましたので、IT リテラシー はほぼ0。大学、大学院では 統計学 を専攻していました。 当時、製薬会社のデータサイエンティストを志望し、就活に励んでいましたが、残念ながらどの会社からも最終面接へのチケットをもらえず。やっぱり薬学部に進学しないとだめなのかな～とか、自分って将来どこで何して働くんだろう～とか、色々考えながら日々を過ごしていたところ、ISIDに出会うことができ入社することを決めました。 入社後の配属先としては、主に顧客の基幹システム（会計、販売、在庫など、顧客の心臓となるシステム）周りのお仕事をしている部署に配属されることになりました。 年度ごとに組織変更があり、部署名が変わってばかりですが、仕事内容は変わらず基幹システムの周辺領域（BIやDWHとも呼ばれる）のソリューションを提案したり導入したりしています。 ※ISIDの自社開発製品「BusinessSPECTRE」（ビジネ ススペ クトル）、「VisAP」（ヴィスエーピー）については、こちらのサイト（ https://erp.isid.co.jp/solution/sap-bi-businessspectre/ ）に掲載されていますので興味のある方は是非！ 2.　就活生の皆さんが気になるであろう質問に淡々と答えます Q1. どんなお仕事？ A1. ISIDの自社開発製品「BusinessSPECTRE」、「VisAP」の提案や導入活動をしています。ドイツ製の基幹システム「SAP」を導入しているお客様をターゲットに、日々の業務データを蓄積→分析→可視化するようなシステムを提案しています。 Q2. どんな職場環境？ A2. 上司や先輩とは、よくコミュニケーションを取ります。最近ではテレワークのため、社内打合せやチャットでのやり取りが主流ですが、仕事のことはもちろんプライベートなことでも気兼ねなく話できるメンバーばかりの環境だなと感じています。同期ともたまに連絡を取り合います。同期は宝物です。 Q3. 教育制度は？ A3. 入社後は新人教育のカリキュラムが組まれているため、それに則って教育を受けることができます。ITに関する研修や、社会人としてのマナー研修など内容は様々で、どれもISIDで働いていく上で必要な知識です。配属後は社内研修制度を通じて専門分野について知識習得する機会があります。半年に一度申し込むことができ、実務をこなしながら自身の スキルアップ を図ることもできるので、有効活用しています！ Q4. 働いていてやりがいを感じるときは？ A4. 一番はお客様から感謝されるときや案件が無事完了したときですが、年次が上がると責任感も増しますし、上司や先輩からの期待も大きくなります。そういった期待に応えられたときや、励ましの言葉をもらったときにやりがいを感じることが多いです。 Q5. 入社前にすべきことはありますか？ A5. 働く上で必要なことは入社してから学べるので、特にやっておくべきことはないです。逆に働いてから長期休暇を取りづらくなる（休暇は取れるけど色々調整するのが面倒）ので、海外旅行に行くとか、日ごろすぐにはできないことにチャレンジすることをオススメします！ Q6. テレワークでの難しさは？ A6. 出社時に比べて社内メンバーやお客様との雑談が極端に減ったように感じます。対面時は気にすることなくできていた雑談も、Web会議越しでは表情が見えないことで雑談しづらい気持ちになるのが正直なところです。お客様とのコミュニケーションでは雑談って結構大事なので、そのあたりのバランスが難しいですね。 Q7. ISIDに入って良かったことは？悪かったことは？ A7. 良かったことは、何よりISIDの「人柄」です。本当にみんなユーモアがあって、やさしさがあって、それでいて頭が切れて面白くて！！仕事だけではなく、プライベートでも一緒に過ごしたいと思えるメンバーばかりです。悪かったことは1つもありません（本当ですよ？笑） Q8. ISIDに入社する人の共通点は？ A8. あくまで個人的な意見ですが、、、 自分を持っていて、自分らしさを相手に伝えることができる 色んなことに興味を持っている すぐにチャレンジしたがる Q9. どんな後輩が欲しいですか？ A9. 何事にもチャレンジしてくれる、手を挙げてくれる後輩は大歓迎です。何事もやってみないとわからない、と思うので、常に前向きにトライしてくれる後輩が入ってきてくれることを願っています！ Q10 . 1日の流れは？ Q10 . こんな感じです。 3.　最後に ISIDで一緒に働きましょう！私の所属する部は、新卒入社と中途入社の社員が半々くらいです。 男女比は男：女＝8：2くらいでしょうか。 本記事でご紹介した内容や働きについて、また基幹システム周辺分野のシステム導入業務にご興味をお持ちの方は、ぜひ採用ページよりご応募ください！ 私たちは一緒に働いてくれる仲間を募集しています！ ISID 募集職種一覧 執筆： @ikeuchi.keisuke 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS Security Hubの コントロール には、「変更によってトリガーされるチェック」と「定期的なチェック」があります。 それぞれのチェックスケジュールについては こちら に記載があり、「定期的なチェック」は次のように書かれています。 定期的なチェックは、最後の実行から 12 時間または 24 時間以内に自動的に実行されます。周期は Security Hub によって決定され、変更はできません。定期的なコン トロール は、実行時の評価をキャプチャします。 すなわち、リソース作成・変更後にすぐにチェックが行われない場合があり、最大で24時間待たなければなりません。コン トロール の動きを調査をするときなどに不便だと感じていましたが、「定期的なチェック」に対してもすぐに実行する方法を見つけたのでご紹介します。 定期的なチェックをすぐに実行する方法 1. コントロールに対応する Config ルールを特定する 2. AWS Config コンソールでルールを見つける 3. 「アクション」>「再評価」を実行する コマンドラインでチェックをすぐに実行する方法 定期的なチェックをすぐに実行する方法 1. コン トロール に対応する Config ルールを特定する Security Hubのセキュリティチェックは AWS Config ルールを利用しており、ドキュメントにはそれぞれのコン トロール が利用している Config ルールが記載されています。 まずは AWS の公式ドキュメントから、すぐにチェックを実行したいコン トロール の Config ルールを特定しましょう。 https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html 2. AWS Config コンソールでルールを見つける AWS Configのコンソールにて、該当するルールを見つけます。ルールによっては名前が少し異なる場合があるようです。 3. 「アクション」>「再評価」を実行する ルール右上の「アクション」>「再評価」をクリックすると、すぐにチェックを再実行してくれます。 しばらくしてリロードすると、最後に評価した日時とルールに非準拠なリソースが更新されました。 Security Hubのコンソールでも、すぐにチェックの結果が反映されていました。 コマンドライン でチェックをすぐに実行する方法 ルール名を特定した後の「再評価」操作は、 コマンドライン の start-config-rules-evaluation コマンド で実行することもできます。 aws configservice start-config-rules-evaluation --config-rule-name <ルール名> 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア(セキュリティ設計) 執筆： @kou.kinyo 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS Security Hubの コントロール には、「変更によってトリガーされるチェック」と「定期的なチェック」があります。 それぞれのチェックスケジュールについては こちら に記載があり、「定期的なチェック」は次のように書かれています。 定期的なチェックは、最後の実行から 12 時間または 24 時間以内に自動的に実行されます。周期は Security Hub によって決定され、変更はできません。定期的なコン トロール は、実行時の評価をキャプチャします。 すなわち、リソース作成・変更後にすぐにチェックが行われない場合があり、最大で24時間待たなければなりません。コン トロール の動きを調査をするときなどに不便だと感じていましたが、「定期的なチェック」に対してもすぐに実行する方法を見つけたのでご紹介します。 定期的なチェックをすぐに実行する方法 1. コントロールに対応する Config ルールを特定する 2. AWS Config コンソールでルールを見つける 3. 「アクション」>「再評価」を実行する コマンドラインでチェックをすぐに実行する方法 定期的なチェックをすぐに実行する方法 1. コン トロール に対応する Config ルールを特定する Security Hubのセキュリティチェックは AWS Config ルールを利用しており、ドキュメントにはそれぞれのコン トロール が利用している Config ルールが記載されています。 まずは AWS の公式ドキュメントから、すぐにチェックを実行したいコン トロール の Config ルールを特定しましょう。 https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html 2. AWS Config コンソールでルールを見つける AWS Configのコンソールにて、該当するルールを見つけます。ルールによっては名前が少し異なる場合があるようです。 3. 「アクション」>「再評価」を実行する ルール右上の「アクション」>「再評価」をクリックすると、すぐにチェックを再実行してくれます。 しばらくしてリロードすると、最後に評価した日時とルールに非準拠なリソースが更新されました。 Security Hubのコンソールでも、すぐにチェックの結果が反映されていました。 コマンドライン でチェックをすぐに実行する方法 ルール名を特定した後の「再評価」操作は、 コマンドライン の start-config-rules-evaluation コマンド で実行することもできます。 aws configservice start-config-rules-evaluation --config-rule-name <ルール名> 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア(セキュリティ設計) 執筆： @kou.kinyo 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 IAM の Permissions Boundary（アクセス許可境界） についてやもやしていました。効果はわかるものの、どうして IAM ポリシーだけではダメで Permissions Boundary が必要なのかよくわかりませんでした。この記事では IAM のポリシードキュメントと API の仕様から、 Permissions Boundary が導入された本質的な理由を考えてみます。 結論から先に述べると、Permissions Boundary を使うことで特定の権限を超えて IAM ユーザー/ロールが作成されるのを防ぐ効果があり、これは IAM ポリシーだけでは実現できません。Permissions Boundary は、特定のユーザーが IAM ユーザー/ロールを作成するのを許可しつつ、権限昇格を防止する目的などに使用できます。 権限昇格の例 Permissions Boundary とは 権限昇格を防ぐ例 本質1: IAM ポリシードキュメントに iam:PermissionsBoundary 条件キーが使える 本質2: Permissions Boundary は CreateUser / CreateRole 時に追加できる さいごに 権限昇格の例 まずは IAM の権限昇格を簡単な例で見てみます。 以下の IAM ポリシーを持つ IAM ユーザーがあるとします。 iam:CreateRole （IAM ロールを作成する権限） と iam:PutRolePolicy （IAM ロールにインラインポリシーを追加する権限）、さらには sts:AssumeRole が許可されています。他の権限については省略します。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": [ " iam:CreateRole ", " iam:PutRolePolicy " ] , " Resource ": " * " } , { " Effect ": " Allow ", " Action ": [ " sts:AssumeRole " ] , " Resource ": " * " } ] } iam:CreateRole が許可されているので、以下の信頼ポリシーを持つ IAM ロールを作ることができます。（同じアカウント内の プリンシパル であれば、 AssumeRole を許可） { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " AWS ": " arn:aws:iam::000000000000:root " } , " Action ": " sts:AssumeRole " } ] } 先の IAM ユーザーは iam:PutRolePolicy が許可されているので、作ったロールに任意のインラインポリシーを追加できます。例えば以下のような全てを許可するポリシーをエラーなく追加できます。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": " * ", " Resource ": " * " } ] } 先の IAM ユーザーは sts:AssumeRole が許可されているので、作ったロールを AssumeRole し、アクセスキーID、シークレットアクセスキー、セッション トーク ンを獲得することで、全ての操作が許可される権限を手に入れることができます。元のユーザーにはできなかった操作ができるようになるので、権限昇格されています。 （以上の例は「IAM ユーザー」が「IAM ロールを経由して」権限昇格する例でしたが、権限昇格する主体が「IAM ロール」の場合や、「IAM ユーザーを経由して」権限昇格する場合もあります。） Permissions Boundary とは Permissions Boundary の実態は IAM 管理ポリシーです。他の IAM 管理ポリシーと同じように作成します。 一つの IAM ユーザー/ロールには最大で1つの IAM 管理ポリシーを、 Permissions Boundary として追加できます。また、Permissions Boundary にインラインポリシーを指定することはできません。 IAM ユーザー/ロールに Permissions Boundary が追加されている場合、そのユーザー/ロールに許可される権限は「 アイデンティティ ベースのポリシー」と「Permissions Boundary」の AND 条件になります。Permissions Boundary で明示的に許可されていない権限は、 アイデンティティ ベースのポリシーで許可されていても最終的にユーザー/ロールには許可されません。 （ https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html より） 権限昇格を防ぐ例 Permissions Boundary を使うことで、どのように権限昇格を防ぐことができるのか見てみます。 以下の IAM 管理ポリシーを my-permissions-boundary という名前で作成します。 iam:CreateRole iam:PutRolePolicy sts:AssumeRole の3つの権限しか許可していません。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": [ " iam:CreateRole ", " iam:PutRolePolicy ", " sts:AssumeRole " ] , " Resource ": " * " } ] } 対象の IAM ユーザーに作成した my-permissions-boundary を Permissions Boundary として追加します。 対象の IAM ユーザーのポリシーを以下のように変更します。 Condition 句を追加し、Permissions Boundary として my-permissions-boudary が指定された場合のみ iam:CreateRole iam:PutRolePolicy できるようにしています。（この例では自身のポリシーを変更する権限を持っていないこともポイントです。） { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": [ " iam:CreateRole ", " iam:PutRolePolicy " ] , " Resource ": " * ", " Condition ": { " StringEquals ": { " iam:PermissionsBoundary ": " arn:aws:iam::000000000000:policy/my-permissions-boudary " } } } , { " Effect ": " Allow ", " Action ": [ " sts:AssumeRole " ] , " Resource ": " * " } ] } 以上が準備段階で、この状態で IAM ロールを経由して権限昇格を試みても次のような結果になります。 my-permissions-boudary を付与しないと、IAM ロールを作ることに失敗します。 my-permissions-boudary を付与すれば、IAM ロールを作成できます。 Admin 権限相当のインラインポリシーを作成した IAM ロールにつけ、AssumeRole をすることはできますが、Permissions Boundary で明示的に許可された以上の権限を持ちません。 以上はよくある Permissions Boundary の説明でした。このように権限昇格の防止を実現できるのは、2つの仕様上の本質があるためだと考えています。 本質1: IAM ポリシードキュメントに iam:PermissionsBoundary 条件キーが使える 権限昇格を防ぎたい IAM ユーザー/ロールのポリシーに iam:PermissionsBoundary 条件キーが使える のが第一のポイントです。これによって、Permissions Boundary に特定のポリシーが存在する場合に限って特定の操作を許す、といった書き方ができるようになりました。 " Condition ": { " StringEquals ": { " iam:PermissionsBoundary ": " arn:aws:iam::000000000000:policy/my-permissions-boudary " } } 本質2: Permissions Boundary は CreateUser / CreateRole 時に追加できる こちらはより重要です。 CreateUser と CreateRole の API 仕様を確認すると、これらの API を呼びだす時のパラメータで Permissions Boundary を追加できることがわかります。 一方で、通常のポリシーについては CreateUser と CreateRole の呼び出し時に追加することはできず、後から AttachUserPolicy 、 PutUserPolicy 、 AttachRolePolicy 、 PutRolePolicy など別 API で付与しなければなりません。すなわち、 IAM ユーザー/ロールを作成した瞬間にはポリシーが何もついていない状態にどうしてもなってしまい 、最初から特定の IAM ポリシーを持つように制限できません。Permissions Boundary であれば作成と同時に付与できるので、 iam:PermissionsBoundary 条件キーと併用することで特定の Permissions Boundary を持つ場合に限って ユーザー/ロールの作成を許可する、といった書き方ができます。 推測ですが、作成時からポリシーを付与できるように従来の CreateUser / CreateRole の API 仕様を変更するよりも、新しく Permissions Boundary という機能を追加した方が望ましいと判断したのではないかと思います。 さいごに 理解していても IAM の権限は複雑で、Permissions Boundary を使いこなすのは慎重な設定が必要な印象です。 公式ドキュメントの例 にも目を通すと、さらに理解の助けになるのではないかと思います。 お読みいただいてありがとうございました。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア(セキュリティ設計) 執筆： @kou.kinyo 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）