はじめに ソフトクリエイトで Microsoft 365 の設計・構築を担当している、 野菜トリプル  です。 Entra/Intuneなどのインフラ、Defenderなどのセキュリティ製品の導入と並行して、SharePoint の設計・構築および管理者教育を担当しています。

ニューヨークの 9 月中旬には、特別なエネルギーがあります。パンプキンスパイスラテがたっぷりとあり、気温も下がってきていて、もうすぐセーターが必要となりそうな天気です。街は全速力で戻ってきました。AWS のローンチカレンダーも同様です。2026 年 9 月 14 日週、そのエネルギーは、Amazon Bedrock 上の新しいフロンティアモデル、Amazon Quick のデスクトップアプリ、そして AI エージェントで最大の効果を得ている開発者は単により良いツールを使っているだけではなく、働き方そのものが違うのだという示唆に表れていました。 では、早速見ていきましょう! 見出し OpenAI GPT-6 Astra が Amazon Bedrock 上で一般的に利用できるようになりました – GPT-6 Astra は OpenAI の最新かつ最も高性能なモデルであり、Amazon Bedrock 上で実行できるようになりました。より深い推論と判断、プロフェッショナル品質の文章とデザイン、および高度なコンピュータとブラウザの使用を、要求の厳しいビジネスワークフローにもたらします。このモデルは、最大 100 万の入力トークンのコンテキストウィンドウをサポートしているため、大規模なコードベース、長期契約、または大量のドキュメントコレクションを送信して、競合する入力を調整するように依頼できます。 サポートされている Amazon Bedrock API を使用して GPT-6 Astra を呼び出すことも、Amazon Bedrock のモデルを使用するように ChatGPT Work と Codex を設定することもできます。ローンチと並行して、OpenAI は ChatGPT Work 用の新しいエンタープライズプラグインを導入しています。これにより、Astra のブラウザ使用機能を一般的なビジネスアプリケーション全体に拡張できます。確立された AWS 統制は、ワークロードの保護、アクセスの管理、モデル呼び出しアクティビティの監査に役立ちます。また、推論データはモデルトレーニングには使用されません。 もっと読む 2026 年 9 月 7 日週のリリース 9 月 7 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon Quick デスクトップアプリが macOS と Windows で一般的に利用できるようになりました – Amazon Quick デスクトップアプリを使用すると、Amazon Quick をコンピュータに接続して、ローカルファイルを操作したり、バックグラウンドでカレンダー、E メール、ビジネスアプリに接続したままにしたりできます。会話、コンテキスト、エージェントはデスクトップとモバイル全体で同期したままであるため、ある画面で始めた作業が別の画面に引き継がれます。今回のリリースでは、Quick エージェントはコンピュータを閉じた後も実行され続けるため、オフィスを離れる前に長時間かかるタスクを開始し、帰宅中にモバイルアプリからの入力を追加して、帰宅時に結果を確認することができます。既存の Quick ユーザーは デスクトップアプリをダウンロード でき、モバイルアプリは Apple App Store と Google Play から入手できます。 もっと読む AWS Lambda が Lambda マネージドインスタンスで 90 分の関数タイムアウトをサポートするようになりました – Lambda マネージドインスタンスでの非同期呼び出しとイベントソースマッピング (ESM) 呼び出しでは、最大 90 分の関数タイムアウトを設定できるようになりました。これは、以前の 15 分の制限から 6 倍に増加しています。これにより、作業を複数の関数に分割することなく、より長い継続実行を必要とするデータ処理、メディアトランスコーディング、財務計算、AI 推論、およびバッチジョブへの扉が開かれます。同期呼び出しでは、既存の最大 15 分が維持されます。より長いタイムアウトは、非同期で呼び出された場合、最大 1 年間実行できる Lambda 永続関数内のステップにも適用されます。 もっと読む Amazon EBS Volume Clones がアカウント間でボリュームをコピーするようになりました – Amazon Elastic Block Store (Amazon EBS) Volume Clones は、ボリュームを別の AWS アカウントにコピーし、ターゲットアカウントの AWS Key Management Service (AWS KMS) キーで再暗号化できるようになりました。本番稼働用と開発用を別々のアカウントで維持する場合は、ボリュームを AWS Resource Access Manager (AWS RAM) と共有し、ターゲットアカウントに同じアベイラビリティーゾーンで新しいコピーを作成させることができます。例えば、本番稼働のデータベースボリュームを独立した開発のアカウントに複製できます。クロスアカウントコピーは、暗号化されていないボリュームやカスタマーマネージドキーで暗号化されたボリュームなど、すべてのボリュームタイプで機能します。 もっと読む 第 2 世代のシングルラック AWS Outposts が一般的に利用できるようになりました – 新しいシングルラック AWS Outposts は自己完結型の 42U ラックで、コンピューティング、ストレージ、ネットワーキングを 1 つのコンパクトなユニットにまとめたものであり、低レイテンシー、ローカルデータ処理、またはデータレジデンシーが必要で、設置面積を大きくする余地がない場所に適しています。シングルラックは最大 2,688 の vCPU と 100 TB の Amazon EBS ストレージを搭載し、汎用 (M7i、M8i)、コンピューティング最適化 (C7i、C8i)、メモリ最適化 (R7i、R8i)、Outposts アクセラレーテッドネットワーキングインスタンスなど、x86 搭載の最新の Amazon EC2 インスタンスをサポートしています。マルチラックの Outposts や AWS リージョンと同じ API、コンソール、自動化、ガバナンス、セキュリティコントロールを利用できます。 もっと読む Amazon OpenSearch Serverless が Vercel の v0 で利用可能になりました – Vercel の v0 内で検索または AI アプリケーションを自然言語で記述し、Amazon OpenSearch Serverless でバックアップされたフルスタックアプリを入手できるようになりました。v0 は、コレクションをプロビジョニングし、データをインデックス化し、OpenSearch Serverless エンドポイントを使用して検索拡張生成 (RAG) ワークロードのフルテキスト検索とベクトル検索を、v0 インターフェイスを離れることなく行います。OpenSearch Serverless はユーザーに代わってキャパシティをスケールアップ/ダウンするので、ユーザーはクラスター管理ではなくアプリケーションに集中できます。新しい AWS アカウントでプロビジョニングすることも、既存の AWS アカウントをリンクすることもできます。 もっと読む AWS Transform for .NET モダナイズが CLI を介して一般的に利用できるようになりました – AWS Transform カスタムで AWS マネージド .NET モダナイズを単一の CLI コマンドでトリガーし、インタラクティブに実行したり、既存のパイプラインにスクリプト化したりできます。CLI は、ウェブアプリケーション、Visual Studio IDE、Kiro パワー、および MCP エージェントでの既存の AWS Transform for .NET エクスペリエンスと並行して機能します。言語バージョンのアップグレード、フレームワークの移行、パフォーマンスの最適化、そのまま実行またはカスタマイズできる変換によるコードベースの分析に使用できます。.NET モダナイズの変換には、1 か月あたり 50,000 分の無料エージェント時間が含まれます。 もっと読む AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: Clare Liguori がフロンティアエンジニアリングについて発表 – 既に AI コーディングアシスタントを使用しているけれども、リリースがそれほど速くないと感じている場合は、ここから始めてください。AWS のシニアプリンシパルエンジニアである Clare Liguori が、 フロンティアエンジニアリング に関する実践者向けマニフェストを発表しました。これは、Amazon 全体のチームから引用された、AI エージェントによるソフトウェアの構築方法を変えるための 10 の原則です。議論は直接的です。ソフトウェア開発は、エージェントとの連携方法を変えた人と、コーディングツールだけを変えた人の 2 つに分かれています。フロンティアエンジニアリングはバイブコーディングではありません。最初の数週間は、ステアリングファイルの作成、コードベースのリファクタリング、エージェントの作業の細分化の学習に費やします。それらの週はゆっくりと感じられます。その後数週間は、ソフトウェアを直接構築するのではなく、ソフトウェアを構築するエージェントのセットアップを構築することになるため、劇的に速く感じられます。 世界中の学生に Kiro を 1 年間無料で提供 – Kiro Students プログラムは、11 の大学から 16 か国の 121 の新しい学校に拡大しています。対象となる学生は、1 か月あたり 1,000 クレジットで Kiro を 1 年間利用でき、プレミアムモデルや Kiro Web などの有料機能をすべて利用できます。クレジットカードやトライアルタイマーは不要です。IDE、CLI、ブラウザの Kiro Web、または Kiro Crew で作業できます。ユーザーが学生である場合は、 大学の E メールアドレスでサインアップ してください。 セキュリティのための AI の現状: 信頼にとって何が重要かを測定する – セキュリティチームはトリアージ、脅威モデリング、インシデント対応、コードレビューに AI を使用していますが、すべてにフラグを立てるツールでは時間の節約にはなりません。「 セキュリティのための AI の現状 」では、Anshumali Shrivastava 氏と Neha Rungta 氏が Deception Benchmark を紹介しました。これは、モデルが実際の脆弱性と、リスクが高いように見えるけれども実際には安全なコードを見分けることができるかどうかをテストする新しい評価です。ベンチマークには、16 の言語と 70 を超える共通脆弱性タイプ一覧 (CWE) カテゴリ全体で 14,822 のサンプルが含まれています。標準プロンプトでは、精度は 55% 前後に達しますが、精度とほぼ同じくらい不正確になる可能性も高く、テストした 12 のモデルのいずれも、偽陽性と偽陰性の両方を 10％ 未満に抑えていませんでした。投稿は、検証済みの採点のためのデータセット、ホワイトペーパー、および送信ワークフローにリンクしています。 AI を活用した足場により、フルスタック AWS アプリケーションを数分で構築 – Nx Plugin for AWS のバージョン 1.0 は、API、ウェブサイト、データベース、AI エージェント用の決定論的ジェネレーターと、それらを実行するための AWS インフラストラクチャを含むオープンソースのツールキットです。各ジェネレーターは、セキュリティ、オブザーバビリティ、および型安全性が既に実装された状態で、実際にデプロイ可能なコードを作成しているため、AI アシスタントは基盤を組み立て、アプリケーションロジックに労力を費やすことができます。Bingo Industries ではこれを利用して、マルチエージェント運用チャットボットをアイデアから本番稼働までを 3 週間未満で完了させました。プラグインは GitHub 上のオープンソース です。 pnpm create @aws/nx-workspace を使用してワークスペースを作成し、コーディングエージェントに付属の MCP サーバーを指定します。 コンピューティングでの最も古いアーキテクチャ – 「 All Things Distributed 」で、Werner Vogels 氏はお客様からよく聞かれる質問「AI が私の仕事を取ってしまうのか?」という質問から始めます。そして記憶に行き着きます。Kiro Crew で時間を過ごした後、彼は Jeff Hawkins の「 A Thousand Brains 」から、Crew がマークダウンファイル、ベクトルデータベース、およびキーバリューインデックスでどのように保存、統合、忘却を行うかまでの線をなぞります。彼の結論は、脳はコンピューティングでの最も古いアーキテクチャであり、それがどのように機能するかを最もよく考えた人が次のツールを構築するということです。さあ、構築しましょう。 AWS のブログ記事の詳細な一覧については、 AWS ブログ ページをご確認ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Summits – AWS Summits は、クラウドや AI のコミュニティが一堂に会し、つながり、学び、そして最新のテクノロジーを探求するための無料の対面イベントです。 今後の場所にはドバイ (9 月 30 日) が含まれます。 カレンダー全体 を閲覧してお近くのサミットを探したり、グローバルライブストリームやオンデマンドハブを介してセッションをストリーミングしたりできます。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。今後のイベントには、 ベルリンでの DACH (9 月 15 日) 、 ブダペストでの CEE (9 月 17 日) 、 オランダのユトレヒト (9 月 23 日) 、 南フロリダのマイアミ (10 月 14 日) 、 オーストラリアのブリスベン (10 月 16 日) などがあります。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 9 月 14 日週のニュースは以上です。9 月 21 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! – Micah この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

はじめまして。昨年新卒として株式会社ラクスに入社し、現在はHRソリューション開発部楽楽勤怠開発課でバックエンドエンジニアをしているmurosyoです。普段は楽楽勤怠の機能開発を担当しています。開発本部が掲げる 『顧客に価値を高速提供できるAIネイティブな開発組織への変革』 というビジョンのもと、ClaudeのSkillsやAgentsなどを整備・展開しています。 今回は、私がチームに導入を試みた 「Claude Codeを用いたIssueの自動解消」 の取り組みについて、構成の全貌や、実際にやってみて直面した「AIネイティブな開発ならではの壁」について、包み隠さずお話ししたいと思います。 はじめに 背景とゴール：「プログラムの不具合をいち早く修正し、お客様のユーザ体験を向上させたい」 Claude Codeを用いたIssue自動解消の全貌（実践編） フロー全体の解説と「Routines」の活用 今回の仕組みのメリット 導入で見えた「AIネイティブな開発」の壁 レビューの難しさ：コードの妥当性を測るための「深いドメイン理解」 AIとの協働をさらに進化させる：今後の展望 レビューコスト軽減への挑戦：意図を明確にするドキュメント化 Spec Driven Developmentへの拡大 おわりに はじめに 背景とゴール：「プログラムの不具合をいち早く修正し、お客様のユーザ体験を向上させたい」 自社で最も大切にしている価値観の一つが 「顧客志向」 です。お客様の業務課題を解決し、圧倒的に使いやすいサービスを提供し続けるためには、発生した不具合や細かな改善要望（Issue）に対して、いかに迅速にアプローチし、修正を届けるかが鍵となります。 しかし、日々の新規機能開発と並行してIssueを消化していくのは、どのチームにとってもリソース的に容易ではありません。「エンジニアの時間はより高度な設計やドメイン理解に使いたい。でも、目の前の不具合も一刻も早く直してユーザ体験を向上させたい」。 このジレンマを解消するためのゴールとして、 「Issueの調査からPR（Pull Request）作成までのフローをAIで半自動化し、開発効率を飛躍的に高めること」 を設定しました。 Claude Codeを用いたIssue自動解消の全貌（実践編） 試行錯誤の末、私は以下のようなフローでIssueの自動解消パイプラインを構築しました。 フロー全体の解説と「Routines」の活用 Claude Codeには、定型的なタスクを定義して実行できる「Routines」という機能があります。これを用いて、大きく2段階に分けたフローを構築しました。 ※下記に記載する内容はサンプルです。 Issueの起票 ユーザがリポジトリにIssueを起票します。 下記の内容を記載します。 発生している事象 再現手順 期待する挙動 修正対象のIssueにコード調査を依頼するラベルを付与します。 コード調査（1つ目のRoutine） コード調査の依頼が付与されているIssueを検索します。 見つかったIssueの内容を基に、Claude Codeがコードベースを検索・調査します。 ユーザへの確認事項の提示 コード調査の結果と、修正内容の実装にあたってClaudeが知りたい確認事項をIssue上にコメントとして記載します。 コード調査完了済みを示すラベルを付与します。 ユーザの回答 人間がそのコメントを確認し、確認事項に返信および修正方針が問題なければGOサインを、修正が必要ならフィードバックをIssueに返信します。 Issueに実装を依頼するラベルを付与します。 実装（2つ目のRoutine） コードの調査結果とユーザの回答結果を基に、Claude Codeが実際の実装（コードの変更）を行います。 AIレビューとテスト項目書の作成 実装後、Claude自身によるセルフレビューを実行し、さらに今回の修正に対するテスト項目書を自動作成します。 PRのDraft作成 以下の情報を記載したDraft PRを自動生成します。 実装内容のサマリー レビュー結果 テスト項目 対象のIssue番号 PRにはAIによって修正されたことがわかるラベルを付与します。 Issueには実装が完了し、PRの作成が行われたことを示すラベルを付与します。 ローカルでの動作検証と最終レビュー 最後に人間（ユーザ）が作成されたブランチをローカルに取り込み、動作検証を行ってPRをマージします。 今回の仕組みのメリット 今回の仕組みには多くのメリットがあります。 人間の稼働時間外にAIを働かせられる 例えば、夕方にIssueを起票し、夜間のうちに「コード調査」を実行しておきます。翌朝出社すると、Issueにはすでにコード調査の結果と実装方針、実装にあたっての確認事項が記載されており、人間はそれを読んで回答するだけです。これにより、日中の貴重な開発セッションのコンテキストスイッチを発生させることなく、並列で作業を進めることができるようになりました。 Issue上に全ての内容が記載されるため、Issueを確認するだけでどのような方針にしたかをいつでも振り返ることができる Issue上に当時の調査結果や修正案、修正方針がすべて残るため、後から見返したときに『どの調査結果を根拠にこの修正方針を選んだのか』を追うことができます。 ローカルPCを汚染しない 実装は全てクラウド環境（サンドボックス）で実施されているため、ローカルに余計なブランチが作成されることがなく、また、Claudeの修正がローカル環境に影響を与えるものであっても、修正内容を確認し、危険だと判断したら取り込まない選択ができるためローカルPCが汚染されません。 個人の環境に依存しないため、誰が操作しても再現性のある挙動を実現できる ローカルでIssueの調査と解消をしていたときは、実行環境が各自のPCに依存するため、ツールの起動条件や調査結果の出力内容が環境ごとに変わることがありましたが、クラウド環境（サンドボックス）で動作させることで、誰がやっても同じ環境・同じ設定で実行されるため、挙動が安定しました。 Human in the Loopを挟むことで段階的に進めることができる 最初のRoutineでコードの調査結果を基に実装方針を検討し、開発者に確認するというフローを挟むことでClaudeが勝手に設計・実装を行って、意図した内容と大きく異なる実装になってしまうということがないようになりました。 誤った実装で余計なトークンを使用しなくなったことにより、コスト的にも安価に済ませることができます。 導入で見えた「AIネイティブな開発」の壁 ここまで聞くと夢のような仕組みに思えるかもしれませんが、実際に運用してみると、想像以上に大変な課題に直面しました。 レビューの難しさ：コードの妥当性を測るための「深いドメイン理解」 最も大きな壁は、 「人間によるコードレビューの負荷」 でした。 Claude Codeが生成するコードは、文法的には正しく、テストも通るものが大半です。しかし、楽楽勤怠が持つ複雑なビジネスロジックや、特有のドメイン知識に本当に即しているかどうかは、パッと見ただけでは判断できません。 AIが「なぜこの実装アプローチをとったのか」という意図を正確に理解するためには、レビュワーである人間側が、結局のところ既存のコードベースを深く読み込み、AIの思考プロセスをリバースエンジニアリングして紐解く過程が必要になります。 この「AIの実装が本当に正しいか、コードを読んで理解する」という作業が思いのほか重く、AIによってコーディングの時間は削減されたものの、レビューの時間が長引いてしまい、結果として恩恵が一部相殺されてしまうというジレンマを感じました。 AIとの協働をさらに進化させる：今後の展望 これらの課題を踏まえ、私たちはこの仕組みをさらにブラッシュアップしていく予定です。 レビューコスト軽減への挑戦：意図を明確にするドキュメント化 レビューコストが高い問題については、「既存コードの書き方に合わせること」と「参照先や実装意図を明示すること」を、プロンプトやRoutineのルールとしてAIに徹底させるアプローチを試しています。 「〇〇のディレクトリにあるXXパターンの実装を踏襲しました」「理由は△△だからです」というサマリーがPRに明確に記載されていれば、レビュワーの認知的負荷は劇的に下がると考えています。 Spec Driven Developmentへの拡大 もう一つの展望は、この仕組みを 「Spec Driven Development（仕様駆動開発）」 に応用することです。 「仕様書（Spec）」をIssue上で管理し、合意が取れたSpecを基にAIが実装を行う。このサイクルを回すことで、ドメイン知識のズレを実装前に吸収し、より本質的な「顧客価値の最大化」にフォーカスした開発ができるのではないかと期待しています。 おわりに AIにコードを書かせることは簡単になりつつありますが、それを実運用に載せ、真に「ユーザ体験の向上」に繋げるためには、人間とAIの協働プロセスを泥臭くデザインしていく必要があります。 課題はまだまだ山積みですが、ラクスのカルチャーである「小さく試して大きく育てる」の精神で、これからもAIネイティブな開発組織への変革に挑戦していきたいと思います。 この記事が、同じようにAIツールのチーム導入を模索している皆さんの参考になれば幸いです！