TL;DR — 私は一人で複数のAIエージェントを使い、事業を運営しています。仕事をさせているうちに、文書が自然と3種類に分かれました。① やり方（手順） ② 何をしてきて、今どこにいるのか（プロジェクト記録） ③ 何を守るべきか（原則）。 しかし、②番が少し奇妙でした。手順でも原則でもないのに、業界にぴったりの呼び名がないのです。その正体を追いかけるうちに、「生きているシステム」という結論に至りました。
私は20年間、写真の仕事をしていました。今はひょんなことから、複数のAIエージェントを率いて一人で会社を運営しています。コードもデプロイもコンテンツも、エージェントたちが分担して行っています。しかし、人間であれAIであれ、複数で一緒に仕事をするには、結局文章として残しておく必要があります。言葉だけでは残りません。そのため、私は文書マニアになりました。
仕事をさせているうちに、書き残す文書が自然と3種類に分かれました。
- 手順 — 「この作業はこのように行う。」デプロイ方法、レポート作成方法など。どのように(how) を含みます。
- プロジェクト記録 — 「このプロジェクトはこのように始まり、今ここまで来た。」何を(what) してきたかを含みます。
- 原則 — 「何があってもこれは守る。」決して破ってはならない規範。なぜ(why) に該当します。
ここまでは明確でした。しかし、ある日疑問が湧きました。この3つは正確にどう異なり、どのように一体となって機能するのか？ 特に中央にある「プロジェクト記録」です。これは手順でも原則でもないのに、一体何なのでしょうか？
この質問一つを抱え、しばらく考え続けました。思ったよりも深く。
1. 手順と記録は「品詞」が異なっていた
まず手順とプロジェクト記録を並べて見てみました。すると、両者は全く品詞が異なる存在でした。
手順は動詞です。「これをどうするか。」状態がありません（ステートレス）。呼び出されれば実行され、終われば消えます。毎回同じように動きます。関数のようなものです。
プロジェクト記録は名詞です。「今どこまで来たか。」状態を内包しています。昨日の決定、今日の進行、積み重ねてきた歴史がすべて含まれています。常に累積されます。データのようなものです。
これを悟ると、両者の関係が見えてきました。競合するのではなく、直交します。一方は横軸、もう一方は縦軸です。そして決定的に — 手順がプロジェクト記録を読み込み、更新します。 オブジェクトとメソッドの関係と全く同じです。記録（データ）があり、手順（関数）がそれを扱います。
では、3番目の「原則」は？これは上記の両方を見下ろしています。手順も記録も原則を破ってはいけません。つまり、3つの階層がこのように座標系をなすのです。
原則 (上から統制)
│
記録(状態) ┼ 手順(行為)
│
ここで一つ明確になったことがあります。手順と原則は業界で一般的な概念です。手順はランブック(runbook)であり、原則は設計原則や規約です。しかし、中央の「プロジェクト記録」は…これは一体何と呼ばれているのだろう？ 疑問が募りました。
2. そこで調べてみたのですが、名前がありませんでした
「プロジェクト単位で状態と歴史をすべて内包する生きている文書。」このようなものを業界では何と呼ぶのだろうか。調べてみたところ、ぴたりと当てはまる単一の用語はありませんでした。 その代わり、既に確立された複数のパターンが一つに融合した形でした。
- ドメイン駆動設計(DDD)の「境界づけられたコンテキスト(bounded context)」 — 一つの凝集された領域を丸ごとまとめる概念。私のプロジェクト記録一つ一つがまさにこれでした。
- イベントソーシング(event sourcing)の「追加のみのログ」 — 修正・削除せずにイベントを積み重ねるだけで、現在の状態はそのイベントを合計して得る方式。私の記録の「履歴」がそのままこのパターンでした。
- AIエージェントの「長期記憶(long-term memory)」 — エージェントが文脈を失わないように永続的に保持するストレージ。私の記録の用途がまさにこれです。
- さらに、通常は別々に存在する文書 — 設計決定記録(ADR)、障害振り返り(post-mortem)、目標・指標(OKR)、リスク台帳 — これらを私はプロジェクト一つにつき一つの文書にすべて詰め込んでいました。
業界ではこれらがそれぞれ別々に存在します。決定記録は決定記録として、振り返りは振り返りとして、指標はスプレッドシートとして。しかし、私は知らずにそれをプロジェクト単位で凝縮してしまったのです。
決定的な違いも一つありました。既存のこれらの文書はすべて人間が一次読者です。私のものはAIエージェントが一次読者です。エージェントが仕事を始める際に最初に読むのがこの記録だからです。
そこで導き出された結論はこれでした。私が作ったものはまだ業界に名前がついていない、まさに現れつつあるパターン(emerging pattern) だ。一文でまとめると — 「プロジェクト」を頭の中や散らばったファイルではなく、読み書き・索引付け可能な一つのデータ構造（一級オブジェクト）に昇格させたもの。 通常、組織における「プロジェクト」は、人の頭の中や散発的な文書に散らばっていますよね。私はそれを結晶化してオブジェクトにしてしまったのです。
ここまで来ると、なぜ私が最初にそんなに迷ったのかが逆に見えてくるようになりました。
3. フォルダを100個作って満足したのに、すべて死んでいました
最初、私は誰もがやることをしました。テーマ別のフォルダです。戦略/ インフラ/ 技術/ 哲学/。分野別にきっちり区切って、どれほど満足したことか。
一週間後、何が起こったと思いますか？誰もそのフォルダを開きませんでした。 エージェントも、私もです。
今なら理由が分かります。テーマ別フォルダは図書館だからです。本を棚にしまう構造。しかし、図書館の宿命は放置です。戦略/フォルダに戦略文書を入れた瞬間、それは死にます。二度と取り出されず、更新もされず、一ヶ月後には現実と食い違っています。静的な分類は時間に耐えられません。
前述の答えがここで光を放ちました。問題は分類の基準だったのです。「テーマ」で分けるのではなく、「ライフサイクル」で分けるべきでした。「これは何の分野だろう？」ではなく、「これはどのプロジェクトの生きている流れだろう？」 と。そうすることで、同じ文書でも死なずに参照され続け、更新されます。資産とは結局、働き続けるものだからです。墓の中の文書は仕事をしませんが、流れの中の文書は仕事をします。
4. 結局、ルールはたった一つに絞られました
そこでプロジェクト記録を運用するルールを色々と作ってみましたが、最後まで生き残ったのは一つでした。
重複は許容するが、欠落は禁止する。
最初は逆をやっていました。「重複は非効率だから、事前に整理しよう。」しかし、これが落とし穴でした。何が重要かも分からない状態で枝葉を刈り取るので、後で必要なものが既に消えてなくなっているのです。
これがなぜ正しいのかは、実は数学です。 2つの実数のコストが全く異なるからです。
- 欠落は不可逆です。 一度書き残さなかったものは永遠に復元不可能です。その瞬間の文脈はそのまま蒸発します。
- 重複は可逆です。 重なったものは後でいつでも統合し、削減できます。一時的に場所を占める余剰に過ぎません。
コストが非対称なので、答えは決まっています。迷ったら、とりあえず残せ。 これは、自然と工学が既に検証したパターンです。DNAもまず遺伝子を複製しておき、後で分化させます。その余分なコピーが新しい機能の材料になります。Gitもとりあえずすべてコミットし、後で整理します。まず保存、後で凝縮。事前に最適化はしません。
5. これが「生きている」という意味です
では、積み重ねるだけだと散らからないのか、と？ここに核心があります。
効率は積み重ねながら凝縮するものであり、積む前に閉じ込めるものではありません。
十分に積み重なれば、その中で重複が自然と明らかになります。その時に統合すれば良いのです。システムが自ら矛盾を発見し、自ら整理し、自らルールを修正します。初期には重複と非効率に見えたものが、時間が経つにつれて凝縮され、進化していくのです。これが死んだ図書館と生きているシステムの違いです。
そしてここで、先ほどの3つの階層が再び出会います。日々の作業記録がプロジェクト記録に移され（状態）、そこから繰り返される教訓が手順として固まり（行為）、決して破ってはならないことが明らかになれば原則へと昇華します（規範）。一日分の会話 → プロジェクト資産 → 手順 → 原則。 ただ流れていってしまう一瞬が、段階を踏んで上がっていくことで、ますます強固な資産へと結晶化されていくのです。
私にとって、この問いが最も重要でした。「今日行った仕事を、どのように放置せずに資産として確立するか？」 3階層の文書システムは、結局この問いに対する答えだったのです。
6. 正直な告白 — まだ解決できていない課題
ここまで読むと、かなりそれらしく聞こえますよね？正直に言います。
このシステムが生きている本当の理由は、私が毎日目を通しているからです。凝縮する時期が来たか、何が抜けているか、どこがずれているか — 結局今は私が心臓の役割を果たしています。
だから次の課題は明確です。この生命力を自動化できるか？ 私が見ていない日でも、システムが自ら欠落を感知し、凝縮を始めるようにできるか。「欠落禁止」を人間ではなくシステムが保証するようにすることです。生きているものの究極は結局自ら動くことだからです。そこまで行けば、それはもはや私の文書整理法ではなく、真のオペレーティングシステムとなるでしょう。
長い文章でしたね。まとめると — 手順・記録・原則という3階層から始まりましたが、中央の「プロジェクト記録」の正体を追いかけるうちに、名前のないパターンと生きているシステムというところにまで行き着きました。
皆さんにお聞きしたいです。もしプロジェクトをこのように**「一つのデータ構造（一級オブジェクト）」として扱った**方がいらっしゃいましたら、それを何と呼んでいますか？そして、その「凝縮する判断」まで自動化された方がいらっしゃいましたら、ぜひお話を聞きたいです。私はちょうどそこで立ち止まっていますので。
読んでいただきありがとうございます。🙏
筆者は写真の仕事を経て、現在はAIツールで小さな事業を立ち上げています。