【超実用的】マジで雑なメモも完璧な報告文にするAIプロンプト集
はじめに
「splunk やった」「バグ直した」「api なんか動かん」...こんな殴り書きメモしかない時、ありますよね？
この記事では、どんなに雑なメモでもそれっぽい報告文に変換するプロンプトテクニックを紹介します。
パターン1: 超シンプルな単語メモ
入力例（本当に雑）
ログイン
バグ
直した
テスト
API
最強プロンプト
以下の断片的なメモから、作業報告を作成してください。
【ルール】
1. 単語だけのメモから文脈を推測して自然な文章にする
2. 推測が入る部分は控えめに表現する
3. 不明な部分は「確認中」「作業中」等でぼかす
4. 完了/実施中/予定を自然に分類
5. ●マーカー使用、絵文字不要
6. です・ます調
7. 短めに
【メモ】
ログイン
バグ
直した
テスト
API
【補足情報（あれば）】
なし
出力例
本日の作業報告です。
■ 完了
● ログイン機能のバグ修正
■ 実施中
● テストの実施
● API関連の作業
以上です。
パターン2: 時系列メモ（箇条書き）
入力例
10:00 ログインバグ調査
11:30 原因特定、セッション管理
13:00 修正
14:00 テスト開始
15:30 レビュー依頼
まだ終わってない
プロンプト
以下の時系列メモを作業報告にまとめてください。
【ルール】
1. 時刻情報は削除
2. 作業の流れを自然な文章に
3. 完了と未完了を区別
4. 簡潔に
5. ●マーカーのみ
【メモ】
10:00 ログインバグ調査
11:30 原因特定、セッション管理
13:00 修正
14:00 テスト開始
15:30 レビュー依頼
まだ終わってない
出力例
本日の作業報告です。
■ 完了
● ログインバグの調査と原因特定
- セッション管理の問題でした
● バグの修正
■ 実施中
● テストの実施
● レビュー待ち
以上です。
パターン3: 混沌としたメモ
入力例（マジで雑）
splunk ダッシュボード
spl書いた
index=security とか
グラフ出た
アラート TODO
ドキュメント？
明日やる
エラー出てたけど直った
パフォーマンス遅い気がする
万能プロンプト
以下の非常に断片的なメモを、読みやすい作業報告にしてください。
【重要なルール】
1. メモの順番は無視して、内容で整理
2. 完了/実施中/TODO/問題点 に自動分類
3. 技術用語はそのまま使用
4. 曖昧な表現（「気がする」等）は「要確認」等に変換
5. 短く簡潔に
6. ●のみ、絵文字不要
【メモ】
splunk ダッシュボード
spl書いた
index=security とか
グラフ出た
アラート TODO
ドキュメント？
明日やる
エラー出てたけど直った
パフォーマンス遅い気がする
【出力フォーマット】
■ 完了
■ 実施中
■ 今後の予定
■ 懸念事項
出力例
Splunkダッシュボードの作業報告です。
■ 完了
● SPLクエリの作成
- index=securityを使用
● グラフの表示確認
● エラーの修正
■ 今後の予定
● アラート設定
● ドキュメント作成
- 明日実施予定
■ 懸念事項
● パフォーマンスについて要確認
以上です。
パターン4: チャット履歴・会話メモ
入力例
A: ログインエラー出てる
B: DB見て
A: コネクション切れてた
A: 再起動した
B: 直った？
A: うん
B: じゃあドキュメント更新して
A: まだ
プロンプト
以下の会話ログから作業報告を作成してください。
【ルール】
1. 会話形式を報告文に変換
2. 誰が言ったかは不要
3. 事実だけを抽出
4. 時系列を整理
5. シンプルに
【会話ログ】
A: ログインエラー出てる
B: DB見て
A: コネクション切れてた
A: 再起動した
B: 直った？
A: うん
B: じゃあドキュメント更新して
A: まだ
出力例
ログインエラー対応の報告です。
■ 完了
● 問題の調査
- DBコネクション切断が原因でした
● 応急対応
- DBを再起動し、復旧しました
■ 未完了
● ドキュメントの更新
以上です。
パターン5: コード・ログ混在メモ
入力例
エラーログ:
ERROR: Connection timeout
原因調べた
config.timeout=30だった
60に変更
retry_count=3も追加
テストした
OK
プロンプト
以下のエラーログと作業メモから報告文を作成してください。
【ルール】
1. エラーログは整形して引用
2. 原因と対応を明確に
3. 設定値は正確に記載
4. コードブロック使用
5. 簡潔に
【メモ】
エラーログ:
ERROR: Connection timeout
原因調べた
config.timeout=30だった
60に変更
retry_count=3も追加
テストした
OK
出力例
タイムアウトエラーの対応報告です。
■ 発生した問題
ERROR: Connection timeout
■ 原因
タイムアウト設定が短すぎました（30秒）
■ 実施した対応
設定を以下のように変更しました:
- timeout: 30秒 → 60秒
- retry_count: 0 → 3
■ 結果
テストを実施し、問題が解決したことを確認しました。
以上です。
パターン6: 英語メモ混在
入力例
login bug fixed
API integration WIP
need to check performance
docs 明日
deploy Friday
プロンプト
以下の英語・日本語混在メモを日本語報告文にしてください。
【ルール】
1. 全て自然な日本語に
2. 技術用語は適宜英語のまま
3. 完了/実施中/予定を分類
4. 簡潔に
【メモ】
login bug fixed
API integration WIP
need to check performance
docs 明日
deploy Friday
出力例
本日の作業報告です。
■ 完了
● ログインのバグ修正
■ 実施中
● API統合作業
■ 要確認事項
● パフォーマンスの確認が必要です
■ 今後の予定
● ドキュメント作成（明日）
● デプロイ（金曜日）
以上です。
パターン7: 超短文メモ
入力例
やった:
- バグ
- テスト
- レビュー
TODO:
- deploy
- docs
プロンプト
以下の極めて簡潔なメモを報告文にしてください。
【ルール】
1. 各項目に具体性を少し追加
2. 完了とTODOを明確に区別
3. 自然な文章に
4. 短く
【メモ】
やった:
- バグ
- テスト
- レビュー
TODO:
- deploy
- docs
出力例
本日の作業報告です。
■ 完了
● バグ修正
● テストの実施
● レビュー対応
■ 今後の予定
● デプロイ作業
● ドキュメント作成
以上です。
【最強】どんな雑メモでも対応する汎用プロンプト
以下のメモを作業報告にしてください。
メモがどんなに雑でも、読みやすい報告文にしてください。
【絶対守るルール】
1. メモに書いていないことは推測で追加しない
2. 不明な点は「確認中」「作業中」等でぼかす
3. 完了/実施中/未着手/問題点 を自動判別して分類
4. 技術用語はそのまま使用
5. です・ます調
6. ●マーカーのみ使用、絵文字は一切使わない
7. 1項目1-2行程度
8. 英語が混在していても自然な日本語に
9. 時刻情報は削除
10. 全体で10行以内に収める
【メモの特徴を自動判別】
- 単語の羅列 → 文章化
- 時系列メモ → ストーリーに整理
- 会話形式 → 報告形式に変換
- コード/ログ混在 → 適切にフォーマット
【必ず使う構造】
■ 完了
（完了した作業）
■ 実施中
（進行中の作業）
■ 今後の予定
（TODO）
■ 懸念事項・確認事項
（問題や不明点があれば）
以上です。
【メモ】
[ここに雑なメモを貼り付け]
実践例：本当に雑なメモで試す
例1: 殴り書き
【メモ】
ログイン直した
api動かん
db遅い
明日見る
テストやった
出力:
本日の作業報告です。
■ 完了
● ログイン機能の修正
● テストの実施
■ 今後の予定
● API動作確認（明日実施）
● DBパフォーマンス調査（明日実施）
以上です。
例2: メモアプリのコピペ
【メモ】
9:30 出社
ログイン調査
セッションがおかしい
redis見た
11:00 修正開始
expires設定ミス
直した
14:00 テスト
OK
レビュー待ち
ドキュメントまだ
出力:
ログイン機能の修正報告です。
■ 完了
● 問題の調査
- セッション管理の不具合を特定しました
- Redisのexpires設定が誤っていました
● 修正の実施
● テスト完了
■ 実施中
● レビュー待ち
■ 未完了
● ドキュメント更新
以上です。
例3: Slack自分用メモのコピペ
【メモ】
@self
splunkやった
indexとsourcetype設定
SPL: index=security action=failure | stats count by user
グラフ出た！
でもパフォーマンス悪い気がする
データモデル使ったほうがいい？
アラートは明日
出力:
Splunk設定作業の報告です。
■ 完了
● インデックスとソースタイプの設定
● SPLクエリの作成と動作確認
- 失敗ログイン数をユーザー別に集計
● グラフ表示の実装
■ 今後の予定
● アラート設定（明日実施）
■ 確認事項
● パフォーマンス改善について検討が必要です
- データモデルの活用を検討中
以上です。
応用テクニック
テク1: メモの粒度を指定
【条件に追加】
メモの粒度: [詳細/標準/簡潔]
詳細: 各作業の背景や理由も含める
標準: 作業内容のみ
簡潔: 完了/未完了の事実のみ
テク2: 対象読者を指定
【条件に追加】
対象読者: [マネージャー/チームメンバー/自分用メモ]
マネージャー: ビジネスインパクト重視
チームメンバー: 技術詳細含む
自分用メモ: 箇条書きでOK
テク3: トーン指定
【条件に追加】
トーン: [フォーマル/標準/カジュアル]
フォーマル: 丁寧語多め
標準: です・ます
カジュアル: 口語的
よくある失敗と対処法
失敗1: 勝手に盛られる
問題:
メモ: 「バグ直した」
出力: 「重大なセキュリティバグを特定し、迅速に修正を実施しました」
対処:
【条件に追加】
- メモに書かれていない情報（重大、迅速等）は追加しない
- 事実のみを淡々と記載
失敗2: 専門用語が変換される
問題:
メモ: 「SPL書いた」
出力: 「検索処理言語を記述しました」
対処:
【条件に追加】
- 技術用語は元の表記のまま使用
- 略語を勝手に展開しない
失敗3: 構造が複雑すぎる
問題:
サブセクションが多すぎて読みにくい
対処:
【条件に追加】
- セクションは最大4つまで（完了/実施中/予定/懸念）
- 各セクション内の階層は1段まで
コピペ用：究極のテンプレート
以下の雑なメモを報告文にしてください。
【絶対ルール】
・完了/実施中/予定/懸念 に分類
・●のみ、絵文字不要
・です・ます調
・各項目1-2行
・全体10行以内
・メモにない情報は追加しない
・技術用語はそのまま
・時刻は削除
【メモ】
[貼り付け]
番外編：もっと極端な例
スクショのOCRテキスト
【メモ】
L o g i n
b u g
f i x e d
このような認識ミスだらけでも:
本日の作業報告です。
■ 完了
● ログインのバグ修正
以上です。
スマホ音声入力の失敗
【メモ】
ろぐいんバグなをした
API統合てす中
どきゅめんとあした
これも:
本日の作業報告です。
■ 完了
● ログインのバグ修正
■ 実施中
● API統合テスト
■ 明日の予定
● ドキュメント作成
以上です。
まとめ
雑メモを報告文にする3原則
-
メモの形式を気にしない
- 単語でも、時系列でも、会話でもOK
-
AIに分類を任せる
- 完了/実施中を自動判別させる
-
シンプルな構造を指定
- 複雑な報告は不要、事実だけ
プロンプトの黄金比
条件: 30%（ルール定義）
構造: 20%（出力フォーマット）
メモ: 50%（実際の内容）
このテンプレートがあれば、どんなに雑なメモでも5秒で報告文が完成します。
もう「報告文書くの面倒」とは言わせません！