2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@s1019(S)

AI仕様駆動開発で作る、MBTI×恋愛相談アプリ「OSHIRIAI」

2
Posted at

AI仕様駆動開発で作る、MBTI×恋愛相談アプリ「OSHIRIAI」

サービスの内容

OSHIRIAI (推しりあい) は、MBTI風診断とAI恋愛相談を組み合わせたWebアプリケーションです。
単なる性格診断にとどまらず、相手の性格タイプと自身の性格タイプや会話傾向から推論して、
恋愛の日々の悩みを親身になって寄り添います。

主な機能は以下の通りです：

  • 恋愛MBTI風診断: 50問の恋愛や対人関係に特化した質問から性格推定
  • パートナー診断: 気になるあの人の性格推定を自然対話から診断
  • AI恋愛相談: 気になる人の性格タイプと自身の性格タイプから推論したAIとの恋愛・対人相談
  • ポイントシステム: 相談機能などを利用するためのポイント管理機能も搭載

最初にサービスの宣伝

  • 「あなたを理解するAIパートナー」: 一般的なAIチャットとは違い、あなたの性格タイプと相手の性格タイプを考慮し、また会話履歴から性格傾向もサマリしながら親身にアドバイスを提供します
  • 「リアルタイムな対話体験」: ストリーミング応答により、まるで人と話しているようなスムーズなコミュニケーションを実現しました

サービスの技術構成

本アプリは以下のモダンな技術スタックで構築されています。
構成はかなりシンプルで最近私が作っているサービス構成の中ではもっとも単純です。
Front-Backend間はSSEでストリーミング対応しています

Frontend

  • Framework: Next.js (React)
  • Styling: Tailwind CSS
  • State Management: Context API

Backend

  • Framework: Express, tsoa (OpenAPI definition)
  • Database: PostgreSQL (TypeORM)
  • AI/LLM: Mastra Agent Framework, OpenAI GPT-5
  • Authentication: JWT (jsonwebtoken)

Infrastructure

  • Environment: Docker (Dev Container対応)

プロジェクト構成と解析

本プロジェクトはモノレポ構成を採用しており、インフラからフロントエンド、バックエンドまでを一元管理しています。
主要なディレクトリ構成と役割は以下の通りです。

oshiriai/
├── .devcontainer/       # 開発環境 (Dev Container)
├── .github/             # CI/CD (GitHub Actions)
├── infrastructure/      # インフラ (AWS CDK)
├── oshiriai-front/      # フロントエンド (Next.js)
└── oshiriai-server/     # バックエンド (Express)

1. 開発環境 (.devcontainer)

Dockerを用いた統一された開発環境

チーム開発における環境差異をなくすため、VS CodeのDev Containersを活用しています。
devcontainer.json には、Prettier, Biome, GitLens などの推奨拡張機能や、PostgreSQLへの接続設定が定義されており、Dockerfile でNode.js環境を構築します。これにより、開発者はコンテナを立ち上げるだけですぐにコーディングを開始できます。

2. CI/CD (.github)

GitHub Actionsによる自動化

workflows ディレクトリ配下に、各サービスのデプロイパイプラインが定義されています。

  • on-push-frontend.yml: oshiriai-front ディレクトリへの変更を検知し、DockerイメージをビルドしてECRへプッシュします。
  • on-push-server.yml: oshiriai-server ディレクトリへの変更を検知し、同様にECRへプッシュします。

共通のデプロイロジックを再利用することで、ワークフローの保守性を高めています。（あたり前か、、、）

3. インフラ (infrastructure)

AWS CDKによるInfrastructure as Code (IaC)

AWSリソースはすべてTypeScriptで記述されたCDKコード (infrastructure-stack.ts) で管理されています。

  • Compute: AWS Fargate (ECS) 上でFrontendとServerのコンテナを実行。
  • Network: VPC, Public/Private Subnet, Security Groups, ALB, Route53を構成。
  • Database: RDS (PostgreSQL) をプライベートサブネットに配置。
  • Access: IAM Roleによる権限管理。

4. フロントエンド (oshiriai-front)

Next.jsアプリケーションとマルチステージビルド

Dockerfile ではマルチステージビルドを採用し、生成物のみを軽量な実行用イメージ (runner) にコピーすることで、イメージサイズを最小化しています。
React Contextによる状態管理や、Tailwind CSSによるスタイリングなど、モダンなフロントエンド開発の構成です。

5. バックエンド (oshiriai-server)

ExpressサーバーとAIエージェントの統合

Dockerfile はフロントエンド同様にマルチステージビルドを採用し、TypeScriptをビルドしたJSファイルを実行します。
tsoaを用いた型安全なAPI定義や、Mastra Frameworkを組み込んだAIエージェントのロジックが含まれています。

AI仕様駆動開発の実情

結論：この規模なら 1日 で開発可能です。

しかし、完全な自動化（100%）は現時点では難しいというのが正直なところです。

特にドメイン境界の設計や認証周りの詳細な実装など、
最後の詰め（ラストワンマイル）は手動での調整が必要不可欠でした。

7~8割 くらいまでは余裕でできるんだけど、
AI駆動開発って最後の1割を埋めるのが、自分で書いてないのも相まって指数関数的にしんどいです。
しかし、全部手動で作ったら10日はかかったと思うので、1order くらい早いです。

本プロジェクトにおけるAI開発の貢献度は以下の通りです。

開発フェーズとAIの貢献度

  1. 7割 (70%) まで: Antigravity + Gemini Pro 3

    • プロジェクトの雛形作成、基本的なボイラープレートコードの生成、DBスキーマの初期設計などは、AntigravityとGemini Pro 3が高速に処理しました。
    • 圧倒的な速度で「動くもの」を作るフェーズで非常に強力でした。

  2. 9割 (90%) まで: Cursor + Claude Sonnet 4.5 or 4.6

    • より複雑なロジックの実装、バグ修正、リファクタリングにはCursorとClaude Sonnet 4.5 or 4.6を活用しました。
    • 文脈を理解した高度なコード補完と修正により、品質をプロダクションレベルに引き上げました。

  3. 残り1割 (10%) : 手動 (Human)

    • ドメイン境界の調整: 複雑なビジネスロジックの境界線や、微妙な仕様のニュアンス決定。
    • 認証・セキュリティ: セキュリティ要件の最終確認や、細かい挙動の修正。
    • UXの微調整: AIでは判断しきれない「使い心地」の部分。

AI仕様駆動開発は、開発スピードを劇的に向上させますが、最終的な品質保証と設計の整合性を取るためには、エンジニアによる 「最後の1割」の手動介入 が依然として重要です。

AI駆動の辛いところ

SkillやMPCサーバーで Method や how to を教育しても
以下が防ぎきれません。
今回のような比較的シンプルなサービスですら嘘をまぜられてしまいます。

責務境界を捻じ曲げる

責務が完全に分離している部分は、LLMまかせでいけるのですが、
どうしても責務境界がうまくいきません。

たとえば、backendとfrontendの結合境界で矛盾があった場合、
人間の場合はUX観点で最適になるように矛盾を解きますが、
LLMの場合は、backend側を100%正として、front側を捻じ曲げるか、
その逆でfrontを正としてbackendを捻じ曲げるのどちらかを行ってくケースがあります。

フォールバックと後方互換

仕様駆動開中、
実装 → Planの比較(Thinkig) -> 実装 ... みたいなイテレーションをLLMが自動で回しますが
その中で、自身が実装したEntityを自身が破壊する時に、
勝手に後方互換を担保として複雑化してきます。
(Plan上には後方互換不要と書いていますが、稀にやる)

実行がエラーになっている関数を根本修正せずに、
fallbackを追加して、見かけ上動作している状態でテストをパスさせてきます。

型AnyとOptionalの多様

型をanyで無理やり整合したり、必須のpropsもOptionalで定義してきて
人間が見た時に、可読できない状態にしてくる。

これらは、どれだけルールを強化しても完全に0にはできませんでした。

SaaS is Dead って本当？

2026年2月の現段階で、私は「エンタープライズクラスのSaaSをAIだけで実装可能」というお題には懐疑的です。

仮に実現できた人がいるなら、マルチテナント対応、ユーザーごとのR/W権限管理、エンタープライズクラスの可用性を持つプロダクトをAI駆動開発だけで作った作品を見せてほしいです。

コードを直接記述する量は減った

ここ数年のLLMの進歩は凄まじいと思います。直接コードを書く量は圧倒的に減りました。フロントエンドやテスト設計は、もうほぼ自分で書くことはなくなりました。

私の会社にいたコーダーさんもほとんどカットされ、cursor、copilot、codex、antigravityなどに置き換わりました。

しかし、設計・実装・運用をすべてAIで置き換えられる世界線は、まだ数年はかかると思います。

またAIが技術的に超えないといけないハードルとして、以下の課題 と考えています。

サービス・ドメイン境界

  • サービス間の境界（ドメインAとドメインBの結合、認証認可）
  • サービス全体の権限（LLM/MPCが参照してよいもの、よくないもの）
    • ユーザごとにDBのMCPにアクセス可能なR/W権限やentityが異なるケースの制御

物理境界（Cloud構築系）

  • 可用性
  • エラーレート急上昇時の原因調査
  • パフォーマンスボトルネックの特定

ビジネス境界

  • 人間の振る舞いによる改善

課題の整理

簡単な課題
ドメイン境界のような、複数の知識を統合的に扱う必要があるケース
→ 入力トークンが爆発してしまう
→ ドメイン同士に矛盾がある

難しい課題
物理や人間のような、境界知識がデジタル情報化されていないケース
→ そもそも入力トークン化できない

結論：非エンジニアによる完全AI駆動開発はまだ先

SWエンジニアでない人がAI仕様駆動開発だけでサービスを提供するには、上記の課題がすべて解決された後になるのではないかと思います。
それは、まだ先のことだろうなと思っています。

エンジニアの役割は変わらない

エンジニアリングは社会実装です。
会社や社会の課題と親身に向き合い、それを設計・実装・運用していく中でAIをうまく活用していく——ので、そんなに役割かわらないと楽観的に見ています。

コンサル・設計・実装・運用が溶け合って、すべてうまくこなしていく必要はあると思いますが、付加価値の高いエンジニアはAIの出現依然もそれをこなしていたはずです。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?