AI Projects

すべてのAIに、考えるためのワークスペースを。

多数のファイルをアップロードし、Google DriveやGitHubを接続し、プロジェクトの指示を追加すれば、ChatGPT、Claude、Gemini、Grok、そしてAI Collaborationが同じインデックス化されたナレッジベースをもとに作業できます。Projectsは、その場限りのチャット添付を超えて、実際の業務を前に進めるための仕組みです。

PDF OCR 画像の理解 GitHubリポジトリ Google Drive コードファイル インデックス化されたチャンク

プロジェクトワークスペース

ファイル、指示、AIモデルがひとつのコンテキストレイヤーを共有します。

ソース

スキャンしたcontract.pdf

OCRが表、条項、レイアウトの手がかりを抽出します。

/src/auth/session.ts

コードは検索可能な参照資料としてインデックス化されます。

Driveのリサーチフォルダ

インポートしたファイルは、同期して再インデックス化できます。

brand-moodboard.png

画像には検索可能な説明が付与されます。

リトリーバルエンジン

チャンク04
チャンク18
チャンク27
チャンク42

どのモデルにも送信

回答には、関連するプロジェクトのチャンクだけが添付されます。

モデルにフォルダ全体をひとつのプロンプトへ詰め込む必要はありません。必要なタイミングで、必要な資料だけを受け取ります。

ChatGPT Claude Gemini Grok AI Collaboration
プロジェクトが必要な理由

チャットは一時的なもの。プロジェクトは組織の記憶になります。

実際のAI業務には、元資料、扱いにくいPDF、スクリーンショット、コード、クライアントの背景、意思決定、バージョン、そして常設の指示があります。Projectsはそれらをひとつにまとめ、新しい会話がいつも同じ作業記憶から始まるようにします。

多数のファイル

プロジェクトのライブラリを作る

チャットのたびにファイルを添付し直すのではなく、文書、スプレッドシート、画像、メモ、コードをひとつのワークスペースにアップロードできます。プランおよび安全上の制限が適用されます。

OCRを内蔵

スキャンしたPDFが使えるようになる

MultipleChatはまずOCRでPDFからテキストを抽出し、必要に応じて別の抽出方法に切り替えます。

インデックス化されたチャンク

AIは回答する前に検索します

ファイルは重なりを持つチャンクに分割され、質問のたびに検索されます。そのため、フォルダ全体をコンテキストに詰め込まなくても、最も関連性の高い箇所を回答に使えます。

ひとつのコンテキスト

どのモデルでも使えます

ClaudeからChatGPTに切り替えても、モデルを比較しても、AI Collaborationを実行しても、同じコンテキストを組み立て直す必要はありません。

仕組み

ファイルがAIのコンテキストになるまで。

ここが重要な点です。Projectsはファイルを保管するだけではありません。処理し、インデックス化し、あなたの質問にとって重要な部分を取り出します。

ステップ1

アップロードまたはインポート

ファイルを直接追加するか、Google Driveからインポートするか、GitHubリポジトリのファイルを取り込みます。ファイルはプロジェクトのメタデータとともに保存され、インデックス化の順番待ちに入ります。

ステップ2

抽出とOCR

PDF、Officeファイル、CSV、コード、テキストは、検索可能なテキストに変換されます。画像はあとから見つけられるように説明が付与されます。

ステップ3

チャンク化とインデックス化

大きなファイルは、重なりを持つチャンクに分割されます。MultipleChatはそのチャンクを個別に保存し、適切なユーザーまたはチームのプロジェクトに限定して管理します。

ステップ4

回答のために取り出す

質問すると、プロジェクトが関連するチャンクを検索し、最も適した根拠をプロジェクトの指示とともにプロンプトへ添付します。

バックエンドの詳細

チャンク単位の取得により、AIは大規模なプロジェクトライブラリでも作業できます。

プロジェクトのインデックスは重なりを持つテキストチャンクを使い、質問のたびにプロジェクトを検索して、最も一致する箇所を返します。これが「一度ファイルをアップロードした」と「ワークスペースが必要な資料をあとからも見つけ続けられる」の違いです。

約1,000文字のチャンク

長い文書は、扱いやすく検索できるブロックに分割されます。

チャンク同士の重なり

チャンクの境界をまたいでも、文脈が保たれます。

上位の一致を取得

モデルが目にするのは、無関係なファイルのノイズではなく、関連する箇所です。

対応ファイル

実務が頼りにしている、雑多な資料を持ち込みましょう。

Projectsは、PDF、画像、コードベース、スプレッドシート、プレゼンテーション、構造化データ、プレーンテキストのメモのために作られています。危険な実行可能形式や書庫形式は、安全のためブロックされます。

PDFとスキャン文書

PDF OCRは、スキャン文書やテキスト量の多い文書からテキストを抽出します。表や構造化されたコンテンツも、利用できる場合は対象となります。

文書、表計算、スライド

DOCX、XLSX、CSV、TSV、PPTXなどの形式を、検索可能なプロジェクトのナレッジに変えられます。

コードと設定ファイル

Python、JavaScript、TypeScript、React、Vue、Java、Go、Rust、C/C++、SQL、YAML、JSONをはじめ、多くのテキスト・コード形式に対応しています。

画像とスクリーンショット

PNG、JPG、GIF、WebPのファイルは検索用の説明を付与できるため、視覚的な参照資料もプロジェクトの記憶から消えません。

連携

ナレッジがすでにある場所を、つなぎましょう。

Projectsは、ワークスペースを手作業で作り直すことを求めません。Driveからインポートし、GitHubからファイルを取り込み、AIのコンテキストを情報源のそばに置けます。

Google Drive

Driveのファイルをインポートして同期

Google Docs、Sheets、Driveのファイルをプロジェクトに取り込めます。Googleネイティブのファイルはテキストとして扱いやすい形式に書き出せ、Drive PDF OCRは扱いにくいPDFを使えるテキストに変えるのに役立ちます。

Driveのインポート手動同期PDF OCRのフォールバックプロジェクトのインデックス化

GitHub

リポジトリからコードをインポート

GitHubを接続し、リポジトリのファイルを選んでプロジェクトにインポートすれば、MultipleChatがコードをインデックス化します。アーキテクチャの説明、モジュールのレビュー、実際のコードベースに基づくプロジェクトチャットに役立ちます。

リポジトリのファイルブランチのメタデータSHAの確認同期時の再インデックス化
コントロール

プロジェクトの指示が、すべてのモデルの足並みをそろえます。

トーン、対象読者、制約、希望する形式、用語、ブランドルール、コーディング規約、引用の要件、クライアントの背景といった常設の指示を一度追加すれば、プロジェクト内のどのチャットもそのルールを引き継げます。

プロジェクト指示の例

あなたはAcmeのQ3ローンチプロジェクトの中で作業しています。

回答する前に、アップロードされた製品ブリーフ、価格表、ブランドボイスガイド、顧客調査を参照してください。

簡潔で経営層向けの表現を優先してください。不確かな点は明示してください。主張がプロジェクトの資料に依拠する場合は、出典のファイル名を示してください。

トーン
ルール
出典の扱い
ユースケース別プレイブック

多くの方は、プロジェクトに何を入れればよいか分かりません。ここでお見せします。

ワークスペースが仕事に合っているとき、プロジェクトは真価を発揮します。学生には講義資料が、マーケターにはブランドとキャンペーンの背景が、弁護士には案件ファイルが必要です。これらのプレイブックでは、何をアップロードし、どんな指示を設定し、最初にどのプロンプトを実行すればよいかを説明します。

目安

人間の専門家がまじめに答えるためにファイルを必要とするなら、まずそのファイルをプロジェクトに入れましょう。

学生

講義・試験のプロジェクト

ノート、スライド、リーディング資料、評価基準、過去問をアップロードして、学習ガイド、小テスト、小論文へのフィードバックに変えましょう。

学生向けプレイブック →

マーケティングチーム

ブランド・キャンペーンのプロジェクト

ブランドガイド、製品資料、キャンペーンブリーフ、競合調査、成果メモをアップロードしましょう。

マーケティング向けプレイブック →

法務チーム

案件ファイルのプロジェクト

契約書、証拠資料、スキャンしたPDF、時系列メモ、調査資料をアップロードして、出典に基づく法務レビューを行いましょう。

法務向けプレイブック →

エンジニア

コードベースのプロジェクト

GitHubのファイル、READMEドキュメント、スキーマ、スタックトレース、スクリーンショットを接続して、AIがリポジトリを理解できるようにしましょう。

コーディング向けプレイブック →

コンサルタント

クライアント案件のプロジェクト

ブリーフ、調査資料、メモ、スプレッドシート、過去の資料をアップロードして、クライアントにそのまま出せる提言にまとめましょう。

コンサルティング向けプレイブック →

研究者

文献・出典のプロジェクト

論文、メモ、データセット、下書きをアップロードして、文献マトリクスと出典に基づく統合をつくりましょう。

リサーチ向けプレイブック →

プロダクトチーム

機能・ロードマップのプロジェクト

ユーザーフィードバック、PRD、仕様書、スクリーンショット、分析メモをアップロードして、より良いプロダクトの意思決定を下書きしましょう。

プロダクト向けプレイブック →

セールスチーム

アカウントのプロジェクト

商談メモ、アカウント調査、製品資料、提案書をアップロードして、具体的なフォローアップや反論への対応に活かしましょう。

セールス向けプレイブック →

コンテンツチーム

編集・出典のプロジェクト

編集基準、出典のPDF、インタビュー、下書き、ブランドの実例をアップロードして、出典に基づくコンテンツワークフローをつくりましょう。

コンテンツ向けプレイブック →

信頼のレイヤー

行き当たりばったりのアップロードではなく、本気のファイルのために。

バックエンドは、アップロードされた資料を信頼できない参照データとして扱います。ファイルは検証され、危険な拡張子はブロックされ、インデックス化はユーザーまたはチームの範囲に限定されます。取得されたチャンクはラップされ、ファイルの内容が命令ではなく出典であることをモデルが理解できるようにします。

ファイルの検証

プロジェクトへのアップロードでは、保存とインデックス化の前に、ファイル形式とコンテンツのシグネチャを確認します。

Azureストレージ

プロジェクトのファイルは、インデックス化される前に、メタデータとライフサイクルの状態とともに保存されます。

プロンプトインジェクション対策

取得したファイルの内容は信頼できない参照資料として扱われるため、アップロードされたファイルが黙ってAIに指示を与えることがないようにしています。

チームを考慮したスコープ

個人とチームのプロジェクトチャンクは別々のスコープで管理されるため、検索は適切なワークスペースの中に留まります。

ベストプラクティス

目的ごとに、ひとつのプロジェクトを。

元資料がひとまとまりになっているとき、プロジェクトは最もうまく機能します。ひとつのクライアント、ひとつの製品、ひとつの研究テーマ、ひとつのコードベース、ひとつのキャンペーン、ひとつの法務案件。そうすることで取得の精度が保たれ、無関係なコンテキストが減ります。

01

まず出典をアップロード

最終的な成果物を求める前に、文書、コード、画像、スプレッドシートをプロジェクトに渡しましょう。

02

指示は一度書けば十分

対象読者、トーン、制約、出典の使い方に関する要件を、プロジェクト単位で定義しましょう。

03

適切なAIモードを使う

ひとつのモデルとチャットする、複数のモデルを並べて比較する、あるいはAI Collaborationにより強固な回答を統合させる、といった使い分けができます。