私の 1 人用 OpenClaw 会社アーキテクチャ v1.0 は、会社の会計、コンプライアンス、および運用をすべて AI に委任します。

この記事では、オープンソースAI GatewayのOpenClawを使用して一人会社の全栈管理システムを構築する経験を共有しています。主なポイントは以下の通りです:

  • OpenClawの利点:オープンソース、セルフホスティング、マルチエージェントアーキテクチャ、Discord統合、持続的な運用による自然な管理。
  • マルチエージェント設計:CTO、会計、ビジネス、コンプライアンス、監視エージェントなどの役割分担をチャネルルーティングで管理。
  • 段階的なアクティベーション:ビジネス量に応じてエージェントを徐々に有効化し、複雑さを回避。
  • 決定権限マトリックス:ガードレール内での自律実行、外部での確認要求により安全性を確保。
  • データアーキテクチャ:SQLiteを単一データソースとして使用、統一操作層、Notionミラーバックアップ。
  • メモリシステム:参照日付に基づく有効期限と信頼度スコアリングを持つ二層アーキテクチャで、古い情報を防止。
  • 自動化運用:月次決算、コンプライアンススキャン、システムヘルスチェックなどのスケジュールタスク。
  • セキュリティ設計:機密操作のボタン確認、コマンドホワイトリスト、ハニーポットファイル検出、PII監査。
  • 経験した課題:Macのスリープ問題対応、exec権限のバランス調整、Gateway再起動時のセッション喪失、Notion API制限など。 システムは、設計の良さ、データの追跡可能性、セキュリティを重視し、AIを通じて個人が業務を効率的に管理することを目指しています。
要約

作者:しゆ

読みたくない場合は、OpenClaw アカウントに直接送信できます。

1人 + OpenClaw = 管理チーム

オープンソースのAIゲートウェイを活用した個人企業向けフルスタック管理システムの構築

AI時代以前は、個人経営の企業

個人経営の会社や独立したビジネスを経営している場合、仕事のリズムはおそらく次のようになります。午前中に口座を調整し、午後に提案書を作成し、夜にコンプライアンス文書を処理し、その合間に顧客からのメッセージに返信し、サーバーの状態を確認し、データ レポートを更新する必要もあります。

1 つの仕事をしているのではなく、同時に 5 つの仕事をしているのです。

多くの人はまず、AIチャットボットに助けを求めるでしょう。ChatGPTとClaudeは確かに質問に答えたり、ドキュメントを作成したりできます。しかし、しばらく使ってみると、チャットボットは「管理」の問題ではなく、「質問への回答」の問題を解決していることに気づくでしょう。

必要なのは、よりスマートなアシスタントではなく、タスクを割り当て、コンテキストを記憶し、タスクを自動的に実行し、必要に応じて相談できる AI 管理システムです。

この記事では、 OpenClaw (オープンソースのAIゲートウェイ)を用いて、個人企業向けのフルスタック管理システムを構築した際の思考プロセスと経験をすべて共有します。これは概念実証ではなく、実際に稼働しているシステムです。

なぜ OpenClaw なのか?

OpenClawの利点:

  • オープンソース、自己ホスト型 - すべてのデータはサードパーティを経由せずに自分のマシン上に保存されます。

  • ネイティブマルチエージェントアーキテクチャ - 異なるエージェントには独立したパーソナリティファイル ( SOUL.md )、ツール権限、およびメモリ空間があります。

  • Discord 統合 – チャンネルは部門であり、メッセージの送信はコマンドの発行であり、自然な管理インターフェースです。

  • 永続的な操作 - 一度実行されて終了するワークフローではなく、24 時間 365 日オンラインのゲートウェイです。

最も重要なポイント:チャネル = 部門、メッセージ = コマンド。このモデルは管理シナリオに自然と適応します。 #accountingチャネルで「今月の経費の概要」と言えば、経理担当者が自動的に応答し、 #opsチャネルで「サーバーの状態を確認」と言えば、運用担当者が引き継ぎます。コマンド構文を覚える必要はなく、部下にメッセージを送信するのと同じくらい自然な操作です。

マルチエージェントアーキテクチャ設計

分業

私のシステムでは現在、次の役割が計画されています。

  • CTO エージェント – システム アーキテクチャ、コード、展開、ツール開発を担当するテクニカル リーダー。

  • 会計代行 – 簿記、決算整理、月次決算、報告書作成

  • ビジネスエージェント - 顧客とのコミュニケーション、注文追跡、見積管理

  • コンプライアンスエージェント - 規制レビュー、文書アーカイブ、定期スキャン

  • 監視エージェント – システムハートビート、異常アラート、リソース監視

段階的な有効化

非常に重要な設計原則は、最初にすべてのエージェントをアクティブ化しないことです。

事業量が少ないうちは、CTOが会計とコンプライアンスの責任を担うだけで十分です。事業量が増えるにつれて、これらの責任は徐々に細分化されていきます。

フェーズ A (初期段階): CTO が複数の役割を担い、他のエージェントは休止状態です。

フェーズB(安定期):会計とコンプライアンスを活性化し、CTOはテクノロジーに注力

フェーズ C (拡張フェーズ): 全員がライブになり、それぞれが職務を遂行します。

フェーズの切り替えは、トリガー条件(例えば、月間トランザクション数が閾値を超えるなど)を検出するスケジュールタスクを使用して自動化することも、手動で行うこともできます。重要なのは、まずアーキテクチャを構築し、必要に応じて有効化することです。

チャネルルーティング

#cto -オフィス → CTOエージェント

#会計→ 会計士

#コンプライアンス→ コンプライアンスエージェント

#ops -monitor → 監視エージェント

#general → すべてのエージェントに表示され、要求に応じて応答します。

OpenClaw の設定ファイルでは、各エージェントがどのチャネルをリッスンするかを指定できます。メッセージは到着時に自動的にルーティングされるため、手動で @ を押す必要はありません。

意思決定権限マトリックス

これはシステム全体の中で最も重要な設計の 1 つです。

フェンスの内側 → エージェントは、イベント後のログを記録しながら自律的に実行します。

ガードレールの外側 → エージェントは一時停止し、@boss が決定を要求します。

不明 → ガードレールの外側として検討し、再度質問したほうがよいでしょう。

例えば:

  • 日常的な経費を記録する → ガードレール内で自動的に実行する。

  • データベースレコードの削除 → ガードレールの外側では確認が必要です。

  • 見慣れない税金のカテゴリに遭遇 → 不明なので報告します。

重要な原則:エージェントは、不確かな状況では独断で行動すべきではありません。間違いを修正するコストは、質問するコストをはるかに上回ります。

データアーキテクチャ

単一のデータソース

すべてのビジネスデータはローカルのSQLiteデータベースに保存されます。MySQLやPostgreSQLを使わない理由は何でしょうか?個人経営の企業では同時実行性は不要だからです。SQLiteは設定もメンテナンスも不要で、必要なファイルは1つだけです。バックアップは単なるファイルのコピーです。

~/.openclaw/data/main.db

├── 取引 # 取引記録

├── クライアント # クライアント情報

├── ドキュメント # ドキュメントインデックス

├── audit_log # 監査ログ

└──……

統合オペレーションレイヤー

すべてのデータベース操作は、統一された操作スクリプト(db_ops.pyなど)を通じて実行する必要があり、直接SQLを記述することはできません。メリット:

  • 自動監査 - すべての操作が自動的に記録されます(誰が、いつ、何を実行し、何が変更されたか)。

  • 統一されたフォーマット – これにより、1 つのエージェントが 1 つのフォーマットを使用し、別のエージェントが別のフォーマットを使用するという問題が回避されます。

  • アクセス制御 - 不正な操作は操作レベルで傍受できます。

Notionミラーバックアップ

SQLiteはデータソースですが、ユーザーフレンドリーではありません。そこで、Notionを使って視覚的なミラーを作成しました。

  • リアルタイム同期: キー操作 (トランザクションの追加、ステータスの変更) により、即時同期がトリガーされます。

  • 毎日のバックアップ: 何も見逃されていないことを確認するために、毎日 23:00 に完全な検証が実行されます。

  • 読み取り専用ミラー: Notion では表示はできますが変更はできないため、双方向同期の悪夢を回避できます。

多言語エクスポート

ビジネスに多言語シナリオが含まれる場合は、エクスポート レイヤーで言語適応を実行できます。

db_ops.export_csv() # 中国語版

db_ops.export_csv() # 英語版

db_ops.export_csv() # バイリンガル翻訳

列名、カテゴリ名、ステータス ラベルはすべて構成ファイルにマッピングされ、エクスポート時に自動的に翻訳されます。

記憶システム

二層メモリアーキテクチャ

作業記憶には容量制限(例:200行)があり、この制限を超えると破棄する必要があります。長期記憶は理論上は無制限ですが、データ量が増えるにつれて検索品質が低下するため、定期的なクリーンアップが必要です。

忘却曲線:基準日に基づく有効期限メカニズム

各メモリエントリには参照(参照日)が含まれ、実際に最後に使用された日時が記録されます。注: 自動ロードは参照としてカウントされません。返信で実際に使用されたエントリのみが参照として扱われます。

- [2025-01-15][ref:2025-02-20] サプライヤーAの支払いサイクルはNet 30です

- [2025-01-15][ref:2025-01-15] 仮メモ(1ヶ月間使用せず、期限切れ間近)

有効期限ルール:

  • 高優先度メモリ: 参照は 90 日後に期限切れになります。

  • 暫定的な注意: 参照は 30 日後に期限切れになります。

  • コアID情報: 削除されない

信頼スコア

すべての記憶が同じように信頼できるわけではありません。それぞれの記憶に信頼度スコアを割り当てました。

ソース価格(執筆時点):

  • ユーザー確認済み → 0.95

  • 手動入力 → 0.85

  • ログから自動抽出 → 0.50

時間減衰: 60 日以上ヒットしていないメモリを参照し、信頼度は 1 日あたり 0.95 倍になります。

検索強化: 検索結果が見つかるたびに、信頼度レベルが 1.05 倍になります (最大 0.95)。

自動削除: 信頼度が 0.1 未満の場合に削除します。

古くなった記憶は、記憶が全くないよりもなぜ危険なのでしょうか?

これは苦い経験から学んだ教訓です。記憶がなければ、エージェントは「わかりません」と言い、あなたは調べなければなりません。しかし、エージェントが古い情報(3ヶ月前の価格や廃止された規制など)を覚えていた場合、自信満々に間違った答えを返し、あなたは確認すらしないかもしれません。

古くなった記憶は、いわば有害なキャッシュのようなものです。したがって、忘却のメカニズムはオプションではなく、必須です。

自動化された運用と保守

スケジュールされたタスクの例

クローン:

- 名前: 月次決済

スケジュール: "0 10 1 * *" # 毎月1日の午前10時

アクション: 月次決算概要

- 名前: コンプライアンススキャン

スケジュール: "0 9 * * 1" # 毎週月曜日午前9時

アクション: コンプライアンススキャン

- 名前: システムヘルスチェック

スケジュール: "*/30 * * * *" # 30分ごと

アクション: システムハートビートチェック

- 名前: データ同期

スケジュール: "0 23 * * *" # 毎日午後11時

アクション: データをNotionに同期する

- 名前: メモリクリーンアップ

スケジュール: "30 23 * * *" # 毎日23:30

アクション: メモリ有効期限のクリア

心拍数モニタリング

監視エージェントは30分ごとにシステムの状態(ゲートウェイのオンライン状態、ディスク容量、データベースの整合性など)をチェックします。異常が検出された場合は、Discord経由でアラートが送信されます。

自動アップグレード検出

OpenClaw の新しいバージョンを定期的にチェックし、利用可能になった場合は通知しますが、自動的にはアップグレードされません (アップグレードは「フェンス外」の操作です)。

安全設計

個人経営の企業におけるAIシステムでは、セキュリティ設計が極めて重要です。何か問題が発生した場合、他に助けてくれる人がいないからです。

敏感な操作ボタンを確認する

すべての危険な操作(重要な設定の削除または変更、シェル コマンドの実行)では確認を求める必要があります。

⚠️ 実行を確認しますか?

作戦: 2024年からのアーカイブデータを削除

影響: 回復不能

[✅ 確認] [❌ キャンセル]

これはテキストによる確認ではなく、Discordのインタラクティブコンポーネント内のボタンです。エージェントが勝手に「確認」をクリックすることを防ぎます。

コマンドホワイトリスト + 階層制御

🟢 自由に実行可能: ls、cat、head、tail、sqlite3 (読み取り専用)

🟡 ドキュメントが必要です: Python 3、Node.js、ファイル書き込み操作

🔴 rm、chmod、ネットワーク リクエスト、データベース書き込みには確認が必要です。

⛔ 絶対に禁止:sudo、システムファイルの変更、機密ディレクトリへのアクセス

ハニーポットファイル検出

機密ディレクトリに複数のハニーポットファイルを配置します。エージェントがこれらのファイルを読み取ろうとすると、プロンプトインジェクションの可能性があると判断され、直ちにアラートがトリガーされ、エージェントが停止します。

PII監査スキャン

すべてのエージェントの出力ログを定期的にスキャンし、個人識別情報(PII)の偶発的な漏洩がないか確認します。漏洩が検出された場合はアラートを発し、PIIを自動的に削除します。

落とし穴に陥った経験

サーバーとして使用した場合の Mac の休止状態の問題

MacでOpenClaw Gatewayを実行している場合は、休止状態の問題に対処する必要があります。Macはアイドル状態になるとデフォルトで休止状態になり、ゲートウェイとの接続が切断されます。解決策:

# 休止状態を無効にする(sudo が必要)

sudo pmset -a sleep 0 ディスプレイスリープ 0 ディスクスリープ 0

# あるいは、カフェインを使用して、人を覚醒させておくこともできます。

カフェイン -s &

ただし、放熱性と電力コストには注意が必要です。長期運用には、低消費電力のLinuxデバイスの使用をお勧めします。

実行権限のバランス調整

エージェントに実行権限を与えすぎると、予期せぬシステムクラッシュにつながる可能性があります。一方、権限が少なすぎると、多くの自動タスクが実行できなくなります。私の経験では、

  • デフォルトで最小限の権限

  • 必要な場合にのみ開け、開けるたびに理由を記録します。

  • ブラックリストの代わりにホワイトリストを使用します。

ゲートウェイの再起動後にセッションが切断されました

OpenClaw Gateway が再起動すると、以前のセッション会話は失われます。セッションコンテキストに依存する長時間実行タスクがある場合は、再開可能な割り込み可能な設計を実装するか、重要なコンテキストをファイルに書き込む必要があります。

Notion APIのさまざまな制限

  • 1 分あたりのリクエスト数にはレート制限があります。

  • 1 つのブロックには最大テキスト長の制限があります (2000 文字)。

  • 一部のリッチ テキスト形式はサポートされていません。

  • データベース属性タイプを変更すると、同期スクリプトでエラーが発生する可能性があります。

推奨事項: 同期スクリプトには、堅牢なエラー処理と再試行ロジックが必要であり、API 呼び出しが常に成功するとは想定しないでください。

構成のマージでは追加のみが可能で、置き換えはできません。

OpenClaw の設定ファイルのマージロジックは、置換ベースではなく追加ベースです。つまり、ローカル設定とグローバル設定の両方で同じフィールドを定義した場合、上書きではなくマージされます。この落とし穴を経験して、重要な設定は1か所にのみ定義し、あちこちに散らばらせないようにすることを学びました。

一人で会社を経営する場合、最大のボトルネックとなるのは能力ではなく、帯域幅です。会計、法務、テクノロジー、そして事業運営のすべてに同時に精通し、かつ全てがスムーズに進むようにすることは不可能です。

1 人 + 適切に設計された AI システム = 完全な管理チーム。

しかし、重要なのは「適切に設計されている」というフレーズです。これは次のことを意味します。

  • 明確に定義された権限の境界 – エージェントは何ができるか、何ができないか、どのような質問をする必要があるかを把握しています。

  • データ フローは追跡可能であり、すべての操作が記録され、問題を調査できます。

  • セキュリティに妥協はありません。ハニーポット、ホワイトリスト、PII スキャンはすべて必須です。

  • 記憶には期限があります。古くなった情報は、まったく情報がないよりも危険です。

  • 段階的な進化 - 過度な進歩を避け、必要な場合にのみアクティブ化し、システムをシンプルに保ちます。

これは「人間を AI に置き換える」という話ではなく、「AI を使って 1 人の人間がさまざまなものを管理できるようにする」という実践です。

システムは現在も継続的なイテレーションを続けていますが、コアアーキテクチャは既に安定稼働しています。ご自身の独立事業の運営にAI活用をご検討されている皆様にとって、これらの経験が少しでもお役に立てれば幸いです。

テクノロジースタック: OpenClaw + SQLite + Notion + Discord + Python

適したシナリオ: 個人企業、独立系開発者、フリーランサー、小規模スタジオ

共有先:

著者:xiyu

本記事はPANews入駐コラムニストの見解であり、PANewsの立場を代表するものではなく、法的責任を負いません。

記事及び見解は投資助言を構成しません

画像出典:xiyu。権利侵害がある場合は著者へ削除をご連絡ください。

PANews公式アカウントをフォローして、強気・弱気相場を一緒に乗り越えましょう