マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20251110
Description
関連リンク
新人エンジニアの皆さん、こんにちは!今回は、AIの頭脳であるLLM(大規模言語モデル)を効率的に使うための大事な話、「コンテキスト圧迫」という課題とその解決策について解説します。
AIエージェントが様々なツールを使う際に役立つ「MCP (Model Context Protocol)」という技術が普及するにつれて、一つの問題が浮上しました。それは、AIが必要な情報(コンテキスト)を受け取りすぎて、かえって混乱したり、大事な情報を見落としたりする「コンテキスト圧迫」です。人間も大量の情報に触れると疲れるように、AIも情報の量が増えすぎると「コンテキストの腐敗(Context Rot)」という現象で、情報処理能力が落ちることが研究で分かっています。
この問題は、多くのMCPツールが、AIが使う可能性のあるすべてのツール定義を最初にまとめてAIに渡してしまう設計にあるためです。例えば、10~20個のツールがあるうち、実際にAIがそのタスクで使うのはごく一部ということも珍しくありません。これでは、AIの限られた「思考スペース(コンテキストウィンドウ)」が無駄な情報でいっぱいになり、処理効率が落ちてしまいます。
この問題を解決するために、主に二つのアプローチが考えられています。
1. Progressive disclosure(段階的開示):
これは「必要なときに、必要な情報だけを渡す」という考え方です。Anthropic社の「Claude Skills」がその良い例です。AIエージェントは最初、ツールの名前と簡単な説明だけを受け取り、実際にそのツールが必要だと判断したときに初めて、詳しい使い方を読み込みます。これにより、AIの思考スペースを常に最小限に保ち、効率的な判断を促します。
2. MCPにコードを実行させる方法:
この方法では、AIが直接ツールを呼び出すのではなく、TypeScriptなどの「コード」を生成して実行させます。Cloudflare社の「Code Mode」やAnthropic社の提案する手法などがこれに当たります。AIはツールのAPIを呼び出すコードを自分で書き、実行することで、必要な処理を行います。このアプローチのメリットは、AIが複数のツールを組み合わせて複雑な処理を行ったり、不要な中間結果をコンテキストに含めずに処理を完結させたりできる点です。例えば、Sentry社の「エージェントモード」のように、AIに「use_sentry」という一つの汎用ツールだけを与え、そのツール内でさらにAIエージェントが具体的な機能を呼び出す、というアプローチもあります。これにより、AIが最初から大量のツール定義を読む必要がなくなり、コンテキストを効率的に使えます。
これらの解決策は、AIエージェントがもっと賢く、効率的にタスクをこなせるようになるための重要な進化です。AIの開発現場で直面する可能性のあるコンテキストの問題を理解し、その解決策を知ることは、より良いAIシステムを構築する上で非常に役立つでしょう。AIがどのように情報を処理し、どんな課題があるのかを知ることで、これからの開発に活かしてください!
引用元: https://azukiazusa.dev/blog/mcp-tool-context-overflow/
この記事では、OpenAIが先日部分的にリリースした新しい大規模言語モデル「GPT-5-Codex-Mini」へのユニークなアプローチが紹介されています。このモデルは「GPT-5-Codex」の小型版で、現時点ではOpenAIの公式CLIツール「Codex CLI」やVS Code拡張機能を通じてのみ利用でき、直接APIにアクセスすることはできません。
筆者は、この新しいモデルに直接プロンプトを送りたいと考え、Codex CLIツールをリバースエンジニアリング(解析して仕組みを調べること)することに挑戦しました。Codex CLIがApache 2.0ライセンスのオープンソースであることに着目し、そのコードを改造して、モデルに直接プロンプトを送れる独自のコマンドを追加するという方法をとりました。
開発プロセスで驚くべき点は、筆者がRustというプログラミング言語のコードをほとんど書かず、その改造作業のほとんどをAIエージェントであるCodex自身に任せたことです。筆者は「codex prompt」という新しいサブコマンド(プロンプトを直接モデルに送る機能)の設計を指示し、Codex(AI)は、その指示に基づいてコードの記述、コンパイル、フォーマット、リンティングまで実行しました。筆者は主に、AIが生成したコードが意図通りに動くかを確認し、エラーが発生した際にはAIに追加の指示を与える役割でした。
開発中には、Codex CLIが利用するプライベートなAPIが特定の「指示(instructions)」を必要とすることや、AIがファイルを編集する機能(ツール実行やワークスペースアクセス)を無効にする必要性など、いくつかの課題に直面しました。これらもAIとの対話を通じて解決し、最終的にモデルが単一のプロンプトに応答するだけのシンプルなコマンドを実装できました。
この改造ツールを使って、筆者は「自転車に乗ったペリカン」のSVG画像を生成するプロンプトを、「GPT-5-Codex」「GPT-5」「GPT-5-Codex-Mini」の各モデルに送りました。結果として、GPT-5-Codex-Miniが生成した画像は「ひどい」出来栄えで、ペリカンも自転車も抽象的な形の集合体となってしまい、期待外れでした。しかし、この試みによって、OpenAIのプライベートAPIエンドポイントや、role="developer"メッセージを通じてシステムプロンプトを渡せる仕組みなど、貴重な技術的知見が得られました。
このブログ記事は、新しいAIモデルへの探求心と、AIエージェントを活用して効率的に開発を進める現代的な手法を示しており、私たちエンジニアが日々進化するテクノロジーにどのように向き合うべきかを示唆しています。
引用元: https://simonwillison.net/2025/Nov/9/gpt-5-codex-mini/
新人エンジニアの皆さん、AIの能力評価は正確に行えていますか?オックスフォード大学主導の研究が、AI(特に大規模言語モデルLLM)の能力や安全性を測る「ベンチマーク」という評価方法に科学的な弱点があることを指摘しました。この研究は、世界42の主要機関の研究者が協力し、445のAIベンチマークを分析した大規模なものです。
研究の主な課題点:
統計的な厳密さの欠如:
評価されたベンチマークのわずか16%しか、モデル間の性能差が偶然ではないことを示す統計的手法を用いていませんでした。これにより、AIが本当に改善されたのか、それともたまたま良い結果が出ただけなのか、判断が難しい状況です。
曖昧な定義:
約半数のベンチマークが「推論能力」や「無害性」といった抽象的な概念を明確に定義しないまま評価しようとしていました。測定したい能力がはっきりしないと、テストが本当にその能力を測れているのか疑問が生じます。
具体例で考えるベンチマークの落とし穴:
- フォーマットと能力の混同: AIが問題の答えを知っていても、特定の複雑な形式で回答できないと低評価になる場合、AIの真の能力が正しく測られていません。
- 「丸暗記」と「理解」の区別: 簡単な計算問題は解けても、少し条件が変わると失敗するAIは、パターンを記憶しているだけで、根本的な理解が不足している可能性があります。
- 結果の過度な一般化: 医療試験で高得点を取ったAIが「医師レベルの専門知識を持つ」と解釈されるのは誤解を招きます。試験と実世界の複雑な能力は異なります。
これらの弱点は、AIシステムの開発や規制において、その能力や安全性について誤った認識を生むリスクがあります。ベンチマークはAIの設計、展開、規制にも影響を与えるため、その信頼性は非常に重要です。
改善のための提言:
研究チームは、より信頼性の高いAIベンチマークを構築するための8つの提言を行っています。主な内容は以下の通りです。
- 測定概念の明確化と分離:
何を測りたいのかを具体的かつ操作可能に定義し、無関係な要素の影響を排除して、その能力のみを評価する。 - 実世界を反映した評価の構築:
テスト項目が実際の利用状況や求められるスキルを適切に代表しているかを確認し、測定対象の範囲を広くカバーする。 - 分析と正当化の強化:
統計的手法を用いて性能差の確実性を報告し、AIが失敗した理由を詳細に分析する(エラー分析)。そして、そのベンチマークが意図した目的を測る上で有効であることを科学的に正当化する。
さらに、研究チームは、ベンチマークの設計原則を評価するための実用的なツール「Construct Validity Checklist」も提供しています。
この研究は、AI開発に携わる私たちエンジニアにとって、より正確で信頼性の高いAIシステムを構築するために不可欠な視点を提供してくれます。AIの評価方法を改善することで、私たちはAI技術の健全な発展に貢献できるでしょう。本論文は2025年12月に開催されるNeurIPS会議で発表予定です。
引用元: https://www.oii.ox.ac.uk/news-events/study-identifies-weaknesses-in-how-ai-systems-are-evaluated/
VOICEVOX:春日部つむぎ





