Atlassian、AIエージェント向けの文脈地図「Teamwork Graph」を解説　接続だけでは答えは出ない

執筆はHead of Product, Teamwork GraphのSanja Samirana Panda氏です。

結論から言うと、AIエージェントに判断させるには、ツールへの接続だけでは不十分だと整理されています。仕事のつながりと権限を記録した地図が必要だという考え方です。

たとえば、顧客から「15%の値引きで契約を更新できないか」と聞かれたとします。契約書は顧客管理システムに、値引きの方針は社内wikiに、承認はチケットにあります。AIが3つのシステムをつないでも、それぞれが「今回の顧客に当てはまるか」は分かりません。

記事では、現在よく使われる2つの技術を挙げています。RAG（検索結果を回答に組み込む仕組み）は、ベクトル検索で「内容が似ている文章」を探します。MCP（Model Context Protocol）は、AIがツールを呼び出すための共通の窓口です。Atlassianは、MCPは「データに届く道」で、ベクトル検索は「その中から似た文章を探す仕組み」だと説明しています。

ただし、似ていることは権限があることと同じではありません。割引の方針と承認が並んで出てきても、どちらがこの顧客、この地域、この契約期間に当てはまるかは分かりません。

接続と関係づけは別の仕事です

文脈グラフは、仕事の関係を記録したものです。「このエスカレーションはこの顧客のもの」「この承認はこの例外に効く」「次の対応はこの人が担当する」といった関係を、あらかじめ結びつけておきます。

一般的なナレッジグラフは「ものが何であるか」を表します。文脈グラフは、誰が何を持ち、何が決まり、今何が適用されるかという「仕事の動き」を表すと説明されています。

AtlassianのTeamwork Graphでは、既存のツールから関係を取り込み、仕事が進むにつれて更新するとしています。そのため、AIはタスクごとに関係を組み直さなくて済みます。ツールを増やすだけでは足りない理由も、ここにあります。

接続を増やすと、答えが変わります

同じ更新の例に、情報源を1つずつ足して説明しています。

最初は方針と契約書だけです。この段階では例外が必要だと分かりますが、誰が例外を認められるかは分かりません。

次に、その顧客に紐づくサポートのエスカレーションを足します。急ぎの度合いと取引上のリスクが変わったと分かります。ただし、急ぎであることは承認の代わりにはなりません。

3つ目は、Slackで話題になった似た事例です。先例のヒントにはなりますが、別の顧客についての最近のメッセージを今回の承認に置き換えてはいけないと記事は述べています。

最後に、記録された承認と顧客の担当者を結びつけます。承認が今回の顧客、地域、期間に当てはまるかを確認でき、次に動く人も分かります。承認が見つからない、または情報源同士が食い違う場合は、勝手に例外を通さず、確認に回すべきだとしています。

記事の要点は、情報源の数ではなく、情報同士の関係が回答を変えるという点です。

権限の範囲と、確認して止まる設計

文脈グラフの目的は、AIに「すべての文脈」を渡すことではありません。利用者とタスクに合った文脈だけを渡すことです。取り出した内容は判断の根拠として扱い、アプリの制御を上書きする指示としては扱わないとされています。

AIの推奨は行動の許可ではないとされています。実際の変更は、その行動を行うアイデンティティの権限に従います。

AtlassianのMCPサーバーでは、Teamwork Graphのツールを通じて、権限付きの関係を取得できると説明されています。ただし、取得や変更できる範囲は、人かエージェント用アカウントかを問わず、行動する主体の権限に従います。

日本での使い方と提供状況

記事は、Teamwork Graphの料金や日本での提供時期には触れていません。

一方で、MCPとCLIを使えば、Atlassian以外のAIモデルやエージェントからも同じ文脈を使える、と記事は説明しています。特定のAIベンダーに縛られにくいという考え方です。