目次 はじめに サマリ 人間はタスクを完全には並列処理できない 以前にも承認待ちの課題は存在していた 作った仕組みと設計上の工夫 issueの選定条件を明確にする 1回の実行で1 issueだけ扱う 複数のリポジトリを横断してコンテキストを集める まとめ 参考文献 はじめに AIにコードを書いてもらえるようになると、実装は一気に速くなりますが、実装そのものが速くなったからといって、開発全体が速くなるとは限りません。 AIに実装を依頼するには、対応するタスクを選び、必要な資料や前提を集め、実行結果を確認し、次の作業を起動する必要があります。これらの工程に人間の手作業や待ち時間が残っていると、実装速度が上がるほど、今度は実装以外の部分がボトルネックになります。 私自身、SkillsやRules、リポジトリ固有のコンテキストを整えることで、AIによる実装が少しずつ速くなっていることを感じていました。一方で、AIに任せたいタスクがあっても、人間がセッションを立ち上げて指示を出さなければ、作業は始まりません。実装以外の部分には、依然として人間による起動や確認が残っていました。 また、同期的に会話をしながら複数のタスクを切り替えることにも限界を感じていました。AIに任せられる範囲を広げるだけでなく、人間が見るべきものを絞る必要があると考えました。 そこで、Claude Codeのルーティンを使い、実装タスクを定期的に進める仕組みを設計しました。目的は、人間を完全に開発から外すことではなく、人間が判断すべき仕事に集中できるよう、繰り返し作業や待ち時間を減らすことにあります。 この記事では、対象となるissueをどのように選び、必要なコンテキストをどう集め、実装からドラフトPRの作成、レビュー、報告までをどのように自動化したのかを紹介します。 サマリ 今回の課題に対して、 Claude Codeのルーティン を使った仕組みを作りました。 このルーティンは1時間ごとに実行され、対応するissueの選定から、必要なコンテキストの収集、実装、セルフレビュー、ドラフトPRの作成、AIレビュー、実行結果の報告までを行います。1回の実行で扱うissueを1件に絞り、対応方針が明確なものだけを対象にすることで、無人で動かす範囲を限定しました。 *1 一方で、仕様やマージの判断などは人間に残しています。今回の自動化の目的は、人間を開発から外すことではなく、人間の判断が不要な箇所への介入を減らすことです。 人間はタスクを完全には並列処理できない ここでは、AIの実装速度が上がると、なぜ人間がボトルネックになりやすいのかを考えてみます。 人間は複数のタスクを同時に抱えることができます。しかし、それらを同じ瞬間に判断し、行動まで進めることは簡単ではありません。人間が一度に意識して扱える作業情報には限りがあります。一つのタスクを覚えるだけでも、目的、優先度、変更箇所、制約、現在の進捗など、複数の情報を保持する必要があります。複数のタスクを同時に抱えると、すぐに扱う情報が増えていきます。仮に複数のタスクを並列に進められたとしても、すべてのタスクの状況を同じ精度で保持し続けることは難しくなります。 そのため、タスクAに取り組んでいる間、タスクBやタスクCは待ちの状態になります。タスクAを一区切りつけてからタスクBへ移り、さらにタスクCへ移るというように、人間の注意や判断を切り替えながら作業を進めることになります。この状態を、時間の流れに沿って図にすると次のようになります。 タスク切り替えの図 タスクを切り替えるときは、単に別の画面を見るだけではなく、注意を向ける対象も切り替える必要があります。そのため、複数のタスクを並列に進めているように見えても、実際には人間がタスクを切り替えながら、一つずつ処理していることが多くあります。 以前にも承認待ちの課題は存在していた 承認待ちは今回初めて現れた問題ではありません。Auto Modeの登場以前、セッション中には人間の承認を待つ場面がありました。ファイル編集やコマンド実行など、Claude Codeが次のアクションへ進む前に許可を求めることがありました。人間が画面を確認して許可を出せば処理は進みますが、その間はAIも待ち状態になります。 承認待ちをなくすだけであれば、 --dangerously-skip-permissions を使う方法がありますが、このオプションは権限確認を省略し、Claude Codeにすべてのアクションを実行させるためのものです。この方法では安全性の問題が残るため、解決策にはなりません。公式ドキュメントでも、 --dangerously-skip-permissions はすべてのアクションを確認なしで実行するモードであり、隔離されたコンテナや仮想マシンで使うことが推奨されています。 現在のClaude Codeでは、Auto Modeがデフォルトになりました。Auto Modeでは、通常のようにすべてのアクションを人間に確認するのではなく、別のモデルで構成された分類器がツール呼び出しを確認します。危険な操作や環境外への操作などを検出した場合は、処理を止めたり、より安全な方法を選んだり、人間に確認を求めたりします。つまり、Auto Modeは確認をすべて無視するのではなく、AIによるチェックを挟みながら長く実行できるようにする仕組みです。 AIによる判断が安全なものか気になるかもしれませんが、 Anthropicが公開した検証 では、危険なコマンドを人間の手動確認とAuto Modeがどの程度検出できるかを比較し、人間の手動確認が危険なコマンドを検出できた割合は13.6%、Auto Modeは89%だったと報告されています。つまり、Auto Modeは人間の手動確認よりも高い割合で危険なコマンドを検出したとされています。 今回解決したい課題は、Auto Modeが扱っている問題と似ていると考えました。タスクの目的や実行してよい範囲が明確であれば、人間がすべての操作に介入しなくても、AIに作業を任せやすくなります。 そこで、同じ考え方を、セッションの外側にも広げられないかと考えました。どのissueを選び、必要なコンテキストを集め、セッションを起動するかという作業も、条件を定めたうえでAIに任せられるのではないか、という発想です。 作った仕組みと設計上の工夫 今回作った仕組みは、GitHubのissueを起点に、実装からドラフトPRの作成、レビュー、結果の報告までを定期的に進めるルーティンです。 全体の流れは次の図のようになります。 ルーティン全体像の図 issueの選定条件を明確にする 定期実行されるルーティンでは、issueの曖昧さをAIが勝手に補う可能性があります。 そこで、AssigneeやLabelなどの管理情報を、自動実行してよいissueを選ぶための手がかりとして使っています。issue本文の自然言語だけで判断させるのではなく、機械的に確認できる条件を先に置くことで、対象範囲を狭くしています。 1回の実行で1 issueだけ扱う 候補issueが複数あったとしても、1回の実行で着手するのは1件だけにしました。 複数のissueを同時に処理すれば、単純に処理量を増やせます。しかし、無人実行では、どこか一つの判断を誤ったときに複数の変更へ影響が広がります。また、失敗したissueと成功したissueが混ざると、後から原因を確認することも難しくなります。 1回1 issueに制限すると、処理量は減ります。その代わり、どのissueを処理したのか、どこで止まったのか、どの成果物が生成されたのかを追いやすくなります。 また、1回の実行で扱うissueの背景や関連資料などのコンテキストも抑えられるため、AIが参照すべき情報を絞りやすくなります。今回は処理量の最大化よりも、コンテキストを過度に広げず、失敗したときに戻しやすいことを優先しました。 複数のリポジトリを横断してコンテキストを集める issueの本文には、目的、対応範囲、完了条件が分かるように記載していますが、これだけでは実装に必要な情報が足りないことがあります。 現在担当している案件では、実装に必要な情報が複数のリポジトリに分散しています。参照できるリポジトリが限られるとコンテキストが足りず精度が落ちるため、各リポジトリの役割や参照先をまとめたリポジトリを用意し、コンテキスト収集の最初に参照させるようにしました。 まとめ 実際に運用してみると、人間がセッションを起動したり、作業の進捗を確認したりしなくても、手が離れている時間に実装タスクを進められるようになりました。実装を待つ時間や、次の作業を起動する手間が減り、人間は仕様の確認や成果物のレビューなど、判断が必要な作業に集中しやすくなりました。 これにより、仕様がお客様の業務に合っているか、画面が使いやすいかといった、お客様への価値に直結する確認に時間を充てやすくなりました。 今回の取り組みでは、実装にかかる時間が短くなったからこそ、次はその周辺に残っている作業や待ち時間を減らし、開発フロー全体を整えたいと考えました。AIにコードを書かせるだけでなく、AIが継続的に作業できるフローを設計することが重要になると考えています。 参考文献 Claude Code Docs「権限モードを選択する」 Claude by Anthropic「Auto mode is now the default in Claude Code」 Claude Code Docs「ルーティン」 *1 : ここでのセルフレビューは、実装を行ったClaude Codeのセッションが、自身の変更内容を見直す工程です。AIレビューは、ドラフトPRの作成後に別のAIがPRを確認する工程を指します。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 10 月に入り、朝晩はすっかり涼しくなってきました。1 週間で Kiro の使い方を学ぶオンラインチャレンジ Kiro University Challenge は、最終課題の締切が日本時間 10 月 6 日 15:59 に迫っています。最大 5,250 の Kiro クレジットを獲得できるチャンスなので、まだ提出していない方は最後のひと頑張りをどうぞ。 お昼休みの 30 分で最新情報を知れる「 もぐもぐAWS 」では、AI をテーマにした会が 10 月に予定されていますので是非ご参加ください。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、9 月 28 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「REST API を Amazon Bedrock AgentCore Gateway で MCP サーバー化する ― オリックス「PATPOST」での取り組み」を公開 オリックス株式会社様は、生成 AI を活用したビジネス文書管理サービス「PATPOST」を約 2,300 社に提供しています。利用者ごとにデータを出し分ける既存 API を、どう AI エージェントに開放するかが課題でした。そこで、 Amazon Bedrock AgentCore Gateway で REST API を改修せずに MCP サーバー化し、 Interceptor 機能で利用者ごとの API キーを引き渡す構成を PoC で検証しました。その結果、データの境界を保ったまま MCP 化でき、Lambda Target でツールを集約すると消費トークンも大幅に減ることを確認しています。 ブログ記事「【開催報告】組み込みソフトウェア開発でも AI エージェントは活用できる ─ 日立産業制御ソリューションズ様とのワークショップ」を公開 株式会社日立産業制御ソリューションズ様の組み込みソフトウェアエンジニア 102 名に、 Kiro を開発ライフサイクル全体に適用するハンズオンワークショップ を実施した開催報告です。HVAC 制御システムを題材に、既存コードの読み解きから仕様化、実装、テストまでを体験し、GitLab の Issue に指示を書いて経過を残す進め方も紹介しています。AI エージェントが実装を速くするだけの道具ではないことが伝わる内容です。 ブログ記事「OCC が AWS 上に構築したエージェンティック AI 調査ソリューションでセキュリティオペレーションを強化」を公開 世界最大の株式デリバティブ清算機関である The Options Clearing Corporation (OCC) が、Amazon Bedrock で構築したセキュリティ調査エージェント「SOC エージェント」の導入を発表しました。この記事では、SIEM のデータに対して調査方針の立案から証拠の取得、評価までをエージェンティックループで進め、説明可能かつ監査可能な結果を返す仕組みを紹介しています。規制業界の方に参考になる設計です。 ブログ記事「Kiro workflows のご紹介」を公開 少ない監督で、人が見守る手間を減らしながら複雑なタスクを最後までやり遂げる Kiro workflows が発表されました。この記事では、エージェントステップやループ、並列ブランチで構成されるグラフをモデルが定義し、Kiro ランタイムが各ステップを独立したセッションで確実に実行する仕組みとレシピの書き方を紹介しています。Kiro チーム自身が数千回の workflow を回して Kiro を開発しているという話も興味深いです。 ブログ記事「Claude Opus 5.5 が Kiro で利用可能になりました」を公開 Anthropic 社の Claude Opus 5.5 が、2026 年 9 月 28 日より Kiro IDE、CLI、Crew、Web のすべてで利用可能になりました。この記事では、変更前に根本原因を突き止め、作業しながら自身の仕事を検証する Opus 5.5 の特徴と提供状況を紹介しています。Amazon 社内のベンチマークでは Opus 5 よりツール呼び出しを約 40% 減らし、トークン消費を半分に抑えたとのことです。 ブログ記事「Kiro で SAP モダナイゼーションを加速」を公開 SAP ABAP、SAP BW、SAP PI/PO のモダナイゼーションを単一のプロンプトで一括実行できる、Kiro ベースのサンプルエージェントが公開されました。この記事では、SAP S/4HANA 準拠への変換やクリーンコア化、仕様書生成、単体テスト自動化といったユースケースと、80 以上のルールを備えたステアリングファイルなどのセーフガードを紹介しています。2027 年 12 月の標準サポート終了を控えた SAP ユーザーは要チェックです。 ブログ記事「Kiro で SAP モダナイゼーションを加速 – ベンチマークとユースケース」を公開 上記のサンプルエージェントについて、社内ベンチマークとパートナー・お客様の成果を詳しく紹介する続編です。88 オブジェクトの ABAP コードを 4.5 時間で SAP S/4HANA 準拠に変換して工数を 87% 削減したほか、22 の SAP PI/PO インターフェースを約 2 時間で SAP BTP Integration Suite に変換した結果などが、使用した Kiro クレジット数とともに公開されています。移行計画の見積もりにも役立ちます。 ブログ記事「AWS と SAP、SAP Business AI Platform の提供拡大に向け協業を強化」を公開 AWS は SAP Sapphire 2026 で、SAP との 5 年間の戦略的協業契約を発表しました。この記事では、SAP Business AI Platform のプラットフォームサービスと SAP Business Data Cloud を、日本を含む 7 つの新しい AWS リージョンに 2026 年 12 月から段階的に展開する計画などを紹介しています。データレジデンシー要件のある国内の SAP ユーザーには嬉しいニュースです。 ブログ記事「Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1」を公開 Amazon Bedrock Guardrails の自動推論チェックは、形式的検証の技術を使って AI の出力がビジネスルールに準拠しているかを数学的に検証する機能です。この記事では、自然言語のドキュメントから自動推論ポリシーを作成・改善する方法や、テストケースの設計、注釈によるポリシー改善など、技術的な基礎と実装方法を解説しています。規制産業でハルシネーション対策を検討している方におすすめです。 ブログ記事「自動推論チェックで回答を書き換えてハルシネーションを抑えるチャットボットのリファレンス実装」を公開 自動推論チェックのフィードバックを使って LLM の回答を反復的に書き換え、必要に応じてユーザーに確認の質問を行うオープンソースのチャットボットが公開されています。この記事では、検証結果の種類ごとに書き換えや質問を判断するループの仕組みと、監査ログを含むバックエンドの構成を詳しく解説しています。規制のある環境で生成 AI を使いたい方は、上のパート 1 とあわせて読むと理解が深まります。 ブログ記事「Amazon S3 Vectors がメタデータの pre-filtering に対応し、フィルター付き検索の再現率が向上」を公開 Amazon S3 Vectors で、類似性検索の前にメタデータフィルターを評価する pre-filtering が利用可能になりました。この記事では、絞り込みの強いフィルターで取得できる一致ベクトルが最大 5 倍に増える仕組みや、前方一致の演算子 $startsWith、CLI を使った始め方を紹介しています。マルチテナントの RAG やエージェントの検索精度に悩んでいる方は要チェックです。 ブログ記事「HR Open Standardsを活用したHRデータ統合のためのオントロジー設計」を公開 「子会社を全部挙げる」「空席のポジションを探す」といった質問は、ベクトル類似検索ベースの RAG が苦手とするものです。この記事では、 HR Open Standards をもとに共通オントロジーを設計し、Amazon Neptune Serverless と SPARQL テンプレートで検索した結果を Amazon Bedrock で回答文に整形する構成を解説しています。構造化データに強い質問応答を作りたい方の参考になります。 ブログ記事「AWS DevOps Agent Skills を作成するためのベストプラクティス」を公開 AWS DevOps Agent の Skills は、チームの調査ノウハウを再利用可能なプレイブックとして蓄積し、誰がオンコールでも一貫した調査を行えるようにする仕組みです。この記事では、エージェント指示との使い分けや起動を左右する description の書き方、複数 Skills の組み合わせ方、見落としやすい失敗パターンまでを紹介しています。Skills を書いたのに使われない、と悩んでいる方に読んでほしい内容です。 ブログ記事「今月の AWS オブザーバビリティ: 2026 年 8 月と 9 月」を公開 8 月と 9 月のオブザーバビリティ関連のアップデートをまとめた記事です。AI ファーストのオブザーバビリティを提供する Amazon CloudWatch Omni の一般提供開始をはじめ、AWS CloudTrail と Amazon Q Console の統合による自然言語でのアクティビティ調査、アラームのウォームアップ期間などが紹介されています。AWS DevOps Agent 関連の記事もまとまっているので、運用に AI を取り入れたい方はぜひ。 ブログ記事「【開催報告】AI ペルソナワークショップ — 自社だけの AI ペルソナを作って、試してみよう」を公開 2026 年 9 月 15 日に、マーケティングや事業企画に携わる 7 社 19 名の皆様と、自社データから AI ペルソナを作って試すワークショップを開催しました。この記事では、GitHub で公開しているサンプル実装 sample-ai-persona を使い、ペルソナへのインタビューやペルソナ同士の議論、評価からネクストアクションまでを半日で体験した様子をレポートしています。顧客調査を素早く回したい方はサンプルを試してみてください。 ブログ記事「【開催報告】AWS Future of Money ～AI × ブロックチェーンが創る新金融エコシステム～」を公開 2026 年 8 月 19 日に、金融業界のお客様約 45 名を対象としたイベント「AWS Future of Money」を開催しました。この記事では、野村ホールディングス様や JPYC 様のご講演に加え、AI エージェントが購買まで完結する「エージェンティック・コマース」や AI エージェント向け決済規格への対応など、AI とブロックチェーンが変える決済の未来についての議論をレポートしています。 ブログ記事「送配電事業におけるクラウド活用と AI 技術の最前線 ― T&D エグゼクティブ・ラウンドテーブル 開催報告」を公開 2026 年 8 月 7 日に、送配電事業者 32 社・組織から 61 名にご参加いただいた T&D エグゼクティブ・ラウンドテーブルの開催報告です。量子時代のセキュリティに加え、100 万台超のネットワーク機器の障害対応を AI エージェントで自律化した NTT ドコモ様の取り組みなど、通信業界の AI 活用事例が紹介されています。業界をまたいだ「自律運用」の考え方が参考になります。 ブログ記事「【開催報告】KubeCon + CloudNativeCon Japan 2026 – AWS ブース：Amazon EKS の最新ソリューションに関するデモセッションを実施」を公開 2026 年 7 月 29 日から 2 日間開催された KubeCon + CloudNativeCon Japan 2026 の AWS ブースで実施した、12 のデモセッションの資料が公開されました。Amazon EKS Auto Mode での LLM 駆動エージェントの運用やモデルロードの高速化、AWS DevOps Agent によるインシデント対応、EKS 向け Agent Skills など、AI 関連のテーマも多く含まれています。 サービスアップデート Claude Sonnet 5.5 が AWS で利用可能に Anthropic 社の Claude Sonnet 5.5 が、Amazon Bedrock と Claude Platform on AWS で利用可能になりました。Sonnet 5 からコーディングとナレッジワークの性能が大きく向上し、多くの作業でタスクあたりのコストを抑えつつ高速に応答します。1 枚資料や図、スライドの作成、スプレッドシートの整理など、そのまま共有できるアウトプットも得意です。同日に AWS GovCloud (US) でも提供が始まっています。詳細は こちらのドキュメント をご参照ください。 OpenAI GPT-6.1 Sol が Amazon Bedrock で一般提供開始 OpenAI 社の GPT-6.1 Sol が Amazon Bedrock で一般提供開始されました。GPT-6 Sol のアップグレード版で、エージェント型コーディングやコンピュータ操作、プロフェッショナルな業務で高い性能を発揮します。OpenAI 社によると、GPT-6 Astra に迫る性能をおよそ 5 分の 1 のコストで実現しており、明示的なプロンプトキャッシュにも対応しているため、コンテキストを繰り返し使うエージェントを低コストで動かせます。 Amazon Bedrock Managed Agents, powered by OpenAI がプレビュー開始 AWS と OpenAI 社が共同開発した Amazon Bedrock Managed Agents (BMA) がプレビューで利用可能になりました。OpenAI の Agents API をベースに AWS ネイティブに作られており、状態の保持やツールの選択・実行、コード実行、複数ステップの調整をマネージドで任せられます。各エージェントは独自の IAM ロールで動作し、重要なアクションの前の人による承認や AWS CloudTrail への記録にも対応しています。詳細は こちらのドキュメント をご参照ください。 OpenAI GPT-6 Astra が Amazon Bedrock で UltraFast モードをサポート Amazon Bedrock の GPT-6 Astra で、速度を重視するワークロード向けのプレミアムな速度ティア UltraFast モードが利用可能になりました。OpenAI 社によると、API での推論が最大 6 倍高速になり、最大で毎秒 300 トークンを出力します。リアルタイムのコーディングアシスタントや対話型エージェント、顧客向けのチャット体験など、応答の速さと品質の両方が求められる用途に向いています。 Grok 4.7 が Amazon Bedrock で利用可能に SpaceXAI の Grok 4.7 が Amazon Bedrock で利用可能になりました。コーディングやエージェントタスク、ナレッジワーク向けのフロンティアモデルで、Grok 4.6 から複数形式が混在するドキュメントの扱いや、計画とエラー回復を伴うリポジトリ規模のコーディングが改善されています。フォーム入力やポータル操作をこなすブラウザ操作エージェントも強化されており、US Geo とグローバルのクロスリージョン推論で利用できます。 Amazon Bedrock の Claude モデルがインド、韓国、シンガポールで利用可能に Amazon Bedrock で、インドでは Claude Opus 5、Claude Sonnet 5、Claude Haiku 4.5、韓国では Claude Opus 5 と Claude Sonnet 5、シンガポールでは Claude Sonnet 5 が利用可能になりました。インドではムンバイとハイデラバードにまたがる地理的クロスリージョン推論、韓国とシンガポールではリージョン内推論で提供されます。 Amazon Bedrock が英国 (ロンドン) リージョンで Claude モデルのリージョン内推論をサポート Amazon Bedrock のロンドンリージョンで、Claude Opus 5.5 と Claude Sonnet 5 のリージョン内推論が利用可能になりました。推論リクエストとデータは呼び出したリージョン内で処理され、リージョン外に出ることはありません。英国内でのデータ処理が求められる金融サービスや医療、公共部門のお客様が、最新の Claude モデルを大規模に活用しやすくなります。 Amazon Bedrock AgentCore Gateway が VPC エンドポイント向けにプライベート TLS 証明書をサポート Amazon Bedrock AgentCore Gateway で、プライベート認証局が署名した TLS 証明書を使うターゲットに接続できるようになりました。MCP サーバー、OpenAPI、HTTP プロキシの各ターゲットで利用でき、Amazon VPC Lattice を使った VPC 内のプライベートエンドポイントに、中間の Application Load Balancer なしで直接接続できます。社内の私設 CA で運用しているシステムをエージェントにつなぎたい場合に便利です。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker Unified Studio が Iceberg REST Catalog 接続と Amazon DocumentDB の IAM 認証をサポート Amazon SageMaker Unified Studio で、Snowflake Open Catalog や Databricks Unity Catalog など Iceberg REST 仕様に準拠した外部カタログへの接続と、Amazon DocumentDB への IAM 認証による接続がサポートされました。外部カタログのテーブルを Visual ETL やノートブックから読み書きでき、DocumentDB にはパスワードを保存せずに接続できます。ML や生成 AI の開発で使うデータへのアクセスがシンプルになります。 AWS MCP Server が東京を含む 6 つのリージョンで新たに利用可能に AI コーディングエージェントに AWS API への単一のインターフェースを提供するマネージド MCP サーバー、AWS MCP Server が東京、シンガポール、シドニー、アイルランド、ロンドン、オレゴンの 6 リージョンで新たに利用可能になりました。開発者に近いリージョンで低レイテンシに使えるほか、リクエストデータをリージョン内にとどめられるため、データレジデンシーの要件にも対応しやすくなります。国内のお客様には待望の東京リージョン対応です。詳細は こちらのドキュメント をご参照ください。 AWS CLI が Agent Toolkit for AWS のスキルの一括更新とバージョン確認をサポート AWS CLI の Agent Toolkit for AWS 向けコマンドに、インストール済みのスキルを最新版と比較する check-skill-updates と、古くなったスキルをまとめて更新する update-skill --all が追加されました。これまでスキルを 1 つずつ確認・更新する必要がありましたが、Kiro や Claude Code などのコーディングエージェントが常に最新のガイダンスで動くよう、1 コマンドで揃えられます。AWS CLI 2.37.0 以降で利用できます。 AWS Well-Architected Agent がプレビュー開始 AWS Trusted Advisor と AWS Well-Architected Tool の次世代版となる AI 搭載サービス、AWS Well-Architected Agent がプレビューで利用可能になりました。コスト、セキュリティ、パフォーマンス、信頼性の観点で AWS インフラを分析し、ビジネス目標に応じて優先度付けした推奨事項を SSM ランブックや CLI スクリプトとともに提示します。IaC テンプレートもレビューし、修正案まで返してくれます。詳細は こちらのドキュメント をご参照ください。 Amazon S3 Vectors がメタデータの pre-filtering に対応し、フィルター付き検索の再現率が最大 5 倍に Amazon S3 Vectors で、類似性検索の前にメタデータフィルターを評価する pre-filtering がサポートされ、絞り込みの強いフィルターで一致するベクトルを最大 5 倍多く返せるようになりました。パスや URL の前方一致に使える $startsWith 演算子も追加されています。新しいベクトルバケットのインデックスではデフォルトで有効になり、既存のインデックスも API で切り替えられます。追加料金はかからず、RAG やエージェントの検索結果がより網羅的になります。 Amazon Quick のアプリでデータセットのライブデータを利用可能に Amazon Quick で、Quick のデータセットのライブデータを直接使うアプリケーションを構築できるようになりました。アプリビルダーのチャットエージェントにデータセット名と作りたいものを自然言語で伝えるだけで、常に最新の KPI やグラフを表示し、申請や承認といった業務アクションまでこなせるアプリを作れます。アプリの利用者には各自の権限が適用され、設定済みの行・列レベルのセキュリティもそのまま有効です。 Amazon Aurora Serverless がエージェント型 AI などのバースト性の高いワークロード向けにより高速にスケール Amazon Aurora Serverless が、1 秒以内に最大 16 ACU を追加し、ワークロードの増加に合わせて最大 256 ACU までスケールできるようになりました。処理が終われば自動的にゼロまでスケールダウンするため、アクティビティの急増と長いアイドル時間を繰り返すエージェント型 AI アプリケーションのデータベースに特に向いています。プラットフォームバージョン 3 または 4 のクラスターではデフォルトで有効で、設定変更は不要です。 AWS Marketplace が従量課金メータリング統合向けの AI エージェントスキルを提供開始 AWS Marketplace の出品者向けに、従量課金型 SaaS のメータリング統合を AI コーディングアシスタントの中で構築・デプロイ・検証できるエージェントスキルが一般提供されました。料金モデルのヒアリングから適切な API の推奨、統合コードと CloudFormation スタックの生成、本番前のエンドツーエンドテストまでをガイドしてくれます。後から請求漏れとして発覚しがちなミスを事前に防げ、AWS MCP Server 経由で Kiro などから利用できます。 AWS Continuum for Penetration Testing が 6 つのリージョンで新たに利用可能に Web アプリケーションや API に対するペネトレーションテストを実施できるマネージドサービス、AWS Continuum for Penetration Testing (AWS Security Agent) が、ソウル、カナダ (モントリオール)、ロンドン、米国東部 (オハイオ)、パリ、ストックホルムの 6 リージョンで新たに利用可能になりました。本番環境に近いリージョンでテストを実行でき、データレジデンシーの要件を満たしながらセキュリティテストを継続できます。 Kiro CLI 2.25 がチャットからの Powers 管理と V3 の出力スタイル選択に対応 Kiro CLI 2.25 がリリースされました。V3 セッションで /powers install や /powers uninstall を使い、チャットの中から Powers を追加・削除できるようになり、追加した Powers はそのまま現在のセッションで使えます。また、/settings から V3 の応答の出力スタイルを選べるようになったほか、セッション終了時に実行される SessionEnd フックが追加され、後片付けの自動化もしやすくなりました。 Kiro IDE 1.2 がバックグラウンドで動く Workflows と信頼されていないワークスペースの保護強化に対応 Kiro IDE 1.2 がリリースされました。複数ステップの計画をバックグラウンドで実行する Workflows が追加され、チャット上部の Workflows エリアから進捗の確認や一時停止、再開ができます。また、エージェントがエージェント設定やフック、Powers、Workflow レシピを変更する前に必ず確認するようになり、信頼されていないワークスペースではコマンドの実行ごとに確認を求めるなど、安全性も強化されています。 Kiro CLI 2.26 / 2.27 で Workflows とステアリングのライブコンテキスト参照に対応 2.26 では V3 セッションで Workflows を有効化し、/workflow run でレシピを実行できるようになったほか、信頼されていないワークスペースでの MCP ツールやシェルの承認チェックが強化されました。2.27 では、ステアリングから行範囲の指定や #[[folder:…]] でファイルやフォルダの内容を読み込めるようになり、保存したプロンプトをスラッシュコマンドとして呼び出せます。Classic モードには非推奨の通知が出るようになったので、利用中の方は移行をご検討ください。 Kiro Web のクラウドセッションで Workflows が利用可能に Kiro Web のクラウドセッションで、複数ステップのエージェント計画をバックグラウンドで実行する Workflows がオプトインで利用可能になりました。会話で目的を伝えると Kiro が Workflow を提案して起動し、サイドパネルから各ステップの状態確認や方向修正、途中の質問への回答ができます。investigate、feature-pipeline、publish-pr の 3 つのレシピが同梱されており、自作のレシピもアップロードできます。 Claude Sonnet 5.5 が Kiro で利用可能に Anthropic 社の Claude Sonnet 5.5 が、Kiro IDE、CLI、Crew、Web で実験的サポートとして利用可能になりました。Sonnet 5 より出力が 30% 以上高速になり、実際のナレッジワークでは Opus 5.5 に迫る性能を発揮します。100 万トークンのコンテキストウィンドウに対応し、クレジット乗数は 1.3 倍です。Pro 以上のプランで、us-east-1 と eu-central-1 から利用できます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

こんにちは。タイミーのデータエンジニアリング部DSグループでMLOpsを担当しているYukitomoです。 前回の記事では、Python + uvのモノレポ環境において、Renovateを用いて依存関係更新のプルリクエストを制御するための基本設計を紹介しました。 その後、実際に運用してみると、Renovateの管理対象はPythonの依存パッケージだけでは収まりませんでした。 devcontainer.json やCloud Runのマニフェストなどへ対象を広げるにつれて設定が複雑になり、Mend.io経由で動かして結果を待つだけでは、意図通りに動かない設定の原因を追いにくくなりました。 そこで今回は、前回からの更新として、以下の4点を紹介します。 Renovate設定をローカルやCI/CDで検証できるようにしたこと 検証手順をAIエージェント用スキルとして整備したこと devcontainer.json やCloud Runのマニフェストをアプリケーション単位のプルリクエストにまとめる設定 グルーピングされた更新で、対象となるすべてのファイルを bumpVersions で更新する設定 この記事の想定読者 Renovate設定を継続的に改善・デバッグしたい方 Mend.io経由でRenovateを運用しており、設定変更の検証に課題を感じている方 プライベートなGoogle Cloud Artifact Registryを使うモノレポでRenovateを運用している方 AIエージェントにRenovate設定の調査・修正・dry runを任せたい方 要約（TL;DR） Mend.ioへ反映する前に、ローカルやCI/CDでRenovateのconfig validationとdry runを実行できるようにした 検証手順をAIエージェント用スキルにまとめ、調査手順と実行環境を揃えた managerごとに異なる packageFileDir を正規化し、アプリケーション単位で更新をまとめた グルーピングされたプルリクエストでは、 upgrades に含まれるディレクトリを列挙し、すべての pyproject.toml / uv.lock を bumpVersions で更新した 前提とするモノレポ構成 今回の内容を説明するため、次のような簡略化したモノレポを想定します。 . ├── .renovaterc.json5 ├── group-x │ ├── project-a │ │ ├── .devcontainer │ │ │ └── devcontainer.json │ │ ├── kustomize │ │ │ ├── base │ │ │ └── overlays │ │ ├── pyproject.toml │ │ └── uv.lock │ └── project-b │ ├── pyproject.toml │ └── uv.lock └── group-y └── ... 記事中で扱う設定の全体像は次の通りです。説明を簡潔にするため、実際の設定から関係する部分だけを抜き出しています。 { extends : [ "config:recommended" ] , devcontainer : { managerFilePatterns : [ "/(?:^|/)\\.devcontainer/(?:[^/]+/)?devcontainer\\.json$/" , "/(?:^|/)\\.devcontainer\\.json$/" , ] , } , packageRules : [ { matchFileNames : [ "group-x/**" ] , groupName : "group-x" , groupSlug : "group-x" , additionalBranchPrefix : "{{packageFileDir}}/" , } , { matchFileNames : [ "**/devcontainer.json" ] , additionalBranchPrefix : "{{replace \"/\\.devcontainer\" \"\" packageFileDir}}/" , } , { matchFileNames : [ "**/kustomize/**" ] , additionalBranchPrefix : "{{{replace '/kustomize/.*' '' packageFileDir}}}/" , } , { matchUpdateTypes : [ "major" , "minor" , "patch" ] , bumpVersions : [ { bumpType : "patch" , filePatterns : [ "/^({{#each (distinct (lookupArray upgrades \"packageFileDir\"))}}{{{.}}}{{#unless @last}}|{{/unless}}{{/each}})\\/pyproject\\.toml$/" , ] , matchStrings : [ "version\\s*=\\s*\"(?<version>[^\"]+)\"" ] , } , { bumpType : "patch" , filePatterns : [ "/^({{#each (distinct (lookupArray upgrades \"packageFileDir\"))}}{{{.}}}{{#unless @last}}|{{/unless}}{{/each}})\\/uv\\.lock$/" , ] , matchStrings : [ "name = \"[^\"]+\"\\nversion = \"(?<version>[^\"]+)\"\\nsource = \\{ (?:editable|virtual) = \"\\.\" \\}" , ] , } , ] , } , ] , } AIエージェント用スキルは独立したリポジトリで管理しているため、そのファイル構成は後述の2章で説明します。 1. Renovate設定はローカルやCI/CDで検証してからデプロイする 一般的なソフトウェア開発では、変更をメインブランチに入れる前にローカルやCI/CDで検証します。Renovateの設定も同じように扱えるよう、ローカルでconfig validationとdry runを実行するスクリプトを用意しました。このスクリプトは、2章で説明するAIエージェント用スキルに含めています。 実際のスクリプトはもう少し複雑ですが、Google Cloud Artifact RegistryやGitHubへの認証情報を環境変数へ設定した上で、固定バージョンのRenovateを実行するのがポイントです。 RENOVATE_HOST_RULES="$(gcloud auth print-access-token | jq -Rc '[ {matchHost:"asia-northeast1-docker.pkg.dev",hostType:"docker",username:"oauth2accesstoken",password:.}, {matchHost:"asia-northeast1-python.pkg.dev",username:"oauth2accesstoken",password:.} ]')" \ GITHUB_COM_TOKEN="$(gh auth token)" \ RENOVATE_CONFIG_FILE=.renovaterc.json5 \ npx --yes --package "renovate@${RENOVATE_VERSION}" renovate-config-validator --strict # または、同様に環境変数を設定してdry runを実行 # TIER = extract | lookup | full npx --yes --package "renovate@${RENOVATE_VERSION}" renovate --platform=local --dry-run="$TIER" Renovateの設定項目は多岐にわたります。Mend.io経由で実行していると、一見エラーなく終了していても、一部の設定が意図通りに適用されていないことがありました。 Mend.io側の環境変数を変えてメインブランチ以外で動作させ、詳細ログを確認する方法でもデバッグできます。ただし、Gitリポジトリの管理者権限が必要になる場合があり、誰でも簡単に試せるわけではありません。また、設定変更をプルリクエスト化し、承認後にメインブランチへ反映してから実行結果を確認する方法では、フィードバックループが長くなります。 そのため、現在はRenovate設定を「ローカルで検証してからデプロイする対象」として扱うようにしました。 2. AIエージェント用スキルとして準備する Renovateのdebug logは非常に大きく、リポジトリが大きくなるとdry runにも時間がかかります。人が毎回同じ前提を確認しながらログを読むのではなく、AIエージェントが一定の手順で設定を調査・修正できるよう、検証手順をスキルとして整備しました。 構成は以下です。 plugins/renovate-config-tester/ ├── assets │ ├── sample.gha.yml # サンプルのGitHub Actions │ └── sample.renovaterc.json5 # Renovateのサンプル初期設定 ├── scripts │ └── renovate-local.sh # 1章で説明したRenovate実行スクリプト └── SKILL.md SKILL.md には、主に次の前提と調査手順を記載しています。 Renovateのバージョン Renovateは必ず固定バージョンで実行します。Renovateの管理対象となるファイル（例：GitHub Actionsのworkflow）にバージョンを記述し、その更新はRenovate自身に任せます。スキルは、このファイルから実行するバージョンを取得します。 # CI用GitHub Actions jobs : validate-and-dry-run : runs-on : ubuntu-latest env : # renovate: datasource=npm depName=renovate RENOVATE_VERSION : 44.29.4 # Renovate自身が更新し、スキルはここから取得する steps : - name : Install Renovate run : npm install -g "renovate@${RENOVATE_VERSION}" - name : Renovate dry run run : renovate --platform=local --dry-run=lookup Node.jsの必要バージョン RenovateはNode.js applicationであるため、Renovateのバージョンに対応したNode.jsが必要です。 本記事で扱っているRenovate 44系は、Node.js 24の環境で検証しました。手元ではNode.js 26環境で正常に実行できなかったため、スキルにはRenovateが対応するNode.jsバージョンを確認し、検証済みのruntimeを使うよう明記しています。 gcloudやghの認証情報が必要であること Private Artifact RegistryやGitHubにアクセスする必要がある場合は、事前に gcloud や gh の認証を済ませる必要があります。 ただし、AIエージェントにtokenを直接扱わせるのではなく、スクリプト( renovate-local.sh )の中で RENOVATE_HOST_RULES やGitHub tokenを組み立てるようにしています。AIエージェントはスクリプトを実行するだけで、credentialの組み立て方を毎回判断する必要はありません。 必要なツール類 RenovateのログはJSONL形式で出力されるため、調査には jq などが必要です。リポジトリや設定によっては yq も利用します。こうした周辺ツールもスキルの前提に含めることで、AIエージェントが調査できない理由を切り分けやすくしています。 実行ログは一旦ファイルに記録してから読む 対象リポジトリが大きい場合、debug logをそのまま読み込ませるとLLMのtokenを多く消費します。そこで、ログを一旦ファイルへ保存し、対象パッケージやbranchに関係する行だけを grep / jq で抽出します。 "${CLAUDE_SKILL_DIR}/scripts/renovate-local.sh" > /tmp/renovate.log 2>&1 スキルとして独立させたことで、自分が担当するリポジトリ以外にも同じ調査手順を展開できます。Renovate設定の調査方法を人へ説明する代わりに、AIエージェントが同じ前提と手順で調査できる状態にしたことが、今回の大きな変更です。 3. devcontainer.jsonやCloud Runのマニフェストもアプリケーション単位のプルリクエストにまとめる Renovateは当初、Pythonの依存パッケージ更新を中心に導入しました。その後、 devcontainer.json やCloud Runのマニフェストから参照するコンテナイメージなどにも対象を広げています。 前提とするモノレポで単純に対象managerを増やすと、同じアプリケーションに関する更新であっても、ファイルの場所によって別のプルリクエストになります。 pyproject.toml / uv.lock の更新 .devcontainer/devcontainer.json のimage/feature更新 kustomize配下にあるCloud Runマニフェストのコンテナイメージ更新 これらは「同じアプリケーションの実行・開発環境に関する更新」としてまとめて確認したいケースが多く、プルリクエストが細かく分かれるとレビューの負担が増えます。そこで、managerごとに異なる packageFileDir を正規化し、アプリケーション単位のbranch prefixへ揃えます。 A. モノレポ内のdevcontainer.jsonを検出する 各アプリケーション配下の .devcontainer/devcontainer.json もRenovateの対象へ含めるため、devcontainer managerの managerFilePatterns を追加します。 devcontainer : { managerFilePatterns : [ "/(?:^|/)\\.devcontainer/(?:[^/]+/)?devcontainer\\.json$/" , "/(?:^|/)\\.devcontainer\\.json$/" , ] , } , B. packageFileDirをアプリケーションのディレクトリへ正規化する 前回の記事で紹介した共通ルールでは、 packageFileDir を additionalBranchPrefix に使っています。しかし、devcontainer managerの packageFileDir には /.devcontainer が含まれるため、そのままでは pyproject.toml / uv.lock の更新と別のbranchになります。 そこで、devcontainer managerから抽出したdependencyについては、 packageFileDir 末尾の /.devcontainer を取り除きます。 // 前回の記事で紹介した共通ルール { matchFileNames : [ "group-x/**" ] , groupName : "group-x" , groupSlug : "group-x" , additionalBranchPrefix : "{{packageFileDir}}/" , } , // devcontainer.json用のルール { matchFileNames : [ "**/devcontainer.json" ] , additionalBranchPrefix : "{{replace \"/\\.devcontainer\" \"\" packageFileDir}}/" , } , これにより、たとえば group-x/project-a/.devcontainer は group-x/project-a へ正規化されます。 Cloud Runのマニフェストが kustomize/base や kustomize/overlays/env に分かれている場合も、同じ考え方で /kustomize/** を取り除きます。 { matchFileNames : [ "**/kustomize/**" ] , additionalBranchPrefix : "{{{replace '/kustomize/.*' '' packageFileDir}}}/" , } , この設定により、Python dependency、devcontainerのimage/feature、Cloud Runマニフェストのコンテナイメージを、アプリケーション単位のプルリクエストとして確認しやすくなります。 ただし、複数アプリケーションの更新をさらに1つのプルリクエストへまとめると、別の問題が発生しました。 bumpVersions.filePatterns で {{packageFileDir}} だけを参照すると、グループ内に複数ある pyproject.toml と uv.lock のバージョンを更新しようとしても、一部しか更新されなかったのです。4章ではこの対処方法を紹介します。 4. グルーピング時のbumpVersionsで対象ファイルを漏れなく更新する 前回記事は bumpVersions をtop-levelに置く例を紹介しました。現在はpathを条件に加えているため、 packageRules の中に移しています。 通常であれば、 filePatterns は {{packageFileDir}}/pyproject.toml のように書きたくなります。しかし、複数のアプリケーションを1つのプルリクエストへグルーピングした場合、この記述ではいずれか1つの pyproject.toml / uv.lock しか更新されませんでした。 RenovateのDiscussion #35770を参考に、グループ内の upgrades からすべての packageFileDir を取り出し、正規表現の選択肢として組み立てるよう変更しました。 { matchUpdateTypes : [ "major" , "minor" , "patch" ] , bumpVersions : [ { bumpType : "patch" , filePatterns : [ "/^({{#each (distinct (lookupArray upgrades \"packageFileDir\"))}}{{{.}}}{{#unless @last}}|{{/unless}}{{/each}})\\/pyproject\\.toml$/" , ] , matchStrings : [ "version\\s*=\\s*\"(?<version>[^\"]+)\"" ] , } , { bumpType : "patch" , filePatterns : [ "/^({{#each (distinct (lookupArray upgrades \"packageFileDir\"))}}{{{.}}}{{#unless @last}}|{{/unless}}{{/each}})\\/uv\\.lock$/" , ] , matchStrings : [ "name = \"[^\"]+\"\\nversion = \"(?<version>[^\"]+)\"\\nsource = \\{ (?:editable|virtual) = \"\\.\" \\}" , ] , } , ] , } , lookupArray で各upgradeの packageFileDir を取り出し、 distinct で重複を除き、正規表現の選択肢として連結しているのがポイントです。 設定 グループ内の対象 更新結果 {{packageFileDir}} のみを参照 複数ディレクトリ いずれか1組だけ更新 upgrades からディレクトリを列挙 複数ディレクトリ 対象となる全組を更新 この記述はRenovateのtemplate contextに含まれる upgrades を利用します。導入時には、使用するRenovateバージョンでconfig validationとdry runを実行し、想定するすべてのファイルが更新対象になっていることを確認してください。 まとめ 今回、Renovateの設定をMend.ioへ反映する前に検証できるようにし、その手順をAIエージェント用スキルとして整備しました。configだけでなく、実行環境やcredentialの渡し方、ログの調べ方まで含めて管理することで、同じ前提と手順で継続的に設定を改善できます。 また、 packageFileDir の正規化によって更新をアプリケーション単位にまとめ、複数アプリケーションをグルーピングする場合は、 bumpVersions の対象もグループ全体へ広げました。モノレポのRenovate設定は、検証と運用を繰り返しながら育てることが重要だと感じています。 このようなMLOps基盤や開発環境の改善に、一緒に取り組むメンバーを募集しています。 We’re Hiring! 現在、タイミーでは、データサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています！ 現在募集中のポジションは こちら です。 また、気軽な雰囲気での カジュアル面談 も随時行っています。「話を聞きたい」と思われた方は、ぜひお気軽にエントリーしてください。 References 前回記事: Renovateの設定 - Timee Product Team Blog Renovate configuration options Renovate package rules Feedback thread: bumpVersions · renovatebot/renovate · Discussion #35770