要点
繰り返すAI自動化業務なら、私は重要な指示をチャット欄だけに残しません。Markdownファイルにして、範囲、入力資料、出力形式、確認手順、停止条件、担当者を置きます。プロンプトは一回の回答を良くできますが、作業指示書は次回の実行を安定させます。
- 長いプロンプトでも、版管理と再利用ができなければ一回限りの依頼に近いままです。
- Markdownは、繰り返す業務、ファイルを使う業務、人の確認が必要な業務に向いています。
- 重要なのは範囲、入力、出力条件、確認、停止条件、更新ルールです。
- 一回だけの質問や判断基準が固まっていない仕事には、作業指示書を選ばないほうがいいです。
- 別の担当者が同じファイルで再実行できるかどうかが、いちばん現実的な品質基準です。
- 向いている読者
- 同じAI支援業務を何度も回すために、長いチャット文ではなく再利用できる作業指示書へ移したい企画、運用、自動化担当者。
- テーマ
- 自動化
- 最終確認
- 2026年6月19日
- Markdown
- Codex
- Claude Code
- ChatGPT
- MCP
ワークフローの要点
このガイドを自動化フローに変えるための実用マップです。
- 01 入力
繰り返す業務、必要な入力データ、担当者、成功基準を先に決めます。
- 02 AI処理
AIは下書き、分類、要約、振り分け、ツール実行など、範囲が明確な工程に置きます。
- 03 人の確認
承認、例外処理、コスト上限、慎重な判断は人が確認できるように残します。
- 04 出力
結果をチェックリスト、保存プロンプト、SOP、監視できる自動化実行に落とし込みます。
- Markdown
- Codex
- Claude Code
- ChatGPT
- MCP
- Markdown
- AI自動化
- 作業指示書
- Codex
- Claude Code
運用メモ
ツールを先に押さず、業務に合うかを先に見る。
入力、承認点、失敗時のログが曖昧なままだと、自動化は混乱を速くするだけです。
全面自動化の前に安全に繰り返せる一歩を選びます。
長いプロンプトに依存していたAI自動化業務を、再利用できるMarkdown作業指示書へ移す考え方を示します。
5 参照した公開情報
変わりやすい機能や価格は、参照先と公式情報で確認してから判断します。
ワークフロー
大きく変える前に小さな試行を行い、確認地点が明確になってから広げます。
- 長いプロンプトでも、版管理と再利用ができなければ一回限りの依頼に近いままです。
- Markdownは、繰り返す業務、ファイルを使う業務、人の確認が必要な業務に向いています。
- 重要なのは範囲、入力、出力条件、確認、停止条件、更新ルールです。
- 一回だけの質問や判断基準が固まっていない仕事には、作業指示書を選ばないほうがいいです。
業務フロー
このガイドがつながる業務フロー
読んでいるガイドが、どの業務フローに関係するのかを確認できます。
自動化プラットフォーム、アプリビルダー、エージェントビルダー、会計ツール、汎用AIアシスタントを比較するルートです。
関連トピックを見る- 向いている場合
- 単体ツール購入、社内ワークフロー構築、広いプラットフォーム導入で迷うチーム
- 向かない場合
- 繰り返しのきっかけ、担当者、入力がまだ決まっていない場合は、自動化より先に業務の形を整える方がよいです。
実務ならまずこう判断します
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はサーバー側から再利用できる依頼形を出します。
製品機能は別ですが、方向は同じです。繰り返す仕事では、その場限りのプロンプトより再利用できる文脈が強いです。
順番はこうです。
- Markdown作業指示書を先に作る。
- AI支援で手動実行する。
- 確認と停止条件を増やす。
- 安定した部分だけエージェント指示、スキル、プロンプトテンプレートへ移す。
- 失敗率が十分に退屈になるまで人の承認を残す。
粗い状態のまま自動化しないほうがいいです。まず、人が再実行できる程度まで指示を安定させます。
採用する前に確認すること
Markdownを選ぶなら、反復価値、担当者、出力条件があるかを確認します。きちんとして見せるためのファイルは続きません。
一番早い確認は、ファイルを別の人に渡して何も説明しないことです。その人が始められ、止まる場所も分かるなら使えます。始める前に質問が五つ出るなら、まだ指示は作成者の頭の中に残っています。
これは文章力の問題ではありません。運用設計の問題です。Markdownファイルは、その問題を早めに見えるようにします。
FAQ
Markdown作業指示書はプロンプト保存と違いますか？
違います。プロンプトは依頼文を良くします。作業指示書は依頼の周りの引き継ぎを良くします。入力、出力条件、確認者、停止条件まで入ります。
すべてのAI業務に必要ですか？
不要です。一回だけの質問には重いです。反復業務、共同作業、ファイルを使う仕事、確認負荷が高い仕事に向いています。
ファイルはどこに置くべきですか？
仕事がある場所に置きます。リポジトリならAGENTS.mdや/docs/operations/が候補です。業務フォルダなら元スプレッドシートやレポートの近くがよいです。次回すぐ見つかることが大事です。
失敗した後、最初に直す場所は？
停止条件と出力条件です。私が見た失敗の多くは、AIが値を推測する、例外を飛ばす、次のシステムへ渡せない形で出す、のどれかでした。
参照した公開情報
機能、価格の文脈、比較上の判断を確認するために参照した主な公開ページです。
- OpenAI Codex AGENTS.md guide OpenAI
- OpenAI Codex Skills documentation OpenAI
- Claude Code memory documentation Anthropic
- Claude Code settings documentation Anthropic
- Model Context Protocol prompts specification Model Context Protocol
