はじめに

先に結論を書いておくと、「コードを書く」より「要件を整理して、引き継ぎ資料を書く」のが得意なタイプの人ほど、Kiro と相性がいいかもしれない、という話です。

私はいま MSP 監視チームのセクションリーダーをしていて、立場としてはずっと「開発を依頼する側」でした。

何かツールを作りたいとき、自分でガリガリ実装するというより、要件を整理して開発チームにお願いする。レビューも開発フローの中で誰かがやってくれる。そういう動き方がほとんどだったんですよね。

ところが最近、大規模障害対応を補助する社内ツールを 自分一人で 作る機会がありました。使ったのが Kiro です。

言い換えると——コードが書けないことは、AI と作る時代には、もう致命的な弱みじゃないのかもしれない。むしろ、マネジメントで毎日やっている「整理して、書いて、任せる」が、そのまま開発の武器になる。これを Kiro の3つの機能 spec / steering / hook で実感した、というのが今日の話です。

正直、最初は「私が一人で動くものを作れるのかな」と半信半疑でした。でもやってみたら、思っていたのと違う手応えがあったので、その記録を残しておきます。

ざっくり言うと

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

  • spec を書く作業は、マネジメントでいつもやってる「要件整理」とほぼ同じでした
  • steering file は、AI への「申し送り書」だった。チームの新メンバーに渡す引き継ぎ資料を書く感覚に近いです
  • hook で「読み取りはAIに任せる／壊す操作は人間が承認」を切り分けたら、安心して手綱を渡せるようになりました

特に2つ目の「申し送り書」感覚は、マネージャーや運用者の人ほどピンと来るんじゃないかと思います。順に書いていきます。

きっかけと、最初の壁

作りたかったのは、大規模障害のときに Incident Commander のトリアージ判断を助ける社内 AI ツールです。技術構成だけ並べると、Bedrock AgentCore + Strands Agents SDK + Lambda + DynamoDB + Next.js、みたいな感じ。書き出すとそれっぽいですが、私自身は全部を手で書けるわけではありません。

最初にぶつかった壁は、シンプルに 「何から手をつければいいのか分からない」 でした。

コードを書ける人なら、頭の中で設計しながら手を動かせるんだと思います。でも私はそれができない。いきなり実装に飛び込むと、確実に迷子になる自信がありました。

そこで Kiro の spec-driven という進め方に乗ってみることにしました。requirements.md（要件）→ design.md（設計）→ tasks.md（タスク）の3点セットを先に書いてから、それに沿って実装する、というやり方です。

これを見たとき、正直「あ、これ知ってるやつだ」と思いました。要件を決めて、設計に落として、やることリストに分解する。マネジメントで普段やっている段取りと、ほとんど同じだったんですよね。

spec を書いてみたら、要件定義は「いつもの仕事」だった

実際に spec を書き始めてみると、これが思った以上にしっくり来ました。

たとえば「インシデント一覧を返す API」みたいな機能ひとつでも、requirements.md に「認証はどうする」「ページネーションは」「エラー時の挙動は」と要件を番号付きで並べていく。気づいたら Requirement が9個になっていました。

これ、新しい施策を始めるときに「論点を洗い出して箇条書きにする」のと、頭の使い方が同じなんです。コードの知識というより、「漏れなく整理する力」が効く作業でした。

面白かったのが tasks.md の Wave 構成 です。メインの spec だけでタスクが 112 個あって、それぞれに依存関係が JSON の依存グラフで定義されている。「Wave 0 が終わったら Wave 1 に進んでいいよ」という順序を私が決めて、AI がその通りに手を動かす。

これはもう、プロジェクトの工程表をそのまま AI に渡している感覚でした。段取りを組む力が、そのまま「AI への指示書」になる。役割分担がすごく自然だったんです。

↑ これが実際の tasks.md の一部です。waves（ウェーブ）という単位で「どのタスクを、どの順番で実行していいか」をまとめていて、AI はこの順番（Wave -1 → 0 → 1 …）でタスクを進めてくれます。番号の若いものから片付けて、依存しているものは後回し、というのが一目で分かります。

個人的に気に入っているのが、途中の id: 11.5 に入っている「ペアレビュー指摘の取り込み（Wave 12 着手前ゲート）」というメモです。これは「人のレビューが終わるまで次の工程に進まない」という関所を、工程表の中に自分で埋め込んだもの。AI に任せきりにせず、要所で人が確認するポイントを段取りとして組み込めるのが、地味だけどすごく安心感があります。

最終的に、機能ごとの spec が10個ほど積み上がりました（セキュリティ強化、統合テスト、API追加…と、関心事ごとに spec を分けていく運用です）。結果として、フロントエンドからインフラまで約3週間で E2E（端から端まで動く状態）に到達できて、Property-Based Testing を含むテストも600件以上、CDK のスタックも9本がデプロイできる状態になりました。

正直、3週間前の自分に「一人でここまで行けるよ」と言っても信じなかったと思います。

steering file が「AI への申し送り書」だった

ここが今回、一番「なるほど」と思った部分です。

Kiro には steering file という仕組みがあります。プロジェクト全体に効かせたいルールやドメイン知識を Markdown に書いておくと、セッションをまたいでも、書いた内容を毎回 AI が読み込んでくれる——つまり、いちいち同じ説明をし直さなくてよくなる、というものです。

私はここに、MSP 監視チームの「当たり前」を書きました。

たとえば msp-triage-knowledge.md というファイルには、大規模障害をどういうトリガーで判断するか、アラートのノイズパターンはどういうものか、どういうときに連絡を上げるか、といったチームの暗黙知をまとめています。これを書いておくと、AI が「うちのチームのルールを分かっている前提」で実装を進めてくれるんですよね。

これ、感覚としては完全に 新しく入ったメンバーへの「申し送り書」 なんです。

新メンバーが来たとき、私たちは「うちはこういうルールで動いてます」「これは触っちゃダメです」という引き継ぎ資料を渡しますよね。steering file は、まさにそれを AI 向けに書いている感覚でした。

しかも面白いのが、申し送り書は1枚じゃなくていい、というところ。私の場合は6本に分けて運用しています。

  • 障害トリアージのドメイン知識を書いたもの（fileMatch 条件付き — Agent や Tool のコードを触ったときだけ自動で効く）
  • 「構築しながら学んだことは記録に残す」という学習方針を書いたもの（常時有効）
  • 実装したら設計書に反映する、という同期ルールを書いたもの（常時有効）
  • タスク実行の振る舞いルール（コマンドは Kiro が実行する、テスト確認はローカルで、Git 運用規約）
  • Backlog 課題の作成テンプレート（手動で呼び出すタイプ）
  • ターミナルまわりでハマった問題の解決メモ（手動で呼び出すタイプ — 同じ罠に二度はまらないための記録）

…といった具合です。ポイントは、「いつ効かせるか」を制御できること。常に効かせるもの、特定のファイルを触ったときだけ自動で効くもの（fileMatch）、手動で呼ぶもの（manual）——私はこの3パターンを使い分けています。

たとえば MSP の判断ルールが書かれた steering は、Agent のコードを触っているときだけ自動発動する設定にしています。フロントエンドを触っているときにまでドメイン知識がコンテキストに入ると邪魔になるので、必要なときだけ効かせる。これは「状況に応じて申し送り書を出し分ける」感覚で、チーム運営でやっている「この会議ではこの資料を出す」の判断と同じですよね。

そしてもう一段おもしろいのが、steering には Global と Workspace の2つのスコープがある、というところです。

  • Workspace は、いま開いているプロジェクト専用の申し送り書。さっきの MSP のドメイン知識みたいな「この案件だけのルール」を置きます。
  • Global は、どのプロジェクトを開いても効く申し送り書。私はここに「自分はこういう人間で、こういう文体で書く」みたいな、いわば “私という人間の取扱説明書” を置いています。

これも、新メンバーに渡す資料が「会社共通の就業規則」と「この現場だけのローカルルール」に分かれているのと同じだなと思いました。実はこの記事自体も、Global に置いた「技術ブログの書き方」の申し送り書が効いた状態で書いています。AI が私の口調を覚えてくれている感じで、ちょっと面白い体験です。

hook で、AI に手綱を渡しても怖くなくなった

もうひとつ、安心材料になったのが hook です。

AI に開発を任せていて一番怖いのって、「勝手に何か壊されたらどうしよう」だと思うんです。特に AWS を触る作業だと、delete 系のコマンドを勝手に実行されたら、と考えると手が止まります。

そこで auto-approve-aws-read という hook を入れました。これは preToolUse（ツール実行前）のタイミングで動く仕組みで、shell コマンドが走る前に毎回 AI が「これは安全か？」を判定するという構造です。

具体的に何を許可しているかというと:

  • describe-* / get-* / list-* みたいな、見るだけの AWS CLI コマンド → 自動でOK
  • lambda invoke / cognito-idp initiate-auth みたいな、テスト用の実行系 → 自動でOK
  • cat / grep / jq / npx cdk synth みたいな、ローカルで完結する安全なコマンド → 自動でOK
  • create-* / delete-* / update-* / deploy / rm -rf みたいな、壊しうるコマンド → 拒否して私に確認を求める

面白いのが、これが単純な正規表現マッチではなくて、AI が文脈を見て判断する仕組みになっているところです。「明らかに破壊的じゃなければ通す」というニュアンスの判定ができる。

正直に言うと、これは AI の判断に100%寄りかかる仕組みではありません。取りこぼしもありうるので、本丸の安全弁は「破壊的操作は人間が承認」のほうに置いていて、自動承認はあくまで “明らかに安全な読み取りの摩擦を減らす” ための割り切り、という使い方にしています。

これを入れたら、調査系の作業はサクサク進むのに、危ない操作の手前では必ず一回止まる、という状態になりました。実際、この記事のために手を動かしている間も、find や grep が hook を通過してスッと自動承認されるのを何度も見ました。

「見るのは任せる、壊すのは人間が確認する」。この線引きが効いていて、AI に手綱を渡しても怖くなくなったんですよね。

これはマネジメントで言う「権限委譲」と全く同じだなと思いました。任せる範囲と、必ず自分が見る範囲を決める。それを設定ファイルで表現できるのが、地味だけどすごく良かったです。

思ったこと

一通りやってみて、一番強く感じたのは 「マネジメントのスキルが、そのまま開発のスキルになった」 ということでした。

要件を整理する、段取りを組む、チームの当たり前を言語化する、任せる範囲を決める。どれも普段マネージャーとしてやっていることで、コードの知識とは別物です。

Kiro の spec と steering と hook は、その「普段やっていること」を、AI と一緒に開発する形に翻訳してくれる仕組みだったんだなと思います。

逆に言うと、書いていないことは AI に伝わらない、ということでもあります。チームの当たり前を申し送り書に書かなければ、AI はそれを知らないまま動く。「書く」という行為が、これまで以上に強い意味を持つ感覚がありました。

コードを書くのが苦手でも、「整理して書く」のが得意なら、十分に戦える。これは同じような立場の人に伝えたいなと思いました。

これからどうするか

このプロダクトはまだ作っている最中です。今回は spec / steering / hook ——つまり「作る前の段取り」の話に絞りました。

実はこの開発、もうひとつ Kiro の Powers（AWS の公式ドキュメントや実環境の状態を、AI が直接調べに行ってくれる仕組み）を現在進行形でかなり使っています。たとえば AgentCore みたいに新しすぎて情報が少ないサービスでも、AI が公式ドキュメントを Power 経由で参照してから実装してくれる。しかも「どんなときに、どの Power で裏取りするか」の判断基準を steering に書いて、AI に任せています。

この「Powers で”推測しないで作る”」話は長くなるので、別記事でじっくり書こうと思っています。

同じような立場の方 — つまり、開発は依頼する側だったマネージャーや運用者で、でも自分でも何か作ってみたいと思っている方 — がいたら、いきなりコードからじゃなく、spec（要件整理）と steering（申し送り書）から入ってみるのをおすすめしたいです。

たぶん、思っているより自分の今までのスキルが効きます。

もし試した方がいたら、どんなふうに steering を書いたか共有しあえると嬉しいです。私もまだ手探りの最中なので、一緒に学んでいきたい感じです。

まとめ

長くなったので、3つにまとめて締めます。

  • spec を書く = いつもの「要件整理」。コードより先に、得意な段取りから入れる
  • steering file = AI への申し送り書。チームの当たり前を書くと、AI が文脈を持って動く
  • hook = 権限委譲の線引き。読み取りは任せ、壊す操作は人間が承認。安心して手綱を渡せる

「コードが書けないと開発はできない」と思っていたんですが、Kiro を触ってみて、その前提が少し変わりました。整理して、書いて、任せる。それでプロダクトが立ち上がっていく感覚は、純粋に楽しかったです。

おまけ：書いた設計書が、AI レビューの「評価軸」にもなっていた話

ここまで「書く」ことの話をしてきましたが、実はこの“書いた設計書”、別の場面でも効きました。

Kiro の spec で書いた設計書（requirements.md / design.md）を、コードだけじゃなく AWS Security Agent（AWS の AI セキュリティレビュー）にも一緒に渡してみたんです。

そうしたら、設計書に書いた要件が、次のコードレビューの 自動評価軸として認識される、という閉ループが起きました。「書くこと = AI の判断基準を定義すること」という今回の話と、まさに地続きの体験で、これはちょっと感動しました。

この話だけで一本書いているので、興味があればこちらもどうぞ。

→ AWS Security Agentにレビューしてもらったら、設計書を書くことが急に楽しくなった話

「spec を書く」が、開発の場面でもレビューの場面でも効いてくる。書いておくと、いろんなところで AI が拾ってくれるんだなと実感しています。