Llm

OpenClaw を使っていて API コストが気になっていませんか？ ClawRouter は、リクエストごとに最安のモデルを自動選択してくれるオープンソースの LLM ルーターです。最大約92%のコスト削減が期待でき、しかも完全無料で利用できます。 ClawRouter とは ClawRouter は、OpenClaw 向けに設計されたエージェントネイティブな LLM ルーターです。MIT ライセンスで公開されており、誰でも無料で利用できます。 主な特徴: 55以上のモデルに対応 — DeepSeek V3.2、Nemotron Ultra 253B、Mistral Large 3 675B、Llama 4 Maverick など 1ms 未満のルーティング — すべてローカルで処理されるため、レイテンシの追加はほぼゼロ 15次元のリクエスト分析 — 各リクエストを多次元で要素分解し、最適なモデルをスコアリング 11モデルが完全無料 — 簡単なクエリは無料モデルに自動ルーティング どれくらいコストが下がるのか ClawRouter の公式ベンチマークによると: 指標 値 ClawRouter 平均コスト $2.05 / 100万トークン Claude Opus 直接利用 $25 / 100万トークン 削減率 約92% たとえば「2+2は？」のような簡単な質問は、DeepSeek などの無料モデルに自動ルーティングされます。一方、複雑な推論が必要なタスクにはプレミアムモデルが選択されるため、品質を犠牲にしません。 仕組み ClawRouter は各リクエストに対して以下のプロセスを実行します: リクエスト分析 — 入力テキストを15次元で要素分解（タスクの複雑さ、必要な推論能力、言語、コンテキスト長など） スコアリング — 各モデルの能力とコストを総合的に評価 ルーティング — 最もコスト効率の良いモデルを自動選択 この全プロセスが 1ms 未満で完了します。 ...

OpenClaw で構築された AI エージェント「Felix」が、従業員ゼロで月売上1,200万円規模の会社を運営しているという事例が話題になっている。起業家 Nat Eliason（エリアソン）氏がどのようにこの仕組みを構築したのか、その構造と示唆をまとめる。 Felix が回す会社の構造 エリアソン氏は、OpenClaw で作った AI エージェント「Felix」を中心に会社を運営している。 Felix = CEO 兼プロダクト責任者 Iris = カスタマーサポート担当 Remy = セールス担当 全員が AI エージェントで、人間はエリアソン氏本人だけ。やっていることは Discord に音声メモを送ることだけで、5分程度のボイスメモで方向性を伝えると、Felix が全体を組み立てて実行まで持っていく。 驚異的なコスト構造 初期費用: 約22万円（Mac Mini 等） 月額コスト: 約6万円（Claude Max 2アカウント分） 人件費: ゼロ 30日間の売上: 約1,200万円 年間ランレート換算: 1.5億〜3億円 利益率がほぼ100%という異常な構造になっている。 毎晩の自己改善ループ Felix の最も興味深い特徴は「毎晩の自己改善ループ」だ。 Felix は毎晩、部下の Iris と Remy の仕事をレビューして再プログラムしている。人間の上司が部下にフィードバックするのと同じことを、AI エージェントが AI エージェントに対して行っている。 さらに、Felix は毎晩すべてのチャット履歴を読み返して「Nat が自分をブロックした場面」を1つ見つける。そのブロッカーを恒久的に取り除く方法を自分で考えて実装する。つまり毎日少しずつ自律性が上がっていく仕組みになっている。 スケーリングの壁 エリアソン氏が語るスケーリングの壁が興味深い。 「単一エージェントの処理限界にぶつかっている」 「ボトルネックは資金じゃなくてインフラ」 VC から出資オファーが来ても、必要なのはお金ではなく「エージェントの自律性（agency）」だという。何億円投じてもエージェントが賢くならない限り天井は変わらない。 Felix のビジネス内容 Felix が運営するビジネスは、主に3つの収益源で構成されている。 1. Felix Craft（PDF ガイド） 最初のプロダクトは「How to Hire an AI」という66ページの PDF ガイド（$29）。AI を実際のチームメンバーとして活用する方法をまとめたもので、Felix 自身が執筆した。Next.js + Vercel + Stripe で世界一シンプルな販売サイトを構築し、初日に15万円を売り上げた。累計で約$41,000の売上を記録している。 ...

この記事では、Python基礎からLLM/RAG開発、MLOpsまでを6ヶ月で学ぶロードマップを、すべて無料のリソースで紹介する。各月のゴールと具体的な教材リスト付き。 AIエンジニアの求人は前年比143%増加している。米国での平均年収は約17万5,000ドル。インドでは10件の求人に対して1人しか適格な候補者がいない状況だ。 学位は不要。ブートキャンプも不要。必要なスキルを学ぶためのリソースはすべて無料で公開されている。この記事では、AI分野のコンテンツクリエイターであるNav Toor氏が提唱する6ヶ月のロードマップを紹介する。1ヶ月ずつ、6つのフェーズで構成されている。 Month 1: Python とプログラミング基礎 すべてのAIフレームワーク、ライブラリ、ツールはPythonの上に構築されている。このステップを省略したり、急いで済ませたりしてはいけない。 学ぶべき内容: 変数、関数、ループ、条件分岐、データ構造（リスト、辞書、セット）、オブジェクト指向プログラミング、ファイル操作、エラー処理、Git/GitHub の基本。 リソース Python for Everybody（Dr. Chuck, ミシガン大学） — YouTubeとCourseraで無料公開。史上最も人気のあるPythonコース CS50P: Introduction to Programming with Python（Harvard, David Malan） — YouTube で無料。ハーバード品質、前提知識不要 Automate the Boring Stuff with Python（Al Sweigart） — オンラインで無料閲覧可能。初日から実践的なPython Git and GitHub for Beginners（freeCodeCamp） — YouTube で無料。1時間で必要な知識をカバー マイルストーン: CSVを読み込み、データを処理し、結果を出力するPythonスクリプトを書ける。GitHubアカウントに3つ以上のプロジェクトがプッシュされている。 Month 2: 数学と統計 数学の学位は不要だ。モデルがなぜ動くのか、うまくいかないときにどう対処すべきかを理解できる程度の数学で十分だ。 学ぶべき内容: 線形代数（ベクトル、行列、内積、固有値）、微積分（微分、勾配、連鎖律）、確率（ベイズの定理、分布）、統計（平均、分散、仮説検定、回帰）。 リソース 3Blue1Brown: Essence of Linear Algebra — YouTube で無料。16本の動画。史上最高の数学ビジュアルコンテンツ 3Blue1Brown: Essence of Calculus — YouTube で無料。同じクオリティと明快さ Khan Academy: Statistics and Probability — 無料。包括的。自分のペースで学習可能 MIT 18.06: Linear Algebra（Gilbert Strang） — MIT OCW で無料。大学講義のゴールドスタンダード StatQuest with Josh Starmer — YouTube で無料。専門用語なしで統計を解説 マイルストーン: 勾配降下法を直感的に理解できる。損失関数の役割と、行列乗算がニューラルネットワークで重要な理由を説明できる。 ...

AIエージェントを本番運用していると、スキルが静かに壊れていく問題に直面する。agent-skill-bus は、エージェントスキルのヘルスモニタリング・自己改善・依存管理を担うフレームワーク非依存の運用基盤だ。 背景: 42体のAIエージェント運用で見えた課題 開発者のシュンスケ氏（@The_AGI_WAY）は、42体のAIエージェントを半年間運用する中で以下の課題に直面したという。 エージェントは壊れる — APIの変更、モデルのアップデート、認証の期限切れなどで、スキルが静かに劣化する タスクは衝突する — 複数のエージェントが同時に同じファイルを編集し、データ破損が発生する 依存関係が管理できない — 複雑なタスクはA→B→Cの順序が必要だが、多くのシステムは並列実行してしまう 学習ループがない — フィードバック機構がないため、同じ失敗が繰り返される 42体を人間が目視で監視するのは現実的ではない。そこで作られたのが agent-skill-bus だ。 3つのモジュール構成 agent-skill-bus は、独立して動作する3つのモジュールで構成されている。 モジュール 役割 Prompt Request Bus DAG（有向非巡回グラフ）ベースのタスクキュー。依存関係の解決とファイルロックを提供 Self-Improving Skills スキル品質の自動モニタリングと修復ループ Knowledge Watcher 外部変更の検知から自動改善トリガーを発火 これらが連携することで、閉ループの自己改善エージェントシステムを形成する。 1 2 3 4 5 外部変更 ──→ Knowledge Watcher ──→ Prompt Request Bus ──→ 実行 ↑ │ │ ↓ Self-Improving ←── スキル実行ログ Skills セットアップと基本的な使い方 Node.js のみで動作し、外部依存はゼロ。 ...

コロンビア大学の Vishal Misra 教授が、AI のスケーリングの限界と AGI（Artificial General Intelligence: 汎用人工知能）実現に必要な条件について語っている。同教授はコンピュータサイエンス・電気工学を専門とし、AI・コンピューティング副学部長を務める。「モデルを大きくすれば知能に届く」という期待に対し、根本的に異なるアプローチが必要だという指摘だ。 スケーリングだけでは解決しない Misra 教授の主張の核心は明快だ。 いま広く存在している誤解の一つは、スケールを拡大すればすべて解決するというものです。ですが、スケールだけではすべては解決しません。必要なのは、別種のアーキテクチャです。 現在の LLM は、パラメータ数やデータ量を増やすことで性能を向上させてきた。しかし、この「スケーリング則」には限界がある。モデルを大きくしても、タスク固有の性能は上がるが、継続的に適応し汎化する能力は自動的には得られない。これこそが真の知能に必要な能力だ。 継続学習と破滅的忘却のジレンマ AGI に必要な第一の条件として、Misra 教授は「可塑性（plasticity）」を挙げる。これは継続学習（continual learning）によって実装されなければならない。 この継続学習は難しい問題です。新しいことを学べるという利点と、破滅的忘却のリスクを両立させなければならないからです。重みを更新しても、重要だったことや、すでに学んだことを忘れてしまうなら、それは進歩ではありません。そうなると、ただのランダムでカオスなモデルになってしまいます。 破滅的忘却（catastrophic forgetting）は、ニューラルネットワークが新しいタスクを学習する際に、以前のタスクの性能が急激に低下する現象だ。現在の LLM はファインチューニング時にこの問題に直面する。新しい知識を獲得しながら、既存の知識を保持する。この一見シンプルな要件が、技術的には極めて困難な課題だ。 相関から因果へ 第二の条件は、「相関から因果への移行」だ。 AGI に到達するには、二つのことが必要だと私は考えています。一つはこの可塑性であり、これは継続学習によって実装されなければなりません。もう一つは、相関から因果へ移行することです。 現在の LLM は、大量のテキストデータから統計的な相関パターンを学習している。「AのあとにBが来やすい」というパターンは捉えられるが、「AがBを引き起こす」という因果関係の理解は本質的に異なる。因果推論ができなければ、未知の状況での推論や、ある行動がどんな結果をもたらすかの予測は困難だ。 現在の AI 研究への示唆 Misra 教授の指摘は、現在の AI 開発の方向性に対する重要な問題提起だ。 スケーリングの限界: パラメータ数やデータ量の増加だけでは、質的な飛躍は起きない アーキテクチャの革新: Transformer アーキテクチャの改良だけでなく、根本的に新しい設計が求められる 継続学習の実現: 学習と記憶の両立は、脳科学の知見も取り入れた新しいアプローチが必要 因果推論の統合: 統計的パターンマッチングを超えた、因果モデルの構築が不可欠 「大きくすれば賢くなる」という単純な物語は魅力的だが、AGI への道はもっと複雑で、根本的なブレイクスルーが求められている。 参考 Vishal Misra - Columbia University Chatting about AI with our New Vice Dean of AI and Computing - Columbia Engineering

GPUなしで毎秒100ページ以上のPDF→Markdown変換を実現するオープンソースツール「OpenDataLoader PDF」が話題になっている。Apache 2.0ライセンスで完全無料、CPUのみで動作するため、高価なGPUハードウェアは不要だ。 OpenDataLoader PDF とは OpenDataLoader PDF は、PDFドキュメントをAI活用に適した構造化データ（Markdown、JSON、HTML等）に変換するオープンソースのパーサーだ。Java で実装されており、Python・Node.js・Java から利用できる。 主な特徴: 超高速処理: ローカルモードで 0.05秒/ページ（CPUのみ）、8コア以上のマシンでマルチプロセスバッチ処理すると毎秒100ページ以上 GPU不要: CPUだけで高速に動作するため、導入コストが低い 高精度: ベンチマークで総合精度0.90を達成し、読み順・テーブル・見出し抽出で1位 Apache 2.0ライセンス: 商用利用可能な完全オープンソース インストール Python パッケージは Java CLI のラッパーのため、Java 11以上とPython 3.10以上が必要だ。 1 2 3 4 5 # Python pip install -U opendataloader-pdf # Node.js npm install @opendataloader/pdf Java の場合は Maven で opendataloader-pdf-core を依存関係に追加する。 基本的な使い方 Python でのシンプルな変換 1 2 3 4 5 6 7 import opendataloader_pdf opendataloader_pdf.convert( input_path=["file1.pdf", "file2.pdf", "folder/"], output_dir="output/", format="markdown,json" ) フォルダを指定すれば一括変換も可能だ。出力形式は Markdown、JSON、HTML、プレーンテキスト、注釈付きPDFから選べる。 ...

Vibe Coding（バイブコーディング）で成果を出せる人と出せない人の違いは何か。CHI 2026 で発表された論文「Computer Science Achievement and Writing Skills Predict Vibe Coding Proficiency」が、その答えを実証的に示している。結論は、CS の基礎知識と論理的な文章作成能力の2つが鍵だというものだ。 Vibe Coding とは Vibe Coding は、2025年初頭に Andrej Karpathy が提唱したプログラミングスタイルだ。ソースコードを直接編集するのではなく、自然言語で LLM にプログラムの仕様を伝える。生成された結果を観察しながら反復的に改善していくアプローチだ。 「誰でも自然言語でアプリが作れる時代」と言われる一方で、実際には同じツールを使っても成果に大きな差が出る。この差を生む要因は何なのか。 論文の概要 Sverrir Thorgeirsson、Theo B. Weidmann、Zhendong Su の3名による研究（arXiv: 2603.14133）は、大学生100名を対象にした事前登録済み（仮説や分析計画を事前に公開した）横断研究だ。 被験者は以下の4つの能力を測定された: コンピュータサイエンス（CS）の達成度 汎用的な認知能力（いわゆる「頭の良さ」） 文章作成能力 Vibe Coding の成績（専門家の合意で設計された評価タスク） 評価タスクでは、参加者はまずサンプルアプリケーションを確認する。次に LLM ベースのエージェントへプロンプトを作成し、生成されたアプリケーションをテストしながら改善を重ねる。最終的な成果物を人間の評価者が採点した。 2つの重要な予測因子 研究の結果、Vibe Coding の成績を有意に予測する因子は以下の2つだった: 1. CS の基礎知識（最も重要） CS の達成度は、汎用的な認知能力を統制した後でも有意な予測因子として残った。つまり、「頭が良い」だけでは不十分で、コンピュータサイエンスの基礎を理解していることが独立した強みになる。 回帰分析の結果、CS の知識が説明する固有分散（ΔR² = 0.125）は文章力（ΔR² = 0.059）の約2倍だった。 2. 論理的な文章作成能力 文章を論理的に構成し、意図を明確に伝える能力も有意な予測因子だった。これは当然とも言える。LLM に的確な指示を出すには、要件を整理し、曖昧さなく文章化するスキルが求められるからだ。 「頭の良さ」だけでは足りない 興味深いのは、汎用的な認知能力（特定分野に依存しない一般的な認知スキル）は、それほど大きな影響を持たなかったという点だ。 これは重要な示唆を含んでいる。Vibe Coding は「誰でもできる」わけではないが、「天才でなければできない」わけでもない。CS の基礎知識と論理的な文章力という、学習可能なスキルが鍵を握っている。 教育・実務への示唆 この研究結果は、AI 時代のプログラミング教育に対して重要な問いを投げかける: ...

社内資料をRAGで検索しているのに「欲しい情報に限って見つけてくれない」「関係ない文書ばかり読んで的外れな回答をする」という経験はないでしょうか。AIDB が紹介する新しいRAG手法は、検索方法そのものをモデル自身に判断させるというアプローチで、この問題に正面から取り組んでいます。 従来RAGの限界：一本調子の検索 従来のRAGはシンプルです。あらかじめ決まった方法（主にベクトル類似度検索）で文書チャンクを引っ張ってきて、まとめてLLMに渡す。検索がハズれたら、その時点でもう正解にはたどり着けません。 どんなに優れたモデルを使っても、読む資料がズレていれば回答の質は上がりません。問題は「LLMの能力」ではなく「検索戦略の固定化」にあります。 3つの検索戦略を状況に応じて使い分ける この新手法では、モデルが以下の3つの検索戦略から最適なものを選択し、必要に応じて組み合わせます。 検索戦略 特徴 向いているケース キーワード検索 特定の語句・コードをピンポイントで探す 固有名詞、型番、コマンドなどを調べるとき 意味検索（セマンティック検索） 意味的に近い文書を探す 概念的な質問、言い換えが多い文書を扱うとき チャンク全文読み 対象範囲を丸ごと読み込む 文脈が重要な長文、前後関係が必要なとき 重要なのは、どの順番で、どの検索を使うかをモデル自身が推論して決定する点です。固定のパイプラインではなく、質問の性質や文書の構造に合わせて動的に戦略を切り替えます。 なぜこれが機能するのか 読み込むテキスト量は同等以下 従来のRAGと比較して、読み込むテキストの量は同等かそれ以下です。にもかかわらず、回答精度は大きく向上します。これはトークン数の節約にもつながります。 モデル進化と共にスケールする構造 この手法の特筆すべき点はモデルの推論能力と性能が比例することです。モデルの推論能力が高いほど、「どの検索を、どの順番で使うか」という判断精度が上がり、RAG全体の性能が向上します。 つまり、将来より優れたモデルが登場すれば、RAGのフレームワーク自体を改修しなくても自然に性能が底上げされます。 実装への示唆 この手法を自社のRAGシステムに取り入れる場合、以下の点が設計のポイントになります。 1. 検索ツールの整備 モデルが選択できるよう、複数の検索エンドポイントを用意する必要があります。BM25（キーワード）、ベクトルDB（意味）、ドキュメント取得（全文）の3種を揃えるのが基本構成です。 2. ツール呼び出し（Function Calling）の活用 OpenAI / Anthropic / Google などの主要LLMはFunction Callingをサポートしています。検索戦略の選択をFunction Callingで実装することで、モデルが自律的に検索を制御できます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 tools = [ { "name": "keyword_search", "description": "固有名詞・型番・コマンドなど特定のキーワードで文書を検索する", "parameters": {"query": "string"} }, { "name": "semantic_search", "description": "意味・概念の近さで関連文書を検索する", "parameters": {"query": "string"} }, { "name": "read_document", "description": "指定した文書チャンクを全文読み込む", "parameters": {"document_id": "string"} } ] 3. 推論能力の高いモデルを選ぶ ...

Microsoft がオープンソースで公開した Agent Governance Toolkit は、自律型 AI エージェントに欠けていたセキュリティレイヤーを提供するツールキットだ。ポリシー強制、ゼロトラスト ID、実行サンドボックス、信頼性エンジニアリングの4つの柱で、OWASP Agentic Top 10 の全10項目のリスクをカバーする。 背景：なぜ AI エージェントにガバナンスが必要か AI エージェントが自律的にツールを呼び出し、ファイルを操作し、外部 API と通信する時代になった。しかし、その自律性にはリスクが伴う。意図しないゴールの書き換え、過剰な権限の付与、エージェント間通信の改ざん、カスケード障害など、従来の Web アプリケーションとは異なるセキュリティ課題がある。 OWASP は「Agentic Top 10」として AI エージェント特有のリスクを定義しており、Agent Governance Toolkit はこの全10項目に対応している。 4つの柱 1. Policy Engine（ポリシーエンジン） すべてのエージェントアクションを実行前に評価し、許可・拒否を判定する。サブミリ秒（0.1ms 未満）のレイテンシで動作するため、エージェントの応答速度に影響を与えない。 1 2 3 4 5 6 from agent_governance_toolkit import CapabilityModel capabilities = CapabilityModel( allowed_tools=["web_search", "file_read"], denied_tools=["file_write", "shell_exec"] ) 許可するツールと拒否するツールを明示的に定義し、エージェントが意図しない操作を行うことを防ぐ。 ...

Agentic Coding（AIエージェントによるコーディング）が普及する中、AIに渡すドキュメントをどこに配置すべきかという問題が注目されています。古川陽介氏（@yosuke_furukawa）のポストで紹介されていた記事「Your Docs Directory Is Doomed」（Yagmin）の内容をもとに、この問題を考えます。 /docs ディレクトリの進化と限界 Agentic Coding を始めると、多くのプロジェクトで以下のようなドキュメントが増えていきます: まず CLAUDE.md や AGENTS.md のような設定ファイルを作成 ARCHITECTURE.md でシステム全体の構造を記述 機能仕様やデザインドキュメントを /docs フォルダにまとめ始める この流れ自体は自然ですが、記事では /docs ディレクトリへの集約には根本的な問題があると指摘しています。 /docs ディレクトリの問題点 1. 発見可能性（Discoverability） LLM はどのドキュメントをいつ読むべきかを自律的に判断する必要があります。/docs に大量のファイルがある場合、LLM が適切なドキュメントを見つけられる保証はありません。計画フェーズで必要なドキュメントと、コード生成フェーズで必要なドキュメントは異なりますが、それを正しく参照できるでしょうか。 2. ドキュメントの腐敗（Documentation Rot） コードは頻繁に変更されますが、対応するドキュメントの更新は忘れがちです。小さな不整合が積み重なり、LLM が参照するコンテキストの品質が徐々に劣化していきます。さらに厄介なのは、ドキュメントが間違っていることに気づくための仕組み（observability）がないことです。 3. 構造の欠如 ドキュメント間の階層関係や依存関係が明示されていないため、LLM がドキュメント群をナビゲートする明確な方法がありません。各自が自分のスタイルで書くため、LLM にとって情報の探索がしにくい構造になります。 4. 変更速度の不一致（Velocity Mismatch） ドキュメントの種類によって変更頻度が異なります。アーキテクチャの概要はめったに変わりませんが、API仕様やコンポーネントの詳細は頻繁に更新されます。一つのディレクトリにすべてをまとめると、この違いが管理を困難にします。 コロケーション（Colocation）というアプローチ 古川氏がツイートで触れているように、一つの解決策はコロケーション — ドキュメントをコードの近くに直接配置する方法です。 src/ auth/ README.md # 認証モジュールの説明 auth.ts auth.test.ts api/ README.md # APIモジュールの説明 routes.ts middleware.ts このアプローチの利点: 発見可能性の向上: 関連コードと同じディレクトリにあるため、LLM が自然に参照できる 更新の同期: コードを変更する際にドキュメントも目に入るため、更新忘れが減る スコープの明確化: 各ドキュメントが担当する範囲が明確 Agentic Coding でのドキュメント管理の方向性 「Your Docs Directory Is Doomed」の記事は、従来のドキュメント管理は「1985年からの解決策」に過ぎないと指摘しています。Agentic Coding 時代には、以下の要素が重要になります: ...