コードを書かない継続プロジェクトで Claude をどう使うか
チャット／Projects／Claude Code の違いと、1人・チームでの組み立て方

1結論サマリ

• 「コーディングしないから Claude Code は不要」は誤解。Claude Code の本質はコードを書くことではなく、ファイルと Git（変更履歴を記録する仕組み）を扱えること。企画書・議事録・調査メモはすべてテキストで、差分に意味がある——むしろ文書中心の仕事のほうが恩恵は大きい。
• 3者は競合しない。役割が違う。ざっくり言えばチャット＝考える場所、Projects＝前提を共有する場所、Claude Code＝成果物を確定させる場所。
• 決め手は「成果物が積み上がるか」。その場の判断やアウトプットが目的ならProjects で十分。文書が資産として溜まっていくならClaude Code。ここを取り違えると、過剰な仕組みか、後戻りできない混乱かのどちらかになる。
• Projects の弱点は「履歴が残らない」こと。ナレッジもカスタム指示も上書きで、いつ・誰が・なぜ変えたかが追えない。継続PJではこれが効いてくる。
• チームの障壁は技術ではなく参加のしやすさ。非エンジニアにターミナルを強いるのは非現実的だが、ブラウザで動く claude.ai/code を使えば環境構築なしで参加できる。「書く人」と「読む人」を分ける設計も有効。
• GitHubが使えなくても諦めなくてよい。Git と GitHub は別物で、Gitは手元で動き外部と通信しない。承認済みSaaSしか使えない環境でも、ローカルGit＋共有ドライブで価値の大半は取れる。SharePointやGoogleドライブの標準のバージョン履歴も履歴の受け皿として使える。第8章に、前提メモと意思決定ログのひな型を含む具体的な作り方を案A・B・C別に載せた。
• Projects と Claude Code は競合しない。チームで使うならProjects＝全員の入口、Claude Code＝作る人の道具という分担が素直。どちらが優れているかではなく、誰が何をするかで決まる。前提の共有はどちらも自動で（CLAUDE.md を共有フォルダに置けば全員に効く）、違うのは効く相手。
• 置き場所はクラウドでなくてよい。社内のファイルサーバーの共有フォルダでそのまま成立する——むしろSaaSですらないぶん承認の観点では最も通りやすく、同期の仕組みが挟まらないので動作も素直。

2継続PJで必ず起きる3つの問題

単発の相談では起きないが、数か月続くと確実に発生する。どのツールを選ぶかは、この3つのどれに困っているかで決まる。

3チャット／Projects／Claude Code の比較

同じ Claude でも、扱えるものと残るものが違う。継続PJで効く観点だけに絞って並べる。

4コードを書かないのに Claude Code が効く理由

名前のせいで誤解されやすいが、Claude Code が提供しているのは「プログラミング」ではなく「ファイルとGitを触れる作業環境」。この違いが分かると、企画系での使いどころが見えてくる。

4-1. 企画系の成果物こそ「差分」が意味を持つ

企画書・議事録・調査メモ・意思決定ログ——これらはすべてテキストで、「前回から何が変わったか」が本質的な情報である。

4-2. CLAUDE.md がプロジェクトの憲法になる

Claude Code はリポジトリ内の CLAUDE.md を常時読み込み、恒常的なルールとして扱う。Projects のカスタム指示と役割は似ているが、決定的な違いはバージョン管理されること。

• ルールの変更が履歴に残る。「いつからこの書き方に統一したのか」「なぜ変えたのか」が後から追える。
• ルール自体をレビューできる。チームなら、方針変更を差分として提示し、合意してから反映できる。
• 書いておけば毎回効く。用語の統一、書式、確認すべき事項、公開の可否——口頭の申し送りが仕組みになる。

4-3. 検証を自動化できる

企画系でも機械的に確認できることは多い。人間のレビューを、確認作業から判断に集中させられる。

• 必須項目が埋まっているか（目的・予算・期限・責任者）
• 用語や表記が統一されているか
• 参照しているリンクや添付が存在するか
• 公開してはいけない情報が混ざっていないか

4-4. 逆に、Claude Code が過剰になる場合

51人で回す場合の構成

1人なら合意形成のコストがないため、最初から Claude Code に寄せてよい。障壁は自分の慣れだけ。

6チームで回す場合の構成

チームの難所は技術ではなく参加のしやすさ。全員に同じ使い方を求めると、たいてい一部が脱落する。

6-1. 「書く人」と「読む人」を分ける

全員がClaude Codeを使う必要はない。役割で入口を変えるのが現実的。

6-2. 非エンジニアの参加障壁を下げる

• ブラウザ版（claude.ai/code）を使う。Claude Code はターミナルのほか、デスクトップアプリ・ブラウザ・IDE拡張から利用できる。ブラウザ版なら環境構築が不要で、非エンジニアでも入りやすい。
• 操作を覚えさせない。「コミットして」「PRを作って」と日本語で頼めばよい。Gitのコマンドを覚える必要はない。
• ルールは CLAUDE.md に集約する。人に覚えてもらうのではなく、仕組みに覚えさせる。新しく入った人も、Claudeが自動的に流儀に従う。
• 最初の1人が全部作る。リポジトリ構造とルールを整えてから招く。空のリポジトリに複数人を招くと、まず間違いなく散らかる。

7組み合わせるのが正解

3者は排他ではない。思考の段階によって置き場所を変えると、それぞれの長所が素直に効く。

8承認済みのSaaSしか使えない場合

ここまでは GitHub のような外部リポジトリが使える前提だった。しかし実務では「会社が承認したSaaSしか使えず、新規の承認を通すのが極めて難しい」という制約が頻繁にある。とくに非IT部署では、使えるものの範囲は自分で決められない。これは努力や理解の問題ではなく、単に環境の問題である。
したがってここでは「承認を取りに行く方法」ではなく、いま手元にあるもの——Claude と、社内のファイルサーバーや M365／Google Workspace と、自分のPC——だけでどこまでできるかを扱う。結論から言えば、かなりのところまでできる。

8-1. 決定的な区別：Git と GitHub は別物

ここを混同していると、必要のない諦め方をしてしまう。

8-2. 制約の強さ別・3つの現実解

どの案になるかは環境が決めるもので、上の案が偉いわけではない。案Cでも「前提が積み上がらない」問題は解決するので、自分の環境で成立するところから始めればよい。
3案の違いは「Gitを使うか」「Claude Code を使うか」の2点だけ——チームで案B・案Cを検討している場合は、8-6 で Projects と Claude Code の使い分けを整理している。

8-3. 案A の作り方（ローカルGit）

1. 作業フォルダをローカルディスクに作る。C:\work\プロジェクト名\ のように、同期フォルダの外に置く。
2. そのフォルダをGitで管理し始める。Claude Code に「このフォルダをGitで管理して」と頼めばよい。コマンドを覚える必要はない。
3. 前提メモ（CLAUDE.md）を置く。中身は次の 8-4 のひな型と同じでよい。
4. 区切りごとに「記録して」と頼む。そのとき変更の理由も一緒に伝えると、コミットメッセージに残る。
5. 確定した成果物だけを共有ドライブへコピーする。リポジトリ自体は同期させない。

8-4. 案B の作り方（共有ドライブ中心）

Gitを使わず、共有の置き場所と標準機能だけで組む。

① 置き場所を決める（クラウドでなくてよい）

② フォルダ構成を決める

③ ファイル名にバージョンを付けない

④ バージョン履歴を確認・活用する

• SharePoint／OneDrive：通常は既定で有効。ライブラリの設定でバージョン履歴の有無と保持数を一度確認しておく。ファイルの「バージョン履歴」から過去の版を開ける・戻せる。
• Google ドライブ：自動で版が残る。Googleドキュメントなら ［ファイル］→［版履歴］→［現在の版に名前を付ける］ で節目に名前を付けられる。「決裁前」「役員報告版」など、後から探す手がかりになるので必ず使う。

⑤ 前提メモを1枚作る（ここが最も効く）

⑥ 意思決定ログを追記していく

⑦ レビューは変更履歴機能で行う

• Word：［校閲］→［変更履歴の記録］をオンにしてから編集してもらう。誰がどこを直したかが色分けで残る。
• Googleドキュメント：右上の編集モードを［提案］に切り替えてもらう。提案は承認・却下を選べる。

8-5. 案C の作り方（Projects中心）

Claude Code 自体が使えない場合。やることは案Bとほぼ同じで、前提メモの置き場所が変わる。

1. プロジェクトを作る。継続PJごとに1つ。
2. カスタム指示に、前提メモ（8-4⑤）の内容をそのまま貼る。これで全員が同じ前提でClaudeに話しかけられる。
3. プロジェクトナレッジに入れるもの——過去の良い成果物を1〜2点（書式の見本になる）、主要な決定の要約、参照する社内資料。全部入れる必要はなく、毎回参照するものだけ。
4. 成果物は共有ドライブへ。会話の中に置いたままにしない。正本は必ずドライブ側。
5. 意思決定ログ（8-4⑥）は案Bと同じく共有ドライブに置く。

8-6. チームの場合：Projects と Claude Code のどちらを使うか

案B・案Cをチームで回すとき、ここが一番迷うところ。先に結論を書くと、この2つは排他ではなく、役割が違うので併用が普通。「どちらが優れているか」ではなく「誰が何をするか」で決まる。

前提：案Bでは Claude Code が共有ドライブを直接読み書きできる

人数と役割で決める

8-7. 複数人で同じファイルを触るときの注意

案B・案Cとも、共有ドライブ上の1ファイルを正本にするため、同時編集の競合が起こり得る。Gitのようにマージしてくれる仕組みはない。

• 担当を決める。1つの文書につき、その時点で書く人は1人。これが最も確実で、実務上いちばん多い運用。
• Claude Code で触る前に同期の完了を確認する。同期中のファイルを書き換えると競合ファイルが生まれる。
• Officeファイルより Googleドキュメント／Wordのオンライン版のほうが同時編集に強い。ただしClaude Code から扱うならプレーンテキスト（.md／.txt）が最も扱いやすい——差分も見やすく、競合も起きにくい。

8-8. どこまで代替できるか（まとめ）

意外に見落とされるが、SharePoint も Google ドライブも標準でバージョン履歴を持っている。Gitほど精密ではないが、企画文書ならこれで足りる場面は多い。

8-9. もし相談できる機会があれば

そもそも交渉できる立場にないことのほうが多いので、ここは読み飛ばして構わない。案A・案Bだけで実務は回る。
ただ、たまたま情報システム部門と話す機会ができたときのために、通りやすい言い方だけ書いておく。審査する側の関心は「データの流出先が増えるかどうか」にある、という一点を押さえておくと話が早い。

• 案A・案Bは「データの保存先が増えない」構成である。新しいSaaSを増やす話ではなく、承認済みのものの使い方の話——そう説明できると、相手の懸念とかみ合う。
• 実績があると話が具体的になる。構想段階より、案A／案Bで成果が出たあとのほうが説明しやすい。待っている間も前に進められるのが、この構成の良いところ。
• 「何を書かないか」を先に決めておくと強い。情報の区分を自分たちで明文化していれば、懸念に具体的に答えられる。

9その他の選択肢

3者以外にも、企画系の継続PJで効く仕組みがある。必要になってから足せばよいので、最初から全部揃える必要はない。

10段階的な導入手順

いきなり全部やらない。各段階で得られるものがはっきりしているので、途中で止めても損はない。

1. Projects を作る（30分）。まず前提の共有だけ解決する。問題①が解消し、回答のブレが減る。ここで足りるならここで終わってよい。
2. リポジトリを1つ作り、CLAUDE.md を書く（半日）。目的・前提・用語・書式・やらないこと。この時点で問題①②に効き始める。
3. 成果物をファイルとして置き、コミットを習慣にする（数週間）。理由を書いて記録する。問題③が解消し、正本が定まる。
4. 検証を自動化する（必要になったら）。抜け漏れやリンク切れを機械的に検出する。レビューが判断に集中できる。
5. チームに広げる（体制ができたら）。ルールが固まってから招く。レビュー役はブラウザだけで参加できるようにする。

11まとめ

• Claude Code はコーディング専用ではない。本質はファイルとGitを扱えることで、文書が成果物である企画系こそ相性が良い。
• 選ぶ基準は「成果物が積み上がるか」。積み上がらないなら Projects で十分。積み上がるなら、履歴と差分が持てる Claude Code。
• Projects の弱点は履歴が残らないこと。年単位のPJでは、ルールや前提がいつ・なぜ変わったかを追えないことが効いてくる。
• 役割分担：Projects＝読む場所、Claude Code＝書く場所。正本はリポジトリに置き、二重管理を避ける。
• チームの障壁は参加のしやすさ。ブラウザ版を使い、レビュー役はGitHubの画面だけで参加できるようにする。先にルール、あとから人。
• 承認済みSaaSしか使えない環境でも道はある。GitとGitHubを分けて考え、作業リポジトリはローカル、共有ドライブへは成果物のコピーだけ（同期フォルダにリポジトリを置くのは破損のもとで、Microsoftも非推奨）。意思決定ログを1枚維持するだけでも「決定の経緯が消える」問題は防げる。

各サービスの提供形態・プラン条件・機能（2026年8月時点）は変更されることがあります。導入前に公式情報で最新の条件をご確認ください。本稿は運用設計の一般的な整理であり、特定の構成を保証するものではありません。