はじめに こんにちは、2025年9月から2026年1月まで AI Shift でインターンをしていた MAO KEYU です。 インターン期間中は、大規模言語モデルを用いた推論システムに関する研究に取り組みました。その成果をまとめた論文が、自然言語処理分野の国際会議である ACL 2026 の Findings に採択されました。 そこで今回は、アメリカ・サンディエゴを訪れ、論文の発表および参加者との研究交流を行いました。 本記事では、ACL 2026 の概要や会場の雰囲気、私たちが発表した研究、発表時にいただいた質問、そして会場で興味を持った研究について紹介します。 学会概要 ACL（Annual Meeting of the Association for Computational Linguistics）は、自然言語処理および計算言語学分野における世界最大規模の国際会議の一つです。 第64回となる ACL 2026 は、2026年7月2日から7日まで、アメリカ・カリフォルニア州のサンディエゴで開催されました。前半にはチュートリアルやワークショップ、後半には Main Conference が実施され、世界各国から自然言語処理の研究者やエンジニアが集まりました。 近年の大規模言語モデルの急速な発展もあり、ACL への論文投稿数は大幅に増加しています。 OpenAccept の集計によると、ACL 2026 の投稿数は過去最多となる12,148件でした。 このうち、Main Research Track には2,297件が採択され、採択率は18.91%でした。また、Main Conference には届かなかったものの、意義のある研究成果を掲載する Findings には2,164件が採択され、採択率は17.81%でした。 前年のACL 2025 における投稿数は8,360件であったため、わずか1年間で投稿数が約45%増加したことになります。2024年の4,407件と比較すると、2年間で投稿数は約2.8倍に増えており、自然言語処理研究への関心の高まりと、分野全体の急速な拡大がうかがえます。 学会の雰囲気 サンディエゴ 開催地のサンディエゴは、アメリカ西海岸の南端に位置し、太平洋とメキシコ国境に面した都市です。年間を通して比較的温暖な気候で、海岸や港を中心とした景観でも知られています。 会場 ACL 2026 は、Manchester Grand Hyatt San Diego のカンファレンスフロアを利用して開催されました。独立したコンベンションセンターではなく、大型ホテルの1階から4階にあるホールや会議室が会場となっており、エスカレーターでフロアを移動しながら各セッションに参加する形式でした。 学術交流の中心となっていたのは、特に1階と2階です。1階の Grand Hall では大規模なポスターセッションが行われ、周辺には受付や企業ブースが設置されていました。2階の Harbor Ballroom では Keynote や全体セッションが開催され、その周辺にも Oral Session や研究交流のためのスペースが配置されていました。 ポスター会場 ポスターセッションでは、発表者と参加者の距離が近く、一つの研究について長時間議論する場面も多く見られました。 Social Event ACL 2026 の Social Event は、会場ホテルから海沿いを歩いた場所にある USS Midway Museum で開催されました。 USS Midway は、かつてアメリカ海軍で運用されていた航空母艦で、現在は San Diego Bay に停泊する博物館として公開されています。 Social Event は7月6日の夕方から開催され、参加者は実際の空母の内部や飛行甲板を見学しながら交流することができました。 私たちの論文 概要 今回、私たちは ACL 2026 Findings に採択された論文 “BiCSRouter: Bi-Level Cross-System Routing for Utility-Aware LLM Inference” を発表しました。 LLM を用いた推論では、一つのモデルが集中的に思考する Single-Agent System と、複数のモデルが協力する Multi-Agent System のどちらを利用するかが、回答性能や推論に大きく影響します。しかし、すべての問題に対して同じシステムを使用することが、常に最適とは限りません。 そこで本研究では、Single-Agent の集中的な推論能力と、Multi-Agent の広範な協調能力を活用するための Bi-Level Routing を提案しました。 第1段階の Intra-Regime Routing では、それぞれのシステム内部で使用する LLM や推論方法、Agent 構成を選択します。続く Inter-Regime Routing では、予測される性能と Cost に基づき、Single-Agent と Multi-Agent のどちらを使用するかを決定します。 これにより、タスクごとに適切な推論構成を選び、回答性能と API Cost のバランスを取ることを目指しています。 実験結果 実験では、Coding Task としてMBPP、数学推論 Task として MATH を使用しました。また、Single-Agent、固定構成の Multi-Agent System、既存の Adaptive Routing 手法と比較しました。 実験結果について、精度、Performance–Cost Balance の順で紹介します。 1. 精度について BiCSRouter は、MBPP で89.40%の Pass@1、MATH で90.37%の Accuracy を達成し、比較した実用的な Routing 手法の中で最も高い性能となりました。 MBPP では、Adaptive Routing 手法の平均を8.99ポイント上回りました。また、Intra-Regime Routing のみを行う MasRouter を5.4ポイント、Inter-Regime Routing のみを行う RaterLLM を9.2ポイント上回りました。 この結果から、各 System 内部の Configuration を選択する Intra-Regime Routing と、Single-Agent・Multi-Agent を選択する Inter-Regime Routing の両方を行うことが、性能向上に有効であることが分かりました。 2. Performance–Cost Balance について BiCSRouter は、MBPP において、実用的な Baseline の中で最も優れた Pareto-optimal な結果を達成しました。 最高性能の Reference である GPT-5 CoT と比較すると、MBPP では精度低下を2ポイントに抑えながら、推論Cost を46%削減しました。MATH でも、精度低下を1.34ポイントに抑えながら、Cost を25%削減しています。 総括すると、BiCSRouter は単に高い精度を達成するだけでなく、問題に応じて Single-Agent と Multi-Agent を適切に使い分けることで、性能と推論 Cost のバランスを改善できることが確認されました。 ポスター発表と Q&A ポスターセッションでは、約1時間半にわたって発表を行いました。多くの方に研究を紹介し、ルーターの設計やコスト計算、実環境への応用について幅広い質問やフィードバックをいただきました。 以下では、発表中にいただいた主な質問と、実際に行った議論を紹介します。 なぜ Single-Agent と Multi-Agent を組み合わせるのか 参加者： 「まず、この研究のモチベーションを簡単に教えてください。」 私： 「Single-Agent には、一つのモデルが集中的に推論できる強みがあります。一方、Multi-Agent には、複数のモデルが異なる観点から協調できる強みがあります。 ただし、すべての問題に対して常に同じシステムを使うことが最適とは限りません。そこで本研究では、問題ごとに両者を使い分ける Bi-Level Routing を設計しました。」 Configuration とは何を表すのか 参加者： 「Intra-Regime Routing で選択する “Configuration” とは、具体的に何を指しますか？」 私： 「一つの Query に回答するために必要な構成全体を指します。 Single-Agent の場合は、使用する LLM と推論戦略が含まれます。Multi-Agent の場合は、各 Agent の役割、トポロジー、使用する LLM などが含まれます。そのため、二つの Regime では Configuration の意味が少し異なります。」 Router 自体も LLM なのか 参加者： 「Router はどのようにモデルを選択するのですか。Router 自体も LLM なのでしょうか？」 私： 「今回の Router は LLM ではなく、軽量な MLP です。 まず、Query と各モデルの Description を Embedding し、Intra-Regime Routing によって各システム内部の Configuration を選択します。その後、選択された Configuration に対する予測性能と Cost を推定し、Utility に基づいて Single-Agent と Multi-Agent のどちらを使うか決定します。」 参加者： 「つまり、LLM に Routing Option を直接生成させているわけではないのですね。私はそれに近い研究をしています。」 私： 「はい、その通りです。私たちも Llama-3B-Instruct のような軽量 LLM を Meta-Controller として使う方法を検討しました。 ただし、LLM による Routing は Latency が大きく、特に小規模モデルでは指示追従や出力形式が不安定でした。一方で、LLM Router 自体は非常に興味深い研究方向だと思います。」 Latency は考慮したのか 参加者： 「私たちも Single-Agent と Multi-Agent の選択を研究していますが、特に Latency を重視しています。この点は検討しましたか？」 私： 「Latency は実用上とても重要で、初期段階では私たちも検討しました。 しかし、Cost と Latency を同時に Penalty として扱うと、最適化が難しくなります。また、Latency は API プラットフォームや通信状況による変動が大きく、公平な評価も簡単ではありません。そのため、今回は主に性能と API Cost に焦点を当てました。」 この方からは、関連研究である Multi-Agent Reasoning Improves Compute Efficiency: Pareto-Optimal Test-Time Scaling も紹介していただきました。同じ問題を異なる観点から研究している方と、その場で意見交換できたことが特に印象に残っています。 Cost と Prompt Cache 参加者： 「Cost はどのように計算していますか？」 私： 「Closed-Source Model については、実際の Input・Output Token 数に、それぞれの API 単価を掛けて計算しています。」 参加者： 「Prompt Cache は考慮していますか？Cache Hit によって実際の料金は大きく変わると思います。」 私： 「今回は明示的には考慮していません。とても重要な指摘だと思います。より現実的で公平な Cost Modeling を行うために、今後検討すべき要素だと考えています。」 新しい Model や System にも拡張できるのか 参加者： 「新しい Model や、Single-Agent・Multi-Agent 以外の System にも拡張できますか？」 私： 「新しい Model を追加する場合は、Model Description と学習データを追加し、Router を再学習することで対応できます。 新しい Regime を追加することも可能で、論文中では追加の System を含む探索的な実験も行っています。ただし、Regime が増えると探索空間が急激に大きくなり、Policy の収束も難しくなります。そのため、現時点では特徴の異なる二つの System を丁寧に組み合わせる設計が効果的だと考えています。」 Dataset と学習 参加者： 「どのような Dataset で評価しましたか？」 私： 「Coding の MBPP、数学推論の MATH、自然言語理解の MMLU など、性質の異なるタスクを使用しました。」 参加者： 「MATH や MMLU は規模が大きいですが、学習コストはどのように抑えましたか？」 私： 「大規模な Dataset については、先行研究に従って代表的な Subset を使用しました。例えば MATH では、異なる難易度から問題を抽出し、Dataset 全体の構成をできるだけ保つようにしています。一方、比較的小規模な MBPP については、全 Dataset を使用しました。」 ピックアップ ここでは、私が気になった論文をピックアップして紹介します。 Causal2Vec: Improving Decoder-only LLMs as Embedding Models through a Contextual Token Decoder-only LLM を Embedding Model として活用 軽量な BERT-style Model で入力文を Contextual Token に圧縮 LLM の構造や Causal Attention を変更せず、文全体の情報を各 Token に提供 Contextual Tokenと EOS Token を結合し、Last-token Pooling の Recency Bias を軽減 公開 Retrieval Dataset のみを用いたモデルとして、MTEB で SOTA を達成 AgentRouter: A Knowledge-Graph-Guided LLM Router for Collaborative Multi-Agent Question Answering Query に応じて適切な Agent 構成を選択する Routing Framework Query、Context 内の Entity、候補 Agent を Heterogeneous Knowledge Graph として表現 GNN を用いて各 Agent への Routing Distribution を予測 複数 Agent の出力を重み付けして統合 私たちの BiCSRouter とも関連が深く、Agent 間の相補性を活用する設計が興味深い DRPG: Decompose, Retrieve, Plan, Generate — An Agentic Framework for Academic Rebuttal Academic Rebuttal の作成を支援する Agentic Framework Reviewer Comment の分解、Evidence 検索、回答方針の計画、回答生成の4段階で構成 Planner は回答方針の選択で98%以上の精度を達成 8B Model のみで既存手法や平均的な人間の Performance を上回る 研究者にとって身近な Rebuttal 作業への応用が印象的 おわりに 本記事では、ACL 2026 の雰囲気や、私たちの研究、ポスター発表での議論、気になった論文を紹介しました。 自分たちの研究を直接説明し、近いテーマに取り組む研究者からフィードバックをいただけたことは、非常に貴重な経験でした。 最後になりますが、トレーナーの村田さん、研究に協力いただいた AI Lab の本多さんをはじめ、本研究および学会参加を支援してくださった皆様に感謝いたします。 投稿 ACL 2026 参加報告 は 株式会社AI Shift に最初に表示されました。

「QA」と名のつくチームに配属されたのに、やっていることはテストと不具合報告……そんな経験はないでしょうか。 自分は開発エンジニアから第三者検証会社を経て、現在はビットキーで品質戦略を担当しています。キャリアの中で「QA」を名乗る現場をいくつも見てきましたが、その多くで感じたのは違和感でした。QAと言いながら、やっていることはテストではないか。では「QA」とは本来何なのか。 この記事は、2026年5月に開催された勉強会「AI時代に、品質エンジニアとして何者になるか」での登壇内容をベースに書いたものです。 第三者検証時代の違和感 第三者検証会社に入り、「QAを行う案件」にアサインされた

～生成AIエージェント時代に知っておきたい「知識のデータモデリング」の本質～ はじめに 「チャンク分割が重要です。」 最近、この言葉を耳にする機会が本当に増えました。技術イベントの登壇でも、AIベンダーの提案セミナーでも、生成AIの解説記事でも、まるで業界の合言葉であるかのように当たり前に使われています。 しかし、私は時々、ふと立ち止まって考えてしまうのです。 「私たちは、この『チャンク』という言葉の持つ本当の重みを、どれほど理解できているのだろうか」と。 文章を機械的に300文字ごとに区切れば、それが優れたチャンクなのでしょうか。 機械的にオーバーラップを20%入れておけば、そ