はじめに

前回、Kiro の spec と steering と hook の話を書きました。あれは「作る前の段取り」、つまり手を動かす前にどう整えるか、という話でした。

今回はその続きで、もうひとつの武器 Powers の話です。いま作っている社内ツールの開発で、現在進行形でどう使っているかを書きます。

私が作っているのは、2025年に正式リリースされた Amazon Bedrock AgentCore をベースにした AI ツールです。比較的新しいサービスということは、裏を返すと 情報がまだ少ない。ブログ記事も少ないし、AI に聞いても学習データが追いついていない。けっこう手探りで進む領域でした。

そういうときに効果的だったのが Powers です。一言で言うと、Kiro の Powers は「AI が AWS の”今”の状態や公式ドキュメントを、自分で調べに行ける」拡張。情報が少ないサービスを実装するときほど、これが効きます。

ここで一つ、やってみて分かった逆説があります。AI に任せれば任せるほど、「調べてから書く」という地味な規律のほうが効いてくる、ということ。一見、先に調べるのは”遠回り”に見えます。でも実際にやってみると、その遠回りが一番の近道でした。私はこの「書く前に、まず裏を取らせる」習慣を 裏取りファースト と呼んでいます。AI に推測で書かせない。書く前に、まず裏を取らせる。

正直に言うと、この裏取りファーストを徹底してから「推測で実装して、あとで事故る」が目に見えて減りました。今日はその話を、つまずいた場面も含めて書いていきます。

ざっくり言うと

長くなりそうなので、先に結論を3つ。

  • Powers を入れると、AI が 公式ドキュメントや CloudWatch ログを自分で見に行ってくれる
  • でも本当に効くのは Power そのものより、「どんなときに裏取りするか」の判断基準を steering に書いたこと
  • それで AI が 「推測」と「確認済み事実」を分けて動くようになる。私はこの習慣を 裏取りファースト と呼んでいて、これでデプロイ後の事故がぐっと減りました

特に2つ目が肝です。順に書いていきます。

Powers って何？

Powers が何かというと、MCP ツール（AI が外部サービスに接続する口）と、そのツールの使い方を定義した steering（POWER.md）がセットになった、拡張パッケージです。ツールだけをポンと渡すのではなく、「どういうときに使うか」「どの順番で調べるか」という ワークフローごと AI に渡せる。ここが、ただの MCP 接続と違うところです。

私が主に使っているのは、この2つです。

  • aws-devops-agent（AWS DevOps Agent Power） — CloudWatch Logs や Lambda の状態を、リアルタイムに調べる
  • aws-agentcore（AWS AgentCore Power） — AgentCore まわりのドキュメント検索と状態確認

ほかにも用途に応じていくつか入れていますが、よく使うのはこの3つです。

たとえば AWS DevOps Agent Power を入れると、AI は CloudWatch Logs を直接読めるようになるのに加えて、「まずログを見て、根本原因を特定して、最後に修正案を出す」という 調査の段取りまでセットで入ってきます。「ツール」だけじゃなく「ツール＋使い方のルール」がワンセットになっているわけです。しかもどれも “調べる” ための拡張で、勝手にリソースを消したり作ったりするものではありません。

これを知ったとき、1本目で書いた steering（AI への申し送り書）と同じ思想だな、と思いました。前回の steering が「自分で書く申し送り書」だったのに対して、Power は「その道のプロが書いた申し送り書＋それに合った道具が、最初から一式そろっている状態」。自分で全部書かなくても、インストールするだけで AI の動き方がグレードアップするんです。

最初は「便利な検索ツールが増えたな」くらいに思っていました。でも、本当の価値はこの “使い方ごと渡せる” ところにありました。

ここが本題：「推測で実装しない」を AI のルールにした

開発していて一番こわいのは、「たぶんこういう仕様だろう」で書いて、デプロイしてから事故ることです。特に情報の少ない新サービスだと、この「たぶん」が頻発します。

そこで私は、steering（前回書いた “AI への申し送り書” です）に「Power を使うべき判断基準」を書きました。次のどれかに当てはまったら、実装に進む前に必ず Power で確認する、というルールです。

  • 環境変数・設定値（自動で入るのか、手で設定するのか）
  • API の振る舞い（リクエスト / レスポンスの形式、認証、エラー）
  • SDK の使い方（ライフサイクル管理、async 対応など）
  • IAM 権限（どのアクションが、どのリソースに必要か）
  • サービス間の連携（Runtime → Gateway → Lambda のような経路）
  • 課金や制約（タイムアウト上限、サイズ上限、レート制限）

そして、一番効いている一文がこれです。

「推測」と「確認済み事実」を明確に区別する。推測で実装した箇所は、デプロイ後に必ず問題になる。

これを steering に書いておくと、AI が自分で「ここは確認が要るな」と判断して、Power を選んで裏取りしてから実装を進めてくれます。

新しく入ったメンバーに「ここは自分で調べてから書いてね」と口で言う代わりに、ルールとして書いておく。そうすると AI が勝手にやってくれる。これは地味に気持ちのいい体験でした。

調べる順番も決めておいた

判断基準と一緒に、「調査の優先順序」も steering に書いています。

  1. まずログを見る（CloudWatch などで、実際に何が起きたか）
  2. 公式ドキュメントで裏を取る（サービスの制約を確認）
  3. Power で横断的に調べる（DevOps Agent や AgentCore）
  4. コードを読む
  5. 選択肢とトレードオフを出して、最後は人（私）に確認する

これも、前回の hook（権限委譲）と同じ考え方です。いきなり手を動かさせず、段取りで縛る。順番を決めておくと、AI の調査が脱線せず、最後は必ず私に判断が返ってきます。

…と、ここまでは「ルールを決めた」話。じゃあ、このルールが無かったらどうなるのか。次は、それを地で行ってしまった、わりと痛い失敗の話です。

急がば回れ — 修正提案にすぐ飛びついて、5連敗した話

正直に、いちばん遠回りした話から書きます。

AgentCore Gateway を CDK でデプロイしようとしたときのことです。最初のデプロイで、いきなりエラーが出ました。「ToolSchema のキーが許可されていない」という内容です。

Kiro が「スキーマの構造を直しましょう」と提案してくれたので、私はそのまま適用しました。そうしたら次は「AllowedAudiences のパターンが合わない」という別のエラー。

「じゃあ認証まわりを直そう」と適用すると、今度は「LambdaTargetConfiguration が invalid」。直すと「InlinePayload が camelCase になっている（PascalCase じゃないとダメ）」。直すと、また別のエラー。

…という感じで、エラーが出る → 直す → 別のエラー、を5回くり返しました。提案が出るたびにすぐ飛びついて、その場しのぎで直して、また別のところが崩れる。完全に負のループです。

いま思えば、本来は2回目あたりで一度手を止めて、ドキュメントを読みに行くべきでした。ただ、エラーがどれも “スキーマの細かい書き方” に見えたので、つい「次こそ直る」と進めてしまったんですよね。

結局どうなったかというと、5回直しても安定しなくて、最後は「CDK で Gateway を管理するのをやめる」という判断にたどり着きました。Gateway の登録は CDK から外して、CLI で個別管理する形にしたんです。

あとから分かったのは、AgentCore Gateway は新しいサービスで、API の仕様が頻繁に変わっていて、CDK の L1 Construct では追従が難しいということでした。これ、最初に公式ドキュメントを Power で1回確認していれば、たぶん見えていた話なんですよね。「ここは CDK で頑張る場所じゃない」と、最初に判断できたはずでした。

5回直す道より、1回調べる道のほうが、ぜんぜん速かった。まさに 急がば回れ です。

この一件で学んだのは、AI の提案を鵜呑みにしない、でも自分で全部調べるのも無理、という現実でした。だから今は「AI に調べさせてから、AI の提案を検証する」という二段構えにしています。これが、はじめに書いた 裏取りファースト の正体です。具体的には、修正提案が出ても、すぐ適用せず——

  1. まず Power で公式ドキュメントを確認する（本当にその仕様？）
  2. 「提案された修正」と「実際の仕様」に乖離がないか照合する
  3. 乖離があれば、修正方針そのものを変える

この「裏取り1手」を挟むだけで、不要な修正の連鎖がほとんど無くなりました。地味だけど、効きます。

ちなみに、新規で実装するときはもう少し順番を厚くしていて、さっき書いた「調べる順番」（ログ → ドキュメント → Power → コード → 人に確認）に沿っています。修正提案の検証は、そのうちの「ドキュメントで裏取り」にあたる部分、という整理です。

もう一つの回り道 — IAM 権限の正体は、名前のひと文字違いだった話

もうひとつ、似たような遠回りをした話を。ただしこれは、あとで steering のルールに化けた、ちょっとだけ報われた失敗です。

E2E の接続確認をしていたとき、Lambda から AgentCore Runtime を呼ぶところで、403（権限エラー） にぶつかりました。

IAM ポリシーには bedrock-agentcore:InvokeRuntime を付けています。名前からして、これで合っているはず。Kiro も「ポリシーは正しいはずなんですけどね…」と言うけれど、何度見直しても 403 が消えません。

ここで本当は、Power で公式の IAM リファレンスを引けばよかった。でも私は先に、ワイルドカード（bedrock-agentcore:*）で全部許可して切り分ける、という手っ取り早い道を選んでしまいました。結果は——あっさり動きました。（念のため：このワイルドカードは原因を切り分けるための dev 環境限定の一時措置で、本番に向けては最小権限に絞る前提です。）

動いたということは、ポリシーの書き方ではなく、アクション名そのものが間違っていたということです。あとから公式リファレンスで確認したら、正しくは bedrock-agentcore:InvokeRuntime ではなく bedrock-agentcore:InvokeAgentRuntime でした。Agent がひとつ入る。

なぜこうなったのか、正確なところは分かりません。ただ、AgentCore が比較的新しいサービスなこと、似た名前のアクション（別サービスの bedrock:InvokeAgent など）が存在することを考えると、AI が “それっぽい名前” を類推で組み立ててしまったんじゃないかと思います。いずれにせよ、AI が自信満々で間違った名前を出してきた、という事実は変わりません。

ワイルドカードで動かしたこと自体は、切り分けとしては正しい一手です。でも、先に Power でドキュメントを引いていれば、回り道せずに一発で分かった——またしても、です。

この一件があってから、私は steering に 「IAM 権限まわりは、実装する前に必ず Power で確認する」 というルールを足しました。さっきの「Power を使うべき判断基準」に IAM が入っているのは、実はこの失敗が元になっています。失敗が、そのままチームのルール（申し送り書）になった、というわけです。

思ったこと

ここまで2つのつまずきと1つのルールを書いてきて、改めて思うのは、AI と開発するときに本当に効くのは「調べる前に手を動かさない」という規律のほうだ、ということでした。

Power という道具そのものより、「いつ・何を裏取りするか」を決めてルール化したことのほうが、ずっと効きました。道具は、ルールがあって初めて活きるんだなと。

もちろん「実装前にドキュメントを読む」なんて、エンジニアにとっては当たり前の基本です。今回おもしろかったのは、その当たり前を AI 自身の挙動として steering に埋め込めた こと。人間が毎回気をつけ続けるんじゃなく、仕組みで担保できるようになったのが、これまでと違うところでした。

これは前回の「書いていないことは、AI に伝わらない」とも地続きです。作るときのルールだけじゃなく、「どう調べるか」も書いておかないと、AI は平気で推測で進みます。逆に書いておけば、ちゃんとそのとおりに裏を取ってくれる。

新しいサービスを触るときほど、この「推測と事実を分ける」規律が効く——これが今回の一番の学びでした。

これからどうするか

いまは aws-devops-agent / aws-agentcore の2つが中心ですが、observability や cost まわりの Power も、運用フェーズに入ったら本格的に使ってみたいと思っています。「Power を使うべき判断基準」も、使いながらまだまだ育てていく予定です。

もし、AI に推測で書かれて困っている方がいたら——「とりあえず動いたけど、なんか不安」みたいな状態の方がいたら、Power と steering の “裏取りルール” はけっこうおすすめです。AI に調べさせてから、その結果で AI の提案を検証する。この二段構えだけで、だいぶ安心して任せられるようになります。

まとめ

  • Powers ＝ AI が AWS の「今」や公式ドキュメントを、自分で調べに行ける拡張
  • でも効くのは Power 単体じゃなく、「いつ・どう裏取りするか」を steering に書くこと
  • ねらいは 「推測」と「確認済み事実」を分けること＝裏取りファースト。情報の少ない新サービスほど、これで効いてくる

先に調べるのは、一見すると遠回りです。でも AI と作るときほど、その遠回りが一番の近道でした。

おまけ：このシリーズについて

この記事は、Kiro で社内ツールを作りながら書いているシリーズの一本です。「Kiro をどう使っているか」を、作業のフェーズごとに分けて書いています。

書く → 調べる → レビューする。Kiro と一緒に「作る前・作りながら・作ったあと」をどう回しているか、という流れです。

そして最後の一本は、いま作っているプロダクトが完成したら書くつもりです。たぶん「実際に運用に乗せてみたら」みたいな話になると思います。進捗があったら、また書きます。