Reasonix：DeepSeek上で動作する、Claude Codeスタイルのコーディングエージェント

もしあなたが、ターミナル内で動作し、ファイルを読み取り、コマンドを実行し、自身のミスを修正してくれるコーディングエージェントである Claude Code の働き方が気に入っているものの、月額サブスクリプションよりも、各タスクごとにほんのわずかな料金を支払いたいと思うなら、次の方法が最適です。つまり、Claude Code風のCLIエージェントである Reasonix を DeepSeek のAPIに接続するのです。

2026年9月16日更新：私は2026年9月9日に自身の環境からReasonixを撤去し、現在ではチャットアプリ内にターミナルボットとして表示されなくなっています。この記事は、かつてどのように動作していたかの記録として残しておくものです。現在も同様の目的で維持されているツールについては、DeepSeek Harness (dsh) をご覧ください。

最終的に得られるもの

まずは2026年7月11日時点でリリースされたバージョンです：

$ reasonix --version
1.18.0

次にワークフローについて説明します。プロジェクトのディレクトリでターミナルを開き、reasonix と入力した上で「このスクリプトに --dry-run フラグを追加し、READMEも更新してほしい」といった指示を出します。エージェントは関連ファイルを読み取り、編集し、スクリプトを実行して動作確認を行った上で結果を報告します。これはClaude Codeユーザーにも馴染み深い処理の流れです。ただし内部的な仕組みには違いがあります：

• 中核となるAIエンジンはDeepSeekで、課金もトークン単位です。flashモデルは日常的な編集や補助作業向け、pro推論モデルは複雑なリファクタリングやデバッグ向けとなっています。2026年6月時点では、常時稼働させているエージェント群がこの2つのモデル層を利用しており、その1か月分のDeepSeek課金額は 24.08ドル でした。
• 自由にスケジュール設定が可能です。ライセンス制限がないため、長時間かかる作業――たとえば一括リファクタリングやテスト作成、ドキュメント整備など――をユーザーが使用量を気にすることなく実行させられます。
• 状態情報はホームディレクトリ内に保存されます。Reasonixは ~/.reasonix/ という隠しフォルダを用意し、設定ファイルやプロジェクトごとのセッション履歴、メモリ情報を保持するため、複数回の実行でも各リポジトリの文脈を覚えておくことができます。

手順1：インストール

これはnpmのグローバルパッケージです：

npm install -g reasonix
reasonix --version

これだけでインストールは完了します。Node.jsを標準とは異なるパスにインストールしている場合、npm のフルパスを控えておいてください。4番目の手順で自動更新機能を設定する際に必要になります。

手順2：DeepSeekを指定する

まずDeepSeekのプラットフォームサイトでAPIキーを作成します（従量課金制です。私の場合、7月の最初の11日間だけでも全エージェント群で2.23ドルしかかかりませんでした）。その後 ~/.reasonix/config.toml 内にプロバイダー情報を記述します：

# ~/.reasonix/config.toml — the shape, not a paste of mine
default_model = "deepseek-flash"

[[providers]]
name        = "deepseek"
base_url    = "https://api.deepseek.com"
models      = ["deepseek-v4-flash", "deepseek-v4-pro"]
api_key_env = "DEEPSEEK_API_KEY"    # NAME of the variable, not the key itself

エージェントCLIごとに項目名は異なりますが、根本的には ベースURL・認証情報・モデルID という3つの要素に集約されます。ツールの種類に関係なく守るべき2つのルールがあります：

• chmod 600 を使ってキー情報が含まれるファイルのアクセス権限を制限し、絶対にコマンドライン経由でキーを渡さないようにしてください。そうしないとシェルの履歴や ps の出力に残ってしまうからです。api_key_env という間接的な仕組みがあるのは、機密情報と設定内容を別々に扱えるようにするためです。設定ファイルは助言を求める際にチャットへ貼り付けることも想定されていますが、.env にはそうした用途はありません。
• 両方のモデル層を必ず指定することです。通常作業には flash 層、難易度の高い処理には pro 層を用いることでコスト管理が可能になります。ほとんどのタスクは安価な flash 層で済み、モデルが苦戦していると判断できる場面だけ pro 層を利用するというのが最も費用対効果の高い運用法です。

手順3：サブエージェントとスキル

サブエージェントとは、メインエージェントから生成される限定された作業範囲を持つワーカーのことで、「この関数を呼び出している箇所をコードベース内から探してほしい」といった指示に応じて動作します。トークン単位の課金制においては、こうしたワーカー群が flash 層で処理を行い、オーケストレーター側は pro 層で推論を実行するという使い分けもコスト調整の手段となります。一方スキルとは、エージェントが必要に応じて読み込む指示書のことで、たとえばデプロイ手順やテスト作成のルールなどを一度記述しておくだけで、以降のセッションでも繰り返し説明する手間が省けます。

現在のバージョンでは、こうした振る舞いの割り当てをデフォルト設定に任せるのではなく明示的に指定できるようになっており、この設定部分こそが実際の課金に直結するため理解しておく価値があります：

[agent]
# planner_model  = "deepseek-pro"    # two-model collaboration: pro plans, flash executes
# subagent_model = "deepseek-pro"    # default tier for spawned workers
# subagent_models = { review = "deepseek-pro", security_review = "deepseek-pro" }
# recovery_model = "deepseek-pro"    # steps in when a turn fails

特に重要なのは3行目にあるスキルごとの割り当てマップです。大抵の作業――特定文字列の検索やファイル名の変更、典型的なテストコードの作成など――は flash 層で十分対応可能です。しかしコードレビューやセキュリティチェックの場合はそうではなく、安価なモデルだと自信満々に間違った回答を返してしまうこともあります。こうした重要なタスクだけ pro 層を使うように指定することで、本当に必要な箇所での質の高い判断が実現しつつ、それ以外は低コストで済むという効果が得られます。これはすべてのサブエージェントに一律で同じモデル層を割り当てるよりもはるかに効率的な運用法です。

手順4：定期的な更新設定

エージェントCLIは進化が速く、古いバージョンではツールの改善点が利用できなくなります。そこで現在では自動更新機能が標準で備わっており、これが最も適切な対応策となります：

reasonix upgrade

設定ファイル内で更新トラックを指定しておく必要があります：

[cli]
update_channel = "stable"   # stable | preview

もし手動での操作なしに更新させたい場合は、スケジュール設定を行います。私の環境でも自動更新が行われており、撤去時点ではCLIが v1.18.0 になっていました。この設定を行う際には npm を直接呼び出すスクリプトも存在します。標準機能を使っている場合でも読んでおく価値があります。なぜなら単純に npm update -g を定期実行するだけでは、回避すべき失敗パターンが2つ存在するからです：

#!/usr/bin/env bash
set -euo pipefail
LOG="$HOME/logs/update-reasonix.log"
NPM="$(command -v npm)"

# 1. Lock guard — two overlapping npm runs corrupt the install
exec 9>"${LOG%.log}.lock"
flock -n 9 || { echo "update already running"; exit 0; }

# 2. Log rotation — cron logs grow forever unless you trim them
[ -f "$LOG" ] && tail -n 5000 "$LOG" > "$LOG.tmp" && mv "$LOG.tmp" "$LOG"

echo "before: $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"
"$NPM" update -g reasonix >> "$LOG" 2>&1
echo "after:  $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"

cron や systemd のタイマー機能などを利用して更新処理を設定できます。更新前後のバージョン情報をログに残すことは見た目以上に重要です。なぜなら、ある日突然エージェントの挙動が変化した際に、それが更新によるものかどうかを即座に判別できるからです。

実際のプロジェクトでの利用法

これまで述べた内容はグローバルな設定に関するものです。エージェントCLIを本当に有効活用するには、プロジェクトごとの設定が不可欠となります。Reasonixでは設定情報が特定の順序で読み込まれるため、その順序を知っておくと便利です：

flag  >  ./reasonix.toml  >  ~/.reasonix/config.toml  >  built-in defaults

つまり、リポジトリのルートディレクトリに reasonix.toml を配置すると、それがそのプロジェクト専用の指示書となります。一方でグローバル設定ファイルには認証情報や個人の好みが記述されます。更新チャンネルやCLIの挙動に関する項目などは意図的にグローバル限定にされており、他者から受け取ったリポジトリ内の設定ファイルが勝手にインストール全体の更新方法を変更してしまうことを防いでいます。この分離方針は理にかなっており、他人から提供されたプロジェクト用設定ファイルも安全に利用できる理由となります。

セッション状態やメモリ情報もプロジェクトごとに区分され、~/.reasonix/projects/<project>/sessions/ 配下に保存されます。ホームディレクトリからではなくプロジェクトディレクトリ内で起動すれば、前回の作業で得たコンテキストを維持したまま作業を続けられます。もちろん $HOME から起動することも可能ですが、そうすると文脈情報が混在してしまい、複数のリポジトリを扱う場合には避けた方が無難です。

プロジェクト用設定ファイルに記述すべき内容としては、効果の大きさ順に以下のような項目が挙げられます：

• ビルドやテストを実行するコマンドです。これこそが最も重要な記述項目と言えます。自身の作業結果を検証できることを把握しているエージェントは、推測で行動することがなくなります。
• モデル割り当ての設定――先ほど述べた subagent_models ブロックを各プロジェクトに合わせて調整します。セキュリティ要件が厳しいプロジェクトと静的サイトでは適切なデフォルト値も異なります。
• 禁止事項の明記です。たとえばデプロイ制限や触れてはならないファイル、あるいは「本番環境に対してこのコマンドを絶対に実行しない」といったルールを一度書き留めておくだけで、繰り返し説明する手間が省けます。
• 手順的な作業用のスキルです。デプロイ手順書やリリースチェックリストなどをここに記述しておくと、そうした手順がリポジトリ内に定義され、自分自身の記憶に頼る必要がなくなります。

このような利用形態に適した実例としては、自前でホストするチャットアプリ、バックアップ用GUI、そして WordPressサイトを静的サイトへ移行する例 などが挙げられます。これらはいずれも明確なコードベースや検証用コマンド、リリース前のチェックポイントが存在するという共通点を持っています。

補足：チャットアプリにも組み込む

ターミナル内で動作するエージェントだからといって必ずしもターミナルに留まる必要はありません。Reasonixは単なるPTY上のCLIなので、xterm.js を利用してウェブUIへ出力ストリームを流し込み、ネットワーク内のあらゆる端末から利用することも可能です。私が運用していた自前ホスト型チャットアプリでも2026年9月までこの仕組みが採用されており、Reasonixは通常のチャットエージェントと並んで「ターミナルボット」として起動・再起動・停止制御機能付きで表示されていました。この実装方法の詳細については DisPatch：自前ホスト型AIチャット にまとめられています。

注意点

• 推論モデルは回答する前に処理が停止しているように見えることがあります。 プロ版では、返答前に思考の過程がストリーム配信されます。もしエージェントを取り巻くラッパーやゲートウェイのアイドルタイムアウト値が短すぎると、長時間かかる思考処理が途中で中断されてしまいます。タイムアウト値を引き上げてください。モデル自体のせいにしないでください。
• 絶対にキーをargvに入れてはいけません。 設定ファイル（chmod 600）または環境変数ファイルのみを使用してください。コマンドラインフラグは履歴やプロセス一覧に漏れ出してしまいます。
• npmのパスをアップデーター内で固定してください。 cronは最小限のPATH設定で実行されます。対話型シェルとcron環境下ではnpmの解決先が異なる可能性があります。スクリプト内でパスを明示的に指定するか、ハードコーディングしてください。
• アップデートジョブに排他制御を施してください。 flockを使用しないと、反応が遅いnpmレジストリと頻繁なスケジュール設定の組み合わせにより、同時に2つのグローバルインストールが実行され、CLIが破損してしまう恐れがあります。
• 利用料金の増加傾向にも注意してください。 フラッシュ処理がデフォルトであれば、従量課金制でも低コストに抑えられます。万が一に備えて全てのタスクをプロ版で実行していると、結局はサブスクリプション料金と同じになってしまいます。最初の1週間は支出状況を必ず確認してください。
• セッションフォルダーがどんどん肥大化します。 プロジェクトごとの履歴記録は便利ですが、会話の多いエージェントでは数ヶ月分のデータが蓄積されます。時折、該当するドットフォルダ内のセッションデータを整理してください。
• 設定スキーマがバージョンごとに変わります。 このツールではconfig_versionマーカーを用意しています。これはリリースごとに設定内容が変化するためです。例えば、認証情報がconfig.tomlからapi_key_envへ移動したのもその一例です。アップデート後にエージェントが認証できなくなった場合は、新しいキーを生成する前に現在のドキュメントと照らし合わせて設定内容を確認してください。
• 古いセッションを再開するには追加料金がかかります。 プロバイダーのプロンプトキャッシュ期間が切れた後に会話を再開すると、コンテキスト情報が再度送信されるため全額の料金が発生します。冷蔵状態のセッションから復元する際に古いツール出力を削除する設定もありますので、これを有効にしておいてください。新規セッションを開始した方が、古いセッションを復活させるよりも費用が安く済む場合が多いです。

関連情報：より広範なDeepSeek全般の接続ガイドでは、実際のClaude Code CLIをDeepSeekが提供するAnthropic互換エンドポイントに向ける方法について説明しています。またDeepSeek Harness (dsh)、LLMアシスタントの設定方法、DisPatch：自己ホスト型AIチャットもご参照ください。