相手のAIにプロンプトを打っているだけだった

自分が相手に渡した指示文の、いちばん最後にこう書いてあった。

「下の枠内をそのままClaudeに貼ればOKです」

親切のつもりだった。読むもの、決まっていること、注意点、完了の条件。全部書いてある。相手は貼るだけで動く。実際、速かった。

5か月後、相手が1on1でこう言った。「出してもらったものを作るだけになっていた」。そのとき初めて、自分がやっていたことに名前がついた。相手に頼んでいるつもりで、相手のAIにプロンプトを打っているのと変わらなかった。

これは、そこから1週間で責務の型を引き直した記録である。まだ検証中で、うまくいったとは書けない。同じ壁に当たる人は多いはずなので、途中の状態で残しておく。

丁寧な指示書は、着手許可証になっていた

いま、AIを使って4つのプロダクトを複数人で開発している。経営ダッシュボード、補助金の検索システム、LINEの経営支援ツール、求人サイト。要件をいちばん把握しているのは自分で、開発も分かる。だから設計図もロードマップも手順も、AIで全部書いて渡していた。相手はCodexやClaude Codeで実装する。

渡していたのは、たとえばこういう指示文だった。

タスク: 検索結果ページを実装する

まず読む — docs/requirements.md の §1 と §5、open-questions の #32

決まっていること — URL は /search/?{query} の動的ページ・noindex。フリーワードは引き継がない

実装の注意 — URL の組み立ては lib/routes.ts に集約する。まずダミーデータで動く状態にする

完了の条件 — typecheck / lint / test / build が通る。docs を同じ PR で更新する

どれも丁寧だと思っていた。相手のオンボーディングコストは最小で、品質のばらつきも出ない。実際、短期の速度は出た。ある案件は4週間で100本以上のPRがマージされた。

ただ、相手から見るとこれは設計図ではなく、着手許可証だった。次の指示書が出るまで、相手は動けない。

起きたことを、事実だけ並べる

• 相手のPRを、自分が6日間レビューできなかった。相手はその間、次に何をすればいいか分からなかった
• 別の案件で、相手のコミットが約3週間止まった。理由は「次の指示書が出ていなかったから」
• レビューで直す点を見つけると、自分で直してマージしていた。速いから。相手には「直された事実」だけが残り、「なぜ」は残らなかった
• 相手のテストがCIで走っていなかった。CIの設定は自分の担当で、相手は触れなかった。相手は「相談したい」とPRに書いていたが、自分が返さなかった

どれも、相手の力の問題ではなかった。全部、自分のところで止まっていた。

癖ではなく、構造だった

自分の癖だと思っていた。任せることにビビっている、という自覚もあった。人にこの話をしたとき、自分の口からこう出た。「道筋まで引くと、その責務は自分にある。相手が責任を持つ部分がどこにもなくなる」。返ってきたのは「任せる勇気」という言葉だった。

それで、4つのリポジトリのルール・CI・PRテンプレート・指示書を全部読み直した。分かったのは、癖ではなく構造だったということだ。4つすべてで、協業の型が「自分が設計・道筋・完了条件まで書き、相手がAIに流し、自分が検収して巻き取る」前提で書かれていた。コードオーナーもレビュアーの自動アサインも自分。「コミット・push・PR・マージ・公開は司令塔だけが行う」。司令塔は自分。責任者への集中は、設計意図として明文化されていた。ハーネスは「AIが壊さない・迷わない」ためには良くできていた。同時に、「相手の思考が入らない」設計でもあった。

もう一つ分かった。案件ごとに、開始時に握った責務が違っていた。相手が主開発で自分は助言役の案件もあれば、自分が最終責任を持つ案件もある。責務が違うのに、ハーネスは一律に「自分が道筋を引く」型だった。握った責務と、運用していた型がずれていた。 相手が主開発のはずの2案件で、自分が定義表もDoDもレビューも握っていた。ずれの正体はこれだった。

合否と持ち主。2つの問いで型が決まる

「設計」「監修」「主開発」という役割の言葉で分けたのが、境界を曖昧にした原因だった。そこで、プロジェクト開始時に握る問いを2つに絞った。

• 問1 合否: 先方に出す前の「これで出せる」を誰が決めるか
• 問2 持ち主: 設計と実装を誰が手を動かして決めるか

伴走型は、自分は合否も持ち主も持たない。役割は「壊れない条件」の番人と、120点を議論する相手役。受け入れ型は、自分が受け入れ基準を握り、設計と実装は相手に委ねる。受託型は自分が作って相手が検収する納品仕事、自前型は自分が作って自分が決める。

4案件を当てはめると、2案件は伴走型で握ったのに、受け入れ型で運用していた。もう1案件は受け入れ型で型は合っていたが、指示文が設計に踏み込んでいた。

型が決まれば、渡すものが決まる。受け入れ型なら渡すのは受け入れ基準だけで、設計・タスク分解・検証手順は持ち主が書く。伴走型なら渡すのは「壊れない条件」だけだ。型を決めずに指示文を書くと、どの型でも設計まで渡してしまう。

ここで一つ、自分にとって大きかった定義変更がある。「受け入れ基準を作る＝設計では？」と思っていた。そうではなかった。受け入れ基準は、画面・URL・テスト・CIの結果を見れば判定できるものに限る。コードの配置・手順・順番に触れた瞬間、それは設計＝持ち主のものになる。 最終責任は「自分で設計すること」ではなく「受け入れ基準を握ること」で持てる。設計を渡しても、責任は持てる。

型を決める証拠は、契約書と体制表にある。検収前の最終確認を誰の名前で行うか、相手が自分抜きで先方に納品できるか。それで決まる。

指示書をやめて、線だけ引く

指示書で相手を縛るのをやめ、ハーネスの役割を「線を引くこと」に移した。

1. 憲法。変えてはいけないことだけをリポジトリの先頭に置く。「原文にない情報は補完しない」「数字はLLMに作らせない」。先方に約束した言葉（「自動連携は範囲外」）もここに置く。相手が設計を持つとき、これだけは守ってほしい線がここに集まる。

2. 持ち主表。領域ごとに、持ち主・持ち主が決めてよいこと・相手に聞くことを表にする。指示書が着手許可証になっていた状態を解く。

3. 依頼はbriefの5項目だけ。

# brief: <topic>
## ゴール（先方の言葉で）
## 責任範囲（持ち主／自分が持つこと）
## 制約（憲法＋先方への約束）
## 期限
## 先方に見せる日

「まず読む」「実装の注意」「完了の条件」は書かない。設計・タスク分解・DoD・検証手順は持ち主が書き、PRに「採用しなかった案と理由」を残す。

4. レビューを2種に分ける。境界レビューは、憲法違反・約束違反・境界越えだけを見る。非同期で、直さず返す。120点レビューは、動くものを2人で触って「先方が感動するには何が足りないか」を議論する。同期で、AI製なので辛口でよい。品質ゲートはあったが、価値ゲートがなかった。

あとは3つ。マージは持ち主が自分のタイミングでやる。自分が持ち主の領域を直したら「巻き取り: 理由」を1行残す。強制はgit本体とCIだけに寄せる。AI専用の仕掛けは、相手の環境では効かない。

型を変えた翌日に見えたこと

型を決めた翌日、レビュー待ちだったPRを境界レビューの型で見直した。

ダッシュボードの相手は、1on1で目線を合わせた翌日から、指示書なしで広告データ連携を5本のPR・約1万行で作りきっていた。プレビューURLも付いていた。自分がbriefを書く前に、相手はもう動いていた。相談の場を作れていなかっただけで、作りきる力は最初からあった。別の案件の相手も、待たせていたPRの中で自分で設計判断を記録し、実測してから実装していた。設計の余白は、こちらが思うよりずっと前から使われていた。

一方で、境界レビューには本当に「境界」の論点が出た。作られた仕組みは継続稼働するもので、納品後に誰が運用するかが決まっていなかった。主指標の定義が、画面と定例の決定で割れていた。相手の落ち度ではなく、憲法と約束を自分が渡していなかった結果だ。境界レビューは、そのために要る。

まだ分からないこと

• briefの粒度が粗すぎて相手が止まる可能性。「起きた事象とセットでないルールは足さない」と決めているので、起きてから直す
• 巻き取りの記録が実際に減るか。減らないなら、記録ではなく設定と権限の側に欠けがある
• 経緯の転記を自分が持つ限り、自分がボトルネックの一部として残る

おわりに

相手に「自分がハーネスを付けたので、外す責任は自分にある。勝手に外れるものではない」と言った。外す作業は、新しい設計図を書くことではなく、相手に委ねる決断のほうだった。この記事も、設計図ではなく決断の記録として残しておく。

責務の型は2つの問いで決まる。合否を誰が決めるか、持ち主は誰か。設計まで自分で書けてしまう人ほど、この2問に先に答えてから、指示文を書き始めたほうがいい。自分はそうしなかったので、5か月かかった。

「貼ればOKです」と書いた指示文は、消さずに残しておく。次に同じ一文を書きそうになったとき、先に2つの問いに戻るための目印にする。