この記事の要点
- AIハッカソンでChatGPTやClaudeを活用し、短時間でMVPらしいプロダクトを形にできました。
- 一方で、課題分析や発表の骨子が曖昧なまま進めた結果、発表では大きく失敗しました。
- AIは作業や整理を高速化してくれますが、「何を作るか・何を捨てるか・何を伝えるか」といった判断は人間が担う必要があります。
- 今回の最大の学びは、AIで作る速度が上がるほど、人間側の判断の重要性が増すということです。
今回の気づき
AIを使うことで、短時間でもMVPらしいものを作れることを体感しました。
一方で、発表では大きく失敗しました。
その原因は、課題分析の解像度が浅いまま開発と発表準備を進め、「何を一番伝えるべきか」が曖昧だったことです。
AIで速く作れるようになったからこそ、以下は人間が決める必要があります。
- 何を作るか
- 何を捨てるか
- 何を伝えるか
- そもそも誰のどんな課題を解くのか
この記事では、AIハッカソンでの失敗をもとに、AI時代の開発で人間が握るべき判断について整理します。
はじめに
先日、AIハッカソンに参加しました。
参加したハッカソンはこちらです。
https://hack-2026-spring.sugoiai.org/
今回のハッカソンでは、ChatGPT、Claude Design、Claude Code などを使いながら、短時間でMVPを作ることに挑戦しました。
作ったのは、AI初学者が業務の中でAI活用のきっかけを得るためのサービスです。
クエスト、XP、レベル、バッジのような要素を使い、日々の小さな業務改善をゲームのように積み上げていく、という方向性でした。
実際に作ったものはこちらです。
https://ai-quest-for-work.vercel.app/
開発面では、かなり手応えがありました。
AIを使うことで、短時間でも「プロダクトらしいもの」を形にできました。
以前ならもっと時間がかかっていたはずの画面作成や実装も、かなり速いサイクルで進められました。
一方で、発表では大きく失敗しました。
自分で発表の骨子を作れていないまま、Claude Design や ChatGPT にスライド構成や説明の整理を頼りすぎてしまい、本番では自分の言葉で話しづらくなりました。
結果として、短い発表時間を十分に活かせませんでした。
この経験から、AI時代の開発では「速く作れること」以上に、人間がどこで判断するかが重要だと感じました。
また、今回の経験を通じて、短時間で作って公開し、振り返りをして次に活かすサイクルを定期的に回していきたいとも思いました。AIによって試行コストが下がった今だからこそ、小さく作って学ぶ回数を増やすことが重要だと感じています。
今回の進め方
今回の開発では、大まかに以下のような役割分担をしました。
| ツール | 主な役割 |
|---|---|
| ChatGPT | 要件整理、壁打ち、レビュー |
| Claude Design | UI案、デザイン方針、画面イメージ作成 |
| Claude Code | 実装 |
| 人間 | 判断、取捨選択、最終確認、発表 |
この進め方自体はかなり有効でした。
ChatGPTで要件や方向性を整理し、Claude DesignでUIの方向性を作り、Claude Codeで実装を進める。
この流れによって、短時間でもMVPらしいものを作ることができました。
ただ、振り返ると、AIに任せる前に自分が決めておくべきことがいくつもありました。
特に今回の失敗は、技術的な仕様の曖昧さというより、人間側の判断の曖昧さ にありました。
失敗の根本：課題分析と発表骨子が曖昧だった
発表でうまく話せなかった直接の原因は、スライド構成をAIに頼りすぎたことです。
ただ、振り返ると、それだけが原因ではありませんでした。
そもそも自分の中で、課題分析の解像度が十分に高くありませんでした。
今回作ったサービスは、「AI初学者にAI活用を習慣化してもらう」という方向性でした。
この方向性自体は悪くなかったと思っています。
しかし、発表時点では以下を十分に言語化しきれていませんでした。
- AI初学者とは具体的に誰なのか
- なぜAIを使わないのか
- AIの知識が足りないのか
- 自分の業務のどこにAIを使えばいいかわからないのか
- 既存の研修やChatGPT単体ではなぜ足りないのか
- 何が1回楽になれば、次も使ってみようと思えるのか
ここが曖昧なままだと、「何を一番伝えるべきか」も曖昧になります。
結果として、AIにスライド構成を作らせても、見た目は整っているが、自分の言葉で語りづらい資料になってしまいました。
つまり今回の失敗は、単なる発表準備不足ではなく、課題分析・取捨選択・発表設計がつながっていなかったことにあると感じています。
学び1：AIは判断の曖昧さを、それっぽい成果物に変えてしまう
今回、一番大きく感じたのはこれです。
AIは、判断が曖昧な状態でも、それっぽい成果物を作れてしまう。
これはAIの強みでもあり、危うさでもあります。
AIに「こういうスライドを作って」「この内容を整理して」「このUIを作って」と依頼すると、かなり整ったものが返ってきます。
しかし、人間側で以下が曖昧なままだと、出来上がったものは「見た目は整っているが、自分では扱いづらいもの」になります。
- 何を一番伝えたいのか
- 誰に向けた発表なのか
- どの価値を短時間で伝えるのか
- 何を説明し、何を捨てるのか
- どの体験をMVPの中心にするのか
今回の発表では、まさにこれが起きました。
スライドや説明の材料はありました。
でも、自分の中で発表の骨子が固まっていませんでした。
その状態でAIに整理させたため、見た目や文章は整っているものの、自分の言葉で話しづらい構成になってしまいました。
これは、AIが悪いという話ではありません。
むしろ、AIは与えられた曖昧な材料から、もっともらしい形を作ってくれました。
問題は、その前段階で、自分が判断すべきことを判断できていなかったことです。
AI活用で重要なのは、作業を任せる前に以下を明確にしておくことです。
- 今回の一番の主張は何か
- 何を成果として見せるのか
- どの機能は説明しないのか
- 何を作らないのか
- どの課題を解いていると言い切るのか
学び2：「便利そう」ではなく「確かに必要だ」まで掘る
今回の案は、「AI初学者にAI活用を習慣化してもらう」という方向性でした。
繰り返しになりますが、方向性自体は悪くなかったと思っています。
ただ、振り返ると、もっと課題を深掘りできたはずでした。
「AI活用を習慣化するサービスです」だけだと、少し広いです。
それよりも、以下のように言えた方が、課題の解像度は高くなります。
自分の業務の中でAIを使う場所がわからない人に、最初の成功体験を渡すサービスです。
この言い方にすると、考えるべきことが変わります。
単にAIの使い方を教えるのではなく、業務の中でAIを使う入口をどう作るかが重要になります。
たとえば、以下のような問いです。
- どの業務でAIを使うのか
- その業務はどれくらい頻繁に発生するのか
- その人は今どうやって解決しているのか
- AIを使うと何分短縮できるのか
- 1回使ったあとに、次も使いたくなるのか
- 成功体験として十分に小さい単位になっているのか
「便利そう」ではなく、「確かに必要だ」と思ってもらうためには、機能の説明だけでは足りません。
必要なのは、以下を具体化することです。
- 誰が
- どの場面で
- 何に困っていて
- 既存のやり方ではなぜ足りず
- これを使うと何が変わるのか
AIは、この整理を手伝ってくれます。
でも、最終的に「この課題を解く」と決めるのは人間です。
学び3：何を伝えるかまでAIに委ねてはいけない
今回の一番わかりやすい失敗は、発表でした。
発表前、自分で「何を話すか」の骨子を作れていませんでした。
その状態で、Claude Design にスライドを作らせ、ChatGPT にレビューさせ、ほぼそのまま発表しようとしてしまいました。
結果として、発表資料はあるのに、自分の言葉で話しづらい状態になりました。
発表で必要なのは、きれいなスライドだけではありません。
むしろ短い発表時間では、以下を自分で言えることの方が重要です。
- 誰の課題を解くのか
- 何を作ったのか
- それによって何が変わるのか
- なぜ今それが必要なのか
- 一番伝えたいことは何か
AIはスライドの構成案を出せます。
文章も整えてくれます。
見た目の方向性も作れます。
ただし、発表の軸そのものは自分で決める必要があります。
AIに任せてよいのは、たとえば以下です。
- 言い回しを整える
- スライド構成の案を出す
- 抜け漏れを指摘してもらう
- 想定質問を出してもらう
- 冗長な部分を削ってもらう
一方で、人間が握るべきなのは以下です。
- 最初の一言
- 一番伝えたい主張
- どの順番で話すか
- 何を話さないか
- 自分が納得して話せるか
発表の骨子を自分で作らずにAIに任せると、発表資料は完成しても、自分の発表にはなりません。
次回からは、AIにスライドを作らせる前に、最低限これだけは自分で書こうと思います。
- 誰の課題か
- なぜその課題が重要か
- 作ったものは何か
- 使うと何が変わるか
- 一番伝えたいことは何か
これがない状態でAIに頼ると、「きれいだけど話せない資料」になりやすいです。
学び4：作る力だけでなく、捨てる力が必要
AIを使うと、作るコストがかなり下がります。
今回も、短時間で画面や機能を形にできました。
これは大きな手応えでした。
一方で、作るコストが下がると、別の問題が出てきます。
それは、作りすぎる ことです。
AIに頼めば、機能案はいくらでも出てきます。
画面も追加できます。
説明文も増やせます。
実装もある程度進められます。
ただ、ハッカソンやMVP開発では、機能が多いほど良いとは限りません。
むしろ、機能が増えるほど、何を検証したいのかがぼやけます。
今回のサービスでも、やろうと思えば以下のような機能を足す余地はありました。
- ログイン
- DB保存
- 通知
- ランキング
- チーム機能
- 管理画面
- 詳細な学習履歴
- 複雑なバッジ条件
しかし、今回本当に見せるべきだったのは、おそらくそこではありませんでした。
コアにすべきだったのは、次の体験です。
AI初学者が、自分の業務でAIを1回使えたと感じる体験
そのためには、機能を増やすよりも、以下を明確にする方が重要でした。
- どんな業務クエストを用意するのか
- 初学者が迷わず実行できるか
- 実行後に「少し楽になった」と感じられるか
- もう一度使いたくなるか
AI時代は、まず作ってみることの価値が上がります。
ただし、それと同じくらい、作ったものを削る力も重要になります。
発散と収束の流れとしては、以下のようなイメージです。
- 発散：AIを使ってまず形にする
- 収束：本当に必要なもの以外を捨てる
- 検証：コア体験が伝わるかを見る
AIで作る力が伸びるほど、人間には「捨てる力」が必要になると感じました。
また、今後は今回のような小さなプロダクトを短期間で作り、公開し、振り返りを行うサイクルを継続したいと思っています。AIによって実装速度が上がったからこそ、1回で完璧を目指すよりも、試して学ぶ回数を増やす方が価値が大きいと感じています。
今後は小さく作ってPDCAを回したい
今回のハッカソンを通じて、AIを使えば短時間でもプロダクトらしいものを作れることがわかりました。
これは大きな収穫でした。
一方で、今回のように課題分析や発表設計が曖昧なままだと、せっかく作ったものの価値を十分に伝えきれません。
だからこそ、今後は「作って終わり」ではなく、小さく作って、公開して、振り返って、次に活かすサイクルを意識的に回したいと思っています。
具体的には、毎週または隔週で2〜3時間ほど時間を取り、以下のような流れを試したいです。
- 小さな課題を1つ決める
- AIを使って短時間で形にする
- 実際に触ってみる、または人に見せる
- 何が伝わったか、何が伝わらなかったかを振り返る
- 残すもの、捨てるもの、次に試すことを決める
AIによって実装のコストが下がった今、1回で完璧なものを作るよりも、小さく試す回数を増やす方が重要だと感じています。
作る力だけでなく、課題を見つける力、捨てる力、伝える力も、このサイクルの中で鍛えていきたいです。
AIに任せること、人間が握ること
今回の経験をもとに、AIに任せやすいことと、人間が握るべきことを整理すると、以下のようになります。
| 領域 | AIに任せやすいこと | 人間が握るべきこと |
|---|---|---|
| 企画 | アイデア出し、観点出し、壁打ち | 誰のどの課題を解くか |
| 要件定義 | 論点整理、抜け漏れ確認 | 何をMVPの中心にするか |
| UI | 画面案、文言案、デザイン方針 | どの体験を一番見せるか |
| 実装 | 定型コード、コンポーネント作成、修正案 | 仕様の妥当性、レビュー地点 |
| 発表 | スライド案、表現改善、想定質問 | 何を一番伝えるか |
| MVP判断 | 機能案の列挙 | 何を作らないか |
AI活用で重要なのは、AIに仕事をさせることだけではありません。
むしろ、以下を設計することが重要です。
どこまでAIに任せて、どこで人間が判断するか。
今回の失敗は、その線引きが曖昧だったことにあります。
次回から使うチェックリスト
今回の反省を、次回以降のハッカソンやAI駆動開発で使えるチェックリストにしておきます。
課題分析
- 誰のどんな課題を解くのか、一言で言えるか
- AI初学者を具体的な人物像まで分解できているか
- その人がなぜAIを使わないのか説明できるか
- 「AIの使い方がわからない」のか、「業務のどこに使えばいいかわからない」のかを分けて考えたか
- 既存手段ではなぜ足りないのか説明できるか
何を作るか
- 「便利そう」ではなく「確かに必要」と言えるか
- MVPで検証したい体験は1つに絞れているか
- 最初の成功体験を具体的に言えるか
- その体験は短時間で伝わるか
- 画面や機能よりも、体験を中心に説明できるか
何を捨てるか
- 作らない機能を明示したか
- 作れるから作っている機能が混ざっていないか
- 機能追加によってコア体験がぼやけていないか
- 見せたい体験に直結しない説明を削ったか
- 発表で話さない内容を決めたか
AIに任せる範囲
- AIに任せる作業と、人間が判断する領域を分けたか
- AIに渡す前に、自分の判断を言語化したか
- AIの出力をそのまま採用していないか
- 修正指示の範囲を限定しているか
- 「見た目が整っている」ことと「自分が扱える」ことを分けて確認したか
何を伝えるか
- 発表の骨子を自分で書いたか
- 1分で価値を説明できるか
- 自分の言葉で話せるスライドになっているか
- スライドが主張を支えているか
- 一番伝えたいことを1つに絞ったか
おわりに
今回のハッカソンでは、AIを使うことで短時間にMVPを作れることを体感しました。
これは大きな収穫でした。
一方で、発表では大きく失敗しました。
その失敗から、AI時代の開発では「作る力」だけでは足りないと感じました。
課題分析が浅いままだと、何を作るべきかも、何を捨てるべきかも、何を伝えるべきかも曖昧になります。
その曖昧さを抱えたままAIに頼ると、見た目は整っているが、自分の言葉で扱いきれない成果物になってしまう。
AIで速く作れるようになった。
でも、何を作るか、何を捨てるか、何を伝えるかは自分で決める必要がある。
AIに作業を任せることはできます。
しかし、判断まで渡してはいけない。
次にハッカソンや短時間開発に取り組むときは、課題分析・取捨選択・発表設計を自分で握ったうえで、AIを実現手段として使いたいと思います。