ワークフロー 1
コードベースのプロジェクトを作成する
README、主要なモジュール、パッケージファイル、設定、アーキテクチャ文書から始めましょう。GitHub を連携する場合は、インポートしたリポジトリのファイルをそのプロジェクト内にとどめてください。
試してほしいプロンプト
プロジェクトのファイルを読み、アーキテクチャを要約してください。フレームワーク、主なデータフロー、重要なディレクトリ、外部サービス、リスクのありそうな箇所を特定してください。
開発者向けプロジェクト
開発者向け AI プロジェクト
コード、ドキュメント、スクリーンショット、チケットをつなげて、AI が回答する前にリポジトリを理解できるようにします。
シンプルな考え方
AI に推測させるのではなく、プロジェクトそのものを渡しましょう。
開発者ならよくご存じの問題です。AI は単体の関数ならそれなりに書けても、回答がプロジェクトのアーキテクチャ、コーディング規約、既存のファイル、採用しているパッケージ、過去の決定事項に左右される場面になるとつまずきます。
MultipleChat のプロジェクトでは、GitHub からリポジトリのファイルをインポートし、ドキュメントをアップロードし、スクリーンショットやエラーログを追加し、技術スタックを説明するプロジェクトの指示を作成できます。そうすれば AI は、曖昧なプロンプトから推測するのではなく、回答する前に関連するチャンクを取り出せます。
アップロードするもの
まずは回答に必要なファイルから始めましょう。
AI プロジェクトがうまくいかない原因の多くは、アップロードする資料が少なすぎることです。人間の専門家に元の資料が必要なら、プロジェクトにも必要です。
GitHub リポジトリのファイル、重要なモジュール、設定ファイル
README ファイル、アーキテクチャのメモ、API ドキュメント
エラーログ、スタックトレース、失敗したテストの出力
UI のバグのスクリーンショット、製品要件、Figma のメモ
データベーススキーマ、SQL ファイル、JSON のサンプル、連携用ドキュメント
プロジェクトの指示
あなたの職種ならではの考え方をプロジェクトに伝えましょう。
同じファイルでも、指示によって回答は大きく変わります。最初に一度だけ期待する内容を設定しておけば、どのモデルも情報源、不確かな点、形式の扱い方を理解できます。
既存のアーキテクチャと命名規則に従ってください。
存在しないファイルや API をでっち上げないでください。リポジトリの文脈が不足している場合は質問してください。
小さなパッチを優先し、大規模なリファクタリングの前にはトレードオフを説明してください。
確信が持てない場合は、どのソースファイルや設定を確認すべきかを示してください。
応急的な修正、堅牢な修正、長期的なリファクタリングの選択肢を分けて示してください。
活用ガイド
まず試したい5つのワークフロー。
これは理論上の機能説明ではありません。開発者がプロジェクトを作成したら最初に試すべき、実践的なワークフローです。
ワークフロー 2
ログとソースファイルを使ってデバッグする
エラーログと関連ファイルをアップロードします。プロジェクトはコードとログをまとめて検索できるので、スタックトレースだけを貼り付けるよりはるかに効果的です。
試してほしいプロンプト
プロジェクトのファイルとこのスタックトレースを使って、考えられる根本原因を特定してください。最小限のパッチ、影響を受けるファイル、変更後に実行すべきテストを1つ示してください。
ワークフロー 3
見慣れないコードを説明してもらう
新しいリポジトリに参加したときや過去の作業を見直すときは、まずコードベースの全体像を求め、それから個々のモジュールを掘り下げましょう。
試してほしいプロンプト
このプロジェクトで認証がどのように機能しているかを説明してください。関連するファイルを引用し、リクエストのライフサイクルを説明し、セキュリティ上のリスクや不明確な前提があれば挙げてください。
ワークフロー 4
実装方法を比較する
プロジェクト内で AI Comparison や AI Collaboration を使うと、同じコードベースに基づいたさまざまな実装戦略が得られます。
試してほしいプロンプト
ロールベースの権限を追加する必要があります。このコードベースに対する3つの実装方法（最小限の変更、クリーンなアーキテクチャ、移行しやすい方法）を比較してください。リスクと影響を受けるファイルも含めてください。
ワークフロー 5
要件を開発計画に落とし込む
製品メモ、スクリーンショット、ドキュメントをアップロードし、チケット、ファイル単位の実装手順、エッジケースを求めます。
試してほしいプロンプト
アップロードした機能概要を実装計画にまとめてください。タスク、影響を受けるファイル、データモデルの変更、API の変更、UI の状態、テスト、リリース時のリスクを含めてください。
避けたい失敗
多くの人はプロジェクトを漠然と使いすぎています。
解決策はシンプルです。プロジェクトの目的を絞り、実際の資料をアップロードし、情報源に基づいた出力を求めることです。
1.バグがインポートや設定に関係している場合、ファイルを1つだけアップロードするのは避けましょう。
2.既存のパターンを先に説明させないまま、AI にモジュールを書き換えさせないでください。
3.関係のない複数のリポジトリを1つのプロジェクトに混ぜないでください。
4.テストを軽視しないでください。変更のたびに、何を実行すべきか AI に確認しましょう。
5.生成されたコードが、使っているフレームワークのバージョンに合っていると思い込まないでください。
よくある質問
開発者からよく寄せられる質問。
プロジェクトに GitHub からファイルをインポートできますか？
はい。プロジェクトでは GitHub からリポジトリのファイルをインポートし、リポジトリ・パス・ブランチなどのメタデータを保存して、プロジェクト内検索のために内容をインデックス化できます。
プロジェクトはコードベース全体を理解できますか？
重要なファイルをインポートしたときに最もよく機能します。README、パッケージや設定のファイル、主要なモジュール、スキーマ、ドキュメント、タスクに関係するファイルなどです。質問すると、検索機能が関連するチャンクを見つけ出します。
UI のバグのスクリーンショットをアップロードできますか？
はい。対応する画像ファイルには検索可能な説明文を付けられるため、スクリーンショットや視覚的な資料をプロジェクトと結び付けておけます。
開発者はプロジェクト内でどのモデルを使うべきですか？
比較してみてください。アーキテクチャが得意なモデル、パッチの書き方が得意なモデル、レビューが得意なモデルがあるかもしれません。プロジェクトでは各モデルに同じコードの文脈が渡されるので、公平に比較できます。
正しい方法で始めましょう
難しい質問をする前に、まずプロジェクトを作成しましょう。
資料をアップロードし、ルールを設定すれば、MultipleChat が ChatGPT、Claude、Gemini、Grok、AI Collaboration のために関連する文脈を取り出します。