AIに「自分のコピー」を作る方法：記憶と判断基準をファイルに移す手順

「AIに自分のコピーを作る」と聞くと、少し大げさに聞こえるかもしれません。
ここでいうコピーは、人格をそのまま再現するという意味ではありません。
あなたの代わりに人生を決めるAIでもないし、何でも自動で稼いでくれる仕組みでもない。

私が作ってきたのは、もっと地味なものです。
自分が毎回見ている情報。
自分が何を嫌がり、何を採用し、どこで止まり、どこで進むのか。
その判断の癖を、AIが読める形にしていく仕組みです。

これは、コードを書ける人だけの話ではありません。
私はハウスクリーニングの個人事業主です。
もともとコードは書けませんでした。
独学でAIやツールを触りながら、自分の仕事、自分の発信、自分の判断を、少しずつ外に出していっただけです。

しかも、私は過去にFXと情報商材で、合計860万円を失っています。
この数字は、きれいな成功物語のために出しているわけではありません。
むしろ逆です。
私は「判断を間違えると、人は普通に大きく失う」ということを、自分の身体で知っています。

だから、AIに求めているものも、派手な自動化ではありません。
もっと手前です。
「いまの判断は、自分の基準からズレていないか」
「この文章は、それっぽく整っているだけではないか」
「これは本当に進めるべきか。それとも、止めるべきか」
この確認を、毎回ゼロからやらなくて済む状態にする。

それが、私にとっての「自分のコピー」です。

この教材で作る成果物は一つです。
自分の判断基準ファイルの元です。
完成版でなくて大丈夫です。
まずは、AIに読ませるための入口、判断基準、外部記憶、失敗記録の型を、手元に残します。

01なぜ「自分のコピー」なのか

一人事業で一番きついのは、作業量そのものではありません。
もちろん作業量も多いです。
現場もあるし、見積もりもあるし、発信もあるし、商品も作る。
でも、本当に削られるのは、毎回の判断です。

どれを優先するか。
どこまで調べるか。
この提案は受けるのか。
この文章は出していいのか。
このAIの出力は採用していいのか。
この違和感は、ただの怖さなのか、それとも本当に止まるべきサインなのか。

一人でやっていると、この判断が全部自分に返ってきます。
誰かが横で「それは前にも同じ失敗をしている」と言ってくれるわけではない。
「その言い方は、あなたの売り方と合っていない」と止めてくれるわけでもない。

AIを使い始めた最初のころ、私はここを勘違いしていました。
AIに作業を頼めば、自分が楽になると思っていた。
でも実際には、AIは作業を速くする一方で、判断の回数も増やします。
出力が増えるからです。

文章案が一瞬で10個出る。
商品案が何パターンも出る。
改善案も、構成案も、導線案も出る。
でも、その中から何を採用して、何を捨てるかは、結局こちらが決めないといけない。

つまり、AIを入れると「作業」は軽くなるが、「採否判断」は増える。
ここを放置すると、AIを使っているのに疲れるようになります。

私が作りたかったのは、AIに全部を任せる仕組みではありません。

01.01出力を自分基準で見る

AIが出したものを、自分の判断基準でふるいにかける仕組みです。

たとえば、文章を作るとき。
AIは、きれいな文章をすぐに出します。
でも、きれいな文章がそのまま使えるとは限らない。
私の文脈が抜けているかもしれないし、売り方が強すぎるかもしれないし、逆に説明が弱すぎるかもしれない。

ここで必要なのは、「もっと自然にして」ではなく、もっと具体的な判断基準です。
私はどんな言葉を嫌うのか。
何を言うと、自分の売り方からズレるのか。
どういう根拠がないと、断定してはいけないのか。
どんなときは、速度を優先していいのか。
どんなときは、速度よりも確認を優先するのか。

これを毎回チャットで説明していたら、それだけで疲れます。

01.02基準を毎回読ませる

だからファイルにします。
AIが毎回読む場所に置きます。
ミスが起きたら、その場でルールに戻します。

一人事業で「自分が二人になる」とは、作業員が一人増えることだけではありません。
自分の判断を、外に置けるようになることです。

もう一人の自分が、横でこう言う状態です。
「それは前にもズレた」
「その判断は、あなたの基準だと保留」
「そこは急いでいい」
「そこは急ぐと壊れる」

この教材では、その作り方をそのまま書きます。
概念だけではなく、どのファイルを作り、何を書き、どの順番で育てるかまで落とします。

▼ここで手を動かす

ここでは、自分の判断基準をきれいに言語化しなくて大丈夫です。
まずは、過去にAIへ差し戻したこと、採用したこと、嫌だったことを貼るだけで進めます。

私の判断基準の材料を整理してください。
分類や言語化はあなたが行ってください。
出してほしい項目は、採用したもの、却下したもの、保留にしたもの、繰り返し嫌だと感じているもの、今後AIに確認してほしいことです。
分からないところは「要確認」と書いてください。
ここから私の材料です。
AIに出して良かったもの：
AIに出して違うと感じたもの：
過去に失敗した判断：
自分が嫌う売り方や言葉：
速度を優先したい作業：
必ず自分で確認したい作業：

なぜ効くか。
最初から「判断基準を書いてください」と言われると止まります。
採用、却下、保留の実例から入ると、AIが判断基準の形へ整理できます。

02AIに渡す記憶の4層構造

AIに自分のコピーを作るとき、最初にやることは「大量のメモを読ませること」ではありません。
むしろ、いきなり全部読ませると壊れます。

AIは、情報量が多いほど賢くなるわけではない。
何をどの順番で読めばいいかが決まっているから、動けるようになります。

02.01記憶は順番で使う

私が参考にした考え方には、raw / wiki / digest / identity という4層があります。
ここで一行で定義します。
raw は原本、wiki は整理済みの知識、digest は最近の文脈、identity は自分の核です。

raw は、原本です。
日記、メモ、貼り付けたログ、思いつき、会話の断片。
ここは書き換えません。
材料置き場です。

wiki は、整理済みの知識です。
人物、顧客、ツール、意思決定、調査結果、よく使う手順。
原本から取り出したものを、あとで使える形にした場所です。

digest は、最近の文脈です。
今週何をやっているか、直近で何を決めたか、何を忘れてはいけないか。
AIが毎回すべての過去を読まなくても、今の状態に追いつけるようにする層です。

identity は、自分の核です。
価値観、声、禁止ライン、判断基準、今の目標。
AIが「この人として振る舞う」ために、最初に見るべき層です。

ただ、この4層をそのままフォルダ名として真似る必要はありません。
私のVaultでは、実運用に合わせて少し違う形になっています。
Vaultは、ここでは自分のメモやファイルを置く場所くらいの意味です。
大事なのは名前ではなく、役割です。

このVaultでは、おおまかに次の4つが動いています。

一つ目は、CLAUDE.md です。
これはAIが起動時に読む入口です。
言語ルール、読むべき外部記憶、作業規律、やってはいけないこと、どのファイルを優先するかが書かれています。
人間で言えば、仕事を始める前に見る最初のメモです。

二つ目は、rules/ です。
ここには、判断コア、文体、メモリ運用、特定の振る舞いルールを外部化します。
CLAUDE.md に全部を貼ると重くなるので、入口には参照先だけを書き、中身はルールファイルへ分ける。
この分離がかなり大事です。

02.02必要な時だけ引く記録

三つ目は、ファイルメモリです。
直近セッションの記録、過去のやり取り、作業ログ、失敗の痕跡がここに入ります。
これは「毎回必ず全部読むもの」ではなく、必要なときに引きに行く記憶です。
全部を常時持たせるのではなく、必要になったら検索する。

四つ目は、Vault外部記憶です。
このVaultでは、self/identity.md、self/goals.md、self/methodology.md、WORK_LOG.md がそれに近い役割を持っています。
自分の役割、今の目標、意思決定フレーム、過去のミスと再発防止ルール。
ここをAIが起動時に読むことで、毎回の判断が前回から続きます。

この4層を、初めて作る人向けに最小構成へ落とすなら、次の形で十分です。

my-ai-copy/
・CLAUDE.md
・rules/judgment-core.md
・rules/writing-style.md
・self/identity.md
・self/goals.md
・self/methodology.md
・WORK_LOG.md

最初から自動化しなくていいです。
最初からフックもいりません。
ここでいうフックは、特定のタイミングで自動実行される仕組みのことです。

02.03入口と基準を分ける

まずは、AIが毎回読む入口と、自分の判断基準を置く場所を作る。
これだけで変わります。

ここでやってはいけないのは、メモを全部同じ場所に突っ込むことです。
「思いつき」と「確定ルール」と「現在の目標」と「過去の失敗」が混ざると、AIはどれを重く見ればいいのか分からなくなります。

人間でも同じです。
領収書、日記、契約書、今日のToDo、反省ノートが全部混ざっていたら、仕事は進みません。
AIに渡す記憶も同じで、重要なのは量ではなく、層です。

私の中では、こう分けています。
CLAUDE.md は入口。
rules/ は判断のルール。
self/ は自己定義。
WORK_LOG.md は失敗から作った規律。

この4つを分けると、AIへの指示がかなり安定します。
毎回「私の文体はこうで」「今はこのプロジェクトをやっていて」「前にこういうミスがあって」と説明しなくて済む。
AIが勝手に思い出すのではなく、読むべき場所に置いているから思い出せる。

ここに、記憶を作るうえで一番大事な区別があります。

02.04使える順番に並べる

記憶とは、保存量のことではありません。
AIが使える順番に並んでいることです。

▼ここで手を動かす

ここでは、フォルダ名を自分で設計しなくて大丈夫です。
今あるメモやファイルの種類を貼って、AIに最小構成へ分けさせてください。

私のAI用の記憶を、最小構成に分けてください。
分類はあなたが行ってください。
使う層は、入口、判断ルール、自己定義、今の目標、失敗記録、必要時だけ引く過去ログです。
私がいきなり全部を自動化しない前提で、最初に作るべきファイルと、中身の見出しだけを出してください。
ここから私の状況です。
今あるメモやファイル：
AIに毎回説明していること：
過去の失敗や差し戻し：
今進めている仕事：
AIに触らせたくない情報：

なぜ効くか。
最初からフォルダ設計を読者に任せると、名前で迷います。
役割ごとにAIへ分けさせると、記憶の置き場が「何のためにあるか」で決まります。

チャット型AIで使う場合は、CLAUDE.md 相当の内容を会話の最初に貼ってください。プロジェクト指示欄やカスタム指示がある環境なら、そこに置く。起動時に自動で読む仕組みがないなら、毎回最初に読ませる。大事なのはファイル名ではなく、AIが作業前に同じ判断基準を読んでいる状態です。

03判断コアの作り方

この教材の中心はここです。

AIに自分のコピーを作ると言っても、文体だけを真似させても意味がありません。
文体は表面です。
本当に移植しないといけないのは、判断基準です。

03.01判断基準を移す

ここでいう判断コアは、「私はこういう人間です」と自己紹介を書く場所ではありません。
自分が実際に何を採用し、何を却下し、どこで保留し、どんな根拠を要求するのかを、AIが読める形にしたものです。

私のVaultにも判断コアがあります。
ただし、その中身をそのまま公開することはしません。
個別の判断ログや具体的な文脈は、その人の事業や関係者に紐づくからです。
ここでは、構造だけを取り出します。

作り方は、次の順番です。

最初に、行動ログを集めます。

03.02採用と却下を集める

自分が過去に「採用」と言ったもの、「却下」と言ったもの、「これは違う」と差し戻したもの、「ここは良い」と言ったものを集めます。
チャットログ、メモ、WORK_LOG、過去の制作物へのコメント、SNS投稿、修正履歴。
材料はきれいでなくていいです。
むしろ、汚いままのログの方が判断の癖が出ます。

次に、そのログを三つに分けます。
採用ログ。
却下ログ。
保留ログ。

採用ログには、「なぜそれを良いとしたのか」を書きます。
速かったからなのか、構造が通っていたからなのか、文体が合っていたからなのか、現実で使える粒度だったからなのか。

却下ログには、「何が地雷だったのか」を書きます。
煽りすぎたのか、根拠が薄かったのか、こちらの文脈を消したのか、言葉だけ誠実そうで行動が伴っていなかったのか。

03.03保留理由を残す

保留ログには、「何が足りなかったのか」を書きます。
情報不足なのか、本人確認が必要なのか、まだ一回限りの偶然なのか、比較対象がないのか。

この三つを分けるだけで、かなり見えてきます。
自分は何を嫌がるのか。
何があれば進めるのか。
どこで止まるのか。

次に、判断の優先順位を作ります。
難しい言葉で作る必要はありません。
どの条件が満たされていないと、他が良くても却下するのかを決めます。

ここで大事なのは、拒否権つきにすることです。
拒否権とは、一つでも触れたら止める条件のことです。

たとえば、文章案を見るとします。
読みやすい。
構成もきれい。
行動も起きそう。
でも、根拠のない断定が入っている。
この場合、読みやすさが高くても止める。

別の例です。
商品案としては売れそう。
でも、自分がやりたくない売り方になっている。
この場合も止める。

判断コアは、平均点を出すためのものではありません。
自分が絶対に超えてはいけない線を、AIに渡すためのものです。

汎用フォーマットは、次の形で十分です。

judgment-core.md

0. 判断の優先順位（拒否権つき）

最上位：絶対に破ってはいけない条件
・例：根拠のない断定をしない
・例：本人の文脈を消さない
・例：やりたくない売り方に寄せない

第2層：採用判断で重く見る条件
・例：現実で実行できる粒度か
・例：読者がそのまま真似できるか
・例：自分の強みと相性が良いか

第3層：調整で直せる条件
・例：言い回し
・例：見出し
・例：順番

判定
・最上位に違反：即却下
・第2層が弱い：保留または再設計
・第3層だけ弱い：修正して採用可

なぜ効くか。
AIは放っておくと「全体的に良いです」と言いがちです。
でも人間の判断には、一点でも触れたら止める条件があります。
そこを先に渡すと、採用、保留、却下が安定します。

次に、即時却下リストを作ります。
これは、迷わず捨てるものの一覧です。

03.04具体的な禁止に直す

ポイントは、抽象語で書かないことです。
「薄い文章はダメ」ではAIが分かりません。
「実績や根拠がないのに、必ず成果が出るように書く」なら分かります。

「ダサい表現はダメ」ではなく、「誠実さを宣言文でアピールする」「相手にNOを渡すだけの弱い締め方にする」のように、行動として書く。

即時却下リストの例はこうです。

即時却下リスト

根拠がない未来予測を断定する
本人の経験にない数字や体験談を作る
誠実さを行動ではなく宣言文で見せようとする
読者を煽って不安で動かす
一般論だけで、本人の文脈に戻ってこない
曖昧な指示を、確認なしに恒久ルールへ変える
出力をきれいにするために、重要な前提を削る

なぜ効くか。
却下条件を行動で書くと、AIが検査できます。
抽象語のままだと「たぶん大丈夫です」で通ってしまうため、具体的な禁止行動にします。

これは、あなた用に書き換えてください。
このリストに正解はありません。
あなたが過去に本当に嫌だったもの、実際に差し戻したもの、二度とやりたくないものを入れます。

次に、承認パターンを作ります。
「何があればOKなのか」です。
人は却下理由は覚えていても、採用理由は曖昧になりがちです。
でも、AIには採用理由も必要です。

承認のパターン

・抽象論ではなく、実際の手順に落ちている
・使う人が、次に何を作ればいいか分かる
・強い言葉を使わなくても、構造で説得している
・本人の経験と、読者の実行可能性が両方残っている
・判断保留の場所が、保留として明示されている

なぜ効くか。
却下条件だけだと、AIは減点を避けるだけになります。
承認パターンも渡すと、何を満たせば採用に近づくのかが見えます。

次に、保留ルールを作ります。
保留は、弱さではありません。
むしろ、判断コアで一番大事な部分の一つです。

AIは、何かを聞かれると答えたくなります。
でも、人間の判断では「まだ決めない」が正解の場面があります。
材料が足りない。
本人確認が必要。

03.05未確認は保留にする

相手の事情が分からない。
数字の根拠がない。
一回だけの反応で、まだ信号とは言えない。

これを保留として書きます。

保留のルール

・実体験か推測か分からない数字は、本人確認に回す
・顧客や他者が関係する内容は、公開前に固有情報を確認する
・一回だけの成功は、再現性ありと扱わない
・最新情報・価格・仕様は、確認するまで断定しない
・判断基準同士が衝突したら、上位の拒否権を優先する

なぜ効くか。
保留ルールがないと、AIは足りない材料をそれらしく補います。
決めない条件を先に渡すと、確認が必要なものを確認として残せます。

最後に、本人確認の5問を作ります。
これは、AIが自分の判断コアを作ったあとに、人間へ確認するための質問です。

私は、この5問がかなり重要だと思っています。
AIだけで判断コアを作ると、それっぽい自己分析になりやすいからです。
本人が「いや、そこじゃない」と言える問いが必要です。

本人確認の5問

このAIがあなたの代わりに却下していいものは何ですか？
逆に、あなた本人の確認なしに進めてはいけないものは何ですか？
速度と品質が衝突したとき、どの領域では速度を優先しますか？
どんな表現・売り方・判断をされると、「自分ではない」と感じますか？
過去の失敗から、AIに二度と繰り返してほしくないことは何ですか？

なぜ効くか。
AIが作った判断コアは、本人確認を通さないと一般論に寄ります。
この5問で、AIに任せる範囲と、人間が必ず見る範囲を分けられます。

ここまでやると、AIへの指示が変わります。
「私っぽく書いて」ではなく、こう言えるようになります。

この出力を、judgment-core.md の判断基準に通してください。
拒否権に触れる箇所、保留にすべき箇所、修正で採用できる箇所に分けてください。

なぜ効くか。
「私っぽく」はAIにとって曖昧です。
判断基準のファイル名と見る項目を指定すると、AIは雰囲気ではなく、採用・保留・却下の基準で見られます。

この一文が使えるようになると、AIはただの文章生成ツールではなくなります。
自分の判断基準を通すフィルターになります。

▼ここで手を動かす

ここでは、判断コアを自分で完成させなくて大丈夫です。
過去の採用、却下、保留の材料を貼って、AIに初稿を作らせてください。

私の判断コアの初稿を作ってください。
分類と文章化はあなたが行ってください。
構成は、判断の優先順位、即時却下リスト、承認のパターン、保留のルール、本人確認の5問にしてください。
私の経験にない数字や体験談は作らないでください。
不明なところは「要確認」と書いてください。
ここから材料です。
採用した例：
却下した例：
保留した例：
AIに二度とやってほしくないこと：
自分が大事にしたい売り方：
速度を優先してよい作業：
必ず自分で確認したい作業：

なぜ効くか。
判断コアは、自己紹介ではなく採否の記録から作る方が強いです。
実例を渡すと、AIが「何を止め、何を通すか」に変換できます。

04外部記憶の設計

判断コアを作ったら、次は外部記憶を作ります。

外部記憶というと、大きなデータベースを想像するかもしれません。
でも、最初はMarkdownファイルで十分です。
Markdownは、見出しと本文だけで書ける普通のテキストファイルです。
むしろ、最初から複雑な仕組みにすると続きません。

04.01外部記憶を作る

私のVaultでは、外部記憶の中心に self/ があります。
ここには、自分の役割、目標、方法論を置いています。
加えて、失敗と再発防止を記録する WORK_LOG.md があります。

汎用化すると、最小構成は4ファイルです。

self/identity.md
self/goals.md
self/methodology.md
WORK_LOG.md

identity.md は、AIに渡す自己定義です。
ここには、肩書きだけを書くのではありません。
自分が何者として動いているのか、どんな活動領域を持っているのか、どんなツールを使っているのか、どんな判断ベースラインを持っているのかを書きます。

汎用の型はこうです。

Identity

役割：私は何者として仕事をしているか。
例：一人事業者、現場職、発信者、商品制作者など。

活動領域：今扱っている領域。
例：現場業務、AI活用、記事制作、商品設計など。

判断のベースライン：判断するときに優先する軸。
例：速度を重く見る、ただし根拠のない断定はしない。

使用ツール：AI、ノート、コード、業務ツールなど。

この記憶群の目的：このファイル群が何のためにあるか。

なぜ効くか。
肩書きだけでは、AIは判断できません。

04.02役割ごとに分ける

役割、活動領域、判断の軸、使う道具を分けると、AIが「誰として動くか」を読みやすくなります。

goals.md は、今の目標です。
ここで大事なのは、夢や願望を書くことではありません。
AIが「今、何を優先すべきか」を判断できる状態にすることです。

汎用の型はこうです。

Goals

最優先（今週）：今週、最も優先する作業。

進行中：止めてはいけない案件。

完了：すでに閉じたもの。
AIが何度も提案しないようにする。

任意タスク：時間があれば進めるもの。

バックログ：まだ優先度が決まっていないもの。

なぜ効くか。
目標が混ざっていると、AIは終わった話を何度も出したり、今やるべきでない提案をします。
今週、進行中、完了、任意、未整理を分けるだけで、会話の焦点が合います。

methodology.md は、意思決定フレームです。
ここには、自分がどう考えるかを書きます。

04.03判断の癖を書く

たとえば、「個人の努力ではなく構造で説明する」「優劣ではなく相性で見る」「作り直しを減らすために、先に範囲を決める」のような判断の癖です。

ここは、きれいな哲学にしなくていい。
むしろ、作業中に使えるチェックリストにします。

Methodology

思考フレーム：構造で説明する、相性で判断する、速度を重く見る、固定ルールにしすぎない。

作業フロー：人間が方向を決める、AIが作業する、AIの出力を判断コアで検査する、ミスはWORK_LOGに戻す。

完了条件：成果物が指定場所にある、指示外の作業をしていない、保留事項が明示されている。

なぜ効くか。
AIは、作業の速さだけを見ると勝手に進めすぎます。
考え方、作業の順番、完了条件を渡すと、速さと確認の境目を揃えられます。

WORK_LOG.md は、失敗をルールに変える場所です。
ここだけは、きれいな成功記録ではありません。
むしろ、ミスを書くためのファイルです。

外部記憶で一番よくないのは、AIに毎回「完璧な自分」だけを読ませることです。
それではコピーになりません。

04.04失敗を次回に戻す

自分がどこでズレたか、AIがどこで失敗したか、人間が何を差し戻したか。
ここを残すから、次の判断が変わります。

そして、この4ファイルを CLAUDE.md の起動時必読リストに入れます。

起動時に読む外部記憶

self/identity.md
self/goals.md
self/methodology.md
WORK_LOG.md
rules/judgment-core.md

なぜ効くか。
読む順番を決めると、AIが毎回の会話だけで判断しなくなります。
誰として動くか、今どこへ向かっているか、どう判断するか、過去に何を避けるかの順番で始められます。

AIは、毎回のチャットだけであなたを理解するわけではありません。
毎回読むファイルによって、あなたの続きから始められるようになります。

ここまで作ると、AIに対する指示が短くなります。

この作業フォルダの起動時必読を読んだ前提で、この教材の本文を書いてください。

なぜ効くか。
前提をファイル側に移しておくと、毎回の依頼文が短くなります。
依頼文が短くなっても、AIが読む前提は減らないので、出力のズレが減ります。

ただし、注意点があります。
外部記憶は、増やすほど良いものではありません。
毎回読むファイルが増えすぎると、AIの文脈が重くなります。
だから、起動時に必ず読むものと、必要時だけ検索するものを分けます。

起動時に読むのは、自分の核と今の作業軸だけ。
過去ログや大量の素材は、必要なときに引く。
この主従関係を崩さないことです。

▼ここで手を動かす

ここでは、4ファイルを自分で書き切らなくて大丈夫です。
自分の仕事と今の目標を貼って、AIに空欄つきの初稿を作らせてください。

私の外部記憶4ファイルの初稿を作ってください。
ファイルは、identity.md、goals.md、methodology.md、WORK_LOG.mdです。
完成版ではなく、空欄と要確認を残したスターターにしてください。
事実や数字は作らないでください。
ここから私の状況です。
私の仕事：
今扱っている領域：
今週の最優先：
進行中の案件：
判断で大事にしたいこと：
過去に繰り返したくない失敗：
AIに毎回読ませたいこと：

なぜ効くか。
空欄つきで作ると、読者がいきなり完成版を目指さなくて済みます。
AIに「要確認」を残させることで、作ってよい情報と本人確認が必要な情報が分かれます。

05自己改善ループ

自分のコピーを作るうえで、判断コアと外部記憶だけではまだ足りません。
なぜなら、AIは一度作って終わりではないからです。

運用していると、必ずズレます。
言い回しが違う。
判断が浅い。
勝手に要約する。
確認すべきところを確認しない。
一般論に逃げる。

05.01ズレを直す仕組み

このズレを、その場の注意で終わらせると、また起きます。
だから、ミスを規律に変える流れを作ります。

私のVaultには、自己改善ループの仕組みがあります。
構造としては、reflection と triage の2段階です。
reflection は、何が起きたかを所見として残すことです。
triage は、その所見を本当にルール化するか仕分けることです。

これを一般化すると、流れはこうなります。

05.02改善の流れを決める

失敗・差し戻し
↓
reflection：何が構造的に失敗したかを所見化する
↓
triage：本当にルール変更すべきか分類する
↓
draft：最小の変更案を作る
↓
human approval：人間が採用するか決める
↓
CLAUDE.md、rules、WORK_LOGに反映する

なぜ効くか。
ミスを見つけたAIに、そのまま本体を書き換えさせると、一回の失敗を大きなルールにしすぎることがあります。
所見、仕分け、変更案、人間承認を分けると、過剰なルール化を防げます。

実際にAIへ渡すreflection用の指示は、次の形で足ります。

直前の差し戻しをreflectionとして整理してください。
対象ファイルは変更しないでください。
次の4点だけを書いてください。
1. 何が起きたか
2. 証拠になる出力や差し戻し内容
3. 構造的な原因
4. ルール化するなら最小変更は何か
出力先は、所見用の一時メモにしてください。

なぜ効くか。
「対象ファイルは変更しない」と明記すると、AIが反省しながら勝手に本体を直すのを防げます。
まずは何が起きたかを記録するだけに絞るのが安全です。

置き場所は、本文ではなく一時メモの下に分けます。
開発をしない人は、ここは「改善メモ置き場」と読み替えてください。
名前は何でもいいですが、役割は分けます。

・findings：所見だけを書く場所
・drafts：採用する場合の変更案を書く場所

findings には所見だけを書きます。
見出しは、たとえば次の形です。

finding: 短い名前

何が起きたか

証拠

構造的な原因

最小変更案

なぜ効くか。
所見だけを別にすると、ミスが起きた瞬間の勢いで本体ルールを増やさずに済みます。
証拠と原因を分けることで、ただの感想も混ざりにくくなります。

drafts には、採用する場合の変更案を書きます。
見出しは、たとえば次の形です。

draft: 短い名前

変更対象

変更しないもの

追加するルール文

検証方法

なぜ効くか。
変更する内容だけでなく、変更しないものも書くと、修正範囲が広がりすぎません。
検証方法まで置くと、そのルールが本当に効いたかを見直せます。

ここで大事なのは、AIに勝手に本体を直させないことです。

反省したAIが、そのままルールを書き換える。
これは一見便利ですが、危ないです。

05.03一度の失敗を広げすぎない

なぜなら、一回のミスを過剰に一般化してしまうからです。

たとえば、ある文章で「見出しが多すぎる」と差し戻されたとします。
そこでAIが「見出しは禁止」とルール化したら、次に必要な見出しまで消えます。
これは改善ではありません。
一回の反省を固定ルールにしすぎています。

だから、自己改善ループでは役割を分けます。

reflection は、所見を書く係です。
対象ファイルは改変しません。
「何が起きたか」「どの証拠があるか」「構造的な原因は何か」「最小の変更は何か」を、所見として出します。

triage は、所見を分類する係です。
証拠があるのか。
範囲は明確か。
本当にルール変更が必要か。
既存の別ルールと重複していないか。
ここを見ます。

分類は、だいたい4つで足ります。
ACCEPT は、証拠があり、最小変更が必要なもの。
REJECT は、証拠が弱いか、変更すると悪影響があるもの。
NEEDS_EVIDENCE は、ありそうだが材料が足りないもの。
DUPLICATE は、すでに別のルールで扱っているもの。

draft は、採用候補の変更案です。
ここでも、まだ本体は直しません。
どのファイルを変えるか、何を変えないか、検証方法は何かまで書いた提案にする。

最後に、人間が承認します。
ここで初めて、CLAUDE.md、rules/、WORK_LOG.md に反映します。

この順番が大事です。
ミスが起きる。
AIが反省する。
でも、AIが勝手に人格を書き換えない。
人間が採用したものだけが、次回以降の規律になる。

自分のコピーを作るというのは、AIを放置して自動進化させることではありません。
人間が承認した学習だけを、次の自分に戻すことです。

05.04失敗を教材に変える

この仕組みがあると、失敗の意味が変わります。
失敗がただの失敗で終わらない。
次回からAIが避けるべきルールになります。

一人事業では、これがかなり効きます。
誰かが教育係をしてくれるわけではないからです。
自分で失敗し、自分で直し、自分で仕組みに戻す。
その流れをAIとファイルで作る。

これが、自己改善ループです。

▼ここで手を動かす

ここでは、改善ループを自分で設計しなくて大丈夫です。
直近の差し戻しや、AIがズレた場面を貼ってください。

直近のAIのズレを、自己改善ループに乗せる形へ整理してください。
まだ本体ファイルは直さない前提で、reflection、triage、draft、人間承認の順に分けてください。
一回の失敗を大きく一般化しすぎないようにしてください。
ここから材料です。
何が起きたか：
実際の出力や差し戻し：
こちらが期待していたこと：
繰り返し起きているか：
ルールにするなら避けたい過剰反応：

なぜ効くか。
ミスの直後は、強いルールを作りたくなります。
AIに所見、分類、変更案、人間承認へ分けさせると、必要な学習だけを戻しやすくなります。

06失敗記録の運用

WORK_LOGは、ただの反省ノートではありません。
AIに読ませるための失敗記録です。

人間向けの反省ノートなら、「次から気をつける」で終わってもいいかもしれません。
でも、AIに渡すなら、それでは弱い。
AIが次回同じ場面で使えるように、形式を決めます。

基本形はこれです。

日付・テーマ

何を間違えたか：実際に起きたズレを書く。
感情ではなく、行動として書く。

原因：なぜそのズレが起きたか。
個人の能力や気分ではなく、構造で書く。

再発防止ルール：次回AIが何をすれば避けられるかを書く。
「気をつける」ではなく、実行できる文にする。

適用範囲：どの作業に適用するか。
逆に、どこには適用しないか。

なぜ効くか。
AIは「気をつける」を実行できません。

06.01失敗記録の型

行動、原因、再発防止、適用範囲に分けると、次回の作業前に使えるルールになります。

この形にしておくと、AIが読んだときに使えます。

ここでは、実際のVaultにある失敗記録の形式を元に、固有情報を抜いた例を2つ出します。
中身は教材用に一般化しています。

一つ目は、曖昧な指示を勝手に補完した失敗です。

曖昧な指示を、確認なしに処理した

何を間違えたか：ユーザーが「これを記憶して」「いい感じにして」と言ったとき、対象、保存先、適用範囲を確認せずに処理した。
その結果、どこまで恒久ルールにしていいのかが曖昧なまま進んだ。

原因：指示の不足を、AI側が推測で埋めた。
軽い作業なら問題にならないが、記憶、保存、ルール化のように後へ残る作業では危険だった。

再発防止ルール：「これ」「それ」「記憶して」「いい感じに」「任せる」などの曖昧語があり、保存先、対象、適用範囲が不明な場合は、実行前に確認する。
リスクが低く作業を止めない場合でも、「私はAをBと解釈します」と前提を明示してから進める。

適用範囲：記憶、ファイル編集、恒久ルール化、公開物の作成に適用する。
軽い一時的な整形には、最終報告で前提を共有すればよい。

なぜ効くか。
曖昧な指示をそのまま恒久ルールにすると、次回以降の判断までズレます。

06.02残す前に範囲を見る

対象、保存先、適用範囲を確認する形にしておくと、残してよいものだけを残せます。

二つ目は、質問をそのまま受けて、一段上の問いに変えなかった失敗です。

問いをそのまま処理し、判断を前に進めなかった

何を間違えたか：ユーザーが「どうしたらいい？」と聞いたとき、表面の質問にだけ答えた。
本当は、より良い判断や実行につながる問いへ変換できたのに、それをしなかった。

原因：回答を急ぎすぎて、問いの目的を確認しなかった。
ユーザーが欲しいのは説明ではなく、次の判断を良くすることだった。

再発防止ルール：回答前に「この問いは、より良い判断・実行につながる形へ一段上げられるか？」を確認する。
より良い問いがある場合は、「もっと良い問いにするとこうです：『...』」を短く提示してから、元の意図に答える。
ただし、単純実行や緊急性の高い作業では長くしない。

適用範囲：相談、判断、設計、記事構成、商品設計に適用する。
明確な実行指示には、作業を止めすぎない。

なぜ効くか。

06.03問いを一段上げる

問いを少し上げるだけで、AIの返答は作業手順から判断材料へ変わります。
ただし毎回長く止めると邪魔なので、適用範囲も一緒に書きます。

この2つを見ると分かります。
WORK_LOGは、失敗談を面白く書く場所ではありません。
次回のAIが使えるように、行動ルールへ変換する場所です。

ここでも、サニタイズが必要です。
サニタイズとは、公開してはいけない固有情報を抜くことです。
顧客名、取引先名、メールアドレス、実パス、未公開の商品計画、売上目標、具体的な導線名は入れない。
公開教材にするなら、必ず汎用例へ置き換えます。

ただし、構造は残します。
何を間違えたか。
原因。

06.04使えるルールにする

再発防止ルール。
適用範囲。

この4つが残っていれば、失敗は教材になります。

▼ここで手を動かす

ここでは、失敗記録を自分で整えなくて大丈夫です。
直近の失敗や差し戻しを貼って、AIにWORK_LOGの形へ変換させてください。

直近の失敗を、AIに読ませるWORK_LOG形式へ変換してください。
感情の反省ではなく、次回AIが使える行動ルールにしてください。
形式は、何を間違えたか、原因、再発防止ルール、適用範囲です。
顧客名、メールアドレス、実パス、未公開の商品計画など、固有情報は汎用表現へ置き換えてください。
ここから材料です。
起きたこと：
実際に困ったこと：
差し戻した内容：
次回避けたいこと：
どの作業に適用したいか：

なぜ効くか。
失敗をただ保存しても、AIは次回に使えません。
行動ルールと適用範囲に変換すると、同じ場面で読み返せる記憶になります。

07導入7段階

ここまで読むと、全部を一気に作りたくなるかもしれません。
でも、いきなり全部自動化すると壊れます。

AIに自分のコピーを作る作業は、順番が大事です。
最初からフック、自動要約、週次レビュー、複数のAIまで入れると、何が効いているのか分からなくなります。

07.01全部を一気に作らない

導入は7段階で考えます。

第1段階は、CLAUDE.md を作ることです。
ここには、AIが毎回読む起動ルールを書きます。
言語、作業の進め方、読むべきファイル、やってはいけないこと、出力形式。
最初は短くていいです。
重要なのは、毎回同じ入口から始めることです。

最小例はこうです。

CLAUDE.md

最初に読むファイル

self/identity.md
self/goals.md
self/methodology.md
WORK_LOG.md
rules/judgment-core.md

言語
回答は日本語。

作業規律
既存ファイルを勝手に上書きしない。
曖昧な指示は前提を明示する。
判断に迷ったら保留する。

なぜ効くか。
入口がないと、AIは毎回その場の依頼だけで動きます。
最初に読むファイルと作業規律を置くことで、毎回同じ前提から始められます。

07.02声と禁止を決める

第2段階は、文体と出力ルールを作ることです。
ここでは、あなたの文章の声、禁止表現、改行、見出し、読者との距離感を書きます。
ただし、文体ルールを機械的にしすぎない。
「必ず2文ごとに文末を変える」のような固定ルールは、逆に不自然になります。
読者とどの距離で話すのか、何を避けるのかを中心に書きます。

第3段階は、判断コアを作ることです。
これは先ほどの章で書いた通りです。
ログを集め、採用、却下、保留に分け、判断の優先順位、拒否権、即時却下リスト、本人確認5問に落とします。
この段階で、AIはただの作業者から判断補助に変わります。

第4段階は、外部記憶を4ファイルに分けることです。
identity.md、goals.md、methodology.md、WORK_LOG.md。
最初はこれだけでいい。
この4つがないまま高度な自動化に進むと、AIは毎回ふわっとした一般論に戻ります。

07.03記憶の置き場を分ける

第5段階は、Vaultやフォルダを4層化することです。
原本、整理済み知識、最近の文脈、自分の核を分けます。
名前は raw / wiki / digest / identity でもいいし、自分の運用に合わせた名前でもいい。
大事なのは、原本と確定ルールを混ぜないことです。

既存メモを振り分けるときは、まだ材料のままなら原本層に置きます。
何度も使う知識なら整理済み知識、今週の作業に関わるなら最近の文脈です。
判断基準、禁止ライン、文体の核は、自分の核として扱います。

第6段階は、起動時・終了時のループを作ることです。
ここで初めて、自動化を入れます。
起動時に必読ファイルを読む。
終了時や定期タイミングで、ミスや差し戻しを拾う。
ただし、最初からフル自動で本体を書き換えない。
所見と提案までに止め、人間承認を挟みます。

07.04週に一度見直す

第7段階は、週次の棚卸しを入れることです。
週に一度、次のような問いを見ます。

・先週、AIが繰り返したミスは何か
・WORK_LOGに戻すべきものはあるか
・goals.mdは今の状態とズレていないか
・judgment-core.mdに追加すべき拒否権はあるか
・逆に、過剰に固定しすぎたルールはないか

なぜ効くか。
週次で見ると、ミスを一回の感情でルール化しにくくなります。
繰り返したもの、今の目標からズレたもの、固定しすぎたものを分けて見直せます。

ここまで来ると、AIはかなり「自分の続き」から動けるようになります。
でも、順番を飛ばさない方がいいです。

導入優先度を短く言うと、こうです。

CLAUDE.mdを作る
文体・出力ルールを作る
判断コアを作る
外部記憶4ファイルを作る
Vaultを4層化する
自己改善ループを入れる
週次棚卸しを入れる

最初のゴールは、AIがあなたを完全再現することではありません。
あなたが毎回説明していたことを、ファイルに移すことです。

次のゴールは、AIがあなたの判断基準で出力を検査できることです。

その次のゴールは、ミスが起きたときに、それを次回の規律へ戻せることです。

07.057段階で始める

この順番で十分です。
派手ではないですが、実運用ではこれが強い。

▼ここで手を動かす

ここでは、7段階を自分で計画しなくて大丈夫です。
今どこまでできているかに印を付けて、AIに次の一歩へ変換させます。

今あるもの：

□ AIが毎回読む入口
□ 文体や出力ルール
□ 判断コア
□ identity / goals / methodology / WORK_LOG
□ 原本と確定ルールの置き場分け
□ ミスを所見化する流れ
□ 週次で見直す時間

私の導入状況を、7段階に沿って整理してください。
できているもの、足りないもの、次に1つだけ作るものに分けてください。
最初から自動化しすぎない前提で、今日やる作業を1つに絞ってください。
最後に、今日作るファイルの見出しだけを出してください。
ここから私の状況です。
今あるもの：
まだないもの：
AIに毎回説明していること：
直近で困っているズレ：
今日使える時間：

なぜ効くか。
7段階を全部やろうとすると止まります。
AIに「今日やる1つ」へ絞らせると、導入が知識ではなく作業になります。

08特典案内

この教材は、読むだけでは意味が薄いです。
実際に自分の環境へ移すところまでやって、初めて効きます。

そのために、特典は3つに分けました。

08.01環境へ移す準備

一つ目は、CLAUDE.md の最小スターターです。
このVaultで使っている起動時必読リスト、言語ルール、作業規律の構造を、汎用化した雛形にしています。
いきなり巨大な設定ファイルを作る必要はありません。
まずは、AIが毎回同じ入口から始められる状態を作ります。

二つ目は、判断コア作成質問セットです。
判断の優先順位、拒否権、即時却下リスト、本人確認5問を、自分で埋められるようにした質問集です。
ここを埋めると、AIに「私っぽく」ではなく、「この基準で採用、却下、保留して」と言えるようになります。

三つ目は、外部記憶テンプレ一式です。
identity.md、goals.md、methodology.md、WORK_LOG.md の4ファイルを、空欄と記入例つきでまとめています。
最初から完璧に書く必要はありません。
まずは空欄を埋め、運用しながら更新していく形です。

08.02最小構成を作る

この3つがあれば、最小構成は作れます。

最初に CLAUDE.md を置く。
次に、外部記憶4ファイルを置く。
最後に、判断コアを作る。

この順番で進めてください。
迷ったら、特典1で入口を作り、特典3で外部記憶を置き、特典2で判断コアを埋める順番だけ守れば十分です。

▼ここで手を動かす

最後に、ここまでの材料を「判断基準ファイルの元」にまとめます。
完成させる必要はありません。
空欄と要確認が残っていて大丈夫です。

ここまでの内容を、私の判断基準ファイルの元としてまとめてください。
作るものは、CLAUDE.mdの最小スターター、judgment-core.mdの初稿、identity.md、goals.md、methodology.md、WORK_LOG.mdの初稿です。
事実や数字は作らないでください。
不明なところは「要確認」と書いてください。
最後に、今日から使う最初の一文を作ってください。
ここから私の材料です。
毎回AIに説明していること：
自分の仕事：
今の目標：
採用したい判断基準：
却下したい判断：
保留したい判断：
過去に繰り返したくない失敗：

なぜ効くか。
最後にファイル単位へまとめると、読んで終わりになりません。
入口、判断基準、自己定義、目標、方法論、失敗記録の元が残るので、次回のAI作業にそのまま渡せます。

付録A

09特典1_CLAUDEmd最小スターター

このファイルは、AIが毎回同じ入口から作業を始めるための CLAUDE.md 雛形です。
そのまま貼るのではなく、角括弧の部分を自分用に書き換えてください。

# CLAUDE.md

> このファイルは、AIが最初に読む作業ルールです。
> 毎回の説明を減らし、判断基準と作業規律を固定するために使います。

## 起動時に読む外部記憶

AIは新しい作業を始める前に、以下をこの順で読む。
読んだことを報告する必要はない。
読んだうえで、作業判断に反映する。

1. self/identity.md — 私の役割・活動文脈・使うツール
2. self/goals.md — 現在の目標・優先順位
3. self/methodology.md — 意思決定フレーム・作業の進め方
4. WORK_LOG.md — 過去のミスと再発防止ルール
5. rules/judgment-core.md — 採用・却下・保留の判断基準

## 言語ルール

- 回答は日本語で行う。
- ユーザーが英語で書いた場合のみ英語で返す。
- 公開物は、読み手と対等な目線で書く。
- 上から教えない。
- 下から媚びない。

## 作業規律

- 指示された範囲外の作業をしない。
- 既存ファイルを勝手に上書きしない。
- 保存先、対象、適用範囲が曖昧な場合は確認する。
- 推測で補って進める場合は、「私はAをBと解釈します」と明示する。
- 実行前に、何をどこまで作るかを確認する。
- 個人情報、顧客情報、未公開の事業情報を公開物に入れない。

## 判断の優先順位

1. safety：公開してはいけない情報を出さない。
2. judgment-core：私の採用・却下・保留基準に従う。
3. goals：今の目標と優先順位に合う作業をする。
4. methodology：構造的に説明し、一般論に逃げない。
5. speed：必要以上に重くしすぎず、動く形へ出す。

## 曖昧さの扱い

次の語があるときは注意する。

- これ
- それ
- いい感じに
- 任せる
- 記憶して
- 保存して
- あとで使えるように

対象、保存先、適用範囲、完了条件が不明な場合は、作業前に確認する。
軽い作業で止めない場合でも、補った前提を最終報告に残す。

## 出力前チェック

- 指示されたファイルだけを作ったか。
- 既存ノートを上書きしていないか。
- 個人情報や未公開情報を入れていないか。
- 判断コアの拒否権に触れていないか。
- 一般論ではなく、実行できる粒度になっているか。
- 保留事項があれば明示したか。

## 完了報告

作業が完了したら、次の形式で報告する。

DONE: created=<作成数> updated=<更新数> skipped=<スキップ数>
files:
- <path>
notes:
- <サニタイズした内容>
- <判断保留事項>

10最初に作るフォルダ構成

my-ai-copy/
├── CLAUDE.md
├── rules/
│   └── judgment-core.md
├── self/
│   ├── identity.md
│   ├── goals.md
│   └── methodology.md
└── WORK_LOG.md

11使い方

上の CLAUDE.md 雛形を自分の作業フォルダへ置く。
self/ と rules/ を作る。
まずは空ファイルでもいいので、起動時必読リストの参照先を用意する。
1週間使い、毎回説明していることを CLAUDE.md か self/ に移す。
AIがミスしたら、注意で終わらせず WORK_LOG.md に戻す。

12注意

CLAUDE.md は長ければ良いわけではありません。
最初は短く作り、運用で本当に必要になったものだけ足してください。

付録B

13特典2_判断コア作成質問セット

この質問セットは、AIに渡す judgment-core.md を作るためのものです。
目的は、自己紹介を書くことではありません。
あなたが何を採用し、何を却下し、どこで保留するかを、AIが使える形にすることです。

141. 行動ログ抽出

次の材料を集めてください。

過去に採用した文章、企画、提案
過去に却下した文章、企画、提案
差し戻したAI出力
「これは違う」と感じた出力
「これは良い」と感じた出力
失敗後に作ったルール
何度も説明している注意点

集めたら、次の3列に分けます。

採用ログ：なぜOKだったか
却下ログ：何が地雷だったか
保留ログ：何が足りず判断できなかったか

152. 評価関数の階層を作る質問

次の問いに答えてください。

どれだけ他が良くても、これを破ったら即却下する条件は何ですか？
採用判断で一番重く見る条件は何ですか？
修正すれば採用できる軽いズレは何ですか？
速度を優先してよい領域はどこですか？
速度より確認を優先すべき領域はどこですか？
AIが「良いです」と言っても、あなたが信用しない出力はどんなものですか？
あなたが「これは自分ではない」と感じる判断は何ですか？

書き出したら、次の型へ入れます。

## 評価関数の階層（拒否権つき）

最上位：拒否権
- 
- 
- 

第2層：採用判断で重く見る条件
- 
- 
- 

第3層：修正で直せる条件
- 
- 
- 

判定ルール
- 最上位に違反：即却下
- 第2層が弱い：保留または再設計
- 第3層だけ弱い：修正して採用可

163. 即時却下リストを作る質問

次の問いに答えてください。

過去に「二度とやらない」と思った表現は何ですか？
AIがよく出してくるが、自分の売り方と合わないものは何ですか？
読者や顧客に対して、絶対に使いたくない煽りは何ですか？
根拠がないのに断定されると困る領域はどこですか？
自分の体験として書かれると困るものは何ですか？
「きれいだけど薄い」と感じる出力には、どんな共通点がありますか？
公開前に必ず人間確認へ回すべき情報は何ですか？

型はこうです。

## 即時却下リスト

1. 
2. 
3. 
4. 
5. 
6. 
7.

174. 承認パターンを作る質問

次の問いに答えてください。

過去に採用した出力は、何が良かったですか？
読者がそのまま動ける出力には、何が入っていますか？
あなたの経験が残っている文章には、どんな特徴がありますか？
逆に、一般論へ逃げていない出力には何がありますか？
あなたが「これは使える」と判断する最低条件は何ですか？

型はこうです。

## 承認のパターン

- 
- 
- 
- 
-

185. 保留ルールを作る質問

次の問いに答えてください。

AIだけで判断してはいけない領域はどこですか？
最新確認が必要なものは何ですか？
顧客・他者・取引先に関わる情報は、どう扱いますか？
数字・実績・体験談は、どこまで確認しますか？
一回だけの成功を、再現性ありと扱わないための条件は何ですか？
判断基準同士が衝突したとき、どれを上位にしますか？

型はこうです。

## 保留のルール

- 
- 
- 
- 
-

196. 本人確認の5問

AIに判断コアの草案を作らせたら、最後に必ず本人確認をします。

1. このAIがあなたの代わりに却下していいものは何ですか？
2. あなた本人の確認なしに進めてはいけないものは何ですか？
3. 速度と品質が衝突したとき、どの領域では速度を優先しますか？
4. どんな表現・売り方・判断をされると、「自分ではない」と感じますか？
5. 過去の失敗から、AIに二度と繰り返してほしくないことは何ですか？

207. 完成形テンプレ

# judgment-core.md

## 目的
このファイルは、AIが私の基準で採用・却下・保留を判断するためのもの。

## 評価関数の階層（拒否権つき）

## 即時却下リスト

## 承認のパターン

## 保留のルール

## 根拠への要求水準

## 説明・撤退の様式

## 本人確認が必要な領域

## 更新ルール
ミスや差し戻しが起きたら、WORK_LOGに記録し、人間承認後にこのファイルへ反映する。

付録C

21特典3_外部記憶テンプレ一式

このファイルは、AIに毎回読ませる外部記憶4ファイルの雛形です。
self/identity.md、self/goals.md、self/methodology.md、WORK_LOG.md を作るときに使ってください。

22フォルダ構成

my-ai-copy/
├── CLAUDE.md
├── self/
│   ├── identity.md
│   ├── goals.md
│   └── methodology.md
├── rules/
│   └── judgment-core.md
└── WORK_LOG.md

23self/identity.md

# Identity — [あなたの名前または活動名]

## 役割

私は、[何者として仕事をしているか]。

記入例：
私は、一人で事業を進めている個人事業主。
現場業務、発信、商品制作、AI活用を、自分の判断で進めている。

## 活動領域

- [領域1]
- [領域2]
- [領域3]

記入例：
- 現場業務
- AI活用
- 記事制作
- 商品設計

## 判断のベースライン

私は、判断するときに次を重く見る。

- [判断軸1]
- [判断軸2]
- [判断軸3]

記入例：
- 一般論ではなく、自分の文脈に合うかを見る
- 根拠のない断定を避ける
- 迷ったときは、実行できる最小単位に落とす

## 使用ツール

- [AIツール]
- [ノートツール]
- [業務ツール]
- [制作ツール]

記入例：
- ChatGPT / Claude / Codex など
- Obsidian
- Google Drive
- エディタ、ブラウザ、表計算ツール

## この記憶の役割

このファイルは、AIが私を毎回ゼロから理解し直さなくて済むようにするためのもの。
肩書きではなく、活動文脈と判断の入口を書く。

24self/goals.md

# Goals — 現在の目標

## 最優先（今週）

- [今週の最優先]

状態：
[進行中 / 保留 / 完了]

完了条件：
[何ができたら完了か]

## 進行中

- [案件名または作業名]
  - 状態：
  - 次にやること：
  - 判断保留：

## 完了

- [完了した作業]
  - 完了日：
  - 再提案しないためのメモ：

## 任意タスク

- [時間があればやる作業]

## バックログ

- [優先度未確定の作業]

## 更新ルール

週に1回、または大きな方針変更があったときに更新する。
AIは、古い目標を前提に提案しない。

25self/methodology.md

# Methodology — 意思決定フレーム

## 判断の原則

私は、次の順番で考える。

1. 何を達成したいのかを確認する
2. 動かせるものと動かせないものを分ける
3. 個人の努力ではなく、構造で原因を見る
4. 自分の文脈と相性が良いかを見る
5. 実行できる最小単位へ落とす

## AIに期待する役割

AIには、次の役割を期待する。

- 情報整理
- 文章化
- 構造化
- 判断補助
- ミスの再発防止

AIに期待しないこと。

- 私の代わりに最終判断すること
- 未確認の数字や体験談を作ること
- 公開してはいけない情報を出すこと
- 一般論で押し切ること

## 作業フロー

方向を決める → AIに作業を渡す → 出力を判断コアで検査する → 採用・修正・保留・却下に分ける → ミスはWORK_LOGへ戻す

## 完了条件

AIは、作業完了時に次を確認する。

- 指定された成果物がある
- 指示範囲を超えていない
- 判断保留が明示されている
- 個人情報や未公開情報が混ざっていない
- 次回へ戻すべき学びがあればWORK_LOG候補として出す

26WORK_LOG.md

# WORK_LOG — ミスと再発防止ルール

このファイルは、失敗を次回の規律へ変えるためのもの。
気持ちを書く場所ではなく、AIが次回使えるルールへ変換する場所。

---

## [日付] [テーマ]

### 何を間違えたか

[実際に起きたズレを書く]

記入例：
曖昧な指示に対して、対象・保存先・適用範囲を確認せずに進めた。

### 原因

[構造的な原因を書く]

記入例：
軽い作業のつもりで、後に残る記憶・ルール化の重さを区別しなかった。

### 再発防止ルール

[次回AIが実行できる文にする]

記入例：
「記憶して」「保存して」「いい感じに」のような曖昧語があり、後に残る処理を行う場合は、対象・保存先・適用範囲を確認する。

### 適用範囲

[どこに適用するか。どこには適用しないか]

記入例：
記憶、ファイル編集、公開物作成、恒久ルール化に適用する。
軽い一時整形では、作業を止めすぎない。

---

## [日付] [テーマ]

### 何を間違えたか


### 原因


### 再発防止ルール


### 適用範囲

27CLAUDE.mdに書く読み込み指定

## 起動時に読む外部記憶

1. self/identity.md
2. self/goals.md
3. self/methodology.md
4. WORK_LOG.md
5. rules/judgment-core.md

AIは、作業前に上記を読み、判断に反映する。
ただし、読んだことを毎回報告しなくてよい。

28運用ルール

空欄のままでもよいので、まず4ファイルを置く。
1週間使い、毎回説明していることを追記する。
ミスが起きたら、チャットで注意して終わらせず WORK_LOG.md に戻す。
目標が変わったら goals.md を更新する。
自分の判断基準が増えたら judgment-core.md に移す。
個人情報、顧客情報、未公開事業情報はテンプレに入れない。