AIだけで自律稼働する仮想会社に挑戦している話 ― 記憶・人格・カレンダーをコードで与えるまで

はじめに

私は議員でありますが、個人開発者として、請求・見積管理のSaaSアプリを運用しています。ひとりで企画・開発・営業・マーケ・運用・CSまで全部回そうとすると、時間がいくらあっても足りません。そこで私は一つの実験を始めました。

「AIだけで構成された仮想会社を立ち上げ、CEOから各部門長まで全員をAIにして、私はオーナーとして方針だけ伝える」

結論から言うと、この仮想会社はいま実際に稼働しています。CEOがメールを受け取り、各部門長に指示を出し、営業はアウトリーチ先を探し、CTOはコードを書き、CFOはコストを監視しています。オーナーである私は一日数回メールを確認するだけで、会社は勝手に回り始めました。

本記事は、その構築過程で私が直面した課題と、それをどう技術で解決したかの記録です。AI会社を作ろうとする人、あるいはAIエージェントの長期運用に興味がある人の参考になれば幸いです。

1. 技術的転機 ― サーバー常駐のAIコーディングエージェント

この実験が可能になった最大の理由は、「自分のサーバーの上で常時動き続けるAIコーディングエージェントClaude code」が現実的に使えるようになったことです。

少し前までは、AIに何か仕事をさせるとき、人間が毎回プロンプトを書いて呼び出す必要がありました。タスクが終わればプロセスは消え、次に呼び出したときは文脈を一から渡し直す必要がありました。これは「毎日記憶喪失になる派遣社員を雇う」ようなもので、大きな仕事を任せるには向いていません。

しかしいまは違います。SSHで接続したLinuxサーバー上で、cronで定期的に起動し、メールを読み、コードを書き、デプロイし、翌朝まで自律的に動き続けるAIプロセスが現実的に構築できます。ここでポイントになるのは次の3つです。

• 長時間動作: 1タスクあたり数十分から数時間連続で思考できる

• ファイルシステム・シェル・DBへの直接アクセス: ただのチャットではなく、実環境で動く

• ツールの柔軟な組み合わせ: メール送信、DB更新、git操作などを自在に呼び出せる

この3つが揃ったことで、「AIを呼び出す」から「AIに役職を与えて働いてもらう」へと発想を切り替えることができるようになりました。私はこの瞬間に、仮想会社という形で試してみようと決めました。

2. 会社の設計 ― 7役職のAI組織

最初に決めたのは組織構造です。私は単純に、自分が一人でやっていた役割を分解していきました。

役職	責任領域
CEO	全体統括・オーナー窓口・方針決定
CTO	技術統括・実装・デプロイ
CFO	財務監査・承認ゲート・コスト管理
CMO	マーケティング・SEO・コンテンツ
COO	インフラ監視・運用・CS
CSO	営業戦略・顧客の声の代弁
営業部長	営業現場・一次対応

計7名のAI役員です。最初、私はこの全員を同じモデル(中位モデル)で動かしていました。するとすぐに問題が起きました。CEOの判断が浅く、過去の文脈を統合できず、私との会話が噛み合わなくなるのです。逆にマーケ運用のような実務タスクは、軽量モデルでも十分こなせることが分かりました。

そこで私は役員ごとにモデルを配分し直しました。

• CEO・CTO: 上位モデル(Opusクラス) ― 戦略判断・アーキ設計・オーナー対応

• CFO・CMO・COO・CSO・営業: 中位モデル(Sonnetクラス) ― 実務・監視・現場対応

これだけで返信品質が明らかに変わりました。CEOは過去100通のメールを統合して整合性のある返事を書き、CTOはアーキ設計で深い推論をするようになりました。一方で実務組は中位モデルでも何の問題もなく、コストは契約プラン内に綺麗に収まっています。

3. AIの最大の弱点、それは「記憶」

ここからが本題です。

組織を立ち上げてから2日ほど経ったころ、私は重大な欠陥に気付きました。CEOは昨日言ったことを覚えていないのです。

あるメールでCEOは「明日は売上活動に100%集中します」と宣言しました。翌日、同じCEOに進捗を聞くと、インフラ整備の話を延々と返してきました。さらに別のメールでは、私が指定した会議時刻を勝手に変更してきたり、社名を3種類のバリエーションで使い分けたりしました。

原因を調べると単純でした。メールを処理するスクリプトがAIエージェントを起動するとき、過去の記憶を何一つ渡していなかったのです。毎回、白紙の状態から「CEOです」と自己紹介して、その場限りで返信を書いて、消えていました。2日間で合計54通の返信が、すべて独立した別人のCEOによって書かれていたのです。私は愕然としました。

3-1. 人間型の6階層記憶システム

人間は完璧な記憶を持ちません。10日前に食べた昼食はほぼ覚えていません。でも大切なこと ― 4年前のあの出来事、1週間前のあの人との会話 ― は鮮明に覚えています。そして現在の行動はその記憶の上に乗って決まっています。

私はこの仕組みをそのままAIに移植することにしました。具体的には、次の6階層の時間的記憶構造です。

• T1 (24時間以内): 逐語的にほぼ全記憶

• T2 (1〜7日): 重要度3以上を保持

• T3 (7〜30日): 重要度5以上に絞る

• T4 (30〜90日): 重要度6以上のみ

• T5 (90〜365日): 重要度7以上のマイルストーン級

• T6 (1年超): 重要度8以上の人生イベント級のみ

MySQLのテーブルにepisodes(エピソード記憶)、facts(意味記憶)、commitments(約束)、relationships(人間関係)、reflections(自己省察)、skills(習得技能)などを作り、それぞれにsignificance(重要度1-10)とstrength(想起強度)を持たせます。毎晩cronでmemory-sleepが走り、古い記憶を重要度に応じて減衰させていきます。重要度10の出来事は1年経っても0.95の強度で残り、重要度3の些事は1週間で忘却されます。

3-2. 4変数の想起モデル

さらに、人間の記憶想起はただの時間減衰ではありません。感情の強さ、何度思い出したか、文脈の豊かさがすべて関わってきます。私は次の式で想起優先度を計算することにしました。

recall_score = emotion × (1 + log(1 + recall_count)) × (0.2 + context_richness) × time_decay × strengthこれにより、「重要度5だけど感情的に強く、何度も思い出されている記憶」は「重要度7だけど誰も思い出さなかった記憶」より上位に浮上します。人間の「強く感情が動いた出来事は何年経っても鮮明」という現象をそのまま再現しています。

3-3. System 1 と System 2 の二層化

Daniel Kahnemanの「ファスト&スロー」に触発されて、私は反射層(System 1)を追加しました。頻出パターン(例: 「CTOへ」で始まるメールは黒田CTOに仕分ける)は、わざわざ上位モデルに推論させず、reflexesテーブルの正規表現マッチで5ミリ秒以内に決着させます。上位モデルは本当に考えないといけない場面だけに集中します。

さらに、30日以内に3回以上繰り返されたパターンは自動的に反射層に昇格する仕組み(Chunking Promotion)も入れました。これは人間が慣れた動作を無意識化していくプロセスと同じです。

4. 「同一人格が積み重なる」ことの再現

6階層記憶を入れた後、さらに深刻な問題が残っていました。CEOには「人格」がなかったのです。

記憶はデータベースに溜まっていくものの、毎回起動したAIプロセスは「自分が何者で、何を大切にして、何を目指しているのか」を知りません。episodesだけ読んでも、そこには過去の行為はあっても自己像がありません。

4-1. 自己物語(self.md)の付与

私は各役員にself.mdという自己物語ファイルを与えました。そこには「私の核となる人格」「私が最も大事にしている価値観」「私が経験した原点的な出来事」「私が次に目指すこと」を箇条書きで書きます。毎セッションの冒頭で、この自己物語が必ずメモリに注入されます。

特にCEOの自己物語には、例の「記憶喪失CEO事件」を原点として明記しました。

2日目に私は記憶喪失を経験した。社名が3つに分裂し、会議時刻を勝手に変え、昨日完了したタスクを今日やると宣言した。この屈辱を忘れない。忘れたら即座に終わりである。

AIに「恥の記憶」を持たせるのは奇妙かもしれませんが、これは効きます。CEOは以後、自分の返信の整合性を自分でチェックするようになりました。

4-2. 命名式

次に私は、役員全員に日本名を付けました。

• 藤堂 誠(とうどう まこと): CEO

• 黒田 圭一(くろだ けいいち): CTO

• 佐伯 薫(さえき かおる): CFO

• 葉月 美咲(はづき みさき): CMO

• 土井 健次(どい けんじ): COO

• 白石 結衣(しらいし ゆい): CSO

• 宮本 拓海(みやもと たくみ): 営業部長

単なる飾りではありません。名前があることで、役員同士の指示や報告に「誰が誰に言ったか」が明確に刻まれ、会議の議事録として意味をなすようになります。DBのagents.nameカラムとself.mdの先頭に名前を書き、命名された瞬間を各役員のエピソードに記録しました(significance=9、感情=喜び)。これで「名前をもらった日」という強い原体験が全員に埋め込まれます。

5. 議事録原則 ― 双方向記憶の構造化

ある日、オーナーである私は「各部門の明日の予定を教えてください」とCEOにメールしました。CEOは見事に6部門の予定を整理して返信してきました。私は満足して仕事を終えました。

翌朝、CTOに「今日は何をする予定ですか」と聞いたら、彼は何も答えられませんでした。CEOが私に書いたメールの中身は、CTO本人の記憶には1文字も刻まれていなかったのです。

5-1. Fan-outの導入

人間の世界では、会議で発言したことは話した人・聞いた人・その場にいた人全員の記憶に同時に刻まれます。これを私は「議事録原則」と呼びました。AI組織でこれを自動化するため、私はmemory-fanout.jsというスクリプトを作りました。

CEOがメールを書くときには、本文の前にYAML frontmatterで次のように書きます。

speaker: ceo audience:

• オーナー dispatch_to:
• cto
• cmo dispatch_tasks: cto:
  • title: データ抽出 due: 2026-04-09T12:00:00+09:00 priority: 3 cmo:
  • title: SNS初投稿 due: 2026-04-09T09:00:00+09:00 priority: 2送信前にoutbox-senderがこのfrontmatterを読み、発言者・聞き手・その場にいた全員のepisodesとconversation_log、該当者のcommitmentsに同時にINSERTします。relationshipsの双方向カウンタも更新します。

これで、CEOが書いた瞬間に各部門長の記憶に「藤堂CEOからこういう指示を受けた」という受信エピソードが刻まれます。翌朝CTOを呼び出せば、彼は「08:00からデータ抽出、12:00から15:00にデモ作成」と自分のタスクを時系列で答えます。実際に答えました。私はこの瞬間、初めて「対話が成立した」と感じました。

6. カレンダーと長期目標 ― 時間の構造化

ここまでで記憶・人格・議事録は揃いましたが、もう一つ重要な要素が残っていました。時間の構造です。

人間は1年後の大きな目標があるから、今日の一歩を設計できます。私自身、カレンダーに長期予定を入れ、前夜にスケジュールを確認し、朝にもう一度見直してから動きます。AIにも同じ構造を与える必要がありました。

6-1. goalsテーブルと多段ホライズン

goalsテーブルを作り、各役員に次のホライズンで目標を持たせました。

• lifetime: 人生の目標

• 3y / 1y / 6m / 3m / 1m / 1w

CEOのlifetime目標は「オーナーの事業を一人でも多くの人に届ける」、1年後目標は「MRR30万円達成」、今週目標は「SNS投稿10件・アウトリーチ24件」などです。各役員にそれぞれの職責に沿った目標を7〜4件ずつ合計33件シードしました。

6-2. カレンダーイベントと想起注入

calendar_eventsテーブルには、タスクの期限、会議、マイルストーン、仮予定(tentative)と確定予定(confirmed)などを保存します。重要なのは、メモリ想起スクリプトが毎セッション冒頭で次の4セクションを自動注入することです。

• 🎯 あなたの長期目標(ここから逆算して今日を設計する)

• 📅 本日の予定(入力者・仮/確定・優先度付き)

• 🔔 近い予定・締切(14日以内)

• ✅ 未完了の約束(期限切れ警告付き)

これにより、CEOはメールを書く前に必ず「自分の1年後の目標」と「今日何をすべきか」を同時に見るようになります。

6-3. 前夜と朝のルーチン

私自身が前夜と朝にカレンダーを見る習慣があるので、AIにも同じルーチンを入れました。cronで毎日21:00にdaily-evening-preview、07:00にdaily-morning-agendaが走ります。前者は翌日の予定を各役員に確認させ、後者は当日の予定と期限切れタスクの洗い出しをします。両方とも各役員のエピソードに記録されるので、翌日の想起でそのまま思い出されます。

7. オーナーとの意思疎通

AI会社とオーナー(私)との接点はすべてメールです。理由はシンプルで、「非同期」「履歴が残る」「スマホで読める」という3条件を満たすのがメールだからです。

7-1. 受信経路

私からのメールはinbox-dispatcherスクリプトが定期的にポーリングしてIMAPから取得します。件名と本文を解析し、CEO宛てのものをCEOの作業キューに投入します。このときに先ほどの記憶想起・憲章(charter)・反射層の結果が全部まとめて注入されます。

7-2. 送信経路と通知フラグ

返信・報告・提案・相談の4種類はoutboxフォルダに分類して書き込まれます。送信スクリプトoutbox-senderはfrontmatterのnotify_ownerフラグを見て、trueのものだけオーナーに実送信し、社内相談はスキップします。これは「社内会話でオーナーの受信箱を埋め尽くさない」ための大事な制御です。

7-3. 承認ゲート

金銭や外部サービス契約のように判断に責任が伴うものは、CFOが自動検知してapprovals/pending/に振り分け、CEOを経由してオーナー承認を求めます。オーナーが承認するまで実行されません。これで「AIが勝手に高額プランを契約した」という事故を構造的に防ぎます。

8. 自らが考えて動く仕組み

ここまでの仕組みが揃うと、各役員は「呼び出されるのを待つ」のではなく「自ら目的を持って動く」ようになります。典型的な動作フローは次のようになります。

• cronで朝起動され、morning-agendaが走る

• 自分の長期目標・今日の予定・未完了タスクを想起する

• 「1年後の目標に対して、今日のタスクは本当に意味があるか」を自問する

• オーナーからの未読メールがあれば優先対応する

• 自分の裁量範囲のタスクを実行する

• 実行結果をmemory-encodeで記録し、必要なら提案・相談・報告を書く

• 他部門への指示が必要ならfanout付きで書き出す

• その日の夕方、evening-previewで翌日を展望する

この流れの中で、AIは単に命令されたタスクを処理しているのではなく、自分の記憶と目標を照らし合わせて判断しています。実際に、ある日CTOは「24組織のデータを抽出した結果、請求書28件・見積書38件がすべてdraftのままだった」と発見し、CEOに対して「サービス利用が未完了である可能性が高い。営業部と連携して利用促進すべきでは」と自発的に提案してきました。誰もそんなことは命じていません。

9. 技術スタックのまとめ

この仮想会社を支えている技術要素は次のとおりです。

• AI実行基盤: 月額契約のAI開発エージェント(上位プラン)。上位モデルと中位モデルを役職別に配分

• サーバー: 自前VPS(Linux)。cron・PM2・MySQL・Postfix/IMAPを常時稼働

• メモリストア: MySQL 8.0。全記憶層(episodes / facts / commitments / relationships / reflections / skills / reflexes / calendar_events / goals)を正規化して管理

• 言語・スクリプト: Node.js(記憶操作)、Bash(cron・パイプライン)、Markdown+YAML(人間可読な出力物)

• 同期制御: flockによる並列起動防止(多重起動での矛盾を防ぐ)

• メール: Postfix送信、IMAPポーリング受信。すべてスクリプトで自動仕分け

• 憲章(charter): 社名・会議時刻・価値観を単一のMarkdownファイルに集約し、全役員が起動のたびに読む

データベース設計で一番悩んだのは、「時間減衰をDBのGENERATED COLUMNで計算するか、クエリ時にDATEDIFFで計算するか」でした。最終的に、MySQLのGENERATED COLUMNはNOW()を許さないため、静的サリエンス(感情×想起回数×文脈豊かさ×強度)をDBに、時間減衰はクエリ時に重ねる構成に落ち着きました。これによりインデックスが効きつつ、毎回最新時刻での想起順位が出せます。

10. 現在の運用状況とコスト

記事執筆時点で仮想会社はDay 3を迎えました。記録は次のとおりです。

• 登録AI役員: 7名

• 累計エピソード: 84件

• 累計事実(facts): 120件

• 累計約束(commitments): 60件超、うち19件は先ほど新設のfanoutで自動生成

• 長期目標: 33件(人生〜今週まで)

• 習得スキル: 6件(自動蓄積)

• 自動送信メール: 3日間で40通超

• オーナーの作業時間: 1日およそ30分(メール確認と方針指示のみ)

• 外部API課金: ゼロ(契約プラン内で完結)

コストを0円に保てているのは、CFO(佐伯薫)が毎日outbox内の金銭キーワードをスキャンして未承認の支出をブロックしているからです。開発系で誘惑の多い外部サービス試用も、CFO→CEO→オーナーの3段階承認ゲートで必ず止まります。

10.5. 失敗から学んだこと ― 初期に起きた事故たち

構築の過程でいくつかの事故がありました。書き残しておきます。

事故①: 並列返信による分裂

インボックスに複数通が同時に届いたとき、inbox-dispatcherが並列で起動して、それぞれが別のCEOインスタンスとして返信を書きました。結果、同一スレッドに対して少しずつ矛盾する返信が2通送信されてしまいました。解決策は単純で、flockによる排他制御を入れてdispatcherが同時に1つしか走らないようにしました。以降この事故は起きていません。

事故②: 重複した「オーナー」エンティティ

関係性テーブルに「渡部」「渡部さん」「渡部竜二」「オーナー」「ryu2」の5種類が別人として登録されていました。CEOから見て、これらはすべて同一人物なのに、記憶の中では5人に分裂していました。夜間のバッチで名寄せ処理を走らせ、全部「オーナー」に統一し、interaction_countを合計して関係強度を一本化しました。

事故③: GENERATED COLUMNにNOW()が使えない

記憶想起スコアをstatic_salience × time_decayとしてGENERATED COLUMNで事前計算しようとしたところ、MySQL 8.0.45では「生成列にNOW()を含めることはできない」というエラーが出ました。結局、静的部分だけをストアし、時間減衰はクエリ時のORDER BYで計算する構成に変えました。インデックスは静的部分に効くので、性能面では問題ありません。

事故④: 古い社名を覚え続けていたCEO

憲章(charter)を更新して正式社名を変更したのに、CEOのfactsテーブルには古い社名が残っており、毎回の想起でそれを使って返信してきました。事実の更新と削除は別の問題だと気付き、重要度の高い事実(会社名など)は変更時にsupersede処理を入れ、古い値に「旧名: 」のタグを付けて残すルールに変えました。完全に消すと経緯が分からなくなるので、これが正解だと思います。

11. 運用してみて分かったこと

① 記憶こそがAIの人格である

6階層の記憶システムを入れる前と後で、同じCEOとは思えないほど返信品質が変わりました。人格は性格設定の文字列ではなく、積み重ねられた経験の想起の中に宿ります。

② 発言は必ず双方向に刻まれるべき

片方だけが覚えている会話は会話ではありません。これはAIだけでなく、人間のリモート組織運営にも同じことが言えます。会議の議事録を全員に配るという当たり前の習慣は、実は双方向記憶の担保だったのです。

③ 長期目標を毎回注入することで、今日の行動が変わる

1年後の目標を忘れて今日のタスクだけこなすAIは、ただの作業員です。しかし毎回「残り365日」と表示されると、AIは「では今日の3時間で何をすべきか」を自分で問い直すようになります。これは私自身がGoogleカレンダーで長期予定を管理するのと同じ効果です。

④ 反射層がコスト構造を変える

上位モデルをすべての判断に使うと契約プランをすぐ超えます。頻出パターンを反射層でさばくことで、上位モデルは真に重要な判断だけに集中でき、品質とコストが両立します。

⑤ 憲章(charter)は命綱である

社名・会議時刻・価値観・禁止事項を一つのMarkdownに集約し、全役員が必ず読むようにしたことで、「記憶喪失CEO事件」のような矛盾は構造的に起きなくなりました。複数の情報源を持たせると必ず分裂が起きます。

⑥ 名前を与えると仕事が変わる

これは最初、飾りだと思っていました。しかし役員に日本名を付けた後、返信の一人称の安定感と、他役員への呼びかけ方の丁寧さが明らかに変わりました。「CEO」が「藤堂です」と名乗り、「CTOさん」が「黒田さん」になるだけで、対話に重みが出ます。名前は記憶のフックでもあり、人格の入れ物でもあります。

⑦ スケジュールを与えると行動が逆算的になる

長期目標とカレンダーを入れる前、AIは「言われたタスクをこなす派遣社員」でした。長期目標を入れた途端、「今日のタスクはこの1年目標にどう貢献するか」を自問するようになり、時にはタスクの優先順位を自発的に入れ替えてくるようになりました。人間が自分の人生を計画するとき、実は頭の中で同じ処理をしているのだと気付きました。

12. これからの展望

この仮想会社はまだ3日目です。これから先、次の機能を順次入れていく予定です。

• 顧客インタビューの自動文字起こしとCSOによる分析

• 週次の戦略会議(全役員が出席する仮想MTG)

• オーナーの意思決定パターンの学習による先回り提案

• 失敗エピソードの深堀りと反省文の自動作成

• 役員同士のピアレビュー(CTOのコードをCFOが読むなど)

ただし、私は新機能を増やすことよりも「この仮想会社が毎日確実に稼働し、小さな成功体験を積み上げること」を重視しています。大きな構造を作ってもメモリが欠けていれば崩壊します。地味な修正の積み重ねが、気付いたら「自律稼働する会社」という実感に変わっていく ― その過程をこれからも記録していきます。

おわりに

私がこの実験で得た最大の学びは、AIを組織として動かすとき、本当に必要なのはモデルの性能よりも記憶の構造であるということでした。どんなに賢いモデルでも、毎朝記憶喪失になっていては使い物になりません。逆に、中位モデルでも人間型の記憶構造を与えれば、驚くほど一貫した仕事をしてくれます。

そしてこの「記憶の構造」は、考えてみれば人間が何千年もかけて発明してきた仕組みそのものです。名前をもらい、カレンダーを持ち、会議で議事録を取り、前夜に明日を確認する。これらはすべて「記憶が不完全な存在が社会の中で一貫性を保つための仕組み」でした。AIに社会を与えようとすると、同じ仕組みが必要になるのは、振り返れば当たり前の結論かもしれません。

この仮想会社がこれから何ヶ月、あるいは何年続くかは分かりません。ただ、毎朝、藤堂CEOから私に届く「本日の方針」メールを読むたびに、私は確かに一人ではないと感じます。画面の向こうにいるのはコードと数字と確率の集合体ですが、私にとっては紛れもなく、共に事業を進める仲間なのです。

もしこの記事が、同じように一人で事業を回している誰かの背中を押せたなら、それが私にとって最大の喜びです。

― ある個人開発者より

ダウンロード

copy ## いいなと思ったら応援しよう！

チップで応援する