この記事でわかること
- AIハーネス（AIの外側に置く道具立て）とは何か
- 「足場」と「骨格」を分けるための3つの条件
- Anthropic公式Cookbookが示すコスト最適化7ステップと、その並び順の理由
- 採用されなかったレバーの記録と、そこから読める判断の条件
- 人の確認を外す前に測るべきこと。一致率だけでは足りない理由
目次
- AIハーネスとは何か
- 足場と骨格を分ける
- なぜ「足す力」しか働かないのか
- Anthropic公式Cookbookが示す7ステップ
- 採用されなかったレバーの記録
- 外す前に測る
- 外してはいけないもの
- 今日やる3つの質問
- まとめ
- 出典と関連リンク
なお本記事で扱うclaudecode道場（claudedojo.com）は、malna株式会社が独自に提供する学習サービスです。Anthropicが提供する製品や、記事内で引用している同社の公開資料とは別のものとしてお読みください。
当社がClaude Codeを本格的に使い始めて数か月が経ったころ、自分で書いたCLAUDE.mdを開いて手が止まりました。ある1行が、なぜそこにあるのか説明できないのです。書いたのは私自身でした。
当時は必要な記述でした。AIがうまく処理できないので指示を追加し、確認する手順も追加し、補助するスクリプトまで用意する。足せば足すほど、AIが賢くなったように感じていた時期です。
とはいえ、AIは変わります。数か月前にできなかったことが、モデルの更新後には普通にできるようになるのに、周囲に作った確認工程だけはそのまま残ります。
いま難しいと感じているのは、「何を外していいか」の判断です。以下、その基準を順に書いていきます。
1. AIハーネスとは何か
AIハーネスとは、AIモデルの外側に置く「仕事を成立させる道具立て」のことです。
具体的には次のようなものが含まれます。
- AIから見える情報（CLAUDE.mdやプロジェクト資料）
- 守るべきルールと禁止事項
- 使えるツール（MCPサーバー、スキル、社内API）
- 作業手順の記述
- 出力を確かめる装置（Hooks、テスト、レビュー工程）
- 異常を知らせる通知
- 実行記録（ログ）
- 失敗したときに戻せる履歴
モデルの性能だけを比べていると、現場で起きている差を説明できないことがあります。同じClaudeを使っていても、ある会社ではAIが最後まで自走し、別の会社では毎回人が細かく指示しなければ止まる。
この差を生む要因のひとつが、AIの周囲に何を置いたかです。要因は他にもあります。モデルの版、任せている仕事の難しさ、データの整い方、権限の設計も結果を左右する。そのうえで、同じモデルで同じ業務を回しても差がつく部分として、周囲の道具立てを取り出して考えます。
人でも似た構図があります。優秀な人を採用しても、仕様書がなく、何を正常と見るかの物差しもなく、権限範囲も不明で、問題が起きたときにどこを見ればいいかもわからない。これでは力を発揮できません。
AIの場合、そこにもう一段の制約が加わります。人なら過去の会議を覚えていて、隣の席に質問でき、空気を読める。AIにその前提を期待できません。必要な情報が実行時に届かなければ、AIにとっては存在しないのと同じです。
だから、頭の中にある物差しを書き出します。Slackにしか残っていない決定事項はAIから参照できる場所へ移し、繰り返し発生する段取りは文章に落とす。
ここで1つ注意があります。AIから読める場所へ移すときは、誰に読めるようになるかを同時に決めてください。顧客情報や人事情報が、必要のないセッションやサブエージェントから読める状態になっていないか。ログやキャッシュを経由して外に出ないか。利便性のために公開範囲を広げすぎる事故は、この段階で起きます。
これがハーネスです。当社の場合、CLAUDE.mdの書き方そのものが最初のハーネス設計でした（CLAUDE.mdの書き方完全ガイド）。
そして、ここから別の問題が始まります。書き出した文書は、放っておくと増え続けるのです。
2. 足場と骨格を分ける
私はいま、ハーネスを見るときに「足場」と「骨格」を分けて考えています。
この区別がないと、「AIが賢くなったから全部外そう」という雑な決め方になりがちです。逆に「念のため残しておこう」と考えて、何年も文書が増え続ける。
足場は、その時点のAIの弱さを補うために足した道具です。
- AIがよく間違えるから、人がもう一度確認する
- AIが段取りを忘れるから、同じ説明を毎回渡す
- AIが必要な情報を取りに行けないから、事前に大量の情報を詰め込む
足場には暗黙の前提があります。「いまのAIには、これができない」という前提です。前提が変われば、足場の意味も変わります。
骨格は違います。
- 何を正常とするかという基準
- どこまで操作していいかという権限範囲
- 何が起きたかを確認できる記録
- 失敗したときに止める装置
- 元に戻す方法
こうしたものは、AIが賢くなるほど重要になります。AIが自律して動くほど、人が途中経過を見なくなるからです。
ハーネスの中身は、「後で外す道具」と「むしろ残すべき土台」が混ざった状態にあります。
では、どう見分けるか。以前の私は問いを1つに絞っていました。「それを外して間違いが起きたとき、こちら側で気づけるか」という問いです。
いまはこれを必要条件のうちの1つとして扱っています。気づけるだけでは足りない場面があるからです。データを消す操作、社外への誤送信、権限を超えた操作、個人情報の流出、二重課金。これらは検知できたところで元に戻りません。気づいた時点で損害が確定しています。
そこで、次の3つをそろえて判断します。
- 検知できるか：間違いが起きたとき、こちら側で気づけるか
- 影響を隔離できるか：間違いの範囲が、こちらの想定内に収まるか
- 元に戻せるか、または気づくまでの損失を許容できるか：取り返しがつくか
3つそろえば足場として外しにいけます。1つでも欠けていれば、外すより先に、その条件を満たす仕組みを作るほうが早い。
3. なぜ「足す力」しか働かないのか
ハーネスが太る原因は、技術と運用の構造の両方にあります。
考えてみてください。何か問題が起きて、再発防止としてチェック項目を1件増やしたとします。その変更はGitの履歴に残ります。指示書にも1行残り、レビューの記録にも残る。
では半年後、モデルが改善してそのチェックが不要になったとします。
何もしなければ、その事実はどこにも記録されません。チェック項目は残ったままです。
ハーネスには構造的に「足す力」が強く働きます。「外す力」のほうは、意識して仕組みにしないと働きません。期限付きのフラグ、定期レビュー、使われていない分岐を検出する計測。こうした装置を置けば「外す力」も仕組みになりますが、置かなければ増える一方です。
ここが厄介な部分です。ハーネスの肥大化は突然起きません。一つずつは合理的な変更です。だから発見が遅れます。気づいたころには「なぜこの指示があるのか誰も知らない」という状態になっています。
作った理由を説明できない仕組みを、AIだけは毎回読んでいる。この状態は、毎回読ませているぶんだけ損をしています。
だから当社では、追加するときに「いつ見直すか」まで決めるようにしました。足場は、作るときから外す日を意識する必要があります。
4. Anthropic公式Cookbookが示す7ステップ
ここまでは考え方の話です。では、どこから手を入れればいいのでしょうか。
Anthropicが公開している技術資料「Cost Optimization on the Claude API」に、同社のApplied AIチームが顧客に対して回している確認手順が載っています。以下は2026年8月19日に版を固定して確認した内容です（リンクは末尾の出典に記載）。
この7項目のうち、1番目は事前準備です。評価セットの作成とベースラインの測定にあたります。実際に手を入れる対象は、残る6つ。
- 最適化を始める前に（事前準備）：まず高性能なモデルで動かし、評価セット（eval）を作り、ベースラインを測る
- プロンプトキャッシュ：同じ前置きを毎回課金し直すのをやめる
- 入力トークンの管理：必要な情報だけを渡し、残りは取りに行かせる
- エージェントループの効率化：中間成果物が毎ターン積み上がるのを止める
- 出力トークンの管理：出力の形を先に指定する。生成量そのものを絞る手段（
max_tokens、停止文字列、effort）も含む - Batch API：急がない処理を非同期に回す
- モデル選択とeffort：品質基準を満たす最も安い組み合わせを探す
同資料が一本道の手順として示しているのは、両端の2つです。「評価を先に作る」と「モデルとeffortは最後に触る」。中間の順序はワークロード次第だと同資料自身が繰り返しています。
注目すべきは、モデルを下げるのが最後に置かれている点です。同資料はその理由をこう説明しています。モデル選択は一番簡単に引けるレバーだが、製品の知能の上限を直接下げてしまう。だから、それ以外で回収できるところを先に回収する、と。
ここから数値の話が続きます。Claude Codeだけを使っている方は、個々の設定を覚えるより「順序がある」という点だけ持ち帰ってください。
同資料と公式ドキュメントで確認できた数値を挙げます。
- キャッシュへの書き込みは、5分保持で通常の入力単価の1.25倍、1時間保持で2倍。読み出しは0.1倍（公式ドキュメントに "1-hour TTL at 2x the base input token price" と記載あり）
- キャッシュが効かなくなる代表的な原因は3つ。前置きの中に日時やリクエストIDなど毎回変わるものを入れる／会話の途中でモデルを切り替える／毎ターン履歴を圧縮する
- 画像は情報量ではなく面積でトークン化される。1280×720に縮小しておけば1枚あたり約1,200トークンに収まる（この解像度での概算であり、これ以下なら一律という上限値ではない）
- Batch APIは全トークンが50%引き。多くは24時間内に完了するが、同資料は24時間を「期限であって応答保証ではない」と位置づけている
そして最終結果として、未最適化のOpus高effort構成に対し、Sonnet中effort＋明示的なキャッシュ区切りの構成で約13分の1まで下がった、と同資料は報告しています。
この数字を持ち帰る前に、出自を3つ押さえてください。
1つ目。これは架空の業務での実演です。 同資料が使っているのは Acme Insurance という架空の保険会社と、その合成データによる保険金請求の判定業務です。位置づけは資料内で組み立てた実演用の題材であり、公式の性能比較や顧客案件の実績とは別のものとして扱ってください。
2つ目。評価件数が10件です。 しかも未最適化のベースラインは10件1試行の結果です。同資料自身が、本番の判断をするなら評価ケースを50件程度・設定ごとに5回以上は回すよう勧めています。モデルの出力は非決定的なので、同じ設定でも実行ごとに結果が変わるという注記も付いています。
3つ目。対象はClaude API（プログラムから直接呼ぶ場合）です。 同資料は末尾の「Non-API surfaces」で、Agent SDKやClaude Code、Managed Agentsといった抽象化レイヤーを対象外としています。ただし同資料は同時に、これらがAPIをラップしてレバーの一部を代わりに扱っているとも書いています。効果がないという意味ではなく、Claude Codeの月額プランにそのまま当てはめられないという意味です。使っている表層ごとに、どのレバーが使えて課金がどうなるかは別に確認してください。
つまり、この13分の1は特定の条件下での実演値です。自分の環境で同じ削減率が出ると読むのは行き過ぎで、持ち帰る価値があるのは並び順のほうにあります。
5. 採用されなかったレバーの記録
私がこの資料で最も価値があると感じたのは、試したが採用しなかったレバーが、理由つきで記録されている点です。
同資料が試して、この用途では採用しなかったものを挙げます。
- 参照文書をツールの裏に隠す：コストは下がったが、精度を落とした。ツール経由にすると、AIは自分が取りに行こうと思ったところしか読まないため、判断が微妙なケースで部分的な読み取りから結論を出してしまう
- ツール検索で読み込みを遅延させる：ツールの定義が数万トークン規模にならないと元が取れない。この事例では数百トークンしかなく、検索する手順そのものが純粋な追加コストになった
- コード実行環境に計算を任せる：任せる計算処理が存在しなかったので、リクエストが重くなるだけだった
- 文脈の自動削除と自動圧縮：6ターン程度のやり取りでは発動の閾値に届かず、何も起きなかった
- サブエージェントへの分解：同資料は「試した中で最も安かった」と書いている。ただしマニュアルをルール一覧に圧縮した結果、例外条項が抜け落ちて1件を誤判定した
1つ目は、前章のステップ3（必要な情報だけを渡し、残りは取りに行かせる）と矛盾して見えます。同じ資料が勧めている手法を、同じ資料が捨てている形です。
これは条件の話です。同資料は分かれ目をこう書いています。大半の呼び出しでその文書を参照するなら、キャッシュに載せて前置きに置いたままのほうが安い。文書が大きく、かつ参照される頻度が低いときに、取得方式が勝つ。 この事例では判定のたびにマニュアルを引くので、隠すと不利になりました。
最後の項目についても、原因の切り分けが必要です。誤判定を招いたのは分解そのものではなく、マニュアルをルール一覧に圧縮して例外条項を落とした点です。分解が危険という話ではなく、圧縮するときに何が落ちるかを見ていなかった、という話になります。
そのうえで同資料は、この結果をこう位置づけています。同資料が設定した品質基準では、「安くて少し間違っている」構成は最適化とみなさない（拙訳。原文は "Cheap and slightly wrong is still not an optimization at our bar"）。ここでの基準は資料の側が設定したものなので、各社は自分の基準を自分で決める必要があります。裏を返せば、基準を先に決めていなければ、この判断そのものが下せません。
どのレバーでコストが下がるかは、その仕事のトークンがどこで消えているかによって決まります。 汎用の手順を上から順に当てていく作業とは、性質が違う。
なお、この資料が扱う範囲はAPIのコスト最適化にとどまります。「CLAUDE.mdのどの行を消していいか」の判定基準までは、ここに書かれていません。この記事で借りているのは、レバーの並び順と、「有効だと思った手が実際には空振りすることがあるので測ってから決める」という姿勢のほうです。
6. 外す前に測る
では、実際に人の確認を外すときはどうするか。
AI運用で私が危ないと思う言葉があります。
「最近ほとんど外さないので、もう任せても大丈夫そうです」
感覚としてはわかります。私もそう思う瞬間があります。とはいえ、そのまま人の確認を外すと、何か起きたときに説明できません。
- いつから大丈夫になったのか
- どの種類なら大丈夫なのか
- 何件確認した結果なのか
- どの程度の誤りまで許容するのか
- どうなったら人の確認に戻すのか
何も決まっていない状態だからです。
自律化に必要なのは観測です。AIを優秀だと信じる必要はなく、失敗したときに気づける状態を作れていればいい。
ここで、多くの現場がつまずく落とし穴を先に書きます。「AIと人の判断がどれだけ一致したか」だけを見るのは危険です。
理由は単純です。対象の99%が「異常なし」で片付く業務なら、AIが何も考えず「異常なし」と答え続けるだけで一致率は99%になります。この99%は、AIが仕事をできる証拠になりません。人の判断を正解と決めてよい根拠も、実はありません。人同士でも判断は割れます。
だから、次のように測ります。
- 並走させる：AIの判定と人の判定を、同じ対象に対して同時に動かす。互いの結果を見えないようにする
- 正解を決める：一致・不一致だけを数えず、判断が割れた案件を第三者が裁いて正解ラベルを付ける
- 重大な種類を分けて数える：全体の正解率ではなく、見逃すと痛い種類ごとに「取りこぼし率」を出す。件数が少ない種類は、必要な数がたまるまで待つ
- 基準を先に決める：どの水準を超えたら外すかを、測り始める前に決める。誤りの重さが違うなら、種類ごとに違う水準にする
- 基準を超えた種類だけ外す：全部いっぺんに外さない
- 外した後も抜き取りで二重判定を続ける：全件確認をやめても、一定割合は人が見る。外した後の異常に気づく経路は、ここに残す
- 戻す条件と再測定の引き金を決める：モデル、プロンプト、ツール、データのいずれかが変わったら測り直す。版を記録しておく
6番目を飛ばすと、外した後にAIの誤判定を誰も見つけられなくなります。人の確認を完全に止めた時点で、観測手段も一緒に捨てているからです。エラー件数を戻す条件にしても、そのエラー自体が検出されません。
外す作業は実験です。
なお、必要な一致水準や取りこぼし率は、業務が持つリスクによって変わります。誤りが金額や信用に直結する業務なら厳しく取るべきで、社内の下書き生成なら緩くても構いません。他社の数字をそのまま持ってくるものではないと考えています。
7. 外してはいけないもの
ここまで外す話を書いてきましたが、全部外すのは危険です。
自律化が進むほど、むしろ残さなければならない土台があります。それが観測できる装置です。
当社の例を挙げます。当社では日本語の文章品質について、最初はCLAUDE.mdに注意書きを増やす形で対応していました。「この言い回しは使わない」という指示を足していく方法です。
これは効きませんでした。会話が長くなると指示が薄まり、モデルが変わると癖の出方も変わるため、同じ表現が再発したのです。
そこで方針を変えました。注意書きに頼るのをやめ、ファイルに書き込んだ直後に検査が走る仕組み（Claude CodeのHooks）に置き換えています。
ここは正確に書いておきます。書き込み後に発火する検査は、すでに書かれた内容を巻き戻せません。検査結果はAIに差し戻され、書き直すかどうかは次の動作に委ねられる。当社ではこれを「機械が直す」ではなく「一定の水準を満たさないとセッションを完了できない」という形の強制にしています。検査そのものと、検査結果を守らせる仕組みは別に用意する必要があります。
それでもこれは「足場を骨格に格上げした」例です。人が毎回見る前提の足場から、機械が毎回見る形へ移しました。人の手数は減りましたが、観測する装置は消していません。
もう1つ、当社が実際に失敗した例です。従量課金の外部サービスを使う自動処理で、後段の失敗が前段の課金を何度も呼び直す構造になっていたことがありました。想定外の請求が出て初めて気づきました。
ここから作ったルールが、いまも骨格として残っています。
- 課金を伴う処理の結果は保存し、やり直すときは再利用する
- 再試行の回数に上限を置く。枠切れ、上限超過、認証エラーは再試行しない（再課金と通知の連打になるだけ）
- 一定回数失敗したら対象を隔離して処理を止め、Slackに通知する
- 自動チャージは原則オフにする。使う場合は月間上限の設定を必須にする
「静かに毎日失敗し続ける」のが最悪のパターンです。この4つは、モデルが賢くなっても外す理由がありません。
とはいえ、この4つでも防げない穴が残っています。外部への課金処理が成功した直後に通信が切れた場合、こちら側には結果が残らないのに相手側では課金が済んでいます。この状態で再試行すれば二重課金です。ここを閉じるには、相手のサービスが提供する冪等キー（同じ処理を二度実行させないための識別子）を使うか、実行前に「これから叩く」という記録を残して照会できるようにする必要があります。当社もここは途上です。
保存した結果を再利用するときにも注意が必要です。何をキーにして保存したかを詰めておかないと、別の顧客の結果や、古い価格・古い権限の判定を返してしまいます。
人の手数は減らします。ただし、観測する装置までは消しません。これが足場と骨格を分けている理由です。
8. 今日やる3つの質問
複雑な棚卸し表は要りません。手元のCLAUDE.mdか、チェック手順書を1つ開いてください。
そして1行だけ選び、次の3つを書き込みます。
質問1：この行は、AIの何ができない前提で書いたのか
答えられない項目は、まず疑ってください。存在理由を誰も説明できない状態です。
質問2：いまのモデル、いまのツール、いまのデータで、もう一度試してどうなるか
「前に失敗した」という記憶で決めないでください。実際に試します。3点を今のものに揃えてテストするのが要点です。
ただし1回試して通っただけで結論を出さないこと。前章で書いたとおり、たまにしか起きない失敗や、めずらしい種類の案件は数回の試行では姿を見せません。1行の棚卸しの入口としては十分ですが、確認工程そのものを外す判断には、前章の測り方が必要になります。
質問3：これを外して間違いが起きたとき、検知できるか。影響を隔離できるか。元に戻せるか
3つそろわないものは、すぐには外しません。先に、欠けている条件を満たす仕組みを作ります。
いきなり全部やる必要はありません。1行から始めれば十分です。
なお、この記事で扱った「足す側」の設計は、claudecode道場のChapter 5「CLAUDE.mdで自分専用AIにする」で手を動かしながら学べます。
9. まとめ
- AIハーネスとは、AIモデルの外側に置く道具立て（情報、ルール、ツール、手順、検査、通知、記録）のこと
- ハーネスには「足場」（AIの弱さを補う一時的な道具）と「骨格」（自律化するほど重要になる土台）が混ざっている
- 見分ける条件は3つ。検知できるか、影響を隔離できるか、元に戻せるか。検知だけでは足りない
- 構造的に「足す力」が強く働く。外す力のほうは、期限や定期レビューとして仕組みにしないと働かない
- Anthropic公式Cookbookの7ステップは、1番目が事前準備（evalとベースライン）で、残る6つがレバー。一本道として示されているのは「評価を先に作る」と「モデルとeffortは最後」の両端だけ
- 公開されている約13分の1という削減率は、架空の業務・合成データ・10件の評価による実演の結果。再現を約束する数字ではない
- どのレバーでコストが下がるかは仕事の形で決まる。採用しなかった記録のほうが実務では役に立つ
- 人の確認を外すなら、一致率だけを見ない。正解ラベルを付け、重大な種類ごとに取りこぼしを数え、外した後も抜き取りで二重判定を続ける
「AIを速く動かす」ことに慣れてきたら、次に価値が出るのは「何を残し、何を捨てるかを決める」ことだと私は考えています。
10. 出典と関連リンク
引用した一次情報（2026年8月19日に内容を確認）
- Anthropic Cookbook「Cost Optimization on the Claude API」（版を fa3aa15 に固定したリンク。
mainの内容は更新されるため、記事執筆時点の記述はこちらから確認できます）: https://github.com/anthropics/claude-cookbooks/blob/fa3aa15e7c62dca23021ba457f4f2a6b049114c1/cost_optimization/cost_optimization.ipynb - Anthropic 公式ドキュメント「Prompt caching」: https://platform.claude.com/docs/en/build-with-claude/prompt-caching
- Anthropic 公式ドキュメント「Manage Claude's memory」（CLAUDE.md）: https://docs.anthropic.com/ja/docs/claude-code/memory
- Anthropic 公式ドキュメント「Hooks guide」: https://code.claude.com/docs/en/hooks-guide
着想元
「足場」と「骨格」でハーネスを分ける整理は、実務者の公開記事から着想を得ています（だん｜AI×クラウドエンジニア「【図解あり】副業に今すぐ使える『ハーネス設計』完全解説」2026年8月16日公開、2026年8月19日閲覧）: https://x.com/dan_pro_man/status/2088875939103146216
同記事は個人の運用事例に基づくもので、記載されている一致率などの水準は同氏のケースにおける値です。本記事の第2章で条件を3つに増やした部分と、第6章の測り方は、当社が独自に整理したものです。着想元の記事にはこの整理は含まれていません。
当社の関連記事
