私にとって 2026 年 5 月 4 日週、最もエキサイティングだったニュースは、 Amazon Bedrock AgentCore が最初のマネージド支払い機能をプレビュー したことです。これにより、AI エージェントが API、MCP サーバー、ウェブコンテンツ、その他のエージェントに自律的にアクセスして支払いを行うことが可能になります。Coinbase や Stripe と提携して構築されているため、請求、認証情報管理、コンプライアンスを実現するためにカスタマイズしたシステムを構築するという、差別化されていない面倒な作業が不要になります。 Coinbase CDP ウォレットまたは Stripe Privy ウォレットを支払い接続として接続し、セッションレベルの支出制限を設定すると、エージェントは実行中に自律的に取引を行います。私が最もワクワクしているのは、AgentCore 決済で何ができるかということです。例えば、リアルタイムの市場データに対してその場で支払いができるリサーチエージェントや、タスクの途中で有料 API を呼び出すコーディングエージェントなどです。 詳細については ブログ投稿 にアクセスし、 ドキュメント を使用してさらに詳しく調べた上で、 AgentCore CLI の使用を開始してください。 2026 年 5 月 4 日週のリリース 2026 年 5 月 4 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Agent Toolkit for AWS – AI コーディングエージェントがエラーを減らし、トークンコストを削減して、エンタープライズグレードのセキュリティコントロールを実現しながら AWS で構築するのに役立つ、本番環境ですぐに利用できるツールとガイダンスのスイートです。追加料金なしでご利用いただけます。Agent Toolkit for AWS は、 AWS ラボ で利用可能な MCP サーバー、プラグイン、スキルの後継です。使用を開始するには クイックスタートガイド にアクセスするか、 GitHub で利用できるスキルとプラグインをご参照ください。 AWS MCP サーバーの一般提供開始 – 少数の固定ツールセットを通じて、すべての AWS サービスに対するセキュアかつ認証済みのアクセスを AI エージェントやコーディングアシスタントに付与する、マネージドリモートモデルコンテキストプロトコル (MCP) をご使用いただけます。これは Agent Toolkit for AWS の一部です。詳細については、 Seb Stormacq のブログ投稿 をご覧ください。 AI エージェント向け Amazon WorkSpaces (プレビュー) – AI エージェントを使用して、マネージド WorkSpaces 環境からデスクトップアプリケーションに安全にアクセスして操作できます。この機能により、組織はエンタープライズグレードのガバナンスとコンプライアンスを完全に維持しながら、日常のワークフローを大規模に自動化できるようになります。詳細については、 Micah Walter のブログ投稿 をご覧ください。 Amazon EC2 M8idn/M8idb インスタンスと R8idn/R8idb インスタンス – これらのインスタンスは、AWS および最新の第 6 世代 AWS Nitro Card でのみ利用可能なカスタムの第 6 世代 Intel Xeon Scalable プロセッサを搭載しています。前世代のインスタンスと比較して、これらのインスタンスは vCPU あたりのコンピューティングパフォーマンスを最大 43% 向上させます。M8idn/R8idn インスタンスは最大 600 Gbps のネットワーク帯域幅を提供し、M8idb/R8idb インスタンスは最大 300 Gbps の EBS 帯域幅を提供します。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 2 周年を迎える Valkey – Valkeyは、オープンでコミュニティ主導型のテクノロジーが、単一ベンダーのどのモデルよりもイノベーションが早く、拡張性が高く、より多くの価値をもたらすことを証明しています。Valkey では Docker のプルが 1 億回 (前年比で 17 倍に増加) を超え、225 人以上のコントリビューターが 1,500 件を超えるプルリクエストを提出しました。これは、同時期の Redis の開発ペースの約 2 倍です。 Amazon ElastiCache では最新の Valkey 9.0 を使用することもできます。 SQL を使用した数十億スケールのベクトルのクエリ – 標準 SQL を使用して Amazon Aurora PostgreSQL-Compatible Edition の Amazon S3 Vectors をクエリする方法と、ベクトルの類似性の結果を 1 つのクエリでリレーショナルフィルターと組み合わせる方法を学ぶことができます。例えば、意味論的に最も類似した製品を見つけてから、1 つの SQL ステートメントにおいて価格、在庫状況、またはテナントでフィルタリングする方法などです。 AWS DevOps エージェントを使用したエンドツーエンドのエージェンティック SRE の構築 – Amazon CloudWatch、Splunk 、GitHub、Slack とシームレスに統合して、調査範囲を定義する DevOps エージェントスペースを設定する方法を学びましょう。また、Webhook を介して自動調査をトリガーする方法、緩和計画を作成する方法、エージェント対応仕様を Kiro などのコーディングエージェントに渡して実装する方法も学ぶことができます。 AWS ブログ投稿の全リストについては、必ず AWS ブログ ページをご覧ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 5 月 11 日週のニュースは以上です。2026 年 5 月 18 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

目次 はじめに 検証用リソース 1. Audit Logging とは何か？ 2. 監査ログを有効にする方法 elasticsearch.yml の設定例 Docker 環境でのログ出力設定 3. 主要な監査イベントの種類 4. ログ構造の理解（JSON 形式） 5. 実際の Audit Log サンプル 5.1. 認証失敗（存在しないユーザー / パスワード間違い） 5.2. 権限のないインデックスへのアクセス 5.3. 検索の実行とクエリ内容の記録 6. 実践的な運用 Tips ノイズのフィルタリング 7. まとめ 参考資料 はじめに システムのセキュリティを確保する上で、「誰が、いつ、何をしたか」を正確に記録する 監査ログ（Audit Logs） は欠かせません。 特に機密性の高いデータを扱う Elasticsearch クラスターにおいて、 監査ログは不正アクセスの検知やコンプライアンス要件（SOC2、PCI-DSSなど）の達成に不可欠な機能です。 本記事では、Elasticsearch の Audit Logging の仕組み、主要なイベントタイプ、そして運用上のベストプラクティスについて詳しく解説します。 検証環境今回の解説にあたり、以下の環境で動作を確認しています。 Elasticsearch バージョン: 9.4.0 デプロイ形態: Self-Managed (Docker コンテナ) ライセンス: Enterprise (Trial) ※ 監査ログ機能は Enterprise ライセンスでのみ提供されます。 ログ出力先: JSON ファイル 検証用リソース 今回の検証で使用した docker-compose.yml や設定ファイル一式は、以下の GitHub リポジトリで公開しています。 elastic-blogs/2026-05-audit-logging at main · SIOS-Technology-Inc/elastic-blogs A sample code for blogs about Elastic. Contribute to SIOS-Technology-Inc/elastic-blogs development by creating an accoun... github.com 1. Audit Logging とは何か？ Elasticsearch の監査機能（Audit Logging）は、クラスター内で発生するセキュリティ関連のイベントを記録する機能です。 これには、認証の成功・失敗、インデックスへのアクセス、セキュリティ設定の変更などが含まれます。 この機能は Elasticsearch の「Security」スタックの一部として提供されており、設定を有効にすることで利用可能になります。 2. 監査ログを有効にする方法 監査ログはデフォルトでは 無効 です。 有効化するには elasticsearch.yml に設定を追加し、ノードを再起動する必要があります。 elasticsearch.yml の設定例 # 監査ログを有効化 xpack.security.audit.enabled: true # 検証用：実行されたクエリ本文（request.body）も記録する xpack.security.audit.logfile.events.emit_request_body: true # 全てのイベントタイプを対象にする（運用時は絞り込みを推奨） xpack.security.audit.logfile.events.include: _all ※GitHub のサンプルでは、docker-compose.yml ファイルで上記を定義しています。 [!CAUTION] emit_request_body を true にすると、クエリに含まれる機密情報（個人情報など）がそのままログに出力される可能性があります。 本番環境での利用には十分注意してください。 Docker 環境でのログ出力設定 今回は Docker コンテナを利用しており、ログ出力を適切に制御するために $ES_HOME/config/log4j2.properties を編集し、 /usr/share/elasticsearch/logs/＜クラスター名＞_audit.json に出力されるよう構成しています。 3. 主要な監査イベントの種類 記録されるイベントの中でも、特に運用監視で重要なものを紹介します。 イベント名 内容 監視のポイント access_granted 操作が許可された 正常なアクセス。特権操作の追跡に利用。 access_denied 操作が拒否された 権限不足の確認。短時間の多発は攻撃の予兆。 authentication_failed 認証に失敗した 不正なログイン試行、またはアプリの設定ミス。 authentication_success 認証に成功した 特権ユーザー（elastic 等）のログイン監視に。 security_config_change セキュリティ設定変更 ロールやユーザー定義の変更。内部不正防止に重要。 4. ログ構造の理解（JSON 形式） 監査ログは構造化された JSON 形式で出力されるため、SIEM や Kibana での解析が容易です。 timestamp: イベント発生時刻 event.action: イベントの種類（access_granted など） user.name: 操作を行ったユーザー名 origin.address: リクエスト送信元の IP アドレスとポート action: 実行された内部アクション（indices:data/read/search など） url.path: リクエスト先のパス request.body: 実行されたクエリ内容（設定時のみ出力） 5. 実際の Audit Log サンプル ここでは、具体的な操作とそれに対応するログの出力を確認します。 ※今回の検証環境では、/usr/share/elasticsearch/logs/＜クラスター名＞_audit.json ファイルに出力されます。 5.1. 認証失敗（存在しないユーザー / パスワード間違い） ユーザー名やパスワードを間違えた場合、event.action: “authentication_failed” が記録されます。 実行コマンド: curl -X GET -u dummy:password --cacert ./certs/ca/ca.crt https://localhost:9200/ 出力ログ（抜粋）: { "type":"audit", "timestamp":"2026-04-30T01:22:22,842+0000", "event.action":"authentication_failed", "user.name":"dummy", "origin.address":"192.168.143.2:35134", "url.path":"/", "request.method":"GET" } 補足: ログ上はユーザー名間違いとパスワード間違いを区別できませんが、user.name を確認することで、既存ユーザーへの攻撃か未知のユーザーによるものかを判断できます。 5.2. 権限のないインデックスへのアクセス 認証には成功しているものの、操作権限がない場合は access_denied となります。 実行コマンド: # guest1 ユーザー（閲覧権限なし）で検索を実行 curl -X GET -u guest1:password --cacert ./certs/ca/ca.crt "https://localhost:9200/kibana_sample_data_logs/_search?pretty" 出力ログ（抜粋）: { "type":"audit", "event.action":"access_denied", "user.name":"guest1", "action":"indices:data/read/search", "indices":["kibana_sample_data_logs"] } 5.3. 検索の実行とクエリ内容の記録 emit_request_body を有効にしている場合、どのようなクエリが投げられたかも記録されます。 実行コマンド: curl -X POST -u elastic:password --cacert ./certs/ca/ca.crt "https://localhost:9200/kibana_sample_data_logs/_search?pretty" \ -d '{"query":{"match":{"geo.dest":"CN"}}}' 出力ログ（抜粋）: { "event.action":"authentication_success", "user.name":"elastic", "url.path":"/kibana_sample_data_logs/_search", "request.body":"{\"query\":{\"match\":{\"geo.dest\":\"CN\"}}}" } 6. 実践的な運用 Tips 監査ログは非常に詳細ですが、デフォルトのままではログサイズが膨大になり、ディスクやパフォーマンスに影響を及ぼします。 ノイズのフィルタリング 特定の監視用ユーザーや、信頼できる内部通信をログから除外することで、重要なイベントに集中できます。 設定例: # 特定のイベントを除外 xpack.security.audit.logfile.events.exclude: ["anonymous_access_denied"] # 特定のユーザーを監視対象から除外するフィルタ例 xpack.security.audit.logfile.events.ignore_filters: filter_monitor: users: ["monitor_user"] 7. まとめ Elasticsearch の Audit Logging は、クラスターの透明性を高め、インシデントへの対応力を向上させる強力な武器です。 1. まずは検証環境で有効化し、出力されるログの量と内容を確認する。 2. 必要なイベントに絞り込むことで、ストレージの消費とパフォーマンスへの影響を最小限にする。 3. Kibana や SIEM で可視化し、異常なアクセスパターンを即座に検知できる体制を整える。 セキュリティの第一歩として、ぜひ設定を試してみてください。 参考資料 Elasticsearch Guide: Security event audit logging Audit settings reference https://github.com/SIOS-Technology-Inc/elastic-blogs/blob/main/2026-05-audit-logging/ The post Elasticsearch Audit Logging 解説：セキュリティ監視とコンプライアンスのための第一歩 first appeared on Elastic Portal .

法人ディベロップメント課のS.Sです。 マイナビBiz / LIVING の新規開発・保守運用を行なっております。 この記事では、現在、私が関わっている、とあるPJ で、Techtus さまとの協業（オフショア開発）により、PJ を進める中での経験や気づきについて、ご共有できればと思います。（※ PJ は、現在進行中です） オフショア開発事情について気になる オフショア開発の難しい点や良い点について知りたい 経験を踏まえて、次回オフショア開発を進めるならどうしたいか という方には、お力添えになれる記事かと思います。 参照: Techtus とは オフショア開発の3つの良さ １、開発速度が本当に早い！ 協業で開発を進めて頂いた Techtus さまの開発チームの開発速度は非常に早く、こちら側で元々想定していたスケジュールから、1ヶ月以上巻きで進めてもらうことができました。 今回、実装して頂いた開発者は、2名体制でしたが、2画面/日ペースでPR レビュー依頼が届き、レビューコメントへの対応も基本的に 即時返信・対応で、滞りなくスムーズに進んだ 印象でした。 ２、にも書いていますが、 技術的なレベルも高く、技術的な詰まりなども、ほぼなく進めて頂けたのも開発速度が早い 理由なのかなと思っております。 ２、開発チームの技術力が高い！ 本PJでは、Next.js（v15） による開発を進めているのですが、新しい機能活用、技術/SEO提案などが、頻繁に飛び交いながら、PJ が進んでおります。 迅速に、依頼画面を作って頂くだけに止まらずに、 積極的に技術的な付加価値を提供頂き、ともにブラッシュアップして開発を進めていけた のも非常に感謝でした。 ３、言語の壁なく、素早く問題解決が進められるスムーズな連携！ オフショア開発をする、となった時に最初に思い浮かんだのが言語の壁でした。 しかし、Techtus さまでは、 コミュニケーター（マイナビと Techtus エンジニア間で日本語 / ベトナム語 でやり取りしてくださる人）がいるため、言葉の壁を感じず、いつもの開発のように進めることができました。 また、コードレビュー時には、お互いに英語でのやり取りが可能でしたので、ここも言葉で悩むことなくスムーズに進められた印象でした。 私自身、英語力に関しては簡単な英語の読解ができるくらいのレベルで伝えることには不安がありましたが、今は Google 翻訳があるので、そんなツールも活用しつつ、特にストレスなく対応できました。 やり取りを進めていく内に自然と、Google 翻訳に頼る頻度は減っていくので、さらにスムーズになった印象でした。 （副次的なものですが、初見PRレビュータイミングでは、訳さずに読解することで、英語力が少し上がるのもよかったです。（次は、ベトナム語にもチャレンジしてみたいな。）） オフショア開発で工夫した3つの点 １、ファーストレスポンスを最速で行う オフショア開発では、開発している場所・時間が物理的に違います。 そのため、お互いに相手方の状況が見えません。 したがって、 分からない状態での「待ち」が相当なストレスを生み、開発パフォーマンスに悪影響を与えてしまいます。 なので、普段の開発よりも増して、ファーストレスポンス速度を早めるように意識しました。 これによって、お互いに、分からない状態での「待ち」を作らないことで、互いにノンストレスかつ、滞り少なくトントンと開発を進めることができたのかなと思います。 ２、前提を含めた丁寧な説明 オフショア開発では、相手方は、初めて向き合うサービスであることがほとんどです。 自分たちが思っている当たり前や前提がほぼ 0 のため、なるべく丁寧に、前提説明をする ように努めました。 開発を進める中での質問やレビュー時には、 「こうこう、こういう理由で、こんな実装してほしい」 などを 具体的かつ論理的に伝えることで、納得感を持って開発を進めてもらえた のかなと思います。 ※ ここは、工夫した点でも、あり改善余地ありの点でもあるので、そちらに記載します ３、視覚的情報（+数値）を用いた意思共有 言葉の壁はありませんでしたが、開発文化やニュアンス、表現、受け止め方の違いは、あったかなと感じました。 そんな違いを問題にしないために、視覚的情報を用いるように工夫しました。 この手法を用いることで、 見たそのもの、そのままは、どこの誰が見ても基本的には同じように捉えることができます。 数字についても同様です。 なので、視覚的情報と、数値を用いることで、認識ズレを減らせたのかなと思います。 言葉のみの場合： タイトル: タイトルの位置を気持ち下げて、全体としていい感じに中央っぽく見えるようにしてください。 メール欄 メールの入力欄は、今より少し大きめにして、押しやすそうな印象に寄せてください。 パス欄 パスワードの入力欄も、メール欄と同じくらいのサイズ感に整えてください。 ボタン ボタンは角をもう少し丸くして、入力欄との間隔もちょっと広めに調整してください。 視覚的情報を用いた場合： 圧倒的に、後者の方がズレなく伝わることが体感できます。 オフショア開発で苦労した3つの点 １、仕様を認識ズレなく理解してもらうこと 先ほどの工夫の箇所でも書きましたが、 前提や背景知識が違うので、こちら側の当たり前は、相手方の当たり前ではなかった です。 特に、開発初期は、レビュータイミングで、認識がズレていたり、こちら側で当たり前としてしまっていたことが、相手方の当たり前ではないことでやり直しが発生してしまうこともありました。 早めに気づいて改善することで軌道修正はできましたが、当初は苦労しました。 ２、開発環境の共有 完全な自チームの場合であれば、AWSを含む各種アカウントの共有がなされている、かつ物理的に近い距離で開発ができ、環境共有に困ることは、ほぼありません。 しかし、 オフショア開発の場合は、各種アカウントの全てではなく、必要なものかつ、共有できるものが限られる中で対応を進めていく 必要がありました。 そのため、開発の進め始めに、あちらの local では動いているが、こちらの local では動かない、というようなタイミングがありました。（Github, Docker 利用をしていたのでベースの共有化はできてはいるものの。。） ３、開発手法や進め方の足並みを揃えること 当初、開発文化が異なるチーム同士で開発を進める中で、 どんな手法を用いて どんな粒度で どんなルールでやっていくか という所の認識合わせが困難でした。 事前に、キックオフ会の実施や、ドキュメントを作成して、足並みが揃うよう努めましたが、やはり、前提や背景、文化が違うもの同士で協業をするというのもあり、 「あ、この観点や考え方もドキュメントに追加しないとな」 というものがボロボロと出てきた印象がありました。 PJ を進める業務を行いつつ、こういった基礎の部分を同時修正していくことに苦労 しました。（もっと早めの段階の問題出しが重要だなと） ただし、ここを軌道修正したことで、様子見やすれ違い頻度も減り、スムーズにPJ が進むようになった印象がありました。 次回、オフショア開発をする時に、気をつけたい3つのポイント 最後に、ここまでの経験を踏まえて、次回、オフショア開発を進める際に、気をつけたいポイントをまとめたいと思います。 １、最初に、開発手法や進め方・ドメイン知識の共有の時間をしっかり取る 今回は、キックオフ（全体のスケジュール感や対応範囲の認識合わせ）に加えて、開発者向けドキュメントを作成し、共有することで、最初の認識合わせを終えました。 しかし、これでは、軌道修正タイミングが遅れてしまうなと反省しています。 最初に、 開発者の認識合わせの時間をしっかりと確保し、その中でこちら側、あちら側のそれぞれの認識を理解しあって、足りないものに気づき補うことで、開発スタートとともに素早くスタートダッシュを切れるようになる と思いました。 早めに問題を浮き彫りにした方が、全体として効率・改善速度は早められますからね。 ２、スプリント単位での依頼チケットの丁寧な概要説明と時間の確保 スプリント単位ごとに、チケット依頼タイミングに、概要説明の時間をしっかりと確保し、認識合わせを密にしていきたい です。 このようなやり方は、一見、工数がかかってしまうように感じてしまいますが、これにより、手戻りやスムーズなレビュー・マージができるようになるかと思いました。 チケット内容に、概要記載が前提なので、ある程度打ち合わせを繰り返す中で、OKなものはサクサク進めていけます。 そのため、 最初の最初は、工数かかる体感はあるかもしれないですが、段々とその負荷は減り、認識ズレもなくなるので、全体で見たら、最適な進め方 なのかなと思います。 このようなイメージです。 ３、検証環境の対応順序を早めにする 上記の通りですが、次回以降は、local でベースの環境構築ができたら、すぐに、検証環境の準備を進めていくようにしたいです。 デジ戦側・Techtus 側・事業部側が、共通して同じ環境で確認ができる検証環境を先んじて作っておくことで、同じ目線で動作確認や修正を前倒しで進めていくことができるため です。 検証環境の構築は、インフラメンバーへ構築依頼が必要になるため、始めにそう決めておかないといけない部分だと思っており（いきなり依頼は物理的に難しい）、次回、スケジューリングを立てるタイミングで必須で早めの設定と依頼を進めていきたいと思いました。 最後に ここまで、振り返ってみて感じたことの一言でまとめると、 共通認識を早めに、丁寧に、細かくアクションを取ることが重要 ということかなと思いました。 オフショア開発に限らずですが、より文化や背景、物理的な距離、ドメイン知識の違いなどがどうしてもある中で、 早め早めに、「共通認識」を持つ機会を能動的に作っていくことで、そのズレを無くし、スムーズなPJ 進行ができる のかなと思います。 こうして、文章で書いているとすごく当たり前ではあると思うのですが、 当たり前だからこそ、いざやるタイミングで抜けてしまいがち なので、未来の自分が新PJ スタートタイミングでこの記事を見て、戒めようと思います。