Oracle Content Management

解決する課題

画像・動画・文書といったデジタル資産と構造化コンテンツを、サイトやアプリごとにバラバラに持たず、1つのコンテンツハブで一元管理して多チャネルへ配信できます。

• 部署やプロジェクトごとに散在する資産を集約して再利用したい
• マーケ用の Web・モバイル・外部アプリへ同じコンテンツを多チャネル配信したい
• フロントエンドの実装に縛られず、ヘッドレスCMSとして API でコンテンツを取りたい
• 作成・レビュー・承認・公開のワークフローとバージョン管理を効かせたい
• 多言語サイトの翻訳と地域別公開を管理したい

主要概念と用語

• インスタンス（OCE Instance）: Oracle Content Management の実体。テナンシ／コンパートメントに作成し、管理 UI と API のエンドポイントを持つ
• アセット（Asset）: 画像・動画・文書などのデジタル資産、およびコンテンツアイテム（構造化データ）の総称
• リポジトリ（Asset Repository）: アセットを束ねる入れ物。アクセス権・公開チャネル・分類（タクソノミ）・ワークフローを束ねる単位
• コンテンツタイプ（Content Type）: 構造化コンテンツのスキーマ定義。フィールドを定義し、コンテンツアイテムはこの型に従う
• コンテンツアイテム（Content Item）: コンテンツタイプに沿って作られた1件の構造化データ。ヘッドレス配信の主対象
• 公開チャネル（Publishing Channel）: コンテンツを公開する宛先の論理単位。チャネルトークンで配信先を識別する
• サイト（Site）: 組み込みのサイトビルダーで作る Web サイト。アセットを参照して構成する
• ワークフロー（Workflow）: 下書きから承認・公開までの状態遷移を定義する仕組み
• ヘッドレス配信: UI を持たず、REST API や GraphQL でコンテンツだけを取得して任意のフロントから利用する形態

仕様・制限・クォータ

• PaaS 型のマネージドサービス。インスタンス単位で提供され、基盤の OS やパッチは Oracle が運用する
• インスタンスはコンパートメント／リージョンに属するリージョナルリソース。配信先のチャネルやサイト URL はインスタンスに紐づく
• 作成にはオブジェクトストレージのネームスペースと IDCS（Identity Cloud Service）のアクセストークンが必要で、認証・ユーザー管理は IAM/IDCS と連携する
• アセットの最大ファイルサイズ、リポジトリ数、API レート、ストレージ容量などはサービス制限（Limits）やエディションで上限が決まり、引き上げや上位プランで拡張する
• コンテンツの取得は REST API と GraphQL を提供。公開済みコンテンツは CDN 経由で配信される
• バージョン管理・履歴を持ち、誤った公開はロールバックできる

内部の仕組み

コンテンツはリポジトリに格納され、コンテンツタイプで構造を定義します。作成者は管理 UI または API でアセット／コンテンツアイテムを登録し、ワークフローに沿ってレビュー・承認を経て公開チャネルへ公開します。公開されたコンテンツは内部のオブジェクトストレージに保持され、CDN を通じて配信されるため、世界中から低遅延で取得できます。

ヘッドレス利用では、フロントエンドがチャネルトークン付きの REST/GraphQL エンドポイントへ問い合わせ、公開済みのコンテンツアイテムやアセットを JSON で受け取ります。下書き状態のコンテンツはプレビュー用エンドポイントで確認でき、公開前に表示を検証できます。ユーザー認証とアクセス制御は IDCS/IAM と連動し、リポジトリ単位で閲覧・編集権限を分離します。

設計パターン / ベストプラクティス

• ヘッドレス配信: コンテンツタイプで構造を固め、公開チャネル経由で REST/GraphQL を叩く。フロントは静的サイトジェネレータやSPAで構築
• デジタル資産の中央管理: 画像・動画をリポジトリに集約し、各サイト・アプリから参照して再利用と一貫性を確保
• 多言語・地域別公開: 言語ごとにコンテンツの翻訳バリアントを持ち、地域別チャネルへ出し分ける
• ワークフローでガバナンス: 承認者を挟む公開フローを設定し、誤公開や未承認コンテンツの流出を防ぐ
• リポジトリ分割: 部署・ブランド・公開範囲ごとにリポジトリを分け、IAM/IDCS で権限を最小化する

運用・監視

• インスタンスの作成・更新・削除といった管理操作は**非同期のワークリクエスト（Work Request）**として実行され、進捗・エラー・ログを work-request 系コマンドで追跡できる
• すべての管理操作は **OCI Audit（監査ログ）**に記録され、誰がいつインスタンスやリポジトリを変更したか追跡できる
• ユーザー・グループ・ロールの管理は IDCS の管理コンソールで行い、アクセス権の付与状況を定期的に棚卸しする
• 公開コンテンツの利用状況やストレージ消費は管理コンソールのレポートで把握し、容量や制限への到達を早めに検知する

コスト

セキュリティ

• 認証・ユーザー管理は IDCS／IAM と連携し、ロールとグループでアクセス権を制御する。リポジトリ単位で閲覧・編集を分離できる
• 保存データ・転送データはともに暗号化され、API・配信は TLS（HTTPS） で行われる
• 公開チャネルとチャネルトークンで外部公開する範囲を限定し、未公開コンテンツが本番 API から漏れないようにする
• すべての操作は Audit に残り、不審なアクセスや権限変更を追跡できる

関連サービス・比較

公開済みコンテンツの実体はオブジェクトストレージに保持され、CDN で配信されます。生のファイル置き場である Object Storage と、コンテンツ管理・配信まで担う Content Management の役割の違いを整理します。

ハンズオン / CLI例

# Content Management（OCE）インスタンスを作成
# IDCS アクセストークンとオブジェクトストレージのネームスペースが必要
oci oce oce-instance create \
  --compartment-id "$COMPARTMENT_OCID" \
  --name "my-oce" \
  --admin-email "admin@example.com" \
  --idcs-access-token "$IDCS_ACCESS_TOKEN" \
  --object-storage-namespace "$OS_NAMESPACE" \
  --tenancy-id "$TENANCY_OCID" \
  --tenancy-name "my-tenancy"

# コンパートメント内のインスタンス一覧を確認
oci oce oce-instance list \
  --compartment-id "$COMPARTMENT_OCID" \
  --query "data[].{Name:name, State:\"lifecycle-state\"}" --output table

# インスタンスの詳細（管理 URL など）を取得
oci oce oce-instance get --oce-instance-id "$OCE_INSTANCE_OCID"

# 作成は非同期。ワークリクエストで進捗・エラーを追跡
oci oce work-request list --compartment-id "$COMPARTMENT_OCID" --output table