Github

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 によるタスク特化のファインチューニングが、大規模な事前学習よりも効率的にドメイン知識を獲得できることを示しています。 ...

GitHub Copilot CLI の /research コマンド — コミットログも Actions 履歴も全部調べてくれるディープリサーチ @07JP27 氏が X で連続投稿し、GitHub Copilot CLI の /research コマンドの威力を紹介しています。 /research コマンドすげえ。Web を Deep Research してくれるのはもちろん、紐づくリポジトリのコミットログとか GitHub Actions の実行履歴まで全部見てくれて「お前のこのときのコミットのここが原因だぞ。Actions のログにもこう出てるだろ」みたいなことを言ってくる。 元の投稿では Qiita 記事（@shyamagu 氏の解説）も参照されており、MCP ツール連携や WorkIQ との統合例が紹介されています。本記事では、/research コマンドの技術的な仕組みと、Claude Code との比較を交えて解説します。 /research コマンドとは 概要 2026 年 2 月 25 日、GitHub Copilot CLI が全有料プラン向けに一般提供（GA）を開始しました。同日リリースの v0.0.417 で追加された /research コマンドは、ディープリサーチ専用のスラッシュコマンドです。 通常のチャットが速度重視なのに対し、/research は徹底性（thoroughness）を重視します。複数のツールを呼び出しながら情報を収集し、数百行に及ぶ Markdown レポートを生成します。 1 2 3 4 5 # 基本的な使い方 /research Azure App Service の 2026 年の新機能 # MCP ツールを明示的に指定 /research microsoft-docs ツールを使って Azure App Service の新機能を調査してください 3 つのクエリ分類 /research はクエリを自動分類し、回答形式を最適化します。 ...

labor-law-mcp — Claude の労務ハルシネーションを防ぐ MCP サーバーと「一次情報 / 二次情報」の設計思想 sabaaji0113氏のポストが、労務法令の条文と通達を Claude に提供する MCP サーバー「labor-law-mcp」の公開を告知し、804いいね、143RT、937ブックマーク、約63,000表示と大きな反響を呼んでいます。 税務より苦労した！！労務MCPサーバー「labor-law-mcp」を公開しました。Claudeが労務の質問に答えるとき、条文や通達のハルシネーションを防ぐためのMCPサーバーです。 — sabaaji0113 このプロジェクトが注目される理由は3つあります。第一に、法律というハルシネーションが許されない領域で一次情報への直接アクセスを実現していること。第二に、先行する税法版（tax-law-mcp）のアーキテクチャを応用し、取得できない情報を「ごまかさない」設計を導入したこと。第三に、社労士・会計事務所という明確な実務ユーザーを想定していることです。 labor-law-mcp の全体像 基本情報 項目 内容 開発者 kentaroajisaka GitHub kentaroajisaka/labor-law-mcp npm labor-law-mcp ライセンス MIT 言語 TypeScript 99.4% Stars 35 対応法令数 45法令 6つのツール ツール データソース 機能 get_law e-Gov 法令API v2 法令名 + 条番号で条文を Markdown 形式で取得 search_law e-Gov 法令API v2 キーワードで法令を横断検索 search_mhlw_tsutatsu 厚労省法令等DB 厚労省通達をキーワード検索 get_mhlw_tsutatsu 厚労省法令等DB 通達本文を HTML→テキスト変換して取得 search_jaish_tsutatsu 安全衛生情報センター 安衛法関連通達を検索 get_jaish_tsutatsu 安全衛生情報センター 安衛通達本文を取得 対応法令（45法令・6カテゴリ） カテゴリ 主要法令 労働基準 労働基準法、労働契約法、最低賃金法、同施行令・規則 労働安全衛生 労働安全衛生法、じん肺法、同施行令・規則 労働保険 労災保険法、雇用保険法、労働保険料徴収法 雇用対策 職業安定法、労働者派遣法、障害者雇用促進法 均等・ワークライフバランス 育児介護休業法、男女雇用機会均等法、パート有期法 社会保険 健康保険法、厚生年金保険法、国民年金法、介護保険法 略称にも対応しています。「労基法」「安衛法」「育介法」「健保法」「パワハラ防止法」など12の略称で自然に質問できます。 ...

macOS Keychain で .env のシークレットを守る — 1Password 不要、無料で実現する AI エージェント時代の秘密管理 前回の記事で、@suin 氏の opx を紹介しました。1Password CLI をラップし、.env に op:// 参照だけを書くことで AI エージェントからシークレットを守るツールです。 しかし、opx には 1Password の契約（月額 $2.99〜）が前提という制約があります。実は macOS には Keychain という強力な秘密管理基盤が標準搭載されており、追加コストなしで同等の「プロセススコープ認証」を実現できます。本記事では、macOS 組み込み機能だけで .env の秘密を守る方法を、ツール選定から実践設定まで解説します。 なぜ macOS Keychain なのか 1Password との比較 項目 1Password + opx macOS Keychain コスト 月額 $2.99〜 無料（OS 標準） インストール 1Password アプリ + CLI + opx 不要（security コマンドが標準搭載） チーム共有 Vault 共有で容易 端末ローカル（共有には別の仕組みが必要） クラウド同期 1Password クラウド iCloud Keychain で Apple デバイス間は同期可能 Touch ID op run 時に認証 Keychain アクセス時に認証（設定が必要） Linux 対応 1Password CLI あり gnome-keyring / KeePassXC で代替 暗号化 1Password 独自（AES-256-GCM） macOS Keychain（AES-256） 個人開発やスモールチームなら、macOS Keychain で十分です。チーム全体でシークレットを共有したい場合は 1Password の Vault 共有が優位ですが、「AI エージェントに .env を読まれても安全にする」という目的だけなら無料で実現できます。 ...

Theatre.js — GUI でWebアニメーションを直感的に作れるモーションデザインエディタ しば（@shiba_program）氏のポストが、GUI でWebアニメーションを作成できる JavaScript ライブラリ「Theatre.js」を紹介しています。 GUIで直感的にWebアニメーションが作れる「theatre.js」すごいな。編集した内容が即座に反映されるので、これは微調整捗る。GUIで編集できるから、デザイナーに調整任せることもできそう。デモにある高度なものだけでなく、Webサイトで使うシンプルなアニメーションの作成もかなり楽にしてくれるはず — しば（@shiba_program） 投稿が注目している「デザイナーに調整を任せられる」という点は、Theatre.js の設計思想の核心です。コードでアニメーション対象を定義し、ブラウザ上の GUI エディタで動きを調整する。このワークフローにより、エンジニアとデザイナーの協業が自然に成立します。 Theatre.js とは何か Theatre.js はフィンランド・ヘルシンキの Theatre.js Oy が開発するオープンソースの Web モーションデザインライブラリです。GitHub Stars 12.2k、1,600以上のプロジェクトが依存しており、Web アニメーション領域で確固たる地位を築いています。 基本情報 項目 内容 開発元 Theatre.js Oy（ヘルシンキ） ライセンス Apache 2.0（@theatre/core）/ AGPL 3.0（@theatre/studio） 言語 TypeScript 82.6% GitHub Stars 12.2k 現バージョン 0.5（1.0 開発中） 対応技術 Three.js、React Three Fiber、HTML/SVG、任意のJSライブラリ 2つのパッケージ構成 Theatre.js は2つの独立したパッケージで構成されます。 パッケージ 役割 使用場面 @theatre/core アニメーション再生エンジン 開発・本番の両方 @theatre/studio GUI エディタ（シーケンスエディタ、グラフエディタ、プロパティパネル） 開発時のみ この分離設計が重要です。Studio は開発時にのみ使い、本番ビルドには core だけを含めます。エディタのコードが本番バンドルに入らないため、パフォーマンスへの影響はありません。 4つの基本概念 Theatre.js には、理解すべき4つの概念があります。 ...

AI が書いたコードに「なぜそうなったか」の記録はあるか — git-memento と AI コード追跡の新標準 @SatoshiSsSs 氏が X で投稿した、git-memento に関する解説が注目を集めています。 AIが書いたコードに「なぜそうなったか」の記録はあるか？ Hacker News（HN）で議論になっている git-memento を読み解く Hacker News での議論では、AI が生成したコードのセッション履歴をコミットに紐づけるべきか否かが活発に議論されています。AI コーディングの普及とともに、「コードは動くが、なぜその実装になったのか誰も分からない」という問題が深刻化しています。本記事では、この問題の構造と、git-memento をはじめとする解決策の技術的な仕組みを掘り下げます。 問題 — AI が書いたコードの「なぜ」が消えている Vibe Coding 時代の追跡可能性の危機 2026 年、AI コーディングツール（Claude Code、Cursor、GitHub Copilot など）でコードを書くことが日常になりました。しかし、AI が生成したコードには構造的な問題があります。 従来の開発: 開発者が考える → コードを書く → コミットメッセージに意図を記録 → 「なぜそうしたか」は開発者の頭の中 + コミット履歴にある AI 駆動開発: 開発者が指示する → AI が考える → AI がコードを書く → コミット → 「なぜそうなったか」は AI セッションの中に閉じている → セッションが終わると消える CodeRabbit の分析（2025 年 12 月）によると、AI と共著されたコードは人間が書いたコードと比較して、ロジックエラーが 75% 多く、セキュリティ脆弱性が 2.74 倍多いとされています。問題が発見されたとき、「なぜこの実装になったのか」を遡れなければ、修正の方針すら立てられません。 ...

AnimaWorks — 「AIだけの会社組織」を作る日本発フレームワークの設計思想 りょうま(@ryoma_nakajima)氏のポストで紹介された「AnimaWorks」が注目を集めています。 日本人が開発している「AIだけで作る会社組織」フレームワークを試してみる。AIに性格を指定するところから始まるのが近未来感すごすぎて好き — りょうま(@ryoma_nakajima) 72,000超の表示、447ブックマークという反響は、「AIエージェントに組織を作らせる」というアイデアへの強い関心を示しています。元になったげれげれ(@medmuspg)氏のポストでは、OpenClawとの違いを「1人の優秀なAI秘書」と「AIだけの会社組織」という対比で説明しています。 本記事では AnimaWorks の設計思想を掘り下げ、マルチエージェントフレームワークの現在地を整理します。 AnimaWorks とは何か AnimaWorks は「Organization-as-Code」を標榜する、自律型AIエージェントチームのためのオープンソースフレームワークです。Apache License 2.0で公開されており、10,600行以上のPythonコードで構成されています。 コアの思想は明快です。 “Imperfect individuals collaborating through structure outperform any single omniscient actor."（不完全な個体が構造を通じて協力すれば、単一の全知の存在を凌駕する） 項目 内容 開発者 xuiltul（日本人開発者） 言語 Python（10,600行以上） ライセンス Apache License 2.0 対応モデル Claude, GPT-4o, Gemini, Mistral, Ollama 等 実行モード 4種（Claude Agent SDK / Codex SDK / LiteLLM / Basic） UI Webダッシュボード + 3Dワークスペース + 音声チャット OpenClaw との決定的な違い OpenClaw と AnimaWorks は同じ「AIエージェント」カテゴリに分類されますが、設計思想が根本的に異なります。 観点 OpenClaw AnimaWorks 設計思想 1人の優秀なAI秘書 AIだけの会社組織 エージェント数 基本は1体（拡張でマルチ可） 最初からマルチエージェント前提 関係性 ユーザーとエージェントの1対1 上司・部下の階層構造 記憶 コンテキストウィンドウ依存 神経科学に着想を得た永続記憶 通信 ユーザーへの応答 エージェント間の非同期メッセージング カプセル化 なし（透過的） 各エージェントの内部は他から不可視 開発元 Peter Steinberger（オーストリア、現OpenAI） xuiltul（日本） この違いは単なる機能差ではなく、組織論に基づく設計かどうかの差です。AnimaWorks は「不完全な個体の協力」を前提に設計されており、現実の企業組織と同じく、情報の非対称性やコミュニケーションコストを意図的に組み込んでいます。 ...

Claude Code / MCP を安全に使うための実践ガイド — settings.json の多層防御と deny の落とし穴 セキュリティ研究者のyousukezan氏（バグバウンティプログラムでランク1位受賞歴あり）が紹介した Zenn 記事「Claude Code / MCP を安全に使うための実践ガイド」が注目を集めています。165いいね、161ブックマークという反響は、Claude Code のセキュリティ設定に対する実務者の強い関心を示しています。 本記事では元記事の内容を掘り下げつつ、公式ドキュメントや GitHub Issues の情報を加えて、実務で本当に機能するセキュリティ設定を整理します。 背景 — 8桁後半の被害事例 この記事が書かれた背景には、AI コーディングツール経由で Google Ads の MCC が乗っ取られ、8桁後半の被害が発生した事例があります。報告された4つの攻撃ベクターは全て Claude Code / MCP の利用シーンで再現可能です。 攻撃ベクター Claude Code での該当リスク 間接プロンプトインジェクション Webページに埋め込まれた隠し指示をAIが実行 プロンプトサプライチェーン攻撃 外部から取得した CLAUDE.md / settings.json / .mcp.json の改ざん MCP権限悪用（Tool Poisoning） 許可済みMCPツールの悪意ある利用 クレデンシャルリーク トークンやAPIキーのログ・git履歴への残存 最も重要な3つの設定 元記事が推奨する最小限の設定は3つです。 1. bypassPermissions モードの無効化 1 2 3 4 5 { "permissions": { "disableBypassPermissionsMode": "disable" } } --dangerously-skip-permissions フラグは全ての承認プロンプトをスキップします。公式ドキュメントによると、このモードではClaude がファイルの削除、破壊的なコマンドの実行、不可逆な変更を承認なしで行えます。disableBypassPermissionsMode: "disable" で組織全体でこのモードを禁止できます。 ...

dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス AI エージェントが .env ファイルを読み取るリスクが現実のものとなり、平文の .env を代替するツールが続々と登場しています。本シリーズでは aws-vault、lkr、dotenvx + 1Password CLI をそれぞれ解説してきました。 しかし「結局どれを使えばいいのか」という疑問が残ります。本記事では、4つのツールの守備範囲・強み・限界を比較し、チーム構成や開発環境に応じた選択指針を提示します。 4ツールの守備範囲 最も重要な違いは管理対象の範囲です。 ツール 管理対象 DB接続 SaaS キー LLM API キー AWS 認証 aws-vault AWS 認証情報のみ - - - 対応 lkr LLM API キー（8社） - - 対応 - dotenvx .env に書ける全て 対応 対応 対応 対応 1Password CLI 全種類 対応 対応 対応 対応 aws-vault と lkr は特定領域に特化したツールです。.env に含まれる全てのシークレットをカバーするには、dotenvx か 1Password CLI が必要になります。 各ツールの強みと弱み aws-vault 1 $ aws-vault exec dev -- python manage.py runserver 強み 弱み STS 一時認証（15分〜で自動失効） AWS 認証情報しか管理できない AssumeRole による権限分離 macOS 限定（Keychain 依存） MFA 統合 チーム共有不可 漏洩しても短時間で無効化される 最大の強みは STS による一時認証です。他のどのツールも「漏洩しても自動で失効する」認証情報は提供できません。aws-vault が発行する一時認証情報は、仮に AI エージェントに読まれても最短15分で失効します。 ...

個人のファインチューニング済みモデルを P2P で相互利用する — 分散 MoE で「みんなの AI」は成立するか 先の記事「オープンソース AI は『無料』でも『民主化』でもない」で取り上げた Dario Amodei の指摘 — 推論には高価な計算資源が必要であり、重みの公開だけでは真の民主化にならない — に対して、興味深い反論の構想があります。 Qwen 3.5 のような軽量モデルを各個人が自分のドメインでファインチューニングし、P2P ネットワークで互いのエージェントに相互利用させれば、大規模 LLM と同等の仕組みを分散的に構築できるのではないか? この構想を技術的に検証します。 構想の全体像 — 分散 Mixture of Experts この発想は、商用 LLM の内部で使われている Mixture of Experts（MoE） アーキテクチャを、P2P ネットワーク上に展開したものと捉えることができます。 個人A: Qwen 3.5 (法律ドメインでファインチューニング) 個人B: Qwen 3.5 (医療ドメインでファインチューニング) 個人C: Qwen 3.5 (プログラミング特化) 個人D: Qwen 3.5 (会計・税務特化) 個人E: Qwen 3.5 (マーケティング特化) ↓ P2P ルーティングレイヤー（質問の性質に応じて最適なノードを選択） ↓ エージェントが複数の専門モデルを横断的に活用 商用 LLM が「1 つの巨大なモデル内でエキスパートを切り替える」のに対し、この構想は「ネットワーク上の独立した専門モデルを切り替える」アプローチです。 なぜ今この構想が現実味を帯びているのか 3 つの技術的な進歩が、この構想を「空想」から「検討に値する」レベルに引き上げています。 ...