生成部分が定着する前に

AI生成のテクスチャーは、提供元の開示ページを誰も開かないうちに、オートメーション・レーンを持つことがある。そこを軸にコーラスを組み立てると、サウンドを差し替えるためにベースやボーカルのフレージングまで見直すことになりかねない。ソフトウェアに関する疑問に、アレンジメントまで結びつくことになる。

MusicRadarによる9月19日の「倫理的なAI」音楽ツールをめぐる論考は、責任と透明性を語る企業を、ミュージシャンがどう見極められるのかを問いかけている。実際的な対応は、使える出力を手放しにくくなる前に、そうした約束を具体的な質問へと置き換えることだ。

ある提供元は学習データの出所を詳しく説明する一方で、アップロードしたファイルがどう扱われるかについてはほとんど語らないかもしれない。別の提供元はファイルの扱いを明確に管理できても、報酬モデルを曖昧なままにしているかもしれない。それぞれの主張には、それぞれの証拠が必要だ。最初の確認は試作用のプロジェクトで行い、作品本来のボーカルは専用のフォルダーに残しておく。

まず目的を明確にする

まずは、作業内容を一文で説明することから始める。ノイズの多い録音を修復するのか、コード進行を提案させるのか、それとも完成した伴奏パートを生成するのか。作業内容によってツールに渡す素材が変わり、アレンジメント内に生じる依存関係も異なる。自分で弾き直すコードの提案と、残すつもりで生成する演奏では、必要となる制作上の判断が違う。

次に、実際の処理経路を確認する。アプリケーションはファイルを手元のマシンで処理するのか、リモートサービスへ送るのか、それとも両方を組み合わせるのか。判断できない場合は、未解決の疑問として記録しておく。DAW内に表示されるプラグイン画面だけでは、計算処理がどこで行われるかは分からない。

チームとして許容できる範囲についても合意しておく。あるコラボレーターはオーディオの修復には抵抗がなくても、生成された演奏を残すことには同意しないかもしれない。その境界線を作業内容の横に書き留めておけば、試聴がうまくいったからといって、知らないうちに依頼の範囲が広がるのを防げる。

初回のテストは、評価できる程度に範囲を絞ります。たとえば、評価用に作成した素材だけを使い、ラフなアレンジ向けに8小節のパーカッション案を求めることができます。これで、未完成のレコードを実験に持ち込まずに、入力と出力を追跡できる明確なタスクが定まります。

調達に関する主張を追跡する

トレーニングの側面については、検討中の製品やモデルに結び付いた開示を探します。企業全体のミッションステートメントでは、現在使うツールについて十分に説明されていない可能性があります。役立つ情報には、関わった素材の種類が示され、それらを企業がどのように入手したかが説明されています。

対象範囲を注意深く読みます。提供元が参加したミュージシャンやデータパートナーを挙げている場合は、その関与がシステムのどの部分に及ぶのかを確認します。説明が、記載されたトレーニングソースのすべてを対象としているのか、それとも一部だけなのかを記録します。境界が明確でない場合は、その不確実性を見える形で残します。

報酬が選択の基準になる場合は、誰が支払いを受け、取り決めがどのように機能するのかを説明した情報を探します。個々のアーティストの契約内容まで期待せずに、仕組みについて尋ねることはできます。

外部評価があり、その委任範囲が明確であれば、追加の根拠になります。実施日、調査対象となったバージョン、誰が委託したのかを確認します。ファイルの取り扱いに関する調査と、トレーニングソースに関する調査では、答えられる問いが異なります。主要な結論とともに対象範囲も保存します。

自分のファイルを追跡する

今日のセッション中にサービスへ入力する素材については、元のモデルに関する詳細な説明が提供元から公開されている場合でも、別途確認すべき事項があります。

自身のアカウントとプランに該当する説明を確認する。処理後に何が保持されるのか、またアップロードしたデータが開発目的で再利用される可能性があるのかを尋ねる。自分で操作できる管理項目を確認する。削除が可能とされている場合は、提供元が示す対象範囲と所要時間を読む。その説明の記載日入りのコピーを保管する。

共同作業では、誰かが先に進むボタンをクリックする前に、アップロードを承認できる人を決めておく。エンジニアはツールを操作する準備ができていても、アーティストは分離したボーカルを送信することに疑問を持っているかもしれない。そうした疑問をセッションノートに記録できるようにしておく。

この点が未解決の間は、評価用に意図的に作成したテスト録音を使う。自分で数小節を演奏して録音すれば、他人の未完成の演奏をテスト素材にすることなく、インターフェースを試せる。

証拠台帳を作成する

短いプロジェクトメモがあれば、安心させるような一言が、いつの間にか事実として定着するのを防げる。重要な主張ごとに、次の4項目を使う。

  • 主張: 提供元はこの製品について、具体的に何と説明しているか。
  • 証拠: その説明はどこにあり、どのバージョンまたはプランを対象としているか。
  • 空白: 何が不明確なまま、または未検証のまま残っているか。
  • 判断: この特定の用途にはそれで十分か、そして誰が同意したか。

日付とリンクを追加する。提供元の説明と、独立して調査した事実との違いを保つ。企業があるプロセスについて説明していることは正確に記録できるが、そのプロセスを自分で調査したと主張してはならない。

対象範囲を「具体的」「部分的」「未回答」のいずれかで示す。具体的な説明であっても、確認する手段のない主張が含まれていることがある。その制限をメモに残す。

昨年のモデルについて詳細な開示を行っており、同じインターフェースで新しいバージョンも利用できる仮想の企業を考えてみましょう。既存の文書からは、記録すべき主張が得られます。それが新しいモデルにも当てはまるかどうかは、提供元に確認すべき別の問題です。そのバージョンに関する正確な質問を、フォローアップメールに記載しましょう。

ミックスに戻す

開示内容の確認を終えても、音楽的な疑問は残ります。出力を文脈の中で捉えましょう。修復ツールの場合は、処理後の音声とバイパスした音声を、知覚上同程度の音量で比較します。生成素材の場合は、試行ごとに作業内容を統一し、その後に何を編集したかを記録します。ドラムのアタックやフレーズの終わり際に何が起きているかも含め、解決したかった問題に耳を傾けましょう。

聴感上の結果は、証拠台帳の隣に残しておきます。ツールの音が非常に優れていても、出典に関する疑問が解消されないことがあります。明確な文書があっても、音楽的には役に立たない結果になる余地は十分に残ります。結論はそれぞれ別の行に記録しましょう。

関係するコラボレーターとともに、想定する用途について暫定的な判断を書き留めます。サービスのバージョンや作業内容が変わった場合は、判断を見直しましょう。試しに行った実験から導かれるチームの判断は、依頼を受けたボーカルセッションの場合とは異なることがあります。

最終的なバウンスの前に、記録をもう一度開きます。どのツールがそのパートを提供したのか、それを採用する根拠となった情報は何か、そしてどの疑問が未解決のまま残っているのかを、全員が確認できる状態にしておきます。その記録を、レンダリング済みの音声とともにプロジェクトフォルダーへ入れましょう。