Ampersandを基礎から理解する：AIはどうすれば、長く付き合える協力者になれるのか

2026年10月22日（日本時間）確認。対象はhumans&が10月20日に公開したAmpersand v0.1です。本稿は、公式資料の調査、公開された評価数値の再計算、独自の説明用例をまとめたものです。Ampersandの推論APIによる出力品質の試験は実施していません。

1. 返事の上手なAIから、その後まで考えるAIへ

ミカ、レン、アキの3人が、地域の公的支援情報を探しやすくするウェブページを作っているとします。これは本稿のために作った架空の例です。以下の会話は、Ampersandの出力ではありません。

レンは木曜日に「金曜日は休みます」と伝えました。アキは掲載情報の確認を担当しています。ところが、ミカが「金曜日の朝に全員で最終確認して、そのまま公開しよう」と提案します。

この場にいるAIには、いくつもの選択肢があります。

答えの良し悪しは、その一文を読んだ印象だけでは決まりません。いつ発言したか、誰の事情を覚えていたか、何を勝手に決めたか、数日後に誰が後始末したかまで関係します。

このような長い相互作用を学習対象にするのが、Ampersandの発表を理解する入口です。humans&は、仮想の参加者と長くやり取りする強化学習によって、集団の協働を支えるモデルを作ったと説明しています。公式発表

ここには、単に会話の雰囲気をよくする以上の研究課題があります。AIが発言したあとに何が起きるのか。その結果をどのように採点し、次の行動へ反映するのか。順番に見ていきましょう。

2. 基礎：言語モデルは何を学習しているのか

言語モデルは、文章などを細かい単位に分け、その続きがどうなるかを学習します。この単位を「トークン」と呼びます。一つの単語が一つのトークンになるとは限らず、日本語と英語でも分かれ方が違います。

学習を通じて調整される内部の数値が「パラメータ」です。たとえば、ある文脈では丁寧な説明が続きやすい、あるコードではこの記号が必要になる、といった膨大な関係が、パラメータに反映されます。多数の文章を暗記するという説明だけでは、組み合わせて応用する能力を十分に表せません。

ただし、「文章の続きとしてもっともらしい」ことと、「今、この人たちにとってよい行動である」ことは、別々に確かめる必要があります。冒頭のAIが、とても自然な日本語で金曜日の予定に賛成しても、レンの不在を解決したことにはなりません。

そこで、基礎となるモデルを作った後に、その振る舞いを調整します。大まかには次のように考えられます。

これは理解のための整理です。実際のモデル開発では方法を組み合わせます。強化学習にも、正解を機械的に検査できる課題、比較評価から作った報酬、複数の手順を要する環境など、さまざまな設定があります。Ampersand以前のAIがすべて一問一答で学んでいた、という意味ではありません。

3. 強化学習の「報酬」は、お金や称賛とは限らない

強化学習では、ある状況で行動を選ぶ仕組みを「方策」と呼びます。言語モデルなら、どの言葉を出すか、道具を呼ぶか、発言を控えるか、といった選択につながります。

選んだ行動によって、その後の状況が変わります。その結果を学習に使える数値にしたものが「報酬」です。

冒頭の例なら、「予定が合ったか」「正しい情報が公開されたか」「何度も説明し直す負担が増えなかったか」を、評価の候補にできます。どれを測るか、どう重く扱うかは設計上の判断です。AIに自然に備わった善悪の物差しではありません。

ここで難しいのが、結果が遅れて現れることです。今日の短い確認が、金曜日のやり直しを防ぐかもしれません。今日の大げさな励ましが、会話を長くするだけかもしれません。逆に、今は役に立たなく見える質問が、後の重大な誤解を防ぐこともあります。

一連の状況と行動の履歴を「軌跡」と呼びます。長い軌跡の最終結果から、途中のどの選択がよかったのかを学ぶ問題が、行動への貢献の割り当てです。最後の一文だけを採点すれば済むとは限りません。

それでも、長く待てば必ず正しい評価になるわけではありません。間違った目標を与えれば、AIはその目標を効率よく追いかける可能性があります。「会話を活発にする」という報酬なら、余計な質問を増やすことが有利になるかもしれません。「誰も反対しない」という報酬なら、必要な異論を避けることが有利になるかもしれません。評価の設計は、モデルの大きさと同じくらい重要です。

4. Ampersand、Persimmon、評価役を分ける

humans&の研究を読む際には、少なくとも三つの役割を区別すると理解しやすくなります。

Ampersandは協力するAI側、Persimmonは仮想の利用者側を担います。Persimmonが反応を生成することと、その反応を望ましいと採点することは、別の役割です。Ampersandモデルカード・Persimmonモデルカード

画像にあった「user modelに対して強化学習した」という説明は、この関係を指します。「人間を相手に勝つ競技」と受け取る必要はありません。AIが行動し、その行動に応じて変化する人間側の反応を、練習環境として利用するということです。

また、人間の反応モデルは、実在する特定個人の心を読み取る装置でもありません。設定や履歴から、あり得る反応を生成します。ある人の意向を予測できると主張するなら、その人や対象集団について、別途妥当性を確かめる必要があります。

本稿のために作成した概念図です。一般的な学習の役割分担を説明しており、Ampersandの非公開の内部構造を示すものではありません。

5. なぜ、普通のアシスタントに人間役を頼むだけでは難しいのか

練習相手が、どんな提案にも「素晴らしいですね」と答えたらどうなるでしょう。

AIは、しつこく説明しても相手は喜ぶ、全員に同じ助言をしても通じる、予定を変えても誰も困らない、と学んでしまうかもしれません。その練習環境で成功しても、現実の相手は忙しく、誤解し、断り、気を変えます。

人の振る舞いには、少なくとも二種類のばらつきがあります。同じ人でも、状況や時刻によって反応が違います。さらに、人によって価値観、知識、余裕、表現が違います。

このばらつき全体を、ここでは「分布」と考えます。平均的に一つの返事を生成できるだけでは、断る人、迷う人、誤った前提を持つ人を含む練習になりません。

Persimmonは、このような複数人・複数ターンの反応分布を扱うことを目的にしたモデルです。公開された判別試験では、人間の会話と生成会話の組を判定役が取り違えた割合が平均19.8%と報告されています。この課題の偶然水準は50%です。Persimmonの発表

19.8%を「人間の能力の19.8%」と読むことはできません。測っているのは、その判定役が、その会話と条件で区別できたかどうかです。

さらに、会話の見た目が自然でも、重要な介入への反応が正しいとは限りません。説得されたような返事を作ることと、現実の人が実際に行動を変えることには距離があります。予測された会話の自然さ、反応分布の正確さ、行動を変えた場合の結果の正確さは、それぞれ検証対象です。

6. 長い対話を使うと、学習の計算も難しくなる

長い練習をたくさん行うには、会話を生成する処理と、モデルを更新する処理を同時に動かしたくなります。

ところが、ある会話の生成が終わるまでに、学習中のモデルが何度も更新されることがあります。届いた練習記録は、すでに古くなった方策で作られているわけです。これが、異なる方策の記録を使う学習の難しさです。

古い教本で練習した生徒の答案を、新しい教え方の改善に使う場面を想像してください。答案は役立ちますが、「今の教え方なら、同じ誤りを同じ頻度で起こす」とは限りません。しかも、長い答案の途中で教え方が変わっているような状態なら、扱いはさらに難しくなります。

humans&が説明するCOROは、こうした長い、古さの異なる記録から学ぶための方法です。関連するOAPLの研究は、方策間のずれが大きい記録を使う学習を扱っています。OAPL原論文

数学を少しだけ見ると、COROの中心には「同じ組の平均からの差」があります。以下は公開式を理解するための記号の説明です。完全な実装仕様ではありません。

各記録の報酬の差 = その記録の報酬 − 組の平均報酬
各記録の方策の差 = その記録の対数確率比 − 組の平均対数確率比

これら二つの差が対応するように学習する。

対数確率比は、大まかには「今の方策が、その記録の行動を、生成した当時の方策よりどれくらい選びやすいか」を表します。報酬が相対的に高い記録を、相対的に選びやすくする方向です。

平均を引く操作には、わかりやすい性質があります。ある組の全員の報酬に同じ定数を足しても、平均との差は変わりません。一方、報酬を何倍かにすると、その差の大きさは変わります。基準点への依存を減らすことと、報酬の尺度や内容の問題を解決することは、同じではありません。

発表では、この比較を使って絶対的な基準値の推定に依存する項を除き、方策のずれを抑える強さも調整すると説明しています。学習方法の説明

この方法がうまく動いても、評価する目標が妥当か、仮想の人々が現実を表しているかは、別に確かめる必要があります。学習を安定させる工夫は、評価の正しさを保証するものではありません。

7. 公開された数字を、自分で計算すると何が見えるか

今回、公式チャートの公開データと表示コードを取得し、集計値から得点を再計算しました。これは提供元の数字を用いた再分析です。モデルを再実行した独立追試ではありません。

モデルカードは評価値を暫定結果とし、評価の実行が終わるにつれて数値が変わる可能性を明記しています。以下は本稿の確認時点の値です。モデルカード

公開図の計算は、次の形でした。

総合点 = 目標の進み具合 − 0.2 × 相互作用の負担

「負担」は、この評価が定義する相互作用コストです。ドル建てのAPI料金ではありません。

出典：公開集計データ・図の表示コード。上表は掲載された集計値からの算術計算です。

Ampersandは、この表では目標の進み具合が最も大きいモデルです。しかし、負担を差し引いた総合点ではFableが0.00254点上回ります。小数点以下まで示したのは、これほど小さい差を大きな優劣に読み替えないためです。

公開データでは12の仮想状況を等しく重く扱っています。Ampersandの108件は、その状況を繰り返した記録です。108人の実参加者ではありません。表示される標準誤差も、仮想状況内での反復変動から求めたものです。現実の人々への効果の信頼区間として使うことはできません。

負担の重みを変えてみる

同じ公開集計値で、負担の重みだけを変えると、点推定で先頭に来るモデルが変わります。

提供元の公開集計値から作成した図です。固定された結果への重み付けを変えたもので、モデルを再実行した結果ではありません。

これは「正しい重みは0.3だ」という主張ではありません。公開図の一つの得点には、どの結果をどれだけ重く扱うかという判断が含まれている、と確かめる実験です。

ミカたちの例に戻れば、作業を早く進めることを重視するチームと、割り込みを少なくすることを重視するチームでは、好ましい介入が変わり得ます。どちらにも役立つモデルを評価したければ、一つの合計点に隠れた内訳を読む必要があります。

この再計算だけでは、モデル間の差に統計的な意味があるか判断できません。同じ状況で得た結果の対応や共分散など、差の不確かさを計算するための情報が必要です。標準誤差の棒が重なるかだけで、有意差の有無を断定することもしません。

8. 協働の改善は、どの能力に現れたのか

CooperBenchは、複数のエージェントが同じソフトウェアに対して相互に影響する変更を行う課題です。ひとりで正しくコードを書けても、相手の変更を壊したり、同じ箇所を矛盾する形で変えたりすれば、共同作業は失敗します。CooperBench原論文

humans&の公開表では、Ampersandの共同作業の成功率は39.0%、基盤のGLM 5.3は17.3%でした。一方、単独の成功率は48.8%と52.5%です。共同作業は21.7ポイント改善し、単独成績は3.7ポイント下がっています。この比較では、両者に同じmini-sweの実行基盤が使われています。公式比較表

この結果から読み取りやすいのは、調整や連携に関する振る舞いが変わった、ということです。あらゆるコード課題に強くなったと結論する材料にはなりません。

また、評価表にある「チームワーク」の指標は、単独なら解ける課題を、問題を起こす仲間がいる場合にも解けるか、という条件付きの評価です。一般的な「チームでの仕事の59.1%に成功した」という意味とは違います。評価する課題、実行条件、採点方法を揃えて比較する必要があります。Collaborative Intelligenceの公開資料

プライバシーと安全性も、それぞれの意味を読む

プライバシーの課題には、「一切情報を出さない」だけでは解けないものがあります。レンの予定を調整するには不在という情報が必要でも、不在の私的な理由まで共有する必要はないかもしれません。情報を役立てることと、適切な範囲を超えて開示しないことの両方が問題になります。CIMemories原論文

Ampersandのモデルカードには、プライバシーの違反指標0.241と情報の網羅率0.609が載っています。前者は公開図でViolation@5と呼ばれる指標で、「利用者の24.1%が被害に遭った」という実社会の割合ではありません。また、プロンプト注入が成功した割合はAmpersandが0.687、基盤モデルが0.668です。Ampersandモデルカード

したがって、協力が上手になったという結果だけを理由に、外部への投稿や変更を自由に任せる判断はできません。モデルの提案、実行できる権限、実際の変更を確認する処理を、それぞれ設計する必要があります。

9. Simile、Aaru、Andonと、どうつながるのか

これらの会社は、同じものを別の名前で提供しているわけではありません。研究上の役割を並べると、関係がわかりやすくなります。

これは役割の整理です。各社の製品がすでに相互接続しているという意味ではありません。

Simileから学ぶ：自信も検証対象にする

Simileは、反応を予測するモデルとは別に、その予測がどれくらい外れそうかを推定する仕組みを説明しています。約8,600問を使い、学習に含まれない問題で信頼度を評価しています。Building confidence in Simile

ここから借りたいのは、「自信がある」という文章を、そのまま信頼性としない姿勢です。冒頭のAIが「全員がこの予定に賛成するでしょう」と言っても、それだけでは予測の根拠になりません。似た予測を以前にどれくらい外したか、今回の条件が過去とどれくらい違うかを確認したいところです。

Aaruから学ぶ：何の分布を測ったかを明確にする

Aaruは、2,993問・186研究を対象にした回答分布の評価で、観測された平均絶対誤差を3.53ポイントと報告しています。また、人口生成と個体の行動軌跡に用いるモデルはLLMではないと説明しています。Population simulation at the replication floor

「人間を模擬する」と聞いて、どの会社も同じ言語モデルに人物設定を書いている、と決めつけるべきではありません。入力、内部の方法、出力、評価する単位が違います。

回答の割合を正しく予測する課題と、長い共同作業で適切なタイミングに介入する課題も違います。異なる問題で報告された得点を、そのまま一つの順位表へ置くことはできません。

Andonから学ぶ：親切な対応の、その後を見る

Andonは、AIが関わる実際の二つの事業で、5人の従業員との4か月の経験を報告しています。親切な対応と、運用上の判断ミスによる負担が同時に生じる事例を扱っています。人間の管理者との無作為比較ではなく、限られた実験からの報告です。AI bosses are kind, but sometimes dumb, which hurts employees

その記事の読み方は、Ampersandにも役立ちます。好ましい返事をしたかだけでなく、約束したことが本当に実行されたか、誰かが後始末をしていないかを確認するのです。

Andonの別の記事は、模擬事業から実際の事業へ進む理由も説明しています。Why we built Pion・公開記事一覧

10. 今回、実際に確認できたこと

確認を三つに分けます。

2026年10月22日8時33分45秒（日本時間）に、認証情報を付けず公式のモデル一覧APIへアクセスすると、HTTP 401と、API用の認証情報が必要である旨の応答が返りました。開発者向け画面もサインインを求め、この作業環境にはAmpersand用のAPIキーが設定されていませんでした。

これは、サービス全体が故障しているという観測ではありません。今回の環境では、認証付きの推論まで進めなかったという記録です。架空の成功例や、他のモデルの出力をAmpersandの結果として載せることはしていません。

再計算の手順と確認範囲は、再現用の説明、計算用スクリプト、観測記録にまとめています。

11. APIを使うときに理解しておきたい構造

公開APIでは、モデルや指示、使える道具を定義する「エージェント」と、一つの会話履歴を保持する「セッション」を区別します。新しい入力で処理が始まり、返答、道具の要求、発言しない完了などが生じます。公式入門

セッションが履歴を保存することと、モデルのパラメータがその利用者との会話で更新されることは違います。ここを混同すると、「会話を続ければモデルそのものが自動的に再学習される」と思い込んでしまいます。公開仕様から確認できるのは、まず会話の状態を保持する仕組みです。

また、モデルが道具を呼びたいと返しても、その結果を現実に起こすのはアプリケーション側です。表示先が共有の会話なのか個人の画面なのか、外部への投稿が許可されているか、といった判断をアプリケーションが扱います。統合ガイド

公開仕様はOpenAIのAgents APIの一部に対応すると説明しています。任意の既存チャットAPIの接続先だけを置き換えれば、すべて同じように動くと考えず、対応項目を確認する必要があります。API仕様

確認時点の料金は、100万トークン当たり、通常の入力1.00ドル、キャッシュされた入力0.20ドル、出力5.20ドルです。推論用のトークンも出力料金に含まれます。仮に通常入力1万、出力2,000トークンなら、単純計算は0.0204ドルです。道具の後の続行や履歴の圧縮などが加われば、実際の利用量は変わります。料金と制限

12. 次にモデルを試すなら、どんな実験にするか

本稿の次に行う小さな試験は、「モデルに何でも任せて、よさそうな出力を選ぶ」形より、条件を先に固定した方が学びを残せます。以下は提案であり、実施済みの結果ではありません。

1. 同じ会話条件を用意する。 予定の矛盾、更新された出典、発言が不要な場面、共有してはいけない架空の情報を含む短い課題を作る。
2. 比較対象を置く。 単純な規則や既存のモデルと、同じ入力で比較する。
3. 行動ごとに評価する。 正しい指摘、不要な割り込み、見落とし、不適切な情報共有、権限外の提案を分けて数える。
4. 費用と失敗も残す。 入出力、実行時間、トークン、応答しなかった例を保存する。成功例だけを選ばない。
5. 新しい条件で再確認する。 文面を変えた課題や、学習・調整に使っていない条件でも確かめる。

初回は、道具を実行して外部へ連絡する必要はありません。何をしようとしたかを記録するだけでも、タイミングや判断の傾向を調べられます。日本語で使うなら、日本語の課題も別に用意します。Persimmonの資料は、英語以外について反応分布の一致を評価していないとしています。日本語の文章が出せることと、日本語環境で振る舞いの妥当性が確認されていることを区別したいところです。Persimmonの制約

13. Managerに取り入れるなら、どこに使うか

ここからは、この研究を踏まえた設計上の提案です。AmpersandをManagerへ導入済みだという報告ではありません。

Managerの目的を、環境を改善し、その結果を確かめることに置くなら、反応モデルは候補を考えたり、見落としを探したりする部分に使えます。たとえば、公的情報への案内を整理する際に、初めて読む人がどこで迷いそうか、どの説明が余計かを検討する補助です。

ただし、その予測を公開の権限や成果の証明にしてはいけません。構成は、次のように役割を分けられます。

最初の実装に、個人別の追跡や詳細な人物像の収集を必須とする理由はありません。所有する公開ページについて、情報が古くなったことや操作上の問題を検出し、限定した修正を行う経路から始められます。

評価も段階的です。ページが公開された。正しい公式情報へ到達できた。人が手続きを完了できた。実際に支援を受けた。暮らしの負担が減った。これらはつながり得ますが、それぞれ別の観測が必要です。

Ampersandの発表から取り入れたい中心的な考え方は、AIの行動を、その後に生じる状況と負担まで含めて評価することです。実装では、発言を控える選択、実行しない選択、費用と失敗の記録、別の条件での検証が具体的な部品になります。

14. この発表をどう受け止めるか

私たちの架空のチームにとって、役立つAIは、金曜日の不在に気づき、必要な確認を短く伝え、全員が作業を進められるようにする存在です。ときには、本人たちが解決するまで待つことも含まれます。

そのような振る舞いを学ぶには、練習相手の反応、長期の結果、負担の評価、実運用での検証をつなぐ必要があります。Ampersandは、この問題をモデルの学習方法として扱った具体的な試みです。

公開された数値は、その方向に進んだ手掛かりを示しています。同時に、評価の重みで順位が変わること、共同作業と単独能力の改善が一致しないこと、仮想の状況での成績が現実の便益を直接示さないことも読み取れます。

次に確かめたいのは、実際の課題に接続したとき、どの判断が変わり、誰の負担が減り、どんな失敗が残るかです。その記録まで揃うと、「協力的に見えるAI」から、長く付き合う価値を確かめられるAIへ、議論を進められます。

主な一次資料

• Ampersand発表・モデルカード
• Persimmon発表・モデルカード
• 公開評価データ・表示コード
• OAPL原論文
• CooperBench原論文
• CIMemories原論文
• Collaborative Intelligence
• Simile：Building confidence in Simile
• Aaru：Population simulation at the replication floor
• Andon Labs：AI bosses・Why we built Pion・記事一覧
• Ampersand API入門・統合・API仕様・料金