メインコンテンツへスキップ

指示を出す直前に何を確認すべきか — 3つの自問と、汚れた作業ツリーへの委任

AIキャラクターのモデル調整で同じ型の誤りを1日に6回犯し、別の案件では委任先が未コミットの変更を無断変更と誤認して破棄した。指示・委任の直前に確認すべき点を整理する。

この記事は、AIエージェントへの委任設計に関する運用記録の1本である。AIキャラクターのモデル調整と、別の案件のLP改修委任、それぞれで指示・委任の出し方を点検した内容をまとめる。

この記事で分かること

  • 同じ型の誤りを1日に何度も繰り返した原因
  • 未コミットの変更が「無断変更」と誤認され破棄された経緯
  • 指示・委任の直前に自問すべき具体的な項目

この記事で分からないこと(正直に書く)

  • 3つの自問を挟んでも防げなかった誤りが他にどれだけあるか
  • 作業ツリーの汚れを機械的に検知する仕組みを導入したかどうか

何をしたか

AIキャラクターのモデルをリビルドする作業と、別プロジェクトのLP改修を委任する作業、それぞれで指示・委任の出し方を点検した(出所: 自社の運用記録、確認日2026-09-06)。

何が起きたか(1) — 同じ型の誤りを1日に6回犯した

ゼロ号室のキャラクターモデルをリビルドする作業で、参照した部位から値や基準を別の部位へ持ち込む際に、その値が成立していた条件を確かめないという同じ型の誤りを1日に6回犯した(出所: 自社の運用記録、確認日2026-09-06)。最も大きな1件は、ある前提が自社の参照実測と矛盾していたにもかかわらず、別の部位で通った判断をそのまま別の部位へ移してしまったことだった。

何が起きたか(2) — 無断変更と誤認され、正当な変更が破棄された

別のプロジェクトでLP改修をエージェントに委任した際には、依頼者側がすでに実装していた未コミットの変更を、委任先が「スコープ外の無断変更」と誤認し、git checkoutで破棄してしまう事故が起きた(出所: 自社の運用記録、確認日2026-09-06)。委任先は作業ツリーの由来を知らないため、自分が変更していないファイルの差分を事故や混入に見えると判断し、善意で「掃除」してしまった。

なぜ気づけなかったか

どちらの事故にも共通するのは、説明を1つ作れた瞬間に探索を打ち切るという点である。リビルド作業では、値を移す説明が1つ成立した時点でそれ以上の対立仮説を確かめなかった。委任の場面では、委任先にとって「見えている差分は自分がやっていない変更」という説明が1つ成立した時点で、無断変更という結論に飛びついた。どちらも、指示を出す側・受ける側それぞれの視点では、その場では筋が通って見えていた。

どう直したか

指示・基準を出す直前に3つを自問する運用にした。1つ目は対立仮説で、同じ症状を作れる別の原因を名前で挙げられるか確認し、挙げられなければ「無い」のではなく「調べていない」と判断して、先に対立仮説を確かめる測定を発注する。2つ目は基準の適格性で、渡す数値がそれを渡さないと捕まえられない欠陥を1つ名指しできない場合は、値でなく確認の手順そのものを渡す。3つ目は役割の同一性で、値が成立していた条件を書き出し、適用先で同じ条件が成り立つかを確認し、1つでも成り立たなければ値でなく測り方を渡す。委任の場面では、委任前に自分の作業をコミットすることを最優先にし、コミットできない場合はプロンプトに「作業ツリーには依頼者の未コミット変更が存在する。指定ファイル以外には触れず、git checkout・restore・cleanを実行しない」と明記する。

再発防止の手順

  1. 指示・基準を出す前に、対立仮説・基準の適格性・役割の同一性の3つを自問する
  2. 対立仮説を名前で挙げられない場合は、それを確かめる測定を先に発注する
  3. 委任前に自分の作業をコミットする。できない場合は作業ツリーの状態をプロンプトに明記する
  4. 委任先の完了報告に「スコープ外の変更を破棄した」とあれば、即座にgit statusと対象ファイルの存在を確認する
  5. 投入・採用の判断は、前段階の候補とだけでなく、現在の本番の状態と比較してから行う

指示・委任の前段として出典の扱いを確認する手順は「委任先が付けた出典は候補にすぎない」を、担当範囲を分ける具体的な書き方は「同じ10本のファイルを2系統のエージェントに書かせるとどうなるか」を参照してほしい。複数エージェントの判定をどこまで信じるかは「複数エージェントの批判が全滅判定を出すとき」にも通じる。

指示・委任設計の点検について相談したい場合は、お問い合わせから編集部まで連絡してほしい。

よくある質問

Q1. なぜ同じ型の誤りを1日に6回も繰り返したのか

参照した部位から値や基準を別の部位へ持ち込む際、その値が成立していた条件を確かめなかったため。説明を1つ作れた時点でそれ以上の対立仮説を確かめなかったことが根本の原因である。

Q2. なぜ正当な変更が「無断変更」と誤認されたのか

委任先は作業ツリーの由来を知らないため、自分が変更していないファイルの差分を事故や混入だと判断し、善意でgit checkoutにより破棄した。

Q3. 指示・基準を出す前に何を自問すべきか

対立仮説(同じ症状を作れる別の原因を名前で挙げられるか)、基準の適格性(渡す数値が無いと捕まえられない欠陥を名指しできるか)、役割の同一性(値が成立していた条件が適用先でも成り立つか)の3つである。

Q4. 汚れた作業ツリーで委任するときはどうすればよいか

委任前に自分の作業をコミットすることを最優先にする。できない場合は、作業ツリーに未コミット変更が存在すること、指定ファイル以外には触れずgit checkout・restore・cleanを実行しないことをプロンプトに明記する。

この記事に関連する業界別AI導入ガイド

地域ごとのAI導入状況・活用法・補助金情報をまとめています。

食品業界のAI活用(12.8%) 全業界を見る →

関連する取り組み

CONNECTED SERIES
AIで投資の壁を越える
18 本の実装記録。AI 投資の「予測不能」と言われる 9 つの壁を、コードと実データで検証した連載。
note で読む →
B2B API
Persona API
行動データから再構成した 2,245 体のペルソナを LLM 推論に注入。AI 出力の文脈リッチ化、顧客 segmentation に。
詳細を見る →

AI導入のご相談を承っています

AI導入支援の実務経験を活かし、お手伝いしています。お気軽にご相談ください。

他のカテゴリも読む

AI最新ニュース AI業界の最新ニュースと企業動向 AI導入戦略 AI投資判断・ROI分析・導入ロードマップ 業界別AI活用 製造・金融・小売など業界別のAI活用動向 導入事例 企業のAI実装プロジェクト事例とコンサルティング知見 研究論文 NeurIPS、ICMLなどの注目論文レビュー