見出し画像

【仮説】AI時代はProjectが資産になる

KAWAI

AIエージェント時代に育てるべきものは、汎用Skillでも、全体Memoryでもありません。

育てるべきものはProjectです。

この記事は全文無料（期間限定）で閲覧できます。

見出し画像はAIで生成しました。
プロンプトはこの記事に掲載中。



モデル企業は記憶を強化したい

AIモデル提供企業は、SkillsやMemoryを強化したがります。

これは陰謀論ではなく、プロダクト設計として自然な流れです。

ユーザーの作業履歴、好み、ファイル、会話、指示、ワークフローを製品内に蓄積できれば、そのAIは使うほど便利になります。

OpenAIはChatGPTのProjectsを「長く続く作業を一つの場所へまとめる専用スペース」と説明しています。

Projectsにはチャット、ファイル、指示、関連コンテキストを置けます。

さらにProject memoryによって、同じProject内の会話やファイルを参照し続けられます。

AnthropicもClaudeのProjectsで、チャット履歴とナレッジベースを持つ自己完結型ワークスペースを提供しています。Project Knowledgeには文書、テキスト、コードなどを入れられ、容量が大きくなるとRAGで最大10倍まで拡張される仕組みもあります。

ClaudeのSkillsも同じ方向です。公式説明では、Skillsは指示、スクリプト、リソースを含むフォルダで、Claudeが必要に応じて動的に読み込みます。特定タスクの再現性、速度、一貫性を高めるための仕組みです。

ここまでは便利です。問題は、便利になるほど切り替えコストが上がることです。

【先着100名限定】Claude Codeデザインパターン
〜フォルダ構造・Skills・database・コンテンツ生成フロー全公開〜

【超初心者OK】Claude Code 個別サポート
※早割先着10名様分は完売しました。


便利さはロックインになる

AIのロックインは、モデル性能ではなく文脈で起きます。

モデルは乗り換えられます。APIも乗り換えられます。

UIも乗り換えられます。

しかし、自分の作業履歴、好み、顧客理解、過去の判断、プロジェクト固有の文脈が一つのサービス内に沈むと、乗り換えにくくなります。

これはSaaSの定石です。

CRMに顧客データが溜まるほど、別CRMへ移れなくなります。

Notionに社内Wikiが溜まるほど、別ツールへ移れなくなります。

Figmaにデザインシステムが溜まるほど、別ツールへ移れなくなります。

AIでも同じことが起きます。

Memoryが育つほど、そのAIは「自分のことを分かっている」ように見えます。

Skillsが増えるほど、そのAIは「自分の仕事に合っている」ように見えます。

Project内のファイルと会話が増えるほど、そのAIから離れにくくなります。

だから、AIモデル提供企業がMemory、Skills、Projectsを強化するのは合理的です。

ユーザーに長く使ってもらえるからです。

切り替え機会を減らせるからです。

サブスクリプション継続、利用量増加、チーム展開につながるからです。

ただし、ユーザー側が同じ方向に乗る必要はありません。


ユーザー側の最適解はProject First

ユーザー側の最適解は、AIサービス側のMemoryを育てることではなく、自分のProjectを育てることです。

Projectに、目的、背景、判断基準、ターゲット、データ、素材、過去成果物、運用ルールを集約します。

Projectとは、単なるフォルダではありません。

事業、案件、記事群、講座、プロダクト、広告運用、顧客支援など、成果物を生み続ける単位です。

AIエージェントにとっての作業環境であり、人間にとっての意思決定資産です。

Projectに入れるべきものは、次のような情報です。

  • 目的

  • 顧客

  • ターゲット

  • 競合

  • 過去施策

  • 成果指標

  • アナリティクス

  • ブランドルール

  • 禁止表現

  • 成果物テンプレート

  • 使うコマンド

  • 検証手順

  • 過去の失敗

  • 判断ログ

これらをProject側に置いておけば、ClaudeからCodexへ切り替えても、Gemini CLIへ切り替えても、ローカルLLMへ切り替えても使えます。

AIエージェントが変わっても、Projectが残るからです。


汎用Skillを増やしすぎると弱くなる

汎用的に使えるSkillを増やしすぎるのは、あまり強くありません。

理由は、汎用Skillほど判断が薄くなるからです。

たとえば「記事を書くSkill」は便利です。

しかし、どの顧客に向けるのか、どの収益導線に接続するのか、過去記事とどう差別化するのか、どの表現がブランドに合わないのかまでは、Projectを読まないと分かりません。

「広告を作るSkill」も同じです。

広告制作の一般論は書けます。

しかし、本当に必要なのは、商材の粗利、LTV、獲得単価、ターゲットの不安、過去クリエイティブの勝ち負け、媒体ごとの反応です。

これはSkillではなくProject dataです。

Skillは、作業手順を再利用するために使うものです。

Projectは、判断材料を蓄積するために使うものです。この2つを混ぜると、すぐに破綻します。

汎用Skillに何でも詰め込むと、別案件の文脈が混ざります。

全体Memoryに何でも覚えさせると、個人の好みと案件固有の判断が混ざります。

結果として、AIはそれっぽく賢くなりますが、成果物の精度は落ちます。


README.mdを中心に置く

Project Firstで重要なのは、README.mdを中心に置くことです。

CLAUDE.mdやAGENTS.mdを否定する必要はありません。

ただし、それらを主戦場にしないほうがいいです。

CLAUDE.mdはClaude Codeに強い形式です。

AGENTS.mdはCodexに強い形式です。

どちらも便利ですが、特定エージェント寄りの入口です。

Projectの中心説明をそこに置くと、そのエージェントの都合にProjectが引っ張られます。

README.mdは、人間にもAIにも読める中立的な入口です。

GitHub、ローカルフォルダ、社内Wiki、ドキュメントサイト、どこでも自然に読まれます。

ClaudeでもCodexでもGeminiでも、README.mdを読む指示は通しやすいです。

だから、CLAUDE.mdやAGENTS.mdには長く書かなくていいです。

書くことは短くていいです。

# Instructions

このProjectで作業する前に、必ずREADME.mdを読んでください。
README.mdにある目的、制約、判断基準、検証手順を最優先してください。

実際のルール、背景、データ、判断基準はREADME.mdとProject配下のdocs、data、assets、scriptsへ置きます。

エージェント別ファイルは、Project本体への導線に徹します。


ProjectにSkills、Memory、Dataを入れる

Project Firstの設計では、Skills、Memory、DataをProjectに入れます。

ここで言うSkillsは、サービス横断で使う巨大な個人Skillではありません。

そのProjectでだけ使う小さな手順です。

たとえば広告案件なら、Project内に「勝ち訴求抽出」「広告レビュー」「LP改善」「媒体別リライト」のような手順を置きます。

記事メディアなら「過去記事検索」「タイトル案生成」「定型CTA挿入」「事実確認」のような手順を置きます。

Memoryも同じです。個人全体のMemoryに「この顧客は◯◯」と覚えさせるより、Project内のREADMEやdocsに書きます。

そうすれば、別AIでも読めます。チームメンバーも読めます。

履歴管理もできます。

DataもProject側に置きます。

アナリティクスCSV、顧客インタビュー、ターゲット仮説、過去投稿の反応、広告レポート、売上データ、制作素材をProjectに入れます。

AIの記憶ではなく、ファイルとして残します。

この設計にすると、AIは道具になります。Projectが資産になります。


モデル企業が言いにくい戦略

この戦略を、AnthropicやOpenAIが強く言う可能性は高くありません。

理由は単純です。

自社サービス内のMemory、Skills、Projectsが育つほど、ユーザーはそのサービスを使い続けやすいからです。

もちろん、OpenAIもAnthropicもデータ管理やProject機能を便利にするために開発しています。

公式説明でも、Projectsは文脈整理、長期作業、共同作業を助ける機能として語られています。

それ自体は正しいです。

ただし、企業側の最適化とユーザー側の最適化は一致しません。

企業側は、自社AIの中に文脈が集まるほど強くなります。

ユーザー側は、自分のProjectに文脈が集まるほど強くなります。

ここを混同すると、AIを使っているつもりで、AIサービスの中に自分の業務資産を預け続けることになります。便利ですが、弱いです。


実務でのProject構成

私なら、Projectを次のように作ります。

project-name/
  README.md
  CLAUDE.md
  AGENTS.md
  docs/
    strategy.md
    target.md
    offer.md
    brand.md
    operations.md
  data/
    analytics/
    interviews/
    reports/
  assets/
    references/
    images/
    prompts/
  skills/
    article.md
    ad-review.md
    research.md
  memory/
    decisions.md
    learnings.md
    failures.md
  scripts/
    collect-data.py
    validate-output.py

README.mdには、Projectの目的、成果物、対象読者、収益導線、重要指標、フォルダ構成、AIに読ませる順番を書きます。

CLAUDE.mdとAGENTS.mdには、README.mdを読む指示だけを書きます。

docsには、背景情報と判断基準を置きます。dataには、分析用の一次データを置きます。assetsには、素材やプロンプトを置きます。skillsには、そのProject専用の作業手順を置きます。memoryには、意思決定ログと学習履歴を置きます。

この形なら、Claude CodeでもCodexでも使えます。

ChatGPT Projectsへアップロードしても使えます。

ローカルLLMへ渡しても使えます。人間が引き継いでも読めます。


結論

AIモデル提供企業は、MemoryやSkillsを強化していきます。

それは自然です。

ユーザー体験が良くなり、継続利用が増え、切り替えコストも上がるからです。

しかし、ユーザー側が育てるべきものはAIサービス内の記憶ではありません。

Projectです。

ProjectにSkills、Memory、Dataを入れ、README.mdを中心に説明し、エージェント別ファイルは入口にします。

これからのAI活用は、どのモデルを使うかより、どこに文脈を貯めるかで差が出ます。

モデルは変わります。UIも変わります。料金も変わります。Projectだけが、自分の側に残ります。

Projectこそ全てです。


参考情報

【先着100名限定】Claude Codeデザインパターン
〜フォルダ構造・Skills・database・コンテンツ生成フロー全公開〜

⬇️ 1on1で密に教えて欲しい方はこちらがオススメです。

【超初心者OK】Claude Code 個別サポート
※早割先着10名様分は完売しました。

⬇️ 法人研修をご希望の方はこちら

Claude Code 法人研修 無料相談はこちら

noteメンバーシップに参加すると700本以上の記事が読み放題です。

お問い合わせ・個別相談・法人研修のご依頼

AI活用・キャリア戦略 個別相談

書籍「AIでゼロからデザイン」好評発売中

#AI #生成AI #AIエージェント #AI時代 #AI活用 #AI人材 #AI研修 #AIツール #Claude #ClaudeCode

ここから先は

0字

1,000本以上の記事が読み放題。AI × デザインを主軸に、独自の視点やノウハウをお届けします。A…

LIGHT（読み放題）

¥980 / 月
あと10人募集中

STANDARD（読み放題 + チャット相談）

¥2,980 / 月
あと1人募集中

PREMIUM（STANDARD + 月次1on1）

¥7,980 / 月
あと2人募集中
ログイン

この記事が気に入ったらチップで応援してみませんか？