Grokで同じ案件を何日も続けている人が、毎回の説明し直しと前提のズレで時間を失わないための記事です。

「プロジェクトを使えば返答が賢くなる」と思ったまま進めると、部屋だけ増えて、探す手間と指示の衝突が残ります。

先に結論を置きます

Grokのプロジェクトは、モデルの精度を上げる機能ではありません。

同じ前提で話し続けられるようにする機能です。

単発の質問なら、普通のチャットで足ります。「この文章を短くして」「このエラーの意味は」は、その場で終わります。会話のあとに前提を持ち越す必要がありません。

一方、何日も続く作業は別です。

企画の方針
読者の想定
すでに捨てた案
アップロードした資料の優先順位

これらを毎回最初から説明し直すと、作業時間より説明時間のほうが増えます。

プロジェクトとは、簡単に言うと、テーマごとに分けた作業部屋です。性能の話ではありません。前提を部屋に固定する話です。

公式が言っていることと、現場で起きること

公式の説明も、性能の話ではありません。

GrokのProjectsページは、カスタムワークスペースを作り、ファイルを上げて会話を賢くし、安全に共同作業すると書いています。

カスタムワークスペースとは、簡単に言うと、テーマごとに分けた作業場所です。

SpaceXAIのGrok担当であるEvan Baconは、2026年8月に「Projects for everyone, everywhere」と投稿し、中身を次の2つだと説明しています。

カスタム指示（その部屋専用の振る舞いルール）
チャット間で共有するファイル

モデルが突然賢くなる話ではありません。前提を部屋に固定する話です。

Projects for everyone, everywhere! Custom instructions and shared files across chats.

同じ趣旨は担当者の公式投稿でも確認できます。

ここを取り違えると、プロジェクトを「より賢いGrok」として使い始めます。期待が外れたあと、部屋の数だけが増えます。

混同しやすい2つの製品

混同しやすいのが、Grok BuildとGrok Botです。

Grok Buildは、開発作業を進めるエージェントです
Grok Botは、外部ツールの中で仕事を終わらせる製品です
プロジェクトは、その手前にある会話の部屋分けです

部屋が散らかっていると、同じ説明を何度も繰り返します。

普通のチャットで足りる作業と、プロジェクトにした方が楽な作業は、寿命が違います。

質問がその場で終わるなら、普通のチャットで足りる
数日〜数週間続くなら、プロジェクトにした方が楽
方針・口調・禁止事項が固定なら、部屋が要る
資料をその都度貼るだけで足りるなら、部屋は不要
部屋を作りすぎると、探す手間が増える
テーマを混ぜると、指示が衝突する

たとえば、ブログの見出し案を3つ出してほしいだけなら、普通のチャットで足ります。

同じ連載を1週間かけて構成し、過去稿のトーンを維持し、参考PDFを何度も参照するなら、部屋が要ります。

判断の軸は短くて足ります。

「この説明を来週もう一度するか」

もう一度するなら、部屋を分けます。

普通のチャットは、会話が終わるたびに前提が薄くなる

普段のGrokチャットは、会話が終わるたびに文脈が薄くなりやすいです。

次のスレッドを開くと、次のものをまた最初から説明し直すことになります。

前に渡した資料の中身
自分の好みの口調
すでに捨てた案

ここでいう文脈とは、直前のやり取りだけではありません。

この案件では何を優先し、何をやらないかという前提のことです。

単発チャットでも、同じスレッドの途中なら覚えています。切れた瞬間に、同じ説明をもう一度書く側に戻ります。

次のスレッドでやり直しになる3つの情報

やり直しになりやすいのは、次の3つです。

資料の中身（PDFの結論、過去稿のトーン、仕様の例外）
口調と形式（箇条書きか、専門用語を先に噛み砕くか）
判断基準（採用する案、捨てた案、読者の想定）

たとえば連載の第3回を書くとき、次を毎回貼り直すのは執筆ではありません。

前回は事例を3つに絞った
読者はX運用の初心者
見出しは結論先出し

質問そのものより、前提の再掲のほうが長くなる時点で、部屋を分ける判断材料になります。

私はこれを説明コストと呼んでいます。

プロジェクトがセットで残すもの

公式のProjectsがうたうのは、カスタムワークスペース、ファイル、共同作業です。

現場で効く中身は3点セットです。

カスタム指示
アップロードしたファイル
関連する会話

この3つが同じ部屋に残るので、「この企画の担当Grok」に近い状態を維持できます。

一つのプロジェクトの中では、カスタム指示・アップロードしたファイル・関連する会話がセットで残る。

Grok Buildのような開発エージェントとは役割が違います。こちらはコードを並列で進める道具ではありません。会話の前提を散らさない箱です。

残したい情報の置き場所が違います。

口調と禁止事項は、毎回プロンプトに書くか、カスタム指示に一度書くか
参考資料は、その都度添付し直すか、部屋に置いて参照させるか
関連する会話は、スレッドが分かれると薄くなるか、同じ案件の履歴として残るか

向く作業も違います。今日終わる質問は普通のチャットです。翌日以降も同じ前提が要る仕事はプロジェクトです。

判断基準は短いです。

同じ説明を2回書いたら、3回目は部屋へ移します。

逆に、一度きりの校正や単語の確認まで全部プロジェクトにすると、部屋の数が増えて探すコストだけが残ります。残すのは「来週も使う前提」だけにします。

いちばん効くのはカスタム指示である

プロジェクトの中でいちばん効くのは、カスタム指示です。

ファイルは資料を残します。会話履歴は経緯を残します。ですが、返答の形を毎回そろえるのは、部屋に書いたルールです。

一度書けば、そのプロジェクト内の新しいチャットにも効きます。

カスタム指示とは、簡単に言うと、その部屋専用の振る舞い指定です。アカウント全体の好みとは別レイヤーです。

全体設定で「丁寧語」にしていても、案件部屋では「結論を先に、根拠は3行」と上書きできます。全体設定は広く、プロジェクト指示は狭く書くほうが安定します。

効く指定は短いです。最初から長いマニュアルを置かないほうが衝突しにくいです。

たとえば次のような指定です。

このプロジェクトでは簡潔に箇条書きで返す
専門用語は先に噛み砕いてから出す
アップロードした資料を、一般知識より優先して参照する

「いつも最高の回答をして」「創造的に」は判断基準になりません。何をやめたかが見えないからです。

禁止事項を先に書くほうが効きます。

未確認の数字を補わない
資料にない機能を提案しない
他案件の口調を持ち込まない

曖昧な美辞は、部屋をまたいだときに衝突しやすいです。

弱い指定と使える指定の差は、ここにあります。

「わかりやすく書いて」ではなく、「結論1行のあと、根拠を箇条書き3点」
「初心者にも優しく」ではなく、「専門用語は初出で括弧補足してから使う」
「よく調べて」ではなく、「アップロード資料を優先。無い事実は無いと書く」
「変なことはしない」ではなく、「未確認の料金・制限を断定しない」

判断基準は2つだけです。

その文を消したら返答が崩れるか
来週の自分も同じ文を貼るか

どちらも「いいえ」なら、指示ではなくその回のプロンプトに書きます。部屋のルールは少ないほど衝突しません。

ここまで分かっても、まだ手元では止まります。

どの文を部屋に残し、どの文をその回だけに書くか。ファイルは何を置いて、何を置かないか。部屋を作る仕事と、作らない仕事の境目。ここが空のままだと、次のスレッドでまた同じ説明を書き始めます。

ファイルは「何度も貼り直す手間」を減らすために置く

プロジェクトのファイルは、賢く見せるための飾りではありません。

PDF、メモ、コード、画像を部屋に置いておくと、そのプロジェクト内の新しいチャットでも参照できます。資料を何度も貼り直す手間が減ります。

置く基準は単純です。

来週の会話でも同じ実物を見せたいか

見せたいならファイルにします。その回だけのスクリーンショットや、一度読めば捨てる下書きは、チャットに貼って終わりにします。

何でも上げると、古い版と新しい版が混ざります。

置いてよいものと、置かないものの違いはここにあります。

置いてよい：方針メモ、過去稿、仕様の抜粋、用語集、構成案、参照したい図表
置き方を分ける：完成稿と下書き、採用案と没案
置かない：パスワード、APIキー、個人情報、関係ない資料の一括投下

機密はチャットにも上げません。これはプロジェクトの機能以前の扱いです。

コードを実際に編集して進める作業は、部屋にソースを置くだけでは足りません。実行と差分管理が要る仕事はGrok Build側の役割です。

プロジェクトは前提と資料の保管、Buildは工程の実行、と切ると迷いが減ります。

向く使い方は「テーマが混ざると散らかる仕事」に限る

プロジェクトが向くのは、性能を上げたいときではありません。

テーマが混ざると会話が散らかる仕事です。

単発の質問を全部部屋に入れると、探す手間だけが増えます。

向く仕事には共通点があります。翌日以降も同じ前提が要ることです。

公式のProjectsがうたうカスタムワークスペースは、この「案件単位の隔離」に近いです。

学習用と営業文面を同じ部屋に置くと、口調も資料の優先順位も崩れます。

テーマが混ざると会話が散らかる人ほど、効きやすい。

作らなくてよい例も明確です。

単語の意味
一度きりの校正
今日中に捨てる下書き確認

これらは普通のチャットで終わります。部屋の数は少ないほど強いです。

「この説明を来週もう一度するか」が否なら作りません。

週1回しか開かない部屋は、指示が古いまま残りやすいです。

製品の切り分けもここで固定します。

外部ツールの中で仕事を終わらせたいならGrok Bot
リポジトリを編集して工程を進めるならGrok Build
会話の前提を散らさない箱がプロジェクト

同じ「プロジェクト」という言葉でも、中身は作業部屋であり、開発エージェントではありません。

状況ごとの置き場所は次のとおりです。

見出しを3つ出してほしい：普通のチャット。前提が1回で終わる
連載を1週間かけて揃える：プロジェクト。口調・資料・没案が残る
コードを実行して直す：Grok Build側。差分と実行が必要
社内ツールに結果を置く：Grok Bot側。成果物の置き場がチャット外

性能の期待を外し、前提の固定だけを目的にすると、プロジェクトは地味ですが使い続けられます。

ただし、前半だけではまだ動けません。

部屋を1つ作るか、作らないか。カスタム指示に残す文と、その回のプロンプトに残す文。ファイル名の切り方と、古い版の残し方。使っていない部屋をいつ閉じるか。

ここが空のままだと、次にGrokを開いた瞬間、また同じ前提を書き始めます。

前半で止めると、次のスレッドでも説明コストが先に来ます。口調と資料と没案が混ざったまま、部屋だけが増えます。

後半を読むと、部屋を分ける基準と、カスタム指示・ファイル・会話を残す順番を、今開いている画面の単位で判断できます。

後半：部屋を分ける基準と、指示・ファイルを残す順番