同じ作業を繰り返さないために｜AIとの制作手順を仕組みに残す理由

手順を残したからといって、次の作業がすべて同じになるわけではありません。題材や商品、公開先が違えば、必要な確認も変わります。それでも、毎回ゼロから考えなくてよい部分が見えると、次に何をすればよいかを決めやすくなりました。

「できた」で終わると、次回また迷う

一つの制作が終わると、ほっとして次へ進みたくなります。ただ、何がうまくいったのか、どこを確認したのかを何も残さずにいると、次に似たものを作るとき、また同じことを思い出すところから始まります。

その場では分かっていたことも、時間がたつと細かな順番や注意点は曖昧になります。以前に使った画像の条件、商品ページに載せる情報、公開前に見るリンクなど、ひとつずつ調べ直すこともありました。

そこで、作業が終わったときに「次回も使えそうなこと」を短く記録するようになりました。全部を記録するのではなく、次の自分が迷いそうなところを残す感覚です。

最初に残したのは、作業の順番

手順を残すとき、最初に役立ったのは細かな操作方法よりも、大まかな順番でした。

何を作るのかを決める。形にする。必要な情報や表示を確かめる。人が内容を見て判断する。公開後の状態を確認する。こうした流れが見えると、作業の途中で「次は何を考えるのか」が分かりやすくなります。

活動記録 #4で紹介したデジタルツールの制作でも、最初は商品ごとに必要なものを探りながら進めていました。複数の商品を作る中で、説明文や画像、動画、価格、動作条件など、繰り返し準備する要素が見えてきました。

デジタルツールを5つBOOTHで販売して分かったこと

一度流れが見えても、次の商品ではそのまま当てはまらないところがあります。だから順番は「必ずこの通りに進める規則」というより、作業を始めるための土台として使っています。

確認項目は、作るものに合わせて使う

順番が分かってくると、作業ごとの確認項目も残せるようになりました。

記事なら、タイトルやURL、内部リンク、公開ページでの表示など。商品ページなら、価格、画像、動画、購入先、対応環境や注意事項など。Webページなら、リンク先やページの正規URL、一覧への掲載などを確認します。

毎回すべてを同じように見るのではなく、今回の制作に関係する項目を選びます。題材に合わない項目は使わず、必要なものが足りなければ追加します。

活動記録 #5では、YouTube動画をそのまま文字起こしするのではなく、Web記事として読みやすい形に組み直す流れを紹介しました。動画ごとに内容は違いますが、中心テーマを考え、構成を作り、記事だけでも伝わるか確かめる、といった考え方は次の制作でも参考になります。

YouTube動画をWeb記事にして残すまで

確認項目は、漏れを完全になくすための保証ではありません。何を見るかを思い出しやすくするための手掛かりです。実際にページや商品を見て、今の内容に合っているかを確かめることも続けています。

状態を残すと、途中から再開しやすい

作業の順番や確認項目に加えて、「今どこまで終わったか」を残しておくことも大切でした。

一度にすべての作業を終えられるとは限りません。記事を書いた段階なのか、ページとしての確認まで終わったのか、公開を待っているのか。状態が分かれば、次に戻ってきたとき、すでに終わったことを最初から調べ直さずに済みます。

制作記録には、完了したことだけでなく、まだ判断していないことや次の作業も書いておきます。そうすると、作業の途中で止まった場合にも、どこから再開すればよいかをつかみやすくなりました。

次の人が確かめられる記録にする

「確認した」とだけ残すより、何を見て、どこまで分かり、何がまだ分からないかを分けると、次の確認を始めやすくなります。たとえば外部サービスの画像をページに載せる場合は、次のように整理できます。

記録する項目	記入例
目的	LINEスタンプ一覧で、購入前に画像が表示されるときの通信を案内する
確認したもの	ページの画像URLがLINEの画像配信サーバーを参照し、画像に遅延読み込みが指定されていること
分かったこと	画像が読み込まれると外部サーバーへの通信が発生する。購入リンクを押すこととは別の処理として説明が必要
まだ分からないこと	外部サーバーが通信時に扱うログの項目や保存期間は、このページの実装確認だけでは分からない
次にすること	ページ上で通信を案内し、提供元のプライバシーポリシーへリンクする。次回も画像参照先が変わっていないか確認する

これはサイトの実装と公開中の説明をもとにした記録例です。外部サービス側のログや保存期間を調査した結果ではありません。確かめられた範囲と未確認の範囲を同じ欄に混ぜないようにすると、後から読む人も事実と推測を区別できます。

追記：前回の「PASS」を別の成果物へ使い回さない

ここからは2026年10月29日に確認した、このサイトのビルド検証スクリプトとテスト記録に基づく補記です。前の記録例が「調べた内容をどう残すか」だったのに対し、ここでは「記録した対象が今の成果物と同じか」を確かめます。

Webサイトは、原稿や設定などのソースから、公開用のHTMLや画像をまとめた成果物を作ります。以前の検査がPASSでも、その後に原稿を直したり、別フォルダーの生成物を見たりした場合は、同じ検査結果として使えません。

そこで本サイトの検証処理では、ビルド対象のコミット、ソースのSHA-256、生成ファイル一覧と内容に対応するSHA-256を、小さな記録ファイルへ残しています。SHA-256は、対象データから計算する照合用の値です。後の検査で値が合うかを見ることで、対象の取り違えや途中の変更を検出する手掛かりにします。

意図的に違う状態を作って、止まるかを試す

test-verify.ps1では、本番ファイルとは別の一時的なテスト用ファイルを作り、検査が受け入れる場合と拒否する場合を確認しています。以下は、そのテストで確認する内容の一部です。実際の公開ファイルが壊れていた事例ではありません。

テスト用に作る状態	期待する動作	何を見落とさないためか
記録のコミットと生成物が一致する	受け入れる	正しい組み合わせまで誤って止めない
記録を作った後でHTMLを変更する	拒否する	検査後に変わった内容へ以前のPASSを流用しない
記録のコミット値を別のものにする	拒否する	違う版の結果を混ぜない
ソースの照合値を変える	拒否する	同じ名前のフォルダーでも中身を取り違えない
記録ファイルがない	拒否する	証拠がないのに確認済みとしない
必須の出力ファイルを欠かす	拒否する	生成途中のフォルダーを完成品として使わない

2026年10月29日の回帰検査では、これらを含む既存7項目が想定どおりに動くことを確認しています。そのうち通常ビルド経路のテストは、呼び出しを確かめるための模擬コマンドを使います。7項目がPASSしたことと、実サイト全ページの内容・見た目・安全性を確認したことは同じではありません。実際のサイトビルドと生成物検査は別に実施します。

次回のために残す最小限の組み合わせ

別のサイトや制作物で同じ考え方を使うなら、ツール名をそのまま写すより、次の記録がそろうかを見ます。

• 対象：どの版のソースから、どの出力先へ作ったか。
• 検査：何を確認してPASSしたか。実際の公開確認か、ローカルの模擬検査か。
• 証拠：記録ファイルの場所と、成果物を識別する値。
• 再確認の条件：ソースや生成物を変更したとき、どこからやり直すか。
• 未確認：画像の見やすさ、実機動作、外部サービス側の状態など、検査に含めていないこと。

照合値が一致していても、元の文章が正しいことや、利用者が迷わず操作できることは証明できません。この仕組みで減らせるのは、確認した対象と別のものを「確認済み」として扱う取り違えです。サイト制作で公開確認を見直した例では、取得不能と公開失敗を分ける判断も紹介しています。記録を残すときは、対象の一致と確認内容の十分さを、それぞれ見直してください。

追記：途中で止まった作業コピーを、次回の完成品にしない

2026年10月31日、このサイトの活動確認用スクリプトを見直した際には、古い版を指定したコピーと、最新の公開用ソースを区別する必要がありました。以下はその準備処理で実施した検証記録です。活動先の全サービスを確認できた記録や、無人実行が成功した記録ではありません。

完成フォルダーへ直接書かず、準備中の置き場を分ける

途中までコピーできたフォルダーを、次回「もう準備できている」と使ってしまうと、欠けたファイルや違う版が混ざるおそれがあります。そこで、今回だけの一時フォルダーにファイルをそろえ、照合結果と記録ファイルを保存してから、同じ保存領域内で完成フォルダー名へ変更する形にしました。以前の完成フォルダーには追記しません。

この処理では、GitHubのmainから取得した427個の追跡ファイルを、その版のファイル一覧とGitのハッシュで照合しました。書き込んだ後にもSHA-256を計算しています。別名の新しいコピーを2回作り、どちらも照合に成功しました。427という数はこの検証時のソース数で、今後の固定合格件数ではありません。

確認した場面	実際に確認した結果	次回へ持ち越す判断
同じmainから新規コピーを2回作る	別々の完成フォルダーが作られ、各427ファイルが一致	既存フォルダーを更新する必要はない
記録ファイルへの書き込みを模擬的に失敗させる	今回の一時フォルダーが除去され、完成品として残らない	ディスク障害の実発生ではなく、失敗処理のテストとして記録する
既存コピーの内容を再照合する	試験用に作成した4コピー、計1,708ファイルが保存済みの照合値と一致	他の制作物を変更していないか、対象を限定して確かめる
手動で許可を受けた環境から実行する	準備処理は成功	毎晩の自動実行で同じ書込・通信権限を使えるかは別途確認する

自分の作業へ取り入れるなら、先に決める4項目

1. 元の版：取得日時だけでなく、元のファイル群を特定できる版番号やコミットを残す。
2. 作成場所：既存データと混ざらない専用の保存先を選び、別の場所を指定したら止まるようにする。
3. 完成の条件：必要ファイル、内容の照合、記録の保存が終わってから完成扱いにする。
4. 失敗時の扱い：今回自分が作った一時データだけを片付ける。消せなかった場合は保存場所と失敗を明記し、完成扱いにしない。

この方法は、ファイルをそろえる段階の取り違えを減らすためのものです。文章の正しさ、画面の読みやすさ、外部サービスの取得可否は別の検査が必要です。作業記録には「コピー準備完了」「内容確認完了」「公開確認完了」を別々に残すと、次に何を確かめるべきかが分かります。画面の文章を確認するときは、横スクロールがなくても文字が切れる場合の点検方法も合わせて使えます。

次の人にも渡せる作業記録の型

作業を再開したり、別の人へ引き継いだりするときは、次の項目を埋めておくと、完了した範囲と残っている確認を読み分けやすくなります。必要な項目だけ使い、作業に関係のない情報や認証情報は記録しません。

• 目的：何を準備・確認する作業か。
• 対象の版：日付だけでなく、コミット、バージョン、ファイル一覧など、元データを特定できる情報。
• 保存先：今回の作業用に選んだ場所。既存データと混ざらないかも記す。
• 完了条件：どの一覧や照合結果がそろえば完了とするか。
• 実施結果：実際に確認した件数や一致・不一致。件数の基準は、その時点の元データから取り、過去の例の数を固定条件にしない。
• 証拠と未確認：記録の場所と、今回の確認に含めなかったこと。
• 失敗時と次の行動：途中データの後始末ができたか、誰が何を確かめれば再開できるか。

たとえば、先ほどのコピー準備の記録を引き継ぐなら、「GitHub mainから取得したファイル一覧と照合」「別々に作ったコピーは各427ファイルで一致」「記録書き込みの模擬失敗では一時フォルダーが残らない」「夜間の自動実行や活動先サービスの確認は未検証」と短く分けて書けます。427件はその検証時点の実測値です。別の作業では、元データの一覧から照合対象を決めてください。

この型は確認内容を共有するためのメモで、ファイルの安全性や作業の成功を保証するものではありません。引き継ぐ相手が必要な資料を開けるか、次の作業へ進む条件がそろっているかも別に確かめます。文章での引き継ぎ項目を整理したい場合は、ChatGPTで引き継ぎメモを整理する方法も参考になります。

問題が起きたら、次の確認に生かす

手順を残していても、思いどおりに進まないことはあります。想定した表示にならない、リンク先が違う、必要な情報が足りない。そうしたときに、その場だけで直して終えると、同じ種類の見落としが次回も起きるかもしれません。

そこで、次に役立つことがあれば確認項目や説明を見直します。たとえば、作業後に気づいた注意点を、次回は準備段階で確認できるようにする。問題を全部なくすというより、経験から次の手掛かりを一つ増やす考え方です。

手順そのものも固定せず、使ってみて分かりにくい部分や、今の作業に合わなくなった部分は整えます。書いた内容を守ることが目的ではなく、次の制作で実際に役立つ形にすることが目的だからです。

AIへの依頼も、使える形を残す

毎回の依頼を最初から考え直さないように、繰り返し使う前提や確認の仕方をまとめておくこともあります。そうすると、必要な条件を伝え直しやすくなり、制作ごとに違う部分へ意識を向けやすくなります。

ただし、以前の依頼文をそのまま使えば、いつでも正しい結果になるわけではありません。新しい作業の目的や対象に合わせて、必要な条件を見直すようにしています。過去の手順が現在の状況と合わないときは、まず状態を確認して更新します。

活動記録 #6では、AIに任せる確認と、人が判断することを分けるようになった理由を書きました。手順を残すことも同じで、AIに作業を頼みやすくする一方、内容や見た目、公開してよいかの判断まで手順だけに任せるわけではありません。

AIと人間で「確認」を分担するようになった理由

仕組みになっても、人の判断は残る

作業の流れや確認項目がまとまってくると、次にすることを考えやすくなります。けれど、手順に沿って進めたことだけで、内容がよいか、説明が正確か、今公開してよいかまで決まるわけではありません。

AIに整理や確認を手伝ってもらいながら、状況に合わせて手順を調整する。できあがったものを見て、必要なら直し、公開するかどうかを決める。そこは今も自分で確かめています。

私にとって仕組み化は、全部を自動にすることではありませんでした。

一度うまくいった作業を、次も使える形で残しておく。次回に使い、状況に合わせて直し、人が最後に確認する。その積み重ねで、AIとの制作は単発の作業から、少しずつ続けやすい仕組みに変わっていきました。

これからも、作って終わりにせず、次の制作に役立つことを少しずつ残していこうと思います。