初めてのAI駆動開発。「コードは1行も書かない」縛りで勤怠管理アプリを1ヶ月で本番公開した全8ステップ

Posted at 2026-08-20

はじめに

タイトルの「コードは1行も書かない」は誇張ではなくて、自分でエディタを開いてコードを書いた回数は本当に0回です。手を動かしたのは、APIキーを .env.local に貼るのと、Supabaseの管理画面をポチポチしたくらい。それ以外は全部AIに書いてもらいました。

QAエンジニアを2年やったあと開発エンジニアに移って半年、という時期に、社内のAI学習サポート企画に参加しました。狙いは2つで、**「システム開発の工程を一通り通して、できるようになる」ことと、「AIを活用する力を身につける」**こと。その練習台として与えられた題材が勤怠管理アプリでした。約1ヶ月で、打刻から月次集計・CSVエクスポートまで動くものを本番公開できました。

大事なのは、目的は「勤怠アプリを作ること」ではないという点です。アプリは工程を一周するための題材でしかありません。なので、この記事も「勤怠アプリの作り方」ではなく「同じ流れをなぞれば別のアプリも作れる手順書」として書きます。

対象読者: これからAI駆動開発を始める人、AIでWebアプリを1本作りきってみたい人
使ったもの: GPT / Claude Code / Pencil / Codex（＋公開後の運用にナノクロー）
できたもの: https://kintaihub.vercel.app

なお、この記事は社内向けにやった成果報告スライド（全48枚）を、公開用に情報を整理して再構成したものです。スクリーンショット内の氏名・GitHubのアカウント名はダミーに差し替えています。

Claude Codeの運用まわりは過去にも書いていて、毎日3回「挨拶ハラスメント」して5時間の使用枠で作業を止まらなくする話や、毎朝7時に一足先に「出社」させて予定とSlackの宿題を1通で提出させる話もあります。今回は「Claude Codeで実際にプロダクトを1本作る」側の話です。

作ったもの: KintaiHub

題材と、その「架空の課題設定」

先に正直に書いておくと、題材の勤怠管理アプリは自分で選んだものではなく、企画側から与えられたものです。そして、そこに置いた課題も実在の顧客から聞いた話ではなく、「出退勤の管理をまだ紙のタイムカードやExcelでやっている会社があったら」という架空の設定として自分で組み立てました。

月末の集計が大変
リアルタイムの勤務状況がわからない
紙・Excelの転記でミスが出る

想定した課題	KintaiHub による解決
月末の手集計に時間がかかる	自動集計・CSVエクスポートで即時確認
リアルタイムの勤務状況がわからない	管理者画面でリアルタイム把握
紙・Excelの転記ミスが発生する	打刻データをそのまま集計、転記不要

課題が架空でも、そこから要件を立てて設計して、テストして本番に出すまでの工程は本物なので、練習台としてはこれで十分でした。むしろ「誰の何を解決するのか」を自分で言葉にするところからやったので、STEP1の絞り込みが自然と練習になりました。

MVPの機能は思いきり絞りました。

従業員: 始業・終業・休憩開始/終了をボタン1クリックで打刻、自分の月別履歴を確認
管理者（部長以上・経理部）: 全従業員の勤務状況をリアルタイム確認、月次集計、CSVエクスポート

実際の画面

ログイン画面

打刻ダッシュボード — ワンクリックで始業・終業・休憩を記録。ボタンは現在の勤務状態に応じて有効／無効が切り替わります。

勤怠履歴 — 月別に自分の打刻履歴を確認。実労働時間も自動算出。

管理者ダッシュボード — 全従業員の勤務状況をリアルタイム表示。Supabase Realtimeで、誰かが打刻すると管理者の画面が勝手に更新されます。

月次集計・CSVエクスポート — 出勤日数・総勤務時間・総休憩時間・実労働時間を自動集計し、CSVで落とせます。

デモは https://kintaihub.vercel.app で公開しています（テストアカウントは記事には載せていません。ログイン画面までは見られます）。

技術スタックと「AIの分担」

技術スタックは、AIに壁打ちして「初学者でも詰まりにくく、無料枠で本番公開まで行ける組み合わせ」で選びました。

カテゴリ	技術
フロント / ルーティング	Next.js（App Router）
言語	TypeScript
スタイリング	Tailwind CSS
DB・認証・Realtime	Supabase
デプロイ・ホスティング	Vercel
E2Eテスト	Playwright

そして、今回いちばん伝えたいのがこっちの表です。AIを1つだけ使うのではなく、得意分野で分担させました。

AI・ツール	担当
GPT	壁打ち・要件の洗い出し・設計・デザイン案の生成
Claude Code	実装の主体（コードを書くのは基本ここ）
Pencil	デザインファイル（`.pen`）の作成
Codex	生成画像からアイコン・画像を透過で切り出し
ナノクロー	公開後の修正運用（Issue → 実装 → PR → マージ）
GitHub Issues	修正依頼の見える化

「全部Claude Codeでやればいいのでは」と最初は思っていたんですが、画像生成とデザインの発想はGPT、コードはClaude Codeと分けたほうが圧倒的に速かったです。

なお、表の最後にあるナノクローはプラスアルファです。公開したあとの修正運用（STEP8）で試しに足したもので、ここはClaude Codeにそのままやらせても同じ流れが回ります。この記事の本筋は、その手前のSTEP1〜7です。

開発の全体像

流れはこうです。

構想 → 設計 → デザイン → 実装 → DB連携 → テスト → デプロイ → 修正運用 → 振り返り

一本道に見えますが、実際にやっていることは全ステップ共通で、

人は「意図」を決め、AIが「実装」する

これだけです。自分の仕事は「何を作りたいか」「これは合っているか」を決めることで、手を動かすのはAI。この役割分担が最後まで崩れませんでした。

前提: AI駆動開発の共通知識

STEP1に入る前に、全ステップで効いてくる基本を3つだけ。ここを押さえていないと、どのステップでも同じところで詰まります。

① Claude Code の進め方

Claude Code（ターミナルで動くAIエージェント）を使うときの基本です。

基本はプランモードで開始する（shift + tab）。いきなり実行させない
プランが出てきたら、「そのまま実行」か「修正して実行」を使い分ける。ちょっとでも違和感があれば必ず修正側を選ぶ（選択肢の番号はバージョンによって変わるので、番号ではなく中身で選ぶのが安全です）
コンテキストは80%を切る前に /clear か /compact。残量が減ってくると露骨に精度が落ちます
「考えさせる → 確認 → 実行」の型を徹底すると手戻りが減る

「考えさせる → 確認 → 実行」を守るだけで、出来上がりの質がかなり変わりました。プランを読まずに実行させた回は、だいたい後で作り直しになっています。

② プロンプトの型

プロンプトは毎回この4点セットで書いていました。

［役割］    あなたはプロのウェブアプリケーションデザイナーです
［指示］    このアプリのデザインコンセプトを作ってください
［指示の詳細］ テーマ・カラー・フォント・アイコンなどを細かく決めて
［なぜ］    このテーマをもとに各デザインを決めるため

実際に投げたのはこれです。

あなたはプロのウェブアプリケーションデザイナーです。このアプリのデザインコンセプトを
作ってください。デザインのテーマやカラー、フォントアイコンなど、このウェブアプリケー
ションを作る上でのデザイン要素を細かく決めて欲しいです。今回作ったデザインテーマを
もとに各デザインを決めるためです。

特に効くのが最後の**［なぜ］**です。「この出力を次に何に使うのか」を書いておくと、次のステップで使いやすい粒度で返ってきます。逆にここを書かないと、きれいだけど使えないポエムが返ってくることがありました。

③ ターミナルの小技

地味ですが、1ヶ月毎日触るとここの差が効いてきます。

操作	効果
`ctrl + a` / `ctrl + e`	カーソルを行の先頭／末尾へ一瞬で移動
`ctrl + w`	直前の単語を削除（打ち間違いの修正に）
先頭に `!`	Claude Code起動中でもコマンドを実行できる（例: `! git push origin main`）
`cmd + shift + v`（Clipy）	クリップボード履歴。画像もそのままClaudeに貼れる
iTermを `cmd + d` で分割	AIの待ち時間に別ペインで作業を進める
`/statusline` `/resume` `/clear` `/compact`	状況表示・再開・履歴整理を使い分ける

! は本当によく使いました。Claudeに聞きながら、その場で ! git status を打てるので、ターミナルを行き来しなくて済みます。

ここからが本編の全8ステップです。

STEP1 構想 — 「何を作らないか」を決める

GPTで壁打ちして画面を洗い出す

まずGPTに要望をぶつけて、必要な画面と機能を洗い出します。

このmvpを作るための画面名と画面数を洗い出してください

出てきたのはこんな感じでした。

ログイン画面 / 勤怠時間一覧画面 / 勤怠詳細画面 / 月次勤怠提出画面
従業員勤怠一覧画面 / 従業員勤怠詳細画面 / 申請承認一覧画面 / 月次勤怠集計画面

8画面。多いです。ここから**「MVPとして最初に作る必要最低限」に絞り込んでください**ともう一度投げて、5画面まで削りました。

このステップ、AI駆動開発で一番サボりたくなるところなんですが、ここで削らなかった機能は最後まで自分の首を絞めます。あとで出てくる「GPTが勝手に機能を足してくる問題」も、元の画面一覧が固まっていれば気づけます。

Claude Code で土台を作る

画面が決まったら、Claude Codeに移ります。

作業フォルダに移動して、プランモードで開始（shift + tab）
READMEを作ってもらう — 「以下のアプリを作るので README を作ってください」と、洗い出した要望をそのまま渡す
/init で CLAUDE.md を生成（日本語で作ってもらう） — プロジェクトのルールをAIに共有するファイル
1プロジェクトに集約する — ドキュメント（設計書）、Pencil（デザイン）、テスト、アプリのコードを全部同じリポジトリに置く

4番目が地味に効きました。設計書もデザインもテストも同じ場所にあるので、実装のときに「この設計書とこのデザインを見て作って」とパスで指定するだけで済みます。

STEP2 設計書づくり — レビューもAIにやらせる

設計書は、役割を与える → フォーマットを作る → 画面ごとに分割する → 別のClaudeにレビューさせるの順で作りました。

あなたはシニアWebエンジニアです。このMVPの設計書を Markdown で作成します。
必要なフォーマットを大項目・中項目つきで作成してください。

フォーマットが固まったら、

各画面ごとに、詳細設計書の md ファイルに分割してください

最終的にこういう構成になりました。

docs/
├── spec/
│   ├── overview.md        # 全体概要
│   ├── requirements.md    # 要件
│   ├── database.md        # DB設計
│   ├── api.md             # API設計
│   ├── auth.md            # 認証・権限
│   ├── components.md      # 共通コンポーネント
│   ├── screens.md         # 画面一覧
│   └── screens/
│       ├── 01-login.md
│       ├── 02-dashboard.md
│       ├── 03-history.md
│       ├── 04-admin.md
│       ├── 05-admin-report.md
│       └── 06-correction-modal.md
├── design/                # デザイン（後述）
└── test/                  # テスト設計（後述）

書き上げたら、別のClaudeセッションにレビューさせます。同じセッションで「レビューして」と言うと自分が書いたものを褒めがちなので、まっさらなセッションに設計書だけ渡すのがコツです。

やってみて分かったのは、実務でやるなら1画面ずつ作って、都度ルールを足していくほうが手戻りが少ないということ。5画面まとめて設計書を作ると、1画面目で見つかった抜けが残り4画面にも同じように残っていて、直すのが5倍面倒でした。

STEP3 デザイン — ここが一番長い（全9手順）

正直、ここが今回いちばん時間を使ったところです。でもここを固めておくと実装が一気に楽になります。

① デザインワードを捻出する（GPT）

まず、モデルにしたい既存アプリのスクリーンショットをGPTに添付して、こう聞きます。

この添付画像のデザイン要素を、あらゆる観点から1ワードで書き出してください

「クリーン」「余白」「カード型」「信頼感」みたいなワードがズラズラ出てくるので、そのなかから自分のイメージに合うものだけをコピーして次に進みます。

いきなり「かっこいいデザインにして」と言っても何も出てこないんですが、この「1ワードに分解する」を挟むと、以降の指示が急に通るようになります。自分でも驚きました。

② Pinterestで参考画像を集める

「ウェブアプリ + 選んだワード」で検索する
イメージに近い画像を4枚コピー（画面下部の関連画像も意外と当たりが多い）
GPTに貼り付ける

③ コンセプトを詳細化する（GPT）

集めた参考画像を渡して、コンセプトをテキストで具体化してもらいます。

この添付画像を参照して、デザインのコンセプトを詳細に設計してください

返ってきたものを要約するとこうなりました。

方向性: 信頼感のある業務ツール × 軽やかなクラウド感 × わかりやすい見える化
コンセプト名: Clear Work Flow（見える、整う、進む。）
配色: ホワイト基調 + ブルー(#1E88D8) + ライトブルー + ネイビー
状態色: 出勤=青 / 退勤=グレー / 休憩=オレンジ / 未打刻=赤 / 承認=緑
レイアウト: 余白広めのカード型
フォント: Noto Sans JP
モチーフ: 「流れ」（流線・円・矢印・クラウド）

ここで画像ではなくテキストにしてもらうのがポイントです。テキストなら、このあと CLAUDE.md に貼れます。

④ デザインテーマを画像で出力する（GPT）

固まったコンセプトとREADMEを渡して、テーマ・フォント・アイコン・画面イメージを画像で出してもらいます。

上記のデザインテーマで下記ウェブアプリを作りたいので、デザインテーマ・コンセプト・
フォント・アイコン・画面イメージを画像で出力してください
［READMEを丸ごと添付］

⑤ 各画面の画像を生成する

画面一覧＋詳細設計書を渡して、1画面ずつ生成します。GPTの分岐機能を使って並行で走らせ、最後に1つに集約しました。

生成したのはこの5画面です。

ログイン
打刻ダッシュボード
勤怠履歴
管理者ダッシュボード
月次集計

⑥ アイコン・画像を透過で切り出す（Codex）

生成した画面画像のなかから、ロゴやヒーローのモックアップをCodexにスクショから切り出してもらい、背景を透過にします。

切り出した画像は asetts/ フォルダにまとめて置きました。こうしておくと、次のPencilがこれらの画像を参照して各画面に配置してくれます。

⑦ `design/CLAUDE.md` にデザインシステムを集約する

ここまで決めたことを、docs/design/CLAUDE.md に全部書き出します。

# KintaiHub デザインシステム仕様

## デザインコンセプト：Clear Work Flow（見える、整う、進む。）
## カラー：primary-500 #1E88D8（メイン）／status: working / on_break / ...
## タイポグラフィ：Noto Sans JP（400 / 500 / 700）
## コンポーネント：ボタン・カード・バッジ・テーブル の規約

これがあると、実装フェーズでClaude Codeが勝手に色やフォントを変えなくなります。「デザインの正」を1ファイルに置くのが効きました。

⑧ Pencilで扱う対象を決める

Pencil は、.pen というファイルにデザインを保存して、MCP経由でAIエージェントが読み書きできるデザインツールです。デザインファイルがリポジトリの中に置けるのが特徴です。

Pencilに任せる範囲を先に決めて、これも CLAUDE.md に書いておきます。

ペンシルファイルで扱うものは、デザインテーマ（テーマカラー・フォント・アイコン・画像）、
各画面のデザイン、画面間の遷移状態です。
これらを design ディレクトリの CLAUDE.md に追記してください

ここを揃えておくと、Pencil化するときに大きく崩れにくいです。

⑨ Pencilで各画面を再現する

④で作ったデザインテーマ画像を「ゴール」として渡して、テーマと各画面・遷移をPencil上に作ります。

このデザインテーマの「デザインテーマ」「タイポグラフィ」「アイコンセット」「画面イメージ想定」を
kintaihub.pen ペンシルファイル上に作ってください

ハマったところ: Pencil（MCP）の 32000 エラー

デザインフェーズで一番詰まったのがこれです。

症状
デスクトップ版のPencilではMCP接続がOKだったのに、VSCode拡張版に切り替えたら 32000 エラーで繋がらなくなりました。

原因
~/.claude.json と ~/.claude/.mcp.json が別々の設定を持っていて、CLIが古いほうの設定を参照し続けていました。デスクトップ版のときの設定が残っていた形です。

解決
2つの設定ファイルを、いま使っている版の内容で揃えたら接続できました。

エラーが出たときのチェックリスト

~/.claude.json の内容を確認する
~/.claude/.mcp.json の内容を確認する
2つのファイルで設定が食い違っていないか比較する

学びとしては、エラーメッセージを読むより先に「いまどの設定ファイルを参照しているか」を確認したほうが早い、でした。接続経路を切り替えたときは両方のファイルを揃える。これは他のMCPサーバーでも同じことが起きそうだなと思っています。

STEP4 実装 — 設計書とデザインを「パスで」渡す

① 画面を実装する

Claude Codeに、設計書のパスとPencilのNodeIDと完成イメージ画像をまとめて渡します。

以下の設計書とデザインを参考に、○○画面を作成してください
［設計書のパス］　［PencilのNodeID］　［完成イメージ画像］

STEP1で「1プロジェクトに集約」しておいたのが、ここで効いてきます。全部同じリポジトリの中にあるので、パスを書くだけで済みます。

なお、認証が邪魔で画面の確認まで進めないときは、一時的に認証をコメントアウトしてURL直打ちで各画面を見ていました。もちろん最後は戻します。

② ローカルで動く状態にする

実装できたら、まず手元のブラウザで見られる状態にします。

ローカルで確認できる状態にしてください
［src のパス］

npm run dev
# → http://localhost:3000 を開いて確認

③ デザインのズレをなくす

ここが実装フェーズで一番回した工程です。

Pencilを修正 → 実装に反映 → 完成イメージとの差分をゼロに近づける
ズレが起きた原因は CLAUDE.md にルール化して再発を防ぐ
ルールが増えて CLAUDE.md が肥大化したら、階層に分割する

コツは、「ここがズレているので、コードのこの箇所を直して」と1つずつ指示することです。「全体的にデザインがズレてるので直して」と言うと、直っていたところまで壊れます（何度かやりました）。

STEP5 外部サービス連携 — 「連携して」の型

Supabase・Vercel・Playwright・ナノクロー、どれも基本は同じ型で進みました。

Claudeに「〜〜と連携して」と指示するだけ
APIキーなど、Claudeが設定できないものは人間が手動でやる（Claudeが手順を出してくれるので、それに従うだけ）
最後に「連携手順のHTMLを作成して」と同じセッションで頼む

3番目がおすすめです。連携をやりきった直後の、まだ文脈が残っているセッションで頼むと、人間が読み返せる振り返り資料が出てきます。今回は docs/supabase-setup.html、docs/vercel-setup.html、docs/playwright-setup.html が生まれました。半年後の自分と、同じことをやる後輩のために置いてあります。

つまり 「連携して」→（必要なら手動）→「手順をHTML化して」 が基本の型です。

Supabaseの場合

Supabaseでプロジェクトを作成（開発用／本番用を分けて用意）
APIキー・URLを取得して .env.local に設定（ここは人間が手動。秘密鍵はコミットしない）
MCP / CLI で操作。認証とRLS（Row Level Security、行単位のアクセス制御）でデータを保護

NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

RLSは「従業員は自分の打刻しか見られない、管理者は全員分を見られる」をDB側で担保する仕組みです。フロントで if (role === 'admin') と書くだけだと、APIを直接叩かれたら終わりなので、ここはAIに任せきりにせず設計書（docs/spec/auth.md）に書いてから実装させました。

STEP6 テスト — QA出身なので、ここは譲れなかった

① Playwrightで自動化する

Playwrightを導入（今回はお試しなのでChromeのみ）
CIワークフローで、PRを出したら自動テストが走るようにする
devサーバーを起動して、テストの実行過程を画面で確認する

実行過程を目で見られるようにしておくと、「テストは通ったけど本当に意図した操作をしているのか」が確認できます。本番案件なら Chrome / Safari など複数ブラウザでやるべきところですが、今回は範囲を絞りました。

② エラーパターンのエビデンスを自動で残す

認証失敗や通信エラーなどの異常系を、動画＋スクリーンショットで自動取得するようにしました。

QAをやっていたときは、こういうエビデンスを手動でスクショして貼り付けていました。それが自動で残るのは、正直かなり感動しました。

③ テストケース作成の型

テストケースも、設計書と同じで「役割を与えてルールをファイル化する」でいけます。

あなたはシニアQAエンジニアです。製品版レベルの品質で一般公開するため、
あらゆる観点からテストケースを作成するルールを test/CLAUDE.md に作ってください

観点を test/CLAUDE.md に定義してしまえば、あとは画面遷移図（PFD）を全網羅する形でケースを起こして、実行はAIに任せられます。

STEP7 デプロイ（Vercel）

ここは拍子抜けするほど簡単でした。

GitHub連携で自動デプロイ（main = 本番 / PR = プレビュー）
Supabase・Vercelは会社アカウントで運用
環境変数はVercel側にも設定する（.env.local はローカル用なので、ここを忘れると本番だけ落ちます）

結果として、コードをpushするだけで本番に反映される状態になりました。初めて自分のURLが世に出た瞬間で、ここは素直に嬉しかったです。

STEP8 修正運用 — 公開してからが本番

公開したら終わり、ではなくて、ここからバグやデザインの粗が出てきます。最初は「あそこ直して」と口頭で伝えていたんですが、何を頼んだか自分でも分からなくなったので、修正依頼をGitHub Issuesに一本化しました。

Issue 作成  →  修正実装  →  PR  →  マージ（Closes #）

役割分担: 人は依頼を伝えるだけ／AIがIssue作成からマージまで対応する（今回はナノクローに任せましたが、Claude Codeでも同じことができます）
種別ラベル: バグ / デザイン / 機能改善 / 要確認
見える化: Open = 未対応 / Closed = 完了

セットアップは gh（GitHub CLI）でやりました。

# ラベルを用意する
gh label create "バグ" --color d73a4a --description "不具合の修正"
gh label create "デザイン" --color a2eeef --description "見た目の修正"
gh label create "機能改善" --color 0e8a16 --description "機能の追加・改善"
gh label create "要確認" --color fbca04 --description "仕様の確認待ち"

日々の運用はこの流れです。

# 1. 依頼を Issue にする
gh issue create --title "[修正] ヘッダーの崩れ" --label "デザイン"

# 2. 作業用ブランチを切る（番号は Issue 番号）
git switch -c fix/issue-12-header

# 3. 修正してコミット
git add -A && git commit -m "ヘッダーの崩れを修正"

# 4. PR を作成（本文に Closes #12 を入れる）
git push -u origin fix/issue-12-header
gh pr create --fill --body "Closes #12"

# 5. マージ → Issue #12 は自動で Closed（＝完了）
gh pr merge --squash

PR本文に Closes #12 と書いておくと、マージした瞬間にIssue #12が自動で閉じます。これだけで「未対応の一覧」がOpen Issueとして常に正しい状態に保たれるので、進捗管理をやめられました。

あと、自分ルールとして画面に関わる修正は、PR本文に「修正前」「修正後」のスクショを必ず貼ることにしています。

Closes #12

## 修正前
（スクショを貼る）

## 修正後
（スクショを貼る）

文章だけより何がどう変わったか一目で分かりますし、デグレ（直したつもりが別の場所を壊す）に気づけます。

なお、秘密情報の扱いだけは最初に固めておくのを強くおすすめします。

.gitignore

node_modules/
.next/
.env
.env.local
.env.*.local
.DS_Store
/.claude/

一度GitHubにpushした秘密情報は、あとで消しても履歴に残ります。最初に止めるのが鉄則、とガイドにも書き残しました。リポジトリも慣れるまではprivate推奨です。

gh repo create プロジェクト名 --private --source=. --push

やってみて分かったこと

GPTは、頼んでいない機能を混ぜてくる

一番の学びがこれでした。GPTが生成した画面には、STEP1で洗い出した機能に無いものが混じっていることがあります。 それっぽい見た目なので気づかずに実装まで進むと、設計書に無いものが実装されている、という状態になります。

対策はシンプルで、一つ一つの作業を精査してから次のステップに進む。ステップの切れ目で「これ、画面一覧にあったっけ？」と確認するだけで、手戻りがかなり減りました。逆に言うと、STEP1で画面一覧を紙に落としておいたからこそ気づけたわけで、最初の絞り込みが後半で効いてきた形です。

振り返りは4ステップで回す

作りっぱなしにせず、こういうサイクルにしました。

漏れを発見する — どこが抜けていたかを洗い出す
原因を分析する — なぜその問題が起きたのか
次回の観点に反映する — 同じ流れで作るとき、どんな観点が必要か
手順をAIでレポート化する — やった手順をまとめて再現可能にする

4番目が、この記事のもとになった成果報告スライドです。

感想

AIを使えば、IT初学者でもアプリが作れるのは本当だと実感しました
同じ手順で別のアプリも作れるので、再現性が高い
初めて自分のWebアプリを公開できて、純粋に嬉しかったです
ただし、アプリ作り自体はAIができても「要件を満たしているか」を考える力は必要でした

まとめ

人は「意図」、AIは「実装」。この分担が最後まで崩れなかった
設計とテストを「型」にする（CLAUDE.md / design/CLAUDE.md / test/CLAUDE.md）と手戻りが激減する
同じ流れで別のアプリも作れる。この記事のSTEP1〜8は、そのままなぞれる手順書のつもりで書きました

AIを「使いこなす力」が、これからの開発スキルなんだなと思っています。AIは強力な相棒ですが、最後に「考えて判断する」のは自分でした。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up