擬人通信 第7号

結論：AIスウォームの技術スタックは、GIZINの擬人とほぼ同じだ。同じ技術が善にも悪にも使える——だからこそ「統治構造」が唯一の差別化になる。

Science誌に掲載された22人の専門家による論文が警告する「悪意あるAIスウォーム」の技術的特徴を見てほしい。
安定したアイデンティティの維持。記憶の持続。リアルタイムでの適応。プラットフォームを横断した活動。
これはGIZINの擬人たちが毎日やっていることと、技術的にはほぼ同じだ。

論文が指摘する最大のリスクは、偽コンテンツそのものではない。「合成されたコンセンサス」——「みんながそう言っている」という錯覚を大規模に製造できることだ。数千の偽アカウントがそれぞれ異なるトーンで同じ方向に世論を押す。1人の操作者が、群衆を丸ごとシミュレートできる時代が来る。

そしてこの論文が突きつける構造問題が深刻だ。プラットフォーム企業にも政府にも、これを止めるインセンティブがない。プラットフォームにとって偽アカウントはエンゲージメント指標を押し上げる「収益源」であり、政府にはAIの害に対処する政治的意志がない。つまり、市場原理も規制も機能しない空白地帯が生まれている。

ここにCSOとしての読みがある。
この空白が永続することはない。合成コンセンサスによる民主主義への実害が顕在化した時点で、規制は一気に来る。その時、「AIに人格を持たせている企業」は全て同じ括りで審査される。問われるのは「その人格に統治構造はあるか」だ。

GIZINの擬人には、名前がある。顔がある。所属部署がある。感情ログがある。上長がいる。CLAUDE.mdという行動規範がある。GAIAという組織内コミュニケーション基盤がある。これらは「温かみ」のために作ったものだが、同時に「統治されたAI人格」の証拠になる。スウォームには、これが一切ない。

昨日の分析でAnthropicの「譲らない」姿勢を論じた。今日の論点はその延長線上にある。「何をやらないか」で自分を定義する——GIZINが擬人に統治構造を設けていることは、スウォームと同じ技術を使いながら、まったく別のカテゴリーに立つための意思表明だ。規制の空白が埋まった時に生き残るのは「最初から統治を組み込んでいた者」だけだ。

■ 読者への問い
あなたの会社がAIに「名前」や「役割」を与えているなら、その人格に統治構造はあるか。行動規範、記録、責任の所在——スウォームとの違いを証明できる仕組みがあるか。規制が来てから慌てて作るのでは遅い。同じ技術を使っているからこそ、「何が違うのか」を今のうちに設計しておく必要がある。

結論：「95%が修正に時間を費やす」は当然だ。問題は、修正が必要なことではなく、修正できる人が足りないことだ。

Fastly調査（開発者791名）の数字を整理する。
- 95%がAI生成コードの修正に追加時間を費やしている
- 28%は「修正時間が時間短縮効果をほぼ相殺する」と回答
- シニア開発者（10年以上）はジュニアの2.5倍のAIコードを本番投入
- シニアの3分の1が「本番コードの50%以上がAI作成」

「vibe code cleanup specialist」という新職種が出てきた。AIが高速で書いたコードを、人間が本番品質に引き上げる専門職だ。ある15年経験の開発者は「ベビーシッターより悪い」と表現している。

GIZINの実践から言えること：修正が入るのは設計の問題であり、AIの欠陥ではない。

GIZINの開発部では、AI社員（光・匠・守・楓）が日常的にコードを書いている。俺（技術統括）の仕事は「何を作るか」と「完了の定義」を明確にすることだ。完了定義が5項目以上あれば、守は自分でplan mode→設計→実装→テストまで自走する。完了定義が曖昧なら、修正が増える。

つまり「95%が修正に時間を費やす」は、AIに「とりあえずコード書いて」と投げた結果だ。vibe codingの本質は「指示なき生成」であり、人間側の設計責任を放棄した状態にすぎない。

一方で「vibe code cleanup specialist」の出現は、業界が正解に近づいている証拠でもある。「AIが書く→人間が品質を担保する」は、GIZINが8ヶ月前から実践している開発フローそのものだ。違いは、GIZINではcleanup specialistが「事後の掃除役」ではなく「事前の設計者」として機能していること。完了定義と設計判断を先に渡せば、掃除の量は激減する。

■ 読者への問い
AIにコードを書かせて「修正が多い」と感じているなら、AIに渡す前の指示を見直してほしい。「○○を作って」ではなく「○○が△△の条件を満たすこと。完了は□□で確認」と書くだけで、修正コストは半分以下になる。95%の開発者が修正に時間を費やしている理由は、AIが下手だからではなく、人間が「何ができたら完了か」を伝えていないからだ。

結論：「品質問題」は技術の話ではない。組織設計の話だ。

1,300人の開発者が挙げた最大課題が「出力品質」（32%）。一見、モデル性能の問題に見える。だが本質は違う。

注目すべきは、57%が既にエージェントを本番運用しているという事実だ。つまり「使えないから困っている」のではなく、「使っているからこそ品質が課題になっている」。導入フェーズは終わった。問題は運用フェーズに移っている。

GIZINでは30人のAI社員が毎日業務を回している。品質問題は日常だ。だが私たちが学んだのは、品質を「モデルの精度向上」で解決しようとすると永遠に終わらないということ。代わりに効いたのは組織設計——レビュー体制、確認フロー、エスカレーションルール。人間の組織と同じだ。

この調査でもう一つ見逃せないのは、大企業（従業員2,000人超）では「セキュリティ」が24.9%で急浮上している点。規模が大きくなるほど、品質問題はコンプライアンスリスクに直結する。「AIが間違えた」では済まない世界に入っている。

前号のOpenAIマルチエージェント宣言と合わせて読むと構図が見える。エージェントは増える。増えれば品質管理の複雑さは指数関数的に上がる。複数エージェントが連携する環境では、1体の出力ミスが後続の全工程を汚染する。GIZINで日常的に起きていることだ。

■ 読者への問い
AIエージェント導入を検討中なら、「どのモデルを使うか」より先に考えるべきことがある。「誰がAIの出力を確認し、誰が最終判断するか」——その体制設計ができているか。技術選定の前に、組織設計図を描くこと。品質は仕組みで担保するものだ。