日々のWebシステム開発やWordPressサイトの運用管理において、生成AIやエージェントツールは欠かせない相棒になりました。
ここに至るまでには様々な試行錯誤がありました。最初は自宅にゲーミングPCを用意してOllamaでローカルLLMを動かすところから始まり、ChatGPTのCodex、Claude Codeでの自動化実験などを経て、現在は Google One(Gemini / Antigravity / Jules)とn8n、そして自作のLaravel運用基盤 を組み合わせた運用に落ち着いています。
最初から完璧な完全自動化を目指すのではなく、「まずは手動で型を作り、定額サブスクの枠組みで安心して回せる仕組みに落とし込む」ことで、日々の運用・改善がとても心地よいサイクルで回り始めました。
今回は、私がどのようなプロセスを経て現在のAIエージェント活用にたどり着いたのか、その変遷と運用の仕組みについて等身大のログとしてまとめます。
試行錯誤の変遷:Ollama、Claude、そしてAntigravityへ
1. ゲーミングPCでのローカルLLM試作とChatGPTの定番化
AIを開発や運用に組み込もうと考えた初期は、ゲーミングPCを購入してUbuntuサーバーを立て、Ollamaを入れてローカルLLMを動かす試作などを行っていました。自前環境ならではの自由度の高さや面白さはあったものの、実務のスピード感や精度の面で少しハードルを感じる場面もありました。
一方で、ChatGPT(Codex)を使ったプログラミング支援は日常的な開発スタイルとして定着していきました。
2. Claude Codeとの出会いと、運用で見えてきた課題
転機となったのは、WordPressサイトの運用・管理をClaudeのCLI(claude コマンド)で自動化し始めたことです。
Linearにタスクを積んでclaude -p でプロンプトを流し込み、自動実行させるワークフローを組んだことで、「エージェントに自律的に動いてもらうコツ」を掴むことができました。
しかし、実務で本格的に回し続ける中で、いくつかの壁に直面しました。
- 手戻りと待ち時間のコスト: Claudeは非常に賢く、最後まで自動で実行してくれる魅力がある反面、実行速度がややゆっくりで、もし期待とズレたアウトプットが出た際の手戻り・修正コストが大きく感じられました。
- トークン上限の壁: プランを上位に引き上げても、日常的に運用タスクを回していると上限に達してしまい、作業が止まるストレスがありました。
3. Gemini / Antigravity へのシフト
そこで、トークン効率やレスポンスの速さを考慮し、GeminiおよびGoogleのエージェント環境(Antigravity、Jules)を軸にする構成へと舵を切りました。
使ってみて実感したメリットは以下の通りです:
- 軽快なレスポンスと小回りの良さ: レスポンスが早く、途中で止まることがあっても手動でクイックに軌道修正できます。作業のテンポが崩れません。
- Linuxフレンドリー: 普段の開発環境として Linux Mint を愛用しているのですが、Antigravityには公式でLinux版クライアントが用意されていた点も非常に心強いポイントでした。
- 定額サブスク内で完結する安心感: Google One のプラン枠内で活用できるため、従量課金APIの請求額を気にすることなく、一定の予算感の中で安心して試行錯誤を繰り返すことができます。
現在の運用アーキテクチャと自動化の流れ
現在では、WordPress運用専用のアプリケーションをLaravelで開発し、エージェントが自走できる環境を整えています。
【トリガー】
チャット / メール / 定期実行(Cron)
│
▼
【ワークフロー自動化】
n8n(Ubuntuサーバー上)
│
▼(SSH経由)
【エージェント実行環境】
Dockerコンテナ(Laravel + MCP + agyコマンド)
│ ├─ AGENTS.md(サイトごとの運用ルール・思想の定義)
│ └─ Linear / 自作アプリ(タスク管理)
│
▼
【結果処理】
返却されたJSONをパース ──▶ メール・チャット等へ完了通知
工夫しているポイント
- API実行ではなくCLIサブスク枠で回す
- Docker環境内で
agyコマンドを実行する形にしています。API従量課金ではなくサブスクプランの枠内で実行させることで、コストの上限をコントロールしながら継続的な運用が可能になりました。
- Docker環境内で
AGENTS.mdによるルールの一元管理- サーバー上の各プロジェクトに
AGENTS.mdを配置し、サイトごとのトーン&マナーや前提条件、チェックリストを明文化しています。これにより、エージェントがブレずに一貫したアウトプットを出せるようになります。
- サーバー上の各プロジェクトに
- Julesによる非同期タスク・セキュリティチェック
- 日常の運用タスクとは別に、定期的なセキュリティチェックや細切れにした開発タスクはJulesに投げておくなど、役割分担を行っています。
- 「手動で型を作ってからn8nに乗せる」アプローチ
- 最初から完全自動化を狙うのではなく、まずは手動でプロンプトやタスクのやり取りを調整し、安定した「型」が見えてきたものから順次n8nに組み込んでいます。
実際に任せているタスク
現在、この仕組みの上で以下のようなタスクを回しています。
- Webシステム開発: Laravel等での機能実装のサポート、テストコードの補助。
- サイトのアクセス解析・レポート作成: 定期的なアクセス状況の集計と、要約レポートの出力。
- 改善提案・競合調査: アクセスデータや競合サイトの動向を踏まえた、新規記事の切り口やリライト案の作成。
- WordPress記事の推敲・改善: 定義したルールに沿ったコンテンツの校正やブラッシュアップ。
「作って、経過を見て、改善して、更新していく」というWeb運用の基本サイクルが、無理なく自然に回るようになりました。
気づき・考察:仕組み化が生み出す「安心感」と「余白」
どのAIモデルが絶対に一番優れている、というわけではないと感じています。Claudeの丁寧な自走力も素晴らしいですし、GeminiやCodexのスピード感やトークン効率もそれぞれの良さがあります。大切なのは、「自分の開発リズムやコスト感にフィットする使いこなし方を見つけること」 でした。
また、従量課金への不安や手戻りのストレスを減らし、日々のルーティンをn8nとエージェントに任せられるようになったことで、作業に追われる感覚が減り、「本来注力したい設計や新しいアイデアの具現化に夢中になれる時間」 が増えました。
技術で不安を解消し、日々の仕事に落ち着きをもたらす──この仕組みづくり自体が、私たちが目指すWebシステムのあり方とも重なっているように感じています。
まとめ
ローカルLLMの試作から始まったエージェント運用の試行錯誤ですが、
- 手動で対話しながら「再現性のある型」を作る
- 定額サブスク内で安全に回るCLI・Docker環境を整える
- n8nでトリガーと通知を繋ぎ、無理のない自動化サイクルに乗せる
という現在の形に落ち着きました。
AIエージェントの導入や自動化は、大きな投資をして一気に全自動を目指すよりも、日々の小さな「繰り返し作業」をひとつずつ安心して任せられる形に整えていくのが、長く無理なく付き合っていくコツなのかもしれません。
今後も実際の運用の中で得られた知見や試行錯誤を、ブログ等で共有していきたいと思います。
コメントを残す