2026 年 4 月 28 日の「 What’s Next with AWS 」では、マット ガーマン (AWS CEO）、Colleen Aubrey (Amazon Applied AI Solutions SVP)、Julia White (AWS CMO) と OpenAI のリーダーたちがディスカッションを行い、両社とそのお客様がエージェントを使って事業の運営方法をどのように変えているかについて話し合いました。 このイベントでの主な発表のまとめをご紹介したいと思います。 Amazon Quick は、あらゆる作業に接続し、ユーザーにとって重要な事柄を学び、ユーザーに代わって行動する AI アシスタントです。2026 年 4 月 28 日より、新しいデスクトップアプリの使用、無料プランとプラスプランへのサインアップ、チャットを使ったビジュアルアセットの生成が可能になり、Quick をさらに多くのアプリに簡単に接続できるようになります。 Quick の新しいデスクトップアプリ (プレビュー) : ブラウザを開かずにローカルファイル、カレンダー、コミュニケーションへの接続を維持することで、パーソナライズされたエクスペリエンスを創り出すことができます。 Quick の新しい無料プランとプラス料金プラン : 個人の E メールアドレス、または既存の Google、Apple、Github、Amazon 認証情報を使用して数分でサインアップできます。AWS アカウントは不要です。 ビジュアルアセットをその場で生成 : Quick では、洗練された文書、プレゼンテーション、インフォグラフィック、画像をチャットインターフェイスから直接作成できるようになりました。デザインスキルや何時間ものフォーマット調整を不要にするこの機能は、2026 年 4 月 28 日からご利用いただけます。 Quick をさらに多くのアプリに簡単に接続 : Quick は、ネイティブ統合の対象を拡大して、Google Workspace、Zoom、Airtable、Dropbox、Microsoft Teams を追加しました。この統合も2026 年 4 月 28 日から利用可能です。 詳細については、 Amazon News 記事 をご覧ください。 Amazon Connect は、単一製品から、Amazon Connect Decisions (サプライチェーン)、Talent (採用)、Customer (カスタマーエクスペリエンス)、および Health (ヘルスケア) の 4 つを含めた一連のエージェンティック AI ソリューションへと拡大されました。これらは既存のワークフローで機能するように設計されています。 Amazon Connect Decisions は、チームを後手に回る危機管理から先手を取る計画と意思決定へと移行させるサプライチェーン計画およびインテリジェンスソリューションです。30 年におよぶ Amazon の運営科学と 25 を超えるサプライチェーン特化型ツールを組み合わせる AI チームメイトは、ユーザーのビジネスに適応し、チームから学び、業務を継続的に改善します。 Amazon Connect Talent (プレビュー) は、スケール化された採用を管理するタレントアクイジションリーダーのために構築されたエージェンティック AI 採用ソリューションです。AI 主導の面接、科学的根拠に基づいたアセスメント、一貫的な評価を実現することで、採用担当者が優秀な候補者をより早く採用できるようにしながら、人間が持つ先入観を低減する柔軟な面接体験を応募者に提供します。 Amazon Connect Customer (旧称 Amazon Connect) は、音声、チャット、デジタルチャネルの全体でインテリジェントかつパーソナライズされたカスタマーエクスペリエンスを実現します。Amazon Connect Customer では、技術的な専門知識がなくても、組織が会話型 AI を数か月ではなく数週間でセットアップし、カスタマーエクスペリエンスを設定できる新しい設定機能が提供されるようになりました。 Amazon Connect Health は、エージェントによる患者確認、予約管理、患者インサイト、アンビエントドキュメンテーション、医療コーディングを提供することで、患者がより迅速に医療ケアを利用し、臨床医がケアにより多くの時間を費やし、スタッフが専門業務に専念できるようにします。 詳細については、 Amazon News 記事 をご覧ください。 AWS と OpenAI がパートナーシップを拡大 Amazon Bedrock に最新の OpenAI モデルを導入した AWS と OpenAI は、Codex on Amazon Bedrock の提供を開始するとともに、OpenAI を搭載した Amazon Bedrock Managed Agents をリリースしました (すべて限定プレビュー中)。これらは、企業が信頼するインフラストラクチャ上で、企業が求めるフロンティアインテリジェンスを提供します。 Amazon Bedrock 上の OpenAI モデル (限定プレビュー) : GPT-5.5 および GPT-5.4 を含めた最新の OpenAI モデルが、プレビューとして Amazon Bedrock で利用可能になります。OpenAI のフロンティアモデルは、統合されたキュリティ、ガバナンス、コスト管理を提供する、使い慣れた Bedrock API 経由で使用します。追加のインフラストラクチャを設定する必要も、新しいセキュリティモデルを学ぶ必要もありません。 Codex on Amazon Bedrock (限定プレビュー) : 既に大規模に運用されている AWS 環境内で OpenAI コーディングエージェントにアクセスできます。AWS 認証情報を使用した認証、Amazon Bedrock インフラストラクチャを使用した推論の処理、Codex 使用量の AWS クラウドコミットメントへの適用が可能です。Codex on Bedrock は Bedrock API 経由で利用でき、まずは Codex CLI、Codex デスクトップアプリ、Visual Studio Code 拡張機能からご利用いただけます。 OpenAI 搭載の Amazon Bedrock Managed Agents (限定プレビュー) : Amazon Bedrock Managed Agents は、フロンティア AI モデルと信頼の置ける AWS インフラストラクチャを組み合わせることで、お客様が本番環境対応の OpenAI 搭載エージェントをクラウドで迅速かつ簡単に構築できるようにします。OpenAI フロンティアモデルの可能性を最大限に引き出すように設計された OpenAI ハーネスを使用して構築されており、実行時間の短縮、推論の精緻化、長期的タスクの確実な制御を実現します。 詳細については、 AWS 最新情報記事 と Amazon News 記事 をご覧ください。 原文は こちら です。

本記事は 2026 年 4 月 17 日 に公開された「 Track Amazon Bedrock Costs by Caller Identity with IAM Principal-Based Cost Allocation 」を翻訳したものです。 Amazon Bedrock での生成 AI 利用が拡大すると、「Bedrock のコストを押し上げているのはどのチーム、アプリケーション、ユーザーか？」という疑問が生まれます。これまでは、 AWS CloudTrail ログと請求データを手動で突き合わせ、API コールを特定の ID にマッピングする必要がありました。時間がかかり、ミスが起きやすく、大規模な運用では維持が困難です。 AWS は Amazon Bedrock 向けの AWS Identity and Access Management (IAM) プリンシパルベースのコスト配分を発表しました。Bedrock API コールごとに呼び出し元 (IAM ユーザーまたはロール) の ID を AWS Cost and Usage Report (CUR 2.0) と AWS Cost Explorer に自動的に記録する機能です。カスタムツールなしで、API コールを実行した IAM プリンシパルごとに Bedrock モデルの支出を追跡、配分、最適化できます。 本記事では、この機能の仕組み、セットアップ方法、Amazon Bedrock コストをきめ細かく可視化する方法を説明します。 IAM プリンシパルベースのコスト配分が重要な理由 複数のチーム、アプリケーション、ユーザーが同じ AWS アカウントを共有して基盤モデルを呼び出すケースは珍しくありません。プリンシパルレベルのコスト帰属がなければ、Bedrock のコストは単一の明細項目として表示され、次のような疑問に答えることが困難です。 Anthropic Claude で最もトークンを消費しているチームはどこか？ 顧客向けチャットボットと社内の要約ツールでは、どちらのコストが高いか？ Bedrock のコストを正しい部門やプロジェクトにチャージバックできるか？ IAM プリンシパルベースのコスト配分は、Bedrock API コールの実行者を自動的に記録し、その ID と IAM プリンシパルに付与されたタグを対応するコストおよびトークン使用量に関連付けることで、上記の課題を解決します。 具体的には次のことが可能です。 Bedrock モデルを呼び出している IAM ユーザーやロールの特定 Bedrock モデルの使用状況を部門、チーム、プロジェクトなどの組織構造にマッピング Bedrock モデル費用の実際の利用部門への費用配賦（Chargeback）と部門別コストの可視化（Showback） プリンシパルごとの使用パターン分析による最適化機会の発見 仕組み CUR 2.0 データエクスポートで IAM プリンシパルデータを有効にすると、AWS は Bedrock API コールごとに呼び出し元の ID を自動的に記録します。有効化後、CUR 2.0 で次のデータを利用できます。 line_item_iam_principal : Bedrock API コールごとの呼び出し元の IAM ARN を含む新しいカラム (例: arn:aws:iam::123456789012:user/username や arn:aws:sts::123456789012:assumed-role/rolename/session-name ) IAM プリンシパルタグ: 呼び出し元の IAM プリンシパルに付与され、コスト配分タグとして有効化されたタグが、Tags カラムに iamPrincipal / プレフィックス付きで表示されます (例: department と costCenter をコスト配分タグとして有効化すると、 iamPrincipal/department 、 iamPrincipal/costCenter として表示) Cost Explorer でも IAM プリンシパルのコスト配分タグでコストのグループ化やフィルタリングが可能です。ディメンションとして Tag を選択し、該当する “IAM principal” タグ (例: iamPrincipal/department ) を選ぶと、部門、チーム、プロジェクトなど定義したタグディメンションごとに Bedrock モデルの支出を確認できます。 はじめに Amazon Bedrock の IAM プリンシパルベースのコスト配分は 3 つのステップでセットアップできます。 前提条件 開始前に以下を確認してください。 Amazon Bedrock API コールに IAM ユーザーまたはロールを使用していること IAM コンソールと Billing and Cost Management コンソールへのアクセス権があること CUR 2.0 データエクスポートが設定済みであること (または作成権限があること) 重要: IAM プリンシパルベースのコスト配分は、Billing and Cost Management コンソールで管理アカウントレベルで有効化する必要があります。 AWS Organization のメンバーアカウントが個別に有効化することはできません。 ステップ 1: IAM プリンシパルにタグを付与する まず、Bedrock API を呼び出す IAM ユーザーとロールに、わかりやすく標準化されたキーでタグを付与します。 1. IAM コンソールに移動します 2. Bedrock API を呼び出す IAM ユーザーまたはロールを選択します 3. Tags タブで department、costCenter、team、project などのキーでタグを追加します (図 1 参照) 4. 該当する IAM プリンシパルに対して繰り返します 図 1: IAM ロールにタグを付与する IAM コンソール画面 ヒント: 低カーディナリティで分かりやすいタグ値を使用してください。department=engineering や costCenter=CC-1234 のようなタグが理想的です。セッション ID やタイムスタンプのような高カーディナリティの値は、Cost Explorer でのカーディナリティ増大や CUR ファイルサイズの肥大化につながるため避けてください。 ステップ 2: コスト配分タグを有効化する 次に、Billing コンソールでタグを有効化し、コストレポートに表示されるようにします。タグが有効化の対象として表示されるのは、そのタグが付与された IAM プリンシパルが少なくとも 1 回 API コールを実行した後です。IAM ユーザー、ロール、ロールを引き受けたセッションのいずれでも同様です。 5. Billing and Cost Management コンソール に移動します 6. Cost Allocation Tags に移動します 7. ステップ 1 で付与した IAM プリンシパルタグを見つけます 8. タグを選択して Activate を選びます (図 2 参照) 図 2: Cost Allocation Tags の有効化ページを表示する Billing コンソール画面 注意: タグの有効化後、Cost Explorer と CUR レポートにタグが表示されるまで最大 24 時間かかる場合があります。 ステップ 3: CUR 2.0 で IAM プリンシパルデータを有効にする 最後に、CUR 2.0 エクスポートに呼び出し元の ID データを含めるよう設定します。 9. Billing and Cost Management コンソール で Data Exports に移動します 10. 新しい CUR 2.0 エクスポートを作成します 11. “Include caller identity (IAM principal) allocation data” オプションを選択します (図 3 参照) 12. エクスポート設定を保存します 重要: IAM プリンシパルのコスト配分を有効にしても追加料金は発生しません。ただし、この機能を有効にすると CUR ファイルサイズが増加します。以前は 1 行だったコスト明細項目が、使用量に貢献した IAM プリンシパルごとに複数行に展開されるためです。多数の異なるプリンシパルによる大量の使用パターンでは、S3 ストレージコストが大幅に増加する可能性があります。これを踏まえて、古い CUR ファイルに対する S3 ライフサイクルポリシーの適用を検討してください。 図 3: IAM プリンシパル配分データのチェックボックスを表示する Data Exports 設定ページ コストデータの確認 セットアップが完了しデータが流れ始めたら (最大 24 時間)、Cost Explorer と CUR 2.0 レポートの 2 つの方法で IAM プリンシパルごとの Bedrock コストを分析できます。 Cost Explorer での確認 13. AWS Cost Explorer に移動します 14. ディメンションとして Tag を選択します (図 4 参照) 15. 該当する “IAM Principal” タグ (例: iamPrincipal/costCenter ) を選びます 16. 選択したタグディメンションごとの Bedrock モデル支出の内訳を確認します 図 4: IAM プリンシパルタグごとの Bedrock 支出内訳を表示する Cost Explorer チャート CUR 2.0 レポートでの確認 Amazon Athena や任意の分析ツールで CUR 2.0 データをクエリします。 line_item_iam_principal カラムには Bedrock 推論コストごとの完全な IAM ARN が含まれ、Tags カラムの iamPrincipal/ プレフィックス付きタグでタグディメンションごとにコストを分割できます。 ゲートウェイアーキテクチャへの対応 多くの組織では、Amazon Bedrock API コールを Amazon API Gateway 、カスタムプロキシ、共有内部サービスなどの中間ゲートウェイ経由でルーティングしています。このアーキテクチャでは、CUR 2.0 に記録される IAM プリンシパルはエンドユーザーの ID ではなくゲートウェイの実行ロールになります。そのため、Bedrock コストが単一の IAM ロールに集約されて表示される場合があります。 Bedrock コストが 1 つの IAM ロールにまとまっている場合、ゲートウェイ経由のアクセスが原因と考えられます。ゲートウェイパターンでコストの可視性を維持するための戦略を紹介します。 コンシューマーグループごとに個別の IAM ロールを使用する ゲートウェイの背後にあるチームやアプリケーションごとに個別の IAM ロールを割り当てます。ゲートウェイの実装を変更することなく、コスト帰属の粒度を維持できます。 ゲートウェイの実行ロールにタグを付与する 共有ロールを使用している場合でも、IAM プリンシパルタグ (department や application など) を付与してコストを適切なビジネスユニットにマッピングできます。 セッションタグで動的な帰属を実現する ゲートウェイの背後で最もきめ細かなコスト帰属を実現するには、セッションタグが有効です。ゲートウェイが AssumeRole で共有 IAM ロールを引き受ける際、セッションタグをパラメータとして渡すことで、そのセッションのロールの既存タグを上書きできます。 仕組みは次のとおりです。 ゲートウェイアプリケーションが AssumeRole または同様の AWS Security Token Service (STS) API を呼び出します ロールの引き受け時に、アプリケーションがセッションタグ (例: department=engineering、project=devx-v2、costCenter=CC-1234) を渡します セッションタグがそのセッションの対応する IAM ロールタグを上書きします そのセッション中の Bedrock API コールがセッションタグの値で CUR 2.0 に記録されます 共有ゲートウェイロール経由でも、アプリケーション、プロジェクト、部門レベルでのコスト配分が可能になります 注意: Bedrock はタグの和集合、つまり複数のタグソースを統合して記録します。元の IAM プリンシパルタグ、上書きされたタグ、セッション中に追加された新しいタグが含まれます。セッションタグは一致するタグキーの上書きや新しいタグの追加が可能ですが、既存の IAM プリンシパルタグを選択的に削除することはできません。ロール引き受け時のセッションタグの渡し方の詳細は、 セッションタグに関する AWS ドキュメント を参照してください。 ベストプラクティス IAM プリンシパルベースのコスト配分を効果的に実装するためのベストプラクティスです。 低カーディナリティのタグキーを使用する 。department、costCenter、project のようなタグが理想的です。頻繁に変わる値やリクエストごとに一意な値は避けてください。 命名規則を標準化する 。コスト配分を有効にする前に、タグキーの大文字小文字、命名パターン、許容値を組織全体で統一してください。一貫性のない命名 (例: Department、department、dept の混在) をすると、コストの集計・分析が困難になります。 未使用のタグを定期的に確認・無効化する 。古いタグや未使用のタグはコストレポートのノイズになります。有効なコスト配分タグを定期的に監査してください。 チーム間のタグ使用状況を監視する 。Bedrock モデルを利用する新しい IAM プリンシパルに一貫してタグが付与されているか確認してください。 まとめ IAM プリンシパルベースのコスト配分により、Amazon Bedrock の支出を押し上げている ID を正確に把握できます。IAM プリンシパルへのタグ付与、コスト配分タグの有効化、CUR 2.0 での IAM プリンシパルデータの有効化を行うことで、組織全体で Bedrock コストの追跡、配分、管理が可能になります。今すぐこの機能を有効にして、24 時間以内にチーム、部門、プロジェクトごとの Bedrock 支出の分析を始めましょう。 詳細は IAM プリンシパルベースのコスト配分のドキュメント を参照してください。この機能に関する質問やフィードバックは、 AWS re:Post または AWS Support までお寄せください。 著者について Koushik Das AWS のシニアテクニカルアカウントマネージャー。お客様の戦略的イニシアチブの推進と生成 AI 導入を支援しています。クラウド財務管理 (CFM) とヘルスケア・ライフサイエンス分野の AI イノベーションを専門としています。 Anand Gaurav AWS の Billing and Cost Management チームのプリンシパルテクニカルプロダクトマネージャー。FinOps と生成 AI の交差領域におけるコスト管理のプロダクト戦略を担当しています。 翻訳はソリューションアーキテクト 大磯が担当しました。原文は こちら です。

はじめに こんにちは。開発部でiOSエンジニアをしている野口です。 ヘルシカ - ダイエット・食事管理のための簡単カロリー計算 every, Inc. ヘルスケア／フィットネス 無料 ヘルシカのiOSアプリではXcode Cloudを使用して開発環境・本番環境への配布を行っています。本記事では、配布にかかっていた実行時間を約50%削減した方法を紹介します。 背景と課題 削減前のXcode Cloudの実行時間は約30分かかっていました。これを削減できれば、開発スピードの向上やQAから修正へのサイクルが回しやすくなり、品質の向上が期待できると考えました。 各ステップの実行時間はApp Store Connectのダッシュボードから確認できます。調査したところ、 ci_post_clone.sh の実行が全体の約62%を占めており、ここがボトルネックであることがわかりました。 ステップ 時間 割合 Run ci_post_clone.sh script 16分46.9秒 62.34% Run xcodebuild archive 6分17.9秒 23.39% Resolve package dependencies 2分2秒 7.55% その他（環境設定・取得・Export・後処理など） 1分48.5秒 6.72% Build Archive 合計 26分55.3秒 100.00% Prepare Build for App Store Connect 44.8秒 — 総合計 約27分40秒 — ※主要なステップ以外は「その他」にまとめています。 原因の分析 ci_post_clone.shとは ci_post_clone.sh は、Xcode Cloudがリポジトリをクローンした直後に自動で実行されるシェルスクリプトです。ビルドに必要な追加ツールのインストールや設定ファイルの書き換えなど、ビルド前の準備処理を記述します。以下の画像のPost-cloneと記述されている箇所で ci_post_clone.sh が動きます。 引用元: 実行していた処理 ci_post_clone.sh では、以下の処理を行っていました。 # ci_post_clone.sh #!/bin/sh brew install mint mint bootstrap -m ../Mintfile --overwrite y # Mintfile realm/SwiftLint@0.52.4 mono0926/LicensePlist@3.24.11 kiliankoe/swift-outdated@0.8.0 nicklockwood/SwiftFormat@0.53.3 Mintを使用して、以下のツールをインストールしていました。 SwiftLint : コードの静的解析 SwiftFormat : コードのフォーマット LicensePlist : ライセンスの管理 swift-outdated : 依存関係の更新確認 改善のアプローチ これらのツールはいずれも開発時に使用するものであり、Xcode Cloudでの配布時には実行する必要がありません。Xcode Cloudの役割はCDであり、配布作業のみ行えれば十分だからです。 そこで、「不要なツールのインストールをやめる」ことで実行時間を削減する方針としました。 キャッシュによる高速化を採用しなかった理由 「Mintのインストールをキャッシュすれば速くなるのでは？」と考えるかもしれませんが、Xcode Cloudのキャッシュ機能には制約があります。 GitHub ActionsやCircleCIなどのCI/CDツールでは、任意のパスやフォルダを指定してキャッシュできます。例えば ~/.mint をキャッシュしておけば、2回目以降のインストールを高速化できます。 一方、Xcode Cloudのキャッシュ対象は DerivedData配下のみ に限定されています。具体的にキャッシュされるのは以下の2つです。 Xcodeのビルドキャッシュ （インクリメンタルビルド用の中間成果物） Swift Package Managerで取得・ビルドされたライブラリ 任意のパスを指定する機能は提供されていないため、Homebrew経由でインストールしたMintなどはキャッシュの対象外です。つまり、 ci_post_clone.sh でのインストール処理は毎回フルで実行されることになります。 To reduce the amount of time it takes to perform a build, Xcode Cloud stores each build's derived data and other cached information for reuse in a secure and private way. — Xcode Cloud workflow reference | Apple Developer Documentation このキャッシュの制約があるからこそ、キャッシュで高速化するのではなく、そもそも不要な処理をXcode Cloudから取り除くアプローチが有効になります。 具体的には、 ci_post_clone.sh を削除してXcode CloudでのMintインストール自体をやめ、各ツールの実行はGitHub Actionsやローカル環境に移行しました。 各ツールの対応内容 SwiftLint・SwiftFormat ローカル環境でのビルド（Build Phase）とGitHub Actionsでのみ実行するようにしました。 GitHub Actionsの設定 # .github/workflows/ci.yml name : CI on : pull_request : branches : - develop jobs : swift_format : name : SwiftFormat runs-on : macos-latest steps : - uses : actions/checkout@v4 - name : Cache Mint packages uses : actions/cache@v4 with : path : ~/.mint key : ${{ runner.os }}-mint-${{ hashFiles('Mintfile') }} restore-keys : | ${{ runner.os }}-mint- - name : Install Mint run : brew install mint - name : Run SwiftFormat lint run : mint run swiftformat healthcare Packages --lint swift_lint : name : SwiftLint runs-on : macos-latest steps : - uses : actions/checkout@v4 - name : Cache Mint packages uses : actions/cache@v4 with : path : ~/.mint key : ${{ runner.os }}-mint-${{ hashFiles('Mintfile') }} restore-keys : | ${{ runner.os }}-mint- - name : Install Mint run : brew install mint - name : Run SwiftLint run : mint run swiftlint lint ローカル環境（Xcode Build Phase）の設定 XcodeのRun Script（Build Phase）でSwiftFormatとSwiftLintを実行します。Run ScriptはXcode Cloud上のビルドでも実行されるため、環境変数 CI が TRUE のときはスキップするようにしています（Xcode Cloudでは CI=TRUE が設定されます）。 if [ " $CI " = "TRUE" ]; then exit 0 fi if [ -d " /opt/homebrew/bin " ]; then export PATH =" $PATH :/opt/homebrew/bin " fi mint run swiftformat healthcare Packages mint run swiftlint lint LicensePlist もともとBuild PhasesのRun Scriptでビルドのたびにライセンス情報を自動生成していたため、生成物をGit管理していませんでした。今回の対応で生成物をGit管理に含め、Build PhasesからRun Scriptを削除しました。パッケージを変更した際にはローカルでライセンス情報を再生成する運用としています。 swift-outdated もともとXcode Cloudでは実行していなかったため、対応は不要でした。 結果 これらの対応により、Xcode Cloudの実行時間を約30分から約15分へ、約50%削減することができました。ビルドやパッケージ解決の設定を変えたわけではなく、 ci_post_clone.sh の処理を見直しただけでこれだけの効果が得られました。 まとめ Xcode Cloudの実行時間を削減するために、CDとして不要なツールのインストール処理を見直しました。Xcode CloudのキャッシュはDerivedData配下のみという制約があるため、キャッシュで高速化するのではなく、そもそも不要な処理をXcode Cloudから取り除くアプローチを採用しています。各ツールの実行はGitHub Actionsやローカル環境に移行し、CI/CDの役割を明確に分離しました。 Xcode Cloudの実行時間に課題を感じている方の参考になれば幸いです。