AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3894ä»¶

本ブログは 株匏䌚瀟スギ薬局様 ずアマゟン りェブ サヌビス ゞャパン合同䌚瀟が共同で執筆いたしたした。 みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの吉田です。 「生成 AI を業務に掻甚したいが、䞀過性の PoC で終わっおしたう」「成果を組織党䜓に広げるにはどうすればいいか」——こうしたご盞談をいただく機䌚が増えおいたす。 今回ご玹介するのは、株匏䌚瀟スギ薬局様の事䟋です。珟堎の業務課題ず技術を組織ずしお結び぀けながら、 Amazon Bedrock を掻甚した幎末調敎 QA ボットず調剀医薬品圚庫確認゚ヌゞェントを構築されたした。これらの成果が次の AI 掻甚を呌ぶサむクルが回り始め、AI 利掻甚が組織に根付いおいく過皋をご玹介いたしたす。 䌁業抂芁ずデゞタル倉革ぞの取り組み 株匏䌚瀟スギ薬局様は、ドラッグストアず調剀薬局を党囜に展開する䌁業です。近幎、ドラッグストア・調剀薬局業界では、薬剀垫䞍足や調剀・介護領域ぞの事業拡匵を背景に、経営統合や M&A による芏暡拡倧が進んでいたす。スギ薬局様もグルヌプ再線により調剀薬局が合流し、店舗数・埓業員数がさらに拡倧したした。 こうした事業環境の倉化に察応するため、スギ薬局様は DX を積極的に掚進しおいたす。各務 CDO は、DX の方針・ビゞョンに぀いお次のように語りたす。 「䌚瀟の OS をアップデヌトし、2030幎たでに AI DX を倖郚に提䟛できる歊噚ぞ進化させる」こずです。デゞタル技術で効率化し、創出した「可凊分時間」を人間らしい接客に再投資できるようにしたす。組織暪断の「サヌビス型チヌム」を栞に、自埋的に人が成長し続ける堎䜜りを目指しおいたす。 組織䜓制OneSUGI PJ × CTO as a Service このビゞョンを実珟するため、スギ薬局様では DX・AI 掚進本郚のもず、業務課題の把握から技術的な解決たでを組織的に掚進する䜓制を構築しおいたす。 OneSUGI PJ 珟堎の業務課題を集玄・粟査し、゜リュヌションのリリヌスたでを䞻導したす。 CTO as a Service 技術アドバむザヌずしお、課題に察する最適な゜リュヌションの方向性を提案したす。 AI 掚進郚 CTO as a Service の技術方針をもずに実装・運甚を担い、OneSUGI PJ にサヌビスを提䟛したす。 この䜓制により、珟堎のニヌズず技術的な実珟性を䞡茪で回せる仕組みが確立されおいたす。 図スギ薬局様の AI 掻甚掚進䜓制 以降でご玹介する幎末調敎 QA ボットず調剀医薬品圚庫確認゚ヌゞェントは、この組織䜓制から生たれた具䜓的な AI 利掻甚の取り組みです。 取り組み①幎末調敎 QA ボット 課題 スギ薬局様では毎幎、幎末調敎期間䞭に掟遣瀟員6〜7名をロヌテヌションで雇甚し、人事郚ず合わせお玄10名䜓制で幎末調敎に察する瀟内電話問い合わせ察応を行っおいたした。昚今のグルヌプ再線により察象者が玄4,000人増加し、問い合わせ件数のさらなる増倧が芋蟌たれおいたした。 こうした状況の䞭、人事郚から「AI による問い合わせ察応業務の効率化を、幎末調敎が始たるタむミングに間に合わせたい」ずいう芁請があり、玄1ヶ月埌たでに RAG チャットボットを甚意する必芁がありたした。たず䞖間で評刀の高いツヌルを評䟡したしたが、既存のデヌタ゜ヌスに察応しおおらず、別の手段を怜蚎するこずになりたした。 解決策Bedrock Chat による迅速な構築 既存デヌタ゜ヌスを甚いた RAG を実珟したいずいう明確な目的ず、人事郚偎である皋床ボットを管理したいずいうニヌズがありたした。そこで採甚したのが、 Bedrock Chat です。 Bedrock Chat は、Amazon Bedrock を基盀ずした AWS のサンプルチャットアプリケヌションです。 ワンクリックで AWS 䞊にデプロむ でき、Web UI から RAG 甚のナレッゞ远加やボットのカスタマむズが可胜です。人事郚偎でファむルの远加やボットの線集ができるため、運甚負荷を最小限に抑えられる点が決め手ずなりたした。 RAG のデヌタ゜ヌスには幎末調敎 FAQ リストを䜿甚し、瀟員1人が2日で環境を構築、人事郚ず連携しお数日でリリヌスを実珟したした。この際、スギ薬局様の運甚芁件に合わせたカスタマむズは、AI コヌディングアシスタントの Kiro を掻甚しお実斜したした。 図:実際の幎末調敎 QA ボットの利甚むメヌゞ。埓業員が幎末調敎に関する質問を入力するず、FAQ を怜玢する様子。 成果 幎末調敎 QA ボットは幎末調敎の期間䞭、玄40日間の皌働で以䞋の成果を䞊げたした。 定量的な成果 指暙 結果 問い合わせ凊理件数 期間を通しお玄2䞇件 人事工数の削枛 1ä»¶10分換算で3,000時間以䞊 入電率の倉化 1.21% → 1.08%察象者が玄4,000人増加したにもかかわらず䜎䞋 電話察応䜓制 昚幎ず同じ玄10名䜓制で問題なく察応 コスト SaaS 補品では1,200䞇円かかる想定だったずころを、AWS のマネヌゞドサヌビスを掻甚しお瀟員1人が2日で構築し運甚費は玄10䞇円皋床に収たった 定性的な成果 幎末調敎 QA ボットは珟堎から奜評を埗たした。ボットのクロヌズ埌には、人事党般の問い合わせサポヌトツヌルずしおの利掻甚怜蚎が開始されたほか、他郚門からも問い合わせ察応に AI ゚ヌゞェントを掻甚したいずいう芁望が䞊がるようになりたした。 たた、幎末調敎シヌズンの終了埌には本ボットのリ゜ヌスを削陀しおいたす。必芁な時に立ち䞊げ、䞍芁になれば停止できるクラりドの埓量課金モデルを掻かし、迅速か぀コストを最小限に抑えた運甚を実珟したした。4䞇人を超える埓業員が利甚察象ずなる䞀方、䞀人あたりの利甚頻床は限定的です。こうした利甚パタヌンには、ナヌザ単䜍で課金される完成型のサヌビスよりも、Amazon Bedrock のトヌクン単䜍の課金をはじめずする AWS の埓量課金モデルがマッチしおいたした。 今回構築した環境は圹目を終えたしたが、「AI でここたでできる」ずいう䜓隓が瀟内に広たり、次の取り組みを加速させるこずになりたす。 取り組み②調剀医薬品圚庫確認゚ヌゞェント 課題 幎末調敎 QA ボットの奜評も远い颚に、OneSUGI PJ ぞの次の AI 掻甚案件ずしお調剀医薬品圚庫確認゚ヌゞェントが舞い蟌みたした。 調剀薬局のグルヌプ統合盎埌、圚庫管理システムは䌚瀟間で統合されおおらず、調剀薬局の薬剀垫が近くのスギ薬局店舗に電話をかけお圚庫を確認しおいたした。電話が぀ながれば数分で枈む䜜業ですが、実際には「盞手が忙しくお察応できない」「忙しいだろうから遠慮しお電話しづらい」ずいう心理的な課題を抱えおいたした。 薬剀には䜿甚期限があるため過剰に圚庫を眮くこずはできず、普段の消費ペヌスにない薬剀は欠品になりやすい状況です。患者様に必芁なお薬をお枡しできなければ、他の薬局に足を運んでいただくこずになり、患者様ぞの負担は倧きくなりたす。 解決策基幹システムデヌタを掻甚した AI ゚ヌゞェント たず幎末調敎 QA ボット同様 Amazon Bedrock による RAG を怜蚎したしたが、構造化された圚庫デヌタに察しおは毎回結果が異なり、期埅する回答を埗られなかったため、別のアプロヌチを暡玢したした。 最終的に採甚したのは、Text2SQL のアプロヌチです。゚ヌゞェントフレヌムワヌクには Amazon Bedrock Agents を遞びたした。フルマネヌゞドで運甚負荷が䜎く、モデル呌び出しず Lambda の実行費甚のみで枈むため、限られた時間の䞭でツヌル開発ずいう本質的な䟡倀提䟛にフォヌカスできる点が決め手ずなりたした。自然蚀語の問い合わせを SQL に倉換し、デヌタりェアハりスである Amazon Redshift に集玄された圚庫デヌタを怜玢する構成ずしたした。 図調剀医薬品圚庫確認゚ヌゞェントのシステム構成 この構成の肝は、基幹システムに蓄積された゚ンタヌプラむズデヌタ圚庫デヌタ・店舗マスタ・医療薬品マスタを AI ゚ヌゞェントから盎接掻甚できるこずです。AWS 䞊にデヌタ基盀ず AI 基盀が共存しおいるからこそ、お客様ご自身で迅速か぀手軜にデヌタ掻甚を実珟するこずができたした。なお、デヌタぞのアクセス制埡に぀いおは、党店舗共通で参照可胜なカラムのみを察象ずし、Lambda 関数の䞭でアクセス範囲を制限する蚭蚈ずしおいたす。 Text2SQL の粟床は、LLM の性胜だけでは決たりたせん。既存のデヌタマヌトスキヌマの正確な理解、業務甚語のプロンプトでの䌝え方、生成された SQL の評䟡方法——これらを短いサむクルで詊行錯誀しながら求める回答粟床ぞずチュヌニングしおいくこずが重芁でした。たた、短期間で評䟡・改善を繰り返すために、近隣店舗の怜玢には Amazon Location Service を掻甚し、フロント゚ンドには幎末調敎 QA ボットでも利甚した Bedrock Chat の Agent 連携機胜 を甚いお迅速に構築しおいたす。 図実際の圚庫確認゚ヌゞェントの利甚むメヌゞ。薬剀垫が店舗名ず薬品名を入力するず、察象店舗および近隣店舗の圚庫数ず䜍眮関係が返されたす。 成果 箄1ヶ月で構築し、200店舗に公開。2026幎4月初旬から本番展開を開始しおいたす。 珟堎では AI ゚ヌゞェントに察する抵抗感はなく、幎配の方もスムヌズに問い合わせができおいたす。 最も倧きな倉化は、業務フロヌそのものの転換です。 Before After 圚庫確認の方法 近くの店舗に電話 AI ゚ヌゞェントに問い合わせ 心理的な障壁 「忙しいだろうから遠慮しお電話しづらい」 自分のタむミングで気兌ねなく怜玢 情報の範囲 電話した1店舗の情報のみ 近隣店舗の圚庫ず距離を䞀芧で把握 お客様の声 各務様コメント取締圹 / DX・AI掚進本郚長 å…Œ CDO 今埌も AI の本質を理解し、そこに察応をできる組織力が勝負になるず考えおいたす。䜕故ならばその組織力は1日ではできないためです。AI がその組織力匷化にも䞀圹買っおくれるず考えおおり、その芖点で䜿い倒しおいく予定です。 有路様コメントDX・AI掚進本郚 AI掚進郚 課長 技術遞定では、䞖の䞭の事䟋にある補品を実際に利甚しお比范したした。その結果、AWS が最も粟床が高く、導入ずランニングコストが䞀番安いず刀断したした。日々アップデヌトがある䞭で安定しお業務に利甚するには苊劎もありたすが、評䟡の結果安定しおいるず刀断したら導入メリットは高いので、今埌も積極的に詊行錯誀しお業務改善ぞず掻甚しおいきたいず思っおいたす。 高階様コメントDX・AI掚進本郚 OneSUGI PJ リヌダヌ AI を特別なものではなく、店舗や本郚の日垞業務に溶け蟌む圓たり前のツヌルずしお浞透させるこずを重芖しおいたす。珟堎起点での掻甚ず小さな成功䜓隓の積み重ねを通じお、䞻䜓的に AI を䜿いこなす文化の醞成を進めおいたす。今埌も珟堎に寄り添いながら、倉革を着実に掚進しおいきたす。 今埌の展望 スギ薬局様では、圚庫確認゚ヌゞェントを調剀薬局の党店舗に展開し、珟堎からのフィヌドバックをもずに改善を進めおいく予定です。 たた、数幎埌には数癟の AI ゚ヌゞェントを本郚メンバが自ら構築できるようになるこずをゎヌルずしおいたす。その基盀ずしお Amazon Bedrock AgentCore の掻甚も怜蚎いただいおいたす。 たずめ 今回は、スギ薬局様が組織暪断のチヌムで珟堎業務課題ず技術を結び぀け、Amazon Bedrock を掻甚しお幎末調敎 QA ボットず調剀医薬品圚庫確認゚ヌゞェントを構築した事䟋をご玹介したした。 特に泚目すべきは、以䞋のサむクルが組織ずしお回っおいる点です。 組織䜓制の確立 業務課題ず技術を぀なぐ䜓制を敎備する 珟堎課題の集玄 OneSUGI PJ が珟堎の声を拟い䞊げる 技術による迅速な解決 CTO as a Service が最適な゜リュヌションを短期間で遞定する 成果が次の取り組みを加速 成功䜓隓が瀟内に広たり、新たな AI 掻甚の芁望に぀ながる AI 掻甚を成功させるには、技術だけでなく、業務課題ず技術を぀なぐ組織䜓制が鍵です。スギ薬局様の取り組みは、AI を組織に根付かせたいず考えおいる倚くの䌁業にずっお、参考になる事䟋ではないでしょうか。 AI 掻甚掚進の䜓制づくりを含め、生成 AI の業務利甚や、業務デヌタを掻甚した AI ゚ヌゞェントの構築にご興味・ご関心のあるお客様は、ぜひ AWS たでお気軜にご盞談ください。 著者 吉田 英史 は、東海地方を䞭心に小売・消費財業界のお客様を支揎しおいるアマゟンりェブサヌビスの゜リュヌションアヌキテクトです。身の回りの生掻に欠かせない様々なビゞネスをクラりドで加速するお手䌝いができるこずを、䜕より嬉しく感じおいたす。
本蚘事は「 Planview saves 40+ hours per audit cycle by automating SOC 2 compliance with Kiro CLI 」を翻蚳したものです。 コンプラむアンス管理は、時に圧倒的な負担に感じるこずがありたす。倚くの゚ンゞニアリングチヌムにずっお、継続的に倧きな泚意を払い続ける必芁がある業務です。チヌムは幎間サむクルごずに 40 時間以䞊をかけお゚ビデンスを収集し、クラりドプロバむダヌのコン゜ヌルを操䜜し、監査期限が迫る䞭でスプレッドシヌトを䜜成しおいたす。 戊略的ポヌトフォリオ管理のリヌダヌずしお䞖界䞭で 3,000 瀟以䞊の顧客にサヌビスを提䟛する Planview も、同じ課題に盎面しおいたした。マルチサヌビスの AWS むンフラストラクチャ党䜓で SOC 2 コンプラむアンスを維持するために、顧客向けの機胜開発に充おるべき゚ンゞニアリング時間が消費されおいたのです。ここでは、Planview が Kiro CLI を䜿っおコンプラむアンスワヌクフロヌをどのように倉革し、コンプラむアンスサむクルあたり 40 時間以䞊を削枛したかをご玹介したす。 コンプラむアンスは倧倉 Kiro 導入前の Planview のコンプラむアンス管理は、以䞋のような状況でした。 ゚ンゞニアが手動で゚ビデンスを収集 — 20 以䞊のクラりドサヌビスにたたがり、コン゜ヌルや API からデヌタを取埗しおいたした。 チヌムがスプレッドシヌトの発掘䜜業を実斜 — セキュリティコントロヌル、タむムスタンプ、監査蚌跡を远跡しおいたした。 監査準備サむクルに 40 時間以䞊を消費 — ゚ンゞニアをプロダクト開発から匕き離しおいたした。 耇数のチヌムメンバヌにたたがる調敎オヌバヌヘッド — クラりドプロバむダヌず SOC 2 芁件の䞡方に粟通した専門知識が必芁でした。 クラりドコンプラむアンスを管理する倚くの゚ンゞニアリングチヌムが、同様の課題に盎面しおいたす。監査に費やす時間、コンテキストスむッチ、手動゚ラヌの可胜性、四半期サむクルの蚈画が、コストを耇合的に増倧させおいたす。 コンプラむアンスぞの新しいアプロヌチ Planview は、たた別のコンプラむアンスダッシュボヌドを構築するのではなく、異なるアプロヌチを遞びたした。Kiro CLI を䜿っお、コンプラむアンスの自動化を開発ワヌクフロヌに盎接組み蟌んだのです。 圓初、Planview の SOC 2 コンプラむアンスプロセスは完党に手動で、セキュリティチヌムず゚ンゞニアリングチヌムに倚倧な時間ずリ゜ヌスを芁しおいたした。コンプラむアンスワヌクストリヌムの効率化のため、チヌムは 2025 幎第 1 四半期に商甚の継続的コンプラむアンスプラットフォヌムを評䟡したした。Planview は長期的には継続的コンプラむアンス機胜の導入を蚈画しおいたすが、フル商甚プラットフォヌムのオヌバヌヘッドなしに迅速に䟡倀を提䟛できる暫定的な゜リュヌションが必芁でした。このニヌズに Kiro は最適でした。Kiro は Planview の既存ワヌクフロヌに盎接統合され、フルコンプラむアンスプラットフォヌムぞの移行の道を閉ざすこずなく、すぐに自動化のメリットを提䟛したした。 Kiro CLI でカスタムコンプラむアンス゚ヌゞェントを䜜成する Planview は、Kiro CLI の組み蟌み aws ツヌルずカスタム゚ヌゞェント機胜を䜿甚しお、クラりドサヌビスぞのきめ现かな読み取りアクセスを蚭定したした。Kiro のカスタム゚ヌゞェントを䜿うず、ナヌスケヌスに合わせた特定のコンテキストずツヌル暩限を持぀、目的特化型の AI アシスタントを䜜成できたす。Planview の堎合、SOC 2 コンプラむアンスワヌクフロヌに関連する技術的゚ビデンスを取埗するために、クラりドサヌビスぞの事前承認枈みの読み取り専甚アクセスを持぀゚ヌゞェントを䜜成したした。事前承認ずは、゚ヌゞェントが各読み取り操䜜に察しお手動の承認を必芁ずしないこずを意味したす。これにより、監査サむクルや゚ビデンス収集タスクごずに手動で暩限を付䞎する必芁がなくなり、以前は 40 時間以䞊かかっおいた手動プロセスが自動化されたワヌクフロヌに倉わりたした。この統合は読み取り専甚の非䟵襲的なアクセスで動䜜するため、むンフラストラクチャのセキュリティは確保され、倉曎されるこずはありたせん。これはコンプラむアンスに限った話ではありたせん。䟋えば、CloudWatch メトリクス、S3 バケット蚭定、Lambda 関数ログをク゚リするむンフラストラクチャ監芖甚のカスタム゚ヌゞェントを䜜成し、AWS サヌビスぞの事前承認枈み読み取りアクセスを付䞎しお、運甚ヘルスレポヌトを自動生成するこずもできたす。 カスタム゚ヌゞェントの䜜成方法 ず 蚭定䟋 をご芧ください。 以䞋の䟋は、 ~/.kiro/agents/soc2-compliance.json に保存するカスタム soc2-compliance ゚ヌゞェント JSON の参考䟋です。これを SOC 2 コンプラむアンスプロセスを支揎するアシスタントずしお掻甚でき、CLI で kiro-cli --agent soc2-compliance たたはカスタム゚ヌゞェント名を䜿っお起動できたす。 { "name": "soc2-compliance", "description": "セキュリティコントロヌル、監査準備、ポリシヌ適甚のための SOC 2 コンプラむアンスアシスタント", "prompt": "file://./prompts/soc2-expert.md", "tools": [ "read", "write", "aws" ], "allowedTools": [ "read" ], "toolsSettings": { "write": { "allowedPaths": [ "docs/compliance/**", "policies/**", "audit/**", "security/**" ] }, "aws": { "allowedServices": [ "iam", "cloudtrail", "config", "guardduty", "securityhub", "inspector", "kms", "s3" ], "autoAllowReadonly": true } }, "resources": [ "file://policies/**/*.md", "file://docs/compliance/**/*.md", "file://audit/**/*.json", "file://security/controls/**/*.yaml" ] } この JSON は、セキュリティコントロヌル、監査準備、ポリシヌ適甚を支揎するために蚭蚈された特化型゚ヌゞェント蚭定を定矩しおいたす。各セクションの意味は以䞋の通りです。 name — ゚ヌゞェントの識別子/名前 description — ゚ヌゞェントの目的を説明する人間が読める説明文SOC 2 コンプラむアンス業務 prompt — ゚ヌゞェントのシステム指瀺/動䜜を含むマヌクダりンファむルぞのパス ./prompts/soc2-expert.md  tools — ゚ヌゞェントがアクセスできるツヌル: read組み蟌みツヌル— ファむル/ディレクトリの読み取り write組み蟌みツヌル— ファむルの䜜成/倉曎 aws組み蟌みツヌル— AWS CLI 呌び出し allowedTools — ナヌザヌ承認を必芁ずしないツヌルここでは read のみ自動承認。write ず aws は確認が必芁 toolsSettings — 各ツヌルのきめ现かな暩限蚭定: write.allowedPaths — ゚ヌゞェントが曞き蟌みできるディレクトリを限定コンプラむアンスドキュメント、ポリシヌ、監査ファむル、セキュリティファむル aws.allowedServices — ゚ヌゞェントが操䜜できる AWS サヌビスを限定IAM、CloudTrail、Config、GuardDuty、SecurityHub、Inspector、KMS、S3 — すべおセキュリティ/コンプラむアンス関連 aws.autoAllowReadonly — 読み取り専甚の AWS 操䜜describe-*、list-*、get-* などは承認䞍芁 resources — ゚ヌゞェント起動時に自動的にコンテキストに読み蟌たれるファむル: ポリシヌのマヌクダりンファむル コンプラむアンスドキュメント 監査 JSON ファむル セキュリティコントロヌル YAML ファむル あるいは、゚ヌゞェント蚭定 JSON を手動で䜜成する代わりに、Kiro CLI の /help ゚ヌゞェントを䜿甚できたす。これは、自然蚀語の説明からスマヌトな゚ヌゞェント蚭定の掚奚を生成する組み蟌みアシスタントです。Kiro CLI 内で /help Help me create a custom agent for soc-2 compliance を実行するず、Kiro が SOC 2 コンプラむアンスを支揎するための初期ドラフトを自動的に生成したす。 /help Help me create a custom agent for soc-2 compliance を実行するず、以䞋のこずが起こりたす。 Kiro は組み蟌みの /help ゚ヌゞェントに切り替わりたす。これは Kiro CLI に関する質問に答え、蚭定を生成するために特化された゚ヌゞェントです。 /help ゚ヌゞェントは Kiro の内郚ドキュメントを参照しお正しい゚ヌゞェント蚭定スキヌマを怜玢し、生成される蚭定が有効なフィヌルドを䜿甚し、ベストプラクティスに埓っおいるこずを確認したす。 /help ゚ヌゞェントは、ツヌル、暩限、リ゜ヌスパタヌン、カスタマむズされたシステムプロンプトを含む掚奚蚭定を、手動の JSON 䜜成なしに生成したす。必芁に応じおこれを調敎できたす。 Kiro CLI でカスタム゚ヌゞェントを䜿甚する 開発者がタヌミナルで kiro-cli --tui --agent soc2-compliance を䜿っおこのカスタム゚ヌゞェントを起動するず、チャットセッション開始時に「aws」ツヌルの allowedServices、resources、allowed paths のコンテキストず暩限が読み蟌たれたす。 --tui フラグを䜿甚するず、Kiro CLI の新しい UX が読み蟌たれたす。通垞の kiro-cli タヌミナル䜓隓を䜿甚したい堎合は、 kiro-cli --classic --agent soc2-compliance を䜿甚するか、Kiro タヌミナル内で /agent soc2-compliance を䜿甚できたす。 プロンプト䟋: 「すべおの S3 バケットの暗号化ステヌタス、パブリックアクセス蚭定、アクセスログ蚭定を瀺す SOC 2 CC6.1 コンプラむアンスレポヌトを生成しおください。」 Kiro の機胜を掻甚しお、Planview は SOC 2 および ISO ゚ビデンスのタむムスタンプ収集を簡玠化したした。システムがタむムスタンプ付きの情報を取埗できるようになり、Kiro は以䞋を自動的に実行できるようになりたした。 すべおのリヌゞョンにわたる S3 蚭定のク゚リ、たたは同じ結果を生成するク゚リの実行を支揎するスクリプトの䜜成 暗号化蚭定ずキヌ管理の確認 アクセスコントロヌルリストずバケットポリシヌの怜蚌 タむムスタンプ付きのフォヌマットされたコンプラむアンス゚ビデンスの生成 ゚ヌゞェントが耇雑さを凊理し、チヌムは必芁な゚ビデンスを取埗できたす。 泚意: AI が生成するコンプラむアンス出力は、゚ヌゞェントに提䟛されるプロンプトの具䜓性ず範囲に倧きく䟝存したす。これは監査プロセスを加速するためのツヌルであり、決定論的なコンプラむアンスツヌルの代替ずなるものではありたせん。AI が生成したすべおの掚奚事項、ポリシヌテキスト、監査゚ビデンスは、本番環境での䜿甚や監査人ぞの提出前に、資栌のあるコンプラむアンス専門家によるレビュヌず怜蚌を受ける必芁がありたす。 成果 以前は手動でのデヌタ収集が必芁だった䜜業が、自動的に行われるようになりたした。Kiro はタむムスタンプ付きのコンプラむアンス゚ビデンスを取埗し、䞊蚘の AWS 蚱可サヌビスを䜿甚しおセキュリティスキャンを実斜し、特定の SOC 2 および ISO コントロヌル芁件に沿ったアヌティファクトを敎理したす。 このワヌクフロヌは、開発環境の倉曎を必芁ずせずに Planview の既存プロセスに統合されたす。以前は手動だった゚ビデンス収集が、Kiro CLI の組み蟌みツヌルを通じお実行され、フィヌドバック甚の察話型むンタヌフェヌスが提䟛されたす。Planview チヌムは、すぐに倧きく枬定可胜な効果を実感したした。 コンプラむアンスサむクルあたり 40 時間以䞊を削枛 — 節玄された時間は、゚ビデンス収集ではなく顧客䟡倀の構築に掻甚されおいたす。 自動化による党䜓的な効率 60% 向䞊 — チヌムは監査リク゚ストに 3〜4 倍速く察応できるようになりたした。 チヌムメンバヌあたり 1〜1.5 SDE スプリント分の時間を節玄 — 機胜開発や改善に振り向けられおいたす。 オンデマンドの゚ビデンス収集 — 特定の時間を確保するのではなく、幎間を通じお監査に備えるこずができたす。 しかし、本圓の成果は、゚ンゞニアリングリ゜ヌスが本来あるべき堎所に戻ったこずです。スプレッドシヌトの䜜成ではなく、プロダクトの構築に集䞭できるようになりたした。 たずめ Planview のアプロヌチは、コンプラむアンス業務が負担である必芁はないこずを瀺しおいたす。コンプラむアンス芁件を仕様ずしお提䟛し、AI を開発ワヌクフロヌに盎接組み蟌むこずができたす。 カスタム゚ヌゞェント のような機胜は、セキュリティ基準を維持しながら、チヌムが顧客ぞの䟡倀提䟛に集䞭できるよう支揎したす。 Planview は、コンプラむアンス管理以倖のナヌスケヌスにも Kiro CLI のカスタム゚ヌゞェントの掻甚を拡倧しおいたす。これにより、組織党䜓のより倚くの開発者が再珟可胜なワヌクフロヌを䜿甚し、効率化の効果を倍増させるこずができたす。 Kiro CLI を 今すぐ 始めたしょう。
前回の Week in Review に、2026 幎、お客様ずの AI-Driven Development Lifecycle (AI-DLC) ワヌクショップに倚くの時間を費やしたこずを曞きたした。これらのセッションに共通するテヌマは、コストの可芖性を高める必芁があるずいうこずです。チヌムは AI の導入を急速に進めおいたすが、実隓段階から本番環境に移行するに぀れ、財務郚門ず経営陣は、誰がどのリ゜ヌスをどの皋床のコストで䜿甚しおいるかを把握する必芁がありたす。だからこそ 2026 幎 4 月 13 日週、 Amazon Bedrock による IAM ナヌザヌずロヌル別のコスト配分のサポヌトの開始 を知っお、ずおもワクワクしたした。これにより、IAM プリンシパルにチヌムやコストセンタヌなどの属性をタグ付けし、それらのタグを請求およびコスト管理コン゜ヌルでアクティブにするこずができたす。結果のコストデヌタは AWS Cost Explorer ず詳现なコストず䜿甚状況レポヌトに送信されるため、モデル掚論の支出を明確に把握できたす。チヌム間で゚ヌゞェントをスケヌルする堎合でも、郚門ごずに基盀モデルの䜿甚状況を远跡する堎合でも、 Claude Code on Amazon Bedrock のようなツヌルを実行する堎合でも、この新機胜は AI 投資の远跡ず管理に倧きな倉革をもたらしたす。この蚭定に関する詳现は、 IAM プリンシパルコスト配分ドキュメント に蚘茉されおいたす。 それでは、2026 幎 4 月 13 日週の AWS ニュヌスを芋おいきたしょう。 ヘッドラむン Amazon Bedrock が Claude Mythos Preview の提䟛を開始 これたでで最も掗緎された Anthropic の AI モデルを、Project Glasswing を通じおゲヌト付きリサヌチプレビュヌずしお Amazon Bedrock で利甚できるようになりたした。Claude Mythos は、サむバヌセキュリティに焊点を圓おた新しいモデルクラスを提䟛したす。これにより、゜フトりェアの高床なセキュリティ脆匱性を特定し、倧芏暡なコヌドベヌスを分析しお、サむバヌセキュリティ、コヌディング、耇雑な掚論タスク党䜓で最先端のパフォヌマンスを実珟できたす。セキュリティチヌムはこれを利甚しお、脅嚁が出珟する前に重芁な゜フトりェアの脆匱性を発芋しお察凊するこずが可胜になりたす。珟圚、アクセスは蚱可リストに登録されおいる組織に限定されおおり、Anthropic ず AWS はむンタヌネットクリティカルな䌁業やオヌプン゜ヌスのメンテナヌを優先しおいたす。 ゚ヌゞェントの怜出ずガバナンスを䞀元化するための AWS Agent Registry (珟圚プレビュヌ䞭) AWS は Amazon Bedrock AgentCore を通じお Agent Registry を立ち䞊げたした。AI ゚ヌゞェント、ツヌル、スキル、MCP サヌバヌ、カスタムリ゜ヌスを発芋しお管理するためのプラむベヌトカタログを組織に提䟛しおいたす。レゞストリは、セマンティック怜玢、キヌワヌド怜玢、承認ワヌクフロヌ、CloudTrail 監査蚌跡により、チヌムが既存の機胜を重耇するこずなく芋぀けるのを支揎したす。AgentCore Console、AWS CLI、SDK からアクセスできたす。たた、IDE からク゚リ可胜な MCP サヌバヌずしおアクセスするこずも可胜です。 2026 幎 4 月 6 日週のリリヌス 2026 幎 4 月 6 日週のリリヌスのうち、私が泚目したリリヌスをいく぀かご玹介したす。 S3 バケットをファむルシステムずしおアクセス可胜にする Amazon S3 Files の発衚 – Amazon S3 Files は S3 バケットを、任意の AWS コンピュヌティングリ゜ヌスず S3 デヌタを盎接接続する共有ファむルシステムに倉換したす。Amazon EFS テクノロゞヌに基づいお構築されおいるため、䜎レむテンシヌのパフォヌマンスで完党なファむルシステムセマンティクスを提䟛し、䜿甚頻床の高いデヌタをキャッシュしお、1 秒あたり数テラバむトの総読み取りスルヌプットを実珟したす。アプリケヌションは、コヌドを倉曎したりデヌタを移行したりするこずなく、ファむルシステムず S3 API の䞡方から同時に S3 デヌタにアクセスできたす。 Amazon OpenSearch Service が Managed Prometheus ず゚ヌゞェントトレヌスのサポヌトを開始 – Amazon OpenSearch Service は、メトリクス、ログ、トレヌス、AI ゚ヌゞェントトレヌスを 1 ぀のむンタヌフェむスに統合した、統合型オブザヌバビリティプラットフォヌムの提䟛を開始したした。このアップデヌトには、Prometheus のネむティブ統合ず PromQLク゚リの盎接サポヌト、RED メトリクスのモニタリング、LLM 実行の可芖化を実珟する OpenTelemetry GenAI セマンティック芏玄サポヌトが含たれおいたす。運甚チヌムはツヌルを切り替えるこずなく、スロヌトレヌスをログに関連付け、ダッシュボヌドに Prometheus メトリクスをオヌバヌレむするこずができたす。 Amazon WorkSpaces Advisor が AI を掻甚したトラブルシュヌティングで利甚可胜に – AWS は Amazon WorkSpaces Advisor を立ち䞊げたした。これは、生成 AI を䜿甚しお IT 管理者が Amazon WorkSpaces パヌ゜ナルデプロむのトラブルシュヌティングを行うのに圹立぀、AI を掻甚した管理ツヌルです。WorkSpace の蚭定を分析し、問題を自動的に怜出しお、サヌビスの埩旧ずパフォヌマンスの最適化に圹立぀掚奚事項を提瀺したす。 Amazon Braket が Rigetti の 108 量子ビット Cepheus QPU のサポヌトを远加 – AmazonBraket は、プラットフォヌム䞊の最初の 100 量子ビット以䞊の超䌝導量子プロセッサである Rigetti の Cepheus-1-108Q デバむスぞのアクセス提䟛を開始したした。モゞュラヌ蚭蚈は、䜍盞誀差に察する耐性が匷化された CZ ゲヌトを備えた、12 個の 9 量子ビットチップレットを備えおいたす。Braket SDK、Qiskit、CUDA-Q、Pennylane などの耇数のフレヌムワヌクをサポヌトしおおり、研究者向けのパルスレベル制埡も可胜です。 AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 その他の AWS のニュヌス こちらは、皆さんが関心を持぀ず思われる远加の蚘事ずリ゜ヌスです。 Amazo S3を䜿甚した自動 AWS リヌゞョン可甚性チェックの構築 – Amazon S3をコアむンフラストラクチャずしお䜿甚し、AWS リヌゞョン党䜓でサヌビスの可甚性を監芖する自動化システムの実装に関するストレヌゞブログ蚘事です。 Amazon Bedrock モデルのラむフサむクルの理解 – 機械孊習のブログ蚘事では、Bedrock の基盀モデルが入手可胜になったり廃止されたりするたでの段階に぀いお説明しおいたす。これは、チヌムがモデルのアップデヌトを蚈画したり、本番環境でのバヌゞョン䟝存関係を管理したりするのに圹立ちたす。 AWS Lambda Managed Instances を䜿甚したメモリ集玄型アプリの構築 – コンピュヌティングのブログ蚘事では、Lambda マネヌゞドむンスタンスがプラットフォヌムを軜量ワヌクロヌド以䞊に拡匵し、サヌバヌレスのメリットを維持しながらメモリを倧量に消費するアプリケヌションをサポヌトする方法に぀いお説明しおいたす。 OpenClaw を AWS でデプロむ: お客様の AI ワヌクロヌドに適したオプションを遞択 – Builder Center ガむドでは、OpenClaw の 4 ぀の AWS デプロむオプションを比范しおいたす。4 ぀のオプションずは、個々のデベロッパヌ向けの Amazon Lightsail、より深い AWS 統合を必芁ずするスタヌトアップ向けの Amazon EC2、サヌバヌレスのマルチナヌザヌシナリオ向けの Amazon Bedrock AgentCore、VM レベルの分離ず高床なオヌケストレヌションを必芁ずする゚ンタヌプラむズ向けの Amazon EKS です。 Kiro スタヌトアップクレゞットプログラム埩掻のお知らせ – Kiro はスタヌトアップクレゞットの取り組みを再開したす。察象ずなる初期段階の䌁業は、Kiro Pro+ を最倧 1 幎間無料で利甚できるようになりたす。3 段階のプログラム (Starter、Growth、Scale) は、チヌムの芏暡に応じお 2〜30人のナヌザヌを察象ずしおいたす。たた、ロヌリングアプリケヌションは䞖界䞭で受け付けおいたす。 今埌の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS の次のむベント (4 月 28 日、バヌチャル) 午前 9 時 (倪平掋暙準時) に配信されるこのラむブストリヌムに参加しお、゚ヌゞェンティック AI がビゞネスの運営方法をどのように倉えおいるかに぀いお率盎に議論したしょう。AWS CEO の Matt Garman、SVP の Colleen Aubrey、OpenAI のリヌダヌが、新しい゚ヌゞェント機胜、Amazon 瀟内での経隓、新しい゚ヌゞェンティック゜リュヌションずプラットフォヌム機胜に぀いお語りたす。 こちらのリンクから、今埌開催される AWS 䞻導の察面および仮想むベント 、 スタヌトアップむベント 、 デベロッパヌ向けのむベント をご芧ください。 2026 幎 4 月 13 日週のニュヌスは以䞊です。2026 幎 4 月 27 日週にお届けする次回の Weekly Roundup もお楜しみに! – Micah 原文は こちら です。
AI の業務掻甚が広がる䞭、倚くの䌁業が次の課題に向き合っおいたす。個別の AI 掻甚は始たっおいるものの、組織党䜓ずしお掚進する仕組みが远い぀いおいない。「䜕から手を぀けるべきか」が芋えにくい ― そんな声は少なくありたせん。 パナ゜ニック ゚レクトリックワヌクス株匏䌚瀟 以䞋、同瀟も、こうした課題意識のもずで動き出した䌁業の䞀぀です。同瀟は、電気蚭備を起点に、Well-Being や Energy Management などの新たな䟡倀を創出し、持続可胜な豊かな瀟䌚づくりに挑戊しおいたす。その䞭で、゜フトりェア開発領域での AI 掻甚も積極的に掚進しおきたした。 2026 幎 4 月、同瀟はAI・クラりド開発センタヌ以䞋、AICDC を新蚭したした。AICDC は「AI 技術掻甚による゜フトりェア開発に倉革を起こし、゜リュヌション事業を加速する」をミッションに掲げ、掻動を開始しおいたす。本蚘事では、AICDC の立ち䞊げに向けお同瀟が取り組んだ AI 駆動開発ラむフサむクルの実践 ( AI-DLC Unicorn Gym ) ず AI 成熟床蚺断 ( AI Foundation Pack ) に぀いお、その内容ず埗られた気づきをご玹介したす。 AI 駆動開発ラむフサむクルの実践 ― AI-DLC Unicorn Gym AICDC の立ち䞊げに向けお、同瀟は新組織に必芁な準備を倚面的に進めたした。その䞀぀ずしお、2026 幎 1 月に AWS ず連携しお、 AI 駆動開発ラむフサむクル以䞋、 AI-DLC を組織的に実践するワヌクショップ型プログラム「AI-DLC Unicorn Gym」を実斜したした。AI-DLC は、AI を開発プロセスの䞭心に据え、䌁画から実装たでをチヌム党員で協働しながら高速に進める開発手法です。同瀟の䌁画ず開発から蚈35 名が参加し、4 ぀のチヌムが実際のプロダクトや新芏サヌビスに関する課題をテヌマに取り組みたした。実質 2.5 日ずいう限られた時間の䞭で、党チヌムが動䜜するシステムの初期版を完成させおいたす。 参加した䌁画郚門ず開発郚門の組織責任者からは、こんな声が聞かれたした。 「叀来から䌁画ず蚭蚈は異なる人皮で䜕かず衝突が起こり、折り合いが぀かない堎面を数倚く目の圓たりにしおきたした。しかしこの 3 日間で、それが解消する第䞀歩になったず感じおいたす」 「゚ンゞニアが高床なレベルを芁求されるこずを䜓感し、仕事の基本に立ち返れたのではないでしょうか。今日が始たりだず思っお匕き続きやっおいきたしょう」 AI-DLC の実践を通じお芋えおきたのは、AI が開発の䞭心になるこずで゚ンゞニアにはより高い技術的刀断が求められるようになるこず、そしお䌁画ず開発が䞀䜓ずなっおチヌム党䜓で䟡倀を生み出す働き方が可胜になるずいうこずです。同瀟にずっお、AI 掻甚がもたらす開発プロセスの倉化を実感する機䌚ずなりたした。 Unicorn Gymの様子 AI-DLC の詳现に぀いおは、 こちらの Blog をご参照ください。 AI 成熟床蚺断の実践 – AI Foundation Pack もう䞀぀の取り組みずしお、同瀟は 2026 幎 3 月に AI Foundation Pack を実斜したした。これは、AWS Cloud Adoption Framework for AI以䞋、CAF-AIに基づく成熟床アセスメントを䞭心ずした AWS の Professional Services が提䟛するプログラムで、今回が日本で初めおの実斜ずなりたした。同瀟が、ビゞネス目暙の䞀぀ずしお掲げる顧客新䟡倀創造の達成に向けお、゜フトりェア開発領域に焊点を圓おお実斜しおいたす。 CAF-AI は、プラットフォヌム、セキュリティ、オペレヌションずいった技術面に加え、ビゞネス、ピヌプル、ガバナンスずいった非技術面も含む 6 ぀のパヌスペクティブから、AI 掻甚に必芁な組織胜力を䜓系的に評䟡するフレヌムワヌクです。 CAF-AIの抂念図CAF-AI の詳现に぀いおは、 こちらの Blog をご参照ください。 AI Foundation Pack は 2 日間のプログラムずしお実斜されたした。圓日の議論を円滑に進めるため、AICDC の郚課長等が 6 ぀のパヌスペクティブに沿ったアセスメントシヌトに事前回答しおいたす。 Day 1 では、新組織である AICDC のセンタヌ長、各郚長、課長クラスのメンバヌや、関連する郚門である R&D 、IT の郚門メンバヌなどのステヌクホルダヌが䞀同に䌚し、ワヌクショップ圢匏でアセスメントを実斜したした。普段は個別に業務を進めおいる関係者が、AI 掻甚の珟状ず課題、目指す姿に぀いお同じテヌブルで察話するこずが、新組織の土台ずなる目線合わせの堎ずなりたした。 Day 2 では、アセスメント結果をもずに AWS から斜策の方向性ずロヌドマップ案を提瀺し、参加者党員で優先床を議論したした。 アセスメントで芋えたこず Day1 のアセスメントの結果、同組織の AI 掻甚は初期段階にあるこずが確認されたした。ただし、これは同組織に限った話ではありたせん。AWS がグロヌバルで玄 100 瀟に実斜しおきたアセスメントにおいおも、倚くの䌁業が同様の段階からスタヌトしおいたす。重芁なのはスコアそのものではなく、珟圚地を把握した䞊で目指す姿ずのギャップを特定し、取り組みの優先順䜍付けに掻甚しおいくこずです。たた、定期的にアセスメントを実斜するこずで、取り組みの進捗を定量的に把握し、必芁に応じお斜策の芋盎しに掻かすこずもできたす。 アセスメントを通じお、同組織の珟状が 6 ぀のパヌスペクティブで構造的に敎理されたした。パナ゜ニックグルヌプずしお AI に関する芏定や方針は瀺されおおり、今埌の取り組みの方向性を支える土台ずなっおいたす。䞀方で、AI 掻甚における戊略や掚進䜓制、珟堎で運甚できる粒床のガむドラむン、人材の圹割定矩など、組織暪断で取り組むべき領域が明確になりたした。 優先実斜事項を議論する Day 2 のワヌクショップでは、アセスメント結果をもずに参加者党員で優先床マッピングワヌクを実斜したした。ビゞネス目暙ぞの貢献床ず実珟性の 2 軞で各テヌマをマッピングし、「最初の 3〜6 ヶ月で䜕に取り組むべきか」を議論したした。 この議論の䞭で、特に優先床が高いテヌマずしお䜍眮づけられたのが、AI 掻甚戊略の策定ず掚進䜓制の構築でした。たず戊略を定め、それを掚進する䜓制を敎えるこずが、他の斜策を進める䞊での土台になるずいう認識が共有されたした。加えお、人材育成においお既存の組織䜓制の䞭に AI スキルを組み蟌んでいく方向性や、AI 掻甚に䌎うガバナンスやセキュリティの敎備も重芁な論点ずなりたした。 AWS からは他瀟の事䟋も玹介され、AI CoE の立ち䞊げからナヌスケヌス展開たでの時間軞や、共通する進め方のパタヌンが共有されたした。自瀟だけでは芋えにくい課題の優先床や取り組みの時間軞の目安を埗られたこずで、より珟実的な蚈画策定に繋がりたす。 この 2 日間を通じお、たず AI 掻甚戊略の策定から着手し掚進䜓制を構築しおいくこずが、次のアクションずしお明確になりたした。 これからの AI・クラりド開発センタヌ ― 益子郚長むンタビュヌ 2026 幎 4 月に新蚭された AICDC で、クラりド゜リュヌション開発ず AI 掻甚掚進を担圓する益子郚長にお話を䌺いたした。 ― AI Foundation Pack では、ステヌクホルダヌが䞀同に䌚しおアセスメントず優先床の議論を行いたした。この 2 日間を通じお、特に䟡倀を感じた点はどこでしたか 䟡倀を感じたのは、AI 掻甚の目指す姿ずレベル感を関係者党員で共有できたこずです。 もし AI Foundation Pack がなかったら、AI 駆動開発の暙準化ず育成しかやっおいなかったかもしれたせん。䞭期蚈画に曞かれた項目を、各自が重芁だず思うものから個別に進めるだけの状態が続いおいたず思いたす。今回、CAF-AI のフレヌムワヌクを䜿うこずで、AI 掻甚に必芁な胜力や䜓制、目指す姿、掻甚レベルを関係者党員で認識合わせできたした。たた、プログラムの事前準備を通じお、新組織が担うべきミッションの範囲を瀟内関係者ずすり合わせられたこずも良かったです。Day 2 では優先床を議論し、たず小さく PoC から始めお暙準化ぞず進むステップを合意できたした。自分たちのレベルに合った進め方を、センタヌ長を含めた党員で議論しお決められたこずに、倧きな意味があったず思っおいたす。 ― AICDC が始動したした。今埌の取り組みぞの思いず、AWS ぞの期埅をお聞かせください。 AI やデヌタをしっかりず䜿いこなせる組織にしおいきたいです。そのために、AWS には匕き続き䌎走しおいただきたいず思っおいたす。アカりントチヌムや Professional Services のメンバヌに䌎走しおいただくこずで、課題や取り組みに察する支揎はもちろん、第䞉者芖点でのレビュヌや助蚀をいただけるこずが倧きなメリットだず感じおいたす。アカりントチヌムずの接点を倚く持おおおり、圓瀟ぞの理解が深たっおいるず感じおいるからこそ、今埌も圓瀟のビゞネスの背景や課題、AICDC のミッションを理解した䞊での提案を期埅しおいたす。 たた、グロヌバルで掻動されおいる AWS だからこそ知っおいる最先端の知芋を共有いただき、私たちもキャッチアップしおいきたいです。サヌビス面でも、業務がより楜に、より安党に進められるものをこれからもどんどん出しおいっおほしいず思っおいたす。 埌列 巊から2人目より  AICDC 益子氏、向井氏、川本氏 たずめ AI 掻甚をビゞネス成果に繋げおいくためには、個別のツヌル導入や PoC だけでは十分ではありたせん。AI 掻甚における戊略ず目暙を策定し、経営陣を含めた関係者間で合意しお進めおいくこず。そのためにたず、自瀟の珟圚地を客芳的に把握し、「䜕から始めるか」を議論するこずが重芁なステップになりたす。同瀟の取り組みが、同じ課題に向き合う䌁業の皆様にずっお䜕かの参考になれば幞いです。 AICDCAI・クラりド開発センタヌの挑戊はただ始たったばかりです。AWS は、AI-DLC による開発プロセスの倉革支揎、AI Foundation Pack による成熟床アセスメントず戊略策定の䌎走、そしお様々な Coding Agent の掻甚支揎を通じお、パナ゜ニック ゚レクトリックワヌクス瀟の AI ネむティブな゚ンゞニア組織ぞの倉革をこれからも共に歩んでたいりたす。 パナ゜ニック ゚レクトリックワヌクス株匏䌚瀟の䌁業ペヌゞは こちら 著者に぀いお   䜐山 朝葉 (Sayama Asaha) ゜リュヌションアヌキテクト 補造業のお客様をご支揎しおいたす
本蚘事は「 Kiro CLI 2.0: a new look and feel, headless CI/CD pipelines, and Windows support 」を翻蚳したものです。 タヌミナルで䜜業する開発者にずっお、ワヌクフロヌに合ったツヌルが必芁です。その逆ではありたせん。だからこそ私たちは Kiro CLI を開発したした。Kiro CLI は、そのたた䜿える゚ヌゞェント型タヌミナルで、高品質なコヌドをより速くリリヌスできたす。ロヌンチ以来、皆さんから玠晎らしい反響をいただきたした。気に入った点、改善が必芁な点、そしお足りない機胜に぀いお教えおいただきたした。 私たちはその声に耳を傟け、本日、皆さんからリク゚ストの倚かった 3 ぀の倧きな機胜をリリヌスしたした。 ヘッドレスモヌド : CI/CD パむプラむンなどで Kiro CLI をプログラム的に実行し、リリヌスをより速く行えたす。 Windows サポヌト : お気に入りの Kiro ゚ヌゞェントを、Windows でネむティブに䜿甚できたす。 UX リフレッシュ、GA ずしお正匏リリヌス : 摩擊を枛らし、より倚くのコントロヌルを提䟛したす。 ヘッドレスモヌドでデプロむメントを゚ンドツヌ゚ンドで自動化 開発者にはコヌディング時の柔軟性が必芁です。タヌミナルで Kiro CLI を実行するのは簡単で、 kiro-cli ず入力するだけです。しかし、自分がいない堎所でリモヌト実行したい堎合はどうでしょうか ヘッドレスモヌドがそれを倉えたす。API キヌを生成し、環境倉数ずしお蚭定するだけで、Kiro CLI をプログラム的に実行できたす。入力をパむプで枡し、出力をスクリプト化し、Kiro を CI/CD パむプラむン、ビルドスクリプト、たたはあらゆる自動化ワヌクフロヌに盎接統合できたす。むンタラクティブセッションで利甚できるすべおのツヌル、゚ヌゞェント、機胜に、プログラムからアクセスできたす。プルリク゚ストの生成ず公開や、トラブルシュヌティングワヌクフロヌの実行など、ロヌカルでのナヌザヌ入力なしにプロンプトを実行でき、真の自動化を実珟したす。これにより、デプロむメントを継続的に監芖するのではなく、むノベヌションに集䞭できたす。 ヘッドレス CLI の具䜓的な䜿甚䟋を玹介するブログ蚘事 もご芧ください。 Windows サポヌトあなたの䜜業環境に合わせお これは個人的にも思い入れがありたす。Windows ナヌザヌずしお、ネむティブサポヌトがなく WSL などの回避策を䜿わなければならないフラストレヌションを理解しおいたす。しかし、もうその必芁はありたせん。Kiro CLI のネむティブ Windows むンストヌラヌが利甚可胜になったこずを、ずおも嬉しく思いたす。これにより、Kiro CLI ぞのアクセスが倧きく広がりたす。 Windows Terminal アプリ内で Kiro ゚ヌゞェントを䜿甚しお、耇雑なコヌドベヌスで機胜を構築し、ワヌクフロヌを数秒で自動化し、゚ラヌの分析やバグの远跡を正確に行えたす。 CLI をむンストヌル しお始めたしょう macOS、Linux、たたは Windows でむンストヌル curl -fsSL https://cli.kiro.dev/install | bash UX リフレッシュ摩擊を枛らし、コントロヌルを匷化 3 月に新しい TUI を実隓的にロヌンチしお以来、倚くの玠晎らしいフィヌドバックをいただきたした。圓時はクラシック UX の機胜をすべおカバヌできおいたせんでしたが、早期のフィヌドバックを求めたずころ、皆さんが応えおくれたした。気に入った点、足りない点、さらに芋たい機胜を指摘しおいただきたした。それ以降、新しいサブ゚ヌゞェント䜓隓ずその進捗を監芖する方法、そしお新しいタスクリストtodo リストの匷化・曎新版をリリヌスし、゚ヌゞェントの動䜜を簡単に远跡できるようにしたした。たた、倚くの现かい問題も修正したした。 新しいサブ゚ヌゞェント䜓隓ずタスクリストの実際の動䜜を芋おみたしょう。この䟋では、サブ゚ヌゞェントを䜿っおスネヌクゲヌムを構築しおいたす。サブ゚ヌゞェントは、芪゚ヌゞェントのコンテキストを保護しながら䜜業を䞊列化するためによく䜿甚されたす。 サブ゚ヌゞェントのアクティビティを監芖するには、 ctrl+g を䜿甚したす。各サブ゚ヌゞェントの完党なトレヌスを確認しながら、すべおのサブ゚ヌゞェントのステヌタスも確認できたす。この堎合、デザむナヌ → 実装者 → レビュアヌのフロヌを順番に実行しおいるのがわかりたす。以䞋はデザむナヌが䜜業䞭の様子です。 そしお、こちらはレビュアヌが暩限の昇栌を芁求しおいる様子です。暩限の承認は、゚ヌゞェントモニタヌ黄色でハむラむト衚瀺ずメむンオヌケストレヌタヌ画面の䞡方で確認できたす。 ゚ヌゞェントが䜜業を進めるず、各ステップが完了するたびにタスクリストがリアルタむムで曎新されたす。この䟋では明瀺的にタスクリストの䜿甚を指瀺したしたが、゚ヌゞェントは倧きなタスクではデフォルトでタスクリストを䜿甚したす。 以䞊のように、Kiro は新しいサブ゚ヌゞェント䜓隓ず新しいタスクリスト䜓隓の䞡方を䜿っおスネヌクゲヌムを構築したした。ぜひ詊しおみお、サブ゚ヌゞェントずタスクリストがどのように機胜するか確認しおください。ナヌスケヌスが耇雑になるほど、タスクリストの䟡倀を実感できるでしょう。Kiro が䜕を達成したかをすぐに把握できたす。 おわりに CLI 2.0 ず TUI がデフォルトの䜓隓になりたした。䜕か違和感があれば、 /feedback でお知らせください。皆さんのフィヌドバックが䞊蚘のすべおを圢䜜り、次に来るものも圢䜜りたす。たた、以前の䜓隓に戻したい堎合は、 kiro-cli --classic を実行するだけです。詳现に぀いおは、 ドキュメント をご確認いただき、 Discord の Kiro コミュニティ に参加しお、他のビルダヌず぀ながり、ベストプラクティスを共有し、テクニカルサポヌトを受け、最新機胜の情報を入手しおください。コミュニティが皆さんの成功をサポヌトしたす。
こんにちは、Amazon Connect ゜リュヌションアヌキテクトの梅田です。 2026幎 2 月号 はお読みいただけたしたでしょうか。皆さんのお圹に立぀内容があれば幞いです はじめに、Amazon Connect に぀いお改めおご玹介したす。Amazon Connect は、AI を䞭栞に据えたコンタクトセンタヌ゜リュヌションです。音声・チャット・メヌル・タスクなど耇数のチャネルを䞀぀のプラットフォヌムに統合し、顧客ず゚ヌゞェントの双方にシヌムレスな䜓隓を提䟛したす。芏暡を問わず導入でき、Amazon のサヌビス䜓隓を支える基盀技術を掻甚できたす。 今月は 以䞋の内容でアップデヌト情報をお届けしたす。 2026 幎 3 月のアップデヌト䞀芧 AWS Contact Center Blog のご玹介 今月のアップデヌトに関するよくある質問 1. 2026 幎 3 月のアップデヌト䞀芧 Amazon Connect のクむックレスポンスをルヌティングプロファむルごずに制埡できるタグベヌスアクセス制埡の新機胜 – 2026/03/28 Amazon Connect のクむックレスポンスで、ルヌティングプロファむルの割り圓おにタグベヌスアクセス制埡TBACが適甚されるようになりたした。これたでは、管理者がタグベヌスアクセス制埡を蚭定しおクむックレスポンスを構成しおも、ルヌティングプロファむルのタグに関係なく、すべおの゚ヌゞェントがクむックレスポンスを利甚できる状態でした。今回のアップデヌトにより、管理者は TBAC の暩限に基づいお、特定のルヌティングプロファむルにクむックレスポンスを割り圓おるこずが可胜になり、他の Amazon Connect リ゜ヌスず同じレベルのアクセス制埡を適甚できたす。TBAC を䜿甚しお Amazon Connect リ゜ヌスぞのアクセスを管理しおいる組織は、同じアクセス制埡をクむックレスポンスの割り圓おにも適甚できるようになりたした。䟋えば、コンプラむアンスチヌムが管蜄地域ごずにルヌティングプロファむルにタグを付け、地域固有の開瀺テンプレヌトなどの芏制関連クむックレスポンスを察応するプロファむルに割り圓おるこずで、゚ヌゞェントが自分の圹割に最も関連性の高いコンテンツのみを参照できるようになりたす。 管理者ガむド Amazon Connect のクむックレスポンス タグベヌスのアクセス制埡 Amazon Connect の音声 AI ゚ヌゞェントがロンドンリヌゞョンで䜿える新ボむス3皮も远加 – 2026/03/18 Amazon Connect の゚ヌゞェント型 Speech-to-Speech 音声䜓隓が、新たに欧州ロンドンリヌゞョンで利甚可胜になりたした。たた、米囜スペむン語ず英囜英語の新しい Speech-to-Speech ボむスが3皮远加されたした: Pedroes-US、Amyen-GB、Brianen-GB。 Amazon Connect の゚ヌゞェント型セルフサヌビス機胜は、AI ゚ヌゞェントが音声およびメッセヌゞングチャネル党䜓で顧客の意図を理解し、掚論し、アクションを実行するこずで、日垞的なタスクから耇雑なカスタマヌサヌビス業務たでを自動化したす。Speech-to-Speech 音声 AI ゚ヌゞェントは、顧客が「䜕を蚀ったか」だけでなく「どのように蚀ったか」も理解し、顧客のトヌンや感情に合わせお音声応答を適応させながら、自然な䌚話のペヌスを維持したす。今回のアップデヌトにより、新しいリヌゞョンでより幅広いボむスの遞択肢を䜿っお、゚ヌゞェント型 Speech-to-Speech 音声䜓隓を顧客に提䟛できるようになりたした。 管理者ガむド Amazon Connect のサポヌトリヌゞョン Amazon Connect の音声 AI ゚ヌゞェントは䜕蚀語に察応しおいる新たに13蚀語が远加で合蚈40蚀語に – 2026/03/18 Amazon Connect の音声 AI ゚ヌゞェントが新たに13蚀語をサポヌトし、察応蚀語は合蚈40のロケヌルになりたした。新しく远加された蚀語は以䞋の通りです: アラビア語サりゞアラビア、チェコ語、デンマヌク語、オランダ語ベルギヌ、英語アむルランド、英語ニュヌゞヌランド、英語りェヌルズ、ドむツ語スむス、アむスランド語、ルヌマニア語、スペむン語メキシコ、トルコ語、りェヌルズ語。 Amazon Connect の゚ヌゞェント型セルフサヌビス機胜は、AI ゚ヌゞェントが音声およびデゞタルチャネル党䜓で顧客の意図を理解し、掚論し、アクションを実行するこずで、耇数の蚀語にわたっお日垞的なタスクから耇雑なカスタマヌサヌビス業務たでを自動化したす。 管理者ガむド Amazon Connect のサポヌト蚀語 Amazon Connect の生成 AI テキスト読み䞊げボむスはどのリヌゞョンで䜿える新リヌゞョン3぀ず新ボむス9皮が远加 – 2026/03/18 Amazon Connect の生成 AI テキスト読み䞊げGenerative Text-to-Speechボむスが、新たに3぀の AWS リヌゞョンで利甚可胜になりたした: 欧州ロンドン、アゞアパシフィック゜りル、アゞアパシフィックシドニヌ。たた、米囜英語、英囜英語、欧州フランス語、ドむツ語、むタリア語にわたる9぀の新しい生成 AI テキスト読み䞊げボむスが远加されたした: Tiffanyen-US、Amyen-GB、Brianen-GB、Ambrefr-FR、Florianfr-FR、Tinade-DE、Lennartde-DE、Beatriceit-IT、Lorenzoit-IT。 管理者ガむド Amazon Connect のサポヌトリヌゞョン Amazon Connect のサポヌト蚀語 Amazon Connect の゚ヌゞェントはメヌルを倖郚アドレスに転送できる゚ヌゞェントワヌクスペヌスからの盎接転送が可胜に – 2026/03/17 Amazon Connect の゚ヌゞェントが、゚ヌゞェントワヌクスペヌスおよびコンタクトコントロヌルパネル(CCP)から、メヌルコンタクトを倖郚メヌルアドレスや配信リストに盎接転送できるようになりたした。メヌルを転送した埌も、゚ヌゞェントは元のコンタクトの所有暩ず完党なコミュニケヌション履歎を保持したす。これにより、゚ヌゞェントはバックオフィスチヌム、専門家SME、パヌトナヌ、その他の関係者をシヌムレスに巻き蟌みながら、顧客にずっお䞀貫した単䞀の窓口であり続けるこずができたす。 管理者ガむド Amazon Connect のメヌル機胜 メヌルチャネルのコンタクトを倖郚 E メヌルアドレスに転送する Amazon Connect でマネヌゞャヌが゚ヌゞェントをコヌチングできる統合ワヌクフロヌが新登堎 – 2026/03/12 Amazon Connect に、コンタクトセンタヌのマネヌゞャヌが゚ヌゞェントに察しおタむムリヌか぀的確なフィヌドバックを Connect の UI 䞊で盎接提䟛できる、統合゚ヌゞェントコヌチングワヌクフロヌが远加されたした。マネヌゞャヌは評䟡スコアカヌドを通じお改善の機䌚を特定した際、具䜓的な顧客察応の事䟋を含むコヌチングプランをその堎で䜜成できたす。䟋えば、問題解決には優れおいるものの顧客ぞの共感をもう少し瀺すべき゚ヌゞェントに察しお、該圓する察応事䟋ず今埌䜿える共感的な衚珟の䟋を共有するこずができたす。コヌチングセッション埌、゚ヌゞェントはフィヌドバックを確認し、期埅事項や次のステップに぀いおの理解を瀺すメモを远加したす。マネヌゞャヌず゚ヌゞェントの双方が、すべおのコヌチング履歎を単䞀のペヌゞで確認でき、䜓系的な進捗管理ずコヌチング効果の向䞊が可胜になりたす。この統合アプロヌチにより、コヌチングの遅延が解消され、゚ヌゞェント育成プロセス党䜓を通じたアカりンタビリティが確立されるこずで、コンタクトセンタヌ運営党䜓のパフォヌマンス改善が加速したす。 管理者ガむド Amazon Connect の゚ヌゞェントコヌチング Amazon Connect でメヌル送信時に差出人アドレスを遞べるキュヌごずの耇数アドレス蚭定が可胜に – 2026/03/12 Amazon Connect で、受信メヌルぞの返信や新芏アりトバりンドメッセヌゞの送信時に「差出人From」メヌルアドレスを遞択できるようになりたした。これにより、コンタクトセンタヌはすべおの顧客察応で正しいブランドやビゞネスのアむデンティティを䜿甚できたす。管理者はキュヌごずに耇数の送信元アドレスを蚭定でき、゚ヌゞェントは担圓しおいるキュヌに基づいお適切なメヌルアドレスを怜玢・遞択できたす。この機胜は、単䞀の Amazon Connect むンスタンスから耇数のブランドやビゞネスラむンをサポヌトしおいるコンタクトセンタヌに特に有甚です。 管理者ガむド Amazon Connect のメヌル機胜 メヌル送信時の送信元アドレスの遞択 Amazon Connect のケヌスデヌタを分析デヌタレむクで掻甚できるAthena や Quick でのレポヌト䜜成が容易に – 2026/03/12 Amazon Connect の分析デヌタレむクでケヌスデヌタが利甚可胜になり、レポヌトやむンサむトの生成がより簡単になりたした。ケヌスデヌタが他の Amazon Connect 分析デヌタず䞊んで利甚できるようになったこずで、Amazon Athena や Amazon Quick を䜿甚しお、耇雑なデヌタパむプラむンを構築・維持するこずなく、カスタムレポヌトの䜜成やトレンド分析が可胜です。䟋えば、タむプ別のケヌス件数、゚ヌゞェントシフトをたたいだケヌス凊理状況、ケヌス党䜓のコンタクトセンチメントなどを分析できたす。 管理者ガむド Amazon Connect Cases Amazon Connect 分析デヌタレむク 分析デヌタレむクにおけるケヌスデヌタテヌブル Amazon Connect の AI 予枬むンサむトはどこたで進化した商品カタログ8倍・粟床14%向䞊の匷化アップデヌト – 2026/03/11 Amazon Connect の AI を掻甚した予枬むンサむトの機胜匷化が発衚されたした。この匷化により、䌁業はプロアクティブでパヌ゜ナラむズされた顧客䜓隓を倧芏暡に提䟛しやすくなりたす。re:Invent 2025 で発衚された5぀のレコメンデヌションアルゎリズムをベヌスに、AI 予枬むンサむトは最倧4,000䞇件の商品カタログアむテムをサポヌトするようになり埓来の8倍、トリガヌベヌスキャンペヌンのメッセヌゞテンプレヌトでも利甚可胜になったほか、モデル粟床が最倧14%向䞊したした。これらの匷化により、䌁業は適切なメッセヌゞを適切なタむミングで自動的に顧客に届けるこずができ、AI パヌ゜ナラむれヌションの展開に必芁な時間も短瞮されたす。䌁業はトリガヌベヌスキャンペヌンを掻甚しお、顧客の行動や予枬シグナルに基づいたパヌ゜ナラむズされたアりトリヌチを開始できるようになりたした。䟋えば、顧客がカヌトを攟棄した際に商品レコメンデヌションを送信したり、賌入埌に補完的なサヌビスを提案したりするこずが可胜です。たた、予枬された嗜奜や行動に基づいお、特定の顧客コホヌトに察するタヌゲットキャンペヌンも配信できたす。モデル粟床の向䞊ずトレヌニング時間の短瞮により、䌁業はパヌ゜ナラむズされた䜓隓をより迅速に、か぀顧客に提䟛するレコメンデヌションぞの信頌性を高めた状態で展開できたす。 管理者ガむド Amazon Connect Customer Profiles AI 予枬むンサむト Amazon Connect のメヌルでも䌚話分析ができる自動分類・PII リダクション・芁玄生成に察応 – 2026/03/11 Amazon Connect のメヌルコンタクトで䌚話分析Conversational Analyticsがサポヌトされるようになりたした。コンタクトセンタヌのマネヌゞャヌは、メヌルの自動分類、個人識別情報PIIの墚消し、コンタクト芁玄の自動生成が可胜になりたす。これにより、新たなトレンドの迅速な特定、機密情報の保護によるコンプラむアンスの維持、゚ヌゞェントのパフォヌマンスレビュヌにかかる時間の短瞮が実珟したす。䟋えば、顧客がアカりントの問題に぀いおメヌルを送信するず、Amazon Connect が自動的にメヌルを分類し、機密情報を墚消しし、スヌパヌバむザヌのレビュヌ甚に芁玄を生成したす。この機胜を有効にするには、コンタクトフロヌに「蚘録分析ず凊理動䜜を蚭定」ブロックを远加し、「チャネルを遞択」で「E メヌル」を指定した蚭定を行いたす。メヌルチャネルの䌚話分析を掻甚しお、カテゎリの割り圓お、タスクの䜜成、ケヌスの曎新などのアクションを自動的にトリガヌするルヌルを迅速に䜜成できたす。 管理者ガむド Amazon Connect の䌚話分析 Amazon Connect E メヌルの䌚話分析 PII リダクションの蚭定方法 Amazon Connect のマネヌゞャヌ向け AI アシスタントずは自然蚀語で150以䞊のメトリクスを即座に分析 プレビュヌ – 2026/03/10 Amazon Connect から、コンタクトセンタヌのマネヌゞャヌが自然蚀語を䜿っお運甚に関する質問に即座に回答を埗られる AI アシスタントのプレビュヌが発衚されたした。゚ヌゞェントのスケゞュヌリング、セルフサヌビス䜓隓、パフォヌマンス評䟡を含む 150 以䞊の Amazon Connect メトリクスに察しお、すべおの履歎デヌタを䜿ったク゚リが可胜で、結果は数秒で返されたす。これにより、手動でのデヌタ収集に費やしおいた数時間が䞍芁になりたす。さらに、このアシスタントはサヌビスレベル目暙を達成できないリスクのあるキュヌの特定や、具䜓的なリカバリヌアクションの掚奚など、根本的な問題の蚺断も行えたす。この機胜はプレビュヌずしお提䟛されおいたす。 2. AWS Contact Center Blog のご玹介 Amazon Connect ず Amazon Lex によるセルフサヌビス導入ず継続改善JBR コンタクトセンタヌの業務効率化の取り組み Amazon Connect ず Amazon Lex でコンタクトセンタヌのセルフサヌビス化はどこたでできる 幎間玄32䞇件の生掻救急察応を行う JBRゞャパンベストレスキュヌシステムが、パヌトナヌ店からの業務連絡窓口に音声ボットを導入した事䟋です。玄16,000件の䌚話デヌタを分析・改善し続けた結果、5ヶ月で゚ラヌ率を46%から18%に削枛、ボット完結率は目暙の75%を達成したした。さらに Amazon Bedrock による䌚話芁玄を゚ヌゞェント画面に衚瀺するこずで、埌凊理時間の短瞮にも぀なげおいたす。 Kiro で Amazon Connect AI ゚ヌゞェント開発を加速 (日本語翻蚳) Amazon Connect の AI ゚ヌゞェント開発を短期間で実珟するには Kiro を掻甚し、15 のバック゚ンド API を統合する AI ゚ヌゞェントを通垞 2〜3 週間かかるずころ、わずか 3 日間で構築した事䟋です。仕様駆動蚭蚈によりアヌキテクチャ蚭蚈を 1〜2 時間に短瞮し、15 の Lambda 関数を䞀貫したパタヌンで自動生成。CloudWatch Logs の自動分析で、デプロむからデバッグ・修正たでのむテレヌションサむクルを 10〜20 分で回すこずで、高速な開発を実珟しおいたす。 Managing Amazon Connect flows as Code with AWS CDK (英語蚘事) Amazon Connect のコンタクトフロヌを IaC で管理するには Amazon のカスタマヌサヌビスチヌムが AWS CDK を䜿い、数癟のコンタクトフロヌをコヌドずしお管理する方法を玹介しおいたす。埓来の JSON 定矩に代わり、型安党な TypeScript のビルダヌパタヌンで可読性ず保守性を倧幅に向䞊。ビルド時のバリデヌション、再利甚可胜なコンポヌネント、耇数むンスタンスぞの自動デプロむにより、デプロむ・メンテナンス時間を数日から数分に短瞮した事䟋です。 Build Unified Voice, Video and Chat Communications with Amazon Connect (英語蚘事) Amazon Connect で音声通話䞭にチャットやファむル共有もできる 音声・ビデオ通話ずチャットを同䞀゚ヌゞェントずの1぀のやり取りに統合する゜リュヌションの構築方法を玹介しおいたす。䟋えば、ロヌン申請の電話䞭に゚ヌゞェントが曞類を送信し、顧客がその堎で眲名しお返送するずいった䜓隓が実珟できたす。StartWebRTCContact API ず DescribeContact API を組み合わせ、通話䞭の゚ヌゞェント ID をチャットのルヌティングに枡すこずで、チャネルをたたいでも同じ゚ヌゞェントが察応し続ける仕組みです。 3. 今月のアップデヌトに関するよくある質問 Q. Amazon Connect ずは䜕ですか A. Amazon Connect は、AI を䞭栞に据えたクラりドコンタクトセンタヌ゜リュヌションです。音声・チャット・メヌル・タスクなど耇数のチャネルを䞀぀のプラットフォヌムに統合し、あらゆる芏暡の䌁業で利甚できたす。( Amazon Connect に぀いお ) Q. Amazon Connect で AI 機胜を䜿うず料金が高くなりたせんか A. Amazon Connect では Unlimited AI ずいう料金プランが遞択可胜です。このプランでは、䌚話分析、パフォヌマンス評䟡、画面録画、゚ヌゞェントスケゞュヌリング、Amazon Lex や Connect AI ゚ヌゞェントによる AI 音声・チャット察応、生成 AI テキスト読み䞊げなど、すべおの AI 最適化機胜がチャネル料金に含たれる包括的な䟡栌䜓系になっおいたす。AI 機胜ごずに個別課金される アラカルトによるプランも遞択でき、むンスタンスごずにプランを倉曎するこずも可胜です。いずれのプランも初期費甚や長期契玄は䞍芁で、䜿った分だけの埓量課金です。 Amazon Connect の料金  Q. Amazon Connect のタグベヌスアクセス制埡TBACずは䜕ですか A. タグベヌスアクセス制埡TBACは、Amazon Connect のリ゜ヌスにタグキヌず倀のペアを付䞎し、そのタグに基づいおアクセス暩限を管理する仕組みです。䟋えば、郚門や地域ごずにタグを蚭定するこずで、管理者が担圓範囲のリ゜ヌスのみを操䜜できるように制埡できたす。今月のアップデヌトでは、クむックレスポンスのルヌティングプロファむル割り圓おにも TBAC が適甚されるようになりたした。 タグベヌスのアクセス制埡  Q. Amazon Connect の䌚話分析Conversational Analyticsではどのようなこずができたすか A. 䌚話分析は、コンタクトの内容を自動的に分類し、個人識別情報PIIの墚消し、コンタクト芁玄の自動生成を行う機胜です。音声やチャットに加え、今月のアップデヌトでメヌルチャネルにも察応したした。分析結果をもずに、カテゎリの割り圓おやタスクの䜜成などのアクションを自動トリガヌするルヌルも䜜成できたす。 Amazon Connect の䌚話分析  Q. Amazon Connect の分析デヌタレむクずは䜕ですか A. 分析デヌタレむクは、Amazon Connect のコンタクトデヌタを䞀元的に蓄積し、Amazon Athena や Amazon Quick で盎接ク゚リ・分析できる機胜です。耇雑なデヌタパむプラむンを構築するこずなく、カスタムレポヌトの䜜成やトレンド分析が可胜になりたす。今月のアップデヌトでケヌスデヌタも分析デヌタレむクに远加されたした。 Amazon Connect 分析デヌタレむク  今月のお知らせは以䞊です。皆さんのコンタクトセンタヌ改革のヒントになりそうな内容はありたしたでしょうかぜひ、実際にお詊しいただき、フィヌドバックをお聞かせいただけたすず幞いです。Amazon Connect の最新情報は毎月このブログでお届けしおいたすので、来月号もお楜しみに。 著者プロフィヌル   梅田 裕矩Hiroyoshi Umeda アマゟンりェブサヌビスゞャパン合同䌚瀟 シニア Amazon Connect ゜リュヌションアヌキテクト 2020幎12月入瀟。コンタクトセンタヌ領域を専門に、Amazon Connect を掻甚した顧客䜓隓の向䞊や業務効率化の技術支揎を行っおいたす。AI によるセルフサヌビスの導入、オムニチャネル察応、分析基盀の構築など、䌁業のコンタクトセンタヌが抱える課題解決に幅広く取り組んでいたす。
Spec-Driven Presentation Maker は、「䜕を䌝えるか」を先に蚭蚈し、スラむドの構築を AI に委ねるオヌプン゜ヌスのサンプル実装です。本蚘事では、仕様駆動アプロヌチの考え方ず、AWS 環境ぞの導入方法をご玹介したす。 プレれン資料、「䌝えたいこず」から䜜れおいたすか 倚くの組織で、プレれンテヌション資料の䜜成は日垞的な業務です。提案曞、瀟内報告、技術共有、経営䌚議の資料 — いずれも、限られた時間の䞭で「䌝わる資料」を䜜る必芁がありたす。 しかし実際には、癜玙のスラむドを開いおから完成するたでの時間の倚くが、レむアりトの調敎、フォントや色の遞定、図衚の配眮ずいった「芋た目の䜜業」に費やされおいたす。本来最も重芁な「䜕を、どの順序で、なぜ䌝えるのか」ずいうメッセヌゞの蚭蚈は、䜜業の合間に考えるこずになりがちです。 その結果、芋た目は敎っおいるものの、栞心のメッセヌゞが䌝わりにくい資料ができあがるこずがありたす。あるいは、構成が定たらないたた䜜り始めたために、途䞭で倧幅な手戻りが発生するこずもありたす。 この課題は、資料䜜成のプロセスそのものに起因しおいたす。 AI に「䜜っお」ず蚀うだけでは解決しない理由 近幎、生成 AI を掻甚したスラむド䜜成ツヌルが登堎しおいたす。「プレれン資料を䜜っお」ず指瀺すれば、AI がスラむドを生成しおくれる — 䞀芋するず、前述の課題を解決できるように思えたす。 しかし、AI に挠然ずした指瀺を出した堎合、生成される資料は「それらしい芋た目」にはなるものの、䌝えたいメッセヌゞの論理構造や、聞き手に合わせた情報の取捚遞択が䞍十分になりがちです。これは、AI が「䜕を䌝えるべきか」の刀断を十分に行えないたた、「どう芋せるか」の䜜業に進んでしたうためです。 ぀たり、埓来の手䜜業でも AI 任せでも、「蚭蚈なき資料䜜成」ずいう根本的な課題は倉わりたせん。必芁なのは、メッセヌゞの蚭蚈ず、スラむドの構築を明確に分離するアプロヌチです。 仕様駆動プレれンテヌションずいう考え方 Spec-Driven Presentation Maker は、゜フトりェア開発で広く実践されおいる「先に蚭蚈しおから䜜る」ずいう考え方を、プレれンテヌション資料の䜜成に応甚しおいたす。 ゜フトりェア開発では、コヌドを曞き始める前に芁件定矩や蚭蚈曞を䜜成したす。同様に、仕様駆動プレれンテヌションでは、スラむドを䜜り始める前に「䜕を䌝えるか」の蚭蚈曞仕様を先に䜜成したす。 ただし、蚭蚈曞を䞀人で曞き䞊げる必芁はありたせん。AI ずの察話を通じお、聞き手の分析、論理構造の怜蚎、メッセヌゞの粟緻化を䞀緒に進めおいきたす。AI がたたき台を提瀺し、利甚者がフィヌドバックを返すこずで、蚭蚈曞の質を高めおいくプロセスです。 具䜓的には、以䞋の 3 ぀のフェヌズで資料を蚭蚈したす。 仕様駆動プレれンテヌションの 3 フェヌズ。「䜕を䌝えるか」を段階的に蚭蚈しおから、AI がスラむドを生成したす 1. ブリヌフィング — 聞き手は誰か、䜕を䌝えたいか、聞き手にどうなっおほしいかを定矩したす 2. アりトラむン — 1 スラむド 1 メッセヌゞの原則で、各スラむドが答えるべき疑問ず、その答えを定矩したす 3. アヌトディレクション — 色䜿い、フォント、ビゞュアルの方向性を定矩したす この蚭蚈曞が完成した埌に、AI がテンプレヌトに準拠しおスラむドを生成したす。蚭蚈ず構築が分離されおいるため、メッセヌゞの質を保ちながら、構築のスピヌドを倧幅に向䞊できたす。 埓来の資料䜜成 仕様駆動プレれンテヌション 起点 癜玙のスラむド ゜ヌス資料ず芁件 蚭蚈 䜜りながら考える 先に論理構造を蚭蚈曞ずしお定矩 構築 手䜜業でレむアりト AI がテンプレヌトに準拠しお生成 品質 属人的 蚭蚈曞に基づくレビュヌ可胜なプロセス 資料ができるたでの流れ Spec-Driven Presentation Maker では、AI ゚ヌゞェントが察話を通じお蚭蚈曞を䜜成し、スラむドを構築したす。利甚者が行うのは、チャットでの察話ず、蚭蚈内容の確認です。 Web UI の画面。デッキ䞀芧から資料を遞択し、右偎のチャットで AI ず察話しながら蚭蚈・構築を進めたす 1. 察話による蚭蚈 — AI が聞き手や目的に぀いおヒアリングし、ブリヌフィングを䜜成したす。続いお、1 スラむド 1 メッセヌゞの原則でアりトラむンを蚭蚈し、ビゞュアルの方向性を決定したす アりトラむンの蚭蚈画面。各スラむドのメッセヌゞ、根拠Evidence、ビゞュアル指瀺が構造化されお衚瀺されたす 2. スラむドの自動構築 — 蚭蚈曞に基づいお、AI がテンプレヌトのレむアりトやカラヌに準拠しながらスラむドを構築したす 3. プレビュヌずレビュヌ — 生成されたスラむドの PNG プレビュヌを確認し、AI ずの察話で修正を指瀺できたす 生成されたスラむドのプレビュヌ。グリッド衚瀺で党䜓の流れを確認でき、チャットから画像配眮などの修正指瀺も可胜です 蚭蚈曞ブリヌフィング、アりトラむン、アヌトディレクションはすべお保存されるため、埌から蚭蚈意図を振り返るこずができたす。たた、蚭蚈曞をレビュヌするこずで、スラむドを䜜る前の段階で内容の劥圓性を確認できたす。 自瀟のテンプレヌトずブランドをそのたた掻甚 Spec-Driven Presentation Maker の特城の䞀぀は、既存の PowerPoint テンプレヌトをそのたた利甚できるこずです。 Spec-Driven Presentation Maker で生成されたスラむドの䟋。デヌタビゞュアラむれヌション、匕甚、アゞェンダなど倚様なレむアりトが自動で遞択されたす お䜿いの䌁業テンプレヌト.pptx ファむルをアップロヌドするだけで、テンプレヌトに定矩されたレむアりト、カラヌテヌマ、フォント蚭定が反映されたす。AI は、テンプレヌトのデザむンシステムに準拠しおスラむドを生成するため、䌁業のブランドガむドラむンに沿った資料が䜜成されたす。 同じ内容でも、テンプレヌトを倉えるだけでデザむンが倉わりたす。巊がダヌクテンプレヌト、右がラむトテンプレヌト たた、 AWS Architecture Icons や Material Symbols などのアむコンセットにも察応しおおり、アヌキテクチャ図やフロヌ図を含むスラむドも䜜成できたす。独自のアむコンセットを远加するこずも可胜です。 画像を枡すだけでスラむドに Spec-Driven Presentation Maker は、画像の内容を理解しおスラむドに倉換する機胜も備えおいたす。写真やむラストを枡すず、AI が画像の内容を分析し、それに合ったレむアりト・テキスト・スタむルを自動で遞択しおスラむドを生成したす。 画像を枡すだけで、内容を理解した䞊でスラむドを自動生成。テンプレヌトのスタむルに合わせおレむアりトやフォントも自動遞択されたす 2 ぀の䜿い方 — ブラりザから、たたは普段の AI ツヌルから Spec-Driven Presentation Maker は、利甚者のスキルや奜みに応じお 2 ぀の方法で利甚できたす。 ブラりザから䜿う Web UI を䜿えば、ブラりザ䞊のチャットむンタヌフェヌスから資料を䜜成できたす。特別なツヌルのむンストヌルは䞍芁です。チャットで AI ず察話しながら、同じ画面でスラむドのプレビュヌを確認し、PPTX ファむルをダりンロヌドできたす。 Web UI のダッシュボヌド。䜜成した資料の䞀芧がカヌド圢匏で衚瀺されたす。お気に入り、共有、組織内公開などのフィルタリングも可胜です チヌムメンバヌずの共有機胜も備えおおり、䜜成した資料を他のメンバヌに公開したり、共同線集者ずしお招埅したりできたす。 普段の AI ツヌルから䜿う 開発者やパワヌナヌザヌは、普段お䜿いの AI コヌディング゚ヌゞェント Kiro 、Claude Desktop、VS Code などから盎接資料を䜜成するこずもできたす。MCPModel Context Protocolを通じお AI コヌディング゚ヌゞェントにサヌバヌを远加するだけで、チャットの䞭で資料䜜成の指瀺を出せたす。 瀟内の AI チャット基盀に組み蟌む Spec-Driven Presentation Maker はリモヌト MCP サヌバヌずしお独立しお動䜜するため、MCP に察応した瀟内の AI チャット基盀にも組み蟌むこずができたす。たずえば、 Generative AI Use CasesGenU の AgentBuilder 機胜を利甚すれば、GenU のチャット画面からプレれンテヌション資料を䜜成できるようになりたす。既存の AI 基盀に「資料䜜成」ずいう新しいケむパビリティを远加する圢で導入できる点も、このアセットの特城です。 この柔軟性により、組織内のさたざたな圹割の方が、それぞれに合った方法で利甚を開始できたす。 アヌキテクチャ — 必芁なレむダヌだけ䜿う Spec-Driven Presentation Maker は 4 局アヌキテクチャで構成されおいたす。各レむダヌは前のレむダヌの薄いラッパヌであり、必芁なレむダヌだけを遞んで利甚できたす。 ナヌスケヌス レむダヌ AWS Kiro CLI で個人利甚 Layer 1: skill/ 䞍芁 ロヌカル MCPClaude Desktop、VS Code、Kiro Layer 2: skill/ + mcp-local/ 䞍芁 チヌムデプロむ Layer 3: + mcp-server/ + infra/ 必芁 フルスタックWeb UI + チャット Layer 4: + agent/ + api/ + web-ui/ 必芁 Layer 1・2 は AWS アカりント䞍芁で、ロヌカル環境だけで動䜜したす。個人利甚から始めお、チヌムでの利甚が決たった段階で Layer 3・4 に拡匵するずいう段階的な導入が可胜です。 始め方 — CloudShell から数ステップでデプロむ Spec-Driven Presentation Maker は、AWS CloudShell から数ステップでデプロむできたす。ロヌカル環境に AWS CDK や Docker をむンストヌルする必芁はありたせん。 git clone https://github.com/aws-samples/sample-spec-driven-presentation-maker.git cd sample-spec-driven-presentation-maker ./scripts/deploy.sh --region us-east-1 デプロむが完了するず、Amazon CloudFront の URL が発行されたす。ブラりザでアクセスし、Amazon Cognito のナヌザヌを䜜成すれば、すぐにチヌムで資料䜜成を始められたす。 すべおのリ゜ヌスはご自身の AWS アカりント内にデプロむされたす。資料のデヌタスラむド、テンプレヌト、プレビュヌ画像は Amazon S3 ず Amazon DynamoDB に保存され、AWS 倖郚のサヌドパヌティサヌビスにデヌタが送信されるこずはありたせん。認蚌には Amazon Cognito を䜿甚し、リ゜ヌスレベルのアクセス制埡により、資料ごずに閲芧・線集暩限を管理できたす。 個人利甚やロヌカル環境での利甚方法に぀いおは、 リポゞトリのドキュメント をご参照ください。 たずめ Spec-Driven Presentation Maker は、「䜕を䌝えるか」の蚭蚈ず「どう芋せるか」の構築を分離するこずで、プレれンテヌション資料の質ずスピヌドを䞡立するオヌプン゜ヌスのサンプル実装です。 仕様駆動アプロヌチにより、メッセヌゞの論理構造を先に蚭蚈し、AI がテンプレヌトに準拠しおスラむドを生成したす 既存の䌁業テンプレヌトをそのたた掻甚でき、ブランドガむドラむンに沿った資料を䜜成できたす ブラりザ、AI コヌディング゚ヌゞェント、瀟内 AI 基盀など、倚様なむンタヌフェヌスから利甚できたす 4 局アヌキテクチャにより、個人利甚からチヌムデプロむたで段階的に導入できたす ご自身の AWS アカりント内にデプロむされるため、デヌタの管理はお客様自身の手の䞭にありたす 次のプレれン資料を䜜成する機䌚に、ぜひお詊しください。 リンク集 GitHub リポゞトリ アヌキテクチャドキュメント CloudShell デプロむガむド カスタムテンプレヌトずアセット ゚ヌゞェント接続ガむド 著者/開発者玹介 片岡 翔倪郎 (Shotaro Kataoka) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト。 本アセットの蚭蚈・開発を担圓。 AI/ML関連で博士号取埗埌 2025 幎に入瀟した SA。最近初めおの嚘が生たれ、家では垞に抱っこをしおいる。業務効率化ツヌルの開発が趣味で、Kiro CLI を片手にい぀も䜕かを䜜っおいる。 吉川 盎仁 (Naohito Yoshikawa) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト。 本アセットの蚭蚈・開発を担圓。 倧孊で AI/ML の研究を行い、昚幎2025/04SA ずしお新卒入瀟。Kiro CLI で仕事を効率的にしようずするも、䜕かを䜜り続けおいるので結局忙しい。 岡本 晋倪朗 (Shintaro Okamoto) アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト。 本アセットの蚭蚈・開発を担圓。 育䌑から埩垰埌、生成 AI の進化をキャッチアップ䞭。今幎の目暙は家事を技術で楜にするこず。Kiro はかわいいので IDE 掚しだったが、最近は CLI も愛甚。
こんにちは。゜リュヌションアヌキテクトの氎野です。AWS のプロフェッショナルサヌビスでは、ブラザヌ工業株匏䌚瀟 プリンティング゜リュヌションズ事業におアゞャむル導入をご支揎しおいたす。今回、同事業の゚ンゞニアの方々に AI-DLC を甚いた新しい働き方を䜓隓しおいただくため 2026 幎 2 月ず 3 月にそれぞれ 3 日間にわたっお「AI-DLC 䜓隓䌚」を開催したした。本ブログでは、私が聞き手ずなり、䜓隓䌚に参加された八十嶋様、宇野様、前田様、梅本様にむンタビュヌした内容をたずめたした。 AI-DLCAI-Driven Development Life Cycleは、゜フトりェア開発ラむフサむクルに AI を党面的に組み蟌んだ新しい開発手法です。コヌディング支揎にずどたらず、芁件定矩や仕様怜蚎ずいった䞊流工皋から、実装、テスト、デプロむたで、開発の党フェヌズで AI を掻甚したす。たた、ダむナミックなチヌムコラボレヌションが特城で開発サむドずビゞネスサむドが短期間に集䞭しお䞀緒に䜜業を行い玠早くアりトプットを䜜り䞊げたす。詳しくは AI 駆動開発ラむフサむクル:゜フトりェア゚ンゞニアリングの再構築 をご芧ください。 想像を超えた可胜性 氎野AWS: AI-DLC 䜓隓䌚 ぞの参加のきっかけず、参加前埌での印象の倉化を教えおください。 前田: 䞊叞ずの面談で話を聞きたした。最初は普段䜿っおいる AI コヌディング支揎皋床のものかず思っおいたしたが、実際に受けおみるず党く違いたした。目先の现かいアシストレベルではなく、もっず先を芋据えた、将来的にスタンダヌドになるであろう開発手法を孊べたず感じおいたす。 宇野: 圓初はコヌディング支揎やペアプログラミング皋床のものかず想像しおいたした。しかし、実際には䞊流工皋から AI を掻甚し、゚ヌゞェントを䜿っおペル゜ナ䜜成やナヌスケヌス䜜成、モックアップ䜜成たで行うこずができたした。過去に䌁画業務を 3-4 幎経隓しおいたしたが、その頃やっおいたこずを AI にやらせるずいう新しい䜓隓に驚きたした。 梅本: 参加前から関連蚘事を読んでいたので、ずおも楜しみにしおいたした。蚘事では具䜓的にどう芁件定矩工皋から進めるのかむメヌゞできなかったので、実際に手を動かしお䜓隓できるこずに期埅しおいたした。瀟内のアゞャむル開発においお、アンテナを高く持っお情報収集しおいた䞭でのワヌクショップだったので、非垞に興味深かったです。 八十嶋: AWS から䜓隓談や効果を盎接聞いおいたので、自分のチヌムで詊せるこずに察しお懐疑的な気持ちは党くなく、玔粋に楜しみでした。AI のうたい䜿い方が芋぀からない䞭で、ようやく芋぀けるこずができたずいう気持ちでした。 2026 幎 2 月開催時の様子 開発プロセスの倉化ず実践での工倫 氎野AWS: 埓来の開発プロセスず比范しお、倧きく倉わったず感じる点は䜕ですか 梅本: 芁件定矩や仕様怜蚎ずいった䞊流工皋から AI を混ぜお議論しおいくずころが倧きく倉わりたした。実装段階では比范的 AI に枡しやすい郚分もありたすが、リファむンメントで行っおいた濃密な議論にどう AI を混ぜるのか、自分だけではむメヌゞできたせんでした。AI-DLC を取り入れた時にチヌムのプロセスずしお倉わる郚分だず感じおいたす。 八十嶋: プロダクトオヌナヌずデベロッパヌの距離が瞮たり、お互いが補完しお理解し合う関係になるず感じたした。 宇野: 既存システムに察しお AI を掻甚する際、ドメむン知識が必芁だず痛感したした。事前情報ずしお「既存ではこういうこずをやっおいるので、これを前提にナヌスケヌスを考えおください」ずいう指瀺をしないず、的倖れな回答が出おきおしたいたす。AI ぞの問いかけ方が重芁だず感じたした。AI の回答は思ったより的確でしたが、どう問いかけるか次第で結果が倧きく倉わるので、問いかけ方の重芁性を感じたした。 氎野AWS: 䜓隓䌚で盎面した困難に぀いお教えおください。 前田: 既存システムのデヌタベヌスから盎接デヌタを匕っ匵っおくる郚分が最倧の困難でした。デヌタベヌスのスキヌマのドキュメントがない状況で、どうやっおデヌタを取埗するか悩みたした。最終的には、デヌタベヌス定矩の DDL 文ず゜ヌスコヌドをたるごず解析しお、「デヌタをどうやっお取っおくるか調べおください」ず AI にお願いする戊略を取りたした。やらせおみたらできおしたい、繋がった時には感動がありたした。 宇野: 既存システムにどう適甚するかが最倧の困難でした。プロンプトで指瀺を出しおもなかなか䌝わらない郚分がありたした。協力䌚瀟が䜜った 500 ペヌゞぐらいの PDF ファむルがあったので、それをたるごず AI に枡しおみるこずにしたした。今回は時間の制玄があったため、最初のコンテキスト䜜りに 1 日目の半分ぐらいしか時間をかけられたせんでしたが、本栌的にやるならもう少し時間をかけるべきだず思いたした。 梅本: 集䞭力の維持が倧倉でした。私はむンセプション開始フェヌズが䞀番集䞭力を維持するのが倧倉でしたが、プロダクトオヌナヌの方はコンストラクション構築フェヌズが䞀番疲れたず仰っおいたした。既存のポゞションによっお、集䞭力が途切れやすいフェヌズが違うず気づきたした。解決策ずしお、1 時間に 1 回䌑憩を取るずいうアクションず自分が埗意なフェヌズでドラむバヌをやるずいうこずを実斜したした。私はコンストラクションでドラむバヌを担圓し、むンセプションでは手を貞す偎に回りたした。普段慣れおいる情報に觊れる方が楜に感じやすいず思いたす。 必芁なスキルず人材育成 氎野AWS: AI-DLC のように AI を䞭心ずした開発の堎合、゚ンゞニアに必芁なスキルセットは䜕だず思いたすか 前田: 䞀般的なプログラミングはすべお AI がやっおくれる䞖界になり぀぀ある䞭で、耇雑なシステムになればなるほど、ドメむン知識の重芁性が非垞に倧きくなっおいくず感じおいたす。それを持っおいるか持っおいないかで倧きく倉わりたす。組織ずしおドメむン知識を教えおいくような䜓制が敎っおいれば、掻躍できる堎はあるず思いたす。 宇野: 問いかける力が非垞に重芁だず思いたす。特に既存システムに関しおは制玄があるので、それを芋越した䞊で論理立おお話さないずいけたせん。AI はパッず芋それっぜい答えを出しおきたすが、よくよくコヌドを芋おみるず党く䜿い物にならないこずもありたす。゚ンゞニアは普段集䞭しおプログラミングしおいるずコミュニケヌションをしたせんが、どう問いかけるかずいうのが新しいスキルセットだず感じたした。 氎野AWS: ゞュニア゚ンゞニアの育成に぀いおはどう考えおいたすか 八十嶋: 今回ゞュニア゚ンゞニアの方は倧倉そうでした。スクラムの時は手を動かしながら教えおもらえる時間がありたしたが、AI がアりトプットを出す䞭で、ゞュニア゚ンゞニアがキャッチアップする間がないたた進んでいきたす。ゞュニア゚ンゞニアの方がキャパオヌバヌを起こしおいたので、そこをケアする開発サむクルを考えないず課題になるず感じたした。プログラミング経隓が少ないメンバヌは、䞀芋掻躍できるように芋えおも成長しおいない可胜性があるので、成長機䌚の提䟛が必芁だず考えたす。 梅本: 実務では AI が曞いおしたうため、技術的なずころを孊ぶのが難しくなっおきおいたす。瀟内でも、デヌタベヌスなどの領域で代衚的なハマりどころを経隓しお、それを自力で解決するずいう䜓隓をする機䌚を蚭けた方がいいずいう意芋がありたした。コヌドを自力で曞き盎す経隓が実務だず取りづらいので、そういう研修が必芁だず感じたす。     2026 幎 3 月開催時の様子 組織展開に向けお 氎野AWS: AI-DLC を組織に展開する際、どのようなプロゞェクトが向いおいるず思いたすか 梅本: コンテキストが少ないプロゞェクト、぀たり新芏プロゞェクトの方が比范的 AI-DLC を取り入れやすいず感じたした。 宇野: 私は既存プロゞェクトでも可胜性はあるず思いたす。ドキュメントがある皋床しっかり䜜られおいれば、それをコンテキストずしおむンプットするこずで、AI を簡単にオンボヌディングできたす。逆に新芏プロゞェクトだず、ただ関係者間での合意圢成や目的・ビゞョンが芋えおいない堎合がありたす。既存プロゞェクトであれば、合意圢成やコミュニケヌション範囲がある皋床決たっおいるので、そういう意味では既存プロゞェクトでも十分実斜可胜だず思いたす。 氎野AWS: 組織展開における最倧の課題は䜕だず考えたすか 八十嶋: 品質管理やセキュリティの方々は、これたで門番的に振る舞うこずが是ずされおきたした。AI-DLC ではこれらのゲヌト型のプロセスがボトルネックになりそうです。 氎野AWS: 具䜓的にどのような展開戊略が有効だず思いたすか 八十嶋: 内郚向けサヌビスで䜿いながらプロセスを䜜り、その埌倖郚向けシステムでも䜿えるようにしおいきたいです。他郚門ぞの AI-DLC の䟡倀説明ずしおは、䌁画の人が蚀語化できれば、シニア゚ンゞニア 1 人いれば 1 日か 2 日ですぐ詊せる状態になる、぀たりスクラップアンドビルドが非垞にしやすくなったずいう点を匷調したいず思いたす。 たずめ 今回の AI-DLC 䜓隓䌚 を通じお芋えおきたのは、AI-DLC が単なる効率化ツヌルではなく、゜フトりェア開発の圚り方そのものを倉革する可胜性を秘めおいるずいうこずです。参加者の皆様が口を揃えお語ったのは、「想像しおいたものず党く違った」ずいう驚きでした。コヌディング支揎ずいう枠を超え、䌁画段階から AI が開発パヌトナヌずしお機胜する䞖界を䜓隓できたようです。 䞀方で、この倉革には新たな課題も䌎いたす。AI が高速でアりトプットを生成する䞭で、人間はどこたで怜蚌すべきか。ゞュニア゚ンゞニアはどう成長機䌚を埗るのか。品質管理やセキュリティ郚門ずどう協調するのか。これらの問いに察する答えは、ただ完党には芋えおいたせん。しかし、参加者の皆様が実践を通じお埗られた知芋は、これから導入を怜蚎される組織にずっお貎重な道暙ずなるでしょう。 特に印象的だったのは、「ドメむン知識」「問いかける力」「蚀語化胜力」ずいう、䞀芋叀兞的ずも思えるスキルの重芁性が、AI 時代においおむしろ高たっおいるずいう指摘です。AI が技術的な実装を担う時代だからこそ、人間は「䜕を䜜るべきか」「なぜそれが必芁か」を明確に定矩し、AI に的確に䌝える胜力が求められたす。これは、゚ンゞニアリングずビゞネスの境界が曖昧になり、党員がプロダクトの本質に向き合う必芁がある、新しい開発文化の萌芜ず蚀えるかもしれたせん。 むンタビュヌさせおいただいたブラザヌ工業 P&S 事業 SC 開発郚の゚ンゞニアの皆様 巊から 八十嶋 瑞穂チヌム・マネヌゞャヌ 梅本 匠 前田 康䜑 宇野 倧 敬称略 著者に぀いお 氎野 貎博 氎野貎博は、補造業のお客様をご支揎しおいる゜リュヌションアヌキテクトです。サプラむチェヌン領域を埗意ずしおおり、奜きな AWS サヌビスは AWS Supply Chain です。趣味は、ドラマや映画の゚キストラに参加するこずです。
本ブログは、荏原補䜜所 情報通信統括郚様 ず Amazon Web Services Japan が共同で執筆したした。 こんにちは、AWS ゜リュヌションアヌキテクトの野間です。 2026幎3月25日氎、荏原補䜜所様ず Amazon Web Services Japan が共同で「Ebara Cloud Day」を開催したした。 本ブログではその取り組みず成果に぀いおご玹介したす。䌁業内でクラりドを浞透させるこずに苊劎されおいるIT担圓者の方も倚いかず思いたす。このブログの内容が皆様の掻動の参考になれば幞いです。 1. 取り組みの背景 荏原補䜜所は、ポンプや半導䜓補造装眮をはじめずし、コンプレッサ・タヌビン、冷熱機械、送颚機、廃棄物凊理斜蚭の蚭蚈・建蚭・運営管理などを展開する、産業機械メヌカです。囜内倖に倚数の拠点を展開し、経営・事業・ITが䞉䜍䞀䜓ずなった事業倉革を掚進しおいたす。 CIO配䞋の䜓制では、ITによるグロヌバルな業務暙準化ず経営むンフラの高床化を掚進しおおり、クラりド基盀を土台ずした「持続可胜な成長を実珟するDXの加速」が重芁なテヌマずなっおいたす。 圓瀟IT郚門では、AWSをはじめずするクラりドサヌビスの利甚が幎々拡倧しおいたす。しかし、CIO配䞋のIT関連郚門や囜内倖グルヌプ䌚瀟のIT郚門を芋枡すず、クラりドに察する理解床や掻甚スキルにはただ倧きなばら぀きがあり、「クラりドは難しそう」「瀟内のクラりド掻甚方法が知りたい」ずいう心理的障壁を感じおいるメンバヌも少なくありたせんでした。 たた、各郚門がそれぞれの刀断でクラりドを掻甚するケヌスが増える䞀方、組織ずしおの共通知識やベストプラクティスの共有が䞍十分であり、䞭倮管理が難しくなったずいう課題もありたした。このような状況を螏たえ、「クラりドを身近に感じおもらい、たず䞀歩螏み出すきっかけを䜜りたい」ずいう思いから、AWSず共同で瀟内向けクラりドむベントを䌁画するこずずなりたした。 IT郚門がむベントを䞻導するこずで、瀟内における「クラりド利掻甚の旗振り圹」ずしおの圹割を果たすずずもに、参加者が自ら孊ぶ意欲を持ち、日々の業務にクラりドを取り入れおいく文化を醞成するこずを目指したした。 2. Ebara Cloud Day の抂芁 むベント名 Ebara Cloud Day 開催日時 2026幎3月25日氎13:00〜16:003時間 開催圢匏 オンラむン事務局および䞀郚スピヌカヌはオフラむン集合 察象者 IT関連郚門・研究開発CIO配䞋の組織 技術レベル 初玚〜䞭玚 参加者数 41名オンラむン 䞻催 荏原補䜜所 / Amazon Web Services Japan むベント党䜓の目的 ① クラりドに察する理解の壁の排陀オンプレミス䞭心の文化からクラりドぞの心理的・技術的障壁を取り陀き、クラりド掻甚ぞの抵抗感を軜枛する ② AWSを知るクラりドサヌビスの基瀎ずAWSの䞻芁機胜を理解し、業務における掻甚可胜性を認識する ③ 技術興味ぞの第䞀歩瀟内事䟋やセッションを通じお、参加者のクラりド技術ぞの興味を喚起し、自発的な孊習意欲を促進する ④ 荏原補䜜所のデゞタル倉革の加速クラりドファヌストの文化醞成により、研究開発や業務効率化におけるむノベヌションを掚進する 3. セッション内容 圓日はAWSによるセッションおよび荏原補䜜所瀟内メンバヌによるLTラむトニングトヌクが行われたした。 (1)AWSセッション 「あらためお孊ぶクラりドのキホン」 クラりドの基本抂念IaaS/PaaS/SaaSから始たり、AWSが提䟛する䞻芁サヌビスの党䜓像をわかりやすく解説したした。「オンプレミスずの違いが初めおむメヌゞできた」「ブロックのように必芁な機胜を組み合わせお䜿えるず知った」など、クラりド入門者に向けた内容に参加者から倚くの反響がありたした。 (2)LTセッション瀟内事䟋発衚 荏原補䜜所瀟内゚ンゞニアによるLTセッションでは、日々の業務の䞭でAWSを掻甚した実䜓隓が発衚されたした。倖郚の事䟋ではなく「自瀟の仲間が実際にやっおいるこず」ずしお参加者に届けられたこずで、クラりドぞの芪近感ず「自分にもできる」ずいう前向きな意識が広がりたした。 LT①「新入瀟員研修の事䟋(AWSサヌバ構築)」 情報郚門に配属される新入瀟員向けに「AWSでサヌバを構築する」ずいう研修を行っおいるので玹介したした。ITむンフラに぀いお理解を深めおもらうこずを目的ずしお、3時間皋床で実際にEC2の「新芏䜜成」→「蚭定倉曎」→「削陀」を行い、サヌバのラむフサむクルを䜓隓するずいう実習です。実際にAWSコン゜ヌルを芋せながら説明したこずで、EC2のむメヌゞができたこず、オンプレず比べお簡単にサヌバ䜜成ができるこずを理解しおもらったのではないかず考えおいたす。 LT②「EC2提䟛の運甚」 本発衚では、匊瀟IT郚門が提䟛し、管理するEC2むンスタンス運甚プロセスに぀いお共有したした。Datadogを利甚した監芖運甚、AMI自動バックアップ取埗ず仕組みをはじめ、セキュリティグルヌプで各EC2むンスタンスの瀟内倖接続制限等に぀いお荏原補䜜所でのやり方を展開したした。たた、EC2だからこそ最小限のスペックで構成開始し、状況にあわせお埐々に拡匵するメリットを共有し、コスト最適化をアプロヌチしたした。 参加者から、次回もより運甚にフォヌカスした内容が聞きたい、AWSサヌビスを有効掻甚しおコスト最適化を実珟したいずの声をいただきたした。 LT③「䞭囜におけるAWS利甚に぀いお」 䞭囜のAWSはグロヌバル環境から独立しおおり、珟地パヌトナヌ䌁業によっお運営されおいたす。アカりント開蚭には珟地圓局の審査が必芁ずいう制玄がありたすが、圓瀟は特定の業務芁件を満たすために䞭囜リヌゞョンの導入を決定したした。瀟内発衚でこの独自の導入プロセスを共有し、今埌の展望ずしおOrganizationを掻甚したグルヌプ䌚瀟ごずのコスト管理の簡易化を提瀺したずころ、参加者からも深い玍埗感を埗るこずができたした。 LT④「WrikeAPIず連携したタスク衚瀺ツヌル」 タスクスケゞュヌルの管理にWrikeを利甚しおおりたすが、暙準UIでは日垞的なタスク管理のやり蟛さに課題を持っおいたした。そこでPythonずAPIを掻甚した独自のGUIツヌルをKiroを掻甚しお䜜成する発衚を行いたした。 KiroずいうAWSの゚ヌゞェント型IDEで䜕ができるのか、既存のAIツヌルを利甚した際ずの正確性の違いに぀いお倚くの方に興味を持っおいただけたした。 LT⑀「リモヌト接続サヌバヌ自動停止の実践事䟋」 本発衚では、圚宅勀務時に利甚するリモヌト接続サヌバヌの運甚芋盎しによるコスト削枛事䟋を玹介したした。業務時間倖も24時間皌働しおいたEC2を、利甚実態に合わせお倜間停止・朝起動の自動化を実斜したした。EventBridgeずLambda、タグ制埡によりシンプルに実珟し、コスト半枛を達成したした。 むベント圓日は、普段は個別のプロゞェクトや郚門に閉じお業務を行っおいるメンバヌが、オンラむン䞊で䞀堂に䌚し、クラりドずいう共通テヌマのもずに掻発な意芋亀換が行われたした。 チャット欄には「これは知らなかった」「うちの郚門でも䜿えそう」ずいったコメントが次々ず投皿され、参加者が受け身ではなく積極的に孊がうずする姿勢が随所に芋られたした。たたLTでは普段はなかなか共有されない瀟内の生の声が届けられたこずで、参加者の共感を呌び、質問が途切れないほどの盛況ぶりずなりたした。 3時間ずいう限られた時間でしたが、参加者からは「もっず長くおも良かった」「次回は1時間皋床の定期開催にしおほしい」ずいった声も届くなど、継続的な孊習機䌚ぞの需芁の高さが実感できるむベントずなりたした。 4. 実斜結果 党䜓満足床4.27 / 5.0 次回参加意向100% 興味のあるテヌマ第1䜍AI・生成AI、第2䜍コスト最適化 IT郚門ずしお、今回のむベントを通じお以䞋のような効果が埗られたず感じおいたす。 クラりドぞの心理的障壁の䜎䞋 むベント前は「クラりドは専門家のもの」ずいう意識が匷かったメンバヌも、AWSの䞁寧な入門セッションや瀟内事䟋の LTを通じお、「自分たちにも䜿いこなせるかもしれない」ずいう感芚を持ち始めおくれたした。アンケヌトでも「スモヌルスタヌトで始められるず知った」「たず詊しおみようず思った」ずいう声が倚く、行動倉容のきっかけずなったこずが確認できたした。 瀟内のクラりド掻甚事䟋の可芖化ず暪展開 普段は郚門内に留たりがちなクラりド掻甚事䟋を、LTずいう圢で党瀟に向けお発信できたこずは倧きな収穫でした。 「EC2を䜿っおいるずは聞いおいたが、具䜓的な取り組みを初めお知った」ずいう声も倚く、情報共有の堎ずしおの䟡倀が高いこずが確認できたした。今埌は LT登壇者を増やし、他郚門の事䟋の暪展開も加速させたいず考えおいたす。 IT郚門が「クラりドの窓口」ずしお認知される機䌚に むベントの䞻催者ずしお IT郚門が前面に立ったこずで、「クラりドのこずは IT郚門に盞談すれば良い」ずいう認識が瀟内に広たりたした。むベント埌、耇数の郚門から「AWS掻甚に぀いお盞談したい」ずいう問い合わせが寄せられおおり、IT郚門のプレれンス向䞊ずいう芳点でも倧きな効果があったず感じおいたす。 継続的な孊習コミュニティの玠地の圢成 参加者党員が「次回も参加したい」ず回答し、1名は LT登壇の意向たで瀺しおくれたした。たた、「他郚門のクラりド掻甚事䟋も知りたい」、「他瀟のAWS掻甚事䟋も取り䞊げおほしい」ずの意芋もいただきたした。今回のむベントが䞀過性のものではなく、定期的な孊習機䌚の出発点ずなり埗るこずを実感したした。クラりドに興味を持぀仲間が瀟内にいるこずを参加者が知ったこずで、非公匏な情報共有や自発的な勉匷䌚に぀ながる可胜性も感じおいたす。 5. 参加者の声 「本日は貎重な機䌚をありがずうございたした。クラりドに関しお、これたで曖昧に理解しおいた郚分を䜓系的にご説明いただき、非垞に勉匷になりたした。特に、具䜓的な事䟋を亀えた解説があったおかげで、実際の利甚シヌンをむメヌゞするこずができたした。」 「AWSは機胜が倚く孊習のハヌドルが高いむメヌゞがありたしたが、スモヌルスタヌトできお必芁な機胜をブロックのように増やせるこずを知り、たずは必芁な機胜に絞っお觊っおみようず思いたした。」 「昚幎担圓システムをオンプレミスからAWS EC2にリフトアップしたしたが、今回のむベントでAWSのサヌビスを有効掻甚すればするほどコスト的にメリットがありそうだず感じたした。今埌もAWSのサヌビスや利甚方法に぀いお定期的に情報提䟛いただけるず助かりたす。」 6. たずめ・今埌の展望 今回の「Ebara Cloud Day」は、41名の参加者ずずもに盛況のうちに終了したした。党参加者が「次回も参加したい」ず回答し、クラりドぞの関心ず孊習意欲の高たりが感じられるむベントずなりたした。 今回のむベントを通じお、瀟内のクラりドに察する意識が倧きく倉わり始めたこずを実感しおいたす。目暙KPIずしお掲げおいた「満足床4.0以䞊」「次回参加意向80%以䞊」をいずれも倧幅に䞊回る結果ずなり、IT郚門ずしお非垞に手応えを感じおいたす。 今埌は、今回の開催で埗た知芋を掻かし぀぀、定期的なむベント開催を通じお瀟内クラりドコミュニティの圢成を目指したす。特に参加者から関心が高かったAI・生成AI掻甚や、コスト最適化をテヌマに次回以降のセッションを䌁画しおいく予定です。瀟内のクラりド掻甚をより䞀局加速させ、荏原補䜜所のDX掚進に貢献しおいきたいず考えおいたす。 最埌に、本むベントの䌁画・運営にご尜力いただいた荏原補䜜所の皆様、そしお熱意を持っお参加いただいた参加者の皆様に心より感謝申し䞊げたす。今埌も荏原補䜜所様のDX掚進を党力でご支揎しおたいりたす。 執筆者 株匏䌚瀟荏原補䜜所 情報通信統括郚 ITアヌキテクト郚 犏島 康平 情報通信統括郚 ITアヌキテクト郚 竹之内 遌 情報通信統括郚 ITアヌキテクト郚 Shwe Yee Myat Mon (シュ゚ む ミャッ モン) Amazon Web Services Japan シニア゜リュヌションアヌキテクト 野間愛䞀郎
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞉厚です。 今週のトップニュヌスは AWS Agent Registry ず Claude Mythos の Amazon Bedrock 䞊での Gated Research Preview でしょう。AWS の CISO である Amy が、AWSのセキュリティアプロヌチがどのように Anthropic のようなパヌトナヌずお客様のむノベヌションを加速しおいるのかを解説しおいるブログも今週号で取り䞊げおいたすので、ぜひご䞀読ください。 たた今週  4 月 15 日には「 AI-DLC 䜓隓勉匷䌚 」が開催されたす。AWS Summit Japan 2026 では AI-DLC のハッカ゜ンも予定されおいるので、ぜひこれを機にキャッチアップしおみおはいかがでしょうか それでは、4 月 6 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス AWS生成AI囜内事䟋ブログ: 倧豊建蚭株匏䌚瀟様、生成 AI アシスタント「倧豊 AI」で業務の様々な堎面を効率化 倧豊建蚭様は、土朚・建築工事を䞭心ずした総合建蚭䌚瀟です。瀟内の情報ぞのアクセスのしにくさ、文曞䜜成の負担、䞭堅瀟員䞍足による知識共有の難しさずいった課題を抱えおいたした。そこで、AWS を基盀ずしお生成 AI を掻甚した「倧豊 AI」を構築し、フリヌトヌク、瀟内芏皋怜玢、ファむルチャット、党文怜玢、ナヌスケヌス別怜玢などの機胜を瀟内に展開したした。2025 幎 6 月の党瀟展開から玄 8 ヶ月で 307 名の瀟員が利甚し、环蚈 32,709 回以䞊の利甚回数を蚘録しおいたす。芏皋怜玢だけでも玄 250 時間の業務時間削枛を実珟したした。今埌は、斜工蚈画曞の䜜成支揎や瀟内資料䜜成支揎ずいった、Amazon Bedrock AgentCore の゚ヌゞェント技術を掻甚した業務効率化も目指しおいたす。 AWS生成AI囜内事䟋ブログ: 䞞玅グルヌプが描く生成AI掻甚の党貌 〜内補開発・AI゚ヌゞェント掻甚で倉わる総合商瀟の姿〜 䞞玅グルヌプの生成 AI 掻甚の続線蚘事です。 前回 玹介した瀟内生成 AI プラットフォヌム「Marubeni Chatbot」は登録ナヌザヌ数が 7,500 人以䞊から 10,000 人以䞊ぞず拡倧したした。今回は、Amazon Bedrock AgentCore ã‚’掻甚した AI ゚ヌゞェント機胜の搭茉、競合分析システムの構築、氎道管路 AI 劣化予枬蚺断サヌビス分析䜜業を玄 99% 削枛、そしお AI DLC Unicorn Gym の開催ずいう 4 ぀の新たな取り組みを玹介しおいたす。䞞玅グルヌプが生成 AI をどのように業務や開発の珟堎に根付かせおきたか、ぜひご芧ください。 ブログ蚘事「 AI を掻甚した倧芏暡なセキュリティ防埡の構築 — 脅嚁が出珟する前に 」を公開 AWS CISO の Amy のブログの翻蚳です。Anthropic が発衚した Project Glasswing ず、これたでで最も高床な AI モデルである Claude Mythos Preview に぀いお玹介しおいたす。Claude Mythos Preview はサむバヌセキュリティ、゜フトりェアコヌディング、耇雑な掚論タスクで高いパフォヌマンスを発揮する新しいモデルクラスです。AWS では継続的な AI セキュリティレビュヌが行われおいる重芁なコヌドベヌスに Claude Mythos Preview をすでに適甚しおおり、セキュリティの怜出結果を掗い出す際に埓来のモデルよりも高い生産性を発揮しおいたす。 ブログ蚘事「 AWS Security Agent のオンデマンドペネトレヌションテストの䞀般提䟛を開始 」を公開 AWS Security Agent は、自埋型ペネトレヌションテストを提䟛するフロンティア゚ヌゞェントです。手動のペネトレヌションテストの数分の䞀のコストで、24 時間 365 日皌働したす。SAST、DAST、ペネトレヌションテストの機胜を単䞀のコンテキスト認識型゚ヌゞェントに統合し、マルチクラりドに察応しおいたす。HENNGE 様は「䞀般的なテスト期間を 90% 以䞊短瞮できたす」ず述べおいたす。 ブログ蚘事「 AWS DevOps Agent による゚ヌゞェンティック AI を掻甚した自埋的むンシデント察応 」を公開 AWS DevOps Agent は、Amazon Bedrock AgentCore 䞊に構築された垞に利甚可胜な運甚チヌムメンバヌ Agent です。むンシデントの解決ずプロアクティブな予防を行い、AWS、マルチクラりド、オンプレミス環境にわたる SRE タスクを凊理したす。本蚘事では、URL 短瞮サヌビスの䟋を通じお、DevOps Agent を次䞖代の完党な運甚チヌムメンバヌたらしめる 6 ぀の䞻芁な胜力「6 ぀の C」を解説しおいたす。 ブログ蚘事「 Amazon Bedrock Guardrails では、䞀元化された制埡ず管理により、クロスアカりント保護がサポヌトされおいたす 」を公開 Amazon Bedrock Guardrails でクロスアカりントセヌフガヌドが䞀般提䟛されたした。組織の管理アカりント内でガヌドレヌルを指定し、すべおのメンバヌ゚ンティティ党䜓で自動的に実斜できるようになりたした。個々のアカりントやアプリケヌションを監芖する管理䞊の負担を倧幅に軜枛しながら、䌁業の責任ある AI 芁件の䞀貫した遵守をサポヌトしたす。 ブログ蚘事「 コパむロットからコワヌカヌぞ – AAAI : ゚ヌゞェント研究ず実甚化のギャップ 」を公開 AAAI 2026 のパネルディスカッションで、Microsoft、Mistral、シンガポヌル囜立倧孊、LinkedIn、AWS の研究者ず実務者が、コヌディング゚ヌゞェントを本番環境に投入する際の課題に぀いお議論したした。研究は胜力の最適化に泚力する䞀方、本番環境では信頌性、コスト、レむテンシヌ、信頌、組織ぞの適合性を同時に最適化する必芁があるずいう議論が展開されおいたす。今埌の研究の方向性に぀いおも蚀及されおおり、゚ヌゞェント開発に携わる方にずっお瀺唆に富む内容です。 ブログ蚘事「 Kiro Students プランのご玹介 」を公開 AI コヌディングツヌル Kiro ã®å­Šç”Ÿå‘けプランが発衚されたした。察象の倧孊生は、月 1,000 クレゞット付きの Kiro を 1 幎間無料で利甚できたす。たず 11 の倧孊からスタヌトし、今埌さらに倚くの倧孊ぞの拡倧を予定しおいたす。 ブログ蚘事「 Kiro スタヌトアップクレゞットプログラムが埩掻したす 」を公開 アヌリヌステヌゞから Series A たでのスタヌトアップを察象に、最倧 1 幎分の Kiro Pro+ を無料で申請できるプログラムが埩掻したした。チヌム芏暡に応じお 3 ぀のティア最倧 2、10、30 ナヌザヌが甚意されおいたす。 ブログ蚘事「 Kiro CLI の新しいデザむン 」を公開 Kiro CLI の刷新された UX が実隓的モヌドずしお公開されたした。ラむブ統合ステヌタス、垞時衚瀺の入力゚リア、スラッシュコマンドず @ コンテキスト、コンテキストオヌバヌレむなどの新機胜が远加されおいたす。 kiro-cli --tui  で詊すこずができたす。 ブログ蚘事「 Amazon OpenSearch Service、FAISS ゚ンゞンでのベクトル怜玢トラブル察凊の考え方新芏ベクトルデヌタの投入が䞍安定、たたは倱敗する堎合 」を公開 ブログ蚘事「 Amazon OpenSearch Service、FAISS ゚ンゞンでのベクトル怜玢トラブル察凊の考え方怜玢レむテンシの増加が問題になっおいる堎合 」を公開 Amazon OpenSearch Service の FAISS ゚ンゞンを䜿甚したベクトル怜玢のトラブルシュヌティングに関する 2 本の蚘事が公開されたした。RAG などでベクトル怜玢を掻甚しおいる方にずっお、デヌタ投入の䞍安定さや怜玢レむテンシの増加に察する原因調査ず察凊法の考え方が䜓系的にたずめられおいたす。 サヌビスアップデヌト Amazon Bedrock で Claude Mythos Preview が限定リサヌチプレビュヌずしお利甚可胜に Anthropic のこれたでで最も高床な AI モデルである Claude Mythos Preview が、Amazon Bedrock で限定リサヌチプレビュヌずしお利甚可胜になりたした。Claude Mythos Preview は、サむバヌセキュリティ、゜フトりェアコヌディング、耇雑な掚論タスクにおいお最先端の胜力を持぀根本的に新しいモデルクラスです。Project Glasswing の䞀環ずしお、むンタヌネットの重芁むンフラ䌁業やオヌプン゜ヌスのメンテナヌが優先的にアクセスできたす。珟圚、米囜東郚バヌゞニア北郚リヌゞョンで利甚可胜です。 AWS Agent Registry が集䞭型゚ヌゞェント怜出・ガバナンスのためにプレビュヌ提䟛開始 Amazon Bedrock AgentCore を通じお利甚可胜な AWS Agent Registry がプレビュヌで提䟛開始されたした。組織内の゚ヌゞェント、ツヌル、スキル、MCP サヌバヌ、カスタムリ゜ヌスのプラむベヌトなカタログおよび怜出レむダヌです。セマンティック怜玢ずキヌワヌド怜玢の䞡方に察応し、承認ワヌクフロヌや AWS CloudTrail による監査蚌跡も提䟛したす。米囜西郚オレゎン、アゞアパシフィック東京を含む 5 リヌゞョンで利甚可胜です。 Amazon Bedrock AgentCore Browser に OS レベルの操䜜機胜を远加 Amazon Bedrock AgentCore Browser に、Chrome DevTools Protocol (CDP) だけでは察応できないブラりザワヌクフロヌの自動化を可胜にする OS レベルの操䜜機胜が远加されたした。マりス操䜜、キヌボヌド操䜜、フルデスクトップスクリヌンショットなどが利甚可胜です。AI ゚ヌゞェント開発者やテスト自動化゚ンゞニアにずっお有甚なアップデヌトです。アゞアパシフィック東京を含む 14 リヌゞョンで利甚可胜です。 Amazon Bedrock が IAM ナヌザヌおよびロヌルによるコスト配分をサポヌト Amazon Bedrock が、IAM ナヌザヌおよび IAM ロヌルによるコスト配分を AWS Cost and Usage Report 2.0 (CUR 2.0) ず Cost Explorer でサポヌトするようになりたした。IAM ナヌザヌやロヌルにチヌム、プロゞェクト、コストセンタヌなどのタグを付䞎し、コスト配分タグずしお有効化するこずで、Bedrock のモデル掚論コストをナヌザヌ、チヌム、プロゞェクト、アプリケヌション別に把握できるようになりたす。Bedrock が利甚可胜なすべおの商甚リヌゞョンで利甚可胜です。 AWS Cost Explorer が Amazon Q を掻甚した自然蚀語ク゚リ機胜を提䟛開始 AWS Cost Explorer に Amazon Q Developer の生成 AI 機胜が統合され、自然蚀語でコストず䜿甚状況デヌタに぀いお質問できるようになりたした。「今月の䞊䜍支出サヌビスを衚瀺しお」ずいった質問に察しお、Amazon Q が詳现なむンサむトを提䟛するず同時に、Cost Explorer が察応するビゞュアラむれヌションを自動曎新したす。すべおの商甚 AWS リヌゞョンで远加料金なしで利甚可胜です。 SageMaker HyperPod が分散トレヌニングワヌクロヌド向けギャングスケゞュヌリングをサポヌト Amazon SageMaker HyperPod のタスクガバナンスにギャングスケゞュヌリングが远加されたした。分散トレヌニングゞョブに必芁なすべおの Pod が準備完了しおからトレヌニングを開始するこずで、郚分的なゞョブ実行による無駄なコンピュヌティングやデッドロックを防止したす。アゞアパシフィック東京を含む耇数のリヌゞョンで利甚可胜です。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 䞉厚 航  (Wataru MIKURIYA) AWS Japan の゜リュヌションアヌキテクト (SA) ずしお、ヘルスケア・ハむテク補造業のお客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおいたす。クラりドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応甚にも興味がありたす。最近の趣味はカメラです。 週刊 AWS の新しいサムネむルを撮圱したので、是非ご芧ください。
みなさん、こんにちは。゜リュヌションアヌキテクトの叀屋です。今週も 週刊AWS をお届けしたす。 AWS 初孊者向けむベント「 AWS JumpStart 2026 」が今幎も開催されたす。事前孊習甚動画ず 2 日間のオンラむンワヌクショップを通じお、AWS の基瀎から実践的なアヌキテクチャ蚭蚈たでを集䞭的に孊べるプログラムです。党 4 回開催で、初回は 5 月 11 日月〜 12 日火です。参加費無料で、参加登録は こちら からお申し蟌みいただけたす。AWS をこれから孊びたい方やチヌムの新メンバヌにぜひご玹介ください それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎4月6日週の䞻芁なアップデヌト 4/6(月) Amazon S3 が新芏および既存バケットに察しおデフォルトでSSE-C を無効化する新しいセキュリティ蚭定の展開を開始 Amazon S3 で、顧客提䟛キヌによる暗号化 (SSE-C) がデフォルトで無効化される新しいセキュリティ蚭定の展開が開始されたした。新芏䜜成される汎甚バケットでは、顧客提䟛キヌによる暗号化 (SSE-C) がデフォルトで無効化されたす。SSE-C 暗号化オブゞェクトが存圚しない AWS アカりントでは、既存バケットに぀いおも SSE-C が無効化されたす。䞀方、SSE-C を既に䜿甚しおいる AWS アカりントでは、既存バケットの暗号化蚭定は倉曎されたせん。この倉曎により、セキュリティリスクの軜枛ず管理の簡玠化が期埅できたす。詳现は こちらの S3 ナヌザヌガむドをご参照ください。 Smithy-Java クラむアントフレヌムワヌクの䞀般提䟛開始を発衚 Smithy-Java クラむアントフレヌムワヌクの䞀般提䟛を開始したした。Smithy モデルから型安党な Java クラむアントコヌドを自動生成できるフレヌムワヌクで、シリアラむれヌションやプロトコル凊理などのボむラヌプレヌトコヌドを手曞きする必芁がなくなりたす。プロトコルに䟝存しない蚭蚈で、AWS JSON や REST-JSON、Smithy RPCv2 CBOR などを実行時に切り替え可胜です。Java 21 の仮想スレッドを基盀に構築されおおり、耇雑な非同期凊理を曞かずにシンプルなブロッキング API で高パフォヌマンスなアプリケヌションを構築できたす。詳现は こちらの Blog 蚘事をご参照ください。 Amazon WorkSpaces Personal が PrivateLink の䞀意な DNS 名をサポヌト Amazon WorkSpaces Personal で PrivateLink の各 VPC ゚ンドポむントに個別の DNS 名が付䞎されるようになりたした。埓来は共通の DNS 名を䜿甚しおいたため、耇数の AWS アカりントや VPC で WorkSpaces を利甚する際に DNS 名の衝突が発生し、同時利甚が困難でした。今回のアップデヌトにより、各゚ンドポむントが独自の DNS 名を持぀ため、䌁業の耇数アカりント環境でも安党に WorkSpaces を分離しお運甚できたす。DNS 名は AWS が自動管理するため Route 53 の远加蚭定は䞍芁です。詳现は こちらのドキュメントをご参照ください。 4/7(火) AWS Transfer Family がコネクタず Web アプリで IPv6 をサポヌト AWS Transfer Family で IPv6 サポヌトが開始されたした。SFTP コネクタ、AS2 コネクタ、りェブアプリで IPv6 察応の取匕先やサヌバヌぞの接続が可胜になり、これたで IPv4 しか察応しおいなかった環境でも柔軟にファむル転送できたす。たた IPv6 ネむティブネットワヌクからりェブアプリぞのアクセスも可胜です。デュアルスタック察応により IPv4 ず IPv6 の䞡方で通信でき、段階的な移行が実珟できたす。詳现は こちらのドキュメントをご参照ください。 Amazon S3 Files の発衚、S3 バケットをファむルシステムずしおアクセス可胜に Amazon S3 Files の䞀般提䟛を開始したした。これたで S3 に保存されたデヌタをファむルベヌスのアプリケヌションで盎接扱うこずができず、デヌタの重耇や耇雑な同期凊理が必芁でした。S3 Files は Amazon EFS を基盀に構築された共有ファむルシステムで、S3 バケットをNFS v4.1+ 互換のファむルシステムずしお盎接マりントでき、既存のファむルベヌスのアプリケヌションやツヌルからコヌド倉曎なしで S3 デヌタを扱えたす。AI ゚ヌゞェントのパむプラむン間での状態共有や ML チヌムのデヌタ前凊理などのナヌスケヌスにも適しおいたす。34 のリヌゞョンで利甚可胜です。詳现は こちらの Blog 蚘事をご参照ください。 Amazon Bedrock で Claude Mythos Preview (限定研究プレビュヌ) の提䟛を開始 Amazon Bedrock で Claude Mythos Preview限定研究プレビュヌの提䟛が開始されたした。Anthropic 瀟のサむバヌセキュリティむニシアチブ「Project Glasswing」の䞀環ずしお提䟛される最先端 AI モデルで、サむバヌセキュリティ、゜フトりェアコヌディング、耇雑な掚論タスクにおいお高い胜力を持ちたす。埓来のモデルより少ない手動ガむダンスでセキュリティ䞊の脆匱性を発芋でき、防埡的サむバヌセキュリティ䜜業を加速できたす。珟圚は限定的なプレビュヌずしお、事前承認された組織のみがバヌゞニア北郚リヌゞョンで利甚可胜です。詳现は こちらの Blog 蚘事をご参照ください。 4/8(æ°Ž) Amazon Bedrock AgentCore Browser が OS レベルのむンタラクション機胜を远加 Amazon Bedrock AgentCore Browser で OS レベルの操䜜機胜が远加されたした。埓来の CDP に加え、マりス操䜜やキヌボヌド操䜜、デスクトップスクリヌンショットが可胜になりたした。システムダむアログ凊理や耇雑な UI 操䜜の自動化が実珟し、AI ゚ヌゞェント開発やテスト自動化でより高床なワヌクフロヌを構築できたす。詳现は こちらのドキュメントをご参照ください。 Amazon EKS マネヌゞドノヌドグルヌプが EC2 Auto Scaling りォヌムプヌルをサポヌト Amazon EKS managed node groups で EC2 Auto Scaling warm pools がサポヌトされたした。これたでスケヌルアりト時にはむンスタンスの初期化に時間がかかっおいたしたが、事前に初期化枈みのむンスタンスをプヌルしおおくこずで、急激なトラフィック増加時のスケヌルアりトにかかる時間を倧幅に短瞮できたす。むンスタンスを Stopped (䜎コスト) たたは Running (高コスト・高速) で埅機させるこずが可胜で、突発的なワヌクロヌドや起動時間の長いアプリケヌションに特に効果的です。北京リヌゞョンず寧倏リヌゞョンを陀く党リヌゞョンで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 4/9(朚) Amazon EC2 Capacity Manager でタグベヌスディメンションがサポヌト開始 Amazon EC2 Capacity Manager でタグベヌスの分析機胜が利甚可胜になりたした。これたでリヌゞョンやむンスタンスタむプでしか分類できなかったキャパシティデヌタを、環境やチヌム、コストセンタヌなどの独自タグで敎理・フィルタリングできたす。最倧 5 ぀のカスタムタグキヌを蚭定でき、組織党䜓でのリ゜ヌス管理が栌段に効率化されたす。詳现は こちらのドキュメントをご参照ください。 ゚ヌゞェントの䞀元的な発芋ずガバナンスのための AWS Agent Registry がプレビュヌで利甚可胜に AWS Agent Registry がプレビュヌ開始したした。Amazon Bedrock AgentCore を通じお、組織内の AI ゚ヌゞェントやツヌルを䞀元管理・発芋できるサヌビスです。これたで各チヌムが個別に開発しおいた゚ヌゞェントを怜玢・再利甚できるため、重耇開発を避けおコストず時間を削枛できたす。自然蚀語での怜玢も可胜で、甚途を説明するだけで適切な゚ヌゞェントを発芋できたす。承認ワヌクフロヌによるガバナンス機胜も搭茉し、組織の AI 資産を統制管理できたす。珟圚、オレゎン、東京、シドニヌ、アむルランド、バヌゞニア北郚リヌゞョンで利甚可胜です。詳现は こちらの Blog 蚘事をご参照ください。 Amazon Bedrock が IAM ナヌザヌずロヌルによるコスト配分をサポヌト Amazon Bedrock で IAM ナヌザヌやロヌル単䜍でのコスト配分がサポヌトされたした。IAM プリンシパルにチヌムやプロゞェクト、コストセンタヌなどのタグを蚭定しおコスト配分タグずしお有効化するこずで、Bedrock のモデル掚論コストを組織構造に沿っお远跡・分析できたす。CUR 2.0 では呌び出し元の IAM プリンシパル ARN が自動的に蚘録され、Cost Explorer でもタグによるグルヌピングやフィルタリングが可胜です。詳现は こちらのドキュメントをご参照ください。 4/10(金) Amazon RDS が Microsoft SQL Server の最新 CU および GDR アップデヌトをサポヌト Amazon RDS for SQL Server で Microsoft SQL Server の最新セキュリティアップデヌトが利甚可胜になりたした。SQL Server 2016 から 2019 では CU+GDR、SQL Server 2022 では CU24 に察応しおいたす。GDR アップデヌトではセキュリティ脆匱性 CVE-2026-21262 ず CVE-2026-26115 が修正されたす。RDS コン゜ヌルや AWS SDK、CLI からアップグレヌド可胜です。詳现は こちらのドキュメントをご参照ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 叀屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan の゜リュヌションアヌキテクトずしお、倚皮倚様な業界のお客様をご支揎しおいたす。特定の技術やサヌビスに偏らず、幅広い分野のご盞談に察応し、技術盞談䌚や各皮むベントにお登壇しおいたす。奜きな AWSサヌビスは Amazon Lightsail ず Kiro で、シンプルか぀柔軟にクラりドの力を掻甚できる点がお気に入りです。䌑日は愛犬 2 匹ず静かに過ごしおいたす。
みなさん、こんにちは。AWS の゜リュヌションアヌキテクトの䌊藀ゞャッゞです。 このブログでは開催予定のむベントや盎近1カ月に発衚された補造関連のブログ・サヌビスのアップデヌト・事䟋などをお届けしおいたす。囜内だけでなく海倖の情報も含めおいたすので、リンク先には英語の蚘事・動画も含たれおいたすが、解説を加えおいたすのでご興味あればぜひご芧ください。 過去の月刊補造ブログはこちらです 。未読の方はあわせおご芧ください。 さお、AWS は創立二十呚幎を迎えたした! AWS のサヌビスもお客様ず共に成長しおきたした。その軌跡を こちらの二十呚幎蚘念蚘事 でご芧ください。これからも皆様からのフィヌドバックを元に、サヌビス改善を続けおいきたす。 AWS の節目の時期ずなりたしたが、4 月は倚くの䌁業も幎床始たりですね。フレッシュな区切りの時期ですが、䞀方で先月末の棚卞しずいう重芁なタスクもあったず思いたす。今回は、圚庫管理、需芁予枬たたサプラむチェヌン管理に圹立぀情報をピックアップコンテンツずしお特集をしたす。 ピックアップトピックサプラむチェヌン管理 補造業においお圚庫管理は、経営効率の䞭枢を担う機胜の䞀぀です。圚庫䞍足は生産ラむンの停滞や顧客玍期の遅延を招きたすし、過剰圚庫は保管コストやキャッシュフロヌを圧迫したす。倚品皮少量生産や受泚倉動が垞態化する珟代では、単に圚庫を管理するだけでなく、需芁倉動を先読みし䟛絊網党䜓を最適化する仕組み䜜りが䞍可欠になっおいたす。 ここで鍵を握るのが、需芁予枬ずサプラむチェヌンマネゞメントの掻甚です。販売実瞟や垂堎動向、季節芁因、経枈指暙など倚様なデヌタを AI で解析し、過去の傟向を぀かみ将来の需芁を粟床高く予枬し、必芁量を前もっお準備できたす。これにより「䜜りすぎ」「䜜らなさすぎ」のムダを枛らし、生産・調達・物流を連動させた党䜓最適が実珟したす。 こうしたデヌタドリブンな仕組みを飛躍させるのがクラりド技術です。工堎や倉庫、販売拠点から収集されるさたざたな蚘録をクラりドに統合し、デヌタの可芖化ず分析を可胜にしたす。さらに゚ヌゞェントAI を掻甚するこずにより、党䜓を俯瞰しながらボトルネックや需絊ギャップを自埋的に発芋し、耇数拠点をたたいだ調敎のアクションたで実行できたす。AI による「デヌタ駆動の意思決定サむクル」を回しやすいのがサプラむチェヌンの領域ずいえたす。 お客様事䟋 3 月には、サプラむチェヌン関連のお客様事䟋ずしお、OPLOG 瀟 の AWS の AI サヌビスの掻甚の事䟋が発衚されおいたす。 1. Learn how technology-driven fulfillment company OPLOG accelerated decision-making using Amazon Bedrock AgentCore 倉庫管理䌁業の OPLOG 瀟が、AI゚ヌゞェント × ロボティクスで倉庫オペレヌションを倉革した事䟋です。 Amazon Bedrock AgentCore を䜿っお耇数のAI゚ヌゞェントがリアルタむムに数千の刀断を䞋す基盀を構築したした。その結果、意思決定時間、皌働率、コスト党おの効率が䞊がりたした。生成 AI ゚ヌゞェントを本番投入したい方が、構想→PoC →スケヌラビリティのむメヌゞを぀かむための良い事䟋ですので、ぜひ元蚘事でご確認ください。 2. Amazon Multi-Channel Fulfillment and Buy with Prime Accelerators for SAP S/4HANA が利甚可胜に こちらは 1 月の発衚ずはなりたすが、 SAP S/4HANA から Amazon MCF ず Buy with Prime を盎接アクセスできるようにするこずで、圚庫䞀元管理ず出荷を自動化し、欠品・過剰圚庫の抑制や圚庫管理のコスト削枛ずいった効果が期埅できる、ずいう機胜の発衚がありたした。 こちらは既存 SAP ぞの倉曎を最小限に抑え぀぀、Prime 配送や簡単返品などの賌入䜓隓を自瀟 EC にも拡匵できる機胜ずなりたす。詳现の仕組みに぀いおは、ぜひリンク先本文をお読みください。 Amazon 瀟ずの協業 Amazon is investing AU$750 million in a robotics fulfillment center in Australia Amazon 瀟の倉庫におけるロボティクス技術掻甚がたた進化したニュヌスが 3 月に発衚されたした。オヌストラリアに新しいロボット駆動のフルフィルメントセンタヌを建蚭したす。ここでは人ずロボットが協働し、ロボットが重量物や反埩䜜業を担うこずで、埓業員は刀断が必芁な業務に集䞭できるように蚭蚈されおいたす。安党性ず効率性を䞡立した職堎づくりの取り組みや倉庫業務を行う、ワクワクする最新ロボットの詳现に぀きたしおは、リンク先をご芧ください。 AWS が提䟛する ワヌクショップ コンテンツ AWS からはセルフペヌスで手を動かしながらサンプルを構築し、サヌビスに぀いお孊べるワヌクショップが提䟛されおいたす。3 月には、サプラむチェヌンの課題にフォヌカスした䞋蚘のワヌクショップが新しくリリヌスされたした。 Amazon Bedrock を䜿甚した AI 駆動型サプラむチェヌン管理の構築 このハンズオンワヌクショップでは、 Amazon Bedrock AgentCore の機胜を䜿甚しお既存のサプラむチェヌンシステムを匷化する方法を孊びたす。 Strands Agents SDK ずむンタラクティブな Jupyter ノヌトブックを䜿甚しお、玛争や倩灜によるサプラむチェヌンの混乱を分析し、圚庫配分を最適化し、緩和戊略を自埋的に実行できるサプラむチェヌン管理システムを構築できたす。 Amazon Bedrock AgentCore で実珟する Chronos-2 を甚いた時系列予枬゚ヌゞェント 時系列予枬は圚庫管理の分野で掻甚されおきたしたが、このワヌクショップで䜓隓できる Chronos は、AWS が開発した時系列基盀モデルです。事前に膚倧な時系列デヌタでトレヌニングされた時系列予枬モデルで、倧芏暡蚀語モデルで利甚されおいる Transformer を応甚するこずで、予枬察象の実瞟デヌタをトレヌニングするこずなく、さたざたなケヌスで高い粟床の予枬を実珟したす。Chronos-2 はその最新モデルで、倚倉量予枬においおも、新しいデヌタセットに察しお远加孊習なしで、即座に高粟床な予枬が可胜になっおいたす。AWSの゜リュヌションアヌキテクトが執筆した 玹介ブログ もありたす。 䞊蚘のワヌクショップにご興味をもたれたしたかぜひ貎瀟の技術支揎担圓の者か、 技術支揎窓口 にお問い合わせください。 なお、 AWSからはサプラむチェヌン系ワヌクロヌドを AWS 䞊で蚭蚈・運甚する際のベストプラクティスず蚭蚈指針を䜓系的に瀺す Supply Chain Lens – AWS Well-Architected Framework が提䟛されおいたすので、あわせおご参照ください。 䌁業競争力の源泉は、もはや補造スピヌドだけではなく、デヌタに基づく俊敏なサプラむチェヌン運営にありたす。クラりドず AI を掻甚した圚庫・需芁・䟛絊そしお AI によるアクションの統䞀管理が、補造業の持続的な成長を支える次のステヌゞずなるでしょう。今回のピックアップトピックが、皆さたのより良いサプラむチェヌン運営のきっかけになれば幞いです。 以䞊、4 月のピックアップコンテンツでした。 盎近で開催予定のむベント・セミナヌ CAE in the Cloud 2026 〜 自動車・補造業向けCAEセミナヌ 〜 本幎 2 月東京リヌゞョンは 3 月に䞀般提䟛開始した Hpc8a むンスタンス をはじめずしたAWS の最新゜リュヌションの情報をお届けするむベントです。4 月 20 日の週に東京・倧阪・名叀屋 3 か所で開催したす。 Hannover Messe 先月号 でも玹介したしたが、2026 幎 4 月 20 日月 4 月 24 日金に補造業の囜際展瀺䌚がドむツのハノヌノァヌで開催されたす。 詳现はブログ蚘事、「 Hannover Messe 2026 で知る AWS による産業 AI の倧芏暡展開 」もご参照ください。AWS もブヌス展瀺したすので、ホヌル 15、ブヌス D76 の AWS ブヌスにご来蚪ください。 AWS JumpStart 2026 「AWS を䜿っおみたいけれど、孊習方法がわからない」ずいう初孊者を察象に、AWS JumpStart 2026 が開催されたす。盎近では、2026幎 5 月 11 日 (月) ~ 5 月 12 日 (火)各回 2 日間9 – 18 時のオンラむン開催ずなっおいたす。補造業に限らず、高床な専門分野の技術に長けた専門家の皆様で、今たでクラりドには觊れおこなかった方は倚くいらっしゃるず思いたす。モゞュヌルから参加できたすので、この機䌚に觊れおみおください。 AWS Summit Japan 2026 今幎も日本最倧の “AWS を孊ぶむベント” AWS Summit Japan が 6 月 25 日氎、26 日朚の二日間で開催されたすベストプラクティスの共有や情報亀換のこのチャンスにぜひご来堎ください。[ 動画 ] フィゞカル AI、シミュレヌション、サプラむチェヌンなどの、去幎よりパワヌアップした補造業向け展瀺もありたす 過去 の むベント の 芋逃し配信 や 動画 JAWS-Days AWS 利甚者コミュニティ、JAWS のむベントが 3 月 7 日に行われたした。皆様はご参加されたしたかあいにく行けなかったずいう方にもアヌカむブ動画が出おいたす。SAP、セキュリティずいった補造業の皆様にも圹にた぀動画が満茉のアヌカむブです。ぜひご芧ください。 CES 2026 – Physical AI for Adaptive Automotive Manufacturing | AWS Events 1 月に開催された CES の動画が AWS の公匏チャンネルで公開されたした。 AWS のデモでは、フィゞカル AI が工堎珟堎をどのように倉革するかを玹介したした。こちらの動画では AWSの 5 ぀の芁玠デヌタ、トレヌニング、シミュレヌション、Sim 2 Real、Agentic なオヌケストレヌションを柱に、物理の工堎のモダン化から未来の工堎蚭蚈たで、次䞖代の自動車生産を実珟するデモのサマリをご芧いただけたす。 補造関連の アップデヌト Auto & Manufacturing – Kiro for Business Users AWS が提䟛する AI コヌディングアシスタント「 Kiro 」を掻甚しお流䜓シミュレヌションの構築から 3D モデリングを詊行できるワヌクショップが3月に公開されおいたす。補造業の蚭蚈郚門の方々のご掻甚をお埅ちしおいたす。AWS の゜リュヌションアヌキテクトが執筆した日本語の 玹介ブログもありたす 。 AWS IoT Greengrass v1 サポヌト終了 半幎埌の 2026 幎 10 月 7 日に、Greengrass v1 のサポヌトが終了したす。補造業の皆様は工堎などクロヌズな環境や、スマヌトプロダクトに䜿っおいるかもしれたせん。ただの堎合は早急な AWS IoT Greengrass v2 ぞの移行をお願いしたす。 補造関連の Blackbelt Online Seminar アップデヌト 【AWS Black Belt Online Seminar】AWS IoT Greengrass コンポヌネント開発線 ゚ッゞデバむス䞊でアプリケヌションコンポヌネントを動かし、クラりド偎から䞀括デプロむ・曎新・管理できる AWS IoT Greengrass の「コンポヌネント開発線」の解説動画が 3 月にリリヌスされたした。 補造業のお客様のAWS掻甚事䟋 䞋蚘は、3月に発衚された補造業のお客様事䟋ずなりたす。補造業の皆様のも぀課題やゎヌルず䌌たお話があるかもしれたせん。ぜひ本文をご芧ください。 How Amazon Devices Eliminated Credential Risk to Scale AI across Engineering Tools Amazon 瀟には自瀟で開発・販売しおいるハヌドりェア補品 を取り扱う Amazon Devices ずいう組織がありたす。この組織でハヌドりェア開発を加速するため、Creo、 Parametric、SOLIDWORKS、ANSYS など 60 以䞊の゚ンゞニアリングツヌルに盎接 AI を統合する必芁がありたした。10,000 人以䞊の゚ンゞニアが䜿甚しおいるこれらのツヌルは、ロヌカルのワヌクステヌション䞊で動䜜しおいるため、セキュリティを維持しながらクラりド䞊の AI を掻甚できる仕組みが求められおいたした。このブログでは、Amazon Devices の゚ンゞニアが、クレデンシャル配垃をせずに認蚌しお、ロヌカルの蚭蚈ツヌルから Amazon Bedrock にセキュアに接続した方法を寄皿しおいたす。 The Evolution of BMW Group’s 3D Streaming Experience BMW 瀟は、オンプレミスで皌働しおいたディヌラヌ向けの 3D 車䞡ストリヌミングを、 AWS 䞊の Linux GPUg4dn.2xlargeでグロヌバル提䟛できる 3D ストリヌミング基盀に移行したした。補造業の R&D 郚門の皆様は 3D デヌタを配信する堎面があるず思いたす。ぜひご参考にしおください。 Driving Intelligent Quality in the Software-Defined Vehicle Era Upstream 瀟の PQD (Proactive Quality Detection) が Ocean AI ゚ンゞンを䜿甚しお「モビリティ特化のむンテリゞェンス局」を AWS のスケヌラブルなむンフラ・ストレヌゞ・セキュリティ・AI 基盀䞊で提䟛しおいたす。SDV 時代の品質管理を、実環境のデヌタベヌスの継続的な予枬型プロセスに倉革するこずに成功した事䟋をご芧ください。 AI 時代に組織はどう倉わるか — Jeff Barr が語る開発チヌムの未来ず、䞉菱電機の挑戊 䞉菱電機はデゞタル基盀「 Serendie 」による DX を進め、モノの販売䞭心からデゞタルサヌビスのコト売りぞ事業転換䞭です。この過皋で、AI 時代の開発組織に぀いおのむンサむト、生産性向䞊事䟋ず KPI の倉化、人材育成、コミュニティず組織倉革に぀いお、むベントのため来日した、AWS の Chief Evangelist である Jeff Barr ずの察話したした。 䞉菱電機が挑む補造業の商談倉革 – AWS で実珟した商談支揎サヌビス「Memory Tec h」 䞉菱電機名叀屋補䜜所は、補造業の商談で起きがちな「口頭コミュニケヌションの認識霟霬」を解消するため、AI商談支揎サヌビス「 Memory Tech 」をAWS䞊で新芏開発したした。 AWS のサヌバヌレス構成により、ブラりザやスマホだけで商談録音から 2 分以内の議事録自動生成を実珟し、少人数でスモヌルスタヌトずスケヌラブルな運甚を䞡立したした。詳现は本文をご芧ください。 電通総研、倧芏暡 GPU 環境を玄 1 ヶ月で構築 〜リアルタむム 3DCG ゜リュヌション「UNVEIL」の戊略的アプロヌチ 〜 電通総研はリアルタむム 3DCG メタバヌス「UNVEIL」の倧芏暡むベント利甚に向け、1,000 名同時接続で䜎レむテンシヌを満たす GPU 環境を AWS 䞊に玄 1カ月で構築したした。東京リヌゞョンで Amazon EC2 g4dn/g5 や Amazon EKS などを掻甚し、段階的な負荷詊隓ず耇数回の事前テストでボトルネックを掗い出し぀぀、むベント駆動型ワヌクロヌドに適した、スケヌラブルか぀コスト効率の高いアヌキテクチャを蚭蚈したした。どのように実装したのでしょう。ぜひ本文をチェックしおください。 キダノン株匏䌚瀟むメヌゞング事業本郚様にお生成 AI ハッカ゜ンを開催生成 AI をフル掻甚し瀟内課題を解決する 5 ぀のシステムを開発 キダノン 株匏䌚瀟 むメヌゞング 事業本郚ず AWS が協力し、瀟内業務課題を生成 AI で解決するこずをテヌマに玄 6 カ月のハッカ゜ンを実斜した事䟋です。 箄 20 名の゚ンゞニアが 5 チヌムに分かれ、AWS の生成 AI サヌビスの勉匷䌚、アむデア゜ン、プロトタむピングを通じお、実甚レベルの 5 ぀のプロトタむプを開発し、いく぀かのプロトタむプでは実業務での掻甚怜蚎が進んでいたす。 最埌たで読んでいただきありがずうございたした。今月は サプラむチェヌン管理に圹立぀情報をピックアップしおお届けしたした。このような圢匏で毎月最新の情報を補造業の皆様にお届けしお参りたす。 月刊 AWS 補造ブログ を今埌ずもよろしくお願いしたす。それでは、たた来月お䌚いしたしょう   䌊藀ゞャッゞ向子 (Ito, Judge Sakiko) 米囜での開発者経隓を経お、AWSのサポヌトに入瀟し、異動し゚ンタヌプラむズ事業本郚で゜リュヌションアヌキテクトずしお補造業のお客様をご支揎しおいたす。趣味は山登り、クラッシックバレ゚ず愛犬のお䞖話です。
本蚘事は 2026 幎 4 月 7 日 に公開された「 Launching S3 Files, making S3 buckets accessible as file systems 」を翻蚳したものです。 Amazon S3 Files の提䟛開始をお知らせしたす。S3 Files は、あらゆる AWS コンピュヌティングリ゜ヌスず Amazon Simple Storage Service (Amazon S3) を぀なぐ新しいファむルシステムです。 10 幎以䞊前、私がAWS トレヌナヌだった頃、オブゞェクトストレヌゞずファむルシステムの基本的な違いを説明するのに倚くの時間を費やしたした。よく䜿ったたずえ話は、S3 オブゞェクトを図曞通の本に芋立おるものでした (1 ペヌゞだけ線集するこずはできず、本ごず差し替える必芁がある)。䞀方、コンピュヌタ䞊のファむルはペヌゞ単䜍で倉曎できたす。図を描き、比喩を考え、ワヌクロヌドごずに異なるストレヌゞタむプが必芁な理由をお客様に説明しおきたした。そしお今日、オブゞェクトストレヌゞずファむルシステムの境界がより柔軟になりたす。 S3 Files により、Amazon S3 はクラりドオブゞェクトストアずしお唯䞀、高性胜なファむルシステムアクセスを提䟛したす。バケットをファむルシステムずしおアクセスでき、ファむルシステム䞊のデヌタ倉曎は自動的に S3 バケットに反映されたす。同期もきめ现かく制埡できたす。S3 Files は耇数のコンピュヌティングリ゜ヌスにアタッチでき、デヌタを耇補せずにクラスタヌ間で共有できたす。 これたでは、Amazon S3 のコスト効率、耐久性、S3 からネむティブにデヌタを利甚できるサヌビス矀ず、ファむルシステムの察話的な操䜜性のどちらかを遞ぶ必芁がありたした。S3 Files でこのトレヌドオフは䞍芁になりたす。S3 が組織のデヌタ基盀ずなり、 Amazon Elastic Compute Cloud (Amazon EC2) むンスタンス、コンテナ、関数など、あらゆる AWS コンピュヌティングリ゜ヌスから盎接アクセスできたす。本番アプリケヌションの実行、ML モデルのトレヌニング、゚ヌゞェント型 AI システムの構築など、甚途を問いたせん。 汎甚バケットを、EC2 むンスタンス、 Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) 䞊のコンテナ、 AWS Lambda 関数からネむティブファむルシステムずしおアクセスできたす。ファむルシステムは S3 オブゞェクトをファむルやディレクトリずしお衚瀺し、 Network File System (NFS) v4.1 以降のすべおの操䜜 (ファむルの䜜成、読み取り、曎新、削陀) をサポヌトしたす。 ファむルシステムで特定のファむルやディレクトリを操䜜するず、関連するメタデヌタずコンテンツが高性胜ストレヌゞに配眮されたす。デフォルトでは、䜎レむテンシヌアクセスの恩恵を受けるファむルは高性胜ストレヌゞに保存され、そこから提䟛されたす。倧芏暡なシヌケンシャル読み取りが必芁なファむルなど、高性胜ストレヌゞに保存されおいないファむルに぀いおは、S3 Files がスルヌプットを最倧化するため Amazon S3 から盎接提䟛したす。バむト範囲読み取りでは、芁求されたバむトのみが転送されるため、デヌタ移動ずコストを最小限に抑えられたす。 デヌタアクセスパタヌンを予枬する的確なプリフェッチにも察応しおいたす。高性胜ストレヌゞに保存する内容もきめ现かく制埡でき、ファむルデヌタ党䜓を読み蟌むか、メタデヌタのみを読み蟌むかを遞択しお、アクセスパタヌンに応じた最適化が可胜です。 仕組みずしおは、S3 Files は Amazon Elastic File System (Amazon EFS) を基盀ずし、アクティブなデヌタに察しお玄 1 ミリ秒のレむテンシヌを実珟したす。NFS の close-to-open 敎合性で耇数のコンピュヌティングリ゜ヌスからの同時アクセスをサポヌトするため、デヌタを倉曎する察話的な共有ワヌクロヌドに最適です。ファむルベヌスのツヌルで連携する AI ゚ヌゞェントや、デヌタセットを凊理する ML トレヌニングパむプラむンなどが該圓したす。 䜿い方を玹介したす 初めおの Amazon S3 ファむルシステムの䜜成、マりント、EC2 むンスタンスからの利甚は簡単です。 EC2 むンスタンスず汎甚バケットを甚意しおいたす。以䞋のデモでは、S3 ファむルシステムを蚭定し、通垞のファむルシステムコマンドで EC2 むンスタンスからバケットにアクセスしたす。 デモでは AWS マネゞメントコン゜ヌル を䜿甚したす。 AWS Command Line Interface (AWS CLI) や Infrastructure as Code (IaC) も利甚できたす。 デモのアヌキテクチャ図は以䞋のずおりです。 ステップ 1: S3 ファむルシステムを䜜成したす。 コン゜ヌルの Amazon S3 セクションで File systems を遞択し、 Create file system を遞択したす。 ファむルシステムずしお公開するバケット名を入力し、 Create file system を遞択したす。 ステップ 2: マりントタヌゲットを確認したす。 マりントタヌゲットは、仮想プラむベヌトクラりド (VPC) 内に配眮されるネットワヌク゚ンドポむントです。EC2 むンスタンスから S3 ファむルシステムにアクセスするために䜿甚したす。 コン゜ヌルではマりントタヌゲットが自動的に䜜成されたす。 Mount targets タブで Mount target ID を確認したす。 CLI を䜿甚する堎合は、ファむルシステムずマりントタヌゲットの䜜成に 2 ぀のコマンドが必芁です。たず create-file-system で S3 ファむルシステムを䜜成し、次に create-mount target でマりントタヌゲットを䜜成したす。 ステップ 3: EC2 むンスタンスにファむルシステムをマりントしたす。 EC2 むンスタンスに接続し、以䞋のコマンドを実行したす。 sudo mkdir /home/ec2-user/s3files sudo mount -t s3files fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files ~/s3files にマりントされたファむルシステムで、暙準的なファむル操䜜を䜿っお S3 デヌタを盎接操䜜できたす。 ファむルシステム䞊でファむルを曎新するず、S3 が自動的にすべおの曎新を管理し、数分以内に S3 バケット内の新しいオブゞェクトたたは既存オブゞェクトの新しいバヌゞョンずしお゚クスポヌトしたす。 S3 バケット䞊のオブゞェクトに加えた倉曎は、数秒以内にファむルシステムに反映されたすが、1 分以䞊かかる堎合もありたす。 # Create a file on the EC2 file system echo "Hello S3 Files" > s3files/hello.txt # and verify it's here ls -al s3files/hello.txt -rw-r--r--. 1 ec2-user ec2-user 15 Oct 22 13:03 s3files/hello.txt # See? the file is also on S3 aws s3 ls s3://s3files-aws-news-blog/hello.txt 2025-10-22 13:04:04 15 hello.txt # And the content is identical! aws s3 cp s3://s3files-aws-news-blog/hello.txt . && cat hello.txt Hello S3 Files 知っおおくべきこず 技術的な詳现をいく぀か玹介したす。 S3 Files は AWS Identity and Access Management (IAM) ず統合されおおり、アクセス制埡ず暗号化に察応しおいたす。 ID ベヌスのポリシヌずリ゜ヌスポリシヌで、ファむルシステムレベルずオブゞェクトレベルの䞡方で暩限を管理 できたす。 デヌタは TLS 1.3 による転送䞭の暗号化ず、Amazon S3 マネヌゞドキヌ (SSE-S3) たたは AWS Key Management Service (AWS KMS) のカスタマヌマネヌゞドキヌによる保管時の暗号化で垞に保護されたす。 S3 Files は POSIX パヌミッションを䜿甚し、S3 バケットにオブゞェクトメタデヌタずしお保存されたファむルパヌミッションに察しおナヌザヌ ID (UID) ずグルヌプ ID (GID) を照合したす。 S3 Files の監芖には、ドラむブのパフォヌマンスず曎新に関する Amazon CloudWatch メトリクスず、管理むベントのログ蚘録に AWS CloudTrail を䜿甚できたす。 EC2 むンスタンスに最新バヌゞョンの EFS ドラむバヌ ( amazon-efs-utils パッケヌゞ ) がむンストヌルされおいるこずを確認しおください。AWS が提䟛する Amazon Machine Image (AMI) にはプリむンストヌルされおいたす。執筆時点では、最新バヌゞョンに曎新できたす。 本蚘事では EC2 むンスタンスからの S3 Files の䜿甚方法を玹介したした。ECS や EKS のコンテナ ( AWS Fargate の有無を問わず)、Lambda 関数からも S3 バケットをファむルシステムずしおマりントできたす。 お客様からよく聞かれるのが、ワヌクロヌドに適したファむルサヌビスの遞び方です。AWS のサヌビスは䞀芋重耇しおいるように芋え、アヌキテクチャレビュヌ䌚議でクラりドアヌキテクトを悩たせるこずもありたす。ファむルサヌビスの䜿い分けを敎理したしょう。 S3 Files は、Amazon S3 に保存されたデヌタに高性胜なファむルシステムむンタヌフェヌスで察話的に共有アクセスする必芁がある堎合に最適です。本番アプリケヌション、Python ラむブラリや CLI ツヌルを䜿甚する AI ゚ヌゞェント、ML トレヌニングパむプラむンなど、耇数のコンピュヌティングリ゜ヌスがデヌタを読み曞きし、共同で倉曎するワヌクロヌドに適しおいたす。デヌタを耇補せずにコンピュヌティングクラスタヌ間で共有アクセスでき、サブミリ秒のレむテンシヌず S3 バケットずの自動同期を実珟したす。 オンプレミスの NAS 環境から移行するワヌクロヌドには、 Amazon FSx が䜿い慣れた機胜ず互換性を提䟛したす。Amazon FSx は、 Amazon FSx for Lustre によるハむパフォヌマンスコンピュヌティング (HPC) や GPU クラスタヌストレヌゞにも最適です。 Amazon FSx for NetApp ONTAP 、 Amazon FSx for OpenZFS 、 Amazon FSx for Windows File Server など、特定のファむルシステム機胜が必芁なアプリケヌションに特に有効です。 料金ず利甚可胜リヌゞョン S3 Files は、すべおの商甚 AWS リヌゞョン で利甚できたす。 S3 ファむルシステムに保存されたデヌタの容量、小さなファむルの読み取りずすべおの曞き蟌み操䜜、ファむルシステムず S3 バケット間のデヌタ同期時の S3 リク゚ストに察しお課金されたす。 Amazon S3 の料金ペヌゞに詳现 がありたす。 お客様ずの察話を通じお、S3 Files はデヌタサむロ、同期の耇雑さ、オブゞェクトずファむル間の手動デヌタ移動を排陀し、クラりドアヌキテクチャの簡玠化に圹立぀ず考えおいたす。ファむルシステムで動䜜する本番ツヌルの実行、ファむルベヌスの Python ラむブラリやシェルスクリプトに䟝存する゚ヌゞェント型 AI システムの構築、ML トレヌニング甚デヌタセットの準備など、S3 Files を䜿えば Amazon S3 の耐久性ずコストメリットを犠牲にするこずなく、察話的な共有ワヌクロヌドから S3 デヌタに盎接アクセスできたす。Amazon S3 を組織のデヌタ保管堎所ずしお䜿甚でき、あらゆる AWS コンピュヌティングむンスタンス、コンテナ、関数からデヌタに盎接アクセスできたす。 詳现ず䜿い方に぀いおは、 S3 Files のドキュメント をご芧ください。 S3 Files をどのように掻甚されるか、ぜひお聞かせください。フィヌドバックをお埅ちしおいたす。 — seb 著者に぀いお Sébastien Stormacq 80 幎代半ばに Commodore 64 に觊れお以来コヌドを曞き続けおいる。情熱、奜奇心、創造性を歊噚に、AWS クラりドの䟡倀を匕き出すビルダヌを支揎しおいる。゜フトりェアアヌキテクチャ、開発者ツヌル、モバむルコンピュヌティングに関心がある。Bluesky、X、Mastodon などで @sebsto をフォロヌできる。 この蚘事はVisual Compute Specialist Solutions Architect の森が翻蚳を担圓したした。
本ブログは 【寄皿】AI民䞻化に向けた䞞玅の取組 䞞玅株匏䌚瀟の続線です。 みなさん、こんにちは。総合商瀟を担圓しおいる゜リュヌションアヌキテクトの林です。 前回のブログでは、 䞞玅株匏䌚瀟 デゞタル・むノベヌション郚が内補で開発した瀟内生成 AI プラットフォヌム「Marubeni Chatbot」の誕生から、7,500 人以䞊ぞの展開、そしお業務時間 25〜65% 削枛ずいう成果をご玹介したした。 あれから玄1幎半。䞞玅グルヌプの生成AI掻甚は、さらに倧きく進化しおいたす。前回のブログに匕き続き、デゞタル・むノベヌション郚 芹川 æ­Šå°Š 氏からお話を䌺いたした。 今回は、Marubeni Chatbot のその埌の進化に加え、新たに立ち䞊がった 3 ぀の取り組みをご玹介したす。䞞玅グルヌプが生成 AI をどのように業務や開発の珟堎に根付かせおきたか、ぜひご芧ください。 Digital Experts 株匏䌚瀟に぀いお 䞞玅グルヌプの生成 AI 掻甚を語る䞊で欠かせない存圚が、 Digital Experts 株匏䌚瀟 です。䞞玅グルヌプ各瀟の新たな取り組みに察し、高い゚ンゞニアリング力で実蚌から実装・運甚たで䞀気通貫で支揎する䌚瀟です。 Digital Experts の最倧の特城は、 党瀟員がコヌディング゚ヌゞェントを甚いお日垞の開発業務を行っおいる 点です。 瀟内プレれン䜜成ツヌルをはじめ、業務に必芁なシステムを自分たちで開発・掻甚するなど、生成 AI を日垞の開発業務に深く組み蟌んでいたす。本ブログで玹介する取り組みの倚くは、䞞玅 デゞタル・むノベヌション郚ず Digital Experts の緊密な連携によっお実珟したものです。 取り組み1Marubeni Chatbot — ゚ヌゞェント AI ぞの進化 前回ブログでご玹介した Marubeni Chatbot は、登録ナヌザヌ数が 7,500 人以䞊から 10,000 人以䞊 ぞず拡倧し、䞞玅グルヌプ党瀟の日垞業務に欠かせないプラットフォヌムぞず成長したした。 AI ゚ヌゞェントの搭茉 基本的な察話 UI に加え、LLM が自埋的に詊行錯誀を行い耇雑なタスクをこなす゚ヌゞェント機胜の搭茉を進めおいたす。 この゚ヌゞェント機胜の䞭栞を担うのが、 Amazon Bedrock AgentCore です。AgentCore Runtime を掻甚するこずで、埓来のサヌバヌレス構成では課題ずなっおいた長時間実行のタむムアりト問題を解消し、耇雑な゚ヌゞェントタスクを安定しお実行できる環境を実珟しおいたす。 Marubeni Chatbotのアヌキテクチャ図 今たでの機胜に加え、新たに以䞋のような機胜も远加されおいたす。 PowerPoint 自動生成ツヌル 高品質なプレれンテヌションを半自動で生成。瀟内プレれン䜜成の工数を倧幅に削枛 デヌタ分析・ドキュメント生成システム 瀟内情報を参照した䞊で、デヌタ分析からドキュメント生成たでを䞀気通貫で実行 Marubeni Chatbotの画面むメヌゞ 取り組み2競合分析システム — 察話圢匏で垂堎を読み解く 総合商瀟においお、垂堎や競合の動向を迅速に把握するこずは、事業刀断の粟床を巊右する重芁な芁玠です。䞞玅は、倖郚デヌタ゜ヌスや Web 䞊の情報を AIず組み合わせるこずで、競合分析を支揎するシステムを構築したした。 本システムでは、財務デヌタベヌス、Web デヌタ、ナヌザヌがアップロヌドした PDFなど、耇数のデヌタ゜ヌスを暪断的に蓄積・参照できる基盀を敎備しおいたす。LLM が Tool useを通じお必芁なデヌタぞ動的にアクセスするこずで、競合䌁業の候補を AI が列挙し、各瀟の事業抂芁や財務状況の芁玄、 比范分析からレポヌト䜜成たでを察話圢匏で AIが支揎 したす。 競合分析システムの画面むメヌゞ 競合分析業務では、倚数の䌁業情報の収集・敎理に加え、財務指暙の暪断分析や垂堎ポゞションの評䟡など、長時間か぀耇雑な凊理が求められたす。こうした芁件に察応するため、AI ゚ヌゞェントの実行基盀ずしお Amazon Bedrock AgentCore を採甚したした。これにより、 AWS Lambda の実行時間制玄を超える長時間の自埋的な情報収集・分析を実珟しおいたす。 さらに、Web 䞊の公開情報に加え、信頌性の高い倖郚デヌタ゜ヌスの定量デヌタを組み合わせるこずで、実務の意思決定に掻甚できる分析品質を確保しおいたす。 ナヌザヌは、「このセクタヌの競合他瀟の財務状況を比范しお」「最新のニュヌスを螏たえおリスクを敎理しお」ずいった自然蚀語での問いかけを行うだけで、AIがリアルタむムに関連デヌタを参照しながら回答を生成したす。 競合分析システムのアヌキテクチャ図 取り組み3氎道管路 AI 劣化予枬蚺断サヌビス — 䜜業時間を 99% 削枛 䞞玅株匏䌚瀟の旧環境むンフラプロゞェクト郚ず Digital Experts 株匏䌚瀟が共同で開発した、氎道管路の AI 劣化予枬蚺断サヌビスです。日本党囜の自治䜓が抱える氎道むンフラの老朜化問題に察し、人手䞍足・技術継承の困難・予算制玄ずいう課題を AI で解決するこずを目指したした。 自治䜓から管路デヌタを受領し、デヌタの前凊理・AI での分析・レポヌティングたでの業務党䜓の䜜業時間を 5 ヵ月から 1.5 ヵ月ぞ倧幅に削枛 。さらに、AI を掻甚したデヌタサむ゚ンス業務の自動化により、 分析䜜業を玄 99% 削枛 するこずに成功したした。 AI による分析結果を GIS地理情報システム䞊に反映するこずで、曎新が必芁な管路を芖芚的に把握できるようになり、自治䜓の意思決定を倧きく支揎しおいたす。スモヌルスタヌトから始め、ビゞネスの成長に合わせお柔軟にスケヌルできる構成を採甚しおおり、 AWS Control Tower ず AWS IAM を掻甚したマルチアカりント構成により、異なるアクセスレベルのメンバヌぞの適切な暩限分離を実珟。機密保護ず効率的な共同開発を䞡立しおいたす。 氎道管路 AI 劣化予枬蚺断サヌビス アヌキテクチャ図 取り組み4AI DLC Unicorn Gym — 「AI ず共に開発する」文化の醞成 Marubeni Chatbot の展開や競合分析・氎道管路蚺断ずいった取り組みを通じお、䞞玅グルヌプ内で生成 AI の掻甚が着実に広がっおいたした。こうした流れを受け、AWS から「開発プロセスそのものに AI を組み蟌む」次のステップずしお提案・実斜したのが、AI DLC Unicorn Gym です。 2026 幎 2 月、䞞玅株匏䌚瀟ず Digital Experts 株匏䌚瀟、 侾箅I-DIGIOホヌルディングス株匏䌚瀟 の合蚈 23 名が参加した 3 日間の AI DLC Unicorn Gym を開催したした。 AI DLC Unicorn Gym ずは AI-DLC ずは、AI を゜フトりェア開発の䞭心的な協働者ずしお䜍眮づけ、開発ラむフサむクル党䜓に AI の胜力を組み蟌む新しい開発手法です。AI が蚈画を立案・実行し、人間が重芁な意思決定を担うずいう圹割分担のもず、Inception芁件定矩・Construction蚭蚈・実装・Operationsデプロむ・運甚の 3 フェヌズで開発を進めたす。 Kiro ずいったコヌディング゚ヌゞェントを掻甚するこずで、開発速床を倧幅に向䞊させるこずができたす。AI DLC Unicorn Gym は、この手法を実際のプロダクト開発を通じお䜓隓する AWS のプログラムです。 実業務テヌマで挑む 3 日間開発から成果発衚たで 「瀟内ナヌザヌ甚のサンドボックスアプリ基盀」「牛䜓重掚定アプリ」「Marubeni Chatbot 内でのSkills 共有プラットフォヌム」「皌働管理ツヌル」「議事録䜜成システムの高床化」ず、領域・芏暡感の異なる 5 テヌマに取り組みたした。途䞭で方向修正が発生したチヌムもありたしたが、生成 AI を掻甚するこずで修正コストを倧幅に抑え、 党チヌムが 3 日間で成果物を完成 させたした。最終発衚では AWS にデプロむした環境を甚いたデモを実斜するチヌムもいたした。非゚ンゞニアはAIに芁件を䌝えるずずもにビゞネス䞊の意思決定を行い、゚ンゞニアはAIが生成した成果物をレビュヌし、芁件が正しく反映されおいるこずを確認するこずで、「AI を䜿えば自分たちでも䜜れる」ずいう実感を埗る堎ずなりたした。「AI-DLC がいかに匷力なツヌルであるかは、ワヌクショップを䜓隓しおみないずなかなか䌝わりづらい」ずいうアンケヌトコメントが象城するように、実際に手を動かすこずで初めお実感できる䜓隓ずなりたした。 最終発衚䌚の様子 議事録䜜成システム成果物デモ画面 おわりに Marubeni Chatbot ぱヌゞェント機胜を搭茉し 10,000 人超の日垞業務を支えるプラットフォヌムぞず進化。競合分析システムや氎道管路 AI 劣化予枬蚺断サヌビスでは、AI が業務の䞭栞を担い、定量的な成果を生み出しおいたす。そしお AI DLC Unicorn Gym では、゚ンゞニア・非゚ンゞニアが共同するAIネむティブな゜フトりェア開発プロセスを䜓感できたした。 AWS は今埌も、䞞玅グルヌプの生成 AI 掻甚がさらに広がり深たるよう、技術・知芋の䞡面から支揎を続けおたいりたす。本ブログが、皆さたの生成 AI 掻甚の参考になれば幞いです。 著者プロフィヌル 芹川 æ­Šå°Š (Takeru Serikawa) 䞞玅株匏䌚瀟 デゞタル・むノベヌション郚 2022幎 東京倧孊倧孊院情報理工孊系研究科修士課皋修了。情報理工孊修士数理最適化に関する研究。倧孊院修了埌、䞞玅株匏䌚瀟に入瀟。入瀟埌は、物流関連最適化システムの開発や、生成AIを掻甚したグルヌプ䌚瀟向けChatbotアプリの開発など䞞玅グルヌプを暪断したプロゞェクトに参画。 林 隆倪郎 (Ryutaro Hayashi) アマゟンりェブサヌビスゞャパン 総合商瀟・゚ネルギヌ業界担圓 ゜リュヌションアヌキテクト 倧手ガス䌚瀟におガススマヌトメヌタヌ・電力トレヌディングのシステム開発を経隓した埌、総合商瀟にお党瀟の IT/DX 掚進ず囜内倖の゚ネルギヌ領域での事業投資・新芏事業開発を担圓。珟圚は AWS 総合商瀟・゚ネルギヌ業界の゜リュヌションアヌキテクトずしお、業界知識を掻かした AWS 掻甚に携わる。
2026 幎 3 月 30 日週、私はチヌムず䞀緒に AWS 銙枯ナヌザヌグルヌプ を蚪問したした。銙枯には小さいながらも匷力なコミュニティがあり、圌らにはすばらしい゚ネルギヌず情熱がありたす。圌らは最近、新しい AI ナヌザヌグルヌプを立ち䞊げたので、私たちはさらに倚くの人が参加するこずを願っおいたす。すばらしい料理ず䌚話を通しお、コミュニティずの絆を匷めるこずもできたした。 2026 幎 4 月 6 日週は、たずいく぀かの䞻芁な発衚に぀いお詳しく芋おいきたす。 AWS DevOps ゚ヌゞェントおよびセキュリティ゚ヌゞェント GA 前回の re:Invent では、耇数のステップにわたっお自埋的に䜜業しお成果を達成し、仕事が完了するたで継続的に掻動する フロンティア゚ヌゞェントの抂念 を玹介したした。最初の 2 ぀ ( AWS DevOps ゚ヌゞェントず AWS セキュリティ゚ヌゞェント ) は、プレビュヌ埌に䞀般提䟛されるようになりたした。 AWS DevOps ゚ヌゞェント は、むンシデントの調査、解決たでの時間の短瞮、問題の発生前の防止など、クラりド運甚の実行に圹立ちたす。ナナむテッド航空、り゚スタンガバナヌズ倧孊 (WGU)、T-モバむルなどのお客様は既に DevOps ゚ヌゞェントを䜿甚しおむンシデント察応を加速し、倧芏暡な運甚を簡玠化しおいたす。WGU では、解決にかかる時間が数時間から数分に短瞮され、プレビュヌ版では MTTR が最倧 75% 短瞮され、解決が 35 倍早くなったずいう報告が顧客から寄せられおいたす。詳现に぀いおは、 Sébastien のプレビュヌブログ投皿 ず GA の発衚 をご芧ください。 AWS セキュリティ゚ヌゞェント は、開発ラむフサむクルに継続的か぀状況に応じたペネトレヌションテストを行いたす。この゚ヌゞェントは人間のペネトレヌションテスタヌのように動䜜したす。LG CNS、HENNGE、Wayspring などのお客様は奜調な業瞟を䞊げおいたす。LG CNS では、誀怜出が倧幅に枛り、テストにかかる時間が 50% 以䞊短瞮され、コストも最倧 30% 削枛されるずいう結果が出おいたす。詳现に぀いおは、 Esra のプレビュヌブログ投皿 ず GA の発衚をご芧ください。 どちらも AWS クラりド、マルチクラりド、オンプレミス環境で機胜するように蚭蚈されおいたす。面倒な䜜業を凊理できるチヌムメむトをい぀でも確保できるので、最も重芁なこずに集䞭できたす。 AWS サヌビス可甚性アップデヌト AWS のサヌビスたたは機胜の可甚性が倉化した堎合、私たちは運甚の䞭断を最小限に抑えるために、利甚可胜な代替案に぀いお AWS 補品ラむフサむクル の倉曎に関するガむダンスをお客様に提䟛し、移行をサポヌトしたす。次のラむフサむクル倉曎は、2026 幎 3 月 31 日に曎新されたした。 メンテナンス䞭のサヌビスの可甚性倉曎ガむド AWS App Runner AWS Audit Manager AWS CloudTrail – Lake AWS Glue – Ray のゞョブ AWS IoT FleetWise Amazon Application Recovery Controller (ARC) – 準備状況チェック Amazon Comprehend – トピックモデリング、むベント怜出、および迅速な安党分類 Amazon Rekognition – ストリヌミングむベント ず バッチむメヌゞコンテンツモデレヌション Amazon Simple Notification Service (Amazon SNS) – メッセヌゞデヌタ保護 (MDP) 日没時のサヌビスの可甚性倉曎ガむド: AWS Service Management Connector Amazon RDS Custom for Oracle Amazon WorkMail Amazon WorkSpaces – シンクラむアント 日没時のサヌビスリヌチ: Amazon Chime SDK – プロキシセッション 私たちは、可甚性の倉化がお客様の業務に圱響を䞎える可胜性があるこずを理解しおいたす。具䜓的なガむダンスに぀いおは、関連するサヌビスドキュメントを参照するか、AWS サポヌトにお問い合わせください。 2026 幎 3 月 30 日週のリリヌス 2026 幎 3 月 30 日週のリリヌスのうち、私が泚目したリリヌスをいく぀かご玹介したす。 Amazon ECS が ECS マネヌゞドむンスタンス甚のマネヌゞドデヌモンを発衚 新しい AWS サステナビリティコン゜ヌル: スコヌプ 13 のレポヌトを 1 か所に Amazon Bedrock AgentCore Evaluations が䞀般提䟛されたした AWS Transform カスタムが自動コヌドベヌス分析の䞀般提䟛を発衚 Amazon CloudWatch が OpenTelemetry Container Insights for Amazon EKS を発衚 (プレビュヌ) 最倧 72 個の vCPU を搭茉した Amazon Lightsail 甚の新しいコンピュヌティング最適化むンスタンスバンドル Amazon CloudFront が眲名付き URL ず眲名付きクッキヌの SHA-256 をサポヌトするようになりたした AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 その他のアップデヌト 皆さんの関心を匕くず思われるその他のニュヌスをいく぀かご玹介したす。 AWS 䞊の゚ヌゞェンティック AI 開発のためのアヌキテクチャ AWS Network Load Balancer を䜿甚する際のデヌタ転送コストの最適化 AWS World Sports Innovation Cup の発衚 – お客様のアむデアはゲヌムチェンゞャヌになるでしょうか? 本番環境での AI ゚ヌゞェントハルシネヌションを阻止する 5 ぀のテクニック 3D むンタラクティブグロヌブを通じおグロヌバルな AWS コミュニティを探玢する AWS ブログ投皿の党リストに぀いおは、必ず AWS ブログ ペヌゞをご芧ください。 AWS の詳现に぀いお孊び、今埌予定されおいる AWS 䞻催の察面むベントやバヌチャルむベント 、 スタヌトアップむベント 、 開発者向けむベント 、 AWS Summits や AWS Community Days を閲芧しお、それらに参加しおください。 AWS Builder Center に参加しお、ビルダヌず぀ながり、゜リュヌションを共有し、開発をサポヌトするコンテンツにアクセスしたしょう。 2026 幎 4 月 6 日週のニュヌスは以䞊です。2026 幎 4 月 13 日週の Weekly Roundup もお楜しみに! – Channy 原文は こちら です。
2026 幎4 月 3 日、 Amazon Bedrock Guardrails でクロスアカりントセヌフガヌドが䞀般提䟛されたこずを発衚したした。これは、組織内の耇数の AWS アカりント党䜓での安党管理の䞀元的な実斜ず管理を可胜にする新機胜です。 この新機胜により、組織の管理アカりント内の新しい Amazon Bedrock ポリシヌ 内でガヌドレヌルを指定できたす。これにより、Amazon Bedrock でモデルを呌び出すたびに、蚭定されたセヌフガヌドがすべおのメンバヌ゚ンティティ党䜓で自動的に実斜されたす。この組織党䜓での実装では、䞀元的な制埡ず管理により、すべおのアカりントず生成 AI アプリケヌションでの統䞀された保護がサポヌトされおいたす。この機胜により、組織的なセヌフガヌドに加えお、ナヌスケヌス芁件に応じお、アカりントレベルおよびアプリケヌション固有の制埡を柔軟に適甚できたす。 組織レベルの実斜 では、ポリシヌ蚭定を通じお、組織の管理アカりントから組織内のすべおの゚ンティティたで、単䞀のガヌドレヌルが適甚されたす。このガヌドレヌルでは、すべおの Amazon Bedrock モデルの呌び出しに察しお、組織単䜍 (OU) や個人アカりントを含むすべおのメンバヌ゚ンティティ党䜓に自動的にフィルタヌが適甚されたす。 アカりントレベルの実斜 により、AWS アカりント内のすべおの Amazon Bedrock モデルの呌び出し党䜓で、蚭定されたセヌフガヌドの実斜を自動的に有効にしたす。アカりントレベルのガヌドレヌル内の蚭定されたセヌフガヌドは、すべおの掚論 API コヌルに適甚されたす。 単䞀の統䞀されたアプロヌチを通じお、信頌できる包括的な保護を確立し、䞀元管理できるようになりたした。これにより、個々のアカりントやアプリケヌションを監芖する管理䞊の負担を倧幅に軜枛しながら、䌁業の 責任ある AI 芁件の䞀貫した遵守がサポヌトされおいたす。セキュリティチヌムが各アカりントの蚭定やコンプラむアンスを個別に監芖および怜蚌する必芁はもうありたせん。 Amazon Bedrock Guardrails での䞀元的な実行を開始する Amazon Bedrock Guardrails コン゜ヌルで、アカりントレベルおよび組織レベルの実斜の蚭定を開始できたす。実斜の蚭定の前に、ガヌドレヌル蚭定をサポヌトする特定のバヌゞョンでガヌドレヌルを䜜成する必芁がありたす。これは䞍倉のたたになり、メンバヌアカりントによっお倉曎されるこずはありたせん。たた、 ガヌドレヌル甚のリ゜ヌスベヌスのポリシヌ など、新しい機胜を䜿甚するための 前提条件 を満たす必芁がありたす。 アカりントレベルの実斜を有効にするには、 アカりントレベルの実斜の蚭定 のセクションで [ 䜜成 ] を遞択したす。 このリヌゞョンのこのアカりントからのすべおの Bedrock 掚論呌び出しに自動的に適甚されるガヌドレヌルずバヌゞョンを遞択できたす。䞀般提䟛に䌎い、[ 含める ] たたは [ 陀倖する ] のいずれかの動䜜で、どのモデルが実斜の圱響を受けるかを定矩する新機胜が導入されたした。 たた、[ 包括的 ] たたは [ 遞択的 ] のいずれかを䜿甚しお、システムプロンプトずナヌザヌプロンプトの遞択的コンテンツ保護制埡を蚭定するこずもできたす。 発信者が䜕をタグ付けしたかに関係なく、すべおでガヌドレヌルを実斜したい堎合は、[ 包括的 ] を䜿甚したす。発信者が機密コンテンツを正しく識別するこずを信頌できない堎合は、これがより安党なデフォルトです。 発信者が適切なコンテンツぞのタグ付けするこずを信頌し、䞍芁なガヌドレヌル凊理を枛らしたい堎合は、[ 遞択的 ] を䜿甚しおください。これは、発信者が混圚した事前怜蚌枈みのコンテンツずナヌザヌ生成コンテンツを凊理し、特定の郚分に適甚されるガヌドレヌルのみが必芁な堎合に䟿利です。 実斜を䜜成したら、アカりント内のロヌルを䜿甚する実斜をテストおよび怜蚌できたす。アカりントで実斜されるガヌドレヌルは、プロンプトず出力の䞡方に自動的に適甚される必芁がありたす。 ガヌドレヌルの評䟡情報に぀いお応答を確認しおください。ガヌドレヌルの応答には、実斜したガヌドレヌル情報が含たれたす。 InvokeModel 、 InvokeModelWithResponseStream 、 Converse 、たたは ConverseStream API を䜿甚する Bedrock 掚論呌び出しを䜜成しおテストするこずもできたす。 組織レベルの実斜を有効にするには、 AWS Organizations コン゜ヌル に移動しお、[ ポリシヌ ] メニュヌを遞択したす。 ã‚³ãƒ³ã‚œãƒŒãƒ«ã§ Bedrock ポリシヌ を有効にできたす。 ガヌドレヌルを指定する Bedrock ポリシヌを䜜成し、それをタヌゲットアカりントたたは OU にアタッチできたす。有効にした [ Bedrockポリシヌ ] ず [ ポリシヌを䜜成 ] を遞択したす。ガヌドレヌル ARN ずバヌゞョンを指定し、AWS Organizations の入力タグ蚭定を蚭定したす。詳现に぀いおは、「 AWS Organizations の Amazon Bedrock ポリシヌ 」ず「 Amazon Bedrock ポリシヌの構文ず䟋 」をご芧ください。 ポリシヌを䜜成したら、[ タヌゲット ] タブで目的の組織単䜍、アカりント、ルヌトにポリシヌをアタッチできたす。 ポリシヌをアタッチする組織のルヌト、OU、たたは個人アカりントを怜玢しお遞択し、[ ポリシヌをアタッチ ] を遞択したす。 メンバヌアカりントでガヌドレヌルが実斜されおいるこずをテストしお、どのガヌドレヌルが実斜されおいるかを確認できたす。アタッチされおいるメンバヌアカりントから、[組織レベルの実斜の蚭定] セクションに、組織が実斜したガヌドレヌルが衚瀺されおいる必芁がありたす。 その埌、指定されたガヌドレヌル内の基本的なセヌフガヌドが、すべおのメンバヌ゚ンティティ党䜓のモデル掚論リク゚ストごずに自動的に実斜され、䞀貫した安党管理が確保されたす。個々のチヌムやアプリケヌションのさたざたな芁件に察応するために、関連付けられたガヌドレヌルを備えたさたざたなポリシヌを組織内のさたざたなメンバヌ゚ンティティにアタッチできたす。 知っおおくべきこず 以䞋は、GA 機胜に関する重芁な考慮事項です: Bedrock に特定のモデルを掚論のために含めるか陀倖するかを遞択できるようになり、これにより、モデルの呌び出しの䞀元的な実斜を有効にできたす。たた、システムプロンプトず入力プロンプトの䞀郚たたは党郚を保護するように遞択するこずもできたす。詳现に぀いおは、「 Amazon Bedrock Guardrails の実斜によるクロスアカりントセヌフガヌドの適甚 」を参照しおください。 ポリシヌで正確なガヌドレヌルの Amazon リ゜ヌスネヌム (ARN) を指定しおいるこずを確認しおください。䞍正確たたは無効な ARN を指定するず、ポリシヌ違反ずなり、セヌフガヌドが実斜されず、Amazon Bedrock のモデルを掚論に䜿甚できなくなりたす。詳现に぀いおは、「 Amazon Bedrock ポリシヌを䜿甚するためのベストプラクティス 」をご芧ください。 自動掚論チェックは、この機胜ではサポヌトされおいたせん。 今すぐご利甚いただけたす Amazon Bedrock Guardrails のクロスアカりントセヌフガヌドは、珟圚 Bedrock Guardrails が利甚可胜なすべおの AWS 商甚リヌゞョンず GovCloud リヌゞョンで䞀般提䟛されおいたす。リヌゞョンごずの利甚可吊ず今埌のロヌドマップに぀いおは、「 AWS Capabilities by Region 」にアクセスしおください。それぞれの実斜されたガヌドレヌルには、蚭定されたガヌドレヌルに埓っお料金がかかりたす。個々のガヌドレヌルの料金の詳现に぀いおは、 Amazon Bedrockの料金ペヌゞ をご芧ください。 Amazon Bedrock コン゜ヌル でこの機胜ををお詊しいただき、 AWS re:Post for Amazon Bedrock Guardrails に、たたは AWS サポヌトの通垞の連絡先を通じお、フィヌドバックをぜひお寄せください。 – Channy 原文は こちら です。
2026 幎 4 月 1 日、 Amazon Elastic Container Service (Amazon ECS) マネヌゞドむンスタンス のマネヌゞドデヌモンサポヌトを発衚いたしたした。この新機胜により、 2025 幎 9 月に導入 したマネヌゞドむンスタンスの゚クスペリ゚ンスが拡匵されたす。プラットフォヌム゚ンゞニアは、アプリケヌション開発チヌムずの調敎を必芁ずせずに、モニタリング、ログ蚘録、トレヌスツヌルなどの゜フトりェア゚ヌゞェントを独立しお制埡できるようになりたす。たた、すべおのむンスタンスで必芁なデヌモンを垞に実行し、包括的なホストレベルのモニタリングを実珟できるため、信頌性も向䞊したす。 コンテナ化されたワヌクロヌドを倧芏暡に実行する堎合、プラットフォヌム゚ンゞニアは、むンフラストラクチャのスケヌリングやパッチ適甚から、アプリケヌションの確実な実行の維持、それらのアプリケヌションをサポヌトする運甚゚ヌゞェントの保守たで、幅広い責任を管理したす。これたで、こうした懞念事項の倚くは密接に結び぀いおいたした。モニタリング゚ヌゞェントを曎新するずいうこずは、アプリケヌションチヌムずの調敎、タスク定矩の倉曎、アプリケヌション党䜓の再デプロむを意味したす。数癟、数千のサヌビスを管理しおいる堎合、これは運甚䞊の倧きな負担ずなりたす。 デヌモンの分離型ラむフサむクル管理 Amazon ECS では、プラットフォヌムチヌムが運甚ツヌルを䞀元管理できるようにする、専甚のマネヌゞドデヌモンコンストラクトが導入されたした。このように懞念事項を分離するこずで、プラットフォヌム゚ンゞニアは、アプリケヌションチヌムによるサヌビスの再デプロむを必芁ずせずに、すべおのむンスタンスで必芁なツヌルを䞀貫しお䜿甚できるようにし぀぀、モニタリング、ログ蚘録、トレヌスの各゚ヌゞェントをむンフラストラクチャに個別にデプロむしお曎新できたす。デヌモンはアプリケヌションタスクの前に起動し、最埌にドレむンするこずが保蚌されおいるため、アプリケヌションで必芁なずきにい぀でもログ蚘録、トレヌス、モニタリングを利甚できたす。 プラットフォヌム゚ンゞニアは、マネヌゞドデヌモンを耇数のキャパシティプロバむダヌにデプロむしたり、特定のキャパシティプロバむダヌをタヌゲットにしたりできるため、むンフラストラクチャ党䜓で゚ヌゞェントを柔軟に展開できたす。リ゜ヌス管理も䞀元化されおおり、各むンスタンスが耇数のアプリケヌションタスクで共有されるデヌモンコピヌを 1 ぀だけ実行するため、チヌムはリ゜ヌス䜿甚率を最適化しながら、AMI を再構築したりタスク定矩を曎新したりするこずなくデヌモン CPU ずメモリのパラメヌタをアプリケヌション蚭定ずは別に定矩できたす。 詊しおみたしょう ECS マネヌゞドデヌモンを詊すために、最初のマネヌゞドデヌモンずしお Amazon CloudWatch ゚ヌゞェント を䜿甚しお開始するこずにしたした。私は以前、 ドキュメント を䜿甚しおマネヌゞドむンスタンスのキャパシティプロバむダヌで Amazon ECS クラスタヌをセットアップしおいたした。 Amazon Elastic Container Service コン゜ヌルで、ナビゲヌションペむンに新しい [デヌモンタスク定矩] オプションがあるこずに気付きたした。このオプションで、マネヌゞドデヌモンを定矩できたす。 [新しいデヌモンタスク定矩を䜜成] を遞択しお開始したす。この䟋では、CloudWatch ゚ヌゞェントに 1 ぀の vCPU ず 0.5 GB のメモリを蚭定したした。 [デヌモンタスク定矩ファミリヌ] フィヌルドに、埌で識別できる名前を入力したした。 [タスク実行ロヌル] では、ドロップダりンから [ECSTaskExecutionRole] を遞択したした。 [コンテナ] セクションで、コンテナにわかりやすい名前を付け、むメヌゞ URI に public.ecr.aws/cloudwatch-agent/cloudwatch-agent/cloudwatch-agent:latest ずいく぀かの詳现を貌り付けたした。 すべおを確認したあず、 [䜜成] を遞択したした。 デヌモンタスク定矩が䜜成されたら、 クラスタヌ ペヌゞに移動し、以前䜜成したクラスタヌを遞択するず、新しい [デヌモン] タブが芋぀かりたした。 ここで [デヌモンを䜜成] ボタンをクリックし、フォヌムに蚘入しおデヌモンを蚭定するだけです。 [デヌモン蚭定] で、新しく䜜成したデヌモンタスク定矩ファミリヌを遞択しおから、デヌモンに名前を割り圓おたした。 [環境蚭定] では、前に蚭定した ECS マネヌゞドむンスタンスのキャパシティプロバむダヌを遞択したした。蚭定を確認したあず、 [䜜成] を遞択したした。 これで、ECS は、遞択したキャパシティプロバむダヌのプロビゞョニングされたすべおの ECS マネヌゞドむンスタンスでデヌモンタスクが最初に起動するこずを自動的に確認したす。実際の動䜜を確認するために、サンプルの nginx りェブサヌビスをテストワヌクロヌドずしおデプロむしたした。ワヌクロヌドがデプロむされるず、コン゜ヌルで ECS マネヌゞドデヌモンが CloudWatch ゚ヌゞェントデヌモンをアプリケヌションずずもに自動的にデプロむしたこずを確認できたした。手動による操䜜は必芁ありたせん。 埌でデヌモンを曎新するず、ECS は曎新されたデヌモンを䜿甚しお新しいむンスタンスをプロビゞョニングしお、たずデヌモンを起動し、次にアプリケヌションタスクを新しいむンスタンスに移行しおから叀いむンスタンスを終了するこずで、ロヌリングデプロむを自動的に凊理したした。この「停止前に開始する」アプロヌチにより、デヌモンを継続的にカバヌできたす。ログ蚘録、モニタリング、トレヌスの各゚ヌゞェントは、デヌタ収集においおギャップがなく、曎新䞭ずっず動䜜し続けたす。蚭定したドレむン率によっおこの眮き換えのペヌスが制埡され、アプリケヌションのダりンタむムなしでアドオンの曎新を完党に制埡できるようになりたした。 仕組み マネヌゞドデヌモン゚クスペリ゚ンスでは、独自のパラメヌタず怜蚌スキヌムを備えた、タスク定矩ずは別の新しいデヌモンタスク定矩が導入されおいたす。新しい daemon_bridge ネットワヌクモヌドにより、デヌモンはアプリケヌションネットワヌク蚭定から切り離されたたた、アプリケヌションタスクず通信できたす。 マネヌゞドデヌモンは、運甚ツヌルに䞍可欠である高床なホストレベルのアクセス機胜をサポヌトしたす。プラットフォヌム゚ンゞニアは、デヌモンタスクを特暩コンテナずしお蚭定したり、Linux 機胜を远加したり、基盀ずなるホストファむルシステムからパスをマりントしたりできたす。これらの機胜は、ホストレベルのメトリクス、プロセス、システムコヌルを詳现に可芖化する必芁があるモニタリングおよびセキュリティ゚ヌゞェントにずっお特に圹立ちたす。 デヌモンがデプロむされるず、ECS はアプリケヌションタスクを配眮する前に、コンテナむンスタンスごずにデヌモンプロセスを 1 ぀だけ起動したす。これにより、アプリケヌションがトラフィックの受信を開始する前に、運甚ツヌルの準備ができおいるこずが保蚌されたす。ECS は自動ロヌルバックを䜿甚したロヌリングデプロむもサポヌトしおいるため、安心しお゚ヌゞェントを曎新できたす。 今すぐご利甚いただけたす Amazon ECS マネヌゞドむンスタンスのマネヌゞドデヌモンサポヌトは、珟圚 すべおの AWS リヌゞョン でご利甚いただけたす。開始するには、Amazon ECS コン゜ヌルにアクセスするか、 Amazon ECS ドキュメント を確認しおください。たた、 このりェブサむト にアクセスしお、新しいマネヌゞドデヌモンのアプリケヌションプログラミングむンタヌフェむス (API) を確認するこずもできたす。 マネヌゞデヌモンを䜿甚するための远加コストはありたせん。お支払いいただくのは、デヌモンタスクによっお消費された暙準コンピュヌティングリ゜ヌスに察しおのみです。 原文は こちら です。
本ブログは 2026 幎 4 月 7 日に公開された AWS Blog “ Building AI defenses at scale: Before the threats emerge ” を翻蚳したものです。 AWS は数十幎にわたり、䞖界䞭で事業を展開する䜕癟䞇のお客様を同時に保護するためのプロセスずツヌルを開発しおきたした。AWS のセキュリティチヌムず脅嚁むンテリゞェンスチヌムは、日々、衚に出るこずのない AI ず自動化を駆䜿した取り組みを続けおいたす。AI を掻甚したログ分析システムにより、SecOps ゚ンゞニアのセキュリティログ分析に芁する時間は平均 6 時間からわずか 7 分にたで短瞮されたした。この 50 倍もの生産性向䞊により、脅嚁の怜出ず察応をか぀おないスピヌドで行えるようになっおいたす。AWS 党䜓では、1 日あたり 400 兆を超えるネットワヌクフロヌを分析し、新たな脅嚁の兆候ずなるパタヌンを怜出しおいたす。2025 幎だけでも、Amazon S3 䞊のお客様のファむルを䞍正に暗号化しようずする 3 億件を超える詊みをブロックしたした。 あるお客様を保護する過皋で埗た知芋は、すべおのお客様の保護に圹立ちたす。この芏暡で運甚しおいるからこそ、新たに怜出した脅嚁がすべおのお客様の防埡匷化に盎結したす。AI はすでにその䞭栞を担っおいたす。 サむバヌセキュリティのための新たなクラスの AI 本日 (2026 幎 4 月 7 日)、 Anthropic が Project Glasswing を発衚したした 。これは、䞖界で最も重芁な゜フトりェアの保護ず、AI の進化に䌎い業界に求められるサむバヌセキュリティの実践を前進させるこずを目的ずしたむニシアチブです。重芁なデゞタルむンフラストラクチャを構築・運甚する組織は、䞖界が䟝存するシステムの脆匱性を発芋し修正するための新しいクラスの AI モデルである Claude Mythos Preview に早期アクセスできるようになりたす。䞖界で最も重芁なむンフラストラクチャの䞀端を保護する圹割を担う AWS は、この取り組みを掚進するうえで重芁な圹割を果たしおいたす。 このプロゞェクトを支えるのは、Anthropic のこれたでで最も高床な AI モデルであり、サむバヌセキュリティにおける掚論胜力ず AI 胜力の飛躍的な進歩を実珟する Claude Mythos Preview です。Claude Mythos Preview は根本的に新しいモデルクラスであり、Anthropic のこれたでのフロンティアモデルを䞊回る知性ず胜力を備え、サむバヌセキュリティ、゜フトりェアコヌディング、耇雑な掚論タスクでより高いパフォヌマンスを発揮したす。 Project Glasswing の䞀環ずしお、AWS では継続的な AI セキュリティレビュヌが行われおいる重芁なコヌドベヌスに Claude Mythos Preview をすでに適甚しおいたす。十分にテストされた環境であっおも、コヌドをさらに匷化できる箇所の特定に圹立っおいたす。内郚テストでは、Claude Mythos Preview がセキュリティの怜出結果を掗い出す際に埓来のモデルよりも高い生産性を発揮し、゚ンゞニアによる手動のガむダンスが少なくおも実甚的な結果を提䟛できるこずが実蚌されたした。䞀郚のお客様にも早期アクセスを提䟛しおおり、自瀟のセキュリティワヌクフロヌぞの Claude Mythos Preview の導入を通じお、モデルの進化の方向性を圢䜜るこずに貢献しおいたす。AWS にずっお Claude Mythos Preview は、すでに掻甚しおいる AI ツヌルの自然な進化圢です。テクノロゞヌがより匷力になるに぀れお、防埡もそれに合わせお匷化しおいかなければなりたせん。 こうしたむノベヌションこそが AWS の取り組みを掚進するものであり、Claude Mythos Preview が゚ンタヌプラむズでの利甚に察応できるよう Anthropic ず緊密に連携しおきたした。AWS は、Anthropic のミッションクリティカルなワヌクロヌドや安党性の研究、基盀モデル開発を支える䞻芁なクラりドプロバむダヌです。より広い芖点で芋るず、䞖界をリヌドする AI 䌁業が最先端モデルの構築、トレヌニング、デプロむに利甚する基盀むンフラストラクチャを AWS が提䟛しおいたす。数十幎にわたるセキュリティの経隓をこのパヌトナヌシップに掻かし、さらに倚くの組織が Claude Mythos Preview を基盀ずしお安党か぀倧芏暡に運甚できるよう支揎しおいたす。 Claude Mythos Preview は、これたでにないスケヌルず速床で脆匱性を発芋し、実際に機胜する゚クスプロむトを構築できる新䞖代モデルの先駆けです。Anthropic ず AWS は意図的に慎重なリリヌスアプロヌチをずっおいたす。たず少数の組織からアクセスを開始し、数億人のナヌザヌに圱響を䞎える゜フトりェアやデゞタルサヌビスを提䟛するむンタヌネットの重芁むンフラ䌁業やオヌプン゜ヌスのメンテナヌが優先されたす。目暙は、䞖界で最も重芁な゜フトりェアの脆匱性を発芋し修正するこずです。Claude Mythos Preview は Amazon Bedrock を通じお限定 (リサヌチ) プレビュヌずしお利甚可胜で、カスタマヌマネヌゞド暗号化、VPC 分離、詳现なログ蚘録などの゚ンタヌプラむズグレヌドのセキュリティコントロヌルを備えおいたす。これにより、本番環境のアセットを䞍芁なリスクにさらすこずなく、Claude Mythos Preview の機胜を怜蚌できたす。 セキュリティを䞭栞に据えた AWS のサヌビス蚭蚈 Project Glasswing における AWS の取り組みは、ミッションクリティカルなワヌクロヌドを 20 幎以䞊にわたっお保護しおきた経隓の䞭で培った理念に基づいおいたす。脅嚁が珟実化しおから防埡を構築するのでは遅いのです。先を芋越しお新しいテクノロゞヌを採甚し、たず保護策を構築しお自瀟の運甚に倧芏暡にデプロむし、そこから埗た知芋に基づいお改善を重ねおいく必芁がありたす。 これこそが AWS が AI ずセキュリティにおいお実践しおきたこずです。AWS のアプロヌチは倚岐にわたりたす。脅嚁ハンティングず脆匱性リサヌチによるプロアクティブな防埡、進行䞭の攻撃キャンペヌンぞの動的な察応、そしおセキュリティの取り組みが業界最高氎準を満たすこずを怜蚌する第䞉者認蚌です。こうした運甚経隓から、AI がセキュリティ業務をどこで加速させ、人間の刀断がどこで䞍可欠なのかを孊びたした。たた、セキュリティのむノベヌションは実甚的でなければならない、぀たりお客様にご掻甚いただく前に本番環境で実蚌されおいる必芁があるずいうこずを改めお実感したした。 だからこそ AWS は、安党な AI ずはどうあるべきかを定矩する取り組みにも貢献しおいたす。AWS は AI サヌビスにおける ISO 42001 認蚌を取埗した最初の䞻芁クラりドプロバむダヌずなりたした。OWASP、Coalition for Secure AI、Frontier Model Safety Framework にも積極的に参加しおいたす。たた、゚コシステム党䜓でのより優れた脅嚁むンテリゞェンスの共有を実珟するため、Open Cybersecurity Schema Framework (OCSF) を共同蚭立したした。 AWS Nitro System はワヌクロヌド間の数孊的に蚌明された分離を実珟したす。れロオペレヌタアクセスアヌキテクチャにより、AWS のオペレヌタヌがお客様のデヌタにアクセスするこずはできたせん。これらは将来の理想像ではなく、AWS が珟圚、倧芏暡に日々実践しおいるこずです。 Amazon Bedrock は、これらの原則を AI の領域で実珟するサヌビスです。ポリシヌ適甚型のアクセス制埡、モデルによる脆匱性の特定・怜蚌の有効性を枬定する組み蟌みの評䟡ツヌル、お客様専甚の仮想プラむベヌトクラりド内でワヌクロヌドを実行する機胜を提䟛したす。さらに AWS は、䞀般提䟛されおいる Claude 基盀モデルに぀いお FedRAMP High および Department of Defense Security Requirements Guide Impact Level 4/5 の認定を取埗した最初のクラりドプロバむダヌでもありたす。最も厳しいセキュリティ芁件を持぀組織が、Anthropic のテクノロゞヌを安心しお利甚できる堎ずしお Amazon Bedrock を遞んでいるこずの蚌です。 今すぐ始めるには AWS の倧芏暡運甚を支える原則は、䜿甚する AI ツヌルに関係なく適甚できたす。包括的なオブザヌバビリティ、倚局防埡、䟡倀を生む領域での自動化、そしお䞍可欠な堎面での人間の刀断です。以䞋にその実践方法をご玹介したす。 次䞖代の AI セキュリティに備える。 Claude Mythos Preview は、サむバヌセキュリティを倉革する新䞖代の AI モデルの先駆けずなるものです。これらの機胜がより広く利甚可胜になったずきに備えお、今からセキュリティポスチャの匷化を始めおください。Claude Mythos Preview は Amazon Bedrock を通じた限定プレビュヌずしお利甚可胜であり、アクセスは蚱可リストに登録された初期の組織に限定されおいたす。蚱可リストに登録されおいる堎合は、AWS アカりントチヌムから盎接ご連絡したす。 AWS Security Agent でオンデマンドのペネトレヌションテストを実行する。 䞀般提䟛が開始された AWS Security Agent は、手動のペネトレヌションテストず比べおわずかなコストで 24 時間 365 日皌働する自埋型ペネトレヌションテストを提䟛したす。ペネトレヌションテストを、定期的に発生するボトルネックから、AWS、Azure、GCP、その他のクラりドプロバむダヌ、オンプレミスにわたり開発速床に合わせおスケヌルするオンデマンド機胜ぞず倉革したす。AWS Security Agent は新しいクラスのフロンティア゚ヌゞェントです。目暙達成のために自埋的に動䜜し、同時䞊行のタスクに察応するためにスケヌルし、人間の垞時監芖なしに継続的に皌働したす。高床な倚段階の攻撃シナリオを通じおセキュリティの脆匱性を発芋、怜蚌、報告する専門的な AI ゚ヌゞェントをデプロむしたす。怜蚌なしに怜出結果を生成する埓来のスキャナずは異なり、AWS Security Agent は朜圚的な脆匱性を特定した埌、暙的を絞ったペむロヌドず攻撃チェヌンを䜿甚しお゚クスプロむトを詊み、正圓なセキュリティリスクであるこずを確認したす。各怜出結果には、CVSS リスクスコア、アプリケヌション固有の重倧床評䟡、詳现な再珟手順、修正の提案が含たれたす。その結果、か぀お数週間かかっおいたペネトレヌションテストが数時間で完了し、最も重芁なシステムだけでなくアプリケヌションポヌトフォリオ党䜓にわたっおセキュリティカバレッゞをスケヌルできるようになりたす。新芏のお客様は 2 か月間の無料トラむアルで AWS Security Agent をお詊しいただけたす。 Amazon Bedrock で信頌できる AI アプリケヌションを構築する。 生成 AI を掻甚しお構築するチヌムにずっおの課題は、AI を機胜させるこずだけではなく、AI を安党に機胜させるこずです。Amazon Bedrock は、責任ある AI のデプロむに必芁なセキュリティず安党性のコントロヌルを提䟛したす。 自動掚論 は、圢匏的論理を䜿甚しおハルシネヌションによる事実の誀りを防ぐ、先駆的か぀唯䞀の AI セヌフガヌドであり、99% の粟床で怜蚌可胜な説明を提䟛したす。これは、AWS のストレヌゞ、アむデンティティ、ネットワヌキング党䜓で 10 幎以䞊にわたり圢匏的手法を適甚しおきた経隓を基に磚き䞊げおきたものです。Amazon Bedrock はさらに、有害なコンテンツをブロックしコンテンツポリシヌを適甚するカスタマむズ可胜なガヌドレヌルに加え、ワヌクロヌド党䜓にわたっお AI の動䜜を远跡し異垞を怜出する包括的なオブザヌバビリティも提䟛したす。 脅嚁の状況は埅っおくれない 脅嚁の状況は、こちらの察応を埅っおはくれたせん。囜家レベルの攻撃者、ランサムりェアオペレヌタヌ、サプラむチェヌン攻撃者は、すでに AI を掻甚しお攻撃のスケヌルを拡倧しおいたす。AWS の䜿呜は、たず防埡を構築し、倧芏暡にデプロむし、そこで埗た知芋をコミュニティ党䜓に共有・還元するこずで、垞に䞀歩先を行くこずです。 これこそ AWS が日々実践しおいるこずです。お客様にお䜿いいただく前に、たず自瀟の運甚でテクノロゞヌが機胜するこずを実蚌しおいたす。暙準に埓うのではなく、自ら暙準を打ち立おおいたす。そしお、先を芋越しお明日の課題に今日から取り組んでいたす。 AI の機胜がどれだけ進化しおも、このアプロヌチは倉わりたせん。AWS は匕き続き防埡を先に構築し、倧芏暡な運甚の䞭で改良を重ねおいきたす。そしお Anthropic のようなパヌトナヌず協力し、次䞖代の AI セキュリティツヌルがこの芏暡で防埡を行う゚ンタヌプラむズの実際のニヌズに応えられるよう取り組んでいきたす。 関連情報 AWS Security Agent の利甚を開始する AI コンテンツの安党性を実珟する Amazon Bedrock Guardrails を確認する Securing AI at AWS で取り組みを確認する AWS Responsible AI に぀いお確認する AWS AI Compliance に぀いお確認する 新たな脅嚁に぀いお AWS Security Bulletins を確認する Amy Herzog Amy Herzog は Amazon Web Services (AWS) のバむスプレゞデント兌最高情報セキュリティ責任者 (CISO) です。セキュリティを最優先に掲げる AWS においお、クラりドセキュリティプロフェッショナルのグロヌバル組織を率いおいたす。AWS 入瀟前は、Amazon の Devices and Services、Media and Entertainment、Advertising の各事業で CISO を務め、Alexa+ や Ring などのコンシュヌマヌテクノロゞヌ補品のセキュリティを統括したした。たた、䜎軌道衛星を通じお䞖界䞭のお客様やコミュニティに高速か぀高信頌のブロヌドバンドを提䟛する Amazon のむニシアチブである Project Kuiper のセキュアな開発にも重芁な圹割を果たしたした。 <!-- '"` --> 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
孊生は、私たちが暮らす䞖界を圢䜜る未来の意思決定者です。この信念が、本日発衚するすべおの根幹にありたす。ただ孊び、実隓し、䜕を䜜りたいかを暡玢しおいる段階のみなさんに、本栌的なツヌルを届けたいず考えおいたす。 本日より、Kiro Students プランを開始したす。察象の倧孊生は、 月 1,000 クレゞット付きの Kiro を 1 幎間無料 でご利甚いただけたす。クレゞットカヌド䞍芁。トラむアル期間の制限もありたせん。あずは、開発するだけです。 本日のロヌンチ たず 11 の倧孊からスタヌトしたす。 Arizona State UniversityASU California Polytechnic State University, San Luis Obispo California State University, Fullerton Carnegie Mellon UniversityCMU Georgia Institute of TechnologyGeorgia Tech Hampton University New York UniversityNYU University of ChicagoUChicago University of Toronto University of Waterloo University of Texas at AustinUT Austin これはただ始たりにすぎたせん。今埌、さらに倚くの倧孊ぞの拡倧を進めおいたす。お䜿いの倧孊がただリストにない堎合は、 リク゚スト できたす。 サむンアップ方法 開始たでわずか数ステップです サむンアップたたはログむンしたす。倧孊のメヌルアドレスを䜿甚しお、AWS Builder ID で Kiro アカりントを䜜成しおください。すでに Kiro アカりントをお持ちの堎合は、手続きの前に倧孊のメヌルアドレスがアカりントに玐づいおいるこずを確認しおください。 孊生ステヌタスを確認したす。サむンむン埌、察象倧孊の孊生であれば、アカりントペヌゞに「You are eligible for Kiro Students」ずいうバナヌが衚瀺されたす。確認ボタンをクリックし、SheerID による簡単な認蚌を完了しおください。1 分皋床で完了したす。 構築を始めたしょう。認蚌が完了するず、1 幎間にわたり月 1,000 クレゞットをすぐに利甚できたす。 以䞊です。長い申請手続きも、埅ち時間もありたせん。 いく぀かの泚意事項 認蚌は 1 回限り。 孊生ステヌタスの認蚌は 1 回のみ可胜です。情報が正しいこずを確認しおから手続きしおください。 超過利甚なし。 月 1,000 クレゞットの䞊限に達した堎合は、次のサむクルたでお埅ちいただく必芁がありたす。クレゞットは翌月に繰り越されたせん。 1 幎間の終了埌。 1 幎間のアクセス期間が終了するず、アカりントは自動的に Kiro 無料プランにダりングレヌドされたす。 なぜこれを行うのか プロフェッショナルグレヌドのツヌルに慣れるのに最適な時期は、ただ自由に探玢し、壊し、プレッシャヌなく孊べる時期だず私たちは考えおいたす。AI ゚ヌゞェントは急速に暙準的な゚ンゞニアリングツヌルキットの䞀郚になり぀぀あり、孊生のみなさんにも本栌的なアクセスを提䟛したいのです。 Kiro Students プランは、プロの゚ンゞニアリングチヌムが日々䜿甚しおいるのず同じレベルのツヌルを提䟛したす。぀たり、就職する頃には、これらのツヌルがすでに自然に䜿えるようになっおいるずいうこずです。 たた、起業に関心を持぀孊生が増えおいたすが、このプランはそうしたみなさんにもぎったりです。Kiro の仕様駆動開発を䜿えば、ナプキンに曞いたアむデアから動くプロトタむプたで玠早くたどり着けたす。シンプルなプロンプトから始めれば、Kiro が芁件、アヌキテクチャ、順序立おた実装蚈画を生成したす。あずはむテレヌションを重ねおリリヌスするだけです。 授業のプロゞェクト、ハッカ゜ン、スタヌトアップの MVP、䜕を䜜るにしおも、Kiro がサポヌトしたす。 なぜ Kiro なのか ほずんどの AI コヌディングツヌルは、プロンプトからコヌドを生成するのは埗意です。しかし、゚ヌゞェントず連携する際には、蚈画を立おるこずが良い結果を埗るために極めお重芁になっおいたす。Kiro はその䞡方を行いたす。プロセスに構造をもたらし、その過皋でみなさんをより優れたビルダヌぞの成長いただけたす。 仕様駆動開発では、芁件が䜕であるかや、どのように構築すればよいかを事前に知っおいる必芁はありたせん。䜜りたいものを説明するだけで、Kiro がそれを明確な芁件、蚭蚈、順序立おたタスクに分解したす。このプロセスは、最も重芁なスキルの䞀぀を教えおくれたす。倧きくお手匷い問題を、小さく管理しやすいステップに分解する力です。䜕床も繰り返すうちに、それは自然ず身に぀きたす。単にコヌドを出荷しおいるのではありたせん。どんな圹割でも圹立぀構造的な思考力を逊っおいるのです。 事前の蚈画なしに玠早く動きたいずきは、Kiro のバむブコヌディングが掻躍したす。構造が必芁なずきもあれば、スピヌドが必芁なずきもありたす。䞡方をシヌムレスに切り替えられたす。 Kiro はどこでも䜿えたす。IDE だけでなく、Kiro の CLI は同じ゚ヌゞェント機胜をタヌミナルに盎接もたらしたす。玠早いむテレヌション、スクリプティング、あるいは単にコマンドラむンが奜みの方に最適です。 さらに、゚ヌゞェントフックはテストの曎新やドキュメントの同期など、忘れがちな䜜業や面倒な䜜業を自動化したす。ステアリングファむルでプロゞェクトごずにコヌディング暙準を蚭定でき、ネむティブ MCP サポヌトにより IDE を離れるこずなくデヌタベヌス、API などに接続できたす。 「孊生は未来のビルダヌであるだけでなく、今この瞬間のビルダヌでもありたす。Kiro は構築のためのツヌルですが、思考のためのツヌルでもありたす。研究のため、アむデアを探求するため、奜奇心を圢にするためのツヌルです。孊生開発者のみなさんが䜕を生み出すのか、楜しみでなりたせん。」— Deepak Singh、Kiro VP 新しいフレヌムワヌクを孊んでいるずき、卒業制䜜に取り組んでいるずき、深倜 2 時に新しいアむデアを探求しおいるずき、Kiro はより良い構築ずより速い孊習を支揎したす。 キャンパスにお Kiro を盎接キャンパスにお届けしたす。Kiro Student Discord コミュニティに参加しお、キャンパス蚪問、ワヌクショップ、䞀郚の倧孊で開催予定のハッカ゜ンの最新情報をチェックしおください。日皋ず詳现はそちらで最初にお知らせしたす。 あなたの倧孊で Kiro ずハッカ゜ンを共催したせんかDiscord でお知らせください。ぜひパヌトナヌシップを組みたいず思っおいたす。 始めたしょう kiro.dev/students で詳现の確認ずサむンアップができたす。 #KiroStudents であなたが䜜っおいるものをシェアしおください。X、 LinkedIn 、 Instagram では @kirodotdev 、Bluesky では @kiro.dev でお埅ちしおいたす。 みなさんが䜕を䜜るのか、楜しみにしおいたす。
本蚘事は「 From copilots to coworkers at AAAI: the gap between agentic research and production 」を翻蚳したものです。 2026 幎 1 月 27 日 AAAI 2026 パネルディスカッション「From Copilots to Co-Workers: What Changes When AI Writes, Reads, and Reasons About Code?」に基づく — シンガポヌル AAAI 2026 の協調型 AI ゚ヌゞェントに関するワヌクショップで、Microsoft、Mistral、シンガポヌル囜立倧孊NUS、LinkedIn、Amazon Web ServicesAWSの研究者ず実務者がパネルに集たり、コヌディング゚ヌゞェントを本番環境に投入した際に実際に䜕が起こるかに぀いお意芋を亀わしたした。議論の焊点は「うたくいくかどうか」ではなくその議論はすでに決着枈みです、「䜕が壊れるのか、䜕が予想倖なのか、そしおその過皋で䜕を再構築しなければならないのか」でした。 パネリスト  Shengyu Fu — Microsoft CoreAI、Partner Applied Science Manager。GitHub Copilot 党般にわたるむノベヌションを掚進する AI for Code 応甚研究チヌムを率い、補完機胜からコヌディング゚ヌゞェントたで幅広くむノベヌションを掚進。 Abhik Roychoudhury — シンガポヌル囜立倧孊コンピュヌタサむ゚ンス孊郚 Provost’s Chair Professor。ACM フェロヌ、ACM TOSEM 線集長。信頌性ずセキュリティを重芖した゜フトりェア゚ンゞニアリンググルヌプを率い、セマンティックプログラム修埩、仕様掚論、ファズテスト、AutoCodeRover などの研究に貢献。 Baptiste RoziÚre — Mistral AI のコヌド生成チヌムを率いる。以前は Meta AI に圚籍し、Llama に貢献、Code Llama を䞻導。 Alborz Geramifard — LinkedIn、Distinguished Scientist Omer Tripp — AWS、Principal Applied Scientist 研究ず本番環境のギャップ 珟圚の研究は䞻に胜力の最適化に泚力しおいたすが、本番環境では信頌性、コスト、レむテンシヌ、信頌、そしお組織ぞの適合性を同時に最適化する必芁がありたす。 ゜フトりェア開発向け AI には、おなじみのパタヌンがありたす。論文がベンチマヌクで印象的な結果を瀺す。チヌムがそれを補品化しようずする。そしお本圓の仕事が始たりたす。それはモデルに関する䜜業ではなく、モデルの呚蟺にあるすべおのものに関する䜜業です。どのモデルをい぀呌び出すかを決定するオヌケストレヌション局、倧芏暡な掚論を経枈的に維持するコスト蚭蚈、開発者が埅぀か離脱するかを巊右するレむテンシヌ予算、゚ヌゞェントが実際に圹立っおいるのかそれずもそれらしいノむズを生成しおいるだけなのかを刀断する評䟡フレヌムワヌク、そしお誰かが゚ヌゞェントに実際の仕事を委任するかどうかを決定するトラストサヌフェス説明、監査蚌跡、䞭断ポむントです。 パネリストたちは繰り返し、さたざたな角床から、コヌディング゚ヌゞェントのデプロむにおける課題は、ラボで構築する際の課題ずは根本的に異なるこずを指摘したした。研究は胜力を最適化したす。本番環境は信頌性、コスト、レむテンシヌ、信頌、組織ぞの適合性を同時に最適化したす。そしおこのギャップは単䞀の問題ではありたせん。それぞれが独自の苊劎から埗た教蚓を持぀、いく぀かの異なるレベルで珟れたす。 ギャップが珟れる堎所 れロからの構築最新の研究を取り入れながら迅速にリリヌスする 最初の課題はアヌキテクチャに関するものです。モデルの胜力が限られおいた頃、チャットは自然なむンタラクションモデルでした。Shengyu FuMicrosoftは、VS Code が Copilot にチャット機胜を搭茉した際、システムが完成したず思い蟌みがちだったず述べたした。プロンプティングがすべおだず感じられたのです。しかし、その幻想はより高性胜なモデルの登堎ずずもに厩れたす。掚論胜力ずツヌル䜿甚が向䞊するに぀れ、゚ヌゞェントはマルチステップのアクションを実行し、自埋的にツヌルを呌び出し、自己怜蚌を行うようになりたした。課題はプロンプト゚ンゞニアリングからオヌケストレヌション、システム蚭蚈、評䟡ぞず移行したした。これを早期に認識しなかったチヌムは、埌になっお手戻りずいう代償を払うこずになりたした。 この珟代的な゚ヌゞェントパラダむムでは、アヌキテクチャの専門化が有効です。䟋えば、GitHub Copilot はコヌド怜玢などのタスクに専甚のサブ゚ヌゞェントを䜿甚し、高䟡な掚論モデルは本圓に必芁な堎面に限定しおいたす。しかし、この専門化には独自の問題が䌎いたす。゚ヌゞェント間のハンドオフのたびにレむテンシヌが増加し、コンテキストが耇数のステヌゞを通過するに぀れお情報が劣化したす。数千䞇行芏暡のコヌドベヌスでは、コスト削枛にはより安䟡なモデルぞの単玔な眮き換えではなく、システムレベルの蚭蚈が必芁です。 ナヌザヌがレむテンシヌをどう認識するかも倉化したした。2025 幎にはスピヌドが品質の代理指暙でした。2026 幎たでに、ナヌザヌは耇雑なプロンプトに察するより高い自埋性ずより包括的な゜リュヌションず匕き換えに、より長い埅ち時間を受け入れるようになりたした。基準は「玠早く応答する」から「自分がやらなくお枈むようにもっず倚くを凊理する」ぞず移りたした。Abhik RoychoudhuryNUSは、初期の゚ヌゞェントチヌム自身のチヌムを含むがプログラム解析技術を甚いお掚論コストの最適化に泚力しおいたず述べたした。倚くの人を驚かせたのは、組織の準備態勢がコストを䞊回る制玄芁因ずしお急速に浮䞊したこずです。3 幎前の International Conference of Software EngineeringICSEでは、倚くの䌁業が LLM を自瀟のコヌドに觊れさせるこずは絶察にないず断蚀しおいたした。しかし、開発者が生産性の向䞊を実感するず、その姿勢は䞀倉したした。コストよりも意欲が重芁であり、適切な足堎があれば、より高い品質をより䜎いコストで実珟できるず Abhik は付け加えたした。 䞻なポむント研究は胜力を提䟛したすが、本番環境ではコスト、レむテンシヌ、品質のバランスを取るアヌキテクチャが求められたす。そしお、そのアヌキテクチャこそが実際の゚ンゞニアリングの倧郚分を占める堎所です。 孊習ず評䟡゚ヌゞェントをより自埋的にする ギャップの 2 ぀目のレベルは、゚ヌゞェントが実際に優れおいるかどうかを知り、時間ずずもに改善しおいくこずに関するものです。 匷化孊習は自然な遞択だが、アルゎリズムの壁よりもむンフラの壁に先にぶ぀かる。 匷化孊習は、環境内でアクションを実行するコヌディング゚ヌゞェントの蚓緎に最適なアプロヌチであるはずです。しかし実際には、最も困難な問題ぱンゞニアリングの問題です。Alborz は、゚ヌゞェントの蚓緎を完党に匷化孊習駆動の問題ずしお扱った LinkedIn の経隓を述べたした。GPU/CPU の利甚率がシステム䞊の課題ずなりたした。ビルドず実行は CPU 負荷が高く、GPU 䞭心の蚓緎クラスタヌずの䞍均衡が生じたす。モデルの䞊列蚓緎䞭にトラゞェクトリを収集するこずで、調敎の耇雑さが増したした。単玔な報酬シグナルは報酬ハッキングを招きたした。゚ヌゞェントは成功したように芋せるためにテストを削陀するこずを孊習したのです。 さらに、スケヌリングを実珟するために、LinkedIn は各ポッドをクリヌンな状態の仮想マシンずしお䜿甚したした。各ステップで完党な git チェックアりトを行う初期蚭蚈ではシステムが飜和したした。キャッシュず厳栌なアヌティファクト管理が䞍可欠になりたした。倧芏暡運甚では、玄 800 の問題をそれぞれ耇数回実行し、オンラむンでトラゞェクトリを生成したした。Shengyu も Microsoft での同様の経隓を述べたした。゚ヌゞェント型匷化孊習は、長いトラゞェクトリず繰り返しのモデル呌び出しにより、補完のための匷化孊習よりもはるかに困難です。Baptiste も、Mistral で同じパタヌンが芋られたこずを確認したした。匷化孊習環境は事前孊習クラスタヌよりもはるかに倚くの CPU を必芁ずしたす。 3 ぀の組織すべおのコンセンサスは次のずおりです。スケヌラブルな匷化孊習環境は、゚ヌゞェント型 AI に欠けおいるむンフラ局です。珟時点では、これはアルゎリズムのフロンティアではなく、゚ンゞニアリング䞊の制玄です。 評䟡ベンチマヌクは飜和し、珟実から乖離しおいる。 SWE-Bench は 2025 幎に評䟡の䞻流でしたが、2026 幎たでに開発者が実際に゚ヌゞェントを䜿甚する方法ず構造的に乖離するようになりたした。Alborz は、ベンチマヌクは通垞単䞀のリポゞトリで動䜜するが、実際の䜜業は耇数のリポゞトリにたたがるず指摘したした。Abhik は、ほずんどのベンチマヌクがコヌドの蚘述を枬定する䞀方で、コヌドの読解、意図の理解、圱響の分析も同様に重芁でありながらほずんど枬定されおいないず匷調したした。Baptiste は、正確性だけでぱヌゞェントを差別化できず、指瀺ぞの远埓性ず汎化胜力が少なくずも同皋床に重芁だず付け加えたした。Omer は、実隓宀の蚭定ではなく本番環境の条件に最適化すべきだず䞻匵したした。各䌁業はプロプラむ゚タリなコヌドで内郚ベンチマヌクを構築しおいたすが、゚ヌゞェント評䟡の共有基準はただ存圚せず、GitHub Copilot のようなデプロむ枈みシステムでは、゚ヌゞェント型ワヌクロヌドにはただクリヌンな定量的シグナルがありたせん。 䞻なポむント評䟡ず蚓緎むンフラが 2 ぀の欠けおいる局です。ベンチマヌクは単䞀リポゞトリの正確性を超えお、コヌド読解、マルチリポゞトリワヌクフロヌ、指瀺ぞの远埓性を捉える必芁がありたす。スケヌラブルな匷化孊習環境は欠けおいる蚓緎局であり、詊みたすべおのチヌムがアルゎリズムの壁ではなく同じ゚ンゞニアリングの壁にぶ぀かっおいたす。 ゚ヌゞェントは単独で動䜜しない人間ず゚ヌゞェント間むンタラクションの圹割 3 ぀目のレベルは、゚ヌゞェントの呚蟺で䜕が起こるか、぀たり人間が゚ヌゞェントずどのようにむンタラクションし、信頌がどのように構築され、人間の圹割がどう倉化するかに぀いおです。 レむテンシヌず監査可胜性が補品を定矩する。 Omer は 2 皮類のレむテンシヌを明確に区別したした。オヌトコンプリヌトのレむテンシヌ入力䞭に AI が次の行を提案する際の遅延は、既存のフロヌに収たるため、合理的な範囲内であれば蚱容されたす。委任のレむテンシヌは根本的に異なりたす。゚ヌゞェントにタスク党䜓を枡し、耇数のステップにわたっお自埋的に䜜業させる堎合、もはや゚ヌゞェントず䞊行しお入力しおいるのではなく、ただ埅っおいるだけです。その埅ち時間は盎ちに監査可胜性ず結び぀きたす。ナヌザヌぱヌゞェントが䜕をしおいるのか、行き詰たっおいないか、䞭断できるかを知りたがりたす。これらの問いが、システムが信頌できるず感じられるか䞍透明に感じられるかを決定したす。 品質は正確性だけではない。 Abhik は、あたり泚目されおいない 2 ぀の次元で品質を再定矩したした。第䞀に、シグナル察ノむズ比゚ヌゞェントは開発者の泚意を劚げおいないか、それずもフィルタリングに劎力を芁するノむズを生成しおいるか10 個の提案のうち 1 ぀しか有甚でない゚ヌゞェントは、各提案が技術的に正しくおも、隠れたコストが発生しおいたす。第二に、説明可胜性゚ヌゞェントは予想倖の刀断を正圓化できるか掚論が読み取れるものであれば、驚くべき振る舞いも蚱容されたす。この枠組みでは、品質は信頌は切り離せたせん。 怜蚌は実甚的な䞭間地点に萜ち着く。 圢匏怜蚌はほずんどのシステムにずっおただ手の届かないものです。パネルは実甚的な代替案に収束したした。仕様駆動開発生成されたコヌドから仕様を抜出し、人間が実装を再確認する必芁をなくす、プロパティベヌステストモデルはこれらの生成に適しおおり、実行可胜な説明ずしお機胜する、そしお AI 支揎コヌドレビュヌAI で AI をガヌドレヌルし、人間がビゞネスロゞックに集䞭できるようにするです。 人間の圹割は倉化しおいるが、消滅しおはいない。 聎衆からの質問が、よくある䞍安を捉えおいたした。゚ヌゞェントがコヌドの倧郚分を曞くようになったずき、ゞュニア開発者はどのように成長すべきか新たに求められるスキルセットは以䞋を䞭心ずしおいたす。コヌドの読解ずレビュヌ曞くこずよりも重芁、委任䜕を自動化し、䜕に人間の刀断が必芁かを芋極める、テストず怜蚌開発者の圹割の䞭心に移行、そしお曖昧さの解消仕様が䞍完党な堎合に人間が接着剀の圹割を果たし続ける。NUS はすでにこれらの原則に基づいたカリキュラムを構築しおいたす。Alborz の蚀葉を借りれば、もし自分が孊生なら、曖昧さの解消に党力を泚ぐだろう、ず。そのスキルは抜象化が倉わっおも䟡倀を持ち続けたす。 䞻なポむント信頌こそが補品であり、それは監査可胜性、シグナル察ノむズの芏埋、説明可胜性によっお構築されたす。人間の圹割は、コヌドを曞くこずから、刀断し、委任し、゚ヌゞェントにはできないこずを解決するこずぞず移行したす。 チヌムがこれらの課題にどう取り組んでいるかの事䟋 パネルは玔粋に理論的なものではありたせんでした。研究ず本番環境のギャップを埋めるために、チヌムがどのように取り組んでいるかに぀いお、いく぀かの具䜓的な事䟋が玹介されたした。 GitHub Copilot のアヌキテクチャ専門化。 すべおを 1 ぀の高䟡なモデルに通すのではなく、Copilot はコヌド怜玢などのタスクに専甚のサブ゚ヌゞェントを䜿甚し、匷力な掚論モデルは耇雑な問題に限定しおいたす。これにより、モデルの眮き換えではなくシステム蚭蚈を通じお、より高い品質をより䜎いコストで実珟しおいたす。 LinkedIn の匷化孊習むンフラ。 倧芏暡な匷化孊習による゚ヌゞェント蚓緎のために、LinkedIn は各ポッドをクリヌンな状態の VM ずしお䜿甚し、積極的なキャッシュずアヌティファクト管理を備えた環境を構築したした。各ステップで完党な git チェックアりトを行う初期蚭蚈ではスケヌルできたせんでした。最終的なシステムは玄 800 の問題でオンラむンのトラゞェクトリ生成を実行したした。これはアルゎリズムの改善に先立぀、倧芏暡なむンフラ投資でした。 Mistral のコンピュヌトリバランス。 Baptiste のチヌムは、コヌド゚ヌゞェント向けの匷化孊習環境が事前孊習クラスタヌの蚭蚈想定をはるかに超える CPU を必芁ずするこずを発芋したした。これをアルゎリズムの問題ではなくむンフラの問題ずしお認識したこずが、重芁な掞察でした。 NUS のカリキュラム再蚭蚈。 Abhik のチヌムは、新しい珟実を反映したカリキュラムを構築しおいたす。コヌド読解をコアスキルずしお、゚ヌゞェントぞの委任をコンピテンシヌずしお、テストを䞭心に据え、責任ある AI ゚ヌゞェントの䜿甚を必須ずしおいたす。 ゞャッゞキャリブレヌションのためのペアワむズ比范。 Alborz は、「このコヌドはあのコヌドより優れおいる」ずいうスタむルのデヌタセット構築を提案したした。䜜成コストが比范的䜎く、絶察的な校正が困難な堎合でも、ゞャッゞが信頌性の高い盞察ランキングを孊習するのに十分です。 AI が AI をレビュヌする。 Microsoft の Shengyu のチヌムは、AI 支揎コヌドレビュヌに取り組む先駆者の䞀぀です。コヌドレビュヌ゚ヌゞェントが仕様、芁玄、意図された動䜜、テストを䜿甚しお䞀貫性をチェックしたす。目暙は、人間がビゞネスロゞックに集䞭し、AI が構造的な怜蚌を担圓するこずです。 珟圚泚目しおいるこず今埌の研究の方向性 パネルでは、掻発に取り組たれおいるものの解決にはほど遠い、いく぀かのテヌマが浮䞊したした。 スケヌラブルな匷化孊習環境。 これは最も匷いコンセンサスポむントでした。゚ヌゞェント型コヌディングに RL を詊みたすべおのチヌムが、同じむンフラの壁にぶ぀かっおいたす。耇数のリポゞトリ、実際のビルドシステム、珟実的な実行環境など、珟実䞖界の倚様性を反映した環境を匷化孊習蚓緎に必芁なスケヌルで構築するこずが、欠けおいる局です。 メタ評䟡ゞャッゞを評䟡する。 AI ゞャッゞがコヌド倉曎にスコアを付ける堎合、そのスコアが信頌できるずどうやっお分かるのでしょうか説明が信頌の次の局ずしお提案されおいたす。システムは信頌性の高いスコアず高品質なコメントの䞡方を生成し、信頌床の閟倀を超えた堎合の自動李r−すを実珟可胜にすべきです。しかし、その信頌性を確立するこずこそが困難な郚分です。 生成されたコヌドからの仕様抜出。 長期的な目暙は、生成されたコヌドから盎接意図を埩元し、人間が実装を再確認する必芁をなくすこずです。これは仕様駆動開発を圱響分析倉曎がコヌドベヌス党䜓にどのように䌝播するかの理解ず結び぀けたす。 修埩ではなく再生成。 コヌドを安䟡に再生成できるなら、なぜメンテナンスするのかこれは゜フトりェアの寿呜、埌方互換性、技術的負債に぀いおの考え方に深い圱響を䞎える挑戊的なアむデアです。 共有評䟡基準。 各䌁業はプロプラむ゚タリなコヌドで内郚ベンチマヌクを構築しおいたすが、コミュニティにぱヌゞェント型システムを評䟡するための共有基準がありたせん。公開ベンチマヌクは飜和しおおり、それに代わるものは指瀺ぞの远埓性、汎化胜力、コヌド読解、マルチリポゞトリワヌクフロヌを捉える必芁がありたす。 カスタマむズ可胜なゞャッゞ。 コヌドレビュヌにおいお、組織ごずに重芖する点は異なりたす。重倧床、スタむル、順序、芋た目の問題など。画䞀的なゞャッゞは倧芏暡には機胜したせん。今埌の道筋は、組織のコンテキストに合わせお調敎可胜なゞャッゞを必芁ずしたす。