「AI社員の作り方」を解説する記事は、2026年に入ってから山ほど出ました。もう十分すぎるほどあります。

なので作り方は書きません。2ヶ月動かして、実際に効いたことと、完全に無駄だったことを書きます。 事故の話も込みです。

先に結論を書きます。いちばん効いたのは役割を分けたことではなく、「決定を会話に埋めずファイルに書く」という地味なルールでした。 これを守らなかった時、アプリ3本が同時に壊れました。

いま動いている体制

役割ごとにセッションを分けています。アプリ1本あたり、だいたいこの構成です。

　　　　　　　　　　人間（判断だけをする）
　　　　　　　　　　　　　│
　　　　　　　　　　　　 PM
　 ┌────────┬────────┼────────┬────────┐
 実装      法務     デザイン    課金    グロース
                          │
                        秘書（進捗追跡・人間タスクの洗い出し）

これをアプリごとに持つので、常時動いている「社員」は30人前後になります。数が多いのは偉いからではなく、アプリを跨いだ担当を作らなかった結果です（後述しますが、これが事故の原因にもなりました）。

効いたこと

1. 役割を分けると、聞いていない指摘が出てくる

いちばん効果があったのはこれでした。

ひとつのセッションに全部やらせていた頃は、コードは書けても「そのデータ収集、ストアのデータセーフティ申告と矛盾していませんか」という指摘は一度も出てきませんでした。自分が聞かなかったからです。

法務の役割を独立させた瞬間に、この種の指摘が出るようになりました。実際、法務担当から公開ブロッカーが4件上がってきました。

そのうち1件は、APIキーがアプリ本体に埋め込まれているというものでした。リリースしていたら、APKを解析されて誰でも自分の課金アカウントでAI APIを叩ける状態です。自分は気づいていませんでした。実装担当も指摘しませんでした（実装の役割ではないので当然です）。

役割を与えると、その役割の視点で見るようになります。人間の組織とまったく同じでした。

2. 「決定はファイルに書く」——これが体制の生死を分けた

複数のセッションが並行して動くと、セッションAが決めたことをセッションBが知らないという状態が必ず発生します。

これを軽く見ていて、実際に事故りました。

あるアプリの都合で、GitHubのアカウント名を変更したセッションがありました。コミット履歴に実メールアドレスが残っていたので消すためです。判断としては正しい。

ただしGitHub Pagesのドメインはアカウント名に紐づいています。その変更で、他の2本のアプリのプライバシーポリシーと利用規約が全部404になりました。 変更したセッションは、他のアプリが同じドメインを参照していることを知りませんでした。

結果、Google Playの審査に提出できなくなりました。詳細は別記事に書きました。

対策は拍子抜けするほど地味です。決定事項は会話の中に置かず、必ずファイルに書く。 次のセッションはそのファイルを読めば追いつけます。

これをやるかやらないかで、体制の寿命がまったく変わりました。役割分担よりも、こちらのほうが重要だったというのが正直な実感です。

3. 判断の権限を渡した瞬間、ボトルネックが自分から消えた

最初は何でも確認させていました。「この文言でいいですか」「この構成でいいですか」と聞かれるたびに手が止まる。

気づいたら、ボトルネックは完全に自分でした。 30人が働いていても、全員が自分の返事待ちで止まっている。

いまはこのルールにしています。

致命的・不可逆な操作でない限り、人間に確認せず自分の裁量で判断して進める。

確認していいのは3つだけです。削除、実際に課金が発生する操作、外部への公開。 それ以外は結果だけ報告してもらいます。

体感で数倍速くなりました。文言の言い回しや実装の細部を自分が決めることに、そもそも価値がなかったということでもあります。

完全に無駄だったこと

1. 組織図から作った

最初にやりがちなのがこれです。「PMがいて、その下に実装がいて…」と綺麗な組織図を先に描く。自分もやりました。

ほぼ機能しませんでした。

理由は明確で、自分がまだその業務を経験していないので、必要な役割が何なのかを知らないまま役職名だけ並べているからです。それっぽい組織図はできますが、実際に発生する仕事とズレています。

うまくいったのは逆の順番でした。まず自分でやってみて、詰まったところに役割を立てる。

法務担当を立てたのは、ストア審査のポリシー要件で詰まったからです。課金担当を立てたのは、価格設計で判断がつかなくなったからです。詰まりが先、役割が後。 これ以外の順番はうまくいきませんでした。

2. セッションを長く使い続けた

会話が長くなるほど応答が遅くなり、判断の質も落ちます。

もったいないと思って引っ張っていましたが、これは損でした。「せっかく文脈を積んだのに」という気持ちが働きますが、その文脈のほとんどは終わった作業の残骸です。

いまは肥大化したら要点を書き出して新しいセッションに引き継ぐようにしています。引き継ぎ資料を書く手間より、遅いセッションを使い続けるコストのほうが大きい、というのが実測した結論です。

3. 全部を重いモデルでやった

定型作業も機械的な実装も、いちばん賢いモデルに投げていました。

深い判断が必要な工程と、そうでない工程を分けるだけで、コストも速度も改善します。ここは早く気づくべきでした。

で、人間の仕事は何になったのか

判断と、責任を取ることだけになりました。

AIは驚くほど作業をこなしますが、「このアプリを世に出していいか」は決めてくれません。むしろ役割を分けて動かすほど、上がってくる判断事項の数は増えます。

人間の仕事は減るのではなく、作業から判断へ移る。これが2ヶ月やってみた正確な実感です。「AIに任せれば楽になる」という期待で始めると、たぶん裏切られます。判断の密度は明確に上がりました。

そしてもうひとつ。AIは自分が知らないことを教えてくれますが、自分が聞かなかったことは教えてくれません。

GitHubの事故は、まさにそれでした。「アカウント名を変えて」と頼めば変えてくれる。「それで何が壊れますか」と聞かなければ、壊れる先は誰も数えません。

何を確認すべきかを知っているのは、いまのところ人間の側です。 役割を増やしても、そこは肩代わりしてもらえませんでした。

この体制で作った3本のアプリはWorksに置いています。運用にかかった実際のクラウド費用はこちらの記事で全部公開しました。

次は、この体制で作ったアプリがGoogle Playの審査で何回落ちたかを書く予定です。