ENGINEER BLOG ENGINEER BLOG
  • 公開日
  • 最終更新日

【Kiro】Kiroワークショップに参加して学んだ「仕様駆動開発」の実力と、報告会で見えたリアルな反応

この記事を共有する

目次

この記事の一部はKiroによって生成されました

こんにちは。
パーソル&サーバーワークスの佐藤(美)です。
最近はAIコーディングによる業務の効率化に興味があり、社内外でAIを活用している方を参考に模索していますが、その中で「動くコード」と「正しいコード」は違うと漠然と感じていました。
先日、Kiroワークショップに参加して、その差を埋める鍵が「仕様駆動開発」にあると実感しました。

この記事では、仕様駆動開発について今回のワークショップで学んだことと、後日実施した報告会での反応をまとめます。

イベントの概要

ワークショップの内容

Kiroを座学とハンズオンで学ぶ、途中の休憩を含む計5時間程度のワークショップに参加しました。
構成は以下の3パートです。

パート 内容
ワークショップ1 既存ECサイトの改修(Specモードで商品説明欄を追加)
座学パート Spec開発とVibe開発の違い、Steering・Hooksの使いどころ、ベストプラクティス
ワークショップ2 Kiroを使った自由開発(テーマは参加者が自由に設定)

Spec開発とVibe開発 ― 何が違うのか

Specモード:仕様を作ってからAIに開発させる

ワークショップ1では、既存のECサイトのソースコードを読み込ませ、新機能の実装を行いました。
既存改修の要件を整理するために、Spec開発を選択してRequirementsから作っていきます。

図: Specモードの選択画面

Requirementsとは?

要件定義のことです。Kiroが要件を整理し、requirements.mdを自動生成します。
ただし、成果物は人間が確認・修正を行います。この段階で抜け漏れがないかチェックすることが、Spec開発の肝です。

Specモードで「商品に説明欄を追加したいです」とたった一言送信すると、以下のような要件ドキュメントが生成されました。
一言の指示から、既存仕様の把握・新しい要件の整理まで行ってくれています。

図: 一言の指示から生成されたRequirements

Requirementsの後は、Design(技術設計)→ Tasks(実装タスクの分解)と進みます。
要件から設計、設計からタスクまですべてが追跡可能で、「なぜこのコードが生成されたのか」を遡れるのがSpecモードの大きな強みです。

Vibeモード:スピード重視のプロトタイピング

一方、Vibeモードでは仕様に関するドキュメントを作成せず、チャットベースで直接コードを生成します。
最大の利点はスピードです。仕様を確定させないため機動力があり、プロトタイピングや検証に向いています。
ただし、仕様のトレーサビリティがないため、長期的なメンテナンスが必要なアプリケーションには不向きです。

自由開発で見えた両モードの差

ワークショップ2では課題は提示されず、参加者がテーマを決めて自由に開発しました。
ここで顕著だったのが、SpecモードとVibeモードで所要時間と仕上がりの粒度に大きな差が出たことです。

私はKiro学習用のクイズアプリをSpecモードで開発しました。
「簡単に」と指示しても、AIが詳細に要件を定義してくれます。曖昧さを許さない仕組みです。
結果として、11タスク中3タスクが完了した時点で45分が経過。詳細な機能まで実装されたものの、ワークショップの時間内には完成しませんでした。
チームの他の参加者も半数は時間内に終わらなかったようです。

図: Specモードでの開発中の様子 短時間で「動くもの」を見せるならVibeモード、品質とトレーサビリティを確保するならSpecモード。
場面に応じた使い分けが重要だと体感しました。

Steering・Hooksの使いどころ

KiroはAIモデルではなく、VS Codeから派生した統合開発環境(IDE)です。
そのため、VS Codeの拡張機能など普段の開発体験をそのまま活かせます。
加えて、Kiro独自の機能としてSteeringとHooksが用意されています。

Steering ― チームのルールをAIに守らせる

技術スタックやコーディング規約をファイルで定義し、AIに守らせる仕組みです。
プロジェクト内の所定フォルダに配置するだけで、AIが生成するコードすべてに一貫したルールが適用されます。

Steeringの有無でどれだけ変わるか?
ワークショップ1では、Kiroに日本語で応答させるためのSteeringファイルを作成しました。
Steeringファイルに「日本語を使用すること」と定義するだけで、AIが生成するコードのコメントや変数名の説明がすべて日本語に統一されます。
たったこれだけの設定で出力が一貫して変わる体験は、Steeringの仕組みを直感的に理解するのに十分でした。

SteeringファイルはGitで管理できるため、「誰がいつルールを変更したか」も追跡可能です。
新メンバーが入っても同じ品質基準が適用されるので、属人化の防止にもつながります。

Hooks ― 自動で品質チェックを走らせる

Hooksは、ファイル保存時に自動でレビューやLintを実行する仕組みです。
人がレビューする前にAIが品質チェックしてくれるため、問題をリアルタイムで検出できます。
また、仕様変更時にSpecファイルとコードの乖離を自動で検知・修正する用途にも活用できます。

ワークショップで学んだベストプラクティス

座学パートで共有されたベストプラクティスの中から、特に実務で役立ちそうなものを紹介します。

Specファイルの分割管理
1つの大きなSpecファイルにまとめるのではなく、独立したドメインや機能ごとにSpecファイルを分割することが推奨されています。大きなSpecだとファイル間でコンフリクトが発生しやすくなるためです。

仕様変更時のフロー
仕様変更があった場合は、Requirementsから修正し、Refine → Update tasksと進めます。
Hooksを活用すれば、この反映を自動化することも可能です。

チーム開発での共有
SpecファイルはGitで管理し、共通部分はGit Submoduleで共有するのが推奨されています。

コンテキストの管理
AIのコンテキストが80%を超えたら、重要な情報をSteeringにテキスト化しておくことが推奨されています。
AIが参照できる情報量には限りがあるため、整理しておくことで精度を維持できます。

セキュリティと責任
AIがセキュリティ対策を提案することはできますが、最終チェックは人間が必須です。
ワークショップでは、Linuxの生みの親であるLinus Torvaldsの言葉が引用されていました。
「人間が作成したものは人間が責任を持つ」― AIはあくまでツールであり、最終判断と責任は開発者にあります。

報告会を実施して

後日、このワークショップの内容をお客様向けに報告会として共有しました。

報告会の工夫

今回報告会に参加いただいたのは、AIコーディングに触れたことがない方がほとんどでした。
そのため、ライブデモを3本(Vibeモード、Specモード、Steering比較)組み込んで、実際の動きを見てもらう構成にしました。

実は、この報告会の発表資料(スライド、スクリプト、デモ用のSpec)もすべてKiroとの対話で作成しています。
アウトラインの相談から始めて、構成の提案、デモシナリオの設計、スライドの生成まで、Kiroと一緒に進めました。
コーディングだけでなく、資料作成や企画整理にも活用できるというのは、使ってみて初めて実感したことです。

リスナーの反応

Kiroにほとんど触れたことがないリスナーの皆様からは、以下のようなご意見・ご感想をいただきました。

  • 前向きな声: 早速PCにインストールして使ってみたい。ゼロからコードを書かなくても、機能実装の参考にできそう。
  • 慎重な声: 使いどころによっては活用できそうだが、実務での利用には情報の正確性やセキュリティ面で不安もある。
  • 具体的な活用イメージ: 今まで使用したことのないAWSサービスを用いてシステム構築をする際の、実装のたたき台として使えそう。

前向きな反応と慎重な反応の両方があったのは健全だと感じました。
AIツールの導入には「何ができて、何ができないか」を正しく理解することが不可欠です。
報告会がその理解の入り口になれたなら、実施した意味があったと思います。

まとめ

これまではKiroの中核をなす仕様駆動開発について深く掘り下げたことがなく、手探り状態で使用していました。
今回のワークショップを通じて、Spec・Steering・Hooksという3つの柱を体系的に理解し、実務に活かせるスキルを得ることができました。

特に印象に残っているのは以下の3点です。

Specモードの「曖昧さを許さない」仕組み
一言の指示からでも、AIが要件を詳細に定義してくれる。

Steeringによるルールの強制力
ファイルを1つ置くだけで、生成コードの品質が劇的に変わる。
使い方によってはチーム全体のコードの質やセキュリティ水準を底上げできる。

AIはツールであり、仕様の質と人間の判断が成果を決める
良い仕様を書けば良いコードが出てくるし、曖昧な仕様なら曖昧なコードが出てくる。


Kiroは魔法のツールではありません。しかし、仕様を軸にAIをコントロールするというアプローチは、品質とスピードの両立を目指すチームにとって大きな武器になると感じています。

この記事は私が書きました

sato(mi)

記事一覧

はじめまして。ブログをご覧いただきありがとうございます。 日々の気づきや学び、役に立ったことを中心に発信しています。 少しでも誰かのヒントや後押しになれば嬉しいです。

sato(mi)

この記事を共有する

クラウドのご相談

CONTACT

クラウド導入や運用でお悩みの方は、お気軽にご相談ください。
専門家がサポートします。

サービス資料ダウンロード

DOWNLOAD

ビジネスをクラウドで加速させる準備はできていますか?
今すぐサービス資料をダウンロードして、詳細をご確認ください。