Leon 2.0開発者プレビューを読む。ツールと記憶を軸に変わる個人アシスタント

旧来型から2.0コアへ移るLeon

Leonは、自分で確認できる環境に置き、個人作業を助けるオープンソースのAIアシスタントとして紹介されています。READMEが描く現在の中心は、単純な質問応答や意図分類だけではありません。目標を理解し、扱う方法を選び、道具を呼び出し、必要な情報を記憶し、問題が起きたときに回復するアシスタントへ移ろうとしています。2019年の最初のリリース時に近い古典的な意図分類型とは、設計の重点が異なります。

README冒頭の重要なお知らせは、2026年3月29日時点でLeonがdevelopブランチ上の2.0 Developer Previewに注力していると説明します。新しいドキュメントは未完成で、現在のドキュメントサイトと古いガイドの多くはレガシーアーキテクチャを反映しています。旧来の、より安定したエージェント以前の版を使いたい場合はmaster、新しいコアを探索したり貢献したりする場合はdevelopを選ぶよう案内されています。

この分岐は、導入判断の前提を変えます。masterとdevelopを同じ製品版として扱うと、手順、画面、実行結果、設定の説明が混ざります。現在の状態を読む一次参照としてcore/context/LEON.mdとcore/context/ARCHITECTURE.mdが指定されているため、対象ブランチを固定し、公開サイトの説明をそのまま2.0の仕様だと見なさないことが必要です。

smart、controlled、agentの役割分担

READMEでは、Leonの実行方式をsmart、controlled、agentの三つに分けています。smartモードは、与えられた作業に応じて処理方法をシステム側が選ぶ方式です。controlledモードは、決定論的なnative skillとactionに沿って実行します。agentモードは、手順を段階に分けて計画する経路です。三つは名称だけの設定違いではなく、実行の予測しやすさと柔軟性の配分が異なります。

制御を優先したい処理では、native skillとactionを明示するcontrolledモードが検討対象になります。複数段階の判断や道具の選択が必要な作業ではagentモードが候補になりますが、計画を作れることは、目的を正しく理解し、常に正しい結果を返すことを意味しません。最初の評価では、同じ入力を繰り返し、選ばれたモード、使われた道具、失敗時の処理を記録します。smartモードの自動選択を便利さだけで評価せず、誤った経路を選んだ場合の停止方法も確認します。

Leonは、単なる文章返答ではなく実際のtoolを使って作業する設計を掲げています。デスクトップやブラウザーを操作するcomputer use、画面上の結果を検証する仕組み、Satelliteを経由した実行にも言及があります。ただし、素材には各操作の許可範囲、認証方式、失敗時の復元手順までは示されていません。外部操作を試すときは、読み取り専用の作業から始め、対象画面と変更結果を人が確認できる環境を用意します。

SkillsからToolsまでの実行鎖

Leonのnative skillは、Skills、Actions、Tools、Functions、必要に応じてBinariesという鎖に沿うとREADMEで説明されています。上位のスキルが作業の入口になり、actionが具体的な操作を選び、toolとfunctionが処理を実行し、場合によっては外部バイナリへ到達する構造です。agent skillはSKILL.mdに基づくワークフローとして扱われ、制御された処理のnative skillとは役割が分かれています。

この構造は、機能を追加したり実行経路を追跡したりする際の手掛かりになります。失敗したときに、モデルの判断、skillの定義、actionの引数、toolの実装、外部プログラムの状態を区別できます。導入評価では、成功した最終回答だけでなく、どの層が呼ばれたかをログで確認し、書き込み操作やネットワーク操作がどこで発生したかを記録します。素材はこれらの層の詳細な権限表を示していないため、想定した境界を実行結果で検証します。

READMEには、検索、生産性、システムユーティリティ、メディア処理、コード支援、メモリ連携、音声やオーディオに関するスキルとtoolkitが含まれるとあります。機能名が列挙されていても、すべてのOSで同じように使えるとは限りません。機器、依存ソフト、必要な権限、データ保存場所を機能ごとに洗い出し、使わない機能を無効にできるかも確認します。

環境文脈と階層型メモリの扱い

Leonは、実際に動いているマシンや設定に関するcontextを利用し、回答を利用者の環境から離れすぎないようにする設計を示しています。また、永続的な好み、日々の状況、直近の会話という層を持つmemoryにも言及しています。長く使うほど同じ設定を説明する手間を減らせる可能性がある一方、記憶に何が残り、いつ参照され、どう削除できるかは導入時に確認すべき管理項目です。

自分の環境を根拠にするアシスタントでは、正しいcontextと古いcontextを区別しなければなりません。最初の検証では、意図的に変更した設定が回答へ反映されるか、削除した情報をLeonが再利用しないか、複数の利用者の情報が混ざらないかを確認します。READMEは階層の存在を説明していますが、素材だけでは保持期間、暗号化、権限分離、エクスポート形式まで判断できません。機密情報を投入する前に、保存先と削除手順を文書化します。

self-modelと、不要な文脈を増やさないためのbounded proactive pulse systemも説明されています。これは時間の経過に合わせた一貫性や能動的な処理を意識した仕組みと読めますが、実行頻度、起動条件、停止方法の詳細はこのREADMEにはありません。能動処理を試す場合は、外部通信や画面操作を許可しない状態で挙動を観察し、いつ何が実行されたかを人が追跡できるようにします。

serverとbridgeを分けて読む構成

READMEのArchitecture Snapshotでは、serverが主要な実行基盤です。routing、memory、context管理、HTTP API、agent実行、controlled実行を担当すると説明されています。appはWebアプリケーション、auroraはUI componentとpreview環境、skillsはnativeとagentに分かれた機能群です。core/contextには、Leonのidentityとarchitectureを説明する生成文書が置かれます。

bridgesにはNode.jsとPythonのbridge、toolkit定義、tool runtimeが含まれ、tcp_serverにはruntime stackの一部が使うPython serviceがあります。単一のサーバーだけを起動すれば全機能が揃うと決めつけず、利用するskillがどのbridgeやサービスを必要とするかを確認します。Node.js側の処理とPython側の処理で、環境変数、実行権限、依存ライブラリ、障害時のログが分かれる可能性があります。

この構成を調べるときは、server、app、skills、bridges、tcp_server、core/contextの順に役割を対応させ、必要な範囲だけを起動します。HTTP APIを外部へ公開する場合は、待受アドレス、認証、入力制限、ログの個人情報、bridgeから呼ばれる外部プログラムを点検します。READMEは構成の高水準な一覧を示す資料であり、各サービスの本番運用設定や可用性を保証する説明ではありません。

Node.js 24以上でのローカル導入

Getting Startedにある前提条件はNode.js 24.0.0以上で、対応OSはLinux、macOS、Windowsです。Node.jsの管理方法としてVoltaが推奨されています。導入手順は、GitHubリポジトリをcloneし、プロジェクトルートへ移動し、npm install --global pnpm@latestでpnpmを入れ、pnpm installで依存関係を取得する流れです。

起動コマンドはpnpm start、セットアップ確認はpnpm run checkです。READMEの説明では、既定の実行はローカルで行われ、アプリケーションはhttp://localhost:5366で利用できます。ここで明確なのは、必要なNode.jsの版、導入に使うpnpm、起動入口、確認入口、既定のローカルURLです。外部公開用の待受設定や認証の手順まで書かれているわけではありません。

再現性を保つため、Node.jsの実際の版、pnpmの版、選んだブランチ、取得したコミット、OS、環境変数を記録します。masterで旧来版を確認するのか、developで2.0 Developer Previewを試すのかを、導入前に決めます。checkが成功しても、利用したいskill、bridge、モデル、デスクトップ操作がすべて動くとは限りません。目的ごとに小さな確認項目を作り、ローカルURLを外部へ開く前にアクセス範囲を明示します。

開発者プレビューの貢献条件

Leonは2.0 Developer Previewへの貢献者を段階的に受け入れています。READMEにはcontributor form、Roadmap、Discord、GitHub issuesへの入口があります。新しいコアの設計が動いている時期なので、公開された機能名だけを見て拡張APIが安定していると判断しない方がよいでしょう。skillやtoolkitを追加する場合は、既存の命名、実行鎖、権限、文書化の慣例を先に確認します。

READMEが説明する貢献者の少なさには、二つの事情があります。一つは、ツール、memory、context、agent型実行を中心にコアを再構築する大きな移行期で、変更対象が多いことです。もう一つは、Leonが主に余暇時間に開発されており、進捗が均一でない可能性があることです。これはプロジェクトの自己説明であり、将来の速度や参加条件を保証する情報ではありません。

採用や貢献を考えるチームは、変更頻度と自分の保守能力を照合します。問題報告では、ブランチ、再現手順、実行環境、関連するskillやbridge、ログを添えます。外部の公開サイトが古い可能性を踏まえ、2.0の挙動はリポジトリ内のLEON.mdとARCHITECTURE.mdを読み、実際のコードと突き合わせます。

MITライセンスと文書の境界

素材のライセンス情報はMITで、著作権者はLouis Grenardです。ライセンス本文は、著作権表示などの条件を守ることを前提に、使用、複製、変更、結合、公開、配布、サブライセンス、販売を許可する内容として整理されています。ソフトウェアは現状のまま提供され、保証を行わず、請求や損害に対する責任を負わない旨も記載されています。

MITであることは、サポート契約、セキュリティ対応、稼働率、個人情報の扱いを約束するものではありません。社内利用や製品組込みでは、採用版のLICENSEを保管し、依存ライブラリ、bridge、モデル、外部サービスの条件を別々に点検します。利用者のcontextやmemoryを扱う構成なので、ソフトウェアの許諾とデータ管理の承認を同じ確認として済ませないことが大切です。

文書の境界も明確です。READMEはLeon 2.0の新しい文書がまだ準備されておらず、公開ドキュメントサイトが新コアに遅れている可能性を示します。したがって、紹介ページだけで設定や安全性を断定できません。対象ブランチを固定し、core/context/LEON.md、core/context/ARCHITECTURE.md、README、LICENSEを同じ版で保存してから、必要な機能をローカルで確認します。

編集部の結論

Leonは、手元の環境に合わせた文脈とツールを使い、個人向けの作業をローカル中心に組み立てたい開発者が検討できるオープンソースのアシスタントです。現在のREADMEが示す中心は完成済みの安定製品ではなく、developブランチで進む2.0 Developer Previewです。公開ドキュメントは新コアに追いついていないと明記されているため、導入前にブランチ、Node.jsの版、依存サービス、実行モード、保存されるメモリの範囲を固定し、リポジトリ内の参照文書と実機の動作を照合してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes