AI・LLM デイリーブリーフィング
2026年10月26日（月）｜日本時間 8:33時点
今日の最重要トピックは、AWSとUC Berkeleyが公開した新しいAIエージェント実行基盤「Infinity」です。
従来のAIエージェントは、外部ツールの応答を待つ間も実行プロセスを保持する構成が一般的でした。Infinityはこの仕組みを変え、8GBのメモリで約75,000エージェントを保持できるという研究結果を公開しています。
また、オープンソースCoding Agent「goose」の機能強化、GitHub CopilotのMicrosoft Teams統合、国産LLMのAPI一般公開にも注目します。
今回は10月23日の公式リリースを中心に、未紹介の重要な更新を5件選びました。週末の10月24〜25日については、大型LLMの新規公開を確認できなかったため、国内の注目リリースを1件補足しています。その項目は発表日を明示し、新着ニュースとは区別します。
1. 【最重要】AWS「Infinity」公開 — 8GBで75,000エージェントを保持する新ランタイム
公開：10月23日｜新OSS・研究プレビュー
Amazon Web ServicesとUC Berkeleyの共同研究プロジェクト「Hydro」が、AIエージェント向けの新しい実行基盤「Infinity」を公開しました。
最大の特徴は、エージェントが外部ツールを呼び出した時点で会話履歴を保存し、実行プロセスを終了できることです。
ツールの処理結果が返ってきたら、保存した状態からエージェントを再開します。
Apache 2.0ライセンスで公開され、AWS Lambdaなどのサーバーレス環境でも動作します。
なぜ重要か
従来のAIエージェントでは、ツール実行中に待機処理が発生します。
例えば、Coding Agentが20分かかるビルドを開始した場合です。
一般的な同期型の実装では、処理の完了を待つためにワーカーや実行環境を保持します。
Infinityでは、待機中のエージェントを会話履歴として永続化し、計算資源を解放できます。
技術・実装ポイント
Infinityは、プログラミング言語の非同期処理で使われる「Stackless Coroutine」の考え方をAIエージェントに応用しています。
textユーザーからの依頼
↓
AIエージェント起動
↓
LLMがツール呼び出し
↓
会話履歴を保存
↓
ツールを非同期実行
↓
エージェントを停止
│
│ 待機中の計算資源を解放
│
↓
ツール結果をキューで受信
↓
会話履歴を復元
↓
エージェント再開AWSが公開した参考アーキテクチャは次の構成です。
| コンポーネント | 役割 |
|---|---|
| AWS Lambda | エージェントの短時間実行 |
| SQS FIFO | イベントとツール結果の配送 |
| Aurora DSQL | 会話履歴の永続化 |
| DynamoDB | 重複イベントの検出 |
| EventBridge Scheduler | 長時間の待機・再開 |
| Amazon Bedrock | LLM推論 |
性能： AWSの合成ベンチマークでは、80,000エージェント、320万回のモデル応答相当を処理し、アイドル状態のエージェント1件当たり約100KBのメモリ使用量を報告しています。
この結果から、8GBで約75,000エージェントを保持できると推定しています。
ただし、これは75,000件のLLM推論を同時実行できるという意味ではありません。
API・実装： Rust製フレームワークで、独自ツール、MCP、非同期イベント、子エージェントに対応します。
料金： Infinity自体は無料のOSSです。Lambda、SQS、Aurora DSQL、Bedrockなどには通常の利用料金が発生します。
利用条件： 現在は初期研究リリース。本番導入には障害復旧、イベントの真正性、セキュリティなどの検証が必要です。
公式情報：AWS技術解説 ／ Infinity公式ドキュメント ／ Lambda実装ガイド
2. オープンソースCoding Agent「goose 1.56」公開 — サブエージェントの並列制御を強化
公開：10月23日｜OSSアップデート
オープンソースAIエージェント「goose」のバージョン1.56.0が公開されました。
今回の更新では、サブエージェントの同時実行数を制限する機能、失敗したサブエージェントの再開、推論レベルの自動調整などが追加されています。
また、OpenAI Responses APIのプロンプトキャッシュを効率的に利用するため、セッションIDをキャッシュキーとして送信する改善も行われました。
なぜ重要か
複数のCoding Agentを並列実行すると、API利用量やツール呼び出しが急増する可能性があります。
今回の更新は、サブエージェントの並列数と推論コストを管理するための実用的な改善です。
開発者が見るべきポイント
新しい並列数制限：
bashexport GOOSE_MAX_CONCURRENT_SUBAGENTS=4この環境変数により、同時実行するサブエージェント数を制限できます。
その他の主な変更点は次のとおりです。
| 機能 | 内容 |
|---|---|
| 自動推論レベル | モデルの推論設定を自動調整 |
| サブエージェント再開 | 失敗・キャンセル後の再開 |
| 並列数制限 | 同時実行数の上限設定 |
| キャッシュ料金 | プロバイダー固有の料金設定に対応 |
| OpenAI Responses | セッションIDをキャッシュキーとして送信 |
| MCP | ツール名の互換性改善 |
対応モデル： OpenAI、Anthropic、Google、Amazon Bedrock、Ollamaなど、複数のプロバイダーを利用できます。
API： gooseはCLI、デスクトップアプリ、組み込み用APIを提供しています。今回の更新は主にエージェントの実行制御と互換性改善です。
料金： goose本体はApache 2.0のOSS。接続するLLMのAPI料金は別途発生します。
利用条件： macOS、Windows、Linuxに対応。機能によっては利用するモデルやプロバイダー側の対応が必要です。
特に注目したいのは、モデルの推論能力だけでなく、エージェントをどう並列実行するかが性能と費用に直結する点です。
公式情報：goose 1.56.0リリースノート ／ goose公式リポジトリ
3. GitHub Copilot、Microsoft TeamsからIssue修正とPR作成が可能に
公開：10月23日｜新機能
GitHubが、Microsoft Teams向けGitHubアプリを更新しました。
TeamsのチャネルやチャットでIssueの通知を受け取り、その会話からCopilotにバグ修正を依頼できます。
CopilotはIssueを調査し、コードを修正してPull Requestを作成します。
これにより、TeamsからGitHubへ移動せずに、開発作業を開始できるようになりました。
なぜ重要か
これまでのCoding Agentは、IDEやGitHub上で起動することが中心でした。
今回の機能は、チーム内のコミュニケーションを、そのままAIエージェントへの作業依頼に変換するものです。
開発者が見るべきポイント
基本的な流れは次のとおりです。
textMicrosoft Teams
↓
GitHub Issue通知
↓
@GitHub で修正依頼
↓
GitHub Copilot
↓
コード調査・修正
↓
Pull Request作成
↓
人間によるレビュー
↓
マージ連携方式： Teams向けGitHubアプリを利用します。
認証： GitHubアカウントとの接続が必要です。
対象： Teamsのチャネル、グループチャット、個人チャット。
API： 今回はTeamsアプリの機能拡張であり、独立した新APIの公開ではありません。
料金： 新機能専用の追加料金は発表されていません。利用するGitHub Copilotの契約や使用量に関する条件は別途確認が必要です。
移行期限： 旧GitHubアプリは2026年11月16日に廃止予定です。
既存のGitHub通知アプリを利用している場合は、新しい統合アプリへの更新が必要になります。
また、PRが作成されたことと、コードの正しさが確認されたことは別です。レビューとCIによる検証は引き続き必要です。
4. 【日本・今月の注目】国産LLM「Sarashina」6モデルを無料APIで公開
公開：10月13日｜国内サービス・未紹介の重要リリース
SB Intuitionsが、国産LLM「Sarashina」をAPIから利用できる無料ベータサービスを公開しています。
今回提供されたのは、文章生成だけでなく、Embedding、Reranking、安全性判定、翻訳などを含む6モデルです。
事前申込は不要で、Googleアカウントによるログインで利用できます。
これは10月13日の発表であり、今日の新着ではありませんが、日本語RAGを構築する開発者にとって実用性が高い未紹介リリースとして取り上げます。
なぜ重要か
一般的なRAGシステムでは、LLM以外にもEmbeddingモデルやRerankerが必要です。
Sarashinaは、これらを日本語向けのモデル群としてまとめて提供しています。
特に、日本語の文書検索システムを無料で試作できる点が魅力です。
開発者が見るべきポイント
| モデル | 用途 |
|---|---|
| Sarashina3 mini | 文章生成・推論 |
| Sarashina3 nano | 軽量な文章生成 |
| Sarashina3 embedding | ベクトル検索 |
| Sarashina3 rerank | 検索結果の再順位付け |
| Sarashina3 guard | 入出力の安全性判定 |
| Sarashina3 translate | 日英・英日翻訳 |
例えば、次のような日本語RAGシステムを構築できます。
text日本語の社内文書
↓
Sarashina3 embedding
↓
ベクトルDB
↓
検索
↓
Sarashina3 rerank
↓
関連文書を選別
↓
Sarashina3 mini
↓
回答生成
↓
Sarashina3 guard
↓
安全性判定API： 6モデルを呼び出せるAPIを一般公開。
料金： ベータ期間中は無料。終了時期は未定です。
利用制限： レート制限があります。
データ保護： ベータ版では、サービス改善を目的として利用データが活用される場合があります。
そのため、顧客の機密データや非公開ソースコードを投入する場合は、利用規約とデータの取り扱いを確認する必要があります。
5. GitHub Copilot、OpenCode・Claude Code・Codexのモデル利用状況をAPIで取得可能に
公開：10月23日｜API機能拡張
GitHubがCopilot Usage Metrics APIを拡張しました。
今回の更新では、Copilotをモデルプロバイダーとして利用する外部ツールについても、リクエスト数やトークン消費量を集計できるようになりました。
対象にはOpenCode、Claude Code、Codex、Zedなどが含まれます。
さらに、モデルがユーザーによって選択されたのか、自動選択されたのかを区別する情報も取得できます。
なぜ重要か
Coding Agentを複数導入すると、どのツールがどれだけモデルを利用しているのか把握しにくくなります。
今回の機能により、Coding Agentごとのモデル利用状況を共通のAPIから取得し、比較できるようになります。
開発者が見るべきポイント
新しい集計フィールドはtotals_by_clientです。
主なデータ構造は次のとおりです。
| フィールド | 内容 |
|---|---|
client | 利用したツール |
request_count | 成功したモデル呼び出し数 |
session_count | セッション数 |
token_usage | 入出力トークン消費量 |
totals_by_model | モデル別の利用量 |
model_selection_mode | モデルの選択方式 |
対応クライアント： OpenCode、Claude Code、Codex、Copilot CLI、VS Code、JetBrainsなど。
API： Enterprise・Organizationの1日・28日単位の利用状況レポートに対応。
認証・権限： Enterprise Owner、Organization Owner、Billing Manager、または所定のCopilot Metrics閲覧権限が必要です。
料金： 今回のAPI拡張に伴う追加料金は発表されていません。Copilot契約は必要です。
制限： request_countはユーザーのプロンプト数ではなく、モデル呼び出し回数です。1回のプロンプトから複数回のモデル呼び出しが発生することがあります。
また、clientはクライアントが送信する識別情報に基づくため、厳密な本人確認済みクライアントIDではありません。
なお、今回のメトリクスはCopilot経由のモデル利用が対象です。各ツールから直接契約した外部APIの利用量まで自動集計するものではありません。
今日いちばん注目すべき1件
AWS「Infinity」— AIエージェントの実行方式を変える可能性
今日の5件では、Infinityの公開を最も重要と考えます。
理由は、AIエージェントの長時間実行における、根本的なアーキテクチャの問題に取り組んでいるからです。
特に注目したいのは、AIエージェントを常時動作するプロセスではなく、イベントに応じて再開される状態機械として扱う設計です。
この考え方は、AWS Step FunctionsやEventBridgeを使用したイベント駆動アーキテクチャにも通じます。
AWS開発者としての注目ポイント
Infinityの設計では、次の3つが重要になります。
1. 実行状態の永続化
会話履歴や処理状態を保存することで、特定のLambdaインスタンスに依存しない構成を実現します。
2. イベント駆動による再開
外部ツールの完了、ユーザーからの追加指示、子エージェントからの報告などをイベントとして受信し、処理を再開します。
3. 待機時間と計算時間の分離
長時間の外部処理を待つためだけに、Lambdaなどの実行環境を保持する必要がなくなります。
ただし、実際のシステムでは会話履歴の保存・取得、メッセージ配送、LLM推論などのコストが残ります。必ずしも従来構成より安価になるとは限りません。
今後のAIエージェント設計への影響
従来のAIエージェントは、次のような構成が中心でした。
textAgent起動
↓
LLM推論
↓
Tool Call
↓
待機
↓
LLM推論
↓
Tool Call
↓
待機
↓
終了Infinityは、これを次のような構成へ変えます。
textイベント発生
↓
Agent起動
↓
状態を復元
↓
LLM推論
↓
Tool Call
↓
状態を保存
↓
Agent停止
── 待機 ──
Tool完了イベント
↓
Agent再起動
↓
処理を継続これは単なる高速化ではありません。
AIエージェントを数千、数万単位で運用するための、実行基盤そのものの再設計です。
現時点では研究プレビューですが、AWS Lambda、SQS、DynamoDB、Aurora DSQLを利用する構成が具体的に公開されているため、AWSを扱う開発者にとって検証価値の高い技術です。
今日の結論： AIエージェント開発では、モデルの性能やトークン単価だけでなく、エージェントの状態管理、非同期実行、待機時間の削減、障害からの再開が、今後さらに重要になります。
Infinityは、その方向性を具体的なOSS実装として示した注目のリリースです。