2 つの投稿を取り込んで要約しました。動画が付いているのは投稿 1 だけで、投稿 2 は X の長文記事（動画なし・図 2 枚）です。動画は音声を文字起こしし、スライドを 30 秒ごとに切り出して内容を確認しました。

投稿 1：動画「Maximizing the value of Claude Code」

投稿本文の主張

上の注意のとおり、動画とは別の話（100 体のエージェント、Chief／PM エージェント、自己学習）

動画の正体

Anthropic のオンライン講座（スライド右上に「Claude Code workshop」、最後に「Thank you. Questions?」）。話し手は冒頭で Anthropic の所属と名乗る

話し手の狙い

「チェックリストは新機能が出るたびに古くなる。仕組みを理解すれば自分の環境で正しい手を考えられる」。ソフトは定額（席単位）から、タスクごとに払う時代になったので、効率よく使うことは仕事の一部

締めの一文

「Efficient doesn't mean fewer tokens. It means the ones you use go toward what you actually asked for.」（効率的とはトークンを減らすことではなく、使ったトークンが頼んだことに向かっていること）

1. 単位はどの契約でもトークン

• API・クラウド経由ならトークン単価で払う。Pro・Max・Team・Enterprise なら 5 時間枠と週枠だが、その枠もトークンで測られる
• スライドの価格表（100 万トークンあたりの米ドル、出典表記は claude.com/pricing。スライドの表示をそのまま転記、公式ページでの照合はしていない）：

2. 1 回のプロンプトの裏で起きていること

• 送られるのはプロンプトだけではない。セッション開始時に、システムプロンプト・組み込みツールの定義・作業ディレクトリと git の状態・CLAUDE.md・スキルと MCP の名前と説明が積まれ、その末尾に自分の一文が付いて 1 回のリクエストになる
• 「utils.test.ts の失敗テストを直して」と打つと、モデルはまずファイルを読むツール呼び出しを返す → Claude Code が実行して結果を返す → …と1 つのプロンプトが複数回（スライドの例では 5 回）のリクエストになり、往復のたびに文脈が伸びる
• トークンは 3 種類：入力（送るもの全部）・出力（最後の要約だけでなく、ツール呼び出し・編集・思考も含む）・キャッシュ（前回と同一の先頭部分）
• 値段の差の理由：入力は 1 回の処理でまとめて読めるので安い。出力は 1 トークンごとに文脈全体をもう一度通すので高い（const x = 1 を書くのに const で 1 回、x で 1 回…）。キャッシュは前回計算した内部状態を使い回すので最も安い

3. 最大のレバーはプロンプトキャッシュ

• 入るトークンが多く出るトークンは少なく、入る分のほとんどがキャッシュの枠内。健全なセッションでは入力の大半がキャッシュ読みになる。/usage の「Prompt cache」の行で自分の割合を確認できる
• スライドの倍率（通常の入力単価に対して）：キャッシュ読み 0.1 倍、5 分キャッシュの書き込み 1.25 倍、1 時間キャッシュの書き込み 2 倍
• 一致判定は先頭の 1 トークン目から。1 トークンでも違えば、そこから後ろは全部新規扱いで定価になる

4. キャッシュには寿命がある

• ~/.claude/settings.json（チームなら managed settings）の "promptCacheTtl": "1h"・"subagentPromptCacheTtl": "1h" で延ばせる
• ただし 1 時間キャッシュの書き込みは高い（2 倍）ので、数分以上離れずに作業し続ける人は 5 分のほうが安い。会議・昼休み・長いビルドで離れて同じセッションに戻る人なら 1 時間が得

5. 実践の 4 か条（スライド「In practice」）

1. モデルと effort はセッション開始時か /clear の直後に決める（失うキャッシュが無いうちに）
2. 途中でモデルを変えるなら、先に /compact してから変える（新モデルは短い要約だけ読めば済む）
3. 席を離れる前、キャッシュが温かいうちに /compact。compact は会話全体をもう一度読んで要約を書くので、戻ってきてからやると定価で全部読むことになる
4. 明日続けるなら、帰る前に compact しておく。冷えた状態の claude --resume は会話全体を定価で読み直す

6. 入れる量を減らす（文脈を賢く）

• モデルは掛け算。大きいモデルは 1 トークンあたりの計算量が多く、入出力の全トークンに効く。「小さいモデルは劣ったモデルではない」：Haiku＝素早い助手（小さい仕事・サブエージェント）、Sonnet＝ジェネラリスト（精密な編集・機械的な変更・文脈内のコードの質問）、Opus＝専門家（微妙なバグ・不慣れな領域・言葉にしにくい問題）、Fable＝誰も見たことのない問題のスペシャリスト
• 知っているファイルは @ で指定。事前にファイル内容が入るので、最初の読み込みの往復が消える（2 回 → 1 回）
• 新しいセッションで /context を見て、システムプロンプト・ツール・CLAUDE.md・スキル・MCP がそれぞれ何トークン食っているか確認する
• CLAUDE.md には全タスクに要るものだけ。「DB マイグレーションの手順」のようなタスク固有のものはスキルへ（スキルは名前と説明だけ常駐し、必要なときだけ本体が読まれる）。さらに、数か月前のモデルには必要だった指示が今は不要なことがある。/claude-api prompt-audit というスキルが CLAUDE.md とスキルを点検し、削れる箇所の差分を提案する
• MCP は使わないものを /mcp で切る。ツール定義は必要時読み込みになったので待機中は安いが、ゼロではない。gh・aws・gcloud のような CLI で済むなら、事前に何も読み込まれない
• コマンド出力は会話に残り続ける。巨大な出力は Claude Code がファイルに逃がすが、その閾値未満の「400 件のテストを 1 行ずつ表示」は全部が以後のリクエストに乗る。失敗だけ出す静かな reporter を使い、よく使うコマンドをそのままの形で CLAUDE.md に書いておく（例：npx vitest run <file> --reporter=dot）
• effort＝どこまで踏み込むか。「ボタンを緑に」で色だけ変える時もあれば、コードベースとデザインシステム全体を理解しようとする時もある。既定値で大抵十分で、Fable 5.1 のような大きいモデルは medium で優秀。結果が外れたら「知らなかったのか（→モデルを上げる）、頑張らなかったのか（→effort を上げる）」で切り分ける。やりすぎなら effort を下げる
• 文脈は足されるだけで減らない。タスクの間に /clear した場合と 1 本の長いセッションで続けた場合を比べると、後者はタスク 1 を最後まで持ち歩くので約 2 倍のトークンを使う（スライドの図の例）。道具は /compact（要約に置き換え。何を残すか指示もできる）・/rewind（直近の数ターンを捨てる）・/clear（新しい会話。後で戻りたいなら先に rename しておけば resume できる）
• サブエージェント：長いログ・リポジトリ全体・テスト全件のような「結論だけ欲しい調べもの」を別の文脈でやらせ、結論だけ本会話に戻す。サブエージェント自体はタダではなく（自分の入出力とキャッシュがあり、キャッシュは 5 分）、その仕事単体の合計は増えることもある。得るのは本会話が小さく保たれ、以後の毎ターンが安くなること。サブエージェントごとにモデルと effort を指定できる（掘るだけなら Haiku や Sonnet）

7. チームの管理者向け（managed settings）

管理コンソールで定義する 1 つの設定ファイルで、全員のインストールが起動時に読み込み、利用者は上書きできない。

• OpenTelemetry で見るべき 3 つ：(1) 入力に占めるキャッシュ読みの割合（本来は圧倒的に大きい。低い人はモデルや effort の切替でキャッシュを壊している）、(2) セッション内の入力量の推移（タスク中に上がり clear で落ちるのが健全。上がり続けるだけなら 1 本の終わらないセッションに住んでいるか、冷えたセッションを resume している）、(3) 人ごとのモデル別コスト（何でも大きいモデルでやっている人がわかる）。どれも「気づいたのでこうしてみて」の一言で直る
• 上限：Team・Enterprise では席ごとの 5 時間枠・週枠が天井。続けて働かせたいなら usage credits をオンにして、組織・グループ・個人ごとに支出上限を付ける。autoContinueAtUsageLimit は、枠に当たったセッションが待機し、枠のリセット後に自動でタスクを再開するかどうか（無人の長時間実行で効く）

8. 持ち帰る 3 つ

1. 最初に決めて、触らない：モデル・effort・MCP サーバー（途中で effort を変えてもキャッシュが壊れないのは Fable 5.1 だけ）
2. 何を入れるかを意識する：知っているファイルは @ で、CLAUDE.md は痩せさせ、タスク固有の手順はスキルに、うるさい作業はサブエージェントへ
3. 1 本のセッションを永遠に続けない：新しいタスクは /clear、離席前に /compact。冷えた resume は全体を 1 回定価で読む

そしてモデルはこのすべての掛け算。チームなら同じ選択を managed settings で。「価格や機能は変わり続けるが、この考え方は変わらないはず」。

投稿 2：記事「Harness Engineering: How to Build AI Agents That Don't Fall Apart」

形式

X の長文記事（本文テキスト・コード例 7 つ・図 2 枚。動画なし）

反応（取得時点）

表示 2,169,654・いいね 1,111・ブックマーク 3,155

一言でいうと

エージェントが失敗し続けるとき、問題は知能ではなく周りの環境。その環境が「ハーネス」で、それを設計するのがハーネス・エンジニアリング

問題提起

エージェントが失敗すると、多くの人はプロンプトを変え、次にモデルを変え、次に文脈窓を大きくする。それでも決定を忘れ、違うツールを使い、検証を飛ばし、同じループにはまる。モデルは推論エンジンにすぎず、何を見られるか・何に触れるか・セッションをまたいで何が残るか・何を証拠とみなすか・いつ止めるかを決めるのはハーネス。

• 「プロンプト・エンジニアリングは指示を良くする。ハーネス・エンジニアリングは指示が実行される条件を良くする」
• 同じモデルでも、チャット欄に置けば質問に答えるだけ、リポジトリ・端末・テスト・ブラウザ・記憶・隔離された worktree・レビューの輪の中に置けばソフトを出荷できる。重みは変わっていない、ハーネスが変わった
• 引用元として OpenAI の「Harness engineering: leveraging Codex in an agent-first world」（初期の遅れは能力不足ではなく環境が仕様化されていなかったため）、Anthropic の「Harness design for long-running application development」、Dario Amodei の発言、Claude Managed Agents の告知投稿（@claudeai、2026-04-08）が挙げられている（記事の主張で、一次情報での裏取りはしていない）

ハーネスの 7 つの仕事（記事の図より）

権限の例（記事のコード例をそのまま転記）：

READ FILES       allowed by default
RUN TESTS        allowed inside sandbox
WRITE FILES      allowed inside workspace
ACCESS NETWORK   scoped by task
DEPLOY           requires approval
DELETE DATA      requires approval

それ以降の主張

• 指示はインフラにする。大事な規則は 2 回書く：エージェントが理解できる「ガイド」と、迂回できない「機械的な検査」。例：「UI コードは DB を直接叩かない」というガイドと、UI がリポジトリ層を import したら lint が落ちる検査。次のエージェントは事故を覚えていなくていい、ハーネスが覚えている
• ループはハーネスのもの。「動くまでやり直せ」は制御ではない。証拠・再試行の上限・予算・人への引き上げ経路を持つ。どう直すかはモデルが決め、もう 1 回やってよいかはハーネスが決める（記事の例は 3 回まで build → verify、失敗したら差分を状態に積み、最後は人のレビューへ）
• 失敗はシステムを格上げする。RUN → OBSERVE → CLASSIFY → REPAIR → VERIFY → ACCEPT の流れで、分類した失敗を「ガイドを足す・テストを足す・道具を良くする・権限を締める・新しい状態を保存する」の恒久更新に変える。パッチは 1 回の実行を直し、ハーネスの変更はその後の全実行を良くする
• 頭脳・手・履歴を分ける。サンドボックスが死んでも履歴は残り、モデルが変わっても道具と方針は点検でき、再開時は成果物と痕跡から状態を組み立て直せる（Anthropic の Managed Agents の session・harness・sandbox の分離を例に）
• 実行ごとに「変更の領収書」を残す：使った文脈・方針の版・モデル・道具・テスト結果・人の修正回数・再試行回数・コスト・採用した成果物・巻き戻し地点。モデル更新の比較、退行の原因特定、監査ができる
• ループを閉じる最小のハーネスから始める。短く低リスクなら 1 プロンプト＋1 レビュー、ファイル編集・ネットワーク・PR 作成を伴う 6 時間の実行なら本物のハーネス。ハーネスは制御する失敗面より小さく
• 結び：プロンプト・エンジニアリングはモデルに何をするか伝え、コンテキスト・エンジニアリングは何を見せるか決め、ハーネス・エンジニアリングはモデルが行動する世界を作る。モデルは来月変わるが、道具・テスト・状態・方針・痕跡は改善し続けられる

チェックリスト（記事の原文をそのまま転記）

記事では「いくつも No なら、強いモデルに替えても信頼できるようにはならない。失敗が高くつくだけ」と続きます。

[ ] Is success defined before execution begins
[ ] Can the agent find the right project knowledge without loading everything
[ ] Does every tool have a clear contract and failure state
[ ] Is execution isolated from production systems
[ ] Are important decisions stored outside the conversation
[ ] Does every risky transition have evidence
[ ] Are irreversible actions protected by approval
[ ] Does every loop have a retry cap and budget
[ ] Can the run resume after interruption
[ ] Can you explain every tool call and state change
[ ] Does failure update a guide, test, tool, or policy
[ ] Can the final artifact be rolled back

life の運用に照らすと

要約とは別の欄に、life の現状と突き合わせた気づきを書きます（判断は shika に委ねます）。

• CLAUDE.md を痩せさせ、領域別の規則を .claude/rules/（paths で必要時読み込み）に逃がした 2026-09-16 の整理は、動画の「CLAUDE.md は全タスクに要るものだけ、タスク固有はスキルへ」、記事の「地図は小さく、詳細は対象の近くに」と同じ方向です
• 動画の話では サブエージェントのキャッシュは 5 分、途中で effort を変えてキャッシュが壊れないのは Fable 5.1 だけ、冷えた resume・離席後の compact は定価で全体を読む。秘書から長い調査を振って待つ使い方では、この 3 点がコストに効いている可能性があります（未計測。OpenTelemetry か /usage のキャッシュ率で確かめられます）
• 記事の「規則はガイドと機械的な検査の 2 回書く」は、life の bin/pages-deploy.sh（title が無いと終了コード 2）や bin/x-posts.sh --check がすでにやっている形です

取得と確認の方法