お願いと強制と審査を、どの層に置くか決める

15回かけて、道具と仕組みを並べてきました。最終回は、それを使って何をするかの話です。

読み返してみると、この道具の設計には一貫した区別がありました。お願いするものと、強制するものが、はっきり分けてあります。

お願いの層と、強制の層

第9回で、公式ドキュメントの一文を引きました。CLAUDE.md と自動メモリはどちらも文脈であって、強制される設定ではない、というものです。

これは制限の告白ではなく、設計の宣言です。同じページに続きがあります。Claude が何を決めようと動作を止めたいなら、フックを使ってください、と。

つまり、置き場所が2層に分かれています。

お願いの層には、CLAUDE.md、スキルの説明文、依頼文が入ります。たいてい効きますが、保証はありません。効きやすくする書き方（具体的に、短く、矛盾なく）はありますが、確率の話にとどまります。

強制の層には、許可の規則、フック、サンドボックスが入ります。Claude の判断とは関係なく効きます。deny 規則は bypassPermissions でも効きますし、フックはシェルのコマンドとして必ず実行されます。

書ける内容も変わります。お願いの層には、文章で表せるものなら何でも書けます。強制の層に書けるのは、機械が判定できる条件だけです。

確実さと表現力が交換関係にあります。 だから両方要ります。

間に入った審査の層

この講座で扱った Claude Code には、もう1つの層があります。第5回の auto モードです。

分類器は、人の代わりに操作を審査します。お願いの層のように確率的ではなく、強制の層のように条件が固定でもありません。判断を、別のモデルに委譲するという第3の形です。

この層があることで、選べる範囲が変わります。以前なら「全部自分で見る」か「全部やめる」の二択だったところに、「別の目に見てもらう」が入りました。

第14回で長い作業をクラウドへ出す話をしましたが、あれが成立しているのも、この層があるからです。人が見ていない時間に何かが起きても、審査は動いています。

分類器が読まないものは、誰も審査していない

ただ、この層には空白があります。

第5回で引いたとおり、分類器はツールの実行結果を読みません。ファイルやウェブページの中にある敵対的な内容が分類器を直接操作できないようにするための設計で、これは正しい判断です。

同時に、こうも言えます。返ってきた内容そのものを審査している層は、どこにもありません。

Claude 本体は読みます。読んで作業の材料にします。第11回で MCP の注意点として書いたのはこのことでした。疑わしい内容に印を付ける仕組みは別にありますが、それは「審査」というより「注意喚起」に近いものです。

いまのところ、ここを埋める手段は権限を絞ることだけです。読み取りだけにする、触られたくないファイルを deny で塞ぐ、戻せない操作を人の判断に残す。層を増やしても、範囲を狭める作業はなくなりません。

任せられる作業の2つの条件

角度を変えます。どの作業を任せられるかという問いです。

条件は2つあります。

正しさの判定基準が先に決まっていること。 テストが通ること、型が合うこと、既存の書き方に揃っていること。基準が決まっているので、出てきたものを評価できます。決まっていなければ、返ってきたものが良いかどうかを判定する手段がありません。

失敗しても戻せること。 第8回で見たとおり、戻せる範囲は仕組みによって違いました。チェックポイントはシェルのコマンドが変えたファイルを戻しませんし、サブエージェントの編集も戻しません。「戻せる」と思っている範囲が、実際の範囲と一致しているかを確かめてください。

境目は作業の難しさではありません。難しくても基準が決まっていれば任せられますし、簡単でも基準が決まっていなければ任せられません。

基準を決める仕事は、なくならない

この講座で置いてきたものは、どれも「基準を先に決めて書き出す」作業でした。

CLAUDE.md は守るべきことを書き出したもの。スキルは手順を書き出したもの。許可の規則は境界を書き出したもの。フックは必ず起きることを書き出したもの。

書き出す側は任せられません。何を守るべきかを決められるのは、そのコードで何を実現したいかを知っている人だけです。

つまり、任せられる範囲を広げる作業は、人にしかできないという形になっています。ここが、この講座の中心にあった構造です。

速くなったのは出力で、読む速さではない

正直に書きます。BenriWorks で計測しているわけではないので、開発全体が速くなったかどうかは分かりません。

はっきりしているのは、出てくる量と、読む速さの差が開いたことです。

第12回でサブエージェントを扱ったとき、並べても読む側は1人だと書きました。第14回でセッションを並べる話をしたときも、結論は同じでした。第6回でファストモードを紹介したときも、待っていない作業では意味がないと書きました。

3回とも同じことを言っています。この道具が速くしたのは出力のほうで、判断のほうではありません。

だからこの講座は、止まる場所を減らす方向には進みませんでした。差分の読み方（第4回）、モードの選び方（第5回）、計画の読み方（第7回）、巻き戻し（第8回）。どれも、速くするための仕掛けではなく、速くなった部分と速くならない部分の差を吸収するための仕掛けです。

仕組みを増やすと、新しい問題が生まれる

ここまで作ってきたものに、副作用があります。

審査の層を厚くするほど、通ったものを信用するようになります。これは仕組みの失敗ではなく、仕組みの目的そのものです。見る量を減らすために作ったのだから、見る量は減ります。

問題は、減らした判断が本当に不要だったかを確かめる方法がないことです。分類器が見ていない種類の問題は、分類器を増やしても見つかりません。そして、層が増えるほど「通ったから大丈夫だろう」という気持ちは強くなります。

いまのところ、BenriWorks でこれに対して打てている手はありません。事故が起きたら規則かフックを1つ足す、という後追いの形で運用しています。足りているとは思っていません。この講座を書き終えた時点でも、ここは開いたままです。

最後に残る仕事

道具が引き受けてくれない仕事を、3つ挙げます。

何を作るかを決めること。基準を決める仕事そのものです。

誰のために作るかを決めること。差分から読み取れないものは、生成もされません。

そして、やめる判断。作ったものを畳む、機能を削る、続けてきた運用を止める。どれも戻せない操作で、しかも基準が決まっていません。2つの条件のどちらからも外れているので、構造上、人が決めるしかありません。

ここから先

公式ドキュメントは、困っている項目から読んでください。この講座は入口を作るためのもので、仕様の全部は扱っていません。更新も速いので、細かい設定の話は公式の記述が常に正です。

道具を比べたいなら、Codex 集中講座が全17回で同じ範囲を扱っています。Git と GitHub と Vercel の回は、この講座から意図的に外した部分です。

同じ仕様書を2つのエージェントに渡して比べた記録は「2つのエージェントに、同じ仕様書を渡してみた」にあります。うまくいかなかった部分も書いてあります。そちらのほうが、たぶん役に立ちます。

参照した情報

• 本文中の各回への言及は、この講座の第1回から第15回の内容
• 引用した公式の記述は Anthropic「How Claude remembers your project」「Choose a permission mode」（code.claude.com/docs、2026年9月時点）