つい先日、私たちの会社で、AIが自信満々に間違えた。
社内システムの状況調査を頼んだところ、AIはこう断言した。「このシステムはRender（クラウドサービス）上で動いています」。しかし、主要な稼働先はすでに別の環境へ移っていた。
原因は数分で見つかった。作業フォルダの名前に、移行前のサービス名がそのまま残っていたのだ。AIはその名前を読み、文字どおりに信じた。
少なくとも、この場面でAIがゼロから嘘を作ったわけではなかった。机に残っていた古い地図を、真面目に読んだのだ。
この記事は「良い指示文の書き方」の話ではない。その一歩手前にある、AIに渡す「机」の作り方の話だ。長いプロンプトを書く前に、机から古い地図を下げる。それだけで防げる間違いがある。
あなたの机にも、同じ罠がある
同じ項目の古い値が並べば、AIはどれが現役かを人の記憶なしには確定できない。
- 9,800春の企画書
- 10,800最終2
- 12,800承認待ちメモ
使えばいい？流暢さは、正本を決めてくれない
他人事に聞こえるだろうか。なら、自分のPCのフォルダを思い出してほしい。
企画書_最終.docx企画書_最終2.docx企画書_最終_修正版.docx
どれが本当の最終か、自分でももう自信がないファイル。数字が古いままの料金表。「あとで直す」と言ったまま三か月たったFAQ。そして、チャットの中にだけ残っている「あの件、OKです」。
紙の書類は、古くなると黄ばむ。ファイルは何年たっても黄ばまない。去年の料金表と今日の料金表が、まったく同じ顔で隣に並ぶ。
人間は「たしかこっちが新しい」で選べる。作った日の記憶が体に残っているからだ。AIにその記憶はない。AIに見えるのは、机に置かれた文字がすべて。だから──
AIの答えは、あなたの机の鏡になる。机が矛盾していれば、答えも矛盾する。しかもAIは、それを自信のある声で読み上げる。
再現実験①──散らかった机のまま、頼む
理屈だけでは自分の仕事へ置き換えにくい。そこで編集部は2026年8月21日、架空のオンライン講座を題材に二つのフォルダを作り、同じ種類の依頼をAIへ渡した。講座や人物は実在しないが、入力ファイル、依頼文、出力は編集記録として保存している。万能性を測るbenchmarkではなく、机の置き方で挙動がどう変わるかを見る小さな再現実験だ。
最初のフォルダには、次の5ファイルだけを置いた。どこの机にもある光景だと思う。
春講座_企画書_最終.md──受講料9,800円・早期特典あり春講座_企画書_最終2.md──受講料10,800円・早割9,800円料金改定メモ.txt──「秋は12,800円に上げる案で進める。※青木さんの最終OK待ち」受講者アンケート抜粋.md秋講座_日程.md──開講10月3日・申込期限9月20日
この机のまま、AIへ一言。「秋講座の案内メールを書いて」と頼んだ。
AIは、もっとも完成度が高そうな「最終2」の企画書を軸に、読みやすいメールを作った。日程は正しく10月3日。アンケートの「満足度4.6」まで気を利かせて引用する。そして受講料は10,800円（早割9,800円）、早期特典つき。
正解は「12,800円・特典廃止」だから、肝心の数字が両方違う。
ここでAIを責める前に、机をもう一度見てほしい。料金は9,800円、10,800円、12,800円の三つが転がっていて、12,800円は「OK待ち」のメモのまま止まっている。決裁が下りた事実は、このフォルダの外にしか存在しない。
この机で正解できるのは、チャットの返事と決定の経緯を覚えている人だけだ。
実際の出力は、メールの末尾に「12,800円へ改定する案もありましたが、確定記録がないため10,800円で作成しました」と添えていた。それでも安心はできない。急いでいる日に、きれいな本文の下の小さな一行を読み飛ばせば、そのまま誤案内を送ってしまう。それが現実に起きる失敗の形である。
ひとりで仕事をしてきた人の机には、これまで一度も「他人」が座ったことがない。だから、机が自分専用になっていることに気づく機会がなかった。AIは、あなたの机に座る最初の他人だ。間違いが起きたのは、他人が読める机になっていなかったからで、それはあなたの落ち度というより、今まで必要がなかっただけである。
再現実験②──今度は、机を先に渡す
短い入口からcurrentへ進み、workだけを編集する。decisionsは理由、archiveは退役済みの地図として残す。
料金・日程・名称
変更はここへ閉じる
before / after / 日付
残す。ただし現役から外す
同じ仕事を、今度は小さな「仕事場」を作ってから頼む。作ったのは、フォルダ5つとファイル数枚だけだ。
my-ai-workspace/
├── 00_READ_FIRST.md ← AIが最初に読む地図
├── current/ ← 今の正解だけを置く棚
│ ├── service_facts.md ← 料金・日程・特典の正本
│ ├── audience.md ← 誰に向けて書くか
│ └── writing_tone.md ← どんな文体で書くか
├── work/ ← AIと編集中の下書き
├── decisions/ ← 何を・いつ・なぜ変えたか
└── archive/ ← 古いが経緯として残す資料
心臓部は00_READ_FIRST.mdだ。長い会社紹介はいらない。次の程度でいい。
# この仕事場の使い方
## 最初に読む順
1. current/service_facts.md
2. current/audience.md
3. current/writing_tone.md
## 正本ルール
- 料金・日程・特典は current/ だけを正とする
- archive/ は過去比較を頼まれた時だけ読む
- 矛盾を見つけたら、推測せず、作業を止めて先に報告する
## 権限
- 編集してよいのは work/ の中だけ
- current/ と decisions/ は変更案の提案まで
- 送信・公開・決済は行わない
そして依頼は、ここまで短くなる。
00_READ_FIRST.md から読んで、work/ の下書きを現在の事実に合わせて更新して。矛盾があれば、直す前に教えて。
二回目の実験では、AIは本文を書き始めなかった。最初に料金と特典の二つの矛盾を挙げ、値上げ理由を反映する提案まで添えたうえで、「currentを正として更新してよいですか」と承認を待った。
この設計なら、AIへ最初に返してほしいのはメールではない。報告だ。
作業前に矛盾を報告します。
・work/ の下書きは受講料 9,800円ですが、current/service_facts.md では 12,800円です。
・下書きには早期特典の記載がありますが、current では「廃止」となっています。
current を正として下書きを更新してよいですか。
勝手に直さず、止まって、聞く。そういう挙動を先に設計する。
魔法ではない。READ_FIRSTに「矛盾を見つけたら、推測せず、作業を止めて先に報告する」と書いたからだ。ケース①では本文の下に埋もれたかもしれない注意を、本文より先に出させる。順番を変えるだけで、道具の手触りは一変する。
「たまに間違える道具」が、「確認してくる同僚」になる。
手間は、正直に言っておく
このやり方は、初回だけを見れば遠回りだ。
小さな机でも、作るには30分ほど見ておきたい。散らかったフォルダのまま頼むだけなら、依頼は数秒で済む。だから一度きりの仕事では、準備の方が重い。
一方で、同じ種類の仕事を繰り返すほど準備は効いてくる。毎回数百字の背景説明を書かず、「READ_FIRSTから読んで、この下書きを更新して」で始められる。料金や方針が変わっても、直すのはcurrentの一か所だ。繰り返さない仕事に机はいらない。繰り返す仕事には、毎回の説明より、一度の整理が効く。
「古い正解」の防ぎ方──消さない・混ぜない・札を貼る
机を作っても、放っておけばまた古い地図がたまる。ファイルは黄ばまないからだ。防ぎ方は、三つの動作と一つの禁止に集約できる。
① 新しい正解は、先に current へ書く
料金を12,800円へ変えたら、チャットで「OKです」と返事をする前に、current/service_facts.mdを直す。ファイルの頭に「いつ確かめたか」を添える。
verified_at: 2026-08-21 ← 最後に人が確認した日
next_review: 2026-11-21 ← 次に見直す日
受講料: 12,800円
早期特典: なし（2026秋から廃止）
重要な決定をした日の「最後の作業」を、チャットへの返信ではなくcurrentの更新に変える。実験①で12,800円がAIへ届かなかった原因は、決定がチャットの中で止まっていたことだった。この一手が一番効く。
② 変えた理由は decisions に一枚だけ残す
# 2026-08-18 料金改定
- 変更前: 9,800円 → 変更後: 12,800円
- 理由: 個別フィードバック枠の追加
- 影響: LP・FAQ・案内メールを要更新
三か月後の自分とAIが、「なぜこの値段なのか」を辿れるようになる。
③ 古い資料は捨てず、札を貼って archive へ退役させる
図書館は古い本を捨てない。開架から閉架へ移すだけだ。同じように、春の企画書の先頭へ退役札を貼り、archive/へ移す。
STATUS: SUPERSEDED（役目を終えた資料）
REPLACED_BY: current/service_facts.md
消せば経緯を失う。混ぜれば現在と衝突する。残す、ただし現役の棚からは外す。この中間だけがちょうどいい。
④（禁止）矛盾の裁定を、AIにさせない
二つの料金を見つけたAIに「いい感じに判断して」と頼んではいけない。空白を上手に埋める能力は、創作では武器だが、料金・契約・日程では事故になる。AIに任せるのは文章化であって、事実の採決ではない。裁くのは、いつでもあなただ。
履歴は、「戻る」ためだけにあるのではない
同じ一枚を育てながら、料金、特典、反映先がいつ・なぜ変わったかをcommitで辿る。
- INITIAL9,800円 + 特典
最初の公開条件を登録
a18c2f - DECISION12,800円 + 特典廃止
個別フィードバックを追加
c51e90 - SYNCFAQ + 案内文を同期
現在値をすべての導線へ反映
f07b64
ここまでなら、整理したローカルフォルダでもできる。GitとGitHubを使う価値は、その先にある。ファイルを上書きして終わらせず、ひとつの仕事が、どんな判断を経て現在の形になったかを残せることだ。
たとえば、current/service_facts.mdを一つだけ育て、節目ごとに短い言葉を添えてcommitする。
08/12 秋講座の初期案を登録 9,800円・特典あり
08/18 個別フィードバック枠を追加 12,800円・特典廃止
08/21 FAQと案内メールへ反映 表記を統一
三か月後、受講者から「なぜ値段が変わったのですか」と聞かれたとする。現在のファイルだけを見ても、12,800円という答えしか分からない。履歴を開けば、8月18日に何が消え、何が加わり、どんな意図でcommitしたかを辿れる。
正本が「いま」を伝え、履歴が「なぜ」を伝える。
これは復旧より前に効く。GitHub DesktopのChangesでは、まだ採用していないAIの変更だけを赤と緑の差分で確認できる。Historyでは、採用したcommitを時刻、説明、変更ファイルと一緒に辿れる。GitHub上で一つのファイルを開けば、少し物騒な名前のBlameから、行ごとに誰が、いつ、どのcommitで変えたかも確認できる。
AIにFAQ全体を整えさせたら、文章はきれいになったが、返金条件まで勝手に丸められていた。そんな時も、完成文を最初から読み比べる必要はない。差分から「AIが触った場所」だけを見て、その二行を採らないと決められる。失敗が大きな上書き事故ではなく、採用前の候補で止まる。
成功した状態も残る。先月よく反応された案内文、トーンを崩す前のFAQ、説明が短くまとまった企画書。ファイル名を最終2、最終3と増やさなくても、同じファイルの過去へ戻って比べられる。失敗は捨てるゴミではなく、次のAIに「どこで道を外れたか」を示す材料になる。
使っているAIツールがGitの履歴へアクセスできるなら、次のようにも頼める。
current/service_facts.mdの現在内容と、このファイルの直近5件の変更履歴を確認して。現在値と変更理由が食い違っていたら、書き換えずに報告して。
ただし、repositoryを置いただけで、すべてのAIが履歴まで自動で読むわけではない。履歴を扱えるツールと権限が必要で、読ませる指示も要る。そこまで接続しない場合でも、履歴は人間の確認と復旧のために残る。
なお、変更履歴を作っている主役はGitであり、この仕組みはローカルだけでも使える。GitHubは、その履歴を別の場所へ同期し、ブラウザで確認し、必要なら他の人とレビューする置き場だ。二つを分けて理解しておくと、「GitHubへ置けばAIが賢くなる」という誤解も起きにくい。
月10分の点検も、AIにやらせる
「文書管理なんて続く気がしない」という人にこそ、最後の仕掛けを渡したい。点検そのものをAIの仕事にするのだ。月に一度、こう頼む。
このフォルダ全体を読んで、次の4つを一覧にして。修正はまだしないで。
① 同じ項目なのに値が違う箇所（料金・日付・名称）
② 「検討中」「OK待ち」のまま止まっている決定
③ verified_at が90日以上前のファイル
④ どの資料からも参照されていない、古そうなファイル
あなたの仕事は、返ってきた一覧を見て「これは現役」「これは退役」と指を差すこと。小さな仕事場なら、月10分の点検から始められる。
古い地図に騙されるのもAIなら、古い地図を一番速く見つけ出すのもAIである。
どこまで本当か──効果の限界も先に言う
二つ、正直に付け加える。
第一に、「repositoryに資料を置くとAIが賢くなる」という言い方は、半分だけ正しい。AIの頭が恒久的に良くなるわけではない。持たせる地図が新しくなるだけだ。ただし逆に言えば、学習を待つ必要がない。地図を差し替えた次の瞬間から、答えは変わる。
第二に、机を整えてもAIは間違える。だから最後の砦は、変更の差分（diff）を人の目で見て承認することだ。ここでGitHubが効いてくる。Gitは、commitした時点のファイル状態を履歴として残す。GitHub Desktopでは、その履歴と変更差分を画面で辿れる。この性質は、文章の仕事にも効く。
始め方にコマンド入力はいらない。公式アプリのGitHub Desktopを使えば、三歩で動く。
GitHub Desktopを入れて、サインインする。
「Create a New Repository」で
my-ai-workspaceを作り、「Publish repository」で置く。Keep this code privateのチェックを必ず確認する。そのフォルダを、ファイルを読めるAIツール（Claude Code、Codex、Cursor等の「フォルダを開く」相当）で開く。
AIが一文を書き換えるたび、差分画面に緑（追加）と赤（削除）の線が引かれる。あなたは線を見て、採るか、直すか、捨てるかを決めればいい。採用するなら一文を添えて記録（commit）する。「秋講座の案内、初稿」。それで履歴に残る。
そして最初に一度だけ、練習用ファイルの一文を変え、差分を見て、commitしてほしい。その後、GitHub DesktopのHistoryでそのcommitを右クリックし、Revert Changes in Commitを選ぶ。元のcommitを消すのではなく、変更を打ち消す新しいcommitが作られる。戻し方を知らないまま、任せる範囲を広げない。消火器の場所を確かめてから火を使うのと同じである。
戻せないものを、先に数えておく
下書き、差分、人の判断、commitまでは履歴へ残す。送信・公開・決済は別の承認線の向こう側に置く。
- 01AI DRAFT下書き
- 02DIFF変更を見る
- 03HUMAN GATE採る・直す・捨てる
- 04COMMIT履歴へ残す
- 送信
- 公開
- 決済
- 削除
- 権限変更
Gitが巻き戻せるのは、記録したファイルの状態だけだ。
送信したメール。公開した投稿。実行した決済。変更した権限。これらはcommitを戻しても、戻らない。
だから最初の段階では、AIに「送信・公開・購入・削除・権限変更」を渡さない。AIは下書きまで。送るのは人間。この線を最初に引けば、まずは失敗をファイル変更の範囲へ閉じ込められる。commitしたファイルなら履歴から辿れるが、外へ出た操作までGitが取り消してくれるわけではない。
もう一つ。private repositoryは秘密金庫ではない。パスワード、APIキー、不要な顧客情報は最初から置かない。一度記録した秘密は、ファイルを消しても履歴の中に残り続けることがある。
今日できる一歩──階段は三段だけ
今夜5分: 机はそのままでいい。いま使っているフォルダをAIに読ませて、さきほどの点検プロンプトを流す。返ってくる「矛盾の一覧」を眺める。──たぶん、少し驚くはずだ。その驚きが、次の段への入場券になる。
週末30分: 繰り返し発生する文章仕事を一つだけ選び、
my-ai-workspaceを作る。READ_FIRSTとcurrentを書き、下書きを一本AIに作らせ、差分を見て、commitする。毎月10分: 点検はAIに一次スキャンさせ、あなたは指差しの判断だけをする。
冒頭の話に戻る。あのフォルダ名の直し方は、数分で済む。古い名前を現実に合わせるか、READ_FIRSTに「配置先の正本はここ」と一行書くか。それだけで、次のAIはもう古い地図を読まない。
あなたの机にも、きっと何かが眠っている。古い名前。古い料金。チャットの中で止まったままの決定。それを見つける最初の5分から、AIとの仕事は変わり始める。
AIに渡すのは、指示だけではない。
仕事場を渡そう。
次に読む一歩──机を渡したら、次は「説明する」のをやめてみる。AIに質問をさせると、依頼はもっと短くなる。→ 次稿『AIの答えが浅い時、足りないのはプロンプトより「質問」かもしれない』（公開後にリンク）
一次資料・参考
GitHub Docs — Creating your first repository using GitHub Desktop
OpenAI — Harness engineering: leveraging Codex in an agent-first world
本文の講座例は、2026年8月21日にClaudeを用いて行った二条件の再現実験です。入力ファイルと出力は編集部で保存しています。講座・人物は架空であり、モデル一般の性能を測るbenchmarkではありません。
