> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 複数のアーティファクトと別々のプロジェクト

> Replit で、アーティファクトを1つのプロジェクトにまとめる場合と、別々のプロジェクトを作成する場合について学びましょう。

[プロジェクト](/ja/references/projects-and-artifacts/projects)は、Replit で構築するすべてのものを収めるコンテナです。プロジェクトには、デザイン、アプリ、スライド、データ、および作成したすべてのアウトプットが含まれます。
[アーティファクト](/ja/references/projects-and-artifacts/artifacts)は、プロジェクト内の公開可能なアウトプットです：ウェブアプリ、モバイルアプリ、スライドデッキ、動画など。

複数のものを構築する場合、2つの選択肢があります：

* 1つのプロジェクトに複数のアーティファクトを追加する
* または、別々のプロジェクトを作成する

適切な選択は、アプリがデータ、ロジック、デプロイのライフサイクルを共有するかどうかによって異なります。このガイドでは、アーティファクトを1つのプロジェクトにまとめる場合と、別々に作成する場合について説明します。

## プロジェクト内でアーティファクトが共有するもの

[アーティファクト](/ja/references/projects-and-artifacts/artifacts)が同じ[プロジェクト](/ja/references/projects-and-artifacts/projects)内にある場合、自動的に以下を共有します：

* **データベース**：1つのアーティファクトがデータを書き込むと、他のアーティファクトが即座に読み込めます
* **バックエンドとAPI**：共有されたサーバーロジック、重複したコードは不要
* **ファイルストレージ**：画像、ドキュメント、アップロードがアーティファクト間でアクセス可能
* **デプロイ**：公開するとすべてが同期してまとめてデプロイされます

つまり、アーティファクト間の接続設定やコードの重複が不要です。ただし、他のアーティファクトを公開せずに1つのアーティファクトだけを公開することもできません。

## クイックガイド

既存のプロジェクトにアーティファクトを追加するか、別のプロジェクトを作成するかを決める際の主なシナリオを紹介します。

| **1つのプロジェクトに複数のアーティファクトを使用**         | **別々のプロジェクトを使用**                      |
| ------------------------------------ | ------------------------------------- |
| アプリが同じデータとバックエンドを共有している              | アプリが基盤となるロジックやデータを共有していない             |
| すべてをまとめてデプロイしたい                      | 独立したデプロイサイクルが必要                       |
| 補完的な関係にある（顧客向けアプリと管理ダッシュボードなど）       | 無関係なプロダクト、または異なるクライアント向け              |
| 1つのアーティファクトの変更を他のアーティファクトに自動的に反映させたい | プロジェクトが短命（キャンペーンのランディングページやイベントサイトなど） |

## 例

### 同じプロジェクト：1つのプロダクト向けウェブアプリ＋モバイルアプリ

あるレストランが、顧客がメニューを閲覧するためのウェブアプリと、スタッフが注文を管理するためのモバイルアプリを構築しています。両方のアプリが同じメニューアイテム、注文、顧客情報のデータベースに接続されています。

**1つのプロジェクトにする理由：** アプリが同じデータとバックエンドを共有しています。顧客がウェブアプリで注文すると、スタッフはモバイルアプリで即座に確認できます。

### **同じプロジェクト**：アプリ＋管理ダッシュボード＋投資家向けピッチデッキ

あるスタートアップが、メインプロダクト、コンテンツ管理用の内部管理パネル、資金調達用のスライドデッキを、すべて1つのプロジェクトで構築しています。

**1つのプロジェクトにする理由：** 管理ダッシュボードはアプリが表示する同じデータを管理しており、ピッチデッキは共有バックエンドからライブメトリクスを参照できます。

### **別々のプロジェクト**：2つの無関係なクライアントアプリ

あるフリーランサーが、1つのクライアント向けにECストアを、別のクライアント向けに予約システムを構築しています。

**別々のプロジェクトにする理由：** アプリには共有されるデータやロジックがありません。各クライアントには独立したデプロイが必要であり、一方への変更が他方に影響しないようにする必要があります。

### **別々のプロジェクト**：メインプロダクトと並行するキャンペーンのランディングページ

年間を通じて稼働する本番アプリと、マーケティングキャンペーン用の短命なランディングページがあります。

**別々のプロジェクトにする理由：** キャンペーンページには独自のライフサイクルがあります。立ち上げて数週間稼働させ、その後終了させます。別々にしておくことで、メインプロダクトに余分なものが混在せず、独立して公開または削除できます。

## よくある質問

<Accordion title="アーティファクトを別のプロジェクトに移動できますか？">
  現在はできません。アーティファクトを分離する必要がある場合は、新しい[プロジェクト](/ja/references/projects-and-artifacts/projects)を作成して、Agent にそこで再構築するよう依頼してください。
</Accordion>

<Accordion title="プロジェクトに含められるアーティファクトの数に制限はありますか？">
  プロジェクトに含めることができるアーティファクトは最大7個です。アーティファクトが増えるとより多くのメモリを消費し、プレビューが遅くなる可能性があるため、この制限が設けられています。それ以上のアーティファクトが必要な場合は、別の[プロジェクト](/ja/references/projects-and-artifacts/projects)を開始してください。
</Accordion>

<Accordion title="プロジェクトから1つのアーティファクトだけを公開できますか？">
  現在はできません。公開するとすべてがまとめてデプロイされます。独立したデプロイが必要な場合は、別々のプロジェクトを使用してください。
</Accordion>