こんにちは、エンジニアの岩間です。

先日、社内で「【Kiro・Playwright】社内でフルAI開発バトル！！「1行も書かずに」Todoアプリを完成させよ」なる企画を開催しました。

ルールはシンプルで、プログラミング禁止、AIへの指示だけでアプリを作るというものです。
お題はシンプルなTodoアプリですが、あえてふわっとした依頼にし、参加者それぞれがどう解釈しAIにどう指示を出すのかがポイントとなるゲームです。
企画には、Kiroを触ったことのない人、スペック駆動開発したことない人、AIを利用して開発をしたことがない人、また、非エンジニアのメンバーにも参加してもらったので、途中で詰まって終わる人が出るんじゃないかと最初は不安がありましたが結果、16人全員が完成させ、16通りのTodoアプリができあがりました。

この企画は今年のギークフィードアドベントカレンダーのテーマにもしています。
12/1にルール説明、12/2〜12/17で参加者が毎日ブログを投稿しているので、よろしければチェックしてみてください。

今回の記事では運営視点で振り返ってみます。

そもそも何をやったのか

アドベントカレンダー1日目の記事で企画の目的やルールを詳しくご紹介しています。

ルールと内容は以下の通りです。

当日参加メンバーに提示したお題は以下の画像の通りです。
お題はあえて曖昧にしました。「いい感じ」とは？という話ですが、それをどうAIを使って形にしていくのかがこの企画のポイントです。

リアル性を持たせるため、ゲーム開始1時間後には実務でもありがちな追加要件を提示しました。

参加者一覧と結果サマリー

参加してくださった皆さんの職種、時間、UI・機能とブログリンクをまとめてみました。

計16名が参加し、エンジニア経験や職種に関わらず、多くの参加者が2〜3時間台で完成させていました。

UIや機能に関しては本当に十人十色でした。

発見と気がつき

同じお題なのにUIが全然違う！

まず驚いたのが、見た目のバリエーションです。

企画前の予想では、多少の違いはあっても、だいたい似たようなリスト形式のアプリになるのではないかと思っていました。
実際大半のメンバーがリスト形式での実装ですが、
sakumaさんだけがカンバンボード（To Do / In Progress / Done）式を選択し、ドラッグ&ドロップでステータス管理できる形でした。
Notionでも似たような形式でタスク管理できますが、UXへのこだわりを感じる素晴らしい仕上がりでした

takeuchiさんの「すべてのタスク」と「今日のタスク」を横に並べて表示する2カラム形式も独自性がありました。
「今日やるべきこと」という要件を、UIのレイアウトで解決してきたtakeuchiさんは、エンジニアではなくなんとセールスアシスタントです。（すごい）

独自機能もさまざま

使いやすさを追求し様々な独自機能を実装してくれたメンバーもいます。

解釈が分かれたポイント

特に差が出たのは以下の3点です。

タスクの完了機能の有無

• 「完了機能がないと、戻す機能も作れない」と読み解き、完了ステータスを実装したチーム
• 初期要件を忠実に守り（あるいはAIが初期指示に固執し）、完了機能を実装しなかったチーム

「今日やるべきこと」とは何か

お題には「今日やるべきタスクに集中できる」とありますが、この定義も解釈が分かれました。
例えばsakuraiさんからはこんな鋭い質問をいただきました。

＞今日やるべきことだけを管理できる軽量なツールが欲しいんだよね。
こちらですが、今日やるべきことの定義はなんですか？
期限が今日のものですか？
期限がまだ来ていないものすべてですか？
今日のタスクというフラグがあるものですか？
その他ですか？
その他の場合は定義をもう少し詳しく教えてほしいです

結果、「必須」「できれば今日中」など優先度で分類する形で実装されていました。
また、takeuchiさんはデータ定義ではなくUIのアプローチで解決しました。「全タスク」と「今日のタスク」を左右2カラムに並べることで、今日やるべきことに集中する体験を実現しています。

「ログイン不要」だけど複数人で使う

お題には「ログイン機能は不要」とありましたが、「社員のために」という文言もあります。
「ログインさせないのに、どうやって複数人で使い分けるのか？」という矛盾に対し、アプローチは大きく3つに分類できました。

• 担当者フィールドで対応：多数派
• 最初にユーザー名を入力：sakuraiさん
• ブラウザ識別子＋名前登録で他人のタスクは編集不可：maimaiさん

maimaiさんはこの矛盾に気づき、運営に質問を重ねた上で高度な解決策を導き出していました。（さすが）

「ログイン機能は不要」というところが気になり、いくつか質問しました。複数の社員で使いたい、でもID/PWを管理したくない。ログイン以外の方法で、手間を取らせずにユーザーを識別できればより良いものができそう？と思いました。── maimai

「元に戻す機能」の解釈

追加要件として出した「間違って完了させたタスクを元に戻す機能」も、実装のアプローチが分かれました。

• チェックボックスのON/OFF
• 「未完了に戻す」ボタン
• ドラッグ&ドロップでステータス移動
• 時間制限付きUndo（10秒以内）
• 汎用Undo機能
• ステータスをドロップダウンで切り替え
• 完了機能自体実装なし

「間違ってタスク完了してしまった」という状況をどう捉えるかで、実装が変わっていました。

Damarさんの「10秒以内に戻すボタン」は特に印象的でした。Gmailの送信取り消し的な発想だと思います。
「間違って完了してしまった」という状況を、直後に気づくケースに限定して解決されていました。

一方で、汎用的なUndo機能を実装した人もいます。
Undoだと、だいぶ前に完了させたタスクを戻すのは難しいケースもあると思いますが、どっちが正解かは、実際の使い方によるところです。

同じ要件でも、「何を解決したいのか」の解釈で実装が変わってくると思います。

非エンジニアtakeuchiさんがアプリ開発

今回、個人的に一番嬉しかったのがこれです！

takeuchiさんはセールスアシスタントで、普段コードを書くことはありません。

運営からはKiroの基本的な操作方法だけをレクチャーし、「あとはAIと会話して自己解決してください！」と無茶振りに近いお願いをしたのですが、なんと 約4時間 でアプリを完成させていました。
しかも2カラム形式という独自UIで、モーダルやタスクを未完了に戻す機能まで実装していました。

AIとの対話だけで作れるので、非エンジニアな何もわかっていない私でもツールを作ることができました ── takeuchi

AWSへのデプロイはKiroに聞いてコンソールからぽちぽちされたそうです。素晴らしいです。

AIへの指示の出し方が人それぞれ

参加者のブログを読んでいて、AIとの向き合い方に大きく4つのパターンがあることに気づきました。

①とりあえず丸投げ

要件をそのままAIに渡して、出てきたものを見て調整していくスタイル

②事前に徹底整理

手元のメモに画面の想像図を書いてから、「必要な質問を整理して提示してください」とAIに依頼。運営にも何度か確認してから開発を始めるスタイル

③対話的に壁打ち

「曖昧な要件だと思うので私に判断を仰ぎたい部分は必ず私に質問してください」という一文をプロンプトに入れて、AIを議論相手として使うスタイル

④多段レビュー

AIに文書を作らせ、AIに自己レビューさせ、最後に人間がレビューという3段階プロセス。時間制限を設けて効率化を図る人もいました。

運営として気づいたこと

曖昧な要件は想像以上に解釈が分かれる

今回のお題はかなりふわっとしていましたが、想像以上に解釈が分かれました。

「サクサク動く」「今日やるべきタスク」「ログイン不要だけど複数人で使う」「元に戻す機能」など、同じ言葉でも人によって全然違う解釈になりました。

解釈が分かれること自体は良いとも悪いとも言えなくて、AIが思いもよらない良い提案をしてくれることもあれば、お客さんやPLの希望を人間側がちゃんと理解できていなくて変な方向に進むこともあります。

結局、AIが何を出力するかは、人間が何を入力するかで決まります。
曖昧な指示を出せば曖昧な解釈が、明確な指示を出せば明確な成果物が返ってきます。
今回の企画を通じて、AI時代に問われているのはAIの性能ではなく、指示を出す側である私たちの要件に対する解像度なのだと強く感じました。

AIに質問させるのは有効

「質問してください」と明示的に指示した参加者は、手戻りが少なかった印象です。
AIは言われたことをやろうとするので、曖昧なまま進むと後で大きな修正が入ります。

プロンプトの最後に『何か疑問があれば質問してください』と仕込む。焦らなければもう少しクオリティが高くなる方法に気付くことができました── sakuma

AI時代のエンジニアに必要な3つの力

企画当初、「ルール説明編」の記事で、この企画の目的として「AI時代のエンジニアに必要な3つの力」を定義していました。
実際に全員のアウトプットが出揃った今、それぞれの項目がどう発揮されたか振り返ります。

1. 隙間を埋める設計力

当初の定義は「曖昧な要件（行間）を読み取り、最適な仕様を仮説検証する力」でした。

今回のバトルでは、「完了機能の有無」が良いテストケースになったと思います。
間違って完了したタスクを元に戻す機能がほしい＝完了させる機能が必要という依存関係に気づけるかどうかがポイントだったと思います。
AI任せにせず、人間が仕様の整合性をチェックする場面だったのかなと思います。

2. AIマネジメント力

「AIをコーダーではなく部下として使い、指示・判断する力」です。

参加者のブログを見ると、プロンプトの工夫にはっきりと差が出ていました。

• 「曖昧な点は質問して」と指示し、対話を引き出したmatsuraさんやsakumaさん
• Sparring Partnerを設定し、AIに議論を求めたDamarさん

AIの提案を鵜呑みにせず、意図した成果物へ導くための指示出しのスキルは、今後もっと大事になりそうだなと感じました。

3. 品質への意識

「作って終わりではなく、テストまで完結させて品質を担保する力」です。

今回は全員がPlaywrightによるE2Eテストを実装しましたが、さらに踏み込んでプロパティベーステスト（PBT）を導入したochiaiさんやaraoさん、クロスブラウザテストを行ったSameeraさんなど、AIのコーディング力を借りて「人間が手で書くには面倒なテスト」を充実させていたのが印象的でした。

参加者の声（抜粋）

指示・プロンプトの出し方

適当なインプットは適当なアウトプットになる── sakuma

最初のプロンプトがふわっとしていると、要件定義や設計がそれなりに曖昧なまま出てきてしまい、何度か書き直しが必要になりました。── yamada

不明瞭な点が多いと補完できる範囲を超えてしまうことがあるので、初めの要件を如何に明確にできるかが重要だと思いました。── tokito

曖昧な要件だと思うので私に判断を仰ぎたい部分は必ず私に質問してください」という一文を加えることで、AIが勝手に判断して進むのではなく、適切なタイミングで確認を求めてくれるようになりました。これにより手戻りを大幅に削減できました。── matsura

プロンプトの最後に「何か疑問があれば質問してください」と仕込む steering に最低限の条件を用意して変な方向に進まないようにする など、焦らなければもう少しクオリティが高くなる方法に気付くことができたように思いました。── sakuma

今回のKiroへの指示はすべて英語で行いました。 英語の方が自分の考えをより正確に表現できるし、インターネットで見つけた「AIに単に同意させず、対話的に批判してもらうためのプロンプト（いわゆる”intellectual sparring partner”スタイル）」を参考にしました。── Damar

Kiroに要件を伝える際に、曖昧な部分を勝手に判断せずに質問するように指示を行うようにする。 まずは、要件や、壁打ち、運営への質問から、わかったことを議事録に残してもらうように指示を行う── sakurai

AIとの向き合い方・レビューの重要性

便利な反面何も考えなくてもある程度のものができてしまうので、生成AIが何をやっているのかをちゃんと理解しながらレビューする能力が重要だと感じた── haga

Kiroが修正しようとしていることを適宜理解して適切にフィードバックする能力が必要ですね。人間相手と同じだなあという印象。苦労することには変わらない。── maimai

一部のAI出力が冗長で、仕様として不要な説明が多く、取捨選択に時間がかかりました。── Damar

よくわからない技術要素でも実装できちゃう。これは新しい技術要素を取り入れるチャレンジできるという反面、操作している人間がよくわからないことが実装できちゃう怖さもありますね。── maimai

今回は認証などのセキュリティ面は考慮していない、既存システムとの連携、共存等、実際の現場で扱うにはどの程度有効なのか、はまだまだ検証したうえで扱っていく必要があるなと感じました。また既存の顧客に対して今回の要件定義書、設計書では納品物としては扱えない場合があるので、その点はどう対応していく必要があるのか検討が必要と感じました。── mukai

新鮮な体験・驚き

最初に想像していた通りのアプリが作れた── ochiai

このような経験は初めてだったためプロンプトを投げるだけでどんどん修正されていく様子は観ていて爽快でした── hirata

非エンジニアな何もわかっていない私でもツールを作ることができました── takeuchi

ほぼ苦痛なく作れたと感じましたのでMVPなどを作る時に活かせると考えています── ammar

これまで、AI を使ってアプリケーションを一から実装した経験はありませんでしたが、このプロジェクトを通じて、AI を活用してアプリをゼロから構築する実践的な経験を得ることができました。── sameera

効率化・工夫

AIが処理している間に仕様の確認等時間を有効につかえるようにすると効率的 ── hama

brainstorming.mdという議事録をAIに作成してもらった、後から「なぜこの設計にしたのか」を振り返ることができました。── sakurai

課題・苦労した点

AWSにデプロイして正常動作を確認できるまですごい時間がかかってしまった。同じような問題を繰り返している状態だったので、なんか根本的にやり方が間違っていたような気がします。自分でコード書けないのつらい。── maimai

フロントエンドのUIデザインについてはほとんどやり取りしていないけど、これでいいのか？見た目を変更したいときはどの段階でチェックして修正していくのがいいんだろうか？（実際顧客とやり取りすると、見た目のUIデザインに対する指摘って結構あると思うのですが…日本的すぎる？）── maimai

詳細を理解しないままだと、単にCreditを超消費するだけな気がする。Creditの有効活用ってどうやるのがいいのか？（お金は大事ですよね）── maimai

ツールへの感想

PlaywrightのMCPを利用したE2Eテストの自動生成は特に興味深かったです。テストを書く、書いたテストをメンテナンスし続けるという基本的ながら後回しになりがちな業務に、ようやく正面から向き合うことができそうです。── sakuma

Kiroのアイコンがピョコピョコ動くのかわいい。── arao

Kiroに対する慣れの問題と思いますが、tasks.mdのタスクごとにタブが大量にできるので、「あのやりとりのどのタブのどこだっけ、、、」ってなりました。── arao

普段使ってるClaude CodeにもSDDを行う仕組み(https://github.com/gotalab/cc-sdd)があることは知ってましたが、試していなかったので使ってみようと思います。── arao

 

まとめ

改めて今回の企画やってみて良かったなと思います。

分かったことは、AIは優秀な実行者だけど、要件を決めるのは人間の仕事だということ。
曖昧な指示を出せば曖昧な成果物が返ってくるし、詰めた指示を出せばそれなりのものができるということです。

また、「Todoアプリ」という一見シンプルなお題でも、解釈の余地はたくさんあることも分かりました。

次回やるなら、お題をもう少し複雑にしてみたいです。認証機能や複数ユーザー対応など、AIがどこまでやれるのか、もっと攻めてみたいと思います。

参加してくれた皆さん、日々の業務で忙しい中本当にありがとうございました！

The following two tabs change content below.

• この記事を書いた人
• 最近の記事

iwama

システム開発事業部所属/エンジニア/2023 Japan AWS Jr. Champions。 PHP/Laravel/FreePBX/AWSなどいろいろやってます。React勉強中。

iwama (全て見る)

• 社内でフルAI開発バトルやってみた結果、全員違うTodoアプリができた話 - 2025-12-18
• Amazon Q in Connectセルフサービスで多言語対応チャットボットを作ってみた - 2025-12-14
• 【Kiro・Playwright】社内でフルAI開発バトルを企画した話〜ルール説明編〜 - 2025-12-01
• ロングネイル女子エンジニア、筋トレとピラティスで最強になった話 - 2025-08-26
• 取引先から最短距離にいる担当者へメール通知する仕組みをSalesforce Apexで実現してみた〜後編〜 - 2025-05-28