Claude Code 解説書 — Thread 2 of 8
仕組みを理解する
エージェンティックループとアーキテクチャ
第1章では、Claude Codeが「LLMに手足を与えるエージェンティックハーネス」であることを学んだ。 このスレッドでは、その「手足」が具体的にどう動くのか——つまりClaude Codeはなぜ自律的に動けるのかという問いに、技術的な精度をもって答えていく。
エージェンティックループ（Agentic Loop）とは、AIが「調査→実行→検証」を自律的に繰り返す動作サイクルのことです。Claude Codeのすべての挙動は、このループの上に成り立っています。
2.1エージェンティックループの3フェーズ
Claude Codeにタスクを渡すと、内部では次の3つのフェーズが循環的に実行される。
Phase 1：コンテキスト収集（Gather Context）は、タスクを遂行するために必要な情報を集める段階だ。 ファイルを検索して読み、コードの構造を把握し、Git（バージョン管理ツール）の状態を確認する。 たとえば「認証のバグを直して」と頼むと、Claude Codeはまずsrc/auth/ディレクトリ配下のファイルを探索し、関連するテストコードや設定ファイルを読み込む。
Phase 2：アクション実行（Take Action）は、収集した情報に基づいて実際に行動する段階だ。 ファイルの編集、コマンドの実行、新しいファイルの作成などがここに含まれる。 たとえば、バグの原因がトークンの有効期限チェック漏れだと判断したら、該当コードを修正し、テスト用のフィクスチャ（テストデータ）を追加する。
Phase 3：結果検証（Verify Results）は、自分のアクションが正しかったかを確認する段階だ。 テストスイートを実行してパスするか確認し、型エラーが出ていないかチェックし、問題があれば原因を分析して再びPhase 2に戻る。
重要なのは、これら3フェーズは明確に分離されるのではなく、流動的に繰り返されるということだ。 公式ドキュメントの表現では「These phases blend together（フェーズは溶け合う）」——収集の途中でアクションを取ることもあれば、検証中に新たな情報収集が必要になることもある。 Claude Codeは前のステップで得た情報をもとに次に何をすべきかを判断し、数十のアクションを連鎖させて自律的に軌道修正しながらタスクを完了する。
図2.1 — エージェンティックループの循環構造。3フェーズは流動的に繰り返され、人間はいつでも介入できる
そして、もう1つの重要なポイントがある。人間はこのループの一部だ。 Claude Codeが作業中であっても、いつでも割り込んで方向を修正したり、追加のコンテキストを与えたり、別のアプローチを試すよう指示できる。 公式ドキュメントの表現では「Claude works autonomously but stays responsive to your input（自律的に動くが、あなたの入力には常に応答する）」。
具体例：テストが落ちた場合のループ動作
fix the failing tests と入力した場合、Claude Codeの内部では次のようなステップが連鎖する：
テストスイートを実行して、どのテストが失敗しているか確認する（収集）
エラー出力を読み取り、失敗の原因を分析する（収集）
関連するソースファイルを検索して特定する（収集）
該当ファイルを読み込み、コードの文脈を理解する（収集）
バグの原因となっているコードを編集する（実行）
テストを再実行して、修正が正しいか確認する（検証）
ステップ6で別のテストが壊れていれば、ステップ2に戻って再分析し、修正を繰り返す。これがエージェンティックループだ。
2.2モデルとツール — 「脳」と「手足」
エージェンティックループを動かしているのは、2つのコンポーネントだ。
モデル（Model）は、Claude Codeの「脳」にあたる。 Anthropicの言語モデルClaudeが、コードを読んで理解し、コンポーネント間の関係を把握し、目標達成のために何を変更すべきかを推論する。 複雑なタスクでは、作業をステップに分解し、各ステップの結果から学んで次のアプローチを調整する。
ツール（Tool）は、Claude Codeの「手足」にあたる。 公式ドキュメントはこの違いを一言で表現している：「ツールなしのClaudeはテキストで応答するだけ。ツールを持つClaudeは行動できる」。 ファイルの読み書き、コマンドの実行、Web検索、外部サービスとの連携——これらはすべてツールによる行動であり、各ツールの実行結果がループにフィードバックされて次の判断材料になる。
図2.2 — モデル（推論エンジン）が判断し、ツール群が実行する。結果はモデルにフィードバックされる
利用可能なモデルは複数あり、タスクに応じて使い分けられる。Sonnetは大半のコーディングタスクに適したバランス型で、Opusは複雑なアーキテクチャ判断に強い高精度推論型だ。 セッション中に/modelコマンドで切り替えるか、起動時にclaude --modelで指定する。
「Claudeが判断する」とは：公式ドキュメントで「Claude chooses」「Claude decides」と書かれている箇所は、すべてモデルが推論を行っていることを意味する。 Claude Codeはモデルの判断に基づいてツールを呼び出し、その結果をモデルに返し、モデルが次のステップを判断する——これが「エージェンティック」の実体だ。
2.35つの組み込みツールカテゴリ
Claude Codeが標準で備えているツールは、5つのカテゴリに分類される。 各カテゴリは異なる種類の「行動能力（agency）」を表しており、これらを組み合わせることでClaude Codeは多様なタスクに対応する。
図2.3 — 5つの組み込みツールカテゴリ。各カテゴリが異なる種類の行動能力を提供する
これら5カテゴリに加えて、サブエージェント（子タスクへの委任）やユーザーへの質問など、オーケストレーション（タスク管理・調整）用のツールも存在する。 さらに、組み込みツールの上に拡張レイヤーを重ねることで、Claude Codeの能力を拡張できる。 Skills（再利用可能な知識）、MCP（外部サービス接続）、Hooks（自動化）、Subagents（タスク委任）——これらについてはスレッド4以降で詳述する。
重要な設計原則：Claude Codeの検索ツールは、RAG（Retrieval-Augmented Generation＝ベクトルデータベースを使った検索拡張生成）のような複雑な技術ではなく、素朴なglobとgrepをモデルが駆使する方式を採用している。 Boris Cherny（Claude Code創設者）の言葉を借りれば「Plain glob and grep, driven by the model, beat everything（モデルが操る素朴なglobとgrepが、すべてに勝る）」。
2.4Claude Codeがアクセスできるもの
ターミナルでclaudeを実行すると、Claude Codeは次の6つのリソースにアクセスする。 この「アクセス範囲の広さ」が、インラインコード補完ツール（現在のファイルしか見えない）との決定的な違いだ。
図2.4 — Claude Codeがアクセスできる6つのリソース。プロジェクト全体を横断的に把握する
たとえば「認証のバグを直して」と頼んだ場合、Claude Codeは関連ファイルを検索して複数のファイルを読み、文脈を理解し、ファイル間で整合的な編集を行い、テストで検証し、必要ならgit commitまで実行する。1つのファイルしか見えないインラインコード補完ツールとの根本的な違いはここにある。
CLAUDE.md（プロジェクトのルートに配置するマークダウン形式の指示書）とオートメモリ（MEMORY.md）については、第4章で詳しく解説する。 拡張機能（MCP、Skills、Subagents等）については、第5〜8章が対応する。
2.5実行環境の3タイプ
エージェンティックループ、ツール、アクセス範囲——これらの基本構造はClaude Codeをどこで使っても同じだ。 変わるのはコードがどこで実行されるかとどうインタラクションするかだけだ。
図2.5 — 3つの実行環境。エージェンティックループは同一で、実行場所とインターフェースだけが異なる
インターフェースもターミナル以外に、デスクトップアプリ、IDE拡張（VS Code / JetBrains）、Webインターフェース（claude.ai/code）、Slack、CI/CDパイプラインなど複数の選択肢がある。 重要なのは、インターフェースが変わってもエージェンティックループの動作は同一であるということだ。
2.6セッション管理
セッション（Session）とは、Claude Codeとの1回の対話単位だ。 起動から終了までのすべてのメッセージ、ツール使用、その結果がローカルに保存される。
セッションの独立性
各セッションは独立した存在であり、新しいセッションは過去のセッションの会話履歴を持たない。 セッション間で知識を引き継ぐ手段は2つある：オートメモリ（Claude Codeが自動的に学習して保存する知見）とCLAUDE.md（開発者が手動で記述する永続的な指示書）だ。
再開とフォーク
claude --continue（またはclaude -c）で直前のセッションを再開できる。claude --resumeで過去のセッション一覧から選んで再開することも可能だ。 再開時、会話履歴はすべて復元されるが、セッション中に付与したパーミッション（許可設定）は引き継がれない——改めて承認が必要だ。
図2.6 — セッションの再開（resume）とフォーク（fork）。Gitのブランチ分岐と同じ発想
--fork-sessionは、それまでの会話履歴を保持したまま新しいセッションIDで分岐する操作だ。 元のセッションは一切変更されない。 たとえば「修正方針Aで試してみたが、別の方針Bも試したい」という場合にフォークを使えば、方針Aの作業を失うことなく方針Bを独立して検証できる。Gitのブランチ分岐と同じ考え方だ。
コンテキストウィンドウの管理
コンテキストウィンドウ（Context Window）とは、AIモデルが一度に「読める」情報量の上限だ。 会話履歴、ファイル内容、コマンド出力、CLAUDE.md、読み込まれたスキル、システム命令——これらすべてがコンテキストウィンドウに収まる必要がある。
作業が長引くとコンテキストは埋まっていく。Claude Codeは自動的にコンパクション（圧縮）を行い、古いツール出力を先にクリアし、必要に応じて会話を要約する。/contextコマンドで現在のコンテキスト使用状況を確認でき、/compactで手動圧縮も可能だ。
コンテキストが満杯になると何が起きるか：会話の初期に与えた詳細な指示が失われる可能性がある。 そのため、永続的に守らせたいルール（コーディング規約、禁止事項など）はCLAUDE.mdに記述し、会話履歴に頼らないことが重要だ。
コンテキストを効率的に管理する手段として、Skills（オンデマンド読み込み——必要な時だけコンテキストに入る）とSubagents（独立したコンテキストでタスクを処理し、要約だけを返す）がある。 これらについては第4章以降で詳述する。
ブランチとセッションの関係
セッションはディレクトリに紐づく。Gitのブランチを切り替えるとClaude Codeは新しいブランチのファイルを見るが、会話履歴はそのまま保持される。 並列作業が必要な場合は、git worktree（Gitの機能で、1つのリポジトリに複数の作業ディレクトリを作る仕組み）を使えば、ブランチごとに独立したClaude Codeセッションを走らせることができる。
2.7安全機構 — チェックポイントとパーミッション
自律的に動くエージェントには、安全装置が不可欠だ。 Claude Codeには2つの安全機構がある：チェックポイント（変更の巻き戻し）とパーミッション（行動の制御）。
チェックポイント — すべてのファイル編集は取り消せる
Claude Codeがファイルを編集する前に、必ず現在の内容のスナップショット（チェックポイント）が自動保存される。 何か問題が起きた場合、Escキーを2回押すだけで、任意の過去の状態に巻き戻せる。
ただし、チェックポイントが保護するのはローカルのファイル変更のみだ。 データベースへの書き込みやAPIの呼び出し、デプロイメントなど、外部システムに影響するアクションは巻き戻せない。 これが、Claude Codeが外部に副作用を持つコマンドの実行前に人間に確認を求める理由だ。
パーミッション — 3つのモード
Shift+Tabキーを押すと、3つのパーミッションモードを順に切り替えられる。
図2.7 — 3つのパーミッションモード。Shift+Tabで切り替え。安全性と自律性のトレードオフ
頻繁に実行する信頼済みコマンド（npm testやgit statusなど）は、.claude/settings.jsonに登録しておけば、毎回の確認を省略できる。 設定は組織ポリシーから個人の好みまで、複数のスコープ（適用範囲）で階層的に管理可能だ。
実践的な使い分けの例
新規プロジェクトを探索するとき：Plan modeでコードベースを読み込ませ、構造を理解する計画を立てさせる。変更は一切発生しない。
テストの修正作業：Auto-accept editsに切り替え、ファイル編集は自動承認しつつ、npm testの実行は確認してから行う。
本番環境に影響する作業：Defaultモードのまま、すべてのアクションを逐一確認しながら進める。
安全性と自律性のトレードオフ：すべてを確認すれば安全だが、エージェントの自律性を損なう。すべてを自動承認すれば高速だが、予期しない変更のリスクが生じる。 Claude Codeの設計は「デフォルトは安全側に、必要に応じて段階的に自由度を上げる」という原則に基づいている。 まずはDefaultモードで動作を理解し、信頼が築けたらモードを上げていくのが賢明だ。
2.8まとめ — アーキテクチャの全体像
このスレッドで学んだ内容を、1枚のアーキテクチャ図に統合する。
図2.8 — Claude Codeアーキテクチャの全体像。人間の指示から安全機構まで、全レイヤーの関係を俯瞰する
| 概念 | 役割 | 詳細 |
|---|---|---|
| エージェンティックループ | 核心動作 | 収集→実行→検証の流動的サイクル。人間はいつでも介入可能 |
| モデル | 推論エンジン（脳） | Sonnet（汎用）/ Opus（高精度）。コードを理解し判断を下す |
| ツール | 行動手段（手足） | 5カテゴリの組み込みツール＋拡張レイヤー |
| アクセス範囲 | 情報源 | プロジェクト全体、ターミナル、Git、CLAUDE.md、メモリ、拡張 |
| 実行環境 | コードの実行場所 | ローカル / クラウド / リモートコントロールの3タイプ |
| セッション | 対話の単位 | 独立・再開・フォーク可能。コンテキストウィンドウで管理 |
| 安全機構 | 保護の仕組み | チェックポイント（巻き戻し）＋パーミッション（3モード） |
第3章では、ここで理解したアーキテクチャの上で実際にClaude Codeをインストールし、日常の開発ワークフローに組み込んでいく。 「仕組みがわかった」状態から「使いこなせる」状態への橋渡しだ。
次のスレッドへの予告：第3章「導入と日常ワークフロー」では、インストール手順、基本コマンド体系、そして実際の開発タスク（バグ修正、テスト作成、コードレビュー、PR作成など）での活用パターンを学ぶ。
Support
homulaの支援体制
Claude Codeの導入・運用を検討されている企業向けに、homulaは以下の支援を提供しています。
AIエージェント・ブートキャンプ
3〜5日間で動くプロトタイプを構築し、ROI試算まで完了。Claude Codeを含むAIコーディングツールの最適な導入戦略を策定します。
エンタープライズ導入支援
セキュリティポリシー策定、CLAUDE.md設計、MCP接続、チーム展開まで一気通貫で支援。400社超の導入実績に基づく知見を提供します。
シリーズナビゲーション
← 前の章
第1章：Claude Codeとは何か
Coming Soon
第3章：導入と日常ワークフロー
よくある質問
エージェンティックループとは、Claude Codeの核心的な動作サイクルです。「コンテキスト収集（ファイル検索・コード読解）→ アクション実行（ファイル編集・コマンド実行）→ 結果検証（テスト確認・エラー分析）」の3フェーズを流動的に繰り返し、人間の指示を自律的に遂行します。
Default（すべてのアクションに都度確認が必要）、Auto-accept edits（ファイル編集は自動承認、コマンド実行は確認が必要）、Plan mode（読み取り専用で計画だけを立案）の3モードがあります。Shift+Tabで切り替え可能で、安全性と自律性のトレードオフを段階的に調整できます。
チェックポイントが保護するのはローカルのファイル変更のみです。データベースへの書き込み、APIの呼び出し、デプロイメントなど外部システムに影響するアクションは巻き戻せません。これが、Claude Codeが副作用を持つコマンドの実行前に人間に確認を求める理由です。
組み込みツールは5カテゴリに分類されます：ファイル操作（読取・編集・作成）、検索（パターン検索・正規表現）、実行（シェルコマンド・Git・テスト）、Web（検索・ドキュメント取得）、コードインテリジェンス（型エラー検出・定義ジャンプ）。さらにMCP・Skills・Subagents等の拡張レイヤーで能力を拡張できます。
フォークは、それまでの会話履歴を保持したまま新しいセッションIDで分岐する操作です。元のセッションは変更されないため、「修正方針Aで試したが方針Bも試したい」という場面で、Aの作業を失わずにBを独立検証できます。Gitのブランチ分岐と同じ発想です。
Claude Codeのエンタープライズ導入を検討していますか？
homulaは400社超の支援実績を持つAIインテグレーターです。Claude Codeの導入戦略策定からMCP接続、チーム展開まで一気通貫で支援します。