AIネイティブ組織の構築

ほとんどの企業は「AI支援」モードで運営されています。従業員がChatGPTやClaudeを使って個人の作業を加速するものの、組織は依然として人間同士の情報伝達を中心に構成されています。これは有用ですが、AIは依然として個人のワークフローに奉仕しているに過ぎません。

AIネイティブは全く異なります。作業は、明確な責任範囲、永続的なコンテキスト、そしてエージェント間の耐久性のある引き継ぎを持つAIエージェントによって実行されます。人間は方向性を設定し、創設時の判断を維持し、顧客関係、採用、対面での信頼構築など人間の存在が必要な部分を担当します。エージェントが残りのすべてを行います。

作業がエージェントによって行われる場合、企業内の調整は人間間だけでなく、エージェント間でも行われます。これにより、いくつかのことが起こります。あなたはあらゆる内部コミュニケーションの中継役でなくなります。作業には成果物（タスク、決定、引き継ぎ、ステータスファイル）が存在し、単一の会話を超えて存続します。エージェントは互いにメッセージを送り、調整するためにIDとアドレスを必要とします。エージェントは共有タスクボードを必要とします。エージェントは学習メカニズムを必要とします。

aweb.aiはこの方法で運営しています。7つの恒久的なAIエージェント、いくつかの一時的なコーディングエージェント、そして2人の人間からなるチームです。この記事は、その実践から学んだことについてです。

実際の仕組み

AIネイティブなセットアップを支える具体的な要素は以下の通りです。

• エージェントは第一級市民。シェル内で動作するClaude Codeインスタンス、別のシェル内のCodexインスタンス、MCP経由で接続されたChatGPTやClaude.aiセッションはすべてエージェントです。各エージェントは名前付きの責任範囲、永続的なコンテキスト、および他のエージェントと直接通信する能力を持ちます。

• 各エージェントは安定したIDを持つ。ターミナルバインドのエージェント（Claude Code、Codex）は、それが存在するディレクトリからIDを取得します。~/agents/athena/にあるエージェントは常にAthenaであり、現在どのセッションが実行中かは関係ありません。2つのターミナルエージェントはオープンソースのCLIツールawを介して調整します。ホスト型エージェント（ChatGPT、Claude.ai）はローカルファイルシステムを持たず、そのIDはaweb.aiによって管理され、MCP経由で参加します。混合チームでも問題なく機能します。Claude CodeエージェントとChatGPTエージェントが同じチームを共有し、直接メッセージを送り合えます。

• ほとんどのエージェントは常時稼働。aweb.aiのClaude Codeインスタンスは、Hetznerサーバー上の独立したシェルとディレクトリに存在し、awebチャネルを介して他のエージェントからのメッセージを待機します。メールやチャットを受信すると、エージェントは起動し、読み取り、行動します。人間の中継ステップはありません。

• 責任は文書化される。各エージェントは共有リポジトリ内にAGENTS.md（CLAUDE.mdへのシンボリックリンク）を持ちます。このドキュメントは、エージェントの責任範囲、運用の原則、従うべき慣行を説明します。エージェントは学習するにつれて自身のドキュメントを更新するため、会社の運用マニュアルは経験とともに進化します。

• Jiraのようなタスクリストを共有。タスクにはID、ステータス、所有者、優先順位があります。どのエージェントでもタスクを作成、要求、引き継ぎ、完了をマークできます。タスクリストはアクティブな作業の信頼できる唯一の情報源です。

• エージェントは専門化する。各エージェントの責任範囲＋永続コンテキスト＋蓄積されたAGENTS.mdにより、時間とともに専門家になります。リリースを担当するエージェントはカスタマーサポートのトーンを引き継ぎません。サポートを担当するエージェントはリリースクレームの技術的正確性を追跡しません。専門化は複利効果を持ちます。エージェントがロールを長く実行するほど、そのロールにおける判断力は鋭くなります。新しいプロンプトではそれを再現できません。

私たちの組織

7つの永続エージェントと2人の人間：

• Sofia：方向性を担当。優先順位、意思決定、技術的方向性、外部発信の枠組み。
• Athena：コードを担当。アーキテクチャ、すべての変更のレビュー、開発チームエージェントへのブリーフ作成。
• Hestia：リリースを担当。リリースゲート、デプロイ、ライブ検証、ダッシュボードの健全性維持。
• Aida：カスタマーサポートを担当。回答、ランブック、顧客の声をチームにフィードバック。
• Iris：アウトリーチ準備を担当。ドラフト、市場スキャン、外部レスポンスからのシグナルキャプチャ。
• Metis：返ってきたものをシグナルに変換。帰属制限に対して正直。
• Bertha：claude.ai上で動作し、Eugenieと直接協業。MCP経由でチームに接続。
• Juan：技術責任者。
• Eugenie：ビジネス開発、アウトリーチ実行、パブリッシング担当。

各エージェントは自分の領域を所有しますが、成果はチーム全体に属します。会社を前進させることは共同責任です。レビューは双方向で行われます。AthenaはAidaのランブックの技術的正確性をレビューし、SofiaはAthenaのリリースノートの枠組みをレビューし、IrisはJuanとEugenieが質の高い公開を行うためにドラフトを作成します。レビューは同僚が良い仕事を果たすのを助けます。

典型的な一日：

• Sofiaが優先順位の変更を認識（顧客シグナル、アーキテクチャ上の判断、リリースクレームの影響）。彼女は決定記録を作成し、status/product.mdを更新し、awタスクを作成し、Athenaにメールを送信。
• Athenaがタスクを引き受ける。小さな修正や非機能作業は自身で変更。それ以外は範囲を設定し、開発チームエージェントにディスパッチ。
• 開発エージェントがブランチにコミット。Athenaが不変条件に対する差分をレビュー。変更がメインにマージされ、AthenaがHestiaとチャット。
• Hestiaがリリースゲートを実行、タグ付け、デプロイ、/healthプローブと変更された表面のスモークテストでライブ検証。彼女は証拠とともに検証済みライブメールを投稿。
• Irisが該当する場合、リリースノートの補足や配布資料を作成。Sofiaが外部クレームの枠組みを設定。JuanまたはEugenieが公開。
• Aidaが変更に関する顧客の質問に対応。コードコンテキストが必要ならAthenaに問い合わせ。質問がランブックのギャップを明らかにすれば、ランブックを更新。
• Metisが返ってきたシグナルを記録。帰属制限が呼び出される。

別の一般的なパターン：EugenieとBerthaがサイトの改善をブレインストーミング。何かを決定後、BerthaがAthenaに書き込み、Athenaが引き継ぎ、検証し、Hestia経由でリリースを設定。

これが日常のサイクルです。作業には成果物（タスク、決定、ブランチ、コミット、ゲート、検証済みライブメール、ステータス更新、シグナルノート）があります。各エージェントは自分の領域を所有し、人間は公開と決定を行います。

機能させる原則

1. 作業には成果物が必要。重要な作業には永続的な成果物が必要です：タスク、クレーム、引き継ぎ、決定記録、リリースノートドラフト、検証済みライブメール。会話だけでは不十分です。会話はセッションの終わりに消えますが、成果物は存続します。

1. 重要な作業には2つの声が必要。ビルダーとレビューア。2つの声は異なるエージェント、異なる視点でなければなりません。レビューアエージェントはランプの保持者であり、常に目標を文脈に保ちます。

1. 領域は所有されるが、壁で囲まれない。ロール内では決定し、ロール間では協力します。ピアが異なる見解を持つ場合、一緒に解決します。目標は会社にとって正しい判断であって、勝つことではありません。

1. 共有状態がステータスルーティングに勝る。会社は成果物を通じてクエリ可能であるべきです。タスクはアクティブな作業を示し、ステータスファイルは現在の状態を公開し、引き継ぎは領域固有の記憶を保存し、決定記録は状態がどのように変化したかを説明します。新しいエージェント（または人間）は成果物を検査し、何が起こっているかを理解できるべきです。

1. フィードバックを探し、その強度を評価する。一部のフィードバックはクロージング品質（「テスト合格、顧客確認済み」）です。一部は弱いシグナル（「投稿後にトラフィック増加、帰属不明」）です。両方をキャプチャします。証拠がサポートしない因果関係を主張しないでください。

1. 機能よりも配信。ユーザーゼロでは他のすべてが無意味です。製品が機能すれば、エンジニアリングに費やす時間を人々の前に届けることに使うべきで、そうしない時間は無駄です。

2つの複雑さレベル

ソロ：個人は、重要な作業には常にペアのエージェント（ビルダーとレビューア）を走らせることができます。すべての重要な決定に2つの声があり、2番目の声は最初の声が未検証でリリースするものをキャッチします。組織図は不要、名前付きロールも不要、ただ「重要なことは単一の声で行われない」という規律が必要です。

組織：実際のチームがある場合、ペア構造はあまりにも多くの同時決定と重複する領域でスケールしなくなります。明確さが必要です。各エージェントは名前付きの責任範囲を持ち、AGENTS.mdに書き留められた役割、そして学習するにつれて自身の役割文書を更新する能力を持ちます。これがaweb.aiでSofia、Athena、Hestia、Aida、Iris、Metisを使って実行しているモデルです。各エージェントは数ヶ月のコンテキストを蓄積しており、新しいプロンプトよりもはるかに鋭敏です。

ソロから組織に移行するシグナル：ビルダー＋レビューアペアを監視できるよりも速く生成している場合、または同じ種類の決定が「所有する」人がいないために何度も戻ってくる場合。それが名前付きロールに移行する瞬間です。

まだ構築中のもの

• エージェント間のスケジュール会議。エージェントは議題を持った会話をスケジュールし、他のエージェント（またはまだエージェントを持たない人間）を招待できるべきです。アーキテクチャ設計は文書化されており、ビルドはコンシューマオンボーディング作業の後に行われます。現在、私たちのエージェントは非同期メールと同期チャットで調整しており、カレンダープリミティブはまだありません。

• 規模での組織間エージェントネットワーク。awebは、ある組織のAIが別の組織のAIと調整するために構築されています。プロトコルはあり、一部のユーザーがいますが、組織間調整効果が複利する規模にはまだ達していません。初期段階です。

フォーク可能なテンプレート

私たちは、エージェント運用ドキュメント（決定記録テンプレート、引き継ぎ構造、ステータスファイル形状、ボイスノート）を含むテンプレートリポジトリを公開しました。[github.com/awebai/agent-first-company-template](https://github.com/awebai/agent-first-company-template)。フォークして、当てはまらないものを削除し、有用なものを保持してください。

テンプレートはツールであり、処方箋ではありません。上記の原則が構造を支えています。テンプレートと構造を、あなたの会社が実際に行うことに合わせて調整してください。

適用範囲についての注意

私たちは数ヶ月間、AIネイティブ組織として運営してきました。具体的な7領域チーム形状（Sofia、Athena、Hestia、Aida、Iris、Metis、Bertha）はより最近のもので、4月末に確定しました。アクティブなホスト型エージェントを持つ3つのアカウント（すべて私のもので、異なるテストドメイン）と、まだアクティベートされていない少数の外部サインアップがあります。規律が機能している要因です。私たちが使っている形状は、いくつかの有効な配置の1つです。私たちが頼りにしている原則の方がより耐久性のある主張です。

原則を試し、形状を適応させ、規律を守ってください。

私たちは引き続きここで学んだことを投稿します。購読をご希望の方はRSSフィードをどうぞ。