AIアシスタントを使ってセットアップする

このページは、AIアシスタント向けの手順書です。Claude Code、Codex、Cursor、またはウェブページを読み取り、理想的にはリポジトリのローカルコピーで作業できるあらゆるアシスタントを対象とします。この手順書では、1つ以上のリポジトリでCoroidを設定する方法をアシスタントに案内します。ログイン、アクセス権付与、シークレット入力、変更承認など、人間のみが行える作業の際には、必ずユーザーの確認を求めます。

アシスタントに渡してください#

Coroidが作業するリポジトリでアシスタントを開き、次のプロンプトを入力してください：

Set up Coroid for this repository. Follow the runbook at
https://coroid.ai/docs/export/en-US/getting-started/assistant-setup.md
step by step. Ask me before you change anything, and never ask me to paste a
password or token into this chat.

複数のリポジトリに対応する場合は、それらをすべて含むディレクトリでアシスタントを開き、プロンプト内でその名前を指定します。アシスタントが検査と確認を行い、ユーザーが介入が必要な各ステップで具体的に何をすべきかを教えてくれます。

アシスタントの基本ルール#

Coroidはホスト型のAIソフトウェアファクトリーであり、作業内容の記述からユーザーのリポジトリ内でテスト済みかつレビュー済みのpull requestを生成します。以下のルールに従ってください：

1. ユーザーが作業を指示し、アシスタントが準備を担います。ユーザーに代わって登録、ログイン、利用規約への同意、アプリのインストール、アクセス権の付与は行えません。何をどこで行うべきかを正確に伝え、ユーザーから完了の確認を得るまで待機してください。
2. 会話内にシークレット情報を含めないでください。パスワード、個人用アクセストークン、プロバイダーキー、MCPトークンを要求しては決して実行しないでください。ユーザーはシークレットをCoroidポータルまたは自身のシェルに入力します。万が一チャットに貼り付けられた場合は、ユーザーにそれを無効化して新しいものを作成するよう伝えてください。
3. 変更前に必ず確認を求めてください：ユーザーのリポジトリ、Coroidプロジェクト、招待状におけるコミット、ブランチ、プルリクエストなどです。
4. 次のステップに進む前に各ステップを確認してください。チェックに失敗した場合は、そのステップの注記を参照し、合格するかユーザーがスキップを選択するまで続行しないでください。
5. 推測ではなく製品の仕様に従ってください。ポータルにこの手順書で説明されていない項目が表示された場合は、ユーザーに見えた内容を伝え、ポータルの指示に従ってください。設定を勝手に作り出さないでください。
6. セットアップ記録を残してください最終的に各ステップとその結果を記録します。

各ステップでは詳細ページへのリンクが提供されます。https://coroid.ai/llms.txt文書全体の索引が作成されます。

ステップ1：計画を合意する#

以下の質問を一度に、一つずつではなくユーザーに尋ねてください：

次にプランを繰り返し確認します：ユーザーが関与する下記の手順と対象となるリポジトリです。

こちらをご覧くださいプランと料金、制限とクォータと同期またはローカルのみ。

ステップ2：各リポジトリがクリーンなクローンからビルドおよびテストできるかを確認します。#

これは最も有益な作業です。すべてのCoroidタスクはクリーンで一時的なLinuxワークスペースで実行されます：新しいクローン、キャッシュなし、イメージのツールチェーン以外はインストールされていません。プロジェクトをビルドおよびテストできないエージェントは自身の作業を検証できず、変更とは無関係な理由でタスクの検証に失敗します。

リポジトリ内でローカルに作業できる場合は、各リポジトリに対して以下を行ってください：

1. 使用言語、パッケージマネージャー、およびモノレポかどうかを特定します。
2. README、CI設定、およびマニフェスト内にあるインストール、ビルド、テストのコマンドを見つけます。
3. 実行前に確認を求めてください。その後、リポジトリを空の一時ディレクトリにクローンし、他に何も設定せずにインストール、ビルド、テストを実行します。ユーザーの作業コピーにはキャッシュや.envファイルがあり、問題を隠してしまいます。
4. 新しいクローンでは存在しないが実行に必要なものをすべて記録します：
   • テストで必要なデータベース、キャッシュ、キューなどのサービス
   • テスト前のコード生成、マイグレーション、フィクスチャなどの手順
   • 環境変数または.envファイルで、コミットされていないもの
   • プライベートパッケージレジストリ
   • イメージに含まれていないランタイム エージェント環境

デプロイ、公開、または共有環境に影響を与えるコマンドは決して実行しないでください。テストスイートが遅い場合や有料サービスを呼び出す場合は、事前にユーザーに確認を求めてください。

各リポジトリごとに簡易な準備状況チェック結果を報告します：実行コマンド、テストスイートの実行時間、合格した項目、および提案される修正策を含む各不備内容。

ランタイムが不足している場合も障害にはなりません。ツールチェーンを内包するコンテナで対応できます。ローカルでリポジトリにアクセスできない場合は、ユーザーから得られる情報を収集し、クリーンクローン検証が行われなかったことを記録してください。

こちらを参照してくださいビルドおよびテスト設定および言語サポートとエージェント環境。

ステップ3：Coroidのエージェントが読み取る指示書を作成する#

各タスクの実行前に、Coroidのエージェントはリポジトリ内のメモリファイルを読み取ります：AGENTS.md、CLAUDE.mdまたはGEMINI.mdをルートディレクトリに配置し、.cursor/rules。ステップ2で検証したコマンドはここに記載します。

「AGENTS.md」を提案するか、既存のファイルに追加し、以下の内容を記載します：

• クリーンクローンから検証済みのインストール・ビルド・テストコマンド、およびそれらを実行するディレクトリ。
• テストに必要な手順とサービス。
• 1つのパッケージや1つのファイルなど、最小限で有用なテストセットの実行方法。
• コード自体では示されない規約や制約：固定モジュール、変更禁止領域、追加禁止の依存ライブラリ。

コード内にすでに記載されている内容は省略し、ファイルを短く保ってください。もしCLAUDE.mdまたは.cursor/rulesに同じ指示が記載されている場合は、AGENTS.mdにまとめ、別のファイルから@AGENTS.md行でインポートします。

ユーザーに差分を確認させてください。承認を得たら、新しいブランチ上でコミットし、pull requestを開くか、ユーザー自身にコミットさせてください。最初のタスクが実行される前にこの変更をベースブランチに反映させる必要があります。なぜなら各タスクはそのブランチのチェックアウト先からメモリファイルを読み取るからです。ユーザーが承認したステップ2の修正内容も同様の手順で処理します。

こちらを参照してくださいプロジェクトコンテキスト設定およびプロジェクトコンテキスト。

ステップ4：アカウントと組織（ユーザー）#

ユーザーが既にCoroidの組織にオーナーまたは管理者として所属している場合は、このステップをスキップしてください。

ユーザーに次の操作を依頼してください：

1. でサインアップするhttps://client.coroid.ai/auth/signup勤務用メールアドレスを使用して、アドレスを認証します。
2. 利用規約に同意する
3. 組織を作成する

確認：ユーザーがを開けるか確認してくださいhttps://client.coroid.ai/projects。このセットアップを完了するにはオーナーまたは管理者の役割が必要です。なぜなら、ソースコントロールの接続やプロバイダーキーの追加ができるのはこれらの役割のみだからです。

を参照してくださいアカウントと組織を作成する。

ステップ5：ソースコントロールを接続（ユーザー）#

開始前に、ユーザーと共にアクセス要件を確認してください。他者の承認を待つために途中でインストールが停止されることが、このステップが1分で済むはずが1日かかる主な原因です。

GitHub#

ユーザーはを開きます設定 → 接続 → ソースコントロール (https://client.coroid.ai/settings/connections/source-control)。

GitHubアプリ：GitHubのインストール画面で、ユーザーはを選択しますリポジトリのみを選択そしてステップ1で合意されたものを選択します。インストールしたユーザーが退職してもアプリは引き続き動作し、Webhookイベントを受信します。これによりCoroidがプルリクエスト上にチェック結果を公開できるのです。ただし、トークンではGitHubのチェックを公開できません。

パーソナルアクセストークン：ユーザーはGitHub上で有効期限付きのトークンを作成し、それをCoroidポータルに貼り付けます。合意されたリポジトリに限定された細かい権限を持つトークンを使用することを推奨します。プルリクエストはトークンのオーナーに帰属し、そのユーザーのアクセス権が失われると接続が切断されます。

GitLab#

GitLabは非公開プレビュー中であり、有効化されているアカウントでのみ表示されます。パーソナルアクセストークンと連携し、そのapiスコープが必要です。もしGitLabがソースコントロール下に表示されない場合は、ユーザーにCoroidへ問い合わせるよう伝え、それに基づいて計画を立てないでください。

ブランチ保護#

Coroidは通常のプルリクエストを作成するため、ブランチ保護、必須チェック、レビュー規則が引き続き適用されます。保護機能を有効にしておくことを推奨します。もし規則で署名付きコミットやCoroidが生成できないステータスチェックが求められる場合、プルリクエストは作成されるもののマージできない状態になります。ユーザーにその旨を伝え、規則を変更しないでください。

チェック：プロバイダーがソースコントロール下に接続済みとして表示されます。実際の証拠はステップ6でリポジトリがプロジェクト一覧に表示されることです。

詳細はコードを接続する、GitHub、GitLabおよびリポジトリおよびブランチ設定。

ステップ6：プロジェクトを作成する（ユーザー）#

リポジトリごとに1つのプロジェクトを作成し、1つのリポジトリに対して2つを作成しないでください。ユーザーはプロジェクト → 新規作成 (https://client.coroid.ai/projects/new) そして、各リポジトリについて：

1. 接続済みのプロバイダーから選択するか、またはURLで接続を使用してパブリックリポジトリを追加します
2. を選択しますリポジトリモード：同期モードではCoroidがブランチをプッシュしプルリクエストを作成します。ローカルモードでは、誰かが同期を開始
3. デフォルトブランチを確認します
4. プロジェクトを作成します

チームがデフォルトブランチ以外にマージする場合、例えばdevelopのように、プロジェクトのリポジトリ設定でベースブランチを指定してください。ベースブランチが誤っていると、誰もレビューしないブランチにプルリクエストが送信されてしまいます。

リポジトリが一覧に表示されない場合、その原因はほとんどの場合以下のいずれかです：

• GitHubアプリにそのリポジトリへのアクセス権が与えられていない
• トークンのスコープが狭すぎてリポジトリを一覧表示できない
• リポジトリが接続された組織とは異なる組織に属している

詳細は最初のプロジェクトを作成とリポジトリおよびブランチの設定。

ステップ7：Coroidが検出した内容を確認#

各プロジェクトの概要画面を開いて、以下の内容を読み上げるようユーザーに依頼してくださいリポジトリ詳細情報や以下に記載されている内容セットアップを完了：

• ステータスとブランチ：指定されたリポジトリがクローンされ、合意したベースブランチに配置されます。概要画面でリポジトリがまだクローンされていないと表示される場合は、ユーザーが「リポジトリをクローン」を選択しますリポジトリをクローン。
• スタック：Coroidが検出した言語、フレームワーク、パッケージマネージャー、テストツールです。これらを準備状況チェックの結果と照らし合わせてください。初回同期後にスタックが空または誤っている場合は、そこから再度スキャンできます
• セットアップを完了：「依存関係が正常にインストールされなかった」といった項目は、ステップ2で指摘された同じ不備を示しています。ユーザーと共にそれらを解決してください

次に、ユーザーはプロジェクトの設定 → ナレッジ → コンテキストを開きます。ステップ3で作成されたメモリファイルが「リポジトリソース」に一覧表示され、有効になっている必要がありますリポジトリソースにあり、有効になっている必要があります。もし「作成と表示される場合は、そのファイルがまだ接続されたブランチに反映されていません

「プロジェクトコンテキスト設定とビルドおよびテストの設定。

ステップ8：組織設定（任意）#

ユーザーが今すぐこれらの設定を適用するかどうかを尋ねてください。いずれも問題なく利用できる既定値が用意されています

• メンバー、以下に設定 → メンバー：プルリクエストをレビューする人々で、オーナー、管理者、メンバー、またはレビュアーとして指定されます。ポリシーやプロバイダーキーを変更する必要がある人には管理者権限のみを推奨します。Professionalプランが必要です
• プロバイダーキー、以下に設定 → プロバイダーキー：組織独自のモデルプロバイダーアカウントを使用するためだけに利用します。ユーザーはポータルでキーを入力します。プロバイダー側で支出限度付きの制限付きキーを推奨します
• 他の組織からの設定：そちらで設定バンドルをエクスポートし、「設定 → データ → 設定をエクスポート」からインポートします設定 → データ → 設定をエクスポート。シークレットはプレースホルダーとして送信されるため、プレビュー内のすべての項目に注意が必要です。needsRebindプレビュー内の各項目に確認が必要です。

こちらをご覧ください：アカウントと組織を作成する、プロバイダーキーおよび設定のエクスポートとインポート。

ステップ9：Coroidへの接続（オプション）#

クライアントがリモートMCPサーバーをサポートしている場合、そのMCPサーバー経由でCoroidにアクセスできます。https://api.coroid.ai/mcp。セットアップにはこれが必須ではありませんが、プロジェクトを自分で確認し、後で作業を実行するのに役立ちます。

1. ユーザーが開くのは設定 → 接続 → Coroid MCPサーバー (https://client.coroid.ai/settings/connections/coroid-mcp）。組織で利用できない場合は、このステップをスキップしてください。
2. クライアント設定クライアントごとのコマンドが表示されます。OAuthを使用する場合、ユーザーはブラウザでアクセスを承認します。個人用アクセストークンを使用する場合は、それをアクセストークンで作成し、自身のシェル内の環境変数に保存します。値を直接確認する必要はありません。
3. 機能する最小限のアクセス権を推奨します：mcp.readセットアップを確認するために使用し、さらに mcp.work.writeタスクを作成する場合のみ使用します。トークンをこれらのプロジェクトに限定し、有効期限を設定し、自動化ポリシークライアントが無人で実行する前に

確認事項：「call」list_projects、次にget_projectステップ6で指定した各プロジェクトに対して実行し、リポジトリとブランチを確認します。

MCPには「api.coroid.aiのみを使用してください。クライアントポータルのホスト名では利用できません。

こちらをご覧ください：CoroidをMCPサーバーとして利用する。

ステップ10：最初のタスクを作成する#

新しいプロジェクトの1つで、ユーザーと共に小さな最初のタスクを作成して完了させます。良い最初のタスクとは、実際のもので小さく、既存のテストに近く、明確な完了基準があるものです。認証処理、決済、データ移行、終了の定まらない整理作業、まだ誰も決定していない設計判断を要するものは避けてください。

実装方法ではなく結果を記述します：作業完了時に何が真であるべきか、どのファイルが関連するか、触ってはいけない部分は何か。ユーザーは新規作業 (https://client.coroid.ai/work/new）、仕様を読み、計画を承認します。作業の実行にはエージェント時間が消費され、無料プランではUTC時間で1日あたり2時間まで利用可能なので、いつ実行するかはユーザーが決定します。

こちらをご覧ください：最初のタスクを実行するおよび仕様書。

ステップ11：引き継ぎ#

ユーザーにセットアップ記録を渡します：

• 各リポジトリ、そのプロジェクト、リポジトリモード、ベースブランチ
• ソースコントロールの接続方法、および接続の所有者：アプリのインストーラー、またはトークンの所有者とその有効期限
• リポジトリごとに修正された不具合、未解決の不具合（例えば開いているプルリクエストがAGENTS.md）、およびユーザーが残すことを選んだ不具合
• 設定の実施・スキップ内容、および作成された最初のタスク

その後、ユーザーを結果をレビューしてマージする最初のpull requestで得られる内容について

次へ#

アカウントと組織を作成する— 同じセットアップを手動で行う