DevOps Agentが作成したAgent-ready specificationsを使ってKiro Webにバグを修正させてみた

AIにお任せでエラーの原因特定〜バグ修正まで簡単に実現できました！
2026.05.21
リテールアプリ共創部@大阪の岩田です。
DevOps AgentにはAgent-ready specificationsというドキュメント作成してくれる便利な機能があります。
これはコーディングエージェント向けにコードや設定の変更に関連する推奨事項を記載したドキュメントになっていて、このドキュメントをコーディングエージェントに渡せば、AIが自律的にPR作成等のタスクを進めてくれるようになっています。
公式ドキュメントには以下のように記載されています。
For recommendations that involve code or configuration changes, AWS DevOps Agent can generate an agent-ready specification. This specification provides a structured document that can be handed directly to a coding agent for implementation.
The specification includes:
Problem statement – A summary of the issue and its root cause
Solution summary – A high-level description of the recommended approach
Target repositories – The specific repositories where changes need to be made
Code changes – Detailed descriptions of what needs to change and why, with specific file paths and implementation considerations
Test requirements – What scenarios need to be tested
Implementation plan – A phased approach to implementing the changes
Agent-ready specifications accelerate implementation by providing coding agents with the context they need to make production-ready changes without requiring extensive back-and-forth with engineers.
このブログでは、私が社内向けに運用しているブログ自動レビューの仕組みを題材に、実際にAgent-ready specificationsの生成〜バグ修正まで実施した流れをご紹介します。
 対象システムとバグの概要題材にするのは以下ブログで紹介しているブログの自動レビューシステムです。
https://dev.classmethod.jp/articles/devio-autoreview-by-bedrock/
ブログ執筆時から色々と処理が追加されており、現在はStep Functionsを使って様々なチェック処理を実施しています。
こちらのステートマシンですが、最後のNotifySlackというLambdaの実装にバグがあり、レビューの指摘事項が長文になるとSlack APIの制約に引っかかりSlack通知に失敗するという問題がありました。このバグを題材にDevOps Agentに調査 & Kiro Webに修正をお願いしてみます。
 DevOps Agentで調査まずはDevOps Agentに不具合の調査をしてもらいます。なおソースコードを管理しているGitHubリポジトリは事前にエージェントスペースと接続済みの状態です。
以下のようにエラーで終了したStep Functionsの実行がありました。まずはこの実行ARNを控えます。
実行ARNと時間帯を添えてDevOps Agentに調査を依頼します。
調査が始まったらコーヒーでも飲みながら調査の完了を待ちましょう。
しばらく待つと調査が完了します。
DevOps Agentが特定した根本原因は以下の通りでした。
GitHub リポジトリ cm-iwata/devio-blog-aoto-review の notify-slack/app.py において、Slack Block Kitメッセージを構築する際にtext要素の文字数バリデーションやtruncation処理が一切実装されていない。Slack Block Kitの section ブロックの text 要素は最大3000文字の制限があるが、LLM生成テキスト（media_policy, typo）やTextLint結果（text_lint_result）がそのまま無制限にblock.text.textに設定され、187行目の slack_client.chat_postMessage() でバリデーションなしに送信されている。これは既知のSlack API制限に対する防御的プログラミングの欠如であり、長文のレビュー結果が生成された場合に必ずエラーとなるバグである。
なるほど。確かに長文メッセージの切り詰めなどは実装していませんでした。調査結果の妥当性が確認できたので、Generate Mitigation Planをクリックして緩和計画を作成してもらいます。
緩和計画内の次のステップとして以下のAgent-ready specificationsが作成されました。
## 変更要件

1. **システムは、Slack Block Kit メッセージの text 要素が3000文字の制限を超えないよう、送信前に文字数をバリデーションし、必要に応じて切り詰める処理を実装すること**
notify-slack/app.py において、Slack API の chat.postMessage に送信する Block Kit メッセージを構築する際、各 section ブロックの text 要素（text.text フィールド）が Slack API の3000文字制限を超えないことを保証する。具体的には、LLM生成テキスト（media_policy, typo）、TextLint結果（text_lint_result）、およびその他の動的コンテンツを Block Kit の text 要素に設定する前に、文字数をチェックし、3000文字を超える場合は2950文字程度に切り詰めて '...(以下省略)' などのサフィックスを追加する。これにより、長文のレビュー結果が生成された場合でも Slack API が invalid_blocks エラーを返さず、NotifySlack Lambda 関数が正常に完了し、Step Functions ワークフローが成功することを保証する。

**受け入れ基準**

- notify-slack/app.py に、Slack Block Kit の section ブロック text 要素の文字数を3000文字以内に制限する関数またはロジックが実装されている
- media_policy, typo, text_lint_result などの動的コンテンツを Block Kit メッセージに設定する際、上記の文字数制限ロジックが適用されている
- 3000文字を超えるコンテンツは、2950文字程度に切り詰められ、切り詰めが発生したことを示すサフィックス（例: '...(文字数制限により省略)'）が追加されている
- 単体テストまたは統合テストで、3001文字以上のレビュー結果が生成された場合でも Slack API が成功レスポンス（ok: true）を返すことを確認している
- 変更後のコードで Step Functions ワークフローを実行し、長文レビュー結果のケースで NotifySlack ステップが正常完了し、ワークフロー全体が SUCCESS ステータスで終了することを確認している
 Kiro Webでソースコードを修正するここからはKiro Webにバグを修正してもらいます。
まずソースコードを管理しているリポジトリでissueを作成し、先ほど生成された仕様をそのまま貼り付けます。
このissueにkiroラベルを付与すると、kiro-agentが修正を実装してくれます。
しばらく待つと修正が完了し、PRが作成されます。
差分の詳細を確認すると、以下の通りtruncate_textという関数が追加されており、各ブロックのメッセージを生成する処理からこの関数の呼び出しが追加されていました。
SLACK_BLOCK_TEXT_MAX_LENGTH = 3000
TRUNCATION_SUFFIX = "...(文字数制限により省略)"

def truncate_text(text: str, max_length: int = SLACK_BLOCK_TEXT_MAX_LENGTH) -> str:
    """Truncate text to stay within Slack Block Kit's character limit.

    If text exceeds max_length, it is truncated to (max_length - len(suffix))
    characters and the suffix is appended so the total never exceeds max_length.
    """
    if len(text) <= max_length:
        return text
    truncated_length = max_length - len(TRUNCATION_SUFFIX)
    return text[:truncated_length] + TRUNCATION_SUFFIX
特に実装に問題はなさそうなので、このままPRをマージしてデプロイすれば修正完了です！
 まとめDevOps AgentとKiro Webにお任せすることでエラーの原因調査 ~ バグの修正まで完了しました。こういった機能をうまく活用してシステムの改善サイクルを高速化していきたいですね！
 参考Proactive incident prevention - AWS DevOps Agent