G-gen の堂原です。当記事では、 Google Workspace の Gmail で、メールの送受信を特定のメールアドレスやドメインとの間にだけ許可し、それ以外は制限する方法について解説します。 はじめに 当記事について 仕様 手順1 : アドレスリスト作成 手順1-1 : アドレスリストの管理画面への遷移 手順1-2 : アドレスリストの作成 手順2 : 「配信を制限」の設定 手順2-1 : コンプライアンス画面への遷移 手順2-2 : 「配信を制限」の設定 はじめに 当記事について E メールの利用に際して、組織内のユーザーが外部の不特定多数とメールを送受信することを防ぎたいケースがあります。例えば、学校の生徒が持つメールアドレスからは、同じ学校の教師と生徒だけと送受信できるようにするケースが考えられます。 Google Workspace の Gmail には「 配信を制限 」という機能があります。これを利用することで、管理者が許可した特定のメールアドレスやドメインとのみ送受信できるようにし、それ以外は禁止するように構成できます。当記事では、「配信を制限」機能の設定方法を紹介します。 参考 : メールの送受信を承認済みアドレスまたはドメインのみに制限する - Google Workspace 管理者 ヘルプ 仕様 「配信の制限」設定を行うと、対象の 組織部門 に所属するユーザーは、指定されたアドレスリストに含まれない送信元からのメールを受信できなくなり、またアドレスリストに含まれない宛先へメールを送信できなくなります。 制限に抵触した場合、送信元のメールアドレスには バウンスメール が返送されます。 バウンスメール例 手順1 : アドレスリスト作成 手順1-1 : アドレスリストの管理画面への遷移 まずは、送受信を許可したいドメインやメールアドレスを設定した アドレスリスト を作成するために、「アドレスリストの管理画面」へ遷移します。 管理コンソール（ https://admin.google.com/ ）にログイン 左のサイドバーの「アプリ」をクリック 「Google Workspace」をクリック 「Gmail」をクリック 「Gmail の設定」に遷移するため、設定項目にある「ルーティング」をクリック 「アドレスリストの管理」は最上位の組織部門でしか設定できないため、最上位の組織部門を選択 「アドレスリストの管理」をクリック 手順1-2 : アドレスリストの作成 「アドレスリストの管理」画面にて、アドレスリストを作成します。 「アドレスリストの管理」にて、「アドレスリストを追加」をクリックします。 「アドレス」に送受信を許可したいアドレスとドメインを入力します。注意点として、メールの送信に失敗した際に送信元に送られてくるバウンスメールを受信するためには、 mailer-daemon@googlemail.com を許可する必要があります。 手順2 : 「配信を制限」の設定 手順2-1 : コンプライアンス画面への遷移 「配信を制限」設定は「Gmail の設定」の「コンプライアンス」画面にあるため、まずはそこまで遷移します。 左のサイドバーにて、「アプリ」をクリック 「Google Workspace」をクリック 「Gmail」をクリック 設定項目にある「コンプライアンス」をクリック 手順2-2 : 「配信を制限」の設定 「配信を制限」の設定画面を開きます。 メールの送受信を制限したい組織部門を選択 「配信を制限」欄にある「設定」をクリック 以下が「配信を制限」の設定画面です。 メールの送受信を許可したいアドレスリストを 1. の箇所に追加します。 2. の箇所に入力した文言は、バウンスメール管理者からのメッセージとして記載されます。 再掲 : バウンスメール例 3. にチェックを付けた場合、同じドメインの Google Workspace アカウント（今回だと dev.g-gen.co.jp ）に対して送信するメールは、「配信を制限」設定の影響を受けなくなります。すなわち、組織のドメインをアドレスリストに追加していなくても、組織内であればメールの送受信が可能です。 堂原 竜希 (記事一覧) クラウドソリューション部クラウドエクスプローラ課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024, 2025に選出 (2024年はRookie of the year、2025年はFellowにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

はじめに 駅メモ！開発チームの id:kaidan388 です。 昨年の6月に新機能として「アルバム機能」をリリースしました。私はこの開発でリーダーを務めました。 このアルバム機能は、駅メモ！の中でも特に規模の大きな開発となりました。また、これまでの新機能がバトル面の強化やチェックイン・アクセスのしやすさが中心で、ライフログを強化する試みはあまり例がなかったため、「本当にユーザーの皆様に楽しんでいただけるだろうか」という懸念も当初はありました。 今回は、この大規模かつ前例のない開発を無事にリリースまで進めるために、チームで試みた2つの工夫について、そのメリットとデメリットを交えてご紹介します。 はじめに アルバム機能について 工夫1：大規模ドッグフーディングの実施 良かった点 1. クオリティの向上 2. 最適な画質の模索 難しかった点 1. 工数の予想が難しくなる 2. コードの整合成が取れない 3. 環境準備のコスト まとめ 工夫2：アジャイル的な週次動作確認 メリット 1. バグの徹底的な洗い出し 2. 段階的なクオリティアップ デメリット リファクタリングに時間がかかる おわりに アルバム機能について 駅メモ！は、おかげさまで11周年を迎えることができました。これを「20年続くゲーム」にしていくために、ゲームを継続して遊ぶこと自体が楽しさにつながる機能を、より増やしていきたいと考えました。 駅メモ！には、ユーザーの皆様の「おでかけの記録」を残すライフログという側面があります。 しかし、これまでの新機能はバトル面の強化や、駅の回収（アクセス）をしやすくする強化が中心で、このライフログという側面に関わる機能強化は比較的少ない状態でした。 そこで今回、ライフログ機能の強化を行うことになりました。 様々な軸が考えられましたが、まずは情報量が多く、ユーザー様が後から振り返る価値を感じやすい「写真」や「画像データ」の素材としての価値に着目し、それらを記録として残す機能の開発を進めることにしました。 また合わせて、以前からユーザー様からのご要望も多かった「過去の移動ログを残し、いつでも見返せる機能」も追加しました。移動の記録と写真を同時に見ることで、お出かけの思い出としてよりリッチに記録できる仕組みを目指しました。 工夫1：大規模ドッグフーディングの実施 前例のない機能だったため、開発の初期段階から「まずは社員で集中的に遊んでみて、そのフィードバックを元に仕様を変更していく」という方針を前提に進めました。 もちろん、駅メモ！では普段からリリース前に開発したものを社員で動作確認しています。 しかし今回はその規模を拡大し、駅メモ！開発チーム外からも、普段から駅メモ！で遊んでいる社員に参加を呼びかけました。最終的に、普段の動作確認の4~5倍の人数の協力を得ることができました。 この取り組みでわかった、良かった点と難しかった点をご紹介します。 良かった点 1. クオリティの向上 最大のメリットは、やはりクオリティの向上です。 人数が多いだけでなく、駅メモ！の熟練者から、チーム外のライトユーザーまで、多様な視点からの意見が数多く集まりました。これらの意見を集約することで、UI/UXをどのように変更すべきかが明確になりました。 例えば、ドッグフーディング中に参加者から「本当にただ写真を記録するための道具になってしまっていて、ゲームらしい『楽しい』という感情が湧きづらい」という指摘がありました。 このフィードバックを受け、急遽、画像を投稿する際に以下のようなミニでんこ画像を表示する仕様を追加しました。 かわいいでんこの画像を追加することで、シンプルに画面を華やかにしたり、でんこと一緒に記録して旅をしている感覚を高めたりする効果を狙っています。 この追加によってユーザー様の感情にどういった変化が生まれるかを定量的に計測するのは難しいですが、追加後の開発メンバーやドッグフーディング参加者の反応を見る限り、非常に好評でした。 2. 最適な画質の模索 画質についても、シビアな調整が必要でした。 画質を良くしすぎると画像1枚あたりの容量が嵩み、特にサーバーからの配信コストが非常に高くなってしまいます。かといって、画質が低すぎると「画像を記録する」という体験そのものの価値を損ねてしまいます。 ドッグフーディングを何度も行い、参加者から画質についての具体的なフィードバックを受けることで、コストと体験のバランスを見極め、細かく調整することができました。 難しかった点 1. 工数の予想が難しくなる フィードバックに応じて仕様を変更すると、当然工数も増えます。 後から工数が増えることで、開発の完了時期の予想が難しくなってしまいました。 対応策としてアルバム開発では、以下のようにチケット状況をグラフにして可視化し、期限までに完了できるかに注視しつつリソースの調整などを行いました。 傾きが急になっている箇所は、まさにドッグフーディングの結果を受け工数の見積もりが増加したタイミングです。 2. コードの整合成が取れない フィードバックに応じて仕様が変更されることで、開発初期に書いたコードと整合成が取れなくなり、結果定期的にリファクタが必要になりました。 これも工数を増やすことにつながります。 3. 環境準備のコスト そもそも、「本番のアプリで、一部の社員だけがアルバム機能（開発中のもの）を遊べるようにする」という環境を準備する作業自体にも、相応の時間がかかります。 今回は、２種類のビルド成果物を用意しておき、ユーザによってアルバム機能を含むビルド成果物と含まないビルド成果物を出しわける、という方法を取りました。 目的は達成されますが、２回ビルドが必要になるのであらゆる場面で時間がかかってしまい、コストが増えてしまいます。 まとめ クオリティが確実に上がるという大きなメリットがある反面、その分エンジニアの対応負荷が高くなるトレードオフの関係にあります。 何にでもこの規模のドッグフーディングを行うのはコストパフォーマンスが悪いと感じたため、プロジェクトの重要度や特性に応じて実施を判断すべきだと感じました。 工夫2：アジャイル的な週次動作確認 駅メモ！では通常、ある程度仕様やデザインが固まってから開発（実装）を開始する、ウォーターフォール型に近い進め方を取ることが多いです。 しかし今回は、 プロジェクト全体の規模が非常に大きい 前述のドッグフーディングの結果、仕様変更が予想される という理由から、従来のように「ある程度の要件が固まるのを待ってから開発する」という進め方ができませんでした。 そこで今回は、要件が固まりきるのを待たず、すでにある程度仕様が確定している画面から順番に開発を着手していきました。 特にドッグフーディングの実施日がマイルストーンとなるため、そこまでにコア機能（最低限、画像がアップロードできる部分など）を完成させる必要がありました。細かいデザイン調整は後回しにして、まずは動くものを優先する、といった判断も行いました。 感覚としては、「いつもの半分の開発工数で、7割くらいの完成度のものを作る」ことを求められるような状況でした。 また、開発と並行して、週に1〜2回のペースで、そこまでの開発進捗についてアルバム機能開発チーム内で動作確認会を行いました。 結果として、「1週間単位で計画立て→開発→動作確認→次の計画立て」という、アジャイル開発に近い体制を取ることになりました。 この方針にも、当然ながら良い点と悪い点がありました。 メリット 1. バグの徹底的な洗い出し まめに動作確認を繰り返すため、バグを早期に、かつ徹底的に潰すことができます。 実際、今回のアルバム機能は規模が大きかったにも関わらず、リリース時に機能起因の不具合は1件も発生しませんでした。これは大きな成果だと感じています。 2. 段階的なクオリティアップ 大規模なドッグフーディングにかける前、まずは開発チーム内で何度も動作確認を実施しました。これにより、チーム内で見つけた分かりづらい文言やUIの細かい調整を事前に実施できました。その結果、クオリティ向上につながりました。 デメリット リファクタリングに時間がかかる この進め方の宿命ですが、一度書いたコードを、後からの仕様変更に伴って何度も書き直していくことになります。 開発の終盤になるほどコードベースは全体的に混沌としていき、変更作業が辛くなっていく、という場面も多々ありました。 「変更に強いコードを書く」という基本がいかに大事か、改めて痛感させられました。 おわりに 今回は、駅メモ！の「アルバム機能」開発において試みた、「大規模ドッグフーディング」と「アジャイル的な週次動作確認」という2つの工夫をご紹介しました。 どちらもメリットだけでなく、工数の増加やコードの複雑化といったデメリットも抱えていますが、前例のない大規模開発を進める上では非常に有効な手段だったと感じています。 リリース後、多くのユーザー様がアルバム機能をご利用くださり、お出かけの思い出を写真と共に記録していただいている様子を拝見し、開発チーム一同、大変嬉しく思っています。 これからも駅メモ！を長く楽しんでいただけるよう、チーム一同、開発と改善を続けてまいります。

2021 年に AWS に入社して以来、私は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスファミリーが成長するのを見てきました。そのペースは今でも驚きを隠せません。AWS Graviton 搭載のインスタンスから、特殊な高速コンピューティングオプションまで、パフォーマンスの限界をさらに押し上げる新しいインスタンスタイプが数か月ごとにリリースされているように感じられます。2026 年 2 月の時点で、AWS は 1,160 を超える Amazon EC2 インスタンスタイプを提供しており、その数は今も増え続けています。 2026 年 2 月 16 日週最初のニュースである Amazon EC2 M8azn インスタンスの一般提供はその良い例です。M8azn インスタンスは、第 5 世代 AMD EPYC プロセッサを搭載した高周波で高ネットワークの汎用インスタンスであり、クラウド内で最も高い 5 GHz の最大 CPU 周波数を提供しています。前世代の M5zn インスタンスと比較した場合、M8azn インスタンスは最大 2 倍優れたコンピューティングパフォーマンス、4.3 倍広いメモリ帯域幅、10 倍大きい L3 キャッシュを提供します。また、M5zn より最大 2 倍のネットワークスループット、最大 3 倍の Amazon Elastic Block Store (Amazon EBS) スループットも提供します。 第 6 世代の Nitro Card を使用して AWS Nitro System 上に構築された M8azn インスタンスは、自動車、航空宇宙、エネルギー、電気通信分野におけるリアルタイム財務分析、ハイパフォーマンスコンピューティング、高頻度取引、CI/CD パイプライン、ゲーム、シミュレーションモデリングなどのワークロード向けです。このインスタンスでは、メモリと vCPU の比率が 4:1 になっており、2 個から 96 個の vCPU 数、最大 384 GiB のメモリを搭載した 9 種類のサイズ (2 種類のベアメタルタイプを含む) で利用できます。詳細については、 Amazon EC2 M8azn インスタンスページ をご覧ください。 2026 年 2 月 9 日週のリリース 以下は、2026 年 2 月 9 日週に行われたその他の発表の一部です。 Amazon Bedrock が 6 つのフルマネージドオープンウェイトモデルのサポートを追加 – Amazon Bedrock が、DeepSeek V3.2、MiniMax M2.1、GLM 4.7、GLM 4.7 Flash、Kimi K2.5、Qwen3 Coder Next のサポートを開始しました。これらのモデルは、フロンティア推論とエージェンティックコーディングのワークロードに対応します。DeepSeek V3.2 と Kimi K2.5 は推論とエージェンティックインテリジェンスを対象としており、GLM 4.7 と MiniMax M2.1 は大規模な出力ウィンドウでの自律コーディングをサポートし、Qwen3 Coder Next と GLM 4.7 Flash は本番環境デプロイ用のコスト効率に優れた代替手段を提供します。Project Mantle を活用するこれらのモデルは、OpenAI API 仕様との設定不要の互換性を提供します。 このリリースにより、仕様主導型の AI 開発ツールである Kiro での DeepSeek v3.2、MiniMax 2.1、Qwen3 Coder Next といった新しいオープンウェイトモデルの使用も可能になります。 Amazon Bedrock が AWS PrivateLink のサポートを拡大 – Amazon Bedrock が、 bedrock-runtime エンドポイントの既存サポートに加えて、 bedrock-mantle エンドポイントでも AWS PrivateLink をサポートするようになりました。bedrock-mantle エンドポイントは、Amazon Bedrock で提供される大規模な機械学習モデル用の分散型推論エンジンである Project Mantle を活用しています。Project Mantle は、サービス品質制御を備えたサーバーレス推論、自動化されたキャパシティ管理によって引き上げられたデフォルトカスタマークォータ、OpenAI API 仕様との設定不要の互換性を提供します。OpenAI API 互換エンドポイントの AWS PrivateLink サポートは、14 の AWS リージョンでご利用いただけます。使用を開始するには、Amazon Bedrock コンソールにアクセスするか、OpenAI API 互換性ドキュメントを参照してください。 Amazon EKS Auto Mode がマネージド Kubernetes 機能のための強化されたロギング機能を発表 – Amazon EKS Auto Mode で Amazon CloudWatch Vended Logs を使用するログ配信ソースを設定できるようになりました。これは、Auto Mode のマネージド Kubernetes 機能からコンピューティングの自動スケーリング、ブロックストレージ、負荷分散、ポッドネットワーキングに関するログを収集するために役立ちます。各 Auto Mode 機能は、AWS 認証と承認が組み込まれた CloudWatch Vended Logs 配信ソースとして、標準の CloudWatch Logs よりも低い料金で設定できます。ログは、CloudWatch Logs、Amazon S3、または Amazon Data Firehose を宛先として配信できます。この機能は、EKS Auto Mode が提供されているすべてのリージョンでご利用いただけます。 Amazon OpenSearch Serverless がコレクショングループのサポートを開始 – 新しいコレクショングループを使用して、異なる AWS Key Management Service (AWS KMS) キーを持つコレクションの全体で OCU (OpenSearch Compute Unit) を共有できるようになりました。コレクショングループは、コレクションレベルのセキュリティとアクセス制御を維持しながら、共有コンピューティングモデルを通じて全体的な OCU コストを削減します。また、最大 OCU 制限に加えて最小 OCU 割り当てを指定することも可能になったため、遅延の影響を受けやすいアプリケーションの起動時におけるベースラインキャパシティが保証されます。コレクショングループは、現在 Amazon OpenSearch Serverless が提供されているすべてのリージョンでご利用いただけます。 Amazon RDS がスナップショットの復元時におけるバックアップ設定のサポートを開始 – スナップショット復元操作の実行前と実行中にバックアップ保持期間と希望するバックアップウィンドウを表示し、変更できるようになりました。これまで、復元されたデータベースインスタンスとクラスターはスナップショットメタデータからのバックアップパラメータ値を継承し、変更できるのは復元完了後のみでした。これからは、自動バックアップとスナップショットの一部としてバックアップ設定を表示し、復元時にこれらの値を指定または変更できるようになるため、復元後に変更する必要がなくなります。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンにあるすべての Amazon RDS データベースエンジン (MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2) と Amazon Aurora (MySQL 互換および PostgreSQL 互換エディション) で利用でき、追加料金はかかりません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit に参加しましょう。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS AI and Data Conference 2026 – 3 月 12 日にアイルランドの Lyrath Convention Centre で開催される、1 日限りの無料対面イベントです。このカンファレンスでは、Amazon Bedrock、Amazon SageMaker、QuickSight を用いたエージェントの設計、トレーニング、およびデプロイの他、エージェントの AWS データサービスとの統合、エージェントを大規模に運用するためのガバナンスプラクティスの適用といったトピックを取り上げます。アジェンダには、アーキテクト、開発者、ビジネスリーダー向けの戦略的ガイダンスとハンズオンラボが含まれています。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスであり、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われます。このイベントは、 アーメダバード (2 月 28 日)、 スロバキア (3 月 11 日)、 プネー (3 月 21 日) で開催される予定です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。こちらのリンクから、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と デベロッパー向けのイベント をご覧ください。 2026 年 2 月 16 日週のニュースは以上です。2026 年 2 月 23 日週の Weekly Roundup もお楽しみに! – Esra この記事は、Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。