logo

鎌イルカのクラフト記

article icon

AIが「また同じこと聞いてくる」のは、あなたのせいじゃない

AIが「また同じこと聞いてくる」のは、あなたのせいじゃない

前回の記事では、AIとうまく付き合うための「伝え方」についてお話ししました。What(何を)/ Why(なぜ)/ 完了条件——この3つを伝えれば、AIの出力は格段によくなる、と。

でも、実際にAIを使い込んでいくと、「伝え方」だけでは解決できない壁にぶつかります。

たとえば、こんな場面を想像してみてください。

あなたはAIと一緒にプロジェクトの企画書を作っている。最初に「予算は300万円以内」「ターゲットは20代女性」「納期は6月末」と丁寧に伝えた。AIは完璧な初稿を返してくれた。翌日、続きをやろうとチャットを開いたら——AIは昨日の会話を何も覚えていなかった。

「え、昨日あんなに話したのに?」

そうなんです。AIは覚えてくれません。 そして、これはAIの「バグ」ではなく「仕様」です。

前回の記事で「AIは超優秀だけど記憶喪失の新人」と書きました。あの比喩、実は今回の本題に直結しています。記憶喪失の相手と仕事をするなら、何が必要でしょうか?

答えはシンプルです。メモです。

この記事では、AIとの仕事を「一発の会話」で終わらせず、積み重ねていくための方法をお伝えします。難しいツールの話ではありません。メモ帳ひとつでできることです。


第1章:AIは覚えてくれない

3つの「忘れる」を知っておく

AIが「忘れる」タイミングは、大きく3つあります。

① チャットが長くなると忘れる

前回の記事でも触れましたが、AIとのやりとりが長くなると、最初のほうで伝えた情報が抜け落ちていきます。これはAIが処理できる情報量(コンテキストウィンドウと呼ばれます)に限りがあるためです。

あなた:「この企画書、冒頭で説明した3つのKPIに沿って修正して」 AI:「承知しました。KPIについて改めて教えていただけますか?」

——さっき説明したじゃん!

人間同士なら「さっき言ったでしょ?」で済みますが、AIにその「さっき」はもう存在しない可能性があります。

② セッションが切れると全部消える

ブラウザを閉じた、アプリを再起動した、翌日改めてアクセスした——多くのAIサービスでは、セッションが切れると会話の文脈がリセットされます。昨日1時間かけて共有した前提条件は、きれいさっぱり消えています。

③ 別のチャットには持ち越せない

「営業チームの課題について話したチャット」と「新しい施策のアイデアを出したチャット」は、AIの中では完全に別世界です。あなたの頭の中ではつながっていても、AIにとっては何の関係もない別の会話です。

「さっき言ったじゃん!」が通じない相手

人間の同僚なら、たとえ詳細を忘れても「ああ、あの件ね」くらいの文脈は残っています。共有の経験があるからです。

でもAIには、あなたとの共有体験がありません。 前回のチャットでどれだけ深い議論をしても、セッションが切れれば初対面に戻ります。毎回「はじめまして」からやり直し。

これ、冷静に考えるとかなり非効率ですよね。毎回同じ前提を説明し直す。毎回同じ注意事項を伝え直す。毎回同じフォーマットを指定し直す。

人間なら「引き継ぎメモ」を書く

新人に仕事を引き継ぐとき、あなたはどうしますか? 口頭で全部伝えて「じゃ、あとはよろしく」とはしないでしょう。引き継ぎ資料を作りますよね。

  • この業務の目的はこれ
  • 関係者はこの人たち
  • 注意すべきポイントはここ
  • 過去にこんなトラブルがあった

AIも同じです。毎回記憶を失う相手には、読めば状況が分かるメモを渡してあげればいいのです。


第2章:「メモ」がないとどうなるか

毎回ゼロから説明する非効率

プログラミングをしない方にも、こんな経験はないでしょうか。

メールの場合:

取引先への定例報告メール。毎月AIに書いてもらっているけど、毎回「相手は〇〇社の田中部長で、プロジェクトの進捗を報告するメールで、トーンはフォーマルだけど堅すぎず…」と1から説明している。先月と同じことを言ってるのに。

議事録の場合:

週次ミーティングの議事録。毎回「参加者はこの5人で、フォーマットは決定事項・アクションアイテム・次回議題の3部構成で…」と指定している。先週と同じフォーマットなのに、AIは知らない。

企画書の場合:

社内提案用の企画書テンプレート。AIに「うちの会社のフォーマットはこうで、承認フローはこうで…」と毎回説明している。もう5回目なのに。

どれも共通しているのは、「AIが前回のやりとりを覚えていれば不要な説明」を、毎回繰り返しているということです。

プログラミングに限った話だと思いましたか? 実は日常の業務でも、まったく同じことが起きています。AIが前回の前提を持ち越せない限り、仕事の種類が違ってもつまずく場所は同じです。

エンジニアの世界でも同じことが起きる

最近、エンジニアの間で「バイブコーディング」という言葉が話題になっています。AIに「なんかいい感じに作って」とノリで指示を出し、出てきたコードをそのまま使うスタイルのことです。

初速はすごいです。ものの数分で、それらしい画面やプログラムができあがる。

でも、これが破綻するのは3回目くらいの変更からです。

1回目:「ログイン機能を作って」→ 動いた!

3回目:「パスワードリセット機能を追加して」→ ログイン機能が壊れた

なぜ壊れるのか? AIは途中までの経緯や設計意図を正確には覚えていないからです。「たぶんこういう構造だろう」と推測して新しいコードを書くので、既存の仕組みと矛盾が生じる。

基盤なしにAIを走らせると何が起きるか

前回の記事で、AIのハルシネーション(もっともらしい嘘)について書きました。実は、ハルシネーションが起きやすい状況には共通点があります。

AIに渡す情報が少ないほど、ハルシネーションは増えます。

考えてみれば当然です。AIは手持ちの情報から「最もありそうな答え」を推測して返します。手持ちの情報が少なければ、推測に頼る割合が大きくなり、的外れな回答(=ハルシネーション)が増える。

つまり、メモを渡さずにAIを使うということは、ハルシネーションの確率を自分で上げているようなものです。


第3章:AIに渡すメモの書き方

「自分が何をしたいか」を明確にするのは人間の仕事

前回の記事で「What / Why / 完了条件」の3つを伝えましょうと書きました。メモは、この考え方を**「使い回せる形」**にしたものです。

毎回のチャットでゼロから伝える代わりに、メモとして書き出しておけば、コピペするだけで済みます。

AIが読めるメモとは?

AIに渡すメモは、人間向けの美しいドキュメントである必要はありません。AIが正確に理解できる形式であればOKです。ポイントは3つ。

① 箇条書きにする

長い文章より、箇条書きのほうがAIは正確に読み取れます。

長文で書いた場合

「このプロジェクトは〇〇社向けの提案で、予算は500万円以内に収める必要があり、ターゲットは30代の管理職層で、納期は来月末で、前回の提案ではデザインが地味だと言われたので今回はもう少しビジュアルに力を入れたいと思っています」

箇条書きの場合

  • クライアント: 〇〇社
  • 予算: 500万円以内
  • ターゲット: 30代管理職
  • 納期: 来月末
  • 前回のフィードバック: デザインが地味→ビジュアル強化

同じ情報量ですが、箇条書きのほうが圧倒的に読みやすく、AIが見落とす確率も下がります。

② 前提条件を明記する

「当然分かっているだろう」は通用しません。AIは何も知らない前提で書きましょう。

以下をメモ帳やNotionにコピーして使ってください。

前提条件
- 社内向け資料(社外に出さない)
- 読者はITに詳しくない経営層
- グラフはExcelで作成済み(添付データを参照)
- 過去の類似報告書のフォーマットに合わせる

③ 完了条件を具体的に書く

「いい感じに」ではなく、何をもって完了とするかを書きます。

以下をメモ帳やNotionにコピーして使ってください。

完了条件
- A4で3枚以内
- 見出しは3階層まで
- 結論を最初に書く
- 専門用語は使わない(使う場合は括弧内に説明)

具体例:メール返信のテンプレ化

たとえば、取引先への定例報告メールを毎月AIに書いてもらう場合、こんなメモを用意しておきます。

以下をメモ帳やNotionにコピーして使ってください。

メール定型情報
- 宛先: 〇〇社 △△部長
- 用件: 月次プロジェクト進捗報告
- トーン: フォーマルだが堅すぎない。「いつもお世話になっております」で始める
- 構成: ①全体サマリ(3行)②進捗詳細 ③課題と対応策 ④来月の予定
- 注意: 具体的な金額は記載しない(口頭で伝える)

次回からは、このメモをチャットの冒頭に貼って「今月の進捗はこちらです:(データ)」と追記するだけ。毎回1から説明する手間がなくなります。

プロジェクトの「読めば分かるメモ」

もう少し大きな単位、たとえばプロジェクト全体のメモはこんな形になります。

以下をメモ帳やNotionにコピーして使ってください。

プロジェクト概要
- プロジェクト名: 社内研修プログラム刷新
- 目的: 新人の早期戦力化(現状6ヶ月→3ヶ月が目標)
- 期間: 2026年4月〜9月
- 予算: 200万円
- 関係者: 人事部(主管)、各部門マネージャー、外部講師
 
制約条件
- 既存のeラーニングシステムを活用(新規システム導入なし)
- 研修時間は業務時間の20%以内
- 9月の新人配属に間に合わせる
 
決定事項(随時更新)
- 4/5: 研修は3フェーズ構成(基礎→部門別→OJT)に決定
- 4/7: 基礎フェーズの教材はAIで作成する方針に決定
 
未決事項
- 外部講師の選定(候補3名、来週中に決定)
- 効果測定の指標(人事部と要相談)

このメモがあれば、新しいチャットを開いても「このプロジェクトについて、次のタスクをお願いします」と言うだけで、AIは文脈を理解して作業を始められます。

前回記事の「What / Why / 完了条件」の発展形

前回の記事で紹介した3要素は、1回のやりとりのための指示でした。メモは、それを蓄積可能な資産に変えるものです。

前回の記事(1回限り)今回の記事(蓄積型)
毎回Whatを口頭で伝えるWhatをメモに書いておく
毎回Whyを説明するWhyはプロジェクト概要に記載済み
毎回完了条件を指定する完了条件はテンプレに固定済み

1回の指示を磨くのが「伝え方」。使い回せる形にするのが「メモ」。 この2つが揃って初めて、AIとの仕事は「積み重ね」になります。


第4章:メモが変わったらどうする?

仕様は必ず変わる

ここまで読んで「よし、メモを作ろう!」と思った方。素晴らしいです。でも、もうひとつだけ知っておいてほしいことがあります。

メモは、必ず古くなります。

プロジェクトの予算が変わった。納期が前倒しになった。ターゲットが変更になった。仕事をしている以上、前提条件は常に動きます。

メモが古いまま放置されると何が起きるか? AIは古いメモを「正しい前提」として処理します。 予算が300万に増えたのに、メモに「200万以内」と書いてあったら、AIは200万の前提で企画書を作ります。人間なら「あれ、予算変わったんじゃなかったっけ?」と気づくかもしれませんが、AIはメモに書いてあることを忠実に信じます。

「変更の波紋」という考え方

ひとつの前提が変わると、それに依存していた他のすべてが影響を受けます。これを**「変更の波紋」**と呼びます。

たとえば、「納期が1ヶ月前倒し」になったとしましょう。

納期前倒し
 ├→ スケジュールの修正が必要
 │ ├→ 各フェーズの期間を短縮
 │ └→ マイルストーンの日付変更
 ├→ リソース配分の見直し
 │ ├→ 追加の人員が必要?
 │ └→ 外注の検討
 ├→ 品質基準の再検討
 │ └→ どこを削るか?
 └→ 関係者への連絡
   └→ クライアントとの調整

ひとつの変更が、芋づる式に他の要素に波及していく。これはプログラミングでも、業務でも、どんな分野でも同じです。

メモを更新するときの3ステップ

変更が生じたとき、メモをどう更新すればいいか。シンプルな3ステップです。

Step 1:何が変わったかを明記する

メモの該当箇所を直接修正するだけでなく、「変更履歴」として残すのがおすすめです。

以下をメモ帳やNotionにコピーして使ってください。

変更履歴
- 4/10: 納期を6月末→5月末に前倒し(クライアント要望)
- 4/12: 予算200万→300万に増額(前倒し対応の追加コスト承認済み)

Step 2:影響範囲を洗い出す

変更の波紋がどこまで及ぶか、箇条書きで書き出します。ここでAIを活用するのも効果的です。「この変更が他のどこに影響するか、メモの内容をもとに洗い出して」と聞けば、AIは見落としがちな依存関係も指摘してくれます。

Step 3:影響を受けた箇所を更新する

洗い出した影響範囲に基づいて、メモの関連箇所を更新します。

たとえば、第3章のプロジェクトメモで予算が変わったなら、更新はこんな短い差分で十分です。

Before: 「- 予算: 200万円」

After: 「- 予算: 300万円」 「- 4/12: 予算200万→300万に増額(追加コスト承認済み)」

ここで重要なのは、Step 2を飛ばさないことです。変更箇所だけ直して「はい、更新完了」とすると、関連する他の記述が古いまま残り、メモの中で矛盾が生じます。AIはその矛盾に気づかず、どちらか一方を勝手に採用して作業を進めてしまいます。

人間が基盤を作り、AIが維持・拡張する

ここまで聞くと「メモの管理って大変そう…」と思うかもしれません。確かに、すべてを人間が手動で管理するのは限界があります。

ただ、ここにもAIとの分業が活きてきます。

  • 人間の仕事:最初のメモを書く。重要な前提の変更を判断する。方向性を決める
  • AIの仕事:メモの整形・構造化。変更の影響範囲の洗い出し。フォーマットの統一

「完全自動で勝手にやってくれる」は残念ながらまだ夢の話です。でも人間が骨格を作り、AIがそれを整え広げていく——この分業なら今日から始められます。

実際、AI開発の世界では「CoDD(Coherence-Driven Development)」という考え方が提唱されています。これは、設計書の変更が他のどこに波及するかをAIが自動で追跡し、整合性を維持する仕組みです。専門的な話ですが、考え方の本質はシンプルです。「変わったら、関連するものも全部チェックする」。これはメモの管理でも、プロジェクトの管理でも、まったく同じです。

大事なのは、最初から完璧な仕組みを作ろうとしないこと。まずはメモ帳ひとつから始めてください。


まとめ

前回の記事では「伝え方」を、今回は「メモ」を取り上げました。この2つはセットです。

1. AIは覚えてくれない。これはバグではなく仕様。 → チャットが長くなれば忘れ、セッションが切れれば全消え。毎回「はじめまして」からやり直しになる。

2. メモがないと、毎回ゼロから説明する羽目になる。 → 同じ前提を何度も伝える非効率。しかも、情報が少ないほどハルシネーションのリスクが上がる。

3. メモは「箇条書き・前提条件・完了条件」で書く。 → AIが正確に読み取れる形式にする。美しい文章より、構造化された情報のほうがAIには伝わる。

4. メモは必ず古くなる。変更の波紋を意識して更新する。 → 変更箇所だけでなく、影響範囲を洗い出して関連箇所も更新する。ここを怠ると、メモの中で矛盾が生じ、AIが混乱する。

5. 人間が基盤を作り、AIが維持・拡張する。 → 完全自動は夢のまた夢。でも、分業なら今日から始められる。


前回「伝え方がすべて」と言いましたが、正確には**「伝え方 × メモ」がすべて**です。

伝え方は「1回のやりとりの質」を上げるもの。メモは「やりとりの積み重ね」を可能にするもの。この2つが揃うと、AIとの仕事は「毎回のガチャ」から「着実に前に進むプロジェクト」に変わります。

まずはひとつ、よく使うAIへの指示をメモにしてみてください。定例メールのフォーマットでも、議事録のテンプレートでも、何でもいいです。それを次回のチャットの冒頭に貼るだけで、**「ああ、前回と同じことを説明しなくていいんだ」**という快感を味わえるはずです。

その小さな一歩が、AIとの仕事を「消耗」から「蓄積」に変える第一歩です。

💡 メモで前提を蓄積できるようになったら、次は「大きな仕事の分解術」へ。AIに複雑な仕事を任せるコツをお伝えします。

目次