コンテキストグラフ：数十年にわたる言語理論をエージェント時代に向けて体系化する

機械が生成したように聞こえるコンテンツと、読者、ブランド、そして一語一語の背後にある文化的なニュアンスを理解した人が書いたように感じられるコンテンツ。その違いを生むものは何か、これまで何度も考えてきました。行き着く答えは、いつも同じです。文脈です。

言語モデルの言語能力は向上しており、私たちはこの流れが今後も続くと見込んでいます。まだ十分な水準には達していませんが、その進歩の速さは無視できません。しかし、依然として不足しているのは、モデルとコンテンツの間に位置するシステムです。つまり、モデルに対して、あなたが誰であるか、どのように語るか、この特定の文で何が重要か、そしてそもそもなぜその文が存在するのかを伝える仕組みです。これこそが Glossia で私たちが取り組んでいる課題であり、現在この分野で最も興味深い課題だと考えています。

3つの要素、そのうち2つは私たちが制御できる

単言語および多言語コンテンツへの真に新しいアプローチを実現するために必要なものを考えると、3つの要素が見えてきます。

高い言語能力を持つモデル。 まだ十分な水準には達していませんが、急速に進歩しており、私たちはこの傾向が続くと見込んでいます。基盤モデルを構築する必要はありません。モデルが十分に成熟したとき、それを適切に活用できる準備を整える必要があります。
エージェントが必要とする文脈をモデル化し、共有するシステム。 これはモデルとコンテンツの間に位置する部分です。ボイス、用語、トーン、読者の期待を捉え、それらすべてを構造化された形でエージェントに提供するレイヤーです。
ユーザーがもたらす文脈。 人間は、判断力、文化的な認識、創造的な方向性をもたらします。これらを完全に代替できるシステムはありません。しかし、それらを容易に記録し、再利用できるようにすることは可能です。

この3つのうち、私たちが制御できるものは2つあります。システムそのものと、ユーザーによる文脈の提供をどのように支援し、それによってシステムを改善していくかです。この両方を適切に実現することが、「大規模言語モデルをつなぐだけ」のソリューションが急速に増えている分野において、Glossia を際立たせる要因になると考えています。システムには、数十年にわたる言語理論を、エージェント型技術の世界で生まれつつある基本要素として体系化する必要があります。また、そのユーザー体験を通じて、適切な文脈が確実に記録され、洗練され、再び処理の循環へ戻されるようにする必要があります。

現代翻訳学の創始者の一人であるユージン・ナイダは、優れた翻訳とは単語同士を一対一で対応させることではないと主張しました。彼が提唱した動的等価という概念では、対象読者と翻訳されたメッセージの関係が、元の読者と原文の関係と同じように感じられるべきだとされています。これは素晴らしい考え方ですが、深い文脈理解が必要です。誰が読むのか、どのような文化的枠組みを持っているのか、原文がどのようなトーンを意図していたのか。まさにこうした情報を、モデルがアクセスできる場所に保持する必要があります。

何を、どのように記録する必要があるのか

私たちが最初に検討してきたことの一つは、どのような情報を記録する必要があり、エージェントが実際に利用できるようにするには、それをどのように構造化すべきかという点です。検討を重ねるほど、これは単純な設定ファイルや設定ページではないと分かってきました。必要なのはグラフです。具体的には、**有向非巡回グラフ**です。

なぜ有向非巡回グラフなのでしょうか。それは、文脈が平面的なものではないからです。ブランドのボイスは用語に影響します。用語は、特定の機能についてどのように記述するかを形作ります。読者の期待はフォーマルさの水準に影響し、それがさらに単語の選択に影響します。こうした関係には方向と階層があり、循環することはありません。

これには先行事例があります。ナレッジグラフは、概念間の構造化された関係を表現するため、長年にわたってAIシステムで使用されてきました。近年では、コンテキストグラフが動的なコンテキストレイヤーを追加することでこの考え方を拡張しています。これはまさに、エージェントが十分な情報に基づいて意思決定を行うために必要なものです。また、マルチエージェントの分野では、DAG（有向非巡回グラフ）が基盤となるパターンとなり、タスクの依存関係や情報の流れをモデル化するために使用されています。

しかし、私が特に期待しているのは、このグラフの各ノードをバージョン管理する必要があるという点です。ブランドボイスを変更しても、以前のバージョンにアクセスできなくなるべきではありません。用語エントリを更新した場合、システムは古い定義に基づいて生成されたコンテンツと、再検討が必要になる可能性がある部分を把握する必要があります。これにより、変更の影響を実際に受ける部分に対してのみエージェント型ワークフローが実行されるよう最適化でき、すべてを再処理せずに済みます。

双方向性を前提とした設計

コンテキストノードとコンテンツの関係には方向性が必要であり、かつ双方向に機能する必要があると考えています。

一方から見ると、コンテンツがコンテキストにどのように接続されているかを把握する必要があります。あるコンテキストが変更された場合、たとえばブランドボイスをよりカジュアルなものに変更した場合、以前のバージョンに基づいて作成されたブログ記事、製品説明、ヘルプ記事はどれでしょうか。それらが再検討または再翻訳の対象です。これが、コンテキストからコンテンツへの順方向です。

もう一方から見ると、言語専門家がコンテンツを確認して、なぜ特定の選択が行われたのか疑問に思った際、その判断の基礎となったコンテキストまで遡れる必要があります。どのボイス定義が有効だったのでしょうか。どの用語ルールが適用されたのでしょうか。この後方トレーサビリティにより、人間はエージェントが行った処理を理解し、確信を持って改善を重ねられます。

NASAはこれを双方向トレーサビリティと呼んでいます。これは、エンティティ間の関連をどちらの方向からでも追跡できる能力を指します。システム工学に由来する原則ですが、言語コンテキストと生成コンテンツの間にフィードバックループを構築する際に、まさに必要なものです。

この双方向性によって、段階的な改良が可能になります。言語専門家はコンテンツをレビューし、それを形作ったコンテキストを確認し、ボイス定義を調整する必要があると判断したうえで、その調整を作成できます。その後、システムは変更の影響を受ける他のコンテンツを正確に把握できます。これは緊密なループであり、人間の判断に深く根ざしています。

単一リポジトリの枠を超えて

このグラフには、私が特に興味深いと感じる別の側面があります。単一のリポジトリ内だけに置くことはできません。 コンテキストグラフは、複数のプロジェクト間、さらには複数の組織間で共有できる必要があります。

考えてみてください。企業にはブランドボイスがあります。そのボイスは、すべての製品、すべてのウェブサイト、すべてのサポート記事に適用されます。単一のリポジトリだけに属するものではありません。複数の領域にまたがる関心事です。中核となるボイスを組織レベルで定義し、特定の製品や対象読者に合わせてプロジェクトレベルで上書きを適用することもできます。これはスコープ継承であり、プログラミングで一般的に使用されるパターンを言語コンテキストに適用したものです。

また、このコンテキストは適切にバージョン管理する必要があります。ボイス定義を変更する際に、以前のバージョンを消去することはできません。Gitがコンテンツアドレス可能ストレージとDAG（有向非巡回グラフ）を使用してバージョンを管理する方法から学べることは多くあります。Gitのコミット、ブランチ、差分のモデルは、過去のすべての状態へのアクセスを維持しながら、時間の経過に伴う変更を追跡することを基本としています。これは、言語コンテキストにまさに必要な仕組みです。

実際、私たちはボイスの変更を、ボイス変更リクエストと呼ぶ仕組みを通じて行うべきだと考えています。プルリクエストがコードの変更について議論する場を作るのと同様に、ボイス変更リクエストは言語表現の変更について議論する場を作ります。なぜ、より会話調のトーンへ移行するのでしょうか。どのような影響があるのでしょうか。どのコンテンツが影響を受けるのでしょうか。変更が波及する前に、こうした点を議論する価値があります。

人間の存在意義が薄れるのではなく、創造性がさらに発揮される領域

ここからが非常に興味深いところです。人工知能（AI）について語る際、多くの人が主張するように人間を排除するのではなく、このシステムは人間に、より創造的な役割を与えます。

言語の専門家とコンテンツ戦略担当者からなるチームが、ブランドの言語的な方向性についてアイデアを議論するセッションを想像してください。コンセプトを探究し、トーンの変更について議論し、どのモデルも参照できない文化的背景を取り入れることができます。そして、何百ものファイルを手作業で更新する代わりに、決定事項をコンテキストグラフへの調整として記録します。その後の波及はシステムが処理します。

さらに一歩進めて、言語の専門家がAIアシスタントとともに言語表現のアイデアを探究する、エージェント型セッションを想像してみてください。「エラーメッセージをもっと共感的な表現にしたらどうなるだろう？」エージェントは影響をシミュレーションし、現在のコンテキストがどのように変わるかを示し、更新後のコンテンツをプレビューします。言語の専門家は内容を洗練し、調整し、納得できた段階でコンテキスト変更リクエストを提出します。これは大きな可能性を秘めているのではないでしょうか。

これは言語の専門家を置き換えるためのものではありません。 言語について、微妙なニュアンスと文化的背景を踏まえた判断を下すという、言語の専門家がすでに得意としている仕事のために、より優れたツールを提供することが目的です。システムが機械的な部分（波及、影響分析、一貫性）を処理し、人間は創造的な部分（ボイス、トーン、文化的な共鳴）に集中します。

私は何度も、ナイダが動的等価によって示そうとしたことに立ち返ります。目標は、機械的な意味での言語的な正確さではありません。言語にかかわらず、読者とコンテンツの間に同じように感じられる関係を作ることです。それには、審美眼、判断力、文化的な認識が必要です。これらは人間が非常に得意とする一方で、モデルが今も苦手としているものです。システムの役割は、そうした人間の洞察を確実に記録し、構造化し、再利用できるようにすることです。

今後について

次回の記事では、さらに技術的な内容に踏み込み、この分野ではまだ実現されていない体験を可能にするうえでサンドボックスが果たす役割と、私たちがアプリケーション・プログラミング・インターフェース（API）に多大な投資を行っている理由について説明します。言語表現の変更を本番環境へ反映する前に、ステージング、プレビュー、テストするという大きな領域があり、私たちはその詳細を掘り下げることを楽しみにしています。

これらの内容に共感していただけたなら、現在のツールに不満を感じている言語の専門家、ローカリゼーションのワークフローに苦労してきた開発者、あるいは言語とテクノロジーが交わる領域について深く考えている方のいずれであっても、ぜひご意見をお聞かせください。