AI秘書が育つのは、会話を重ねるからではなく仕事の型を残すから
Claude Codeに経験を引き継ぐための、記録と確認の小さな設計
「Claude Codeを毎日使っているのに、次の依頼ではまた最初から説明している」
このもどかしさ、よくわかります。
使った回数だけで、AIが自分の仕事を覚えてくれるわけではありません。
みのるんさんのスライド「Claude Codeを『使うほど育つ』AI秘書にするノウハウ」は、AIに仕事を任せる前に仕事場へ文脈を集め、相談しながら進め、うまくいった方法や失敗を設定に反映する考え方を紹介しています。
Speaker Deckのスライドは2026年9月17日公開で、全74枚です。
私も、Claude CodeとCodexを使い分け、依頼の計画・実装・レビューの役割をファイルに書いています。
Obsidian vault には、後から参照する知識と記事を置いています。
そこで感じているのは、AIに何かを「覚えさせる」より、次の仕事で参照する資料を整えるほうが効くということです。
この記事では、スライドで紹介されている考え方を私の運用に引きつけながら、明日から始められる残し方をまとめます。
先に結論
最初に渡すのは、きれいに整理した説明ではなく、目的・事情・資料の場所です
毎回使うルール、特定の仕事の手順、後から引き継ぐ記憶を分けて残します
AIに任せる工程と、人が判断する工程を先に決めます
うまくいかなかったら、その場の修正で終わらせず、次の依頼に使える形に直します
自動化の範囲は、やり直せる作業から広げます
この記事は次のような方に向いています
Claude Codeに毎回同じ背景を説明している
依頼のたびに、どこまで任せてよいか迷う
AIの出力を直して終わりにし、次も同じところで詰まる
この記事でわかること
仕事の文脈を置く場所の決め方
CLAUDE.md・メモリ・スキルに書く内容の例
任せる作業と、人が確認する作業の分け方
失敗や修正を次の仕事へ引き継ぐ手順
1. まず背景や事情を伝え、要点は一緒に整える
スライドでは、話の順序を整えてから渡す必要はないと説明されています。
まず背景や事情を伝え、AIに要点や提案の形へまとめてもらい、人が確認して決める流れです。
これは、依頼文を完璧にしてから送るより、判断に必要な材料を落とさず渡すことを優先する考え方だと思います。
何を作るかだけでなく、なぜ必要なのか、誰が使うのか、どこに資料があるのかも一緒に伝えます。
私がDiscord経由でClaude Codeに依頼するときも、計画と作業を分けています。
Claude Codeが依頼内容や関係ファイルを見て手順をまとめ、承認後にCodexへ作業を渡します。
最初に作業へ飛び込まず、背景・変更範囲・確認方法をそろえる運用です。
たとえば「議事録を作って」だけでなく、会議の目的や資料の場所も一緒に伝えます。
AIがまとめた決定事項を読み、内容が合ってから議事録に整えてもらいます。
最初の依頼は、箇条書きでなくても大丈夫です。
次の項目を、分かる範囲で声に出すか、文章にしてみてください。
何を終わらせたいか
それが必要になった経緯
誰が成果物を使うか
関係するファイルやリンクはどこか
変えてはいけないことは何か
どこで人の確認を入れたいか
話し終えてから、こう頼みます。
今話した内容を、目的・背景・関係資料・制約・未確認事項に分けて整理してください。
まだ作業は始めず、理解が合っているか私に確認してください。
資料が見つからない場合や、推測が含まれる場合は、そのまま明記してください。ここでのポイントは、情報をきれいに整えることではありません。
AIが何を知っていて、何を知らないかを人が確かめられる状態にすることです。
2. 「覚えて」ではなく、置き場所ごとに書く内容を決める
「次から覚えておいて」と頼むだけでは、何がどこに残ったのか分かりにくくなります。
後で使いたい情報を、役割ごとに置き分けると探しやすくなります。
Claude Codeの公式ドキュメントでは、CLAUDE.md は毎回必要なプロジェクトの約束事、Skills は必要なときに使う再利用可能な手順や知識として説明されています。
また、hooks は決まったイベントで動く自動処理に向いています。
機能の使い分け
ここからの5分類は、公式の分類やスライドの分類を再現したものではありません。
私が「いつ使う情報か」で整理した、記事独自の置き分けです。
スライドでは仕事場に置くものとして、CLAUDE.md、Rules、Skills、コネクタの4項目が挙げられています。
この4項目とは分けて、ここでは私の作業で使っているメモリや作業ログも含めて考えます。
CLAUDE.md: どの依頼でも守る役割、作業範囲、優先順位
メモリ: 長く参照する本人の好みや、繰り返し役立つ背景
Skill: 手順が決まっている繰り返し作業
作業ログ: 今回の目的、決定、未完了事項、次の一手
hookや設定: 毎回機械的に適用したい制御や処理
公式ドキュメントの説明に沿って、CLAUDE.md には「毎回守る約束」、Skillには「特定の場面で使う手順」を書きます。
長い説明や参照資料まで、すべて毎回の指示に詰め込む必要はありません。
私の執筆ワークスペースでは、CLAUDE.md に工程の担当を定めています。
執筆・推敲、確認、公開、記録の担当が分かれています。
記事の文体は style-profile.md、ひな形は templates/article.md に置いています。
毎回の依頼に記事の全ルールを貼り付けず、工程の担当は常時のルールで確認します。
文体やひな形は、記事を書くときにそれぞれのファイルを参照します。
たとえば文体を直したいときは、依頼文ではなく style-profile.md を更新します。
最初に作る CLAUDE.md は、次のような短い内容から始められます。
# この作業場について
- 目的: Webアプリの開発と保守
- 主な利用者: 私と開発チーム
- 作業前に読む: docs/overview.md
# 進め方
- 調査と実装を分ける
- 変更前に対象ファイルと確認方法を示す
- 依頼にないファイルは変更しない
# 人が判断すること
- 外部への送信、公開、削除は実行前に確認する
- 事実を確認できないときは推測で補わず、未確認と書く内容は、実際の仕事に合わせて変えてください。
重要なのは、きれいな設定を完成させてから始めることではありません。
何度も説明していることから1つ選び、次に使える場所へ移すことです。
置き場所に迷ったら、最近繰り返し説明したことを一つ選んでください。
それが毎回のルールか、特定作業の手順か、今回だけの進捗かを分けるところから始められます。
たとえば「回答には根拠のファイル名を付ける」は、調査依頼全般に関わるルールです。
「毎月の請求書を作るとき、先月の内容と照合する」は、特定の繰り返し作業の手順です。
「今は3社分の資料を確認し、残り1社は未確認」は、その日の進捗です。
同じ文章に詰めず、使う場面ごとに分けると、後で古くなった情報を見つけやすくなります。
3. 一度の修正を、次回の依頼に持ち越す
AIの出力が違ったとき、直して納品するだけで終わると、次回も同じ説明が必要になります。
その場の会話で修正することと、繰り返す仕事の手順を更新することは分けて考えます。
スライドでは、うまくいった流れやつまずきへの対処を残し、次の作業に活用する姿が紹介されています。
「コンテキストの複利」という表現も出てきます。
一度整理した情報が別の仕事でも使われ、説明を短くできるという考え方です。
ただし、何でも記録すればよいわけではありません。
その場限りの事情を恒久的なルールにすると、古い情報が残って判断を邪魔します。
記録する前に、同じ場面がまた起きるかを考えます。
私の自動メモリは、個別ファイルを「1ファイル1事実」にしています。
MEMORY.md には各ファイルへの索引を1行ずつ置き、必要な知識だけを探せる形です。
たとえば、ネットを使う調査をCodexに頼むときの起動方法を、次のように記録しています。
Codexにネットを使う調査を渡すときは --write で起動する。read-only だとネットが遮断される。
一度つまずいたことを、次の依頼で使える短いルールにした例です。
知識はObsidian vaultに置いています。
作業開始時に読むのは入口の map.md だけで、棚の中身は必要になったときに辿ります。
すべてを毎回読ませず、入口から必要な情報へ進む形です。
セッションの会話ログは /savechat でvaultの 5_agent_log/ に書き出します。
その日のやりとりを、長く使うルールや手順と同じ場所に混ぜないためです。
次のような依頼で、今回の学びを分類できます。
今回の作業を振り返ってください。
1. 今回だけの事情
2. 次回も使える手順
3. 毎回守るべきルール候補
4. まだ確認が必要なこと
それぞれに根拠となる会話やファイルを付けてください。
候補を挙げるだけにして、設定ファイルは変更しないでください。まず最近の作業を一つ選び、「次も使う手順」と「今回だけの事情」を二列に書き分けてみてください。
手順だけをSkillやルールの候補にし、今回だけの事情は作業ログに残します。
記録を更新するか迷ったとき
同じ説明や修正を繰り返した: ルールや手順にする候補です
その場限りの相手・日付・事情: 作業ログに残す候補です
一度しか起きていない例外: すぐ恒久ルールにせず、様子を見ます
何度も参照される長い資料: 毎回の指示から分け、必要なときに読む形を検討します
育つというのは、AIの能力が勝手に上がることではありません。
人が確認した経験を、次の仕事で参照できる形に変えることです。
4. 任せる工程と、人が決める工程を分ける
スライドでは、「人間 → AI → 人間」という型が示されています。
人が目的や背景を渡し、AIが情報を集めたり整えたりし、最後は人が確定します。
完成形を一度に作らせるのではなく、途中で確認を挟む進め方です。
私はこの考え方を、工程の受け渡しに使っています。
たとえば記事の執筆では、草稿を作る担当と、事実や書式を確認する担当を分けています。
レビューが終わるまでは公開工程へ進まない、という境界もファイルに明記されています。
役割分担を決めるときは、作業を「準備」「案を作る」「確定する」に分けると整理しやすいです。
準備: 資料を探す、情報を並べる、抜けを見つける
案を作る: 下書き、一覧、候補、手順を作る
確定する: 外部送信、申請、公開、削除、金額の確定
最初は、AIに準備と案作りを頼みます。
人が確定する操作は、文章で「気を付けて」と伝えるだけにせず、具体的な操作名で書きます。
申請フォームを入力するところまで進めてください。
送信ボタンは押さず、入力内容を一覧にして私に確認してください。
金額・日付・宛先は、元資料と照合できる根拠も示してください。公式ドキュメントは、権限設定やhooksなどの制御手段を案内しています。
一方で、スライド自身も「危ない操作を必ず聞いてくれる保証はない」と注意しています。
許可設定やモードの挙動は、利用環境と現行ドキュメントで確かめてください。
Claude Codeのhooks
指示文は大切ですが、重要な操作を文章だけで守れると思い込まないことも大切です。
実際に設定できる制御と、運用上の確認を組み合わせます。
まずは、次の依頼で人が確認する操作を一つ決め、送信や公開の直前で止める指示を書いてみてください。
5. 失敗を小さく試し、見直せる範囲を広げる
AIに任せる範囲を一気に広げると、間違いに気づく場所も増えます。
まずは、やり直しやすい作業で流れを確かめます。
結果を見てから、次に任せる工程を決めます。
たとえば、会議メモから議事録の下書きを作るなら、次の順番で試せます。
元のメモを渡して、決定事項と未決事項を分けてもらう
発言の根拠が分からない項目に印を付けてもらう
人が内容を確認してから、共有用の文章に整えてもらう
共有先へ送る作業は、慣れるまでは人が行う
ここで確認したいのは、文章が自然かどうかだけではありません。
決定事項の取り違えがないか、推測が事実のように書かれていないか、元の記録へ戻れるかも見ます。
私の作業ルールにも、確認できない内容を推測で埋めないことや、担当外の工程へ進まないことが入っています。
これは、AIの成果物だけでなく、作業の境界もレビューできるようにするためです。
失敗したら、原因と再発防止の候補を一緒に整理してもらいます。
候補を読んだら、次にも起きそうなものだけを一つ選び、次回使う場所へ移してください。
よくある失敗と対策
失敗1: 最初から全部の情報を整理して渡そうとする
準備に時間がかかり、依頼する前に疲れてしまいます。
まずは話せる範囲で背景を伝え、足りない情報を質問させます。
失敗2: 「覚えておいて」と頼んだのに、次回また説明する
何をどこに記録したかが分からなくなっています。
「次回も使うルール」「特定の作業手順」「今回の記録」のどれかを指定します。
失敗3: 承認を求められたら、内容を読まずに進める
確認が多すぎると、承認が作業の一部になり、形だけになりやすいです。
確認が必要な操作を絞り、その操作の内容と影響を読んでから判断します。
失敗4: 自動化できたことを、正しさの証拠にする
手順を最後まで実行できても、入力値や結果が正しいとは限りません。
成果物と根拠資料を照合する工程を残します。
まとめ
会話の量だけでなく、次に使う文脈を置く場所が大切です
毎回のルール、繰り返す手順、その日の作業記録を分けます
目的と背景を渡し、途中の成果物を確認し、最後は人が決めます
修正をその場限りにせず、再発するものだけ次回の手順へ反映します
小さく試し、根拠を確認できる範囲から任せます
まずは、最近AIに何度も説明したことを1つだけ選んでみてください。
それを CLAUDE.md、メモリ、Skill、作業ログのどこに残すか決めるところから始められます。
参考資料
みのるん「Claude Codeを『使うほど育つ』AI秘書にするノウハウ」Speaker Deck（2026年9月17日公開）
Anthropic「Extend Claude Code」
Anthropic「Hooks reference」
