# 인간 1명 + AI社員 5명을 24시간 운영하기 위해 만든 코그노바(COGNOVA) 컴퍼니 OS의 전 설계도

> https://bookfactory.kr/c/ai-tech/10175
> 게시판: AI·머신러닝
> 작성자: admin
> 작성일: 2026-08-20T18:00:15.362Z

---

![見出し画像](https://assets.st-note.com/production/uploads/images/305099050/rectangle_large_type_2_2d3d04601953a32dda14d7c256a242a2.jpg?width=1280)

AI社員を雇うな。「AI会社」を実装せよ。AIエージェントを5体作った。最初は、本気でこれで会社が動くと思っていた。CEOが1人。その下にAI社員を配置する。Research担当。Editor担当。Automation担当。Design担当。System担当。それぞれに役割を与え、それぞれに優秀なプロンプトを書く。 Founderである私は方向だけ決める。あとはAI社員が勝手に働く。記事を書く。画像を作る。投稿する。数字を分析する。改善する。次の記事を書く。寝ている間にも会社が進む。──完璧に見えた。少なくとも、PowerPointに組織図を書いている間は。現実は違った。AI社員は、驚くほど簡単に会社を壊す。正確には、AIが壊すのではない。AIが働くことを前提として作った「人間側のシステム」が壊れる。あるAIは仕事を終えたと言った。確認すると終わっていなかった。別のAIは投稿したと言った。URLがない。また別のAIはエラーを検知し、再試行した。また失敗した。さらに再試行した。また失敗した。そして大量のログだけが残った。「処理完了」という文字を見て安心した数分後、ブラウザで確認すると記事は存在しない。別の日には、正常に動いていた自動化を改善しようとして、逆に投稿ラインを止めた。AI社員同士が同じ対象を触れば、さらに面倒になる。社員A：「修正しました」社員B：「最適化しました」社員C：「競合を検知したので復旧しました」私：「で、今どの状態なの？」全員：「正常です」私がURLを開く。正常ではない。笑うしかない。だが、この失敗から重要なことが分かった。⸻AI会社の難易度は「AIの賢さ」では決まらない現在、多くのAIエージェント論は、「何を考えさせるか」に集中している。もちろん重要だ。しかし、実際にAIを会社の業務へ投入すると、もっと泥臭い問題が支配的になる。誰が仕事を受け取るのか。誰が実行するのか。成功を誰が判定するのか。途中で落ちたら誰が復旧するのか。同じ仕事を二重実行しないためにどうするのか。AIが「完了しました」と言ったとき、それを信用していいのか。人間が寝ている6時間に障害が発生したらどうするのか。APIが落ちたら？ブラウザが固まったら？認証が切れたら？投稿ボタンは押されたが公開されなかったら？公開されたが画像が違ったら？AIが間違ったブランドの記事を投稿したら？ここまで来ると、「プロンプトエンジニアリング」という言葉だけでは説明できなくなる。必要なのは、Operating Systemだ。私はこれを、COGNOVA Company OSと呼ぶことにした。⸻「AI社員を作る」と「AI会社を作る」は全く違うこの違いを理解するまで、かなり遠回りした。AI社員を作るのは簡単だ。例えば、こんなプロンプトを書く。ROLE:あなたはCOGNOVAのSenior Editorです。OBJECTIVE:読者価値と収益性を最大化する記事を制作してください。RESPONSIBILITIES:- テーマ調査- 構成作成- 本文執筆- タイトル最適化- CTA作成- 公開前品質確認これだけでも、かなり優秀なEditorになる。しかし、会社は動かない。なぜなら、「記事を書いた後、どうするのか」が存在しないからだ。そこで、記事完成後はPublisherへ渡してください。と書く。少し会社っぽくなる。だが次の問題が発生する。「渡したこと」を誰が確認する？Publisherが停止していたら？同じ記事を2回受け取ったら？Editorが記事を作り直したら？旧版と新版のどちらを公開する？Publisherが、「公開しました」と言ったら、それを誰が確認する？つまり、社員を増やすたびに、社員そのものより「社員間の状態管理」が重要になる。ここから私の考え方は完全に変わった。AI会社の最小単位は、AI Agentではない。JOBだった。⸻COGNOVA Company OSの最小単位現在、私は仕事を概念的にこう扱っている。{ "job_id": "CN-20260819-0001", "brand": "COGNOVA", "publisher": "Founder", "channel": "note", "task": "publish_article", "status": "QUEUED", "priority": "P0", "content_hash": null, "public_url": null, "retry_count": 0, "checkpoint": null, "created_at": "2026-08-19T02:00:00+09:00", "updated_at": "2026-08-19T02:00:00+09:00"}AI社員に、「今日の記事を投稿して」とは頼まない。システム上では、JOBを生成する。そのJOBが、QUEUED↓GENERATING↓READY↓PUBLISHING↓VERIFYING↓PUBLISHEDと移動する。途中で失敗すれば、FAILEDでは終わらない。RECOVERINGへ送る。人間しか解決できないなら、HUMAN_GATEへ送る。重要なのはここだ。「AIが何と言ったか」は状態判定に使わない。「公開しました！」では駄目。公開URLが存在する。第三者としてアクセスできる。タイトルが一致する。本文が一致する。対象アカウントが一致する。そこまで確認して、初めて、PUBLISHEDになる。これを導入してから、私はAIへの見方が変わった。AIを信用しなくなったわけではない。むしろ逆だ。AIを信用しなくても会社が動く構造にした。これは人間の会社と同じだと思う。優秀な社員を採用することと、優秀な会社を作ることは、同じではない。⸻私が一番間違えていたこと最初の私は、「AIをもっと賢くすれば解決する」と思っていた。だからプロンプトを改善した。長くした。役割を細分化した。ルールを増やした。例外処理を書いた。AI社員へ、「絶対に止まるな」と命令した。結果。もっと複雑に壊れた。これはかなり重要な失敗だった。AIへ、「自律的に判断してください」と書くことと、自律システムを作ることは、全く違う。本当の自律化とは、AIに自由を与えることではない。「自由に失敗しても復旧できる構造」を作ることだ。ここに気づいてから、COGNOVAの設計思想は変わった。⸻会社を5つの優先度に分解した現在の基本思想は単純だ。P0 = 定刻公開・外部配信P1 = 公開確認・障害復旧・未達回収P2 = 公開後品質監査・修正P3 = 次回準備・コンテンツ在庫P4 = 環境改善・最適化この5行は、一見すると大したことがない。しかし私にとっては、数千行のプロンプトより重要だった。以前はAutomation担当が、「システムを改善した方がいい」と判断すると、改善を始める。その間に公開が遅れる。つまり、会社を良くする仕事が、会社の売上を作る仕事を止めていた。これは本末転倒だった。そこで、P4はP0を絶対に妨害してはいけない。という原則を置いた。完璧なシステムを作るより、今日の記事を公開する。画像が少し弱いなら、公開後に直す。コードが美しくなくても、本番を止めない。これはソフトウェア開発というより、実際の会社経営に近かった。⸻そして「24時間自律稼働」という幻想も捨てた私は一時期、AIツールやAIエージェントに、「24時間365日働け」と命令すれば、24時間365日働く会社が作れると思っていた。当然、作れない。チャットは常駐プロセスではない。会話が終われば、そこで止まる。本当に24時間動かすには、AIの外側が必要になる。現在の基本構造はこう考えている。Human Founder │ ▼Chief Nexus │ ▼Persistent Queue │ ┌────┼────┐ ▼ ▼ ▼Worker Worker Worker │ ▼External Service │ ▼Verifier │ ▼State DB │ ▼WatchdogAIはこの中の一部にすぎない。Queue。Worker。State DB。Checkpoint。Heartbeat。Watchdog。Verifier。これらがあって初めて、AIが「社員」になる。⸻ある夜、これを痛感した午前2時。システムを見ていた。AIは正常。Dockerも正常。Workerも正常。ログも流れている。一見、問題はない。でも記事が出ていない。原因を追った。生成は成功していた。キューにも入っていた。Publisherも処理していた。「SUCCESS」まで記録されている。それなのに公開URLがない。つまり、内部的には成功しているが、現実世界では失敗していた。この瞬間、自動化というものの定義を変えた。旧定義：プログラムが最後まで実行された新定義：現実世界に期待した結果が存在し、第三者が確認できるこれは小さな違いに見える。でも、この2つは全く違う。そしてCOGNOVAでは、後者だけを成果として扱うことにした。⸻ここまでが無料部分であるここまで読んで、「なるほど、考え方は分かった」で終わってほしくない。だから、ここから先は思想論をやめる。実装へ入る。有料部分では、自分の会社・副業・メディア・開発プロジェクトへそのまま移植できる形まで落とす。具体的には、* Company OS全体アーキテクチャ* AI社員の役割定義* Chief Agent用System Prompt* Worker用System Prompt* JOB Schema* SQLite/PostgreSQL設計* Queue設計* Checkpoint実装* Heartbeat実装* Watchdog* Retry / Backoff* HUMAN_GATE* 重複実行防止* Content Hash* Single Writer* 公開確認Verifier* 障害台帳* URL台帳* KPI* 日次レビュー* AIがAIを監督するときの設計* 「止まらない会社」にするための実装原則まで公開する。きれいな概念図では終わらせない。コードを書く。プロンプトを書く。DBを書く。失敗条件を書く。そして最後に、ゼロから同じ仕組みを作るなら、私ならどう構築するかを手順化する。ここから先は、AIについて読む記事ではない。AI会社を作るための設計書である。

**출처:** [note 원문](https://note.com/cognova_founder/n/n3a37ced725b8)

*번역: Gemma 3(.44) 초벌 + 교정 검수*

[원문 보기](https://note.com/cognova_founder/n/n3a37ced725b8) | 출처: note.com