AI/LLM

Claude Code の設定ファイル CLAUDE.md に「こう書け」「これは禁止」「この順番で処理しろ」とルールを追加していったら 300行を超え、AI の出力品質がどんどん落ちていった——そんな経験を経て「99%消した。残したのは、哲学だけ。」という結論に至った話が X で話題になっている。 なぜルールを増やすと AI の性能が落ちるのか コンテキストウィンドウの競合 LLM はコンテキストウィンドウ内のすべての情報を処理する。CLAUDE.md のルールが増えるほど、実際の作業に使える「注意力」が奪われる。コンテキストが埋まるにつれてパフォーマンスが低下するのは、LLM の根本的な特性だ。 指示の上限問題 IFScale ベンチマークの研究によると、フロンティアモデルは 150〜200個の指示 を超えたあたりから選択的注意のバイアスがピークに達し、それ以降は均一に失敗するパターンに収束する。Claude Code のシステムプロンプト自体がすでに約50個の指示を含んでいるため、ユーザーが使える枠は実質100〜150個。200行の詳細なルールを書いた時点で、すでに予算オーバーだ。 指示追従バイアス LLM はプロンプトの 先頭と末尾 の指示に従いやすい傾向がある。中間に埋もれたルールは見落とされがちだ。ルールが増えるほど、重要な指示が中間に埋もれて無視されるリスクが高まる。 具体的に何が起こるか 例えば「見出しは H2 を必ず4つ使え」「セクションは5つ構成にしろ」というルールを設定したとする。すると AI は、本来3セクションで十分な内容でも無理やり5セクションに引き伸ばし、冗長な文章を生成してしまう。 ルールに 従うこと自体が目的化 し、最適な出力を考える余地がなくなる。これは人間の組織でも起こる現象だ。過剰なルールがかえって生産性を下げる。 「哲学だけ残す」アプローチ 細かいルールではなく方針を伝える 悪い例: - 見出しは H2 を4つ使うこと - 各セクションは200〜300文字 - コードブロックには必ず言語指定をつけること - 箇条書きは最大5項目まで 良い例: - 読者が最短で理解できる構成を優先する - 冗長さよりも明確さを重視する Anthropic 公式の推奨 Anthropic の公式ドキュメントでも、CLAUDE.md について以下のように推奨している: 肥大化した CLAUDE.md は、実際の指示を AI に無視させる原因になる Claude がすでに正しくやっていることについては、わざわざルールを書かない 削除できるものは削除し、自動化できるものはフックに変換する Progressive Disclosure パターン すべての情報を CLAUDE.md に詰め込むのではなく、情報の見つけ方 を教える方法が効果的だ。 ...

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万トークン）と比較すると高価だが、マルチモーダル対応を単一モデルで実現している点が差別化要因となる。 ...

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 を増やすことで、サブエージェントからさらにサブエージェントを生成する多段ネストが可能になります。 ...

OpenClaw エージェントを使って、TradingView の指標を自動スクレイピングし、Pine Script から Python に変換してバックテストまで全自動で実行する手法が話題になっています。 OpenClaw とは OpenClaw は、オーストリアの開発者 Peter Steinberger 氏が 2025 年 11 月に Claude を使って構築したオープンソースの AI エージェントです。ローカルマシン上で動作し、自然言語の指示を受けてタスクを自律的に実行します。GitHub で 32 万以上のスターを獲得しており、2026 年初頭にはユーザー数が 200 万人を超えるなど急成長しています。 主な特徴: マルチプラットフォーム対応: Mac / Windows / Linux で動作 メッセージ連携: WhatsApp、Telegram、Slack、Discord など複数チャネルに対応 スキルシステム: モジュラーなプラグイン（スキル）で機能を拡張可能 永続メモリ: コンテキストを記憶して継続的に動作 トレーディング戦略の自動バックテスト 今回話題になっているのは、OpenClaw エージェントを使ったトレーディング戦略の自動バックテストです。 処理の流れ TradingView 指標の自動スクレイピング: TradingView から 50 以上のテクニカル指標を自動収集 Pine Script → Python 変換: TradingView 独自の Pine Script で書かれた指標を Python コードに自動変換 バックテスト実行: 変換した戦略を過去データで自動検証 結果のフィルタリング: 失敗した戦略を自動除外し、勝ちパターンを抽出 GitHub へのログ: テスト結果を自動で GitHub リポジトリに記録 設定を済ませれば、コードを一切書かずにこの一連のプロセスが自動で回り続けます。 ...

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 を使った X（旧 Twitter）運用で、1週間で79万インプレッション・フォロワー1,000人以上増加という成果報告が話題になっています。この記事では、その成果の背景にある「ナレッジ管理」と「投稿生成プロセス」の重要性について解説します。 OpenClaw × X運用の成果 @ichiaimarketer 氏が報告した成果: 約1週間で79万インプレッション フォロワー1,000人以上増加 注目すべきは、この成果は OpenClaw のツール自体の力ではなく、使い方に依存しているという点です。 鍵は「ナレッジ管理」 AI に「思いつきで投稿させる」のではなく、蓄積された知識・経験をコンテキストとして与えることが重要です。 なぜナレッジ管理が重要か コンテキストの質が出力の質を決める — LLM は与えられた情報から生成するため、ナレッジベースの質が投稿の質に直結する 一貫性のあるブランディング — 過去の投稿や知見を蓄積することで、アカウントとしての一貫した声が生まれる 専門性の反映 — 自分の専門知識をナレッジとして整理することで、AI が専門的な投稿を生成できる OpenClaw でのナレッジ管理の実践 OpenClaw には Knowledge Management スキルが用意されており、メモリエントリを自動的に分類・整理できます。蓄積された知見は Research、Insight、Pattern などのフォルダに分類され、タイムスタンプ付きの Markdown ファイルとして保存されます。 また、OpenClaw の cron システムと組み合わせて定期的に同期することで、ナレッジベースを常に最新の状態に保てます。 この整理されたナレッジをスキルから参照することで、投稿生成時に適切なコンテキストを自動的に提供できます。 投稿生成プロセス 効果的な X 運用のための投稿生成プロセスは以下の流れです: ナレッジの蓄積 — 日々の学びや知見をナレッジベースに追加 コンテキストの構築 — 投稿テーマに関連するナレッジを選択 AI による生成 — OpenClaw の bird スキルを使って投稿を生成 レビューと投稿 — 生成された内容を確認して投稿 OpenClaw の bird スキル OpenClaw には bird というスキルが組み込まれており、X/Twitter の操作を CLI ベースで行えます: ...

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 動作確認は以下のコマンドで行えます。 ...

VS Code マーケットプレイスにおける AI コーディングアシスタントの日次インストール数を示すグラフが話題になっている。GitHub Copilot のインストール数が急激に落ち込む「崖」が鮮明に表れており、SaaS 事業者やプロダクトマネージャーにとって示唆に富む内容だ。 グラフが示すもの 「Daily Install Counts of AI Coding Assistants in Visual Studio Code」と題されたグラフには、以下の 3 つの AI コーディングアシスタントの日次インストール数（30日移動平均）が描かれている。 GitHub Copilot（オレンジ）：2021年末から着実に成長し、2025年後半には日次 150,000 インストール近くまで到達。しかし 2026年に入って急落し、現在は 60,000 前後まで落ち込んでいる Claude Code（シアン）：2025年後半に登場し、直近で急速に伸長。日次 60,000 近くまで上昇 OpenAI Codex（イエロー）：同じく直近で伸びを見せているが、Claude Code よりやや控えめ 注目すべきは、GitHub Copilot のインストール数がピークから半分以下に急落している点だ。この「崖」は、競合の台頭と GitHub Copilot 自体の変化の両方が要因と考えられる。 急落の背景 GitHub Copilot の課金モデル変更 GitHub Copilot は 2024年12月に無料ティアを導入し、月 2,000 回のコード補完と 50 回のチャットリクエストという制限付きで提供を開始した。同時に、有料プランの価格体系も複雑化している。 Free：月 2,000 補完 / 50 チャット Pro：$10/月 Pro+：$39/月 Business：$19/ユーザー/月 Enterprise：$39/ユーザー/月 無料ティアの導入は新規ユーザー獲得を狙った施策だが、既存の有料ユーザーが無料枠で十分と判断して解約するケースもあり得る。また、Microsoft は従来の IntelliCode を廃止し、AI 支援を Copilot に一本化する戦略を取っている。 ...

Anthropic が Claude Code の新機能「Code Review」を発表した。PR が開かれると、複数のエージェントがチームとして並列にコードレビューを実行し、人間が見落としがちなバグを検出する。開発者の Boris Cherny 氏（@bcherny）は「数週間使って、自分では気づかなかった本物のバグを何度も見つけてくれた」と報告している。 仕組み PR がオープンされると、Code Review は以下のステップを実行する: エージェントチームの派遣 — 複数のエージェントが並列に動き、それぞれ異なるクラスの問題（ロジックエラー、セキュリティ脆弱性、コード品質など）を探す 検証フェーズ — 候補として検出された問題を実際のコード挙動と照合し、偽陽性をフィルタリングする 深刻度ランキング — 検出された問題を重要度順に並べる レビューコメント投稿 — PR に対してサマリーコメント 1 件と、具体的な問題箇所へのインラインコメントを投稿する レビューの深さは PR の規模と複雑さに応じてスケールする。大きく複雑な変更にはより多くのエージェントが投入される。 検出精度 Anthropic 社内でのテスト結果: PR サイズ 指摘ありの割合 平均指摘数 大規模（1,000行以上） 84% 7.5件 小規模（50行未満） 31% 0.5件 特筆すべきは誤検出率が 1% 未満という点だ。エンジニアが「この指摘は間違い」と判定したケースがほとんどなく、検証フェーズによる偽陽性フィルタリングが効果的に機能していることを示している。 なぜ必要なのか Cherny 氏によれば、Anthropic のエンジニア一人あたりのコード出力は 2026 年に入って 200% 増加した。AI コーディングエージェントによってコード生成が加速する一方で、レビューがボトルネックになっていた。人間のレビュアーが処理できる量には限界があり、AI が書いたコードも人間が書いたコードも、同じ品質基準でレビューする必要がある。 Code Review はこの問題に対する Anthropic 自身の解答だ。まず社内で使い、効果を確認した上で外部に公開している。 利用条件 対象プラン: Team / Enterprise（Research Preview） 料金: トークン使用量に基づく従量課金。PR サイズと複雑さに応じて平均 $15〜25 レビュー時間: 約 20 分 セットアップ: 管理者が GitHub App をインストールし、対象リポジトリを選択。開発者側の追加設定は不要 組織レベルでの月間支出上限、リポジトリ単位の有効化制御、レビュー受け入れ率の分析ダッシュボードも用意されている。 ...