AIに任せる境界の引き方——「頼んだことだけやる」を徹底する

🎯AIは「収束しがちなパターン」を持つ

コーディングAIには、指示に対して「よかれと思って」振る舞いを足していく傾向があります。頼んだ関数に加えて、想定していない入力への防御コードを積む。1つのバグ修正のはずが、周辺のリファクタまで巻き込む。こうした放っておくと必ず同じ方向に流れる癖を、私たちは社内で「収束しがちなパターン」と呼んで、禁止則として言語化しました。

背景には、自然文の指示だけでは規約が守られにくいという現場感があります。この「確率的な判断は当てにせず、守らせたい約束は仕組み側に置く」という発想は、Martin Fowler のHarness engineeringの整理とも重なります。だから私たちは「気をつけてね」ではなく、ルールとして明文化して毎回参照させる形にしました。

🚫禁止則1: 要求外の機能追加をしない

1つ目のルールは、頼まれたことだけやるです。要求外の機能追加と、過剰なエラーハンドリングを明示的に禁じています。「あったら便利そう」は、頼まれていなければ足さない。これを運用ドキュメントの先頭に近い場所へ置き、作業前に必ず読ませています。

なぜここまで徹底するかというと、一人会社では書かれたコードの一行ずつが将来の自分の保守対象だからです。気を利かせた分岐が増えるほど、後から読むときの負荷が上がり、テストすべき経路も増えます。スコープを絞って任せるほうが、結局は速く、壊れにくいという実感があります。

🧩禁止則2: サブエージェントを過剰に起動しない

2つ目は、調査を分担する子エージェントを安易に増やさないことです。AIは「念のため専門の探索役を立てよう」と判断しがちですが、一回のファイル読み込みや一、二回の検索で済むことに別エージェントを起動するのは、そのまま応答時間と費用の無駄になります。

私たちのルールはシンプルで、「自分でできるか？」を先に問うというものです。できるなら直接やる。本当に独立した複数の探索軸があり、まとまった調査が必要なときだけ委譲する。一人会社ではコストの一円が自分の財布から出ていくので、この「まず自分で」の順序を明文化しておくと、AIの過剰な段取りを抑えられます。

🗺️境界は「気持ち」でなく「基準」で引く

任せる範囲を決めるとき、「なんとなく重要そう」という感覚で線を引くと、判断がぶれて毎回考え直すことになります。私たちは、外に公開するもの・お金や契約が絡むもの・元に戻せないものは人間が最終承認し、内部で完結して後から戻せることはAIに自走させる、という可逆性と外部到達で判定する基準を持っています。

面白いのは、境界をはっきり文章にするほど、逆にAIへ任せられる範囲が広がることです。「ここから先は人間」という線が明確なら、その手前は安心して手を離せます。曖昧なまま全部を心配するより、明文化された基準があるほうが自走の幅は大きくなります。

📌スコープは「渡す前」に決めておく

最後に実務のコツを一つ。境界は作業が終わってから注意するより、依頼する時点でスコープを言い切っておくほうが効きます。「この関数だけ直す」「新しい依存は足さない」「テストは既存の書式に合わせる」——渡すときに範囲を明示すると、余計な追加そのものが生まれにくくなります。

私たちはこうした頻出のズレを、その都度「よくあるミス」として一行のルールに落とし、次からは作業前に参照する運用にしています。個別に叱るのではなく、再発しないように仕組みへ変換する——これが一人会社でAIを暴走させないための地道な背骨です。

🧭まとめ: 「頼んだことだけやる」を仕組みにする

AIに任せる境界は、才能や気合いではなく設計の問題です。要求外の機能追加をしない、過剰なエラー処理をしない、子エージェントを安易に増やさない——この「頼んだことだけやる」をルールとして明文化し、作業前に毎回参照させる。そして任せる範囲は可逆性で線を引く。これだけで、AIの善意による暴走はかなり抑えられます。

まずは、直近で「頼んでいないのにやられて困ったこと」を一つ、一行のルールにしてみてください。境界を言葉にした分だけ、安心して手を離せる範囲が広がります。

この「頼んだことだけやる」を含む委譲のルール群は、AI COO の運営構造として ai-coo-starter（OSS）に雛形化してあります。境界の言語化を一から書き起こさずに始められます。