ARNO

ARNO — エージェントリポジトリのナビゲーションと操作

エージェントのための IDE

ARNO は、IDE があなたに提供する機能を、MCP 経由でコーディングエージェントに提供します。シンボル単位で読み込み、既知のリビジョンに対して編集し、編集とあわせてコンパイラーの診断結果を受け取り、リポジトリ独自のコマンドで検証し、変更内容を確認してチェックポイントに戻せます。それぞれの手順はツール呼び出し1回で完了し、シェルを使う必要はありません。

ARNO がリポジトリ内を把握する方法はシンボル認識による読み取りであり、その目的はトランザクションです。シェルのほうが適している場面では、シェルを使ってください。ARNO が答えるべき問いは、エージェントが ARNO を使わない場合よりも、許容できるコストでより多くの作業をこなせるかどうかです（docs/benchmark.md）。

トークンは半分、修正した課題は増加。 cobra（Go）、ky（TypeScript）、requests（Python）、ripgrep（Rust）の実際にクローズされた12件の課題を Claude Code で検証し、各上流修正に付属する非公開テストで評価しました。

Claude Code の使用ツール	修正した課題	タスクあたりのトークン数	タスクあたりの時間
組み込みツール	12件中10件	1.38M	215s
組み込みツールの代わりに ARNO	12件中12件	0.68M（−51%）	163s（−24%）

単にツール一覧が短くなるだけではありません。Bash、Read、Edit、Write に絞ったシェルと比べても、ARNO は2回の別々の実行で、トークン数を18～25％削減し、ターン数も減らしました。Sonnet 5、各タスク1回、4言語での結果です。 結果と注意事項 · セットアップ方法

ステータス： 0.0.14 をリリースしました。Jade の名称を使わない初のリリースです。0.0.11 以前は Jade で、初期段階ながら利用可能で、フィードバックを求めています。試してみますか？ テスター向けガイドから始めてください。

curl -fsSL https://raw.githubusercontent.com/julianbei/arno/main/install.sh | sh

macOS と Linux 向けです。Windows はサポートしていません（理由と賛成票を投じる場所はこちら）。 更新するには、もう一度実行してください。その他のインストール方法。

---

目次

• ARNO を試す：テスター向けガイド
• ARNO が生まれた理由
• インストール
• MCP クライアントの設定
• コンテナで使用する
• ツール
• リポジトリのコマンド
• 言語サポート
• 設計原則
• シェルが適している場合
• ARNO がまだ対応していないこと
• 安定性とバージョン管理
• テレメトリー
• 問題の報告
• 開発

---

ARNO を試す：テスター向けガイド

テストにご協力いただき、ありがとうございます。セットアップには30分ほどかかります。役立つのは、普段の作業で1～2週間ほど有効にして使い、その結果を知らせていただくことです。使うのをやめた場合も、ぜひお聞かせください。

1. ARNO と言語サーバーをインストールする

macOS および Linux：

curl -fsSL https://raw.githubusercontent.com/julianbei/arno/main/install.sh | sh

Windows はサポートされていません。申し訳ありません！対応を希望する場合は、👍 issue #2 を押すか、なぜ必要なのかをそこでお知らせください。（WSL 2 は Linux を実行するため、Linux ビルドが動作する可能性はありますが、テストもバグ報告の受付も行っていません。）

スクリプトは OS と CPU に合ったビルドを選び、リリースのチェックサムと照合して、/usr/local/bin にインストールします。そこに書き込めない場合は ~/.local/bin にインストールします。sudo も Go ツールチェーンも不要です。そのディレクトリが PATH に含まれていない場合は、シェルのプロファイルに追加するか確認し、MCP クライアントの設定で command として使う絶対パスを表示します。初回インストール時には、続いて arno-mcp install を起動します。これは、選択した言語サーバーをインストールするメニューです。Enter キーでスキップでき、いつでも再実行できます。更新するには、同じコマンドをもう一度実行してください。新しいリリースがあると ARNO が通知します（更新チェックを参照）。 （Go を使いたい場合は、go install github.com/julianbei/arno/cmd/arno-mcp@latest も使えます。）ARNO は、ほかに何もインストールしなくても、あらゆる言語の構造を読み取れます。正確な参照情報、ファイルをまたいだ名前変更、編集時の型エラー検出には、その言語のサーバーが必要です。arno-mcp install でインストールするか、手動でインストールしてください。

言語	インストール	備考
Go	go install golang.org/x/tools/gopls@latest	初回の応答は約 1.6 秒です。
Java	brew install jdtls（JDK 21 以降が必要）、または使用しているディストリビューションのパッケージ	インデックス作成中は、初回の応答に約 8.5 秒かかります。check は mvn または gradle を実行します。Gradle ラッパーしかない場合は、エージェントに一度 ./gradlew build を宣言させてください（ステップ 4）。
Scala	cs install metals（coursier）	sbt ビルドを metals がインポートできるように、ARNO_METALS_IMPORT=1 を設定してください（.bloop/ と .metals/ が作成されます）。初回の応答は約 22 秒です。
Kotlin	—	文法解析器もサーバーもまだありません。テキスト検索のみ利用できます。必要な場合はお知らせください。

サーバーがなくてもエラーにはなりません。ARNO は、どの回答が概算になるかを通知します。

2. エージェントを実際のリポジトリに接続する

Claude Code の場合は、作業するリポジトリのルートにある .mcp.json に次の内容を記述してください（ほかのホストについてはCodex CLI、goose、OpenCodeを参照してください）。

{
  "mcpServers": {
    "arno": {
      "type": "stdio",
      "command": "arno-mcp",
      "args": ["--root", "/absolute/path/to/the/repo", "--tools", "core"],
      "alwaysLoad": true
    }
  }
}

これにより、Claude Code 自身のツールも引き続き使えます。最も明確な違いを確認するには、いくつかのセッションで、それらの代わりに ARNO を使ってください。同じ設定で claude --tools "" を実行します（理由とトレードオフ）。ARNO のインストールまたはアップグレード後は、クライアントを再起動または再接続してください（/mcp）。

3. 起動したことを確認する

エージェントに 「arno.capabilities を呼び出して」 と依頼してください。各言語について、server … (not started) または no server (… not installed) と表示され、さらに ARNO が検出したビルドおよびテストコマンド（mvn、gradle、sbt、go test）も表示されます。インストールしたサーバーが未インストールと表示される場合は、バグとして報告してください。

4. 試してみること

普段どおりに作業してください。最初のセッションで試す項目が必要な場合は、次のチェックリストを参考にしてください。

• コードを見つけて追跡する：「X はどこで宣言され、どこから呼び出されていますか？」— find、references。
• ファイルをまたいで名前を変更する： 複数のファイルで使われているメソッドまたはクラス — rename（gopls、jdtls、または metals の実行中は正確です）。
• 複数箇所を一度に変更する：「シグネチャを変更して呼び出し元も更新し、ビルドを確認してください」— check と組み合わせた apply。
• 必要なテストを実行する： ファイル名またはテスト名を指定した run_tests、または check: "impact" を指定した apply。
• 繰り返し使うコマンド： エージェントに、よく実行するコマンド（./gradlew :core:test、sbt "testOnly *ParserSpec" など）を declare_command で登録させます。以降のセッションでは .arno/commands.json から再利用できます。
• 元に戻す： リスクのある作業の前に checkpoint を実行し、問題が起きた場合は revert します。

5. 使ってみた感想をお聞かせください

タイミング	こちらにご報告ください
1、2 週間後、または ARNO をオフにするとき	フィードバック
ARNO のツールがあるのにエージェントがシェルを使った	使いづらかった点
ツールが誤った回答を返した、または失敗した	バグ
ARNO に追加してほしい機能がある	機能の要望

テンプレートでは、arno.capabilities の出力と、任意で arno.telemetry の出力を求めます。どちらにもソースコードは含まれません。テレメトリは ローカルのみで記録され、引数や応答テキストは記録しないため、非公開リポジトリから貼り付けても安全です。

JVM で既知の課題： Java または Scala ファイルにはフォーマッターが実行されません。 大規模な Gradle ビルドでは、jdtls の初回の回答が 8.5 秒より大幅に遅くなることがあります。Kotlin はまだサポートされていません。

---

ARNO が存在する理由

grep、sed、cat に頼るエージェントは、あなたが制御できるツール群の外で動作しています。 リビジョン追跡も、ガードレールも、テレメトリもなく、何をしたのか、なぜその方法を選んだのかを知る手段もありません。シェルへのフォールバックはすべて、可視性に生じる穴です。

モデルにシェルを使わないよう伝えても解決できません。シェルを使うのは、そちらのほうが 低コスト だからです。トークンが少なく、往復が少なく、柔軟性も高いからです。したがって、根本的な解決策は、構造化されたツールをより低コストな選択肢にし、それが成功したかを測定することです。

それがこの取り組みのすべてであり、検証可能です。このリポジトリ独自のベンチマークでは、ARNO は現実的なエンジニアリング上の質問 7 件に、同等のシェルコマンドの 0.85 倍 のトークン数で回答します。応答を JSON からプレーンテキストにする前は 5.63 倍 でした。変更点とその理由については、docs/response-style.md をご覧ください。

同じくらい重要なのが、対照的な測定結果です。無関係なリポジトリで質問したところ、結果は 1.36 倍 となり、シェルよりも悪くなりました。あいまいなシンボル名のため、追加の曖昧さ解消の呼び出しが必要になったからです。自分のリポジトリでの 7 つのシナリオと、別のリポジトリでの 1 つのシナリオでは結果が異なります。どちらも正直な結果ですが、外部での利用を予測するのは後者です。外部の 4 つのリポジトリで行った 0.0.4 のパイロットでは、より大規模に検証しました。Claude Code の組み込みツールの代わりに ARNO を使い、実際の問題 12 件中 12 件を解決し、トークン数を 51% 削減しました。また、ツールを 4 つに絞ったシェルと比べても 18～25% 少なくなりました （docs/benchmark-results.md）。ARNO はまだ完成していません。

ARNO 自身の開発ログ（docs/feedback.md）には、作者が bash を使おうとしたすべての場面と、その理由が記録されています。そこから見つかった傾向は明白でした。最後まで残っていたフォールバックは、ツールがリリースされたときではなく、開発ログで 名指しされてから 2 つのタスク以内に、それぞれ解消されていました。

---

インストール

インストールスクリプトを使う

curl -fsSL https://raw.githubusercontent.com/julianbei/arno/main/install.sh | sh

お使いの OS と CPU に対応する最新のリリースバイナリをダウンロードし、checksums.txt と照合して検証したうえで、sudo を使わずに /usr/local/bin または ~/.local/bin にインストールします。更新するには、再度実行してください。PATH 上に arno-mcp がすでにある場合は、その場所で置き換えられ、最新の状態であれば何もダウンロードされません。ディレクトリが PATH に含まれていない場合は、シェルのプロファイルへの追加を提案します（ARNO_ADD_TO_PATH=1 を設定すると、確認なしで追加します）。また、MCP クライアントの設定で使う絶対パスを表示します。ARNO_VERSION でリリースタグを固定し、ARNO_INSTALL_DIR でディレクトリを指定できます。必要なら、まず内容を確認してください： install.sh。

Windows はサポートされていません。詳しくは issue #2 をご覧ください。対応を希望する場合は、👍 を付けてください。

言語サーバー：arno-mcp install

arno-mcp install                           # menu: pick what to install
arno-mcp install --list                    # what is installed, and how the rest would be
arno-mcp install --servers go,java,scala   # install these, no questions
arno-mcp install --all                     # every missing server this machine can install

メニューには、ARNO が使用できる各言語サーバー、インストール済みかどうか、実行される正確なコマンドが表示されます。たとえば、gopls には go install、jdtls には brew install jdtls、metals には cs install metals、TypeScript と Pyright には npm install -g、rust-analyzer には rustup component add rust-analyzer、ruby-lsp には gem install ruby-lsp が使われます。実行前には確認が求められます。マシンにインストーラーがないサーバーには、手動でインストールする手順が表示されます。インストールスクリプトでは、最初のインストール後にメニューが開きます。ARNO_SKIP_SETUP=1 を指定するとスキップできます。

エージェントやスクリプトの場合 — メニューに答えるターミナルがないため、同じ手順が確認なしで実行されます。

# install ARNO and chosen servers in one go
curl -fsSL https://raw.githubusercontent.com/julianbei/arno/main/install.sh | ARNO_SERVERS=go,java sh

arno-mcp install --list --json                   # state of every server, as JSON
arno-mcp install --servers java,scala --dry-run  # the commands, not run
arno-mcp install --servers java,scala            # run them

--list --json を指定すると、各サーバーの key、installed かどうかとその場所、このマシンでインストールする場合の command、該当するコマンドがない場合の manual 手順が表示されます。arno.capabilities では、サーバーが見つからない場合、その行の末尾にインストールするコマンドが表示されます。インストールは意図的に MCP ツールではありません。グローバルパッケージのインストールは、承認を行うエージェントのシェル経由で実行されます。

その他のインストール方法

上記のインストールスクリプトが最も簡単です。以下の方法も利用できます。

Go から

go install github.com/julianbei/arno/cmd/arno-mcp@latest    # newest
go install github.com/julianbei/arno/cmd/[email protected]   # pinned to a tag

$GOBIN にインストールされます。未設定の場合は $(go env GOPATH)/bin にインストールされます。通常は ~/go/bin ですが、デフォルトでは PATH に含まれていません。含まれていない場合は追加し、次のコマンドで確認してください。

export PATH="$PATH:$(go env GOPATH)/bin"
arno-mcp --version

PATH を変更したくない場合は、以下に示す arno-mcp だけの指定ではなく、MCP クライアントの設定で絶対パスを使用してください。

リリースバイナリから

linux および darwin の amd64 と arm64 向けのビルド済みバイナリが、各 GitHub リリースに添付されています。同じ場所に checksums.txt もあります。各バイナリはそれぞれのプラットフォーム上でネイティブにビルドされています。ARNO は cgo 経由で tree-sitter にリンクするため、linux のビルドには比較的新しい glibc が必要です。古いディストリビューションを使う場合は、ソースからビルドするか、musl に対して静的リンクされたコンテナイメージを使用してください。

VERSION=$(curl -fsSL https://api.github.com/repos/julianbei/arno/releases/latest | sed -n 's/.*"tag_name": *"\([^"]*\)".*/\1/p' | head -n 1)
OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
curl -fsSL "https://github.com/julianbei/arno/releases/download/${VERSION}/arno-mcp_${VERSION}_${OS}_${ARCH}.tar.gz" \
  | tar xz
sudo mv "arno-mcp_${VERSION}_${OS}_${ARCH}" /usr/local/bin/arno-mcp

Claude Desktop 用の MCP バンドルから

0.0.11 以降、各 GitHub リリースには arno-mcp_<version>.mcpb も含まれています。これは、Intel と ARM 向けの macOS および Linux バイナリをまとめたバンドルです。Claude Desktop で開き、ARNO が作業するリポジトリを選ぶと、コアツールを使って実行されます。ターミナルも Docker も必要ありません。言語サーバーは arno-mcp install からインストールするか、tree-sitter だけで実行できます。

ソースから

git clone https://github.com/julianbei/arno.git
cd arno
make binary          # bin/arno-mcp, version stamped from git describe
make install         # or straight onto your PATH

オプション：gopls

references と rename は、正確にコンパイラーで解決された情報を得るために gopls を使用します。なくてもこれらの機能は動作しますが、references はレスポンス内でその旨を示したうえでテキスト上の近似結果に切り替わり、rename は推測による変更を避けるため実行されません。

arno-mcp install --servers go      # or: go install golang.org/x/tools/gopls@latest

以下のすべての言語も同様です。arno-mcp install でインストール済みのサーバーを確認し、残りをインストールできます（言語サーバー）。

---

MCP クライアントの設定

ARNO は stdio MCP サーバーです。クライアントからバイナリを指定してください。

{
  "mcpServers": {
    "arno": {
      "type": "stdio",
      "command": "arno-mcp",
      "alwaysLoad": true,
      "env": {
        "ARNO_WORKSPACE_ROOT": "/absolute/path/to/the/repo/arno/should/work/on"
      }
    }
  }
}

ARNO_WORKSPACE_ROOT は、ARNO が調査および編集するリポジトリを指定します。ARNO のチェックアウト先である必要はありません。別の場所を指定することが、この設定の目的です。--root /path/to/repo フラグは環境変数より優先されます。ARNO は起動時に、使用した3つの設定元（フラグ、環境変数、作業ディレクトリ）のどれかを表示するため、エージェントが誤ったリポジトリを気づかれないまま操作することはありません。

ARNO は、git 管理されていないディレクトリや、まだコミットがないリポジトリでも動作します。どちらの場合も、利用できない機能（changes、diff、history、checkpoint は git が必要です）が示され、それ以外の機能は引き続き利用できます。

組み込みツールをARNOに置き換える

ARNOがトークンを節約できるのは、エージェント自身のツールの代わりに使う場合であり、ツールの隣に追加する場合ではありません。各ターンでツールリスト全体が再送信されます。Claude Codeでは、そのうち組み込みツールが約38kトークンを占めます。ARNOのパイロットベンチマーク（cobra、ky、requests、ripgrepの実際の課題12件を各1回実行）では、次の結果になりました。

ツール	解決したタスク	1回あたりのトークン数	1回あたりの時間
Claude Codeの組み込みツール	12件中10件	1.38M	215s
Bash、Read、Edit、Writeに絞った組み込みツール	12件中10件	0.90M	213s
ARNOのみ、coreプロファイル	12件中12件	0.68M	163s
両方、すべての組み込みツールとARNO	12件中11件	1.50M	191s

組み込みツールのリストを絞るだけでも、節約効果の大部分が得られます。そのうえでARNOを使うと、絞り込んだシェル構成と比べてトークン数が25％、時間が24％減り、どちらのシェル構成でも失敗した2つのタスクを解決しました。ARNOとすべての組み込みツールの両方を与えた場合、エージェントは5回に4回の呼び出しでBashを使い、両方のリストのコストが発生しました。組み込みツールの代わりにARNOを実行するには、次のようにします。

claude --tools "" --mcp-config arno.json

arno.jsonでcoreプロファイルを指定します。このプロファイルには、リポジトリで宣言されている読み取り、編集、検証、コマンド実行用の12個のツールが含まれ、その他のツールも引き続き呼び出せます。

{
  "mcpServers": {
    "arno": {
      "type": "stdio",
      "command": "arno-mcp",
      "args": ["--root", "/absolute/path/to/the/repo", "--tools", "core"],
      "alwaysLoad": true
    }
  }
}

このトレードオフは現実のものです。Bashがなければ、エージェントは任意のコマンドを実行できません。run_tests、check、およびdeclare_commandで宣言されたリポジトリコマンドで、ビルド、テスト、繰り返し実行可能なスクリプトに対応できます。宣言は.arno/commands.jsonに保存されるため、以降のセッションで再利用できます。Git操作、ネットワークアクセス、またはその場限りのスクリプトが必要なタスクでは、シェルが必要です。上記の数値は各タスクを1回実行した結果です。結果、パイロットでの修正後に再実行した結果、注意事項についてはdocs/benchmark-results.mdを参照してください。

その他のホスト

ARNOのツールだけを使用し、実際のセッションで宣言を見つけ、その隣に挿入してcheckを実行する方法で検証済みです。

Codex CLI（0.154）の場合、~/.codex/config.tomlに次のように記述します。

[mcp_servers.arno]
command = "arno-mcp"
args = ["--root", "/absolute/path/to/the/repo", "--tools", "core"]

CodexはMCPツールを呼び出すたびに確認を求めます。approval_policy = "never"ではツール呼び出しが拒否されます。codex exec --approve-for-meを実行するか、ARNOのツールを対話的に承認してください。

goose（1.50）の場合、1回だけ実行するには次のようにします。

goose run --with-extension "arno:arno-mcp --root /absolute/path/to/the/repo --tools core" -t "…"

または、goose configure → 拡張機能の追加 → コマンドライン拡張機能で、コマンドにarno-mcp --root /absolute/path/to/the/repo --tools coreを指定すると、永続的に設定できます。gooseのclaude-codeプロバイダーで検証済みです。

OpenCode（1.18）の場合、リポジトリのルートにあるopencode.json、または~/.config/opencode/opencode.jsonに次のように記述します。

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "arno": {
      "type": "local",
      "command": ["arno-mcp", "--root", "/absolute/path/to/the/repo", "--tools", "core"],
      "enabled": true
    }
  }
}

OpenCodeはサーバー名をツール名の先頭に付けるため、ツールはarno_arno_findなどの名前で表示されます。github-copilotプロバイダー（Claude Sonnet 5）で検証済みです。

ClineとGemini CLIは、まだ検証されていません。

一度は戸惑う3つのこと

"alwaysLoad": true を設定しないと、Claude Code は ARNO をまったく使わないことがあります。 Claude Code はデフォルトで、MCP ツールをツール検索の背後に隠します。エージェントにはツール名だけが表示され、定義は見えないため、ツールを呼び出す前に検索する必要があります。すぐに使える独自のシェルツールやファイルツールがあると、検索は行われません。ARNO のベンチマークでは、ARNO とシェルの両方を与えられたエージェントは、3回の実行すべてで ARNO を呼び出しませんでした。同じ設定で alwaysLoad を有効にすると、直接 ARNO を呼び出しました。他のホストにも同等の設定がある場合があります。ARNO のツールが実際に呼び出されていることを確認してください。

1つのサーバーは1つのリポジトリを担当しますが、そのリポジトリの任意のワークツリーで作業できます。 ARNO は起動したディレクトリに固定されており、シェルで cd してもその場所には反映されません。MCP には呼び出しごとの作業ディレクトリがないためです。同じリポジトリの別の git worktree で作業するセッションは、一度だけ arno.workspace path=<worktree> を指定します。そのサブエージェントにも引き継がれます。別のワークツリーで作業するサブエージェントは、独自の呼び出しで root=<path> を渡します。セッション群で使う場合は ARNO_REQUIRE_WORKSPACE=1 を設定してください。どのワークツリーで作業するかを一度も指定していないセッションからの書き込みは、共有チェックアウトに書き込まれる代わりに拒否されます。docs/worktrees.md を参照してください。

MCP ツールカタログは接続時に固定されます。 新しく追加されたツールは、クライアントを再接続するまで表示されません。セッション中に ARNO をアップグレードし、ツールが見当たらない場合は、調査を始める前に再接続してください。

go run ./cmd/arno-mcp ではなく、バイナリを使ってください。 go run の設定では、プロセスを起動するたびに再コンパイルが行われます。ここで測定したところ、ビルドキャッシュが温まっている状態でも、最初のハンドシェイクまで284～584msかかりました。バイナリでは14msです。キャッシュが冷えていると、数秒かかります。また、ソースが変わるたびにサーバーも気付かれないまま変わります。ARNO 自体を開発している間は便利ですが、それ以外では戸惑いのもとになります。このリポジトリ独自の .mcp.json では、そのために意図的に go run を引き続き使っています。

環境変数

変数	効果
ARNO_WORKSPACE_ROOT	操作対象のリポジトリです。--root で上書きされます。
ARNO_JSON=1	プレーンテキストの代わりに、機械可読な JSON を出力します。
ARNO_TELEMETRY=0	ローカルでの使用状況の記録を完全に無効にします。
ARNO_STATE_DIR	テレメトリログをワークスペースの外部に保存します。ワークスペースごとにサブディレクトリを作成します。
ARNO_METALS_IMPORT=1	metals が sbt ビルドをインポートし、Scala の編集で診断情報を得られるようにします。sbt を実行し、.bloop/ と .metals/ を作成します。
ARNO_UPDATE_CHECK=0	新しいリリースを毎日確認する機能を無効にします（更新チェック）。
ARNO_REQUIRE_WORKSPACE=1	複数のワークツリーがあるリポジトリで、セッションが arno.workspace（または呼び出し時の root=）でワークツリーを指定するまで、書き込みを拒否します。チェックアウトを共有するセッション群向けです。docs/worktrees.md を参照してください。
ARNO_MAX_WORKSPACES	1つのサーバーが同時に開いておく git ワークツリーの数です（デフォルトは3。最も長く使われていないものから退避されます）。docs/worktrees.md を参照してください。

インストールスクリプトでは、次の変数も読み取ります。

変数	効果
ARNO_VERSION	インストールするリリースです。例：v0.0.12。デフォルトは最新バージョンです。
ARNO_INSTALL_DIR	arno-mcp の配置先です。デフォルトは、すでに PATH 上にある arno-mcp のディレクトリ、書き込み可能であれば /usr/local/bin、それ以外の場合は ~/.local/bin です。
ARNO_SERVERS	メニューを表示せずに後からインストールする言語サーバーです。go,java,scala,typescript,python,rust,ruby、または all を指定します。
ARNO_SKIP_SETUP=1	言語サーバーのセットアップ手順をスキップします。
ARNO_ADD_TO_PATH=1	確認せずに、インストールディレクトリをシェルプロファイルに追加します。
ARNO_RELEASE_URL	ミラー用のリリースのベース URL です。

---

コンテナで使用する

ARNO はサービスではなく子プロセスなので、実用的な方法は ARNO を起動するのではなく、バイナリを独自のイメージにコピーすることです。

FROM ghcr.io/julianbei/arno-mcp:latest AS arno

FROM your-project-base
COPY --from=arno /arno-mcp /usr/local/bin/arno-mcp
ENV ARNO_WORKSPACE_ROOT=/workspace

または、同梱の Dockerfile から自分でビルドできます。

公開されているイメージは distroless/static なので、git、gopls、言語ツールチェーンは含まれていません。ARNO は実行時にそれぞれの有無を検出し、失敗するのではなく明示的なメッセージを表示して機能を縮退させるため、この構成でも動作します。テキストベースの references フォールバックを利用でき、changes／diff／history／checkpoint は無効になります。すべての機能を使いたい場合は、独自のイメージに git と gopls をインストールしてください。ARNO が検出します。

---

ツール

4 つのグループに分かれた 31 個のツールがあります。すべての応答はプレーンテキストで、まず決め手となる行を示し、その後に補足情報を続けます。生の出力は要求された場合にのみ返します。

MCP では各ツールが arno.<name> として登録されます。たとえば arno.outline、arno.replace_symbol などです。以下の表では読みやすさのため、名前のみを記載しています。ほとんどの MCP クライアントでは、すでに接頭辞付きの名前が表示されます。ドットが別の表記に置き換えられることもあります（Claude Code では mcp__arno__arno_find と表示されます）。通信上、ARNO は arno.find と arno_find の両方を受け付けます。

調査

ツール	機能
capabilities	このワークスペースで ARNO が実行できることを、言語ごとに表示します。文法解析またはテキストスキャン、言語サーバーの状態、フォーマッター、git、検証コマンド、宣言済みコマンドを確認できます。最初に呼び出してください。
outline	ファイルの構造を、本文を読み込まずに宣言の種類ごとにまとめて表示します。
read_range	行をそのまま、またはファイル全体を読み込みます。lines: "280-400" で範囲を指定します。ranges を使うと、1 回の呼び出しで複数のファイルや範囲を読み込めます。終了行がファイルの末尾を超える場合は、末尾まで読み込みます。dep:<name>/<path> を指定すると、ロックされたバージョンの依存関係のソースを読み取り専用で読み込めます。依存関係の検索には、grep と find で dependency を指定します。
find	1 回の呼び出しで宣言を見つけ、その本文も取得します。queries を使うと、複数の名前を一度に検索できます。
grep	パスのグロブを使って、リテラル文字列または正規表現を検索します。grep -rn の代わりに使えます。
references	使用箇所を検索します。言語サーバーがインストールされている場合は正確な結果を返し、それ以外の場合は名前の一致に基づく近似結果を返します。どちらが結果を返したかも表示します。
retrieve	クエリに基づいて作業セットを取得します。
context	1 つのシンボルの周辺コンテキストをまとめます。
workspace_tree	ディレクトリ構造を表示します。

シンボルは path::Name、名前が曖昧な場合は path::Name@line で指定します。曖昧な読み込みでは推測せず、候補とそのシグネチャを返します。

変更

ツール	機能
replace_symbol	宣言全体を置き換えます。完全な path::Name@line ID、またはファイル内で名前が一意の場合は path::Name のみを指定します。
replace_text	一致するテキストが一意の場合に置き換えます。行番号ではなく内容を基準にします。ほかのテキスト編集と同様、編集後の領域を返します。
replace_file	ファイル全体の内容を置き換えます。
create_file	新しいファイルを作成します。
delete_file	1 つのファイルを削除します。ディレクトリは削除できません。
delete_symbol	1 つの宣言を削除します。
rename	言語サーバーを使ってファイルをまたいで名前を変更します。正確に変更できない場合は推測せず、処理を拒否します。
insert	何も置き換えずにテキストを追加します。新しい関数、新しいセクション、追加のケースなどに使用します。アンカーを指定しない場合は末尾に追加し、一意なアンカーを指定した場合はその前後に配置します。
apply	複数の編集を 1 つのアトミックな処理として実行します。アンカーを事前に検証し、すべてを適用するか、どれも適用しません。リビジョンの更新は 1 回、最後の検証も 1 回です。

編集結果は「成功」ではなく、その影響を返します。リビジョンの遷移、移動したシンボル、即時の診断、開始したバックグラウンド検証の ID が含まれます。編集では expectedRevision の事前条件を指定できます。これを指定すると、古い状態に基づく編集は、並行する変更を黙って上書きするのではなく、明示的に失敗します。

検証

ツール	説明
check	ビルド、型チェック、またはテストを実行します。コマンドを決めつけず、リポジトリ独自のコマンドを特定します。マニフェストに基づき、Makefile のターゲット、npm スクリプト、cargo、Maven、Gradle、sbt、pytest/mypy、bundler の順に調べます。判別できないプロジェクトは、誤ったツールチェーンで実行するのではなく、その旨を報告します。実行結果には実行したコマンドが必ず記載され、dryRun では実行せずにコマンドを示します。
run_tests	ファイル、テスト名、または変更されたファイルに対象を絞ってテストします。
run_command	リポジトリで宣言されたコマンドを名前で指定して実行します。
declare_command	宣言済みのコマンドを追加または削除します。
job_status	バックグラウンドジョブの状態を確認します。
job_output	必要に応じてジョブの生の出力を取得します。

終了ステータスが判断基準です。成功したように見える行を出力しても、終了ステータスが 0 以外なら失敗です。

状態

ツール	説明
changes	変更箇所を、パスだけでなくファイルおよびシンボルごとに示します。
diff	未追跡ファイルも含めてパッチを表示します。since には任意の git リビジョンを指定できます。
history	git log -L を使って、あるシンボルに変更を加えたコミットを表示します。
checkpoint	復元可能な時点を記録します。ARNO が編集したファイルのスナップショットを取得し、git の HEAD を記録します。コミットではありません。
revert	それらのファイルをチェックポイントの状態に戻します。git の状態は変更せず、チェックポイント以降にコミットが追加されている場合は拒否します。
events	ワークスペースのイベントストリームを表示します。
telemetry	このワークスペースで ARNO 独自のツールがどのように使われたかを表示します。
workspace	このリポジトリの git worktree を一覧表示し、セッションがデフォルトで使用する worktree を切り替えます。

workspace、events、telemetry、job_status、job_output を除く上記の各ツールには、任意の root=<path> も指定できます。これは、このリポジトリの git worktree のひとつを指定し、その呼び出しで操作するものです。docs/worktrees.md を参照してください。

---

プロジェクトの設定

ディスカバリーでは、マニフェストからリポジトリのビルド方法やテスト方法を推測しますが、誤ることもあります。たとえば、Makefile の python -m pytest はシステムのインタープリターを選び、1 ファイルのチェックに対する npm run test は lint とブラウザーテスト一式を実行し、TypeScript アプリが隣接する Go モジュールには「ビルド」方法が 2 通りあります。コミットされた .arno/project.json で答えを一度指定できます。エディターが .vscode/ に設定を保持するのと同じです。

{
  "areas": [
    { "path": ".", "language": "go",
      "build": "go build ./...", "test": "go test ./...",
      "testName": "go test -run {name} ./..." },
    { "path": "web", "language": "typescript",
      "typecheck": "node_modules/.bin/tsc --noEmit",
      "test": "node_modules/.bin/vitest run",
      "testFile": "node_modules/.bin/vitest run {file}",
      "testName": "node_modules/.bin/vitest run {file} -t {name}" }
  ],
  "env": { "python": ".venv/bin/python", "vars": { "CI": "1" } },
  "generated": ["web/dist", "*.pb.go"],
  "notes": "Browser tests need Playwright; run unit tests by file."
}

• エリアは、それぞれ独自の言語とコマンドを持つリポジトリ内の領域で、それぞれのパス内で実行されます。check は、ある種類のコマンドが宣言されているすべてのエリアでそれを実行します。ファイルを指定した run_tests は、そのファイルを含む最も深いエリアを使用します。{file} はエリアからの相対パス、{name} はテスト名です。
• 空のフィールドはディスカバリーによる推測にフォールバックするため、ディスカバリーが誤る部分だけを設定できます。設定を解析できない場合、未知のフィールドが指定されている場合、またはワークスペースの外部のパスが指定されている場合は、無視せずチェックを失敗させます。
• env はインタープリターのディレクトリを PATH の先頭に置き、変数をすべてのコマンドに追加します。generated パスは grep、find、ワークスペースツリーで除外されます。エリアの一覧とともに記載された notes は、セッション開始時にエージェントに送られます。
• dryRun を指定した check は、コマンドの取得元が .arno/project.json の場合、その旨を示します。

arno-mcp init --root /path/to/repo は、ディスカバリーに基づいてエリアを 1 つ含むファイルを作成します。内容を確認してコミットしてください。既存のファイルを上書きすることはありません。

リポジトリコマンド

ビルドとテスト以外にも、リポジトリごとに lint、codegen、migrate、release-gate といった独自の動詞があります。それを知らないエージェントはシェルに手を伸ばします。そこで ARNO では、代わりにコマンドを記録できます。

declare_command(name: "lint", run: "golangci-lint run ./...")
run_command(name: "lint")

コマンドは .arno/commands.json に保存され、これはコミットすることを想定しています。これにより、リポジトリで宣言されたコマンドの語彙ができます。誰か（または何か）が実行方法を見つけて一度記述すれば、その後はずっと名前で呼び出せます。名前を指定せずに run_command を呼び出すと、リポジトリで宣言されているコマンドが一覧表示されます。未知の名前で呼び出すと、実際に存在するコマンドが返されるため、誤った推測は失敗ではなく学びにつながります。

どちらの応答にも、検出された候補も表示されます。これは、リポジトリ内のマニフェストから ARNO が検出できるものの、まだ宣言されていない npm スクリプトと Makefile ターゲットです。検出は読み取り専用で、declare_command が宣言するまでは何も書き込まれません。また、ビルド、型チェック、テストですでに実行されている check スクリプトは、抜けがないため一覧から除外されます。capabilities でも、すでに報告されている内容と併せて同じ候補が表示されます。これにより、2026-09-16 のベンチマークで直接計測された失敗パターンを解消しました。つまり、何も宣言されていないリポジトリで、マニフェストに答えがすでにあるのに、エージェントが run_command の名前（test-unit、model_formsets_tests）を推測し、それぞれ無駄な呼び出しをしていました。

検証チェーン

Semgrep、カスタムリンター、ライセンスチェックといったリポジトリのルールは検証に含めます。ARNO との統合は不要です。手順を && でつなぎ、順番に実行するコマンドをひとつ宣言します。

{
  "validate": {
    "run": "go test ./... && semgrep scan --config .semgrep.yml --error",
    "description": "tests, then repository rules"
  }
}

または、ファイルを編集せずに declare_command(name: "validate", run: "…") を呼び出します。

run_command(name: "validate") を呼び出すと、ARNO 内で実行されるため、その実行がセッションの記録に残ります。終了ステータスによって結果が決まります。ルールに違反すると実行は失敗し、その後の手順は実行されず、概要には失敗した出力が先頭に表示されます。semgrep scan --error またはお使いのツールの同等のフラグを使ってください。指摘事項を出力しても終了コードが 0 になるツールは、合格と判定されます。

---

言語サポート

構造の解析には、バイナリにコンパイルされた tree-sitter 文法を使用するため、何もインストールせずに動作します。意味解析には実際の言語サーバーを使用し、これはユーザーが用意します。arno-mcp install でインストールでき、ARNO は初回使用時に起動し、セッション中は再利用して、終了時にシャットダウンします。

言語	構造	意味解析（以下をインストールした場合）
Go	✅ 組み込み	gopls
TypeScript / TSX	✅ 組み込み	typescript-language-server
JavaScript	✅ 組み込み	typescript-language-server
Rust	✅ 組み込み	rust-analyzer
Python	✅ 組み込み	pyright-langserver、または pylsp / jedi-language-server
Ruby	✅ 組み込み	ruby-lsp、または solargraph
Java	✅ 組み込み	jdtls
Scala	✅ 組み込み	metals
その他すべて	テキストスキャン、通知あり	—

各行は make conformance によってエンドツーエンドで検証されます。このコマンドは、8 つすべてのサーバーを含むイメージをビルドし、各言語の実際のリポジトリを対象に ARNO を実行します。

意味解析のリクエストは、サーバーのインデックス作成が終わるまで（$/progress トークンを使って）待機します。インデックス作成中のサーバーは、時間をかけて正しい答えを返すのではなく、誤った答えを返すためです。プライマリサーバーが名前変更を受け付けない場合、ARNO はその言語でインストールされている代替サーバーに問い合わせます。ruby-lsp はクラス名を変更できますが、メソッド名は変更できないため、Ruby のメソッド名変更には solargraph もインストールする必要があります。 ruby-lsp のみの場合、メソッド名の変更は拒否され、サーバーからの理由が繰り返し表示されます。

各編集レスポンスには、ファイルをチェックしたもの（checked: pyright-langserver）またはチェックされなかった理由（not checked: app.py: pyright-langserver is not installed）が記載されます。

Scala ではオプトインが必要です。 metals がエラーを報告するのは sbt のビルドをインポートした後です。また、インポートによって sbt が実行され、リポジトリに .bloop/ と .metals/ が作成されるため、先に許可を求めます。ARNO_METALS_IMPORT=1 が設定されていない限り、ARNO はインポートを拒否し、その旨を編集レスポンスに記載します。エディターですでにインポート済みのリポジトリでは、設定は不要です。

「構造」とは、アウトライン、シンボルの読み取り、シンボル単位の編集、grep、検索です。「意味解析」とは、正確な references、ファイルをまたぐ rename、編集時の型レベルの診断です。

ARNO は PATH に加えて、ツールチェーンが実際にサーバーをインストールする場所（~/go/bin、~/.cargo/bin、~/.local/bin、~/.coursier/bin）も検索します。これは、go install が gopls をデフォルトでは PATH に含まれない場所にインストールするためです。PATH だけを確認するクライアントでは、動作する gopls があるマシンでも Go がサポートされていないと報告されてしまいます。

サーバーが見つからなくてもエラーにはなりません。ARNO は上記のとおり機能を縮退させ、どのような応答が返されたかを通知します。

設計原則

1. ソースより構造を優先します。 まず必要十分な最小限の表現を返します。全ソースよりアウトライン、未加工のログより要約を先に返します。
2. モデルの推論より決定論的なツールを優先します。 ARNO は tree-sitter、git、gopls、プロジェクト独自のビルドツールをオーケストレーションします。これらを再実装せず、答えを得られる場合に推測することもありません。
3. すべての編集には事前条件があり、結果が返されます。 編集では想定するリビジョンを指定でき、ARNO のリビジョンが進んでいる場合は拒否されます。編集結果として返されるのは「成功」ではなく、リビジョンの遷移、変更内容、診断情報です。ARNO の外部で行われた変更は、まだリビジョンを進めません（リリース計画のフェーズ 5）。
4. ログより結論を優先します。 まず判定を示し、未加工の出力はリクエストに応じて展開します。
5. テキスト操作よりセマンティック操作を優先します。 ただし、セマンティックな方法が常に存在するとは限らないため、テキストによる代替手段も利用できます。
6. 状態を明示します。 リビジョン、チェックポイント、変更セットは、暗黙の前提ではなくオブジェクトです。
7. 検証はデフォルトで完了を待ち、リクエストに応じてバックグラウンドで実行します。 check、run_tests、run_command は判定を返します。実行に時間がかかる場合は、代わりにポーリング対象のジョブを返せます。
8. 近似値は近似値であることを明示します。 ARNO がテキストスキャンや名前一致のグラフにフォールバックする場合は、注意書きをデータと一緒にレスポンスに含めます。エージェントが読まないドキュメントに記載するだけではありません。
9. ARNO はモデルやハーネスに依存しません。 MCP はアダプターであり、アーキテクチャではありません。
10. インフラの高度さではなく、エージェントの成果を測定します。 タスク完了までのトークン数とターン数を測定します。成功率が下がるなら、トークン削減に価値はありません。
11. リポジトリネイティブの実行。 ビルド、テスト、lint は、検出された、または .arno/commands.json で宣言されたリポジトリ独自のコマンドを使って、ARNO 内で実行します。これにより、検証はシェルを介した別作業ではなく、記録の一部になります。
12. 代替手段より安価であること。 あるワークフローでシェルのほうが簡単、速い、安価であれば、ARNO はそのワークフローに失敗しています。どちらが優れているかは意見ではなく、ベンチマークで判断します（docs/benchmark.md）。

より詳しい設計ドキュメントは docs/scope.md です。

---

それでもシェルが適切なツールである場合

ARNO はシェルの合成可能性に対抗しようとはしません。次のいずれかに該当する作業でシェルを使うのは、抜け道ではなく、意図的な選択です。

• Git 操作：commit、branch、rebase、push、blame。ARNO は git の状態（changes、diff、history）を読み取りますが、状態を変更することはありません。
• 単発の確認：ローカルサーバーへの curl、プロセスの調査、ポートの確認、環境変数の読み取り。
• スクリプトやビルドシステム自体のデバッグ。コードに何が書かれているかではなく、シェルコマンドが何をするかが問題となる場合です。
• 依存関係やツールチェーンのインストール：npm install、go install、pip install。
• あらゆる種類のネットワークアクセス。

シェルでも実行できるものの、ARNO 側で行う作業：

• ビルド、型チェック、テスト、lint、コード生成。 check、run_tests、または宣言済みのコマンド（declare_command の後に run_command）を使って実行します。シェルから実行した検証は、変更トランザクションからは確認できません。編集記録に判定が残らず、対象を絞ったテストランナーもなく、失敗の要約も得られません。
• コードの読み取りと検索、およびコードの編集。 ARNO のリビジョン、診断情報、来歴が適用されるのはこの作業です。

検証のためにシェルから実行し続けるコマンドは、.arno/commands.json、またはエリアのビルドコマンドやテストコマンドとして .arno/project.json に記述してください。

---

ARNO がまだ行わないこと

Windows。 ARNO は macOS と Linux 専用にビルドおよびテストされています。中途半端に 3 つのプラットフォームに対応するより、2 つのプラットフォームでしっかり動作することを優先しています。追って通知するまで、Windows 向けのビルド、テスト、調査は行いません。ARNO の Windows 対応を希望する場合は、issue #2 に 👍 をお願いします。これが間違った判断だと思う場合も、そちらにお知らせください。率直なご意見を歓迎します。WSL 2 は Linux を実行するため、Linux ビルドが動作する可能性はありますが、テストはされていません。

このリストは機能一覧よりも役に立ちます。報告する価値のあることと、すでに把握していることがわかるためです。予定されている内容は ROADMAP.md をご覧ください。

• 9つの言語では正式な文法で解析し、それ以外はテキスト検索にフォールバックします。 Go、TypeScript、TSX、JavaScript、Python、Ruby、Java、Scala、Rustは適切に解析されます。それ以外（Kotlin、Swift、C/C++、C#、PHPなど）は、一部の宣言を検出し、ほかを見落とすヒューリスティックで処理されます。見落とす量は言語によって大きく異なるため、こうした概要は網羅的な一覧ではなく、手がかりとして扱ってください。ARNOは常に、どちらの処理が使われたかを示します（! no kotlin grammar — …）。
• セマンティック機能を使うには、その言語の言語サーバーをインストールする必要があります。 ARNOは、マシン上にある任意の言語サーバーとLSPで通信します（言語サポートを参照）。言語サーバーがあれば、referencesとrenameはコンパイラーと同等の精度で、ファイルをまたいで動作します。ない場合、referencesはその旨を示したうえでテキストベースの近似結果にフォールバックし、renameは推測で変更を加えずに拒否します。近似的な参照一覧でも読者の役には立ちますが、近似的な編集は破損につながります。
• 補完、ホバー、コードアクションには対応していません。 ARNOのLSPクライアントが実装しているのは、ツールが必要とする参照、名前変更、診断であり、プロトコル全体ではありません。
• blame、リポジトリをまたぐ操作、リモート実行には対応していません。
• フォーマットにはプロジェクト独自のルールが適用され、対象は編集したファイルだけです。 gofmtとrustfmtは常に実行されます。prettier（TypeScript/JavaScript）、blackまたはruff（Python）、scalafmtは、リポジトリで設定が宣言されている場合にのみ実行されます。設定には、prettierの設定ファイルまたはpackage.jsonのキー、[tool.black]、[tool.ruff.format]またはruff.tomlの[format]セクション、.scalafmt.confがあります。NodeとPythonでは、プロジェクト独自のバイナリが使われます。プロジェクトが選んでいないフォーマッターを使うと、1行の編集がファイル全体の差分になってしまうためです。rustfmtは最も近いrustfmt.tomlとCargo.toml（またはワークスペース）からエディションを読み込み、対象のファイルを1つだけフォーマットします。編集していないファイルにあるmod宣言はたどりません。Ruby、Java、JSON、Markdownは編集後の状態のままにされ、ARNOは.editorconfigを解釈しません。
• リビジョン追跡には、gitではなくARNO独自のカウンターを使用します。 セッション内の同時編集を検出します。これはVCSではありません。チェックポイントは、ARNOが編集したファイルのスナップショットを作成し、gitのHEADを記録します。revertはそれらのファイルだけを復元し、それ以外には手を加えません。gitの状態を変更することはなく、チェックポイントの作成後にコミットが行われている場合は拒否します。コミット済みの作業を取り消すのはgitの役割です。チェックポイントはサーバーの再起動後には残りません。
• 信頼できない入力に対する堅牢性はありません。 宣言されたシェルコマンドを実行し、指定されたファイルを編集します。開発ツールとして扱い、makeを実行したくないリポジトリに対しては使わないでください。サンドボックスやコンテナー内でARNOを実行した場合に、保護されるものと保護されないものは次のとおりです。
  • ARNO自体によって保護されるもの： 読み書きはシンボリックリンクを含めてワークスペースのルート内に限られます。依存関係のソースは読み取り専用です。リポジトリから、ARNOにそのリポジトリが同梱するバイナリを起動させることはできません（宣言されたコマンドは、すでに信頼しているシェルを通じて実行されます。また、.arno/project.jsonのインタープリターは、差分で確認するパスです）。
  • サンドボックスによってのみ保護されるもの： check、run_tests、run_commandの実行時に、宣言されたコマンド、Makefileのターゲット、npmスクリプト、テストスイートが行う動作（ネットワークアクセス、ワークスペース外のファイルへのアクセス、環境変数内の認証情報など）です。ARNOはリポジトリ独自のコマンドを、ユーザーの環境で実行します。悪意のあるリポジトリのmake testは、ARNOを使ってもシェルで直接実行しても、同じように危険です。
  • まったく保護されないもの： 有害なコマンドを宣言するよう求められたエージェント、およびワークスペースのインデックス作成時に独自のプロジェクト設定（ビルドスクリプト、プラグインなど）を実行する言語サーバーです。

---

安定性とバージョン管理

ツール名と必須引数は固定されており、テストで適用されています。0.0.3 ではツールは追加されず、2 つの引数（find の query、read_range の path）が省略可能になりました。どちらも後方互換性があります。スキーマと サーバーの指示は、引き続き接続時に一度だけ読み込まれるため、アップグレード後は再接続してください。 docs/tool-contract.md に、全体の仕様と破壊的変更に該当するものの方針が記載されています。

固定されていないもの：応答の 文言、.arno/* のファイル形式、シンボル ID の 正確な表記、そして internal/ 以下のすべてです。応答は、解析する形式ではなく、 モデルが読むテキストとして扱ってください。何かを解析する必要がある場合は、 ARNO_JSON=1 で機械可読な出力を得られます。

---

テレメトリ

ARNO は、自身のツールの使用状況、つまり呼び出し回数、応答サイズ、所要時間、 および呼び出し元が諦めてシェルを使う前に最も頻繁に発生する失敗の種類を記録します。

これはワークスペース内の .arno/telemetry.jsonl に書き込まれ、どこにも送信されません。 引数、応答本文、エラーテキストは記録せず、各呼び出しの対象（パス、シンボル、クエリ）の 10 文字のハッシュだけを記録します。これにより、混乱のレポートで、2 つ目のツールが 同じものについて尋ねたかどうかを確認できます。ARNO_TELEMETRY=0 で無効になり、 telemetry(reset: true) で消去されます。

ARNO は、作業を依頼されただけのリポジトリにファイルを残さないよう努めています。

• git リポジトリでは、ログを作成する前に、git がすでに無視している場合を除き、 ARNO はログを .git/info/exclude に追加します。これはクローン内だけで有効な無視ファイルで、 コミットされることはありません。.gitignore は変更されません。ログは未追跡ファイルとして 表示されないため、未追跡ファイルをすべてコミットするハーネスでもコミットされません。
• ARNO_STATE_DIR=/some/dir を指定すると、ログはワークスペース外の、ワークスペースごとの サブディレクトリに移動します。ARNO のルートが、別の何かによって一括でコミットまたは レビューされるチェックアウトにある場合に使用してください。
• ARNO が呼び出しを明確に拒否した場合（不明なツール名など）、ログは作成されません。

.arno/commands.json は別扱いです。これはリポジトリで宣言するコマンドの語彙であり、 コミットを前提としていて、コマンドを宣言した場合にのみ作成されます。

更新チェック

テレメトリとは別に、ARNO は GitHub で最新のリリースタグを確認します。 これは releases/latest への認証なしのリクエスト 1 回で、ワークスペースや ARNO の使い方に関する情報は一切送信しません。最大でも 1 日に 1 回、 バックグラウンドで、タイムアウトは 3 秒です。確認に失敗した場合やオフラインの場合も、 次の確認は 1 日後になります。新しいリリースがある場合は、実行中のバージョンを 尋ねたときに限り、次の場所に表示されます。

$ arno-mcp --version
arno-mcp v0.0.12
update available: v0.0.13 (running v0.0.12) · curl -fsSL https://raw.githubusercontent.com/julianbei/arno/main/install.sh | sh, then reconnect your MCP client

また、arno.capabilities の 2 行目にも表示されます。サーバーの指示や、 他のツールの応答に表示されることはありません。ARNO_UPDATE_CHECK=0 で無効になり、 CI（CI が設定されている場合）と開発ビルドでも無効です。

この機能があるのは、応答の コスト が、応答を読む人には見えないためです。 最初の実環境での計測では、日常的な呼び出しで、あるツールが 704ms で 4.6KB を返していました。 手書きのメモを 16 件作成していても、これには気づけなかったでしょう。

---

問題の報告

docs/reporting.md には、有用な報告に必要な内容が記載されています。 課題テンプレートは 4 種類あります。

• フィードバック — 実際に使ってみた感想、または無効にした理由。
• バグ — 期待どおりに動作しなかった場合。
• 使いにくさ — 「代わりにシェルを使った」。これは価値の高い報告です。
• 機能の要望 — X ができるようにしてほしい場合。

どれを選べばよいかわからない場合は、使いにくさを選んでください。最も簡単に書けて、 最も対応しやすい内容です。また、「単に習慣だった」も有効な回答です。ぜひお寄せください。 シェルに切り替えるたびに、ARNO を使う価値がなかった場面がわかります。 それこそが、ARNO を確実に改善できる唯一のシグナルです。

バグを報告する前に、バージョンが変わってからクライアントが再接続されているか 確認してください。古いツールカタログは、「このツールが見つからない」や 「修正が反映されなかった」といった問題の意外に多くの原因になっています。

---

開発

make build      # go build ./...
make test       # go test ./...
make fmt        # gofmt -w ./cmd ./internal
make binary     # bin/arno-mcp, version-stamped
make install    # onto your PATH

リポジトリ独自のコマンドは .arno/commands.json で宣言されています。これには release-gate が含まれており、ビルド、vet、テスト、gofmt チェックを実行します。タグを付けるには、このゲートを通過する必要があります。エージェントと同じ方法で実行してください：run_command(name: "release-gate")。

構成：

パス	内容
cmd/arno-mcp	MCP stdio サーバー — 重要なエントリーポイントです。
cmd/arno	内部 API を直接操作する小規模な CLI です。
cmd/arno-bench	ARNO と同等のシェルコマンドを比較するトークンベンチマークです。
internal/workspace	リビジョン、変更セット、チェックポイント、git です。
internal/code	シンボルインデックス、アウトライン、検索、grep、参照です。
internal/edit	変更、アトミックな適用、フォーマットです。
internal/diagnostics	編集に対する即時フィードバックと gopls です。
internal/jobs	非同期ジョブランナーとコマンド検出です。
internal/languages	言語ごとのアダプター（Go、TypeScript、Rust）です。
internal/commands	宣言済みコマンドのレジストリです。
internal/telemetry	ローカルでの使用状況の記録です。
internal/transport	MCP アダプターと、トランスポートに依存しない内部 API です。
internal/protocol	共有のリクエスト型とレスポンス型です。

コントリビューションを歓迎します。唯一の厳格なルールは原則 8 です。近似的な処理を行うコードパスを追加する場合は、その旨をレスポンスで伝える必要があります。

---

ライセンス

Apache License 2.0 — 詳細は LICENSE を参照してください。Copyright 2026 Julian Amelung。