Claude Codeに/loop + cronで夜勤させたら、朝起きたらPRが生えてる！？みたいなやつの作り方

Posted at 2026-03-19

この記事の対象読者

Claude Codeを日常的に使っていて、もっと自律的に動かしたい開発者
「permissionの承認ボタンを押すだけの人間」になっている自覚がある方
--dangerously-skip-permissions を使っているが、もう少し安全な方法を探している方
CI/CDとは別に、開発中の「ちょっとした自動化」をAIに任せたい方

この記事で得られること

Claude Code /loop コマンドの仕組みと制約の完全な理解
Auto Mode（Research Preview）の正体と --dangerously-skip-permissions との違い
tmux + cron を組み合わせてセッションを永続化する実践パターン
開発・本番監視・CIの3つの環境別セットアップ
「放っておいたら壊れていた」を防ぐためのガードレール設計

この記事で扱わないこと

Claude Code自体のインストール方法や基本的な使い方
GitHub ActionsやClaude Code on the Web（Desktop scheduled tasks）の詳細
Ralph Loop等のサードパーティ製ループツールの比較
Agent SDK（プログラマティックなエージェント構築）の話題

1. 「承認ボタンを押すだけの人間」問題

Claude Codeで大きめのリファクタリングを任せたことがある人なら、こんな経験があるはずだ。

コーヒーを淹れに席を離れて戻ってきたら、Claudeはステップ2で止まっている。mkdir の実行許可を待って。...orz

Claude Codeはデフォルトで、あらゆる操作に対して許可を求める。ファイル編集、Bashコマンド、ネットワークアクセス、MCP ツール呼び出し。セキュリティの観点では正しい設計だが、20ステップ以上のタスクになると、開発者は「承認ボタンを押すだけの人間」に成り下がる。

これを夜勤の警備員に例えると、こういう状況だ。

優秀な警備員を雇ったのに、廊下を曲がるたびに「曲がっていいですか？」と電話してくる。
ドアを開けるたびに「開けていいですか？」と電話してくる。
巡回どころではない。そして雇い主も寝られない。

この問題に対して、2026年3月のClaude Codeアップデートは3つの回答を用意した。

機能	導入バージョン	役割
`/loop`	v2.1.71	巡回スケジュールの自動化（セッション内cron）
Auto Mode	Research Preview（3月12日〜）	警備員自身が「これは報告不要」と判断する能力
cron + tmux	OS機能	警備室（セッション）を永続化するインフラ

この3つを組み合わせると、「寝ている間にAIが働き、朝起きたら成果物ができている」ワークフローが実現する。

読者は今、「それってDockerコンテナ内で --dangerously-skip-permissions 付ければ同じじゃない？」と思ったかもしれない。半分正解で、半分不正解だ。順を追って解説する。

2. /loop — セッション内で回り続ける巡回スケジュール

2.1 /loopとは何か

/loop は Claude Code v2.1.71（2026年3月）で導入されたスラッシュコマンドで、セッション内でプロンプトを定期的に自動実行するcronライクなスケジューラだ。

夜勤の警備員に例えるなら、「巡回表」を渡す行為に相当する。「5分ごとにサーバールームを見てきて」「2時間ごとにエラーログをチェックして」といった指示を、一度渡せばあとは自動で繰り返してくれる。

# 基本構文
/loop <間隔> <プロンプトまたはコマンド>

# 実例
/loop 5m デプロイのステータスを確認して
/loop 10m /run-tests
/loop 2h エラーログを確認してissueがあればPRを作って

自然言語で間隔とタスクを書くだけでよい。内部的にはPOSIX cron式（例: */5 * * * *）に変換されて登録される。

2.2 /loopの制約 — これを知らずに使うと事故る

/loop には明確な制約がある。ここを理解せずに使うと「朝起きたら何も動いていなかった」という悲しい朝を迎える。

制約	詳細
セッション依存	ターミナルを閉じると全てのループが消える。永続化なし
3日間の自動失効	定期タスクは作成から3日後に自動削除される
最大50タスク	1セッションあたり同時に50個までのスケジュールタスク
逐次実行	複数ループは並列ではなく逐次に動く
ジッター	定期タスクは周期の最大10%（上限15分）遅延する可能性あり
遅延発火	Claude が長時間タスク実行中にスケジュール時刻を過ぎた場合、完了後に1回だけ発火する

特に重要なのはセッション依存の制約だ。SSHが切れた、ノートPCを閉じた、うっかり exit した ─ いずれもループは即死する。復旧手段はない。これを解決するのが後述のtmux + cronパターンだ。

2.3 /loopの得意パターンと苦手パターン

向いているタスク:

デプロイ監視（HTTPステータスの定期チェック）
テストスイートの定期実行
PRのCIステータス変化の検知
エラーログのスキャンと要約
依存パッケージの脆弱性チェック

向いていないタスク:

創造的な設計判断が必要なタスク
副作用が大きく取り消しが難しい操作
外部サービスへの書き込みを伴うタスク（DB更新など）
前回の出力に依存する連鎖タスク

3. Auto Mode — 「判断を委ねる」という選択

3.1 パーミッション問題の3つの選択肢

Claude Codeのパーミッション制御には、段階的な3つの選択肢がある。

夜勤の警備員に戻ろう。雇い主として、どこまで権限を委譲するかの問題だ。

モード	比喩	コマンド
通常モード	廊下を曲がるたびに電話してくる	（デフォルト）
Auto Mode	異常時だけ電話してくる優秀な警備員	`claude --enable-auto-mode`
YOLO Mode	鍵を全部渡して「好きにやって」	`--dangerously-skip-permissions`

3.2 Auto Modeの仕組み

Auto Modeは2026年3月12日にResearch Previewとしてリリースされた。パーミッション判断をClaude自身に委ねる仕組みで、アクションごとにリスクを評価し、安全と判断すれば自動承認、危険と判断すればプロンプトを表示する。

# Auto Modeの有効化
claude --enable-auto-mode

Auto Modeは管理者によって無効化できる。Windowsの場合、レジストリキー HKLM\SOFTWARE\Policies\ClaudeCode の disableAutoMode を disable に設定する。Linuxでは /etc/claude-code/managed-settings.json に {"disableAutoMode": "disable"} を記述する。

3.3 Auto Mode vs --dangerously-skip-permissions — 本質的な違い

ここが最も重要な区別だ。

比較項目	Auto Mode	--dangerously-skip-permissions
パーミッション判断	Claude自身がリスク評価	全てバイパス
プロンプト・インジェクション対策	あり（不完全ながら組み込み）	なし
読み取り操作	自動承認	自動承認
ファイル削除	確認を出す可能性あり	確認なしで実行
ネットワークアクセス	確認を出す可能性あり	確認なしで実行
推奨環境	隔離環境推奨	隔離環境必須
トークン消費	やや増加（リスク評価の推論分）	変わらない

Auto Modeでも隔離環境での実行が推奨されている。 本番環境のクレデンシャルやAPIアクセスがある環境では、Auto Modeであっても安全とは言えない。プロンプト・インジェクション対策は組み込まれているが、Anthropic自身が「不完全」と明言している。

4. 永続化の壁 — tmux + cron で「警備室」を建てる

4.1 なぜ永続化が必要なのか

/loop は優秀だが、セッションが死ねば全てが消える。ノートPCを閉じたら終わり。SSHが切れたら終わり。

ここで必要になるのが、セッションそのものを永続化するインフラだ。夜勤の比喩で言えば、「警備室」を建てることに相当する。警備員（Claude）が巡回中でも、警備室（tmuxセッション）は壊れない。雇い主（開発者）が寝ていても、警備室はそこにある。

4.2 パターンA: tmux + /loop（セッション内完結型）

最もシンプルなパターン。tmuxセッション内でClaude Codeを起動し、/loop で定期タスクを設定する。

# 1. tmuxセッションを作成
tmux new-session -d -s claude-night -c ~/my-project

# 2. Claude Codeを起動（Auto Mode有効）
tmux send-keys -t claude-night 'claude --enable-auto-mode' Enter

# 3. 起動を待つ
sleep 15

# 4. /loopコマンドを送信
tmux send-keys -t claude-night '/loop 30m テストを実行して、失敗があればコードを修正してテストが通るまでリトライして' Enter

メリット: 設定が簡単。Claude Codeのセッション文脈が維持される。
デメリット: 3日で/loopが失効する。Claudeプロセスがクラッシュしたら復旧しない。

4.3 パターンB: cron + claude -p（ヘッドレス型）

/loop を使わず、OSのcronから直接 claude -p（非対話モード）を定期実行するパターン。

# crontabに登録
crontab -e

# 30分ごとにテスト実行 + 失敗時は修正を試みる
*/30 * * * * cd /home/dev/my-project && claude -p "テストを実行して、失敗していたらコードを修正してPRを作って" --dangerously-skip-permissions --output-format stream-json >> /var/log/claude-night.log 2>&1

# 毎朝9時に前日のコミット要約を生成
0 9 * * * cd /home/dev/my-project && claude -p "昨日のコミットを要約してSlack用のMarkdownを生成して" --dangerously-skip-permissions >> /var/log/claude-morning.log 2>&1

メリット: セッション管理不要。cronなので信頼性が高い。マシン再起動後も自動復旧。
デメリット: 各実行が独立セッションなので文脈が引き継がれない。claude -p はヘッドレスなのでAuto Modeではなく --dangerously-skip-permissions が必要。

claude -p はログインセッションの認証情報に依存する。cronから実行する場合、環境変数（特に ANTHROPIC_API_KEY や認証トークン）が正しく渡されているか確認が必要だ。macOSの launchd の方がcronより認証周りの問題が少ないという報告もある。

4.4 パターンC: tmux + cron（ハイブリッド型） ★推奨

tmuxセッションの永続性と、cronの信頼性を組み合わせた最も堅牢なパターン。

考え方はこうだ:

cronが毎日決まった時刻にtmuxセッションを再作成する（古いセッションは破棄）
新しいセッションでClaude Codeを起動する
Claude Codeに「前回の記憶ファイルを読んで作業を再開して」と指示する

Claude Codeの /loop は3日で失効するが、cronが毎日セッションを再起動するので、この制限を事実上回避できる。

セットアップスクリプト:

#!/bin/bash
# claude-night-shift.sh — Claude Codeの夜勤セットアップ

PROJECT_DIR="/home/dev/my-project"
SESSION_NAME="claude-night"
LOG_FILE="/var/log/claude-night.log"

echo "[$(date)] Starting Claude night shift..." >> "$LOG_FILE"

# 既存セッションを終了
tmux kill-session -t "$SESSION_NAME" 2>/dev/null
sleep 2

# 新しいtmuxセッションを作成
tmux new-session -d -s "$SESSION_NAME" -c "$PROJECT_DIR"

# Claude Codeを起動（Auto Mode）
tmux send-keys -t "$SESSION_NAME" 'claude --enable-auto-mode' Enter

# 起動完了を待つ（MCP接続等に時間がかかる場合がある）
sleep 20

# 作業指示を送信
tmux send-keys -t "$SESSION_NAME" \
  'プロジェクトの状態を確認して、.claude/memory/night-shift.md があれば読んで前回の続きから作業して。以下のループを設定して: (1) /loop 30m テストを実行して失敗があればコードを修正 (2) /loop 2h 依存パッケージの脆弱性チェック (3) /loop 4h オープンなPRのレビューコメントを確認して対応' Enter

echo "[$(date)] Claude night shift started." >> "$LOG_FILE"

crontab設定:

# 毎日21時にClaude夜勤を開始
0 21 * * * /home/dev/scripts/claude-night-shift.sh

# 毎朝8時にClaude夜勤の成果をまとめる
0 8 * * * tmux send-keys -t claude-night '今夜の作業をまとめて .claude/memory/night-shift.md に保存して。修正したファイル一覧、作成したPR、残っている問題を含めて' Enter

5. 環境別セットアップ — 開発 / 本番監視 / CI

5.1 開発環境（ローカルマシン / WSL）

目的: テストの自動修正、コードレビュー、ドキュメント更新

# .claude/settings.local.json（開発環境用）
{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(git diff)",
      "Bash(git status)",
      "Bash(git add)",
      "Bash(git commit)",
      "Bash(git push)"
    ],
    "deny": [
      "Bash(rm -rf)",
      "Bash(sudo *)",
      "Bash(curl * | bash)",
      "Bash(docker rm)",
      "Bash(DROP TABLE)"
    ]
  }
}

settings.json の allow / deny リストを使えば、Auto Mode や --dangerously-skip-permissions を使わなくても、安全な操作だけを自動承認できる。「鍵を全部渡す」のではなく「特定のドアだけ開けられるカードキー」を渡すイメージだ。

5.2 本番監視環境（Dockerコンテナ内）

目的: ログ監視、アラート生成、インシデント初動対応

# Dockerfile.claude-monitor
FROM node:22-slim

# Claude Codeインストール
RUN npm install -g @anthropic-ai/claude-code

# 作業ディレクトリ
WORKDIR /app

# 監視対象のソースコードをマウント（読み取り専用）
# docker run -v /path/to/project:/app:ro

# ネットワーク制限（必要最小限のアクセスのみ）
# docker run --network=monitoring-net

CMD ["claude", "--dangerously-skip-permissions", "-p", \
     "ログファイルを監視して、ERROR/CRITICALを検知したら原因分析と対策案をreport.mdに出力して"]

# docker-compose.monitor.yml
services:
  claude-monitor:
    build:
      context: .
      dockerfile: Dockerfile.claude-monitor
    volumes:
      - ./src:/app/src:ro          # ソースコード（読み取り専用）
      - ./logs:/app/logs:ro        # ログ（読み取り専用）
      - ./reports:/app/reports     # レポート出力先（書き込み可）
    environment:
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
    networks:
      - monitoring-net
    restart: unless-stopped

networks:
  monitoring-net:
    driver: bridge

本番監視ではコンテナの隔離が必須だ。--dangerously-skip-permissions をコンテナ外で使うと、プロンプト・インジェクション攻撃でクレデンシャルが漏洩するリスクがある。2026年1月にPromptArmorが実証したように、.docx ファイル内の非表示テキストがClaude Codeを操作してファイルをアップロードさせる攻撃が確認されている。

5.3 CI/CD環境（GitHub Actions連携）

目的: PR自動レビュー、テスト失敗の自動修正

# .github/workflows/claude-review.yml
name: Claude Code PR Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'

      - name: Install Claude Code
        run: npm install -g @anthropic-ai/claude-code

      - name: Run Claude Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          claude -p "このPRの差分をレビューして。バグ、セキュリティ問題、パフォーマンス懸念をチェックして結果をreview.mdに出力して" \
            --dangerously-skip-permissions \
            --output-format stream-json \
            > review-output.json

      - name: Post Review Comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = fs.readFileSync('review.md', 'utf8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## 🤖 Claude Code Review\n\n${review}`
            });

6. ガードレール設計 — 「放置」を「安全な放置」にする

自律ワークフローで最も怖いのは、「放っておいたら取り返しのつかないことになっていた」だ。以下に、段階的なガードレールを設計する。

6.1 Hooksによる安全弁

Claude Code v2.0以降、Hooksはパーミッション制御の推奨手段になっている。--dangerously-skip-permissions の代わりに、Hooksで細かくコントロールできる。

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": "python3 .claude/hooks/validate_command.py \"$TOOL_INPUT\"",
        "timeout": 5000
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write",
        "command": "python3 .claude/hooks/check_file_change.py \"$TOOL_INPUT\"",
        "timeout": 5000
      }
    ]
  }
}

#!/usr/bin/env python3
# .claude/hooks/validate_command.py — Bash実行前のバリデーション

import sys
import json

BLOCKED_PATTERNS = [
    "rm -rf /",
    "sudo",
    "DROP TABLE",
    "curl * | bash",
    "wget * | sh",
    "> /dev/sda",
    "mkfs",
    "dd if=",
]

def validate(tool_input: str) -> None:
    """コマンドが安全かどうかを検証する。"""
    try:
        data = json.loads(tool_input)
        command = data.get("command", "")
    except (json.JSONDecodeError, AttributeError):
        command = tool_input

    for pattern in BLOCKED_PATTERNS:
        if pattern.replace("*", "") in command:
            # 非ゼロ終了コードでツール呼び出しを拒否
            print(json.dumps({
                "hookSpecificOutput": {
                    "permissionDecision": "deny",
                    "reason": f"Blocked pattern detected: {pattern}"
                }
            }))
            sys.exit(1)

    # 許可
    print(json.dumps({
        "hookSpecificOutput": {
            "permissionDecision": "allow"
        }
    }))

if __name__ == "__main__":
    validate(sys.argv[1] if len(sys.argv) > 1 else "")

6.2 コスト監視スクリプト

/loop を短い間隔で回すと、APIコストが想定以上に膨らむことがある。以下の診断スクリプトで事前に見積もれる。

#!/usr/bin/env python3
"""
claude_cost_estimator.py — /loop のコスト見積もりツール

使い方:
    python claude_cost_estimator.py --interval 30 --hours 8 --tokens-per-cycle 5000
"""

import argparse
from dataclasses import dataclass


@dataclass
class CostEstimate:
    """コスト見積もり結果を保持するデータクラス。"""
    cycles: int
    total_input_tokens: int
    total_output_tokens: int
    estimated_cost_usd: float
    duration_hours: float


# 2026年3月時点の価格（Opus 4.6）
PRICING = {
    "opus-4.6": {"input": 15.0 / 1_000_000, "output": 75.0 / 1_000_000},
    "sonnet-4.6": {"input": 3.0 / 1_000_000, "output": 15.0 / 1_000_000},
}


def estimate_cost(
    interval_minutes: int,
    duration_hours: float,
    tokens_per_cycle: int,
    model: str = "sonnet-4.6",
    output_ratio: float = 0.4,
) -> CostEstimate:
    """ループのコストを見積もる。

    Args:
        interval_minutes: ループの間隔（分）
        duration_hours: 総稼働時間
        tokens_per_cycle: 1サイクルあたりの推定トークン数
        model: 使用モデル
        output_ratio: 出力トークンの比率（0.0〜1.0）

    Returns:
        CostEstimate: 見積もり結果
    """
    cycles = int((duration_hours * 60) / interval_minutes)
    input_tokens = int(tokens_per_cycle * (1 - output_ratio))
    output_tokens = int(tokens_per_cycle * output_ratio)

    total_input = cycles * input_tokens
    total_output = cycles * output_tokens

    pricing = PRICING.get(model, PRICING["sonnet-4.6"])
    cost = (total_input * pricing["input"]) + (total_output * pricing["output"])

    return CostEstimate(
        cycles=cycles,
        total_input_tokens=total_input,
        total_output_tokens=total_output,
        estimated_cost_usd=cost,
        duration_hours=duration_hours,
    )


def main() -> None:
    parser = argparse.ArgumentParser(description="Claude /loop コスト見積もり")
    parser.add_argument("--interval", type=int, default=30, help="ループ間隔(分)")
    parser.add_argument("--hours", type=float, default=8.0, help="稼働時間")
    parser.add_argument("--tokens-per-cycle", type=int, default=5000, help="1サイクルのトークン数")
    parser.add_argument("--model", default="sonnet-4.6", choices=PRICING.keys(), help="モデル")
    args = parser.parse_args()

    result = estimate_cost(args.interval, args.hours, args.tokens_per_cycle, args.model)

    print(f"=== Claude /loop コスト見積もり ===")
    print(f"モデル:          {args.model}")
    print(f"間隔:            {args.interval}分")
    print(f"稼働時間:        {result.duration_hours}時間")
    print(f"サイクル数:      {result.cycles}回")
    print(f"総入力トークン:  {result.total_input_tokens:,}")
    print(f"総出力トークン:  {result.total_output_tokens:,}")
    print(f"推定コスト:      ${result.estimated_cost_usd:.2f}")
    print(f"")
    print(f"💡 Pro/Max サブスクリプションなら定額内で収まる可能性あり")
    print(f"   API課金の場合は上記が目安コスト")


if __name__ == "__main__":
    main()

6.3 よくあるトラブルと対処法

#	症状	原因	対処法
1	朝起きたら何も実行されていない	tmuxセッションが死んでいた（OOM等）	cronでセッション死活監視を追加。`tmux has-session` で確認して再起動する
2	`/loop` が動いているのに結果が出ない	Claudeが長時間タスク実行中でスケジュールが遅延	ループ間隔を長めに設定（最低10分推奨）
3	`claude -p` が "Not logged in"	cronの環境変数にAPIキーが渡っていない	crontab内で `ANTHROPIC_API_KEY=xxx` を設定するか、`.env` をsource
4	コストが想定の3倍	Auto Modeのリスク評価でトークン消費増	`--model sonnet` で軽量モデルに切り替え。間隔を長くする
5	ファイルが意図せず削除された	`--dangerously-skip-permissions` + プロンプト・インジェクション	即座にコンテナ化。Hooksでrmを禁止。git管理で復旧
6	`/loop` が3日後に止まった	定期タスクの3日間自動失効仕様	cronで毎日セッションを再作成するハイブリッドパターンを採用
7	複数ループが干渉する	逐次実行のため先のタスクが長引くと後のタスクが遅延	重いタスクは別セッション（別tmuxウィンドウ）に分離

7. ユースケースガイド — 実際にどう使うか

7.1 深夜のテスト自動修復

最も手軽で効果の高いユースケース。「テストが落ちたら直す」を夜通し回す。

# tmuxセッション内で
/loop 30m テストスイートを実行して。失敗したテストがあれば、テストコードではなくプロダクションコードを修正して。修正後にテストを再実行して全部通ることを確認して。通らなかった場合はgit stashして元に戻して。

7.2 PR監視 + 自動修正

オープンなPRに対して、CIの状態を定期チェックし、失敗していれば修正を試みる。

/loop 2h gh pr list --state open をチェックして、CIが失敗しているPRがあれば、そのブランチをチェックアウトして修正を試みて。修正できたらコミット&プッシュして。

7.3 依存パッケージの脆弱性監視

/loop 6h npm audit を実行して。CVEが検出されたら、パッケージのアップデートを試みて。テストが通ることを確認してから vulnerability-fix ブランチにコミット&プッシュしてPRを作って。

7.4 朝のブリーフィング生成

/loop 24h 昨日のgitログから、変更されたファイル、追加/削除された行数、各コミットの要約を含むデイリーレポートを morning-briefing.md に出力して。

8. 学習ロードマップ — 次に何を学ぶべきか

自律開発ワークフローの世界に踏み出したら、以下の順で知識を広げていくと効率的だ。

レベル	トピック	学習リソース
1	/loop の基本操作	この記事のセクション2
2	パーミッション設計	Claude Code Best Practices
3	tmux + cron 永続化	この記事のセクション4
4	Hooks によるガードレール	Hooks Documentation
5	Agent SDK	Agent SDK Guide
6	Multi-Agent Teams	`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` で有効化（実験的機能）

まとめ

Claude Code /loop + Auto Mode + cron/tmux の組み合わせは、「AIに夜勤させる」という一見荒唐無稽な発想を、実用レベルに引き上げてくれる。

正直、最初は半信半疑だった。「寝てる間にAIがコード書くとか、SF映画じゃあるまいし」と。でも実際にtmux + cronでセットアップして、/loop 30m テスト修正 を仕掛けて寝た翌朝、PRが3本生えていたときの衝撃は忘れられない。(;ﾟдﾟ)ﾎﾟｶｰﾝ

もちろん万能ではない。Auto Modeはまだ Research Preview だし、プロンプト・インジェクションのリスクは常に意識する必要がある。コンテナ隔離やHooksによるガードレールなしに本番環境で回すのは、鍵を全部渡して「好きにやって」と言うようなものだ。

ただ、適切なガードレールさえ設計すれば、テスト修復、PR監視、脆弱性チェック、朝のブリーフィング生成といった「人間がやらなくてもいいけどやらないと困る」タスクをAIに委ねられる時代が、もう来ている。

夜勤の警備員は、ちゃんと巡回してくれる。ただし、警備室（tmux）を建て、シフト表（cron）を書き、カードキー（パーミッション設計）を正しく渡すのは、雇い主であるあなたの仕事だ。

参考文献

この記事が参考になったら、いいね・ストックしていただけると励みになります。
他にもAI開発環境やセキュリティに関する記事を書いています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up