Kiro のワークフローで"自動車運転相棒AI"アプリを作ってみた（第3部：言葉と声を与え、仕上げる）

こんにちは。クラウド事業統括本部の Yoshi です。普段は TAM（テクニカルアカウントマネージャー）として、お客様のAWS活用のご支援をしています。

Kiro の ワークフロー機能 で、車載データと会話する相棒AI「AI Co-Driver」を個人開発で作ってみた実践記の、ついに完結編です。第1部で全体像を描き、第2部で「いつ・何を言うべきか」を端末側で判定するところまで来ました。今回は、ここまで確定させた"事実"に 言葉と声を与えて、相棒AIとして仕上げます。

そして完結編の裏テーマは、「開発未経験の自分が、仕上げの工程でどこにつまずき、どう乗り切ったか」 です。手を動かす部分はワークフローに任せられても、やはり開発経験が無いと踏む落とし穴があります。ただ、そこを日々の業務の段取り感覚で乗り越えられたというところまでお届けします。

目次

• シリーズ構成
• M4〜M5：言葉と声を与える
• 開発未経験ゆえにつまずいた3つ
• 完成 — イメージ通りに動いた！
• 業務の教訓が効いた — 入口を固め、最終確認は実地で
• 三部作の回収 — 開発未経験でも端まで作れた
• 開発環境
• まとめ

シリーズ構成

• 機能紹介編: Kiro IDE のワークフロー機能を紹介 〜レシピとランタイムで"段取り"を任せる〜
• 第1部: 全体像を描いてから動く
• 第2部: データで裏取りし、エッジで判定する

M4〜M5：言葉と声を与える

第2部までで、端末側のトリガーエンジンが「水温が危険域に入った」「ブーストが立ち上がった」といった 事実（イベント） を確定するところまで作りました。残りは、その事実に言葉と声を与えて相棒AIとして完成させる、仕上げの2段です。

• M4：言い回しだけ LLM にオフロード。確定済みの事実を Gemini に渡し、相棒AIらしい一言に変えます。トーンは航空無線のような短く冷静な定型句にしました。接続・起動のような固定句はLLMを通さず定型文で出し、数値が活きるイベントだけGeminiに言い回しを生成させます。圏外やエラーのときは定型文に退避し、LLMが使えなくても相棒AIは黙らない（第2部からの原則・ADR-004）。
• M5：声を与えて E2E を閉じる。文字だった発話を音声（TTS）で鳴らし、端から端まで通します。あわせて、運転中に一瞥できる グランスUI（glance＝一瞥）を実装。音声を主役にして画面は補助、車両計器と重複する速度・回転数は出さず、水温・油温は3色の縦バー、ブーストは半円のアークで、周辺視でも状態が分かるようにしました。

# 相棒AIのセリフ（航空無線調・一例）
暖機完了     : "THERMALS NORMAL. COMBAT READY."
ブースト最大 : "MAX POWER. [boost] BAR. CLEARED HOT."
水温 危険   : "WARNING. COOLANT CRITICAL. BACK OFF."

M4・M5とも、計画→実装→レビューのワークフローで組み、レビューはいずれも APPROVED。…ところが、仕上げの工程でこそ、開発未経験の自分がつまずきました。

開発未経験ゆえにつまずいた3つ

ここが完結編の本音です。手を動かす部分はワークフローに任せられても、「ちゃんと動くか」の最後の詰めには、やはり開発経験が要る と痛感しました。実機で3つのつまずきに出会いました。いずれも共通して、ワークフロー内（PC上）では捕まらず、実機で初めて表面化した のが特徴です。

とくに①は、手法として示唆的でした。この権限漏れは PC上の単体テストでは絶対に捕まりません。テストはLLM呼び出しを偽物に差し替えて動かすので、本物の通信権限が無くても緑になるからです。実装エージェントもレビューエージェントも、ロジックに集中していてこの1行の宣言漏れを見落としました。実機のログに出た一文で、ようやく原因が分かりました。

SecurityException: Permission denied (missing INTERNET permission?)

もうひとつ、③のゲージ調整は 人とエージェントの役割分担が最も象徴的に出た場面 でした。「ちょうどいいサイズ」は実機を車載して目で見ないと決まりませんでした。「もう少し大きく」「まだ小さい」を私が実機を見て判断し、オーケストレーター（会話セッション）側に数値で指示して反映するという往復を繰り返しました。半径の倍率を少しずつ刻み、1画面のゲージを詰めるのに13回のやり直しがかかりました。人が「どう見えるべきか」を決め、エージェントが正確に反映する。この分担は、一番"感覚"が要るUIの詰めでもきれいに機能しました。

完成 — イメージ通りに動いた！

最後に残っていたのは、「ブーストが全開の領域に入ったとき、ゲージ内側の赤いリングが点灯して光る」演出の、実走行での目視確認でした。

実走行でブーストが全開の領域（約1.0bar）に達した瞬間、グラデーションがアークのほぼ全域まで満ち、内側の赤い半リングが点灯して光るのを確認できました。温度バーも実データで点灯し、相棒AIのメッセージも実走行で発話。設計・サイズ・演出が、すべて実機で成立 しました。

子どものころ憧れた演出が、自分の車の中で、実データに反応して声と光で返ってくる。アプリ開発ほぼ未経験の自分でも、到達できました。

業務の教訓が効いた — 入口を固め、最終確認は実地で

つまずきはしましたが、乗り切れたのは、日々の業務で染み付いた段取りの感覚があったからかもしれません。

• 出戻りを減らすために入口を固めた。権限漏れの教訓から「外部I/Oを足すときは権限をチェックリスト化」。変更の入口でチェック項目を決めておけば後段の手戻りが減る、という段取りです。
• 「レビューが通った」と「本番で動く」を混同しなかった。静的レビューAPPROVEDは論理の確証であって、ビルド成功ではない。この切り分けを握っていたから、実機で落ち着いて詰められた。
• 最終確認は必ず実地で行った。UIのサイズも演出の点灯も、実機・実走行でしか本当のことは分からない。「大丈夫そう」で止めなかった。

これも、日々の業務で普段やっていることとそのまま重なりました。設計レビューや机上の確認がいくら通っても、本番環境で確かめるまでは「動く」と言い切らない。変更の入口でチェックを固めて手戻りを減らし、最後は実地で検証する。開発経験が無くても、この段取りの感覚があればつまずきを拾って前に進める仕上げの工程で、それをいちばん実感しました。

三部作の回収 — 開発未経験でも端まで作れた

三部作を振り返ると、各編でやったことは、私が TAM として仕事で日々やっている段取りそのものでした。

• 第1部：全体像を描き、不確実性の高い順に並べ、一番読めないリスクを最初に潰した。
• 第2部：思い込みでなく実データで基準を決め、安全の軸は人（エッジ）で握った。
• 第3部：出戻りを減らすため入口を固め、最終確認は実地で行った。

アプリ開発そのものはほぼ未経験でした。Kotlin も Android も、ゼロからひとりで完成まで持っていったことはありません。それでも端まで作れたのは、「手を動かす部分」をワークフローに任せ、「段取りと判断」を自分が握る という分担が、この業務感覚とぴったり噛み合ったからです。

Kiro のワークフローの価値は、「コードを書いてくれること」そのもの以上に、人が段取りと判断に集中できる形に、作業を預けられること にあると感じました。開発未経験でも、業務で培った段取り感覚さえあれば、実機で動くアプリを端まで作れるこの三部作で伝えたかったのは、その手応えです。

開発環境

参考までに、三部作を通して使った開発環境の一覧です。特別なものは使っておらず、手元にあるもので組んでいます。

まとめ

• 確定済みの事実を LLM で自然な一言に変え（M4）、音声で鳴らしてグランスUIを灯し（M5）、相棒AIを E2E で完成 させた。
• 仕上げの工程で、開発未経験ゆえのつまずき（権限漏れ・型推論の循環・ゲージの暴発）に出会った。どれもワークフロー内では捕まらず、実機ビルド／実機テストが捕まえた。
• 「静的レビューAPPROVED ≠ ビルドが通る」。レビューは論理・設計の確証であって、実コンパイルの確証ではない。この切り分けを正直に握ることが、過大な期待を避ける鍵だった。
• UIの数値調整は、人が実機を見て決め、エージェントが反映する往復で詰めた。人×エージェントの分担が象徴的に出た場面。
• 三部作を貫いたのは、TAM / 運用で培った段取りの感覚。手を動かすのはワークフロー、段取りと判断と最終確認は人。開発未経験でも、この分担が噛み合えば実機アプリを端まで作れた。

3回にわたってお付き合いいただき、ありがとうございました。この記事が誰かのお役に立てれば幸いです。以上 Yoshi でした。

参考

• Kiro IDE のワークフロー機能を紹介 〜レシピとランタイムで"段取り"を任せる〜（DevelopersIO） - 本シリーズの土台となる機能紹介編
• 第1部：全体像を描いてから動く（DevelopersIO）
• 第2部：データで裏取りし、エッジで判定する（DevelopersIO）
• Kiro 公式サイト
• Kiro 公式ドキュメント
• 第1部：全体像を描いてから動く
• 第2部：データで裏取りし、エッジで判定する