🪄

初心者が“なんとなく”をやめて作ったTikTokクローン（開発ログ1）

に公開
AI
Python
初心者
アプリ開発
システム設計
tech

〜設計・構成・AI活用まで含めた記録〜

週2日、1時間ずつ時間を取りながら開発しました。本記事はその時系列に沿ってまとめています。

はじめに

私はIT未経験の状態でシステムエンジニアになり、10か月が経ちました。
開発経験もほとんどないまま現場に入り、日々学びながらも、「自分でちゃんと設計して作れるのか？」という不安はずっと残っていました。

これまでの個人開発は、正直「なんとなく」😅。AIに聞き、エラーを直し、動けばOK。でもそれでは応用が効かない...。

だから今回、TikTokのクローンを題材に、設計からデプロイまでの流れを、きちんと整理しながらやってみることにしました。
先輩にアドバイスをいただきながら、

  • どう考えるのか
  • なぜその構成にするのか
  • どう進めるのか

その思考プロセスをできるだけ細かく言語化しています。

こんな人に読んでほしい

  • IT未経験・駆け出しエンジニアの方
  • 「動くけど、理解は浅い気がする」とモヤモヤしている人
  • 開発の際、何から始めればよいかわからない人
  • AIに頼れるけど、実力がついているか不安な人
  • TikTokなどの身近なアプリをエンジニア視点で見てみたい人

この開発で大事にしていること

本プロジェクトは
「迷わず作り続けられる構造」を作ることを重視しています。

  • どういったステップでどう考えてすすめていくか
  • AIを“使い倒す”が、理解は手放さない

設計・実装・思考のログを残し、
再現性のある開発プロセスとしてまとめることをゴールにしています。

Day1：題材決定・既存サービス分解・全体像把握

1. ゴール設定・題材決定

題材は TikTokクローン。
理由：

  • UIが明確で、画面遷移が少ない
  • フロント・バック・API設計が必須
  • 「なんとなく作った」にならず、構造を説明できる
  • なんか面白そう
  • TikTokはユーザーとして使ったことがあるので気になる

この時点のゴールは 完成させることではなく、構造を理解しながら作ること。

2. 既存サービス分析（TikTok）

TikTokのUIをそのまま眺めるのではなく分解した。
ホーム画面のスクリーンショットなどから、必要な機能・コンポーネントを洗い出していく。

  • TikTokの画面・操作を洗い出し
  • 再生
  • スクロール
  • いいね
  • コメント
  • シェア

「最低限、アプリとして成立する機能」を抽出
ここで意識した点

  • いきなり全部作らない
  • MVPに必要な要素だけを残す

UIが派手でも、構造は意外とシンプルだと分かる。

Day2：技術スタック・構成・設計思想の整理

3. 技術スタック検討

ある程度必要な機能を洗い出せたら、それを基に、技術スタックを検討する。
この時、他の類似サービスの技術スタックを参考にしたり、AIからアイデアを得て参考にするのもポイント。

MERNスタックや安定のLAMP、高速なJAMstackなど知名度が高い技術スタックもあるので、それらの特徴などを勉強するもの今後のシステム構成の参考になる。
スタートアップからメガベンチャーなど様々な会社の技術スタック事例を見るのは面白いなと感じました。
https://findy-tools.io/articles/2024-tech-stack/1

今回私は、

フロントエンド

  • React（typescript）
  • シンプルな構成を優先

バックエンド

  • Python / FastAPI想定
  • APIベース設計

DB・認証

  • SQLite
  • 初期は最低限 or 仮置き
  • 簡単にローカルで動かせるDBを選択
  • 将来拡張を前提に考慮

4. プロジェクト構成・フォルダ設計：modular monolith

modular monolith とは

  • 同じリポジトリ内
  • ただし、役割は明確に分離

フロント / バックエンド分離
のように
責務単位でモジュール化する。

なぜこの構成か

  • 並列して考えられる
  • 今自分が「どの部分」にいるか分かりやすい
  • 「分けられる状態」を保ったまま一体で作れる
  • context switching の概念

context switching = 別のプロセスを実行中に、複数のプログラムを並行動作させる。

フォルダ構成

  • 他人のリポジトリを参考にしつつ
  • 最終的には自分が把握できる構成を自分で作る

5.セキュリティと責務の意識

設計段階から以下を意識する：

  • APIキーをフロントエンドに埋め込まない
  • 認証・認可は必ずバックエンド責務
  • フロントは「表示と操作」に集中させる

この段階で,「これはフロントでやるべきか？バックか？」を毎回自問することで、設計の精度が上がる。

セキュリティも設計の一部として考える。

Day3：土台構築・ロードマップ・設計の言語化

6. フロント・バックの土台作成

  • テンプレートを使って初期構築
  • まずは「起動する」「つながる」状態を作る

この段階でやらないこと：

  • 機能実装
  • UIの作り込み

目的は全体がつながる最低限の骨組みを作ること。

7. ロードマップ策定

  • 今すぐやること
  • 後回しにすること
  • 壊す前提のもの

今回は学習目的の個人開発なので、完璧な計画ではなく、 迷った時に戻るための地図として作成しました。

Day4：画面設計・AI活用・実装準備

8. 画面設計・ワイヤーフレーム

ここでAIを本格的に使う。

  • ワイヤーフレームをAIに作らせる
  • ただし 前提条件をプロンプトに明示
    • PCブラウザ版
    • 対象ユーザー
    • 画面の目的
      要件を整理できていると便利

これにより、

  • 手戻りを減らす
  • イメージを先に固定する

この時点ではデザインを詰めすぎず、

  • 何が表示され
  • 何が操作でき
  • 何がデータとして必要か

が分かることを優先した。
良かった点：

  • 完成イメージを先に持てる
  • UI実装時の迷いが激減
  • 二度手間が減る

9. UI実装の進め方

  • VS Code 上でシンプルブラウザーを開く
  • 指定しながら微調整
  • 完璧を目指さず、更新前提で進める

「考える」と「見る」を行き来できる環境をつくる

今回の開発で一番意識していること

AIとの付き合い方（かなり重要）

今の開発では、

  • ワイヤーフレーム
  • 画面一覧
  • API整理
  • ドキュメント草案
    など、ほぼ何でもAIに突っ込める。
    だからこそ、
  • どこまでAIを使うか
  • どこを自分で理解するか
    これらを意識しないと、「動くけど説明できない」「自分のものにならない」状態になる。

AIは思考の加速装置であって、思考の代替ではないので、そのことを常に念頭におきつつ
そしてこのログは、 「あとから自分が振り返って理解できる」ための記録でもあります。

Discussion