何を任せ、何を自分で決めるか

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

読み返してみると、判断の場面で同じ基準が何度も出ていました。第3回の承認、第5回のサンドボックス、第7回のコミットの粒度、第11回の MCP の権限、第15回のデプロイの戻し方。全部、同じ質問に帰着していました。

繰り返し出てきたのは、戻せるかどうか

戻せる操作は任せてよく、戻せない操作は人が決める。

この1行が、この講座の実質的な結論です。技術の話に見えて、実際には範囲の決め方の話をずっとしていました。

ファイルの書き換えは戻せます。Git があるからです。だから作業フォルダへの書き込みは既定で許されています。コミットも戻せます。打ち消すコミットを積めばよい。デプロイも戻せます。過去の配信へ切り替えられるからです。

戻せないのは、外部への送信、本番のデータの書き換え、公開、削除。これらの前には、必ず人が1人立ちます。

仕組みを作るというのは、この線をその場の判断ではなく設定として引くことです。疲れている日でも同じ線が引かれているようにする。第5回で「人の注意力だけが最後の防波堤になる状態は、長続きしません」と書いたのは、この意味でした。

任せられる作業の条件

もう1つ、別の角度からの基準があります。

正しさの判定基準が先に決まっている作業は、任せられます。

テストが通ること。型が合うこと。既存の書き方に揃っていること。リンク先が実在すること。どれも、正しいかどうかを機械が言えます。基準が決まっているので、出てきたものを評価できます。

基準が決まっていない作業は、任せても評価できません。「この機能は作るべきか」「この画面は分かりやすいか」「この変更は誰の役に立つか」。答えが1つに決まらないので、返ってきたものが良いかどうかを判定する手段がありません。

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

2つの基準は独立しています。戻せるが基準が決まっていない作業もありますし、基準は決まっているが戻せない作業もあります。任せられるのは、両方を満たすところだけです。

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

この講座で作った仕組みは、全部が「基準を先に決めて書き出す」作業でした。

AGENTS.md は、守るべきことを書き出したものです。スキルは、手順を書き出したものです。自動検査は、合格の条件を書き出したものです。プルリクエストは、判断する場所を書き出したものです。

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

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

速くなったかどうかは、言いにくい

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

観察できたのは、別のことです。判断が必要な場面の数と位置が変わりました。

以前は、書きながら判断していました。書く手と決める頭が同じ人の中にあったので、区別がありません。いまは、依頼を出すときに決め、返ってきたものを見るときに決めます。判断は減らず、まとまって前後に移動しました。

そして、判断の質は前より要求されるようになりました。書きながら決めていたころは、決めそこねた部分が書いている途中で気づけました。いまは、決めそこねたまま依頼を出すと、決めそこねたまま完成したものが返ってきます。

第6回で「完了の条件が書かれていないと、終わりを判定するのが人の目だけになる」と書きました。書かないことの代償が、以前より早く、まとまった形で返ってくるようになったということです。

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

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

検査を増やすほど、通ったものを信用するようになります。第14回で「レビューを通ったことを合格と呼ばない」と書きましたが、実際には、3つの目を通ったものを人が同じ密度で読み直すことは減ります。

これは仕組みの失敗ではありません。仕組みの目的そのものです。読む量を減らすために作ったのだから、読む量は減ります。

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

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

最後に残る仕事

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

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

誰のために作るかを決めること。第8回で「なぜ変えたかは差分からは絶対に読み取れない」と書きましたが、読み取れないものは生成もされません。

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

この講座で作ったもの

17回を振り返ると、作ったのは道具の使い方ではなく、順番でした。

手元で動かし、規約を置き、Git で管理し、GitHub で確認し、検査を通し、公開する。途中に止まる場所を3つ置きました。差分を読むところ、プルリクエスト、本番へ出す判断。

止まる場所を置くのは、速くするためではありません。速くなった部分と、速くならない部分の差を吸収するためです。コードが出てくる速さは変わりましたが、人が読んで納得する速さは変わっていません。

ここから先

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

BenriWorks では、この形で作ったものを実際に公開しています。同じ仕様書を2つのエージェントに渡して比べた記録は「2つのエージェントに、同じ仕様書を渡してみた」に、Android アプリを実際の車内で動かすまでの記録は「Codex の導入から、Android 測定アプリが実乗車で動くまで」にあります。どちらも、この講座で書いた順番の実物です。

うまくいかなかった部分も書いてあります。そちらのほうが、たぶん役に立ちます。

参照した情報

• 本文中の各回への言及は、この講座の第1回から第16回の内容
• 挙げた事例は BenriWorks の各リポジトリで2026年に実際に行った作業