Kiro のワークフローで"自動車運転相棒AI"アプリを作ってみた（第1部：全体像を描いてから動く）

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

今回から全3回で、Kiro IDE の ワークフロー機能 を使って、車載データと会話できる「相棒AI」アプリを個人開発で作ってみた記録を書きます。アプリ開発そのものはほぼ未経験の私が、普段の業務で染み付いた「段取りの感覚」とワークフローがどう噛み合ったかを主役にした実践記です。

目次

• シリーズ構成
• はじめに — なぜ"喋る相棒"を作りたくなったのか
• 作ったもの（AI Co-Driver）の全体像
• 開発を始める前に決めたこと — ワークフローと「段取り」
• 不確実性の高い順に並べる — マイルストーン設計
• 第1の山：車に繋いで実データが取れるか（M1）
• つまずき：Connected なのにデータが来ない
• 業務感覚への接続 — 「一番読めないリスクを先に潰す」
• 次回予告
• まとめ

シリーズ構成

本シリーズは、系統の違う2本立てで発信しています。まず ワークフロー機能そのものの紹介記事（別記事）を土台に置き、その機能を 個人開発で端まで試した実践記（この三部作）が続きます。

• 機能紹介編はこちら: Kiro IDE のワークフロー機能を紹介 〜レシピとランタイムで"段取り"を任せる〜
• 第2部: データで裏取りし、エッジで判定する
• 第3部: 言葉と声を与え、仕上げる

はじめに — なぜ"喋る相棒"を作りたくなったのか

子どものころ、車が主人公と一緒に走り、言葉を交わす作品を夢中で見ていた方は多いと思います。私にとってそれは、レースを走る車に搭載された相棒AIが実況し助言する作品（『新世紀GPXサイバーフォーミュラ』のアスラーダ）と、ナイトライダーの相棒AI「K.I.T.T.」でした。運転席で車と会話する、あの感じ。

大人になって、手元には OBD-II で車両データを拾えるアダプタと、センサーの塊であるスマートフォンと、クラウドのLLMがあります。「あのころ憧れた"喋る相棒"、いまなら自分でも作れるのでは？」これがこの個人開発の出発点です。

ただ、私はアプリ開発がほぼ未経験です。運用・インフラ寄り。Kotlin も Android も、ゼロからひとりで完成まで持っていった経験はありません。

そこで試したかったのが、Kiro の ワークフロー機能 です。計画・実装・レビューを決まった段取りで回してくれるなら、「作り方そのもの」を相棒に任せられるのではないか。本記事はその実験の第1部になります。

作ったもの（AI Co-Driver）の全体像

主役は手法ですが、題材が分からないと話が進まないので、作ったものを先に一言で紹介します。

AI Co-Driver は、走行中の車両データとスマホのセンサーを読み取り、状況に応じて音声で話しかけてくる相棒AIアプリです。構成要素はこんな組み合わせです。

ポイントは 「判定はエッジ、言い回しだけクラウド」 というハイブリッド構成にしたことです。危険の検知のようなリアルタイム性が命の部分を通信往復に頼ると、電波が悪い場所で止まってしまいます。だから"気づく"のは端末側で完結させ、LLM には"どう言うか"だけを任せました。この設計判断の理由は第2部で詳しく触れます。

ここからが本題です。この題材を、Kiro のワークフローでどう作っていったか。

開発を始める前に決めたこと — ワークフローと「段取り」

いきなりコードを書き始めたくなるところですが、やらなかったことがあります。それは 「いきなり作る」こと です。

開発経験はないですが日々の業務で実際にやっている動きです。

• まず全体像（どこからどこまでを、どの順で）を描く
• 一番読めない・一番こわいところ（ボトルネックやリスク）を先に特定する
• 出戻りが出ないよう、確かめる順番を決めてから手を動かす

Kiro のワークフローは、この進め方と相性が良さそうでした。ワークフローでは、作業の段取りを レシピ として定義しておくと、ランタイム がそのとおりに「計画 → 実装 → レビュー」を回してくれます。各ステップは本体の会話とは別の 独立セッション で動くので、実装ログで会話が埋まりません。レビューまで通ったら次へ、という収束ループもワークフロー側が面倒を見てくれます。

オーケストレーター（私との会話）
  └─ ワークフローを起動
       ├─ 計画エージェント（wf-planner）: このマイルストーンの実装計画を立てる
       ├─ 実装エージェント（wf-coder）: 計画どおりにコードを書く
       └─ レビューエージェント（semantic_reviewer）: 設計意図・ADR遵守をレビュー
            └─ APPROVED になるまで 実装⇄レビュー を繰り返す（収束ループ）

つまり私がやるのは、「何を・どの順で作るか」を決める入口と、最後に実機で確かめる仕上げです。実際に手を動かすコーディングとレビューは、ワークフローに任せます。この役割分担が、今回いちばん効きました。

不確実性の高い順に並べる — マイルストーン設計

全体像を描くとき、機能ではなく 「どこが一番読めないか」 で順番を決めました。この相棒AIで最も不確実なのは、見た目でも音声でもなく、「そもそも自分の車に繋いで、実データが取れるのか」 でした。ここが通らなければ、どんなに上物を作っても意味がありません。

そこでマイルストーンを、不確実性の高い順に並べました。

最初に作るのは M1「Walking Skeleton」。見た目も作り込みも後回しで、「車 → 端末 → 画面」まで細く1本だけ通す骨組みです。ここに今回いちばんのリスク（車とちゃんと通信できるか）を全部乗せて、最初に殺しにいきます。

この「M1に最大リスクを寄せる」という判断は私がしました。ワークフローに投げたのは、その先の 「M1を実装してレビューまで通す」 という作業です。何を最初に作るかという設計判断は人、作る作業はワークフロー、という分担です。

第1の山：車に繋いで実データが取れるか（M1）

M1 のゴールはシンプルです。

車に繋いで、水温と車速が毎秒2〜3回、画面に流れること。

これだけです。喋らないし、LLMも使わないし、UIも素っ気ない。ただ「実車の数字が、嘘なくリアルタイムで出る」ことだけを確かめました。

実装はワークフローに任せました。OBD-II の Bluetooth 接続、初期化コマンドの送信、水温と車速のPIDをポーリングして16進の応答を数値に変換し、画面に出す——という骨組みを計画・実装・レビューで一周させます。

そして実車に繋いでみました。ここで、最初のつまずきが待っていました。

つまずき：Connected なのにデータが来ない

アダプタとのBluetoothは「Connected」の表示。緑のランプ。手応えあり……と思いきや、画面の水温も車速も、ぜんぶ -- のまま。1つも数字が出てきません。

切り分け

• エンジンは始動済み。アダプタも接続先は確定している。Bluetooth層は正常。
• アダプタのランプが周期的に点滅していました。これは「ECUにリクエストは投げているが、正常な応答が得られていない」サイン。
• 疑うべきは物理層やBluetoothではなく、OBDのプロトコルのネゴシエーションだと当たりがつきました。

原因は、初期化で使っていた プロトコル自動判定（ATSP0） が、この車の通信方式を確定しきれていなかったことでした。自動に任せたのが裏目に出た形です。

対処は、自動判定をやめて プロトコルを明示指定 することにしました。

# 自動判定（ATSP0）に任せていた初版 → Connected なのに全項目 --
# ↓
# プロトコルを明示指定する方針に変更
ATSP6   # まずこの方式を明示（ダメなら別方式へフォールバック）
0100    # 接続直後にサポートPIDを問い合わせて確定を強制
ATDPN   # 実際に採用されたプロトコルを確認

この「自動に頼らず明示する」判断は、設計記録（ADR）として残しました。実機でこう直った、という裏取りまで含めて1件のADRにしてあります。

ADR-006: OBDプロトコルは自動（ATSP0）に頼らず明示指定する
　状況: 自動判定だと Connected でも全項目が取得できなかった
　決定: ATSP6 を明示し、ダメなら順にフォールバック。0100 で確定を強制
　教訓: 「Connected だがデータが来ない」はBluetoothでなく
　　　　 OBDプロトコルのネゴシエーションを疑う

明示指定に変えて、再接続。今度は数字が流れ始めました。

生の応答と画面の表示値が一致し、暖機で上がり冷却で下がる挙動も物理的に筋が通っています。M1 合格。この相棒AIが成立する一番の土台（実車とちゃんと会話できる）が、最初に確定しました。

合格したM1は、切り戻せるようにタグを打って保存しました。以降のマイルストーンは、この骨組みを壊さず改修で積み上げていきます。

業務感覚への接続 — 「一番読めないリスクを先に潰す」

第1部でやったことを、普段の業務の言葉に置き換えると、こうなります。

• 全体像を先に描いた。機能を思いつく順ではなく、「どこが一番読めないか」でマイルストーンを並べた。
• 一番こわいリスクを最初に殺しにいった。この相棒AIなら「車と通信できるか」。ここが死ねば全部死ぬので、M1に全部寄せた。
• つまずいたら、層で切り分けた。Connected なのにデータが来ない、を物理層・Bluetooth・プロトコルに分解して、プロトコルに原因を絞り込んだ。

これは、私が普段の業務でやっていることとほぼ同じでした。お客様の環境でも、全体像を描き、一番のボトルネック・一番読めない依存関係を先に潰し、問題が出たらレイヤーで切り分けていきます。順番を間違えなければ、出戻りは最小で済む。この段取りの感覚が、ワークフローの「計画 → 実装 → レビュー」の進め方とそのまま重なりました。

アプリ開発未経験でも、この「段取りを描く力」さえ持っていれば、手を動かす部分はワークフローに任せて前に進める第1部でまず、その手応えがありました。

次回予告

第2部では、**「データで裏取りし、エッジで判定する」**内容を紹介します。全PIDとGセンサーを揃え（M2）、走行中のデータをログに溜めて（M2.5）、机上で決めた閾値が実測とどれだけズレていたかをデータで突き合わせ、そのうえで「いつ喋るか」をエッジ（端末）で決定論的に判定するトリガーエンジン（M3）を作ります。「主観でなくデータで基準を決める」「安全の軸は人間で握る」という、これまた業務で染み付いた姿勢がそのまま効いた回です。

まとめ

• Kiro のワークフローで、車載データと会話する相棒AI「AI Co-Driver」を個人開発で作り始めた。主役は アプリ開発をワークフローでどう進めたか（手法）。
• いきなり作らず、不確実性の高い順にマイルストーンを並べた。一番読めない「車と通信できるか」をM1に寄せ、最初に潰しにいった。
• 設計判断（何を最初に作るか・プロトコルを明示する）は人、実装とレビューはワークフロー、という役割分担で進めた。
• M1は「Connected なのにデータが来ない」でつまずいたが、層で切り分けてプロトコルのネゴシエーションに原因を特定し、明示指定で解決。実車データ取得に成功した。
• この進め方は、TAM として普段やっている「全体像を描く・一番読めないリスクを先に潰す・層で切り分ける」とそのまま重なった。開発未経験でも、業務の段取り感覚とワークフローが噛み合えば前に進める。

この記事が誰かのお役に立てれば幸いです。以上 Yoshi でした。

参考

• Kiro IDE のワークフロー機能を紹介 〜レシピとランタイムで"段取り"を任せる〜（DevelopersIO） - 本シリーズの土台となる機能紹介編
• Kiro 公式サイト
• Kiro 公式ドキュメント
• 第2部：データで裏取りし、エッジで判定する
• 第3部：言葉と声を与え、仕上げる