AIへの指摘をルール集に育てるには？Claudeの定期実行で指摘を抜き出し、採否を人が決める手順

AIで資料を作るたびに、「手順が多い」「表の列が多い」と同じ指摘を繰り返していないでしょうか。その場では直っても、次の会話ではまた同じ形の資料が出てきます。

結論から言うと、指摘を「どの資料で・AIが何を出し・何を直し・なぜか」の1件ずつで指摘ログに残し、Claudeの定期実行に毎日読ませて、ルール集に加えるかの推薦メモを作らせるのが続けやすいと思います。定期実行に任せるのは推薦メモまでで、採用・統合・削除は人が決め、採用したルールだけを資料づくりのプロジェクトに置きます。メモリは上司の名前や好みの書き方といった背景に任せ、条件付きの判断基準はルール集で持つ、という分担です。

この記事では、指摘の記録の形、メモリとルール集の違い、定期実行の設定と指示文を順に説明します。そのうえで、同じ指摘ログから推薦メモを3回作らせた自社の試験をもとに、推薦メモのどこを人が読めばよいかを示します。

指摘は「どの資料で・何を直し・なぜか」を1件にして残す

AIに資料を作ってもらうと、同じ指摘を何度もしていることに気づきます。「この手順は多すぎるので3つにまとめて」「表の列が多くて投影すると読めない」。その場では直してもらえますが、次の会話でまた同じ形の資料が出てきます。Claudeのプロジェクトでも、知識ベースに追加しない限り、会話同士で文脈は共有されないと公式ヘルプに書かれています。言ったことは、どこかに残さない限り次へ引き継がれないわけです。

では、何を残せばよいのでしょうか。私は、指摘を「どの資料で」「AIが何を出し」「何を直し」「なぜか」の4つで1件にして書きためるのが、ルールに育てやすい形だと考えています。

項目	書く内容	例
資料の種類	その指摘が当てはまる場面	ピッチ資料、配布資料、社内報告
AIが出したもの	指摘する前の出力	導入手順を7ステップで1枚に並べた
指摘	どう直してほしいか	手順は3つにまとめて
理由	なぜそう直すのか	口頭で補足するので、画面は要点だけでよい

場面を書くと、反対に見える指摘が両立する

4項目のうち、とくに効いてくるのが「資料の種類」です。先日、AIで資料を作っている方との打ち合わせで、指摘を1件ずつためていく案が話題になりました。そこで例に挙がったのが「配布資料では項目が多くてもよいが、ピッチ資料では減らす」という形のルールです。この案はまだ誰も運用して確かめたものではありませんが、場面を書く意味がよく分かる例だと感じました。

たとえば、ピッチ資料では「手順は3つにまとめて」と言い、配布資料では「手順は省かず全部載せて」と言ったとします。場面を書かずに並べると、2つの指摘は正反対に見えます。AIにまとめさせれば、どちらかが消えるか、両方を足して割ったあいまいなルールになるかもしれません。場面を書いておけば、「ピッチ資料は口頭で補うので絞る」「配布資料は後で一人で読むので省かない」という2つのルールとして並べられます。

理由も同じくらい大切です。理由があると、後でその指摘をルールにするかを決めるとき、今回だけの事情なのか、毎回当てはまる事情なのかを見分けられます。「今回の打ち合わせは担当者との話なので社長の名前を入れないで」という指摘は、理由を読めば今回だけの指示だと分かります。

1週間分の指摘ログの例

この記事では、営業企画の担当者が1週間にAIへ出した指摘を、架空の例として使います。実在の顧客や案件ではありません。

ID	資料の種類	AIが出したもの	指摘	理由
F01	ピッチ資料	導入手順を7ステップで1枚に並べた	手順は3つにまとめて	口頭で補足するので、画面は要点だけでよい
F02	配布資料	導入手順を3ステップに要約した	手順は省かず全部載せて	後で一人で読むので、口頭の補足がない
F03	ピッチ資料	比較表を7列で作った	列は4つまでにして	投影すると文字が読めない
F04	ピッチ資料	表紙に先方の社長名を入れた	今回は社長の名前を入れないで	今回の打ち合わせは担当者との話なので
F05	ピッチ資料	冒頭に会社概要を3枚入れた	会社概要は1枚にして	相手はすでに当社を知っている
F10	ピッチ資料	手順を3つにまとめた	手順は5つまでなら載せていい	3つだと端折りすぎて、質問が増えた

実際のログには10件あり、F06からF09には、出典の書き方、1枚に入れる主張の数、結論の位置についての指摘が入っています。F01とF10は、同じピッチ資料の手順の数について逆を向いています。こうした食い違いは、指摘を1件ずつ残して並べたときに初めて目に入ります。

記録の手間は、作業の最後に1回だけにします。資料ができたら、その会話の中でClaudeに次のように頼みます。

この会話で私が出した指摘を、指摘ログに1件ずつ追記してください。
項目は「日付」「資料の種類」「あなたが出したもの」「指摘」「理由」です。
私が理由を言っていない指摘は、理由の欄を空けたままにしてください。

理由を空けたままにするよう頼むのは、AIがもっともらしい理由を補ってしまうのを避けるためです。空いた欄は、後で読んだときに自分で埋めれば十分です。

メモリは背景を覚え、ルール集は人が採用した判断基準を持つ

指摘を書きためる話をすると、「Claudeにはメモリがあるのだから、自動で覚えてくれないのか」と聞かれます。私も最初はそう考えました。そこで公式ヘルプでメモリの仕組みを確かめると、メモリとルール集は役割が違うことが見えてきます。

メモリは、Claudeが判断して話題ごとに保存する

Claudeのメモリは、会話が終わってからまとめるのではなく、会話の途中で話題（topic）ごとに保存されます。Claudeが自分で保存するほか、「これを覚えて」と頼んで保存させることもできます。公式ヘルプが挙げる覚える内容は、役割や仕事の文脈、仕事で関わる人、伝え方の好み、仕事の進め方、進行中の仕事などです。たとえば上司が誰で、どんな書き方の報告を好むかを覚えておけば、次に報告書を頼んだときに説明し直さずに済みます。

保存された話題は、設定の「Your Claude」から読み、編集・削除できます。プロジェクトにはプロジェクトごとのメモリがあり、プロジェクトの中ではそのメモリと、プロジェクト外の会話のメモリを合わせて使います。完全に分けたいときは、プロジェクトの「Use account memory」をオフにします。また、会話を削除しても、その会話から作られたメモリは消えないと書かれています。

判断基準は、人が採用したものだけを並べたい

ここで、前の節の指摘を思い出してください。「ピッチ資料の比較表は4列まで」「配布資料では手順を省かない」は、背景情報というより、条件付きの判断基準です。こうしたルールには、次のような扱いが必要になります。

• どの資料に当てはめるかという条件を、言葉どおりに残す
• 採用した日と、もとになった指摘を記録する
• 食い違うルールを人が一本化し、古くなったルールを消す

メモリでも話題を読んで直すことはできます。ただ、何をどの言葉で保存するかを最初に決めるのはClaudeです。条件付きのルールを、採用したものだけ、採用した言葉のまま並べておきたいなら、自分で管理するルール集のほうが向いていると思います。

比べる点	メモリ	ルール集
何を残すか	役割、関わる人、好み、進行中の仕事などの背景	人が採用した、条件付きの判断基準
誰が保存を決めるか	Claudeが会話の中で判断する。「覚えて」と頼むこともできる	人が推薦メモを読んで採否を決める
どこで使われるか	会話と、クラウドで動くCoworkのタスク	ルール集を置いたプロジェクトのすべての会話
見直し方	設定の画面で話題ごとに読み、編集・削除する	ファイルを開き、日付と根拠を見て直す・消す

置き場所は、Claudeのプロジェクトが使えます。プロジェクトの指示と知識ベース（プロジェクトに入れておく資料の置き場）に入れたものは、そのプロジェクトのすべての会話で使われます。営業資料用のプロジェクトにルール集を置けば、そのプロジェクトで新しい会話を始めるたびに、同じルールを前提にAIが資料を作ります。

メモリを切る必要はありません。上司の名前や好みの書き方はメモリに任せ、資料の判断基準はルール集で持つ。この分担にしておくと、どちらに何が入っているかを迷わずに済みます。

定期実行には、指摘ログから推薦メモを作るところまでを任せる

指摘がたまってきたら、次はそれをルールの候補に仕分ける作業です。毎日自分で読み返すのは続かないので、ここをClaudeの定期実行に任せます。

定期実行でできること

Claudeの定期実行（Scheduled tasks）は、Pro・Max・Team・Enterpriseの有料プランで使える機能です。作成時に書いたプロンプトがタスクの指示として保存され、選んだ頻度で実行されます。各回はそれぞれ独立したCoworkのセッションとして動き、結果は通常のタスクと同じように後から確認できます。通常のCoworkのタスクと同じく、接続したツールやスキルも使えます。

手動で作る場合は、左のサイドバーの「Scheduled」から「New task」を選び、「Set up manually」で次の項目を入れます。

1. タスク名
2. タスクの内容を書いたプロンプト
3. 承認モード（Claudeが操作の前に確認を求めるかどうかの設定）
4. 頻度（毎時、毎日、毎週、平日、手動）
5. 使うモデル（任意）
6. 作業するフォルダ（任意）

ChatとCoworkが1つにまとまった新しい画面では、「平日の18時に、指摘ログから推薦メモを作って」のように会話の中で頼み、Claudeが示すタスク名・頻度・指示を確かめて「Schedule」を押す流れになります。作った後は、同じ画面から指示や頻度の編集、一時停止、削除、手動での実行ができます。

過去の会話を読ませず、指摘ログを渡す

最初に確かめたかったのは、定期実行が過去の会話を読めるかどうかでした。Claudeには過去の会話を検索する機能があり、頼むとツールの呼び出しとして過去の会話を探します。プロジェクトの中の会話は、そのプロジェクトの中だけを探します。ただし、2026年11月15日に公式ヘルプを確認した範囲では、定期実行の各回がこの検索を使えるかについての記載は見つかりませんでした。

そこで、定期実行には過去の会話を探させず、前の節で作った指摘ログのファイルを読ませる形にします。会話の中で指摘ログへ追記しておけば、定期実行は決まった1つのファイルを読むだけで済みます。

ファイルの置き場所には条件があります。定期実行はリモートで動くので、パソコンがスリープ中でもデスクトップアプリを閉じていても実行されます。一方で、パソコン上のフォルダをクラウドのセッションが読み書きできるのは、そのパソコンでデスクトップアプリが開いている間だけです。指摘ログを手元のフォルダに置くなら、平日の終業前のように、パソコンとアプリが開いている時刻に実行を合わせておくと確実です。

推薦メモを作る指示文

定期実行に保存する指示文は、次のようにしました。

あなたは資料づくりのルール集を管理する担当です。
指摘ログと採用済みのルール集を読み、ルール集に加えるかどうかを
人が判断するための推薦メモを作ってください。ルール集そのものは書き換えないでください。

推薦メモは次の4つに分けてください。
1. 新しいルールの候補：ルールの文、適用する場面（どの種類の資料か）、理由、根拠にした指摘のID
2. 採用済みのルールと同じ内容の指摘：該当するルールのIDと指摘のID
3. 今回だけの指示と思われる指摘：指摘のIDと、そう判断した理由
4. 互いに食い違っていて人の判断が必要な指摘：指摘のIDと、何が食い違っているか

指摘ログに書かれていないことをルールにしないでください。

4つに分けるのは、人が読むときに判断の種類ごとに見られるようにするためです。新しい候補は採るかどうか、重複は確認だけ、今回だけの指示は捨ててよいか、食い違いはどちらを基準にするか。分かれていれば、それぞれ1行ずつ判断できます。

「ルール集そのものは書き換えないでください」と書くのは、採否を人に残すためです。Coworkは、パソコン上のフォルダに結び付いたプロジェクトについて、プロジェクトの内容を変えないと説明されていて、残したいものは自分で追加するよう案内されています。ルール集の更新は人が行う、という流れはこの仕様とも合っています。

推薦メモを3回作らせると、範囲の広がりと状況次第の指摘で結果が分かれた

推薦メモをそのまま信じてよいのか、どこを人が読めばよいのか。それを確かめるために、前の節の指示文で推薦メモを3回作らせてみました。

試した条件

入力は、第1節の架空の指摘ログ10件と、採用済みのルール2件（「ピッチ資料では1枚に言いたいことを1つにする」と「社外に出す資料では社名・製品名の表記を先方の公式表記に合わせる」）です。同じ入力と同じ指示文で、Claude Codeの非対話実行（モデルはclaude-sonnet-5、ツールなし）を3回実行しました。Coworkの定期実行そのものではなく、定期実行が毎日行う「読んで仕分ける」部分だけを取り出して試したものです。

ログには、仕分けの答えを決めておいた指摘を混ぜています。F08（1枚に言いたいことは1つに）は採用済みのルールと同じ内容、F04（今回は社長名を入れない）は今回だけの指示、F01（手順は3つ）とF10（5つまでなら可）は食い違いです。

3回とも同じだった仕分けと、分かれた仕分け

結果は次のとおりです。

見て分かる形の仕分けは、3回とも同じでした。F08は採用済みのルールと同じ内容、F04は今回だけの指示、F01とF10は食い違いとして人の判断へ回されました。指摘ログにないルールを足すことも、ルール集を書き換えることもありませんでした。

分かれたのは2か所です。1つは、F05（相手がすでに当社を知っているので会社概要は1枚に）の扱いです。2回は「相手がすでに自社を知っている場合」のような条件付きのルール候補にし、1回は今回だけの指示に分類しました。1回目のメモには「『相手が自社を知っているかどうか』を毎回どう判定するかの基準が別途必要」という備考も付いていました。相手との関係で変わる指摘は、ルールにするか今回だけにするかを、AIも決めきれないようです。

もう1つは、候補文の範囲です。F02の指摘は「手順は省かず全部載せて」でしたが、候補文は3回とも「手順や項目を要約せず全て記載する」「手順などの情報を省略せず全部載せる」のように、手順以外にも広がっていました。このまま採用すると、配布資料ではどんな項目も省けないルールになってしまいます。

人が読むのは、候補文の範囲と状況次第の指摘

どうやら、推薦メモで人が読む場所は2か所に絞れそうです。重複や今回だけの指示、数の食い違いのように見て分かる形の仕分けは、AIに任せても3回とも同じでした。人が読むのは、候補文が元の指摘より広くなっていないかと、相手や状況によって変わる指摘をルールにするかどうかの2点です。

候補文を読むときは、根拠のIDから指摘ログの元の言葉に戻り、名詞の範囲を見比べるのが手早いと思います。「手順」が「手順や項目」になっていれば、元の言葉に戻すか、保留にします。

ただし、これは架空の指摘10件を1つのモデルで3回仕分けた小さな試験です。どのモデルでも、どの指摘でも同じ結果になるとは言えません。ルール集を使うことで資料の質がどれだけ上がるかも、この試験では測っていません。

採用・統合・削除は人が決め、ルール集をプロジェクトに置く

推薦メモを読んだら、候補ごとに採用・統合・保留・削除のどれにするかを人が決めます。

推薦メモから決めること

採用は、候補文を元の指摘と同じ範囲に直してから入れます。統合は、似たルールを1つにまとめることです。たとえば「比較表は4列まで」と「1枚に言いたいことは1つ」は、どちらもピッチ資料で投影する画面についてのルールなので、ピッチ資料の画面のルールとして近くに並べておくと読み返しやすくなります。保留は、条件を書けない指摘です。先ほどのF05のように、相手との関係で変わる指摘は、「どういう相手なら1枚にするか」を言葉にできるまで保留にします。

食い違いは、どちらを基準にするかを人が決めます。F01とF10なら、後から出た「3つだと端折りすぎて質問が増えた」という理由を読み、「ピッチ資料の手順は5つまで」に一本化する、といった判断になります。決めた理由は、ルールの横に書いておきます。

ルール集の1件は、次のように書いています。

R03 ピッチ資料の比較表は4列までにする。
    理由：投影すると文字が読めないため。根拠：F03。採用：2026-11-15
R04 ピッチ資料の手順は5つまでにする。
    理由：3つでは端折りすぎて質問が増えたため。根拠：F01、F10（F10を優先）。採用：2026-11-15

根拠の指摘IDと採用日を残しておくと、後で「このルールはいつ、何があって決めたのか」を指摘ログまでたどれます。半年前のルールが今の資料に合わなくなったとき、消してよいかを判断する材料にもなります。

ルール集はプロジェクトの指示か、ファイルに置く

採用したルールは、資料を作るプロジェクトに置きます。Coworkのプロジェクトは、プロジェクトごとに指示、定期実行、ファイルやフォルダなどの文脈、メモリを持ちます。数件のうちはプロジェクトの指示に書き、増えてきたらルール集のファイルをプロジェクトに入れておく使い方が扱いやすいと思います。指摘ログ、推薦メモを作る定期実行、ルール集を同じプロジェクトにまとめておけば、どこに何があるかを迷いません。

前の節で触れたとおり、Coworkはパソコン上のフォルダに結び付いたプロジェクトの内容を変えません。採用したルールは、自分でプロジェクトの指示やファイルに反映します。

ルールが手順に育ってきたら、スキルにする選択肢もあります。Claudeのスキルは、Customize > Skillsから自作のものをZIPでアップロードして使えます。過去のレビューからスキルを一度に作る方法は、フィードバックスキルの作り方で詳しく書きました。日々のルール集は、そのスキルを育てる材料にもなります。開発者向けに、会話の終了をきっかけに規約とスキルの下書きを作る方法は、会話からルールやスキルを自動生成する手順で扱っています。

チームで使うなら、編集できる人を決める

TeamやEnterpriseのプランでは、プロジェクトを「Can view（見る・使う）」と「Can edit（編集する）」の権限で共有できます。チームで同じルール集を使うなら、Can editを持つ人をルール集の管理者に絞ると、誰かの指摘がそのまま全員のルールになるのを防げます。

見直しの時期も決めておきます。たとえば月に1回、ルール集を上から読み、最近の推薦メモで食い違いが出ているルールや、根拠の指摘が古いルールを消すか直すかを決める。ルール集は、増やすより、使える量に保つほうが難しい気がしています。あなたのルール集は、何件くらいになったら見直しますか。

よくある質問

Q1. 定期実行に、過去の会話から指摘を探させることはできますか？

2026年11月15日に公式ヘルプを確認した範囲では、定期実行の各回が過去の会話を検索できるかは書かれていませんでした。会話の検索そのものは有料プランの機能で、頼むとツールの呼び出しとして過去の会話を探し、プロジェクトの中ではそのプロジェクトの会話だけを探します。確実に動かしたい場合は、この記事のように作業の最後に指摘ログへ追記し、定期実行にはそのファイルを読ませてください。

Q2. パソコンを閉じていても、推薦メモは作られますか？

定期実行はリモートで動くので、パソコンがスリープ中でも実行されます。ただし、パソコン上のフォルダにある指摘ログを読むタスクは、そのパソコンでデスクトップアプリが開いている間しかファイルに届きません。指摘ログを手元のフォルダに置く場合は、アプリが開いている時刻に実行を合わせてください。

Q3. ルール集を作るなら、メモリはオフにしたほうがよいですか？

オフにする必要はありません。役割や関わる人、好みの書き方といった背景はメモリに任せ、資料の判断基準はルール集で持つ、と分けておけば両方を使えます。特定の作業だけメモリを使わせたくない場合は、新しい会話の最初のメッセージを送る前に「+」メニューからメモリをオフにできます。プロジェクトのメモリをアカウント全体のメモリと分けたい場合は、プロジェクトの「Use account memory」をオフにします。

Q4. ルールが増えすぎて、AIが守りきれなくなりませんか？

増えすぎたと感じたら、まず統合と削除を行います。同じ目的のルールを1つにまとめ、根拠の指摘が古いものや最近の指摘と食い違うものを消します。資料の種類ごとにルールが育ってきた場合は、ピッチ資料用と配布資料用のようにプロジェクトを分けるか、手順として使うものをスキルにする方法もあります。

Q5. 自分の指摘のクセまでルールになってしまいませんか？

ルールになる可能性はあります。推薦メモは、指摘ログに書かれたことを仕分けるだけで、その指摘が正しいかは判断しません。チームでルール集を使うなら、採用する前に他のメンバーにも読んでもらい、「この理由は自分の好みではないか」を確かめてから入れると安心です。編集できる人を絞っておくと、採用の判断を一か所に集められます。