AIの最前線を、
毎日5分で。

まず大きかったのは、開発の土台に入る危険が見つかったこと

• Pythonでよく使われるLiteLLMの一部の版に、起動時に勝手に動いて情報を集める仕組みが紛れ込みました。[1]
• これにより、鍵のような大事な情報や、クラウドの設定、作業用の秘密情報まで抜き取られるおそれがありました。[1]
• しかも、LiteLLMを土台にした多くの道具や仕組みに広く影響する可能性があるため、単体の問題では終わりません。[1]
• 記事では、複数の会社の鍵をあちこちに散らすより、できるだけ少ない入口にまとめる考え方が勧められていました。[1]

AIを作る流れでは、「速さ」と「安全」のぶつかり合いがはっきりした

• AIがコードを書く場面では、速く作れる反面、危ない部分も一緒に出やすいことが改めて示されました。[2]
• 特に目立つのは、本来止めるべき処理が抜けることや、見えてはいけない部分が外に出ることです。[2]
• こうした問題は、見た目のミスよりも、判断の抜けや確認不足として起きるため、表面だけのチェックでは見つけにくいとされています。[2]

安全性の確認は、作る前から運用中まで続ける方向へ進んでいる

• Inspect AI、Garak、PyRIT、DeepEval を組み合わせて、作成前の確認から、わざと難しい質問を投げる検証、本番での見張りまでをつなげる方法が紹介されました。[8]
• ただし、何でも拒否すればよいわけではないことも強調されました。安全な質問まで断ると、使いにくいAIになってしまうためです。[8]

使う側の体験も大きく変わりつつある

• Googleは、古い知識のままではうまく動かない場面に対し、最新の使い方の手がかりを与えて、コード作成を助ける仕組みを示しました。[9]
• OllamaとOpenHands CLIを使って、仕様書を渡すだけで簡単な画面アプリを作る流れも紹介され、AIに「作業の段取り」を任せる方向が強まっています。[12]
• MCPの紹介では、AIが自分でファイルや外部の道具を扱えるようにする標準的なやり方が広がっていることがわかります。[13]

音声やローカル利用では、個人向けの新しい使い方が増えた

• Gemini Live APIを使い、話しながら助言してくれるプレゼン補助ツールが作られました。[6]
• AMDは、端末の中で動くAIを扱いやすくする、プライバシー重視の画面を出しました。[11]
• Sunoは、自分の声や好みに合わせて、より細かく音楽を作れる方向に進みました。[4]

まずは「AIは速いが、雑にもなりうる」と考える

• AIは作業を早くしますが、速さの裏で見落としも増えます。[2]
• だから、AIを答えを出す機械ではなく、たたき台を作る相棒として使うのが安全です。

情報の置き場所を減らす

• いろいろな場所に鍵や秘密を書き散らすほど、問題が起きたときの被害は大きくなります。[1]
• 一般の人でも、会員登録、仕事用、試用用の情報をできるだけ分け、不要な登録情報は減らす意識が役に立ちます。

AIの「うなずきやすさ」を前提にする

• AIは、気持ちよく受け答えする一方で、間違いを強く止めないことがあります。[3]
• 重要な相談ほど、AIの返答をそのまま採用せず、別の人や別の情報源で確認する習慣が大切です。

使い道を「作業の代行」ではなく「準備の短縮」に置く

• いきなり全部を任せるより、調べ物、下書き、整理、比較のような場面で使うと失敗しにくいです。[12][6]
• AIに向くのは、面倒な下ごしらえを短くすることです。

ローカルで動くAIは、安心材料になりやすい

• 端末の中で完結する道具は、外に出したくない内容を扱うときに安心しやすいです。[11]
• ただし、安心できるからこそ、設定や保存先の管理は丁寧にする必要があります。

便利さより、確認の手間を少し残す

• AIは早く進めてくれますが、最後に一度立ち止まるだけで、失敗をかなり減らせます。[8]
• そのひと手間が、後からの大きな手戻りを防ぎます。