J.A.R.V.I.S.計画第二十九話

小さく始めるAIエージェント

CodexのComputer Useを入口に、OpenClawでチャネル・サーバー・遠隔デバイスへ広げる

AIエージェントは、いきなり全社導入しなくても始められます。まずはCodexのComputer Useで、目の前のパソコンをAIに操作させる。そこから、OpenClawでチャット、サーバー、カメラ、音声、複数デバイスへ広げます。

今回のテーマは、ジャービス計画第二十九話として「小さく始めるAIエージェント」を技術寄りに整理することです。結論から言うと、最小構成はCodexサブスクとComputer Useです。macOSまたはWindows上でCodexが画面を見て、クリックし、入力し、ブラウザやアプリを操作する入口としては、これが最も軽い始め方です。

ただし、他のコンピュータも操作したい、サーバーの点検をさせたい、遠隔地のカメラを見せたい、音声を出したい、SlackやNextcloud Talkなど複数チャネルから呼びたい、という話になると、単体のComputer Useだけでは足りません。そこから先は、OpenClawの出番です。

Codex Computer Use: 目の前のPCとGUIアプリをAIに操作させる最小構成。
OpenClaw: Gateway、モデル、チャネル、Node、音声、遠隔操作、ログ、権限を束ねる本格構成。
AI特命室の実務: 小さく試し、使える範囲を見極めてから、社内チャットやサーバー運用へ拡張する。

OpenClawを動かす最低限の構成として、チャネル、OpenClaw、通常モデル、MemorySearch、MemorySearch用モデル、Memoryファイルの関係を示す図 — OpenClawを動かす最低限の構成。チャネルを入口に、OpenClawが通常モデルと記憶検索を使い分ける流れを示しています。

1. CodexのComputer Useは「一台のPCを触らせる」入口

CodexのComputer Useは、画面を見て、GUIを操作するための機能です。OpenAIのCodex資料では、macOSとWindowsで利用でき、macOSではScreen RecordingとAccessibilityの許可が必要です。アプリの設定画面を確認する、ブラウザで再現確認をする、GUIにしか出ない不具合を追う、といった場面に向いています。

ここで大事なのは、Computer Useが万能のAGI基盤ではなく、一台のPC上にある見える画面を扱う入口だという点です。AIに画面操作を任せるだけならこれで十分ですが、社内チャット、遠隔Node、複数PC、常駐Gateway、音声出力、定期実行まで含めると、設計対象が一気に増えます。

Computer Useを使う時は、AIが見てよい画面だけを開き、権限確認や支払い、秘密情報を扱う操作では人間が横で確認する前提にします。

2. OpenClawで必要になる三つの部品

OpenClawを小さく始める時は、まず三つに分けます。AIエージェントの本体であるOpenClaw、頭脳として使うモデル、そして人間とAIが会話するチャネルです。この三つを混同すると、設定が分かりにくくなります。

部品	役割	最小構成の考え方
OpenClaw本体	Gateway、セッション、ツール、チャネル接続、権限、ログを管理します。	まず一台のPCに入れ、Control UIで動作確認します。
モデル	AIの推論を担当します。Codexサブスク、OpenAI API、Anthropic、Google、ローカルLLMなどを選びます。	Codexサブスクを使うならOpenAI OAuthで認証し、openai/gpt-*をCodex runtimeに通します。
チャネル	人間がAIへ指示し、AIが返事を返す入口です。	最初はControl UI。社内運用ならMattermostやNextcloud Talk、SaaS連携ならSlackやTeamsへ広げます。

3. OpenClawを最小構成で入れるコマンド

OpenClaw公式のGetting Startedでは、Node.jsはNode 24推奨、Node 22.19以上も対応とされています。macOSまたはLinuxでまず試すなら、次の流れが最短です。

# macOS / Linux
node --version
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
openclaw gateway status
openclaw dashboard

この時点では、外部チャットをまだ足さず、Control UIだけでよいです。OpenClawのGatewayが起動し、ブラウザで http://127.0.0.1:18789/ が開き、AIから返答が来ることを確認します。

最初からSlackやLINEをつなぐより、まずControl UIでGateway、モデル、ツールが動くことを確認してからチャネルを増やす方が安全です。

4. CodexサブスクをOpenClawの頭脳にする

OpenClaw側でCodexを使う場合、OpenAIのモデル名、Codex runtime、チャネルを別々に考えます。OpenClawのドキュメントでは、OpenAI系のエージェントターンは openai/<model> を使い、通常はCodex app-server harnessを通す構成が案内されています。

サブスク認証を使う場合は、まずOpenAI providerでログインします。利用できるモデルは契約やアカウントに依存するため、設定後にstatusとprobeで確認します。

openclaw models auth login --provider openai
openclaw models status --probe
openclaw models set openai/gpt-5.5
openclaw gateway restart
openclaw gateway status --require-rpc

設定例は次のようになります。実運用では、現在の openclaw.json をバックアップしてから、openclaw config patch --dry-run で差分を確認して反映します。

{
  plugins: {
    allow: ["codex"],
    entries: {
      codex: {
        enabled: true,
        config: {
          computerUse: {
            autoInstall: true,
          },
        },
      },
    },
  },
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
    },
  },
}

Computer Useまで使うなら、OpenClawのチャット上でCodex側の状態も確認します。次のコマンドはCLIではなく、OpenClawの会話チャネルに送るスラッシュコマンドです。

/codex status
/codex models
/codex computer-use status
/codex computer-use install
/new

Codex、OpenClaw、Channel、Nodeをカード形式で整理した第二十九話の図解 — CodexからOpenClawへ広げる時の基本要素を、四つの入口として整理した図解です。

OpenClawチャネル選定の早見図 — チャネルは、最小入口、社内構築、SaaS連携、顧客接点で選び方が変わります。

5. チャネル比較表の読み方

今回の指定資料 OpenClaw_Channel_Comparison_20260626.xlsx は、チャネルを「社内構築」と「社外利用」に分けています。ここでの評価は、チャットAPI単体の機能数ではなく、AIエージェントの業務入口として何を任せられるかで見ます。したがって、WebChat / Control UI は検証・管理入口としては重要でも業務入口スコアは低め、Nextcloud Talk は文書共有・予定・権限管理まで同じ自社管理領域へ置けるため高めに評価します。

初回検証: WebChat / Control UI – OpenClaw本体の動作確認用。業務チームの主導線ではなく、管理・検証入口として使う。
社内業務基盤: Nextcloud Talk – 文書、予定、権限、会話を自社管理の同じ基盤へ置ける。AIエージェントの業務入口として最も説明しやすい。
社内チャット: Mattermost – チャンネル、スレッド、Bot、コマンド運用を自社サーバー側へ寄せられる。
暗号化・分散重視: Matrix – E2EEや分散homeserverまで見たい技術寄り組織向け。設計難度は高い。
企業SaaS連携: Slack / Microsoft Teams – Slackはワークフローとスレッド、TeamsはMicrosoft 365統制に強い。
最速外部連携: Telegram – BotFatherのトークンで始めやすく、long pollingなら公開URLなしでも試しやすい。
日本向け顧客接点: LINE – Flex messageやquick replyなど、日本市場の顧客導線に向く。HTTPS webhookは必須。
現場スマホ・海外: WhatsApp – 画像、文書、音声メモに強い。QRログイン運用の弱さは説明が必要。

社内構築向け

順位	チャンネル	位置づけ	評価
1	Nextcloud Talk	社内業務基盤の本命	業務入口5 / 導入3 / 統制5 / 外部依存5
2	Mattermost	社内チャットの本命	業務入口4 / 導入3 / 統制5 / 外部依存5
3	Matrix	暗号化・分散重視	業務入口4 / 導入2 / 統制5 / 外部依存5
4	WebChat / Control UI	検証・管理入口	業務入口2 / 導入5 / 統制5 / 外部依存5
5	Synology Chat	NAS通知・簡易窓口	業務入口2 / 導入3 / 統制4 / 外部依存5
6	IRC	技術者向け限定用途	業務入口1 / 導入3 / 統制4 / 外部依存5

社外利用・SaaS連携向け

順位	チャンネル	位置づけ	評価
1	Slack	社外SaaS連携の本命	業務入口5 / 導入3 / 統制4 / 外部依存1
2	Microsoft Teams	大企業向け本命	業務入口5 / 導入2 / 統制5 / 外部依存1
3	Discord	デモ・コミュニティ向け	業務入口4 / 導入3 / 統制3 / 外部依存1
4	LINE	日本市場向け顧客接点	業務入口4 / 導入3 / 統制3 / 外部依存1
5	WhatsApp	現場モバイル枠	業務入口4 / 導入3 / 統制2 / 外部依存1
6	Google Chat	Google Workspace向け	業務入口4 / 導入2 / 統制4 / 外部依存1
7	Telegram	最速検証・通知向け	業務入口3 / 導入5 / 統制2 / 外部依存1
8	iMessage	Mac限定の参考枠	業務入口3 / 導入1 / 統制2 / 外部依存2

6. チャネル別の最小コマンド例

Control UIで動作確認できたら、次に使うチャネルを選びます。ここで重要なのは、単に「チャットできるか」ではなく、会社がファイル、予定、承認、問い合わせ、権限管理をどの運用境界に置きたいかです。たとえばNextcloud Talkは、単体のチャット製品というより、Nextcloudというファイル共有・カレンダー・共同編集・ユーザー管理をまとめる自社管理型グループウェアの中にあるチャット/会議機能です。Nextcloud公式でも、Talkはチャット、ビデオ通話、ウェビナーだけでなく、ファイル共有や文書編集と同じアプリ内で連携するものとして説明されています。比較軸は「もうNextcloudがあるか」ではなく、AIへの依頼、関連資料、共有リンク、会話履歴、ユーザー権限を同じ自社管理領域へ寄せたいかどうかです。

Nextcloud Talk

Nextcloud Talkの採用理由は、チャット機能の多さだけではありません。比較対象として見るべき点は、文書共有、予定、ユーザー権限、AIチャットを自社管理の同じ業務基盤へまとめられるかです。SlackやMattermostはチャット中心、Matrixは暗号化や分散重視です。一方Nextcloud Talkは、Nextcloud上のファイル、共有リンク、カレンダー、ユーザー権限と近い場所でAIエージェントを使えることが強みです。契約書、手順書、議事録、スクリーンショット、点検レポートとAIへの依頼を同じ管理範囲に置きたい会社には、MattermostやMatrixよりも上に置ける業務上の理由があります。

注意点は、OpenClaw側のNextcloud Talk bot連携には、botからDMを開始できない、メディアはURL送信になる、native commandに制約がある、といった実装上の制約があることです。ただし、これは「Nextcloud全体の機能が低い」という意味ではありません。AIエージェントの業務入口としては、文書共有・予定・権限管理まで自社管理したい会社が、その業務基盤の入口としてAI会話を置く選択肢として高く評価するのが正確です。

openclaw channels add --channel nextcloud-talk \
  --base-url https://cloud.example.com \
  --secret-file ~/.openclaw/secrets/nextcloud-talk-secret

openclaw gateway restart
openclaw channels status --probe

Mattermost

openclaw plugins install @openclaw/mattermost
openclaw config patch --file ./mattermost-channel.json5 --dry-run
openclaw config patch --file ./mattermost-channel.json5
openclaw gateway restart
openclaw channels status --probe

# BotFatherで bot token を作成した後
openclaw config set channels.telegram.botToken --ref-provider default --ref-source env --ref-id TELEGRAM_BOT_TOKEN
openclaw gateway
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

ここで共通して重要なのは、トークンやshared secretをチャットに貼らないことです。環境変数、secret file、OpenClawのsecret参照を使い、設定前後に openclaw config validate と openclaw channels status --probe を実行します。

7. AGIに近い使い方は、チャネルだけでは終わらない

AIエージェントらしい面白さは、チャットで答えるだけではありません。サーバーを点検する、別PCの画面を確認する、遠隔地カメラを見る、音声で返す、定期タスクで報告する、異常時に人間へ確認を戻す、という部分にあります。

ここでOpenClawは、Gatewayを中心に、チャネル、Node、メディア、音声、cron、ツール、権限、ログをつなぎます。つまり、OpenClawは「AIに話しかけるアプリ」ではなく、AIに実務の入口と手足を渡すための運用基盤です。

ただし、AGIに近い使い方ほど、権限、ログ、承認、復旧手順が重要になります。AIに任せる範囲を広げる前に、止める条件と人間承認の場所を決めておきます。

8. ニリアコットAI特命室での進め方

ニリアコットAI特命室では、いきなり大きなAI基盤を売るのではなく、まず「どの業務をAIに触らせるか」を切り分けます。たとえば、最初はCodex Computer Useでブラウザ操作やアプリ確認を試し、次にOpenClawのControl UIでGateway運用を確認し、必要になった段階でMattermost、Nextcloud Talk、Slack、LINEなどへ広げます。

サーバー運用や月次点検へ広げる場合は、第二十八話のProxmox VEアップグレード注意点や第二十七話のClearWing構築手順のように、ログ、バックアップ、検品、報告の形まで整えます。導入前の棚卸しは、30分AI業務診断で小さく始めるのが安全です。