「このコミット、誰が書いたんですか」——その問いに、もう人間の名前だけでは答えられない。社内のエージェントが増えるほど、作業の記録には "Rovo"、"Claude"、"Codex" といった名前が混ざり、「誰が・何を・なぜ実行したのか」が曖昧になっていく。homula がエンタープライズのエージェント導入で最初にぶつかる壁も、たいていここにある。モデルの賢さではなく、実行の帰属（アカウンタビリティ）と統制だ。
2026年10月7日、アムステルダムで開かれた Team '26 Europe で、Atlassian が Agentic Multiplayer Protocol（AMP） を発表した（BusinessWire / SiliconANGLE）。狙いは明快で、AIエージェントを「ツール」ではなく名前と持ち主を持つチームの一員として扱い、人間と並べて管理することだ。この発表は、日本企業のAI推進担当にとっても見逃せない論点を含んでいる。本稿では AMP の要点を押さえたうえで、「名前を与えること」で解ける問題と、依然として残る問題を切り分ける。
AMPとは何か——発表の要点
AMP は、エージェントを Atlassian プラットフォーム上の「参加者」として扱うための枠組みだ。報道各社の整理を総合すると、中核は次の3つになる。
- 呼び出せる: Jira のコメント、Confluence、Loom などで、人間を
@mentionするのと同じようにエージェントを呼び出せる（Diginomica）。 - 帰属できる: すべてのエージェントが明確な「持ち主」と独立したプロフィールを持つ。Rovo 製も、サードパーティ製も、固有のアイデンティティを与えられる。
- 統制できる: エージェントは「ユーザーの権限を借りて（Run as User）」動くか、専用のサービスアカウントで動く。いずれの行動も監査証跡として残り、管理コンソール上に人間のアカウントと並んで表示される（Techzine）。
土台にあるのが Teamwork Graph だ。Atlassian によれば、追跡するオブジェクトと関係性は半年前の約1,500億から 2,500億以上 に増え、新しい Code Search により、ソースコードを関数・シンボル・クラス単位まで読み込むという。あわせて、作り直した MCP サーバー（Jira/Confluence タスクで最大25%のトークン削減を同社内ベンチで主張）、80以上のコネクタ、Jira 上のエージェントセッション、複数ステップを自律実行する Rovo Work モードなども発表された。同社は、プラットフォーム上で人間とエージェントが月あたり1,000万回以上協働しており、Rovo は Fortune 500 の80%超で使われていると述べている（いずれも同社公表値）。
重要なのは、AMP が MCP や A2A を置き換えるものではない点だ。各社の取材では、MCP（ツール接続）と A2A（エージェント間連携）は引き続きその下で動き、AMP はその上に「誰が参加者で、誰が持ち主か」という層を重ねるものだと説明されている。接続プロトコルの話ではなく、参加者の身元と帰属の話だと理解すると位置づけが掴みやすい。
「名前」で解ける問題——可視化とオンボーディング
まず素直に評価すべきは、この方向性が正しいということだ。homula も繰り返し主張してきたとおり、エージェント統制の出発点は「共有サービスアカウントを捨て、エージェントごとに固有のIDと持ち主を与える」ことにある（関連: AIエージェントに『それ専用のID』を）。先日の Google の「万能エージェントが自分のメールアドレスを持つ」という動きと同様（関連記事）、業界は確かに**「すべてのエージェントは誰かに答える存在であるべき」**という合意に収束しつつある。
名前を与えることで、少なくとも次が解ける。
| 解けること | 中身 |
|---|---|
| 可視化 | どのエージェントが稼働中で、何にアクセスでき、誰が持ち主かが一覧になる |
| 帰属 | 作業ログに人間と同じ粒度でエージェント名が残り、後から追跡できる |
| オンボーディング | 既存の @mention や権限の仕組みに乗せられ、現場が使い始めやすい |
人間のワークフローにエージェントを「同僚」として自然に差し込む設計は、導入の摩擦を大きく下げる。ここは率直に優れている。
「名前」で解けない問題——帰属は統制ではない
一方で、発表の読み方には注意が要る。複数のアナリストが指摘するのは、「誰が書いたかのラベル」と「重要な判断を誰がしたかの記録」は別物だという点だ。変更に著者ラベルが付いても、人間が意味のあるレビューをした証拠にはならないし、開発者はエージェントの出力を書き換えたうえで自分名義でコミットできる。帰属（attribution）は透明性の第一歩だが、実行の統制（enforcement）そのものではない。
さらに、タイミングの問題がある。より強い非人間ID（NHI）の統制機能——集中管理されたエージェント台帳やアクセス制限——は、報道時点で「近く提供」とされ、具体的な提供日が示されていないものがある（InfoWorld / Forbes）。つまり現状で確実に手に入るのは「基本的なエージェントIDと監査証跡」であり、「組織横断の強制力」はこれからの部分が残る。
統制を評価するときは、「可視化できるか」ではなく「止められるか」で測るべきだ。逸脱時に実行を遮断できるか、機密データの持ち出しをポリシーで拒否できるか、承認を挟めるか——ここが揃って初めて、監査証跡は「後からの証拠」から「事前の防波堤」になる。
ベンダーの壁——1社の中の統制と、エージェントが散らばる現実
最大の論点は境界だ。AMP は、サードパーティのエージェント（OpenAI、Anthropic、Cursor、Figma など）を Atlassian 上の参加者として迎え入れられるよう設計されている。開発者のPC上で Claude がバグ修正を走らせた痕跡を Teamwork Graph に取り込む、といった例も示されている。これは強力だが、裏を返せば**「Atlassian のプラットフォームに関わる限り」という条件付き**でもある。
ここで二つの現実がのしかかる。第一に、AMP は MCP のように標準化団体へ提出された公開仕様ではなく、Atlassian プラットフォーム内の設計仕様として存在する（winzheng の分析）。他ベンダーが独立に同じID体系を実装できる保証はない。第二に、企業のエージェントは Atlassian の中だけにいない。CI/CDパイプライン、n8n や Dify のワークフロー、自社の業務システム、SaaS に埋め込まれた名もなきエージェント——実行は組織全体に散らばる。1社のプラットフォームが自分の壁の内側で与えるIDは、その外側のエージェントには届かない。
だからこそ、AMP・Google・OpenAI が各々に進める「自社内での同僚化」は歓迎すべき前進でありながら、企業側には“ベンダー中立で、横断的に効く統制層”が別途必要になる。各ベンダーの囲いの中の身分証を、組織全体の実行統制に翻訳する層だ（この構造はエージェント管理レイヤーでも整理した）。
homulaの観点——「名前」の次に要る、横断的な実行統制
homula は、エンタープライズ向けの AIエージェント・インテグレーターとして、まさにこの「横断層」を設計の中心に据えている。勝ち筋は、ベンダーのID体系と対立するのではなく、その上に実行の統制を重ねることだ。
- 接続はベンダー中立に: Agens は MCP を活用し、200以上のツールと構築ゼロで接続する。AMP や各社のエージェントが増えても、接続点を1社に固定せず、中立なハブとして束ねられる。
- 統制は「止められる」まで: Agens Control が、承認フロー・DLP・RBAC・5年分の監査ログを提供する。帰属ラベルの先にある「事前の承認」と「逸脱時の遮断」、そして長期の証跡を、ベンダー横断で一枚に揃える。
- 順序を間違えない: まずは業務の棚卸しとプロトタイプ構築、ROI試算を3〜5日で回す AIエージェント・ブートキャンプから。どのエージェントに、どの権限を、どの承認を挟んで与えるか——組織の統制設計を、PoCの段階から織り込む。
AMP が示したのは、「エージェントに名前と持ち主を」という業界の正しい方向だ。だが名前は入口にすぎない。日本企業が問うべきは、**「名前を付けたあと、組織全体でそれを“止められる”のか」**である。
まとめ
- Atlassian の AMP（2026年10月7日発表）は、エージェントに固有IDと持ち主、監査証跡を与え、人間と並ぶ「参加者」として扱う構想。方向性は業界の合意に沿っており、可視化・帰属・オンボーディングの面で優れる。
- ただし帰属は統制ではない。著者ラベルは透明性の第一歩であって、承認・遮断・長期監査といった「止める力」とは別物だ。強いNHI統制機能は一部が「近く提供」で、提供日が未確定の要素も残る。
- AMP は公開標準ではなく、効力は基本的に Atlassian の壁の内側に及ぶ。企業のエージェントは estate 全体に散らばるため、ベンダー中立で横断的に効く統制層が別途必要になる。
- homula は、MCPベースの中立な接続（Agens）＋承認・DLP・RBAC・5年監査（Agens Control）で、各ベンダーの「名前」を組織全体の「実行統制」へ翻訳することを勝ち筋とする。
「名前を付ける」の先にある「止められる統制」を、自社のエージェント全体でどう設計するか。最初の一歩は、現状の棚卸しからで構いません。