DeepSeek HarnessをGitHub Actionsで動かす方法

症状：AI Agentにリポジトリを渡したら、想定外のファイル変更や秘密情報の露出が心配になる。
最速解決：まずHeadlessモードで読み取り専用の手動タスクだけを実行し、書き込みは差分確認と独立したテストを通過した後に限定します。

最初に決めるべき接続方針

2026年8月18日時点で、DeepSeek Harnessは開発者プレビュー段階です。公式リポジトリには互換性を壊す変更があり得ると明記されているため、GitHub Actionsに専用の公式Actionが提供されている前提では設計しないでください。CIからは、公式開発ガイドに記載されたコマンドをシェルから呼び出す構成が現実的です。(公式リポジトリ)

個人リポジトリなら、最初の成功条件を「同じコミットに対して同じ種類の要約や検査結果を生成し、リポジトリを変更しないこと」に置きます。小規模チームでは、AIの提案をビルド、テスト、レビューの代わりにせず、候補差分または工件として保存してから別ジョブで検証します。

この設計が向いている人は次のとおりです。

• 個人開発者：手動実行でリポジトリ要約や静的検査を行いたい人
• 小規模チーム：プルリクエストの補助コメントや修正候補を作りたいチーム
• プラットフォーム担当者：runner、権限、秘密情報、同時実行を管理する人
• セキュリティ担当者：AI Agentに許可する入力とツール操作を制限したい人

公式のDeepSeek Harness開発ガイドでは、Headlessモードの一回限りの実行例、DEEPSEEK_API_KEY、任意のDEEPSEEK_BASE_URLが示されています。実際のコマンドは更新される可能性があるため、導入時には必ず同ガイドとリポジトリの現行状態を再確認してください。

個人開発者は手動・読み取り専用から始めます

GitHub Actionsで最初からpushや外部プルリクエストをトリガーにすると、入力、実行権限、秘密情報の三つが同時に増えます。したがって、初期段階はworkflow_dispatchによる手動実行、対象リポジトリの固定、出力先の工件化に限定します。

DeepSeek Harness公式ガイドにあるソース checkout 後の実行例は、次の形です。

name: DeepSeek Harness read-only review

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  inspect:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install and build
        run: |
          corepack enable
          pnpm install
          pnpm run build

      - name: Run Headless task
        env:
          DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}
        run: |
          pnpm dsh --profile headless "summarize this workspace" \
            > deepseek-summary.txt

      - name: Upload result
        uses: actions/upload-artifact@v4
        with:
          name: deepseek-summary
          path: deepseek-summary.txt

この例は読み取り専用運用の骨格を示すもので、使用するNode.js、pnpm、アクションのバージョンは導入日に公式資料で確認してください。開発ガイドではNode.js 22.19以上と24以上、リポジトリのpnpm@11.7.0、Git 2.26以上が前提として記載されています。(DeepSeek Harness公式開発ガイド)

Headlessモードに必要なのは、少なくとも次の入力です。

• 対象ワークスペース、または事前に取得したリポジトリ
• 実行する指示文
• DEEPSEEK_API_KEYなどの環境変数
• 成功または失敗をCIに返す終了ステータス
• 後から確認できる標準出力、要約、ログ、工件

注意：AIの出力が自然な文章になっていても、終了ステータスが成功とは限りません。ログの有無だけで判定せず、期待するファイルが存在するか、変更が発生していないか、検査コマンドが成功したかを別々に確認してください。

手動導入の確認項目

• [ ] トリガーはworkflow_dispatchだけになっている
• [ ] permissionsはcontents: readから始めている
• [ ] APIキーをリポジトリ内のファイルに保存していない
• [ ] タスク文に「ファイルを書き換えない」と明記している
• [ ] git diff --exit-codeなどで変更の有無を確認している
• [ ] 結果を工件として保存している
• [ ] 失敗時に後続の公開、マージ、デプロイが起動しない

小規模チームはAIの提案をテスト門禁の外に置きます

GitHub ActionsでDeepSeek Harnessを無人実行できますか。
できますが、無人実行と自動マージは別の判断です。AI Agentのジョブは「要約」「失敗理由の整理」「候補パッチの生成」までに留め、既存のビルド、テスト、コードレビューを通過しない限り、保護ブランチへ反映させない構成にします。

おすすめは、次の二段構成です。

1. Agentジョブが作業用ディレクトリで結果または候補差分を作る
2. 独立した検証ジョブが新しい作業領域で差分を適用し、ビルドとテストを実行する

AIのジョブと検証ジョブで同じワークスペースや認証ファイルを共有すると、Agentが残した一時ファイルや変更済み設定が検証結果に混ざります。候補差分は工件として渡し、検証側で明示的に取得する方が、原因を追跡しやすくなります。

AI Agentが自動修正したコードを誤ってマージしない方法はありますか。
書き込み権限を初期値で与えず、GITHUB_TOKENの権限を最小化し、マージ判定をAgentの終了ステータスから切り離します。ブランチ保護、必須チェック、手動承認、差分の人手確認を組み合わせ、修正内容が「テストを通った」だけでなく「意図した範囲だけを変更した」ことを確認します。

GitHubは、秘密情報の自動マスキングが完全なセキュリティ境界ではないこと、悪意あるコマンドで秘密情報やリポジトリ内容が外部送信され得ることを説明しています。fork由来の入力を秘密情報付きジョブへ直接渡さない設計が必要です。(GitHub公式の侵害runner対策)

固定依存が必要なら自前運用のMac runnerを選びます

短時間の読み取りタスクなら、まずGitHubが用意するホストrunnerで依存関係と実行時間を確認します。固定したNode.js、pnpm、CLI、秘密ネットワーク、キャッシュ、macOS固有のツールが必要になった段階で、自前運用のMac runnerを比較します。

ホストrunnerを選ぶ条件

• 毎回クリーンに近い環境で実行したい
• リポジトリの機密データを専用機に残したくない
• タスクが短く、固定したキャッシュの効果が小さい
• macOS固有の依存関係が必須ではない
• runnerのOSやハードウェアを細かく指定する必要がない

自前運用のMac runnerを選ぶ条件

• macOS専用のSDK、ツールチェーン、署名環境が必要
• プライベートネットワークや社内依存へ接続する必要がある
• 大きな依存関係のキャッシュを維持したい
• 同一構成を長期間再現したい
• CIのたびに環境準備を繰り返す負担が大きい

GitHubのrunner仕様では、macOS 11.0以降が対応範囲に含まれ、self-hosted、OS、CPUアーキテクチャーなどのラベルを組み合わせてジョブを振り分けられます。ラベルは累積条件なので、指定したすべてのラベルを持つrunnerだけが候補になります。(GitHub公式のself-hosted runner仕様)

ただし、自前運用のMac runnerは天然の安全装置ではありません。ワークスペース、シェル履歴、キャッシュ、SSHキー、環境変数が残れば、次のジョブや別リポジトリへ影響が及びます。公開リポジトリや外部forkのプルリクエストを同じrunnerへ流す構成は、GitHub自身も強く注意しています。(GitHub公式の安全な利用方法)

プラットフォーム担当者はrunnerを責任範囲で分離します

複数リポジトリがある場合、1台のMac runnerを単純に全社共有するのではなく、次のように実行プールを分けます。

• readonly-agent：要約、静的検査、テキスト工件だけを許可
• candidate-write：隔離された作業領域で候補差分を生成
• sensitive-ci：署名、社内ネットワーク、機密リポジトリ専用
• manual-approved：人の承認後だけ起動する高権限タスク

GitHub Actionsのrunnerグループは、利用可能なリポジトリを制限し、ラベルと組み合わせてジョブの送信先を絞れます。runnerのグループ自体を権限境界として扱い、リポジトリ単位で許可対象を明示してください。(GitHub公式のrunnerグループ利用方法)

複数リポジトリで1台のMac runnerを共用できますか。
技術的には可能ですが、同じ作業ディレクトリ、認証ファイル、キャッシュ、セッション状態を共有するなら避けるべきです。共用する場合は、リポジトリごとのrunnerグループまたはラベル、ジョブごとの一意な作業ディレクトリ、終了後のクリーンアップ、同時実行数の制限を設定します。機密度や書き込み権限が異なるリポジトリを同一プールへ混在させるなら、別ホストへ分ける方が説明責任を果たしやすくなります。

導入前の条件分岐

• 手動起動で読み取り専用なら、ホストrunnerを選びます。
• macOS固有の依存関係が必要なら、隔離したMac runnerを選びます。
• 外部forkのコードを実行するなら、秘密情報付きの自前runnerへ送らないでください。
• 候補差分を作るだけなら、書き込み可能なGit認証情報を渡さず工件で受け渡します。
• 社内ネットワークへの接続が必要なら、専用runnerグループと専用リポジトリを組み合わせます。
• 長時間の常時稼働が不要なら、まずホストrunnerで再現性を測り、運用負担を増やさない選択に戻します。

セキュリティ担当者は秘密情報と外部入力を分離します

GitHub ActionsへDeepSeek API Keyを安全に渡すにはどうしますか。
リポジトリ、組織、または環境のSecretとして登録し、必要なジョブのenvへ明示的に注入します。設定例や.envをコミットせず、ログへ環境変数全体を出力しないでください。GitHub Actionsでは、ワークフローが明示的に参照したSecretだけが利用されますが、実行中のプログラムが値を外部へ送信する危険まで消えるわけではありません。(GitHub公式のSecret管理)

特に避けるべき組み合わせは、外部入力、秘密情報、自前runner、書き込み可能なGitHubトークンです。プルリクエスト本文、Issue本文、変更された設定ファイル、依存関係のインストール結果は、いずれもAgentへの入力として扱い、信頼境界を越える前に検査します。

経験則：Agentに「必要なら権限を上げてよい」と指示するのではなく、権限昇格が必要な操作は失敗させ、別ジョブまたは人の承認へ渡してください。便利さよりも、拒否された操作を記録できることが重要です。

拡張前に3種類の基準タスクで検証します

いきなり複数リポジトリや並列実行へ広げず、次の順番で基準タスクを作ります。各タスクについて、成功率、実行時間、失敗理由、手動確認に要した時間、生成された工件の有無を記録してください。これらは導入先の実測値として管理し、一般的な性能値として扱わないでください。

1. リポジトリ要約
   変更なしで、対象範囲、主要モジュール、既知の検査項目をテキストとして出力します。

2. テスト失敗の説明
   既存ログだけを入力し、失敗原因の候補と確認すべきファイルを出力します。Agent自身に修正を許可しません。

3. 受動的な候補パッチ
   一時ディレクトリで修正候補を作り、差分、テスト結果、未解決点を別々の工件として保存します。

次の条件を満たすまでは、同時実行数や対象リポジトリを増やさないでください。

• [ ] 同じコミットで再実行できる
• [ ] 変更前後の差分を取得できる
• [ ] APIキーとGitHubトークンの範囲を説明できる
• [ ] Agentジョブと検証ジョブの作業領域が分かれている
• [ ] 失敗したタスクを手動で再現できる
• [ ] runner終了後に認証情報と一時ファイルが残らない
• [ ] 承認なしで保護ブランチへ変更できない
• [ ] 工件の保存場所と保持方針を確認できる

DeepSeek Harnessは開発者プレビューであり、公式ガイドに記載されたHeadlessコマンドや環境変数も今後変わる可能性があります。最後に、導入日に公式リポジトリ、開発ガイド、GitHub公式ドキュメントを再確認してください。最終更新日は2026年8月18日で、これらの資料を基に内容を確認しています。

GitHub Actionsのホストrunnerだけでは、固定依存、macOS固有のツール、社内ネットワーク、持続的なキャッシュを安定して扱えない場合があります。一方で、自前運用はrunnerの更新、隔離、ログ、認証情報の消去、故障時の交換まで自分で管理する必要があり、単発タスクには過剰です。固定環境が本当に必要だと確認できたら、自前運用Mac runnerの利用シナリオを確認し、まずは単一リポジトリ・単一同時実行で受け入れ試験を行うのが安全です。

短期の検証環境や一時的なCI用Macが必要なら、物理機を購入して常時管理するより、KVMFLUXのMac環境に関する案内を比較対象に入れる方法もあります。長期の安定した高負荷処理や物理インターフェースが必要な場合は専用購入が適しますが、DeepSeek HarnessのHeadless検証やrunner構成の試行では、期間を限定したレンタルの方が撤退条件を決めやすく、運用負担を抑えやすい選択です。