初めての取引
インストールから最初の安全な取引まで、一通りの手順を解説します
このガイドでは、クローンしたばかりのリポジトリから始めて、Agent を通じて最初の小さな取引を実行するまでの流れを説明します。実際の資金を動かす前に知っておくべきセーフティの設定をすべて取り上げ、それぞれの意味も解説します。
手順だけ確認したい方は:インストール → ログイン → ハード制約の設定 → minara doctor → チャットして取引、の流れを追ってください。このページの残りの部分は、各ステップが重要な理由を説明しています。
これはターミナルを使った手順です。インタラクティブな minara チャットセッション(REPL)からすべての操作を行います。ダッシュボードを好む方には、エージェントとチャットで同じ最初の取引を Web UI から行う手順を用意しています。
0. 事前準備
- Node.js ≥ 24。
- Minara アカウント(デバイスフローまたは API キーでログイン)。
- LLM プロバイダーの設定(Anthropic API、Claude OAuth、OpenAI、または OpenRouter のいずれか)。
- 損失を許容できる少額の資金。Agent は安全性を重視した設計ですが、接続されたシステムはどれも予期しない形で障害が起きる可能性があります。最初の取引は本番デプロイではなく、避難訓練のような位置づけで考えてください。
まだクローンとインストールが済んでいない場合は、インストールを参照してください。
1. セットアップウィザードを実行する
minara setupウィザードは利用可能なプロバイダーを自動検出し、各プロバイダーへのログインを案内します。既存の ~/.minara/ ディレクトリにインポート可能な状態があるかどうかも確認し、ワークスペース(SOUL.md、AGENTS.md、USER.md)を作成して、doctor を実行し、チートシートを表示します。
ウィザードが実際に行うこと:
~/.minara/(または$MINARA_DATA_DIRが設定されている場合はそちら)にsandbox/files/、workspace/、logs/、空のminara.dbを作成します。- アクティブなモデルを
~/.minara/settings.jsonのmodelセクションに書き込み、メッセージング/プロバイダーの認証情報を~/.minara/credentials.jsonに保存します。 - 暗号化された認証プロファイルを
~/.minara/auth/に保存します。 - 最後に
doctorチェックを実行します。これにより、起動時の問題が最初の LLM 呼び出し時ではなく、すぐに表面化します。
環境変数にすでにクレデンシャルが設定されている場合、ウィザードはそれを自動的に読み込み、対応するログイン手順をスキップします。
2. 設定を確認する
minara doctor正常な出力では、すべてのチェックが緑色で表示されます:
✓ data dir /Users/you/.minara
✓ sqlite minara.db (WAL)
✓ llm provider anthropic (api_key)
✓ minara auth device flow
✓ tool registry 62 tools registered
✓ workspace SOUL.md, AGENTS.md, USER.md
✓ env ANTHROPIC_API_KEY, MINARA_API_KEY set黄色または赤色の項目は実質的に動作に影響します。doctor がすべてクリアになるまで先に進まないでください。よくある問題:
minara auth (not configured):minara auth login minaraを実行し、ブラウザでデバイスフローを完了してください。llm provider (no credentials):ウィザードでいずれかを選択するか、環境変数を直接 export してください。tool registry (0 tools):通常、一部のファクトリ関数が依存するクレデンシャルが環境変数にない場合に発生します。ログの missing-env 警告を確認してください。
3. 最初のターンの前にハード制約を設定する
このページで最も重要なステップです。Agent は、LLM の動作に関わらずパーミッションティアのフックチェーンによって強制される、3 つのハード制約の上限を持っています:
# 1 回の取引あたりのドル上限。Agent はこの金額を超える単一の取引を実行できません。
minara config set safety.maxTransactionAmount 25
# 1 日の合計ドル上限。アトミックなチェックと減算処理により、同時実行の取引がレースコンディションでこの上限を超えることはありません。
minara config set safety.dailySpendCap 100
# ブロックリスト。Agent に絶対に触れてほしくないものを追加します。正規アドレスレイヤーがすでに既知の詐欺を検出しますが、これはユーザーが制御するレイヤーです。
minara config set safety.blockedTokens '["SAFEMARS","SQUID"]'最初の取引では、ミスがあっても回復できる上限を設定してください。1 回あたり $25、1 日あたり $100 であれば、最悪の場合でも損失は $100 に収まります。これは授業料として割り切れる金額です。
値が反映されているか確認します:
minara config listセーフティレイヤーが公開しているすべての設定については、資金安全スタックを参照してください。
4. 緊急停止ワークフローを有効にする
セッション中は /kill をいつでもすぐに実行できる状態にしておいてください。このコマンドは BeforeToolCallHook チェーンがすべてのツール呼び出しで確認するフラグを設定するため、有効化するとティア 2 以上のすべての操作が即座に停止します。
このステップで特に設定作業はありません。ただし、コマンドが存在することを覚えておいてください。最初のターンで練習しておくとよいでしょう:
> /kill
✓ emergency stop ACTIVE — all tier 2+ tools blocked
> /unkill
✓ emergency stop cleared5. REPL を起動する
minaraアイデンティティバナー、チートシート、点滅するプロンプトが表示されます。まず読み取り専用の質問をして、Agent が正しく動作していることを確認しましょう:
> what's BTC trading at?Agent は market.spot スキルをアクティベートし、get_price を呼び出して価格を返すはずです。呼び出しの詳細を確認したい場合は、/logs 20 でツール呼び出しの全チェーンを確認できます。
読み取り専用のクエリをいくつか試して、動作に慣れておきましょう:
> show my portfolio
> trending tokens on solana
> what's my daily spend so farこれらはすべてティア 1 の操作であり、資金を動かすことはありません。
6. 小さなスワップを準備する
次に、設定した上限に収まる最小限の取引を依頼します。1 回あたり $25 の上限であれば:
> swap $10 of USDC into ETH on base期待される流れ:
- Agent が
activate_skillsを通じてmarket.spotスキルをアクティベートします。 token_safety_checkを呼び出し、Base 上の USDC と ETH を正規アドレスに解決します。position_sizerを呼び出し、$10 のサイズを計算してclipped: false(上限以下)を返します。- 現在のポートフォリオに対して
exposure_limit_checkを呼び出します。 - スワップのシミュレーションを実行し、推定出力とプライスインパクトを取得します。
- プライスインパクトとともにシミュレーション結果をユーザーに提示し、確認を求めます。
yesと入力した後に限り、実際のswapツールを呼び出します。
確認ステップは実際に機能しています。requires_user_confirmation を持つすべてのティア 3 ツールは、確認が行われるまで L3 リスクゲートでブロックされます。次のターンのシステムプロンプトに、保留中の確認ブロックが表示されるはずです:
<pending_confirmation>
skill: market.spot
action: swap
summary: "$10 USDC → ETH on base, est output 0.0028 ETH, price impact 0.3%"
</pending_confirmation>プライスインパクトが小規模取引のスリッページ閾値(デフォルト 2%)を超えた場合、確認前にスワップが拒否されます。これはスリッページ保護が正常に機能している証拠です。
7. 確認して監査ログを確認する
yes と入力します。Agent がスワップを実行し、Minara のトランザクション ID とともに結果を報告します。このターンの監査エントリをすぐに確認しましょう:
sqlite3 ~/.minara/minara.db \
"SELECT tool_name, blocked, substr(result_json, 1, 80)
FROM audit
WHERE session_id = (SELECT session_id FROM sessions ORDER BY created_at DESC LIMIT 1)
ORDER BY created_at DESC LIMIT 20;"ツール呼び出しのチェーンが blocked = 0 の swap 行で終わっていることを確認できるはずです。それ以前の各呼び出しは、スワップの前に実行されたチェック(トークン安全性、サイジング、エクスポージャー、スリッページシミュレーション)です。
これが、予期しない動作を調査するたびに使う証跡です。将来のターンで問題が発生した場合、このクエリが最初の確認手段になります。
8. 確認と次のステップ
最初のスワップが完了したら、いくつか試してみてください:
/status:緊急停止の状態、本日の支出、登録済みツール数、アクティブなスキルセッション。ひと目で状況を把握できるダッシュボードになります。/budget:今日の LLM 費用をタスク別に表示します。1 回のセッションの実際のコストを把握するのに役立ちます。/prompt:現在のシステムプロンプトブロックをダンプします。キャッシュ可能な部分と動的な部分の境界、アクティブなスキルフラグメントを確認できます。LLM が何を見ているかを理解するのに役立ちます。/history 20:ロールとコンテンツのプレビュー付きで、直近 20 件の履歴エントリを表示します。/compress:セッションが長くなってきたら実行してください。Haiku を使って古いターンを要約し、プロンプトを小さく保ちます。
初日にやってはいけないこと
- Autopilot を開始しないでください。 Autopilot は、LLM がユーザーを介さずに判断を行うホップを追加します。セットアップへの信頼が確立された後には有用なツールですが、「Agent が正しく動作するか検証する」という目的には適していません。
- ワークフロー内で緊急停止を無効にしないでください。 それが正解になることはありません。
- 1 日の上限を自分の許容範囲を超えて引き上げないでください。 上限の目的は、ミスの影響範囲を限定することです。「今日の取引の合計額はどのくらいになりそうか」ではなく、「バグで失っても許容できる金額はいくらか」を基準に設定してください。
- 監査ログを公開しないでください。 リダクターは既知の機密キーをマスク処理しますが、取引履歴とタイムスタンプの組み合わせによって、一部のパターンが特定される可能性があります。プライベートな業務データとして扱ってください。
- アップグレード後に
doctorをスキップしないでください。 スキーママイグレーションは冪等ですが、新しいツールセットや環境変数が含まれるバージョンは、古い設定に問題を起こす可能性があります。minara doctorであれば数秒で確認できます。
次のステップ
- 資金安全スタックを読んで、すべての取引が通過する 6 段階のセーフティパスを理解してください。
- サンドボックスとパーミッションを読んで、フックチェーンの動作を理解してください。
- オブザーバビリティを読んで、重要な監査クエリを学んでください。
- 自動化の準備ができたら、ワークフローとAutopilotを読んでください。
- ターミナルよりダッシュボードを好む方は、エージェントとチャットで同じ流れを Web UI から確認できます。
最初の取引は退屈に感じるくらいがちょうどいいです。それがこの設計の目的です。もし興奮するような体験だったとしたら、セーフティレイヤーにバグがある可能性があります。そのときはぜひ報告してください。