仕事を引き取るAIの同僚-第7回:「調べてまとめる同僚」を“業務仕様書”として作る
公開日
2026年2月18日
更新日
2026年4月26日
この記事の主な内容
この記事のポイント
・AIの同僚を 組織の資産 として引き継ぐための「業務仕様書」の書き方
・属人化を防ぐ 10項目のテンプレート(コピペ可)
・運用でぶれない バージョン管理・評価指標 の作り方
・シリーズ全7回の学びを 組織展開するロードマップ
なぜ「業務仕様書」が必要なのか
個人のAI活用から組織のAI活用へスケールさせると、必ず問題になるのが 属人化 です。
・担当者が異動したら誰も使い方が分からない
・プロンプトが散在していて引き継げない
・同じような同僚を別部署で重複構築している
・精度が落ちても「なぜ落ちたか」が追えない
これを防ぐには、AIの同僚を 一般業務と同じように設計図=業務仕様書として残す 必要があります。
業務仕様書テンプレート 10項目
| 項目 | 記入内容 | 例 |
|---|---|---|
| 1. 業務名 | AIの同僚の役割名 | 競合調査ボット |
| 2. 目的 | 何を達成するか | 競合3社の月次動向を週1で共有 |
| 3. 利用者 | 誰が使うか | マーケティング部 5名 |
| 4. 入力仕様 | 何を受け取るか(型・例) | 会社名・調査項目(自然言語) |
| 5. 出力仕様 | 何を返すか(型・フォーマット) | A4一枚・見出し+箇条書き |
| 6. 使用モデル | どのAIを使うか | Claude Sonnet 4 / GPT-4o |
| 7. システムプロンプト | 全文(変更履歴付き) | 別紙参照 |
| 8. ナレッジベース | 参照資料・更新頻度 | 公開IR資料+社内競合DB/月次更新 |
| 9. 評価指標 | 精度・満足度をどう測るか | 利用者アンケート、回答引用率 |
| 10. エスカレ条件 | 人間に繋ぐ基準 | 出典不明・判断が分かれる案件 |
システムプロンプトはバージョン管理する
システムプロンプトは コードと同じくバージョン管理 すべきです。推奨はGitリポジトリ、もしくはNotionページでの履歴管理。変更時には必ず記録します。
| バージョン | 日付 | 変更内容 | 変更者 | 影響範囲 |
|---|---|---|---|---|
| v1.0 | 2026-02-01 | 初版 | 岡崎 | 新規 |
| v1.1 | 2026-02-15 | 出典明記の指示を追加 | 岡崎 | 出力末尾 |
| v1.2 | 2026-03-01 | エスカレ条件の明確化 | 田中 | 判断分岐 |
これにより「昨日まで動いていたのに精度が落ちた」という問題を 原因まで追跡 できます。
評価指標は「定量+定性」で
| 種類 | 計測頻度 | 指標 |
|---|---|---|
| 定量 | 月次 | 利用回数/利用者数/回答生成時間/エスカレ率/出典引用率 |
| 定性 | 四半期 | 5段階の満足度/「このボットがなくなったら困るか」(Yes/No)/改善要望の自由記述 |
定量で異常を検知し、定性で方向性を決める のが基本です。
組織展開ロードマップ(90日プラン)
| フェーズ | 期間 | やること | 成果物 |
|---|---|---|---|
| Phase 1:パイロット | Day 1〜30 | 1部署・1ユースケースで構築 | 業務仕様書 v1.0、利用ログ |
| Phase 2:横展開 | Day 31〜60 | 隣接部署で類似ケース展開 | 仕様書 v2.0、ベストプラクティス集 |
| Phase 3:標準化 | Day 61〜90 | 社内ガイドライン・研修整備 | 標準テンプレ、社内研修資料 |
失敗しがちな3つの罠
| 罠 | 結果 | 対策 |
|---|---|---|
| ① 業務仕様書を作らず口伝で運用 | 担当者が離れた瞬間に使えなくなる | 初日から仕様書を作る |
| ② プロンプトを管理しない | 気づけば複数バージョンが混在、誰が書いたか不明に | Git/Notionで必ずバージョン管理 |
| ③ 評価指標を定めない | 「なんとなく使われてる」で終わり、効果が可視化されない | 月次で数字を出す運用を最初から組み込む |
シリーズ全7回の学びを組織に展開する5ステップ
1. 第1回の「同僚マインドセット」を組織共通言語にする
2. 第2〜5回のユースケースから自部署に合うものを選ぶ
3. 第6回のDifyで最初の1体を作る
4. 第7回の業務仕様書でドキュメント化して引き継ぎ可能に
5. 月次レビューと横展開で組織全体の資産に育てる
明日からできる3つのアクション
① 動いているAI同僚(プロンプト等)を「業務仕様書テンプレ10項目」で書き起こす
30分でテンプレを埋めれば、属人化リスクが大幅に下がります。
② プロンプトをNotion/Gitに保存しバージョン管理を始める
最初は1つのプロンプトでもOK。「変更履歴を残す」習慣がスケール時の保険になります。
③ 月次レビューの定例を作る
毎月1回30分、利用ログと改善要望を確認する場を設ける。これだけで品質が安定します。
シリーズの振り返り
| 回 | テーマ |
|---|---|
| 第1回 | AIはツールではなく、”同僚”として考える |
| 第2回 | 調べて・まとめて・報告するだけの仕事を引き取らせる |
| 第3回 | 毎回ゼロから考える文章を先に書かせる |
| 第4回 | 「またその質問?」を言わなくてよくなる任せ方 |
| 第5回 | 考え始める前が一番しんどい仕事を整えてもらう |
| 第6回 | Difyで仕事を任せる仕組みを作る |
| 第7回 | 「調べてまとめる同僚」を業務仕様書として作る |
連載の終わりに:AIの同僚は退職しない
全7回を通じて、個人の「AI活用」から組織の「AI戦力化」への道筋を示してきました。業務仕様書がある限り、AIの同僚は退職せず、異動せず、24時間365日、組織のために働き続けます。
最初の1体から始めて、3か月後には組織の資産に育っているはずです。
<文/岡崎 凌>
新着記事
同じカテゴリーの新着記事
同じカテゴリーの人気記事
この記事に関連する教室: 統計・データ分析教室 → 社会人の学び直し講座 →





