「開発チームが Muse Code を使いたいと言っている。許可してよいか」——情報システム部門や法務が判断するために、確認しておくべき点を整理します。
1. どちらの料金ティアを使うのか
ここが最大の分岐点
Muse Code には2つのティアがあり、contributor ティアを選ぶと入力と出力が Meta のモデル学習に使われます。単価は約21分の1になりますが、その差額は「打ち込んだ内容を渡すこと」の対価です。
コーディングエージェントにおける「入力」は、打った質問文だけではありません。エージェントが作業のために読んだソースコード、設定ファイル、ログ、テストデータがそのまま入力になります。詳しくはcontributorティアの記事に整理しました。
2. 起動時に何を読み込むか
実測したところ、Claude Code を併用している環境では、Muse Code の起動時に Claude Code の個人ルールが読み込まれます（実測記事）。そこに社内の事情を書いていれば、それも送信対象になります。
この挙動は HOME を差し替えることで回避できることも確認しています。
3. 既定の安全設定は妥当か
既定値は安全側に寄っています。
| 項目 | 既定 |
|---|---|
| ツール承認 | on-request（求める） |
| 承認の判定 | on（LLMが判定） |
| ネットワーク | proxy-only |
| サンドボックス | 有効 |
問題はこれを外すオプションが用意されていることです。--yolo ひとつで承認もサンドボックスも無効になります。現場が使うコマンドを把握できる状態にしておく必要があります。
4. ログに何が残るか
セッションのイベントログがディスクに保存されます。muse export で書き出すと、メッセージ・ツール呼び出しと結果・承認記録・暗号化された推論内容などが1つのJSONにまとまります。--redacted で秘匿処理をかけた書き出しもできます。
ログを残したくない場合は --no-session-log があります。
5. 検証は課金なしで始められる
--provider echo を使えば、アカウント作成も課金もなしにCLIの挙動と安全設定を確認できます（記事）。導入可否を判断する前段階として使えます。
確認事項のまとめ
- 使用するティアを標準に固定できるか。現場判断で contributor に切り替えられる状態になっていないか
- 顧客のコードを扱うリポジトリと、社内の実験用リポジトリを分けられているか
- NDA・再委託条項・成果物の権利帰属と矛盾しないか（契約書の文言によります。法務にご確認ください）
- 認証情報や本番データが、エージェントの読める範囲に置かれていないか
--yoloなどの安全解除オプションの扱いを決めているか
本稿は論点の整理であり、法的な助言ではありません。実際の判断は契約内容によりますので、顧問弁護士や法務部門にご確認ください。