導入

本書の読み方

本書は 3 部構成で進む。順番には意味がある。Prompt だけでは前提保持に失敗し、Context だけでは実行と検証が閉じず、Harness だけでは間違った前提を丁寧に壊すからである。

3部構成

Part I Prompt Engineering

最初に固めるのは、単一タスクの契約である。ここでは、Prompt Contract、requirements shaping、prompt eval を扱う。狙いは、AIエージェントが「何をやるべきか」を誤読しない状態を作ることにある。

Part II Context Engineering

次に固めるのは、判断材料である。repo context、task brief、Session Memory、skill、context pack を扱う。狙いは、AIエージェントが途中で前提を落とさず、必要な artifact へ迷わず辿り着ける状態を作ることにある。

Part III Harness Engineering

最後に固めるのは、実行境界と運用である。single-agent harness、verification harness、restart protocol、operating model を扱う。狙いは、AIエージェントが verify 前に止まらず、安全に retry / handoff / review できる状態を作ることにある。

2026年版の読み替えルール

2026 年版では、本文と repo artifact を durable な判断基準として読み、runtime detail は一次情報で補う。読み進めるときの優先順位は次のとおりである。

章本文で、どの failure mode を減らす章かを把握する
sample-repo と supporting artifact で、実際に残す入力と証跡を確認する
利用中ツールの official docs で、権限、protocol、pricing、実行境界の最新仕様を確認する

この順番を守ると、UI や CLI の細かい差分に引きずられず、仕事を閉じるための設計を先に固定できる。

3つの読み進め方

通読する読み方

最も推奨する読み方である。CH01 から CH12 まで順に読み、同じ recurring case に Prompt、Context、Harness がどう積み上がるかを見る。AIエージェントをチームへ導入したい読者には、この読み方が最も効く。

仕事から逆引きする読み方

すでに困っている failure mode が明確なら、そこから入ってもよい。

誤答が多い: CH02-CH04
前提を忘れる: CH05-CH08
verify 前に止まる、壊す: CH09-CH12

ただし、後ろの Part ほど前の Part を前提にする。必要に応じて前章へ戻る前提で読むことを勧める。

repo と併読する読み方

sample-repo を実際に開きながら読む方法である。この読み方では、各章末の 参照する artifact を使い、紙面で役割を理解した後に repo で現物を見る。最初から repo へ飛び続けるより、本文で役割を掴んでから確認する方が負荷は低い。

repo との付き合い方

この本の主役は repo ではなく本文である。repo は補助線であり、主張の根拠であり、再利用可能な artifact の置き場である。したがって、各章を読むときは次の順を守るとよい。

章の問題設定を読む
その章で増える artifact の役割を理解する
必要になったときだけ repo で現物を確認する

repo を先に眺めると、artifact の羅列に見えやすい。本文を先に読むと、なぜその artifact が必要かが分かりやすい。

利用中ツールとの差分をどう扱うか

本書で扱う Prompt、Context、Harness の考え方は、特定の UI や単一のモデル名に依存しない。一方で、実際に使う ChatGPT、coding agent、CLI、CI は時点によって振る舞いが変わる。

読み進めるときは、次の順で差分を確認すると安全である。

本書で固定したい artifact と判断基準を理解する
repository の最新差分と docs/pages-publishing.md、docs/operating-model.md を確認する
利用中ツールの official docs と protocol 仕様で、権限、実行境界、verify 手順の最新仕様を確認する

2026 年版では、OpenAI / Codex の公式 docs、MCP / A2A の仕様、GitHub / Anthropic / Google の一次情報を優先 source として扱う。本文と利用中ツールの挙動が一致しない場合は、artifact と verify の考え方を優先しつつ、個別手順は一次情報で読み替える。

recurring case の追い方

本書の recurring case は、章ごとに次のように姿を変える。

BUG-001: bugfix contract、single-agent harness、done criteria を学ぶ
FEATURE-001: product spec、acceptance criteria、ADR、context pack、verification harness を学ぶ
FEATURE-002: feature list、restart protocol、multi-agent planning を学ぶ
HARNESS-001: verification、evidence、review-ready な運用を学ぶ

1 つのケースが複数章に出てくるのは重複ではない。Prompt では契約、Context では前提、Harness では実行と検証というように、見る層が変わる。

章の見取り図

CH01 は failure model の定義である。CH02-CH04 で Prompt Engineering を固め、CH05-CH08 で Context Engineering を積み、CH09-CH12 で Harness Engineering を閉じる。付録はテンプレート集と用語集、後付けは source notes、読書案内、索引 seed、図表一覧方針であり、通読後の再参照装置として使う。

章ごとに見るべき問いは一貫している。

この章は、どの failure mode を主に減らすのか
この章で増える artifact は何か
その artifact は次の章でどう使われるのか

読み終わりの到達点

読み終わった時点で目指すのは、「AIエージェントが役立つ気がする」という感想ではない。次の状態に到達することである。

曖昧要求を実装準備ができた artifact に変換できる
AIエージェントに見せるべき context を分解し、保守できる
verify、handoff、review まで含めて作業を閉じる harness を設計できる

ここから本文に入る。まず CH01 で、AIエージェントが実務でどこで失敗するかを定義する。