Agent

Qwen-Agent 公式エージェントフレームワーク完全ガイド — モデル開発チームが作った「全部入り」の設計思想 @abxxai（Abdul Shakoor）のポストが、Qwen チームが公式リリースしたエージェントフレームワーク「Qwen-Agent」を紹介し、10万ビュー超・2,900ブックマーク・2,200いいねと極めて高い反響を集めています。 BREAKING: The Qwen team just shipped their official agent framework and it has everything. No stitching together third-party libraries. No fighting abstractions. 「サードパーティのライブラリをつなぎ合わせる必要がない」「抽象化と戦わなくていい」という評価は、既存のエージェントフレームワーク（LangChain、CrewAI 等）が抱える複雑さへのアンチテーゼです。 Qwen-Agent とは何か Qwen-Agent は、Alibaba Cloud の Qwen チームが開発したオープンソースのエージェントフレームワークです。Qwen 3.0 以上のモデルをベースに、Function Calling・MCP・Code Interpreter・RAG・Chrome 拡張を統合した「全部入り」のフレームワークとして設計されています。 最大の特徴: モデルとフレームワークの共進化 LangChain や CrewAI がモデルに依存しない汎用フレームワークであるのに対し、Qwen-Agent は Qwen モデルと一体的に開発されています。 観点 Qwen-Agent LangChain / CrewAI 開発元 Qwen モデル開発チーム サードパーティ モデルとの関係 共進化（同時に開発・最適化） モデル非依存 ツール呼び出し ネイティブ統合（テンプレート・パーサー内蔵） アダプタ経由 抽象化の層 薄い（モデルに直接最適化） 厚い（汎用性のための間接層） 対応モデル Qwen 系が最適、他モデルも利用可 幅広いモデルに対応 Qwen チームは「モデルの開発当初から、ツール使用と深い推論を含む強力なエージェント能力の実現が戦略の柱だった」と述べています。フレームワークはモデルの能力を最大限に引き出すために設計されており、汎用フレームワークでは到達できない最適化が実現されています。 ...

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 ハイブリッドアーキテクチャです。 ...

SBI北尾「新卒採用を大幅に減らすのは絶対命令」— AI による採用構造変化は景気回復しても戻らない @keyplayers 氏（高野秀敏）のポストが、SBI 北尾吉孝会長の新卒採用削減宣言と、みずほ FG の事務職5,000人削減を取り上げ、AI による雇用構造の不可逆な変化について論じています。47万ビュー・1,900いいね・560ブックマークと極めて高い反響を集めています。 SBI北尾さんが「新卒採用を大幅に減らすのは絶対命令」と明言した。みずほも事務職5000人分を削減する。これが現実です。 私は4000人以上の経営者と会ってきたけど、今回の流れは過去のリストラとは本質が違う。「不景気だから減らす」じゃない。「もうAIでできるから人がいらない」という構造変化。景気が回復しても、この採用枠は戻ってこない。 4,000人以上の経営者と接してきた高野氏が「過去のリストラとは本質が違う」と断言する理由は明快です。不景気による一時的なコスト削減ではなく、AI による業務代替という構造的な変化だからです。 何が起きたのか — 2つの具体的な動き SBI: 「よほど優秀でなければ採るな」 2026年3月3日、SBI ホールディングスの北尾吉孝会長は東京でのイベントで以下の発言をしました。 新卒採用を含めて、新しい採用を大幅に減らすのは絶対命令 よほど優秀でなければ採るな 北尾氏は生成 AI の登場を「革命」と呼び、こう続けています。 今世紀最大の社会変革がこれから5年の間に起こる。ついていけなければ、脱皮できない蛇と一緒で終わりになる さらに、金融業務を「完全に AI エージェント化」する方針も表明しています。顧客対応を含む金融 AI エージェントの開発に着手しており、人間の業務を AI に置き換える流れは採用だけでなく、既存業務にも及びます。 みずほ FG: 事務職15,000人のうち5,000人を削減 2026年2月、みずほ FG は今後10年で事務職を最大5,000人削減する計画を発表しました。 項目 内容 現在の事務職員数 約15,000人 削減目標 最大5,000人（3分の1） 期間 10年 方法 配置転換 + 採用抑制 + 自然減（解雇ではない） AI 投資額 3年間で最大1,000億円 転換先 個人向け営業、グループ業務支援 注目すべきは「解雇ではなく配置転換」としている点です。日本の雇用慣行では即座の解雇は難しいため、採用抑制と自然減を組み合わせた「緩やかな縮小」が取られます。しかし、これは新卒の採用枠が10年間にわたって縮小し続けることを意味します。 なぜ「景気が回復しても戻らない」のか 高野氏の指摘で最も重要なのは「景気が回復しても、この採用枠は戻ってこない」という点です。 過去のリストラ vs AI リストラ 過去のリストラ（2008年〜） AI リストラ（2026年〜） 原因 不景気・業績悪化 技術による業務代替 性質 景気循環（一時的） 構造変化（不可逆） 景気回復時 採用枠が復活 採用枠は戻らない 対象 全社的なコスト削減 特定業務の消滅 代替先 外注・派遣 AI エージェント 構造変化の不可逆性 従来の景気循環: 好景気 → 大量採用 → 不景気 → リストラ → 好景気 → 大量採用 ... （サイクルが繰り返される） AI による構造変化: AI 導入 → 業務自動化 → 採用削減 → 好景気 → AI がさらに改善 → さらに削減 （戻る力が働かない） AI エージェントが事務業務を処理できるようになると、景気が回復しても「また人を雇って同じ仕事をさせよう」とはなりません。AI の方が速く、安く、ミスが少ないからです。 ...

Shannon — 自律型 AI ペネトレーションテスターが「実証なき報告」を終わらせる @heynavtoor 氏のポストが話題になっています。 Someone just open sourced a fully autonomous AI hacker and it’s terrifying. It’s called Shannon. Point it at your web app, and it doesn’t just scan for vulnerabilities. It actually exploits them. Shannon は「No Exploit, No Report（実証できなければ報告しない）」を原則とする、完全自律型の AI ペネトレーションテストツールです。従来のスキャナーが「ここが危険かもしれません」と警告を出す場面で、Shannon は実際に攻撃を実行し、成功した場合だけ報告します。XBOW ベンチマークで 96.15% のスコアを記録し、GitHub で 10,000 以上のスターを獲得しています。 なぜ Shannon が注目されるのか — 年 1 回ペンテストの限界 現代の開発チームは Claude Code や Cursor を使い、毎日コードを出荷しています。一方、ペネトレーションテストは年 1 回が一般的です。365 日のうち 364 日は「検証なし」で本番にデプロイしている計算になります。 ...

.env を AI に安心して触らせる — 1Password CLI ラッパー「opx」とプロセススコープ認証の設計 @suin 氏のポストが、AI エージェント時代の .env 管理問題に対する実践的な解決策として、自作の 1Password CLI ラッパー「opx」を公開しています。 .envをAIに安心して触らせたくて、こんなの作った AIエージェントなしではもう開発が成り立たないほど必須になってきています。権限設定がいろいろできるにせよ、本質的にAIエージェントにはプロジェクトの全ファイルを触りうる力を与えているわけで、気になるのがシークレットなどの機密情報です。 Claude Code や Cursor などの AI コーディングエージェントは、開発者と同じ権限でファイルシステムにアクセスします。.env にアクセストークンや AWS キーを平文で書いていれば、エージェントはそれを読めてしまいます。この構造的な問題に対し、「.env に機密情報を一切書かない」というアプローチで解決するのが opx です。 問題の構造 — AI エージェントが .env を読める なぜ危険なのか AI コーディングエージェントは通常のプロセスとして動作し、シェル環境を継承します。 開発者のシェル └── AI エージェント（Claude Code, Cursor 等） ├── ファイルシステムへのフルアクセス ├── .env ファイルの読み取り ├── 環境変数の参照 └── Bash コマンドの実行 .zshrc に AWS_SECRET_ACCESS_KEY を書いていれば、エージェントもそれを持っています。プロンプトインジェクション攻撃を受けた場合、エージェントが意図せず機密情報を外部に送信するリスクがあります。 実際に報告されている脆弱性 2025年末に公開された「IDEsaster」と呼ばれる調査では、Cursor、Windsurf、GitHub Copilot、Cline など30以上の AI IDE に脆弱性が発見されています。OpenAI Codex CLI では .env ファイルを経由した任意コマンド実行の脆弱性（CVE-2025-61260）も報告されました。 ...

「Claude Codeが無料で使える最強AIエージェント」は本当か — Accomplish の実態とAI煽りの再来 ガガロットAI(@gagarotai200)氏のポストが604いいね、764ブックマーク、約42,000表示と大きな反響を呼んでいます。 『Claude Code』が無料で使える最強AIエージェントが登場したww Accomplishっていうローカルで動くAIエージェントがGitHubに上がってたから共有する。これ入れれば、Claude Codeレベルの AIエージェントがサブスク購入なしで永遠に使えるwww — ガガロットAI(@gagarotai200) この投稿者は、以前「OpenClawで5人解雇」という根拠不明の煽りポストでも注目を集めた人物で、AIスクールを運営しています。今回も「最強」「無料」「永遠に使える」というキーワードが並んでいますが、主張はどこまで正確なのでしょうか。Accomplish の実態を公式情報から検証します。 Accomplish とは何か Accomplish は2026年1月13日に公開されたオープンソース（MITライセンス）のデスクトップ AI エージェントです。GitHub Stars 9.6k、Forks 1k、コントリビューター31名と、一定の支持を集めています。 基本情報 項目 内容 開発元 accomplish-ai ライセンス MIT 技術スタック Electron + React + TypeScript 対応OS macOS（Apple Silicon / Intel）、Windows 11 最新バージョン 0.3.10 内部構造 OpenCode CLI を node-pty 経由で起動 主要機能 ブラウザ自動化: Web検索、フォーム入力、データ抽出 ファイル管理: フォルダ整理、ファイル名変更、コンテンツベースの分類 ドキュメント作成: レポート作成、要約、メール下書き ワークフロー自動化: 反復タスクの自動化 対応 AI モデル カテゴリ プロバイダー クラウドAPI Anthropic（Claude）、OpenAI、Google AI、xAI、DeepSeek、Moonshot AI 等 クラウドインフラ Amazon Bedrock、Azure Foundry、OpenRouter、LiteLLM ローカル Ollama、LM Studio 主張の検証 主張1: 「Claude Codeレベルの AIエージェント」 検証結果: 大幅に誇張 ...

「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 の実運用上の痛みです。 ...

236 件の AI 案件データが明かす「発注企業とベンダーの 2.5 年のズレ」— AI 受託開発市場の構造的ギャップと勝ち筋 @1edec 氏が X で公開した記事が注目を集めています。 ある製造業の担当者は、こんなことをおっしゃっていました。「役員から『AI を検討せよ』と言われたんですが、何から始めればいいかわからなくて。とりあえず相談した感じです」 @1edec 氏は 236 社の AI 関連商談データを分析し、発注企業が求めるものと AI 受託ベンダーが提供するものの間に2〜2.5 年の時間的ズレが存在することを指摘しています。本記事では、この分析が示す AI 受託開発市場の構造的ギャップと、ベンダーが取るべき戦略を解説します。 236 件の商談データが語る現実 発注企業が実際に求めているもの 236 件の商談データから浮かび上がるのは、**最先端 AI ではなく「目の前の業務課題の解決」**を求める企業の姿です。 発注企業が口にする課題キーワード: 「Excel の転記を自動化したい」 「手書き帳票をデジタル化したい」 「問い合わせ対応を効率化したい」 「在庫管理を最適化したい」 「議事録を自動で作成したい」 これらは LLM やマルチモーダル AI のような最先端技術を必要とするものではありません。OCR、RPA、チャットボットなど、既に成熟した技術で解決できる課題がほとんどです。 ベンダーが提案するもの 一方、AI 受託ベンダーの多くは、最先端の技術を前面に押し出します。 ベンダーが提案しがちな内容: 「生成 AI で業務を革新」 「LLM を活用した次世代システム」 「AI エージェントによる自律的な業務処理」 「マルチモーダル AI で非構造データを統合分析」 ここに2〜2.5 年のギャップが生まれます。ベンダーは 2026 年の最先端を提案しますが、発注企業が必要としているのは 2023〜2024 年に成熟した技術で解決できる課題なのです。 なぜ 2.5 年のズレが生まれるのか キャズム理論で読み解く AI 普及の現在地 この構造を理解するには、ジェフリー・ムーアが提唱したキャズム理論が有効です。 技術普及の 5 段階: イノベーター（2.5%） → 技術そのものに価値を見出す。PoC を自ら回す アーリーアダプター（13.5%） → 競争優位のために新技術を積極採用 ──── キャズム（深い溝） ──── アーリーマジョリティ（34%） → 「実績はあるか」「安全か」を重視。確実性を求める レイトマジョリティ（34%） → 周囲が使い始めてから導入 ラガード（16%） → 必要に迫られるまで動かない 236 件の商談データに現れる企業の多くは、アーリーマジョリティ以降の層です。「役員から AI を検討せよと言われた」という動機は、イノベーターやアーリーアダプターの特徴ではありません。「周囲がやり始めたから、うちも」という圧力で動き出した企業です。 ...

AIエージェント「デモ→本番」95%脱落 × 4つの壁とエージェンティックRAG実践 Femke Plantinga さんが、AIエージェントのデモと本番環境のギャップについて、Stack AI・Weaviate と共同作成した無料ガイドを公開しています。 95% of AI agent demos never make it to production. Yet 79% of enterprises expect full-scale agentic AI adoption within three years. So what’s the disconnect? https://x.com/femke_plantinga/status/2029134837890621844 48 いいね・8 RT を集めたこのポストが指摘するのは、AIエージェントの「デモでは動く」と「本番で使える」の間にある巨大なギャップです。MIT の調査（GenAI Divide: State of AI in Business 2025）でも、エンタープライズ向け生成AIシステムのうち本番環境に到達するのは**わずか5%**という数字が報告されています。 95%が脱落する現実 複数の調査が、AIエージェントのデモ→本番の落差を裏付けています。 調査・出典 数字 MIT GenAI Divide 2025 本番到達は全体の 5% 企業調査（探索中 30%、パイロット 38%、デプロイ準備 14%、本番稼働 11%） パイロットから先に進めない Gartner 予測 2027年までにエージェンティックAIプロジェクトの 40%以上が中止 AI施策全般 90〜95%が持続的な本番価値を提供できず、ROI達成は 12%未満 問題はモデルの性能ではなく、自律システムを運用するエンジニアリング規律の欠如です。 ...

AnimaWorks 脳科学5層記憶 × マルチエージェント「文脈崩壊」問題への解答 まさお@AI駆動開発さんが、マルチエージェントの最大の課題である「長期タスクで文脈が壊れる」問題に対して、脳科学ベースの記憶システムで挑むOSS「AnimaWorks」を紹介しています。 マルチエージェントの最大の課題「長期タスクで文脈が壊れる」に、脳科学ベースの記憶システムで挑んでいるOSSがある。それが『AnimaWorks』。エージェントを「ステートレスな関数」ではなく「組織の中の人」として設計するフレームワーク。 https://x.com/AI_masaou/status/2029134762447667373 21 いいね・2 RT を集めたこのポストが注目するのは、従来のマルチエージェントが抱えるコンテキストウィンドウの限界を、「記憶の蓄積・整理・忘却」というサイクルで乗り越えようとする設計思想です。 マルチエージェントの「文脈崩壊」問題 LLM の「記憶」の仕組み まず前提として、LLM（ChatGPT や Claude など）には人間のような記憶がありません。LLM が「覚えている」ように見えるのは、会話の全履歴を毎回テキストとして入力に含めているからです。この入力テキスト全体をコンテキストウィンドウと呼びます。 ┌─────────────────────────────────────┐ │ コンテキストウィンドウ（例: 200K トークン） │ │ │ │ システム指示 │ │ ユーザー: こんにちは │ │ AI: こんにちは！ │ │ ユーザー: Pythonで関数を書いて │ │ AI: def hello(): ... │ │ ...（数百ターンの会話履歴） │ ← 会話が長くなるほど膨らむ └─────────────────────────────────────┘ ウィンドウの物理的限界 コンテキストウィンドウには上限があります（Claude で約 200K トークン、日本語で約 10〜15 万文字）。長期タスクでは会話履歴がこの上限に達し、古い情報から順に切り捨てられます。 タスク開始時: 「このプロジェクトでは認証にJWTを使う方針です」 ← 重要な初期方針 ... 200ターン後 ... 「ログイン機能を実装して」 → エージェントは JWT の方針を忘れており、 セッション認証で実装してしまう 注意力の希釈（Lost in the Middle） ウィンドウ内に収まっていても、情報量が多すぎると LLM の「注意力」が分散します。研究では、コンテキストの先頭と末尾の情報は活用されやすいが、中間部分は見落とされやすいことが分かっています。 ...