47 ポイント 投稿者 sungmin330 2026-01-06 | 8件のコメント | WhatsAppで共有

プロダクト自体よりも、技術面および実装面で感じたことを振り返った内容です。

完全に個人的な考えです。

大学4年の学期中に学びながら開発したプロジェクトであることを踏まえてご覧ください!

なぜこのプロジェクトを始めたのか

  • スタートアップを立ち上げるつもりでプロダクトを開発。PM/POの観点から
  • Claude Codeで本当にフルスタックのMVP開発が可能かを検証
  • 株式投資における銘柄発掘の課題を解決
  • 商用プロダクトを積極的に導入し、その過程でインサイトを得る

プロジェクトのタイムラインと追加情報

  • 企画+開発: 1か月
  • デプロイ: 1週間
  • 運用: 2か月
  • 投資金額
    • Claude Code: 100USD
    • Apple開発者アカウント: 100USD
    • AWS: 約220USD
    • Managed DB: 約300USD
    • 無料枠: Datadog, Langfuse, Posthog
    • 広告: 4万ウォン
    • 合計: 約100万ウォン(自腹..)

開発プロセス

フロントエンド

  • デザイントークンを定義
  • Figmaでコアページ3つを実装
  • Expoにデザイントークンを適用し、Figma MCPを活用して実装
  • Expo MCPの利用も試みたが安定せず、実際の成果物を見ながらデバッグ
  • 「デザイントークンを使い、他ページのデザインコンセプトを借用して…」というプロンプトで、Figmaワイヤーフレームなしに新規ページを生成

バックエンド

  • 要件をもとにAPIを開発してほしいと依頼
  • フロントエンド要件をもとに必要なエンドポイントも一緒に作ってほしいと依頼
  • 汎用的なスタックであるDjangoを使い、実装自体はボトルネックなくClaude Codeで開発可能

AI

  • マルチエージェントアーキテクチャを定義し、それをもとに実装してほしいと依頼
  • 最新のLangChainおよびLLMOps仕様に対応するため、Webリンクを添付して参照させた
  • LLMサービスのプロンプトをLLM自身が生成して活用

Observability

  • ClickStackベースで構築後、Datadogへ移行
  • システム全体の開発後にロギングおよびAnalyticsを適用

Infra

  • 当初はPulumiを使おうとしたが、Claude Codeがうまく扱えず、AWS CLIベースのスクリプト生成でデプロイ用ファイルを作成
  • コストの関係でCI/CDおよびDev Serverは未構築

導入技術リスト

  • サービス: サブスクリプション/決済、ソーシャルログイン、ダークモード
  • データ: APIベースのデータ収集、CDC、ETL
  • AI: マルチエージェント、Text-to-SQL、Agentic RAG、SSEストリーミング、セッション管理、Retry、Rate Limit
  • LLMOps: AB Test、Cloud Based Prompt Management(OTA Update)、Synthetic Dataset、Evaluation

インサイト

実装

  • 約1か月間、Claude Codeの100USDプランがあれば、この規模のプロダクトを一人で作れた
  • デザイントークンの規格だけを定義してUIを実装したが、もしデザインシステムまで実装してClaude.mdに落とし込んでいれば、より速く安定したフロントエンドを開発できただろう
  • デザインシステムの重要性。フロントエンド開発の生産性を大きく高める。Figmaを作るより、まず実装して修正する方が速い。実際、実装はされているがFigmaにはないページもある。
  • 例外ケースの定義。モバイルアプリとAIシステムではさらに重要だ。システム全体のTimeout管理、Backgroundポリシー、ストリーミング復旧、単純なエラーなど、ハッピーパスではないケースについて企画して実装する必要がある。Claude Codeが自動でエラー処理を実装する場合もあるが、フロントエンドとバックエンドを統合的にうまく解決してくれるわけではない。したがって、このような部分は追加でClaude Codeに要求して解決する必要がある。
  • 大規模リファクタリングは禁止。開発初期にフロントエンドの1ファイルへReactとCSSコードをすべて入れており、これを分離しようとしてリファクタリングを進めた。結果的に失敗した。分離はできたが既存UIと異なる形になってしまい、結局少しずつ分離していく過程を踏む必要があった。開発初期からコードアーキテクチャについて考え、コンポーネントを活用する場合は関連内容をプロンプトに追加して、うまく使わせる必要がありそうだ。
  • Claude.mdを活用。機能開発をした後、その内容をもとにClaude.mdへ保存するとよい内容を追加してほしいとClaude Codeに依頼。徐々にファイルが大きくなるので、ここで本当に必要な内容だけを残し、残りは削除してほしいと要求。readmeとclaude.mdを適切に活用してLLMのコンテキストを調整して活用。(skillsがなかった時代)
  • サブエージェントは活用せず。なくても十分作れたので使わなかった。単にPlanモードで開発計画が具体化するまで依頼し、十分になったらAgentに自律的に開発させた。
  • パッケージや技術は事前に定義して伝える方がよい。Claude.mdやReadmeや特定の仕様を正確に明示して作業させることで、重複コードを作ったり別スタックを使ったりする状況を防げる(Skills?)

AIシステム

  • ReActは遅い。UXがひどい。マルチエージェントを並列実行する構成にしていても遅すぎる。
  • UX。遅い応答を解決するため、マルチエージェントのstepを見せるUX、ストリーミング、アニメーション、動的Markdownレンダリングなどを導入した。しかし応答に毎回1分かかるなら意味があるのか?…(B2Cアプリ)
  • クラウドベースのプロンプトおよびツールスキーマ管理。Online環境で適用できる点がよい。今では必須だと思うし、Langfuse大好き。
  • Text-to-SQLではプロンプトにスキーマを入れる必要がある。このときコンテキストを食いすぎる。fine-tuningあるいはRAGで解決できそうだ。
  • 評価とIteration。ユーザーペルソナごとにSynthetic Datasetを構成し、LLM-as-a-Judgeで評価した。自動化したいが、やはり一人でやるには開発リソースが足りない。
  • 評価メトリクスとルーブリック: 思ったより厄介だ。汎用メトリクスはDAUやMAUのようなものだと思う。こうしたメトリクスだけではインサイトは得られない。ケースバイケースでメトリクスを定義して低品質事例を見分け、それを解決しながらIterationが必要になる。結局、カスタムメトリクスをうまく作れるよう支援するシステムが必要だ。(マルチターンは?..)
  • 思った以上に厳しいOpenAI Tier。低いTierでは良いモデルを本番運用に使えない。

インフラ

  • AWSは高い、Managed DBも高い。良いが後悔している
  • Clickhouseは非常に高いが良い。Managedを使うと楽だ。特にCDCまで一度にできる点がよい。(速くてもLLMが遅いのでは意味がないが)
  • Qdrant、Redis Cloudも悪くない。構築に時間がかからず、コストも安い。
  • Datadog。とても良い。ただし高くなる予定なので無料枠だけ使った。特に発生したエラーを別途まとめて知らせてくれる機能がとても良い。ECSにエージェントをサイドカーとして入れて使った。

サービス

  • 決済とサブスクリプション。Toss Payの利用も検討したが使わなかった。まず年会費が必要で、React NativeのドキュメントがなくSDKもいまひとつ。かなり失望した。結果としてNice Paymentsを選んだ。年会費がなく開発サーバーもあり、無難に開発できた。
  • Apple決済。Nice Paymentsを使ったが問題がある。Appleの決済ポリシーは厳しい。iOS開発の過程でAppleのポリシー問題があり、さまざまな文書やUI面での対応が必要だ。素直にAppleの内部課金システムを使う方が気が楽だと思う。
  • 決済とサブスクリプション(自動課金)は別物だ。自動課金を実装するにはスケジューリング基盤が必要で、カードキーを保存するためのセキュリティにも気を配る必要がある。結局実装はしたが思ったより難しい。Stripeを使ってみたいと思った。
  • プッシュ通知。Expoで手軽に構築できる。結局、メッセージ送信にはバックオフィスが必要だが、必須の機能だと思う。

考えたこと

  • ソフトウェアのデザインパターンとアーキテクチャの重要性は高まっていきそうだ。
  • コーディングエージェントで、トイプロジェクトを超えた成果物を作ることへの人々の関心が高まるとよい。
  • オーバースペックは避けよう。ただ就職するにはオーバースペックも知っておくべきではないか? 次からはインスタンス1台にdocker-composeで終わらせるのがよいかもしれない…(supabaseで?)
  • 一人起業の時代はほぼ来ている。ただし、お金を稼ぐことと作ることは別問題だと思う。
  • 一人でやるのは面白くない
  • LinearもJiraの代わりとして使うには悪くない。初めて使ったので、チケット階層ごとにまとめて見る方法がまだよく分からない。

結果

  • サーバー費用を負担できず、プロジェクトは終了した。
  • 残高 -100

参考

4p以降に追加内容があります。

https://figma.com/deck/wsGLEmFYOUPUheWBl1t23K/…

8件のコメント

 
angrybird0 2026-03-20

残高 -100

 
chickendreamtree 2026-01-09

良い内容の共有ありがとうございます。

 
princox 2026-01-07

100万ウォン以上の価値がある経験だと思います。私も大学4年生のときは、あまりプロジェクト経験がなかったと記憶しています。AIを使ってあれだけ実装してみせたなんて、本当にすごいですね。

 
mark87 2026-01-07

経験の共有がとても面白いですね。楽しく読ませていただきました。調べてみたら、なんと母校の後輩の方だったんですね。最近は4年生のうちにこんな挑戦までしているんですか。本当に素晴らしいです。

 
slowandsnow 2026-01-07

学習目的でオーバーエンジニアリングしたのでしょうが、コストが高すぎて残念ですね。

 
awbrg789 2026-01-07

しっかりしていますね

 
botplaysdice 2026-01-07

最近の大学生のポートフォリオのクオリティは本当にすごいですね。20年前に私が卒業した頃は、本当に何も分からないまま卒業した気がしますが、たいしたものです。

 
zxcv123 2026-01-07

AIが全体の水準をものすごく引き上げましたよね。
もう今は、本当に開発者はただ人当たりのいい人を採るのが正解な気もしますね(笑)