このシリーズについて
AI と一緒にキャリア資産を育てていく過程を記録しています。この記事は第5回です。
はじめに
前回は、自分が過去に書いた投稿を材料にして、AI に価値観を分析させた話を書きました。
今回は、この連載そのものの話です。
連載を始めるとき、設計書を1本書きました。何を書き、何を書かないかを決めたものです。Markdown で書いて、リポジトリに置いてあります。
その設計書が、記事を公開するたびに書き換わってきました。最初に決めたルールが足りず、公開してから足したものがほとんどです。今回はその経緯を書きます。
想定している読者
- 個人の発信で、どこまで書いてよいかの線引きに悩んでいる人
- ルールを決めたのに守れない、あるいは決めたことを忘れる人
この記事で扱わないこと
- 公開範囲のルールの全文
- Git の使い方そのもの
当時のやりとりの載せ方
- 引用: そのまま載せたもの
- 要約: 要点だけ書き直したもの
- 編集: 公開にあたり表現を変えたもの
最初は「公開前チェックリスト」だった
設計書の初稿は190行でした。そのうち、公開前に確認する部分はこれだけです。
引用（2026年8月の設計書より）
## 7. 公開前チェックリスト
投稿ボタンの前に必ず通す。
目視で確認する:
（中略。8項目）
機械で確認する（原稿のパスを指定して実行する）:
（中略。grep 3本）
目視の8項目は、会社名が入っていないか、個人名が入っていないか、金額が入っていないか、といったものです。grep は、書きたくない語を機械的に探すためのものを3本。
これで足りると思っていました。要するに、通るか通らないかを見る仕組みです。
公開する直前に、それでは足りなくなった
第1回を公開する当日、この節を作り替えています。
記事が書き上がって、いざ投稿ボタンを押す前に読み返したときに、チェックリストで拾えないものが残っていることに気づきました。
たとえば、社内の人が読んだらどう見えるか。数年後に読まれたときに立場が変わらないか。記事から自分に辿り着く経路が新しく増えていないか。どれも、禁止語を探すだけでは出てきません。
その日のうちに追加したのは、次のものです。
「全世界に公開する前提でレビューする」の4観点
Qiita のガイドラインとの突き合わせ
レビュー結果の書き方
「リスクゼロは目指さない」という方針
AI にレビューを依頼するときの一文
サービス名を探す grep を1本
節の名前も「公開前チェックリスト」から「公開前レビュー」に変えました。設計書はこの1回で260行から311行になっています。
チェックからレビューへ変わった
名前を変えたのは、やることが変わったからです。
チェックリストは、条件を満たしているかどうかを見ます。答えは通るか通らないかのどちらかです。
レビューは、問題がないかを見るだけでは終わりません。残るリスクを言葉にして、それを自分が許容するかどうかを決めるところまでやります。設計書にはこう書きました。
引用（2026年8月の設計書より）
「リスクゼロ」は目指さない。残るリスクを言語化し、許容すると決めたことを記録する。
判断の記録が残っていれば、後から見直せる。
もう1つ、レビューでやるようになったことがあります。書いた事実の根拠を確かめることです。
第2回で、GitHub へ移行したときに git push が通らなくなった話を書きました。記事のネタを溜めているファイルには、こう書いてありました。
引用（2026年8月の記事ネタより）
SSH 鍵の期限切れで詰まった話
自分の記憶では、鍵が期限切れになっていたと思っていました。ところが記事にする段になって確認すると、期限切れだったという根拠が見つかりません。確認できたのは、Permission denied (publickey) が出たこと、鍵を作り直して登録し直したこと、そのあと使えるようになったこと。ここまででした。
そこで原因は断定せず、起きた事象とやったことだけを書きました。公開した第2回にも「期限切れ」という言葉は入っていません。
レビューでやりたいのは、文章をきれいにすることではありません。自分の記憶や AI の補完で、確認できていない因果を事実として残さないことです。
そのうえで、AI がリスクや違和感を指摘しても、最後に何を残すかを決めるのは自分です。指摘を受けて直したものもあれば、理由を書いて残したものもあります。
それでも公開すると事故する
レビューの仕組みを作ったあとも、事故は起きました。
第2回を投稿したとき、タグが第1回のままになっていたのです。本文は差し替えたのに、タグだけ前の回のものが残っていました。公開後に気づいて差し替えています。
公開前レビューは通っていました。ただ、レビューが見ていたのは原稿の中身だけです。投稿画面で何を選ぶかは、設計書のどこにも書いてありませんでした。
このとき、公開ログにこう書いています。
引用（2026年8月の公開ログより）
投稿直前に、タイトル・タグ・冒頭の管理用メモの3点を確認する手順を決める
事故しにくい場所へ、ルールを移した
ただ、この書き方には問題があります。「投稿直前に確認する」は、結局のところ気をつけるという話です。忘れたときに止まる仕組みがありません。
次の回でやったのは、確認の手順を足すことではなく、タグを決める場所を変えることでした。
下書きの Markdown の冒頭に、タグを書く欄を作りました。
# ChatGPTで壁打ちして、Claude Codeで成果を管理するようになった
状態：初稿
作成日：2026-08-19
タグ：ChatGPT Claude 生成AI キャリア AIとキャリアを育てる
タグは記事を書き始める前に決まっています。それを原稿の一番上に置いておけば、投稿画面ではコピーして貼るだけです。思い出す必要がありません。
区切り文字を半角スペースにしたのも、このためです。Qiita のタグ欄にそのまま貼れます。
第3回と第4回は、これで貼り間違いが起きていません。
「次から気をつける」で終わらせず、事故しにくい場所へルールを移す。 チェックリストに項目を1つ足すのは簡単です。ただ、項目が増えるほど、自分が見落とす確率も上がっていくように思います。
公開するたびに、小さなルールも増えた
大きな変更のほかに、細かいものも溜まっていきました。理由は書きませんが、どれも実際に困ったことから来ています。
タグはシリーズ共通3つと記事ごと2つで組む
記事の一覧を冒頭に置くのをやめ、末尾に前後リンクを置く
前後リンクは次回を先、前回を後に並べる
本文で章番号を使って参照しない
引用ラベルの日付は年月まで書く
このうち「本文で章番号を使って参照しない」は、第4回のレビューで出たものです。章を書き足したときに、本文に書いた「第8章で触れた」という参照がずれました。読者は章番号を数えないので、参照ごと外しました。
設計書を完成させてから始めなくてよかった
この記事を書いている時点で、設計書は344行あります。初稿の190行から、記事を4本公開する間に増えました。
もし最初から344行を書こうとしていたら、たぶん連載は始まっていません。何を書けばいいのか分からないからです。タグの貼り間違いは、実際に貼り間違えるまで思いつきませんでした。章番号の参照がずれる問題は、章を足すまで存在しませんでした。
順番はこうでした。
公開する
↓
困る
↓
AI とレビューする
↓
Markdown にルールを足す
↓
また公開する
書き足したのは事実ですが、なぜ書き足したのかは、それだけでは残りません。残っているのは git の履歴のほうです。いつ、何が、どの記事の直前に足されたのかを、あとから確認できます。この記事も、記憶ではなく履歴を見て書いています。
この記事のまとめ
- ルールは最初から完成させず、実際に使って困ったことを次のルールにする。困る前に思いつくルールは、たいてい足りない
- 「次から気をつける」で終わらせず、事故しにくい場所へルールを移す。項目を足すより、思い出さなくて済む形にする
- AI がリスクを指摘しても、最後に何を残すかを決めるのは自分。指摘を採用した記録も、採用しなかった理由も、あとで見直せる形にしておく
ルールを Markdown で書いて git に置いておくと、増えた結果だけでなく、増えた理由まで残ります。設計書そのものが、記事の材料になりました。
次回は、まだ決めていません。溜めてあるネタから選びます。
前回（第4回）