Skales 12.9.26 を採用前に読む: リポジトリは配布物であり、ソースは v7 で凍結されている
Personal AI desktop agent for Windows, macOS, Linux, Android & iOS. Set a goal, it works on its own. Teams (pair two desktops, agents + humans), Agent2Agent, Workflows, Codework, multi-agent orgs, desktop + browser automation. 15+ AI providers, BYOK. No Docker, no terminal. Agent Skills (SKILL.md). Migration importer. Recurring autonomous tasks.
ひと目でわかる
- これは何？
- Skales は Windows、macOS、Linux、Android、iOS で動く個人向け AI デスクトップエージェントで、BSL 1.1 の下で配布されている。ただしこの GitHub リポジトリにチェックインされている TypeScript のソースはメンテナンスされていない v7 のスナップショットであり、実際に動作するコードではない。何を評価し、何を評価できないのかを整理する。
- 誰に向いている？
- 導入を検討すべきなのは、Docker やターミナルを避けたい個人ユーザー、Ollama による完全オフライン運用を重視する人、SKILL.md で自分の作業手順をエージェントに覚えさせたい人だ。逆に、ソースを読んで挙動を検証したいチーム、BSL 1.1 の商用条件を確認せずに業務利用したい組織、リポジトリのコードを fork して自前ビルドしたい開発者には向かない。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 5 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
このリポジトリは何を配布していて、何を配布していないか
最初に押さえるべき事実は、skalesapp/skales が製品のソースコード置き場ではないという点だ。README には「this repository carries the releases, the changelog and the issues; the checked-in source is a frozen v7 snapshot, not the code that ships」と明記されている。つまりここにあるのはリリース、CHANGELOG、Issue トラッカー、インストールガイドであり、チェックインされた TypeScript のツリーは歴史的な v7 のスナップショットで、メンテナンスもビルドもされていない。
この構成は、GitHub のリポジトリを見て採用判断をする習慣のあるエンジニアにとって罠になる。コードを読めば内部設計が分かるという前提が成立しないからだ。読めるのは数世代前の設計であり、現在の 12.9.26 がどう動くかは分からない。製品そのものは skales.app からダウンロードする署名済みアプリケーションで、ライセンスは BSL 1.1、個人利用は無料と README は説明している。
したがって評価の出発点は「ソースを読む」ではなく「配布物を動かす」になる。ソース監査を前提にした導入フローを組んでいる組織は、この時点で方針を変える必要がある。
Docker もターミナルも使わせないという設計判断
README の比較表は、典型的な AI エージェントとの差としてセットアップ手順を挙げている。向こうは Docker、ターミナル、Python CLI で、RAM 使用量は 1.5GB から 3GB 以上、対応 OS は Linux か Docker 必須とされる。Skales 側は EXE、DMG、AppImage をダウンロードしてダブルクリック、RAM は約 300MB、Windows、macOS、Linux のネイティブ対応、最初のタスクまでの時間は 30 秒と書かれている。
この表の数値は README の主張であり、本記事で追試したものではない。だが設計の方向性は読み取れる。インストール体験をアプリ配布の形に閉じ込め、ランタイム環境の構築を利用者から隠すという判断だ。これは開発者以外を対象読者に含める場合には合理的で、README も「made for everyone from 6 to 60+」と書いている。
代償もある。コンテナで動かすエージェントは、権限やネットワークを Docker のレイヤーで統制できる。ネイティブアプリとして動くエージェントは、その統制点が OS 側の権限設定に移る。組織で配る場合は、Docker のポリシーではなくエンドポイント管理側で何を許可するかを決めることになる。
goal、code、モバイルペアリング: 操作の入り口
日常的な操作はスラッシュコマンドとして README に例が示されている。`/goal build me a trading bot` はバックグラウンドで多数のステップにまたがって実行され、中断した場所から再開すると説明されている。`/code` は任意のチャットにフォルダを紐づけ、インラインの差分表示とワンクリックの undo を提供する。
モバイル側は QR でペアリングし、スマートフォンからこのデスクトップのツール一式を操作するか、スマートフォン単体で動かすかを選べる。Android は Google Play の `app.skales.mobile`、iOS は App Store の id6763328966 として配布されている。
機能一覧には Chat、Code、Studio、Cockpit、Planner、Iris Orbit、Memory、Mobile、Skales Pocket、Plugins、Discover and Wrapped という複数の画面が並ぶ。数が多いこと自体は採用理由にならない。評価するなら、自分の作業がどの画面に収まるかを先に決め、そこだけを触るほうが判断が早い。
SKILL.md と MCP、Ollama: 拡張の接続点
拡張の接続点として README が名前を挙げているのは Agent Skills、つまり SKILL.md と、トピックにも入っている MCP だ。SKILL.md はエージェントに作業手順を教えるためのファイル形式で、リポジトリのコードを書き換えずに振る舞いを足せる。プロバイダ側は 15 以上に対応し、BYOK で自分のキーを持ち込み、Ollama を使えば完全オフラインで動かせると説明されている。API キー不要の無料トライアルとして Skales IQ が組み込まれている。
ここで注意したいのは、SKILL.md の仕様そのものがこのリポジトリには見当たらないことだ。README は形式の名前と役割に触れるだけで、スキーマや探索パスは書いていない。実際にスキルを書くなら docs.skales.app 側の記述を確認する必要がある。MCP についても対応の記載はあるが、どのトランスポートを実装しているかは README からは分からない。
オフライン運用を売りにしている点は、クラウド経由のエージェントを避けたい層には明確な差になる。ただし Ollama 側のモデル性能とツール呼び出しの相性はモデル次第で、Skales が保証する範囲ではない。
Team と Agent2Agent は README の記述が薄い
リポジトリの説明文には Teams、Agent2Agent、Workflows、Codework、multi-agent orgs といった語が並ぶ。デスクトップ 2 台をペアにしてエージェントと人間を混ぜる、という構想が読み取れる。
だが README 本文には、これらの仕組みを説明する記述が見当たらない。ペアリングの手順、メッセージの受け渡し方、権限がどう委譲されるか、失敗したときにどの単位でロールバックするか。いずれも確認できない。複数エージェントを協調させる機能は、権限境界と失敗時の扱いが最も難しい部分であり、そこが説明されていない状態で業務フローに組み込むのは早い。
判断材料としては、単一マシン上の `/goal` と `/code` が自分の用途を満たすかどうかを先に確かめ、複数台連携は別の検証項目として切り分けるのが現実的だ。README の記述だけでは、Team 機能がどの程度完成しているかを評価できない。
BSL 1.1 と、凍結されたソースという制約
ライセンスは BSL 1.1 で、個人利用は無料と README は説明する。BSL は一定期間後にオープンソースライセンスへ移行する前提の source-available ライセンスで、何が許され何が許されないかは付随する追加条件に依存する。本記事は法的助言ではないので、商用利用や再配布を検討する場合は自組織の法務判断が必要になる。GitHub のライセンス識別子が NOASSERTION になっている点も、自動判定に頼らず原文を確認すべき理由になる。
もう一つの制約は、先に触れた v7 スナップショットだ。ソースが公開されているように見えて、それは現行版ではない。脆弱性を自分で確認したい、パッチを当てたい、fork して自前ビルドしたい、という動機はこのリポジトリでは満たせない。SECURITY.md を先に読むよう README が求めているのも、対象範囲が限定されているためだ。
結果として、Skales は「ソースを読んでから決める」タイプの採用には向かない。動かして確かめるか、あるいは導入しないかの二択に近い。
OpenClaw や Hermes Agent からの移行と、他の選択肢との違い
README は OpenClaw、Hermes Agent、ChatGPT からの乗り換えを想定し、Settings > Import from Another Tool という移行インポータを用意していると説明する。既存ツールの設定を持ち込める点は、乗り換えの摩擦を下げる。ただしインポータが何を取り込み、何を取り込まないかは README には書かれていない。移行前に、自分の設定がどの項目に相当するかを確認しておく必要がある。
代替として名前が挙がっている OpenClaw や Hermes Agent との違いは、配布形態にある。Skales は署名済みのネイティブアプリとして配られ、Docker もターミナルも要求しない。逆に、コンテナで動かすエージェントは環境をファイルで記述でき、CI やサーバ上で再現しやすい。Skales はその再現性を、インストールのしやすさと引き換えにしている。
どちらが優れているかではなく、統制をファイルで持ちたいのか、利用者の手元で完結させたいのかで分かれる。サーバ上で無人実行したい用途は、この配布形態の想定外だと考えたほうがよい。
リリースの刻み方から見るメンテナンス費用
リリース履歴を見ると、v12.9.21 Cockpit 2.0 が 2026-09-02、v12.9.25 Backbone が 09-03、v12.9.26 Grip が 09-06 と、数日の間隔で版が上がっている。パッチ番号が細かく進む更新が継続していることは、配布物としては活発だと読める。
一方で、この速度は利用者側の追従コストでもある。デスクトップアプリは自動更新の仕組みを持つことが多く、検証した版と手元の版がずれやすい。業務で使うなら、どの版を基準にするかを決め、CHANGELOG.md で変更点を追う運用が要る。リポジトリ側のソースが v7 で止まっている以上、差分をコードから読むことはできない。
費用の見積もりで唯一はっきりしているのは、ライセンス確認のコストと、バージョン追従のコストだ。どちらもこのリポジトリだけでは完結せず、skales.app と docs.skales.app を併せて見る必要がある。
編集部の結論
導入を検討すべきなのは、Docker やターミナルを避けたい個人ユーザー、Ollama による完全オフライン運用を重視する人、SKILL.md で自分の作業手順をエージェントに覚えさせたい人だ。逆に、ソースを読んで挙動を検証したいチーム、BSL 1.1 の商用条件を確認せずに業務利用したい組織、リポジトリのコードを fork して自前ビルドしたい開発者には向かない。最初に確認すべきは、skales.app から入手する署名済みアプリのバージョンが 12.9.26 と一致しているか、docs.skales.app のドキュメントがこのリポジトリの README と同じ機能範囲を説明しているか、そして BSL 1.1 の下で自分の用途が許される範囲に入るかを自組織の法務判断で確かめることだ。
コミュニティノート