DEVELOPER’s BLOG

技術ブログ

AWS Kiro Spec駆動開発とは - AIとの対話を構造化する新しいアプローチ

2026.03.05 Jun Moronaga
体験記 生成AI
AWS Kiro Spec駆動開発とは - AIとの対話を構造化する新しいアプローチ

目次

  1. はじめに
  2. Kiroについて
  3. 実際に触ってみた
  4. 感想
  5. おまけ


1. はじめに

AIを使用してコーディングする場面を思い浮かべてください。
コード生成した結果、周辺とは違った書き方をされたり、余計な箇所を直されたり、意図しない修正をされて困った経験はありませんか？
他機能への影響が限定的な箇所や、とても簡単な機能の修正は、思い通りにいくことが多いですが、
他機能への影響が大きい改修など、機能の複雑度が高くなればなるほど上手くいかないことは顕著になりませんか？
本来はそんな(レバレッジの効きやすい)大規模な修正作業こそ、AIに任せたいものですよね。(しみじみ)

これらの問題の多くは、AIに「何を作りたいか」を正確に伝えられていないことが原因であることが多いと思います。
つまり、AIとの対話において、必要な情報を適切な形で提供できていないことが原因です。
プロンプトを調整したり、サービスとやり取りするチャットのセッションをリセットしたり、AIへの依頼方法を調整する行為をプロンプトエンジニアリングの上位概念として「コンテキストエンジニアリング」と言うらしいです。

調整したコンテキストをAIに依頼する。という熟練者達の暗黙知を
手段として提供しているAIコーディングエージェント「AWS Kiro」について、特徴や実際の操作についてまとめてみたので紹介します。


2. Kiroについて

AWS Kiroは、AIコーディングエージェントで、特にSpecモードが特徴的です。
公式ドキュメント

2.1. Spec駆動開発：AIとの対話を構造化する

従来のAIコーディングエージェントでは、「何を作りたいか」「どう作るか」はユーザの任意のタイミングで伝える必要がありました。
しかし、KiroのSpecモードは、開発プロセスを3つのフェーズに分けることで、AIとの対話を構造化してます。

  • フェーズ1: 要件定義（Requirements）
    • 「何を作るか」を明確にする
    • ユーザーストーリーと受入基準を定義
    • この段階でレビュー・修正が可能
  • フェーズ2: 設計（Design）
    • 「どう作るか」を設計する
    • アーキテクチャ、コンポーネント、テスト戦略を定義
    • 要件を基に自動生成され、レビュー・修正が可能
  • フェーズ3: 実装計画（Tasks）
    • 「どの順番で作るか」を計画する
    • 具体的なタスクリストを生成
    • 設計を基に自動生成され、レビュー・修正が可能


この段階的なアプローチにより、各フェーズで必要な情報だけに集中することができ、AIに対して適切な情報を適切なタイミングで提供することができます。
結果として、AIが生成するコードの品質が安定し、意図しない実装を最小限にすることができます。

注意：

AIへ依頼する仕組みとしては整備がされていますが、必ずしも十分な内容を提案してくれるとは限りません。
意図に沿わないものは、適宜修正する必要があります。
他者に伝えるときと同じように、AIにも伝わるよう丁寧に整理する心遣いが大切ですね。

2.2. なぜSpec駆動開発が効果的なのか

Specモードの最大の特徴は、「AIに必要な情報を段階的に整理させる」という点です。

  • 情報の整理
    • 各フェーズで必要な情報だけに焦点を当てられる
    • 前のフェーズの成果物が次のフェーズの入力になる
    • 情報の抜け漏れを防ぐ
  • レビューポイントの明確化
    • 各フェーズで人間がレビュー・修正できる
    • 早い段階で方向性の誤りを修正できる
    • 実装前に要件と設計を確定できる
  • 品質の安定化
    • 要件から実装までのトレーサビリティ
    • （ドキュメント次第ではありますが）プロパティベーステストを含む包括的なテスト戦略
    • 個々のエンジニアの経験に依存しにくい


つまり、Specモードは「AIとの対話の仕組み」そのものを改善することで、
（ある程度のレベルまでは）誰でも適切にAIに情報を伝えられるようになっています。


3.実際に触ってみた

今回はIDE版で進めていきます。
インストール・セットアップの手順については本記事では割愛します。
詳細は公式ドキュメントをご参照ください。

~ % cd sample_kiro
sample_kiro % kiro .

対象のプロジェクトに移動して「kiro .」でkiro.appが開きます
※kiro.appを開いて対象のプロジェクトを開くでも問題ないです。

kiro_start

「Spec」を選択して、早速以下のプロンプトを渡してみました

ブラウザで動作する簡単なTODOリストを作成したいです。

created_requirements

Kiroが requirements.md(要件ドキュメント) を作成してくれました
中身はこんな感じです

requirements.md - クリックして展開

要件ドキュメント

はじめに

ブラウザで動作するシンプルなTODOリストアプリケーション。ユーザーがタスクを追加、完了マーク、削除できる基本的な機能を提供します。

用語集

  • System: TODOリストアプリケーション全体
  • Task: ユーザーが管理する個々のTODO項目
  • Task_List: すべてのタスクを保持するコレクション
  • Local_Storage: ブラウザのローカルストレージAPI
  • User_Interface: ユーザーが操作するブラウザのUI

要件

要件1: タスクの追加

ユーザーストーリー: ユーザーとして、新しいタスクをTODOリストに追加したい。そうすることで、やるべきことを記録し整理できる。

受入基準

  1. WHEN ユーザーがタスクの説明を入力してEnterキーを押すかまたは追加ボタンをクリックする THEN THE System SHALL 新しいタスクを作成してリストに追加する
  2. WHEN ユーザーが空のタスクを追加しようとする THEN THE System SHALL 追加を防止し現在の状態を維持する
  3. WHEN 新しいタスクが追加される THEN THE System SHALL 入力フィールドをクリアして次の入力のためにフォーカスする
  4. WHEN タスクが追加される THEN THE System SHALL タスクを即座にローカルストレージに永続化する

要件2: タスクの完了マーク

ユーザーストーリー: ユーザーとして、タスクを完了としてマークしたい。そうすることで、どのタスクが完了したかを追跡できる。

受入基準

  1. WHEN ユーザーがタスクをクリックする THEN THE System SHALL タスクの完了状態をトグルする
  2. WHEN タスクが完了としてマークされる THEN THE System SHALL 視覚的なフィードバックを提供する（例：取り消し線、チェックマーク）
  3. WHEN タスクの完了状態が変更される THEN THE System SHALL 変更を即座にローカルストレージに永続化する

要件3: タスクの削除

ユーザーストーリー: ユーザーとして、タスクを削除したい。そうすることで、不要になったタスクをリストから削除できる。

受入基準

  1. WHEN ユーザーが削除ボタンをクリックする THEN THE System SHALL タスクをリストから削除する
  2. WHEN タスクが削除される THEN THE System SHALL 削除を即座にローカルストレージに反映する
  3. WHEN タスクが削除される THEN THE System SHALL UIを更新して削除されたタスクを表示しない

要件4: タスクの永続化

ユーザーストーリー: ユーザーとして、ブラウザを閉じて再度開いたときにタスクが保持されていてほしい。そうすることで、作業を継続できる。

受入基準

  1. WHEN ユーザーがアプリケーションを開く THEN THE System SHALL ローカルストレージから既存のタスクを読み込む
  2. WHEN ローカルストレージにデータが存在しない THEN THE System SHALL 空のタスクリストで開始する
  3. WHEN ローカルストレージのデータが破損している THEN THE System SHALL エラーを処理して空のリストで開始する

要件5: ユーザーインターフェース

ユーザーストーリー: ユーザーとして、シンプルで使いやすいインターフェースを使いたい。そうすることで、タスク管理に集中できる。

受入基準

  1. THE User_Interface SHALL 入力フィールド、追加ボタン、タスクリストを表示する
  2. WHEN タスクが表示される THEN THE System SHALL 各タスクに完了状態と削除ボタンを表示する
  3. THE User_Interface SHALL レスポンシブで様々な画面サイズに対応する
  4. WHEN ユーザーがインターフェースと対話する THEN THE System SHALL 即座にフィードバックを提供する

要件6: データの整合性

ユーザーストーリー: システム管理者として、データの整合性が維持されることを確認したい。そうすることで、ユーザーがデータを失わないようにできる。

受入基準

  1. WHEN タスクが作成される THEN THE System SHALL 一意の識別子を割り当てる
  2. WHEN 複数の操作が実行される THEN THE System SHALL データの整合性を維持する
  3. WHEN ローカルストレージへの書き込みが失敗する THEN THE System SHALL エラーを適切に処理する

要件を確認して、修正したいところがあれば修正します。
今回はこのまま進めます。 Move to design phase を押下します。

created_design

要件に沿って Kiro が design.md(設計ドキュメント) を作成してくれました
アーキテクチャ、コンポーネント、データの永続化の方法論や、正常性プロパティ、テスト戦略まで、結構細かい粒度で設計をアウトプットしてくれました。

design.md - クリックして展開

設計ドキュメント

概要

ブラウザで動作するシンプルなTODOリストアプリケーション。HTML、CSS、JavaScriptを使用して実装し、ブラウザのローカルストレージAPIを使用してデータを永続化します。

このアプリケーションは以下の主要機能を提供します： - タスクの追加、完了マーク、削除 - ローカルストレージによるデータの永続化 - レスポンシブなユーザーインターフェース

アーキテクチャ

アプリケーションは以下の3層アーキテクチャで構成されます：

レイヤー

  1. UI Layer（UIレイヤー）: ユーザーインターフェースの表示とユーザー入力の処理
  2. Application Layer（アプリケーションレイヤー）: ビジネスロジックとタスク管理
  3. Storage Layer（ストレージレイヤー）: データの永続化と取得

コンポーネントとインターフェース

1. Task Model（タスクモデル）

タスクを表現するデータ構造：

2. TaskManager（タスクマネージャー）

タスクの管理を担当するコアコンポーネント

3. StorageService（ストレージサービス）

ローカルストレージとのやり取りを担当

4. UIController（UIコントローラー）

UIの更新とユーザー入力の処理を担当

データモデル

Task（タスク）

ローカルストレージ形式

正確性プロパティ

プロパティとは、システムのすべての有効な実行において真であるべき特性や動作のことです。本質的には、システムが何をすべきかについての形式的な記述です。プロパティは、人間が読める仕様と機械で検証可能な正確性保証の橋渡しをします。

Property 1: タスク追加でリストが増加

任意のタスクリストと有効な（空でない）タスク説明に対して、それをタスクリストに追加すると、タスクリストの長さが1増加するべきです。

検証対象: 要件 1.1

Property 2: 空白文字のみのタスクは無効

任意の空白文字のみで構成された文字列に対して、それをタスクリストに追加しようとすると拒否され、タスクリストは変更されないべきです。

検証対象: 要件 1.2

Property 3: 入力フィールドのクリア

任意の入力バーが空でないUI状態に対して、入力を送信すると入力バーが空になるべきです。

検証対象: 要件 1.3

Property 4: 操作の永続化ラウンドトリップ

任意のタスク操作（追加、トグル、削除）に対して、操作を実行してからローカルストレージから読み込むと、同じ状態が復元されるべきです。

検証対象: 要件 1.4, 2.3, 3.2, 4.1

Property 5: 完了状態のトグル

任意のタスクに対して、完了状態をトグルすると、状態が反転する（completed: false → true または true → false）べきです。

検証対象: 要件 2.1

Property 6: 完了タスクの視覚的フィードバック

任意の完了したタスクに対して、レンダリングされたHTMLには完了状態を示す視覚的インジケーター（CSSクラスや属性）が含まれるべきです。

検証対象: 要件 2.2

Property 7: タスク削除でリストから除外

任意のタスクリストとタスクに対して、そのタスクを削除すると、タスクはリストに含まれなくなり、UIにも表示されなくなるべきです。

検証対象: 要件 3.1, 3.3

Property 8: タスクレンダリングの完全性

任意のタスクに対して、レンダリングされた文字列には、タスクの説明、完了状態インジケーター、削除ボタンが含まれるべきです。

検証対象: 要件 5.2

Property 9: タスクIDの一意性

任意のタスクのコレクションに対して、すべてのタスクIDは一意であるべきです（重複がない）。

検証対象: 要件 6.1

エラーハンドリング

入力検証エラー

  • 空または空白文字のみのタスク説明は拒否される
  • エラーメッセージは表示せず、単に操作を無視する（シンプルなUX）

ストレージエラー

  • ローカルストレージが利用できない場合、メモリ内でのみ動作
  • ローカルストレージのデータが破損している場合、空のリストで開始
  • ストレージへの書き込みが失敗した場合、コンソールにエラーをログ出力

データ検証エラー

  • ローカルストレージから読み込んだデータが無効な形式の場合、そのエントリをスキップ
  • 必須フィールド（id、description）が欠けているタスクは無視

テスト戦略

デュアルテストアプローチ

このアプリケーションは、ユニットテストとプロパティベーステストの両方を使用して包括的なカバレッジを実現します：

  • ユニットテスト: 特定の例、エッジケース、エラー条件を検証
  • プロパティテスト: すべての入力にわたる普遍的なプロパティを検証

両方のアプローチは補完的であり、包括的なカバレッジに必要です。

ユニットテストの焦点

ユニットテストは以下に焦点を当てます：

  • 特定の例（例：「買い物に行く」というタスクを追加）
  • エッジケース（空のストレージ、破損したデータ、ストレージ失敗）
  • コンポーネント間の統合ポイント
  • エラー条件とエラーハンドリング

プロパティベーステストの設定

  • テストライブラリ: fast-check（JavaScriptのプロパティベーステストライブラリ）
  • イテレーション数: 各プロパティテストは最低100回実行
  • タグ形式: 各テストには設計ドキュメントのプロパティを参照するコメントを含める
    • 例：// Feature: browser-todo-list, Property 1: タスク追加でリストが増加
  • 実装ルール: 各正確性プロパティは単一のプロパティベーステストで実装される

テストカバレッジ

  1. TaskManager:

    • ユニットテスト: 基本的な追加/トグル/削除操作
    • プロパティテスト: Property 1, 2, 4, 5, 7, 9

  2. StorageService:

    • ユニットテスト: 保存/読み込み/エラーハンドリング
    • プロパティテスト: Property 4（ラウンドトリップ）

  3. UIController:

    • ユニットテスト: イベントハンドリング、UI更新
    • プロパティテスト: Property 3, 6, 8

エッジケースのテスト

以下のエッジケースはユニットテストでカバーします：

  • 空のローカルストレージ（要件 4.2）
  • 破損したローカルストレージデータ（要件 4.3）
  • ストレージへの書き込み失敗（要件 6.3）
  • 特殊文字を含むタスク説明
  • 非常に長いタスク説明

設計についてもこのまま進めます。 Move to implementation plan を押下します。

created_tasks

tasks.md(実装計画)が作成されました。
一部のタスクをオプション化してまずはコア機能のみの計画にするか or 最初から包括的に作成する計画にするか
聞かれたので、包括的に作ってもらいました。

tasks.md - クリックして展開

実装計画: ブラウザTODOリスト

概要

HTML、CSS、JavaScriptを使用してブラウザで動作するシンプルなTODOリストアプリケーションを実装します。ローカルストレージを使用してデータを永続化し、プロパティベーステスト（fast-check）とユニットテストで品質を保証します。

タスク

  • [] 1. プロジェクト構造とテスト環境のセットアップ

    • HTMLファイル（index.html）を作成
    • CSSファイル（styles.css）を作成
    • JavaScriptファイル（app.js）を作成
    • テスト環境をセットアップ（Jest + fast-check）
    • package.jsonを作成してテストスクリプトを設定
    • 要件: すべて

  • [] 2. StorageServiceの実装

    • [] 2.1 StorageServiceクラスを実装
    • ローカルストレージへの保存・読み込み機能
    • エラーハンドリング（破損データ、ストレージ失敗）

    • 要件: 4.1, 4.2, 4.3, 6.3

    • [] 2.2 StorageServiceのユニットテストを作成

    • 正常な保存・読み込みのテスト
    • 空のストレージのテスト
    • 破損データのエラーハンドリングテスト
    • 要件: 4.2, 4.3, 6.3

  • [] 3. TaskManagerの実装

    • [] 3.1 TaskManagerクラスを実装
    • タスクの追加、トグル、削除機能
    • 一意のID生成（UUID）
    • StorageServiceとの統合

    • 要件: 1.1, 1.2, 2.1, 3.1, 6.1

    • [] 3.2 Property 1のプロパティテストを作成

    • Property 1: タスク追加でリストが増加

    • 検証対象: 要件 1.1

    • [] 3.3 Property 2のプロパティテストを作成

    • Property 2: 空白文字のみのタスクは無効

    • 検証対象: 要件 1.2

    • [] 3.4 Property 4のプロパティテストを作成

    • Property 4: 操作の永続化ラウンドトリップ

    • 検証対象: 要件 1.4, 2.3, 3.2, 4.1

    • [] 3.5 Property 5のプロパティテストを作成

    • Property 5: 完了状態のトグル

    • 検証対象: 要件 2.1

    • [] 3.6 Property 7のプロパティテストを作成

    • Property 7: タスク削除でリストから除外

    • 検証対象: 要件 3.1, 3.3

    • [] 3.7 Property 9のプロパティテストを作成

    • Property 9: タスクIDの一意性

    • 検証対象: 要件 6.1

    • [] 3.8 TaskManagerのユニットテストを作成

    • 基本的な追加・トグル・削除操作のテスト
    • エッジケース（特殊文字、長い説明）のテスト
    • 要件: 1.1, 2.1, 3.1

  • [] 4. チェックポイント - すべてのテストが通ることを確認

    • すべてのテストが通ることを確認し、質問があればユーザーに尋ねる

  • [] 5. UIControllerの実装

    • [] 5.1 UIControllerクラスを実装
    • DOM要素の取得と初期化
    • イベントリスナーの設定（追加、トグル、削除）
    • タスクリストのレンダリング
    • 入力フィールドのクリア

    • 要件: 1.1, 1.3, 2.1, 2.2, 3.1, 5.1, 5.2

    • [] 5.2 Property 3のプロパティテストを作成

    • Property 3: 入力フィールドのクリア

    • 検証対象: 要件 1.3

    • [] 5.3 Property 6のプロパティテストを作成

    • Property 6: 完了タスクの視覚的フィードバック

    • 検証対象: 要件 2.2

    • [] 5.4 Property 8のプロパティテストを作成

    • Property 8: タスクレンダリングの完全性

    • 検証対象: 要件 5.2

    • [] 5.5 UIControllerのユニットテストを作成

    • イベントハンドリングのテスト
    • UI更新のテスト
    • 要件: 1.1, 2.1, 3.1

  • [] 6. HTMLとCSSの実装

    • [] 6.1 index.htmlを完成させる
    • 入力フィールド、追加ボタン、タスクリストのマークアップ
    • JavaScriptファイルの読み込み

    • 要件: 5.1

    • [] 6.2 styles.cssを実装

    • レスポンシブデザイン
    • 完了タスクの視覚的スタイル（取り消し線など）
    • シンプルで使いやすいUI
    • 要件: 2.2, 5.3

  • [] 7. アプリケーションの統合とワイヤリング

    • [] 7.1 すべてのコンポーネントを統合
    • app.jsでStorageService、TaskManager、UIControllerを初期化
    • アプリケーション起動時にタスクを読み込む

    • 要件: 4.1

    • [] 7.2 統合テストを作成

    • エンドツーエンドのフローをテスト
    • 要件: すべて

  • [] 8. 最終チェックポイント - すべてのテストが通ることを確認

    • すべてのテストが通ることを確認し、質問があればユーザーに尋ねる

注記

  • 各タスクは特定の要件を参照してトレーサビリティを確保します
  • チェックポイントは段階的な検証を保証します
  • プロパティテストは普遍的な正確性プロパティを検証します
  • ユニットテストは特定の例とエッジケースを検証します

run all tasks

Kiroにタスクの実行してもらいます。（チャットに「run all tasks」と入力） 実行中は以下のような感じで、進行状況がわかるようになってます。

run

最終的にできたアプリはこちらです。

todoアプリ

  • タスクの追加、削除、do/undoができる
  • データの永続化ができてる（localstrageの範囲で）
  • レスポンシブでシンプルなデザイン


4. 感想

「実際に触ってみた」のセクションで見てきたように、Specモードを使った開発では、
最初の簡単なプロンプトから

  • 要件定義、設計、実装計画が段階的に生成
  • 各フェーズで必要な情報が整理・確認することができ
  • tasks.mdの実行中に何度かエラーが発生し（エラー解析＞修正を繰り返し）つつも、最終的に要件を満たすアプリを完成することができました


実際には、AIが提案する要件や、設計に対して、修正しながら進めていく事になると思います。
「要件定義、設計、実装計画」に時間をかける事で、品質や満足度の高いものを提供していければなと思いました。

AWS KiroのSpec駆動開発は、AIとの対話を構造化することで、品質を一定以上に得られる仕組みだと思います。
プロンプトの書き方ばかりに時間をかけるのではなく、最初から仕組み化されたツールを選ぶことも大切ですね。
ぜひ一度、試してみてはいかがでしょうか。


5. おまけ

AWS KiroにはCLI版の提供もあります。
以下の通り、インストール、pathの設定後に「kiro-cli」にて起動できます。 （メッセージは英語表示になってますが、日本語の質問すると日本語で返ってきました。）
エディターの縛りなく使用が可能です！！

sample_kiro % curl -fsSL https://cli.kiro.dev/install | bash ### Kiro CLIをインストール ###
Kiro CLI installer:

Downloading package...
✓ Downloaded and extracted
✓ Package installed successfully

🎉 Installation complete! Happy coding!

1. Important! Before you can continue, you must update your PATH to include:
/Users/moronagajun/.local/bin

Add it to your PATH by adding this line to your shell configuration file:
export PATH="$HOME/.local/bin:$PATH"

2. Use the command "kiro-cli" to get started!

sample_kiro % nvim ~/.zshrc ### 自分の場合はmacなので「~/.zshrc」に「export PATH="$HOME/.local/bin:$PATH"」を追記 ###
sample_kiro % source ~/.zshrc ### 「~/.zshrc」を再読み込み ###
sample_kiro % kiro-cli ### プロジェクトのディレクトリで「kiro-cli」を実行 ###

sample_kiro % Welcome to Kiro CLI, let's get you signed in!

Press enter to continue to the browser or esc to cancel ### enter 押下するとブラウザが起動するので、ログイン ###

✓ Signed in with Google (use "kiro-cli logout" to logout)
⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀ ⢀⣴⣶⣶⣦⡀⠀⠀⠀⢀⣴⣶⣦⣄⡀⠀⠀⢀⣴⣶⣶⣦⡀⠀⠀⢀⣴⣶⣶⣶⣶⣶⣶⣶⣶⣶⣦⣄⡀⠀⠀⠀⠀⠀⠀⢀⣠⣴⣶⣶⣶⣶⣶⣦⣄⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀ ⢰⣿⠋⠁⠈⠙⣿⡆⠀⢀⣾⡿⠁⠀⠈⢻⡆⢰⣿⠋⠁⠈⠙⣿⡆⢰⣿⠋⠁⠀⠀⠀⠀⠀⠀⠀⠀⠈⠙⠻⣦⠀⠀⠀⠀⣴⡿⠟⠋⠁⠀⠀⠀⠈⠙⠻⢿⣦⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀ ⢸⣿⠀⠀⠀⠀⣿⣇⣴⡿⠋⠀⠀⠀⢀⣼⠇⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⢠⣤⣤⣤⣤⣄⠀⠀⠀⠀⣿⡆⠀⠀⣼⡟⠀⠀⠀⠀⣀⣀⣀⠀⠀⠀⠀⢻⣧⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀ ⢸⣿⠀⠀⠀⠀⣿⡿⠋⠀⠀⠀⢀⣾⡿⠁⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⢸⣿⠉⠉⠉⣿⡇⠀⠀⠀⣿⡇⠀⣼⡟⠀⠀⠀⣰⡿⠟⠛⠻⢿⣆⠀⠀⠀⢻⣧⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀ ⢸⣿⠀⠀⠀⠀⠙⠁⠀⠀⢀⣼⡟⠁⠀⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⢸⣿⣶⣶⡶⠋⠀⠀⠀⠀⣿⠇⢰⣿⠀⠀⠀⢰⣿⠀⠀⠀⠀⠀⣿⡆⠀⠀⠀⣿⡆
⠀⠀⠀⠀⠀⠀⠀ ⢸⣿⠀⠀⠀⠀⠀⠀⠀⠀⠹⣷⡀⠀⠀⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣼⠟⠀⢸⣿⠀⠀⠀⢸⣿⠀⠀⠀⠀⠀⣿⡇⠀⠀⠀⣿⡇
⠀⠀⠀⠀⠀⠀⠀ ⢸⣿⠀⠀⠀⠀⠀⣠⡀⠀⠀⠹⣷⡄⠀⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⣤⣄⠀⠀⠀⠀⠹⣿⡅⠀⠀⠸⣿⠀⠀⠀⠸⣿⠀⠀⠀⠀⠀⣿⠇⠀⠀⠀⣿⠇
⠀⠀⠀⠀⠀⠀⠀ ⢸⣿⠀⠀⠀⠀⣾⡟⣷⡀⠀⠀⠘⣿⣆⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⣿⡟⣷⡀⠀⠀⠀⠘⣿⣆⠀⠀⢻⣧⠀⠀⠀⠹⣷⣦⣤⣤⣾⠏⠀⠀⠀⣼⡟
⠀⠀⠀⠀⠀⠀⠀ ⢸⣿⠀⠀⠀⠀⣿⡇⠹⣷⡀⠀⠀⠈⢻⡇⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⣿⡇⠹⣷⡀⠀⠀⠀⠈⢻⡇⠀⠀⢻⣧⠀⠀⠀⠀⠉⠉⠉⠀⠀⠀⠀⣼⡟
⠀⠀⠀⠀⠀⠀⠀ ⠸⣿⣄⡀⢀⣠⣿⠇⠀⠙⣷⡀⠀⢀⣼⠇⠀⠸⣿⣄⡀⢀⣠⣿⠇⠸⣿⣄⡀⢀⣠⣿⠇⠀⠙⣷⡀⠀⠀⢀⣼⠇⠀⠀⠀⠻⣷⣦⣄⡀⠀⠀⠀⢀⣠⣴⣾⠟
⠀⠀⠀⠀⠀⠀⠀ ⠀⠈⠻⠿⠿⠟⠁⠀⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠀⠀⠀⠈⠙⠻⠿⠿⠿⠿⠟⠋⠁


Jump into building with Kiro:

1. Ask a question or describe a task
2. Use /context add to provide Kiro with additional info
3. Connect to external tools with by using /mcp

Use /help for more information and happy coding!

Model: auto (/model to change) | Plan: KIRO FREE (/usage for more detail)


4% > Ask me anything! ### ここにプロンプトを渡す ###

最後に、「設計を明確にしてからAIに依頼することが大切」という観点でCursorのPlanモードについても記事を書いてます。
興味がありましたら、一緒に読んでいただけると嬉しいです。
CursorのPlanモードについての記事はこちら

最後の最後までお読みいただき、ありがとうございました。

一覧にもどる

関連記事

コード生成を安定させる3つのポイント：設計書・指示の出し方・セッション管理

はじめに ポイント1:設計書を書いてもらいましょう ポイント2:Geminiを使うときの指示の出し方 ポイント3:自分で修正したら「読み直して」と必ず伝える まとめ はじめに 生成AIを使ってコード生成や修正を行うことは、もはや特別なことではなくなってきました。 Gemini や CodeX、Copilot、Cursor など、選択肢も増え、「うまく使えばかなり楽になる」という実感を持っている方も多いと思います。 一方で、実際に使い込

記事詳細
コード生成を安定させる3つのポイント：設計書・指示の出し方・セッション管理
コラム 生成AI
非エンジニアでもできる！Microsoft Copilotを利用した業務改善入門

目次 はじめに プロジェクトの概要 ― 障害対応を生成AIで効率化する 全体の構想 - PowerAutomate × Copilot Studioによる自動化 実際に構築したフロー - Microsoft 365 Copilotでできること 振り返りと教訓 おわりに 1. はじめに 2026年現在、生成AIサービスは目的や専門性に合わせて非常に多くの選択肢がありますが、その中でも、Microsoft Copilotは

記事詳細
非エンジニアでもできる！Microsoft Copilotを利用した業務改善入門
生成AI
Cursorを使う前に知っておきたかったこと | Rulesやコードレビュー

目次 1. はじめに 2. Cursorの概要 3. 言語モデルの選択 4. 4つのモード 　4-1. Agentモード 　4-2. Askモード 　4-3. Planモード 　4-4. Debugモード 5. Rulesの設定 　5-1. プロジェクトルール 　5-2. ユーザールール 6. コードレビューでの活用 　6-1. レビュー用のプロジェクトルールを作成する 　6-2. レビュー対象の差分

記事詳細
Cursorを使う前に知っておきたかったこと | Rulesやコードレビュー
生成AI
Cursor Planモードのススメ：なぜ

想定読者 Cursorを使い始めたけれど「なんとなくAskしか使っていない」方 Copilotの延長のような感覚でAgentを使ってうまくいかなかった経験がある方 設計やレビューの工夫に関心がある方 目次 はじめに Cursorの4つのモードと使い分け Planモードでできること Planモードの実践的な使い方 よくある失敗パターン まとめ 1. はじめに Cursorでコーディングしているとき、こんなことに心当たり

記事詳細
Cursor Planモードのススメ：なぜ"いきなり書かせる"と事故るのか
生成AI

お問い合わせはこちらから

CONTACT US