Viva Engage（旧Yammer）の「投票（Poll）」は、社内コミュニティで素早く意見を集めるのに便利です。一方で、Network Data Export API でデータを吸い上げようとすると「質問と選択肢は取れるのに票数が取れない」という壁に当たります。本記事では、APIの現状整理と、実務で困らないための代替策・設計のコツをまとめます。
結論：Viva Engageの投票結果（票数・集計）はAPIでは取得できない
先に結論を明確にすると、Viva Engage の投票（Poll）の「結果（票数や集計）」は、現状の公式APIでは取得できません。Network Data Export APIで出力される Messages.csv には投票の質問文と選択肢（オプション）までは含まれますが、投票結果そのもの（各選択肢の票数、合計票数、投票したユーザーなど）はエクスポート対象外です。
また、旧Yammer時代からある Core API（Yammer Core REST API）や、Microsoft Graph の Viva Engage API を見ても、投票結果を返す公式エンドポイントは用意されていない、というのがMicrosoft側の回答です。つまり「API経由で投票結果を自動収集する」ことは、現時点では機能ギャップとして残っています。
Network Data Export APIで「投票」がどう出力されるか
Network Data Export API は、Viva Engage ネットワーク内のメッセージやユーザー、グループなどをZIPにまとめ、複数のCSVとして返す仕組みです。HTTPのGETリクエスト1回でZIPが返る、同期型のAPIとして提供されています。
投票（Poll）は、エクスポート成果物の中では基本的に Messages.csv に含まれます。Microsoft Learn のCSV仕様を見ると、メッセージには message_type があり、値として poll が定義されています。さらに、投票に関係するカラムとして poll_options（選択肢）と poll_voting_closed_at（投票締め切り時刻）が用意されています。
| CSV/カラム | 意味 | 投票分析での使いどころ | 注意点 |
|---|---|---|---|
| Messages.csv | ネットワーク内の投稿・返信を格納 | 投票投稿（Poll）もここに入る | 結果（票数）は含まれない |
| message_type | メッセージ種別（normal/praise/poll/announcement など） | poll を抽出して「投票投稿一覧」を作れる | poll でも結果は別データとして存在しない |
| poll_options | 投票の選択肢 | 質問文＋選択肢の“設問定義”を保存できる | 票数はこの中に入らない |
| poll_voting_closed_at | 投票が締め切られた日時 | 「いつ集計すべきか」「締め切りを過ぎた投票」判定に使える | 締め切りが未設定/変更される運用もある |
ここまでを見ると、Network Data Export API は「投票という投稿が存在したこと」を記録するには十分です。たとえば、監査やアーカイブ目的で「いつ誰がどのコミュニティで投票を投げたか」「どんな選択肢だったか」を残すことはできます。しかし、結果集計（票数）や“投票という行動”のログは出力されないため、レポート用途で困りやすいのが実情です。
Network Data Export APIの実行例（最小構成）
「投票結果は取れない」とはいえ、まずは 投票投稿を漏れなく棚卸しできるようにしておくと、手作業集計の工数も読めます。Network Data Export API は、クエリパラメータで期間や対象モデル（CSV種別）を絞れます。
メッセージ（Messages.csv）だけを期間指定で取得する
ドキュメント上の例では、次のように since / until / model / include を指定できます（include=csv は添付ファイルを除外してCSVのみを返す指定です）。
GET https://www.yammer.com/api/v1/export?since=2025-12-01T00:00:00+00:00&until=2025-12-31T23:59:59+00:00&model=Message&include=csv運用のコツ：大きな一発より、短い間隔で回す
Network Data Export API の公式ドキュメントでは、信頼性の観点から「大きくて頻度の低いエクスポート」より「日次などの定期エクスポート」を推奨しています。投票投稿の棚卸しも、日次や週次でZIPを取得し、差分だけ処理する設計が現実的です。
Messages.csvから「投票投稿一覧」を作る（結果が取れない前提の自動化）
票数は取れなくても、投票の質問文・選択肢・締め切り・コミュニティが一覧化できるだけで、レポートや運用が楽になるケースがあります。たとえば「今月は投票が何本走ったか」「どのコミュニティで投票が多いか」などは、Messages.csvだけで可視化できます。
以下はPythonで、message_type=poll を抽出して“投票台帳”CSVを作る例です。poll_options の形式は環境や仕様変更で揺れる可能性があるため、JSONとして読めなければ文字列のまま出すようにしています。
import json
import pandas as pd
df = pd.read_csv("Messages.csv")
polls = df[df["message_type"] == "poll"].copy()
def normalize_options(v):
if pd.isna(v):
return ""
s = str(v)
try:
obj = json.loads(s)
# 例: ["A","B"] や [{"text":"A"},{"text":"B"}] などを想定して安全に整形
if isinstance(obj, list):
out = []
for x in obj:
if isinstance(x, dict):
out.append(str(x.get("text", x)))
else:
out.append(str(x))
return " / ".join(out)
except Exception:
pass
return s
polls["poll_options_norm"] = polls["poll_options"].apply(normalize_options)
cols = [
"id",
"group_name",
"sender_name",
"created_at",
"title",
"body",
"poll_options_norm",
"poll_voting_closed_at",
]
polls[cols].to_csv("poll_inventory.csv", index=False, encoding="utf-8")この台帳に、手作業で「票数」と「取得日時（締め切り後の最終結果か）」を追記する運用にすると、完全手作業よりはかなり軽くできます。
なぜ「票数・集計」が出力されないのか（仕様を読み解く）
Microsoft Learn のViva Engageデータエクスポート説明では、エクスポートに含まれない項目として「User activity data（ユーザー活動データ）」が明示されています。投票は「投稿（メッセージ）」としては残りますが、票を入れる行為はユーザーの活動ログに近く、設計上はこの“活動データ”側に寄っている可能性が高いです。結果として、質問と選択肢は残る一方で、票数がエクスポートに入らないと考えると、現場の体感とも整合します。
また、同じ「投票」に見える仕組みでも、Viva Engageには Answers（Q&A） のように“投票データがCSVとして用意されている”機能があります（例：Answers.csv に voterID が入る）。つまり、投票というUXがあっても、機能ごとにデータの扱いが違い、Pollについてはまだエクスポート/APIが追いついていない、という見方もできます。
Core API（Yammer Core REST API）で投票結果が取れない理由と注意点
「昔からあるYammerのREST APIなら取れるのでは？」と期待する方も多いのですが、Microsoftが公開している Core API 一覧には、投票結果専用のエンドポイントは含まれていません。さらに重要なのが、Microsoft Learn側で “一覧にないAPIは未公開・非サポートで、予告なく停止される可能性がある” と明記されている点です。ネットワークトレース等で見つけた非公開APIに依存すると、突然動かなくなるリスクが現実的にあります。
加えて、Core API 自体も「大規模な一括エクスポート用途ではない」ことが明確にされています。投票結果のような“集計系データ”を取りたい要件は、まさに一括集計・分析に寄るため、Core API で補完しようとしても設計が噛み合いにくいのがポイントです。
Microsoft Graph（Viva Engage API）でできること／できないこと
Microsoft Graph にも Viva Engage API が用意されていますが、現時点の主目的はコミュニティ（Community）の管理とロール（役割）の管理です。たとえば、コミュニティの作成や更新、ロールの割り当てなどが中心で、投稿メッセージや投票の結果を取得する用途はカバーされていません。
さらに、Graph の Viva Engage API は native mode のネットワークでのみサポートされ、legacy や external network には使えないという制約もあります。「Graphなら全部取れる」という期待を持っていると、ここでつまずきます。
できること／できないことを比較表で整理
| 観点 | Network Data Export API | Core API（Legacy） | Microsoft Graph（Viva Engage API） |
|---|---|---|---|
| 投票の質問文・選択肢 | 取得可能（Messages.csv に poll_options） | 公式には結果取得不可（専用エンドポイントなし） | 未対応（メッセージ/投票取得が目的ではない） |
| 投票結果（票数・集計） | 取得不可 | 公式には取得不可 | 取得不可 |
| 一括エクスポート適性 | 高い（ZIPでCSV一式） | 低い（bulk export用途ではない） | 対象外（管理系が中心） |
| 権限/前提 | Verified Administrator などの権限が前提 | 利用できる範囲はエンドポイントと権限次第 | native mode前提＋Graphの権限設計 |
| 将来の安定性 | 公式ドキュメントあり | 未公開API依存はリスク大 | 公式だがカバー範囲が限定的 |
現実的な代替策：運用で「投票結果」を残す
APIで自動回収できない以上、短期的には「運用で欠落を埋める」設計が必要です。ポイントは、手作業を“属人化させず、作業量を最小化する”ことです。
UIで結果を確認し、記録の型を決める
おすすめは、投票を実施するチームで「結果の保存フォーマット」を先に決め、締め切り後に一度だけ記録する運用です。スクリーンショットでも転記でも構いませんが、後から追えるように最低限のキー項目を残します。
| 記録項目 | 例 | 残す理由 |
|---|---|---|
| 投票URL（または投稿ID） | https://…/threads/123456789 | 元投稿へ戻れるようにする |
| コミュニティ名 | 全社連絡 / 情シス | どこで行われた投票かが重要 |
| 質問文 | 新ポリシー案に賛成ですか？ | 集計結果だけだと意味が分からなくなる |
| 選択肢 | 賛成 / 反対 / どちらでもない | 設問定義を固定する |
| 各選択肢の票数 | 賛成 42、反対 5… | 欲しいのはここ。後追い集計できないため必須 |
| 取得日時 | 2026-01-04（例） | 締め切り後の最終結果かどうか判断できる |
| 証跡（スクショ/添付） | PNG、PDF | 監査・レビューで説明が必要な場合に有効 |
手作業が発生しても、上記のように“型”があれば、担当が変わっても運用が継続しやすくなります。特に投票が多い組織では、SharePointリストやExcel台帳など、検索できる場所に記録するのが現実的です。
定期集計が必須なら「最初から集計APIがある投票」に寄せる
月次・四半期のレポートで投票結果が必ず必要なら、Viva EngageのPollにこだわるより、集計やエクスポートが前提の投票ツールへ寄せたほうが長期的なコストが下がります。代表例が Microsoft Forms です。
具体的には「Formsでフォーム（投票）を作る → Viva Engageにリンクを投稿する」という形にすると、回答データの扱い（エクスポートや自動化）が一気にやりやすくなります。投票UIは2つに分かれますが、レポート・監査・自動集計を重視する組織では、この割り切りが効きます。
「Viva Engageのコミュニティで意見を集めたい」という目的が主なら、投稿の可視性や議論の文脈はEngage側に残しつつ、数値化する部分だけをFormsに逃がす、という設計です。
投票を“分析可能なデータ”にするための設計のコツ
投票結果を取りたい要件があるなら、実施前の設計で“後から困らない形”にしておくのが重要です。特に、Data Export APIで残るのは質問文と選択肢までなので、ここを最大限活用します。
| 設計のコツ | やること | 期待できる効果 |
|---|---|---|
| 投票タイトルに識別子を入れる | 例：「【2026Q1】在宅勤務ルール投票」 | Messages.csv上で検索しやすい |
| 選択肢を短く固定する | 「賛成/反対」など、表記ゆれを抑える | 集計・比較がしやすい |
| 締め切りを必ず設定する | poll_voting_closed_at を有効活用 | 手作業の集計タイミングが決まる |
| 投票の目的を本文に書く | 「結果は○月○日にまとめて共有します」等 | 参加率が上がり、集計の説明もしやすい |
| 結果の保存先を先に宣言する | SharePoint/Teams/議事録など | “誰が保存するか問題”を減らす |
それでも自動化したい場合に考えるべきこと
「どうしても自動集計したい」という声が出るのは自然です。ただし、現時点では公式APIでの取得手段がないため、自動化＝非公式手段への依存になりがちです。過去には、ブラウザの通信を解析して非公開エンドポイントを叩く方法が紹介された例もありますが、サポート外であり、仕様変更・停止・セキュリティ面のリスクを抱えます。
社内システムに組み込むなら、次の観点で一度立ち止まることを推奨します。
- 非公式APIへの依存は、運用担当者が変わったときに保守不能になりやすい
- 認証やアクセス制御が不透明になり、監査で説明できない可能性がある
- 仕様変更で突然取得できなくなった場合、業務影響が大きい
フィードバック提出が最も確実な“将来の解決策”
現時点での公式な推奨対応は、Microsoftのフィードバックチャネルに要望を上げることです。Microsoft Q&Aでも、投票結果エクスポートは「機能ギャップ」であり、フィードバックポータルへの投稿・賛同（Upvote）を案内しています。
Microsoft 365 のフィードバックは、アプリ内の「フィードバック」機能から送る方法もありますが、“公開のコミュニティフィードバック”としては Microsoft Feedback Portal が案内されています。ここでは既存の要望を探して投票でき、同種の要望が増えるほど優先度が上がる可能性があります。
フィードバックの出し方（具体例）
- Microsoft Feedback Portal にアクセスし、Viva Engage 関連のフォーラムを検索する
- 同じ要望があれば Upvote し、追加でユースケースをコメントする
- なければ新規で要望を作成し、再現手順・期待結果・代替策の有無を具体的に書く
要望を書くときは「なぜ必要か」を業務要件として説明すると通りやすくなります。例えば、次のようなテンプレートを使うと整理しやすいです。
【要望】Viva Engage Poll の投票結果（票数・集計）を API / Data Export で取得できるようにしてほしい
■背景
- コミュニティ運営のレポートを月次で作成している
- 現状のNetwork Data Export APIでは Messages.csv に投票の質問と選択肢は出るが、票数が取得できない
■困っている点
- 管理画面/投稿UIで手作業集計が必要で、工数と属人化が発生
- 証跡として結果を残すにはスクリーンショットが必要で、監査対応が煩雑
■実現してほしいこと
- 投票IDごとに、各選択肢の票数、総票数、（可能なら）締め切り時点の結果を取得できるAPIを提供してほしい
- Data Export の成果物に poll_results のようなCSVまたはカラム追加でも良い
■期待効果
- コミュニティ運営の改善がデータドリブンになる
- 手作業が減り、監査・レポートの品質が上がるよくある質問
Q. Messages.csv に poll_voting_closed_at があるのに、なぜ票数がないの？
A. データエクスポート仕様として、Pollは「投稿の定義（設問）」は出力されますが、投票行為や集計結果は対象外です。Microsoft側も現状は取得できないと回答しています。
Q. Core API の messages 系エンドポイントを叩けば取れますか？
A. 公式には投票結果取得を提供していません。未公開APIや非公式手段に頼ると、停止や仕様変更のリスクがあるため、業務システムでの採用は慎重に判断してください。
Q. Microsoft Graph で将来取れるようになりますか？
A. 将来の拡張可能性はありますが、現時点のGraphのViva Engage APIはコミュニティ管理とロール管理が中心で、投票結果取得はカバーされていません。必要ならフィードバックとして要望を上げるのが近道です。
まとめ
Viva Engage（旧Yammer）の投票（Poll）は、Network Data Export APIで「質問と選択肢」までは取得できますが、「票数・集計結果」は取得できません。Core APIやMicrosoft Graphにも、投票結果を返す公式エンドポイントは現状存在しないため、短期的にはUIでの記録運用、長期的にはForms等の代替や、フィードバック提出による機能拡張要望が現実的な打ち手になります。
コメント