記事一覧

OpenFang — Rust 製シングルバイナリの「エージェント OS」が再定義する自律型 AI の設計 @mikefutia 氏が X で紹介した OpenFang v0.3.7 のリリースが注目を集めています。 OpenFang v0.3.7 is out! here’s everything since v0.3.3 OpenFang は RightNow AI の創設者 Jaber 氏が開発する、Rust で一から構築されたオープンソースのエージェントオペレーティングシステムです。チャットボットフレームワークではなく、自律的にタスクを実行する「エージェント OS」を標榜しています。2026 年 2 月 24 日の公開から 4 日で GitHub スター 4,037 を獲得し、パーソナル AI エージェント領域で最速級の立ち上がりを見せました。 本記事では、OpenFang のアーキテクチャ、独自の「Hands」機構、Python 製フレームワークとの構造的な違いを技術的に解説します。 なぜ「エージェント OS」なのか チャットボットフレームワークとの違い LangChain や CrewAI のような既存のエージェントフレームワークは、基本的にユーザーのプロンプトを起点に動作します。ユーザーが指示を出し、エージェントが実行し、結果を返す。この対話ループが基本構造です。 OpenFang が「OS」と名乗る理由は、プロンプトなしで自律的に動作する設計にあります。 既存フレームワーク: ユーザー → プロンプト → エージェント → 結果 → ユーザー （対話ループ） OpenFang: スケジュール → エージェント → タスク実行 → 知識グラフ更新 ↓ ダッシュボードに報告 （自律ループ、ユーザーの介入は承認ゲートのみ） 24 時間 365 日、バックグラウンドでエージェントが動き続ける。リード獲得、競合監視、SNS 投稿、コンテンツ生成を自動で行い、ユーザーはダッシュボードで結果を確認する。これが OpenFang の設計思想です。 ...

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 日は「検証なし」で本番にデプロイしている計算になります。 ...

Swift for Android vs Kotlin Multiplatform — マルチプラットフォーム時代の「Xbox vs PlayStation」 Level Up Coding の記事（Jacob Bartlett 氏）が注目を集めています。同じローラーコースターアプリを Swift for Android と Kotlin Multiplatform（KMP）の両方で構築し、開発体験を徹底比較した実践レポートです。 著者はこの 2 つの技術を「Xbox vs PlayStation」に例えています。どちらも「ビジネスロジックを共有し、UI はネイティブで書く」という同じアーキテクチャ思想を持ちながら、アプローチが正反対です。iOS 開発者が Android に進出するか、Android 開発者が iOS に進出するか — その出発点の違いが設計全体に反映されています。 2 つのアプローチ — 同じ目的、逆の方向 両技術の根本的な違いは「どちらのプラットフォームを起点にするか」です。 Swift for Android: iOS (SwiftUI) ← Swift コア → Android (Jetpack Compose) "iOS ファーストの開発者が Android に展開" Kotlin Multiplatform: Android (Jetpack Compose) ← Kotlin コア → iOS (SwiftUI) "Android ファーストの開発者が iOS に展開" 項目 Swift for Android Kotlin Multiplatform 共有言語 Swift Kotlin コンパイル方式 Swift → ネイティブ .so（JNI 経由） Kotlin → ネイティブバイナリ（Obj-C ヘッダ生成） Android 側 UI Jetpack Compose Jetpack Compose iOS 側 UI SwiftUI SwiftUI 境界技術 JNI + swift-java 自動バインディング Kotlin/Native + Obj-C 互換 開発開始年 2025 年（プレビュー） 2017 年 Swift for Android の仕組み — swift-java と JNI Swift for Android は 2025 年 10 月に公式プレビューとしてリリースされました。Swift Android Workgroup が Swift.org の公式ワークグループとして設立され、Android を Swift の正式サポートプラットフォームにする取り組みが進行中です。 ...

.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 Ads」の正体 — Anthropic 公式ではない個人開発スキルが日本でバズった構造を解剖する @lapper_s_high 氏のポストが、「Claude Ads」の名前が引き起こした混乱を端的に指摘しています（いいね 482）。 開発者も日本でこんなに話題になるなんて思わなかったのでは・・ Claude Adsなんて名前つけるから。。 引用元の @ryottaman 氏のポスト（表示 27万、ブックマーク 390）が拡散の起点となり、日本の SNS では「Anthropic が広告運用ツールを出した」という誤解が広がりました。 実際には、Claude Ads は **Anthropic の公式製品ではなく、個人開発者が GitHub に公開した Claude Code 向けのスキル（拡張機能）**です。本記事では、なぜこの混乱が起きたのか、Claude Ads の実態は何なのか、そして Claude Code のスキルシステムがどのように機能するのかを解説します。 なぜ混乱が起きたのか — 3つの偶然の重なり 偶然1: Anthropic のスーパーボウル CM 2026年2月、Anthropic はスーパーボウル第60回大会で CM を放映しました。キャッチコピーは 「Ads are coming to AI. But not to Claude.」（広告は AI にやって来る。だが、Claude には来ない）。OpenAI が ChatGPT への広告導入を発表した直後のタイミングで、「Claude は広告を入れない」と宣言する内容でした。 この CM は大きな話題となり、OpenAI の Sam Altman CEO が「面白いが明らかに不誠実」と反論する事態にまで発展しています。 偶然2: 「Claude Ads」という名前 その直後、個人開発者の Daniel Agrici 氏が GitHub に公開したのが claude-ads です。これは Claude Code で広告アカウントを監査するスキルであり、「Claude を使って Ads（広告）を分析する」という意味での命名でした。 ...

「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エージェント」 検証結果: 大幅に誇張 ...

「Figma は 100% 不要」宣言の真意 — Claude Code が溶かすデザインとコードの境界 @kawai_design 氏が X で公開した記事が議論を呼んでいます。 Claude Code を使えば使うほど、Figma を開く理由が消えていく。これは私だけの感覚ではありません。今、世界中のデザイナーが同じ疑問を抱えています。私の結論は明確です。Figma は 100% 不要。 同時期に UX Collective に掲載された Michael Buckley 氏の記事「Figma はデザインツールではない。コードを避けるためのピタゴラスイッチだ」も世界のデザイナーを震撼させました。本記事では、この「Figma 不要論」の構造と、Figma 自身の対応、そして AI 時代のデザインワークフローの変化を技術的に整理します。 「ピタゴラスイッチ」批判 — 何が問題なのか UX Collective の記事が突いた急所 Michael Buckley 氏の記事は、Figma でのデザイン作業を**ルーブ・ゴールドバーグ・マシン（ピタゴラスイッチ）**に例えました。 Figma でボタンを作る作業: 1. Auto Layout を設定する 2. パディングを調整する 3. ホバーステートを作る 4. インタラクションを設定する 5. プロトタイプモードで動作確認する 6. 開発者に引き渡す 7. 開発者がコードで再実装する 開発者が同じボタンを作る作業: <button className="btn-primary">送信</button> → 5 分で完了。ホバー、アクセシビリティも含めて 「パンケーキを返すためにピタゴラスイッチを作るようなもの」— この比喩が刺さったのは、多くのデザイナーが無意識にこの非効率を受け入れていたからです。 本質的な問題: デザインとコードの「翻訳」 Figma の存在意義はデザインとコードの間の翻訳レイヤーにあります。 従来のワークフロー: デザイナーの意図 → Figma でビジュアル化（翻訳 1） → デザインスペック作成（翻訳 2） → 開発者がコードに変換（翻訳 3） → 実装結果をデザイナーがレビュー（逆翻訳） 翻訳のたびに情報が劣化する: - ピクセルのズレ - インタラクションの解釈違い - レスポンシブ挙動の不一致 - アクセシビリティの抜け漏れ AI がデザインの意図を理解し、直接コードを生成するようになれば、この翻訳プロセス自体が不要になります。@kawai_design 氏の「翻訳の元データである Figma ファイルも要りません」という指摘は、ここに根ざしています。 ...