この記事は、Sol・Terra・Lunaへ仕事を振るとき、「誰が担当するか」だけでなく「どのタイプで、どこまで任せるか」まで決めたい人向けだ。結論は、担当役割・実行タイプ・対象・禁止事項・完了条件・証拠を1つの依頼文に入れること。
今回わかったのは、AIを賢く見せる長い設定よりも、仕事を渡すときの型が大事だということだ。役割とタイプを分け、目的、対象、禁止事項、完了条件、確認方法までを1つの依頼文に入れる。これだけで、調査・実装・レビューの境界が見えやすくなる。
サブエージェントを強くするのは、モデルの名前より仕事の境界。
「改善して」だけでは、どこからが成功かわからない
「もっとよくして」「ざっくり改善して」という依頼は、始めるには簡単だ。しかし、何を変えるのか、何を残すのか、いつ止めるのかが決まっていない。担当者が自分で範囲を広げ、親が想定していないファイルまで触ることもある。
最初に書くべきなのは、完成した見た目ではなく、読者や利用者が最後に何をできるようになるかだ。そこから対象、制約、証拠へ分けていく。
- 目的: 何をできる状態にするか
- 対象: どのファイル、記事、URL、件数を扱うか
- 保持: 何を変えずに残すか
- 完了: どんな状態なら終わりか
- 証拠: 何を確認すれば終わりと言えるか
この5つが揃うと、依頼は「いい感じに」から「確認できる仕事」へ変わる。
Sol・Terra・Lunaは、能力ではなく役割で分ける
ここでいうSol・Terra・Lunaは、公式のモデル名を説明するものではない。今回の作業で使った、仕事の性質を覚えるための役割名だ。
- Sol: 目的、優先順位、設計、例外を決める
- Terra: 資料、前提、不明点、実装上の事実を調べる
- Luna: 対象と手順が決まった作業を実行し、証拠を返す
曖昧な仕事をいきなりLunaへ渡すと迷いやすい。逆に、単純な確認までSolへ渡すと判断の説明が増える。先に役割を決めると、モデル同士を競わせずに済む。
役割と実行タイプは別欄にする。たとえば「担当役割: Sol」「実行タイプ: max」と書く。maxはこの環境で使うタイプ名の例で、難しい設計判断や横断レビューに使うなら、その目的も併記する。タイプの意味や利用可否は、使っているエージェント定義を正本にし、名前だけで推測しない。
依頼文は役割・タイプを含む11項目で書く
9項目だけでは、誰にどの設定で頼むかが抜ける。先頭に担当役割と実行タイプを加えた11項目を最初に埋める。全部を長文で説明する必要はない。空欄を作らないことのほうが大切だ。
担当役割: 実行タイプ: 目的: 対象・入力: 正本・参照元: 変更してよい範囲: 変えてはいけないもの: 完了条件: 確認方法・証拠: 不明時に止める条件: 出力形式:
たとえば「Heroを改善して」ではなく、「担当役割: Terra。実行タイプ: worker。対象: モバイルの入力欄と送信ボタン。48px以上にする。16pxの文字は維持。既存のデスクトップ配置とダークモードを変えない。最終CSSの上書きまで確認し、変更ファイルと検証結果を返す」と書く。設計判断が必要なら、先にSolへ「実行タイプ: max」で方針と完了条件を決めてもらう。
この書き方なら、実装そのものだけでなく、後段のCSSに上書きされていないかまで完了条件にできる。
Grill Meは、実行前に隠れた分岐を潰す
型を作る前に「これで本当に使えるのか」と迷うなら、Grill Meのように質問を一つずつ返す工程を入れるとよい。いきなり実装を始めず、まず目的、対象、時間、公開境界を確定する。
- この仕事の読者・利用者は誰か
- 今回の対象はどこまでか
- 何を変えずに残すか
- 何をもって完了とするか
- 本番反映まで含めるか
質問は一度に一つがよい。推奨案と別案のトレードオフを添えると、答える側も判断しやすい。目的が決まっていないのに担当だけ増やすと、速く迷うだけになる。
Sol・Terra・Lunaに頼むときの実用テンプレート
実際に使うときは、次のように頼む。Solは設計判断、Terraは事実確認、Lunaは決まった作業の実行。役割ごとにタイプ、対象、禁止事項を分け、親は最後に差分と実効状態を確認する。
目的: 既存UIを壊さず、今回の改善をローカルで完成させる 対象: [具体的なファイル一覧] Sol: - type: max - 改善方針と優先順位を決める - 完了条件と確認項目を返す - 担当外ファイルは変更しない Terra: - type: explorer - 正本、前提、不明点を調べる - Solの方針に必要な事実と参照元を返す - ファイルと本番環境は変更しない Luna: - type: worker - 決定済みの定型作業だけを実行する - 変更箇所と確認結果を返す - 方針が曖昧なら開始せずSolへ戻す 共通: - 既存機能、本文、画像、公開状態を変更しない - 変更ファイル、検証結果、未確認点を短く報告する - 本番反映は親の明示指示があるまで行わない 親の完了条件: - 差分を確認する - 375px、ダーク、reduced-motionを確認する - 問題がなければ、別工程として本番反映する
いきなり全件へ広げず、10件で型を試す
新しい依頼テンプレートを作っても、最初から200件へ適用しない。まず10件だけ実行し、迷った箇所、聞き直し、修正、確認漏れを記録する。
- 10件: 依頼文の空欄と失敗の型を見つける
- 50件: 担当分けと完了条件が安定するか確認する
- 全件: 例外と公開前確認まで含めて広げる
今回も、SolとTerraが作業して終わりではなかった。SolはSolarの操作性を一貫して仕上げ、Terraはdeployの安全化とreduced-motionを進めた。一方で、HeroのCSSは親が最終上書きを見て補正した。
この差が大事だ。サブエージェントの報告をそのまま完了扱いにせず、親が実際の差分と最終状態を確認する。分担の目的は、親の判断をなくすことではなく、判断が必要な場所へ集中することだからだ。
まとめ：AIへのお願いを、再利用できる仕事に変える
サブエージェントに仕事を頼むとき、最初から完璧な長文を書く必要はない。ただし、目的、対象、保持するもの、完了条件、証拠だけは省略しない。
曖昧な部分はGrill Meで一つずつ深掘りし、決まった実装はTerraへ、例外と最終判断はSolへ、定型作業はLunaへ渡す。10件で試して、50件で安定させ、全件へ広げる。
AIを賢く使うために、モデル同士を競わせなくていい。お願いの型を整えれば、誰が何をするかが見え、失敗したときも次の依頼へ学びを戻せる。
