Claude Codeの仕組みを完全解説【2026年最新】：クライアント・サーバー構造からCLAUDE.md解釈・コンテキスト圧縮まで徹底ガイド
室谷今回はClaude Codeの「仕組み」の話をしましょう。「なんとなく使えてるけど、中で何が起きているかわからない」という人が.AI（ドットエーアイ）コミュニティでもかなり多いんですよね。
テキトー教師講座でもそうで、「Claude Codeってどういう仕組みですか？」という質問は必ずセッション初日に来ます。使い方を教える前に「仕組みを理解しよう」と言うと、みんな最初は「そんな細かいところ知らなくていいんじゃ？」という顔をするんですが・・・
室谷でも実際、仕組みを知ってから使うのとそうでないのとでは、生産性がまるで変わるんですよ。「Claudeが突然忘れた」とか「思った通りに動かない」とか、そういうトラブルの原因が全部つながってくるので。
テキトー教師そうなんですよ。仕組みを知った受講生さんは「ああ、これがそういうことか」と腹落ちして、CLAUDE.mdの書き方も変わりますし、コンテキスト管理の仕方も変わります。
室谷この記事を読み終えると、Claude Codeが何をやっているかがコードレベルで理解できます。「なぜCLAUDE.mdが効くのか」「なぜセッションが長くなると精度が落ちるのか」「サブエージェントはどういう仕組みか」、この3つが全部クリアになりますよ。
Claude Codeの基本構造：2つの独立したシステム
室谷まず一番の基本から。Claude Codeは「2つの別々なシステムが連携している」んですよね。
これ、意外と知らない人が多い。
これ、意外と知らない人が多い。
テキトー教師そうなんです。多くの人が「Claude Codeというひとつの賢いツール」として認識しているんですが、実態は全然違って・・・
室谷ローカルで動くCLIツール（Claude Codeクライアント）と、Anthropicのサーバーで動くAIモデル（Claude）の2層構造です。これを理解するのが全ての出発点。
テキトー教師ブラウザとウェブサイトの関係に近いですね。ブラウザはあなたのコンピューターで動いていて、ウェブサイト（コンテンツ）はサーバー側にある。
ブラウザ自体に「知性」があるわけじゃない。
ブラウザ自体に「知性」があるわけじゃない。
室谷VirtusLabのエンジニアが詳細な技術解説記事を書いていて、そこでもこの点を強調しているんですよ（）。「Claude Codeは軽量な実行環境で、インテリジェンスはClaude側にある」と。
整理するとこうなります。
| 役割 | 動作場所 | 担当する処理 |
|---|---|---|
| Claude Codeクライアント | あなたのPC（ローカル） | ファイル読み書き、コマンド実行、画面表示 |
| Claudeモデル | Anthropicサーバー（クラウド） | 思考・判断・コード生成 |
テキトー教師この表を見ると「あれ、じゃあコードは全部クラウドに送られてるの？」と心配する受講生さんがいるんですが・・・
室谷そこが面白い設計で、全ファイルをクラウドに送ってるわけじゃないんですよ。Claudeが「このファイルを読んで」と指示したファイルの内容だけがAPIを通じて送られる。
常時全コードをアップロードしているわけじゃない。
常時全コードをアップロードしているわけじゃない。
ツール呼び出し（Tool Calls）の仕組み
テキトー教師で、「Claudeが読んで」というのはどうやって実現されているんですか？という話が次に来ます。
室谷ここが「ツール呼び出し（Tool Calls）」の話ですね。Claudeはテキストを返すだけじゃなくて、「このツールを使って」という構造化された命令をAPIレスポンスに含めることができる。
テキトー教師例えば「Pythonファイルを全部リストして」とユーザーが言ったとき、Claudeは「find . -name '*.py'というコマンドを実行するツールを呼んで」という形式で返す。
室谷そうです。そのレスポンスを受け取ったClaude Codeクライアントが、実際にそのコマンドをローカルで実行して、結果をまたAPIに返す。
これをループして回している。
これをループして回している。
テキトー教師つまり実際の「実行」は全部ローカル。「判断」は全部クラウド。
というシンプルな役割分担ですね。
というシンプルな役割分担ですね。
具体的なフローはこうなります。
- ユーザーがClaude Codeに指示を入力
- Claude Codeクライアントが、利用可能なツール一覧とユーザーのメッセージをAPIに送信
- Claudeモデルが思考し、「このツールを使え」という指示をAPIレスポンスに含める
- Claude Codeクライアントがローカルでそのツールを実行（ファイル読み取り、コマンド実行等）
- 実行結果をAPIに送り返す
- Claudeが結果を受け取り、次の判断をする
- 完了したらテキストで回答を返す
室谷このループが「1ターン」の処理の正体で、複雑なタスクはこれを何十回も繰り返している。Pragmatic EngineerがClaude Codeのアーキテクチャを深掘りした記事では、「90%のコードをClaude Code自身が書いた」と紹介されていましたが、それもこのループが高速に動いているからです。
Claude Code自体のテックスタック
テキトー教師「Claude Code自体は何で作られているんですか？」という質問も実際によく聞かれます。
室谷TypeScriptとReact、Inkフレームワーク、Bunで作られています。Inkというのはターミナル上でReactのUI部品を使えるようにするフレームワークで、あのカラフルなターミナル表示がこれで実現されている。
テキトー教師「なんでターミナルツールにReact？」とみんな驚くんですが・・・
室谷これが面白い設計思想で、「Claudeが得意な技術スタックで作る」という判断なんですよ。TypeScriptとReactはモデルがすでに大量のコードを学習しているので「on distribution（得意な領域）」。
つまり、Claude自身がClaude Codeを書き、修正できる。
つまり、Claude自身がClaude Codeを書き、修正できる。
テキトー教師「ツールが自分自身を改善できる」という構造ですね。Anthropicのエンジニアリングチームが言う「AIファースト」の実践版。
室谷実際、Claude Code自体の約90%のコードがClaude Codeで書かれているという話もあるくらいで・・・。エンジニアがひとり2-3人分の速度で開発できているのはこの構造のおかげです。
CLAUDE.mdがなぜ効くのか：AIが解釈しているから
テキトー教師CLAUDE.mdの話も押さえておきたいですね。「CLAUDE.mdに書いたことをClaude Codeが理解してくれる」という感覚を持っている人が多いんですが、もう少し正確に言うと・・・
室谷CLAUDE.mdをClaude Codeクライアントが読んで、そのテキストをAPIリクエストのコンテキストに含める。解釈しているのはあくまでClaudeモデル側、ということですよね。
テキトー教師そうです。これ、すごく重要で。
Claude Codeクライアント自体はCLAUDE.mdの内容を「理解」していない。テキストをそのままClaude側に渡すだけ。
Claude Codeクライアント自体はCLAUDE.mdの内容を「理解」していない。テキストをそのままClaude側に渡すだけ。
室谷だからCLAUDE.mdで「もしAとBの条件が重なったときはCの動作をしてください」みたいな複雑な条件分岐も書けるんですよね。「クライアントがルールエンジンとして処理する」わけじゃなくて、「モデルが自然言語として理解する」から。
テキトー教師これを理解してからCLAUDE.mdを書くと、書き方が変わります。「コンピュータに処理させるコード」じゃなくて「人間に説明するように書く」のが正解。
室谷VirtusLabの記事にもこんな例が出ていました。「guideline.mdというファイルを新しいAPIエンドポイントを実装するときだけ読んでください」という指示をCLAUDE.mdに書いておくと、Claudeはバグ修正のタスクのときはそのファイルを読まず、新しいエンドポイント実装のときだけ読む。
この条件分岐はClaudeが判断している。
この条件分岐はClaudeが判断している。
テキトー教師受講生さんによく言うのが「CLAUDE.mdは設定ファイルじゃなくて手紙を書くような感覚で」ということですね。
.claudeディレクトリの全体像
室谷CLAUDE.mdだけじゃなくて、
.claudeディレクトリ全体がClaude Codeのカスタマイズの核心なんですよね。テキトー教師そうです。整理するとこうなります。
CLAUDE.md→ 全体の前提・ルール（毎回コンテキストに含まれる）rules/→ 特定ファイルを触るときだけ自動参照されるルールagents/→ 専門チーム（サブエージェント）の定義hooks/→ 特定イベントのときに強制実行されるスクリプト
室谷rules/の仕組みが特に面白くて、例えばrules/python.mdを作っておくと、Pythonファイルを編集するときだけそのルールが参照される。全部を毎回コンテキストに入れなくていいので、トークンの節約にもなる。テキトー教師hooks/も理解している人が少なくて・・・。コードを書いた後に自動でテストを走らせる、とかLinterを実行する、というのをHooksで設定できます。これはClaude Codeクライアント側で「物理的に」実行されるので、Claudeがうっかり忘れても確実に動く。
室谷これは「Claudeに頼む」じゃなくて「ツールに強制させる」という設計で、信頼性が全然違うんですよね。重要な品質チェックはHooksに入れるのが正解。
コンテキストウィンドウの仕組みと圧縮パイプライン
テキトー教師「Claudeが途中から精度が落ちた」「さっき話したことを忘れた」という経験、使っている人なら誰でもあると思うんですが・・・
室谷これ、コンテキストウィンドウとコンテキスト圧縮の仕組みを知ると、「あ、そういうことか」となりますよね。
テキトー教師Claudeが1度に「見ている」情報には上限（コンテキストウィンドウ）があって、それを超えてくると古い情報を圧縮・削除していく。
室谷流出したソースコードを分析した結果として、この圧縮パイプラインの詳細が明らかになっていて・・・
テキトー教師このツイートの内容がすごくて。単純に「古い順に削除」じゃなくて、3層のパイプラインで段階的に対処しているんですよね。
コンテキスト圧縮パイプラインの詳細
室谷UCLのチームが書いた論文（arXiv:2604.14228）によると、実装レベルでは5つのステップで圧縮が進みます。コストが安いものから順に実行される設計で・・・
テキトー教師「budget reduction → snip → microcompact → context collapse → auto-compact」という5ステップですね。ユーザーから見えるのはそのうちの一部ですが、内部ではこの5段階で処理されている。
室谷ユーザーが意識するレベルで整理すると、こういう感じです。
| 圧縮フェーズ | 処理内容 | コスト |
|---|---|---|
| 軽量プリプロセス（毎ターン） | ツール結果の不要部分を削除。MicroCompact相当 | 超低コスト |
| セッションメモリ再構築 | セッションメモリファイルから文脈を再構築 | 中程度 |
| 完全要約（最終手段） | Claudeに「会話を要約して」と依頼。/compactコマンド相当 | 高コスト |
テキトー教師「最初の軽量プリプロセスが毎回動いている」というのが重要で、毎ターンAPIリクエスト前に実行されるんですよ。ツール実行結果の不要部分を自動削除する処理で、会話の構造自体は変えない。
コストが低いから毎回できる。
コストが低いから毎回できる。
室谷セッションメモリ再構築は、APIコールが不要なので安い。最後の完全要約は高コストなので最終手段として使う。
室谷賢いのが「preserved-tail relinking」という設計で、要約後も直近のメッセージの尾部を保存しておいて、再開時にその尾部を要約チェーンにリンクし直す。「今まさに作業中のコンテキスト」を極力維持する設計になっている。
テキトー教師「Claudeが忘れた」の正体は「メッセージを削除している」じゃなくて、「境界切断＋要約置換＋尾部保存が組み合わさった結果」なんですよね。設計上は最大限「忘れない」ようにしようとしているんですが、トークン制限との戦いで。
室谷だから実践的な対応策としては、「長い会話を続けるより、重要なコンテキストはCLAUDE.mdやセッションメモリに書き出す方が確実」になる。これ、仕組みを知らないと気づけない対処法ですよね。
コンテキストの見える化：円グラフの意味
テキトー教師Claude Codeの画面に「謎の円グラフ」が表示されているのを気にしたことがある人も多いと思うんですが・・・
室谷あれ、コンテキストウィンドウの残量メーターなんですよw 満タンになると自動でコンテキスト圧縮が発動する。これを知らずに使っていた人が「急に品質が落ちた」と感じるわけです。
テキトー教師受講生さんに「あの円グラフを常に右上に表示するようにClaude Codeを設定できるので、残量を意識しながら使いましょう」とアドバイスしています。
室谷円グラフが黄色や赤になってきたら、新しいセッションを始めるか、重要な情報をCLAUDE.mdに書き出すタイミングだということが一目でわかる。
サブエージェントの仕組み：並列処理とトークン分離
テキトー教師「Claude Codeのサブエージェントってどういう仕組みなんですか？」というのも頻出質問です。
室谷サブエージェントは「別の会話セッション」として動くんですよね。メインのClaude Codeセッションから独立した形で、別のタスクを並行して処理できる。
テキトー教師で、サブエージェントのコンテキストはメインセッションには流れてこない。「まとめ（summary）」だけが親に返る、という設計。
室谷これが面白い最適化で。例えば「AとBとCの3ファイルを並行してリファクタリングして」というタスクを3つのサブエージェントに分割した場合、それぞれが独立したコンテキストで動く。
メインのコンテキストには最終結果だけが返ってくる。
メインのコンテキストには最終結果だけが返ってくる。
テキトー教師ただ、これはトークンコストも高くなりますよね？
室谷UCLのチームがソースコードを解析した論文（arXiv:2604.14228）によると、Agent Teamを使うとだいたい7倍のトークンコストになるという結果が出ています。それでも並列処理で速度が上がるので、「時間をとるかお金をとるか」のトレードオフですね。
テキトー教師「サブエージェントは万能じゃない」というのは実際の指導でも必ず伝えます。独立した短いタスクならサブエージェントが有効ですが、相互に依存する複雑なタスクだと同期が難しくなる。
室谷MYUUUでは「独立して並行実行できるか」「タスク間の依存関係があるか」を判断基準にしています。独立性が高い場合はサブエージェント、依存関係が強い場合は1つのセッションで順番に実行する、という使い分け。
拡張機能のコスト序列：Hooks・Skills・Plugins・MCP
テキトー教師Claude Codeの拡張方法が4種類あって、それぞれコンテキストコストが違うという話も整理しておきたいですね。
室谷これも流出ソースコードの解析で明らかになっていて・・・コンテキストコストが低い順にHooks、Skills、Plugins、MCPという序列があります。
テキトー教師Hooksが一番軽い。「特定イベントに反応してローカルスクリプトを実行する」だけで、モデルのコンテキストをほぼ消費しない。
室谷Skillsはレシピ書のようなもので、「このタスクをやるときはこの手順で」という定義をMarkdownで書く。モデルがそれを読んで実行する形なので、Hooksより少しコストが上がる。
テキトー教師MCPが一番コストが高い。外部ツールとの連携なので、ツールの説明をコンテキストに含める必要があって・・・多くのMCPサーバーをつなぐとその分コンテキストが圧迫されます。
室谷だから「とりあえず全部MCPで繋げばいい」じゃなくて、頻繁に使う軽い処理はHooks、定型タスクはSkills、外部サービス連携だけMCPという使い分けが大事。
| 拡張方法 | コスト | 特徴 |
|---|---|---|
| Hooks | 低 | ローカルスクリプト実行。コンテキストほぼ消費なし |
| Skills | 低〜中 | Markdownのレシピ。モデルが読んで実行 |
| Plugins | 中 | 組み込み拡張 |
| MCP | 高 | 外部ツール連携。ツール説明がコンテキストに入る |
権限管理の仕組み：MLクラシファイアによる自動判断
テキトー教師「Claude Codeが実行するとき、いちいち許可を求めてくる」という話、使い始めた人が最初に驚くところですよね。
室谷あれ、セキュリティの仕組みなんですよ。Claude Codeクライアントが各ツール実行の前に「これは安全か？」を判断して、危険な操作は許可を求める、という設計です。
テキトー教師で、昔は「--dangerously-skip-permissions」というオプションで全部スキップできたんですが・・・
室谷名前が最高ですよねw でも実際「本番DBが消えた」という事故が起きていて。それで出てきたのがauto modeですよね。
テキトー教師このツイートにある「MLクラシファイア」の話、面白いですよね。
室谷そうです。各ツールコール（ファイル書き込み、コマンド実行）の実行前にMLモデルがチェックする。
大量ファイル削除、機密データ流出、悪意あるコード実行を検出してブロックする。安全なアクションだけ自動実行する、という仕組みです。
大量ファイル削除、機密データ流出、悪意あるコード実行を検出してブロックする。安全なアクションだけ自動実行する、という仕組みです。
テキトー教師「プロンプトインジェクション対策」が特に重要で。ファイルの中身やコマンドの出力に「悪意ある指示」が仕込まれていた場合、そこからClaudeがハイジャックされることがある。
それをクラシファイアが弾く。
それをクラシファイアが弾く。
室谷流出ソースコードの解析によると、7種類の権限モードがあって、ユーザーの93%は「yes」をクリックし続けるという結果が出ていて・・・だから自動化層で補正する設計にしたらしい。実際の人間の行動パターンに合わせた設計が面白い。
許可リストの設計：settings.jsonで先に決める
テキトー教師Routinesやスケジュール実行を使うときに特に重要なのが、permissionの「allowリスト」の事前設計ですね。
室谷深夜に無人実行するときに「許可を求める」ダイアログが出ると全部止まってしまう。だからsettings.jsonのallowリストを先に設計しておく必要がある。
「何を自動化するか」よりも「何を止めないか」を先に決める、という発想の転換ですね。
「何を自動化するか」よりも「何を止めないか」を先に決める、という発想の転換ですね。
テキトー教師具体的には
.claude/settings.jsonに許可するツールとアクションを書いておきます。例えばこういう書き方です。{
"permissions": {
"allow": [
"Bash(git commit:*)",
"Bash(npm run *)",
"Read(*)",
"Edit(*)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(sudo *)"
]
}
}
これで「gitコミットは自動で許可」「npmスクリプトは許可」「ファイル読み書きは許可」「削除系は禁止」という設定ができる。
テキトー教師受講生さんに「このリストを作る過程が、実はセキュリティ設計の練習になる」と言うと、「なるほど」という反応をもらいます。
Claude Codeはどうやって生まれたのか
室谷せっかくなので「なぜこういう仕組みになったのか」の背景も話しましょう。Claude Codeの誕生ストーリーがめちゃくちゃ面白いんですよ。
テキトー教師Boris Chernyというエンジニアが最初に作った話ですよね。
室谷2024年9月にAnthropicに入社したBoriが、ClaudeのAPIを触りながら「ターミナルで使えたら面白いな」と思って作り始めた。最初はAppleScriptを使って「今聴いている音楽を教えて」という小さいデモだったんですよ。
テキトー教師そこから「ファイルシステムへのアクセスを持たせたら？」という発想の転換があって・・・
室谷そこからが大変化で。Claudeがファイルを読んで、importを辿って、関連ファイルを自分で探し始めた。
「これは product overhang（製品として解放されていなかったモデルの能力）だ」とBorisは気づいた。
「これは product overhang（製品として解放されていなかったモデルの能力）だ」とBorisは気づいた。
テキトー教師「AIがすでにできるのに、それを活かすプロダクトがなかった状態」ですよね。その穴を埋めたのがClaude Code。
室谷Anthropic社内で最初に共有した日、エンジニアの20%が使い始めて、5日後には50%になっていた。「公開すべきか社内の秘密兵器にすべきか」という議論まで起きたくらいです。
テキトー教師「公開したらAnthropicの競合優位性がなくなる」という意見もあったんですが・・・
室谷「AIの安全性と能力について学ぶために、人が使うツールが必要。Claude Codeがそのツールになる」という結論で公開を決めた。
会社のミッションと一致するから、という理由です。
会社のミッションと一致するから、という理由です。
テキトー教師この「仕組みを公開する」というAnthropicの姿勢が、他のツールにはない透明性につながっているんでしょうね。
Claude Codeの「とは」を整理する
室谷改めて「Claude Codeとは何か」を整理しましょうか。一言でいうと・・・
テキトー教師「AIモデル（Claude）を、コーディングに特化した形で使えるようにするクライアントツール」ですよね。「Claude Code自体がAI」じゃなくて「ClaudeにコーディングのUI/UXを提供するラッパー」という理解が正確。
室谷「claude code とは」と検索した人に向けて整理するとこうなります。
| 項目 | 内容 |
|---|---|
| 正体 | TypeScript製のCLIツール（npmでインストール） |
| AI部分 | AnthropicのClaude（クラウドAPI） |
| できること | ファイル編集、コマンド実行、コードベース探索、テスト実行 |
| 料金 | Claude Proプラン（月$20）またはAPI従量課金 |
| 対応OS | macOS、Linux、Windows（WSL2・ネイティブ両対応） |
テキトー教師「claude code インストール」で最初に詰まる人も多いんですが、インストール自体は1行です。
curl -fsSL https://claude.ai/install.sh | bash
macOS/Linux/WSLはこれだけ。Windowsネイティブはインストールスクリプトが別にあります。
インストール後に
インストール後に
claudeコマンドを打つと自動でログイン画面が立ち上がる。テキトー教師でもここからが本題で、「インストールできた」は出発点に立っただけ。仕組みを理解して使うのと理解しないで使うのとでは、1ヶ月後に全然違う結果になります。
まとめ：仕組みを知ると使い方が変わる
室谷今日の内容を振り返りましょう。Claude Codeの仕組みの核心は「2つのシステムの連携」。
テキトー教師ローカルで動くクライアントが「手と足」で、クラウドのClaudeが「頭」。この構造を理解すると、なぜCLAUDE.mdが効くのかがわかります。
室谷CLAUDE.mdをClaude Codeクライアントが読んでAPIに送る。解釈するのはClaudeモデル側。
だから「人間に説明するように書く」のが正解。
だから「人間に説明するように書く」のが正解。
テキトー教師コンテキスト管理も「単純な削除」じゃなくて3層の圧縮パイプライン。設計上は「忘れない」ように最大限努力しているが、トークン制限との戦い。
室谷サブエージェントは「別セッション＋サマリー返送」で並列処理を実現。ただしAgent Teamは通常の約7倍のトークンコスト。
「独立性」が高いタスクに絞って使うのが正解。
「独立性」が高いタスクに絞って使うのが正解。
テキトー教師拡張方法のコストはHooks→Skills→Plugins→MCPの順に高くなる。「とりあえずMCP」じゃなくて、目的に合わせて最低コストの方法を選ぶ。
室谷これだけ頭に入ってると、「なんか調子悪い」「急に忘れた」というトラブルへの対処が全部変わりますよね。
テキトー教師講座では「仕組みを知ってから使う」と「なんとなく使う」で、3ヶ月後の習熟度が全然違うという話をしています。ぜひこの記事を読んだあとで、改めて自分のCLAUDE.mdやsettings.jsonを見直してみてください。
よくある質問（FAQ）
室谷最後に、よく来る質問にまとめて答えておきましょう。
テキトー教師「コードはAnthropicに送られるのか」という質問は一番多いですよね。
室谷答えは「Claudeが明示的に読むよう指示したファイルの内容のみ」です。プロジェクト全体が自動的にアップロードされるわけじゃない。
必要なファイルの内容だけAPIを通じて送られる。
必要なファイルの内容だけAPIを通じて送られる。
テキトー教師「CLAUDE.mdはどこに置くのか」という質問も頻出です。
室谷プロジェクトのルートディレクトリに置くのが基本で、ホームディレクトリ（
~/.claude/CLAUDE.md）にグローバルな設定を書くこともできます。プロジェクト固有の設定はルート、全プロジェクト共通の設定はグローバルで使い分けるのがベストプラクティスです。テキトー教師「なぜ「コード」という名前なのか」という質問も来たりします（笑）
室谷BorisがAIをターミナルで使えるツールを作ったとき、ターゲットとして最初はソフトウェアエンジニアを想定していたので「Claude Code」という名前にした。でも実際にはデータサイエンティストや非エンジニアも使い始めていて、Borisが「名前を変えるべきだったかも」と思っているという話もあります。
テキトー教師「仕組みを理解したい人向けの次のステップは？」
室谷まずはCLAUDE.mdを書いてみること。「人に説明するように」書くのが出発点。
次に
次に
.claude/settings.jsonで許可リストを設定する。この2つをやるだけで、Claude Codeの使い方が変わります。
