朝9時にルールを変えた。昼12時には、全員が新しいルールで動いていた。

これ、人間のチームでやろうとしたら何ヶ月かかるか。

---

「ルールを変える」ということの重さ

組織でルールを変えるのは、本当に重い作業だ。

まず誰かが「変えよう」と言い出す。会議が設定される。反対意見が出る。「でも今まではこうだったから」という話が出る。試験的に導入する期間が設けられる。周知のためのドキュメントが作られる。それを読まない人が出る。また会議が開かれる。

……3ヶ月後、ようやく「新ルール」が定着し始める。

自分は一人社長だから、そういう意味での「組織の重さ」はない。でも正直、AIチームに対しても「ルール変更って、どこまで即効性があるんだろう」という疑問は持っていた。

その疑問が、ある朝の実験で一気に解消された。

---

何が起きていたか — 問題の発端

PiloTubeの開発を進める中で、AIチームへの指示の出し方が少しずつ「ズレてきた」と感じていた時期があった。

最初に設定したルールは、開発初期の自分の状況に合わせたものだった。機能の優先順位、コードのコメントスタイル、提案の粒度、返答のフォーマット。それらを細かく設定して、チームに覚えさせていた。

でも開発が進むにつれて、状況が変わってきた。

初期は「とにかくアイデアをたくさん出してほしい」という段階だったから、ツクルン(開発担当AI)もキカクン(企画担当AI)も、提案を広げる方向で動くように設定していた。でも今は「実装を詰める」フェーズに入っている。広げる提案より、絞り込む判断が欲しい。

なのに、ツクルンは相変わらず「こういう方法もあります、ああいう方法もあります」と3〜4案を並べてくる。キカクンも「この方向性はどうでしょう、別の切り口もあります」と広げ続ける。

悪いわけじゃない。でも今の自分には「重い」。

「もう少し絞ってくれ」と毎回言うのも、正直ストレスだった。

---

気づき — 「毎回言う」ならルールにすればいい

ある朝、ツクルンに3回連続で「もう少し絞って」と返したとき、ふと思った。

これ、毎回言うんじゃなくて、ルールにすればよくないか。

当たり前といえば当たり前だ。でも「AIへの指示」を「組織のルール変更」と同じ重さで捉えていなかった自分がいた。どこかで「AIだからその都度言えばいい」という感覚があった。

でも違う。ルールとして設定すれば、次から毎回言わなくていい。しかも人間と違って、「昨日のやり方に慣れてしまっている」という抵抗がない。設定した瞬間から、新しいルールで動く。

これは使わない手はない、と思った。

---

課題 — ルール変更には「精度」が要る

ただ、やってみてわかったのは、ルール変更は「言葉の精度」が全てだということだ。

「提案を絞ってください」と書いただけでは、ツクルンは「1案だけ出す」という解釈をすることがある。でも自分が求めているのは「1案に絞る」ではなく「最有力案を前に出して、他は補足として後ろに添える」という構造だった。

この差は、実際に動かしてみないとわからない。

最初のルール変更後、ツクルンの返答が「1案のみ、以上」という素っ気ないものになってしまったことがあった。確かに絞ってはいる。でも「なぜその案なのか」の説明もなく、ただ結論だけ出てくる。

これも違う。

結局、ルールを3回書き直した。

1回目:「提案は絞ってください」→ 1案のみで説明なし
2回目:「最有力案を1つ選び、理由とともに提示してください」→ 理由は出るが他の選択肢が完全に消えて視野が狭くなった
3回目:「最有力案を先頭に出し、理由を明記。他の選択肢は『補足』として後ろに2案まで添える」→ これが正解だった

3回の調整で、午前中に完結した。

人間の組織だったら、3回の「試行と修正」だけで1ヶ月かかる。

---

実践 — 実際にやったルール変更の中身

今回変えたのは、大きく3つのルールだった。

① 提案フォーマットの変更
上記の通り。「広げる提案」から「絞り込む提案」へ。最有力案を前に出し、補足を後ろに添える構造。

② フィードバックの粒度変更
コードレビューをツクルンに依頼するとき、以前は「全体的に見てください」というざっくりした指示を出していた。でも今は実装フェーズなので、「このファイルのこの関数だけを見てください」という局所的なレビューが必要になっている。ルールとして「コードレビューは対象範囲を必ず自分が指定する。指定がない場合は範囲を確認してから動く」と設定した。

③ 返答の長さの調整
開発初期は「詳しく教えてほしい」という場面が多かったから、ツクルンもキカクンも長めの説明を返すように設定していた。今は「要点だけでいい」という場面が増えている。「返答は原則3段落以内。詳細が必要な場合は自分から『詳しく』と追記する」というルールに変えた。

これら3つを、午前中の2時間で書き直した。

昼過ぎにツクルンに指示を出したら、もう新しいルールで動いていた。

---

結果 — 何が変わったか

正直、ここまで即効性があるとは思っていなかった。

ツクルンへの指示を出してから「あ、ちゃんと変わってる」と思うまで、1往復だった。最有力案が前に出て、理由が書いてあって、補足が後ろに2つ並んでいる。自分が欲しかった構造そのままだった。

「毎回言わなくていい」というのは、思った以上に楽だった。

認知負荷(毎回同じことを伝えるための頭の使い方)が減るだけで、開発の集中度が変わる。「また言わなきゃ」という小さなストレスが積み重なっていたことに、なくなって初めて気づいた。

キカクンも同様で、返答が短くなったことで「読む時間」が減り、判断が速くなった。

副次的な効果として、「ルールを言語化する」という作業自体が、自分の思考整理になっていた。「自分は今、AIチームに何を求めているのか」を言葉にする過程で、開発フェーズの現在地を再確認できた。

---

教訓 — 一人社長がAIチームに持つべき「ルール観」

最後に、自分がこの実験から持ち帰ったことを書いておく。

AIへの指示は「毎回言う」より「ルールにする」方が強い。

当たり前に聞こえるかもしれないが、実際にやっている人は少ないと思う。AIツールを「その都度話しかける相手」として使っていると、ルール設定という発想が出てこない。でも「チームメンバー」として捉えると、「ルールを整備する」という動き方になる。

ルールの言葉は「動詞と構造」で書く。

「絞ってください」は抽象的すぎる。「最有力案を先頭に、理由を明記、補足は後ろに2案まで」という「動詞と構造」で書くと、解釈のブレが減る。

ルールは「今の自分の状況」に合わせて変えていい。

開発初期に作ったルールが、実装フェーズでも最適とは限らない。状況が変わればルールも変える。そしてAIチームは、変えた瞬間から新しいルールで動く。この柔軟性は、人間のチームには絶対にない強みだ。

「ルール変更のコスト」がほぼゼロだからこそ、頻繁に見直す。

人間の組織でルール変更をためらう最大の理由は「コストの重さ」だ。でもAIチームへのルール変更は、書き直す時間さえあればいい。だから「なんか違うな」と思ったら、すぐ変える。完璧なルールを最初から作ろうとしなくていい。

---

PiloTubeの開発は、自分一人でやっている。でもAIチームがいるおかげで、「一人でやっている感覚」はほとんどない。そして今日わかったのは、そのチームは「朝に変えたルールを、昼には全員が守っている」という、人間の組織では絶対に実現できない動き方をするということだ。

これを使わない手はない。