こんにちは。エンタープライズ第一本部 戦略ソリューション 1 部の英です。 普段はWebアプリやスマホアプリの案件などを担当しています。あと、趣味でAIを勉強しています。 世界中がJevの話題で持ち切りなので、流行りに乗ります。 忙しい人向けに短く簡潔に書きます！きっと5分後には Jevわかったかも！ の状態になると思います。 試しに電通総研テックブログの記事100本を高速に仕分け、街に見立てて可視化してみたので、その様子をご覧ください！ 弊社のこれまでの歩み、成長が高速に可視化されます。 Jevとは？ 文章を生成するAIではなく、 小さな判断を高速に返すAI です。 「どのカテゴリか」「何点か」「Yes / No か」を確率付きの構造化データで返します。分類、スコアリング、タグ付け、大量データの仕分けが主戦場です。 どういう仕組み？ 文章(state)と質問(questions)を渡します。質問は3種類で、1回の呼び出しに複数まとめて同時に評価できます。 種類 返るもの 例 Choice 選択肢ごとの確率 この記事の主題は? Score 段階ごとの確率と期待値 技術的な深さは0〜4のどこ? Noul Yesの確率(0〜1) AWSの記事? TypeSafeは 公式ブログ で、新しいモデルアーキテクチャ、Parallel Sampler、 RLCD(Reinforcement Learning for Calibrated Decisions)という学習法を採用していると説明しています。 もう少しだけ中身の話(解釈込み) TypeSafeによると、Jevは従来のLLMとは異なる新しいモデルアーキテクチャを採用し、Parallel Sampler と RLCD（Reinforcement Learning for Calibrated Decisions）という仕組みを使っています。内部アーキテクチャの詳細は現時点では公開されていません。 Parallel Sampler ：LLMのようにトークンを1つずつ生成するのではなく、複数の質問に対する出力を並列に返す RLCD ：判断結果に加えて、その確率や信頼度が適切になるよう学習する 型付きの出力 ：文章ではなく、Choice / Score / Noulなど事前に定義された形で結果を返す 誰が作った？ Diogo Almeida氏らが創業したTypeSafe AI 。Diogo Almeida氏はTypeSafe AIの共同創業者兼CEOで、元OpenAI・Google BrainのAI研究者。 なぜ速くて安い？ LLMはトークンを順に生成しますが、Jevは文章生成ではなく、型付きの判断とその確率を返すことに特化しています。複数の質問に対する出力も1回のクエリで並列に返します。公表値は応答70〜500ms、入力$0.042/百万トークン、 出力は無料 。TypeSafeの評価では、System One型のクエリでLLMより40〜200倍高速とのこと。 ということで試してみる 弊社のテックブログ100本をJevで分類し、 3Dの街を生成するミニアプリ を作りました。本ブログの歩みが可視化されます。 記事1本 = 1リクエストで16問をまとめて聞きます。 Choice ×1: 主題(AI / Cloud / Security / DevOps / Data / Software / Manufacturing / Productivity / Other) Score ×3: 技術的深さ、ハンズオン度、新しさ Noul ×12: AI / AIエージェント / AWS / Azure / Google Cloud / コード / アーキテクチャ / 実験 / ベンチマーク / CI/CD / IaC / セキュリティ アプリからの呼び出しは 計100回、並列5本 。1,600判定を100回で済ませ、5本同時に飛ばして1つ返るたびに次を投げます。 順に呼ぶと約65秒の計算ですが、実測13.26秒でした。Jevは1リクエスト全体で64kトークンまで扱えますが、state と最長の質問1つを合わせて32kトークンまでという制限があります。そのため、今回のように1記事約7,000トークンの場合、100記事を1リクエストにまとめることはできません。 技術は Next.js 15 + TypeScript、3D は React Three Fiber(Three.js)+ drei + postprocessing、状態管理は zustand。 Jev は公式 JavaScript SDK( @typesafe-ai/sdk )をサーバー側から呼んでます。 Jevの結果 街での表現 主題(Choice) 地区 技術的深さ / ハンズオン度 / 新しさ(Score) 高さ / 幅 / 発光 AIエージェント、AWS / Azure / GCP(Noul) リング、屋上のビーコン CI/CD、IaC(Noul) 屋上の回転バー、上部の足場格子 コード / アーキテクチャ / 実験 / ベンチ(Noul) パネル / アンテナ / パーティクル / メーター パネルの見方 建物をクリックすると実 API で再判定し、16問の答えを質問タイプ別に表示します。 Primary Topic(Choice) : 9カテゴリの確率のうち1位。 FEATURES(Noul) : 各項目が Yes の確率。複数同時に成立し、合計100%にはなりません。50%以上のみ表示。 SCORES(Score) : 期待値 ÷ 最大値。「75%」は0〜4の期待値3.0 / 4。 Classification NNN ms : 再判定1回のAPI往復時間。 INITIAL → LIVE : 最初の一括分析と再判定の差。 その後、建物が階層に分解されます。1層 = 1判定で、値が大きいほど厚くなります。 実測結果 100本を並列5で投げた結果(2026-09-24、 jev-1.13.0 、社内プロキシ経由)。 INITIAL BUILD Articles 100 Completed 100 Decisions 1600 Wall-clock time 13.26 sec Avg API latency 651 ms Median API latency 568 ms p95 API latency 1280 ms Fastest 278 ms Slowest 1578 ms Input tokens 707,688 「API latency」はJev APIの往復時間で、モデル内部の推論時間ではありません(ネットワーク分を含む)。 本文は先頭6,000文字で打ち切り。約71万トークン、公表単価で 約0.03ドル 。失敗0件(SDK既定の自動リトライを含む)。 入力トークン量と応答時間の相関はほぼなし(相関係数 0.07)。記事の長さより回ごとの揺れが大きい。 主題の分布: AI / GenAI 37、Security 17、Productivity 16、Cloud 11、Software 7、DevOps 4、Data 4、Manufacturing 3、Other 1。 「Amazon Bedrock Managed Knowledge Base が日本語PDFを扱えない件」は、主題 = AI / GenAI(1.00)、AWS 0.99、コード 0.97、実験 0.97、技術的深さ 3.0/4。製品ではなく「何の記事か」で分類され、AWSであることはNoulで別に拾えます。 5回再判定すると、主題は毎回100%で、境界が曖昧なFeatureだけ数ポイント揺れました。 INITIAL LIVE AI / GenAI 100% → 100% (5回とも) AI Agent 89% → 89% Architecture 59% → 61% / 59% / 58% Benchmark 52% → 50% / 53% / 52% Latency 1176ms → 824 / 859 / 893 / 939 / 1257 ms まとめ ということで今回は話題のJevを使ってみました。 分類モデルに似ていますが、現状扱えるデータはテキストが中心。判断を確率で返すところがポイントです。 とにかく速くて安いのが良いですね。今回の100記事の一括分析だけなら約$0.03、再判定や開発中の試行錯誤まで含めても今回の検証全体で$0.1程度しかかかりませんでした。驚異的ですね。 コールセンターなどで導入した場合、例えば閾値を80%に設定し、信頼度が80%以上ならJevを信頼してシステムで処理し、80%未満なら人の判断に回すみたいな使い方が良いと思います。 社内やシステム内のブルシットジョブをJevに置き換えるみたいな動きは今後あるかもしれませんね。 上司をJevに置き換えても、あなたの仕事は回るかもしれません。 大規模システムでも大した処理ではないのに、無駄にコードが複雑だったりするケースってありますよね。 これらはJevで外出すことで処理やコードを単純化できるかもしれません。 参考 TypeSafe AI 公式ドキュメント: https://docs.typesafe.ai/ Introducing System One Models & Jev(公式ブログ 2026-09-15): https://typesafe.ai/blog/introducing-system-one-models-and-jev 電通総研テックブログ: https://tech.dentsusoken.com/ 採用情報 先日Xで「JTCでは社内のAI利用が進んでおらず働きにくい」みたいなのが話題になってましたが、弊社はこの数年間で各種AIツールのライセンスや申請周りがかなり整備され、めちゃくちゃ働きやすいです。 AIを使って効率的に仕事したいSIの方はぜひご検討ください。ClaudeCodeもCodexも使いたい放題です。(2026年9月現在) ↓ のスターを押していただけると嬉しいです。励みになります。 最後まで読んでいただき、ありがとうございました。 エンタープライズ第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。 私たちは一緒に働いてくれる仲間を募集しています！ 中途採用-エンタープライズ第一本部 新卒採用-エンタープライズ第一本部 執筆： 英 良治 (@hanabusa.ryoji) レビュー： @wang.yuxin （ Shodo で執筆されました ）

2026年8月12日に、「Merpay Tech Talk 〜3年で50ヵ国へ。メルカリ決済基盤アーキテクチャ刷新の舞台裏〜」をオンラインで開催しました。 この記事はイベントレポートです。配信当日の内容を簡単に紹介します。詳しくは、YouTubeで公開している配信アーカイブ動画をご視聴ください。 イベント概要 メルカリは、日本に出品された商品を海外のお客さまが購入できる「メルカリグローバルアプリ」を提供しています。2025年に台湾でサービスを開始し、2026年春には米国でも展開しました。今後は 3年以内に50ヵ国以上へ拡大することを目指しています 。 サービスを多くの国へ展開するには、多通貨への対応だけでなく、国ごとに異なる決済手段や決済事業者との接続、言語や商習慣に合わせた決済画面、会計システムとの連携など、幅広い課題を解決する必要があります。 今回のイベントでは、グローバル展開を決済面から支えるPaymentチームのエンジニアが登壇し、決済画面と決済基盤のアーキテクチャをどのように刷新したのか、開発を通じて得られた成果や新たな課題とともに紹介しました。 登壇者 今回の登壇者は、Paymentチームでバックエンド開発に携わる以下の3名です。 tanaka0325 / 株式会社メルペイ Backend Engineer ryuyama / 株式会社メルペイ Backend Engineer tomo / 株式会社メルペイ Backend Engineer 3年で50ヵ国へ向けたPaymentチームの取り組み メルカリグローバルアプリの拡大に向けてPaymentチームのミッションには、多通貨や各国の決済手段への対応、決済画面のカスタマイズ、決済事業者との接続、会計システムとの連携などがあります。 今回のセッションでは、そのなかでも「決済画面」と「決済基盤」という2つの領域に焦点を当てました。新しい国や決済手段への展開を速めながら、プロダクトごとの柔軟性と、決済プラットフォームとしての一貫性・安全性をどのように両立したのかを説明しました。 決済画面を共通化するCheckout Solution 決済画面では、Paymentチームが提供する共通基盤「Checkout Solution」を活用しています。Checkout Solutionは、メルカリのさまざまなサービスが同じ仕組みの上で決済画面を提供できるようにするもので、2024年から国内向けに稼働しています。グローバルアプリでも、この仕組みを土台にしました。 以前は、新しいサービスを立ち上げるたびに各プロダクトチームが決済画面をゼロから実装していました。特に、3Dセキュアのような複雑な非同期フローをプロダクトごとに実装する必要があり、開発コストが大きくなるという課題がありました。 Checkout Solutionの考え方は、決済画面を「どのサービスでも同じ部分」と「サービスごとに違う部分」に分けることです。例えば、支払い方法を選ぶ欄や、購入ボタンを押したあとに支払いを確定する処理は、どのサービスでもほぼ同じです。一方で、配送方法の選択やクーポンの適用は、商品を発送するサービスと配送が不要なサービスとでは大きく異なります。 Checkout Solutionでは、前者を「Core Elements」、後者を「Flex Elements」と呼び、開発する担当も分けています。Core ElementsはPaymentチームが一度つくりすべてのサービスで共通利用し、複雑な決済処理をここに集約しています。Flex Elementsは各プロダクトチームが、自分たちのサービスに必要な要素だけを実装します。 この分け方により、新しいサービスの決済画面をつくるときは、プロダクトチームはFlex Elementsのデザインと設定を追加するだけで済み、内部の決済処理に手を入れる必要がありません。逆に、新しい決済手段を追加するときは、PaymentチームがCore Elementsを一度更新すれば、すべてのサービスの決済画面に反映されます。 グローバル展開に向けた決済基盤の刷新 決済基盤では、外部の決済事業者との接続と、残高・売上・会計イベントの管理方法を見直しました。 1つ目は、外部の決済事業者とのつなぎ方です。クレジットカード会社や各国の決済サービスなど、実際にお金を動かす事業者はPayment Service Provider（PSP）と呼ばれ、決済手段や国ごとに接続の仕方が異なります。 従来の決済サービスは日本国内向けに発展してきたため、こうしたPSPごとの接続ロジックが決済の中核サービスである Payment Service に直接組み込まれていました。その結果、新しい決済手段や通貨を1つ追加するだけでPayment Serviceに手を入れる必要があり、展開する国が増えるほど開発が難しくなる構造になっていました。 そこで、PSPとのやり取りだけを担当する「Payment Provider Service」に切り出しました。PSPごとの違いはすべてこのサービスのなかで吸収し、Payment Serviceは「どのPSPを使っているか」を意識せずに、注文から支払い完了までの流れを管理することに集中できるようにしています。 この分離によって、新しい国や決済手段を追加するときの変更範囲を、Payment Provider Serviceのなかに限定できるようになりました。 2つ目は、残高・売上・会計記録の管理方法です。決済が1件成立すると、お客さまの残高の増減、事業としての売上、そして会計上の記録という3種類の記録が発生します。従来はこれらを別々のサービスが管理し、その整合性を決済サービスが調整していたため、仕組みが複雑になり、記録どうしのずれを防ぐことが難しくなっていました。 新しい「Balance V2 + Bookkeeper」では、会計で使われる複式簿記の考え方を取り入れています。「今いくら残っているか」という残高と、「なぜ残高が変わったのか」という理由を必ずセットにし、1つのトランザクションとして同時に記録します。片方だけが記録される状態を許さないことで、決済と会計のずれを構造的に防いでいます。 刷新後の決済基盤は、グローバルアプリ向けにリリースし、クレジットカード、Apple Pay、Google Payをサポートしています。Apple PayとGoogle Payを追加した際は、上で紹介した仕組みにより、バックエンドの開発から品質保証までを約1カ月で完了できました。 最後に 3年で50ヵ国という目標に向けて、Paymentチームは決済画面と決済基盤の両面から、グローバル展開を支えるプラットフォームづくりを続けています。 今回紹介した内容の詳細や、登壇者による質疑応答は、ぜひ 配信アーカイブ動画 でご覧ください。 また、Merpay Tech Talkは、定期的にエンジニア向けのイベントを開催しています。イベント開催案内を受け取りたい方は、connpassグループのメンバーになってくださいね！ メルカリconnpassグループページ 関連記事 Checkout Solutionの詳細（決済画面基盤の設計） Building a Flexible Checkout Solution: Frontend Architecture for Multi-Service Integration メルカリのグローバル展開を支えるPayment Platformの進化 グローバル展開にむけたアプリと基盤の再構築 関連求人 Merpayでは、グローバル展開を支える決済画面・決済基盤の開発に一緒に取り組む仲間を募集しています。採用情報について、詳しくは以下のエントリーをご覧ください。 Software Engineer, Backend – Merpay Product Engineer, Backend – Merpay Senior Software Engineer, Backend – Merpay Senior Product Engineer, Backend – Merpay

みなさん、こんにちは。ソリューションアーキテクトの 大前 です。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 デモの構築に注力しています。