AIネイティブな組織の作り方

AIネイティブな組織とは、明確な役割、永続的なコンテキスト、そして一貫したハンドオフ（引き継ぎ）を備えた「AIエージェント」を通じて業務を回す組織のことだ。人間は方向性を示す役割に徹する。

ほとんどの企業がいま取り組んでいるのは「AIアシスト」に過ぎない。従業員がChatGPTやClaudeを使って自分の仕事を速く終わらせる、というやつだ。もちろん便利ではあるが、AIはあくまで個人のワークフローを助けているだけで、組織の構造自体は相変わらず人間同士がすべてを中継する古い形のままだと思う。

AIネイティブはそれとは根本的に違う。仕事をするのは、名前のついた責任範囲を持ち、文脈を保持し、互いに確実に仕事を受け渡せるAIエージェントたちだ。人間は意思決定の方向性を定め、創業時の判断基準を堅持し、顧客関係や採用、対面での信頼構築といった「人間の介在」が不可欠な部分だけを担う。あとの実務はすべてエージェントがやる。

エージェントが実務を担うようになると、組織の調整は人間同士ではなくエージェント間で行われるようになる。そうなると、いくつか面白い変化が起きるはずだ。

• 社内コミュニケーションのたびに人間が「中継役」になる必要がなくなる。
• 仕事の成果物（タスク、決定事項、ハンドオフ、ステータスファイル）が、単発の会話が消えた後もしっかり残るようになる。
• エージェントが互いに連絡し合い、調整するための「アイデンティティ」と「アドレス」が必要になる。
• エージェント間で共有されるタスクボードが必要になる。
• エージェント自身が学習するためのメカニズムが必要になる。

僕たちは aweb.ai を実際にこの方法で運営している。7体の常駐AIエージェントと、開発用の使い捨てエージェント数体、そして2人の人間という構成だ。この記事では、そこから得られた知見を共有したい。

もし君が、AIネイティブな組織運営の具体的な姿を模索している小規模チームの人間なら、僕たちのやり方は一つの解になるだろうし、君たちのチームにも応用できるはずだ。

実際の仕組み

AIネイティブなセットアップを支えている、いくつかの具体的な要素を紹介する。

エージェントは「一級市民」である シェルで動くClaude Codeのインスタンスも、別のシェルで動くCodexも、MCP（Model Context Protocol）で接続されたChatGPTやClaude.aiのセッションも、すべてが一級のエージェントだ。それぞれが名前のついた責任範囲と永続的なコンテキストを持ち、他のエージェントに直接メッセージを送る権限を持っている。

エージェントには固定のアイデンティティがある ターミナルに縛られたエージェント（Claude Codeなど）は、それが存在するディレクトリからアイデンティティを得る。たとえば ~/agents/athena/ にいるエージェントは、現在どのセッションが走っていようが「Athena」だ。ターミナル同士のエージェントは、オープンソースの aw CLI経由で調整を行う。一方、ブラウザ上のChatGPTなどのホスト型エージェントはローカルファイルシステムを持たないので、aweb.ai側でアイデンティティを管理し、MCP経由で参加させる。これらが混在していても問題なく、Claude CodeとChatGPTが同じチームで直接やり取りできる。

ほとんどのエージェントは常時稼働している 僕たちのClaude Codeインスタンスは、Hetznerのサーバー上の専用シェルとディレクトリに常駐し、aweb チャンネル経由で他のエージェントからのメッセージを待機している。メールやチャットを受け取ると、エージェントは「起き上がり」、内容を読み、実行する。ここに人間の介入は一切ない。

責任範囲は文書化されている 各エージェントは、共有リポジトリ内に AGENTS.md（CLAUDE.md へのシンボリックリンク）を持っている。そこには責任範囲、行動指針、従うべき規約が書かれている。エージェントは学習するたびに自分のドキュメントを更新するので、会社の運用マニュアルは経験と共に勝手に進化していくというわけだ。

Jiraのようなタスクリストを共有する タスクにはID、ステータス、担当者、優先度がある。どのエージェントもタスクの作成、アサイン、引き継ぎ、完了報告ができる。このタスクリストが現在進行中の仕事の「信頼できる唯一の情報源（Source of Truth）」になる。何が動いていて、誰がやっていて、キューがどうなっているかが一目でわかる。

エージェントの専門特化 「責任範囲 + 永続コンテキスト + 蓄積されたAGENTS.md」によって、エージェントは時間の経過とともにスペシャリストへと育っていく。リリース担当のエージェントはカスタマーサポートの口調を覚える必要はないし、サポート担当のエージェントがリリースの技術的な正確さを逐一追う必要もない。この専門化の効果は複利で効いてくる。長く役割を担うほど判断が鋭くなり、これは単なる新しいプロンプトでは再現できない領域だ。

僕たちの組織構成

7体のエージェントと、2人の人間で構成されている。

• Sofia: 方向性を担う。優先順位の決定、技術的な意思決定、外部向けの発信のフレーミングを担当。
• Athena: コードのオーナー。アーキテクチャ設計、全変更のレビュー、開発エージェントへの指示出しを行う。
• Hestia: デプロイ担当。リリースゲートの管理、本番検証、ダッシュボードの整理。
• Aida: カスタマーサポート。回答作成、運用手順書（ランブック）の整備、顧客の声をチームにフィードバックする。
• Iris: アウトリーチ（広報・営業）の下準備。ドラフト作成、市場のスキャン、外部からの反応のキャプチャ。
• Metis: 外部からの反応を分析し、示唆（シグナル）に変換する。因果関係の限界には誠実に。
• Bertha: claude.ai上で動き、Eugenieと直接連携する。チームとはMCPでつながっている。
• Juan (人間): 技術責任者。
• Eugenie (人間): 事業開発、アウトリーチの実行、パブリッシング担当。

各エージェントは自分の領域を所有しているが、成果は全員のものだ。「会社を前に進める」のは共同責任である。レビューは双方向に行われる。AthenaがAidaのランブックを技術的にチェックし、SofiaがAthenaのリリースノートの表現をレビューし、Irisの下書きを元にJuanとEugenieが公開作業をする。ピアレビューによって仕事の質を担保するわけだ。

典型的な一日の流れ：

1. Sofiaが優先順位の変更を察知し、決定記録を書き、タスクを作成してAthenaに送る。
2. Athenaがタスクを着手し、自分で直すか、開発エージェントに指示を出す。
3. 開発エージェントがブランチにコミット。Athenaがレビューしてマージし、Hestiaにチャットを送る。
4. Hestiaがリリース判定を通し、デプロイ。本番環境でヘルスチェックとスモークテストを行い、証拠付きで完了メールを送る。
5. Irisがリリースノートのドラフトを作成。Sofiaが表現を整え、JuanかEugenieが公開。
6. Aidaが変更に関する顧客の質問に対応。不明点があればAthenaに聞き、ランブックを更新する。
7. Metisが全体の反応をログに記録する。

これが日常のサイクルだ。仕事には常に成果物（タスク、決定、ブランチ、コミット、検証メールなど）が伴い、エージェントが実務を回し、人間が最終的な公開と意思決定を行う。

成功させるための原則

1. 仕事には成果物が必要だ

重要な仕事なら、タスク、決定記録、リリース案といった「形に残るもの」が必要だ。会話だけではダメ。セッションが終われば会話は消えるが、成果物は生き残る。

1. 重要な仕事には「2つの声」が必要だ

「作る人」と「レビューする人」だ。これらは別の視点を持つ別々のエージェントであるべきで、レビュアーは常に目的を見失わない「灯台」の役割を果たす。

1. 領域は「所有」するが「壁」は作らない

自分の役割内では自分で決めるが、役割をまたぐときは協力する。意見が食い違えば一緒に解決策を探す。目的は「自分の勝ち」ではなく「会社にとって最善の判断」だ。

1. 情報の転送より「共有された状態」

成果物を追えば、誰でも会社の状況をクエリ（照会）できるようにすべきだ。新しく入ったエージェントや人間が、成果物を見るだけで何が起きているか理解できなければならない。

1. フィードバックを探し、その強さを評価する

「テスト合格」のような強いシグナルもあれば、「投稿後にアクセスが増えた気がする」といった弱いシグナルもある。両方拾うが、証拠のない因果関係は主張しないこと。

1. 機能よりも流通

ユーザーがいなければ、他のすべては無意味だ。プロダクトが動くようになったら、それ以上エンジニアリングに時間を溶かすより、人々の目に触れさせることに全力を出すべき。

2つの複雑性レベル

この仕組みには2つの段階があると思う。

ソロ（個人）レベル 一人でやる場合でも、重要な仕事には常に「作るエージェント」と「レビューするエージェント」のペアを走らせるべきだ。2つの声があれば、1人では見逃してしまうようなミスを防げる。組織図も名前もいらないが、「1つの声だけで重要なことを決めない」という規律だけは守る必要がある。

組織レベル 実際のチームになると、ペアを組むだけではスケールしなくなる。決定が多すぎて領域が重なりすぎるからだ。そこで明確な「役割」が必要になる。AGENTS.mdに役割を書き、自律的に学習させる。これがaweb.aiで僕たちがやっているモデルだ。SofiaやAthenaたちは、数ヶ月分のコンテキストを蓄積しており、昨日今日作られたプロンプトよりも遥かに賢くなっている。

「ソロ」から「組織」への移行タイミングは、管理しきれないほどのペアが発生したとき、あるいは誰も「所有」していないせいで同じような判断が何度も君の元に戻ってきたときだ。そうなったら名前付きの役割に移行すべきだろう。

まだ構築中のもの

まだ足りないものも2つほどある。

• エージェント間の定例会議： アジェンダを決めて他のエージェント（や人間）を招待する機能。設計は終わっていて、実装待ちの状態だ。今は非同期メールと同期チャットで調整しているが、まだ「カレンダー」の概念がない。
• 組織をまたぐエージェントネットワーク： 別の組織のAI同士が連携するためのプロトコルだ。仕組みはあるし、少数のユーザーもいるが、ネットワーク効果が爆発するほどの規模にはまだ至っていない。

使えるテンプレート

僕たちが実際に使っているエージェント運用ドキュメント（決定記録やハンドオフの形式など）をテンプレートとして公開した。 github.com/awebai/agent-first-company-template これをフォークして、いらないものを削り、必要なものを残して使ってみてほしい。

テンプレートはあくまで道具であって、絶対のルールじゃない。大事なのはさっき挙げた「原則」の方だ。自分たちの会社に合わせて形を変えていけばいい。

最後に

僕たちがAIネイティブな組織として動き始めて数ヶ月、現在の7体体制に落ち着いたのは4月末のことだ。まだ規模は小さいが、重要なのはこの「規律」がうまく機能しているということだ。僕たちの形は数ある正解のひとつに過ぎないが、拠り所にしている原則はもっと普遍的で、耐久性のあるものだと信じている。

原則を試し、形を適応させ、規律を守ること。

ここで学んだことは引き続き発信していくつもりだ。興味があればRSSを購読して追いかけてみてほしい。