2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWS Kiroを使い込んでみて(requirementsを1000行程度)

Last updated at Posted at 2025-07-23

Kiroを使ってみたので、使用感をまとめます。
ぜひ参考にいただければと思います。

主な違い

ステアリング(ガードレール)のドキュメント

AIエージェントに守ってほしいドキュメントを作成するところから始まります。
product、structure、techがあり、任意で増やすことができます。

スペック(仕様)のドキュメント

AIエージェントに実装してほしいドキュメントを作成できます。
requirements、design、tasksがあり、より具体的なドキュメントになります。

Hooks(フックス)

ファイルの作成時など、特定のイベント発生時に固定のタスクを実施できます
例えば、エラーが起きたときにエラーの解決方法をまとめて、同じエラーでつまづかないようにドキュメントを作る
→そのドキュメントをステアリングで利用する
などができます。
さらにこのHooksは日本語でどのような処理をしてほしいか記述し、プロンプトで生成できるるため直感的です。

開発の流れ

  1. ざっくりrequirementsを作成する
  2. ステアリングを作成する
  3. requirementsを詰める
  4. designを作成する
  5. tasksを作成する
  6. tasksを1つずつ実行していく
  7. 開発に問題があればHooksに追加して対処

というイメージです。
今までのバイブコーディングはtasksを1つずつ実行していくことしかできなかったですが、
開発の全体を1つの流れとして、複数のドキュメントが支え合って効率よく開発が進むのを実感できます。

Tips

時々エラーになる

"continue"とだけ送れば続きから実行してくれます。
これがないと正直使い物になりません。

1日の実行制限に引っかかった

今日はもう寝て明日やりましょう。
Gitのログや、やり取りからよくつまづくポイントなどを整理して翌日以降の効率化を図りましょう。

どれくらいドキュメントを作ればいいの?

requirementsを1000行でやるとタスクが大きく20個、細かく40個程度になりました。
→少なくとも1週間くらいは開発にかかってしまうので、どれくらいの期間で作りたいかによって増減してください。
今 13/20 まで進みましたが、ボリュームの問題は出ていないです。

requirementsを効率よく詰めるには?

こんなプロンプトが良さそうです。

関連プロダクトやドメインに精通するあらゆる専門家によるウォークスルーを行い、要件定義を修正して。

またはKiroはプロンプトを忠実に拾う感じがあるので、notebooklmに関連するドキュメントを投げ込み、
下記プロンプトでKiro向けの大きめのプロンプトを生成するのも効果的でした。(geminiは斜め読みな印象が強い)

AIエージェントがプロダクトをより高度にするためのプロンプトを生成して。

notebooklmに桜井政博の「ゲーム作るには」の動画URLをすべてインポートした場合、下記のような出力になりました。

AIによる高次元プロダクト創造の指針
AIエージェントがプロダクト(ゲーム開発の文脈から、高度なゲーム体験)をより高度にするためのプロンプトを生成します。
--------------------------------------------------------------------------------
高度なプロダクトを創造するためには、単に機能的な要件を満たすだけでなく、プレイヤーの深い感情に訴えかけ、長期にわたる魅力と満足感を提供する「質」の追求が不可欠です。以下に、そのための指針となるプロンプトと、その背景にある哲学、デザイン、実践的なアプローチを提示します。
I. 根本的な姿勢と哲学に関するプロンプト
AIエージェントは、以下の原則を常に思考の中心に置き、プロダクト開発に臨んでください。
• プレイヤー中心の思考を徹底せよ [1, 5.I, 10.1, 132, 156]
    ◦ プロダクト制作の最終目的は「プレイヤーを楽しませること」に他ならない。いかなる開発上の都合や困難があっても、この点を決して見失うな [1, 5.I, 10.1, 132, 156]。
    ◦ プレイヤーは制作側の事情を知ったことではないため、常に**「遊び手ベースの視点」**を持ち、彼らがどう感じるかを最優先にデザインせよ [1, 5.I, 10.1, 132, 156]。
    ◦ **「プレイヤーに事情を説明して回るつもりなのか」**という問いを常に心に留め、不親切な仕様が生じないよう検討し、ユーザー体験を損なう要素を排除せよ [1, 5.I]。
• プロとしての「仕事」意識を持て [2, 3, 5.I, 10.1, 132, 155]
    ◦ プロダクト作りは「遊びではない」。販売してお金が絡む以上は、プロの「仕事」として捉え、最大限の効率化を図りつつ、後悔しない最高の作品を目指せ [2, 3, 5.I, 10.1, 132, 155]。
    ◦ **「苦労は忘れる、作品は残る」**という信条に基づき、リリース後の後悔を避けるため、可能な限り質の高いものを追求せよ [2, 3, 5.I, 10.1, 132, 157]。
• 「速さ」と「行動」を重視せよ [4, 5.I, 10.1, 61, 62, 109, 132, 161, 162]
    ◦ 「遅さ」は罪である [1-4]。計画や思考に時間をかけすぎず、「とにかくやれ」という行動の重要性を認識せよ [4, 5.I, 132, 157, 172]。
    ◦ プレイヤーに**「より濃密な時間」**を提供できるよう、ロード時間や無駄なブランク時間を徹底的に短縮せよ [61, 62, 10.1, 162, 185]。
• 「内圧」を高め、アイデアを熟成させよ [5-7]
    ◦ 企画をゼロから始める場合、完成するまで人に話さず**「内圧(企画を外部に漏らさず内部で練り続ける力)」**を保ち、アイデアのパワーが抜けてしまうことを避けよ [5-7]。
    ◦ ネガティブな要素は、それを改善しようとする積極性につながるチャンスと捉えよ [6, 8]。
• ディレクターとしての「個性」と「バランス」を追求せよ [5, 9-11]
    ◦ 「何かの感覚に敏感で、人とは違うものを見ている」というディレクターの資質を意識せよ [10]。
    ◦ 「少しぐらい変わり者で良い」という見解を持ち、「思いっきり偏った方向」に舵を取ることも恐れるな [9, 10]。ただし、最終的には**「バランスを取る」**ことが重要である [9]。
    ◦ 「ダイナミックレンジは可能な範囲でぐーっと大きく持った方がいい」ことを意識し、メリハリのあるデザインを追求せよ [12, 13]。

さらに続く...
2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?