AI・LLMの最新ニュースを毎朝日本語でまとめてお届けします
Model Context Protocolの新仕様(2026-07-28版)が公開され、サーバー側で持っていたセッションIDの仕組みがなくなりました。これまでリモートMCPサーバーを複数台に並べると、別のサーバーが発行したセッションIDを受け取って処理できない問題がありました。そのためスティッキーセッションや共有のセッションストアで回避する必要がありました。新仕様ではこうした工夫が要らなくなり、通常のHTTPサービスと同じ感覚で負荷分散できます。MCPサーバーを運用している人は、移行の要否を確認しておく必要があります。
Appleは、macOSの「フルディスクアクセス」権限を与える手順に、明示的な操作や追加の制御を加える方針を発表しました。AIエージェントが自律的に動くようになり、データ流出のリスクが大きく増えたことを理由に挙げています。MetaのMuseがメッセージデータを監視していた件をめぐる議論も背景にあります。Mac上でコーディングエージェントやローカル自動化ツールを使っている人は、権限の与え方やセットアップ手順が変わる可能性があります。
Simon Willison氏は、従量課金のAPIやサービスに「月X ドルを超えたら止めてエラーを返す」というハード上限を、最初から有効にしておくべきだと主張しています。上限に近づいたら警告メールを送るだけのソフト上限では足りない、というのが同氏の考えです。理由は、コーディングエージェントのおかげで有料APIを呼ぶコードを誰でもすぐ動かせるようになり、思わぬ請求が起きやすくなったことです。エージェントに有料APIの鍵を渡しているなら、使っているサービスで支出を強制的に止められるかを今のうちに確認しておくべきです。
主要モデルの公開に合わせて出る安全性報告書の執筆を統括していたDavid Robinson氏が、OpenAIを退社しました。同氏はThe Atlanticに寄稿し、同社の文化が壊れていると訴えています。寄稿では、今の反復型の開発は失敗が起きることを前提にしており、モデルの能力が上がるほどリスクも大きくなると指摘しました。そのうえで、原子力や航空分野の安全管理の知見を取り入れることや、人が監視していない状態での安全性を確かめる新しい科学を作ることを求めています。OpenAIの安全性評価を判断材料にしている企業にとっては、評価プロセスそのものへの内部からの疑問として読む価値があります。
2026年10月1日、Josh Hawley上院議員(共和党)とChris Murphy上院議員(民主党)が「AI Agent Accountability Act」を発表しました。このZennの記事によると、法案はAIエージェントの法的責任を、エージェントを動かす「操作者(Operator)」と作る「開発者(Developer)」に分けて問う形になっています。筆者は自分の自動投稿パイプラインで両方の役割を担っている人間を数え、答えが1人だったことを紹介しています。個人でエージェントを作って自分で動かす開発者は、両方の責任を一人で負う可能性がある、という問題提起です。
Metaは「Muse Gadgets」を発表し、ESP32やRaspberry Pi向けのSDKをGitHubでオープンソースとして公開しました。自作したデバイスや家電を、パーソナルAIの「Muse」とつなげられるようになります。また、自作機器と連携させる専用デバイス「Muse Home Link」を、米国の有料会員には無償で配ります。Museはメッセージデータの監視をめぐって批判も受けているため、連携させる際は権限の設計にも注意が要ります。
Anthropicは10月2日、企業でClaudeの導入を主導できるエンジニアを育てる「Claude Frontier Academy」を立ち上げました。1億ドルを投じ、2027年末までに「Frontier Deployed Engineer」を1万人育てる計画です。研修は医師の研修医制度を手本にした実地型で、最初の受講者はサンフランシスコ、ニューヨーク、ロンドンで研修を受けています。モデルの性能だけでなく、企業への導入を支える人材の量もベンダー間の競争軸になってきています。
InfoQの講演で、DoorDashのエンジニアが社内向け生成AIプラットフォームを作ってきた経緯を紹介しました。はじめは外部ベンダーのモデルに頼っていましたが、オープンウェイトモデルへ移行しています。講演では、LLMやエージェントの利用を仲介するゲートウェイの設計や、5,000人を超える社内ユーザーに向けて精度・レイテンシ・コストをどう両立させたかが語られました。社内でLLM基盤を内製するか迷っている組織には、具体的な判断材料になります。
9月30日に公開された推論エンジンMagnitudeは、llama.cppより最大2倍速いとうたっています。筆者が16GBのM5 Macで同じGGUFモデルを動かして比べたところ、生成速度はMagnitude 0.2.4が毎秒88.9〜97.0トークンでした。llama.cppは最新版で毎秒103.7〜105.1トークンと、逆の結果になりました。測定は筆者の環境1つだけのものですが、ローカルLLMの実行環境を乗り換える前に、自分のハードウェアで測り直す必要があることを示す例です。
Godotでミニゲームを作らせる個人ベンチマークの続編です。指示役の親エージェントにclaude-opus-5-5(medium)を使い、実装を任せる子エージェントをCodex CLI上のgpt-6.1-solに固定しました。そのうえでeffortの段階ごとに性能を測っています。旧版のgpt-6-solや、gpt-6-astraとの違いも比べています。実装を任せるモデルとeffortの組み合わせを選ぶときの参考になりますが、結果は筆者のベンチマーク条件での値です。同じシリーズでgpt-6-lunaの検証記事も出ています。
社内文書を検索して答えるRAGで、退職した担当者の名前が今の担当者のように回答に出てしまう問題がありました。筆者は旧担当者と現担当者の対応表で置き換えようとしましたが、日本語の固有名詞は単純な文字列置換では正しく切り出せず、2日間はまったといいます。最終的に、敬称を手がかりにして置き換える範囲を絞る方法にたどり着きました。元の文書は書き換えずに出力側で直す設計なので、日本語でRAGを運用している人にとっては、そのまま参考にしやすい失敗例です。
申込書の画像をVLMに1枚まるごと渡して読む項目を指定しても、毎回違う列が抜け落ちる問題がありました。筆者はこの方式をやめ、帳票OCRで昔から使われてきた、様式ごとに読み取り位置を事前に登録する方法に戻しました。効果が大きかったのは精度よりも出力の形が毎回同じになることで、後工程で扱いやすくなり、読み漏れのチェックも楽になったといいます。速さや汎用性を手放した代わりに安定性を取った判断として、業務でVLMを使ったOCRを検討している人に参考になります。
