Jira や Confluence などのサードパーティ製サービスを Loop でも「そのまま動くカード」として使いたいのに、Teams ではインタラクティブな Adaptive Card、Loop ページではただのサムネイル…。この記事では、このギャップが生まれる理由と、2025年時点で現実的に取れる設計・運用パターンを、開発者・情シス・現場ユーザーの視点でまとめます。
サードパーティ製 Adaptive Card × Loop ページの「今」を整理する
まずは、質問になりがちなポイントを噛み砕いて整理します。
- Teams チャットやチャンネルに Jira の URL を貼ると、リンク展開（unfurling）によって Adaptive Card ベースの Loop コンポーネントとして表示され、カード上からステータス変更などの操作ができます。
- しかし同じ URL を Loop ページに貼り付けると、多くの環境で 静的なサムネイルカードにとどまり、Teams のような双方向操作ができません。
- Teams 上で展開されたカードをコピーして Loop ページに貼り付けても、やはり静的カードのままです。
さらに、開発者や管理者が気にするのが .loop ファイルの扱いです。
- Microsoft 純正の Loop コンポーネント（表・チェックリストなど）は
.loopファイルとして OneDrive / SharePoint に保存される、というのが公式ドキュメントの説明です。 - ところが Jira などサードパーティ製の Adaptive Card ベースの Loop コンポーネントでは、どこにも
.loopファイルが作られていません。
この「挙動の違い」を理解するには、Loop コンポーネントの種類と ホスト（実行基盤）の違いを分けて見るのが近道です。
Loop コンポーネントと .loop ファイルの基本
まずは、Loop コンポーネント自体の構造をおさらいします。
第一者（Microsoft 製）Loop コンポーネント
Microsoft 公式ドキュメントでは、Teams や Outlook で作られる Loop コンポーネントは、実体としては OneDrive 上の .loop ファイルだと説明されています。
- 例：表、チェックリスト、番号付きリスト、段落など
- 作成元：Teams チャット、Teams チャンネル、Outlook メール、OneNote、Whiteboard など
- 保存場所：OneDrive や SharePoint の特定フォルダー（
Microsoft Teams Chat filesなど） - 特徴：
- リアルタイム共同編集（共同著者）
- バージョン履歴、保持ポリシーなどのガバナンスが SharePoint / OneDrive と一体
- Loop アプリや Office.com からも発見・検索が可能
言い換えると、「Loop コンポーネント＝.loop ファイルのビュー」と考えると分かりやすいです。
サードパーティ製 Adaptive Card ベースの Loop コンポーネント
一方で、2025 年時点の「Adaptive Card ベースの Loop コンポーネント」は、開発者が Teams メッセージ拡張とリンク展開を組み合わせて実装する、ホスト依存のカード表示です。
- URL を貼ると、Bot / メッセージ拡張が呼び出され、Adaptive Card JSON を返す
- JSON には
metadata.webUrlが含まれ、この URL がカードを一意に識別するキーになる - Teams や Outlook は、このカードを インタラクティブな Loop コンポーネント風 UIとして描画する
つまり、サードパーティ製の Adaptive Card ベース Loop コンポーネントは、ファイルとしての Loop コンポーネントではなく、「カードをどう表示するか」というホスト側の約束で成り立っています。
なぜ Loop ページでは「静的サムネイル」になるのか
ここが実務上もっとも困るポイントです。なぜ Teams では「動くカード」なのに、Loop ページでは「静止画っぽいカード」になってしまうのでしょうか。
Teams は Adaptive Card のフルホスト
Teams は、Bot Framework と Adaptive Cards のホストとして設計されています。
- カード内のボタンを押すと「Action.Execute」などのアクションが Bot に飛ぶ
- Bot が処理結果を返すと、カードが更新される（refresh）
- メッセージ拡張・リンク展開・Universal Actions など、双方向 UI のための仕組みが一式揃っている
Adaptive Card ベースの Loop コンポーネントも、この Teams のホスト機能を前提に設計されています。
Loop ページは同じホスト機能をまだ持っていない
対して Loop アプリ（Loop ページ）は、現時点では 同じレベルで Adaptive Card を実行するホストとしては実装されていない、と考えるのが妥当です。
- URL を貼るとプレビュー（サムネイル）カードは生成される
- しかしカード内のアクションを処理する Bot 実行基盤や、Adaptive Card の refresh ロジックが Loop ページには露出していない
- 結果として、「リンクのプレビュー」としては見えるが、Teams のように双方向に更新はできない
実際、Microsoft Q&A でも、サードパーティ製 Adaptive Card の Loop ページ上でのふるまいについて、「バグというよりはプラットフォームの制限」と整理されています。
公式ドキュメントとのギャップ
Adaptive Card ベースの Loop コンポーネントの公式ドキュメントでは、「Loop アプリに URL を貼ると Loop コンポーネントとして展開される」といった説明もありますが、これは主に サポートされているクライアントとシナリオを包括的に記述したもので、サードパーティ製コンポーネントが Loop ページで完全に Teams と同じ振る舞いをするとは明記されていません。
Q&A のモデレーターも「Loop ページでの完全なインタラクティブ動作を確認できる公式ドキュメントは見当たらない」とコメントしており、2025 年時点では、Loop ページ側の制限として受け止めるのが現実的です。
なぜ .loop ファイルが作られないのか
次に、「サードパーティ製の Adaptive Card ベース Loop コンポーネントで .loop ファイルが作られない理由」を整理します。
第一者 Loop コンポーネント：.loop ファイルを作る世界
Teams / Outlook で作成される表やチェックリストなどの Loop コンポーネントは、必ず裏側に .loop ファイルが存在します。
- 構造化された JSON とコラボレーション状態がファイルとして保存
- どのアプリから開いても同じ内容・同じ履歴を参照
- OneDrive / SharePoint のライフサイクル管理・保持ラベルなどの対象になる
サードパーティ Adaptive Card ベースのコンポーネント：レンダリングのみの世界
一方で Jira などのサードパーティ製 Adaptive Card ベース Loop コンポーネントは、Q&A の回答でも明言されている通り、.loop ファイルを生成しません。
- Adaptive Card の JSON は、毎回 Bot / メッセージ拡張から動的に返される
- カードの「実体」は Jira 側の課題やレコードであり、Microsoft 365 側には永続化されない
- Loop コンポーネントの「URL」は
metadata.webUrlなどのメタデータに紐づくだけで、ファイルシステム上の .loop には対応しない
この設計により、サードパーティ製コンポーネントは「どのチャットに貼っても同じ URL なら同じカードとして描画できる」一方で、Loop ファイルとしてのガバナンス（バージョン履歴、保持ラベルなど）の枠組みには入らない、というトレードオフがあります。
Teams と Loop ページの挙動を比較する
ここまでの話を、実務で使いやすい形にまとめた比較表です。
| シナリオ | Teams チャット / チャンネル | Loop ページ |
|---|---|---|
| Jira などサードパーティ URL を貼り付け | リンク展開により Adaptive Card ベースの Loop コンポーネントとして表示。カード上からステータス変更などが可能。 | 多くのケースで静的なサムネイル／リンク プレビューとして表示。インタラクティブ操作は不可（2025 年時点）。 |
| Teams 上のカードをコピーして貼り付け | 別のチャット／チャンネルでも同じインタラクティブカードとして動作。 | Loop ページに貼ると静的カードとして表示。元の挙動は再現されない。 |
| .loop ファイルの生成 | Microsoft 純正の Loop コンポーネントでは .loop ファイルが OneDrive / SharePoint に保存される。 | サードパーティ Adaptive Card ベース Loop コンポーネントでは .loop ファイルは生成されない。 |
| 主な用途 | ライブ更新・その場操作・通知の受信と対応 | 要点の整理、意思決定の記録、台帳としての管理 |
2025 年時点での結論：できること・できないこと
上記を踏まえて、2025 年時点での整理は次のようになります。
- Loop ページへ「ネイティブな」サードパーティ Loop コンポーネントを埋め込むことはできない
- Teams と同じレベルのインタラクティブカードを Loop ページに直接置くことは、仕様上サポートされていないと判断するのが妥当。
- サードパーティ Adaptive Card では .loop ファイルは作られない
- 第一者（Microsoft 製）の Loop コンポーネントとは保存モデルが異なる。
- Loop ページにサードパーティの生データを直接埋め込むための公式 API / 埋め込みポイントは未公開
- 現状は Teams メッセージ拡張 + リンク展開が中心。
- Loop ページのセクションやブロックを Graph API で直接 CRUD する手段も正式には公表されていない。
- 仕様拡張の要望は Microsoft Feedback Portal へ
- Q&A でも Feedback Portal への投稿が推奨されている。
現場ですぐ使えるワークアラウンド設計
「仕様だから仕方ない」で終わらせると誰も幸せにならないので、2025 年時点で現実的に取れるワークアラウンドを整理します。
パターン 1：操作は Teams、整理は Loop ページ
もっともシンプルでおすすめなのが、「操作の場」と「記録の場」を分離する設計です。
| 目的 | 推奨ツール | ポイント |
|---|---|---|
| Jira 課題の状態変更、コメント、承認 | Teams チャット／チャンネルの Adaptive Card | リンク展開カードをピン留めして「作業ハブ」にする。 |
| プロジェクトの台帳管理・意思決定ログ | Loop ページ（表・チェックリスト） | Jira キーや Teams スレッドへの URL を列として保持。 |
具体的な運用イメージは次の通りです。
- 各プロジェクトごとに「プロジェクト用 Teams チャンネル」と「プロジェクト用 Loop ページ」を用意。
- Jira で課題が作られたら、Teams メッセージ拡張から課題を検索して Adaptive Card を挿入。
- ステータス変更や担当者変更など、日々の更新は Teams のカード上で完結させる。
- Loop ページには「課題一覧」表を作り、以下のような列を持たせる：
- Jira キー
- 概要（要約文）
- 現在のステータス（手入力 or 定期的に更新）
- 担当者
- 期日
- Jira 課題 URL
- 関連 Teams スレッド URL
- 定例ミーティングでは Loop ページを開き、各行をもとに進捗確認。細かい操作が必要になったらリンクから Jira / Teams 側に飛ぶ。
Loop ページ側を「永続化された情報の台帳」、Teams 側を「瞬発的な作業場」と割り切ると、ツールごとの役割が明確になり、ユーザーにも説明しやすくなります。
パターン 2：Power Automate / Logic Apps で「ゆるく」つなぐ
「Teams 側のカードは自動で最新状態を流したい」という場合は、Power Automate や Azure Logic Apps を使って疎結合で連携させるのがおすすめです。
例：Jira 課題の更新を Teams カードに反映するフロー（イメージ）
- トリガー：Jira コネクタで「課題が更新されたとき」。
- アクション：
- Teams コネクタで該当チャンネルに「Adaptive Card を Post」する。
- カードの内容は、課題キー、概要、ステータス、担当者、期限など。
- 必要に応じて、既存メッセージを更新する形にしても良い。
Loop ページ側は、あくまで「要約とリンク」を保持するだけにしておき、リアルタイムな変更は Teams カードに任せる設計です。
ポイントは以下の 2 つです。
- Loop ページを「リアルタイム同期しようとしない」：完全同期を目指すと途端に複雑になり、結局破綻しがちです。
- 「人が見る画面」と「システムが更新する画面」を分ける：人が日常的に見るのは Teams、月次の振り返りやレビューでは Loop ページ、といった役割分担が使いやすいです。
パターン 3：「永続化したい情報」を Loop に落とす
Loop ページには、外部システムのすべての情報をコピーしようとせず、「将来振り返るときに必要になる情報」だけを抜き出すのがおすすめです。
例えば「インシデント・障害管理」の場合、Loop ページの表に次のような列を用意します。
- インシデント番号（Jira キーなど）
- 発生日
- 影響範囲（サービス名・顧客など）
- 暫定対応（1 行の要約）
- 恒久対策（決定事項の要約）
- ステータス（Open / Monitoring / Closed など）
- Jira / ServiceNow チケット URL
- ポストモーテム資料へのリンク
詳細なログ・コメント・議論の流れは Jira や Teams のスレッドに任せ、Loop には「意思決定と約束事」だけを残すイメージです。こうすることで、Loop ページは「人があとから読み返して理解しやすい台帳」として機能し続けます。
開発者向け：Adaptive Card ベース Loop コンポーネントの実装ポイント
ここからは、実際にサードパーティ製の Adaptive Card ベース Loop コンポーネントを開発する立場の方向けの整理です。
基本の実装フロー
Microsoft の開発者ドキュメントでは、おおむね次のステップで実装することが推奨されています。
- 検索コマンド付きメッセージ拡張を実装
- ユーザーが Jira の課題番号などを検索し、候補リストから選べるようにする。
- リンク展開（Link Unfurling）を有効化
- アプリ マニフェストに対象ドメイン（例：
your-jira.example.com）を設定し、その URL が貼られたときに Bot に invoke が飛ぶようにする。
- アプリ マニフェストに対象ドメイン（例：
- Adaptive Card JSON で Loop コンポーネントを表現
type: "AdaptiveCard"/version: "1.6"など。metadata.webUrlに、そのカードを一意に指す URL を設定する。refreshプロパティとAction.Executeを使って、ユーザー操作や定期更新に対応する。
- Microsoft 365 チャネルへの拡張
- アプリ マニフェストをバージョン 1.13 以降にし、Microsoft 365 チャネルを追加する。
- 必要に応じて SSO を構成し、ユーザーが再認証なしで Jira にアクセスできるようにする。
このパスで構築されるコンポーネントは、あくまで Teams / Outlook での動作が第一級であり、Loop ページでのインタラクティブな動作は保証されていません。この前提を設計時から共有しておくことが重要です。
「.loop にしたい」という要求への向き合い方
開発者からよく出る質問が、「サードパーティ製の Adaptive Card から .loop ファイルを生成して、ネイティブ Loop コンポーネントのように振る舞わせられないか？」というものです。
これに対して、2025 年時点では次のように答えるのが正直です。
- サードパーティ製コンポーネントから任意の .loop ファイルを生成し、第一者コンポーネントと同等の共同編集・ライブ同期をさせる方法は公開されていない。
- Graph API を使って Loop ページやコンポーネントを CRUD する公式手段も、現時点ではアナウンスされていない。
- 将来の計画についても、公開情報ベースでは読み取れない（Roadmap や Ignite / Build のセッションをウォッチするしかない）。
そのため、プロジェクト提案や顧客向け説明では、「今できること」と「将来の期待」を明確に分けて説明することが重要です。
よくある質問へのショートアンサー集
Q1. 「Loop ページでも Teams と同じように Jira カードを操作したい」
A. 2025 年時点ではできません。Loop ページには Adaptive Card をフルにホストする仕組みが提供されておらず、リンク展開も静的プレビューにとどまります。
実務上は「操作は Teams、整理は Loop」という役割分担を明示するのがおすすめです。
Q2. 「サードパーティの Adaptive Card でも .loop を作れないの？」
A. 作れません。第一者 Loop コンポーネント（表・チェックリストなど）は .loop ファイルとして保存されますが、サードパーティ製 Adaptive Card ベースの Loop コンポーネントは、メタデータにもとづく動的レンダリングであり、.loop ファイルは生成されません。
Q3. 「Graph API で Loop ページのセクションやブロックを直接読んだり書いたりできる？」
A. 公式にサポートされているとは言えません。Microsoft Q&A のモデレーターも、Loop ページの内容を直接操作する Graph API については公式情報がないとコメントしており、一般公開された API としてはまだ整備されていないと見るべきです。
Q4. 「今後、Loop ページ上でもインタラクティブカードが動くようになる可能性は？」
A. 可能性はありますが、時期や仕様は不明です。Loop や Adaptive Card ベース Loop コンポーネントは比較的新しい領域であり、Microsoft 365 Roadmap や公式ブログを見ると関連する更新が継続的に行われています。ただし「Loop ページでサードパーティ Adaptive Card を完全サポートする」という具体的な項目は現時点で見当たりません。
もし組織として重要なユースケースであれば、Microsoft Feedback Portal に要望を投げることをおすすめします。
導入・設計時のチェックリスト
最後に、これから Loop とサードパーティ連携を本格導入する際のチェックリストをまとめます。
- 1. どのユーザーストーリーで「カード上の操作」が必要かを洗い出す
- 例：インシデントのエスカレーション承認、チケットの担当アサイン、タスクの完了チェックなど。
- これらは必ず Teams（または Outlook）で完結できるようにデザインする。
- 2. Loop ページでは「何を残すのか」を決める
- 決定事項、最終的なステータス、外部システムのキー／URL など。
- ログのすべてをコピーしない。人間が読み返すときの「要約」に集中する。
- 3. 自動化でカバーする範囲を線引きする
- 「カードの自動投稿・更新」は Power Automate / Logic Apps に任せる。
- Loop ページの自動更新は「どうしても必要な部分」に限る（無理に完全同期しない）。
- 4. ガバナンスとコンプライアンスの要件を確認する
- .loop ファイルに対する保持ラベルや監査要件と、Jira 側の保持ポリシーを別々に整理する。
- 「どの情報がどのシステムに残るのか」を一度図にしておくと、監査やセキュリティレビューが通しやすい。
- 5. 仕様の変化を追う担当者・チームを決める
- Ignite / Build のセッション、Microsoft 365 Roadmap、公式ブログをウォッチする担当を決める。
- 仕様が変わったときに、社内の「ベストプラクティス」を更新できるようにしておく。
まとめ：2025 年のベストプラクティス
この記事で見てきたように、2025 年現在、サードパーティ製 Adaptive Card ベースの Loop コンポーネントは、Teams / Outlook では強力である一方、Loop ページ上ではインタラクティブに動作しないという明確な制約があります。
この制約を前提にしたうえで、実務としては次のようなスタンスが現実的です。
- 「操作は Teams、整理は Loop」という役割分担を徹底する。
- Loop ページにはネイティブ コンポーネント（表・チェックリスト）で台帳を作り、外部キー／URLで連携する。
- Power Automate / Logic Apps で Teams 側のカード更新を自動化し、Loop には要約とリンクを残す。
- 仕様拡張の要望は Feedback Portal で継続的に上げつつ、Roadmap や公式ドキュメントをウォッチする。
「Loop ページで Jira カードを直接いじれるようになる日」はいつか来るかもしれません。しかし、そこを待つのではなく、今の制約を踏まえた情報設計を先に固めておくことが、チーム全体の生産性を最も大きく押し上げてくれます。
まずはひとつのプロジェクトで、「操作＝Teams」「整理＝Loop」という分離パターンを試し、その結果をもとに自社なりのベストプラクティスを磨き込んでいくと良いでしょう。
コメント