目次 誰の、どんな問題を解決する記事か トレースの基本構造 スパンの種類 どこに、どんな名前で保存されるか 準備 トレース収集の設定を確認する サンプルデータを入れる 四つの調査シナリオ シナリオ 1：ツールを使わない場合と使う場合の比較 シナリオ 2：複数ツールを使った処理の遅延調査 ツールの中で LLM が呼ばれている 入力トークンはラウンドの中でも増える 同じ質問をもう一度送ると シナリオ 3：ツールエラーの調査 シナリオ 4：長い会話のトークン増加調査 小さな注意：View Trace はすぐに開かない ダッシュボードで環境全体を見る 実務で使う ES|QL 3 本 ラウンド（トレース）ごとの集計 ツール別の呼び出し回数とエラー数 モデル別のトークン使用量 最初に作るアラート 2 つ 会話ごとのトークン上限 ツールの失敗 作るときの注意点と、応用の例 プライバシー設定とアクセス権 トレースと会話履歴は別の保存先 アクセス権は「インデックス単位」 参考資料 誰の、どんな問題を解決する記事か AI エージェントを PoC から運用に進めると、次のような場面に必ず出会います。 回答は返ってきたが、なぜ 30 秒もかかったのか分からない 検索したはずなのに、答えが実データと合わない トークンの消費が想定より多い。Agent の作り方の問題か、使い方の問題か判断できない この記事は、Elastic Agent Builder を使っていて、こうした「回答の裏側」を調べたいエンジニアのために書きました。この分野は Agent Observability（エージェントの可観測性） と呼ばれ、Splunk など他社も同じ名前で製品を出し始めています。求められていることは共通です。処理の流れを追って原因を突き止めること、トークンとコストを追うこと、異常を検知することです。 Elastic 9.5 では、Agent Builder の実行を OpenTelemetry（OTel）形式で記録する Agent Observability and Monitoring が Technical Preview として発表されました。LLM 呼び出し、ツール呼び出し、処理時間、トークン使用量を Elasticsearch に保存し、1 回の回答から環境全体の傾向まで確認できます。 この記事では、Kibana の標準サンプルデータ（Sample eCommerce orders）を使い、Agent Builder に質問して本物のトレースを作りました。その結果をもとに、 個別の調査 → 全体の監視 → 自動通知 の順で説明します。 トレースの基本構造（会話、ラウンド、スパン） 4 つの調査シナリオを View Trace で読む 環境全体を Overview ダッシュボード で見る 実務で使う ES|QL 3 本と、最初に作る アラート 2 つ 本番導入前に決める プライバシー設定と権限 トレースは普通の Elasticsearch データです。Discover や ES|QL の知識がそのまま使えます。 検証環境 : Elastic Cloud Serverless（検証日: 2026 年 9 月 16 日）。トレースに記録された Kibana のバージョンは 9.6.0 でした。Serverless は機能が順次提供されるため、画面や項目名がスタック版と異なる場合があります。 Agent Observability and Monitoring は、Elastic 9.5（2026 年 8 月 4 日発表）で Technical Preview として発表されました。 トレースの基本構造 Agent Builder のトレースは、 会話 > ラウンド > スパン の 3 段でできています。 段 意味 ID 会話（conversation） 1 つのチャット画面 gen_ai.conversation.id ラウンド（round） メッセージを 1 回送って、回答が 1 回返るまで trace_id（1 ラウンド = 1 トレース） スパン（span） ラウンドの中の 1 つの処理 span_id スパンの種類 スパンは主に 4 種類です。種類は attributes.elastic.inference.span.kind という属性に入っています。 スパン名の形 種類 何を表すか 主に確認できること invoke_agent <Agent 名> CHAIN ラウンド全体（一番外側の箱） 全体時間、成否 invoke_agent <Agent 名> AGENT Agent 1 回分の実行 Agent 単位の時間、成否 chat <モデル名> LLM LLM へのリクエスト モデル、プロバイダー、入力・出力トークン、時間 execute_tool <ツール名> TOOL 検索や ES|QL 実行などのツール どのツールか、時間、成功・失敗 invoke_agent は CHAIN と AGENT の 2 つの意味で使われます。区別するときは span.kind を見ます。このほかに generate_title（会話タイトルの生成）と generate_esql（自然言語から ES|QL を作る処理）というスパンも出てきます。どちらも中で LLM を呼びます。 どこに、どんな名前で保存されるか トレースは traces-agent_builder.otel-<Space ID> というデータストリームに保存されます。 Default Space なら traces-agent_builder.otel-default です。 隠しインデックスではなく、普通のデータストリーム なので、Discover、Lens、Dashboard、ES|QL、アラートルールがそのまま使えます。 属性の多くは、OpenTelemetry の GenAI セマンティック規約（ gen_ai.* ）に沿った名前です。今回の検証で確認できた主なものを挙げます。 属性 意味 実測の例 gen_ai.operation.name 処理の種類 chat、execute_tool、invoke_agent gen_ai.request.model / gen_ai.response.model モデル名 anthropic-claude-5-sonnet gen_ai.provider.name プロバイダー名 elastic gen_ai.usage.input_tokens / output_tokens 入力・出力トークン数（long 型） 17,154 / 84 gen_ai.conversation.id 会話の ID（既定では匿名化されたハッシュ） 399b6330a91f4697 gen_ai.tool.name / gen_ai.tool.type / gen_ai.tool.call.id ツール名、種類、呼び出し ID platform.core.execute_esql、extension gen_ai.input.messages / gen_ai.output.messages 入出力メッセージ プライバシー設定オフのため [] Elasticsearch の OTel データストリームでは、これらは attributes.gen_ai.request.model のように attributes. の下に入ります。スパン名は name フィールドで、 span.name はその別名（alias）です。時間は duration にナノ秒で入ります。 ただし、すべてが標準というわけではありません。 gen_ai.* の規約はまだ試験段階です（Elastic の公式ドキュメントでは Experimental、OTel のレジストリでは Development と表記されています）。また、a ttributes.elastic.inference.span.kind と CHAIN、AGENT、LLM、TOOL という分類は、 elastic.* で始まる Elastic 独自の拡張です。つまり、保存形式は OTel、属性名は OTel の規約、スパンの分類は Elastic 独自、という 3 層になっています。 準備 トレース収集の設定を確認する Stack Management → GenAI Settings → Agent Build er Traces を開きます。 Collect conversation traces （agentBuilder:tracing:enabled）は既定でオンです。オフになっていると View Trace アイコンが表示されません。 Advanced privacy settings は既定ですべてオフです。今回はオフのまま進めます。理由は第 8 章で説明します。 同じ画面の Install Dashboard から、 [Elastic] Agent Builder Overview ダッシュボードを導入します。ダッシュボードは自動では入りません。Space ごとに導入が必要です。 サンプルデータを入れる Integrations を開き、 Sample Data と検索して Sample eCommerce orders を Install data します。インデックス名は kibana_sample_data_ecommerce です。件数を Dev Tools で確認しておきます。 GET kibana_sample_data_ecommerce/_count 結果は 4,675 件でした。後で Agent の回答と比べるために、この数字を控えておきます。 四つの調査シナリオ ここからが本題です。カスタム Agent やカスタムツールは作らず、標準の Elastic AI Agent だけを使います。モデルはチャット画面の既定のまま（表示は「Anthropic Claude Sonnet 5」）です。目的は回答の内容を評価することではなく、 質問の種類を変えると、トレースがどう変わるか を比べることです。 シナリオ 調べること 使う質問 1 ツールを使わない場合と使う場合の比較 短い回答だけの質問と、件数を実データで調べる質問 2 複数ツールを使った処理の遅延調査 2 段階の集計 3 ツールエラーの調査 存在しないインデックスの検索 4 長い会話のトークン増加調査 同じ会話で 3 回質問 各質問の後、回答の下にある View Trace アイコンをクリックします。フライアウトのヘッダーに Trace ID、スパン数、合計時間 が表示され、その下にウォーターフォールが並びます。各行にスパンの種類と時間、LLM 呼び出しの行には入力・出力トークン数が出ます。 シナリオ 1：ツールを使わない場合と使う場合の比較 まず基準値を取ります。ツールを使わない短い回答です。 「トレース基本テスト成功」とだけ回答してください。ツールは使用しないでください。 次に、ツールを 1 回使わせます。 kibana_sample_data_ecommerce のドキュメント数を、Elasticsearch の実データを検索して確認してください。推測では答えず、必ず利用可能なツールを使ってください。最終回答には件数と、検索に成功したかどうかだけを書いてください。 項目 ツールなし ツール 1 回 スパン数（View Trace） 4 6 合計時間 4,579 ms 6,307 ms 回答を作る LLM 呼び出し 1 回（4,168 ms） 2 回（3,369 ms と 2,188 ms） ツール呼び出し 0 1 回（platform.core.execute_esql、31 ms） 入力／出力トークン（本体） 17,154 / 84 17,581 / 16 ステータス Ok Ok この比較から 3 つのことが分かります。 1 つ目は、短い質問でも入力トークンが約 17,000 ある ことです。入力トークンは画面に入力した文章だけではありません。Agent のシステム指示、利用できるツールやスキルの定義も LLM への入力に含まれます。この約 17,000 トークンは、いわば Agent の「基本料金」に近い部分です。この値は Agent の設定、有効なツールやスキルの数、製品のバージョンによって変わります。 2 つ目は、ツールの前後で LLM が呼ばれる ことです。今回は、1 回目の LLM 呼び出しで Agent が「どのツールを、どんな引数で使うか」を決め、ツールを実行した後、2 回目で結果を読んで回答を作りました。Agent が複数のツールをまとめて選んだり、結果を見てやり直したりすると、回数は増えます。時間の内訳を見ると、ツールの実行は 31 ms、LLM 呼び出しは合わせて 5,557 ms です。この質問では、時間のほぼ全部が LLM 待ちでした。 3 つ目は、頼んでいない generate_title スパンがある ことです。新しい会話の 1 ラウンド目には、会話のタイトルを自動で付ける処理が走ります。この処理は、回答を作るモデルとは別の軽いモデル（google-gemini-3.5-flash-lite、入力 249 / 出力 19 トークン）を使っていました。2 ラウンド目以降には出ません。 シナリオ 2：複数ツールを使った処理の遅延調査 kibana_sample_data_ecommerce で、最も注文数が多い商品カテゴリ（category）を調べてください。次に、そのカテゴリの注文の平均金額（taxful_total_price の平均）も調べてください。2 つの結果を、それぞれどのクエリで確認したかと一緒に答えてください。 回答は「Men’s Clothing（2,024 件）」と「平均 60.97（対象 908 件）」でした。 トレースは 18 スパン、34,707 ms です。シナリオ 1 より質問が複雑になっただけで、スパン数は 6 から 18 に、時間は 6 秒から 35 秒に増えました。内訳は、回答を作る chat が 6 回、ツールが 5 回（attachments.read、get_index_mapping、generate_esql、execute_esql 2 回）、そして generate_esql の中の chat が 2 回です。 ツールの中で LLM が呼ばれている ツリーを見ると、 execute_tool platform.core.generate_esql （2,553 ms）の下に generate_esql スパンがあり、その下に chat google-gemini-3.5-flash-lite が 2 つ入っています。「自然言語を ES|QL に変える」という仕事には、通常 LLM などの生成処理が必要です。Agent 本体（claude-sonnet）は「今は ES|QL が必要だ」と判断してツールを呼ぶだけで、実際のクエリ作成はツールの中の別のモデルに任せています。 つまり、ツールには 2 種類あります。ここでの「決定的」とは、同じ入力に対して基本的に同じ処理を行うという意味です。 ツールの種類 例 時間 決定的な処理を行うツール execute_esql（27 ms）、get_index_mapping（15 ms） Elasticsearch に問い合わせて結果を返す。速い 内部で LLM を呼ぶツール generate_esql（2,553 ms） 変換や生成のために LLM を呼ぶ。遅い 利用者の画面には tool: platform.core.generate_esql ran と 1 行出るだけです。その中で別のモデルが 2 回動いていたことは、トレースを見ないと分かりません。「ツールが遅い」と思っていたら、実は中の LLM が遅かった、という切り分けができます。 入力トークンはラウンドの中でも増える このラウンドの chat の入力トークンは、17,233 → 17,522 → 18,552 → 18,929 → 19,446 → 20,019 と増え続けました。ツールの結果が返るたびに、それが次の LLM 入力に追加されるためです。 なお、この実験では 1 回目の送信で画面に「Reasoning error: TypeError: network error」と表示されましたが、2回目に実行したら1回目と2回目の回答が無事に表示されました。問題は Agent の処理の外側（ブラウザへの配信経路のどこか）で起きたと考えられます。トレースは、記録された範囲で「Agent が何をしたか」を示しますが、「利用者の画面に何が起きたか」は範囲外です。 同じ質問をもう一度送ると 同じ会話で、同じ質問をもう一度送ってみました。今度は 3 スパン、9,915 ms、LLM 呼び出しは 1 回だけです。ツールは使っていません。Agent は「前回と同じ内容のご質問ですね」と答え、会話履歴から回答を作りました。入力トークンは 20,669 です。 「検索せずに履歴から答えた」ことが、ツールスパンが無いという形ではっきり見えます。回答が期待と違うときに、まず確認するべきポイントです。 シナリオ 3：ツールエラーの調査 Observability では、正常な処理だけでなく、 失敗した処理を見つけられること が重要です。存在しないインデックスを指定して、読み取りクエリを 1 回だけ実行させます。 利用可能な ES|QL 実行ツールで、次のクエリを変更せずに 1 回実行し、結果またはエラーを説明してください。 FROM trace-test-missing-index-v1 | LIMIT 1 別のインデックスには置き換えないでください。 Agent はクエリをそのまま実行し、 verification_exception: Unknown index [trace-test-missing-index-v1] というエラーを受け取りました。そして、インデックスが存在しないことが原因だと利用者に説明しました。 トレースは 7 スパン、14,610 ms です。execute_tool platform.core.execute_esql（14 ms）の status.code は Error でした。一方、ラウンド全体を表すルートの invoke_agent は Ok です。 ここで注目したいのは、 ツールの失敗と会話の失敗は別の概念 だという点です。ツールが失敗しても、Agent がそれを受け止めて説明できれば、会話としては成功です。監視するときは両方を見ます。ツールのエラー率は「壊れやすいツール」を見つけるため、Agent 実行のエラー率は「Agent が正常終了できなかった割合」を見るためです。 注意が 2 つあります。公式ドキュメントによると、execute_tool スパンの status.code が Error になるのは、主に引数やスキーマの検証エラーのときです。ツールの中でエラーを捕まえて、通常の結果として Agent に返した場合は Error になりません。今回の Unknown index は Elasticsearch が返した実行エラーでしたが Error として記録されました。ツールの実装によって扱いが違うので、 status.code だけですべてのツール失敗を拾えるとは考えないほうが安全です 。もう 1 つ、今回の設定（Include tool call details オフ）では、エラーの本文（Unknown index … という文字列）はトレースに保存されません。残るのは status.code = Error という事実だけです。 シナリオ 4：長い会話のトークン増加調査 新しい会話を 1 つ作り、その中で 3 回続けて質問しました。 kibana_sample_data_ecommerceにはどんなフィールドがありますか。主なものを10個だけ挙げてください。 そのうち、金額に関係するフィールドはどれですか。 その金額フィールドの中で、合計が一番大きいものはどれですか。実データで確認してください。 ラウンド 最初の chat の入力トークン ツール ラウンド全体の時間（ES|QL で集計） 1 17,167 get_index_mapping 14,667 ms 2 18,595 なし（履歴から回答） 9,913 ms 3 19,095 generate_esql、execute_esql 24,925 ms 入力トークンが 17,167 → 18,595 → 19,095 と、ラウンドを重ねるごとに増えています。 ラウンドを重ねると、過去の会話のコンテキストが入力に加わる ためです。なお、公式ドキュメントによると、Agent Builder は長い会話を圧縮（compaction）します。そのため、常に全履歴がそのまま送られるわけではありません。 シナリオ 2 の「ツール結果で増える」と合わせると、今回の実験で入力トークンが増えた主な理由は 2 つでした。会話が長くなること、そして 1 ラウンドの中でツールを何度も使うことです。このほかにも、システム指示の変更、有効なツールやスキルの変更、添付ファイル、会話の圧縮、モデルや製品バージョンの変更で入力トークンは変わります。トークンの監視では、1 回の呼び出しだけでなく、会話単位の合計を見ることが大切です。 小さな注意：View Trace はすぐに開かない 2 ラウンド目の直後に View Trace を開くと、「No spans found」と表示されました。少し待って開き直すと、3 スパンが表示されました。トレースの書き込みは非同期です。特に、ラウンド全体を表すルートの invoke_agent は、Agent の処理が終わった後に閉じられて書き込まれます。回答直後に開くと、このスパンや、終わったばかりのスパンがまだ入っていないことがあります。数字を記録するときは、少し待ってから ES|QL で数え直すのが確実です。 ダッシュボードで環境全体を見る 1 件の回答を詳しく調べるなら View Trace、複数の会話をまとめて監視するなら [Elastic] Agent Builder Overview ダッシュボードを使います。 ダッシュボードは 4 つのセクションに分かれています。今回の検証（会話ラウンド 10 回、約 19 分）の値を並べます。 セクション 確認できること 今回の値 Token Usage & Cost 入出力トークン合計、LLM リクエスト数、モデル別・プロバイダー別の内訳 入力 571,179、出力 11,067、リクエスト 40（sonnet 27、gemini 13） Conversation Volume & Latency 会話ラウンド数、平均・p95・最大の処理時間 10 ラウンド、平均 20.75 秒、p95 48.50 秒、最大 59.79 秒 Agent Execution Agent 別の実行回数と処理時間 elastic-ai-agent 10 回、平均 17.37 秒 Tool Call Frequency & Errors ツール呼び出し数、エラー数、成功率、平均時間、ツール別の内訳 17 回、エラー 1、成功率 94.1%、平均 2.78 秒 読み取れることが 3 つあります。 入力トークン 571,179 に対して、出力は 11,067 です。入力が出力の 50 倍以上あります。コストを考えるなら、入力側を見る必要があります。 Conversation（ラウンド全体）の平均 20.75 秒と Agent Execution の平均 17.37 秒には約 3.4 秒の差があります。ラウンドには、Agent の実行のほかに、タイトル生成や回答の保存といった処理が含まれるためです。 ツールの成功率 94.1% は黄色で表示されています。ダッシュボードの定義では、90% 未満が赤、90〜99% が黄、99% 以上が緑です。シナリオ 3 で意図的に起こした 1 回のエラーが、そのまま反映されています。 このダッシュボードは、すべてのパネルが ES|QL で作られています。データストリーム名が traces-agent_builder.otel-default と直接書かれているため、Space ごとに導入する必要があります。ダッシュボードは Elastic が管理する読み取り専用（Managed）です。自社向けに変えたいときは、 複製 してから編集します。パネルのクエリは、自分のダッシュボードを作るときの手本になります。 小さなコツを 1 つ。データが見えないときは、まず Time Picker を広げてください。既定の Last 15 minutes のままだと、少し前の会話は範囲外になります。 実務で使う ES|QL 3 本 トレースは普通のデータストリームです。ここでは、調査でよく使う 3 本のクエリと、その実測結果を紹介します。 ラウンド（トレース）ごとの集計 FROM traces-agent_builder.otel-default | WHERE @timestamp > NOW() - 3 hours | STATS spans = COUNT(*), llm_calls = COUNT(*) WHERE `span.name` LIKE "chat *", tool_calls = COUNT(*) WHERE `span.name` LIKE "execute_tool *", errors = COUNT(*) WHERE status.code == "Error", input_tokens = SUM(TO_LONG(attributes.gen_ai.usage.input_tokens)), output_tokens = SUM(TO_LONG(attributes.gen_ai.usage.output_tokens)), total_ms = MAX(duration) / 1000000, started = MIN(@timestamp) BY trace_id | SORT started ASC この 1 本のクエリで、ラウンドごとの違いが一目で分かります。 ポイントは 3 つです。span.name は name の別名で、公式ドキュメントに合わせてバッククォートで囲っています。duration の単位はナノ秒なので、1,000,000 で割ってミリ秒にしています。トークン数は公式ドキュメントに合わせて TO_LONG() で包んでいます。今回の環境では long 型だったので直接 SUM() もできましたが、型の違いに備えて公式例と同じ書き方にしています。 ツール別の呼び出し回数とエラー数 FROM traces-agent_builder.otel-default | WHERE @timestamp > NOW() - 3 hours AND `span.name` LIKE "execute_tool *" | EVAL duration_ms = duration / 1000000 | STATS calls = COUNT(*), errors = COUNT(*) WHERE status.code == "Error", avg_ms = AVG(duration_ms) BY `span.name` | SORT calls DESC モデル別のトークン使用量 FROM traces-agent_builder.otel-default | WHERE @timestamp > NOW() - 3 hours AND `span.name` LIKE "chat *" | STATS requests = COUNT(*), input_tokens = SUM(TO_LONG(attributes.gen_ai.usage.input_tokens)), output_tokens = SUM(TO_LONG(attributes.gen_ai.usage.output_tokens)) BY attributes.gen_ai.request.model, attributes.gen_ai.provider.name 最初に作るアラート 2 つ ES|QL が書けるということは、アラートも作れるということです。 Stack Management → Rules → Create rule で Elasticsearch query ルールを選び、クエリ言語に ES|QL を指定します。公式ドキュメントには 4 つの例がありますが、最初に必要なのは次の 2 つです。 会話ごとのトークン上限 1 つの会話の入出力トークン合計が上限を超えたら通知します。公式ドキュメントの例では 256,000 です。「Create an alert for each row」を選ぶと、会話ごとに 1 件のアラートになります。 FROM traces-agent_builder.otel-default | WHERE `span.name` LIKE "chat *" | STATS input_tokens = SUM(TO_LONG(attributes.gen_ai.usage.input_tokens)), output_tokens = SUM(TO_LONG(attributes.gen_ai.usage.output_tokens)) BY attributes.gen_ai.conversation.id | EVAL total_tokens = input_tokens + output_tokens | WHERE total_tokens > 256000 ツールの失敗 特定のツールの失敗が 5 回を超えたら通知します。シナリオ 3 のエラーは、この条件で拾えました。ただし、シナリオ 3 で書いたとおり、ツールの中で捕まえて通常の結果として返されたエラーは status.code に出ません。このアラートは一部のツール失敗を見逃す可能性があります。 FROM traces-agent_builder.otel-default | WHERE `span.name` LIKE "execute_tool *" AND status.code == "Error" | STATS failures = COUNT(*) BY `span.name` | WHERE failures > 5 作るときの注意点と、応用の例 公式の例を少し変えるだけで、運用に合わせた検知も作れます。たとえば、6-1 のクエリの BY を trace_id にして llm_calls = COUNT(*) を加えれば、「1 ラウンドで LLM 呼び出しが 15 回を超えた」という暴走の検知になります。また、今回の環境では attributes.user.hash （匿名化された利用者の識別子）がトレースに入っていたので、これで集計すれば「利用者ごとのトークン上限」も作れます。ただし、このフィールドは執筆時点の公式ドキュメントには載っていないため、使う前に GET traces-agent_builder.otel-default/_field_caps?fields=attributes.user.* で自分の環境を確認してください。 もう 1 つ、Elastic Workflows（決まった手順を自動で実行する機能）と組み合わせる使い方があります。Workflow から夜間に Agent を何十回も呼ぶような運用では、誰も画面を見ていません。トークンの使いすぎやツールの連続失敗をアラートで知らせる仕組みが必要になります。上の 2 つのアラートはそのまま使えます。Workflow ツールのスパン名や、Workflow から呼び出した Agent の記録単位は今回は検証していないので、次回の記事で確認します。 閾値は、ダッシュボードで 1 週間ほど傾向を見てから決めます。今回の検証では 19 分で約 58 万トークンでした。 プライバシー設定とアクセス権 Agent Builder のトレース収集は既定で有効です。ただし、 既定で保存するのは処理時間、モデル名、トークン数、ステータスといった構造的なメタデータ です。会話の内容を保存する Advanced privacy settings は、管理者が明示的にオンにしない限りオフです。 今回の環境では、Advanced privacy settings に 7 つの項目がありました。 設定 オンにすると保存されるもの 主なリスク Include user prompts in traces 利用者の質問 個人情報、顧客情報 Include LLM responses in traces Agent の回答 検索結果や機密情報の再保存 Include tool call details in traces ツールの引数と結果 クエリ、取得文書、外部 API の結果 Include system prompt in traces Agent のシステム指示 内部ルールやプロンプト設計の露出 Include real tool, agent, and conversation names in traces カスタム Agent・ツールの実名、会話タイトル 内部構成の特定 Include real conversation and workflow IDs in traces 実際の ID 会話や利用者との関連付け Include user data in traces 実際のユーザー ID とユーザー名 利用者の特定 執筆時点の公式ドキュメントとは 2 か所で違いがありました。5 番目の項目は、公式ドキュメントでは「Include real tool and agent names in traces」で、会話の名前については書かれていません。7 番目の「Include user data in traces」は、公式ドキュメント（6 項目）にはありません。画面の説明では、既定では実際のユーザー ID とユーザー名を省き、相関用の安定したハッシュ（user.hash）だけを残すとありました。どちらも Serverless の画面が先行している可能性があります。自分の環境の画面で確認してください。 匿名化の仕組みも押さえておきます。カスタムのツール、Agent、Workflow の名前は custom という文字に置き換わります。ID は 安定したハッシュ に置き換わるので、実名が分からなくても同じ会話のスパンをグループ化できます。Elastic 組み込みのツールと Agent は、常に実名で記録されます。 今回の検証では、7 項目すべてオフでした。この状態でも、処理時間、モデル、トークン数、ステータスは確認できました。一方、スパンの詳細では gen_ai.input.messages が []（空）になっています。これは不具合ではなく、設定が反映された結果です。 トレースと会話履歴は別の保存先 トレース側で利用者の入力を保存しなくても、Agent Builder の会話履歴には本文が残ります。個人情報を扱う場合は、トレースの設定だけでなく、会話の保持・共有・削除の方針も別に決める必要があります。 アクセス権は「インデックス単位」 Agent Builder のトレースは、 traces-agent_builder.otel-<Space ID>  というデータストリームに保存されます。通常の閲覧権限だけでは、「自分の会話のトレースだけを読む」ようには自動で分離されません。そのため、トレースを調査する担当者を決め、データへの権限をロールで管理できます。 Elastic Cloud Serverless では、Admin and settings → Custom roles → Create role を開きます。Index privileges の対象に  traces-agent_builder.otel-* 、権限に  read  と  view_index_metadata  を指定します。Discover やダッシュボードで調査する担当者には、Kibana 側で対象 Space の Discover: Read と Dashboard: Read も付けます。Agent Builder を利用させる必要がなければ、その機能の権限は None で構いません。 このロールを追加しても、担当者が別のロールから持っている広い権限は消えません。実際の閲覧範囲は、割り当て済みのロールを合わせて確認してください。また、トレースの生データにはプロジェクト名や ID などが含まれるため、社外に共有する際は確認とマスクが必要です。 参考資料 本記事は、以下の Elastic 公式ドキュメントと OpenTelemetry の仕様に基づいています。 Elastic 9.5: Columnar, VectorDB index mode & auto-calibration, and AI-driven alert triage（2026-08-04） https://www.elastic.co/blog/whats-new-elastic-9-5-0 Collect Elastic Agent Builder traces https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/collect-traces Elastic Agent Builder traces overview dashboard https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/agent-traces-dashboard Create alerts on Elastic Agent Builder trace data https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/create-alerts Monitor usage and costs for Elastic Agent Builder https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/monitor-usage Chat with Elastic Agent Builder agents（View Trace） https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/chat Permissions and access control in Elastic Agent Builder https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/permissions Elastic Agent Builder built-in skills reference（agent-builder-traces） https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/builtin-skills-reference Connect Elastic Agent Builder agents and Elastic Workflows https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/agents-and-workflows Elastic Agent Builder Kibana API（Converse API） https://www.elastic.co/docs/explore-analyze/ai-features/agent-builder/kibana-api Sample data https://www.elastic.co/docs/manage-data/ingest/sample-data OTel tracing for AI agents: token cost dashboards in Kibana（Elasticsearch Labs, 2026-07-28） https://www.elastic.co/search-labs/blog/opentelemetry-tracing-agent-builder OpenTelemetry Semantic Conventions for Generative AI https://github.com/open-telemetry/semantic-conventions-genai Elasticsearch OTel traces mapping（span.name alias、duration nanos） https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/otel-data/src/main/resources/component-templates/traces-otel@mappings.yaml Splunk Agent Observability（他社の Agent Observability の例として参照） https://www.splunk.com/en_us/products/agent-observability.html The post AI エージェントの「中で何が起きたか」を見える化する first appeared on Elastic Portal .

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 9 月 17 日に更新された About Amazon の記事「 AWS、米国とアイルランドを結ぶ海底ケーブル Fastnet を展開 」では、米国メリーランド州とアイルランドのコーク県を結ぶ大西洋横断の海底光ファイバーケーブル Fastnet が紹介されています。2028 年の運用開始時には 320 Tbps を超える設計容量（HD 映画 1,250 万本の同時ストリーミングに相当）を備え、従来のケーブル回廊から離れた陸揚げ地点によって、他の海底ケーブルに問題が起きてもサービスを継続できる経路の多様性を確保します。増え続ける AI のトラフィックを見据えた設計で、生成 AI やエージェントを支える土台となるネットワーク層にも AWS の投資が続いていることが分かります。AWSを支えるインフラの裏側に興味がある方は是非読んでみてください。 また、お昼休みの 30 分で最新情報を知れる「 もぐもぐAWS 」では、AI をテーマにした会が予定されています。是非カレンダーをチェックしてご参加ください。 それでは 9 月 14 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 AWS Professional Services と実現する第一興商カラオケ聴感採点 AI の開発 」 株式会社第一興商と Amazon Web Services Japan の共同執筆記事です。通信カラオケ「DAM」シリーズの採点機能を高度化するため、第一興商は AWS Professional Services と共同で人間の聴感に即した歌声評価 AI「聴感採点モデル」を開発し、フラッグシップモデル LIVE DAM WAO! に搭載された採点機能「精密採点Ai Heart」の中核として活用しています。従来の機械採点は音程・リズム・ビブラートなどの音響パラメータを機械的に評価する方式で、人間が心地よいと感じる歌声のニュアンスを十分に評価できず、機械的に高得点を狙う「採点歌い」を過大評価しがちという課題がありました。最も困難だったのは「人間の聴感」を表す教師データの作成で、当初の 5 段階尺度法は審査員のブレが大きかったため、AWS Professional Services の提案で 2 つの歌声を聴き比べる一対比較法に切り替え、約 15 万回のラベル作業を経て Bradley-Terry 法で聴感スコアに変換しています。歌唱音源はオープンソースの深層学習モデル Audio Embedding Generator で 1 秒ごとに 128 次元のベクトルに変換し、AWS Fargate for Amazon ECS による最大 1,000 並列の基盤で約 13 万ファイルを 1.5 時間で処理しました。ラベリングには Amazon SageMaker Ground Truth、モデルの学習には AutoGluon Tabular と Amazon SageMaker AI を使い、製品化の際には DAM 端末のスペックに合わせた軽量化も行っています。人の感性という定量化しにくいものを教師データに落とし込む工程の工夫は、他分野の機械学習にも参考になります。 AWS生成AI国内事例ブログ「 【寄稿】株式会社レスター、Amazon Bedrock で顧客課題とグループの解決力をつなぐ情報プラットフォームを構築 」 半導体・電子部品の販売やソリューション提供などを手がける株式会社レスターによる寄稿記事です。事業領域の拡大とグループ再編で顧客基盤や商材、知見が広がる一方、他の会社・事業・部門が何を得意とし、どの顧客と接点を持つのかを把握しにくいという課題に対し、分散していた営業情報を一つの土台に集める AI 情報プラットフォームを構築しています。中核となるレスターマッチングサービス（RMS）は、顧客ニーズと解決手段を結びつけるマッチングの仕組みであると同時に、顧客・取引実績・担当者・商材・議事録などを関係性を保ったまま蓄積するグループ共通のデータウェアハウスです。情報の流れを「データ化」「蓄積・統合」「引き出して提案へつなぐ」の 3 段階に整理し、AI 議事録では商談の録音を Amazon Transcribe で文字起こし・話者分離したうえで Amazon Bedrock 上の Anthropic Claude が議事録として整理し、AI チャットボットでは LangGraph で構築したエージェントを Amazon Bedrock AgentCore Runtime 上で動かし、Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless による RAG（検索拡張生成）で社内文書や議事録を検索します。録音時の同意取得、議事録ごとに参照対象へ含めるかの選択、競合情報の閲覧制限、人による最終判断といった運用ルールに加え、モデルの追加学習と RAG での参照を混同しないよう「AI に学習させる」ではなく「社内 AI 回答時の参照対象に含めるか」と表現する工夫も紹介されています。 AWS生成AI国内事例ブログ「 NTTドコモ モバイルイノベーションテック部における AI-DLC 実践（第1回）：フィジカルAI領域でのML開発への適用 」 株式会社NTTドコモ モバイルイノベーションテック部が、AWS が提唱する AI-DLC（AI-Driven Development Lifecycle）の TTT（Train The Trainer）に参加し、フィジカル AI（現実世界で物理的に動作する AI）領域の機械学習パイプラインを 3 日間のチーム開発で構築した取り組みを、全 2 回で紹介する寄稿記事の第 1 回です。対象は SO-101 ロボットアームで「キューブを持ち上げる」タスクで、模倣学習モデル（ACT）は人手で収集した 10 件のデモデータでは成功率 10%、NVIDIA の COSMOS や Mimic によるデータ増幅で 45% まで向上したものの改善が頭打ちになったため、模倣学習で得た動作知識を軽量なポリシーに蒸留し強化学習で改善する RPD（Refined Policy Distillation）論文のアプローチを採用しています。個人が AI と対話しながら進める Vibe Coding では判断やコンテキストが蓄積されないという課題意識から、要件の構造化と設計レビューを重視する AI-DLC を ML 開発に適用し、Inception フェーズではチーム全員が Kiro を囲むモブスタイルで論文や専門情報を読み込ませながら、4 つのタスクリストと 3 つの実装ユニットを定義しました。Kiro による設計レビューでは、チェックポイント形式の不一致や入力次元の食い違いなど 11 個の不整合を実装前に検出し、Inception フェーズだけで 30 以上の構造化ドキュメントを生成しています。「コードが動くが出力が正しくない」不具合が起きやすい ML 開発で、設計段階の整合性チェックが手戻りの削減につながるという実感が語られています。 AWS生成AI国内事例ブログ「 NTTドコモ モバイルイノベーションテック部における AI-DLC 実践（第2回）：2チーム並行開発の実験結果と知見 」 第 2 回は、Construction フェーズにおける 2 チーム並行開発の実験結果と知見です。両チームは蒸留から PPO（強化学習）、評価までのパイプライン構造を共有しつつ、チームピンクは KL ペナルティの効果検証、チームブルーは蒸留初期化そのものの効果検証と、細部の設計判断を分けて比較しました。実装開始直後に ACT の学習環境構築に想定以上の工数がかかると判明したチームブルーは、AI-DLC のプロセスに従って Inception フェーズに立ち戻り、タスクリストの優先度を根拠にスコープを絞る軌道修正を行っています。3 日間の結果は、模倣学習のみのベースライン 45% に対し、チームブルーで蒸留あり 64%、蒸留なし 90% と「蒸留初期化は逆効果」に見えるものでしたが、TTT 後に構造化された実験記録を読み返して Inception に立ち戻ったところ、座標変換の欠落が真因だったことが数時間で判明しました。座標変換を修正し損失関数を変更して再蒸留したうえで PPO を実行した結果、成功率は 97% に到達し、蒸留なしの 90% を統計的に有意に上回っています。1 日で 3 回の実験サイクルを回せたこと、専門家が不在でもパイプラインを構築でき専門家は品質の最終確認に集中できる状態になったこと、そして失敗の記録が次のサイクルの出発点になることが、AI-DLC を ML 実験に適用する利点として整理されています。 ブログ記事「 【開催報告】ファッション・アパレル業界向け 第一回ナレッジ共有会 〜 SMART から始まる業界共通課題への挑戦と学びの場 」 2026 年 7 月 29 日に開催された、ファッション・アパレル業界のお客様 6 社 20 名が参加したナレッジ共有会の開催報告です。AWS Prototyping Program から生まれ 2026 年 4 月に GitHub（aws-samples）で公開された店舗業務支援 AI エージェント SMART（Store Manager Agent for Retail Tech）と、Kiro も活用した合同ブートキャンプを起点に、各社が取り組んできた AI エージェント開発の実践ナレッジを企業の垣根を越えて共有する場です。サザビーリーグ IRIS 様は、グループの飲食ブランドである麺屋 猪一を対象に、SMART をベースとした週報・月報の自動生成機能を Amazon Bedrock、Amazon EventBridge、AWS Lambda、Amazon S3 Tables、Amazon Athena、Amazon SNS などで約 1 ヶ月半で開発し、店舗 PoC では約 15 分かかっていた週報作成が 0 分になり、現在は全 4 店舗で利用が始まっています。ジンズ様は店舗出身で IT 未経験のメンバーが Kiro とともに 2 週間で、Amazon Transcribe による音声テキスト化、Amazon Bedrock による感情分析・ペイン分類、改善案の自動生成、Excel 出力までを行う店舗フィードバック収集 Web アプリを構築し、アンドエスティ HD 様は「AI は判断しない。作戦を複数提示し、人が決める」という設計思想のもと Amazon Bedrock AgentCore を活用した在庫消化 Agent の開発を 2.5 ヶ月進めています。 ブログ記事「 セキュリティにおける AI の現在地: 信頼構築に最も重要な指標の測定 」 AWS は、AI モデルが実際の脆弱性と「危険に見えても本当は安全なコード」を区別できるかを直接測定する初のベンチマーク Deception Benchmark を公開しました。16 のプログラミング言語、70 を超える CWE（Common Weakness Enumeration）カテゴリにわたる 14,822 個のサンプルで構成され、パラメータ化されたステートメントで SQL インジェクションのパスが閉じられている Flask エンドポイントのように、脆弱性パターンは見えるが緩和策によって悪用不可能になっているコードが含まれます。従来のベンチマークは AI が脆弱性を発見・悪用できるかを測るものでしたが、本ベンチマークは誤検出を見分ける防御側の適合率を測る点が新しく、5 社 12 モデルを評価した結果、標準的なプロンプトでは適合率が 50% 台半ばにとどまり、偽陽性率（安全なコードを脆弱と判定する率）と偽陰性率（実際の脆弱性を見逃す率）の両方を本番利用の最低基準とする 10% 未満に抑えられた構成はありませんでした。エクスプロイトの実証を求めるプロンプトでは偽陽性率が 17〜74 ポイント下がる一方で実際の脆弱性の 7〜44% を見逃すなど、どのモデルにも同じ失敗パターンが見られます。サンプルと評価ワークフローは GitHub で公開されており、ベンチマークが暗記の問題にならないようラベルは非公開です。AI セキュリティツールを評価する際は、脆弱性を発見できるかだけでなくどのくらいの頻度で誤るかをベンダーに確認し、リスクの高いコードパスでは人間の検証と組み合わせることが推奨されています。 ブログ記事「 自動推論に立ちはだかる 3 つの難題 」 Amazon の vice president 兼 distinguished scientist である Byron Cook 氏が 2025 年 8 月に Amazon Science Blog に公開した記事の翻訳です。生成 AI ベースのシステムで正しい推論を実現する際に最も厄介な 3 つの側面として、あいまいな自然言語を構造化された言語へ変換すること、絶えず変化し時には矛盾するルールのもとで何を真理とするかを定義すること、そして組み合わせの数が天文学的になる中で確定的に推論することを挙げ、Amazon Bedrock Guardrails の自動推論チェック（Automated Reasoning checks）がそれぞれにどう対処しているかを解説しています。自然言語の変換では、形式言語への変換候補を複数生成してソルバーで等価かどうかを証明・反証し、意味が食い違えばユーザーに確認を求めます。確定的な推論では SAT（充足可能性問題）ソルバーを活用しつつ、自身の判定結果を参照して矛盾を生むルールのように正しい答えが存在しないケースを Gödel の不完全性定理と結び付け、無矛盾性と完全性を同時に満たせない中で AWS は無矛盾性を選んだと述べています。自動推論チェックの背景にある考え方を理解するのに役立つ記事です。 ブログ記事「 はじめての自動推論 」 同じく Byron Cook 氏が 2021 年 12 月に Amazon Science Blog に公開した記事の翻訳で、上記「自動推論に立ちはだかる 3 つの難題」を読む前の予備知識としておすすめです。自動推論についてまったく知識のない業界の実務者向けに書かれており、必要な前提知識は短い C と Python のコード断片を読めることだけです。x + y == y + x を返す関数が false を返し得るかを unsigned int の全組み合わせで網羅的にテストすると 1,360 年以上かかる一方、自動推論ツールは代数を使ってミリ秒単位で答えを出せるという例から始まり、ループが必ず停止するかを推論する少し複雑な例を通じて、ツールが制御構造、最終的に真になること、常に真であることをどう推論しているかを直感的に説明します。末尾には書籍、国際会議、ツール、講演やブログへのリンクが豊富にまとめられており、さらに学びたい方の出発点になります。 ブログ記事「 自動推論による数学的確実性の 10 年: Automated Reasoning Group が歩んだ道 」 こちらも同じくByron Cook 氏が 2026 年 8 月に Amazon Science Blog に公開した記事の翻訳で、2016 年に発足した Amazon の Automated Reasoning Group（ARG）の 10 年を振り返ります。2016 年の第 1 回 Demo Day で紹介された、VPC ネットワークに関する質問に答えるツール Tiros は Amazon Inspector のネットワークセキュリティ分析や Reachability Analyzer の基盤になり、そこから派生した Zelkova は S3 Block Public Access や IAM Access Analyzer などポリシーを分析するツールの基盤になっています。現在 ARG の本番サービスは 1 日あたり数十億件のクエリを処理し、生成 AI 向けには Amazon Bedrock Guardrails の自動推論チェックがモデルの応答をポリシーに照らして形式論理で検証しています（検証精度は最大 99%）。自動推論が AWS のセキュリティと信頼性をどう支えてきたのか、その全体像をつかめる記事です。 ブログ記事「 エージェント型 AI による ERP ビジネスプロセス運用の変革 」 ある大手企業の Direct Ship（直送）請求業務では、ERP における手作業の例外処理が請求の遅延や収益認識への影響を招いていました。Accenture は Amazon Bedrock や Amazon Bedrock AgentCore などを用いたエージェント型 AI ソリューションを 5 週間で稼働させ、SOP（標準作業手順書）やジョブエイド、組織内のナレッジを一元化して自然言語で質問できる Digital Assistant と、SAP S/4HANA や認証用の Okta といった既存エンタープライズシステムとの統合機能を提供しています。アーキテクチャは、基盤モデルを提供する Amazon Bedrock、ツールの選択とワークフローのオーケストレーションを担う Strands Agents SDK、複数ターンの会話コンテキストを保持する Amazon Bedrock AgentCore、SAP S/4HANA へ安全に接続する AWS Lambda、事前処理した例外レポートを保存する Amazon RDS、レポートデータのロードを制御する AWS Step Functions の 6 つのサービスで構成されています。複数システムを行き来せずに SAP データへ即時アクセスでき、価値の高い注文を事後対応ではなくプロアクティブに処理できるようになったほか、新しいチームメンバーが対話を通じて組織のナレッジにアクセスできるようになった点が成果として挙げられ、同じパターンは調達や在庫管理など他の SAP モジュールにも拡張できるとしています。 ブログ記事「 ERP例外処理をAWSエージェント型標準作業手順書（SOP）で自動化 」 ERP の例外処理を AI エージェントで自動化するためのフレームワークとリファレンスアーキテクチャを解説する翻訳記事です。請求書の例外や購買発注（PO）の承認ブロック、月次決算などで発生する手作業の介入に対し、SAP ユースケース向けの AWS Agentic AI Solutions Framework と、その中核となるエージェント型標準作業手順書（Agentic SOP）を紹介しています。Agentic SOP は、業務プロセスごとに別々のエージェントを作るのではなく、ナレッジベースから SOP を動的に解釈し、SAP と非 SAP システムをまたいで複数ステップの例外を自律的に解決する単一の AI エージェントで、判断や承認が必要な箇所ではヒューマン・イン・ザ・ループの制御が働きます。フレームワークは、アドバイザリーモードから監督付き実行、自律的な解決へと段階的に信頼を獲得する仕組み、SOP 駆動の統合エージェントアーキテクチャ、決定論的で監査可能なアクションのためのガード付き MCP（Model Context Protocol）サーバー、ID を意識したセキュリティとコンプライアンス、監査水準の永続的な状態管理という 5 つのコア機能で構成されます。リファレンスアーキテクチャでは、Amazon EventBridge がスケジュール実行する AWS Lambda で SAP OData サービスから例外を検知し、Amazon DynamoDB に状態と監査証跡を記録しながら、Amazon Bedrock AgentCore 上の Strands エージェントが Amazon Bedrock Knowledge Bases から SOP と SAP OData API 仕様を取得して SAP への操作を実行し、必要に応じて Amazon SES 経由で人間へエスカレーションします。あるグローバル製造企業では、1,000 件を超えるアクティブな PO にまたがる 2 億 5,000 万ドル超の購買管理において、1 決算サイクルあたり 30 日超かかっていた手作業が PO あたり数分で完了するようになったとしています。 ブログ記事「 月刊 AWS 製造 2026 年 9 月号 」 製造業向けに 8 月に公開されたブログとサービスアップデートをまとめた月刊記事です。今月のピックアップトピックは「エージェントに現場を任せるとき、境界線をどこに引くか」で、PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあると指摘しています。コニカミノルタ様の「未来の実験室」では AI の担当を目標色・操作候補・停止条件へ分解した JSON の中間表現までに絞って座標制御は人が設計した決定論的な制御層が担うこと、SUMCO 様の SynchroFabAI では AI に任せるのは異常状態と因果関係の推測までで操作は人間が実施すること、AWS Summit の Physical AI デモではエージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ったことなど、AI の判断と現実世界への操作を直結させない共通の構図を取り上げています。境界を決める物差しとしては Amazon Science の SOP-Bench を挙げ、不要なツールを追加すると成功率がほぼ半減した実験結果を紹介したうえで、決めた境界を Amazon Bedrock AgentCore の時間的ポリシーや AgentCore Payments でインフラ側から強制する考え方をまとめています。 ブログ記事「 Kiro の GPT‑5.6 モデルが 100 万トークンのコンテキストウィンドウに対応 」 Kiro の IDE、CLI、Web のすべてで、GPT‑5.6 Sol、Terra、Luna が 100 万トークンのコンテキストウィンドウに対応しました。272K から 1M への拡大により、コードベース全体や長文ドキュメント、長く続いたマルチターンのエージェント履歴を、チャンク分割や要約を挟まず細部を失わないまま 1 回のリクエストで処理できます。記事では、レガシー移行や依存関係のマッピングといったリポジトリ規模の理解、API レイヤーやスキーマ、アプリケーションの状態が絡み合うバグのエンドツーエンドのデバッグ、セッションの全履歴を視界に残したまま進める長時間のエージェンティックなタスクの 3 つを、1 回のパスで可能になる仕事の例として挙げています。 ブログ記事「 Kiro Web の自律モードで技術的負債に大規模に立ち向かう 」 Kani Rust Verifier や CBMC といったオープンソースの形式検証ツールの保守や開発を担う AWS Automated Reasoning Group が、2025 年 11 月時点で 916 件あったオープン issue に Kiro Web の自律モードで取り組んだ事例です。app.kiro.dev でタスクを記述するか、GitHub issue に kiro ラベルを付けるか、コメントで /kiro とメンションすると、Kiro は隔離されたサンドボックスにリポジトリをクローンし、issue と関連コードの分析、作業の分解、変更の実装、テストスイート全体の実行を経てプルリクエストを開きます。Kiro はマージ権限を持たず、人間が書いたコードと同じ承認要件の対象になります。2 か月で Kiro は 87 件のオープン issue に対応するプルリクエストを提出し、これはそれまでの 22 か月でチームが対応した 94 件に迫る数で、マージされた Kiro 生成コードが持ち込んだリグレッションはゼロでした。2 年以上バックログに残っていた Kani コンパイラのクラッシュの issue を人間の作業 5 分未満で修正とリグレッションテストを含むプルリクエストにつなげたケーススタディのほか、CI は通るが修正を検証していないテスト、アーキテクチャ的に誤った修正、プラットフォーム固有の失敗、フォーマット違反といったうまくいかなかったパターンも紹介されています。 ブログ記事「 Claude Fable 5.1 が Kiro で利用可能になりました 」 Anthropic の Claude Fable 5.1 が、Kiro のエンタープライズ顧客向けに利用可能になりました。バグ修正や関数のリファクタリングといったインタラクティブなタスク、大規模なリファクタリングや長時間の自律実行のような複数ステップにわたるタスク、大規模なコードベース全体にまたがる推論を必要とするセキュリティやシステムレベルの複雑なタスクの 3 種類で到達点を引き上げるとしています。モデルはセッション全体を通して計画を保持し、Kiro の spec 駆動のアプローチによりタスクが成功しないと判断された場合には早期に停止してクレジットの消費を抑えます。 ブログ記事「 Kiro Crew でソフトウェアファクトリーを構築し、1 週間で 1000 件の PR をマージした方法 」 Kiro Crew をフルタイムで開発する 3 人のエンジニアが、7 日間で 1,000 件のプルリクエストをマージした経緯を振り返っています。1 日あたり 120 件を超えるプルリクエストはすべて CI とレビューを通っており、この数字は狙ったものではなく、並行開発の限界にぶつかるたびに 1 人がより多くのセッションを回せる進め方を生み出してきた結果だとしています。Kiro Crew 自体はこの 3 人を中心に 500 人近いコミュニティコントリビューターとともに開発されています。その変化は、1 セッションを手作業で回す段階、複数のタブを人間がつなぐ段階、memory・ダッシュボード・cron・workflow でセッションが温まった状態から始まる段階（10〜20 セッション）、triage・実装・レビュー・マージを独立したステージとキューでつなぐ agent pipeline の段階（20 セッション以上）、そしてセッションの外側に立つエージェントがゴールの分解・割り当て・巡回・受け入れ・順序付けを担い人間はゴールを持つだけになる Crew Mode の段階（50 セッション以上）の 5 つに整理されています。同時に、エージェント間の調整、memory の境界、ホスト側で強制する権限制御、エージェントが書き換えられない監査ログという 4 つのガバナンス上の問題と、数百セッション規模で立ち上がるコストの問題にも踏みこんでいます。 サービスアップデート 新しい AgentCore Runtime が Amazon Bedrock AgentCore で利用可能に Amazon Bedrock AgentCore 内のサーバーレス microVM コンピュートである AgentCore Runtime の次世代版が利用可能になりました。新しい Runtime は、セッション中に使われなくなったメモリを回収する弾力的なメモリ管理によってピーク値ではなく実際の使用量に対して課金されるようになり、エージェント環境を一度準備してスナップショットを取り、新しいインスタンスはそこから復元する仕組みによって、コンテナイメージのサイズや同時実行数に関係なく一貫したコールドスタート時間を実現します。事前プロビジョニング不要、ゼロへのスケール、ハードウェアで強制されるセッション分離、使った分だけの支払いというサーバーレスモデルはそのままです。東京リージョンを含む米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（アイルランド）、アジアパシフィック（東京）で利用でき、ランタイムの作成または更新時に platformVersion を V2 に設定することで使い始められます。 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供開始となりました。Moonshot AI によれば、Kimi K3 は同社で最も高性能なモデルで、2.8 兆パラメータに到達した初のオープンモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを組み合わせており、大規模リポジトリにまたがる長時間のコーディングセッション、スキャンしたページやスクリーンショットを含む複数ドキュメントの分析、長く続くエージェントワークフローに向いています。クロスリージョン推論を通じて、Amazon Bedrock が利用できるすべての AWS リージョンで利用できます。 Qwen3.6-35B-A3B-NVFP4 と Wan2.1-T2V-1.3B-Diffusers モデルが Amazon SageMaker JumpStart で利用可能に NVIDIA の Qwen3.6-35B-A3B-NVFP4 と Alibaba の Wan2.1-T2V-1.3B-Diffusers が Amazon SageMaker JumpStart で利用可能になりました。Qwen3.6-35B-A3B-NVFP4 は Alibaba の Qwen3.6-35B-A3B を NVIDIA が量子化したモデルで、総パラメータ 35B のうちトークンあたり 3B（256 のエキスパートのうち 8 つ）のみを活性化する Mixture-of-Experts 構成です。262K トークンのコンテキストウィンドウは YaRN スケーリングで約 1M まで拡張でき、NVIDIA の ModelOpt フレームワークで NVFP4 に量子化することで、会話ターンをまたいだ thinking の保持、マルチトークン予測、複数ステップのエージェントパイプライン向けのツール呼び出しを、メモリ使用量を抑えながら利用できます。Wan2.1-T2V-1.3B-Diffusers は 1.3B パラメータのテキストから動画への生成モデルで、8.19 GB の VRAM で動作し、RTX 4090 で 5 秒の 480p 動画を約 4 分で生成できます。いずれも SageMaker JumpStart のモデルカタログか SageMaker Python SDK からデプロイできます。 Ministral-3-3B-Instruct-2512 と Ministral-3-8B-Instruct-2512 モデルが Amazon SageMaker JumpStart で利用可能に Mistral AI の Ministral 3 ファミリーから、Ministral-3-3B-Instruct-2512 と Ministral-3-8B-Instruct-2512 が Amazon SageMaker JumpStart で利用可能になりました。いずれもエッジ展開やリソースの限られた環境向けに設計された、ビジョン対応のコンパクトな言語モデルです。3B モデルは 3.4B の言語モデルと 0.4B のビジョンエンコーダで構成され、FP8 では 8GB の VRAM に収まりながら 256K トークンのコンテキストウィンドウに対応し、英語、フランス語、スペイン語、ドイツ語、中国語、日本語、韓国語、アラビア語を含む数十言語での指示追従、システムプロンプトへの高い遵守性、構造化 JSON 出力を伴うネイティブな関数呼び出しを Apache 2.0 ライセンスで提供します。8B モデルは 8.4B の言語モデルと 0.4B のビジョンエンコーダで構成され、FP8 なら 12GB の VRAM に収まり、より大きな Mistral Small 3.2 24B に匹敵する能力を備えます。SageMaker JumpStart のモデルカタログか SageMaker Python SDK からデプロイできます。 Gemma-4-31B-it-assistant と Gemma-4-31B-IT-NVFP4 モデルが Amazon SageMaker JumpStart で利用可能に Google DeepMind の Gemma-4-31B-it-assistant と NVIDIA の Gemma-4-31B-IT-NVFP4 が Amazon SageMaker JumpStart で利用可能になりました。Gemma 4 のフラッグシップである 31B の dense モデルを、フル精度版と量子化版の両方で利用できます。Gemma-4-31B-it-assistant はアシスタント向けにチューニングされたモデルで、テキストと画像（フレーム列としての動画を含む）を入力としてテキストを出力し、256K トークンのコンテキストウィンドウと 140 以上の言語に対応します。 granite-speech-4.1-2b、kanana-2-30b-a3b-instruct、OpenFold3 モデルが Amazon SageMaker JumpStart で利用可能に IBM の granite-speech-4.1-2b、Kakao の kanana-2-30b-a3b-instruct、OpenFold Consortium の OpenFold3 の 3 モデルが Amazon SageMaker JumpStart で利用可能になりました。granite-speech-4.1-2b は英語、フランス語、ドイツ語、スペイン語、ポルトガル語、日本語を対象とした多言語の自動音声認識（ASR）と双方向の音声翻訳（AST）向けに構築された 2B パラメータのモデルで、単語誤り率 5.33%、リアルタイムファクター約 231 の性能を Apache 2.0 ライセンスで提供します。kanana-2-30b-a3b-instruct は Kakao が開発した韓国語・英語バイリンガルの指示追従とエージェント型 AI ワークフロー向けモデルで、Multi-head Latent Attention（MLA）と Mixture-of-Experts（MoE）を採用し、30B の総パラメータのうちフォワードパスごとに 3B のみを活性化、YaRN スケーリングで最大 128K トークンに対応します。OpenFold3 は OpenFold Consortium とコロンビア大学の AlQuraishi Lab が開発した拡散ベースのモデルで、タンパク質、DNA、RNA、小分子リガンドを含む生体分子複合体の全原子構造予測を行い、コンピュータ支援創薬などの研究に活用できます。 Amazon SageMaker AI がトレーニングジョブと処理ジョブのインスタンス優先リストに対応 Amazon SageMaker AI のトレーニングジョブと処理ジョブで、インスタンスの優先リストを指定できるようになりました。これまではジョブ投入時に 1 つのインスタンスタイプしか指定できず、需要の高い GPU ではそのインスタンスが確保されるまで待つか、複雑なリトライロジックを組むか、異なるインスタンスタイプで複数のジョブを同時に投入して対処する必要がありました。今回のアップデートでは、たとえば ml.g6.48xlarge を 2 台、または ml.g5.48xlarge を 4 台といった優先順位付きのリストを渡すと、SageMaker がリストを順に確認し、容量が確保できた最初の構成でジョブを起動します。同じジョブ投入の中で、オンデマンドと予約済みの SageMaker Flexible Training Plans のどちらから容量を調達するかも設定できます。既存のトレーニング・処理ジョブの API の範囲で使え、SageMaker が利用できるすべての AWS リージョンで CLI、API、SDK、コンソール UI から利用できます。 Amazon Q Console で CloudTrail イベントを自然言語で分析 AWS CloudTrail が Amazon Q Console と統合され、AWS アカウントのアクティビティを自然言語で調査できるようになりました。クエリを書いたりログファイルを手作業で解析したりせずに、CloudTrail のトレイルが適切に設定されているか、ロギングのカバレッジに抜けがないか、どのデータイベントソースを記録しているかといった設定の確認から、特定の IAM ロールに誰がアクセスしたか、VPC 設定にどんな変更が加えられたか、過去 1 週間に不正なアクセス試行がなかったかといったセキュリティ調査、特定のリソースを作成・削除したのは誰か、どの API 呼び出しがエラーを発生させているか、なぜ請求が急増したのかといった運用上のトラブルシューティングまで質問できます。Amazon Q Console がサポートされているすべての AWS 商用リージョンで利用できます。 Amazon Quick が個別シートの生成と画像からの分析作成に対応 Amazon Quick の Generate Analysis が拡張され、ダッシュボードをより速く作るための 2 つの方法が追加されました。Generate Sheet では、既存の分析の中に追加したいシートを自然言語で説明すると、データに合わせて選ばれたビジュアル、フィルターコントロール、前年比や前月比といった計算フィールドを含むシートが追加され、ビジュアルを 1 つずつ手作業で組まなくても分析を拡張できます。画像からの分析生成では、他の BI ツールのダッシュボードを含む既存ダッシュボードの画像をプロンプトに添付すると、Amazon Quick がサポートする範囲で編集可能な分析として再作成します。ローンチ時点では Enterprise サブスクリプション / Author Pro ユーザーが利用でき、組織がアクセスを制限していない場合は Author も Amazon Quick Enterprise の一部として 2026 年 12 月までプロモーションアクセスで利用できます。Amazon Quick が利用できるすべての AWS リージョンで一般提供されています。 Kiro IDE 1.1 : Agent Artifacts とネイティブ ARM64 ビルド Kiro IDE 1.1 では、エージェントの出力を後から見返せる成果物として扱う Agent Artifacts が加わりました。ドキュメント、図、コード、画像などのエージェント出力をチャットの履歴に埋もれさせず永続的なアーティファクトとして残し、会話からコンパクトなプレビューを開く、Agent Focus でチャットの横に全体を表示してレビューする、Agent Focus のコンテキストパネルから後で戻る、といった使い方ができます。あわせて Windows と Linux 向けのネイティブ ARM64 ビルドが提供され、x64 エミュレーションに頼らずダウンロードページから各プラットフォーム用の ARM64 版を選べます。エディタの基盤は Code OSS 1.131 に更新され、コンパクションされた会話が適切なコンテキストを保持するようになったほか、MCP の失敗が分かりやすくなり、Hooks の信頼性が向上し、エンタープライズプロファイルが選択したリージョンへリクエストをルーティングするようになりました。 Kiro Model : GPT-5.6 Sol、Terra、Luna が 1M コンテキストウィンドウにアップグレード 2026 年 9 月 14 日付の Kiro のモデル changelog です。Kiro IDE、CLI、Web で GPT-5.6 Sol、Terra、Luna のコンテキストウィンドウが 272K から 1M トークンに拡張され、あわせて GPT-5.6 ファミリーのクレジット倍率が更新されました。詳細は上記のブログ記事「 Kiro の GPT‑5.6 モデルが 100 万トークンのコンテキストウィンドウに対応 」をご参照ください。 Kiro CLI 2.22 : フルスクリーンチャットとセッション一覧の効率化 Kiro CLI 2.22 では、インタラクティブな TUI セッションと Lite セッションでフルスクリーンチャットが使えるようになりました。 /fullscreen と入力すると、現在の会話がシェルの履歴とは独立したスクロール可能な専用のターミナル画面に移り、もう一度 /fullscreen と入力するとインライン表示に戻ります。V2 と V3 のどちらでも利用でき、マウスやタッチパッド、キーボードでスクロールし、クリックとドラッグで選択したテキストをコピーできます。今後の TUI セッションを常にフルスクリーンで始めたい場合は /settings の Display で Start fullscreen をオンにします。V3 のセッションダッシュボードも整理され、 /sessions では検索・フィルター・ソート・グループ化のコントロールがセッション一覧から分離され、最終利用順のフラットな一覧として開き、最終利用・セッション名・メッセージ数でのソートと選択内容の記憶に対応し、Tab キーでコントロールと結果の間を移動できます。あわせて、長時間にわたる作業の信頼性も改善されています。 Kiro Model : Claude Fable 5.1 のプレビューが Kiro Enterprise 向けに展開開始 Kiro Enterprise の組織向けに、Claude Fable 5.1 のプレビューが Kiro の各クライアントで段階的に展開され始めました。1M のコンテキストウィンドウと 6 倍のクレジット倍率で提供され、推論は米国東部（バージニア北部）（us-east-1）のみで実行されます。有効化の手順やデータ保持の扱いなど詳細は上記のブログ記事「 Claude Fable 5.1 が Kiro で利用可能になりました 」をご参照ください。 最後に生成 AI の活用を検討されている企業の皆様に向けて、AWS ジャパンでは「 AWS ジャパン生成 AI 実用化推進プログラム 」をご用意しています。ぜひご活用ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近ハーブを育てるのにハマってます。

みなさん、こんにちは。ソリューションアーキテクトの 大前 です。9 月に入り一段と涼しくなってきましたが、いかがお過ごしでしょうか。今月は「エージェントに現場を任せるとき、境界線をどこに引くか」をピックアップトピックとしてお届けしつつ、8 月に公開された製造業向けのブログとサービスアップデートをご紹介します。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。 ピックアップトピック: エージェントに現場を任せるとき、境界線をどこに引くか PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあります。今回ご紹介している記事のいくつかでは、同じ問いに別の角度から答えていました。 AI に判断を任せ、実行は別の層で制御する コニカミノルタ様の「未来の実験室」 では、材料開発の実験を「緑色を作ってください」と自然言語で指示できます。ただしモデルは座標や動作列を生成しません。担当は目標色・操作候補・停止条件へ分解した JSON の中間表現までで、座標制御は人が設計した決定論的な制御層が担います。役割を絞ったので、軽量な Claude Haiku 系でも成立します。 SUMCO 様の SynchroFabAI も同じ構図で、AI に任せるのは「異常状態の推測」と「因果関係の推測」までであり、操作は人間が実施します。 AWS Summit での Physical AI デモ構築 においても、エージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ることで安全性を保ちながらロボットが動くデモを構築しました。これらに共通するのは、AI の判断と現実世界への操作を直結させず、その間に人の確認や決定論的な制御、外部から強制される権限制御を置いている点です。 では、どこまでをAIに任せ、どこからを人や制御層に渡すべきでしょうか。その境界は、モデルの性能だけでは決められません。8 月に公表された Amazon Science の論文で提案されている SOP-Bench では、標準作業手順書（SOP）を AI エージェントに実行させて成功率を測定しています。11 のモデルで試した結果、新しいモデルが必ず高い成功率を示すわけではありませんでした。また、ツール構成を比較した実験では、必要なツールだけを与えた場合に比べ、不要なツールを追加すると成功率がほぼ半減しました。自社の手順と実際のツール構成で性能を測り、安定して実行できる範囲だけをAIに委ねることが、AI と人間の境界を決める現実的な方法です。ただし、境界を決めるだけでは十分ではありません。実運用では、その境界を技術的な制約として強制する必要があります。 決めた境界をインフラ側で強制する 8 月は Amazon Bedrock AgentCore にこの方向の機能が 2 つ加わりました。 時間的ポリシー は、それまでの操作履歴を踏まえて各リクエストを評価する認可ルールで、作業順序の強制や特権操作前の人間承認を設定できます。 AgentCore Payments では支払い上限をインフラ層で強制できます。 「危険な操作をしないでください」とプロンプトに書くのと、そもそもその操作が許可されない状態を作るのは、まったく別のことです。後者は OT のインターロックに近い考え方です。エージェントを現場に出すために必要なのは、モデルを賢くすることだけでなく、任せない範囲を先に決め、その境界を外部から強制することなのかもしれません。 直近で開催予定のイベント 9/14 – 9/19 IMTS 2026 北米最大級の工作機械展示会がシカゴで開催されます。AWS もブースを出展予定で、量子コンピューティングと製造業をテーマにした AWS 主催のレセプションもあります。 10/13 – 10/16 CEATEC 2026 JEITA 主催のデジタルイノベーションの総合展示会が幕張メッセで開催されます。テーマは「Transformation -企業が、産業が、そして社会が変わる-」です。 AWS も Hall 4 で、安川電機様とご一緒に展示を予定しています。 10/26 – 10/31 JIMTOF2026 世界最大級の工作機械見本市が東京ビッグサイトで開催されます。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントがラスベガスで開催されます。2,200 を超えるセッションが予定されています。 製造関連ブログのご紹介 8/3 Engineering Development Hub : A unified workbench to accelerate product development 製品開発チームは、 分断されたツール・データサイロ・計算リソース制約 という課題に日々直面しています。 Engineering Development Hub (EDH) は、複雑なシステムの設計・テスト・検証に必要なアプリケーション・計算・データを1つのオープンソース環境に統合した、クラウドベースのエンジニアリングワークベンチです。 Amazon Lab126 や Rivian などの顧客が既にEDHを活用しており、NVIDIA Isaac Sim でのフィジカルAI模倣学習や車載インフォテインメント開発などの実例を紹介しています。 大規模ハードウェア開発を高速化したい設計・開発部門の方におすすめです。 8/6 Run HPC Simulations faster with Siemens Teamcenter and AWS ParallelCluster 「解析の順番待ちで設計が止まる」という課題を、Teamcenter Simulation と AWS ParallelCluster の連携で解いた記事です。設計を選んでジョブを投げれば入力は自動で置かれ、計算ノードは終われば消えます。数日の設計スタディが数時間に。 解析のリードタイム短縮を検討している CAE・解析部門の方におすすめです。 8/7 Leading FMEG Player Builds Manufacturing Control Tower on AWS 工場ごとにデータが閉じていると、異常に気づくのは手遅れになってからとなります。本記事ではインドの大手電設機器メーカーが約 15 工場を 4 層構成でつなぎ、障害後の意思決定を 24 時間超から 2 時間未満に、拠点追加の工数を 1 工場あたり 20% 未満（従来は 80〜100%）に縮めた事例をご紹介しています。 複数拠点の OT データ統合をこれから広げる方におすすめです。 8/18 SUMCO が挑む、Amazon Redshift × 生成 AI による半導体ウェーハ製造 DX 株式会社 SUMCO 様との共著です。ネットワーク分離と権限分離によるセキュアな AWS 基盤上に、データ分析パイプラインの RedPulse と自然言語でのデータ分析を実現する SynchroFabAI を積み上げた道筋が語られます。 セキュリティを担保しつつ、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析などによるデータ分析の力を組織全体に広げていく過程をご覧いただけます。 8/19 Agentic AI でつなぐモノ・サービスの改善サイクル リリース後に溜まる運用データが、次の開発に一度も戻ってこない。その原因を「データのサイロ」と「人材のサイロ」に切り分け、Amazon Quick で埋める方法です。AI 自身が仮説を立てて検証まで進みます。 製品の改善サイクルを回したい開発・品質部門の方におすすめです。 8/20 Amazon Bedrock とロボティクスで目指す「未来の実験室」 コニカミノルタ株式会社様との共著です。材料開発の実験を自然言語で指示すると、ロボットアームが実際に手を動かし、結果が電子実験ノートに戻るという閉ループを約 2 か月で実装されています。開発には Kiro CLI を活用されており、 生成 AI をチャットの外の実機制御へ広げたい研究開発部門の方におすすめです。 8/21 Accelerating Chip Tape-out with AWS Unified Operations 半導体企業がAWS上でEDA（電子設計自動化）ワークロードを実行する際、インフラの可用性・性能がチップ納期に直結します。 AWS Unified Operations はAWSの最上位サポート層にあたり、専任チームが、アーキテクチャ支援・迅速なインシデント対応・財務最適化・セキュリティ監視を提供します。本記事では、12 か月のテープアウト工程に沿って Unified Operations がどのように支援を行うのかを紹介します。 高可用性が求められる HPC ワークロードを抱える方におすすめです。 8/21 SOP-Bench: A new benchmark for evaluating AI agents on real business procedures Amazon Science が発表した、標準作業手順書（SOP）を AI エージェントに実行させる公開ベンチマークです。倉庫点検や危険物分類を含む、12 業務領域・2,000 超のタスクを実際に動くツールと正解付きで用意し、エージェントの。自社の手順を足して評価することもできます。 エージェントを本番に載せる前の物差しが欲しい方におすすめです。 8/24 ソフトウェア開発を AI エージェントで加速する ── TOPPAN が体験した SDLC 主要フェーズの手応え TOPPAN 株式会社様との共著です。20 名が Kiro CLI を活用し、SDLC の Research・Plan・Release をAI と協調しながら回す体験を行いました。レガシーコードから設計書を復元する手応えや、AWS MCP Server を頼りに CI/CD を組む感触が率直に語られます。 AI を活用した開発の効率化に興味のある方におすすめです。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで 6 月の Summit で展示した「AI エージェントが街の障害物を自律的に見つけて片付ける」デモを、どう作ったかの記録です。10 名全員が兼務で、実機を使った統合に充てられたのは本番前の約 1 か月という過酷な条件の中で、企画の可視化から 3D モデリング、実装、説明員資料などの全工程を生成 AI と伴走する過程を紹介しています。 AI を使った開発プロセスの型づくりに関心のある方は、ここから読むと全体像がつかめます。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編 上記デモのロボット側です。FANUC 社製協働ロボット 2 台をクラウドの AI エージェントと連携させるデモ開発の裏側をご紹介しております。画像から動作指令までを 1 つのモデルで出す方式を採らなかった理由、コーディングエージェントの権限を「変更できる／人の承認が要る／エージェントの外で強制される」の 3 つに切った線引き、そして手先の向きを保つ拘束を AI が誤って無効化した経験から「禁止と代替手順はセットで書く」に至った経緯まで、任せる範囲の決め方が具体的に語られます。 今号のピックアップトピックの実例編として、あわせてお読みください。 製造関連の主要なサービスアップデート 8/3 Amazon SageMaker AI がフルファインチューニングに対応 25 以上のオープンソースモデルで全パラメーターを更新できます。設備の型式ごとの符牒や検査基準といった組織固有の語彙を、モデルに深く覚え込ませたいときにご利用いただけます。 8/4 AWS Security Hub Extended がソフトウェアサプライチェーンのセキュリティに対応 外部から取り込むオープンソース部品に悪意あるコードが混ざっていないかを、アプリに組み込む前に検出・遮断できます。 8/6 AgentCore に時系列ポリシーとレート制限を追加 ピックアップトピックでご紹介した機能です。宛先ごとのリクエスト数・トークン数の上限も併せて設定できます。 8/7 AWS Parallel Computing Service が FedRAMP・SOC・ISO・PCI の対象に マネージド HPC サービスである、Parallel Computing Service がSOC、ISO などの主要な第三者認証の対象になりました。統制・監査要件が壁になっていた技術計算部門の導入判断を後押しします。 8/11 AWS Glue から SageMaker Unified Studio へワンクリックでアクセス AWS Glue と同じ権限のままクエリ・品質チェック・パイプライン構築へ移れます。データカタログの整備から分析・AI 活用までを、ツールを行き来せずに進められます。 8/18 AgentCore payments が一般提供開始 エージェントが有料の API を自ら見つけて使い、決済まで行えます。支払い上限はインフラ側で強制されるので、外部データを都度買う調達系エージェントも統制下で運用できます。 8/19 Amazon SageMaker のノートブックが Trusted Identity Propagation に対応 共有ロールではなく利用者本人の ID でデータ参照を制御でき、誰が何を見たかが AWS CloudTrail に残ります。品質データや設計情報の閲覧範囲を部門・拠点で分けたい分析基盤にご利用いただけます。 最後まで読んでいただきありがとうございました。 今月は、AI に任せる範囲の決め方と、その境界を仕組みで守る方法をご紹介しました。来月も、製造業における AI 活用のヒントをお届けします。それでは、また来月お会いしましょう！ 著者について 大前 遼（Ryo Omae） ソリューションアーキテクト 大前 遼（Ryo Omae）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。製造業のお客様を中心に、クラウド活用の技術支援を行っています。好きな領域は機械学習や生成 AI ・ロボティクスで、最近は Physical AI デモの構築に注力しています。