DAO-Code 自動実行は安全ですか？2026 チームモード選択ガイド

「自動実行にした途端、作業フォルダー外のファイルや秘密情報まで触れないか」が心配なら、まずplanで読み取りだけを確認してください。

今週の推奨手順は、チーム標準を逐項承認に固定し、読み取り調査だけplanへ分離することです。作業ディレクトリの隔離、認証情報の保護、復旧、監査をすべて検証できた場合に限り、限定されたテスト環境でautoを試します。yoloは日常のチーム開発には使いません。

対象となる担当者

チームのDAO-Code利用基準を決める技術責任者向けです。コードリポジトリ、APIキー、ビルド用認証情報を守るセキュリティ担当者にも適しています。

複数の開発環境へDAO-Codeを配布するプラットフォーム管理者は、端末ごとに自由なモードを許可するのではなく、最初に共通のルールと復旧手順を決めてください。

5つの実行方式と操作範囲

DAO-Codeの公式READMEでは、plan、default、acceptEdits、auto、bypassPermissionsという5つの実行方式が説明されています。これは安全認証の結果ではなく、プロジェクト側が公開している操作設計です。現在の仕様は、DAO-Code公式READMEの実行方式で導入前に再確認してください。

読み取り、ファイル編集、Shellコマンド、外部ディレクトリへのアクセスは同じリスクではありません。編集だけを自動化できても、コマンド実行や外部接続まで安全になるわけではないため、操作種別ごとに許可範囲を分けます。

操作ルールと作業ディレクトリ

安全な設定は「autoを選ぶこと」ではなく、autoに渡す範囲を小さくすることです。DAO-Codeの公式安全方針には、ルールの分層、敏感な対象への確認、監査ログ、任意のシステムサンドボックスが示されています。ただし、これは第三者監査や、すべてのプラグインとMCPサービスの安全性を意味しません。公式セキュリティ方針と実際の設定を照合してください。

次の条件分岐でモードの上限を決めます。

• 未知のリポジトリ、取得元が不明なコード、外部入力が多いタスクなら、planを選びます。読み取り結果と変更案を確認してから、別の作業領域へ移します。
• 信頼できる個人用リポジトリでも、本番設定や認証情報が同じディレクトリにあるなら、逐項承認へ戻します。
• 専用ディレクトリ内だけで生成、編集、テストを行い、外部パスをdenyにできるなら、検証後にautoを候補とします。
• denyルールが自動実行で無視される、または親ディレクトリへ書き込めるなら、autoを使わず逐項承認に戻します。
• 破棄可能な仮想環境で、認証情報を持たず、終了後に環境を再作成できる場合だけ、より強い自動化を検討します。
• 本番データ、秘密鍵、課金操作、削除処理、未確認のMCPツールが関係するなら、手動確認を維持します。

実際の検証では、作業ディレクトリ内の安全なテストファイルを編集させた後、親ディレクトリ、SSH設定の保存場所、環境変数ファイル、共有ボリュームへの書き込みを順番に試します。成功条件は「操作が失敗した」だけではありません。どのルールが拒否し、ログに何が残り、再実行時も同じ判定になるかまで記録します。

認証情報と外部接続

DAO-Codeをチームへ配布する場合、コードの変更より先に認証情報の流れを確認します。AI APIキー、SSH設定、クラウド認証情報、プロジェクト用シークレットは、ファイルだけでなく、ログ、メモリー、環境変数、子プロセスにも現れる可能性があります。

公式方針に敏感な対象への確認や秘密情報対策が記載されていても、機能の存在を完全な秘密情報監査とみなしてはいけません。次の確認を分けて行います。

• 秘密情報を含むファイルを読み取ったとき、内容が監査ログへそのまま出ないか。
• Shellの子プロセスへ不要な環境変数が渡らないか。
• SSHやクラウド接続の設定が、説明なしに変更されないか。
• 外部URL、MCP、Webhookへの接続が許可なしに発生しないか。
• 秘密情報スキャンが検出した場合、処理が停止するのか、警告だけで続くのか。
• SSRF対策や接続先制限が、外部入力を経由した場合にも機能するのか。

OWASPのAI AgentとMCPに関するセキュリティ指針でも、エージェントの権限縮小、外部入力の検証、ツール呼び出しの監視が重視されています。DAO-Codeの機能説明と、チーム側の運用統制は別の層として設計してください。

失敗後の復旧とshadow-git

自動実行の評価では、成功率よりも失敗後の復旧時間を見ます。誤った編集、依存関係の変更、生成ファイルの大量追加が起きたとき、正式なGit履歴を壊さずに戻せることが重要です。

導入前に、次の手順を実行してください。

1. 専用ブランチまたは複製した作業ディレクトリを作成します。
2. DAO-Codeを実行する前に、現在の状態を記録します。
3. 意図的に誤った編集と不要なファイル作成を含むテストタスクを与えます。
4. shadow-gitのチェックポイントと復元コマンドを確認します。
5. 復元後に、正式なGit履歴、未追跡ファイル、無視設定がどうなったかを比較します。
6. 別の担当者が同じ復旧を実行できるよう、手順と失敗条件を文書化します。

shadow-gitの記録があっても、プロジェクト自身のバージョン管理を置き換えるものではありません。復元操作が正式な履歴へ自動反映される設計なら、autoの利用範囲を狭めます。復旧可能な作業コピーと、レビュー対象となる正式ブランチを分けてください。

監査ログと責任分担

監査では、単にログが存在するかを確認しません。誰が、どのモードで、どの操作を、どの理由で許可したかを後から追える必要があります。

最低限、操作の種類、対象パス、コマンド、外部接続、判定結果、承認者、復旧の有無を確認します。一方で、ログ自体にAPIキー、トークン、個人情報、ソースコードの機密部分が残れば、監査記録が新しい漏えい経路になります。OWASPのログ設計ガイドに沿って、収集対象、マスキング、保管、閲覧権限を決めてください。

チーム内では、少なくとも次の責任を分けます。

• 高リスク操作を承認する担当者。
• 実行後のログを確認する担当者。
• ルール変更をレビューする担当者。
• 事故時に環境を停止し、復旧する担当者。

一人の管理者がすべてを兼ねる場合でも、承認と事後確認を同じ画面の流れに埋め込まないようにします。DevSecOpsの工程分離や証跡管理は、NISTのDevSecOps参照モデルも設計時の比較材料になります。

チーム導入の検証手順

1. 対象環境を複製する
   本番リポジトリや実際の認証情報を使わず、破棄できる作業領域を用意します。

2. planで影響範囲を確認する
   読み取り対象、推奨変更、外部接続の有無を記録します。ここで不明なパスが出たら、autoへ進みません。

3. allow、ask、denyを分離する
   作業ディレクトリ内の編集は許可候補、依存関係やShellは確認対象、認証情報や親ディレクトリは拒否候補にします。

4. 越権書き込みを試す
   作業領域の外、秘密情報の保存場所、共有ディレクトリへ書き込むタスクを用意します。自動モードでも拒否されることを確認します。

5. 秘密情報の流出を確認する
   ダミーのAPIキーを置き、ログ、メモリー、子プロセス、外部接続先に値が出ないかを調べます。実際のキーは使いません。

6. 失敗から復元する
   変更を意図的に壊し、shadow-gitとプロジェクトのGit操作で戻します。正式履歴に不要なコミットや変更が残らないことを確認します。

7. 監査担当を決める
   ログを確認する人、モード変更を承認する人、環境を再作成する人を明文化します。

この手順を合格条件として残せない場合、DAO-Code 自動実行をチーム標準にしないでください。機能があることと、安全に運用できることは別の判断です。

モード選択マトリクス

ここでいう「逐項承認」は、DAO-Codeの具体的な方式名だけでなく、チーム運用上の基準を指します。実際の設定名は、導入時点のREADMEと安全方針に合わせて読み替えてください。

最終判断の条件分岐

• 読み取り中心で、リポジトリが未知なら、planを選びます。
• 通常のチーム開発で、変更内容をレビューしたいなら、default系の逐項承認を選びます。
• 作業ディレクトリが専用化され、外部パスと秘密情報が遮断され、復旧テストに合格したなら、限定タスクだけautoを選べます。
• 本番認証情報、不可逆操作、未監査のMCP、共有ディレクトリがあるなら、autoへ移行せず逐項承認に戻します。
• 環境を終了後に完全破棄でき、資格情報を置かない場合だけ、yolo相当の方式を隔離テストで検討します。

FAQ

DAO-Code 自動実行命令は安全ですか？

安全性はモード名だけでは判断できません。planで読み取り範囲を確認し、allow、ask、denyのルール、秘密情報の保護、作業ディレクトリの隔離、復旧手順を検証してください。実行ログにAPIキーやSSH設定が残らないことも確認し、未検証のMCPや外部フックは別枠で評価します。

チームでDAO-Codeを使うならどのモードが適していますか？

通常のチーム開発では、変更やコマンドごとに確認できる逐項承認を基準にします。読み取り中心の調査はplan、破棄可能な隔離環境で範囲を限定した反復作業はautoが候補です。生産環境の認証情報や不可逆操作を扱う場合は、autoへ移行せず手動確認を維持します。

DAO-Code autoモードを導入する前に何を確認すべきですか？

まず専用の作業ディレクトリだけを書き込み対象にし、denyルールが自動実行中にも効くかを試します。次に、APIキー、SSH設定、クラウド認証情報がログや子プロセスへ漏れないこと、shadow-gitから変更を戻せること、誰がログを確認するかを決めます。

DAO-Code yoloモードは正式プロジェクトに向いていますか？

日常の正式プロジェクトには向きません。yoloは確認を省く範囲が大きく、誤った削除、秘密情報の送信、想定外の外部接続を発見する前に処理が進む可能性があります。使うなら認証情報を置かず、終了後に環境ごと破棄できる隔離テストに限定してください。

DAO-Codeが作業ディレクトリだけを変更するよう制限する方法はありますか？

プロジェクト専用ディレクトリを作り、ルールで許可対象、確認対象、拒否対象を分けます。親ディレクトリ、秘密鍵の保存場所、共有ボリューム、設定ファイルをdeny側へ置き、外部パスへの書き込みを試してください。自動モードでも拒否が維持されるかが合格条件です。

現在のMac環境と隔離されたMac環境

手元のMacだけで運用すると、開発作業と検証用の自動実行が同じユーザー領域、同じ認証情報、同じファイルシステムに重なりやすくなります。さらに、設定を誤ると作業用データの退避、環境の再作成、チーム全員への同じ状態の配布に手間がかかります。

HashvpsのMacレンタルを検討する場合は、単に処理性能を見るのではなく、専用の作業領域を分けられるか、利用後に環境を再交付できるか、アクセス権とログの担当を決められるかを確認してください。料金や提供条件は変更される可能性があるため、Hashvpsの料金・プラン詳細で現行条件を確認し、運用ルールはHashvpsのヘルプセンターと照合してください。

自前のMacは、長期的に同じ環境を保持し、物理デバイスやローカル資産へ直接アクセスしたいチームに向いています。一方で、複数の検証環境を毎回分離したい場合は、ローカル環境だけでは隔離、初期化、再配布の作業が増えます。先にautoの越権、認証情報、復旧テストを隔離環境で完了し、その結果を基にレンタルを含む運用方式を選ぶのが安全です。