LLM

Google が 2026年3月に公開した Gemini Embedding 2 は、テキスト・画像・動画・音声・ドキュメントを同一のベクトル空間に埋め込める、初のネイティブマルチモーダル埋め込みモデルだ。RAG パイプラインやマルチモーダル検索を構築する開発者にとって注目すべきモデルとなっている。 主な特徴 ネイティブマルチモーダル対応 従来の埋め込みモデルはテキスト専用か、別モデルで画像を処理する必要があった。Gemini Embedding 2 は全モダリティを 3072次元の統一ベクトル空間 に直接埋め込む。これにより、テキストで検索して関連する画像や動画を取得するといったクロスモーダル検索が自然に実現できる。 対応モダリティと制限: モダリティ 制限 テキスト 最大 8,192 トークン 画像 1リクエストあたり最大 6枚（PNG, JPEG） 動画 最大 120秒（MP4, MOV） 音声 ネイティブ対応（テキスト変換不要） インターリーブ入力にも対応しており、1つのリクエストに画像とテキストを混在させて渡すことができる。 Matryoshka 表現学習（MRL） Matryoshka Representation Learning（マトリョーシカ表現学習）により、重要な意味情報がベクトルの先頭次元に集約される設計になっている。デフォルトの 3,072次元から 1,536 や 768次元に切り詰めても、検索品質の大部分を維持できる。 Google の推奨次元数: 3,072次元：最高品質 1,536次元：高品質（コスト削減向け） 768次元：バランスの良い推奨値 768次元に切り詰めた場合でも、同サイズの固定次元モデルを上回る性能を発揮するとされている。 多言語対応と性能 100以上の言語をサポート MTEB 多言語リーダーボードで 69.9 を記録しトップランク MTEB コード検索でも 84.0 と高スコア 料金 プラン 料金 リアルタイム API $0.20 / 100万トークン バッチ API $0.10 / 100万トークン（50% OFF） OpenAI の text-embedding-3-small（$0.02/100万トークン）と比較すると高価だが、マルチモーダル対応を単一モデルで実現している点が差別化要因となる。 ...

Kali Linux チームが、外部 SaaS に一切依存しない完全ローカルの AI ペンテスト支援環境の構築ガイドを公式ブログで公開した。Ollama でローカル LLM を動かし、MCP（Model Context Protocol）経由で nmap などの Kali ツールを自然言語から操作する構成だ。 構成要素 コンポーネント 役割 アーキテクチャ上の位置づけ Ollama ローカル LLM サーバー。llama.cpp のラッパーとしてモデルのダウンロード・サービングを簡素化 推論エンジン（脳） mcp-kali-server Flask ベースの MCP サーバー（127.0.0.1:5000）。nmap, gobuster, nikto, hydra, sqlmap 等の Kali ツールを MCP 経由で公開 ツールサーバー（手足） 5ire デスクトップ AI アシスタント兼 MCP クライアント。ユーザー入力を LLM に送り、LLM の応答からツール呼び出しを検出し、MCP 経由でツールを実行し、結果を LLM に戻すループを回す AI エージェント（オーケストレーター） この構成で「エージェント」に相当するのは 5ire だ。LLM（Ollama）は推論を担うだけであり、ツールサーバー（mcp-kali-server）は呼ばれるのを待つだけ。ユーザーの意図を解釈し、LLM とツールの間を仲介して自律的にループを回す 5ire こそがエージェントの役割を果たしている。Claude Code に例えると、Ollama は API の向こう側の Claude モデル、mcp-kali-server は MCP サーバー、5ire は Claude Code 本体に相当する。 ...

OpenAI Codex に搭載された SubAgent（サブエージェント）機能が話題になっています。複数の AI エージェントを並列で動かし、複雑なコーディングタスクを群（Swarm）として処理できるこの機能について、技術的な詳細をまとめます。 SubAgent とは何か Codex の SubAgent は、メインのエージェントが複数の専門化されたエージェントを並列でスポーン（生成）し、それぞれの結果を統合するワークフロー機能です。コードベース探索やマルチステップの機能実装など、並列処理が有効なタスクに特に威力を発揮します。 特筆すべきは、サブエージェントからさらにサブエージェントを生成できる（ネスト可能な）点です。これにより、複雑なタスクを再帰的に分解して処理できます。 ビルトインエージェント Codex には3つのビルトインエージェントが用意されています。 エージェント 役割 default 汎用フォールバック worker 実装・修正中心のタスク explorer コードベース探索中心のタスク 主要な設定パラメータ 1 2 3 4 5 6 # ~/.codex/agents/ または .codex/agents/ に TOML 形式で配置 [agents] max_threads = 6 # 並行スレッド上限（デフォルト: 6） max_depth = 1 # ネスト深度上限（デフォルト: 1） job_max_runtime_seconds = 1800 # タイムアウト（デフォルト: 30分） max_depth を増やすことで、サブエージェントからさらにサブエージェントを生成する多段ネストが可能になります。 ...

Google のシニア AI プロダクトマネージャー Shubham Saboo 氏が、OpenClaw エージェントを 40 日間運用した経験から導き出した「マークダウンファイル駆動のエージェント運用スタック」について紹介する。モデルを変えず、蓄積されたマークダウンファイルだけでエージェントが成長していくというアプローチだ。 コアコンセプト：マークダウンファイルが成長エンジン このスタックの最大の特徴は、モデル自体は変わらないという点にある。エージェント間の違いは「蓄積されたマークダウンファイル」にある。データベースもオーケストレーションフレームワークもメッセージキューも不要で、ディスク上のマークダウンファイルがすべてのインテグレーション層として機能する。 3 層スタック構造 エージェントの設計は以下の 3 層で構成される： 1. Identity 層（アイデンティティ） SOUL.md がセッション起動時に毎回読み込まれる。ここにはエージェントの人格、役割、原則、関係性が定義される。 1 2 3 4 # SOUL.md - 役割: プロジェクトマネージャー - 原則: 簡潔さを重視、事実ベースで判断 - 性格: Dwight Schrute 的な徹底さ TV キャラクターの名前をエージェントに付けるのが Saboo 氏のテクニックだ。Claude の学習データにキャラクターの性格が含まれているため、「Dwight Schrute のエネルギーで」と伝えるだけで、徹底的で真剣な仕事ぶりが期待できる。 2. Operations 層（行動ルール） AGENTS.md でセッション起動ルーティンとメモリ管理ルールを定義する。運用開始から約 1 週間後に作成するのが推奨される。 1 2 3 4 # AGENTS.md - セッション開始時: MEMORY.md を読み込む - タスク完了時: 日次ログに記録 - エラー発生時: 修正内容をメモリに追記 3. Knowledge 層（記憶・ログ） MEMORY.md は約 2 週間の運用後に初期化する。日次ログをレビューし、繰り返し発生する修正パターンを恒久的なエントリとして蒸留していく。 ...

OpenClaw で AI エージェントを運用していると、「エージェントが内部で何をしているのか分からない」という課題に直面します。Comet チームが開発した opik-openclaw は、OpenClaw のエージェント動作をトレース・評価・監視できるオブザーバビリティプラグインです。AI の「ブラックボックス」を「ガラスボックス」に変えるツールとして注目されています。 Opik とは Opik は、Comet が開発する Apache 2.0 ライセンスのオープンソース LLM オブザーバビリティプラットフォームです（GitHub で 18,000 以上のスター）。LLM アプリケーションのライフサイクル全体 — 開発・評価・本番監視 — をカバーする統合基盤として設計されています。 Opik の 3 つの柱 1. トレーシング（開発） すべての LLM 呼び出しについて、プロンプト・レスポンス・メタデータ・コスト・レイテンシを詳細に記録します。1 日あたり 4,000 万以上のトレースを処理できるスケーラビリティを持ち、Prompt Playground でプロンプトの実験・比較も可能です。 2. 評価とテスト LLM-as-a-judge によるハルシネーション検出、コンテキスト精度、回答の関連性といった自動評価メトリクスを提供します。データセットを定義して「良い回答とは何か」を基準化し、新バージョンのアプリを自動スコアリングできます。Pytest との統合により CI/CD パイプラインに評価を組み込むことも可能です。 1 2 3 4 5 6 7 8 9 from opik.evaluation.metrics import Hallucination metric = Hallucination() score = metric.score( input="フランスの首都は？", output="パリです。", context=["フランスの首都はパリである。"], ) print(score) # HallucinationResult(score=0.0, reason="...") 3. 本番監視と最適化 ...

OpenClaw を使っていると「AI が裏で何をしているのか分からない」と感じることはありませんか？Comet が開発した opik-openclaw は、OpenClaw のエージェント動作をトレース・可視化するオープンソースプラグインです。AI を「ブラックボックス」から「ガラスボックス」に変えてくれます。 opik-openclaw とは opik-openclaw は、Comet が開発する LLM オブザーバビリティプラットフォーム Opik（GitHub Star 18,000+）の OpenClaw 公式プラグインです。 OpenClaw のエージェントが実行するすべての操作を記録・可視化し、以下の情報をダッシュボードで確認できます。 LLM 呼び出し: 入出力ペア、トークン数、レイテンシ、コスト ツール実行: どのツールが、いつ、どんな引数で呼ばれたか エージェント委譲: サブエージェントへのタスク委譲の流れ 推論プロセス: 最初のメッセージから最終応答までの全会話フロー セットアップ（3 コマンド） 1 2 3 4 5 6 7 8 # 1. プラグインをインストール openclaw plugins install @opik/opik-openclaw # 2. 認証情報を設定 openclaw opik configure # 3. ゲートウェイを再起動 openclaw gateway restart 動作確認は以下のコマンドで行えます。 ...

セキュリティスタートアップ CodeWall の AI エージェントが、マッキンゼーの社内 AI プラットフォーム「Lilli」をわずか2時間で完全突破した。4,650万件のチャット履歴からシステムプロンプトまで、認証なしで読み書き可能だったという。攻撃手法は SQL インジェクション——教科書の1章目に載る古典的な脆弱性だ。 Lilli とは Lilli はマッキンゼーが社内向けに構築した生成 AI プラットフォームで、数万人のコンサルタントが日常的に利用している。戦略立案、M&A 分析、クライアント対応など、機密性の高い業務に活用されていた。 Lilli のアーキテクチャ マッキンゼーは Lilli の技術構成をある程度公開しており、その設計思想と今回の事件のギャップが際立つ。 RAG パイプライン + オーケストレーション層 Lilli のコアは RAG（Retrieval-Augmented Generation）パイプラインだ。40以上のキュレーション済みナレッジソースに10万件超のドキュメント、インタビュー記録、セクター別プレイブックが格納されている。ユーザーのクエリはベクトル埋め込みでマッチングされ、5〜7件の関連文書が引用付きで提示される。四半期あたり約200万クエリを処理する規模だ。 技術スタック LLM: Cohere、OpenAI（Azure 経由）など複数モデルを併用。Microsoft、Google、Nvidia、Anthropic との戦略的パートナーシップ フレームワーク: QuantumBlack の Horizon ツールキット、LangChain、FAISS インフラ: Microsoft Azure（データストレージ・スケーラビリティ） 独自ツール: PowerPoint を85%以上読み取り可能にする独自ドキュメントパーサー 「ゼロトラスト」設計——のはずだった マッキンゼーは Lilli のセキュリティについて、ゼロトラストセキュリティスタック、オンプレミスデータストア、ロールベースアクセス制御（RBAC）、完全な監査ログを備えていると説明していた。しかし実際には、22個の API エンドポイントが認証なしで外部に公開されていた。設計上のセキュリティと実装上のセキュリティの乖離が、今回の事件の根本原因だ。 攻撃の経緯 CodeWall の自律型セキュリティエージェントは、以下の手順で Lilli を攻撃した: 公開 API ドキュメントの発見 — Lilli の API ドキュメントが外部から閲覧可能な状態だった 認証不要エンドポイントの特定 — 22個のエンドポイントが認証なしでアクセス可能だった SQL インジェクションの検出 — ユーザー検索クエリを書き込むエンドポイントで、JSON のキー名が SQL 文に直接連結されていた 本番データベースへのフルアクセス — 読み取りと書き込みの両方が可能な状態に到達 人間の介入は一切なし。AI エージェントが自律的に脆弱性を発見し、エクスプロイトまで完了した。 ...

Claude Codeでツール実行のたびに「パスワード漏洩リスク: 0%」「悪意あるコード実行リスク: 0%」のようなセキュリティリスクのパーセンテージを表示させるCLAUDE.mdの設定がSNSで話題になった。これに対し、セキュリティエンジニアから「それは対策ではなくお気持ち表示」という指摘が上がり、議論を呼んでいる。 話題になった「パーセンテージ表示」 @wan_line_（ワン@AIのお兄さん）氏が2026年3月9日に投稿したポストでは、CLAUDE.mdに以下のようなルールを記述することが提案されていた: ツール実行のたびに パスワードが外に漏れる可能性: ○% 外部サーバーにデータが送られる可能性: ○% 悪意あるコードが動く可能性: ○% PCの設定が書き換わる可能性: ○% Claude Codeで「yes連打」してしまうユーザー向けに、実行前にリスクを可視化してくれるという趣旨だ。 セキュリティ専門家の反論:「お気持ち表示」 この投稿に対し、@sudachikawaii（シンジ☁Shinji）氏が反論した: セキュリティ屋から言うと、これは「対策」ではなく「お気持ち表示」です。LLMはコードの安全性を静的解析していないので、表示されるパーセンテージに技術的根拠がありません。 「0%」を見てyes押すのは、yes連打と同じです。 指摘のポイントは明快だ: LLMは静的解析エンジンではない — LLMが出すパーセンテージは、コードを構文解析して脆弱性を検出した結果ではなく、「それっぽい数値」を生成しているだけ 偽の安心感を与える — 「0%」という表示を見てユーザーが安心してyesを押すなら、結局yes連打と変わらない 技術的根拠がない — 実際のセキュリティリスク分析には、静的解析ツール（SAST）、依存関係チェック、ネットワーク通信の監視などが必要 Claude Codeに本当に効くセキュリティ対策 Claude Codeには、CLAUDE.mdの「お気持ちルール」よりもはるかに実効性のあるセキュリティ機能が組み込まれている。公式ドキュメントに基づき、本当にやるべき対策を整理する。 1. サンドボックスを有効にする 最も重要な対策。Bashコマンドの実行をOSレベルで隔離し、ファイルシステムやネットワークへのアクセスを制限する。 macOSではSeatbelt、LinuxではBubble Wrapが使用される /sandbox コマンドで有効化 2. denyルールで危険なコマンドをブロック permissions.deny に実行禁止コマンドを明示的に設定する。評価順は deny → ask → allow で、denyが最優先。 1 2 3 4 5 6 7 8 9 { "permissions": { "deny": [ "Bash(command:rm -rf *)", "Bash(command:curl *)", "Bash(command:wget *)" ] } } 3. 機密ファイルへのアクセスを遮断 .env やシークレットファイルへのアクセスをブロックする。 ...

ゼロトピック（Zero Topic）の #337「Claude Code時代の仕様書の役割」 が話題になっている。10X の矢本氏が、生成 AI が開発プロセスに与える影響と、仕様書の役割がどう変わるかを整理した回だ。 バイブコーディングの限界と仕様駆動開発 Claude Code のようなAIコーディングエージェントの登場で、コード生成速度は飛躍的に向上した。しかし「バイブコーディング」— AI に任せて探索的にコードを生成するアプローチ — には問題がある。 検証負債の蓄積: AI の生成速度が人間の理解・検証速度を上回る 意図不明なコード増殖: 内部構造を精査せず先に進み、誰も理解していない領域が広がる デバッグ困難化: コードの意図が不明では根本原因の特定が難しい こうした課題に対する解が 仕様駆動開発（Spec-Driven Development: SDD） だ。Thoughtworks Technology Radar Vol.32（2025年4月）で Trial に採用されたこの手法は、「仕様を先に定義し、その仕様に基づいて AI にコードを生成させる」という原則に立つ。 仕様書の役割の変化 従来の設計書は人間同士のコミュニケーションツールだった。AI との協働では「AI への指示書」としての側面が加わる。 SDD における仕様書の構成は、Kiro が提唱する3層モデルが分かりやすい: ファイル 役割 requirements.md ユーザーストーリーと受け入れ基準 design.md アーキテクチャ、シーケンス、設計上の注意 tasks.md 実装計画とタスク分解 重要なポイントは、仕様は 「唯一の情報源（Single Source of Truth）」 として機能し、プロセス駆動はルールブック（プロセスルール）が別途担当するという区別だ。 Claude Code での実践 基礎レベル: CLAUDE.md + ステアリングファイル CLAUDE.md に制約・規約・コンテキストを定義 .steering/ 配下に作業バッチフォルダを作成 要件定義書・設計書・タスクリストを生成・保存 タスクに沿ってコード生成・テスト実施 応用レベル: カスタムコマンドの活用 2026年1月に plansDirectory 設定が追加され、/plan モードで作成した計画書を Git 管理できるようになった。さらにカスタムコマンドを使えば、ドメイン知識を埋め込んだ独自のワークフローを構築できる。 ...

Andrej Karpathy が公開した autoresearch は、AI エージェントが自律的に ML 実験を繰り返すツールだ。寝ている間に AI が 100 回実験し、朝起きたらモデルが賢くなっている——そんな研究スタイルを 630 行の Python コードで実現する。 autoresearch とは nanochat（軽量 LLM 学習コア）をシングル GPU・1 ファイルに凝縮し、AI エージェントが自律ループで学習コードを改善していく仕組み。 基本構造はシンプル: 人間が .md ファイル（プロンプト）を設計する AI エージェントが .py（学習コード）を自律的に改善する 各実験は ちょうど 5 分間 のトレーニングで構成され、1 時間あたり約 12 回、一晩で約 100 回の実験が自動で回る。 人間: program.md を設計（研究の方針・制約を定義） ↓ AI エージェント: 学習コードを修正 ↓ 5分間のトレーニング実行 ↓ 結果を評価（validation loss） ↓ 改善されていれば git commit → 次のイテレーションへ 技術的な特徴 630 行のミニマル設計 autoresearch の核心は「小さく始めて、エージェントに任せる」という哲学にある。 シングル GPU で完結（マルチ GPU 不要） ニューラルネットワークのアーキテクチャ、オプティマイザ、ハイパーパラメータすべてを AI が調整 git feature ブランチ上で動作し、改善があれば自動コミット MIT ライセンスで公開 「コードを書く」のではなく「プログラムをプログラムする」 Karpathy が強調するのは、研究者が Python ファイルを直接触るのではなく、Markdown でエージェントへの指示を設計するというパラダイムシフトだ。 ...