Cloud Service
Amazon WorkDocs
ファイルの保管・共有・共同編集をクラウドで完結。バージョン管理やコメントで業務文書を安全に扱える、フルマネージドの文書管理サービス WorkDocs。
- 1.ファイルをクラウドに集約して保存・共有し、Web/デスクトップ/モバイルから安全にアクセスできる
- 2.バージョン履歴・コメント・フィードバック依頼など、文書の共同作業を支援する機能を備える
- 3.ディレクトリ連携でユーザーを管理し、保存時暗号化や監査ログでガバナンスを効かせやすい
解決する課題
業務で扱うファイルをメール添付や各自のPCで管理していると、最新版がどれか分からなくなり、退職者の端末にだけ重要文書が残るといった問題が起きます。社外との共有も、無秩序なリンク共有では漏えいの温床になります。Amazon WorkDocs なら:
- ファイルをクラウドに集約し、Web・デスクトップ同期・モバイルから同じデータへアクセスできる
- バージョン履歴を自動で残し、過去の版へいつでも戻せる
- 共有相手や権限をユーザー単位で制御し、誰がいつアクセスしたかを記録できる
- 文書へのコメントやフィードバック依頼で、メールを往復させずに共同作業を進められる
主要概念と用語
- サイト: 組織ごとに作られるWorkDocsの作業空間。固有のURLを持ち、ユーザーやファイルはこの単位で管理される
- ディレクトリ: ユーザー認証の基盤。AWS Directory Service のマネージドディレクトリや、オンプレの Active Directory と連携して使う
- ユーザーの種類: 容量を割り当てられる正規ユーザーと、共有された文書のみ扱えるゲストなどの区分がある
- 共有とアクセス権: フォルダやファイル単位で、閲覧・コメント・編集・所有者といった権限を相手ごとに付与する
- バージョン: ファイルを更新するたびに自動保存される版。履歴から過去の版を参照・復元できる
- フィードバック(コメント): 文書上に残せる指摘やメモ。レビュー依頼を出して回収できる
- 同期クライアント(Drive): PCのフォルダとWorkDocsを同期し、ローカルファイルのように扱うためのアプリ
仕様・制限・クォータ
- WorkDocs サイトはリージョン単位で作成し、利用にはユーザー認証の土台となるディレクトリが必要
- 正規ユーザーには一定のストレージ容量が割り当てられ、組織のプランに応じて拡張できる
- 1ファイルあたりのアップロードサイズや、同時に扱える共有数などに上限があり、用途に応じて確認する
- 対応クライアントはWebブラウザ、Windows/macOS向けの同期アプリ、iOS/Android向けモバイルアプリなど
- アクセス可能なファイル形式やプレビュー対応形式は決まっており、未対応形式はダウンロードして開く
WorkDocs は提供方針が変わる場合があります。新規にサイトを設計する際は、最新の公式アナウンスとサポート状況を必ず確認してから採用を判断してください。
内部の仕組み
WorkDocs は、ファイルの実体を AWS が管理するストレージに保管し、メタデータ(所有者・共有先・バージョン情報など)を別途管理することで、共有や履歴の機能を提供します。利用者はWebやクライアントアプリからアクセスし、認証は連携したディレクトリで行われます。
- ユーザー認証はディレクトリ(マネージドディレクトリ、またはオンプレADとの連携)で行う
- ファイルを更新すると新しいバージョンとして保存され、過去の版も保持される
- 共有操作のたびにアクセス権が更新され、誰がどの文書にアクセスできるかが一元管理される
- 同期クライアントは変更を検知してクラウドと差分を同期し、複数端末で最新状態をそろえる
設計パターン / ベストプラクティス
- 既存ADと連携: オンプレの Active Directory やマネージドディレクトリと連携し、社員が普段のアカウントでサインオンできるようにする
- フォルダ設計で権限を整理: 部門・プロジェクト単位でフォルダを切り、共有はフォルダ単位で付与して管理を簡潔にする
- 社外共有はルール化: 外部ユーザーへの共有可否や、リンク共有の範囲を組織ポリシーで明確にする
- 退職時の引き継ぎ: 退職者の所有文書を別ユーザーへ移管する運用を決め、孤立ファイルを防ぐ
- 同期対象を絞る: 全社共有の巨大フォルダを無制限に同期させず、必要な範囲だけをローカル同期する
運用・監視
- CloudTrail でサイトの作成・ユーザー管理・共有設定などのAPI操作を記録し、監査に使う
- 管理者向けの管理画面から、ユーザーの追加・無効化やストレージ割り当てを管理する
- 文書のアクティビティ履歴で、閲覧・編集・共有などの操作を追跡できる
- 退職・異動に合わせてユーザーを速やかに無効化し、アクセス権を棚卸しする
- ディレクトリ側のパスワードポリシーやMFAと合わせて、全体のアクセス統制を維持する
コスト
利用者数に応じた課金が基本で、正規ユーザーごとに月額の費用とストレージ容量が割り当てられます。共有相手のうち閲覧のみのゲストは、正規ユーザーとは異なる扱いになることがあります。
| 利用区分 | 課金の考え方 | 主な用途 |
|---|---|---|
| 正規ユーザー | ユーザー単位の月額+割当ストレージ | 日常的に文書を作成・編集する社員 |
| 共有/ゲスト | 閲覧中心の限定利用 | 社外レビューや一時的な参照 |
- 使っていないユーザーは無効化し、人数ベースの費用を抑える
- ストレージの追加割り当ては費用に影響するため、不要な大容量ファイルの放置を避ける
- 具体的な料金は変動するため、採用前に公式の料金ページで最新の体系を確認する
WorkDocs はユーザー数が費用に直結します。退職者や休眠アカウントを定期的に棚卸しし、有効ユーザー数を実態に合わせましょう。
セキュリティ
- ファイルは保存時暗号化に対応し、鍵はKMSで管理できる
- 通信は暗号化され、Web・クライアント間のデータ転送を保護する
- ユーザー認証はディレクトリで行い、MFAやパスワードポリシーと組み合わせる
- 共有は相手ごとに閲覧・コメント・編集などの権限を分けて付与し、最小権限を徹底する
- 社外共有やリンク共有の可否を組織ポリシーで制御し、意図しない外部公開を防ぐ
権限を細かく設計せず、全社員に編集権限で共有したり、外部リンク共有を無制限に許可したりすると、文書をクラウドに集約する意義が薄れます。共有範囲は必ず最小権限で設計してください。
関連サービス・比較
オブジェクトストレージの Amazon S3 とよく比較されますが、S3 は「アプリやシステムが使う汎用ストレージ」、WorkDocs は「人が使う文書管理・共同作業の場」という位置づけの違いがあります。
| 観点 | WorkDocs | Amazon S3 |
|---|---|---|
| 主な利用者 | エンドユーザー(人) | アプリ・システム |
| 主目的 | 文書の保管・共有・共同編集 | 汎用オブジェクトストレージ |
| 共有・権限 | ユーザー単位の共有とコメント機能 | IAM/ポリシーによるアクセス制御 |
| バージョン管理 | 文書のバージョン履歴を標準で提供 | バージョニングを任意で有効化 |
ハンズオン / CLI例
# WorkDocsサイト(組織)の一覧を確認
aws workdocs describe-instances \
--query "Organizations[].{Id:OrganizationId}"
# 指定組織のユーザーを一覧表示
aws workdocs describe-users \
--organization-id d-0123456789 \
--query "Users[].{User:Username,Status:Status,Storage:Storage}"
# ルートフォルダ配下の文書とフォルダを確認
aws workdocs describe-folder-contents \
--folder-id <root-folder-id> \
--query "Documents[].{Name:LatestVersionMetadata.Name,Id:Id}"
AWS Service
Amazon WorkDocsを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
エンドユーザー / VDI
比較で見る軸
クラウド: AWS / カテゴリ: エンドユーザー / VDI / 難易度: basic
導入後に効く点
バージョン履歴・コメント・フィードバック依頼など、文書の共同作業を支援する機能を備える
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- エンドユーザー / VDI
- 難易度
- basic
- 関連資格
- SAA-C03
- 設計柱
- security / operational
判断チェックリスト
- 自社の用途が「エンドユーザー / VDI / security」に近いか確認する。
- 強みである「ファイルをクラウドに集約して保存・共有し、Web/デスクトップ/モバイルから安全にアクセスできる」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。