個人のプロンプトを共有しただけでは、担当者が変わったときに同じ品質で使えるとは限りません。入力資料、実行手順、確認基準、例外時の戻し方を一緒に残します。この記事でいうskillsは、業務手順を再利用できる形にまとめる考え方です。
指示文と業務の手順書を一緒に管理する

ツール固有のファイル形式だけを揃える前に、何を入力し、何を確認して完成とするかを明確にします。実行環境による違いも記録します。
| 項目 | 確認・実施する内容 |
|---|---|
| 目的 | 対象業務、利用者、完成後の用途。 |
| 入力 | 必要な資料、入力様式、使えない情報。 |
| 手順 | 実施する順序、参照先、必要な承認。 |
| 完成条件 | 事実、形式、根拠、公開範囲の確認基準。 |
Claude CodeやCodexなど、利用環境固有の仕様を使う場合は、その時点の公式説明を確認します。本記事では共通して整理できる運用要件を扱い、特定環境の形式を一律の仕様として説明しません。
記事やSNSの制作へ手順を応用するには、記事・SNS制作にAIを導入する前に決めたい品質基準と確認工程をご覧ください。
例外と確認の手順まで書く

通常の入力だけで動作する手順では、材料不足や仕様変更に弱くなります。わからないときに何を確認し、どこで止めるかを決めます。
| 項目 | 確認・実施する内容 |
|---|---|
| 不足 | 資料や条件が足りない場合は、推測せず確認事項を返す。 |
| 矛盾 | 資料間で内容が異なる場合は、基準資料と確認担当へ戻す。 |
| 重要操作 | 送信、公開、削除、権限変更等は必要な承認を確認する。 |
| 失敗 | 再実行の前に現在の状態を確認し、二重実行を防ぐ。 |
「自動で完了」とだけ書かず、どの操作が対象なのかを具体化します。担当者が同じ場面で同じ判断をできるようにすることが目的です。
引き継ぎ用プロンプトのひな型
以下は説明用のひな型です。自社の対象・資料・確認体制に合わせて書き換えて使います。
目的:渡された資料から、指定した業務に使うたたき台を作成する。 入力:対象業務、利用者、資料、出力の用途、公開・入力できる範囲。 参照:提供資料に書かれた事実と、提案する内容を区別する。 出力:要点/根拠となる資料と箇所/未確認事項/人が確認する項目。 不明時:資料にない数値・仕様・予定・実績は推測で補わず、確認が必要と示す。 実行の境界:送信・公開・データ変更は実行せず、担当者の確認用に出力する。 更新時:版、変更理由、確認に使った入力例と結果を残す。
確認する手順や条件は、AI研修を受けても業務で使われない理由と定着の進め方も参考になります。
版と検証用の入力を残して更新する

手順は一度作って終わりではありません。ツール、資料、業務の変更に合わせて更新できるように管理します。
| 項目 | 確認・実施する内容 |
|---|---|
| 版管理 | 変更日、変更内容、担当、利用する環境を記録する。 |
| 確認用入力 | 通常、条件不足、例外を含む入力例を用意する。 |
| 確認結果 | 採用した出力と、修正・停止が必要だった内容を残す。 |
| 引き継ぎ | 新しい担当者が資料から実行・確認できるかを試す。 |
手順の検証を、見本と同じ文章が出たかだけに限定しません。必要な事項、禁止事項、根拠、操作の安全性を確認します。

自社のサイト・業務への当てはめに迷ったら、AI導入・業務活用を相談するからご相談いただけます。
よくある質問

依頼や社内での実施を検討するときに確認したい点です。
| 項目 | 確認・実施する内容 |
|---|---|
| 良いプロンプトを一つ作れば十分ですか? | 資料、利用条件、確認工程も必要です。目的や対象業務が違えば、指示文をそのまま使えない場合があります。 |
| ツールを変更しても同じように使えますか? | 共通の業務要件は引き継げますが、仕様や権限、出力の違いを確認し、再検証します。 |
個別の条件は、対象業務と資料を確認してから判断します。
相談前に整理すること

指示文に、入力・完成条件・例外・承認・更新の情報を添えてください。担当が変わっても利用と確認ができるかを試しましょう。
| 項目 | 確認・実施する内容 |
|---|---|
| 対象 | 対象サイトや業務と、困っていることを共有する。 |
| 材料 | 利用できる資料と、公開・入力できる範囲を整理する。 |
| 分担 | 社内で担当できる作業と、依頼したい作業を分ける。 |
CommunityCreateでは、必要な調査・制作・実装・運用の範囲を整理してご提案します。


