毎日AIに使う3つの型 —— プロンプトの土台・チェック手順・引き継ぎメモ

「プロンプトの書き方」を検索する経営者が、この1年で本当に増えました。

私は自社のブログをAIに書かせて毎晩1本、翌朝9時に自動で公開する運用を続けています。今日でちょうど43日目、公開本数は32本を超えたところです。

その中で、毎日必ず使い続けている"型"は、たった3つしか残っていません。凝ったプロンプトの書き方ではなく、この3つを最初に決めておくと、AI活用は少しずつ会社に積み上がります。

今日は、その3つの型それぞれの中身と、途中でうまくいかなかった話を、そのまま書きます。

1. 「良いプロンプトを毎回考える」は続かない
2. 型1: プロンプトの土台 —— 毎回一緒に渡す「うちのルール」
3. 型2: チェック手順 —— 生成された後、必ず通す関門
4. 型3: 引き継ぎメモ —— 昨日から今日へ渡す1枚
5. なぜ3つに絞るのか
6. 明日から始めるならこの順番
7. まとめ

1. 「良いプロンプトを毎回考える」は続かない

まず、業界の潮目がすでに変わっています。

2026年に入ってから、AIの世界では「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ、という言い方をよく見るようになりました（コンテキストエンジニアリングとは？ — Salesforceブログ、プロンプトエンジニアリングは終わった？ — cloco）。

難しそうな言葉ですが、中身はシンプルです。1回のプロンプトを磨くより、AIが仕事するときに「何を知っている状態か」を設計する、というだけの話です（プロンプトエンジニアリングとの違い — Findy Team+）。

私はこれを難しく捉えず、「AIに毎回渡す3枚を決める」という形で運用に落としました。それが以下の3つです。

型1: 土台 —— 毎回一緒に渡す「うちのルール」
型2: チェック —— 生成された後、必ず通す関門
型3: 引き継ぎ —— 昨日から今日のAIへ渡す1枚メモ

順に見ていきます。

2. 型1: プロンプトの土台 —— 毎回一緒に渡す「うちのルール」

1つ目は、AIに何を頼むときも、指示文の前に必ず一緒に貼りつける短い文書です。私はこれを「土台」と呼んでいます。

土台に書くのは、次の4つだけで十分でした。

役割: AIがどんな立場で書くか（例: 建設実務の経験があるライター）
読者: 誰に向かって書くか（例: 中小企業の経営者。ITに明るいとは限らない）
NG表現: 使ってはいけない言い回し（例: 「必ず〜になる」「絶対に〜」）
出力の形: 章立て・文字数・段落の長さの目安

2026年のプロンプトの解説記事でも、この「役割・読者・NG・形式」の4要素はほぼ共通して挙げられています（プロンプト設計7原則 — Uravation、プロンプトの書き方完全ガイド — OptiMax）。

土台の効き目は、書いた瞬間には出ません。効いてくるのは、同じ土台を10回・20回と貼り続けたあとです。AIが「うちの会社の人」として振る舞い始め、頼み方を短くしても意図がずれなくなります。

失敗した話も1つ書いておきます。運用を始めた最初の頃、私は土台を欲張って長く書きすぎました。禁止表現を20個、注意事項を15個並べたら、AIは長い注意書きの後半をだんだん無視するようになりました。

土台はA4半分に収まる長さにする、というのが今の私の目安です。長くしたくなったら、それは土台ではなく、次に説明する「チェック手順」に回します。

3. 型2: チェック手順 —— 生成された後、必ず通す関門

2つ目は、AIが書き終えたあとに必ず通す3項目のチェックリストです。

私が使っているのは、この3項目だけです。

1. 数字は本文で言っている値と、引用元・自分の実測値と一致しているか 2. 氏名・固有名詞の表記は正しいか 3. 引用リンクは実在するURLか（AIが作った架空のURLではないか）

これは、以前このブログで書いたAIに任せて事故りかけた話で扱った失敗から生まれた項目です。

正直に書きます。私はAIに書かせた記事7本で、自分の建設実務の年数を「20年」「22年」で混在させたまま公開してしまったことがあります。3本では自分の名前の漢字も間違えていました（雅治／正治／増本正浩）。

これは「AIが悪い」のではなく、チェックを型にしていなかった私の運用不備でした。この3項目を最後に必ず人が通すようにしてから、同じ種類の事故はゼロです。

2026年の生成AI導入ガイドでも、「チェックリストを事前に決めて、AIに自分で採点させ、最後は人が突き合わせる」という2段構えが推奨されています（AIの回答品質チェック10項目 — ゼットリンカー）。

ここで大事な線引きが1つあります。AIに「自分の出力を採点して」と頼むことはできますが、それは人による確認の代わりにはなりません。同じAIが書いた文章を同じAIが採点しても、同じ思い込みが素通しになるだけです。

数字・氏名・引用リンクの3つだけは、最後に人が目で突き合わせる。この線は動かさない方が無難です。

2026年3月31日に更新されたAI事業者ガイドライン第1.2版でも、AIエージェントの業務利用では「重大な影響が生じ得る場面で、人間が判断を介在させる仕組み」を社内ルールに反映することが明記されました（AI事業者ガイドライン第1.2版について — 経済産業省）。中小企業でも、この線引きから逃げない方が長い目で楽になります。

4. 型3: 引き継ぎメモ —— 昨日から今日へ渡す1枚

3つ目は、AIのセッションは切れるという前提で運用するための1枚メモです。

現在のAIは、会話のウィンドウ（コンテキストと呼びます）に上限があり、そこから外に出た情報は参照できません。昨日話したことは、今日別のセッションを立ち上げると、ほぼ完全に忘れられています（AIはなぜ前の話を忘れるのか — note）。

この対策として、AI業界では「ハンドオフメモ」や「HANDOFF.md」という呼び方で、次のセッションに渡す1枚メモを作る運用が定着してきました（Claude Codeのカスタムスラッシュコマンドでセッション引き継ぎノートを生成する — ヌーラボ、HANDOFF STATEの意味や活用法 — ユニバーサルマーケティング）。

これは中小企業の言葉に置き換えると、社内の引継ぎノートとまったく同じです。担当者Aから担当者Bに仕事を渡すときに、その日の状況を1枚にまとめる、あれです。

私が毎晩AIに渡している引き継ぎメモには、この4項目だけを書いています。

昨日書いたこと: タイトル・扱った話題・使ったソース
今日渡すこと: 次の候補と、なぜそれを選んだか
空いた枠: もし前日が落ちていたら、どの日が抜けているか
直近の失敗: 直前で気づいた事故と、次に同じ轍を踏まないための対策

「昨日書いたこと」の欄が一番効きました。これを書き始める前、翌日のAIは前日と似た切り口の記事を書こうとしていました。切り口の重複を人が毎回検知するのは骨が折れます。1行渡すだけで、AIは自分で違う角度を探しに行きます。

もう1つ失敗を書いておきます。引き継ぎメモを作る前、私は代わりに「設計書のなかに★マークを付けて、次に書く記事の目印にする」という運用をしていました。書いた記事の★マークを外し忘れると、AIは同じ記事を延々と書こうとします。実際に8晩、ブログの自動化が止まったまま気づけませんでした。

この失敗のあと、目印運用をやめて、「引き継ぎメモにその日の状況を書き出す」型に切り替えました。人にとっても、AIにとっても、状況を書いて渡す方が、目印を維持するより持続します。