はじめに：AIに頼んでも「うちの仕事」にならない理由
ChatGPTやClaudeに「提案書の構成を考えて」と頼んだことがある人なら、こんな経験があるはずです。
出てきた構成は、たしかにそれっぽい。でも、自分のサービスの強みも、いつも聞かれる質問も、去年うまくいった提案の流れも入っていない。結局、自社の説明を貼り直し、口調を伝え直し、前回のチャットを探してコピーしてから、やっと使えるものが出てくる。そして翌週、別の案件で同じことを繰り返す。
これは、AIの性能だけの問題とは限りません。仕事に必要な「材料」を十分に渡せていないことも、原因のひとつです。
人間の新人に例えるなら、会社説明もマニュアルも過去の資料も渡さずに、初出勤の日に「うちらしい提案書を作って」と言っているようなものです。誰がやっても一般論しか出せません。
この記事では、あなたが普段使っているツール（ChatGPT、Claude、Notion、Googleドキュメント、メールなど）に散らばっている情報を取り出し、AIが迷わず読める「ナレッジ」として整理し、実際の仕事で使い回すまでの手順を解説します。
想定している読者は、AIチャットを日常的に使っている個人事業主、小さなチームの担当者、社内でAI活用を任された人です。プログラミングの経験は不要です。ターミナルのコマンドがいくつか出てきますが、実行環境と保存先を確認して使えるサンプルを載せています。Pythonの例にはPython 3が必要です。
まず、この記事を読み終えた後に何が変わるのかを図で確認してください。
左の状態では、説明のコストが毎回発生します。右の状態では、AIが資料を参照できる環境と読み方の指示を用意することで、共通の説明を減らし、今回の案件の条件に集中できます。静止画版を見る。
前提：情報が「ある」ことと、AIが「使える」ことは別
「うちの資料はGoogleドライブに全部あります」「Notionにまとめてあります」「ChatGPTのメモリ機能をオンにしています」という人は多いです。それでも冒頭のような状態から抜け出せないのは、情報の存在と、AIが仕事で使える状態が別物だからです。
置き場所ごとに、得意なことと限界を整理すると次のようになります。
受付の付箋、倉庫、掲示板はどれも必要ですが、AIが仕事の前に読む「資料室」の代わりにはなりません。
チャットAIのメモリ機能は、あなたの好みや呼び方を覚えるには便利です。ただ、覚えられる量には上限があり、何をどう覚えたかを自分で完全に管理することもできません。会社の全資料を預ける場所ではなく、受付の人が持っている付箋くらいに考えるのが安全です。
Googleドライブや共有フォルダは、ファイルを保管する倉庫としては優秀です。ただし、最新版や優先順位を明示しないと、AIが古い資料を参照するおそれがあります。2023年と2026年の料金表が同じ場所にあるなら、どちらを使うかを指定します。
Notionや社内Wikiは、人が画面で読むための道具です。ページが階層の奥に埋まっていたり、データベースに分かれていたりすると、AIが横断して読むには毎回外部から取りに行く仕組みが必要になります。
この記事で作るのは、それらとは別の「AIが最初に読む資料室」です。実体は、自分のパソコン（またはクラウド同期されたフォルダ）の中にある、Markdownというテキスト形式のファイルの集まりです。
Markdown（マークダウン）は、# で見出し、- で箇条書きを表すだけの軽い書き方で、ChatGPTの回答に ** が混じって出てくることがあるのはこの形式です。AIはもともとこの形式を読み書きするのが得意なので、資料室の書式として相性が良いのです。
補足しておくと、Obsidianなどの専用アプリは必須ではありません。Obsidianはローカルのフォルダを見やすく表示するビューアであって、資料室の実体はフォルダとテキストファイルです。VS Codeでも、Cursorでも、普通のテキストエディタでも、この記事の内容はそのまま使えます。
全体像：5つのステップを回し続ける
作業は5つのステップに分かれます。一度作って終わりではなく、5番目のステップから1番目に戻る循環を回すことで、使うたびに資料室が育っていきます。
1周目は雑でかまいません。2周目以降で精度を上げる前提で進めます。静止画版を見る。
それぞれのステップを、一人でWeb制作と運用支援をしている個人事業主を例にしながら見ていきます。この例は説明用の架空のものですが、士業、講座の運営者、小さな会社の営業事務など、どの仕事でもそのまま置き換えられます。
ステップ1：普段使っているツールからデータを取り出す
最初にやるのは整理ではなく、材料を一か所に出すことです。ここで整理まで始めると、ほぼ確実に途中で止まります。
受け入れ用のフォルダを先に作る
まず、原本のコピーを受け入れる _inbox フォルダだけ作ります。以下のBashコマンドは、Macのターミナル（bash/zsh）、またはWindowsのGit Bash・WSLで実行してください。PowerShellにそのまま貼る書式ではありません。
# 資料室の親フォルダと、原本コピーの受け入れ先を作る
mkdir -p knowledge-base/_inbox/{chat-logs,notion,docs,sheets,messages,voice}
cd knowledge-base
以後、取り出したファイルはすべて _inbox の中の該当フォルダにコピーします。元のツールにあるデータは削除しません。_inbox はあくまでコピー置き場です。
エクスポートの方法はツールごとに違いますが、行き先はすべて _inbox の下です。静止画版を見る。
集める対象に優先順位をつける
すべてを集める必要はありません。次の表は、先ほどの個人事業主の例で「濃い情報がどこにあるか」を整理したものです。あなた自身の版を、この表を埋める形で作ってみてください。
| 情報の種類 | どこにあるか | 優先度 | 理由 |
|---|---|---|---|
| サービス内容・料金・納期 | Googleドキュメントの料金表、過去の見積書 | 高 | AIが最も間違えやすく、間違えると損害が出る |
| よく聞かれる質問と答え | Gmail、LINE、打ち合わせメモ | 高 | 提案書・FAQ・返信文の材料になる |
| 過去にうまくいった提案書 | Googleドライブ、Notion | 高 | 構成と言い回しの型になる |
| 自分の判断の履歴 | ChatGPT・Claudeの会話 | 中 | 「なぜそう決めたか」が残っている |
| 作業手順（納品、請求、更新作業） | 頭の中、Notionのチェックリスト | 中 | 手順書（後述のplaybook）の元になる |
| 競合や参考にしたサイト | ブックマーク、Notionのクリップ | 低 | 参考にはなるが、自社の正本ではない |
「頭の中」が多い人ほど、この後の「音声入力で出す」工程が効きます。
ChatGPT・Claudeの会話履歴を取り出す
会話履歴には、単なる文章ではなく「あなたの判断の過程」が残っています。商品名を決めた経緯、提案書の構成を直した理由、ボツにした案。これらは普通の会社資料には残っていません。
ChatGPTの場合の手順です。
- 画面左下（または右上）のプロフィールアイコンから「設定」を開きます。
- 「データコントロール」を選び、「データをエクスポート」を押します。
- 確認画面で「エクスポートを確認」を押します。
- 登録メールアドレス（電話番号のみのアカウントではSMS）にダウンロードリンクが届くのを待ちます。公式には最長7日とされています。
- メールの「データエクスポートをダウンロード」からzipを保存します。リンクの有効期限は24時間なので、届いたら早めに保存してください。
- zipを展開し、会話履歴を確認します。以下の変換例は
conversations.jsonが含まれる形式を対象にします。削除済みの会話は復元できません。
ChatGPT Business・Enterpriseでは、この個人向けのセルフサービス書き出しは利用できません。組織の管理者に確認してください。対応プランと手順はOpenAI公式ヘルプで確認できます。
Claudeの個人向けプランでは、Web版またはデスクトップ版の「設定 → プライバシー」から書き出すと、メールでダウンロードリンクが届きます。Team・Enterpriseは組織のPrimary Ownerによる書き出しです。詳細はClaude公式ヘルプを参照してください。次のスクリプトは conversations.json 内に chat_messages がある形式に対応します。
conversations.json はそのままでは人間にもAIにも読みにくいので、会話ごとのMarkdownファイルに変換します。次のスクリプトを chat_export_to_md.py という名前で保存し、zipを展開したフォルダで実行してください。ここで扱うChatGPTとClaudeの2形式を判別します。画像・添付・すべての将来の形式を扱う汎用変換器ではありません。
"""ChatGPT / Claude のエクスポート（conversations.json）を、会話ごとの Markdown に変換する。
使い方（エクスポートのzipを展開したフォルダで実行）:
python3 chat_export_to_md.py conversations.json _inbox/chat-logs
"""
import json
import re
import sys
from datetime import datetime
from pathlib import Path
def safe_name(title: str, limit: int = 60) -> str:
# ファイル名に使えない文字を除く
title = re.sub(r'[\\/:*?"<>|\r\n]+', " ", title or "untitled").strip()
return title[:limit] or "untitled"
def chatgpt_messages(conv: dict):
# current_node から parent をたどり、実際に表示されていた分岐だけを取り出す
mapping = conv.get("mapping", {})
node_id = conv.get("current_node")
chain = []
while node_id:
node = mapping.get(node_id) or {}
msg = node.get("message")
if msg:
role = (msg.get("author") or {}).get("role")
parts = (msg.get("content") or {}).get("parts") or []
text = "\n".join(p for p in parts if isinstance(p, str)).strip()
if role in ("user", "assistant") and text:
chain.append((role, text))
node_id = node.get("parent")
return list(reversed(chain))
def claude_messages(conv: dict):
out = []
for m in conv.get("chat_messages", []):
role = "user" if m.get("sender") == "human" else "assistant"
text = (m.get("text") or "").strip()
if text:
out.append((role, text))
return out
def to_markdown(title, created, source, messages):
# 先頭に管理用の情報（frontmatter）を付ける。status は仕分け後に書き換える
lines = ["---", f"title: {json.dumps(title, ensure_ascii=False)}", f"source: {source}", f"created: {created}",
"status: raw", "---", ""]
for role, text in messages:
lines += [f"## {'あなた' if role == 'user' else 'AI'}", "", text, ""]
return "\n".join(lines)
def main(src, dst):
data = json.loads(Path(src).read_text(encoding="utf-8"))
out_dir = Path(dst)
out_dir.mkdir(parents=True, exist_ok=True)
count = 0
for conv in data:
if "mapping" in conv: # ChatGPT 形式
title = conv.get("title") or "untitled"
ts = conv.get("create_time")
created = datetime.fromtimestamp(ts).strftime("%Y-%m-%d") if ts else "unknown"
messages, source = chatgpt_messages(conv), "chatgpt"
else: # Claude 形式
title = conv.get("name") or "untitled"
created = (conv.get("created_at") or "unknown")[:10]
messages, source = claude_messages(conv), "claude"
if not messages:
continue
fname = f"{created}_{safe_name(title)}.md"
target = out_dir / fname
suffix = 2
while target.exists():
target = out_dir / f"{created}_{safe_name(title)}_{suffix}.md"
suffix += 1
target.write_text(to_markdown(title, created, source, messages), encoding="utf-8")
count += 1
print(f"{count} 件の会話を {out_dir} に書き出しました")
if __name__ == "__main__":
if len(sys.argv) != 3:
print("使い方: python3 chat_export_to_md.py conversations.json 出力フォルダ")
sys.exit(1)
main(sys.argv[1], sys.argv[2])
# zipを展開したフォルダで実行する
python3 chat_export_to_md.py conversations.json ../knowledge-base/_inbox/chat-logs
実行すると 2026-03-14_提案書の構成相談.md のようなファイルが、テキストのある会話ごとにできます。同名の出力があれば連番を付け、上書きしません。ChatGPTで回答を「再生成」して分岐した会話は、最後に表示していた側だけを取り出す仕様です。画像や添付は含めず、テキストだけを残します。
このスクリプトは、記事執筆時点のエクスポート形式を模した疑似データで動作を確認しています。エクスポート形式は将来変わる可能性があるため、エラーが出た場合はエラー文をそのままAIに貼って「このエラーを直して」と聞いてください。
Notionを取り出す
Notionは、ページ単位でもワークスペース全体でもMarkdownとして書き出せます。
- 特定のページだけ欲しい場合は、ページ右上の「…」メニューから「エクスポート」を選びます。
- エクスポート形式で「Markdown & CSV」を選び、サブページを含めるかを決めます。
- ワークスペース全体が欲しい場合は、「設定」からワークスペースの設定を開き、「ワークスペースのすべてのコンテンツをエクスポート」を実行します。ダウンロードリンクはメールまたはアプリ内の受信箱に届きます。
- zipを展開し、
_inbox/notion/にコピーします。
展開すると、ページはMarkdownファイル、データベースはCSVとして出てきます。次の名前整理は任意です。リンク先の書き換えは行わないため、相対リンクが切れることがあります。リンクを残したい場合は名前を変えず、試す場合も別のコピーで行ってください。ファイル名の末尾に32桁の英数字（ページID）が付いているので、後で読みにくければ次のスクリプトで取り除けます。rename_notion_export.py という名前で保存して実行してください。
"""Notionエクスポートのファイル名・フォルダ名から、末尾の32桁IDを取り除く。
使い方:
python3 rename_notion_export.py _inbox/notion
"""
import re
import sys
from pathlib import Path
root = Path(sys.argv[1])
count = 0
# 深い階層から順に処理する（親を先に変えると子のパスがずれるため）
for p in sorted(root.rglob("*"), key=lambda x: -len(x.parts)):
new_name = re.sub(r" [0-9a-f]{32}(?=\.[^.]+$|$)", "", p.name)
if new_name == p.name:
continue
target = p.with_name(new_name)
if target.exists():
print(f"スキップ（同名あり）: {p}")
continue
p.rename(target)
count += 1
print(f"{count} 件の名前を変更しました")
# knowledge-base フォルダで実行する
python3 rename_notion_export.py _inbox/notion
自分以外のメンバーのプライベートページは、権限がなければエクスポートされません。チームで使っている場合は、誰のアカウントで書き出すかを先に決めておきます。
Googleドキュメント・スプレッドシートを取り出す
Googleドキュメントは、標準機能でMarkdownとしてダウンロードできます。
- 対象のドキュメントを開きます。
- メニューの「ファイル」から「ダウンロード」を選び、「マークダウン（.md）」を選びます。
- 保存したファイルを
_inbox/docs/に入れます。
画像が長い文字列として埋め込まれる形式では、ファイルが大きくなることがあります。重要な図表は説明をテキストで残し、不要な画像だけをコピー側から除きます。画像行を一括削除すると必要な情報まで失うため、中身を確認してください。
ファイル数が多い場合は、Googleテイクアウトで「ドライブ」を選んで一括ダウンロードします。書き出し形式としてWord形式（.docx）を選んだ場合は、pandoc というツールでMarkdownに変換します。
# pandoc のインストール（Macの場合。Windowsは公式サイトのインストーラを使う）
brew install pandoc
# docx を md に一括変換して _inbox/docs に置く
for f in *.docx; do
pandoc "$f" -t gfm -o "_inbox/docs/${f%.docx}.md"
done
スプレッドシートは「ファイル」から「ダウンロード」で「カンマ区切り形式（.csv）」を選び、_inbox/sheets/ に入れます。料金表や案件一覧のような表形式のデータは、CSVのままでもAIは十分読めます。
メール・チャットは「全件」ではなく「濃いところ」だけ
Gmail、Slack、LINE公式アカウントなどの履歴は量が多く、全件を取り込んでも大半はノイズです。ここでは、次の3種類だけを狙って取り出します。
- お客様から2回以上聞かれた質問と、そのときの自分の答え
- クレームや修正依頼と、それにどう対応したか
- 打ち合わせの後に送った「決まったこと」の確認メール
やり方は手作業で十分です。Gmailなら検索窓に「見積」「納期」「修正」などのキーワードを入れ、該当メールの本文をコピーして、_inbox/messages/faq-raw.md のようなファイルに貼っていきます。1通ごとに ## 2026-04-10 納期の相談 のような見出しを付けておくと、後の仕分けが楽になります。
Slackは、ワークスペースの管理者であれば設定画面からエクスポートできますが、公開チャンネルの全履歴が対象なので量が膨大です。特定のチャンネルの重要なやり取りだけをコピーする方が現実的です。
頭の中にある情報を音声で出す
ここまでの作業で「ツールには残っていないけれど、自分は知っている」情報がたくさんあることに気づくはずです。断るときの基準、値引きの判断、納品前に必ず確認すること、この表現は使いたくないという好み。これらは、実は一番価値の高いナレッジです。
おすすめは、スマートフォンの音声入力で15分話すことです。きれいに話す必要はありません。次のテーマを1つずつ、思いつくまま話してください。
| テーマ | 話す内容の例 |
|---|---|
| 自己紹介と事業 | 何を、誰に、いくらで提供しているか。始めた経緯 |
| お客様の悩み | 相談に来る人が最初に言う言葉。本当の困りごと |
| 選ばれる理由 | 他社ではなく自分に頼む人が挙げる理由 |
| うまくいった仕事 | どんな流れで進めたか。何が良かったか |
| 失敗した仕事 | 何が原因で、次から何を変えたか |
| 譲れないこと | やらない仕事。使わない言葉。守っている納期の考え方 |
| 判断の基準 | 値引きの可否、追加作業を受けるかどうかの線引き |
書き起こしたテキストを _inbox/voice/2026-09-13_事業について.md として保存します。整理はまだしません。整理はステップ3で、AIにやらせます。
ステップ2：集めたデータを「4つの箱」に仕分ける
材料が _inbox に集まったら、次は仕分けです。ここで重要なのは、すべてのファイルを「同じ価値」として扱わないことです。
AIが一番やらかしやすい事故は、古い情報を今の情報として使うことと、他社の情報を自社の情報として使うことです。この2つを防ぐために、ファイルを次の4つの箱に分けます。
| 箱 | 定義 | 個人事業主の例 |
|---|---|---|
| 正本 | 今この瞬間も正しく、AIが最優先で信じてよい情報 | 2026年9月版の料金表、現在のサービス一覧、会社概要、自分のプロフィール |
| 過去成果物 | 自分が過去に作ったもの。構成や言い回しの参考にはなるが、数値は古い可能性がある | 2024年の提案書、去年のセミナー資料、過去に送った見積書 |
| 外部参考 | 他社・他人が作ったもの。参考にはするが、自社の意見や口調とは区別する | 競合のサービスページ、参考にした記事、業界団体のガイドライン |
| 非公開 | 顧客名、個人情報、契約金額など、AIに渡す範囲を別途決めるべきもの | 顧客リスト、個別の契約書、請求書一覧 |
なお、非公開情報の有無を先に人が確認します。AIに渡せない情報は、一次仕分けを依頼する前に除外してください。複数の分類に当てはまる場合も、非公開情報の扱いを優先します。
どれにも当てはまらない、または迷ったものは _review という箱に入れて、後で人が見ます。無理にどこかへ分類しないことが、精度を保つコツです。
アニメーションは「2023年の料金表」を例に、正本ではなく過去成果物へ振り分ける経路をたどっています。静止画版を見る。
仕分けの実例
実際のファイルで考えると判断しやすくなります。
「2023年のサービス案内PDF」は、サービス内容の説明としては今も参考になりますが、料金が古いので正本にはできません。過去成果物に入れ、ファイルの先頭に「料金は古い。最新は 20_products を参照」と一行書きます。
「ChatGPTで商品名を相談した会話」には、最終的に採用した名前と、ボツにした10案が混ざっています。会話ファイル自体は過去成果物に置き、採用した名前と「なぜその名前にしたか」だけを抜き出して正本側に書きます。
「競合他社のサービスページを保存したもの」は外部参考です。ここで気をつけたいのは、競合の言い回しがそのまま自社の口調に混ざる事故です。外部参考のフォルダに置き、後述する地図で「参考にしてよいが、表現は流用しない」と明記します。
「請求書一覧のCSV」には顧客名と金額が並んでいます。非公開の箱に入れ、AIに渡すときは「件数と月別の合計だけを集計した版」を別に作るなど、渡す範囲を決めます。
一次仕分けはAIにやらせ、人が確認する
数十ファイルなら手作業で十分ですが、会話履歴を含めると数百ファイルになることも珍しくありません。その場合は、AIに一次仕分けをさせて、人は結果を確認する形にします。
Claude CodeやCodex、Cursorのように、フォルダの中身を直接読めるAIツールに、次のような依頼をします。
knowledge-base/_inbox の中のファイルを1つずつ読み、次の4つのどれに当たるかを判断してください。
- 正本：今も正しく、最優先で信じてよい情報
- 過去成果物：自分たちが過去に作ったもの
- 外部参考：他社・他人が作ったもの
- 非公開：顧客名・個人情報・個別の金額を含むもの
判断できないものは「要確認」としてください。
出力は「ファイル名 | 分類 | 根拠となった一文 | 更新すべき点」の表にして、
_review/仕分け結果_2026-09-13.md に保存してください。
ファイルの移動や削除はまだしないでください。表を作るだけです。
最後の一行が重要です。AIに最初から移動や削除をさせると、間違った分類でファイルが行方不明になります。まず表だけ作らせ、人が目を通して直してから、移動は次のステップで行います。
ステップ3：フォルダ構造を作り、Markdownに整える
仕分けの結果が固まったら、AIが読むための本棚を作ります。ここでは、次のような構造をおすすめします。
knowledge-base/
├── INDEX.md ← 地図。AIが最初に読む（ステップ4で作る）
├── 00_rules/ ← 口調、NG表現、人が必ず確認する箇所
├── 10_company/ ← 会社概要、プロフィール、実績、体制
├── 20_products/ ← サービス内容、料金、納期、FAQ（正本）
├── 30_customers/ ← お客様の悩み、よく聞かれる質問、断った案件の傾向
├── 40_playbooks/ ← 仕事ごとの手順書（提案書の作り方、納品手順など）
├── 50_outputs/ ← 成果物。past/ に過去分、年月フォルダに新規分
├── 80_private/ ← 非公開情報。AIに渡す範囲を別に決める
├── 90_references/ ← 外部の参考資料
├── _inbox/ ← 未整理の原本コピー
└── _review/ ← 判断に迷ったもの、AIの分類結果
番号を付けているのは、フォルダを開いたときに読む順番が分かるようにするためです。番号が小さいほど「AIが先に読むべきもの」、大きいほど「参考程度のもの」という意味を持たせています。
フォルダ名に日本語を使っても動きますが、ツールによっては文字化けや検索の問題が起きることがあるので、フォルダ名は英語、ファイルの中身は日本語という組み合わせが無難です。
AIは全ファイルを読むのではなく、地図に従って必要な場所だけを読みに行きます。静止画版を見る。
ファイルの書き方：1テーマ1ファイル、先頭に管理情報
各ファイルは「1テーマ1ファイル」にします。「会社のこと全部.md」のような巨大ファイルは、AIが読む量が増えるだけでなく、どこを直せばいいか人間にも分からなくなります。
ファイルの先頭には、次のような管理情報（frontmatter）を付けます。これがあると、AIが「この情報はいつ時点のものか」「信じてよいか」を判断できます。
---
title: Web保守プランの内容と料金
status: current # current（正本）/ archived（過去）/ reference（外部参考）
updated: 2026-09-01
owner: 自分
note: 料金改定は毎年4月。改定したらこのファイルだけ直す
---
status と updated は必ず書きます。古い情報の誤参照を減らす手がかりになりますが、最新資料との照合と人による確認は必要です。
中身のサンプル
抽象的な説明だけでは作りにくいので、個人事業主の例で4つのファイルの中身を示します。数値やサービス名はすべて架空です。
20_products/web-maintenance-plan.md（正本）の例です。
---
title: Web保守プランの内容と料金
status: current
updated: 2026-09-01
---
## 対象
- 当方で制作したサイト、または引き継ぎ調査を完了したサイト
## プラン（税別・月額）
| プラン | 料金 | 含まれる作業 |
|---|---|---|
| ライト | 15,000円 | CMS更新、バックアップ、月次レポート |
| スタンダード | 30,000円 | ライトの内容 + 月2回までの軽微な修正 |
## 含まれないもの
- 新規ページの制作（別途見積）
- 他社制作サイトの調査前の作業
## よくある質問
- Q. 途中でプラン変更はできますか
A. 翌月から可能。月の途中では変更しない
30_customers/faq.md（正本）の例です。メールから抜き出した実際の質問を、聞かれた回数と一緒に並べます。
---
title: よく聞かれる質問と答え方
status: current
updated: 2026-09-05
---
## 納期はどれくらいですか（過去半年で7回）
- 標準はデザイン確定から6週間。デザイン確定までの期間は別に見込む
- 答えるときは「6週間」の前に「デザイン確定から」を必ず付ける
## 他社で作ったサイトも保守してもらえますか（4回）
- 引き継ぎ調査（有償）を先に行う。調査の結果、断ることもある
- 調査なしで見積は出さない
## 安くなりませんか（3回）
- 値引きはしない。代わりに作業範囲を減らす提案をする
00_rules/writing-style.md（ルール）の例です。口調とNG表現、人が確認する箇所を書きます。
---
title: 文章のルール
status: current
updated: 2026-09-05
---
## 口調
- 一人称は「当方」。「弊社」は使わない（一人でやっているため）
- 語尾はですます調。「〜させていただきます」は1文書に1回まで
## 使わない表現
- 「業界最安」「絶対」「必ず成果が出る」
- 競合他社の名前を出した比較
## 人が必ず確認する箇所
- 料金と納期の数値（20_products の値と一致しているか）
- お客様の社名・担当者名（80_private 以外に書かれていないか）
40_playbooks/proposal.md（手順書）の例です。AIに「この手順で進めて」と渡すためのものなので、読む順番と保存先まで書きます。
---
title: 提案書を作る手順
status: current
updated: 2026-09-05
---
## 読む順番
1. 00_rules/writing-style.md
2. 20_products/ の該当サービス
3. 30_customers/faq.md
4. 50_outputs/past/ にある直近2件の提案書（構成の参考。数値は使わない）
## 構成
1. お客様の現状と困りごと（30_customers の言葉を使う）
2. 提案する内容と、含まれないもの
3. 進め方と納期
4. 料金（20_products の値のみ。独自に計算しない）
5. よくある質問
## 保存先
- 50_outputs/YYYY-MM/proposal_案件名.md
## 出力後に人が確認すること
- 料金・納期の数値
- 「含まれないもの」が漏れていないか
散らかった原本から、AIに下書きを作らせる
上の4ファイルを最初から手で書く必要はありません。_inbox の材料を読ませて、AIに下書きを作らせます。
knowledge-base/_inbox/voice/2026-09-13_事業について.md と
_inbox/docs/料金表_2026.md を読み、次の2ファイルの下書きを作ってください。
1. 20_products/web-maintenance-plan.md
- サービス内容、料金、含まれないもの、よくある質問の見出し構成
- 料金は原本にある数値だけを使い、推測で補わない
2. 30_customers/faq.md
- 音声メモの中で「よく聞かれる」と言っている質問を抜き出す
- 答え方の方針が語られていれば、その言葉を残す
どちらも先頭に frontmatter（title / status: current / updated: 今日の日付）を付けてください。
原本に書かれていないことは書かず、不明な点は「要確認：」で始まる行にしてください。
「原本に書かれていないことは書かない」「不明点は要確認と書く」の2つを毎回入れてください。推測で補わない方針を伝えたうえで、出力と原本の数値を照合します。
出てきた下書きを読み、間違いを直し、足りない部分を追加で話して、またAIに整理させる。この往復を2〜3回すれば、実用に耐えるファイルになります。
ステップ4：AIが最初に読む「地図」を作る
フォルダとファイルができたら、最後に INDEX.md を作ります。これはAIが最初に読む地図で、資料室の館内案内図に当たります。
ここで多くの人がやってしまうのが、INDEX.mdに情報そのものを詰め込むことです。地図には「どこに何があり、何を優先し、何を読まないか」だけを書きます。短いほど良いです。
---
title: この資料室の地図
updated: 2026-09-13
---
## この資料室について
- Web制作と運用支援を一人で行う個人事業の、AI用ナレッジです
- 依頼を受けたら、まずこのファイル、次に 00_rules を読んでください
## 優先順位
1. 20_products と 10_company の status: current のファイルが正本です。矛盾があればこちらを信じてください
2. 50_outputs/past は構成と言い回しの参考です。数値・料金・納期は使わないでください
3. 90_references は外部の情報です。表現を流用せず、自社の意見として書かないでください
4. 80_private は、依頼文で明示されない限り読まないでください
## フォルダの案内
| フォルダ | 中身 | いつ読むか |
|---|---|---|
| 00_rules | 口調・NG表現・確認箇所 | 毎回 |
| 10_company | 会社概要・プロフィール・実績 | 自己紹介や信頼性が必要なとき |
| 20_products | サービス・料金・納期・FAQ | 見積、提案、質問回答のとき |
| 30_customers | お客様の悩みと質問 | 提案書、FAQ、返信文のとき |
| 40_playbooks | 仕事ごとの手順書 | 該当する仕事を頼まれたとき |
| 50_outputs | 成果物 | 参考にするとき、保存するとき |
## 成果物の保存先
- 50_outputs/YYYY-MM/ に、種類_案件名.md の名前で保存してください
## 不明な点があるとき
- 推測で埋めず、「要確認：」で始まる行にして人に聞いてください
ツールごとの「入口ファイル」
ツールごとの指示ファイルや設定に、INDEX.mdを参照する方針を書きます。適用範囲と読み込み条件はツールによって異なるため、初回は実際に参照したファイルを確認してください。
| ツール | 指示を置く場所 | 書く内容 |
|---|---|---|
| Claude Code | CLAUDE.md |
「作業前に INDEX.md を読み、その指示に従ってください」 |
| Codex | AGENTS.md |
同上 |
| Cursor |
.cursor/rules/ 内のルールファイル（常時適用など条件を設定） |
同上 |
| ChatGPTのプロジェクト、Claudeのプロジェクト | プロジェクトのファイルと指示欄 | INDEX.md と正本フォルダの主要ファイルをアップロードし、指示欄に「INDEX.md の優先順位に従う」と書く |
ターミナルを使わない人は最後の行の方法で構いません。正本ファイルが更新されたら、アップロードし直す手間があることだけ覚えておいてください。
ナレッジを作るときの注意点
ここまでの手順の中で、特につまずきやすい点をまとめます。どれも、実際に運用を始めてから気づくと手戻りが大きいものです。
原本は触らず、コピーで作業する
_inbox にあるのはコピーであり、NotionやGoogleドライブの元データはそのまま残しておきます。AIにファイルの移動や削除をさせるときは、「移動する前に一覧を出して、人の確認を待ってください」と必ず添えます。基礎工事で大事なのは速さより、壊さないことです。
1つのファイルに全部を詰め込まない
「会社のこと全部.md」を1本作ってAIに渡すやり方は、最初は楽に見えます。しかし、AIが毎回全文を読むためコストが増え、重要な部分を見落とし、人間もどこを直せばいいか分からなくなります。地図は短く、中身は1テーマ1ファイルが原則です。
日付とステータスを必ず書く
frontmatterの status と updated は省略しないでください。料金改定があったのに古いファイルが current のまま残っていると、AIは古い料金で見積を作ります。改定したら、古い方を archived にして 50_outputs/past へ移す、という運用をルール化します。
正本と外部参考を混ぜない
参考にした他社の記事や競合のサービスページを正本と同じフォルダに置くと、AIはそれを自社の思想として扱います。「業界最安」と書いてある競合ページを読んだAIが、自社の提案書に同じ言葉を使う、という事故が実際に起きます。外部参考は別フォルダに置き、地図で「表現は流用しない」と明記します。
顧客名と個人情報の渡し方を決める
80_private という名前や「読まないで」という指示はアクセス制御ではありません。AIに渡さない情報は、AIがアクセスできるフォルダの外に保管するか、権限で遮断します。そのうえで、顧客名・担当者名・契約金額のうち渡してよい範囲を決めます。クラウドのAIサービスに渡す場合は、社名を「製造業A社」のように置き換えた版を作る、集計値だけを渡す、といった工夫が必要です。会社で使う場合は、AIサービスの利用規約とデータの扱いを確認し、社内のルールに従ってください。
AIの分類を鵜呑みにしない
一次仕分けをAIに任せるのは効率的ですが、「正本」と判断されたものは必ず人が目を通します。特に料金、納期、実績の数値は、AIが自信を持って間違えるところです。_review フォルダを「迷ったら置く場所」として運用し、空にすることを目標にしないでください。
完璧を目指さない
最初から全フォルダを埋める必要はありません。正本が3ファイル、ルールが1ファイル、手順書が1ファイル、地図が1ファイル。合計6ファイルあれば、最初の仕事は回せます。使いながら足りないものを足す方が、結果的に早く仕上がります。
補足として、フォルダ全体をGitで管理しておくと、AIが書き換えた内容を後から確認したり、間違えた変更を戻したりできます。
# knowledge-base の中で一度だけ実行する
git init
echo "_inbox/" >> .gitignore # 原本コピーは容量が大きいので除外
echo "80_private/" >> .gitignore # 非公開情報は履歴に残さない
git add . && git commit -m "ナレッジの初期構築"
Gitに慣れていない人は、この工程は飛ばして、フォルダごと定期的にバックアップするだけでも構いません。
ステップ5：ナレッジを使って仕事をし、結果を戻す
資料室ができたら、実際に仕事を頼みます。ここで初めて、ステップ1から4の効果が出ます。
使い方の3パターン
どのツールを使うかで、やり方が少し変わります。
- Claude CodeやCodexのようなターミナルで動くAIを使う場合は、
knowledge-baseフォルダに移動してから起動します。適用される入口ファイル（CLAUDE.md や AGENTS.md）にINDEX.mdの参照を指示し、実際に読めているかを確認します。 - Cursorのようなエディタを使う場合は、
knowledge-baseをフォルダとして開き、チャット欄から依頼します。 - ブラウザのChatGPTやClaudeを使う場合は、プロジェクト機能にINDEX.mdと正本ファイルをアップロードし、依頼のたびに「INDEX.md の優先順位に従って」と一言添えます。
依頼文の書き方が変わる
ナレッジがあると、依頼文は「何をどう読んで、どこに出すか」を指定する形になります。
ナレッジがなかったときの依頼文は、こうでした。
Web保守の提案書を作って。うちは一人でやっていて、料金はライトが15,000円で……（以下、毎回同じ説明が続く）
ナレッジがある状態では、こうなります。
INDEX.md を読んだうえで、40_playbooks/proposal.md の手順で、
製造業のお客様向けにWeb保守プラン（スタンダード）の提案書の構成案を作ってください。
- お客様の困りごとは 30_customers/faq.md の「他社で作ったサイトも保守してもらえますか」の項目を使う
- 料金は 20_products/web-maintenance-plan.md の値のみ使う
- 50_outputs/2026-09/proposal_製造業向け保守.md に保存する
説明がなくなった分、依頼文は「今回の案件で何が違うか」だけに集中できます。
出てきた成果物を確認する
AIが出したものは、そのまま使わず、00_rules に書いた「人が必ず確認する箇所」をチェックします。先ほどの例なら、料金と納期の数値、含まれないものの記載、社名や担当者名の混入の3点です。
確認して直した箇所は、そのまま次の工程の材料になります。
修正点をナレッジに戻す
ここが、資料室を「育てる」工程です。成果物を直したとき、その修正を3種類のどれかに戻します。
| 修正の種類 | 戻す先 | 例 |
|---|---|---|
| 表現や口調の修正 | 00_rules/writing-style.md |
AIが「弊社」と書いた。一人称は「当方」とルールに追記 |
| 手順や読む資料の修正 |
40_playbooks/ の該当手順書 |
提案書に実績が入っていなかった。読む順番に 10_company/results.md を追加 |
| 良くできた成果物 | 50_outputs/past/ |
お客様の反応が良かった提案書を、次回の参考用に移す |
たとえば、AIが提案書の冒頭に「業界最安」と書いてきたとします。これを手で消すだけでは、次回も同じことが起きます。writing-style.md の「使わない表現」に一行足し、次の依頼で読ませることで再発を抑えやすくなります。ただし、出力の確認は続けます。この一行が、あなたの仕事の判断がAIに引き継がれた瞬間です。
1周するごとに、次の依頼で説明しなければならないことが減っていきます。静止画版を見る。
週に1回、15分の棚卸し
毎回の修正に加えて、週に1回15分だけ、次のことをします。
-
_reviewにたまったファイルを見て、分類して移動するか、削除するかを決めます。 - 今週の成果物のうち、良かったものを
50_outputs/pastに移します。 - 今週AIに口頭で補足したことがあれば、ルールか手順書に書きます。
- 料金や体制に変更があれば、正本を直して
updatedの日付を更新します。
この15分を続けるかどうかで、3か月後の資料室の使いやすさがまったく変わります。
最初の週末でやること：3時間プラン
長い記事になったので、最初の一歩を具体的な時間配分に落とします。
- 0〜20分：
_inboxフォルダを作り、ChatGPTとClaudeのエクスポートを申請します。届くまで時間がかかるので最初に押しておきます。 - 20〜50分：料金表、サービス案内、直近の提案書2件、よく使う返信メール5通を
_inboxにコピーします。 - 50〜70分：音声入力で、事業の説明、よく聞かれる質問、譲れないことを話し、
_inbox/voice/に保存します。 - 70〜110分：AIに
20_productsと30_customersの下書きを作らせ、数値を確認して直します。 - 110〜140分：
00_rules/writing-style.mdと40_playbooks/の手順書を1本、AIと一緒に書きます。 - 140〜160分：
INDEX.mdを書き、ツールの入口ファイルにINDEX.mdを読むよう指示します。 - 160〜180分：実際の仕事を1つ頼み、出てきたものを確認して、修正点を1つルールに戻します。
会話履歴のエクスポートが届いたら、後日スクリプトで変換して _inbox/chat-logs に追加し、翌週の棚卸しで仕分けます。
よくあるつまずきと対処
| 症状 | 原因 | 対処 |
|---|---|---|
| エクスポートのメールが届かない | 処理待ち、迷惑メール、組織の設定で無効 | 迷惑メールフォルダを確認。数日待っても届かなければ管理者に確認 |
conversations.json が数百MBあって開けない |
会話数が多い | 開かずにスクリプトで変換する。変換後は必要な会話だけ残す |
| 変換スクリプトがエラーで止まる | エクスポート形式の変更、文字コード | エラー文を全部コピーしてAIに貼り、修正案をもらう |
| Googleドキュメントの.mdが巨大 | 画像が長い文字列で埋め込まれている可能性 | 必要な図表の説明を残し、不要な画像だけコピー側から除く |
| AIが古い料金で見積を作る | 古いファイルが status: current のまま |
古い方を archived にして past へ移す。地図に優先順位を明記 |
| AIが競合の言い回しを使う | 外部参考が正本と同じ場所にある |
90_references に分け、地図に「表現を流用しない」と書く |
| AIが依頼のたびに全ファイルを読んで遅い | 地図がない、または地図に全文が書いてある | INDEX.md を短くし、「いつ読むか」の列を作る |
| 成果物が毎回同じ構成になる | 手順書が細かすぎる | 手順書は「読む順番と確認箇所」に絞り、構成の細部はAIの判断に任せる |
まとめ
AIに毎回同じ説明をしている状態から抜け出すために必要なのは、より良いプロンプトではなく、AIが読める資料室です。
手順を振り返ります。普段使っているツールから原本をコピーして _inbox に集める。正本、過去成果物、外部参考、非公開の4つの箱に仕分ける。1テーマ1ファイルで、日付とステータスを付けてMarkdownに整える。短い地図（INDEX.md）を作り、ツールの入口からその地図を読ませる。仕事を頼み、直した内容をルールと手順書に戻す。
この循環を回し始めると、今日書いた提案書が来月のFAQの材料になり、今週直した一行が来年まで効き続けます。逆に、作らなければすべてチャット欄に流れて消えます。
完璧な資料室を作ってから始める必要はありません。今週末の3時間で、正本3ファイルと地図1枚から始めてください。
参考リンク
- OpenAIヘルプセンター「ChatGPT の履歴とデータをエクスポートする方法」 https://help.openai.com/ja-jp/articles/7260999-how-do-i-export-my-chatgpt-history-and-data
- Notionヘルプ「Notionのコンテンツをエクスポート」 https://www.notion.com/ja/help/export-your-content
- Google公式「Import and export Markdown in Google Docs」 https://workspaceupdates.googleblog.com/2024/07/import-and-export-markdown-in-google-docs.html
- Claude公式「Export your Claude data」 https://support.claude.com/en/articles/9450526-export-your-claude-data
- Pandoc公式サイト https://pandoc.org/
図解は本文に掲載しています。アニメーションGIFには静止画版へのリンクも付けています。会話履歴の変換スクリプトとNotionのファイル名整理スクリプトは、本文中のコードブロックをそれぞれ chat_export_to_md.py、rename_notion_export.py という名前で保存して使えます。