こんにちは！コミュニケーション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 で執筆されました ）

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