Arslan を解き明かす。最初のプロトタイプから v0.1.63 までの設計・実装・進化

01 / プロジェクト概要自然言語を、実際の仕事につなげる

Arslan は、Mac を主な対象とする、ローカルファーストのオープンソース個人用 AI アシスタントです。ユーザーが取り組みたい仕事を伝えると、Arslan がコンテキストを整理し、モデルを呼び出し、ツールを使い、実行過程を記録して、確認できる回答やファイルを届けます。チャット、記憶、ファイル処理、ターミナル、Web、一部のネイティブアプリ操作、バックグラウンドタスクを、一つの作業窓口にまとめています。

作者が AI の支援を受け、いわゆる vibe coding によって、単独で開発と改良を続けているプロジェクトです。本書では、製品の目標から実際のコードの適用範囲までをたどり、設計の理由、動作の仕組み、初期のプロトタイプから v0.1.63 までの変化を紹介します。

一つの窓口で、さまざまな仕事を

「ローカルファースト」が意味すること

ローカルファーストとは、データの主な保存先と処理の実行場所を指します。デスクトップ UI、ローカルサービス、データベース、ワークスペース、Mac 向けツールは、主にユーザーのマシンで動作します。モデルはユーザーが設定します。クラウドモデルを使う場合、リクエストに含まれる会話、資料の抜粋、使用を許可された記憶は、該当するモデル提供者に送信されます。互換性のあるローカルモデルのエンドポイントにも接続できますが、ツール呼び出しや画像認識の能力は、モデルとサービスの実装に依存します。

そのため、Arslan のアーキテクチャでは、どのマシンで作業が行われ、どの内容がどのモデルのエンドポイントに送られるかという二つの問いに答える必要があります。ローカルデータの永続化、クラウドへの記憶の送信許可、ツールの権限はそれぞれ別の役割を担っており、一つの「ローカル」設定では表せません。

本書が対象とするバージョン

本文は、正式リリースされた v0.1.63 を基準にしています。公開日時は北京時間（UTC+8）の 2026 年 10 月 27 日 22:26:31、照合の基準日は 2026 年 10 月 27 日です。コードへのリンクは、リリースコミット 9bbb6ad653b4 に固定しています。リリース後の開発、過去の機能、今後の技術的な方向性は、それぞれ区別して記載します。

実装の入口：Arslan の統合エントリーポイント；タスクと記憶の利用コンテキスト；モデル接続；v0.1.63 リリース記録。

02 / 個人開発とオープンソースAI とともに、一人でアプリをシステムへ育てる

Arslan は、私が AI の支援を受けて単独で開発したプロジェクトです。いわゆる vibe coding にあたります。最初のプロトタイプからその後の各バージョンまで、一貫して私一人で開発を進めてきました。

ここでいう「個人開発」とは、プロジェクト全体を作者が単独で進めており、AI が実装過程の協働ツールであるという意味です。同時に Arslan は、オープンソースのフレームワーク、システム API、外部モデル、サードパーティのコンポーネントを基盤としています。開発方法、プロジェクトの責任、コンポーネントの出所は、それぞれ別の意味を持ちます。以下では、最終的に製品に組み込まれた設計と実装について説明します。

コードの生成から、使える製品の保守へ

コードが動くことは、製品に必要なことのごく一部です。デスクトップアプリでは、サービスの起動方法、ウィンドウの接続方法、古いデータベースの移行方法、プロセス終了後の後処理、システム権限を持つ主体、開発環境のないマシンで配布パッケージが動くかどうかも解決しなければなりません。Agent にはさらに不確実性があります。モデルのタイムアウト、ツール引数の欠落、Web ページの読み取り不足が起こり得ますし、実行の途中でユーザーの承認が必要になることもあります。

こうした課題を受け、Arslan の改良は次第に四つの方向へ進みました。明示的な契約で入力と状態を制約すること、観察可能なツール結果で完了状況を照合すること、権限の境界で実際の副作用を制御すること、そしてテストとリリース時の受け入れ確認で変更の妥当性を確かめることです。AI の支援は実装や原因調査を速められますが、最終的な製品の提供には、これらの制約がそろっている必要があります。

Arslan 自体の役割と、依存コンポーネントの役割

プロジェクトは Apache-2.0 で公開されています。サードパーティのコンポーネントのライセンスと帰属は、THIRD_PARTY_NOTICES.md を参照してください。このファイルはアプリにも同梱されています。Arslan がシェルコマンドを読み取るコードは Hermes Agent（MIT）を元にしており、その出典もここに記載しています。オープンソース化によって、実装、制約、変遷を確認でき、「なぜこの設計にしたのか」も文書の一部となっています。

作者の開発方法は、作者自身の説明に基づきます。実装と帰属：プロジェクトのライセンス；サードパーティの帰属；実行コアのアーキテクチャ選択；統一ループへのリファクタリング。

03 / 技術スタックUI、ホスト、実行、データの役割分担

Arslan の技術スタックは、デスクトップ製品としての配布と個人用 Agent の役割に沿って構成されています。以下の正確なバージョンは、v0.1.63 のロックファイルに記載された、そのソースコードの依存関係の解決結果です。ユーザーのマシンにインストールすべきツールのバージョンでも、プロジェクト自体のリリース番号でもありません。

Python の実行コアを維持する理由

Python はモデル適応、文書処理、Agent ループ、タスクサービスを担当し、既存のエコシステムと実装をそのまま活かせます。Tauri と Rust は、ウィンドウ、プロセスのライフサイクル、ネイティブ連携を担当します。この実行コアを維持する判断は、公開されているアーキテクチャ決定記録に残っています。コアを別の言語へ移行すると、ツール、データ移行、パッケージング、テストの境界が同時に変わるため、「よりネイティブになる」という理由だけでは利点を判断できません。

論理的には層を分けていますが、配備形態は引き続きローカルサービスが中心です。内部の Python モジュールをそれぞれリモートのマイクロサービスにしているわけではなく、動作に Redis、Celery、Docker、Kubernetes も必要ありません。Hands、Bridge、MCP サービス、ターミナルの子プロセスは、独立した権限や実行環境が必要な箇所でプロセスの境界を設けています。

固定された依存関係：フロントエンドのロックファイル；デスクトップのロックファイル；Python のロックファイル。設計と帰属：実行コアに関する決定；サードパーティの帰属。

04 / これまでの歩み専門家を生成する仕組みから、仕事を続けられる一つの Arslan へ

Arslan は、作者が AI を活用した vibe coding により、単独で開発を続けているプロジェクトです。その歩みには新機能の追加だけでなく、設計の撤回もあります。実行条件を整える必要がある機能もあれば、複雑さを取り除くべき部分もありました。過去の機能をすべて並べるより、こうした変化を理解するほうが、現在のアーキテクチャをよく説明できます。

6 月：まず「会話を通じて Agent を生成する」一連の流れを作る

現存する最初のコミットは 2026 年 6 月 7 日のデータモデルです。当時の方向性は Meta-Agent でした。技術に詳しくないユーザーが会話を通じて分野ごとの専門家を作り、その専門家がタスクを遂行するという構想です。その後、モデルアダプター、ツールレジストリ、要件を聞き取る会話の状態機械、テンプレート、Spawn Manager、CLI が加わりました。6 月 8 日には、FastAPI、非同期データベース、認証、WebSocket、React UI が接続され、操作、保存、再接続ができるプロトタイプになりました。

ツールが実際に動き始めると、システムは「何を実行したか」を把握し、回答に使う資料も供給する必要が生じました。6 月 23 日には Runs、Steps、Evaluations、文書の分割、SQLite FTS5 が追加され、6 月 27 日には MCP の stdio と HTTP トランスポートが導入されました。これにより、専門家向けのプロンプトを生成するだけの段階から、モデルの呼び出し、ツールの実行、過程の保存、資料の検索、ユーザーへの結果の返却まで、一回の実行全体を管理する段階へ進みました。

最初のデータモデル；Runs データモデル；FTS5 の知識インデックス；MCP HTTP トランスポート。

7 月：記憶と製品の提供を、技術的な課題として捉える

7 月 5 日、Second Brain に embedding とスコープで絞り込むハイブリッド検索が追加されました。全文検索、ベクトル類似度、RRF による順位融合を組み合わせたものです。その後、事実の出所、有効性、置き換えと取り消し、整理提案、利用記録が加わりました。記憶は単なるチャットの要約ではなくなり、資料の関連性、現在も有効かどうか、どの範囲に属するかが、モデルのコンテキストに入れられるかどうかを左右するようになりました。

多くの履歴をコンテキストに取り込むと、新たなトレードオフが生まれます。検索範囲が広すぎると無関係な資料が混ざり、古い事実が新しい事実を上書きし、外部の文章が長期的な動作に影響する可能性があります。そのため、7 月の実装では事実に出所と時系列を付け、自動追加、レビューが必要な変更、機微な内容を区別し、整理結果を提案の受信箱へ送るようにしました。その後の記憶機能もこうした制約に沿って発展しています。「より多くを覚える」ことよりも、ユーザーが確認し、訂正し、取り消せることが、明確な技術目標になりました。

この時期には長期保守への対応も始まりました。7 月 14 日、データベース移行を独自のバージョン管理 runner に切り替え、Alembic への依存を削除しました。7 月 10 日にはライセンスを Apache-2.0 に変更し、NOTICE と SECURITY.md を追加しました。7 月 25 日には明示的なオープンソース化準備のコミットが記録されています。7 月 27 日には、初のデスクトップインストール版として v0.1.0 を公開しました。Tauri のシェルと実行ファイル化した Python バックエンドを一緒に配布し、署名、公証、更新、初回インストールの検査がリリース工程に入りました。

実際のインストール環境では、すぐに開発時のテストでは見えなかった欠落が明らかになりました。v0.1.0–0.1.6 のパッケージには WebSocket の実行時依存関係が不足しており、health API は正常でもチャットには接続できませんでした。0.1.7 で依存関係と PyInstaller の hidden import を修正し、実際のハンドシェイクをインストール時の受け入れ確認に追加しました。この不具合は、「バックエンドが起動した」だけでなく、「ユーザーの操作経路全体が使える」ことまで検証すべき理由を示しています。

ハイブリッド検索；バージョン管理された移行；オープンソース化の準備；配布パッケージの WebSocket 障害の振り返り。

8 月：接続できる機能を、ユーザーにも分かるものにする

0.1.20 では、認証情報の状態を「未設定」「復号可能」「復号不可能」に分け、salt と鍵の移行を安定させました。検索には出典とエラーの説明が加わり、モデルはタスクごとに役割を分担するようになりました。その後、MCP OAuth、OpenRouter ログイン、初回案内、拡張機能一覧、ローカルワークスペースの読み書き、定期タスク、SSH が順次追加されました。拡張機能が増えるにつれ、現在の接続でツールを呼び出せるのか、設定したツール類が有効なのか、どの操作に許可が必要なのかを、システムが正確に伝える必要も生じました。

ローカルでの実行機能も分離が進みました。ワークスペースの読み取りと書き込みを分け、書き込みには対応する許可を必要としました。定期タスクには専用の実行スケジュールの許可を設けました。SSH では接続先を記憶できますが、リモートでの実行には毎回確認を求めます。こうしてツールの一覧は、能力と利用条件の両方を示すものになりました。ユーザーにとって「接続済み」と「今回は実行できる」は異なる状態であり、UI とモデルのコンテキストの両方で、その違いを表す必要があります。

0.1.23 の turn journal により、会話を切り替えても生成中の回答を再び受け取れるようになりました。一方、インストール版が npx を見つけられない問題の修正は、デスクトップアプリが受け取る環境とターミナルの環境が異なることを、改めて示しました。8 月の主題は接続先の追加だけでなく、接続、状態、許可を、ユーザーが理解できる操作へ変えることでした。

9 月：一回の回答から、追跡できる仕事へ

0.1.38 では信頼性を集中的に強化しました。既定で実行を拒否する Python サンドボックス、独立した計算ランタイム、永続化された Runs、成果物、チェックポイント、共有の実行予算が加わりました。0.1.40 のプレビューと安定化では、プロジェクト記憶、文書の出典、タスクの継続、移行前のバックアップが進む一方、言語をまたぐ複数文書の比較に関する既知の失敗も記録に残しました。出典をクリックできることは資料を見つけられることを示すだけで、モデルの結論の正しさを証明するものではありません。

それより少し前の 8 月 31 日から 9 月 3 日にかけて、音声機能は読み上げ（0.1.32）、押している間だけの音声入力（0.1.36）から、半二重の音声会話（0.1.37）へ進み、マイク権限と使用言語の選択も修正されました。その一方で、0.1.40 の調査機能の受け入れ確認では、異なる言語間の比較の失敗を成功扱いに変更していません。0.1.41 の出典レビューも、判定の調整が十分でなかったため、既定では無効のままにしました（この調査レビューは、0.1.63 で後に削除されました）。こうした記録は「システムが検査した」ことの意味を限定し、実際の失敗に沿って次の改善を進める基盤となっています。

0.1.41 では、ウィンドウを閉じてもメニューバーに残って作業を続けるようになりました。0.1.42 では長いタスクをバックグラウンドへ移し、ユーザーがチャットを続けられるようにしました。0.1.43 ではさらに、予算のソフト上限と強制停止を区別しました。ソフト上限に達したら、手元の資料を使ってまず成果をまとめ、調査が途中で止まって何も届けられない事態を避けます。タスクは次第に UI から独立したライフサイクルを持つようになりましたが、任意の外部操作をクラッシュ後に安全に自動再実行できるという意味ではありません。

9 月末から 10 月：一つの実行ループへ集約する

初期設計では専門家を長期的に存在する役割として扱い、ユーザーとシステムの双方が、選択、招待、振り分けを扱う必要がありました。0.1.44 では専門家の作成とディスパッチを停止し、既存の専門家の手順を Skill に変換できるようにしました。0.1.46 では、利用経路がなくなった専門家のバックグラウンド進化を停止しました。0.1.48 では前段の router を取り除き、すべてのメッセージが直接 Agent ループに入るようにしました。リリースノートによれば、「できません」という一部の定型回答は、実際の能力ではなくルーティングの判定に由来していました。この集約により、ツールの選択を、実際のツールと状態を持つ実行過程に戻しました。

集約後の改善は、共通の実行層に集中しています。0.1.49 はネイティブなツールプロトコル、応答の途切れ、失敗からの復旧を改善しました。0.1.50 では現在の作業状態、計画、代替経路が加わり、0.1.51 ではコマンドサンドボックスと Island、0.1.52 ではユーザーの記憶と learned practices が後続の作業で使われるようになりました。ここでの「学習」は、管理可能な経験を保存して利用することであり、基盤モデルの重みを更新することではありません。

0.1.53 では、独立した Hands helper によってアクセシビリティツリーを読み取り、Mac アプリを操作できるようになり、Mac 側の iPhone Bridge も含まれました。0.1.54 では、この Mac 側を iPhone アプリに対応できる状態に整え（Touch ID による承認、スマートフォン 1 台につき 1 項目、スマートフォンを削除したときの後片付け）、ターミナルゲートの 4 つの抜け穴を塞ぎました。いずれも確認を増やす方向の変更で、減らすものではありません。0.1.55 では、確認を求めるものすべてを一つの見た目と一つのキューにまとめました。カードには Inbox から回答でき、危険な手順でなければ Island からも回答できます。0.1.56 では、プロジェクトを二層で扱うようになりました。すべてのプロジェクトを並べるボードと、プロジェクトごとのレベルです。各レベルのチェックポイントには、Arslan が示せる証拠があるときにだけチェックが付きます。0.1.57 では、能力が育つようになりました。ある手順に Arslan のできないことが必要になると、サーバーやスキルを探し、確認を求め、バージョンを固定してサンドボックス内にインストールし、テストしてから手順をやり直します。0.1.58 では、返信とファイルが読みやすくなりました。実行した内容を控えめな一行で示し、ファイルはカードとして返り、リーダーで読めるようになり、会話ごとに任意のモデルを選べます。0.1.59 では、長い回答の間もチャットが途切れなくなり、ユーザーの言語で回答し、終わったバックグラウンドの作業を完了として数えるようになりました。0.1.60 では Hands v2 が加わりました。作業対象の一つのウィンドウを見ること、一瞬だけ前面を借りること、そしてユーザーが了承した場合に限り画面を引き継ぐことができます。0.1.61 では、チャットウィンドウ、Inbox、Island、iPhone に共通の承認カードが一つ入り、MCP サーバーは自分で起動するようになり、temperature 設定を拒否する Claude モデルの問題も修正されました。0.1.62 では、長いターミナルコマンドをそれぞれの上限まで実行でき、「ユーザーの確認が必要」は実際に痕跡を残した可能性のある操作だけに絞られ、MCP ツールの説明は、あるプロバイダーの拒否がすべてのチャットを壊さないように整え直され、ファイルの書き込みはリンクをたどって作業フォルダーの外へ出ないようになりました。0.1.63 では、返信の実行中にメッセージを追加でき、回答は書かれるそばからストリーミングされ、読み取りは最大 4 件を同時に実行し、1 ターンを取り消せるようにチェックポイントを保存し、あまり使わないツールは必要なときにだけ送られ、タスクごとのドル上限（既定でオン）が加わり、無害なコマンドの判定が後で完成するまでは新しいコマンドのたびに確認します。コードの削除もありました。どの返信からも到達できなかった専門家時代のコード、進化とキュレーションの仕組み、調査レビュー、「Distill」、Docker による配備経路、取り込んだ Hermes のコピーです。以前の専門家オーケストレーションは、すでに過去の仕組みです。また、アクセシビリティ経由の操作ができるからといって、すべてのアプリを確実に制御できるとは限りません。現在も、目に見える状態、明確な権限、確認できる結果によって、モデルが実際に行える仕事を制約しています。

信頼性の基盤；安定版の調査アシスタントの範囲；バックグラウンド作業；統一 Agent ループ；Hands と Bridge。

05 / システムアーキテクチャUI、実行、権限は、それぞれ何を担うのか

分かりやすく説明すると、React はユーザーの作業画面、Tauri は macOS とつなぐシェル、Python は仕事を調整するエンジンです。モデルが判断し、ツールが実際に動作し、データベースとディスクが過程と結果を保存します。これらの役割は一つのデスクトップ製品にまとまっていますが、同じプロセスで動くわけではありません。

この層構造を選んだ理由

起動時にプロセスを接続する仕組み

1. Tauri が実行ファイル化された Python sidecar を起動し、サービスの準備ができるまで起動画面を表示します。
2. sidecar はローカルポート 47317へのバインドを優先し、競合時には一時ポートを使います。その後、標準出力で ARSLAN_PORT を返してハンドシェイクします。
3. デスクトップシェルがポートを受け取ると、システム WebView に、ローカルサービスが提供する React ページを読み込ませます。固定ポートを優先することで、WebKit origin と UI のローカルストレージを安定させます。サーバー側の会話ディレクトリにより、ポートが変わっても履歴を再び見つけられます。
4. UI は HTTP でリソースを管理し、WebSocket でテキストストリーム、ツール状態、承認、タスクの進捗を受け取ります。ローカル接続でも token と接続元の検証は必要です。デスクトップアプリのサーバーは常に token を要求し、他のウェブサイトからの呼び出しを受け付けず、起動元の環境から引き継いだ設定を無視します。
5. シェルは、ライフサイクルを連動させるために標準入力パイプを保持します。親プロセスの終了で EOF が生じると、sidecar は後処理をして終了できます。出力パイプも継続的に読み取り、ブロックや、接続断後に孤児プロセスが残ることを防ぐ必要があります。

これらの仕組みにより、ウィンドウ、サービス、データベースのライフサイクルを整合させます。HTTP health の成功だけでは、WebSocket、添付ファイル、静的リソース、ネイティブ helper がすべて使えるとは確認できません。リリース時の受け入れ確認では、それぞれ個別に検査します。

起動の詳細：実行ファイル化したサービスの入口とポート方針；sidecar のハンドシェイクとパイプ管理；WebSocket 接続。

旧設計と新設計：再利用を保ち、専門家への振り分けを終了する

「統一ループ」は「すべて逐次実行」や「委任しない」という意味ではありません。コードには、制約付きの読み取り専用 worker が残っています。これは、独立した人格、装備、進化、ルーティングを持つ初期の専門家システムとは異なります。

コードの入口：デスクトップシェルと sidecar のライフサイクル；統合エントリーポイント；実行ループ；Python のネイティブ実行コアを維持する決定；Bridge プロセスの監視；ローカル Bridge 制御チャネル；デバイス間プロトコル。

06 / 実行ランタイム一つの依頼に、過程と境界と結果を持たせる

Arslan の実行コアは、ユーザーの意図を観察可能な一連の動作へ変えます。コンテキストを準備し、モデルを呼び出し、ツールの要求を検証し、許可された操作を実行し、実際の結果を読んで、続行するか成果を届けるかを判断します。v0.1.60 以降、既定の入口は統一ループです。メッセージは直接回答処理に入り、長期的な事実の抽出は回答後に行います。主要経路では、最初にモデルによるルーティングを行いません。また、どの返信からも到達できなくなっていた専門家時代のコード（専門家の作成、そのテンプレートとエンジン）は、v0.1.63 で削除されました。

ソース：メッセージの入口とコンテキストの構成；信頼できるタスクコンテキスト；統一ツールループ。

モデルは次の一手を提案し、ランタイムは実行条件を管理する

モデルに見えるツールは、名前、用途、引数 schema の集合です。モデルが構造化された tool_calls を返すと、ランタイムはまず JSON を解析し、引数を検証します。そのうえで、ツールが引き続き利用可能か、現在の予算で実行できるか、ユーザーの許可が必要かを再確認します。組み込みツールはレジストリによって実行関数に対応付けられ、mcp_ で始まるツールは MCP 呼び出しへ渡され、モデルに提供されるのは、今すぐ使える状態にある MCP サーバーだけです。レジストリに登録されていても、毎回の会話でそのツールが開放されるとは限りません。v0.1.63 以降、リクエストに載せるのは日常的に使うツールと二つの検索役 find_tools、use_tool だけです。あまり使わないツールと MCP ツールは、必要なときに見つけて呼び出し、承認も記録も直接呼び出した場合と同じです。会話が必要に応じて使ったツールの一覧は最大 12 件まで増え、メモリ上にのみ保持されます。

重要な境界の一つは応答の完全性です。提供者側の出力長制限でツール呼び出しが途切れた場合、そのバッチは、個々の呼び出しが完結して見えても実行しません。ツール呼び出しを含むモデルの文章は過程の説明としてのみ扱い、最終成果として先に提示することはできません。実行の前後でチェックポイントを記録し、実際のツール結果を、対応する呼び出しの識別情報とともにモデルへ返します。Web ページ、ファイル、外部ツールからの内容は、引き続きデータとして扱います。

したがって、「ファイルを保存しました」という説明には、実際の保存結果と成果物の参照が対応している必要があります。自然言語で約束しただけでは、操作が実行済みになったことにはなりません。ツールの失敗も次の入力に含まれ、ループは経路を調整できますが、同じ権限と予算を引き続き守る必要があります。

「指定したディレクトリを読み、一覧を作成する」例では、まずディレクトリのパスがタスクの入力範囲に入ります。モデルが読み取りを要求し、ツールが実際のファイル情報を返して初めて、一覧を作る根拠が得られます。さらにファイルの移動や削除を求められた場合、ランタイムはその操作に応じて許可を判断します。最終的には、生成済みのファイルを示し、確認結果を説明する必要があります。この過程におけるファイル一覧、操作の応答記録、成果物の参照は、それぞれ異なる証拠の役割を担います。

v0.1.63 以降、回答は書かれるそばから表示されます（後掲の各エンドポイントで）。これまで回答を保留していた検査は、必要なときに回答の後ろへ訂正を追加します。ストリームが途中で失敗した場合、Arslan はユーザーが見た内容を残し、最初からやり直さずに、返信が中断されたことを伝えます。モデルが続けて複数の読み取り（ウェブページ、検索、サーバー側が読み取り専用と示している MCP ツール）を求めた場合は、最大 4 件を同時に実行します。各結果はそれを求めた呼び出しと対応付けられたままで、読み取りではない呼び出しは、その位置で単独で実行されます。

ソース：同時に実行される読み取り；ストリーミングとツールループ。

入口を統一しながら、モデルのプロトコルの違いを保つ

LLMAdapter が統一された呼び出しインターフェースを提供し、各 Provider がリクエスト形式、ストリーミングイベント、ツール呼び出し、usage を扱います。Provider の実装は httpx で HTTP リクエストを送信します。OpenAI 互換エンドポイントにはローカルモデルサービスも設定できます。クラウドモデルを選んだ場合、対応するリクエストのコンテキストは、ユーザーが設定した提供者へ送られます。

Trajectory はループ内の構造化された実行軌跡であり、「どの呼び出しがどの結果を生んだか」という関係を保持します。内部の記録を統一しながら、各提供者がそれぞれのプロトコルを使えるため、ツールとのやり取りを照合しにくい一続きの通常テキストに押し込めずに済みます。エンドポイントがネイティブな履歴を拒否した場合、そのターンの残りは従来の構成方式に切り替わります。

この層には二つの修復があります。0.1.61 以降、プロバイダーが任意のリクエスト設定（たとえば新しい Claude モデルの temperature）を拒否した場合、Arslan はその設定を外すか、エラーが求める名前に変えて再送し、再起動までそのモデルについて記憶します。0.1.62 以降、MCP ツールの説明は Anthropic、OpenAI 互換プロバイダー、Gemini が受け付ける形に整え直されます。それでもプロバイダーが特定のツールを拒否した場合、そのツールは返信の残りの間は除外されます（2 回目の拒否、またはツールを特定しない拒否があった場合は、その返信ではすべての MCP ツールを除外します）。組み込みツールは書かれたまま送られます。

ソース：モデルの共通インターフェース；軌跡のデータ構造；Provider の能力に関する契約；拒否された設定を外して再送；MCP ツール説明の整形；必要なときに使うツール；実行層の変更説明。

一時的な協働 worker とバックグラウンドタスクの役割

delegate_work は、独立した調査を一時的な worker に分担させます。一度に最大 4 件、同時に実行できるのは最大 2 件です。現在、worker に開放しているのは web_search と web_extractだけです。ファイルや個人の記憶への書き込み、再帰的な再委任はできません。主担当が資料を受け取り、照合と統合を行います。この設計は、並列調査の利点を保ちつつ、実行の責任を元のタスクに集約します。

一方、バックグラウンド job は、時間のかかるタスク全体を扱います。独立したコンテキストと予算を持ち、ツールループ、成果物の検査、修正処理を再利用します。進捗はタスクカードを通じて会話に返され、既定では最大 3 件を同時実行します。ネットワーク接続、チャットウィンドウ、バックグラウンド実行はそれぞれ独自のライフサイクルを持つため、会話の切り替えはタスクのキャンセルを意味しません。マシンがスリープしたりプロセスが終了したりしても、バックグラウンド作業がクラウドに引き継がれるわけではありません。

強制上限に達する前に、成果をまとめる

予算では、モデルリクエスト数、ツール呼び出し数、累計 token、実行時間に加え、v0.1.63 以降はドル額も計測します。チャットの返信とバックグラウンドタスクには、同じ上限が適用されます。設定で選んだ段階（既定は standard）です。soft limit に達したら調査範囲の拡大を止め、既存の成果をまとめる必要があります。hard limit は、消費が際限なく続くことを防ぎます。入れ子の実行と再試行もタスク予算に計上します。また、進展のない繰り返し呼び出しを別途検出し、失敗した同じ経路を何度も試すことを避けます。

表は soft の既定値で、4 項目の hard 値はその 1.5 倍です。一回の出力上限と成果物のサイズ制限は別に計算します。token 使用量は応答後に計上するため、これらのしきい値は実行を調整するための境界であり、正確な費用上限や完了時間の保証ではありません。承認カードの返答を待っている時間は、実行時間に含めません。段階の上にはタスクごとのドル上限があり、既定でオン、$2 です（設定 › バックグラウンド › タスクごとのドル上限）。上限の 3 分の 2 に達すると締めくくりに入り、上限に達すると停止します。価格が分かっているモデルの応答だけが計上されるため、ローカルモデルや価格表にないモデルは加算されず、その場合も token の上限は有効です。確認は次のリクエストの前に行うため、実行は 1 回の応答分だけ超過することがあります。再開したタスクは、使用済みの回数、実行時間、ドル額を引き継ぎます。停止中の待機時間は再実行の時間には含めず、予算もリセットしません。

時間のかかる作業はチャットの中にとどまります。Arslan が自分でバックグラウンドへ押し出すことはなくなり、バックグラウンドタスクは、ユーザーまたはモデルが選んだときに、同じ作業を別の場所で行うものです。10 分経つと、返信は作業が続いていることを伝えます。ターミナルコマンドは、求めた時間だけ実行されます（既定 2 分、最大 10 分）。ただし、返信に残っている時間を超えることはありません。時間制限で止められた場合も、Arslan はそこまでの出力を受け取り、その旨を知らされます。出力があふれるコマンドは、先頭と末尾を残します。既定では、新しいコマンドはまずカードを表示します（v0.1.63）。定期タスクはこのバージョンではコマンドを実行せず、その手順はスキップされて Inbox に一覧されます。回答のないカードは 30 分で期限切れになり、これは拒否ではないと Arslan に伝えられます。

ソース：予算ルール；コマンドの時間制限と出力の上限；承認カードとその期限切れ；一時的な協働 worker；バックグラウンドタスク。

タスク、実行の試み、受け入れ判定を別々に記録する

TaskSpec は、指示、入力、範囲、受け入れ項目、予算といったタスクの合意条件を、改訂番号とともに保存します。一つの task に複数の attempt があり、attempt は具体的な一回の実行の試みです。条件の変更、取消後に届く古い結果、再開後の新しい試みの状態を混在させてはいけません。永続化の更新時には attempt の識別情報と row version の両方を確認し、古い実行が新しい状態を上書きすることを防ぎます。

受け入れ結果は、合格、失敗、未実施、該当なしなどを区別します。判定には対応する証拠が必要であり、約束した検査を省いたり、すべてをモデルの自己評価だけに頼ったりすることはできません。ファイルの存在、所属タスク、ダイジェストなどは決定論的に検証でき、主観的な品質についてモデルや人の評価を補助的に使います。準備中、実行中、効果不明の操作が残っている場合には、リポジトリ層でもタスクが直接成功状態になることを防ぎます。

タスクの改訂を識別する必要があるのもこのためです。古い要件に対する結果は、新しい要件が満たされた証拠にはなりません。受け入れ確認は、同じ版の合意条件、有効な同一の実行の試み、そのタスクに属する証拠に対応させます。重要な検査を任意に「該当なし」にすることはできず、契約ルールに合う重要度の低い項目に限って、その扱いが可能です。証拠が不足している場合は、未検証または未完了の状態を維持し、追加の確認を待ちます。

既存の証拠から安全に再開する

チェックポイントは、進捗、使用済み予算、証拠、成果物の参照を保存し、実行イベントは UI の再接続後に確認できます。プロセス内の run registry は、実際の非同期タスクとキャンセルの入口を保持し、接続中のウィンドウにイベントを配信します。再接続時にはスナップショットの取得とイベントストリームへの接続を一体で行い、接続の引き継ぎ時にイベントが欠落したり重複したりすることを減らします。

プロセス再起動後、終了していない実行は中断として識別され、ユーザーが明示的に続行します。外部へ送信済みでも応答を受け取れていない操作は、効果が不明です。直接再送せず、先に照合する必要があります。バックアップからの復元では、古い操作許可を失効させ、関連する操作を不確定として記録します。チェックポイントが解決するのは「どこから安全に続けられるか」であり、すでに生じた外部の結果を取り消すものではありません。

「このターンを元に戻す」には、別の種類のチェックポイントが使われます（v0.1.63）。ターンが初めてファイルを書くかコマンドを実行するとき、Arslan は作業フォルダーを元の状態のまま一度だけ保存します。元に戻すと、ファイルが復元され、そのターンとそれ以降のすべてのターンが、そこで学んだ事実とともに会話から取り除かれます。要約は残り、メッセージ ID が再利用されることはありません。フォルダーが保存されるのは、ファイルが 20,000 件以下で 5 GB 以下であり、空きディスク容量が十分で、Arslan のデータと同じディスク上にある場合に限られます。再構築できるフォルダー（Python 環境、node_modules、ビルド出力、__pycache__）と、秘密情報の形をしたファイルは保存の対象外で、元に戻すときも復元されません。元に戻すためのボックスには、保存されなかったものが表示されます。ターンの後に変更されたファイルは残され、一覧されます。実行がまだフォルダーを変更している間は、元に戻す操作は拒否されます。

停止にも二つの層があります。実行レジストリは待機中または実行中の非同期処理をキャンセルし、永続化された状態は遅れて届く結果の反映を阻止します。外部システムがすでに受け付けた要求について、ローカルの待機をキャンセルしても、相手側が未実行であるとは証明できません。そのため、操作テーブルでは、準備中、開始済み、確認済み、失敗、効果不明、キャンセル済みなどの状態を区別します。復旧処理はまずそれらを確認し、どの手順を再試行できるかを判断します。

ソース：タスクと受け入れ確認の契約；永続化された状態と並行更新の検査；成果物の検証；実行と明示的な続行；接続と実行の分離；バックアップ復元の境界；元に戻すためのフォルダーのチェックポイント；ターンの取り消し。

ウィンドウに状況を伝え続けるターン

0.1.59 以降、ターンの実行中は、モデルが 1 つの長いファイルを数分かけて書いている場合でも、サーバーが少なくとも 15 秒ごとに「作業中」のイベントをウィンドウへ送ります。そのため、「Interrupted」は接続そのものが失われたことを意味するようになりました。v0.1.63 以降、Arslan がまだ回答している間に送られたメッセージは、返信が終わるのを待たず、返信の次のステップでその返信に届きます。まだ始まっていないステップはスキップされ、返信はまずそのメッセージを読み、ウィンドウには追加されたことが表示されます。最終回答をすでに書いている返信には残りのステップがないため、メッセージはその直後に実行されます。承認カードが待機している間にメッセージを送ると、メッセージの内容を添え書きとしてカードに「いいえ」と答えたことになり、メッセージは次に実行されます。回答の言語は、ユーザーの最新のメッセージに合わせます。判定ではパス、URL、コードを無視し、言葉を含まないメッセージには UI の言語で回答します。ウィンドウの接続が切れている間に承認を求めても、ターンが失敗することはなくなりました。カードは Inbox、Island、または再接続したウィンドウで待機します。

ソース：作業中イベント、キュー、再接続後のカード；実行中の返信に追加されたメッセージ；回答の言語。

プロジェクト：ボード、レベル、証拠を必要とするチェックポイント

0.1.56 以降、プロジェクトはレベルの計画を持ちます。各レベルには明確な達成条件と、いくつかのチェックポイントがあります。種類（ゲーム、アプリ、ウェブサイト、リサーチ、執筆、動画、スキル、旅行、仕事、その他）を選ぶと、モデルを呼び出さずにテンプレートからレベルの下書きが作られます。「Let Arslan refine」を使うと、ユーザー自身のモデルを 1 回だけ呼び出し、ゴールに合わせてレベルを調整します。ユーザーがプロジェクトを作成するまで、何も保存されません。ボードの列（Idea、Shaping、Doing、Done）は現在のレベルから導かれるもので、ドラッグで動かすことはありません。Done と Dropped を設定できるのはユーザーだけです。

Arslan が計画を進めるのは、示せる証拠があるときだけで、対象も現在のレベルに限られます。ファイルを指定したチェックポイントは、そのファイルがプロジェクトフォルダーに現れた時点でチェックが付きます。ユーザー自身の発言の後には、判定役（judge）がそのメッセージが何かの完了を伝えているかを確かめます。プロジェクトの引き継ぎから始めたバックグラウンドジョブは、完了状態で終わったときに対応するチェックポイントにチェックを付けます。小さなチェックは取り消せます。レベルのクリアはカード上の提案として示され、通知や Inbox の項目にはなりません。Arslan が自分でレベルを進めてよいか一度だけ尋ねるのは、10 回続けて推測が正しかった後に限られます。学習した計画のルール、ユーザーのペース、「停滞」のヒントはローカルにとどまり、モデルに届くのはユーザーが自分で始めた下書き作成の要求の中だけです。

ソース：レベル、ボード、提案；ファイル、ユーザーの発言、実行；レベルのテンプレート；計画のルール、ペース、停滞。

07 / データと記憶役立つコンテキストを残し、データの境界も明確にする

Arslan は、主な状態をマシン上の SQLite に保存します。会話、実行記録、タスク、個人の記憶、モデル設定、使用量には、それぞれ対応するデータモデルがあります。ファイルの成果物はディスクに書き込みます。非常に長いツール出力の全文はアプリのデータフォルダーに別途保存され（保持期間は 7 日間）、モデルは結果に示されたパスから分割して読み取ります。そのため、ウィンドウを閉じてもタスクの過程は消えず、「そのとき何を話したか」「実際に何をしたか」「今後何を覚えてよいか」を別々に管理できます。

データへのアクセスには、非同期 SQLAlchemy と aiosqliteを使います。接続では WAL、外部キー検査、5 秒のビジータイムアウトを有効にし、 synchronous=NORMALを設定しています。これらはローカルの単一ユーザー向けアプリに合わせた選択で、配備時の依存を減らし、読み書きが並行する場合の使い勝手を改善します。データディレクトリには協調型のプロセスロックも設け、同じプロトコルを守るインスタンスが同じデータを同時に使うことを防ぎます。

役割ごとにデータオブジェクトを分ける

タスクテーブルは現在の状態、改訂テーブルは合意条件、attempt テーブルは実行の試み、event テーブルは順序付きイベント、action テーブルは実際の操作とその効果の状態を保存します。これらが連携して、検証と復旧を支えます。個人の記憶では、安定した識別情報、内容の改訂、出所を分離し、編集、追跡、削除をしやすくしています。すべてのチャット内容を、そのまま永続的な記憶にしているわけではありません。

ソース：SQLite 接続；実行・資料・設定のモデル；タスクモデル；個人コンテキストと記憶のモデル。

作業用コンテキスト：今回の入力を制御し、元の履歴を残す

モデルが一度に受け取れる量には限りがあるため、Arslan は長さに上限のある逐次更新の要約と最近のメッセージで、作業用コンテキストを構成します。v0.1.63 以降、この履歴ウィンドウの大きさは、そのターンのモデルによって決まります。推定でコンテキストウィンドウの 40% とし、3,000 token を下回らず 24,000 token を超えません（不明なモデルは 32,000、ローカルモデルは 8,192 とみなします）。要約そのものにも長さの制限があります。これは履歴を組み立てるための予算であり、モデルリクエスト全体の大きさという意味ではありません。システム指示、ツール schema、資料、結果も別の領域を使います。

会話が長くなると、直近 4 回のユーザーターンは原文のまま残り（予算の半分に収まる間）、それより古いターンのツール要約が先にマスクされます。これには費用がかかりません。履歴が予算の 4 分の 3 を超えると、古いメッセージが要約にまとめられ、要約には「目標」「進捗」「決定事項」「触れたファイル」「次のステップ」の各項目が保たれます。ターンごとに変わるもの（事実、要約、資料、回答の言語）は、システムプロンプトではなく、そのターンのリクエストの冒頭にある参照ブロックに載せられ、ユーザーの言葉として保存されることはありません。圧縮が変えるのは次回の入力に含める内容であり、データベース内の完全な会話を削除するわけではありません。圧縮に失敗しても元の記録は残ります。長すぎるツール出力には、別途ディスクへ保存する仕組みがあります。モデルには先頭と末尾の抜粋とファイルパスを渡し、必要に応じて分割して読み取ります。完全な出力は保持ポリシーに従って削除します。

この層構造により、モデルには現在のタスクに必要な情報を優先して見せながら、後の照合に使う元の根拠を残せます。要約は既存の内容を圧縮した表現にすぎず、外部操作の実際の応答記録の代わりにはなりません。

個人の記憶：関連性より先に、利用できるかを判断する

記憶の項目には、種類、範囲、機密度、利用ポリシー、状態、信頼度に関する情報、改訂番号を持たせます。範囲はグローバルまたは特定のプロジェクトで（ほかにドメインや専門家などの内部的な範囲もあります）、各項目には所有者もあります。local_only などの利用ポリシーが、クラウドモデルへの要求に含めてよいかをさらに決定します。各ターンの信頼できるコンテキストは、データベースから会話設定を読み込みます。通常のユーザーテキスト、Web ページ、モデル出力が、これらの権限を勝手に書き換えることはできません。

「あなたについて」と「Mac ノート」は、量を制限した基本情報として挿入し、その他の内容は関連性で選びます。v0.1.52 以降は、既定で有効な「自分のことを覚え、会話で使う」により、通常の項目で、cloud_allowed のものを、設定済みのクラウドモデルで使えます。機微な内容には追加の許可が必要です。local_only の内容は、全体のスイッチを有効にしてもクラウドに送れるようにはなりません。

ContextReceipt は、使った項目と改訂、利用理由、推定量を記録し、記憶の本文は複製しません。ユーザーはコンテキストの選択根拠を追跡でき、システムもそのために機微な内容のコピーを新たに作らずに済みます。

記憶を編集すると新しい改訂が作られ、項目の現在の改訂を指すポインターも更新されます。出所の記録は、その版がどのように形成されたかを引き続き示します。停止、期限切れ、置換済み、削除などの状態も、後続のコンテキストに含めるかに影響します。バージョン管理は変更の照合に役立ちますが、削除処理では消す必要のある本文を消去します。したがって、すべての履歴が永久に削除できないイベントストアではありません。

ソース：履歴と要約；長いツール出力；モデルのウィンドウに応じた履歴の大きさ；ターンごとの参照ブロック；会話の許可；範囲・プライバシーによる絞り込みと利用記録。

資料検索：キーワードとベクトルを組み合わせる

知識資料の検索モジュールは、SQLite FTS5 の全文検索と、ベクトルのコサイン類似度検索に対応しています。前者は語句の一致を、後者は embedding を使って意味の近い断片を探します。両方を利用できる場合は、RRF で順位を統合します。RRF が比べるのは順位であり、尺度の異なる生のスコアを直接混ぜません。embedding が未設定、またはベクトルがない場合も、全文検索を利用できます。

検索された断片は出典とともにモデルのコンテキストに入り、モデルが現在の質問と合わせて回答を組み立てます。ここでいう RAG は、この仕組みを指します。資料の検索は資料コレクションが紐付けられたプロジェクトでのみ行われます。クラウドモデルを使う場合は、その会話自体のクラウド記憶の許可も有効である必要があります（既定の「Remember me」スイッチは資料を対象にしません）。結果は recall ツールの戻り値としてコンテキストに入ります。基盤モデルの重みを変更する必要はなく、別途配備したベクトルデータベースにも依存しません。個人の記憶 v2 の選択には、主に権限による絞り込み、全文検索、ローカルの関連性ロジックを使います。すべての記憶が同じベクトル処理を通ると解釈することはできません。

経験からの学習：訂正を、レビューできるルールにする

Lesson は、ユーザーの訂正、失敗の後に成功した回避策、マシン環境の特徴を保存します。たとえば、現在の Mac であるコマンドに別の引数が必要なら、出所のある経験として残し、類似タスクの参考にできます。呼び出すのは最大 5 件、合計約 800 文字で、動的な agent status に入れ、固定のシステムプレフィックスには混ぜません。呼び出し、遵守、成功、失敗をそれぞれ計数します。

保存する価値があるか、既存の内容と重複または矛盾するかについては、judgment 層が狭い範囲の判断を提示し、確率と後の結果を記録できます。ユーザーの訂正や、外部コンテンツの影響を受けていない経験は、設定で許可され、有用と判断されれば直接有効にできます。その他のレビューが必要な内容は提案へ送ります。認証情報を含む候補はその場で破棄されます。「推測された機微情報はレビューが必要」というルールは個人の記憶に適用されるもので、経験には適用されません。判断が得られない場合やタイムアウト時には、フォールバック経路があります。

0.1.55 以降、訂正として扱われるのは、会話の中で Arslan が以前に行ったことへの応答だけです。最初のメッセージは依頼であり、訂正にはなりません。同じターンでうまくいったばかりの経路に反する訂正は、すぐには有効にならず、ユーザーの承認を待つ提案になります。また、macOS が権限を拒否した場合のように、ユーザー自身が直す必要のある失敗を、別の経路を取る理由として学習することはありません。Arslan が会話中に記憶を保存したときは、そのことをスレッド内に表示し、Undo で取り消せるようにします。

これらの仕組みは、アプリが保存して呼び出す知識を変更するもので、モデルの重みを学習するものではありません。judgment の有効範囲も用途ごとに異なります。記憶、経験、プロジェクトの各ポイントは回答後に実行され、登録されている一つ（ターンの完了）はオフです。コマンドを実行するかどうかを決める judgment はありません。コマンドカードの shadow 判断は v0.1.63 で削除され、許可フローだけが決めます。

ソース：資料のハイブリッド検索；経験の抽出と呼び出し；小規模な判断と実行モード。

削除を、要約と古いバックアップにも反映する

記憶を削除すると、システムは deletion epoch を進め、その項目の古い改訂の本文と出所を消去し、すべての会話の逐次要約と、実行記録にキャッシュされたプロンプトを消去します。これにより、古い派生コンテンツが削除済みの記憶を呼び戻すことはありません。削除記録には照合用のコンテンツ指紋（ローカル鍵による HMAC）と範囲などのメタデータだけを残し、削除済みの本文を台帳に再保存することを避けます。suppression 記録は、チャット履歴に残る同じ出所から記憶が再び自動生成されるのを防ぎます。記憶の削除と元の会話の削除は、別々のデータ操作です。「このターンを元に戻す」は、さらに範囲の狭い三つ目の操作です。出所のすべてが取り消されたターンである項目を削除し（ほかの出所にも裏付けられている項目は、その出所だけを失います）、本文の墓標は残さず、要約は保持します。

独立した削除台帳と削除マニフェストにより、起動時と復元時にも削除を引き続き適用します。古いバックアップを復元する前には、ストレージの識別情報を検証し、データを有効にする前に、削除情報と照合して一時領域のデータを整理します。これにより、古いバックアップから削除済みの記憶が戻る可能性を抑えます。この保証は復元手順と利用可能な削除記録に依存し、外部に出力済みのすべてのコピーを取り消せるという意味ではありません。

バックアップ内の他の記憶も、すべての利用許可がすぐに復元されるわけではありません。復元処理はそれらをレビュー待ちとして隔離し、利用ポリシーを厳しくし、キャッシュされたコンテキストを消去し、すべての定期タスクを無効にし、会話単位のクラウド利用と機微情報の許可を取り消し、進行中のプロジェクトをアーカイブします。データの復元と利用の再承認を分けることで、古い会話の許可が新しい実行環境で知らないうちに有効になることを防ぎます。

移行を完了してから、アプリがデータを使い始める

現在のデータベース更新は、明示的な移行 runner を使います。schema のバージョン検査、更新前バックアップの準備、不足するテーブルの作成、未実行の移行の順次実行を行い、その後に鍵の互換性処理と記憶 v2 の有効化を行います。不明な schema や新しすぎる schema は拒否し、古いプログラムが新しいデータを不用意に変更することを防ぎます。v0.1.63 の明示的な登録は 0070まで進んでいます。初期の Alembic の履歴を、現在の実行方式と混同しないでください。v0.1.60 以降に追加されたのは、0067（権限テーブル）、0068（MCP サーバーごとの一つの状態と各ツールのヒント）、0069（メッセージ ID は再利用されないため、ターンを元に戻しても削除済みの ID が再び割り当てられることはありません）、0070（保存されていた「危険なコマンドのときだけ確認」が、一度だけ「すべてのコマンドの前に確認」へ移行）です。

記憶 v2 の有効化では、旧来の事実テーブルと学習テーブルを legacy テーブルに改名し、読み取り専用のトリガーを追加します。互換ビューが旧来の読み取り口を新構造に対応付け、全文インデックスもこの過程で作成します。モデルの API キー、MCP の環境変数と OAuth トークン、SSH 鍵などの秘密フィールドには、フィールド単位の Fernet 暗号化（PBKDF2 とインストールごとに独立した salt）を使いますが、通常の会話やタスクのテーブルまで含めたデータベース全体の暗号化ではありません。永続化、秘密情報の保護、バックアップからの復元には、それぞれ固有の境界があります。

ソース：記憶の削除と改訂；常設の回答とタスクごとの回答；ターンの取り消し；削除台帳；復元前の削除照合；バックアップ復元の調整；復元データの隔離；ストレージの起動順序；明示的な移行；権限テーブル；記憶構造の有効化；鍵フィールドの保護。

08 / ツール、Skill、拡張機能機能を再利用し、実行の境界を保つ

Arslan は、「何ができるか」と「どう行うか」を分けて構成しています。ツールは実際の操作、Skill は手順と参考資料、MCP は外部機能との接続を担い、プラグインのマニフェストがそれらを組み合わせます。モデルが受け取るのは、そのターンで利用できる機能の集合です。ソースのレジストリにツールが存在しても、既定で有効であることや、実行が許可済みであることを意味しません。

四つの概念の関係

宣言から実行までに行う検査

組み込みツールは登録済みの実行器が処理し、 mcp_ で始まる呼び出しは MCP プロキシに渡されます。ツール結果は統一ループへ戻り、モデルはそれをもとに引数を補い、代替手段を選び、またはタスクを終えます。モデルがすでに Skill を読んでいても、ファイル、コマンド、アプリの操作は、それぞれの権限検査を通る必要があります。

0.1.63 以降、リクエストはすべてのツールを載せるわけではありません。載せるのは、日常的に使うツールの常駐セット（ウェブ検索とページの読み取り、ファイルの読み取り・書き込み・編集、ターミナル、計画、バックグラウンド作業、記憶、read_skill、機能の一覧、Hands のデスクトップツール）と、二つの検索役です。find_tools は、このターンで呼び出せるが提示されていないツールを順位付けし、use_tool はそのうち一つを本来の名前で呼び出します。引数はそのツール自身のパラメーターに照らして検査され、直接呼び出した場合と同じ承認、トレース、受領記録が適用されます。MCP ツール、attach_file、ブラウザーツールは、この方法で利用します。必要に応じて使ったツールは、次のターンからその会話の一覧に加わります（会話ごとに最大 12 件、メモリ上に保持されるため、再起動後はモデルが改めて探します）。find_tools が返す MCP サーバーのテキストは、指示ではなく外部のデータとして包まれます。

モデルが続けて複数の読み取りを求めた場合は、最大 4 件を同時に実行します。対象は、ウェブ検索とページの読み取り、read_skill、ファイルの読み取りや一覧表示など、そしてサーバー側が読み取り専用と示している MCP ツール（一つのグループにつきサーバーごとに 1 件）です。各呼び出しは引き続き返信の順序ですべての関門を通り、各結果はそれを求めた呼び出しと対応付けられたままです。読み取りではないものは、その位置で単独で実行されます。

Skill は必要に応じて読み込みます。索引が利用できる手順をモデルに示し、read_skill が登録済みの SkillPack または許可された参考資料のパスから本文を取得します。これにより、手順のライブラリを増やしながら、各ターンのコンテキスト量を抑えられます。Arslan は独自の Skill を二つ同梱しています。デザインされた HTML レポートと、Skill を作る Skill です。0.1.63 以降、専門家時代の初期データ、あらかじめ用意された MCP コネクターの一覧、モデルのコネクター提案ツールはなくなりました（新しい MCP サーバーの検索は、後述の find_capability を通ります）。また、廃止された名前でインポートした Skill が削除されることもなくなりました。

0.1.55 以降、Capabilities ページでは Arslan にできることをスイッチとして一覧表示し、それぞれがオン、オフ、あと一歩で使える、この環境では使えない、のいずれかであるかを理由とともに示します。オフにした機能はモデルにまったく提示されず、read_skill もオフの Skill の読み込みを拒否します。各行は、そのターンでどのツールを渡すかを決めるのと同じゲートから読み取るため、ツールが欠けているのに行が「オン」と表示されることはありません。whats_new ツールは、「どのバージョンか、何が変わったか」という質問に、モデルの記憶ではなく、アプリに同梱されたリリースノートから答えます。

拡張サービスは、新たな信頼境界になる

ローカルの stdio MCP は通常、独立したプロセスの起動を伴い、HTTP MCP はリモートサービスへ接続する場合があります。Arslan は、接続、主アシスタントからの利用可否、ツールの公開、認証情報の保存と表示をそれぞれ管理します。プラグインのマニフェストで宣言する HTTP MCP サービスの URL は、HTTPS が必須です。secret スロットはパラメーターの形式を宣言し、実際の認証情報をマニフェストに埋め込みません。設定済みの環境値は暗号化して保存し、読み出して表示するときはマスクします。

0.1.61 以降、ユーザーがオンにした MCP サーバーはすべて、Arslan を開いたときにバックグラウンドで起動します。同時に起動するのは最大 4 つで、チャットがその完了を待つことはありません。各サーバーには、「機能」ページとモデルの両方が読む一つの状態があり、モデルに提供されるのは今すぐ使える状態のサーバーだけです。それ以外のサーバーへの呼び出しには、その状態と理由が返され、キーとトークンはマスクされます。初回の起動には 120 秒が与えられます。失敗したサーバーは 30 秒後に再試行され、その後は間隔が広がります（最長でも 10 分に 1 回）。

0.1.62 以降、Arslan は MCP ツールのパラメーター説明を、Anthropic、OpenAI 互換プロバイダー、Gemini が受け付ける形に整え直してから送ります。組み込みツールは書かれたまま送られます。それでもプロバイダーが特定のツールを拒否した場合、そのツールは返信の残りの間は除外され、返信は続きます（拒否がツールを特定しない場合や、2 つ目のツールが拒否された場合は、その返信ではすべての MCP ツールが除外されます）。

0.1.63 以降、MCP の呼び出しは、サーバーがそのツールの動作をどう示しているかに応じて確認を求めます。サーバーが読み取り専用と示しているツールは、カードなしで実行されます。破壊的と示しているものは、毎回、今回のみとして確認を求めます。それ以外は、今回のみ、またはその会話について確認を求め、「Always」は選べません。引数が長すぎてカードに全文を表示できない呼び出しは、切り詰めずに拒否されます。これらの印はサーバー自身の申告であり、Arslan が検証するものではありません。確認できる相手がいない場合（定期実行）は、読み取り専用のツールだけが実行されます。

これらの制約は、意図しない露出や誤実行の機会を減らしますが、実際の MCP サービスは、与えられたリソースにアクセスし得ます。ツールの出所、必要な権限、リモートへ送られるデータ、操作の副作用は、いずれも拡張機能として説明すべき事項です。

育つ能力：探す、尋ねる、インストールする、スキャンする、テストする

0.1.57 以降、ある手順に Arslan のできないことが必要になると、find_capability が公式の MCP Registry、GitHub、審査済みのスキルライブラリをまとめて検索します。propose_capability が名前を挙げられるのは、この会話で提示された候補だけです。カードはモデルの言葉からではなく、その検索結果からサーバー側で組み立てます。内容は、追加される機能、入手元、プロジェクト自身のライセンスファイルから読み取ったライセンス、実行方法、使用できるフォルダー、必要なキーです。承認できるのは、尋ねた Arslan のウィンドウだけです。バックグラウンドジョブや、尋ねる相手のいないターンでは、見つけた候補を Capabilities ページの「Arslan found」に記録するにとどめます。

承認後は、バージョンを固定し、無効の状態でインストールします。ハッシュ付きのロック、公開されたチェックサム、またはコミットで固定し、Arslan 自身の固定された uv または Node を使います。インストール中にパッケージのコードは実行しません（wheel のみ、npm はインストールスクリプトなし）。スキャンは既知の危険なパターンを探します。たとえば、スキルに隠された指示、さらにコードを取得して実行するコード、macOS がプログラムを起動する場所への書き込みです。重大な検出があれば、再び削除します。スキャンでは安全を証明できません。そのため、サーバーはその後、専用のサンドボックス内で動作します（第 09 章）。有効にする前に、起動して少なくとも 1 つのツールを一覧に出せなければなりません。ツールループはツール一覧を読み直すので、失敗した手順を同じ返信の中でやり直せます。GitHub から取り込んだスキルは、1 つのコミットに固定し、ファイルごとにチェックサムを持ちます。その本文は外部のコンテンツとして読み、権限を与えることはできません。

ソース：確認、インストール、スキャン、テスト、有効化；固定したインストールと入手元でのライセンス確認；既知パターンのスキャン；MCP Registry、GitHub、スキルライブラリ。

ファイルはファイルとして返る：ワークベンチのリーダー

0.1.58 以降、ターンの中で書き出されたファイルは返信の下にカードとして表示され、返信に含まれるパスは Arslan 内またはファイルブラウザーで開けます。ワークベンチのリーダーが読み取れるのは、Arslan 自身の読み取りツールが読める場所に限られます。つまり、ワークスペース、既定の読み取りが有効な場合の Desktop、Documents、Downloads、アクティブなプロジェクトのフォルダー、Arslan 自身の出力です。シンボリックリンクは先に解決し、隠しファイルや認証情報のような名前のファイルは一覧にも表示せず、読み取りもしません。ファイルのバイト列は nosniff 付きの添付として送り、HTML は空の sandbox 属性を持つ iframe 内に表示するため、そのスクリプトは実行できません。

0.1.63 以降、スクリーンショット、グラフ、エクスポート、文書などのファイルを求めると、attach_file がそれを回答に添付します。ウィンドウにはファイルカードが表示され、ペアリングした iPhone にはファイルそのものが届きます。これはリーダーが読める場所を読むだけなので専用のカードは出ず、同じルールが適用されます。隠しファイルや認証情報のような名前は対象外で、読み取り可能なフォルダーの外へ出るリンクも対象外です。また、Arslan 自身のデータ、キーチェーン、SSH 鍵の配下にあるもの、20 MB を超えるファイル、1 回の実行で保持できる数を超えるファイルも添付しません。

ソース：attach_file；リーダーの読み取り範囲と隠す名前；ファイルのバイト列；サンドボックス化した HTML。

Hands v2：一つのウィンドウの画像、バッチ、前面の借用、画面の引き継ぎ

Hands は引き続き、ウィンドウをアクセシビリティツリーとして読み取ります。0.1.60 以降は、読み取りのたびに、その一つのウィンドウの JPEG を添付することもできます。画面全体を撮ることはありません。画像はメモリ上にだけ保持してモデルにのみ送り、ディスク、トレース、UI には書き出しません。モデルが画像を受け付けない場合は、代わりに macOS Vision がローカルで文字を読み取ります。この機能は設定 → Hands でオフにでき、指定したアプリではテキストだけに限定することもできます。一つのアプリでの複数の手順は最大 8 件のバッチとしてまとめて実行し、アプリが前面にないときでもメニュー項目を直接選び、アプリはバックグラウンドで開きます。0.1.62 までは、チャットの返信で行える操作は最大 5 件で、すべて一つのアプリ内に限られていました。0.1.63 以降、チャットの返信に Hands 独自の上限はなく、バックグラウンドジョブと同じく実行自体の上限の中で操作します。スケジュール実行は Mac 上で一切操作できません。承認する人がいないためです。

ポップアップメニューのように、アプリが前面にないと動かない操作もあります。その場合 Hands は、キー入力が 1 秒途切れるのを待ってから、すべてのディスプレイの縁が青く光る間、約 1 秒だけ前面を借ります。その間に押されたキーは保持しておき、ユーザーのアプリが前面に戻ったときに再送します。アプリのウィンドウが別のデスクトップにある場合、Hands は同じルールのもとでそこへ移動し、作業が終わったとき、操作のないまま 15 秒が経ったとき、またはユーザーが最初に入力したときに戻ります。より長い作業では、バックグラウンドジョブが最大 30 分間、画面の引き継ぎを求めることができます。キーボードやマウスの入力があると、ユーザーが続行するまで一時停止します。「While I'm away」は既定でオフです。オンにすると、入力のないまま 3 分が経った後、カードなしで引き継ぎを始めることがあります。前面の借用はオフにでき、その場合 Hands は代わりに操作を断ります。

ソース：一つのウィンドウのみ、何も書き出さない；前面の借用；別のデスクトップ；画面の引き継ぎと入力による一時停止；チャット内の操作、バッチ、メニュー；設定 → Hands。

検索とウェブの読み取り

0.1.63 以降、web_search は、そのターンが動いているモデル自身の検索を最初に使います。Anthropic 自身の API 上の Claude の会話では Anthropic のウェブ検索、DeepSeek のモデルでは DeepSeek の検索です。ローカルモデルでの会話が、検索クエリをプロバイダー自身の検索へ送ることはありません。設定で選んだ Tavily またはセルフホストの SearXNG は、唯一の検索になるか、モデル自身の検索の次のバックアップになります。意図的な選択がない場合は、ベストエフォートの DuckDuckGo のスクレイピングが最後に来ます。検索サービスが Arslan を拒否したときは、結果に検索がブロックされ何も検索されなかったと示され、「結果なし」とは表示されません。

ページの読み取りとブラウザーでは、外向きの通信のガードが維持されます。ローカル名、実際のプライベートアドレス、制御文字を含むホストは拒否されます。0.1.61 以降、プロキシや VPN が DNS に偽のアドレス（198.18.0.0/15）で応答する Mac では、https のポート 443 で要求された名前のうち、すべてのアドレスがそのブロックにあるものは通され、そのような名前への通常の http や別のポートは拒否されます。そのような名前では、リクエストが実際にどこへ行くかをプロキシが決めます。引き続き有効なのは TLS であり、実際の名前に対して検証されます。

ソース：検索の順序とブロックされた検索；プロバイダーごとの検索；外向き通信のガードと偽 IP の例外。

並列調査を残している理由

統一 Agent ループには、制限付きの一時的な読み取り専用 workers が残っています。v0.1.63 では一度に最大 4 件、同時に最大 2 件を実行できます。ツールは検索と Web ページ抽出に限られ、ファイルや個人の記憶へ書き込まず、再帰的に workers を増やすこともできません。主アシスタントが結果を確認して統合します。

この委任は、互いに独立した資料調査を分割するのに適しています。初期の恒久的な専門家の分身とはライフサイクルが異なり、ユーザーが先に専門家チームを選んだり管理したりする必要はありません。また、すべてのメッセージを別の「専門家」に強制的に振り分けるものでもありません。並列化するかどうかは、タスクを有効に分割できるかと、追加の呼び出し費用によって判断します。

バックグラウンド、定期実行、heartbeat

バックグラウンド job は、時間のかかる実行を現在のチャットから切り離し、同じモデル、ツール、受け入れ確認のロジックを再利用します。定期タスクは「いつ開始するか」を永続化します。heartbeat はチェックリストを定期的に確認する用途の一つで、既定では無効であり、確認と提案を担当します。定刻に起動したからといって、提案が承認済みの書き込みやコマンドになるわけではありません。0.1.63 以降、定期実行はすべて、確認できる相手のいない通常の Arslan のターンです。このバージョンでは、以前に何を許可していたかにかかわらず、ターミナルコマンドを一切実行せず、書き込みは Arslan 自身のフォルダーにだけ行い、Mac を操作せず、サーバーが読み取り専用と示している MCP ツールだけを実行します。それ以上が必要な手順は拒否され、Inbox に一覧されます。

チャットの返信とバックグラウンドタスクは、タスクごとのドル上限で止まります（既定でオン、$2。上限の約 3 分の 2 で締めくくりに入ります。価格が分かっているモデルだけが計上されます）。上限は設定で変更できます。長い作業のために、チャットの返信がバックグラウンドへ押し出されることはなくなりました。バックグラウンドの作業は、ユーザーまたはモデルが選んだときに、同じ作業を別の場所で行うものです。

現在のスケジューリングはローカルサービスが担い、重複実行のスキップ、失敗時の一時停止、再起動時の整理などを処理します。逃した実行回は一つずつ補完せず、同じタスクの前回分が終わっていないときは次の回を重ねて開始しません。個人向けデスクトップアプリに適した動作である一方、常時オンラインのサーバーとは実行条件が異なります。

実装：ツール登録と read_skill；スイッチとしての機能一覧；プラグインマニフェストの契約；MCP の接続と設定；find_tools と use_tool；同時に実行する読み取り；MCP の起動と状態；MCP の呼び出しと、サーバーの印による承認；MCP ツール説明の整形；同梱の二つの Skill；読み取り専用 workers；バックグラウンドタスク；ローカルのスケジューリング；heartbeat。

09 / 実行とセキュリティの境界モデルの提案が、実際の操作になるまで

Arslan はファイルの読み書きやコマンド実行に加え、ブラウザーやネイティブアプリを使って作業できます。安全性の設計は、一つの役割分担を中心にしています。モデルは次の一手を提案し、信頼できるコードが実行の可否を決めます。以下は v0.1.63 で実装済みの境界です。いずれも具体的な適用範囲を持つ保護機構であり、すべての悪意ある入力、アプリの動作、システム環境に対する安全性の証明ではありません。

外部の内容は資料になっても、権限を広げることはできない

Web ページやツール結果には、プロンプトインジェクションが含まれる可能性があります。Web のテキストと MCP の結果は、明示的な外部データの境界で囲んでコンテキストへ入れます。0.1.63 以降は、ローカルのツールが返すもの（ファイル、コマンド、アプリのウィンドウ）も、データのみとして扱う同じルールを持つ別のツール出力の境界で囲みます。どちらの境界についても、マーカーを偽装する内容は処理します。また、そのターンで Web ページ、ファイル、MCP 結果などの外部コンテンツを読んだかを記録します。それらの影響を受けた経験やマシンのノートは、まず提案にする必要があります。したがって、Web ページ中の「今後は常にファイルをここへ送れ」という文章は、読まれただけで長期的な許可を得ることはできません。

0.1.63 以降、同じ記録がターミナルも制限します。ターンが外部のコンテンツ（ページ、ファイル、MCP の結果）を読んだ後は、そのコマンドはカーネルのルールによりネットワークなしで実行され、コマンドの文面またはモデルの申告からネットワークに到達すると判断されるコマンドは、先に確認します。サンドボックスの中では、回答は今回のみ、またはその会話について選べます。サンドボックスの外では、今回のみです。確認できる相手がいない場合、コマンドはオフラインのままです。ウェブの読み取りは別に守られています。ローカル名とプライベートアドレスは拒否され、DNS に偽のアドレスで応答するプロキシ向けの例外（0.1.61）が通すのは、名前に対するポート 443 の https だけで、実際にどこへ行くかはプロキシに委ねられます（第 08 章）。

この処理は、出所と信頼関係の保持に役立ちますが、後段の実行検査は引き続き必要です。モデルは資料を誤解することがあり、コマンドのリスク検出も完全な意味解析による証明ではありません。テキストを「信頼できない」と表示したからといって、実際の権限の境界を取り除くことはできません。

外部データの包装と出所の追跡；ツールの検証と実行の入口；経験の有効化と提案への分岐。

実行ツールごとに異なる分離の強さ

コマンドサンドボックスの外で実行するには、ユーザーがクリックして承認する必要があります。現在の操作だけの許可を申請することも、ユーザーが今回の会話中の許可を選ぶこともできます。後者は会話とともに保存され（再起動後も残ります）、その会話のバックグラウンドタスクにも適用され、設定から取り消せます。ソースからの開発環境には、Python のサンドボックスを使わない明示的な退避設定もありますが、デスクトップアプリでは無効です。どちらも、モデルが自ら保護を解除できるという意味ではありません。

0.1.62 以降、write_file と edit_file は、リンクをたどって作業フォルダーの外へ出ることがありません。外を指すリンクを通した書き込みは拒否されます。別の場所に二つ目の名前を持つファイル（ハードリンク）は作業フォルダーの中で置き換えられ、もう一方の名前は古い内容のままです。新しいファイルが実行可能になることはなく、既存のファイルは権限を保ちます。ファイルは隣に新しいファイルとして書き出してから入れ替えるため、書き込みに失敗しても古いファイルには手が付きません。0.1.63 以降、ターンが作業フォルダーに最初の変更を加えるときにチェックポイントを保存し、「このターンを元に戻す」でファイルが復元され、そのターンは会話から取り除かれます。これは復旧のための安全網であり、境界ではありません。保存するのは、ファイルが 20,000 件以下で 5 GB 以下のフォルダーだけです（Python 環境、node_modules、ビルド出力、キャッシュは対象外で、保存せず、復元もしません）。秘密情報の形をしたファイルはコピーせず、対象は作業フォルダーだけで、Mac の外へ出たものは何も元に戻さず、保存できなかったときは「Not saved」と表示します。チェックポイントは 7 日間保持されます。

制限された計算環境と開発用の退避設定；ワークスペースと保護ディレクトリのルール；インストールしたサーバーのサンドボックス；通常コマンドのフォールバックとオフライン時の拒否；コマンドポリシー；リンクをたどらない書き込み；チェックポイント；このターンを元に戻す。

承認は具体的な操作に紐づけ、バックグラウンドにはすべての便宜的な許可を引き継がない

承認カードは、 call_id と操作の種類に紐づき、種類が異なる返答で別のカードを承認することはできません。Mac のウィンドウとスマートフォンに同時に表示されるカードは、最初の有効な回答を採用し、他の画面へ終了を通知します。回答がなければ 30 分間開いたままで、時間切れは拒否ではありません（0.1.61 以降。それ以前のバージョンでは 300 秒で期限切れ）。0.1.61 以降、カードはウィンドウ、Inbox、Island、iPhone のどこでも同じ見た目で、選択肢は「1 回だけ」（カードが最初に提示するのが「このタスクの間」の場合はそちら）、「この会話の間」、「Always」、そして Arslan に届く添え書き付きの「いいえ」です。カードが待機している間にチャットへ入力したメッセージは、そのメッセージを添え書きとして「いいえ」と答えたことになり、1 回のクリックで答えられるのは 1 枚のカードです。種類によっては選択肢が少なくなります。ルールに該当するコマンド、お金、画面の引き継ぎ、アプリ内の危険な手順は今回のみの回答になり、サンドボックスの外に出ること、サイト、ショートカット、MCP ツールには「Always」が提示されることはありません。バックグラウンドタスクのカードには、ウィンドウのカードと同じ選択肢があります。0.1.63 以降（S4a）、会話から開始したタスクは、その会話の許可（サンドボックスの外に出る許可を含む）を使います。確認できる相手がいない実行（スケジュール実行）は、これらの手順を一切取りません。以前の回答は有効にならず、その手順は直ちに拒否され、実行できなかったことは Inbox に一覧されます。このバージョンでは、スケジュール実行はターミナルコマンドを一切実行しません。モデルが MCP への接続、リモートマシンの登録、他の実行経路へのアクセスを提案した場合も、提案と実際の接続の有効化は分けて扱います。

外部への副作用についても、要求を送信しただけでは操作の完了にはなりません。タスクの復元時には、結果の分からない実行中の操作を不確定とし、プロセスを再起動したというだけで自動的に再実行しません。ここでの目標は、再試行と復旧の意味を明確にすることであり、任意の外部システムで取り消しができると約束することではありません。

0.1.55 以降、ウィンドウ、バックグラウンドタスク、iPhone のいずれから来た待機中のカードも、すべて一つのキューと Inbox に並び、そこから call_id で回答できます。返答はカード自身の種類から組み立てられるため、そのカードの承認か取り消ししかできず、より広い選択肢（この会話の間、Always）は、それを提示するカード上でしか選べません。iPhone と Island が返せるのはカードの最初の選択肢だけで、「Always」は返せません。Inbox は、カード自身が提示した選択肢であればどれでも返せます。Island は、フォルダー、アプリ、画面、MCP ツール、スケジュール、サイト、ショートカットのカードと、危険な種類に当たらないコマンドや作業フォルダーへの書き込みに回答できます。お金、送信、削除、アプリ内の危険な手順、画面の引き継ぎ、サンドボックスの外に出ること、ターミナルの ask ルールに該当する、または読み取れないコマンド、ネットワークも求めるコマンド、リモートホスト上のあらゆる操作、システムの変更、他のエージェントの設定、機能のインストール、AppleScript、サンドボックスで囲まずに実行されるコマンド、そして検査が把握していない種類のカードは承認できません。これらには「Open in Arslan」が表示され、Island のページだけでなくサーバーも、Island からの承認を拒否します。サンドボックスのラッパーなしで、承認された単純な AppleScript またはショートカットを実行するカードと、機能をインストールするカードは、Mac のウィンドウでのみ承認されます。そのようなカードへの iPhone からの承認は破棄されます。ウィンドウでは ⌘⏎ で許可、Esc で拒否します。単独の ⏎ でカードに回答することはありません。

Inbox と Island からの回答；カードの関連付け、期限切れ、複数端末からの回答；復元時の不確定な副作用；接続の提案と許可の入口。

Hands は、より小さなプロセスにシステム権限を集約する

Accessibility 権限を与える先は、 Arslan Hands.appであり、メインアプリではありません。署名付きの配布版は、保護された Unix socket、起動ごとに生成する token、peer の署名検査を通じて要求を受け付けます。ルールは helper 自体が実行し、下層の agent-desktop が独立してその権限を持つわけではありません。0.1.61 以降、アプリを見ることとアプリ内で操作することは、アプリごとに 1 枚のカードで、「このタスクの間」が最初の選択肢です。0.1.60 以降は、チャットの返信でも操作できます。0.1.62 までは一つのアプリ内で最大 5 手順まででしたが、0.1.63 以降はバックグラウンドタスクと同じく、その実行自体の上限の中で、複数のアプリにまたがって操作でき、「停止」で止められます（スケジュール実行は承認する人がいないため操作できません）。会話から開始したタスクはその会話での承認を引き継ぎます。ブラウザーでの操作、ショートカットや AppleScript の実行は、引き続きバックグラウンドの作業にだけ提供されます。アプリはその識別情報で判定されるため、.app を付けた名前、フルパス、大文字小文字の違いで指定しても、禁止アプリの一覧や未承認の状態をすり抜けることはできません。削除、送信、支払い、購入、送金、送信確定などの機微なボタンは、実際のラベルに基づき毎回確認します。パスワードフィールドには入力せず、パスワードマネージャーやシステムのセキュリティ画面などは、禁止アプリの一覧に含めます。

停止操作は停止ラッチを設定し、後続の操作はその検査を通る必要があります。アクティビティ記録には操作の手がかりを残し、入力テキストは長さだけを記録します。制約も公開しています。別の Space にあるウィンドウには、前面の借用のルールのもとでそこへ移動した場合にだけ到達でき、画面上の位置を指定したクリックやドラッグは提供していません。大きなウィンドウの読み取りには 10–20 秒かかる場合があります。Stop で中断した呼び出しには、対応する trace 行がないことがあり、監査記録はあらゆる中断について完全な証拠を保証するものではありません。

0.1.56 以降、Hands は各要求を最大 1 回だけ実行します。要求 ID に対する応答は 10 分間保持され、同じ ID が繰り返されたときはそこから応答します。バックエンドは、応答を受け取り損ねた場合、操作を再送するのではなく、その応答を取りに行きます。テキストを読み取れないフィールドへの追記は、内容を置き換えるのではなく拒否します。Return キーは、そのフィールドにフォーカスがあるときにだけ押します。送信したものの読み戻せなかった操作は、完了ではなく「sent, not confirmed」（送信済み・未確認）として報告します。Hands が動かすのは、Arslan の fork から固定したコミットでビルドした agent-desktop です。Cua Driver のエンジンは 0.1.63 で Hands から切り離され、helper はもうそれを探すことも起動することもありません（未使用のモジュールは helper のソースにまだ残っています）。0.1.60 以降、一つの作業について 1 枚のカードで最大 8 つのアプリを承認でき、会話から開始したバックグラウンドタスクはその会話での承認を引き継ぎます。また、設定 → Hands でアプリを恒久的に許可できます。削除、送信、支払い、購入、送信確定、送金、署名、投稿、公開、確定を表すラベル（複数の言語に対応）が付いたクリック、選択、メニューの最終項目と、それに対応するショートカットキー、Return で送信するアプリでの Return キー、画面の引き継ぎ、すべての AppleScript は、引き続き毎回確認します。

socket、token、peer、停止の検査；禁止アプリと操作分類；常に確認する語とキー；Hands の実測と制約；API と WebSocket の認証。

10 / iPhone と Mac Bridge依頼と確認はスマートフォンで、実行は Mac で

モバイル連携により、ペアリング済みの iPhone から Mac のタスクを確認し、作業を依頼し、承認に回答し、結果を読むことができます。実行するのは引き続き Mac 上の Arslan です。スマートフォンは別のクラウド Agent サービスではなく、Mac の HTTP インターフェースを直接公開したり呼び出したりすることもありません。本章は、Mac v0.1.63 の公開プロトコルとソースコードを基準にしています。Mac Bridge は以前のリリースに含まれており、公開リリースノートでは iPhone App は引き続き公開予定とされています。そのため、本書では App Store での公開や、本番環境における一連の経路の受け入れ確認が完了したとは述べません。0.1.60 以降の変更には、登場する箇所にバージョンを付けています。0.1.61 のリリースノートには、Mac 側が Arslan for iPhone 1.0 に対応すると書かれていますが、これは引き続き App Store での公開予定として説明されています。

CloudKit はメールボックスであり、デバイスの本人性はプロトコルで確認する

v1 は、同じ Apple ID の CloudKit 非公開データベースを使います。Mac は電源が入り、オンラインで、実行可能な状態である必要があります。そうでなければメッセージは処理待ちとなり、スマートフォンから電源の切れた Mac を動かすことはできません。LAN 内の Bonjour は今後の方向性であり、この版の代替直結経路ではありません。Mac helper は、アプリに伴って動く独立した ArslanBridge.appで、stdin 経由でローカル API token を受け取ってバックエンドに接続します。スマートフォンはこの token を持たず、モデルの API key も受け取りません。

エンベロープのクラウド側で見える索引フィールドには、送信元・送信先のデバイス、シーケンス番号、大まかな kind、通知フラグ、時刻があります。実際のメッセージ種別、本文、ファイル内容は、アプリ層の暗号文に含まれます。したがって、「エンドツーエンド暗号化」は、ペアリングされたデバイス間のメッセージ保護を指します。メタデータが存在しないことや、バックエンドのモデル呼び出しがユーザー設定の AI サービスを一切経由しないことを意味しません。

転送、エンベロープ、Mac 側の接続プロトコル；CloudKit ストレージの実装；Bridge の実行入口。

QR コードの読み取りは、ペアリングの始まりにすぎない

QR コードには、一回限りの pairing_id、Mac の署名用・鍵交換用の公開鍵、32 バイトのペアリング鍵、固定のコンテナ識別子、有効期限が含まれます。有効期間は最大 600 秒です。スマートフォンは、期限切れ、誤ったコンテナ、制約に合わない内容を拒否し、QR コード内の Mac 公開鍵を固定します。その後、自身の識別用・鍵交換用の鍵を生成し、暗号化されたペアリング要求を送ります。Mac は要求を検証した後もユーザーに提示し、Mac 上でのクリックによって承認または拒否を決めます。

同じ要求の再試行には同じ決定を返し、二度目の許可を生じさせないようにします。承認後はデバイスの識別情報を使って通信し、ペアリングコードは使用済みになります。Mac からスマートフォンの登録を取り消すこともできます。同じ iPhone が再びペアリングするときは以前の ID を伝え、Mac はそれらの古い項目を 2 件並存させずに削除します。スマートフォンを削除すると、Mac がそのスマートフォン宛てに iCloud に残していたメッセージも削除されます。起動時にも Mac は、ペアリングが解除されたスマートフォンを待ち続けている記録を消去します。設定 › 接続 › iPhone では、各スマートフォンは Mac がそこから認証済みのメッセージを初めて読み取るまで Connecting… と表示され、その後は Connected と最終接続時刻が表示されます。各デバイスの秘密鍵は、それぞれの Keychain に保存します。信頼の根拠は、一回限りのペアリング情報とユーザー確認の組み合わせであり、「同じ iCloud アカウントだから、どのメッセージも信頼できる」というものではありません。0.1.60 以降、iPhone 側でペアリングを解除すると、Mac は、設定 › 削除 を実行したときと同じようにそのスマートフォンの登録を消し、以後そこから届くものを無視して、一覧を更新します。

メッセージの内容、出所、コンテキストを同時に検証する

新しいメッセージごとに一時的な X25519 鍵で共有秘密を確立し、HKDF-SHA256 で 32 バイトの鍵を導出します。ChaCha20-Poly1305 で認証付き暗号化を行い、さらに Ed25519 で署名します。ヘッダーには長さで区切る UTF-8 フィールドを使い、言語間の JSON の並び順の違いが検証に影響しないようにします。ヘッダーフィールドは署名と AEAD 認証の両方に結び付けます。これは CryptoKit の暗号プリミティブを使ったアプリケーションプロトコルであり、Signal の Double Ratchet は実装していません。一時鍵を使うことだけをもって、あらゆる状況での前方秘匿性を主張することもできません。

受信時の順序は明確です。形式と受信者を確認し、署名を検証してから復号します。その後、平文とヘッダーの一致を確かめ、ファイルがある場合は添付も検証します。どの段階で失敗しても、業務上の処理が部分的に反映されてはいけません。ファイルの上限は 20 MiB で、暗号文のダイジェスト、認証タグ、平文のサイズとダイジェストがすべて一致して初めて、キャッシュやプレビューが可能になります。

ペアリング、暗号スイート、検証順序；Mac のエンコード・デコードと暗号プロトコル；一回限りのペアリングとユーザーの決定。

配信成功、操作完了、UI の最終状態は別のもの

Mac の状態スナップショットは、まだ実行中のタスクだけを含みます。通常の heartbeat 間隔は 60 秒で、スマートフォンは 90 秒間更新がなければオフラインと判断します。進捗は頻度を制限してまとめ、最終状態は速やかに送る必要があります。そのためクライアントは、メッセージの重複と順序の乱れを処理しながら、タスク一覧、承認カード、履歴を整合させなければなりません。「最後に受け取ったテキストで前を上書きする」だけでは状態を維持できません。

シーケンス番号、処理記録、ACK、削除；業務上の重複防止と結果の対応付け；スナップショットと heartbeat。

スマートフォンの承認は、Mac の許可と実行経路を再利用する

スマートフォンには具体的な action、target、risk を表示します。承認には端末内の生体認証が必要ですが、拒否には不要です。回答を送信した後も、Mac からの approval.resultを待ちます。Mac はカードがまだ有効かを確認し、元の confirm / cancel 操作へ対応付けます。スマートフォンからコマンドに「常に許可」を与えることはありません。音声入力は確認待ちのテキストを作れますが、承認の代わりにはなりません。

0.1.61 以降、承認カードはどこでも一つです（チャットウィンドウ、Inbox、Island、iPhone）。スマートフォンには、カードのタイトルから取ったカード自身の質問と、承認が何を対象とするかが表示されます。回答できるのは 1 回だけ、またはそれがカードの最初の選択肢である場合は「このタスクの間」（アプリ、サイト、ショートカットのカードでは、見出しの末尾が「(for this task)」になります）で、「この会話の間」と「Always」は選べません。Mac 上でのカードの待機時間は 30 分です（0.1.61 より前は 5 分）。時間切れは expired として報告され、Arslan はこれを拒否ではなく、誰も回答しなかったものとして扱います。新しい機能のインストールを求めるカードは、スマートフォンには届きません。Mac が先に回答した場合（ウィンドウ、Inbox、Island のいずれか）、スマートフォンの approval.result には answered_on_mac が含まれます。

ファイル、ライブ会話、スマートフォンからの進路変更

これらは追加のプロトコルタイプです（プロトコル文書の 5.7 節）。対応していない Mac は unknown_type を返し、Mac が新しいイベントを送るのは、hello の capabilities でそれを求めたスマートフォンだけです。

• スマートフォンからのファイル（0.1.61）。Arslan for iPhone から送られたファイルや写真（20 MiB まで、1 メッセージにつき最大 10 件）は、通常のアセットと同じく検査され、Mac の作業フォルダーの Inbox/iPhone に、日付ごとのフォルダーで保存されます。Arslan はメッセージと一緒にそれを読み、画像はモデルへ画像として渡せます。メッセージのファイルがすべて 120 秒以内に届かない場合、そのメッセージは実行されず、スマートフォンは再送できます。
• ライブ会話（0.1.61）。Mac は、最新の 20 件の会話と、実行中のタスクがある会話を連携させたままにするため、スマートフォンはそれらを一覧し、Arslan の作業中に回答、進捗、カードを追えます。スマートフォンから会話を削除できます（Remote 会話は削除されません）。1 通のメッセージに収まらないほど長い履歴は、最も古いメッセージから削られ、切り詰めたことが示されます。
• 書かれるそばから届く回答（0.1.63）。これを求めたスマートフォンには、返信がそこまでの全文を持つ partial イベントとして届きます。頻度は 1 秒に 1 回まで、100 KB までで、最終メッセージがそれらを置き換えます。Mac で入力した言葉は、Mac からのものとして印を付けてスマートフォンに表示され、スマートフォンを鳴らすことはありません。
• 進路変更（0.1.63）。返信の実行中に送ったメッセージは、終わるのを待たず、次のステップでその返信に届きます。iPhone、Mac のウィンドウ、押している間だけの音声入力のいずれでも同じです。返信が最終回答を書いている間は残りのステップがないため、メッセージはその直後に実行されます。0.1.63 の既知の制限：返信中に Mac のウィンドウで追加したメッセージは、iPhone には次の返信からしか表示されず、iPhone は自分のメッセージが追加された後も「Queued behind the current turn」と表示し続けます。
• スマートフォンへのファイル（0.1.63）。ファイル（スクリーンショット、グラフ、エクスポート、文書）を求めると、Arslan はそれを回答に添付します。Mac のウィンドウにはファイルカードが表示され、iPhone にはファイルそのものが届きます。上限は 20 MiB です。

承認マーカーと既存操作の対応付け；スマートフォンの削除・再ペアリング時の後片付け；状態、機能のフィールド、スマートフォンのファイルとライブ会話の受信箱；ライブの連携、スマートフォンからのファイル、部分的な返信；独立したプロトコル参照実装；0.1.54 の公開時点の提供状況。

11 / 検証とソフトウェアの配布動くソースから、インストールして更新できるアプリへ

デスクトップソフトウェアの配布単位は、アプリのパッケージです。ソース環境に存在する Python モジュール、システムツール、古いデータベースによって、リソースが不足したインストールパッケージでも正常に見えることがあります。Arslan では、ソース、プラットフォーム、凍結した成果物、新規ユーザー環境、配布という層に分けて検証します。本章は、v0.1.63 の手順と対応するリリースの証拠を記録しています。

CI は動作、プラットフォーム、依存関係の境界を確認する

macOS のテストは、pytest の終了コードだけで合格とはしません。パイプラインは JUnit を解析し、指定した 60 件のプラットフォームテストが実行され、スキップも失敗もゼロであることを要求します。依存関係の不足ですべてスキップされた場合も不合格です。Python と Rust は Hands の契約サンプルを共有し、Mac、iOS、独立した Python 参照実装は Bridge のベクトルを共有します。これにより、引数のマッピング、署名、宛先、改ざん、再送攻撃の境界を言語間で照合できます。

それでも結果には適用範囲があります。Swift の型チェックはマイクの許可を、Linux のユニットテストは macOS カーネルを、模擬メールボックスは本番の CloudKit を検証しません。テスト件数は全体の網羅率でもなく、重複するスイートを足して独立したシナリオ数にすることもできません。

四つの CI グループと実行必須の条件；言語間で共有する Hands の契約サンプル；Bridge の参照実装。

リリースは厳密に特定したソースコミットから始まる

Release workflow は、公開する SHA に対して成功した CI があるかを照会します。別のコミットの成功では代替できません。ビルドではロックファイルに従った依存関係を使用し、Python は uv が管理する独立したインタープリターを明示的に選び、runner が偶然 framework build を選ぶのを防ぎます。バックエンドは PyInstaller onedir で凍結し、フロントエンドの静的リソースと Swift/Rust helper を Tauri アプリと一緒に組み立てます。

署名と公証には別々の役割があります。内蔵 Mach-O を先に署名し、外側のアプリで包みます。配布には Developer ID、hardened runtime、タイムスタンプを使用します。DMG を Apple の公証に提出し、チケットを staple して Gatekeeper で検査します。ビルドスクリプトには、未署名の開発用パッケージや、一部の認証情報がない場合の警告経路も残されています。そのため、「ビルドできる」ことが、そのまま「一般配布の条件を満たした」ことにはなりません。正式公開では、実際に生成された成果物を確認する必要があります。

更新マニフェストには別の制約もあります。tag は Tauri のバージョンと一致する必要があり、updater の署名がある場合にだけ対応する manifest を生成します。手順は GitHub Draft Release を作成し、正式公開後に初めて、インストール済みアプリが次回以降の確認で更新を見つけられます。

正確な SHA の確認、バージョン検査、Draft Release；凍結、組み立て、署名、公証、フォールバック分岐；PyInstaller の依存関係とリソース。

新規インストールの検証ではアプリ本体を直接起動する

fresh_install_check.py は一時的な HOME と最小限の環境を使い、パッケージ内の実物の arslan-desktop を起動します。ソースの venv で代わりにサービスを起動するのではありません。検査項目は、ユーザーのデータベースや秘密ファイルがパッケージに混入していないこと、初回起動の初期化、token の生成とファイル権限、未認証リクエストの拒否、実際の WebSocket 101 ハンドシェイク、フロントエンド JavaScript の正常な取得です。HTTP 200 は SPA のフォールバックページにすぎない可能性があるため、リソースの検査ではステータスコードだけを見てはいけません。

同じスクリプトは、ネイティブ OCR、埋め込み helper、Bridge の自己診断、関連する署名も検査します。過去には凍結パッケージから動的に読み込む WebSocket 依存関係が抜け、ヘルス API は正常でもチャットの接続をアップグレードできないことがありました。これは、インポートの成功、サービスの稼働、コア機能がパッケージに含まれていることが、三つの異なる証拠であると示しています。

アプリ起動とパッケージ内の検証；動的な WebSocket 依存関係の明示的な収集。

更新のインストールはユーザーが開始し、ダウンロード内容を検証する

Tauri updater は公開された latest.json から更新を見つけ、アプリに組み込まれた公開鍵でアーカイブの署名を検証します。起動時に一度確認し、メニューからの手動確認も可能です。この版には定期確認の timer はありません。新しいバージョンがあると通知を表示し、ユーザーがインストールをクリックしてから、ダウンロード、署名検証、置換、再起動を行います。自動確認の失敗は一時的なオフラインの可能性がありますが、インストールの失敗はユーザーに明確に伝える必要があります。

初期の 0.1.0/0.1.1 では updater プラグインを登録しただけで、確認関数を明示的に呼んでいなかったため、新しい版を自動検出できませんでした。現在の実装では、確認、インストール可能な状態、ダウンロード失敗、再起動を明示的な流れとしてつないでいます。署名の設定があることと、その流れが実際に呼び出されることは別です。

確認、インストール、再起動の状態；更新 URL と公開鍵の設定。

0.1.63 の配布に関する証拠は何を対象にしているか

リリースコミットの GitHub Actions の記録によると、リリースのソースは main 上の 9bbb6ad6 です。main に対する CI は初回の試行で成功しました（run 40502155919）。その中で、macOS ジョブの指定した 60 件のプラットフォームテストはスキップゼロ、バックエンドは 9,469 件成功、124 件スキップでした。タグをプッシュしても独自の CI の実行は始まらなかったため、ゲートは同じコミットに対する main 上の実行を使いました。Release workflow（run 40505601007）は、ソース検証、ビルド、公開の各手順に成功し、DMG の公証は承認され、staple と Gatekeeper の確認も完了しました。出荷アプリの fresh-install の検査は 92 件成功、0 件失敗で、Hands による署名済みバックエンド接続の受け入れと Bridge の自己診断を含みます。

その前の 2 つのリリース。0.1.61 は main の fb6d7230 から作成されました（main 上の CI run 38489348597、タグの CI run 38498094635、リリース run 38498094628。プラットフォームテスト 54 件、バックエンドは 8,466 件成功、124 件スキップ、fresh install 89/0）。0.1.62 は release/0.1.62 の a4fca23b から作成されました（ブランチの CI run 39112567104、タグの CI run 39114206598、リリース run 39114206588。プラットフォームテスト 55 件、バックエンドは 8,747 件成功、125 件スキップ、fresh install 89/0）。いずれも初回の試行で成功し、公証、staple、Gatekeeper の確認を通過しました。

検証対象はそれぞれ異なり、記録もそれを区別しています。0.1.63 の公開ノートには、リリース候補で短い項目の一覧を手動で確認し、そのうち 2 件は合格しなかったと書かれています（1 件は依頼以上のことを変更した 3 回目の追加編集、もう 1 件は長いファイルの 1 行の変更をターミナルで行ったもの）。正確な 0.1.63 の DMG を手動でインストールして一連の操作を完走したとは書かれておらず、本書もそうは主張せず、出荷版のアプリで iPhone から Mac までの経路を一通り実行したとも主張しません。0.1.61 と 0.1.62 のノートには、本書が拠り所とする実際の Mac での手動検証の記録はありません。比較として、0.1.53 の Verification には、実際の Mac で Hands を使って Notes のメモを作成して読み戻し、承認を 36 秒待った操作が記録されています。ただしこれは最終 DMG ではなく、43751254 の build-only パッケージで行われたものです。自動のパッケージ検証、以前のビルドによる機能実測、正確な配布パッケージの手動受け入れ検証は、互いに代用せず、分けて説明すべきです。

12 / テストと検証タスクが正しくできたかをどう判断するか

タスクが終了したこと、ファイルを開けること、報告書の内容が正しいことは、三つの異なる判断です。Arslan は実行記録で起きたことを示し、成果物と契約の検査で確定できる部分を検証し、さらに実タスクの評価でモデルの働きを観察します。どの層で合格しても、他の層の代わりにはなりません。

まず「完了」を確認可能な証拠に分ける

タスクの受け入れでは、ルールによる検査、モデルによる評価、人による再確認を区別します。テキスト、JSON、ファイルの完全性、画像の寸法、実際の実行結果には決定的な検査を使えます。モデル評価は適した項目だけを判断し、実行していない検査を成功扱いに変えてはいけません。成果物を解析できることは構造が読める証拠であり、出典の読み取り記録はシステムが内容を取得した証拠です。どちらも、事実の正しさや視覚的な品質を自動的に証明するものではありません。

受け入れルールと成果物検査の範囲；0.1.53：未完了のタスクには Not done を明示。

テストを層に分け、それぞれ別の問いに答える

例えば、2026 年 9 月の信頼性改善では、外部モデル費用ゼロの固定された 30 項目の契約を用意しました。保存、キャンセル、成果物、バックアップ、権限などのコードを実際に実行しますが、provider には決定的な代替実装を使っています。これは技術的な契約の証拠であり、実モデルによる 30 件のエンドツーエンドタスクではありません。後の有料評価は別の層の証拠なので、同じ成功率として混ぜることはできません。

テスト自体も、実際に実行されたことを示す必要があります。v0.1.63 の macOS CI は JUnit レポートを解析し、指定した 60 件のプラットフォームテストが実行され、スキップがゼロであることを求めます。Hands の Python 側と Rust 側は契約サンプルを共有し、Bridge の両端はプロトコルのベクトルを共有します。重要な保護では、変異テストが一時的にルールを壊してテストが失敗することを確認し、実装の表面だけをなぞり、動作を制約できていないテストを見つけます。

技術的な契約とモデル品質の区別；プラットフォームテストの件数とスキップ防止条件；出典レビューの回帰検査と変異テスト。

リリース検証はソースと成果物に結び付ける

Fresh-install 検査は、隔離した新しい HOME でアプリを起動し、認証、WebSocket の実際の 101 ハンドシェイク、フロントエンド資源、OCR、helper を確認します。ヘルス API が 200 を返すことだけでは不十分です。初期のパッケージには、HTTP サービスが正常でもチャット接続を一切確立できないものがありました。

v0.1.63 のリリースはコミット 9bbb6ad6 に対応しています。main に対する CI は初回の試行で成功しました（run 40502155919。タグをプッシュしても独自の CI の実行は始まりませんでした）。リリース手順（run 40505601007）のソース検証、ビルド、Release は成功し、DMG の公証は承認されて staple され、Gatekeeper の確認も完了しました。出荷アプリの fresh-install 検査は 92 件成功、0 件失敗で、Hands の起動と Bridge の自己診断を含みます。（0.1.61 と 0.1.62 はそれぞれ 89 件中 89 件が成功しました：run 38498094628 と run 39114206588。0.1.53 では順序に依存する不安定なテストのため、CI の二回目の試行が必要でした。0.1.54 ではその原因、つまりテストが共有のデータベースセッションを漏らしていた問題を修正し、そうしたテストがあれば必ず失敗させるガードを追加しました。）

実機での操作の証拠は、別途明示されたビルドによるものです。Notes のテストでは、バックグラウンドタスクが Hands でメモを作成し、読み戻しました。最初の承認カードで 36 秒待っても続行できました。ファイル名変更のタスクには mv を使い、Finder ウィンドウは操作していません。これらのテストには、コミット 43751254 の以前の build-only パッケージを使いました。正式公開のコミットとの差は、バージョン番号と説明文書です。最終公開と同じ SHA ではありません。また、0.1.60 のリリースノートは、公開前に正確な最終 DMG を手動インストールして一連の操作を完走していないことも明示していました。インストール検査と、以前のビルドでの Notes 実測は分けて記載すべきです。

0.1.63 自身のリリース前テストは 2 つの基準を満たせず、ノートもそう書いています。「リスクのあるコマンドだけ確認」をオンにして、DeepSeek と Claude で 9 つのタスクをそれぞれ 3 回実行しました。「拒否された削除の後に別の方法を探す」タスクは、Claude で 3 回中 0 回の合格でした（0.1.62 では 3 回中 3 回）。作業フォルダーへ移動してから名前を指定して行う削除は、「このターンを元に戻す」でファイルを戻せるため、意図的にカードなしで実行されたからです。「1 つの文書への 3 回の追加編集」のタスクは、DeepSeek で 3 回中 1 回、Claude で 3 回中 0 回の合格でした。チェッカーはセクションが元の長さの 60% を下回るまで削られることを求めますが、タスクは短くするよう求めているだけだからです（チェッカーはそのまま維持されました）。出荷時の既定である、新しいコマンドの前に毎回確認する設定は、これらのラウンドでは実行されていません。この種の結果は弱い箇所を探すためのもので、順位付けではありません。

0.1.63 のリリースノート；リリースパイプライン；インストール検査；パッケージ化と署名。

実タスクのデータ：比較も弱点も残す

2026 年 10 月 3 日の 0.1.51 評価では、deepseek-v4-pro を使い、同じ回の Hermes と比較して、四種類のタスクをそれぞれ三回実行しました。「受け入れ合格」は checker score=3 を意味し、実行状態の done と同じではありません。費用と時間は、失敗を含む各種類三回の平均で、費用にはその回のオフピーク料金を使っています。時間は最初のモデル要求開始から最後の要求終了までの幅です。タスク全体のエンドツーエンド所要時間でも、モデルの純粋な推論時間でもありません。

この実験は改善点を探すためには適していますが、製品全体の順位付けには適していません。モデル、タスク、環境、承認方針が結果に影響します。この回には残高不足と再開もあり、費用ゼロの失敗要求四件を計時用の usage log から除外しましたが、元のログは保持しています。公開実験記録には、こうした実施条件も残されており、集計を読む際は併せて考慮すべきです。

バージョン間の比較も解釈を限定する必要があります。リマインダーの標本は 0.1.49 の 1/3 から 0.1.50 の 3/3 になり、この時期には再開経路とコンテキスト状態が改善されました。ただし、バージョン間には複数の変更があり、差のすべてを一つのプロンプトやモジュールに厳密に帰属させることはできません。

0.1.51 の実験方法と経過；四つのタスクの集計；再開経路の段階的な評価。

モデルによるレビューも評価する必要がある

0.1.41 の出典レビューの較正では、13 件の報告書に対して 14 件の指摘が出ました。正しいものは 1 件、判断が微妙なものは 2 件、誤りは 11 件で、事前登録した既知の誤り二件も見逃しました。そのため、この機能は標準で無効のままです。別のモデルを呼べば自動的に信頼できるファクトチェッカーになるわけではなく、形式が正しくアンカーが存在しても、指摘の妥当性は保証できません。

0.1.52 の経験学習の検証は、別の限界を示しています。AppleScript が拒否された後、経験が保存・想起され、次回は直接 EventKit を選びました。これは、経験が実行に影響することを示します。しかし、その後のスクリプト編集と検査で呼び出しが増え、高速化は測定できませんでした。経験自体が効率を上げるか判断するには、同じタスクを経験あり／なしで対にして繰り返す必要があります。当時の記録は、この公平な速度比較をまだ実施していないことを明示しています。

より強い品質の結論には、タスク、成果物、検査基準を事前に固定し、モデルと設定、呼び出し軌跡、実費、失敗原因を記録し、独立した人の注釈でモデルの採点を較正する必要があります。形式が不正な採点、未実行の検査、取得できない証拠は、それぞれの状態を維持すべきです。集計をよく見せるために合格扱いにしてはいけません。

出典レビューの公開較正結果；経験学習で確認できた項目と未実証の項目；より強い品質の結論に必要な評価条件。

13 / 技術的な方向性既存の機能から、より確実な成果の提供へ

Arslan には、実行、継続的なタスク、記憶という三つの基盤があります。次に検証すべきなのは、より複雑な場面でも正しい状態を保ち、信頼できる結果を出し、ユーザーが制御を維持できるかどうかです。下図では、実装済みの機能、引き続き検証が必要な部分、今後の選択肢を分けています。これは技術的な検討資料であり、日程付きのリリース公約ではありません。本章は v0.1.63 を反映しています。0.1.64 で予定されているものは、構築済みではなく予定として示します。

0.1.64 の予定（計画であり未構築。承認済みの 0.1.64 計画による）：まず、コマンド、Python、インストールしたツールを対象に、既定で拒否するサンドボックスを入れます。次に「リスクのあるコマンドだけ確認」が戻ります。その後に任意の「自動」モードが続きます。レビュー役のモデルが一部のカードに答えるもので、既定ではオフ、事前に決めた合格ラインを満たした場合にのみリリースされ、サンドボックスの外に出るもの、外部へ何かを送るもの、ネットワークに出るものは決して承認しません。モードは 5 つになり、会話ごとに入力欄の横で選びます。計画、毎回確認、自動編集、フルアクセス、自動です。設定に残るのは新しい会話の既定値だけです。定期タスクでは読み取り専用のコマンドが再び使えるようになります。それまでは新しいコマンドはすべて先に確認し、定期タスクはコマンドを実行しません。記憶された回答を一覧して元に戻すページと、許可するフォルダーの設定は検討中で、計画には入っていません。0.1.63 のノートは、既知の制限に対する 2 つの修正も挙げています。同じコマンドの中でフォルダーを移動してから行う削除が、誤って作業フォルダーの内側として扱われること、そして長いファイルの 1 行の変更が編集ツールではなくターミナルを通ることです。

実タスクでの成果

固定タスク群では、検索の網羅性、引用と結論の対応、ファイルを開けること、システム操作が実際に反映されたこと、失敗時に事実を正しく伝えて終了できることを確認すべきです。既存の比較では調査タスクの課題が明らかになっており、0.1.63 のリリース前の実行（DeepSeek と Claude で 9 つのタスクをそれぞれ 3 回）でも、自ら定めた 2 つの基準を満たせませんでした。拒否された削除の後に別の方法を探すこと（Claude で 3 回中 0 回。「リスクのあるコマンドだけ確認」では、作業フォルダー内の削除はカードなしで実行されるため）と、1 つの文書への 3 回の追加編集（DeepSeek で 3 回中 1 回、Claude で 3 回中 0 回）です。ツールを増やす前に、「見つからなかった」「最後まで読めなかった」「検証しなかった」「正しく成果を渡せなかった」がそれぞれどの段階で起きたかを特定するほうが、完了率の改善につながります。

再開とデバイス間の整合性

ネットワークの再試行、メッセージの重複、アプリの再起動、ユーザーによるキャンセルは、同時に起こり得ます。今後は、安定した業務 ID、古いメッセージによる最終状態の上書き防止、承認を取り消した後の動作、副作用が不明な場合の確認経路を中心に検証できます。クラッシュの注入やプロトコルの異常系を通じて、自動処理できる状況と、ユーザーの確認に戻る必要がある状況を明確にします。一部はすでに提供されています。0.1.63 以降、ターンが作業フォルダーを最初に変更する前にチェックポイントが保存され、「このターンを元に戻す」でファイルが復元され、そのターンが取り除かれます。これには制限があります。保存するのは、ファイルが 20,000 件以下で 5 GB 以下のフォルダーだけです（Python 環境、node_modules、ビルド出力、Python のキャッシュは対象外）。それ以外では「Not saved」と表示します。対象は作業フォルダーだけで、その外への影響は含みません。

測定可能な学習の効果

経験を記憶することは出発点にすぎません。同じタスクとモデルの条件で、経験あり／なしの完了率、呼び出し費用、所要時間、誤動作を繰り返し比較する必要があります。古くなった経験が修正されるか、外部の文章が経験を汚染し得るか、削除後も想起されることがないかも確認すべきです。

プラットフォームと拡張の負担

Tauri はクロスプラットフォームのホスト基盤を提供しますが、Seatbelt、Vision、Accessibility、Apple Events、CloudKit にはプラットフォーム固有の性質があります。他のデスクトップ OS に対応するには、これらの機能を置き換えて検証する必要があり、一度コンパイルできたことを製品機能の移植完了とはみなせません。外部ツールが増えれば、認証情報、権限、障害の種類も増えます。

以上は、現行の実装とテスト結果から整理した技術的な方向性です。具体的な優先順位や日程は、今後の正式なリリースノートに従います。

14 / 用語集用語を具体的な実装に結び付ける

用語は、異なる仕組みを区別するために使います。以下では簡潔な定義とともに、各概念が Arslan の実装でどう使われるかを示します。過去の仕組みは、その旨を明記しています。

AI とコンテキスト

ソフトウェア構造、状態、信頼性

OS、セキュリティ、配布

現在のシステムは、主にローカルの階層型モノリスと独立した helper で構成されています。SQLite とプロセス内の非同期スケジューリングは、個人向けデスクトップ製品のインストールと運用に適しています。関連する用語は、この規模の配置を前提に理解してください。

15 / よくある質問Arslan を使い、理解するうえで混同しやすいこと

16 / バージョン付録0.1.0 から 0.1.63 までの全変更記録

本付録は、v0.1.0–v0.1.63 の正式版形式の番号を持つ 64 タグと、0.1.40 のプレビュー系列、0.1.59 のベータ版を扱います。2026 年 10 月 27 日に確認した公開リリース記録では、GitHub 上で現在参照できるのは、正式 Release 63 件、プレリリース 6 件の計 69 件です。v0.1.39 にはバージョンタグがありますが、現在、対応する公開 Release はありません。

最新の正式版 v0.1.63 は、北京時間の 2026 年 10 月 27 日 22:26:31に公開されました。元の UTC 時刻は 10 月 27 日 14:26:31 です。以下の表は、すべて北京時間の日付に統一しています。明示した v0.1.39 のタグ日付を除き、日付は Release の published_at に基づいており、コミット日を公開日の代わりにはしていません。

0.1.40 のプレビュー系列：番号があっても公開済みとは限らない

公開プレリリースは beta.3、beta.5、beta.6 です。beta.1 と beta.2 は候補タグと関連記録が残り、beta.4 は単独公開せず、変更を beta.5 に取り込みました。六つの番号を、ユーザー向けに六回公開したプレリリースと解釈することはできません。

beta.2 は、公開状態を別途記録する必要性を示す例です。署名付きビルドとインストール検査は成功しましたが、そのタグの CI は失敗し、草稿は公開しないよう明示していました。その後 beta.3 で、「公開予定のコミットに成功した CI があること」という条件を導入しました。beta.5 は、未公開 beta.4 の変更を含み、先に beta.4 をインストールする必要がないことも明記しています。

変更をさかのぼって調べるには

正式リリースの項目は対応する Release に、v0.1.39 はバージョンタグにリンクしています。変更の要約は、正式なリリースノートと隣接タグ間のコミットを突き合わせ、計画文書にしかない機能を提供済みとして記載しません。実装を調べる場合は、その版のタグまたはリリースコミットに固定し、変わり続ける main で過去の版を説明しないようにしてください。

リポジトリーの一部のリリース草稿には、ビルド前の HOLD や草稿の注記が残っています。当時の公開手順を知る資料にはなりますが、現在公開されているかどうかを単独で判断する根拠にはすべきではありません。公開 Release の状態と最終検証記録を併せて確認する必要があります。ここでいう「現在、公開 Release なし」は今回確認できた状態を表し、リリース文書によれば、v0.1.39 と beta.2 にはかつて未公開の Release 草稿がありましたが、現在は Release の一覧にありません。

すべての公開 Releases；バージョンタグ；beta.3 の同一コミット CI 検証；未公開 beta.4 に関する beta.5 の説明；現在の正式版。

17 / バージョンの基準とソースへの入口文書の結論から根拠をたどれるようにする

本書は固定したバージョンの実装を説明し、公開リリースの記録、Git タグと履歴、リリースコミットのソース、アーキテクチャ上の判断、公開された受け入れ検証資料を相互に確認しています。初期の設計は変遷を説明するために用い、後のコードで置き換えられた動作は過去のものと明記します。作者が独立して AI 支援による開発を行っているという説明は、作者本人によるものです。

疑問に対応する実装を探す

1. プロジェクトの変遷：公開 Release；追跡できる最初のコミット；One Arslan；統一ループ。
2. プログラムの起動：デスクトップのライフサイクル；ローカルサービスの入口；Agent の入口；ツールループ。
3. モデルの接続：アダプター；ツールの実行軌跡；実行予算。
4. タスクの保存と再開：タスクの契約；状態、永続化、試行の隔離とチェックポイント；受け入れ検証；バックアップ復元後の承認の無効化とタスクの隔離。
5. 記憶の使用と削除：個人コンテキスト；資料の検索；経験；記憶の永続化；バージョン管理された移行。
6. 機能の拡張：組み込み実行器；プラグインのマニフェスト；MCP；読み取り専用ワーカー。
7. 権限の適用主体：ターミナルのポリシー；コマンドサンドボックス；実行とフォールバック；Hands helper。
8. スマートフォンの接続：Bridge プロトコル；Bridge のライフサイクル；イベントと承認のマッピング。
9. 評価とリリース：0.1.51 の実タスク比較；0.1.52 の受け入れ検証；インストールの受け入れ検証；リリースワークフロー。
10. オープンソースの出典とフィードバック：ライセンス；第三者の権利帰属；セキュリティ報告の方針；プロジェクトの Issues。

本書は、特定のバージョンと、その確認可能な範囲を説明するものです。後続のバージョンについては、対応する Release とソースの両方を参照してください。アーキテクチャの方向性、設計意図、テスト範囲、正式な提供内容を分けて記載し、それぞれの結論がどこまで適用できるかを判断しやすくしています。