2026年8月11日の記録
AI活用では、「何回やるか」より「いつ見切るか」を決めておく。
今日はかなり複数の作業を同時に進めた1日だった。大きく分けると3つ。白髪記事制作のループを実際に回したこと。広告記事を数字を見ながら改善したこと。そしてAIで修正を続けるときの「見切りライン」がかなり明確になったこと。
特に今日は、うまくいったことと時間を使いすぎたことの両方があった。その差を振り返ると、今後のAIの使い方にかなり活かせそうだ。
白髪記事の「試作」から「実行」へ
昨日まで設計していた、白髪染めをテーマにした記事群。今日は実際の制作へ移した。
今回やりたいのは、単純にAIへ「この記事を書いて」と頼んで終わる方法じゃない。最初にゴールとルールを設定して「作成→確認→修正→再確認」という流れ自体を回す。最近試している「ループエンジニアリング」の考え方だ。
最近公開されたLoop Engineeringに関する論文でも、単発のプロンプトではなく、目標・検証・停止条件・記憶などを含む再利用可能なループそのものを設計するという考え方が整理されているらしい。
今日はまず、そのための指示文を作成。そして1記事目で「本当にこのルールで回るのか?」をテストした。
1記事目を使って「ルール」を育てる
当然、最初から完璧にはいかなかった。実際に動かしてみると、ここは情報が足りない、ここはAIが変更してはいけない、といった問題が出てくる。
そのたびに人間が全部修正するのではなく「次から同じ問題を起こさないためのルール」に変える。ここを意識した。
この考え方に近い2026年の研究でも、人間からのレビューで得た修正内容を継続的な行動ルールとして蓄積し、次回以降のAIの自己チェックへ利用する閉ループ型のアプローチが報告されているらしい。
一度直して終わりではなく、一度の失敗を次の失敗を減らす仕組みに変える。今回やりたかったのは、まさにこれだ。
ループが回ることを確認して、そのまま2記事目へ
何度か調整した結果「これなら回せそう」というところまで持っていくことができた。そこでそのまま2記事目まで作成。
さらに今回の白髪記事は、記事単体で終わらないようにしている。1記事目から2記事目へ、そこから関連する別の記事へ、それぞれ内部リンクでつなぎながら読者の悩みに応じて回遊できる構造だ。
今後制作する記事も含めて約7記事を設計しているので、すべて揃えば「広告→記事→関連記事→予約・相談」という流れがかなり形になってくるはずだ。記事を量産するのではなく、記事同士が役割を持った一つの仕組みを作る。ここまで持っていきたいと思っている。
今日改めて感じた「プロンプト」の重要性
ループエンジニアリングというと「プロンプトエンジニアリングの次」のようにも見える。でも実際にやってみると、プロンプトが重要ではなくなるわけじゃない。
むしろ何を目的にするのか、何を確認するのか、何を変更していいのか、どこで終了と判断するのか。こうしたルールを明確にするために、最初の指示設計がさらに重要になる感覚がある。
ループエンジニアリングについての最近の整理でも、プロンプトとループは別物であり、ループ設計がプロンプトを不要にするわけではないと指摘されているらしい。一発でいい回答を出すためのプロンプトから、何度回しても大きくズレないためのプロンプトへ。少し役割が変わってきたように感じる。
この記事で扱っていること
設計していた白髪染めの記事群を実際の制作へ移し、作成→確認→修正→再確認というループを回し始めた日です。
一方でマニュアル制作では時間を使いすぎ、AIで修正を続けるときの「見切りライン」が明確になりました。
- 白髪記事の「試作」から「実行」へ
- 1記事目を使って、次から同じ問題を起こさないルールを育てる
- ループが回るようになっても、最初の指示設計はむしろ重要になる
- (note有料部分)修正に時間を使いすぎた場面と、そこで決めた見切り方
この記事の重要ポイント
- AI活用では、「何回やるか」より「いつ見切るか」を決めておく
- 人間が全部修正するのではなく、次から同じ問題を起こさないためのルールに変える
- 一発でいい回答を出すためのプロンプトから、何度回してもズレないためのプロンプトへ役割が変わってきた
この記事の後半は、noteの有料エリアです。
初出:note「DAY74|ループが回り始めた。次に必要なのは「どこで見切るか」」