AIの業務活用

チーム共用AI依頼文を作る:会議メモ整理基準をバージョン管理する

チーム協業AIを個人ごとの依頼文ではなく、共同でレビュー・修正するチーム資産にする方法を扱います。ハヌルチームのAI議事録整理用依頼文をv1.0からv1.1へ改善し、同じテスト入力で再確認する流れを追います。

目次を表示

対象読者複数人が同じ種類の会議メモをAIで整理しながら、出力形式とレビュー基準をそろえたい非開発者チーム

準備するもの
  • テキストを入力できる一般的なAIチャットツール
  • 実際の機密情報・顧客情報ではなく仮想データを使うこと
  • メンバーが一緒に確認できる依頼文のバージョン記録を残すこと
  • AIの結果を原文メモと人が直接照合すること

01個人の依頼文ではなくチーム共用基準にする

同じ会議メモを整理しても、メンバーごとにAIへ与える指示が違えば、結果の項目名、出典表示方法、未確定事項の扱い方が変わることがあります。この記事の目的は「よい文章」を作ることではありません。チームが繰り返し使う入力形式、期待する出力、禁止事項、レビュー方法を一つの文書にまとめ、変更理由を記録することにあります。個人用プロンプトの保管とは異なり、誰が何を変えたのかを他のメンバーが再確認できる必要があります。

仮想のハヌルチームは2026-11-14 14:00–16:00に地域住民向け「まちのデジタル基礎ワークショップ」を準備します。定員は30名で、参加費はありません。会場確定期限は2026-10-24、広報物最終版は2026-10-28、講師確定は2026-10-30です。2026-10-23時点の申込者は22名です。これらの事実はチーム共用依頼文が変わっても勝手に修正してはいけません。

共用依頼文に入れる要素チームで決める基準理由
入力形式メモ作成者と項目番号を一緒に提示出典をたどり直しやすくする
出力形式決定・タスク・未確定・衝突を分ける合意済みの内容と確認すべき内容を混ぜない
出典表示各項目末尾にメモタグを残す複数人の記録を追跡できるようにする
禁止事項担当者・期限・決定を推測しない原文にない確定を防ぐ
変更記録バージョン・日付・変更者・理由を記録共同所有文書の変更根拠を残す

02同じテスト入力を固定して比較する

バージョンを直すたびにテスト入力まで変えると、何が原因で結果が変わったのか区別しにくくなります。以下のデータは2026-10-20の会議についての3人の仮想メモです。表現が互いに異なり、広報物の日程には1人の相対的な表現が混じっています。また、チーム共用依頼文自体のバージョン記録と変更者も一緒に入力し、その後のoutputで新しい情報を作らないようにします。

入力資料
ハヌルチーム共通事実
- イベント: まちのデジタル基礎ワークショップ
- イベント日: 2026-11-14
- イベント時間: 14:00–16:00
- 定員: 30名
- 対象: 地域住民
- 参加費: なし
- 会場確定期限: 2026-10-24
- 広報物最終版期限: 2026-10-28
- 講師確定期限: 2026-10-30
- 申込状況: 2026-10-23時点22名

メンバーの役割
- ミンソ: チームリーダー・全体日程
- ジュノ: 会場・物品
- ソヨン: 広報・申込受付
- ドユン: プログラム・講師手配

テスト会議: 2026-10-20

[メモ-ミンソ-1] 会場はA案の市民センター3階セミナー室を優先して検討する。最終決定は2026-10-24までに行う。
[メモ-ミンソ-2] 広報物最終版は2026-10-28までに準備する。
[メモ-ジュノ-1] A案の市民センター3階セミナー室は収容32名、プロジェクターあり、エレベーターあり、利用可能確認済み。
[メモ-ジュノ-2] B案の区立図書館講堂は収容60名で、利用可否はまだ確認されていない。
[メモ-ソヨン-1] 広報物は会場確定後に最終修正が必要。
[メモ-ジュノ-3] 広報物は「来週中」に仕上げると聞いた。正確な日付は再確認したい。
[メモ-ドユン-1] 講師確定期限は2026-10-30である。

共用依頼文のバージョン記録
- v1.0: 2026-10-22、変更者ミンソ、最初の共用案を作成
- v1.1: 2026-10-23、変更者ソヨン、衝突項目と出典表示ルールを明記するよう修正

この入力には実際の組織情報や顧客データはありません。実際の業務で共用依頼文を作る場合も、機密、パスワード、認証情報、個人識別情報をそのまま貼り付けず、まず組織の情報保護方針を確認します。

03入力・出力・禁止事項を一つの依頼文に固定する

v1.1の要点は、より長く書くことではなく判断ルールを明記することです。特に複数人の記録が衝突したときに片方を自動選択せず、両方の記録を残したうえで「確認必要」として分けるよう求めます。また、メモにない担当者や日付をもっともらしく埋めないよう禁止します。

プロンプト
以下の複数人の会議メモをチーム共有用に整理してください。

入力ルール
- 各メモの作成者と項目番号を出典として使います。
- 共通事実と個別メモを区別します。

出力形式
1) 決定済みの内容
2) タスク
3) 未確定事項
4) 互いに衝突する、または表現が異なる記録
各項目末尾に原文の出典タグを付けます。

禁止事項
- 入力にない担当者、日付、時刻、数字、決定を作らないでください。
- 相対的な日付表現を任意のYYYY-MM-DDに変えないでください。
- 衝突する記録の一方を勝手に採用しないでください。
- 確定か不明な場合は「確認必要」と書いてください。

最後に、人が原文と照合すべき項目を短く書いてください。
バージョン変更内容レビューポイント
v1.0最初の共用案項目分類がチームで使うのに十分か確認
v1.1衝突保持・出典表示ルールを追加少数の記録や異なる表現が消えていないか確認

04よい結果は正解らしく見せるより根拠を残す

以下は実際のAI実行値ではなく、依頼文をレビューするために作った編集例です。重要なのは新しい決定を作らず、異なる記録を原文タグとともに保存することです。

結果例
[結果例 · 実際のAI出力ではありません]
共用依頼文: v1.1
変更記録: 2026-10-23、変更者ソヨン

決定済みの内容
- イベント日は2026-11-14、時間は14:00–16:00である。定員は30名である。
- 講師確定期限は2026-10-30である。[メモ-ドユン-1]

タスク
- 会場はA案の市民センター3階セミナー室を優先して検討し、2026-10-24までに最終決定する。[メモ-ミンソ-1]
- 広報物は会場確定後に最終修正が必要である。[メモ-ソヨン-1]

未確定事項
- B案の区立図書館講堂の利用可否は確認必要。[メモ-ジュノ-2]

互いに衝突する、または表現が異なる記録
- ミンソは広報物最終版期限を2026-10-28と記録した。[メモ-ミンソ-2]
- ジュノは広報物を「来週中」に仕上げると聞いたと記録し、正確な日付を再確認したいと書いた。[メモ-ジュノ-3]
- したがって広報物期限の表現は原文確認が必要であり、一方の記録を勝手に削除しない。

人が照合する項目
- ミンソとジュノの広報物期限の記録を一緒に確認する。
- ジュノのB案利用可否について、新しい確認結果が出たか確認する。

この形式はAIが会議の結論を代わりに決める仕組みではなく、メンバーがどこを確認すべきか明らかにする仕組みです。特に[メモ-ミンソ-2]と[メモ-ジュノ-3]のように表現が異なる場合、一方を削除すると確認すべき論点自体が消えてしまいます。

05共用依頼文が失敗するパターンもチームで一緒に記録する

共用依頼文を一度作って終わりにすると、繰り返し起こる誤りが残ります。チームは、どのような誤った出力が出たか、その誤りを防ぐためにどのルールを追加したかを、バージョン変更理由として残すほうがよいです。

誤った結果例
[誤りやすい結果例 · 実際のAI出力ではありません]
- 会場はB案に確定した。
- ジュノが広報物を完成させる。
- 広報物期限は2026-10-27である。
- B案は利用可能である。

この例は入力にない決定を作り、広報担当ではないジュノに新しい業務を割り当て、提示されていない日付とB案の利用可否を確定しました。修正方法は文章を滑らかにすることではなく、依頼文に「推測禁止」「衝突保持」「出典タグ維持」のルールを加え、同じテスト入力で再確認することです。

確認リスト
共用依頼文レビュー一覧
- 入力形式に作成者と原文項目番号が残っているか
- 決定・タスク・未確定・衝突が区別されているか
- 入力にない担当者・日付・時刻・数字を作らないよう禁止しているか
- 異なる記録を一方へ統合してしまっていないか
- 変更バージョン・日付・変更者・理由をメンバーが確認できるか
- 実際の業務データを入れる前に組織の情報保護方針を確認したか

06バージョン変更は同じ入力で再レビューする

チーム共用プロンプトは完成品というより、小さな運用ルールに近いものです。新しいバージョンを作るときは、変更者が理由を記録し、別のメンバーが同じテスト入力で結果形式と漏れの有無を確認してから共有します。特定のAI製品の設定に依存するより、入力と出力のルールをテキストで残しておけば、ツールが変わってもチームのレビュー基準を維持しやすくなります。

  • 依頼文を直した人とレビューした人が、何が変わったかを一緒に読む。
  • テスト入力はそのままにし、決定・タスク・未確定・衝突の分類が維持されているかを見る。
  • 新しいバージョンで出典タグが抜けたり、未確認情報が確定へ変わったりしていないか確認する。
  • チームが実際に使うと決めたバージョンだけを共用場所に明確に表示する。

次の記事「AIの結果をチームでレビュー・承認する方法:週次レポート共有前のチェック」では、共用依頼文で作った結果でも、共有前に事実、漏れ、機密情報、担当者、最終承認状態をどのように分けて確認するかを扱います。

自分で確認する項目

仮想入力データと編集例 · 実際のAI実行なし · 名前・日付・数値の一致検査

  • すべてのcodeブロックにinput・prompt・output・bad_output・checklistのいずれかのroleがあることを確認
  • outputの人名・YYYY-MM-DD日付・HH:MM時刻・数字が同じ記事のinputに存在するか確認
  • v1.0とv1.1の変更記録が、入力データにあるバージョン・日付・変更者と一致するか確認
  • 衝突する広報物期限の記録がoutputで一方に勝手に統合されていないか確認
  • 会場・イベント日程・定員・主要期限・申込状況がシリーズ共通事実と矛盾していないか確認
  • 時間削減率や生産性向上率などの効果数値を使っていないか確認
検証範囲の限界

実際のAIツールで実行した結果ではなく、チーム協業AIの使い方を説明するために作った仮想入力と編集例です。実際のチームデータには機密情報・個人情報が含まれる可能性があるため、入力前に組織の情報保護方針と原文の公開範囲を確認する必要があります。