はじめに

最近、Anthropic 関連のニュース記事を読んでいて、「Environment-centric（環境中心）」という言い回しに目が留まりました。出典は BigGo ファイナンスの解説記事「AI 競争の勢力図を変える: Anthropic の『環境中心』設計思想が導く約47.6兆円の成長」です。

「環境中心（environment-centric）」「Memory Moat」「3 つの柱」といった整理は、Anthropic 公式が出している用語ではなく、上記の BigGo 記事による解説上のフレーミングと、それを受けた筆者の整理 です。Anthropic 公式ドキュメントや公式ブログにこのままの形で明文化されているわけではない点に留意してください。本記事はあくまで「BigGo 記事の整理を起点に、Anthropic の各プロダクトを横断して読み直してみる」試みとして読んでいただけたらと思います。

この記事の中で示されている整理が、Anthropic の最近のプロダクト群、つまり Claude Code・Agent Skills・MCP（Model Context Protocol） の方向性をきれいに説明していて、自分自身も普段これらを使っていて何となく感じていた「Anthropic は LLM そのものではなく、その周囲の『環境』を整えにかかっている」感覚と一致するものでした。

本記事では、この「環境中心」設計思想とは何かを、BigGo 記事と Anthropic の公式情報を参照しながら、自分なりに読み解いてみます。あくまで一つの視点として読んでいただけたらと思います。

なお、本記事は AI モデルの優劣論ではありません。「モデル性能をどう測るか」ではなく、「モデルを『何の中で』動かすか」 という、設計レイヤーの話として整理していきます。

1. 「環境中心」とは何か

BigGo の記事では、Anthropic のアプローチをこう要約していました。

知識を外部のスキルフォルダに分散させ、文脈をファイルシステムに永続化し、接続をプロトコルで標準化する

少し噛み砕くと、次のような考え方になります。

軸	モデル中心の発想	環境中心の発想
知識の置き場所	できるだけプロンプトに詰め込む	外部のスキルフォルダに分散
文脈の保持	コンテキストウィンドウに依存	ファイルシステムに永続化
外部接続	プロダクトごとに専用統合	MCP のような共通プロトコルで標準化
AI の置き場所	IDE のプラグイン	ターミナルや OS の上に直接配置

つまり、AI の「賢さ」をモデルの内側だけで完結させるのではなく、モデルの外側にある環境（ファイルシステム・スキルライブラリ・プロトコル） に責任を分散させていく、というのが「環境中心」のニュアンスです。

ここで一つ留意しておきたいのは、これは「モデル開発を諦めた」という話では当然なくて、Anthropic 自身は Opus / Sonnet / Haiku といったモデル系列の改善も並行して進めている点です。あくまで 「モデルの賢さに加えて、環境側のレバレッジを取りに行っている」 と理解するほうが正確だと思います。

2. なぜ「環境中心」なのか - モデル性能だけでは差別化が難しくなった

ではなぜ、Anthropic はわざわざ環境側にも力を入れ始めたのでしょうか。

BigGo 記事の中で示唆されていたのが、「モデル性能はオープンソース化を含む競合の追い上げで急速に追いつかれる」 という構造的な事情でした。これは確かにここ数年の流れを見ていれば実感のある話で、フロンティアモデルが半年から1年で別社にキャッチアップされる、という状況が常態化しつつあります。

その上で、もう一段だけ深く見ると次のような順序になっていそうです。

モデルの絶対性能 だけで差をつけ続けるのは難しい
ただし、モデルが置かれる 「環境」 はそれぞれの組織で固有のものになり得る
環境側を標準化・拡張可能な形で設計しておけば、「自社モデルが置かれた環境」自体が競争優位 になる

BigGo 記事はこれを 「Memory Moat（記憶の堀）」 という言葉で表現していました。組織が長年の運用を通じて蓄積したスキルライブラリやファイルシステム構造、エージェント同士のやり取りの履歴は、コピーが難しい資産になる、という発想です。

ここは断定するつもりはないのですが、過去のクラウド競争で「単発の API 性能」より「そのクラウド上に積まれたデータと運用ノウハウ」が乗り換えコストになっていった構図を思い出します。AI でも似た現象が起きるなら、確かに環境側の標準化は早く動いておく価値があるはずです。

3. 3 つの柱：Claude Code / Agent Skills / MCP

BigGo 記事で「環境中心」を支える 3 つの柱として挙げられていたのが、Claude Code・Agent Skills・MCP です。それぞれが「環境のどの部分を整えるか」に対応していて、整理するときれいに役割が分かれます。

柱	担当する「環境」	何をしているか
Claude Code	OS / ターミナル / シェル	AI を IDE のプラグインから「ターミナルの第一級住民」へ昇格させる
Agent Skills	ファイルシステム	知識・手順・プロンプトをフォルダ構造としてバージョン管理可能にし、必要に応じて段階的に読み込む
MCP	外部サービス・API への接続	「ツール」「リソース」「プロンプト」を共通プロトコルで定義し、製品横断で再利用可能にする

3-1. Claude Code：ターミナルへの直接配置

Claude Code は、IDE の拡張機能としてではなく、ターミナルから直接立ち上げて作業させる前提で設計 されています。これによって AI は「補助役」から「作業者」のレイヤーに上がり、git・npm・cargo・各種 CLI ツールを直接触る前提でワークフローを組めるようになります。

逆に言うと、AI を IDE プラグインに閉じ込めている限り、AI が触れる環境は IDE の中に閉じてしまう、ということでもあります。本番のオペレーション環境はターミナルとシェルの上にあるので、そこに直接置くという判断は、「AI に環境そのものを操作させたい」 という設計思想にとって自然な帰結だと感じます。

3-2. Agent Skills：ファイルシステムを外部メモリ化

Agent Skills は、AI に渡したい知識や手順を SKILL.md などのフォルダ構造で管理 し、必要に応じてロードする仕組みです。重要なのは、「全部一度にコンテキストへ詰め込まない」 という設計になっている点です。

これは Anthropic が提唱する Progressive Disclosure（段階的開示） という考え方に直結していて、必要な情報を必要なタイミングだけロードする運用にすることで、

コンテキストウィンドウの圧迫を防ぐ
スキル単位でバージョン管理できる
用途別に共有・再利用できる

といった利点が出てきます。私自身、Skills を業務で使っていてもっとも効くのは、「組織や個人ごとにカスタマイズした手順を、フォルダとしてリポジトリに置けること」 だと感じています。

3-3. MCP：接続を標準化する

MCP（Model Context Protocol）は、AI モデルと外部サービスを繋ぐためのオープンな共通プロトコルです。各社が独自仕様で繋いでいた「ツール呼び出し」「リソース提供」「プロンプト共有」を、MCP として規格化しよう、という動きになっています。

ここのポイントは、Anthropic がこの規格を自社プロダクト専用にせず、オープンにしている 点です。短期的には自社の囲い込みを弱める判断にも見えますが、長期的には「標準化された接続レイヤーを早めに作った側が、エコシステム全体の重力を持つ」という戦略にも見えます。

3 つの柱を縦に並べると、

OS / シェル（Claude Code）
ファイルシステム（Agent Skills）
外部サービス（MCP）

という、開発者にとってお馴染みの 3 階層を全部「AI が直接触れる環境」として整え直そうとしている、という見方ができます。これはなかなか野心的な絵だと思います。

4. Progressive Disclosure：すべてをコンテキストに載せない設計

BigGo 記事で出てきたキーワードのひとつが Progressive Disclosure（段階的開示） でした。これは Agent Skills の根底にある設計思想でもあります。

簡単に整理すると、

必要なときに、必要なスキルや情報だけをロードする
フォルダ構造そのものをドキュメントとして使い、AI に「目次」を見せる
詳細はファイルパスやリンクとして渡し、必要になったタイミングで AI 自身に読みに行かせる

というアプローチです。コンテキストウィンドウは確かに数百K〜数百万トークンへと拡大していますが、「だからこそ全部詰め込む」のではなく、「だからこそ必要なものだけ取り出させる」 方向に振り切った、というのが Anthropic の判断に見えます。

これは私自身、巨大な CLAUDE.md を作って詰め込み運用を試みた後で、「長文 CLAUDE.md より、Skills として小さく分割しておいたほうが破綻しにくい」という体感に至った経験とも一致します。プロジェクトによって相性はあると思いますが、Skills 分割側に倒すほうが安定するケースは多いと感じます。

5. Memory Moat：環境そのものが競争優位になる

「環境中心」設計の戦略的なねらいを、BigGo 記事は 「Memory Moat（記憶の堀）」 という言葉で表現していました。

何が堀になるか	内容
スキルライブラリ	組織が運用の中で育ててきた `SKILL.md` 群
ファイルシステム構造	エージェントが操作してきた前提となるディレクトリ設計やリポジトリ構造
接続済み MCP サーバー群	自社サービス・社内 API への接続定義の蓄積
プロンプト・ガイドライン	コードレビュー方針、命名規則、ドメイン知識のドキュメント化

これらは AI モデル本体には書き込まれていません。組織側に残る資産 です。だからこそ、もし将来モデルが入れ替わったとしても、これらの環境資産は引き継げます。

裏を返すと、「モデルを乗り換える＝環境資産を捨てる」にならないように設計してある とも言えます。MCP のような共通プロトコルがあれば、特定のモデルベンダーに環境資産がロックインされる可能性も下がります。これは導入する側にとっても安心材料になる側面だと思います。

ただし、この Memory Moat 論には注意も必要です。「組織が育てる」側面が大きいため、最初から自動で堀が掘れるわけではない という点です。Skills を整備し、MCP サーバーを書き、ファイルシステム構造を意図的に設計する、という地道な投資が前提になります。「ツールを入れたらすぐ堀ができる」とは思わないほうがよさそうです。

6. 具体例：22,000 行 PR と Epic の事例

BigGo 記事で挙げられていた具体例も、「環境中心」の効き方を裏付ける材料として読みごたえがありました。

Anthropic 内部での 22,000 行 PR

強化学習のコードベースに対し、Claude が記述した2万2,000行に及ぶ大規模コード修正がわずか1日で検証・マージされた

通常なら2週間規模と見積もられる作業量を、4 段階のプロセスで回したそうです。

ステップ	内容
1. 探索・計画	15〜20分。コードベースを Claude に探索させ、対象ファイル・パターンを特定し、計画ドキュメントにまとめさせる
2. 実行	計画ドキュメントを別セッションに渡し、Claude に実装させる
3. 検証	E2E テストを通して機能を検証する
4. 人間による最終確認	拡張性が必要な箇所や、後から触られる可能性が高い箇所を中心にレビュー

ここで効いているのは、「計画ドキュメント」という外部成果物に Skills 的な役割を持たせている 点です。長大なコンテキストに頼るのではなく、計画自体をファイルとして残し、別セッションでも再利用できる形にしている。これはまさに 「ファイルシステムを外部メモリとして使う」 設計の実例です。

Epic（米国ヘルスケア IT）での導入事例

BigGo 記事はもうひとつ、Epic の事例にも触れていました。

Epic では Claude Code 利用の半分以上が非エンジニア職

これは「環境中心」の話と直結します。AI を IDE プラグインに閉じ込めていた時代は、当然ながら IDE を使うエンジニア中心でした。一方、ターミナル＋ファイルシステム＋外部接続を整えた環境 に AI を置くと、医療・業務のドメイン担当者など、コードを書かない職種でも自分の業務をエージェントに引き渡せるようになります。

「誰が AI を使えるかは、AI のモデル性能ではなく、AI が置かれている環境の形で決まる」というのは、覚えておきたい示唆だと感じました。

7. Erik Schluntz 氏の核心的助言と「環境中心」の関係

BigGo 記事は、Anthropic の研究員で「Building Effective Agents」共著者である Erik Schluntz 氏 の言葉も引用していました。

コードの存在は忘れてもいいが、製品の存在は決して忘れてはならない

これは vibe coding についての発言として知られていますが、「環境中心」の文脈で読み直すと、別の意味も帯びてきます。

コード：モデル内側の出力物。揮発的で、書き直されうるもの
製品：環境側に積み上がる、ユーザー体験・データ・スキル・接続の集合体

つまり、エンジニアが守るべきは「自分が書いた一行一行」ではなく、「プロダクトとして提供している価値と、その背後の環境設計」のほうだ、という整理にもなります。

ここは少し私自身の解釈も入っていますが、「環境中心」設計思想と Erik Schluntz 氏の助言は、「揮発するもの（コード）に握りすぎず、残るもの（環境と価値）に手を入れろ」 という同じ根を持っているように感じます。

8. 自分の手元のプロジェクトに当てはめるとどうなるか

ここまで Anthropic 側の戦略を読み解いてきましたが、これを自分のチームに引き寄せると、いくつかの実務的な問いが立ちます。

問い	自分のチームでの当てはめ方
どの作業を AI に渡すか？	コードベースの leaf nodes（依存されない末端機能）から始め、徐々に境界を引き上げていく
知識をどこに置くか？	プロンプトに毎回貼るのではなく、`Skills` フォルダや `CLAUDE.md` に置き、Progressive Disclosure を活用する
外部接続をどう増やすか？	自社 API・社内ツールに対して MCP サーバーを1つずつ書き、エージェントが触れる「環境」を広げていく
何を組織資産として残すか？	計画ドキュメント・SKILL.md・MCP 定義・コードレビュー方針を Git でバージョン管理する
検証可能性をどう設計するか？	コードを読まずに正しさを判定できる E2E テスト・ストレステスト・入出力契約を先に作る

これらは全部一気にやる必要はなくて、自分の手の届く範囲で1つずつ環境を整えていく イメージで取り組むほうが現実的です。たとえば「最初は CLAUDE.md だけ整える」「次に頻出操作を Skill 化する」「次に1つだけ MCP サーバーを書く」というように。

逆に言うと、「Anthropic が言う環境中心の絵を、自分のチームでも縮小版で再現できる」 という点が、この設計思想のうれしいところです。Anthropic が大企業向けの専有プラットフォームを作っているわけではないので、個人や小規模チームでも同じ思想を取り入れる余地があります。

9. 注意したい点

「環境中心」は強力な考え方ですが、いくつか留意しておきたい点もあります。

自動で堀が掘れるわけではない：Skills や MCP を書く労力は、誰かが負担する必要があります。最初の数ヶ月は投資先行になります
環境が育つほど、初期に決めたディレクトリ構造の負債が効いてくる：早い段階で「どういう粒度で Skill を切るか」を一度真剣に考えておくと後が楽です
すべての作業に向いているわけではない：使い捨てスクリプトや個人プロトタイプには、環境を整える前に手を動かしたほうが速い場面もあります
モデル性能を軽視するわけではない：環境を整えても、モデルが弱いと結局つらいです。「環境とモデル両輪」が現実の運用です

このあたりを踏まえつつ、「自分のプロジェクトのどこに環境投資を効かせるか」を見極めていくのが、いまの落としどころに近いと感じます。

10. まとめ

最後に、本記事の要点を簡単に振り返ります。

「環境中心」とは、AI の賢さをモデルの内側だけに閉じず、ファイルシステム・スキルライブラリ・プロトコル にまで責任を分散する設計思想です
それを支える 3 つの柱が Claude Code（ターミナル）・Agent Skills（ファイルシステム）・MCP（外部接続） で、それぞれが「環境のどの階層を整えるか」を担っています
戦略的なねらいは、モデル性能だけでは差がつきにくくなる中で、環境側に組織独自の資産（Memory Moat）を積み上げて競争優位を作る ことです
具体例として、22,000 行 PR の検証可能設計や、Epic で 非エンジニア職が利用の半分以上を占める 浸透の仕方が紹介されていました
自分のチームでも、CLAUDE.md の整備、Skills の分割、MCP サーバーの少しずつの追加、計画ドキュメントの Git 管理、といった形で 縮小版を再現 できそうです
一方で、「環境を育てる」のは時間と意思決定がかかる仕事なので、「ツールを入れた瞬間に堀ができる」という期待は持たないほうが安全です

「揮発するコードではなく、残る環境のほうに手を入れる」という発想は、Erik Schluntz 氏の as old as civilization（マネジメントが古来扱ってきたテーマ）にも通じます。AI の進化が一段加速していく中で、自分たちの仕事のどの部分を「環境」として残し、どの部分は揮発させてよいのか。そのラインを意識的に引いていく作業が、これから数年間の手元の課題になりそうです。

参考リンク

本記事の起点となった解説記事: https://finance.biggo.jp/news/xvvxrJ0Bh5an-7Ghs500
Anthropic 公式「Building Effective Agents」: https://www.anthropic.com/research/building-effective-agents
Model Context Protocol（MCP）公式: https://modelcontextprotocol.io/