1. 何といっても管理が大変
2. 分散されて、一つ一つのボリュームが小さくなってしまう
3. 手を広げすぎてどれも中途半端になってしまう

２番３番は運営者（自分自身）の力量を見積り間違えた場合ですので、最初から欲張らずに、分相応の数に絞るか、とりあえず一つ一つ手を付けていけばいいわけですが、１番の管理の問題は大きいです。

これまでであれば、複数のサイトを一人で管理するなどちょっと考えられませんでした。２つや３つぐらいなら頑張ればできた範囲かもしれませんが、それ以上となると自分の首が絞まります。しかし、MovableTypeを手に入れた今、これも不可能ではなくなってきました。つまり、１番の問題も解決する可能性も出てきたわけです。MovableTypeは複数のコンテンツを管理するCMS（Contents Management System）であるともいえるわけですから。

しかし、MovableTypeも完璧ではないので、工夫も必要ですし、妥協も必要です（爆）

つまり、『なんちゃって複数サイト』もしくは『実質的な複数サイト』に止めることです。サイト毎にデザインやレイアウトを変えだすと、管理が破綻します。核となるデザインを決めたらどのサイトも基本は同じがいいです。欲張ってもせいぜい３パターンぐらいでしょう。まずは自分自身とこの契約（妥協）をしましょう（笑）

逆にいうと、核となるデザインは徹底的にこだわることをおすすめします。どんなサイトでも通用する万能なものがいいです。そのためには余計なものはなるべく削ぎ落としましょう。

また、テンプレートも工夫しなければなりません。『PHPで軽量化！』が終えているあなたであれば、既にノウハウは蓄積されているはずです。このノウハウを駆使して、これまでよりも、もう少し慎重に行動すれば複数サイトの運営は可能です。

何より最初が肝心です。後戻りできないことも多いですし、最初に苦労（工夫）しておけば、後々永続的に楽ができますからね。次回からは具体的な工夫をご紹介していきます（といっても焼き直しの部分も多いと思いますが）。

ここで、とりあえず、テンプレート･モジュールを導入することにしました。マニュアルの分割です。

工場内で、それぞれ部署を設け、各部で作ったものを組み立てて、完成した家一軒を出荷する、というやり方です。各部はそこで必要とされるマニュアルだけが配布されるので、（スッキリしたプログラムソースとなり）人為的なミスは減りました。しかし、出荷は相変わらず大変ですし（再構築時間に変化はありません）、工場スペースの節約にはなりません（ディスクスペースの節約にもつながりません）。

次に、A社はPHPモジュールという革新的な技術を知りました。工場で作るのはパーツで、それを運んで現地で組み立てる、いわゆる現地工法です。

これは革命です。これまでは道路のすいている深夜でしか運搬できませんでしたが、3トントラックあたりでも運べてしまうので、昼夜を問わずいつでも運べ、運行速度も上げられます（再構築時間が格段に早まります）。

家一軒を保管しておくよりもパーツで保管した方が工場スペースは有効に使えます（ディスクスペースの節約につながります）。PHPモジュールでもマニュアルはパーツごとに分割されていますので読みやすいです（シンプルなプログラムソースが実現できます）。しかし現地で組み立てますので、少しだけユーザーに負担をかけます（PHPプログラムを多用するかどうかによりますが、ブラウザの表示時間は長くなります）。引越しは数日待ってもらう必要があるでしょう。

そこで、味をしめたA社では、パーツの分割化を極限まで行なおうという提案がなされ、採択されました。しかし、問題が露呈してきます。組み立てにどんどん時間が掛かるようになってきたため、ユーザーからのクレームが遅かれ早かれ来そうです。また、部品化しすぎてマニュアルは簡便になりましたが部署が増えすぎて組織が複雑になってしまいました（増えすぎると今度はモジュール管理が大変になります）。

A社は分割のしすぎを反省し、無駄な（極端すぎる）分割をやめる方向に軌道修正しました。

こうして、A社は事業が軌道に乗ってきたため、アメリカにも工場を作ろうと計画します。アメリカでうまくいけば各国でも工場を作ろうと計画しています。しかし、そちらの工場でも同じような複雑な組織を作らないといけないことが、事業拡大のネックになっていることに気がつきました。すっきりした組織が求められているわけです。また、各国ごとにマニュアルを配布してしまうとメンテナンスに苦しむだろうと予期していました。

そこで、A社はもう一度、基礎に戻って、テンプレート･モジュールとPHPモジュールとをよく検討してみることにしました。

テンプレート・モジュールはマニュアルを分割するだけです。つまり、各国の工場に配布することができます。一方、PHPモジュールの場合はパーツまで一気に作ってしまいますので、MadeInUSAの文字とか、現地販売台数を特定できる連番などが刻まれています。つまり、パーツを本社一箇所においておくというのは、現地情報を含まないパーツに限られるわけです。

そこで、A社はテンプレート･モジュールを採用しなおし、マニュアルをインターネットで閲覧できるようにして、マニュアル管理だけでも楽をしようと計画しました。つまり、テンプレート･モジュールのファイルにリンクファイルを設定することです。

しかし、その時、現場の社員が声を上げました。
「テンプレート･モジュールのファイルにリンクファイルを設定するのを、PHPモジュールに応用できるのではないですか？」
よく考えれば簡単なことでした。インデックス・テンプレートにもアーカイブ・テンプレートにもリンクファイルの設定ができることに気がついたのです。これまで、何気なしにみていたリンクファイルの設定に一躍脚光が浴びせられたのです。

A社は『リンクファイルの有効活用』というプロジェクトを立ち上げることにしました。その報告は次回で。

リンクファイルとは、ヘルプを見ると、

テンプレートの内容を編集するとき、Movable Typeのウェブ・アプリケーション以外で編集した方が簡単な場合もよくあります。たとえば、コードがハイライトされるテキスト・エディタでHTMLを編集するのを好む人が多くいます。 Movable Typeのテンプレートを外部のファイルにリンクすると、Movable Typeにあるテンプレートのコピーをその外部のファイルと同期しながら、外部のアプリケーションでテンプレートを編集することができます。 同期プロセスは双方向に働きます。テンプレートを編集するとき、リンクされている外部のファイルが最新のファイルがどうかチェックされます。Movable Typeでテンプレートを保存するときは、変更に応じて外部のリンクされているファイルも更新されます。 リンクされているファイル名の値は、外部ファイルまでのファイルシステムへのフル・パス、あるいはウェブログの ローカル・サイト・パス に対しての相対パスのどちらかにしてください。

つまり、一個のファイル（プログラムソース）をそれぞれのサイトで共用できるわけです。これで『部品はそれぞれで作るがプログラムソースは同じ』ということが可能になりました。早速『SyndicatePowered.inc』に関して行なってみましたが、全く問題ありません。これで、現地情報を含んだ部品も、マニュアルの一本化を図りながら部品化によるメリット（ディスク容量の節約、再構築の負荷軽減）が行なえるようになりました。

やり方は、『このテンプレートにリンクするファイル』の部分に絶対パスを入れ、それぞれのブログでも同じパスを参照させるだけです。拡張子は何でも構いませんが区別しやすいように私は『inm』としてみました。注意点は保存すると同期しますので、横着して中身が空のままパスだけ設定して保存しないことです。（追記参照）

これで色々なことができそうです。とりあえず今回はここまで。

【2005/6/23追記】
上で中身が空のままパスだけ設定して保存すると中身が消えると記述していますが、確認しましたところ、完全に空であれば、既存のソースがそのまま保存されます。つまり、複数サイトの追加時は、テンプレート名、出力ファイル名とリンクファイルのパスだけペーストすればよく、中身までペーストする必要はないわけです。完全な空ではなく、スペースが一つでも入っていると、既存のソースは消えてしまいますが。

【2005/8/27追記】
例えば『テンプレート』のうち『インデックス・テンプレート』の場合、通常『出力ファイル名』を指定しますよね。これは、index.htmlだったり、index.phpだったり、インクルードすべきファイル名（Head.incとか）だったりします。
ところが『このテンプレートにリンクするファイル』というフォームは空にしている場合が多いと思います。これは一体「なんだろう？」と多少気になりながらも気にしないことにしていた人が大半ではないでしょうか？
これが、本題のリンクファイルの設定です。例えば、
/home/sites/lolipop.jp/users/lolipop.jp-dp********/web/inc/head.inm
というようにフルパスでリンクファイルの保存場所を指定してあげると、複数サイトを管理している場合に、他のブログでも出力先がHead.incファイル（こちらはそれぞれのサイトのホームディレクトリにそれぞれHead.incを置くようにする）のプログラムソース（テンプレートという表現の方が分かりやすいかもしれません）として、上記保存先を共通にすればいいわけです（すなわち、別のブログでもリンクファイルの設定を上記アドレスにする）。

少しは分かりやすくなりましたでしょうか？

前置きが長くなりましたが、説明します。私も一気に上りきったばかりなので、かなりハイテンションです。ご容赦下さい。

まずはバックアップを取ってください。フルバックアップです。という自分は昨日したばかりだったのでやってませんが（爆）

複数サイト共通のパーツで投稿時に動かないもの
例：スタイルシート

全くパーツが同じであるならば、メインサイトで管理しておけばいいです。他のサイトは作成された構築物を読み込みに行けばいいです。他のサイトからの読み込み方法ですが、スタイルシートでなければ絶対パスでPHPモジュール、スタイルシートはURL指定をするだけです。

複数サイト共通のソースで投稿毎に動かないもの
例：バナー、フッター、Powerd部分、head部分の一部等

ソースは共通ですが、属地情報を持ちます。つまり、サイトのタイトルが入ったり、サイトのホームへのリンクが貼られていたり、サイトのアクセス解析ページへのリンクが貼られていたりしますので、構築物は一致しません。

こうしたものにおすすめの方法は、インデックステンプレートとして作成し、リンクファイルを設定します。リンクファイルのパスはメインサイトの直下に『inc』フォルダでも作成してその中に入れたらいいでしょう。拡張子は何でもいいですが、私は『inm』にしました。投稿時に動きませんので、再構築オプションを外しておいていいです。

複数サイト共通のソースで投稿毎に動くもの
例：Link部分（総投稿数を表示する場合）、カテゴリー一覧（カテゴリー毎の投稿数を表示する場合やカテゴリーを頻繁に増やす可能性がある場合）

この場合は、基本的に上の『複数サイト共通のソースで投稿毎に動かないもの』と同じやり方ですが、再構築オプションは入れておきます。

ソースは複数サイト共通だが、インデックスだけのもので投稿時に動くもの
例：新着情報リンク、新着コメントリンク、新着TBリンク、更新情報やプロフィールを頻繁に変える場合等

正直言って、コメントとTBはしてもらった経験が皆無なのでよく分かりません（爆）

これらは、部品化しても無意味なのでテンプレートモジュールの方がいいです。ソースは共通なのでリンクファイルを設定した方がいいです。リンクファイルのパスは先ほどの『inc』フォルダでいいでしょう。拡張子は何でもいいですが、さっきのと区別するため私は『itm』にしました。

ソースは複数サイト共通だが、月別やカテゴリー別だけのもので投稿時に動くもの
例：カテゴリー別の記事リンク一覧、月別の記事一覧等

これらも、部品化する意味は無いです。各月毎に一個あればいいだけで、個別からはインクルード（readfile）しないわけですから。

おすすめは、やはり上の『ソースは複数サイト共通だが、インデックスだけのもので投稿時に動くもの』と同じです。

ソースは複数サイト共通で、各アーカイブで利用される個別のもの
例：本文、追記、記事タイトル、コメント、トラックバック等

これらは個々に格納しておくと良いと思われるものです。複数のアーカイブで再利用されるでしょう。

おすすめの方法は、PHPモジュール（アーカイブ版）です。やり方は『PHPで軽量化！』のところに記載しましたので参照してください。なお、ソースを共有しますので、リンクファイルを設定します。リンクファイルのパスは先ほどの『inc』フォルダでいいでしょう。拡張子は何でもいいですが、さっきのと区別するため私は『ina』にしました。

ソースは複数サイト共通で、個別で利用されるカテゴリー別（月別）のもの
例：個別エントリーが属するカテゴリーの記事リンク一覧

先ほどの『ソースは複数サイト共通だが、月別やカテゴリー別だけのもので投稿時に動くもの』と違うのは個別で利用されるという点です。個別で利用されるのであれば部品化する意味はあります。

やりかたは、やはりPHPモジュール（アーカイブ版）です。上を参照してください。

以上です。

これらをすることで、管理するファイル数は非常に少なくなります。また、インデックス（メインページ）やカテゴリーアーカイブ、個別アーカイブ、月別アーカイブもリンクファイルを設定可能です。これで、複数サイトの管理もばっちりでしょう。

留意点

リンクファイルを設定するということは、ファイルがお互いに同期しますので、間違えると取り返しがつきません。複数サイトを運営していると、ひとつ間違えてももうひとつのところからソースをコピーできたりしますので、バックアップをとらなくてもリカバリできますが、同期を取ってしまうと、リカバリは文字通りバックアップファイルからのみとなります。

カット＆ペーストしていいものなのかどうか、よく考えてください。同じソースだと思っていても、微妙に異なる場合があるものですよ。繰り返しで恐縮ですが、慎重に行なってください。また、一気にやらないと忘れてしまいますよ。やり方を忘れてもこのサイトを見にこればいいだけですが、ソースが共通だったかどうか、ディレクトリ構造及びファイル構成がどうなっていたか、そもそもどこまで作業をしていたのか、そうしたことはちんたらやっていると忘れてしまうものです。

それでは、幸運を祈ります。

なお、タブ作成の部分ですが、私は下記のようにしています。

<div id="nav"> <ul> <MTBlogs> <li><a href="<$MTBlogURL$>" onMouseOut="msg.innerHTML=''" onMouseOver="msg.innerHTML='<$MTBlogDescription$>'"> <$MTBlogName$></a></li> </MTBlogs> </ul> </div>

テンプレートの名前：003banner

出力ファイル名：banner.inc

このテンプレートにリンクするファイル：
/home/sites/lolipop.jp/****/***********/***/***/banner.inm

再構築オプション：しない

テンプレートの中身：
<a name="top"></a>/***アンカーの設置***/

<div id="banner">/***バナー領域の定義開始***/
<a href="<$MTBlogURL$>" accesskey="1"><$MTBlogName$></a>/***バナー部分***/
</div>/***バナー領域の定義終了***/

<div id="bannerR">/***バナーR領域の定義開始***/
<form method="get" action="<$MTCGIPath$><$MTSearchScript$>">/***フォームの設置開始***/
<input type="hidden" name="IncludeBlogs" value="<$MTBlogID$>" />
<<input id="search" name="search" size="15" tabindex="1" value="" />
<input type="submit" value="検索" tabindex="2" accesskey="0" />
</FORM>/***フォームの設置完了***/

</div>/***バナーR領域の定義完了***/

<div id="nav">/***nav（ナビゲーション）領域の定義開始***/
<ul>/***リスト構造定義開始***/
<MTBlogs> /***全ブログ対象ループ処理開始***/
<li><a href="<$MTBlogURL$>" onMouseOut="msg.innerHTML=''" onMouseOver="msg.innerHTML='<$MTBlogDescription$>'" title="<$MTBlogName$>">
<$MTBlogName trimj_to="22"$>
</a></li>
</MTBlogs>/***全ブログ対象ループ処理終端***/
</ul>/***リスト構造定義完了***/
</div>/***nav（ナビゲーション）領域の定義完了***/

<div id="msgbox">/***msgbox（概要等表示エリア）領域定義開始***/
<span ID="msg" style="font-size: 9pt"></span>
</div>/***msgbox（概要等表示エリア）領域定義終了***/

久々のMTコンテンツなので復習をかねてソースを出してみました。上の『全ブログ対象ループ処理』の部分で、MTが管理しているブログを対象にしています。削除したブログは当然引っかかってきませんが、再構築オプションを外していますので、手動でもう一度プログラムを回しなおしてあげる必要があったわけです。

最後の後始末としては、独自ドメインの場合、サブドメインを取得していると思いますので、それを削除します。ロリポップの場合は『サブドメイン設定』画面で削除します。