「30分間でClaude Code × Vibe Coding」した軌跡①～大学時間割作成アプリ～

はじめに

アイデアは軽く、実装は重い――の時代は終わり、現代のAI支援開発はこの重さを部分的に肩代わりし、人は「何を成すか」に集中し、機械は「どう成すか」を駆動する構図を現実にしつつあります。

先日弊社オフィスで開催された「ProgateBar」にて、ゲリラ的に「Vibe Codeging」トライしてみました。
後の懇親会で、30分間の頭のプロセスを何名かから聞かれたので、「AIと会話した内容」を公開してみたいと思います。

作ったもの

大学の時間割自動生成アプリという具体的テーマを素材に、AIエージェントとの対話を「原文のまま」引用しながら、要件定義→設計→実装→デプロイ/デバッグまでのプロセスを振り返ります。

曖昧さと、スコープと、制約と、そしてエラーに。「ただ漠然とやる」ではなく具体に落とすこと、この辺りで何か感じ取れるものが見つかったら幸いです。

---

本記事の読み方

• 各フェーズで元のAIエージェントとのやりとり（原文） を引用します。
• 引用の後に、私の解説（なぜそうしたか/そうすべきか）と再定義（言葉の精度）、 チェックリスト（明日使える具体） を付します。
• 目的は、「AIと組むと開発が速い」で終わらせず、速さの裏側で崩れがちな品質・運用の礎をどう立て直すかを共有することにあります。

---

1. 要件定義フェーズ：曖昧さと期待に向き合う

元のやりとり（原文）

プロセス概要： ユーザーが大まかなアイデアを提示し、AIがそれを詳細な要件に落とし込みます。その後、ユーザーがPoC（概念実証）として開発スコープを絞り込みます。
【ステップ1：初期要件の提示とAIによる詳細化】
ユーザーからの指示・プロンプト:

以下の要件のウェブアプリを開発したいと思います。詳細な要件を提案して下さい。

✓ 大学の授業（講義）を
　自動で時間割りしてくれる。
✓ 必要単位と本人の空き時間
　から自動で組んでくれる。
✓ Googleカレンダーに自動反映。

AIエージェントの対応・成果物:
ユーザーの3つの要件を元に、本格的なWebアプリケーションの詳細な要件定義書を提案。
提案内容には、機能要件（ユーザー管理、授業データ管理、制約条件設定、Googleカレンダー連携等）、技術要件（React, Node.js等）、非機能要件（セキュリティ、パフォーマンス等）、画面構成案、4段階の開発フェーズ案が含まれていた。
【ステップ2：開発スコープの決定】
ユーザーからの指示・プロンプト:

PoCでPhase1だけやります

AIエージェントの対応・成果物:
ユーザーの指示を受け、開発範囲をMVP（Minimum Viable Product）である「基本的な時間割生成機能」に限定。
実装する機能を「必要単位数設定」「制約条件設定」「4つの生成モード」「複数パターン生成」などに絞り込んだ、PoC版の機能概要を作成した。

解説：言葉の暴れ馬を馴らす

ここでの肝は、「自動で」という言葉です。自動は万能感を帯びやすく、後工程の爆発点になります。「自動」の再定義が必要です。

• 入力の自動か、選好の自動か、最適化（探索）の自動か。
• どの制約クラス（時間帯、教室キャパ、単位、先修科目、重複禁止）が必須で、どれがソフト制約か。
• 解が存在しない場合の降格戦略（Relaxation）をどうするか。

PoCをPhase1に絞る決断は、 「欲しい全部」より「試したい芯」 を優先した点で妥当です。MVPの定義を「薄い完成」ではなく「学習の最短距離」 に置いたからです。

再定義

• 「自動」＝「制約充足問題（CSP）に対する近似探索。解が出ない可能性を仕様として持つ」。
• 「PoC」＝「価値仮説を検証するための機能・非機能の最小構成。継続しない覚悟も同梱する」。

チェックリスト（要件）

• 目的関数（例：空きコマ最小化/集中曜日最小化/午前優先）を明文化したか。
• ハード/ソフト制約を列挙→優先度付けしたか。
• 解なし時のUI（提示・回避提案・再探索）を定義したか。

---

2. 設計フェーズ：重さと軽さのトレードオフに向き合う

元のやりとり（原文）

プロセス概要： PoC開発をコーディングエージェントが実行できるよう、具体的な開発仕様書を作成します。ユーザーのフィードバックを受け、仕様をよりシンプルで軽量なものへと変更します。
【ステップ1：開発仕様書の初期作成依頼】
ユーザーからの指示・プロンプト:

コーディングエージェントに上記サービスの開発指示を出すための指示書ドキュメントを作成してください。

AIエージェントの対応・成果物:
DB設計やAPI仕様、アルゴリズムの実装方針などを含む、本格的な開発仕様書を作成した。
【ステップ2：仕様の軽量化】
ユーザーからの指示・プロンプト:

DB構築は不要な軽量な実装要件にへんこうしてください。
授業データはデモでお願いします。
Googleカレンダー連携はしません。

AIエージェントの対応・成果物:
仕様を大幅に簡略化。最終的な軽量版開発仕様書 (docs.md) を作成。主な仕様は以下の通り。

• DB不要: データはブラウザのLocalStorageで管理。
• サーバー不要: Next.jsの静的サイトとして実装。
• デモデータ: 50科目の授業データをコードに内蔵。
• 連携なし: Googleカレンダー連携はスコープ外。
• 技術スタック: Next.js, TypeScript, Zustand, Tailwind CSS, shadcn/ui。

解説：軽いことは善だが、軽薄では困る

「軽量化」はPoCで強力ですが、軽量=検証しやすいが、将来に持ち越す設計判断は増えるという事実に向き合う必要があります。LocalStorageは手軽ですが、ユーザー・マルチデバイス・共有は検証できません。ここで重要なのは、「今切り捨てた検証は何か」をログとして残すことです。捨てた理由を言語化しておけば、次フェーズの設計で回収できます。

再定義

• **「軽量」**＝「検証の単位が小さいという意味。将来の差し替え点（抽象化境界）を用意する」。

  • 例：データアクセス層をhookで抽象化し、LocalStorage→APIへの移行を差し替え可能に。

チェックリスト（設計）

• 永続化境界の抽象化（interface/facade）を切ってあるか。
• データモデルは実環境の拡張（教室/定員/先修）を想定した拡張余地があるか。
• 「捨てた検証項目リスト」をdocs.md末尾に付記したか。

---

3. 実装フェーズ：タスク分解と探索アルゴリズムに向き合う

元のやりとり（原文）

プロセス概要： 設計フェーズで作成された軽量版開発仕様書（docs.md）を元に、コーディングエージェント（Claude Code）がゼロからアプリケーションを自動で実装します。
ユーザーからの指示・プロンプト:

docs.mdの指示書に従って、実装を行ってください。

AIエージェントの対応・成果物:

• 指示の理解とタスク分解: TODOリストを生成。
• プロジェクトセットアップ: Next.js/TypeScript/Tailwind等の設定自動化。
• ディレクトリ構造: app, components, lib, types。
• デモデータ: types/index.ts に型、lib/data/demo-courses.ts にデータ。
• コアロジック: lib/services/generator.ts に時間割自動生成アルゴリズム。
• 状態管理: lib/stores/timetable-store.ts（Zustand+LocalStorage）。
• UI: shadcn/uiベースでグリッド/カード等を実装。
• 組み立て: app/page.tsx。
• 完了報告: TODO完了の要約を生成。

解説：CSP（制約充足問題）に素手で臨まない

時間割生成は典型的なCSPです。Backtracking + ヒューリスティクス（MRV: 最小残余値）、あるいは局所探索（Hill Climbing/Simulated Annealing）、ソフト制約のペナルティ最小化など、アルゴリズムの選択がUXに直結します。PoCでは貪欲 + 局所改善で十分かもしれませんが、失敗時の説明責務（なぜこの割当なのか/なぜ不可能なのか）を考えると、探索ログと衝突説明の仕組みを最初から埋めておくのが良いでしょう。

「つよつよエンジニア」の再定義

「つよつよエンジニア」とは、難しいアルゴリズムを語れる人ではなく、難しさの境界を見つけて、UI/仕様/探索戦略の分担で難しさを局所化する人だと考えます。足りないのは知識ではなく分解であることが多いからです。

チェックリスト（実装）

• 探索過程の ログ（選択/棄却） を取得できるか。
• 解なし時のRelaxation順序（どの制約を緩めるか）を持つか。
• 状態管理の永続化失敗時（LocalStorage枯渇/無効化）にフォールバックがあるか。

---

4. デプロイ＆デバッグ：現象→原因→対策（一次対応/恒久対応）に向き合う

元のやりとり（原文）

プロセス概要： 実装されたアプリケーションをVercelにデプロイ…（略）
【ステップ1：デプロイ方法の確認】
ユーザー:

この内容をvercelでデプロイする方法を教えてください。

AI:
Vercel CLIとGitHub連携の2通りの手順書、vercel.jsonなどの設定案を提示。

【ステップ2：ビルドエラー①（TypeScriptの型エラー）】
ユーザー（エラー報告）:

Type error: 'seed' is possibly 'undefined'.

AI:
seed が undefined になりうる型安全性の問題を特定し、初期値を設定する修正案を提示。

【ステップ3：ビルドエラー②（Vercelのデプロイエラー）】
ユーザー（エラー報告）:

Error: The file "/vercel/path0/out/routes-manifest.json" couldn't be found.

AI:
Next.jsの output: 'export' とVercel標準の不整合を特定。next.config.js と vercel.json を推奨設定に合わせる修正案を提示。

解説：一次対応は止血、恒久対応は再発ゼロの設計

seed の例は、 「例外が起きたから直す」ではなく「例外が起きない設計にする」 の好例です。ガード/初期値/型の絞り込みは「二度と」の第一歩です。

// 例：seedの安全な初期化
const normalizeSeed = (v: unknown, fallback = 42) =>
  Number.isFinite(Number(v)) ? Number(v) : fallback;

const seed = normalizeSeed(process.env.NEXT_PUBLIC_SEED);

Vercelの件は、プラットフォームの標準フローに合わせるのが最短です。静的エクスポートを前提にした設計からSSR/ISRへ舵を切るとき、ビルド成果物と実行時アーキテクチャの対応関係を（誰が見ても）一目で分かるように残すべきです。

恒久対応テンプレ（SRE Runbook 抜粋）

• 現象：どの指標が閾値を超えたか（ログ/ビルド/ヘルスチェック）。
• 直接原因：何が欠落/不整合だったか（例：output: 'export' とVercel標準の不整合）。
• 根本原因：なぜ検出できなかったか（CIに静的/動的デプロイの整合チェックがない等）。
• 恒久対策：CIに構成Lint（next.config.js/vercel.json 互換性チェック）を追加。
• 学び：「ガイドに従う」は技術的負債の返済でもある（独自化は保守コスト）。

---

付録：言葉の再定義と小さな作法

再定義

• 自動：解空間を探索し、満たせないときの説明責務を含む。
• 軽量：差し替え可能性の担保を条件にする。
• PoC：価値仮説検証の最短経路であり、将来の撤退も並走する。
• 完成：「デプロイできた」ではなく、観測・回復・説明が可能な状態。

作法

• 仕様に解なし時のUXを必ず入れる。
• 探索アルゴリズムはログと説明が出る実装にする。
• データ境界を抽象化し、LocalStorage→APIの差し替えを容易に。
• CIに構成Lint（Next/Vercel整合）と型の厳格化を入れる。
• 失敗はRunbookと恒久対策に昇華する。「次は」ではなく「二度と」。

---

ふりかえり：AIと人の役割分担

今回の流れは、AIが構造化・生成・一次解析を高い速度で担い、人が定義・優先順位・再設計を行った事例でした。スピードの獲得は同時に品質の崩落リスクでもあります。だからこそ、言葉を再定義する作法と、現象→原因→対策の型を、あらかじめチームの共通資産として持っておくべきだと考えます。
起きた問題に耐えることではなく、問題を言語化して、観測・回復・説明が可能な形に変えることに向き合っていきたいと思います。

いえらぶでは一緒に最速でサービス開発する仲間を募集しています

AIを活用しまくっているのは、つまるところ業界に対して1つでも多く・早くプロダクトを提供するのが目的です。共感してくれる方を広く募集しています。

カジュアル面談しましょう

DMいつでもお待ちしております。採用拘わらず、AIについてでもマネジメントについてでも、何でもお話ししたいです。

新卒採用サイト

大学生向けインターンシップ「いえらぶAIブートキャンプ」募集ページ