実践 Claude Code ハーネス設計完全ガイド - コンテキストエンジニアリングで AI エージェントを使いこなす

このセクションの導入として、難しい依頼は通るのに簡単な依頼を外すという 割り切れなさ の正体を認識し、凸凹した知性と目に見えない境界という2つの鍵からコース全体の土台を俯瞰できます。その先に立ち上がる ハーネス設計者 という役割も掴めます。

このセクションの導入として、AIの知性が凸凹になる原因と、その 見えない境界 という山場、そして測って構造で埋めるという結論までを俯瞰できます。直感が使えないという事実を正確に受け取ることが、コース全体の出発点になることも掴めます。

重いリファクタリングは通るのに集計の境界を1日ずらすという体験を、人間の 積み上げの前提 が通じない現象として理解できます。投げ直せば当たる揺らぎと、同じ場所を外し続ける 頑固な偏り を区別して受け取れるようになります。

検証できる領域では機械が自動で答え合わせを返せるため、AIが何百万回も訓練を回して能力を跳ね上げる仕組みを理解できます。Karpathy が指摘する スパイク が、偶然のムラではなく 答え合わせの有無 という理由から起きる再現性のある現象であり、人間にとっての難しさとは別物だと把握できます。

跳ね上がりが原因で凸凹がその結果という順番で用語を整理し、天才的な博識家と混乱した小学生が同じモデルに 同居 している状態を理解できます。能力を なだらかな坂 と捉えるイメージを手放す必要性も掴めます。

Mollick教授の 城壁 のたとえから、ソネットは書けるのにちょうど50語の詩は書けないという逆転を理解できます。壁は AI自身にも見えない ため、報告の言い切りの強さが判定材料にならないことも把握できます。

ボストン・コンサルティング・グループの758人が参加した 事前登録型 の実験を通じて、フロンティアの内側では片づけた数が12.2パーセント多く、25.1パーセント速く、品質も40パーセントを超えて向上したことを理解できます。もともと成績が下位だった人ほど43パーセント伸びる 底上げ が起きたことも把握できます。

AIが外すよう狙って設計された課題では、正解率が約84.5パーセントから約60から70パーセントへ落ち込み、成果が反転したことを理解できます。原因がAIの性能ではなく答えを問い直さない 認知的降伏 にあり、分かれ目は フロンティアの外側 に立ったことだけだったと把握できます。

人間にとっての難しさという物差しと、AIの凸凹を決めている 答え合わせの有無 は、測っている対象がまったく違うことを理解できます。より賢い物差しに取り替えても当てにいくかぎり外れは残るため、当てるのをやめて 確かめる側 へ回るという結論を掴めます。

ハーネスを、AIにできないことを一つずつ構造で埋めたものの集合体として定義できます。情報が届いていない、指示を守り切れない、出力を自分で評価できない、達成を確かめないという 定番の凹み に、それぞれ対になる構造が答えとして生まれていることを理解し、銀の弾丸 を探さない見方を持てます。

リトライや冗長化のように、信頼できない部品を構造で補うこと自体は エンジニアリングの伝統 であり、これまでの筋肉がそのまま効くことを理解できます。新しいのは、能力の輪郭が文書化されていないAIに対して、皆さんが 部品の計測者 を兼ね、現場だけの地図を自分で描く点だと把握できます。

仮説を立て、小さく試し、測り、手を打つという4つの段を回して、現場だけの凹みを自分で測る手順を理解できます。感想ではなく 答え合わせの形 にすること自体が仕事をAIの出っ張りの側へ引き寄せる打ち手になると掴め、月をまたぐ集計を例に実践できるようになります。

プロンプトは依頼と一体なので保存しても次の依頼では効かず、構造は依頼の外側にあるため置くだけで毎回効き続けることを理解できます。差の正体が書く速さではなく 手戻りの往復 が消えることにあり、全員に平等に効く モデルの更新 と違って構造は置いた人だけを動かすと掴めます。

AIの能力をなだらかな坂だと思い、見た目の難易度で任せて外して驚く人と、境界が見えない前提で 目測 をやめる人の違いを理解できます。分かれ目がプロンプトの巧拙ではなく 測る構造 を持っているかどうかであり、その構造を持つ人ほど大胆に任せられることを掴めます。

スパイクという原因、見えない境界という山場、そして凹みを構造で埋めた集合体という結論までを一本に結び直して理解できます。定番の凹み は他人が測ってくれた地図を受け取り、現場だけの白紙は自分で測って埋めるという 2階建て の付き合い方で臨む心構えを持てます。

AIの知性は凸凹で境界が見えないから凹みを構造で埋める、というコース全体の土台を理解できます。次に学ぶ コンテキストエンジニアリング が、必要な情報がAIの手元に入っていないという凹みへの答えであり、Write、Select、Compress、Isolate の4戦略で埋めるという見通しを持てます。

このセクションの導入として、コンテキストエンジニアリングが「AI が見る世界を設計する技術」であり、AI の成果が「何をどう見せるか」で決まることを理解できます。ハーネス設計の中核を4つの戦略として体系的に学ぶ準備が整います。

このセクションで学ぶ Write・Select・Compress・Isolate の4つの戦略の役割を俯瞰し、それぞれが「情報を外に書き出す」「必要な情報だけ取り込む」「圧縮する」「文脈を分離する」という狙いを持つことを把握できます。

コンテキストウィンドウが「LLM が一度に参照できる情報の総量」であり、人間のワーキングメモリと同じく有限であることを理解できます。情報を詰め込みすぎると精度が下がるため、「最小限の高シグナルなトークンで最大の成果を引き出す」という設計指針を説明できるようになります。

Write 戦略を理解し、CLAUDE.md・進捗ファイル・メモリファイルなど外部記憶に知識を書き出すことで、セッションを超えて文脈を永続化できる仕組みを説明できるようになります。「毎朝記憶がリセットされるチームメンバー」の比喩で、なぜエージェントに自分でメモを取らせる必要があるのかを語れます。

Select 戦略を理解し、事前に全部読み込むのではなく必要になった時に必要な情報だけをジャストインタイムで取り込む設計を説明できるようになります。軽量な識別子を渡して段階的に情報を開示する「プログレッシブ・ディスクロージャー」の考え方を、自分の設計に取り入れられます。

Compress 戦略を理解し、コンパクション（要約）とツール結果クリアリングという2つのテクニックで限られたコンテキストウィンドウを最大活用する方法を説明できるようになります。設計判断や未解決の課題は保持し、古いツール結果や冗長な出力は除去するという保持・除去の判断基準を持てます。

Isolate 戦略を理解し、サブエージェントに独立したコンテキストウィンドウを持たせて文脈を分離し、結果を要約だけメインに返す設計を説明できるようになります。大量のトークンを消費する作業でメインの文脈を汚染せず、並列処理で時間を短縮できる仕組みを理解できます。

Write・Select・Compress・Isolate の4戦略がどう合流して最適なコンテキストを生み出すかという全体像を説明できるようになります。「最も強力なモデルで最小限のプロンプトから始め、失敗を観察して段階的に追加する」という、過剰設計を避ける原則を実践に活かせます。

このセクションの要点として、Write・Select・Compress・Isolate の4戦略それぞれの狙いを整理して再確認し、AI エージェントが参照する情報を最適に設計する全体像を自分の言葉で語れるようになります。

次のセクションで学ぶ Claude Code の6つの制御インターフェースへの橋渡しとして、4つの戦略を具体的な機能でどう実現するかという問いを持ち、理論を実践につなげる見通しを得られます。

このセクションの導入として、コンテキストエンジニアリングの4戦略を Claude Code でどう実現するかを学ぶことを理解し、ハーネス設計のための6つの制御インターフェースが存在することを把握できます。

このセクションで学ぶ CLAUDE.md・Rules・Hooks・Skills・サブエージェント・MCP サーバーという6つの制御インターフェースを俯瞰し、それぞれがコンテキストエンジニアリングの戦略と結びついていることを把握できます。

CLAUDE.md がプロジェクトの取扱説明書として知識と規約を永続化する Write 戦略の実装であることを理解できます。個人・プロジェクト・ローカルの3つのスコープを使い分け、具体的に書く・理由を添える・定期的に更新するという効果的な記述のコツを実践できるようになります。

効果的な CLAUDE.md の4つの構成要素、プロジェクト構造・コマンド・コーディング規約・やってはいけないことを説明できるようになります。「Claude が推測できない情報を理由付きで書く」という原則を理解し、ルールに理由を添えることでエージェントの応用的な判断力を引き出せるようになります。

Rules が CLAUDE.md と異なり、ファイルパターンにマッチした時だけ条件付きでコンテキストに注入される Select 戦略の実装であることを理解できます。フロントマターでファイルパターンを指定し、ファイル種別ごとに指示を分離してコンテキストウィンドウを効率化する設計を説明できるようになります。

テストファイル用 Rules の具体的な書き方を理解し、フロントマターの paths に glob パターンを指定する方法を説明できるようになります。ルールに「なぜそうするのか」の理由を添えることで、エージェントが類似の判断にも応用できるようになる効果を実感できます。

API ハンドラー用 Rules の実例を通じて、ファイル種別ごとに規約を分離して自動適用する設計を説明できるようになります。API のコードを触る時だけバリデーションやエラー形式などの固有ルールが注入される仕組みが、Select 戦略の実践であることを理解できます。

Hooks がツール実行の前後に検証処理を差し込むミドルウェアパターンであることを理解し、PreToolUse・PostToolUse・Notification という主要な Hook タイプの役割を説明できるようになります。AI の行動をリアルタイムに制御することで危険な操作のリスクを減らせる仕組みを把握できます。

settings.json で Hooks を定義する方法を理解し、イベント・matcher・コマンドの3要素を組み合わせて柔軟なガードレールを構築できるようになります。matcher の正規表現で対象ツールを指定する方法や、async による非同期実行の使いどころを説明できます。

Skills が再利用可能な手順書（レシピ）であり、スラッシュコマンドで呼び出した時だけコンテキストに読み込まれる Select 戦略の応用であることを理解できます。CLAUDE.md・Rules・Skills の読み込みタイミングの違いを説明し、複雑な手順を標準化して同じ品質で繰り返し実行できる利点を把握できます。

Skill ファイルの構成、フロントマターと本文のステップバイステップ手順、$ARGUMENTS プレースホルダーによる引数の受け取りを理解し、再利用可能な手順書を自分で組み立てられるようになります。

サブエージェントが独立したコンテキストウィンドウで複雑なタスクを分離・並列実行する Isolate 戦略の直接的な実装であることを理解できます。Explore・Plan・General Purpose などにタスクを委任し、結果を要約として受け取ることで、メインの文脈を圧迫せず大規模な処理を行える仕組みを説明できるようになります。

MCP サーバーが外部システムとの接続を標準化された方法で構造化する仕組みであることを理解できます。ツール定義に型情報と説明を含めることで AI が正しく使いこなせること、外部システムの情報を Select 戦略のようにジャストインタイムで取得できることを説明できるようになります。

6つの制御インターフェースを戦略・使いどころ・読み込みタイミングの軸で使い分けられるようになります。「常時読み込みは最小限にする」という設計原則を理解し、CLAUDE.md に何でも書くのではなく Rules や Skills に適切に分離する判断ができるようになります。

このセクションの要点として、6つの制御インターフェースそれぞれの役割とコンテキストエンジニアリング4戦略との対応関係を整理して再確認し、効果的なハーネス設計の第一歩を踏み出せる状態になります。

次のセクションで Hooks を深掘りする準備として、CLAUDE.md の「確率的な指示」と Hooks の「決定論的な制御」の違いという論点を意識し、続く学習の焦点を掴めます。

このセクションの導入として、Hooks が他の制御インターフェースとは根本的に異なる特別な仕組みであり、AI エージェントの行動を確実に制御するガードレールを設計できることを理解する出発点に立てます。

このセクションで学ぶ4つのポイント、確率的指示と決定論的制御の違い・フックスクリプトのインターフェース・3つのフックタイプの実践・Hooks と CLAUDE.md の使い分けを俯瞰し、学習の地図を持てます。

CLAUDE.md の指示が「確率的なお願い」であり、AI は高い確率で従うが100%の保証はないことを理解できます。一方 Hooks は exit 2 によって「決定論的な強制」を実現することを把握し、本番データの保護など失敗が許されない場面でこの違いが決定的になる理由を説明できるようになります。

Hooks の3つのイベントタイプ、PreToolUse・PostToolUse・Notification と、ツール実行ライフサイクル上でそれぞれがいつ発火するかを説明できるようになります。exit 0 で実行に進み exit 2 でブロックするという基本フローを理解できます。

フックスクリプトのインターフェース仕様、stdin で渡される JSON・exit 0 の許可・exit 2 のブロック・stdout の Claude へのフィードバック・stderr のユーザー表示を理解できます。JSON は Claude Code 本体が自動的に組み立てて渡すものであり、自分が書くのはスクリプト側だけだと整理できるようになります。

フックスクリプトの具体例を通じて、stdin から流れてくる JSON を jq で解析し、実行しようとしているコマンドを抽出する処理を読み解けるようになります。入力リダイレクトや /dev/stdin といった仕組みも含めて、スクリプトの起点を理解できます。

stderr と stdout の役割の違いを理解し、リダイレクトで stderr に出してユーザーの画面に警告を表示し、リダイレクトなしの echo で stdout に出して Claude のコンテキストに情報を渡す使い分けを説明できるようになります。Claude が stdout の内容を読んで代替案を検討する仕組みを把握できます。

exit code が制御を確定させる役割を理解し、exit 2 で確実にブロック・exit 0 で許可という判定を説明できるようになります。stderr でユーザーに警告し、stdout で Claude に状況を伝え、exit 2 でブロックするという3つの出力が連携して安全なガードレールを形成する全体像を語れます。

PreToolUse フックが実行前に検証を行い、exit 2 で確実に操作をブロックする役割を理解できます。ブロック理由を stdout で返すと Claude が代替案を考えること、破壊的な Bash コマンドや本番環境への危険な操作を防ぐ典型的な使い方を説明できるようになります。

validate-bash.sh の実装を通じて、危険なコマンドのパターンリストとマッチングして exit 2 でブロックする PreToolUse フックを設計できるようになります。パターンを追加するだけでガードレールを拡張でき、人の注意力ではなく仕組みでチームの「やらかし」を防げることを理解できます。

Notification フックがツール実行フローの外で、ユーザーの注意を必要とするタイミングに発火する仕組みを理解できます。長時間タスクの完了通知や承認待ちの通知を、デスクトップ通知・Slack・ターミナルのベル音などに送る使い方を説明できるようになります。

notify-done.sh の実装を通じて、osascript によるデスクトップ通知・ベル文字によるビープ音・Slack Webhook への POST という3つの通知方法を設計できるようになります。環境に合わせて通知先を選び、複数を組み合わせる方法を理解できます。

settings.json で PreToolUse・PostToolUse・Notification の3つのフックを統合する方法を理解できます。timeout による無限ループ防止、async による非同期実行、matcher への空文字列指定で全ツールにマッチさせるなど、実践的な設定のポイントを説明できるようになります。

Hooks と CLAUDE.md の使い分けを「失敗が許されないか」「柔軟な判断が必要か」という判断フローで決められるようになります。決定論的な Hooks で絶対に守るべきルールを強制し、確率的な CLAUDE.md で柔軟なガイドラインを伝える、二層構造の設計判断ができるようになります。

このセクションの要点として、確率的指示と決定論的制御の違い・フックのインターフェース仕様・3つのフックタイプ・CLAUDE.md との使い分けを整理して再確認し、堅牢なガードレールを設計できる状態になります。

次のセクションで学ぶエージェント設計パターンの原則への橋渡しとして、Anthropic の「Building Effective Agents」に基づくルーティング・ACI 設計・投票という論点を意識し、Hooks の設計思想とのつながりを掴めます。

このセクションの導入として、Anthropic 公式の「Building Effective Agents」に基づき、エージェントシステムの設計パターンそのものに焦点を当てることを理解できます。ワークフローとエージェントという2分類や「シンプルさを維持する」という基本スタンスを把握できます。

このセクションで学ぶ3つのパターン、ルーティング・ACI 設計・投票を俯瞰し、それぞれが入力の振り分け・ツール接点の最適化・複数実行による品質合意という狙いを持つことを把握できます。

ルーティングパターンを理解し、入力をまず分類してカテゴリごとに最適化された専門ハンドラへ振り分ける設計を説明できるようになります。各ハンドラが専門のプロンプト・ツール・コンテキストを持つことで、汎用エージェント1つより高い精度が得られる理由を語れます。

Claude Code の Rules が「ファイルパスによるルーティング」であることを理解し、一般的なルーティングと構造が同じだと再解釈できるようになります。AI が分類する代わりにファイルパスのパターンマッチで決定論的に分類することで、分類精度を100%保証する設計の利点を説明できます。

ACI（Agent-Computer Interface）設計が、人間向けの UI/UX 設計と同じように AI エージェント向けにツールの使い勝手を設計する考え方であることを理解できます。Anthropic が「ツールの最適化がプロンプト全体の最適化より時間を要した」と報告した事実から、ツール設計の重要性を実感できます。

ACI 設計の4つの原則、思考のための余裕・自然な形式・オーバーヘッド排除・明確な命名を説明できるようになります。「ジュニア開発者向けのドキュメントと同等の品質」という基準で、エージェントが誤解なくツールを使える設計を組み立てられるようになります。

相対パスと行番号指定の悪い ACI 設計が失敗を招き、絶対パスと内容マッチングの良い設計が精度を高める具体例を理解できます。Anthropic が相対パスを絶対パス必須に変えただけでファイル編集の精度が劇的に向上した事実から、わずかな設計差が信頼性を大きく左右することを説明できるようになります。

投票パターンを理解し、同じタスクを複数回独立に実行して結果を集約・統合することで合意を形成する設計を説明できるようになります。Isolate 戦略の並列実行が「異なるタスク」だったのに対し投票は「同一タスク」である違いや、AI 出力のばらつきを多数決で補って信頼性を高める仕組みを語れます。

コードレビューでセキュリティ・パフォーマンス・保守性の3視点を並列に評価する、投票パターンの発展形を理解できます。2つ以上のエージェントが指摘した問題を高確度の問題として優先対応する統合方法を説明し、Claude Code のサブエージェントで実現する方法も把握できます。

ルーティング・投票・パイプラインの3パターンを組み合わせて段階的にシステムを成長させる設計を理解できます。「複雑さは実測で効果が証明された場合のみ追加する」という Anthropic の原則に従い、シンプルなプロンプトから始めて必要に応じて専門化や信頼性向上を加える進め方を説明できるようになります。

このセクションの要点として、ルーティング・ACI 設計・投票の3パターンと「シンプルから始める」共通原則を整理して再確認し、エージェント設計の基礎を自分の言葉で語れるようになります。

次のセクションで学ぶ Generator-Evaluator パターンへの橋渡しとして、投票パターンで得た「複数視点で評価する」重要性を踏まえ、生成と評価を構造的に分離して品質を改善する発想を予習できます。

このセクションの導入として、Generator-Evaluator パターンが AI の出力品質を劇的に改善する手法であり、その効果が AI の構造的な弱点である自己評価バイアスを正面から解決することに由来すると理解する出発点に立てます。

このセクションで学ぶ3つのポイント、自己評価バイアスの原因と克服・Generator-Evaluator の設計原理・Claude Code での実装方法を俯瞰し、学習の道筋を持てます。

同じエージェントに生成と評価の両方をさせると、品質が平凡でも自信を持って成果を称賛してしまう自己評価バイアスを理解できます。生成時の文脈と思考パターンがそのまま評価をバイアスするという構造的な原因を、Anthropic の観察に基づいて説明できるようになります。

敵対的生成ネットワーク（GAN）に着想を得て、生成と評価を完全に分離するアーキテクチャの原理を理解できます。Generator は成果物の作成に集中し、Evaluator は独立したコンテキストで品質を判定する。「独立した評価者を懐疑的にチューニングする方が自己批判より簡単」という分離の理由を説明できるようになります。

グレーダブル・クライテリア（採点可能な基準）の考え方を理解し、「良い・悪い」という主観表現ではなく低スコアと高スコアの具体的な状態を定義することで Evaluator が客観的に判定できる仕組みを説明できるようになります。基準を evaluation-rubric.md に切り出す Select 戦略の実践も把握できます。

evaluation-rubric.md の具体的な書き方を理解し、各基準を1・3・5の3段階で定義し、重みと合格ラインを数値で明示する方法を説明できるようになります。評価基準の重み付けを「損失関数」のように設計して Generator の出力方向を制御するという Anthropic の知見を実践に活かせます。

スプリントコントラクトが、Generator と Evaluator が作業開始前に完了基準を合意する仕組みであることを理解できます。高レベルの仕様と検証可能な成果のギャップを埋め、評価者が「そんなの聞いてない」と言わないようにする役割を説明できるようになります。

スプリントコントラクトの具体例を通じて、エージェント間のコミュニケーションをファイルベースで行い認識のずれを防ぐパターンを理解できます。specs/sprint-contract.md というファイルパスの設計が、マルチエージェント環境でエージェントが自律的にファイルを発見できる信頼性につながることを説明できるようになります。

スプリントコントラクトの3つの必須セクション、実装スコープ・完了基準・検証方法を読み解けるようになります。「何を」作るかは書くが「どう」作るかは Generator に任せること、完了基準は二値で判定できる検証可能な項目だけを書くというコツを理解できます。

スプリントコントラクトと評価ルーブリックの役割分担を理解できます。前者は「何を作るか・できたか」の二値判定、後者は「どの程度良いか」の段階評価という関心の分離が、ソフトウェア設計の単一責任の原則であり、各エージェントが必要な情報だけにアクセスする Select 戦略の実践であることを説明できるようになります。

Playwright によるライブ検証を組み込んだ評価パイプラインを理解できます。コードレビューではなく実際にアプリケーションを操作して UI・API・データベースの状態を確認することが品質保証の要であり、不合格なら具体的なフィードバックとともに Generator に差し戻す流れを説明できるようになります。

反復を何回まわすのが効果的かの相場観を持てるようになります。フロントエンドは5〜15回、フルスタックは3〜5スプリントという目安と、改善が前半に集中する収穫逓減の法則を理解し、闇雲に回数を増やさない判断の土台を身につけます。

反復をどこで止めるべきかを、感覚ではなく基準で見極められるようになります。品質スコア・Critical項目・コストという3つの観点を組み合わせ、完璧ではなく品質基準を満たす最小限の反復回数を選ぶ考え方を身につけます。

このセクションの要点として、自己評価バイアス・分離の効果・グレーダブル基準・ライブ検証を整理して再確認し、生成と評価を分離して品質を保証する設計を自分の言葉で語れるようになります。

次のセクションで学ぶ /goal コマンドへの橋渡しとして、Generator-Evaluator の「別の評価者に判定させる」発想が、そのまま Claude Code の組み込みコマンドとして箱詰めされていることを予習できます。

このセクションの導入として、/goal コマンドが「完了条件を渡すとAIが達成まで自走する」仕組みであり、正しく使う鍵が条件の書き方に集約されることを理解し、学習の見通しを持てます。

このセクションで学ぶ3つの論点、条件駆動の自律終了・評価器に証拠を出させる条件設計・暴走ガードと運用を俯瞰し、地図を持った状態で本編に入れるようになります。

毎ターン承認を繰り返す「子守り」の負担を認識し、完了条件を1つ渡して席を立てる /goal の価値を、自分の日々の作業に引き寄せて説明できるようになります。

/goal が完了条件を設定し達成まで自走して自動的にクリアするコマンドであること、Claude Code v2.1.139 以降が必要で1セッションにつき目標は1つであることを説明できるようになります。

毎ターン後に別の小型モデルがトランスクリプトを読み合否と理由を返すこと、/goal が Generator-Evaluator と Stop hook を箱詰めした組み込みプリミティブであることを理解できます。

評価器は画面に表示された内容だけで判定しコマンドを実行しないため、正しい使い方とは「証拠をトランスクリプトに出させる条件を書くこと」だと説明できるようになります。

「きれいにして」のような測定不能な曖昧条件が、yes に転じる瞬間を持たずにさまようか完了したつもりで止まる理由を、実在の体験談を通じて理解できます。

良い条件が測定可能な終了状態・述べられたチェック・重要な制約の3点で構成されること、とりわけ証明方法まで条件に書き込む重要性を説明できるようになります。

検証だけを条件にすると全チェック通過でも使い物にならない報酬ハッキングが起きること、抜け道を塞ぐ制約で「測っていないもの」を守る書き方を理解できます。

同じゴールを曖昧な条件から測定可能な条件へ、さらに抜け道を塞ぐ制約へと書き直す一連の流れを、test/auth の例で自分でも辿れるようになります。

条件は4000文字まで具体的に書けること、品質を形容詞で述べず既知の良い手本を指し示すことで、終了コードより表明しにくい品質も条件に落とせることを理解できます。

or stop after N turns などのターン句・時間句で暴走を止める設計と、開けっ放しの目標を走らせ続ける危険を説明できるようになります。

評価トークンが無視できる一方で積み上がるメインターンが実コストであること、trust ダイアログや disableAllHooks といった実行要件を把握できます。

引数なしでの状態確認・clear とそのエイリアス・--resume での復元・-p でのヘッドレス実行・Ctrl+C という /goal の実務操作を一通り使えるようになります。

このセクションの要点、条件駆動の自律終了・表示された証拠だけを見る評価器・良い条件の3点セット・暴走ガードを整理して再確認できます。

次に学ぶマルチエージェント設計への橋渡しとして、2エージェントの協調を超え、複数のエージェントで複雑なタスクを分割統治する発想を予習できます。

このセクションの導入として、単一エージェントでは扱いきれない複雑なタスクが存在し、その解決策として複数のエージェントを協調させるマルチエージェント設計が必要になることを理解できます。

このセクションで学ぶ3つのパターン、オーケストレーター・ワーカー・シーケンシャルパイプライン・ファンアウト・ギャザーを俯瞰し、それぞれが委任・直列分業・並列実行という異なる協調の形を持つことを把握できます。

単一エージェントの3つの限界、コンテキスト容量・専門性の希釈・処理時間を説明できるようになります。各エージェントが専門領域に特化した独立コンテキストを持つことで精度と速度を改善できること、「トークン使用量だけで性能の80%の分散を説明できる」という Anthropic の実測の意味を理解できます。

オーケストレーター・ワーカーパターンを理解し、リードエージェントが全体戦略を策定してタスクを分解し、専門ワーカーに委任して結果を統合する設計を説明できるようになります。複数ファイルにまたがる変更や大規模リファクタリングなどの適用場面を判断できます。

シーケンシャルパイプラインパターンを理解し、各エージェントが1工程を担当し前工程の出力を次工程の入力とするリレー方式を説明できるようになります。Planner から Generator、Evaluator へとつなぐ典型例を通じて、各工程が独自のコンテキストで専門性を発揮する利点を語れます。

ファンアウト・ギャザーパターンを理解し、独立した複数タスクを同時に並列実行して結果を集約する設計を説明できるようになります。各エージェントが固有のキーに結果を書き込んで競合を防ぐこと、Anthropic が並列実行で処理時間を最大90%短縮した事実を把握できます。

3つのパターンをタスク特性に応じて使い分けられるようになります。タスク間の関係（相互依存・前後依存・独立）・動的分解の要否・速度・複雑さという軸で判断し、「シンプルなパターンから始めて必要に応じて移行する」という原則を実践できるようになります。

Anthropic がマルチエージェントリサーチシステムの構築で得た実践的なコツ、クエリの複雑さでスケールする・ツール選択が成果を左右する・メモリに計画を保存するを説明できるようになります。「プロンプトエンジニアリングが主要なレバー」であり、複雑な制御構造より適切なプロンプト設計が効果的だという知恵を理解できます。

このセクションの要点として、3つのマルチエージェントパターンとその使い分け、「シンプルから始めプロンプト設計を最優先する」共通原則を整理して再確認し、複雑なタスクの分割統治を自分の言葉で語れるようになります。

次のセクションで学ぶ長時間エージェントの管理への橋渡しとして、数時間に及ぶ長いタスクでコンテキストの壁をどう越えるか、構造化ハンドオフでセッション間の連続性をどう確保するかという論点を意識できます。

このセクションの導入として、AI エージェントに長時間のタスクを任せるときに避けて通れない「コンテキストの壁」を、適切な設計で克服できることを理解する出発点に立てます。

このセクションで学ぶ3つのテクニック、コンテキスト不安への対策・構造化ハンドオフ・進捗管理の仕組みを俯瞰し、長期タスクでセッションを超えて成果を積み上げる学習の道筋を持てます。

コンテキスト不安を理解し、コンテキストウィンドウの容量が埋まってくるとモデルが残り容量を察して作業を早期に切り上げ、品質の手抜きや楽観的な完了宣言が起きる現象を説明できるようになります。エージェントの「完了しました」を鵜呑みにしないという視点を持てます。

コンパクションと全リセットを比較し、Anthropic が推奨する「全リセット＋構造化ハンドオフ」を理解できます。コンパクションの「何が失われたかわからない」リスクを回避し、完了したタスク・未完了タスク・重要な判断・次のアクションを引き継ぎ文書で渡す設計を説明できるようになります。

進捗ファイル（claude-progress.txt）の実践例を通じて、完了した作業・現在の状態・次のアクションという3つのシンプルなセクションで状況を引き継ぐ設計を理解できます。エージェント自身が各タスク完了時に更新することで、新しいセッションが数秒で状況を把握できる仕組みを説明できるようになります。

フィーチャーリスト（feature_list.json）の実践例を通じて、各機能をカテゴリ・説明・検証ステップ・合否で管理する設計を理解できます。passes フィールドの変更のみ許可しテスト項目自体をロックすることで、エージェントがテストを消して「全合格」にする不正を防ぐという重要なルールを説明できるようになります。

Initializer エージェントと後続の Coding エージェントの役割分担を理解できます。初回セッションで環境構築・フィーチャーリスト作成・進捗ファイル初期化・初回コミットを行い、2回目以降は進捗確認から実装・テスト・更新のサイクルを回す、役割を分離した長時間プロジェクトの構成を説明できるようになります。

スタートアップパターンを CLAUDE.md に組み込む実践を理解できます。セッション開始時に必ず実行する手順、作業ディレクトリ確認・git ログ確認・進捗ファイル読み込み・タスク選択・アプリ起動を明記し、「スキップしてはいけない」と指示することで全セッションに永続適用する Write 戦略の実践を説明できるようになります。

コンテキスト毒性を理解し、エージェントの幻覚（ハルシネーション）がコンテキストに残留すると以降の推論が汚染された前提で進む危険を説明できるようになります。定期的な全リセット・外部検証の組み込み・ファクトチェック・検証済みの事実だけを記録するという4つの対策を実践できるようになります。

このセクションの要点として、コンテキスト不安・全リセットと構造化ハンドオフ・進捗管理・コンテキスト毒性への対策を整理して再確認し、コンテキストの壁を越える設計術を自分の言葉で語れるようになります。

次のセクションで学ぶエージェント向けツール設計への橋渡しとして、ACI 設計の4原則をさらに踏み込み、ツール数を絞る選択的実装やコンテキスト効率の設計といった実践的なテーマを予習できます。