セーフィー株式会社でサーバーサイドエンジニアを務めている尹です。 近年、AI エージェントやプロンプトエンジニアリングといった言葉が広く使われています。私自身、バックエンドの開発や社内ツールの自動化を進める中で、プロンプトの「使い捨て」に課題を感じていました。 通常、プロンプトはその場で書いて使い捨てるものとして扱われがちです。しかし、開発で繰り返し使う指示ほど、毎回ゼロから書き直すのは非効率で、書く人によって品質もばらつき、変更履歴も残りません。本来であれば再利用できるはずの指示が、資産として蓄積されずに失われてしまう――これが私の感じていた課題です。 本記事では、こうした使い捨てのプ

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 さて、7月28日（火）に東京・赤坂インターシティにて、「 AWS Bedrock LLM Day Japan 」が開催されます。Anthropic や OpenAI、OSS の最新モデルから、先日の AWS Summit New York での発表まで、生成 AI の最新動向を半日で体験いただけるイベントです。Amazon Bedrock を活用してビジネスにイノベーションを起こされているユーザーの事例セッションもご用意しています。生成 AI の最新情報のキャッチアップや、ビジネスへの活かし方に課題をお持ちのお客様にとって有用な機会ですので、ぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年7月6日週の主要なアップデート 7/6(月) Amazon SageMaker HyperPod が Disaggregated Prefill and Decode (DPD) に対応 Amazon SageMaker HyperPod が、LLM 推論の prefill フェーズと decode フェーズを分離して実行する Disaggregated Prefill and Decode (DPD) に対応しました。計算集約的な prefill とメモリ帯域集約的な decode をそれぞれ専用の GPU プールに割り当て、KV キャッシュを Elastic Fabric Adapter (EFA) 経由で転送します。これにより、トークンごとのレイテンシーが安定し、厳しいレイテンシー SLO のもとでもスループットを高められます。prefill / decode の容量を独立してスケールでき、インテリジェントルーターがリクエストを自動で最適配分するため、コストとパフォーマンスのバランスを取りやすくなります。EKS オーケストレーターと EFA 対応インスタンスを使用でき、SageMaker HyperPod が提供されている全リージョンでご利用いただけます。 Amazon Cognito がレート制限のセルフサービス設定に対応 Amazon Cognito が、API レート制限をセルフサービスで設定できる新しいプロビジョニング API に対応しました。コンソールまたは API から、アカウントレベルの上限までレート制限を自分で設定でき、変更は即座に反映されます。これまでサービスクォータ経由で必要だった手動の審査プロセスや待ち時間なしに、トラフィックパターンに応じてレート制限を柔軟に増減できます。急なトラフィック増加やキャンペーン時にも、事前のクォータ引き上げ申請を待たずに対応できるようになります。Amazon Cognito が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon CloudWatch Application Signals が Service Events を提供開始 Amazon CloudWatch Application Signals が、例外・レイテンシーのスナップショット、関数レベルのパフォーマンスデータ、デプロイイベントを自動収集する Service Events を提供開始しました。ADOT SDK や CloudWatch Observability EKS アドオンで計測しておくだけで、コードを変更することなくこれらのイベントを自動的にキャプチャできます。デプロイ後に新たに発生した例外を素早く特定できるため、リリース後の問題調査にかかる時間を短縮できます。オプションで関数呼び出しメトリクスを有効にすれば、さらに細かい可視化も可能です。Java / Python / JavaScript に対応し、すべての商用 AWS リージョンでご利用いただけます。 7/7(火) Amazon SageMaker Unified Studio が既存 MWAA 環境のインポートに対応 Amazon SageMaker Unified Studio が、既存の Amazon Managed Workflows for Apache Airflow (MWAA) 環境をプロジェクトにインポート・接続できるようになりました。Workflows ツールで「Add connection」を選択し、Airflow の設定を入力するだけで、運用中の環境をそのまま利用できます。DAG を再作成したり移行したりすることなく、分析や機械学習と同じインターフェースからワークフローを管理できる点が魅力です。Apache Airflow 3 以降では、ドラッグ＆ドロップエディタによるビジュアルオーサリングも利用できます。Amazon SageMaker Unified Studio が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon ECS Managed Instances が GPU の管理料金を最大 60% 引き下げ Amazon ECS Managed Instances が、GPU インスタンスの管理料金を引き下げました。G シリーズは 35%、P シリーズおよび AWS Trainium は 60% の値下げとなり、GPU ワークロードをよりコスト効率よく実行できます。ECS Managed Instances はインフラを AWS が完全管理し、GPU メトリクスの自動監視や、ハードウェア障害の自動検出・修復も備えています。CloudWatch Container Insights による可視化と障害時の自動復旧により、運用負担を抑えつつ稼働停止時間を最小化することが可能です。ECS Managed Instances が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon RDS for Oracle が Oracle Database 26ai のサポートを開始 Amazon RDS for Oracle が、最新の長期サポートリリースである Oracle Database 26ai のサポートを開始しました。自然言語から SQL を生成・実行する Select AI や、ベクトル埋め込みをデータベース内に格納してセマンティック検索を実現する Oracle AI Vector Search を利用でき、SQL 内で直接 RAG (Retrieval Augmented Generation) を構築しやすくなります。データをデータベース外に持ち出すことなく、Anthropic Claude や Amazon Nova、Meta Llama などの基盤モデルを活用した高度な分析が可能です。JSON Relational Duality Views や SQL Property Graphs といった新しいデータアクセス方法も加わり、開発者やビジネスユーザーの生産性向上につながります。すべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンでご利用いただけます。 7/8(水) Amazon Redshift の Graviton ベース RG インスタンスがトレーリングトラックで利用可能に Amazon Redshift の Graviton ベースの RG インスタンス（rg.xlarge、rg.4xlarge）が、安定性を重視するトレーリングトラック（P201）でも利用できるようになりました。RG インスタンスは RA3 インスタンスと比較して最大 2.4 倍高速なクエリ性能を提供し、vCPU あたりのコストを 30% 削減できます。本番環境の安定性を優先するお客様が、検証済みのトラック上でこの高いコストパフォーマンスを享受できます。AWS マネジメントコンソール、AWS CLI、AWS SDK から、新規クラスターの作成または既存クラスターのリサイズでご利用いただけます。 AWS Security Hub が Network Scanning を提供開始 AWS Security Hub が、環境内のリソースがインターネットから実際に到達可能かどうかを検出する Network Scanning を提供開始しました。セキュリティグループやルートテーブルの設定を評価するだけでなく、実際にプローブを行い、パブリック IP アドレスや仮想マシン、ロードバランサー、到達可能なポートと稼働中のサービスを特定して検出結果を生成します。設定ベースの検出を補完し、外部から実際にアクセスできるリスクを正確に把握できるため、攻撃対象領域の削減に役立ちます。AWS だけでなく Azure 環境も対象とし、Security Hub Essentials の契約であれば追加費用なしで、個別アカウントや組織全体で有効化できます。AWS Security Hub をサポートするすべての商用リージョンでご利用いただけます。 Amazon Aurora DSQL が変更データキャプチャ (CDC) の一般提供を開始 Amazon Aurora DSQL が、変更データキャプチャ (CDC) の一般提供を開始しました。insert / update / delete 操作の結果を変更イベントとして自動的にキャプチャし、Amazon Kinesis Data Streams に配信できます。これにより、マイクロサービス間のデータ同期や、AWS Lambda 関数のトリガー、Amazon S3・Amazon Redshift・Amazon OpenSearch Service へのデータ連携を、インフラを管理することなく実現できます。データベースワークロードへの影響を抑えた設計により、パフォーマンスに影響を与えずに変更データを取得できるのは実運用で効いてきます。Aurora DSQL が利用可能なすべての AWS リージョンでご利用いただけます。 7/9(木) Amazon SageMaker Feature Store が一括書き込みとレコード一覧の API を追加 Amazon SageMaker Feature Store が、複数レコードを単一リクエストで一括書き込みできる BatchWriteRecord と、フィーチャーグループ内のレコード識別子をページ単位で一覧表示できる ListRecords を追加しました。BatchWriteRecord は複数のフィーチャーグループにまたがる書き込みにも対応し、API 呼び出しを削減して、低レイテンシーで取り込みが可能になるほか、一部のレコードが失敗してもリクエスト全体は継続されます。ListRecords により、フィーチャーグループの内容を参照・監査・ライフサイクル管理でき、カスタムツールを構築する必要がなくなります。あわせて、オフラインストアのテーブル名・データベース名をカスタムで指定できるようになり、データカタログの整理も容易になりました。Amazon SageMaker Feature Store が利用可能なすべての AWS リージョンでご利用いただけます。 AWS Config が 191 個のマネージドルールを追加 AWS Config が、Amazon Bedrock、Amazon SageMaker、Amazon ECS、Amazon EKS、Amazon RDS、Amazon Redshift、Amazon S3、AWS CloudTrail など主要サービスに対応した 191 個のマネージドルールを追加しました。暗号化、ロギング、パブリックアクセス、ネットワークセキュリティ、データ保護といった設定を自動で評価でき、AI ワークロードからクラウドインフラまでガバナンスの適用範囲が広がります。ルールは個別に、またはコンフォーマンスパックとして一括でデプロイできるため、複数サービスにまたがるベストプラクティスの適用やコンプライアンス管理を効率化できます。 7/10(金) Amazon EC2 R8in / R8ib / R8idn / R8idb インスタンスが東京リージョンなどで利用可能に メモリ最適化インスタンスの Amazon EC2 R8in、R8ib、R8idn、R8idb が、アジアパシフィック（東京）およびヨーロッパ（フランクフルト、アイルランド）を含むリージョンで追加で利用可能になりました。第 6 世代 Intel Xeon Scalable プロセッサと第 6 世代 AWS Nitro カードを搭載し、前世代（R6in / R6idn）と比較して vCPU あたり最大 43% のコンピューティング性能向上を実現します。R8in / R8idn は最大 600 Gbps のネットワーク帯域幅を、R8ib / R8idb は最大 300 Gbps の EBS 帯域幅を提供し、リアルタイムのビッグデータ分析や分散キャッシュ、AI/ML クラスター、大規模商用データベースなど、メモリ集約型のワークロードに適しています。 AWS DMS Schema Conversion が AWS MCP Server による AI エージェント自動化に対応 AWS Database Migration Service (DMS) Schema Conversion が、AWS MCP Server を介した AI エージェント自動化に対応しました。Kiro、Claude Code、Cursor などの AI コーディングエージェントを接続することで、自然言語による指示から、プロジェクト作成、ソースメタデータの参照、スキーマ変換、評価レポートの生成、結果のエクスポートまで、マイグレーションのワークフロー全体を IDE から直接実行できます。ストアドプロシージャや関数、トリガーといったコードの変換も支援し、試行錯誤のループを削減できる点がうれしいポイントです。追加料金なしで、既存のすべての ソース/ターゲットエンジンの組み合わせでご利用いただけます。 AWS Organizations が新規組織にアカウント離脱防止のセキュリティコントロールをデフォルト適用 AWS Organizations が、コンソールから新規に組織を作成する際に、メンバーアカウントの組織からの離脱や自己クローズを防ぐサービスコントロールポリシー (SCP) を自動的に適用するようになりました。これにより、深いセキュリティ知識がなくても、初日から強固なガバナンスパターンを確立でき、初期構成が簡略化されます。適用される設定は必要に応じて自由にカスタマイズできます。現在では、米国東部（バージニア北部）、AWS GovCloud (US-East / US-West)、中国リージョンでご利用いただけます。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon Quick です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

こんにちは。開発1部の村上です。 本記事は AIブログリレー 8本目 です。 エブリーではAIエージェントを社内のあらゆる業務で活用していくことを目指しています。そのAIエージェントたちを支えるのがデータ基盤です。そしてこの基盤を、AIにデータを「読ませる」ためのものから、AIエージェントを「動かす」ためのものへ進化させていきたいと考えています。本記事では、そのために必要なステップを整理します。 人のための基盤から、AIエージェントを "動かす" 基盤へ これまでのデータ基盤は、暗黙のうちに「人が使う」前提で設計されてきました。ダッシュボードを見るのも、SQLを書くのも人です。「この売上には手数料が含まれているんだっけ？」という定義の曖昧さも、人が文脈と経験で補完してきました。 利用者がAIエージェントに変わると、この暗黙の補完が効かなくなります。さらにエージェントが増えていくことを前提に立つと、基盤は特定の誰かの道具ではなく、すべてのエージェントが立つ共通の足場になります。足場が曖昧なままエージェントを増やすと、曖昧さの解釈がエージェントの数だけ生まれてしまいます。 さらにAIエージェント時代のデータ基盤は、データを参照して質問に答えるといった、データを「読める」ようにするだけでは不十分だと考えています。データにもとづいて業務の中で行動するエージェントを支える、つまりAIエージェントを「動かす」ところまでを、基盤の責務として考えていく必要があります。 このような基盤には、次の3つのステップがあると考えています。 参照できる : あらゆるデータを収集し、AIが参照可能な状態にする（メダリオンアーキテクチャ） 解釈を間違えない : 指標や用語の意味を一元定義する（セマンティックレイヤー） 行動できる : 業務のオブジェクト・関係・アクションを機械可読にする（オントロジー） 順に見ていきます。 あらゆるデータを集め、AIが参照できる状態にする 最初のステップは、構造化・非構造化を問わずデータを収集し、AIが参照できる状態にすることです。ここで採用しているのがメダリオンアーキテクチャです。 メダリオンアーキテクチャは、データをBronze（生データ）、Silver（クレンジング・整形済み）、Gold（ビジネス利用可能）という層に分けて、段階的に品質を昇格させていく設計です。 （出典: What is a Medallion Architecture? | Databricks ） ポイントは「きれいなデータを一発で作る」のではなく、生データを捨てずに保持したまま、信頼できる状態へ段階的に到達させることにあります。AIエージェント時代には、この層の分離がもう一つの意味を持ちます。エージェントにどの層を見せるかを制御できることです。品質保証されたGold層だけをエージェントの参照先にすることで、生データの揺らぎに引きずられた回答を構造的に防げます。 このステップまで整うと、Text to SQLが動き始めます。「先月のチャネル別売上は？」と聞けばエージェントがSQLを書いて答えてくれる。人が結果を確かめながら使う形であれば、AI活用はここから十分始められます。 ただし、「参照できる」と「正しく解釈できる」の間には溝があります。テーブルとカラムが見えることと、その数字が何を意味するかを理解していることは、別の問題だからです。 AIが解釈を間違えない状態にする 2つ目のステップは、セマンティックレイヤーの整備です。指標の定義、ディメンション、シノニム、用語といったビジネス上の意味を、BIツールやエージェントの側ではなくデータ層で一元的に定義します。 たとえばCAC（顧客獲得コスト）の定義がエージェント間で曖昧だったとします。すると、事業KPI分析エージェントとマーケティングエージェントが異なる計算式のCACを見て動いてしまう、といったことが起こります。しかもどちらのSQLも正しいため、この食い違いに気づくのは困難です。 Goldに計算済みのCACテーブルを置く手もありますが、CACのような比率指標は計算済みの値を再集計できません。「全チャネル合算では?」と粒度の違う質問が来た瞬間、エージェントはCACの平均を取って間違えます。だから必要なのは計算結果ではなく、計算式の定義です。 セマンティックレイヤーは、この定義をデータ層で管理します。Databricksの実装で言えば Unity Catalog Business Semantics がこれにあたります。中核となるmetric viewは、測度（CACの計算式そのもの）と、それを集計するディメンションを分離して定義する仕組みで、SQL・ダッシュボード・エージェントのどこから利用しても、同じ定義から同じ計算が決定的に実行されます。加えて glossaryやdomains といった用語・文脈を整備する機能の発表も続いており、この領域への投資はプラットフォーム側でも加速しています。 効果は数字にも表れています。dbtが2026年に再実施した ベンチマーク では、Text to SQL単体の精度は最新モデルで64.5%まで改善した一方、セマンティックレイヤー経由ではカバーされた質問に対してほぼ100%に到達しています。モデルの進化だけでは埋まらない差が、定義の一元化で埋まるということです。 ここまで整うと、エージェントは指標を正しく計算し、要因を正しく分解できるようになります。「読む」はほぼ完成です。しかし、分析だけではなく行動まで促そうとすると、まだ決定的に足りないものがあります。 AIが行動できる状態にする オントロジーとは何か 3つ目のステップがオントロジーの構築です。このブログリレーの 1本目でCTOも紹介 していましたが、オントロジーとは、業務を構成する オブジェクト （顧客、受注、商品...）、その 関係 、そしてそれぞれに実行できる アクション を、機械可読な形で定義したものです。 もともとオントロジーは知識工学の用語で、古典的にはオブジェクトと関係の記述を指します。エンタープライズの文脈ではPalantirがこれを拡張し、オブジェクト・プロパティ・関係というセマンティックな要素に加えて、アクションという「世界を変更する操作」までをオントロジーに含めています（参考: Palantir Ontology ）。 業界の現在地 この領域は、まさに製品化が始まったところです。Databricksも2026年6月のData + AI Summitで独自のオントロジーである Genie Ontology を発表しました（現在プレビュー）。テーブル・クエリ・ダッシュボードから事業の文脈を自動抽出して生きたグラフを構築するもので、Unity Catalogで定義したセマンティクスがこのオントロジーに供給される構造になっています。アクション定義までは含まないかもしれませんが、オブジェクトと関係の自動構築という意味で同じ方向に進んでいます。 複数のエージェントが、同じ地図の上で動く 例として、定期購入型のEC（サブスクEC）でオントロジーの一部を考えてみます。 構成要素は次の4つです。 オブジェクト : 顧客、定期契約、定期受注（第n回の個別のお届け）、商品、在庫引当、配送 関係 : 顧客は定期契約を持つ。定期契約は定期受注を生成する。定期受注は商品を含み、在庫を引き当て、配送に紐づく 状態 : 定期受注は「受付中 → 出荷確定 → 発送済み」と遷移する。「お届け日の2日前に出荷確定へ移る」という締切の定義もここに属する アクション : 各オブジェクトに対する操作。前提条件・効果・権限がセットで定義される 配送先を変更する（前提: 状態が受付中） メニューを差し替える（前提: 状態が受付中、かつ、おまかせコース） 次回分の変更を予約する（対象: 定期契約。いつでも可） このオントロジーの上で、複数のエージェントが動くとどうなるか。同じサブスクECで動くCSエージェントと在庫オペレーションエージェントがいるケースを考えます。ここで見たいのは、互いに無関係な2つの出来事です。ある日、CSエージェントには顧客から「配送先を変えたい」という問い合わせが届きます。一方、在庫オペレーションエージェントの側では、入荷遅延によって木曜出荷分の在庫が不足していました。別々のトリガで、2体はそれぞれ独立に動き出します。それぞれの動きを並べるとこうなります。 CSエージェント 在庫オペレーションエージェント 起きたこと 顧客「配送先を変えたい」 入荷遅延で木曜出荷分の在庫が不足 関係の辿り方 顧客 → 定期契約 → 定期受注 商品 → 在庫引当 → 定期受注 受付中の受注への行動 「配送先を変更する」を実行 「メニューを差し替える」で欠品を吸収 出荷確定済みの受注への行動 「次回分の変更を予約する」に切り替え、「次回分から新しい住所にお届けします」と案内 引当済みのため対象外。手を付けない この2体は、会話もしていなければ、仕事の引き継ぎもしていません。起点も違います。片方は顧客から、もう片方は商品から関係を辿り、同じ定期受注オブジェクトに到達しているだけです。そして2体が共通して参照しているのは、定期受注の「状態」と、その状態を前提条件に持つアクションの定義です。顧客対応と欠品対応という別々の業務が矛盾しないのは、「出荷確定後は変更できない」というルールがアクションの前提条件として基盤に一つだけ存在して、両方がそれを参照しているからです。 ルールを各エージェントのプロンプトやMCPツールの説明文に書けば済む、と思うかもしれません。実際、エージェントが1〜2体のうちはそれで動きます。しかしそれは定義のコピーです。10体に定義がコピーされた世界では、ルール変更のたびに10箇所の改修が発生し、直し漏れたエージェントは旧ルールで動き続けます。API側で変更を拒否することはできますが、それで防げるのは誤った実行までで、エージェントは「変更できますよ」と案内してから実行に失敗する可能性もあるかもしれません。オントロジーはこの知識を参照に変えます。エージェントが何体いても、参照先は1つです。 この構造の強さは、ルールが変わる日にはっきり現れます。出荷締切を前日から2日前に早める、という業務判断が下りたとします。変更するのは基盤上の定義1箇所。その瞬間から、CSエージェントの案内も、在庫オペレーションエージェントの組み替え範囲も、将来作られる何体目かのエージェントの行動も、すべて同時に新しいルールに従います。 3層の上でエージェントを動かす ここまでの3ステップを一度に眺めると、こうなります。ステップ1でデータが見える。ステップ2で数字を正しく読める。ステップ3で「何ができて、実行すると何がどう変わるか」が分かる。 ここまではCSと在庫オペレーションの2体で見てきましたが、この土台の上には、マーケティングエージェント、予実管理エージェント、と業務ごとのエージェントを並べていけます。全員が同じ指標定義を読み、同じオブジェクトとアクション定義の上で動く。データ収集だけを進めてエージェントを増やすと、指標・フロー・ルールの定義が各エージェントのプロンプトへサイロ化していきますが、3層が整った基盤の上では、すべてのエージェントが同じ世界を見て行動します。 エブリーはどう取り組むか エブリーではステップ1にこれまで投資を続けてきており、メダリオンアーキテクチャによる基盤は整いつつあります。ステップ3のオントロジーは技術的にもまだ新しく、すぐに全面適用できる段階ではありません。そこで今期は、ステップ3を意識しながら、ステップ2のセマンティックレイヤーを整備していきます。 このステップ2と3は、アプリケーションのコードと人の暗黙知に散在している世界の定義を、基盤上の宣言的で機械可読な一箇所へ引き上げていく作業です。「CACの計算式」も「出荷確定後は変更できない」という定義も、今この瞬間もアプリケーションの実装の中に、そしてオペレーションを担う人の頭の中に存在しています。 そして、ここが重要なのですが、この作業はデータチームが外から観測するだけでは完遂できません。「締切を何時にするか」「CACに何を含めるか」は、データの中に答えがある問題ではなく、ビジネスの意思決定そのものだからです。セマンティックレイヤーもオントロジーも、技術の問題である以前に、ビジネスと一緒に定義を決めにいく組織の問題です。だからこそ、このリレーの 1本目でCTOが書いた 、エンジニアが事業の中に入ってその基盤を作っていくという話になるのだと思っています。 基盤を育てることと、ビジネスと共に定義を決めること。この両方が揃ったとき、データ基盤はAIにデータを読ませる基盤から、AIエージェントを動かす基盤になります。 さいごに 本記事では、AIエージェントを「動かす」ためのデータ基盤を、参照できる・解釈を間違えない・行動できる、という3つのステップで整理しました。エブリーではこの基盤づくりをこれから本格化させていきます。進捗や学びは、またこのブログで共有していく予定です。 エブリーでは一緒に働く仲間を募集中です！ エンジニアブログをきっかけに少しでも興味も持っていただけたら、まずはカジュアルに面談しましょう！