受託開発やSES、フリーランスでの参画そのものを否定したいわけではありません。
ただ、AIを入れたときに、情報分断や権限分断がより見えやすくなるのではないか、という話です。
はじめに
前回は、AI時代でもヒアリングミスは簡単には消えない、という話を書きました。
今回は、もう少し実装寄りの話です。
AIエージェントをチームで使うとき、まず考える対策の一つに、共通ルールを整備するというものがあります。
たとえば、以下のようなものです。
- AGENTS.md
- CLAUDE.md
- Kiroのsteering file
- Copilotのcustom instructions
- プロジェクト独自のAI利用ルール
- 共通プロンプト
- テンプレート
- ハーネス
ここでは、ハーネスという言葉を少し広めに使っています。
AIに読ませる前提、作業時のルール、実行方法、確認方法などをまとめて、各担当者が同じように使えるようにしたもの、くらいの意味です。
こうした共通ルールやハーネスは、かなり大事だと思います。
ただ、実際にやってみると、それだけでは期待したほど結果が揃わないことがあります。
同じルールを配った。
同じ前提も渡した。
同じような作業をしている。
それでも、担当者ごとにAIの出力が微妙に違う。
実装方針がずれる。
差分の大きさが変わる。
レビューのしやすさも変わる。
なぜそうなるのか。
今回は、「共通ルールを配っても、AIの出力はなぜ揃わないのか」について考えてみます。
共通ルールを作れば揃うと思っていた
AIをチーム開発に入れるとき、最初に考えるのはルール整備だと思います。
たとえば、次のようなルールです。
- 既存コードを優先する
- 仕様変更と関係ないリファクタをしない
- 共通コンポーネントを勝手に変更しない
- 変更前に方針を説明する
- テストを追加する
- 差分を小さくする
- 作業後に変更内容を要約する
こういうルールは有効です。
AIに毎回同じ前提を説明しなくてよくなります。
担当者ごとの作業方針もある程度揃えやすくなります。
レビュー時にも、「このルールに沿っているか」を見やすくなります。
そのため、共通ルールを整備すること自体は、かなり意味があると思います。
ただ、ここで一つ期待しすぎていたところがありました。
それは、共通ルールを配れば、AIの出力もかなり揃うのではないか、という期待です。
実際には、そこまで単純ではありませんでした。
同じルールでも、頼み方が違う
同じルールを使っていても、担当者ごとにAIへの頼み方は違います。
たとえば、ある人は最初に広く調査させます。
まず既存コードを読んで、実装方針を3案出してください。
まだ変更はしないでください。
別の人は、最初から実装を頼みます。
この機能を追加してください。
既存の実装に合わせてください。
また別の人は、かなり細かく制約を書きます。
変更してよいファイルはこの3つだけです。
共通コンポーネント、APIクライアント、状態管理は変更しないでください。
問題を見つけても報告だけにしてください。
どれが絶対に正しい、という話ではありません。
作業内容によっては、広く調査させた方がよいこともあります。
小さい修正なら、すぐ実装してもらった方が速いこともあります。
影響範囲が大きいなら、制約を強めた方が安全なこともあります。
ただ、頼み方が違えば、AIの出力も変わります。
同じルールを読ませていても、直近の指示、読ませたファイル、会話の流れ、担当者の判断によって、AIの動き方は変わります。
AIへの話し方には、その人のアイデンティティがある
ここが、最近かなり大事だと感じています。
AIへの頼み方は、単なる操作手順ではないと思います。
その人の仕事の進め方が出ます。
設計への考え方が出ます。
慎重さが出ます。
怖がっているポイントが出ます。
どこまでAIを信じるかも出ます。
言い換えると、AIへの話し方には、その人のアイデンティティがあるのだと思います。
ある人は、AIをかなり信頼して大きく任せる。
ある人は、AIを便利な補助者として扱い、細かく確認しながら進める。
ある人は、AIに設計案だけ出させて、実装はかなり制御する。
ある人は、AIの提案を積極的に取り入れて、既存コードも改善しようとする。
これは性格の問題というより、経験や価値観の違いだと思います。
過去にAIの大きな差分で苦労した人は、かなり慎重になります。
逆に、AIに広く任せてうまくいった経験がある人は、大きく任せたくなります。
どちらにも理由があります。
だから、「全員この言い方でAIに頼んでください」と強制するのは、あまり現実的ではないと感じています。
もちろん、最低限のルールや禁止事項は必要です。
しかし、AIとの会話の仕方を完全に統一しようとすると、かなり無理が出ます。
プロンプトの統一には限界がある
共通プロンプトを用意することはできます。
たとえば、以下のようなテンプレートです。
目的：
変更してよい範囲：
変更してはいけない範囲：
既存設計で守ること：
実装前に確認してほしいこと：
作業後に報告してほしいこと：
これはかなり有効です。
特に、経験の浅いメンバーがAIに雑に依頼して、意図しない大きな差分を作ってしまうのを防ぐ効果があります。
ただし、テンプレートを配っても、そこに何を書くかは人によって変わります。
どこまでを変更可能範囲と見るか。
何を禁止事項として書くか。
どの既存設計を重要だと判断するか。
実装前にどこまで調べさせるか。
ここには、担当者の判断が入ります。
つまり、プロンプトの型は揃えられても、プロンプトの中身までは完全には揃いません。
そして、その中身の違いが、AIの出力の違いにつながります。
共通ルールは「出力を揃える魔法」ではない
ここで言いたいのは、共通ルールが無意味ということではありません。
むしろ、共通ルールは必要です。
ただし、共通ルールに期待する役割を間違えると、うまくいかないのだと思います。
共通ルールは、AIの出力を完全に揃える魔法ではありません。
どちらかというと、AIと人間が作業するときの最低ラインを揃えるものです。
たとえば、以下のような効果です。
- 勝手な大規模リファクタを減らす
- 変更範囲を意識させる
- 既存設計を優先させる
- 作業前の確認を促す
- 作業後の説明を揃える
- レビュー観点を共有する
これは十分に価値があります。
しかし、共通ルールだけで、担当者ごとの判断やAIへの話し方まで揃うわけではありません。
その前提で、チーム設計を考える必要があります。
揃えるべきなのは、話し方よりも境界かもしれない
AIへの話し方を完全に揃えるのが難しいなら、何を揃えるべきなのでしょうか。
私は、担当境界と成果物の条件を揃える方が現実的ではないかと思っています。
たとえば、次のようなものです。
- この担当者が責任を持つ業務範囲
- 変更してよいコード範囲
- 変更してはいけない共通領域
- 他機能とのインターフェース
- データの正
- 状態遷移
- 受け入れ条件
- レビュー観点
つまり、「AIにどう話すか」を完全に縛るのではなく、「最終的に満たすべき条件」を揃えるという考え方です。
AIへの頼み方には個人差があります。
そこを完全に消すのは難しいです。
しかし、担当範囲、責務、インターフェース、受け入れ条件が明確なら、AIの使い方が多少違っても、成果物のズレは抑えやすくなります。
細かく分けすぎると、AIのブレが表に出る
AIを使うチーム開発では、細かすぎる作業分担が難しくなることがあります。
たとえば、次のような分け方です。
Aさん：画面の入力項目
Bさん：バリデーション
Cさん：API呼び出し
Dさん：状態管理
Eさん：共通コンポーネント修正
人間だけで開発していた時代にも難しい分担ですが、AIを使うとさらに難しくなることがあります。
各担当者がAIを使って、それぞれ少しずつ良さそうに直す。
すると、入力項目、バリデーション、API、状態管理、共通コンポーネントの前提が少しずつずれます。
しかも、それぞれの差分だけを見ると悪くないことがあります。
しかし、最後に合わせると、微妙に噛み合わない。
これは、AIの出力品質が低いというより、作業分担が細かすぎて、各AIが局所的な文脈で動いていることが原因かもしれません。
もう少し大きなブロックで担当する
そのため、AIを使うなら、担当者の分け方を少し変えた方がよいのではないかと感じています。
細かい部品単位ではなく、もう少し大きな業務ブロックや責務単位で分ける。
たとえば、次のような分け方です。
Aさん：申請フロー全体
Bさん：請求データの登録から確定まで
Cさん：通知設計と通知履歴
Dさん：帳票出力と出力条件
この分け方なら、担当者とAIが一つのまとまった文脈を持ちやすくなります。
画面、API、状態、バリデーション、テストをばらばらに見るのではなく、一つの業務の流れとして考えやすいです。
もちろん、大きく分ければすべて解決するわけではありません。
大きすぎる担当はレビューしづらくなりますし、属人化も起きます。
ただ、AIを使う場合、あまりに細かい部品単位で分けると、担当者ごとのプロンプトの違いがそのまま設計のズレとして出やすいのではないかと思います。
その意味で、AI時代の担当分けは、単なる作業量ではなく、文脈のまとまりで考える必要があるのかもしれません。
それでも共通ルールは必要
ここまで書くと、「では共通ルールはいらないのか」と見えるかもしれません。
そうではありません。
共通ルールは必要です。
ただし、目的を少し変えて考える必要があります。
共通ルールの目的は、全員のAIの出力を完全に同じにすることではありません。
むしろ、以下のような目的だと思います。
- やってはいけないことを明確にする
- レビュー不能な差分を減らす
- AIが迷ったときの判断基準を置く
- 担当境界を越えた変更を防ぐ
- 作業後の説明を残す
- チームとして最低限の安全性を確保する
つまり、共通ルールは「個人差を消すもの」ではなく、「個人差があっても壊れにくくするもの」です。
この捉え方の方が、現実に近い気がします。
おわりに
AIエージェントをチームで使うなら、共通ルールやハーネスはかなり重要です。
ただ、それを配れば全員のAI出力が揃う、というほど単純ではないと思います。
同じルールを読ませても、担当者ごとにAIへの頼み方は違います。
どこまで任せるか、どこで止めるか、どのファイルを読ませるか、どの提案を採用するか。
そこには、その人の仕事の進め方や設計観が出ます。
AIへの話し方には、その人のアイデンティティがあります。
そして、それを完全に強制することは難しいです。
だからこそ、チームで揃えるべきものを少し変える必要があるのだと思います。
話し方を完全に揃えるのではなく、担当境界を揃える。
プロンプトを完全に統一するのではなく、成果物の受け入れ条件を揃える。
細かい部品単位で人を分けるのではなく、文脈を持てる業務ブロックで考える。
AI時代のチーム開発では、個人のAI活用を無理に均一化するより、個人差があっても破綻しにくい分担とレビューの仕組みを作る方が大事なのかもしれません。
シリーズ構成
- 【AIエージェント時代のSES・受託開発を考える⑨】SESや多重下請けの現場では、AIだけでは開発はうまくならない
- 【AIエージェント時代のSES・受託開発を考える⑩】AIはヒアリングミスをどこまで救えるのか
- 【AIエージェント時代のSES・受託開発を考える⑪】共通ルールを配っても、AIの出力はなぜ揃わないのか
- 【AIエージェント時代のSES・受託開発を考える⑫】機能ごとに人を割り振ると、AIの強みが消えるのではないか
- 【AIエージェント時代のSES・受託開発を考える⑬】仕事を出す側が背景を渡せないと、AIも判断できない
- 【AIエージェント時代のSES・受託開発を考える⑭】判断権限のない現場で、AIの提案はどこまで活かせるのか
- 【AIエージェント時代のSES・受託開発を考える⑮】SES現場でAIを使う前に揃えたい前提
- 【AIエージェント時代のSES・受託開発を考える⑯】AIを入れても改善しにくい現場の特徴