> ## 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.
# 並行して構築する
> 並行タスクを使って複数の機能を同時に構築する方法を学びます：安全に委任し、作業を小さく分割し、驚きのない形で変更を適用します。
複数の作業を同時にこなす力は、優れたビルダーと卓越したビルダーを分けるスキルの一つです。このページでは、たとえこれまでこの方法で作業したことがなくても、安全に複数の機能を同時に構築する方法を学びます。
## Agentとの新しい働き方
これまでは、隣に座っているパートナーのようにAgentと作業してきたかもしれません：質問し、見守り、応答する。並行して構築するというのは、これとは異なる関係性です。機能をAgentに**タスク**として渡すと、あなたが他のことをしている間に、Agentがバックグラウンドでそれを構築します。
実は、日常生活ではすでにこの働き方をしています。洗濯機が終わるまでその前に立ち続けたりはしません。洗濯を始めたら、料理をしに行きます。タスクも同じように機能します：1つを開始し、それが実行されている間に別のものを開始したり、他のものをレビューしたり、メインの会話でAgentとチャットを続けたりできます。
これによってあなたの役割が変わります。1つの構築を見守る乗客ではなく、複数の構築を指揮するディレクターになるのです。
## タスク実行中もアプリは安全
誰もが最初に聞く質問はこうです：*見ていない間に、バックグラウンドタスクがアプリを壊してしまうのでは？*
いいえ、大丈夫です。各タスクはプロジェクトの独自の**コピー**上で作業します。タスクの作業内容をレビューして適用することを選ぶまで、アプリは変更されません。
各タスクは独自のAgentを持ち、プロジェクトの全コンテキストを引き継ぐため、同じ説明を繰り返す必要はありません。タスクは互いに独立しているので、最初のタスクが実行中であっても、すぐに次のタスクを開始できます。
## 実例：3つの機能を同時に
予約とサインインをすでに処理しているレンタカーアプリを想像してください。そこに3つの機能を追加したいとします：
* イベントページ
* イベント登録
* お問い合わせフォーム
1つずつ順番に構築すると、それぞれ約5分として合計15分かかります。並行して構築すれば、約5分で済みます。
各機能ごとにタスクを作成します。タスクはPlanモードで開始するため、構築前にそれぞれのプランが表示されます。プランを承認すると、何が起こるか見てみましょう：イベントページとお問い合わせフォームはすぐに構築を開始しますが、イベント登録は待機します。イベントページがまだ存在しなければ、訪問者はイベントに登録できないからです。Agentはこの依存関係を自動的に検知し、プロジェクトマネージャーのように振る舞い、依存先のタスクの後にそのタスクを実行します。
すべてを一度に確認するには、タスクボードを開きます。ここでは、すべてのタスクが下書きから完了まで、列をリアルタイムで移動していきます。
## 作業を小さく分割する
並行構築をうまく機能させるスキルは、機能を小さく自己完結したタスクに切り分けることです。小さなタスクはより早く終わり、レビューしやすく、互いに干渉する可能性も低くなります。
便利なルール：**タスクの説明に「そして」が含まれる場合は、分割を検討しましょう。**
* 良い例：「イベントページを追加する」「お問い合わせフォームを追加する」
* 大きすぎる例：「イベントと登録とメール通知と管理画面を追加する」
大きいバージョンが間違っているわけではありませんが、1つのAgentにすべてを順番にやらせることになります。4つの小さなタスクに分ければ、Agentはそれらをまとめて実行できます。
自分で試してみましょう。次のうち、並行して実行できるのはどれでしょうか？
1. ダークモードの切り替えを追加する
2. 顧客レビューセクションを追加する
3. 顧客がレビューに返信できるようにする
4. アプリをフランス語に翻訳する
タスク1、2、4は互いに独立しており、すべて同時に実行できます。タスク3はタスク2に依存しています：レビューが存在しなければ返信する対象がないからです。これを自分で見抜く必要はありません。Agentが依存関係を検知し、これら2つのタスクを自動的に順序付けしてくれます。
## 適用する前に更新する理由
ここは誰もがつまずく唯一のポイントなので、ゆっくり説明します。
2人の友人が、同じパーティーの招待状のコピーをそれぞれ家に持ち帰って改善するとします。1人は地図を追加し、もう1人はスケジュールを書き直します。最初の友人のバージョンを採用すると、それが本物の招待状になります。ここで2人目の友人のコピーに問題が生じます：その書き直しは、もう存在しない招待状を元にしているのです。2人目の作業を採用する前に、最新バージョンをもとにやり直してもらう必要があります。
タスクもまったく同じように機能します。それぞれのタスクは開始時にプロジェクトをコピーしています。1つのタスクの変更を適用した瞬間、他のすべてのタスクのコピーは1バージョン分古くなります。無関係な機能であれば多くの場合問題ありませんが、コードを読んでいるわけではないので、2つのタスクが同じ箇所を変更していないとは言い切れません。
タスクの変更を適用する前に、まずそのタスクを**更新**してください。更新すると、タスクがアプリの最新バージョンと同期し、コンフリクトが解決されるため、タスクは互いを上書きするのではなく、積み重なるように構築されます。
## マネージャーとしてレビューする
並行構築を行うと、あなたはマネージャーになります。そして、マネージャーにありがちな典型的な失敗は、確認していない作業を承認してしまうことです。守るべき規律はシンプルなループです。一度に1つのタスクずつ進めます：
完了したタスクを開き、機能を試してみます。ユーザーになったつもりでクリックして操作してみましょう。
問題なければ、変更をメインアプリに適用します。
次に完了したタスクに触れる前に、それを更新して、今変更したばかりのバージョンと同期させます。
すべてのタスクが取り込まれるまで、テスト、適用、更新を繰り返します。
まとめて承認することは絶対に避けてください。レビューしていない3つの機能を一度に適用すると、何かおかしいときに容疑者が3つになってしまいます。
## 順番に進めるべき場合
並行構築はツールであってルールではありません。次のような場合は、メインの会話で一度に1つずつ進めましょう：
* **2つのアイデアが同じ画面に触れる場合。** 「ホームページをリデザインする」と「ナビゲーションを変更する」は衝突します。順番に行いましょう。
* **探索している場合。** デザイン作業では、1回の試みの結果が次に欲しいものを変えてしまいます。探索は作業指示ではなく会話です。
* **タスクを一文で説明できない場合。** シンプルに言い表せないなら、それを委任する準備がまだできていないということです。
## 自分の限界を見つける
並行構築の限界を決めるのはReplitではありません。あなたの注意力です。タスクを切り替えるたびに、集中力という小さなコストを支払うことになり、その予算は人それぞれ異なります。
まずは2つのタスクから始めましょう。レビューが快適に感じられたら、3つに挑戦してみてください。Agentは構築が十分に上手なので、すべてのステップを監視する必要はなく、ほとんどのビルダーはこの切り替えに見合うだけの速さを感じています。ただし、これは有効にする設定ではなく、練習して身につけるスキルです。
## 次のステップ
* [タスクシステム](/ja/core-concepts/agent/task-system)：タスクの仕組みに関する完全なリファレンス。
* [PlanモードとBuildモード](/ja/learn/plan-vs-build-mode)：タスクがプランから始まる理由。
* [バイブコーディング101](/ja/learn/foundations/vibe-coding-101)：タスクを分割することを自然にする、小さく分けて構築するというマインドセット。