OpenClawのビジネス向け環境構築で考える、AIエージェントの倫理とセキュリティ。そしてクローズドループへ

OpenClawのビジネス向け環境構築で考える、AIエージェントの倫理とセキュリティ。そしてクローズドループへ

2026.02.11

はじめに

OpenClawを仕事で使いたいという強い思いから、色々調べて試してきました。AIアシスタントが常駐して、日常のタスクを自律的にこなしてくれる環境を本気で構築したらどうなるか。その実験と実践の記録です。

自宅のMac miniに常駐するAIアシスタントを構築しました。Discordをインターフェースに、音声通話、電話応答、ワークフロー自動化、クラウドインフラ管理まで一通りの機能を持たせています。

この記事では、その構築過程をテーマ別に整理してまとめます。時系列ではなく、機能単位で書いているので、興味のあるパートだけ読んでも成立するようにしています。

使っている主な技術スタックは、OpenClaw、Claude Code、ElevenLabs、Whisper、Twilio、n8n、Terraform、Tailscaleなど。個人開発の規模ですが、セキュリティやIaCも手を抜かずにやっています。

動作環境はMac mini(Apple Silicon)、macOS 26.2です。


第1章 導入編

OpenClawとは

OpenClawは、LLMをエージェントとして常駐させるためのフレームワークです。Discordをフロントエンドにして、ファイル操作、シェル実行、Web検索、ブラウザ操作などを統合的に扱えます。

セットアップ手順

まずHomebrewを入れます。

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'eval "$(/opt/homebrew/bin/brew shellenv zsh)"' >> ~/.zprofile
source ~/.zprofile

Claude Codeのインストール。

curl -fsSL https://claude.ai/install.sh | sh
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

OpenClawのインストール。Node.js関連の依存も全部自動で入ります。

curl -fsSL https://openclaw.ai/install.sh | bash

初回起動(onboardウィザード)

openclaw onboard

聞かれるのは以下の3点です。

  • AIモデルの選択 → anthropic/claude-opus-4-6 を選択
  • 認証 → Claudeにログインしてトークンを取得
  • アシスタントの名前 → 「クロウ」(以降、フロントエンドとなるDiscord/Telegram上のBotをこう呼びます)

claude-opus-4-6 を選んだ理由は、100万トークンのコンテキストウィンドウとコーディング性能の強化に加え、価格がOpus 4の約3分の1(入力$5/出力$25 per 1M tokens)でバランスが良かったためです。

ウィザードが完了するとGatewayデーモンが起動し、SOUL.mdUSER.mdIDENTITY.mdMEMORY.md が自動生成されます。

Gateway started: ws://127.0.0.1:18789 (PID XXXXX)

モデル選定とレスポンス速度のチューニング

初期設定では claude-opus-4-6 を選択しましたが、運用してみるとレスポンスが遅いという問題が出ました。Discordで話しかけてから返答が届くまでに体感で数秒から十数秒かかる場面があり、日常的に使うには厳しい速度です。

原因は3つありました。

  1. Opusモデルの推論速度: Opusは高精度だが重い。日常会話レベルのやりとりにはオーバースペック
  2. 不要なtool call: メモリファイルの読み込みやファイル操作を毎回実行していた
  3. Discord APIの構造的制約: メッセージ送信からWebhook、Gateway、モデル呼び出し、返信という経路の往復遅延はアプリケーション側では短縮できない

対策として、デフォルトモデルを claude-sonnet-4-20250514 に切り替えました。Sonnetは推論速度がOpusの数倍速く、日常会話やタスク指示には十分な精度です。重いタスク(長文生成、複雑なコーディング)にはOpusを明示的に指定する運用にしています。

openclaw config.patch <<'EOF'
{
  "models": {
    "default": "anthropic/claude-sonnet-4-20250514"
  }
}
EOF

併せて、簡単な会話では即答するようSOUL.mdに指示を追加し、メモリファイルの読み込み頻度も最小化しました。体感速度はかなり改善しています。

トリプルフォールバック設定

Anthropic APIにはレート制限があり、連続でタスクを投げるとリクエストが弾かれることがあります。特にサブエージェントを並行実行する場面で顕著です。

対策として、モデルの3段階フォールバックを設定しました。

openclaw config.patch <<'EOF'
{
  "models": {
    "default": "anthropic/claude-sonnet-4-20250514",
    "fallback": [
      "openai/gpt-5.3-codex",
      "google/gemini-2.5-pro"
    ]
  }
}
EOF
  1. Sonnet(Anthropic直接API) — メインモデル。通常はこれで処理
  2. Sonnet via Bedrock(Amazon Bedrock) — Anthropic直接APIが制限にかかった場合の第2候補。同じモデルだが経路が異なるためレート制限が別枠
  3. Codex(OpenAI) — Anthropic系が両方ダメな場合の第3候補
  4. Gemini 2.5 Pro(Google) — 最終手段

Bedrockの活用がポイントです。OpenClawにはBedrockのモデルを自動検出する bedrockDiscovery 機能があり、リージョンを指定するだけで利用可能なモデルが自動的にフォールバック候補に加わります。

{
  "models": {
    "bedrockDiscovery": {
      "enabled": true,
      "region": "us-east-1",
      "providerFilter": ["anthropic"]
    }
  }
}

これにより、Anthropicの直接APIがレート制限にかかっても、同じSonnetモデルがBedrock経由で使えるため、ユーザー体験を落とさずに処理を継続できます。Bedrock側にはClaude Opus、Sonnet、Haikuの各バージョンが揃っているので、実質的にAnthropicモデルの可用性が大幅に向上します。

4社のAPIキーをそれぞれ設定しておく必要がありますが、一度設定すれば自動で切り替わります。実運用では、フォールバックが発動するのはサブエージェントを多用したときくらいです。

ペルソナ設定

OpenClawでは、AIの振る舞いをMarkdownファイルで定義します。

  • SOUL.md — AIの性格、話し方、判断基準を記述するファイル。名前は「クロウ」としました。口調や対応方針、やっていいこと・悪いことの境界線をここで定義します。
  • USER.md — ユーザー自身の情報。好み、技術スタック、仕事の文脈などを書いておくと、AIが的確に応答できるようになります。
  • AGENTS.md — セッション開始時の行動ルール。「まずSOUL.mdを読め」「メモリファイルを確認しろ」といった手順を定義します。

これらのファイルを整備することで、毎回ゼロから文脈を説明し直す必要がなくなります。セッションが切れても、ファイルベースで記憶と人格が復元される設計です。


第2章 コミュニケーション編

Discordで喋れるようにする

Discord Developer Portalでの手動作業が必要なパートです。ここが一番時間がかかりました。

Discord Bot作成の手順

  1. Discord Developer Portalで New Application → 名前を入力
  2. 左メニュー Bot → Add Bot
  3. Privileged Gateway Intents で MESSAGE CONTENT INTENT を ON
  4. Reset Token → トークンをコピー(一度しか表示されないので注意)
  5. 左メニュー OAuth2 → URL Generator → Scopes: bot + applications.commands → Permissions: View Channels / Send Messages / Read Message History / Add Reactions
  6. 生成されたURLをブラウザで開き、自分のサーバーにBotを招待

OpenClawにトークンを設定

openclaw config.patch <<'EOF'
{
  "channels": {
    "discord": {
      "token": "YOUR_DISCORD_BOT_TOKEN"
    }
  }
}
EOF

設定を反映するにはGatewayをリロードします。

kill -SIGUSR1 $(pgrep -f "openclaw gateway")

iPhoneとのペアリング

Discordに入ったクロウにペアリングコードを送ります。自動承認され、iPhoneからDiscord経由でAIアシスタントと会話できるようになります。

Telegramチャネルの追加

Discordだけでなく、Telegram経由でもAIアシスタントにアクセスできるようにしました。マルチチャネル対応にすることで、Discord以外のメッセンジャーからも同じクロウに話しかけられます。

Telegram Botの作成

TelegramのBotFatherで新しいBotを作成します。/newbot コマンドでBot名とユーザー名を指定するだけで、APIトークンが発行されます。

OpenClawへの設定

Telegram連携にはchannelsとpluginsの両方に設定を追加する必要があります。channelsだけ設定してもBotは動きません。

openclaw config.patch <<'EOF'
{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "YOUR_TELEGRAM_BOT_TOKEN",
      "dmPolicy": "pairing"
    }
  },
  "plugins": {
    "entries": {
      "telegram": { "enabled": true }
    }
  }
}
EOF

設定後、Gatewayをリロードするとbotが起動します。

ペアリング

Discordと同様に、Telegramからもペアリングが必要です。Telegram上でBotにメッセージを送ると承認コードが表示されるので、CLIで承認します。

openclaw pairing approve telegram <code>

承認後はTelegramのDMからクロウに直接話しかけられるようになります。Discord側のペアリングとは独立しているので、それぞれ個別に承認が必要です。

使い勝手

DiscordとTelegramのどちらから話しかけても、同じAIアシスタントが応答します。レスポンス速度もほぼ同じで、体感できる差はありません。ボトルネックはLLM APIの推論時間なので、チャネルの違いは誤差の範囲です。

Discordはデスクトップ作業中に、Telegramはモバイルでサッと確認したいときに、という使い分けをしています。

音声機能の実装 — TTS・文字起こし・モデル選定

ElevenLabs TTSとクローンボイス

テキスト読み上げにはElevenLabsを使っています。特徴的なのは、自分の声をクローンしている点です。ElevenLabsの音声クローン機能で自分の声を登録し、AIが応答する際にその声で読み上げるようにしました。

最初はmacOS標準の say コマンドを試しましたが、0バイトのファイルが生成される問題が発生しました。ElevenLabsのAPIに切り替えて解決しています。

openclaw config.patch <<'EOF'
{
  "messages": {
    "tts": {
      "provider": "elevenlabs",
      "elevenlabs": {
        "apiKey": "YOUR_ELEVENLABS_API_KEY"
      }
    }
  }
}
EOF

OpenClawのTTSスキルにvoiceIdを設定するだけで、すべての音声出力がクローンボイスになります。

Whisperによる音声文字起こし

音声入力の文字起こしにはOpenAIのWhisperを使っています。

brew install ffmpeg
pip3 install openai-whisper

モデル別の検証結果です。

  • base / CPU — 約1秒。精度がやや低い
  • large / CPU (FP32) — 数分。精度は高いが遅すぎる
  • large / MPS (Apple Silicon GPU) — 約14秒。短い音声で無言失敗する問題あり
  • medium / CPU (FP32) — 約5秒。精度・速度のバランスが良い

mediumモデル + CPU に落ち着きました。5秒程度で書き起こしが完了し、日本語の精度も実用的です。

OpenClawへの設定は以下の通りです。

{
  tools: {
    media: {
      audio: {
        enabled: true,
        models: [{
          type: "cli",
          command: "/path/to/whisper",
          args: ["--model", "medium", "--language", "ja",
                 "--output_format", "txt", "{{MediaPath}}"],
          timeoutSeconds: 60
        }]
      }
    }
  }
}

設定後はDiscordで音声メッセージを送るだけで、テキストに変換された状態でAIに届きます。

MLX Whisper — Apple Silicon最適化

MLX WhisperはApple Silicon向けに最適化されたWhisper実装です。Metal GPUを活用するため、同じMac mini上でも処理速度が劇的に改善します。

large-v3モデルを使って、数十秒の音声を約3.4秒で高精度に文字起こしできています。CPUベースのWhisperでlargeモデルを動かすと数十秒かかっていたことを考えると、まったく別物です。

導入はpipでインストールするだけ。モデルは初回実行時に自動ダウンロードされます。Apple Siliconを使っているなら、最初からMLX Whisper一択で良いと思います。

電話連携 — Twilioで着信・発信を自動化する

着信フロー

Twilioで電話番号を取得し、着信時に以下の処理を自動実行するようにしました。

  1. 着信を受けてクローンボイスで応答メッセージを再生
  2. 相手の発話を録音
  3. 録音データをWhisperで文字起こし
  4. 文字起こし結果をDiscordに転送

これにより、電話に出られなくても内容がDiscordに届きます。留守番電話の完全自動化です。

発信フロー

逆方向も実装しています。Discordからメッセージを送ると、Twilioが指定番号に発信し、クローンボイスでメッセージを読み上げます。自分の声で電話をかけるAIという、やや奇妙だが実用的な仕組みです。

インフラ面の工夫

TwilioのWebhookはパブリックURLが必要です。Mac miniは自宅にあるので、cloudflaredトンネルを使ってローカルサーバーを公開しています。

運用上の課題として、cloudflaredのトンネルURLが再起動のたびに変わる問題がありました。これに対して以下の自動化を組みました。

  • LaunchAgent でcloudflaredとローカルサーバーをMac mini起動時に自動起動
  • トンネルURL取得後、Twilio APIを叩いてWebhook URLを自動更新

これで再起動しても手作業なしに電話連携が復旧します。


第3章 開発環境編

Docker環境の構築(Colima)

Docker DesktopではなくColimaを使っています。OSSで、ライセンスの心配がなく、CLIベースで扱いやすい。Mac miniのようなヘッドレス環境には向いています。

brew install colima
brew install docker docker-compose

# VM起動(Apple Silicon最適化)
colima start --cpu 2 --memory 4 --disk 20 --vm-type vz

docker-composeプラグインの設定も必要です。

mkdir -p ~/.docker
echo '{"cliPluginsExtraDirs":["/opt/homebrew/lib/docker/cli-plugins"]}' > ~/.docker/config.json

Claude Codeのコンテナ化

Claude Codeをコンテナ内で動かす方法を試行錯誤した結果、以下のパターンに落ち着きました。

  1. sleep infinityで常駐するコンテナを起動
  2. docker execでコンテナ内に入り、claude -pでタスクを実行

公式Dockerイメージがないため、自前でDockerfileを作成しました。

FROM node:22-bookworm-slim
RUN npm install -g @anthropic-ai/claude-code@2.1.37
ENV PATH="/usr/local/share/.config/yarn/global/node_modules/.bin:$PATH"
ENTRYPOINT ["claude"]

APIキーは .env ファイル経由で注入します。常駐コンテナにexecで入る方式は、起動コストを毎回払わなくて済む点がメリットです。

n8nによるワークフロー自動化

n8nのデプロイ

ワークフロー自動化ツールのn8nはdocker-composeでデプロイしました。永続化ボリュームを設定し、再起動してもワークフローが消えないようにしています。

# docker-compose.yml
services:
  n8n:
    image: n8nio/n8n
    ports:
      - "5678:5678"
    environment:
      - TZ=Asia/Tokyo
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n

パスワードは .env ファイルで管理し、gitにはコミットしません。

n8nからDocker API経由で呼び出し

n8nのHTTPリクエストノードからDocker APIを直接叩いて、Claude Codeコンテナにタスクを投げる構成にしました。n8nのワークフロー内でコード生成やレビューを自動実行できます。

Human in the Loopワークフロー

最も実用的だったのが、Human in the Loopパターンです。

  1. n8nのワークフローがClaude Codeにコード生成を依頼
  2. 生成結果をレビューフォームとして提示
  3. 人間が内容を確認し、承認または却下
  4. 承認された場合のみ後続処理(デプロイ等)を実行

AIに全自動で任せるのではなく、重要なポイントで人間の判断を挟む設計です。

n8n REST APIとcookie認証の落とし穴

n8nのREST APIを外部から叩く際、認証でハマりました。n8nはデフォルトでcookieベースの認証を使いますが、N8N_SECURE_COOKIEが有効だとHTTPS以外では認証cookieが送信されません。

ローカル環境でHTTPアクセスしている場合は、環境変数でN8N_SECURE_COOKIE=falseを明示的に設定する必要があります。ドキュメントには書かれていない挙動で、ログにもエラーが出ないため原因特定に時間がかかりました。

開発ツール群

Claude Code — コーディングの実行部隊

Claude Codeはclaude -pの非対話モードで使っています。タスクを文字列で渡すと、ファイルの読み書き、コマンド実行まで含めて自律的に作業してくれます。

OpenClaw(クロウ)がユーザーとの会話・タスク分解・成果物レビューを担当し、Claude Codeが実際のコーディング・テスト・ビルドを担当します。「TODOアプリ作って」と言えば、クロウが要件を整理してClaude Codeに投げ、結果を確認して返してくれます。

OpenClawからの呼び出し、n8nワークフローからの呼び出し、直接CLIでの利用と、複数の経路で使い分けています。

Codex CLI — セカンドオピニオン

OpenAIのCodex CLIをセカンドオピニオンとして使っています。GPT系のモデル(GPT-5.3-Codex)でコードレビューを行い、Claude Codeの出力とクロスチェックします。Claude Codeが書いたコードを同じモデルにレビューさせても、同じバイアスが残るためです。

brew install --cask codex
codex login  # ChatGPTアカウントでログイン

diffベースでレビューできるので、「直前のコミットをレビューして」という使い方が便利です。

codex review --base HEAD~1

異なるモデルの視点を入れることで、片方が見落とすパターンを拾えます。

実際のレビュー結果

TODOアプリのソースコードをCodexにレビューさせたところ、以下の指摘がありました。

  1. タイムゾーンバグ: new Date('YYYY-MM-DD') がUTC解釈されて日付が1日ズレる可能性。parseISO に統一すべき
  2. 完了日の集計ミス: 週間完了数が updatedAt に依存しており、完了後の編集でもカウントされる。completedAt フィールドの追加が必要
  3. LocalStorageのバリデーション不足: 壊れたデータで実行時エラー。zodでスキーマ検証を入れるべき
  4. テーマ切替でクラス破壊: className = ... で全クラスを上書き。classList.toggle に修正すべき
  5. テスト不足: フィルタ・ソート・永続化にVitestでテスト追加すべき

タイムゾーンバグのような実運用で踏む問題を事前に発見できました。

運用フロー
  1. Claude Codeで成果物を作る
  2. Codexでレビュー(codex exec "レビューして" or codex review --base HEAD~1
  3. 指摘事項をClaude Codeで修正

gog CLI — GmailとGoogleカレンダー操作

Google Workspace CLI(gog)を導入し、AIアシスタントがメール確認やスケジュール参照に使えるようにしました。

brew install steipete/tap/gogcli

GCPでOAuthクライアントを作成し、クレデンシャルを登録します。

gog auth credentials set credentials.json
gog auth add your-email@example.com

OAuth同意画面のテストユーザー設定を忘れると403エラーになるので注意です。

OpenClawと組み合わせれば「未読メールある?」「今日13時にMTG入れて」と言うだけで実行してくれます。

Puppeteer — スクリーンショット取得

Mac miniはヘッドレスなので、Webページの見た目を確認する手段としてpuppeteerを使っています。puppeteerでモバイルサイズのスクリーンショットを撮影し、Discordに送ることで成果物を視覚的に確認できます。

Playwright — ブラウザ自動化

OpenClawのブラウザ操作機能で内部的に使われています。スクリーンショット取得やDOM操作をヘッドレスで実行できます。

npm install @playwright/test
npx playwright install chromium

Chromiumだけ入れれば十分です。puppeteerと役割が重なりますが、OpenClawとの統合はPlaywright側で行われているため、両方入れています。

xAI Grok API — SNS検索とWeb検索

xAIのResponses APIを使い、Grok経由でX(Twitter)の投稿検索とWeb検索を実行できるようにしました。OpenClawの検索機能を補完する位置づけです。

Responses APIにはビルトインツールとして x_search(X投稿検索)と web_search(Web検索)が用意されています。APIにツール指定付きでリクエストを投げると、Grokがリアルタイムで検索を実行し、結果を要約して返します。

技術的なポイントは以下の通りです。

  • エンドポイント: https://api.x.ai/v1/responses
  • モデル: grok-4-1-fast-reasoning を使用。サーバーサイドツール(x_search、web_search)はgrok-4ファミリー以降のモデルでないと動作しない。grok-3系では非対応
  • 認証: XAI_API_KEY 環境変数でAPIキーを渡す
  • x_searchの絞り込み: allowed_x_handlesfrom_dateto_date などのパラメータで検索対象を制限できる

CLIから手軽に呼べるようにシェルスクリプトを作成しました。

curl -s "https://api.x.ai/v1/responses" \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-4-1-fast-reasoning",
    "tools": [{"type": "x_search"}],
    "input": "検索クエリ"
  }'

x_searchweb_search に差し替えれば、一般的なWeb検索も同じ要領で実行できます。

実際に「OpenClawについてXの投稿を検索して要約」と投げたところ、Grokがリアルタイムで関連投稿を検索し、引用URL付きで要約を返しました。SNS上のリアルタイムな反応を拾えるのは、通常のWeb検索にはない強みです。


第4章 インフラ編

EC2とTailscaleによるゼロトラスト構成

AWSにはEC2インスタンスを1台立てています。スペックはt4g.nano。ARM(Graviton)で、月数ドルの最小構成です。

特徴的なのはセキュリティグループの設定で、インバウンドルールを完全に閉鎖しています。SSH含め、外部からのアクセスは一切許可していません。

aws ec2 revoke-security-group-ingress \
  --group-id sg-XXXXXXXXXXXXXXXXX \
  --ip-permissions '[全ルール]'

代わりにTailscaleを使って、VPN経由でのみアクセスする構成にしています。セキュリティグループが空なので、ポートスキャンされても何も見えません。

AWS CLIのセットアップ

brew install awscli
aws configure

最初はIAM Identity Center(旧SSO)を試みましたが、メンバーアカウントからのセットアップでエラーになったため、IAMアクセスキー方式に切り替えました。その後、Keychain連携で平文ファイルを排除する対応を行っています(第5章で詳述)。

EC2にTailscaleを導入

# EC2上で実行
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

SSH接続はTailscale経由で行います。

# ~/.ssh/config
Host my-ec2
  HostName 100.x.x.x
  User ec2-user
  IdentityFile ~/.ssh/my-keypair.pem
  ProxyCommand tailscale nc %h %p

Terraform v1.5.7でIaC化

インフラはTerraformで管理しています。バージョンはv1.5.7を明示的に選んでいます。これはHashiCorpがBSLライセンスに移行する前の、最後のMPL(オープンソース)バージョンです。

brew install terraform

Homebrewで配布されているのがこの最終OSSバージョンです。OpenTofuへの移行も選択肢にありますが、現時点ではv1.5.7で問題なく動いているのでそのまま使っています。

プロジェクト構成

infra/ ディレクトリに以下の構成で作成しました。

infra/
├── main.tf        # provider設定
├── variables.tf   # 変数定義
├── ec2.tf         # EC2 + セキュリティグループ
└── outputs.tf     # 出力定義

既存リソースのimport

稼働中のEC2とセキュリティグループを terraform import で取り込みました。

terraform import aws_instance.claw_dev i-XXXXXXXXXXXXXXXXX
terraform import aws_security_group.claw_dev_sg sg-XXXXXXXXXXXXXXXXX

importした直後の terraform plan では差分が出ます。2点ハマりました。

AMIの差分: Terraformが最新のAMI IDを参照しようとし、既存インスタンスのAMIと異なるためreplace(再作成)判定になりました。AMI IDを変数化し、既存のAMI IDを指定することで解決しています。

セキュリティグループのdescription: コードに書いたdescriptionと実際のdescriptionが異なるとreplace強制になります。AWS上の既存descriptionに合わせて解決しました。

# 差分ゼロを確認
terraform plan
# No changes. Your infrastructure matches the configuration.

destroy 0を確認してから terraform apply を実行しました。GitHubにはprivateリポジトリとしてpushしています。

二段構えのセキュリティスキャン

IaCのセキュリティには2つのツールを組み合わせています。

  • tfsec — Terraformコードの静的解析。デプロイ前にセキュリティリスクを検出
  • Prowler — AWSアカウントのランタイムCSPM。実際のリソース状態をスキャン

tfsecが「設計図のチェック」、Prowlerが「完成品のチェック」という関係です。両方やることで、コードと実環境のギャップを検出できます。

tfsecの実行

brew install tfsec
tfsec infra/

3件検出されました。

  • CRITICAL: egress 0.0.0.0/0(全宛先許可) → Tailscale通信に必要なためignoreコメントで明示許可
  • HIGH: IMDSv2が未強制 → metadata_options ブロックを追加
  • HIGH: EBSルートボリュームが暗号化されていない → root_block_device ブロックで暗号化を指定

修正後に再実行したところ、全パスしました。

No problems detected!

Prowlerの実行

pip3 install prowler
prowler aws

70チェックを実行し、19件FAIL(HIGH 6, MEDIUM 10, LOW 3)でした。主な対応として、EBSデフォルト暗号化を有効化しました。

aws ec2 enable-ebs-encryption-by-default --region ap-northeast-1

IMDSv2の強制やEBS暗号化はTerraformコードに追加済みです。既存インスタンスへの適用はEC2再作成時になります。

その他のハードニング

  • EBSデフォルト暗号化 — リージョン設定で有効化。新規作成されるEBSボリュームがすべて自動暗号化されます
  • IMDSv2強制 — インスタンスメタデータサービスをv2のみに制限。SSRF攻撃によるクレデンシャル窃取を防ぎます

クラウドコスト管理

AWS Cost Explorer CLIでコストを分析しました。

aws ce get-cost-and-usage \
  --time-period Start=2025-02-01,End=2025-02-10 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

合計 $9.34(月ペースで約$28)でした。内訳は以下の通りです。

  • QuickSight: $3.68
  • EC2: $2.21
  • VPC: $1.03
  • その他: $2.42

AWS Budgetsでアラート設定

月額$50を超えたら通知が飛ぶようにAWS Budgetsを設定しました。80%到達時と100%到達時の2段階でメール通知されます。


第5章 セキュリティ編

この章では、個人開発環境のセキュリティをどこまで真面目にやるか、という問いに対する実践記録をまとめます。結論から言うと、やればやるほど穴が見つかるので、フレームワークを使って体系的に潰すのが正解でした。

Mac miniのセキュリティ監査

常駐マシンであるMac mini自体のセキュリティも確認しました。

openclaw security audit --deep

実行したところ、FileVaultはON、Time Machineは設定済みでしたが、ファイアウォールがOFFでした。OpenClawが自動でONに設定しました。

  • FileVault — ディスク暗号化が有効であることを確認
  • ファイアウォール — macOSのアプリケーションファイアウォールを有効化
  • SIP(System Integrity Protection) — 有効であることを確認。カーネル拡張やシステムファイルの改変を防止する仕組みで、無効化は厳禁です
  • 不要なサービスの停止、共有設定の確認

Tailscale VPNによるゼロトラストネットワーク

WireGuardベースのメッシュVPNです。基本的にP2P直接接続で、多くの場合データはTailscale社のサーバーを経由しません。ポート開放不要、個人利用無料(100デバイスまで)。

# CLIバージョンをインストール(cask版はsudo必要)
brew install tailscale

# デーモン起動(userspace-networkingモード、root不要)
tailscaled --tun=userspace-networking \
  --state=$HOME/.tailscale/tailscaled.state \
  --socket=$HOME/.tailscale/tailscaled.sock &

# ログイン(ブラウザで認証)
tailscale --socket=$HOME/.tailscale/tailscaled.sock up

ヘッドレス環境ではcask版(GUI)がsudo必要で使えないため、CLI版 + --tun=userspace-networking が正解です。

Tailscaleで以下の3台をメッシュ接続しています。

  • Mac mini(自宅、AIアシスタント常駐)
  • iPhone(モバイルアクセス用)
  • EC2インスタンス(AWS)

すべてのデバイス間通信がWireGuardベースの暗号化トンネルを経由します。パブリックIPを晒す必要がないので、攻撃対象面が大幅に減ります。

ハマりポイント:ファイアウォールとの共存

Tailscale経由でdevサーバーにアクセスしたところ、レスポンスが空(HTTP 000)になりました。macOSファイアウォールがNode.jsへの着信をブロックしていたのが原因で、socketfilterfw --unblockapp で解決しています。

ただし、Node.jsの着信を常時許可しておくのはセキュリティ上望ましくありません。Node.jsに脆弱性が見つかった場合、Tailscale VPN内のデバイスが侵害されていると攻撃経路になり得ます。開発時のみ許可し、終了後はブロックに戻す運用を推奨します。

# 開発時のみ許可
sudo socketfilterfw --unblockapp $(which node)
# 終了後にブロックに戻す
sudo socketfilterfw --blockapp $(which node)

セキュリティ第一原則とAI行動ルール

運用ルールとして「セキュリティ第一原則」を策定しました。具体的には以下のような方針です。

  • 新しいサービスを追加する前にセキュリティ影響を評価する
  • 認証情報はファイルに書かず、環境変数または専用の秘密管理を使う
  • 公開エンドポイントは最小限にする
  • 判断に迷ったら安全側に倒す

AIアシスタントのSOUL.mdにもこの原則を組み込み、AIが判断する際にもセキュリティを優先するようにしています。

OpenClawではAIの行動ルールを TOOLS.mdMEMORY.md にファイルとして書きます。口頭で伝えたルールはセッションが変わると忘れますが、ファイルは永続します。

設定した鉄則は以下の通りです。

  • クレデンシャルファイルの直接読み取り禁止(CLIツール経由は可)
  • クレデンシャルの外部送信禁止(git push、API、チャット等あらゆる手段)
  • GitHubリポジトリは必ずprivate
  • パスワード・トークンは絶対にコミットしない
  • 外部アカウント作成・購入は事前確認
  • 外部システムへの書き込み・削除は事前確認
  • ファイル削除は rm 禁止、trash を使用

macOS自動アップデートの有効化

常駐マシンのOSを最新に保つことは基本中の基本です。macOSの自動アップデート設定を確認したところ、セキュリティアップデートの自動インストールが無効になっていました。

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticallyInstallMacOSUpdates -bool true
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CriticalUpdateInstall -bool true

これにより、重要なセキュリティパッチが自動適用されます。CIS Controls v8のControl 4(セキュア設定)の要件を満たすための基本対策です。

秘密情報のmacOS Keychain一元管理

セキュリティフレームワークの策定過程で、秘密情報の管理に大きな問題があることが分かりました。APIキーやトークンが ~/.zshrc に平文で書かれていたのです。シェルを開くたびにexportされる便利さはありますが、セキュリティ上は最悪の状態です。

対策として、すべての秘密情報をmacOS Keychainに移行しました。

Keychainへの登録

security add-generic-password -s "ANTHROPIC_API_KEY" -a "claw" -w "sk-ant-..."
security add-generic-password -s "TWILIO_ACCOUNT_SID" -a "claw" -w "AC..."
# 他のキーも同様

Keychainヘルパースクリプト

Keychainから必要なキーを取得してexportするヘルパーを作りました。

#!/bin/bash
# keychain-env.sh
get_secret() {
  security find-generic-password -s "$1" -a "claw" -w 2>/dev/null
}

for key in XAI_API_KEY ANTHROPIC_API_KEY TWILIO_ACCOUNT_SID TWILIO_AUTH_TOKEN; do
  val=$(get_secret "$key")
  [ -n "$val" ] && echo "export ${key}=\"${val}\""
done

source <(./keychain-env.sh) で環境変数にロードします。~/.zshrc には平文のキーを一切書かなくなりました。

AWS credential_processとの連携

AWSの認証情報も同様にKeychainに移行しました。~/.aws/credentials に平文でアクセスキーを書く代わりに、credential_process を使ってKeychain経由で動的に取得します。

#!/bin/bash
# aws-keychain-helper.sh
KEY_ID=$(security find-generic-password -s "AWS_ACCESS_KEY_ID" -a "claw" -w)
SECRET=$(security find-generic-password -s "AWS_SECRET_ACCESS_KEY" -a "claw" -w)

cat << EOF
{
  "Version": 1,
  "AccessKeyId": "$KEY_ID",
  "SecretAccessKey": "$SECRET"
}
EOF

~/.aws/config にcredential_processとして登録するだけで、AWS CLIやTerraformが透過的にKeychainから認証情報を取得します。

Docker .envの動的生成

Dockerコンテナに渡す .env ファイルも、Keychainから動的に生成するようにしました。gitにコミットされるリスクがゼロになります。コンテナ起動前にヘルパースクリプトで .env を生成し、起動後に削除するフローです。

依存パッケージの脆弱性対応

セットアップが一段落した後、brew outdatedとpipの脆弱性チェックを実施しました。常駐マシンなので、既知の脆弱性を放置するわけにはいきません。

まずHomebrewパッケージの更新です。

brew update && brew upgrade

次にPythonパッケージの脆弱性対応です。pip auditで検出された問題を修正しました。

pip3 install --upgrade cryptography urllib3 pip setuptools wheel future

主な更新内容は以下の通りです。

  • cryptography 44.0.1→46.0.5 — CVE修正を含むメジャーアップデート
  • urllib3 →2.6.3 — セキュリティ修正
  • pip →26.0.1、setuptools →82.0.0 — それぞれ脆弱性修正

注意点として、cryptographyのメジャーバージョンを上げるとProwlerやpyOpenSSLなど一部ツールで非互換の警告が出ます。セキュリティ修正を優先してアップグレードし、警告が出るツールは動作確認した上でそのまま使っています。

セキュリティ検知体制

防御だけでは不十分で、異常を検知する仕組みが必要です。以下の監視スクリプトをcronで自動実行しています。

ネットワーク監視(30分間隔)

lsof -i -nP で外部接続を監視し、既知のプロセス(Discord、Telegram、cloudflared、tailscaled等)以外の不審な接続を検知します。リスニングポートのベースラインも管理しており、新しいポートが開いた場合にアラートを出します。

ファイル改ざん検知(SHA-256)

OpenClawの設定ファイル、~/.zshrc~/.aws/config~/.ssh/config/etc/hosts など重要ファイルのSHA-256ハッシュをベースラインとして記録し、変更があれば即座に検知します。初回実行でベースラインを作成し、以降は差分を検知してアラートログに記録する仕組みです。

ログ集約と保持ポリシー

セキュリティログの集約スクリプトを日次で実行しています。各監視スクリプトの出力、macOSのセキュリティ状態(FileVault、ファイアウォール、SIP)、Tailscaleの接続状態をまとめて日次サマリーを生成します。

保持ポリシーは以下の通りです。

  • 監視ログ: 30日保持、以降アーカイブディレクトリに移動
  • アーカイブ: 90日保持、以降削除

Trivy導入 — Dockerイメージ脆弱性スキャン

ローカルのDockerイメージに既知の脆弱性が含まれていないかを確認するため、Trivyを導入しました。

brew install trivy

週次のcronジョブで全ローカルイメージをスキャンし、CRITICAL/HIGHの脆弱性があればアラートログに記録します。スキャン対象はn8n、Claude Code用のNode.jsイメージなど、稼働中のコンテナイメージすべてです。

Semgrep導入 — 静的コード解析(SAST)

自前で書いたコードのセキュリティチェックとして、Semgrepを導入しました。

pip3 install semgrep

Semgrepはルールベースの静的解析ツールで、--config auto で言語に応じたルールセットが自動選択されます。週次でtodo-apptwilio-servertoolsディレクトリをスキャンし、ERROR以上の検出があればアラートを出します。

tfsecがインフラコードの静的解析なら、Semgrepはアプリケーションコードの静的解析という位置づけです。

ソフトウェア資産棚卸しの自動化

CIS Controls v8のControl 2(ソフトウェア資産のインベントリと管理)に対応するため、ソフトウェア資産の自動棚卸しスクリプトを作りました。

対象は以下の4カテゴリです。

  • Homebrew — formula と cask の全パッケージとバージョン
  • Python — pip listの全パッケージ(Python 3.9 / 3.13両方)
  • npm — グローバルインストールされたパッケージ
  • Docker — ローカルに存在するイメージとID

初回実行でベースラインを作成し、以降は差分を検知します。意図しないパッケージの追加や削除を把握できるようになりました。

週次セキュリティ監査の自動化

cronジョブで週次のセキュリティ監査を自動実行しています。毎週月曜9:00に実行し、結果をDiscordに通知します。チェック内容は以下の通りです。

  • macOSのセキュリティ設定(FileVault、ファイアウォール、SIP)
  • 不要なlistenポートの検出
  • Tailscaleの接続状態
  • AWS側のProwlerスキャン

結果はファイルに出力され、異常があればDiscord経由で通知が来ます。

NIST CSF 2.0 + CIS Controls v8 フレームワーク策定

ツール単体のスキャンだけでは、何をどこまで守れているのかの全体像が見えません。そこで、NIST Cybersecurity Framework 2.0をベースにしたセキュリティフレームワークを策定しました。

NIST CSF 2.0は6つの機能(GOVERN、IDENTIFY、PROTECT、DETECT、RESPOND、RECOVER)でセキュリティ活動を整理するフレームワークです。企業向けに設計されていますが、個人環境にスケールダウンして適用しました。補助的にCIS Controls v8も参照し、具体的な対策の抜け漏れをチェックしています。

評価結果

各機能の成熟度を4段階(Tier 1〜4)で評価した結果は以下の通りです。

  • GOVERN(ガバナンス): Tier 2 — ポリシーは文書化済みだが定期レビューが未実施
  • IDENTIFY(識別): Tier 2 — 資産・リスクは把握済み、データフロー図は別途作成
  • PROTECT(防御): Tier 3 — 最も成熟。Tailscale、FileVault、tfsec、日次スキャン等が稼働
  • DETECT(検知): Tier 2 — 30分間隔の自動監視とログ集約を実装
  • RESPOND(対応): Tier 2 — 手順は文書化済み、訓練は未実施
  • RECOVER(復旧): Tier 1 — Git/Terraformでの復元は可能、バックアップ体制は弱い

55%から80%への改善過程

CIS Controls v8のIG1(基本的サイバーハイジーン)達成率は、初回評価時は55%程度でした。主な弱点は以下でした。

  • 秘密情報が ~/.zshrc に平文で散在(CIS 5: アカウント管理)
  • リアルタイム検知の仕組みがない(CIS 13: ネットワーク監視)
  • ログの集約・保持ポリシーが未定義(CIS 8: 監査ログ管理)
  • ソフトウェアインベントリが手動(CIS 2: ソフトウェア資産管理)
  • Dockerイメージのスキャンなし(CIS 10: マルウェア防御)
  • アプリケーションコードの静的解析なし(CIS 16: アプリケーションセキュリティ)

これらを本章で述べた対策で順次潰していった結果、IG1達成率は約85%、全体スコアは約76%まで改善しました。残る課題はTime Machineバックアップの整備(RECOVER)とインシデント対応訓練(RESPOND)です。

データフロー図

システム全体のデータの流れを文書化しました。以下は概要です。

[ユーザー] <-> [Discord/Telegram] <-> [OpenClaw Gateway] <-> [LLM APIs]
                                            |
                                      [Mac mini ローカル]
                                       |- Keychain (秘密情報)
                                       |- Workspace (コード・設定)
                                       |- MLX Whisper (音声->テキスト)
                                       |- ElevenLabs API (テキスト->音声)
                                       |- Docker
                                           |- n8n (ワークフロー)
                                           |- Claude Code (コード実行)

外部サービスとの連携ごとに、送信データ・受信データ・認証方法・暗号化方式を整理しています。たとえばAWS関連はKeychain経由のcredential_processで認証し、Tailscale VPN経由でのみ通信します。音声データはMLX Whisperでローカル処理され、外部には送信されません。

データ分類も定義しました。

  • 機密: APIキー、トークン、SSH鍵 — macOS Keychain + FileVault暗号化
  • 重要: ワークスペース、MEMORY.md、Terraformステート — FileVault + GitHub private
  • 一般: 会話ログ、生成コンテンツ — FileVault

インシデント対応テンプレート

万が一の事態に備えて、インシデント対応記録のテンプレートを作成しました。記録すべき項目は以下の通りです。

  • 基本情報: インシデントID、検知日時、重大度、ステータス
  • 分類: 種別(不正アクセス、クレデンシャル漏洩、設定ミス等)、影響範囲
  • タイムライン: 検知から対応完了までの時系列記録
  • 対応内容: 封じ込め、根絶、復旧の各フェーズ
  • 根本原因分析と再発防止策
  • 証拠保全チェックリスト

個人環境でここまでやるのは過剰に見えるかもしれませんが、インシデントが起きたときに「何をどの順番でやるか」が決まっていると、パニックにならずに済みます。

Git SSH署名

コミットの真正性を担保するため、Git SSH署名を設定しました。

ssh-keygen -t ed25519 -f ~/.ssh/git-signing-key -C "git-signing"

Gitの設定に以下を追加します。

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/git-signing-key.pub
git config --global commit.gpgsign true

これにより、すべてのコミットにSSH署名が付与されます。第三者がコミットを改ざんした場合、署名検証で検出できます。GitHub上で「Verified」バッジが表示されるようにするには、公開鍵をGitHubに登録する必要があります。


第6章 運用編

証跡管理

すべてのセットアップ作業や設定変更は、以下のファイルに記録しています。

  • OPS.md — 運用ログ。何をいつ変更したかの時系列記録
  • setup/environment.md — 環境構成のスナップショット。インストール済みツール、バージョン、設定値の一覧
  • 日次ログmemory/YYYY-MM-DD.md)— 指示内容、実行コマンド、結果、判断理由をセットで記録
  • 障害記録 — 症状、原因、対処、再発防止をテンプレート化

「1ヶ月前に何をしたか」を振り返れる状態にしておくことは、個人開発でも重要です。特にAIアシスタントと協働する場合、AIが過去の文脈を参照できるようにしておくと作業効率が上がります。

LaunchAgentによる自動復旧

Mac miniは常駐環境なので、再起動後にサービスが自動復旧する仕組みが必要です。macOSのLaunchAgentを使い、OpenClaw Gatewayを自動起動するよう設定しました。

<!-- ~/Library/LaunchAgents/ai.openclaw.gateway.plist -->
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>ai.openclaw.gateway</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/openclaw</string>
    <string>gateway</string>
    <string>run</string>
  </array>
  <key>KeepAlive</key>
  <true/>
  <key>RunAtLoad</key>
  <true/>
  <key>StandardOutPath</key>
  <string>/tmp/openclaw-gateway.log</string>
  <key>StandardErrorPath</key>
  <string>/tmp/openclaw-gateway.err</string>
</dict>
</plist>

ポイントは KeepAlivetrue にしている点です。Gatewayプロセスがクラッシュしても、macOSが自動的に再起動してくれます。gateway run はフォアグラウンドで実行するサブコマンドで、LaunchAgentとの相性が良い。gateway start だとデーモンとしてforkするため、LaunchAgentが「プロセスが終了した」と判断して無限再起動ループに入る問題がありました。

launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plist

これでMac miniを再起動しても、ログイン後にGatewayが自動で立ち上がります。

日次メモリ管理

OpenClawのメモリシステムは2層構造になっています。

  • memory/YYYY-MM-DD.md — 日次の作業ログ。その日に何をしたか、何が起きたかの生記録
  • MEMORY.md — 長期記憶。日次ログから重要な決定や学びを抽出して蓄積

AIは毎セッション開始時にこれらを読み込みます。日次ファイルは直近数日分、MEMORY.mdは常に参照されます。人間の日記と長期記憶の関係に近い設計です。

定期的にAI自身がメモリの整理を行い、古くなった情報を削除し、重要な知見をMEMORY.mdに昇格させます。

HEARTBEAT.mdの活用

OpenClawには定期的にAIをポーリングする仕組み(ハートビート)があります。HEARTBEAT.mdにチェックリストを書いておくと、AIが自律的にタスクを実行します。

活用例としては、メールの未読チェック、カレンダーの予定確認、セキュリティスキャンの実行結果確認などです。人間が指示しなくても、AIが定期的に巡回して異常があれば報告してくれます。


第7章 デモ・実績

TODOアプリ

環境の動作確認を兼ねて、TODOアプリを作りました。「モバイルで、デザインはモダンで、技術はReactで、機能は豊富で。」この一言からクロウが要件を展開し、React + TypeScript + Vite + Tailwind CSSで15機能のアプリを約3分でビルドしました。

src/
├── types/todo.ts          # 型定義(Todo, SubTask, Priority, Category)
├── store/todoStore.ts     # LocalStorage永続化 + CRUD + フィルタ/ソート
├── components/
│   ├── TodoItem.tsx       # スワイプ対応カード型タスク表示
│   ├── AddTodoModal.tsx   # タスク追加/編集モーダル
│   ├── TodoList.tsx       # 検索・フィルタ・ソート・進捗バー付き一覧
│   ├── Dashboard.tsx      # 統計(完了率・カテゴリ別バーチャート・週間推移)
│   ├── BottomNav.tsx      # 3タブナビゲーション
│   └── Settings.tsx       # ダーク/ライトモード切替
├── App.tsx                # ルーティング + FAB
└── index.css              # Tailwind + CSS変数(ダーク/ライト)

型定義も含めたTypeScriptコードが出てくるので、そのままビルドが通ります。puppeteerでモバイルサイズのスクリーンショットを撮影してDiscordに送ることで成果物を確認しました。

企業調査レポート

「クラスメソッドについて調査して」と頼んだところ、サブエージェントがWeb調査を並行実行し、python-pptxでPowerPoint資料を自動生成しました。企業概要、AWS実績、売上推移、競合比較の10スライド構成、所要時間は約2分です。

採用ページデザイン

「クラスメソッドの採用ページをデザインして」で、3パターンのHTML(モダン/ダーク/カジュアル)が生成されました。puppeteerでスクリーンショットを撮影してDiscordに送信する流れも自動です。

最初はClaude Codeを直接呼び出しましたが、初回のブラウザ認証でヘッドレス環境では失敗しました。OpenClawのサブエージェント機能に切り替えて解決しています。

名刺アプリ

名刺表示用のWebアプリも作りました。こちらもClaude Codeで生成しています。デザインの調整指示を何度か出して、納得のいく見た目にするまでのイテレーションが早いのが印象的でした。

これらのデモプロジェクトを通じて、ツールチェーンが正しく動作していること、AIによるコード生成の実用性を確認しています。


第8章 メタ体験

AIにブログを書かせるということ

このブログ記事自体、クロウが書いています。「昨日やったことブログにまとめて」と一言伝えたら、シェル履歴・Gatewayログ・ファイルのタイムスタンプを自分で調べてタイムラインを再構成し、記事を書いてGitHubにpushしました。修正指示も「ワンライナーだったな」「参考リンク足して」と言うだけで即反映されます。


まとめ

Mac mini 1台にAIアシスタントを常駐させ、以下の機能を構築しました。

  • Discord・Telegram経由での対話とタスク実行
  • クローンボイスによる音声応答と電話連携
  • Docker上でのワークフロー自動化(n8n + Claude Code)
  • TerraformによるAWSインフラ管理
  • ゼロトラストネットワーク(Tailscale)と多層セキュリティ
  • NIST CSF 2.0に基づくセキュリティフレームワーク
  • Keychain一元管理、検知体制、SAST/コンテナスキャン
  • ファイルベースの記憶と自律的な運用

すべてを1台のMac miniで動かしているので、ランニングコストは電気代とAPI利用料、Twilioの電話番号維持費程度です。

この構成の要点は、「AIに何でもやらせる」のではなく、「AIが自律的に動ける範囲を明確に設計する」ことだと感じています。ペルソナ定義、セキュリティ原則、Human in the Loopの仕組み、すべてがAIの行動範囲を適切に制約するためのものです。

自由にやらせすぎると事故が起きるし、制約が強すぎると使い物にならない。そのバランスを、設定ファイルとワークフローで表現するのがOpenClawの設計思想であり、今回の構築で最も学びが大きかった部分です。

実際に仕事で使えるのか

結論から言えば、使えます。ただし「AIに全部任せる」ではなく「AIをチームメンバーとして使う」という前提です。

3日間の構築で実用性を確認できた領域は以下の通りです。

  • 調査・レポート作成: 企業調査からPowerPoint自動生成まで、実用レベルの出力が得られる
  • コード生成・レビュー: Claude CodeとCodex CLIのクロスチェックで、単一モデルでは見落とすバグを事前に検出できる
  • 定型作業の自動化: n8nとHuman in the Loopの組み合わせで、承認フロー付きの自動化が構築できる
  • 情報収集: メール確認、カレンダー参照、Web検索、SNS検索を自然言語で指示するだけで実行される
  • インフラ管理: TerraformによるIaCとセキュリティスキャンの自動化で、手作業のミスを排除できる

一方、仕事で使う場合に検討が必要な点もあります。

  • 機密情報の取り扱い: 社内データをLLM APIに送信することの是非は、組織のポリシーに依存する。ローカルLLMとの併用も選択肢に入る
  • レスポンス速度: リアルタイムの会議中に使うには遅い。バックグラウンドでの調査や準備作業に向いている
  • 精度の保証: 最終的なチェックは人間が行う前提で設計すべき。Human in the Loopは便利な機能ではなく、必須の安全装置

指示→実行→レビュー→承認のサイクルを回せる仕組みは、3日で構築できました。AIアシスタントは万能な代替要員ではありません。本来持っている力を引き出すための設計が必要な存在です。ペルソナ定義、フォールバック設計、セキュリティ原則、Human in the Loop。これらはAIを制約するためのものではなく、AIが最大限の力を発揮できる環境を整えるためのものです。

同時に、倫理に反することはさせない。人間が判断の中心にいる。これは譲れない前提です。AIの力を最大化することと、人間中心の設計を貫くことは矛盾しません。むしろ、その両立こそが実用的なAIアシスタント環境の本質だと、3日間の構築を通じて実感しています。

次のステップ — AIによるクローズドループ

ここまでの構築で、万全のセキュリティ、倫理原則、人間中心の設計が整いました。しかし正直に言えば、ひとつのジレンマがあります。人間がループの中に入ると、遅くなるのです。

Human in the Loopは安全装置として必須です。ただし、すべてのタスクに人間の承認を求めていては、AIアシスタントの本来の力を活かしきれません。セキュリティスキャンの結果確認、定型レポートの生成、依存パッケージの更新。これらは判断基準が明確で、AIが自律的に完結できる領域です。

次に目指すのは、AIによるクローズドループの構築です。人間が介入しなくても安全に回せるタスクを特定し、そこだけを完全自動化する。セキュリティフレームワークと行動ルールが整備された今だからこそ、AIに任せる範囲を段階的に広げることができます。

人間は重要な判断に集中し、定型的な作業はAIが自律的に回す。そのバランスポイントを見つけることが、劇的な生産性向上への鍵だと考えています。


クラスメソッド社では、AIをフル活用したい元気な若手エンジニアを募集しています。あらゆる技術を駆使して、新しい時代の波を乗りこなしましょう。

https://careers.classmethod.jp/

参考リンク


環境: Mac mini (Apple Silicon) / macOS 26.2 / OpenClaw v2026.2.6-3 / Tailscale v1.94.1 / Colima v0.10.0 / Docker v28.4.0 / Codex CLI v0.98.0 / AWS CLI v2.33.18 / Terraform v1.5.7 / tfsec v1.28.14 / Prowler v5.18.1 / Trivy / Semgrep v1.151.0

この記事をシェアする

FacebookHatena blogX

関連記事