生成AIを開発に使う機会が増え、最近では「AIに実装を任せる」こと自体はそれほど珍しくなくなってきました。
一方で、実際にAIを使っていると、こんな場面がよくあります。
- AIにタスクを依頼する
- AIが実装する
- 人間が結果を確認する
- 問題があれば人間が再びAIに指示する
- AIが修正する
- また人間が確認する
確かに実装作業そのものはAIが行っています。
しかし、人間が毎回「確認 → 判断 → 再指示」をしているのであれば、AIが自律的にタスクを進めているとは言いにくい気がします。
では、どうすればAIはもっと自律的にタスクを進められるのでしょうか。
最近いろいろなAIツールを試す中で、重要なのはAIモデルそのものの性能だけではなく、AIが行動した結果を自分で観測し、評価し、その結果を次の行動につなげられる「閉ループ」を作ることなのではないかと考えるようになりました。
この記事では、現時点で考えている「AIに自律的にタスクを進めてもらうための閉ループ設計」について整理してみます。
なお、まだ実際の開発プロセス全体に適用して十分な検証を行ったものではありません。
あくまで今後試していくための設計・仮説の整理です。
閉ループとは何か
まず、普段AIに開発を依頼するときの流れを単純化すると、次のようになります。
人間
↓
AI
↓
実装
↓
人間が確認
↓
AIへ再指示
AIは実装できますが、その結果を評価して次に何をするか決めているのは人間です。
つまり、AIから見ると処理は途中で途切れています。
これを次のようにできればどうでしょうか。
目的・タスク
↓
計画
↓
実行
↓
実行環境
↓
結果を観測
↓
結果を評価
↓
成功した？
↙ ↘
いいえ はい
↓ ↓
再計画 完了
↓
再実行
AIが何かを実行したあと、その結果を再びAIが取得します。
そして、
- 期待した結果になったのか
- 失敗したのか
- 修正が必要なのか
- タスクは完了したのか
を判断します。
失敗していれば、結果をもとに再計画してもう一度実行します。
成功していればタスクを完了します。
「実行」の結果が「観測」を通して次の「実行」に戻ってくる。
この記事では、このような構造を「閉ループ」と呼ぶことにします。
AIが賢くなるだけでは自律化しない
最近のLLMはかなり賢くなっています。
コードを書かせても、ある程度まとまった機能であれば一度の依頼で実装できることも増えてきました。
そのため、モデルがさらに賢くなれば、そのまま自律化も進んでいくように感じます。
しかし、モデルがどれだけ賢くても、
実装しました
↓
本当に動くかは分からない
↓
人間が確認
となっている限り、人間はループの中に残ります。
逆に、多少性能の低いモデルだったとしても、
実装
↓
テスト
↓
失敗
↓
ログ確認
↓
修正
↓
再テスト
↓
成功
まで自分で回せるのであれば、一定のタスクについてはかなり自律的に進められる可能性があります。
もちろんモデル性能は重要です。
ただ、自律化を考える場合、
「どのモデルを使うか」と同じくらい「モデルの出力をどう評価して次の入力へ戻すか」が重要なのではないか
と考えています。
閉ループを成立させるために重要そうなこと
では、実際に閉ループを作る場合、何が必要になるのでしょうか。
現時点では、大きく以下の要素が重要だと考えています。
1. 完了条件をAIが判定できること
まず難しいのが「何をもって完了とするか」です。
例えば、
ログイン画面をいい感じに修正してください
というタスクがあったとします。
実装自体はAIでもできます。
しかし「いい感じになったか」をAIが機械的に判定するのは簡単ではありません。
一方、
- 正しいID・パスワードでログインできる
- 誤ったパスワードではエラーが表示される
- 未入力の場合はバリデーションが表示される
- ログイン成功後はホーム画面へ遷移する
まで定義されていれば、かなり評価しやすくなります。
要件
↓
実行・評価可能な完了条件
↓
AIによる実装
↓
テスト
↓
成功 / 失敗
閉ループを作るためには、要求を単に文章として与えるだけではなく、AI自身が「できた」と判定できる形に落とすことが重要になりそうです。
これはAI駆動開発を考える上で、かなり大きなテーマだと思っています。
2. AIが自分の仕事の結果を観測できること
次に必要なのが「観測」です。
例えばAIがコードを書けたとしても、
- 実際の画面
- テスト結果
- コンソール
- サーバーログ
- APIレスポンス
- DBの状態
などを見ることができなければ、実装結果が正しかったのか分かりません。
そのため閉ループでは、実装を担当するAIだけではなく、
実装を担当するAI
↓
アプリケーション
↓
テスト / ブラウザ / Computer Use
↓
結果を観測
↓
AIへフィードバック
のように、実際の環境から結果を取得する仕組みが重要になると考えています。
Computer Useによって観測できる範囲を広げる
ここで個人的に注目しているのがComputer Useです。
Computer Useは、AIがスクリーンショットなどから画面の状態を認識し、マウスやキーボードに相当する操作を行うことで、人間がGUIを操作するのと近い形でPCやアプリケーションを扱う仕組みです。
従来のAIによる開発では、
コードを書く
↓
コマンドを実行する
↓
テスト結果やログを読む
といった、AIが直接扱いやすい情報を中心に閉ループを作ることになります。
しかし実際の業務では、すべての情報がAPIやログとして綺麗に取得できるわけではありません。
人間がブラウザを開き、
「このボタンを押すとどうなるか」
「実際の画面には何が表示されているか」
「この操作をするとエラーが再現するか」
と確認している場面はかなりあります。
Computer Useを利用すると、この「人間が画面を見て操作する」という部分までAIが担当できる可能性があります。
AI
↓
画面を確認
↓
操作
↓
画面が変化
↓
変化後の画面を確認
↓
次の操作を判断
↓
再び操作
よく考えると、これ自体が小さな閉ループになっています。
そのためComputer Useは単なる「AIにPC操作をさせる便利機能」というより、AIが観測・行動できる環境をGUIまで広げる技術として見ると、自律化においてかなり重要なのではないかと思っています。
もちろん、すべてをComputer Useで行う必要はありません。
APIから取得できる情報はAPIを使った方が安定しますし、テストコードで確認できるものは自動テストを使った方が高速で再現性も高くなります。
理想的には、
AI
↓
何で確認するべきか？
↙ ↓ ↘
自動テスト API Computer Use
↓ ↓ ↓
└──── 結果を観測 ────┘
↓
結果を評価
のように、対象に応じて適切な観測手段を選べる状態だと思います。
その中でComputer Useの価値は、これまで「人間が画面を見るしかなかった領域」までAIの観測範囲にできる可能性があることです。
閉ループを成立させるには、AIが自分の行動結果を観測できなければなりません。
そう考えると、Computer Useの進化は単なるPC操作の自動化ではなく、AIが自律的に仕事を完了できる領域そのものを広げるものになるのではないかと考えています。
3. 「作るAI」と「評価するAI」をどうするか
もう一つ気になっているのが評価です。
例えば、あるAIに、
この機能を実装してください
と依頼します。
実装後に同じAIへ、
この実装は正しいですか？
と聞いた場合、本当に十分な評価になるのでしょうか。
自分で作ったものを自分で評価すると、最初の思い込みや解釈をそのまま引き継いでしまう可能性があります。
そこで、
要件
↓
実装を担当するAI
↓
実装
↓
評価を担当するAI
↙ ↘
失敗 成功
↓ ↓
実装担当へ戻す 完了
のように、実装するAIと評価するAIを分離する方法が考えられます。
必ずしも別のLLMを使う必要はなく、
- コンテキストを分離する
- 評価専用のプロンプトを使う
- テスト結果を中心に判断させる
- 必要に応じて別モデルを利用する
など、いろいろな方法が考えられそうです。
どこまで分離するのが効果的なのかは、今後実際に検証してみたい部分です。
4. 失敗した後の設計が重要
閉ループというと、
実装
↓
テスト
↓
失敗
↓
修正
↓
再テスト
を繰り返せばよいようにも見えます。
しかし、単純にこれを繰り返すだけでは、
修正
↓
失敗
↓
修正
↓
失敗
↓
修正
↓
失敗
↓
……
という無限ループになる可能性があります。
そのため実際には、
失敗
↓
原因分析
↓
再計画
↓
修正
↓
再評価
のような構造が必要になるはずです。
さらに、
- 同じエラーが何回続いたか
- 同じ修正を繰り返していないか
- 別のアプローチへ切り替えるべきか
- 追加情報が必要なのか
- 人間へ確認すべきなのか
といった状態も管理する必要があります。
閉ループで重要なのは「何度でもAIにやらせること」ではなく、失敗から次の行動を変えられることなのだと思います。
5. 人間へのエスカレーションを設計する
AIを自律化しようとすると、「いかに人間を介在させないか」を考えがちです。
ただ、すべてをAIだけで解決する必要はないと思っています。
むしろ重要なのは、
「どの状態になったら人間を呼ぶか」
を明確にすることではないでしょうか。
例えば、
- 要件が複数の意味に解釈できる
- 破壊的変更が必要
- セキュリティ上重要な判断が必要
- 一定回数以上失敗している
- AIの評価結果に十分な確信がない
場合だけ人間へエスカレーションします。
人間
▲
│
判断が必要な問題のみ
│
管理役のAI
／ │ ＼
実行AI 実行AI 実行AI
↕ ↕ ↕
閉ループ 閉ループ 閉ループ
通常の問題は下位のループで解決し、解決できないものだけ上位へ送ります。
これができれば、人間はAIの作業を逐一確認するのではなく、AIだけでは判断できない問題に集中することができます。
個人的には、このエスカレーション設計がAI自律化ではかなり重要になるのではないかと考えています。
大きなタスクは階層化できるのではないか
さらに考えていくと、一つの閉ループだけではなく、複数の閉ループを階層化できるのではないかと思っています。
例えば、
プロジェクトの目的
↓
管理役のAI
／ │ ＼
機能A 機能B 機能C
↓ ↓ ↓
閉ループ 閉ループ 閉ループ
上位のAIはプロジェクト全体の目的を管理し、下位のAIへタスクを分割します。
各下位AIは自分の担当範囲について、
計画
↓
実行
↓
観測
↓
評価
↓
再計画
を繰り返します。
下位で解決できない問題だけ上位へエスカレーションします。
そして上位でも判断できない問題だけ人間へ送ります。
もしこの構造が十分に機能するのであれば、人間が管理する単位を、
個々のタスク
から、
達成したい目的
へ徐々に引き上げられる可能性があります。
これはAIを使って大量にコードを書くこと以上に、個人的には興味がある部分です。
閉ループは開発以外にも使える
ここまで開発を例に書いてきましたが、この考え方自体は開発に限定されないと思っています。
例えばコンテンツ生成なら、
コンテンツを生成
↓
ユーザーからの反応を取得
↓
反応を分析
↓
改善
↓
再生成
教材なら、
問題を生成
↓
ユーザーが回答
↓
正答率・離脱などを観測
↓
難易度や内容を調整
↓
次の問題を生成
テストなら、
対象を操作
↓
結果を観測
↓
期待値と比較
↓
問題を発見
↓
課題として記録
となります。
共通しているのは、AIが何かを生成して終わるのではなく、生成物が環境へ投入され、その結果が再びAIへ戻ってくるという点です。
このフィードバックをどのように作るかが、AIを単なる生成ツールから自律的に仕事を進める仕組みへ変えていく上で重要になるのではないかと考えています。
OutSystems開発でも試してみたい
自分は普段OutSystemsを使った開発をしているため、この閉ループをOutSystems開発にも適用できないかと考えています。
例えば将来的には、
要件
↓
タスクを計画
↓
AIによる開発
↓
OutSystemsアプリケーション
↓
自動テスト / Computer Use
↓
結果を評価
↓
成功した？
↙ ↘
いいえ はい
↓ ↓
修正 証跡を保存
↓ ↓
└──────→ 完了
のような形です。
特にOutSystemsのようなローコード開発では、従来のコード中心の開発とは異なる部分があります。
そのため、
- 開発を担当するAIとOutSystemsをどう接続するか
- 実行環境をAIからどう観測するか
- UIをどこまで自動評価できるか
- 要件や受入条件をどう管理するか
- 修正後の影響範囲をどう評価するか
- どこで人間の承認を入れるべきか
など、実際に試してみないと分からないことがかなりありそうです。
ここは今後実際に検証してみたいと思っています。
まとめ
AIによる自律化について考えると、どうしても「もっと賢いモデルを使えば解決する」と考えたくなります。
もちろんモデル性能の向上によって解決される問題も多いと思います。
一方で、AIがどれだけ賢くなっても、そのAIが自分の仕事の結果を見ることができなければ、人間が結果を確認する必要があります。
現時点では、
目的
↓
計画
↓
実行
↓
観測
↓
評価
↓
再計画
というループをどこまでAI自身で回せるようにするかが、自律化を考える上で重要なのではないかと考えています。
そして、そのためには少なくとも、
- 機械的に評価可能な完了条件
- 実行結果を観測する仕組み
- 実行するAIと評価するAIの役割
- 失敗からの再計画
- 無限ループを防ぐ仕組み
- 人間へのエスカレーション
- タスクや目的の階層化
といった設計が必要になりそうです。
AI駆動開発というと「AIにどう実装させるか」に注目しがちですが、今後はそれ以上に、
「AIが実装した後、どうやって自分で正しさを確認し、次の行動を決めるのか」
を設計することが重要になってくるのかもしれません。
個人的には、AIの自律化とは単にプロンプトを工夫することではなく、
「AIが行動した結果が、次の行動を決めるための入力として戻ってくる構造を作ること」
なのではないかと考えています。
今後はこの仮説を、実際のOutSystems開発などに適用しながら検証していきたいと思います。