開発・実装
5件 / 元の本文を表示
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の利用量まで自動集計するものではありません。