【注意喚起】これまで作成したものを全部消せというXでのAI利用に対する流行についてパワーユーザー別の見立て

前回の記事の第二弾：AI設定を「全部消す」は全員に当てはまらない

パワーユーザーは、自分が何をAIの外側に持っているかで対応が変わる

前回の記事では、「新しいモデルが賢くなったからSkillやInstructionを全部消す」という議論について、モデルを補助するInstructionと、外部ツールを動かすためのWorkflow、Graph、Guardrailなどを区別する必要があると整理した。

今回はそこから一段進めたい。

同じ「AIをかなり使っている人」でも、そのシステム構成は大きく異なる。Claude Codeを大量のCLAUDE.mdやSkillで調整している人、Codexを複数並列で動かす人、Gemini CLIにExtensionやMCPを接続している人、自分でGraphを組んでいる人では、新モデルが出たときに見直すべきものが違う。

2026年現在の各社の方向性を確認すると、この違いは以前より明確になっている。

結論から言えば、パワーユーザーが行うべきなのは「全部消す」ことではない。

自分のシステムのどこまでをモデルに依存させているかを確認し、依存している層だけを再評価することである。

---

1．現在のAIエージェントは、すでに一種類ではない

現在「AIエージェント」という言葉には、少なくとも異なる構造が含まれている。

Claude Codeのように、モデル自身がコードベースを読み、ファイルを編集し、テストやコマンドを実行するCoding Agentがある。Anthropic自身もClaude Codeを「agentic coding tool」と位置付けている。 

Codexも同様にCoding Agentから始まったが、現在は複数エージェントの並列利用、Skills、Automations、さらにPluginsを利用した外部サービスとのWorkflowへ範囲を広げている。OpenAIによれば、現在ではCodex利用者の約20％が開発者以外であり、用途そのものがコード生成以外へ広がっている。 

Gemini CLIも単なるチャット型CLIではない。ExtensionにはMCP Server、Custom Command、Prompt、GEMINI.mdなどをまとめられる。Google自身がExtensionを機能拡張の標準的な方法として位置付けている。 

さらにLangGraphのような構成では、モデルより上位にState、Node、Edgeを持つ実行系そのものを構築する。公式ドキュメントではLangGraphを長時間動作するStateful Agent向けの低レベルOrchestration Runtimeと定義し、Durable Execution、Persistence、Human-in-the-loopなどをモデルとは別に管理している。 

したがって、これらすべてを「AIを使い込んでいる人」として一つのカテゴリーにすると、モデル更新時の対応を正しく議論できない。

---

2．パワーユーザーを「何を外部化しているか」で分類する

利用時間や課金額ではなく、システム構造から分類した方が実態を把握しやすい。

ここでは大きく5種類に分ける。

タイプ 主な制御場所 モデル更新の影響 新モデル時の主な対応

Prompt-heavy型 CLAUDE.md、GEMINI.md、AGENTS.md等 大 Ablation

Skill / Tool型 Skill、MCP、Plugin、Extension 中 InstructionとToolを分離評価

Harness型 Hook、Permission、Subagent、Runtime設定 中〜小 Interface互換性確認

Workflow / Graph型 Code、State、Node、Edge 小 Node内部のモデル依存部分を評価

外部統合型 API、DB、Storage、Automation等 モデルより環境変更の影響大 Integration Test

実際には一人のユーザーが複数タイプを併用する。

重要なのは、自分の資産をこの分類で見直すことである。

---

3．Prompt-heavy型は今回もっともAblationする価値がある

最も大きく見直すべきなのは、モデルの行動を大量の自然言語Instructionによって調整してきた環境である。

例えば、

「最初に必ず計画する」

「実装前にすべての関連ファイルを確認する」

「問題が起きたら必ず原因を5個考える」

「簡単な作業でもSubagentに委譲する」

といった指示を大量に蓄積しているケースだ。

これは過去モデルの失敗を観測し、その都度Instructionを追加してきた結果として発生しやすい。

新モデルでは、その一部をモデル自身が処理できる可能性がある。

さらに興味深いことに、現在のOpenAIのモデルガイダンスでも、長いInstructionへの追従能力が向上する一方、SkillやAGENTS.mdに曖昧・矛盾した指示が存在すると、それ自体がモデルの作業を阻害し得ると説明されている。 

Anthropic側でも同様の現象が確認できる。現在のClaudeではSubagentへの委譲能力が高く、逆に簡単な作業までSubagentを使いすぎる場合があるため、必要なら委譲を抑制する指示を追加するよう案内している。 

つまりモデルが変われば、

「以前は不足していた能力」だけでなく、「以前とは異なる過剰行動」も発生する。

このタイプでは、バックアップを取得した上でInstructionを外し、同一タスクセットを新旧構成で評価する価値が高い。

---

4．Skill / Tool型は「Skillを消す」ではなく、中身を分解する

次が非常に重要である。

現在、Skillという単語そのものが広すぎる。

例えばOpenAIではPluginsがrepeatable workflowをパッケージ化し、その内部にSkillsやAppsなどを含められる。Appsは外部データや外部アクションへの接続を担当する。 

Gemini CLIのExtensionも同様で、MCP ServerとGEMINI.mdを同一Extensionに含められる。 

つまり、一つの「Skill」の中に、

Instruction

と

Capability

が共存する可能性がある。

ここを一括削除してはいけない。

例えば、

GEMINI.md：このツールを使うときは最初に○○を考えろ

はAblation候補になり得る。

しかし、

MCP Server：外部会計システムへアクセスする

まで削除すると、モデルの能力とは関係なくCapabilityそのものを失う。

したがってSkill / Tool型のユーザーは、

Skill = Instruction + Tool + Workflow + Configuration

として分解して評価する必要がある。

---

5．外部ツール中心のユーザーは、モデルよりInterface変更を監視する

API、MCP、CLI、Database、Storage、Browser、GitHubなどを多数接続しているユーザーでは事情がさらに違う。

例えば、

要求取得 → API A → データ変換 → API B → 検証 → Storage

という処理があるとする。

モデルが高性能になったとしても、API AとAPI Bの接続仕様は消えない。

必要なのはInstructionのAblationより、

API schemaが変わっていないか

Authentication方式が変わっていないか

Tool名が変わっていないか

Parameterが変わっていないか

File pathが変わっていないか

Runtimeからアクセス可能か

Permissionが変わっていないか

というIntegration Testである。

これは現在のAI環境では特に重要になる。

Claude CodeにもPermission Mode、MCP、Session Resumeなどモデル外部の実行機構が存在する。 

Gemini CLI ExtensionもMCPやCustom Toolを独立した構成要素として扱う。 

OpenAI側でもPluginsによってCodexから外部データ・アクションを扱う方向へ拡張している。 

したがってこのタイプでは、

Model Upgrade Test

と

Runtime / Integration Upgrade Test

を別々に実施すべきである。

「モデルを変えたら動かなくなった」だけでは原因判定にならない。

---

6．Graph型では、モデルを交換してもGraphを消す必要はない

Graph型ではさらに明確である。

LangGraphではState、Node、Edgeが明示的に分離される。

Stateは現在状態、Nodeは処理、Edgeは次にどのNodeを実行するかを決める。Edgeには条件分岐を持たせることもできる。 

さらに公式ドキュメントでは、

Workflow = predetermined code path

Agent = dynamic process/tool usage

として明確に区別している。 

例えば、

START → Research → Implement → Test

というGraphがあり、

Test成功 → END

Test失敗 → Diagnose → Implement

と定義されている場合を考える。

新モデルが高性能になっても、

Test失敗 → Diagnose

というEdgeを削除する根拠にはならない。

変化する可能性があるのはDiagnose Node内部である。

旧モデルでは非常に細かい原因分析Promptが必要だったものが、新モデルでは、

Analyze the failure and identify the root cause.

程度で十分になる可能性がある。

つまりGraph型ユーザーが新モデル導入時に行うべきなのは、

Graph AblationではなくNode Ablation

に近い。

Topologyは維持し、各Node内部に存在するModel Compensationを減らして評価する。

LangGraph自体も、決定論的LogicとAgentic Behaviorを同一Workflow内で組み合わせる構成を正式にサポートしている。 

ここは現在の「全部消す」議論と明確に分離した方がよい。

---

7．長時間自律実行するユーザーは、むしろ状態管理を強化する

さらにLong-running Agentでは別の問題が出てくる。

処理時間が数分ではなく数時間、あるいは継続的Automationになれば、

「モデルがどれだけ賢いか」

だけではシステムの信頼性を決められない。

途中でProcessが停止する。

Networkが切れる。

APIがRate Limitになる。

Clientが更新される。

Workerが再起動する。

その場合、必要になるのはState PersistenceとCheckpointである。

LangGraphのAgent Serverでは、Thread、Run、Checkpoint、Long-term memoryなどを永続化し、Workerが停止してもCheckpointから再開できる構成になっている。 

これはモデル性能とは完全に異なる品質特性である。

したがってLong-running Agentを運用するパワーユーザーでは、新モデル導入時にInstructionを減らすことより、

再開可能性、冪等性、Checkpoint、Rollback、Timeout、Retry

を確認する方が重要な場合さえある。

---

8．複数Agent型では「賢くなったからAgentを減らす」可能性はある

一方で、モデル性能向上によって構成自体を簡略化できる領域も存在する。

以前、

Planner Agent

↓

Research Agent

↓

Critic Agent

↓

Implementation Agent

↓

Review Agent

と5つに分割しなければ安定しなかった処理が、新モデルでは1〜2 Agentで処理できる可能性は十分ある。

これはGraphを捨てることとは違う。

必要なNode数が減る可能性があるということだ。

現在のLangChainも、Agentをモデル＋ToolによるFeedback Loopとして扱いながら、その実行基盤自体はGraphとして構築している。 

したがってMulti-Agentユーザーは、新モデルごとに、

「このAgent分割は現在も品質向上に寄与しているか」

を評価した方がよい。

ここはAblationする価値がかなり高い。

---

9．モデルを頻繁に交換するユーザーは、モデル非依存層を増やした方がよい

Claude、GPT、Geminiなど複数モデルを用途によって切り替えるユーザーでは、さらに別の設計原則が出てくる。

外部Workflowを、

Model → Everything

としてしまうと、モデル変更のたびにシステム全体が影響を受ける。

それより、

Model ↓ Tool Interface ↓ Workflow / State ↓ External Systems

と分離する方がモデルを交換しやすい。

実際Anthropicのドキュメントにも、LLM Gatewayを利用してコード変更なしでProviderを切り替える構成が示されている。 

これは今後かなり重要になると考える。

モデルの更新速度が高い以上、最も寿命の短いコンポーネントをシステムの中心的な依存対象にすると、更新のたびに全体を再検証することになるからだ。

---

10．各タイプで「消す・残す・テストする」を変える

ここまでを実務的にまとめると、モデル更新時の対応はこうなる。

使用方法 消す／減らす候補 原則残すもの 必ずテストするもの

Prompt-heavy 旧モデル補正Instruction 必須業務ルール 同一タスクで品質比較

Skill-heavy Skill内の過剰Instruction Tool本体・必要Capability Skill単位の成功率

MCP / Plugin 冗長な利用説明 Server・Connector Schema・Auth・Permission

Hook-heavy モデル挙動補正Hook Security / Validation Hook 発火条件

Multi-Agent 不要になったAgent分割 必要な責任分離 End-to-end品質

Graph Node内の補助Prompt State・Edge・業務Topology Node＋遷移条件

Automation 冗長な判断Prompt Schedule・Trigger・State 冪等性・Retry

外部API統合 モデル補助説明 API接続・変換処理 Integration Test

Production Agent 不要なScaffolding Permission・Audit・Rollback Recovery Test

こうして見ると、全ユーザー共通の「削除リスト」は作れない。

構成によって変更対象が違うからである。

---

11．各社がAgent機能を増やしていること自体が重要

今回調べていて興味深かったのはここだった。

もし「モデルが十分賢くなればSkillや外部構造は不要になる」という方向へ本当に進んでいるのであれば、各社は外部構造を減らすはずである。

しかし実際には逆の動きも強い。

OpenAIはCodex/ChatGPTにPlugins、Skills、Apps、外部Workflowを拡張している。 

GoogleはGemini CLI Extensionsを標準的な拡張方法として整備し、MCP、Command、Contextをパッケージ化できるようにしている。 

AnthropicもClaude CodeにMCP、Permission、Session、Subagentなど、モデル外部の実行制御を持たせている。 

LangGraphはさらに明確に、Model/Toolより下ではなく、それらを制御するOrchestration Runtimeを独立させている。 

つまり現在起きているのは、

「モデルが賢くなったので外部構造が不要になる」

という単純な収束ではない。

むしろ、

モデル内部に書くべきInstructionは減らせる一方、モデル外部に置くべき実行構造は明確になってきている

と見る方が現在の製品設計と整合する。

---

12．これからのパワーユーザーに必要なのは「資産台帳」

そこで今回の考察から、一つ実務的な提案ができる。

SkillやHookを名前だけで管理するのではなく、それぞれについて依存対象を記録する。

例えば、

Asset Type Dependency 更新条件

coding-rule Model Compensation Model Model変更

github-tool Capability GitHub API API変更

deploy-flow Workflow 業務仕様 Workflow変更

delete-confirm Guardrail Security Policy Policy変更

workspace-path Environment Client/Runtime Workspace変更

retry-loop Reliability Runtime Runtime変更

という形である。

これを持っていれば、新しいモデルが出たとき、

「全部消すべきか？」

を考える必要がなくなる。

Dependency=Modelの資産だけ抽出して評価すればよい。

Clientが更新されたならEnvironment依存を確認する。

APIが更新されたならCapabilityを確認する。

業務フローを変更したならWorkflowを確認する。

Security Policyを変更したならGuardrailを確認する。

変更原因と検証対象が対応する。

---

結論：「パワーユーザー」という分類自体を更新した方がいい

今回の議論を追っていくと、「パワーユーザー」という言葉そのものに問題があることが分かる。

AIを毎日何時間も使っている人。

大量のSkillを持っている人。

Claude Codeを使っている人。

複数Agentを動かしている人。

MCPを大量に接続している人。

Graphを設計している人。

Production環境でAgentを運用している人。

これらは同じ成熟度でも、同じアーキテクチャでもない。

そのため、あるパワーユーザーが「全部消したら性能が上がった」と報告しても、その結果を別のパワーユーザーへそのまま適用することはできない。

まず確認すべきなのは、

その人は何を消したのか。

次に、

それはModel、Client、Runtime、Environment、Workflowのどこに依存していたのか。

そして、

自分の同名の資産は、本当に同じ役割を持っているのか。

である。

モデル性能が上がるほど、旧モデルを補助するInstructionは減らせる。

しかし同時に、AIが外部世界で実行できる処理が増えるほど、Workflow、Permission、Validation、Persistence、Recoveryといったモデル外部の設計は重要になる。

したがって、次世代のパワーユーザー環境で目指すべきなのは「設定を増やすこと」でも「全部消すこと」でもない。

モデルに依存する部分を最小化し、外部システムに依存する部分を明示し、変更された層だけを交換・検証できる構造にすること。

モデル更新のたびに環境全体を作り直す必要がなくなったとき、初めてAIエージェント環境が「新しいモデルを使っている状態」から、継続的に更新可能なシステムへ移行したと言える。