一人の熟練者だけが、AIへ何を渡し、どこで止め、結果を採用するかを毎件判断している。その人が業務から離れても、別担当者は同じ仕事を進められるでしょうか。手順書を渡しただけでは、この問いには答えられません。
ここで中心となる問いは、「熟練者の判断をSkill・検査・停止へどう移せば、別担当者が作成者の常時介入なしにAI支援業務を一件進められるか」というものです。
一件の成果物から熟練者の介入を取り出し、AIへの手順、入力の検査、停止、運用担当者の採否へ割り当てます。判断を移したつもりで未経験者が誤った結果を通さないよう、成果物と停止状態で試します。
そのためには、いきなりAIへの指示を細かく書き連ねるのではなく、Skillの長い文書を書く前に、代表タスクでSkillなしの失敗を記録し、評価ケースと基準を作ることが推奨されています。
熟練者の介入がない状態でAIがどのように間違えるかを観察することで、システム化すべき判断基準が明確になります。
また、AIモデルが「処理を完了しました」と宣言することと、実状態が成功しているかは別問題です。検証にあたっては、評価のtaskは入力と成功条件を持つ一件であり、試行を経て最後に成立した状態（outcome）を確認するというアプローチで、実際の出力データを測る枠組みが必要です。
通し例は架空の小型デスクライトの商品案内です。入力の欠落と矛盾を止める小さな検査を実際に試し、Skillから成果物の採否までを一件の経路として設計します。AIによる下書きと別担当者の運用結果はまだ検証していません。
以下では、判断をどこへ実装するか、停止後に何を残すか、別担当者の試行で何を測るかを順に考えます。
熟練者が毎件している判断を、成果物から逆算する
一件の成果物と、熟練者が途中で加えた修正・差し戻し・停止を並べます。そこで「何を見て進めたか」「何が欠けると止めたか」を、次回も同じ入力で確かめられる条件にします。
たとえば「小型デスクライトの商品案内作成」という架空の業務を例にします。熟練者は単に文章を整えているだけでなく、渡された製品資料をもとに以下のような判断を行っています。
- 資料に「バッテリー駆動時間」の記載がなければ、推測で埋めずに仕様の責任者へ確認する。
- 二つの資料で明るさが300ルーメンと500ルーメンに分かれたら、どちらかを選ばず停止する。
これらは、人間が後からAIの出力を見て手動で修正するための項目ではなく、あらかじめ「停止条件」として組み込むべき要素です。この判断のうち、項目の欠落と二資料の値の食い違いは入力検査へ移せます。一方、文章の用途に合うか、根拠が主張を本当に支えるかは別の確認が必要です。
このように入力段階で弾くべきものを定義した上で、AIの評価について考えます。
評価フレームワークにおいて、タスクとは初期の入力と成功条件を持つ一件の処理であり、試行を経て最終的に成立した状態（outcome）として記録されます。ここで重要なのは、AIモデル自身が「完了しました」と宣言することと、実際の状態が成功条件を満たしているかはまったく別の問題だということです。
欠落と値の食い違いは同じ入力に対して確認できる条件になりました。次に、取り出した条件をSkill・検査・担当者のどこへ置くか決めます。
Skillには作業手順、検査には合否、担当者には採否を置く
条件を置く場所は三つです。SkillにはAIが読む資料と作業順、検査には明示的な停止条件、運用担当者には資料との照合と公開前の採否を渡します。
第一の層であるAIのSkillには、具体的な作業の進め方を置きます。Skillの指示は簡潔に保ち、変わりやすい補足は参照ファイルへ分けます。評価ケースで失敗した際に必要な内容だけを足していくのが基本です。
今回作った例のSKILL.mdは、job.jsonを受け取り、下書き前にpreflight.pyを呼び、STOPなら文章を書かずに理由を返し、READYなら許可された仕様から案内文と事実の参照箇所を作る手順です。商品仕様はSkill本文へ書き込まず、入力ファイルに置きます。
第二の層である検査には、客観的な条件の確認を任せます。AIに厳密な論理チェックを任せると不安定になりがちであるため、壊れやすい処理は具体的なスクリプトとして切り出すことが推奨されています。
今回、架空のデスクライト仕様を検証する入力検査コードpreflight.pyを作成し、実行しました。このコードでは必須五項目（product_name、audience、use_case、light_output_lm、drive_time_h）の存在を確認します。空欄、参照元の有無、同一項目の値の食い違いも検査します。
正常・欠落・矛盾の三入力を流した結果は後で詳しく見ます。ここで確認したのは入力の検査までで、下書き生成と別担当者による運用はまだ試していません。
第三の層では、運用担当者が出力と原資料を読み、採否または資料の責任者への差し戻しを決めます。担当者がAIの不完全な出力を毎件手作業で修正したり、欠落した情報を勘で補ったりする運用は避けるべきです。業務を別担当者へ引き継ぐ際は、反復手順の入力と出力、責任者、判断分岐、例外時の相談先を明確にする必要があります。
STOPなら理由と資料を仕様の責任者へ返し、READYの後にできた下書きは原資料と照合して採否を決めます。形式検査の通過だけで案内を公開しません。
別担当者が日々触るのは案件ごとのjob.jsonと、STOP理由を示すresult.json、照合待ちの下書きです。Skillと検査コードを毎件編集させません。失敗が再現したら、Skillの管理者がその入力を試験ケースに加え、手順または検査を直して版を更新します。
ここで検査へ移せたのは、仕様の欠落と値の食い違いです。文章の意味と実際の運用を確かめるまでは、作成者の常時介入が不要になったとは言えません。
定時に一件を進め、止まった理由を残す
Skillを渡しただけでは入力検査も停止も自動では動きません。定時の起動役が未処理の一件を取り出し、同じ案件を二重に処理しないよう案件IDを記録してから、検査、Skill、成果物保存へ進めます。STOPが出た時点で後続処理を起動しません。
一件の状態は、未処理→入力検査→READYまたはSTOP→下書き→照合待ち→採用・差し戻しと移します。STOPならresult.jsonの理由を資料の責任者へ返し、次の定時実行では自動再開しません。資料の修正版を新しい入力版として受け取ってから再投入します。
照合待ちも担当者の採否が出るまで進めません。このジョブ管理と定時起動は設計段階で、今回実行したのは入力検査だけです。
今回実行したpreflight.pyはjob.jsonを読み、result.jsonへREADYまたはSTOPと理由を保存します。
READYのときだけ、実行環境がSkillへ許可済みの仕様を渡し、案内文の下書きdraft.mdと各事実の参照箇所を残す設計です。STOPなら下書き工程を起動しません。これは後段のAI生成まで実施した結果ではなく、担当者が一件を進めるための実行経路です。
下書き後には、参照箇所のない数値や主張を確認対象として保留し、運用担当者が原資料と照合します。入力検査を通過しても、モデルが指示どおりに書いたと保証はできません。
そして処理が途中で止まった際は、「停止記録」を残す仕組みが不可欠です。AIを用いた処理の検証性を高めるには、エージェントの発話や経路と、保存されたファイルなどの最終状態は別々に確認するという原則に従います。
実行環境では、result.jsonに停止状態と理由を保存し、どの入力版をどの順に処理したかを別の実行記録へ残す設計にします。今回のサンプルで実際に保存したのは前者です。
停止理由と資料の持ち主を結びつければ、担当者は作成者を毎回呼び出す前に、資料の確認先へ不足を返せます。この経路が使えるかは、正常・欠落・矛盾入力と別担当者の試行で確かめます。
正常・欠落・矛盾の三つの入力で試す
正常な入力でREADYを返すだけでは、危ない入力を通さないか分かりません。今回の公開用サンプルには、欠落と値の食い違いを含む入力も作り、保存されたresult.jsonを確認しました。
正常入力の
normal.jsonには五項目と参照元を入れ、検査結果がREADYになることを確認しました。ここでは案内文の生成までは試していません。欠落入力の
missing.jsonではdrive_time_hを外し、result.jsonがSTOPとmissingを返すことを確認しました。STOP時に下書き工程を起動しないかは、実行環境を接続してから別に試します。矛盾入力の
conflict.jsonでは、明るさについて架空の二資料に300と500を置き、result.jsonがSTOPとconflicting_valuesを返すことを確認しました。『手元用』と『部屋全体』の意味上の矛盾は、このコードでは検査できません。
仕組みを構築する際は、Skillの動作を代表的なタスクで評価し、異なる条件でも試すことが推奨されています。もしテストの段階で、AIが推測で書いてしまったり矛盾を見逃したりした場合は、事前になんでも防ごうと説明書を長く書き連ねるのではなく、発生した失敗に対してのみ最小限の指示をSkillに追加します。
また、テストにおいて「誤った通過」を見逃さないためには、検証方法の使い分けが必要です。
文字数や必須文言の有無はプログラムで確実に見つけられますが、コードによる検査は特定の条件を再現性高く確認できる一方で、意味の破綻や自由文の品質を測るには限界があるとされています。
そのため、「矛盾を無視してもっともらしく書き切ってしまった」というような意味的な誤通過はコードの検査だけでは防げないことがあり、評価対象に合わせてテスト段階で人の判断を組み込んで最終状態を確認します。
今回の三入力では、項目の欠落と同一項目の値の食い違いに対する入力検査の動作だけを確認できました。案内文の意味、参照資料との対応、別担当者による運用は別の試験が必要です。
別担当者に一件を任せ、残る熟練者の介入を測る
入力検査だけが通っても、未経験の担当者が成果物を正しく扱えるとは限りません。Skillから採否までの経路を用意した後で、別担当者の一件を受け入れ試験にします。
次に別担当者へ、作成者が口頭で補足せずに一件を進める試験を依頼します。公式のSkill作成指針も別の実行者の利用を観察して改訂する方法を示しています。ここで確認するのは、担当者が作成者の頭にある条件を聞かずに着手し、停止理由と成果物を扱えるかです。
架空の「小型デスクライトの商品案内作成」を例に考えてみましょう。別の担当者に、架空の明るさなどの性能値が書かれた仕様書を渡し、実際にAIツールを動かして作業を進めてもらいます。
試験中に熟練者が助言した場合は、その時点と理由を記録します。記録するのは、担当者がSTOPの理由から資料の確認先を選べたか、READY後の下書きと原資料を照合できたか、作成者に何を聞いたかです。本人の操作記録と成果物で確認し、感想だけを成功判定にしません。
熟練者の助言や事後修正が必要だったら、理由を入力不足、検査漏れ、品質判断、権限の問題に分けて記録します。介入が生じた原因を分析する際は、タスク（初期の入力や目標）と試行、途中の記録、最終状態（outcome）を区別します。試行後の実状態を確認する評価の枠組みです。
担当者が作業に迷った場合でも、無闇にAIのSkillの指示文を長くするのではなく、「自動検査のスクリプトに漏れていた条件を追加する」や、「例外発生時の相談先ルールを明確にする」といった形で、プロセス全体を修正します。
別担当者の試行では、着手できたか、STOP時に資料の確認先を選べたか、作成者を何回・何のために呼んだか、成果物に誤った通過がないかを記録します。未実施の試験から独立運用や効果を断定せず、残った介入のうち規則化できるものをSkillと検査へ戻します。
よくある質問
自動化されたAI支援プロセスを引き継いだ後、運用責任は誰が持ちますか？
公開の採否を決める人、Skillと検査を更新する人、入力資料を確定する人を、業務の開始前にそれぞれ指定します。
熟練者の常時介入なしに回る仕組みを作ったとしても、それは誰も責任を負わずにシステムを放置してよいということではありません。業務をチームへ引き渡す際は、AIツールを渡すだけでは足りません。反復手順の入力と出力、責任者、判断分岐、例外時の相談先を明確にします。
架空の案内文では、仕様の持ち主が入力を確定し、運用担当者が下書きと原資料を照合し、公開責任者が最終的な掲載可否を決める分担が考えられます。組織で同じ人が複数の役割を担う場合も、判断の所在は記録します。
情報不足やエラーでAIが作業を停止した場合、どのように再開すればよいですか？
停止理由を確認し、資料の責任者が不足や矛盾を解消した版を用意してから、同じ入力検査を再実行します。
たとえばresult.jsonが駆動時間の欠落を示した場合、下書きへ進まず仕様の責任者に確認を戻します。修正版を受け取ったら入力検査からやり直し、旧版と混ぜません。
再実行では修正された資料の版、前回のSTOP理由、新しいresult.jsonを残します。READYへ変わったことだけで案内文を採用せず、下書きの原資料との照合を続けます。
自動検査を通過した成果物は、すべて「成功」と判定してよいのでしょうか？
結論から言えば、自動検査の通過はあくまで形式的な前提条件を満たしたに過ぎず、最終的な品質における成功判定の境界は担当者が担います。
コードは、指定された数値や文言の有無を繰り返し確認できます。一方、意味の破綻や自由文の品質はコードだけで測れません。評価対象に応じて人が判断します。
架空例の事前検査が弾けるのは、入力の必須項目の欠落と、同じ項目に異なる値が並ぶ場合です。
しかし、「ターゲット層に響く自然な文脈になっているか」といった定性的な境界線を、コードの検査だけで完璧に保証することは困難です。検査通過後に人が原資料と下書きを読み、意味のずれがあれば公開を止めます。その判定が新しい入力でも繰り返し必要なら、Skillの指示か確認手順へ戻せるか検討します。
AIを組み込む仕事の流れづくりをご支援します
Deskrexでは、AIを使って調査・制作・分析などの仕事を進めるために、工程と役割分担を設計し、実装する支援を行っています。AIに渡す資料や指示、使えるツール、人が確認する箇所を整理し、一連の仕事として動く仕組みをつくります。
まず、届けたい成果物と現在の作業手順を確認し、実際の仕事をAIで試します。品質、処理量、時間、費用を見ながら、今すぐ任せられる作業と、追加の設計や開発が必要な作業を確かめます。
その結果をもとに、工程の統合や並列化、ツール連携、結果の検証と修正の手順を組み込みます。実行回数や費用の上限、人の判断を待つ条件、途中の状態を保存して再開する方法も含めて設計し、実務で動作を確かめます。
業務へのAI導入やワークフロー作成のご相談は、AIワークフロー作成支援のご案内からお問い合わせください。任せたい仕事と、現在使っているツールを伺い、取り組む範囲を一緒に整理します。
市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai
