楽楽メールマーケティング開発課では現在、「AI-HTMLメール生成機能」の開発に取り組んでいます。8月26日には一部のお客様向けにβ版を先行リリースし、12月には全てのお客様へβ版をリリースする予定です。 本記事では、開発を担当する垣内繁直さんに、取り組みの背景や工夫した点、開発を振り返って感じたことをお聞きしました。 楽楽メールマーケティングとは なぜこの機能を作ることになったのか AI-HTMLメール生成機能とは、どんな機能なのか 開発で難しかったことは何か スピードと品質は、どう両立させたのか 今後、どう進化させていきたいのか 楽楽メールマーケティングとは 「楽楽メールマーケティング」はメール作成から配信まで簡単にできるメルマガ配信サービスです。 なぜこの機能を作ることになったのか 楽楽メールマーケティングでは、メールマーケティングの効果を高めるために、月6回程度の配信を推奨しています。しかし実際には、既存顧客の約50%がこの推奨回数を満たせておらず、十分に配信できていない状態が続いていました。 原因を調査したところ、大きく2つの課題があるのではないかと考えました。 1つは配信のための担当者の稼働がそもそも取れないこと、もう1つはどんなメールがお客様に刺さるのかというノウハウが不足していることです。 この2つの課題を解決する手段として着目したのが、AIによるメールの自動生成です。 AIが自動生成することで、メール1通あたりの作成時間を大幅に削減し、稼働不足を解消します。 もう一つの狙いは、既存のノウハウをAIに引き継がせることです。楽楽メールマーケティングにはこれまで多くのお客様の配信を支援してきた実績があり、その中でどのような文章がメールの成果につながりやすいかというノウハウがすでに蓄積されています。このノウハウをAIのメール生成機能に組み込むことで、AI自身が質の高いメール文面を提案できるようにしました。これにより、メールマーケティングの専門知識を持たないお客様でも、成果につながりやすいメールを作成できるようになります。 時間をかけなくても、お客様に質の高いメールを届ける。質とスピードをどちらも向上させることがこの機能の目指すところです。 AI-HTMLメール生成機能とは、どんな機能なのか メールを作成する際は、まず自社の商品・サービスを登録します。ここでは、製品ページや自社サイトのURLを入力するか、PDFファイルを取り込むだけで、AIが情報を取得・分析し、製品情報を自動で作成します。 取り込んだ製品情報をもとに、配信するメールの方針を設定します。配信目的は、アポ獲得やウェビナー集客など、楽楽メールマーケティングがこれまで培ってきた成果実績にもとづくテンプレートから、用途に応じて選択する仕組みです。配信ターゲットはAIが自動で提案し、そのまま使うこともカスタマイズすることもできます。あわせて、メール本文に埋め込む誘導ボタン（CTA）やロゴの挿入位置、署名についても設定します。 方針が固まると、製品情報と方針をもとにAIがメール本文の案を複数生成します。ユーザーが選んだ案は楽楽メールマーケティングに従来から搭載されているリッチなHTMLエディターにそのまま展開され、デザインを追加で編集したうえで配信できる仕組みです。 すでに何社かのお客様が、この機能で作成したメールをそのまま配信できているほど、高い品質に達しています。そのうえで、さらに質の高いメールを届けられるよう、生成品質の向上にも継続して取り組んでいます。 開発で難しかったことは何か 開発で難しかった点は大きく2つあります。1つは開発期間の短さです。この案件は2ヶ月でβ版をリリースするという要望があり、事業部側からも早期リリースへの強い要望がありました。 もう1つは技術的な挑戦です。バックエンドをTypeScriptで実装したこと、AI機能をこのチームで実装するのは初めてだったことなど、実績のない技術への挑戦が続きました。 技術選定には明確な理由があります。AIのモデルにOpenAIのGPTを採用したところ、対応SDKの言語がTypeScriptやGoなどに限られていました。バックエンドチームはこれまでPHPしか扱ったことがありませんでしたが、PHP向けのSDKがなかったため、楽楽自動応対のAI-FAQ機能のバックエンドですでに採用実績のあったTypeScriptを選び、開発効率を重視しました。 開発期間が短い中で、実績のない新しい技術を使って開発することが、最大の難しさでした。 スピードと品質は、どう両立させたのか AI機能そのもの、特にプロンプトの調整や生成物の品質評価は、楽楽メールマーケティング開発課とは別部署のAI開発課が担当しました。楽楽メールマーケティング開発課は、それをアプリケーションに組み込む役割を担いました。この役割分担が、2ヶ月という短期間での開発を可能にした理由の一つです。 組み込みで特に工夫したのはプロンプト周りです。AI開発課が品質を担保したプロンプトを静的ファイルとして切り出し、そのまま使う仕組みにすることで、組み込み時に品質を損なわないようにしました。 開発の進め方自体にも工夫がありました。これまでチームではウォーターフォール的に要件を固めてから開発する進め方が中心でしたが、2ヶ月という期間ではそれが通用しません。要件が固まりきらないまま、開発と設計を同時に走らせました。 スピードを出すためにはAIを活用することが必須でしたが、単純に生成させるだけでは保守性の低いものができてしまいます。 そこでこだわったことが、AIの生成したコードに対する静的解析・リントなどのガードレールです。フックの仕組みを使い、AIがコードを実装するたびにガードレールが自動的に働き、指摘があればAI自身が修正するループを作ることで、人が介入しなくても一定の品質を保てるようにしました。 開発初期の1ヶ月ほどは、AIが出したコードをほぼ全て人間がレビューしていましたが、そこで挙がった指摘を静的解析やリントのルールに落とし込むことで、徐々にレビュー範囲を減らしていきました。この取り組みにより、後半は多くをAIに任せられる状態になりました。 品質を担保しながらAIに任せる範囲を広げていく仕組み作りこそが、今回の開発で最も工夫した点です。 今後、どう進化させていきたいのか 初段リリース以降は、β版利用時のお客様の声をもとに方向性を固めていく方針です。現時点で検討している方向性は、大きく3つあります。 1つ目は、応用的なメールへの対応です。自社テンプレートへの対応や、企業ごとのプロンプト追加に対応することで、これまで「ラクスの標準的な形」に合わせる必要があり対象外だったお客様も含め、より多くのお客様にこの機能を使ってもらえるようにしたいと考えています。自社のブランドガイドラインや既存の運用フローを崩さずに、AI生成のメリットを享受できる状態を目指します。 2つ目は、複数のメールコンテンツと配信セットの提案です。お客様が指定した配信内容に対して複数のメール案を作成・提案し、選ばれた案をそのまま配信セットまで組めるようにします。1通ずつ作成・配信していた業務をまとめて完結できるようにすることで、「次のメールを考える時間がない」という状況を解消し、配信頻度の維持・向上につなげたいと考えています。 3つ目は、過去のメール内容や配信結果を分析した、次に配信すべきコンテンツの自動提案です。配信結果画面と連動し、これまでの配信結果と自社の製品情報をもとに、次に配信すべきコンテンツをAIが提案し、メール作成まで行う機能を目指しています。単発のメール作成支援にとどまらず、配信結果を活かした改善サイクルを、ノウハウがなくても回せるようにすることが狙いです。 3つの方向性に共通するのは、より多くのお客様に、より少ない手間で、成果につながるメールを配信し続けてもらうという狙いです。稼働不足とノウハウ不足という2つの壁を取り除くことから始まったこの機能は、これからも進化を続けていきます。

はじめに ネットショップ作成サービス「BASE」のプロダクト開発チームでエンジニアリングマネージャー（EM）をしている髙嶋です。 BASE は組織としても個人としてもエンジニアイベントに積極的に関わっており、時折イベントの会場提供をさせていただくこともあります。2026/8/24（月）に「PHPerKaigi mini #4」を弊社オフィスにて開催したので、本記事ではその様子についてご紹介します。 phperkaigi.connpass.com PHPerKaigi mini とは PHPerKaigi mini は、技術カンファレンス「PHPerKaigi」のスポンサー企業およびスポンサーを検討中の企業がホストとなり、PHPer 向けに開催される勉強会です。トークテーマは必ずしも PHP 関連である必要はなく、「PHPer が聞いて面白ければ何でもアリ」というゆるやかなコンセプトで運営されています。 今回は第4回として、我々 BASE 株式会社がホストを務めました。 当日の雰囲気 登壇者・参加者あわせて20名程度にお集まりいただき、6本の LT と懇親会で大いに盛り上がりました。 ちなみに BASE からは、 @meihei が「CloudSearch から OpenSearch へ切り替えたけど質問ある？」と題して発表を行いました。詳細な内容については、いずれまた別の形でアウトプットされる予定なので楽しみにしていてください。 他には ADR の実践から Claude Code の個人開発活用、DI フレームワークの高速化まで、テーマが多岐に渡ったのも本イベントらしい点だったのではないかと思います。 おわりに 弊社では今後も機会があればエンジニアイベントの会場提供を行っていきたいと考えていますので、お気軽にお声がけください。 最後に、BASE はエンジニアイベントでわいわい楽しみたいという方に非常にマッチする環境です。ご興味のある方は、ぜひ採用情報もご覧いただけますと幸いです。 binc.jp

現在、 AWS Graviton5 プロセッサを搭載した  Amazon EC2 の R9g インスタンスと R9gd インスタンスが一般的に利用できるようになっています。R9g インスタンスはメモリ最適化されており、AWS がこれまでに構築した中で最もエネルギー効率の高いプロセッサを搭載した Graviton4 ベースの R8g インスタンスと比較して、コンピューティングパフォーマンスが最大 25% 向上します。 R9g インスタンスは、データベース、インメモリキャッシュ (Valkey、Redis、MemCached)、リアルタイムのビッグデータ分析、コンテナ化されたマイクロサービスベースのアプリケーション (Kubernetes、Docker、EKS、ECS など) を含む Linux ベースのワークロード、C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの一般的なプログラミング言語で記述されたアプリケーションなど、メモリを大量に消費するワークロードに最適です。 R9gd インスタンスには、ローカルの NVMe ベースの SSD ブロックレベルストレージが含まれており、オープンソースデータベース、分散型リアルタイムビッグデータ分析、大規模なインメモリデータベース、大規模なキャッシュワークロードなど、高速で低レイテンシーのローカルストレージを必要とするメモリ集約型のワークロードに最適です。 現在 R8g インスタンスでワークロードを実行している場合、R9g を使用すると、消費電力を抑えながら、より高速なメモリ、より高いネットワークと Amazon EBS の帯域幅、大きな L3 キャッシュにより、vCPU あたりのパフォーマンスが向上します。 R9g は何が違うのか Graviton5 プロセッサは、Graviton4 に比べていくつかのハードウェア改善をもたらしています。 vCPU あたりのコンピューティングパフォーマンスが最大 25% 向上 DDR5 8800 MT/s メモリ（Graviton4 の 5600 MT/s から増加）、クラウドで利用可能な最速のメモリ L3 キャッシュが 5 倍大きく、データの局所性が向上 最大のインスタンスサイズでは最大 2 倍のネットワークと EBS 帯域幅 (最大 100 Gbps のネットワーク、48 xlarge では最大 72 Gbps の EBS) 最大 3 倍のパケット処理パフォーマンス R9g インスタンスと R9gd インスタンスは、Amazon EBS と Amazon VPC ネットワーキング間の帯域幅割り当てを 25% 調整できるインスタンス帯域幅設定 (IBC) をサポートしています。これにより、データベースやキャッシュなど、特定の帯域幅要件を持つワークロードのパフォーマンスを最適化できます。 すべての R9g および R9gd インスタンスは AWS Nitro System 上で動作し、仮想化、ストレージ、ネットワーキングを専用ハードウェアにオフロードします。これにより、インスタンス間の強固なセキュリティ分離を維持しながら、アプリケーションはベアメタルに近いパフォーマンスを実現できます。 R9g インスタンスと R9gd インスタンスには、今年初めに C9g と M9g インスタンスで導入された Nitro System と同じ拡張機能である Nitro Isolation Engine (NIE) が搭載されています。Nitro Isolation Engine (NIE) は、インスタンスの分離を強制し、正式な検証を利用して数学的な精度で分離を保証します。Nitro Isolation Engine は、仮想マシン間の分離を強制する役割を担う専用コンポーネントです。その役割には、最小限の一連の API を通じて、仮想マシンのメモリ、CPU レジスタ状態、I/O デバイスに対するあらゆるアクセスを仲介することが含まれます。Nitro Isolation Engine は形式検証を活用しています。形式検証とは、ハードウェアまたはソフトウェアが、特定のテストケースにおいてだけでなく、意図されたとおりに動作することを数学的に証明する手法です。この高度な検証手法により、Nitro は形式的に検証された初のクラウドハイパーバイザーとなっており、数学的に証明されたクラウドセキュリティの新たな標準を打ち立てています。Nitro Isolation Engine の詳細については、 ブログ投稿 をご覧ください。対象範囲や前提条件を含む形式検証の結果の詳細については、 テクニカルホワイトペーパー を参照してください。 EC2 R9g および R9gd インスタンスの仕様 R9gとR9gdのインスタンスはそれぞれ、ミディアムからメタル 48XL まで、11種類のサイズでご利用いただけます。次の表は、各サイズの完全な仕様を示しています。 インスタンスサイズ vCPU メモリ (GiB) インスタンスストレージ ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) r9g.medium 1 8 EBS のみ 最大 15 最大 12 r9g.large 2 16 EBS のみ 最大 15 最大 12 r9g.xlarge 4 32 EBS のみ 最大 15 最大 12 r9g.2xlarge 8 64 EBS のみ 最大 17 最大 12 r9g.4xlarge 16 128 EBS のみ 最大 17 最大 12 r9g.8xlarge 32 256 EBS のみ 17 12 r9g.12xlarge 48 384 EBS のみ 25 18 r9g.16xlarge 64 512 EBS のみ 34 24 r9g.24xlarge 96 768 EBS のみ 50 36 r9g.48xlarge 192 1536 EBS のみ 100 72 r9g.metal‑48xl 192 1536 EBS のみ 100 72 R9gd インスタンスは、高速で低レイテンシーのスクラッチスペースまたは一時キャッシュを必要とするワークロード向けに、ローカル NVMe ベースの SSD ストレージを追加することで、R9g と同じコンピューティング性能とネットワークパフォーマンスを提供します。 インスタンスサイズ vCPU メモリ (GiB) インスタンスストレージ (NVMe SSD) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) r9gd.medium 1 8 1 x 59 GB 最大 15 最大 12 r9gd.large 2 16 1 x 118 GB 最大 15 最大 12 r9gd.xlarge 4 32 1 x 237 GB 最大 15 最大 12 r9gd.2xlarg 8 64 1 x 474 GB 最大 17 最大 12 r9gd.4xlarge 16 128 1 x 950 GB 最大 17 最大 12 r9gd.8xlarge 32 256 1 x 1900 GB 17 12 r9gd.12xlarge 48 384 3 x 950 GB 25 18 r9gd.16xlarge 64 512 1 x 3800 GB 34 24 r9gd.24xlarge 96 768 3 x 1900 GB 50 36 r9gd.48xlarge 192 1536 3 x 3800 GB 100 72 r9gd.metal‑48xl 192 1536 3 x 3800 GB 100 72 使用の開始 サポートされている任意の ARM ベースの AMI を使用して、 Amazon EC2 コンソールから R9g インスタンスと R9gd インスタンスを起動できます。R9g インスタンスは、Amazon Linux 2023、Amazon Linux 2、Ubuntu 22.04+、RHEL 8.4+、SUSE Linux エンタープライズサーバー 15 SP3+、Debian 12+、およびその他の主要な Linux ディストリビューションをサポートしています。 R8g から移行する場合、ほとんどのアプリケーションではコードを変更する必要はありません。同等の R9g インスタンスサイズを選択すると、アプリケーションのパフォーマンスが向上します。コンテナ化されたワークロードの場合、R9g は Amazon EKS、 Amazon   ECS 、および標準の Kubernetes デプロイメントと連携します。Arm64 用に構築されたマルチアーキテクチャコンテナイメージは変更なしで動作します。 始めるのに役立つリソースはいくつかあります。 AWS Graviton 入門ガイドでは 、Graviton ベースのインスタンスでワークロードを構築、実行、最適化する方法について説明しています。 Graviton節約ダッシュボードは 、コスト削減を追跡するのに役立ちます。 AWS Transform は Java アプリケーションを x86 から Graviton に移行するためのコード変換を自動化します。詳細については、 AWS Graviton プロセッサをご覧になるか、AWS Graviton でコンピューティングをレベルアップしてください 。 料金と利用可能なリージョン Amazon EC2 R9g および R9gd インスタンスは、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、および欧州 (フランクフルト) リージョンで利用可能です。 R9g および R9gd インスタンスは、Savings Plans、オンデマンド、スポットインスタンス、ハードウェア専有インスタンス、または専有ホストを通じて購入できます。詳細な料金については、「 Amazon EC2 の料金 」ページにアクセスしてください。 始める準備はできましたか? Amazon EC2 コンソール から R9g インスタンスを起動してください。詳細については、 Amazon EC2 R9g インスタンスページを参照してください 。 API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 Amazon EC2 用 AWS re:Post でフィードバックを共有するか、通常の AWS サポートの連絡先から連絡してください 。 – Daniel Abib 原文は こちら です。