みなさん、こんにちは。アトラシアンでコミュニティマーケティングを担当している新村です。今回は6月23日にDeNAさんに会場をお借りして開催された第81回 ACE Tokyo Meetupの様子をレポートしたいと思います。ACE Tokyoはアトラシアンの公式コミュニティで、アトラシアンに関心を持つ皆様の交流の場として多くの参加者にお集まりいただいています。東京を中心に活動していますが、今後はオンライン、オフラインを交えつつ、多くの方にご参加いただける形を作っていきたいと思っています。
今回はTeam on Tour Tokyoでも話題となったTeamwork Graphをテーマに、アトラシアンからの解説やユーザー視点での検証結果などを交えての会となりました。質問も多く出て、懇親会の時間が少し短くなってしまったほど盛り上がりました。
【MCP やコネクタだけじゃない！】ファイルシステム化による AI 連携の可能性【JIRAFS を作った話】
白柳さん (DeNA)
JIRAFSという新しいAI連携アプローチ
最初のセッションでは、DeNAの白柳さんが、JiraやConfluenceの情報を"ファイルシステムとして扱う"ことでAI連携を実現する試み「JIRAFS」について紹介しました。MCPや各種コネクタとは異なる角度から、AIにコンテキストを渡す方法を考えた発表で、会場でも強い関心を集めていました。
背景にあった実務上の課題
背景にある問題意識はとても実務的です。AI活用では、JiraやConfluenceにある情報をどうAIに渡すかが重要になりますが、実際にはセキュリティや権限管理、Slackなど他ツールとの分断、情報の分散、そしてユーザーにとっての使いやすさが課題になります。DeNAではそうした課題に向き合う中で、ChatAI「Rinchan」のような取り組みも行ってきた一方で、すべての利用者が権限や構造を意識してAIを使いこなすのは難しいという現実もあったそうです。
Jira / Confluenceをファイルとして扱う
そこで生まれたのがJIRAFSです。Jiraのプロジェクトやチケット、Confluenceのスペースやページを、ローカルのファイルシステム上に階層構造として見せることで、AIエージェントにとって扱いやすい形に変換します。チケットやページ本文だけでなく、添付ファイルやメタ情報もファイルとして参照でき、ConfluenceページはMarkdownやHTMLに近い形で内容を取得できるようにしているとのことでした。
ファイルシステム化による利点
このアプローチの面白さは、AIから見ると「読み取り専用の安全なファイル群」として扱える点です。ファイルシステムとして公開することで、権限を絞りやすく、AIエージェントには必要な情報をコンテキストとして与えやすい。特別な操作系を新たに覚えなくても、既存のAIツールやローカル環境と組み合わせやすいのも利点として語られていました。
人・仕事・情報の関係性をAIが読み解く ── Teamwork Graphが変えるチームコラボレーション
皆川 (アトラシアン)
Teamwork Graphを文脈層として捉える
皆川のセッションは、今回のMeetup全体の中心テーマでもあるTeamwork Graphを、なぜ今重要なのかという問題意識から丁寧にひもとく内容でした。ベースになっているのはTeam on Tourで他の方が講演した内容とのことですが、今回はACE Tokyo向けに補足も加えながら、Teamwork Graphを"AI活用のための文脈層"としてどう捉えるべきかが整理されていました。
AI活用が個人最適に留まる課題
冒頭で語られたのは、いま多くの組織で起きているズレです。個人単位ではAIによって作業速度が上がっている一方で、組織全体として見ると、業務プロセスにAIを組み込めている例はまだ多くありません。AIで仕事は速くなったはずなのに、組織としてのROIや意思決定の質にまで十分つながっていない。その背景にあるボトルネックとして示されたのが「コンテキスト不足」でした。
なぜコンテキストが重要なのか
単にデータがあるだけでは、AIは本当に必要な意味にたどり着けません。たとえば、関連しそうなチケットやドキュメントを検索して回答を作ることはできますが、それだけではデータ同士のつながりが見えず、ノイズが多く、推測ベースの回答になりやすい。ここで重要になるのが、誰が、どの仕事に関わり、どの知識とつながり、どの目標に向かっているのかという"関係性"です。
Team / Goal / Work / Knowledgeの4要素
Teamwork Graphは、そうした関係性を扱うための基盤として紹介されました。皆川の説明では、これは一種のナレッジグラフであり、特に Team / Goal / Work / Knowledge の4要素を中心に、組織内のデータや活動を結びつける役割を持っています。JiraやConfluenceだけでなく、サードパーティのアプリや外部データも含めて関係性を持たせることで、AIが"点の情報"ではなく"つながった文脈"として業務を理解できるようになります。
コンテキストの有無で変わる回答品質
セッションの中で印象的だったのは、コンテキストの有無による違いを具体的に比較していた点です。一般的なエージェントは、関連しそうなチケット、関連しそうなドキュメント、関連しそうな担当者情報を個別に探し、それらを組み合わせて回答します。しかしTeamwork Graphがある場合は、たとえば類似インシデントから、そのインシデントに紐づくPR、対応ドキュメント、担当者、所属チームまでを関係性ベースでたどれます。つまり、検索結果を並べるのではなく、グラフ上のつながりを辿りながら意味ある候補へ近づいていける。これが、回答の確からしさや意思決定のしやすさにつながるという説明でした。
マルチホップ検索がもたらす実務上の価値
この文脈で紹介されていたのが、マルチホップ検索の考え方です。キーワード一致だけではなく、「似た事象」→「関連PR」→「対応者」→「その人が属するチーム」→「過去のナレッジ」といった形で複数段階の関係をたどることで、組織の実態に沿った答えに近づける。結果として、ノイズを減らしつつ、トークン消費も抑えられるという点も実務上のメリットとして語られていました。
外部からも使えるTeamwork Graph
また、Teamwork GraphはすでにRovoの基盤として動いているだけでなく、外部からも活用できる方向に広がっています。セッションでは、MCPやCLI経由でTeamwork Graphを外から使えるようになってきたことや、Forgeを通じてJira以外のWorkデータ、たとえばAsanaやMondayのようなツールも取り込める可能性があることにも触れられていました。これは、Atlassian製品にすべての情報が蓄積されていなくても、組織全体のAI活用を成立させる方向に進んでいることを意味します。
AIをチームの基盤へ引き上げる
最後のまとめとして伝わってきたのは、AIを個人の便利ツールとして終わらせず、チームや組織の基盤へと引き上げるためには、モデル性能以上にコンテキスト設計が重要だというメッセージでした。Teamwork Graphはそのための中間層であり、AIとデータをつなぐ"構造化された文脈"そのものだと言えます。Team '26で語られていた中核メッセージが、より具体的なユースケースとともに腹落ちするセッションでした。
Teamwork Graph × AI による管理者として考慮すべきことの変化について
岡崎さん (DeNA)
管理者・運用者の視点から見るTeamwork Graph
岡崎さんのセッションでは、Teamwork GraphやAIの話を、管理者・運用者の視点からどう捉えるべきかが語られました。技術的な仕組みの理解だけでなく、「何をつなげるのか」「どこまで見せるのか」「どんな前提で整備しておくべきか」という、実際に運用する人にとっての論点が整理されていたのが特徴です。
コンテキストは設計と運用で価値を持つ
まず前提として示されたのは、コンテキストは自然に生まれるものではなく、設計と運用によって初めて価値を持つということでした。人間は、時間・空間・立場・経緯といった前提を無意識に補完して会話できますが、LLMはそこが苦手です。だからこそ、管理者には「AIが正しく理解できる状態を組織として整える」という新しい役割が生まれてきます。
管理者が考えるべきことは増えている
この文脈で、岡崎さんは"管理者は何もしなくてよいわけではない"と明確に語っていました。Teamwork Graphは自動的に形成されていく面がありますが、だからといって放置してよいわけではありません。むしろ、連携対象、権限設定、データの意味づけ、構造化の仕方によって、AIの出す答えの質や安全性が変わってくるため、管理者が考えるべきことは増えている、という整理です。
サードパーティ連携と権限の見極め
具体的には、サードパーティ連携の扱いが大きな論点として挙げられていました。Google Driveのような外部ツールをつなげば、確かにAIが参照できる文脈は増えます。しかしその一方で、どのコネクタ方式を使うのか、どの権限でつながるのか、元システム側のアクセス制御はどう引き継がれるのか、規約やデータ取り扱いはどうなっているのかまで見ておく必要があります。便利さだけで接続するのではなく、接続先アプリがどのようなデータを保持し、どのようにアクセス制御されるのかを把握した上で判断することが求められる、という指摘は非常に実務的でした。
製品仕様と契約プランの差分を把握する
また、Atlassian製品側の仕様変化や契約プランの違いによっても、AI活用の前提は変わります。たとえば、同じ機能名でもクラウドとサーバーで挙動が違ったり、利用者単位で有効化されるものと全社的に展開されるものが混在したりするため、管理者は「機能があるか」だけでなく、「誰が、どこで、どう使えるか」を把握しておく必要があります。AI導入が進むほど、こうした差分理解の重要性は増していくはずです。
デモで見えたコンテキストと回答の違い
セッション後半ではデモも交えながら、コンテキストによって回答がどう変わるかが紹介されました。同じ問いをしても、どのデータソースにアクセスできるか、どの領域を参照対象にするかによって、回答の粒度や妥当性が変わります。これは裏を返すと、管理者が整備した情報構造や権限境界が、そのままAIの振る舞いに反映されるということです。モデルの性能比較やプロンプトの工夫も大切ですが、それ以前に「AIが理解できる情報をどう組織内に整えるか」が重要なテーマになってきている、というまとめは非常に示唆的でした。
管理者は情報流通を設計する役割へ
さらに印象的だったのは、管理者の仕事が"設定する人"から"情報流通を設計する人"へ変わりつつあるという点です。OAuth 2.0やプライバシー、情報アーキテクチャのような周辺知識も含め、どのような情報がどう流れ、どの関係性がAIにとって意味を持つのかを見極める力が必要になる。Teamwork Graph × AIの世界では、単なる製品管理ではなく、コンテキスト設計そのものが管理者の役割になっていくのだと感じさせるセッションでした。
Teamwork Graph × AI によるチームワークや情報流通の変化について
伊藤さん (ACE Tokyo リーダー)
最後のLTでは、伊藤さんがTeamwork GraphとAIによって、チームワークや情報流通がどう変わっていくのかを、「情報と人の関係を使うことで、情報や人の見つけ方が変わる」という視点でコンパクトに共有しました。
目的を言語化できることが鍵になっていく
「同じようなことで困ってた人がどうやって解決されたか知りたい・話を聞きたい」という、以前からおなじみのお題を出発点に、Teamwork Graph による変化の考察が語られました。
従来の主流であった検索では、適切なキーワードを見つけ、結果からノイズを除外するステップを踏むことになります。一方でTeamwork Graph × AI（Rovo）の時代では、目的を伝えると意図を解釈して情報を探索して整理して回答してくれる、つまり、「目的の言語化が鍵になる」と。
Rovo が Teamwork Graph を通して見つけやすい情報の形とは
次は、情報に到達しやすくなるために適したConfluenceページの作り方は？という実践的なトピックです。Teamwork Graph には、その人のConfluenceページへの関わり方、create / update / mentioned-in / watch などが記録されます。ということは、ページに書いてある情報が限定されていると、人と情報の関わりが明確になる。そこから、「Teamwork Graph × Rovo の時代では、人や情報やゴールを見つけやすくするためには、Confluenceの１つ１つのページは特定の内容に絞られていると効果的（かもしれない）」という考察が紹介されました。
コミュニティでツールを使う力を育てていこう
LTの最後では、Teamwork Graph を意識した取り組みや事例紹介は少なく、コミュニティで経験や実感の共有を行うことでツールをよりよく使う力を育てていこう、というメッセージで締めくくられました。
懇親会
セッションが大盛り上がりで、若干懇親会も遅れ気味のスタートでしたが、今回のフード&ドリンクスポンサーをしていただいたリックソフトの甲斐さんの乾杯のご挨拶で懇親会がスタートしました。
今回は少し短い時間でしたが、いつも通り議論が白熱しておりました。
最後にいつもの集合写真で締めたいと思います。
