少人数でサービスを開発・運用するためのループエンジニアリング

UNIQUEX では、AI エージェントによる開発と運用の自動化と、その実行を管理する仕組みづくりを、ループエンジニアリングと呼んでいます。少人数でサービスを速く開発し、運用し続けることが目的です。まず、エージェントの実行状態、権限、処理量を管理する仕組みを作ります。この記事では、この仕組みをハーネスと呼びます。そのうえで、Ticket、ソースコードの管理、自動の検査、配布、監視、フィードバックの受付といったツールをハーネスにつなぎ、サービスの運用、監視、維持、開発を回します。たとえば画面の不具合が報告されると、報告は Ticket にまとまり、エージェントが修正案を作って自動の検査にかけ、人が本番への反映を承認する、という流れになります。人が Ticket を確認して開発し、運用し、監視する作業を、最終的にはなくすことを目指しています。

AI エージェントを会社に入れると、費用のかかる場所が変わります。人が手を動かす時間は減る一方で、エージェントを人が見張る時間と、止まらないエージェントが生む無駄や危険が、新しい費用になります。経営者が決めることは 2 つです。何を任せて何を人に残すか。そして、止まり方をどう設計するかです。

UNIQUEX の決め方は次のとおりです。仕事の依頼、状態、記録は Ticket に集約し、Ticket に書いてあることだけを正式な状態として扱います。エージェントの記憶やチャットの履歴は状態とみなしません。エージェントの動き方は 1 本のループに限ります。人の判断を残す線は先に引いてあり、本番への反映、外部システムへの取り消せない書き込みや削除、権限の変更、有料の資源の作成には、必ず人の承認を求めます。この承認は、設定を変えても省略できません。繰り返しの作業は仕組みに任せ、責任のある判断は人が行う、という方針に基づいています。

フィードバック SDK で、課題の入口を多方向にする

ループの入口は Ticket です。Ticket は AI エージェントが切ることも、人が切ることも、レビューの指摘から生まれることもあります。これに加えて、画面からその場で送れる入口を置くのがフィードバック SDK です。公開サイトや社内の各画面に埋め込む部品で、利用者は問題の起きた画面でそのまま報告を始められます。報告の内容、画面上の箇所、スクリーンショット、診断情報が、同じ Ticket にまとまります。課題がさまざまな方向から入り、1 か所に集まる設計が、ループ全体の要です。

SDK の仕組みは次のとおりです。

• 埋め込み。既存のログインと受付の経路につなぎ、ボタンを 1 つ置く。公開サイトの匿名受付は標準では有効にしない
• 撮影と範囲の選択。表示中の画面を写し、全画面の操作で範囲を選ぶ。パスワード欄と除外指定の要素は写さない
• 受付と検査。報告の内容とスクリーンショットをそのまま信用せず、認証、機密区分、サイズ、サイトの登録を確かめてから保存する。本文に指示の形があっても、指示としては扱わない
• Ticket 化。Ticket と報告を同じトランザクションで保存する。同じ報告 ID の再送には同じ受付結果を返し、Ticket を増やさない
• 版の申告。参照している文書や記事の ID と版と見出しを、最大 5 件まで報告に添えられる

ハーネスが状態を持ち、エージェントが判断する

この設計では、対応案の検討を言語モデルに任せ、進捗や権限などの状態管理はハーネス側で行います。見分け方は、2 回実行して同じ結果になるべきものはハーネス側に置く、です。読み取りの位置、使用した ID、書き込みの権限も、ハーネス側の管理対象です。

ループは途中で止まるものとして設計します。同じ ID の呼び出しが 2 回届いても結果が 1 回分にしかならない性質を冪等と呼び、書き込みは冪等を原則にします。どこまで処理したかを示す印がカーソルで、これは書き込みが成功した後に進めます。処理の前に進めると、失敗した 1 件が未処理のまま残り、通常の巡回では再取得されません。再実行による重複は同じ ID で防げるので、迷ったら重複する側に倒します。

打ち切りも記録します。件数の上限で止めたなら、止めた件数と理由を実行の記録に残します。全部処理したのか途中で止まったのかを区別できないと、処理漏れに気づけず、安定した運用ができません。壊れた状態を見つけたときは自動で直さず、ループを止めて人に報告します。

ループの 5 要素と、止まる決まり

ループエンジニアリングでは、処理量に上限を設け、仕事が無ければ何も変えずに終わり、後続が滞ったら新しい処理を止める仕組みを作ります。そのために、すべてのループで次の 5 つを定義し、1 つでも欠けていれば運用に載せません。

• トリガー。いつ動くか。時刻、人の指示、別のループの完了のいずれか
• 入力。何を読むか
• 出力。何を書くか。書いてよい先は事前に決める
• 乾き条件。やることが無いことをどう見つけ、何も変えずに終わるか
• 予算。1 回で処理する上限と、超えた分の持ち越し方

乾き条件の無いループは、新しい情報が無いのに記事を書き直して差分を汚します。予算の無いループは、初回に全量を取りに行って取得元の制限に当たります。

下流が滞ったら上流を止めることを背圧と呼びます。レビュー待ちの成果物が増え続けないよう、人が確認できる量に合わせて取得と変換のループを止めます。1 巡回で扱う数と同時に走らせる数にも上限があり、超えたら設定を既定に戻します。処理量を人が管理できるように、実行の頻度はエージェント自身には変えさせません。人は実行記録を確認し、必要に応じて頻度や上限を変えます。図 1 は、この構造を Ticket を中心に描いたものです。

承認の関門と、別のエージェントへの引き継ぎ

処理を先へ進める前に、承認の要否と承認者を決める箇所を関門と呼びます。関門ごとに、環境単位で方式を設定します。方式は 3 つあり、human では人が承認し、agent では起案したエージェントとは別のエージェントが方針の範囲で判断して、その判断を監査に残します。none は承認を省略します。設定の無い環境はすべて human で、本番の既定も human です。先に引いた下限は、設定でも変えられません。図 2 は、流れの中に関門が並ぶ様子です。

人が判断するときは、対応案と理由、想定される影響をまとめて提示し、承認か差し戻しを選べるようにします。読んで考えて書き直す作業は人に戻しません。記録では、人が承認したもの、agent が承認したもの、承認を省略したものを区別し、agent が通したものに人の名前は記録しません。人の判断を捏造しないことは、変えない規約です。

引き継ぎもハーネスの機能です。作業の指示、使用中のブランチ、進捗を引き継ぎの情報としてまとめ、別のエージェントに渡せるようにしています。渡す相手が別の会社のモデルでも構いません。エージェントの利用枠が上限に当たったことは検知され、止まったことが人に知らされます。

セキュリティのループ

ループエンジニアリングは、セキュリティの対応にも使えると考えています。不正アクセスのような攻撃が来たとき、エージェントがログを読んで一次の切り分けを行います。切り分けとは、どこから、何に、いつ届いたかを特定することです。その結果をもとに、エージェントが対応の候補を出します。候補は、通信の遮断、鍵の無効化、設定を直前の段階へ戻すことで、選ぶのは人です。遮断と無効化の関門は human にし、設定では変えません。

そのために、ログを AI 自身が読める形で置き、検知をきっかけにしたループを即時に組めるようにすることを検討しています。対応時間を短縮できるかどうかは、実装してから検証します。

いまの記録にあるのは次の範囲です。稼働の異常は Ticket へ流し、AI は起票の提案までで、判断と承認は人が行います。障害対応の手順書には、時刻、影響のあったサービス、直近の変更を特定し、外部への送信を個別に止め、原因と復旧を Ticket に記録することが定めてあります。ログの一次確認に AI を使う方法については、導入の相談を受け付けています。

人に残る決定と、提供しているもの

この仕組みは、人による常時の見張りを減らすことを目指し、承認待ちや異常が無い範囲では夜間も処理を続ける設計にしています。本番への反映、取り消せない書き込み、権限、費用の決定は、人の手元に残ります。

UNIQUEX は、少人数でサービスを開発・運用する会社に向けて、AI エージェントに任せる作業の整理と、開発・運用の仕組みづくりを支援しています。具体的には、いまの開発手順の整理、任せる範囲と止まる条件の設計、小さく試す段階導入の計画から始めます。相談は問い合わせから受け付けています。

この記事は、社内の設計文書と作業の記録だけをもとに書いています。速さや費用の効果は測っていないため、書いていません。