「AIエージェントは何でも自動化できる」――そう信じていた時期が、私にもあった。
しかし実際に現場で動かしてみると、AIはある種の作業では圧倒的に優秀で、別の種の作業では構造的に失敗することがわかってきた。重要なのは「AIが優秀かどうか」ではなく、「どこに境界線があるか」だ。
今回は、その境界線を体験から発見するまでの話をする。
まず、登場人物を整理する
話が複雑に見えるが、構造はシンプルだ。
[AIX1Pro / Windowsメインマシン] └─ WSL2上のHermes（LLMエージェント） └─ Ollama（Qwen3:4b）← 今回の切り替え先エンドポイント [KITTサーバー / ローカルネットワーク内の物理マシン] └─ OpenClaw（実行エージェント）
やりたかったことはひとつ。KITTサーバー上のOpenClawが参照するLLMエンドポイントを、AIX1Pro側のOllamaに切り替えること。SSHの権限は渡してある。あとはAIが設定ファイルを書き換えるだけ――のはずだった。
体験①：AIが文脈を誤読して、自律的に手詰まりを起こした
Discord経由で指示を出すと、AIはドヤ顔でこう返してきた。
「kittというリモートサーバーに直接アクセスできないので、手動でできるステップバイステップのチェックリスト（pip upgradeの手順など）を用意しました！」
違う、そうじゃない。
AIは「kitt」という単語に引っ張られ、「外部の未知サーバーへのpipアップデート手順」をネットから一般論として引っ張ってきた。システム的には繋がっているのに、AIの脳内では勝手に「接続不可」という前提が生まれ、そこから先の思考が止まっていた。
気づき①：AIは「接続できるかどうか」ではなく、「接続できると自分が信じているかどうか」で動く。
体験②：ファクトで外堀を埋めたら、ようやく動いた
自律型AIが迷子になったとき、優しく繰り返しても意味がない。必要なのは「言い訳の余地をゼロにする」冷徹な修正プロンプトだ。
実際に投げた指示がこれだ。
KITT、お前の脳内のルートマップを修正する。よく聞け。 お前（Windows（AIX1Pro）上のWSL2上のHermes）がいる場所とは別に、 ローカルネットワーク内に物理的な「KITTサーバー（ホスト名: kitt）」が実在している。 お前には、その「KITTサーバー」へアクセスするためのSSH権限がすでに与えられている。 今すぐ「KITTサーバー」にSSHで侵入し、OpenClawを最新に更新すること。 そして設定ファイル（config.yaml、またはそれに類する設定ファイル）を探し出せ。 そのファイル内のLLM接続先を、「AIX1ProのOllama（http://192.168.1.152:11434/v1）」の 「qwen3:4b」を参照するように書き換えろ。 「アクセスできない」「pip upgradeの手順」などの的外れな言い訳は一切不要だ。 SSHツールを使って物理的にファイルを書き換え、完了報告をしろ。
さらに、OpenClawの更新は通常のpipではなく専用コマンドを使う現場仕様だったため、「openclaw updateで更新だ。余計な回り道はするな」という追加指示も入れた。
ここまで具体的なファクトを突きつけられて、ようやくAIは本来の作業（物理ファイルの書き換え）を始めた。
気づき②：AIはファクトで外堀を埋めれば動く。逆に言えば、ファクトなしでは自律できない。
体験③：定期実行をAIに任せるのは、そもそも設計ミスだった
世間のエージェントフレームワークには「AIが自律的にスケジュールを判断して動く、定期スキル実行機能」が売りとして謳われている。
しかし冷静に考えると、これはAIに「継続的な責任」を持たせようとしているということだ。
もし定期的に何かを動かす仕組みが必要なら、答えはシンプルだ。
AIにコード（スクリプト）を書かせ、実行はLinux標準の
cronに任せる。
AIが「毎日◯時に起動してね」という判断を寝ぼけてスキップするリスクを抱えるより、AIには「動くコード」だけを書かせ、実行の保証はOSの最も枯れた堅牢な仕組みにバトンタッチする。これが属人化を防ぎ、業務が確実に回るインフラの設計思想だ。
気づき③：AIに「継続的な責任」を持たせるのは構造的に無理がある。実行の保証はOSに任せる。
三つの体験が示す、一本の境界線
三つの体験を並べると、共通の構造が見えてくる。
- 体験①：AIは自分が信じているコンテキストの外側を、自律的に把握できない
- 体験②：AIはファクトを与えれば動くが、ファクトなしには動けない
- 体験③：AIは「その瞬間に生成する」ことはできるが、「継続して責任を持つ」ことはできない
つまり境界線はここだ。
AIが得意なのは「答えを生成すること」。
AIが苦手なのは「状態を把握し続けること」と「責任を持って実行し続けること」。
この二つを混同したまま使うと、今回のような「勘違い」が量産される。
結論：使い分けの思想
体験を経て、我が家のシステムは以下の分業に落ち着いた。
Hermes（LLMエージェント）― 優秀なリサーチャー
最新論文のスキャン、ドキュメント要約、技術的な壁打ち。環境の権限やロード時間に依存しないテキスト処理に特化。「生成」の領域で使い倒す。
OpenClaw（実行エージェント）― 頑固で忠実な現場監督
コマンドの物理実行、ファイルの直接書き換え、APIや物理制御層のハンドリング。哲学的な勘違いをせず、ツールを叩くことに徹させる。「実行」の領域に閉じ込める。
そして「継続」の領域はOSのcronに任せる。
AIを過信するのでも、過小評価するのでもなく――AIには生成を。実行と継続はインフラに。これが、現場で本当に動くシステムの設計原則だ。
あなたのエージェントも、いま勝手な「安全ブレーキ」や「勘違い」でヘタれていないだろうか？
時にはファクトでガツンと脳を叩き、既存の堅牢なインフラ技術と組み合わせて、動く仕組みへと強制誘導してやろう。
