README・CHANGELOG・Codex作業ルールまで作った理由｜AI開発を資産として残す方法

前回は、ChatGPT、Codex、n8n、Geminiと人間で、「自分専用AI週報」を育てる役割分担についてお伝えしました。

仕組みが動くようになると、次に考えるべきことがあります。

「数か月後の自分たちも、この仕組みを理解できるだろうか？」

n8nでワークフローを作る。
Geminiへ指示を渡す。
Gmailでメールを送る。

ここまでできれば、自動化としては一応動きます。

ですが、仕組みは作って終わりではありません。

情報源を増やしたくなるかもしれません。
メールの形式を変えたくなるかもしれません。
エラーが出たときに、見直す必要があるかもしれません。

別のAIや別の担当者と一緒に改善する場面も出てくるはずです。

そのときに、「作った本人しか分からない仕組み」では困ります。

そこで今回、「自分専用AI週報」では、ワークフローだけでなく、README、CHANGELOG、Codex作業ルールも残すことにしました。

今回は、なぜドキュメントを作ったのか？何を書いたのか？そして、仕組みを資産として残すために大切だと感じたことをお伝えします。

このは屋

（生成AI×デジタルマーケティングスクール）

スモールビジネス特化の学び舎。スモールビジネスオーナーに向けて、ネットから集客する方法、オンラインで商売する方法、労働集約型から知識集約型へ移行する方法、安定した継続的な収入源を確保する方法…etc。悔いの無い生涯を謳歌する為の、鼻歌まじりの商売と生涯を、ワンストップで、トータルにサポートしている。

この記事の要約

自動化の仕組みは、動くだけでは十分ではありません。
README、CHANGELOG、作業ルールを残すと、後から見直しや改善がしやすくなります。
AIと一緒に仕組みを作るほど、何をAIに任せ、何を人間が判断するかを文書に残す価値が高まります。
ドキュメントは説明書ではなく、仕組みを育てるための資産です。

動く仕組みでも、時間がたつと分からなくなります

自動化を作った直後は、仕組みをよく覚えています。

どの情報源を使っているのか。
Geminiに何を指示しているのか。
どのノードでメールを整形しているのか。
なぜ重複送信防止を入れたのか。

作った本人なら、まだ説明できます。

ですが、数週間後や数か月後になると、少しずつ忘れていきます。

「このCodeノードは、何のためにあるのか？」
「なぜ直近7日ではなく、8日間を対象にしているのか？」
「Manual Triggerで実行したとき、履歴はどうなるのか？」
「どこまで確認したら、本番運用して良いのか？」

こうした疑問が出てきたとき、画面上のノードだけでは答えが見つからないことがあります。

だから、仕組みを作るときには、考え方や判断の理由も残しておく必要があります。

今回作った3つのドキュメント

「自分専用AI週報」では、主に次の3つのドキュメントを作りました。

ドキュメント	主な役割
README	仕組み全体、情報源、運用方法、注意点をまとめる
CHANGELOG	バージョンごとの変更内容と、確認済み・未確認の内容を残す
CODEX_RULES	CodexなどのAIへ依頼するときの安全ルールを残す

名前だけを見ると、少し開発者向けに感じるかもしれません。

ですが、考え方はシンプルです。

READMEは、「この仕組みは何をするものか」を説明する資料です。
CHANGELOGは、「何をいつ、どう変えたか」を残す記録です。
CODEX_RULESは、「AIにどこまで任せるか」を決める約束です。

READMEは「全体像を忘れないための地図」です

READMEには、「自分専用AI週報」の全体像をまとめました。

たとえば、次のような内容です。

この仕組みの目的
どのような人や業務に役立てたいか
使っている主なツール
情報源の一覧
ワークフローの処理順
重複送信防止の考え方
Manual TriggerとSchedule Triggerの違い
運用時の注意点
今後の改善候補

特に大切だったのは、ノードの説明だけを書かないことです。

たとえば、「RSS Feed ReadでRSSを取得する」と書くだけでは、後から見ても役割は分かります。

ですが、それだけでは、「なぜこの情報源を選んだのか？」までは分かりません。

そこでREADMEには、次のような考え方も残します。

公式情報を優先する理由
スモールビジネスが試せる更新を重視する理由
ニュースを集めることではなく、次の行動につなげることが目的であること
Macが停止している週は、定期実行されない可能性があること

READMEは、作業手順書だけではありません。

「この仕組みは、何のために存在するのか」を残す地図です。

CHANGELOGは「変更した理由を残す記録」です

仕組みを改善していくと、バージョンが増えていきます。

最初は、少数のRSSからニュースを集めるだけだったかもしれません。

その後、情報源を増やすかもしれません。
重複送信防止を入れるかもしれません。
メールの見た目を整えるかもしれません。

このときに必要になるのが、CHANGELOGです。

CHANGELOGには、主に次のようなことを残します。

そのバージョンで何を目的にしたか
前のバージョンから何を変えたか
追加したノードや変更した処理
確認できたこと
まだ確認できていないこと
既知の課題

これがないと、後から見返したときに困ります。

たとえば、重複送信防止を入れたあとに問題が出たとします。

そのとき、「どのバージョンから、この処理を入れたのか？」を確認できなければ、原因を探しにくくなります。

一方で、変更履歴が残っていれば、次のように考えられます。

直前に何を変えたか確認する
変更前後で、処理がどう違うかを見る
必要なら、前のバージョンへ戻す
改善案は新しい下書きとして作る

CHANGELOGは、過去を記録するためだけの資料ではありません。

次の改善を安全に進めるための記録です。

CODEX_RULESは「AIとの約束」を残す資料です

今回、特に重要だと感じたのが、CodexなどのAIへ依頼するときのルールです。

AIは、ファイルを読んだり、改善案を作ったり、コードの下書きを書いたりできます。

とても便利ですね。

ですが、便利だからといって、本番環境の操作まで自動で任せて良いわけではありません。

たとえば、次のような操作は、慎重に扱う必要があります。

n8nへのImport
既存ワークフローの編集
Publishや有効化
Manual実行やSchedule実行
Gmailからのメール送信
認証情報の表示や変更

これらは、外部サービスや受信者に影響を与える操作です。

そこで、Codexに依頼するときのルールを文書に残しました。

基本的な考え方は、次のとおりです。

既存JSONは上書きしない
改善案は新しい下書きJSONとして作る
認証情報や送信先を表示・変更しない
n8nへのImportやPublishは、勝手に行わない
メール送信や外部操作は、人間の明示的な承認がある場合だけ検討する
分からないことは推測で進めず、未確認事項として残す

このルールがあると、AIに依頼するときに毎回ゼロから説明しなくて済みます。

また、AIができることと、人間が判断することの境界も分かりやすくなります。

「完成」と「確認済み」を分けて書くことが大切です

自動化の仕組みでは、「作った」と「本番で使える」が同じではありません。

たとえば、JSONファイルが完成していても、n8nへImportしていなければ、実際には動いていません。

Importできても、Gmail送信を確認していなければ、最後まで動くかは分かりません。

Manual Triggerで動いても、Schedule Triggerで定期実行したときに、同じように動くかは別です。

だから、ドキュメントでは、次の状態を分けて書くことにしました。

状態	意味
設計済み	仕組みの考え方やJSONの下書きがある
Import済み	n8nへ読み込める状態になった
手動テスト済み	Manual Triggerで処理を確認できた
送信テスト済み	承認済みの送信先でメールを確認できた
本番稼働確認済み	Schedule Triggerによる定期実行を確認できた

このように書き分けておけば、実際にはまだ確認していないことを、「できている」と思い込まずに済みます。

AIと一緒に作業するときほど、この区別は大切です。

AIは、もっともらしい文章を作れます。

ですが、実際に動いたかどうかは、実行結果を見なければ分かりません。

ドキュメントは「未来の自分」への引き継ぎです

ドキュメントというと、誰か別の担当者に渡すためのものだと思われるかもしれません。

もちろん、それも大切です。

ですが、最初に助かるのは未来の自分です。

数か月後に、新しい情報源を追加したくなるかもしれません。
Geminiへの指示を変えたくなるかもしれません。
メールのデザインを調整したくなるかもしれません。

そのときにREADMEやCHANGELOGがあれば、以前の判断をすぐ確認できます。

「なぜこの仕組みにしたのか？」
「どこまでテストしたのか？」
「何を変えると影響が出るのか？」

こうしたことが分かれば、改善のスピードは上がります。

ドキュメントは、面倒な事務作業ではありません。

未来の自分が、もう一度考え直す時間を減らすための資産です。

小さな仕組みほど、早めに残しておく方が良い

「まだ小さな仕組みだから、ドキュメントは後で良い」と考えたくなるかもしれません。

ですが、私は逆だと感じています。

小さいうちに残した方が良いです。

仕組みが小さいうちは、判断の理由を思い出しやすいからです。

情報源が2つから10個へ増えたあとでは、「最初は何を考えていたのか？」を思い出すだけでも大変になります。

また、ドキュメントは最初から完璧でなくて構いません。

最初は、次のような内容だけでも十分です。

この仕組みの目的
使っている主なツール
現在の処理の流れ
確認済みのこと
未確認のこと
次に改善したいこと

これだけでも、何も残っていない状態とは大きく違います。

「自分専用AI編集者」へ進むためにも必要な土台です

「自分専用AI週報」は、ニュースを集めてメールで届ける仕組みです。

ですが、最終的な目的は、ニュースを読むことだけではありません。

集めた情報から、次に試すことを決める。
記事のテーマを考える。
メルマガや動画のネタにする。
お客様へ伝えるべき変化を整理する。

こうした流れを作ることが、「自分専用AI編集者」につながります。

そして、「自分専用AI編集者」を育てるためにも、何を集め、どう判断し、どこまで確認したのかを残しておく必要があります。

仕組みが大きくなるほど、記憶だけで管理するのは難しくなります。

だから、今のうちからドキュメントを残すことにしました。

まとめ

自動化の仕組みは、動くだけではなく、後から理解・改善できる状態にすることが大切です。
READMEは仕組み全体の地図、CHANGELOGは変更理由の記録、CODEX_RULESはAIとの約束を残す資料です。
「設計済み」「手動テスト済み」「本番稼働確認済み」など、確認状況を分けて記録することが重要です。
ドキュメントは、未来の自分や将来の担当者が仕組みを育てるための資産になります。
「自分専用AI週報」を「自分専用AI編集者」へ育てていくためにも、仕組みと判断の両方を残していきます。

次回は、このシリーズのまとめとして、「自分専用AI週報」を作って見えてきたことと、次に進める「自分専用AI編集者」についてお伝えします。

前回の記事はこちらです。AIに全部任せない。ChatGPT・Codex・n8nと人間で「自分専用AI週報」を育てる役割分担