【個人開発】AIエージェントへの「一言」がトークン代とデグレを救う？Kiroの実力検証

はじめに

個人開発でKiroを使い始めて早３週間程が経過しました。
既存システムの設計を読み込ませて実装させる場合、プロンプト次第でだいぶブレが発生する事は経験済みでした。
しかし、今回は個人開発という事もありあまりプロンプトを気にせず開発を進めていました。

ただ１つ気になる事があったんです。

もしデグレゼロを実現出来たら時短になるしトークンの消費も少ないハズ！

ということで実際に簡易的なプロンプト操作をしてみました。

素直にデグレゼロにしてとお願いする

設定ファイルを配置するシステムプロンプトではなく、あえて対話式のプロンプトで制御してみました。
実際のプロンプトは下記になります。

予約キャンセル機能 — 荷主が予約を取り消すことができる
この機能を実装してください。
・実装するに伴い他の画面に影響があるかどうかも確認
・影響があると判断した箇所は全て修正して
・デグレの発生はできる限り避けたい

シンプルでわかりやすく、複雑な指示は特にしていません。
誰でも今から試せる内容です。

結果

Kiro自身が デグレなし と教えてくれました。
これを試す前はKiroを過信していて実際にデグレが発生し何度か二度手間、三度手間をしました。

たかが個人開発にプロンプトなんて極めなくても、、、

それは浅はかな考えでした。
せっかくAIエージェント使ってるのにそんな無駄もったいない！
トークンも消費しますし、 塵も積もれば山となる！ 省ける無駄は省きたい。
これからは効率よく作業できる方法を探ろうと思いました。

全実装が完了しました。デグレなし、全テスト PASS です。
変更したファイルをまとめます。

バックエンド
005_add_cancelled_status.sql
 — bookings の CHECK 制約に cancelled 追加
booking.go
 — BookingStatusCancelled 定数追加
booking_service.go
 — ErrCannotCancel・ErrForbidden・Cancel() メソッド追加
interfaces.go
 — BookingServiceInterface に Cancel 追加
booking.go
 — Cancel ハンドラー追加（DELETE /api/v1/bookings/:id）
main.go
 — bookings.DELETE("/:id", ...) ルート追加
フロントエンド（影響箇所を全て修正）

BookingStatusBadge.vue — cancelled バッジ追加
BookingList.vue — accepted 予約にキャンセルボタン追加
ScheduleList.vue — cancelled 予約のステータス変更ボタン非表示・ラベル追加
Tracking.vue — ポーリング停止条件に cancelled 追加
QRScan.vue — cancelled スキャン時のエラーメッセージ追加
テスト

mock_services_test.go
 — MockBookingService に Cancel 追加
booking_handler_test.go
 — Cancel ハンドラーテスト6件追加
booking_service_test.go
 — Cancel サービステスト8件追加

各画面の確認

荷主の予約一覧に「キャンセル」ボタンがあることを確認！

バス会社のスケジュール一覧も予約済みのスケジュールは「削除」ボタンが非活性になっています。

実際にキャンセルをするとステータスのみ変化しました！
指示してないのに物理削除はされず、ステータスのみ変更される。これはお見事！

ちょっとだけ、ん？となったけど、これは許容範囲なのかな。
予約済みの荷物はないのにスケジュールが消せない！ただ、荷物がキャンセルされた形跡は残っている｡｡｡
実用的なのかここは検討が必要ですね。

QRコードをスキャンする事で荷物のステータスを更新できる機能があります。
そこも「キャンセル済み」とエラー出ていますね！ほんとに デグレなし 実現しました。

結果の凄さ

単に新機能を作るだけでなく、フロントエンドのバッジ表示からポーリングの停止条件、QRスキャン時のエラーハンドリングまで、「言わなくても影響範囲をすべて洗い出して修正した」点が驚きでした。

気づき

指示していない「論理削除（ステータス変更）」が採用されたのは、AIがシステムの整合性を優先した結果だと思います。ただ、そのせいで「キャンセル済み荷物があるスケジュールが削除できない」という副作用も生まれました。
ここは、「AIに仕様を丸投げするのではなく、人間が最終的なビジネスロジックを判断する余地」として面白いポイントです。

おわりに

下記URLから失敗例を確認する事ができます。
AIを過信しすぎると良くないとわかりつつも、少しプロンプトに工夫を加える事でデグレゼロになったので過信してしまうのも無理はありません。

ただし、今回は個人開発（ゼロからKiroと環境を構築した）という背景を考慮すると シンプルな指示（デグレなしで、影響範囲を確認して）が、実は最強のプロンプトだった というのが私の感想です。

既存システムがあり、その開発にAIを使う！
となると システムプロンプト がとても大事になってきます。
実際にClineとKiroに「サンプルソースコードを読み込んで同じ構成で設計書の内容を実装して」とだけ指示すると、、、

• Cline：サンプルコートとほぼ同じコピーを作成
• Kiro：jQueryしか使用していないのにReact.jsを採用

このようなことが実際に起きたので導入する際は慎重にですね。
特に 既存システム があるという事は 既存データが存在する！ ということ。
全てのデータに対して想定通りテストが通る事を確認しないと大変なことになりそう。。。
というのが私の感想です。

世の中とても便利になりましたが、まだまだ人間の工夫や知恵は必要みたいです。
その工夫や知識が大きく変わりつつあるのできちんとキャッチアップしていこうと思います！