汎用エージェントは、計画を立て、推論し、長時間にわたって作業をこなすことには長けている。しかし実際の成果物を生み出す能力は、いまだにテキストとコードに偏っている。シンガポール国立大学とオックスフォード大学の研究チームによるOmni-IO Skillsは、このギャップをモデルを再学習させることなく埋める方法を提案する。ホストエージェントの推論コアはそのままにし、その上に着脱式のハーネス(harness、エージェントが実際にツールを選び、実行し、結果を管理できるよう支える運用レイヤ)を一枚かぶせることで、テキスト・画像・映像・音声・文書・3D・コードという7つのモダリティを行き来させる。
いまオムニ(omni、複数の感覚・媒体を同時に扱う)能力を伸ばす道は、大きく二つある。一つは、ファウンデーションモデルそのものにモダリティを次々と詰め込んでいくやり方。画像、音、映像を一つのモデル内で処理しようとすれば、新しいデータ、新しいコーデック、新しいデコーダ、アライメント段階がついて回り、能力が大きくなるほどモデル更新のコストに足を取られる。もう一つは、専門モデルやツールをその都度つなぎ合わせるやり方。こちらは柔軟だが、肝心なものが抜け落ちている。手順をどう定めるか、タスク間の依存関係をどう表現するか、中間成果物をツール間でどう受け渡すか、前の対話で作った成果物を次のターンでどう呼び戻すか——それらが宙に浮いたままなのだ。
たとえるならこうだ。工房に腕のいい職人たち(専門モデル・ツール)はすべて揃っているのに、作業指示書もなければ、半製品を運ぶコンベアもなく、作ったものを置いておく棚もない。各自の実力は確かでも、一つの完成品へとはつながらない。論文が指摘する欠けたピースこそ、この指示書・コンベア・棚にあたるオムニエージェントハーネスである。
Omni-IO Skillsは、能力を「スキル(Skill)」という読み込み可能な(loadable)単位に載せて運ぶ。スキルは三つの層位に分かれる。アトミックスキル(Atomic、再利用可能な能力単位)が19個、エキスパートスキル(Expert、具体的な成果物を作る生産手順)が2個、シナリオスキル(Scenario、複数の関連成果物をまとめて出す応用課題)が6個。合わせて27個のスキルが38個の代表的課題をカバーし、理解・生成・推論・検索という4つの能力群と7つのモダリティにまたがる。オンライン講義を一つ作るとしよう。収録を分析する仕事はアトミックスキルが、スライドという成果物を取り出す仕事はエキスパートスキルが、スライド・挿絵・ナレーション・解説映像を一まとまりに束ねる仕事はシナリオスキルが担う、という具合だ。
その下はさらに四つの層に分かれる。スキル入口層(作業知識)、MCPツールサービス層(ツールへのアクセス)、プロバイダ・設定層(どのサービスに実際につなぐか)、そしてアセットレジストリ層(生み出された成果物の永続保存)である。こう分けたおかげで、作業知識と実行バックエンドが切り離される。論文がファウンデーションモデル・専門モデル・メディアエンジンのすべてを「交換可能な実行バックエンド」として扱うと明言する理由がここにある。特定のモデルスタックにワークフローを縛りつけない、ということだ。
このアプローチで最も巧みなのは、複数アセットのワークフローをグラフで表現した点である。論文はこれを宣言型実行グラフ(Declare Execution Graph、DEG)と呼ぶ。互いに依存しないタスクは同時に(ウェーブスケジューリング)走らせ、成功した成果物はレジストリに登録して後続のタスクやその後のターンで再利用する。途中で特定のタスクが失敗しても、その地点だけを隔離する。要点は二つだ。並列で回せるものは並列で回して時間を削り、一度作った成果物はファイルパスやサービスに縛られず再利用する。
評価はUniMデータセットの統制された90個の部分集合であるUniM-90で行われ、ホストとしてGPT-5.6 SolとClaude Sonnet 5の二つのエージェントが使われた。数値はどちらのホストのものかを区別して読む必要がある。
| 指標 | GPT-5.6 Sol | Claude Sonnet 5 |
|---|---|---|
| 入力サポート率(ハーネス前 → 後) | 40.00% → 100% | 38.89% → 100% |
| 相対SQCS(前 → 後) | 26.99 → 74.94 | 27.82 → 77.78 |
| Strict Structure Score | 100.00 | 99.78 |
| Lenient Structure Score | 100.00 | 100.00 |
入力サポート率とは、そもそもそのリクエストを受け取って処理できたかを意味する。ハーネスをかぶせる前は両ホストとも半分も受け取れなかったものが、かぶせた後は90個のインスタンスすべてを処理した。SQCS(Semantic–Quality Coupled Score、意味と品質を同時に見るスコア)の相対値は、GPT-5.6 Solで47.95ポイント、Claude Sonnet 5で49.96ポイント上がった。
注目すべき対比が一つある。ハーネスをかぶせた後の絶対SQCSは全インスタンス基準で74.94と77.78だが、これはベースエージェントが自分のサポートしていたより狭い部分集合でのみ測った67.49と71.53よりも高い。平たく言えば、ハーネスはカバー範囲をすべてに広げながらも品質を落とさなかった。普通は処理範囲を広げれば平均品質は下がるものだが、その逆が出たわけだ。
正直に指摘しておくべき点がある。第一に、評価がUniM-90という90個の統制された部分集合に限られる。著者ら自身が「controlled」と明示した設定なので、実際のプロダクションの雑多なリクエストでも同じ数値が出るかは、この論文だけでは断定できない。第二に、指標が構造スコアとSQCS中心である。構造スコアが100に近いというのは、成果物の形式・完結性がよく整っているという意味であって、内容が人間の専門家水準だという保証ではない。第三に、ハーネスの力は結局、後ろにつながる専門モデルやメディアエンジンの品質に依存する。「交換可能なバックエンド」という設計は長所であると同時に、バックエンドが貧弱ならハーネスもその程度にしかならない、という意味でもある。第四に、スキル27個・課題38個は人が設計して組み込んだカタログだ。新しいドメインが入ってくるとき、誰がどれだけのコストでスキルを増やすのかは、要旨と抜粋だけからは見えてこない。
一つの場面を考えてみよう。顧客がチーム会議の録音と参考資料をアップロードし、「要約してほしい」と言う。AI PMが要約を作って届ける。数日後、同じ顧客が「その内容で新入社員教育用の解説映像を一本作ってほしい」と再び依頼する。
いまのありがちな処理の仕方は、この二つのリクエストを事実上まったくの他人として扱う。二回目のターンで録音と資料をまた呼び出して最初から分析し、一回目の要約で抽出した核心的な論点・用語・数値を呼び戻せないまま、映像スクリプトを新しく組み立てる。そのため要約版と映像のトーンや強調点が微妙にずれ、顧客は「この前まとめたあのポイント、なぜ抜けているのか」と問い返すことになる。
Omni-IO Skillsが説くアセットレジストリとターン横断の再利用が変えるのは、まさにこの地点だ。最初のターンで、録音の文字起こし、資料の要約、抽出した核心的論点がそれぞれレジストリに登録される。二回目のターンの映像生成タスクは、元資料を再び分析する代わりに、この登録済みの中間成果物を入力として受け取り、スクリプト→ナレーション→映像をDEGで束ねる。ナレーション音声と挿絵のように互いに依存しない枝は同時に走る。PMが気にかけるのは「会議要約でまとめた三つの結論を映像の冒頭に」といった指示だけで、アセットをツール間で運ぶ配管はハーネスが引き受ける。
派遣型AI PMというONTLEのモデルにおいて、この図の含意は明確だ。顧客一人のプロジェクトは、複数のターンにわたって文書・画像・映像・データを行き来しながら積み上がっていく。ターンごとに文脈が蒸発すれば、PMは毎回新しいインターンのように一から尋ねる。逆に、プロジェクト単位で中間成果物が永続アセットとして残り、次のリクエストがその上に続いていけば、派遣PMの一貫性は人間の担当者に近づく。ただし、先の限界もそのまま当てはまる。ONTLEがこうしたアセット層を導入したとしても、実際の映像・画像・文書を生み出す後段エンジンの品質と、スキルカタログをどう広げ維持するかが、体感される結果を分ける。ハーネスは配管を敷いてくれるだけで、水の味までは保証しない。
いいえ。論文の核心的な主張が「ホストエージェントの推論コアを変えない」ことである。着脱式のハーネスをかぶせる方式なので、実験でも異なる二つのホストに同じハーネスをつけて効果を確認した。
タスクをどの順番で実行せよと手続き的に一つひとつ指示する代わりに、どんなタスクがあり互いに何に依存しているかをグラフとして宣言しておけば、依存関係のないタスクはシステムが自動で同時にスケジューリングする、という概念だ。実行順序の最適化と失敗の隔離を、人ではなくグラフ検証・スケジューラが処理する。
現在の実装がアトミック19・エキスパート2・シナリオ6で計27個だと明示されている。論文はスキル・ランタイム・アセット層がモデルやツール、応用要求に合わせて「進化しうる(evolvable)」構造だと説明するが、新規スキルを追加する具体的なコストや手順は、要旨・抜粋の範囲では見えてこない。
そうではない。入力サポート率は、そのリクエスト自体を受け取って処理できたかを測る指標だ。品質は別途SQCSと構造スコアで測定し、その値は100ではなく74.94・77.78(相対SQCS)といった水準である。二つの指標を混ぜて「すべて完璧」と読むと誤解になる。