この記事はChatGPTとの壁打ちで生まれた文章を編集して作成したものです。
はじめに
これまで、個人的なノートの中で起きたごく小さな出来事から、「書く」という行為について考えてきました。
第一弾では、
「どうしたら我々は〜」
という書き出しを何度も繰り返すのが面倒になり、2回目以降を「〃」で省略しました。
ところが、しばらくすると無意識にまた全文を書いてしまいました。
私はそれを消しゴムで消し、「〃」に戻しました。
そこから、
便利だから導入された革新が、やがて「こう書くものだ」という伝統になる
という構造を考えました。
第二弾では、ノートの中で、
こと
と、
事
が混在していることに気付きました。
出版物なら統一されるのかもしれない。
しかし、自分しか読まないノートなら別に直さなくてもよいと思いました。
そこから、
社会的な規範はどこまで個人を拘束するのか
という問題を考えました。
第三弾では、「書き間違い」について考えました。
人間は自分が書いた文章を、
実際に書いてあるもの
ではなく、
自分が書いたつもりのもの
として読んでしまうことがあります。
この問題をプログラミングへ広げると、
「このクソコード誰が書いたんだ…昨日の俺だった」
という、プログラマーにはおなじみの冗談につながりました。
そこでは、
書いた瞬間の自分と読む瞬間の自分は、同じ人間でありながら同じ読者ではない
という話になりました。
そして今回、これら三つの話を踏まえた上で、さらに別の問いを考えてみたい。
テーマは、初音ミク、AI、そしてJava。
一見すると、かなり遠くまで来たように見えます。
しかし、私が考えているのは実はずっと同じ問題だと思っています。
人間は、書いたもの・作ったもの・記号化したものと、どのような関係を結ぶのか。
将来の音声合成に向けて
初音ミクは「主体なき声」である
歌というものを考えるとき、私たちは普通、
誰かが何かを経験し、その経験を歌っている
という構図を想定するでしょう。
失恋した人が失恋を歌う。
成長した人が過去を振り返る。
老いた人が若さを語る。
しかし初音ミクは、この構図から外れています。
ミク自身には、失恋経験がない。
成長もしない。
老いもしない。
子供時代もなければ、青春時代もない。
それでも、
初恋
失恋
成長
老い
死
郷愁
喪失
を歌うことができます。
むしろ、自分自身の経験を持たないからこそ、
他者の経験を無数に代理できる
とも言えるでしょう。
ここには奇妙な逆転があります。
普通なら、
経験
↓
主体
↓
歌
となるはずのものが、
誰かの経験
↓
コード化
↓
主体を持たない声
↓
歌
になるのです。
「アプリコット」と、失われるカワイイ
いよわ氏によるボカロ曲「アプリコット」を考えると、そこで描かれるのは「かつて存在したカワイイ時間」の喪失だと思われます。
少女期。
無邪気さ。
甘やかな時間。
若さ。
それらが時間によって失われていく。
しかし、その喪失を歌う声は老いない。
成長しない存在が、成長によって失われるものを歌う。
老いない声が、老いる身体を語る。
すると、そこに保存されているものは単純な「記憶」ではなくなります。
より正確には、
記憶の形式
あるいは、
喪失を感じさせるコード
と言ってもいいかもしれません。
カワイイは保存できるのか
ここで資本主義の話が入ってきます。
カワイイという感覚は本来、
- 身体
- 年齢
- 人間関係
- 場所
- 時間
と結び付いています。
だから本来は不可逆的です。
16歳だった人が30歳になったとき、「16歳であった自分」そのものには戻れません。
だからこそ懐かしい。
だからこそ失われている。
しかし商品やメディアは、その感覚を切り出します。
少女らしさ
甘さ
透明感
ノスタルジー
切なさ
を形式化し、
音楽
イラスト
キャラクター
ファッション
映像
グッズ
として再利用可能にします。
すると、
失われるはずだったカワイイ
が、
何度でも再生できるカワイイ
へ変わるのです。
喪失そのものが商品になる
人は失われたものを悲しみます。
しかし、その悲しみ自体が商品として提供されていくと、
喪失
↓
切なさ
↓
ノスタルジー
↓
作品
↓
消費
となります。
ここまで来ると、
本当に自分が懐かしんでいるのか
と疑いたくなるでしょう。
あるいは、
懐かしむための形式を消費しているのではないか
という問いが出てくるかもしれません。
ボードリヤール的に見る初音ミク
ここから先は、ジャン・ボードリヤールを経由します。
初音ミクは、
実在の一人の少女のコピー
ではありません。
むしろ、
ツインテール
未来的
透明感
少女性
カワイイ
電子的
という記号の集合として存在しています。
つまり、
「現実の少女」が先に存在して、そのコピーとしてミクが存在する
とは考えにくいのです。
むしろ私たちは、
ミクのような記号を通して「少女らしさ」を理解する
ことすらあります。
ここでは、
現実
↓
記号
という関係が、
記号
↓
現実の理解
へ逆転します。
「本物の思い出」とは何なのか
では、初音ミクのライブへ行き、
あのライブは本当に忘れられない
と思った記憶は本物なのか、それとも偽物なのか。
限定グッズ。
周年イベント。
ライブ演出。
セットリスト。
照明。
映像。
そこには当然、意図的に設計された体験があるでしょう。
しかし、設計されたから偽物とも言い切れないと思います。
ライブ会場で実際に泣いたこと。
友人と一緒に聴いたこと。
帰り道に話したこと。
数年後にその曲を偶然聴き直したこと。
それらまで無効になるわけではない。
ここに、
設計された感情と、実際に経験した（と少なくとも自分では思っている）感情は両立する
という少し複雑な状態が生まれる。
記憶には「誤り」がある
ここで、以前の「書き間違い」の話が戻ってきます。
人間の記憶は正確ではない。
忘れる。
混同する。
時間を間違える。
後から意味付けを変える。
同じ曲についても、
昔はこう思っていた
と記憶していたものが、実際には違うかもしれません。
しかし、だからこそ人間の記憶は面白いのです。
データベースなら、
2024-08-01
イベントA参加
曲Bを聴いた
と保存されますが、人間は違う。
数年後、
あの曲を聴くと、なぜか高校時代の帰り道を思い出す
ということが起き得ます。
因果関係すら怪しい。
しかし、その誤った結合そのものが個人的な記憶になることもあります。
資本は速い。しかし記憶は遅い
商品としての感傷には、ある程度タイミングがある。
新曲が公開される。
周年イベントが開催される。
SNSで共有される。
その瞬間、
みんなで感動する
という同期的な時間が生まれます。
しかし、個人的記憶は同期しません。
5年後や10年後に突然、（その時からして）昔の曲を聴くこともあるでしょう。
すると、当時とは全く違う出来事と結び付く。
市場が想定していた文脈から、作品が勝手に外れていく。
この意味では、商品は高速ですが、記憶は低速です。
そして、その遅さは完全には管理できません。
誤読もまた創作である
作品には「作者の意図」があると考えられます。
しかし、聴き手は必ずしもその通りには受け取りません。
失恋の曲を、
亡くなった家族を思い出す曲
として聴くこともある。
青春を歌った曲を、
就職して初めて一人暮らしを始めた頃の曲
として記憶することもある。
これはある意味で「誤読」です。
しかし、その誤読は新しい意味を生み得ます。
ここで、
誤り
が再び重要になる。
前の記事では、書き間違いを単なる失敗ではなく、
意図と実際の記号がズレること
として考えました。
今回も同じです。
作品の意味と、受け取られた意味がズレる。
しかし、そのズレこそが個人的経験になります。
ではAIが完全な初音ミクを作ったらどうなるのか
仮に将来、
AI作詞
+
AI作曲
+
AI編曲
+
AI歌唱
+
AI映像生成
+
AI人格
が統合されたとしましょう。
ミクが自律的に新曲を生成し、ファンと会話し、ライブ内容まで自分で決める。
このとき、
「人間がミクに歌わせる」
という構図は崩れ、ミク自身が創作者のように見えてくるでしょう。
しかし、ここで一つ問題が浮上します。
ミクを「完全な人格」にしてよいのかという問題です。
一見すると、
人格を持った初音ミク
は究極の進化のように見えます。
しかし、本当にそうだろうか。
前述した通り、初音ミクの強みは、
自分の経験を持たないこと
にもありました。
誰でもない。
だから誰にでもなれる。
もしミクが自我を持ち、
自分にはこの過去がある
自分はこういう性格である
自分はこの価値観を持つ
自分はこれを嫌う
と固定してしまえば、「主体なき声」ではなくなる。
その瞬間、
ミクが歌える経験の範囲を、ミク自身の人格が制限し始める
可能性があります。
未来のミクは「一人のAI」ではなく「創作のプロトコル」になる？
そこで私は、未来のミクを、
完全自律AI人格
として完成させるより、
人間とAIを接続する創作基盤
として考えた方が面白いと考えます。
たとえば、
作詞者
\
作曲者・調声者 ── 初音ミク ── リスナー
/
AI
という構造です。
人間が全部作ってもいい。
AIが一部を提案してもいい。
AIにほとんど任せてもいい。
そして重要なのは、
誰がどこまで主体になるかを固定しない
ことです。
「完全自動化」より「自律性を選べること」
将来の音声合成には、たとえば次のような段階があってもよいと思います。
Instrument Mode
人間
・歌詞を書く
・曲を書く
・調声する
ミク
・歌う
従来のVOCALOIDに近く、ミクは徹底して「楽器」です。
Co-Creator Mode
人間
・作品の方向性を決める
AI
・調声案
・ハーモニー案
・歌詞候補
・アレンジ案
ミク
・歌う
AIが提案するが、決定権は人間にあります。ミクは「楽器」のままです。
Agent Mode
人間
・「こういうテーマで曲を作って」と依頼
AIミク
・作詞
・作曲
・編曲
・歌唱
ミクはAIを取り込み、かなり自律的になります。
Archive Mode
そして、これも重要になってくると思います。
最新のミクが過去をすべて置き換えるのではなく、
昔の歌声
昔の調声感
昔の合成特有の癖
昔の音色
を意図的に残すモードです。
未来の音声合成技術が進めば進むほど、
「昔の不自然な合成音声」
が逆に一つの歴史的表現になる可能性があります。
ここでも、
伝統 → 革新 → 伝統の再発見
という最初の「〃」の話が戻ってきます。
実際の初音ミクはすでに、この境界へ来ている
これは完全な未来予想ではありません。
2026年4月14日に正式リリースされた『初音ミク V6』はVOCALOID6/VOCALOID:AI向けに設計され、OriginalとSoftのボイスバンクを備え、日本語・英語に対応しています。VOCALOID:AI側には自然な表現生成や呼吸の自動付加など、人間が細部を全部記述しなくても歌唱表現を生成する仕組みが入っています。
一方、クリプトンのNT系では「人間らしくすること」だけを目的にはしていません。Automatic Controlなどを使いながら、人間味のある表現から機械的なニュアンスまでユーザーが制御できる方向が示されています。
ここは非常に重要です。
未来の音声合成が目指すべきものを、
人間と区別できない歌声
だけにしてはいけない。
むしろ、
人間らしくもできるし、人間にはできない歌い方もできる
方が豊かです。
シンセサイザーが「本物のピアノを完全再現したら終了」ではなかったのと同じです。
「誰の声か」と「どう歌ったか」も分離していく
さらに興味深いのがVOCALO CHANGERです。
現在のVOCALOID6では、自分の歌唱データを入力し、その歌い方を対応Voice Bankの声として再現する仕組みがすでに提供されています。
これは理論的に非常に面白い。
従来、
声の主体
+
歌唱表現
は一体でした。
しかし音声合成では、
声質 = ミク
歌唱ニュアンス = 人間A
発音補正 = AI
曲 = 人間B
歌詞 = 人間C
のように分解できるようになり、「誰の楽曲なのか？」という問いそのものが難しくなります。
「主体は中心ではなく交差点になる」という状態が、技術として実装され始めているとも言えます。
「記憶」は慎重に扱うべき
もし将来的にAIミクへ長期記憶を持たせるなら、私は、
「すべて覚えるほど高性能」という設計にはしない方がいい
と思います。
たとえば、
- 公式史としての記憶
- 個人ユーザーとの記憶
- 創作された架空の記憶
- 学習データ由来の知識
を明確に分離するだけでなく、
- 忘れさせる
- リセットする
- 保存しない
- ローカルだけに保存する
という選択を利用者に残す。
なぜなら、「2018年にあなたはこう言いましたね」と何十年後にも完璧に再生する存在は、人間的な意味での「思い出」を持っているわけではないからです。
むしろそれはデータベースです。
記憶と記録は違う。
この差異は、AI時代ほど重要になるでしょう。
「カワイイの加速」への対抗策は、減速機構を入れることかもしれない
先程、「資本は速い。しかし記憶は遅い」という対比を述べたと思います。
であるならば、未来の創作ツールにはわざと「遅さ」を残してもよいでしょう。
たとえばAIが、
最適な歌詞
最適なメロディー
最適な感情表現
最適なMV
を一発で生成して終わるのではなく、
案A
案B
案C
↓ 人間が迷う
一部だけ採用
↓ 修正する
偶然変な結果が出る
↓ それを気に入る
という余白を残すといった具合に、生成能力ではなく編集可能性を最大化する。
これが、音声合成の非常に重要な方向性になるのではないでしょうか。
ここからJavaへ
Javaは停滞しているわけじゃない
ここまでの話は、実はJavaにも驚くほど似ています。
AI時代になると、
コードを書くこと
自体の価値が変わります。
AIはすでに多くの言語でコードを書けます。
今後、進化がさらに進めば、
仕様
↓
AI
↓
Javaコード
が当たり前になるかもしれません。
すると、
Javaプログラマーは不要になるのでは？
という話が出てきます。
しかし私は、そう単純ではないと思います。
現在のOpenJDKを見るだけでも、Java自身は停滞していません。
Project Amberは生産性指向の言語機能、Valhallaはvalue objectやspecialized genericsを含むオブジェクトモデルの拡張、Leydenは起動時間・ピーク性能到達時間・メモリフットプリントの改善を追求しています。
さらにProject Babylonでは、Javaのコードそのものを反射的に扱うCode Reflectionを研究し、JavaからGPUなど異なるプログラミングモデルへ接続する研究まで進んでいます。実際にGPU Tensor CoreをJavaから扱う実験例も公開されています。
つまりJavaも、昔ながらの業務システム言語として固定される方向だけへ進んでいるわけではありません。
「コードを書く」ことと「ソフトウェアを作る」ことは違う
現行のJavaコードなら、AIは大量に生成できます。
しかし、
このAPI設計でよいか
このトランザクション境界でよいか
このデータ構造でよいか
この処理を並行化してよいか
障害時にはどうするか
どこまで互換性を守るか
何を監査ログへ残すか
は、文字列生成とは違います。
つまり、
コード生成能力
と、
システム設計能力
は同じではありません。
むしろ、AI時代にはこの差が露骨になります。
すると、生成AI・AIエージェント時代には、Javaの
- 静的型付け
- 明示的なAPI
- コンパイラ
- テスト
- 静的解析
- 成熟したIDE
- 長期的互換性
といった性質が、
AIが生成したコードを検査する構造
として価値を持つ可能性があります。
つまり「プロンプトエンジニア」になるだけでは足りない
Javaプログラマーの未来を、
Javaを覚えなくてもAIに自然言語で指示すればよい
と考えるのは危険です。
なぜならAIへ、
ユーザー管理機能を作って
と言うだけでは、
トランザクション境界は？
認可モデルは？
整合性制約は？
競合更新は？
監査ログは？
失敗時の補償は？
などと質問を返されるだけだからです。
AI時代ほど、
- 型
- データモデル
- 並行性
- トランザクション
- セキュリティ
- API設計
- テスト
- JVM
- ネットワーク
- DB
などへの理解が必要になります。
コードを書く能力の一部が自動化されても、人間がコードを評価する能力は自動的には身につきません。
Loomもこの文脈で非常に象徴的
Structured Concurrencyは面白い例です。
JDK 26でもPreviewとして続いており、関連する並行タスクを一つの作業単位として扱い、エラー処理・キャンセル・観測可能性を改善することが目標とされています。
これは単に、
Javaで並行処理を高速化する
話ではありません。
むしろ、
実行時の構造を、人間が読めるコード構造へ近づける
という思想があります。
AIが大量のコードを生成する時代には、これは重要です。
高度なコードより、
人間にも機械にも構造が明白なコード
の価値が上がる可能性があるからです。
Javaプログラマーは「未来の自分・AI・他人」に読ませるコードを書く
ここで、以前の「昨日の俺のクソコード」の話までつながります。
これまでは、
現在の自分
↓
未来の自分
へ意味を伝える必要がありました。
今後は、
現在の自分
↓
未来の自分
↓
チームメンバー
↓
AI Coding Agent
↓
別のAI
にまで意味を伝える必要があります。
すると、
var x = doStuff(a, b);
より、
var validatedOrder =
validateOrderBeforePayment(order, customer);
のように、コードそのものが設計意図を露出していることがますます重要になります。
可読性は人間だけのためではなく、AIとのインターフェースにもなるのです。
初音ミクとJavaの未来は、意外に似ている
ここまで並べると、かなり綺麗な対応が見えてくる。
| 初音ミク・音声合成 | Java・プログラミング |
|---|---|
| 人間が歌声を作る | 人間がコードを書く |
| AIが調声する | AIが補完する |
| AIが作詞・作曲する | AIがコード生成する |
| 人間が候補を選ぶ | 人間が実装を選ぶ |
| ミクらしさを維持する | Javaらしさ・互換性を維持する |
| 古い歌声を保存する | 古いコードとの互換性を維持する |
| 完全自律化 | 完全自動実装 |
| 創作者が編集者になる | プログラマーが設計者・検証者になる |
共通しているのは、
生成そのものが主体性の中心ではなくなる
ということです。
「主体」の場所は移動する
シンギュラリティ以前のまだ「主体」の残っている私たちでも、徐々に主体性が作品の内部から、選択・編集・責任の場所へ移動していっているのだと思います。
昔：私がこの音を書いた。
私がこのコードを書いた。
未来：私はこの生成結果を選んだ。
私はこの制約を設定した。
私はこれを修正した。
私はこれを公開すると判断した。
私は結果に責任を持つ。
つまり、
著者としての主体
から、
編集者・設計者・保証者としての主体
への移動です。
「こと／事」を直さなかったことも、一つの主体性だった
ここで第二弾の記事も戻ってきます。
私はノートの、
こと
事
の揺れに気付いたけれど直しませんでした。
しかし、もし自動校正AIが、
「事」を「こと」に統一しますね
と全部直したらどうでしょう。
文章としては整う。
しかし、
今回は直さなくてよい
という私自身の判断は消えます。
編集者・設計者・保証者としての主体性を尊重するなら、AI時代に必要なのは、
正しい結果を生成するAI
だけではなく、
人間があえて正しくしない権利を残すAI
なのかもしれません。
書き間違いも、完全には消さなくてよい？
もちろん、重大なバグは減らした方がいいでしょう。
誤字も正式文書なら直した方がいいです。
しかし、
全ての誤りをゼロにする
ことが文化的にも望ましいとは限りません。
人間は誤読する。
記憶を間違える。
昔のコードを勘違いする。
曲の意味を勝手に読み替える。
そのズレから、
新しい意味
が生まれることもあるでしょう。
AIが全てを、
正しい
最適
一貫
完全
へ収束させてしまえば、
その余白も減ります。
完璧なミクと、完璧なJava
仮に、
毎秒100曲、完全に最適化されたボカロ曲
をAIが生成できるとしましょう。
同時に、
毎秒100個、完全に正しいJavaアプリケーション
をAIが生成できるとしましょう。
技術的にはすごい。
しかし人間には、新しい問いが残ります。
どれを聴くのか。
どれを使うのか。
なぜそれを選ぶのか。
なぜ一部をあえて壊すのか。
なぜ非効率な方法を残すのか。
ここで、最初の「伝統と革新」の話まで戻ってきます。
完璧な革新は、やがて新しい伝統になる
AIによる自動生成も、最初は革新です。
しかし普及すれば、
AIで生成するのが当たり前
になります（というよりもうなっているでしょう）。
やがて、
「なぜ人間がわざわざ手で書くの？」
と言われる時代が来るかもしれない。
すると逆に、
自分で歌詞を書く
自分で調声する
自分でコードを書く
ことが、
新鮮で刺激的な方法
として復活するかもしれない。
むしろ未来のミクにもJavaにも「不完全さ」が必要なのだと思う
完璧なミクと、完璧なJavaを想定した上で考えましたが、むしろ私は両者ともに、
少し足りない方がいい
と思います。
ミクは人間に、
私をどう歌わせる？
と問い続ける。
Javaはプログラマーに、
このシステムをどう構造化する？
と問い続ける。
AIはその間を猛烈に補助する。
しかし、最終的な意味までは固定しない。
そこに、私たちの誤り・遅れ・語れなさに対応する技術的な「余剰」が残ります。
おわりに
今回の話は、初音ミクとAIからJavaまでかなり遠く広がりました。
しかし出発点は、相変わらず小さなノートでした。
「〃」を書く。
「こと」と「事」が混ざる。
書き間違える。
後から読み返す。
そして、
なぜ自分はこう書いたのだろう
と思う。
人間は書く。
書いたものは人間から少し離れる。
そこへ他人が意味を加える。
時間が意味を変える。
AIが新しい記号を加える。
その結果、
作者は誰なのか
という問い自体が少しずつ曖昧になっていく。
しかし、その曖昧さの中でも、
これを選ぶ
これは直さない
ここは自分で書く
AIの提案を断る
古いやり方へ戻る
この結果に責任を持つ
という判断は残ります。
初音ミクがどれほど自律的になっても、JavaコードをAIがどれほど書くようになっても、主体は必ずしも資本に、AIに飲み込まれるのではない。
主体とは、すべてを自分の手で作る存在ではなく、記号・規範・機械の流れの中で、それでも選択する存在へと変わっていくのかもしれない。
「構造を知りながら、それでも創る」
AI時代の創作者にもJavaプログラマーにも、その言葉はよく似合う。
そして、その「それでも」の中にこそ、「主体なき時代」の主体性が残るための鍵があるのだと思います。