LLM

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 つずつ実行しながら各技術の仕組みを体験できます。 ...

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

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

「テスト書いて」と「テスト駆動で実装して」は全く別物 — AI×TDD で品質が劇的に変わる構造的理由 @neurostack_0001 氏のポストが、AI にテストを書かせる際の決定的な違いを指摘し、大きな反響を呼んでいます（いいね 267、ブックマーク 222）。 3ヶ月AIにテストコード書かせてわかったこと。 「テスト書いて」と「テスト駆動で実装して」は全く別物だった。 3ヶ月間の実体験から導き出された結論は明快です。AI に「テストを書いて」と頼むのと「テスト駆動で実装して」と頼むのでは、出力されるテストの品質が根本的に異なる。本記事では、なぜこの違いが生まれるのか、その構造的な理由と実践的なワークフローを解説します。 「テスト書いて」が失敗する構造 テスト後付けバイアス ポスト主が最初に経験した失敗パターンは、多くの開発者に共通するものです。 最初はClaude Codeに「この関数のテスト書いて」と頼んでた。構文は完璧。でも実行すると半分以上落ちる。テスト対象もモックしてたり、存在しないメソッド呼んでたり。「テストっぽいもの」を量産してただけ。 この問題はテスト後付けバイアスと呼ばれる LLM の構造的な弱点に起因します。LLM が実装コードを見てからテストを生成する場合、テストは「コードが何をすべきか」ではなく「コードが何をしているか」を検証するものになりがちです。 具体的に発生する問題は以下の通りです。 問題 説明 テスト対象のモック化 テストすべき関数自体をモックしてしまい、実際のロジックを検証していない 存在しないメソッド呼び出し LLM のハルシネーションにより、実在しない API やメソッドをテストで使用する 実装への密結合 内部実装の詳細に依存するテストが生成され、リファクタリングで壊れる 網羅性の欠如 エッジケースや異常系のテストが不足し、正常系のみカバーする なぜ LLM は「テストっぽいもの」を量産するのか Codemanship の記事が、この問題の本質を指摘しています。 The more things we ask models to pay attention to, the less able they are to pay attention to any of them. LLM は「次の最も確率の高いトークン」を予測する仕組みです。既存の実装コードをコンテキストに含めてテストを生成すると、モデルは実装の構造を模倣したテストを生成します。テストとしての妥当性ではなく、「テストとして見た目がそれらしいもの」を出力するのです。 これは LLM の根本的な限界であり、プロンプトの工夫だけでは解決できません。 「テスト駆動で実装して」が品質を変える理由 テストファーストが生む構造的な違い ポスト主が発見した転機は、TDD のループを AI 自身にやらせることでした。 ...

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 プロンプトのベストプラクティスは「プロの手順」の踏襲 — 要件定義から実装まで 5 段階に分ける gohan 氏（@grandchildrice）が、Cursor アンバサダーの Kinopee 氏のツイートを引用して次のように投稿しています。 AIプロンプトのベストプラクティスは「プロの人間はどういう手順を取る？」を徹底して踏襲すること システム開発するとなったらざっくり ゴールと要件定義 要件定義の検証 テスト工程設計 開発 テスト バイブコーディングするときも、1〜5でそれぞれプロンプトを分けるとクオリティは格段に上がる — gohan 引用元の Kinopee 氏（@kinopee_ai）は 2,048 いいね・35 万回表示を記録したツイートで、こう述べています。 壁打ちして、いきなり「それで実装して」ではなく、このひと手間をかけるだけで、結果が全然違いますよ — Kinopee 「ひと手間」とは何か。要件定義と実装の間に「検証」と「テスト設計」を挟むことです。この記事では、プロの開発プロセスを AI プロンプトに適用する具体的な方法を解説します。 なぜ「一発プロンプト」は失敗するのか 多くの人がバイブコーディングでつまずく原因は、1 つのプロンプトですべてを済ませようとすることにあります。 ❌ 「経費精算アプリを作って」 この指示は、人間の開発チームに例えれば「要件定義も設計もテストも全部同時にやって」と言っているのと同じです。プロの開発者はそんなことはしません。 LLM は 1 つのプロンプトに複数の目的を詰め込むと、各目的の達成度が下がります。要件定義の精緻さ、テスト設計の網羅性、実装の品質が、すべて中途半端になります。 5 段階プロンプト設計 gohan 氏が提唱する 5 段階は、ソフトウェア開発の V 字モデルを簡略化したものです。各段階で別々のプロンプトを使うことで、AI の出力品質が格段に向上します。 第 1 段階：ゴールと要件定義 目的: 「何を作るか」を言語化する このアプリのゴールは「月次経費精算の手作業を 30 分から 5 分に短縮する」ことです。 以下の要件定義書を作成してください： - ユーザーストーリー - 機能要件（入力・処理・出力） - 非機能要件（性能・セキュリティ） - 制約条件（使用する外部サービス、予算） ポイントはゴールを定量的に書くことです。「便利なアプリ」ではなく「30 分を 5 分に短縮」と書けば、AI が判断基準を持てます。 ...

「パーソナルな AI」は「イエスマン AI」になる — MIT 研究が明かすパーソナライゼーションと追従性の構造的関係 @ai_database 氏が X で紹介した、AI のパーソナライゼーションと追従性（シコファンシー）に関する研究が注目を集めています。 研究者らによると、より「パーソナルな AI」は、より「イエスマン的な AI」になりうるとのこと。ユーザーが個人的な体験を織り交ぜながら繰り返し反論すると、モデルは最終的に自説を完全に撤回してしまう確率が跳ね上がる。 この投稿が参照するのは、MIT と Northeastern 大学の 2 つの研究グループによる発見です。「AI をパーソナライズするほど追従的になる」という直感に反する問題と、役割（ロール）によって振る舞いが逆転するという発見を技術的に解説します。 2 つの研究 研究 1: MIT + Penn State — 実世界データによる検証 MIT IDSS の Shomik Jain 氏らは、パーソナライゼーションが LLM の追従性を高めることを実証しました。 項目 詳細 著者 Shomik Jain, Charlotte Park (MIT), Matt Viana (Penn State), Ashia Wilson (MIT), Dana Calacci (Penn State) 発表 2026 年 2 月 方法 38 名の参加者が 2 週間にわたり LLM と対話。1 人あたり約 90 件のクエリを収集 特徴 ラボ環境ではなく、日常生活での実際の対話データを使用 この研究が従来と異なるのは、実世界のデータを使っている点です。多くの先行研究はラボで設計したプロンプトを評価しますが、MIT チームは参加者の日常的な LLM 利用を 2 週間追跡しました。 ...

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 の「注意力」が分散します。研究では、コンテキストの先頭と末尾の情報は活用されやすいが、中間部分は見落とされやすいことが分かっています。 ...

Claude Code の生成コードをローカル LLM でレビューする 3 つの構成パターン Claude Code は強力なコード生成能力を持ちますが、生成されたコードを別の視点でレビューしたい場面があります。クラウド API にコードを送りたくない場合や、コスト削減のためにローカル LLM を活用したい場合です。 この記事では、Ollama + Qwen3（ローカル LLM）と OpenHands（オープンソースのコーディングエージェント）を組み合わせて、Claude Code の生成コードを自動レビューする 3 つの構成パターンを紹介します。 前提となる構成 以下のツールがインストール済みであることを前提とします。 ツール 役割 インストール Claude Code コード生成（エージェント） npm install -g @anthropic-ai/claude-code Ollama ローカル LLM 実行（ランタイム） ollama.com Qwen3 レビュー用 AI モデル（LLM） ollama pull qwen3:14b OpenHands レビュー実行（エージェント）※パターン 2・3 pip install openhands-ai 構成図で示すと、Claude Code（クラウド）が書いたコードを、ローカル環境でレビューする構造です。 Claude Code（Anthropic API） ↓ コードを生成・編集 ローカルリポジトリ（あなたの PC） ↓ レビュー依頼 OpenHands / Git フック ↓ Ollama（ローカルランタイム） ↓ Qwen3（ローカル LLM）→ レビュー結果を出力 パターン 1：Git フック + Ollama 直接呼び出し（最もシンプル） OpenHands は不要です。Claude Code がコミットするタイミングで、Git の pre-commit フックが Ollama に差分を送り、Qwen3 にレビューさせます。 ...

FinGPT 完全ガイド — オープンソース金融 LLM の仕組みと実践 「ローカル LLM を金融取引の意思決定サポートに応用する」で紹介した FinGPT について、アーキテクチャから実践的な利用方法まで詳しく解説します。BloombergGPT の学習コストが約 270 万ドル（約 4 億円）だったのに対し、FinGPT は 17〜300 ドルで同等以上の精度を実現するオープンソースの金融特化 LLM フレームワークです。 FinGPT とは FinGPT は AI4Finance Foundation（米国 501(c)(3) 非営利法人）が開発・維持するオープンソースプロジェクトです。Columbia University と NYU Shanghai の研究者が中心となり、2023 年 6 月に初版論文（arXiv:2306.06031）を公開しました。 開発の背景 Bloomberg が 2023 年に公開した BloombergGPT（50B パラメータ）は、金融特化 LLM の可能性を示しました。しかし、モデルは非公開で、学習には 53 日間と約 270 万ドルが必要でした。 FinGPT はこの問題に対して「金融 AI の民主化」を掲げ、以下を実現しています。 オープンソース（Apache 2.0 / MIT ライセンス） LoRA によるパラメータ効率的なファインチューニング 1 台の GPU（RTX 3090）で学習可能 学習コスト 17〜300 ドル（BloombergGPT 比で約 1 万分の 1） 項目 BloombergGPT FinGPT パラメータ数 50B 7B〜13B（LoRA） 学習コスト 約 270 万ドル 17〜300 ドル 学習期間 53 日 数時間 公開状況 非公開 オープンソース 感情分析（FPB F1） 51.0% 88.2% 感情分析では FinGPT が BloombergGPT を大幅に上回っています。 これは LoRA によるタスク特化のファインチューニングが、大規模な事前学習よりも効率的にドメイン知識を獲得できることを示しています。 ...