OpenRouter で AI モデルを一元管理する — コスト削減と効率化の実践

AI モデルの利用が増えるにつれ、複数のプロバイダの API キーを管理する煩雑さやコストの把握が難しくなっていく。OpenRouter を使えば、1つの API キーで複数の AI モデルにアクセスでき、コスト管理も一元化できる。 OpenRouter とは OpenRouter は、複数の AI モデルプロバイダ(OpenAI、Anthropic、Google、Meta など)のモデルに単一の API エンドポイントからアクセスできるルーティングサービスだ。OpenAI 互換の API 形式を採用しているため、既存のコードからの移行も容易になっている。 料金体系 OpenRouter は無料から始められる。クレジットカードの登録も不要だ。 無料モデル: DeepSeek V3/R1、Google、Meta、Mistral など約27種類のモデルが無料で利用可能(1日50リクエスト、1分20リクエストの制限あり) 有料モデル: Claude や GPT-4 などのプレミアムモデルはプロバイダの正規料金で従量課金。最低金額やロックインなし BYOK(自分の API キー持ち込み): 月100万リクエストまで無料。以降は通常料金の5%の手数料 OpenRouter を使う3つのメリット 1. コスト効率の向上 各プロバイダと個別に契約する代わりに、OpenRouter 経由で利用することで支出を一元管理できる。用途に応じて安価なモデルと高性能なモデルを使い分けることで、全体のコストを最適化できる。 2. API キーの一元管理 複数のプロバイダの API キーを管理する必要がなくなる。1つの OpenRouter API キーだけで、さまざまなモデルにアクセスできる。 1 2 # OpenRouter API キーを設定するだけで複数モデルにアクセス可能 export OPENROUTER_API_KEY="sk-or-..." 3. 最新モデルへの素早い切り替え 新しいモデルがリリースされた際、OpenRouter 上で利用可能になればすぐに試すことができる。プロバイダごとにアカウント登録や API キー発行をする必要がない。 ...

2026年3月8日 · 1 分

# OpenHands × Ollama ローカルLLM実践記 — Mac Studio M3 Ultra で動かすまでの全記録

OpenHands × Ollama ローカルLLM実践記 — Mac Studio M3 Ultra で動かすまでの全記録 TL;DR: OpenHands(旧OpenDevin)をMac Studio M3 Ultra(96GB)+ Ollama + Qwen3-Coder 30B で動かそうとした。Docker-in-Docker のビルド問題、Playwright依存、ランタイムイメージ手動構築を経てUI起動まで到達したが、30Bモデルのtool calling精度不足で実用には至らなかった。 1. OpenHands とは OpenHands(旧 OpenDevin)は、オープンソースのAIコーディングエージェントプラットフォーム。75以上のLLMプロバイダーに対応し、SWE-bench で Qwen3-Coder 使用時に 69.6% のスコアを記録している。 公式リポジトリ: https://github.com/All-Hands-AI/OpenHands 特徴: Web UI でブラウザから操作 Docker サンドボックスで安全にコード実行 CodeActAgent による自律的なタスク遂行 Playwright 統合によるブラウザ操作 2. 動機 — なぜ OpenHands を試したか 前回の実験で Qwen Code(CLI エージェント)を Ollama + Qwen3-Coder 30B で動かしたが、複雑な multi-step タスク(GitHub PR レビューなど)で tool calling が破綻する問題に直面した。 OpenHands は SWE-bench で高スコアを出しており、エージェントスキャフォールディングの力で同じ 30B モデルでも改善されるのでは?という仮説を検証するために試した。 ...

2026年3月6日 · 3 分

「決定性のないソフトウェア」の設計と評価 × t_wada氏の視点とskill-creatorが実装したTDD→EDD移行パターン

「決定性のないソフトウェア」をどう設計し評価するか — t_wada 氏の視点と skill-creator が実装した答え 和田卓人(@t_wada)氏が X で言及した、skill-creator の設計に関するコメントが注目を集めています。 skill-creator いい感じで動作すると思っていたら中身がこのようになっていたのか。決定性のないソフトウェアをどう実践的に設計して評価するかといった観点でも参考になるエントリ。 t_wada 氏は、テスト駆動開発(TDD)の日本における第一人者であり、Kent Beck 著『テスト駆動開発』の翻訳者、power-assert-js の作者として知られるプログラマです。その t_wada 氏が「決定性のないソフトウェアの設計と評価」という観点で skill-creator を評価しています。 元記事は逆瀬川ちゃん氏のブログ「skill-creator から学ぶ Skill 設計と、Orchestration Skill の作り方」です。本記事では、t_wada 氏の指摘する「決定性のないソフトウェア」の設計問題に焦点を当て、skill-creator がどのような解を実装しているかを解説します。 「決定性のないソフトウェア」とは何か 従来のソフトウェアとの違い 決定的ソフトウェア(従来): 入力 A → 常に出力 X 入力 B → 常に出力 Y → 「2 + 2 = 4」を assert できる 非決定的ソフトウェア(LLM ベース): 入力 A → 出力 X1, X2, X3...(毎回異なる) 入力 B → 出力 Y1, Y2, Y3...(毎回異なる) → 「正解」が一意に定まらない LLM の出力は確率的です。同じプロンプトを送っても、temperature やサンプリングの影響で異なる結果が返ります。従来の assertEqual(expected, actual) というテスト手法が通用しない世界です。 ...

2026年3月5日 · 4 分

Agentic AI の仕組み — 4層アーキテクチャで理解する「考えて動く AI」の全体像

Agentic AI の仕組み — 4層アーキテクチャで理解する「考えて動く AI」の全体像 Ronald van Loon さん(@Ronald_vanLoon)が、@Python_Dv 作成の Agentic AI アーキテクチャ図を共有し、注目を集めています。 How #AgenticAI works https://x.com/Ronald_vanLoon/status/2029305639546060814 このインフォグラフィックは、Agentic AI の動作原理を Input Sources → AI Processing → Action Layer → Output の4層で整理しています。「生成 AI と何が違うのか」「なぜ自律的に動けるのか」を、この4層構造を軸に解説します。 生成 AI と Agentic AI の根本的な違い まず前提を整理します。生成 AI(Generative AI)と Agentic AI は、AI の進化の段階が異なります。 観点 生成 AI Agentic AI 基本動作 プロンプトに対してコンテンツを生成 目標に向かって自律的に行動 姿勢 受動的(聞かれたら答える) 能動的(自分で判断して動く) タスク範囲 1回のやり取りで完結 複数ステップを跨いで継続 外部連携 なし(テキスト入出力のみ) API・ツール・データベースと連携 記憶 セッション内のみ セッション間で永続化可能 自己修正 なし エラーを検知して自動リカバリー IBM は両者の関係を端的にまとめています。「生成 AI は考えて話す。Agentic AI は計画して実行する」。 ...

2026年3月5日 · 4 分

Agentic AI 学習ロードマップ — 「フルスタックインテリジェンス」を9ヶ月で習得する体系的な道筋

Agentic AI 学習ロードマップ — 「フルスタックインテリジェンス」を9ヶ月で習得する体系的な道筋 @ingliguori 氏(Giuliano Liguori)のポストが、Agentic AI を学ぶためのロードマップを共有しています。 Roadmap to learn Agentic AI: AI fundamentals → Python + frameworks → LLMs → Agents architecture → Memory + RAG → Planning & decision-making → RL & self-improvement → Deployment → Real-world automation Agentic AI = full-stack intelligence. 「Agentic AI = フルスタックインテリジェンス」というフレーズが示すように、AI エージェントの開発には基礎数学からデプロイまで、フルスタックの知識が求められます。本記事では、このロードマップを複数の学習リソースと照合しながら、各段階で何を学び、どのツールを使い、どこまでを目指すのかを体系的に解説します。 ロードマップの全体像 Liguori 氏が示した9ステップを、Scaler の9ヶ月ロードマップと roadmap.sh の AI Agents ロードマップを参考に、時系列で整理します。 月0-1 AI Fundamentals ← 数学 + ML 基礎 月1-2 Python + Frameworks ← API + ライブラリ 月2-3 LLMs ← Transformer + プロンプト 月3-4 Agents Architecture ← ReAct + ツール使用 月4-5 Memory + RAG ← ベクトル DB + 検索拡張 月5-6 Planning & Decision ← 計画 + マルチエージェント 月6-7 RL & Self-improvement ← フィードバック + 自律性 月7-8 Deployment ← MLOps + 監視 月8-9 Real-world Automation ← ポートフォリオ + 実案件 Step 1: AI Fundamentals(月0-1) 学ぶこと 分野 具体的な内容 線形代数 ベクトル、行列演算、固有値分解、SVD 微積分 勾配、偏微分、最適化 確率・統計 ベイズの定理、分布、仮説検定 ML 基礎 教師あり/なし学習、評価指標 推奨リソース Khan Academy — 数学基礎 “Mathematics for Machine Learning”(書籍) StatQuest — 統計の直感的理解 この段階のゴール 「なぜニューラルネットワークが動くのか」を数学的に説明できること。数式を書ける必要はないが、勾配降下法やベイズ推論の直感を持つことが重要です。 ...

2026年3月5日 · 4 分

Agentic AIの周期表 — 66要素で読み解くAIエージェント構築の全体像

Agentic AI の周期表 — 66 要素で読み解く AI エージェント構築の全体像 @ingliguori(Giuliano Liguori)氏のポストが話題になっています。 Agentic AI now has its own “Periodic Table”. From: LLM, RAG, RL to PLAN, MAS, LTM to SAFE, HUMAN oversight to HR, MKT, LEGAL use cases. Autonomous AI = memory + planning + tools + safety + collaboration. It’s a system, not a prompt. Capital One の Chief Scientist である Prem Natarajan 氏が、AI エージェント構築に必要な 66 の要素を化学の周期表のように体系化した「Agentic AI Periodic Table」を公開しました。LLM や RAG といった基盤技術から、メモリシステム、安全性プロトコル、業務適用まで、エージェント開発の全領域を一枚の表に凝縮しています。 ...

2026年3月5日 · 4 分

AIVideo Agent — 「動画版 OpenClaw」が24時間コンテンツパイプラインを自律運用する仕組み

AIVideo Agent — 「動画版 OpenClaw」が24時間コンテンツパイプラインを自律運用する仕組み Hasan Toor 氏(@hasantoxr、フォロワー42万人)が「動画制作の OpenClaw が登場した」と紹介して話題になっています。 BREAKING: The「OpenClaw for video production」just dropped. It’s called AIVideo Agent and it runs your entire content pipeline 24/7 entirely on its own. No API keys. No technical setup. No configuration screens. Just tell it what you want. It ships. ブックマーク 1,949、閲覧数 93,000 超と大きな反響を呼んでいるこの投稿が紹介しているのは、Y Combinator 出身の AIVideo.com が提供する Video Composer Agent です。「API キー不要、技術セットアップ不要、設定画面なし」という訴求は、OpenClaw が「チャットで指示するだけ」でタスクを実行するのと同じ発想を動画制作に持ち込んだものです。 OpenClaw が変えた「エージェント=非エンジニア向け」の期待値 AIVideo Agent が「OpenClaw for video production」と呼ばれる背景を理解するには、OpenClaw が何を変えたのかを押さえる必要があります。 ...

2026年3月5日 · 3 分

gen-ai-experiments × 130超の生成AIアプリを「動かして学ぶ」LangChain・RAG・エージェント実践集

130 超の生成 AI アプリを「動かして学ぶ」— gen-ai-experiments リポジトリ完全ガイド @alifcoder 氏が X で紹介した、生成 AI の実践的学習リポジトリが注目を集めています。 Collection of 130+ production-ready Gen AI apps, agents, and experiments. Built with LangChain, RAG, AI Agents, Multi-Agent Teams, and more. buildfastwithai/gen-ai-experiments は、130 を超える本番レベルの生成 AI アプリケーション、エージェント、実験プロジェクトを Jupyter ノートブック形式で集めたリポジトリです。LangChain、RAG、AI エージェント、マルチエージェントシステムなど、2024-2026 年の主要な AI 技術スタックを網羅しています。 本記事では、このリポジトリの構成と活用法、類似リソースとの比較、そして「動かして学ぶ」アプローチの価値を解説します。 なぜ「動かして学ぶ」が重要なのか ドキュメントだけでは身につかない 生成 AI の学習には特有の難しさがあります。 生成 AI 学習の 3 つの壁: 1. API の組み合わせの壁: LLM API 単体は簡単。だが RAG、エージェント、 ツール連携を組み合わせると複雑度が指数的に増加 2. プロンプト設計の壁: 「動くプロンプト」と「良いプロンプト」の差は ドキュメントでは伝わらない。実行して出力を見るしかない 3. 本番品質の壁: デモレベルと本番レベルの間にある エラーハンドリング、レート制限、コスト管理の知識 gen-ai-experiments は、これらの壁を動くコードで越えるアプローチを取っています。631 の Jupyter ノートブックがあり、セルを 1 つずつ実行しながら各技術の仕組みを体験できます。 ...

2026年3月5日 · 3 分

Qwen3.5-0.8B を日本語SFTしたモデル公開 — スマホで動く0.8Bパラメータの実力と小規模LLMの現在地

Qwen3.5-0.8B を日本語SFTしたモデル公開 — スマホで動く0.8Bパラメータの実力と小規模LLMの現在地 @Holy_fox_LLM 氏(ほーりーふぉっくす)のポストが、Qwen3.5-0.8B を約10万件の日本語データでフルパラメータ SFT したモデルを Hugging Face で公開しています。 Qwen3.5 0.8Bに対して約10万件超のデータを用いてフルパラでSFTしたモデルを公開しました!スマホなどの推論に最適なモデルとなっています ポストは440いいね、69リツイートと高い反響を集めています。Qwen3.5 Small シリーズが2026年3月2日にリリースされた直後のタイミングで、日本語コミュニティの素早い対応として注目されています。 Qwen3.5 Small シリーズ — 0.8B でもマルチモーダル リリースの概要 2026年3月2日、Alibaba の Qwen チームが Qwen3.5 Small シリーズを Apache 2.0 ライセンスで公開しました。0.8B、2B、4B、9B の4サイズで構成されています。 モデル パラメータ VRAM(FP16) 主な用途 Qwen3.5-0.8B 8億 約1.6GB スマホ、IoT、エッジデバイス Qwen3.5-2B 20億 約4GB 軽量サーバー、タブレット Qwen3.5-4B 40億 約8GB ローカル PC Qwen3.5-9B 90億 約18GB デスクトップ、サーバー 注目すべきは、9B モデルが OpenAI の gpt-oss-120B(13.5倍のサイズ)を GPQA Diamond ベンチマークで上回ったことです(81.7 vs 71.5)。 Gated DeltaNet アーキテクチャ Qwen3.5 Small シリーズの技術的な特徴は、Gated DeltaNet ハイブリッドアーキテクチャです。 ...

2026年3月5日 · 3 分

「MCPは死んだ、CLIに栄光あれ」— Playwright CLI が出した結論と、それでもMCPが生き残る理由

「MCPは死んだ、CLIに栄光あれ」— Playwright CLI が出した結論と、それでもMCPが生き残る理由 @swarm_ai_cloud 氏のポストが、@hiroki_daichi 氏が紹介した「MCP is dead. Long live the CLI」という記事に対して、Playwright CLI の登場を根拠に「結論が出た」と指摘しています。 今年1月、PlaywrightがCLIを出したことで結論出ましたね。 2026年2月、Eric Holmes の「MCP is dead. Long live the CLI」がHacker Newsのトップに上がり、85ポイント・66コメントを集めました。LLM にとって MCP は不要で、CLI で十分だという主張です。そして1月に Microsoft が Playwright CLI をリリースしたことで、この議論に具体的なデータが加わりました。 Eric Holmes の主張 — MCP は何の利益ももたらさない Holmes の記事は5つの論点で MCP の不要性を訴えています。 論点 主張 LLM に特別なプロトコルは不要 何百万もの man ページと Stack Overflow で訓練済み。CLI とドキュメントを渡せば十分 CLI は人間も使える 問題発生時に同じコマンドを人間が実行してデバッグできる。MCP は JSON ログの解読が必要 合成可能性 jq、grep、パイプで自由に組み合わせ可能。MCP サーバーの返すデータは固定 認証は解決済み aws、gh、kubectl は人間とエージェントの両方で動作する 可動部品がない CLI バイナリにバックグラウンドプロセスは不要。MCP サーバーは初期化で落ちることがある Holmes が特に強調したのは、MCP の実運用上の痛みです。 ...

2026年3月4日 · 3 分