LangAlpha: 投資リサーチを持続するワークスペースとして扱うエージェントハーネス
Claude Code for Financial Market
ひと目でわかる
- これは何？
- 金融市場の解釈と投資判断を支援するPython製エージェント基盤。単発の質問応答ではなく、ワークスペースに研究を蓄積する設計を採る。採用判断の前に確認すべき境界を整理する。
- 誰に向いている？
- LangAlphaが向くのは、四半期リバランスやセクター・ローテーションのように数週間から数カ月かけて仮説を更新し続けるリサーチで、Python 3.13以降の実行環境とPostgreSQL、Redisを自分で用意できるチームだ。逆に、単発の株価照会や決算数値の抽出だけが目的なら、ワークスペースとサンドボックスの初期費用に見合わない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
単発プロンプトでは捉えられない投資リサーチを対象にする
READMEは既存のAI金融ツールを「investing as one-shot」と要約し、投資の実態はベイズ更新的だと対置している。仮説を立て、日々届くデータで確信度を更新し、数週間から数カ月かけてポジションを見直す。この反復構造を1つのプロンプトでは表現できない、というのが出発点である。解決策として提示されるのが、リサーチ目標ごとにワークスペースを作る運用だ。READMEの例では「Q2 rebalance」「data center demand deep dive」「energy sector rotation」といった単位でワークスペースを切り、エージェントが目標とスタイルを聞き取り、最初の成果物を生成し、ファイルシステムへ保存する。翌日戻ればファイル、スレッド、蓄積されたリサーチが残っている。対象読者は、銘柄スクリーニングの結果を一度受け取って終わりにするのではなく、その結果を起点に調査を積み上げる個人投資家やリサーチ担当者である。
ワークスペース、サンドボックス、agent.md という3層の記憶
永続化は単一の仕組みではなく層になっている。まず各ワークスペースが専用サンドボックスに対応し、構造化ディレクトリとワークスペースノート（agent.md）を持つ。READMEはこれを、セッションとスレッドをまたいでリサーチが複利で積み上がる場所と説明する。次に長期メモリストアが `.agents/user/memory/` と `.agents/workspace/memory/` の2箇所に分かれ、ユーザー設定とサンドボックス横断の知識を保持する。3層目が `.agents/user/memo/` で、これはユーザーが管理する置き場であり、PDFやmarkdownのリサーチノートをアップロードするとエージェントが必要時に読む。設計上の判断として、メモリを自動抽出に任せず、ユーザーが明示的に投入する経路を残している点は評価できる。反面、`.agents/` 配下のディレクトリ構造そのものが運用契約になるため、ワークスペースを大量に作るほど何をどこに置いたかの管理コストは利用者側に戻ってくる。
Programmatic Tool Callingがコンテキスト消費を抑える仕組み
LangAlphaの技術的な中心はProgrammatic Tool Calling（PTC）である。READMEの説明では、MCPサーバーから取得した金融データをそのままLLMのコンテキストウィンドウに流し込むのではなく、エージェントがPythonを書いて実行し、その中でデータを処理する。多段の分析をサンドボックス内で完結させ、トークン消費を抑える狙いだ。これと対になるのがProgressive Tool Discoveryで、読み込んだMCPツールはコンテキストには要約として置き、完全なドキュメントはワークスペースへ書き出す。エージェントは必要になった時点でツールを発見して使う。スキルにJSONツールを紐付け、スキルが有効化されたときだけエージェントへ公開する方式も同じ思想の延長にある。データ取得の階層も二段構えで、素早い照会はネイティブツール、大量データの処理やチャート生成、複数年にわたる分析はMCPサーバーとサンドボックス側に寄せる。この分担は、データ量の多い処理をLLMの外へ出すという一貫した判断として読める。
起動までの経路: セルフホスト版、Python 3.13、必要なミドルウェア
配布形態は複数ある。リリースには v2026.09.07、desktop-v0.2.3、desktop-oss-v0.2.3 の3つが並び、desktop-oss-v0.2.3 は「Desktop v0.2.3 (self-hosted)」と注記されている。自分でホストする場合はこの系列を選ぶことになる。READMEのバッジが示す実行要件はPython 3.13以降で、主要言語はPython。構成図から読み取れる依存は、FastAPIバックエンド、PostgreSQL（アプリデータ用とLangGraphチェックポインタ用のデュアルプール）、Redis（SSEイベントバッファ、市場データのAPIキャッシュ、ステアリング用）である。フロントエンドはReact 19、Vite、Tailwindで、CLI/TUIは `libs/ptc-cli/`、エージェントコアは `src/ptc_agent/`、バックエンドは `src/server/`、Webは `web/`、プラグインは `plugins/` に置かれている。リポジトリには `docs/api/README.md` と `docs/README.zh-CN.md`、`docs/README.ja-JP.md` が含まれるため、API仕様と日本語ドキュメントはここを起点にするとよい。具体的なインストール手順や環境変数の一覧は与えられた資料からは確認できない。READMEのGetting Startedアンカーが存在すること以上のことは述べられない。
エージェントの並列実行と、途中で方向を変える操作
長時間動くリサーチを支える仕組みとして、エージェントスワームがある。分離されたコンテキストウィンドウを持つ非同期サブエージェントを並列に走らせ、ツールセットとスキルを事前に読み込み、実行中のステアリングとチェックポイントからの再開、UI上での進捗監視を行う。Live steeringは、エージェントやサブエージェントが作業中でもフォローアップメッセージを送り、終了を待たずに軌道修正や意図の明確化を行う機能である。Secretaryはフラッシュエージェントを秘書として使い、ワークスペースの作成と管理、深いPTC分析のバックグラウンド投入、実行中タスクの監視、結果取得を会話コマンドで行う。ここにはhuman-in-the-loopの承認が挟まる。自動化は定期実行、単発実行に加え、株価や指数がリアルタイムの価格条件に達したときに発火する価格トリガー型がある。ただしこれらはすべて実行中の状態管理を伴うため、PostgreSQLのチェックポインタとRedisのイベントバッファが落ちたときに何が再開でき、何が失われるかは運用前に把握しておく必要がある。READMEはRedisのイベントバッファを150Kイベント、再接続リプレイ対応と記述しているが、それを超えた場合の挙動には触れていない。
スキルと出力形式がリサーチの型を決めてしまう点
財務リサーチ向けのスキルとして、DCFモデル、カバレッジ開始レポート、決算分析、モーニングノート、ドキュメント生成などがプリビルドで用意され、スラッシュコマンドか自動検出で有効化される。Web UI側は、インラインの財務チャート、複数形式のファイルビューア、TradingViewチャート、WebSocket経由のリアルタイム市場データ、エージェントが描くチャート注釈、ターンごとの出典パネル、会話の共有、サブエージェント監視を備える。ここで注意したいのは、スキルがリサーチの型を固定するという副作用である。DCFのスキルを有効化すれば、エージェントはその型に沿って入力を埋めようとする。独自の評価軸で企業を見たい場合、既存スキルの枠組みが思考の足場になるか制約になるかは用途次第だ。出典パネルがターン単位で付く設計は、生成物をそのまま意思決定に使わず検証する前提を UI に埋め込んでいる点で筋が通っている。
向かない場面と、代替となるアプローチ
LangAlphaは投資判断を支援するが、判断そのものを保証しない。ワークスペースとサンドボックス、PostgreSQL、Redisを常時動かす構成は、単発の株価確認や決算数値の抽出には過剰である。その用途なら、LangChainのツール呼び出しでデータAPIを1回叩き、結果をそのまま返す短いスクリプトのほうが速く、障害点も少ない。LangAlphaとの違いは状態の持ち方にある。単発スクリプトは毎回ゼロから始まり、前回の仮説を引き継がない。LangAlphaはワークスペースとagent.mdに前回の文脈を残し、PTCでデータ処理をLLMの外に出し、サブエージェントで調査を並列化する。逆に言えば、文脈を引き継ぐ必要がない問い合わせにこの構造を持ち込むと、サンドボックスの起動とチェックポイントの書き込みが純粋なオーバーヘッドになる。もう一つの境界はデータ源で、READMEが挙げるのはMCPサーバー経由のマルチティアなプロバイダ階層であり、どのプロバイダが実際に使えるかは資料からは特定できない。接続先が自分の対象市場をカバーしていなければ、エージェントの能力以前に分析が成立しない。
Apache-2.0 と、運用側に残るコスト
ライセンスはApache-2.0で、リポジトリのバッジにも明記されている。商用利用や改変、再配布の条件は同ライセンスの条文に従うため、ここで法的な解釈は示さない。運用コストとして資料から読み取れるのは、PostgreSQLのデュアルプール（アプリデータとLangGraphチェックポインタ）、Redis、サンドボックス実行環境、そしてLLMプロバイダの従量課金である。マルチプロバイダのモデル層はエラー時の自動フェイルオーバーを行うとREADMEは説明しており、特定プロバイダの障害でリサーチが止まりにくい設計になっている。一方で、モデルを切り替えれば同じスキルでも出力の質は変わる。アップグレード面では、デスクトップ版とサーバー版が別系列のバージョン番号で進んでいるため、自己ホスト環境ではどのリリース系列を追うかを最初に決めておかないと、後から移行コストが発生する。暗号化はpgcryptoによる保存時暗号化、認証情報の漏洩検出とマスキング、ワークスペース単位のシークレット保管が挙げられている。シークレットの投入経路とローテーション手順は資料に記載がないため、導入時に自分で設計する必要がある。
編集部の結論
LangAlphaが向くのは、四半期リバランスやセクター・ローテーションのように数週間から数カ月かけて仮説を更新し続けるリサーチで、Python 3.13以降の実行環境とPostgreSQL、Redisを自分で用意できるチームだ。逆に、単発の株価照会や決算数値の抽出だけが目的なら、ワークスペースとサンドボックスの初期費用に見合わない。導入前に確認すべきは、READMEが挙げるMCPサーバー群のうち実際にどのプロバイダのデータへ接続できるか、pgcryptoによる保存時暗号化が自分のPostgreSQL構成で有効になるか、そしてdesktop-oss-v0.2.3の自己ホスト版とホスト版で機能差がどこにあるかの3点である。
コミュニティノート