実務ならまずこう切り分けます

AIに同じ仕事を二回以上任せるなら、私は大事な指示をチャット欄だけに置きません。Markdownの作業指示書に移します。

理由は地味です。Markdownファイルなら業務フォルダに置けます。変更履歴も残せます。次の担当者が開いて読めます。長いプロンプトは初回には便利ですが、数日後に再実行すると、恒久ルール、その日の例外、仮の依頼が一つの文章に混ざっています。

OpenAI CodexのAGENTS.mdやSkills、Claude Codeのmemoryやsettings、MCPのpromptsを見ると、製品ごとの呼び方は違っても、方向は近いです。繰り返すAI業務には、会話の外に残る指示レイヤーが必要です。

私の基準は単純です。一回の答えならプロンプトで足ります。来月、別の担当者が同じ仕事を回すならMarkdownの作業指示書が向いています。

長いプロンプトが繰り返し業務で崩れる理由

長いプロンプトは最初の改善が早いです。背景を足し、条件を足し、例を入れると回答は良くなります。そこまでは問題ありません。

問題は三回目、四回目の実行で出ます。

「前回はどのプロンプトを使ったのか」と聞かれます。誰かが最後に例外条件を追加します。ファイルの場所が変わります。レポートの列名が変わります。事故の後で承認基準も変わります。プロンプトは長くて立派に見えますが、どの行が恒久ルールで、どの行がその日だけの事情なのかが曖昧になります。

AI自動化で時間が溶けるのは、モデルが文章を書けないからではありません。引き継ぎが柔らかすぎるからです。

プロンプトの癖後で起きることMarkdown作業指示書の癖
長文をチャットに貼る版が残らないルールをファイルに置く
同じ背景を毎回説明する担当者ごとに表現がずれる背景セクションを再利用する
「表にして」と頼む出力の形が毎回変わる必須フィールドを明記する
例外を会話で済ませる重要な例外が抜ける停止条件を分けて書く
目視だけで判断する確認基準が主観になる確認手順を置く
例をチャットに残す次回に消える例をルールの近くに置く
所有者を決めない誰も直さない担当者と更新条件を書く
ミスを手で直す翌月も同じミスが出るミスをファイルの規則に変える

これは机上の分類ではありません。一か月ほど実務で回すと見えます。最初の回答は悪くないのに、複数人が同じ弱い指示を直し続ける状態になります。

Markdownが合う仕事、合わない仕事

Markdownは万能ではありません。ファイルにするだけの反復性がある仕事に合います。

私が作業指示書へ移すのは、たとえば次のような仕事です。

  • 月次のベンダー比較メモ
  • 顧客フィードバックの分類
  • 会議メモの整形と次アクション抽出
  • 社内ポリシー草案の確認
  • スプレッドシートからの報告文作成
  • リリースノート準備
  • サポートチケットの振り分け
  • 反復する調査ブリーフ

共通点は「AIに書かせること」ではありません。引き継ぎです。入力があり、期待する出力があり、人が確認する地点があり、次回にも残すべきルールがあります。

逆に、一回だけの質問には作業指示書を選ばないほうがいいです。仕事そのものがまだ探索段階だったり、判断基準を人が説明できなかったりする場合、ファイルは手間を増やします。まず何度か動かして、同じ修正が二回出たら、その修正をルールにします。

私ならこの条件で決める: よい指示書は思ったより短い

よくある失敗は、作業指示書を分厚いマニュアルにしてしまうことです。

実際に使われるファイルは短いです。会社の全背景は書きません。起こりうる例外を全部並べることもしません。AIと担当者が同じ仕事を再開できるだけの構造を渡します。

私はまず九つの項目を見ます。

項目書く内容失敗の兆候
目的この仕事が必要な理由AIが違う目的を最適化する
背景この仕事に必要な最低限の文脈会社紹介のように長くなる
入力ファイル、期間、項目名AIが資料を推測する
出力条件形式、見出し、列、文体実行ごとに形が変わる
判断ルール分類、順位、承認、除外表現の雰囲気で判断が変わる
禁止事項編集、削除、公開、推測の禁止範囲外を触る
確認コマンド、目視、出典照合完了を誰も判断できない
停止条件人が見るべき状況危ない作業が進む
更新ルールいつファイルを直すか同じミスが翌月も出る

この九つが二、三画面で収まるなら使えます。初回実行の前に目次が必要なほど長いなら、仕事を分けたほうがよいです。

担当者に渡せるテンプレート

最初に作るなら、私は次の形にします。作業指示書はブランド文書ではなく、仕事を動かすファイルです。文章は普通で構いません。

# 作業指示書: [業務名]

## 目的
- この仕事が必要な理由:
- 成果物を使う人:
- 成果物が支える判断:

## 入力
- 元ファイル:
- 対象期間:
- 確認するシステム:
- 推測してはいけない項目:

## 出力条件
- 形式:
- 必須セクションまたは列:
- 文体:
- 保存先:
- 変えてはいけない内容:

## 判断ルール
- 分類基準:
- 優先順位:
- 十分な根拠:
- 人が判断する地点:

## 禁止事項
- 編集禁止:
- 公開禁止:
- 削除禁止:
- 推測禁止:

## 完了前の確認
- 検証手順:
- 目視確認:
- 出典照合:
- リンクまたはファイル確認:

## 停止条件
- 停止する状況:
- 担当者に聞く状況:
- メモに残す状況:

## 完了条件
- 成果物の場所:
- 確認通過:
- 未解決の質問:
- 別担当者がこのファイルで再実行可能:

## 更新ルール
- このファイルを直す条件:
- 担当者:
- 最終確認日:

この中で特に大事なのは「推測してはいけない項目」です。AIがもっともらしく埋めてはいけない値を先に止めるだけで、手戻りはかなり減ります。

例: 月次ベンダー比較メモ

月次のベンダー比較メモを例にします。支援ツール、CRM、社内ツールなどで、費用と利用状況を毎月確認する仕事です。管理者が知りたいのは、費用がなぜ動いたか、利用状況も動いたか、ベンダーと再確認すべきかです。

作業指示書なしだと、依頼はこうなりがちです。

ベンダーレポートを比較して要約して。

これでは薄いです。AIは読みやすいメモを書けますが、業務上の判断基準を落とすかもしれません。Markdownなら、こう絞れます。

  • 今月のエクスポートと前月のエクスポートだけを使う。
  • 更新見積もりがある場合は定価ではなく更新見積もりを優先する。
  • 利用増と席数増を分けて書く。
  • 費用が12%以上増え、利用が増えていない場合だけ確認対象にする。
  • 契約条件が不明なものは「確認事項」に送る。
  • 低利用と担当者確認の両方がない限り、解約提案は書かない。

これでAIは単に要約するのではなく、業務基準に沿って動けます。見る数字、止まる条件、使ってはいけない表現があるからです。

完了条件と停止条件

AIが文章を出しただけで仕事は終わりません。文章は簡単に出ます。完了は証拠で判断します。

最低限、完了条件には次の四つを入れます。

  • 期待した出力ファイルまたはページがある
  • 必須項目がそろっている
  • AIが使った元資料名が残っている
  • 例外と不足データが別に列挙されている

停止条件はさらに重要です。自信のある誤答を止める線だからです。

私は次のような条件を入れます。

  • 元ファイルがない場合は停止する。
  • 二つの資料で数字が合わない場合は停止する。
  • 成果物が外部公開につながる場合は停止する。
  • 顧客、決済、法務、セキュリティ情報が想定外に出た場合は停止する。
  • 削除、不可逆な編集、アカウント変更が含まれる場合は停止する。
  • ファイルにない事業判断が必要な場合は停止する。

ここで作業指示書はプロンプトを超えます。業務の境界になります。

最初の7日間の回し方

大きなプロセスとして始める必要はありません。反復する仕事を一つ選び、一週間だけ試します。

1日目は、すでに繰り返している業務を一つ選び、最初の作業指示書を書きます。三画面を超えないようにします。

2日目は、一度実行してAIが推測した場所を全部メモします。

3日目は、その推測を入力ルール、出力ルール、停止条件のどれかに変えます。

4日目は、別の担当者に同じファイルを渡し、追加説明なしで動かしてもらいます。

5日目は、手戻りを数えます。抽象的な精度ではなく、人が直した項目数を記録します。

6日目は、ファイルに残すルールと別チェックリストへ分ける項目を決めます。

7日目は、標準手順にするか捨てるかを決めます。悪い作業指示書は、ないより危険です。人に変な安心感を与えるからです。

次に接続するもの

Markdown作業指示書が安定したら、そこから強い自動化へ移せます。

Codex系のプロジェクト指示は、リポジトリ内でエージェントの振る舞いを決められます。Skillsは反復手順をファイルに残す考え方に近いです。Claude Code memoryはプロジェクト文脈を次回へつなぎます。MCP promptsはサーバー側から再利用できる依頼形を出します。

製品機能は別ですが、方向は同じです。繰り返す仕事では、その場限りのプロンプトより再利用できる文脈が強いです。

順番はこうです。

  1. Markdown作業指示書を先に作る。
  2. AI支援で手動実行する。
  3. 確認と停止条件を増やす。
  4. 安定した部分だけエージェント指示、スキル、プロンプトテンプレートへ移す。
  5. 失敗率が十分に退屈になるまで人の承認を残す。

粗い状態のまま自動化しないほうがいいです。まず、人が再実行できる程度まで指示を安定させます。

採用する前に確認すること

Markdownを選ぶなら、反復価値、担当者、出力条件があるかを確認します。きちんとして見せるためのファイルは続きません。

一番早い確認は、ファイルを別の人に渡して何も説明しないことです。その人が始められ、止まる場所も分かるなら使えます。始める前に質問が五つ出るなら、まだ指示は作成者の頭の中に残っています。

これは文章力の問題ではありません。運用設計の問題です。Markdownファイルは、その問題を早めに見えるようにします。

判断が変わる質問

Markdown作業指示書はプロンプト保存と違いますか？

違います。プロンプトは依頼文を良くします。作業指示書は依頼の周りの引き継ぎを良くします。入力、出力条件、確認者、停止条件まで入ります。

すべてのAI業務に必要ですか？

不要です。一回だけの質問には重いです。反復業務、共同作業、ファイルを使う仕事、確認負荷が高い仕事に向いています。

ファイルはどこに置くべきですか？

仕事がある場所に置きます。リポジトリならAGENTS.mdや/docs/operations/が候補です。業務フォルダなら元スプレッドシートやレポートの近くがよいです。次回すぐ見つかることが大事です。

失敗した後、最初に直す場所は？

停止条件と出力条件です。私が見た失敗の多くは、AIが値を推測する、例外を飛ばす、次のシステムへ渡せない形で出す、のどれかでした。

再利用できるMarkdown作業指示書に、文脈、出力条件、確認、停止条件、更新ルールを配置した構成図
Markdownの作業指示書は、使う資料、作る成果物、確認方法、止める条件まで書かれて初めて現場で使えます。

参考にした資料