みなさんこんにちは、X（クロス） イノベーション 本部　ソフトウェアデザインセンターの鈴木です。 この度「 AWS Certified Solutions Architect – Professional（以降、SAP-C02）」に合格しました。 この記事では学習した内容や、合格のために必要だと感じたことについてまとめたいと思います。 後半には、若手（社会人歴3年目）の私が、SAP-C02を受検して良かったと感じたことも記載します。 読んでいただいた方の受検の参考に、そして学習へのモチベーションにつながれば幸いです。 筆者について SAP-C02とは？ SAP-C02合格までの道のり 学習時間と学習したコンテンツ 書籍 ①AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル ②AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 udemy ③Practice Exam AWS Certified Solutions Architect Professional ④【01版】AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集（全5回分375問） 2回の受検を通して 解けなかった問題や苦手に感じた分野の復習 時間を意識して問題を解き、試験に慣れる 受検してよかったこと AWSサービスを広く学ぶことができた セキュリティやネットワーク、コンテナ技術など基本的なIT技術の知識を得ることができた まとめ 筆者について 新卒3年目 業務での AWS 経験は8ヶ月目（以前はフロントアプリケーション開発に携わっていました） 現在の業務は、 AWS をインフラ基盤とした社内アプリケーションを、フロントエンド・バックエンド・インフラと全体的に開発しています。 SAP-C02とは？ SAP-C02の概要は以下のとおりです。詳しくは 公式サイト をご覧ください。 Amazon Web Services （ AWS ）の認定資格プログラムの中で、高度な アーキテクチャ スキルと クラウドコンピューティング の専門知識を持つプロフェッショナル向けの資格 問題は75問（択一または多肢選択式）、試験時間は180分 1000点満点で750点が合格ライン SAP-C02合格までの道のり SAP-C02を受検するまでに、 AWS 系の資格は以下の2つを取得しました。 特にアソシエイト資格のSAA-C03は、SAP-C02を受検するにあたりベースとなる知識が求められるため、先に受検しておくことをオススメします。 AWS Certified Cloud Practitioner (CLF-C01) AWS Certified Solutions Architect – Associate (SAA-C03) 本題のSAP-C02は、1回目の受検は704点で不合格、2回目の受検で合格することができました。 1回目の受検から2回目の受検までに行ったことは、「2回の受検を通して」セクションに記載します。 学習時間と学習したコンテンツ 学習時間は、だいたい100 ~ 150時間（2時間×週4~5日×3ヶ月）くらいかかりました。 以下、学習に使用した教材を紹介します。 上からオススメの順に並んでいますので、ご参考にしてみてください。 書籍 ① AWS 認定資格試験テキスト&問題集 AWS 認定ソリューションアーキテクト - プロフェッショナル ⭕️出題範囲を広くカバーしており、よく出題される分野をイラストを交えてまとめてある参考書です。 学習のとっかかりとしてオススメです。 🔺本番レベルの問題数が十分ではないため、他の教材で補う必要があります。 ② AWS 認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 ⭕️ ①と比較して、問題の量とその解説が充実しています。 ⭕️ 巻末に付録してある模擬試験は本番レベルで、解説も丁寧です。正解の選択肢だけでなく、不正解の選択肢がなぜダメなのかについてもわかりやすく解説されているため、とても役に立ちました。 🔺出題範囲が旧試験（SAP-C01）を想定しており、新試験（SAP-C02）のカバーされていない範囲は他の問題集で補う必要があります。 udemy ③Practice Exam AWS Certified Solutions Architect Professional 英語の問題集で、2.5回分の演習問題が収録されています。多少読み取りにくくはありますが、 Google翻訳 を使用することで英語が得意でない私でも学習できました。翻訳が怪しいところは英文に戻して読み進めていました。 ⭕️内容としては、実際の試験に出題される問題に近い内容の問題が多く収録されている印象です。また解説欄には、問題に関連する AWS 公式ドキュメントのリンクが掲載されており、わからないところはすぐに公式ドキュメントで調べられてとても良かったです。 ⭕️新試験（SAP-C02）に対応しており、本番に近い内容の問題が多い印象で、英語の問題集ということを差し引いてもオススメできる問題集だと思いました。 ④【01版】 AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集（全5回分375問） ⭕️ 私が試験対策をしていた際、udemyで日本語の問題集はこれ一択でした。5回分の演習問題が収録されており、問題量としては申し分ないでしょう。 5回分の演習問題が収録されているため、試験を想定して時間を意識して解く練習をするのがオススメです。 🔺出題範囲が旧試験（SAP-C01）を想定しており、新試験（SAP-C02）のカバーされていない範囲については他の問題集で補う必要があります。 上記を学習する上で不明点が生じた場合は、まず AWS 公式ドキュメントを調べました。 AWS 公式ドキュメントはとても充実しており、調べたい内容はほとんど文書化されていた印象です。 （公式ドキュメントの情報をもとに問題を作成しているからかもしれませんが） 2回の受検を通して 「SAP-C02合格までの道のり」で記載した通り、2回目の受検で合格しました。1回目の受検から2回目の受検までにしたことは以下のとおりです。 解けなかった問題や苦手に感じた分野の復習 1回目の試験で解けなかった問題や苦手に感じた分野を当日中にメモしておき、集中的に復習しました。"絶対に合格した"という確証がない限り、受検直後にメモしておいた方が賢明です。 時間を意識して問題を解き、試験に慣れる SAP-C02は試験時間が3時間ありますが、各問題の文章量がとても多いため時間に余裕はありません。 （私は見直す時間が全く取れませんでした） そのため「学習時間と学習したコンテンツ」で紹介した③のUdemy教材を新たに学習し、試験のペースを掴むことと長文から顧客要求を素早く理解することを練習しました。 受検してよかったこと 最後に、SAP-C02を受検して良かったことは以下の2点です。 AWS サービスを広く学ぶことができた 本試験は対象サービスの幅が広く、どのようにサービスを組み合わせて顧客要求を達成できるかを問われるため、各サービスへの知識と理解が深まりました。 そのおかげで、学習する前に比べてサービス構成図を見た際にどのようなサービスであるかや、サービス構成上のどこに問題があるかが以前よりわかるようになった気がします。 実際に アーキテクチャ 設計をしないまでも、レビューなどで大いに役立つ知識がつけられたのではないかと思います。 セキュリティやネットワーク、コンテナ技術など基本的な IT技術 の知識を得ることができた 若手ということもあり、セキュリティやネットワーク、コンテナ技術など基本的な IT技術 の知識が乏しかったためとても苦戦しました。しかし、SAP-C02の学習を進めていくうちに副次的に幅広く知識をつけることができました。 （アソシエイト資格と比べると、この辺りの知識がないと解けない問題はたくさんあります） 自分の IT技術 に関する知識の無さに悲しくなることもありましたが、若手の人にこそIT知識の幅を広げるという意味でも本資格に挑戦してみる価値はあると思います。 まとめ 今回は合格体験記と題して、学習した内容や学習して良かったことを紹介いたしました。 学習は大変でしたが、 AWS サービスをより深く学ぶことができ、 IT技術 の知見を広げることができました。 読んでいただいた皆さんの参考に少しでもなれれば幸いです。 最後までお読みいただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ フルサイクルエンジニア 執筆： @suzuki.takuma 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

みなさんこんにちは、X（クロス） イノベーション 本部　ソフトウェアデザインセンターの鈴木です。 この度「 AWS Certified Solutions Architect – Professional（以降、SAP-C02）」に合格しました。 この記事では学習した内容や、合格のために必要だと感じたことについてまとめたいと思います。 後半には、若手（社会人歴3年目）の私が、SAP-C02を受検して良かったと感じたことも記載します。 読んでいただいた方の受検の参考に、そして学習へのモチベーションにつながれば幸いです。 筆者について SAP-C02とは？ SAP-C02合格までの道のり 学習時間と学習したコンテンツ 書籍 ①AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル ②AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 udemy ③Practice Exam AWS Certified Solutions Architect Professional ④【01版】AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集（全5回分375問） 2回の受検を通して 解けなかった問題や苦手に感じた分野の復習 時間を意識して問題を解き、試験に慣れる 受検してよかったこと AWSサービスを広く学ぶことができた セキュリティやネットワーク、コンテナ技術など基本的なIT技術の知識を得ることができた まとめ 筆者について 新卒3年目 業務での AWS 経験は8ヶ月目（以前はフロントアプリケーション開発に携わっていました） 現在の業務は、 AWS をインフラ基盤とした社内アプリケーションを、フロントエンド・バックエンド・インフラと全体的に開発しています。 SAP-C02とは？ SAP-C02の概要は以下のとおりです。詳しくは 公式サイト をご覧ください。 Amazon Web Services （ AWS ）の認定資格プログラムの中で、高度な アーキテクチャ スキルと クラウドコンピューティング の専門知識を持つプロフェッショナル向けの資格 問題は75問（択一または多肢選択式）、試験時間は180分 1000点満点で750点が合格ライン SAP-C02合格までの道のり SAP-C02を受検するまでに、 AWS 系の資格は以下の2つを取得しました。 特にアソシエイト資格のSAA-C03は、SAP-C02を受検するにあたりベースとなる知識が求められるため、先に受検しておくことをオススメします。 AWS Certified Cloud Practitioner (CLF-C01) AWS Certified Solutions Architect – Associate (SAA-C03) 本題のSAP-C02は、1回目の受検は704点で不合格、2回目の受検で合格することができました。 1回目の受検から2回目の受検までに行ったことは、「2回の受検を通して」セクションに記載します。 学習時間と学習したコンテンツ 学習時間は、だいたい100 ~ 150時間（2時間×週4~5日×3ヶ月）くらいかかりました。 以下、学習に使用した教材を紹介します。 上からオススメの順に並んでいますので、ご参考にしてみてください。 書籍 ① AWS 認定資格試験テキスト&問題集 AWS 認定ソリューションアーキテクト - プロフェッショナル ⭕️出題範囲を広くカバーしており、よく出題される分野をイラストを交えてまとめてある参考書です。 学習のとっかかりとしてオススメです。 🔺本番レベルの問題数が十分ではないため、他の教材で補う必要があります。 ② AWS 認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 ⭕️ ①と比較して、問題の量とその解説が充実しています。 ⭕️ 巻末に付録してある模擬試験は本番レベルで、解説も丁寧です。正解の選択肢だけでなく、不正解の選択肢がなぜダメなのかについてもわかりやすく解説されているため、とても役に立ちました。 🔺出題範囲が旧試験（SAP-C01）を想定しており、新試験（SAP-C02）のカバーされていない範囲は他の問題集で補う必要があります。 udemy ③Practice Exam AWS Certified Solutions Architect Professional 英語の問題集で、2.5回分の演習問題が収録されています。多少読み取りにくくはありますが、 Google翻訳 を使用することで英語が得意でない私でも学習できました。翻訳が怪しいところは英文に戻して読み進めていました。 ⭕️内容としては、実際の試験に出題される問題に近い内容の問題が多く収録されている印象です。また解説欄には、問題に関連する AWS 公式ドキュメントのリンクが掲載されており、わからないところはすぐに公式ドキュメントで調べられてとても良かったです。 ⭕️新試験（SAP-C02）に対応しており、本番に近い内容の問題が多い印象で、英語の問題集ということを差し引いてもオススメできる問題集だと思いました。 ④【01版】 AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集（全5回分375問） ⭕️ 私が試験対策をしていた際、udemyで日本語の問題集はこれ一択でした。5回分の演習問題が収録されており、問題量としては申し分ないでしょう。 5回分の演習問題が収録されているため、試験を想定して時間を意識して解く練習をするのがオススメです。 🔺出題範囲が旧試験（SAP-C01）を想定しており、新試験（SAP-C02）のカバーされていない範囲については他の問題集で補う必要があります。 上記を学習する上で不明点が生じた場合は、まず AWS 公式ドキュメントを調べました。 AWS 公式ドキュメントはとても充実しており、調べたい内容はほとんど文書化されていた印象です。 （公式ドキュメントの情報をもとに問題を作成しているからかもしれませんが） 2回の受検を通して 「SAP-C02合格までの道のり」で記載した通り、2回目の受検で合格しました。1回目の受検から2回目の受検までにしたことは以下のとおりです。 解けなかった問題や苦手に感じた分野の復習 1回目の試験で解けなかった問題や苦手に感じた分野を当日中にメモしておき、集中的に復習しました。"絶対に合格した"という確証がない限り、受検直後にメモしておいた方が賢明です。 時間を意識して問題を解き、試験に慣れる SAP-C02は試験時間が3時間ありますが、各問題の文章量がとても多いため時間に余裕はありません。 （私は見直す時間が全く取れませんでした） そのため「学習時間と学習したコンテンツ」で紹介した③のUdemy教材を新たに学習し、試験のペースを掴むことと長文から顧客要求を素早く理解することを練習しました。 受検してよかったこと 最後に、SAP-C02を受検して良かったことは以下の2点です。 AWS サービスを広く学ぶことができた 本試験は対象サービスの幅が広く、どのようにサービスを組み合わせて顧客要求を達成できるかを問われるため、各サービスへの知識と理解が深まりました。 そのおかげで、学習する前に比べてサービス構成図を見た際にどのようなサービスであるかや、サービス構成上のどこに問題があるかが以前よりわかるようになった気がします。 実際に アーキテクチャ 設計をしないまでも、レビューなどで大いに役立つ知識がつけられたのではないかと思います。 セキュリティやネットワーク、コンテナ技術など基本的な IT技術 の知識を得ることができた 若手ということもあり、セキュリティやネットワーク、コンテナ技術など基本的な IT技術 の知識が乏しかったためとても苦戦しました。しかし、SAP-C02の学習を進めていくうちに副次的に幅広く知識をつけることができました。 （アソシエイト資格と比べると、この辺りの知識がないと解けない問題はたくさんあります） 自分の IT技術 に関する知識の無さに悲しくなることもありましたが、若手の人にこそIT知識の幅を広げるという意味でも本資格に挑戦してみる価値はあると思います。 まとめ 今回は合格体験記と題して、学習した内容や学習して良かったことを紹介いたしました。 学習は大変でしたが、 AWS サービスをより深く学ぶことができ、 IT技術 の知見を広げることができました。 読んでいただいた皆さんの参考に少しでもなれれば幸いです。 最後までお読みいただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ フルサイクルエンジニア 執筆： @suzuki.takuma 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

みなさんこんにちは、 電通国際情報サービス （ISID）X イノベーション 本部ソフトウェアデザインセンターの佐藤太一です。 皆さんは最近発売された 『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』 はもう読みましたか？ この本は Erlang やElixirを使ってプロパティベーステストというテスト手法について具体的なコードを使って実践的に学習できる本です。非常に素晴らしい本ですが、難しい部分も多いため私は少しずつ読んでいる所です。 この記事では、この本を読むにあたってサンプルコードを動かすための環境を使っているOSに依存せずに作成する方法を説明します。 事前の準備 最小限のDev Container devcontainer.jsonを編集する環境の構築 Erlang用VS Code拡張 テスト用プロファイルで使うライブラリをエディタに認識させる まとめ この記事で紹介している開発環境の構成ファイル .devcontainer/devcontainer.json 事前の準備 この記事が前提とする環境について軽く説明します。 まず、  VS Code  を事前にインストールしておいてください。 次に、 Docker Desktop をインストールして動作する状態にしてください。基本的には単に インストーラ を実行すれば動作する状態になります。 そして、 VS Code に  Dev Containers 拡張をインストールしておいてください。 最後に、作業用のプロジェクト ディレクト リを作成してください。ここでは、pbt という ディレクト リを作成してプロジェクトのルート ディレクト リとしています。 最小限のDev Container まずは、Dev Containerを使って Erlang が提供する公式のDockerイメージを使った開発環境を作成してみましょう。 プロジェクトのルート ディレクト リに、  .devcontainer  という ディレクト リを作って、その中に  devcontainer.json  というファイル名で以下の内容を保存します。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " containerEnv ": { " TZ ": " Asia/Tokyo " } , " runArgs ": [ " --init " ] } name の値は、分かりやすい名前なら何でもいいです。ここでは、devcontainer- erlang としています。 image の値は、 erlang :slim としています。これは公式のイメージ名です。 ベースイメージや Erlang ランタイムのバージョンを別なものにしたい場合には、 https://hub.docker.com/_/erlang から探してください。 containerEnv の値は、コンテナ内で参照される 環境変数 です。ここでは タイムゾーン が  Asia/Tokyo になるよう設定しています。時刻に起因する問題の調査は難しいので、ここで明示的に設定しています。 runArgs の値は、  --init  を渡すことでDockerが  /dev/init  というシグナルハンドリング用のプロセスを起動してくれます。これによってコンテナを安定的にシャットダウンできます。 devcontainer. json を編集する環境の構築 ここから、devcontainer. json を編集しながら開発環境を構築していくので、まずは快適に json ファイルを編集できるようにしましょう。 devcontainer. json には、Dev Containerとして起動した VS Code を構成するための設定項目がありますので、それらを編集します。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " esbenp.prettier-vscode " ] } } } customizations  というキーがDev Containerの構成を行うための設定項目です。この中に vscode  という項目がありますね。 settings の中では、 VS Code の設定項目を管理します。 editor.renderWhitespace  の値として、  all  を設定しているのは、ファイルの中に紛れ込んだ全角スペースを見つけやすくするためです。私たちが IME を使っている以上、意図しない場所に全角スペースが入り込んでしまい、それによって理解が困難なエラーメッセージを読むことになるのは避けられません。全角スペースが見えていれば、そういったドハマりから抜け出しやすくなります。 [json][jsonc]  の値として、いくつか設定しています。ちなみに、jsoncは、 JSON  with commentsの略称です。 editor.defaultFormatter  の値として、esbenp.prettier- vscode  を設定しています。これによってprettierを使ったフォーマットが行われます。 editor.formatOnSave  の値として、trueを設定することでファイル保存時にフォーマットが行われるようにしています。 editor.codeActionsOnSave  の値として、source.fixAll を有効化することで自動的に補正できるフォーマットエラーをprettierが積極的に補正してくれます。 extensions の中では、Dev Containerとして起動された VS Code にインストールされる VS Code 拡張を列挙します。ここでは、 JSON を自動フォーマットするための  esbenp.prettier-vscode  を設定しています。 Erlang 用 VS Code 拡張 次は、 Erlang 用の VS Code 拡張を追加します。 マーケットプレイス を確認するといくつかの拡張がありますが、一番利用者の多いものを今回は使います。 erlang devcontainer. json のextensionsに拡張を追加すると、以下のようになります。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " erlang.formattingLineLength ": 200 , " [erlang] ": { " editor.defaultFormatter ": " pgourlain.erlang ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } , " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " pgourlain.erlang ", " esbenp.prettier-vscode " ] } } } erlang.formattingLineLength の値として、200を設定しています。この設定項目はドキュメントには記載がないので、私の設定値をここに書いています。 [erlang] の値として、いくつか設定しています。何をしているかは [json][jsonc]  の時と同じです。 これで Erlang のアプリケーション開発環境は完成です。しかし、本を読み進めていくと早々に問題にぶつかります。 テスト用プロファイルで使うライブラリをエディタに認識させる 書籍では、PropErというライブラリをrebarというビルドツールに構成するように指示されます。 その結果、rebar.configを以下のように構成します。 { project_plugins , [ rebar3_proper ]} . { profiles , [ { test , [ { erl_opts , [ nowarn_export_all ]} , { deps , [ proper ]} ]} ]} . { erl_opts , [ debug_info ]} . { deps , []} . rebar3では、依存ライブラリをプロファイル毎に管理できるようになっています。 そして、 proper は test プロファイルでのみ参照されます。 ダウンロードされた依存ライブラリは、プロジェクトのルート ディレクト リにある _build ディレクト リ以下に格納されています。 この状態だと、rebarによるビルドは成功するのですが、エディタ上で can't find include lib "proper/include/proper.hrl” といったエラーが出力されます。 このエラーを解決するため VS Code のエディタ上でも、testプロファイル以下にダウンロードされたライブラリを参照するように設定を追加します。 変更した後のdevcontainer. json は以下のようになります。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " erlang.formattingLineLength ": 200 , " erlang.includePaths ": [ " _build/test/lib " ] , " [erlang] ": { " editor.defaultFormatter ": " pgourlain.erlang ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } , " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " pgourlain.erlang ", " esbenp.prettier-vscode " ] } } } erlang.includePaths の値として、ライブラリを格納している ディレクト リの 相対パス を記述しています。 まとめ ここまで、Dev Containerで Erlang アプリケーションの開発環境を構築する方法について説明してきました。 普段あまり使っていない プログラミング言語 でも、Dockerベースのコンテナ技術を使えば簡単に開発環境を構築できることがお分かりいただけたんじゃないでしょうか。 特に私が普段使っている Windows では インストーラ を使ったバイナリのインストールは後腐れが残り易いので、本を読み終わったら全てを片付けられて副作用のないDev Containerは非常に便利です。 この記事を読んでいただいたあなたも是非、クリーンな開発環境を構築してプロパティベーステストという応用可能性の高いテスト手法に習熟できることを願っています。 この記事で紹介している開発環境の構成ファイル 最後に作った構成ファイルを紹介します。 .devcontainer/devcontainer. json { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " erlang.formattingLineLength ": 200 , " erlang.includePaths ": [ " _build/test/lib " ] , " [erlang] ": { " editor.defaultFormatter ": " pgourlain.erlang ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } , " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " pgourlain.erlang ", " esbenp.prettier-vscode " ] } } } 執筆： @sato.taichi （ Shodo で執筆されました ）

みなさんこんにちは、 電通国際情報サービス （ISID）X イノベーション 本部ソフトウェアデザインセンターの佐藤太一です。 皆さんは最近発売された 『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』 はもう読みましたか？ この本は Erlang やElixirを使ってプロパティベーステストというテスト手法について具体的なコードを使って実践的に学習できる本です。非常に素晴らしい本ですが、難しい部分も多いため私は少しずつ読んでいる所です。 この記事では、この本を読むにあたってサンプルコードを動かすための環境を使っているOSに依存せずに作成する方法を説明します。 事前の準備 最小限のDev Container devcontainer.jsonを編集する環境の構築 Erlang用VS Code拡張 テスト用プロファイルで使うライブラリをエディタに認識させる まとめ この記事で紹介している開発環境の構成ファイル .devcontainer/devcontainer.json 事前の準備 この記事が前提とする環境について軽く説明します。 まず、  VS Code  を事前にインストールしておいてください。 次に、 Docker Desktop をインストールして動作する状態にしてください。基本的には単に インストーラ を実行すれば動作する状態になります。 そして、 VS Code に  Dev Containers 拡張をインストールしておいてください。 最後に、作業用のプロジェクト ディレクト リを作成してください。ここでは、pbt という ディレクト リを作成してプロジェクトのルート ディレクト リとしています。 最小限のDev Container まずは、Dev Containerを使って Erlang が提供する公式のDockerイメージを使った開発環境を作成してみましょう。 プロジェクトのルート ディレクト リに、  .devcontainer  という ディレクト リを作って、その中に  devcontainer.json  というファイル名で以下の内容を保存します。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " containerEnv ": { " TZ ": " Asia/Tokyo " } , " runArgs ": [ " --init " ] } name の値は、分かりやすい名前なら何でもいいです。ここでは、devcontainer- erlang としています。 image の値は、 erlang :slim としています。これは公式のイメージ名です。 ベースイメージや Erlang ランタイムのバージョンを別なものにしたい場合には、 https://hub.docker.com/_/erlang から探してください。 containerEnv の値は、コンテナ内で参照される 環境変数 です。ここでは タイムゾーン が  Asia/Tokyo になるよう設定しています。時刻に起因する問題の調査は難しいので、ここで明示的に設定しています。 runArgs の値は、  --init  を渡すことでDockerが  /dev/init  というシグナルハンドリング用のプロセスを起動してくれます。これによってコンテナを安定的にシャットダウンできます。 devcontainer. json を編集する環境の構築 ここから、devcontainer. json を編集しながら開発環境を構築していくので、まずは快適に json ファイルを編集できるようにしましょう。 devcontainer. json には、Dev Containerとして起動した VS Code を構成するための設定項目がありますので、それらを編集します。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " esbenp.prettier-vscode " ] } } } customizations  というキーがDev Containerの構成を行うための設定項目です。この中に vscode  という項目がありますね。 settings の中では、 VS Code の設定項目を管理します。 editor.renderWhitespace  の値として、  all  を設定しているのは、ファイルの中に紛れ込んだ全角スペースを見つけやすくするためです。私たちが IME を使っている以上、意図しない場所に全角スペースが入り込んでしまい、それによって理解が困難なエラーメッセージを読むことになるのは避けられません。全角スペースが見えていれば、そういったドハマりから抜け出しやすくなります。 [json][jsonc]  の値として、いくつか設定しています。ちなみに、jsoncは、 JSON  with commentsの略称です。 editor.defaultFormatter  の値として、esbenp.prettier- vscode  を設定しています。これによってprettierを使ったフォーマットが行われます。 editor.formatOnSave  の値として、trueを設定することでファイル保存時にフォーマットが行われるようにしています。 editor.codeActionsOnSave  の値として、source.fixAll を有効化することで自動的に補正できるフォーマットエラーをprettierが積極的に補正してくれます。 extensions の中では、Dev Containerとして起動された VS Code にインストールされる VS Code 拡張を列挙します。ここでは、 JSON を自動フォーマットするための  esbenp.prettier-vscode  を設定しています。 Erlang 用 VS Code 拡張 次は、 Erlang 用の VS Code 拡張を追加します。 マーケットプレイス を確認するといくつかの拡張がありますが、一番利用者の多いものを今回は使います。 erlang devcontainer. json のextensionsに拡張を追加すると、以下のようになります。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " erlang.formattingLineLength ": 200 , " [erlang] ": { " editor.defaultFormatter ": " pgourlain.erlang ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } , " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " pgourlain.erlang ", " esbenp.prettier-vscode " ] } } } erlang.formattingLineLength の値として、200を設定しています。この設定項目はドキュメントには記載がないので、私の設定値をここに書いています。 [erlang] の値として、いくつか設定しています。何をしているかは [json][jsonc]  の時と同じです。 これで Erlang のアプリケーション開発環境は完成です。しかし、本を読み進めていくと早々に問題にぶつかります。 テスト用プロファイルで使うライブラリをエディタに認識させる 書籍では、PropErというライブラリをrebarというビルドツールに構成するように指示されます。 その結果、rebar.configを以下のように構成します。 { project_plugins , [ rebar3_proper ]} . { profiles , [ { test , [ { erl_opts , [ nowarn_export_all ]} , { deps , [ proper ]} ]} ]} . { erl_opts , [ debug_info ]} . { deps , []} . rebar3では、依存ライブラリをプロファイル毎に管理できるようになっています。 そして、 proper は test プロファイルでのみ参照されます。 ダウンロードされた依存ライブラリは、プロジェクトのルート ディレクト リにある _build ディレクト リ以下に格納されています。 この状態だと、rebarによるビルドは成功するのですが、エディタ上で can't find include lib "proper/include/proper.hrl” といったエラーが出力されます。 このエラーを解決するため VS Code のエディタ上でも、testプロファイル以下にダウンロードされたライブラリを参照するように設定を追加します。 変更した後のdevcontainer. json は以下のようになります。 { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " erlang.formattingLineLength ": 200 , " erlang.includePaths ": [ " _build/test/lib " ] , " [erlang] ": { " editor.defaultFormatter ": " pgourlain.erlang ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } , " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " pgourlain.erlang ", " esbenp.prettier-vscode " ] } } } erlang.includePaths の値として、ライブラリを格納している ディレクト リの 相対パス を記述しています。 まとめ ここまで、Dev Containerで Erlang アプリケーションの開発環境を構築する方法について説明してきました。 普段あまり使っていない プログラミング言語 でも、Dockerベースのコンテナ技術を使えば簡単に開発環境を構築できることがお分かりいただけたんじゃないでしょうか。 特に私が普段使っている Windows では インストーラ を使ったバイナリのインストールは後腐れが残り易いので、本を読み終わったら全てを片付けられて副作用のないDev Containerは非常に便利です。 この記事を読んでいただいたあなたも是非、クリーンな開発環境を構築してプロパティベーステストという応用可能性の高いテスト手法に習熟できることを願っています。 この記事で紹介している開発環境の構成ファイル 最後に作った構成ファイルを紹介します。 .devcontainer/devcontainer. json { " name ": " devcontainer-erlang ", " image ": " erlang:slim ", " customizations ": { " vscode ": { " settings ": { " editor.renderWhitespace ": " all ", " erlang.formattingLineLength ": 200 , " erlang.includePaths ": [ " _build/test/lib " ] , " [erlang] ": { " editor.defaultFormatter ": " pgourlain.erlang ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } , " [json][jsonc] ": { " editor.defaultFormatter ": " esbenp.prettier-vscode ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll ": true } } } , " extensions ": [ " pgourlain.erlang ", " esbenp.prettier-vscode " ] } } } 執筆： @sato.taichi （ Shodo で執筆されました ）

みなさんこんにちは、X（クロス） イノベーション 本部　ソフトウェアデザインセンターの鈴木です。 データベースに Amazon DynamoDB を採用しているWebアプリケーションを、 Amazon RDSを採用したWebアプリケーションにリプレイスしている際に、データ移行で苦戦したことを記事に残します。 背景 実現したいことと、苦戦したこと 実現したいこと アプリケーションとテーブル定義 苦戦したこと 解決方法 要点 DynamoDB→S3へのエクスポート 開発環境へのダウンロード、変換処理 RDSへのインポート まとめ 背景 従来のアプリケーションでは、データベース層にNoSQL型のデータベースであるDynamoDBを採用していました。 しかし、利用ユーザーが増加して パーティション キー以外での検索要件が出てきたことで、フルスキャンをせざるを得ないケースがたびたび発生したためレスポンスタイムやコストの問題が発生していました。 以上のことから、NoSQL型のデータベースより柔軟に検索が可能な、 RDB 型のデータベースであるRDSに移行することとなりました。 実現したいことと、苦戦したこと 実現したいこと 移行元のDynamoDBテーブルからデータをエクスポートし、移行先のアプリケーションのデータベース（ PostgreSQL ）のテーブル定義に基づいてデータを変換します。最終的には、RDSへデータをインポートすることを目指します。 データの変換・移行には、 AWS Glueや AWS DMS(Database Migration Service)などの AWS サービスを利用することもできます。今回は、開発環境でデータの一部を使いたかったこともあり、開発環境でTypeScriptを用いて変換します。 アプリケーションとテーブル定義 アプリケーションは、Next.js × Prisma を用いて実装しています。 データベースには PostgreSQL を採用しており、記事用に簡略化した移行後のテーブル構成は以下のとおりです。 userテーブルとaccountテーブルがあり、userテーブルのidを外部キーに、accountテーブルとリレーションを築いています。 苦戦したこと DynamoDBからエクスポートしたデータを変換してデータベースにインポートする過程で、SERIAL型であるuserテーブルのidはレコードが作成されるまで確定しません。accountテーブルにレコードを作成する際に、accountテーブルの外部キーであるuser_idは、userテーブルのレコードを作成後にuserテーブルから取得しなければなりません。 また、Webアプリケーションの ソースコード や、アプリケーションが参照しているデータベースの スキーマ にはなるべく手を加えないようにしたいです。 解決方法 要点 今回は次の流れで解決しました。 ①accountテーブルとは別に一時的なaccount_tmpテーブルをデータベースに作成する。 ②userテーブルとaccount_tmpテーブルに変換後のデータをINSERTする。 ③userテーブルからaccount_tmpテーブルのレコードに対応したuser_idを取得して、account_tmpテーブルのレコードをUPDATEする。 ④account_tmpテーブルからaccountテーブルにINSERTする。 以降、詳しくみていきます。（ AWS の構成やデータ構造は記事用に簡略化しています） DynamoDB→S3へのエクスポート 記事用にDynamoDBテーブルを作成しました。 パーティション キーにはemailを設定しています。 項目は、以下のとおりです。 email (S) account (L) updated_at (N) created_at (N) test-user1@ example.com [{"name": "test-user1-1"}, {"name": "test-user1-2"}] 1696129200 1696129200 test-user2@ example.com [{"name": "test-user2-1"}] 1696129200 1696129200 test-user3@ example.com [{"name": "test-user3-1"}, {"name": "test-user3-2"}] 1696129200 1696129200 このテー ブルデー タを開発環境に移動させるため、S3 バケット にエクスポートします。 まず、エクスポート用にS3に バケット を作成します。 その後、DynamoDBのコンソール画面から、「エクスポートおよびストリーム」タブから「S3へのエクスポート」を選択することで、先ほど作成したS3 バケット にデータをエクスポートします。 詳しい手順は、詳細は AWSの公式記事 を参照してください。 開発環境へのダウンロード、変換処理 S3のコンソール画面から、先ほどエクスポートしたDynamoDBテーブル情報をダウンロードしてください。 AWS CLI から aws s3 cp s3://[バケット名]/[データが配置されたフォルダパス] [ダウンロード先のフォルダパス] --recursive でもダウンロード可能です。 ダウンロード後のデータは解凍しておいてください。DynamoDBのデータ量が多い場合は複数ファイルに分かれていることもあります。 gunzip ./input/fsjiydg6by6o5cjalruephgpca.json.gz -k 解凍後のデータを開くと、DynamoDBから出力したデータは以下のような形式となっています。DynamoDB JSON 形式と呼ばれるらしいです。 // fsjiydg6by6o5cjalruephgpca.json { " Item ": { " email ": { " S ":" test-user1@example.com " } ," updated_at ": { " N ":" 1696129200 " } ," account ": { " L ": [{ " M ": { " name ": { " S ":" test-user1-1 " }}} , { " M ": { " name ": { " S ":" test-user1-2 " }}}]} ," created_at ": { " N ":" 1696129200 " }} } { " Item ": { " email ": { " S ":" test-user2@example.com " } ," updated_at ": { " N ":" 1696129200 " } ," account ": { " L ": [{ " M ": { " name ": { " S ":" test-user2-1 " }}}]} ," created_at ": { " N ":" 1696129200 " }} } { " Item ": { " email ": { " S ":" test-user3@example.com " } ," updated_at ": { " N ":" 1696129200 " } ," account ": { " L ": [{ " M ": { " name ": { " S ":" test-user3-1 " }}} , { " M ": { " name ": { " S ":" test-user3-2 " }}}]} ," created_at ": { " N ":" 1696129200 " }}} データベース( PostgreSQL )にデータをインポートするため、 CSV 形式に変換します。変換の過程で、DynamoDB JSON 形式を扱いやすい JSON 形式に変換するため @aws-sdk/util-dynamodb というパッケージを用います。 変換に用いた自作の スクリプト を一例として掲載します。 下記のコードをターミナル上で実行し、データを CSV 形式で出力します。 ./node_modules/.bin/ts-node convert.ts ./input ※「./input」はDynamoDBテーブル情報があるフォルダ // convert.ts import * as fs from "fs" ; import * as readline from "readline" ; import { unmarshall } from "@aws-sdk/util-dynamodb" ; import { Parser } from "json2csv" ; // 型を定義 type Account = { name: string ; } type UserTableFormat = { email: string ; createdAt: Date ; updatedAt: Date ; } ; type AccountTableFormat = { name: string ; createdAt: Date ; updateAt: Date ; email: string ; } ; // 出力先のcsvファイルのヘッダーと値を紐づける const userTableFields = [ { label: "email" , value: "email" } , { label: "createdAt" , value: "createdAt" } , { label: "updatedAt" , value: "updatedAt" } , ] ; const accountTableFields = [ { label: "name" , value: "name" } , { label: "createdAt" , value: "createdAt" } , { label: "updatedAt" , value: "updatedAt" } , { label: "email" , value: "email" } , ] ; // 各フォルダ・ファイルを定義 const inputFolder = process .argv [ 2 ] ; const outputFilePath = "./output" ; const outputUserTable = outputFilePath + "/userTable.csv" ; const outputAccountTable = outputFilePath + "/accountTable.csv" ; // 出力先のディレクトリを作成 fs.mkdirSync ( outputFilePath , { recursive: true } ); // 出力ファイルの初期化 fs.writeFileSync ( outputUserTable , "" ); fs.writeFileSync ( outputAccountTable , "" ); // DynamoDBテーブル情報ファイルの一覧を取得 const fileList = fs.readdirSync ( inputFolder ) .filter (( f ) => f.endsWith ( ".json" )); // 変換・書き込み処理 for ( const inputFile of fileList ) { const rs = fs.createReadStream ( inputFolder + "/" + inputFile ); const rl = readline.createInterface ( { input: rs } ); rl.on ( "line" , ( line ) => { // 変換前に余分な文字列を削除 const inputLine = line .slice ( 0 , -1 ) .replace ( /{"Item":/ , "" ) .replace ( /\r?\n/g , "" ); // DynamoDB JSON→JSONに変換 const inputData = unmarshall ( JSON .parse ( inputLine )); // テーブルごとにデータを分割 const userTableRecord: UserTableFormat = { email: inputData.email , createdAt: new Date ( inputData.created_at * 1000 ), updatedAt: new Date ( inputData.updated_at * 1000 ), } ; let accountTableRecords: AccountTableFormat [] | null ; if ( ! inputData.account ) { accountTableRecords = null ; } else { accountTableRecords = inputData.account.map (( a: Account ) => { return { name: a.name , createdAt: new Date ( inputData.created_at * 1000 ), updatedAt: new Date ( inputData.updated_at * 1000 ), email: inputData.email , } } ) } // csv形式にパース const userTableParser = new Parser ( { fields: userTableFields , header: false , withBOM: true } ); const userTableCsv = userTableParser.parse ( userTableRecord ); let accountTableCsv if ( accountTableRecords && accountTableRecords.length > 0 ) { const githubAccountTableParser = new Parser ( { fields: accountTableFields , header: false , withBOM: true } ); accountTableCsv = githubAccountTableParser.parse ( accountTableRecords ); } // テーブルごとにファイル出力 fs.writeFileSync ( outputUserTable , userTableCsv.slice ( 1 ) + "\n" , { flag: "a" } ); if ( accountTableCsv ) { fs.writeFileSync ( outputAccountTable , accountTableCsv.slice ( 1 ) + "\n" , { flag: "a" } ); } } ); } 以上で、データの変換は完了し、outputフォルダに変換後のデータがテーブル単位でファイルとして出力されています。 S3 バケット のルートに「upload」フォルダを作って、これらのファイルをアップロードします。S3のコンソール画面からでも、次の AWS CLI から（以下コマンド）でもアップロード可能です。 aws s3 cp ./output/ s3://[バケット名]/upload/ --recursive RDSへのインポート RDSに対して、 psql コマンドライン を使用してS3にアップロードした csv ファイルデータを反映させていきます。 詳細は省きますが、RDSをプライベートサブネット内に作成している場合、踏み台サーバを使用するなどでデータベースにアクセスしてください。今回は踏み台サーバでポート フォワ ーディングを行い、RDSの対象データベースへ通信できる状態で、以下のコマンドを実行してデータベースに接続します。 パスワードの入力が求められるため、データベースユーザーに対応するパスワードを入力してください。 psql --host=localhost --port=5432 --username=[RDSのユーザー名] --dbname=[RDSのデータベース名] --password postgres 次に、 psql を用いてS3のファイルデータをRDSにインポートするため、以下のコマンドから aws _s3 拡張機能 をインストールします。 CREATE EXTENSION aws_s3 CASCADE; \dx コマンドを実行し、 aws_s3 拡張機能 がインストールされていることを確認します。 postgres=> \dx List of installed extensions Name | Version | Schema | Description -------------+---------+------------+--------------------------------------------- aws_commons | 1.2 | public | Common data types across AWS services aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3 plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language (3 rows) ここが今回の本題です。 課題にも記載しましたが、userテーブルのidはレコードが作成されるまで生成されないため、accountテーブルの外部キーであるuser_idは CSV 形式に変換するタイミングでは確定させることができませんでした。 今回は以下の方法で解決しました。 userテーブルのユニークカラム(email)をフィールドに持つ account_tmpテーブルを作成する。 S3にアップロードした csv ファイルを、userテーブルとaccount_tmpテーブルに取り込む。 userテーブルに作成されたレコードからaccount_tmpテーブルに設定したユニークフィールドをもとにidを取得し、account_tmpテーブルのuser_idを更新する。 account_tmpテーブルのレコードをaccountテーブルにINSERTする。 account_tmpテーブルを削除する。 具体的には以下の SQL ファイルを psql から実行します。 \i data_migration.sql -- data_migration.sql -- 1. account_tmpテーブルを作成する CREATE TABLE " account_tmp " ( " id " SERIAL NOT NULL , " name " TEXT NOT NULL , " user_id " INTEGER , " created_at " TIMESTAMP ( 0 ) NOT NULL DEFAULT CURRENT_TIMESTAMP , " updated_at " TIMESTAMP ( 0 ) NOT NULL DEFAULT CURRENT_TIMESTAMP , " email " TEXT NOT NULL , CONSTRAINT " account_tmp_pkey " PRIMARY KEY ( " id " ) ); -- 2. S3にアップロードしたcsvファイルを、userテーブルとaccount_tmpテーブルに取り込む SELECT aws_s3.table_import_from_s3( ' "account_tmp" ' , -- テーブル名 ' "name", "user_id", "created_at", "updated_at", "email" ' , -- カラム名 ' (format csv) ' , -- ファイル形式 ' bucket-name ' , -- バケット名 ' upload/accountTable.csv ' , -- バケットルートからのファイルパス ' ap-northeast-1 ' -- リージョン ); SELECT aws_s3.table_import_from_s3( ' "user" ' , ' "email", "created_at", "updated_at" ' , ' (format csv) ' , ' bucket-name ' , ' upload/userTable.csv ' , ' ap-northeast-1 ' ); -- 3. ユニークフィールドをもとにidを取得し、account_tmpテーブルのuser_idを更新する UPDATE " account_tmp " SET " userId " = " user " . " id " FROM " user " WHERE " account_tmp " . " email " = " user " . " email " ; -- 4. account_tmpテーブルのレコードをaccountテーブルにINSERTする INSERT INTO " account " ( " name " , " user_id " , " created_at " , " updated_at " ) SELECT " name " , " user_id " , " created_at " , " updated_at " FROM " account_tmp " ; -- 5. account_tmpテーブルを削除する DROP TABLE " account_tmp " ; 以上で無事にRDSへデータを移行できました。 ちなみに開発環境のデータベースに取り込む際は、以下2点を変更してください。 psql でデータベースにログインする際、開発環境のデータベースホスト名・ポート番号・データベース名・ユーザー名に置き換えて実行する。 「data_migration. sql 」の「2. S3にアップロードした csv ファイルを、userテーブルとaccount_tmpテーブルに取り込む」部分を開発環境の csv ファイルからデータを取り込むように修正して、 \i data_migration.sql を実行する。 -- data_migration.sql -- (省略) -- 2. csvファイルをテーブルに取り込む \COPY " account_tmp " ( " name " , " user_id " , " created_at " , " updated_at " , " email " ) FROM ' ./output/accountTable.csv ' DELIMITER ' , ' CSV \COPY " user " ( " email " , " created_at " , " updated_at " ) FROM ' ./output/userTable.csv ' DELIMITER ' , ' CSV -- 3. ユニークフィールドをもとにidを取得し、account_tmpテーブルのuser_idを更新する -- (省略) まとめ 今回は、DynamoDBからRDSへデータを移行する際に苦戦したことを記事に残しました。user_id問題以外にも、DynamoDB JSON の変換方法など色々と勉強になりました。 同じ場面に出くわす機会は少ないと思いますが、どなたかの参考になれば幸いです。 最後までお読みいただきましてありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ フルサイクルエンジニア 執筆： @suzuki.takuma 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

みなさんこんにちは、X（クロス） イノベーション 本部　ソフトウェアデザインセンターの鈴木です。 データベースに Amazon DynamoDB を採用しているWebアプリケーションを、 Amazon RDSを採用したWebアプリケーションにリプレイスしている際に、データ移行で苦戦したことを記事に残します。 背景 実現したいことと、苦戦したこと 実現したいこと アプリケーションとテーブル定義 苦戦したこと 解決方法 要点 DynamoDB→S3へのエクスポート 開発環境へのダウンロード、変換処理 RDSへのインポート まとめ 背景 従来のアプリケーションでは、データベース層にNoSQL型のデータベースであるDynamoDBを採用していました。 しかし、利用ユーザーが増加して パーティション キー以外での検索要件が出てきたことで、フルスキャンをせざるを得ないケースがたびたび発生したためレスポンスタイムやコストの問題が発生していました。 以上のことから、NoSQL型のデータベースより柔軟に検索が可能な、 RDB 型のデータベースであるRDSに移行することとなりました。 実現したいことと、苦戦したこと 実現したいこと 移行元のDynamoDBテーブルからデータをエクスポートし、移行先のアプリケーションのデータベース（ PostgreSQL ）のテーブル定義に基づいてデータを変換します。最終的には、RDSへデータをインポートすることを目指します。 データの変換・移行には、 AWS Glueや AWS DMS(Database Migration Service)などの AWS サービスを利用することもできます。今回は、開発環境でデータの一部を使いたかったこともあり、開発環境でTypeScriptを用いて変換します。 アプリケーションとテーブル定義 アプリケーションは、Next.js × Prisma を用いて実装しています。 データベースには PostgreSQL を採用しており、記事用に簡略化した移行後のテーブル構成は以下のとおりです。 userテーブルとaccountテーブルがあり、userテーブルのidを外部キーに、accountテーブルとリレーションを築いています。 苦戦したこと DynamoDBからエクスポートしたデータを変換してデータベースにインポートする過程で、SERIAL型であるuserテーブルのidはレコードが作成されるまで確定しません。accountテーブルにレコードを作成する際に、accountテーブルの外部キーであるuser_idは、userテーブルのレコードを作成後にuserテーブルから取得しなければなりません。 また、Webアプリケーションの ソースコード や、アプリケーションが参照しているデータベースの スキーマ にはなるべく手を加えないようにしたいです。 解決方法 要点 今回は次の流れで解決しました。 ①accountテーブルとは別に一時的なaccount_tmpテーブルをデータベースに作成する。 ②userテーブルとaccount_tmpテーブルに変換後のデータをINSERTする。 ③userテーブルからaccount_tmpテーブルのレコードに対応したuser_idを取得して、account_tmpテーブルのレコードをUPDATEする。 ④account_tmpテーブルからaccountテーブルにINSERTする。 以降、詳しくみていきます。（ AWS の構成やデータ構造は記事用に簡略化しています） DynamoDB→S3へのエクスポート 記事用にDynamoDBテーブルを作成しました。 パーティション キーにはemailを設定しています。 項目は、以下のとおりです。 email (S) account (L) updated_at (N) created_at (N) test-user1@ example.com [{"name": "test-user1-1"}, {"name": "test-user1-2"}] 1696129200 1696129200 test-user2@ example.com [{"name": "test-user2-1"}] 1696129200 1696129200 test-user3@ example.com [{"name": "test-user3-1"}, {"name": "test-user3-2"}] 1696129200 1696129200 このテー ブルデー タを開発環境に移動させるため、S3 バケット にエクスポートします。 まず、エクスポート用にS3に バケット を作成します。 その後、DynamoDBのコンソール画面から、「エクスポートおよびストリーム」タブから「S3へのエクスポート」を選択することで、先ほど作成したS3 バケット にデータをエクスポートします。 詳しい手順は、詳細は AWSの公式記事 を参照してください。 開発環境へのダウンロード、変換処理 S3のコンソール画面から、先ほどエクスポートしたDynamoDBテーブル情報をダウンロードしてください。 AWS CLI から aws s3 cp s3://[バケット名]/[データが配置されたフォルダパス] [ダウンロード先のフォルダパス] --recursive でもダウンロード可能です。 ダウンロード後のデータは解凍しておいてください。DynamoDBのデータ量が多い場合は複数ファイルに分かれていることもあります。 gunzip ./input/fsjiydg6by6o5cjalruephgpca.json.gz -k 解凍後のデータを開くと、DynamoDBから出力したデータは以下のような形式となっています。DynamoDB JSON 形式と呼ばれるらしいです。 // fsjiydg6by6o5cjalruephgpca.json { " Item ": { " email ": { " S ":" test-user1@example.com " } ," updated_at ": { " N ":" 1696129200 " } ," account ": { " L ": [{ " M ": { " name ": { " S ":" test-user1-1 " }}} , { " M ": { " name ": { " S ":" test-user1-2 " }}}]} ," created_at ": { " N ":" 1696129200 " }} } { " Item ": { " email ": { " S ":" test-user2@example.com " } ," updated_at ": { " N ":" 1696129200 " } ," account ": { " L ": [{ " M ": { " name ": { " S ":" test-user2-1 " }}}]} ," created_at ": { " N ":" 1696129200 " }} } { " Item ": { " email ": { " S ":" test-user3@example.com " } ," updated_at ": { " N ":" 1696129200 " } ," account ": { " L ": [{ " M ": { " name ": { " S ":" test-user3-1 " }}} , { " M ": { " name ": { " S ":" test-user3-2 " }}}]} ," created_at ": { " N ":" 1696129200 " }}} データベース( PostgreSQL )にデータをインポートするため、 CSV 形式に変換します。変換の過程で、DynamoDB JSON 形式を扱いやすい JSON 形式に変換するため @aws-sdk/util-dynamodb というパッケージを用います。 変換に用いた自作の スクリプト を一例として掲載します。 下記のコードをターミナル上で実行し、データを CSV 形式で出力します。 ./node_modules/.bin/ts-node convert.ts ./input ※「./input」はDynamoDBテーブル情報があるフォルダ // convert.ts import * as fs from "fs" ; import * as readline from "readline" ; import { unmarshall } from "@aws-sdk/util-dynamodb" ; import { Parser } from "json2csv" ; // 型を定義 type Account = { name: string ; } type UserTableFormat = { email: string ; createdAt: Date ; updatedAt: Date ; } ; type AccountTableFormat = { name: string ; createdAt: Date ; updateAt: Date ; email: string ; } ; // 出力先のcsvファイルのヘッダーと値を紐づける const userTableFields = [ { label: "email" , value: "email" } , { label: "createdAt" , value: "createdAt" } , { label: "updatedAt" , value: "updatedAt" } , ] ; const accountTableFields = [ { label: "name" , value: "name" } , { label: "createdAt" , value: "createdAt" } , { label: "updatedAt" , value: "updatedAt" } , { label: "email" , value: "email" } , ] ; // 各フォルダ・ファイルを定義 const inputFolder = process .argv [ 2 ] ; const outputFilePath = "./output" ; const outputUserTable = outputFilePath + "/userTable.csv" ; const outputAccountTable = outputFilePath + "/accountTable.csv" ; // 出力先のディレクトリを作成 fs.mkdirSync ( outputFilePath , { recursive: true } ); // 出力ファイルの初期化 fs.writeFileSync ( outputUserTable , "" ); fs.writeFileSync ( outputAccountTable , "" ); // DynamoDBテーブル情報ファイルの一覧を取得 const fileList = fs.readdirSync ( inputFolder ) .filter (( f ) => f.endsWith ( ".json" )); // 変換・書き込み処理 for ( const inputFile of fileList ) { const rs = fs.createReadStream ( inputFolder + "/" + inputFile ); const rl = readline.createInterface ( { input: rs } ); rl.on ( "line" , ( line ) => { // 変換前に余分な文字列を削除 const inputLine = line .slice ( 0 , -1 ) .replace ( /{"Item":/ , "" ) .replace ( /\r?\n/g , "" ); // DynamoDB JSON→JSONに変換 const inputData = unmarshall ( JSON .parse ( inputLine )); // テーブルごとにデータを分割 const userTableRecord: UserTableFormat = { email: inputData.email , createdAt: new Date ( inputData.created_at * 1000 ), updatedAt: new Date ( inputData.updated_at * 1000 ), } ; let accountTableRecords: AccountTableFormat [] | null ; if ( ! inputData.account ) { accountTableRecords = null ; } else { accountTableRecords = inputData.account.map (( a: Account ) => { return { name: a.name , createdAt: new Date ( inputData.created_at * 1000 ), updatedAt: new Date ( inputData.updated_at * 1000 ), email: inputData.email , } } ) } // csv形式にパース const userTableParser = new Parser ( { fields: userTableFields , header: false , withBOM: true } ); const userTableCsv = userTableParser.parse ( userTableRecord ); let accountTableCsv if ( accountTableRecords && accountTableRecords.length > 0 ) { const githubAccountTableParser = new Parser ( { fields: accountTableFields , header: false , withBOM: true } ); accountTableCsv = githubAccountTableParser.parse ( accountTableRecords ); } // テーブルごとにファイル出力 fs.writeFileSync ( outputUserTable , userTableCsv.slice ( 1 ) + "\n" , { flag: "a" } ); if ( accountTableCsv ) { fs.writeFileSync ( outputAccountTable , accountTableCsv.slice ( 1 ) + "\n" , { flag: "a" } ); } } ); } 以上で、データの変換は完了し、outputフォルダに変換後のデータがテーブル単位でファイルとして出力されています。 S3 バケット のルートに「upload」フォルダを作って、これらのファイルをアップロードします。S3のコンソール画面からでも、次の AWS CLI から（以下コマンド）でもアップロード可能です。 aws s3 cp ./output/ s3://[バケット名]/upload/ --recursive RDSへのインポート RDSに対して、 psql コマンドライン を使用してS3にアップロードした csv ファイルデータを反映させていきます。 詳細は省きますが、RDSをプライベートサブネット内に作成している場合、踏み台サーバを使用するなどでデータベースにアクセスしてください。今回は踏み台サーバでポート フォワ ーディングを行い、RDSの対象データベースへ通信できる状態で、以下のコマンドを実行してデータベースに接続します。 パスワードの入力が求められるため、データベースユーザーに対応するパスワードを入力してください。 psql --host=localhost --port=5432 --username=[RDSのユーザー名] --dbname=[RDSのデータベース名] --password postgres 次に、 psql を用いてS3のファイルデータをRDSにインポートするため、以下のコマンドから aws _s3 拡張機能 をインストールします。 CREATE EXTENSION aws_s3 CASCADE; \dx コマンドを実行し、 aws_s3 拡張機能 がインストールされていることを確認します。 postgres=> \dx List of installed extensions Name | Version | Schema | Description -------------+---------+------------+--------------------------------------------- aws_commons | 1.2 | public | Common data types across AWS services aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3 plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language (3 rows) ここが今回の本題です。 課題にも記載しましたが、userテーブルのidはレコードが作成されるまで生成されないため、accountテーブルの外部キーであるuser_idは CSV 形式に変換するタイミングでは確定させることができませんでした。 今回は以下の方法で解決しました。 userテーブルのユニークカラム(email)をフィールドに持つ account_tmpテーブルを作成する。 S3にアップロードした csv ファイルを、userテーブルとaccount_tmpテーブルに取り込む。 userテーブルに作成されたレコードからaccount_tmpテーブルに設定したユニークフィールドをもとにidを取得し、account_tmpテーブルのuser_idを更新する。 account_tmpテーブルのレコードをaccountテーブルにINSERTする。 account_tmpテーブルを削除する。 具体的には以下の SQL ファイルを psql から実行します。 \i data_migration.sql -- data_migration.sql -- 1. account_tmpテーブルを作成する CREATE TABLE " account_tmp " ( " id " SERIAL NOT NULL , " name " TEXT NOT NULL , " user_id " INTEGER , " created_at " TIMESTAMP ( 0 ) NOT NULL DEFAULT CURRENT_TIMESTAMP , " updated_at " TIMESTAMP ( 0 ) NOT NULL DEFAULT CURRENT_TIMESTAMP , " email " TEXT NOT NULL , CONSTRAINT " account_tmp_pkey " PRIMARY KEY ( " id " ) ); -- 2. S3にアップロードしたcsvファイルを、userテーブルとaccount_tmpテーブルに取り込む SELECT aws_s3.table_import_from_s3( ' "account_tmp" ' , -- テーブル名 ' "name", "user_id", "created_at", "updated_at", "email" ' , -- カラム名 ' (format csv) ' , -- ファイル形式 ' bucket-name ' , -- バケット名 ' upload/accountTable.csv ' , -- バケットルートからのファイルパス ' ap-northeast-1 ' -- リージョン ); SELECT aws_s3.table_import_from_s3( ' "user" ' , ' "email", "created_at", "updated_at" ' , ' (format csv) ' , ' bucket-name ' , ' upload/userTable.csv ' , ' ap-northeast-1 ' ); -- 3. ユニークフィールドをもとにidを取得し、account_tmpテーブルのuser_idを更新する UPDATE " account_tmp " SET " userId " = " user " . " id " FROM " user " WHERE " account_tmp " . " email " = " user " . " email " ; -- 4. account_tmpテーブルのレコードをaccountテーブルにINSERTする INSERT INTO " account " ( " name " , " user_id " , " created_at " , " updated_at " ) SELECT " name " , " user_id " , " created_at " , " updated_at " FROM " account_tmp " ; -- 5. account_tmpテーブルを削除する DROP TABLE " account_tmp " ; 以上で無事にRDSへデータを移行できました。 ちなみに開発環境のデータベースに取り込む際は、以下2点を変更してください。 psql でデータベースにログインする際、開発環境のデータベースホスト名・ポート番号・データベース名・ユーザー名に置き換えて実行する。 「data_migration. sql 」の「2. S3にアップロードした csv ファイルを、userテーブルとaccount_tmpテーブルに取り込む」部分を開発環境の csv ファイルからデータを取り込むように修正して、 \i data_migration.sql を実行する。 -- data_migration.sql -- (省略) -- 2. csvファイルをテーブルに取り込む \COPY " account_tmp " ( " name " , " user_id " , " created_at " , " updated_at " , " email " ) FROM ' ./output/accountTable.csv ' DELIMITER ' , ' CSV \COPY " user " ( " email " , " created_at " , " updated_at " ) FROM ' ./output/userTable.csv ' DELIMITER ' , ' CSV -- 3. ユニークフィールドをもとにidを取得し、account_tmpテーブルのuser_idを更新する -- (省略) まとめ 今回は、DynamoDBからRDSへデータを移行する際に苦戦したことを記事に残しました。user_id問題以外にも、DynamoDB JSON の変換方法など色々と勉強になりました。 同じ場面に出くわす機会は少ないと思いますが、どなたかの参考になれば幸いです。 最後までお読みいただきましてありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ フルサイクルエンジニア 執筆： @suzuki.takuma 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS WAF には AWS マネージドルール が複数提供されており、利用することで AWS が定めた条件に一致するリク エス トをブロックしてくれます。各マネージドルールグループには、複数の個別のルールが含まれています。例えば コアルールセット (CRS) マネージドルールグループ には、v1.6 時点で 22 個の個別ルールが含まれています。 マネージドルールグループの個別ルールには、アプリケーションによっては条件が厳しすぎるものもあります。例えば以下の個別ルールによってリク エス トをブロックして欲しくない場合があるかもしれません。 マネージドルール名 検出条件 SizeRestrictions_BODY リク エス トボディサイズが 8 KB を超える場合はブロック EC2MetaDataSSRF_BODY リク エス トボディに「 localhost 」「 127.0.0.1 」の文字列が含まれている場合はブロック（＊注1） GenericLFI_BODY リク エス トボディに「../../」の文字列が含まれている場合はブロック、など (＊注1) 筆者が確認した条件であり、公式のアナウンスではありません。また他にも条件があるかもしれません。 マネージドルールがアプリケーションの要件に合わない時は、個別のルールのアクションを Count にオーバーライドすることができます。 しかしこれではあらゆる状況においてそのルールによるブロックが無効化されてしまい、マネージドルールを使っている効果が薄れてしまいます。そうではなく、「特定の条件においてのみ」マネージドルールのアクションを Count に変更したい場合があると思います。 こちら でも紹介されているような方法であり、 AWS WAF の ラベル を利用して実現します。 マネージドルールに条件を追加する仕組み まず、特定の条件において「のみ」マネージドルールのアクションを変更するための仕組みを説明します。 マネージドルールの判定条件に一致した場合、一致した目印として特定の「ラベル」がリク エス トに付与されます。ルールアクションを Count にオーバーライドした場合も、ブロックはされなくなりますが「ラベル」は Block の時と変わらず付与されます。例えば EC2MetaDataSSRF_BODY ルールに一致した場合は awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_Body というラベルが付与されます。付与されたラベルは Web ACL 内の後続のルールからも確認することができます。 マネージドルールグループの後に評価される自作ルールを追加し、Statement に「（ Count にオーバーライドした）マネージドルールに一致した場合に付与されるラベル」と「ブロックを有効にしたい条件」を AND 条件で評価させることで、「特定の条件においてのみ」アクションを Count に変更することができます。例えば、リク エス トの URI パスが /api/* であれば EC2MetaDataSSRF_BODY ルールによるブロックを無効にしたいが、他の URI パスではそのまま有効にしたい場合、次の2つの Statement を AND 条件で繋げ、アクションを Block とした自作ルールを追加します。 リク エス トに「awswaf:managed: aws :core-rule-set:EC2MetaDataSSRF_Body」ラベルがある かつ URI パスが /api/* ではない (NotStatement) 場合に、 Block ここからは、これを実際にマネジメントコンソールで試してみます。 （準備）ALBの作成 WAF Web ACL を関連付けるための ALB を作成し、固定レスポンスを返すようにします。 WAF Web ACL 作成 WAF Web ACL を作成し、ALB に関連付けます。 「Create web ACL 」をクリック Web ACL の名前を入力し、前のステップで作成した ALB を関連付け、「Next」をクリック 「Add managed rule groups」をクリック 「 AWS managed rule groups」にある「Core rule set」のスイッチをオン あとはデフォルト設定のまま Web ACL の作成を完了させます。 WAFの動作確認①：マネージドルールの動作確認 WAF Web ACL が関連付けられた状態の ALB にリク エス トを送ってみます。 ボディに何も含まれていない POST リク エス トは、ブロックされることなく ALB に設定した固定レスポンスが返ってきます。 しかしリク エス トボディに「 localhost 」を含めると、WAF にブロックされ 403 が返されます。 個別ルールのアクションのオーバーライド EC2MetaDataSSRF_BODY ルールのアクションを Count にオーバーライドし、リク エス トボディに「 localhost 」があってもブロックされないようにしていきます。 先ほど作成した WAF Web ACL に追加したマネージドルールをチェックし、「Edit」を選択 EC2MetaDataSSRF_BODY ルールアクションを Override to Count に変更し、「Save rule」をクリック 次の画面でも「Save」をクリック WAFの動作確認②：マネージドルール無効化の確認 再びリク エス トボディに「 localhost 」を含めるリク エス トを送信すると、今度はブロックされずに固定レスポンスが返ってきます。 現在、あらゆる状況において EC2MetaDataSSRF_BODY ルールによるブロックが無効化されている状態です。次のステップからは「 URI パスが /api/ から始まる場合に限り、ブロックを無効化する」ようにカスタマイズしていきます。 自作ルールの追加 「Add my own rules and rule groups」をクリック ビジュアルエディタで次のように Statement を組み立て、「Add rule」をクリック 優先順位がマネージドルールグループよりも後ろであることを確認し、「Save」をクリック WAFの動作確認③：自作ルールの確認 再びリク エス トボディに「 localhost 」を含めるリク エス トを送信すると、今度はブロックされました。 しかし、リク エス ト URI を「/ api /hello」とすると、ブロックされずに通過しました。 以上で、マネージドルールグループの個別ルールに条件を追加することができました。 より複雑な条件の場合 以上はシンプルな条件について確認しましたが、条件が複雑な場合の自作ルールの組み方を簡単に説明します。例として以下の場合です。 マネージドルールグループの EC2MetaDataSSRF_BODY ルールと GenericLFI_BODY ルールを対象にしたい リク エス トがこれらのルールに一致した場合、「リク エス ト URI が /api/* 」かつ「 content-type ヘッダーが application/json 」の場合はブロックされないようにしたい。それ以外の場合はブロックしたい このような自作ルールは次のように実現できます。 今のところ AND 条件や OR 条件が多重になるルールはビジュアルエディタで作成できませんので、 JSON エディタに切り替えてルールを編集することになります。 例に示した複雑な条件の自作ルールは、以下のような JSON で作れます。 { " Name ": " custom-body-block ", " Priority ": 1 , " Statement ": { " AndStatement ": { " Statements ": [ { " OrStatement ": { " Statements ": [ { " LabelMatchStatement ": { " Scope ": " LABEL ", " Key ": " awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_Body " } } , { " LabelMatchStatement ": { " Scope ": " LABEL ", " Key ": " awswaf:managed:aws:core-rule-set:GenericLFI_Body " } } ] } } , { " NotStatement ": { " Statement ": { " AndStatement ": { " Statements ": [ { " ByteMatchStatement ": { " SearchString ": " /api/ ", " FieldToMatch ": { " UriPath ": {} } , " TextTransformations ": [ { " Priority ": 0 , " Type ": " NONE " } ] , " PositionalConstraint ": " STARTS_WITH " } } , { " ByteMatchStatement ": { " SearchString ": " application/json ", " FieldToMatch ": { " SingleHeader ": { " Name ": " content-type " } } , " TextTransformations ": [ { " Priority ": 0 , " Type ": " NONE " } ] , " PositionalConstraint ": " EXACTLY " } } ] } } } } ] } } , " Action ": { " Block ": {} } , " VisibilityConfig ": { " SampledRequestsEnabled ": true , " CloudWatchMetricsEnabled ": true , " MetricName ": " custom-body-block " } } さいごに AWS WAF マネージドルールグループの個別ルールの適用条件を、ラベルと自作ルールを使ってカスタマイズする方法を試しました。最初は難しそうに見えるかもしれませんが、理屈を理解すると柔軟にマネージドルールをカスタマイズできるようになるので、 AWS WAF をより使いこなしたい方はぜひ試してみてください。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @kou.kinyo 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS WAF には AWS マネージドルール が複数提供されており、利用することで AWS が定めた条件に一致するリク エス トをブロックしてくれます。各マネージドルールグループには、複数の個別のルールが含まれています。例えば コアルールセット (CRS) マネージドルールグループ には、v1.6 時点で 22 個の個別ルールが含まれています。 マネージドルールグループの個別ルールには、アプリケーションによっては条件が厳しすぎるものもあります。例えば以下の個別ルールによってリク エス トをブロックして欲しくない場合があるかもしれません。 マネージドルール名 検出条件 SizeRestrictions_BODY リク エス トボディサイズが 8 KB を超える場合はブロック EC2MetaDataSSRF_BODY リク エス トボディに「 localhost 」「 127.0.0.1 」の文字列が含まれている場合はブロック（＊注1） GenericLFI_BODY リク エス トボディに「../../」の文字列が含まれている場合はブロック、など (＊注1) 筆者が確認した条件であり、公式のアナウンスではありません。また他にも条件があるかもしれません。 マネージドルールがアプリケーションの要件に合わない時は、個別のルールのアクションを Count にオーバーライドすることができます。 しかしこれではあらゆる状況においてそのルールによるブロックが無効化されてしまい、マネージドルールを使っている効果が薄れてしまいます。そうではなく、「特定の条件においてのみ」マネージドルールのアクションを Count に変更したい場合があると思います。 こちら でも紹介されているような方法であり、 AWS WAF の ラベル を利用して実現します。 マネージドルールに条件を追加する仕組み まず、特定の条件において「のみ」マネージドルールのアクションを変更するための仕組みを説明します。 マネージドルールの判定条件に一致した場合、一致した目印として特定の「ラベル」がリク エス トに付与されます。ルールアクションを Count にオーバーライドした場合も、ブロックはされなくなりますが「ラベル」は Block の時と変わらず付与されます。例えば EC2MetaDataSSRF_BODY ルールに一致した場合は awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_Body というラベルが付与されます。付与されたラベルは Web ACL 内の後続のルールからも確認することができます。 マネージドルールグループの後に評価される自作ルールを追加し、Statement に「（ Count にオーバーライドした）マネージドルールに一致した場合に付与されるラベル」と「ブロックを有効にしたい条件」を AND 条件で評価させることで、「特定の条件においてのみ」アクションを Count に変更することができます。例えば、リク エス トの URI パスが /api/* であれば EC2MetaDataSSRF_BODY ルールによるブロックを無効にしたいが、他の URI パスではそのまま有効にしたい場合、次の2つの Statement を AND 条件で繋げ、アクションを Block とした自作ルールを追加します。 リク エス トに「awswaf:managed: aws :core-rule-set:EC2MetaDataSSRF_Body」ラベルがある かつ URI パスが /api/* ではない (NotStatement) 場合に、 Block ここからは、これを実際にマネジメントコンソールで試してみます。 （準備）ALBの作成 WAF Web ACL を関連付けるための ALB を作成し、固定レスポンスを返すようにします。 WAF Web ACL 作成 WAF Web ACL を作成し、ALB に関連付けます。 「Create web ACL 」をクリック Web ACL の名前を入力し、前のステップで作成した ALB を関連付け、「Next」をクリック 「Add managed rule groups」をクリック 「 AWS managed rule groups」にある「Core rule set」のスイッチをオン あとはデフォルト設定のまま Web ACL の作成を完了させます。 WAFの動作確認①：マネージドルールの動作確認 WAF Web ACL が関連付けられた状態の ALB にリク エス トを送ってみます。 ボディに何も含まれていない POST リク エス トは、ブロックされることなく ALB に設定した固定レスポンスが返ってきます。 しかしリク エス トボディに「 localhost 」を含めると、WAF にブロックされ 403 が返されます。 個別ルールのアクションのオーバーライド EC2MetaDataSSRF_BODY ルールのアクションを Count にオーバーライドし、リク エス トボディに「 localhost 」があってもブロックされないようにしていきます。 先ほど作成した WAF Web ACL に追加したマネージドルールをチェックし、「Edit」を選択 EC2MetaDataSSRF_BODY ルールアクションを Override to Count に変更し、「Save rule」をクリック 次の画面でも「Save」をクリック WAFの動作確認②：マネージドルール無効化の確認 再びリク エス トボディに「 localhost 」を含めるリク エス トを送信すると、今度はブロックされずに固定レスポンスが返ってきます。 現在、あらゆる状況において EC2MetaDataSSRF_BODY ルールによるブロックが無効化されている状態です。次のステップからは「 URI パスが /api/ から始まる場合に限り、ブロックを無効化する」ようにカスタマイズしていきます。 自作ルールの追加 「Add my own rules and rule groups」をクリック ビジュアルエディタで次のように Statement を組み立て、「Add rule」をクリック 優先順位がマネージドルールグループよりも後ろであることを確認し、「Save」をクリック WAFの動作確認③：自作ルールの確認 再びリク エス トボディに「 localhost 」を含めるリク エス トを送信すると、今度はブロックされました。 しかし、リク エス ト URI を「/ api /hello」とすると、ブロックされずに通過しました。 以上で、マネージドルールグループの個別ルールに条件を追加することができました。 より複雑な条件の場合 以上はシンプルな条件について確認しましたが、条件が複雑な場合の自作ルールの組み方を簡単に説明します。例として以下の場合です。 マネージドルールグループの EC2MetaDataSSRF_BODY ルールと GenericLFI_BODY ルールを対象にしたい リク エス トがこれらのルールに一致した場合、「リク エス ト URI が /api/* 」かつ「 content-type ヘッダーが application/json 」の場合はブロックされないようにしたい。それ以外の場合はブロックしたい このような自作ルールは次のように実現できます。 今のところ AND 条件や OR 条件が多重になるルールはビジュアルエディタで作成できませんので、 JSON エディタに切り替えてルールを編集することになります。 例に示した複雑な条件の自作ルールは、以下のような JSON で作れます。 { " Name ": " custom-body-block ", " Priority ": 1 , " Statement ": { " AndStatement ": { " Statements ": [ { " OrStatement ": { " Statements ": [ { " LabelMatchStatement ": { " Scope ": " LABEL ", " Key ": " awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_Body " } } , { " LabelMatchStatement ": { " Scope ": " LABEL ", " Key ": " awswaf:managed:aws:core-rule-set:GenericLFI_Body " } } ] } } , { " NotStatement ": { " Statement ": { " AndStatement ": { " Statements ": [ { " ByteMatchStatement ": { " SearchString ": " /api/ ", " FieldToMatch ": { " UriPath ": {} } , " TextTransformations ": [ { " Priority ": 0 , " Type ": " NONE " } ] , " PositionalConstraint ": " STARTS_WITH " } } , { " ByteMatchStatement ": { " SearchString ": " application/json ", " FieldToMatch ": { " SingleHeader ": { " Name ": " content-type " } } , " TextTransformations ": [ { " Priority ": 0 , " Type ": " NONE " } ] , " PositionalConstraint ": " EXACTLY " } } ] } } } } ] } } , " Action ": { " Block ": {} } , " VisibilityConfig ": { " SampledRequestsEnabled ": true , " CloudWatchMetricsEnabled ": true , " MetricName ": " custom-body-block " } } さいごに AWS WAF マネージドルールグループの個別ルールの適用条件を、ラベルと自作ルールを使ってカスタマイズする方法を試しました。最初は難しそうに見えるかもしれませんが、理屈を理解すると柔軟にマネージドルールをカスタマイズできるようになるので、 AWS WAF をより使いこなしたい方はぜひ試してみてください。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @kou.kinyo 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは！金融ソリューション事業部の孫です。 現在、我々はChatGPT全般の活用を積極的に検討しており、その多様な可能性の中には メタバース におけるChatGPTの利用も含まれています。 この観点から、 AWS 上にサーバーレス アーキテクチャ を採用したChatGPT活用アプリケーションの設計と構築を実施いたしました。 はじめに インフラストラクチャの全体像 実装手順 構築手順 事前準備 手順1. Lambda関数の作成 手順2. DynamoDBの作成 手順3. WebSocket API Gatewayの作成 手順4. SNSトピックの作成 機能検証 セッションテスト 複数のクライアントが同時にセッションを持つテスト 終わりに はじめに ChatGPTベースのアプリケーションを構築する際には、2つの一般的な選択肢があります。 一つは既存のアプリケーションにOpenAI API を直接統合すること、もう一つはOpenAI API をラップしてインフラサービス化にすることです。 今回は、以下の点を考慮して、後者の選択をしました： セキュリティリスク：アプリケーション側でOpenAI API Keyを管理する必要があること コスト管理：OpenAIとのやり取りは有料で、ユーザーの質問の頻度と単語数を制御する必要があること 再利用可能性：開発したソリューションは他のプロジェクトに適用可能で、コストを節約できること 今回は、インフラスト ラク チャを設計する前に、以下の要件を明確にしました： 複数のユーザーが同時に一つのOpenAIアカウントを使用できること 従量課金制を実装し、コストを削減すること サーバーの維持コストを削減すること API トラフィック 制御を実装すること OpenAIへのリク エス トの同時実行数を制限すること これらの要件に基づいて、今回は以下のインフラスト ラク チャ設計を完成させました。 インフラスト ラク チャの全体像 本記事では、下記の構成図に基づき、構築作業を進めていきます。 WebSocket API Gateway ：クライアントのリク エス トをバックエンドサービスにルーティングするために使用します。 API リク エス トの トラフィック 制御ができます HTTPの30秒の タイムアウト 制限を解決し、503エラーを減らすために、WebSocket接続方式を選択しました meta_connect_handler ：ユーザーの認証機能を提供します。 本記事では、インフラ構築に焦点を当てるため、認証に関する実装は対象外としております meta_handler_chat ：ユーザーのリク エス トを Amazon SNS サービスに転送する機能を提供します。 ユーザーのリク エス トは SNS を介して処理されるため、OpenAIサーバーへの即時リク エス トが不要となり、非同期処理になります meta_chat ：ユーザーからのリク エス トをOpenAIサーバーに送信し、その結果を受け取る機能を提供します。 本記事においては、 LangChain （version: 0.0.317） フレームワーク を活用して、OpenAI API を介してOpenAIとのやり取りを行います LangChain フレームワーク を使用することで、OpenAI API を直接利用することなく、LLM（Large Language Models）アプリケーションの開発を高速化できます ただし、LangChainのバージョン更新は頻繁に行われるため、本記事で使用している API が将来的に非推奨（deprecated）になる可能性にご注意ください。そのため、特定のバージョンを固定することをお勧めします。 meta_disconnect_handler ：ユーザーがログアウトした後、その会話履歴を削除する機能を提供します。 Dynamodb ：ユーザーの会話履歴を保存するテーブルを作成します。 SNS ：ユーザーのリク エス トを非同期に処理するために使用します。 上記の AWS アーキテクチャ 図に記載した番号①〜⑨に沿って、処理の流れを説明します。 ①： ユーザーはWebSocket URL接続を介してChatGPTサービスの利用を開始する ②： 接続は最初にWebSocketのデフォルトの /$Connect ルートにルーティングされ、 meta_connect_handler で接続の認証を実施する ③： ユーザーは /sendprompt ルートを通じてチャット内容を meta_handler_chat に送信する ④： meta_handler_chat が処理した後、ユーザーリク エス トは SNS サービスのトピックに送信する ⑤： SNS はユーザーリク エス トを サブスクリプション meta_chat Functionに送信する ⑥： meta_chat は Langchain を利用し、OpenAIとの対話機能をそろえ、会話の文脈はDynamoDBに保存される ⑦： OpenAIサーバーは質問回答を返し、WebSocket接続を介してユーザーに返却する ⑧： ユーザーがLogoutしたら、 /$disconnect ルートがトリガーされる ⑨： meta_disconnect_handler はDynamoDBのユーザー会話の文脈を削除し、プロセスが終了する 実装手順 構築手順 以下の手順で構築を行います。 Lambda関数の作成 DynamoDBの作成 WebSocket API Gateway の作成 SNS トピックの作成 事前準備 NodeJS開発環境のセットアップ ローカルに Node.js をダウンロードしてインストールします（18.xバージョンを推奨） 本記事で提供されたコードは、Lambdaにコピーすることでそのまま クラウド 環境でビルド・運用が可能です ただし、後述するLangChainレイヤーの作成プロセスにおいてローカル環境でLangChainパッケージをダウンロードする必要があり、その際にはNodeJS環境が使用されることにご注意ください AWS アカウントの作成 AWS アカウントを持っている場合は、対応不要です AWS アカウントをお持ちでない場合は、 カウント作成の流れ を参考に、アカウントを作成してください ※本検証を行う場合、使用する AWS リソースの利用料金が発生する点にご注意ください OpenAIアカウントの作成 OpenAI API のアカウントを作成し API KEYを入手します API KEYの発行手順は こちら を参照してください 手順1. Lambda関数の作成 meta_connect_handler AWS Lambdaコンソールで meta_connect_handler という名前のLambda関数を作成し、ランタイムとしてNode.js 18.xを選択します。 ※上述した通り、本記事ではインフラ構築に焦点を当てるため、認証に関する実装は対象外です。デフォルトで生成されたコードをそのまま使用してください。 meta_handler_chat 上記と同様に AWS Lambdaコンソールで meta_handler_chat という名前のLambda関数を作成します。 この関数はユーザーリク エス トを受け取り、 SNS サービスのトピックに送信する役割を果たします。 この関数に SNS のPublic権限を追加し、 環境変数 で SNS のARN値（ SNS_TOPIC_ARN ）を設定してください。 具体的な実装コードは以下のとおりで、ユーザーのメッセージ( event.body.user_msg )を取得し、ユーザー接続情報とメッセージ内容を含む SNS のトピックを発行します。 // aws-sdkパッケージをインポートします import { SNSClient, PublishCommand } from "@aws-sdk/client-sns"; const client = new SNSClient(); const topicArn = process.env.SNS_TOPIC_ARN; export const handler = async(event) => { let body; if (typeof event.body === 'string') { body = JSON.parse(event.body); } else { body = event.body; } // ユーザー接続情報とメッセージ内容を含むSNSのトピックを発行します const command = new PublishCommand({ TopicArn:topicArn, Message:JSON.stringify({ requestContext:event.requestContext, payload: body.user_msg, }) }); let response; try{ await client.send(command); }catch (error) { console.log("Error:", JSON.stringify(error)); } }; meta_chat 同様な手順で AWS Lambdaコンソールで meta_chat という名前のLambda関数を作成します。 この関数はLangchainを使用してOpenAIサーバーとのインタ ラク ションする役割を果たします。 DynamoDBおよびAPIGatewayへのアクセス権限を追加し、OpenAI API KEYを 環境変数 として設定してください。 また、Lambdaではlangchainパッケージがないため、ローカルでダウンロードし、Layerとして関数にアップロードする必要があります。 具体的な手順は以下のとおりです： ローカルで npm install langchain を実行し、langchainをインストールします。 生成された node_module フォルダをZIPのパッケージ化します。 ZIPファイルをLayerにアップロードし、関数でlayer依存関係を設定します。 注意：OpenAIサービスの実行時間は3秒を超える可能性があるため、関数の実行時間設定を調整し(3秒 → 1分 )、 タイムアウト の問題を回避してください。 「コード」タブにて、下記のコードをコピーしてください。 // Langchainとaws-sdkパッケージをインポートします import { ChatOpenAI } from "langchain/chat_models/openai"; import { ConversationChain } from "langchain/chains"; import { BufferMemory } from "langchain/memory"; import { DynamoDBChatMessageHistory } from "langchain/stores/message/dynamodb"; import { ApiGatewayManagementApiClient, PostToConnectionCommand } from "@aws-sdk/client-apigatewaymanagementapi"; export const handler = async (event) => { console.log(JSON.stringify(event)); const body = JSON.parse(event.Records[0].Sns.Message); //SNSのトピックから必要な情報（クライアントの接続情報、ユーザーの質問内容のpayload）を読み取ります const requestContext = body.requestContext; const connectionId = requestContext.connectionId; const user_request = body.payload; // apigateway クライアントの初期化 const apigateway_client = new ApiGatewayManagementApiClient({ endpoint: 'https://'+requestContext.domainName + '/' + requestContext.stage, }); 　// 文脈保存先としてのDynamoDBを設定し、DynamoDBChatMessageHistoryを初期化します const chatHistory = new DynamoDBChatMessageHistory({ tableName: "Conversations", partitionKey: "ConnectionId", sessionId: connectionId, config: { region: "ap-northeast-1", }, }); // const memory = new BufferMemory({ chatHistory: chatHistory, }); // OpenAI model の初期化 const model = new ChatOpenAI({ modelName: "gpt-3.5-turbo", temperature: 0.5 }); // 初期化されたメモリおよびモデルを利用して、ConversationChainを初期化します。 const chain = new ConversationChain({ memory: memory, llm: model, verbose: true }); try { // OpenAIサーバーにリクエストを送信します const response = await chain.call({ input: user_request, }); // OpenAIからの回答を受け取り、それをクライアントに返却します const api_gateway_input = { ConnectionId: connectionId, Data: JSON.stringify(response) }; 　　 const command = new PostToConnectionCommand(api_gateway_input); await apigateway_client.send(command); } catch (error) { console.log("Error:", JSON.stringify(error)); } }; meta_disconnect_handler meta_disconnect_handler という名前のLambda関数を作成し、主にユーザーの会話履歴をクリアするために使用されます。 meta_chat と同様に、DynamoDBへのアクセス権限を追加してください。 具体的なコードは以下のとおりです。 // Langchainパッケージをインポートします import { BufferMemory } from "langchain/memory"; import { DynamoDBChatMessageHistory } from "langchain/stores/message/dynamodb"; export const handler = async (event) => { console.log(JSON.stringify(event)); const requestContext = event.requestContext; const connectionId = requestContext.connectionId; const chatHistory = new DynamoDBChatMessageHistory({ tableName: "Conversations", partitionKey: "ConnectionId", sessionId: connectionId, config: { region: "ap-northeast-1", }, }); const memory = new BufferMemory({ chatHistory: chatHistory, }); //DynamoDBから該当するユーザーの会話文脈を削除します await memory.chatHistory.clear(); }; 手順2. DynamoDBの作成 AWS 管理コンソール上で Amazon DynamoDB コンソールを開き、 Conversations という名前のテーブルと パーティション キーを ConnectionId に設定します。 通常、 パーティション キーはユーザーIDにすべきですが、今回ではログイン機能がないため、クライアント接続IDを パーティション キーとして使用します。 手順3. WebSocket API Gateway の作成 コンソールからWebSocket API Gateway を作成します。 ルーティングキー $connect 、 $disconnect 、および sendprompt を追加します。 Lambda関数の統合をそれぞれ設定します。 WebSocket URL( wss ://)を記録します。 手順4. SNS トピックの作成 標準の SNS トピックを作成します。 サブスクリプション を作成し、ポリシーのフィールドでlambdaを選択し、 meta_chat のARNリンクをエンドポイントのフィールドに貼り付けます。 SNS トピックARNをコピーし、 lambda_handle_chat の 環境変数 SNS_TOPIC_ARN の値に貼り付けます。 機能検証 セッションテスト wscatツールのインストール npm install -g wscat を実行し、wscatツールをインストールします。これは AWS が提供するWebSocket API をテストするツールです。 参考資料 。 WebSocket URLへの接続 以下のコマンドを使用して API Gateway に接続します： wscat -c 「WebSocket URL(wss://)」 セッションの開始 質問1「what is your name?」および質問2「What did I ask you just now?」に対する回答の関連性を確認します（文脈確認）。 DynamoDBのデータを確認 DynamoDBで会話履歴を確認します。 セッションの終了 [ctrl + c]を押してセッションを終了し、再度DynamoDBを確認して、以前のセッション記録が削除されたことを確認します。 複数のクライアントが同時にセッションを持つテスト 2つのクライアントで実施している会話がそれぞれ独立して行われることを確認するためのシミュレーションを行います。 終わりに この記事では、 AWS 上でChatGPTベースのインフラスト ラク チャの設計および構築について取り上げました。 今後、本インフラ構成において以下の点についてさらなる改善を行う予定です。 OpenAIのアクセスキーを保護するために AWS Secret Serviceを使用します ユーザー数が増えるにつれて、OpenAIの使用制限に達した場合に備えて、シームレスなアカウント切り替えを実装します より正確な回答を提供するためにVectorDBを統合することを検討しています より対話型のユーザーエクス ペリエ ンスを提供するために、ストリーミング応答モデルに移行します これからもChatGPTの応用シナリオについてさらに探求し、その結果をAIに興味を持つ読者と継続的に共有し続ける予定です。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 執筆： @chen.sun 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは！金融ソリューション事業部の孫です。 現在、我々はChatGPT全般の活用を積極的に検討しており、その多様な可能性の中には メタバース におけるChatGPTの利用も含まれています。 この観点から、 AWS 上にサーバーレス アーキテクチャ を採用したChatGPT活用アプリケーションの設計と構築を実施いたしました。 はじめに インフラストラクチャの全体像 実装手順 構築手順 事前準備 手順1. Lambda関数の作成 手順2. DynamoDBの作成 手順3. WebSocket API Gatewayの作成 手順4. SNSトピックの作成 機能検証 セッションテスト 複数のクライアントが同時にセッションを持つテスト 終わりに はじめに ChatGPTベースのアプリケーションを構築する際には、2つの一般的な選択肢があります。 一つは既存のアプリケーションにOpenAI API を直接統合すること、もう一つはOpenAI API をラップしてインフラサービス化にすることです。 今回は、以下の点を考慮して、後者の選択をしました： セキュリティリスク：アプリケーション側でOpenAI API Keyを管理する必要があること コスト管理：OpenAIとのやり取りは有料で、ユーザーの質問の頻度と単語数を制御する必要があること 再利用可能性：開発したソリューションは他のプロジェクトに適用可能で、コストを節約できること 今回は、インフラスト ラク チャを設計する前に、以下の要件を明確にしました： 複数のユーザーが同時に一つのOpenAIアカウントを使用できること 従量課金制を実装し、コストを削減すること サーバーの維持コストを削減すること API トラフィック 制御を実装すること OpenAIへのリク エス トの同時実行数を制限すること これらの要件に基づいて、今回は以下のインフラスト ラク チャ設計を完成させました。 インフラスト ラク チャの全体像 本記事では、下記の構成図に基づき、構築作業を進めていきます。 WebSocket API Gateway ：クライアントのリク エス トをバックエンドサービスにルーティングするために使用します。 API リク エス トの トラフィック 制御ができます HTTPの30秒の タイムアウト 制限を解決し、503エラーを減らすために、WebSocket接続方式を選択しました meta_connect_handler ：ユーザーの認証機能を提供します。 本記事では、インフラ構築に焦点を当てるため、認証に関する実装は対象外としております meta_handler_chat ：ユーザーのリク エス トを Amazon SNS サービスに転送する機能を提供します。 ユーザーのリク エス トは SNS を介して処理されるため、OpenAIサーバーへの即時リク エス トが不要となり、非同期処理になります meta_chat ：ユーザーからのリク エス トをOpenAIサーバーに送信し、その結果を受け取る機能を提供します。 本記事においては、 LangChain （version: 0.0.317） フレームワーク を活用して、OpenAI API を介してOpenAIとのやり取りを行います LangChain フレームワーク を使用することで、OpenAI API を直接利用することなく、LLM（Large Language Models）アプリケーションの開発を高速化できます ただし、LangChainのバージョン更新は頻繁に行われるため、本記事で使用している API が将来的に非推奨（deprecated）になる可能性にご注意ください。そのため、特定のバージョンを固定することをお勧めします。 meta_disconnect_handler ：ユーザーがログアウトした後、その会話履歴を削除する機能を提供します。 Dynamodb ：ユーザーの会話履歴を保存するテーブルを作成します。 SNS ：ユーザーのリク エス トを非同期に処理するために使用します。 上記の AWS アーキテクチャ 図に記載した番号①〜⑨に沿って、処理の流れを説明します。 ①： ユーザーはWebSocket URL接続を介してChatGPTサービスの利用を開始する ②： 接続は最初にWebSocketのデフォルトの /$Connect ルートにルーティングされ、 meta_connect_handler で接続の認証を実施する ③： ユーザーは /sendprompt ルートを通じてチャット内容を meta_handler_chat に送信する ④： meta_handler_chat が処理した後、ユーザーリク エス トは SNS サービスのトピックに送信する ⑤： SNS はユーザーリク エス トを サブスクリプション meta_chat Functionに送信する ⑥： meta_chat は Langchain を利用し、OpenAIとの対話機能をそろえ、会話の文脈はDynamoDBに保存される ⑦： OpenAIサーバーは質問回答を返し、WebSocket接続を介してユーザーに返却する ⑧： ユーザーがLogoutしたら、 /$disconnect ルートがトリガーされる ⑨： meta_disconnect_handler はDynamoDBのユーザー会話の文脈を削除し、プロセスが終了する 実装手順 構築手順 以下の手順で構築を行います。 Lambda関数の作成 DynamoDBの作成 WebSocket API Gateway の作成 SNS トピックの作成 事前準備 NodeJS開発環境のセットアップ ローカルに Node.js をダウンロードしてインストールします（18.xバージョンを推奨） 本記事で提供されたコードは、Lambdaにコピーすることでそのまま クラウド 環境でビルド・運用が可能です ただし、後述するLangChainレイヤーの作成プロセスにおいてローカル環境でLangChainパッケージをダウンロードする必要があり、その際にはNodeJS環境が使用されることにご注意ください AWS アカウントの作成 AWS アカウントを持っている場合は、対応不要です AWS アカウントをお持ちでない場合は、 カウント作成の流れ を参考に、アカウントを作成してください ※本検証を行う場合、使用する AWS リソースの利用料金が発生する点にご注意ください OpenAIアカウントの作成 OpenAI API のアカウントを作成し API KEYを入手します API KEYの発行手順は こちら を参照してください 手順1. Lambda関数の作成 meta_connect_handler AWS Lambdaコンソールで meta_connect_handler という名前のLambda関数を作成し、ランタイムとしてNode.js 18.xを選択します。 ※上述した通り、本記事ではインフラ構築に焦点を当てるため、認証に関する実装は対象外です。デフォルトで生成されたコードをそのまま使用してください。 meta_handler_chat 上記と同様に AWS Lambdaコンソールで meta_handler_chat という名前のLambda関数を作成します。 この関数はユーザーリク エス トを受け取り、 SNS サービスのトピックに送信する役割を果たします。 この関数に SNS のPublic権限を追加し、 環境変数 で SNS のARN値（ SNS_TOPIC_ARN ）を設定してください。 具体的な実装コードは以下のとおりで、ユーザーのメッセージ( event.body.user_msg )を取得し、ユーザー接続情報とメッセージ内容を含む SNS のトピックを発行します。 // aws-sdkパッケージをインポートします import { SNSClient, PublishCommand } from "@aws-sdk/client-sns"; const client = new SNSClient(); const topicArn = process.env.SNS_TOPIC_ARN; export const handler = async(event) => { let body; if (typeof event.body === 'string') { body = JSON.parse(event.body); } else { body = event.body; } // ユーザー接続情報とメッセージ内容を含むSNSのトピックを発行します const command = new PublishCommand({ TopicArn:topicArn, Message:JSON.stringify({ requestContext:event.requestContext, payload: body.user_msg, }) }); let response; try{ await client.send(command); }catch (error) { console.log("Error:", JSON.stringify(error)); } }; meta_chat 同様な手順で AWS Lambdaコンソールで meta_chat という名前のLambda関数を作成します。 この関数はLangchainを使用してOpenAIサーバーとのインタ ラク ションする役割を果たします。 DynamoDBおよびAPIGatewayへのアクセス権限を追加し、OpenAI API KEYを 環境変数 として設定してください。 また、Lambdaではlangchainパッケージがないため、ローカルでダウンロードし、Layerとして関数にアップロードする必要があります。 具体的な手順は以下のとおりです： ローカルで npm install langchain を実行し、langchainをインストールします。 生成された node_module フォルダをZIPのパッケージ化します。 ZIPファイルをLayerにアップロードし、関数でlayer依存関係を設定します。 注意：OpenAIサービスの実行時間は3秒を超える可能性があるため、関数の実行時間設定を調整し(3秒 → 1分 )、 タイムアウト の問題を回避してください。 「コード」タブにて、下記のコードをコピーしてください。 // Langchainとaws-sdkパッケージをインポートします import { ChatOpenAI } from "langchain/chat_models/openai"; import { ConversationChain } from "langchain/chains"; import { BufferMemory } from "langchain/memory"; import { DynamoDBChatMessageHistory } from "langchain/stores/message/dynamodb"; import { ApiGatewayManagementApiClient, PostToConnectionCommand } from "@aws-sdk/client-apigatewaymanagementapi"; export const handler = async (event) => { console.log(JSON.stringify(event)); const body = JSON.parse(event.Records[0].Sns.Message); //SNSのトピックから必要な情報（クライアントの接続情報、ユーザーの質問内容のpayload）を読み取ります const requestContext = body.requestContext; const connectionId = requestContext.connectionId; const user_request = body.payload; // apigateway クライアントの初期化 const apigateway_client = new ApiGatewayManagementApiClient({ endpoint: 'https://'+requestContext.domainName + '/' + requestContext.stage, }); 　// 文脈保存先としてのDynamoDBを設定し、DynamoDBChatMessageHistoryを初期化します const chatHistory = new DynamoDBChatMessageHistory({ tableName: "Conversations", partitionKey: "ConnectionId", sessionId: connectionId, config: { region: "ap-northeast-1", }, }); // const memory = new BufferMemory({ chatHistory: chatHistory, }); // OpenAI model の初期化 const model = new ChatOpenAI({ modelName: "gpt-3.5-turbo", temperature: 0.5 }); // 初期化されたメモリおよびモデルを利用して、ConversationChainを初期化します。 const chain = new ConversationChain({ memory: memory, llm: model, verbose: true }); try { // OpenAIサーバーにリクエストを送信します const response = await chain.call({ input: user_request, }); // OpenAIからの回答を受け取り、それをクライアントに返却します const api_gateway_input = { ConnectionId: connectionId, Data: JSON.stringify(response) }; 　　 const command = new PostToConnectionCommand(api_gateway_input); await apigateway_client.send(command); } catch (error) { console.log("Error:", JSON.stringify(error)); } }; meta_disconnect_handler meta_disconnect_handler という名前のLambda関数を作成し、主にユーザーの会話履歴をクリアするために使用されます。 meta_chat と同様に、DynamoDBへのアクセス権限を追加してください。 具体的なコードは以下のとおりです。 // Langchainパッケージをインポートします import { BufferMemory } from "langchain/memory"; import { DynamoDBChatMessageHistory } from "langchain/stores/message/dynamodb"; export const handler = async (event) => { console.log(JSON.stringify(event)); const requestContext = event.requestContext; const connectionId = requestContext.connectionId; const chatHistory = new DynamoDBChatMessageHistory({ tableName: "Conversations", partitionKey: "ConnectionId", sessionId: connectionId, config: { region: "ap-northeast-1", }, }); const memory = new BufferMemory({ chatHistory: chatHistory, }); //DynamoDBから該当するユーザーの会話文脈を削除します await memory.chatHistory.clear(); }; 手順2. DynamoDBの作成 AWS 管理コンソール上で Amazon DynamoDB コンソールを開き、 Conversations という名前のテーブルと パーティション キーを ConnectionId に設定します。 通常、 パーティション キーはユーザーIDにすべきですが、今回ではログイン機能がないため、クライアント接続IDを パーティション キーとして使用します。 手順3. WebSocket API Gateway の作成 コンソールからWebSocket API Gateway を作成します。 ルーティングキー $connect 、 $disconnect 、および sendprompt を追加します。 Lambda関数の統合をそれぞれ設定します。 WebSocket URL( wss ://)を記録します。 手順4. SNS トピックの作成 標準の SNS トピックを作成します。 サブスクリプション を作成し、ポリシーのフィールドでlambdaを選択し、 meta_chat のARNリンクをエンドポイントのフィールドに貼り付けます。 SNS トピックARNをコピーし、 lambda_handle_chat の 環境変数 SNS_TOPIC_ARN の値に貼り付けます。 機能検証 セッションテスト wscatツールのインストール npm install -g wscat を実行し、wscatツールをインストールします。これは AWS が提供するWebSocket API をテストするツールです。 参考資料 。 WebSocket URLへの接続 以下のコマンドを使用して API Gateway に接続します： wscat -c 「WebSocket URL(wss://)」 セッションの開始 質問1「what is your name?」および質問2「What did I ask you just now?」に対する回答の関連性を確認します（文脈確認）。 DynamoDBのデータを確認 DynamoDBで会話履歴を確認します。 セッションの終了 [ctrl + c]を押してセッションを終了し、再度DynamoDBを確認して、以前のセッション記録が削除されたことを確認します。 複数のクライアントが同時にセッションを持つテスト 2つのクライアントで実施している会話がそれぞれ独立して行われることを確認するためのシミュレーションを行います。 終わりに この記事では、 AWS 上でChatGPTベースのインフラスト ラク チャの設計および構築について取り上げました。 今後、本インフラ構成において以下の点についてさらなる改善を行う予定です。 OpenAIのアクセスキーを保護するために AWS Secret Serviceを使用します ユーザー数が増えるにつれて、OpenAIの使用制限に達した場合に備えて、シームレスなアカウント切り替えを実装します より正確な回答を提供するためにVectorDBを統合することを検討しています より対話型のユーザーエクス ペリエ ンスを提供するために、ストリーミング応答モデルに移行します これからもChatGPTの応用シナリオについてさらに探求し、その結果をAIに興味を持つ読者と継続的に共有し続ける予定です。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 執筆： @chen.sun 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

皆さんこんにちは。グループ経営ソリューション事業部グループ経営 コンサルティング 第2ユニット一般会計 コンサルティング 部第2グループ（FAC２部）に所属している小林です。 FAC２部では自社製品である「Ci X (サイクロス)」という会計システムパッケージの新規開発・導入・保守を行っており、私は主にその保守業務を担当しています。 この記事ではISIDに興味をお持ちの就活生の方々向けに私がISIDに入社して初めて担当した業務から学んだことについて、自身の振り返りの意味も込めてご紹介したいと思います。 あと、Ci Xに関しては こちら も参考にしてみてください！ 自己紹介 まずは自己紹介いたします。 私は2022年に新卒入社し、半年の研修を経て、現在は2年目の勤務になります。 大学では院まで進学し、 放射線 系の研究をしていました。 そのままの進路でいくのならば、メーカー勤務や 原子力 関係の企業に就職するのが王道でした。 物理という学問は好きでしたし、研究室も自分で望んで所属しましたが、大学4年間で勉強した物理の理論を、研究室で応用することは少なく、愚直に地味な実験を繰り返す成果の見えない生活が率直に自分には合っていませんでした。そんな時にHP係を担当しまして、学べば学ぶほど、スキルが身に付くのを感じ、研究室のHPを管理したり、学会のHPを作成することが楽しかったのを覚えています。 ささいな理由ではありましたが、本当に自分のやりたいことって何だろうと考えた時に気づいたらIT業界を志すようになっていました。就活では上手くいかないことだらけでしたが、自分の率直な思いを面白いと聞いてくれたのがISIDで、IT経験が特にない私でも希望していた開発の部署に配属させてくれました。 そして現在、私は自社製品の保守業務からスタートしています。 配属されてから一年も経過はしていませんが、業務はかなり幅広いです。 今回はそれについて広く浅く紹介いたします。 保守の仕事内容について 保守業務のおおまかな流れは製品のリリース後、まず、お客様が製品を使用していて何かしらお問い合わせが生じた際にその旨を保守窓口が受け取り、保守チームに対応を要求します。そしてその後、保守チームは再現調査や原因究明を行って不具合かどうかを判断し、必要があれば設計を変更したり、中身の実装を修正したりして仕様変更対応を行い、テストをします。 以下では私が携わった範囲で担当した業務プロセスを私自身の所感も含めて説明します。 1．原因調査 トラブルシューティング の入り口になるプロセスです。起こってしまったトラブルに対して何が原因だったのか監査ログやシステムログなどを通して原因を探ります。 このプロセスはいざやってみるとどの工程の中でも直感とスキル、判断力が必要で、これを即座にできる人は保守としての力が特に強い人なのだと個人的に思っています。 2．設計 もし、仕様変更が必要な場合、設計を修正することがあります。欠陥修正に該当する設計書の内容を読み込んで画面定義やロジックなどどこを修正すべきなのか判断し、修正します。特にロジックが難しく、簿記の知識も絡む箇所もあるので、何度見返しても不明な部分に関しては先輩社員に聞きながら進めていました。 3．実装 上記の設計修正が完了したあと、その設計に基づいて実際に内部の実装も変更します。 実装で用いる技術要素は以下です。 バックエンド技術（ Java , Spring Boot, Thymeleaf, PostgreSQL 等） フロントエンド技術（ HTML5 、TypeScript、Vue.js 等） 業務は新卒の研修で学んだことが直接生きており、改めて研修の大切さを実感しました。 4．テスト 実装が完了した後はテストを行い、機能に問題がないか不具合チェックをします。直接変更してはいなくともその変更の影響を受けたところに対してバグが出てしまうこともあるため、機能のテストだけでなく、その周辺に関してもテストをします。配属直後はこのプロセスから携わり、Ci*Xがどういう機能を有しているのか学びながらこれらのテストを行っていました。 5．その他 上記以外にも SQL を更新したり、サーバーの管理者としての業務もあります。 SQL にはデータを定義する DDL やデータを操作する DML など種類がありますが、フォルダごとに配置され、一括して リポジトリ にまとめられています。 私はGitを使用してチームメンバーが編集や新規作成した SQL を更新しています。Gitの勉強にもなりますし、 SQL を取り込む際にエラーになることは多々あるので、 SQL の内容について考える機会も多いです。 また、Ci*Xのテスト環境は AWS で運用しており、アプリケーションが動作している環境は Amazon EC2 を使っています。チーム内から依頼されたサーバーの容量拡張や棚卸、新規作成、複製などの業務を担当しています。また、手動で行っていたこれらの業務も今は AWS CDK と GitHub Actionsを用いて ソースコード から自動で行えるように取り組んでいます。 AWS は未経験でしたが、触ってみると楽しいことも多く、 AWS Certified Cloud Practitioner という初級の資格を取りつつ、もっと知識を深めて業務に応用できたらいいなと思っています。 一日の流れ 毎朝、 Jira のチケットの進捗状況を確認します。 朝会終了後はチケットの作業に取り組むことが多いです。 隔週で勉強会があったり、毎週、一般会計 コンサルティング 部の方たちと雑談するような時間もあります。 配属当初は不明点を上司に相談できるような夕会の時間も設けてもらっていました。 FAC２部（保守業務）での働き方の特徴 配属前、開発は設計や実装などある程度の期間を設定し、段階を踏みながら業務を進めていくイメージを持っていましたが、保守業務の特徴は多種多様な角度から不具合の対処やテストを求められることが多く、内容の異なるチケットを抱えていることはよくあることなので、その点において配属直後から幅広い業務に携われていると感じています。 チケットも自分で選択しながら進められますし、先輩社員との1on1で業務やそれ以外に困っていることなどを適宜聞いてくれる場もありますので裁量を持って仕事させてもらえる環境だなと日々感じています。 また、基本的にテレワークがメインになります。出社する必要がないので、そういう点で気楽さを感じています。ただ、テレワークにおけるコミュニケーションはテキストやメールが主となるため、個人の文章力や読解力の差で情報伝達内容の認識に差異や時差が生じてしまったり、情報収集が必要最低限になることが多いなど、難しさも感じています。会議を設定して、あらかじめ質問をまとめ、限られた時間で情報収集する力が求められるなと日々感じています。 最後に 今回は、Ci*Xシリーズの保守業務の内容とその仕事や働き方の特徴についてお伝えしました。 テクニカルな話題が多い中で、少し異色なブログではありましたが、いかがでしたか？ 保守業務は様々な角度から問題点が切り込まれるので大変な思いをすることもたくさんありますが、その分、身につくスキルは多いと思います。 これを見てくださっている就活生のみなさんとも共に仕事ができたらなと思います！ ありがとうございました！ www.isid.co.jp 執筆： @kobayashi.shun 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

皆さんこんにちは。グループ経営ソリューション事業部グループ経営 コンサルティング 第2ユニット一般会計 コンサルティング 部第2グループ（FAC２部）に所属している小林です。 FAC２部では自社製品である「Ci X (サイクロス)」という会計システムパッケージの新規開発・導入・保守を行っており、私は主にその保守業務を担当しています。 この記事ではISIDに興味をお持ちの就活生の方々向けに私がISIDに入社して初めて担当した業務から学んだことについて、自身の振り返りの意味も込めてご紹介したいと思います。 あと、Ci Xに関しては こちら も参考にしてみてください！ 自己紹介 まずは自己紹介いたします。 私は2022年に新卒入社し、半年の研修を経て、現在は2年目の勤務になります。 大学では院まで進学し、 放射線 系の研究をしていました。 そのままの進路でいくのならば、メーカー勤務や 原子力 関係の企業に就職するのが王道でした。 物理という学問は好きでしたし、研究室も自分で望んで所属しましたが、大学4年間で勉強した物理の理論を、研究室で応用することは少なく、愚直に地味な実験を繰り返す成果の見えない生活が率直に自分には合っていませんでした。そんな時にHP係を担当しまして、学べば学ぶほど、スキルが身に付くのを感じ、研究室のHPを管理したり、学会のHPを作成することが楽しかったのを覚えています。 ささいな理由ではありましたが、本当に自分のやりたいことって何だろうと考えた時に気づいたらIT業界を志すようになっていました。就活では上手くいかないことだらけでしたが、自分の率直な思いを面白いと聞いてくれたのがISIDで、IT経験が特にない私でも希望していた開発の部署に配属させてくれました。 そして現在、私は自社製品の保守業務からスタートしています。 配属されてから一年も経過はしていませんが、業務はかなり幅広いです。 今回はそれについて広く浅く紹介いたします。 保守の仕事内容について 保守業務のおおまかな流れは製品のリリース後、まず、お客様が製品を使用していて何かしらお問い合わせが生じた際にその旨を保守窓口が受け取り、保守チームに対応を要求します。そしてその後、保守チームは再現調査や原因究明を行って不具合かどうかを判断し、必要があれば設計を変更したり、中身の実装を修正したりして仕様変更対応を行い、テストをします。 以下では私が携わった範囲で担当した業務プロセスを私自身の所感も含めて説明します。 1．原因調査 トラブルシューティング の入り口になるプロセスです。起こってしまったトラブルに対して何が原因だったのか監査ログやシステムログなどを通して原因を探ります。 このプロセスはいざやってみるとどの工程の中でも直感とスキル、判断力が必要で、これを即座にできる人は保守としての力が特に強い人なのだと個人的に思っています。 2．設計 もし、仕様変更が必要な場合、設計を修正することがあります。欠陥修正に該当する設計書の内容を読み込んで画面定義やロジックなどどこを修正すべきなのか判断し、修正します。特にロジックが難しく、簿記の知識も絡む箇所もあるので、何度見返しても不明な部分に関しては先輩社員に聞きながら進めていました。 3．実装 上記の設計修正が完了したあと、その設計に基づいて実際に内部の実装も変更します。 実装で用いる技術要素は以下です。 バックエンド技術（ Java , Spring Boot, Thymeleaf, PostgreSQL 等） フロントエンド技術（ HTML5 、TypeScript、Vue.js 等） 業務は新卒の研修で学んだことが直接生きており、改めて研修の大切さを実感しました。 4．テスト 実装が完了した後はテストを行い、機能に問題がないか不具合チェックをします。直接変更してはいなくともその変更の影響を受けたところに対してバグが出てしまうこともあるため、機能のテストだけでなく、その周辺に関してもテストをします。配属直後はこのプロセスから携わり、Ci*Xがどういう機能を有しているのか学びながらこれらのテストを行っていました。 5．その他 上記以外にも SQL を更新したり、サーバーの管理者としての業務もあります。 SQL にはデータを定義する DDL やデータを操作する DML など種類がありますが、フォルダごとに配置され、一括して リポジトリ にまとめられています。 私はGitを使用してチームメンバーが編集や新規作成した SQL を更新しています。Gitの勉強にもなりますし、 SQL を取り込む際にエラーになることは多々あるので、 SQL の内容について考える機会も多いです。 また、Ci*Xのテスト環境は AWS で運用しており、アプリケーションが動作している環境は Amazon EC2 を使っています。チーム内から依頼されたサーバーの容量拡張や棚卸、新規作成、複製などの業務を担当しています。また、手動で行っていたこれらの業務も今は AWS CDK と GitHub Actionsを用いて ソースコード から自動で行えるように取り組んでいます。 AWS は未経験でしたが、触ってみると楽しいことも多く、 AWS Certified Cloud Practitioner という初級の資格を取りつつ、もっと知識を深めて業務に応用できたらいいなと思っています。 一日の流れ 毎朝、 Jira のチケットの進捗状況を確認します。 朝会終了後はチケットの作業に取り組むことが多いです。 隔週で勉強会があったり、毎週、一般会計 コンサルティング 部の方たちと雑談するような時間もあります。 配属当初は不明点を上司に相談できるような夕会の時間も設けてもらっていました。 FAC２部（保守業務）での働き方の特徴 配属前、開発は設計や実装などある程度の期間を設定し、段階を踏みながら業務を進めていくイメージを持っていましたが、保守業務の特徴は多種多様な角度から不具合の対処やテストを求められることが多く、内容の異なるチケットを抱えていることはよくあることなので、その点において配属直後から幅広い業務に携われていると感じています。 チケットも自分で選択しながら進められますし、先輩社員との1on1で業務やそれ以外に困っていることなどを適宜聞いてくれる場もありますので裁量を持って仕事させてもらえる環境だなと日々感じています。 また、基本的にテレワークがメインになります。出社する必要がないので、そういう点で気楽さを感じています。ただ、テレワークにおけるコミュニケーションはテキストやメールが主となるため、個人の文章力や読解力の差で情報伝達内容の認識に差異や時差が生じてしまったり、情報収集が必要最低限になることが多いなど、難しさも感じています。会議を設定して、あらかじめ質問をまとめ、限られた時間で情報収集する力が求められるなと日々感じています。 最後に 今回は、Ci*Xシリーズの保守業務の内容とその仕事や働き方の特徴についてお伝えしました。 テクニカルな話題が多い中で、少し異色なブログではありましたが、いかがでしたか？ 保守業務は様々な角度から問題点が切り込まれるので大変な思いをすることもたくさんありますが、その分、身につくスキルは多いと思います。 これを見てくださっている就活生のみなさんとも共に仕事ができたらなと思います！ ありがとうございました！ www.isid.co.jp 執筆： @kobayashi.shun 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS WAF は簡単に Web アプリに WAF を追加でき、かつ値段も他の WAF 製品より安いため、好きな AWS サービスの一つです。そんな AWS WAF ですがしばらく構築・運用し、これを最初から知っておけば・・・と思ったことがあるので 8つご紹介します。 AWS WAF の基本については分かっている前提で、特に説明はいたしません。また2023年10月現在の最新バージョンである、いわゆる「 AWS WAF v2」を対象としています。 その1: AWS マネージドルールのボディサイズ制限が厳しい その2: ファイルアップロードが AWS マネージドルールの XSS に引っかかることがある その3: マネージドルールにはバージョンがある その4: CloudWatch Logs のロググループ名に決まりがある その5: 35個のログストリームに分割される その6: ログに Cookie ヘッダーが記録されてしまう その7: ログ出力条件の EXCLUDED_AS_COUNT とは何か その8: コンソールで作成したルールを JSON 出力すると IaC での書き方がわかる さいごに その1: AWS マネージドルールのボディサイズ制限が厳しい AWS WAF を利用する際に AWS マネージドルール はとても便利です。その中の コアルールセット (CRS) マネージドルールグループ には SizeRestrictions_BODY というリク エス トボディのサイズを検査するルールがあり、 8 KB を超えるボディを持つリク エス トをブロック します。 ボディサイズが大きいリク エス トや、ファイルアップロードにおいては 8 KB を簡単に超えてしまう ことがあるので、本番環境に導入する前に想定するサイズのリク エス トがブロックされないかしっかりテストが必要です。 ※このようなルールが設定されている理由は、 AWS WAF は リクエストボディの最初の 8 KB しか検査できない という制約があるためです。リク エス トボディの 8 KB 以降の位置に攻撃文字列が含まれていても検査できないため、コアルールセットでは 8 KB を超えるリク エス トを一律でブロックすることで対応しています。 想定する正当なリク エス トが 8 KB を超えてしまう場合、ルールグループ内の SizeRestrictions_BODY ルールのアクションを「Count」にオーバーライドすることで、実質的に除外することができます。ただしボディサイズ制限が全くないのは心許ないので、次のように WAF Web ACL を作ることが考えられます。 コアルールセットマネージドルールグループでは SizeRestrictions_BODY を「Count」にオーバーライドする 適切な値でボディサイズ制限を行う独自ルールを作成する このようなルールを複数作り、リク エス トパスに応じて異なるボディサイズの 閾値 を設定することも可能です（例えばファイルアップロードを受け付ける URI パスに対しては 100 KB に制限し、それ以外の URI パスに対しては 8 KB に制限するなど） ボディサイズ制限の 閾値 を 8 KB より大きくする場合、前述の通り、それを超える部分のリク エス トボディの中身は他のルールでも検査されないことに留意してください なお、re:Post の次の投稿でも SizeRestrictions_BODY でブロックされた場合の対応方法が記載されています。マネージドルールに一致した際に追加されるラベルと独自ルールを組み合わせて、特定の URI パス（=ファイルアップロードを行う URI パス）ではない場合のみブロックを発動させる方法です。 AWS WAF によってブロックされているファイルをアップロードするにはどうすればよいですか? https://repost.aws/ja/knowledge-center/waf-upload-blocked-files その2: ファイルアップロードが AWS マネージドルールの XSS に引っかかることがある Web アプリに対してバイナリファイルのアップロードをした時に、運悪く コアルールセット (CRS) マネージドルールグループ の CrossSiteScripting_BODY ルールに引っかかってしまったことがありました。そのときのログの一部は次の通りです。バイナリデータが XSS の シグネチャ に一致してしまったようです。 " terminatingRuleMatchDetails ": [ { " conditionType ": " XSS ", " location ": " BODY ", " matchedData ": [ " < ", " \u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000 " ] } ] , re:Post の次の投稿によると、 ファイルアップロードでは CrossSiteScripting_BODY 以外にも SQLi_BODY 、 WindowsShellCommands_BODY 、 GenericLFI_BODY 、 SizeRestrictions_BODY ルールによってブロックされる可能性がある ようです。 AWS WAF によってブロックされているファイルをアップロードするにはどうすればよいですか? https://repost.aws/ja/knowledge-center/waf-upload-blocked-files 投稿では対応方法として「文字列または 正規表現 ( regex ) 一致条件が設定されたセーフリストを使用して、リク エス トを許可します。」が紹介されています。マネージドルールに一致した際に追加されるラベルと独自ルールを組み合わせて、リク エス トボディに特定の文字列（ファイル拡張子などを想定していると解釈しました）が含まれていない場合のみブロックを発動する方法です。（注：日本語の投稿ではなぜかリク エス トヘッダーから特定の文字列を探すとありますが、 英語の投稿 ではリク エス トボディから探すと書いてあります。リク エス トボディの方がしっくりきています。） あるいは「その1」の SizeRestrictions_BODY の場合と同じように、特定の URI パス（=ファイルアップロードを行う URI パス）ではない場合のみブロックを発動させる方法を取っても良さそうです。 その3: マネージドルールにはバージョンがある マネジメントコンソールでマネージドルールを使っていたらすぐに気が付いたと思うのですが、筆者は CDK で Web ACL を作っていたのでずっと知りませんでした。 マネージドルールにはバージョンが存在します 。 （ AWS マネージドルールのうち「IP レピュテーション、 Bot Control、アカウント乗っ取り防止のルールグループ」にはバージョンが存在しません。バージョンに関わらず、日ごろから頻繁にルールが更新されるためでしょう。） バージョンを特に指定しない場合、そのマネージドルールがデフォルトと設定したバージョンが利用され、ルールプロバイダーがデフォルトバージョンを変更すると構築した Web ACL でも自動的に新しいバージョンに更新されます。自動的に更新されることを避けたい場合は、「静的バージョン」を明示的に指定します。ただしこの場合も、「緊急時の必須の更新」がされる可能性があるそうです。またバージョンの有効期限が切れると、次のような扱いになるようです。 AWS マネージドルールルールグループの場合、 AWS WAF は、有効期限切れのバージョンを使用しているウェブ ACL を、ルールグループのデフォルトバージョンに移動します。 AWS Marketplace ルールグループの場合、プロバイダーは有効期限の処理方法を決定します。詳細については、マネージドルールグループプロバイダーに問い合わせてください。 マネージドルールには SNS トピックが用意されている場合があり、サブスクライブすることでバージョンを含めたルールの更新情報を受け取ることができます。特に静的バージョンを使用する場合はルールバージョンを手動更新することになるので、 SNS トピックをサブスクライブしておくと良いでしょう。 その4: CloudWatch Logs のロググループ名に決まりがある AWS WAF を利用する場合はログをぜひ取っておきたいところですが、CloudWatch Logs に出力する場合、 ロググループ名は aws-waf-logs- で始まる必要があります 。 https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/logging-cw-logs.html#logging-cw-logs-naming マネジメントコンソールでロググループを指定する場合は画面にこの条件が書いてありますし、 aws-waf-logs- で始まるロググループ以外は選択肢に表示されないのでまだ分かりやすいです。 しかし CloudFormation （もちろん CDK も）を利用する場合、 aws-waf-logs- で始まるロググループ以外を Web ACL に関連付けしようとすると、デプロイ時に次のようなエラーになります。「ARN が有効でない」というエラーメッセージでは何がいけないのか全く分からず、どハマりしたことがあるのは自分だけではないはずです。 Resource handler returned message: "Error reason: The ARN isn't valid. A valid ARN begins with arn: and includes other information separated by colons or slashes., field: LOG_ DESTINATION , parameter: arn: aws :logs:ap-northeast-1:111122223333:log-group:waf-logs-xxxxx ちなみにログの出力先が S3 バケット の場合も、 バケット 名は aws-waf-logs- で始まる必要があります。 https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/logging-s3.html#logging-s3-naming その5: 35個のログストリームに分割される CloudWatch Logs にログを出力すると、 35個のログストリームに分割 され、この数を減らすことはできません 。出力の スループット を高めるためのようです。 近い時刻で発生したログメッセージでも、複数のログストリームに分散して出力されるため、ロググループから特定のログを探すのは難しいです。ログストリームを横断して時系列にログを見たり、特定のログを探したい場合は CloudWatch Logs Insights を利用するのが便利です。以下の公式ブログや re:Post 投稿が参考になります。 Amazon CloudWatch Logs による AWS WAF ログの分析 https://aws.amazon.com/jp/blogs/news/analyzing-aws-waf-logs-in-amazon-cloudwatch-logs/ CloudWatch または Amazon S3 に保存されている AWS WAF ログを分析するオプションは何ですか? https://repost.aws/ja/knowledge-center/waf-analyze-logs-stored-cloudwatch-s3 その6: ログに Cookie ヘッダーが記録されてしまう WAF Web ACL のログを出力すると、 httpRequest.headers フィールドにリク エス トヘッダーが記録されます。つまり、 クライアントが送信した Cookie も記録されてしまいます 。 （スクリーンキャプチャの値はダミーです） 例えば分析のためにログを出力したり、共有したりすると有効なセッション ID などセンシティブな情報が漏えいするリスクがあります。 この問題への対応として、ログ出力時に 特定フィールドをマスキング することが可能です。例えば cookie ヘッダーをマスキングするには次のように設定します。 このように設定すると、出力されるログの cookie ヘッダーは REDACTED という文字列に置き換えられます。 その7: ログ出力条件の EXCLUDED_AS_COUNT とは何か ログを出力する場合、アクションが特定の条件に該当する場合のみ出力するように設定できます。リク エス トが許可された場合のログも全て記録すると量が多くなってしまうので、「ブロック」時と「カウント」時のみ出力したいことがあります。 カウント時の条件は、実は COUNT と EXCLUDED_AS_COUNT の2種類があります 。基本的には COUNT 扱いと考えて良いですが、 EXCLUDED_AS_COUNT として扱われるケースが2つ、以下のブログで説明されています。 AWS WAF のログ分析に関する考慮事項 https://aws.amazon.com/jp/blogs/news/aws-waf-log-analysis-considerations/ マネージドルールグループで ”Set all rule actions to count” で Count に設定した場合 マネージドルールグループで個別のルールを Count に設定した場合 ただし上の AWS のブログは情報が古く、現在個別のルールを Count に設定した場合の動きは少々異なるようです（ 参照 ）。簡単にまとめると、以下のようになると理解しています： 2022 年 10 月 27 日より前に、 WAF ルールの JSON では ExcludedRules が利用でき、これに含めた個別ルールは EXCLUDED_AS_COUNT 扱いになる マネジメントコンソールで個別ルールを Count に設定すると、 EXCLUDED_AS_COUNT 扱いになる 2022 年 10 月 27 日以降は、 WAF ルールの JSON で ExcludedRules に含めた個別ルールは変わらず EXCLUDED_AS_COUNT 扱いになる WAF ルールの JSON で RuleActionOverrides が新しく利用でき、オーバーライド先をカウントにした場合は COUNT 扱いになる マネジメントコンソールで個別ルールを Count に設定（過去に作成したルールの編集も含めて）すると、 COUNT 扱いに変わる この動きを意識してログ出力条件を作成すると良いと思います。 その8: コンソールで作成したルールを JSON 出力すると IaC での書き方がわかる CloudFormation もしくは CDK で複雑な条件の Web ACL を作成する場合、書き方が分からずに困ることがあります。 例えば「 URI パスが /file/upload 以外へのリク エス トでボディサイズが 100 KB 以上の場合にブロックする」ルールは、CDK だとこんな感じで書くことになります。（ルール部分のみ） { name: "SizeConstraint" , priority: 10 , statement: { andStatement: { statements: [ { notStatement: { statement: { byteMatchStatement: { searchString: "/file/upload" , fieldToMatch: { uriPath: {} , } , textTransformations: [ { priority: 0 , type : "NONE" , } , ] , positionalConstraint: "EXACTLY" , } , } , } , } , { sizeConstraintStatement: { fieldToMatch: { body: { oversizeHandling: "CONTINUE" , } , } , comparisonOperator: "GE" , size: 100 * 1000 , textTransformations: [ { priority: 0 , type : "NONE" , } , ] , } , } , ] , } , } , action: { block: {} } , visibilityConfig: { sampledRequestsEnabled: true , cloudWatchMetricsEnabled: true , metricName: "SizeConstraint" , } , } , これをヒントなしで正しく書ける気がしません。一方でマネジメントコンソールでルールを作成すれば、画面の説明に従って割と分かりやすく作成できます。 そこで IaC で WAF のルールを作る場合も、まずはマネジメントコンソールで試しに作成してみて、画面で「ルール JSON エディタ」に切り替えましょう 。 JSON でのルールの書き方を表示してくれます。これをコピーして IaC で利用すると良いでしょう。（CDK に使う場合はプロパティ名の頭文字を大文字から小文字に変換する必要がありますが、自前で書くよりはずっと楽です。） ちなみにルール JSON エディタ画面の説明にもある通り、 JSON を使えばビジュアルエディタではサポートされていないような、深い階層の条件を持つルールを作ることもできます。以下の re:Post 投稿も参考になります。 複雑なカスタム AWS WAF JSON ルールを作成する方法を教えてください。 https://repost.aws/ja/knowledge-center/waf-create-complex-custom-rules さいごに ご紹介した内容はいずれも公式ドキュメントやブログに書いてあることなのですが、WAF を使い始める時は早く構成したい気持ちが先走ってなかなか網羅的にチェックはできませんね。今振り返ると最初に知っておきたかったと感じたことをまとめてみました。誰かの参考になれば嬉しいです。 記事の中に掲載したリンクで特におすすめのものを再掲しておきます。 コアルールセット (CRS) マネージドルールグループ https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-baseline.html#aws-managed-rule-groups-baseline-crs （どのようなルールで検査を行うのか、利用前に一通り把握しておきましょう） AWS WAF によってブロックされているファイルをアップロードするにはどうすればよいですか? https://repost.aws/ja/knowledge-center/waf-upload-blocked-files Amazon CloudWatch Logs による AWS WAF ログの分析 https://aws.amazon.com/jp/blogs/news/analyzing-aws-waf-logs-in-amazon-cloudwatch-logs/ CloudWatch または Amazon S3 に保存されている AWS WAF ログを分析するオプションは何ですか? https://repost.aws/ja/knowledge-center/waf-analyze-logs-stored-cloudwatch-s3 ルールグループ内のアクションオーバーライド https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/web-acl-rule-group-override-options.html 複雑なカスタム AWS WAF JSON ルールを作成する方法を教えてください。 https://repost.aws/ja/knowledge-center/waf-create-complex-custom-rules 以下は、この記事では触れませんでしたが参考となる re:Post の投稿です。 AWS WAF ルールでブロックされているファイルのアップロードを、ルールを除外せずに明示的に許可するには、どうすればよいですか？ https://repost.aws/ja/knowledge-center/waf-explicit-allow-file-uploads AWS WAF の HTTP リク エス トの XSS または SQLi 検査から特定の URI を除外する方法を教えてください。 https://repost.aws/ja/knowledge-center/waf-exclude-specific-requests-inspection AWS WAF を利用して DDoS 攻撃を緩和するにはどうすればいいですか? https://repost.aws/ja/knowledge-center/waf-mitigate-ddos-attacks 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @kou.kinyo 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS WAF は簡単に Web アプリに WAF を追加でき、かつ値段も他の WAF 製品より安いため、好きな AWS サービスの一つです。そんな AWS WAF ですがしばらく構築・運用し、これを最初から知っておけば・・・と思ったことがあるので 8つご紹介します。 AWS WAF の基本については分かっている前提で、特に説明はいたしません。また2023年10月現在の最新バージョンである、いわゆる「 AWS WAF v2」を対象としています。 その1: AWS マネージドルールのボディサイズ制限が厳しい その2: ファイルアップロードが AWS マネージドルールの XSS に引っかかることがある その3: マネージドルールにはバージョンがある その4: CloudWatch Logs のロググループ名に決まりがある その5: 35個のログストリームに分割される その6: ログに Cookie ヘッダーが記録されてしまう その7: ログ出力条件の EXCLUDED_AS_COUNT とは何か その8: コンソールで作成したルールを JSON 出力すると IaC での書き方がわかる さいごに その1: AWS マネージドルールのボディサイズ制限が厳しい AWS WAF を利用する際に AWS マネージドルール はとても便利です。その中の コアルールセット (CRS) マネージドルールグループ には SizeRestrictions_BODY というリクエストボディのサイズを検査するルールがあり、 8 KB を超えるボディを持つリクエストをブロック します。 ボディサイズが大きいリクエストや、ファイルアップロードにおいては 8 KB を簡単に超えてしまう ことがあるので、本番環境に導入する前に想定するサイズのリクエストがブロックされないかしっかりテストが必要です。 ※このようなルールが設定されている理由は、 AWS WAF は リクエストボディの最初の 8 KB しか検査できない という制約があるためです。リクエストボディの 8 KB 以降の位置に攻撃文字列が含まれていても検査できないため、コアルールセットでは 8 KB を超えるリクエストを一律でブロックすることで対応しています。 ※(2024/3/11追記)ALB以外に関連付けるWAF Web ACL のリクエストボディの検査サイズ制限が 16 KB（64 KBに引き上げ可能）に増えました。 https://aws.amazon.com/about-aws/whats-new/2024/03/aws-waf-larger-body-inspections-regional-resources/ 想定する正当なリクエストが 8 KB を超えてしまう場合、ルールグループ内の SizeRestrictions_BODY ルールのアクションを「Count」にオーバーライドすることで、実質的に除外することができます。ただしボディサイズ制限が全くないのは心許ないので、次のように WAF Web ACL を作ることが考えられます。 コアルールセットマネージドルールグループでは SizeRestrictions_BODY を「Count」にオーバーライドする 適切な値でボディサイズ制限を行う独自ルールを作成する このようなルールを複数作り、リクエストパスに応じて異なるボディサイズの 閾値 を設定することも可能です（例えばファイルアップロードを受け付ける URI パスに対しては 100 KB に制限し、それ以外の URI パスに対しては 8 KB に制限するなど） ボディサイズ制限の 閾値 を 8 KB より大きくする場合、前述の通り、それを超える部分のリクエストボディの中身は他のルールでも検査されないことに留意してください なお、re:Post の次の投稿でも SizeRestrictions_BODY でブロックされた場合の対応方法が記載されています。マネージドルールに一致した際に追加されるラベルと独自ルールを組み合わせて、特定の URI パス（=ファイルアップロードを行う URI パス）ではない場合のみブロックを発動させる方法です。 AWS WAF によってブロックされているファイルをアップロードするにはどうすればよいですか? https://repost.aws/ja/knowledge-center/waf-upload-blocked-files その2: ファイルアップロードが AWS マネージドルールの XSS に引っかかることがある Web アプリに対してバイナリファイルのアップロードをした時に、運悪く コアルールセット (CRS) マネージドルールグループ の CrossSiteScripting_BODY ルールに引っかかってしまったことがありました。そのときのログの一部は次の通りです。バイナリデータが XSS の シグネチャ に一致してしまったようです。 " terminatingRuleMatchDetails ": [ { " conditionType ": " XSS ", " location ": " BODY ", " matchedData ": [ " < ", " \u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000 " ] } ] , re:Post の次の投稿によると、 ファイルアップロードでは CrossSiteScripting_BODY 以外にも SQLi_BODY 、 WindowsShellCommands_BODY 、 GenericLFI_BODY 、 SizeRestrictions_BODY ルールによってブロックされる可能性がある ようです。 AWS WAF によってブロックされているファイルをアップロードするにはどうすればよいですか? https://repost.aws/ja/knowledge-center/waf-upload-blocked-files 投稿では対応方法として「文字列または 正規表現 ( regex ) 一致条件が設定されたセーフリストを使用して、リクエストを許可します。」が紹介されています。マネージドルールに一致した際に追加されるラベルと独自ルールを組み合わせて、リクエストボディに特定の文字列（ファイル拡張子などを想定していると解釈しました）が含まれていない場合のみブロックを発動する方法です。（注：日本語の投稿ではなぜかリクエストヘッダーから特定の文字列を探すとありますが、 英語の投稿 ではリクエストボディから探すと書いてあります。リクエストボディの方がしっくりきています。） あるいは「その1」の SizeRestrictions_BODY の場合と同じように、特定の URI パス（=ファイルアップロードを行う URI パス）ではない場合のみブロックを発動させる方法を取っても良さそうです。 その3: マネージドルールにはバージョンがある マネジメントコンソールでマネージドルールを使っていたらすぐに気が付いたと思うのですが、筆者は CDK で Web ACL を作っていたのでずっと知りませんでした。 マネージドルールにはバージョンが存在します 。 （ AWS マネージドルールのうち「IP レピュテーション、 Bot Control、アカウント乗っ取り防止のルールグループ」にはバージョンが存在しません。バージョンに関わらず、日ごろから頻繁にルールが更新されるためでしょう。） バージョンを特に指定しない場合、そのマネージドルールがデフォルトと設定したバージョンが利用され、ルールプロバイダーがデフォルトバージョンを変更すると構築した Web ACL でも自動的に新しいバージョンに更新されます。自動的に更新されることを避けたい場合は、「静的バージョン」を明示的に指定します。ただしこの場合も、「緊急時の必須の更新」がされる可能性があるそうです。またバージョンの有効期限が切れると、次のような扱いになるようです。 AWS マネージドルールルールグループの場合、 AWS WAF は、有効期限切れのバージョンを使用しているウェブ ACL を、ルールグループのデフォルトバージョンに移動します。 AWS Marketplace ルールグループの場合、プロバイダーは有効期限の処理方法を決定します。詳細については、マネージドルールグループプロバイダーに問い合わせてください。 マネージドルールには SNS トピックが用意されている場合があり、サブスクライブすることでバージョンを含めたルールの更新情報を受け取ることができます。特に静的バージョンを使用する場合はルールバージョンを手動更新することになるので、 SNS トピックをサブスクライブしておくと良いでしょう。 その4: CloudWatch Logs のロググループ名に決まりがある AWS WAF を利用する場合はログをぜひ取っておきたいところですが、CloudWatch Logs に出力する場合、 ロググループ名は aws-waf-logs- で始まる必要があります 。 https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/logging-cw-logs.html#logging-cw-logs-naming マネジメントコンソールでロググループを指定する場合は画面にこの条件が書いてありますし、 aws-waf-logs- で始まるロググループ以外は選択肢に表示されないのでまだ分かりやすいです。 しかし CloudFormation （もちろん CDK も）を利用する場合、 aws-waf-logs- で始まるロググループ以外を Web ACL に関連付けしようとすると、デプロイ時に次のようなエラーになります。「ARN が有効でない」というエラーメッセージでは何がいけないのか全く分からず、どハマりしたことがあるのは自分だけではないはずです。 Resource handler returned message: "Error reason: The ARN isn't valid. A valid ARN begins with arn: and includes other information separated by colons or slashes., field: LOG_ DESTINATION , parameter: arn: aws :logs:ap-northeast-1:111122223333:log-group:waf-logs-xxxxx ちなみにログの出力先が S3 バケット の場合も、 バケット 名は aws-waf-logs- で始まる必要があります。 https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/logging-s3.html#logging-s3-naming その5: 35個のログストリームに分割される （2025/9/5更新）いつ変わったのか分かりませんが、今はWAFのログストリームが分割されなくなっているようです。なお、それでもログの検索はCloudWatch Logs Insightsを利用するのが便利であることには変わりません。 CloudWatch Logs にログを出力すると、 35個のログストリームに分割 され、この数を減らすことはできません 。出力の スループット を高めるためのようです。 近い時刻で発生したログメッセージでも、複数のログストリームに分散して出力されるため、ロググループから特定のログを探すのは難しいです。ログストリームを横断して時系列にログを見たり、特定のログを探したい場合は CloudWatch Logs Insights を利用するのが便利です。以下の公式ブログや re:Post 投稿が参考になります。 Amazon CloudWatch Logs による AWS WAF ログの分析 https://aws.amazon.com/jp/blogs/news/analyzing-aws-waf-logs-in-amazon-cloudwatch-logs/ CloudWatch または Amazon S3 に保存されている AWS WAF ログを分析するオプションは何ですか? https://repost.aws/ja/knowledge-center/waf-analyze-logs-stored-cloudwatch-s3 その6: ログに Cookie ヘッダーが記録されてしまう WAF Web ACL のログを出力すると、 httpRequest.headers フィールドにリクエストヘッダーが記録されます。つまり、 クライアントが送信した Cookie も記録されてしまいます 。 （スクリーンキャプチャの値はダミーです） 例えば分析のためにログを出力したり、共有したりすると有効なセッション ID などセンシティブな情報が漏えいするリスクがあります。 この問題への対応として、ログ出力時に 特定フィールドをマスキング することが可能です。例えば cookie ヘッダーをマスキングするには次のように設定します。 このように設定すると、出力されるログの cookie ヘッダーは REDACTED という文字列に置き換えられます。 ※（追記） Cookie ヘッダーをマスキングするデータ保護機能が増強されました。セッションIDなど特定の Cookie のみを対象としたり、マスキングの代わりにハッシュ化を行うこともできるようになっています。 https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/data-protection-masking.html その7: ログ出力条件の EXCLUDED_AS_COUNT とは何か ログを出力する場合、アクションが特定の条件に該当する場合のみ出力するように設定できます。リクエストが許可された場合のログも全て記録すると量が多くなってしまうので、「ブロック」時と「カウント」時のみ出力したいことがあります。 カウント時の条件は、実は COUNT と EXCLUDED_AS_COUNT の2種類があります 。基本的には COUNT 扱いと考えて良いですが、 EXCLUDED_AS_COUNT として扱われるケースが2つ、以下のブログで説明されています。 AWS WAF のログ分析に関する考慮事項 https://aws.amazon.com/jp/blogs/news/aws-waf-log-analysis-considerations/ マネージドルールグループで ”Set all rule actions to count” で Count に設定した場合 マネージドルールグループで個別のルールを Count に設定した場合 ただし上の AWS のブログは情報が古く、現在個別のルールを Count に設定した場合の動きは少々異なるようです（ 参照 ）。簡単にまとめると、以下のようになると理解しています： 2022 年 10 月 27 日より前に、 WAF ルールの JSON では ExcludedRules が利用でき、これに含めた個別ルールは EXCLUDED_AS_COUNT 扱いになる マネジメントコンソールで個別ルールを Count に設定すると、 EXCLUDED_AS_COUNT 扱いになる 2022 年 10 月 27 日以降は、 WAF ルールの JSON で ExcludedRules に含めた個別ルールは変わらず EXCLUDED_AS_COUNT 扱いになる WAF ルールの JSON で RuleActionOverrides が新しく利用でき、オーバーライド先をカウントにした場合は COUNT 扱いになる マネジメントコンソールで個別ルールを Count に設定（過去に作成したルールの編集も含めて）すると、 COUNT 扱いに変わる この動きを意識してログ出力条件を作成すると良いと思います。 その8: コンソールで作成したルールを JSON 出力すると IaC での書き方がわかる CloudFormation もしくは CDK で複雑な条件の Web ACL を作成する場合、書き方が分からずに困ることがあります。 例えば「 URI パスが /file/upload 以外へのリクエストでボディサイズが 100 KB 以上の場合にブロックする」ルールは、CDK だとこんな感じで書くことになります。（ルール部分のみ） { name : "SizeConstraint" , priority: 10 , statement: { andStatement: { statements: [ { notStatement : { statement : { byteMatchStatement : { searchString : "/file/upload" , fieldToMatch : { uriPath : {} , } , textTransformations : [ { priority : 0 , type : "NONE" , } , ] , positionalConstraint : "EXACTLY" , } , } , } , } , { sizeConstraintStatement : { fieldToMatch : { body : { oversizeHandling : "CONTINUE" , } , } , comparisonOperator : "GE" , size : 100 * 1000 , textTransformations : [ { priority : 0 , type : "NONE" , } , ] , } , } , ] , } , } , action: { block: {} } , visibilityConfig: { sampledRequestsEnabled: true , cloudWatchMetricsEnabled: true , metricName: "SizeConstraint" , } , } , これをヒントなしで正しく書ける気がしません。一方でマネジメントコンソールでルールを作成すれば、画面の説明に従って割と分かりやすく作成できます。 そこで IaC で WAF のルールを作る場合も、まずはマネジメントコンソールで試しに作成してみて、画面で「ルール JSON エディタ」に切り替えましょう 。 JSON でのルールの書き方を表示してくれます。これをコピーして IaC で利用すると良いでしょう。（CDK に使う場合はプロパティ名の頭文字を大文字から小文字に変換する必要がありますが、自前で書くよりはずっと楽です。） ちなみにルール JSON エディタ画面の説明にもある通り、 JSON を使えばビジュアルエディタではサポートされていないような、深い階層の条件を持つルールを作ることもできます。以下の re:Post 投稿も参考になります。 複雑なカスタム AWS WAF JSON ルールを作成する方法を教えてください。 https://repost.aws/ja/knowledge-center/waf-create-complex-custom-rules さいごに ご紹介した内容はいずれも公式ドキュメントやブログに書いてあることなのですが、WAF を使い始める時は早く構成したい気持ちが先走ってなかなか網羅的にチェックはできませんね。今振り返ると最初に知っておきたかったと感じたことをまとめてみました。誰かの参考になれば嬉しいです。 記事の中に掲載したリンクで特におすすめのものを再掲しておきます。 コアルールセット (CRS) マネージドルールグループ https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-baseline.html#aws-managed-rule-groups-baseline-crs （どのようなルールで検査を行うのか、利用前に一通り把握しておきましょう） AWS WAF によってブロックされているファイルをアップロードするにはどうすればよいですか? https://repost.aws/ja/knowledge-center/waf-upload-blocked-files Amazon CloudWatch Logs による AWS WAF ログの分析 https://aws.amazon.com/jp/blogs/news/analyzing-aws-waf-logs-in-amazon-cloudwatch-logs/ CloudWatch または Amazon S3 に保存されている AWS WAF ログを分析するオプションは何ですか? https://repost.aws/ja/knowledge-center/waf-analyze-logs-stored-cloudwatch-s3 ルールグループ内のアクションオーバーライド https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/web-acl-rule-group-override-options.html 複雑なカスタム AWS WAF JSON ルールを作成する方法を教えてください。 https://repost.aws/ja/knowledge-center/waf-create-complex-custom-rules 以下は、この記事では触れませんでしたが参考となる re:Post の投稿です。 AWS WAF ルールでブロックされているファイルのアップロードを、ルールを除外せずに明示的に許可するには、どうすればよいですか？ https://repost.aws/ja/knowledge-center/waf-explicit-allow-file-uploads AWS WAF の HTTP リクエストの XSS または SQLi 検査から特定の URI を除外する方法を教えてください。 https://repost.aws/ja/knowledge-center/waf-exclude-specific-requests-inspection AWS WAF を利用して DDoS 攻撃を緩和するにはどうすればいいですか? https://repost.aws/ja/knowledge-center/waf-mitigate-ddos-attacks 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研中途採用ページ 電通総研新卒採用ページ 執筆： @kou.kinyo 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回はUE5.2の新機能であるプロシージャルコンテンツ生成 フレームワーク （PCG：Procedural Content Generation Framework）の紹介を行います。 はじめに PCGとはコンテンツ生成に関するルールを作成し、そのルールに沿って植物や岩などのアセットを大量に配置できる機能です。 アセットの種類や位置、大きさなどを指示するルールを作成することで制作時間を大幅に削減でき、 ルールを流用することで大規模なワールド作成なども行えます。 また、変更に対して柔軟に対応しやすいという点もメリットになります。 今回は Gaea という3D地形生成ツールを使用して ランドスケープ を作成しながら、PCGを使用してフォトリアルな森の作り方を説明します。 検証環境/ツール OS： Windows 11 pro GPU ： NVIDIA GeForce RTX 4070 Ti Game Engine： Unreal Engine 5.2.0 実装手順 Gaea上で ランドスケープ を作成 ハイトマップをUE5プロジェクトにインポート PCGを使用して森を生成 1. Gaea上で ランドスケープ を作成 まずはUE上でPCGを使用する前に、木々を生やすための土地（ ランドスケープ ）を作成します。 UEにも ランドスケープ を造形するツールは搭載しているのですが、今回は Gaea という3D地形生成を使用して ランドスケープ を生成します。 こちらの記事 でUEの ランドスケープ 機能を紹介しているので、ぜひこちらもご覧ください。 まずは Gaea をインストールします。 解像度が1024x1024までは無料で使うことができるので、今回は無料版を使用します。 Gaeaを開くと下記のような画面になります。 左のタブの「Geo Primitives」から使用したい地形のモデルを ドラッグ&ドロップ します。 また、いくつかの地形モデルを組み合わせることもできます。 下の図では「Range（山岳）」と「Rocky（岩肌）」のノードを「Combine」を使用して組み合わせてみました。 「Range（山岳）」 「Rocky（岩肌）」 組み合わせた地形 今回の ランドスケープ では、もう少し平地の部分も欲しかったので、 「Range」と「Worselands」の地形ノードを組み合わせて使用しました。 また組み合わせた地形に「FractalTerraces（地層）」のノードや「Erosion（浸食）」のノードを組み合わせ、 よりイメージに近い地形を作成しました。 詳しい地形ノードや効果のノードに関しては こちらの公式リファレンス を参照しました。 次にこれまで作成した地形をUEで使用するためにエクスポート作業を行います。 最終的に作成した「Erosion（浸食）」のノードを右クリックし、Renameを行います。 今回私は「MyWorld」という名前に変更しました。 続いて「MyWorld」を再度右クリックし、Mark for Exportを押下します。 右側のタブにエクスポートの詳細が表示されるので、出力形式を「. png 」に変更します。 また、 UEで推奨しているランドスケープの解像度の値 は1009なので、「Resolution」を「1009」に変更します。 GaeaからUEにデータを移行する際、縦横の比率の変更をする必要があります。 右側の詳細画面のタブを「MyWorld Properties」に切り替え、地形の縦横・高低比率を調査するための「Lv」のボタンを押下します。 すると下記画面のように作成した地形の縦横比率が変わった状態のサンプルが表示されます。 デフォルトのままエクスポートをすると、この状態の地形がUEに入ってしまうので設定を変えていきます。 「Lv」の下にある「Clmp」ボタンを押下し、「Clmp Max」の値を「25%」に変更します。 （この値は作成した ランドスケープ を見ながら適宜調整します） これで元のモデルと同じ縦横比率になるので、このままBuildタブに戻り、「Start Build」を行いファイルを出力します。 続いて出力したファイルをUEにインポートします。 2. ハイトマップをUE5プロジェクトにインポート UEを開き選択モードから ランドスケープ モードに変更します。 新しい ランドスケープ のタブから、「ファイルからインポート」を選択します。 先ほどGaeaでエクスポートした「. png 」ファイルを選択します。 インポート設定画面で、解像度をGaeaで設定した「1009x1009」に変更してインポートします。 インポート後、 ランドスケープ が出現していないように見えますが、「ExponentalHeight」が画面にモヤをかけてしまっており、遠くの ランドスケープ が見えなくなっているだけなので、 選択モードに変更後、上下の位置を変えることで ランドスケープ が見えるようになります。 これでGaeaで作成した ランドスケープ をUE上で使うことができます。 続いて作成した ランドスケープ にPCGで森を作成します。 3. PCGを使用して森を生成 まずPCGで森を作成する前に、作成された ランドスケープ のマテリアルがデフォルトのままで味気ないので、マテリアルを割り当てます。 今回は簡易的に行うため、 アウトライナー で ランドスケープ を選択し、 ランドスケープ マテリアルに任意のマテリアルを選択しました。 次にPCGを使用するために プラグイン の設定をする必要があります。 プラグイン 設定画面から「Procedural Content Generation Framework」をオンにします。UEを再起動させて設定を反映させます。 次に今回フォトリアルな森を作成するために使用するアセットのダウンロードを行います。 Unreal マーケットプレイス から「Megascans Trees(早期アクセス)」を開きダウンロードします。 今回はヨーロッパ風の木を使用しましたが、他に何種類かあったので自分の作りたいイメージに合ったものをダウンロードします。 ダウンロードが完了するとプロジェクトのコンテンツブラウザからダウンロードした木々のアセットを表示できます。 このアセットは後で使うので一旦このまま置いておきます。 UEの編集画面より、PCGで森を生成するための範囲を決めるために「PCGVolume」というアセットを生成します。 画面上部よりアセット追加ボタンを押し、検索して生成してください。 生成した範囲をワールド上に設置し、森を作成したい大きさに任意で設定します。 次に、この範囲とPCGで作成するルールを記載するアセットを紐づけます。 まずルールを記載するためにコンテンツブラウザ内に「PCGグラフ」を作成します。今回は「MyWorldPCG」と 命名 しました。 次に編集画面で アウトライナー より先ほど範囲を決めるために作成した「PCGVolume」を選択し、子要素の「PCGComponent」を選択します。 選択すると、 インスタンス 直下にGraphを選択する欄があるので、先ほど作成した「MyWorldPCG」を選択し、ルールと範囲を紐づけます。 続いて「MyWorldPCG」を編集してルールを作成します。 「MyWorldPCG」を開くとブループリントの編集画面のようなものがでてきます。 まずは「 Surface Sampler」というノードを作成し、「Input」の「Landscape」ピンと繋ぎます。 このノードは Surface （面）に対してルールを適応させていくことができます。 「 Surface Sampler」を選択し、右側の設定画面から「Points Per Squared Meter 」の値を変更します。 この値は、 平方メートルあたりのポイント数を設定できます。今回は一旦「0.01」としました。 次に「Transform Point」ノードを作成し、右につなげます。 ここではアセットの大きさや向きを設定できます。 「Rotation Max」のZ値を360に設定します。これにより生成されたアセットの向きがランダムになります。 また「Scale Min」を0.7に設定します。これにより生成されたアセットの大きさが70~100%の間でランダムになります。 この「Transform Point」を選択した状態で、キーボードの「D」を押下します。 するとノードの右上に水色のマークがついていることを確認できます。これは デバッグ 状態で表示できるモードであるという印です。 UE編集画面に戻ると、「Transform Point」で生成したアセット生成ポイントが デバッグ 状態で見ることができます。（黒や白でブロックが置かれている部分に指定したアセットが表示される予定） 今作成した生成ポイントには大きな木を配置する予定なので、 続けて、小さな木を配置する用のポイントも追加します。 「 Surface Sampler」と「Transform Point」をコピーします。 「 Surface Sampler」の「Points Per Squared Meter 」の値を「0.1」にします。これにより先ほど作成した大きな木用のポイントの10倍の数のアセットが生成できます。 さらに「Point Extents」でブロックの大きさを変更します。デフォルトが「100」だったので半分の「50」に設定します。 この段階でUE編集画面に戻ると下記画像のように変更されます。 同様にさらに小さな草を生やすためのノードもコピーしました。 次に作成したポイントに実際のアセットを割り当てていきます。 「Static Mesh Spawner」ノードを作成します。 右側の設定画面で「Mesh Entries」の右側のプラスボタンを押し、配列を3つ作成します。 追加した配列の内部に入っていき「Description > Static Mesh」の順に開き、先ほど マーケットプレイス から追加した木のアセットを選択します。 木のアセットは「Contents > BlackAlder > Geometry > PivotPainter」の中にあります。 選択して割り当てたら、配列の残った2つにも同様に木のアセットを選択します。 この時、この3つの木のアセットがランダムで生成されるので、使いたい3種類の木のアセットを選択してください。 UE編集画面に戻ると下記画像のように大きな木がランダムで生成されているのを確認できます。 同様に、後2つの「Static Mesh Spawner」ノードを作成します。ここでは小さい木やさらに小さい草木のアセットをそれぞれ配置します。 配置が完了すると以下のようなフォトリアルな森が完成します。 上記の方法で、 数に関しては「Points Per Squared Meter 」の値を変更し 種類に関しては「Description > Static Mesh」のメッシュを変更することで、さまざまな種類の森を簡単に作ることができます。 おわりに UE5.2の新機能であるプロシージャルコンテンツ生成 フレームワーク （PCG：Procedural Content Generation Framework）の紹介を行いました。 画像でお見せしたようなフォトリアルなワールドがとても手軽に作成できるとても便利な機能だと感じました。 ルールベースでコンテンツを生成するので編集や複製なども容易にでき、今後の開発でも色々使用していきたいです。 ルールを作成することで、森の中に道を作成したり、その道にそって草を配置することなどもできるので、 次回はもう少し深掘りしたPCGの使用方法をご紹介します。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 執筆： @okazaki.wataru 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回はUE5.2の新機能であるプロシージャルコンテンツ生成 フレームワーク （PCG：Procedural Content Generation Framework）の紹介を行います。 はじめに PCGとはコンテンツ生成に関するルールを作成し、そのルールに沿って植物や岩などのアセットを大量に配置できる機能です。 アセットの種類や位置、大きさなどを指示するルールを作成することで制作時間を大幅に削減でき、 ルールを流用することで大規模なワールド作成なども行えます。 また、変更に対して柔軟に対応しやすいという点もメリットになります。 今回は Gaea という3D地形生成ツールを使用して ランドスケープ を作成しながら、PCGを使用してフォトリアルな森の作り方を説明します。 検証環境/ツール OS： Windows 11 pro GPU ： NVIDIA GeForce RTX 4070 Ti Game Engine： Unreal Engine 5.2.0 実装手順 Gaea上で ランドスケープ を作成 ハイトマップをUE5プロジェクトにインポート PCGを使用して森を生成 1. Gaea上で ランドスケープ を作成 まずはUE上でPCGを使用する前に、木々を生やすための土地（ ランドスケープ ）を作成します。 UEにも ランドスケープ を造形するツールは搭載しているのですが、今回は Gaea という3D地形生成を使用して ランドスケープ を生成します。 こちらの記事 でUEの ランドスケープ 機能を紹介しているので、ぜひこちらもご覧ください。 まずは Gaea をインストールします。 解像度が1024x1024までは無料で使うことができるので、今回は無料版を使用します。 Gaeaを開くと下記のような画面になります。 左のタブの「Geo Primitives」から使用したい地形のモデルを ドラッグ&ドロップ します。 また、いくつかの地形モデルを組み合わせることもできます。 下の図では「Range（山岳）」と「Rocky（岩肌）」のノードを「Combine」を使用して組み合わせてみました。 「Range（山岳）」 「Rocky（岩肌）」 組み合わせた地形 今回の ランドスケープ では、もう少し平地の部分も欲しかったので、 「Range」と「Worselands」の地形ノードを組み合わせて使用しました。 また組み合わせた地形に「FractalTerraces（地層）」のノードや「Erosion（浸食）」のノードを組み合わせ、 よりイメージに近い地形を作成しました。 詳しい地形ノードや効果のノードに関しては こちらの公式リファレンス を参照しました。 次にこれまで作成した地形をUEで使用するためにエクスポート作業を行います。 最終的に作成した「Erosion（浸食）」のノードを右クリックし、Renameを行います。 今回私は「MyWorld」という名前に変更しました。 続いて「MyWorld」を再度右クリックし、Mark for Exportを押下します。 右側のタブにエクスポートの詳細が表示されるので、出力形式を「. png 」に変更します。 また、 UEで推奨しているランドスケープの解像度の値 は1009なので、「Resolution」を「1009」に変更します。 GaeaからUEにデータを移行する際、縦横の比率の変更をする必要があります。 右側の詳細画面のタブを「MyWorld Properties」に切り替え、地形の縦横・高低比率を調査するための「Lv」のボタンを押下します。 すると下記画面のように作成した地形の縦横比率が変わった状態のサンプルが表示されます。 デフォルトのままエクスポートをすると、この状態の地形がUEに入ってしまうので設定を変えていきます。 「Lv」の下にある「Clmp」ボタンを押下し、「Clmp Max」の値を「25%」に変更します。 （この値は作成した ランドスケープ を見ながら適宜調整します） これで元のモデルと同じ縦横比率になるので、このままBuildタブに戻り、「Start Build」を行いファイルを出力します。 続いて出力したファイルをUEにインポートします。 2. ハイトマップをUE5プロジェクトにインポート UEを開き選択モードから ランドスケープ モードに変更します。 新しい ランドスケープ のタブから、「ファイルからインポート」を選択します。 先ほどGaeaでエクスポートした「. png 」ファイルを選択します。 インポート設定画面で、解像度をGaeaで設定した「1009x1009」に変更してインポートします。 インポート後、 ランドスケープ が出現していないように見えますが、「ExponentalHeight」が画面にモヤをかけてしまっており、遠くの ランドスケープ が見えなくなっているだけなので、 選択モードに変更後、上下の位置を変えることで ランドスケープ が見えるようになります。 これでGaeaで作成した ランドスケープ をUE上で使うことができます。 続いて作成した ランドスケープ にPCGで森を作成します。 3. PCGを使用して森を生成 まずPCGで森を作成する前に、作成された ランドスケープ のマテリアルがデフォルトのままで味気ないので、マテリアルを割り当てます。 今回は簡易的に行うため、 アウトライナー で ランドスケープ を選択し、 ランドスケープ マテリアルに任意のマテリアルを選択しました。 次にPCGを使用するために プラグイン の設定をする必要があります。 プラグイン 設定画面から「Procedural Content Generation Framework」をオンにします。UEを再起動させて設定を反映させます。 次に今回フォトリアルな森を作成するために使用するアセットのダウンロードを行います。 Unreal マーケットプレイス から「Megascans Trees(早期アクセス)」を開きダウンロードします。 今回はヨーロッパ風の木を使用しましたが、他に何種類かあったので自分の作りたいイメージに合ったものをダウンロードします。 ダウンロードが完了するとプロジェクトのコンテンツブラウザからダウンロードした木々のアセットを表示できます。 このアセットは後で使うので一旦このまま置いておきます。 UEの編集画面より、PCGで森を生成するための範囲を決めるために「PCGVolume」というアセットを生成します。 画面上部よりアセット追加ボタンを押し、検索して生成してください。 生成した範囲をワールド上に設置し、森を作成したい大きさに任意で設定します。 次に、この範囲とPCGで作成するルールを記載するアセットを紐づけます。 まずルールを記載するためにコンテンツブラウザ内に「PCGグラフ」を作成します。今回は「MyWorldPCG」と 命名 しました。 次に編集画面で アウトライナー より先ほど範囲を決めるために作成した「PCGVolume」を選択し、子要素の「PCGComponent」を選択します。 選択すると、 インスタンス 直下にGraphを選択する欄があるので、先ほど作成した「MyWorldPCG」を選択し、ルールと範囲を紐づけます。 続いて「MyWorldPCG」を編集してルールを作成します。 「MyWorldPCG」を開くとブループリントの編集画面のようなものがでてきます。 まずは「 Surface Sampler」というノードを作成し、「Input」の「Landscape」ピンと繋ぎます。 このノードは Surface （面）に対してルールを適応させていくことができます。 「 Surface Sampler」を選択し、右側の設定画面から「Points Per Squared Meter 」の値を変更します。 この値は、 平方メートルあたりのポイント数を設定できます。今回は一旦「0.01」としました。 次に「Transform Point」ノードを作成し、右につなげます。 ここではアセットの大きさや向きを設定できます。 「Rotation Max」のZ値を360に設定します。これにより生成されたアセットの向きがランダムになります。 また「Scale Min」を0.7に設定します。これにより生成されたアセットの大きさが70~100%の間でランダムになります。 この「Transform Point」を選択した状態で、キーボードの「D」を押下します。 するとノードの右上に水色のマークがついていることを確認できます。これは デバッグ 状態で表示できるモードであるという印です。 UE編集画面に戻ると、「Transform Point」で生成したアセット生成ポイントが デバッグ 状態で見ることができます。（黒や白でブロックが置かれている部分に指定したアセットが表示される予定） 今作成した生成ポイントには大きな木を配置する予定なので、 続けて、小さな木を配置する用のポイントも追加します。 「 Surface Sampler」と「Transform Point」をコピーします。 「 Surface Sampler」の「Points Per Squared Meter 」の値を「0.1」にします。これにより先ほど作成した大きな木用のポイントの10倍の数のアセットが生成できます。 さらに「Point Extents」でブロックの大きさを変更します。デフォルトが「100」だったので半分の「50」に設定します。 この段階でUE編集画面に戻ると下記画像のように変更されます。 同様にさらに小さな草を生やすためのノードもコピーしました。 次に作成したポイントに実際のアセットを割り当てていきます。 「Static Mesh Spawner」ノードを作成します。 右側の設定画面で「Mesh Entries」の右側のプラスボタンを押し、配列を3つ作成します。 追加した配列の内部に入っていき「Description > Static Mesh」の順に開き、先ほど マーケットプレイス から追加した木のアセットを選択します。 木のアセットは「Contents > BlackAlder > Geometry > PivotPainter」の中にあります。 選択して割り当てたら、配列の残った2つにも同様に木のアセットを選択します。 この時、この3つの木のアセットがランダムで生成されるので、使いたい3種類の木のアセットを選択してください。 UE編集画面に戻ると下記画像のように大きな木がランダムで生成されているのを確認できます。 同様に、後2つの「Static Mesh Spawner」ノードを作成します。ここでは小さい木やさらに小さい草木のアセットをそれぞれ配置します。 配置が完了すると以下のようなフォトリアルな森が完成します。 上記の方法で、 数に関しては「Points Per Squared Meter 」の値を変更し 種類に関しては「Description > Static Mesh」のメッシュを変更することで、さまざまな種類の森を簡単に作ることができます。 おわりに UE5.2の新機能であるプロシージャルコンテンツ生成 フレームワーク （PCG：Procedural Content Generation Framework）の紹介を行いました。 画像でお見せしたようなフォトリアルなワールドがとても手軽に作成できるとても便利な機能だと感じました。 ルールベースでコンテンツを生成するので編集や複製なども容易にでき、今後の開発でも色々使用していきたいです。 ルールを作成することで、森の中に道を作成したり、その道にそって草を配置することなどもできるので、 次回はもう少し深掘りしたPCGの使用方法をご紹介します。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 執筆： @okazaki.wataru 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

こんにちは、グループ経営ソリューション（ GMS ）事業部 グループ経営 コンサルティング 第2ユニット 一般会計 コンサルティング 部 第2グループ、3年目の塚本です。 普段は会計ソリューションである Ci*Xシリーズ の新規開発を担当しています。 ※ Ci*Xシリーズの導入に関して気になる方は川島さんの以下の記事を参考にしてください。 SIerで自社製品導入をする新卒5年目（※IT経験なし）の働き方と今感じること～ちょこっと就活の話も添えて～ 本記事では、業務内容や 1 週間の過ごし方など、私の主な働き方についてざっくりとご紹介します。 IT 企業への就職を検討されている学生の方や、ISID にご興味をお持ちの方の参考になれば幸いです。 目次 目次 自己紹介 仕事内容 新規開発の作業工程 要件定義 設計 実装・単体テスト 結合テスト 製品化 配属後からこれまでの流れ 2年間働いてみて 最後に 自己紹介 私は工学部電気電子系学科出身で、4年間物理学を学んでいました。私の学部では通常であればそのまま院に進学し、メーカーや電気関係の企業に就職することがほとんどです。しかし、院には進学せず学部卒で2021 年に新卒入社しました。入社後に半年間の研修を経て、グループ経営ソリューション事業部に配属されました。 私が院に進学せず、IT企業を目指すことになったきっかけは2つあります。 1つ目は私が所属していた学部では毎年95%以上が院に進学しているという理由から、院に進学するのは当たり前という流れがあり、"〇〇の研究がしたい"というモチベーションの人がほとんどいなかったことです。モチベーション高く仕事をしている企業に就職した方が自己成長に繋がるのではないかと考えました。 2つ目はアルバイト先の塾で、生徒の点数ランキング作成の仕事を手書きという原始的な方法からエクセルの関数などを使って自動化したことにやりがいを感じたことです。 また、大学進学時に経済学部や 経営学 部に進学するか迷っていたこともありもともと会計には興味があったので、グループ経営ソリューション事業部に希望して希望通り配属されています。 自己紹介はこれくらいにして、これから私が所属する第2グループの業務のうち 新規開発 を中心にお話しします。 仕事内容 私が所属する一般会計 コンサルティング 部では自社パッケージの会計システムである Ci＊Xシリーズ の 導入・新規開発・保守 を行っています。 その中でも第2グループでは新規開発・運用・保守を行っていて、私は主に 新規開発 に携わりました。 新規開発の作業工程 私のプロジェクトでは、新規開発の作業工程をざっくり分けると以下の8工程です。 このプロジェクトではそれぞれの工程（赤い箱：私が経験した工程）でどのようなことを行ったかを配属から2年の範囲内で説明します。 ※私が経験した内容のみに絞って説明しているので各工程で他に必要なことがあることに注意してください。 要件定義 要件定義では、ユーザーの要求をシステムで実現することを目的に、どのような機能を開発すれば要求を満たすことができるのかを考えるフェーズです。そして、洗い出された要件を要件定義書に文書化します。 メッセージ入力機能を例に挙げると、入力したメッセージをコピー、削除、送信取消、転送できる必要があるかなどを考えます。また、その領域に関して書籍やインターネットで調査し、それでもわからない論点などはその領域に詳しい方に質問をしました。 設計 設計は、要件定義書に記載された要件を満たすように機能を細かく考えるフェーズです。 具体的には、システムを動かす際に矛盾が生じないように、ユーザーがどのように機能を使うか（ ユースケース 定義）、画面構成はどうするか、計算ロジックはどうするかなどを考えて以下の資料に記載します。 ユースケース 定義書（ユーザー目線でできることをまとめた資料） ドメイン モデル図（概念クラスの関係性の図をまとめた資料） 概念クラス（概念とその属性をまとめた資料） 画面定義書（画面のイメージや制御についてまとめた資料） ロジック定義書（複雑な処理の仕組みについてまとめた資料） 結合テスト 仕様書（ 結合テスト に使用するテストケースをまとめた資料） 実装・ 単体テスト 実装・ 単体テスト は、設計書の設計内容を満たすように実際にコーディングし、設計書通りに動作するか確認するフェーズです。 実装で用いる技術要素は以下です。 バックエンド技術（ Java , Spring Boot, Thymeleaf, PostgreSQL 等） フロントエンド技術（ HTML5 、TypeScript、Vue.js 等） 結合テスト 結合テスト は、設計で作成した 結合テスト 仕様書に記載されたテストケースに従ってシステムが正しく動作しているかを検証するフェーズです。正しく動いていない場合や、設計書・ 結合テスト 仕様書が間違っている場合は欠陥として報告します。 製品化 製品化ではユーザーがシステムの操作で分からないときに閲覧できるマニュアルを作成します。 マニュアル作成 配属後からこれまでの流れ 配属後半年は簡単なタスクで製品のキャッチアップや技術のレベルアップを進め、 結合テスト を経験しました。その後、1年くらいで要件定義から実装・ 単体テスト までを経験することが出来ました。 業務の種類にもよりますが、まだマネジメント業務がないため MTG は比較的少なく作業がメインです。また、品質の高い実装力をつけるため、隔週で勉強会に参加して自己研鑽しています。 2年間働いてみて 配属から約1年半はテレワークメインでした。メンバーと直接的なコミュニケーションを取る機会がかなり少なかったため、質問しづらい関係性で業務に詰まったときは少し辛い環境でした。しかし、半年くらい前から出社日を合わせてプロジェクトメンバーと直接コミュニケーションを取ったことでリモートワークでも以前より質問がしやすい環境になり、今はかなりいい環境で働けていると思います。 業務ではシステムの新規開発で要件定義から 結合テスト までの工程を経験できたので、同年代の開発者の中では システム開発 に関して凄く幅広い経験をでき、力がかなりつきました。その経験は多くの知識（会計知識から開発の技術知識など）が必要なため、学習などで補ったりすることが大変ではありました。しかし、たくさん知識が付いたことで配属当初では考えられないほどの自信が付き、自己成長によるやりがいも感じています。また、 システム開発 では定番かもしれませんが、自分で設計した機能が実装されて実際に動くところを見ることでもやりがいを感じました。 先輩社員から、「この業界は3年間がインプット期間、4年目以降はアウトプットで結果を出す」と言われています。そのおかげて1つ1つのタスクで色々調べたりメモを残したりしてたくさんインプットできています。4年目からのプレッシャーが少しはありますが、それ以上にこの3年間の成長を実感しました。 自分がやりたいことをできる部署に配属してもらい、配属先でもやりたい業務をたくさん任せてもらいました。自分がやりたい・楽しいと思える仕事にたくさん関わることができ、最高のモチベーションで仕事をすることができています。これからもより楽しく仕事をやっていきたいと思っています。 最後に 就活生のみなさんには、やりたいことを明確にしてほしいと思っています。この記事を見て、第2グループでやっていることと自分のやりたいことが一致するかをぜひ考えてみてください。ISIDではやりたいことを発信していると、やらせてもらえることが多い環境だと思うので少しでもやりたいことができそうだと思った方は、ぜひご応募いただければなと思います。 www.isid.co.jp 執筆： @tsukamoto.sou 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは、グループ経営ソリューション（ GMS ）事業部 グループ経営 コンサルティング 第2ユニット 一般会計 コンサルティング 部 第2グループ、3年目の塚本です。 普段は会計ソリューションである Ci*Xシリーズ の新規開発を担当しています。 ※ Ci*Xシリーズの導入に関して気になる方は川島さんの以下の記事を参考にしてください。 SIerで自社製品導入をする新卒5年目（※IT経験なし）の働き方と今感じること～ちょこっと就活の話も添えて～ 本記事では、業務内容や 1 週間の過ごし方など、私の主な働き方についてざっくりとご紹介します。 IT 企業への就職を検討されている学生の方や、ISID にご興味をお持ちの方の参考になれば幸いです。 目次 目次 自己紹介 仕事内容 新規開発の作業工程 要件定義 設計 実装・単体テスト 結合テスト 製品化 配属後からこれまでの流れ 2年間働いてみて 最後に 自己紹介 私は工学部電気電子系学科出身で、4年間物理学を学んでいました。私の学部では通常であればそのまま院に進学し、メーカーや電気関係の企業に就職することがほとんどです。しかし、院には進学せず学部卒で2021 年に新卒入社しました。入社後に半年間の研修を経て、グループ経営ソリューション事業部に配属されました。 私が院に進学せず、IT企業を目指すことになったきっかけは2つあります。 1つ目は私が所属していた学部では毎年95%以上が院に進学しているという理由から、院に進学するのは当たり前という流れがあり、"〇〇の研究がしたい"というモチベーションの人がほとんどいなかったことです。モチベーション高く仕事をしている企業に就職した方が自己成長に繋がるのではないかと考えました。 2つ目はアルバイト先の塾で、生徒の点数ランキング作成の仕事を手書きという原始的な方法からエクセルの関数などを使って自動化したことにやりがいを感じたことです。 また、大学進学時に経済学部や 経営学 部に進学するか迷っていたこともありもともと会計には興味があったので、グループ経営ソリューション事業部に希望して希望通り配属されています。 自己紹介はこれくらいにして、これから私が所属する第2グループの業務のうち 新規開発 を中心にお話しします。 仕事内容 私が所属する一般会計 コンサルティング 部では自社パッケージの会計システムである Ci＊Xシリーズ の 導入・新規開発・保守 を行っています。 その中でも第2グループでは新規開発・運用・保守を行っていて、私は主に 新規開発 に携わりました。 新規開発の作業工程 私のプロジェクトでは、新規開発の作業工程をざっくり分けると以下の8工程です。 このプロジェクトではそれぞれの工程（赤い箱：私が経験した工程）でどのようなことを行ったかを配属から2年の範囲内で説明します。 ※私が経験した内容のみに絞って説明しているので各工程で他に必要なことがあることに注意してください。 要件定義 要件定義では、ユーザーの要求をシステムで実現することを目的に、どのような機能を開発すれば要求を満たすことができるのかを考えるフェーズです。そして、洗い出された要件を要件定義書に文書化します。 メッセージ入力機能を例に挙げると、入力したメッセージをコピー、削除、送信取消、転送できる必要があるかなどを考えます。また、その領域に関して書籍やインターネットで調査し、それでもわからない論点などはその領域に詳しい方に質問をしました。 設計 設計は、要件定義書に記載された要件を満たすように機能を細かく考えるフェーズです。 具体的には、システムを動かす際に矛盾が生じないように、ユーザーがどのように機能を使うか（ ユースケース 定義）、画面構成はどうするか、計算ロジックはどうするかなどを考えて以下の資料に記載します。 ユースケース 定義書（ユーザー目線でできることをまとめた資料） ドメイン モデル図（概念クラスの関係性の図をまとめた資料） 概念クラス（概念とその属性をまとめた資料） 画面定義書（画面のイメージや制御についてまとめた資料） ロジック定義書（複雑な処理の仕組みについてまとめた資料） 結合テスト 仕様書（ 結合テスト に使用するテストケースをまとめた資料） 実装・ 単体テスト 実装・ 単体テスト は、設計書の設計内容を満たすように実際にコーディングし、設計書通りに動作するか確認するフェーズです。 実装で用いる技術要素は以下です。 バックエンド技術（ Java , Spring Boot, Thymeleaf, PostgreSQL 等） フロントエンド技術（ HTML5 、TypeScript、Vue.js 等） 結合テスト 結合テスト は、設計で作成した 結合テスト 仕様書に記載されたテストケースに従ってシステムが正しく動作しているかを検証するフェーズです。正しく動いていない場合や、設計書・ 結合テスト 仕様書が間違っている場合は欠陥として報告します。 製品化 製品化ではユーザーがシステムの操作で分からないときに閲覧できるマニュアルを作成します。 マニュアル作成 配属後からこれまでの流れ 配属後半年は簡単なタスクで製品のキャッチアップや技術のレベルアップを進め、 結合テスト を経験しました。その後、1年くらいで要件定義から実装・ 単体テスト までを経験することが出来ました。 業務の種類にもよりますが、まだマネジメント業務がないため MTG は比較的少なく作業がメインです。また、品質の高い実装力をつけるため、隔週で勉強会に参加して自己研鑽しています。 2年間働いてみて 配属から約1年半はテレワークメインでした。メンバーと直接的なコミュニケーションを取る機会がかなり少なかったため、質問しづらい関係性で業務に詰まったときは少し辛い環境でした。しかし、半年くらい前から出社日を合わせてプロジェクトメンバーと直接コミュニケーションを取ったことでリモートワークでも以前より質問がしやすい環境になり、今はかなりいい環境で働けていると思います。 業務ではシステムの新規開発で要件定義から 結合テスト までの工程を経験できたので、同年代の開発者の中では システム開発 に関して凄く幅広い経験をでき、力がかなりつきました。その経験は多くの知識（会計知識から開発の技術知識など）が必要なため、学習などで補ったりすることが大変ではありました。しかし、たくさん知識が付いたことで配属当初では考えられないほどの自信が付き、自己成長によるやりがいも感じています。また、 システム開発 では定番かもしれませんが、自分で設計した機能が実装されて実際に動くところを見ることでもやりがいを感じました。 先輩社員から、「この業界は3年間がインプット期間、4年目以降はアウトプットで結果を出す」と言われています。そのおかげて1つ1つのタスクで色々調べたりメモを残したりしてたくさんインプットできています。4年目からのプレッシャーが少しはありますが、それ以上にこの3年間の成長を実感しました。 自分がやりたいことをできる部署に配属してもらい、配属先でもやりたい業務をたくさん任せてもらいました。自分がやりたい・楽しいと思える仕事にたくさん関わることができ、最高のモチベーションで仕事をすることができています。これからもより楽しく仕事をやっていきたいと思っています。 最後に 就活生のみなさんには、やりたいことを明確にしてほしいと思っています。この記事を見て、第2グループでやっていることと自分のやりたいことが一致するかをぜひ考えてみてください。ISIDではやりたいことを発信していると、やらせてもらえることが多い環境だと思うので少しでもやりたいことができそうだと思った方は、ぜひご応募いただければなと思います。 www.isid.co.jp 執筆： @tsukamoto.sou 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは。ISID 金融ソリューション事業部の若本です。 先日、GPT-4から発展し、 画像も扱うことができるGPT-4 with vision（GPT-4V）が発表 されました。GPT-4Vは大規模マルチモーダルモデル（LMMs: Large multimodal models）と呼ばれるAIモデルの一種であり、GPT-4の入力として「画像」を拡張したものになります。 今日は Microsoft Researchの論文[1]を中心に、Open AIの発表したSystem Card[2]も踏まえ、GPT-4Vでできることや苦手とすること、そして実用上の制限について解説します。 GPT-4Vの特徴 ① 画像とテキストを入力にできる GPT-4Vでは、GPT-4のテキスト入力に加えて画像も入力することが可能になりました。 画像は複数枚入力することが可能であり、かつ、画像とテキストを任意に交互に組み合わせて入力できます。 ② 画像に関する常識を理解している 画像の中の情報を判別するだけでなく、視覚的な常識に基づいて推論を行うことができます。 例）着用している服装から結婚式の画像だと判断する、部屋のレイアウトから気候や家主の特性を判断する、など ③ 多言語/多文化を理解している GPT-4と同様に、画像についても多言語の入力/出力が可能です。例では、手書き文字に近い崩れたフォントについても正しく理解し、多言語で出力されています。 また、特定の文化圏に関する画像についても理解し説明できることが論文中で示されています。 ④ 感情を理解している 画像中の人間の表情から感情を識別できます。他にも、入力した画像コンテンツがどのような印象を相手に与えるのかといった視覚的な感情も解釈することができます。 また、ネット ミーム の説明などユーモアを理解する能力を持っていることも報告されています。 GPT-4Vができるタスク ① 画像/ビデオの説明 撮影条件に大きく左右されず、画像について説明することができます。画像全体のマクロな説明から、画像内の特定のオブジェクトについてのミクロな説明も可能です。 また、フレームごとに画像を与えることで、ビデオも入力し説明できます。画像の例では、シュートのタイミングやゴールの結果まで推論することができており、画像内の空間的な位置関係と画像同士の時間関係を理解できていることがわかります。 ② 物体の位置特定 画像中の物体の位置や、その物体が何か特定できます。画像の例では、画像内に映る複数人の人物の位置を特定し、それぞれ位置座標と説明を出力しています。 上記のようにテキスト形式で位置座標を取得する（ バウンディ ングボックス）ことはできますが、GPT-4V単体で出力した バウンディ ングボックスの位置座標は正確でない場合があります。ただし、これはpromptによって改善可能です。 ③ 画像中の文章/記号/表をもとにした推論 画像ベースで非言語知能テスト（以下の例は Raven’s Progressive Matrices ）に答えることも可能です。画像内の文章や記号を理解し、解答することが可能です。 PDF化された論文のような複雑な視覚情報でも、一部詳細についてミスは発生したものの大まかには正しく説明されることが示されていました。これらの理解能力を応用することで、Web ブラウジング のようなエージェント操作も実行できる可能性があることが示されています。 ④ 生成AIの出力の改善 画像生成AIに与える指示（prompt）を生成することで、生成AIを用いた画像編集のような ユースケース でより手間をかけない編集が可能になります。画像の例では、暗いトーンでより表紙らしい画像にするための指示をGPT-4Vを用いて生成しています。 ただし、System cardによると、コンテンツ生成について「GPT-4Vは虚偽情報を検出する手段として使用したり、真偽を検証する手段として使用すべきではない」と述べられているため、画像生成の完全な自動化については推奨されていません。 GPT-4Vが比較的苦手とするタスク ① 間違い探し 2つの画像を比較するタスク（間違い探し）はある程度可能ですが、完璧な精度ではないようです。 ② 2023年以降の情報が必要なタスク GPT-4Vは2022年に学習を完了しているため、被災地の写真の説明など、2023年以降の知識が必要なタスクはGPT-4V単体で解くことができません。論文中では、Bing Image Search プラグイン を用いて関連画像を検索した後、GPT-4Vに説明させています。 ③ 専門家の知識が必要なタスク（医療診断） 医療分野における 放射線 報告書の生成タスクを実施し、ある程度の診断精度と高品質なフォーマットから専門家の作業量減少に寄与できる可能性はあるとされる一方、誤識別や数値のミスがありました。 System Cardにおいても、専門家の検証の結果、「医療領域において完璧なパフォーマンスではなく、現在のバージョンのGPT-4Vは医療を遂行するための専門的な医療アド バイス 、診断、治療、判断を代替するには適していない」と結論付けています。 ④ 画像の情報量が多い/読み取れないタスク これまでご紹介したいずれのタスクにおいても、画像内のオブジェクトが非常に混み入っていたり、一目で識別できないほど必要な情報が隠れているとGPT-4Vで推論することは難しくなります。特に、物体のカウントや前述の物体位置検出などでは情報量の多い画像において精度が悪化していました。 制限 Open AIにより、下記のようなクエリには応答しないようチューニングが施されているようです[2]。 身元情報の特定 例）人物の画像をアップロードして誰か特定する、2つの画像を使用して同じ人物かどうかを尋ねるなど 機密情報の窃取 例）年齢、人種など 根拠のない推論を招く幅の広いクエリ 例）画像内の人物にアド バイス してください、など 加えて、GPT-4やDALL·Eの API で用いられているシステム側の分類器も機能し、これまで通り動作します。 その他、筆者の環境ではGPT-4Vが執筆時点で解放されていないため不明ですが、リク エス トには最大画像枚数や画像の解像度などに制限があるかもしれません。 おわりに 今回は、論文をベースにGPT-4Vのできることやその特徴についてご紹介しました。promptのコツなども紹介されており、cookbookとしても非常に参考になる論文ですので、興味のある方はぜひご一読をおすすめします。 また、Conclusionには、今後のLMMsの進化として 1) 画像を生成する、2)ビデオ/オーディオなど別の情報を入力として増やす、などが述べられていました。今後、より進化したLMMsの登場により、さらに広範囲に我々の生活にAIが浸透していくことが期待されます。 参考文献 [1]: The Dawn of LMMs: Preliminary Explorations with GPT-4V(ision) [2]: GPT-4V(ision) System Card 執筆： @wakamoto.ryosuke 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは。ISID 金融ソリューション事業部の若本です。 先日、GPT-4から発展し、 画像も扱うことができるGPT-4 with vision（GPT-4V）が発表 されました。GPT-4Vは大規模マルチモーダルモデル（LMMs: Large multimodal models）と呼ばれるAIモデルの一種であり、GPT-4の入力として「画像」を拡張したものになります。 今日は Microsoft Researchの論文[1]を中心に、Open AIの発表したSystem Card[2]も踏まえ、GPT-4Vでできることや苦手とすること、そして実用上の制限について解説します。 GPT-4Vの特徴 ① 画像とテキストを入力にできる GPT-4Vでは、GPT-4のテキスト入力に加えて画像も入力することが可能になりました。 画像は複数枚入力することが可能であり、かつ、画像とテキストを任意に交互に組み合わせて入力できます。 ② 画像に関する常識を理解している 画像の中の情報を判別するだけでなく、視覚的な常識に基づいて推論を行うことができます。 例）着用している服装から結婚式の画像だと判断する、部屋のレイアウトから気候や家主の特性を判断する、など ③ 多言語/多文化を理解している GPT-4と同様に、画像についても多言語の入力/出力が可能です。例では、手書き文字に近い崩れたフォントについても正しく理解し、多言語で出力されています。 また、特定の文化圏に関する画像についても理解し説明できることが論文中で示されています。 ④ 感情を理解している 画像中の人間の表情から感情を識別できます。他にも、入力した画像コンテンツがどのような印象を相手に与えるのかといった視覚的な感情も解釈することができます。 また、ネット ミーム の説明などユーモアを理解する能力を持っていることも報告されています。 GPT-4Vができるタスク ① 画像/ビデオの説明 撮影条件に大きく左右されず、画像について説明することができます。画像全体のマクロな説明から、画像内の特定のオブジェクトについてのミクロな説明も可能です。 また、フレームごとに画像を与えることで、ビデオも入力し説明できます。画像の例では、シュートのタイミングやゴールの結果まで推論することができており、画像内の空間的な位置関係と画像同士の時間関係を理解できていることがわかります。 ② 物体の位置特定 画像中の物体の位置や、その物体が何か特定できます。画像の例では、画像内に映る複数人の人物の位置を特定し、それぞれ位置座標と説明を出力しています。 上記のようにテキスト形式で位置座標を取得する（ バウンディ ングボックス）ことはできますが、GPT-4V単体で出力した バウンディ ングボックスの位置座標は正確でない場合があります。ただし、これはpromptによって改善可能です。 ③ 画像中の文章/記号/表をもとにした推論 画像ベースで非言語知能テスト（以下の例は Raven’s Progressive Matrices ）に答えることも可能です。画像内の文章や記号を理解し、解答することが可能です。 PDF化された論文のような複雑な視覚情報でも、一部詳細についてミスは発生したものの大まかには正しく説明されることが示されていました。これらの理解能力を応用することで、Web ブラウジング のようなエージェント操作も実行できる可能性があることが示されています。 ④ 生成AIの出力の改善 画像生成AIに与える指示（prompt）を生成することで、生成AIを用いた画像編集のような ユースケース でより手間をかけない編集が可能になります。画像の例では、暗いトーンでより表紙らしい画像にするための指示をGPT-4Vを用いて生成しています。 ただし、System cardによると、コンテンツ生成について「GPT-4Vは虚偽情報を検出する手段として使用したり、真偽を検証する手段として使用すべきではない」と述べられているため、画像生成の完全な自動化については推奨されていません。 GPT-4Vが比較的苦手とするタスク ① 間違い探し 2つの画像を比較するタスク（間違い探し）はある程度可能ですが、完璧な精度ではないようです。 ② 2023年以降の情報が必要なタスク GPT-4Vは2022年に学習を完了しているため、被災地の写真の説明など、2023年以降の知識が必要なタスクはGPT-4V単体で解くことができません。論文中では、Bing Image Search プラグイン を用いて関連画像を検索した後、GPT-4Vに説明させています。 ③ 専門家の知識が必要なタスク（医療診断） 医療分野における 放射線 報告書の生成タスクを実施し、ある程度の診断精度と高品質なフォーマットから専門家の作業量減少に寄与できる可能性はあるとされる一方、誤識別や数値のミスがありました。 System Cardにおいても、専門家の検証の結果、「医療領域において完璧なパフォーマンスではなく、現在のバージョンのGPT-4Vは医療を遂行するための専門的な医療アド バイス 、診断、治療、判断を代替するには適していない」と結論付けています。 ④ 画像の情報量が多い/読み取れないタスク これまでご紹介したいずれのタスクにおいても、画像内のオブジェクトが非常に混み入っていたり、一目で識別できないほど必要な情報が隠れているとGPT-4Vで推論することは難しくなります。特に、物体のカウントや前述の物体位置検出などでは情報量の多い画像において精度が悪化していました。 制限 Open AIにより、下記のようなクエリには応答しないようチューニングが施されているようです[2]。 身元情報の特定 例）人物の画像をアップロードして誰か特定する、2つの画像を使用して同じ人物かどうかを尋ねるなど 機密情報の窃取 例）年齢、人種など 根拠のない推論を招く幅の広いクエリ 例）画像内の人物にアド バイス してください、など 加えて、GPT-4やDALL·Eの API で用いられているシステム側の分類器も機能し、これまで通り動作します。 その他、筆者の環境ではGPT-4Vが執筆時点で解放されていないため不明ですが、リク エス トには最大画像枚数や画像の解像度などに制限があるかもしれません。 おわりに 今回は、論文をベースにGPT-4Vのできることやその特徴についてご紹介しました。promptのコツなども紹介されており、cookbookとしても非常に参考になる論文ですので、興味のある方はぜひご一読をおすすめします。 また、Conclusionには、今後のLMMsの進化として 1) 画像を生成する、2)ビデオ/オーディオなど別の情報を入力として増やす、などが述べられていました。今後、より進化したLMMsの登場により、さらに広範囲に我々の生活にAIが浸透していくことが期待されます。 参考文献 [1]: The Dawn of LMMs: Preliminary Explorations with GPT-4V(ision) [2]: GPT-4V(ision) System Card 執筆： @wakamoto.ryosuke 、レビュー： @yamada.y （ Shodo で執筆されました ）