8月10日、The AI Thinkerが「How to organize Claude Code for product work」と題した記事を公開した。Claude Codeをプロダクト業務で継続的に活用するために必要なのは「うまいプロンプト」ではなく「うまいファイル管理」だ——この主張を軸に、フォルダ構成の設計からセットアップ手順、継続的に効いてくる実践まで、PMが今日から使えるワークフローが詳しく解説されている。
「うまいプロンプト」より「うまいファイル管理」
記事の核心はこの一文に集約される。
基本を超えたところでは、Claude Codeの結果はプロンプトの上手さではなく、ファイル管理の上手さに依存し始める。
良いプロンプトは1セッションを改善する。良いファイルはそれ以降のすべてのセッションを改善する。
チャットモード（ブラウザやデスクトップアプリ）でClaudeを使っていると、会話は毎回ゼロからスタートする。前回アップロードした戦略ドキュメントは消え、丁寧に説明したコンテキストはスクロールしても見つからないスレッドの中に埋もれる。チャットは思考の場としては優秀だが、蓄積の場としては最悪だ、と著者は断言する。
Claude Codeは同じClaudeを「マシン上のフォルダ」に移したもの。コンテキストはファイルとして永続し、繰り返し作業はコマンドで呼び出せる「スキル」として登録でき、成果物はメッセージではなくドキュメントとして残る。
スターターワークスペースの構造
著者は自分のワークスペースをテンプレート化してGitHubで公開している。**claude-code-pm-starter**がそれだ。フォルダ構成、コンテキストファイルのテンプレート、サンプルプロジェクト、5つのスキルがあらかじめ含まれており、技術的な背景がなくても使い始められるよう設計されている。
ワークスペースの主な構成要素は以下の通りだ。
context/フォルダ：会社のプロダクト、ユーザー、競合、作業スタイルなど、会社に関するあらゆる情報を集約するprojects/フォルダ：プロジェクトごとに1フォルダ。タスクと成果物を分離して管理するoperations/フォルダ：スキルなどの運用ファイルを格納する- **
CLAUDE.md**：ワークスペース全体のマップファイル。Claude Codeが起動時に読み込み、どこに何があるかを把握する - スキル：ステータス更新、PRDレビュー、インタビュー合成など、繰り返し発生する作業を1スキル1タスクで定義したファイル群。元記事に記載のパス表記に従い、
operations/配下に格納される
セットアップは6ステップ
記事では具体的なセットアップ手順が示されている。前提条件として有料のClaudeプランが必要だが、それ以外は無料だ。
- VS Codeをインストールする（IDE＝統合開発環境。コードを書かなくても、ファイルパネルでワークスペースを視覚的に確認するために使う）
- GitHubからZIPをダウンロードする（gitアカウント不要）
- VS CodeでフォルダをOpenし、ターミナルを右側に移動させる（左にファイル一覧、右にClaudeという配置にすると、コマンドラインではなく「隣に座る同僚」のように感じられる、と著者は表現している）
- 基本コマンドを覚える
- セットアップスキルを実行する（インタビュー形式で回答するとコンテキストファイルが自動的に埋まる）
- 実際のタスクを渡す（例：タスクファイルからステータスアップデートを作成させる）
claudeとタイプしてEnterを押すだけで、Claude Codeはフォルダ内で起動し、マップファイルを読み込み、最初のメッセージから「どこに何があるか」を把握した状態で動き始める。
継続的に効いてくる6つのプラクティス
記事後半では、このシステムを「複利的に機能させる」ための6つの実践が紹介されている。以下にその全容を整理する。
フィードバックのファイル化：一度与えたフィードバックは、理由とともにファイルに記録する。同じフィードバックを二度しなくて済む仕組みで、著者はこれを「修正がすべて永続的になる」と表現している。
GitHubとのネイティブ連携：Claude Codeは追加のコネクタなしにGitHubと直接やり取りできる。プロダクトが使っているリポジトリを引っ張ってきて「この機能フラグは実際に何をしているか」を質問したり、自分のワークスペースをプライベートリポジトリにプッシュしてチームメンバーと共有したりできる。これはチャットモードにはない機能だ。
スキルの育成：繰り返し実行するタスクは都度プロンプトを打つのではなく、スキルとして定義・登録していく。使うたびにスキルを磨き直し、チーム全体の生産性に還元する設計だ。
コンテキストの継続的な更新：
context/フォルダの内容は一度書いて終わりではなく、プロダクトや組織の変化に合わせて更新し続けることが前提となっている。陳腐化したコンテキストはむしろ誤出力のリスクになる。タスクとアウトプットの分離：
projects/フォルダ内でタスク定義ファイルと成果物ファイルを明示的に分けて管理する。何を依頼したかと何が生成されたかが混在しないため、後から参照・修正がしやすい。ワークスペースのチーム共有：プライベートGitHubリポジトリにワークスペースをプッシュすることで、コンテキストやスキルをチームで共有できる。個人の生産性向上にとどまらず、チームの標準的な作業基盤として機能させることが最終的なゴールとして位置づけられている。
PMだけでなく「コンテキストが重い仕事」全般に使える
著者は「PM向け」としながらも、同じアーキテクチャはデザインリードのリサーチライブラリ、データチームのメトリクス定義、創業者の何でもフォルダにも適用できると明示している。要はコンテキストの量が多く、繰り返し作業が発生するあらゆる知的業務に有効な構造だ。
Anthropicの公式ドキュメントはエンジニア向けに書かれており、PMやデザイナーが「どうファイルを整理するか」を学べる既存のリソースは少ない。この記事とスターターワークスペースは、その空白を埋めることを意図している。
詳細はHow to organize Claude Code for product workを参照していただきたい。
