LLMエージェントで「動き続ける」システムを作る — 自律パイプライン設計の実践

あなたのシステム、止まったら終わりですか？

「AIに作ってもらう」という話はよく聞く。でも自分がもっと面白いと思ってるのは「AIが動き続ける仕組みを作る」ほうだ。

CVEが検知されたら自動でリスク評価して台帳に記録する。メールが届いたら自動で分類して返信ドラフトまで作る。人が気づく前に、システムが次の手を打ってる。

コードを書いてもらうんじゃなくて、起動したら自分でデータを拾って、判断して、記録して、次に備える。そういうシステムをLLMエージェントで作ってきた経験から、ハマりどころも含めて書いてみます。

「自律的なシステム」ってどういうこと？

ざっくり3段階に分けて考えてます。

今回話すのは3つ目です。LLMが「状況判断」の部分に入ることで、事前に全パターンを書き切れない問題に対処できるようになります。

実例①：セキュリティ自動化パイプライン

何を作ったか

自分が開発してるGenbaFlowのセキュリティ運用を、ほぼ人手ゼロで回す仕組みです。

pip-audit / Dependabot
    ↓ 新規CVE検出
GitHub Actions がトリガー
    ↓
risk-assessor エージェント起動
    ↓ ISO27005 に基づくリスク評価
docs/iso27005/risks/ に個別ファイルを生成
    ↓
リスク台帳（ISO27005_risk_register.md）を更新
    ↓
PR作成 → レビューへ

CVEが検知されてから、リスク評価・証跡ファイル生成・PR作成まで、人が介在するのはPRをマージするときだけ。われながらよくできてると思ってます。

なぜLLMが必要だったか

CVEへの対応は「このライブラリのこのバージョンに対して、うちのプロダクトのコンテキストではどの程度のリスクか」という判断が入る。ルールベースでは書き切れない。

影響範囲・悪用可能性・暫定対応の妥当性を自然言語でまとめて台帳に残す、という作業がLLMエージェントにちょうど合ってました。

詳細な実装についてはこちらの記事を参照してください。

実例②：メール自動分析システム

何を作ったか

Gmail × Gemini 3.5 Flash × GASで、受信メールを自動で読んで分類して、返信ドラフトまで生成するシステムを受託で作りました。

Gmail 受信トレイ
    ↓ 未処理メールを取得（GAS トリガー）
Gemini 3.5 Flash で分析
    ↓ 要約・タグ・担当部署・優先度・広告判定
スプレッドシートに記録
    ↓
ダッシュボードに表示
    ↓ スタッフが確認・返信

朝イチに開くと、優先度ごとにカード整理された状態になってます。返信ドラフトもその場で生成できる。「これ欲しかったやつだ」ってなります。

判断の難しさ

一番時間かかったのはプロンプトの調整でした。「広告メールかどうか」「どの優先度にするか」は、具体的な判定基準を例示で書かないとブレる。JSONスキーマを厳密に指定したらパースエラーも大幅に減りました。

詳細はこの記事にまとめてあります。

設計で気をつけてること

2つのシステムを作って気づいたことをまとめます。

冪等性、地味に大事

同じイベントを2回処理しても結果が重複しない設計にする、ってやつです。GitHub Actionsのトリガーは条件次第で複数回発火する。ファイルが既に存在するなら上書きしない、記録が重複しないようキーでチェックする、といった処理が地味に重要です。

エラーリカバリは最初から作り込む

LLMへのAPIコールは失敗します。ネットワーク、レートリミット、パース失敗。「動く」システムは作れても、「止まらない」システムにするにはエラーリカバリを最初から組み込まないといけない。

リトライは必ず入れる。ただし無限ループになる条件も潰す。GASのメール分析では500msインターバルと3回リトライを標準にしました。セキュリティパイプラインはGitHub Actionsのステップごとにエラーを捕捉して、失敗ログを残してから終了。

エージェントが黙って止まってるのが一番困ります。失敗ログが残っていてアラートが飛ぶほうが、何倍もマシです。誰も見てないところで動いてるシステムなので、異常検知は最初から仕込んでおく。

「ここだけ人間が見る」を決めておく

全部自動化しようとしない、これ大事です。セキュリティパイプラインはPRのマージ、メール分析は返信の最終確認が人間のチェックポイントです。完全自動化より、人間が介在しやすい設計のほうが長続きするし、信頼もされやすい。

エージェントは役割ごとに分ける

1つのエージェントに何でもやらせない。「リスク評価だけ」「台帳の更新だけ」と分けると、テストしやすいし壊れたとき原因も特定しやすい。Claude Codeのサブエージェントを使って並列実行することもあります。

ログは「人間が読める」形で残す

エージェントが何をしたか、なぜその判断をしたか、ちゃんとログに残す。「なぜこの優先度にしたか」が残ってると、プロンプトの改版時の比較にも使えてかなり便利です。

セキュリティ要件はAIに丸投げしない

「セキュリティも考慮して実装して」とAIに投げると、ハッシュ化する・HTTPSにする・入力をバリデーションする、といった一般的な対策が出てきます。間違いではないんですけど、そのシステム固有のリスクを踏まえた設計にはならないんですよ。

「何にアクセスするシステムか」「誰が使うか」「悪用されたら何が起きるか」を先に整理して、セキュリティ要件として明示的にAIに渡す。メール分析システムなら、代表メールアドレスへのフルアクセス・複数スタッフの共有利用・操作ログの必要性という文脈を与えて初めて、ログイン失敗回数の制限やセッション検証の設計が出てくる。

要件を持ってるのは人間だけで、AIはそれを教えてもらうまで知らない。ここを省くと、動くけど穴だらけのシステムができあがります。自分も最初はここを甘く見てて、後から作り直した経験があります。

やってみてわかったこと

自律型システムって、普通のバッチ処理より難しいです。「動く」じゃなくて「動き続ける」を目指すと、考えることが増える。

でも一度動き始めると、人の手が離れる領域が増えていくのが面白い。セキュリティパイプラインは毎週自動でリスク台帳が更新されていて、自分がやってるのはPRを確認してマージするだけになりました。これ、思った以上に楽です。

LLMが担うのは「判断材料を揃える」部分だと思っています。分類、評価、要約、優先付け。最終的に何を選ぶかは人間の仕事で、LLMはその決断ができる状態を作るのが役割です。ルールで書ける部分はルールで書いて、ルールで書けない整理や評価だけLLMに任せる。この切り分けがうまくいくとシステムが安定します。

バイブコーディングが流行るのはわかる。でも自律型システムで本当に差が出るのはそこじゃないと思ってます。セキュリティとエラーリカバリをどれだけ手厚く定義して、止まらないようにするか。人間が見てないところで動き続けるシステムほど、「動く」より「止まらない」が設計の核になる。

同じような仕組みを作りたいという方、ぜひご相談をお待ちしています。

本記事で紹介したシステムはいずれも実運用中のものです。Claude Code / Gemini API / GitHub Actions を利用しています。

• AI
• LLM
• システム設計
• 自動化