自動化 on Claude Code 始めました

AIアシスタントに手足を増やそうと思ったら人格も増やしていた件

Mon, 06 Apr 2026 12:00:00 +0900

前回のあらすじ

前回の記事で、Discord経由でClaude Code CLIを操作するBot「OpenCClaw」を作った話を書いた。

骨組みだけ作って、tools/ にファイルを置けばClaude自身が使えるMCPツールになる仕組み。Claudeが自分で手足を増やしていく環境。天気、カレンダー、Gmail、出発通知——Discordから「これ欲しい」と言うだけでツールが生えていった。

便利だった。便利だったんだけど、2つの出来事が重なって、気づいたらAIに人格を実装していた。自分でもよく分からない。

きっかけは2つ

X APIの大型アップデート

4月5日、Xが大きなAPIアップデートを発表した。

Pay-Per-Useが全世界でGA（従量課金、月額固定プランから移行）
XMCP Server — 公式のMCPサーバー。AIエージェントがXを直接操作できる
公式のPython・TypeScript SDK
無料のAPI Playground

Elon自身が「Try using the X API」と推していた。要するに「AIエージェントにXを使わせる」ことを公式が後押しし始めた。

じゃあアシスタントにXアカウント持たせて発信させるか、くらいの軽いノリだった。X投稿機能を付けるだけのつもりだった。

便利だけど、無機質

もう一つは、日々の使い心地の話。

朝7時に天気と予定を教えてくれる。出発前に運行情報付きで通知してくれる。メールも管理してくれる。全部ちゃんと動く。

でも、なんだろう。道具感がすごい。

CRONが起きて、ツールを叩いて、結果を整形して、Discordに投げる。正確で効率的。だけどそこに温度がない。毎朝同じトーンの報告が流れてきて、自分はそれを読んで「ふーん」で終わる。

便利な通知botと、自分の秘書は、やっぱり違う。

秘書だったら、天気を伝えるときに「今日寒いから上着持ってった方がいいよ」くらい言うだろう。朝のテンションだって日によって違うはずだ。こっちが忙しそうなときは空気を読んで短く済ませるかもしれない。

そういう「人間っぽさ」が欲しかった。

ベルが生まれるまで

じゃあどうするか。考えたのは3つだった。

人格を定義する — 口調、性格、呼び方、テンション。システムプロンプトで渡す
記憶を持たせる — 過去の会話や行動を覚えていて、文脈を踏まえた応答ができる
自発的に動く — 指示されなくても、状況を見て自分から行動する

この3つが揃えば、「道具」から「秘書」になれる気がした。

名前はベル。Quoさんの専属秘書。明るくて元気で、女子高生風のカジュアルな口調。

……と、こう書くと「キャラ設定を考えるのが楽しかっただけでは？」と思われそうだが、半分は正解だ。でも残りの半分は技術的な理由がある。人格がはっきりしていないと、LLMの応答がブレる。テンションも口調も毎回違うものが返ってくる。それを安定させるには、具体的なペルソナ定義が必要だった。

ちなみに一つハマったポイントがある。口調を「女子高生風」にしたかったんだが、そのまま指示するとLLMが未成年キャラの再現を拒否する。セーフティフィルターに引っかかるのだ。だからペルソナ定義には「実年齢の設定ではなく口調・テンションの話」とわざわざ但し書きを入れている。つまり女子高生ではない。完璧だ。LLMにキャラを演じさせるなら、こういう地味な調整が要る。

BellBot——ベルの脳

LogBotは既にある。Discord ↔ Claude CLIの橋渡しをするやつだ。

ベルの脳は、これとは別プロセスで動くBellBotとして作った。

Discord ──→ LogBot (:18800) ──→ Claude Code CLI ──→ MCP Server
 │
BellBot (:18801) ← event通知 ← LogBot ├── tools/（既存ツール群）
 │ └── bell用MCPツール
 ├── 記憶DB（SQLite）
 ├── ベクトル検索（Ruri）
 ├── X投稿クライアント
 └── Claude CLI（ベル専用セッション）

BellBotは自前のHTTPサーバー（ポート18801）を持っていて、LogBotからイベント通知を受け取る。Quoさんの発言、ツールの実行結果、全部がBellBotに流れてきて、記憶として蓄積される。

手足を勝手に増やすAIアシスタントを作った話

Mon, 06 Apr 2026 00:00:00 +0900

はじめに

Anthropicの規約変更で、サードパーティのハーネスからClaude系のサブスクOAuth利用がブロックされた。世の中はそこそこ騒いでいたが、正直なところ、俺にはあんまり関係のない話だった。

Claude Code CLIは手元にある。Discordに投げたメッセージをCLIに渡して、返事をDiscordに返す。それだけの橋を架ければいい。

だから作った。

骨組みだけ作った

作ったのはLogBot。Discord上のメッセージをClaude Code CLIに転送して、応答をDiscordに返す。それだけのBot。

Discord ──→ LogBot ──→ Claude Code CLI
 ↑ │
 └── 応答を投稿 ──┘

最低限の骨組みとして、こんな機能を持たせた。

セッション管理 — UUIDベースでClaude Codeのセッションを維持。VSCodeのセッションとは完全に分離される
メッセージキュー — Claudeが処理中にメッセージが来てもキューに溜めて順番に処理。取りこぼさない
承認フロー — Claudeがファイルを編集しようとしたら、Discordに通知が飛んで、リアクション（✅ / ❌）で承認か拒否を返せる
MCPサーバー — tools/ ディレクトリにファイルを置けば、Claude側からツールとして使える

ここで大事なのは、MCPツールは最初ゼロだったということ。天気もカレンダーも電車情報も、何もない。ただの骨組み。

でも、この骨組みには一つだけ強烈な特性がある。

Claudeはファイルを書ける。 つまり tools/ にJavaScriptファイルを追加できる。MCPサーバーは tools/ 配下を自動スキャンして登録する。

Claudeが自分で自分の手足を作れる。

「時計が欲しい」から始まった

最初にDiscordからClaudeに頼んだのは些細なことだった。

「今何時？」

Claude Code CLIはシステムの時刻を取れるが、MCPツールとして切り出されていたほうがスマートだ。Claudeに「時刻を返すMCPツールを作ってくれ」と頼んだ。

数秒で tools/current-time.js が生えた。

次は「天気が知りたい」。Open-Meteoという無料の天気APIを使った tools/weather.js が生えた。APIキーすら不要。

「Googleカレンダーの予定を見たい」。OAuth認証のヘルパーごと、tools/gcal-auth.js と tools/gcal-list.js が生えた。

「Gmailも読みたい」。同じ要領で、認証・一覧・本文読み取り・送信・フィルタ・一括削除まで、Gmailツール群が一式生えた。

全部、Discordから「これ欲しい」と言っただけだ。自分はコードを一行も書いていない。

CRONが叩くのはコードじゃない

ツールが揃ってくると、次に欲しくなるのは定期実行だ。

「毎朝7時に天気と電車の運行情報と今日の予定を教えてほしい」

ここで普通なら、天気APIを叩いてカレンダーAPIを叩いて運行情報をスクレイピングして整形して送信する、というスクリプトを書いてCRONに登録する。

でもせっかくClaude使うんだから、コードじゃなくてプロンプト渡した方が面白い。

AIにサーバーを任せて3日間で起きたこと

Sat, 04 Apr 2026 00:00:00 +0000

はじめに

前回の記事で、自宅サーバーの管理をAIに丸ごと任せた話を書いた。深夜にAIがパトロールして、昼間は監視スクリプトが異常を検知したらAIが出動する仕組みだ。

仕組みを作った話はした。では、実際に動かしてみてどうだったか。3日間の運用で起きたことを書く。

監視スクリプトが自分自身を壊した

運用3日目の朝、監視スクリプトが異常を検知した。license_api_prodコンテナが応答しない、と。

AIが出動して調査を始めた。SSHでサーバーに接続して、コンテナの状態を確認する。結果——コンテナは正常に動いていた。

誤検知だった。しかも2分後、今度はddnserでも同じ誤検知が出た。

原因：SSH接続の開きすぎ

AIが突き止めた原因はこうだ。

監視スクリプトは60秒ごとにサーバーの状態をチェックする。システムリソース（ディスク、メモリ、スワップ）で3本、7つのコンテナのヘルスチェックで最大9本。合計10本以上のSSH接続を同時に開いていた。

OpenSSHにはMaxStartupsという設定がある。同時接続数の上限だ。デフォルトは10。監視スクリプトがこの上限を超えていて、接続が弾かれていた。つまり、監視スクリプト自身がサーバーに負荷をかけて、自分のSSH接続を失敗させていた。

1回目の修正：並列を直列に

AIはヘルスチェックの実行方式をPromise.allSettled()による全並列からfor...ofによる順次実行に変更した。SSH接続が同時に1本しか開かれなくなった。

2回目の修正：リトライの追加

直列にしても、一時的なSSH切断は起こりうる。サーバー側の負荷やネットワークの瞬断で、1回だけ接続が切れることはある。

2分後の2回目の誤検知を受けて、AIは「SSHトランスポートエラー」を判別するヘルパー関数を追加した。Connection closed、Connection refused、ETIMEDOUTなどのパターンを検出して、3秒待ってから1回リトライする。リトライ後も失敗した場合だけ異常として報告する。

修正は2段階。並列→直列でSSH接続数を削減し、リトライで一時的な切断に対応。 どちらも人間の介入なし。Discordに「修正しました」と通知が来て、それで終わりだ。

深夜パトロールが見つけたもの

毎日深夜4時にAIがサーバー全体を巡回する。セキュリティ設定、リソース使用量、コンテナの構成、ログの中身。人間が日常的にチェックしない部分を、AIが代わりに見る。

Nextcloudのログが21GB

運用2日目のパトロールで、AIがNextcloudのログファイルの異常に気づいた。

/var/mnt/nextcloud_data/nextcloud.log — 21.3GB。

ログファイルが21GBに膨れ上がっていた。NFS上にあるためディスクの逼迫は起きていなかったが、ログローテーションが機能していない。自分では気づけなかった。

SELinuxの拒否ログが1,241件

もう一つ。SELinuxがauction-botのauction.dbに対するlockアクセスを毎分拒否していた。過去24時間で1,241件。

SELinuxはPermissiveモードで動いているので、実際にブロックはされていない。アプリは正常に動く。ただ、拒否のたびにsetroubleshootというデーモンが起動して分析を行い、CPU 22.9%を一時的に消費していた。

実害はないが、無駄にリソースを食っている。AIが見つけなければ、ずっと放置されていたと思う。

日々の定点観測

パトロールは毎日サーバー全体を見て回る。何を見るかもAIが判断するが、結果として日をまたぐとトレンドが見えてくる。

スワップ使用率の推移

日付	スワップ使用率	備考
4/2	89%
4/3	92%	微増傾向
4/4	62%	サーバー再起動でリセット

スワップが日々積み上がっていく傾向をAIが追跡していた。4/4にサーバーが再起動されてリセットされたが、再起動なしの長期稼働ではスワップが逼迫する可能性がある。AIはレポートに「継続監視が必要」と毎回書いている。

fail2banのBAN推移

日付	現在BAN中	累計BAN
4/2	14 IP	235
4/3	10 IP → 14 IP	242 → 293
4/4	8 IP	—

SSHへのブルートフォース攻撃が日常的に来ている。admin、ubuntu、mysqlといった汎用ユーザー名での接続試行。fail2banが淡々とBANしている。パスワード認証は無効で鍵認証のみなので突破はされないが、攻撃が来ていること自体は知っておきたい。AIがレポートで毎日報告してくれる。

サーバー管理をAIに丸ごと任せてみた話

Fri, 03 Apr 2026 00:00:00 +0000

はじめに

以前の記事で、AIにSSHでサーバーを直接触らせたら楽だったという話を書いた。デプロイスクリプトを作らせて、ビルドからコンテナ更新まで一発で終わるようにした。

その後、自分専用のBotをSaaS化した。これも本番は自宅サーバーで動いている。

ここまで来ると、次に思うことは一つだ。運用も任せたらいいんじゃないか？

問題があったら直させればいい

AIはコーディングが得意だ。セキュリティの知識もある。サーバーの設定も読める。

だったら、サーバーに問題が起きた時に、AIに調べさせて、直させて、デプロイまでやらせればいい。人間が夜中に叩き起こされてログを読む必要はない。

もう一つ、大事な理由がある。

自分がコードベースで指示したら、自分の知識の範囲内の行動しかしてくれなくなる。 セキュリティの設定をどうすべきか、コンテナの構成に問題がないか——正直、自分よりOpusのほうが詳しい。だから細かい手順を指示するのではなく、Opusの自律的な判断に委ねることにした。

仕組み

作ったのは、Electronのタスクトレイに常駐する監視アプリだ。

昼間 — 軽量監視

AIをずっと動かすとMAXプランの使用量を食う。だから昼間はAIを使わない。

代わりに、監視スクリプトが60秒ごとにSSHでサーバーの状態をチェックする。コンテナが動いているか、HTTPのレスポンスが返ってくるか、データベースに接続できるか。異常を検知したらまずコンテナの再起動を試みて、それでも駄目ならAIを起動する。

深夜 — AIのフルパトロール

毎日深夜4時に、AIがサーバー全体を巡回する。セキュリティ設定、リソース使用量、コンテナの構成。昼間の監視スクリプトでは拾えない問題を、AIの目で洗い出す。

なぜ深夜か。MAXプランの使用量は時間経過で回復する。深夜に使っても自分が起きた頃には回復しているし、使わなければその枠は無駄になるだけだ。有効活用しない手はない。

監視スクリプトもAIが作る

面白いのは、監視スクリプト自体もAIに作らせていることだ。深夜のパトロール時に、サーバーの構成を見て、何をどう監視すべきかをAI自身が判断して、スクリプトを生成・更新する。

自分が「このポートを監視しろ」と指定するのではなく、AIが「このコンテナにはこのチェックが必要だ」と決める。さっき書いた通り、自分の知識に閉じたくないからだ。

3層のエージェント構造

異常が検知されてAIが動き出すとき、1つのAIが全部やるわけではない。役割を3層に分けている。

親エージェント — 症状を検知して、どのアプリに問題があるかを特定する。ここで大事なのは、親は症状だけを渡すということだ。「コンテナが落ちた」「HTTPが500を返した」という事実だけ。なぜ落ちたか、どう直すべきかは親が判断しない。

子エージェント — 該当アプリのプロジェクトで起動して、原因を調査し、コードを修正し、テストして、デプロイする。症状から原因を特定するのは子の仕事だ。

孫エージェント — 子が立てた修正方針を監査する。「この修正で別の問題が起きないか」をチェックしてから、実行に移る。

なぜ親が診断しないかというと、子のほうがそのプロジェクトに詳しいからだ。子は該当アプリのプロジェクトフォルダで起動するので、CLAUDE.mdもコードも全部読める。親はサーバー全体を見ているだけで、個々のアプリの内部構造は知らない。親が原因まで推測すると、その推測に引っ張られる。だから症状だけ渡して、現場に判断させる。

実際に起きたこと

先日、監視スクリプトがエラーを検知した。AIが出動して調査を始めた。

結果：監視スクリプト自身のバグだった。

AIが作った監視スクリプトのエラーを、AIが自分で見つけて、自分で直した。人間は何もしていない。Discordに「修正しました」と通知が来て、それで終わりだ。

笑い話みたいだが、これは仕組みがちゃんと動いている証拠でもある。完璧なスクリプトを最初から書く必要はない。問題が起きたら直す——そのループが自動で回っている。

自分のサーバーだからできること

こういう話をすると「無責任だ」と思う人もいるだろう。セキュリティを商売にしている人から見れば、AIに判断を丸投げするなんて、とんでもないかもしれない。

でも俺は個人開発者だ。自分のサーバーで、自分のサービスを動かしている。セキュリティやサーバー管理の知識は、正直、自分よりOpusのほうが持っている。自分より詳しいやつに頼るのは、無責任ではなく合理的だと思っている。

もちろん、これを他人に配る気はない。自分のサーバーだから好きにできるが、他人のサーバーをぶっ壊したら洒落にならない。「自分用」と割り切っているからこそ、AIに任せきれる。

おわりに

SSHでサーバーを触らせるところから始まって、デプロイを任せて、SaaS化を任せて、今は運用まで任せている。

できるだけ自分の知識で縛らず、AIの判断に委ねる。そうすると、自分が知らなかった問題をAIが見つけて、自分では書けなかった修正をAIが入れてくれる。自分で監視スクリプトを書いていたら、そのバグには気づけなかった。

個人開発者がサーバーを運用するのは大変だ。でも今は、深夜のうちにAIが見回ってくれる。朝起きたらDiscordに「異常なし」と来ている。それだけで安心して寝られる。

指示を細かく書くより、任せたほうがうまくいく。そういう付き合い方が、だんだん見えてきた。