みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。最近1週間の生成 AI を巡っては、Anthropic Claude Opus 4.7 の Amazon Bedrock 対応や、東京リージョンでの提供開始をはじめとして、「より強いモデルを、より現場に近い場所で動かす」ためのアップデートが相次ぎました。また4月20日〜24日に開催された Hannover messe では、AI技術による生産プロセスの最適化、効率化、そして企業の競争力向上と持続可能性が主要なテーマとなっていました 。データ分析中心のAIから「物理世界で自律的に動くフィジカルAI」への移行の加速が進んでいます。そして、AWS界隈も目が離せません。 それでは 4月 20 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 富士通株式会社様との AI-DLC Unicorn Gym で見えた開発の未来 」 AWSが提唱するAI駆動開発ライフサイクル（AI-DLC）を実践的に学ぶプログラム「Unicorn Gym」に、富士通株式会社が参加した際の取り組みを紹介するブログです。7チーム40名弱が3日間、Amazon Bedrock AgentCoreやAmazon Connectなどを活用しながら、COBOLからJavaへの移行、ペーパーレス化システム、AIエージェントプラットフォーム、自動架電システムといった実課題に取り組んだ内容がまとめられています。記事では、COBOLからJavaへの移行で約4,300行のコードを自動生成した事例など、生成AIを活用した開発の具体的な成果が数字とともに語られています。あわせて、SE（システムエンジニア）の役割が「コードを書く力」から「仕様を策定する力」や「AIが生成した成果物をレビューする力」へとシフトしていく点にも触れられており、生成AIを使った開発プロセスを組織に取り入れたいユーザーにとって導入のヒントになる内容です。 ブログ記事「 【開催報告 & 資料公開】お試しから卒業！Kiro の仕様駆動開発を本格活用 in 大阪 」 2026年3月17日にアマゾン ウェブ サービス ジャパン 大阪オフィスで開催された「AWS Business Innovation Series – West Japan」第1回の開催報告ブログです。18社37名が参加し、AWSが提供するIDE「Kiro」を使った仕様駆動開発を、座学・ハンズオン・ハッカソンの3ステップで体験する内容が実施されました。参加者の約85%がIT部門、15%が事業部門で、開発経験者は全体の約10%と少数だった点が特徴で、普段コードを書かない参加者でも半日で動作するプロトタイプまで作れたという反応が紹介されています。「Vibe Coding」と「Specモード」の体験を通じて、要件定義から実装までの流れを掴める構成になっており、生成AIを使った開発に興味はあるが何から始めればよいか迷っているユーザーにとって、社内での取り組みを検討する際の参考になる内容です。 ブログ記事「 AUMOVIO が Amazon Bedrock 搭載のエージェント型コーディングアシスタントでソフトウェア開発を強化 」 自動車部品サプライヤーのAUMOVIO社が、AWSと協業してエージェント型のコーディングアシスタントを開発した事例を紹介するブログです。Amazon BedrockやAmazon SageMaker、AWS Lambdaなどを組み合わせ、自動車特有のコードベース（約7,000関数）でモデルをファインチューニングし、オープンソースの「Cline」を活用したエージェントとして実装されています。自動車業界のようにAUTOSARやMISRA-C/C++といった業界標準への準拠が求められる領域でも、ドメインに特化したファインチューニングとエージェント型のアプローチを組み合わせることで、コーディング支援の実用性を高められる点が特徴です。記事内ではシニア開発者が5日間かけていたバグ修正が数分で完了した例や、冗長なコードを削除してファイルサイズを半減させた事例も紹介されており、業界固有のルールを持つ組織で生成AIによる開発支援を検討しているユーザーにとって参考になる内容です。 ブログ記事「 AI for Science – AI がもたらす研究新時代 」 創薬・ゲノミクス・材料科学・気候科学・物理学といった科学研究の領域で、AI活用が実用段階に入りつつあるという「AI for Science」の潮流を解説したブログです。Amazon Bedrock、Amazon SageMaker AI、Amazon Textract、Amazon Comprehendなどを組み合わせた研究基盤の構成や、Genomics England、Allen Institute、LILA Sciences、アリゾナ大学といった海外の先進事例が紹介されています。文部科学省が推進する「SPReAD」事業の開始タイミングにあわせて、大学や研究機関の研究者に向けて書かれている点が特徴で、8〜12週間の小規模なPoC（概念実証）から始める段階的な進め方が示されています。研究データが基盤モデルの学習に利用されない仕組みなど、知的財産や個人情報に関するデータ保護の考え方にも触れられており、AI活用を検討している研究機関やそれを支援する立場のユーザーにとって参考になる内容です。 ブログ記事「 EngineLab AI: AWSで実現するスタジオとクリエイター向け本番制作AI環境 」 EngineLab社が提供するマネージドデプロイメントプラットフォーム「EngineLab AI」を、Amazon EC2のGPUインスタンスやAWS Deadline Cloud上で活用する方法を紹介するブログです。映像・メディア制作の現場でよく使われるComfyUIなどの生成AIアプリケーションを、本番環境で安定して運用するための構成が解説されています。顧客自身のAWSアカウント内にデプロイされるためデータがプラットフォーム外に出ず、知的財産（IP）を社内に留められる点や、必要なときだけGPUリソースを使うオンデマンド型の構成でオンプレミスの固定費を抑えられる点が特徴です。ノードベースの操作に慣れた上級者向けのUIと、技術知識のないクリエイター向けのArtist UIを両立している点にも触れられており、スタジオやクリエイター組織で生成AIを制作ワークフローに組み込みたいと考えているユーザーにとって、実装イメージをつかめる内容です。 ブログ記事「 開発現場から全社展開へ：Amazon Bedrock で Claude Cowork を動かす 」 Anthropic社が提供するデスクトップアプリ「Claude Cowork」を、Amazon Bedrockをバックエンドとして動かす方法を紹介するブログです。ドキュメントの読み取りや複数ステップのリサーチ、ファイル処理などをアプリ上で行いつつ、データを自社のAWSアカウント内に保持したまま利用できる構成が解説されています。Claude Codeのような開発者向けツールから一歩進んで、プロダクトマネージャー、オペレーションマネージャー、ファイナンスアナリストなど、社内のナレッジワーカー全体に生成AIの活用を広げていく展開イメージが示されている点が特徴です。MDM（モバイルデバイス管理）による一元的な設定配布や、シートライセンス不要の従量課金モデルにも触れられており、開発チームで始めた生成AI活用を組織全体にスケールさせたいと考えているユーザーにとって参考になる内容です。 ブログ記事「 AI 駆動の業務変革手法：『課題は何ですか？』と聞くのをやめた日 」 AWSが開発した業務変革プログラム「AI BPR（AI-driven Business Process Re-Engineering）」について、試行錯誤の過程とともに紹介するブログです。初期の「課題解決型」アプローチが機能しなかった経験から、組織心理学の理論（Appreciative Inquiryなど）を取り入れて再設計し、Observe・Shift・Simulate・Forecastという4段階のフレームワークに行き着いた経緯が解説されています。生成AIの導入は技術的な問題よりも、組織が変化を受け入れる「適応課題」である点に焦点を当てている点が特徴で、AI活用を進めたいがなかなか現場が動かないと感じているユーザーにとって、アプローチを見直すヒントになる内容です。 ブログ記事「 IAM プリンシパルベースのコスト配分で Amazon Bedrock のコストを呼び出し元ごとに追跡する 」 Amazon Bedrockの利用コストを、呼び出し元のIAMユーザーやIAMロール単位で追跡できる新機能を紹介するブログです。Bedrock APIの呼び出しごとにIAMプリンシパルのIDが自動的に記録され、AWS Cost and Usage Report（CUR 2.0）やAWS Cost Explorerでプリンシパル単位のコストを可視化できるようになります。これまではBedrockの利用料金が単一の明細にまとまって表示されていたため、どのチームやプロジェクトがどれだけ使っているかを把握するにはAWS CloudTrailのログと突き合わせる必要がありました。この機能により、チャージバック（社内費用配賦）が正確に行えるようになり、複数チームで生成AIを活用している組織のコスト管理の負荷を下げられます。API Gateway経由でBedrockを呼び出す構成では中間ロールにコストが集約されるため、セッションタグでの動的な帰属が推奨されるといった実装上の注意点にも触れられています。 ブログ記事「 VPC 内のプライベートサービスに AWS DevOps Agent をセキュアに接続する方法 」 AWS DevOps Agentから、Amazon VPC内に閉じたプライベートなサービスに安全にアクセスする構成方法を紹介するブログです。Amazon VPC Latticeのリソースゲートウェイを経由して接続を確立し、セキュリティグループでトラフィックを制御する構成が解説されています。パブリックインターネットに公開することなく、エージェントから社内のプライベートなサービスにアクセスできる点がポイントで、具体例としてセルフホスト型Grafanaへの接続手順が紹介されています。これによりエージェントがオブザーバビリティ（システムの可視化）データを参照できるようになり、インシデント対応時の調査を自動化しやすくなります。AWS CLIとマネジメントコンソールの両方で設定手順が記載されているため、運用環境へのAWS DevOps Agent導入を検討しているユーザーにとって参考になる内容です。 ブログ記事「 Amazon Bedrock での Anthropic の Claude Opus 4.7 モデルのご紹介 」 Anthropic社の最新モデル「Claude Opus 4.7」がAmazon Bedrockで利用できるようになったことを紹介するブログです。米国東部（バージニア北部）、アジアパシフィック（東京）、欧州（アイルランド）、欧州（ストックホルム）の各リージョンで提供され、最大100万トークンのコンテキストウィンドウに対応しています。自律的にコーディングを進めるエージェンティックな用途での性能が向上しており、SWE-Bench Proで64.3%、Finance Agent v1.1で64.4%といったベンチマーク結果が紹介されています。Converse API、Invoke API、Messages APIといった複数の呼び出し方法に対応しているほか、新しい推論エンジンによる動的なキャパシティ割り当てやリクエスト数のスケールにも触れられており、長いドキュメントを扱う業務や、複数ステップにわたるコーディング・分析タスクにClaudeを組み込みたいと考えているユーザーにとって参考になる内容です。 ブログ記事「 Opus 4.7 が Kiro で利用可能になりました 」 Anthropic の最新モデル Claude Opus 4.7 が Kiro IDE および CLI に順次展開されました。Opus 4.6 の直接アップグレード版として、複雑で長時間にわたるタスクでのコーディング性能が向上し、複数ファイル・ツールにまたがるマルチステップ実装や自己検証機能を備えています。Kiro の仕様駆動開発との親和性も高く、大規模コードベースでの高忠実度な実装を実現します。 ブログ記事「 Kiro CLI をプログラムから実行する：ヘッドレスモードの紹介 」 Kiro CLIを、ブラウザを介さずにプログラムから実行できる「ヘッドレスモード」を紹介しています。APIキーを発行して環境変数に設定するだけで、CI/CDパイプラインやcronジョブなど無人の自動化環境でKiroを動かせるようになります。具体例として、GitHub Actionsと組み合わせてプルリクエストに自動でコードレビューを行う実装方法が紹介されています。コードレビュー以外にも、ドキュメント生成、依存関係の監査、マイグレーション支援など幅広い用途に応用できる点が特徴で、開発者の手元だけでなく、CIパイプラインの中に生成AIを組み込んでいきたいと考えているユーザーにとって参考になる内容です。 ブログ記事「 Kiro でビルドする：コミュニティハブと Kiro Labs の紹介 」 Kiroのエコシステム拡張として、「Kiro Community（コミュニティハブ）」と「Kiro Labs」の2つが発表されました。コミュニティハブは開発者の実験的なプロジェクトの共有や、Discord・イベントを通じた情報交換の場として機能し、Kiro Labsはアマゾン社員が構築したオープンソースプロジェクト群を公開する場として位置づけられています。Kiro Labsではカスタムワークフロー、UI、生産性向上ツールなどが「as-is」で提供され、アクティブ・メンテナンス・アーカイブの3段階のステータスが付与されるほか、Amazonのオープンソース基準に沿ったセキュリティレビューも行われます。Kiroをすでに使っているユーザーにとっては、他の開発者の実装例を参照してワークフローを組み立てたり、プルリクエストで貢献したりといった形で活用できるリソースが増える内容です。 サービスアップデート Claude Platform on AWSが近日公開 Anthropic社が提供するネイティブのClaudeプラットフォームを、AWSの認証情報と請求の仕組みでそのまま利用できる「Claude Platform on AWS」が近日公開として発表されました。Anthropic本家のプラットフォームと同じAPIや機能にアクセスできるため、Claudeの最新機能をいち早く利用できるのが特徴です。利用にあたっては、別途Anthropicとの契約や認証情報を用意する必要はなく、既存のAWSアカウントとIAMポリシーをそのまま使えます。APIコールはAWS CloudTrailに記録されるため、ほかのAWSサービスと同じように監査ログを一元的に管理でき、利用料金もAWSの請求書にまとめられます。Amazon Bedrockが「AWSの基盤上でClaudeを動かし、データをAWS内で処理・保持する」位置づけなのに対し、Claude Platform on AWSは「Anthropic側のプラットフォームをAWSの認証・請求で使う」という選択肢を提供する形で、ユースケースに応じて使い分けられる点がポイントです。 Amazon Bedrock AgentCoreが新機能を追加しエージェント開発を加速 Amazon Bedrock AgentCoreに、エージェント開発を加速するための新機能が追加されました。モデル・システムプロンプト・ツールを指定するだけで即座にエージェントを動かせる「マネージドハーネス（プレビュー）」、AWS CDK対応でコードベースのガバナンスを実現する「AgentCore CLI」、コーディング支援ツール向けの事前構築スキル「AgentCore Skills」の3つが提供されます。オーケストレーションコードを書かずにアイデアからプロトタイプまでを素早く立ち上げられる点が特徴で、プロトタイプの進化に合わせて評価・メモリ・ツールを段階的に追加していくこともできます。AgentCore SkillsはまずKiroから利用でき、Claude Code・Codex・Cursorにも順次対応予定です。マネージドハーネスは米国西部（オレゴン）、米国東部（バージニア北部）、欧州（フランクフルト）、アジアパシフィック（シドニー）の4リージョンでプレビュー提供されています。 Amazon QuickがVisierのVeeエージェントと統合し、ワークフォースインテリジェンス機能を提供 Amazon Quickが、Visier社の人材分析プラットフォームのAIアシスタント「Vee」とMCP（Model Context Protocol）経由で統合されました。これにより、Amazon Quickのワークスペース内から、Visierが管理する人員数・離職率・勤続年数・求人情報などのワークフォースデータに自然言語でアクセスできるようになります。人事・財務・オペレーション部門の担当者が、ツールを切り替えることなく組織の人材データを参照できるようになる点が特徴で、定期的なワークフォースレビューやドキュメント作成をQuick Flowsで自動化する使い方も想定されています。Amazon Quickがサポートする全リージョンで利用でき、組織全体の予算やポリシーデータと合わせて意思決定に活用したいユーザーにとって参考になる内容です。 Amazon Bedrock AgentCore GatewayとIdentityがVPC egress に対応 Amazon Bedrock AgentCore GatewayとAmazon Bedrock AgentCore Identityが、VPC egress（VPC内のプライベートリソースへの接続）に対応しました。マネージド型のVPC egressと、自己管理型のAmazon VPC Latticeリソースの両方から構成を選択でき、東京リージョンを含む14のAWSリージョンで利用可能です。これにより、Amazon EKS上でホストしているMCPサーバーや、社内ネットワーク内のプライベートなアイデンティティプロバイダー（IdP）、プライベートDNSで名前解決するリソースなどに、AgentCoreから直接アクセスできるようになります。エージェントからプライベートなエンタープライズシステムに安全に接続したいユーザーにとって、構成の選択肢が広がる内容です。 Amazon SageMaker HyperPodが自動Slurmトポロジー管理に対応 Amazon SageMaker HyperPodが、ネットワークトポロジーを自動で選択・最適化する機能に対応しました。GPUインスタンスタイプに応じてツリートポロジー（階層的な相互接続）とブロックトポロジー（均一な高帯域幅）を自動で選び、クラスターのスケール変更やノード置換の際にも継続的に最適化されます。これまでSlurm設定ファイルやトポロジーファイルを手動で管理していた運用から解放され、GPU間通信（NCCL集約通信）の効率を保ったまま分散学習を進められる点が特徴です。機能はデフォルトで有効化されており設定不要なため、大規模な分散学習を行うユーザーにとって運用負荷の軽減につながる内容です。 Amazon SageMakerがIAM Identity Centerドメインでノートブックとデータエージェントに対応 Amazon SageMaker Unified Studioで、これまでIAMドメインでのみ利用できたサーバーレスノートブックと組み込みのデータエージェントが、AWS IAM Identity Center（IdC）ドメインでも利用できるようになりました。Amazon Athena for Apache Sparkと連携し、SQL・Python・自然言語を単一の対話型ワークスペース上で組み合わせて扱えます。AWS IAM Identity Centerで認証・アクセス管理を一元化している組織でも、IAMドメインと同等の分析・機械学習機能が使えるようになる点がポイントで、AIデータエージェントが自然言語のプロンプトからコードを生成する機能や、ペタバイト規模のデータ処理にも対応しています。シングルサインオン環境を維持したままデータ分析基盤を整備したいユーザーにとって参考になる内容です。 Amazon QuickがSharePointとGoogle Driveを対象としたナレッジベースで複数所有者機能をサポート Amazon Quickで、Microsoft SharePointとGoogle Driveを対象とした管理者管理型のナレッジベースに、複数の所有者を追加できるようになりました。所有者には「オーナー」と「ビューアー」の2種類があり、オーナーは編集・同期・共有・削除を含む管理権限を、ビューアーはクエリのみの権限を持ちます。これまでナレッジベースが単一の所有者に依存していた運用から、チーム単位での共同管理が可能になる点が特徴で、既存のデータソース接続をそのまま再利用できるため、認証情報を再入力する必要もありません。東京リージョンを含む7つのAWSリージョンで利用でき、複数メンバーで社内ナレッジの整備を担当しているユーザーにとって運用がしやすくなる内容です。 Amazon QuickがACL対応ナレッジベースの権限検証機能をサポート Amazon QuickのACL（アクセス制御リスト）対応の知識ベースで、特定のユーザーが特定のドキュメントにアクセスできるかを検証するPermission Checker機能が追加されました。管理者は「Sync reports」タブからメールアドレスを入力することで、アクセス可否や、対象ドキュメントにアクセス可能なユーザー・グループ一覧を確認できます。これまではデータソース側の権限継承を手作業で追いかける必要があり、権限設定のトラブルシューティングに手間がかかっていました。機密情報が想定外のユーザーに参照されていないかを体系的にチェックできるようになるため、社内ナレッジを扱う知識ベース運用のセキュリティ確認を効率化したいユーザーにとって役立つ内容です。東京リージョンを含む7つのAWSリージョンで利用できます。 Amazon SageMaker Unified StudioがIAMドメインのプロジェクト内で複数コードスペースに対応 Amazon SageMaker Unified Studioで、IAMドメインの単一プロジェクト内に複数のコードスペース（個別に設定できる開発環境）を作成・管理できるようになりました。従来はプロジェクトあたりJupyterLabスペース1つとCode Editorスペース1つに限られていましたが、それぞれ独立したAmazon EBSボリュームを持つ複数のスペースを用意できます。長時間のデータ変換ジョブを動かしながら別スペースでモデル学習を進めるといった並行作業がしやすくなる点が特徴で、スペースごとに計算リソースやストレージをスケールさせたり、一時停止・再開したりできます。ブラウザからもローカルIDEからも接続でき、Amazon Q有料版にも対応しているため、1つのプロジェクト内で複数のワークストリームを回しているデータサイエンティストにとって作業効率の向上につながる内容です。 Amazon SageMaker AIがQwen3.5モデルのサーバーレスモデルカスタマイズに対応 Amazon SageMaker AIで、Alibaba Cloudが提供するQwen3.5モデル（4B・9B・27Bパラメータ版）に対するサーバーレスのファインチューニングがサポートされました。教師ありファインチューニング（SFT）と強化学習ファインチューニング（RFT）の両方に対応し、クラスター管理を行わずにモデルカスタマイズを実行できます。自社の独自データでモデルを調整して業界特有の用語や品質基準に適応させたい場合でも、インフラの構築や運用はAmazon SageMaker AI側が担うため、データや評価設計に集中できる点が特徴です。利用した分だけの従量課金モデルで、東京リージョンを含む4つのAWSリージョン（米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド））で提供開始されており、Qwen3.5を自社ユースケース向けに特化させたいユーザーにとって選択肢の一つになります。 Amazon SageMaker AIが生成AI推論レコメンデーション機能を提供開始 Amazon SageMaker AIに、生成AIモデルの推論環境を自動でベンチマークし、最適な構成を提案する「推論レコメンデーション」機能が追加されました。ユーザーがモデルとトラフィックパターン、性能目標（コスト最適化・レイテンシー最小化・スループット最大化のいずれか）を指定すると、システムが複数のインスタンスタイプを評価し、検証済みのメトリクスとともにデプロイ可能な構成を返します。初回応答時間（TTFT）、トークン間レイテンシー、スループット、コスト予測といった指標が一度にまとめて得られるため、手動でベンチマークを組んで比較する手間を省ける点が特徴です。東京リージョンを含む7つのAWSリージョンで利用でき、生成AIモデルを本番展開する際のインスタンス選定に悩んでいるユーザーにとって参考になる内容です。 Amazon SageMaker JumpStartで5つの新しいQwenモデルが利用可能に Amazon SageMaker JumpStartで、Alibabaが提供するQwenシリーズの新しい5つのモデルが利用できるようになりました。ツール利用や実行失敗からの復旧に対応する「Qwen3-Coder-Next」、思考モードの切り替えに対応した「Qwen3-30B-A3B」、数学・科学・コーディングの推論に特化した「Qwen3-30B-A3B-Thinking-2507」、エージェント型コーディング向けの「Qwen3-Coder-30B-A3B-Instruct」、マルチモーダルに対応する軽量モデル「Qwen3.5-4B」の5種類です。数クリックでデプロイできるJumpStartの特性を活かして、コーディングエージェントや多言語アプリケーション、軽量モデルでのコスト最適化された推論など、用途に応じたモデルを選択しやすくなっています。Qwenシリーズを自社のユースケースで試したいユーザーにとって、選択肢が広がる内容です。 Amazon EC2 G7eインスタンスがAWS Local Zonesロサンゼルスで利用可能に Amazon EC2のG7eインスタンスが、AWS Local Zonesのロサンゼルス（us-west-2-lax-1b）で利用できるようになりました。NVIDIA RTX PRO 6000 Blackwell Server Edition GPUと第5世代Intel Xeon Scalableプロセッサを搭載しており、VFXや色補正などのクリエイティブ制作から、大規模言語モデルの推論といったAIワークロードまで幅広く対応します。ロサンゼルス周辺でスタジオワークステーションやポストプロダクション、エッジでのAI推論といった低レイテンシーが求められる用途に、地理的に近い場所からGPUリソースを利用できる点がポイントです。オンデマンドとSavings Plansの両方で購入でき、メディア・エンタテインメント業界やエッジAIの導入を検討しているユーザーにとって選択肢の一つになる内容です。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。

本記事は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 の坂本 和穂 が翻訳しました。

キャリアプロダクト開発部の森 ＠jiskanulo です。 私ごとですが今年で45歳、WEBサービスの開発歴は20年以上になります。世間的にはベテランエンジニアとかシニアエンジニアとかと称される類だと自認しています。 そんな私ですが2026年1月に基本情報技術者試験を受験して合格しました。 この記事は、ベテランエンジニアが基本情報技術者試験をスキル棚卸しツールとして活用した体験と、受験しなくても使えるセルフチェックの方法を紹介します。 www.ipa.go.jp 受験の動機 結果 得意と苦手が可視化された 得意だった領域 苦手だった領域 得意と苦手のコントラストが意味するもの 試験範囲でスキルを棚卸しする方法 受験のTips CBT受験の雰囲気 集中力の維持に課題 まとめ 受験の動機 受験したきっかけは昨今のAIエージェントを前提とした開発手法の変化です。 ファインディではAIエージェントの導入・検証を積極的に行っています。 私もDevin, GitHub Copilot Chat, Cline, Claude Codeなどさまざまなツールやサービスを日々の開発業務に導入すべく検証していました。 2025年6月頃からClaude Codeを本格的に使用しはじめ、2026年3月現在では私自身が手でコードを書くことは全くなくなりました。 昨今のAIエージェントが主となり開発を進める体制では、AIエージェントへ適切な指示を出す力、AIエージェントからの提案を判断し承認・修正するための力が求められます。 この力をつけるための基礎知識として、基本情報技術者試験の内容はちょうどよいと感じています。 また、2025年末に開発部で「基本情報技術者試験の合格を目指しましょう」という方針も出たこともあり、社内のメンバーが続々と受験・合格している流れに乗りました。 受験理由をもう一つ挙げると、実は基本情報技術者試験を20年ほど前に受験して不合格になっており再挑戦をしないままでした。 さらに後年に応用情報技術者試験を受験し合格しているのですが、応用情報は持っているのに基本情報は持っていないというチグハグ感を解消したかったのです。 近いうちにデータベーススペシャリスト試験を受けようと考えていたところ、2026年度からCBT（コンピュータベースの試験）方式に移行するという情報があり、CBTの雰囲気を先に体験しておきたいという思いもありました。 ただデータベーススペシャリスト試験の実施そのものが2026年中は不明瞭な状況です。動向を注視しつつ、申し込みが再開されたらすぐエントリーしたいですね。 www.ipa.go.jp 結果 科目Aは705点、科目Bは680点となんとか合格できました。もう少し余裕を持って合格したかったのですが、そこは今後の伸びしろとします。 得意と苦手が可視化された 受験して最も収穫だったのは、自分のスキルの輪郭がはっきり見えたことです。 得意だった領域 計算問題やコードリーディング、データベース正規化や稼働率計算などの問題はスムーズに解けました。 日常業務でコードを書き、レビューし、設計・運用を考えることを毎日やっているので、実務経験がそのまま得点に結びつきました。 過去問の模擬試験でもこれらの分野は正答率が高く、特別な対策をしなくても安定して解ける状態でした。 苦手だった領域 一方、会計管理や財務指標に関する問題には苦戦しました。損益分岐点、ROI、減価償却といったテーマは過去問を解いていても正答率が目に見えて低い分野でした。 振り返ってみると、日々の開発業務で財務指標を意識する場面はほとんどありませんでした。 業務で触れない領域は経験年数に関係なく穴のまま残っている。この気づきが、受験して得た最大の収穫でした。 得意と苦手のコントラストが意味するもの この経験から見えたことは、エンジニアのスキルは実務でカバーしている範囲には自然と強くなれるが、逆に触れていない範囲は何年経っても盲点のままだということです。 基本情報技術者試験の出題範囲はITエンジニアの基礎知識を広くカバーしています。 だからこそ、受験すると自分のスキルマップの中で「どこが埋まっていて、どこが空白か」が浮き彫りになります。 試験のための勉強がすぐにサービス開発に活かせるかというとそうでもないのですが、自分の基礎知識の全体像を把握するにはちょうどいい粒度だと感じました。 試験範囲でスキルを棚卸しする方法 受験するにあたり、基本情報技術者試験ドットコムに大変お世話になりました。 www.fe-siken.com 私の場合は1日30分、20日間ほどで合計600問を回答しました。無料サービスの範囲でも十分に過去問を試すことができますし、有料のメンバー登録をすると学習の記録管理がしやすくなります。 スキル棚卸しをするために、まず科目Aの過去問を解いてみてください。 分野ごとの正答率が記録されるので、自分がどの分野に強く、どの分野に穴があるかが数値で可視化されます。 参考として、基本情報技術者試験の科目A出題範囲をもとにしたセルフチェック表を載せておきます。自分が「得意」「苦手」「触れたことがない」のどれに当たるか振り返ってみてください。 分野 自己評価（筆者の例） 基礎理論（離散数学、情報理論等） 得意 アルゴリズムとプログラミング 得意 コンピュータ構成要素 得意 システム構成要素 得意 ソフトウェア 得意 ハードウェア 苦手 データベース 得意 ネットワーク 苦手 セキュリティ 得意 マネジメント（プロジェクト・サービス） 苦手 ストラテジ（経営戦略・法務） 苦手 表のとおり、実務で日常的に使う分野は得意、そうでない分野は苦手という傾向がはっきり出ました。 正答率が安定して高い分野は実務でカバーできている基礎知識。低い分野やまったく分からない分野は、業務で触れていない盲点です。「知っているつもりだったが正確には理解できていなかった」という曖昧な領域も見つかるかもしれません。 受験のTips CBT受験の雰囲気 当日午後に受験会場に着くと、試験開始時刻前でも受験を始めてよいと案内されました。 パソコンに向かう前に持ち物検査を終えて着席。 キーボードはログイン時にしか使わず、試験中はマウス操作のみ。紙とペンは貸してもらい、筆算やコードのトレースをしながら回答しました。 回答完了ボタンを押すとすぐに得点が表示され、合否をその場で確認できました。結果待ちのモヤモヤがなかったのは嬉しいポイントでした。 集中力の維持に課題 科目Bの時点で集中力が切れてしまったのが今回の反省点です。 20年前は午前問題のあとに2時間ほどの昼休みがあり、リフレッシュしてから午後問題に臨めました。現在の形式では科目Aのあと10分の休憩で科目Bが始まるため、体力的にも精神的にも消耗した状態で後半戦に入ることになります。 受験する前には十分に体調を整えて臨むことをおすすめします。 まとめ 基本情報技術者試験は、資格取得という目的だけでなく、自分のスキルの得意と苦手を可視化するツールとして活用できました。 スキルを可視化できたこともあり、今年中にデータベーススペシャリスト試験の合格を目指して準備を進めていこうと思います。 みなさんも試験を受けてみてください。受験しなくても、過去問を試すだけでスキルの棚卸しになりますよ。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers