Skip to content
Previous Post
エッセイ:生成AIと意思決定についての思考整理(2026.09.26改稿版)
Next Post
エッセイ:宛先を間違えた手紙

エッセイ:制作周期そのものを、自然時間と機械的反復の中間に置く

load-recordでは、音楽制作を続けながら、現在その過程そのものの記録も行っています。

完成した曲だけではなく、何を見たのか、そこから何を考えたのか、どこで判断が変わったのか。

そうしたものまで広い意味での「record」として残しておきたいと思っています。

将来、それらをもう一度Loadし、新しいAIやSoftwareで解析したり、別の形に再構成したりできるかもしれない。


そのための記録には、今のところ

・GitHub
・Markdown
・Obsidian

を使っています。


1. 記録を閉じ込めず、変化そのものを残す

Markdownが記録の実体で、Gitが変更履歴を持ち、GitHubに保存する。

Obsidianは、それらを見るための窓のようなものです。

大事なのは、Obsidianの中に記録を閉じ込めないこと。

仮に数年後、別のEditorを使うようになっても、MarkdownのTextはそのまま残る。

さらに10年後、今とは違うAIやSoftwareが登場したとしても、Plain Textであれば読み込ませやすいからです。

今使っているApplicationに最適化するより、未来から読み返せる形で残しておく。

これは、弾き語りDemoを完成品として固定するのではなく、未来に再利用できるSourceとして残しておくというload-recordの考え方とも近い。

記録は今の時点で大きく、inbox、seasons、worksに分けています。(2026.09.16現在)

inboxには、その日に見たことや思ったことをそのまま書く。

ただし、観測と着想はなるべく分けるようにしています。


例えば、

「夕方、急に風が冷たくなった」

というのは観測で、

「何かが終わる瞬間は、その瞬間には分からないのかもしれない」

というのは、そこから生まれた着想です。

この二つを最初から一つにしてしまうと、後から残るのは解釈だけになってしまう。

見たものと、そこから出てきたもの。

両方を残しておけば、数年後には別の読み方ができるかもしれない。

もう一つ決めているのは、過去の記録をなるべく書き換えないことです。

後から「あれは違っていた」と思っても、昔の文章を修正するのではなく、現在の記録として追記する。

最初にどう考えていて、後からどう変わったのか。

その差分自体もrecordだからです。

完成した結論だけを残すのではなく、判断が変わっていった過程も残しておく。

Gitの履歴も含めて、最終状態だけではなく、そこへ至る途中も記録の一部として扱っています。


2. 七十二候を、制作の外部クロックとして使う

約5日ごとには、七十二候を目安にして、その期間の記録を読み返します。

ここでも「何があったか」と「そこから何が育っているか」を分けて考える。

さらに約15日、二十四節気くらいの周期で、形になりそうなものがあれば作品へ収束させる。

ただし、これは締切ではありません。

何も生まれない期間があってもいいし、半年かけて育つ着想があってもいい。

ここで七十二候や二十四節気を使っているのは、作品のテーマを季節に合わせるためではありません。

一週間ごと、月末ごと、といった均質なCalendarの周期だけで制作を区切るのでもなく、かといって気分だけに任せるのでもない。

自然の変化をもとに作られた暦を、制作を振り返るための外部クロックとして借りています。

制作周期そのものを、自然時間と機械的な反復の中間あたりに置いてみる。

今のところ、そのくらいの感覚です。


3. Softwareは、Loopの後から現れる

そして、この仕組みでは今のところ専用ツールを作っていません。

記録専用のApplicationも、作ろうと思えば作れると思います。

候の名前を自動入力したり、過去の着想を一覧化したり、AIに次の作品案を提案させたりすることもできる。

でも、今は作らずに運用しています。

load-recordでは、Softwareを最初に考えるのではなく、実際の制作Loopを何度も回したあとで、そこに繰り返し現れる作業やfrictionからSoftwareを抽出したいと考えています。

毎回同じことをしている。

毎回同じ場所で手が止まる。

この変換が面倒だ。

ここはAIに任せたい。

ここだけは人間が判断したい。

そういうものが実際に見えてきたとき、初めてSoftwareにすればいい。

だから、このRepositoryにも、まず2026年いっぱい使ってみて、壊れたところだけ直すという考え方を適用しています。

必要なものを想像して先に作るのではなく、実際に使って、不便が観測されてから作る。


作る。

記録する。

繰り返す。

Patternを見つける。

Methodにする。

必要ならSoftwareにする。


専用ツールがまだ存在しないことも含めて、今のload-recordの設計なのだと思っています。


Updated:

Share this post on: