エージェントを作る過程でエージェントの振る舞いを調教してみた
せーのでございます。
先日、週報を自動生成するエージェントを作りたいと思い作っていたのですが、その過程でエージェントが思っていた挙動をしてくれなかったので、human in the loopでエージェントを鍛えてみたところ、いい感じに動くようになったので、その方法を共有したいと思います。
目的
週報をチームメンバーに共有する必要があるため、週報を自動生成したいと考えていました。
現在の状況として、週報の作成が手作業になっていました。普段Obsidianでデイリーノートを書いており、日々の作業内容やお客様との会話、課題点などを記録しているのですが、週報用にマークダウンにまとめてから、手動でGoogle Document形式に直す、という流れでした。なるべくこの部分を自動化したかったのです。
具体的な要件・制約は以下のとおりです。
- 定型作業なのでスラッシュコマンドで発動させたい
- 先週から今日までのデイリーノートと関連するファイルを読み、1週間の作業内容をまとめたい
- チームメンバーに共有しておいたほうがいいお客様の課題点もまとめたい
- 最終的にGoogle Document上にあるメンバーの定例ドキュメントに書き込む必要がある
最初の実装と問題の発見
最初に、私はAIに以下のような指示を出しました。
週報を書くエージェントを作りたいです。
定型作業なのでスラッシュコマンドで発動するようにしたい。
# 要件
- 先週の木曜日から今日までのデイリーノートと関連するファイルを読んで、1週間どんな作業をしたかをまとめる
- その際チームメンバーに共有しておいたほうがいいお客様の課題点などもまとめる
- 最終的にGoogle Document上にあるメンバーの定例ドキュメントに書き込むことになるので、もっとも効率的な形を考える
- 今まではマークダウンにまとめていて、それを読んでレビュー・ディスカッションするのはできていたが、最終的にGoogle Document形式に直すのが面倒だった
この指示に基づき、週報作成エージェントを作成しました。デイリーノートを読み込んで、顧客ごとの作業内容と課題点を抽出し、マークダウンファイルとして出力する形です。
実際にこのプロンプトでエージェントを作ってみたところ、マークダウンファイルが生成されました。が、実際に使ってみると、いくつか問題が発生しました。
問題1: フォーマットがわかりにくい
生成された週報を見てみると、作業内容が文章の句点区切りになっていて、わかりにくいことが判明しました。
- 企業A: Security Hubホームリージョン移動
実験スクリプト完成。本番環境への小規模テスト準備中。
これだと、何をしたのかが一目でわかりません。箇条書きでドリルダウンして書いたほうがわかりやすいですね。
問題2: 課題の視点が違う
お客様の課題点についても、「何をするか」ではなく「お客様が何に困っているか」を書いたほうが有益だと気づきました。
例えば、以下のような形式です：
- 企業B: Vault Lockについて相談あり
- Vault Lockの期限や有用性について経営陣から疑問が飛んだらしい
- Vault Lockの他社事例やベストプラクティスなどを聞きたい、とのこと
問題3: 書き忘れが発生する
実際にエージェントを動かしてみると、デイリーノートに記載されている作業が週報に書き忘れられていることがありました。特に、社内業務やブログ執筆、学習・知識習得などの作業が漏れやすいことが判明しました。
即座の修正とその問題
問題1〜3を受けて、私はAIに以下のような指示を出しました。
作業内容が文章の句点区切りなのがわかりにくい。箇条書きでドリルダウンして書いたほうがわかりやすい。
課題は「何をするか」ではなく「お客様が何に困っているか」を書いたほうが有益。
書き忘れが起きているので、デイリーノートの「今日の作業まとめ」セクションを参照するようにしてほしい。
AIはその指示に従い、エージェントの定義を修正しました。フォーマットを箇条書きに変更し、課題の視点を「お客様が何に困っているか」に修正し、「今日の作業まとめ」セクションを参照するようにした、という対応でした。
が、そこで問題が生じました。
根本原因の分析が不十分だったのです。AIは単に「指示に従って修正する」という対応をしただけで、なぜそのような形式になったのか、なぜ書き忘れが起きたのか、という根本原因を分析していませんでした。そのため、今回の指摘には対応したものの、次回同じような問題が起きない保証がありません。エージェントが「なぜその形式が良いのか」を理解していないため、別の形で同じ問題が起きる可能性がありました。
Agent Loopの導入
そこで、プロセス重視のアプローチに転換することにしました。
私はAIに以下のような指示を出しました。
そうです。
が、そこにもう一つ、Agent loopの仕組みを入れてほしいです。
ユーザーレビューの前に、レビュー用のエージェントを作り、そのエージェントにレビューしてもらい、修正点があれば週報作成エージェントが修正し、再びレビュー用のエージェントにレビューしてもらう、問題がなければユーザーが最終レビューを行う、という形にしてください。
そしてユーザーの最終レビューで修正点が指摘された場合、その修正内容を汎用化してレビュー用のエージェントを更新してください
処理フロー
大きく「週報作成エージェント」「週報レビューエージェント」「ユーザー」の3つの主体があり、その間をデータが行き来するようなフローになりました。
週報作成エージェントの役割：
- 情報収集
- 要約・フォーマット整理
- マークダウンファイル出力
- 「週報レビューエージェント」にレビューを依頼
- レビュー指摘事項を直す（ここでAgent Loop）
週報レビューエージェントの役割：
- ユーザーからのフィードバック（修正指摘）を受けたら、まずレビュー基準を更新する
- 更新したレビュー基準でレビューする（ユーザーの意図が基準に入っているので、該当箇所はレビューに引っかかる）
- 指摘事項を添えて「週報作成エージェント」に修正を依頼
- 戻ってきたマークダウンファイルをレビュー（ここでAgent Loop）
- 問題がなければユーザーにレビューを依頼
- ユーザーのレビューが通れば「Google Doc形式に挿入するSkills」を呼び出し、内容を変換して所定のセクションにアップ
ユーザーの役割：
- 最終レビュー
- 修正指摘・ルール更新（このフィードバックは週報レビューエージェントに渡り、レビュー基準の更新に使われる）
このように、単一のエージェントではなく、複数のエージェントが協働する仕組みにすることで、各エージェントの役割が明確になり、問題の所在が明確になりました。
「直し方」の問題
Agent Loopの仕組みを作った後、実際にエージェント処理を実行して週報を作成してみました。
私からレビューで以下のような指摘がありました：
- 社内: 週次業務用エージェント作成（1/26）これだけだと、何の目的で作られたエージェントなのかわかりません。内容をもう少し書いたほうがいいです。
- 企業B: Vault Lock導入資料作成（1/28完了）こちらは実際の資料を載せたほうがわかりやすいですね。
ここで、AIは直接週報ファイルを修正しようとしました。私から指摘があったので、すぐに修正して問題を解決しようとしたのです。が、これはAgent Loopの仕組みを無視した行動でした。
週報ファイル自体を修正するのは「週報作成エージェント」の役割であり、レビューするのは「週報レビューエージェント」の役割です。AIが直接修正してしまうと、エージェントが学習する機会を奪ってしまいます。
そこで私は「直接修正してはいけません。修正するのは『週報作成エージェント』で、それを『週報レビューエージェント』がレビューして、私のところに持ってきてください。」と指摘しました。
問題を解決する方法（「直し方」）自体が間違っていたのです。
正しい「直し方」は：
-
問題の根本原因を分析する
- なぜ書き忘れが起きたのか
- なぜレビューで見つけられなかったのか
-
プロセスを改善する
- エージェントの定義を更新する
- レビュールールを更新する
-
エージェントに修正を依頼する（直接修正しない）
- 役割分担を守る
- エージェントが学習する機会を奪わない
-
学習機能を実装する
- ユーザーの指摘を汎用化してルールに追加
- 次回以降同じ問題が起きないようにする
この「直し方」の改善プロセス自体も、フィードバックを通じて改善していく必要があると、改めて理解しました。
学習機能の実装
私はAIに以下のような指示を出しました。
ユーザーレビューで指摘があった場合は、次回からそういう指摘を無くする方法を考えるようにして下さい。
例えば今回は資料のリンクを貼ったほうがいい、という指摘でした。
ということは次回以降は資料のリンクが張っていない場合は、貼ったほうがいい、というレビューをするべきですが、もしかしたら該当するリンクの存在を把握していないかもしれません。
その時はエージェント同士で確認しあい、なければユーザーに確認するのもいい週報を作る方法の一つです。
レビュールールの更新
そこでAIは、レビュールールファイルに「学習済みルール」セクションを追加し、以下のようなルールを追加しました：
作業内容の完全性チェック：
- デイリーノートの
## 今日のタスクセクションの完了タスク（[x]マーク）を全て抽出 - デイリーノートの
## 今日の予定セクションの参加イベントを抽出 - デイリーノートの
## ✅ 今日の作業まとめセクションを確認 - 上記で抽出した項目が週報の「今週の作業」セクションに全て含まれているか確認
エージェント・ツール名の目的明確化：
- エージェント名やツール名が記載されている項目を確認
- 目的が不明確な場合は、デイリーノートの
## 🚀 今日の作業進捗セクションを参照して目的を明確化
資料・成果物へのリンク記載と完全性チェック：
- 資料や成果物を作成した作業項目には、その資料へのリンクを含める
- 重要: ユーザーが指摘したキーワードで検索するのではなく、workspace内の今週更新されたファイルを全て確認する
- 複数の資料がある場合は、全ての資料へのリンクを記載する
- リンク情報が見つからない場合：
- デイリーノートの該当セクションを確認
- 週報作成エージェントに確認を依頼
- 週報作成エージェントが把握していない場合は、ユーザーに確認を依頼
エージェント間の協働
リンク情報が見つからない場合、エージェント同士で確認しあう仕組みを実装しました。エージェント同士で解決できない場合は、ユーザーに確認を依頼します。
これにより、エージェントは単独で完結せず、協働して問題を解決するようになりました。
キーワード検索の限界
実際に運用してみると、さらに細かい問題が明らかになりました。
問題1：リンクを1つ渡したら「生成物は1つ」と思い込む
私は週報レビューで「こちらは実際の資料を載せたほうがわかりやすいですね」と、資料へのリンクを1つだけ渡しました。するとAIは、そのリンクを貼って修正を終了してしまいました。他に似たような箇所がないかは考えず、指摘された1箇所だけ直した、という動きです。実際にはこのケースではエンジニア向け・上司向けの2つの資料があり、両方のリンクを載せる必要がありました。
そこで私は、修正内容を指摘されたらそれだけ直すのではなく、他にも似たような部分がないかをチェックすることが大事だとフィードバックしました（この考え方は、先の「学習機能の実装」で出した指示にも通じます）。
問題2：「上司向け」「エンジニア向け」でキーワード検索しようとする
「このケースでは上司向け・エンジニア向けの2つのリンクが実は必要だった」と伝えると、AIは「上司向け」「エンジニア向け」という2つのキーワードで文章を検索し、該当する資料を探そうとしました。ユーザーが2つのリンクを提示したから資料は2つだと判断し、そのキーワードで検索すれば全て見つかる、という考え方です。
しかしそれでは不十分です。資料の数は2つとは限りません。3つや4つある場合、キーワード検索では見逃してしまいます。また、「技術詳細版」「概要版」「簡易版」のように表現が違うだけの資料も、固定のキーワードでは拾えません。そこで私は「2つかどうかは限らない」「ユーザーが指摘したキーワードで検索するのではなく、workspace内の今週更新されたファイルを全て確認する」とフィードバックしました。
この指摘を踏まえ、レビュールールに「キーワード検索ではなく、workspace内の今週更新されたファイルを全て確認する」というルールを追加しました。ユーザーが提示したリンクの数やキーワードに頼らず、実際に存在するファイルを全て確認することで、資料の数や表現が変わっても見逃さないようにしました。
まとめ
ということで、週報を自動生成するエージェントができました。
簡単な要件でエージェントを作ると、うまく動かないことがわかりました。フォーマットの詳細や情報抽出の詳細が後から明らかになり、実際に使ってみて初めて問題が明らかになることが多いです。
そこで、Human-in-the-Loopの仕組みが重要になります。Agent Loopにより、エージェント間で自動的に修正と再レビューが繰り返され、ユーザーが介入するのは最終確認のみです。
何かを作成するエージェントを作るときは
何かを作成するエージェントを作るときは、必ずそれをテストしたり、チェックしたり、レビューしたりするエージェントを置いて、そこをループさせて、完成品をユーザーレビューにかけるという方式がいいと思います。
- 作成エージェント: 情報収集、要約、フォーマット整理、出力
- レビューエージェント: レビュー、指摘、ユーザー確認、最終処理
- ユーザー: 最終確認、修正指摘（学習機能でルール更新）
この3段階の仕組みにより、エージェントは段階的に進化していきます。
「直し方」を直すことの重要性
何も指示しないとAIは最も効率的な方法で直そうとします。が、それは汎用的な直し方ではないので、修正を入れてあげる必要があります。
問題が起きた時に、即座に修正するのではなく、なぜその問題が起きたのかを分析し、プロセスを改善することが重要です。表面的な修正ではなく、根本原因を分析し、学習機能を実装することで、同じ問題が繰り返し起きることを防げます。
そして、、、
「直し方」自体もフィードバックで改善する
このセッションで最も重要な学びは、問題を解決する方法（「直し方」）自体も、フィードバックを通じて改善していく必要があるということでした。
最初は、問題が起きたら直接修正しようとしました。しかし、ユーザーの指摘により、この「直し方」自体が間違っていることに気づきました。正しい「直し方」は、プロセスを守り、エージェントに修正を依頼し、学習機能を実装することです。
この「直し方」の改善プロセス自体も、フィードバックを通じて改善していく必要があります。これが、エージェントとHuman in the Loopによる進化の本質だと言えるでしょう。
もっとスマートな方法を御存知の方がいればぜひツイッターででも教えて下さい。
