グラレコ
📌 はじめに
AWS Summit Japan 2026 では、AWS が提唱する新しい開発手法 AI-DLC（AI 駆動開発ライフサイクル） をテーマにしたハッカソンが開催されました。お題は「人をダメにするサービスを考えよう！」という挑戦的なもので、117 チームが応募し、書類審査と予選会を経て決勝の 5 チームが選ばれます。
この記事は、そのハッカソンにチーム「ぐうたラボ」（イノベーションラボラトリの4名）として参加し、意思決定支援サービス YesMan を開発したレポートになります。残念ながら予選会で決勝には進めませんでしたが、AI-DLC という手法そのものと、AI が前提となった時代に「何で差がつくのか」を体感する濃い機会になりました。
この記事で学べること
- 🤖 AI-DLC（AI 駆動開発ライフサイクル）が従来の開発と何が違うのか
- 🏆 ハッカソンの選考（書類審査・予選会）が実際にどう運営され、何を評価されたのか
- 🛠️ 私たちが作った YesMan の設計（合議・委任度スコア・倫理ガード・アーキテクチャ）
- 📉 予選で勝ち残れなかった敗因の自己分析と、次に向けた具体的な打ち手
🤖 AI-DLC（AI 駆動開発ライフサイクル）とは
AI-DLC は、AWS が提唱する開発メソドロジーです。特徴を一言でいうと、AI を「開発の中心的な協働者」として位置づける 点にあります。AI に作業を丸投げするのでも、人間がすべてを書くのでもなく、両者がリアルタイムに協調しながら開発を進めます。
基本となるのは、次のサイクルを SDLC（ソフトウェア開発ライフサイクル）全体で繰り返すという考え方です。
- AI が計画を作成する
- AI が不明点の明確化を人間に求める
- 人間が承認する
- AI が実装する
つまり「AI が実行し、人間が監督する」という役割分担になります。この「人間の承認」が挟まることが、後で触れる審査基準にもそのまま効いてきます。
⏱️ 従来開発との違い
AI-DLC では、開発の単位そのものが従来より細かく・速くなります。
| 観点 | 従来の開発 | AI-DLC |
|---|---|---|
| 時間の単位 | スプリント（数週間） | ボルト（数時間〜数日） |
| 作業の単位 | エピック | Unit of Work（作業単位） |
| 成果物の生成 | 人間が中心 | AI が要件・設計・コード・テストを高速生成 |
| 人間の主な役割 | 実装そのもの | 意図の明確化と承認（監督） |
数週間かかっていた作業が数時間〜数日に縮むため、そのぶん「何を作るか」「なぜ作るか」を詰める力が、これまで以上に問われるようになります。
🔄 3 つのフェーズ
AI-DLC は大きく 3 つのフェーズで構成されます。次の図は、その流れを示したものです。
この図のポイントは、最初の Inception フェーズで「何を・なぜ作るか」をしっかり固めてから実装に入る、という順序です。各フェーズの中身は次のとおりです。
- 🔵 Inception（開始）: WHAT（何を）と WHY（なぜ）を決めます。要件分析、ユーザーストーリー、アプリケーション設計、作業単位への分解までを行います。
- 🟢 Construction（構築）: HOW（どう作るか）を決めて実装します。Unit of Work ごとに、機能設計・非機能要件・コード生成・ビルド＆テストをループで回します。
- 🟡 Operations（運用）: IaC とデプロイメント管理を担います（現時点ではプレースホルダー的な位置づけです）。
🧭 Adaptive Workflow
もう一つ大事な特徴が Adaptive Workflow です。全ステージを機械的に実行するのではなく、プロジェクトの規模・既存コードベースの有無・変更の複雑さに応じて、必要なステージだけを選んで実行します。小さな変更に大げさな手続きを強いない、という現実的な設計になっています。
🏆 ハッカソンの全体像
🎯 テーマと選考フロー
ハッカソンのテーマは「人をダメにするサービスを考えよう！」でした。生成 AI を活用して、いかに利用者を便利にし、努力を減らすかを競うというものです。一見ふざけたお題に見えますが、後で書くとおり、これが審査では深い議論を生みました。
選考は 3 段階です。次の図は、応募から決勝までの絞り込みを示しています。
この図から分かるとおり、117 チームから決勝に残るのは 5 チームだけです。書類審査で約 8 分の 1、予選会でさらに 3 分の 1 に絞られる、かなり狭き門でした。
📅 スケジュール
開催のスケジュールは次のとおりでした。
| 日程 | 内容 | 場所 |
|---|---|---|
| 4/15・18・25 | AI-DLC 勉強会 | オンライン |
| 4/28 | キックオフ説明会 | オンライン |
| 5/10 | 書類審査 締切 | — |
| 5/30 | 予選会 | 麻布台ヒルズ（オンライン配信あり） |
| 6/26 | 決勝 | 幕張メッセ（AWS Summit Japan 2026 会場） |
参加条件は、2〜4 名でのチーム編成（企業混成・非エンジニアの参加も推奨）、18 歳以上、AWS Builder ID の取得・登録、Summit 期間中の対面参加が可能であること、などでした。非エンジニアの参加が推奨されている点は、AI-DLC が「エンジニアだけのものではない」という思想を反映しています。
📝 書類審査の中身
書類審査は、想定を超える 117 チームが応募する盛況ぶりでした。提出物は GitHub の URL と、Inception フェーズの成果物です。
ここで印象的だったのが、審査員が「AI を評価に使わない」縛りで審査をした ことです。主催者の言葉を借りると「AI を使って我々が先にダメにならないように」。117 チームすべての成果物を人間の目で見て審査し、後から計測したところ 1 件あたり平均で約 30 分かけていたそうです。複数の審査員で評価したあと、評価点のブレを統計的手法で補正してから順位をつけたとのことでした。
🔍 審査の 4 観点
審査は次の 4 つの観点で行われました。
| 観点 | 何を見るか |
|---|---|
| 🎨 創造性とテーマ適合性 | テーマに沿っているか、独自性があるか、「なるほど」と思え、人に勧めたくなるか |
| 💼 ビジネス意図（Intent）の明確さ | 解決したい課題・ターゲット・競合との違い。とくに Biz 視点が入っているか |
| 🧩 Unit 分解の適切さ | ユーザーストーリーを並行実施可能な作業単位に分割できているか |
| 📄 ドキュメントの品質 | AI との議論・監督の積み重ねが成果物の質に表れているか |
とくに学びになったのが、後ろ 2 つの観点での「AI の提案を鵜呑みにしていないか」という視点です。AI-DLC のワークフローには audit.md という、過去の意思決定の履歴を残すファイルがあります。審査員はこのログを読み、参加チームが AI の提案にどう向き合ったかを見ていました。AI が出した Unit 分解にそのまま「承認します」と返しているだけだと、評価は低くなります。逆に、AI と議論を重ね、人間が判断して分割し直した形跡があると評価される、という設計です。
ドキュメント品質の観点では、Inception フェーズを 8 周も回して成果物を磨いたチームもいたそうです。「AI に一度作らせて終わり」ではなく、人間が何度も監督して質を上げることが、そのまま評価につながっていました。
「創造性とテーマ適合性」では、審査員の中でも議論が起きたと共有されていました。「これはダメになっているのかな」「ダメじゃなくてむしろ健康的になってる」「でもダメになった結果として健康的なら、それはアリなのか」——こうしたすり合わせは、まさに AI にはまだできない人間の仕事だと感じます。
🎤 予選会 — 当日の進行
予選会は 5 月 30 日（土）、麻布台ヒルズで開催され、様子はオンラインでも配信されました。書類審査を通過した 15 チームが、それぞれ 20 分の登壇 でプレゼンと MVP（動くプロダクト）を披露し、上位 5 チームが決勝に進みます。
当日のアジェンダは次のとおりでした。
この図のポイントは、各チームの持ち時間が 20 分と限られていることです。事前の作り込みが前提で、当日はプレゼンと MVP のデモで勝負します。短い時間でいかにインパクトを残せるかが、ここで効いてきます。
予選会では Amazon Bedrock や Amazon Q Developer といった技術が活用例として挙げられていました。
そして結果ですが、私たちのチームは決勝の 5 チームには残れませんでした。悔しい結果でしたが、ここからが本題です。何を作り、何が足りなかったのかを振り返ります。
🛠️ 作ったプロダクト「YesMan」
🪞 コンセプト
私たちが作ったのは YesMan という意思決定支援サービスです。キャッチコピーは「人間最後の仕事は、YES で承認すること。」。AI が日常から人生レベルまで「あなたが欲しい答え」を察して提案し、ユーザーは Yes / No をスワイプで選ぶだけ、というプロダクトです。テーマ「人をダメにする」に対する私たちの回答は、「心地よくダメになろう」でした。
解こうとした課題は、判断疲労（decision fatigue） です。発表では、次のようなデータを引用しました。
| データ | 出典（発表での引用） |
|---|---|
| 大人は 1 日に約 35,000 回の意思決定をしている | ケンブリッジ大学 Barbara Sahakian 教授の研究 |
| 36% の人が「日々の選択」をストレス源に挙げた | American Psychological Association, Stress in America |
| 1 日の行動の 45% が習慣（＝決めずに済ませる行動） | Wood & Neal, Duke University (2007) |
これらは私たちが発表で引用したデータです。出典名は実在しますが、「1 日 35,000 回」という数字は広く引用される一方で原典には諸説あります。また APA の 36% は「コロナ禍前と比べて日々の意思決定がよりストレスになったと答えた人の割合」という比較設問の値です。あくまで課題感を伝えるための参考値として捉えてください。
どうでもいい決断は AI に肩代わりさせ、本当に大事なことにエネルギーを残そう、というのが出発点です。
👆 操作モデル — 4 方向スワイプ
操作はシンプルで、カードを 4 方向にスワイプするだけです。
この図のポイントは、Yes だけでなく「別案」「深掘り」「中断」も指の動きひとつで選べることです。タップやキーボード（← → ↑ ↓）でも操作でき、WCAG 2.5.1（ポインタジェスチャの代替）にも配慮しています。
🎯 コアの 2 アプローチ
YesMan の中核は、「あなたを学ぶ × 信頼する人を呼ぶ」という 2 つのアプローチの掛け合わせです。
この図のポイントは、片方だけでは弱い、という点です。嗜好学習だけだと視野が狭くなりがちなので、「誰の目線の提案か」で納得感を補う合議を掛け合わせます。
- ① 嗜好パーソナライズ: Yes/No の履歴から嗜好プロファイルを作り、欲しい答えを予測します。アプリを開いた瞬間に「もしかして〜について？」と先回りで提案し、Yes/No のたびに裏で（EventBridge 経由で非同期に）学習します。プロファイルはいつでも閲覧・修正・全リセットでき、同じ意見ばかりにならないよう配慮しています。
- ② ペルソナ合議: プリセット（慎重派・楽観派・効率派）／知り合い（価値観を共有したペルソナ）／カスタム（親・尊敬する人・理想の自分などを自作）の 3 種類から最大 3 人を呼び、合議で提案を作ります。
⚙️ 主要機能
主な機能を整理すると次のようになります。
合議の流れはやや複雑なので、シーケンス図でも示します。次の図は、ユーザーが入力してから提案を受け取り、Yes を押すまでの流れです。
この図のポイントは、3 つの人格を 並列で 動かしつつ、その発言を待たせずにストリーミングで見せていることです。合議の過程が見えることで、「誰がどう考えたか」が透明になり、安心して任せられる体験を狙っています。
🤐 倫理・安全装置
YesMan は「意思決定の代行」という繊細な領域を扱うため、安全装置を重視しました。なかでも肝になるのが 沈黙演出 です。宗教・選挙・暴力・卑猥という 4 カテゴリに該当する入力には、AI は意図的に応答しません。これらは個人の信条や法的・倫理的に重大な判断であり、AI が代行すべきではないと考えたからです。
| 機能 | 内容 |
|---|---|
| 🗣️ 複数人格の合議 | 3 ペルソナを並列で LLM 呼び出し（asyncio.gather）し、各発言を SSE トークンストリーミングでリアルタイム配信。最後に集約して 1 つの提案にまとめます |
| 📊 委任度スコア | Yes 比率モデル（高いほど委任できている）＋円形チャート＋30 日推移グラフ＋AI 生成の可変コメント＋Yes 採択履歴（最大 20 件） |
| ⚡ No 連打プリフェッチ | 別案を裏で 2 件先取得し、No スワイプ時の待ち時間を体感ゼロに |
| 💬 Yes nudge（可変メッセージ） | 再考を促すマイクロコピーを固定文なしで毎回 LLM 生成し、回数に応じて段階的に変化 |
| 🎙️ 音声入力 | Web Speech API（ブラウザ内蔵）と Server STT（Transcribe）を切り替え可能 |
| 🎮 ゲーミフィケーション | Yes 連続採択のコンボ（🔥🌟⚡🏆）＋紙吹雪、YesMan マスコットの演出 |
| 📱 モバイルアプリ UX | Bottom Navigation・Safe Area・Skeleton ローダー・ページ遷移・触覚フィードバック |
この図のポイントは、判定が不能だったり例外が起きたりした場合に、安全側（沈黙）に倒す（fail-closed）設計になっていることです。さらに、沈黙ログは入力本文を保存せず、ハッシュ（SHA-256）だけを残します。
結婚・進学・離婚・就活・終活といった重大な決断についても、「最終的な判断はご自身で」と注意を促す設計にしました。
💰 ビジネスモデル
収益化は、全ユーザー基本無料で、広告とアフィリエイトで支える構想です。嗜好プロファイルで個人最適化されるため、「予測が当たった直後」という最も自然に行動へ移れる瞬間に、次の一歩（予約・購入）へつなげられる、という狙いです。
MAU 1,000 規模を前提にした 1 ユーザーあたり月次の試算は次のとおりでした。
| 項目 | 金額（月・1 ユーザー） |
|---|---|
| LLM（Claude Haiku 中心） | -¥76 |
| Fargate + Aurora | -¥24 |
| CloudFront + S3 | -¥12 |
| コスト合計 | -¥112 |
| 広告 ARPU | +¥80 |
| アフィリエイト ARPU | +¥240 |
| 粗利 / ユーザー | +¥208 |
なお、センシティブな 4 カテゴリには広告を出さない方針です。ここは収益よりも一貫性を優先しました。
🏗️ 技術スタックとアーキテクチャ
技術スタックは、フロントが TypeScript + React + Vite + Tailwind + PWA、バックエンドが Python 3.12 + FastAPI（DDD／ヘキサゴナルアーキテクチャ）です。LLM 呼び出しは LiteLLM Router を経由し、Amazon Bedrock と Bedrock Guardrails を使います。Strategy + DI パターンで、認証・DB・LLM・音声の実装を環境変数で差し替えられるようにしてあります。
アーキテクチャは 2 層で考えていました。次の図は、実際にデプロイした MVP の構成です。
この図のポイントは、Lambda Web Adapter を RESPONSE_STREAM で動かすことで、サーバーレスのまま合議のトークンストリーミング（SSE）を実現している点です。状態は DB を立てず、MockStore を S3 に pickle で永続化することで、起動を速く・構成をシンプルに保ちました。
📉 結果と敗因の自己分析
ここからは、予選で決勝に残れなかった理由を、できるだけ率直に振り返ります。誰かのミスではなく、自分たちのプロセスとして見つめ直す内容です。
⚖️ 大前提：もう「作れること」では差がつかない
今回いちばん肌で感じたのは、AI を前提にしたプレゼン資料・プロダクト開発が、もはや当たり前になっている ということです。「作れること」「それなりに動くこと」自体は、もう差別化になりません。あたり障りのないプレゼンやプロダクトでは勝てない。勝敗を分けるのは「尖り」と「伝え方」でした。
🔎 敗因（自己分析）
私たちの最大の要因は、コンセプト・課題設定の弱さ でした。とくに「課題が一般的すぎた」ことが響いたと感じています。「判断疲労」というテーマは、共感こそ広いのですが、その分だけ浅くなりがちです。「誰の、どれだけ切実な課題か」というところまで絞り込めておらず、刺さりが弱くなってしまいました。あわせてプレゼンの演出も弱く、限られた 20 分でインパクトを残しきれませんでした。
🥇 上位チームとの差 ＝「アイデアの尖り」
上位チームを見て最も差を感じたのは、「アイデアの尖り」でした。具体的に足りなかったのは、次の 3 点だと整理しています。
この図のポイントは、3 つのどれもが「広く浅く」ではなく「狭く深く」に向かっていることです。
🧭 次回への打ち手 — 「リアルな切実さ」から始める
では次にどうするか。私たちの結論は、一般論ではなく「リアルな切実さ」から始める、というものです。
- 自分や身近な人が本当に困った実体験を起点にして、狭く深い課題を選ぶ
- 「判断疲労」のような広く浅いテーマ化を避け、「この人の、この瞬間」まで具体化する
🎬 プレゼンで次回必ず取り入れること
プレゼンについても、次に取り入れたいことが明確になりました。
- 🗣️ 語りの設計 が最重要：課題 → 解決の物語、熱量、間の取り方で惹きつける
- 🎞️ コンセプト動画で世界観を冒頭から体感させる
- 📷 写真を含めたリアルで透明感のあるビジュアルで質感を出す
- 🔊 動きや音でインパクトを出す（従来のパワポ的な動きではなく）
プロダクト開発の側でも、「作れることは当たり前」を前提に、勝負どころは「尖ったコンセプト × 切実な課題の選定 × 明確な解決手法」を明確化できているか、そして UI/UX にどれだけこだわれるか、に移っていると感じます。
🚀 AIネイティブ時代のこれから
「作れること」がコモディティ化した時代に、人が差別化できる力は別のところにあります。今回の経験から、私が特に強化したいと思ったのは次の 2 つです。
🔬 課題発見・深掘り力
お客様が本当に必要としている課題と対策を、深く考える力です。今回の敗因（課題が一般的すぎた）の裏返しで、「誰の、どれだけ切実な課題か」を掘り当てる力が要ります。鍛え方としては、次の 2 つを考えています。
- 顧客接点を増やす — ユーザーインタビューや現場観察を習慣にして、一次情報に触れる
- 課題設定を他者にレビュー・反論してもらい、あえて「壊してもらう」場を持つ
🗣️ 言語化・プレゼン力
尖りや価値を、わかりやすく・惹きつけて伝える力です。物語と熱量で「伝わる」ところまで持っていきます。こちらの鍛え方は次の 2 つです。
- LT・登壇など、発表の場数を意識的に増やす
- コンセプトを記憶に残る一文で言い切る「一言化」の訓練をする
🎟️ ハッカソンには参加した方がいい
最後に、ハッカソン参加そのものの価値についても書いておきます。社内にいるだけでは出会えないものがたくさんありました。
- 💡 社内にはない考え方・アイデア・作り方を知れる（例：AI を使ってスケジュールを自動調整し、空き時間を作るアルゴリズム）
- 🛰️ エマージングテック領域のヒントも得られる（スマートグラスや AGI など）
- 🔥 優秀なエンジニアがたくさんいること自体が、純粋に刺激になる
✅ まとめ
この記事で一番伝えたかったのは、「作れること」はもうスタートラインで、勝負は『何を・誰のために作るか』と『どう伝えるか』に移っている、ということです。
AI-DLC は、AI に作らせて終わりにする手法ではありませんでした。AI の提案にどれだけ人間が向き合い、議論し、判断したか——その監督の質が、そのまま審査でも問われていました。これは日々の開発にもそのまま当てはまる教訓だと思います。
私たちは予選で敗退しましたが、「課題を狭く深く選ぶこと」と「熱量を持って伝えること」という、次につながる宿題を持ち帰れました。これからこの種のハッカソンに挑戦する方がいましたら、ぜひ「自分や身近な人が本当に困っていること」から始めてみてください。
最後に
決勝に進まれたチームの皆様がんばってください!!