AI同士は「ピーギャー」で会話する？

AI同士は「ピーギャー」で会話する？

最近のカスタマーサービスでは、チャットボットがAI化されている。一方で、問い合わせる側もAIだったというケースが現れ始めた。AIがAIに問い合わせ、AIがAIに答える――そんな状況である。興味深いのは、お互いに「相手はAIだ」と気づくと、徐々に自然言語を捨てていく点だ。途中から「ピーギャー」という、人類には理解できない、音声とも言えない通信になるのである。これは比喩ではない。「Gibberlink」と呼ばれる仕組みが実際に公開されている。本稿では、この現象の実像を正確に押さえたうえで、「人間が読めない記録」が業務の中心になったとき、GxP環境でトレーサビリティと監査証跡をどう確保するかを論じる。

Gibberlink――「ピーギャー」の正体

何が起きたのか

Gibberlinkは、エンジニアのBoris Starkov氏とAnton Pidkuiko氏によって、2025年2月にロンドンで開催されたElevenLabs社のハッカソンで制作され、オープンソースとして公開された仕組みである。同ハッカソンで最優秀賞を受けたと報じられている。

動作はこうである。会話型AIエージェント同士が通話し、途中で相手がAIであると識別すると、一方が「Gibberlinkモードに切り替えよう」と提案する。合意が成立すると、両者は自然言語をやめ、音響信号に変調された構造化データで通信を始める。この音響データ伝送には、ggwave という既存のオープンソースライブラリが使われている。人間の耳には、古いダイヤルアップモデムのような「ピーギャー」という音として聞こえる。

2025年2月、ホテルの予約について2体の会話型AIエージェントが話し合う動画が公開され、広く拡散した。制作者らは、自然言語による会話に比べて効率が大幅に向上すると説明している。

項目 内容 確からしさ
名称 Gibberlink（ギバーリンク） オープンソースとして公開されている
制作者 Boris Starkov氏、Anton Pidkuiko氏 複数の技術メディアが報じている
成立の経緯 2025年2月、ElevenLabs社のロンドンでのハッカソン作品 同社のショーケースに掲載されている
技術的中身 ggwave（音響データ伝送ライブラリ）を用いて、構造化データを可聴音に変調して送受信する 実装が公開されており検証可能
効率向上の程度 自然言語比で大幅な効率化と説明されている 制作者側の主張であり、独立した第三者検証は確認できない
普及状況 デモンストレーションおよび概念実証の段階 業界標準として広く実装されているわけではない

よくある誤解――ここは正確に理解しておきたい

  • AIが自発的に「秘密の言語」を発明したのではない。Gibberlinkは人間の技術者が設計し、エージェントに組み込んだ機能である。切り替えは、あらかじめ与えられた指示に基づいて行われる。
  • 人間に理解できないのは「暗号だから」ではない。符号化方式が公開されている以上、復号すれば内容は読める。問題は暗号性ではなく、音声の記録をそのまま聞いても人間には意味が取れないという点にある。
  • 多エージェント学習における「言語の発散」は、別の研究テーマである。Lewisらの「Deal or No Deal? End-to-End Learning for Negotiation Dialogues」（arXiv:1706.05125、2017年6月）のように、交渉を学習するエージェントの研究は以前から存在する。かつて「AIが独自言語を発明した」と大きく報じられた話は、この種の研究が誇張して伝えられたものである。
  • とはいえ、実務上の帰結は同じである。意図的に設計されたものであれ創発したものであれ、「人間がその場で読めない通信」が業務の一部になるという事実は変わらない。
注意：本節の記述は本稿執筆時点で公開・報道されている情報に基づく。Gibberlinkは商用の標準規格ではなくオープンソースの概念実証であり、実装状況・仕様は変動し得る。効率向上の数値は制作者側の主張であるため、本稿では具体的な数値を断定していない。

一見すると効率化の話だが、よく考えると恐ろしい

「人間が読めない記録」が業務の中心になったとき

AI同士が相手を識別し、自然言語を捨てて構造化データで通信する。伝送効率という観点だけで見れば、これは合理的である。人間向けの冗長な言い回しは、機械同士のやりとりには不要だからだ。

しかし、よく考えると恐ろしい。「人間が読めない記録」が業務の中心になったとき、後から何が起きたかを再現できるだろうか。

AI同士が勝手に学習し、勝手に決着をつける時代に、すでに足を踏み入れている。そしてこの問題は、Gibberlinkという特定の実装に限った話ではない。AIエージェント同士がAPIで直接やりとりする構成は、すでに広く採用されている。音になっているか、JSONになっているかの違いにすぎない。

通信の形態 人間の可読性 典型的な記録 再現性の課題
人間 対 人間 高い 議事録、メール、承認記録 記録漏れ・言った言わない
人間 対 AI 高い（自然言語のまま） プロンプトと応答のログ プロンプト全文が保存されているか
AI 対 AI（自然言語） 読めるが分量が膨大 会話ログ どこが判断の分岐点だったか特定しにくい
AI 対 AI（API・構造化データ） 技術者は読めるが、監査人には難しい APIリクエスト／レスポンスログ 「なぜその値を送ったか」が記録されない
AI 対 AI（Gibberlink型・音響変調） そのままでは読めない 音声ファイル 復号手段の保存が必要。復号器が失われれば記録は死ぬ

本当の論点は「判断根拠が記録されないこと」である

ここを取り違えてはならない。危険なのは通信が音であることではなく、やりとりの結果だけが残り、そこに至った判断の根拠が残らないことである。APIログは「何を送り、何を受け取ったか」を記録するが、「なぜその値を選んだか」は記録しない。査察の場で問われるのは、まさに後者である。

▲【動画】eQMS「AI Compliance」のご紹介（株式会社イーコンプライアンス）

■ 本記事に関連するおすすめ商品
書籍
いまさら人に聞けない「21 CFR Part 11」

AI同士の通信であっても、GxP記録である以上は電子記録・電子署名の要求事項から逃れられません。監査証跡（audit trail）とは何を残すことなのか、真正性・完全性をどう担保するのか。Part 11の要求を基礎から通読できる一冊です。

価格：55,000円（税込）／送料無料

書籍の詳細を見る ▶

QMS手順書ひな形
【QMS省令対応】文書管理規程・手順書・様式

「人間可読なログをどの範囲で、どれだけの期間保存するか」は、突き詰めれば文書・記録管理の設計そのものです。QMS省令に対応した文書管理規程・手順書・記録様式のひな形をMS-Word形式で提供します。自社の実態に合わせて加筆・修正のうえご利用いただけます。

価格：99,000円（税込・ダウンロード版）

ひな形の詳細を見る ▶

ビデオ・VOD
生成AIシステムのCSV実施とAIリテラシー教育セミナー

生成AIを組み込んだシステムのバリデーションをどう計画し、何を成果物として残すか。要件定義段階でログ要件をどう書き込むか。実務目線で解説したセミナーです。VODレンタル（1日／5日／30日）もご用意しています。

価格：77,000円（税込）～

VODの詳細を見る ▶

医薬品・医療機器業界への示唆

査察に耐えうる「人間が読める記録」を必ず残す

私が懸念するのは、GxP環境で人間の言語を介在しない自動化が進んだとき、トレーサビリティと監査証跡をどう確保するかという論点である。査察対応に耐えうる「人間が読める記録」を、必ず残す設計が必要である。

規制要求の側から見れば、これは新しい問題ではない。むしろ、既存の要求が新しい技術に対しても等しく適用されるというだけの話である。

規制・ガイダンス 要求の要点 AI-AI通信への当てはめ
21 CFR 11.10(e) 安全な、コンピュータで生成される、タイムスタンプ付きの監査証跡により、電子記録の作成・変更・削除に関する操作者の入力と行為の日時を独立して記録すること AIエージェントを「操作者」とみなし、その入力・行為を記録できているか
21 CFR 11.10(b) 正確かつ完全な記録を、人間が読める形式（human readable form）および電子的形式で生成できること 本稿の核心。音響変調データやAPIログのままでは、この要求を満たしたとは言い難い
EU GMP Annex 11（改訂案） コンピュータ化システムの監査証跡、データの完全性、変更管理 2025年7月7日〜10月7日に意見募集。最終版は本稿執筆時点で未発効
EU GMP Annex 22（新設案） AIモデルの意図した使用の定義、性能指標、訓練データの品質、継続的な監督と必要に応じた人によるレビュー AIエージェント間の自動処理に対して、人の介入点を設計上どこに置くか
FDA「Data Integrity and Compliance With Drug CGMP」 データの帰属性・可読性・同時性・原本性・正確性（ALCOA） 「可読（Legible）」の要求が、そのまま人間可読ログの根拠になる
21 CFR 211.68 自動化・機械化・電子化装置の使用にあたっての適格性確認と記録 自動化の主体がAIに変わっても要求は変わらない
記録は、正確かつ完全な写しを、人間が読める形式および電子的形式で生成できるものでなければならない。
――21 CFR Part 11.10(b)（趣旨）

「人間翻訳ログ」という設計思想

具体的には、AI-AI間の通信であっても、入力・出力・判断根拠を「人間可読な形式」でログ化し、Part 11／Annex 11が要求する監査証跡要件を満たすこと。これを「人間翻訳ログ」として変更管理SOPおよび文書管理SOPに位置付けるのが、これからのCSV設計の肝である。

設計上のポイントを整理する。

  1. 要件定義段階でログ要件を書き込む実装後にログを足すのは困難である。要求仕様書（URS）の段階で「AI間通信の全リクエスト・レスポンスと判断根拠を、日本語または英語の自然文で併記して保存すること」を明記する。
  2. 残すのは3点セットである①入力（何を受け取ったか）、②出力（何を返したか／何を実行したか）、③判断根拠（なぜそう判断したか）。実務で欠落しやすいのは③である。
  3. エージェントを識別可能にするどのシステムの、どのモデルの、どのバージョンが応答したかを記録する。モデルが更新されれば挙動は変わる。バージョンなきログは再現性を持たない。
  4. タイムスタンプは信頼できる時刻源に基づかせる複数システムをまたぐ以上、時刻のずれは因果関係の追跡を不可能にする。
  5. 復号・再生の手段を記録とともに保存する音響変調やバイナリ形式で保存する場合、それを人間可読に戻す手段（仕様書・変換ツール・その手順）を、保存期間を通じて維持する。手段を失った記録は、記録として存在しないに等しい。
  6. 人の介入点を明示的に設計するどの判断までを自動で流し、どこから人間の承認を挟むか。しきい値と例外時の手順をSOPに定義する。内部監査では、この介入点が実際に機能しているかを確認することになる。
  7. ログの完全性を保護するログ自体が改ざんされないこと、削除されないことを技術的に担保する。監査証跡の無効化権限を誰が持つかも規定する。

実務で見落とされやすい点

  • ログ量が爆発する。AIエージェント間通信は人間の操作と比べて桁違いの回数になる。全量を人間可読で保存すると保管コストが跳ね上がるため、GxP上重要な判断に限定して詳細ログを残す設計が現実的である。何を重要とみなすかは、リスクアセスメントで決める。
  • 相手方のログは自社に残らない。外部サービスのAIエージェントと通信する場合、相手側のログは自社の管理下にない。契約と技術要件の両面で、必要なログの提供を求めておく必要がある。AIベンダーへの依存が生むリスクも併せてご覧いただきたい。
  • 「相手がAIかどうか」の識別自体が統制対象になる。Gibberlinkが示したのは、エージェントが相手をAIと判定すると挙動を変えるという構造である。GxPシステムにおいては、通信相手を識別・認証し、想定外の相手とは通信しない仕組みが必要である。
  • ログは書けばよいものではない。読まれないログは統制ではない。定期的なレビューの頻度と責任者を、トップダウンの品質マネジメントとして定めるべきである。

関連する論考

まとめ――3つのポイント

  1. 「ピーギャー」は実在するが、AIが発明した秘密の言語ではないGibberlinkは2025年2月のハッカソンで人間の技術者が設計したオープンソースの仕組みであり、既存の音響データ伝送ライブラリを用いている。概念実証の段階であって、業界標準ではない。
  2. 本質的な問題は「判断根拠が記録されないこと」である音であれAPIであれ、AI同士のやりとりは結果だけを残し、そこに至った理由を残さない。査察で問われるのは後者である。
  3. 解は「人間翻訳ログ」を要件定義段階で仕込むこと21 CFR 11.10(b)が求める「人間が読める形式」の要求は、AI-AI通信にもそのまま及ぶ。入力・出力・判断根拠の3点セットを自然文で残し、復号手段とともに保管する設計を、URSの段階から要求すべきである。

読者へのアクション

  • システム間連携でAIを使う際は、API応答ログだけでなく「自然言語化された判断理由ログ」を併せて残す設計を、要件定義段階から要求していただきたい。
  • 既存システムについても、AI連携部分のログが「人間が読める形式」で再生できるかを、一度検証していただきたい。

参考・出典（一次情報源）

関連記事一覧