エージェントはあなたのコードとリポジトリ内の指示ファイルを読み取ります。コンテキストこれらのメモリファイルをプロジェクトノート、生成されたコンテキスト、参照情報と組み合わせます。
ここに含まれる内容の背景については、以下をご覧ください。プロジェクトコンテキスト「概念」セクションで説明されており、このページではその管理方法について解説します。
リポジトリのメモリファイル
開く設定 → ナレッジ → コンテキストを開き、以下の項目をご確認ください。リポジトリソース。Coroidは接続されたリポジトリからこれらのファイルを読み取ります：
AGENTS.mdリポジトリルートにある：汎用エージェント指示CLAUDE.mdリポジトリルートにある：Claude指示GEMINI.mdリポジトリルートにある：Gemini指示.cursor/rules：Cursorのプロジェクトルール。該当ディレクトリ内の.mdcルールファイル（サブフォルダを含む）または従来の単一ファイル
これらは一般的にメモリファイルと呼ばれます。有効な内容は作業開始前にエージェントのプロジェクトコンテキストに含まれます。名称が特定のモデルに限定されることはありません。有効なソースはすべてCoroidのエージェントで統合されます。
既存のファイルには「編集」アクション、推定トークン数、エージェントがこれらを利用するかどうかを制御するスイッチが表示されます。明示的に無効にしない限り、ソースは有効な状態です。複数のファイルが重複または矛盾する場合は、エージェントが参照すべきソースのみを有効にし、他を無効にしてください。
GitHubまたはGitLabリポジトリが接続されたプロジェクトで編集を保存すると、プロジェクトのpull requestベースから新しいブランチが作成され、変更内容を含むpull requestが開きます。Coroidはデフォルトブランチにコミットせず、pull requestがマージされた後にエージェントが新しいバージョンを読み取ります。Coroidがホストするリポジトリを持つプロジェクトでは、コミットが行われます。保存前にエディタにその旨が表示されます。
CoroidはCursorが適用する方法でCursorのルールを読み取ります：
| ルール | エージェントが取得する内容 |
|---|---|
alwaysApply: true | ルール全体 |
globsセット | 適用対象ファイルを含むルール全体 |
一部のみdescription | ルールのパスと説明。関連する場合にエージェントが読み取るための情報です。 |
| いずれも含まれない | 何も含まれません：Cursorは誰かが言及した場合にのみこれを適用します。 |
通常の.mdファイルは.cursor/rules内にあるため無視されます。Cursorはこれを無視するからです。ディレクトリ内のルールはリポジトリで編集されるため、該当行には「編集」アクションがありません。
作成とは、ファイルがCoroidのリポジトリチェックアウト内に存在しないことが確認されたことを意味します。読み取りに失敗した場合、ページには「再試行」が表示されます。アクセス障害が必ずしもファイルが欠落していることを意味するわけではありません。接続されたリポジトリのブランチにファイルがコミットされているかを確認してください。タスク実行時にはエージェントがタスクのチェックアウトを読み取ります。そのため、該当ブランチ上の指示ファイルの変更がタスクに反映されます。
有効なメモリファイルは、リポジトリのMarkdownを@pathで読み込むことができます。例えば@AGENTS.md内のCLAUDE.mdまたは@docs/conventions.md。パスは参照元のファイルを基準に解決されます。Coroidはネストされたインポートを追跡し、循環参照を防ぎ、各ファイルと同一の指示内容を一度だけ含めます。コード例やメールアドレス内の参照はそのまま残されます。リポジトリ外の参照は読み込まれず、明示的に無効にされたリポジトリソースを回避するインポートもできません。
自動で検出されるのは指定されたソースのみです。ネストされたAGENTS.mdは@インポートで含めることができますが、そのディレクトリの範囲は推測されません。
アプリコンテキスト
「アプリコンテキスト」の下にはCoroidに保存された指示や参照情報があります。手動で入力したメモや生成されたプロジェクトコンテキストは、リポジトリファイルとは別に有効/無効を切り替えられます。Git外に属する情報にはこれらのエントリを利用してください。
コンテキストの追加
「コンテキストを追加」を選択してエントリを追加します。各エントリにはタイトルと本文があり、後で編集や削除が可能です。
良いエントリは短く、具体的で、永続性があります。アーキテクチャの決定事項、スタイル規約、APIの契約、所有権の境界、明確な禁止事項などが該当します。オンボーディングの説明やリポジトリからすでに明らかな内容は含めないでください。
エントリは分けて名前を付けてください
トピックごとに1つのエントリとし、内容を表すタイトルを付けます。「エラーハンドリングの規約」や「凍結モジュール」は検索可能ですが、両方を含む「メモ」という単一のエントリでは検索できません。
これは重要です。コンテキストは作業内容に応じて選択的に読み込まれるためです。詳しくは段階的スキルをご覧ください。適切に分けたエントリなら、タスクに合ったものが正しく読み込まれます。
参照
文書形式のエントリに加えて、参照先となるリンクやドキュメントを添付できます。公式なコピーがWikiやデザインツール内に存在し、古くなる可能性のある重複コピーを作成したくない場合に利用してください。
タスクごとのコンテキスト
プロジェクト全体に適用されるコンテキストは、そのプロジェクト内のすべての要素に影響します。特定の作業に関連する資料（チケット、顧客レポート、設計文書など）については、該当するタスクに直接添付してください。プロジェクトコンテキストに記載されたタスク固有のメモは、今後の他のタスクで不要なノイズとなってしまいます。
正確さを保つ
古くなったコンテキストは、コンテキストが欠如している場合よりも深刻な問題です。なぜなら、エージェントはそれを公式な情報として扱うからです。規定が変更された際には、コードの変更と同時にエントリも更新してください。
既存の内容をレビューする
時折、新参者になったつもりでコンテキストを読み直してみてください。エントリは蓄積されていき、1年前に終了した移行作業中に記載された内容は、現在では誤解を招く情報となっている可能性があります。