チャネルはいくつでも作成することができます。ただし、テンプレートやメソッドの展開処理は、各ページについてチャネルの数分実行されるため、コンテンツ生成時間（FTP時間）はチャネル数に比例して増加します。チャネル数が２倍になると、コンテンツ生成時間も２倍になると考えてください。
8章 マルチデバイス配信
1. 多チャネル化
マルチデバイスへのコンテンツ配信、つまり、複数のタイプの違うデバイスに対して、それぞれのデバイスに向けて最適化したコンテンツの配信を行う場合には、プライマリチャネルの他に、デバイス用のチャネルを作成して対応します。
例えば、スマートフォン向けのサイトを併設する場合には mobile というチャネルを作ります。（チャネル名は自由につけてください）作成したチャネル mobile には、スマートフォン向けのコンテンツの配信先の設定を行ないます。テンプレート側では、チャネル mobile 向けのコンテンツを生成する時にはスマートフォン向けコンテンツを生成するように展開とメソッドを作成します。 必要があれば、特定のデバイス用の要素定義も加えてください。例えば、モバイル向けのページには、記事のタイトルなどに、PC用のタイトルとは違う、より短いものを使用する必要があるかもしれません。
それぞれのチャネルは、コンテンツの配信先に応じたそれぞれの URL を持ちます。さまざまなデバイスからのアクセスを、そのデバイスのタイプに従って適切な URL に誘導することで、デバイスに最適化されたコンテンツの提供が実現されます。
異なるデバイス向けに同一の URL を通じて異なるコンテンツを提供することも可能ですが、現在の WebRelease は直接はその方式をサポートしていません。チャネルごとに異なる URL を与えることを基本としています。
現状、ブラウザのキャッシュは、URL をキーにして、その URL から得られたオブジェクト（コンテンツ）をキャッシュする仕組みになっています。そのため、同一の URL で異なるコンテンツ（あるときは PC 用、また、あるときは スマートフォン用のコンテンツ）を配布すると問題を引き起こすことがあります。例えば、スマートフォンでサイトを閲覧中のユーザが、スマートフォン用のコンテンツの閲覧から PC 用コンテンツの閲覧に切り替えた後で、（つまり、スマートフォンで PC 用のコンテンツを閲覧することを選択した後で）PC 用コンテンツ中に含まれる、既に閲覧済みでキャッシュにコンテンツが保持されているページへのリンクをクリックした場合に、本来、PC 用のコンテンツが表示されるべきところで意図していないスマートフォン用のコンテンツが表示されてしまうなどの問題が起きてしまうことがあります。現状、スマートフォン上のブラウザは、あまり積極的にキャッシュのバリデートをしないようです。これは、通信量を極力減らす方向でチューニングしていることが理由であろうと考えられますが、将来的にはチューニングの方向が変わることも考えられます。
キャッシュの動作を制限することでこの種の問題を解決することも可能ですが、特にモバイルデバイスでは通信環境が不安定な場合も想定されるため、可能な限りキャッシュを有効に使いたいところです。また、この種の問題は JavaScript などを援用することで回避できる場合も多いのですが、スクリプトが記述できないスタイルシートや添付ファイル類に対しては個別に解決策を採る必要があります。確実に対策を施しておかないと PC 向けのコンテンツをスマートフォン向けのスタイルシートで表示してしまうなどのトラブルが発生しかねません。そして、そのようなトラブルが発生してもコンテンツ提供側では状況が把握できない可能性があります。
このあたりの動作のあり方について、もう少し方向性がはっきりとしてくるまでは、チャネルごとに異なる URL を与える方式でサイトを構築しておくのがよいのではないかと考えています。
WebRelease では、全チャネルでファイルおよびディレクトリ構成は同一となります。例えば index.html は、プライマリチャネル用にひとつ生成され配信される以外に、増設されている他のチャネルに対しても、それぞれのチャネル用の index.html が生成され配信されます。どのような index.html を生成して配信するかはテンプレートの展開とメソッドによって決まりますが、全チャネルについて index.html は必ず配信されます。
イメージ、添付ファイル、サブディレクトリなどについても、全チャネルに対して同一のものが配信されます。現状では、これらがチャネル間で共有されることはありません。イメージや添付ファイルを参照する URL は短い方がよいのですが、チャネル間で共有しようとすると URL が長くなる場合が多いため、共有は行われていません。
全チャネルで同じコンテンツ構成を採用していることによるメリットは例えば下記のとおりです。
- スマートフォンで検索して見つけたコンテンツについて「後で PC やタブレットでゆっくり読みたい」と考えることがあります。それができるためには、スマートフォンで見つけたページに対応する PC やタブレットデバイス用のページが存在することが必要です。このような、いわゆるクロスデバイスの利用環境を提供するためには、コンテンツ構成は同じになっている必要があります。
- 最近利用が活発になっている SNS ですが、知人に教えてもらったページの URL は、その知人が使っていたデバイスに依存しているかもしれません。その知人がタブレットデバイスを使っていたならばタブレットデバイス用のコンテンツの URL を教えてくれることでしょう。一方、自分は、そのコンテンツをスマートフォンで見たいと思うかもしれません。そのような場合にも、対応するスマートフォン用のコンテンツがあれば便利です。
- コンテンツの公開には「承認」が必要な場合があります。WebRelease にも承認ワークフローをサポートする機能があります。承認関連の業務を効率的に行うことは、サイトの運営において大変重要です。チャネルごとにコンテンツ構成が異なると、承認依頼や承認実行を、チャネルごとに行わなければなりません。全チャネルのコンテンツ構成を統一し、その承認処理を全チャネル横並びで行えるようにしておけば、承認処理の効率低下が防げます。ワンソースマルチユースを考えるならば、こういったワークフローもワンソースでなければなりません。
WebRelease では、全チャネルの制御は一律に並行して行われます。システム全体が正常に運用されている限り、つまり、トラブルなどで特定のチャネルに対してコンテンツの配信ができないなどの問題が生じている場合を除いて、全チャネルが同じリビジョンのコンテンツを公開している状態を保つべく動作します。換言すると、特定のチャネルを指定してコンテンツを配信したり、削除したりする機能はありません。
全チャネルを一律に制御することで、チャネル数に関わらず、一定のオペレーションコストでサイトが運用できるようになります。チャネルごとのオペレーションを行う前提でサイトの運用を行うと、そのオペレーションコストはチャネル数に依存して増えてしまいます。安定に稼働するサーバ（WebRelease サーバと公開サーバ）と正しく作成されたテンプレートを使えば、マルチデバイスへの複数コンテンツ配信は小さなオペレーションコストで実現することができるはずです。
チャネルの種類
チャネルには、以下の3つの種類があります。
プライマリチャネル
プライマリチャネルは、サイトが作成されたときに必ずひとつ作られます。デフォルトでは main という名前になっています。この名称は変更することができます。
プライマリチャネルは削除はできません。また、プライマリチャネルは追加して作成することもできません。サイトは必ずひとつのプライマリチャネルを持っているということになります。追加作成できるのは、後述の「サブディレクトリ型チャネル」か「リモートサーバ型チャネル」のいずれかです。
プライマリチャネルには、コンテンツ配信先となる FTP または SFTP サーバへの接続情報を指定します。このチャネル向けに生成されたコンテンツは、指定された FTP (SFTP) 先に配信されます。
プライマリチャネルは、デフォルトのコンテンツを保持しているチャネルでもあります。アクセスしてきたデバイスのタイプを判定した結果、プライマリチャネル以外の他のチャネルに適合しなかった場合、そのデバイスにはプライマリチャネルのコンテンツが提供されます。プライマリチャネル以外をデフォルトチャネルに指定する方法はありません。
プライマリチャネルは、チャネル一覧画面で常に一番上の行に表示されます。プライマリチャネル以外のチャネルは、2 行目以降にチャネル名順に表示されます。
サブディレクトリ型チャネル
マルチデバイス対応などのために作成する、追加チャネルです。このチャネル向けに生成されたコンテンツは、プライマリチャネルのサブディレクトリに配信されます。
このタイプのチャネルには、配信先として、プライマリチャネルの直下のサブディレクトリを指定します。ここで指定したサブディレクトリが、このチャネルに配信されるコンテンツのルートディレクトリとなります。
ひとつのプライマリチャネルに対して、サブディレクトリ型チャネルを複数個作ることができます。
- プライマリチャネルの URL が https://www.example.com/ であるとします。
- サブディレクトリ型チャネル（例えば） mobile を作成し、そのサブディレクトリに「m」を指定したとします。
- この場合、このサブディレクトリ型チャネルに配信されるコンテンツの URL は https://www.example.com/m/ になります。サブディレクトリ型チャネルの URL は、プライマリチャネルの URL と指定したサブディレクトリから自動的に決まります。
- https://www.example.com/about_us.html に対応する、チャネル mobile 用のコンテンツは https://www.example.com/m/about_us.html に配信されます。
- https://www.example.com/m/about_us.html の canonical URL は https://www.example.com/about_us.html であると言えます。
- https://www.example.com/m/ 以下のファイルおよびディレクトリ構成は https://www.example.com/ と同じとなります。ただし、https://www.example.com/m/m/ は生成されません。
サブディレクトリを指定するときには、プライマリチャネルに配信されるコンテンツが使用するディレクトリと衝突しないサブディレクトリを指定する必要があります。 サブディレクトリ名は 15 文字以下に制限されています。
リモートサーバ型チャネル
マルチデバイス対応などのために作成する、追加チャネルです。
特定のデバイス向けのコンテンツを、プライマリチャネルとは異なる、独立した FTP (SFTP) 先に配信したい場合に使用します。マルチデバイス対応の範囲で考えるならば、多くの場合、サブディレクトリ型チャネルで事足りると思いますが、このリモートサーバ型チャネルを使えば、完全に独立した他のサーバに対してコンテンツを配信することができます。
このタイプのチャネルに対しては、プライマリチャネルと同様に、配信先のFTP または SFTP サーバへのログイン情報を指定する必要があります。
リモートサーバ型チャネルは複数個作ることができます。
チャネルの作成
チャネルは「FTP 管理」画面の「チャネル」タブの画面右上にある「新規チャネル」ボタンをクリックすることで追加作成できます。
サブディレクトリ型チャネルの作成と設定
「新規チャネル」ボタンをクリックするとチャネル設定画面が表示されます。サブディレクトリ型チャネルを増設する場合には、下記の説明を参考にして設定を行ってください。設定を記入したら画面右上の「保存」ボタンをクリックして設定を保存します。
コンテンツ配信先
「サブディレクトリ」を指定します。
サブディレクトリ
このチャネル用のコンテンツを配信するサブディテクトリを指定します。このサブディテクトリは、プライマリチャネルが配信されるディレクトリの直下のディレクトリを指定します。
「チャネル名」「チャネル表示名」「タグ」「エンコーディング」については下記を参照してください。
関連項目
リモートサーバ型チャネルの作成と設定
「新規チャネル」ボタンをクリックするとチャネル設定画面が表示されます。リモートサーバ型チャネルを増設する場合には、下記の説明を参考にして設定を行ってください。設定を記入したら画面右上の「保存」ボタンをクリックして設定を保存します。
コンテンツ配信先
「リモートサーバ」を指定します。
その他の設定項目については下記を参照してください。
関連項目
チャネルの削除
チャネルは、チャネル設定画面で「削除」ボタンをクリックすることで削除することができます。
プライマリチャネルは削除できません。
チャネルを削除しても、そのチャネルに過去に配信されている公開サーバ上のコンテンツは削除されません。必要があれば手動で削除してください。