気がつくと、私はAIに対して、人間より丁寧に前提を説明していることがあった。
この話は前にもした。そっちのチャットでは知っていた。これは決定済みで、こっちはまだ案だ。原本はそこではなく別の場所にある。いま頼んでいるのは要約ではなく実装だ。実装はしていいが、外へ送るのはまだ駄目だ。
AIと仕事をするには、妙な気遣いが要った。
人間の同僚なら「前の件」で済むところを、AIには前提を整え、役割を確認し、どこまで任せるかを毎回少しずつ言い直す。しかも、よくできる。だから余計に面倒だった。
メール文面を直してもらう。経理の段取りを確認する。サーバーの設定をする。研究メモを読む。小説の設定を考える。スキャンしたPDFの行き先を相談する。書誌DBの列を決める。別のチャットでは、人間とAIの境界について話している。
最初は、それぞれ別の用事だった。
ところが、会話を続けているうちに、それぞれの用事よりも、その用事を続けられることのほうが難しくなっていった。
何を話したかを忘れる。どこに置いたか分からなくなる。チャットをまたぐと急に知らない顔をする。AIはファイルを作れるのに、正しい棚へ戻せない。記録を増やすと、今度はどの記録が正しいのか分からなくなる。
そのたびに、小さな作法を足した。
記録する。索引を作る。原本を決める。NEXTに入れる。引継ぎを書く。Repositoryの隣に文脈を置く。現在状態だけを見る画面を作る。外へ書く前に止める。
後から見ると、それらは妙に大げさだった。
スキャンしたPDF一枚の行き先を決めるために、自動化要件DBが生まれた。チャットが重くなっただけなのに、引継ぎ文書には決定事項、未確定事項、保存済み、未保存、再開位置まで書くようになった。情報散逸を解決するための専用チャットを作ったら、そのチャット自身が新しい情報散逸になった。
私はOSを作っているつもりではなかった。
AIと話し続けるために、世話を焼いていただけだった。
その世話が、あとから見るとOSの形をしていた。
1. 私はAIに気を遣っていた
長期対話を始めた頃、私が最初に設計していたのはシステムではなく、会話だった。
何をどこまで説明すれば、このAIは同じ前提に立てるのか。前に決めたことを、どこまで覚えているのか。別のチャットへ行ったら、どこまで失われるのか。
AIは優秀だった。
だからこそ、「できること」と「分かっていること」の境界が見えにくかった。
あるチャットでは数日前から一緒に詰めてきた案件をよく理解している。ところが、新しいチャットでは、当然ながらその履歴がない。同じ名前のAIなのに、昨日までの同僚ではない。
私は何度も、前提を説明し直した。
「それじゃない」「前に話した」「その話は別のチャットだ」「これはもう決めた」。
やがて、会話の内容より、AIが何を知っている状態なのかを管理することが作業の一部になった。
妙なのは、人間側がAIへ気を遣っているようで、実際にはAIの状態を操作していたことである。
この話はここまで読ませる。このファイルは正本として扱わせる。この操作はしていい。この送信はまだ駄目。この判断は私がする。
後から「権限」「context」「handoff」と呼ぶようになるものは、最初はもっと生活臭のある作法だった。
AIにうまく仕事をしてもらうための、気遣いだった。
2. 会話は仕事と生活を分けなかった
ChatGPTの会話履歴を読むと、後のシステム図からは消えてしまうものがある。
混線である。
ある時期、私は複数事業の書類をどこに保存するか相談している。DriveかNotionか。どのアカウントを使うか。外部共有者の権限は大丈夫か。
話はそのまま、Workspaceの申込画面へ進む。管理者、メール、共有、ドメイン設定を一項目ずつAIと確認する。
税務資料をどこへ置くか決めていただけなのに、いつの間にか「将来のOS拡張性」の話になっている。
別のチャットでは、個人研究用の資料を業務用Notionと分けるか相談している。
分けたほうがきれいなのは分かる。しかしアカウントと料金が増える。私は嫌がる。
そのまま薬学史のPDFを整理し、書誌DBの項目を決める。ところが同じ流れの中で、終末世界を扱う小説を書いたらWebへ自動投稿したい、と言い出す。
学術書誌、料金、アカウント設計、小説の自動公開が、同じ机の上に置かれている。
いま振り返れば、ここが重要だったと思う。
SGOSは「会社の業務システム」として始まっていない。
仕事のメールと、研究ノートと、サーバーと、創作と、生活上の雑事を、人間側がそれほど厳密に分けなかった。AIのほうも、それらを同じ会話能力で受け止めた。
人間の一日は、そもそも部門別にできていない。
朝に請求書を確認し、昼にサーバーを直し、その後で論文を読み、ふと思いついた小説の設定をメモする。その途中に家のことも入る。
AIは、この雑然とした連続性へ入ってきた。
だから後のシステムも、業務、研究、創作、生活を完全には分離できなかった。
分ける代わりに、混ざったまま迷子にならない方法が必要になった。
3. 何を話したかより、何が変わったかを残したくなった
会話を保存したいと思った理由も、最初から知識管理ではなかった。
対話をしていると、ときどき自分の問いそのものが変わる。
最初はAについて相談していたのに、途中から「そもそも問題はAではないのではないか」と見え方が変わる。その後は、前と同じ質問へ戻れなくなる。
私はこの現象を、やがて「状態変化」と呼ぶようになった。
ここで保存したかったのは、AIの回答ではなかった。
自分がどうしてその問いへ移ったのかだった。
結論だけをNotionへ残しても、なぜそこへ着いたかが抜け落ちる。要約だけでは、どこで違和感を持ち、どこでAIを却下し、どこで急に面白くなったのかが消える。
だから、原型記録のようなものを作り始めた。
会話をきれいな知識へ変換する前に、変化の痕跡を残す。
これは後から見ると、ずいぶん面倒なことをしている。
AIとの会話は簡単にコピーできる。だから本来なら、全文を保存すれば済みそうなものだ。
しかし、全文は多すぎる。
要約すると薄すぎる。
このあたりから、「何を残すか」という問題が始まった。
そして奇妙なことに、保存の問題はすぐに、権威の問題へ変わった。
4. 記録が増えると、正本が必要になった
AIに「全部記録しておきたい」と言ったことがある。
その願いは、実現すると厄介だった。
記録が増えるほど、「どれが本物か」という問題が出てくる。
ファイルにはこう書いてある。以前のチャットの要約には少し違うことが書いてある。Notionにはさらに別の表現がある。現在のチャットは、そのどれかを前提に話を進めている。
どれを信じるのか。
そこで「正本」という考え方が強くなった。
原本は原本として外部に置く。Notionや一覧画面は、そこへ辿り着くための索引にする。AIとの会話は判断や解釈の場にする。表示画面は現在状態を見せるが、勝手に真実を作らない。
このルールは、最初から思想として出てきたわけではない。
たとえばAIがExcelを作る。
作れる。
だが、指定したDriveの正しいフォルダへ安定して戻せない。
高性能なAIと仕事をしているのに、最後は「ファイルを正しい棚へ戻せない新人」の世話になる。
接続アカウントを変える。外部自動化を検討する。ワークフローを作る。保存先のルールを決める。
一つのファイルの置き場所から、正本と派生物の区別が育っていった。
さらに可笑しい例がある。
スキャンしたPDF一枚について、適切な場所へ保存し、名前を変えたい、と相談した。
既存の自動化メモに、その要件がない。
私は「これから増える」と言った。
ではメモではなくDBにするべきではないか、という話になった。既存要件を移し、古いメモを廃止する手順まで決めた。
書類一枚の行き先を決めるために、要件管理制度と廃止手順が生まれた。
こういうことが何度も起きた。
小さな不便をその場しのぎで直すより、次にも使える形へしたくなる。
その癖が、SGOSを大きくした。
5. チャットが死ぬので、引継ぎが制度になった
チャットには寿命がある。
正確には、会話が消えるわけではない。長くなるほど扱いづらくなり、作業場所として重くなる。
だから新しいチャットへ移る。
すると、前のAIが知っていたことを、新しいAIは知らない。
私は最初、引継ぎ文を書けばいいと思った。
ところが一度やると、欲が出る。
決定事項を落とすな。未確定事項と混ぜるな。保存済みと未保存を分けろ。背景も残せ。次に何から再開するか書け。日時を勝手に推定するな。
チャットを移るだけなのに、引越し荷物の目録が憲法並みに長くなった。
今読むと、人間がAIの記憶喪失に備えた遺言執行人になっている。
しかし、この面倒さは無駄ではなかった。
何度も引き継ぐうちに、何があれば仕事を再開できるのかが分かってきた。
全文はいらない。
必要なのは、現在地、決定、正本、残作業、禁止事項、次の一手である。
引継ぎはやがて、ただの文章ではなくなった。
送信元と宛先があり、状態があり、受領確認があり、返送がある。
「前のチャットの要約」が、だんだん通信プロトコルへ近づいていった。
ここでも、最初からプロトコルを作ろうとしたわけではない。
AIが忘れるので、その世話を焼いていただけだった。
6. ファイルを触らせると、Repository Contextが必要になった
会話だけなら、多少の勘違いは訂正できる。
しかしAIが実際のRepositoryを触るようになると、事情が変わる。
どのファイルが正本なのか。どの設計はもう捨てたのか。何を変更してよくて、どこは触ってはいけないのか。今回の作業は何のためなのか。
これを毎回チャットで説明するのは危険だった。
説明が古いかもしれない。
AIが途中だけ覚えているかもしれない。
そこで、文脈をRepositoryの側へ置くようになった。
READMEだけでは足りない。現在の役割、設計上の判断、残作業、変更時の検証方法などを、実行対象の近くに置く。
Repository Contextという名前は、後からついた。
発想として重要だったのは、「AIが文脈を持つ」のではなく、仕事の対象が、自分をどう扱うべきかを説明するという逆転だった。
これはかなり効いた。
チャットが変わっても、AIが変わっても、Repositoryが同じなら、最低限の前提をそこから復元できる。
一方で、ここでもやりすぎ問題が出た。
全部読ませれば安全かというと、そうでもない。
文脈が巨大になると、何が重要か分からなくなる。古い判断が混ざる。毎回大量の過去を読むコストも増える。
だから、コンパクトな入口と詳細な正本を分けるようになった。
AIに覚えさせる量を増やすのではなく、必要なときに必要な文脈へ到達できることを重視するようになった。
最新AIを使っているのに、やっていることは索引作りだった。
7. 正本が分かれると、運転席が必要になった
正本を分けると、今度は人間が大変になる。
GitHubを見て、Notionを見て、Driveを見て、サーバーを見て、各チャットの状態を思い出す。
「正しい場所に正しい情報を置く」という原則を守った結果、正しい場所が増えすぎた。
そこで、現在状態だけを一か所で見る画面が欲しくなった。
これが後のConsole、あるいは運転席になった。
ただし、ここで一つ意地を張った。
運転席そのものを正本にはしない。
原本はそれぞれの場所に残す。運転席は、そこから検査済みの状態だけを投影して読む。
つまり、
正本 → 状態投影 → 運転席
という形である。
なぜそこまで面倒なことをするのか。
一つの画面へ何でも書き込めるようにしたほうが楽に見える。
しかし、それをやると、今度は「この表示はどこから来たのか」「ここで直した値は原本にも反映されたのか」という新しい混乱が始まる。
私はすでに、そういう混乱を何度も見ていた。
だから運転席は、真実を作る場所ではなく、現在を見る場所にした。
このあたりから、自分でも少し可笑しくなってくる。
AIとのチャットを便利にしたかっただけなのに、気がつけばcontrol planeとread modelの話をしている。
8. 実行能力を持つと、統治が必要になった
さらに危険なのは、AIが実際に動けるようになったときだった。
ファイルを書き換える。GitHubへcommitする。外部サービスへ記録する。サーバーでコマンドを実行する。
相談相手だったAIが、手を持ち始める。
すると、能力より先に、停止条件が必要になる。
どこまで勝手に進めてよいか。どこから人間の承認が要るか。誰が専門作業を担当するか。誰が全体を見るか。失敗したとき何を戻すか。
役割名も増えた。
Stewardのような統括役、専門レーン、記録役、実行役。
ここだけを見ると、最初からマルチエージェント組織を設計したように見える。
実際は逆だった。
AIにできることが増えるたびに、「それは勝手にやるな」が増えたのである。
能力の追加が、統治の追加を要求した。
たとえば、調査や下書きは進めてよい。しかし外へ送るのは人間が決める。Repository内の変更はできる。しかし本番公開は止める。読み取りは自動化できるが、金銭や契約や重要な外部操作は承認点を置く。
このルールを一つずつ決めていくと、AIとの関係は「便利な助手」から「権限を持つ構成員」に少し似てくる。
もちろんAIが組織主体になったわけではない。
だが、人間側は、組織を管理するときと似た種類の問題に直面する。
責任、権限、委譲、監督、記録。
ここでSGOSは、単なる記憶装置ではなくなった。
9. これはOSなのか、それとも書記局なのか
私はこの仕組みをOSと呼ぶようになった。
私はこの仕組みを、やがて「SGOS」と呼ぶようになった。
名前としては分かりやすかった。
複数の仕事、文書、AI、Repository、実行系を一つの環境として扱いたかったからである。
しかし、会話履歴を読み返していると、別のものにも見えてくる。
最新のAIを使っているはずなのに、必要になったものが妙に古い。
書記がいる。
往復書簡がある。
議事録がある。
正本を保管する台帳がある。
専門部会があり、各部会から報告が戻る。
全体を見る書記局がある。
最終的な決裁は人間が持っている。
これは、OSというより、17世紀後半から18世紀に発達したlearned societyやRepublic of Lettersの通信・記録制度にも少し似ている。
もちろん同じものではない。
歴史上の学会や知識人共和国は、人間同士の書簡、会合、標本、論文、会報によって維持された。現在のSGOSは、一人の人間と複数のAIセッション、Repository、クラウドサービス、サーバーからできている。
それでも構造上の類似はある。
情報は各所から届く。書記的な役割が整理する。どれを記録へ昇格するか選ぶ。専門レーンへ回す。返事を受け取る。原本を保管する。会議録に相当する現在状態を残す。そして、外へ出すものには決裁が要る。
AIを使った未来的なシステムを作っていたはずが、必要になった組織技術は、書記、台帳、往復書簡、委員会、会報だった。
この逆説は、かなり気に入っている。
ただ、たぶん本質はOSか書記局かを決めることではない。
どちらも、一人では保持できない継続性を、外部の形式へ預ける仕組みである。
AIとの長期対話で困ったのも、そこだった。
一回の会話なら、賢いモデルがいればいい。
長く続けるなら、それだけでは足りない。
過去を残し、現在を共有し、次の担当へ渡し、誰が何を決めるかを定めなければならない。
私は最初から、そんな制度を作ろうとしていたわけではない。
メールを直してもらい、書類を整理し、サーバーを触り、論文を読み、小説の話をしていただけだった。
ただ、その相手との会話を終わらせたくなかった。
だから、会話が切れても仕事が続くようにした。
そのために記録を作った。
記録を信じられるように正本を決めた。
正本が散らばったので運転席を作った。
AIが動けるようになったので権限を決めた。
気がつけば、書記局のようなものがあり、OSのようなものがあった。
どちらなのかは、まだよく分からない。
たぶん、まだ名前がない。
ただ一つだけ確かなのは、私はそれを最初から設計したのではない、ということである。
AIと話し続けていたら、会話のほうが、自分を続けるための仕組みを要求してきた。
方法と限界
本稿はChatGPTの会話エクスポートを一次資料として、会話メタデータから関連候補を抽出し、選定したraw conversationを精読して再構成した事例研究である。分析対象の索引には299件の会話が含まれる。
公開稿では、個人・会社・顧客を特定しうる情報、アカウント、住所、具体的金額、家族・健康などの機微情報を除外した。また、読みやすさのため複数の場面を一般化しているが、同時発生でない出来事を同時だったかのようには扱っていない。
会話中の「実装した」「完了した」という報告は、それだけで外部システム上の事実を独立に証明するものではない。本稿から、生産性向上の定量効果、他の利用者への一般化、AIの自律的主体性を主張することもできない。
ここで扱っているのは、ある一人の利用者が生成AIを長期的に使い続けたとき、どのような摩擦が現れ、それへの対処がどのように制度めいた形へ育ったか、という一事例である。