2026 年 4 月 28 日の「 What’s Next with AWS 」では、マット ガーマン (AWS CEO）、Colleen Aubrey (Amazon Applied AI Solutions SVP)、Julia White (AWS CMO) と OpenAI のリーダーたちがディスカッションを行い、両社とそのお客様がエージェントを使って事業の運営方法をどのように変えているかについて話し合いました。 このイベントでの主な発表のまとめをご紹介したいと思います。 Amazon Quick は、あらゆる作業に接続し、ユーザーにとって重要な事柄を学び、ユーザーに代わって行動する AI アシスタントです。2026 年 4 月 28 日より、新しいデスクトップアプリの使用、無料プランとプラスプランへのサインアップ、チャットを使ったビジュアルアセットの生成が可能になり、Quick をさらに多くのアプリに簡単に接続できるようになります。 Quick の新しいデスクトップアプリ (プレビュー) : ブラウザを開かずにローカルファイル、カレンダー、コミュニケーションへの接続を維持することで、パーソナライズされたエクスペリエンスを創り出すことができます。 Quick の新しい無料プランとプラス料金プラン : 個人の E メールアドレス、または既存の Google、Apple、Github、Amazon 認証情報を使用して数分でサインアップできます。AWS アカウントは不要です。 ビジュアルアセットをその場で生成 : Quick では、洗練された文書、プレゼンテーション、インフォグラフィック、画像をチャットインターフェイスから直接作成できるようになりました。デザインスキルや何時間ものフォーマット調整を不要にするこの機能は、2026 年 4 月 28 日からご利用いただけます。 Quick をさらに多くのアプリに簡単に接続 : Quick は、ネイティブ統合の対象を拡大して、Google Workspace、Zoom、Airtable、Dropbox、Microsoft Teams を追加しました。この統合も2026 年 4 月 28 日から利用可能です。 詳細については、 Amazon News 記事 をご覧ください。 Amazon Connect は、単一製品から、Amazon Connect Decisions (サプライチェーン)、Talent (採用)、Customer (カスタマーエクスペリエンス)、および Health (ヘルスケア) の 4 つを含めた一連のエージェンティック AI ソリューションへと拡大されました。これらは既存のワークフローで機能するように設計されています。 Amazon Connect Decisions は、チームを後手に回る危機管理から先手を取る計画と意思決定へと移行させるサプライチェーン計画およびインテリジェンスソリューションです。30 年におよぶ Amazon の運営科学と 25 を超えるサプライチェーン特化型ツールを組み合わせる AI チームメイトは、ユーザーのビジネスに適応し、チームから学び、業務を継続的に改善します。 Amazon Connect Talent (プレビュー) は、スケール化された採用を管理するタレントアクイジションリーダーのために構築されたエージェンティック AI 採用ソリューションです。AI 主導の面接、科学的根拠に基づいたアセスメント、一貫的な評価を実現することで、採用担当者が優秀な候補者をより早く採用できるようにしながら、人間が持つ先入観を低減する柔軟な面接体験を応募者に提供します。 Amazon Connect Customer (旧称 Amazon Connect) は、音声、チャット、デジタルチャネルの全体でインテリジェントかつパーソナライズされたカスタマーエクスペリエンスを実現します。Amazon Connect Customer では、技術的な専門知識がなくても、組織が会話型 AI を数か月ではなく数週間でセットアップし、カスタマーエクスペリエンスを設定できる新しい設定機能が提供されるようになりました。 Amazon Connect Health は、エージェントによる患者確認、予約管理、患者インサイト、アンビエントドキュメンテーション、医療コーディングを提供することで、患者がより迅速に医療ケアを利用し、臨床医がケアにより多くの時間を費やし、スタッフが専門業務に専念できるようにします。 詳細については、 Amazon News 記事 をご覧ください。 AWS と OpenAI がパートナーシップを拡大 Amazon Bedrock に最新の OpenAI モデルを導入した AWS と OpenAI は、Codex on Amazon Bedrock の提供を開始するとともに、OpenAI を搭載した Amazon Bedrock Managed Agents をリリースしました (すべて限定プレビュー中)。これらは、企業が信頼するインフラストラクチャ上で、企業が求めるフロンティアインテリジェンスを提供します。 Amazon Bedrock 上の OpenAI モデル (限定プレビュー) : GPT-5.5 および GPT-5.4 を含めた最新の OpenAI モデルが、プレビューとして Amazon Bedrock で利用可能になります。OpenAI のフロンティアモデルは、統合されたキュリティ、ガバナンス、コスト管理を提供する、使い慣れた Bedrock API 経由で使用します。追加のインフラストラクチャを設定する必要も、新しいセキュリティモデルを学ぶ必要もありません。 Codex on Amazon Bedrock (限定プレビュー) : 既に大規模に運用されている AWS 環境内で OpenAI コーディングエージェントにアクセスできます。AWS 認証情報を使用した認証、Amazon Bedrock インフラストラクチャを使用した推論の処理、Codex 使用量の AWS クラウドコミットメントへの適用が可能です。Codex on Bedrock は Bedrock API 経由で利用でき、まずは Codex CLI、Codex デスクトップアプリ、Visual Studio Code 拡張機能からご利用いただけます。 OpenAI 搭載の Amazon Bedrock Managed Agents (限定プレビュー) : Amazon Bedrock Managed Agents は、フロンティア AI モデルと信頼の置ける AWS インフラストラクチャを組み合わせることで、お客様が本番環境対応の OpenAI 搭載エージェントをクラウドで迅速かつ簡単に構築できるようにします。OpenAI フロンティアモデルの可能性を最大限に引き出すように設計された OpenAI ハーネスを使用して構築されており、実行時間の短縮、推論の精緻化、長期的タスクの確実な制御を実現します。 詳細については、 AWS 最新情報記事 と Amazon News 記事 をご覧ください。 原文は こちら です。

本記事は 2026 年 4 月 30 日に公開された Ankit Sharma、Brian Beach による “ Amazon Q Developer end-of-support announcement ” を翻訳したものです。 私たちが Amazon Q Developer を立ち上げたときの目標は、AI による支援を開発者の作業の流れに直接組み込むことでした。お客様は VS Code、JetBrains、Eclipse、Visual Studio にわたって Q Developer を導入し、コード生成やデバッグ、チャットベースのガイダンスに活用してきました。Q Developer は、AI が日々の開発サイクルに欠かせない存在であることを証明しました。 この 1 年で私たちが学んだのは、もっともインパクトのある AI 開発者体験はコード生成や補完にとどまらないということです。開発者には、プロジェクト全体 —— アーキテクチャ、要件、テスト、そしてコードの背後にある意図 —— を理解する AI が必要です。そのためには、専用に設計された環境が必要になります。それこそが、私たちが Kiro を構築した理由です。 Kiro とは 、仕様駆動開発（spec-driven development）のためにゼロから構築されたエージェント型の開発環境（IDE、CLI）です。個別のプロンプトに反応するのではなく、構造化された仕様をもとに計画・実装・検証をコードベース全体にわたって進めます。主な機能は次のとおりです。 Specs —— 構築したいものを構造化された自然言語の要件として定義し、Kiro がそれをもとに実装を最初から最後まで進めます。 Hooks —— ファイル保存やコミットなどのイベント発生時に自動で実行されるトリガーです。手動での操作なしに、標準の適用、テストの実行、ドキュメントの更新を行います。 Steering files —— プロジェクト単位の設定ファイルで、アーキテクチャや規約、制約についての永続的なコンテキストを Kiro に提供します。 Custom subagents —— セキュリティレビュー、API 契約の検証、インフラのプロビジョニングなど、ドメイン固有のタスクのために自分で定義できる専用の AI エージェントです。 Powers —— Kiro のエージェント的な振る舞いを自分の開発プロセスに合わせて拡張できる、組み合わせ可能な機能モジュールです。 Kiro には、現在の Q Developer で開発者が活用している機能もすべて含まれています。エージェント型コーディング、インラインチャット、ターミナル統合、そして MCP サポートです。 何が変わるのか Amazon Q Developer の IDE プラグインと有償サブスクリプションは、2027 年 4 月 30 日にサポートを終了します。お客様には Kiro への移行期間として 12 か月が用意されています。 2026 年 5 月 15 日以降、新規サインアップを受け付けなくなります。 IDE プラグインから Builder ID を用いた Q Developer 無料利用枠アカウントの新規作成、および AWS コンソールからの Q Developer サブスクリプションの新規作成はブロックされます。 モデルが変更されます。  2026 年 5 月 29 日より、Q Developer Pro では Opus 4.6 が利用できなくなります。Opus 4.5 やその他の既存モデルは引き続き利用できます。Opus 4.7 を含む最新のコーディングモデルは Kiro でのみ利用できます。 既存のお客様はアクセスを維持できます。 Q Developer Pro サブスクリプションまたは Kiro サブスクリプションを通じて Q Developer をご利用の場合、2027 年 4 月 30 日までは引き続き Q Developer の IDE プラグインにアクセスできます。2026 年 5 月 15 日の変更は、Q Developer アカウントおよびサブスクリプションの新規サインアップにのみ影響します。 IDE プラグインの掲載は継続します。 Q Developer のプラグインは、4 つの IDE マーケットプレイスすべてで引き続き公開され、ユーザーを Kiro へ案内する非推奨の通知が表示されます。移行期間中は、既存ユーザー向けに重要なバグ修正の配信が継続されます。 何が変わらないのか AWS マネジメントコンソールおよび AWS ファーストパーティの体験（AWS マーケティングサイト、AWS ドキュメントサイト、AWS Console Mobile App、チャットアプリ向け Amazon Q Developer —— Slack および Microsoft Teams）における Amazon Q Developer は、今回のサポート終了の影響を受けず、引き続き AWS のお客様にご利用いただけます。これらのプロダクトで Q Developer をお使いのお客様は、現在のサブスクリプションの特典と機能を引き続きご利用いただけます。 お客様にお願いしたいこと 今日から Kiro を試してみてください。 kiro.dev から Kiro をダウンロードし、次のプロジェクトで仕様駆動開発を体験してみてください。 ご利用の IDE に合わせた 移行ガイド をご確認ください。 移行についてご質問がある場合は、担当の AWS アカウントチームまでお問い合わせください。 私たちは AI を活用した開発の未来にわくわくしており、すべてのお客様にとってこの移行ができる限りスムーズなものとなるよう取り組んでいきます。 翻訳は App Dev Consultant の宇賀神が担当しました。

こんにちは、ファインディでFindy Toolsの開発をしている本田です。 このたび、Findy Toolsの新機能として「アーキテクチャAI」をリリースしました。要件を入力するとAWSのアーキテクチャ図と設計の提案が生成される機能です。 findy.co.jp 今回の開発では、PM・仕様策定・スコープ定義・インフラ・FE/BE開発・テストまで、ほぼ一人で1か月で担当しました。そして、コーディングはほとんどClaude Codeに任せ、私自身はほぼコードを書いていません。 この記事では、そんな開発を進めるなかで分かったこと、難しかったこと、そして改めて実感したエンジニアの仕事について紹介します。 アーキテクチャAIについて 一人開発の全体像 エンジニアが価値とコストを自分で判断する 対話で判断の視野を広げる 動くもので共通認識を作る 自分の仕事は減らず、判断と意思決定の時間が増えた まとめ アーキテクチャAIについて 本題に入る前に、リリースした機能を軽く紹介させてください。 アーキテクチャAIは、Findy Toolsの中で提供している機能の1つで、「作りたいシステムの要件」を入力するとAWSを使った構成案とアーキテクチャ図、そして設計の考え方の解説がまとまった形で得られるものです。 ai-architecture.findy-tools.io アーキテクチャの設計はサービスの土台を決める工程で、経験や周辺知識の広さが問われる領域です。そうした知見を持った人に相談しづらい場面でも、構成の検討を前に進める助けになることを目指しています。 ここから先は、この機能を一人で1か月で作ったなかで気づいたことを中心に書いていきます。 一人開発の全体像 今回は、PMから開発、テスト、リリースまでを一人で担当しました。具体的には次のような範囲です。 プロダクトの方向性・優先順位の決定 仕様策定、スコープ定義 インフラの構築 フロントエンド・バックエンドの実装 テスト、リリース作業 開発のワークフローはシンプルで、だいたいこのサイクルを回していました。 GitHub Issueに「なぜ作るのか」「何を作るのか」を、PRDやユーザーストーリーの形で書く Claude CodeにIssueを渡して実装してもらう 自分は差分をレビューし、必要に応じて指示を出す 別チームのメンバーにレビューしてもらい、PRをマージする 実装の途中でも、作りたい背景やユーザーに届けたい価値に立ち戻って方針を調整することはよくありました。 仕様策定やUIのモック作成も、AIと壁打ちしながら進めていました。結果として、自分でコードを書いた量はごくわずかで、ほとんどの実装はClaude Codeが書いています。 一方で、「自分はほぼコードを書いていない」からといって仕事が少ないわけではありませんでした。むしろコーディング以外にやることが山ほどあるというのが実感です。 何を作るか、何を削るかの判断 仕様の細部に関する意思決定 技術選定 コードレビューと品質の担保 スケジュール管理とリリース計画 ここからは、この進め方で1か月やってみて感じたことを書いていきます。 エンジニアが価値とコストを自分で判断する 最も強く感じたのは、 エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携わることの強み です。 今回は一人で担当していたので、事業やプロダクトの意図、技術的な実現可能性、実装コストが、すべて自分の頭の中に揃っていました。「ユーザー価値として外せない部分はどこか」「コストをかける価値があるのはどこか」を、自分の中でつなげて考えながら開発を進めることができます。 具体的には、開発の途中でアーキテクチャ図の描画ライブラリを切り替える判断をしたり、リリースの2週間前になってからSNSで共有されたときに見栄えの良い画像を生成する機能を追加する判断をしたりと、方針転換を素早く進められました。技術的に成立するかをClaude Codeで素早く検証しつつ、プロダクトとして本当に必要かを自分で判断できたことで、価値とコストの両取りを狙える選択肢を見つけやすくなっていました。 体制を一人にしたことが本質ではないと思っています。大事なのはやはり、作る側のエンジニアがユーザー価値や事業価値を理解したうえで、コストと価値のバランスを判断しながら開発に携われているかだと、今回の開発を通じて改めて感じました。 対話で判断の視野を広げる 意思決定が速いのは良いことですが、速ければ良いわけではありません。一つの視点だけで速く判断を続けていると、気づかないうちに筋の悪い方に流れてしまいます。 ここで効いてきたのが、一人で担当していても孤立はしていないという体制づくりでした。 開発中は、事業部長・PO・デザイナと定期的に相談・共有できる場を持ち、それ以外の場面でもいつでもコミュニケーションを取れるようにしていました。 プロダクトとして何を大事にしているか 事業としてこの機能にどういう期待があるか デザインとして譲れない部分はどこか こうした観点を継続的にすり合わせることで、自分一人では見えていなかったより良い選択肢を見つけやすくしていました。 自分の頭の中だけで判断すると、どうしても視野が狭くなります。そこに他の立場の視点が入ると、「他にもっと良い選び方はないか」という問い直しができます。スピード重視の体制であっても、というよりスピード重視だからこそ、チームとの対話は欠かせないと感じました。 動くもので共通認識を作る もう1つ強く感じたのが、 速く見せられるもの・動くものを使って共通認識を作ることの効果 です。これ自体は昔からよく言われる話ですが、AIの力でぐっとやりやすくなりました。 今回は、実プロダクトの開発を始める前に、別リポジトリでPoCアプリを作り、ステークホルダーやインタビューにご協力いただいた方に、実際に見たり触ったりしてもらう時間を取りました。 PoCアプリの画面。デザインは作り込まず、ユーザーに価値を体験してもらうことを優先した。 文章やスライドだけで議論すると、どうしても抽象的になり、認識のズレに気づきにくくなります。動くものがあると、「これは欲しい」「ここは期待と違う」というフィードバックが具体的に返ってくるだけでなく、「どういう価値が得られそうか」という部分でも共通認識を作りやすくなります。 PoCを見たり触ったりしてもらうなかで見えてきたのは次のようなことです。 ユーザーが本当に価値を感じるのはどの部分か 最初はあると便利そうに見えたが、実際はなくても困らない機能 技術的に見落としていた制約や、逆に想定より軽く実現できそうな部分 PoCで得られたこれらの情報が土台になって、本開発のスコープと方針が定まっていきました。 AIで「仮に動くもの」を高速に作れるようになった強みを活かして、動くものを中心に仮説検証のサイクルを回せたこと が、1か月という限られた期間のなかで特に効いたポイントだと思います。 自分の仕事は減らず、判断と意思決定の時間が増えた ここまで書いてきたことを踏まえて、改めて感じたのは 少なくとも今回の自分の経験では、コーディングをAIに任せても、エンジニアとしてやることは減らなかった ということです。むしろ、本質的な判断に集中する必要が出てきた感覚でした。 今回の開発で自分が時間を使っていたのは、次のような部分です。 この機能を作る意味は何か、誰のどんな課題を解くのか スコープをどこまで広げ、どこで切るか どの技術を選び、どの技術を見送るか 出てきたコードが本当に要件を満たしているか、将来の運用に耐えるか どれも、意思決定と判断の仕事です。コーディングそのものをAIに任せられるからこそ、こうした判断に集中できる時間が増えました。 AIと協業するなかで変わる部分と変わらない部分があり、「コードを書く時間」は確実に減りますが、「エンジニアリングを行う時間」は減らない、むしろ増えている感覚でした。 まとめ ほぼ一人で1か月かけてアーキテクチャAIをリリースしてみて、次のことが学びとして残りました。 エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携われると、価値とコストの両取りを狙える選択肢を見つけやすい 速さだけを追うのではなく、複数の視点を対話で取り込んで選択肢を広げていく AIで仮の動くものを高速に作れるようになった強みを活かせば、短期間でも動くものを軸に仮説検証を回しやすい 少なくとも今回の自分の経験では、コーディングをAIに任せても仕事は減らず、判断と意思決定に集中する時間が増えた AIと一緒に開発する時代になっても、「何を作るか」「どう作るか」「なぜそれを選ぶか」を考え抜くことの大切さは変わらないなと、今回の開発を通じて改めて感じました。 アーキテクチャAIは次のページから触れます（Findy Toolsの会員登録が必要です）。ご興味のある方はぜひ試してみてください。 findy-tools.io ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers