9月19日正午のまとめ。この時間帯の関心はローカルLLMの「実用速度」に集まっていた。オープンソースの推論エンジン「Inco Splash」が、Qwen3.8-27BをM5 Max搭載のMacBook Proで144 tok/sで動かすと発表した。2枚のRTX 3090でコーディングエージェントを回す実運用のチューニング記事も注目を集め、1ターンあたりの平均待ち時間を28秒から7秒まで縮めた設定が共有されている。開発ツール周りも小粒ながら動きがあり、Claude CodeがAGENTS.mdに対応したほか、Codexのモデルの選び方やエージェント間連携プロトコル「A2A」の解説記事がQiitaに並んだ。

Qwen3.8-27Bを144 tok/sで──Apple Silicon向け新エンジン「Inco Splash」

RedditのLocalLLaMAコミュニティで、Apple Silicon向けのオープンソース推論エンジン「Inco Splash」が注目を集めている。Qwen3.8-27BをM5 Max搭載のMacBook Proで144 tok/s（トークン毎秒）で動かすというもので、エンジン自体がこのモデルとApple Siliconの双方に合わせて作られている。開発側の発表では、デコード速度はOllamaの最大3倍、oMLXの2倍で、エージェントがサブエージェントへ処理を振る場面では4倍近くになるという。

動作要件はM3以降のApple Silicon、macOS 26.4以降、36GB以上のメモリ。導入はHomebrewから brew install incoai/tap/splash で行い、splash serve --model incoai/Qwen3.8-27B-Splash で起動する。Claude Code、OpenCode、Codex、Hermesなどのコーディングエージェントからそのまま参照する使い方を想定しており、LM Studioのアプリ内からも同じエンジンを利用できる。

数値は開発側の発表ベースで、独立した検証はこれからだ。ただ、27B級のモデルをローカルでエージェント用途に耐える速度で動かす選択肢が増えるのは確かだ。昼の記事で取り上げた64GB Macでのエキスパート・ストリーミングと同じく、「Macで実用速度のローカルLLM」という方向性がさらに厚みを増した形と言える。

2枚のRTX 3090でコーディングエージェント──待ち時間28秒→7秒のチューニング

ローカルLLMをコーディングエージェントに使う際のネックは、モデルの生成速度よりもエージェントの動かし方にあることがある。Redditに投稿された実践記では、オープンソースのコーディングエージェント「Oh My Pi」（OMP）とvLLMを2枚のRTX 3090で動かし、1ターンあたりの平均待ち時間を28秒から7秒まで短縮したという。

効いたのは主にエージェント側の設定だ。明示しないロールにはeffortレベルのデフォルト（xhigh）が効いてしまうため、すべてのロールでレベルを明示したこと、思考トークンの予算を7,500に制限したこと、出力上限を8kから32kへ引き上げたこと（ファイル書き込みが途切れるのを防ぐ）、10KBを超えるツール出力をファイルに退避したこと、サブエージェントを最大4つに絞りappendOnlyContextを有効化したこと――これらの積み重ねで体感速度が約4倍になった。詳細は投稿者のブログ記事にもまとめられている。

モデルそのものを買い替える以外に、運用側の設定でここまで改善できるという実例は参考になる。ローカル環境でエージェントを回して「遅い」と感じたら、ハードウェアの前に設定の切り詰めどころを見直す価値がありそうだ。

Claude CodeがAGENTS.mdを読むようになった──ただし初回セッションでは読まれない

Claude Codeのバージョン2.1.277（2026年9月18日付）のchangelogに、AGENTS.mdサポートの追加が記載された。Qiitaの解説記事によると、プロジェクトにCLAUDE.mdが存在しない場合にClaude CodeがAGENTS.mdを読むようになるというものだ。AGENTS.mdは複数のエージェントツールで共通利用されつつある指示ファイルで、Claude Code専用のCLAUDE.mdとの二重管理を避けたいケースで意味がある。

ただし記事の著者による検証では、プロジェクトの1回目のセッションでは読み込まれないという。移行する場合は、最初のセッションで指示が効いていなくても、すぐファイル側の問題と決めつけない方がよさそうだ。

Codexのモデルはどう選ぶか──Astra・Sol・Terraの使い分け

OpenAIのコーディングエージェント「Codex」で新しいタスクを作ろうとすると、Astra・Sol・Terraという3つのモデルが並ぶ。Qiitaに投稿されたガイドは、この3つの使い分けを整理したもので、「ClaudeのFable・Opus・Sonnetの使い分けはわかったが、Codexは全然わからん」という開発者の疑問に答える形で書かれている。

このブログでも昨日、法律業務向けの特化モデルとしてのAstraを取り上げたばかりだ。OpenAIのモデル体系はコーディング用途でも複線化しており、用途に応じた選択が開発者側に求められている。

MCPの先をつなぐ──Google発のエージェント間連携プロトコル「A2A」

エージェントが企業内のあちこちで使われるようになると、次の課題はエージェント同士の連携になる。Qiitaの解説記事は、Google発のオープンプロトコル「A2A（Agent2Agent）」の仕組みを整理したものだ。

ベンダーもフレームワークも違うエージェント同士は、そのままでは対話できない。MCPがモデル（エージェント）とツールやデータの接続を担うのに対し、A2Aはエージェント同士の協調を担う位置づけで、記事ではGemini Enterpriseの文脈で両者の関係やプロトコルの構造が説明されている。エージェントの数が増えるほど「つなぎ方」の標準は効いてくる。導入を検討する段階の企業では、MCPとA2Aの役割分担を押さえておく意味がありそうだ。

AI「Tilly Norwood」のプレスツアーは順調とは言えない

海外では、Tilly NorwoodというAIが報道各社を回るプレスツアーを行っている。TechCrunchの報じるところによると、ツアーの受けは思わしくない。特に奇妙だった一場面では、インタビューの最中に誤作動を起こしたように見え、中国語を話し始めたという。

人間の宣伝活動と同じ形式をAIが回ることへの皮肉が効いた記事だ。AIパーソナリティの報道対応はまだ始まったばかりで、何を根拠に話しているのか検証しにくい点は、取材する側・読む側の双方にとって今後もつきまとう問題になりそうだ。