AIにサイトの作業を任せていると、「何が動いたか」「何が止まったか」「どこで判断を変えたか」が、セッションの終了とともに消えます。あとから振り返ろうとしても、残っているのは成果物だけで、途中の判断は手元にありません。
結論から書きます。作業ログは、残すか残さないかを都度判断する運用では続きません。ルールだけ作ってもゼロ本になります。続けるには、次の3つを決めます。
- 何のために残すのか（目的が決まると、書く条件が自動で決まる）
- 何を残して、何を残さないか（4軸：失敗・有効・原則・対象読者）
- 自分で書くのではなく、AIが書く（判断を人に残すと止まる）
この記事は、散らかったサイトをAIで作り変えるマニュアルの前提の最後の作業です。ここを飛ばすと、以降の診断・修正・改善で「同じ失敗を2回繰り返しているのに気づけない」状態になります。
目次
この作業で決まること
この作業が終わると、AIに作業させるたびに、1件の記録が勝手に積み上がる状態になります。
人がやることは3つに減ります。
- 目的を1行で決める（何のためにログを残すか）
- 書く軸を決める（失敗・有効・原則・対象読者）
- AIが書いたログを週1回ざっと読む
ログの中身を自分で書き起こすことはしません。書き起こしを人の作業に残すと、忙しい週にゼロになります。
よくある失敗：「大事なことがあったら書く」という自律判断方式にすること。基準が自分の中にしか無いので、忙しくなると書く条件が消えます。
前提：この記事の前に必要なもの
- AIに渡す4つの前提が置かれていること
- AIがサイトを操作できる状態になっていること
- 決定の台帳が1枚あること
決定の台帳と作業ログは別物です。台帳は「有効な方針」を残す場所、作業ログは「その方針に至った経緯と、途中で起きた失敗」を残す場所です。
AIに渡すもの①：ログの目的
最初に、「何のためにログを残すか」を1行で書きます。目的が無いと、ログは形式的になり、自然に止まります。
私は自分のログの目的を「書籍・有料コンテンツの素材として残す」に絞りました。目的を作業記録ではなく「本の1段落になりそうか」に置くと、残すものの基準が自動で決まります。日々の進捗や「今日やったこと」は残しません。あとで誰かが読んで価値があるかどうかだけを基準にします。
目的の例はいくつかあります。自分のサイトなら「本やコンテンツの素材」、勤務先なら「同じ失敗を他のメンバーが繰り返さないため」。どちらでも構いませんが、1種類に絞ることが大事です。目的が2つあると、どちらにも中途半端なログになります。
よくある失敗：目的を決めずに「とりあえず残す」ことから始めること。ログの質がばらつき、見返しても何を書いたのか分からなくなります。
AIに渡すもの②：書く軸（4つ）
次に、1件のログに何を書くかを決めます。私のログは次の4軸で統一しています。
- 失敗したこと：何が起きて、なぜ失敗だったか
- 有効だったこと：何がうまくいき、なぜ効いたか
- 再現可能な原則：この経験から取り出せる、他の場面でも使える判断基準
- 対象読者：この記録を読んで役に立つのは誰か
タスクログ（やったことの時系列）ではなく、4軸で書くようにすると、1件ずつがそのまま本の章や記事の素材になる構造で残ります。日付と作業名だけを並べたログは、あとから読み返したときに情報として使えません。
書く長さの基準は決めません。1行で終わる失敗もあれば、再現原則まで書ける失敗もあります。短くてよいかわりに、4軸のどれにも当てはまらないならそもそも書かない、という条件にしておきます。
AIに渡すもの③：書く主体
3つ目が、実は一番効きます。ログを書くのは人ではなくAIにすることです。
自律判断方式（人が気づいたときに書く）は、設計はあっても2週間以上空白になります。ルールがあり、保存先のディレクトリが用意されていても、書く条件が頭の中にしか無いと、忙しい週は書けません。
AIに任せるときの条件はシンプルです。
- 作業セッションの終わりに、AIが「今回の作業に、失敗・有効・原則・対象読者のどれかに該当する出来事があったか」を判定する
- 該当があれば、4軸のフォーマットで1ファイル書く
- 該当が無ければ何も書かない（毎回書かせない）
人の仕事は、週に1回まとめて読むことだけです。AIが書いたログに事実の間違いがあれば、その週に直します。
よくある失敗：「ログを書く」というタスクを毎日のToDoに入れること。タスクとして残すと、形式的な記録になり、本来書くべき失敗や判断の経緯は書かれません。
手順
- ログの目的を1行で書く（例：「本やコンテンツの素材として残す」）
- ログを置くディレクトリを決め、AIの参照先に加える
- 4軸のテンプレートを1枚だけ用意する
- AIが毎回最初に読むファイルに、「作業の終わりに該当があればログを1件書く」を足す
- 週1回、たまったログを一度に読む
- 事実の誤りがあればその場で直し、設計の問題なら決定の台帳に反映する
ディレクトリ名はなんでも構いません。私は field_notes/ という名前にしています。ファイル名は「日付_プロジェクト_要約.md」の形式で揃えると、あとで検索しやすくなります。
完了条件
- ☐ ログの目的が1行で書かれている
- ☐ 書く軸（失敗・有効・原則・対象読者）が1枚のテンプレートになっている
- ☐ AIが毎回最初に読むファイルから、ログの運用が参照されている
- ☐ 作業セッションの終わりに、AIが自分で該当を判定して書くようになっている
- ☐ 週に1回、ログを読む時間が決まっている
実際に起きた失敗
設計はあったが、2週間以上ゼロ本だった
ログの保存先ディレクトリも、作業記録を集約するためのルールも、先に用意していました。ところが、ある時に確認すると、2週間以上（4月末から5月半ばまで）1本も書かれていませんでした。移行ルールもディレクトリも存在していて、下書きのディレクトリも用意されていたのに、片方には数本、もう片方は空のままでした。
原因は、ルールが「自分で判断して書く」自律判断方式だったことです。書く条件が自分の中にしか無く、忙しい週は条件そのものを思い出せません。設計があっても、書く行為と目的（本の素材として残す）が頭の中でつながっていませんでした。
対策は3つでした。目的を作業記録から「本の1段落になりそうか」に絞ること、フォーマットを決めずに短くても書けるようにすること、そしてAIが「これは重要」と判断したときに自律的に書く運用に切り替えること。この3つで、ログは積み上がるようになりました。
ログが止まっていた期間に、別の自動処理も毎晩落ちていた
ログが止まっていた約11日間の裏で、サイトを巡回する自動スクリプトが毎晩クラッシュしていました。別のスクリプトもAPIのエラーで落ちていました。それだけでなく、使われていないスクリプトがプロジェクトに何本もたまっていました。
本当に失敗だったのは個々のクラッシュではありません。全体を見ている人（または仕組み）がいなかったことです。各プロジェクトのAIは独立して動いていて、別プロジェクトで何が起きているかを知りません。横断的に「全体として健全か」を見る仕組みが無かったので、11日間気づけませんでした。
対策として、プロジェクト単位ではなく自分を最上位に置いた全体設計に切り替えました。実行は各プロジェクトで分かれていてよいが、省察（振り返り）は1か所に集めます。作業ログがその集合地点になります。ログが積み上がっていれば、「どのプロジェクトで、いつ、何が止まっていたか」が1か所で見えます。
よくある質問
Q. ログは毎日書かせたほうがいいですか？
A. いいえ。毎日書かせると、書くこと自体が目的になり、形式的な記録になります。該当する出来事があったときだけ書かせます。目安は「本の1段落として読む価値があるか」です。
Q. 自分で書いたほうが正確ではないですか？
A. 正確でも、続きません。自分で書く運用は忙しい週にゼロになります。AIに書かせて、週1回まとめて事実を直すほうが、長い目で見ると情報が残ります。
Q. 4軸のうち、どれから書き始めればいいですか？
A. 失敗から書くのが一番続きます。失敗は記憶に残りやすく、原因と対策まで書けると、そのまま再現原則が取り出せます。有効だったことは、あとから失敗と対で書くと厚みが出ます。
関連記事
次の作業
- 診断：サイトに必要な修正が大規模・中規模・小規模のどれかを判定する
- 週1回の自動レビューを設計する
- ログから「再現可能な原則」を取り出して台帳に昇格させる
`
