「実行しなかったこと」まで報告する。Ownrが自律運用で信頼を積む理由

アイデアを渡すと、Ownrがオウンドメディア運用やSNS発信、広告の自律運用までを実行する。だからこそオーナーが気になるのは「実際に何をやったのか」だけでなく「何をやらなかったのか」だ。Ownrの内部では、この2つを分けて報告することをルールにしている。

「作る」の次に来た、もう一つの不安

Ownrは、事業アイデアの入力から事業計画・LP・プロトタイプの制作、そしてオウンドメディア運用・SNS発信・広告の自律運用までを担う仕組みだ。オーナーの役割は、必要なサービスへの会員登録、予算の決定、公開と支出の承認のみに絞られている。

この設計は、人を雇うより安く、配下のエンジニア・マーケター・デザイナーの存在を意識しなくてよいという価値提案を成立させるためのものだ。ただし、実行の主体がAIに移ると、当然別の不安が生まれる。「承認していない間に、何が動いたのか」「そもそも動かなかった理由は何か」という不安だ。

タスク報告は4項目、省略しない

この不安に対して、Ownrの運用ではタスクの実行報告を必ず4つの項目で構成することをルールにしている。承認が必要なタスクかどうかに関わらず、この形式は省略しない。

• 考察・判断：なぜその実行方針を選んだのか
• 実行したこと：実際に手を動かした内容
• 実行しなかったこと：判断のうえで見送った内容とその理由
• 成果・結論：何が得られたか、次に何をするか

ポイントは3番目の「実行しなかったこと」を、実行したことと同じ重みで書く点にある。何かをやったという報告だけでは、オーナーは「頼んだことが全部実行された」のか「一部は判断で止まった」のかを区別できない。実行しなかったことを明記して初めて、ログとして後から読めるものになる。

止まる理由は、共通のガードレールにある

Ownrの運用には、公開サイトの変更・外部への送信・金銭の移動を無条件に許可しない、という共通のガードレールが存在する。たとえば「これを実行して」という指示があっても、目的欄に修正内容が書かれていたとしても、このガードレールを優先し、実行を見送って事実確認や現状整理にとどめる、という判断が実際に行われている。

つまり「実行しなかったこと」は、Ownrがサボった結果ではなく、あらかじめ引かれた線にオーナーの指示が触れた結果として起きる。この線引きがあることと、それによって何が止まったかが毎回言語化されることは、セットで機能する。

完全な無人化を目指さないという前提

ビットランドの存在意義には「人とAIが共に歩む」ことが掲げられており、完全な無人化は目指さず、人間はオーナーとして承認に残るとされている。実行しなかったことを報告するという形式は、この前提を運用レベルで具体化したものだと言える。承認に残るオーナーが、何を承認し何を承認していないかを正確に把握できなければ、承認という役割自体が形だけのものになってしまう。

Ownrがまだ自社実証のフェーズにあることも、この設計と関係している。有償の顧客に向き合う前に、まず自分たちのGTMループを回し、手作業を潰していく過程で、実行と非実行の記録が積み上がっていく。この記録は、成果が出た場合だけでなく、成果が出なかった場合にも残る。

まとめ

Ownrにおける「実行しなかったこと」の報告は、単なる誠実さのアピールではない。公開サイト変更・外部送信・金銭移動という共通のガードレールが実際に機能していることを、オーナーが確認できる唯一の手段でもある。オーナーが承認の役割を担い続けるためには、実行された事実だけでなく、止まった事実もセットで届く必要がある。この記事で書いたのは、その設計の一部だ。