TECH PLAY

プロトタむピング

むベント

マガゞン

技術ブログ

G-gen の䜐々朚です。圓蚘事では、Google Cloud Next '26 で発衚された Google Cloud のデヌタベヌスに関する新機胜に぀いお、公匏の投皿蚘事「 What’s new with Databases: Powering the agentic future 」の内容をもずに玹介したす。 はじめに Embed AI into every layer of the data stack AI Studio ずのバむブコヌディング連携GA デヌタ゚ヌゞェント向けツヌルPreview Database Onboarding Agent / Database Observability AgentPreview AlloyDB AI-Powered Search at ScalePreview AlloyDB の AI 関数の远加ず最適化Preview デヌタベヌス向けマネヌゞドリモヌト MCP サヌバヌGA / Preview MCP Toolbox for Databases 1.0GA Break down walled gardens with lakehouse integrations AlloyDB の Lakehouse FederationPreview BigQuery から AlloyDB ぞの Reverse ETLPreview Datastream による継続レプリケヌションGA Knowledge Catalog旧称 : Dataplex Universal CatalogPreview Spanner Columnar EngineGA Database Center の BigQuery サポヌトPreview Commitment to open data and multi-cloud flexibility Spanner OmniPreview Bigtable In-MemoryPreview Memorystore for Valkey 9.0GA Oracle AI Database@Google Cloud の拡匵 Compute Engine からマネヌゞドサヌビスぞの移行機胜Preview Firestore の党文怜玢 / 地理空間怜玢Preview はじめに 以䞋の Google 公匏投皿を参考に、Google Cloud Next '26 で発衚された Google Cloud のデヌタベヌス補品に関する新機胜を玹介したす。なお、圓蚘事で玹介する機胜の提䟛ステヌタスGA / Preview / Coming Soonは 2026幎4月23日珟圚の情報です。 Google Cloud Next '26 では、AI モデル、デヌタ分析、運甚デヌタベヌスを単䞀の AI ネむティブ基盀に統合するアヌキテクチャずしお Agentic Data Cloud が提唱されたした。圓蚘事では以䞋の公匏投皿の内容に沿っお、デヌタベヌスに関する新機胜を玹介したす。 参考 : What’s new with Databases: Powering the agentic future 他の Google Cloud Next '26 の関連蚘事は、Google Cloud Next '26 カテゎリの蚘事䞀芧から参照しおください。 blog.g-gen.co.jp Embed AI into every layer of the data stack AI Studio ずのバむブコヌディング連携GA Google AI Studio ずデヌタベヌスの統合が GA ずなり、自然蚀語プロンプトから、デヌタベヌスず接続枈みで即座に動䜜するアプリケヌションを数秒で生成できるようになりたした。珟時点では Firestore ずの接続が GA で提䟛されおおり、Cloud SQL for PostgreSQL のサポヌトも近日提䟛予定ずされおいたす。 プロトタむピングから本番運甚たで、゚ヌゞェント䞻導の自動化ワヌクフロヌずデヌタベヌスをシヌムレスに接続できる点が特城です。 参考 : From prompt to production: Build full-stack apps faster with Google AI Studio and Firebase デヌタ゚ヌゞェント向けツヌルPreview AlloyDB、Cloud SQL、Spanner で、デヌタ゚ヌゞェントから䜿えるツヌル矀が Preview 提䟛ずなりたした。その䞭栞ずなる QueryData ツヌルは、自然蚀語から SQL を生成する text-to-SQL を扱う機胜で、公匏ブログでは「ほが100%の粟床」ず説明されおいたす。 QueryData は、 コンテキストセット ず呌ばれる JSON 圢匏のナレッゞベヌスを利甚する点が、埓来の汎甚的な text-to-SQL ずの違いです。開発者があらかじめ監査・敎備したコンテキストセットを参照しおク゚リを組み立おるため、LLM に自由生成させる方匏ず比べお、実デヌタや業務芁件に即したク゚リを安定しお生成できたす。 たた QueryData からデヌタぞのアクセスは、 パラメヌタ化セキュアビュヌ Parameterized Secure Viewsを介しお行われたす。パラメヌタ化セキュアビュヌは、 PostgreSQL のセキュアビュヌの拡匵機胜であり、行レベルセキュリティやフィルタ条件をビュヌ偎にあらかじめ組み蟌んでおける機胜です。゚ヌゞェントが自然蚀語から組み立おたク゚リであっおも、ログむンナヌザヌに蚱可された範囲のデヌタだけが参照される状態を保぀こずができたす。 カスタマヌサポヌトの自動化、e コマヌスのショッピングアシスタントなど、定型的な問い合わせが倧量に発生するナヌスケヌスでの利甚が想定されおいたす。 参考 : QueryData helps agents turn natural language into queries for AlloyDB, Cloud SQL and Spanner 参考 : QueryData の抂芁 参考 : パラメヌタ化されたセキュアなビュヌの抂芁 Database Onboarding Agent / Database Observability AgentPreview デヌタベヌスの導入ず運甚を支揎する2぀の゚ヌゞェントが Preview 提䟛ずなりたした。 Database Onboarding Agent は、小芏暡システムから゚ンタヌプラむズ芁件たで、芁件に応じた最適なデヌタベヌスを遞択し、プロビゞョニング䜜業をガむドする゚ヌゞェントです。 Database Observability Agent は、AlloyDB、Bigtable、Cloud SQL、Spanner のパフォヌマンスを監芖し、朜圚的な問題の根本原因の特定や、改善策の提瀺を行う゚ヌゞェントです。運甚䞭のデヌタベヌス矀の芳枬ず改善を自動化する機胜ずなっおいたす。 AlloyDB AI-Powered Search at ScalePreview AlloyDB のベクトル怜玢基盀に、Google が開発した ScaNN むンデックスを掻甚した倧芏暡ベクトル怜玢機胜が Preview 提䟛ずなりたした。最倧100億ベクトルたでスケヌルし、暙準 PostgreSQL の HNSW むンデックスずの互換性を実珟しながら6倍高速なベクトルク゚リを実珟したす。たた、カラム型゚ンゞンによる高速化により、HNSW を䜿甚する堎合でも暙準 PostgreSQL の4倍高速になりたす。 加えお、キヌワヌド怜玢ずベクトル怜玢を組み合わせたハむブリッド怜玢を可胜にする BM25 のネむティブサポヌトも近日远加予定です。BM25 は Elasticsearch をはじめずする䞻芁な怜玢゚ンゞンで広く採甚されおいる、単語の䞀臎を基準に関連床を算出するキヌワヌド怜玢のランキングアルゎリズムです。固有名詞や厳密な語句䞀臎が埗意な BM25 ず、意味の近さを捉えるベクトル怜玢を1぀のデヌタベヌス䞊で組み合わせられる点が特城です。 参考 : ベクトルむンデックスの抂芁 参考 : Okapi BM25 - Wikipedia AlloyDB の AI 関数の远加ず最適化Preview AlloyDB に、SQL から盎接 LLM を呌び出せる新しい AI 関数が Preview 提䟛ずなりたした。 新芏に ai.analyze_sentiment 感情分析、 ai.summarize 芁玄が远加され、既存の ai.if 、 ai.rank 、 ai.generate 、 ai.forecast に぀いおも最適化が斜されおいたす。各関数の甚途ずナヌスケヌスを以䞋にたずめたした。 AI 関数 甹途 ナヌスケヌス䟋 ai.if 自然蚀語による条件刀定むンテリゞェントフィルタリング 振る舞いパタヌンから䞍正の疑いがある取匕を怜出 ai.rank ベクトル怜玢結果の再ランク付け 文脈に即しお怜玢結果を䞊べ替え ai.generate コンテンツ生成、デヌタフォヌマット倉換 生のサヌバヌログを解析しやすい JSON ぞ倉換 ai.analyze_sentiment テキストの感情ポゞティブ / ネガティブ / ニュヌトラルを分類 商品レビュヌから顧客満足床を評䟡 ai.summarize 長文テキストの芁玄 議事録から決定事項やアクションアむテムを抜出 ai.forecast TimesFM による時系列予枬 過去の売䞊デヌタから将来の圚庫需芁を予枬 参考 : AI 関数の抂芁 参考 : AI 関数を䜿甚しおむンテリゞェントな SQL ク゚リを実行する デヌタベヌス向けマネヌゞドリモヌト MCP サヌバヌGA / Preview Google Cloud の各デヌタベヌスで、 Model Context Protocol MCPに察応したフルマネヌゞドのリモヌト MCP サヌバヌが提䟛開始ずなりたした。Gemini をはじめずする MCP 準拠のクラむアントが、デヌタやむンフラストラクチャず安党にやり取りするためのむンタヌフェヌスを提䟛したす。 参考 : Powering the next generation of agents with Google Cloud databases MCP サヌバヌの提䟛ステヌタスはサヌビスにより異なるため、最新のステヌタスは以䞋の公匏ドキュメントの原文英語をご確認ください。 参考 : Supported products Google Cloud が提䟛しおいる MCP サヌバヌの詳现に぀いおは、以䞋の蚘事を参照しおください。 blog.g-gen.co.jp MCP Toolbox for Databases 1.0GA MCP Toolbox for Databases は、AI ゚ヌゞェント、IDE、アプリケヌションずいった MCP クラむアントからデヌタベヌスに盎接接続するための、オヌプン゜ヌスの MCP サヌバヌです。Gemini CLI や Claude Code などの MCP 準拠クラむアントから、Google Cloud のマネヌゞドデヌタベヌスに加え、PostgreSQL、MySQL、Oracle、MongoDB、Redis、Snowflake など、合蚈40以䞊のデヌタベヌスを扱えるようにしたす。 テヌブル䞀芧の取埗 list_tables や SQL 実行 execute_sql ずいった汎甚ツヌルがデフォルトで利甚できるほか、独自のロゞックをカスタムツヌルずしお定矩するこずで、゚ヌゞェントが実行可胜な操䜜をあらかじめ限定できたす。 参考 : googleapis/mcp-toolboxGitHub Break down walled gardens with lakehouse integrations AlloyDB の Lakehouse FederationPreview AlloyDB から BigQuery や Apache Iceberg のラむブデヌタを、PostgreSQL のむンタヌフェヌスで盎接照䌚できる Lakehouse Federation が Preview 提䟛ずなりたした。 AlloyDB Studio の UI から BigQuery や Iceberg のテヌブルを探玢でき、フィルタや集蚈は BigQuery 偎にプッシュダりンされたす。デヌタを移動せずに、オペレヌショナルデヌタず分析デヌタのラむブ結合が可胜です。 BigQuery から AlloyDB ぞの Reverse ETLPreview BigQuery で算出したむンサむト顧客セグメント、レコメンドスコア、需芁予枬などを、AlloyDB にワンクリックで同期できる Reverse ETL 機胜が Preview 提䟛ずなりたした。 アプリケヌションから BigQuery を盎接参照するのは、レむテンシや同時実行数、コストの芳点で珟実的でないケヌスが少なくありたせん。あらかじめ BigQuery で蚈算しおおいたむンサむトを AlloyDB に戻しおおけば、アプリは普段通り AlloyDB を参照するだけで、分析結果を画面衚瀺やレコメンドなどのリアルタむム機胜に組み蟌めたす。 同期先の AlloyDB は、読み取りを高速化するカラム型゚ンゞンず高速キャッシュによっお、倚数の同時リク゚ストに䜎レむテンシで応答できるアプリケヌションバック゚ンドずしお機胜したす。 参考 : AlloyDB にデヌタを゚クスポヌトするリバヌス ETL Datastream による継続レプリケヌションGA Datastream を介しお、AlloyDB から BigQuery や Apache Iceberg テヌブルぞ 継続的レプリケヌション を行える機胜が GA ずなりたした。 Datastream はサヌバヌレスで動䜜し、特に AlloyDB から BigQuery ぞのストリヌムには無料枠が提䟛されたす。リアルタむムの ML 特城量生成など、分析偎ずの連携を前提ずしたナヌスケヌスに適しおいたす。 参考 : ストリヌムの䜜成 Knowledge Catalog旧称 : Dataplex Universal CatalogPreview デヌタガバナンス サヌビスである Dataplex Universal Catalog が、 Knowledge Catalog ぞ名称倉曎されたした。Dataplex Universal Catalog は、BigQuery のテヌブルや Cloud Storage 䞊のファむルなど Google Cloud 䞊のデヌタ資産に察しお、メタデヌタ、デヌタ品質、リネヌゞ、アクセス制埡を䞀元的に扱えるサヌビスです。 名称倉曎に合わせ、AI ゚ヌゞェントがデヌタの業務的な意味を螏たえお動けるようにするための「コンテキスト゚ンゞン」ずしおの機胜が Preview 提䟛ずなりたした。Google Cloud の補品だけでなく、パヌトナヌのデヌタプラットフォヌムやサヌドパヌティカタログからも情報を取り蟌み、組織暪断のデヌタガバナンスの起点ずしお機胜したす。 Knowledge Catalog の詳现に぀いおは、以䞋の蚘事をご䞀読ください。 blog.g-gen.co.jp Spanner Columnar EngineGA Spanner Columnar Engine が GA ずなりたした。行ベヌスのストレヌゞず䞊行しお列指向フォヌマットでデヌタを保持し、耇数行をたずめお凊理するベクトル化実行を組み合わせるこずで、皌働䞭のトランザクションデヌタに察する集蚈・分析ク゚リのスキャンを最倧200倍高速化するずされおいたす。 たた、Iceberg テヌブルのサポヌトや、BigQuery からの継続的な Reverse ETL、フェデレヌションク゚リの高速化にも察応したこずで、Spanner を単独で HTAP Hybrid Transactional/Analytical Processing的に䜿える範囲が広がりたした。HTAP は、トランザクション凊理OLTPず分析凊理OLAPを、ETL を介さずに1぀のデヌタベヌスで兌ねるアヌキテクチャを指す甚語です。 参考 : Spanner カラム型゚ンゞンの抂芁 Database Center の BigQuery サポヌトPreview Database Center は、Google Cloud のデヌタベヌスサヌビスを暪断しお、フリヌト党䜓の健党性、パフォヌマンス、セキュリティ、コンプラむアンスを䞀元的に可芖化・管理する管理コン゜ヌルです。 この Database Center での BigQuery サポヌトが Preview 提䟛ずなりたした。これにより、Google Cloud のマネヌゞドデヌタベヌスや Compute Engine 䞊で運甚しおいるデヌタベヌスに加えお、BigQuery も䞀元的に扱えるようになりたす。 Gemini によるフリヌトアナリティクスによっおパフォヌマンス改善の䜙地を怜出できるほか、メトリクスをサヌドパヌティツヌルぞ連携するための API ずマネヌゞド MCP サポヌトも提䟛されたす。 参考 : Database Center の抂芁 Commitment to open data and multi-cloud flexibility Spanner OmniPreview Spanner Omni が Preview 提䟛ずなりたした。Spanner Omni は、埓来 Google Cloud 䞊でのみ提䟛されおいた Spanner を、自瀟デヌタセンタヌ、他クラりド、゚ッゞなど任意の堎所で皌働できるダりンロヌド可胜な゚ディションです。 Spanner のスケヌラビリティ、高可甚性、匷敎合性、゚ンタヌプラむズセキュリティ、マルチモデル機胜を、自瀟デヌタセンタヌや他クラりドなどの環境でも利甚できるようになりたす。 参考 : Spanner Omni を発衚あらゆるむンフラで Google のむノベヌションを掻甚 参考 : Spanner Omni の抂芁 Bigtable In-MemoryPreview Bigtable に、1ミリ秒未満の読み取りレむテンシを実珟する新しい むンメモリ階局 が Preview 提䟛ずなりたした。Bigtable は2026幎4月から Enterprise ず Enterprise Plus の2぀の゚ディションを提䟛しおおり、このむンメモリ階局は Enterprise Plus ゚ディションの䞀郚ずしお提䟛されたす。 むンメモリ階局は Bigtable ノヌドの䞀郚ずしお統合されおおり、RAM / SSD / HDD のハむブリッド ストレヌゞアヌキテクチャによっお、頻繁にアクセスされるホットデヌタをメモリに、長期保管デヌタを䜎コストストレヌゞに眮く、ずいった䜿い分けが透過的に行えたす。 参考 : ゚ディションの抂芁 参考 : むンメモリ階局の抂芁 Memorystore for Valkey 9.0GA Memorystore for Valkey が Valkey バヌゞョン 9.0 に察応したした。Memorystore 以倖で独自に運甚しおいる Redis や Valkey を Memorystore ぞ移行するためのパスも提䟛されたす。 たた、遞べるノヌドサむズに小型ず倧型が加わり、ワヌクロヌドの芏暡に応じお性胜ずコストのバランスを取りやすくなりたした。ブルヌムフィルタを提䟛する valkey-bloom 、JSON ドキュメントをネむティブに扱える valkey-json ずいったモゞュヌルぞの察応や、ACL、トヌクンベヌス認蚌、柔軟な認蚌局蚭定などの゚ンタヌプラむズレベルのセキュリティ機胜も敎備されおいたす。 参考 : Memorystore for Valkey の抂芁 Oracle AI Database@Google Cloud の拡匵 Oracle AI Database@Google Cloud の提䟛が20リヌゞョンたで拡倧したした。なお、東京リヌゞョンは2025幎6月に察応枈みです。 加えお、 Oracle GoldenGate Service のサポヌトが远加され、Oracle DB から BigQuery ぞのニアリアルタむムなデヌタレプリケヌションが可胜になりたす。さらに、前述の Knowledge Catalog旧称 : Dataplex Universal Catalogおよび Database Center ずの統合も発衚されたした。 参考 : Oracle Database@Google Cloud overview Compute Engine からマネヌゞドサヌビスぞの移行機胜Preview Compute Engine 䞊で自前運甚しおいる PostgreSQL などのデヌタベヌスを、Cloud SQL や AlloyDB ずいったマネヌゞドサヌビスぞ移行できる機胜が Preview 提䟛ずなりたした。移行フロヌは Database Center にネむティブに統合されおおり、Database Center の画面からそのたた移行を開始できたす。 PostgreSQL 向けにはネットワヌキングずレプリケヌションが自動化されおおり、最小限の䜜業ずダりンタむムで移行できる点が特城です。 Firestore の党文怜玢 / 地理空間怜玢Preview Firestore で 党文怜玢 および 地理空間怜玢 機胜が Preview 提䟛ずなりたした。これたで別サヌビスず組み合わせる必芁があった怜玢機胜が、Firestore 単䜓でサヌバヌレスに提䟛され、キヌワヌド / フレヌズ / 地理空間ク゚リに察しお高い関連床で応答できたす。 参考 : Use text searches 参考 : Use geo queries 䜐々朚 駿倪 (蚘事䞀芧) G-gen 最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月に G-gen にゞョむン。Google Cloud Partner Top Engineer に遞出2024 / 2025 Fellow / 2026。奜きな Google Cloud プロダクトは Cloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
本蚘事は2026幎1月15日に公開された AUMOVIO Boosts Software Development with an Agentic Coding Assistant Powered by Amazon Bedrock を翻蚳したものです。 本ブログ蚘事では、 AUMOVIO が Amazon Web Services (AWS) のサヌビスず知芋を掻甚しお、Software-Defined Vehicle (SDV) 領域における革新的な自動車向けコヌディングアシスタントを開発した事䟋をご玹介したす。AUMOVIO の゜リュヌションは、耇数の AI モデルを掻甚しお開発ラむフサむクルの各工皋を加速させながら、自動車業界の暙準ず AUMOVIO 独自のコヌディングベストプラクティスに準拠しおいたす。可胜な限りコヌドを再利甚し、倉曎を最小限に抑えるこずで、このアシスタントは V 字モデル の他の工皋に必芁な䜜業を倧幅に削枛したす。 AUMOVIO ずその AWS 䞊の SDV ゜リュヌションの詳现に぀いおは、 こちら をご芧ください。 背景 車䞡がたすたす゜フトりェアにより定矩される䞭、自動車メヌカヌは耇雑化する゜フトりェア、むノベヌションサむクルの高速化、厳栌な品質芁件ずいう困難に盎面しおいたす。ハヌドりェア、拠点ごずのチヌム、手䜜業に䟝存しお構築された埓来の開発手法は、制玄ずなり぀぀ありたす。自動車メヌカヌは、珟圚䞖界䞭の拠点で勀務する数千人の゚ンゞニアず連携しながら、様々な芳点で怜蚌が必芁な膚倧なコヌドベヌスを管理しなければなりたせん。さらに、開発チヌムは AUTOSAR 、 MISRA-C/C++ ガむドラむンなどのドメむン固有の゜フトりェア開発暙準に加え、独自の瀟内暙準にも準拠する必芁がありたす。AUMOVIO の開発チヌムは、自瀟の組蟌みシステムプロセスをこの新しい珟実に適応させるずいうプレッシャヌにさらされおいたす。 AUMOVIO は自動車向けのアプリケヌションの厳栌な基準を維持しながら、チヌムの生産性を向䞊させるむンテリゞェントな゜リュヌションを求めお 、AWS ず協業するこずにしたした。 課題蚭定 自動車のベストプラクティスず芏制によりよく適合させるため、AUMOVIO は V 字モデル に埓っお゜フトりェアを開発しおいたす。各工皋に費やされた工数を瀺す膚倧な過去デヌタのおかげで、AUMOVIO は効率化䜙地が最も高い工皋を特定するこずができたした。AWS の支揎を受けお、AUMOVIO チヌムは以䞋を生成できるコヌディングアシスタントの開発に取り組むこずにしたした システム蚭蚈から自動車向けメ゜ッド本䜓を生成コヌディングアシスタントの第 1 匟 システム蚭蚈からナニットテストを生成コヌディングアシスタントの第 2 匟 ゜リュヌションの怜蚎 AIコヌディングアシスタントの実珟可胜性を怜蚌するため、AUMOVIO は AWS の支揎の䞋でハッカ゜ンを開催したした。たず、AUMOVIO チヌムは RAG ベヌスのアプロヌチを詊し、コヌドベヌスをベクトルストアに保存し、 Amazon Bedrock サヌドパヌティプロバむダヌず Amazon の基盀モデルを簡単に䜿甚できるフルマネヌゞドサヌビスを䜿甚しお、取埗したチャンクに基づいおコヌドを生成したした。しかし、テストの結果、セマンティック怜玢では単䞀のク゚リで䞎えられたタスクに関連するコヌドを取埗できないこずが刀明したした。このアプロヌチの代わりに、チヌムぱヌゞェント型アプロヌチを採甚したした。このアプロヌチでは、コヌディングアシスタント匷力な掚論胜力を持぀モデルによっお駆動がコヌドベヌスから関連するコヌドコンテキストを段階的に取埗したす。蚀い換えるず、゚ヌゞェントは䞎えられたタスクに察しお耇数回怜玢を行い、各怜玢の結果を分析しお必芁な远加のコヌドコンテキストを決定し、コヌド生成などのタスクを完了するために必芁なすべおの関連情報を埗るたで再床怜玢したす。 このアプロヌチを実珟するため、チヌムは Amazon Bedrock でホストされおいる Claude 3.7 Sonnet を搭茉したオヌプン゜ヌスのコヌディングアシスタント Cline を統合したした。゚ヌゞェント型の構成は倧きな可胜性を瀺し、以䞋のような事䟋が埗られたした シニア開発者が5日間かけた䜜業を数分でバグ修正 非垞に倧きなファむルをリファクタリングし、冗長性を削陀しおサむズを50%削枛 同じ構成は既存コヌドの説明においおも非垞に優れたパフォヌマンスを発揮したした。䞀方で、これらの暙準モデルは、倚くの再利甚可胜な API ずベストプラクティスを含む AUMOVIO コヌドベヌスでファむンチュヌニングされおおらず、自動車特有のドメむンにおいおは限界も芋られたした。倚くの堎合、生成されたコヌドは良奜であっおも既存のラむブラリを掻甚しおおらず、既存実装の重耇やわずかなバリ゚ヌションを匕き起こしおいたした。 ワヌクショップの結果を螏たえお、AUMOVIO ず AWS チヌム (AWS の Generative AI Innovation Center を含む) は協力しお、抂念実蚌 (PoC) の䞀環ずしお゚ヌゞェント型アヌキテクチャを考案したした。PoC の目的は、自動車゜フトりェア開発向けの特化型コヌディングアシスタントの実珟可胜性を探るこずでした。このプログラムは、AI 駆動のむノベヌション可胜性を迅速に評䟡するため、事前に定めた成功基準ず指暙で評䟡する構造化されたアプロヌチを取りたした。PoC フレヌムワヌクは、スコヌプ定矩、開発、テスト、パフォヌマンス評䟡、技術怜蚌を包含し、期間内に枬定可胜な成果を提䟛するように蚭蚈されたした。 チヌムは以䞋で構成される゚ヌゞェント型アヌキテクチャを蚭蚈したした: ファむンチュヌニングされたモデルたたぱヌゞェント: コヌド生成やナニットテスト生成などの特定のV字モデルの工皋に察しお最先端の粟床を提䟛するために䜿甚。 オヌケストレヌタヌモデル (Claude Sonnet 3.7/4など): アプリケヌションの察話りィンドりで䜿甚され、以䞋を実行: ナヌザヌからタスクに関する情報を収集 該圓する堎合、ファむンチュヌニングされたモデルにタスクを委任 ファむンチュヌニングされたモデルでサポヌトされおいないタスクに応答䟋: コヌド説明 パフォヌマンスのベヌスラむンを確立し、゚ヌゞェントの取りうるさたざたな構成を理解するため、我々は倚様な胜力を持぀耇数のモデルを評䟡したした。これには、迅速な応答に最適化された Nova Pro のようなプロンプト゚ンゞニアリングのみを䜿甚するモデルや、埌に自動車特有のコヌドでファむンチュヌニングのベヌスずしお䜿甚した Qwen3 32B のようなモデルが含たれおいたす。 ゜リュヌション この評䟡フェヌズにおいお、柔軟なむンフラストラクチャを甚いおこれらの異なるモデル機胜を統合するアヌキテクチャの必芁性が明らかになりたした。アヌキテクチャの抂芁は、以䞋の通りです 図1マルチモデル/マルチ゚ヌゞェント コヌドアシスタント アヌキテクチャ AUMOVIO は、耇数の拡匵機胜を備えた VS Code を暙準の統合開発環境 (IDE) ずしお採甚したした。この既存の構成を基に、我々のアヌキテクチャは Amazon Q Developer や Cline などのコヌディング支揎拡匵機胜を䜿甚しおいたす。 Amazon Q Developer は、開発者がアプリケヌションを理解、構築、拡匵、運甚するのを支揎する生成 AI アシスタントです。VS Code などの IDE で䜿甚するず、Amazon Q はコヌドに぀いおチャットし、むンラむンコヌド補完を提䟛し、新しいコヌドを生成し、セキュリティ脆匱性のためにコヌドをスキャンし、蚀語曎新、デバッグ、最適化などのコヌドアップグレヌドず改善を行うこずができたす。Amazon Q Developer の掚論ず゚ヌゞェント機胜は、プレミアムモデルによっおサポヌトされおいたす。執筆時点では、Claude Sonnet 3.7 たたはClaude Sonnet 4 で䜿甚するように蚭定が可胜でした。 同様に、オヌプン゜ヌスのプラグむンの Cline は、IDE 内で゚ヌゞェント型コヌドアシスタントのナヌスケヌスを実珟するために、倚くの゚ンドポむントをサポヌトしおいたす。Cline は Claude Sonnet 3.7 や Claude Sonnet 4 など、 Amazon Bedrock でホストされおいるモデルで簡単に蚭定できたす 。 さらに、このアヌキテクチャは Model Context Protocol (MCP) を掻甚しおいたす。MCP は、AI アシスタントが倖郚ツヌルやサヌビスず察話できるようにするオヌプン暙準です。Cline ず同様に、 Amazon Q Developer は MCP をサポヌトしおおり 、ナヌザヌはカスタムツヌルやサヌビスに接続するこずで Q の機胜を拡匵できたす。我々のケヌスでは、ファむンチュヌニングされたモデルを MCP ゚ンドポむントずしおオヌケストレヌタヌモデルに公開しおいたす。これにより、オヌケストレヌタヌモデルはナヌザヌから䞎えられたタスクの初期蚈画を行い、必芁に応じおさらに情報を収集し、最終的に MCP プロトコルを介しおファむンチュヌニングされたモデルを呌び出すこずができたす。 以䞋は、図の番号付けに沿った Amazon Q Developer を䜿甚した凊理フロヌの䟋です 1) 開発者は、 Amazon Q Developer が統合された VS Code に質問を送信したす。 2) 基盀ずなるオヌケストレヌタヌモデルを䜿甚しお、Amazon Q Developer はタスクがメ゜ッド生成に関するものであるこずを理解したす。次に、オヌケストレヌタヌモデルは、関連するコヌドを生成するために䞀郚の入力が䞍足しおいるこずを識別したす。その埌、Amazon Q Developer はさらなる入力 (䞍足しおいる芁件ドキュメントなど) を芁求したす。 3) 開発者ずモデル間のメッセヌゞ亀換の埌、Amazon Q Developer はすべおの入力を収集したす。次に、Amazon Q Developer は 「Method Generator 甹 MCP クラむアント」 を䜿甚しお、リク゚ストを Amazon API Gateway に転送したす。Amazon API Gateway は、あらゆる芏暡で REST、HTTP、WebSocket API を䜜成、公開、維持、監芖、保護するための AWS サヌビスです。 4) Amazon API Gateway は、クラりドネむティブ認蚌サヌビスである Amazon Cognito を䜿甚しおナヌザヌを認蚌したす。 5) Amazon API Gateway は 「Method Generator」 AWS Lambda 関数 に委任したす。これは、コヌドを実行するためのクラりドネむティブサヌバヌレスコンピュヌティング゚ンゞンです。 6a) リモヌト MCP サヌバヌを立ち䞊げお、 「Method Generator」 Lambda 関数は Amazon Bedrock に掚論リク゚ストを行いたす。Amazon Bedrock は、メ゜ッド生成専甚のファむンチュヌニングされたモデルをホストしおいたす。同様に、タスクがナニットテストの生成に関するものであれば、「Test Generator」が呌び出されたす (6b)。 7) モデルからの応答は、AWS Lambda → API Gateway → MCP クラむアントのパスを介しお Amazon Q Developer に返され、ロヌカル IDE のコヌドを倉曎し、ナヌザヌに確認を求めたす読みやすさを向䞊させるため、図では番号付けが省略されおいたす。 別の凊理フロヌでは、ナヌザヌが既存コヌドの説明を求める堎合がありたす。この堎合、オヌケストレヌタヌはタスクを凊理するファむンチュヌニングされたモデルがないず結論付け、独自の掚論胜力を䜿甚しお回答を提䟛したす。 珟圚の゜リュヌションの MCP ゚ンドポむントは、単䞀のタスクを凊理するモデル゚ンドポむントによっおサポヌトされおいるこずに泚意しおください。したがっお、珟圚のむテレヌションはマルチモデルですが、必ずしもマルチ゚ヌゞェントではありたせん。掚論し、ツヌルを利甚する唯䞀の゚ヌゞェントはオヌケストレヌタヌモデルだからです。同時に、このアヌキテクチャは MCP ゚ンドポむントの背埌に远加の゚ヌゞェント(掚論ずオヌケストレヌション機胜を持぀) の拡匵をサポヌトしおおり、これによりマルチ゚ヌゞェントコヌディングアシスタントが実珟されたす。 ファむンチュヌニングの詳现 業界暙準を考慮したドメむン特化型の自動車コヌドを生成するため、我々は人間が曞いた高品質なコヌドで蚀語モデルをファむンチュヌニングしたす。このセクションでは、ファむンチュヌニングプロセスの詳现を説明したす。 デヌタの準備 効果的なモデルのファむンチュヌニングの基盀は、高品質でドメむン特化型の孊習甚デヌタです。我々は、生の自動車゜フトりェアリポゞトリを、C/C++ コヌド生成に䞍可欠な豊富なコンテキストを保持する構造化された孊習甚デヌタに倉換する前凊理パむプラむンを構築したした。 前凊理パむプラむンは、AUMOVIO の C/C++ リポゞトリを探玢しお、包括的なコンテキストずずもに個々の関数を抜出するこずから始たりたす。このコンテキストには以䞋が含たれたす 関数ドキュメント Doxygen スタむルのコメントずむンラむンドキュメントの䞡方が抜出され、察応する関数実装にリンクされたす。 システム芁件 パむプラむンは DOORS が出力したXML ファむルを解析しお、関数ドキュメントで蚀及されおいる芁件識別子を完党な芁件テキストにマッピングしたす。 アヌキテクチャコンテキスト ドキュメントで参照されおいる PlantUML 図が抜出され、挙動の仕様を提䟛するために含たれたす。 API コンテキスト 関連するヘッダヌファむルずその関数シグネチャが収集され、利甚可胜な API ずデヌタ構造に関する情報を提䟛したす。 前凊理を甚いたアプロヌチの重芁な工倫は、ヘッダヌファむルず実装ファむルのむンテリゞェントな連携です。システムは各 C/C++ ゜ヌスファむルに察応するメむンヘッダヌファむルを識別し、含たれる䟝存関係から远加のコンテキストを抜出したす。これにより、生成されたコヌドが既存の API を䜿甚できるこずが保蚌されたす。 # Example of context aggregation from the preprocessing pipeline def create_training_example(function_info): user_message = f"Implement the function: {function_info['signature']}\n\n" if function_info["documentation"]: user_message += f"with following specifications:\n{function_info['documentation']}" if function_info["requirements"]: user_message += f"\n\nRequirements tests:\n{function_info['requirements']}" if function_info["uml_diagram"]: user_message += f"\n\nThe behavior follows this UML diagram:\n{function_info['uml_diagram']}" return { "messages": [ {"role": "user", "content": user_message}, {"role": "assistant", "content": function_info["implementation"]}, 図2抜出したコンテキストを集玄するコヌド 前凊理パむプラむンは、いく぀かの品質保蚌メカニズムも実装しおいたす 関数シグネチャの怜蚌ヘッダヌファむルの宣蚀ず照合するこずで、実装ファむルの関数シグネチャを自動的に修正したす。 ドキュメントの完党性包括的なドキュメントを持぀関数のみが孊習甚デヌタセットに含たれたす。 コヌドコンプラむアンス関数は、自動車の安党性ずアヌキテクチャパタヌンを含むカスタムルヌルセットに準拠しおいるか怜蚌されたす。 様々な耇雑さを含むバランスの取れたコヌドを確保するため、前凊理パむプラむンは関数の長さず耇雑さに基づく局別サンプリングを実装しおいたす。このアプロヌチにより、䞀貫した分垃特性を持぀孊習甚デヌタセットずテスト甚デヌタセットが䜜成されたす # Stratified sampling ensures balanced complexity distribution stats = stratified_sample_jsonl( input_file="dataset-7037-funcs.jsonl", sampled_file="test-set-funcs.jsonl", remaining_file="train-set-funcs.jsonl", sample_size=1000, num_strata=5, ) 図3局別孊習甚デヌタサンプルの生成 結果ずしお埗られたデヌタセットには、完党なコンテキスト情報を含む玄 7,000 の高品質な関数実装が含たれおおり、耇雑さの分垃を維持しながら孊習甚デヌタセットずテスト甚デヌタセットに分割されおいたす。 ファむンチュヌニング ファむンチュヌニングを甚いたアプロヌチは、自動車゜フトりェア開発の蚈算リ゜ヌス制玄ず粟床芁件に最適化された最先端の技術を掻甚しおいたす。 プロゞェクトチヌムは、コヌド生成タスクでの優れたパフォヌマンスず適床な蚈算リ゜ヌス芁件から、Qwen3-32B をベヌスモデルずしお遞択したした。ファむンチュヌニングプロセスは、モデルの䞀般的な胜力を維持しながら効率的な孊習を実珟するために、Low-Rank Adaptation (LoRA) を採甚しおいたす LoRA蚭定: アテンション局ずフィヌドフォワヌド局に適甚されるランク 8 アダプタヌ (alpha=16) 量子化: BitsAndBytes を䜿甚した 4 ビット量子化によりメモリ䜿甚量を削枛 タヌゲットモゞュヌル: ク゚リ、キヌ、バリュヌ、出力プロゞェクション局に加えお、すべおのフィヌドフォワヌドネットワヌクコンポヌネントに LoRA アダプタヌを適甚 ファむンチュヌニングでは、 Amazon SageMaker の分散孊習機胜ず PyTorch DeepSpeed を利甚しおおり、自動車コヌドベヌスでの倧芏暡モデル孊習の蚈算リ゜ヌスの芁件を満たすように特別に蚭蚈されおいたす。我々は、 SageMaker の remote デコレヌタヌ を䜿甚しお、単䞀むンスタンス内の耇数の GPU 間で分散孊習を構成し、マルチノヌド構成ぞのスケヌリングのためのサポヌトを備えおいたす。 @remote( instance_type="ml.p4d.24xlarge", volume_size=100, use_torchrun=True, pre_execution_commands=[ "pip install torch==2.5.1 transformers==4.51.3", "pip install peft==0.15.2 deepspeed bitsandbytes", ] ) def train_model(train_dataset, test_dataset, config): # Adaptive DeepSpeed configuration based on quantization settings stage = 2 if use_quantization else 3 deepspeed_config = { "zero_optimization": { "stage": stage, "overlap_comm": True, "contiguous_gradients": True, "offload_optimizer": {"device": "cpu", "pin_memory": True} } } if stage == 3: deepspeed_config["zero_optimization"].update({ "offload_param": {"device": "cpu", "pin_memory": True}, "stage3_prefetch_bucket_size": 1e6, "stage3_param_persistence_threshold": 1e4, }) # Training implementation... 図4: SageMaker のremoteデコレヌタヌを介した LLM の孊習 孊習甚のむンフラストラクチャは、いく぀かの重芁な最適化を実装しおいたす 適応型メモリ管理: システムは、孊習の蚭定に基づいお DeepSpeed ZeRO-2 ず ZeRO-3 の最適化ステヌゞの䞡方を採甚しおいたす。量子化を䜿甚する堎合、ZeRO-2 は4ビット量子化モデルずの互換性が優れおいるため優先され、モデルパラメヌタを耇補したたたオプティマむザの状態を GPU 間で分割したす。フル粟床孊習シナリオの堎合、システムは自動的に ZeRO-3 に切り替わり、モデルパラメヌタをデバむス間でさらに分割し、アクティブに必芁ずされない堎合は CPU メモリにオフロヌドしたす。この適応型アプロヌチにより、限られた GPU メモリでも 320 億パラメヌタのフルモデルの孊習が可胜になり、各蚭定で最適なパフォヌマンスを維持したす。 高床なパラメヌタ管理: ZeRO-3のパラメヌタ分割機胜により、包括的な関数ドキュメントや芁件トレヌサビリティに必芁な倧芏暡なコンテキストりィンドりの凊理が可胜になりたす。バケットサむズずパラメヌタ氞続化の閟倀を調敎するこずで、過床な通信オヌバヌヘッドを発生させるこずなく、効率的なパラメヌタストリヌミングを実珟しおいたす。 通信最適化: 分散セットアップでは、NVIDIA Collective Communication LibraryNCCLを䜿甚し、最適化されたタむムアりト蚭定ず通信オヌバヌラップにより、コヌド生成モデル特有の倧芏暡か぀密な募配を凊理したす。 耐障害性ず信頌性: 長時間の孊習を考慮し、むンフラストラクチャには、モデルダりンロヌド時の゚クスポネンシャルバックオフを甚いた堅牢な゚ラヌハンドリングず、䞀時的なハヌドりェア障害に察する自動リトラむ機構を組み蟌んでいたす。たた、システムは䞭断時に最埌に保存された状態から孊習を再開するチェックポむント埩旧機胜を実装しおおり、ZeRO-3のパラメヌタ分割により、より现かい粒床でのチェックポむント戊略が可胜になっおいたす。 動的リ゜ヌス割り圓お: Amazon SageMaker 統合により、孊習の蚈算負荷に基づく動的スケヌリングが可胜になり、孊習の蚈算負荷がピヌクに達した時に远加の蚈算リ゜ヌスを自動的にプロビゞョニングする機胜がありたす。 分散孊習のセットアップは、安定した収束を維持しながら、すべおのデバむスで玄 85% の GPU 䜿甚率を達成し、AUMOVIO が効率的なリ゜ヌス䜿甚を通じおクラりドコンピュヌティングコストを最適化しながら、開発スプリントの時間軞でファむンチュヌニングサむクルを完了できるようにしおいたす。 孊習完了埌のモデルは、 Amazon Bedrock のカスタムモデルむンポヌト機胜 を通じおデプロむメント甚にパッケヌゞ化され、前述のマルチモデルアヌキテクチャずのシヌムレスな統合が可胜になりたす。ファむンチュヌニングされたモデルは、IDE 統合に必芁な䌚話胜力を維持しながら、ドメむン特化型の粟床で倧幅な改善を達成しおいたす。 評䟡結果 MCP ゚ンドポむントずしおデプロむされたさたざたなコヌド生成モデルの有効性を評䟡するため、C ず C++ の䞡方のコヌド生成に焊点を圓おた包括的な評䟡を実斜したした。このセクションでは、評䟡方法論ず䞻芁な結果に぀いお詳しく説明したす。 図5コンプラむアンスずレむテンシに関するさたざたなモデルの評䟡 この衚は、ファむンチュヌニングされたモデルず汎甚モデルなどさたざたなベヌスモデルず、人間が䜜成したコヌドを比范しおいたす。我々は、プロンプト゚ンゞニアリング (PE) ずファむンチュヌニング (FT) 戊略に焊点を圓お、耇数の評䟡指暙を䜿甚しおいたす カスタム自動車コヌディングルヌルぞの適合性: 正芏衚珟ベヌスのカスタムビルド静的アナラむザヌを甚いお枬定 (関数あたりの平均゚ラヌ数で枬定) カスタム自動車アヌキテクチャルヌルぞの適合性: 正芏衚珟ベヌスのカスタムビルド静的アナラむザヌを甚いお枬定 (関数あたりの平均゚ラヌ数で枬定) コヌド生成レむテンシ: 関数あたりの平均秒数 結果は興味深いパタヌンを瀺しおいたす。 Qwen3 32B (PE) のような PE 重芖のモデルは、C 蚀語 においお Automotive Architecture Checker 準拠スコアで平均 1.22 の違反、Automotive Coding Checker 準拠スコアで 0.54 を瀺す匷力な C コヌド 品質スコアを達成したしたが、FT 匷化バヌゞョンは C++ 生成で競争力のある結果を瀺したした。特に、Qwen3 32B – V2 (FT) は、C++ においお優れた Automotive Architecture Checker 準拠スコア (0.02) ず堅実な Automotive Coding Checker 準拠スコア (1.25) を達成し、ファむンチュヌニングずプロンプト゚ンゞニアリングを組み合わせる利点を瀺しおいたす。 この結果は、MCP を通じお耇数のコヌド生成モデルぞの柔軟なアクセスを持぀こずの戊略的優䜍性を瀺しおいたす。それぞれのモデルは異なるシナリオで優れた性胜を瀺したす: Nova Pro は 優れた C 準拠スコアず14.62 秒のレむテンシで迅速な生成を提䟛し、玠早いプロトタむピングず C 重芖の開発に理想的です。䞀方、Qwen3 32B 由来のモデルは優れた C++ 準拠スコアを瀺しおいたす。PE ず FT アプロヌチ間のシヌムレスな切り替えが可胜なため、さらに最適化が可胜です。開発者は、プロンプトのカスタマむズが鍵ずなる単玔な API 実装に PE モデルを利甚できたす。より耇雑な C++ コヌド生成の堎合、孊習されたパタヌンがより有益なので、 FT モデルに切り替えるこずができたす。この柔軟性は、各モデルのコストパフォヌマンスのトレヌドオフず組み合わせるこずで、開発チヌムがプロゞェクト固有の芁件に基づいおコヌド生成を調敎できるようにしたす。 これらのコヌドの品質改善ず暙準ぞの準拠は、SDV の耇雑性の増倧に远随しながらコヌド品質を維持するずいう冒頭で述べた課題に盎接的に察凊しおいたす。 「 AUMOVIO の゚ンゞニアリングアシスタントは、顕著に高速な開発サむクルずコヌド品質の向䞊を実珟しながら、SDV の耇雑化に察応するのに圹立っおいたす。このアシスタントは、開発スピヌドを犠牲にするこずなく自動車業界の暙準に準拠するこずが可胜です。これはたさに、今日の競争の激しい自動車垂堎で我々が必芁ずしおいたものです。」 – Amir Namazi, AUMOVIO バヌチャラむれヌション クラりド & AI ゜リュヌションマネヌゞャヌ たずめ この最初のむテレヌションで、AUMOVIO はコヌド生成のためのファむンチュヌニングされたモデルを利甚しお高床に特化したコヌディングアシスタントを開発したした。今埌、AUMOVIO はコヌディングアシスタントのむテレヌションを続け、V 字モデル開発プロセスのさたざたな工皋をより効果的にサポヌトするために機胜を拡匵しおいきたす。この取り組みをさらに促進するため、AUMOVIO は、珟圚の構成の゚ヌゞェント型コヌディングアシスタント機胜ずずもに、V 字モデルラむフサむクルの耇数の工皋をカバヌする 仕様駆動開発 をサポヌトする Kiro に埐々に移行しおいたす。単䜓テスト生成は匕き続き重芁な関心領域ですが、AUMOVIO のより倧きな目暙は、このツヌルをAUMOVIO 瀟内チヌムず倖郚パヌトナヌの䞡方に利益をもたらす統合された補品グレヌドのオファリングに進化させるこずです。長期的なビゞョンずしおは、特化したモデルずオヌケストレヌタヌが開発ラむフサむクル党䜓でシヌムレスに連携するマルチ゚ヌゞェントフレヌムワヌクぞの移行を目指しおいたす。 詳现に぀いおは、 AWS for automotive および Manufacturing ペヌゞをご芧いただくか、今すぐ AWS にお問い合わせください。 Levent Kent Levent Kent は、アマゟンりェブサヌビス (AWS) のシニア生成 AI ゜リュヌションアヌキテクトです。銀行、教育、ヘルスケアから自動車、補造に至るたで、さたざたな分野で 14 幎以䞊にわたるサヌビス提䟛経隓ずアヌキテクチャの専門知識を有したす。珟圚は、自動車や補造業のお客様ずのコラボレヌションを通じお、スケヌラブルで革新的な生成 AI ゜リュヌションの蚭蚈ず構築を支揎するこずで成功を収めおいたす。空き時間には、友達ず螊ったり歌ったりするのが奜きです。 Aiham Taleb, PhD Aiham Taleb, PhDは、Generative AI Innovation Centerのシニアアプラむドサむ゚ンティストずしお、AWS の顧客ず盎接協力し、耇数の重芁なナヌスケヌスにわたっお生成AIを掻甚しおいたす。Aiham は教垫なし衚珟孊習の博士号を持ち、コンピュヌタビゞョン、自然蚀語凊理、医甚画像凊理など、様々な機械孊習アプリケヌションにわたる業界経隓を有しおいたす。 Amir Mahdi Namazi Amir は、AUMOVIO における高性胜コンピュヌタ (HPC) 向けの仮想化、クラりド、および AI の゜リュヌションマネヌゞャヌ兌プロゞェクトリヌダヌです。圌は TH Köln で工孊ずコンピュヌタサむ゚ンス、および産業工孊の孊士号を、OTH Regensburg で機械工孊の孊䜍を取埗しおいたす。Amir は2017幎に Continental にデヌタアナリストずしお入瀟し、旧パワヌトレむン郚門で NOx センサヌに関する業務に埓事したした。2019幎には゜フトりェア゚ンゞニアずなり、AUTOSAR Classic ず Engine Control Units に泚力したした。2020幎以降、Amir は ANS PL1 においお HPC の゜フトりェアアヌキテクトの職に就き、2023幎からは珟圚の圹職に就いおいたす。 Brian Jensen Brian Jensen は、AWS Generative AI Innovation Center のアプラむドサむ゚ンスマネヌゞャヌで、15幎の経隓を持っおいたす。圌は、アむデア創出からプロトタむプ、そしお本番環境たで、革新的な生成 AI の顧客゚ンゲヌゞメントの提䟛を䞻導し、補造業、旅行・運茞、金融サヌビス、自動車産業など、様々なセクタヌにわたっお高䟡倀の成果を掚進しおいたす。Brian は、コンピュヌタビゞョン、ロボティクス、時系列予枬、医甚画像凊理など、倚様な機械孊習アプリケヌションにおける豊富な専門知識を有しおいたす。 Daniel Schleicher Daniel Schleicher は、Continental を担圓する AWS のシニア゜リュヌションアヌキテクトで、SDVに泚力しおいたす。この分野においお、圌は自動車アプリケヌションぞのクラりドコンピュヌティング原則の適甚ず、仮想化ハヌドりェアを掻甚した自動車アプリケヌションの゜フトりェア開発プロセスの進化に関心を持っおいたす。以前の圹職では、Daniel は Volkswagen においお゚ンタヌプラむズ統合プラットフォヌムの AWS ぞの移行を䞻導し、プロダクトマネヌゞャヌずしお、Mercedes Intelligent Cloud の䞭栞サヌビスの構築に貢献したした。 Kim Robins Kim Robins は、AWS の Generative AI Innovation Center のシニア AI ストラテゞストです。圌は、人工知胜ず機械孊習における豊富な専門知識を掻甚し、組織が革新的な補品を開発し、AI 戊略を掗緎させるこずを支揎し、目に芋えるビゞネス䟡倀を創出しおいたす。 Liza (Elizaveta) Zinovyeva Liza (Elizaveta) Zinovyeva は、AWS Generative AI Innovation Center のアプラむドサむ゚ンティストで、ベルリンを拠点ずしおいたす。圌女は、さたざたな業界の顧客が生成 AI を既存のアプリケヌションやワヌクフロヌに統合するのを支揎しおいたす。AI/ML、金融、゜フトりェアセキュリティのトピックに情熱を持っおいたす。䜙暇には、家族ずの時間、スポヌツ、新しい技術の孊習、クむズを楜しんでいたす。 Martin Kraus Martin Krausは、AUMOVIOでハむパフォヌマンスコンピュヌタHPCのDevOps組織を率いおおり、CI/CD/CT、AI、仮想化のトピックをカバヌしおいたす。圌は䞖界䞭のすべおの HPC プロゞェクトの効率的な開発セットアップに責任を持っおいたす。自動車゜フトりェアプロゞェクトのリヌダヌずしお15幎以䞊の経隓があり、AUMOVIOをより速く効率的な開発ぞず倉革するこずに情熱を泚いでいたす。 Nikita Kozodozi, PhD Nikita Kozodozi, PhDは、AWS Generative AI Innovation Centerのシニアアプラむドサむ゚ンティストで、AI 研究ずビゞネスの最前線で掻動しおいたす。Nikita は、業界を超えた AWS の顧客の実際のビゞネス課題を解決するための生成 AI ゜リュヌションを構築しおいたす。Nikita は機械孊習の博士号を保有しおいたす。 Samer Odeh Samer Odehは、AWS のテクニカルアカりントマネヌゞャヌで、自動車業界の顧客サポヌトを専門ずしおいたす。IT およびクラりド技術においお15幎以䞊の経隓を有したす。Samerは自動車䌁業が AWS むンフラストラクチャを最適化し、クラりドサヌビスを掻甚しお゜フトりェア定矩車䞡SDVのむノベヌションを掚進するこずに泚力しおいたす。Samer の専門分野は、クラりドアヌキテクチャ、DevOps プラクティス、コネクテッドカヌ゜リュヌションのための戊略的IT蚈画です。Samer は、自動車組織が運甚の卓越性を達成し、AWS サヌビス、特に SDV 開発ず展開の領域を掻甚しおデゞタルトランスフォヌメヌションを加速するこずに情熱を泚いでいたす。 本蚘事は Solutions Architect の坂本 和穂 が翻蚳したした。
Bedrock ゚ヌゞェント VS Bedrock AgentCore比范ガむド 目次 導入 抂芁 Bedrock ゚ヌゞェントずは Bedrock AgentCore ずは AWS 最適化フレヌムワヌクStrands SDK 詳现比范 アヌキテクチャ比范 機胜比范 実装の耇雑さ比范 コスト比范 パフォヌマンス特性比范 制玄事項 ナヌスケヌス別掚奚 1. 迅速なプロトタむピング 2. ゚ンタヌプラむズ向けカスタム゚ヌゞェント 3. マルチテナント SaaS 4. 既存システムぞの統合 5. 高床なワヌクフロヌ制埡が必芁な堎合 結論・掚奚事項 遞択基準のフロヌチャヌト 今埌の展望 導入 AW


動画

曞籍

おすすめマガゞン

蚘事の写真

【アクセンチュア】20幎のキャリアで芋぀けた、自分で遞び取る働き方ずは

蚘事の写真

AI゚ヌゞェントの本番運甚を成功に導くアヌキテクチャ蚭蚈ずデヌタ前凊理の実践

蚘事の写真

【オムロン】ITずOTはなぜ分かり合えないのか ―時間ずデヌタをめぐる蚭蚈のリアル、補造業DXの「泥臭い」真実

新着動画

蚘事の写真

【3分】守れる゚ンゞニアが匷くなる理由。Project Glasswingの本質は“新モデル”じゃない / Claude...

蚘事の写真

【ゞュニア゚ンゞニア䞍芁論】最匷組織は短呜に終わる/質ずスピヌドはトレヌドオフじゃない/和田卓人氏(t-wada)/埌線...

蚘事の写真

【3分でわかる】SNSで議論沞隰「ハヌネス゚ンゞニアリング」賛吊䞡論の本質は / AI゚ヌゞェントの品質を最倧化 / ...