「dao: command not found」「permission denied」「開発元を確認できない」と表示されても、最初に再インストールやsudoを実行する必要はありません。which、実ファイルのパス、バージョン、uname -mを確認し、PATH、実行権限、Gatekeeper、npm EACCES、API Keyの順に切り分けてください。
このガイドが必要な人
DAO-Codeを実行するとコマンドが見つからない人。
macOSの安全機能にバイナリを止められた人。
npm導入時の権限エラーや、起動後の認証失敗に困っている開発者向けです。
エラーの症状から最初の確認場所を決める
端末に出たエラーは、消さずにそのまま保存してください。エラー文だけでなく、導入方法、使用したシェル、Macのチップも残すと、再現性のある切り分けができます。
| 表示された症状 | まず確認する場所 | 先に避ける操作 |
|---|---|---|
command not found |
実行ファイルの場所とPATH | 何度も再インストールする |
permission denied |
実行ビット、所有者、隔離属性 | 無関係な範囲へ一括変更する |
| 開発元を確認できない | 配布元、署名、Gatekeeper | macOSの安全機能を全面無効化する |
bad CPU type |
uname -mとバイナリの対応 |
別アーキテクチャ版を推測で使う |
EACCES |
npmの保存先と所有者 | 反射的にsudo npmを使う |
| API認証失敗 | Keyの保存場所、権限、アカウント | Macの性能や通信だけを疑う |
DAO-Codeの公式インストールスクリプトは、システムとアーキテクチャに合うバイナリを取得し、既定の配置先への保存と隔離属性への対応を試みます。ただし、シェルのPATHまで常に有効になるとは限りません。詳しくは公式インストールスクリプトと公式インストール手順を照合してください。
PATHが効かない場合と実行ファイルがない場合を分ける
まず、現在のシェルがコマンドを見つけられるか確認します。
command -v dao
which dao
dao --version
printf '%s\n' "$PATH"
uname -m
command -vやwhichが何も返さない場合でも、実行ファイルそのものが消えたとは限りません。公式スクリプトが案内する配置先を確認し、そこにファイルがあるかを読み取り専用で調べます。配置先が分からないまま、ホームディレクトリ全体を対象にした削除や再導入を行うのは避けてください。
ファイルが存在する場合は、完全なパスで一度だけ実行してみます。
/実際に確認した配置先/dao --version
これでバージョンが表示されるなら、主因はPATHです。完全パスでの実行は応急処置であり、恒久的なPATH修正とは別です。zshを使っているなら~/.zshrc、ログイン時に読む設定が必要なら~/.zprofileなど、現在のシェルが実際に読み込むファイルを確認してください。
nano ~/.zshrc
export PATH="/実際に確認した配置先:$PATH"
保存後、設定を読み直します。
source ~/.zshrc
command -v dao
dao --version
新しいターミナルを開いても同じ結果になることが重要です。現在の画面だけで動くなら、設定ファイルの選択を誤っている可能性があります。PATHの値に同じディレクトリを何度も追加する必要はありません。
実行権限とGatekeeperは別の問題として処理する
permission deniedなら、まず対象ファイルの状態だけを確認します。
ls -l /実際に確認した配置先/dao
実行ビットがなく、入手元とファイル内容を検証済みなら、対象ファイルだけに実行権限を付与します。
chmod u+x /実際に確認した配置先/dao
一方、「開発元を確認できない」「悪質なソフトウェアかどうかを確認できない」といった表示は、単純な実行権限エラーではありません。AppleのGatekeeperとランタイム保護の説明では、アプリや実行ファイルの入手元、署名、改変の有無を確認する流れが重視されています。
まず公式リポジトリから取得した資産か、リリース名が案内と一致するかを確認してください。信頼できる公式配布物だと確認できた場合に限り、Appleの未知の開発元から入手したアプリを開く手順を使います。システム設定の安全機能を全面的に無効化する方法は、この問題の標準的な解決策ではありません。
隔離属性が原因かを調べる場合も、対象ファイルを限定します。
xattr -l /実際に確認した配置先/dao
削除を検討するのは、入手元と内容を確認した後だけです。出所不明のファイルに対して、再帰的なxattr削除を実行しないでください。
注意: エラー画面のスクリーンショットを共有する場合は、ユーザー名、ホームディレクトリ、API Key、トークン、Cookieを黒塗りまたは置換してください。エラー調査のために秘密情報を公開する必要はありません。
npm EACCESとNode.jsの不整合を切り分ける
npm経由で導入したときのEACCESは、macOSのGatekeeperとは異なります。多くの場合、npmが書き込もうとしたグローバル保存先の所有者や権限が、現在のユーザーと合っていません。
次の情報を保存してください。
node --version
npm --version
npm config get prefix
npm root -g
ls -ld "$(npm config get prefix)"
DAO-Codeのpackage.jsonに記載されたNode.js条件を確認し、公式のNode.js要件を満たしているかを先に判断します。古いNode.jsのまま依存関係だけを更新すると、権限問題に見える別の失敗が混ざることがあります。
npm公式のEACCES解決ガイドは、Node.jsのバージョン管理ツールを使う方法や、ユーザーが書き込める保存先を使う方法を示しています。したがって、最初からsudo npm install -g ...を選ぶのではなく、現在のprefixがroot所有になっていないかを確認してください。
すでにsudoで導入してしまった場合は、いきなり所有者を広範囲に変更しないでください。対象ディレクトリ、所有者、導入コマンドを記録し、npmの公式手順に沿ってユーザー単位の構成へ移行します。
CPUアーキテクチャとAPI認証は別々に検証する
bad CPU type in executableや起動直後のクラッシュなら、まず次の出力を確認します。
uname -m
file /実際に確認した配置先/dao
Apple Siliconではarm64、Intel Macではx86_64が一般的な表示です。公式インストールスクリプトが選んだバイナリと、実際のMacのアーキテクチャが一致しているかを比較してください。Apple Silicon上でIntel向け資産を使う場合や、Intel MacへApple Silicon向け資産を持ち込んだ場合、Rosettaの有無だけでは解決しないことがあります。
一方、DAO-Codeの画面やコマンドは起動するものの、DeepSeekなどのモデル呼び出しだけが失敗するなら、PATHやCPUの問題ではありません。公式クイックスタートにあるKeyの保存場所と設定形式を確認し、古いKeyを削除してから新しい値を登録します。
次の順番で確認すると、原因を混同しにくくなります。
- Keyの変数名や設定ファイル名が公式説明と一致しているか。
- 余分な空白、引用符、改行が値に入っていないか。
- アカウントが有効で、対象APIを利用できる状態か。
- モデル名やAPIエンドポイントが現在の公式仕様と一致しているか。
- ログに出たHTTPステータスやエラーコードが、認証、残高、モデル指定のどれに該当するか。
Keyを再発行しても、ログに残った古い値が自動で消えるとは限りません。シェル履歴、設定ファイル、CIの環境変数も確認し、共有前には必ず伏せてください。
条件に応じて修復方法を選ぶ
次の分岐で、不要な強い操作を避けられます。
- 実行ファイルが存在し、完全パスで起動するなら、再インストールではなくPATHを修正します。
- 実行ファイルが存在し、実行ビットだけがないなら、入手元を確認したうえで対象ファイルだけを修正します。
- Gatekeeperの警告が出るなら、公式配布物であることを確認してからAppleの手順へ進みます。
- npm prefixがroot所有であるなら、sudoの継続ではなくnpm公式のユーザー単位の構成へ戻します。
uname -mとバイナリの対象が違うなら、対応する公式資産を取得します。Rosettaや別の互換層は、公式の対応条件を確認してから選びます。- コマンドは動くがAPIだけ失敗するなら、Macの性能ではなくKey、アカウント、モデル設定を調べます。
- 公式資産の所在や設定ファイルが確認できないなら、変更を止めてログと導入経路を保存します。推測で削除しないでください。
修復後は再起動後まで検証する
修復が終わったら、次のチェックを上から実行します。
- [ ]
command -v daoが期待した配置先を返す。 - [ ]
dao --versionがエラーなく表示される。 - [ ]
uname -mと実行ファイルの対象アーキテクチャが一致する。 - [ ]
npm config get prefixが意図したユーザー単位の保存先を返す。 - [ ] プロジェクト内を読み取り専用で確認し、秘密情報を含むファイルを共有用ログへ出していない。
- [ ] API Keyを伏せた状態で、受け入れ可能なモデル呼び出しだけを実行する。
- [ ] ターミナルとDAO-Codeを終了し、Macを再起動した後もPATHと設定が残る。
記録には、発生日時、macOSのバージョン、uname -m、Node.jsとnpmのバージョン、導入方法、元のエラー、実施した変更、再起動後の結果を含めます。サポートへ相談する場合は、Hashvpsのヘルプセンターに渡せるよう、Keyを除いた形で整理してください。
よくある症状を最短で解消するための回答
DAO-Codeを導入したのにcommand not foundと表示される場合
完全パスでdao --versionを実行し、成功するならPATHだけを修正します。成功しない場合は、公式スクリプトが作成した配置先とファイルの存在を確認してください。シェル設定を変更した後は、新しいターミナルでもcommand -v daoを実行します。
macOSがDAO-Codeの起動を止めた場合
入手元、配布資産、署名、改変の有無を確認し、公式ファイルだと判断できた場合だけAppleの未知の開発元向け手順を使います。Gatekeeperを全面的に無効化したり、出所不明のファイルへ隔離属性削除を行ったりしないでください。
npmのDAO-Code導入でEACCESが出る場合
npmのprefixと所有者を確認し、Node.jsのバージョン管理またはユーザー単位の保存先へ移行します。sudoを使い続けるとroot所有のファイルが増え、後続の更新でも同じ問題が起こりやすくなります。変更前に現在の構成を記録してください。
ダウンロード後にアーキテクチャ非対応と表示される場合
uname -mとfileの結果を比較します。Apple SiliconとIntelで公式資産が分かれている場合は、該当するものを取り直してください。互換層の導入を先に決めず、公式READMEとインストールスクリプトの選択条件を優先します。
DAO-CodeのAPI Key設定をやり直す場合
コマンドの起動成功とAPI認証成功を別のチェックにします。公式クイックスタートで設定場所を確認し、古い値、空白、誤った変数名、利用権限、モデル指定を順番に見直します。ログや共有画面にはKeyを表示しません。
設定履歴が複雑なら、隔離したMacへ移す判断
同じMacで複数のNode.js、sudo導入、古いPATH、手動で削除した隔離属性が混在している場合、修復を続けるほど原因の境界が曖昧になることがあります。長期運用で物理ポートや常時接続が必要なら自分のMacを直す方が適していますが、短期検証、チーム再現、DAO-Codeの動作確認が目的なら、初期状態を分けた環境の方が比較しやすい場合があります。
現在の環境は、ローカルのPATH設定が端末ごとに違う、権限履歴を消せない、IntelとApple Siliconの確認を同じ端末で行えない、といった弱点があります。Macを買い替える方法は安定しますが、検証期間だけのために固定費とセットアップ時間を負担することになります。
そのため、チームで短期間に同じmacOS環境を用意したい場合は、Hashvpsの案内ページで、必要な環境の受け渡し条件とリセット可否を確認し、手元の修復記録と同じ確認項目を適用してください。レンタルMacも、物理ポートが必要な作業や長期の常時負荷には向きません。用途が「一時的な再現環境」なのか「日常の主開発機」なのかを分けて選ぶことが大切です。
最後に、次のテンプレートを保存しておくと、再発時に調査をやり直さずに済みます。
発生日時：
macOS：
チップ情報（uname -m）：
DAO-Codeの導入方法：
Node.js / npm：
元のエラー：
実行した確認コマンド：
変更したファイル・権限：
API Keyは削除・伏せ字済みか：
再起動後の結果：
この記録と、command -v、バージョン、アーキテクチャの結果がそろっていれば、DAO-Code macOS 開かない問題を「Macが遅い」という曖昧な判断に戻さず、PATH、権限、配布資産、認証のどこで止まったかを再確認できます。
FAQ
Mac環境の構築に悩んだら、HashvpsのリモートMacをご利用ください
Hashvpsなら、手元の端末に左右されず、必要なmacOS環境へリモートでアクセスできます。
権限やPATHの設定に時間をかけず、開発や動作確認に適したMac環境をスムーズに用意できます。