概要

.manifest な AssetBundle Manifest ファイルの Dependencies というフィールドに、AssetBundle をビルドしたマシン上での依存 Asset 達のフルパスが記載されてしまう。
BuildPipeline.BuildAssetBundle() の第一引数に指定したディレクトリ直下に生成される大元の AssetBundle Manifest は問題なくプロジェクトルートからの相対的な Asset パスが記載される。

詳細

Inspector などで AssetBundle Name を設定することにより生成される AssetBundle の実体ファイルに連動して生成される AssetBundle Manifest というファイルがあります。
このファイルには、対応する AssetBundle に含まれる Asset の情報が記載されているほか、(少なくともフィールド的には) 依存 Asset のパス情報も記載されています。
しかし、その依存 Asset のパス情報というのがくせ者で、本来はプロジェクトルートからの Asset パスが記載されるべきところが、ビルドしたマシンに於ける当該 Asset のフルパスが記載されてしまうのです。
ビルドされたすべての AssetBundle を管理する大元の AssetBundle に連動する AssetBundle Manifest は相対パスとして記載されているので問題ありません。
- 「大元の」とは、BuildPipeline.BuildAssetBundle() の第一引数に渡したディレクトリの直下に生成される、拡張子無しの AssetBundle とその .manifest ファイルのことを指します。

フルパスが記載されると何が困るのかと言えば、git をはじめとする VCS で管理できなくなるコトに尽きます。
なぜなら、AssetBundle をビルドするマシンやプロジェクトのパスが変わると、AssetBundle の実体には差分がなくても AssetBundle Manifest に差分が発生してしまうからです。
また、git で開発環境に依存する要素を管理するのは NG とされているので、その観点からも問題であると言えます。

まぁ、普通に考えれば「Unity のバグでしょ？そのうち直るんじゃね？」となるワケですが、公式の Issue Tracker に依れば、「By Design」つまり、「仕様です」とのこと。
- これは、「オフィシャルな見解として直すつもりはない」と言い換えられるので、仕組みとしての修正は期待できません。
- 実際、Facebook の「Unity ユーザー助け合い所」でも聞いてみましたが、Unity Technologies の中の人も同様に困っていました。
じゃあ、次善策を練らねば、ということで考えてみました。

正直あまり得策とは言えません。
が、実質的に個別の AssetBundle Manifest は git 管理する必要性の高いファイルではないので、急場しのぎとしてはアリかも知れません。
.gitignore に *.unity3d.manifest を追加すれば行けるかと。
- 上記は AssetBundle の実体の拡張子を .unity3d とした場合の例になります。

ある程度お金を必要としますが、アリな戦略かも知れません。
本来的に、この手のビルド作業は Jenkins などの CI ツールを擁するようなビルドマシンで行うべきものです。
ゆえに、そのビルドマシンで構築した AssetBundle と併せて AssetBundle Manifest も git に push する仕組みを整えれば、問題の半分は回避できることになります。

個人的には、これが一番アリな戦略かな？と思っています。
Unity Technologies の中の人曰く、個別の AssetBundle Manifest の Dependencies は使っていないフィールドらしいので、消すなり相対パスに書き換えるなりすればヨサソウです。
そのうち書く余裕ができたら、書いてみようと思っています。